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

Dříve 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 to považuje za jednorázovou chybu, jenže stopa vede k architektonickému rozhodnutí, o kterém si nikdo nepamatuje, že ho učinil.

Příčinou je vlastnictví

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á ve chvíli, kdy objednávku zaeviduje. E-shop odečítá ve chvíli, kdy zákazník dokončí objednávku. Podle vlastních pravidel mají pravdu oba a synchronizace mezi nimi rozhoduje bez jasného pravidla.

Řešením je jediný princip: jeden zdroj pravdy na jeden fakt. Údaj o skladu je uložen právě na jednom místě, téměř vždy v ERP nebo ve WMS, protože tam se sklad eviduje a fyzicky se pohybuje zboží. E-shop drží kopii v cache pro zobrazení a rezervaci. Jakmile je to jednou jasně dané, má každá otázka kolem synchronizace odpověď: v pochybnostech vyhrává zdroj pravdy.

Poruchy, které se opakují

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 právě 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í. Stejný webhook dorazí dvakrát (doručení webhooků je typicky at-least-once, takže stejná událost může dorazit vícekrát) a handler odečte sklad dvakrát.
• Plné synchronizace kolidují 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ý.
• Posun v mapování. SKU přejmenované v ERP se v e-shopu bez povšimnutí stane novým produktem; to staré si nechá zastaralý počet navždy.
• Sady a bundly. E-shop prodává sadu; ERP počítá komponenty. Pokud rozpad sady na komponenty vedete v tabulce, počítejte s tím, že je neaktuální.

Vzory, které spor ukončí

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

1. Delty a rekonciliace. Událostmi řízené aktualizace pro rychlost a pravidelné plné porovnání, které najde, co událostem uteklo. Díky rekonciliaci lze rychlé cestě důvěřovat.
2. Idempotentní konzumenti. Každá aktualizace nese identifikátor, na kterém konzument deduplikuje, takže zpracovat ji dvakrát nic nezmění. Tato jediná vlastnost zvládne opakovaná doručení i replaye. Konflikty souběžnosti jsou samostatný problém: ztracené aktualizace a plné synchronizace, které kolidují s deltami, potřebují čísla verzí nebo pořadová čísla, aby zastaralý zápis nemohl přepsat novější.
3. Correlation ID od začátku do konce. Když objednávka 18342 nedorazila do skladu, měly by logy během pár minut ukázat, kam se poděla.
4. Upozorňujte na rozcházení čísel. Synchronizace, která hlásí úspěch, zatímco se čísla rozcházejí, je horší než ta, která selže otevřeně. Porovnávejte agregáty pravidelně a pošlete alert, když delta roste.
5. 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 se po vypršení platnosti všechno vrátí ke zdroji 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. Stejnou architekturu jsme stavěli nad NetSuite, Business Central, Odoo i nad českými a slovenskými systémy jako Pohoda a Money S5, se kterými mezinárodní dodavatelé konektorů většinou nepočítají. Právě tato dlouhá řada menších lokálních systémů je jedním z hlavních důvodů, proč naši práci na integracích vůbec děláme.

Pokud se u vás skladová čísla mezi e-shopem a ERP právě rozcházejí, začněte tím, že jednoznačně určíte, který systém sklad vlastní, a pokud chcete pomoct, stačí se ozvat. Rozhodnout, kde který fakt patří, je návrh systému; zbytek je běžná inženýrská práce.