Організація магазину на базі текдок

Шукаємо спеціаліста з автоматизації (Google Apps Script / Make.com / Zapier / Portant або аналогічних сервісів) та дизайну документів, який допоможе реалізувати напівавтоматичне створення звітів для клієнтів. По факту нам потрібний шаблон, з яким можуть працюювати наші спеціалісти. Суть задачі: Наші спеціалісти мають вносити всі дані про замовлення у зручну Google Таблицю. Для клієнта ці дані мають автоматично (або за кліком) конвертуватися у презентабельний, структурований PDF-документ із фірмовим стилем компанії. Важливо, щоб у PDF коректно підтягувалися скріншоти листування, реальні фото товарів та автоматично будувалися діаграми. Важливо: PDF-документ є окремим документом. Технічні вимоги та очікуваний функціонал Введення даних: Тільки через Google Sheets (зручні випадаючі списки, оцінки, посилання на зображення в Google Drive або пряме вставлення в комірки). Генерація PDF:Г Клієнт отримує чистий PDF-файл, який не виглядає як звичайна екселівська таблиця, а має вигляд професійного бізнес-звіту/презентації. Робота з фото: Завантажені спеціалістом фото та скріншоти мають автоматично масштабуватися та вставлятися у відповідні блоки картки постачальника в PDF без деформації. Графіка: Кругова діаграма має автоматично генеруватися на основі внесених цифр. *Структура фінального PDF-файлу(орієнтовно 6+ сторінок) я надаю після того, як ми спілкуємось по можжливості виконання завдання. Який стек технологій ми розглядаємо? Ми відкриті до ваших пропозицій. Це може бути: Google Sheets + Google Apps Script + Google Docs/Slides (як шаблон). Google Sheets + інтегратори (Make.com / Zapier) + генератори документів (Portant, Documentero, Form Publisher, PDFMonkey тощо). Будь-яке інше надійне рішення, яке забезпечить стабільну роботу без складних дій з нашого боку. Що очікується від виконавця? Аналіз нашого поточного процесу та пропозиція оптимального технічного стеку. Розробка дизайну/шаблону PDF-звіту (або адаптація наших фірмових елементів). Налаштування зв'язку між Google Таблицею та шаблоном документа. Тестування системи (перевірка вставки фото, побудови діаграм, генерації багатосторінкових карток постачальників). Коротка інструкція або відеодемонстрація для нашої команди, як цим користуватися. Буде плюсом у вашому відгуку: Приклади схожих кейсів (автоматична генерація PDF-документів, комерційних пропозицій або звітів із Google Таблиць). Орієнтовний стек програм, який ви пропонуєте для цього завдання. Оцінка термінів та вартості реалізації.

Є діюча production-платформа з каталогом та автоматичним оновленням зовнішніх пропозицій і цін. Стек: — Node.js / TypeScript; — PostgreSQL; — існуючий сервіс оновлення цін і cron; — окремий готовий Python-модуль валідації та вибору пропозицій; — staging і production. Необхідно точково доопрацювати існуючий pipeline оновлення цін без повного переписування backend. ОБОВ'ЯЗКОВИЙ СКОП 1. Інтеграція Python-модуля — Python-модуль залишається окремим компонентом; — повертає структурований результат: offers, selected offer, statuses та risk flags; — Node.js валідує результат і виконує запис у БД; — передбачити обробку помилок і partial/failed runs; — legacy pipeline не відключається до завершення QA. 2. Запуск оновлення за списком Додати запуск: — по одному slug/id; — по переданому списку slug/id. Допустимо CLI або існуючий службовий API. Новий користувацький інтерфейс не потрібен. 3. Shadow Mode Нові результати повинні записуватися окремо і не впливати на production до QA. Потрібні shadow-поля: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Розширення існуючої таблиці offers Додати: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags або зберігання в існуючому JSON; — unique constraint для захисту від дублів. Нову паралельну систему пропозицій створювати не потрібно, якщо існуючу таблицю можна безпечно розширити. 5. UPSERT, STALE і транзакція БД Замінити поточну схему DELETE → CREATE: — UPSERT існуючих і нових пропозицій; — відсутні в повному успішному snapshot пропозиції переводяться в STALE; — при API error, partial result або незавершеному snapshot активні пропозиції не повинні ставати STALE; — оновлення пропозицій, metadata вибраної пропозиції та shadow fields по одній моделі виконується всередині однієї транзакції БД; — при помилці виконується повний rollback. 6. Canonical-safe refresh Оновлення цін не повинно змінювати: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Оновлюються тільки offer, price і shadow data. 7. Збереження поточної cron-логіки Зберегти: — existing cron; — rolling batches; — cooldown; — перевірку PRICE_REFRESH_MIN_DAYS до виклику зовнішнього API; — legacy production pipeline до завершення Shadow QA. 8. Audit output Достатньо одного варіанту: — shadow-колонки в існуючій admin table; або — CSV export. Мінімальні дані: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. Новий складний dashboard не потрібен. 9. Staging і QA — DB migrations; — staging deployment; — smoke test на 5 переданих моделях; — потім Shadow Mode приблизно на 50 моделях; — виправлення технічних помилок, виявлених під час цих прогонів; — коротка документація контракту Python → Node.js та rollback procedure. ОПЦІОНАЛЬНО ОЦІНИТИ ОКРЕМО Простий технічний promotion без нового UI: — promotion однієї моделі по slug; — promotion списку slug; — перенесення підтверджених shadow values в production; — технічна перевірка після rollout. РЕЗУЛЬТАТ — Pull Request; — DB migrations; — робоча інтеграція Python → Node.js; — Shadow Mode; — UPSERT, STALE і транзакційне оновлення; — запуск по slug/id; — staging deployment; — smoke-test results; — коротка документація; — не менше 7 днів виправлення багів по реалізованому scope після приймання. В ОТКЛИКУ УКАЗАТИ 1. Фіксована ціна за обов'язковий scope. 2. Окрему вартість механізму promotion. 3. Термін. 4. Оцінку годин. 5. Коли готові почати. 6. Досвід з PostgreSQL transactions, migrations та ingestion pipelines. 7. Які питання потрібно уточнити до початку. 8. Включені чи staging, QA, migrations та період виправлення помилок. Шаблонні відповіді без конкретної оцінки розглядатися не будуть. Доступ до production на першому етапі не надається. Робота починається з обмеженого code review та staging.

Потрібно розробити централізовану серверну систему збору та зберігання даних із Planfix, 1С, Meta Ads і Google Ads, а також веб-дашборд для їх відображення та аналізу. Усі дані, історія змін, розрахунки та агреговані показники повинні зберігатися виключно в серверній базі даних. Дашборд не повинен зберігати або дублювати бізнес-дані. Він має отримувати необхідну інформацію із серверної бази через API відповідно до запитів користувача та відображати її у вигляді KPI, графіків, таблиць і деталізованих звітів.

Щукаємо для підтримки проекта на базі Yii , треба вносити правки та доопрацювання бази , частково є звязок з попереднім виконавцем .....................

Потрібно зробити міграцію бази з CRM G-PLUS на MyChatBot Обєм бази - 26 тис. лідів 2 воронки - Кол центр та Відділ продажу зі своїми вирвами Картки лідів (крім імені та номеру) мають багато різних полів Ліди також мають голосові записи дзвінків. Їх також потрібно перенести Від кандидата очікую орієнтовну суму та терміни реалізації