Awizacje VSS.net - moduł planowania dostaw i ramp

Zakres modułu awizacji w Studio VSS.net

Awizacje są w Studio VSS.net osobną sekcją menu, obok kartotek, modułu Yard Management, narzędzi bramy (Gate Assistant) i raportów w sekcji Informacje. Sekcja obejmuje cały cykl zgłoszenia: od założenia awizacji przez dostawcę, przez kalendarz ramp, aż po wyjazd pojazdu z terenu zakładu. Moduł działa samodzielnie. Integracja z WMS rozszerza go o przekazanie danych do przyjęcia, ale nie jest warunkiem uruchomienia.

Układ menu odzwierciedla kolejność pracy. Najpierw powstaje awizacja, potem trafia do kalendarza, a w dniu dostawy przechodzi przez bramę i magazyn. Każdy etap ma własny widok, więc ochrona i magazynier pracują na tych samych danych, ale na innych ekranach.

Szczegółowy opis sekcji przedstawia strona produktu Studio VSS.net. Słowniki, z których korzysta moduł, w tym kartoteki przewoźników i magazynów, opisuje artykuł o kartotekach w systemie VSS.net.

Zakładanie awizacji przez dostawcę

Awizację zakłada dostawca albo przewoźnik przez przeglądarkę, bez instalowania oprogramowania. Kreator zaczyna od wyboru obiektu, na przykład centrum logistycznego, a w drugim kroku od wyboru magazynu w tym obiekcie. Dopiero po tych dwóch decyzjach system pokazuje okna czasowe, bo dostępność ramp zależy od magazynu.

W ostatnim kroku dostawca podaje numer rejestracyjny pojazdu i numer zamówienia. Dane kierowcy uzupełnia numer telefonu. Te pola wracają później w kalendarzu i na bramie, dlatego ich jakość decyduje o przydatności całego systemu. Numer rejestracyjny jest też kluczem, po którym kamera ANPR dopasuje pojazd do awizacji.

Awizacja cykliczna

Dostawca, który przyjeżdża co wtorek i piątek o tej samej porze, nie musi zakładać każdej wizyty osobno. Awizacja cykliczna wskazuje dni tygodnia, a system rezerwuje w nich okna na kolejne tygodnie. Lista „Awizacje Cykliczne” pozwala później zmienić albo zakończyć taki szablon.

Kierowca może pracować także na telefonie. Obsługę z urządzeń mobilnych opisuje artykuł o aplikacji awizacyjnej, a wariant dla terminali z systemem Android przedstawia tekst o programie do awizacji na Android. Komunikaty dla kierowców z innych krajów omawia artykuł o wielojęzycznej komunikacji VSS z kierowcami.

Kalendarz ramp i widoki harmonogramu

Kalendarz ma cztery widoki zestawione w tabeli na końcu tej sekcji. Agenda sprawdza się przy odprawie porannej, bo pokazuje listę awizacji w kolejności godzin. Oś czasu lepiej oddaje obciążenie ramp, bo rysuje okna obok siebie i ujawnia nakładające się rezerwacje.

Każdy wpis zawiera nazwę kontrahenta, numer zamówienia, numer awizacji, numer rejestracyjny auta i telefon kierowcy. Kolor wpisu odpowiada obiektowi, a legenda pod kalendarzem objaśnia kolory, gdy jeden użytkownik obsługuje kilka lokalizacji. Kalendarze można dzielić na sekcje według obiektów i ramp, co opisuje artykuł o funkcjach kalendarzy w VSS.net.

Okna czasowe i pojemność ramp

O tym, ile okien system udostępni, decydują parametry globalne ustawiane przez administratora. Należą do nich długość okna czasowego, godziny pracy magazynu, limity czasowe dla awizacji i maksymalna liczba jednoczesnych transportów na rampie. Zasady zatwierdzania określają, czy rezerwacja w wolnym oknie potwierdza się sama, czy czeka na dyspozytora.

• Długość okna - czas zarezerwowany na rampie dla jednej awizacji, zależny od rodzaju ładunku i sposobu rozładunku.
• Godziny pracy magazynu - granice, poza którymi kalendarz nie udostępnia okien.
• Maksymalna liczba jednoczesnych transportów - pojemność rampy w tym samym przedziale czasu.
• Zasady zatwierdzania - automatyczne potwierdzenie albo akceptacja przez dyspozytora.

Pojemność rampy wymaga ochrony przed wyścigiem. Dwóch dostawców może w tej samej sekundzie wybrać ostatnie wolne miejsce w oknie. Jeżeli aplikacja najpierw policzy rezerwacje, a potem osobno zapisze nową, obaj dostaną potwierdzenie. Sprawdzenie i zapis muszą przebiec w jednej transakcji z blokadą zakresu. Poniższa procedura jest przykładem mechanizmu, nazwy tabel są poglądowe.

CREATE PROCEDURE dbo.usp_BookDockSlot
    @DockId    int,
    @SlotStart datetime2(0),
    @SlotEnd   datetime2(0),
    @AdviceId  int
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;

    BEGIN TRANSACTION;

    DECLARE @Capacity int, @Taken int;

    SELECT @Capacity = MaxParallel
      FROM dbo.Dock
     WHERE DockId = @DockId;

    SELECT @Taken = COUNT(*)
      FROM dbo.DockBooking WITH (UPDLOCK, HOLDLOCK)
     WHERE DockId = @DockId
       AND SlotStart < @SlotEnd
       AND SlotEnd > @SlotStart;

    IF @Taken >= @Capacity
    BEGIN
        ROLLBACK TRANSACTION;
        THROW 50001, N'Brak wolnej pojemności rampy w wybranym oknie.', 1;
    END;

    INSERT INTO dbo.DockBooking (DockId, SlotStart, SlotEnd, AdviceId)
    VALUES (@DockId, @SlotStart, @SlotEnd, @AdviceId);

    COMMIT TRANSACTION;
END;

Podpowiedź HOLDLOCK działa jak poziom SERIALIZABLE dla tego odczytu i zakłada blokady zakresu kluczy. Druga sesja, która chce dopisać rezerwację na tę samą rampę, czeka do końca pierwszej transakcji i dopiero wtedy liczy rezerwacje. UPDLOCK zapobiega zakleszczeniu dwóch sesji, które odczytały ten sam zakres. Opis obu podpowiedzi zawiera dokumentacja table hints w Microsoft Learn.

Reguła: blokada zakresu wymaga indeksu na (DockId, SlotStart). Bez niego SQL Server zablokuje całą tabelę rezerwacji.

CREATE NONCLUSTERED INDEX IX_DockBooking_Dock_Slot
    ON dbo.DockBooking (DockId, SlotStart)
    INCLUDE (SlotEnd);

Indeks złożony zaczyna się od kolumny rampy, bo każde zapytanie o pojemność dotyczy jednej rampy. Kolumna końca okna w klauzuli INCLUDE pozwala sprawdzić warunek nakładania bez sięgania do indeksu klastrowego. Blokada zakresu obejmuje wtedy tylko rezerwacje jednej rampy, a dostawcy rezerwujący inne rampy nie czekają na siebie nawzajem.

Warunek nakładania się okien liczy wszystkie rezerwacje, które przecinają nowe okno. Przy oknach o różnej długości to ostrożne przybliżenie, bo dwie rezerwacje mogą przecinać okno w różnych minutach. Dla kalendarza z oknami o stałej długości wynik jest dokładny. Zasady doboru długości okien opisuje artykuł o oknach czasowych, a usługę zarządzania nimi po stronie producenta przedstawia strona zarządzanie oknami czasowymi.

Spóźnienia i przesunięcia okien

Kalendarz działa tylko wtedy, gdy obiekt ma jasną politykę spóźnień. Administrator ustala dla bramy maksymalny czas oczekiwania pojazdu, a limity czasowe awizacji określają, do kiedy dostawca może zmienić albo anulować zgłoszenie. Po przekroczeniu tych granic decyzję podejmuje logistyka, a nie kierowca przy szlabanie.

W praktyce przyjmuje się dwa progi. Niewielkie spóźnienie mieści się w buforze na końcu okna i nie wymaga żadnej akcji. Spóźnienie większe od bufora zwalnia okno dla innych dostaw, a pojazd czeka na wolne miejsce na placu albo dostaje nowe okno w kalendarzu. Oba progi warto opisać w regulaminie dla przewoźników, bo tylko wtedy odmowa wjazdu na umówioną godzinę nie jest zaskoczeniem.

Przesunięcie okna przez dostawcę oznacza w bazie anulowanie starej rezerwacji i założenie nowej w jednej transakcji. Gdyby oba kroki wykonać osobno, w przerwie między nimi inny dostawca mógłby zająć zwolnione miejsce, a przesunięcie zakończyłoby się utratą obu terminów.

Role użytkowników i zakres uprawnień

Administrator tworzy konta i przypisuje im role wymienione w tabeli poniżej. Rola niesie zestaw uprawnień, na przykład prawo do edycji awizacji albo do zatwierdzania zgłoszeń. Dostęp można dodatkowo zawęzić do konkretnych ramp albo do wybranych kontrahentów. Część ustawień globalnych pozostaje zarezerwowana dla supervisora z najwyższymi uprawnieniami.

Konfigurację ról i kluczy API opisuje artykuł o module Administrator w programie VSS.net. W bazie danych rekordy mają kolumnę statusu ACH, w której 0 oznacza bufor, a 1 rekord zatwierdzony. Wartość X oznacza rekord anulowany. Awizacja w buforze nie blokuje jeszcze okna w oczach innych użytkowników, dopóki nie zostanie zatwierdzona zgodnie z zasadami obiektu.

Obsługa awizacji na bramie

W dniu dostawy awizacja trafia na listę „Brama - transporty oczekujące na wjazd”. Pracownik ochrony ma tam do dyspozycji podgląd zgłoszenia, podpis kierowcy, wydruk przepustki oraz zezwolenie na wjazd. Podpis składa się palcem albo rysikiem na ekranie, a system zapisuje go razem z nazwiskiem wpisanym w polu pod obrazem.

Bramę można połączyć z czytnikiem tablic rejestracyjnych albo z terminalem samoobsługowym. Kierowca rejestruje wtedy przyjazd bez udziału ochrony, a system porównuje numer z listą awizacji na dany dzień. Pojazd, który wjechał, dostaje stanowisko postojowe i pojawia się na mapie opisanej w artykule o wizualizacji zajętości miejsc parkingowych.

Pojazd bez awizacji nie jest odsyłany automatycznie. Ochrona rejestruje go jako wjazd nieawizowany, a logistyka decyduje, czy znajdzie się dla niego okno. Taki wpis też trafia do historii, więc raport pokazuje, jaki odsetek ruchu omija system.

Etapy wizyty w kolejnych widokach

Jedna awizacja przechodzi przez kilka list menu. Każde przejście zapisuje czas i użytkownika, dlatego historia wizyty pozwala odtworzyć, gdzie pojazd czekał najdłużej.

Raporty i wskaźniki KPI

Zapisane czasy etapów zasilają pozycję KPI oraz raporty w sekcji Informacje. Raporty pokazują między innymi średni czas obsługi przyjęcia i liczbę awizacji obsłużonych przez poszczególnych magazynierów. Zestawienie awizacji bram w układzie tygodniowym ujawnia dni, w których rampy są przeciążone, oraz godziny, w których stoją puste.

• Średni czas obsługi przyjęcia - różnica między rozpoczęciem a zakończeniem obsługi na rampie, uśredniona dla okresu.
• Awizacje na magazyniera - liczba wizyt obsłużonych przez jedną osobę, pomocna przy planowaniu obsady zmian.
• Obciążenie bram w tygodniu - liczba awizacji na bramę w kolejnych dniach, podstawa do przesuwania dostawców na słabsze dni.
• Odsetek wjazdów nieawizowanych - udział ruchu, który ominął kalendarz, liczony z historii wizyt.

Integracja awizacji z WMS i ERP

VSS.net wymienia dane z ERP przez połączenia API i EDI. Źródłem awizacji może być zamówienie zakupu albo awizo ASN wysłane przez dostawcę. Zatwierdzona awizacja trafia do WMS jako oczekujące zlecenie przyjęcia z listą pozycji, a zmiany statusów w WMS, na przykład zakończenie rozładunku, wracają do VSS.net i dalej do ERP. Mechanizm opisuje szerzej artykuł o tym, jak VSS łączy się z WMS i ERP przy przyjęciach.

Po stronie magazynu najważniejszy jest moment przekazania. Magazynier po przyjeździe pojazdu otwiera zlecenie, które już zawiera pozycje i ilości z zamówienia. Weryfikację ilości z etykietami SSCC oraz obsługę rozbieżności omawia tekst o awizacjach dostaw do magazynu od strony przyjęcia towaru.

• Kierunek ERP do VSS.net - zamówienia zakupu i awiza ASN, z których powstają propozycje awizacji dla dostawców.
• Kierunek VSS.net do WMS i ERP - zatwierdzone awizacje jako zlecenia przyjęcia oraz statusy kolejnych etapów wizyty.

Komunikat integracyjny i powtórzenia

Komunikat z ERP do systemu awizacji zawiera zwykle identyfikator dokumentu źródłowego, dostawcę, magazyn docelowy i pozycje z ilościami. Poniższy przykład w formacie JSON ma charakter poglądowy i nie opisuje rzeczywistego interfejsu produktu.

{
  "sourceSystem": "ERP",
  "sourceDocument": "ZZ/2026/09/0412",
  "supplierCode": "DOST-0187",
  "warehouseCode": "MAG-01",
  "plannedDate": "2026-10-02",
  "lines": [
    { "sku": "5901234123457", "quantity": 480, "unit": "szt" },
    { "sku": "5901234123464", "quantity": 12, "unit": "pal" }
  ]
}

Pole sourceDocument pełni rolę klucza idempotencji. Jeżeli ERP wyśle ten sam dokument drugi raz, na przykład po przekroczeniu limitu czasu połączenia, system awizacji zaktualizuje istniejący rekord zamiast tworzyć duplikat. W bazie wystarcza do tego unikalny indeks na parze system źródłowy i numer dokumentu.

Moduł sprawdza się także w organizacjach bez własnego WMS. Magazyn prowadzący ewidencję w starszym systemie korzysta wtedy z kalendarza i obsługi bramy, a dane o przyjęciu przepisuje z listy awizacji. Działanie całego systemu można sprawdzić w demo awizacji Studio VSS.net. Ogólny kontekst systemów zarządzania placem przedstawia artykuł o systemie YMS.