Sklep WooCommerce + ERP — jak to spiąć i czego unikać

Najpierw: czego oczekujesz od integracji?

Zanim pójdziesz dalej, odpowiedz sobie szczerze na 4 pytania — bo "integracja WooCommerce + ERP" to nie jedna rzecz, tylko 4 osobne rzeczy:

1. Sync produktów — czy chcesz, żeby produkty dodawane w ERP automatycznie pojawiały się w sklepie?
2. Sync magazynu — czy stany w sklepie mają na bieżąco odzwierciedlać to, co w ERP?
3. Sync zamówień — czy zamówienia ze sklepu mają lecieć do ERP (jako dokumenty sprzedaży / WZ)?
4. Sync klientów — czy chcesz wspólną bazę kontrahentów?

Każda firma odpowiada inaczej. Sklep z 50 produktami wprowadzanymi raz na rok — sync produktów nie jest potrzebny, wystarczy ręcznie. Sklep z 5000 produktami zmienianymi codziennie — bez sync produktów się nie obejdzie.

Najczęstszy realny zestaw to (2) + (3): magazyn i zamówienia. Reszta opcjonalnie.

Pułapka #1: Brak źródła prawdy

To jest numer 1 wszystkich problemów integracyjnych, jakie widzę. Pytanie brzmi: gdzie jest "ostateczna" wersja produktu / stanu / ceny?

Zły scenariusz: produkt można edytować równolegle w obu systemach. Ktoś zmienia cenę w WooCommerce, ktoś inny zmienia ją w Subiekcie. Sync nadpisuje raz w jedną, raz w drugą stronę. Następnego dnia nikt nie wie, jaka jest "prawdziwa" cena.

Dobre podejście — wybierz jedno miejsce źródłowe dla każdej kategorii danych:

• Produkty (nazwa, opis, atrybuty, ceny katalogowe) — zwykle sklep (bo tam są zdjęcia, SEO, opisy marketingowe, których ERP nie ma)
• Stany magazynowe — zwykle ERP (bo tam fizycznie liczone są przyjęcia, wydania, korekty)
• Ceny "operacyjne" i rabaty B2B — zwykle ERP
• Zamówienia od klientów — startują w sklepie, lecą do ERP jako dokument sprzedaży
• Klienci — to się dzieli (sklep ma kupujących, ERP ma kontrahentów); zwykle sklep jest źródłem dla B2C, ERP dla B2B

Pułapka #2: Identyfikatory produktów

WooCommerce identyfikuje produkty po wewnętrznym ID (autoinkrement w MySQL) lub po SKU (string nadawany przez Ciebie).

Subiekt GT/nexo, Optima — identyfikują po symbolu (kodzie produktu).

Pytanie: czym matchujemy produkt sklepowy z produktem w ERP?

99% wdrożeń, które robię, używa SKU = symbol w ERP. Brzmi banalnie, ale bywa po drodze masakra:

• W sklepie ktoś przez ostatnie 3 lata wpisywał SKU od czapy — "produkt-1", "kosmetyk_x_v2", "TEST".
• W ERP symbole też nie są spójne — niektóre 13-znakowe EAN-y, niektóre 5-literowe skróty, niektóre po polsku, niektóre po angielsku.
• Te same produkty mają RÓŻNE kody w sklepie i w ERP.

Czego unikać: integracji bez wcześniejszej normalizacji kodów. Jeśli zaczniesz sync na śmieciowych SKU, dostaniesz śmieciową bazę. Lepiej spędzić 2–3 dni przed integracją na uporządkowaniu kodów (czasem masowym update), niż potem rok łapać duplikaty.

Drugie pytanie: warianty. WooCommerce ma "produkty wariantowe" (np. T-shirt: rozmiar S/M/L × kolor czarny/biały = 6 wariantów). Subiekt GT też ma cechy, ale logika nie jest 1:1. Każda integracja musi rozwiązać: każdy wariant to osobny produkt w ERP czy jeden produkt z atrybutami?

Pułapka #3: Synchronizacja stanów w czasie rzeczywistym

"Stan ma być zawsze aktualny" — to brzmi rozsądnie. W praktyce jest pole minowe.

Scenariusze, które się rzucają na ścianę:

• Klient kupuje w sklepie ostatnią sztukę. Sklep ją "rezerwuje". W tym samym momencie kasjer w sklepie stacjonarnym też sprzedaje tę sztukę. ERP odejmuje, ale sklep webowy NIE WIE.
• Klient porzuca koszyk. Sklep zarezerwował sztukę. Co się dzieje ze stanem w ERP? Zwykle nic. Co się dzieje za godzinę gdy klient wraca? Sklep wciąż rezerwuje, ERP się nie zgadza.
• ERP robi sync stanów co 5 minut. Klient otwiera produkt, widzi "1 szt. w magazynie". Klika "Kup". W tym czasie ktoś inny już go kupił. Klient płaci za produkt, którego nie ma.

Co działa:

• Częstość sync stanów: dla większości sklepów 5–15 minut wystarcza. Real-time przez webhook tylko jeśli masz hot-products i risk niedoboru.
• Bufor bezpieczeństwa: zwykle ustawiamy regułę "wystawiaj na sklep stan ERP minus 1 lub minus 2". Zabezpiecza przed wyścigiem kasy stacjonarnej z webem.
• Rezerwacja na czas koszyka: standardowa funkcja WooCommerce, ale trzeba ją skonfigurować (15–30 min zwykle).
• Procedura na niedobór: zamiast obiecywać "stan zawsze aktualny", przygotuj plan na sytuację, gdy nie jest. Auto-mail do klienta "Przepraszamy, towar wyprzedany" + zwrot środków + propozycja zamiennika.

Pułapka #4: Statusy zamówień

WooCommerce ma swoje statusy: pending, processing, on-hold, completed, cancelled, refunded. Subiekt ma swoje typy dokumentów: ZK (zamówienie od klienta), FS (faktura sprzedaży), WZ (wydanie zewnętrzne). Optima ma jeszcze inne.

Pytanie: w którym momencie w sklepie powstaje jaki dokument w ERP?

Najczęściej rozsądna ścieżka:

1. WooCommerce: pending → niczego nie generujemy w ERP
2. WooCommerce: processing (klient zapłacił) → tworzymy zamówienie ZK w ERP
3. WooCommerce: zmiana stanu na completed (przy wysyłce) → generujemy WZ i fakturę (lub paragon) w ERP
4. WooCommerce: refunded → generujemy fakturę korygującą w ERP (lub zaznaczamy ręcznie)

Diabelnie ważne: integracja musi być idempotentna. Czyli jeśli WooCommerce z jakiegoś powodu wyśle status completed dwa razy (np. po przejściowym timeoutcie), integracja NIE może wystawić faktury dwa razy. To wymaga pilnowania ID zamówienia po stronie ERP i sprawdzania, czy dokument już istnieje.

Pułapka #5: Klient B2B vs B2C

Sklepy często sprzedają i hurtowo (B2B), i detalicznie (B2C). To są inne reguły:

• B2B płaci z odroczonym terminem (np. 14 dni), B2C płaci od razu
• B2B ma indywidualne rabaty / cenniki, B2C ma cennik katalogowy
• B2B chce fakturę zawsze, B2C — czasem paragon
• B2B ma NIP, B2C zwykle nie
• B2B ma swojego "opiekuna" handlowego w ERP, B2C wpada do zbiorówki

Integracja musi to rozróżnić. Typowy mechanizm: w WooCommerce dwa "role users" (Customer + Wholesale). Każdy widzi inne ceny i inne metody płatności. Sync z ERP rozdziela ich do różnych grup kontrahentów.

Bez tego rozróżnienia kończy się tak, że hurtowy klient płaci detalicznie albo dostaje fakturę z błędnymi danymi.

Jak NIE wdrażać

1. Bez ustalonego źródła prawdy. "Synchronizujemy w obie strony" = chaos w 2 miesiące.
2. Bez normalizacji kodów produktów. Najpierw posprzątaj, potem łącz.
3. Bez testów na kopii. Integracja zamówień bezpośrednio na produkcji = pierwszy klient wystawia 3 faktury zamiast 1.
4. Bez monitoringu. Sync potrafi cicho umrzeć (token wygasł, hasło ERP zmieniono, API rate-limit). Zawsze ustawiam alerty mailowe na błędy.
5. Z gotową wtyczką + zero customu. Gotowe wtyczki (WP Subiekt, WP-Optima, WP-Allegro itp.) działają dla 80% przypadków. Dla pozostałych 20% — własne pole, własna logika cenowa, własny flow VAT — gotowa wtyczka się załamuje. Lepiej od razu zdecydować: gotowiec czy custom.

Co dobrze działa: architektura, którą zwykle proponuję

1. WooCommerce jako frontend sklepu + katalog
2. Pośrednik (Baselinker / Sellasist / własny skrypt na n8n) zbierający zamówienia i pilnujący wymiany
3. ERP jako źródło stanów magazynowych i miejsce wystawiania dokumentów
4. Księgowość (wFirma / Optima u księgowej) — jako odbiorca dokumentów z ERP, nie z integracji bezpośredniej
5. Monitoring przez prosty webhook → Slack / mail → ja dostaję alert gdy coś padło

To jest stack, który dobrze skalować od 30 zamówień miesięcznie do 3000 dziennie. Powyżej tego — zwykle warto myśleć o Magento + customowym middleware.

Wniosek

Integracja WooCommerce z ERP jest możliwa i działa stabilnie u setek polskich sklepów. Ale to nie jest "wtyczka na 5 minut". To projekt na kilka tygodni, w którym analiza biznesu jest ważniejsza niż kod integracji. Większość problemów rodzi się przed pierwszą linijką kodu — w decyzjach: co synchronizujemy, w którą stronę, kiedy, co jest źródłem prawdy. Im więcej czasu na te decyzje, tym mniej godzin na pożarach później.