Integracje e-commerce B2B - ERP, PIM, hurtownie, płatności

W skrócie

• 1. ERP jest pierwsze. Wszystko inne - PIM, OMS, marketplace - ustawiasz po integracji ERP. Inaczej duplikujesz logikę cen i stanów w dwóch miejscach.
• 2. Synchronizacja w czasie rzeczywistym to mit dla większości B2B. Realne SLA to 5-15 minut na ceny, 1-2 minuty na stany, natychmiast tylko dla rezerwacji w koszyku.
• 3. Middleware vs. bezpośrednio: jeśli masz więcej niż 2 systemy zewnętrzne - middleware. Mniej - bezpośrednio. Granica nie jest filozoficzna, tylko praktyczna (osobny artykuł).
• 4. Najczęstszy błąd: wdrożenie integracji bez kolejek. Pierwsza awaria ERP-a położy ci sklep na 4 godziny.
• 5. Drugi najczęstszy błąd: brak idempotencji. To samo zamówienie wejdzie 3 razy do ERP, klient dostanie 3 faktury, dział księgowości będzie tydzień to czyścić.

Po co właściwie integrować ERP ze sklepem

Najczęstsza odpowiedź, której nie chcę słyszeć: „bo tak się robi". Konkretnie:

1. Stany magazynowe. Sklep B2B pokazuje stany realne, nie „dostępne / niedostępne". Klient widzi na magazynie: 47 szt., w drodze: 800 szt., dostawa 12.06. To dane z ERP/WMS, nie z głowy.

2. Ceny kontraktowe. B2B nie kupuje po cenie z metki. Każdy kontrahent ma swój cennik - czasem 8% rabatu na grupę, czasem stała cena na konkretny indeks, czasem progi ilościowe (od 100 szt. 12 zł, od 500 szt. 11 zł). Ten cennik rodzi się w ERP, sklep go tylko konsumuje. Próba trzymania go równolegle w sklepie kończy się jednym: w piątek po południu klient widzi inną cenę niż w fakturze.

3. Zamówienia. Zamówienie złożone w sklepie musi trafić do ERP - bo z ERP idzie faktura, dokument WZ, paczka. Bez tego dział obsługi przepisuje ręcznie z panelu sklepu do ERP. Widziałem firmy, gdzie 4 osoby robiły to na pełen etat.

4. Limity kredytowe. Klient B2B kupuje na termin. Jeśli przekroczył limit z poprzednich faktur - w ERP jest blokada. Sklep musi tę blokadę respektować, inaczej dostawa idzie do dłużnika.

5. Numery seryjne, partie, daty ważności. Branże regulowane (chemia, farmacja, motoryzacja) - sklep nie sprzedaje produktu, sprzedaje konkretny egzemplarz z partii X o ważności do Y. To wszystko z ERP/WMS.

Każdy z tych pięciu punktów to osobny przepływ danych. I każdy może być realtime, batch, push, pull. Cztery razy pięć to dwadzieścia kombinacji do podjęcia.

Mapa systemów wokół sklepu B2B

Zanim wejdziesz w decyzje techniczne - popatrz na całość. Typowy sklep B2B średniej wielkości jest podpięty pod:

• ERP - system głównego rejestru: produkty, ceny, stany, kontrahenci, faktury. SAP S/4HANA, Comarch ERP XL, Subiekt GT, enova365, Microsoft Dynamics. Pełne przewodniki dla każdego z nich.
• PIM - produkt i jego opis (atrybuty, zdjęcia, dokumenty PDF, certyfikaty). Akeneo, Pimcore, czasem moduły wbudowane w platformę. PIM Akeneo w sklepie B2B.
• OMS - orkiestracja zamówień, jeśli sprzedajesz z wielu magazynów / z wielu kanałów. OMS i WMS - kiedy wdrażać.
• WMS - system magazynowy. Zazwyczaj komunikuje się z ERP, nie wprost ze sklepem.
• Marketplace gateway - BaseLinker, Channable. Wysyłka ofert na Allegro, Amazon, eBay. BaseLinker w sklepie B2B.
• EDI - wymiana dokumentów z sieciami handlowymi i większymi kontrahentami (EDIFACT, X12). Integracje z hurtowniami przez EDI.
• PunchOut - bardzo specyficzne dla B2B: katalog sklepu „wkleja się" do systemu zakupowego klienta (SAP Ariba, Coupa). PunchOut: OCI i cXML.
• Płatności B2B - bramki, faktoring, BNPL biznesowe (Płatności z odroczonym terminem, Mondu, Billie, Twisto Biznes). Płatności B2B z terminem.
• Księgowość i fakturowanie - czasem osobny system (Fakturownia, iFirma, integracja z biurem księgowym), czasem moduł ERP.
• Marketing automation, CRM, email - Salesforce, HubSpot, ActiveCampaign. Mniej krytyczne, ale liczne.

Sklep średniej wielkości ma podpięte 6-9 z tej listy. Duży B2B - wszystkie.

Architektura - middleware czy bezpośrednio

Tutaj większość projektów się rozjeżdża. Decyzja brzmi tak: czy każda integracja jest bezpośrednim połączeniem sklep ↔ system zewnętrzny, czy między nimi siedzi warstwa pośrednia (middleware, ESB, integration platform).

Bezpośrednio to konfiguracja, w której:

• Sklep ma własny moduł importujący produkty z ERP
• Sklep ma własny moduł eksportujący zamówienia do ERP
• Sklep ma własny moduł rozmawiający z BaseLinkerem
• Każdy moduł ma własny harmonogram, własny error handling, własne logi

Middleware to:

• Jeden serwis pośredni (Node.js, Symfony Messenger, Java/Spring, dedykowane platformy typu MuleSoft, Boomi, n8n)
• Sklep wystawia REST API na siebie samego, middleware z niego czyta i pisze
• ERP wystawia API, middleware z niego czyta i pisze
• Wszystkie transformacje danych (mapowanie pól, formaty, słowniki) są w middleware

Kiedy bezpośrednio: mały sklep (do ~5k SKU), 1-2 systemy zewnętrzne, stabilne API po obu stronach. Wdrożenie tańsze o ~30%, utrzymanie prostsze.

Kiedy middleware: sklep średni i duży (10k+ SKU), 3+ systemy zewnętrzne, lub jakikolwiek system zewnętrzny ma niestabilne API (np. starsze instalacje Comarch XL, które potrafią mieć timeout 5 minut przy synchronizacji 80k indeksów). Middleware kosztuje więcej w dniu zero - i ratuje skórę w roku drugim, gdy dochodzi piąta integracja.

Pełna analiza decyzji: Middleware vs. integracje bezpośrednie.

Co się synchronizuje, jak często, w którą stronę

Najczęstszy błąd na etapie planowania - założenie, że „wszystko w czasie rzeczywistym". Realnie to wygląda tak:

Dane	Kierunek	Częstotliwość	Krytyczność
Produkty (podstawowe atrybuty)	ERP → sklep	1 × dziennie (noc)	niska
Ceny kontraktowe	ERP → sklep	co 5-15 min	wysoka
Stany magazynowe	ERP/WMS → sklep	co 1-5 min	wysoka
Rezerwacja w koszyku	sklep → ERP (lub blokada lokalna)	realtime	krytyczna
Zamówienie	sklep → ERP	realtime + retry	krytyczna
Status zamówienia	ERP → sklep	co 5 min	średnia
Faktura PDF	ERP → sklep	po wygenerowaniu	średnia
Numery przesyłek	ERP/WMS → sklep	po wysyłce	średnia
Płatności i salda	ERP → sklep	co 15 min	wysoka

Realtime nie znaczy „w 100 ms". W praktyce B2B realtime to „do 30 sekund". I nawet to wymaga kolejek (RabbitMQ, Redis Streams, AWS SQS) z mechanizmem retry.

Jeśli ktoś sprzedaje ci „pełną synchronizację w czasie rzeczywistym dwustronną" - pytaj o SLA i co się dzieje, gdy ERP padnie na 2 godziny. Większość vendorów odpowiada wtedy „to się nie zdarza". Zdarza się. Bardzo regularnie.

Kolejność wdrażania (mocna teza)

Z dziesięciu projektów które robiłem, w siedmiu klient chciał wdrożyć wszystko równolegle. W żadnym to się nie udało. Sekwencja, która działa:

Etap 1 - ERP ↔ sklep, produkty + stany + ceny. Pierwsze 2-3 miesiące. Bez tego nic nie ma sensu.

Etap 2 - Sklep → ERP, zamówienia. Kolejny miesiąc. Zawsze z idempotencją (każde zamówienie ma unikalny external_id, ponowne wysłanie go nie tworzy duplikatu w ERP).

Etap 3 - ERP → sklep, status + faktury + przesyłki. Tu klienci najczęściej dopytują, bo to widoczne dla ich klientów.

Etap 4 - PIM (jeśli potrzebny). Wdrażasz go gdy bazowy sklep już sprzedaje. Inaczej każda zmiana atrybutu produktu wymaga decyzji „a czy to z PIM czy z ERP".

Etap 5 - Marketplace (BaseLinker), płatności B2B z terminem, EDI. W kolejności zależnej od businessu.

Etap 6 - PunchOut, OMS, advanced workflow. Tylko gdy bazowe procesy działają miesiącami stabilnie.

Próba zrobienia tego równolegle = sklep przeszedł na produkcję, ERP wysyła zamówienia w pętli (bo brak idempotencji), BaseLinker nadpisuje stany z opóźnieniem, klienci kupują towar, którego nie ma. To realny scenariusz, widziałem go u trzech klientów.

Idempotencja, retry, kolejki - must-have

Trzy pojęcia, które decydują czy integracja przeżyje pierwszy rok.

Idempotencja. Każde zdarzenie (zamówienie, aktualizacja stanu, nowy produkt) ma unikalny identyfikator. Wysłanie go drugi raz nie powoduje drugiego skutku. Brzmi banalnie, w praktyce większość integracji z lat 2015-2020 to ma źle. Skutek: po awarii kolejki, gdy retryują się 200 zamówień, w ERP pojawia się 600.

Retry z exponential backoff. Jeśli ERP nie odpowiada - nie próbujesz natychmiast, próbujesz po 1 sekundzie. Potem po 2, 4, 8, 16. Po dziesięciu próbach (~17 minut) - wrzucasz do dead letter queue i alarm na pager. Bez exp backoff zrobisz sobie DDoS na własny ERP.

Kolejki. Wszystko co nie jest synchronicznym wymogiem koszyka - przez kolejkę. RabbitMQ, Redis Streams, AWS SQS, Kafka jeśli skala. Sklep nie czeka aż ERP odpowie - wrzuca zdarzenie do kolejki, kolejka je dostarcza, gdy ERP jest gotowy.

Kolejki RabbitMQ i Redis w e-commerce - szczegółowo, z konfiguracjami.

Co kosztuje, czego się nie wycenia

W ofertach wdrożenia widzisz koszt integracji. Czego nie widzisz:

• Mapowanie słowników. ERP ma 200 kategorii, sklep ma 80, ich relacja nie jest 1:1. Ktoś musi to ręcznie zmapować. 40-80 godzin pracy.
• Atrybuty produktów. ERP trzyma kilka kluczowych, sklep potrzebuje 30 (do filtrowania w sklepie). Skąd brakujące? PIM, ręczne uzupełnianie, lub przepisanie z PDF kart katalogowych.
• Zdjęcia. ERP zazwyczaj ich nie ma. Skąd? FTP klienta? CDN? Folder Google Drive? Każda opcja to osobna integracja.
• Konwersje jednostek. ERP w kilogramach, sklep w sztukach. Albo w opakowaniach (karton = 24 szt.). Logika konwersji rośnie aż do 200 linii kodu na klienta.
• Walidacje. „Klient z grupy X nie może kupować produktu z kategorii Y" - to nie jest standard. To custom logic, którą piszesz w sklepie albo w middleware.
• Migracja danych historycznych. Stare zamówienia z poprzedniego sklepu. Stary cennik dla klientów którzy zostali. To osobny projekt.

Realny koszt integracji ERP-sklep w pełnej skali (80k SKU, 200 klientów, cenniki kontraktowe, zamówienia w obie strony) to 120-300 tysięcy złotych w wdrożeniu i 20-40% tej kwoty rocznie w utrzymaniu. Jeśli ktoś wycenia ci to na 30 tys. - albo nie wycenił połowy, albo to nie B2B.

Typowe systemy ERP i ich specyfika

Krótkie spojrzenie na cztery najczęstsze w Polsce. Każdy ma osobną stronę z technicznym przewodnikiem.

SAP S/4HANA. Najpoważniejszy, najdroższy, najlepiej udokumentowany. API: REST OData, IDoc, SAP PI/PO jako middleware. Wdrożenie integracji 4-6 miesięcy. Klienci to korporacje, hurtownie z >50 M zł obrotu. Integracja z SAP S/4HANA.

Comarch ERP XL. Najczęstszy w polskim B2B średniego segmentu. API: WebService SOAP (klasyczny) lub REST od XL 2021+. Wdrożenia długie, bo XL pozwala na bardzo dużą customizację po stronie ERP - czasem łatwiej coś zmienić w XL niż w sklepie. Integracja z Comarch ERP XL.

Subiekt GT. Polski klasyk dla mniejszych firm. API przez Sferę (dedykowane SDK, COM/.NET). Synchronizacja zazwyczaj batchowa, real-time trudniejszy. Integracja z Subiekt GT.

enova365. REST API, dobrze udokumentowane, modułowe. Najbardziej „nowoczesny" z polskich. Wdrożenia szybsze. Integracja z enova365.

Antywzorce - czego nie robić

Antywzorzec 1: Synchronizacja przez plik CSV na FTP, raz na dobę. Tak, w 2026 widziałem to u dużego klienta. Cennik się aktualizuje raz na dobę, klient widzi wczorajszą cenę przez 23 godziny. Wystarczyło dodać dwie kolumny w fakturze i wystawić REST.

Antywzorzec 2: Brak monitoringu integracji. Sklep „działa", więc ok. Po 3 tygodniach okazuje się, że synchronizacja stanów leci na 30% błędów, klienci kupują produkty których nie ma. Monitoring (Sentry, Datadog, własny dashboard z metrykami kolejek) jest częścią integracji, nie dodatkiem.

Antywzorzec 3: Bezpośrednie SQL-e do bazy ERP. Czasem ktoś, kogo tu nie wymienię, podpina sklep wprost do bazy MS SQL Comarcha. Działa rok. Potem aktualizacja XL, schemat się zmienia, sklep się wywala. Nigdy nie integruj się przez bazę. Tylko przez API.

Antywzorzec 4: Zlewanie warstw transformacji w kontroler PHP sklepu. „Mapowanie danych" w kontrolerze ma 800 linii i nikt nie wie którego klienta dotyczy która gałąź ifów. Refaktor to potem 3 miesiące. Transformacje robisz w middleware albo w dedykowanym serwisie.

Antywzorzec 5: Wszystkie integracje jednym kontem API w ERP. Awaria jednego procesu psuje statystyki wszystkich. Każdy proces (produkty, ceny, zamówienia) - osobne konto API z osobnymi limitami.

Bezpieczeństwo integracji

Krótko, bo to temat na osobny artykuł, ale must-have:

• API ERP nigdy nie wystawione publicznie. VPN, IP whitelist, mTLS - wybierz jedno.
• Klucze API w secret managerze (Vault, AWS Secrets Manager, Doppler) - nigdy w .env w repo.
• Webhooki z ERP do sklepu - podpisywane (HMAC SHA-256 z sekretem). Bez tego ktoś z internetu może puścić ci fake'owe zamówienie.
• Rate limiting po stronie sklepu - żeby kompromitacja ERP nie pociągnęła sklepu.
• Logi integracji bez danych osobowych i danych finansowych (lub z maskowaniem).

FAQ

Czy mogę zintegrować Magento z Comarch XL bez middleware? Tak, do około 5k SKU i 1-2 systemów zewnętrznych poza ERP. Powyżej - middleware ratuje skórę. Zobacz middleware vs. bezpośrednio.

Ile trwa integracja sklepu z ERP? Realnie 3-6 miesięcy do produkcji dla pełnego scope (produkty, ceny, stany, zamówienia, faktury, statusy). Pojedynczy przepływ - 4-6 tygodni.

Czy BaseLinker zastąpi mi pełną integrację ERP? Nie. BaseLinker to gateway między sklepem a marketplace'ami i częściowo magazynem. Nie zastępuje synchronizacji cenników kontraktowych B2B, limitów kredytowych, dokumentów ERP. BaseLinker w sklepie B2B.

Co z synchronizacją realtime przy 200 000 SKU? Realtime dla produktów - nie. Realtime dla stanów konkretnego produktu, którego klient właśnie patrzy - tak (pull on-demand z ERP, cache 30 s). Globalna synchronizacja 200k indeksów to batch.

Czy PIM jest konieczny? Nie zawsze. PIM ma sens gdy: masz 10k+ produktów, atrybutów do filtrowania jest ponad 20, wiele osób edytuje opisy równolegle, lub sprzedajesz w wielu krajach (tłumaczenia). PIM Akeneo w sklepie B2B.

Co dalej

Wybierz ścieżkę:

• Mam już sklep i chcę wdrożyć integrację z ERP → zacznij od strony przewodniej swojego ERP: SAP, Comarch XL, Subiekt GT, enova365.
• Planuję nowy sklep i chcę zaprojektować integracje od zera → Architektura dużych sklepów + Jak wybrać platformę.
• Chcę porozmawiać o konkretnej integracji → Kontakt.