Prečo sa ERP a e-shop nezhodnú na sklade

Skôr či neskôr každý e-shop s ERP narazí na ten istý ticket: storefront tvrdí päť kusov na sklade, sklad tvrdí nula a zákazník práve zaplatil za niečo, čo neexistuje. Podpora tomu hovorí výpadok, stopa však vedie k architektonickému rozhodnutiu, ktoré kedysi ktosi urobil a na ktoré si už nikto nepamätá.

Koreňom je vlastníctvo, nie synchronizačný job

Keď sa čísla rozídu, každý debuguje synchronizačný skript. Skript však väčšinou robí presne to, čo dostal za úlohu; problém je, že dva systémy sú presvedčené, že číslo zásob vlastnia. ERP odpočíta, keď zaeviduje objednávku. E-shop odpočíta, keď sa dokončí pokladňa. Podľa vlastných pravidiel majú pravdu oba a synchronizačný job rozhoduje bez jasného pravidla.

Oprava je jeden princíp: jeden zdroj pravdy na jeden fakt. Pravda o zásobách žije presne na jednom mieste, takmer vždy v ERP alebo vo WMS, pretože tam sa zásoby evidujú a tam sa tovar fyzicky hýbe. E-shop drží cachovanú kópiu na zobrazenie a rezerváciu. Keď si to raz takto pomenujete, každá synchronizačná otázka má jasnú odpoveď: pri pochybnostiach vyhráva zdroj pravdy.

Poruchy, ktoré nachádzame opakovane

S vyriešeným vlastníctvom sú zvyšné chyby mechanické a opakujú sa naprieč platformami aj ERP systémami:

Stratené aktualizácie. ERP pošle zmenu zásob, e-shop je práve uprostred deployu alebo volanie narazí na rate limit a nikto ho nezopakuje. O pár týždňov sa niekto pýta, prečo je jedno SKU celý mesiac „vypredané“.
Duplicitné doručenia. Ten istý webhook príde dvakrát (doručenie webhookov je zvyčajne at-least-once, takže tá istá udalosť môže doraziť viackrát) a handler odpočíta zásoby dvakrát.
Plné synchronizácie, ktoré kolidujú s deltami. Nočný plný import a event-driven aktualizácie bežia nad tými istými riadkami; vyhráva ten, kto skončí posledný, a občas je to ten zastaraný.
Drift mapovania. SKU premenované v ERP sa v e-shope potichu stane novým produktom; staré si natrvalo nechá posledný známy stav zásob.
Sety a kity. E-shop predáva set; ERP počíta komponenty. Ak prevod existuje len v exceli, počítajte s tým, že je neaktuálny.

Vzory, ktoré rozpor odstránia

Integračná vrstva, ktorá prestane produkovať tieto tickety, vyzerá rovnako bez ohľadu na to, aké ERP za ňou stojí:

Delty plus rekonciliácia. Event-driven aktualizácie pre rýchlosť a periodické plné porovnanie, ktoré nájde, čo udalostiam ušlo. Rekonciliácia je kontrolný mechanizmus, ktorý umožňuje spoľahnúť sa na rýchlu cestu.
Idempotentní konzumenti. Každá aktualizácia nesie identifikátor, na ktorom konzument deduplikuje, takže jej dvojité spracovanie nič nezmení a opakované doručenia ani replaye nenarobia škodu. Súbežnostné konflikty sú samostatný problém: stratené aktualizácie a plné synchronizácie kolidujúce s deltami potrebujú verzie alebo sekvenčné čísla, aby zastaraný zápis neprepísal novší.
Correlation ID od začiatku po koniec. Keď objednávka 18342 nikdy nedorazila do skladu, odpoveď na „kde skončila“ chcete v logoch nájsť za pár minút namiesto celého popoludnia.
Alert na divergenciu, nie iba na zlyhanie. Synchronizácia, ktorá beží nazeleno, kým sa čísla rozchádzajú, je horšia než taká, ktorá zlyhá. Porovnávajte agregáty podľa rozvrhu a zavolajte niekoho, keď delta rastie.
Rezervácie s expiráciou. Ak u vás rezervácia vzniká skoro, košík drží zásobu minúty a nezaplatená objednávka dlhšie; vo východiskovom nastavení však rezervácia vzniká až pri založení objednávky, nie pri vložení do košíka. Tak či tak všetko expiruje späť do zdroja pravdy. Predaj tovaru, ktorý počas kampane nie je, sa zvyčajne dá vystopovať k rezerváciám, ktoré nikdy neexpirujú alebo nikdy nevznikli.

Nič z toho nezávisí od dodávateľa. Rovnakú vrstvu sme stavali nad NetSuite, Business Central, Odoo aj nad českými a slovenskými systémami ako Pohoda a Money S5, ktoré medzinárodní dodávatelia konektorov radi ignorujú; aj preto má naša integračná práca stále čo robiť.

Ak sa váš e-shop a vaše ERP práve teraz takto rozchádzajú, začnite tým, že si výslovne dohodnete, ktorý systém číslo vlastní; ak chcete pomoc, stačí jeden hovor. Rozhodnúť, kam ktorý fakt patrí, je system design; samotná výstavba synchronizácie je potom už rutinná práca.