Разработка браузерной игры с использованием блокчейна, запросов, и БД

# Что есть - **1С:Предприятие 8.3.17.1549**, конфигурация **«Фитнес клуб» вер. 3.6** (типовая). - **Файловая база**, каталог `D:\1c\ФК`. **Толстый клиент**, обычный интерфейс. - ОС **Windows 7**, компьютер в клубе, работает постоянно. Лицензия HASP (локальная флешка). - Доступ предоставлю через **AnyDesk / TeamViewer**. ## Проблема, которую нужно решить В этом интерфейсе (толстый клиент) **нет пункта меню для настройки состава OData** — через кнопки не включается. Нужно сделать кодом / обработкой. ## Задача (выбрать то, что проще — ~1-2 часа) ### Вариант А — OData 1. Установить веб-сервер (Apache 2.4 / IIS) на этом ПК. 2. Опубликовать файловую базу с **включенным стандартным интерфейсом OData**. 3. **Задать состав OData кодом** (`УстановитьСоставСтандартногоИнтерфейсаOData`) — открыть на чтение: клиентов, абонементы, штрих-коды/карты, посещения, остатки. 4. Создать пользователя `integration` (логин+пароль, права на чтение). 5. Проверить: `http://localhost//odata/standard.odata/` возвращает данные. ### Вариант Б — Простая обработка-выгрузка (может быть легче для этой конфигурации) 1. Написать внешнюю обработку (.epf), которая выгружает: - клиентов (ФИО, телефон, **штрих-код карты**), - активные абонементы (тип, остаток тренировок, дата окончания), - (по возможности) посещения. 2. Формат: **JSON**, и отправлять POST на наш вебхук (адрес дам) — ИЛИ сохранять в файл, который синхронизируется в облако. 3. Поставить на **расписание** (регламентное задание / Планировщик Windows) — раз в 15-30 мин. ## Важно - **Ничего в конфигурации не менять/не переписывать.** Только выгрузка данных наружу. - **Не выставлять базу в интернет** (Win7 старый). Достаточно локально — отправку в облако сделает наша сторона. - Ключевое поле для связи клиента — **штрих-код карты** (например, 2100000016853). ## Что передать после работы - Как сделали (OData-адрес + логин/пароль, ИЛИ формат обработки-выгрузки). - Названия объектов в конфигурации: как называется справочник клиентов, где хранится штрих-код, где абонемент и остаток тренировок (чтобы я сопоставил с приложением).

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