Триггеры в базе MySQL

Необходимо разработать отдельную 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$, а вы предлагайте свои варианты и желательно, чтобы был опыт.

Необходимо рассчитать статистику в медицинском проекте (включая корреляции). Также есть запрос на создание математической модели прогнозирования развития патологий на основе имеющихся данных.