Słownik statusów niesie tylko opis i kolejność, a warunków przejść w nim nie ma. W opisywanym wdrożeniu przycisk na pasku kierownika otwiera stronę, która uruchamia zapytanie strażnika. Zapytanie zwraca adres akcji z instrukcją UPDATE albo adres komunikatu odmowy, zależnie od bieżącego statusu zlecenia.
Przejścia statusu zlecenia w konfiguracji wyglądają w opisywanym wdrożeniu tak: opis i kolejność statusu zlecenia wydania to wpis słownika, a cztery przejścia zlecane z paska kierownika to przycisk ze strażnikiem i jedna instrukcja UPDATE z wpisem do historii. Kierownik magazynu wybiera te przejścia przyciskami paska narzędzi nad zestawieniem zleceń. Zestawień jest wiele, bo większość statusów ma własne zestawienie.
Statusy etapów ustawiają zapytania wołane z terminala, bez strażnika, a przycisk „Zmień stan” otwiera formularz z listą wszystkich aktywnych statusów słownika i nie sprawdza statusu źródłowego. To granica opisu: artykuł dotyczy wyłącznie przejść zlecanych z paska kierownika i ich strażników.
Dla Twojej firmy ważne jest, które przejścia statusu zlecenia ma zlecać człowiek i czy takie przejście powinno mieć strażnika. Pytania na końcu strony pomagają to ustalić.
Słownik niesie opisy statusów, a oczekujące zlecenie nie ma statusu
Słownik statusów zlecenia wydania to wpisy ogólnego słownika konfiguracji, w których kod łączy się z opisem i kolejnością. Opisy obejmują etapy od kompletacji do wysyłki oraz anulowanie. Sam słownik nie niesie warunków przejść.
Zamówienie bez statusu jest oczekujące. Lista oczekujących filtruje po pustym statusie na widoku bez złączenia ze słownikiem. Widok z opisami statusów łączy się ze słownikiem złączeniem wewnętrznym, więc zamówień bez statusu nie pokazuje. To samo zlecenie bez statusu widać zatem na liście oczekujących, a w widoku z opisami statusów go nie ma.
- Status ustawiony: zlecenie ma kod ze słownika, a opis statusu na listach pochodzi ze słownika.
- Brak statusu: zlecenie jest oczekujące i trafia na listę oczekujących.
Opis statusu na listach pochodzi ze słownika, a większość statusów ma listę
Opis statusu na listach pochodzi ze słownika przez złączenie po kodzie. Widok agreguje przy tym linie zlecenia, więc lista pokazuje liczbę pozycji i sumę ilości na zlecenie. Większość statusów ma własne zestawienie na tym samym widoku, z innym warunkiem na kolumnie statusu.
Zestawienia zbierają statusy w grupy. Lista „w realizacji” zbiera kilka statusów naraz, a lista zrealizowanych kilka innych. Obie czytają ten sam widok i różnią się warunkiem na kolumnie statusu. Trzy zestawienia różnic ilości między etapami opisuje artykuł o zestawieniach różnic.
- Lista „w realizacji”: zbiera kilka statusów naraz.
- Lista zrealizowanych: zbiera kilka innych statusów.
Statusy etapów ustawiają zapytania wołane z terminala, bez strażnika
Statusy etapów ustawiają zapytania wołane z terminala: jedno UPDATE obejmuje wszystkie wiersze zlecenia, a w tym samym wsadzie powstaje wpis do historii z loginem operatora. Wejście do zbiórki ustawia status „w trakcie kompletacji” i operatora, a wejście do pakowania i do załadunku ma własne statusy. Status jest więc jeden na zlecenie, a nie na pozycję. Terminal ustawia te statusy bez sprawdzania statusu poprzedniego.
Cztery przejścia z paska i przywrócenie anulowanego mają strażnika w konfiguracji; terminal i formularz zmiany stanu go nie mają, podobnie jak przyciski flag.
Zakończenie pakowania na terminalu ustawia status „zapakowano”. Gdy na liście zostały sztuki, terminal pyta „Nie pobrano wszystkich pozycji z palety. Czy mimo to zakończyć zlecenie?” i po tym pytaniu ustawia status „zapakowano niekompletne”.
Anulowanie z terminala ustawia status „anulowano” tylko wtedy, gdy nie istnieje żaden ruch zbiórki zlecenia. Ekran proponuje je po komunikacie „Żadna pozycja nie została dodana. Czy chcesz oznaczyć zamówienie jako anulowane?”. Co dzieje się ze zleceniem oczekującym po stronie terminala, opisuje artykuł o kolejce zleceń na terminalu.
Cztery przejścia z paska to przycisk ze strażnikiem i jedna instrukcja UPDATE
Przejście zlecane przez kierownika zaczyna się od przycisku paska narzędzi zestawienia. Przycisk otwiera stronę, która uruchamia zapytanie strażnika. Zapytanie zwraca adres akcji albo adres komunikatu odmowy, zależnie od bieżącego statusu zlecenia, a strona przekierowuje na ten adres.
Cztery przejścia mają własnych strażników, a zestawia je tabela poniżej. Wynikiem przywrócenia jest brak statusu, czyli zlecenie oczekujące. Osobny strażnik przywraca tylko anulowane.
| Przycisk | Statusy, z których wolno | Status po zmianie |
|---|---|---|
| „Do pakowania” | częściowo skompletowane albo skompletowane | do pakowania |
| „Do wysyłki” | zapakowano albo zapakowano niekompletne | gotowe do wysyłki |
| „Do wysyłki detal” | częściowo skompletowane albo skompletowane w drodze wydania sztuka po sztuce | gotowe do wysyłki w drodze wydania sztuka po sztuce |
| „Przywróć” (lista „w realizacji”) | częściowo skompletowane albo skompletowane w obu drogach | brak statusu, czyli zlecenie oczekujące |
| „Przywróć” (listy inne niż „w realizacji”) | tylko anulowano | brak statusu |
Akcja jest wpisem konfiguracji. Treść pytania i komunikatu leży w konfiguracji akcji, podobnie jak treść wpisu historii. Strona akcji wykonuje UPDATE, a potem zapisuje dziennik i dopisuje wpis historii. Sprawdzenie strażnika i UPDATE to dwa osobne żądania, a warunek dotyczący statusu leży w zapytaniu strażnika, nie w instrukcji akcji.
- Instrukcja UPDATE: jedna, po numerze zlecenia.
- Pytanie potwierdzające: tekst pytania, które strona zadaje, zanim wykona UPDATE.
- Tekst przycisku i komunikat: etykieta przycisku oraz komunikat po zmianie.
- Wpis historii: tytuł i treść wpisu.
Przykład (dane wymyślone). Zlecenie ma status „Skompletowane” i stoi na liście zleceń w realizacji. Kierownik zaznacza je i wybiera „Do pakowania”. Zapytanie strażnika sprawdza status i zwraca adres akcji, więc strona pyta o potwierdzenie i wykonuje jedną instrukcję UPDATE. W historii zostaje wpis z loginem kierownika, a zlecenie dostaje status „do pakowania”. Gdyby zlecenie miało status „Zapakowano”, strażnik zwróciłby adres komunikatu odmowy i nic by się nie zmieniło.
Przyciski przejść to wiersze menu przypięte do zestawienia
Przyciski przejść to wiersze menu przypięte do zestawienia nazwą widoku. Wiersz niesie adres strony i parametr z nazwą strażnika. Ten sam przycisk jest powielony dla wielu zestawień, a na liście „w realizacji” stoją obok siebie cztery przejścia.
Od dwóch flag zależy, czy stanowisko wysyłki przyjmie zlecenie, a ten mechanizm opisuje artykuł o bramie dwóch flag. Wybór drogi zlecenia i status końcowy wysyłki opisuje artykuł o torach zlecenia i statusie końcowym wysyłki. Statusem jako warunkiem kontroli przed wysyłką zajmuje się strona o statusie jako warunku kontroli.
Makieta poniżej pokazuje listę zleceń w realizacji z paskiem sześciu przycisków nad siatką, w której status widać w ostatniej kolumnie. Cztery z tych przycisków to przejścia z paska, a piąty to „Zmień stan”.
Formularz zmiany stanu nie sprawdza statusu źródłowego
Przycisk „Zmień stan” otwiera formularz z jednym polem. Pole jest listą wszystkich aktywnych statusów słownika, czyli czyta ten sam słownik, który niesie opisy statusów. Zdarzenie formularza dopisuje do historii wpis o zmianie statusu. W definicji formularza nie ma warunku na status źródłowy.
- Przejście z paska: strażnik sprawdza status zlecenia, zanim strona wykona akcję.
- Zmień stan: formularz nie sprawdza statusu źródłowego.
O wyniku zmiany statusu decyduje więc droga, którą zmiana nadeszła. Terminal ustawia status bez strażnika, a przycisk paska ustawia go przez strażnika. Formularz pozwala wybrać status ze słownika. W opisywanym wdrożeniu strażnik jest zapytaniem konfiguracji platformy, bez funkcji. Strażnika zapisanego jako funkcja w T-SQL opisuje osobny artykuł: strażnik w T-SQL.
Cztery pytania do analizy w Twojej firmie
Odpowiedzi na te pytania nie są faktami z opisywanego wdrożenia, tylko tematami do ustalenia w Twojej firmie.
- Które przejścia statusu zlecenia ma zlecać człowiek, a które mają ustawiać terminale?
- Czy przejście zlecane przez kierownika powinno mieć strażnika, który sprawdza bieżący status?
- Które opisy statusów mają być wpisem słownika, a które warunkiem wpisanym na stałe w zapytaniach i na listach?
- Czy akcja zmiany statusu ma sama powtarzać warunek strażnika, czy wystarczy osobne sprawdzenie przed akcją?