Kalendarz dla firmy transportowej - rezerwacja slotów przez przewoźnika

Kalendarz dla firmy transportowej - dwa plany w jednym widoku

Kalendarz dla firmy transportowej musi pokazywać dwie rzeczy jednocześnie. Pierwsza to rezerwacje slotów na rampach kontrahentów, czyli terminy, w których pojazd ma stanąć pod konkretną bramą. Druga to zajętość własnych zasobów: pojazdów i kierowców. Sam plan rezerwacji bez planu zasobów kończy się dwiema dostawami tego samego pojazdu w tej samej godzinie.

Dyspozytor przewoźnika pracuje więc na przecięciu dwóch osi. Slot jest ograniczony pojemnością rampy odbiorcy, a pojazd jest ograniczony czasem przejazdu i czasem pracy kierowcy. Kalendarz ma pokazać oba ograniczenia w jednym miejscu, zanim dyspozytor potwierdzi rezerwację.

Pierwsze dwa wiersze tabeli należą do systemu awizacji odbiorcy, a dwa kolejne do systemu przewoźnika. Ich połączenie odbywa się przez wspólne pola: numer rejestracyjny i numer zlecenia. Kalendarz rezerwacji w Studio VSS.net opisuje artykuł o kalendarzach w VSS.net, a rozwiązanie po stronie producenta przedstawia strona aplikacja kalendarz.

Dobrze zaprojektowany kalendarz odpowiada dyspozytorowi na cztery pytania, zanim ten potwierdzi termin klientowi.

• Gdzie - do której rampy i którego magazynu ma dojechać pojazd oraz jakie są godziny pracy obiektu.
• Kiedy - jakie okna są wolne i ile czasu zajmie rozładunek przy danym ładunku.
• Czym - który ciągnik i która naczepa spełniają wymagania, na przykład temperaturę lub wymiary.
• Kto - który kierowca ma jeszcze zapas czasu pracy i telefon aktywny w systemie.

Rezerwacja slotów przez przewoźnika

Przewoźnik zakłada rezerwację przez przeglądarkę, bez instalowania oprogramowania. Kreator zaczyna od wyboru obiektu, potem magazynu w obiekcie, a dopiero po tych dwóch decyzjach pokazuje wolne okna, ponieważ dostępność zależy od rampy. Na końcu przewoźnik podaje numer rejestracyjny pojazdu i numer zamówienia, a formularz uzupełnia telefon kierowcy.

Rezerwacja trafia najpierw do bufora jako szkic, który można poprawiać. Dopiero zatwierdzenie zajmuje okno na stałe. O tym, czy zatwierdzenie następuje automatycznie, czy wymaga decyzji dyspozytora odbiorcy, decydują zasady ustawione w parametrach obiektu. Cykl życia zgłoszenia opisuje artykuł awizacja transportu - statusy, zmiany, API.

• Rezerwacja pojedyncza - jedno okno dla jednej wizyty, założone z kreatora z listą wolnych okien.
• Rezerwacja cykliczna - szablon powtarzany w wybrane dni tygodnia, przydatny przy stałych trasach.

Rezerwacja cykliczna oszczędza dyspozytorowi najwięcej pracy. Przewoźnik, który jeździ do tego samego magazynu co wtorek i piątek, zakłada szablon raz, a system rezerwuje okna na kolejne tygodnie. Zmiana lub zakończenie szablonu odbywa się z osobnej listy, więc nie trzeba edytować każdej wizyty.

Zasady doboru długości okien opisuje artykuł o oknach czasowych. Ogólny mechanizm rezerwacji slotów przez oprogramowanie online przedstawia tekst o time slot management.

Reguła: długość rezerwacji wylicza system z liczby palet i rodzaju pojazdu, a nie przewoźnik z własnej oceny.

Zmiana terminu jest zwykłą częścią pracy przewoźnika. Pojazd utknął w korku, załadunek u poprzedniego klienta się przedłużył albo zlecenie przeniesiono na inny dzień. Przesunięcie rezerwacji oznacza w bazie anulowanie starej i założenie nowej w jednej transakcji. Gdyby oba kroki wykonać osobno, w przerwie między nimi inny przewoźnik mógłby zająć zwolnione miejsce, a zmiana zakończyłaby się utratą obu terminów.

SET XACT_ABORT ON;
BEGIN TRAN;
    UPDATE dbo.SlotReservation SET Status = 'X' WHERE ReservationId = @OldId;

    INSERT INTO dbo.SlotReservation (DockId, VehiclePlate, SlotStart, SlotEnd, TravelMinutes, Status)
    VALUES (@DockId, @VehiclePlate, @NewStart, @NewEnd, @TravelMinutes, '1');
COMMIT;

Ustawienie XACT_ABORT ON sprawia, że błąd w dowolnym kroku wycofuje całą transakcję, więc rezerwacja nigdy nie zostaje bez terminu. Sprawdzenie wolnej pojemności rampy wykonuje się w tej samej transakcji, z podpowiedzią blokującą zakres, tak jak opisuje to artykuł o awizacjach VSS.net.

Widoki kalendarza - od dnia do osi czasu

Ten sam zestaw rezerwacji ogląda się w kilku widokach, bo różni użytkownicy potrzebują innej skali. Kierownik zmiany chce siatki godzin jednego dnia, a planista tygodnia potrzebuje rozkładu dostaw w kolejnych dniach. Ochrona przy bramie woli listę w kolejności godzin, a dyspozytor ramp oś, na której okna leżą obok siebie.

Każdy wpis niesie nazwę kontrahenta i numer zamówienia, a także dane pojazdu wraz z telefonem 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, a widoczność przypisuje się rolom: firma transportowa widzi tylko własne rezerwacje, a kierownik magazynu kalendarze wszystkich zarejestrowanych firm.

Przewoźnik korzysta z widoku tygodnia do planowania, a z agendy w dniu jazdy. Agenda mieści się na ekranie telefonu, więc kierowca sprawdza w niej godzinę i rampę bez przewijania siatki. Widok tygodnia z kilkunastoma rampami wymaga większego ekranu i bywa uciążliwy na urządzeniu mobilnym.

Raport wykorzystania rezerwacji

Kalendarz gromadzi dane, które po miesiącu pokazują zachowanie przewoźnika wobec rezerwacji. Zestawienie z historii wizyt odpowiada na pytanie, czy zarezerwowane okna są w ogóle wykorzystywane.

• Wskaźnik niestawień - udział rezerwacji, przy których pojazd w ogóle nie przyjechał, a okno przepadło.
• Odchylenie od okna - średnia różnica między godziną rezerwacji a czasem przyjazdu.
• Anulacje po terminie granicznym - rezerwacje wycofane zbyt późno, żeby okno mogło trafić do innego przewoźnika.
• Wykorzystanie szablonów - udział rezerwacji cyklicznych, które faktycznie zrealizowano.

Przewoźnik używa tego raportu do rozmowy z klientem, a magazyn do zmiany zasad. Firma, która kilka razy w miesiącu nie stawia się w oknie, może dostać krótsze rezerwacje z obowiązkowym potwierdzeniem dzień wcześniej.

Konflikty pojazdu i kierowcy w kalendarzu

Pojemność rampy pilnuje system odbiorcy. Konflikt zasobu przewoźnika, czyli ten sam pojazd w dwóch miejscach naraz, musi wykryć system przewoźnika. Sprawdzenie polega na porównaniu przedziałów czasu: dwie rezerwacje jednego pojazdu nakładają się, gdy początek każdej z nich jest przed końcem drugiej.

SELECT a.ReservationId AS FirstId, b.ReservationId AS SecondId, a.VehiclePlate
FROM dbo.SlotReservation AS a
JOIN dbo.SlotReservation AS b
  ON  a.VehiclePlate = b.VehiclePlate
  AND a.ReservationId < b.ReservationId
  AND a.SlotStart < DATEADD(MINUTE, b.TravelMinutes, b.SlotEnd)
  AND b.SlotStart < DATEADD(MINUTE, a.TravelMinutes, a.SlotEnd)
WHERE a.Status <> 'X' AND b.Status <> 'X';

CREATE INDEX IX_SlotReservation_Vehicle
    ON dbo.SlotReservation (VehiclePlate, SlotStart) INCLUDE (SlotEnd, TravelMinutes, Status);

Przykład ma charakter poglądowy, a nazwy tabel i kolumn są przykładowe. Warunek a.ReservationId < b.ReservationId eliminuje pary odwrócone i porównanie rezerwacji z samą sobą. Kolumna TravelMinutes dodaje do końca rezerwacji czas przejazdu do następnego punktu, więc kalendarz wykrywa też rezerwacje, które nie nakładają się wprost, ale są nie do zrealizowania fizycznie.

Indeks złożony zaczyna się od numeru rejestracyjnego, bo złączenie zawsze dotyczy jednego pojazdu. Kolumny w INCLUDE pozwalają zakończyć zapytanie bez sięgania do indeksu klastrowego. Składnię tworzenia indeksów z kolumnami dołączonymi opisuje dokumentacja CREATE INDEX w Microsoft Learn.

Zasada: ostrzeżenie o konflikcie pojawia się przed zatwierdzeniem rezerwacji, a nie po wysłaniu pojazdu w trasę.

Osobnym ryzykiem jest równoczesna edycja. Dwóch dyspozytorów może otworzyć tę samą rezerwację i zapisać różne zmiany. Rozwiązaniem jest kolumna typu rowversion, której wartość zmienia się przy każdej aktualizacji, a zapis przechodzi tylko wtedy, gdy wersja w bazie zgadza się z tą, którą użytkownik odczytał. Typ opisuje dokumentacja rowversion w Microsoft Learn. Drugi dyspozytor dostaje wtedy komunikat o zmianie zamiast po cichu nadpisać cudzą decyzję.

Ten sam mechanizm sprawdza limit czasu pracy kierowcy: zamiast pojazdu w złączeniu występuje kierowca, a do porównania dochodzi suma godzin w dobie. Wartości limitów zależą od przepisów o czasie pracy kierowców i powinny pochodzić z tabeli konfiguracyjnej, a nie z kodu.

Czas pracy kierowcy i plan floty

Plan kierowcy w kalendarzu przewoźnika ma dodatkowe ograniczenie, którego nie ma plan rampy: limity czasu prowadzenia i obowiązkowe przerwy wynikające z przepisów o czasie pracy kierowców. Rezerwacja, której nie da się zrealizować bez przekroczenia limitu, jest błędem planu, nawet gdy okno na rampie jest wolne.

Wartości limitów przechowuje się w tabeli konfiguracyjnej z datą obowiązywania. Dzięki temu zmiana przepisów lub układu zbiorowego nie wymaga zmiany kodu, a raport historyczny nadal liczy się według reguł obowiązujących w danym dniu.

Taki plan nie zastępuje tachografu ani ewidencji czasu pracy, tylko ostrzega dyspozytora z wyprzedzeniem. Dane o faktycznym czasie prowadzenia pochodzą z tachografu i trafiają do systemu jako zdarzenia, które korygują plan.

Powiadomienia i zmiany terminu

Kalendarz ma sens, gdy zmiana w nim dociera do osoby, której dotyczy. System wysyła potwierdzenie rezerwacji oraz informację o każdej zmianie terminu w formie wiadomości e-mail lub SMS. Numer telefonu kierowcy pochodzi z formularza rezerwacji, dlatego jego poprawność decyduje o skuteczności całego mechanizmu.

Zmianę terminu proponowaną przez magazyn przewoźnik powinien potwierdzić. Bez potwierdzenia system nie wie, czy kierowca dostał informację, a wpis w kalendarzu zostaje w stanie oczekującym. Brak odpowiedzi po ustalonym czasie eskaluje sprawę do dyspozytora przewoźnika, który dzwoni do kierowcy.

Jeśli potwierdzenie ma trafić do kalendarza w telefonie kierowcy, wystarczy załącznik w formacie iCalendar opisanym w standardzie RFC 5545. Poniższy fragment jest przykładem formatu, a nie opisem interfejsu produktu. Czasy zapisano w UTC, a telefon przelicza je na czas lokalny.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//przyklad//kalendarz-slotow//PL
BEGIN:VEVENT
UID:rez-10452@przyklad.pl
DTSTAMP:20261001T060000Z
DTSTART:20261005T070000Z
DTEND:20261005T073000Z
SUMMARY:Rozładunek - rampa 4
LOCATION:Magazyn centralny\, brama 4
END:VEVENT
END:VCALENDAR

Pole UID jest stałe dla rezerwacji, więc przy zmianie terminu system wysyła zdarzenie z tym samym UID i wyższym numerem sekwencji. Kalendarz odbiorcy aktualizuje wtedy istniejący wpis zamiast dodawać nowy.

Kalendarz na telefonie kierowcy

Kierowca zwykle nie siedzi przy komputerze. Rezerwację i jej status sprawdza na telefonie, a potwierdzenie przyjazdu wysyła z aplikacji lub przez odpowiedź na wiadomość. System awizacji działa w przeglądarce smartfona tak samo jak na komputerze, a dla flot pracujących na terminalach istnieje wariant opisany w artykule o programie do awizacji na Androida.

Komunikaty dla kierowców z innych krajów wymagają obsługi języków. Kierowca przyjeżdżający z zagranicy nie powinien dostawać wiadomości w języku, którego nie rozumie, dlatego język komunikatu przypisuje się do konta kierowcy lub przewoźnika. Rozwiązanie omawia artykuł o wielojęzycznej komunikacji VSS z kierowcami.

Integracja kalendarza z systemem TMS

Kalendarz dla firmy transportowej nie zastępuje systemu TMS. TMS prowadzi zlecenia i trasy, a kalendarz rezerwacji zajmuje się oknami u odbiorców. Wspólnym kluczem jest numer zlecenia: rezerwacja powstaje z zlecenia, a zmiana terminu w kalendarzu wraca do zlecenia jako nowa data dostawy. Program tej klasy przedstawia strona o TMS dla firmy transportowej.

Bez tej wymiany dyspozytor wpisuje ten sam termin w dwóch miejscach i prędzej czy później dwa wpisy się rozjeżdżają. Wymiana może odbywać się przez API REST albo przez plik, a każdy komunikat powinien nieść identyfikator zlecenia, żeby ponowne wysłanie nie tworzyło drugiej rezerwacji. Szersze ujęcie oprogramowania dla przewoźników zawiera artykuł o oprogramowaniu dla firmy transportowej.