Najczęstszy powód, dla którego integracja w sklepie „nie działa”, nie jest techniczny. To brak ustaleń: kto jest właścicielem stanu magazynowego, kto odpowiada za zamówienia bez płatności i kto pilnuje etykiet, które nigdy nie zostały nadane. Poniżej porządkujemy stronę organizacyjną: typowe błędy, listę kontrolną przed startem i odpowiedzi na pytania, które dostajemy najczęściej od firm z Józefowa i okolic. Traktuj to jako brief dla wykonawcy albo listę pytań do swojego dostawcy ERP. Część techniczną i kosztową opisujemy w pozostałych sekcjach artykułu.
„Integracja” w sklepie to nie jedno złącze, a trzy niezależne przepływy danych. Każdy ma inne API, inne ryzyko i innego właściciela. Mieszanie ich w jednym projekcie kończy się pytaniem „dlaczego stan się rozjechał”, na które nikt nie umie odpowiedzieć.
Przepływ jednego zamówienia wygląda tak: klient płaci BLIK-iem, operator wysyła webhook z potwierdzeniem, sklep ustawia status „opłacone”, a zadanie synchronizujące przekazuje zamówienie do ERP jako zamówienie klienta (ZK). ERP tworzy dokument, zapisuje rezerwację i zwraca numer dokumentu oraz realny stan magazynowy. Na końcu magazyn generuje etykietę u kuriera i numer listu przewodowego wraca do sklepu — dopiero wtedy paczka ma ślad w systemie. Każde ogniwo ma osobny punkt awarii i osobny log.
Kluczowa decyzja organizacyjna brzmi: który system jest źródłem prawdy o stanie magazynowym. W większości firm z magazynem i Subiektem jest to ERP — sklep sprzedaje, ERP rozlicza i decyduje o dostępności. Odwrotnie ma sens tylko przy sprzedaży wyłącznie online, bez fizycznego magazynu. Zanim podpiszesz umowę z wykonawcą, uporządkuj kolejność prac — pomaga w tym materiał o integracjach z PrestaShop i organizacji wdrożenia.
Zanim wybierzesz metodę integracji, ustal, jaki ERP faktycznie pracuje w firmie — od tego zależy większość pracy.
Co warto synchronizować: stany magazynowe z rezerwacjami, ceny z cennikami i promocjami, kartoteki towarów (EAN, waga, jednostka), zamówienia ze sklepu, dokumenty sprzedaży z powrotem do sklepu oraz płatności do rozliczenia.
Kierunek ma znaczenie. Stany i ceny puszczaj jednokierunkowo ERP → sklep. Dwukierunkowe stany to klasyczna pętla: sklep zapisze rezerwację z koszyka, ERP nadpisze ją realnym stanem, klient zobaczy „brak” w połowie zakupu. Dwukierunkowość ma sens dla zamówień i dokumentów — sklep wysyła ZK, ERP zwraca numer FS i status, a sklep tylko aktualizuje pola.
Trzy metody techniczne: API waliduje dane, ale ma limity zapytań i bywa płatne; baza danych jest szybka, lecz omija logikę ERP, psuje wsparcie producenta i sypie się przy aktualizacji; pliki CSV/XML są najprostsze, ale opóźnione i bez obsługi błędów — trzeba dołożyć kolejkę i log. Częstotliwość: stany co 5–15 minut, ceny raz na dobę w nocy, dokumenty na zdarzenie. Bez logu i alertu na błąd żadna z tych metod nie jest wdrożona. Podobne układy powtarzamy przy wdrożeniach w okolicy — zobacz integracje z ERP, płatnościami i kurierami w Krasnobrodzie oraz analogiczny zakres dla Zwierzyńca.
| Metoda | Zalety | Wady | Kiedy wybrać |
|---|---|---|---|
| API (REST/SOAP) | Walidacja danych, wsparcie producenta, obsługa błędów | Limity zapytań, koszt licencji, wymaga dokumentacji | Subiekt nexo, enova365, SAP B1 |
| Bezpośrednia baza danych | Szybko, dowolne pola, brak limitów | Omija logikę ERP, ryzyko przy aktualizacji, brak wsparcia | Stare Subiekt GT, WF-Mag, brak API |
| Pliki CSV/XML | Najprostsze, tanie, nie rusza ERP | Opóźnienie, brak sygnału o błędzie, konflikty zapisów | Rzadkie zmiany cen, mały katalog |
Operatora płatności wybierz po pięciu liczbach, nie po tym, kto głośniej się reklamuje. Stawki prowizji są negocjowane indywidualnie i zależą od obrotu, dlatego nie podajemy tu konkretnych procentów — pytaj o ofertę dla swojego wolumenu.
Metody, które realnie robią różnicę: BLIK jako domyślna dla klienta detalicznego, Apple Pay i Google Pay na mobile (skracają ścieżkę do dwóch kliknięć), pay-by-link dla zamówień telefonicznych i B2B, gdzie klient nie chce podawać danych karty na stronie. Karta jako jedyna opcja to dziś strata części koszyków.
Technicznie pilnuj trzech rzeczy. Po pierwsze, webhook o statusie transakcji (URL powiadomień) musi być obsłużony po stronie sklepu, a nie tylko skonfigurowany w panelu. Po drugie, żądania trzeba podpisywać kluczem i hashem — bez tego ktoś może podszyć się pod potwierdzenie płatności. Po trzecie, przejdź pełny test w trybie sandbox przed produkcją, łącznie z powtórzonym webhookiem: operator potrafi wysłać powiadomienie dwa razy, więc zapisuj transakcję po identyfikatorze i nie twórz drugiego zamówienia.
Najczęstsza pułapka to nieudana płatność. Klient zamyka okno, transakcja zostaje „pending”, zamówienie wisi jako „oczekuje na płatność”, rezerwacja blokuje towar, a klient nie wraca. Ustaw cron co 15 minut, po 60 minutach wyślij maila z ponowieniem płatności (pay-by-link), po 24 godzinach anuluj i zwolnij towar, a rano sprawdź raport zamówień bez płatności starszych niż doba. To proces, który ktoś musi pilnować — opisujemy to w sekcji o utrzymaniu i opiece technicznej sklepów, a szerszy kontekst regionalny znajdziesz w materiale o integracjach w Zamościu.
| Kryterium | O co zapytać operatora | Dlaczego to ważne |
|---|---|---|
| Prowizja | Stawka dla BLIK, kart i przelewu osobno, przy Twoim obrocie | Różnice między metodami zmieniają koszt miesięczny |
| Wypłata | T+1 czy T+7, jaki próg kwotowy | Bezpośrednio wpływa na płynność firmy |
| Chargeback | Kto prowadzi spór i jaka jest opłata | Pojedynczy spór potrafi zjeść marżę z kilku zamówień |
| Zwroty | Panel czy plik do banku, kto księguje | Zwroty robione ręcznie generują błędy w rozliczeniach |
| Sandbox | Czy jest środowisko testowe i dokumentacja webhooków | Bez testów wdrożenie płatności kończy się na produkcji |
Wybór przewoźnika w koszyku to kilka procent pracy. Reszta siedzi w trzech miejscach: etykiety, punkty odbioru i statusy przesyłek.
Etykiety i protokoły odbioru. Integracja powinna generować etykiety z panelu sklepu jednym kliknięciem, a przy większej liczbie zamówień — zbiorczo: zaznaczasz 40 zamówień, system tworzy 40 etykiet PDF i protokół odbioru dla kuriera. Protokół jest dowodem w sporze „kurier nie zabrał paczki”. Każdy przewoźnik ma własne API (InPost ShipX, DHL24, API DPD, GLS) i własne limity — masowe generowanie często trzeba rozbić na porcje, bo API odrzuca zbyt duży pakiet żądań. Konkretne limity potwierdź na swoim koncie: różnią się w zależności od umowy.
Mapa punktów i paczkomatów. Dane pochodzą z API przewoźnika, nie z map Google. Lista punktów zwykle odświeża się raz na dobę i jest cache’owana w sklepie. Efekt: klient wybiera punkt, który właśnie zamknięto. Zabezpieczenie: przy generowaniu etykiety waliduj kod punktu ponownie; jeśli nie istnieje, blokuj wysyłkę i wyślij klientowi e-mail z prośbą o zmianę.
Statusy. Statusy wracają do sklepu przez webhook albo odpytywanie API co 15–30 minut. Trzeba je zmapować na własne statusy zamówienia i zdecydować, kto wysyła powiadomienie — sklep czy przewoźnik. Jeśli obaj, klient dostanie dwa SMS-y o tym samym.
Zwroty. Etykieta zwrotna powinna powstawać z tego samego panelu i być powiązana z numerem zamówienia, inaczej paczka wraca do magazynu jako anonimowa.
Pułapka: etykieta bez nadania. Wygenerowana etykieta to nie nadana paczka. Zrób raport: zamówienia, w których od wygenerowania etykiety minęło ponad 24 godziny, a brak statusu „nadana” lub „przyjęta od nadawcy”. Zwykle to pojedyncze procenty etykiet — ktoś wydrukował i odłożył.
| Element | Skąd dane | Co ustalić przed startem |
|---|---|---|
| Generowanie etykiet | API przewoźnika (InPost, DHL, DPD, GLS) | Limit etykiet na jedno żądanie, format PDF/ZPL, dane nadawcy i domyślna waga |
| Mapa punktów | Lista punktów z API, cache w sklepie | Częstotliwość odświeżania i walidacja kodu punktu przy etykiecie |
| Statusy przesyłek | Webhook lub odpytywanie API | Mapowanie statusów i to, kto wysyła e-mail/SMS |
| Przesyłki zwrotne | API przesyłek zwrotnych przewoźnika | Czy klient dostaje etykietę zwrotną samodzielnie |
| Etykieta bez nadania | Raport po stronie sklepu | Próg czasu i osoba, która reaguje na wpis |
Ten proces możesz wysłać wykonawcy jako brief i potraktować jako listę pytań do dostawcy ERP.
Pytania do dostawcy ERP: czy jest publiczne API i jaka jest jego dokumentacja (REST, SOAP, XML)? Jakie są limity zapytań na minutę i co dzieje się po ich przekroczeniu? Czy licencja obejmuje integracje zewnętrzne i ile kosztuje dostęp dla integratora? Czy dostaniemy środowisko testowe i na jak długo? Z jakim wyprzedzeniem dostawca informuje o zmianach w API?
Testy akceptacyjne na 10 zamówieniach: opłacone online, za pobraniem, anulowane po opłacie, zwrot, produkt z drugiego magazynu, brak towaru w trakcie składania, dostawa do paczkomatu i kurierem, dwa zamówienia w tej samej minucie na ostatnią sztukę. Sprawdzasz nie tylko to, czy dokument powstał, ale czy stan w sklepie zgadza się ze stanem w ERP po godzinie.
| Etap | Czas | Wynik etapu |
|---|---|---|
| Audyt danych i uprawnień | 2–6 h | Lista kartotek, magazynów i dostępów do API |
| Mapowanie pól | 4–10 h | Dokument: pole sklepu ↔ pole ERP, zasady przy brakach |
| Środowisko testowe | 2–8 h | Kopia sklepu i testowa baza ERP |
| Wdrożenie | zależne od zakresu | Działająca synchronizacja produktów, zamówień, płatności |
| Monitoring i dokumentacja | 8–20 h | Log, alerty, mapa pól, procedura ręcznego wyzwolenia |
Koszt integracji to liczba roboczogodzin razy stawka, a nie cennik z sufitu. Żeby dało się to porównać, przyjmijmy stawkę 150 zł netto za godzinę — podstaw swoje liczby, jeśli masz inne.
Rozbicie na etapy. Audyt i mapowanie pól: 6–16 h (900–2 400 zł). Development: 20–120 h (3 000–18 000 zł). Testy akceptacyjne: 8–24 h (1 200–3 600 zł). Dokumentacja: 4–10 h (600–1 500 zł). Wsparcie powdrożeniowe w pierwszym miesiącu: 4–12 h (600–1 800 zł).
Przykładowe zakresy. Sama integracja z jednym kurierem — etykiety, statusy, protokół odbioru — to zwykle 12–24 godziny, czyli 1 800–3 600 zł. Pełna dwukierunkowa synchronizacja z ERP: produkty, stany, zamówienia, płatności, kilka przewoźników i obsługa zwrotów to 80–220 godzin, czyli 12 000–33 000 zł. Różnica dziesięciokrotna bierze się z zakresu, nie z tego, że ktoś liczy drożej za tę samą pracę.
Co podnosi koszt: brak API po stronie ERP (wtedy zostaje eksport i import plików CSV, a synchronizacja działa z opóźnieniem liczonym w godzinach), nietypowe ceny i promocje — rabaty łączone, progi, ceny per klient — wielojęzyczność i kilka walut, wiele magazynów z rezerwacjami.
Co obniża koszt: gotowe i udokumentowane API, jeden magazyn, jeden kanał sprzedaży, uporządkowane kartoteki — unikalne kody towarów, brak duplikatów, spójne jednostki miary. Sam audyt kartotek przed wyceną potrafi zdjąć kilkanaście godzin z projektu.
Pułapka przy wycenie: przyjmowanie oferty „na sztukę” bez audytu. Po audycie okazuje się, że trzeba dwa razy więcej godzin, a różnicę pokrywa klient. Do kosztu jednorazowego dodaj też opłaty stałe: licencje na integratora i abonament na opiekę techniczną, która pilnuje, czy synchronizacja w ogóle chodzi.
| Zakres | Roboczogodziny | Koszt przy 150 zł/h netto |
|---|---|---|
| Audyt i mapowanie pól | 6–16 h | 900–2 400 zł |
| Development | 20–120 h | 3 000–18 000 zł |
| Testy akceptacyjne | 8–24 h | 1 200–3 600 zł |
| Dokumentacja | 4–10 h | 600–1 500 zł |
| Wsparcie powdrożeniowe (1. miesiąc) | 4–12 h | 600–1 800 zł |
| Prosty kurier: etykiety i statusy | 12–24 h | 1 800–3 600 zł |
| Pełna synchronizacja dwukierunkowa z ERP | 80–220 h | 12 000–33 000 zł |
Zanim ogłosisz, że integracja działa, zrób cztery testy. Każdy zajmuje kwadrans i wyłapuje błędy, które inaczej zobaczy dopiero klient.
1. Duplikaty dokumentów w ERP. Wyeksportuj zamówienia ze sklepu (PrestaShop: Zamówienia → filtr daty → eksport CSV) oraz dokumenty z ERP za ten sam tydzień, np. 1–7 dnia miesiąca. Licz rekordy po numerze zamówienia ze sklepu, nie po dacie — ERP często zapisuje datę wystawienia dokumentu, a nie złożenia zamówienia. Każda różnica to sygnał. Najczęstsza przyczyna: brak klucza idempotencji. Jeśli sklep nie wysyła identyfikatora zamówienia, każda powtórka po timeoucie tworzy drugi dokument. Test: na środowisku testowym przerwij połączenie na 30 sekund w trakcie synchronizacji i sprawdź, czy w ERP powstał jeden dokument, czy dwa.
2. Rozjazd stanów magazynowych. Sprzedaj ten sam produkt z dwóch kanałów w odstępie kilku sekund — np. ręcznie z Allegro i ze sklepu. Jeśli przeszły oba zamówienia, nie masz żadnej blokady magazynowej. Rozwiązanie: magazyn buforowy (2–5 szt. na szybko rotujących pozycjach) albo rezerwacja stanu przy dodaniu do koszyka z krótkim czasem wygaśnięcia.
3. Ciche błędy uprawnień. Token OAuth wygasa, hasło do API kuriera zostaje zmienione w panelu dostawcy — synchronizacja staje, ale sklep sprzedaje dalej. Ustaw cron co 5 minut pingujący endpoint statusu. Trzy nieudane cykle pod rząd to e-mail i SMS do osoby dyżurnej. Drugi alert: zero zamówień w oknie 8:00–20:00 przez 6 godzin.
Kolejność prac i podział odpowiedzialności opisujemy w materiale o organizacji wdrożenia integracji z PrestaShop. Techniczne szczegóły API i webhooków znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Pułapka | Objaw | Test wykrywający | Alert na stałe |
|---|---|---|---|
| Duplikaty dokumentów | Dwa dokumenty z jednym numerem zamówienia | Porównanie liczby rekordów sklep–ERP za tydzień | Różnica liczby zamówień > 0 w raporcie dziennym |
| Rozjazd stanów | Sprzedaż produktu, którego nie ma | Sprzedaż tego samego produktu z dwóch kanałów w odstępie sekund | Stan ujemny w ERP |
| Brak etykiety | Zamówienie opłacone, klient czeka | Lista zamówień > 24 h bez numeru przesyłowego | Liczba pozycji na liście > 0 |
| Brak statusu zwrotnego | Paczka dostarczona, sklep nadal „w realizacji” | Porównanie statusów kuriera i sklepu po 3 dniach | Brak aktualizacji przez 48 h |
| Wygasły token | Zero nowych zamówień w ERP | Ping endpointu statusu co 5 minut | 3 nieudane cykle z rzędu |
Integracja po odbiorze nie jest skończona. Pierwszy rok to zwykle trzy–cztery zmiany po stronie dostawców i kilka sytuacji wymagających reakcji w godzinach pracy sklepu. Dlatego w umowie powinno być SLA, a nie zapis „będziemy reagować”.
Co wpisać do SLA:
Dlaczego dostawcy zmieniają API. Nowa wersja endpointu, wygaszenie starego (typowo 6–12 miesięcy wyprzedzenia), zmiana autoryzacji z klucza API na OAuth2, wymóg whitelisty IP, podpis HMAC. Praktyka: zapisz się na changelog i newsletter techniczny każdego dostawcy ERP, płatności i kuriera, a datę wygaszenia wpisz do kalendarza z 3-tygodniowym wyprzedzeniem. Aktualizacja to osobne zadanie z testem na środowisku przedprodukcyjnym, nie „dodatek przy okazji”.
Monitoring. Trzy elementy: log synchronizacji z pełnym ładunkiem (maskuj dane osobowe — RODO), alerty o błędach oraz dzienny raport zgodności zamówień sklep–ERP wysyłany mailem o stałej godzinie, np. 7:00. Rozjazd w raporcie to sygnał, który dostajesz przed pierwszym telefonem klienta. Dokumentację webhooków, na których opiera się większość takich integracji w WooCommerce, znajdziesz w dokumentacji WooCommerce.
Kopia konfiguracji i wyłącznik. Trzymaj wersjonowane pliki mapowań i reguł, a klucze API w menedżerze haseł, nie w repozytorium. Zbuduj jeden przełącznik zatrzymujący wyłącznie synchronizację: sklep dalej przyjmuje zamówienia, a niesynchronizowane pozycje trafiają do kolejki do ręcznego nadrobienia. Zakres takiej opieki opisujemy w utrzymaniu i opiece technicznej sklepów Józefów.
| Priorytet | Przykład | Czas reakcji | Czas naprawy |
|---|---|---|---|
| P1 | Brak synchronizacji zamówień, płatności nie księgują się | do 1 h w godzinach wsparcia | obejście do 4 h, usunięcie przyczyny do 1 dnia roboczego |
| P2 | Etykiety generują się z błędnym adresem, brak części statusów | do 4 h | do 1 dnia roboczego |
| P3 | Zmiana mapowania pola, nowy szablon wydruku | do 2 dni roboczych | wg harmonogramu zmian |
Józefów, Zwierzyniec, Krasnobród, Szczebrzeszyn, Zamość — to jeden region, w którym firmę odwiedza się w tym samym dniu, a nie „w przyszłym kwartale”. W praktyce wdrożeniowej przekłada się to na trzy rzeczy.
1. Rozmowa z osobą, która czyta logi. W modelu z pośrednikami zgłoszenie brzmi: „nie działa synchronizacja”. Handlowiec przekazuje je projektantowi, projektant wykonawcy, a wykonawca po dwóch dniach dopytuje o numer zamówienia i godzinę błędu. Bezpośredni kontakt skraca to do jednej wiadomości: numer zamówienia, godzina, zrzut ekranu z komunikatem. Przy błędzie blokującym 20 zamówień w dniu wysyłki te dwa dni to różnica między korektą poranną a popołudniową.
2. Odbiór wdrożenia i migracja danych przy jednym stole. Odbiór przez telefon rzadko bywa odbiorem. Na miejscu robimy test na żywo: wystawiamy zamówienie w sklepie, sprawdzamy dokument w ERP, generujemy etykietę, śledzimy status u kuriera, robimy zwrot. Przy migracji kartotek i stanów (typowo od kilkuset do kilku tysięcy pozycji) mapowanie pól — jednostka miary, stawka VAT, kod EAN, kategoria — najszybciej ustala się, gdy obie strony widzą ten sam arkusz na ekranie. W mailu wątek „jak traktujecie opakowania zbiorcze” potrafi ciągnąć się tydzień.
3. Te same godziny pracy i wspólny kalendarz dni handlowych. Sklep w Roztoczu ma inny rytm niż biuro w dużym mieście: praca od rana, sobota handlowa, sezon od maja do września, wzmożenie przed długimi weekendami. Wdrożenia i prace serwisowe planuje się poza tymi oknami — nie w środku majówki i nie w weekend z dużą imprezą plenerową. Zespół z regionu wie, kiedy nie warto dotykać produkcji, i te same godziny ma w kalendarzu.
Przykłady takich wdrożeń opisujemy przy okazji integracji z ERP, płatnościami i kurierami w Zamościu.
| Sytuacja | Zespół zdalny | Zespół z regionu |
|---|---|---|
| Zmiana mapowania pól przy migracji | kilka wymian maili, ustalenia po kilku dniach | wspólny ekran, decyzja na miejscu w trakcie spotkania |
| Awaria P1 w sobotę handlową | zgłoszenie przekazywane między handlowcem a wykonawcą | bezpośredni kontakt z osobą, która zna integrację |
| Odbiór wdrożenia | test opisany w mailu, weryfikacja bez patrzenia na dane | test na żywo: zamówienie, dokument w ERP, etykieta, status, zwrot |
Testowanie integracji bezpośrednio na produkcji, na realnych zamówieniach klientów.
Jak wykryć: W historii zamówień widzisz wpisy testowe, klienci dostają maile o zamówieniach, których nie złożyli, a stany magazynowe na chwilę się rozjeżdżają.
Jak naprawić: Przed startem przygotuj kopię sklepu na osobnym adresie i środowisko testowe ERP (najczęściej kopia bazy albo firma testowa). Na produkcję wchodzisz dopiero po testach akceptacyjnych na 10 zamówieniach.
Zamawianie „integracji z ERP” bez mapowania pól, czyli bez ustalenia, które pole w ERP odpowiada któremu polu w sklepie.
Jak wykryć: Po wdrożeniu pojawiają się duplikaty kartotek towarów, puste pola EAN, zamówienia bez dokumentu sprzedaży albo dokumenty z zerową wartością.
Jak naprawić: Zrób tabelę mapowania: SKU, nazwa, cena netto/brutto, VAT, jednostka, stan, symbol dokumentu. Każde pole musi mieć wskazane źródło i kierunek przepływu.
Synchronizacja stanów magazynowych w obie strony bez reguł nadrzędności.
Jak wykryć: Stan tego samego produktu „skacze” w ciągu dnia, magazyn i sklep pokazują różne liczby, a sprzedaż w sklepie stacjonarnym zmienia dostępność online w losowych momentach.
Jak naprawić: Ustal jeden system nadrzędny dla stanów – praktycznie zawsze jest to ERP. Sklep wysyła do ERP wyłącznie informację o rezerwacji i sprzedaży, a nie własne stany.
Brak obsługi nieudanych płatności, przez co zamówienia zostają „w zawieszeniu” i nigdy nie wracają do klienta.
Jak wykryć: Raport zamówień ze statusem „oczekiwanie na płatność” starszych niż 24 godziny. Jeśli jest ich kilkanaście w tygodniu, tracisz sprzedaż, o której nie wiesz.
Jak naprawić: Podłącz webhooki o statusie transakcji, ustaw automatyczne anulowanie po zadanym czasie i wyślij klientowi jedną wiadomość z linkiem do ponownej płatności.
Traktowanie integracji z kurierem jako wyłącznie dodania przewoźnika do listy w koszyku.
Jak wykryć: Etykiety generowane są ręcznie po jednej, pracownik przepisuje dane do panelu przewoźnika, a klient nie dostaje SMS-a z numerem przesyłki.
Jak naprawić: Zamów integrację obejmującą generowanie etykiet i protokołów odbioru zbiorczo, mapę punktów w koszyku oraz statusy przesyłek wracające automatycznie do sklepu.
Brak monitoringu po wdrożeniu i brak rejestru dostępów – integracja działa, dopóki ktoś nie zmieni hasła.
Jak wykryć: Zmiana hasła w ERP, wygaśnięcie tokenu API albo koniec licencji konektora kończy się cichym zatrzymaniem synchronizacji. Nikt tego nie zauważa, dopóki nie pojawi się problem ze stanami.
Jak naprawić: Ustal alert, który informuje o braku udanej synchronizacji przez X godzin, i prowadź rejestr dostępów: kto ma klucz API, do czego i kiedy ostatnio go rotowano.
Integracja sklepu wywala się najczęściej nie na kodzie, ale na nieustalonych zasadach. Właściciel danych, mapa pól, środowisko testowe i monitoring to cztery elementy, które decydują, czy wdrożenie będzie działało pół roku później. Zanim zapytasz o cenę, przygotuj listę kontrolną i pytania do dostawcy ERP – to skraca rozmowy i chroni przed dopłatami w trakcie. Dokumentacja powdrożeniowa to nie formalność, a najtańsze ubezpieczenie tej inwestycji.
Od inwentarza: wersje systemów, właściciel danych, dostępy do API i limity zapytań. Dopiero potem sensowne jest mapowanie pól. Jeśli zaczniesz od wyboru wtyczki, prawdopodobnie skończysz na wdrożeniu, które trzeba powtarzać.
Tak, to jedne z najczęściej spotykanych połączeń w polskich MŚP. Zwykle łączy się je przez konektor korzystający z API lub z bazy danych. Kluczowe pytanie do dostawcy brzmi: czy potrzebna jest dodatkowa licencja na integratora i czy dostępne jest środowisko testowe. Więcej o samej organizacji takiego wdrożenia piszemy tutaj: https://dropdigital.pl/integracje-z-prestashop-organizacja-wdrozenia.
Jeden prosty przepływ, na przykład stany i zamówienia z ERP do sklepu, to zwykle kilkanaście do kilkudziesięciu godzin. Pełny łańcuch: ERP, płatności i kurierzy z etykietami, mapą punktów i statusami zwrotnymi, to często ponad 100 roboczogodzin, licząc audyt, development, testy i dokumentację. Wycena bez tych czterech pozycji jest zgadywaniem.
Kompletność dokumentu w ERP, zgodność kwot i VAT, poprawny stan magazynowy po sprzedaży, działanie webhooka o płatności, wygenerowanie etykiety i protokołu odbioru, powiadomienie klienta oraz to, co się dzieje po anulowaniu i zwrocie. Każdy z tych punktów sprawdzasz na zamówieniu z płatnością udaną i na takim, które zostało odrzucone.
Raportem: zestaw numerów przesyłek pobranych z systemu przewoźnika ze statusem innym niż „nadana” po upływie ustalonego czasu, na przykład 24 godzin. Taki raport uruchamiany raz dziennie wyłapuje zarówno błędy ludzkie, jak i problemy z samym generowaniem etykiet.
Tak. Zmiany w API przewoźników i operatorów płatności, aktualizacje sklepu, rotacja haseł i kończące się licencje konektorów to typowe przyczyny cichych awarii. Monitoring i ustalony właściciel tematu kosztują mniej niż tydzień sprzedaży ze złymi stanami magazynowymi. Zakres takiej opieki opisujemy tutaj: https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-jozefow.
Jedna osoba decyzyjna, która zna procesy firmy i ma prawo zatwierdzać ustalenia, plus osoba techniczna po stronie ERP. Wdrożenie prowadzone przez pięć osób z różnymi opiniami na temat stanów magazynowych to najprostsza droga do przeciągnięcia terminu.
Jeśli chcesz przejść przez wdrożenie integracji w Józefowie bez przepalania budżetu na poprawki, napisz do nas – pomożemy ułożyć zakres, mapowanie pól i kolejność prac. Możesz też zacząć od audytu tego, co już masz.