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 nazywa to usterką, ale ślad prowadzi do decyzji architektonicznej, której podjęcia nikt nie pamięta.

Przyczyną jest własność, nie skrypt synchronizacji

Kiedy liczby przestają się zgadzać, uwaga kieruje się na skrypt synchronizacji. Ale skrypt zwykle wykonuje dokładnie to, co zaprojektowano; problem w tym, że dwa systemy naraz uważają, że to one są właścicielem stanu. ERP zdejmuje sztuki, 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 jest przechowywana w dokładnie jednym miejscu, niemal zawsze w ERP albo WMS, bo tam księguje się stany i tam odbywa się fizyczny ruch towarów. Sklep trzyma 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.

Błędy, które powtarzają się najczęściej

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

Zgubione aktualizacje. ERP wypycha zmianę stanu, sklep jest akurat w trakcie deployu albo odrzuca wywołanie z powodu rate limitu i nikt go nie ponawia. Tygodnie później 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.
Dryf mapowania. SKU przemianowane w ERP staje się w sklepie nowym produktem bez żadnego sygnału; stare zachowuje nieaktualny stan bezterminowo.
Zestawy i komplety. Sklep sprzedaje zestaw; ERP liczy składniki. Jeśli przeliczenie jest utrzymywane w arkuszu kalkulacyjnym, zwykle jest nieaktualne.

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:

Delty plus rekoncyliacja. Aktualizacje zdarzeniowe dla szybkości i okresowe pełne porównanie, które znajduje to, co zdarzeniom umknęło. Rekoncyliacja to siatka bezpieczeństwa, dzięki której szybkiej ścieżce można ufać.
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: zgubione aktualizacje i pełne synchronizacje ścigające się z deltami wymagają numerów wersji albo sekwencji, żeby nieaktualny zapis nie nadpisał nowszego.
Correlation ID od końca do końca. Kiedy zamówienie 18342 nie dotarło do magazynu, ustalenie, gdzie utknęło, powinno wymagać jednego zapytania do logów, a nie kilku godzin analizy.
Alarmuj już przy rozjeździe. 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 uruchamiaj alert, gdy delta rośnie.
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 wszystko wygasa z powrotem do źródła prawdy. Oversell podczas kampanii prawie zawsze prowadzi do rezerwacji, które nigdy nie wygasły albo nigdy nie istniały.

Nic z tego nie zależy od dostawcy. Tę samą architekturę budowaliśmy dla Business Central, Comarch ERP i Subiekta, ale też dla NetSuite, Odoo czy Pohody i Money S5. Ten długi ogon systemów, które międzynarodowi dostawcy gotowych konektorów zwykle ignorują, to połowa 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łasność wprost. A jeśli chcesz pomocy, wystarczy jedna rozmowa. Decyzja, gdzie leży każdy fakt, to projektowanie systemów; reszta to już rzetelna inżynieria.