BaseLinker: statusy zamówień i automatyczne akcje

Gdy zamówienie trafia do niewłaściwego statusu

Najczęstszym objawem jest zamówienie pozostające w niewłaściwym etapie obsługi. Płatność została zaksięgowana, ale zamówienie nadal ma status oczekiwania na płatność. Przesyłka została nadana, a system nie zmienił etapu realizacji. Czasem jeden zakup pojawia się jednocześnie w kilku miejscach albo wraca do wcześniejszego statusu po synchronizacji.

W BaseLinkerze status zamówienia jest informacją o jego aktualnym etapie, na przykład oczekiwaniu na płatność, kompletowaniu, pakowaniu lub wysyłce. Sam status nie zawsze zmienia się automatycznie. Zależy to od reguł, danych otrzymywanych z systemu sprzedaży, operatora płatności, firmy kurierskiej albo programu ERP, czyli systemu do zarządzania procesami przedsiębiorstwa.

Do błędu może dojść także wtedy, gdy kilka automatyzacji reaguje na ten sam warunek. Jedna reguła przenosi zamówienie do realizacji, a druga po chwili ustawia status związany z brakiem płatności. Bez uporządkowania kolejności działań trudno ocenić, która reguła jest przyczyną problemu.

Jak zbudować spójny model statusów

Konfigurację zaczyna się od opisania rzeczywistego obiegu zamówienia. Najpierw ustala się, jakie etapy są potrzebne i jakie zdarzenie powoduje przejście między nimi. Status „opłacone” powinien oznaczać potwierdzenie płatności, a nie samo wybranie szybkiego przelewu. Status „wysłane” powinien być powiązany z faktycznym przekazaniem przesyłki przewoźnikowi, nie tylko z utworzeniem etykiety.

Ważne jest rozdzielenie statusów operacyjnych od informacyjnych. Status operacyjny steruje pracą osób kompletujących i pakujących. Status informacyjny opisuje zdarzenie, ale nie musi uruchamiać kolejnego działania. Takie rozróżnienie ogranicza liczbę pomyłek, ponieważ nie każda zmiana danych powinna wywoływać e-mail, wydruk lub synchronizację z innym systemem.

Przydatne jest również określenie statusów wyjątkowych. Mogą dotyczyć braku płatności, niezgodności adresu, niedostępności produktu, zwrotu albo reklamacji. Zamówienia problemowe nie powinny pozostawać w zwykłej kolejce, ponieważ automatyczne akcje przeznaczone dla standardowej realizacji mogą wykonać się przed sprawdzeniem sprawy.

Reguły automatyczne i ich warunki

Reguła automatyczna to instrukcja typu „jeżeli wystąpi określony warunek, wykonaj wskazaną akcję”. Warunkiem może być status, sposób dostawy, źródło zamówienia, rodzaj płatności, wartość koszyka albo obecność konkretnego produktu. Akcją może być zmiana statusu, wysłanie wiadomości, utworzenie dokumentu lub przekazanie danych do połączonego systemu.

Najczęstsze problemy wynikają z warunków zbyt szerokich. Reguła sprawdzająca wyłącznie status „nowe” może objąć zamówienia z różnych kanałów sprzedaży, także te, które wymagają ręcznej kontroli. Bez dodatkowego warunku dotyczącego płatności lub dostawy automatyzacja zadziała poprawnie technicznie, lecz niezgodnie z procesem firmy.

Przy projektowaniu reguł analizuje się kolejność ich wykonywania. Najpierw powinny działać warunki porządkujące dane, później akcje związane z komunikacją, a na końcu działania zmieniające etap realizacji. Każda reguła powinna mieć jednoznaczny cel. Jeżeli kilka reguł robi podobne rzeczy, należy sprawdzić, czy nie dublują się albo nie tworzą pętli, czyli ciągu zmian powodujących ponowne uruchamianie tych samych akcji.

Warto też ustalić, co ma się stać, gdy warunek nie jest spełniony. Brak akcji nie zawsze oznacza błąd. Czasem bezpieczniej pozostawić zamówienie w kolejce do kontroli niż automatycznie przypisać je do niewłaściwego etapu.

Powiadomienia wysyłane we właściwym momencie

Powiadomienie powinno wynikać z konkretnego zdarzenia, a nie z każdej zmiany technicznej w zamówieniu. Klient nie potrzebuje kilku podobnych wiadomości po aktualizacji adresu, numeru przesyłki i statusu w krótkim odstępie czasu. Zespół obsługi także traci przejrzystość, gdy skrzynka jest wypełniona komunikatami bez znaczenia dla dalszej pracy.

Podczas konfiguracji sprawdza się szablony wiadomości, czyli przygotowane treści wysyłane automatycznie. Istotne są zmienne, czyli pola uzupełniane danymi konkretnego zamówienia, na przykład numerem zakupu, adresem lub numerem przesyłki. Błędna zmienna może pozostawić pusty fragment albo wstawić nieaktualną informację.

Oddziela się wiadomości zewnętrzne od wewnętrznych. Wiadomość zewnętrzna trafia do kupującego. Wiadomość wewnętrzna może informować zespół o wyjątku, takim jak brak produktu lub niezgodność płatności. Przypadkowe podłączenie szablonu wewnętrznego do wysyłki zewnętrznej może ujawnić informacje organizacyjne, dlatego przed uruchomieniem automatyzacji potrzebna jest kontrola odbiorcy i treści.

Wydruki, etykiety i dokumenty w procesie realizacji

Automatyczne wydruki są wygodne, ale wymagają spójnego powiązania z etapem obsługi. Wydruk listy kompletacyjnej powinien pojawić się wtedy, gdy zamówienie rzeczywiście trafia do kompletowania. Etykieta przewozowa powinna być tworzona dopiero po sprawdzeniu adresu, sposobu dostawy i dostępności danych wymaganych przez przewoźnika.

Lista kompletacyjna to dokument pomagający zebrać produkty z zamówienia. Jeżeli jest generowana zbyt wcześnie, może zawierać pozycje, które później zostały zmienione. Z kolei etykieta utworzona przed kontrolą danych może mieć błędny adres, gabaryt albo metodę dostawy.

Sprawdza się również, czy automatyzacja nie tworzy tego samego dokumentu wielokrotnie. Powodem może być ponowne pobranie zamówienia z marketplace, czyli platformy sprzedażowej, albo zmiana statusu przez kilka niezależnych integracji. Pomocne jest zastosowanie warunku, który rozpoznaje, czy dokument lub etykieta już istnieje.

Synchronizacja z marketplace

Marketplace przekazuje do BaseLinkera zamówienia, dane kupujących i informacje o płatności. Synchronizacja może działać w dwóch kierunkach: dane są pobierane z platformy do BaseLinkera, a następnie część zmian wraca do źródła. Przy takim układzie trzeba ustalić, który system jest głównym miejscem podejmowania decyzji.

Jeżeli status jest zmieniany ręcznie na marketplace, a BaseLinker ma jednocześnie własną regułę przejścia, systemy mogą nadpisywać się wzajemnie. Podobna sytuacja występuje przy zmianie metody dostawy, adresu lub danych fakturowych. Należy ustalić, czy te informacje mają być edytowane w BaseLinkerze, na platformie, czy w systemie ERP.

Przy diagnozie sprawdza się mapowanie statusów. Mapowanie, czyli przypisanie statusu z jednego systemu do odpowiadającego mu statusu w drugim systemie, powinno być jednoznaczne. Jeżeli kilka statusów z marketplace trafia do jednego etapu BaseLinkera, automatyczne akcje mogą nie rozróżniać ważnych przypadków.

Połączenie z ERP i kontrola danych

Integracja z ERP może obejmować produkty, stany magazynowe, ceny, dokumenty sprzedaży oraz statusy zamówień. Każdy z tych obszarów może mieć inne źródło danych. ERP może być źródłem stanów magazynowych, BaseLinker miejscem obsługi zamówień, a marketplace kanałem pozyskania sprzedaży.

Najczęstszy błąd polega na braku ustalenia właściciela danych. Jeśli stany magazynowe są zmieniane ręcznie w dwóch systemach, szybko pojawiają się rozbieżności. Jeżeli dokument sprzedaży jest tworzony zarówno w BaseLinkerze, jak i w ERP, może dojść do powielenia dokumentów albo niezgodności numeracji.

Sprawdza się identyfikatory produktów, czyli oznaczenia pozwalające połączyć tę samą pozycję w różnych systemach. Różny symbol, wariant lub jednostka miary może spowodować, że synchronizacja utworzy nowy produkt zamiast zaktualizować istniejący. Kontrolowana konfiguracja obejmuje także sposób obsługi anulowania, zwrotów i korekt.

Jak przebiega konfiguracja i testowanie

Prace zaczynają się od zebrania informacji o kanałach sprzedaży, metodach płatności, dostawach, dokumentach i obecnych statusach. Analizowane są również reguły, które już działają. Bez tego łatwo naprawić jeden element i jednocześnie zakłócić inny proces.

Następnie przygotowuje się uporządkowany schemat przepływu zamówienia. Schemat pokazuje, jakie zdarzenie zmienia status, która reguła uruchamia akcję i do którego systemu trafia wynik. Dzięki temu można znaleźć miejsce, w którym informacja znika, zostaje opóźniona albo jest nadpisywana.

Po zmianach przeprowadza się testy na zamówieniach kontrolnych. Sprawdza się różne warianty: opłacone i nieopłacone, z dostawą kurierską i odbiorem, z produktem dostępnym i brakującym, a także zamówienie wymagające ręcznej weryfikacji. Test obejmuje status, wiadomość, dokument, wydruk i wynik synchronizacji.

Po uruchomieniu automatyzacji potrzebna jest kontrola logów, czyli zapisów działań wykonywanych przez system. Log pozwala ustalić, która reguła zadziałała, jaki warunek został rozpoznany i czy połączenie z innym systemem zwróciło błąd.

Ile trwa uporządkowanie BaseLinkera

Nie ma jednego czasu właściwego dla każdej konfiguracji. Prosty problem z pojedynczą regułą różni się od przebudowy statusów połączonych z marketplace, ERP, płatnościami, przewoźnikami i wydrukami. Znaczenie ma także liczba istniejących automatyzacji oraz to, czy dokumentacja obecnych ustawień jest dostępna.

Przed rozpoczęciem prac można określić zakres obejmujący samą diagnozę, korektę wybranych reguł albo szersze uporządkowanie procesu. W przypadku rozbudowanych zmian czas zależy od testów i konieczności uzgodnienia, który system ma być źródłem danych. Nie stosuje się sztucznego czasu reakcji ani obietnic niezależnych od zakresu.

Jeżeli konfiguracja jest wykonywana w ramach obsługi informatycznej, możliwa jest praca zdalna albo przyjazd serwisanta. Przy wizycie serwisanta dojazd jest bezpłatny, natomiast praca jest zawsze płatna. Działania nie powinny rozpoczynać się od obietnicy bezpłatnego przeglądu całego środowiska IT.

Co można sprawdzić samodzielnie

Przed zgłoszeniem problemu warto zapisać przykładowe numery zamówień, których dotyczy błąd, oraz zanotować oczekiwany i rzeczywisty status. Przydatne jest wskazanie godziny wystąpienia problemu, kanału sprzedaży i rodzaju płatności. Takie dane ułatwiają odtworzenie warunku, który uruchomił niewłaściwą akcję.

Można sprawdzić, czy problem dotyczy wszystkich zamówień, czy tylko określonego marketplace, sposobu dostawy albo produktu. Warto także porównać dane widoczne w BaseLinkerze z danymi w systemie źródłowym. Jeżeli rozbieżność występuje tylko po jednej stronie, prawdopodobnie problem dotyczy synchronizacji lub mapowania.

Bezpieczne jest przejrzenie listy aktywnych reguł i sprawdzenie, czy nie ma dwóch automatyzacji wykonujących tę samą czynność. Należy jednak zachować kopię opisów ustawień, aby możliwe było odtworzenie poprzedniego stanu. Wrażliwe dane można przekazać w ograniczonym zakresie. Domyślnie nie jest potrzebne hasło klienta.

Błędy przy samodzielnych zmianach

Częstym błędem jest wyłączenie wszystkich reguł naraz. Taki ruch może zatrzymać prawidłowe powiadomienia, wydruki i przekazywanie danych, a później utrudnić znalezienie właściwej przyczyny. Bezpieczniejsze jest wyłączenie jednej podejrzanej reguły po zapisaniu jej warunków i sprawdzenie wyniku na kontrolnym zamówieniu.

Ryzykowne jest także tworzenie kolejnej automatyzacji bez sprawdzenia istniejących. Nowa reguła może tylko przykryć problem, zwiększyć liczbę zmian i doprowadzić do pętli. Nie powinno się również masowo zmieniać statusów bez wiedzy, czy ta operacja uruchamia wiadomości, dokumenty lub synchronizację zewnętrzną.

Błędem bywa testowanie wyłącznie pozytywnego scenariusza. Jeżeli sprawdzane jest tylko opłacone zamówienie z poprawnym adresem, nie zostaną wykryte problemy z brakiem płatności, anulowaniem, zwrotem lub błędnym numerem przesyłki. Test powinien obejmować także sytuacje wyjątkowe.

Kiedy problem nie dotyczy statusów

Nie każda niezgodność w obsłudze zamówienia wynika z reguły BaseLinkera. Jeżeli dane nie pojawiają się w systemie, przyczyną może być przerwane połączenie, wygasły token autoryzacyjny albo błąd po stronie marketplace. Token autoryzacyjny to specjalny klucz umożliwiający systemom wymianę danych bez wpisywania hasła przy każdej operacji.

Jeżeli status jest poprawny, ale brakuje produktu na wydruku, należy sprawdzić mapowanie produktu, wariant oraz dane przekazane przez kanał sprzedaży. Jeżeli wiadomość nie dotarła, problem może dotyczyć skrzynki odbiorczej, serwera pocztowego lub błędnego adresu, a nie samego warunku zmiany statusu.

Jeżeli stany magazynowe są nieprawidłowe, konieczna może być analiza integracji z ERP, a nie automatycznych statusów. Jeżeli etykieta zawiera błędny adres, trzeba sprawdzić dane zamówienia i konfigurację przewoźnika. Rozróżnienie tych przypadków zapobiega poprawianiu niewłaściwego elementu.

Czy da się ograniczyć liczbę statusów?

Tak, często warto pozostawić tylko statusy potrzebne do podejmowania decyzji. Zbyt szczegółowa lista utrudnia pracę, zwłaszcza gdy różnice między etapami nie powodują żadnej konkretnej akcji. Status powinien mieć jasno określone znaczenie i właściciela w procesie.

Co zrobić z zamówieniami wymagającymi ręcznej kontroli?

Dla takich przypadków najlepiej wydzielić status kontrolny oraz opisać przyczynę zatrzymania w notatce wewnętrznej. Automatyzacje przeznaczone dla zwykłych zamówień nie powinny przenosić takiego zakupu dalej bez sprawdzenia danych, płatności lub dostępności produktu.

Czy automatyczne wiadomości można rozdzielić według kanałów sprzedaży?

Tak. Reguła może uwzględniać źródło zamówienia, metodę dostawy albo typ płatności. Dzięki temu treść i moment wysyłki można dopasować do konkretnego procesu, pod warunkiem że mapowanie kanału jest prawidłowe i nie ma konkurencyjnej reguły obejmującej wszystkie zamówienia.

Jak kontrolować konfigurację po zmianach?

Warto okresowo analizować logi, przykładowe zamówienia i historię zmian statusów. Kontrola powinna obejmować także wydruki, wiadomości oraz dane przekazywane do ERP i marketplace. Jeżeli proces sprzedaży się zmienia, reguły wymagają ponownego testu, nawet gdy wcześniej działały poprawnie.

Podsumowanie

Sprawne statusy i automatyczne akcje w BaseLinkerze wynikają z jasnego modelu procesu, jednoznacznych warunków i prawidłowego podziału odpowiedzialności między systemami. Najpierw ustala się znaczenie statusów, następnie porządkuje reguły, powiadomienia, wydruki i synchronizację. Testy na różnych scenariuszach pozwalają wykryć konflikty, zanim wpłyną na obsługę zamówień.