Integracje ecommerce: jak połączyć sklep z ERP, żeby dane się nie rozjeżdżały

Zapytaj dwóch dostawców o integracje ecommerce i dostaniesz dwie listy konektorów. Sklep i ERP rozjeżdżają się jednak na ustaleniach: który system ma rację co do ceny, co właściwie znaczy „dostępny", kto zauważy, że nocny import stanął w połowie. Integracja to te ustalenia zapisane w kodzie. Decyzje zapadają przed pierwszą linijką, a rachunek za całość wyznacza potem dostęp do ERP i to, jak wyglądają w nim dane. Przechodzimy przez nie po kolei, na mechanizmach z wdrożeń, które zbudowaliśmy.

Czym jest integracja sklepu internetowego z ERP

Integracje ecommerce to ustalone przepływy danych między sklepem internetowym, ERP i pozostałymi systemami firmy, w których każda dana ma jednego właściciela i wiadomo, kiedy i którędy płynie. W środku tego układu stoi zwykle ERP, bo to tam firma prowadzi magazyn i dokumenty. Ten tekst dotyczy przede wszystkim integracji sklepu internetowego z ERP.

Najłatwiej zobaczyć, czym jest integracja, po tym, co się dzieje, gdy przepływ ustawiono źle. W sklepie Pitstopparts pełne odświeżenie katalogu od dostawcy trwało godzinami, a w tym czasie sklep mógł przyjąć pieniądze za towar, którego u dostawcy już nie było. Na platformie B2B Plastics wyszukiwanie klienta po adresie e-mail podpinało zamówienie pod inną firmę i ERP odrzucał je, bo NIP się nie zgadzał. Oba systemy w każdej z tych historii działały poprawnie. Zawiodło ustalenie, co ma między nimi płynąć i kiedy.

Jeśli masz ERP, którego nikt w firmie nie zamierza wymieniać, i sklep, który musi z nim rozmawiać, całą pracę dopasowania wykonuje integracja. Wtyczka załatwia z niej najmniejszą część. Więcej ważą trzy decyzje: który system jest źródłem prawdy dla której danej, czy dane płyną od razu po zmianie, czy według harmonogramu, i co się dzieje, gdy druga strona nie odpowiada.

Który system jest źródłem prawdy dla której danej

W 2021 roku sprzedawca choinek FairyTrees sprzedawał głównie przez marketplace'y, miał silny sezon i ERP Microsoft Dynamics NAV, z którym dało się rozmawiać tylko po SOAP. Zanim powstała pierwsza linijka integracji, w dokumencie projektu stanął podział: NAV odpowiada za magazyn i dokumenty, PIM za treść produktów, Magento za ofertę i cenę, a BaseLinker i Channable za obsługę marketplace'ów. Taka kartka wygląda na formalność do dnia, w którym dwa systemy pokażą dwie różne ceny tego samego produktu. Wtedy wiadomo od razu, który z nich poprawić.

Z tego podziału łatwo zrobić szablon na własny projekt:

Przy wypełnianiu takiej tabeli potrafią wyjść dwie niespodzianki, po których widać, że integracja sklepu internetowego nie kręci się wokół sklepu. Pierwsza: źródłem prawdy o ofercie bywa system, na który sklep nie ma żadnego wpływu. W DESA katalog żyje w CRM klienta. Tam powstają kategorie, warianty i strefy cen, tam też ktoś decyduje, które produkty odrzucić. Do sklepu katalog płynie cyklicznym importem, najpierw z CRM do PIM, potem z PIM do Magento, razem z ceną dla każdej strefy.

Druga dotyczy stanu, który w praktyce składa się z dwóch części o różnych właścicielach. ERP zna magazyn, a sklep wie, co już sprzedał i jeszcze nie wysłał. Magento liczy ilość, którą wolno sprzedać, jako stan ze źródeł minus rezerwacje złożonych, niewysłanych zamówień. Integracja, która po prostu przepisuje stan z ERP do sklepu, musi więc brać pod uwagę oba systemy, inaczej towar zarezerwowany godzinę temu znów pokaże się jako dostępny.

Wiersz z fakturą ma od 2026 roku trzeciego uczestnika. Od 1 lutego wszyscy podatnicy VAT odbierają faktury przez KSeF, a największe firmy także je w nim wystawiają. Od 1 kwietnia wystawiają pozostali, a najmniejsi mają czas do końca roku. Pytanie, czy fakturę wystawia sklep, czy ERP, rozstrzyga dziś również, który z nich rozmawia z KSeF.

Zdarzenie czy harmonogram: jak świeża musi być ta dana?

O metodzie decyduje to, jak świeża musi być dana i ile kosztuje pomyłka, a decyzję podejmuje się osobno dla każdej danej. Jak często sklep musi wiedzieć, ile kosztuje produkt? A jak często, ile go zostało w magazynie? W integracji Plastics odpowiedzi są różne: ceny przychodzą z ERP raz dziennie, a stany osobnym przebiegiem, który wykrywa, co się zmieniło, i zapisuje zmianę albo w całości, albo wcale.

Podział według wielkości firmy (duży sklep na zdarzeniach, mały na plikach CSV) niewiele tu pomaga. Cennik grupy handlowej może być z wczoraj, bo zmienia się rzadko, więc Canpol pobiera go z ERP jako plik XML co noc. Dostępność towaru u hurtowni Pitstopparts sprawdza w API dostawcy dopiero w chwili finalizacji zamówienia, bo pomyłka oznacza sprzedaż czegoś, czego nie ma.

Zdarzenia mają swoją pułapkę: trzeba zdecydować, co w ogóle jest zdarzeniem. W DESA Magento wysyła powiadomienie przy każdej zmianie zamówienia, a CRM klienta potrzebuje czterech etapów i ani jednego duplikatu. Między nimi stoi więc integrator z kolejką RabbitMQ, który z wielu powiadomień przepuszcza każdy etap dokładnie raz. Tej ochrony nie daje sama kolejka. Kolejki dostarczają wiadomość co najmniej raz, a po zerwaniu połączenia niepotwierdzona wiadomość wraca, więc to odbiorca musi rozpoznać powtórkę.

Jest też trzecia droga, czyli opóźnienie wybrane świadomie. Aplikacja mobilna Bolero nie odpytuje Magento. Czyta z osobnej kopii danych, którą co noc odbudowuje się na nowo, a zamówienia i płatności wracają z niej do sklepu co kilka minut. Sklep dowiaduje się o zamówieniu z lekkim opóźnieniem, za to ruch z aplikacji go nie obciąża, a nowy kanał nie powiela logiki sklepu. Żadna z tych dróg nie wymaga egzotycznej infrastruktury: Magento 2 ma wbudowany mechanizm kolejek, ale na produkcji zaleca się zewnętrzny broker, na przykład RabbitMQ, i osobne procesy, które odbierają wiadomości, a ktoś musi pilnować, żeby działały.

Gdy coś pójdzie nie tak, i skąd o tym wiesz

20 lipca 2026 roku dostawca ERP Plastics wyłączył produkcyjnie stare endpointy cen i stanów, z których korzystała integracja sklepu. Trzeba było przestawić ją na nowy, jeden zamiast kilku. ERP, którego nikt w firmie nie zamierza wymieniać, i tak się zmienia.

Awarii nie da się więc wykluczyć. Da się za to ustalić z góry, co się wtedy dzieje. W DESA, gdy CRM nie przyjmie etapu zamówienia, w integratorze jest panel ponownej wysyłki i nikt nie musi wołać programisty, żeby zamówienie poszło drugi raz. Awaria usługi zewnętrznej nie może też zatrzymać sklepu: klient ma kupić, nawet gdy coś obok sklepu nie odpowiada. A długi import, który stanie w połowie, powinien ruszyć od miejsca, w którym przerwał, i rozpoznać, kiedy katalog się skończył, zamiast zaczynać od początku.

Druga połowa tej decyzji to pytanie, skąd w ogóle wiesz, że coś się zepsuło. U jednego z klientów monitoring integracji stoi na Grafanie, Graylogu i własnym systemie logów. Przy analizie tych logów okazało się, że większość wpisów dotyczyła zamówień, które integracja świadomie pomijała, a harmonogramy zadań cyklicznych nachodziły na siebie. Powstał plan wycięcia zbędnego logowania, żeby wpis o prawdziwym błędzie nie ginął wśród wpisów o niczym. Niektórych zależności nie widać wcale, dopóki się nie zerwą, jak endpoint logowania aplikacji mobilnej, który zniknął razem z wyłączonym modułem.

Najdroższy błąd integracji to ten, który nie zostawia śladu w logach.

Koszt integracji wyznacza dostęp do ERP

Integracja z ERP kosztuje tyle, ile kosztuje dostęp do niego. Wychodzi to w analizie, zanim ktokolwiek poda cenę. W siedmiu wdrożeniach integracji z ERP mieliśmy siedem różnych systemów i siedem różnych dróg do danych:

• Microsoft Dynamics AX: SOAP z uwierzytelnianiem NTLM, dostęp przez VPN,

• Vendo: REST API,

• Microsoft Dynamics NAV / Business Central,

• 1C: SOAP, z rozliczeniami w wielu walutach,

• Softlab: przez BaseLinkera jako pośrednika,

• CRM klienta, który prowadzi katalog,

• Navireo, obok API hurtowni InterCars.

Najcięższy z tej listy jest przypadek Plastics: AX postawiony na własnych serwerach firmy, schowany za VPN, z SOAP-em i NTLM. Zanim integracja przekaże pierwsze zamówienie, trzeba zestawić tunel i uwierzytelnianie, a potem przejść cały obieg: zamówienie, klient, faktura w PDF, przesyłka, osobno dla B2B i B2C, z zasadą, że nieopłacone zamówienie nie idzie do wysyłki.

Ta sama lista funkcji przy ERP z otwartym REST API to zupełnie inny projekt.

Dostęp sprawdzamy więc kodem, zanim zapadnie decyzja. W MUVE przed decyzją o migracji powstał POC na API starego systemu: krótki prototyp, który miał pokazać, czy da się z niego wyciągnąć dane. Przed modułem kursów walut, który miał zastąpić ręczne przeliczanie cen między rynkami i spiąć kursy z API OANDA z importem cen z PIM, był dwudniowy POC. W Canpol analiza miała osobne warsztaty integracyjne z zespołem po stronie klienta, obok warsztatów o UX i funkcjach. Kwot nie podajemy, bo bez tej analizy byłyby zgadywaniem. Sama analiza przedwdrożeniowa trwa zwykle od trzech do pięciu tygodni. Po niej wiadomo, co trzeba połączyć i którędy.

Dane poprawne dla ERP, złe dla sklepu

W ERP FairyTrees każdy kolor choinki to osobny, niezależny produkt z własnym SKU. Z punktu widzenia ERP wszystko się zgadza: marketplace'y potrzebują właśnie takich płaskich indeksów. Sklep, który wziąłby te dane wprost, pokazałby klientowi osobną kartę dla każdego koloru tej samej choinki, zamiast jednej karty z wyborem wariantu. ERP nikt pod sklep nie przebudował. Różnicę wyrównuje sklep: moduł grup wariantów z własnym panelem składa niezależne indeksy w jeden produkt i pilnuje, żeby filtrowanie i listing kategorii widziały go poprawnie. Moduł ma za sobą pięć lat rozwoju. Koszt danych, które źle pasują do sklepu, nie skończył się w dniu startu.

Klient, który sprzedaje kilkoma markami i przez kilka spółek, pokazał drugi rodzaj kosztu, mniej widoczny. Do jednego konta Channable wpadały zamówienia kilku marek i spółek, a każda spółka księgowała w osobnej instancji NAV. To, która spółka obsługuje który kanał sprzedaży, było wpisane na sztywno w kodzie integracji. Poprawka wymagała przebudowy: spółka trafiła na dokument zamówienia, powiązanie kanału ze spółką da się teraz konfigurować, historyczne zamówienia przeszły na nowy model, a obok powstała druga integracja z Channable.

Oba przypadki mają ten sam wzór. Dane albo decyzja, które na starcie były w porządku, zaczynają kosztować, gdy firma dokłada kanały, marki i spółki. W integracjach ecommerce tę część kosztu najtrudniej wycenić, bo w dniu analizy jeszcze jej nie widać.

Gotowy integrator czy własna szyna

Wybierać nie trzeba. U JKB kanały sprzedaży obsługują gotowe narzędzia, BaseLinker i Channable, a między nimi a ERP pracuje własny system zamówień. Zamówienia z BaseLinkera, Channable i Magento trafiają do niego i zamieniają się w dokumenty ERP, każdy marketplace z własnym kontem i osobną logiką dla Amazon FBA czy Etsy. W drugą stronę płyną stany, ceny, faktury i przesyłki. Gotowe narzędzie robi swoje tam, gdzie problem jest typowy, jak wystawienie oferty na marketplace, a własny kod przejmuje sprawę tam, gdzie zaczyna się księgowość klienta.

Gotowy integrator bywa szyną także w projektach, które budujemy. W Canpol BaseLinker łączy ERP Softlab z Magento, a ten sam indeks występuje w sklepie jako dwa produkty, B2B i B2C, z osobnymi źródłami stanów. Granicę takiego rozwiązania wyznacza jego model danych. W Bolero ceny zestawów i faktura imienna musiały trafić do zamówienia przez integrację z BaseLinkerem dopisaną kodem, i każdy taki wyjątek ktoś potem utrzymuje.

Na drugim końcu jest MUVE, które dostało własną integrację z Allegro. Proces nie mieścił się w typowym modelu: klucze cyfrowe wysyłane automatycznie po zamówieniu, wiele kont, osobne ceny dla każdego rynku, oferty wystawiane na podstawie oznaczeń w PIM i kampanie cenowe Allegro dopasowywane do produktów po EAN z arkusza.

Jest też rachunek. Abonament gotowego integratora rośnie razem ze sprzedażą: w BaseLinkerze płaci się stałą opłatę i osobno od każdego zamówienia. Koszt własnej szyny zależy głównie od tego, ile systemów trzeba połączyć i jak trudno się do nich dostać. Dla małego i średniego sklepu BaseLinker świetnie wystarcza i nie ma sensu budować czegoś obok. Własna szyna zaczyna się opłacać tam, gdzie procesy wychodzą poza typowy model.

Jeden z naszych klientów pracuje na tej samej szynie od sześciu lat. Skala przez ten czas urosła, a architektura się nie zmieniła, bo od początku zakładała, że urośnie. Integrację projektuje się na lata, bo tyle potem z nią żyjesz.

Podsumowanie

Każdy system w firmie ma swojego właściciela. ERP ma dostawcę i księgowość, sklep ma agencję i dział ecommerce, a przestrzeń między nimi nie ma nikogo, poza osobą, która ostatnio coś tam poprawiała. Może dlatego rozmowa o integracji tak chętnie zaczyna się od narzędzi: narzędzie da się kupić, a odpowiedzialności za środek nikt nie sprzedaje. Ktoś po stronie firmy musi uznać ten środek za swój teren i wiedzieć, co się po nim przemieszcza. A u Ciebie kto pilnuje środka?

Jeśli chcesz sprawdzić, jak te decyzje wyglądają w Twoim sklepie i ERP, umów bezpłatną konsultację. Przejdziemy przez nie po kolei i powiemy, co z nich wynika dla zakresu integracji.