Zarządzanie oknami czasowymi na platformie awizacyjnej - reguły konfiguracji

Zarządzanie oknami czasowymi jako zestaw reguł

Platforma zarządzania oknami czasowymi przydziela przewoźnikom przedziały na załadunek i rozładunek, ale o jakości przydziału decydują ustawienia, a nie wygląd kalendarza. Te same rampy mogą pracować płynnie albo stać w kolejkach zależnie od tego, jak długie są okna, jak duże są odstępy między nimi i którzy dostawcy mają pierwszeństwo. Reguły trzeba więc traktować jak dane konfiguracyjne, które można zmieniać bez przepisywania aplikacji.

Artykuł zajmuje się wyłącznie tymi regułami. Rezerwację okna przez internetowy portal i zapis rezerwacji w transakcji SQL opisuje tekst o oprogramowaniu do rezerwacji okien czasowych online. Podstawowe pojęcie okna wyjaśnia strona o oknach czasowych, a zarządzanie oknami w konkretnym produkcie omawia artykuł o zarządzaniu oknami czasowymi w systemie VSS.net.

Ustawienia globalne, takie jak długość okna, godziny pracy magazynu, limity czasowe awizacji i maksymalna liczba jednoczesnych transportów na rampie, ustawia administrator w module konfiguracyjnym. Jego zakres opisuje artykuł o module Administrator w VSS.net. Cały układ produktu pokazuje tekst o systemie VSS jako platformie modułów.

Długość okna zależna od liczby palet i typu towaru

Okno stałej długości działa tylko wtedy, gdy wszystkie dostawy są podobne. Pełna naczepa z jednorodnymi paletami rozładowuje się szybciej niż furgon z towarem mieszanym, który trzeba sprawdzić pozycja po pozycji. Reguły długości okna wiążą więc czas z liczbą palet oraz z typem towaru.

Współczynniki typu towaru

Liczbę palet mnoży się przez czas obsługi jednej palety, a wynik korygują współczynniki zależne od towaru. Poniższa tabela pokazuje przykładowy układ. Wartości są ilustracyjne i każdy magazyn ustala własne na podstawie pomiarów.

Tabela reguł w T-SQL

Reguły przechowuje się w tabeli, a nie w kodzie. Wiersz opisuje zakres liczby palet oraz typ pojazdu i towaru, a także parametry czasu. Kilka reguł może pasować do jednej dostawy, więc każda ma stopień szczegółowości: im węższy warunek, tym wyższy. Nazwy są przykładowe i nie odpowiadają schematowi produktu.

CREATE TABLE dbo.RegulaOkna (
    RegulaId       int IDENTITY PRIMARY KEY,
    TypPojazdu     nvarchar(20) NULL,   -- NULL = dowolny
    TypTowaru      nvarchar(20) NULL,   -- NULL = dowolny
    MinPalet       int NOT NULL DEFAULT 0,
    MaxPalet       int NOT NULL DEFAULT 999,
    StalyMin       int NOT NULL,
    MinNaPalete    decimal(4,2) NOT NULL,
    Szczegolowosc  tinyint NOT NULL     -- wyższa wartość = węższa reguła
);

SELECT TOP (1) StalyMin, MinNaPalete
FROM   dbo.RegulaOkna
WHERE  (TypPojazdu IS NULL OR TypPojazdu = @TypPojazdu)
  AND  (TypTowaru  IS NULL OR TypTowaru  = @TypTowaru)
  AND  @Palety BETWEEN MinPalet AND MaxPalet
ORDER BY Szczegolowosc DESC, RegulaId DESC;

Zapytanie wybiera najwęższą pasującą regułę. Jeśli nie pasuje żadna, aplikacja nie może zgadywać, tylko odrzuca rezerwację z komunikatem o braku konfiguracji. Reguła domyślna z wartościami NULL gwarantuje, że taka sytuacja nie wystąpi dla żadnego pojazdu. Wynik zaokrągla się do pełnego slotu kalendarza, tak jak opisuje to artykuł o zarządzaniu dokami w magazynie.

Reguła: wygrywa najwęższa pasująca reguła, a brak dopasowania jest błędem konfiguracji, nie powodem do przyjęcia domyślnej długości.

Bufory między oknami a przepustowość rampy

Bufor jest odstępem po zakończeniu okna, w którym rampa nie przyjmuje nowego pojazdu. Pochłania drobne opóźnienia, żeby jedno spóźnienie nie przesunęło wszystkich kolejnych wizyt. Kosztuje przepustowość, bo każda minuta bufora jest minutą, której nie da się zarezerwować.

Koszt bufora w liczbie okien

Przy oknach o stałej długości bufor zmniejsza liczbę okien mieszczących się w zmianie. Poniższa tabela pokazuje przykład dla ośmiogodzinnej zmiany i godzinnych okien. Wartości są obliczeniowe: liczbę okien wyznacza część całkowita z dzielenia czasu pracy rampy przez sumę długości okna i bufora.

Przykład pokazuje, że koszt bufora nie rośnie liniowo. Bufor 10 minut i 15 minut daje ten sam wynik w liczbie okien, więc zwykle warto wybrać większy, skoro nic nie kosztuje dodatkowo. Z kolei zmiana z 5 na 10 minut usuwa całe okno z dnia. Dlatego bufor dobiera się razem z długością okna, a nie osobno.

Rodzaje buforów

Bufor może być stały albo zależny od obsługi. Stały jest prosty i przewidywalny. Zmienny dopasowuje się do ryzyka: dłuższy po dostawach z kontrolą jakości, krótszy po rozładunku jednorodnych palet. Poniższe cztery typy różnią się miejscem, w którym odstęp jest doliczany.

• Bufor po obsłudze - doliczany na końcu okna, chroni następną wizytę przed opóźnieniem poprzedniej.
• Bufor przed obsługą - doliczany na początku, potrzebny przy dokach wymagających przygotowania, na przykład schłodzenia.
• Bufor zmiany - przerwa na przełomie zmian, gdy ekipa rozładunku się wymienia.
• Bufor dnia - rezerwa pod koniec dnia na wizyty ad hoc i przesunięcia z godzin szczytu.

Godziny pracy ramp i wyjątki kalendarza

Kalendarz nie może udostępniać okien poza godzinami pracy rampy, dlatego godziny są regułą pierwszego poziomu. Ustawia się je dla każdej rampy osobno i dla każdego dnia tygodnia, ponieważ jedna brama pracuje całą dobę, a druga tylko na jedną zmianę. Poza godzinami pracy magazynu okien nie ma, niezależnie od zapotrzebowania.

Wyjątki kalendarza mają pierwszeństwo przed regułą dnia tygodnia. Okno, które zaczyna się w godzinach pracy, ale kończy po ich zakończeniu, nie może być przyznane, więc długość okna i godziny pracy trzeba sprawdzać razem. Poniższe zapytanie generuje początki okien w zakresie godzin pracy rampy rekurencyjnym wyrażeniem CTE.

WITH Sloty AS (
    SELECT @PoczatekPracy AS Poczatek
    UNION ALL
    SELECT DATEADD(MINUTE, @SlotMin, Poczatek)
    FROM   Sloty
    WHERE  DATEADD(MINUTE, @SlotMin + @SlotMin, Poczatek) <= @KoniecPracy
)
SELECT Poczatek, DATEADD(MINUTE, @SlotMin, Poczatek) AS Koniec
FROM   Sloty
OPTION (MAXRECURSION 1000);

Warunek w części rekurencyjnej pilnuje, żeby ostatni slot kończył się najpóźniej o godzinie zakończenia pracy. Funkcja DATEADD w T-SQL dodaje minuty do znacznika czasu, a limit rekurencji chroni przed pętlą przy błędnych parametrach. Od wygenerowanej listy odejmuje się okna już zarezerwowane i przerwy techniczne.

Priorytety dostawców i klasy dostaw

Gdy popyt na okna przekracza podaż, ktoś musi wygrać. Reguły priorytetu rozstrzygają to z góry, dzięki czemu decyzja nie zależy od tego, który dostawca zadzwoni pierwszy. Priorytet nie działa jednak na każde żądanie. Wpływa tylko na dostęp do okien zarezerwowanych i na kolejność przy konflikcie.

Klasę przypisuje się w kartotece dostawcy, a zmiana wymaga uprawnień działu logistyki. Ta sama kartoteka służy raportom terminowości, co opisuje artykuł o tym, jak VSS buduje przejrzyste SLA z przewoźnikami. Priorytet bez konsekwencji staje się fikcją: dostawca klasy A, który nagminnie się spóźnia, powinien tracić uprawnienia zgodnie z regułą zapisaną w umowie.

Źródła zgłoszeń i obowiązek awizowania

Dostęp do platformy mają kontrahent i przewoźnik oraz magazyn i ochrona obiektu, a każda rola widzi inny zakres. System umożliwia wprowadzenie obowiązku awizowania dla firm transportowych. Dane transportów nie muszą być wpisywane ręcznie: dostawca może udostępnić je w pliku, który system zaczyta i przetworzy. Integracja z programami kontrahentów, takimi jak ERP lub TMS, odbywa się przez wymianę danych.

Aktualizacja okna po zmianie ETA

Pojazd rzadko dojeżdża dokładnie o zaplanowanej godzinie. Systemy śledzenia dostarczają nowy szacowany czas przybycia, czyli ETA, a platforma musi zdecydować, co zrobić z oknem. Naiwna reguła przesuwa okno do nowego ETA automatycznie. To zwykle pogarsza sytuację, bo jeśli wszystkie okna dostosują się jednocześnie, pojazdy nadal mogą przyjechać w tym samym czasie i utworzyć kolejkę przed magazynem.

Reguła: zmiana ETA nie przenosi okna, dopóki system nie sprawdzi pojemności rampy w nowym terminie.

W praktyce wybiera się propozycję najbliższego wolnego okna, ze sprawdzeniem pojemności i priorytetu. Na podstawie historii czasów załadunku i rozładunku można też dostosować układ okien do rodzaju produkcji i załadunku klienta, co zwiększa pojemność albo skraca czas i koszty. Zasady opisano także na stronie producenta o zarządzaniu oknami czasowymi w VSS.

Kolejność stosowania reguł przy rezerwacji

Pięć grup reguł działa razem, więc kolejność ich sprawdzania ma znaczenie dla komunikatu, który zobaczy przewoźnik. Jeśli najpierw sprawdzi się priorytet, a dopiero potem godziny pracy, dostawca dostanie informację o braku uprawnień do okna, które w ogóle nie istnieje. Sensowna kolejność zaczyna się od ograniczeń fizycznych, a kończy na organizacyjnych.

Każde odrzucenie powinno wskazywać konkretny powód, na przykład rampa nieczynna w tym terminie. Ogólny komunikat o braku miejsca zmusza przewoźnika do zgadywania i kończy się telefonem do dyspozytora, czyli dokładnie tym, czemu platforma miała zapobiec.

Testowanie i wersjonowanie konfiguracji okien

Zmiana reguły wpływa na wszystkie przyszłe rezerwacje, więc nie powinna trafiać na produkcję bez sprawdzenia. Najpewniejszy sposób to odtworzenie awizacji z ostatnich tygodni na nowych regułach. Symulacja pokazuje, ile okien przekroczyłoby limit, jak zmieniłoby się wykorzystanie ramp i które dostawy nie znalazłyby terminu.

• Symulacja na danych historycznych - te same awizacje przechodzą przez nowy zestaw reguł, a wyniki porównuje się ze stanem obecnym.
• Zmiana pojedynczego parametru - po jednej modyfikacji ocenia się wynik po pełnym cyklu tygodniowym, żeby znać przyczynę poprawy lub pogorszenia.

Konfiguracja powinna mieć historię: kto i kiedy zmienił regułę oraz jaka była poprzednia wartość. W SQL Server zapewniają to tabele czasowe (temporal tables), które automatycznie zapisują poprzednie wersje wierszy. Ogólny opis platformy awizacyjnej zawiera artykuł o platformie do awizacji. Zachowanie kalendarza w dniu wizyty sprawdza się w demo systemu awizacji, a wpływ długości okna na wykorzystanie ramp pokazuje tekst o awizacji w transporcie i wykorzystaniu ramp.