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 to považuje za jednorazovú chybu, stopa však vedie k architektonickému rozhodnutiu, o ktorom si nikto nepamätá, že ho urobil.

Príčinou je vlastníctvo

Keď sa čísla rozídu, každý ladí 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ď zákazník dokončí objednávku. Podľa vlastných pravidiel majú pravdu oba a synchronizácia medzi nimi nemá pravidlo, podľa ktorého by rozhodla, ktorá hodnota má prednosť.

Riešením je jediný princíp: jeden zdroj pravdy na jeden fakt. Údaj o zásobách je uložený presne na jednom mieste, takmer vždy v ERP alebo vo WMS, pretože tam sa zásoby evidujú a fyzicky sa pohybuje tovar. 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é sa opakujú

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 práve nasadzuje novú verziu 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ý.
• Rozchádzajúce sa mapovanie. 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 komplety. E-shop predáva set; ERP počíta komponenty. Ak rozpis komponentov vediete len v tabuľke, 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í:

1. Delty a rekonciliácia. Event-driven aktualizácie pre rýchlosť a periodické plné porovnanie, ktoré nájde, čo udalostiam ušlo. Vďaka rekonciliácii možno rýchlej ceste dôverovať.
2. Idempotentní konzumenti. Každá aktualizácia nesie identifikátor, na ktorom konzument deduplikuje, takže jej dvojité spracovanie nič nezmení. Táto jediná vlastnosť zvládne opakované doručenia aj replaye. Konflikty pri súbežnom zápise 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ší.
3. Correlation ID od začiatku po koniec. Keď objednávka 18342 nikdy nedorazila do skladu, odpoveď na „kde skončila“ majú logy dať za pár minút.
4. Upozorňujte na rozchádzanie čísel. Synchronizácia, ktorá hlási úspech, kým sa čísla rozchádzajú, je horšia než tá, ktorá rovno zlyhá. Porovnávajte agregáty pravidelne a pošlite alert, keď delta rastie.
5. 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; v predvolenom nastavení však rezervácia vzniká až pri založení objednávky, nie pri vložení do košíka. Tak či tak sa po vypršaní platnosti všetko vráti k zdroju pravdy. Predaj tovaru, ktorý na sklade nie je, sa počas kampaní zvyčajne dá vystopovať k rezerváciám, ktoré nikdy nevypršia alebo nikdy nevznikli.

Nič z toho nezávisí od dodávateľa. Rovnakú architektúru 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 zvyčajne ignorujú. Práve táto skupina menších lokálnych systémov je jedným z hlavných dôvodov, prečo naše integračné služby vznikli.

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, ozvite sa nám. Rozhodnúť, kam ktorý fakt patrí, je system design; samotná výstavba synchronizácie je potom už rutinná práca.