Jak AI może pilnować stanów i dokumentów w Subiekcie GT i nexo, gdy masz dwa magazyny i sklep?

Tak: AI można podłączyć do Subiekta GT przez Sferę i do Subiekta nexo PRO przez wbudowane REST API, a następnie wyciągnąć z niego stany per magazyn, rezerwacje, historię dokumentów PZ, WZ, MM i RW oraz ceny zakupu. Z tych danych AI robi rzeczy praktyczne: przygotowuje listę braków pod zamówienia u dostawcy, wyłapuje towary bez ruchu od pół roku, pomaga wyjaśnić różnice inwentaryzacyjne i odpowiada handlowcowi, ile towaru jest wolnego. Stany w Subiekcie i na stronie sklepu przestają się rozjeżdżać, bo AI synchronizuje stan dyspozycyjny, czyli stan fizyczny minus rezerwacje, po każdym wystawionym ZO lub WZ, a nie raz na dobę o drugiej w nocy.

Jak AI łączy się z Subiektem: Sfera GT, nexo REST API i bezpośredni dostęp do bazy

To pierwsze pytanie, które zawsze pada przy rozmowie o integracji. Subiekt nexo PRO ma wbudowane REST API dostępne przez HTTP. Generujecie klucz API w panelu administracyjnym nexo i od tej chwili można odpytywać towary, stany, dokumenty, kontrahentów, zamówienia i cenniki. Klucz z prawami wyłącznie do odczytu wystarczy do analizy i odpowiedzi handlowca na pytania o dostępność. Do wystawiania dokumentów potrzeba uprawnień zapisu, ale te scenariusze omawiamy osobno, bo wymagają zatwierdzenia przez człowieka.

Subiekt GT to inna sprawa. Nie ma REST API. Interfejs do automatyzacji nazywa się Sfera GT i działa jako serwer automatyzacji COM na Windows. Musi być zainstalowany na tym samym komputerze lub dostępny sieciowo od strony serwera Windows, gdzie stoi Subiekt. Skrypty piszemy w C#, Pythonie z biblioteką pywin32 albo w VBScript. Przez Sferę mamy dostęp do: stanów magazynowych per magazyn, kart towarów z cenami zakupu i sprzedaży, dokumentów PZ, WZ, MM, RW i ZI z pozycjami i datami, rezerwacji, zamówień od odbiorców (ZO) i do dostawców (ZD), a także kartoteki kontrahentów.

Trzecia droga to bezpośredni dostęp do bazy SQL. GT pracuje na Firebirdzie albo SQL Serverze, nexo zawsze na SQL Serverze. INSERT oficjalnie dopuszcza odczyt bazy przez własne zapytania, choć odradza bezpośrednie modyfikacje poza Sferą. W praktyce u klientów z GT na starszej infrastrukturze, gdzie uruchomienie Sfery sprawiało problem, podłączamy się do bazy SQL bezpośrednio i wyciągamy dane widokami. Mamy wtedy dostęp do tych samych tabel: tw__Towar, dok__Dokument, dok__PozycjaDokumentu, stany w tw__StanMagazynowy.

Ważna sprawa do ustalenia na początku: Sfera GT wymaga środowiska Windows w pobliżu serwera z Subiektem. Jeśli Subiekt stoi na dedykowanym PC albo małym serwerze Windows w biurze, tam też uruchamiamy skrypt pośredniczący, który wystawia dane przez HTTP do naszej integracji. Nexo REST API jest dostępne z każdego miejsca w sieci lokalnej, co upraszcza całe wdrożenie.

Co konkretnie AI widzi w danych magazynowych Subiekta

Zanim AI cokolwiek obliczy, musi wiedzieć, co czyta. Typowy układ w hurtowni: magazyn główny, magazyn podręczny przy rampie załadunkowej i sklep stacjonarny jako trzeci magazyn. Do tego sklep internetowy, który synchronizuje stany przez Sello od InsERT albo własny konektor przez API nexo. Trzy miejsca, trzy niezależne stany w Subiekcie, jeden sklep, który widzi tylko część obrazu.

Z takiego układu wyciągamy:

• Stan na każdym magazynie osobno: ilość fizyczna per lokalizacja, nie zagregowana. Handlowiec musi wiedzieć, czy towar jest przy rampie, czy trzeba go najpierw przesunąć MM-ką z głównego. Suma "łącznie 15 sztuk" nic mu nie mówi, jeśli 14 z nich jest zablokowanych w innej lokalizacji.
• Rezerwacje otwarte: ilość zablokowana pod niezrealizowane ZO. Rezerwacja powstaje w Subiekcie przy wystawieniu zamówienia od odbiorcy, zanim pójdzie WZ. AI widzi stan dyspozycyjny, a nie tylko to, co fizycznie leży na półce.
• Dokumenty PZ z cenami zakupu: każde Przyjęcie Zewnętrzne niesie datę, dostawcę i ceny zakupu per pozycja. Z historii PZ wyliczamy średnią ważoną cenę zakupu i śledzimy jej zmiany między dostawami.
• Dokumenty WZ z datami i kontrahentami: Wydania Zewnętrzne to podstawa do liczenia rotacji. Ile sztuk towaru X wyszło w ostatnich 30, 60 i 90 dniach, do jakich klientów.
• Dokumenty MM: Przesunięcia Międzymagazynowe między magazynami. Bez ich śledzenia nie wiadomo, dlaczego stan w jednym miejscu spada bez WZ. MM to też częste źródło różnic inwentaryzacyjnych, gdy wystawiono je tylko po jednej stronie.
• RW: Rozchód Wewnętrzny: zużycie wewnętrzne, ubytki, próbki dla klientów. Handlowcy często o tym zapominają przy sprawdzaniu stanów, a pomijany RW powoduje, że program pokazuje co innego niż rzeczywistość.
• Grupy towarowe: przynależność towaru do grupy w kartotece. Potrzebna do zestawień marży per kategoria i do filtrowania rotacji dla kupca.

Dlaczego stany w Subiekcie i na stronie sklepu się rozjeżdżają i jak to naprawia AI

To bolączka niemal każdej hurtowni z własnym sklepem internetowym. Scenariusz, który widzieliśmy u jednego klienta: klient składa zamówienie przez sklep na 10 sztuk towaru. W Subiekcie stan wynosi 12. Sklep akceptuje zamówienie, bo widzi 12. Ale 8 z tych 12 jest już zarezerwowanych pod ZO wystawione rano przez handlowca, a sklep tego nie wie, bo synchronizacja szła raz na dobę o drugiej w nocy. Dwie godziny później ktoś musi dzwonić do klienta i tłumaczyć, że towaru jednak nie ma.

Przyczyna jest prosta: synchronizacja przez Sello albo własny konektor zazwyczaj eksportuje stan fizyczny, a nie stan dyspozycyjny. Różnica to właśnie rezerwacje. AI podłączone do Subiekta może obliczać stan dyspozycyjny per towar i przesyłać go do sklepu nie raz na dobę, ale po każdym wystawionym ZO albo WZ. Wyzwalacz jest zdarzeniowy, a nie harmonogramowy.

Widzieliśmy też sytuację odwrotną: na stronie stan był 0, więc klienci nie mogli złożyć zamówienia, a w magazynie leżały 40 sztuk. Ktoś wystawił MM z magazynu pomocniczego do głównego po godzinie, gdy ostatnia synchronizacja już minęła. AI, widząc wszystkie trzy magazyny, agreguje prawidłowy stan i aktualizuje sklep już przy następnym sprawdzeniu, zamiast czekać do rana.

Poza synchronizacją AI może odpowiadać handlowcowi bezpośrednio w czacie albo przez wiadomość w programie: "Towar X: stan fizyczny 15, zarezerwowane 7 pod ZO/00234 (klient Nowak Sp. z o.o.), wolne 8, wszystko na magazynie głównym, na podręcznym 0." To zdanie, które normalnie handlowiec musi sam wklikać w kilka ekranów Subiekta.

Lista zamówieniowa u dostawcy: jak AI robi ją z rotacji i rezerwacji

Zamiast kupca, który raz w tygodniu siada z Excelem i patrzy na stany, AI robi to co noc i rano wynik jest gotowy. To jeden z najczęściej wdrażanych scenariuszy w hurtowniach używających Subiekta.

AI zestawia kilka źródeł danych jednocześnie:

• Stan dyspozycyjny per towar z każdego magazynu
• Rotacja z ostatnich 90 dni: średnia dzienna sprzedaż wyliczona z dokumentów WZ
• Otwarte rezerwacje z ZO, które czekają na towar
• Zamówienia do dostawców (ZD) w toku: ile już zamówiono i kiedy spodziewać się dostawy, żeby nie zamawiać dwa razy

Z tych danych AI oblicza, ile towaru starczy na ile dni przy bieżącej rotacji i które pozycje się kończą. Do listy dorzuca towary, pod które są aktywne ZO, ale nie ma czym pokryć: zamówienie od klienta jest, towar nie. To priorytet dla kupca.

Wynik: plik z kolumnami: indeks towaru, nazwa, stan dyspozycyjny, średnie dzienne wydanie, prognozowany brak za X dni, ilość do zamówienia, ostatni dostawca z PZ, ostatnia cena zakupu. Kupiec weryfikuje, koryguje wolumeny i zatwierdza. Nie zaczyna od zera.

Przy okazji AI wyłapuje towary, które formalnie są "na stanie", ale ich stan nigdy nie spada: rotacja zerowa od 180 dni. To osobna lista zalegaków, która trafia do kupca i handlowców. Typowo wygląda to tak, że kilkadziesiąt pozycji leży bez ruchu od pół roku, bo były złe decyzje zakupowe albo produkt wycofał się z oferty, a nikt nie widział tego w jednym zestawieniu.

Różnice inwentaryzacyjne: AI pomaga zrozumieć, skąd się wzięły

Inwentaryzacja w Subiekcie to Arkusz Spisu z Natury, skrótowo ASN. Po wpisaniu liczonych ilości Subiekt wylicza różnice: nadwyżki i niedobory per towar. Wynik idzie do dokumentu ZI (Zatwierdzenie Inwentaryzacji), który koryguje stany. Sam proces liczenia i wpisywania zależy od ludzi ze skanerami. AI tu nie zastępuje, bo liczyć muszą pracownicy.

AI wchodzi po: gdy masz arkusz z różnicami i pytanie "dlaczego towar X ma niedobór 5 sztuk?" Bez narzędzia ktoś musi ręcznie przeglądać historię dokumentów dla tego towaru: czy był RW bez uzasadnienia, czy MM poszło tylko w jedną stronę, czy towar wydano klientowi bez WZ, czy to pomyłka przy liczeniu partii z różnymi datami ważności.

AI, mając historię PZ, WZ, MM i RW dla danego towaru z całego roku, przegląda ją i wskazuje anomalie. Niedobór 5 sztuk przy towarze, który w tym samym czasie miał MM z magazynu głównego na podręczny, a na podręcznym nie ma potwierdzenia odbioru w ASN: AI mówi "sprawdźcie MM/00456 z 15 marca, towar wyszedł z głównego, ale nie trafił do liczenia na podręcznym." Zawęża pole poszukiwań z całego magazynu do dwóch konkretnych dokumentów.

Widzieliśmy też sytuację, gdzie różnice przy jednym towarze brały się z RW wystawianych okazjonalnie przez tego samego pracownika, zawsze w piątki, zawsze ta sama pozycja. AI wyłapało wzorzec z historii dokumentów i wynik trafił do właściciela do weryfikacji.

Marże per grupa towarowa i ceny zakupu: co AI zestawia z PZ i WZ

W Subiekcie towary należą do grup towarowych ustawionych w kartotece. Każde WZ ma cenę sprzedaży, każde PZ ma cenę zakupu. Z połączenia obu wyliczamy marżę na transakcji.

AI przygotowuje co miesiąc zestawienie: marża per grupa towarowa, obrót, średnia ważona marża w ostatnim kwartale i kierunek zmiany. Bez tego kupiec i handlowcy działają trochę w ciemno: widzą obrót w Subiekcie, ale nie widzą w jednym miejscu, gdzie firma zarabia, a gdzie sprzedaje po kosztach.

Ważny detal: Subiekt może wyceniać rozchód różnymi metodami, FIFO albo cena ostatniego zakupu, zależnie od ustawień firmy. AI bierze pod uwagę metodę wyceny przy liczeniu marży, bo inaczej wynik jest błędny przy towarach z dużymi wahaniami cen zakupu między partiami.

Poza marżą AI może zestawiać ceny zakupu z kolejnych PZ dla tego samego towaru i dostawcy. Jeśli ostatnie trzy dostawy od jednego dostawcy idą w górę, a cena sprzedaży stoi, marża się kurczy. Kupiec dostaje tę informację przed kolejną negocjacją, a nie po fakcie.

Od czego zaczynamy wdrożenie

Pierwsza rozmowa to inwentarz techniczny: GT czy nexo, jaka wersja programu, baza Firebird czy SQL Server, czy firma ma Sello i jak idzie synchronizacja ze sklepem, ile magazynów, czy ZO jest wystawiane regularnie, czy MM i RW są prowadzone konsekwentnie. Te ostatnie dwa pytania są ważne. Jeśli firma przez ostatnie pół roku pomijała RW i korygowała stany ręcznie, historyczne dane będą zaburzone. To nie blokuje wdrożenia, ale trzeba wiedzieć, od której daty dane są wiarygodne.

Dla nexo wdrożenie idzie szybciej: klucz API, konfiguracja, pierwsze przepływy danych można mieć działające w ciągu kilku dni. Dla GT potrzebujemy dostępu do serwera Windows z zainstalowaną Sferą albo bezpośredniego dostępu do bazy SQL.

Zazwyczaj zaczynamy od jednego scenariusza. Albo synchronizacja stanów ze sklepem, albo lista braków pod zamówienia, albo odpowiedzi handlowca na pytania o dostępność. Lepiej jedno dobrze niż sześć połowicznie. Efekty są widoczne po 60-90 dniach od wdrożenia, gdy AI ma wystarczającą historię dokumentów, żeby rotacja i prognozy miały sens. Jedno WZ to za mało. Trzy miesiące WZ to już dobra podstawa.

Jeśli prowadzicie hurtownię z Subiektem i zastanawiacie się, od czego konkretnie zacząć, zapraszamy na 15 minut rozmowy. Pokażemy, jak to wygląda na danych podobnych do Waszych. Możecie też zajrzeć na realne wdrożenia, żeby zobaczyć, jak podobne firmy uruchomiły integrację u siebie.