Najczęstszy ból w 15-30 osobowych firmach z własnym sklepem online wygląda tak: magazynier dwa razy dziennie eksportuje stany z ERP do CSV, ktoś inny wgrywa to do Shopera, a w międzyczasie sklep sprzedaje ostatnie sztuki towaru, którego fizycznie już dawno nie ma. Klient czeka tydzień, dostaje maila „przepraszamy", zwraca kartę i więcej nie wraca.
Problem nie leży ani w sklepie, ani w ERP. Problem polega na tym, że oba systemy żyją w innych rzeczywistościach i informują się o sobie wtedy, kiedy ktoś znajdzie czas. W praktyce to oznacza opóźnienie 4-8 godzin między sprzedażą a aktualizacją stanu — i w tym oknie czasowym dzieje się większość katastrof.
Dobra wiadomość: w 2026 roku nie potrzebujesz do tego ani enterprise'owego ESB, ani projektu na pół roku. Potrzebujesz trzech rzeczy: zdecydować, co jest źródłem prawdy, podpiąć trzy strumienie danych i zostawić sobie obejście awarii.
Trzy strumienie, które muszą płynąć w obie strony
Każda sensowna synchronizacja sklep ↔ ERP sprowadza się do trzech strumieni. Reszta to dekoracja.
Strumień 1: Stany magazynowe — z ERP do sklepu. Źródłem prawdy jest ERP, bo to tam fizycznie schodzą sztuki przy wydaniu z magazynu, sprzedaży hurtowej, zwrocie do dostawcy. Sklep musi dowiedzieć się o każdej zmianie w ciągu sekund, nie godzin.
Strumień 2: Zamówienia — ze sklepu do ERP. Kiedy klient kliknie „kup", w ERP musi pojawić się dokument (zamówienie sprzedaży albo od razu WZ), żeby księgowość wystawiła fakturę, a magazyn miał co pakować. Bez tego masz dwa równoległe światy: paragony w Shoperze i faktury w Comarchu, które do siebie nie pasują na koniec miesiąca.
Strumień 3: Kartoteka produktów — z ERP do sklepu. Nowy produkt, zmiana ceny, zmiana opisu — wszystko zaczyna się w ERP i ląduje w sklepie. Dlaczego nie odwrotnie? Bo na ERP wisi księgowość, kasy fiskalne i sprzedaż hurtowa. Sklep online jest jednym z kanałów, nie centrum świata.
Polling czy webhooki — i czy to ma znaczenie
Klasyczna integracja co 15 minut odpytuje sklep o nowe zamówienia, a ERP o zmiany stanów. To działa, ale ma dwie wady: opóźnienie i obciążenie. Dla 5 zamówień dziennie polling jest OK. Dla 200 zamówień dziennie polling będzie albo niedokładny, albo będzie zarzynał oba systemy.
Webhooki rozwiązują problem: sklep sam wysyła „mam nowe zamówienie", ERP (albo middleware nad nim) wysyła „zmienił się stan SKU X". Dane lecą w momencie, w którym się zmieniają. W praktyce większość polskich ERP-ów (Comarch Optima, enova365, Subiekt GT) nie wystawia natywnie webhooków, więc rolę nadajnika przejmuje middleware — mała aplikacja, która siedzi pomiędzy.
Taki middleware to zwykle kilkaset linii kodu w .NET albo Node.js, hostowany na małym VPS-ie. To nie jest projekt na trzy kwartały. To jest projekt na 4-8 tygodni, łącznie z testami i wdrożeniem produkcyjnym.
Konkret: producent kosmetyków, 15 osób
W jednym z naszych projektów 15-osobowy producent kosmetyków naturalnych sprzedawał równolegle przez sklep w Shoperze (B2C) i przez Comarch Optima do hurtowni (B2B). Stan tego samego SKU mógł być w sklepie pokazywany jako „dostępne 12 sztuk", podczas gdy hurtownia właśnie wystawiła fakturę na 20 sztuk z tego samego magazynu.
Mechanika wyglądała tak: dwa razy dziennie magazynier eksportował stany do CSV, wrzucał do panelu Shopera, a w międzyczasie świat się zmieniał. Średnio 14 zamówień miesięcznie kończyło się mailem „przepraszamy, towaru już nie ma". Klienci dzwonili wściekli, opinie w Google spadały, dział obsługi tracił 6-8 godzin tygodniowo na gaszenie pożarów.
Wdrożyliśmy middleware w .NET, który nasłuchuje webhooków z Shopera (nowe zamówienie → rezerwacja w Optimie) i odpytuje Optimę co 60 sekund o zmiany stanów (push do Shopera przez API). Czas wdrożenia: 5 tygodni, koszt poniżej 30 tys. zł. Po pierwszym pełnym miesiącu liczba zamówień anulowanych z powodu „brak towaru" spadła z 14 do 1 — i to był błąd inwentaryzacyjny, nie integracji. Magazynier odzyskał 8 godzin tygodniowo, które wcześniej szły na eksporty i odpisywanie klientom.
Pułapki, które dorwą Cię w pierwszym kwartale
Warianty i rozmiary. Sklep często widzi „koszula męska XL" jako jeden produkt, a ERP widzi to jako osobny SKU. Bez konsekwentnego mapowania wariantów synchronizacja stanów rozjedzie się w drugim tygodniu i nikt nie będzie wiedział, gdzie jest błąd.
Zwroty. Klient zwraca paczkę. W sklepie status zamówienia idzie na „zwrócone", ale w ERP nikt automatycznie nie wraca towaru na stan. Musisz to przewidzieć — albo automatyczna korekta WZ, albo świadoma decyzja, że magazyn robi to ręcznie (i ma na to checklistę).
Multi-magazyn. Jeśli wysyłasz z trzech lokalizacji, sklep musi widzieć sumę stanów, ale rezerwacje muszą lecieć do konkretnego magazynu. To nie jest trywialne — i jest najczęstszą przyczyną „dziwnych" błędów po pierwszym miesiącu.
Ceny promocyjne. Promocja w sklepie nie powinna wracać do ERP jako stała cena. Trzeba zdecydować, gdzie żyje cena bazowa, a gdzie reguły promocyjne, i nie mieszać tych dwóch warstw.
Awaria middleware. Średni VPS żyje 99,9% czasu, czyli pada na około 8 godzin w roku. Musisz mieć kolejkowanie zdarzeń (RabbitMQ, Redis, cokolwiek) i sensowny mechanizm „dograj wszystko, co przeleciało, kiedy serwer wstanie". Inaczej w dniu awarii po prostu stracisz dane.
Co zrobić w ten poniedziałek
Zanim w ogóle zaczniesz rozmawiać z integratorem, zrób trzy rzeczy:
- Policz, ile w zeszłym miesiącu miałeś zamówień anulowanych z powodu „brak towaru". Pomnóż przez średnią marżę i przez 12. To Twoja roczna strata z braku synchronizacji.
- Zmierz, ile godzin tygodniowo Twój zespół spędza na ręcznych eksportach i importach między sklepem a ERP. Pomnóż przez stawkę godzinową i przez 50. To drugi koszt.
- Zapytaj swojego dostawcę ERP (Comarch, Insert, Soneta), czy ma gotowy konektor do Twojego sklepu i co dokładnie obejmuje. W większości przypadków „gotowy konektor" pokrywa 70-80% potrzeb i zostają 2-3 luki do dorobienia middlewarem.
Jeśli po tych trzech krokach widzisz, że tracisz kilkanaście tysięcy złotych rocznie i jeden etat na klepanie plików CSV — to jest projekt, który zwraca się w jednym kwartale. Większość firm, które do nas trafiają z tym problemem, zwleka z decyzją nie dlatego, że nie widzą sensu, tylko dlatego, że nie wiedzą, od którego konkretnego kroku zacząć.
Synchronizacja sklep–ERP to nie jest projekt IT. To jest sposób, żeby przestać tracić klientów z głupiego powodu.