Інтеграція між Planfix і Google Sheets

Сайт розроблений на: Backend: Java + Spring Boot База даних: MySQL Frontend: JavaScript, HTML, CSS Шаблонізатор: Thymeleaf Сервер: VPS (Linux Ubuntu) Reverse Proxy: Apache2 Архітектура: Монолітний додаток На даний момент на сайті реалізовано: Блог з адміністративною панеллю. Можливість створювати та редагувати статті через адмін-панель. Можливість додавати HTML-розмітку та контент через візуальний інтерфейс. Статичні сторінки сайту, які зараз створюються розробником вручну. ⸻ Мета завдання Необхідно реалізувати можливість створювати та управляти новими комерційними сторінками послуг через існуючу адміністративну панель аналогічно тому, як зараз створюються статті блогу. Після реалізації адміністратор повинен мати можливість самостійно створювати нові SEO-сторінки послуг без участі розробника. ⸻ Поточний стан Зараз через адмін-панель можна створювати тільки записи блогу. Приклад: Стаття 1 Стаття 2 Стаття 3 Кожна стаття має: Заголовок URL (slug) Контент SEO-параметри Зображення ⸻ Що необхідно реалізувати 1. Новий тип контенту «Послуги» Створити в адмін-панелі окремий розділ: «Послуги» Він повинен бути незалежним від розділу блогу. Приклад структури: Блог Послуги ⸻ 1. Створення сторінки послуги Адміністратор повинен мати можливість створити нову сторінку послуги через інтерфейс. Комерційні сторінки послуг складаються з 13 блоків, з яких 4 блоки динамічні та 9 статичних. Поля: Назва послуги URL (slug) H1 SEO Title Meta Description SEO Keywords Основний контент сторінки Зображення Статус публікації (Чернетка / Опубліковано) ⸻ 1. Контент сторінки Контент повинен підтримувати: HTML-розмітку Форматування тексту Заголовки H2-H6 Списки Зображення Посилання Бажано використовувати існуючий редактор, який вже застосовується в блозі. ⸻ 1. Генерація URL Кожна послуга повинна мати власний URL. Приклади: /visa/usa/business-visa-usa /visa/usa/business-visa-uk /visa/usa/business-visa-canada ⸻ 1. Відображення на сайті Після публікації сторінка повинна: автоматично ставати доступною за своїм URL; використовувати існуючий шаблон сторінок послуг або новий шаблон; коректно відображатися на всіх пристроях. ⸻ 1. SEO Для кожної послуги необхідно забезпечити можливість налаштування: Title Description H1 Canonical URL (бажано) Open Graph (бажано) Сторінки повинні індексуватися пошуковими системами аналогічно сторінкам блогу. ⸻ 1. Список послуг В адмін-панелі реалізувати: список всіх послуг; пошук; редагування; видалення; зміна статусу публікації. ⸻ 1. Важно Реалізувати можливість створювати нові типи SEO-сторінок без доопрацювання коду в майбутньому. через єдиний механізм управління контентом. ⸻ Що очікується від розробника Необхідно проаналізувати існуючу реалізацію блогу та максимально переиспользувати поточну архітектуру для створення нового розділу «Послуги». При відповіді прошу вказати: Яким чином буде реалізовано завдання. Які зміни знадобляться в БД. Оцінку по часу. Вартість робіт. Які технології повинен знати виконавець Обов'язково: Java Spring Boot MySQL Thymeleaf HTML/CSS JavaScript Робота з Linux Ubuntu Бажано: Spring Security SEO-оптимізація серверних сторінок Досвід роботи з CMS та CRUD-модулями Досвід підтримки монолітних Spring Boot проектів

Потрібно розробити окрему CRM-систему для централізованої обробки всіх роздрібних замовлень з різних каналів продажу (Prom, Rozetka, власні сайти та ручні замовлення). Основні вимоги: Єдиний реєстр замовлень з усіх джерел із збереженням інформації про джерело та його статус. Окремий внутрішній статус CRM, який працює незалежно від статусу на маркетплейсі чи сайті, із двосторонньою синхронізацією статусів там, де це підтримується. Гнучка інтеграція з 1С: для кожного джерела адміністратор може окремо ввімкнути або вимкнути автоматичне вивантаження замовлень. Інтеграція з перевізниками для автоматичного створення ТТН, збереження її номера в CRM та передавання номера ТТН на Prom і Rozetka. Інтеграція з Checkbox для створення проєктів чеків, використовуючи налаштовувану відповідність способів оплати, з подальшим контролем фіскалізації. Підтримка ручного створення замовлень (телефон, Viber, Telegram, Direct тощо) з повним подальшим циклом обробки через CRM. Усі API-ключі та налаштування інтеграцій повинні керуватися адміністратором через інтерфейс CRM без участі програміста. Повний журнал дій і логування інтеграцій для контролю роботи системи. Основна мета Менеджер повинен мати можливість повністю обробити замовлення в одному інтерфейсі CRM — від отримання замовлення до створення документа в 1С, ТТН, проєкту чека та завершення замовлення, без необхідності заходити в кабінети Prom, Rozetka, сайтів, перевізників або Checkbox.

У нас працює синхронізація двох джерел даних із CRM. Система в цілому стабільна. Але залишається частина, які розсинхронізуються. Основна гіпотеза — в одному з джерел дані змінюються вже після первинної синхронізації, і ці зміни не завжди підтягуються в CRM. + данні в двох джерелах мають різні назви/ідентифікатори хоча являють собою одні і тіж сутності

Завдання:розгорнути LLM-сервіс,який знає всю документацію компанії тавідповідає на запитання менеджеріввідділу продажів. Що є зараз:замовник збирав прототип самостійно(окремий проєкт із завантаженоюінформацією про компанію,розміщений на сервері), алеінформація з бази непередається в модель —імовірно, проблема з API. Коді доступи надамо. Першийкрок — аудит: полагодитинаявне абоаргументовано перезібрати з нуля. Необхідний функціонал: Завантаження всієї документаціїкомпанії: опис кожноїпослуги, регламенти, FAQ,ціноутворення (усі матеріалинадамо). Відповіді строго набазі завантаженихдокументів (RAG). Модель невигадує фактів; якщовідповіді в базі немає — чеснопро це повідомляє. Доступ для менеджерівза посиланням(веб-інтерфейс), завторизацією. Сценарії: менеджерставить будь-якезапитання про роботукомпанії; вставляєзапитання клієнта «як є» йотримує готову відповідьдля відправлення;знаходить потрібнийрегламент/звіт за запитом. Оновлення бази знань безрозробника (завантаженняфайлів через інтерфейсабо підключенупапку). Англійська мова. Історіязапитів для контролюякості. Технічні очікування:LLM через API(Claude/OpenAI —запропонувати з розрахунком вартостітокенів), RAG-пайплайн (векторнабаза, embeddings), хостинг нанашому сервері або в хмарі, HTTPS.Архітектура має дозволяти вмайбутньому підключити асистента доаналітичного сховища даних(паралельний проєкт). У відгуку вказати:прикладисхожих RAG-проєктів,стек, строк, вартість роботи таорієнтовну щомісячнувартість володіння (токени +хостинг).

Привіт Є невелике відділення, куди поступають пацієнти. Потрібно розробити просту "базу даних", в якій можна буде вносити розхідні матеріали, перпарати та інше, прихід вихід, а також списувати використання на конкретного пацієнта. Функціонал який необхідний Довідники Медикаменти Витратні матеріали(можливість вносити вручну) Пацієнти(можливість вносити постійно нових і видаляти тих хто виписаний) Працівники(можливість змінювати)Облік руху Єдина таблиця (журнал руху), в якій реєструються все Прихід та списання Можливість корекції в ручну При списанні медична сестра повинна вибрати: дату; пацієнта; препарат або матеріал; кількість; своє ПІБ. Система автоматично зменшує залишок. При приході старша медична сестра повинна мати можливість внести: Дата поставки; Препарат/матеріал; Залишкова кількість; Звідки прийшло; Термін придатностіАвтоматичний функціонал автоматичний розрахунок залишків; контроль мінімального запасу; контроль термінів придатності; попередження про низькі залишки; захист від списання більшої кількості, ніж є в наявності; випадаючі списки; перевірка правильності введення даних; умовне форматування.Звіти Потрібно реалізувати автоматичні звіти: поточні залишки; використання за період; використання по пацієнту; використання по працівнику; історія руху конкретного препарату.Бажано реалізація на Google Sheets; Заповнювати бази будемо самостійно. Потрібен шаблон для роботи. Скільки це коштує не знаю, тому почнемо зі 50$, а ви пропонуйте свої варіанти і бажано щоб був досвід.