„Zapisało się, ale nie widać"
Rekord w bazie jest poprawny, front pokazuje stare dane. Winne są indeksatory w trybie „on save", zapchana kolejka cron albo cache pełnostronicowy.
BaseLinker · Magento · MSI
Magento nie ma jednego „stanu" — i to zmienia całą integrację
BaseLinker wysyła jedną liczbę. Magento przechowuje source items per magazyn, wylicza salable quantity, odejmuje rezerwacje z niezrealizowanych zamówień i pokazuje wynik dopiero po indeksacji. Integracja, która o tym nie wie, sprzedaje towar już zarezerwowany.
SOURCEmagazyn główny18
SOURCEsklep stacjonarny4
RESERVzamówienia w toku−3
SALABLEdo sprzedaży online19
INDEXcataloginventory_stockschedule
Zapis idzie do source. Odczyt zawsze z salable quantity. Front pokazuje wynik po przebiegu indeksatora.
Model danych
Simple, configurable i to, który z nich naprawdę ma stan
Klient widzi produkt configurable. Stan, SKU i cena siedzą na produktach simple. Integracja musi pisać w jedno miejsce, a raportować w drugie — inaczej sprzedaż per model nigdy się nie zgodzi.
| Operacja | Obiekt w Magento | Mechanizm | Co pójdzie źle bez tego |
|---|---|---|---|
| Aktualizacja stanu | simple product | source item per magazyn | zapis do configurable jest ignorowany |
| Odczyt dostępności | configurable + simple | salable quantity | sprzedaż towaru już zarezerwowanego |
| Aktualizacja ceny | simple product | scope: default / store view | cena zmienia się tylko w jednym widoku sklepu |
| Import zamówienia | order + order items | mapowanie po SKU simple | pozycje bez dopasowania i błędne raporty |
| Publikacja na froncie | indeksy katalogu i stanu | cron + indexer w trybie schedule | zmiana zapisana, ale niewidoczna dla klienta |
Mapa magazynów
Bez mapy źródeł stany sumują się przypadkowo
Zanim cokolwiek podłączymy, spisujemy każdy magazyn BaseLinkera i jego odpowiednik w Magento — razem z decyzją, czy w ogóle bierze udział w sprzedaży online.
- jeden magazyn BaseLinkera = jedno source w Magento,
- magazyny nieuczestniczące w sprzedaży online oznaczone jawnie,
- stock group opisany razem z zasadą wyliczania dostępności,
- towar w drodze i zwroty mają własną regułę, nie wpadają do stanu handlowego,
- zmiana mapy zawsze przechodzi przez staging przed produkcją.
BaseLinkerMagento sourceOnline
Magazyn Adefaulttak
Magazyn Bwarehouse_btak
Salonretail_posnie
Serwisservice_holdnie
W drodzebrak odwzorowanianie
Typowe awarie tej pary
Objawy, które w Magento znaczą co innego
Sprzedaż towaru z rezerwacji
Integracja nadpisała stan liczbą z ERP albo BaseLinkera, ignorując rezerwacje Magento. Dostępność rośnie sztucznie, a zamówienia trafiają na brak towaru.
Import kładzie sklep w ciągu dnia
Masowy zapis atrybutów w modelu EAV plus reindeks całego katalogu potrafią zająć bazę na kilkadziesiąt minut. Rozwiązaniem są paczki, kolejki i okno poza szczytem.
Status w pętli
Dwukierunkowa synchronizacja wszystkich statusów sprawia, że dwa systemy nadpisują się nawzajem. Ograniczamy ją do kilku stanów granicznych z jednym kierunkiem.
Duplikaty zamówień
Ponowienie po timeoucie tworzy drugie zamówienie, bo brakuje klucza idempotencji i znacznika „już przekazane".
Cena tylko w jednym store view
Zapis bez świadomości zakresu (scope) zmienia cenę w widoku domyślnym, a klient w innym widoku dalej widzi starą.
FAQ
BaseLinker i Magento — pytania
Bo w Magento to simple trzyma stan i SKU, a configurable jest tylko produktem nadrzędnym prezentowanym klientowi. Integracja musi więc operować na simple przy stanach i cenach, ale mapować zamówienie na właściwy produkt nadrzędny, żeby raporty sprzedaży miały sens.
Przy Multi Source Inventory stan nie jest jedną liczbą. Są source items per magazyn i wyliczana salable quantity, pomniejszona o rezerwacje. Integracja powinna zapisywać do konkretnego source, a czytać salable quantity — inaczej sprzedasz towar, który jest już zarezerwowany.
Zwykle przez indeksatory i cache. Dopóki nie przebiegnie indeksacja stanu i cen albo nie zostanie unieważniony cache, front pokazuje stare dane. Przy częstych aktualizacjach z BaseLinkera warto ustawić indeksatory na tryb harmonogramu i pilnować kolejek cron.
Jeden do jednego, spisane wprost przed wdrożeniem. Każdy magazyn w BaseLinkerze powinien mieć swoje source w Magento i jasno określone, czy w ogóle uczestniczy w sprzedaży online. Bez tej mapy stany sumują się przypadkowo.
Można, ale nie warto robić tego dla wszystkich statusów. Bezpieczniej wybrać kilka stanów granicznych, na przykład wysłane i anulowane, i dla nich ustalić jeden kierunek. Pełna dwukierunkowość szybko prowadzi do nadpisywania statusu w kółko.
Podeślij listę magazynów i tryb pracy indeksatorów
To dwie informacje, które w Magento decydują o połowie problemów ze stanami. Na ich podstawie powiemy, czy obecna konfiguracja jest bezpieczna.