Integracje z ERP, płatnościami i kurierami w Bełżcu sprowadzają się do jednego: zamówienie ze sklepu ma samo trafić do magazynu, oznaczyć się jako opłacone i wygenerować etykietę, bez przepisywania danych ręcznie. Bełżec to rynek MŚP w powiecie tomaszowskim, gdzie liczy się szybka wysyłka i obsługa zamówień, a nie rozbudowana struktura IT. Do spięcia są trzy procesy: zamówienie → magazyn → płatność → etykieta → status. Różnica między integracją a ręcznym przepisywaniem to zwykle 5–15 minut na zamówienie, czyli przy 20 zamówieniach dziennie 2–5 godzin pracy w tygodniu. Szerszy kontekst regionalny znajdziesz w artykule o integracjach z ERP, płatnościami i kurierami w Lublinie.
Bełżec to rynek MŚP w powiecie tomaszowskim. W firmie liczącej 2–10 osób ten sam człowiek odbiera telefon, pakuje paczkę, wystawia fakturę i pilnuje stanów magazynowych. Nie ma tu działu IT ani czasu na wielomiesięczny projekt. Dlatego integracje wdraża się etapami — tylko tam, gdzie efekt widać od razu.
Do spięcia są trzy procesy: zamówienie → magazyn → płatność → etykieta → status. Pierwszy to przepływ zamówienia ze sklepu do ERP, czyli dokument sprzedaży i rezerwacja stanu. Drugi to płatność — bramka odsyła status „opłacone” i sklep sam zmienia status zamówienia. Trzeci to wysyłka — z danych zamówienia powstaje etykieta kurierska, a numer przesyłki wraca do sklepu i mailem do klienta.
Pułapka numer jeden: wdrożenie samej bramki płatności, bez połączenia z ERP. Sklep ładnie pokazuje „opłacone”, ale stany magazynowe i dokumenty nadal prowadzisz ręcznie. Efekt jest połowiczny i szybko zniechęca do kolejnych kroków.
Jeśli sprzedajesz też poza najbliższą okolicą, warto porównać własną sytuację z tym, jak wyglądają integracje z ERP, płatnościami i kurierami w Lublinie — skala i liczba kanałów sprzedaży zmieniają kolejność wdrożenia, ale procesy zostają te same.
Audyt to jedna rozmowa, maksymalnie dwie godziny, plus eksporty danych. Bez niego wdrożenie zamienia się w zgadywanie, który stan magazynowy jest prawdziwy.
Systemy do spięcia:
Inwentaryzacja pól. Dla każdego produktu potrzebujesz: SKU, EAN lub innego kodu kreskowego, stanu, ceny netto i brutto, stawki VAT, jednostki, domyślnego kuriera, wagi i gabarytów. Jeśli w sklepie nie ma EAN-ów, etykiet nie da się generować automatycznie — to pierwsza rzecz do uzupełnienia. Eksport produktów robisz w WooCommerce przez Products → Export (plik CSV), a w PrestaShop przez Zaawansowane parametry → Import. Dokumentacja WooCommerce opisuje dokładnie, jakie kolumny wchodzą w taki plik, więc warto się nią posłużyć przy porządkowaniu danych.
Pytania o wolumen. Ile zamówień dziennie i miesięcznie? Ile w najgorszym dniu roku? Kiedy są szczyty — święta, majówka, sezon letni? Czy pracujecie w weekendy? Od tego zależy częstotliwość synchronizacji: czy wystarczy harmonogram co 5 minut, czy trzeba reagować na zdarzenie w momencie zapłaty.
Dobrym punktem odniesienia jest wdrożenie w sąsiednim powiecie: integracje z ERP, płatnościami i kurierami w Biłgoraju opisują podobny układ systemów i kolejność prac, którą można powtórzyć u siebie.
| System | Co wysyła | Co odbiera |
|---|---|---|
| Sklep (PrestaShop / WooCommerce) | zamówienie, dane klienta, adres dostawy | stan magazynowy, cenę, numer dokumentu |
| ERP | stan, cenę, dokument WZ/PZ/fakturę | zamówienie, korekty, zwroty |
| Bramka płatności | status „opłacone”, identyfikator transakcji | kwotę i dane zamówienia |
| Kurier | numer przesyłki, etykietę PDF | adres, wagę, gabaryty, kwotę pobrania |
Wybór ERP to nie kwestia mody, tylko tego, co system potrafi oddać na zewnątrz i jak często.
Synchronizacja dwukierunkowa obejmuje zwykle cztery strumienie: stany magazynowe (rezerwacja w ERP, uzupełnienie w sklepie), ceny i promocje, zamówienia (sklep → ERP jako zamówienie lub dokument sprzedaży) oraz dokumenty magazynowe i faktury wracające do sklepu jako informacja, co dzieje się z zamówieniem.
Trzy tryby i ich zastosowanie:
Częstotliwość ma konsekwencje sprzedażowe. Synchronizacja co godzinę przy towarze, którego masz 2 sztuki, kończy się sprzedażą bez pokrycia. Sprawdza się 5 minut dla stanów i cen oraz praca na zdarzenie (webhook) dla płatności i numeru przesyłki.
Mapowanie jednostek i stawek VAT to źródło nawet 80% błędów wdrożeniowych. Typowe przypadki: sklep sprzedaje w sztukach, ERP w kartonie 12 szt., cena netto kontra brutto, VAT 23% kontra 8% lub 5%, osobno stawka 0% przy WDT. Każda różnica kończy się ręczną korektą faktury. Dlatego mapowanie robi się raz, na próbce 20–30 produktów, i sprawdza na wystawionej fakturze — zanim uruchomisz cały katalog.
| Tryb integracji | Kiedy ma sens | Typowe opóźnienie | Główne ryzyko |
|---|---|---|---|
| API | ERP ze wspieranym, udokumentowanym API | sekundy | zmiana API bez ostrzeżenia |
| Pliki CSV/XML | Subiekt GT, WF-Mag, starsze wersje ERP | 5–60 minut | konflikt przy równoczesnej edycji towaru |
| Agent lokalny | ERP lokalnie, brak API | 1–5 minut | wyłączony komputer wstrzymuje synchronizację |
Bramka płatnicza ma dwa zadania: przyjąć pieniądze i powiedzieć sklepowi, że pieniądze faktycznie wpłynęły. To drugie załatwia webhook — żądanie z serwera bramki do sklepu, niezależne od tego, czy klient wrócił na stronę „dziękujemy”. Powrót klienta to tylko interfejs. Jeśli zamknie kartę przed powrotem, zamówienie zostanie w statusie „oczekuje na płatność”, choć wpłata jest już na koncie. Dlatego w konfiguracji bramki (Przelewy24, PayU, Autopay, Stripe) wpisujesz publiczny adres webhooka i weryfikujesz podpis lub checksum, a nie polegasz na parametrze w URL powrotu.
Druga rzecz: ten sam webhook potrafi przyjść dwa razy. Sklep musi obsłużyć go idempotentnie — po identyfikatorze transakcji sprawdzasz, czy status nie został już zmieniony. W PrestaShop to przejście na właściwy order state, w WooCommerce hook płatności ustawiający processing lub completed. Dopiero po tym kroku ERP dostaje sygnał do wystawienia dokumentu sprzedaży. Automatyczne oznaczenie „opłacone” i faktura w Subiekcie, Optywie czy enova365 eliminują codzienne parowanie przelewów w banku — zwykle kilkanaście minut dziennie.
Zwroty i reklamacje rób z panelu bramki, nie z panelu sklepu. Refund musi iść tą samą ścieżką co płatność, inaczej księgowość ma dwa źródła prawdy. Z panelu bramki obsłużysz też chargeback — pamiętaj, że karty rozliczają się tygodniami lub miesiącami, więc „zapłacone” nie znaczy „bezpieczne”.
BLIK i szybkie przelewy mają w polskim e-commerce najwyższą konwersję. Jeśli zostawiasz tylko karty, tracisz część koszyków na ostatnim ekranie. Płatności odroczone (np. PayU Płacę później, Klarna) podnoszą wartość koszyka, ale wnoszą status „oczekuje na weryfikację” — nie traktuj takiego zamówienia jako opłaconego, dopóki webhook nie potwierdzi akceptacji.
Ten sam schemat działa niezależnie od regionu — opisaliśmy go też przy integracjach z ERP, płatnościami i kurierami w Lublinie. Jak działają hooki zamówień, sprawdź w dokumentacji WooCommerce.
| Metoda | Co potwierdza webhook | Na co uważać |
|---|---|---|
| BLIK | transakcja zakończona sukcesem, ID transakcji | klient zamknął aplikację banku — status zmieni tylko webhook |
| Szybki przelew (Przelewy24, PayU, Autopay) | zaksięgowanie wpłaty | podwójne wywołania — wymagana idempotencja |
| Karta | autoryzacja i captacja | 3-D Secure, chargebacki rozliczane tygodniami |
| Płatności odroczone | akceptacja po weryfikacji klienta | nie oznaczaj jako opłacone przed decyzją bramki |
Etykieta generowana z poziomu sklepu to najczęstszy punkt wejścia. Przebieg jest stały: zamówienie trafia na status „do wysyłki”, moduł wysyła dane (nadawca, odbiorca, waga, gabaryt, kod punktu odbioru) do API kuriera, dostaje numer przesyłki i plik PDF do wydruku. Ten sam proces może obsłużyć ERP. Wybór jest jeden: albo sklep, albo ERP generuje etykietę. Dwa systemy robiące to równolegle to gwarancja podwójnych numerów i bałaganu w rozliczeniach z kurierem.
InPost: integracja przez API ShipX, kluczowe jest poprawne wskazanie punktu odbioru w zamówieniu i realnej wagi po zapakowaniu — nie wagi towaru. Gabaryt (A/B/C) wybieraj według aktualnej tabeli operatora, bo paczkomat odrzuci nadwymiarowe przesyłki przy nadaniu. DPD i DHL: poza samą etykietą liczy się zamówienie odbioru kuriera przez API oraz protokoły niezgodności, gdy paczek jest mniej niż na liście przewozowym. Nazwy i wersje API zmieniają się — aktualny endpoint i środowisko testowe potwierdź w panelu partnera kuriera.
Numer tracking musi od razu wygenerować maila do klienta z linkiem do śledzenia i zmienić status zamówienia na „wysłane”. Statusy pośrednie (przyjęta, w doręczeniu, doręczona, awizo) pobieraj webhookiem lub cyklicznym odpytaniem API. Bez tego klient dzwoni z pytaniem „gdzie paczka”, a Ty szukasz numeru w panelu kuriera.
Zwroty: etykieta zwrotna z numerem RMA, status „zwrot w drodze”, przyjęcie na magazyn, decyzja o zwrocie środków i spin z panelem bramki płatniczej. Te same pułapki widzimy u firm z okolic — porównaj integracje z ERP, płatnościami i kurierami w Biłgoraju oraz integracje w Krasnobrodzie. Techniczne podstawy modułów znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Kurier | Co integrujemy | Na co uważać |
|---|---|---|
| InPost | etykiety, paczkomaty i kurier, tracking | kod punktu, waga po zapakowaniu, gabaryt A/B/C |
| DPD | etykiety, zamówienie odbioru, tracking | protokoły niezgodności, harmonogram odbiorów |
| DHL | etykiety, zamówienie odbioru, tracking | limity i warunki przedpłaty, terminy odbioru |
Etap 1 — audyt. Zbieramy liczby: ile zamówień dziennie, kto dziś przepisuje dane, jaki ERP (Subiekt GT/nexo, Comarch Optima, WF-Mag, enova365), jaka bramka, jacy kurierzy, kto ma dostępy. Efekt to lista wąskich gardeł w stylu „ręczne faktury zajmują 40 minut dziennie”.
Etap 2 — mapowanie. Statusy sklepu do statusów ERP, słowniki form płatności i dostawy, stawki VAT, dane nabywcy do faktury. Tu powstaje najwięcej błędów, bo „zrealizowane” w sklepie i „zrealizowane” w ERP znaczą co innego.
Etap 3 — środowisko testowe: kopia sklepu, sandbox bramki, sandbox kuriera, testowa baza ERP albo osobna firma testowa w programie księgowym.
Etap 4 — moduł: gotowy moduł plus konfiguracja albo moduł dedykowany z warstwą pośredniczącą, gdy ERP nie ma sensownego API.
Etap 5 — testy: minimum 20 zamówień, 5 zwrotów, 3 anulacje, 2 płatności odroczone. Dorzuć przypadki brzegowe: 1 pozycja, 40 pozycji, kod rabatowy, brak towaru, wysyłka za granicę.
Etap 6 — produkcja: wdrożenie po godzinach, backup, plan wycofania i nadzór nad pierwszymi 20 zamówieniami.
Etap 7 — opieka: monitoring webhooków, alert, gdy zamówienie stoi w „oczekuje na płatność” dłużej niż 30 minut, kanał zgłoszeń i SLA. Realne SLA to czas reakcji 4–24 h zależnie od pory dnia i umowy, z wskazanym deweloperem i jednym kanałem zgłoszeń (mail lub system ticketowy, nie Messenger).
Podobne wdrożenia prowadziliśmy w okolicy — zobacz integracje z ERP, płatnościami i kurierami w Frampolu oraz integracje w Zwierzyńcu.
| Zakres | Szacunek godzin | Co obejmuje |
|---|---|---|
| Prosty | 40–80 h | 1 bramka, 1 kurier, przepływ zamówienie → ERP, faktura |
| Średni | 120–200 h | 2–3 metody płatności, 2 kurierów, stany magazynowe, synchronizacja dwukierunkowa |
| Złożony | 250+ h | kilka magazynów, marketplace, B2B, dedykowana warstwa pośrednicząca |
Nie ma jednego cennika integracji, bo nie ma jednej integracji. Realny punkt odniesienia to stawka 150–300 zł/h netto. Dolna granica to zwykle prace konfiguracyjne i wtyczkowe, górna – pisanie własnego connectora, obsługa błędów, kolejkowanie zdarzeń i praca z systemem, który nie ma porządnego API.
Typowe widełki dla sklepu MŚP wyglądają tak:
| Zakres | Typowy czas | Koszt netto przy 150 zł/h | Koszt netto przy 300 zł/h |
|---|---|---|---|
| Integracja z ERP – mapowanie pól, dokumenty, stany magazynowe | ok. 60 h | 9 000 zł | 18 000 zł |
| Integracja płatności – bramka, statusy, webhooki | 10–20 h | 1 500–3 000 zł | 3 000–6 000 zł |
| Integracja kurierska – etykiety, statusy przesyłek, zwroty | 15–30 h | 2 250–4 500 zł | 4 500–9 000 zł |
Co podnosi koszt po stronie godzin? Po pierwsze, dedykowane pola, których nie ma w standardzie – np. numer partii, data przydatności, kod opakowania. Każde takie pole trzeba przeprowadzić przez cały łańcuch. Po drugie, wiele magazynów – stany trzeba rozdzielić, a wysyłka musi wiedzieć, z którego miejsca idzie towar. Po trzecie, stare wersje ERP bez API albo z API udokumentowanym szczątkowo; wtedy dochodzi praca na bazie danych lub na plikach eksportu.
Do jednorazowego wdrożenia dochodzi utrzymanie: 300–1500 zł/mies. netto. Przy 300–500 zł dostajesz monitoring, aktualizacje wtyczki i reakcję na błędy. Przy 1000–1500 zł dochodzi opieka nad mapowaniem pól, obsługa zmian cenników i wsparcie przy dodaniu nowego przewoźnika.
Uwaga na oferty „od 500 zł za integrację”. Zwykle kończą się dopłatą za wszystko, co wyszło w trakcie. Lepiej znać liczbę godzin i zakres niż kwotę bez kontekstu. Jeśli pracujesz na PrestaShop, punktem startowym do własnego modułu jest dokumentacja dla deweloperów PrestaShop. Skalę podobnych projektów porównasz z naszymi wdrożeniami w integracjach z ERP, płatnościami i kurierami w Lublinie.
| Zakres | Typowy czas | Koszt netto przy 150 zł/h | Koszt netto przy 300 zł/h |
|---|---|---|---|
| Integracja z ERP (mapowanie pól, dokumenty, stany) | ok. 60 h | 9 000 zł | 18 000 zł |
| Integracja płatności (bramka, statusy, webhooki) | 10–20 h | 1 500–3 000 zł | 3 000–6 000 zł |
| Integracja kurierska (etykiety, statusy, zwroty) | 15–30 h | 2 250–4 500 zł | 4 500–9 000 zł |
Większość awarii integracji nie jest spektakularna. Sklep działa, tylko po cichu generuje pracę, której miało nie być. Cztery problemy wracają najczęściej.
Duplikaty zamówień przez brak idempotencji webhooków. Bramka płatności wysyła powiadomienie, nie dostaje potwierdzenia w czasie, więc wysyła je ponownie. Jeśli sklep nie zapisuje identyfikatora transakcji przed przetworzeniem, powstaje drugie zamówienie albo drugi dokument w ERP. Test jest prosty: wyślij ten sam payload webhooka dwa razy z tym samym ID transakcji i sprawdź, czy dokument powstał raz. Klucz idempotencji to numer transakcji lub numer zamówienia zapisany w bazie przed wykonaniem logiki.
Rozjazd stanów. Klient kupuje produkt, którego fizycznie nie ma. Nie sprawdzisz tego „na oko” – potrzebny jest log synchronizacji: kiedy przebiegła ostatnia, ile rekordów zaktualizowano, ile odrzucono. Alert powinien odpalać się nie tylko przy błędzie, ale też gdy synchronizacja nie wykonała się w oczekiwanym cyklu.
Błędne etykiety. Brak walidacji wymiarów i wagi przed nadaniem to zaproszenie do korekt od kuriera i dopłat za gabaryt. Wymuś wagę i wymiary gabarytowe w karcie produktu i blokuj generowanie etykiety, gdy ich brakuje.
Brak logów. Bez zapisu żądań i odpowiedzi nie wiadomo, co i kiedy się zepsuło. Minimum to retencja 30–90 dni i podgląd ostatnich błędów bez wchodzenia na serwer.
Praktyczny wskaźnik: jeśli ręcznie poprawiasz więcej niż 2 zamówienia w tygodniu, integracja wymaga poprawy – to nie „taka specyfika”, to defekt. Przy webhookach w WooCommerce punktem wyjścia jest oficjalna dokumentacja WooCommerce. Zanim zamówisz poprawki, warto porównać objawy z tym, co widzimy w projektach w integracjach z ERP, płatnościami i kurierami w Biłgoraju.
| Pułapka | Objaw | Gdzie sprawdzić |
|---|---|---|
| Brak idempotencji webhooka | Dwa zamówienia lub dwa dokumenty z jednej płatności | Log webhooków, zapis ID transakcji przed przetworzeniem |
| Rozjazd stanów magazynowych | Sprzedaż produktu, którego nie ma na magazynie | Log synchronizacji: rekordy OK, rekordy odrzucone, czas ostatniego przebiegu |
| Błędne etykiety | Korekty faktur od kuriera, dopłaty za gabaryt | Pola wagi i wymiarów w karcie produktu, walidacja przed nadaniem |
| Brak logów | Nie wiadomo, co i kiedy się zepsuło | Retencja logów 30–90 dni, podgląd błędów, alerty |
Wdrożenie integracji w Bełżcu i okolicznych gminach sprowadza się do trzech list: dla właściciela, dla magazynu i dla księgowości. Jeśli któraś pozycja jest niejasna, projekt będzie się ślizgał.
Kogo zaangażować: właściciel podejmuje decyzje o procesie, księgowość zatwierdza moment dokumentu, magazyn weryfikuje dane produktów, deweloper odpowiada za technikę. Bez jednej z tych osób zakres się rozjeżdża.
Zanim wystartujesz, sprawdź, jak wygląda to w sąsiednich gminach – punkt odniesienia dają wdrożenia w integracjach z ERP, płatnościami i kurierami w Frampolu, integracjach w Józefowie, integracjach w Krasnobrodzie oraz integracjach w Zwierzyńcu. Różnice najczęściej dotyczą liczby przewoźników i tego, czy księgowość pracuje na ERP, czy na zewnętrznym programie księgowym.
Kolejny krok: audyt 1–2 h. W jego trakcie ustalamy listę systemów, dostępne API, liczbę pól do mapowania i miejsca, gdzie dziś ludzie przepisują dane ręcznie. Na tej podstawie dostajesz wycenę opartą na liczbie godzin, a nie na widełkach „od–do”.
| Obszar | Kto odpowiada | Co musi być gotowe przed startem |
|---|---|---|
| Proces i decyzje | Właściciel | Lista systemów, osoby z dostępami, sposób wystawiania faktur |
| Dane produktów | Magazyn | Waga i wymiary gabarytowe dla wszystkich produktów |
| Dokumenty i statusy | Księgowość | Moment powstania dokumentu i mapowanie statusów zamówienia |
| Technika | Deweloper | Dostępy do API, tryb testowy, logi, idempotencja webhooków |
Start wdrożenia bez audytu – deweloper dostaje dostępy do sklepu, a lista systemów i pól powstaje w trakcie prac.
Jak wykryć: Nie istnieje żaden dokument z listą SKU, EAN, stawek VAT, jednostek miary i kodów kurierskich. Na pytanie „skąd bierzemy wagę do etykiety?” nikt nie potrafi odpowiedzieć w 30 sekund.
Jak naprawić: Zrób warsztat 2 godziny z właścicielem sklepu i osobą od magazynu. Wynikiem ma być arkusz mapowania pól i lista systemów, zanim powstanie pierwsza linia kodu.
Mapowanie jednostek i stawek VAT zostawione „na potem”, bo wydaje się oczywiste.
Jak wykryć: W ERP produkt jest w opakowaniu zbiorczym (np. 12 szt.), a w sklepie sprzedawany pojedynczo. Albo VAT w sklepie jest brutto, a w ERP netto – i stany zaczynają się rozjeżdżać po pierwszej synchronizacji.
Jak naprawić: Przygotuj tabelę zgodności: SKU → jednostka sklepowa → jednostka ERP → stawka VAT → sposób przeliczania. Przetestuj ją na 5 produktach z różnych grup, zanim włączysz pełną synchronizację.
Uznanie powrotu klienta na stronę „dziękujemy” za potwierdzenie płatności.
Jak wykryć: Zamówienia oznaczone jako opłacone nie mają odpowiednika w panelu bramki płatniczej. Klienci piszą o zamówieniu, które wisi jako nieopłacone, mimo że pieniądze zeszły z konta.
Jak naprawić: Oprzyj status płatności na webhooku z bramki, a nie na przekierowaniu przeglądarki. Powrót na stronę traktuj wyłącznie jako sygnał do odświeżenia widoku dla klienta.
Waga i gabaryt wpisane raz, przy starcie sklepu, i nieaktualizowane po zmianie opakowania.
Jak wykryć: API przewoźnika odrzuca etykiety albo nalicza dopłaty za niedoszacowaną wagę. Klient dostaje awizo, a paczka wraca do nadawcy.
Jak naprawić: Trzymaj wagę i gabaryt przy SKU w ERP, a dla paczek zbiorczych ustal regułę doliczania opakowania. Po każdej zmianie kartonu lub folii zaktualizuj dane i przepuść testowe etykiety.
Testy ograniczone do szczęśliwej ścieżki: jedno zamówienie, jedna płatność, jedna etykieta.
Jak wykryć: Nie ma scenariuszy na zwrot, anulowanie po opłaceniu i płatność odroczoną. Pierwszy prawdziwy zwrot kończy się ręcznym szukaniem numeru przesyłki i edycją statusów w bazie.
Jak naprawić: Ustal minimalny zestaw testów: 20 zamówień, 5 zwrotów, 3 anulacje, 2 płatności odroczone. Każdy scenariusz przechodzi na środowisku testowym i zapisuje wynik w notatce wdrożeniowej.
Brak ustalonego SLA i kanału zgłoszeń po zakończeniu wdrożenia.
Jak wykryć: Zgłoszenia trafiają na prywatny numer handlowca albo na WhatsApp, nikt ich nie zlicza, a drobna poprawka czeka tygodniami.
Jak naprawić: Podpisz prosty załącznik do umowy: czas reakcji 4–24 godziny, jeden kanał zgłoszeń (e-mail lub panel), jedna osoba kontaktowa po każdej stronie.
Organizacyjnie wdrożenie integracji w Bełżcu to przede wszystkim kolejność: audyt, mapowanie pól, środowisko testowe, moduł, testy, produkcja, opieka. Najwięcej czasu i pieniędzy pochłaniają błędy w mapowaniu jednostek i stawek VAT oraz brak webhooków płatności – nie sam kod. Realistyczne ramy to 40–80 godzin dla prostego sklepu i 250+ godzin dla złożonego, a stawka 150–300 zł/h netto daje przewidywalne widełki. Bez ustalonego SLA i kanału zgłoszeń nawet dobre wdrożenie staje się problemem przy pierwszej awarii.
Prosty sklep z jedną bramką i jednym przewoźnikiem to 40–80 godzin pracy. Średni projekt z dwukierunkową synchronizacją ERP i kilkoma przewoźnikami zajmuje 120–200 godzin, a złożony – z wieloma magazynami i kanałami sprzedaży – 250 godzin i więcej. Kalendarzowo przekłada się to zwykle na 3–8 tygodni, bo część czasu pochłaniają testy i uzgodnienia po stronie klienta.
Zwykle nie. Subiekt, Comarch, WF-Mag i Optima mają sposoby wymiany danych – przez API, pliki CSV/XML albo agent lokalny. Problem pojawia się tylko wtedy, gdy wersja programu nie udostępnia żadnej z tych dróg. Wtedy trzeba wybrać eksport plików w harmonogramie albo zaakceptować ręczne przenoszenie danych, co mocno ogranicza sens całego wdrożenia.
Tak, w obu przypadkach pracuje się na modułach integracyjnych. Zakres możliwości zależy jednak od wersji sklepu i konkretnego modułu, dlatego przed wyceną warto sprawdzić dokumentację: dla PrestaShop jest to dokumentacja deweloperska PrestaShop, a dla WooCommerce oficjalna dokumentacja WooCommerce. Kluczowe jest, czy moduł obsługuje webhooki i generowanie etykiet po stronie serwera.
Stawka rynkowa to 150–300 zł/h netto, zależnie od specjalizacji. Integracja ERP o zakresie około 60 godzin to koszt 9–18 tys. zł netto. Na końcową kwotę wpływa też jakość danych wejściowych: jeśli mapowanie jednostek i VAT trzeba ustalać od zera, dochodzi kilka do kilkunastu godzin na same uzgodnienia.
W polskim e-commerce BLIK i szybkie przelewy mają najwyższą konwersję, bo klient nie wpisuje danych karty i nie czeka na potwierdzenie przelewu tradycyjnego. Warunek jest jeden: status „opłacone” musi wynikać z webhooka, a nie z powrotu klienta na stronę. Inaczej rosnąca liczba zamówień zamienia się w rosnącą liczbę ręcznych korekt.
Najpierw zapytaj dostawcę o dokumentację API i listę zdarzeń. Jeśli webhooków nie ma, trzeba sprawdzać statusy płatności cyklicznie, co zawsze działa z opóźnieniem i generuje dodatkową pracę przy zwrotach i anulacjach. Przy wyborze bramki to kryterium warto postawić wyżej niż wysokość prowizji.
Nie. Integracje działają zdalnie i nie wymagają sprzętu na miejscu. Liczy się natomiast czas reakcji wykonawcy i kanał zgłoszeń – dla firmy z Bełżca wygodniejszy bywa wykonawca pracujący zdalnie z SLA 4–24 godziny niż lokalny specjalista dostępny „kiedy będzie”.
Jeśli chcesz przejść przez audyt i mapowanie danych przed wyceną, opisz nam swój sklep, ERP i przewoźników – powiemy wprost, co da się spiąć, a co wymaga zmiany po stronie systemu. Przykład podobnego wdrożenia w regionie znajdziesz w artykule o integracjach z ERP, płatnościami i kurierami w Biłgoraju.