Бюджет: 5000 UAH Термін: 3 дні
Вітаю.
Маю досвід з автоматизаціями CRM систем. Можу допомогти. Пишіть, обговоримо.
Тестуємо salesdrive срм і хочемо щоб дані з цієї срм коректно передавались на пром і розетка. В нас є декілька постачальників від яких берем інформацію через XML файл і завантажуємо в срм. Потім формуємо одне YML посилання в срм і по ньому хочемо передавати і робити оновлення на пром і розетка. Але в процесі тестування виявилось багато труднощів і ручної роботи. Зараз ми працюємо з кіпін срм і там вся інформація. Завдання адаптувати salesdrive срм до пром і розетка, щоб дані з срм коректно передались і оновлювались на маркетплейсах. деталі в спілкуванні.
Важливо! Цікавить виключно ІНТЕГРАЦІЯ ТОВАРІВ та їх подальше автоновлення!
Бюджет: 5000 UAH Термін: 3 дні
Вітаю.
Маю досвід з автоматизаціями CRM систем. Можу допомогти. Пишіть, обговоримо.
Бюджет: 5000 UAH Термін: 7 днів
Привіт, я працював над інтеграцією CRM системи з маркетплейсами Prom та Rozetka для автоматизації управління товарами - скоротив час обробки на 80% та збільшив точність синхронізації до 98%
Чи маєте проблеми з некоректним мапінгом полів між SalesDrive та специфічними вимогами YML для Пром і Розетки?
Пропоную зв'язатися, я безкоштовно проконсультую вас з технічної сторони та складемо план розробки + розповім про мою команду! ✨
Бюджет: 5000 UAH Термін: 3 дні
ДОБРОГО ДНЯ. Є ГОТОВА СИСТЕМА З ІНТЕГРАЦІЄЮ XML ФАЙЛІВ І ПОДАЛЬШОЮ ОБРОБКОЮ КОНТЕНТУ ТА СИНХРОНІЗАЦІЄЮ КАТЕГОРІЙ І ХАРАКТЕРИСТИК З ПРОМОМ ЗА ДОПОМОГОЮ AI. МОЖЛИВО ВАМ БУДЕ ЦІКАВО ОЗНАЙОМИТИСЬ, ДЕТАЛІ В ЛС.
Бюджет: 5000 UAH Термін: 2 дні
Добрий вечір.
ТЗ зрозумів. Напишу кастомні скрипти для роботи з даними. В результаті обновленя цін і залишків буде автоматичним. Додавання нових товарів буде з мінімальним первинним втручанням.
Пишіть, обговоримо деталі.
Бюджет: 5000 UAH Термін: 5 днів
Добрий вечір. Регулярно працюю з SalesDrive та маркетплейсами.
Зв`язати SalesDrive та Prom взагалі без проблем, щодо Rozetka - є нюанси.
Пишіть - обговоримо всі деталі.
Бюджет: 5000 UAH Термін: 5 днів
Вітаю, Андрію! Я Ніна, менеджер інженера-розробника Валентина. Ми вивчили ваше завдання по синхронізації товарів і готові запропонувати рішення, яке прибере 90% рутини.
Ми розуміємо специфіку: стандартний експорт з CRM часто «спотикається» об жорсткі вимоги Розетки до характеристик і категорій. Наш підхід — це не просто налаштування, а створення стабільного процесу.
Що ми реалізуємо:
Автоматизація імпорту: Налаштуємо забор XML-файлів від ваших постачальників безпосередньо в систему.
Smart Middleware (Python): Напишемо прошарок, який буде автоматично «прибирати» дані під вимоги маркетплейсів (валідація категорій, параметрів і фото) перед передачею в SalesDrive.
Синхронізація 24/7: Оновлення цін і залишків буде працювати на 100% автопілоті. Це критично, щоб не ловити скасування замовлень.
Рішення для Розетки: Ми знаємо, що нові товари вимагають ручної модерації на стороні площадки. Наша задача — зробити так, щоб вивантаження було технічно ідеальним, і модерація проходила з першого разу в один клік.
Чому варто працювати з нами:
Валентин спеціалізується на Python-автоматизації і роботі з API. Ми не просто «пробуємо» CRM, ми змушуємо її працювати на ваш бізнес. Весь процес підготовки даних буде прозорим і позбавленим «сміттєвих» помилок.
Попередні умови:
Термін: 5–7 днів.
Бюджет: 5 000 — 7 000 грн (точно після аналізу XML-файлів постачальників).
Андрію, скільки зараз різних XML-структур від постачальників нам потрібно об'єднати в один потік?
Бюджет: 27000 UAH Термін: 14 днів
Ваша задача з інтеграції salesdrive CRM з маркетплейсами PROM і Розетка виглядає цікавим, але й досить складним проєктом. Основним викликом буде налаштування коректної передачі даних через XML і YML формати, а також уникнення ручної роботи, що ви вже виявили під час тестування. Я пропоную спочатку проаналізувати структуру даних, щоб виявити потенційні проблеми з несумісністю між системами. Напередодні реалізації я планую створити чіткий план дій і протестувати всі етапи інтеграції, щоб гарантувати безперебійну роботу з оновленнями на маркетплейсах.
Важливо також врахувати, що процес адаптації може потребувати додаткових доробок в залежності від специфіки даних постачальників. Чи є у вас детальна документація щодо специфікацій API для PROM і Розетка? Це допоможе у значній мірі прискорити процес.
Готовий почати, щоб забезпечити вас стабільною і ефективною системою. Пропоную обговорити деталі, щоб уточнити всі вимоги і запустити проєкт.
Бюджет: 5000 UAH Термін: 1 день
Вітаю! Мав досвід роботи з salesdrive, робив розширення.відпишіть в Приват для обговорення деталей.
Бюджет: 5000 UAH Термін: 5 днів
Доброго дня, є досвід роботи з salesDrive. Можемо обговорити деталі проекту, вже є одна пропозиція по реалізації. Ціна і термін умовні, все після ТЗ. Заздалегідь дякую.
Бюджет: 5000 UAH Термін: 1 день
Привіт!
Ми dZENcode – компанія повного циклу розробки цифрових рішень: від дизайну та програмування до інтеграцій та пострелізної підтримки. Беремо проекти з нуля і підключаємось до доопрацювання існуючих рішень.
Ми можемо допомогти з адаптацією SalesDrive CRM та передачею даних на Prom і Rozetka.
Можемо обговорити зміст прикріпленого прямо тут?
Докладну інформацію про наші послуги та ставки ви знайдете на сайті: Freelancehunt
Подивіться – після цього зможемо обговорити деталі та узгодити наступний крок.
⚠️ Після уточнення всіх деталей визначимо обсяг, підходящий формат співпраці: позадачно, аутсорс або аутстафф і фінальну вартість.
Чому з нами проекти гарантовано доходять до релізу:
💎 10+ років надаємо IT-послуги;
🔥 90+ штатних спеціалістів;
🚀 250+ публічних відгуків з 2015 року;
⚙️ Підтримуємо продукт за SLA після запуску;
✅ Працюємо за NDA та договором з компанією!
Бюджет: 6000 UAH Термін: 4 дні
Вітаю. Реалізую коректну синхронізацію SalesDrive з Prom та Rozetka через автоматизацію обробки XML/YML фідів. Налаштую парсинг вхідних файлів від постачальників за допомогою Python, щоб автоматизувати оновлення залишків та цін без ручної роботи.
Маю досвід розробки комплексних систем автоматизації та інтеграції через API. Виключу помилки дублювання товарів та некоректного відображення характеристик при формуванні фінального посилання для маркетплейсів.
Яку кількість товарних позицій потрібно синхронізувати та чи є специфічні вимоги до маппінгу категорій між Keepin CRM та SalesDrive?
Бюджет: 5000 UAH Термін: 3 дні
Доброго дня!
Маю досвід інтеграції SalesDrive CRM з Prom та Rozetka. Автоматизую передачу й оновлення даних з XML/YML файлів на маркетплейсах. Вирішу складні завдання та оптимізую процеси.
Напишіть мені в лс, уточнимо деталі.
Без ручної обробки не обійтись. Оновляти ціни і наявність можна, але ручна обробка неминуча
Правильно Олександр каже, Розетка не дає автоматичного вивантаження нових товарів, тільки оновлення залишків та цін.
Коротко Нужна программа на Python, которая запускается у меня на ПК (Windows) и делает faceless-видео формата «закадровый голос + сменяющийся видеоряд из фото и клипов» — как исторические документалки на YouTube (пример прикреплю отдельно). Я ввожу тему → программа пишет сценарий, озвучивает, подбирает под каждый кусок текста видео/фото из бесплатных архивов, склеивает → выдаёт готовый MP4. Только для меня. Без сайта, без пользователей, без продажи. Один пользователь — я. Как работает (по шагам) 1. Ввод. Открывается простое окно. Я ввожу тему ролика и выбираю голос озвучки из списка (**список голосов подтягивается автоматически из ElevenLabs по API** — доступные на моём аккаунте). Жму «Создать». (Второй режим: вставить готовый сценарий вместо генерации.) 2. Сценарий. Программа через LLM API (OpenAI/Anthropic, ключ в настройках) пишет сценарий по теме, заданной длины. 3. Разбивка на сцены. LLM делит сценарий на сцены и для каждой возвращает: текст сцены; тип визуала: видео или фото; поисковый запрос (развёрнутая фраза, что должно быть в кадре); пометку «highlight» + оценку важности 1-10 (для интро, см. ниже). 4. Озвучка. Текст отправляется в ElevenLabs API выбранным голосом → аудио. Под длину аудио каждой сцены режется видеоряд. 5. Подбор видео/фото — из бесплатных источников по API (см. список ниже). Под каждый источник запрос формируется по-своему (для точности). Если в одном не нашлось — пробует следующий. 6. Проверка (максимум 3 шага на сцену). Шаг 1: программа берёт первый найденный вариант (видео/фото) по запросу. Шаг 2: отправляет кадр в LLM — «подходит под сцену?». Подходит → стоп. Шаг 3 (если не подходит): программа переключается на поиск фото (по точному запросу фото найти проще, чем видео, — так гарантированно попадаем по смыслу) и берёт его с усиленным движением (зум + панорама). Больше 3 шагов на одну сцену не делать — это экономит бюджет LLM и гарантирует, что кадр в тему. 7. Сборка через ffmpeg/moviepy: клипы и фото под тайминг озвучки, фото оживляются зумом (эффект Кена Бёрнса), голос поверх, простые переходы. Выход: MP4 1920×1080. Правила видеоряда (важно — за это отвечает программа) Первые 60 секунд — интро-тизер: нарезка самых эффектных клипов из всего ролика (берутся сцены с высшей оценкой важности, где есть видео) под отдельный текст-вступление от LLM («в этом видео вы узнаете…»), кадры без пояснений, как интрига. Потом переход и основная часть. Чередование: видео-вставка минимум каждые ~6 секунд, нельзя много фото подряд. Доля видео: не меньше ~40% времени — живые клипы, остальное — фото с зумом. Длина кадра: 4-6 секунд (и фото, и видео). Не мельтешить, не держать статику долго. Для чисто исторических тем, где видео нет — фото с усиленным движением (зум + панорама). Источники (все бесплатные, с API) Современное видео+фото: Pexels, Pixabay. Историческое / архивное (public domain): Wikimedia Commons, Archive.org,Library of Congress, Europeana, NASA, Smithsonian Open Access,Flickr Commons, openverse. Каждый источник — отдельный модуль, легко добавить новый. Использовать только public domain / свободные лицензии с правом коммерческого использования. Никакого парсинга чужих YouTube/сайтов, кусков фильмов, картинок «из гугла».Уникальность подбора Чтобы видео не совпадали с чужими: брать случайный клип из топ-выдачи (не первый), вести базу уже использованных (не повторять), опционально — лёгкая обработка клипа (кроп/зеркало/ скорость). Опции (вкл/выкл в настройках) Только фото — если включено, видео собирается ЧИСТО из фото, без видео-клипов. Каждое фото ОБЯЗАТЕЛЬНО с движением (зум и/или панорама, эффект Кена Бёрнса) — даже в этом режиме не должно быть статичных «мёртвых» кадров, минимальная динамика всегда. Если выключено — стандартный режим (фото + видео-клипы с чередованием, как в правилах видеоряда). Без озвучки — если включено, видео собирается по тексту БЕЗ генерации голоса: код НЕ обращается к ElevenLabs и не накладывает озвучку (видеоряд подбирается по тексту сцен, тайминг кадров — по правилам/параметрам, без привязки к аудио). Если выключено — автоматически делает озвучку по тексту через ElevenLabs, как обычно. Атмосферный оверлей — если включено, поверх всего видеоряда накладывается полупрозрачный слой с плавающими частицами / пылью / светящимися боке / лёгким туманом (particle / dust / bokeh / fog overlay, режим наложения screen/add), чтобы кадры выглядели живыми и кинематографичными. При установке программы кладётся набор из 5-8 популярных оверлеев (частицы, пыль,copyбоке, туман, лёгкое киношное «зерно») в локальную папку — я выбираю нужный из списка. Регулируемая прозрачность/яркость оверлея (ползунок 0-100%), чтобы эффект не был ниcopyслишком тусклым, ни слишком выраженным — я сам настраиваю силу. Желательно, чтобы оверлей можно было накладывать и на УЖЕ готовое видео отдельноcopy(постобработка: взять готовый MP4 → выбрать оверлей → задать прозрачность → сохранить), а не только при сборке. Откуда взять оверлеи для комплектации (свободная лицензия): Pexels, Pixabay (запросыcopy«particle overlay», «bokeh overlay», «dust overlay», «light leaks», «film grain»), Mixkit, Videezy. Исполнитель подбирает 5-8 штук и кладёт в папку программы. Субтитры (вшить или отдельным .srt). Обработка клипов для уникальности. Разрешение/формат, длина видео, доля видео, глубина поиска.Технические требования Python. Модульная структура (источники и LLM — через сменные модули, чтобы легко заменить или добавить). Все API-ключи — в файле настроек, не в коде. Простое окно (GUI на выбор исполнителя — Tkinter/PyQt), запуск двойным кликом. README с инструкцией, понятные логи, комментарии в коде.Что даю я API-ключи (ElevenLabs, LLM, где нужна регистрация — оформлю). Платное оплачиваю сам. Примеры видео-референсов (прикреплю) и примеры тем для тестов.Приёмка (готово, если) Запускаю → окно → ввожу тему, выбираю голос → «Создать» → получаю готовый MP4. Видеоряд по смыслу текста, чередование видео/фото, интро-тизер 60 сек, озвучка поверх. Работает минимум с 6 бесплатными источниками, с fallback между ними. Проверка кадров через LLM: макс. 3 шага на сцену (нашли → LLM проверил → если нет, фото с движением как верняк). Уникальность: рандомизация + база использованного. Только легальные источники. Есть README, запускается с нуля.Передача результата Весь исходный код — в открытом виде (все файлы), без обфускации + собранная рабочая версия. Я могу сам запустить из исходников по инструкции (README: установка, ключи, запуск). Код должен быть чистым, прокомментированным и понятным, чтобы **любой другой программист мог продолжить работу** над ним, если понадобится (не привязка к автору). **Вся повседневная работа — через интерфейс (кнопки, поля, ползунки, выпадающие списки), БЕЗ необходимости трогать код.** Все настройки (тема, голос, опции, оверлей, папки, длина, форматы) меняются в окне программы, а не редактированием файлов. Код на руках — только как моя собственность и страховка, а не как способ управления программой. Все права на код после оплаты — мои.Управление местом на диске (важно) Программа не должна забивать диск. Реализовать: После сборки видео все промежуточные файлы (скачанные клипы, временные куски, аудио-нарезки) автоматически удаляются — на диске остаётся только готовый MP4. Лимит на кэш (параметр в настройках, напр. 5 ГБ): при превышении старые скачанные файлы удаляются автоматически (сначала самые старые). Папку для готовых видео и для временных файлов я задаю в настройках. Показывать, сколько места занято, и кнопка «очистить кэш» вручную.Прошу указать в отклике Примеры похожих работ (ffmpeg/moviepy, работа со стоковыми/архивными API, ElevenLabs/LLM). Предложение по GUI. Использует ли решение базу данных (какую и зачем) — или хватает локальных файлов. Срок и стоимость.
Розробляємо real-time інтеграцію з зовнішнім сервісом Тренер. Відправляємо структуровані знімки стану, отримуємо рекомендації і показуємо їх спливаючим вікном. Завдання — стабільна і повна передача даних для коректної роботи Тренера. Шукаємо розробника для ланцюга: обробка даних → HTTP-комунікація → overlay. Потрібні люди з такими навичками Python добре, Java база, API HTTP/JSON-APIs Проект готовий на 90%, але є деякі несоответствия
Проект: Ми запускаємо B2B-сервіс наскрізної аналітики та управління рекламними кампаніями для таргетологів і медіабайерів. Продукт працюватиме з офіційним Meta API. Головна технічна складність і фокус проекту — віртуозна робота з лімітами Facebook, маршрутизація трафіку між пулом наших додатків і жорстка система захисту інфраструктури від блокувань сірими рекламними акаунтами. У нас вже є детальне технічне завдання, описана архітектура баз даних, логіка балансувальника та вимоги до інтерфейсів. Шукаємо виконавця, який візьме це в реалізацію під ключ (бекенд + фронтенд дашбордів). Що потрібно зробити (Ключові завдання): Інтеграція з Meta API: Налаштувати авторизацію користувачів і регулярний асинхронний парсинг статистики рекламних кабінетів. Запити повинні надсилатися виключно пакетами для економії лімітів. Система авто-відізвання кабінетів: Написати модуль, який безперервно моніторить статуси рекламних акаунтів. Якщо кабінет потрапляє в бан, система повинна автоматично відкликати токен доступу протягом 60 секунд, щоб захистити наше додаток від санкцій Meta. Інфраструктура проксі: Реалізувати тунелювання всіх запитів до API через пул SOCKS5. Обов'язкова жорстка прив'язка конкретного токена користувача до статичного IP-адреси. Розумна маршрутизація: Створити алгоритм, який буде розподіляти прив'язані рекламні кабінети між кількома нашими додатками Facebook у заданих пропорціях для зниження ризиків. Розробка інтерфейсів: Створити клієнтський дашборд зі зведеною таблицею статистики та просунуту адмін-панель для ручного управління лімітами користувачів, прив'язками до додатків і пулом проксі. Очікуваний стек технологій: Бекенд: Python, FastAPI. Асинхронні задачі: Celery, Redis. Бази даних: PostgreSQL (або ClickHouse для статистики, на ваш розсуд). Фронтенд: Vue.js або React (можна використовувати готові UI-бібліотеки та шаблони дашбордів, акцент на функціональність, а не складний дизайн). Вимоги до виконавця: Упевнений досвід роботи з Meta Graph API та Marketing API. Ви повинні розуміти, як працюють ковзаючі ліміти, як читати заголовки завантаженості та як працювати з токенами. Розуміння специфіки арбітражу трафіку. Слова «білінг», «бан рекламного кабінету», «бізнес-менеджер» і «фарм» не повинні викликати у вас запитань. Досвід побудови асинхронних парсерів і роботи з проксі-серверами на рівні мережевих запитів. Готовність працювати за чітким технічним завданням і здавати проект поетапно. Умови: Формат співпраці: Проектна робота (з можливістю переходу на довгострокову підтримку та доопрацювання нових модулів). Бюджет: Обговорюється індивідуально на основі вашої оцінки технічного завдання. Оплата: Поетапна, прив'язана до контрольних точок. Як відгукнутися: У супровідному листі обов'язково вкажіть ваш досвід роботи з Meta API, прикріпіть посилання на схожі проекти (або опишіть їх функціонал, якщо вони під NDA) і напишіть орієнтовну вилку цін і термінів на розробку подібної системи з нуля. Відгуки без опису релевантного досвіду роботи з Facebook API розглядатися не будуть.
Необхідно розробити локальний Python-скрипт для автоматичного заповнення Google Таблиці даними з внутрішнього сервісу компанії. Основна логіка: 1. Підключитися до Google Таблиці. 2. Знайти рядки, де заповнений ID, але відсутні два цільових значення. 3. Сформувати посилання за шаблоном: https://internal-service.example/item/{ID} 4. Отримати два значення (через API, якщо він існує, інакше через Playwright). 5. Записати значення назад у Google Таблицю. 6. Позначити рядок як оброблений. 7. Продовжити обробку наступних рядків. Вимоги: • Python • Google Sheets API • Пріоритет використання офіційного API • При відсутності API — Playwright • Без OCR, розпізнавання екрана та координат миші • Конфіденційні дані не повинні потрапляти в логи • Конфігурація через .env • Тестовий режим (без запису в таблицю) • Не обробляти вже заповнені рядки • Пакетна запис змін у Google Sheets • Коректна обробка помилок і повторних спроб Необхідно надати: - вихідний код; - requirements.txt; - приклад .env.example; - інструкцію по установці; - інструкцію по запуску; - короткий опис архітектури. Перед початком реалізації прошу: 1. Запропонувати архітектуру. 2. Перелічити необхідні доступи. 3. Задати уточнюючі питання. 4. Вказати вартість, терміни та орієнтовну кількість годин.
В рамках підвищення рівня кібербезпеки нашої інфраструктури нам необхідно відмовитися від практики зберігання «вічних» і статичних API-ключів, паролів і токенів інтеграцій у конфігураційних файлах (.env, appsettings.json, config.yaml) наших мікросервісів. Бізнес-мета: Створити єдину захищену точку зберігання конфіденційних даних (секретів) з механізмом їх автоматичного оновлення (ротації) у зовнішніх системах за розкладом. Інші наші сервіси будуть запитувати актуальні токени «на льоту» через API, що зведе до мінімуму шкоду в разі компрометації будь-якого з компонентів системи.Модель безпеки та шифрування (Crypto Core) У базі даних жоден секрет не повинен зберігатися в відкритому вигляді. При старті програми в змінні середовища передається Майстер-ключ (Master Key). Якщо ключ відсутній або має невалідну довжину, сервіс повинен падати на етапі ініціалізації з зрозумілою помилкою в логах. Кожен секрет шифрується перед записом у БД з використанням цього Майстер-ключа. При запиті — розшифровується в пам'яті і віддається в тілі відповіді.Аудит-логування (Audit Trail) Будь-яка дія з секретами (створення, читання сервісом, успішна або неуспішна ротація) повинна записуватися в окремий лог-файл audit.log (або окрему таблицю в БД). Суворе табу: В аудит-лог категорично заборонено записувати самі значення секретів (ні в відкритому, ні в зашифрованому вигляді).