Integracja WooCommerce z ERP: co naprawdę działa, a co nie

WooCommerce działa świetnie, dopóki nie próbujesz wpiąć w niego systemu ERP, który ma własny model danych, własny rytm pracy i zero dokumentacji po angielsku. W tym momencie pozornie prosty projekt zamienia się w jedno z trudniejszych zadań w całym eCommerce. Nie dlatego, że API jest skomplikowane, tylko dlatego, że dane po obu stronach rzadko się ze sobą zgadzają.

Większość integracji idzie tą samą drogą i wpada w tę samą pułapkę: developer bierze gotową wtyczkę, klika mapowanie pól i ogłasza sukces. Przez pierwsze dwa tygodnie wszystko działa. Potem pojawia się pierwszy nietypowy produkt, pierwszy nieprzewidziany status zamówienia i pierwszy cichy rozjazd stanów magazynowych. W tym artykule rozkładamy na części, co w takim wdrożeniu naprawdę działa, a co tylko wygląda dobrze, dopóki nikt nie patrzy.

Dlaczego to trudniejsze, niż wygląda

Na papierze integracja brzmi banalnie: produkty i stany lecą z ERP do sklepu, zamówienia w drugą stronę. Problem w tym, że ERP i WooCommerce to dwa różne światy, które inaczej rozumieją nawet podstawowe pojęcia. To, co w sklepie jest jednym produktem z wariantami, w ERP bywa kilkoma osobnymi indeksami. Status, który dla sklepu znaczy „opłacone”, w ERP może mieć trzy różne odpowiedniki zależnie od formy płatności.

Te rozbieżności nie są błędem. To naturalna konsekwencja tego, że oba systemy powstały do czego innego. Dlatego integracja nie polega na „połączeniu API”, tylko na pogodzeniu dwóch modeli danych, które nigdy nie były projektowane, żeby ze sobą rozmawiać. I właśnie tu rozstrzyga się, czy wdrożenie przetrwa zderzenie z realnymi danymi.

Pułapka gotowych wtyczek

Gotowe connectory zakładają, że Twój ERP mówi standardowym językiem: zamówienie, produkt, klient, faktura. W rzeczywistości każde wdrożenie Subiekt GT, Comarch ERP XL czy SAP Business One ma własne pola niestandardowe, własny słownik statusów i własne reguły walidacji, których żadna uniwersalna wtyczka nie przewidzi.

Dopóki Twoje dane mieszczą się w schemacie, który wtyczka założyła, jest dobrze. Kłopot zaczyna się przy pierwszym wyjątku, a w danych biznesowych wyjątki są normą, nie rzadkością. Wtedy zaczyna się obklejanie narzędzia hackami: dodatkowe pola, skrypty „na boku”, ręczne korekty. Po kilku miesiącach okazuje się, że rozwiązanie, które miało oszczędzić czas, pochłania go więcej niż napisanie integracji od podstaw, a do tego nikt już nie wie, dlaczego coś działa tak, a nie inaczej.

Co naprawdę działa: jedno źródło prawdy

Najważniejsza decyzja w całej integracji nie jest techniczna, tylko porządkowa: trzeba ustalić, który system jest źródłem prawdy dla danego typu danych. U nas zasada jest prosta i prawie zawsze taka sama. ERP jest źródłem prawdy dla produktów i stanów magazynowych. WooCommerce jest źródłem prawdy dla zamówień. Nigdy odwrotnie.

Ta jedna reguła eliminuje większość konfliktów, zanim w ogóle powstaną. Gdy każdy typ danych ma jednoznacznego właściciela, nie ma sytuacji, w której dwie strony „poprawiają” się nawzajem i nadpisują swoje zmiany. Brzmi nudno, ale to właśnie ten nudny porządek odpowiada za to, że stany się nie rozjeżdżają, a zamówienia nie znikają.

Synchronizacja jednokierunkowa z kolejką

Dla większości klientów budujemy własny mechanizm synchronizacji w PHP zamiast polegać na gotowym connectorze. To prosta, ale solidna konstrukcja: kolejka zadań, jednokierunkowy przepływ danych dla każdego typu i pełny log każdej operacji. Każde zdarzenie wie, skąd przyszło i co ma zrobić, a w razie błędu można je bezpiecznie powtórzyć bez ryzyka, że coś zdublujemy.

Taka architektura ma jeszcze jedną zaletę: jest odporna na chwilowe awarie. Gdy ERP na moment przestaje odpowiadać, zadania czekają w kolejce zamiast ginąć, a po przywróceniu połączenia wszystko domyka się samo. To różnica między integracją, która „zwykle działa”, a taką, na której można polegać w szczycie sprzedaży.

Czego nie da się obejść

Jest jedna rzecz, której żadna technologia nie załatwi za Ciebie: zrozumienia, jak naprawdę wyglądają Twoje dane. Automatyczne mapowanie „pole A równa się pole B” wygląda pięknie na prezentacji, ale rozpada się przy pierwszym wyjątku. A wyjątków w prawdziwym ERP są dziesiątki: historyczne rekordy, nietypowe kategorie, dane wprowadzane latami przez różne osoby według różnych zasad.

Dlatego mapowanie zawsze robimy ręcznie, z klientem, na prawdziwych danych, a nie na wyidealizowanym przykładzie. To mniej efektowne niż „automatyczna integracja w pięć minut”, ale to jedyny sposób, żeby uniknąć cichych błędów, które wychodzą dopiero przy reklamacji klienta albo niezgodności magazynu.

Kiedy gotowa wtyczka naprawdę wystarczy

Uczciwie: nie każdy sklep potrzebuje dedykowanej integracji. Jeśli masz prosty katalog, standardowy ERP w typowej konfiguracji i niewielki wolumen zamówień, gotowy connector może wystarczyć i nie ma sensu przepłacać za rozwiązanie szyte na miarę. Warto tylko wiedzieć, gdzie są jego granice, zanim oprzesz na nim cały proces.

Granica przebiega zwykle tam, gdzie pojawiają się niestandardowe pola, większa skala, wiele kanałów sprzedaży albo nietypowe reguły biznesowe. W tych przypadkach własna integracja nie jest fanaberią, tylko najtańszym długoterminowo wyborem, bo eliminuje godziny ręcznej pracy i ryzyko błędów, których przy rosnącym ruchu nie da się już upilnować.

Twój sklep i ERP nie mówią jednym językiem? Porozmawiajmy, a powiemy wprost, czy w Twoim przypadku wystarczy gotowy connector, czy bardziej opłaca się dedykowana synchronizacja.