Integracje z ERP, płatnościami i kurierami to nie jeden projekt, tylko trzy spięcia, które muszą działać w kolejności zgodnej z procesem w firmie: zamówienie → faktura → płatność → etykieta → tracking. W firmach ze Zwierzyńca i okolic najczęstszy błąd to start od wyboru wtyczki, a nie od spisania procesów. Zanim wydasz pieniądze na wdrożenie, ustal wolumen zamówień, kanały sprzedaży i osobę, która po Twojej stronie odbiera poprawki. Poniżej masz typowe błędy, checklistę do odklikania i pytania, które warto zadać wykonawcy na pierwszym spotkaniu.
Integracja to ustalony przepływ danych między systemami. W sklepie wygląda zawsze tak samo: produkt → zamówienie → faktura → płatność → przesyłka → tracking. Każdy etap ma jedno źródło prawdy i jasno określonego odbiorcę.
Różnica między wtyczką a integracją dedykowaną jest prosta. Wtyczka to gotowy moduł: mapujesz kilka pól, wybierasz statusy i działa. Dedykacja wchodzi w grę, gdy ERP nie ma API, gdy masz kilka cenników B2B, gdy stany schodzą z dwóch magazynów albo gdy zamówienia przychodzą jednocześnie ze sklepu, Allegro i od przedstawiciela.
Przykład: firma z okolic Zwierzyńca sprzedająca części do maszyn rolniczych – ok. 40 zamówień dziennie, 12 000 SKU, Subiekt w wersji bez REST API. „Gotowa” wtyczka nie ma się z czym połączyć; potrzebny connector po bazie SQL albo wymiana plików.
Kolejność wdrażania ma znaczenie: ERP → płatności → kurierzy. ERP pierwsze, bo bez poprawnych stanów i faktur płatności nie mają czego zamykać. Płatności drugie, bo ich status wyzwala fakturę i zwalnia wysyłkę (przy pobraniu kolejność jest odwrotna). Kurierzy na końcu, bo etykieta potrzebuje już poprawnego zamówienia i znanego statusu płatności. Jeśli pracujesz na PrestaShop, punktem wyjścia do rozmowy z wykonawcą jest dokumentacja dla deweloperów PrestaShop. Zakres takiego wdrożenia opisujemy też na stronie integracji z ERP, płatnościami i kurierami dla firm ze Zwierzyńca.
| Etap | Źródło prawdy | Co przesyłamy | Co się psuje najczęściej |
|---|---|---|---|
| Produkt | ERP | SKU, nazwa, cena, stan, jednostka | Ceny zmieniane ręcznie w sklepie – rozjazd z ERP |
| Zamówienie | Sklep | Pozycje, adres, forma dostawy i płatności | Duplikaty po ponownym kliknięciu „Złóż zamówienie” |
| Faktura | ERP | Numer, data, kwota, plik PDF | Faktura wystawiona przed potwierdzeniem płatności |
| Płatność | Operator płatności | Status: nowa, opłacona, anulowana, zwrot | Status „oczekująca” nie zmienia się po zaksięgowaniu przelewu |
| Przesyłka | Przewoźnik | Etykieta PDF, numer tracking, waga, gabaryt | Metoda dostawy w sklepie bez mapowania na usługę u przewoźnika |
Pierwszy krok to nie wybór wtyczki, a spisanie procesów. Wystarczy arkusz z siedmioma kolumnami: krok, kto wykonuje, w jakim systemie, ile trwa, jaki dokument powstaje, co może pójść nie tak, kto poprawia błąd. Wypełniasz go razem z osobami, które faktycznie klikają w ERP i drukarce etykiet – nie z zarządem.
Do spisania są co najmniej: przyjęcie zamówienia, rezerwacja stanu, wystawienie WZ lub faktury, potwierdzenie płatności, kompletacja, wygenerowanie etykiety, wysyłka tracking-u, przyjęcie zwrotu, korekta faktury i ponowne nadejście towaru na magazyn.
Pytania o wolumen zadaj sobie na piśmie, bo od nich zależy, czy wdrożenie ma sens finansowy:
Rachunek dla firmy z okolic Zwierzyńca: 20 zamówień dziennie × 22 dni robocze = 440 dokumentów miesięcznie. Ręczne przepisanie zamówienia do ERP zajmuje 2–4 minuty, czyli 15–30 godzin miesięcznie. Przy 100 zamówieniach dziennie to już ponad 100 godzin – etat wypełniony tylko przepisywaniem.
Przykład mapy dla firmy B2B: zamówienie od stałego klienta mailem → wpis do ERP i WZ → faktura z 14-dniowym terminem → etykieta u przewoźnika → tracking mailem do klienta. Kluczowa decyzja: przy odroczonym terminie etykieta nie może czekać na płatność, inaczej towar leży na magazynie. Ustalenie tego na etapie mapy oszczędza potem tygodnie przeprojektowywania. Podobny układ procesów opisujemy przy okazji spięcia ERP, płatności i kurierów w Narolu.
| Krok w procesie | Kto wykonuje | Ile trwa ręcznie | Ryzyko |
|---|---|---|---|
| Przyjęcie zamówienia ze sklepu | Handel / biuro | 2–4 min na dokument | Pominięte zamówienie w szczycie |
| Rezerwacja stanu | Magazyn | 1–2 min | Sprzedaż towaru, którego nie ma |
| Wystawienie WZ / faktury | Księgowość | 3–5 min | Faktura przed potwierdzeniem płatności |
| Potwierdzenie płatności | Księgowość | 1–2 min na przelew | Wysyłka przed zaksięgowaniem |
| Etykieta i tracking | Magazyn | 3–6 min | Błędny adres, brak mapowania usługi |
W praktyce spięcie sklepu z ERP obejmuje sześć strumieni: produkty, stany magazynowe, ceny, zamówienia, faktury i statusy płatności. Każdy ma inną częstotliwość i inne wymagania:
Tryby integracji, które spotkasz w polskich MŚP: REST API, webservice SOAP/XML, pliki CSV/XML wymieniane na FTP lub w udostępnionym katalogu oraz bezpośrednie połączenie z bazą przez ODBC. Do tego kolejka komunikatów (RabbitMQ, Redis), gdy wolumen przekracza kilkaset zamówień dziennie albo gdy API ERP ma limity zapytań.
Co sprawdzić przed wdrożeniem, niezależnie od tego, czy pracujesz na Subiekcie, Comarch ERP Optima, WF-Mag czy enova365:
Dla WooCommerce punktem odniesienia jest oficjalna dokumentacja WooCommerce, a wycenę i zakres takiego spięcia znajdziesz w cenniku integracji z ERP, płatnościami i kurierami w Zamościu. Uwaga na CSV: SKU z wiodącymi zerami potrafi „zgubić” cyfry po drodze.
| Tryb | Kiedy stosować | Typowy wolumen | Główne ryzyko |
|---|---|---|---|
| REST API | ERP ma udokumentowane API i licencję dopuszczającą połączenia zewnętrzne | od kilkuset zamówień miesięcznie w górę | Limity zapytań i brak środowiska testowego |
| Webservice SOAP/XML | Starsze wersje ERP z web service | kilkaset – kilka tysięcy dokumentów miesięcznie | Mało czytelne błędy, trudne logowanie zdarzeń |
| Pliki CSV/XML | ERP nie ma API, pracuje na plikach wymiany | kilka – kilkaset dokumentów dziennie | Konflikt nazw plików przy równoległym imporcie |
| Połączenie z bazą (ODBC) | ERP oparty o SQL, chcemy stany blisko czasu rzeczywistego | dowolny | Aktualizacja ERP może zepsuć integrację; dostęp tylko do odczytu |
| Kolejka komunikatów | Duży wolumen albo kilka kanałów sprzedaży naraz | od ok. 500 zamówień dziennie | Trzeba utrzymywać dodatkową usługę i pilnować zaległości |
Integracja płatności to trzy elementy: widget lub przekierowanie na stronie sklepu, webhook od bramki i mapowanie statusów w ERP. Najczęściej spotykane bramki w polskich sklepach to Przelewy24, PayU, tpay i Stripe. Każda obsługuje inny zestaw metod: BLIK, kartę, szybki przelew, Google Pay i Apple Pay, a PayU dodatkowo płatności odroczone. Każda włączona metoda to osobny scenariusz testowy — nie włączaj wszystkich na start.
Webhook (w Przelewy24 „notification URL”, w Stripe „webhook endpoint”) przychodzi z podpisem i ten podpis trzeba weryfikować. Bez tego każdy może wysłać fałszywe „opłacone”. Przelewy24 podpisuje komunikaty kluczem CRC, Stripe używa nagłówka Stripe-Signature, tpay i PayU mają własne schematy. Wtyczka, która nie sprawdza podpisu, jest dziurawa.
Statusy z bramki muszą być zmapowane 1:1 na statusy w ERP. Brak mapowania chargebacku kończy się tak, że po 60–120 dniach bank zabiera pieniądze, a zamówienie wciąż wisi jako opłacone i wysłane.
Najczęstsza pułapka: płatność zaksięgowana, a zamówienie nie trafia do ERP. Powód to zwykle timeout — sklep dostał webhook, ale ERP nie odpowiedział w kilka sekund i bramka uznała, że nie dostarczyła danych. Rozwiązanie: kolejka (tabela w bazie, Redis albo RabbitMQ) i ponawianie co 5 minut, maksymalnie 5 prób, z logiem po ID zamówienia. Konieczna jest też idempotencja — ten sam webhook może przyjść dwa razy i nie może utworzyć dwóch zamówień.
Przed wdrożeniem przećwicz: sandbox bramki, podwójny webhook, przerwanie połączenia w połowie, anulowanie po opłaceniu, zwrot pełny i częściowy, chargeback. Mapowanie statusów dla WooCommerce opisuje dokumentacja WooCommerce — warto ją pokazać wykonawcy jako punkt odniesienia. Płatność za pobraniem zostaw tylko tam, gdzie klient naprawdę tego wymaga: pieniądze wracają dopiero po doręczeniu, a odsetek zwrotów jest wyraźnie wyższy niż przy BLIK-u. Zakres takiego spięcia opisaliśmy też w materiale o integracjach z ERP, płatnościami i kurierami – Zwierzyniec.
| Status z bramki | Status w ERP | Co powinien zrobić system |
|---|---|---|
| paid / opłacona | opłacone | wystaw fakturę, zwolnij do wysyłki, wygeneruj etykietę |
| pending / nowa | nowe | czekaj 30–60 min, potem anuluj i zwolnij stan magazynowy |
| cancelled / anulowana | anulowane | zwolnij rezerwację, wyślij info do klienta |
| refund / zwrot | zwrot | wystaw korektę faktury, sprawdź, czy paczka wróciła |
| chargeback | reklamacja | zablokuj wysyłkę, powiadom księgowość i handlowca |
Kolejność jest zawsze ta sama: zamówienie w sklepie → etykieta u kuriera → numer przesyłki z powrotem w ERP → manifest → tracking. Każdy krok ma inne API i inne pułapki.
InPost działa przez ShipX API, DPD przez WebAPI, DHL przez DHL24 WebAPI2 lub DHL Parcel API. Różnice, które najczęściej psują wdrożenie:
Manifest to lista przesyłek, którą kurier skanuje przy odbiorze. Bez manifestu przewoźnik może nie odebrać paczek z magazynu, a rozliczenie pokaże przesyłki, których nigdy nie nadałeś.
Tracking: nie odpytuj API co minutę, bo przy kilkuset przesyłkach szybko trafisz w limit zapytań. InPost i DPD mają powiadomienia o zmianie statusu; jeśli ich nie używasz, rób poll co 30–60 minut i trzymaj wynik w cache. Numer przesyłki musi wrócić do ERP i do maila do klienta — najczęstszy błąd to etykieta wygenerowana, a klient bez informacji o wysyłce.
Scenariusze do odklikania: wydruk etykiety, duplikat zamówienia (czy nie powstanie druga etykieta i drugi koszt), manifest, zmiana statusu trackingu, zwrot, reklamacja uszkodzonej paczki, anulowanie po wygenerowaniu etykiety. Podobny zakres dla mniejszych miejscowości opisaliśmy przy okazji integracji z ERP, płatnościami i kurierami w Narolu.
| Przewoźnik | API | Paczkomaty / punkty | Pobranie (COD) | Manifest |
|---|---|---|---|---|
| InPost | ShipX API | tak, kod punktu + rozmiar A/B/C | tak, niższe limity przy paczkomacie | wymagany przed odbiorem |
| DPD | WebAPI | DPD Pickup jako osobna usługa | tak | tak |
| DHL | DHL24 WebAPI2 / DHL Parcel API | DHL POP jako osobna usługa | tak | zależnie od umowy |
Wycena to godziny razy stawka. Na rynku stawka wdrożeniowca to zwykle 120–250 zł netto za godzinę — im bardziej nietypowy system, tym wyżej. Standardowa integracja (sklep + jedno ERP + jedna bramka + jeden kurier) to 20–60 godzin. Nietypowa — 80–150 godzin — wychodzi wtedy, gdy ERP jest własny albo mocno zmodyfikowany, gdy dane są brudne (kartoteki bez EAN, jednostki miary wpisane w opis), gdy jest kilku kurierów i kilka kanałów sprzedaży.
Co konkretnie podbija wycenę:
Do wdrożenia dochodzi utrzymanie: monitoring integracji, aktualizacje po zmianach API, abonament miesięczny zależny od zakresu. Zapytaj wykonawcę wprost, czy utrzymanie jest w cenie wdrożenia, czy płatne osobno — różnica w skali roku bywa większa niż samo wdrożenie.
Rozbicie na etapy i stawki znajdziesz w naszym cenniku integracji ERP, płatności i kurierów w Zamościu oraz w omówieniu kosztu integracji ERP, płatności i kurierów. Oba materiały są po to, żebyś porównał oferty punkt po punkcie, a nie tylko po cenie końcowej.
| Etap | Zakres standardowy | Zakres nietypowy |
|---|---|---|
| Analiza i mapowanie procesu | 3–6 h | 10–20 h |
| Integracja płatności | 5–12 h | 15–30 h |
| Integracja kurierska (etykiety, tracking) | 5–16 h | 20–40 h |
| Integracja z ERP (zamówienia, faktury, stany) | 7–20 h | 30–55 h |
| Testy i odbiór | 2–6 h | 5–10 h |
Trzy rzeczy psują integracje najczęściej: zdublowane zamówienia, ciche błędy komunikacji i brak logów. Każdą da się wykryć przed podpisaniem odbioru — trzeba testować scenariusze, a nie sprawdzać, „czy działa”.
Duble zamówień i stany magazynowe. Test współbieżny robi się prosto: dwie przeglądarki, dwa konta, ostatnia sztuka towaru, kliknięcie „Kupuję i płacę” w tej samej sekundzie. Powtórz 10 razy. Jeśli w ERP pojawią się dwa zamówienia albo stan spadnie do -1, nie ma blokady na poziomie SKU. Drugi test: wyślij ten sam koszyk dwa razy w odstępie 30 sekund i sprawdź, czy sklep rozpoznaje duplikat po ID sesji.
Webhooki płatności. Bramki wysyłają powiadomienie częściej niż raz — po retry, po timeoutcie, po ręcznym ponowieniu z panelu. Sprawdź idempotencję: ten sam identyfikator transakcji wysłany dwa razy nie może dać dwóch faktur ani dwóch maili. W panelu większości bramek jest funkcja ponownego wysłania webhooka — użyj jej w testach. Klasyczny błąd to status „opłacone” przy zamówieniu bez pieniędzy na koncie. Jeśli sklep stoi na WooCommerce, mechanikę webhooków opisuje dokumentacja WooCommerce i warto oprzeć na niej scenariusze testowe.
Limity API i timeouty. ERP (Subiekt, Optima, enova) ma limity zapytań i własne timeouty. Zrób test na podwójnym szczycie: 100–200 zamówień w godzinie. Obserwuj kody 429, komunikaty o przekroczonym limicie i czas odpowiedzi. Wymagaj kolejki z ponowieniami: 3 próby w odstępach 1 / 5 / 15 minut. Bez tego minuta niedostępności API oznacza brak etykiety, o którym nikt się nie dowie.
Logi i monitoring. Przed go-live ustal alerty: webhook nieobsłużony dłużej niż 2 minuty, błąd API trzy razy pod rząd, brak etykiety 15 minut po statusie „do wysyłki”. Dashboard ma pokazywać cztery liczby: zamówienia, opłacone, z etykietą, w błędzie. Do tego ręczny przycisk „ponów” i zapis każdej nieudanej próby.
| Pułapka | Jak ją wykryć przed wdrożeniem | Minimum do ustawienia |
|---|---|---|
| Duble zamówień | 2 przeglądarki, ostatnia sztuka towaru, 10 prób | blokada po SKU/sesji, log duplikatów |
| Powtórzony webhook płatności | ręczne ponowienie z panelu bramki | idempotencja po identyfikatorze transakcji |
| Limit API ERP | 2x szczyt, 100–200 zamówień na godzinę | kolejka 3 prób: 1 / 5 / 15 minut |
| Brak logów | celowe wyłączenie API na 5 minut | alert, dashboard, ręczny retry |
Wydrukuj tę listę i przejdź ją z wykonawcą punkt po punkcie. Jeśli któryś punkt nie ma odpowiedzi, wdrożenie się nie zaczyna — nie dlatego, że ktoś nie umie, ale dlatego, że brakuje decyzji po Twojej stronie.
Pełny zakres tego, co sprawdzamy przy takich projektach, opisuje strona integracji z ERP, płatnościami i kurierami – Zwierzyniec. Jeśli zastanawiasz się nad stawkami, pomocny będzie cennik integracji w Zamościu, bo prace są tam wyceniane w podobnych przedziałach.
| Obszar | Decyzja do podjęcia | Kto ją zatwierdza |
|---|---|---|
| ERP | która wersja i kto daje dostęp do API | księgowość / IT |
| Płatności | lista bramek i walut, obsługa zwrotów | właściciel / księgowość |
| Kurierzy | które firmy i jakie usługi w pierwszej kolejności | logistyka |
| Budżet | wdrożenie plus opieka na 12 miesięcy | właściciel |
| Termin | data startu z buforem 2 tygodni | właściciel i wykonawca |
Integracja nie kończy się na dniu uruchomienia. Zmieniają się wersje ERP, bramka modyfikuje API, kurier dodaje usługę — i wtedy wychodzi, czy ktoś to monitoruje.
Monitoring i kopie zapasowe. Wymagaj sprawdzania kolejki i połączeń z API co minutę. Alerty mają iść mailem i SMS-em, nie tylko na tablicę w panelu. Kopie zapasowe bazy sklepu: codziennie, retencja 30 dni. Osobno zapisuj konfigurację integracji (mapowania SKU, reguły statusów) przy każdej zmianie. Backup bez testu odtworzenia raz na kwartał to nie backup, tylko nadzieja.
Procedura reakcji. Ustal kategorie zgłoszeń: krytyczne (brak faktur lub etykiet, sklep nie przyjmuje płatności), wysokie (błędne stany), niskie (kosmetyka). Zgłoszenie przyjmowane mailem i telefonem, z potwierdzeniem przyjęcia, nie przez formularz kontaktowy. Wpisz, kto eskaluje, jeśli pierwsza linia nie rozwiąże problemu w założonym czasie.
Czasy i okna serwisowe. Realne wartości dla małego i średniego biznesu: reakcja 4 godziny w dni robocze dla krytycznych, naprawa 8 godzin, pozostałe 1 dzień roboczy. Okno serwisowe raz w tygodniu, zgłaszane 3 dni wcześniej. W umowie musi być zapis, że awaria po stronie bramki, ERP lub kuriera nie zwalnia wykonawcy z diagnozy — ma zgłosić problem dostawcy, a nie odesłać Cię z numerem infolinii. Kontakt do dewelopera, który zna kod, bez pośrednictwa handlowca. Tak wyglądają wdrożenia integracji w Hrubieszowie i podobnych miejscowościach, gdzie w firmie nie ma działu IT.
Jak mierzyć jakość opieki. Trzy liczby: liczba incydentów w miesiącu, średni czas naprawy, procent zamówień przetworzonych bez ręcznej pracy. Raport miesięczny do 5. dnia: co się stało, co poprawiono, co zaplanowano.
| Parametr | Wartość do wpisania w umowie | Po co to |
|---|---|---|
| Czas reakcji – krytyczne | 4 h w dni robocze | wiesz, kiedy ktoś zaczyna działać |
| Czas naprawy – krytyczne | 8 h | brak faktur i etykiet blokuje wysyłki |
| Czas reakcji – pozostałe | 1 dzień roboczy | porządkuje drobne poprawki |
| Okno serwisowe | 1 raz w tygodniu, powiadomienie 3 dni wcześniej | planujesz wysyłki i promocje |
| Kopie zapasowe | dzienne, retencja 30 dni, test odtworzenia raz na kwartał | sprawdzasz, czy da się wrócić |
| Raport | miesięczny, do 5. dnia miesiąca | masz podstawę do oceny opieki |
Wybór technologii przed spisaniem procesów — firma wybiera ERP albo wtyczkę, nie wiedząc, kto dziś wystawia WZ, kto fakturę, a kto drukuje etykietę.
Jak wykryć: Zadaj trzy pytania: kto wystawia fakturę, w jakim programie i co się dzieje, gdy ktoś jest na urlopie. Jeśli odpowiedzi są różne od osób, które faktycznie to robią, proces nie jest spisany.
Jak naprawić: Zrób jednostronicową mapę procesu na kartce: zamówienie → WZ → faktura → etykieta → tracking → zwrot. Dopiero do tej mapy dobieraj systemy i zakres integracji.
Pominięcie zwrotów i reklamacji w zakresie projektu — integracja obsługuje sprzedaż, a zwrot trzeba wprowadzać ręcznie do ERP i magazynu.
Jak wykryć: Policz zwroty z ostatnich 3 miesięcy i sprawdź, ile czasu zajmuje ich ręczne zaksięgowanie. Jeśli nikt tego nie liczył, to znaczy, że temat wypadł z zakresu.
Jak naprawić: Dopisz zwroty do zakresu jako osobny scenariusz: przyjęcie paczki, decyzja, korekta faktury, korekta stanu magazynowego, informacja do klienta.
Brak testów współbieżnych — dwa zamówienia na ostatnią sztukę są przyjmowane jednocześnie i stan magazynowy schodzi poniżej zera.
Jak wykryć: Ustaw sztucznie stan 1 na produkcie i złóż dwa zamówienia w tym samym momencie z dwóch przeglądarek. Powtórz test 10 razy.
Jak naprawić: Ustal, który system jest źródłem prawdy o stanie magazynowym, i włącz blokadę lub kolejkę zapytań. Sklep nie może sprzedać tego, czego nie ma ERP.
Zaufanie do webhooków płatności po jednym udanym teście — płatność księguje się w bramce, ale zamówienie nie trafia do ERP.
Jak wykryć: Wykonaj 5 płatności testowych różnymi metodami (BLIK, karta, przelew) i sprawdź w ERP, czy każda z nich ma fakturę i status opłacone. Potem powtórz to samo na produkcji na minimalnej kwocie.
Jak naprawić: Wymagaj obsługi ponowień i ręcznego dosyłania zdarzeń. Ustal, jak wygląda sytuacja, gdy webhook dotrze dwa razy — system nie może wystawić dwóch faktur.
Brak logów i monitoringu przed startem — po tygodniu nikt nie wie, ile zamówień nie przeszło i od kiedy.
Jak wykryć: Zapytaj wykonawcę: gdzie zobaczę błąd integracji z wczoraj i jak dostanę o nim informację? Jeśli odpowiedź brzmi „w logach na serwerze”, to za mało.
Jak naprawić: Ustal przed go-live: dziennik zdarzeń, alert e-mail przy błędzie krytycznym, widok liczby nieudanych synchronizacji i zasadę ponowień.
Założenie, że ERP ma gotowe API w każdej wersji — zakres projektu jest wyceniany bez sprawdzenia wersji i licencji.
Jak wykryć: Poproś o dokładną wersję ERP, numer licencji i informację, czy webservice jest w niej włączony. Sprawdź to na środowisku testowym, nie w dokumentacji zakupowej.
Jak naprawić: Zanim podpiszesz zakres, potwierdź na testowym środowisku jedno proste wywołanie: pobranie listy produktów i wysłanie zamówienia. Jeśli to nie działa, wróć do ustaleń.
Integracje z ERP, płatnościami i kurierami układają się w stałą kolejność: najpierw procesy, potem ERP, następnie płatności, na końcu kurierzy. Największe oszczędności nie wynikają z wyboru narzędzia, ale z dobrego spisania tego, kto co robi i co się dzieje przy zwrocie. Testy webhooków, współbieżne zamówienia i monitoring przed startem kosztują kilka godzin, a oszczędzają tygodnie poprawek po go-live. Jeśli przejdziesz checklistę przed rozmową z wykonawcą, rozmowa będzie o zakresie, a nie o domysłach.
Od mapy procesów, nie od wyboru wtyczki. Spisz na jednej kartce, jak dziś wygląda droga zamówienia: kto je przyjmuje, kto wystawia WZ i fakturę, kto drukuje etykietę i co się dzieje przy zwrocie. Dopiero do tej mapy dobierasz ERP, bramkę płatności i system kurierski.
Tak. ERP jest źródłem prawdy o stanie magazynowym i dokumentach, więc idzie pierwszy. Płatności są drugie, bo bez poprawnych statusów nie wiadomo, które zamówienie wolno realizować. Kurierzy są ostatni — etykieta i tracking to efekt zamówienia, a nie jego początek.
Oba mają dokumentację dla deweloperów i działające mechanizmy API, więc wybór zależy od Twojego ERP i tego, kto będzie utrzymywał sklep. Zobacz dokumentację PrestaShop dla deweloperów oraz dokumentację WooCommerce i sprawdź, czy istnieją gotowe łączniki do Twojego systemu ERP.
Musisz mieć plan awaryjny: listę płatności z bramki i możliwość ręcznego dosłania zdarzenia. W praktyce oznacza to, że ktoś raz dziennie porównuje raport z bramki z listą zamówień w ERP. Bez takiej kontroli płatność zostaje w bramce, a zamówienie nie idzie do realizacji.
Standardowe spięcie sklepu z ERP, bramką płatności i kurierami to zwykle 20–60 godzin pracy wykonawcy, rozłożone na kilka tygodni kalendarzowo. Projekty nietypowe — z rozbudowaną logiką magazynową, wieloma kanałami sprzedaży albo starym ERP bez API — zajmują 80–150 godzin. Termin zależy też od tego, jak szybko po Twojej stronie zapadają decyzje.
Na cenę wpływa liczba systemów, jakość API po stronie ERP, ilość danych do przeniesienia, zakres testów i to, czy chcesz umowę na utrzymanie. Konkretne przedziały znajdziesz na stronach cennik integracji i koszt integracji.
Wtyczka wystarcza, gdy proces jest typowy: jedno źródło magazynu, jedna bramka płatności, jeden kurier. Integracja dedykowana jest potrzebna, gdy masz nietypowe reguły rabatowe, kilka magazynów, własne statusy zamówień albo ERP bez gotowego łącznika. Ocenę zawsze zaczynaj od mapy procesów, nie od listy wtyczek.
Jeśli chcesz przejść taką checklistę razem z nami, zobacz, jak podchodzimy do integracji z ERP, płatnościami i kurierami dla firm ze Zwierzyńca. Wystarczy krótka rozmowa o Twoich procesach, żeby wiedzieć, co jest realne, a co warto odłożyć na później.