Transakcje YMS to zbiór plików aspx i skryptów z folderu \role_maw\, obsługujących awizacje transportu oraz zarządzanie placem manewrowym. Obejmują rejestrację wizyt, rezerwację okien czasowych, obsługę bramy, zmianę statusów, dyspozycje na placu oraz pracę na terminalach mobilnych.
Zakres modułu YMS
Moduł YMS odpowiada za wszystko, co dzieje się z pojazdem od momentu zaplanowania wizyty do chwili opuszczenia terenu zakładu. To obszar szerszy niż sama rezerwacja terminu - obejmuje również ruch na placu manewrowym, obsługę bramy wjazdowej i rejestr osób odwiedzających zakład.
Transakcje tworzące ten moduł można podzielić na pięć grup, które odpowiadają kolejnym etapom obsługi wizyty:
- Rejestracja awizacji - zaplanowanie wizyty i rezerwacja okna czasowego.
- Obsługa statusów - odnotowanie przyjazdu, wjazdu i wyjazdu pojazdu.
- Zarządzanie placem - przypisanie miejsca postojowego i przemieszczanie pojazdów.
- Praca mobilna - te same czynności wykonywane na terminalu przez portiernię.
- Konfiguracja - kalendarze, użytkownicy i słowniki modułu.

Jeden moduł, kilka obszarów pracy
Menu po lewej stronie pokazuje strukturę całego modułu - od nowej awizacji, przez kalendarze i rejestry, po zarządzanie placem oraz asystenta bramy.
YMS, VSS.net i folder role_maw
Przy pierwszym kontakcie z modułem łatwo pogubić się w nazwach, bo w dokumentacji i w strukturze plików występują trzy różne określenia tego samego obszaru.
| Nazwa | Gdzie występuje | Znaczenie |
|---|---|---|
| YMS | Materiały produktowe, obecne nazewnictwo | Yard Management System - awizacje wraz z zarządzaniem placem |
| VSS.net | Starsze opisy, nazwy niektórych skryptów | Wcześniejsze oznaczenie produktu awizacyjnego |
| role_maw | Struktura folderów na serwerze | Katalog, w którym fizycznie zapisane są transakcje modułu |
Rozbieżność jest historyczna i nie oznacza różnych funkcji. Warto o niej pamiętać przy przeszukiwaniu dokumentacji: skrypt o nazwie zawierającej człon vss należy do tego samego modułu co plik z przedrostkiem maw. Ogólną zasadę grupowania plików w katalogi ról opisuje materiał o architekturze transakcji.
Rejestracja i edycja awizacji
Podstawowa ścieżka zaczyna się od utworzenia awizacji. Odpowiada za nią formularz tworzenia i edycji awizacji, w którym wskazuje się obiekt, magazyn, bramę oraz dzień i wolne okno czasowe. Mechanizm samych slotów, wraz z podziałem doby na przedziały przypisane do konkretnej bramy, opisuje szczegółowo materiał o oknach czasowych i awizacji dokowej.
Obok pojedynczej rezerwacji moduł obsługuje kilka wariantów szczególnych:
maw_events_ins.js- dopisanie awizacji w podstawowym trybie.maw_events_cyk- awizacje cykliczne dla stałych kursów powtarzanych w tych samych dniach.maw_events_del.js- anulowanie awizacji wraz z odnotowaniem przyczyny.maw_sko_awiz.js- dopasowanie dostępnych okien czasowych do godzin pracy magazynu.maw_events_ins_ktr_aso- rozszerzenie formularza o dane asortymentowe.
Ostatnia pozycja z tej listy bywa niedoceniana przy wdrożeniu. Informacja o rodzaju ładunku podana już na etapie rezerwacji pozwala magazynowi przygotować właściwe zasoby, zanim pojazd ruszy w trasę.
Statusy i obsługa bramy
Zarejestrowana awizacja zmienia stan wraz z postępem wizyty. Za aktualizację statusu odpowiadają dwie ścieżki: praca z poziomu zestawienia oraz szybka zmiana przez skanowanie.
Pierwsza z nich realizowana jest w rejestrze awizacji danego oddziału i sprawdza się przy obsłudze biurowej. Druga, opisana na stronie zmiany statusu przez skanowanie, przeznaczona jest dla bramy - operator odczytuje kod i status zmienia się bez wypełniania formularza, co przy kilkudziesięciu pojazdach dziennie realnie skraca kolejkę przed wjazdem.
Moduł przewiduje też dwa przypadki wykraczające poza standardową dostawę. Pierwszy to wjazdy nieawizowane, czyli rejestracja pojazdu, który pojawił się bez wcześniejszej rezerwacji. Drugi to księga gości - rejestr wizyt osób i pojazdów niezwiązanych z dostawami towaru, prowadzony na bramie na potrzeby kontroli dostępu do zakładu.
Zarządzanie placem
Po wjeździe pojazd staje się elementem ruchu na placu manewrowym. Ten obszar obsługuje grupa transakcji Yard Management, w której podstawową rolę pełni podgląd transportów na placu wraz z widokiem szczegółów pojedynczej wizyty.
Przypisaniem stanowiska i przemieszczaniem pojazdów zarządza formularz dyspozycji dla ramp i miejsc postojowych. Wydana dyspozycja zmienia stan w rejestrze parkowania, a co za tym idzie także obraz na planie graficznym - sposób budowy takiego planu, wraz z nanoszeniem miejsc postojowych na zdjęcie lotnicze obiektu, opisuje materiał o wizualizacji parkingu.
Uzupełnieniem są transakcje obsługujące przemieszczenia wewnątrz zakładu (yard_transport_wew) oraz rejestr kontenerów. W instalacjach, w których wykorzystywane są powiadomienia, dyspozycja może wywołać wysyłkę wiadomości do kierowcy.
Warto zwrócić uwagę na relację między tymi trzema warstwami, bo bywa źródłem nieporozumień przy wdrożeniu. Rejestr parkowania jest źródłem prawdy - to w nim zapisany jest stan każdego stanowiska. Plan graficzny stanowi wyłącznie warstwę prezentacji tego stanu, a dyspozycja jest poleceniem, które ten stan zmienia. Konsekwencja praktyczna jest taka, że pojazd przestawiony fizycznie na placu, ale bez wydania dyspozycji w systemie, pozostanie na planie w starym miejscu. Dyscyplina rejestrowania zdarzeń decyduje więc o wiarygodności całego obrazu bardziej niż staranność, z jaką narysowano plan.
Z tego samego powodu przy uruchamianiu modułu warto zacząć od ustalenia, kto i w którym momencie odnotowuje poszczególne zdarzenia. Jeśli odpowiedzialność za zmianę statusu nie jest jednoznacznie przypisana, rejestr szybko rozjeżdża się ze stanem faktycznym, a użytkownicy przestają mu ufać.
Praca na urządzeniach mobilnych
Portiernia i ochrona rzadko pracują przy biurku. Dla nich przewidziano osobną grupę transakcji przeznaczonych na terminale i telefony z systemem Android:
android_maw_ins- dopisanie awizacji z poziomu urządzenia mobilnego.android_maw_lista- lista wizyt w układzie tabelarycznym dopasowanym do małego ekranu.android_maw_szukaj- wyszukiwanie awizacji, na przykład po numerze rejestracyjnym.maw_android_awizacja_mobile- kolorowanie statusów awizacji na liście mobilnej.
Kolorowanie statusów z ostatniej pozycji to drobiazg o dużym znaczeniu praktycznym - pozwala ocenić stan wizyty jednym spojrzeniem, bez odczytywania opisu tekstowego na niewielkim wyświetlaczu terminala. Przy pracy w rękawicach, w słońcu albo o zmierzchu ma to znaczenie większe, niż wynikałoby z samego opisu funkcji.
Transakcje mobilne nie są osobnym systemem, lecz innym widokiem na te same dane. Awizacja dopisana na terminalu pojawia się natychmiast w rejestrze dostępnym w przeglądarce, a zmiana statusu wykonana przy biurku jest widoczna na urządzeniu portierni. Wspólną warstwą jest baza danych platformy, a kanałem komunikacji dla aplikacji mobilnych - interfejs WebAPI.
Transakcje konfiguracyjne
| Grupa | Przykładowe transakcje | Kto korzysta |
|---|---|---|
| Rejestracja awizacji | maw_events_ins, maw_events_ins_ktr, maw_events_cyk, maw_events_del | Przewoźnik, dział logistyki |
| Statusy i brama | maw_ach, maw_events_scan, maw_events_ins_yms, maw_events_ins_vss | Portiernia, ochrona |
| Zarządzanie placem | yard_view, yard_view_details, yard_transport_wew, maw_events_dyspozycja | Dyspozytor, brygadzista |
| Aplikacje mobilne | android_maw_ins, android_maw_lista, android_maw_szukaj | Portiernia w ruchu |
| Konfiguracja | j_kalendarz_maw, maw_users, maw_sko_mam, maw_sko_awiz | Administrator, wdrożeniowiec |
Zestawienie powyżej warto potraktować jako mapę wdrożenia. W typowym projekcie uruchamia się je w kolejności odpowiadającej wierszom tabeli: najpierw konfiguracja kalendarzy i użytkowników, potem rejestracja awizacji, następnie obsługa bramy, a na końcu - gdy proces działa - zarządzanie placem i praca mobilna. Odwrócenie tej kolejności zwykle kończy się poprawianiem ustawień na działającym już procesie.
Ostatnia grupa nie jest używana w codziennej pracy operacyjnej, lecz decyduje o zachowaniu całego modułu. Należą do niej transakcja kalendarza awizacji (j_kalendarz_maw), zarządzanie użytkownikami modułu (maw_users) oraz skorowidze specyficzne dla awizacji (maw_sko_mam).
Konfiguracja ta uzupełnia ustawienia ogólne platformy. Parametry globalne, konta i słowniki definiuje się w module administratora, natomiast układ menu i paski poleceń nad zestawieniami - w konfiguratorze. Dzięki temu dopasowanie modułu awizacyjnego do procesu konkretnego zakładu nie wymaga zmian w kodzie transakcji.
Podsumowanie
Transakcje YMS obejmują pełny cykl obsługi wizyty: rezerwację okna czasowego, rejestrację przyjazdu na bramie, zmianę statusów, przypisanie miejsca na placu, dyspozycje przemieszczenia i wyjazd. Wszystkie zapisane są w folderze \role_maw\, a moduł występuje w dokumentacji zamiennie pod nazwami YMS i VSS.net.
Dla wdrożeniowca praktyczny wniosek jest taki, że większość potrzeb da się pokryć konfiguracją istniejących transakcji - od zakresu pól formularza awizacji, przez długość okien czasowych, po sposób prezentacji statusów na terminalu mobilnym.