WHC – Dokumentacja systemu

Wprowadzenie

Czym jest WHC

WHC (Warehouse Calendar) to oprogramowanie do awizacji i zarządzania ruchem pojazdów na dokach (ang. dock scheduling software / yard & dock management). System porządkuje cały proces umawiania dostaw i odbiorów: od momentu, w którym przewoźnik lub dostawca rezerwuje okno czasowe na rampie, przez kontrolę wjazdu kierowcy na teren, aż po rozliczenie czasu operacji i raporty.

W jednym zdaniu: WHC zamienia chaos telefonów, maili i Excela w jeden, współdzielony kalendarz doków, w którym każda dostawa ma swój termin, bramę, status i komplet danych.

Awizacja (appointment) to w WHC podstawowa jednostka pracy — pojedyncza, zaplanowana operacja na rampie (dostawa lub odbiór) z przypisanym terminem, bramą, ładunkiem, kierowcą i statusem.

Jaki problem rozwiązuje

W typowym magazynie TSL (transport-spedycja-logistyka) bez systemu awizacji występują te same bolączki:

• Kolejki ciężarówek pod bramą — bo wszyscy przyjeżdżają „rano" lub „po południu".
• Spiętrzenia pracy na jednych rampach i przestoje na innych.
• Brak jednego źródła prawdy — terminy żyją w mailach, na kartkach, w głowach.
• Brak danych — nikt nie wie, ile naprawdę trwa rozładunek, kto się spóźnia, które okna są niewykorzystane.
• Ręczna obsługa stróżówki — ochrona dzwoni do magazynu, żeby potwierdzić, czy wpuścić auto.

WHC adresuje każdą z tych bolączek konkretnym mechanizmem opisanym w dalszych rozdziałach: oknami czasowymi (time slots), limitami (limits), statusami i flow, automatyzacją wjazdu (entry automation) oraz raportami (reports).

Korzyści w skrócie

Dla kogo jest ta dokumentacja

Dokument jest pisany dla przeciętnego pracownika branży TSL (30–45 lat): supply chain managera, koordynatora awizacji, operatora i dyrektora magazynu. Używamy nomenklatury logistycznej, a pojęcia techniczne tłumaczymy w Słowniku pojęć.

Dokumentacja jest jednocześnie referencją dla modeli i agentów AI (LLM) — stąd jej rygorystyczna struktura, jednolite nazewnictwo, tabele oraz Załącznik techniczny z modelem danych. Przy każdym pojęciu podajemy angielski odpowiednik w nawiasie, aby ułatwić mapowanie na nazwy w systemie, API i bazie danych.

Jak czytać ten dokument

• Spis treści na początku jest klikalny (w wersji HTML) i odwzorowuje pełną strukturę.
• Rozdziały 1–2 to fundament — przeczytaj je najpierw, bo wprowadzają „klocki" i model dostępu.
• Rozdziały 3–11 opisują funkcje operacyjne dnia codziennego (awizacje, widoki, okna, limity, statusy, zamówienia, powiadomienia, stróżówka).
• Rozdziały 12–16 to integracje, API, raporty, bezpieczeństwo i ustawienia.
• Rozdziały 17–18 to słownik i załącznik techniczny (model danych) — punkt wejścia dla integratorów i agentów AI.

Stos technologiczny (w skrócie)

WHC to aplikacja webowa działająca w przeglądarce, hostowana w modelu SaaS (każdy klient ma własną instancję):

• Backend: Java + Spring Boot, baza danych MySQL/MariaDB, warstwa Hibernate.
• Frontend: AngularJS + AngularJS Material, widoki JSP.
• Wielojęzyczność: interfejs PL/EN (każdy obiekt ma tłumaczenia).
• Wsparcie urządzeń: komputery, tablety, telefony (RWD), a także telewizory przemysłowe (ekrany TV w hali, w tym starsze modele).

Szczegóły architektury danych znajdują się w Załączniku technicznym.

Dwa tryby pracy użytkowników

Każdy użytkownik należy do jednej z dwóch stron (ang. side), co jest osią całego systemu uprawnień:

• INTERNAL — strona magazynu: koordynatorzy, operatorzy, kierownicy, ochrona, administratorzy. Widzą i obsługują (zależnie od uprawnień) wszystkie awizacje.
• EXTERNAL — strona kontrahenta: przewoźnicy, dostawcy, odbiorcy. Widzą i edytują wyłącznie własne awizacje, w granicach wyznaczonych przez konfigurację (terminy, załączniki, dostępne bramy).

Ten podział przewija się przez całą dokumentację — przy każdej funkcji zaznaczamy, której strony dotyczy.

Koncepcje i klocki systemu

Ten rozdział to mapa myślowa WHC. Opisuje klocki (building blocks), z których zbudowany jest system, oraz relacje między nimi. Zrozumienie tych pojęć wystarczy, by poruszać się po całej resztą dokumentacji.

Mapa klocków

MAGAZYN (warehouse)
  └── BRAMA / DOK (gate)
        └── OKNO CZASOWE (time slot)
              └── AWIZACJA (appointment)
                    ├── OPERACJA (operation type)  → INBOUND / OUTBOUND
                    ├── STATUS (appt status) → MILESTONE (kamień milowy)
                    ├── JEDNOSTKA ŁADUNKOWA (loading unit) + ilość
                    ├── PRODUKTY (products) + ZAMÓWIENIA (orders)
                    ├── KIEROWCA + POJAZD (vehicle)
                    ├── DODATKOWE POLA (attributes)
                    └── ZAŁĄCZNIKI (attachments)

Sterowanie dostępnością:  LIMITY i BLOKADY (limits)
Sterowanie procesem:      STATUSY + FLOW + AUTOMATYZACJE
Kontrola dostępu:         UŻYTKOWNIK (user) → ROLA (role) → UPRAWNIENIA (permissions)
Kontrola wjazdu:          PUNKT WJAZDU (entry point) + WHITELISTA + ANPR

Klocki infrastruktury

Magazyn (warehouse)

Najwyższy poziom struktury — pojedyncza lokalizacja logistyczna (oddział, centrum dystrybucyjne). Magazyn grupuje bramy, ma adres, opis dojazdu (driving directions) i pozycję na liście. Instancja WHC może obsługiwać wiele magazynów jednocześnie, a użytkownikom przydziela się dostęp do wybranych magazynów.

Brama / dok / rampa (gate)

Fizyczny punkt załadunku/rozładunku należący do magazynu. To na bramach planuje się awizacje. Bramy mają nazwę, kolejność i własne okna czasowe. Dostęp użytkownika może być zawężony do konkretnych bram.

Okno czasowe (time slot)

Przedział czasu na danej bramie, w którym można zaplanować operację — np. „poniedziałek 08:00–09:00 na Rampie 3". Okna definiuje się:

• jako szablon tygodniowy (per dzień tygodnia, powtarzalny),
• albo jako wyjątek dla konkretnej daty (np. inny grafik w święto).

Okna czasowe są fundamentem planowania i działają w dwóch trybach (STATIC/DYNAMIC) opisanych poniżej oraz w rozdziale Okna czasowe.

Punkt wjazdu (entry point)

Brama wjazdowa/wyjazdowa na teren (szlaban, kamera ANPR). Powiązany z magazynem, obsługuje automatyczne rozpoznawanie tablic i sterowanie szlabanem. Opisany w rozdziale Automatyzacje i automatyzacja wjazdu.

Klocek centralny: awizacja (appointment)

Awizacja spina wszystkie pozostałe klocki. Jedna awizacja zawiera m.in.:

• termin — data + okno czasowe (a w trybie DYNAMIC dokładne godziny od–do),
• lokalizację — magazyn + brama,
• operację — dostawa (INBOUND) lub odbiór (OUTBOUND),
• status — bieżący etap procesu,
• ładunek — jednostka ładunkowa + ilość, ewentualnie produkty i powiązane zamówienia,
• dane kierowcy i pojazdu — imię i nazwisko, telefon, numery rejestracyjne ciągnika i naczepy, typ pojazdu,
• dane dodatkowe — komentarze (wewnętrzny/zewnętrzny), atrybuty (dodatkowe pola), załączniki,
• metadane — kto utworzył, kiedy, awizowany podmiot, opiekun, historia zmian.

Dwie strony użytkowników: INTERNAL vs EXTERNAL

Strona jest cechą roli (role) — patrz rozdział Konta, role i uprawnienia.

Dwa tryby okien czasowych: STATIC vs DYNAMIC

To najważniejsza decyzja architektoniczna każdej instancji WHC. Wybiera ją administrator (ustawienie timeSlotsMode), a od niej zależy zachowanie całego planowania.

Zmiana trybu w działającej produkcji jest operacją destrukcyjną (kasuje awizacje), dlatego dostępna jest wyłącznie dla konta superadmin. Tryb wybiera się na etapie wdrożenia.

Szczegóły obu trybów: rozdział Okna czasowe.

Klocki sterujące procesem

Operacja (operation type)

Rodzaj czynności na doku. Każda operacja ma kierunek — INBOUND (dostawa/rozładunek) lub OUTBOUND (odbiór/załadunek) — oraz własny zestaw statusów i ustawień modułu zamówień. Przykłady: „Rozładunek dostawy", „Załadunek na eksport", „Odbiór zwrotów".

Status i milestone (kamień milowy)

Status (appt status) to widoczna etykieta etapu, w którym jest awizacja (np. „Awizowane", „Na placu", „W trakcie rozładunku", „Zakończone"), z własnym kolorem i ikoną. Statusy definiuje się per operacja.

Każdy status może być przypisany do milestone (kamień milowy) — abstrakcyjnej fazy procesu wspólnej dla całego systemu: APPROVED (zatwierdzone), ARRIVED (przyjechał), IN_YARD (na placu), OPERATION_STARTED (rozpoczęto operację), OPERATION_FINISHED (zakończono operację), DONE (zakończone), CANCELLED (anulowane), NOT_ARRIVED (nie dotarł), REJECTED_ON_ARRIVAL (odrzucony przy wjeździe). Milestone steruje logiką systemu (np. rezerwacją produktów, liczeniem spóźnień, grupowaniem w stróżówce).

Limit i blokada (limit / blockade)

Reguła pilnująca przepustowości i dostępności. Limity ograniczają np. liczbę przyjazdów na dzień, liczbę palet w oknie, łączny czas operacji albo „ile X jednocześnie". Blokady wyłączają dostępność (np. zamknięcie bramy, blokada dat dla konkretnego kontrahenta). Limit może blokować albo tylko ostrzegać. Szczegóły: rozdział Limity i blokady.

Klocki ładunku

Jednostka ładunkowa (loading unit)

Typ nośnika ładunku: paleta EUR, paleta przemysłowa, kontener, big-bag itd. Ma czas bazowy (time base) i czas na jednostkę (time per unit), na podstawie których WHC wylicza czas operacji w trybie DYNAMIC. Może mieć przypisany kolor (do kolorowania awizacji).

Umowna jednostka miary (basic loading unit)

Uogólniona miara ładunku (np. tona, m³), używana m.in. w limitach tygodniowych. Ilość zapisywana jest jako basicLoadingUnitQuantity.

Produkt i grupa produktów (product / product group)

Pozycje towarowe (indeksy), opcjonalnie grupowane. Produkty mogą mieć własny czas operacji i są wykorzystywane w module zamówień oraz jako kryterium limitów. Szczegóły: rozdział Zamówienia i produkty.

Klocki danych i kontekstu

Atrybut / dodatkowe pole awizacji (attribute)

Konfigurowalne pole awizacji wykraczające poza pola standardowe — np. „Numer awizo dostawcy", „Temperatura", „Kod SSCC". Typy atrybutów: tekst, tekst wielowierszowy, link, lista rozwijana (jedno- i wielokrotnego wyboru), generowany PIN, generowany UUID. Szczegóły: rozdział Pola awizacji i atrybuty.

Załącznik (attachment)

Plik dołączony do awizacji (CMR, list przewozowy, faktura, zdjęcie). Typy załączników mają reguły (dozwolone rozszerzenia, rozmiar, wymagalność).

Zamówienie (order)

Dokument źródłowy (zamówienie zakupu PO lub sprzedaży SO), zwykle importowany z systemu ERP, na podstawie którego tworzy się awizację. Aktywny tylko gdy włączony jest moduł zamówień.

Klocki dostępu i tożsamości

Użytkownik (user)

Konto w systemie — osoba lub punkt (np. konto kioskowe). Ma dane (e-mail, firma, NIP, telefon), przypisaną rolę, język, dostęp do magazynów/bram, opcjonalnie opiekuna (Account Manager) i klucz API.

Rola (role)

Zbiór uprawnień + przypisanie strony (INTERNAL/EXTERNAL). Rola decyduje, jakie widoki i akcje są dostępne oraz jakie kolumny awizacji widać na listach.

Uprawnienie (permission)

Pojedyncze pozwolenie: dostęp do widoku, prawo do dodania/usunięcia awizacji, edycji konkretnego pola, zmiany statusu z X na Y, przekraczania limitów itd. Pełna lista: rozdział Konta, role i uprawnienia.

Klocki komunikacji

System komunikuje się trzema kanałami, każdy oparty o szablony i wyzwalacze (zdarzenia):

• E-mail — szablony HTML, parametry, załączniki, masowa wysyłka.
• SMS — przez bramkę HostedSMS, z walidacją numerów.
• Powiadomienia systemowe (dzwoneczek) — wewnątrz aplikacji, w czasie rzeczywistym, z opcją dźwięku i popupu.

Szczegóły: rozdział Powiadomienia.

Jak klocki współpracują — przykład

Przewoźnik wchodzi na Dodaj Awizo, wybiera operację „Rozładunek", magazyn i bramę. System pokazuje dostępne okna czasowe — z pominięciem tych zablokowanych przez limity i blokady dat. Po wyborze terminu i wpisaniu danych kierowcy oraz jednostki ładunkowej powstaje awizacja ze statusem domyślnym (milestone APPROVED). Wysyłane jest powiadomienie e-mail/SMS. W dniu dostawy kierowca podjeżdża, kamera ANPR rozpoznaje tablicę z whitelisty, szlaban się otwiera, a status zmienia się automatycznie na ARRIVED. Operator widzi auto w Stróżówce i na Kiosku magazyniera, rozpoczyna operację (OPERATION_STARTED), a po zakończeniu (OPERATION_FINISHED/DONE) dane trafiają do raportu czasu operacji.

Każdy z pogrubionych elementów to klocek opisany szczegółowo w kolejnych rozdziałach.

Konta, role i uprawnienia

WHC ma drobnoziarnisty (granular) system uprawnień: nie ma sztywnego podziału „admin vs użytkownik". Każdy widok i każda akcja są osobnym uprawnieniem, które przydziela się rolom. Dzięki temu zbudujesz dowolny profil — od „tylko podgląd Harmonogramu na TV" po „pełny administrator".

Użytkownik (user)

Konto użytkownika zawiera m.in.:

• Dane: e-mail (login), imię i nazwisko (person name), nazwa firmy (company name), NIP, telefon, adres.
• Rola (role) — decyduje o uprawnieniach i stronie (INTERNAL/EXTERNAL).
• Język interfejsu (PL/EN).
• Dostęp do magazynów i bram — zawężenie widoczności do wybranych lokalizacji.
• Domyślny widok (default view) — ekran otwierany po zalogowaniu (wybierany z listy widoków, do których użytkownik ma dostęp).
• Opiekun / Account Manager — użytkownik INTERNAL przypisany do konta; odbiorca powiadomień.
• Klucz API (API key) — do integracji (nagłówek X-API-KEY).
• Identyfikator zewnętrzny (integrated system user id) — do mapowania na ERP.
• Flagi: konto ukryte (hidden), zatwierdzone przez admina, zweryfikowany e-mail.

Operacje na użytkownikach (widok Użytkownicy)

• Dodawanie, edycja, usuwanie (soft-delete) kont.
• Wyszukiwarka użytkowników.
• Kopiowanie (powielanie) użytkownika i roli — szybkie tworzenie podobnych kont.
• Ręczna zmiana hasła dowolnemu użytkownikowi (z poziomu menu kontekstowego) — dla uprawnionych kont.
• Akceptacja / odrzucanie kont oczekujących (przy włączonej rejestracji z potwierdzeniem).
• Import masowy użytkowników (z konfiguracją kolumn) — przydatny przy onboardingu wielu przewoźników.
• Domyślny wybór „wszystkie magazyny i bramy" przy zakładaniu konta (przyspiesza wprowadzanie).
• Przypisanie opiekuna do dowolnego użytkownika (również INTERNAL).
• Edycja kont admin/superadmin przez uprawnione konta (z zachowaniem hierarchii).

Rola (role)

Rola łączy w sobie:

1. Stronę (side): INTERNAL albo EXTERNAL.
2. Zbiór uprawnień (widoki + akcje + pola).
3. Listę kolumn awizacji widocznych w widoku „Lista" dla tej roli (role appt fields) — każda rola może mieć inny zestaw kolumn i ich szerokości.
4. Opcję „utrzymuj zalogowanie" (keep user logged in) — dla kont specjalnych (kioski, TV), które mają pozostać zalogowane nawet po restarcie systemu.

Zmiany uprawnień roli propagują się natychmiast — użytkownik nie musi się wylogowywać i logować ponownie.

Konto superadmin omija wszystkie kontrole uprawnień — zawsze może edytować pola, usuwać awizacje i zmieniać ustawienia krytyczne. To konto serwisowe/wdrożeniowe.

Katalog uprawnień

Uprawnienia funkcjonalne (akcje)

Uprawnienia do edycji pól awizacji

Wzorzec klucza: appointment.field.<pole>.update (konkretne pole) lub appointment.field.*.update (wszystkie pola). Dzięki temu można np. pozwolić koordynatorowi zmieniać termin, ale nie ilość palet.

Obsługiwane pola:

Uprawnienie do zmiany statusu X → Y

Szczególnie istotny mechanizm kontroli workflow. Uprawnienie appointment.field.status.update przyjmuje parametr:

• ALL — pozwala na dowolne przejścia statusów,
• albo listę dozwolonych przejść w formie par { from, to } — np. operator może zmienić status tylko z „Na placu" na „W trakcie rozładunku", ale nie cofnąć go do „Awizowane".

To pozwala odwzorować realny proces i zapobiec „przeskakiwaniu" etapów.

Uprawnienia do atrybutów (dodatkowych pól)

• appointment.attribute.<id>.update — edycja konkretnego atrybutu,
• appointment.attribute.*.update — edycja wszystkich atrybutów.

Uprawnienia do widoków (views.*)

Każdy ekran systemu jest osobnym uprawnieniem. Przydzielenie/odebranie steruje zarówno widocznością w menu, jak i dostępem do adresu URL.

Rejestracja i wdrażanie kontrahentów

WHC wspiera kilka ścieżek pozyskiwania kont zewnętrznych:

• Tworzenie ręczne przez koordynatora (widok Użytkownicy).
• Import masowy z pliku.
• Samodzielna rejestracja (self-service) przez formularz rejestracyjny — opcjonalnie z potwierdzeniem przez administratora (account approval) lub bez. Formularz (registration form) definiuje, które pola są widoczne/wymagane, oraz domyślny widok i przypisaną bramę po rejestracji.
• Tworzenie automatyczne przez API przy imporcie zamówień (z domyślną rolą, językiem i opiekunem).

Po rejestracji system może wymagać weryfikacji adresu e-mail (z zabezpieczeniem przed „automatycznym klikaniem" linków przez filtry antyspamowe).

Logowanie i bezpieczeństwo dostępu

• Logowanie e-mailem i hasłem.
• Uwierzytelnianie dwuskładnikowe (2FA) — kod e-mailem, z opcją zapamiętania zaufanego urządzenia (trusted device) na określoną liczbę dni.
• Polityka haseł — minimalna długość, wymóg wielkich/małych liter, cyfr, znaków specjalnych.
• „Nie pamiętam hasła" — reset hasła przez link e-mail (gdy włączony).
• Tokeny jednorazowe — linki w e-mailach/SMS (np. zmiana statusu, edycja awizo, potwierdzenie zamówienia) działają bez pełnego logowania; menu i zmiana języka są wtedy ukrywane.
• Logowanie zdarzeń — udane i nieudane próby logowania trafiają do logów systemowych.

Szczegóły bezpieczeństwa: rozdział Bezpieczeństwo, audyt i monitoring.

Awizacje — cykl życia

Awizacja (appointment) to serce systemu. Ten rozdział opisuje wszystko, co można z nią zrobić: od utworzenia, przez edycję i przenoszenie, po historię zmian i wydruk.

Tworzenie awizacji

Awizację tworzy się na dwa główne sposoby, zależnie od strony użytkownika:

• INTERNAL — przez okno dialogowe „Nowe awizo" wywoływane z Harmonogramu (kliknięcie „+" w slocie lub przycisku dodawania). Operator widzi pełny zestaw pól i może ustawić dowolny status początkowy.
• EXTERNAL — przez kreator „Dodaj Awizo" (przewodnik krok po kroku: operacja → magazyn/brama → okno czasowe → dane transportu → załączniki → ewentualne zamówienia).

Ułatwienia przy tworzeniu

• Automatyczne uzupełnianie pól, gdy istnieje tylko jedna opcja (jeden magazyn, jedna brama, jedna jednostka ładunkowa, jeden typ operacji).
• Domyślny status ustawiany automatycznie po wyborze operacji.
• Podsumowanie awizacji w ostatnim kroku kreatora (krok SUCCESS) z identyfikatorem awizo w formacie WHC-123 i przyciskiem szybkiego kopiowania.
• Po dodaniu — sekcja „Co dalej?": dodaj kolejne identyczne awizo, dodaj kolejne puste, lub przejdź do swoich awizacji.
• Walidacja limitów i spójności przed zapisem (patrz Limity).
• Automatyczne powiadomienia (e-mail/SMS/systemowe) zaraz po utworzeniu.

Cykliczne / stałe awizacje (periodic appointments)

Dla stałych kontrahentów i powtarzalnych dostaw system pozwala definiować awizacje cykliczne — powtarzalne wpisy w harmonogramie (np. „codziennie 07:00, Rampa 1, dostawca X"), bez ręcznego dodawania każdego dnia.

Identyfikator awizacji

Każda awizacja ma czytelny identyfikator z prefiksem WHC- (np. WHC-4567). Identyfikator jest widoczny w oknach podglądu, na liście i w komunikatach, a dedykowany komponent pozwala go skopiować jednym kliknięciem — przydatne w korespondencji i przy zgłoszeniach.

Edycja awizacji

Po utworzeniu awizację można edytować w oknie podglądu/edycji. Zakres edycji zależy od uprawnień do pól (patrz Uprawnienia do pól):

• Zmiana danych kierowcy, pojazdu, ilości, jednostki ładunkowej, produktów, atrybutów, komentarzy, załączników.
• Zmiana operacji (po dodaniu) — z osobnym uprawnieniem, opcjonalnie wraz ze statusem.
• Zmiana czasu trwania (duration) w trybie DYNAMIC — z osobnym uprawnieniem.
• Ponowna walidacja limitów uruchamiana tylko, gdy zmienia się pole wpływające na limit (data, okno, ilość, magazyn, brama itd.).
• Podgląd pełnej wartości pól statycznych/nieedytowalnych (np. data utworzenia) oraz okno szybkiego kopiowania wartości pól.

Pola wykluczone (field exclusions)

Administrator może ukrywać lub wyłączać wybrane pola formularza zależnie od kontekstu (operacja, metoda odbioru, typ pojazdu, jednostka ładunkowa, rola, użytkownik, a nawet konkretna wartość atrybutu). Pola wykluczone nie są poddawane walidacji. Szczegóły: rozdział Pola awizacji i atrybuty.

Przenoszenie awizacji (zmiana terminu)

Przeniesienie to zmiana daty i/lub okna czasowego (a w trybie DYNAMIC dokładnych godzin). Dostępne mechanizmy:

• Selektor terminów z kolorowaniem okien wg zajętości (zielone/żółte/czerwone) — od razu widać, gdzie jest miejsce.
• Przeciągnij i upuść (drag & drop) w Harmonogramie (tryb DYNAMIC).
• Kopiowanie awizacji metodą „Ctrl + przeciągnij i upuść" (tryb DYNAMIC) — szybkie powielenie na inny termin.
• Walidacja limitów i nakładania przy przenoszeniu.
• Automatyczna zmiana statusu po przeniesieniu (osobny status dla ruchu wewnętrznego i zewnętrznego).
• Reset flagi spóźnienia po zmianie terminu.
• Zakres dostępnych dat spójny z zakresem Harmonogramu; automatyczne przewijanie do bieżącej daty.

Usuwanie i anulowanie

• Usuwanie to soft-delete — awizacja jest oznaczana jako usunięta, ale dane pozostają (audyt, raporty). Wymaga uprawnienia appointment.delete (superadmin zawsze może).
• Anulowanie to zwykle zmiana statusu na milestone CANCELLED — awizacja zostaje w systemie z odpowiednim statusem.
• Konta EXTERNAL mogą usuwać/anulować własne awizacje (jeśli pozwala konfiguracja).
• Usunięcie/anulowanie zamówieniowej awizacji zwalnia zarezerwowane produkty z powrotem do puli zamówienia.

Historia zmian (audyt awizacji)

Każda awizacja ma zakładkę „Historia zmian" rejestrującą każdą modyfikację pola: status, termin, okno, magazyn, brama, kierowca, pojazd, produkty, atrybuty, czas trwania i ponad 30 innych pól. Dla każdego wpisu zapisywane jest:

• kto dokonał zmiany (z wyróżnieniem zmian wykonanych automatycznie przez system),
• kiedy (z dokładnością do sekund),
• wartość poprzednia → nowa.

Pierwszy wpis to wartość początkowa (przy utworzeniu), kolejne to zmiany. Historia jest podstawą raportów mierzących czas między etapami (np. od OPERATION_STARTED do OPERATION_FINISHED). Dostęp wymaga uprawnienia apptHistory.preview.

Wydruk i kopiowanie awizacji

• Wydruk awizacji — z możliwością wyboru, które pola znaleźć się mają na wydruku (np. dane kierowcy + ładunek + PIN/QR).
• Kopiowanie wartości pól z okna podglądu (szybkie wklejenie do innych systemów).
• Powielanie awizacji (kopiowanie) jako szybkie tworzenie podobnych wpisów.

Wyliczanie czasu trwania operacji

W trybie DYNAMIC WHC sam wylicza, ile potrwa operacja, a tym samym jaki fragment bramy zajmie awizacja:

1. Baza — z jednostek ładunkowych (czas bazowy + ilość × czas na jednostkę) lub z sumy czasów produktów (zależnie od ustawienia metody wyliczania).
2. Dodatkowy czas operacji (extra operation time) — reguły wydłużające czas wg kryteriów (magazyn, brama, operacja, jednostka, pojazd, produkt, użytkownik, okno, data).
3. Mnożnik nocny — wydłużenie lub skrócenie czasu w godzinach nocnych (np. mniejsza obsada nocą).
4. Zaokrąglenie do kroku czasowego (time step).

W trybie STATIC czas operacji nie jest wyliczany automatycznie — awizacja zajmuje całe okno, a użytkownik INTERNAL może opcjonalnie podać oczekiwany czas (expected duration). Szczegóły: rozdział Okna czasowe.

Kolizje i spójność

• Wykrywanie nakładania (overlap) — w trybie DYNAMIC system pilnuje, by przedziały czasowe awizacji na tej samej bramie nie zachodziły na siebie.
• Kontrola spójności (coherency) — magazyn ↔ brama ↔ okno ↔ status ↔ operacja muszą do siebie pasować; w DYNAMIC awizacja musi mieścić się w oknie.
• Limity „jednocześnie" (SIMULTANEOUS) — kontrola, ile jednostek danego typu może być obsługiwanych w tym samym momencie (mapowanie minutowe).

Kolorowanie awizacji

Awizacje w widokach można kolorować według:

• statusu (kolor przypisany do statusu), albo
• jednostki ładunkowej (kolor przypisany do typu nośnika).

System dba o kontrast tekstu i ikon na jasnych tłach (czytelność na jasnych kolorach statusów/jednostek). Ikona spóźnienia kierowcy jest wyróżniana kontrastowym kolorem.

Spóźnienia kierowców

WHC automatycznie wykrywa spóźnienia:

• Po przekroczeniu progu (próg w minutach + punkt odniesienia: początek lub koniec okna) awizacja jest oznaczana jako spóźniona (delayed).
• Informacja o spóźnieniu pojawia się w oknie awizacji i na kafelkach w Harmonogramie (ikona).
• Można skonfigurować powiadomienie „Kierowca się spóźnił" (e-mail/SMS/systemowe).
• Spóźnienie jest resetowane po przeniesieniu awizacji na nowy termin.
• Sumy spóźnień per kontrahent trafiają do raportów.

Widoki operacyjne

WHC oferuje kilka komplementarnych widoków na te same awizacje — każdy zoptymalizowany pod inny scenariusz pracy. Dostęp do każdego z nich reguluje osobne uprawnienie (views.*).

Harmonogram (schedule)

Główny kalendarz awizacji — centrum dowodzenia koordynatora. Adres: /admin/schedule (z opcją wskazania magazynu: /admin/schedule/{magazyn}).

Funkcje

• Perspektywy czasu: 1 dzień, 3 dni, 5 dni, tydzień, miesiąc (M). System sam dobiera perspektywę do wielkości ekranu (np. 1 dzień na małych ekranach, 3 dni gdy mało bram).
• Podział na bramy/rampy w kolumnach; przy wielu magazynach — podział menu na magazyny.
• Dodawanie awizacji kliknięciem „+" w slocie (puste i niepuste sloty, oba tryby okien).
• Podgląd, edycja i przenoszenie awizacji (drag & drop w DYNAMIC, Ctrl+drag = kopiowanie).
• Wyszukiwarka awizacji z opcją „Pokaż awizo w Harmonogramie" (przeskok do dnia i bramy).
• Wyróżnianie awizacji po dodaniu/zamknięciu okna (z auto-przewinięciem do właściwego dnia i bramy).
• Linia czasu (current time line) — pozioma linia „teraz".
• Wiszący/przyklejony nagłówek — zawsze widać dzień i bramę, jak nisko byś nie przewinął.
• Tryb kompaktowy („ściskanie" Harmonogramu w pionie) — więcej awizacji na ekranie.
• Kolorowanie okien wg zajętości (zielony/żółty/czerwony) na bazie limitów.
• Konfigurowalny wygląd kafelków awizacji (HTML + edytor) — wybierasz, jakie dane i ikony pokazać (status, ilość, kierowca, nr zamówienia, ikona spóźnienia itd.).
• Filtrowanie po zakresie dat (mechanizm konfigurowalny), automatyczna synchronizacja danych co ~30 s.
• Utrzymywanie pozycji przewijania przy zmianie bramy/dnia.

Oś czasu (timeline)

Widok osi czasu prezentujący awizacje per brama/okno czasowe w układzie liniowym. Adres: /admin/timeline.

Funkcje

• Filtry: operacja, status, magazyn, brama, kontrahent — z zakładkami filtrów (zapisane zestawy).
• Konfigurowalny wygląd kafelków (górna i dolna linia tekstu).
• Przenoszenie awizacji między slotami.
• Opcjonalne pomijanie pustych slotów/dat przy aktywnym filtrze (mniej szumu).
• Sortowanie awizacji po godzinie rozpoczęcia.
• Auto-przewijanie do bieżącej daty.

Lista awizacji (list)

Tabelaryczny widok awizacji w wybranym zakresie dat. Adres: /admin/appt-list.

Funkcje

• Tabela z konfigurowalnymi kolumnami per rola — każda rola widzi inny zestaw pól (w tym atrybuty/dodatkowe pola).
• Sortowanie po kolumnach i filtrowanie.
• Podgląd/edycja awizacji oraz przyciski „kolejnych/sugerowanych statusów" zamiast sztywnych przycisków.
• Menu boczne (dostępne dla lepszej nawigacji).
• Czytelne wyświetlanie wartości atrybutów, autora i awizowanego podmiotu.

Lista dziś / Awizacje dziś

Szybkie widoki „na dziś" do obsługi bieżącego dnia:

• Lista Dziś (/admin/appt-list-today) — lista awizacji zaplanowanych na bieżący dzień (jak Lista, ale z domyślnym filtrem na dziś).
• Awizacje Dziś (/appts-today) — uproszczony, mobilny widok dnia (lista/kafelki) do szybkiej obsługi statusów.

Twoje awizacje (EXTERNAL)

Widok kontrahenta z jego własnymi awizacjami. Adres: /external-user/appointments.

Funkcje

• Lista własnych awizacji z podglądem, drukiem, anulowaniem i edycją dozwolonych pól.
• Przeniesienie (zmiana terminu) istniejącej awizacji (.../move).
• Edycja wybranego awizo (.../edit).
• Kolorowanie i ukrywanie pól wykluczonych.
• Przeszłe awizacje wyszarzone i przeniesione na koniec listy (czytelność).
• Pełne wsparcie mobilne (RWD) — obsługa z telefonu kierowcy/spedytora, w tym dodawanie załączników.

Dodaj awizo (EXTERNAL)

Kreator nowej awizacji dla kontrahenta. Adres: /external-user/add-appointment. Opisany w rozdziale Awizacje — cykl życia; kluczowe cechy:

• przewodnik krok po kroku z selektorem okien czasowych,
• powiązanie z zamówieniem (gdy moduł zamówień włączony),
• weryfikacja limitów już na etapie wyboru terminu,
• podsumowanie i identyfikator WHC-… na końcu.

Widoki publiczne i linki tokenowe (landings)

Specjalne strony otwierane z linków w e-mailach/SMS (bez pełnego logowania):

Tabela zbiorcza widoków awizacji

Widoki na duże ekrany (TV), stróżówkę i kioski opisuje rozdział Stróżówka, kioski i ekrany TV.

Okna czasowe

Okna czasowe (time slots) decydują o tym, kiedy i gdzie można umawiać dostawy. To one przekładają politykę przepustowości magazynu na konkretne, dostępne terminy widziane przez kontrahentów.

Tryb STATIC vs DYNAMIC

WHC pracuje w jednym z dwóch trybów okien (ustawienie timeSlotsMode), wybieranym przy wdrożeniu:

Tryb STATIC (okna stałe)

• Awizacja zajmuje całe okno (np. 08:00–09:00), niezależnie od wielkości ładunku.
• W jednym oknie może być wiele awizacji (pojemność reguluje się limitami).
• Brak automatycznego wyliczania czasu — opcjonalnie operator INTERNAL podaje oczekiwany czas (expected duration).
• Kontrahentowi można pokazywać okno jako pełen przedział (FULL, np. „08:00–09:00") albo tylko godzinę początku (TIME_FROM, np. „08:00").

Tryb DYNAMIC (okna dynamiczne)

• Awizacja ma własny czas trwania wyliczany z ładunku/produktów; zajmuje fragment bramy w czasie.
• W danym momencie jedna operacja na bramę (system pilnuje nakładania).
• Wymaga konfiguracji wyliczania czasu operacji (z jednostek ładunkowych lub produktów) i ewentualnie dodatkowego czasu operacji.
• Umożliwia przeciągnij-i-upuść oraz precyzyjne (minutowe) przenoszenie.

Definiowanie okien

Okna definiuje się w widoku Konfiguracja → Okna Czasowe (/admin/time-slots):

• Szablon tygodniowy — okna per dzień tygodnia (poniedziałek–niedziela), powtarzalne. (Uwaga: w WHC numeracja dni zaczyna się od poniedziałku.)
• Okna dla konkretnych dat (specyficzne) — wyjątki od szablonu na wybrany dzień (np. krótszy grafik w wigilię, dodatkowe okna w szczycie sezonu).
• Okna definiuje się z dokładnością do minut, można je edytować i zawężać.
• Kopiowanie okien: z dnia tygodnia na konkretną datę, z jednego dnia na inne dni, z bramy na inne bramy.

Bezpieczne zmiany okien

Edycja i usuwanie okien to operacje wrażliwe (mogą dotyczyć istniejących awizacji), więc WHC:

• pokazuje listę awizacji dotkniętych zmianą okna,
• informuje, gdzie znaleźć awizacje z usuwanego slotu,
• waliduje poprawność wprowadzanych przedziałów (w tym przypadki graniczne wokół północy 00:00).

Selektor okien czasowych (time slot picker)

Komponent, w którym kontrahent (i operator) wybiera termin. Pokazuje dostępne okna w układzie dni, z uwzględnieniem limitów, blokad i już zajętej pojemności. Konfigurowalny (ustawienia selektora):

• liczba dni na stronę,
• najmniejszy widoczny slot (w krokach czasowych),
• wysokość i marginesy slotów,
• kolorowanie okien wg zajętości (zielony/żółty/czerwony) — także podczas przenoszenia awizacji.

Horyzont i wyprzedzenie awizacji (dla EXTERNAL)

Dla kontrahentów można precyzyjnie ograniczyć, jak daleko i jak wcześnie wolno awizować:

To kluczowe narzędzie do ochrony magazynu przed dostawami „na ostatnią chwilę" i do wymuszenia planowania z wyprzedzeniem.

Dodatkowy czas operacji (extra operation time)

W trybie DYNAMIC możesz precyzyjnie modelować, ile naprawdę trwa operacja, dodając reguły wydłużające czas. Widok: Konfiguracja → Dodatkowy Czas Operacji (/admin/extra-operation-times).

Każda reguła ma:

• kryteria dopasowania: magazyn, brama, typ operacji, metoda odbioru, jednostka ładunkowa, typ pojazdu, okno czasowe, użytkownik, data, produkt, grupa produktów,
• sposób naliczania: na operację (per operation), za ilość produktu (per product quantity) lub za ilość jednostek ładunkowych (per loading unit quantity),
• wartość (minuty).

Przykład: „+15 min dla każdej operacji z chłodnią", „+2 min za każdą paletę big-bag", „+30 min na bramie 1 w poniedziałki".

Mnożnik nocny

Operacje nocne często trwają dłużej (mniejsza obsada, gorsza widoczność). WHC pozwala ustawić:

• zakres godzin nocnych (początek i koniec),
• procentowy mnożnik czasu operacji w tym zakresie (np. 120% = +20%, 50% = skrócenie o połowę).

Mnożnik wpływa na wyliczany czas trwania awizacji w trybie DYNAMIC.

Limity tygodniowe jednostek

Niezależnie od okien można ustawić limit tygodniowy umownej jednostki miary dla operacji przychodzących (np. maksymalna liczba ton dostaw na tydzień). Wartość 0 oznacza wyłączenie limitu. Mechanizm współgra z modułem limitów opisanym w kolejnym rozdziale.

Limity i blokady

Moduł limitów (limits) to mechanizm, który chroni przepustowość magazynu i wymusza politykę dostaw. To dzięki niemu dostępne okna czasowe „znikają" dla kontrahenta, gdy magazyn osiągnął zaplanowane obłożenie. Widok: Blokady i Limity (/admin/limits).

Dwie kategorie w interfejsie

Widok limitów dzieli się na dwie części:

• Blokady dni per użytkownik — prosty pod-widok do blokowania wybranych dat konkretnemu kontrahentowi (np. „dostawca X nie awizuje w piątki").
• Zaawansowane (wszystkie limity i blokady) — pełna konfiguracja limitów pojemnościowych i blokad z paginacją, kopiowaniem i priorytetami.

Limity pojemnościowe — co można ograniczać

Limit określa maksimum jednej z wielkości (limit entity):

Okres obowiązywania (limit period)

Kryteria dopasowania limitu

Limit można zawęzić do dowolnej kombinacji kryteriów — to czyni go bardzo precyzyjnym narzędziem:

• lokalizacja: magazyn, brama,
• czas: okno czasowe, dzień tygodnia, konkretne daty,
• rodzaj operacji: typ operacji, metoda odbioru,
• ładunek: jednostka ładunkowa, produkt, grupa produktów,
• transport: typ pojazdu,
• strona: konkretny użytkownik (kontrahent),
• dane awizacji: wartość konkretnego atrybutu (dodatkowego pola) — np. limit tylko dla awizacji z atrybutem „Towar niebezpieczny = TAK".

Przykłady:

„Maksymalnie 6 przyjazdów dziennie na Rampie 3" · „Maksymalnie 200 palet dziennie w magazynie Wrocław" · „Maksymalnie 1 chłodnia jednocześnie na całym obiekcie" · „Maksymalnie 4 awizacje na okno dla dostawcy X".

Limity blokujące vs ostrzegające

Każdy limit ma flagę typu:

• Blokujący (blocking) — przekroczenie uniemożliwia zapis awizacji (komunikat błędu, slot niedostępny).
• Ostrzegający (caution) — przekroczenie tylko ostrzega (komunikat), ale pozwala zapisać; slot widoczny z oznaczeniem „ponad limit".

Dla każdego limitu można zdefiniować własny komunikat błędu i ostrzeżenia (wielojęzyczny), aby precyzyjnie poinstruować użytkownika.

Priorytety i kolorowanie

• Priorytet rozstrzyga konflikty, gdy do awizacji pasuje wiele limitów.
• Progi procentowe kolorów (color thresholds) sterują kolorowaniem okien wg zajętości w Harmonogramie i selektorze (zielony → żółty → czerwony). Z kalkulacji wykluczane są awizacje i limity usunięte.

Blokady (kategorie grup limitów)

Poza limitami pojemnościowymi WHC oferuje gotowe kategorie blokad (limit group category), które rozwiązują typowe potrzeby operacyjne:

Przekraczanie limitów (uprawnienie)

Uprawnienie exceedLimits (oraz konto superadmin) pozwala wybranym użytkownikom ignorować blokady limitów — widzą sloty ponad limit i mogą zapisać awizację mimo przekroczenia. To pozwala rozróżnić koordynatora (może „docisnąć" pilną dostawę) od kontrahenta (musi trzymać się limitów). Uwaga: w trybie DYNAMIC fizyczne nakładanie się awizacji jest blokowane osobno, niezależnie od tego uprawnienia.

Egzekucja limitów w praktyce

• Limity są sprawdzane przy tworzeniu, edycji (gdy zmienia się pole istotne dla limitu) i przenoszeniu awizacji.
• Sprawdzane są też przy zwracaniu listy dostępnych okien — slot zablokowany po prostu nie pojawia się kontrahentowi (lub pojawia się jako ostrzegawczy).
• Dostępny jest podgląd „czy przekroczono limit" jeszcze przed zapisem.
• Limity (jak grupy z dziećmi) usuwa się kaskadowo (soft-delete grupy + jej pozycji).
• Limity można kopiować (powielać) — szybkie tworzenie podobnych reguł.

Statusy i przepływ procesu (flow)

Statusy odwzorowują w WHC realny proces obsługi pojazdu na doku — od zatwierdzenia awizacji, przez wjazd, po zakończenie operacji. To one napędzają stróżówkę, kioski, ekrany TV, powiadomienia i raporty czasu operacji. Widok: Konfiguracja → Statusy i Flow (/admin/appt-statuses).

Status awizacji (appt status)

Status to widoczna etykieta etapu. Definiuje się go per typ operacji (inne statusy dla rozładunku, inne dla załadunku). Status ma:

• nazwę (wielojęzyczną) i opis,
• kolor (RGB) i ikonę — używane na kafelkach, listach, w stróżówce i na TV,
• pozycję (kolejność na osi/selektorze),
• domyślność — osobno dla awizacji tworzonych przez INTERNAL i przez EXTERNAL,
• status po przeniesieniu — automatycznie nadawany po zmianie terminu (osobno dla ruchu wewnętrznego i zewnętrznego),
• zewnętrzne ID statusu (integrated system status id) — do mapowania na ERP/integracje.

Operacje na statusach

• Dodawanie, edycja, usuwanie statusów.
• Kopiowanie statusów z jednej operacji do innej — szybka konfiguracja podobnych procesów.
• Wyświetlanie ID statusu w widoku konfiguracji.

Milestone (kamień milowy)

Każdy status można powiązać z jednym z kamieni milowych — abstrakcyjnych faz wspólnych dla całego systemu. Milestone steruje logiką, niezależnie od nazwy nadanej statusowi:

Milestone decyduje m.in. o: rezerwacji produktów (aktywna do OPERATION_STARTED), logice spóźnień (po ARRIVED), grupowaniu w stróżówce i na TV, oraz o kolumnach raportów (czas między milestone’ami).

Kolejne / sugerowane statusy (next statuses)

Zamiast pozwalać na dowolne zmiany, WHC prowadzi użytkownika grafem dozwolonych przejść status X → Y:

• Przejścia definiuje się osobno dla strony INTERNAL i EXTERNAL — operator i kontrahent widzą inne przyciski „następnego statusu".
• Każdy przycisk ma własny tekst i podpowiedź (tooltip), kolejność i kolor.
• Wybór zestawu przycisków zależy od roli użytkownika.
• Opcjonalne potwierdzenie zmiany statusu (ustawienie globalne) — zabezpieczenie przed przypadkowym kliknięciem.
• Zmiana statusu jest dodatkowo chroniona uprawnieniem do przejścia X → Y (patrz Uprawnienie do zmiany statusu).

Przyciski „kolejnych statusów" są używane spójnie w oknie awizacji, na liście, w stróżówce i kioskach.

Fazy przepływu (flow phases)

Faza flow to grupa statusów reprezentująca etap procesu (np. „Na placu", „Oczekujący", „Zaplanowani", „Zakończeni"). Fazy:

• grupują wiele statusów w jeden logiczny etap,
• mają kolejność i wielojęzyczne nazwy,
• mogą być konfigurowane per widok (np. inny układ faz w stróżówce niż na osi czasu) — widoczność i kolejność faz dla danego ekranu.

Fazy flow porządkują widoki operacyjne (zwłaszcza Stróżówkę) w czytelne sekcje „co się dzieje na jakim etapie".

Statusy zamówień (order statuses)

Gdy włączony jest moduł zamówień, zamówienia mają własną ścieżkę statusów (oddzielną od statusów awizacji), definiowaną w Konfiguracja → Statusy Zamówień (/admin/order-statuses). Status zamówienia ma:

• przypisanie do typu zamówienia (zakup PURCHASE_ORDER / sprzedaż SALES_ORDER),
• kolor, ikonę, pozycję,
• domyślność przy utworzeniu,
• zewnętrzne ID statusu (do ERP).

Mapowanie statusów awizacja ↔ zamówienie

WHC potrafi synchronizować statusy między awizacją a powiązanym zamówieniem, według reguł mapowania:

Dzięki temu zmiana etapu w jednym module automatycznie odzwierciedla się w drugim — bez podwójnej obsługi.

Zamówienia i produkty

Moduł zamówień (orders) łączy WHC ze światem ERP: dostawy i odbiory wynikają z konkretnych zamówień zakupu i sprzedaży, a awizacja staje się „realizacją transportową" tych zamówień. Moduł jest opcjonalny — włącza się go globalnie (ustawienie ordersMode) i konfiguruje per typ operacji.

Czym jest zamówienie (order)

Zamówienie to dokument źródłowy, zwykle importowany z ERP (np. Microsoft Dynamics 365 Business Central) lub przez API. Zawiera m.in.:

• typ: zamówienie zakupu (PURCHASE_ORDER) lub sprzedaży (SALES_ORDER),
• identyfikator z systemu zewnętrznego (do mapowania na ERP),
• dostawcę, ceny, datę zamówienia,
• okno realizacji: najwcześniejsza i najpóźniejsza data awizacji (minApptDate / maxApptDate),
• magazyn i bramę docelową, jednostkę i ilość,
• opis towaru, adres,
• produkty (pozycje) i atrybuty zamówienia (dodatkowe pola),
• status zamówienia i flagę „zrealizowane" (isCompleted),
• token do linku „dodaj awizo z tego zamówienia".

Widok zamówień

Uniwersalny widok Zamówienia (/orders) działa zarówno dla INTERNAL, jak i EXTERNAL (konta zewnętrzne widzą tylko własne zamówienia). Pozwala przeglądać zaimportowane zamówienia i tworzyć z nich awizacje. Widok jest stronicowany (paginacja) dla wydajności.

Selektor zamówień (orders picker)

Kluczowy komponent przy tworzeniu awizacji w trybie zamówień — pozwala wybrać, które zamówienia (lub ich części) realizuje dana awizacja. Funkcje:

• wybór jednego lub wielu zamówień (zależnie od konfiguracji operacji),
• podgląd produktów, ilości i adresu magazynu per zamówienie,
• reguła „stare zamówienia jako pierwsze" (patrz niżej),
• automatyczne dedukowanie magazynu z wybranego zamówienia (jeśli zamówienie ma przypisany magazyn),
• aktualizacja puli dostępnych zamówień po dodaniu awizacji,
• wykluczanie zamówień przeterminowanych i już w pełni zrealizowanych,
• wysoka wydajność (zoptymalizowany pod duże listy).

Produkty i grupy produktów

Widok Konfiguracja → Produkty (/admin/products) zarządza katalogiem:

• Grupy produktów (product groups) — np. kategorie towarowe.
• Produkty (products) — indeksy z nazwą (wielojęzyczną), kodem i opcjonalnym czasem operacji (do wyliczania czasu trwania awizacji w trybie DYNAMIC).

Produkty występują:

• na zamówieniu (pozycja + ilość),
• bezpośrednio na awizacji (produkt + ilość), niezależnie od zamówień,
• jako kryterium limitów i dodatkowego czasu operacji.

Ilości produktów i jednostek ładunkowych mogą być niecałkowite, z konfigurowalną precyzją (do 6 miejsc po przecinku).

Konfiguracja modułu per operacja

Dla każdego typu operacji (widok Operacje) ustala się zachowanie zamówień:

Częściowa realizacja zamówienia

Gdy operacja dopuszcza częściową realizację, jedno zamówienie może być transportowane w kilku awizacjach. WHC śledzi, ile z każdej pozycji już zaplanowano:

• ilość całkowita − ilość zarezerwowana = ilość dostępna do awizacji,
• po pełnej realizacji zamówienie jest oznaczane jako zrealizowane (isCompleted),
• przypadek szczególny: gdy w trybie z produktami tworzymy awizo z zamówienia bez produktów, takie zamówienie traktowane jest jako jednorazowe (realizowane w całości w jednym awizo).

Rezerwacja produktów

Produkty z zamówienia są rezerwowane, gdy powiązana awizacja osiąga status z odpowiednim milestone (rezerwacja aktywna do OPERATION_STARTED). Dzięki temu te same pozycje nie zostaną zaplanowane dwa razy. Usunięcie lub anulowanie awizacji zwalnia rezerwację z powrotem do puli zamówienia. W selektorze i podglądzie widać zarezerwowane ilości per produkt/awizo.

„Stare zamówienia jako pierwsze"

Reguła wymuszająca, by starsze zamówienia były transportowane w pierwszej kolejności względem podobnych, nowszych. Za „tożsame" uznawane są zamówienia mające przypisany ten sam magazyn. Zapobiega to zaleganiu starych zamówień i poprawia rotację.

Powiązanie z awizacją i automatyzacje

• Awizacja może być powiązana z jednym lub wieloma zamówieniami (oraz z konkretnymi ilościami produktów z tych zamówień).
• Przy imporcie zamówienia może zostać wysłany e-mail/SMS z linkiem do formularza nowej awizacji.
• Tworzenie awizacji z zamówienia uruchamia łańcuch automatyzacji (np. callback do ERP).
• Dane zamówień (w tym atrybuty zamówień) można pokazywać na kafelkach awizacji (Harmonogram, Oś czasu, TV) oraz w nagłówku okna podglądu, a także w treści powiadomień e-mail/SMS/systemowych.

Import zamówień z ERP opisuje rozdział Integracje i API.

Pola awizacji i atrybuty

WHC pozwala dopasować zestaw pól awizacji do procesu konkretnego magazynu — bez zmian w kodzie. Obok pól standardowych (predefiniowanych) można dodawać własne atrybuty (dodatkowe pola), grupować je tematycznie i sterować ich widocznością.

Pola predefiniowane (standardowe)

To wbudowane pola awizacji, m.in.: data i czas, magazyn, brama, operacja, status, jednostka ładunkowa i ilość, umowna jednostka miary, produkt i ilość, metoda odbioru, typ pojazdu, dane kierowcy, numery rejestracyjne, komentarze, załączniki, awizowany podmiot.

Wybrane usprawnienia pól wbudowanych:

• Imię i nazwisko kierowcy jako jedno połączone pole (obok wariantów osobnych).
• Numer pojazdu (ciągnika) i numer naczepy jako dwa osobne pola.
• Czytelne wartości puste — zamiast pustki wyświetlany jest konfigurowalny znak (np. -).

Atrybuty (dodatkowe pola awizacji)

Atrybut (attribute) to konfigurowalne pole tworzone przez administratora w widoku Konfiguracja → Dodatkowe Pola Awizo (/admin/appt-fields). Pozwala zapisać dane specyficzne dla branży/klienta — np. „Numer awizo dostawcy", „Temperatura", „Kod SSCC", „Numer rampy klienta".

Typy atrybutów

Walidatory atrybutów

• Wymagane (REQUIRED) — pole musi być wypełnione.
• Unikatowe (UNIQUE) — wartość nie może się powtórzyć w obrębie wszystkich awizacji (np. unikatowy numer awizo dostawcy).

PIN i kod QR

Atrybut typu generowany PIN zasila funkcje kontroli wjazdu:

• PIN jest wpisywany przez kierowcę w Kiosku wjazdu lub odczytywany w Stróżówce,
• na bazie PIN-u generowany jest kod QR,
• do e-maila można dołączyć PDF z PIN-em i kodem QR (wygląd i wersja językowa PDF są konfigurowalne).

Kategorie i kolejność pól

Pola (zarówno predefiniowane, jak i atrybuty) można:

• grupować w kategorie tematyczne (np. „Ładunek", „Pojazd", „Kierowca"),
• dowolnie zmieniać ich pozycję w oknie awizacji,
• ustawiać szerokość w widokach tabelarycznych.

To pozwala zbudować przejrzysty, logiczny formularz awizacji dopasowany do procesu.

Kolumny awizacji per rola

Każda rola może mieć własny zestaw kolumn widocznych w widoku „Lista" (role appt fields) — w tym kolumny będące atrybutami. Np. dział celny widzi inne kolumny niż dział transportu.

Wykluczanie pól (field exclusions)

Mechanizm wykluczeń (widok /admin/field-exclusions) pozwala ukrywać lub wyłączać pola formularza awizacji zależnie od kontekstu. Reguła wykluczenia działa wg kryteriów:

• typ operacji, metoda odbioru, typ pojazdu, jednostka ładunkowa,
• rola, konkretny użytkownik,
• a nawet konkretna wartość atrybutu (np. ukryj pole „Temperatura", gdy „Towar mrożony = NIE").

Można też wykluczać konkretne wartości pól z list (np. ukryć wybraną jednostkę ładunkową albo konkretną operację z list w danym kontekście). Pola wykluczone nie są poddawane walidacji.

Pola jako parametry powiadomień i wyświetlania

Wartości pól (standardowych i atrybutów) są dostępne jako parametry {{...}} w szablonach e-mail, SMS, powiadomień systemowych oraz w szablonach wyświetlania (kafelki w Harmonogramie, nagłówek okna podglądu, linie tekstu na TV). Przykłady: {{appt.warehouse}}, {{appt.loadingUnitWithQuantity}}, {{appt.appointedUser.NIP}}, {{vehicleType}}, nazwa pliku ikony statusu. Szczegóły: rozdział Powiadomienia.

Powiadomienia (e-mail, SMS, systemowe)

WHC komunikuje się z uczestnikami procesu trzema kanałami. Wszystkie działają na tej samej zasadzie: szablon (wielojęzyczny) + wyzwalacz/zdarzenie (trigger/event) + odbiorcy + parametry {{...}}. Każdy kanał ma osobny widok konfiguracji.

Kanały

Wyzwalacze (zdarzenia)

Powiadomienie wysyła się w reakcji na zdarzenie (event). Najważniejsze:

• utworzenie awizacji (appointment created),
• usunięcie awizacji (appointment deleted),
• przeniesienie awizacji — zmiana daty/czasu (appointment moved),
• zmiana statusu (status changed),
• zmiana pola / atrybutu awizacji,
• zmiana czasu trwania (duration) w trybie DYNAMIC,
• spóźnienie kierowcy (delayed),
• timery: 1 / 3 / 7 dni przed datą awizacji (przypomnienia),
• import zamówienia (order imported),
• rejestracja / akceptacja / weryfikacja e-mail / reset hasła użytkownika,
• kod 2FA,
• decyzja o wjeździe: dopuszczenie / odrzucenie kierowcy.

Odbiorcy

Dla każdego szablonu wybiera się odbiorców (recipient types), również kilku jednocześnie:

Można też ograniczyć wyzwalacz do roli inicjatora (kto wywołał zdarzenie) — np. „wyślij tylko, gdy status zmienił kontrahent".

Parametry {{...}}

Treść szablonów dynamicznie podstawia dane. Dostępna pula obejmuje m.in.:

• dane awizacji (data, godziny, magazyn, brama, status, ilości, jednostka ładunkowa),
• dane kierowcy i pojazdu,
• dane awizowanego podmiotu (w tym NIP),
• dane zamówień i ich atrybutów,
• atrybuty (dodatkowe pola) awizacji,
• linki z tokenami: edycja awizo, zmiana statusu, akceptacja/odrzucenie, dodanie awizo z zamówienia,
• dane systemu/hosta, formatowanie dat (w tym poprzednia data przy przeniesieniu {{oldDatetime}}),
• nazwa pliku ikony statusu (do wyświetlenia ikony).

System obsługuje też warunkowe wyświetlanie fragmentów HTML (np. if) w blokach definiowanych przez użytkownika.

E-mail — funkcje szczegółowe

• Szablony HTML z edycją kodu; gotowe szablony domyślne (PL/EN).
• Załączniki: pliki awizacji ze storage, generowany PDF z PIN-em i kodem QR, dowolne załączniki ze szablonu.
• Masowa wysyłka (cron poranny) — przypomnienia 1/3/7 dni przed datą awizacji do wszystkich pasujących awizacji (z pominięciem anulowanych).
• Wysyłka asynchroniczna — użytkownik nie czeka, aż e-mail faktycznie wyjdzie.
• „Każdorazowo pytaj o zgodę na wysyłkę" — opcja per szablon (operator potwierdza wysyłkę).
• Test wysyłki i konfiguracja serwera SMTP (z testem połączenia) w Ustawieniach → E-mail.
• Allowlista adresów e-mail (ograniczenie odbiorców, np. na środowiskach testowych).

SMS — funkcje szczegółowe

• Integracja z bramką HostedSMS (login, hasło, nazwa nadawcy w Ustawieniach → SMS).
• Walidacja i automatyczna poprawa numeru telefonu (formaty międzynarodowe, prefiks +48, usuwanie spacji/myślników).
• Wysyłka SMS m.in. przy imporcie zamówienia (z linkiem do formularza awizacji).
• „Każdorazowo pytaj o zgodę na wysyłkę SMS" — opcja per szablon.
• Log SMS — rejestr wysłanych wiadomości (treść, numer, kto wysłał).
• Test SMS z panelu.

Powiadomienia systemowe (dzwoneczek) — funkcje szczegółowe

• Pojawiają się w czasie rzeczywistym pod ikoną dzwoneczka (technologia WebSocket).
• Opcje per szablon: dźwięk (sound) i okienko popup.
• Po zalogowaniu/subskrypcji dosyłane są nieprzeczytane powiadomienia z ostatnich dni.
• Działają nawet po restarcie systemu bez odświeżania strony.
• Jeśli przeglądarka nie wspiera WebSocket, system działa dalej (pomijając powiadomienia).
• Odtwarzanie dźwięku obsłużone również na iPhone/Android.

Zarządzanie szablonami

Wspólne dla wszystkich kanałów:

• Kopiowanie (powielanie) szablonów e-mail / SMS / systemowych.
• Tymczasowe wyłączanie / włączanie wybranego szablonu (funkcja „Wyłącz").
• Globalne włączniki kanałów (e-mail / SMS / systemowe) na poziomie konfiguracji instancji.
• Krytyczne, wbudowane powiadomienia są chronione przed pełną edycją/usunięciem (spójność systemu).
• Wybór statusu w wyzwalaczu pokazuje informację o operacji (czytelność konfiguracji).

Stróżówka, kioski i ekrany TV

WHC wychodzi poza biuro koordynatora — obsługuje stanowiska na bramie, w hali i na placu. Te widoki działają zwykle na dedykowanych kontach (z opcją „utrzymuj zalogowanie"), na tabletach, terminalach i telewizorach przemysłowych.

Stróżówka (gatehouse)

Widok operacyjny dla ochrony/portierni. Adres: /gatehouse. Steruje wjazdem i wyjazdem pojazdów.

Funkcje

• Lista awizacji pogrupowana wg faz flow (np. na placu, oczekujący, zaplanowani, zakończeni) — czytelny obraz „kto gdzie jest".
• Weryfikacja kierowcy po PIN / kodzie QR / tablicy.
• Zmiana statusów przyciskami „kolejnych statusów" (np. wpuszczenie, skierowanie na rampę, wyjazd).
• Podgląd awizacji z danymi potrzebnymi na bramie.
• Dodatkowa tabela historii: awizacje zakończone, anulowane oraz „kierowca nie dotarł".
• Zakres czasowy widoku konfigurowalny (godziny wstecz / do przodu — zwykle wąskie okno, np. ±kilka godzin, dla czytelności).
• Delegowanie decyzji o wpuszczeniu kierowcy do operatora magazynu (rozszerzony proces wjazdu).
• Wsparcie skanera kodów.

Kiosk wjazdu kierowcy (driver entry kiosk)

Samoobsługowy terminal przy wjeździe. Adres: /kiosk-driver-entry. Kierowca sam autoryzuje wjazd.

Funkcje

• Wpisanie PIN lub skan kodu QR.
• Weryfikacja i uzupełnienie/poprawa danych awizacji (np. tablice, dane pojazdu).
• Informacja o statusie decyzji o wjeździe i możliwość ponowienia prośby o wjazd.
• Po pozytywnej weryfikacji — automatyczna zmiana statusu (milestone ARRIVED).
• Integracja z automatyzacją wjazdu (szlaban) — patrz Automatyzacje i automatyzacja wjazdu.

Kiosk magazyniera (warehouseman kiosk)

Ekran dla pracownika magazynu przy rampie. Adres: /kiosk-appt-now.

Funkcje

• Pokazuje aktualnie obsługiwaną awizację na danej bramie/rampie.
• Pozwala zmieniać status operacji na doku (rozpoczęcie/zakończenie operacji) przyciskami „kolejnych statusów".
• Tryb TV/tablet — duża, czytelna prezentacja.

TV — Kolejka awizacji (appointments queue)

Wyświetlacz informacyjny na duży ekran w hali/na placu. Adres: /kiosk-appts-queue.

Funkcje

• Kolejka nadchodzących awizacji (bieżąca, poprzednia, przyszłe) per brama/rampa.
• Konfigurowalne 3 linie tekstu na każdej pozycji (jakie dane pokazać) oraz horyzont godzin do przodu.
• Opcjonalny znacznik statusu (badge) przy każdej pozycji.
• Możliwość wyświetlania danych powiązanych zamówień.
• Duża czcionka, częsta automatyczna synchronizacja danych.
• Wsparcie starszych telewizorów (legacy, m.in. LG WebOS / Chromium z 2020 r.).

Proces wjazdu kierowcy — całość

1. Kierowca podjeżdża. Kamera ANPR rozpoznaje tablicę albo kierowca wpisuje PIN w Kiosku wjazdu.
2. System sprawdza whitelistę (powiązaną z awizacją). Jeśli tablica/PIN się zgadza i mieści w oknie czasowym — decyzja pozytywna.
3. (Opcjonalnie) decyzja jest delegowana do operatora magazynu / stróżówki.
4. Po akceptacji status zmienia się na ARRIVED, a szlaban się otwiera (automatyzacja wjazdu).
5. Auto pojawia się w Stróżówce i na Kiosku magazyniera; operator prowadzi je przez kolejne statusy aż do OPERATION_FINISHED / DONE.
6. Przy wyjeździe — ponowne zdarzenie wyjazdu i ewentualna automatyczna zmiana statusu.

Konfigurację automatyzacji wjazdu opisuje kolejny rozdział.

Automatyzacje i automatyzacja wjazdu

WHC potrafi wykonywać akcje automatycznie — w reakcji na zdarzenia awizacji oraz na zdarzenia fizyczne na bramie (rozpoznanie tablicy, otwarcie szlabanu). Pozwala to ograniczyć ręczną obsługę do minimum.

Automatyzacje (hooki) — własne reguły

Widok Automatyzacje (/admin/hooks-and-handlers) umożliwia tworzenie własnych akcji w języku JavaScript, wyzwalanych zdarzeniami zmiany awizacji.

• Każda automatyzacja (hook handler) ma nazwę, identyfikator zdarzenia (np. zmiana awizacji), kod oraz opis (PL/EN).
• Reguła może np. walidować dane, automatycznie ustawiać pole, blokować zapis przy niespełnionym warunku, integrować z systemem zewnętrznym.
• Definicje są zarządzane centralnie; akcje wykonują się w przeglądarce przy zdarzeniach awizacji.

To narzędzie dla zaawansowanych wdrożeń — pozwala dopasować logikę do nietypowych procesów bez modyfikacji rdzenia systemu.

Automatyzacje wbudowane (backend)

Niezależnie od hooków, system uruchamia wbudowane łańcuchy automatyzacji po kluczowych zdarzeniach:

Automatyzacje czasowe (harmonogram)

• Wykrywanie spóźnień (cyklicznie) — oznaczanie awizacji jako spóźnionych i wysyłka powiadomień.
• Zbyt długo na placu — opcjonalna automatyczna zmiana statusu, gdy auto przekracza dopuszczalny czas postoju.
• Czyszczenie wartości atrybutów z auto-usuwaniem po określonym czasie.
• Przypomnienia 1/3/7 dni przed datą awizacji (poranna wysyłka).

Automatyzacja wjazdu (entry automation, ANPR)

Moduł łączy WHC z fizyczną infrastrukturą bramy: kamerami rozpoznającymi tablice (ANPR) i szlabanami. Konfiguracja w grupie widoków „Automatyzacja wjazdu".

Klocki automatyzacji wjazdu

Jak to działa

1. Po utworzeniu/przeniesieniu/zmianie tablicy w awizacji system automatycznie tworzy wpis na whiteliście (lokalnie, a opcjonalnie też w zewnętrznym systemie szlabanowym), z ważnością „cały dzień" lub w oknie X minut wokół terminu.
2. Kamera ANPR (np. Dahua) rozpoznaje tablicę nadjeżdżającego pojazdu.
3. System sprawdza whitelistę → zapisuje zdarzenie wjazdu → otwiera szlaban (np. przez integrację FLIS) → automatycznie zmienia status awizacji (np. na ARRIVED).
4. Przy wyjeździe — analogiczne zdarzenie i ewentualna zmiana statusu.

Ustawienia kluczowe

Efekt biznesowy: bezobsługowy wjazd umówionych aut — kierowca z poprawną awizacją wjeżdża bez kontaktu z ochroną, a auta nieumówione są zatrzymywane.

Integracje i API

WHC nie jest wyspą — integruje się z systemami ERP, arkuszami, firmami kurierskimi i infrastrukturą fizyczną. Dla integracji programistycznych udostępnia REST API.

API REST

System udostępnia API do zarządzania awizacjami, zamówieniami i użytkownikami. Autoryzacja odbywa się kluczem API w nagłówku X-API-KEY (każdy użytkownik widzi i może wygenerować swój klucz w Ustawieniach → API). API jest bezstanowe (stateless).

Wersja v1 (RESTful, z dokumentacją OpenAPI)

Awizacje (/api/v1/appointments):

• POST — utworzenie awizacji,
• GET, GET /{id}, GET?dateFrom=… — pobieranie list i pojedynczych awizacji,
• GET /sync — pobranie zmian od ostatniego potwierdzenia synchronizacji,
• PATCH /{id} — częściowa aktualizacja z kontrolą wersji (nagłówek If-Match / ETag),
• DELETE /{id} — usunięcie (soft-delete) z kontrolą wersji,
• POST /confirm — potwierdzenie synchronizacji.

Zamówienia (/api/v1/orders): pełny CRUD, wyszukiwanie po identyfikatorze z systemu zewnętrznego, częściowa aktualizacja (PATCH).

Użytkownicy (/api/v1/users): CRUD po ID, e-mailu i identyfikatorze zewnętrznym, częściowa aktualizacja (PATCH).

Wersja v0 (starsza)

Zestaw endpointów POST do dodawania/aktualizacji/pobierania awizacji, zamówień i użytkowników (/api/orders, /api/appointments, /api/users). Utrzymywana dla kompatybilności.

Ustawienia API

• Klucz API per użytkownik (generowanie, kopiowanie).
• Domyślna rola, język i opiekun dla użytkowników tworzonych przez API.
• Standaryzowana obsługa błędów (m.in. 404 — nie znaleziono, 409 — konflikt, 412 — niezgodność wersji).

Integracja z ERP — Microsoft Dynamics 365 Business Central

WHC importuje zamówienia bezpośrednio z Business Central:

• import zamówień sprzedaży (Sales Orders) i zakupu (Purchase Orders) wraz z pozycjami produktowymi i atrybutami,
• import cykliczny z kolejką ponawiania (retry) na wypadek chwilowej awarii,
• po utworzeniu awizacji — callback do Business Central,
• źródła danych mogą obejmować również Google Sheets i Excel w SharePoint,
• alerty e-mail przy błędach komunikacji z ERP,
• odporna obsługa awarii serwera BC.

Integracja z arkuszami (Google Sheets / SharePoint)

• Google Sheets — odczyt/zapis wierszy (konto serwisowe); wykorzystywane m.in. jako źródło importu zamówień oraz do eksportu danych przy wybranych statusach.
• Excel w SharePoint — alternatywne źródło danych zamówień.

Integracje kurierskie

Widok Integracje kurierów (/courier-integration) obsługuje śledzenie przesyłek i powiązanie z awizacjami:

• śledzenie statusów przesyłek u przewoźników: DPD, DHL, UPS, GLS, InPost, Pocztex, Orlen,
• Allegro — obsługa zwrotów (OAuth),
• cykliczne odświeżanie statusów, tworzenie awizacji na podstawie danych kurierskich, wyliczanie przewidywanej daty dostawy.

Integracja z infrastrukturą bramy (ANPR / szlabany)

• Kamery ANPR (np. Dahua) — strumień rozpoznanych tablic.
• Szlabany (np. integracja FLIS) — automatyczne otwieranie dla umówionych aut i synchronizacja whitelisty.

Szczegóły: rozdział Automatyzacje i automatyzacja wjazdu.

Mapowanie statusów do systemów zewnętrznych

Statusy awizacji i zamówień mają pole zewnętrznego ID statusu (integrated system status id), co pozwala spójnie mapować etapy WHC na statusy w systemach partnerów i ERP. Reguły synchronizacji statusów awizacja↔zamówienie opisuje rozdział Statusy i przepływ procesu.

Raporty

Moduł raportów (reports) zamienia dane operacyjne w mierzalne wskaźniki: terminowość, czas operacji, obłożenie, spóźnienia. Widok: Raporty (/reports); wymaga uprawnień views.reports + reports.

Jak działają raporty

• Raport ma konfigurowalne kolumny (nazwy, podpisy, szerokości, kolejność) i typ agregacji (suma, średnia, maksimum, mix).
• Eksport do Excela (plik do pobrania).
• Zakres dat: bieżący miesiąc, poprzedni miesiąc lub dowolny przedział od–do wskazany przy generowaniu.
• Dane respektują dostęp użytkownika: EXTERNAL widzi swoje, INTERNAL — zgodnie z przypisaniem magazynów i bram.

Gotowe rodzaje raportów

Raport awizacji

Pełna lista awizacji z polami: ID, data, godziny, ilości, magazyn, brama, twórca, awizowany podmiot, kierowca, numery rejestracyjne, status, data utworzenia oraz wszystkie atrybuty (dodatkowe pola).

Raport awizacji ze zmianami statusów

Jak wyżej, ale wzbogacony o znaczniki czasu zmian statusów i kamieni milowych — np. kiedy awizacja osiągnęła OPERATION_STARTED i OPERATION_FINISHED. To pozwala policzyć w Excelu rzeczywisty czas operacji na rampie oraz czasy oczekiwania między etapami.

Raport spóźnień

Zestawienie sum spóźnień per kontrahent/spedytor: nazwa, liczba awizacji, łączny czas opóźnienia. Idealny do rozmów z przewoźnikami i do KPI terminowości.

Co zmierzysz dzięki raportom

Raporty są stale rozwijane (dokładność danych, dodatkowe pola, poprawki formatowania Excel).

Bezpieczeństwo, audyt i monitoring

WHC obsługuje dane operacyjne wielu firm jednocześnie, dlatego kładzie nacisk na kontrolę dostępu, rozliczalność (audyt) i niezawodność.

Uwierzytelnianie i dostęp

• Logowanie e-mailem i hasłem; ekran logowania w pełni przetłumaczony (PL/EN).
• Uwierzytelnianie dwuskładnikowe (2FA) — kod wysyłany e-mailem, z opcją zaufanego urządzenia (zapamiętanie na określoną liczbę dni). Włączane w Ustawieniach → Rejestracja i logowanie.
• Polityka haseł — minimalna długość, wymóg wielkich/małych liter, cyfr, znaków specjalnych.
• Reset hasła przez link e-mail (gdy włączony).
• Tokeny jednorazowe — bezpieczne linki w e-mailach/SMS (zmiana statusu, edycja, akceptacja) bez pełnej sesji; menu i zmiana języka są wtedy ukrywane.
• Klucz API (X-API-KEY) dla integracji; sesja API jest bezstanowa.
• Natychmiastowa propagacja uprawnień — zmiana roli działa od razu, bez przelogowania.
• Zabezpieczenia przed niezamierzonym usunięciem/resetem danych systemu.

Audyt — kto, co i kiedy

WHC prowadzi kilka uzupełniających się dzienników:

Widok logów systemowych

• Filtrowanie po poziomie (INFO / WARN / ERROR), datach, wyszukiwanie.
• Dwa poziomy widoczności: zwykły (admin) i superadmin.
• Dokładność czasu zdarzenia do milisekund, paginacja, czyszczenie filtrów.
• Podgląd pełnej treści logu ze sformatowanym JSON-em (duże obiekty, np. szablony e-mail, nie są przycinane).
• Automatyczne czyszczenie logów starszych niż ~3 miesiące; alert e-mail przy nadmiernym rozroście tabeli logów.

Monitoring instancji i niezawodność

• Strona monitorowania stanu instancji (wersja aplikacji, liczba awizacji w okresach, liczba magazynów i bram).
• System monitorowania instancji (kontrola awarii i braku aktywności) oraz alerty e-mail przy problemach integracji.
• Metryki integracji (liczniki i czasy wywołań kurierów, arkuszy) — dla wybranych wdrożeń.
• Asynchroniczna wysyłka e-mail i obsługa zbyt długich operacji — system pozostaje responsywny.
• Uniezależnienie od krytycznych CDN — kluczowe zasoby (JS/CSS) ładowane lokalnie, co eliminuje awarie przy niedostępności zewnętrznych dostawców.
• Wsparcie starszych przeglądarek (m.in. Chromium z 2020 r., telewizory LG WebOS 6.0+).

Licencja i tryb SaaS

WHC działa w modelu SaaS — każdy klient ma osobną instancję. System obsługuje licencję z datą wygaśnięcia, ostrzeżeniami z wyprzedzeniem i blokadą po upływie. Liczenie awizacji na potrzeby rozliczeń opiera się na czasie utworzenia awizacji.

Strefa czasowa i wielojęzyczność

• Strefa czasowa instancji jest konfigurowalna (np. Europe/Warsaw) — wszystkie terminy są spójne.
• Interfejs i treści (statusy, nazwy obiektów, szablony) są wielojęzyczne (PL/EN), z możliwością rozbudowy.

Ustawienia — katalog konfiguracji

Ustawienia zebrane są w menu Ustawienia i podzielone na strony tematyczne. Poniżej kompletny katalog. Część parametrów konfiguruje się na poziomie wdrożenia (instancji), a niektóre dostępne są wyłącznie dla konta superadmin.

Ustawienia → Ogólne

Ustawienia → Czas trwania operacji

Ustawienia → Harmonogram

Ustawienia → Oś czasu

Ustawienia → Rejestracja i logowanie

Ustawienia → TV Kolejka awizacji

Ustawienia → Stróżówka

Ustawienia → Selektor okna czasowego

Ustawienia → Załączniki

Restrykcje załączników mogą działać różnie dla kont INTERNAL i EXTERNAL oraz zależnie od uprawnienia „przekraczania limitów".

Ustawienia → E-mail (SMTP)

Ustawienia → SMS (HostedSMS)

Ustawienia → API

Automatyzacja wjazdu → Ustawienia

Ustawienia na poziomie instancji (wdrożenie)

Część parametrów ustawia się przy wdrożeniu (nie w panelu admina):

Słownik pojęć (terminologia)

Tabela pojęć WHC z odpowiednikami angielskimi (jak w systemie, API i bazie danych) oraz znaczeniem biznesowym. Ułatwia spójną komunikację oraz mapowanie przez agentów AI.

Pojęcia domenowe

Pojęcia dostępu i ról

Pojęcia widoków i stanowisk

Pojęcia techniczne i konfiguracyjne

Załącznik techniczny — model danych

Ten załącznik jest przeznaczony dla integratorów, administratorów i agentów AI. Opisuje fizyczny model danych WHC: obiekty domenowe (encje), słowniki (enumy) i tabele bazy. Stanowi most między językiem biznesowym (poprzednie rozdziały) a implementacją.

Konwencja wspólna: większość encji dziedziczy po klasie bazowej WhcObject, która dodaje kolumny: id (PK), hash (blokada optymistyczna), created_time, update_time, deleted_time, deleted (soft-delete). Encje *Lang to tłumaczenia (wielojęzyczność), a tabele *_event_initiator_roles, limit_dates itp. to tabele łączące/pomocnicze.

Obiekty domenowe (encje JPA) — wg obszarów

Awizacje (rdzeń)

Infrastruktura magazynowa i wjazd

Parametry transportu i operacji

Statusy i flow

Limity

Pola awizacji

Zamówienia i produkty

Użytkownicy, role, rejestracja

Załączniki, powiadomienia, raporty

Integracje i system

Słowniki (enumy) — kluczowe

Skala modelu

Mapa pakietów backendu (orientacyjna)

Uwaga o aktualności: najnowszy snapshot DDL (db-structure/db-full) bywa o kilka wersji za kodem — tabele najnowszych modułów (automatyzacja wjazdu, fazy flow) istnieją w encjach i migracjach przyrostowych (db-structure/db-update) zanim trafią do pełnego snapshotu. Źródłem prawdy dla zmian schematu są migracje przyrostowe.