Integracja ERP ze sklepem internetowym — ERP, WMS i CRM bez chaosu w danych

Większość chaosu w integracji ERP ze sklepem internetowym nie bierze się z braku technologii, tylko z braku jednej, uzgodnionej odpowiedzi na pytanie: który system jest źródłem prawdy dla tego pola? Jeśli cena żyje jednocześnie w ERP i w sklepie, a obie wersje mogą zmieniać się niezależnie, prędzej czy później się rozjadą. Poniżej rozdzielamy ERP, WMS i CRM jako trzech właścicieli danych, pokazujemy, co polskie systemy ERP oferują w integracji ze sklepem, i porównujemy trzy architektury, spośród których wybierasz, zanim powstanie pierwsza linia kodu integracji.

ERP, WMS, CRM — co każdy z nich naprawdę robi

ERP (Enterprise Resource Planning) to system, w którym żyją ceny, dokumenty sprzedaży (faktury) i zwykle podstawowa karta kontrahenta. W małej i średniej firmie często istniał przed sklepem internetowym, bo wymagały go księgowość i sprzedaż offline.

WMS (Warehouse Management System) odpowiada za to, co fizycznie dzieje się w magazynie, a nie tylko za liczbę „na stanie”. Comarch, producent jednego z polskich systemów WMS, definiuje go tak: „Warehouse Management System (WMS) to kompleksowe rozwiązanie do koordynowania prac i zleceń magazynowych”, a „zadaniem systemów WMS jest usprawnienie wszystkich procesów, które zachodzą w wielopoziomowych magazynach” (comarch.pl/erp/wms, odczyt 2026-10-01). To definicja producenta, ale pierwsze zdanie opisuje całą kategorię, zanim strona przejdzie do własnego produktu. W praktyce WMS ma sens, gdy magazyn ma więcej niż jedną lokalizację lub strefę składowania albo gdy liczba SKU i rotacja sprawiają, że ręczne liczenie stanu zawodzi.

CRM (Customer Relationship Management) przechowuje historię kontaktu z klientem, zgody marketingowe i segmentację — nie samą transakcję (to rola ERP), lecz relację wokół niej. W małym sklepie tę funkcję pełni często ERP albo karta klienta w platformie sklepowej. Dedykowany CRM pojawia się, gdy obsługa i marketing potrzebują więcej niż historii zamówień: zapisu, na co i kiedy klient wyraził zgodę, albo segmentacji po zachowaniu zakupowym.

Trzy role nie oznaczają trzech licencji od trzech dostawców. Część polskich systemów ERP ma wbudowany moduł WMS albo CRM w tej samej licencji. O tym, czy wystarczy moduł wbudowany, czy potrzebny jest osobny system, decyduje to, czy moduł pokrywa Twoją skalę, a nie sama dostępność opcji.

W najmniejszej firmie ERP pełni wszystkie trzy role naraz: stan prowadzony w module magazynowym ERP, karta klienta jako zwykły kontakt w tym samym systemie. To nie jest błąd projektowy. Problem pojawia się, gdy skala przerasta możliwości jednego systemu — setki SKU w kilku lokalizacjach, tysiące kontaktów z historią szerszą niż zamówienia. Wtedy dedykowany WMS albo CRM ma uzasadnienie, zamiast być kupowany „na wszelki wypadek”. Warunek jest jeden: każde pole synchronizowane między sklepem a resztą systemów (stan, cena, karta klienta) ma jednego właściciela, nawet jeśli tymczasowo jest nim ERP, który robi za trzech.

Polskie ERP i integracja ze sklepem internetowym

InsERT. Subiekt GT ma dedykowaną warstwę integracyjną — Sferę, opisaną jako „mechanizm, który umożliwia pisanie rozszerzeń korzystających z wewnętrznych algorytmów systemu Subiekt GT”, zbudowaną na technologiach COM i OLE Automation; wśród przykładów zastosowań InsERT wymienia wprost „obsługiwanie zamówień składanych w sklepie internetowym” (insert.com.pl, Subiekt GT Sfera, odczyt 2026-10-05). InsERT sprzedaje ją jako osobny wariant — Subiekt GT Sfera, czyli Subiekt GT rozbudowany o ten mechanizm — za 2090 zł netto, wobec 1045 zł netto za sam Subiekt GT (ceny ze stron produktów, odczyt 2026-10-05). W nowszej generacji odpowiednik jest tylko w wyższej wersji: „Sfera dla Subiekta nexo” figuruje wśród rozwiązań „dostępnych w wersji PRO”, z dokumentacją techniczną w nexo SDK (insert.com.pl, Subiekt nexo PRO, odczyt 2026-10-01). Cen nexo strony produktów nie podają w treści. Subiekt 123 InsERT opisuje na stronie oferty dla biur rachunkowych jako system „bez zarządzania magazynem” (choć serwis subiekt123.pl oferuje magazyn jako moduł dodatkowy), a Sfery przy nim nie wymienia. Wniosek: jeśli integrację ze sklepem chcesz oprzeć na Sferze, szukaj jej w Subiekcie GT Sfera albo w Subiekcie nexo PRO, nie w Subiekcie 123.

Comarch. Comarch e-Sklep jest według producenta „rozwiązaniem w pełni zintegrowanym z systemami klasy ERP”, a cennik wymienia integrację z Comarch ERP Betterfly, Optima, XL i Altum (comarchesklep.pl i comarchesklep.pl/cennik, odczyt 2026-10-05). Integracja z ERP to tu tylko jedna z warstw: platforma deklaruje też ponad 30 integracji płatności (m.in. Comarch Pay, PayU, BLIK, Przelewy24, PayPal), integracje wysyłkowe (m.in. Paczkomaty InPost, DHL, UPS), darmową integrację z Allegro i przypomnienia o porzuconym koszyku. Dla magazynu Comarch ERP XL jest osobny moduł, Comarch WMS Magazynier, z „automatyzacją procesów magazynowych dzięki współpracy z drukarkami etykiet, czytnikami kodów oraz kolektorami danych” (comarch.pl/erp/xl/gospodarka-magazynowa, odczyt 2026-10-01). Ceny e-Sklepu są publiczne — pakiet Standard „już od 150 zł/mies.”, Enterprise od 599 zł, B2B od 899 zł miesięcznie (cennik nie precyzuje, czy to kwoty netto). Cen Comarch WMS strony produktu nie podają; ten sam model — wycena przez partnera wdrożeniowego — powtarza się przy enova365.

enova365. Integruje się natywnie z „Allegro, Shoper, PrestaShop, Magento, WooCommerce i Base” i wymienia konkretne funkcje: automatyczne pobieranie zamówień z e-sklepów, automatyczną aktualizację stanów magazynowych w sklepach, automatyczne zakładanie kart kontrahentów, aktualizację statusów zamówień w e-sklepie, wysyłanie numerów listów przewozowych do klientów i cykliczną synchronizację przez harmonogram zadań (enova.pl/branze/handel-i-e-commerce, odczyt 2026-10-01). Ta lista dobrze pokazuje, co poza stanem i ceną wchodzi w integrację ERP ze sklepem: obieg zamówienia w obie strony i karta kontrahenta, która w enova365 żyje w tym samym systemie co reszta ERP. Ceny modułu integracyjnego producent nie publikuje — strona prowadzi do formularza z prośbą o prezentację lub wycenę.

Symfonia. Integrator Symfonia Handel z e-commerce ma wspierać „dwukierunkową wymianę danych” — zamówień, danych produktowych i magazynowych w czasie rzeczywistym, danych płatności i automatycznego generowania faktur — i komunikuje się „przez API (broker)” (symfonia.pl/oprogramowanie/integrator-e-commerce, odczyt 2026-10-01). Integrator należy do linii Symfonia Handel, nie do całej rodziny produktów Symfonia. Strona nie wymienia obsługiwanych platform sklepowych ani ceny.

WMS jako usługa SaaS z publiczną ceną. W przeciwieństwie do systemów WMS sprzedawanych przez partnerów bez jawnej ceny, Sellasist — polski integrator zamówień — publikuje ceny modułów magazynowych. Mini WMS (tryby zbierania i pakowania w aplikacji) to „Dodatek płatny: 50 zł netto za użytkownika / miesiąc”, a pełny Sellasist WMS z lokalizacjami i wirtualnymi regałami — „od 199 zł za użytkownika / miesiąc”; wdrożenie prowadzą wyłącznie specjaliści Sellasist albo certyfikowani wdrożeniowcy (sellasist.pl/cennik, odczyt 2026-10-05). To punkt odniesienia przy porównywaniu kosztu WMS, a nie dowód, że taki moduł zastąpi dedykowany system w dużym magazynie.

Kontrakt danych — kto jest źródłem prawdy dla czego

Zanim wybierzesz technologię integracji, ustal dla każdego pola obecnego w więcej niż jednym systemie, który system wygrywa, gdy wersje się różnią. To jest kontrakt danych: nie dokument prawny, tylko ustalenie, do którego wracasz przy każdym sporze.

Jeśli stan magazynowy ma dwóch właścicieli naraz (WMS i ERP aktualizowane niezależnie), nie masz kontraktu danych, tylko dwa źródła, które rozjadą się przy każdej ręcznej korekcie w jednym z nich. Rozwiązanie jest decyzyjne, nie techniczne: jeden system jest właścicielem pola, drugi je tylko odczytuje.

Tak wygląda to w praktyce. Magazynier po inwentaryzacji koryguje stan w WMS, ale integracja synchronizuje stan tylko w jedną stronę, z ERP do WMS. WMS pokazuje poprawiony stan, ERP i sklep — starą liczbę, a następna synchronizacja nadpisuje korektę. Z zewnątrz wygląda to na awarię integracji, choć żaden z systemów nie ma błędu: kierunek przepływu danych po prostu nie został jednoznacznie ustalony.

Jak spisać kontrakt danych przed integracją

Kontrakt danych zmieści się w jednym arkuszu, o ile odpowiesz w nim na te same pytania dla każdego pola. Nie potrzebujesz do tego wykonawcy ani narzędzia, tylko osoby, która zna obieg towaru i dokumentów w firmie.

1. Spisz pola, które istnieją w więcej niż jednym systemie — stan, cena (z podziałem na cennik bazowy i promocje), karta klienta, status zamówienia, numer przesyłki, dokumenty.
2. Przypisz każdemu polu jednego właściciela — system, w którym wolno je zmieniać. Pozostałe systemy tylko je odczytują.
3. Ustal kierunek i moment synchronizacji — z którego systemu do którego i kiedy: przy każdej zmianie, cyklicznie czy na żądanie. Przykład z poprzedniej sekcji pokazuje, co się dzieje, gdy kierunek jest nieustalony.
4. Zapisz regułę na konflikt — co robi integracja, gdy wersje się różnią: nadpisuje danymi właściciela, wstrzymuje zamówienie czy zgłasza problem człowiekowi.
5. Wyznacz osobę, która dostaje informację o błędzie synchronizacji — bez tego rozjazd wychodzi na jaw dopiero w reklamacji klienta.

Taki arkusz to też najlepszy brief dla wykonawcy integracji: zamiast „połączcie sklep z Subiektem” dostaje listę pól, kierunków i reguł, którą może wycenić.

Kolejność wdrożeń — co podłączyć najpierw

W typowej małej i średniej firmie ERP jest pierwszy, a integracja zaczyna się od połączenia sklepu z ERP. ERP zwykle istnieje wcześniej, bo wymagały go księgowość i sprzedaż, zanim w ogóle powstał sklep. Pierwszy konektor sklep ↔ ERP przenosi ceny i podstawowe zamówienia — to samo, co z perspektywy dostawcy towaru opisuje tekst o integracji z hurtownią. WMS dochodzi później, gdy liczba SKU, rotacja albo druga lokalizacja sprawiają, że stan prowadzony w samym ERP przestaje być wiarygodny — to moment, by przenieść „stan” do dedykowanego systemu. CRM dochodzi na końcu, gdy obsługa klienta i marketing potrzebują widoku relacji szerszego niż historia transakcji w ERP.

Odwrócenie tej kolejności — np. wdrożenie CRM przed uporządkowaniem źródła prawdy dla ceny i stanu — zwykle kończy się tym, że nowy system dziedziczy bałagan starych, tylko w nowym interfejsie. CRM zasilany danymi klienta z dwóch niezgodnych źródeł (np. ERP i panelu sklepu aktualizowanych niezależnie) od pierwszego dnia ma dwie wersje tego samego kontaktu, czyli dokładnie ten problem, który miał rozwiązać.

Architektura integracji — konektor, iPaaS czy własne API

Masz trzy drogi i każda ma sens przy innej skali:

• Konektor natywny — gotowa integracja producenta ERP z konkretną platformą (Comarch e-Sklep z Optimą lub XL, integrator Symfonia Handel, natywne połączenia enova365 z Allegro, Shoperem, PrestaShop czy WooCommerce). Najniższy koszt wdrożenia, ale tylko w granicach tego, co przewidział producent. Jeśli Twój proces wymaga pola, którego konektor nie obsługuje, nie masz gdzie go dopisać.
• iPaaS (Integration Platform as a Service) — warstwa pośrednia między systemami zamiast połączeń punkt–punkt. To opcja architektoniczna, a konkretne narzędzia tej kategorii (Zapier, Make, n8n) i ich ceny opisuje tekst o automatyzacji sprzedaży, bo dotyczą raczej zdarzeń i zaoszczędzonego czasu niż architektury danych.
• Własne API — integracja pisana pod Twoje systemy, na warstwie producenta (Sfera InsERT, broker API Symfonii) albo jako osobna usługa z kolejkami zdarzeń. Najwyższy koszt budowy, ale jedyna droga, gdy kontrakt danych wymaga logiki, której nie przewidział żaden gotowy konektor (np. nietypowe reguły cenowe B2B albo rozdział stanu między kilka magazynów).

Sygnałem do przejścia na kolejny poziom zwykle nie jest cena, tylko to, ile razy w miesiącu ręcznie obchodzisz ograniczenie konektora. Jeśli ten sam problem regularnie wymaga eksportu do Excela, poprawki i ponownego importu, konektor natywny przestał wystarczać — niezależnie od tego, czy masz już budżet na integrację.

Który wariant opłaca się przy Twojej liczbie zamówień i integrowanych systemów, policzysz w kalkulatorze TCO e-commerce — koszt konektora natywnego i własnego API rozkładają się w czasie zupełnie inaczej.

KSeF — co się zmienia w obiegu dokumentów

Od 2026 roku faktura B2B z Twojego ERP nie jest już tylko plikiem PDF — przechodzi przez Krajowy System e-Faktur. Obowiązek wszedł etapami: „od 1 lutego 2026 r. dla firm, które w 2024 r. miały sprzedaż powyżej 200 mln zł (z VAT), od 1 kwietnia 2026 r. dla pozostałych”, z okresem przejściowym — „do 31 grudnia 2026 r. można jeszcze wystawiać faktury poza KSeF (papierowe lub elektroniczne), jeśli w danym miesiącu suma sprzedaży z VAT na takich fakturach nie przekroczy 10 000 zł” (ksef.podatki.gov.pl, odczyt 2026-10-05). W sklepie internetowym dotyczy to głównie sprzedaży B2B (odbiorcy biznesowi, hurt, marketplace jako kontrahent). Faktury dla konsumentów (B2C) „zarówno przed 1 lutego 2026 r. jak i po tej dacie” pozostają w KSeF dobrowolne, a faktury z kas rejestrujących (w tym paragony z NIP do 450 zł) mogą do 31 grudnia 2026 r. pozostać poza KSeF (ksef.podatki.gov.pl/konsumenci-i-osoby-fizyczne, odczyt 2026-10-05). Oba terminy obowiązku już minęły. Jeśli Twój ERP wystawia faktury B2B do zamówień ze sklepu, a integracja dotąd tego nie uwzględniała, sprawdź, czy ścieżka do KSeF działa — zanim 31 grudnia 2026 r. skończą się wyjątki przejściowe.

Dla kontraktu danych oznacza to jedno: jeśli faktura B2B idzie przez KSeF, ERP jako wystawca musi mieć kompletne i poprawne dane kontrahenta (NIP, adres) w chwili wystawienia, a nie poprawiane po fakcie w innym systemie. KSeF nie jest miejscem, w którym błąd w karcie klienta da się po cichu skorygować, jak w PDF-ie wysłanym mailem.

Jak integracje łączą się z resztą operacji — danymi produktowymi, KPI, automatyzacją i bezpieczeństwem — pokazuje dział operacji e-commerce.