Awizacja transportu - proces po stronie przewoźnika i dyspozytora

Kto uczestniczy w awizacji transportu

Awizacja transportu jest procesem z kilkoma właścicielami. Przewoźnik zgłasza przyjazd, dyspozytor magazynu go zatwierdza, portiernia wpuszcza pojazd, a kierowca potwierdza kolejne etapy wizyty. Każda z tych osób widzi inny fragment tego samego rekordu i ma prawo zmienić tylko swoją część.

Ten artykuł opisuje przebieg zgłoszenia od strony organizacyjnej: rejestrację i statusy, a potem zmiany terminów z powiadomieniami. Zawartość transportu, czyli palety z numerami SSCC oraz wymagania ADR, omawia tekst o tym, jakie dane ładunku zawiera awizacja ładunków i załadunków. Podstawowe pojęcia zebraliśmy w artykule co to jest awizacja w transporcie.

Podział uprawnień wynika z odpowiedzialności. Przewoźnik odpowiada za zgodność pojazdu z zamówieniem, magazyn za dostępność rampy. Jeśli obie strony mogłyby swobodnie edytować wszystkie pola, historia zmian nie pozwoliłaby ustalić, kto przesunął termin i dlaczego pojazd czekał.

Rejestracja awizacji przez przewoźnika

Rejestracja zaczyna się od konta firmy transportowej w systemie awizacji. Przewoźnik nie zakłada zgłoszeń anonimowo, bo magazyn musi wiedzieć, kogo rozliczyć z terminowości i komu wysłać powiadomienie o zmianie.

Konta przewoźników i uprawnienia

W Studio VSS.net konta i uprawnienia konfiguruje się osobno dla przewoźników i spedytorów oraz osobno dla klientów. Uprawnienia określają, do których magazynów i obszarów załadunkowych dana firma może awizować pojazdy oraz czy widzi tylko własne zgłoszenia, czy także zajętość kalendarza. Konta użytkowników wewnątrz firmy przewoźnika pozwalają rozróżnić dyspozytora spedycji od kierowcy, który potwierdza tylko własny przyjazd.

Dobrą praktyką jest powiązanie konta przewoźnika z kartoteką kontrahenta w ERP. Wtedy raporty terminowości, saldo opakowań zwrotnych i faktury za przestoje dotyczą tego samego identyfikatora, a nie trzech wariantów nazwy firmy wpisanych ręcznie.

Formularz zgłoszenia i bufor

Nowe zgłoszenie dodaje się opcją „DOPISZ NOWE AWIZO”. Formularz zapisuje się najpierw w buforze, czyli jako szkic, który przewoźnik może poprawiać. System przechowuje osobno awiza w buforze i awiza zatwierdzone, dzięki czemu dyspozytor nie planuje pracy na podstawie niekompletnych danych.

• Termin i obszar - wybrane okno czasowe oraz magazyn lub obszar załadunkowy, do którego jedzie pojazd.
• Pojazd - numer rejestracyjny ciągnika i naczepy wraz z rodzajem pojazdu, na przykład firana albo chłodnia.
• Kierowca - dane osobowe kierowcy z numerem telefonu, na który trafią powiadomienia SMS.
• Powiązanie ze zleceniem - numer zamówienia zakupu albo zlecenia wydania, z którego wynika cel wizyty.

Długość rezerwacji nie powinna zależeć od deklaracji przewoźnika. System wylicza ją z liczby palet i rodzaju pojazdu, a przewoźnik widzi już tylko wolne okno czasowe o odpowiedniej długości. To eliminuje zgłoszenia „na 15 minut” dla pełnej naczepy.

Zgłoszenie z urządzenia mobilnego

Mniejsi przewoźnicy często nie mają dyspozytora przy komputerze. Zgłoszenie wysyła wtedy sam kierowca z telefonu, a awizacja transportu online przez przeglądarkę działa na smartfonie tak samo jak na komputerze. Dla floty, która pracuje na terminalach, przygotowano osobny program do awizacji na Androida.

Statusy awizacji i ich przejścia

Status jest jedyną informacją, którą widzą wszystkie strony naraz. Z tego powodu jego zmiany muszą być jednoznaczne: kto może przestawić status, w którą stronę i pod jakim warunkiem. Poniższa tabela opisuje typowy cykl życia awizacji w systemie klasy YMS.

Reguła: status zmienia się tylko do przodu, a korekta zrealizowanej wizyty jest nowym zdarzeniem.

Dwie osoby mogą pracować na tej samej awizacji w tej samej chwili, na przykład dyspozytor zatwierdza termin, a przewoźnik go anuluje. Bezpieczne rozwiązanie to współbieżność optymistyczna. Każdy wiersz ma kolumnę typu rowversion w SQL Server, której wartość zmienia się przy każdej aktualizacji. Zapis przechodzi tylko wtedy, gdy wersja w bazie jest taka sama jak odczytana przez użytkownika.

-- fragment przykładowej procedury; nazwy tabel i kolumn są umowne
UPDATE dbo.Awizacje
SET    Status     = 'POTWIERDZONA',
       DataZmiany = SYSUTCDATETIME(),
       ZmienilId  = @UzytkownikId
WHERE  AwizacjaId = @AwizacjaId
  AND  Status     = 'BUFOR'
  AND  Wersja     = @WersjaOdczytana;   -- kolumna typu rowversion

IF @@ROWCOUNT = 0
    THROW 50001, N'Awizacja ma inny status albo zmienił ją inny użytkownik.', 1;

Warunek na status w klauzuli WHERE pilnuje dozwolonych przejść, a warunek na wersję chroni przed nadpisaniem cudzej zmiany. Nie trzeba przy tym trzymać blokady na wierszu przez cały czas, gdy formularz jest otwarty w przeglądarce.

Zmiany terminu i anulacje

Zmiany są normalną częścią awizacji transportu. Pojazd utknął na granicy, załadunek u poprzedniego klienta się przedłużył, zlecenie zostało przeniesione na inny dzień. System nie ma zmian blokować, tylko nadać im reguły i zostawić ślad.

Przesunięcie okna czasowego

Przewoźnik może zaproponować nowy termin z listy wolnych okien. Jeśli zmiana mieści się w tym samym dniu i tym samym obszarze, reguła może ją zatwierdzić automatycznie. Przesunięcie na inny dzień albo do innego magazynu wraca do dyspozytora jako prośba do decyzji.

Przy każdym przesunięciu system zwalnia stary slot i rezerwuje nowy w jednej transakcji. Rozdzielenie tych kroków grozi sytuacją, w której awizacja traci stary termin, a nowy zajmie w międzyczasie ktoś inny. Historia zmian zapisuje poprzedni termin z autorem zmiany oraz powód wybrany przez przewoźnika z listy.

Anulacja i termin graniczny

Anulacja zwalnia rampę dla innych przewoźników, więc liczy się jej moment. Magazyn ustala termin graniczny, na przykład kilka godzin przed początkiem okna. Anulacja wcześniejsza jest neutralna, późniejsza trafia do statystyk przewoźnika tak samo jak spóźnienie.

• Anulacja przez przewoźnika - dostępna do terminu granicznego z portalu, po nim wymaga kontaktu z dyspozytorem.
• Anulacja przez magazyn - zawsze z powodem i automatycznym powiadomieniem przewoźnika oraz kierowcy.

Zmiana pojazdu lub kierowcy

Wymiana ciągnika albo kierowcy nie zmienia terminu ani rampy, więc nie powinna wymagać ponownej rezerwacji. Przewoźnik edytuje tylko dane pojazdu w potwierdzonej awizacji, a system zapisuje zmianę w historii i wysyła nowe potwierdzenie na numer nowego kierowcy. Portiernia widzi przy wjeździe aktualny numer rejestracyjny zamiast tego z pierwotnego zgłoszenia.

Inaczej jest ze zmianą rodzaju pojazdu. Zamiana firany na chłodnię albo solówki na zestaw z naczepą zmienia wymagania wobec rampy i długość obsługi. Taka edycja cofa awizację do decyzji dyspozytora, bo stary slot mógł zostać dobrany do innego typu pojazdu.

Transport nieawizowany i tryb ad hoc

Część pojazdów przyjedzie bez zgłoszenia. Ochrona może wtedy ręcznie zarejestrować pojazd w trybie ad hoc i przydzielić dostępny slot. Takie zdarzenie jest raportowane jako nieawizowane i wpływa na wskaźniki jakości dostawcy, dzięki czemu wyjątek nie staje się cichą regułą.

Powiadomienia dla przewoźnika i kierowcy

Powiadomienie zastępuje telefon, który dyspozytor musiałby wykonać przy każdej zmianie. System wysyła wiadomość e-mail albo SMS automatycznie po zdarzeniu, a odbiorcę wybiera według roli w awizacji.

Jeśli aplikacja awizacyjna jest połączona z monitorowaniem pojazdów, a położenie auta nie pozwala dotrzeć na wyznaczony czas, system sam powiadamia zainteresowane strony. Dyspozytor może wtedy przesunąć termin, zanim pojazd stanie w kolejce.

Kierowcy z zagranicy nie przeczytają komunikatu w języku, którego nie znają. Treść powiadomień warto więc wysyłać w języku zapisanym w profilu kierowcy, co opisuje artykuł o tym, jak działa wielojęzyczna komunikacja z kierowcami w VSS.

Pulpit dyspozytora w dniu wizyty

Dyspozytor pracuje na widoku dnia: lista awizacji z kolorami statusów i oś czasu dla każdej rampy. Rekord awizacji jest w tym widoku zadaniem do wykonania, a nie formularzem. Dyspozytor przeciąga pojazd na inną rampę, zatwierdza zgłoszenia z bufora i widzi, które pojazdy są już na placu.

Pojazdy, które przyjechały przed swoim oknem, czekają na parkingu buforowym. Pulpit pokazuje je w osobnej kolejce z czasem oczekiwania liczonym od wjazdu. Gdy rampa zwolni się wcześniej, dyspozytor wywołuje kolejny pojazd, a kierowca dostaje SMS z numerem rampy. Przyjazd przed czasem nie blokuje wtedy bramy wjazdowej, a zwolnione minuty rampy nie przepadają.

Przyjazd i identyfikacja pojazdu

Wjazd zamyka etap planowania. Portiernia odnajduje awizację po numerze rejestracyjnym, po kodzie QR z potwierdzenia albo przez czytnik RFID przy bramie, a status przechodzi na „W trakcie”. Szczegóły obsługi osoby za kierownicą opisuje artykuł, jak przebiega awizacja kierowcy przy bramie.

Wskaźniki terminowości przewoźników

Każde zdarzenie w awizacji ma znacznik czasu, więc terminowość liczy się z danych, a nie z opinii. Porównanie planowanego początku okna z rzeczywistym wjazdem daje odsetek przyjazdów na czas dla każdego przewoźnika. Do tego dochodzą późne anulacje i transporty nieawizowane. VSS publikuje te wyniki partnerom w portalu, co opisuje tekst o tym, jak budować przejrzyste SLA we współpracy z przewoźnikami.

Zasada: tolerancję spóźnienia definiuje się w minutach dla obszaru, a nie ocenia uznaniowo przy rampie.

Integracja przewoźników przez portal i API

Portal wystarcza przewoźnikowi, który awizuje kilka pojazdów tygodniowo. Operator z setkami zleceń planuje je we własnym systemie i nie będzie przepisywał danych ręcznie. Dla niego awizacja powinna powstawać automatycznie z chwilą przypisania pojazdu do zlecenia w jego programie TMS.

Studio VSS.net integruje się z systemami partnerów przez REST API lub pliki EDI. Z ERP pobiera zamówienia zakupu i automatycznie tworzy propozycje awizacji, które dostawca potwierdza w portalu. Poniższy fragment JavaScript pokazuje ogólny wzorzec wywołania po stronie przewoźnika; adres i nazwy pól są przykładowe i zależą od konfiguracji integracji.

async function wyslijAwizacje(awizacja, token) {
  const odp = await fetch('https://awizacje.example.com/api/awizacje', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer ' + token,
      'Idempotency-Key': awizacja.numerZlecenia
    },
    body: JSON.stringify(awizacja)
  });
  if (odp.status === 409) {
    throw new Error('Wybrane okno czasowe jest już zajęte');
  }
  if (!odp.ok) {
    throw new Error('Błąd rejestracji awizacji: ' + odp.status);
  }
  return odp.json();
}

Nagłówek z kluczem idempotencji chroni przed podwójną awizacją. Jeśli połączenie zerwie się po wysłaniu żądania, system przewoźnika ponowi je z tym samym numerem zlecenia, a serwer zwróci istniejący rekord zamiast tworzyć drugi. Po stronie magazynu zatwierdzona awizacja trafia dalej do WMS, co opisuje artykuł o tym, jak działa integracja VSS z WMS i ERP przy przyjęciach.

Reguła: każde żądanie API tworzące awizację niesie klucz idempotencji.

Integracja działa w obie strony. System przewoźnika potrzebuje informacji zwrotnej o zatwierdzeniu awizacji i zmianie rampy, a na koniec o zamknięciu wizyty. W typowej architekturze zamiast odpytywać API co kilka minut rejestruje się adres zwrotny (webhook), pod który platforma wysyła zdarzenie przy każdej zmianie statusu. Zdarzenia trafiają najpierw do tabeli kolejki w bazie, a osobne zadanie wysyła je asynchronicznie, więc chwilowa niedostępność serwera przewoźnika nie blokuje zapisu statusu w magazynie.

Wybór kanału zależy od skali, a nie od technologii. Ten sam system zarządzania awizacjami obsługuje równolegle portal i API, a także import z ERP, bo wszystkie kanały zapisują zgłoszenie w tej samej tabeli i przechodzą te same reguły statusów. Opis funkcji po stronie produktu zawiera serwis awizacje transportu w Studio VSS.net, a przebieg procesu można sprawdzić w demo systemu awizacji bez instalacji.