Teksty o integracjach zewnętrznych w PrestaShop wyglądają zwykle tak samo: lista przewoźników, lista porównywarek, lista hurtowni. Taka lista nie odpowiada na żadne pytanie, które pada w realnym projekcie, bo pytanie brzmi nie „z czym się da”, tylko „co dokładnie trzeba rozstrzygnąć, zanim ktokolwiek napisze linijkę kodu”.
Ten artykuł jest o trzech obszarach, w których integracje zewnętrzne najczęściej decydują o tym, czy sklep da się skalować: wysyłce, feedach produktowych i hurtowniach. Płatności, live chat i systemy opinii pomijamy, bo mają u nas własne materiały, a ich mechanika jest zupełnie inna niż tych trzech.
Kurierzy i brokerzy wysyłki
Rozmowa o integracji kurierskiej zwykle zaczyna się od pytania, z którym przewoźnikiem się łączymy. To złe pierwsze pytanie. Właściwe brzmi: kto tworzy przesyłkę i generuje etykietę.
Trzy układy właścicielskie
Od odpowiedzi na to pytanie zależy cały zakres prac po stronie sklepu.
| Układ | Kto tworzy przesyłkę | Co robi sklep | Gdzie się łamie |
|---|---|---|---|
| Sklep jako nadawca | sklep, przez integrację z przewoźnikiem albo brokerem | zbiera dane adresowe, tworzy paczkę, drukuje etykietę, zapisuje numer do śledzenia | wersje modułu przewoźnika, walidacja adresu, gabaryty i waga |
| System firmowy jako nadawca | system magazynowy albo ERP | wystawia zamówienie i odbiera numer listu z powrotem | kanał zwrotny numeru, opóźnienie, brak klucza powiązania |
| Broker wysyłki jako nadawca | zewnętrzna platforma wysyłkowa | przekazuje zamówienie i odbiera numer oraz statusy | zakres danych przyjmowany przez brokera, obsługa wielu sklepów w jednej instancji |
Numer listu przewozowego to osobny strumień danych
To rozstrzygnięcie, które w wycenach bywa pomijane, a potrafi zająć więcej czasu niż samo połączenie z przewoźnikiem.
W układzie, w którym przesyłkę tworzy system firmowy, numer listu nie wraca w odpowiedzi na wywołanie, które wysłało zamówienie. Wraca osobnym kanałem, zwykle z opóźnieniem. Bywa nim plik wymiany odkładany w uzgodnionym katalogu albo osobne wywołanie po stronie sklepu.
Przy takim kanale trzeba podjąć trzy decyzje, a każda z nich ma konsekwencje operacyjne:
- Jeden zapis na zamówienie czy jeden zbiorczy na dobę. Zapis na zamówienie daje aktualność i prostą obsługę błędów. Zbiorczy, odkładany raz dziennie wieczorem, jest tańszy po stronie systemu firmowego, ale opóźnia informację dla klienta o kilka godzin.
- Kto i kiedy czyści stare wpisy. Bez tej odpowiedzi plik rośnie, a po kilku miesiącach samo jego przetworzenie przy każdym przebiegu staje się kosztem. Jeśli ma być czyszczony cyklicznie, każdy wpis potrzebuje daty dodania, bo inaczej nie da się bezpiecznie ustalić, co już zostało przetworzone.
- Co jest kluczem powiązania. System firmowy musi trzymać numer zamówienia ze sklepu jako numer zewnętrzny. To jedyny sposób, żeby numer listu trafił do właściwego zamówienia.
Wniosek, który zmienia projekt statusów i szablonów wiadomości, nie tylko integrację: numer do śledzenia jest daną asynchroniczną, więc sklep musi umieć obsłużyć zamówienie, które jest już wysłane, ale numeru jeszcze nie ma.
Choreografia statusów
Sekwencja, która sprawdza się w projektach z systemem firmowym po drugiej stronie, wygląda tak:
- Do systemu realizującego wysyłkę wychodzą wyłącznie zamówienia opłacone. Zamówienia z przelewem tradycyjnym czekają po stronie sklepu.
- Po przekazaniu zamówienia sklep ustawia status mówiący, że realizacja ruszyła. Od tego momentu sklep nie jest już właścicielem procesu.
- Numer listu wraca i sklep ustawia status końcowy. To ostatni status, jaki sklep zna. Dalsze etapy życia przesyłki są poza jego widokiem.
- Klient dostaje nazwę przewoźnika i numer do śledzenia.
Warta uwagi jest decyzja z punktu czwartego: czy podajemy klientowi gotowy link do śledzenia, czy sam numer. Link bywa niestabilny i wymaga utrzymania, a błędny generuje zgłoszenia do obsługi. Sam numer jest odporniejszy, choć mniej wygodny.
Etykieta zbiorcza to osobna funkcja
Integracja z przewoźnikiem odpowiada za utworzenie przesyłki. Wydrukowanie kilkuset listów przewozowych z listy zamówień to druga, niezależna funkcja. Sklep wysyłający paczki partiami raz dziennie potrzebuje obu.
To dobry przykład na tezę, która wraca w całym tym artykule: integracja kurierska nie kończy się w momencie, w którym dane dolatują do przewoźnika. Reszta pracy jest w panelu, na liście zamówień i w pakowni.
Dostępność przewoźnika jest regułą biznesową, nie ustawieniem
Tu integracja kurierska przestaje być integracją i staje się projektem. Poniższe wymagania są typowe, a żadnego z nich standardowa konfiguracja PrestaShop nie obsłuży bez dodatkowego kodu:
- Zawężenie metod dostawy do kategorii produktu, bo asortyment regulowany nie może wyjść dowolnym kanałem.
- Ukrycie przewoźników, gdy koszyk zawiera wyłącznie produkty wirtualne. Klasyczny błąd wdrożenia to klient płacący za dostawę pliku.
- Koszt dostawy zależny jednocześnie od wagi i od wartości zamówienia. PrestaShop natywnie każe wybrać jedno kryterium, więc jednoczesne uwzględnienie obu wymaga własnego przelicznika.
- Koszt i próg darmowej dostawy zależne od kodu pocztowego, z listą kodów wczytywaną z pliku. Sklepu z własnym transportem miejskim nie da się opisać tabelą wag.
- Dodatkowe pole przy metodzie dostawy, którego wartość klient podaje potem kurierowi przy odbiorze.
- Podział zamówienia według dostępności. Gdy w koszyku są produkty dostępne i niedostępne, klient wybiera, czy sklep rozbije to na dwa zamówienia realizowane osobno, czy poczeka na skompletowanie całości. Ta jedna decyzja dotyka wysyłki, magazynu, faktur i integracji naraz.
Punkt odbioru ma dwa niezależne warianty
W rozmowach handlowych mylone są dwa zupełnie różne mechanizmy.
Punkt przewoźnika wybierany jest z sieci automatów i punktów partnerskich. Wybór dzieje się w komponencie dostarczonym przez przewoźnika, a sklep musi go przenieść do zamówienia i utrzymać przy późniejszej edycji zamówienia w panelu.
Punkt własny sklepu, czyli odbiór w salonie, to wybór z listy lokalizacji sklepu, a nie z zewnętrznej sieci. Wiąże się ze stanem magazynowym tej konkretnej lokalizacji, nie magazynu centralnego, i pociąga za sobą obsługę zwrotów oraz reklamacji przyjmowanych na miejscu.
Pierwszy wariant to integracja z przewoźnikiem. Drugi to integracja z magazynem. Teksty branżowe piszą o automatach paczkowych i pomijają, że odbiór własny jest zupełnie innym projektem.
Koszt dostawy trzeba pokazać przed koszykiem
Zestaw funkcji, który w projektach wraca najczęściej i który cały wylicza się z tej samej konfiguracji przewoźników:
- koszt dostawy widoczny na karcie produktu, z uwzględnieniem wskazanych przewoźników,
- informacja, ile brakuje do progu darmowej dostawy, w koszyku i na karcie produktu,
- próg darmowej dostawy liczony osobno dla zamówień od danego producenta,
- licznik wysyłki, który do określonej godziny pokazuje czas pozostały na złożenie zamówienia z wysyłką tego samego dnia, a po tej godzinie przełącza się na najbliższy dzień roboczy,
- doliczanie opakowania do koszyka w zależności od wybranej metody dostawy.
Rozjazd między obietnicą na karcie produktu a ceną w koszyku jest typowym skutkiem obejścia tej konfiguracji zamiast jej rozbudowania.
Wersje modułów przewoźnika jako osobna kategoria awarii
Zdarza się, że moduł przewoźnika przestaje generować przesyłki po aktualizacji. Sklep instaluje kolejne wersje, czasem kilka w trakcie jednego zgłoszenia, a problem nie ustępuje. Bywa też odwrotnie: nowa wersja wtyczki dostawcy psuje działającą integrację przy niezmienionym sklepie.
Praktyczna konsekwencja jest taka, że integracja z przewoźnikiem jest zależnością zewnętrzną o własnym cyklu wydawniczym, nad którym sklep nie ma kontroli. Stąd dwie zasady. Każde zgłoszenie w tym obszarze opisuje się trójką wersji: wersja PrestaShop, wersja PHP, wersja modułu, bo bez nich nie da się go analizować. A przed aktualizacją modułu przewoźnika trzeba mieć środowisko, na którym da się wygenerować testową przesyłkę.
Dwie rzeczy, o których nie myśli się przy wycenie
Dostawa jako pozycja zamówienia. System księgowy albo ERP zwykle oczekuje, że koszt dostawy będzie pozycją na liście pozycji, a nie osobnym polem. Przy złej implementacji rozjeżdżają się podsumowania i podatek.
Transport bez ceny w chwili zamówienia. Przy produktach wielkogabarytowych klient składa zamówienie, obsługa dopiero potem podaje wycenę transportu, a klient ją akceptuje i dopłaca. To wywraca standardowy przepływ, bo zamówienie istnieje przed poznaniem swojej wartości końcowej.
Feedy produktowe
Drugi obszar rządzi się zupełnie inną logiką, choć powierzchownie wygląda prościej.
Feedów jest tyle, ilu odbiorców
Nie ma czegoś takiego jak uniwersalny generator feedu. W praktyce powstają osobne generatory dla poszczególnych odbiorców, bo każdy odbiorca ma własny kontrakt danych: inny format, inny zestaw pól obowiązkowych, inną taksonomię kategorii, inne wymagania co do identyfikatora produktu.
Feed nie jest eksportem katalogu. Jest tłumaczeniem katalogu na cudzy słownik. Konsekwencja dla budżetu jest taka, że koszt nie skaluje się z liczbą produktów, tylko z liczbą kanałów.
Harmonogram, czyli kto kogo pyta i jak często
Feed pracuje w cyklu i sam cykl jest osobnym elementem konfiguracji. Trzy pytania do rozstrzygnięcia w analizie:
- Czy plik jest generowany na żądanie odbiorcy, czy odkładany na serwerze i tylko pobierany?
- Co się dzieje, gdy generowanie trwa dłużej niż odstęp między przebiegami?
- Czy odbiorca dostaje pełny katalog za każdym razem, czy tylko zmiany?
Ostatnie pytanie jest tym samym problemem, który wraca przy synchronizacji stanów: przy dużym katalogu przebieg bez podziału na partie po prostu nie przechodzi. Wydajnościową stronę tego zagadnienia opisujemy osobno w materiale o kosztownych awariach w szczycie sprzedażowym.
Mapowanie kategorii i identyfikator produktu
Dwa miejsca, w których feedy wywracają się najczęściej.
Taksonomia odbiorcy nie jest taksonomią sklepu. Produkt musi jednocześnie siedzieć w drzewie wygodnym dla klienta sklepu i w drzewie wymaganym przez odbiorcę feedu. Rozwiązaniem jest mechanizm mapowania, który przy dodaniu produktu do jednej kategorii automatycznie dopisuje go do kategorii zmapowanej.
Identyfikator musi być unikalny i musi istnieć. Powiązanie trzyma się na kodzie EAN albo na referencji, więc warto wymusić ich unikalność na poziomie pojedynczego wariantu. Bez tego zdarza się, że eksport przestaje działać, bo klucz mapowania jest w większości katalogu niewypełniony, mimo że integracja przeszła testy na próbce. Testy przechodzą, bo do testów wybiera się produkty kompletne.
Stąd wniosek, który warto powiedzieć wprost: feed jest tylko tak dobry, jak dane w katalogu. Projekt feedowy zaczyna się od porządkowania katalogu, nie od pisania generatora.
Cena i dostępność w feedzie kontra cena w sklepie
Rozjazd ceny między kanałami prawie nigdy nie jest błędem feedu. Jest skutkiem braku decyzji, który cennik jest źródłem prawdy dla którego kanału. Cztery sytuacje, w których to wychodzi:
- Sklep ma przeliczniki cen osobne dla każdego sklepu w instalacji wielosklepowej. Feed generowany bez świadomości kontekstu wyśle cenę z niewłaściwego przelicznika.
- Ceny są przypisane do grup klientów. Feed publiczny musi wiedzieć, którą grupę reprezentuje, bo inaczej pokaże cenę hurtową w kanale konsumenckim albo odwrotnie.
- Ceny w walutach obcych bywają osobnym cennikiem, a nie przeliczeniem kursu. Kanał zagraniczny potrzebuje ceny z cennika, nie z kalkulatora.
- Gdy dwa systemy liczą cenę samodzielnie, podsumowania zamówień przestają się zgadzać. Rozstrzygnięcie, które zwykle działa: przekazujemy cenę netto i osobno wartość podatku.
Konfiguracja wielosklepowa cicho psuje feedy
To teza, której nie ma w tekstach branżowych, a która kosztuje najwięcej, bo nie daje żadnego sygnału błędu.
Integracja kanałowa, która nie jest świadoma wielu sklepów w jednej instancji, będzie działać w sklepie podstawowym i cicho gubić dane w pozostałych. Typowy objaw: zamówienia złożone w obcojęzycznej wersji sklepu w ogóle nie docierają do zewnętrznego integratora, przy pozornie identycznej konfiguracji. Nic nie zwraca błędu, zamówienia po prostu nie pojawiają się tam, gdzie powinny.
Dlatego przy każdym module, który ma pracować w takiej instalacji, sprawdza się cztery rzeczy osobno: czy jest świadomy kontekstu sklepu w konfiguracji, w odczycie, w zapisie i w samym przetwarzaniu. Szerzej o konsekwencjach takiej architektury piszemy w tekście o multistore w PrestaShop.
Dane strukturalne to nie feed
Warto rozgraniczyć dwa mechanizmy mylone w rozmowach o widoczności produktów. Dane strukturalne opisują zawartość strony dla wyszukiwarki i żyją w kodzie strony. Feed produktowy to plik wysyłany do konkretnego odbiorcy, według jego kontraktu. To dwa różne mechanizmy o dwóch różnych celach.
Marketplace to nie porównywarka
Rozróżnienie istotne merytorycznie i kosztowo, mimo że handlowo obie rzeczy brzmią podobnie.
Porównywarka dostaje feed i odsyła ruch do sklepu. Integracja jest jednokierunkowa i kończy się na pliku.
Marketplace przyjmuje zamówienie u siebie i to zamówienie musi wrócić do sklepu. Pociąga to za sobą konsekwencje, których przy porównywarce nie ma: zamówienie przychodzi już opłacone, więc nie może przejść przez standardową bramkę płatności i potrzebuje dedykowanej metody. Do tego dochodzą statusy i rezerwacja stanu magazynowego.
Integracja z marketplace dotyka statusów, płatności i magazynu, a nie tylko katalogu. Dlatego wycena podłączenia marketplace i wystawienia feedu do porównywarki to dwie różne rozmowy.
Hurtownie i dropshipping
Nie ma standardu, jest osobny projekt na każdą hurtownię
Integracje z hurtowniami realizuje się jako osobne mechanizmy importu dla poszczególnych dostawców, bo nie istnieje standard formatu ani zakresu danych po stronie hurtowni.
Przy hurtowni pytanie nie brzmi więc „czy to się da zintegrować”, tylko „co ta konkretna hurtownia udostępnia i w jakiej formie”. Odpowiedź na to pytanie wyznacza wycenę, a nie liczba produktów w katalogu.
Czego z hurtowni brakuje najczęściej
Lista danych, które trzeba wynegocjować, bo pierwsza wersja integracji ich nie ma:
- Termin realizacji i dane wysyłkowe. Sklep sprzedaje, a nie wie, kiedy dostawca wyśle. To brak, który wychodzi już po uruchomieniu importu produktów i zamówień.
- Informacja o tym, co się zmieniło. Bez metody zwracającej wyłącznie zmienione ceny każdy przebieg pobiera pełny katalog.
- Jakość danych wejściowych. Zastrzeżenia do poprawności danych produktowych, stanów i cen otrzymywanych z interfejsu dostawcy to nie jest błąd integracji, tylko stan wejścia, z którym trzeba coś zrobić.
Integracja z hurtownią zaczyna się od sprawdzenia, co hurtownia potrafi wysłać, a kończy na liście rzeczy, których nie wyśle nigdy. Ta druga lista jest ważniejsza, bo wyznacza, co sklep musi uzupełniać ręcznie.
Stan magazynowy nie jest liczbą
Najczęstsze pułapki w tym obszarze:
- Stan przychodzi jako tekst z jednostką, a nie jako liczba. Przy prostym parsowaniu kończy się to wyzerowaniem dostępności całego asortymentu albo cichym zapisem błędnej wartości.
- Stan na wariant kontra stan na produkt. Czy limit jest globalny dla produktu, czy każdy wariant ma własny, i czy warianty u dostawcy istnieją jako osobne produkty. To pytanie trzeba zadać przed startem, nie w trakcie.
- Limit ilości na jednego klienta. Osobna dana obok stanu magazynowego. Reguła jest przy tym niebanalna: klient może zamówić maksymalnie tę liczbę, chyba że dostępnych jest mniej sztuk, wtedy kupuje tyle, ile jest. Limit dla produktów w cenie promocyjnej bywa osobnym mechanizmem, wymagającym własnej implementacji.
- Wiele źródeł stanu naraz. Magazyn centralny, sklepy stacjonarne, hurtownia. Pytanie, który magazyn jest źródłem prawdy dla którego kanału sprzedaży, jest pytaniem projektowym, nie technicznym.
Automatyka, która ratuje katalog zasilany z zewnątrz
Dwa mechanizmy, które przy katalogu zasilanym z hurtowni są standardem, a nie dodatkiem.
Automatyczne włączanie i wyłączanie produktu w zależności od stanu, wraz z przenoszeniem go między kategoriami. Bez tego katalog zapełnia się widocznymi produktami, których nie da się kupić.
Oznaczanie produktów wycofanych datą wycofania, po której produkt sam się wyłącza, z odróżnieniem produktów aktywnych od wyłączonych właśnie z tego powodu. To rozwiązuje problem, którego sama integracja nie rozwiąże: hurtownia przestaje przysyłać produkt, a sklep nie wie, czy to chwilowy brak stanu, czy koniec oferty.
Dropshipping jest trybem zamówienia, nie modelem biznesowym
Włączenie dropshippingu w zamówieniu oznacza równocześnie trzy rzeczy: możliwość podania jednorazowego adresu dostawy innego niż adres z konta klienta, wskazanie daty realizacji oraz zawężenie dostępnych metod dostawy i płatności do tych, które w tym trybie mają sens.
Dropshipping nie jest więc przełącznikiem w konfiguracji. Jest osobnym torem zamówienia, który dotyka adresów, terminów, przewoźników i płatności naraz. To najkrótsze wyjaśnienie, dlaczego prośba o dodanie dropshippingu wycenia się jak projekt, a nie jak ustawienie.
Komunikat dostępności jest częścią integracji
Scenariusz testowy dla stanów magazynowych obejmuje nie tylko liczby, ale i komunikaty widziane przez klienta: produkt dostępny, brak w magazynie, brak z możliwością zamówienia, prezentowanie daty dostępności. Integracja stanów nie kończy się w bazie danych, tylko na karcie produktu.
Cztery pytania wspólne dla wszystkich trzech obszarów
Przy kurierze, przy feedzie i przy hurtowni wracają dokładnie te same rozstrzygnięcia. Jeśli z tego tekstu warto zapamiętać jedną rzecz, to tę listę.
- Co jest kluczem powiązania i czy jest wypełniony. Każda encja potrzebuje identyfikatora po obu stronach, a powiązanie trzyma się na numerze zewnętrznym. Zanim wycenisz integrację, policz, ile pozycji w katalogu ma ten klucz faktycznie wypełniony. To zapytanie do bazy na kilka minut, a wynik potrafi zmienić harmonogram projektu.
- Który system jest źródłem prawdy dla której danej. Osobno dla ceny, osobno dla stanu, osobno dla kartoteki klienta, osobno dla statusu przesyłki. Brak tej decyzji nie objawia się od razu, tylko przy pierwszym konflikcie.
- Co się dzieje przy błędzie. To trzy rozstrzygnięcia, nie jedno: moment wywołania, zachowanie przy sukcesie i zachowanie przy porażce. Ponowienie z zapisem w logu nie jest odpowiedzią, bo nie mówi, ile razy ponawiać, co zrobić z danymi po prostu błędnymi i kto się o tym dowiaduje.
- Czy integracja jest świadoma wielu sklepów. Jeśli instalacja obsługuje więcej niż jeden sklep, każdy moduł trzeba sprawdzić osobno pod tym kątem, bo brak tej świadomości nie zwraca błędu.
Integracje mają swój odbiór
Ostatnia rzecz, którą warto ustawić w harmonogramie jako osobny punkt, a nie podpunkt odbioru sklepu.
Weryfikacja feedów produktowych, sprawdzenie synchronizacji z systemami zewnętrznymi i hurtowniami, test zadań cyklicznych oraz kontrola zgodności stanów magazynowych to osobne kryteria odbioru. Wykonuje się je na środowisku przedprodukcyjnym, na sucho, przed puszczeniem ruchu. Sprawdzenie logów po tych testach jest częścią odbioru: brak wpisów jest tak samo podejrzany jak ich nadmiar.
Pełny zakres naszych prac w tym obszarze opisuje strona integracji PrestaShop.
