System zarządzania awizacjami - architektura, statusy i integracje

Z czego składa się system zarządzania awizacjami

System zarządzania awizacjami rejestruje każdą wizytę pojazdu na terenie zakładu. Zapisuje cel wizyty oraz jej czas i przebieg. Oprócz tego koordynuje dostęp do zasobów placu, takich jak doki i wagi. Dostawca albo przewoźnik loguje się do systemu przez przeglądarkę i rezerwuje wolny termin w wybranym doku magazynu, a dyspozytor widzi tę rezerwację w tym samym momencie.

Od strony technicznej system dzieli się na trzy warstwy. Użytkownik pracuje w przeglądarce, logika działa w aplikacji webowej, a wszystkie dane trafiają do bazy. Taki podział ma praktyczną konsekwencję: na stanowisku dyspozytora ani na komputerze przewoźnika nie instaluje się nic poza przeglądarką. Aktualizacja aplikacji dotyczy wtedy jednego serwera, a nie kilkudziesięciu komputerów, i nikt po stronie dostawców nie musi jej wykonywać.

Warstwa przeglądarkowa

Dostęp przez przeglądarkę oznacza, że dostawca nie czeka na konto w firmowej sieci ani na instalację klienta. Wystarczy adres portalu i login, a konto zakłada administrator systemu. Kierowca z innego kraju otwiera ten sam portal w swoim języku, bo interfejs ma wersje angielską i niemiecką, a także francuską i rosyjską. Szerzej pisze o tym artykuł o wielojęzycznej komunikacji z kierowcami.

Aplikacja i baza danych

Aplikacje SoftwareStudio powstają w technologii ASP.NET i opierają się na rozwiązaniach Microsoft. Aplikacja działa na serwerze stron IIS, a dane przechowuje silnik SQL Server. Instalacja sprowadza się do utworzenia witryny WWW i umieszczenia aplikacji w wybranym, wcześniej przygotowanym katalogu.

Wymagania i instalacja na serwerze

Do poprawnej pracy potrzebny jest serwer z zainstalowanym systemem operacyjnym, serwerem stron IIS oraz silnikiem bazy danych SQL Server. Opis systemu podaje także minimalne wymagania sprzętowe dla stanowisk i drukowania. Zestawia je poniższa tabela, przy czym liczby pochodzą z dokumentacji aplikacji i należy je traktować jako dolną granicę, a nie jako zalecenie dla produkcji.

Reguła: wersje IIS i SQL Server dobiera się według zaleceń Microsoft dla danej platformy, a minimalny sprzęt z opisu aplikacji służy tylko do oceny stanowisk.

Producent platformy opisuje w dokumentacji, jak działa serwer WWW i jakie ma role w systemie Windows Server; dobrym punktem wyjścia jest przegląd serwera IIS w Microsoft Learn. Dla instalacji z awizacją ważne są dwie decyzje: czy portal ma być dostępny z zewnątrz oraz czy baza stoi na tym samym serwerze co aplikacja. Pierwsza wpływa na sposób publikacji i certyfikat, druga na wydajność przy wielu równoległych rezerwacjach.

Cykl statusów awiza w bazie

Awizo przechodzi przez kilka stanów, a system zapisuje je w kolumnie statusu. W opisie systemu kolumna nazywa się ACH i przyjmuje trzy wartości: 0 dla bufora, 1 dla awiza zatwierdzonego oraz X dla awiza anulowanego lub usuniętego. Moduł programu pozwala dopisać nowe awizo i prowadzi dwa rejestry, czyli awiza w buforze oraz awiza zatwierdzone.

Bufor i zatwierdzenie

Bufor chroni harmonogram przed błędnymi zgłoszeniami. Wpis od zewnętrznego dostawcy trafia najpierw do statusu 0, dyspozytor sprawdza go i dopiero wtedy zmienia status na 1. Szczegółowy opis pól dokumentu znajduje się w artykule o polach i statusach awizo dostawy, a zbiorcze zmiany statusów opisuje strona o awizacjach dostaw i masowych zmianach.

Zatwierdzenie jest jedną instrukcją UPDATE, którą warto zabezpieczyć warunkiem na obecny status. Dzięki temu dwóch dyspozytorów, którzy klikną w tej samej chwili, nie zatwierdzi tego samego awiza dwa razy. Poniższy fragment jest przykładem mechanizmu, a nazwy tabeli i kolumn nie odpowiadają schematowi produktu.

-- przykład: ograniczenie wartości statusu oraz bezpieczne zatwierdzenie
ALTER TABLE dbo.AwizoPrzyklad
  ADD CONSTRAINT CK_AwizoPrzyklad_Ach CHECK (Ach IN ('0', '1', 'X'));

UPDATE dbo.AwizoPrzyklad
SET    Ach = '1', ZatwierdzilUzytkownik = @Uzytkownik
WHERE  AwizoId = @AwizoId
  AND  Ach = '0';                 -- zmiana tylko z bufora

IF @@ROWCOUNT = 0
    RAISERROR('Awizo zostało już zatwierdzone lub anulowane.', 16, 1);

Anulowanie bez utraty historii

Wartość X nie kasuje wiersza. Awizo pozostaje w bazie, więc raport punktualności albo rozliczenie postoju może sięgnąć do anulowanych zgłoszeń. Ograniczenie wartości opisuje dokumentacja o ograniczeniach CHECK w SQL Server. Baza odrzuca wtedy błędny status niezależnie od tego, która aplikacja próbuje go zapisać.

Integracje z WMS i ERP

System zarządzania awizacjami działa samodzielnie, ale najwięcej daje w połączeniu z magazynem i systemem finansowo-handlowym. Zatwierdzone awizacje trafiają do WMS jako zlecenia przyjęcia lub wydania. Magazynier widzi wtedy przy wjeździe pojazdu, co ma być rozładowane i na jaki adres odłożone. Od strony ERP system pobiera zamówienia zakupu i tworzy z nich propozycje awizacji, które dostawca potwierdza w portalu.

Interfejs REST wymaga kilku decyzji projektowych, które dokumentacja Microsoft omawia w wytycznych projektowania interfejsów API. Praktyczny wniosek dla awizacji jest prosty: żądanie tworzące propozycję powinno być idempotentne, żeby ponowiona wysyłka z ERP nie rezerwowała dwóch okien. Przykładowy ładunek wygląda tak.

{
  "zamowienieZakupu": "ZK/2026/0412",
  "dostawca": "PRZYKLAD-01",
  "planowanaData": "2026-10-14",
  "jednostki": { "rodzaj": "paleta", "liczba": 22 },
  "kluczIdempotencji": "ZK-2026-0412-v1"
}

System może też działać bez WMS. Jako samodzielny moduł YMS wystarcza magazynom, które prowadzą ewidencję w arkuszach albo starszych programach, i pełni wtedy rolę portalu awizacyjnego. Kwestie przyjęcia towaru po stronie magazynu omawia artykuł o awizacjach dostaw do magazynu, a mechanizm wymiany danych z ERP - opis integracji VSS z WMS i ERP. Ogólny przegląd łączenia systemów magazynowych daje strona o integracji systemów magazynowych.

Portal dla dostawców i urządzenia mobilne

Część systemu widoczna dla firm zewnętrznych wymaga osobnej uwagi, bo to ona kształtuje pierwsze wrażenie dostawcy. Dostawca po zalogowaniu widzi wolne terminy i rezerwuje jeden z nich w wybranym doku. Wolne okno wynika z dostępności ramp i z awiz już zatwierdzonych, więc portal nie oferuje terminów, których magazyn nie obsłuży.

Awizacje można tworzyć w formularzu internetowym albo na telefonie z systemem Android. Kierowca, który już stoi przed bramą, potwierdza przyjazd bez dzwonienia do dyspozytora. Obsługę na urządzeniach mobilnych, w tym kody QR i pracę bez zasięgu, opisuje artykuł o programie do awizacji na Androida.

Reguła: zgłoszenie z zewnątrz trafia do bufora, a termin na rampie zajmuje dopiero po zatwierdzeniu przez dyspozytora.

Uprawnienia i role

Dostawca powinien widzieć wyłącznie własne awiza. Dyspozytor widzi wszystkie, a ochrona ogranicza się do wjazdów i wyjazdów danego dnia. Taki podział warto spisać przed wdrożeniem jako macierz uprawnień. Mechanizmy uwierzytelniania opisuje dokumentacja uwierzytelniania w ASP.NET Core.

Raporty i wskaźniki z danych awizacji

Każda wizyta zostawia w bazie ślad, który po kilku miesiącach staje się materiałem do analizy. Zapisane są planowany termin oraz status awiza, a także znaczniki wjazdu i wyjazdu pojazdu, więc z samych znaczników czasu można policzyć punktualność dostawców i czas postoju na placu. Nie potrzeba do tego osobnego systemu analitycznego. Wystarczy zapytanie do bazy albo raport w usłudze raportowej.

Poniższy przykład liczy średni czas postoju i odsetek spóźnień dla każdego dostawcy. Zapytanie korzysta z funkcji DATEDIFF, którą opisuje dokumentacja DATEDIFF w T-SQL. Nazwy obiektów są przykładowe.

-- przykład: średni postój i odsetek spóźnień według dostawcy
SELECT  Dostawca,
        AVG(DATEDIFF(MINUTE, Wjazd, Wyjazd))                        AS SredniPostojMin,
        100.0 * SUM(CASE WHEN Wjazd > PlanowanyPrzyjazd THEN 1 ELSE 0 END)
              / COUNT(*)                                            AS ProcentSpoznien
FROM    dbo.WizytaPrzyklad
WHERE   Ach = '1' AND Wyjazd IS NOT NULL
GROUP BY Dostawca
ORDER BY ProcentSpoznien DESC;

Wynik warto czytać razem z liczbą wizyt, bo dostawca z dwiema dostawami w miesiącu i jednym spóźnieniem ma 50 procent, choć niczego to jeszcze nie dowodzi. Rozbudowane zestawienie błędów planowania i wskaźników opisuje strona o zarządzaniu awizacjami: błędach i wskaźnikach.

Wdrożenie systemu w firmie

Zanim firma zdecyduje o wdrożeniu, warto policzyć, ile godzin miesięcznie tracą kierowcy i magazynierzy na ręczne ustalanie terminów. To najprostszy sposób oszacowania zwrotu, bo opiera się na własnych danych, a nie na obietnicach producenta. Wynik pokazuje też, które dostawy generują najwięcej telefonów do dyspozytora, i od nich należy zacząć.

Wdrożenie zaczyna się od jednej bramy albo jednej rampy, a nie od całego terenu zakładu. Taki pilotaż pozwala oswoić dostawców i pracowników z nowym harmonogramem, zanim system obejmie wszystkie punkty odprawy. Na tym etapie wychodzą pierwsze rozbieżności między wyobrażeniem o procesie a rzeczywistością na rampie, na przykład dostawy, które nigdy nie mieściły się w standardowym oknie.

• Słowniki - magazyny i rampy, a także rodzaje pojazdów i kontrahenci muszą być uzupełnione przed pierwszą rezerwacją.
• Zasady okien - domyślna długość obsługi dla typowej dostawy i sposób jej ręcznej korekty.
• Procedura wyjątków - co robi ochrona z pojazdem bez awizacji i jak długo taki pojazd czeka na wolny termin.
• Komunikacja z dostawcami - kiedy zaczyna obowiązywać rezerwacja przez portal i do kiedy przyjmowane są zgłoszenia telefoniczne.

Osobną kwestią jest transport nieawizowany. System nie może go ignorować, dlatego regulamin magazynu powinien określać maksymalny czas oczekiwania na wolne okno. Ogranicza to spory z przewoźnikami i utrzymuje przewidywalność pracy na bramie.

Arkusz Excel czy system awizacji

Małe firmy nadal zarządzają awizacjami w arkuszach kalkulacyjnych i kalendarzach. Przy kilku dostawach dziennie to działa, dopóki jedna osoba pilnuje pliku. Problemy zaczynają się, gdy w harmonogramie pracuje kilku użytkowników, a każdy zapisuje własną kopię. Awaria komputera w trakcie edycji potrafi zniszczyć dane, a brak integracji zmusza do ręcznego przepisywania zamówień.

Granicę wyznacza liczba dostawców i częstość zmian. Duże przedsiębiorstwo z rozbudowaną logistyką potrzebuje systemu praktycznie od początku, natomiast mała firma może zacząć od prostszych narzędzi i policzyć, ile godzin tygodniowo pochłania ręczne ustalanie terminów. Dodatkowe omówienie takiego przejścia znajduje się w artykule o kalendarzu rezerwacji poza Excelem.

Planowanie kolejki dostaw do magazynu

Kolejka samochodów przed magazynem jest skutkiem braku planu, a nie nadmiaru dostaw. System awizacji zamienia ją w harmonogram, w którym każdy pojazd ma okno i rampę. Proces przebiega w pięciu etapach, które zestawia tabela.

O długości okna decyduje rodzaj ładunku. Dostawa dwudziestu dwóch palet wymaga innego czasu niż jedna paleta z drobnicą, więc system oblicza czas obsługi, a użytkownik może go poprawić ręcznie. Same okna omawia strona o oknach czasowych, a przebieg dnia na rampach - artykuł o harmonogramie dnia i rampach.

Zakres systemu YMS

Awizacja jest wycinkiem zarządzania placem. Pełny system klasy YMS dodaje do niej kontrolę ruchu na terenie zakładu i przydział miejsc postojowych, co opisuje artykuł o zakresie systemu YMS i różnicach względem WMS. Ofertę systemu przedstawia serwis awizacje.softwarestudio.com.pl, a szerszy przegląd rynku - portal YMS24.