Wybór paczkomatu w PrestaShop to nie jedno pole w koszyku, a łańcuch czterech ogniw: metoda dostawy, widget z mapą punktów, zapis kodu punktu do zamówienia i etykieta generowana przez API ShipX. Jeśli którekolwiek ogniwo wypadnie, klient zapłaci, ale paczka nie pojedzie. Ten tekst to część organizacyjna wdrożenia: najczęstsze błędy, lista kontrolna i pytania, które wracają przy każdym sklepie. Kwestie techniczne — pełny przepływ danych i konfigurację krok po kroku — rozwijamy w pozostałych sekcjach artykułu.
Wybór paczkomatu w PrestaShop to nie jeden klik, a łańcuch czterech etapów. Każde ogniwo musi zadziałać, zanim paczka pojedzie.
validateOrder() moduł musi zapisać kod do bazy. Moduły robią to różnie: przez kolumnę dodaną do ps_order_carrier albo przez własną tabelę powiązaną z id_order. Sprawdź to przed startem — bez zapisu w bazie panel nie wystawi etykiety automatycznie. Schemat tabel opisuje dokumentacja dla deweloperów PrestaShop.tracking_number.Paczkomat (locker) i punkt POP to dwa różne typy punktów. Paczkomat to skrytka — kod kończy się zwykle literą „M”. POP to punkt odbioru w sklepie, z innym formatem kodu i innymi gabarytami przesyłki. API przyjmuje osobny parametr dla każdego typu, więc moduł musi rozróżnić je już na etapie zapisu. Wysłanie kodu POP jako Paczkomatu kończy się błędem walidacji i etykieta nie powstaje.
Dlaczego kod nie może wylądować w „notatce”. Pole ps_orders.note widzi klient, nie ma żadnej walidacji, a API ShipX go nie odczyta. Efekt: ktoś wystawia etykiety ręcznie w panelu InPost. Przy 30 zamówieniach dziennie to dodatkowe 1–1,5 godziny pracy.
Kto odpowiada za co. Sklep zapisuje kod punktu do zamówienia i przekazuje dane do API. InPost generuje etykietę w ShipX i przydziela numer przesyłki. Kurier odbiera paczkę — tylko jeśli etykieta istnieje. Moduł jest pośrednikiem, a nie integracją, która robi wszystko sama.
| Etap | Co dzieje się w sklepie | Gdzie to sprawdzić |
|---|---|---|
| Metoda dostawy | Klient wybiera „Paczkomat InPost” w kroku dostawy | Wysyłka → Przewoźnicy |
| Wybór punktu | Widget zwraca kod punktu do koszyka | Krok dostawy na frontcie sklepu |
| Zapis kodu | Kod trafia do bazy przy walidacji zamówienia | ps_order_carrier lub tabela modułu |
| Etykieta | ShipX zwraca numer przesyłki dla zamówienia | Zamówienia → pole tracking_number |
Decyzję warto oprzeć na trzech liczbach: koszt wdrożenia, koszt roczny i godziny do startu.
Oficjalny moduł InPost. Darmowy, rozwijany przez InPost, publikowany w ich repozytorium i w Addons. Zawiera widget mapy, trzy metody (Paczkomat, POP, Kurier), generowanie etykiet przez ShipX i wydruk zbiorczy. Ograniczenia: przy niestandardowym checkoutcie (One Page Checkout, własny szablon, koszyk bez przeładowania) widget potrafi się nie wstrzyknąć i kod punktu nigdzie nie trafia; moduł nadpisuje szablony frontu, więc po aktualizacji PrestaShop trzeba je scalać; nie ma własnych reguł typu „darmowy Paczkomat tylko dla wybranych województw”.
Płatny moduł z marketplace. Realnie 200–800 zł netto jednorazowo, licencja zwykle na jedną domenę, często 100–300 zł rocznie za aktualizacje i wsparcie. Ryzyko pierwsze: autor przestaje rozwijać moduł i po wejściu PHP 8.3 albo nowej wersji PrestaShop nie ma kto poprawić kodu. Ryzyko drugie: kod zaszyfrowany (ionCube) — nie dopiszesz własnej reguły wysyłki.
Własny moduł. Ma sens, gdy są niestandardowe reguły wysyłki, zamówienia idą do ERP (Subiekt, Comarch, WMS), jest wielosklepowość na jednym koncie ShipX albo potrzebny jest jeden widget dla punktów kilku operatorów. Realny zakres: 40–120 godzin pracy, zależnie od liczby reguł i integracji. Zanim podejmiesz decyzję, zobacz, jak organizacja i cennik wdrożeń PrestaShop przekładają się na czas pracy przy podobnych zakresach.
| Kryterium | Oficjalny moduł InPost | Płatny moduł | Własny moduł |
|---|---|---|---|
| Koszt wdrożenia | 0 zł | 200–800 zł netto | 40–120 godzin pracy |
| Koszt roczny | 0 zł | 100–300 zł za aktualizacje i support | Utrzymanie po stronie wykonawcy |
| Czas do startu | 1–2 dni | 1–3 dni | 2–6 tygodni |
| Kontrola nad kodem | Brak, poza szablonami | Ograniczona | Pełna |
| Ryzyko po aktualizacji PrestaShop | Zależne od InPost | Zależne od autora modułu | Po Twojej stronie |
1. Konto i token. Załóż konto biznesowe w InPost (panel ShipX), podając dane firmy i NIP. W panelu, w sekcji API, wygenerujesz token organizacji — osobny dla produkcji, osobny dla środowiska testowego. Token traktuj jak hasło: nie wklejaj go do repozytorium ani do zgłoszenia, trzymaj w konfiguracji modułu.
2. Metoda dostawy w PrestaShop. Wysyłka → Przewoźnicy → nowy przewoźnik. Ustaw: nazwa „Paczkomat InPost”, strefa Polska, kraje, grupy klientów, podatek, zakres wag i cen, opóźnienie dostawy. Zrób trzy osobne metody (Paczkomat, POP, Kurier) — inaczej klient nie wybierze punktu POP, a magazyn nie rozdzieli wysyłek. Jeśli pracujesz z wykonawcą, ustal to na etapie wdrożenia PrestaShop dla firmy, a nie po uruchomieniu sklepu.
3. Podpięcie tokenu i test bez etykiety. Wklej token w konfiguracji modułu i uruchom test połączenia. Bezpieczny test: pobranie listy punktów w promieniu kilku kilometrów i walidacja przykładowego kodu punktu. Jeśli widget zwraca punkty, a walidacja przechodzi — token i komunikacja działają. Etykietę na produkcji generuj tylko na realnym zamówieniu, bo zużywa numer przesyłki i trzeba ją anulować.
Sandbox kontra produkcja. Środowisko testowe ma inny adres API i inny token. Nie sprawdzisz w nim rozliczeń, limitów produkcyjnych, realnych powiadomień do klienta ani części usług dodatkowych — ich zachowanie bywa inne niż na produkcji. Dlatego po konfiguracji zrób jedno prawdziwe zamówienie za pobraniem o niskiej wartości i przejdź całą drogę: koszyk → punkt → etykieta → odbiór przez kuriera.
| Element | Sandbox | Produkcja |
|---|---|---|
| Adres API | Osobny endpoint testowy | Endpoint produkcyjny |
| Token | Token testowy | Token organizacji |
| Etykiety | Testowe, bez opłat | Realne, z numerem i kosztem |
| Powiadomienia do klienta | Nie wysyłają się | SMS i e-mail do odbiorcy |
| Czego nie sprawdzisz | Rozliczeń, limitów, części usług dodatkowych | — |
Widget mapy paczkomatów to zewnętrzny skrypt, najczęściej ładowany z domeny operatora. Jeśli trafia do header.tpl albo do hooka displayHeader, płacisz za niego w Core Web Vitals na stronie głównej, w kategorii i na karcie produktu — a używa go wyłącznie koszyk. To najczęstszy błąd przy wdrożeniach PrestaShop.
Krok 1: sprawdź, gdzie skrypt jest dołączany. Przejrzyj motyw (header.tpl, theme.yml) oraz moduły dostawy i płatności. Jeden moduł płatności potrafi dociągać trzy zewnętrzne biblioteki na wszystkich stronach.
Krok 2: ładuj widget dopiero na kroku dostawy. Warunek: element mapy istnieje w DOM (krok wyboru dostawy), a skrypt wstrzykujesz przez Intersection Observer albo prosty test obecności kontenera. Wtedy mapa nie konkuruje o pasmo z obrazem LCP strony głównej.
Krok 3: zmierz przed i po. W PageSpeed Insights porównaj wersję mobilną koszyka i kroku zamówienia. Interesują cię dwie metryki: LCP i TBT (Total Blocking Time). Do tego raport Reduce the impact of third-party code — sprawdź, ile czasu głównego wątku zjada domena mapy. Metodykę pomiaru opisuje dokumentacja web.dev – Core Web Vitals.
Walidacja po stronie serwera. Kontroler zamówienia musi odrzucić zamówienie, gdy pole z kodem punktu jest puste lub niezgodne z formatem. Klient z wyłączonym JavaScriptem nie zobaczy mapy wcale — fallback: lista punktów filtrowana po kodzie pocztowym (zapytanie AJAX do własnej tabeli punktów), a gdy i to padnie — pole tekstowe na kod paczkomatu z walidacją długości i jasnym komunikatem o ryzyku opóźnienia. Cały mechanizm wpina się w standardowe hooki PrestaShop — o tym, jak wygląda to w praktyce przy wdrożeniach PrestaShop, piszemy w części technicznej.
Paczkomat ma trzy gabaryty skrytek. Jeśli sklep tego nie pilnuje, klient kupuje 50-centymetrowy karton „w paczkomacie”, płaci, a ty odwozisz przesyłkę z punktu. Wymiary podane niżej zweryfikuj w aktualnym cenniku operatora — zmieniają się przy modernizacji maszyn.
Przekładanie na PrestaShop:
Produkty bez danych. Waga 0 kg to najczęstsza przyczyna błędnych zamówień — system liczy zero i przepuszcza wszystko. Zrób raport z bazy: produkty aktywne z weight = 0 albo pustymi wymiarami, i uzupełnij dane przed startem. Ustawianie globalnej wagi domyślnej to proteza — każda kalkulacja będzie wtedy kłamstwem.
Koszyk mieszany. Gdy część produktów mieści się w gabarycie A, a jedna pozycja przekracza C, masz dwie drogi: podział zamówienia na dwie przesyłki (dwie etykiety, wyższy koszt, ale klient dostaje paczkomat) albo blokada paczkomatu i pokazanie kuriera. Przy koszyku 2–3 pozycji dzielenie zwykle jest tańsze niż zwrot i ponowne nadanie. Dokumentację pól produktu znajdziesz w PrestaShop Developer Documentation. Jeśli liczbę modułów do tego typu reguł chcesz wycenić przed decyzją, punkt odniesienia daje koszt utrzymania i modułów w PrestaShop.
| Gabaryt | Wymiary wewnętrzne (cm) | Suma wymiarów (cm) | Maks. waga |
|---|---|---|---|
| A | 8 × 38 × 64 | 110 | 25 kg |
| B | 19 × 38 × 64 | 121 | 25 kg |
| C | 41 × 38 × 64 | 143 | 25 kg |
Pobranie za pobraniem. Samo włączenie płatności „za pobraniem” w PrestaShop to za mało — kwota musi trafić do API ShipX w polu pobrania. Etykieta z nadrukiem pobrania różni się od zwykłej; przy błędnym mapowaniu kurier nie inkasuje pieniędzy, a towar jedzie do klienta. Limit kwoty pobrania sprawdź w aktualnym cenniku operatora przed włączeniem tej opcji w sklepie z drogimi produktami.
Etykieta zwrotna. Generujesz ją przez API razem z etykietą nadania albo osobno — klient dostaje PDF lub kod do samodzielnego nadania. Zaleta: płacisz za zwrot dopiero, gdy klient faktycznie go nada. Przy dużej liczbie zwrotów sensowny jest wariant, w którym klient generuje kod sam w aplikacji operatora.
Webhook czy odpytywanie API. Webhook daje status w kilka sekund, ale wymaga publicznego endpointu, obsługi ponowień i kolejności zdarzeń. Cron odpytujący API co 15–30 minut jest prostszy, ma opóźnienie i limity zapytań. W praktyce: webhook jako kanał główny, cron jako siatka bezpieczeństwa dla zdarzeń, które nie dotarły.
Kiedy wysyłać maile. Numer przesyłki wysyłaj przy nadaniu — klient może śledzić paczkę. Kod do otwarcia skrytki dopiero przy statusie gotowości do odbioru, w osobnej wiadomości. Jeśli wyślesz kod razem z potwierdzeniem nadania, zginie w skrzynce i klient stanie przed paczkomatem bez informacji. Obsługę takich procesów po stronie sklepu opisujemy przy wdrożeniach PrestaShop dla firm.
| Status w ShipX | Status w PrestaShop | Co robi sklep |
|---|---|---|
| created / confirmed | W przygotowaniu | Generuje etykietę |
| dispatched_by_sender / taken_by_courier | Wysłane | Mail z numerem przesyłki |
| ready_to_pickup | Gotowe do odbioru | Mail z kodem do skrytki |
| picked_up | Dostarczone | Zamyka zamówienie |
| returned_to_sender | Zwrot do nadawcy | Ręczna weryfikacja |
Siedem sytuacji wraca w niemal każdym sklepie, w którym podłączamy paczkomaty. Każda jest tania w naprawie przed startem i kosztowna po — bo wtedy klienci już zapłacili, a paczki nie jadą.
KRA010) i numeru urządzenia (format 5000-1234). Widget zwraca oba. Jeśli do pola point_code trafi numer maszyny, ShipX albo odrzuci etykietę, albo ją przyjmie i paczka pojedzie pod inny adres. Wymuszaj format po stronie serwera — trzy litery i trzy cyfry — nie tylko walidacją w JavaScripcie.Cache-Control: no-store i wyklucz go z reguł CDN.Widget z mapą punktów dociąga własne skrypty i kafle mapy. Zanim go wstawisz, sprawdź wpływ na wskaźniki Core Web Vitals mierzone na mobile — ładowanie mapy dopiero po kliknięciu „Wybierz punkt” zwykle wystarcza, żeby nie stracić pozycji w wynikach. Jeśli szukasz zespołu, który prowadzi takie wdrożenia razem z integracjami PrestaShop, przejrzyj najpierw tę listę u siebie.
Testujemy na kopii produkcyjnej: prawdziwa baza, prawdziwy token ShipX, prawdziwy koszyk — ale minimalna liczba przesyłek, żeby nie generować kosztów i nie mieszać stanów magazynowych. Cel nie brzmi „sprawdzić, czy działa”, tylko „przejść dokładnie tę samą ścieżkę co klient, zanim zrobi to pierwszy klient”.
1. Test end-to-end. Zamów produkt, wybierz paczkomat, zapłać i sprawdź trzy miejsca: kolumnę, do której moduł zapisał kod punktu (własna tabela lub pole w zamówieniu — zależnie od tego, czy integracja korzysta z hooków, czy z override'u, o czym pisze dokumentacja dla deweloperów PrestaShop), mail do klienta i mail do magazynu oraz przesyłkę w panelu ShipX. Jeśli w którymkolwiek z tych trzech miejsc dane się różnią, integracja nie jest gotowa.
2. Trzy scenariusze etykiet — gabaryt A, B i C. Wygeneruj po jednej etykiecie dla każdego gabarytu i porównaj wymiary zwracane przez API z aktualną specyfikacją InPost. Najczęstszy błąd: moduł wysyła na sztywno gabaryt A, etykieta się drukuje, a paczkomat odrzuca przesyłkę przy odbiorze.
3. Płatność za pobraniem i zwrot. Zamówienie COD ma w API dodatkowe pole — kwotę do pobrania. Sprawdź, czy kwota po promocji i koszcie dostawy zgadza się co do groszа. Potem przetestuj zwrot: czy po zmianie statusu sklep wystawia korektę i czy kod punktu nadal jest widoczny w historii zamówienia.
4. Plan wycofania w 5 minut. Zapisz procedurę przed startem: dezaktywacja przewoźnika w Wysyłka > Przewoźnicy, wyczyszczenie cache w Parametry zaawansowane > Wydajność, purge CDN. Wyłączony przewoźnik znika z koszyka, ale istniejące zamówienia zachowują dane — to najbezpieczniejszy sposób reakcji na awarię w trakcie promocji.
| Test | Co potwierdza | Kryterium zaliczenia |
|---|---|---|
| End-to-end | Spójność kodu punktu w bazie, mailach i ShipX | Ten sam kod w trzech miejscach, etykieta wygenerowana |
| Gabaryty A/B/C | Poprawne mapowanie wymiarów koszyka na etykietę | Trzy etykiety z różnymi wymiarami, żadna nie odrzucona |
| Pobranie i zwrot | Kwota COD i obsługa korekty | Kwota zgodna co do grosza, korekta wystawiona |
| Wycofanie | Czas reakcji na awarię | Przewoźnik ukryty w koszyku w maks. 5 minut |
Poniższe widełki to zakresy z naszych wdrożeń, nie oferta. Cena zależy głównie od tego, czy sklep ma nietypowe procesy: kilka magazynów, własny WMS, faktury zbiorcze, dostawy łączone.
Koszt utrzymania w skali roku. Aktualizacje PrestaShop to zwykle jedno–dwa wydania minor rocznie, do tego zmiany po stronie API InPost (nowe wersje ShipX, zmiany autoryzacji, rotacja tokenów) i testy po każdej aktualizacji. Realistycznie 6–20 h pracy rocznie plus licencja. To pozycja, o której zapominają wszyscy, którzy liczą tylko wdrożenie — pokazuje to zresztą analiza realnych kosztów PrestaShop.
Kiedy własny moduł się zwraca. Policz koszt ręcznej obsługi jednego zamówienia: korekta kodu punktu, ponowne wystawienie etykiety, wyjaśnienie z klientem — w minutach razy stawka godzinowa. Jeśli schodzi na to 15–20 h miesięcznie, a własny moduł wyceniono na 100 h, zwrot przychodzi w ok. 5–7 miesięcy, czyli poniżej progu 12 miesięcy. Jeśli ręczna obsługa zajmuje 2 h miesięcznie, gotowy moduł wygrywa zawsze.
Opieka po wdrożeniu. U nas wygląda to tak: monitorujemy odsetek nieudanych etykiet i alertujemy, gdy przekroczy 2%, reagujemy na komunikaty InPost o zmianach w API i wykonujemy testy po aktualizacjach PrestaShop. Zakres i stawki opisuje cennik wdrożeń i migracji PrestaShop.
| Ścieżka | Nakład pracy | Kiedy wybrać | Główne ryzyko |
|---|---|---|---|
| Gotowy moduł | 3–8 h + 4–10 h poprawek | Do ok. 300 zamówień miesięcznie, standardowy proces | Brak wsparcia dla nietypowych reguł dostawy |
| Modyfikacja modułu | 15–40 h | Paczkomat i kurier w jednej metodzie, własne gabaryty | Rozjazd z aktualizacjami modułu po zmianach w API |
| Własny moduł | 60–140 h | 15–20 h ręcznej obsługi miesięcznie lub nietypowy WMS | Utrzymanie wyłącznie po stronie jednego wykonawcy |
Kod paczkomatu ląduje w polu „notatka do zamówienia” albo w wiadomości e-mail od klienta, zamiast w polu zamówienia czytanym przez generator etykiet.
Jak wykryć: Otwórz kilka zamówień z paczkomatem w panelu i w eksporcie CSV. Jeśli kod punktu widzisz tylko w komentarzu klienta albo w treści maila, a nie w osobnym polu — to ten błąd.
Jak naprawić: Zapisz kod punktu w polu zamówienia (dodatkowe pole lub pole przewoźnika w zamówieniu) i podłącz to pole jako źródło danych dla generatora etykiet. Notatka ma zostać notatką.
Skrypt mapy paczkomatów ładowany globalnie w nagłówku szablonu, na każdej podstronie sklepu.
Jak wykryć: W PageSpeed Insights sprawdź, czy skrypt zewnętrznego widgetu pojawia się w żądaniach strony głównej, kategorii i karty produktu. Jeśli tak — ładuje się wszędzie, choć potrzebny jest raz.
Jak naprawić: Ładuj widget dopiero na kroku wyboru dostawy, najlepiej przez lazy load / Intersection Observer, po interakcji klienta. Zmierz LCP i TBT przed zmianą i po niej, nie „na oko”.
Brak walidacji po stronie serwera: zamówienie można złożyć bez wybranego punktu albo przy wyłączonym JavaScript.
Jak wykryć: Złóż testowe zamówienie z wyłączonym JS w przeglądarce i drugie bez kliknięcia w punkt na mapie. Jeśli przechodzi do płatności — walidacji nie ma.
Jak naprawić: Dodaj sprawdzenie po stronie serwera w procesie składania zamówienia: brak kodu punktu dla metody paczkomatowej = blokada z komunikatem. Walidacja w JS to wygoda, nie zabezpieczenie.
Paczkomaty (locker) i punkty odbioru (POP) wrzucone do jednej metody dostawy i jednego pola kodu.
Jak wykryć: Sprawdź w panelu InPost, czy wszystkie przesyłki mają typ zgodny z tym, co wybrał klient, oraz czy w sklepie da się rozróżnić locker od POP w danych zamówienia.
Jak naprawić: Rozdziel typy punktów na poziomie danych: osobny typ w zapisie zamówienia i poprawne mapowanie przy generowaniu etykiety. Dwa typy punktów to dwa różne kody i dwie różne etykiety.
Produkty bez uzupełnionej wagi i wymiarów, a cennik wysyłki niepowiązany z gabarytem.
Jak wykryć: Zrób eksport produktów i policz, ile pozycji ma puste albo domyślne pole wagi. Potem spróbuj złożyć koszyk z największym produktem do paczkomatu o najmniejszym gabarycie.
Jak naprawić: Uzupełnij wagi i wymiary, a dla produktów bez danych ustaw wartości domyślne z zapasem. Dodaj regułę blokującą wybór paczkomatu, gdy koszyk przekracza największy obsługiwany gabaryt.
Testy wykonywane od razu na produkcji, bez środowiska testowego i bez sprawdzenia połączenia przed pierwszą prawdziwą etykietą.
Jak wykryć: Zapytaj wykonawcę, czy istnieje osobny token i środowisko testowe oraz czy połączenie z API było sprawdzane bez generowania etykiety. Brak odpowiedzi to odpowiedź.
Jak naprawić: Trzymaj dwa zestawy danych: sandbox i produkcję. Przed startem sprawdź samo połączenie i autoryzację, potem wygeneruj jedną etykietę testową na własnej przesyłce.
Wdrożenie paczkomatów w PrestaShop wywala się najczęściej nie na API, a na organizacji: kod punktu w notatce zamiast w danych zamówienia, mapa ładowana globalnie, brak walidacji po stronie serwera i produkty bez wagi. Każdy z tych błędów jest tani do naprawy przed startem i drogi po nim. Przejdź listę kontrolną punkt po punkcie i zapisz wyniki pomiarów przed wdrożeniem mapy. Wtedy rozmowa z wykonawcą dotyczy zakresu, a nie domysłów.
Tak, ale to nie znaczy „za darmo”. Oficjalny moduł InPost jest zwykle punktem startu, a koszt pojawia się przy niestandardowym checkoucie, regułach gabarytowych albo integracji z ERP. Płatny moduł z marketplace kupujesz szybciej, ale płacisz co roku i zależysz od tempa aktualizacji dostawcy. Własny moduł to największy koszt początkowy i najmniejsza zależność od innych.
Kod punktu musi trafić do danych zamówienia powiązanych z przewoźnikiem — czyli do rekordu przewoźnika w zamówieniu, a nie do notatki klienta. Notatka bywa edytowalna, nie ma struktury i nie nadaje się jako źródło dla generatora etykiet. Jeśli w panelu nie widzisz kodu jako osobnego pola, pierwszy problem pojawi się przy pierwszej wysyłce, a nie przy testach.
Spowolni, jeśli załadujesz ją na każdej podstronie. Zewnętrzny skrypt widgetu potrafi podnieść czas blokowania wątku i pogorszyć LCP. Rozwiązanie jest proste: ładuj mapę dopiero na kroku wyboru dostawy, po interakcji klienta. Zmierz LCP, TBT i INP przed wdrożeniem oraz po nim — inaczej nie wiesz, czy problem istnieje.
Poproś o środowisko testowe i osobny token. Na nim weryfikujesz autoryzację, wyszukiwanie punktów i przebieg zamówienia. Uwaga: część zachowań API bywa inna niż na produkcji, więc przed startem wygeneruj jedną etykietę na własnej, realnej przesyłce i prześledź ją do końca.
Jeśli walidacja działa tylko w przeglądarce, zamówienie przejdzie bez kodu punktu i utknie w obsłudze. Dlatego sprawdzenie musi być po stronie serwera, w procesie składania zamówienia. Przy wyłączonym JS zadziała wtedy lista punktów z wyszukiwarką po kodzie pocztowym jako fallback.
Nie ma jednej liczby, która będzie prawdziwa dla każdego sklepu. Przy gotowym module i standardowym checkoucie to kwestia dni roboczych na konfigurację i testy. Własny moduł z regułami gabarytowymi, wielosklepowością albo integracją z ERP to tygodnie. Zapytaj wykonawcę o zakres i etapy, a nie o sam termin.
Technicznie tak, ale w danych zamówienia musisz rozróżnić typ punktu. Locker i punkt odbioru to dwa różne typy punktów i dwa różne kody. Jeśli wszystko wpada do jednego pola bez typu, prędzej czy później wyślesz etykietę niezgodną z tym, co wybrał klient.
Jeśli chcesz przejść przez tę listę z kimś, kto robi to na co dzień, zajrzyj na naszą stronę o wdrożeniach PrestaShop i napisz, na jakim etapie jest Twój sklep. Powiemy wprost, co da się zrobić gotowym modułem, a gdzie potrzebny jest własny kod.