01
Pobranie zamówienia
BaseLinker odbiera zamówienie z marketplace wraz z pozycjami, ilościami i danymi wysyłki.
BaseLinker · Shoper · marketplace
Sprzedajesz na marketplace i w Shoperze — stan musi być jeden
Gdy ten sam towar leży na Allegro, Amazonie i w sklepie, każdy kanał próbuje sprzedać pełną dostępność. Integracja BaseLinker–Shoper ma sprawić, że sprzedaż w jednym miejscu natychmiast zmniejsza dostępność we wszystkich pozostałych — i że nikt nie nadpisuje stanu w drugą stronę.
ALLEGROzamówienie #A-8821−1 szt.
BLmatch po SKU + EANok
STOCK12 → 11zapis
SHOPERPUT /products/stock200
STATUSwysłane + list przewozowypowrót
Jeden kierunek zapisu na pole, log przy każdej zmianie i możliwość odtworzenia, kto ostatni ruszył stan.
Ścieżka zamówienia
Co dzieje się w ciągu minuty po zakupie na Allegro
To jest realna sekwencja, którą projektujemy i którą potem widać w logach. Każdy krok ma własny warunek poprawności — jeżeli któryś zawiedzie, wiadomo dokładnie który.
02
Dopasowanie pozycji
Każda pozycja szuka swojego odpowiednika po SKU, a gdy go brak — po EAN. Brak dopasowania trafia do wyjątków, nie do cichego pominięcia.
03
Zejście ze stanu
Stan spada w systemie, który jest jego źródłem prawdy. Pozostałe kanały dostają wynik, a nie własne wyliczenie.
04
Zapis do Shopera
Nowa dostępność idzie przez Shoper API paczką, z ponowieniem przy błędzie sieci i zapisem odpowiedzi w logu.
05
Powrót statusu
Zmiana statusu i numer przewozowy wracają do kanału sprzedaży, żeby kupujący nie pytał o przesyłkę mailem.
Podział odpowiedzialności
Który system rządzi którym polem
Tabelę wypełniamy razem z klientem przed pierwszą linijką kodu. Bez niej integracja działa do pierwszej kolizji, a potem zaczyna się szukanie, „dlaczego cena wróciła".
| Dane | Źródło prawdy | Kierunek | Częstotliwość |
|---|---|---|---|
| Karta produktu, opis, zdjęcia | Shoper | Shoper → BaseLinker | przy zmianie |
| Stan magazynowy | BaseLinker | BaseLinker → Shoper | po każdym zamówieniu |
| Cena detaliczna w sklepie | Shoper | bez synchronizacji | — |
| Cena na marketplace | BaseLinker | bez synchronizacji | — |
| Zamówienia z marketplace | BaseLinker | BaseLinker → Shoper (opcjonalnie) | na zdarzenie |
| Statusy i numer przewozowy | BaseLinker | BaseLinker → kanał sprzedaży | na zdarzenie |
Rozdzielenie ceny detalicznej od marketplace’owej jest celowe: prowizje i strategia cenowa są tam inne, a próba trzymania jednej ceny w obu miejscach kończy się ręcznym poprawianiem po każdej promocji.
Typowe awarie tej pary
Cztery rzeczy, które psują się właśnie tutaj
Wariant bez własnego SKU
Rozmiar w Shoperze dzieli SKU z produktem nadrzędnym, więc integracja aktualizuje rodzica albo pomija wariant. Efekt: stan rozjeżdża się tylko na części rozmiarów.
EAN na złym poziomie
Kod EAN przypisany do produktu, nie do wariantu, uniemożliwia dopasowanie zamówienia z marketplace i wypycha pozycje do ręcznej obsługi.
Limit zapytań Shoper API
Pełny przelot katalogu w środku dnia wyczerpuje limit i część aktualizacji przepada bez śladu, jeżeli proces nie ma kolejki i ponowień.
Dwa systemy piszą stan
Stan wraca cyklicznie do poprzedniej wartości. To zawsze oznacza dwa zapisy do jednego pola — nie „opóźnienie synchronizacji".
Praca z limitami API
Duży katalog wymaga innego harmonogramu
Przy kilkudziesięciu tysiącach SKU nie da się aktualizować wszystkiego przy każdej zmianie. Proces musi wiedzieć, co faktycznie się zmieniło, i rozłożyć zapisy w czasie.
- aktualizujemy wyłącznie rekordy z realną zmianą stanu lub ceny,
- zapisy idą paczkami z kontrolą tempa i kolejką ponowień,
- pełny przelot katalogu poza godzinami największego ruchu,
- błąd 429 albo timeout nie gubi rekordu — wraca do kolejki,
- każda operacja ma wpis w logu: co, kiedy, z jakim wynikiem.
ZdarzenieReakcja procesuLog
zamówieniezejście ze stanu, zapis do ShoperaINFO
brak SKUpozycja do wyjątków, bez zapisuWARN
HTTP 429backoff i ponowienieWARN
HTTP 5xxponowienie, potem alertERROR
zwrotpowrót stanu, korekta kanałówINFO
Zakres wdrożenia
Cztery etapy zamiast „włączenia integracji"
BaseLinker ma gotowy moduł do Shopera. Problem nie polega na jego uruchomieniu, tylko na tym, żeby po uruchomieniu dane w obu systemach nadal się zgadzały. To jest właściwy zakres pracy.
- mapa kanałów i pól: kto sprzedaje gdzie i który system rządzi którym polem (tabela wyżej),
- audyt identyfikatorów: SKU na poziomie wariantu, EAN na właściwym poziomie, duplikaty,
- uruchomienie na próbce: kilkadziesiąt SKU i realne zamówienie testowe przed pełnym katalogiem,
- harmonogram i logi: tempo zapisów, kolejka ponowień, alert przy 5xx, raport rozjazdów stanu.
Etap drugi jest tym, który najczęściej decyduje o wyniku. Jeżeli identyfikatory są nieuporządkowane, żadna konfiguracja nie pomoże — patrz SKU czy EAN w integracjach.
Co przygotować na start
Sześć rzeczy, które skracają wdrożenie
ElementPo coKto daje
klucz Shoper APIzapis stanów i odczyt kataloguklient
token BaseLinkerzamówienia, statusy, magazynklient
lista kanałówzakres synchronizacjiklient
decyzja o staniejedno źródło prawdywspólnie
eksport SKU/EANaudyt dopasowania pozycjiklient
okno na testyzamówienie testowe bez ryzykawspólnie
Kiedy ta integracja nie jest potrzebna. Jeżeli sprzedajesz wyłącznie w sklepie i nie masz
kont na marketplace, BaseLinker nie rozwiązuje żadnego problemu — wtedy właściwym kierunkiem jest
spięcie sklepu z ERP-em
albo integracja przez Shoper API bez warstwy pośredniej.
FAQ
BaseLinker i Shoper — pytania
Przy sprzedaży na marketplace stan zwykle prowadzi BaseLinker, bo to on rozdziela dostępność między Allegro, Amazon i sklep. Shoper dostaje wtedy stan z jednego kierunku. Odwrotny układ ma sens tylko wtedy, gdy sklep jest jedynym kanałem sprzedaży.
BaseLinker pobiera zamówienie z marketplace, dopasowuje pozycje po SKU lub EAN, obniża stan i wypycha nowy stan do Shopera. Zmiana statusu i numeru przewozowego wraca tą samą drogą, żeby klient sklepu i kupujący na marketplace widzieli spójny stan realizacji.
Najczęściej dlatego, że wariant w Shoperze nie ma własnego, unikalnego SKU albo EAN jest przypisany do produktu nadrzędnego zamiast do rozmiaru. Bez unikalnego klucza na poziomie wariantu integracja nie wie, którą pozycję zaktualizować, i pomija rekord albo trafia w zły produkt.
Przy kilkudziesięciu tysiącach SKU tak. Dlatego aktualizacje puszczamy paczkami, tylko dla rekordów, które faktycznie się zmieniły, z kontrolą tempa i ponawianiem po błędzie. Pełny przelot katalogu robimy poza godzinami największego ruchu.
Sygnałem jest stan, który wraca do poprzedniej wartości bez działania człowieka albo zmienia się cyklicznie. Prawie zawsze oznacza to, że dwa systemy zapisują to samo pole. Rozwiązaniem jest jeden kierunek zapisu na pole i log, który pokazuje, kto ostatni je zmienił.
Wypisz kanały sprzedaży i powiedz, który z nich ma rządzić stanem
Na tej podstawie przygotujemy tabelę źródła prawdy i pokażemy, gdzie obecna konfiguracja może się gryźć.