System VSS.net - delegowanie awizacji na kontrahentów i przewoźników

Podział odpowiedzialności w systemie awizacyjnym

W tradycyjnym obiegu awizacja zaczyna się od telefonu albo wiadomości do dyspozytora magazynu. Dyspozytor szuka wolnego terminu, przepisuje dane pojazdu do arkusza i odsyła potwierdzenie. Każdy krok zabiera mu czas, a literówka w numerze rejestracyjnym wychodzi na jaw dopiero przy bramie.

System VSS.net zmienia ten podział pracy. Kontrahent albo przewoźnik zakłada awizację samodzielnie przez przeglądarkę i wybiera termin spośród wolnych okien. Magazyn zachowuje kontrolę, bo ustawia reguły obsługi oraz uprawnienia kont. Rozdział ról jest osią modułu opisanego w artykule o awizacjach VSS.net, a dane wszystkich modułów leżą we wspólnej bazie, którą omawia tekst o platformie VSS na jednej bazie SQL.

Reguła: partner wybiera termin, ale długość okna wynika z reguł magazynu, a nie z jego deklaracji.

Reguły i uprawnienia po stronie magazynu

Delegowanie nie oznacza oddania systemu. Konfigurację prowadzi administrator, a jej zakres opisuje sekcja o kontach kontrahentów poniżej. Zasady nadawania ról dla modułów VSS.net przedstawia artykuł o module Administrator. Dzięki temu kontrahent może zgłosić dyspozytorowi zbyt krótkie okno, ale nie potrafi go sam skrócić ani wydłużyć.

Po stronie dyspozytora zmienia się charakter pracy. Przestaje przyjmować zgłoszenia. Przegląda harmonogram i reaguje na wyjątki: wizytę, której reguła nie obejmuje, albo prośbę o termin poza godzinami pracy rampy. Zwykłe zgłoszenia nie wymagają jego rozmowy z partnerem, co skraca obsługę awizacji w dniach największego ruchu.

Automatyczne obliczanie czasu załadunku i rozładunku

Czas obsługi pojazdu jest daną wejściową dla całego harmonogramu. Gdy okno jest za krótkie, kolejny pojazd czeka na rampie. Gdy jest za długie, rampa stoi pusta. Według opisu produktu VSS.net oblicza przewidywany czas załadunku i rozładunku na podstawie ustalonych reguł oraz danych historycznych, więc dostawca nie zgaduje długości okna.

Reguła bazowa wiąże czas z rodzajem pojazdu i liczbą palet: stały narzut na podstawienie oraz minuty przypadające na paletę. Dane historyczne korygują ją tam, gdzie magazyn ma dość obserwacji. Przykład pokazuje ten mechanizm w T-SQL. Tabele DurationRule i VisitHistory są poglądowe i nie odwzorowują schematu produktu.

DECLARE @VehicleType tinyint = 2,
        @Pallets     smallint = 24,
        @Planned     int;

-- 1. reguła bazowa: narzut + minuty na paletę
SELECT @Planned = r.BaseMinutes + r.MinutesPerPallet * @Pallets
  FROM dbo.DurationRule AS r
 WHERE r.VehicleType = @VehicleType;

-- 2. korekta: średni czas z 50 ostatnich wizyt tego typu pojazdu
;WITH h AS (
    SELECT TOP (50) ActualMinutes
      FROM dbo.VisitHistory
     WHERE VehicleType = @VehicleType
     ORDER BY FinishedAt DESC
)
SELECT @Planned = CAST(AVG(CAST(ActualMinutes AS float)) AS int)
  FROM h
HAVING COUNT(*) >= 10;

SELECT @Planned AS PlannedMinutes;

Zapytanie zaczyna od reguły bazowej, a potem nadpisuje wynik średnią z ostatnich wizyt. Klauzula HAVING COUNT(*) >= 10 działa jak bezpiecznik. Przy mniejszej próbie zapytanie nie zwraca wiersza, a instrukcja SELECT przypisująca wartość zmiennej zostawia poprzednią wartość bez zmian, więc pozostaje reguła bazowa. Średnia jest wrażliwa na wizyty skrajne, dlatego w praktyce zastępuje się ją medianą albo obcina wartości odstające.

Długość liczona automatycznie ma jeszcze jeden skutek. Awizacje tego samego przewoźnika z różną liczbą palet dostają różne okna, więc harmonogram odzwierciedla rzeczywisty ruch na rampie. Wartości reguł ustawia dyspozytor i zmienia je bez ingerencji w kod. Na etapie wdrożenia porównuje się je z wynikami kilku tygodni. Gdy mediana rzeczywistego czasu przekracza plan o kilka minut, reguła jest zaniżona.

Blokowanie okien czasowych bez konfliktów

Po obliczeniu długości system wybiera i blokuje odpowiednie okna czasowe dla dostawy. Kalendarz dzieli dobę na sloty o stałej długości, na przykład 20 minut, więc wizyta trwająca 80 minut potrzebuje czterech kolejnych wolnych slotów na tej samej rampie. Rezerwacja dwóch rozdzielonych fragmentów nie ma sensu, bo pojazd nie opuści rampy w środku rozładunku.

Znalezienie pierwszego ciągu wolnych slotów to klasyczne zadanie typu gaps and islands. Zapytanie numeruje wolne sloty, odejmuje numer od indeksu slotu w czasie i grupuje wynik. Kolejne sloty dają tę samą różnicę, więc każdy ciąg trafia do osobnej grupy.

DECLARE @DockId int = 3, @Need int = 4;   -- 4 sloty po 20 minut = 80 minut

WITH free_slots AS (
    SELECT SlotStart,
           ROW_NUMBER() OVER (ORDER BY SlotStart) AS rn
      FROM dbo.DockSlot
     WHERE DockId = @DockId
       AND IsBooked = 0
       AND SlotStart >= SYSUTCDATETIME()
), runs AS (
    SELECT SlotStart,
           DATEDIFF(MINUTE, '20000101', SlotStart) / 20 - rn AS grp
      FROM free_slots
)
SELECT TOP (1) MIN(SlotStart) AS RunStart, COUNT(*) AS Slots
  FROM runs
 GROUP BY grp
HAVING COUNT(*) >= @Need
 ORDER BY MIN(SlotStart);

Zapytanie tylko wskazuje kandydata. Samą rezerwację trzeba wykonać w transakcji z blokadą zakresu, bo dwóch dostawców może wybrać ten sam ciąg w tej samej sekundzie. Procedurę z blokadą UPDLOCK i HOLDLOCK omawia artykuł o awizacjach VSS.net, a znaczenie podpowiedzi tabel opisuje dokumentacja table hints w Microsoft Learn.

Reguła: wizyta zajmuje ciągły zakres slotów na jednej rampie i nigdy nie jest dzielona na fragmenty.

Kontrahent widzi w formularzu wyłącznie terminy, które przeszły ten test, więc konflikt nie powstaje po jego stronie. Przesunięcie wizyty przeciągnięciem w widoku harmonogramu powinno przechodzić przez tę samą kontrolę pojemności co rezerwacja. W przeciwnym razie funkcja drag and drop stałaby się obejściem reguł, które magazyn ustawił z myślą o planowaniu dostaw do magazynu.

Dostęp przez przeglądarkę i konta kontrahentów

VSS.net działa jako oprogramowanie online, więc kontrahent niczego nie instaluje. Rejestruje się i loguje na dedykowanej stronie, a po uwierzytelnieniu widzi zakres, który przydzielił mu administrator. Kierowcy i firmy transportowe mogą mieć indywidualne konta, dzięki którym aktualizują status dostaw.

Konfiguracja obejmuje cztery obszary, które administrator ustawia przed uruchomieniem pierwszej awizacji.

• Lokalizacje - obiekty, w których system prowadzi harmonogram.
• Magazyny - jednostki w obrębie lokalizacji, do których kierowane są awizacje.
• Kontrahenci - partnerzy zakładający awizacje, każdy z własnymi kontami.
• Uprawnienia - zakres widoczności i działań, także dla wielu lokalizacji jednocześnie.

Dyspozytor rozpoznaje właściciela wizyty po kolorze, bo system pozwala przypisać oznaczenia kolorystyczne operatorom logistycznym. Kolor wpisu w harmonogramie oszczędza otwierania szczegółów każdej awizacji. Dane kontrahentów i skorowidze, z których korzysta formularz awizacji, opisuje artykuł o kartotekach w systemie VSS.net.

Powiadomienia SMS i e-mail dla uczestników dostawy

System wysyła powiadomienia SMS do kierowców oraz e-maile do przewoźników i spedytorów. Kontrahenci dostają e-mail. Rozdzielenie kanałów ma uzasadnienie: kierowca w kabinie odczyta krótki SMS, a biuro spedycji potrzebuje wiadomości z pełnymi danymi awizacji. Zmiana terminu generuje komplet komunikatów bez udziału dyspozytora.

W systemach tego typu wysyłkę realizuje się zwykle przez kolejkę w bazie danych, a nie przez wywołanie bramki SMS w trakcie zapisu awizacji. Zapis awizacji kończy się wtedy szybko, a błąd operatora SMS nie cofa rezerwacji. Poniższy przykład pokazuje wzorzec kolejki. Nie jest opisem implementacji VSS.net.

CREATE TABLE dbo.NotificationOutbox (
    Id        bigint IDENTITY PRIMARY KEY,
    Channel   varchar(5)     NOT NULL,          -- SMS albo EMAIL
    Recipient nvarchar(200)  NOT NULL,
    Body      nvarchar(1000) NOT NULL,
    Status    tinyint        NOT NULL DEFAULT 0, -- 0 czeka, 1 wysłane, 2 błąd, 3 w trakcie
    Attempts  tinyint        NOT NULL DEFAULT 0,
    CreatedAt datetime2(0)   NOT NULL DEFAULT SYSUTCDATETIME()
);

;WITH next_batch AS (
    SELECT TOP (20) *
      FROM dbo.NotificationOutbox WITH (ROWLOCK, READPAST, UPDLOCK)
     WHERE Status = 0 AND Attempts < 3
     ORDER BY Id
)
UPDATE next_batch
   SET Status = 3, Attempts = Attempts + 1
OUTPUT inserted.Id, inserted.Channel, inserted.Recipient, inserted.Body;

Status pośredni 3 chroni przed podwójną wysyłką, gdy dwa procesy pobierają paczki równolegle. Podpowiedź READPAST pomija wiersze zablokowane przez inny proces, więc kolejka nie czeka na cudze blokady. Po wysyłce proces ustawia status 1. Przy błędzie wraca do 0 w celu ponowienia albo przechodzi na 2 po wyczerpaniu prób. Wiersze tkwiące w statusie 3 zbyt długo wymagają zwolnienia, bo proces mógł zostać przerwany w połowie.

Widoki harmonogramu w codziennej pracy

Program prezentuje harmonogram na pięć sposobów. Dobór widoku zależy od pytania, na które dyspozytor szuka odpowiedzi, a nie od preferencji użytkownika.

Widok tabelaryczny bywa niedoceniany. Ochrona przy wjeździe nie potrzebuje kalendarza, tylko listy pojazdów oczekiwanych w najbliższych godzinach, z numerami rejestracyjnymi ciągnika i naczepy do porównania z tym, co stoi przed szlabanem. Widok osi czasu trafia natomiast na duże ekrany w magazynie, gdzie aktualny dzień i godzina zdarzeń są widoczne dla wszystkich bez logowania do systemu na stanowisku.

Konfigurację kalendarzy oraz uprawnień do widoków opisuje osobny artykuł o kalendarzu Studio Awizacje. Zasady tworzenia okien i ich długości omawia tekst o oknach czasowych, a statusy awizacji i zmiany terminów opisuje artykuł o awizacji transportu.

Raportowanie punktualności i wykorzystania ramp

Delegowanie awizacji daje jeszcze jedną korzyść: każda wizyta zostawia ślad w postaci terminu oraz godziny przyjazdu, a po obsłudze także jej czasu. Menedżer logistyki dostaje dane do raportów o wydajności procesów i punktualności dostaw, a zarząd widzi wykorzystanie ramp. Z takich danych powstają rozmowy z przewoźnikami oparte na faktach, a nie na wrażeniach dyspozytora.

Przykładowe zapytanie liczy odsetek wizyt zgodnych z oknem dla każdego przewoźnika z ostatnich 30 dni. Nazwy tabel są poglądowe. Warunek na ArrivedAt wyklucza wizyty, które się jeszcze nie odbyły.

SELECT c.Name AS Carrier,
       COUNT(*) AS Visits,
       CAST(100.0 * SUM(CASE WHEN v.ArrivedAt BETWEEN v.SlotStart AND v.SlotEnd
                             THEN 1 ELSE 0 END) / COUNT(*) AS decimal(5,1)) AS InWindowPct
  FROM dbo.Visit AS v
  JOIN dbo.Carrier AS c ON c.CarrierId = v.CarrierId
 WHERE v.SlotStart >= DATEADD(DAY, -30, SYSUTCDATETIME())
   AND v.ArrivedAt IS NOT NULL
 GROUP BY c.Name
 ORDER BY InWindowPct;

Miarą jest zgodność z oknem, a nie z godziną rozpoczęcia. Kierowca, który przyjechał 10 minut przed końcem okna, mieści się w nim, ale skraca czas dostępny na rozładunek. Dla takich przypadków dodaje się osobny wskaźnik spóźnienia względem początku slotu, żeby raport nie ukrywał wizyt zbliżonych do granicy.

Wdrożenie od jednej bramy

Największe ryzyko przy wprowadzaniu systemu awizacyjnego leży w kontrahentach, a nie w technice. Partnerzy przyzwyczajeni do telefonu potrzebują czasu, żeby przejść na formularz. Rozsądne jest zatem uruchomienie modułu na jednej bramie albo rampie i rozszerzanie go dopiero po ustabilizowaniu procesu.

Reguła: pierwsza brama pilotażowa powinna obsługiwać kontrahentów o największej liczbie wizyt, bo od nich zależy skuteczność zmiany nawyków.

Etapy wdrożenia układają się w cztery kroki, które zwykle wykonuje się po kolei.

1. Konfiguracja obiektu - lokalizacja i magazyn wraz z rampami oraz godzinami pracy.
2. Konta kontrahentów - rejestracja partnerów i nadanie uprawnień.
3. Reguły czasu obsługi - wartości bazowe, później korekta danymi historycznymi.
4. Pilotaż na jednej bramie - obserwacja kolejek i poprawki reguł przed rozszerzeniem.

Zakres funkcji, w tym integrację z innymi systemami, opisuje strona produktu Studio VSS.net, a działanie formularza awizacji można obejrzeć w demo online. Zachowanie pojazdów już na terenie zakładu, od bramy po wyjazd, opisuje artykuł o procesie na placu. Ten sam mechanizm rezerwacji obsługuje też program online do awizacji dostaw.