Při propojení určete ERP nebo WooCommerce jako zdroj každého pole, používejte stabilní SKU a externí ID a synchronizaci navrhněte idempotentně. Objednávky posílejte přes frontu, sklad pravidelně slaďujte a chyby zobrazujte obsluze. Před ostrým spuštěním proveďte paralelní test na reálných scénářích.
Propojení WooCommerce s ERP odstraňuje ruční přepisování katalogu a objednávek pouze tehdy, má-li přesná pravidla. Oba systémy často ukládají podobná pole, ale používají je jinak. ERP může evidovat zásoby po jednotlivých skladech a ceny bez daně, zatímco e-shop zobrazuje prodejní dostupnost, akce a varianty. Bez mapování významu vznikají rozdíly, které se při větším objemu obtížně dohledávají.
Integrace se proto navrhuje společně s lidmi z e-shopu, skladu, financí a IT. Nejprve se určí zdroj pravdy a životní cyklus objednávky, poté technický způsob výměny. Nejasné pravidlo nelze opravit rychlejším API. Následující kapitoly pokrývají produkty, sklad, objednávky, odolnost i zavedení bez ohrožení ostrého provozu.
Určete systém pravdy pro katalog
V mapovací tabulce uveďte název, popis, SKU, EAN, variantu, cenu, daňovou kategorii, sklad, hmotnost, obrázky a stav publikace. U každého pole označte směr a odpovědného vlastníka. Marketingový popis může vznikat ve WooCommerce, zatímco cena v ERP. Synchronizace pak nesmí celý produkt přepsat jedním objektem. Stabilní SKU nebo interní ID odliší záznam i po změně názvu.
Variantní model musí mít jednoznačnou korespondenci. Položka v ERP může představovat každou variantu samostatně, zatímco WooCommerce je sdružuje pod nadřazený produkt. Definujte vytváření, deaktivaci a opětovnou aktivaci. Chybějící položka nemusí znamenat smazání; může jít o neúplnou dávku. Obrázky přenášejte inkrementálně a kontrolujte velikost, formát a práva k použití. Import musí umět bezpečně pokračovat po přerušení.
Navrhněte sklad a dostupnost pro souběh
Rozlišujte fyzický stav, rezervaci, prodejní dostupnost a očekávaný příjem. WooCommerce potřebuje hodnotu, podle které povolí nákup, ale ERP může mít více skladů a opožděné pohyby. Určete, kdy se kus rezervuje, kdy se uvolní po neúspěšné platbě a jak se zpracuje manuální objednávka mimo web. Bez tohoto modelu může synchronizace správně přenášet nesprávnou obchodní hodnotu.
Při vyšším souběhu se nelze plně spoléhat na občasný export. Použijte událost nebo častější inkrementální tok a periodické úplné sladění. Změny nesmějí mezi systémy vzájemně oscilovat. Sledujte stáří skladové informace a pro případ nedostupnosti ERP nastavte vědomé chování: poslední známá hodnota, bezpečnostní rezerva nebo dočasné omezení prodeje podle rizika sortimentu.
- Fyzický, rezervovaný a prodejní sklad
- Pravidla uvolnění po zrušení platby
- Inkrementální změny i kontrolní sladění
- Definované chování při nedostupném ERP
Přenášejte objednávku pouze jednou a úplně
Určete spouštěcí stav: vytvoření, potvrzená platba nebo ruční schválení. Objednávka obsahuje položky, množství, jednotkové ceny, slevy, dopravu, daně, měny, adresy a identifikátory platby; součet musí být shodný na obou stranách. ERP nemá cenu znovu přepočítávat podle aktuálního ceníku, pokud má evidovat historickou transakci. Každý přenos dostane stabilní klíč, který zabrání duplicitě.
Po úspěchu uložte číslo z ERP a čas, po chybě stav a srozumitelnou příčinu. Dočasnou chybu řeší fronta, trvalou nesprávnost údajů člověk. Oprava adresy nebo položky po exportu potřebuje samostatný proces, ne tichý přepis. Stavy z ERP mapujte pouze tehdy, když mají význam pro zákazníka nebo provoz. Fakturu, tracking a storno přenášejte jako samostatné události s vlastní idempotencí.
Zaveďte pozorovatelnost a bezpečnost
Dashboard má ukázat poslední úspěšnou synchronizaci, počet čekajících a chybných záznamů, stáří nejstarší zprávy a rozdíly při sesouhlasení. Korelační ID propojí objednávku s logem na obou stranách. Upozornění potřebuje konkrétního vlastníka a pokyn, co zkontrolovat. „HTTP 500“ samo o sobě pracovníkovi skladu nepomůže; administrace má chybu bezpečně přeložit na chybějící SKU, neznámou dopravu nebo nedostupný systém.
API účty mají minimální oprávnění a oddělené klíče pro staging a produkci. Tajné údaje nepatří do repozitáře, e-mailu ani na snímky obrazovky. Přenášejte pouze potřebné zákaznické údaje a logy redigujte. U veřejného webhooku ověřujte podpis, čas a ochranu proti opakování. Dohodněte mezi dodavateli obou systémů odpovědnost za dostupnost, změny schématu, uchovávání dat a incidenty.
- Korelační ID napříč systémy
- Viditelná fronta a srozumitelné chyby
- Minimální práva a bezpečná tajemství
- Vlastník incidentu a změny kontraktu
Nasazujte přes vzorek a paralelní kontrolu
Nejprve otestujte reprezentativní produkty: jednoduchý, variantní, zlevněný, vyprodaný, neobvykle těžký a s chybějícím údajem. Poté projděte objednávky s různými platbami, dopravou, kupónem, refundací a stornem. Ověřte duplicitní událost, výpadek a obnovení. Testovací ERP nesmí posílat reálné doklady či skladové pohyby bez jasného oddělení. Výsledky porovnávejte po polích, nejen podle počtu záznamů.
Při migraci nejprve spusťte omezenou skupinu nebo paralelní kontrolu proti stávajícímu procesu. Definujte hranici přijatelných rozdílů a podmínky pro návrat. Po produkčním spuštění dočasně kontrolujte každou chybu a pravidelně slaďujte součty. Teprve po stabilizaci vypněte starý ruční tok. Dokumentace má zahrnovat mapování, spouštěče, fronty, kontakty i postup bezpečného opakování.
Časté dotazy
Jak často synchronizovat sklad s ERP?
Záleží na tempu prodeje, riziku vyprodání a možnostech API. Tok událostí může změnu přenést rychle, pravidelné slaďování zachytí výpadky. Frekvenci stanovte podle přijatelného stáří skladové informace, nikoli podle univerzálního intervalu.
Co když produkt nemá stejné ID v obou systémech?
Vytvořte mapování a ukládejte externí stabilní ID u produktu nebo varianty. Název není spolehlivý klíč. Při chybějícím nebo duplicitním identifikátoru import pro daný záznam zastavte a vyžádejte opravu.
Může ERP integrace fungovat bez monitoringu?
Technicky může chvíli běžet, ale tichá chyba se odhalí pozdě. Monitoring fronty, posledního úspěchu a datových rozdílů je součástí spolehlivého provozu, zejména když integrace ovlivňuje objednávky, sklad nebo doklady.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
