Konfiguracja wymiany API STRONY i API ERP BIMP

# Що є - **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-адреса + логін/пароль, АБО формат обробки-вивантаження). - Назви обʼєктів у конфігурації: як зветься довідник клієнтів, де зберігається штрих-код, де абонемент і залишок тренувань (щоб я зіставив із додатком).

Potrzebna jest oddzielna system CRM do centralnego przetwarzania wszystkich zamówień detalicznych z różnych kanałów sprzedaży (Prom, Rozetka, własne strony oraz zamówienia ręczne). Główne wymagania: Jednolity rejestr zamówień ze wszystkich źródeł z zachowaniem informacji o źródle i jego statusie. Oddzielny wewnętrzny status CRM, który działa niezależnie od statusu na marketplace lub stronie, z dwustronną synchronizacją statusów tam, gdzie jest to wspierane. Elastyczna integracja z 1C: dla każdego źródła administrator może osobno włączyć lub wyłączyć automatyczne wyładowanie zamówień. Integracja z przewoźnikami w celu automatycznego tworzenia TTN, zachowania jej numeru w CRM oraz przekazywania numeru TTN na Prom i Rozetka. Integracja z Checkbox w celu tworzenia projektów paragonów, wykorzystując konfigurowalne dopasowanie metod płatności, z dalszą kontrolą fiskalizacji. Wsparcie dla ręcznego tworzenia zamówień (telefon, Viber, Telegram, Direct itp.) z pełnym dalszym cyklem przetwarzania przez CRM. Wszystkie klucze API i ustawienia integracji powinny być zarządzane przez administratora przez interfejs CRM bez udziału programisty. Pełny dziennik działań i logowanie integracji w celu kontroli pracy systemu. Główny cel Menadżer powinien mieć możliwość całkowitego przetworzenia zamówienia w jednym interfejsie CRM — od otrzymania zamówienia po stworzenie dokumentu w 1C, TTN, projektu paragonu i zakończenie zamówienia, bez konieczności wchodzenia do paneli Prom, Rozetka, stron, przewoźników lub Checkbox.

Mamy synchronizację dwóch źródeł danych z CRM. System ogólnie jest stabilny. Jednak pozostaje część, która jest niesynchronizowana. Główna hipoteza — w jednym ze źródeł dane zmieniają się już po pierwotnej synchronizacji, a te zmiany nie zawsze są pobierane do CRM. + dane w dwóch źródłach mają różne nazwy/identyfikatory, chociaż reprezentują te same byty.

Zadanie: wdrożenie usługi LLM, która zna całą dokumentację firmy i odpowiada na pytania menedżerów działu sprzedaży. Co jest teraz: klient samodzielnie stworzył prototyp (oddzielny projekt z załadowanymi informacjami o firmie, umieszczony na serwerze), ale informacje z bazy nie są przekazywane do modelu — prawdopodobnie problem z API. Kod i dostęp udostępnimy. Pierwszy krok — audyt: naprawić istniejące lub uzasadnione zbudować od nowa. Wymagana funkcjonalność: Załadowanie całej dokumentacji firmy: opis każdej usługi, regulaminy, FAQ, cenniki (wszystkie materiały udostępnimy). Odpowiedzi ściśle na podstawie załadowanych dokumentów (RAG). Model nie wymyśla faktów; jeśli odpowiedzi w bazie nie ma — uczciwie o tym informuje. Dostęp dla menedżerów poprzez link (interfejs webowy), z autoryzacją. Scenariusze: menedżer zadaje dowolne pytanie dotyczące pracy firmy; wstawia pytanie klienta „jak jest” i otrzymuje gotową odpowiedź do wysłania; znajduje potrzebny regulamin/raport na żądanie. Aktualizacja bazy wiedzy bez programisty (ładowanie plików przez interfejs lub podłączony folder). Język angielski. Historia zapytania do kontroli jakości. Oczekiwania techniczne: LLM przez API (Claude/OpenAI — proszę zaproponować z wyliczeniem kosztów tokenów), pipeline RAG (baza wektorowa, embeddings), hosting na naszym serwerze lub w chmurze, HTTPS. Architektura ma pozwalać w przyszłości na podłączenie asystenta do analitycznego magazynu danych (równoległy projekt). W odpowiedzi proszę podać: przykłady podobnych projektów RAG, stack, czas, koszt pracy oraz orientacyjną miesięczną koszt posiadania (tokeny + hosting).

Cześć Jest mały oddział, do którego przyjmowani są pacjenci. Należy opracować prostą "bazę danych", w której będzie można wprowadzać materiały eksploatacyjne, leki i inne, przychody i wydatki, a także przypisywać użycie do konkretnego pacjenta. Funkcjonalność, która jest potrzebna Podręczniki Leki Materiały eksploatacyjne (możliwość wprowadzania ręcznego) Pacjenci (możliwość wprowadzania nowych i usuwania tych, którzy zostali wypisani) Pracownicy (możliwość edytowania)Obliczanie ruchu Jedna tabela (dziennik ruchu), w której rejestrowane jest wszystko Przychód i wydanie Możliwość ręcznej korekty Przy wydaniu pielęgniarka musi wybrać: datę; pacjenta; lek lub materiał; ilość; swoje imię i nazwisko. System automatycznie zmniejsza stan. Przy przyjęciu starsza pielęgniarka musi mieć możliwość wprowadzenia: Daty dostawy; Leku/materiału; Ilości pozostałej; Skąd przyszło; Terminu ważnościFunkcjonalność automatyczna automatyczne obliczanie stanów; kontrola minimalnego zapasu; kontrola terminów ważności; ostrzeżenia o niskich stanach; ochrona przed wydawaniem większej ilości, niż jest dostępna; listy rozwijane; weryfikacja poprawności wprowadzonych danych; formatowanie warunkowe.Raporty Należy zrealizować automatyczne raporty: aktualne stany; użycie w okresie; użycie według pacjenta; użycie według pracownika; historia ruchu konkretnego leku.Preferowane realizacja w Google Sheets; Bazy będziemy uzupełniać samodzielnie. Potrzebny jest szablon do pracy. Nie wiem, ile to kosztuje, więc zaczniemy od 50$, a wy proponujcie swoje opcje i dobrze, żebyście mieli doświadczenie.