Synchronizacja stanów magazynowych: cztery stany i jedno źródło prawdy

Synchronizacja stanów magazynowych rozjeżdża się prawie zawsze z jednego powodu: dwa systemy jednocześnie uznają się za właściciela informacji o tym, ile sztuk jest dostępnych. Sklep zdejmuje sztukę w chwili złożenia zamówienia, ERP dopiero przy wydaniu towaru z magazynu, a serwis sprzedażowy pokazuje liczbę sprzed ostatniego cyklu wymiany danych. Do tego dochodzi drugi problem, który rzadko ktoś nazywa wprost: te systemy liczą co innego, choć w każdym z nich pole nazywa się tak samo — „stan”. Zanim wybierzesz narzędzie, musisz ustalić, o którym stanie w ogóle mówisz.

Cztery różne stany magazynowe, które wszyscy nazywają jednym słowem

W magazynie istnieją cztery różne liczby — stan fizyczny, stan zarezerwowany, stan dostępny i towar w drodze — i to ich pomylenie, a nie awaria integracji, stoi za większością nadsprzedaży. Rozdzielenie ich to najtańsza zmiana, jaką możesz wprowadzić, bo nie wymaga ani nowego systemu, ani nowego dostawcy.

• Stan fizyczny to liczba sztuk, które w tej chwili leżą na regale. Zgadza się z inwentaryzacją i z tym, co widzi magazynier. Konsekwencja: jeśli to jego wysyłasz do sklepu, sprzedajesz towar przypisany już do cudzego zamówienia.
• Stan zarezerwowany to sztuki fizycznie obecne w magazynie, ale przypisane do konkretnych zamówień, dokumentów wydania albo zleceń kompletacji. Konsekwencja: rezerwacja nie zmniejsza stanu fizycznego, więc system, który jej nie widzi, będzie zawyżał dostępność aż do momentu wydania towaru.
• Stan dostępny to stan fizyczny pomniejszony o rezerwacje — jedyna liczba, którą wolno pokazywać kupującemu. Konsekwencja: jeśli sklep, Allegro i Amazon pobierają stan fizyczny zamiast dostępnego, każdy z nich sprzedaje tę samą sztukę niezależnie od pozostałych.
• Towar w drodze to sztuki zamówione u dostawcy lub przesuwane między magazynami, jeszcze nieprzyjęte dokumentem. Konsekwencja: doliczenie ich do stanu dostępnego zamienia sklep w przedsprzedaż, o której klient nie został poinformowany — zamówienie zostanie przyjęte, a wysyłka będzie czekać na dostawę.

Pytanie, które rozstrzyga większość sporów przy wdrożeniu, brzmi więc: którą z tych czterech liczb widzi klient w karcie produktu? Ta sama dyscyplina — jedna encja, jedna definicja, jeden właściciel — wraca przy każdej integracji systemów w firmie, tylko przy stanach magazynowych jej brak widać najszybciej, bo kosztuje anulowane zamówienie.

Który system ma być źródłem prawdy o stanie magazynowym

Źródłem prawdy powinien być ten system, w którym powstaje dokument zmieniający ilość — w praktyce ERP albo system magazynowy WMS, nigdy sklep. Źródło prawdy to jeden system, który jako jedyny ma prawo zapisywać daną wartość, podczas gdy pozostałe wyłącznie ją odczytują. WMS, czyli oprogramowanie sterujące pracą magazynu, komunikuje się z ERP zwykle przez szynę integracyjną albo API; typowy przepływ to zlecenie kompletacji wysyłane z ERP do WMS i zwrotne potwierdzenie realizacji.

Operacyjnie oznacza to trzy konkretne rzeczy. Nikt nie poprawia stanu ręcznie w panelu sklepu, bo najbliższa aktualizacja i tak nadpisze tę zmianę. Każda korekta idzie dokumentem w systemie źródłowym. A jeśli sklep pokazuje liczbę inną niż ERP, domyślnie zakładamy, że to sklep jest nieaktualny — nie odwrotnie.

Webhook czy odpytywanie cykliczne — kiedy który sposób wystarczy

Webhook jest potrzebny wszędzie tam, gdzie liczy się reakcja w sekundach, a odpytywanie cykliczne wystarcza, gdy sprzedajesz w jednym kanale i towar nie schodzi w pojedynczych sztukach. Webhook to model, w którym system sam zgłasza zmianę, wysyłając powiadomienie w chwili jej wystąpienia. Odpytywanie cykliczne to model odwrotny: drugi system co jakiś czas sam pyta, co zmieniło się od ostatniego razu.

Różnica jest czysto operacyjna. Przy odpytywaniu zawsze istnieje okno między dwoma cyklami, w którym sklep sprzedaje na podstawie nieaktualnej liczby. Przy sprzedaży w kilku kanałach naraz — własny sklep plus Allegro, Amazon, eBay, Kaufland czy Empik — to okno mnoży się przez liczbę kanałów, bo każdy z nich niezależnie uważa ostatnią sztukę za dostępną. Webhook to okno zamyka, ale ma własną słabość: powiadomienie może nie dotrzeć, gdy odbiorca akurat nie odpowiada. Dlatego w praktyce łączy się oba modele — zdarzeniowe powiadomienia na bieżąco plus pełne uzgodnienie wszystkich stanów raz na dobę, poza godzinami szczytu.

Sam sposób przesyłania danych bywa różny: REST, SOAP, GraphQL, kolejki komunikatów, a w starszych wdrożeniach transfer plików przez SFTP w formacie CSV lub XML. Uwierzytelnianie to zwykle OAuth 2.0, tokeny albo klucze API. Dla właściciela sklepu istotne jest jedno pytanie: czy dostawca w ogóle wspiera powiadomienia o zmianie, czy jedynym sposobem jest cykliczne pytanie. Jeśli okaże się, że nie ma żadnego wspieranego interfejsu, zostają drogi opisane w tekście o tym, jak połączyć dwa systemy bez API. Wybór między gotową platformą automatyzacji a rozwiązaniem pisanym pod siebie to osobna decyzja, którą rozkłada tekst o tym, czy wybrać Make, n8n czy własną integrację.

Co się dzieje, gdy dwa systemy zmienią ten sam rekord naraz

Wygrywa zapis, który dotarł później — i właśnie to jest problem, bo „później” nie znaczy „poprawniej”. Klasyczny scenariusz: magazynier koryguje stan po inwentaryzacji o 14:02, a integracja wysyła do sklepu wartość pobraną o 14:00 i cofa świeżą korektę. Nikt nie widzi błędu, bo żaden system nie zgłosił awarii — po prostu obowiązuje stara liczba.

Trzy reguły, które to porządkują, warto zapisać w wymaganiach, zanim ktokolwiek zacznie kodować:

• każde pole ma jeden kierunek zapisu, a próba zapisu z drugiej strony jest odrzucana, nie „scalana”;
• każdy komunikat niesie znacznik czasu i własny identyfikator, dzięki czemu starszy komunikat nie nadpisuje nowszego, a ten sam komunikat dostarczony dwa razy nie zmienia stanu dwukrotnie;
• tam, gdzie system po drugiej stronie na to pozwala, przesyłaj operację („zdejmij jedną sztukę”) zamiast wartości bezwzględnej („ustaw siedem”), bo operacja jest odporna na wyścig dwóch równoczesnych zmian.

Rezerwacje z marketplace’ów i bufor bezpieczeństwa — dlaczego to plaster, nie architektura

Bufor bezpieczeństwa to celowe zaniżanie stanu pokazywanego w kanałach sprzedaży, żeby zdążyć zareagować, zanim ostatnia sztuka zostanie sprzedana dwa razy. Działa, ale rozwiązuje objaw, a nie przyczynę — i ma cenę, którą płacisz codziennie.

Problem zaczyna się od tego, że serwisy typu Allegro czy Amazon mają własny moment blokowania towaru i własne opóźnienie w przekazaniu zamówienia do Twojego ERP. Przez te kilka minut sztuka jest już sprzedana w jednym kanale, ale w pozostałych wciąż widnieje jako dostępna. Bufor po prostu przykrywa to okno rezerwą, zamiast je skracać.

Cena bufora jest prosta do policzenia we własnym asortymencie: przy wolno rotujących indeksach z jedną lub dwiema sztukami na stanie rezerwa oznacza, że część katalogu nigdy nie pokaże się jako dostępna. Bufor jest uzasadniony jako rozwiązanie czasowe — na okres wdrożenia, dla najszybciej rotujących indeksów, z ustaloną datą wyłączenia. Jeśli po roku nadal go potrzebujesz, to znak, że nierozwiązany został problem definicji stanu albo częstotliwości wymiany danych.

Mapa synchronizacji: jedna tabela do rozmowy z wykonawcą

Zanim ktokolwiek zacznie wdrażać, rozpisz każdą encję w jednym wierszu: co, w którą stronę, jak często, kto jest właścicielem i co ma się stać przy konflikcie. Poniżej typowy układ dla sklepu sprzedającego w kilku kanałach.

Taką tabelę wypełnisz sam, bez wykonawcy, a ona przesądza o połowie kosztu wdrożenia — im więcej encji i kanałów, tym więcej przypadków brzegowych do obsłużenia; logikę takiej wyceny rozkłada tekst o tym, z czego składa się cena aplikacji mobilnej. Jeśli wolisz od razu uporządkować ją w formie dokumentu do rozmowy, sześciokrokowy kreator briefu prowadzi przez systemy, kanały i procesy, które trzeba w takim projekcie wymienić. Gdy na liście encji pojawiają się także dokumenty sprzedaży, osobnym tematem jest integracja z KSeF własnego systemu.

Czego wymagać od integracji stanów, zanim ją odbierzesz

Integracja bez logów, kolejki nieudanych komunikatów i alertu do konkretnej osoby jest niedokończona, niezależnie od tego, jak dobrze działa w dniu uruchomienia. To są elementy, które decydują o zachowaniu w złym dniu, a nie w dobrym.

• Logi z możliwością odtworzenia zdarzenia — co zostało wysłane, kiedy, w którą stronę i z jakim skutkiem, przechowywane przez ustalony z góry okres.
• Kolejka nieudanych komunikatów to lista wiadomości, których nie udało się dostarczyć; bez niej nieudana aktualizacja stanu po prostu znika i nikt się o tym nie dowie.
• Ponowienia z rosnącym odstępem i limitem prób, żeby chwilowa niedostępność systemu nie wymagała ręcznej interwencji, a trwała awaria nie zapętliła się w nieskończoność.
• Alert do człowieka wysyłany na konkretny adres lub kanał, wyzwalany progiem zdefiniowanym po Twojej stronie — na przykład brakiem odświeżenia stanów przez ustalony czas.
• Właściciel procesu wskazany imiennie, a nie „dział IT”: jedna osoba, która czyta alerty i ma prawo wstrzymać sprzedaż wrażliwych indeksów.

Jedno pytanie zadaj przed podpisaniem umowy, nie po. Część starszych systemów magazynowych obecnych na polskim rynku nie ma publicznego, wspieranego interfejsu, a integracja wpięta bezpośrednio w bazę danych bywa łamana przy kolejnej aktualizacji dostawcy — i wtedy stany przestają się aktualizować bez żadnego komunikatu o błędzie.