Integracje z ERP, płatnościami i kurierami w Frampolu to nie trzy osobne projekty, tylko jeden łańcuch: pieniądze → dokument → paczka. Najwięcej traci się nie na błędzie w kodzie, a na braku właściciela procesu: nikt nie pilnuje numeracji dokumentów i nikt nie sprawdza, co się dzieje, gdy webhook płatności nie dojdzie. Poniżej część organizacyjna: błędy, które widzimy najczęściej, checklista przed startem i pytania, które trzeba zamknąć, zanim ktokolwiek napisze pierwszą linię kodu. Jeśli dopiero wybierasz platformę, zobacz też naszą stronę o wdrożeniach i migracjach PrestaShop w Frampolu.
Integracja w jednym zdaniu: to takie połączenie trzech systemów, żeby dane przechodziły między nimi same — ERP pilnuje magazynu i księgowości, operator płatności pilnuje pieniędzy, kurier pilnuje dostawy. Nie da się tego rozwiązać pojedynczo, bo każdy element zależy od poprzedniego: bez potwierdzonej płatności nie ma paczki, bez dokumentu w ERP nie ma faktury, bez numeru przesyłki nie ma statusu „wysłane”.
Cztery wymierne efekty, które widzimy w projektach:
Kontrprzykład: sklep przepisujący zamówienia do Subiekta ręcznie. Na jedno zamówienie schodzi 3–8 minut, ale prawdziwe pieniądze uciekają gdzie indziej. Po pierwsze, błędy: zła ilość albo produkt, którego nie ma na półce — paczka wraca, a koszt przesyłki zwrotnej i ponownej wysyłki to zwykle 15–30 zł plus czas obsługi. Po drugie, rozjazd stanów o dzień lub dwa: sprzedajesz towar, którego fizycznie nie masz, zamówienie trzeba anulować, a klient nie wraca. Po trzecie, opóźnione dokumenty — faktura wystawiona poza okresem rozliczeniowym to problem dla księgowości, nie dla sklepu.
Kiedy integracja NIE ma sensu. Przy mniej niż 20–30 zamówieniach miesięcznie koszt trzech integracji zwraca się 2–3 lata. Jeśli masz kilkanaście produktów, jednego przewoźnika i jedną osobę, która i tak obsługuje wszystko, ręczna obsługa jest po prostu tańsza. Ten sam łańcuch opisujemy szczegółowo dla mniejszej skali w materiale o integracjach z ERP, płatnościami i kurierami w Józefowie.
Porównaj tę listę z własnym sklepem i zaznacz kroki, w których nadal pracuje człowiek. To najszybszy sposób, żeby zobaczyć, gdzie tracisz czas.
Trzy miejsca, w których integracje pękają najczęściej:
Co się dzieje, gdy ERP jest niedostępny? Zamówienie i płatność zostają zapisane w sklepie, a zdarzenie trafia do kolejki. Ponowienia idą z backoffem: 1 min, 5 min, 15 min, 1 h; po trzech nieudanych próbach leci alert na maila. Etykieta może poczekać, pieniądze i dane klienta nie. Mechanizm webhooków w sklepie opisuje dokumentacja WooCommerce. Warianty tego procesu dla mniejszych miejscowości regionu znajdziesz w opisie integracji z ERP, płatnościami i kurierami w Szczebrzeszynie.
Nie ma „najlepszego ERP”. Jest system, który pasuje do trzech rzeczy: czy w firmie pracuje księgowość, czy ERP ma pełnić rolę magazynu (WMS), i ile dokumentów miesięcznie przechodzi przez system. Do kilkuset dokumentów miesięcznie i handlu z księgowością na Subiekcie GT wystarcza GT albo nexo. Powyżej tysiąca dokumentów, z produkcją albo wieloma kanałami sprzedaży, warto patrzeć na Optimę lub enova365.
Koszty w tabeli to przedziały orientacyjne dla samej integracji sklepu, nie oferta — wycena zależy od liczby mapowanych pól, liczby przewoźników i tego, czy integracja obejmuje też dokumenty księgowe, czy tylko magazyn.
| System | Dla kogo | Typ integracji | Typowy koszt wdrożenia (orientacyjnie) | Największa pułapka |
|---|---|---|---|---|
| Subiekt GT | Handel detaliczny z księgowością na GT, do kilkuset–tysiąca dokumentów miesięcznie | Baza SDF przez oficjalne konektory | 3–8 tys. zł | Insert nie wspiera modyfikacji bazy SDF — każda zmiana to ryzyko przy aktualizacji programu |
| Subiekt nexo | Firmy, które chcą iść na API i nie wracać do plików wymiany | API / WebAPI, częściowo Sfera nexo | 4–12 tys. zł | Część operacji nadal wymaga Sfery, a nie czystego API — trzeba to sprawdzić przed wyceną |
| Comarch Optima | Firmy z pełną księgowością, produkcją, większą liczbą dokumentów | API REST + Sfera | 8–20 tys. zł | Złożone mapowanie pól i statusów; testy bez kopii bazy są praktycznie niemożliwe |
| WF-Mag | Małe firmy, w których ERP ma być magazynem i fakturowaniem | Bezpośrednie łączenie z bazą (brak API) | 3–9 tys. zł | Brak API — własne zapytania do bazy trzeba utrzymywać przy każdej aktualizacji programu |
| enova365 | Firmy średnie, które chcą elastycznego ERP z realnym API | API | 8–20 tys. zł | Koszt licencji i konfiguracji po stronie ERP; projekt trwa dłużej niż przy Subiekcie |
Prowizje to pierwsze, co się porównuje, ale nie jedyne. Orientacyjne stawki rynkowe na 2024/2025: BLIK ok. 0,9–1,3% od transakcji, karty 1,2–1,9%. Przelewy24, PayU i Tpay wyceniają indywidualnie — stawka spada wraz z obrotem, a przy niższych obrotach dochodzi opłata stała za transakcję. Stripe dla kart z EEA to około 1,5% + 1 zł. Te liczby traktuj jako punkt startowy do rozmowy z operatorem, nie jako wiążący cennik.
Kryteria wyboru są trzy i wynikają z koszyka, nie z cennika:
Webhook to fundament, nie dodatek. Bramka powiadamia Twój sklep o płatności, a ten mechanizm musi być zabezpieczony: weryfikacja podpisu HMAC, idempotencja po identyfikatorze transakcji (ten sam webhook potrafi dojść dwa razy), ponowienia po Twojej stronie z wykładniczym backoffem. Najczęstsza pułapka: sklep przyjmuje webhook bez sprawdzania podpisu. Wtedy kilka ręcznie wysłanych żądań POST na publiczny adres daje darmowe zamówienia. Druga pułapka: brak obsługi sytuacji, gdy webhook nie dojdzie — pieniądze wpłynęły, a zamówienie wisi w statusie „oczekuje na płatność”.
Testuj na sandboxie każdej bramki, na jednej liście scenariuszy: sukces, odmowa banku, timeout, zwrot pełny i częściowy, powtórzony webhook. Integrację bramki w WooCommerce opisuje dokumentacja WooCommerce.
| Bramka | Karty (orientacyjnie) | BLIK (orientacyjnie) | Kiedy sensowna |
|---|---|---|---|
| Przelewy24 | 1,2–1,9%, stawka zależna od obrotu | dostępny, stawka wg umowy (ok. 0,9–1,3%) | szeroki wybór metod płatności, sklepy z dużym udziałem BLIK-a |
| PayU | stawka negocjowana od obrotu | dostępny, stawka wg umowy | gdy potrzebujesz rat lub Płacę później |
| Tpay | stawka negocjowana, atrakcyjna przy niższych obrotach | dostępny, stawka wg umowy | prosty sklep, jeden kanał sprzedaży, szybki start |
| Stripe | ok. 1,5% + 1 zł (karty EEA) | dostępny w wybranych konfiguracjach | subskrypcje, sprzedaż międzynarodowa, niestandardowe flow |
Trzech operatorów, trzy API i trzy modele rozliczeń. InPost ShipX API obsługuje Paczkomaty 24/7 i kuriera. DPD WebAPI — kuriera i punkty Pickup. DHL24 — kuriera i punkty POP. Dla klientów z rejonu Frampol–Zamość najważniejsza różnica nie leży w API, a w gęstości punktów odbioru. Zanim wybierzesz zestaw, sprawdź w wyszukiwarce punktów każdego operatora, ile automatów i punktów wypada w promieniu 5 km od Frampola, Biłgoraja i Zamościa. Jeśli w jednej gminie jest jeden punkt, a w drugiej pięć, klient szybciej wybierze tę drugą metodę — i to przełoży się na porzucenia koszyka, nie na Twoją konfigurację.
Generowanie etykiety. W requeście wysyłasz: wymiary (długość/szerokość/wysokość), wagę, gabaryt, typ usługi (paczkomat vs kurier), punkt nadania lub odbioru, dane odbiorcy, flagę pobrania i wartość ubezpieczenia. W responsie dostajesz numer trackingu oraz plik etykiety w PDF lub ZPL. ZPL ma sens tylko przy drukarce termicznej — na zwykłej laserowej drukuj PDF.
Pułapka numer jeden: brak mapowania usług. „Paczkomat” i „kurier” muszą być osobnymi metodami dostawy w sklepie, powiązanymi z osobnym typem usługi w API. Bez tego ERP wygeneruje etykietę kurierską dla zamówienia do Paczkomatu — dopłata i reklamacja. Podobnie przy gabarycie: automat ma limity wymiarów i wagi, a przekroczenie kończy się odmową przyjęcia paczki.
Statusy. Webhooki kuriera są szybsze, ale wymagają publicznego endpointu i weryfikacji źródła żądania. Cykliczne odpytanie API co 15–30 minut jest prostsze, ale opóźnione i ograniczone limitami requestów. Rozsądny kompromis: webhook jako kanał główny, polling raz na godzinę jako zabezpieczenie. Moduł przewoźnika w PrestaShop opisany jest w dokumentacji deweloperskiej PrestaShop, a porównanie podobnych wdrożeń w regionie znajdziesz w materiale o integracjach z płatnościami i kurierami w Zamościu.
| Operator | API | Typy przesyłek | Etykieta / tracking |
|---|---|---|---|
| InPost | ShipX API | Paczkomaty 24/7, kurier | PDF lub ZPL, numer trackingu w response |
| DPD | DPD WebAPI | kurier, punkty Pickup | PDF lub ZPL, numer trackingu w response |
| DHL | DHL24 | kurier, punkty POP | PDF lub ZPL, numer trackingu w response |
Wycena integracji to liczba godzin, nie „pakiet”. Realny rozkład prac wygląda tak: analiza i mapowanie (4–8 h), integracja ERP (16–40 h), płatności (6–12 h), kurierzy (8–16 h), testy end-to-end (8–16 h), dokumentacja i szkolenie (4–6 h). Razem 46–98 godzin w zależności od tego, czy ERP ma gotowe API, czy trzeba je dopiero wystawić.
Przykładowe budżety. Mały sklep WooCommerce + Subiekt nexo + 1 kurier to około 2 500–4 500 zł netto. PrestaShop + Optima + 3 kurierów to około 6 000–12 000 zł netto. Skąd tak duża różnica przy podobnej liczbie godzin? Dolna granica działa wtedy, gdy płatności i kurier wchodzą z gotowych modułów (praca sprowadza się do konfiguracji i testów), a ERP wymienia dane przez eksport/import CSV, a nie przez REST API. Pełne API ERP plus mapowanie stanów magazynowych i numeracji dokumentów to zawsze górna połowa widełek.
Stawki godzinowe na polskim rynku dla małych i średnich firm w 2025 roku: 120–250 zł/h netto. Stawka 120 zł/h oznacza zwykle mniejsze studio lub freelancera bez zaplecza serwerowego; 250 zł/h to zespół z SLA i wsparciem po wdrożeniu.
Czas wdrożenia: 1–2 tygodnie przy prostym zakresie (jedna bramka, jeden kurier, gotowy moduł ERP), 4–8 tygodni przy ERP plus wielu kanałach sprzedaży i wielu kurierach.
Sygnały ostrzegawcze w wycenach: brak rozbicia na godziny, cena ryczałtowa bez listy funkcji i bez zakresu wyłączonego, brak ustaleń o wsparciu po wdrożeniu (kto reaguje, gdy webhook padnie w piątek przed Black Friday). Zanim podpiszesz umowę, przeczytaj też nasz materiał o organizacji wdrożenia i migracji PrestaShop we Frampolu.
| Etap prac | Czas (godziny) | Za co się płaci |
|---|---|---|
| Analiza i mapowanie | 4–8 h | ustalenie pól, statusów i numeracji dokumentów między sklepem a ERP |
| Integracja ERP | 16–40 h | API lub wymiana plików, stany magazynowe, faktury |
| Płatności | 6–12 h | bramka, webhooki, obsługa zwrotów |
| Kurierzy | 8–16 h | API, etykiety, mapowanie usług, statusy |
| Testy E2E | 8–16 h | scenariusze od koszyka do potwierdzenia nadania |
| Dokumentacja i szkolenie | 4–6 h | instrukcja, przekazanie wiedzy zespołowi |
Poniższe pułapki widzimy w projektach najczęściej. Do każdej dopisaliśmy test, który da się wykonać na środowisku testowym w 15–60 minut. Jeśli wykonawca nie umie pokazać wyniku testu, zakres nie jest domknięty. Testy rób na kopii danych, nie na produkcji — kontekst organizacyjny opisujemy w materiale o organizacji wdrożeń i migracji PrestaShop w Frampolu.
| Pułapka | Test przed startem | Wynik, który ma być |
|---|---|---|
| Duplikaty zamówień przy ponowieniu webhooka płatności | Wyślij ten sam webhook 5 razy (ten sam identyfikator transakcji) | Powstaje jedno zamówienie; powtórki odrzucane po ID transakcji, klucz unikalny w bazie |
| Rozjazd stanów magazynowych między sklepem a ERP | Sprzedaj ostatnią sztukę jednocześnie z dwóch kanałów (sklep + marketplace) | Drugie zamówienie nie schodzi z zerowego stanu: blokada, backorder albo jasny komunikat; ERP widzi 0 |
| Kolizja numeracji dokumentów przy sprzedaży w kilku kanałach | Wystaw 100 dokumentów równolegle z dwóch kanałów | Numery są unikalne i rosnące; numer nadaje jedno miejsce (ERP albo osobny serwis numeracji), nie dwa systemy |
| Timeout API kuriera bez kolejki zdarzeń | Zablokuj ruch do API kuriera na 5 minut i złóż zamówienie | Zamówienie wraca do kolejki, próba powtarza się z odstępem, nic nie ginie |
| Brak logów i monitoringu | Wywołaj celowo błąd 5xx po stronie partnera | Alert dociera do człowieka w kilka minut, z ID zamówienia i treścią odpowiedzi |
| Brak mapowania stawek VAT i jednostek | Zamów produkt z inną stawką VAT i jednostką (szt. i kg) | Dokument w ERP zgadza się co do stawki, jednostki i zaokrągleń; brak różnicy groszowej |
| Nieobsłużone zwroty i korekty w ERP | Złóż zwrot częściowy (1 z 3 pozycji) | W ERP powstaje korekta, stan wraca na magazyn, refund idzie z bramki płatniczej |
| Brak planu na awarię ERP | Zatrzymaj ERP na 30 minut w godzinach szczytu | Sklep nadal przyjmuje zamówienia, zapisuje je lokalnie i dogrywa do ERP po jego powrocie |
| Stany w wielu magazynach bez priorytetu | Ten sam towar w dwóch magazynach, zamówienie z jednej gminy | Jest zapisana reguła (koszt dostawy, czas, dostępność), z którego magazynu idzie towar |
| Brak testów na danych produkcyjnych | Powtórz cały przepływ na kopii bazy i konfiguracji produkcyjnej | Liczby i dokumenty się zgadzają; brak pustych pól i rekordów-bliźniaków |
Ta lista jest do odklikania. Dwanaście punktów w pięciu etapach. Ostatnia kolumna mówi, czy punkt jest krytyczny — trzech krytycznych nie wolno pominąć, reszta może poczekać do pierwszego tygodnia po starcie, ale musi mieć termin i właściciela.
Trzy punkty krytyczne: (1) idempotencja płatności — bez niej pierwsza większa promocja wygeneruje duplikaty zamówień; (2) kolejka zdarzeń i ponowień dla kuriera oraz ERP — bez niej każde zatrzymanie API to zgubione zamówienie; (3) testy na kopii bazy produkcyjnej — bez nich prawdziwe dane zobaczysz pierwszy raz na produkcji, w godzinach szczytu.
Do każdego punktu dopisz właściciela (imię, nie dział) i datę. Zachowanie webhooków i zdarzeń w WooCommerce opisuje oficjalna dokumentacja WooCommerce — pamiętaj jednak, że opisuje, jak zdarzenie wysłać, a nie jak bezpiecznie je ponowić. To już decyzja projektowa po Twojej stronie.
| Etap | ☐ Punkt | Krytyczny? |
|---|---|---|
| Przygotowanie | ☐ Spis procesów: kto dziś wystawia dokument, kto nadaje paczkę, kto robi korektę — imiona, nie działy | Nie |
| Przygotowanie | ☐ Wybór systemu nadrzędnego dla stanów i numeracji (ERP czy sklep), zapisany na piśmie | Nie |
| Przygotowanie | ☐ Mapowanie danych podstawowych: stawki VAT, jednostki, kody produktów (SKU/EAN), kontrahenci | Nie |
| Przygotowanie | ☐ Środowisko testowe plus kopia bazy produkcyjnej z zanonimizowanymi danymi osobowymi | Nie |
| Wdrożenie | ☐ Klucze API: osobne konto integracyjne, uprawnienia minimalne, zaplanowana rotacja kluczy | Nie |
| Wdrożenie | ☐ Idempotencja płatności: unikalny klucz zdarzenia i ochrona przed duplikatem zamówienia | TAK |
| Wdrożenie | ☐ Kolejka zdarzeń i ponowienia z rosnącym odstępem dla kuriera i ERP | TAK |
| Testy | ☐ Scenariusze brzegowe: ostatnia sztuka, zwrot częściowy, anulowanie po opłaceniu, płatność za pobraniem | Nie |
| Testy | ☐ Pełny przebieg na kopii bazy produkcyjnej, m.in. 100 dokumentów równolegle | TAK |
| Start | ☐ Okno wdrożenia poza szczytem, plan wycofania (rollback) i nazwisko osoby decyzyjnej | Nie |
| Start | ☐ Monitoring i alerty włączone przed startem, nie dzień po | Nie |
| Opieka po starcie | ☐ Przegląd kolejek i logów raz w tygodniu przez pierwszy miesiąc + lista błędów do poprawy | Nie |
Frampol, Biłgoraj, Zwierzyniec i Szczebrzeszyn łączy jedno: punkty odbioru są rzadsze niż w Lublinie, a trasa kuriera dłuższa. To nie detal — to zmienna, która przekłada się na koszt ostatniej mili i na to, czy darmowa dostawa jeszcze się spina.
Jak dobrać kuriera pod gęstość punktów: wejdź w wyszukiwarkę punktów każdego z 3–4 kurierów, wpisz kod pocztowy Frampola, a potem Biłgoraja, Zwierzyńca i Szczebrzeszyna, policz punkty w promieniu 5 km i sprawdź, ile z nich pracuje w sobotę. Drugi krok to API: czy oddaje zdarzenia statusów (webhooki), czy tylko pozwala wygenerować etykietę. Jeśli tylko etykietę, statusy trzeba dopytywać harmonogramem — czyli potrzebna jest kolejka zdarzeń opisana w pierwszej sekcji.
Koszt ostatniej mili policz sam, bo cennik kuriera to nie cały koszt: podziel koszt jednego kursu (paliwo, czas kierowcy, opłata za strefę) przez liczbę paczek, które realnie mieszczą się na trasie w danej gminie. Przy rozproszonej zabudowie ta liczba jest niższa niż w mieście, więc koszt na paczkę rośnie. Z tego licz próg darmowej dostawy: próg = koszt dostawy ÷ marża procentowa na przeciętnym koszyku. Przykład liczbowy (metoda, nie nasz cennik): dostawa 16 zł, marża 35% — próg wychodzi około 46 zł.
Wsparcie lokalnie czy zdalnie: model lokalny wygrywa, gdy problem siedzi w sieci, drukarce etykiet albo w tym, że trzeba zobaczyć magazyn na miejscu; przegrywa kosztem dojazdu i dostępnością wąskiego specjalisty od ERP. Model zdalny wygrywa czasem reakcji i dostępem do specjalizacji, ale wymaga zdalnego dostępu (VPN, SSH), aktualnej dokumentacji i osoby po Twojej stronie, która potwierdzi, że poprawka działa.
Sąsiednie gminy mamy opisane osobno: integracje z ERP, płatnościami i kurierami w Zamościu, to samo dla Józefowa, integracje w Krasnobrodzie, integracje w Zwierzyńcu i integracje w Szczebrzeszynie.
Wycena w DropDigital: podaj platformę (PrestaShop, WooCommerce), liczbę integracji (ERP, bramka, kurier), liczbę zamówień miesięcznie, czy ERP ma API oraz kto jest właścicielem procesu. Wycena to liczba godzin × stawka, z rozbiciem na audyt, wdrożenie, testy i opiekę — bez cennika z sufitu. Stawek nie publikujemy, bo zależą od zakresu; podajemy je w ofercie.
Brak jednej osoby odpowiedzialnej za mapowanie pól między sklepem a ERP.
Jak wykryć: Zadaj pytanie: kto zatwierdza, że pole VAT w sklepie odpowiada polu stawki w ERP? Jeśli w odpowiedzi pojawia się więcej niż jedno nazwisko albo cisza — nie ma właściciela.
Jak naprawić: Wyznacz jedną osobę po stronie firmy (nie dewelopera), która zatwierdza mapowanie. Spisz to w jednym dokumencie i wersjonuj razem z kodem integracji.
Przyjmowanie płatności bez weryfikacji podpisu webhooka i bez idempotencji.
Jak wykryć: Wyślij ten sam webhook dwa razy i sprawdź, czy w sklepie powstaną dwa potwierdzenia. Sprawdź też, czy w kodzie jest jakakolwiek weryfikacja podpisu HMAC.
Jak naprawić: Weryfikuj podpis każdego żądania, zapisuj identyfikator zdarzenia i odrzucaj duplikaty. Bez tego można dostać fałszywe potwierdzenie i darmowe zamówienie.
Import stanów z ERP nadpisuje ręczne korekty w sklepie, a korekty w sklepie nie wracają do ERP.
Jak wykryć: Poproś o wydruk stanów z obu systemów w tym samym momencie. Jeśli różnice pojawiają się regularnie i nie da się ich wytłumaczyć jednym zdarzeniem — reguła nadrzędności jest nieustalona.
Jak naprawić: Ustal jedną regułę: ERP jest źródłem prawdy dla stanu, sklep tylko sprzedaje. Ręczne korekty w sklepie wyłącz albo zapisuj jako osobne zdarzenie korygujące.
Integracja bez kolejki zdarzeń i bez ponawiania — gdy ERP albo API kuriera chwilę nie działa, zamówienie przepada.
Jak wykryć: Sprawdź w logach, czy istnieje jakikolwiek mechanizm retry. Zablokuj na 5 minut dostęp do ERP i złóż testowe zamówienie.
Jak naprawić: Wprowadź kolejkę zdarzeń i ponawianie z rosnącym odstępem (backoff). Zamówienie nie może zniknąć tylko dlatego, że serwer był niedostępny przez minutę.
Księgowość wystawia faktury ręcznie, mimo że integracja też je tworzy.
Jak wykryć: Policz faktury z jednego miesiąca w ERP i porównaj z liczbą zamówień opłaconych w sklepie. Duplikaty albo brakujące dokumenty pokażą problem od razu.
Jak naprawić: Ustal jedno źródło dokumentu. Jeśli faktura powstaje w ERP, sklep ma tylko przekazać dane i odebrać numer. Zablokuj ręczne wystawianie tam, gdzie działa automat.
Testowanie wyłącznie szczęśliwej ścieżki: poprawne zamówienie, poprawna płatność, poprawna etykieta.
Jak wykryć: Zapytaj, ile scenariuszy błędów przetestowano: nieudana płatność, zwrot, korekta, adres zagraniczny, brak numeru telefonu w danych do etykiety.
Jak naprawić: Rozpisz listę scenariuszy przed startem i przejdź ją na środowisku testowym. Zwroty i korekty zdarzają się w każdym sklepie, więc muszą być przetestowane tak samo jak zwykłe zamówienie.
Integracje z ERP, płatnościami i kurierami Frampol wygrywają albo przegrywają na etapie organizacji, nie kodowania. Najczęstsze problemy to brak właściciela mapowania pól, brak weryfikacji webhooków i brak kolejki zdarzeń na wypadek awarii. Zanim wydasz pieniądze, odpowiedz na dwa pytania: ile masz zamówień miesięcznie i kto po Twojej stronie zatwierdza uzgodnienia. Podobne wdrożenia prowadziliśmy w regionie, m.in. w Zamościu.
Najbezpieczniejsza kolejność to płatności, potem ERP, na końcu kurier. Płatności są najprostsze do sprawdzenia: albo webhook dochodzi i podpis się zgadza, albo nie. ERP to najtrudniejszy element, bo dotyka magazynu i księgowości, więc warto go wdrażać, gdy potwierdzanie płatności działa stabilnie co najmniej kilka tygodni.
Jeśli integracja jest napisana porządnie, zamówienie trafia do kolejki zdarzeń i jest ponawiane z rosnącym odstępem, aż ERP odpowie. Klient widzi normalne potwierdzenie zamówienia, a dokument w ERP powstaje z opóźnieniem, o którym wie tylko obsługa. Jeśli kolejki nie ma, zamówienie po prostu przepada i dowiesz się o tym dopiero od klienta.
Insert nie wspiera modyfikacji pliku bazy SDF przez zewnętrzne narzędzia, więc integracja zwykle idzie przez konektory łączące się z bazą po stronie dewelopera. To działa, ale wymaga osoby, która rozumie ten mechanizm, robi kopie przed każdą zmianą i testuje na kopii, a nie na produkcji. Tanio kupisz skrypt, drogo zapłacisz za odzyskanie bazy.
Punktem odniesienia jest liczba zamówień, nie sam obrót. Przy mniej niż 20–30 zamówieniach miesięcznie ręczne przepisywanie zajmuje mniej czasu niż utrzymanie integracji, a zwrot z inwestycji wychodzi po dwóch, trzech latach. Powyżej 50–80 zamówień miesięcznie ręczna praca zaczyna kosztować więcej niż wdrożenie.
Jedna osoba po stronie firmy, najlepiej ta, która zna zarówno magazyn, jak i księgowość. Deweloper proponuje rozwiązanie, ale nie wie, czy stawka 23% w sklepie ma odpowiadać konkretnej pozycji w ERP. Bez tej osoby mapowanie rozjeżdża się przy pierwszej zmianie stawek albo jednostek miary.
Tak. Generowanie etykiet wymaga danych umowy: numeru klienta, danych nadawcy, umówionego cennika i dostępu do panelu kuriera. Bez tego można co najwyżej przekazać dane do formularza, ale nie wygenerować etykiety automatycznie. Warto też zapytać kuriera o limity zapytań do API, bo to wpływa na liczbę etykiet generowanych w jednej serii.
Ma, ale mniejsze niż jakość dokumentacji. PrestaShop i WooCommerce mają publiczne dokumentacje dla deweloperów, w których sprawdzisz, jak podpiąć się do zamówień i statusów. Zanim wybierzesz platformę, sprawdź, czy istnieje konektor do Twojego ERP i czy jest utrzymywany, a nie tylko opublikowany kilka lat temu.
Napisz do nas krótko: jaki masz sklep, jaki ERP i ile zamówień miesięcznie. Odpowiemy, czy integracja ma u Ciebie sens i od którego elementu zacząć.