Gdy nie wiadomo, czy ERP przyjął dokument, system wybiera stan nierozstrzygnięty zamiast ponowienia

Autor: Adam Siemiątkowski, SoftwareStudio Group Sp. z o.o.

Stan nierozstrzygnięty po wysłaniu dokumentu do ERP bierze się z prostej obserwacji: błąd, który wystąpi po wysłaniu zadania do kolejki, nie dowodzi, że ERP dokumentu nie przyjął. Gdyby system wtedy ponowił wysyłkę, mógłby utworzyć drugi dokument. Gdyby anulował dokument w systemie, oddałby pozycje do ponownego przyjęcia, a ERP mógłby jeszcze utworzyć swój dokument.

Dlatego w opisywanym wdrożeniu odpowiedź „nie wiem” ma osobny stan. Ta strona opisuje reguły tego stanu od strony magazyniera i administratora. Sprawdzenie ilości, które poprzedza wysyłkę, opisuje strona o kontroli ilości w ERP przed zapisem, a sam przebieg wysyłki strona o wysyłce przyjęcia przez kolejkę.

Błąd po wysłaniu nie dowodzi, że dokumentu nie ma

System oznacza moment wysłania zadania do kolejki ERP. Wszystko, co wydarzy się po tym momencie, jest oceniane inaczej niż to, co wydarzyło się przed nim. Odmowa kolejki albo błąd walidacji to odrzucenie: ERP jasno powiedział, że dokumentu nie przyjmuje. Przyjęcie zadania z identyfikatorem wpisu oznacza, że dokument czeka w kolejce i trzeba poczekać na wynik.

Wszystko pomiędzy tymi dwoma wynikami jest stanem nierozstrzygniętym. Należą do niego: brak statusu odpowiedzi, błąd bramy po stronie serwera, przekroczenie czasu, zbyt wiele żądań, błąd połączenia, odpowiedź nieczytelna, odpowiedź bez identyfikatora wpisu i błąd zapisu wpisu śledzącego. Zwykłe odrzucenie to odmowa kolejki inna niż przekroczenie czasu i zbyt wiele żądań.

Stan nierozstrzygnięty blokuje ponowną wysyłkę i anulowanie

Ponowna wysyłka dokumentu w tym stanie jest zablokowana w bazie, a formularz nie ma przycisku ponownej wysyłki. Zablokowane jest też anulowanie: ekran w tym stanie nie oferuje przycisku anulowania, a anulowanie jest zablokowane również w bazie. Decyzję po sprawdzeniu w ERP podejmuje administrator.

Kontrola ilości traktuje taki wpis jak dokument czekający w kolejce, więc ilość pozostaje zarezerwowana na pozycji zamówienia. Ilość nie wraca do puli, dopóki wpis pozostaje nierozstrzygnięty.

Magazynier czyta ostrzeżenie i wie, czego nie robić

Ekran błędu pokazuje opis stanu. W stanie nierozstrzygniętym opis jest oznaczony jako nierozstrzygnięty i mówi, że trzeba sprawdzić w ERP, czy dokument powstał, zanim przyjmie się towar ręcznie albo wyśle dokument ponownie. Ostrzeżenie „nie przyjmuj tego towaru ręcznie w ERP” towarzyszy każdemu dokumentowi, którego stan nie jest znany albo który czeka w kolejce: na ekranach końcowych (sukcesu i błędu) oraz w opisach dokumentów.

Gdy po wysłaniu dokumentu nie odpowie sama wysyłka, formularz nie wysyła go drugi raz. Najpierw pyta o stan. Jeżeli stan zwróci brak wpisu wysyłki, nie jest to dowód, że dokument nie trafił do ERP, bo wywołanie mogło zostać przerwane już po wysłaniu zadania. Ekran pokazuje wtedy komunikat: „Serwer nie odpowiedział na wysyłkę i nie ma jeszcze śladu dokumentu w kolejce ERP. Stan w ERP jest nieznany - nie przyjmuj tego towaru ręcznie w ERP i nie wysyłaj dokumentu ponownie. Sprawdź dokument za kilka minut albo zgłoś sprawę administratorowi.”

Brak śladu dokumentu w kolejce nie oznacza, że dokumentu nie ma w ERP, więc do czasu sprawdzenia nie wysyłamy go ponownie i nie przyjmujemy towaru ręcznie.

Gdy nie odpowie ani wysyłka, ani pytanie o stan, ekran mówi, że serwer nie odpowiedział na żadne z nich, że stan w ERP jest nieznany i że trzeba zgłosić sprawę administratorowi. Przy błędzie samego formularza w trakcie wysyłki ostrzeżenie każe nie przyjmować towaru ręcznie, dopóki stan dokumentu nie zostanie sprawdzony.

Anulować wolno tylko dokument, który nie powstał w ERP

Przycisk Anuluj dokument pojawia się na ekranie błędu przy dokumentach odrzuconych przez ERP, zatrzymanych przez walidację przed wysłaniem, z nieudanym zapisem pozycji i po błędzie formularza, a także wtedy, gdy inny dokument do tego samego zamówienia jest właśnie wysyłany. Serwer sprawdza to jeszcze raz i odmawia, gdy dokument powstał w ERP, czeka w kolejce, jest wysyłany albo jest nierozstrzygnięty. Dokument zatrzymany przez kontrolę ilości jest anulowany automatycznie.

Po błędzie samego formularza ekran pokazuje przycisk anulowania, ale baza odmówi, jeśli dokument w międzyczasie powstał. Anulowanie pyta o powód w oknie przeglądarki, które nie ma wartości domyślnej i zawiera numer dokumentu. Formularz zamienia w powodzie cudzysłowy, apostrofy, kreski pionowe, odwrotne ukośniki, znaki nowej linii i tabulatory na spacje, ucina powód do dwustu znaków i wymaga co najmniej trzech. Przy zbyt krótkim powodzie prosi o uzupełnienie. Login operatora bierze serwer z sesji.

Po udanym anulowaniu pozycje dokumentu są oznaczone jako usunięte i wracają na listę po ponownym otwarciu formularza. Wpis śledzący dostaje status anulowany z dopiskiem: data i login operatora oraz podany powód. Obok przycisku pojawia się komunikat „Dokument został anulowany. Pozycje wracają do realizacji na awizacji.” Gdy dokument w ogóle nie zapisał się w systemie, ekran mówi, że nie ma czego anulować.

Dwa warianty jednego poranka

Przykład z danymi fikcyjnymi, wariant pierwszy: błąd bramy po wysłaniu. Magazynier wysyła dokument dla Zamówienia 26-1001 od Dostawcy Testowego, a brama między systemem a ERP zgłasza błąd już po wysłaniu zadania. Ekran pokazuje opis stanu nierozstrzygniętego i prosi, żeby nie przyjmować Artykułu A ręcznie ani nie wysyłać dokumentu drugi raz. Przycisku anulowania nie ma, a ilość z dokumentu pozostaje zarezerwowana w kontroli. Administrator sprawdza w ERP, czy dokument powstał, i podejmuje decyzję.

Wariant drugi: serwer w ogóle nie odpowiada na wysyłkę, a pytanie o stan zwraca brak wpisu. Ekran pokazuje komunikat o nieznanym stanie w ERP i zaleca sprawdzenie za kilka minut albo zgłoszenie administratorowi. W tym wariancie nie ma wpisu w kolejce, więc kontrola w ERP nie rezerwuje ilości. Ostrzeżenie o ręcznym przyjęciu jest tu więc równie ważne.

Czego ten mechanizm nie obejmuje

W opisywanym wdrożeniu stan nierozstrzygnięty nie rozstrzyga się sam i nie ma automatycznego ponawiania. Statusy samej awizacji opisuje strona o statusach w programie awizacyjnym. System nie gwarantuje też, że każdy dokument powstanie w ERP. Pytanie, kto i w jakim czasie podejmuje decyzję, zostaje po stronie organizacji. Kolejkę i jej wpisy pilnuje monitor opisany na stronie o monitorze kolejki ERP, a ogólne wzorce zapytań T-SQL pokazują artykuły o idempotencji wysyłki i o zapisie błędu przed ROLLBACK. Szerszy opis połączenia awizacji z ERP znajduje się na stronach o integracjach awizacji z programami ERP i o łączeniu systemu awizacji z ERP.

Cztery pytania do analizy przed wdrożeniem podobnych reguł

• Czy ERP w Twojej firmie pozwala sprawdzić, czy dokument o danym opisie lub identyfikatorze już powstał?
• Kto w firmie podejmuje decyzję, gdy stan dokumentu jest nieznany, i w jakim czasie?
• Co jest groźniejsze w Twoim procesie: podwójne przyjęcie czy dokument, który powstał, a magazyn o tym nie wie?
• W jaki sposób magazyn ma być poinformowany, że nie wolno przyjąć towaru ręcznie?