Trzydzieści zamówień dziennie i cztery minuty ręcznej obsługi każdego z nich to około dwóch godzin pracy dziennie, czyli blisko 40 godzin w miesiącu. Tyle czasu ktoś w firmie spędza na przepisywaniu danych między sklepem, programem księgowym i panelem kuriera. Ten artykuł to część organizacyjna: kolejność wdrożenia, typowe błędy i lista kontrolna, którą przejdziesz przed podpisaniem zlecenia na integrację. Nie znajdziesz tu obietnic, że „wszystko zrobi się samo” — integracja to projekt z zakresem, kolejnością i punktami, w których trzeba podjąć decyzję.
Policz to na własnych danych, zanim zamówisz wdrożenie. 30 zamówień dziennie × 4 minuty obsługi jednego zamówienia (przepisanie do ERP, sprawdzenie stanu, wygenerowanie etykiety, potwierdzenie dla klienta) daje 120 minut, czyli 2 godziny dziennie. Przy 20 dniach roboczych w miesiącu to około 40 godzin miesięcznie. Jeżeli osoba obsługująca zamówienia kosztuje firmę 35–45 zł za godzinę brutto z narzutami, mówimy o 1400–1800 zł miesięcznie i 17–22 tys. zł rocznie. Tyle pracy wraca, gdy dane przestają być przepisywane ręcznie.
Trzy objawy, że firma jest już za progiem opłacalności integracji:
Do tego dochodzi rozróżnienie, które trzeba ustalić przed wyceną: integracja jednokierunkowa (zamówienie ze sklepu trafia do ERP, nic nie wraca) i dwukierunkowa (stany magazynowe oraz ceny wracają z ERP do sklepu). Pierwsza jest tańsza i szybsza, ale nie rozwiązuje problemu zdublowanych stanów. Druga wymaga zgodnych SKU po obu stronach i reguły, które stany są nadrzędne. Podobne wyliczenia i warianty wdrożenia opisujemy przy okazji projektu integracji sklepu z ERP w Lublinie.
| Objaw | Co się dzieje w firmie | Koszt, który widać |
|---|---|---|
| Zdublowane stany | Sprzedaż towaru, którego nie ma na magazynie | Anulacje, zwroty, obsługa reklamacji |
| Faktury z opóźnieniem | Lista zamówień zbierana ręcznie raz w tygodniu | Przesunięte terminy płatności, praca po godzinach |
| Pytania o paczkę | Ręczne sprawdzanie statusu w panelu kuriera | 2–3 minuty na każde zgłoszenie klienta |
Kolejność nie jest kwestią upodobań — wynika z zależności danych między systemami. Najczęstsza przyczyna przeprojektowania wdrożenia to podłączenie modułów w innej kolejności niż ta, w której przepływają dane. Rekomendowana sekwencja jest następująca:
Dlaczego kuriera podłączasz dopiero po płatnościach: w wielu wdrożeniach etykieta generuje się wyłącznie dla zamówienia ze statusem „opłacone”. Przy przedpłacie to potwierdzenie z bramki, przy pobraniu — reguła ustawiona w sklepie. Jeśli kurier zostanie podłączony pierwszy, każda etykieta będzie wymagała ręcznej weryfikacji, a to dokładnie ta praca, którą chcesz wyeliminować.
Równolegle możesz prowadzić: konfigurację bramek płatności, mapowanie metod dostawy i cenników kurierskich, treści maili i zmianę statusów zamówienia. Nie wolno równolegle robić stanów przed bazą produktową ani faktur przed dokumentami WZ.
Ten sam schemat stosujemy w mniejszych firmach — przykład kolejności integracji sklepu z ERP w Hrubieszowie pokazuje, że przy niższej liczbie zamówień punkty decyzyjne są identyczne.
Nakład pracy zależy głównie od jednej rzeczy: czy ERP udostępnia API, czy trzeba się do niego dostać inaczej. Systemy z API (Comarch Optima, enova365, iFirma) integruje się przez wywołania usług — szybciej, stabilniej i bez zależności od konkretnej maszyny. Systemy wymagające mostka (Subiekt GT przez Sferę, WF-Mag przez bazę Firebird) wymagają dodatkowej usługi działającej blisko programu.
Co dokładnie synchronizujesz w typowym wdrożeniu: stany magazynowe, ceny i kartoteki produktów, zamówienia ze sklepu jako zamówienia w ERP, dokumenty WZ i faktury sprzedaży. Każdy z tych obszarów ma własne reguły — np. który cennik obowiązuje, jak oznaczyć zamówienie już przepisane i jak uniknąć duplikatów przy ponownej synchronizacji.
Pułapka Subiekta GT: nie ma oficjalnego API. Integracja przez Sferę dla programistów to biblioteka COM działająca na maszynie z zainstalowanym Subiektem, pod Windows. Usługa musi działać lokalnie, a dostęp zdalny wymaga VPN lub tunelu. Aktualizacje Subiekta mogą zmieniać zachowanie bibliotek — trzeba mieć plan na ponowne testy. Wersja nexo ma osobne mechanizmy integracyjne i wycenia się ją inaczej.
Typowy nakład: prosty mostek jednokierunkowy 16–30 godzin. Integracja dwukierunkowa z wieloma cennikami i wieloma kanałami sprzedaży: 40–80 godzin. Do tego dochodzi warstwa sklepu — w PrestaShopie trzeba dopiąć się do Web Service API PrestaShop, który opisuje dostępne zasoby i operacje.
Przykład zbliżonego zakresu przy Subiekcie: integracja ERP ze sklepem w Biłgoraju.
| System | Sposób komunikacji | Uwagi wdrożeniowe |
|---|---|---|
| Comarch Optima | API / usługa sieciowa | Stabilne, wymaga poprawnej konfiguracji dostępu |
| enova365 | API | Dobre do integracji dwukierunkowej |
| iFirma | API REST | Prosta dokumentacja, ograniczenia w dokumentach magazynowych |
| WF-Mag | Mostek do bazy Firebird | Zapytania SQL, ostrożnie z transakcjami i blokadami |
| Subiekt GT | Brak oficjalnego API — Sfera dla programistów | Usługa na maszynie z Subiektem, Windows, dostęp przez VPN |
Wybór bramki to nie kwestia wyglądu przycisku, tylko policzenia trzech rzeczy: ile zapłacisz od transakcji, kiedy dostaniesz pieniądze i co się stanie, gdy klient zechce zwrot.
Prowizja. Stawki startowe mieszczą się zwykle między 0,9% a 2,5% od transakcji, a przy BLIK-u i ratach bywają inne niż przy karcie. Policz to na własnych liczbach: 30 zamówień dziennie po 150 zł to około 135 tys. zł obrotu miesięcznie, więc różnica 0,5 punktu procentowego to blisko 700 zł miesięcznie.
Metody. BLIK musi być — to metoda, którą klient wybiera, żeby nie wpisywać danych karty. Raty i płatności odroczone (Płacę później, Klarna i podobne) mają sens głównie przy koszykach powyżej 500 zł: prowizja jest wyższa, dochodzi weryfikacja klienta, ale część osób bez rat nie kupi.
Czas wypłaty i zwroty. Sprawdź, czy wypłata jest codzienna (T+1), czy zbiorcza raz w tygodniu (T+7). Przy obrocie 135 tys. zł miesięcznie T+7 oznacza, że kilkadziesiąt tysięcy złotych krąży poza firmą. Zapytaj też, czy zwrot pojedynczej transakcji zrobisz z panelu, czy przelewem ręcznym, i czy przy chargebacku dostaniesz maila oraz możliwość wgrania dowodów — potwierdzenia dostawy i numeru śledzenia.
Webhook to serce integracji. Po opłaceniu bramka wysyła żądanie POST na adres w Twoim sklepie i dopiero ono zmienia status zamówienia na „opłacone”. Gdy nie dojdzie — bo serwer zwrócił 500, trwał deploy albo wygasł certyfikat — zamówienie zostaje jako „oczekujące na płatność”, a klient dzwoni. Zabezpieczenie to rekoncyliacja: zadanie cron co 10 minut pobiera z API bramki transakcje z ostatnich 48 godzin i porównuje je ze statusami w sklepie. Do tego przycisk „sprawdź status płatności” w panelu obsługi.
Idempotencja. Ten sam webhook może przyjść dwa albo trzy razy — tak działa ponawianie po timeoucie. Jeśli obsługa zaczyna się od „utwórz zamówienie”, dostaniesz duplikat, dwa maile i dwie paczki. Rozwiązanie: zapisz identyfikator transakcji z bramki w kolumnie z indeksem UNIQUE i przed przetworzeniem sprawdź, czy już istnieje. Zawsze odpowiadaj 200 OK, także dla zdarzenia już przetworzonego — inaczej bramka będzie ponawiać w nieskończoność. Podobny układ decyzji opisaliśmy dla firm z Lublina w materiale o integracjach z ERP, płatnościami i kurierami w Lublinie.
| Kryterium | Co konkretnie sprawdzić | Dlaczego to boli |
|---|---|---|
| Prowizja | Osobno dla karty, BLIK-a, rat i płatności odroczonych | Różnica 0,5 p.p. to przy 135 tys. zł obrotu ok. 675 zł miesięcznie |
| Czas wypłaty | T+1 czy T+7, czy wypłata jest automatyczna | Zamrożona gotówka przy napiętym cashflow |
| Zwroty | Zwrot z panelu czy przelewem ręcznym, kto to księguje | Ręczne zwroty to godziny pracy księgowości |
| Chargeback | Powiadomienie mailowe, możliwość wgrania dowodów | Bez trackingu i potwierdzenia dostawy spór trudno wygrać |
| Webhooki | Podpis, lista zdarzeń, ponawianie, środowisko testowe | Bez sandboxa testujesz na prawdziwych pieniądzach |
Proces od „zamówione i opłacone” do „dostarczone” to kilka osobnych kroków i każdy z nich to inne wywołanie API.
Webhooki statusów. Kurier wysyła zdarzenia: nadana, w drodze, do odbioru, dostarczona, awizo, zwrot do nadawcy. Handler mapuje je na statusy w sklepie i wysyła maila do klienta. Zasada jak przy płatnościach: zero duplikatów i żadnego nadpisywania statusu „zwrot” spóźnionym zdarzeniem „dostarczona”.
Dwie pułapki. Pierwsza to limity rozmiaru — każdy kurier ma maksymalne wymiary i wagę, a API odrzuci nadanie dopiero przy generowaniu etykiety. Dodaj walidację w koszyku, zanim klient zapłaci. Druga to strefy czasowe: nadania po 23:00 potrafią zostać zapisane z datą następnego dnia, a przy zmianie czasu okna odbioru przesuwają się o godzinę. Test jest prosty — wygeneruj etykietę o 23:30 i sprawdź, jaką datę nadania zwrócił kurier.
| Krok | Co się dzieje | Co wymaga kodu |
|---|---|---|
| Zamówienie opłacone | Webhook z bramki zmienia status | Obsługa webhooka i idempotencja |
| Etykieta | API nadania zwraca PDF i numer przesyłki | Mapowanie pól, walidacja wymiarów i wagi |
| Punkt odbioru | Klient wybiera Paczkomat w koszyku | Widget mapy i zapis kodu punktu |
| Nadanie | Kurier odbiera paczkę | Ręcznie lub przez manifest — zależy od kuriera |
| Statusy | Kurier wysyła webhooki | Mapowanie statusów i mail do klienta |
| Dostarczona | Zamówienie się zamyka | Aktualizacja w sklepie i w ERP |
Poniższy plan przejdziesz sam albo zlecisz deweloperowi — ważne, żeby zakres każdego etapu był zapisany w umowie, a nie domyślny.
| Etap | Dowód, że etap jest skończony |
|---|---|
| 1. Audyt i mapowanie pól | Arkusz zaakceptowany przez księgowość i magazyn |
| 2. Środowisko testowe | Zamówienie testowe przechodzi całą ścieżkę bez maili do klientów |
| 3. Testy scenariuszowe | Wszystkie scenariusze przechodzą, w tym zdublowany webhook |
| 4. Migracja i inwentaryzacja | Stany w sklepie i ERP zgodne co do sztuki |
| 5. Start na produkcji | Pierwsze 20 zamówień obsłużone i sprawdzone ręcznie |
| 6. Obserwacja 2–4 tygodnie | Tygodniowy raport: ile zamówień poszło automatycznie |
Nie ma jednego cennika integracji. Są widełki wynikające z liczby godzin pracy i liczby systemów, które muszą wymienić dane. Poniżej realne przedziały dla sklepu na PrestaShop lub WooCommerce — z konfiguracją, testami i krótką dokumentacją.
Same płatności to 8–16 godzin: instalacja modułu, konfiguracja metod, testy płatności nieudanych i zwrotów, obsługa statusów. Kurierzy to 12–24 godziny na jednego lub dwóch przewoźników, w tym mapy punktów odbioru i generowanie etykiet. ERP zaczyna się od 16 godzin przy eksporcie zamówień i stanów, a kończy na 80 przy pełnej wymianie dwukierunkowej.
Co podnosi wycenę:
Własny moduł bywa tańszy niż trzy płatne wtyczki. Trzy wtyczki po 300–600 zł rocznie to 900–1800 zł co roku, do tego licencje na kolejne środowisko (test i produkcja) oraz brak dostępu do kodu — gdy producent przestanie aktualizować wtyczkę, zostajesz z błędem, którego nie naprawisz. Własny moduł to jednorazowy koszt, kod zostaje u Ciebie i działa po zmianie wykonawcy. Punktem wyjścia jest dokumentacja dla deweloperów PrestaShop — warto sprawdzić, czy Twój wykonawca ją zna.
| Zakres | Widełki | Co obejmuje |
|---|---|---|
| Płatności — jeden operator | 8–16 h | konfiguracja metod, statusy, testy zwrotów i płatności nieudanych |
| Kurierzy — jeden lub dwóch | 12–24 h | mapy punktów, generowanie etykiet, statusy przesyłek |
| ERP — podstawowa wymiana | 16–40 h | eksport zamówień, import stanów i cen, numeracja dokumentów |
| ERP — rozszerzona wymiana | 40–80 h | cenniki B2B, limity kredytowe, magazyny wielokrotne, faktury dwukierunkowo |
Te pułapki wracają w większości wdrożeń. Każda ma konkretny objaw, po którym sprawdzisz, czy Twój sklep jest na nią narażony.
Objawy, miejsca sprawdzenia i poprawki warto zebrać w jedną tabelę — przydaje się przy przekazywaniu zlecenia innemu wykonawcy. Punktem odniesienia dla podobnego sklepu mogą być integracje z ERP, płatnościami i kurierami w Biłgoraju.
Integracja nie kończy się w dniu wdrożenia. Płatności zmieniają API, kurierzy dodają usługi, ERP dostaje aktualizację. Bez monitoringu pierwszym, kto dowie się o awarii, jest klient, który nie złożył zamówienia.
Co monitorować:
W umowie o opiekę powinny znaleźć się trzy rzeczy: czas reakcji na incydent krytyczny (sklep nie przyjmuje zamówień, płatności nie przechodzą), jeden kanał zgłoszeń zamiast adresu e-mail do pięciu osób oraz ścieżka eskalacji z numerem telefonu do osoby decyzyjnej. Bez tego SLA bywa deklaracją dobrej woli.
Praca bezpośrednio z deweloperem, który pisał integrację, skraca naprawę, bo nie ma przekazywania kontekstu między pośrednikiem a wykonawcą. Osoba znająca kod od razu wie, czy problem jest w mapowaniu pól, czy w limitach API. Gdy jedna nieudana synchronizacja oznacza 20 telefonów od klientów, liczy się każda godzina.
Rekomendacja: raz w miesiącu przejrzyj logi i kolejkę, raz na kwartał sprawdź daty ważności kluczy API w panelach operatora płatności i kurierów, wpisując je do kalendarza z 30-dniowym wyprzedzeniem. Podobny projekt w sąsiednim mieście opisują integracje z ERP, płatnościami i kurierami w Hrubieszowie.
| Element | Rekomendacja |
|---|---|
| Czas reakcji — incydent krytyczny | 1–2 h w godzinach pracy, do 4 h poza nimi |
| Kanał zgłoszeń | jeden kanał + telefon do osoby decyzyjnej |
| Eskalacja | imię i numer kontaktowy, nie ogólna skrzynka |
| Przegląd po wdrożeniu | raz w miesiącu logi i kolejki, raz na kwartał klucze API |
Podłączanie kuriera przed płatnościami online. W wielu wdrożeniach status „opłacone” jest warunkiem wygenerowania etykiety, więc integracja kurierska bez płatności wisi w powietrzu i trzeba ją przeprojektować.
Jak wykryć: Sprawdź, czy etykiety są generowane ręcznie po tym, jak ktoś potwierdzi wpłatę na wyciągu. Jeśli tak, kolejność została odwrócona.
Jak naprawić: Zamroź prace nad kurierem, dokończ integrację płatności razem z webhookami i reconciliation, a dopiero potem wróć do etykiet.
Traktowanie integracji jednokierunkowej (zamówienie → ERP) jako docelowej. Stany magazynowe rozjeżdżają się przy pierwszym sprzedaży poza sklepem internetowym.
Jak wykryć: Porównaj stany w sklepie i w ERP o dwóch różnych porach dnia. Jeśli różnią się bez żadnej sprzedaży w sklepie, ktoś sprzedaje poza nim albo ręcznie koryguje magazyn.
Jak naprawić: Zaplanuj synchronizację dwukierunkową stanów i ustal, który system jest źródłem prawdy dla którego pola. Zwykle ERP jest źródłem stanów, sklep tylko je prezentuje.
Brak idempotencji przy obsłudze webhooków płatniczych. Ten sam komunikat może przyjść dwa razy i wtedy powstaje zdublowane zamówienie albo podwójna faktura.
Jak wykryć: Wyślij ten sam webhook dwa razy na środowisku testowym. Jeśli powstaną dwie pozycje, brakuje klucza idempotencji.
Jak naprawić: Zapisuj identyfikator transakcji z bramki i przed utworzeniem zamówienia sprawdzaj, czy już go obsłużyłeś. Operacja musi być powtarzalna bez skutków ubocznych.
Poleganie wyłącznie na webhookach bez sprawdzania statusu po czasie. Gdy komunikat nie dotrze, zamówienie wisi jako nieopłacone, choć klient zapłacił.
Jak wykryć: Policz w skali tygodnia, ile zamówień było ręcznie odblokowywanych, bo „pieniądze przyszły, a sklep nie wie”.
Jak naprawić: Dodaj zadanie cykliczne, które po kilkunastu minutach od złożenia zamówienia dopytuje bramkę o status transakcji. To zabezpieczenie tańsze niż reklamacje.
Wdrożenie bez mapowania pól i bez środowiska testowego. Kartoteki klientów i sposoby wysyłki nie pokrywają się z tym, co ma w bazie ERP.
Jak wykryć: Zrób listę pól sklep ↔ ERP. Jeśli gdziekolwiek pojawia się „to się jakoś dopasuje”, mapowanie nie jest gotowe.
Jak naprawić: Najpierw tabela mapowania (pole, format, wymagalność, wartość domyślna), potem kod. Kopię bazy ERP testuj na osobnym środowisku, nigdy na produkcji.
Brak właściciela procesu i monitoringu po wdrożeniu. Nikt nie zauważa, że synchronizacja stanęła, dopóki klient nie złoży zamówienia na towar, którego nie ma.
Jak wykryć: Zapytaj w firmie, kto dostaje alert, gdy integracja zwróci błąd. Jeśli odpowiedź brzmi „chyba nikt”, problem jest organizacyjny, nie techniczny.
Jak naprawić: Ustal jedną osobę odpowiedzialną, włącz alerty o błędach integracji i zapisuj logi. Dodaj prostą procedurę ręcznego domknięcia zamówienia na wypadek awarii.
Kolejność ma większe znaczenie niż wybór narzędzi: baza produktowa w ERP, potem stany, płatności, kurierzy, na końcu faktury i księgowość. Kurier idzie po płatnościach, bo status „opłacone” jest warunkiem generowania etykiety w wielu wdrożeniach. Najczęstsze kosztowne błędy to brak idempotencji webhooków, brak sprawdzania statusu płatności po czasie i wdrożenie bez mapowania pól. Przejdź listę kontrolną przed startem — godzina na decyzje teraz to zwykle kilka godzin mniej poprawek później.
To zależy przede wszystkim od liczby systemów i sposobu komunikacji z ERP. Prosty mostek jednokierunkowy to zwykle 16–30 godzin pracy, a integracja dwukierunkowa z wieloma cennikami i kartotekami sięga 40–80 godzin. Do tego dochodzi czas po stronie Twojej firmy na mapowanie pól, testy i decyzje organizacyjne, którego nikt nie zrobi za Ciebie.
Nie ma oficjalnego API, takiego jak Optima czy enova365. Integracja idzie przez Sferę, a to oznacza, że na maszynie z Subiektem musi działać dodatkowa usługa, która wystawia dane na zewnątrz. To realne ograniczenie: komputer z Subiektem musi być włączony i dostępny, gdy sklep chce zsynchronizować stany.
Na start często wystarcza, ale tylko wtedy, gdy stany magazynowe aktualizujesz wyłącznie w ERP i nie sprzedajesz równolegle poza sklepem. Jeśli sprzedajesz też stacjonarnie albo na marketplace, bez zwrotnej synchronizacji stanów prędzej czy później sprzedasz coś, czego nie masz. Wtedy jednokierunkowość jest etapem przejściowym, a nie rozwiązaniem docelowym.
Sklep nie wie, że klient zapłacił, więc zamówienie zostaje w statusie oczekiwania. Klient widzi, że pieniądze zeszły z konta, i pisze do Ciebie — a Ty odblokowujesz zamówienie ręcznie. Dlatego obok webhooka warto mieć zadanie cykliczne, które dopyta bramkę o status transakcji po kilkunastu minutach.
Technicznie można, ale w wielu wdrożeniach etykieta generuje się dopiero dla zamówienia ze statusem „opłacone”. Bez tego warunku integracja kurierska będzie wymagała ręcznego zatwierdzania każdej przesyłki. Kolejność płatności → kurierzy oszczędza jedno przeprojektowanie.
Tak, bo to inny model przepływu pieniędzy: pobiera je kurier, a nie bramka płatnicza. Trzeba uzgodnić z operatorem płatności, jak wygląda rozliczenie i zwroty, a w sklepie oznaczyć COD jako osobny sposób zapłaty. Bez tego zamówienia za pobraniem potrafią wpadać do tych samych raportów co opłacone online.
Od decyzji, który cennik widzi który klient i które kanały sprzedaży. Dopiero potem projektujesz logikę w integracji — inaczej kod będzie zgadywał, co pokazać w sklepie. Przy wielu cennikach nakład pracy rośnie najbardziej, więc ta decyzja musi zapaść przed pierwszym wierszem kodu.
Jeśli chcesz przejść tę listę kontrolną z kimś, kto robił to na PrestaShop i WooCommerce, napisz do nas. Sprawdzimy Twoje systemy i powiemy, co da się zrobić w jakiej kolejności — bez zobowiązania.