Dlaczego ERP i sklep różnią się stanami magazynowymi

Prędzej czy później każdy sklep z ERP-em dostaje ten sam ticket: storefront pokazuje pięć sztuk, magazyn zero, a klient właśnie zapłacił za coś, czego nie ma. Support traktuje to jako jednorazowy błąd, ale wszystko sprowadza się do decyzji architektonicznej, której podjęcia nikt nie pamięta.

Przyczyną jest własność danych

Kiedy liczby przestają się zgadzać, uwaga kieruje się na skrypt synchronizacji. Ale skrypt zwykle wykonuje dokładnie to, co mu zlecono; problem w tym, że dwa systemy naraz uważają, że to one są właścicielem stanu. ERP zdejmuje towar ze stanu, gdy księguje zamówienie. Sklep zdejmuje, gdy kończy się checkout. Każdy ma rację według własnych zasad, a synchronizacja nie ma reguły rozstrzygania konfliktów.

Rozwiązanie to jedna zasada: jedno źródło prawdy na jeden fakt. Prawda o stanie magazynowym znajduje się dokładnie w jednym miejscu, niemal zawsze w ERP albo WMS, bo tam księguje się stany i tam odbywa się fizyczny ruch towarów. Sklep trzyma buforowaną kopię do wyświetlania i rezerwację. Gdy powie się to wprost, każde pytanie o synchronizację ma odpowiedź: w razie wątpliwości wygrywa źródło prawdy.

Powtarzające się błędy

Gdy własność danych jest ustalona, pozostałe błędy są mechaniczne i powtarzają się niezależnie od platformy i ERP-a:

• Utracone aktualizacje. ERP wypycha zmianę stanu, sklep jest w trakcie deployu albo odrzuca wywołanie z powodu rate limitu i nikt go nie ponawia. Po kilku tygodniach ktoś pyta, dlaczego jedno SKU jest „niedostępne” od miesiąca.
• Podwójne dostarczenia. Ten sam webhook przychodzi dwa razy (dostarczanie jest zwykle at-least-once, więc to samo zdarzenie może przyjść więcej niż raz), a handler zdejmuje stan dwukrotnie.
• Pełne synchronizacje ścigające się z deltami. Nocny pełny import i aktualizacje zdarzeniowe piszą po tych samych wierszach; wygrywa proces, który zakończy się ostatni, a bywa, że to ten z nieaktualnymi danymi.
• Rozjazd mapowania. SKU przemianowane w ERP staje się w sklepie nowym produktem bez żadnego sygnału; stare zachowuje nieaktualny stan już na zawsze.
• Zestawy i komplety. Sklep sprzedaje zestaw; ERP liczy składniki. Jeśli przelicznik zestawu na składniki jest trzymany w arkuszu, zwykle jest nieaktualny.

Wzorce, które eliminują niespójność

Warstwa integracji, która przestaje generować takie tickety, wygląda tak samo bez względu na to, jaki ERP za nią stoi:

1. Delty i uzgadnianie. Aktualizacje zdarzeniowe dla szybkości i okresowe pełne porównanie, które znajduje to, co zdarzeniom umknęło. Uzgadnianie jest tym, co pozwala ufać szybkiej ścieżce.
2. Idempotentni konsumenci. Każda aktualizacja niesie identyfikator, po którym konsument deduplikuje, więc przetworzenie jej dwa razy nic nie zmienia. To eliminuje problem ponowień i replayów. Konflikty współbieżności to osobny problem: utracone aktualizacje i pełne synchronizacje ścigające się z deltami wymagają numerów wersji albo sekwencji, żeby nieaktualny zapis nie nadpisał nowszego.
3. Correlation ID na całej ścieżce. Kiedy zamówienie 18342 nie dotarło do magazynu, ustalenie w logach, gdzie utknęło, powinno zająć kilka minut.
4. Wysyłaj alert przy rozbieżności. Synchronizacja, która raportuje sukces, podczas gdy liczby się rozchodzą, jest gorsza od takiej, która kończy się jawnym błędem. Porównuj agregaty według harmonogramu i wysyłaj alert, gdy delta rośnie.
5. Rezerwacje z terminem ważności. Jeśli Twoja konfiguracja rezerwuje stan wcześnie, koszyk trzyma go przez minuty, a nieopłacone zamówienie dłużej; domyślnie jednak rezerwacja powstaje przy złożeniu zamówienia, a nie przy dodaniu do koszyka. Tak czy inaczej po wygaśnięciu wszystko wraca do źródła prawdy. Nadmierna sprzedaż podczas kampanii zwykle wynika z rezerwacji, które nigdy nie wygasają albo nigdy nie powstały.

Nic z tego nie zależy od dostawcy. Tę samą architekturę budowaliśmy dla NetSuite, Business Central, Odoo oraz czeskich i słowackich systemów takich jak Pohoda i Money S5, które międzynarodowi dostawcy gotowych konektorów zwykle ignorują. Ten długi ogon mniejszych, lokalnych systemów to duża część powodu, dla którego istnieją nasze integracje.

Jeśli Twój sklep i Twój ERP wykazują dziś taką niespójność, zacznij od postawienia pytania o właściciela danych wprost. A jeśli chcesz pomocy, napisz do nas. Decyzja, gdzie leży każdy fakt, to projektowanie systemów; samą synchronizację da się już po prostu zbudować.