Co właściwie wyceniamy – trzy bloki, z których składa się „integracja”

„Integracja” to w praktyce trzy osobne projekty. Można je wdrożyć razem albo po kolei – każdy ma inny czas realizacji i inne ryzyko.

1. ERP ↔ sklep. Dwukierunkowa wymiana danych: sklep wysyła zamówienie, ERP zwraca stany magazynowe, ceny, numer faktury i status realizacji. Dotyczy to Subiekta GT i Nexo, Comarch Optima, WAPRO, ERPNext oraz systemów pisanych na zamówienie. To najdroższy blok, bo najpierw trzeba ustalić, kto jest źródłem prawdy dla ceny i stanu magazynowego.

2. Płatności online i ich statusy. Podłączenie bramki (Przelewy24, PayU, tpay, Stripe) to kilka godzin. Prawdziwa praca zaczyna się przy statusach: nowe, oczekujące, opłacone, anulowane, zwrócone. Webhook z bramki musi przestawić status zamówienia w sklepie, a przy zwrocie – wycofać towar na magazyn.

3. Kurierzy i etykiety. InPost, DPD, DHL, GLS, Poczta Polska: generowanie etykiety z panelu sklepu, nadawanie numeru przesyłki, punkty odbioru, zgłoszenia zwrotów. Ten blok domyka się zwykle w 1–2 dni.

Dla porównania pełne spięcie sklepu z Subiektem GT to często 3 tygodnie pracy: mapowanie pól, zamówienia zbiorcze, faktury, korekty, testy na kopii bazy. Dlatego wycena sprowadza się do prostego wzoru: liczba godzin × stawka godzinowa. Nie istnieje cennik „integracja – 2 000 zł”, bo zakresy różnią się dziesięciokrotnie. Szerszy opis zakresu znajdziesz w sekcji integracje z ERP, płatnościami i kurierami w Zamościu.

Cennik: realne widełki dla Zamościa i regionu lubelskiego

Poniższe przedziały to typowe wartości dla sklepów na PrestaShop i WooCommerce, obsługiwanych z Zamościa i okolic. Kwoty liczone są jako godziny × stawka, więc traktuj je jako punkt odniesienia do rozmowy, nie jako ofertę.

Przykład kalkulacji: sklep PrestaShop + Subiekt GT + InPost + Przelewy24. Kurier 6–16 h, bramka 4–10 h, ERP w podstawowym zakresie (zamówienia, stany, ceny, faktura) 20–40 h. Razem 30–66 h, czyli przy stawce 100–150 zł/h około 3 000–9 900 zł. Rozszerzenie ERP o korekty, zwroty i drop shipping podnosi ten zakres do 12 000 zł i więcej.

Kto pracuje, ten decyduje o stawce. Deweloper pracujący bezpośrednio zwykle mieści się w 90–140 zł/h. Agencja z podwykonawcą dolicza koordynację, testy i wsparcie po wdrożeniu, co daje 130–200 zł/h. Ta różnica nie jest przypadkowa – przy drugim wariancie masz jedną osobę kontaktową i umowę na utrzymanie.

Gotowy moduł czy moduł od zera. Gotowy moduł do PrestaShop czy WooCommerce kosztuje zwykle 200–1 500 zł plus 4–10 h konfiguracji – bywa tańszy na starcie. Ale sprawdź datę ostatniej aktualizacji i historię zmian API. Moduł porzucony po zmianie endpointów u kuriera generuje koszt utrzymania wyższy niż napisanie integracji od zera. Strukturę modułów i hooki opisuje PrestaShop Developer Documentation. Warianty kosztowe rozpisaliśmy też w materiale o koszcie integracji z ERP, płatnościami i kurierami w Zamościu.

Od czego zależy cena – 8 czynników, które przesuwają wycenę o tysiące

Zanim poprosisz o wycenę, odpowiedz na osiem pytań. Każde „tak, więcej” przesuwa kwotę o tysiące złotych.

1. Liczba kanałów. Trzy konta kurierskie zamiast jednego to dodatkowe 3–6 h. Dwie bramki płatności, dwa sklepy, magazyn w Zamościu i drugi w Lublinie – każde konto i każda lokalizacja wymaga osobnej konfiguracji i osobnych testów.
2. Sposób komunikacji z ERP. REST/JSON jest najtańszy. XML/SOAP to więcej kodu i zwykle warstwa pośrednia. Bezpośredni dostęp do bazy ERP jest najszybszy do napisania i najdroższy w utrzymaniu: omija walidację, blokuje tabele przy większym ruchu, a aktualizacja ERP potrafi zniszczyć integrację z dnia na dzień.
3. Mapowanie danych. Pola zamówienia, statusy, jednostki miary, stawki VAT, stany, ceny promocyjne. Statusy w WooCommerce (pending, processing, completed, refunded) nie mapują się 1:1 na statusy dokumentów ERP – WooCommerce Documentation opisuje je dokładnie, ale reguły przejść ustalasz sam.
4. Skąd bierze się cena. Sklep czy ERP? Jeśli w sklepie działa rabat, a ERP zna tylko cenę katalogową, trzeba wskazać regułę nadrzędności. Inaczej po pierwszej promocji stany i ceny się rozjeżdżają.
5. Liczba operacji dziennie. 20 zamówień obsłuży cron co 15 minut. 500 zamówień dziennie wymaga kolejek, ponowień i obsługi limitów API kuriera – to dodatkowe 10–20 h.
6. Dostępy i środowisko testowe. Brak sandboxa po stronie ERP lub kuriera oznacza testy na produkcji i godziny stracone na wyjaśnianie skutków.
7. Faktury automatyczne, korekty, zwroty. To osobna logika, często 8–16 h więcej niż samo przepisanie zamówienia.
8. Drop shipping. Zamówienia u dostawców, potwierdzenia, rozbicie przesyłki na kilka paczek – jeśli ERP tego nie ma, dopisujesz to od zera.

Kurierzy: InPost, DPD i DHL – co wpływa na czas i koszt wdrożenia

Blok kurierski jest najczęściej pierwszą integracją, jaką robimy w sklepach z Zamościa i okolic – i zwykle najtańszą. Punkt startu to InPost ShipX: generowanie etykiet przez API, lista Paczkomatów i punktów odbioru, zwroty oraz pobranie (COD). Standardowy zakres to 8–16 godzin pracy. Różnica między 8 a 16 h to prawie nigdy samo API – to liczba miejsc, w których trzeba obsłużyć wybór punktu i zwroty. To część szerszego tematu, jakim są integracje sklepu z ERP, płatnościami i kurierami w Zamościu.

DPD WebAPI i DHL24 robią to samo, ale inaczej. Różnią się modelem autoryzacji, sposobem nadawania numerów przesyłek i nazewnictwem statusów. To nazewnictwo jest źródłem połowy problemów: statusy typu „w doręczeniu”, „awizo”, „zwrot do nadawcy” trzeba zmapować na statusy sklepu, inaczej klient dostaje maila „wysłane” i ciszę. Przy PrestaShop moduł kurierski podpina się hookami, których listę znajdziesz w dokumentacji dla deweloperów PrestaShop – warto zapytać wykonawcę, na których hookach opiera swoje rozwiązanie.

• Pozycje ponadstandardowe: interaktywna mapka punktów na stronie sklepu, wybór punktu w checkoutcie (zapis do zamówienia i do etykiety), własna numeracja przesyłek, obsługa COD i potwierdzania wpłat.
• Pułapka: brak aktualizacji statusów i ręczne poprawianie ich w panelu. Wykryjesz to przed podpisaniem umowy, prosząc o dwie rzeczy: tabelę mapowania statusów operatora na statusy sklepu oraz informację, czy statusy są pobierane webhookiem, czy cronem i co ile minut.

Kiedy moduł własny wygrywa z płatną wtyczką na subskrypcję? Policz koszt na 3 lata: roczna opłata × 3 plus godziny na obejścia (ręczne statusy, brak mapki punktów, brak COD). Jeśli wtyczka nie obsługuje mapki i pobrania, a licencję opłacasz co roku, moduł pisany pod sklep zwraca się zwykle w 2–3 latach – i nie przestaje działać po nieopłaceniu odnowienia.

Płatności: PayU, Przelewy24, tpay, BLIK, raty – gdzie wycena rośnie

Integracja bramki to nie „przycisk Zapłać”. Samo podłączenie PayU, Przelewy24, tpay czy BLIK-a to kilka godzin: klucze, środowisko testowe, poprawny powrót z bramki na stronę podziękowania. Reszta budżetu idzie na rzeczy, których nie widać na zrzucie ekranu. Całość wyceniamy razem z pozostałymi blokami – punkt odniesienia masz w artykule o koszcie integracji z ERP, płatnościami i kurierami w Zamościu.

• Webhooki i idempotencja. Bramka potrafi wysłać powiadomienie o płatności dwa razy (retry po timeoucie). Bez klucza idempotencji i sprawdzenia „czy zamówienie o tym ID transakcji już istnieje” dostajesz duplikat zamówienia i podwójną wysyłkę. To osobna pozycja w wycenie: zwykle 3–6 h plus testy.
• Zwroty, autoryzacje, korekty i płatności częściowe (np. zadatek). Zwrot pełny to standard, zwrot częściowy, autoryzacja z późniejszym obciążeniem i zadatek – już nie. Każdy scenariusz to osobna ścieżka w panelu i osobne księgowanie.
• PSD2/3DS i nieudane płatności. Wyzwanie 3DS po stronie banku może wrócić jako porażka. Sklep musi to obsłużyć sam: status „oczekuje na płatność”, przypomnienie z linkiem i automatyczne anulowanie np. po 48 h z przywróceniem stanu magazynowego.
• Księgowanie płatności w ERP. Do rozrachunku faktury potrzebny jest numer transakcji, data operacji i kwota. Jeśli ERP dostaje tylko kwotę, księgowość rozlicza to ręcznie.

Kiedy gotowa bramka, a kiedy operator płatności wbudowany w ERP? Gotowa bramka – gdy sprzedajesz w kilku kanałach i chcesz jedno miejsce do zwrotów. Operator w ERP – gdy sprzedaż jest głównie B2B z odroczonym terminem i fakturą, a sklep online to dodatek.

ERP: Subiekt GT/nexo, Comarch Optima, WF-Mag, Fakturownia – realia synchronizacji

ERP to zwykle 60–80% budżetu całego wdrożenia i najwięcej ryzyka. Pierwsze pytanie do wykonawcy brzmi: czy Twój ERP ma API, czy trzeba się do niego doklejać? To pytanie zadajemy też klientom z Lublina i całego regionu – opis integracji ERP, płatności i kurierów w Lublinie pokazuje ten sam schemat.

Podział jest prosty. Comarch Optima i ERPNext mają API i realnie da się z nimi pracować zdalnie. Subiekt GT to inna historia: dostęp przez Sferę (biblioteka .NET) i zależność od wersji oraz od tego, czy masz do niej uprawnienia. Fakturownia i WF-Mag mają własne API, ale zakres pokrycia (dokumenty, magazyn, stany) trzeba potwierdzić przed wyceną, bo bywa różny w zależności od planu i wersji.

Synchronizacja dwukierunkowa: zamówienia → ERP, stany i ceny ← ERP. Ustal częstotliwość i sposób: cron co 5 minut z deltą po dacie modyfikacji czy pełny zrzut co godzinę. Przy katalogu kilku tysięcy produktów pełny zrzut potrafi obciążać bazę sklepu – potrzebna jest delta i indeks na polu modyfikacji.

• Pułapka numeracji: dwa kanały sprzedaży generują numery faktur z dwóch miejsc i dochodzi do konfliktu numerów. Ustal zasadę: numer dokumentu nadaje ERP, sklep tylko odkłada zamówienie.
• Pułapka stanów: przy sprzedaży równoległej w sklepie stacjonarnym stan schodzi do zera między dwiema synchronizacjami. Lekarstwem jest rezerwacja w ERP albo bufor stanu w sklepie.
• Test przed odbiorem: puść 200 zamówień, w tym zwroty, anulacje i płatność przy odbiorze, i porównaj z ERP stany, dokumenty i numerację. Przy 200 rekordach wychodzą duplikaty i problemy wydajności, których nie widać na pięciu testowych zamówieniach.

Jak wygląda wdrożenie krok po kroku i ile trwa

Wdrożenie integracji to nie „wgranie modułu”. To sześć etapów, z których każdy kończy się konkretnym plikiem, decyzją albo raportem. Poniżej typowy przebieg dla sklepu z 20–200 zamówieniami dziennie.

1. Audyt i wycena – 1–2 dni robocze. Zbieramy wersje: PrestaShop 8.1.x, WooCommerce 9.x na PHP 8.2, wersję ERP, listę danych, które muszą płynąć w obie strony (stany, ceny, zamówienia, faktury, listy przewozowe). Efekt: dokument zakresu z liczbą godzin i stawką.
2. Dostępy i sandbox – 1–3 dni. Klucze API bramki płatności, dane testowe kuriera, kopia sklepu, środowisko testowe ERP. Jeśli ERP nie ma sandboxa, pracujemy na kopii jego bazy – nigdy na bazie produkcyjnej.
3. Moduł integracji – od kilkunastu do kilkudziesięciu godzin. Proste spięcie (stany + zamówienia + etykiety) to zwykle 15–25 h. Pełne ERP z fakturowaniem, kilkoma magazynami i zwrotami: 60–100 h i więcej.
4. Testy na kopii sklepu – 2–4 dni. Zasada jest twarda: żadnych testów bezpośrednio na produkcji. Kopia sklepu i kopii bazy danych sprawiają, że błąd w mapowaniu statusu kosztuje zero złotych, a nie kilkaset zgubionych zamówień.
5. Wdrożenie na produkcji – 1 dzień. Okno poza szczytem sprzedaży, backup bazy i plików, plan wycofania (rollback) na wypadek nieoczekiwanego zachowania starej wersji szablonu.
6. 14 dni opieki powdrożeniowej. Śledzenie pierwszych zamówień, korekty mapowań statusów, obsługa przypadków brzegowych: zamówienie bez numeru domu, przesyłka gabarytowa, płatność potwierdzona po anulowaniu.

Kryteria odbioru ustalamy przed startem, nie po: liczba przetestowanych scenariuszy (typowo 10–15 – przedpłata, pobranie, zwrot, anulowanie, brak towaru, dwa magazyny), lista statusów zamówienia zmapowanych 1:1 między sklepem a ERP oraz raport z testów z datą i wynikiem każdego przypadku.

Co blokuje projekt najczęściej: brak dostępu do ERP (hasło do API „ktoś wyśle później” potrafi zatrzymać pracę na tydzień), brak sandboxa po stronie kuriera i brak decyzji o zakresie – na przykład czy faktury wystawiać w ERP, czy tylko synchronizować. Trzy tygodnie opóźnienia to prawie nigdy problem techniczny, a organizacyjny.

Koszty po wdrożeniu: opieka techniczna i SLA

Integracja po uruchomieniu nie jest samodzielna. Kurier zmienia wersję API, bramka płatności przebudowuje mechanizm autoryzacji, ERP dostaje aktualizację, która zmienia strukturę tabeli albo sposób liczenia stanów. Projekt bez opieki technicznej wraca jako awaria w środku sezonu – najczęściej w poniedziałek rano, gdy nikt nie może wygenerować etykiet.

Stały abonament rozliczamy w godzinach miesięcznych. Trzy typowe pakiety to 2 h, 5 h i 10 h. Kwota to godziny pomnożone przez stawkę przyjętą w umowie – orientacyjnie przy stawce 150–200 zł/h to odpowiednio kilkaset złotych, ok. 750–1000 zł i 1500–2000 zł netto miesięcznie. W pakiecie 2 h mieszczą się monitoring, aktualizacje zależności, sprawdzenie logów i drobne zmiany konfiguracji; pakiet 10 h pozwala dodatkowo przeprojektować mapowanie statusów czy dodać regułę nadzoru nad płatnościami.

Dlaczego API się zmienia: kurierzy i ERP deprecjonują stare wersje endpointów, przechodzą z tokena w adresie na OAuth2, zmieniają formaty etykiet (PDF 100×150, ZPL, EPL) i dodają nowe statusy przesyłek. Changelogi publikuje producent platformy – przykładowo dokumentacja WooCommerce opisuje zmiany w kolejnych wydaniach i ostrzega o wycofywanych funkcjach. Praktyczna zasada: raz w miesiącu przejrzyj komunikaty techniczne od kuriera i ERP oraz przetestuj generowanie etykiety i potwierdzenie płatności.

Zakres SLA warto zapisać liczbami, nie hasłami. Typowy podział: awaria krytyczna (nie działają etykiety albo płatności nie potwierdzają zamówień) – reakcja 2–4 h robocze, naprawa do 8 h roboczych; problem istotny (błędne stany na części produktów) – reakcja 1 dzień roboczy; zgłoszenie drobne – 2 dni. Utrzymanie a rozwój: nowy kurier, nowa bramka, dodatkowy magazyn czy eksport danych do BI to nowa funkcja i osobna wycena – chyba że w pakiecie został niewykorzystany zapas godzin.

Jak dostać wiążącą wycenę w 48 godzin

Wycena „na oko” to najczęstsza przyczyna rozczarowania po fakturze. Żeby oferta była wiążąca, a nie orientacyjna, potrzebujemy ośmiu informacji. Bez nich pierwszy e-mail zamienia się w wymianę pięciu pytań, a wycena rozciąga się na 5 dni roboczych.

1. Platforma sklepu i wersja – np. PrestaShop 8.1.5 albo WooCommerce 9.x z informacją o wersji PHP i o tym, czy szablon był modyfikowany.
2. ERP i wersja – nazwa i wersja oraz sposób dostępu: API REST, web service, bezpośrednie zapytania SQL, pliki wymiany. To jeden z największych czynników ceny.
3. Bramki płatności – które działają dziś i czy zostają, plus tryb: przekierowanie, widget BLIK, płatność odroczona.
4. Kurierzy – lista i zakres: same etykiety czy także śledzenie przesyłek, statusy zwrotne, zamawianie podjazdu kuriera.
5. Liczba zamówień dziennie – nie miesięcznie. Podaj też piki (Black Friday, święta), bo od tego zależy kolejkowanie zadań.
6. Liczba magazynów – i czy stany mają być rozbite per lokalizacja, czy sumowane.
7. Sandbox – czy istnieje środowisko testowe po stronie ERP i kuriera, czy trzeba budować je od zera.
8. Oczekiwany termin – data startu i twarde deadline’y, np. wejście w sezon albo zmiana kuriera z końcem umowy.

Te osiem punktów skraca wycenę z 5 dni do 1–2 dni i realnie zmniejsza ryzyko dopłat: zamiast poprawiać założenia w trakcie prac, weryfikujemy je przed podpisaniem umowy.

Jeśli chcesz najpierw porównać widełki, zobacz koszt integracji z ERP, płatnościami i kurierami w Zamościu. Gdy pracujesz na większą skalę lub masz magazyn w innym mieście, punktem odniesienia będą integracje z ERP, płatnościami i kurierami w Lublinie.

Napisz do nas przez formularz kontaktowy i wklej odpowiedzi na te osiem punktów plus krótki opis, co ma się dziać automatycznie. Zapytanie „ile to kosztuje” bez zakresu zawsze kończy się widełkami – zapytanie z zakresem kończy się liczbą godzin i konkretną kwotą.

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

Lista kontrolna do odklikania

• Trzy bloki osobno — Zanim porównasz oferty, sprawdź, czy każda rozbija wycenę na ERP, płatności i kurierów. Kontekst wdrożeń opisujemy na https://dropdigital.pl/integracje-erp-platnosci-kurierzy-zamosc
• Liczba kanałów — Policz konta kurierskie, bramki płatności, sklepy, wersje językowe i magazyny, które mają być spięte w jednym systemie.
• Liczba zamówień dziennie — Ustal szczyt dobowy oraz szczyt w promocjach. 20 zamówień dziennie i 500 zamówień dziennie to inne wymagania wydajnościowe i inny czas testów.
• Interfejs ERP — Zapytaj, czy ERP udostępnia REST/JSON, XML/SOAP, pliki wymiany, czy tylko bezpośredni dostęp do bazy. To największy pojedynczy czynnik ceny.
• Środowisko testowe — Sprawdź, czy ERP i operator płatności dają sandbox, a kurier konto testowe. Brak sandboxu wydłuża wdrożenie i podnosi ryzyko błędów na produkcji.
• Zakres etykiet i punktów — Wypisz osobno: etykieta, wybór Paczkomatu lub punktu w checkoutcie, mapka punktów, zwroty, pobranie (COD), numeracja przesyłek.
• Statusy przesyłek — Ustal, czy status z kuriera ma wracać do sklepu i do ERP oraz jak często – przez webhook czy zadanie cron. Sprawdź to przed podpisaniem umowy.
• Mapowanie danych — Wypisz pola do uzgodnienia: statusy zamówień, stawki VAT, jednostki miary, stany magazynowe, ceny promocyjne, sposób zaokrąglania kwot.
• Faktury, korekty, zwroty — Ustal, czy potrzebna jest faktura automatyczna, korekta przy zwrocie i zamówienia u dostawców przy drop shippingu.
• Gotowy moduł czy moduł własny — Zapytaj o koszt licencji na 36 miesięcy i o to, kto aktualizuje moduł, gdy operator zmieni API. Porównaj to z jednorazowym kosztem modułu własnego.
• Dane dostępowe — Sprawdź, kto dostarcza klucze API, loginy i uprawnienia oraz czy są one wydane na firmę klienta, a nie na wykonawcę.
• Monitoring i wsparcie — Ustal, kto dostaje alert, gdy integracja przestanie działać, i jaki jest czas reakcji zapisany w umowie.
• Dokumentacja powdrożeniowa — Wymagaj jednego dokumentu z opisem konfiguracji i danymi dostępowymi. Maile i zrzuty ekranu to za mało, gdy zmienisz wykonawcę.
• Koszt utrzymania — Spytaj, ile godzin rocznie zajmują aktualizacje i poprawki. Wpisz to do budżetu obok jednorazowego wdrożenia.

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