Datové procesy / 14
Přenášejte objednávky. Udržujte dohledatelné stavy.
Shop hlásí zaplaceno, ERP ještě nezná objednávku a expedice už má tracking číslo. Propojíme tyto kroky s definovanými stavy, jednoznačnými referencemi objednávek a plánovaným obnovením běhu.
Výchozí stav
Stejný název stavu má v každém systému jiný význam.
„Dokončeno“ může v shopu ukončovat zpracování a v ERP znamenat zaúčtování faktury. Dílčí dodávka se týká jednotlivých položek; refund není automaticky úplné storno objednávky.
Definujeme obchodní události a povolené přechody. Platba, objednávka, zásoby, expedice a faktura zůstávají samostatné oblasti odpovědnosti. Integrace zviditelňuje jejich vztahy.
Co zajišťuje DataSource
Předání objednávky. Model stavů. Zpětné hlášení.
Předání objednávky
Přiřazení externího čísla objednávky a cílového ID. Ověření položek, daňových a měnových hodnot a dodacích adres před založením objednávky.
Model stavů
Mapování systémových stavů na obchodní stavy. Samostatná specifikace dílčích množství, storna, refundace a následných změn.
Zpětné hlášení
Vrácení potvrzených cílových stavů a expedičních informací. Řešení opakovaných událostí a nejasných odpovědí zápisu podle identity objednávky.
angenommen → im ERP bestätigt → in Bearbeitung
↓
teilversendet
↓
versendet
Doppeltes Ereignis → bekannten Effekt abgleichen
Älteres Ereignis → aktuellen Zustand erhaltenTechnický scénář / ilustrativní příklad
Hlášení expedice bez opětovného použití starých stavů.
Ilustrativní výřez stavového automatu. Skutečné názvy stavů se dohodnou se systémy. Události platí pro objednávku nebo položku, nikoli plošně pro všechna data.
Vzorová data a navržená pravidla. Konkrétní rozhraní a obchodní pravidla se prověří pro váš projekt.
Ošetření chyb, bezpečnost a provoz
Duplicity: ověření a provoz.
Duplicity
Po timeoutu nejprve ověřit, zda objednávka již vznikla. Druhé založení může dvakrát spustit rezervace, fakturaci nebo expedici.
Pořadí
Události mohou přijít opožděně. Ověřit cílový stav a verzi; problematické přechody oddělit k vyjasnění.
Porovnání
Pravidelně porovnávat otevřené objednávky mezi systémy. Cíleně hlásit nepotvrzené přenosy a trvale odmítané položky.
Odborné otázky
Detaily důležité před implementací.
Objednávky · Sklad · Stavové přechody · Dílčí dodávka · Porovnání
Lze skladový stav jednoduše zkopírovat ze shopu do ERP?
Záleží na autoritativní skladové a rezervační logice. Jinak může stejná objednávka dostupné množství snížit vícekrát.
Jak se modelují dílčí dodávky?
Pomocí položek, množství a jednoznačných referencí dodávek. Jediný stav objednávky často nestačí.
Jsou webhooky nezbytné?
Ne. Pravidelné API porovnání může být vhodné. Webhooky mohou snížit zpoždění, ale potřebují stejná pravidla identity a opakování.
Pro technické vyjasnění
Začít vaším konkrétním procesem.
Popište systémy, seznamy stavů, příklady objednávek a položek a skutečný platební a expediční proces. Reálný anonymizovaný chybový scénář pomůže s prioritizací.
V prvním rozhovoru vyjasníme dostupné přístupy, odpovědnost za data a omezený první datový tok. Poté dohodneme rozsah, odpovědnosti a podmínky.
Pro začátek stačí anonymizované příklady. V prvním dotazu neposílejte hesla, tokeny ani produkční data s osobními údaji.
Související úlohy
Další propojení v kontextu.
Propojit WooCommerce s ERP
Produkty se spravují v ERP, upravují ve shopu a aktualizují souborem. Propojíme datové modely a vyjasníme, které informace spravuje ERP a které zůstávají ve shopu.
Spolehlivě zpracovat webhooky
Přijde událost a má vyvolat akci v dalším systému. Opakované doručení, zpoždění nebo výpadek cílového API z toho dělají provozní proces. Vyvineme jej s jednoznačnými událostmi a ověřitelnými účinky.
Synchronizovat data mezi systémy
Zákazník se změní v CRM i ERP. Který stav platí? Synchronizaci stavíme na obchodních odpovědnostech a stabilních identitách, aby pravidelné přenosy nevytvářely skryté konflikty dat.