VSS.net system - rezerwacja okna, przepustka QR i prognoza dojazdu

Rezerwacja okna czasowego i numer referencyjny

W systemie VSS.net przewoźnik rezerwuje okno czasowe w programie, a kierowca otrzymuje potwierdzenie awizacji z unikalnym numerem referencyjnym. Numer ma postać kodu QR i pełni funkcję elektronicznej przepustki. Rezerwację można wykonać przez Internet albo w aplikacji na telefon z Androidem, więc partnerzy zewnętrzni i dział logistyki korzystają z tych samych danych bez pośrednictwa dyspozytora.

Numer referencyjny musi być unikalny i możliwy do przepisania ręcznie, gdy skan zawiedzie. Nie powinien też zawierać danych osobowych ani informacji o ładunku. Najprostsze rozwiązanie to losowy token z alfabetu pozbawionego znaków mylonych. Przykład pokazuje generowanie takiego tokenu w T-SQL. Nazwa tabeli Advice jest poglądowa.

CREATE TABLE dbo.Advice (
    AdviceId  int IDENTITY PRIMARY KEY,
    RefNo     varchar(10)  NOT NULL,
    SlotStart datetime2(0) NOT NULL,
    SlotEnd   datetime2(0) NOT NULL,
    DockCode  varchar(10)  NOT NULL,
    Status    tinyint      NOT NULL DEFAULT 0,   -- 0 bufor, 1 zatwierdzona
    CONSTRAINT UQ_Advice_RefNo UNIQUE (RefNo)
);

-- 32 znaki bez liter I oraz O, które przypominają cyfry 1 i 0
DECLARE @alphabet char(32) = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789';
DECLARE @ref varchar(10) = '', @i int = 0;

WHILE @i < 10
BEGIN
    SET @ref += SUBSTRING(@alphabet, 1 + CAST(CRYPT_GEN_RANDOM(2) AS int) % 32, 1);
    SET @i += 1;
END;

Dziesięć pozycji z alfabetu o 32 znakach daje około 1,1 biliarda kombinacji, czyli 2 do potęgi 50. Kolizje zdarzają się rzadko, a ograniczenie UNIQUE wyłapuje te, które wystąpią, i wtedy proces losuje token ponownie. Funkcja CRYPT_GEN_RANDOM zwraca liczby z generatora kryptograficznego, więc następnego numeru nie da się odgadnąć po poprzednim. Ma to znaczenie, bo numer działa jak przepustka. Opis funkcji zawiera dokumentacja CRYPT_GEN_RANDOM w Microsoft Learn.

Przepustka QR na bramie wjazdowej

W dniu przyjazdu kierowca przekazuje pracownikowi ochrony numer rezerwacji, najczęściej jako kod QR wyświetlony na smartfonie. Pracownik skanuje kod z dokumentu albo z telefonu. System sprawdza, jakie zamówienia obejmuje pojazd i do której rampy należy go skierować. Rozstrzygnięcie zapada na podstawie danych z bazy, a nie tego, co kierowca deklaruje słownie.

DECLARE @RefNo varchar(10) = 'K7M2QX9HTA',
        @Now   datetime2(0) = SYSDATETIME();

SELECT a.AdviceId, a.DockCode, a.SlotStart, a.SlotEnd,
       CASE WHEN @Now < DATEADD(MINUTE, -30, a.SlotStart) THEN 'ZA WCZESNIE'
            WHEN @Now > DATEADD(MINUTE,  30, a.SlotEnd)   THEN 'PO OKNIE'
            ELSE 'OK' END AS GateDecision
  FROM dbo.Advice AS a
 WHERE a.RefNo = @RefNo
   AND a.Status = 1;

Zapytanie zwraca jeden wiersz albo żadnego. Brak wiersza oznacza nieznany numer albo awizację niezatwierdzoną i ochrona przechodzi na procedurę pojazdu bez rezerwacji. Tolerancja 30 minut jest parametrem przykładowym. Magazyn dobiera ją do długości okna, bo przy oknie 20-minutowym półgodzinna tolerancja obejmuje cały poprzedni i następny slot.

Skaner przy bramie może być czytnikiem ręcznym albo aparatem w tablecie ochrony. Zasada jest ta sama dla kodu na ekranie telefonu i dla kodu wydrukowanego na dokumencie. Wydruk ma tę zaletę, że nie zależy od baterii ani zasięgu kierowcy. Czas od odczytu do decyzji powinien mieścić się w sekundach, dlatego zapytanie opiera się na indeksie po numerze referencyjnym, który zapewnia już ograniczenie UNIQUE.

Reguła: kod QR niesie wyłącznie numer referencyjny, a dane pojazdu i kierowcy system pobiera z bazy po odczycie.

Przepustka potwierdza wjazd na teren zakładu, a po nim podstawienie pojazdu i wyjazd. Te zdarzenia odpowiadają statusom widocznym w kalendarzu, na przykład brama oczekuje na wjazd, magazyn rampy albo awizacja zamknięta.

Opis produktu wspomina także o automatycznej kontroli dostępu, która ogranicza wyciek danych i porządkuje wejścia z zewnątrz. System może ponadto stosować identyfikatory wirtualne i biometryczne do oznaczania personelu magazynu. Rejestr zdarzeń z kamer i odczytów tablic omawia artykuł o kartotekach w systemie VSS.net, a przebieg wizyty po przejściu bramy przedstawia tekst o yard management system.

Prognoza dojazdu z danych GPS i dostawy JiT

Aplikacja awizacyjna może zostać zintegrowana z systemem monitorowania pojazdów. Każdy przewoźnik śledzi własne auta, a bieżąca lokalizacja może trafiać do platformy okresowo, na przykład co 15 minut. Gdy położenie pojazdu uniemożliwia dotarcie na zaplanowany czas, system może automatycznie powiadomić zainteresowane strony e-mailem oraz SMS-em, a status pojawia się na monitorach w magazynie i w dziale logistyki.

Ta funkcja ma największe znaczenie w magazynach firm produkcyjnych, które pracują w modelu just in time (JiT). Spóźniona dostawa komponentów zatrzymuje linię, więc informacja o opóźnieniu ma wartość tylko wtedy, gdy dociera przed decyzją o przesunięciu okna, a nie po niej.

public static TimeSpan? DelayAgainstWindow(
    double remainingKm, double avgSpeedKmh,
    DateTime nowUtc, DateTime slotStartUtc, TimeSpan tolerance)
{
    if (avgSpeedKmh < 5) return null;   // pojazd stoi - prognoza niemiarodajna

    var eta   = nowUtc.AddHours(remainingKm / avgSpeedKmh);
    var delay = eta - slotStartUtc;

    return delay > tolerance ? delay : TimeSpan.Zero;
}

Metoda porównuje przewidywany przyjazd z początkiem okna. Wynik null oznacza brak podstaw do prognozy, bo pojazd stoi albo pozycja jest zbyt stara. Pozostałą odległość dostarcza moduł wyznaczania tras po stronie telematyki, nie sama awizacja. Liczy się ją po trasie, a nie w linii prostej, bo na zatłoczonym obwodzie miasta różnica między tymi wartościami bywa duża. Integrację danych GPS z systemem transportowym opisuje artykuł o Hertz GPS i Linkway, a alerty o opóźnieniach dostaw omawia tekst o monitoringu dla branży transportowej.

Powtarzane komunikaty przy każdym odczycie męczą odbiorców i szybko tracą wagę. Wysyła się je przy pierwszym przekroczeniu tolerancji, a kolejny raz dopiero wtedy, gdy opóźnienie wzrośnie o następny próg, na przykład o 15 minut. Wystarczy do tego jedna kolumna z ostatnio zgłoszonym opóźnieniem przy każdej awizacji.

Prognoza pozostaje szacunkiem. Pozycja starsza o 15 minut daje błąd równy drodze przejechanej od ostatniego odczytu, a średnia prędkość z ostatniej godziny nie uwzględnia korka za najbliższym zjazdem. Alarm powinien więc zależeć od tolerancji, a nie od pojedynczego przekroczenia. Poniższe zestawienie łączy opis produktu z zaleceniem procesowym w trzecim wierszu.

Kanały powiadomień i języki interfejsu kierowcy

System dopasowuje się do odbiorcy. Użytkownik sam wybiera kanał informowania o nadchodzących dostawach. Podstawowe kanały to e-mail i SMS, a trzecią opcją jest połączenie telefoniczne. Kierowcy z innych krajów korzystają z interfejsu opartego na słowniku, na przykład w wersji angielskiej i niemieckiej, a także francuskiej oraz rosyjskiej.

Słownik jest osobną warstwą danych. Etykiety i nazwy statusów pobiera się po kluczu, podobnie jak treść powiadomień, a język wynika z ustawienia konta lub kontrahenta. W kartotece kontrahenta występuje kolumna Język komunikacji, którą opisuje artykuł o kartotekach. Poniższy fragment JavaScript pokazuje zasadę z awaryjnym powrotem do angielskiego, gdy tłumaczenia brakuje. Klucze są poglądowe.

const dict = {
  pl: { gate: 'Brama', slot: 'Okno czasowe' },
  en: { gate: 'Gate',  slot: 'Time slot' },
  de: { gate: 'Tor',   slot: 'Zeitfenster' }
};

function t(key, lang) {
  return (dict[lang] && dict[lang][key]) || dict.en[key] || key;
}

t('slot', 'de');   // "Zeitfenster"
t('slot', 'fr');   // brak tłumaczenia fr - zwraca "Time slot"

Kierowca spoza Polski nie musi znać słownictwa logistycznego, żeby odczytać numer rampy albo godzinę okna. Numery i daty pozostają takie same w każdej wersji językowej. Dyspozytor oraz ochrona pracują na polskim interfejsie i porównują je z tym, co widzi kierowca. Szerzej o komunikacji z kierowcami z zagranicy pisze artykuł o wielojęzycznej komunikacji VSS, a wariant terminala z Androidem przedstawia tekst o programie do awizacji na Androida.

Przy kierowcach z zagranicy trzeba dodatkowo pilnować stref czasowych. Godziny okien przechowuje się w UTC albo z jawnym przesunięciem, a wyświetla w czasie lokalnym magazynu. Dzięki temu wiadomość SMS z godziną 14:00 oznacza to samo dla kierowcy, który wyjechał z innej strefy, i dla ochrony przy bramie. Pomyłka w tym miejscu objawia się systematycznym spóźnieniem o godzinę, co łatwo pomylić z problemem organizacyjnym.

Integracja z systemem magazynowym i ERP

Awizacja bez powiązania z magazynem kończy się na bramie. Dane zamówienia trzeba potem wprowadzić drugi raz do systemu magazynowego. Ten sam mechanizm psuje stany, gdy biuro prowadzi ewidencję handlowo-księgową w jednym programie, a magazynier ewidencję ilościową w drugim. Stany w obu programach zwykle się rozchodzą, bo każdy przyjmuje inne dane, i trudno pilnować zgodności baz produktów oraz kontrahentów.

Alternatywą jest wdrożenie zintegrowane. Opis produktu podaje przykład Studio WMS.net wdrażanego jako dodatek do systemu nadrzędnego WF-mag WAPRO, z dostępem przez przeglądarkę także dla klientów i partnerów. Raporty prac magazynierów oraz zajętości miejsc składowania powstają w SQL Reporting Services, a kody kreskowe 1D lub 2D można odczytywać z bazy WF-mag albo prowadzić niezależnie w samym WMS. Budowę takich raportów opisuje artykuł o SQL Report Builder.

Zgodność identyfikatorów zapewnia tabela odwzorowań między kartoteką awizacji a symbolem w ERP. Dwa ograniczenia unikalności gwarantują, że każdy kontrahent ma dokładnie jeden odpowiednik po drugiej stronie. Kartoteka kontrahentów w VSS.net zawiera osobne pole na numer w zewnętrznym systemie, o czym pisze artykuł o kartotekach.

CREATE TABLE dbo.ContractorMap (
    ContractorId int         NOT NULL,   -- kartoteka awizacji
    ErpCode      varchar(20) NOT NULL,   -- symbol kontrahenta w ERP
    CONSTRAINT PK_ContractorMap PRIMARY KEY (ContractorId),
    CONSTRAINT UQ_ContractorMap_Erp UNIQUE (ErpCode)
);

Reguła: kontrahent i zamówienie powinny mieć w awizacji ten sam identyfikator co w ERP, inaczej integracja kończy się ręcznym uzgadnianiem.

Przepływ komunikatów przy przyjęciu towaru, od zamówienia po dokument magazynowy, omawia artykuł o integracji VSS z WMS i ERP, a warstwę wymiany danych między systemami magazynowymi przedstawia tekst o integracji WMS z ERP przez REST i kolejki. Model, w którym partner zakłada awizacje sam, opisuje artykuł o delegowaniu awizacji w VSS.net.

Scenariusze awaryjne przy bramie

System działa poprawnie, gdy wszystko idzie zgodnie z planem, ale o jego wartości decyduje zachowanie w wyjątkach. Ochrona przy bramie ma kilkanaście sekund na decyzję, więc procedury muszą być krótkie i zapisane. Cztery sytuacje zdarzają się najczęściej.

• Nieczytelny kod - ręczne wpisanie numeru referencyjnego z potwierdzenia, dlatego numer ma być krótki i bez znaków mylonych.
• Brak zasięgu u kierowcy - potwierdzenie zapisane wcześniej w telefonie albo wydrukowane.
• Pojazd bez rezerwacji - obsługa według procedury dla transportu nieawizowanego.
• Przyjazd poza tolerancją okna - decyzja dyspozytora o nowym terminie lub o wpuszczeniu pojazdu.

Dobre wskaźniki dla tej sekcji to odsetek pojazdów bez rezerwacji oraz czas od odczytu kodu do otwarcia szlabanu. Pierwszy pokazuje, czy partnerzy przeszli na rezerwację okien. Drugi ujawnia wąskie gardło przy bramie, zanim zamieni się w kolejkę na drodze dojazdowej.

Pojazdy bez awizacji trafiają do osobnej ścieżki opisanej w artykule o transporcie nieawizowanym. Warto liczyć takie zdarzenia, bo ich odsetek pokazuje, czy partnerzy rzeczywiście przeszli na rezerwację okien. Zakres funkcji modułu przedstawia strona produktu Studio VSS.net, a zachowanie przepustki można sprawdzić w demo systemu awizacji.