Proč se ERP a e-shop neshodnou na skladě

Dřív nebo později narazí každý e-shop s ERP na stejný ticket: storefront hlásí pět kusů skladem, sklad hlásí nulu a zákazník právě zaplatil za něco, co neexistuje. Podpora tomu říká výpadek, jenže stopa vede k architektonickému rozhodnutí, o kterém si nikdo nepamatuje, že ho udělal.

Kořen je ve vlastnictví, ne v synchronizaci

Když se čísla rozejdou, všichni ladí synchronizační skript. Skript ale většinou dělá přesně to, co dostal za úkol; problém je, že dva systémy jsou oba přesvědčené, že skladové číslo vlastní. ERP odečítá při zaknihování objednávky. E-shop odečítá při dokončení pokladny. Podle vlastních pravidel mají pravdu oba a synchronizace mezi nimi rozhoduje bez jasného pravidla.

Oprava je jeden princip: jeden zdroj pravdy na jeden fakt. Pravda o skladu žije právě na jednom místě, téměř vždy v ERP nebo ve WMS, protože tam se sklad zaknihuje a zboží se fyzicky hýbe. E-shop drží kopii v cache pro zobrazení a rezervaci. Jakmile je tohle explicitní, má každá otázka synchronizace odpověď: v pochybnostech vyhrává zdroj pravdy.

Poruchy, které nacházíme pořád dokola

S vyřešeným vlastnictvím jsou zbylé chyby mechanické a opakují se napříč platformami i ERP:

Ztracené aktualizace. ERP pošle změnu skladu, e-shop je zrovna uprostřed deploye nebo volání odmítne kvůli rate limitu, a nikdo to nezopakuje. Za pár týdnů se někdo ptá, proč je jedno SKU celý měsíc „vyprodané“.
Duplicitní doručení. Tentýž webhook dorazí dvakrát (doručení webhooků je typicky at-least-once, takže tatáž událost může dorazit víckrát) a handler odečte sklad dvakrát.
Plné synchronizace v závodě s deltami. Noční plný import a událostmi řízené aktualizace běží nad stejnými řádky; vyhrává, kdo skončí poslední, a občas je to ten zastaralý.
Rozjeté mapování. SKU přejmenované v ERP se v e-shopu tiše stane novým produktem; to staré si nechá zastaralý počet navždy.
Sety a bundly. E-shop prodává sadu; ERP počítá komponenty. Pokud převod žije v excelu, počítejte s tím, že je neaktuální.

Vzory, které spor ukončí

Integrační vrstva, která tyhle tickety přestane produkovat, vypadá stejně bez ohledu na to, jaké ERP za ní stojí:

Delty plus rekonciliace. Událostmi řízené aktualizace pro rychlost a pravidelné plné porovnání, které najde, co událostem uteklo. Rekonciliace je pojistka, díky které se dá rychlé cestě věřit.
Idempotentní konzumenti. Každá aktualizace nese identifikátor, na kterém konzument deduplikuje, takže zpracovat ji dvakrát nic nezmění. Tahle jediná vlastnost pohltí opakovaná doručení i replaye. Souběžné konflikty jsou samostatný problém: ztracené aktualizace a plné synchronizace v závodě s deltami potřebují čísla verzí nebo pořadová čísla, aby zastaralý zápis nemohl přepsat novější.
Correlation ID od začátku do konce. Když objednávka 18342 nedorazila do skladu, má být „kam se poděla“ minutový dotaz do logů, ne celé odpoledne.
Alert na rozjezd čísel, ne jen na selhání. Synchronizace, která svítí zeleně, zatímco se čísla rozcházejí, je horší než ta, která spadne. Porovnávejte agregáty podle plánu a vzbuďte někoho, když delta roste.
Rezervace s expirací. Pokud u vás rezervace vzniká brzy, drží košík zboží minuty a nezaplacená objednávka déle; ve výchozím nastavení ale rezervace vzniká až při založení objednávky, ne při vložení do košíku. Tak či tak všechno expiruje zpět do zdroje pravdy. Přeprodání během kampaní má většinou kořeny v rezervacích, které nikdy neexpirují nebo nikdy nevznikly.

Nic z toho nezávisí na dodavateli. Stejný tvar jsme stavěli proti NetSuite, Business Central, Odoo i českým a slovenským systémům jako Pohoda a Money S5, se kterými mezinárodní výrobci konektorů většinou nepočítají. Právě kvůli téhle dlouhé řadě menších lokálních systémů z poloviny existuje naše práce na integracích.

Pokud se u vás skladová čísla mezi e-shopem a ERP právě rozcházejí, začněte tím, že otázku vlastnictví uděláte explicitní, a pokud chcete pomoct, stačí se ozvat. Rozhodnout, kde který fakt sídlí, je návrh systému; zbytek je běžná inženýrská práce.