База данных

# Co jest - **1C:Przedsiębiorstwo 8.3.17.1549**, konfiguracja **„Klub fitness” wers. 3.6** (typowa). - **Baza plików**, katalog `D:\1c\FK`. **Gruby klient**, zwykły interfejs. - OS **Windows 7**, komputer w klubie, działa non-stop. Licencja HASP (lokalny pendrive). - Dostęp udostępnię przez **AnyDesk / TeamViewer**. ## Problem do rozwiązania W tym interfejsie (gruby klient) **brakuje pozycji menu do konfiguracji składu OData** — nie można włączyć przez przyciski. Należy to zrobić kodem / przetwarzaniem. ## Zadanie (wybrać to, co prostsze — ~1-2 godziny) ### Opcja A — OData 1. Zainstalować serwer WWW (Apache 2.4 / IIS) na tym PC. 2. Opublikować bazę plików z **włączonym standardowym interfejsem OData**. 3. **Ustawić skład OData kodem** (`UstawićSkładStandardowegoInterfejsuOData`) — otworzyć do odczytu: klientów, abonamenty, kody kreskowe/karty, wizyty, stany. 4. Utworzyć użytkownika `integration` (login+hasło, prawa do odczytu). 5. Sprawdzić: `http://localhost//odata/standard.odata/` zwraca dane. ### Opcja B — Proste przetwarzanie-wyładowanie (może być łatwiejsze dla tej konfiguracji) 1. Napisać zewnętrzne przetwarzanie (.epf), które wyładowuje: - klientów (imię i nazwisko, telefon, **kod kreskowy karty**), - aktywne abonamenty (typ, stan treningów, data zakończenia), - (jeśli to możliwe) wizyty. 2. Format: **JSON**, i wysyłać POST na nasz webhook (adres podam) — LUB zapisywać do pliku, który synchronizuje się w chmurze. 3. Ustawić na **harmonogram** (zadanie cykliczne / Harmonogram Windows) — raz na 15-30 min. ## Ważne - **Nic w konfiguracji nie zmieniać/nie przepisywać.** Tylko wyładowanie danych na zewnątrz. - **Nie wystawiać bazy w internecie** (Win7 stary). Wystarczy lokalnie — wysyłkę do chmury zrobi nasza strona. - Kluczowe pole do powiązania klienta — **kod kreskowy karty** (np. 2100000016853). ## Co przekazać po pracy - Jak zrobiono (adres OData + login/hasło, LUB format przetwarzania-wyładowania). - Nazwy obiektów w konfiguracji: jak nazywa się katalog klientów, gdzie przechowywany jest kod kreskowy, gdzie abonament i stan treningów (żebym mógł to porównać z aplikacją).

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.