Jeżeli dwa kanały widzą ostatnią sztukę, oba mogą ją sprzedać. Pełny eksport co godzinę nie rozwiązuje tego problemu — potrzebna jest rezerwacja albo bufor w krótszym oknie czasowym.
Sklep sprzedaje produkt niedostępny w magazynie, a po korekcie w ERP stan wraca do starej wartości.
Sprawdź, czy wiadomości mają znacznik czasu lub wersję rekordu i czy proces odrzuca aktualizację starszą od już zapisanej.
Najpierw zdefiniuj rodzaje stanów
Jeżeli integracja przesyła tylko liczbę stock, trzeba wiedzieć, którą z wielu wartości reprezentuje. Najczęściej do kanałów sprzedaży powinien trafiać stan dostępny po odjęciu rezerwacji i bufora.
- stan fizyczny
- rezerwacje do zamówień
- stan dostępny
- towar w drodze
- stan marketplace
- bufor bezpieczeństwa
- stan wirtualny lub dropshippingowy
Jedno źródło prawdy dla pola stanu
Dla większości firm źródłem prawdy jest ERP albo WMS. Sklep i BaseLinker powinny publikować wynik, a nie samodzielnie ustalać stan bazowy. Wyjątki, na przykład magazyn dropshippingowy albo osobna pula marketplace, trzeba opisać osobnymi regułami.
Szerszą matrycę odpowiedzialności — dla ceny, opisu i zamówienia, nie tylko stanu — opisuje poradnik o źródle prawdy między sklepem, ERP i BaseLinkerem.
| Pole | Źródło | Odbiorcy |
|---|---|---|
| stan fizyczny | ERP / WMS | warstwa integracji |
| rezerwacja | system przyjmujący zamówienie + ERP | agregator |
| stan dostępny | obliczenie integracji albo ERP | sklep, BaseLinker |
| bufor | konfiguracja kanału | sklep / marketplace |
Rezerwacja musi powstać przed kolejną sprzedażą
Największe ryzyko występuje między złożeniem zamówienia a aktualizacją ERP. Nie wystarczy uruchamiać pełnego eksportu co godzinę, jeżeli produkty sprzedają się w kilku kanałach jednocześnie.
- natychmiastowa rezerwacja w centralnym systemie
- lokalna rezerwacja w brokerze integracji
- bufor bezpieczeństwa
- szybsza synchronizacja dla produktów niskostanowych
- blokada sprzedaży przy niepewnym stanie
Aktualizacja powinna być zdarzeniowa albo przyrostowa
Pełny eksport całego katalogu co kilka minut jest kosztowny i utrudnia diagnozę. Proces przyrostowy aktualizuje tylko SKU, które się zmieniły. Pełne porównanie raz na dobę albo tydzień wykrywa rozjazdy, które ominęły kolejkę.
- zdarzenie po zmianie stanu
- kolejka zmian
- okresowy reconciliation pełnego katalogu
- osobna kolejka błędów
- checkpoint ostatniego poprawnego przetworzenia
Konflikty i starsze dane
Każda wiadomość powinna mieć znacznik czasu albo wersję rekordu. Jeżeli opóźniona aktualizacja ze stanem 8 przyjdzie po nowszej aktualizacji ze stanem 3, nie może przywrócić starej wartości.
- odrzucaj starszą wersję
- zapisuj źródło i czas zmiany
- nie używaj czasu serwera odbiorcy jako jedynego kryterium
- zachowuj historię ostatnich operacji
- przy konflikcie zatrzymaj rekord albo wybierz zdefiniowanego właściciela
SKU i mapowanie muszą być stabilne
Aktualizacja stanu po złym SKU jest gorsza niż jej brak. Przed synchronizacją stanu system powinien korzystać z utrwalonej mapy identyfikatorów między ERP, sklepem i BaseLinkerem.
Rekord bez jednoznacznego dopasowania powinien trafić do kolejki błędów. Nie wolno automatycznie przypisywać stanu po podobnej nazwie produktu — patrz hierarchia matchingu SKU i EAN.
Ujemny stan i brak danych to różne sytuacje
Wartości 0, -2, null i brak rekordu nie mogą automatycznie znaczyć tego samego. Dla każdej sytuacji ustal decyzję: publikuj zero, zachowaj poprzedni stan, zablokuj sprzedaż albo zgłoś alarm.
0Brak dostępnej sztuki. Wartość poprawna i jednoznaczna.
Błąd, backorder albo specyficzny model ERP. Wymaga reguły, nie ignorowania.
nullBrak obliczenia. Nie to samo co zero.
Produkt nie został zwrócony przez źródło. Może oznaczać awarię, nie wyczerpanie stanu.
Monitoring musi mierzyć opóźnienie i kompletność
Alert powinien reagować również na ciszę. Jeżeli zwykle pojawia się tysiąc zmian dziennie, brak jakiejkolwiek wiadomości przez kilka godzin może oznaczać awarię źródła.
- czas od zmiany w ERP do publikacji w sklepie
- liczba zmian w kolejce
- najstarsza nieprzetworzona wiadomość
- liczba błędów mapowania
- liczba retry
- liczba SKU z rozjazdem
- data ostatniego pełnego uzgodnienia
Testy przed uruchomieniem
Scenariusze poniżej wychodzą poza „czy stan się zaktualizował”. Każdy z nich sprawdza inną regułę procesu.
- ostatnia sztuka sprzedana równolegle w dwóch kanałach
- anulowanie zamówienia i zwolnienie rezerwacji
- zwrot
- korekta ręczna w ERP
- opóźniona wiadomość
- duplikat zdarzenia
- brak mapy SKU
- ujemny stan
- awaria jednego kanału
- ponowne uruchomienie kolejki