Dlaczego stany magazynowe w sklepie nie zgadzają się z Subiektem – najczęstsze przyczyny i jak je namierzać
Sklep pokazuje 12 sztuk. Magazyn w Subiekcie 8. Który system mówi prawdę?
Często oba – tylko każdy o czymś innym. Sklep liczy stan od chwili ostatniej synchronizacji i pomniejsza go o własne rezerwacje. Subiekt zna tylko dokumenty, które do niego dotarły. Między tymi dwiema liczbami stoi zwykle nie jedna awaria, lecz kilka drobnych reguł i wyjątków, które nikt nie spisał. Oto miejsca, w których dane rozjeżdżają się najczęściej.
Siedem najczęstszych przyczyn rozjazdu
1. Mapowanie magazynów
Jeśli w Subiekcie prowadzisz więcej niż jeden magazyn, sklep musi wiedzieć, z którego ma czytać stany. Problem pojawia się wtedy, gdy ktoś dołoży nowy magazyn, przeniesie towar albo zmieni regułę sumowania. Nagle część zapasu znika ze sklepu, choć fizycznie leży na półce.
2. Rezerwacje po stronie sklepu
Towar dodany do koszyka albo do zamówienia, które czeka na płatność, bywa już zarezerwowany. Sklep pomniejsza dostępność o te rezerwacje, Subiekt jeszcze nic o nich nie wie. Różnica rośnie razem z kolejką niezrealizowanych zamówień i znika dopiero, gdy dokumenty dotrą do programu.
3. Czas synchronizacji
Stan w sklepie to zawsze stan z chwili ostatniej synchronizacji. Im rzadsza, tym większe okno, w którym obie strony mają rację i wciąż się różnią. Do tego dochodzi kolejka: gdy zmian jest dużo, część aktualizacji czeka na swoją kolej i trafia do sklepu później, niż oczekujesz.
4. Ponowienia webhooków
Sklep powiadamia integrację o nowym zamówieniu komunikatem, który w branży nazywa się webhookiem. Jeśli pierwsze wywołanie nie dostało potwierdzenia, sklep wysyła je jeszcze raz. Bez ochrony przed podwójnym przetworzeniem ta sama paczka danych tworzy drugą rezerwację albo drugi dokument – i nikt tego nie widzi, bo oba wyglądają poprawnie.
5. Ręczne korekty
Ktoś poprawił stan w Subiekcie „na szybko” po inwentaryizacji. Ktoś inny sprzedał towar z magazynu, którego sklep w ogóle nie obsługuje. Ręczna korekta, której nikt nie opisał, wraca jako tajemnicza różnica tygodnie później, gdy już nikt nie pamięta, dlaczego powstała.
6. Zwroty
Towar fizycznie wrócił do magazynu, ale dokument zwrotu jeszcze nie powstał – albo powstał po stronie sklepu i nie wrócił do programu. Zwroty to klasyczne miejsce, w którym stany rozchodzą się w jedną stronę: magazyn ma więcej niż sklep.
7. Wersje i dodatki
Po aktualizacji Subiekta GT dodatek obsługujący sklep potrafi przestać działać po cichu. Żaden komunikat o tym nie mówi – widać to dopiero po rosnącej różnicy stanów. Tak samo zachowuje się wygasły token API albo pole w odpowiedzi sklepu, które zmieniło nazwę po jego aktualizacji.
Jak namierzyć, gdzie dane się rozjechały
Nie porównuj dwóch pełnych zestawień i nie szukaj błędu „ogólnie”. Weź jeden przypadek i przejdź z nim całą drogę:
- Wybierz konkretny towar, którego stan się różni – najlepiej taki, który był sprzedawany albo przyjęty w ostatnich dniach.
- Ustal identyfikatory, którymi rekord łączy się między systemami: kod towaru, EAN, numer zamówienia.
- Idź za nim krok po kroku: zamówienie w sklepie, potwierdzenie, dokument w Subiekcie, aktualizacja stanu wracająca do sklepu.
- Znajdź pierwszy punkt, w którym liczba przestaje się zgadzać. To miejsce usterki – niekoniecznie to, w którym ją zauważyłeś.
Drugie pytanie, które warto sobie zadać: który system rozstrzyga? Dla każdego typu danych ustal jedno źródło prawdy. Stany, ceny i statusy wysyłki mogą mieć osobnych właścicieli. Regułę zapisz na piśmie. Od tej chwili każda przyszła różnica ma jasnego sędziego i nie kończy na dyskusji, która strona „czuje się” lepiej poinformowana.
Po trzecie: porównuj wyjątki, nie tabele. Codzienny raport różnic, który pokazuje wyłącznie rekordy wymagające spojrzenia, da się faktycznie przeglądać. Pełne zestawienie dwóch systemów obok siebie po tygodniu nikt czytać nie będzie.
Kiedy wystarczy poprawka, a kiedy nowa integracja
Większość rozjazdów kończy się na małej poprawce w istniejącym połączeniu: mapowanie magazynu, filtr towarów, częstotliwość synchronizacji, ochrona przed ponowionym webhookiem. Integrację da się często naprawić fragment po fragmencie, zamiast pisać wszystko od nowa.
Z drugiej strony są sytuacje, w których żadne poprawianie nie pomoże, bo reguły biznesowe wychodzą poza to, co gotowe rozwiązanie przewidziało. Kilka magazynów z różnymi zasadami, produkty sprzedawane w zestawach lub wersjach, dane przechodzące przez więcej niż dwa systemy. Wtedy sensowniej jest napisać połączenie dokładnie pod te reguły niż doklejać kolejne łatki do rozwiązania, które z takimi regułami sobie nie radzi.
Granica jest prosta: jeśli rozjazd da się wyjaśnić jedną regułą, wystarczy poprawka. Jeśli wyjaśnienie wymaga listy wyjątków, która rośnie z każdym miesiącem, integracja nie pasuje do procesu i czas ją przebudować.
Co dalej
Jeśli masz objaw i chcesz wiedzieć, gdzie leży przyczyna, opisuję takie sprawy krok po kroku na stronie Naprawa integracji i rozbieżności stanów – od odtworzenia jednego przypadku, przez ustalenie źródła prawdy, po małą poprawkę i sposób pilnowania integracji przy kolejnej aktualizacji systemu. Napisz, które liczby się różnią i kiedy problem powstał – od tego zaczynamy.