Integracja sklepu z ERP, bramką płatniczą i kurierem to nie trzy osobne projekty, a jedna historia o danych, które muszą przejść tę samą drogę w obie strony. Zanim wybierzesz moduł czy wtyczkę, spisz na kartce, jak dziś wygląda obieg zamówienia, kto przepisuje dane ręcznie i ile minut mu to zajmuje. Poniżej masz kolejność działań, listę pól do mapowania, kryteria wyboru operatora płatności i kuriera oraz orientacyjne widełki godzinowe. Bez tego kroku integracja kończy się rozjazdem stanów magazynowych i zamówieniami oznaczonymi jako opłacone, choć wpłaty nie ma.
Zacznij od kartki, nie od panelu administracyjnego. Wypisz cztery obszary: stany magazynowe, zamówienia, wysyłki, płatności. Przy każdym zanotuj trzy rzeczy: skąd dane przychodzą, gdzie są nadpisywane i kto robi to ręcznie.
Pytanie kontrolne, które rozstrzyga o całym projekcie brzmi: kto dziś ręcznie przepisuje zamówienia i ile minut mu to zajmuje dziennie? Jeśli jedna osoba poświęca 40 minut na 20 zamówień, to miesięcznie około 13 godzin pracy. To liczba, do której wrócisz przy wycenie — integracja musi być tańsza niż ten czas, inaczej nie ma po co jej wdrażać.
Rozdziel dwie rzeczy, które klienci nagminnie mylą: integrację jednokierunkową i dwukierunkową. Jednokierunkowa to na przykład eksport stanów z ERP do sklepu raz na godzinę — sklep tylko czyta i nic nie odsyła. Dwukierunkowa to sytuacja, w której sklep wysyła zamówienie do ERP, a ERP odsyła numer faktury i status „spakowane”. Przykład: sklep w Krasnobrodzie wystawiał dokumenty ręcznie, bo ERP nie dostawał informacji o anulowaniu zamówienia przez klienta. Wystarczyło dorzucić drugi kierunek, żeby zniknęła połowa telefonów.
Kiedy integracja nie ma sensu? Jeśli firma ma mniej niż około 5 zamówień dziennie, arkusz Google albo eksport CSV z ERP bywa tańszy i szybszy we wdrożeniu. Integracja to nie cel sam w sobie, a koszt: moduł, konfiguracja, utrzymanie i ktoś, kto zrozumie ją po roku. Zanim zamówisz integrację sklepu z ERP, płatnościami i kurierami w Krasnobrodzie, przejdź tę kartkę jeszcze raz na spokojnie.
| Obszar | Co spisać | Pytanie kontrolne |
|---|---|---|
| Stany magazynowe | Kto zatwierdza dokumenty magazynowe i o której godzinie | Czy sklep sprzedaje to, co ERP już odjęło? |
| Zamówienia | Skąd wchodzą zamówienia i gdzie trafiają | Ile osób je przepisuje i jak długo? |
| Wysyłki | Kto generuje etykiety i numery nadania | Czy numer wraca do klienta automatycznie? |
| Płatności | Kto potwierdza wpływ na konto | Czym różni się status opłacone od faktycznej wpłaty? |
ERP jest źródłem prawdy o towarze, cenie i stanie. Sklep tylko je prezentuje. Zanim cokolwiek podłączysz, ustal mapowanie pól. Minimum to: SKU (klucz łączący oba systemy — musi być identyczny, bez spacji i zer wiodących), EAN, cena netto i brutto (zdecyduj, którą trzyma ERP — mieszanie ich to najczęstsza przyczyna rozjazdu o wartość VAT), stan magazynowy, jednostka miary (szt./kg/m — inaczej stany przy sprzedaży ułamkowej się rozjadą), stawka VAT oraz kategoria.
Częstotliwość synchronizacji dobierz do realnego ruchu, nie do „na wszelki wypadek”. Raz na 15 minut ma sens, gdy ten sam towar sprzedajesz na kilku kanałach i magazyn zmienia się w ciągu dnia. Raz na godzinę wystarcza przy jednym sklepie i jednym magazynie. Webhook jest najszybszy, ale wymaga, żeby ERP samo powiadamiało o zdarzeniu — a nie tylko udostępniało bazę do odpytywania.
Typowe ERP w polskich MŚP to Subiekt GT, Comarch Optima, WAPRO, Fakturownia i enova365. Każde daje inny dostęp: jedne mają REST API, inne wymagają Sfery, plików wymiany albo odpytywania bazy. Sprawdź to przed wyceną, bo „mamy API” bywa prawdą tylko w najdroższej licencji.
Pułapka numer jeden: ERP liczy stan po dokumentach magazynowych wystawionych w biurze, a sklep odejmuje rezerwacje koszyka. Klient trzyma dwie sztuki w koszyku przez 20 minut i ERP ich nie widzi. Rozwiązanie: krótki czas życia rezerwacji po stronie sklepu plus bufor bezpieczeństwa — sprzedawaj dopiero wtedy, gdy w ERP jest zapas większy niż jeden. Gdy ERP nie ma API, zostaje eksport XML/CSV, kolejka plików na SFTP i cron, który je pobiera. O wariantach dla mniejszych miejscowości piszemy przy okazji integracji z ERP dla firm w Hrubieszowie.
| Tryb synchronizacji | Kiedy wystarcza | Główne ryzyko |
|---|---|---|
| Co 15 minut | Kilka kanałów sprzedaży, ruch w ciągu dnia | Krótkie okno sprzedaży ponad stan |
| Co godzinę | Jeden sklep, jeden magazyn | Przedłużony rozjazd po dostawie |
| Webhook | ERP wysyła zdarzenia po stronie systemu | Brak obsługi błędów = cicha utrata zdarzenia |
Bramkę wybieraj po kryteriach, nie po logo. Sprawdź prowizję (stawki są negocjowalne, przy stałym obrocie pytaj o cennik indywidualny), dostępność BLIK-a, pay-by-link (przydatny, gdy klient zamawia telefonicznie i chcesz wysłać mu link do zapłaty), kart wraz z Apple Pay i Google Pay, płatności odroczonych oraz terminy wypłat — T+1 czy T+7 robi różnicę, jeśli towarem obracasz szybko i kupujesz za gotówkę.
Na polskim rynku spotkasz Przelewy24, PayU, Tpay, Autopay, Stripe, PayPal i Paynow. Kolejność podłączania jest zawsze podobna: konto sandbox, klucze API (trzymaj je w pliku konfiguracyjnym poza repozytorium), endpoint webhooka na HTTPS, test transakcji na 1 zł z pełnym zwrotem, potem wyłączenie trybu testowego. Dokumentacja techniczna modułu płatności dla WooCommerce jest opisana w dokumentacji WooCommerce, a dla PrestaShop w dokumentacji dla deweloperów PrestaShop — warto zajrzeć, zanim ktoś wgra wtyczkę z nieznanego źródła.
Pułapka pierwsza: brak weryfikacji podpisu webhooka. Endpoint przyjmujący powiadomienia jest publiczny, więc bez sprawdzenia sygnatury, kwoty i identyfikatora transakcji każdy może wysłać POST i oznaczyć zamówienie jako opłacone bez wpłaty. Pułapka druga: podwójne księgowanie. Jeśli status zamówienia zmieniasz i w sklepie, i w ERP, powstają dwa źródła prawdy i dwa dokumenty. Ustal jedno miejsce — najlepiej bramka potwierdza wpłatę webhookiem, sklep zmienia status tylko na tej podstawie, a ERP dostaje wyłącznie dane do faktury. Wyceny takich wdrożeń znajdziesz w naszym cenniku integracji w Zamościu.
| Kryterium | Na co patrzeć | Dlaczego to ważne |
|---|---|---|
| Prowizja | Stawka od transakcji i koszt zwrotu | Wpływa wprost na marżę przy niskiej cenie |
| BLIK | Czy działa bez dodatkowej umowy | Najczęstsza metoda płatności w Polsce |
| Pay-by-link | Możliwość wysłania linku do zapłaty | Obsługa zamówień telefonicznych i e-mailowych |
| Wypłaty | T+1 czy T+7 | Płynność, gdy towar kupujesz z góry |
| Odroczone płatności | Dostępność i koszt dla sprzedawcy | Podnoszą konwersję na droższych koszykach |
Łańcuch jest zawsze taki sam, niezależnie od przewoźnika: zamówienie → utworzenie przesyłki przez API → etykieta PDF → numer trackingowy zapisany przy zamówieniu → mail do klienta → statusy doręczenia → zamknięcie zamówienia i obsługa zwrotu. Różnią się tylko nazwy pól i formaty danych.
Integracja obejmuje:
Gotowa wtyczka czy własny moduł? Wtyczka wystarcza, gdy wysyłasz jednorodne paczki i nie masz nietypowych reguł. Własny moduł jest tańszy w utrzymaniu, gdy dochodzi podział zamówienia na kilka paczek, darmowa dostawa od progu, wysyłka z dwóch magazynów albo ERP narzuca własne statusy — wtedy każda aktualizacja cudzego kodu oznacza łatanie. Punkt wyjścia do decyzji znajdziesz w dokumentacji dla deweloperów PrestaShop, a pełny zakres prac opisujemy w usłudze integracje z ERP, płatnościami i kurierami w Krasnobrodzie.
Dwie pułapki, które widzimy najczęściej:
Wycena rozbija się na sześć bloków. Każdy ma inną niepewność, dlatego pytaj o godziny osobno, a nie o jedną kwotę za całość.
Rozliczenie w godzinach jest uczciwsze niż ryczałt, bo zmiana zakresu jest widoczna od razu — dodajesz drugiego kuriera i wiesz, że to 5 h, a nie spór o aneks.
Nie zapomnij o utrzymaniu. Kurierzy i bramki zmieniają API i wygaszają tokeny. Zakładaj 8–20 h rocznie na aktualizacje i drobne poprawki, nawet jeśli nie zmieniasz niczego w sklepie. Kolejny rok bez tego budżetu oznacza dzień, w którym etykiety przestają się generować.
Punkt odniesienia dla ofert z regionu znajdziesz w naszej sekcji integracje z ERP, płatnościami i kurierami w Zamościu – cennik.
| Etap | Widełki | Od czego zależy szerokość widełek |
|---|---|---|
| Analiza i mapowanie | 4–8 h | Liczba pól, liczba statusów, kto dziś przepisuje dane ręcznie |
| Integracja z ERP | 20–60 h | REST API czy pliki przez FTP, jakość dokumentacji, kolejkowanie zmian |
| Płatności | 4–10 h | Jedna bramka czy kilka metod, raty, waluty, obsługa zwrotów |
| Kurierzy | 6–16 h (pierwszy), 3–8 h (kolejny) | Liczba gabarytów, listy wysyłkowe, webhooki statusów |
| Testy | 6–12 h | Liczba scenariuszy: zwrot, anulowanie, ponowienie webhooka |
| Dokumentacja | 3–6 h | Czy klient przejmuje obsługę, czy zostaje na wsparciu |
Zrób z tych sześciu punktów listę kontrolną i przejrzyj ją raz w miesiącu. Nie chodzi o to, żeby nic się nie zepsuło — chodzi o to, żebyś dowiedział się o tym przed klientem.
| Sygnał | Co sprawdzić | Gdzie szukać |
|---|---|---|
| Rozjazd stanów | Data ostatniej synchronizacji i długość kolejki zmian | Logi integracji po stronie ERP |
| Podwójne zamówienia | Czy ten sam identyfikator zdarzenia pojawia się dwa razy | Log webhooków sklepu |
| Zawieszone etykiety | Limity zapytań i ważność tokenu | Panel integracji u kuriera |
| Fałszywe „opłacone” | Weryfikacja sygnatury, kwoty i waluty | Kod odbiornika webhooka |
| Rozjazd VAT | Suma zamówienia ze stawkami mieszanymi | Zestawienie sklep vs faktura w ERP |
| Brak alertów | Próg alertu i raport dzienny | Monitoring logów i kolejki zadań |
Po wdrożeniu integracja nie przestaje się zmieniać. PrestaShop wydaje kolejne wersje, WooCommerce aktualizuje wtyczki, a kurierzy i operatorzy płatności modyfikują API: zmieniają nazwę pola w odpowiedzi, wymagają tokenu OAuth, wyłączają starą wersję endpointu. Bez opieki sklep działa do pierwszej takiej zmiany, a potem zamówienia przestają spływać do ERP i nikt nie wie dlaczego.
W zakres opieki powinno wchodzić: aktualizacje silnika sklepu i modułów integracyjnych (najpierw na kopii, potem na produkcji), poprawki po zmianach API, backupy bazy i plików, monitoring kolejki zamówień oraz logów płatności, a także reakcja, gdy rano nie generuje się etykieta kurierska przy wysyłce. Zapytaj wprost, kto realnie odpowiada na zgłoszenie: właściciel agencji, account manager czy deweloper, który zna kod integracji. Najkrótsza droga to kontakt z osobą utrzymującą moduł – każdy pośrednik dokłada zwykle 1–2 godziny opóźnienia i dodatkową marżę.
SLA nie może brzmieć „reagujemy szybko”. Ustal dwa poziomy i wpisz je do umowy.
| Typ zgłoszenia | Przykład | Reakcja w SLA | Co dopisać w umowie |
|---|---|---|---|
| Krytyczny | Bramka odrzuca wszystkie płatności, kurier nie generuje etykiet, zamówienia nie trafiają do ERP | do 2 h w godzinach pracy | telefon lub czat awaryjny, informacja zwrotna co 60 min, praca także poza kolejką zleceń |
| Ważny | część zamówień nie zapisuje się w ERP, błędne mapowanie pola, zdublowane stany | do 8 h, czyli następny dzień roboczy | zgłoszenie w systemie ticketowym, jeden właściciel tematu |
| Zwykły | literówka w szablonie etykiety, drobna zmiana komunikatu na stronie płatności | 2–3 dni robocze | zgłoszenia łączone w paczki, okno wdrożeniowe poza godzinami szczytu |
Skopiuj tę listę do notatnika i odhaczaj po kolei. Każdy nieodhaczony punkt to ryzyko rozjazdu stanów magazynowych albo zamówienia oznaczonego jako opłacone, choć wpłaty nie ma.
Typowa pełna integracja ERP, płatności i kuriera w małym sklepie to 40–80 godzin pracy, a opieka po wdrożeniu 2–6 godzin miesięcznie. Orientacyjne stawki znajdziesz w cenniku integracji w Zamościu. Przy WooCommerce warto wcześniej przejrzeć oficjalną dokumentację WooCommerce.
W małej firmie sukces wdrożenia zależy od trzech rzeczy: dokładnego mapowania pól, jednego źródła prawdy dla magazynu i jasnego SLA na utrzymanie. Technologia jest tu najmniej ryzykownym elementem.
Start od wyboru narzędzia („który moduł do Subiekta?”) zamiast od opisu własnego procesu. Efekt: wdrożenie dopasowuje sklep do wtyczki, a nie wtyczkę do pracy firmy.
Jak wykryć: Jeśli na pytanie „kto dziś przepisuje zamówienia i ile to zajmuje minut dziennie?” nie ma jednej konkretnej odpowiedzi, nie znasz jeszcze procesu.
Jak naprawić: Spisz na kartce cztery obszary: stany magazynowe, zamówienia, wysyłki, płatności. Dopiero potem szukaj narzędzi, które obsłużą ten opisany przepływ.
Brak mapowania pól przed wdrożeniem. SKU, EAN, cena netto i brutto, jednostka miary, stawka VAT i kategoria trafiają do integracji „jak leci”, więc systemy nie dogadują się co do tego samego produktu.
Jak wykryć: Po pierwszej synchronizacji produkt występuje dwa razy, ma inny SKU albo inną cenę niż w ERP.
Jak naprawić: Zrób tabelę mapowania: pole w ERP, pole w sklepie, typ danych, kto je aktualizuje. Ustal, czy cena w sklepie jest brutto, czy netto i czy ERP ma być źródłem prawdy.
Integracja dwukierunkowa tam, gdzie wystarczy jednokierunkowa. Dwa systemy nadpisują ten sam status i powstaje wyścig, kto był ostatni.
Jak wykryć: Status zamówienia zmienia się sam z siebie, a w logach widać naprzemienne zapisy z obu stron.
Jak naprawić: Zdecyduj, co jest przepływem jednokierunkowym (np. ERP → sklep dla stanów i cen), a co faktycznie wymaga ruchu w obie strony (np. zamówienie → ERP, status realizacji → sklep).
Brak weryfikacji podpisu webhooka od operatora płatności. Skutek: zamówienia oznaczone jako opłacone, mimo że wpłata nie wpłynęła.
Jak wykryć: Porównaj listę zamówień „opłaconych” z raportem wpłat u operatora — rozjazd widać od razu, zwłaszcza przy testach wysyłanych z zewnątrz.
Jak naprawić: Włącz weryfikację podpisu (sygmatury) każdego powiadomienia, odrzucaj niepodpisane wywołania i loguj je osobno do analizy.
Etykiety kurierskie generują się poprawnie, ale zamówienie nie dostaje statusu „wysłane” ani numeru śledzenia w mailu do klienta.
Jak wykryć: Sprawdź losowe zamówienie z ostatniego tygodnia: czy w sklepie i w ERP jest ten sam status oraz ten sam numer tracking.
Jak naprawić: Domknij pętlę zwrotną: po nadaniu przesyłki numer tracking i status muszą wrócić do sklepu i do ERP. Ustal, który system zapisuje status jako pierwszy.
Brak budżetu na utrzymanie. Integracja działa w dniu odbioru, a po zmianie API operatora płatności albo kuriera przestaje działać.
Jak wykryć: Zapytaj dostawcę ERP i operatora, jak informują o zmianach w API — jeśli nie wiesz, gdzie szukać tych komunikatów, nie masz planu utrzymania.
Jak naprawić: Zaplanuj coroczny budżet na aktualizacje i monitoring. Ustal, kto reaguje na alert o błędzie synchronizacji i w jakim czasie.
Kolejność jest zawsze ta sama: najpierw opis procesu i policzenie ręcznej pracy, potem mapowanie pól, dopiero na końcu wybór narzędzi. Integracja sklepu z ERP, bramką płatniczą i kurierem to przede wszystkim ustalenie, które dane płyną, w którą stronę i który system jest dla nich źródłem prawdy. Bez tego kroku zapłacisz za wdrożenie, a rozjazd stanów i statusów wróci po pierwszym tygodniu. Przy małej skali zamówień — poniżej około 5 dziennie — arkusz bywa rozwiązaniem wystarczającym.
Od opisu własnego procesu, nie od wyboru narzędzia. Spisz na kartce stany magazynowe, zamówienia, wysyłki i płatności, a potem policz, ile czasu zajmuje dziś ręczne przepisywanie danych. Dopiero mając ten opis, sensownie ocenisz, czy potrzebujesz integracji jednokierunkowej, czy dwukierunkowej.
Przy małej skali — jeśli firma ma mniej niż około 5 zamówień dziennie — arkusz i ręczne przepisywanie danych bywają tańsze niż wdrożenie i utrzymanie integracji. Policz godziny pracy miesięcznie i porównaj z kosztem projektu oraz późniejszych aktualizacji.
Tak, ale inaczej. Typowe obejścia to eksport i import plików XML lub CSV, kolejka plików w ustalonym katalogu i harmonogram uruchamiany przez cron. To rozwiązanie działa, lecz jest mniej odporne na błędy i wymaga jasnych zasad nadawania i odbierania plików.
Bo ERP liczy stany po zmianach wprowadzonych w biurze, a sklep odejmuje także rezerwacje z koszyków, które nigdy nie zamieniły się w zamówienie. Do tego dochodzą zwroty i korekty. Rozwiązaniem jest ustalenie, który system jest w tym zakresie źródłem prawdy, i uwzględnienie rezerwacji w samej synchronizacji.
To zwykle dwa osobne wdrożenia, które spotykają się w jednym miejscu: statusie zamówienia. Bramka płatnicza pilnuje, czy wpłata wpłynęła, a kurier dostarcza numer śledzenia i informację o doręczeniu. Ważne, żeby status zamówienia był aktualizowany w jednym systemie, a nie w dwóch równolegle.
W integracjach zwykle tak, bo zakres zmienia się w trakcie: jedno nietypowe pole w ERP albo brak dostępu do testowego API przekłada się na dodatkowe godziny. Przy rozliczeniu godzinowym widać te zmiany na bieżąco. Orientacyjnie: prosta bramka płatnicza to 4–10 h, kurier 6–16 h, a integracja z ERP 20–60 h, w zależności od tego, czy ERP ma API.
Jeśli chcesz przejść tę ścieżkę bez zgadywania, opisz nam swój proces i obecny zestaw narzędzi — powiemy, co da się połączyć, a co lepiej zostawić w spokoju. Więcej o naszym zakresie prac znajdziesz na stronie integracji z ERP, płatnościami i kurierami dla Krasnobrodu.