Elastyczność aplikacji awizacyjnej w Studio VSS.net polega na tym, że administrator dopasowuje reguły rezerwacji, formularze, role i powiadomienia do organizacji pracy obiektu bez ingerencji w kod programu. Reguły ustawia się osobno dla obiektu, kalendarza, rampy i kontrahenta, a na platformie GT konfiguracja działa bez restartu.
Konfiguracji podlegają długość okna czasowego, liczba ramp, zestaw wymaganych pól oraz zakres danych widocznych dla przewoźnika. Sztywny harmonogram, identyczny dla wszystkich magazynów, rzadko odpowiada rzeczywistemu obciążeniu ramp, dlatego formularze awizacji oraz zasady wjazdu ustawia się osobno dla każdego obiektu, a zestawy raportów dobiera się do ról. Jeden system obsługuje wtedy magazyny o różnej organizacji pracy i różnym natężeniu ruchu pojazdów.
Samoobsługa dostawców w zakładach produkcyjnych zastępuje ręczne ustalanie terminów: przewoźnik sam rezerwuje okno czasowe na rozładunek i potwierdza szczegóły transportu przed przyjazdem. Porządkuje to obieg informacji, a moduły systemu opisuje strona o modułach Studio VSS.net.
Co konfiguruje administrator w aplikacji awizacyjnej
Tabela zestawia dziewięć obszarów, w których administrator zmienia zachowanie systemu. Parametry można zmieniać w trakcie eksploatacji, a zmiany zapisują się z datą i nazwiskiem operatora, co ułatwia porównanie wyników przed korektą harmonogramu i po niej.
| Obszar | Co ustawia administrator | Gdzie to ustawia |
|---|---|---|
| Okna czasowe | Długość okna i limit jednoczesnych rozładunków; długość wynika z liczby palet i rodzaju pojazdu | Skorowidz okien czasowych i kalendarze |
| Kalendarze | Osobne kalendarze dla rodzajów transportu i obiektów wraz z widokiem domyślnym i uprawnieniami do edycji | Kartoteki, sekcja kalendarzy |
| Kalendarz pracy | Godziny otwarcia ramp i harmonogramy specjalne, w tym dni wolne | Kartoteki, kalendarze pracy |
| Formularz awizacji | Zestaw wymaganych pól i obowiązkowe załączniki dla rodzaju transportu | Konfiguracja formularza portalu |
| Skorowidze | Typy pojazdów, przyczyny odmowy wjazdu i anulowania oraz kraje i języki | Kartoteki, skorowidze |
| Reguły kontrahenta | Indywidualne okna czasowe i priorytety w kolejce do doków | Kartoteka kontrahentów |
| Role i widoki | Menu i raporty widoczne dla roli oraz zakres danych dla przewoźnika | Role programowe |
| Powiadomienia | Szablony SMS i e-mail oraz język komunikacji z kierowcą | Szablony powiadomień i pole awizacji |
| Brama | Zasady odprawy pojazdu i przypisanie bram do obiektów | Kartoteka bram i moduł Gate Assistant |
Reguły okien czasowych łączą się z danymi z formularza: system liczy czas obsługi z liczby palet, więc zmiana normy w skorowidzu zmienia długość okna przy kolejnych rezerwacjach. Zasady rezerwacji opisuje strona o oknach czasowych, a sposób, w jaki dynamiczne okna czasowe porządkują rozładunek, pokazuje osobny artykuł. Konfigurację wykonuje się w drugim etapie wdrożenia, który trwa 1-2 tygodnie, a harmonogram opisuje strona o wdrożeniu systemu awizacji etapami.
Portal samoobsługowy dla dostawców
Portal kontrahenta pokazuje wolne terminy, więc podwykonawca dopasowuje przyjazd do możliwości zakładu. System wymusza uzupełnienie wymaganych pól, na przykład numeru rejestracyjnego pojazdu i liczby palet, dzięki czemu magazyn dostaje komplet danych jeszcze przed pojawieniem się ciężarówki na bramie. Pełną listę pól formularza zawiera strona o wzorze awizacji dostawy i kierowcy.
Kierownik logistyki widzi statusy awizacji i obciążenie ramp w module Informacje, a wykorzystanie slotów pokazuje raport z filtrami. Dzięki temu korektę długości okna czy limitu rampy opiera się na zapisach z systemu.

Okna czasowe w module Informacje YMS - wykorzystanie slotów
Ekran Okna czasowe w sekcji Informacje modułu YMS pokazuje wykorzystanie slotów awizacyjnych. Dane można filtrować według rampy, kontrahenta, dnia lub tygodnia. Widok pomaga kierownikowi logistyki wykryć przeciążenia i dopasować liczbę okien do rzeczywistego ruchu.
Dokumenty i etykiety logistyczne w awizacji
Administrator wskazuje, które załączniki są obowiązkowe dla danego rodzaju transportu, a które opcjonalne. Dostawcy dołączają w portalu skany dokumentów, na przykład atestów lub listów przewozowych, więc dokumentacja trafia do działu logistyki przed fizycznym przyjazdem towaru i można ją wstępnie zweryfikować.
Jeśli dostawca stosuje etykiety logistyczne GS1, budowę etykiety i numer SSCC jednostki logistycznej określa standard etykiety logistycznej GS1. Numer SSCC można przekazać w uwagach lub w załączonym dokumencie awizacji, a automatyczne mapowanie danych z etykiet wymaga projektu integracyjnego. Ogólne zasady oznaczania opisuje także artykuł o etykietach logistycznych GS1, a dalszy przebieg przyjęcia obsługuje system magazynowy, na przykład program magazynowy WMS.net.
Zasady wjazdu i komunikacja z kierowcą
Zasady bezpieczeństwa na terenie zakładu ustala obiekt, a system pomaga je egzekwować: bramę obsługuje moduł Gate Assistant, a o numerze rampy i zmianie statusu kierowca dowiaduje się z wiadomości. Regulamin wjazdu i wytyczne BHP można przygotować na podstawie wzorów regulaminu dostaw i awizacji oraz instrukcji dla kierowcy na terenie magazynu.
Komunikaty do kierowcy idą w języku wybranym w polu awizacji, a kiosk przy bramie działa w pięciu wersjach językowych. Przy współpracy z zagranicznymi przewoźnikami znaczenie ma wielojęzyczna komunikacja z dostawcami i kierowcami oraz wiadomości e-mail i SMS z poziomu programu, które obejmują treść powiadomień i interfejs portalu.
Awizacja kierowcy obejmuje potwierdzenie terminu oraz przekazanie numeru rampy i informacji o zmianie statusu; proces z perspektywy kierowcy opisuje strona awizacja kierowcy.
Konfiguracja platformy GT plikami wczytywanymi na gorąco
Pakiet awizacji MAW na platformie GT korzysta z plików konfiguracji YAML oraz szablonów HTML ze skryptami JS, które aplikacja wczytuje na gorąco. Zmiana reguły nie wymaga restartu, więc obowiązuje od chwili wczytania pliku. Platforma ma natywną wielojęzyczność, dlatego dodanie kolejnego języka sprowadza się do pliku tłumaczeń i szablonów.
| Cecha | Platforma ST | Platforma GT |
|---|---|---|
| Zmiana konfiguracji | Wydanie wersji lub wgranie transakcji | Podmiana plików konfiguracji bez restartu |
| Format konfiguracji | Kartoteki i skorowidze w aplikacji | Pliki YAML oraz szablony HTML ze skryptami JS |
| Kolejna wersja językowa portalu | 80-100 godzin pracy, bo teksty są w kodzie stron | 8-10 godzin pracy: plik tłumaczeń i szablony |
| Wielojęzyczność | Wersje językowe wymagają prac w kodzie | Natywna wielojęzyczność |
Platformy opisuje szerzej strona o wymaganiach technicznych systemu awizacji, a wpływ wyboru platformy na koszt zawiera cennik systemu awizacji.
Granice elastyczności i prace wdrożeniowe
Nie wszystko ustawia administrator w interfejsie. Tabela pokazuje, które potrzeby załatwia konfiguracja, a które wymagają prac wdrożeniowych lub osobnego wariantu licencji.
| Potrzeba | Jak ją zrealizować |
|---|---|
| Zmiana długości okna lub limitu ramp | Administrator w skorowidzach i kalendarzach |
| Nowy rodzaj transportu lub powód opóźnienia | Administrator w skorowidzach |
| Nowe pole w formularzu awizacji | Prace wdrożeniowe; na platformie GT zmiana w szablonie HTML |
| Wymiana danych z systemem zewnętrznym | Projekt integracyjny przez REST API |
| Zmiana kodu źródłowego | Wariant Developer w abonamencie; licencja wieczysta nie daje dostępu do kodu |
Zasady licencjonowania i prawo do zmian w kodzie opisuje strona o licencjach oprogramowania.