Subiekt, Optima, Comarch XL, enova365: jak połączyć ERP z WooCommerce

„Czy WooCommerce dogada się z naszym Subiektem?” Odpowiedź prawie zawsze brzmi: tak. Ważniejsze jest pytanie następne: jak dokładnie, przy Twoim systemie, licencji i serwerze. Subiekt, Optima i enova365 dochodzą do tego samego celu, czyli produktów, stanów i zamówień bez przepisywania, ale każdy inną drogą i z innymi pułapkami.

Ten artykuł idzie system po systemie. Ogólne zasady (jedno źródło prawdy, kolejka, od czego zależy cena) opisujemy w przewodniku po integracji WooCommerce z ERP, a przebieg projektu od researchu do startu w tekście jak projektujemy integracje ERP. Tutaj zostajemy przy samych systemach i przy problemach, które w praktyce zabierają najwięcej czasu.

Dwie drogi: gotowy connector albo integracja przez API

• Gotowy connector (middleware). Program albo usługa między sklepem a ERP, która przenosi standardowe dane: produkty, stany, zamówienia. Szybki start, licencja lub abonament i funkcje ograniczone do tego, co przewidział producent.
• Integracja przez API. Własny kod, który rozmawia z interfejsem programistycznym ERP (API, SDK albo usługą sieciową). Więcej pracy na początku, za to integracja dopasowuje się do Twoich pól, cenników i statusów.

Czasem dochodzi trzecia droga: wymiana plików XML według harmonogramu. Równie ważne jest, gdzie działa ERP. System w chmurze jest dostępny dla sklepu o każdej porze, w granicach limitów producenta. ERP na serwerze w biurze zwykle nie jest widoczny z internetu, więc w tej samej sieci musi działać connector albo usługa pośrednicząca, a komputer musi być włączony. „Wyłączamy serwer po pracy” oznacza zamówienia czekające do rana.

Subiekt GT i WooCommerce: Sfera i komputer, który musi działać

Subiekt GT nie ma internetowego API. Programy z zewnątrz korzystają z niego przez Sferę dla Subiekta GT, płatny dodatek InsERT oparty na COM i OLE Automation. InsERT sam podaje obsługę zamówień ze sklepu internetowego jako przykład jej zastosowania. Licencja Sfery dla Subiekta jest jednostanowiskowa, a system działa na Windowsie z bazą Microsoft SQL Server, zwykle na serwerze lub komputerze w firmie.

I connector, i własna integracja potrzebują więc programu na tym komputerze, który przez Sferę czyta towary i stany, zapisuje zamówienia, a ze sklepem rozmawia przez internet. Subiekta GT łączyliśmy z WooCommerce m.in. przez SubSync firmy RTNET (integratory.pl): to program instalowany przy Subiekcie, który wymaga aktywnej Sfery i wymienia dane w tle co kilka minut.

Uwaga na przyszłość: GT wciąż dostaje aktualizacje (wersja 1.90 z 23 października 2026), ale InsERT wyraźnie zachęca do przejścia na nexo PRO. Jeśli przesiadka jest w planach, lepiej zrobić ją przed integracją niż zaraz po niej.

Czy Subiekta GT da się połączyć z WooCommerce bez Sfery?

Do automatycznego zapisywania zamówień w Subiekcie Sfera jest w praktyce potrzebna: wymagają jej popularne connectory i to przez nią InsERT przewiduje rozszerzenia programu. Bez niej zostaje import plików EDI++ albo nieoficjalne obejścia, których nie polecamy.

Subiekt nexo i nexo PRO: Sfera w wersji PRO

W linii nexo Sfera należy do rozwiązań wersji PRO, z dokumentacją w nexo SDK dla .NET, więc przy integracji przez własny kod w praktyce potrzebny jest Subiekt nexo PRO. Płatny moduł Sfera PRO+ (od 450 zł netto za stanowisko) dodaje Sferę zdarzeniową, która reaguje na operacje wykonywane w programie. Wymagania są podobne jak w GT: Windows i SQL Server, czyli znowu komputer, który musi działać. Gotowe connectory do nexo PRO też istnieją, m.in. w rodzinie SubSync.

Comarch ERP Optima: e-Sklep, XML albo connector

W publicznych materiałach Comarch nie znajdziesz dokumentacji API Optimy w stylu systemów chmurowych. Oficjalne drogi to własny sklep producenta, Comarch e-Sklep, oraz wymiana plików XML w ramach pracy rozproszonej, z której korzystają aplikacje partnerów. Synchronizacja z e-Sklepem działa przez usługę na serwerze, na którym zainstalowana jest Optima.

Do WooCommerce prowadzą connectory firm zewnętrznych (bezpośrednio albo przez Base, dawny BaseLinker) lub integracja szyta na miarę. Optimę łączyliśmy z WooCommerce. Uwaga na wariant w Chmurze Comarch, gdzie pracuje się przez pulpit zdalny lub aplikację: sposób podłączenia integracji warto wtedy ustalić z Comarch albo partnerem jeszcze przed wyceną.

Comarch ERP XL i WooCommerce: XL API, a w wersji Web REST

Comarch ERP XL może pracować jako serwer aplikacji: kilkadziesiąt funkcji API znajduje się w bibliotece CDN_API.DLL instalowanej razem z systemem. To interfejs dla programów w sieci firmy, z kluczem HASP i bazą zarejestrowaną w Windowsie, a nie usługa, z którą sklep połączy się wprost przez internet. Comarch ERP XL Web ma już REST API i jest przygotowany do chmury, ale Comarch rozszerza jego zakres etapami, więc trzeba sprawdzić, co działa w danej wersji. XL współpracuje też z Comarch e-Sklep. Jeśli Twoja instalacja ma dostępne API albo connector, możemy z nim pracować.

enova365: WebAPI i konektor producenta

Tu jest najprościej. Soneta oferuje moduł WebAPI z interfejsem REST i autoryzacją JWT oraz moduł Integrator (REST i SOAP, XML i JSON). enova365 działa w chmurze albo na własnym serwerze, z możliwością przejścia między wariantami. Producent ma też e-Sklepy Konektor, który obsługuje WooCommerce: wysyła karty towarów ze zdjęciami i stanami, pobiera zamówienia i przesyła tylko zmiany. Konektor pokryje typowy obieg, WebAPI przyda się przy cennikach dla kontrahentów czy kilku sklepach.

Pohoda (Stormware): XML, mServer i zdjęcia

Czeska Pohoda wymienia dane przez XML: import i eksport plików albo POHODA mServer, serwer HTTP wbudowany w program, który przyjmuje żądania XML i odsyła odpowiedzi. Działa tylko przy uruchomionej Pohodzie, a Stormware nie zaleca trzymania go włączonego bez przerwy ani jako usługi Windows, tylko start i stop według harmonogramu. Synchronizacja odbywa się więc w zaplanowanych oknach, a nie w czasie rzeczywistym.

Z Pohodą łączyliśmy WooCommerce i najwięcej pracy kosztowały zdjęcia produktów. Powód widać w specyfikacji XML: przy towarze przekazuje się tylko nazwę pliku, a sam plik musi już leżeć w folderze obrazków firmy na komputerze z Pohodą. Zdjęcia trzeba więc przenosić osobnym kanałem i pilnować zgodności nazw po obu stronach.

Symfonia, programy do faktur i Base

Symfonia ERP Handel udostępnia WebAPI: usługę opartą na REST, z osobną licencją. Żeby zewnętrzna platforma mogła się z nią łączyć, adres WebAPI musi być publiczny, dostępny spoza sieci firmy. Symfonia ma też własny integrator e-commerce i wśród obsługiwanych platform wymienia WooCommerce.

wFirma i Fakturownia działają w chmurze i mają publiczne API, więc problem komputera w biurze tu nie istnieje: sklep sprzedaje, program wystawia faktury.

Base (dawny BaseLinker) bywa pośrednikiem: sklep łączy się z Base, a Base z ERP, np. przez Base Bridge dla Subiekta GT i nexo. Przy Subiekcie GT Base Bridge też wymaga aktywnej Sfery i działającego komputera (producent radzi wyłączyć usypianie). Wygodne przy wielu kanałach sprzedaży, ale to kolejne ogniwo do mapowania i szukania błędów.

Systemy w pigułce

Najtrudniejsze w praktyce: przeprowadzka, mapowanie, weryfikacja, testy

Sam kanał wymiany danych rzadko jest największym kłopotem. Najwięcej pracy i ryzyka siedzi w czterech miejscach.

Przeniesienie istniejącej integracji ze starego sklepu

Często firma ma sklep na innej platformie, od lat połączony z ERP, i przechodzi na WooCommerce. W ERP zostają ślady starej integracji: identyfikatory z poprzedniego sklepu, pola dopisane przez dawny connector, statusy pod stary obieg. Na co uważamy:

• Wspólny klucz. Produkty łączymy po symbolu towaru z ERP zapisanym jako SKU w WooCommerce, a nie po identyfikatorze ze starego sklepu, który po migracji przestaje istnieć.
• Kolejność przełączenia. Stara integracja musi przestać zapisywać do ERP, zanim ruszy nowa. Inaczej to samo zamówienie wpadnie dwa razy, a stany zejdą podwójnie.
• Zamówienia z dnia przełączenia. Opłacone w starym sklepie, a jeszcze niewysłane, trzeba domknąć jednym, ustalonym torem.
• Dane trzymane po swojemu. Atrybuty, opisy czy ścieżki zdjęć zapisane przez stary connector w polach własnych ERP trzeba odnaleźć i przenieść do nowego mapowania.

Mapowanie pól: gdzie dane najczęściej się rozjeżdżają

• Warianty. W WooCommerce to jeden produkt z wariantami, w ERP zwykle osobny towar dla każdego rozmiaru czy koloru. Trzeba ustalić, po czym je grupujemy.
• Stawki VAT. Stawki z ERP (23, 8, 5, 0%, zwolnione) muszą trafić do właściwych klas podatkowych w sklepie, łącznie z dostawą w koszyku z mieszanymi stawkami.
• Zaokrąglenia. WooCommerce może zaokrąglać podatek przy każdej pozycji albo od sumy, a ERP liczy dokument po swojemu. Grosz różnicy potrafi zatrzymać import zamówienia.
• Klient. Osoba prywatna czy firma, NIP, adres do faktury inny niż do wysyłki i sposób rozpoznania kontrahenta, który już jest w ERP.
• Statusy i dokumenty. Który status tworzy zamówienie od klienta, a który fakturę lub paragon, i co się dzieje przy anulowaniu albo zwrocie.
• Zdjęcia i polskie znaki. Zdjęcia w ERP bywają plikami na dysku serwera, a starsze formaty wymiany potrafią zgubić polskie znaki.

Weryfikacja: skąd wiadomo, że dane się zgadzają

„Działa” nie znaczy jeszcze „liczy się poprawnie”. Przed startem porównujemy obie strony na liczbach:

• raport rozbieżności, w którym każdy SKU stoi obok towaru z ERP, ze stanem i ceną po obu stronach;
• zamówienia testowe pokrywające realne przypadki: firma z NIP, osoba prywatna, kod rabatowy, darmowa dostawa, mieszane stawki VAT, wariant, zwrot;
• każdy dokument w ERP sprawdzony z zamówieniem co do grosza, razem z kosztem dostawy;
• przez pierwsze dni po starcie codzienna kontrola stanów i zamówień.

Środowisko testowe także po stronie ERP

Kopia sklepu do testów to standard. Rzadziej pamięta się, że ERP też potrzebuje bezpiecznego miejsca do prób, bo każde zamówienie testowe tworzy w nim prawdziwy dokument. Zależnie od systemu przygotowujemy z klientem:

• kopię bazy ERP albo osobną firmę testową, jeśli licencja na to pozwala;
• drugi magazyn, z którego integracja czyta stany w czasie testów, żeby nie ruszać stanów sprzedażowych;
• produkt testowy, niewidoczny dla klientów, na którym przechodzimy cały obieg zamówienia;
• wyłączone albo testowe wystawianie faktur, bo faktury wysłanej do KSeF nie da się anulować (więcej w artykule KSeF a WooCommerce).

Ile to kosztuje i ile trwa

Gotowy connector to licencja albo abonament, czasem plus moduł po stronie ERP, jak Sfera. To także ograniczony zestaw funkcji: przy prostym katalogu wystarczy, przy własnych polach, cennikach dla kontrahentów i nietypowych statusach zaczyna uwierać. Własną integrację robimy od 3 500 zł netto, a od ustaleń do uruchomienia trwa zwykle 2-4 tygodnie. Od czego zależy cena, piszemy w przewodniku po integracji.

Masz ERP i planujesz sklep na WooCommerce albo przeprowadzkę ze starej platformy? Zobacz, jak robimy integracje z ERP, PIM i CRM, i przykład sklepu B2B Kalvei, który synchronizuje się z ERP w czasie rzeczywistym, sam weryfikuje firmy w czeskim rejestrze ARES i generuje pliki XML dla partnerów handlowych. Potem opisz swój system w formularzu bezpłatnej wyceny, a powiemy wprost, którą drogą warto iść.