Co daje firmie integracja ERP, płatności i kurierów — w liczbach

Opłacalność najlepiej sprawdzić na własnych zamówieniach, nie na ogólnych deklaracjach. Zmierz, ile zajmuje Ci obsługa jednego zamówienia od opłacenia do nadania. W małej firmie to zwykle 4–7 minut: przepisanie danych klienta i pozycji do ERP, dokument sprzedaży, etykieta w panelu kuriera, wklejenie numeru przesyłki do sklepu, mail do klienta. Po integracji ten sam cykl zamyka się w 20–40 sekundach, bo zostaje głównie nadzór i obsługa wyjątków.

Policz to na 200 zamówieniach miesięcznie. Przy 5 minutach na zamówienie daje to 1000 minut, czyli 16 godzin 40 minut pracy co miesiąc — blisko 200 godzin w roku, więcej niż pełny miesiąc pracy jednej osoby. Po integracji, przy 30 sekundach na zamówienie, zostaje około 100 minut miesięcznie. Różnica to ponad 15 godzin miesięcznie, które możesz przesunąć na obsługę klienta, uzupełnianie oferty albo po prostu krótszy dzień pracy.

Koszt błędu przy ręcznym przepisywaniu. Przy 200 zamówieniach i 3% pomyłek mówimy o 6 zdarzeniach miesięcznie. Zły adres to przesyłka zwrotna i ponowny koszt nadania. Zła kwota albo brak faktury to korespondencja, korekta i czas na uzgodnienie z księgowością. Jedno takie zdarzenie to zwykle 15–40 minut pracy. 6 × 25 minut daje 2,5 godziny miesięcznie, których nie widać w żadnym raporcie — a dochodzi jeszcze koszt transportu i ryzyko, że klient nie wróci.

Próg opłacalności. W naszej praktyce integracja zwraca się przy 150–200 zamówieniach miesięcznie, w 2–5 miesięcy. Poniżej 60–80 zamówień oszczędność rzędu 3–4 godzin miesięcznie nie pokryje kosztu utrzymania — lepiej wtedy zawęzić zakres do jednego elementu, najczęściej płatności i etykiet. Zanim podejmiesz decyzję, porównaj stawki: koszt integracji ERP, płatności i kurierów w Zamościu pokazuje, czy liczysz się z jednorazowym wdrożeniem, czy z abonamentem.

Jak wygląda przepływ zamówienia po integracji — krok po kroku

Po integracji zamówienie przestaje być zadaniem dla człowieka, a staje się ciągiem zdarzeń. Zestaw tę listę z własną codziennością i sprawdź, którego kroku u Ciebie brakuje.

1. Złożenie zamówienia — klient wybiera płatność i kuriera. Sklep zapisuje zamówienie ze statusem oczekiwania na płatność.
2. Webhook płatności — operator (Przelewy24, PayU, Stripe, tpay) wysyła żądanie POST na adres Twojego sklepu. To on jest źródłem prawdy, nie powrót klienta na stronę podziękowania — kartę można zamknąć przed przekierowaniem.
3. Dokument w ERP — mostek mapuje kontrahenta, pozycje i stawki VAT. Tu wychodzą różnice słowników: jednostki miary, grupy towarowe, zapis NIP-u.
4. Rezerwacja stanu — towar musi zniknąć z dostępnych, zanim ktoś kupi go drugi raz.
5. Etykieta kurierska — API kuriera generuje etykietę i numer przesyłki.
6. Numer przesyłki w sklepie — zamówienie dostaje status wysłane i numer widoczny dla klienta.
7. Mail do klienta — z numerem i linkiem do śledzenia.
8. Faktura — PDF do klienta, dokument w księgowości.

Synchronicznie czy przez kolejkę. W trybie synchronicznym sklep czeka na odpowiedź ERP w tym samym żądaniu. Gdy ERP jest aktualizowane, ma wolne zapytanie albo restart, żądanie kończy się timeoutem i nie wiadomo, czy dokument powstał — stąd duplikaty faktur. Kolejka (tabela zadań w bazie, WP-Cron, Redis, RabbitMQ) zapisuje zadanie i przetwarza je w tle z ponowieniami. Każdy task musi mieć klucz idempotencji, np. numer zamówienia plus typ zadania, żeby ponowienie nie utworzyło drugiej faktury, oraz kolejkę zadań nieudanych do ręcznego przejrzenia. W Black Friday kolejka przyjmie 2000 zamówień i poda je ERP w tempie, które ten wytrzyma, zamiast zwracać błędy 500.

Które kroki muszą dziać się od razu? Potwierdzenie płatności, rezerwacja stanu, etykieta i mail z numerem — tu liczą się sekundy. Dokumenty magazynowe, faktura zbiorcza, raporty i synchronizacja stanów z hurtowni mogą poczekać 15–30 minut w harmonogramie. Mechanikę webhooków w sklepie opisuje dokumentacja WooCommerce — zamówienia i webhooki.

ERP, z którym najczęściej łączymy sklepy w regionie

W małych i średnich firmach w okolicy trafiamy na cztery grupy systemów i każda wymaga innego podejścia.

Subiekt GT. Zapis dokumentów robi się przez Sferę — bibliotekę COM działającą na Windows, która wymaga wykupionej licencji Sfery i zwykle jednego procesu na bazę. Odczyt stanów przez zapytania SQL jest szybszy do wdrożenia, ale nie utworzy dokumentu, a schemat bazy nie jest publicznym API i może się zmienić po aktualizacji. Praktyczny układ to zapis przez Sferę, odczyt do raportów z bazy.

Subiekt nexo. Komunikacja przez Sferę nexo dla podmiotu — wymaga licencji i konfiguracji po stronie serwera, za to dobrze nadaje się do pracy z dokumentami magazynowymi. Typowy problem: mapowanie jednostek miary i grup towarowych między sklepem a kartoteką.

Comarch ERP Optima. Integracja przez Optima API — tworzenie kontrahentów i dokumentów. Uwaga na wersję licencji i słowniki; bez ich uzgodnienia dokumenty wpadają do złych grup.

WF-Mag i WAPRO. Część wersji nie ma publicznego API, więc wymiana idzie plikami eksportu/importu (CSV, XML) w harmonogramie co 15–60 minut. Pułapka: brak potwierdzenia zapisu. Trzeba pilnować plików wynikowych i drugiego zestawu stanów.

Fakturownia, ifirma, inFakt. Dobre rozwiązanie dla firm bez klasycznego ERP — integracja idzie przez API dokumentów, tworzy fakturę i kontrahenta. Ale to nie magazyn: stany trzeba trzymać w sklepie albo w prostym module, a przy dwóch kanałach sprzedaży zaczyna brakować wspólnego stanu.

Kiedy mostek własny. Jeśli ERP nie ma API, masz kilka sklepów lub kanałów, nietypowe mapowanie albo potrzebujesz kolejki, logu zdarzeń i raportu błędów — piszemy moduł pośredniczący. Jeśli masz jeden sklep i jeden ERP z API, gotowy moduł plus konfiguracja jest tańszy i szybszy. Podobne wdrożenia w mniejszych miejscowościach opisujemy przy okazji integracji z ERP i kurierami w Narolu.

Płatności online — co musi obsłużyć sklep w 2025 roku

Pięć bramek, które w polskich sklepach pojawiają się najczęściej, to Przelewy24, PayU, Tpay, Autopay i Stripe. Wybór nie zależy od wyglądu panelu, a od tego, co musi obsłużyć koszyk: BLIK, karty, przelewy online, płatności odroczone i raty. BLIK odpowiada za większość transakcji detalicznych — jeśli bramka obsługuje go słabo (brak zwrotu na BLIK, brak ponowienia płatności z panelu), klient kończy z ręcznym przelewem i mailem do księgowości.

Drugi filar to webhooki, czyli powiadomienia od bramki o zmianie statusu płatności. Każdy trzeba zweryfikować: podpis HMAC w nagłówku, lista dozwolonych adresów IP bramki, dopasowanie po identyfikatorze transakcji i kwocie. Webhook bez weryfikacji źródła to otwarte drzwi — każdy może wysłać POST „zapłacono”. Konfigurację webhooków w WooCommerce opisuje oficjalna dokumentacja WooCommerce.

Co się dzieje, gdy webhook nie dotrze — bramka miała przerwę, hosting odrzucił żądanie, wystąpił timeout? Zamówienie zostaje na statusie „oczekiwanie na płatność”, a klient pisze albo dzwoni. Potrzebne są dwie rzeczy: rejestr zdarzeń i bezpieczne odpytywanie. Cron co 10–15 minut pobiera transakcje starsze niż 15 minut i wciąż niepotwierdzone, pyta API bramki po identyfikatorze transakcji i zapisuje odpowiedź w logu. Zapytanie musi być idempotentne — to samo zdarzenie nie może dwa razy wystawić faktury ani dwa razy zdjąć stanu magazynowego.

Najczęstsze źródło rozjazdów to mapowanie statusów. Bramka ma kilka stanów (nowa, w trakcie, potwierdzona, anulowana, zwrócona), sklep swoje (PrestaShop: order state, WooCommerce: wc-pending, wc-processing, wc-refunded), a ERP jeszcze inne. Ta tabela musi być uzgodniona z księgowością przed pierwszym testem — inaczej po miesiącu zwroty lądują w ERP jako nowe zamówienia. Ten sam układ bramka–sklep–ERP wraca w każdym wdrożeniu, także przy integracjach płatności, ERP i kurierów dla firm z Hrubieszowa.

Kurierzy i wysyłka: InPost, DPD, DHL, Poczta Polska

Integracja kurierska to nie jedna wtyczka, a zestaw reguł do ustalenia przed wdrożeniem. Pierwsza: etykiety. Potrzebne jest generowanie pojedyncze (z karty zamówienia) i zbiorcze w formie manifestu — jednego pliku PDF z etykietami na cały dzień, gotowego przed godziną, w której kurier odbiera paczki. Druga: zamówienie odbioru o stałej godzinie, np. codziennie 13:00–15:00. Bez tego ktoś ręcznie zamawia kuriera każdego dnia.

Trzecia reguła to punkty odbioru. Listy paczkomatów i punktów (DPD Pickup, placówki Poczty) zmieniają się co tydzień, więc nie wpisuje się ich ręcznie — pobiera się je z API przewoźnika i mapuje na metody dostawy w sklepie. Bez mapowania klient wybiera punkt, którego już nie ma. Czwarta: limity. Paczkomat ma gabaryty A, B, C i maksymalną wagę, przesyłka kurierska — własne. Aktualne wartości bierz z cennika przewoźnika i sprawdź przy każdej zmianie umowy, bo te liczby się zmieniają.

Piąta: statusy. Numer nadawczy musi wrócić do zamówienia i wywołać maila do klienta, a statusy przesyłki (nadana, w drodze, do doręczenia, doręczona, awizo, zwrot do nadawcy) — zaktualizować status zamówienia w sklepie i w ERP. Typowa pułapka: klient dostaje dwa powiadomienia, jedno od sklepu, drugie od kuriera. Lepiej wyłączyć jedno.

Szósta: zwroty i ponowne wysyłki. Zwrot to osobny dokument w ERP (przyjęcie na magazyn plus korekta), a ponowna wysyłka — nowa paczka powiązana z tym samym zamówieniem, żeby historia nie zniknęła. Siódma: awaria API. Etykiety powinny iść przez kolejkę z ponowieniami (1 min, 5 min, 15 min), a gdy przewoźnik nie odpowiada dłużej — potrzebny jest fallback: etykieta z panelu kuriera i ręczne wpisanie numeru do zamówienia. Bez tego w dzień awarii stoi cała wysyłka. Kolejność reguł opisujemy też przy spięciu sklepu z kurierami i ERP w Narolu, a szczegóły modułów przewoźnika znajdziesz w dokumentacji dla deweloperów PrestaShop.

Ile to kosztuje i ile trwa — realne widełki godzinowe

Widełki, których używamy w wycenach dla sklepu z jednym magazynem i standardowym ERP: płatności 8–20 h, kurierzy 12–30 h (jeden przewoźnik; każdy kolejny to zwykle 4–8 h), ERP 24–80 h, moduł niestandardowy od 16 h. Do tego dochodzą testy i czas na poprawki — to nie jest gratis, choć w „tanich” ofertach zwykle go nie ma.

Co podnosi wycenę: brak API w ERP (zostaje eksport i import plików CSV co godzinę, co samo w sobie jest osobnym projektem), licencja ERP bez Sfery albo bez modułu integracyjnego, nietypowe stany magazynowe (rezerwacje, zestawy, produkty na zamówienie), wielomagazynowość, wielowalutowość, dwa sklepy na jednym ERP albo sprzedaż na marketplace. Każda z tych rzeczy to nie drobiazg, a osobny scenariusz do zaprojektowania i przetestowania.

Rozliczenie etapowe działa najlepiej: etap 1 — płatności, etap 2 — kurierzy, etap 3 — ERP, etap 4 — rozszerzenia niestandardowe. Płaci się po odbiorze etapu, więc ryzyko rozkłada się na obie strony, a Ty widzisz działający fragment po kilku tygodniach, nie po pół roku. Orientacyjne stawki i gotowe zestawienie zakresów znajdziesz w cenniku integracji z ERP, płatnościami i kurierami oraz w opisie kosztu wdrożenia integracji w firmie z Zamościa i okolic.

W ofercie powinny być cztery rzeczy: zakres (co dokładnie robimy, a czego nie), założenia (wersje sklepu i ERP, nazwy przewoźników, kto daje dostępy, kto testuje), kryteria odbioru (np. 20 zamówień testowych przechodzi pełną ścieżkę: płatność → dokument w ERP → etykieta → status u klienta) i czas na poprawki (zwykle 14–30 dni od odbioru, bezpłatnie). Brak kryteriów odbioru to najczęstsza przyczyna sporów przy rozliczeniu.

7 pułapek przy integracji i jak je wykryć przed startem

Większość awarii integracji nie wychodzi w dniu startu, tylko wtedy, gdy coś zdarzy się drugi raz: powtórzony webhook, równoległa sprzedaż ostatniej sztuki, inna strefa czasowa. Poniższą listę przejdziesz w 1–2 dni, jeszcze przed odbiorem prac.

Pułapka	Jak to sprawdzić przed startem
Duplikaty zamówień przy powtórzonym webhooku	Wyślij to samo zdarzenie dwa razy (np. z panelu bramki albo powtórzonym żądaniem na endpoint) i sprawdź, czy w sklepie i w ERP powstanie jeden dokument. Wymagaj idempotencji opartej o identyfikator zdarzenia, nie o datę.
Rozjazd stanów magazynowych między sklepem a ERP	Wystaw 1 sztukę w sklepie i w drugim kanale, kup ją równolegle w odstępie kilku sekund. Sprawdź, czy drugi kanał dostanie blokadę, czy sprzeda towar, którego fizycznie nie ma.
Brak logów i brak środowiska testowego	Żądaj sandboxu bramki i klucza testowego kuriera oraz logu żądań i odpowiedzi z ID korelacji, do którego sam zajrzysz — nie tylko „u wykonawcy na serwerze”.
Strefy czasowe i formaty dat	Złóż zamówienie o 23:40 i sprawdź, czy data dokumentu w ERP to ten sam dzień. ERP często pracuje w UTC, a sklep w czasie lokalnym.
Polskie znaki w adresach	Użyj adresu z Ś, Ł, Ż i myślnikiem. Sprawdź etykietę kurierską, adres na fakturze i plik CSV wysyłany do przewoźnika.
Brak obsługi zwrotów i korekt faktur	Zapytaj wprost, czy integracja tworzy dokument korygujący i zwrot w ERP, czy obsługuje wyłącznie nowe zamówienia. To najczęściej pomijany zakres.
Brak alertów przy błędzie	Wyłącz na próbę klucz API i sprawdź, czy ktoś dostaje maila lub wiadomość na Slacka. Błąd, który siedzi cicho w logu, oznacza zamówienia bez etykiety przez kilka dni.

Sam zakres zdarzeń, jakie sklep potrafi wywołać po opłaceniu zamówienia, znajdziesz w dokumentacji dla deweloperów PrestaShop — warto ją przejrzeć przed rozmową o wycenie, żeby nie płacić za funkcje, których platforma nie udostępnia. Jeśli chcesz zobaczyć, jak ten sam zestaw testów wygląda w praktyce u firm z regionu, opisaliśmy to przy okazji wdrożeń w ramach integracji z ERP, płatnościami i kurierami w Zamościu.

Od czego zacząć w firmie ze Szczebrzeszyna — kolejność wdrożenia

W firmie, która nie może zatrzymać sprzedaży na czas wdrożenia, kolejność ma większe znaczenie niż wybór wykonawcy. Zacznij od tego, co daje efekt w pierwszym tygodniu, a stany magazynowe zostaw na koniec — to najbardziej ryzykowny element.

Kolejność MVP:

1. Płatności online — zwykle 1–3 dni. Zamówienie samo zmienia status na „opłacone”, znika ręczne sprawdzanie przelewów. Najczęściej wystarczy klucz API i webhook.
2. Etykiety kurierskie — 2–5 dni. Etykieta powstaje z panelu sklepu, numer przesyłki wraca do klienta automatycznie. Mierząc efekt, licz kliknięcia: trzy to dobry wynik, dziesięć to ta sama praca ręczna w innym miejscu.
3. Dokument sprzedaży w ERP — 3–10 dni. Zamówienie zamienia się w dokument sprzedaży bez przepisywania. Tu najczęściej trzeba uzgodnień z księgowością: jakie pola, jakie statusy, kto wystawia fakturę.
4. Stany magazynowe — 1–3 tygodnie. Synchronizacja dwukierunkowa, rezerwacje, korekty. Dopiero gdy trzy poprzednie etapy działają stabilnie.

Test na 20–30 realnych zamówieniach. Przez 1–2 tygodnie pracuj równolegle: integracja działa, ale obsługa ręczna też, a Ty porównujesz wyniki. Warunek wyłączenia trybu ręcznego: 20–30 zamówień z rzędu bez ingerencji, w tym co najmniej jedno z płatnością odrzuconą, jedno z polskimi znakami w adresie i jedno z wysyłką zagraniczną, jeśli tak sprzedajesz.

Podział zadań. Klient przygotowuje dostępy i klucze API (bramka, kurier, ERP), decyzję, które statusy zamówień wyzwalają jaki dokument, dane do faktur oraz listę osób do alertów. Wykonawca robi mapowanie pól, kod integracji, logi, środowisko testowe, dokumentację i przekazanie wiedzy. Jeśli księgowość prowadzi firma zewnętrzna — wciągnij ją już na etapie dokumentu w ERP, nie po starcie.

Istniejący sklep a migracja. Na działającym sklepie integracje wdrażasz „obok” i wyłączasz jednym ustawieniem — ryzyko jest małe. Przy migracji ze starej platformy najpierw przenosisz dane i treści, uruchamiasz nowy sklep, a integracje dołączasz na końcu. Łączenie obu projektów naraz to najkrótsza droga do dwóch tygodni przestoju. Zakres i stawki dla takiego planu podajemy osobno w cenniku integracji z ERP, płatnościami i kurierami w Zamościu, a podobną kolejność stosujemy w firmach z okolic, m.in. przy integracjach z ERP, płatnościami i kurierami w Hrubieszowie.

Co się dzieje po wdrożeniu — monitoring, SLA i utrzymanie

Integracja nie psuje się w dniu startu, tylko trzy miesiące później — gdy operator zmieni wersję API, a nikt tego nie zauważy, bo zamówienia wciąż przychodzą. Dlatego odbiór prac powinien obejmować monitoring, nie tylko samo działanie funkcji.

Co monitorować	Próg alarmowy	Reakcja
Czas odpowiedzi API bramki i ERP	powyżej 3 s przez 5 minut z rzędu	automatyczny alert, sprawdzenie statusu u operatora
Nieudane zadania w kolejce	3 zadania w 15 minut	ponowienie, potem zgłoszenie
Zamówienia bez etykiety	starsze niż 4 godziny w godzinach pracy	ręczne nadanie i sprawdzenie przyczyny
Brak webhooków w ciągu dnia roboczego	cisza do godziny 10:00	weryfikacja konfiguracji endpointu i klucza

Elementy SLA, które warto uzgodnić na piśmie: okno reakcji (np. 4 godziny w dni robocze i 2 godziny w dniach promocyjnych), jeden kanał zgłoszeń zamiast trzech, ścieżka eskalacji — kto dzwoni, do kogo i po jakim czasie, jeśli przestój trwa dłużej, oraz zapis, czy dni promocyjne i święta są wliczone w okno, czy wyłączone. Bez tego w pierwszy czarny piątek dowiesz się, że „zgłoszenie przyjęte” oznacza odpowiedź w poniedziałek.

Aktualizacje po stronie sklepu, ERP i operatorów. Wersja WooCommerce czy PrestaShop potrafi zmienić strukturę zdarzeń, nowa wersja ERP — nazwy pól, a operatorzy płatności i kurierzy regularnie wygaszają stare wersje API. Zmiana adresu endpointu bramki, ogłoszona z 30-dniowym wyprzedzeniem, zatrzymuje sprzedaż dokładnie w dniu wyłączenia starej wersji. Ustal więc, kto śledzi komunikaty operatorów, kto testuje aktualizację na środowisku testowym i w jakim czasie. Zasady aktualizacji sklepu opisuje dokumentacja WooCommerce, a sposób prowadzenia takiej opieki w mniejszych firmach pokazujemy przy integracjach z ERP, płatnościami i kurierami w Narolu.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Mapa ośmiu kroków zamówienia — Wypisz kroki od złożenia zamówienia do faktury i przy każdym dopisz, kto go wykonuje. Zrób to przed rozmową o wtyczkach.
• Czas obsługi jednego zamówienia — Zmierz stoperem dziesięć kolejnych zamówień od otwarcia panelu do wysłania etykiety i porównaj wynik z widełkami 4–7 minut.
• Liczba zamówień miesięcznie — Policz średnią z ostatnich trzech miesięcy i sprawdź, czy zbliżasz się do 150–200 zamówień, czyli progu, przy którym integracja zwraca się najszybciej.
• Wersja i licencja systemu ERP — Ustal, czy pracujesz na Subiekcie GT, nexo, Optimie, WF-Mag czy WAPRO i czy licencja obejmuje kanał wymiany danych wymagany przez integrację.
• Kanał wymiany danych z ERP — Zapytaj dostawcę ERP, czy udostępnia API, Sferę, czy tylko odczyt bazy, i jakie ograniczenia ma każda z tych dróg.
• Źródło prawdy o stanach magazynowych — Zdecyduj, czy stanem zarządza ERP, czy sklep, i co robicie przy różnicy. Sprawdź to przed włączeniem rezerwacji stanu.
• Tabela mapowania statusów — Przygotuj zestawienie: status w bramce → status zamówienia → dokument w ERP. Przejrzyj je z osobą odpowiedzialną za księgowość.
• Lista statusów z bramki płatności — Pobierz z dokumentacji bramki wszystkie statusy i zdarzenia webhooków, także te dotyczące zwrotów i płatności odroczonych.
• Test braku webhooka — Zablokuj na próbę powiadomienia z bramki i sprawdź, czy zamówienie i tak zmieni status w rozsądnym czasie.
• Reguły wysyłki — Wypisz metody dostawy, limity wagi i wymiarów oraz obsługę punktów odbioru. Uzgodnij je z cennikiem przewoźnika przed włączeniem API.
• Procedura na wypadek przerwy w API przewoźnika — Ustal, kto generuje etykiety ręcznie i jak długo można tak pracować, zanim zamówienia zaczną się opóźniać.
• Obsługa zwrotów i ponownych wysyłek — Sprawdź, czy nowa etykieta na ponowną wysyłkę powstaje z tego samego zamówienia, czy wymaga nowego dokumentu.
• Osoba odpowiedzialna za alerty integracji — Wskaż konkretną osobę i kanał (mail, SMS, czat), który dostaje informację o błędzie zadania w tle.
• Test przedsezonowy — Przed okresem zwiększonego ruchu przejdź cały proces na kilku zamówieniach, w tym na jednym z płatnością odroczoną.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja