Potrzebna baza email przedsiębiorców

Шукаємо спеціаліста з автоматизації (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 Таблиць). Орієнтовний стек програм, який ви пропонуєте для цього завдання. Оцінка термінів та вартості реалізації.

Istnieje działająca platforma produkcyjna z katalogiem i automatycznym aktualizowaniem zewnętrznych ofert i cen. Stos technologiczny: — Node.js / TypeScript; — PostgreSQL; — istniejąca usługa odświeżania cen i cron; — oddzielny gotowy moduł walidacji i wyboru ofert w Pythonie; — staging i produkcja. Konieczne jest punktowe dopracowanie istniejącego pipeline'u odświeżania cen bez pełnego przepisywania backendu. OBOWIĄZKOWY ZAKRES 1. Integracja modułu Python — Moduł Python pozostaje oddzielnym komponentem; — zwraca zorganizowany wynik: oferty, wybrana oferta, statusy i flagi ryzyka; — Node.js waliduje wynik i wykonuje zapis w bazie danych; — przewidzieć obsługę błędów i częściowych/nieudanych uruchomień; — pipeline dziedziczony nie jest wyłączany do zakończenia QA. 2. Uruchomienie odświeżania według listy Dodaj uruchomienie: — po jednym slug/id; — po przekazanej liście slug/id. Możliwe CLI lub istniejące API serwisowe. Nowy interfejs użytkownika nie jest wymagany. 3. Tryb Shadow Nowe wyniki powinny być zapisywane oddzielnie i nie wpływać na produkcję do QA. Wymagane pola shadow: — cena; — ID wybranej oferty; — bezpośredni URL; — status oferty; — flagi ryzyka/QA; — checkedAt; — engineVersion. 4. Rozszerzenie istniejącej tabeli ofert Dodaj: — źródło; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — flagi ryzyka lub przechowywanie w istniejącym JSON; — unikalne ograniczenie dla ochrony przed duplikatami. Nie jest wymagane tworzenie nowego równoległego systemu ofert, jeśli istniejącą tabelę można bezpiecznie rozszerzyć. 5. UPSERT, STALE i transakcja DB Zamień obecną schemę DELETE → CREATE: — UPSERT istniejących i nowych ofert; — oferty, które nie występują w pełnym udanym snapshot, są przekazywane do STALE; — w przypadku błędu API, częściowego wyniku lub niedokończonego snapshot aktywne oferty nie powinny stawać się STALE; — aktualizacja ofert, metadanych wybranej oferty i pól shadow według jednego modelu odbywa się w ramach jednej transakcji DB; — w przypadku błędu wykonywany jest pełny rollback. 6. Bezpieczne odświeżanie kanoniczne Odświeżanie cen nie powinno zmieniać: — marki; — referencji; — modelu; — kolekcji; — nazwy/tytułu; — slug; — opisów; — obrazów; — pól SEO. Aktualizowane są tylko oferta, cena i dane shadow. 7. Zachowanie obecnej logiki cron Zachować: — istniejący cron; — rolling batches; — cooldown; — sprawdzenie PRICE_REFRESH_MIN_DAYS przed wywołaniem zewnętrznego API; — dziedziczony pipeline produkcyjny do zakończenia Shadow QA. 8. Audyt wyników Wystarczy jedna opcja: — kolumna shadow w istniejącej tabeli administracyjnej; lub — eksport CSV. Minimalne dane: — model/referencja; — cena produkcyjna; — cena shadow; — delta; — URL produkcyjny/shadow; — status; — flagi ryzyka; — checkedAt; — engineVersion. Nowy skomplikowany dashboard nie jest wymagany. 9. Staging i QA — migracje DB; — wdrożenie staging; — test dymny na 5 przekazanych modelach; — następnie Tryb Shadow na około 50 modelach; — naprawa błędów technicznych wykrytych podczas tych uruchomień; — krótka dokumentacja kontraktu Python → Node.js i procedura rollback. OPCJONALNIE OCENIĆ ODDZIELNIE Prosta promocja techniczna bez nowego UI: — promocja jednego modelu po slug; — promocja listy slug; — przeniesienie potwierdzonych wartości shadow do produkcji; — techniczna weryfikacja po rollout. WYNIK — Pull Request; — migracje DB; — działająca integracja Python → Node.js; — Tryb Shadow; — UPSERT, STALE i transakcyjne aktualizacje; — uruchomienie po slug/id; — wdrożenie staging; — wyniki testu dymnego; — krótka dokumentacja; — nie mniej niż 7 dni na poprawki błędów w zrealizowanym zakresie po akceptacji. W ODPOWIEDZI WSKAZAĆ 1. Stała cena za obowiązkowy zakres. 2. Oddzielny koszt mechanizmu promocji. 3. Termin. 4. Ocena godzin. 5. Kiedy gotowi do rozpoczęcia. 6. Doświadczenie z transakcjami PostgreSQL, migracjami i pipeline'ami wczytywania. 7. Jakie pytania należy wyjaśnić przed rozpoczęciem. 8. Czy wliczone są staging, QA, migracje i okres naprawy błędów. Szablonowe odpowiedzi bez konkretnej oceny nie będą rozpatrywane. Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca zaczyna się od ograniczonego przeglądu kodu i stagingu.

TZ: Przywrócenie strony z kopii zapasowejRodzaj pracy: rollback/przywrócenie strony, usunięcie błędów po nieudanej aktualizacjiPlatforma: strona działa na dwóch systemach, OpenCart i WordPress (dwie oddzielne administracje) Hosting: ukraine.com.uaOpis problemu17.07.2026 aktualizowano moduł filtrów. Aktualizacja okazała się nieudana, i stronę trzeba było przywrócić do poprzedniej wersji. Jednak podczas przywracania strona częściowo się zepsuła:nie działa część stron;nie działają niektóre przyciski;część ważnej funkcjonalności przestała działać.ZadanieCałkowicie przywrócić stronę z kopii zapasowej z 16.07.2026 do w pełni działającego stanu. Przywrócenie ma obejmować oba systemy (OpenCart i WordPress):pliki strony;bazy danych;ustawienia hostingu;wszystkie elementy interfejsu i funkcjonalność.Wynik: strona działa bez zakłóceń, wszystkie strony, przyciski i funkcje są poprawne na obu platformach.Wymagania wobec wykonawcyPrzed rozpoczęciem prac zrobić kopię zapasową aktualnego (zepsutego) stanu strony.Uwzględnić powiązania między OpenCart a WordPress (wspólna baza, integracja, synchronizacja danych itp.), sprawdzić, aby po przywróceniu oba systemy działały zgodnie.Po przywróceniu przeprowadzić kontrolę kluczowych stron i funkcji na obu platformach.Odbiór pracyPo wykonaniu zadania przewiduje się minimum 4 dni na sprawdzenie działania strony przez zamawiającego. Ostateczny odbiór po potwierdzeniu stabilnej pracy.

Potrzebna jest centralna serwerowa system zbierania i przechowywania danych z Planfix, 1C, Meta Ads i Google Ads, a także webowy dashboard do ich wyświetlania i analizy. Wszystkie dane, historia zmian, obliczenia i agregowane wskaźniki muszą być przechowywane wyłącznie w serwerowej bazie danych. Dashboard nie powinien przechowywać ani duplikować danych biznesowych. Ma on uzyskiwać niezbędne informacje z serwerowej bazy przez API zgodnie z zapytaniami użytkownika i wyświetlać je w postaci KPI, wykresów, tabel i szczegółowych raportów.

Szukamy wsparcia dla projektu opartego na Yii , trzeba wprowadzać poprawki i dopracowania bazy, częściowo jest kontakt z poprzednim wykonawcą .....................