Awizacja dostaw - aplikacja webowa dla dostawcy i mobilna dla kierowcy

Awizacja dostaw w aplikacji - portal i telefon

Awizacja dostaw obsługiwana z aplikacji dotyczy czterech różnych osób i każda z nich potrzebuje innego widoku. Przewoźnik szuka wolnego okna i wpisuje dane pojazdu. Kierowca chce tylko wiedzieć, dokąd jechać po wjeździe. Planista magazynu pracuje na kalendarzu, a ochrona przy bramie sprawdza, czy pojazd jest oczekiwany.

W praktyce działają więc dwa kanały. Portal przeglądarkowy obsługuje rezerwację i zarządzanie awizacjami, a telefon służy do odprawy. Studio VSS.net jest aplikacją webową, więc nie wymaga instalacji na stacjach roboczych i działa w przeglądarce na komputerze oraz na urządzeniach mobilnych.

Podział ma skutek techniczny: każda rola wywołuje inny zestaw punktów końcowych API i wymaga innych uprawnień. Zgłaszający nie powinien widzieć awizacji innych firm, a kierowca nie edytuje harmonogramu. Sposób prezentacji kalendarza i list awizacji dla planisty opisuje tekst o awizacjach dostaw w liczbie mnogiej, a definicję modułu jako produktu - strona o awizacjach VSS.net.

Portal webowy dla przewoźnika

Przewoźnik lub spedytor wchodzi na stronę magazynu z przeglądarki komputera albo telefonu. Nie zakłada konta u producenta oprogramowania, bo rejestracja odbywa się bezpośrednio w portalu danego magazynu. Formularz dzieli się na sekcję danych transportowych i logistycznych, a termin wybiera się w kalendarzu.

W danych transportowych podaje się numery rejestracyjne pojazdu i naczepy oraz dane kierowcy. W części logistycznej podaje się liczbę palet i rodzaj towaru, a osobne pole wskazuje magazyn docelowy. Kalendarz oznacza dostępność slotów kolorami: zielone okno jest wolne, a pomarańczowe ma ograniczoną pojemność.

Reguła: walidacja w przeglądarce poprawia wygodę, ale nie zastępuje walidacji na serwerze. Każde zgłoszenie jest sprawdzane ponownie po stronie bazy danych.

Kontrola po stronie serwera zamyka rezerwację w tej samej transakcji, w której zapisywany jest rekord awizacji. Przeglądarka wysyła dane żądaniem HTTP, a serwer odpowiada kodem 409, gdy okno zostało zajęte w międzyczasie. Przykład wywołania w JavaScript:

async function zarezerwujOkno(oknoId, formularz) {
  const odpowiedz = await fetch('/api/awizacje', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ oknoId: oknoId, ...formularz })
  });
  if (odpowiedz.status === 409) {
    throw new Error('Okno zostało zajęte, potrzebny jest inny termin.');
  }
  if (!odpowiedz.ok) {
    throw new Error('Nie zapisano awizacji, kod ' + odpowiedz.status);
  }
  return odpowiedz.json(); // numer awizacji i token kodu QR
}

Interfejs Fetch opisuje dokumentacja MDN. Nazwy adresów i pól w przykładzie są umowne. Ogólne zasady budowy takich portali omawia artykuł o aplikacji webowej, a przykład gotowego rozwiązania pokazuje aplikacja awizacyjna na portalu awizacji.

Aplikacja kierowcy i kod QR na bramie

Po zatwierdzeniu formularza system generuje kod QR i wysyła potwierdzenie SMS-em lub e-mailem. Kierowca nie musi instalować niczego, bo wiadomość zawiera kod albo link do niego. Przy wjeździe skanuje kod na terminalu bramowym albo tablecie ochrony.

System weryfikuje tożsamość, sprawdza aktualność awizacji i wyświetla numer rampy z instrukcją dojazdu. Cała odprawa trwa kilkadziesiąt sekund i nie angażuje dyspozytora. Dla transportów ADR system sprawdza dodatkowo wymagane dokumenty, zanim wyda zgodę na wjazd.

Zawartość kodu QR ma znaczenie dla bezpieczeństwa. Kolejny numer awizacji da się odgadnąć, więc kod powinien zawierać losowy token. Poniższy fragment C# tworzy taki token z generatora kryptograficznego.

using System.Security.Cryptography;

string token = Convert.ToHexString(RandomNumberGenerator.GetBytes(16)); // 128 bitów
string tresc = $"AW:{numerAwizacji}:{token}";
// tresc trafia do kodu QR, a token jest zapisany w bazie razem z awizacją

Na bramie serwer porównuje odczytany token z zapisanym i sprawdza, czy awizacja ma status zatwierdzonej. Skan kodu wygasłego albo dotyczącego anulowanej awizacji kończy się odmową.

Szczegóły identyfikacji kierowcy na bramie i przy kiosku opisuje tekst o awizacji kierowcy.

Kierowca bez smartfona lub zasięgu

Nie każdy kierowca ma w chwili wjazdu telefon z dostępem do sieci. Kod z wiadomości można wtedy wydrukować albo podać numer awizacji ochronie, która odszuka wizytę w panelu. Przy dużej liczbie dostaw pomaga kiosk samoobsługowy, przy którym kierowca zgłasza się bez udziału ochrony, co opisuje strona o kiosku samoobsługowym.

Ważne, żeby awaria jednego kanału nie blokowała bramy. Odprawa ręczna zapisuje te same dane i zostawia ślad, że została wykonana bez skanu, więc raport punktualności pozostaje kompletny.

Powiadomienia SMS i e-mail w aplikacji

Automatyczne wiadomości zastępują telefoniczne potwierdzenia i przypomnienia. Kierowca dostaje je w czterech momentach, a każdy z nich odpowiada na konkretne pytanie, które wcześniej zadawał dyspozytorowi.

• Potwierdzenie - wiadomość z kodem QR po złożeniu awizacji.
• Przypomnienie - informacja 24 godziny przed planowanym przyjazdem.
• Zmiana - alert, gdy magazyn zmienia rampę lub godzinę.
• Wezwanie - komunikat z numerem rampy po wjeździe na teren zakładu.

Po stronie magazynu planista dostaje powiadomienie, gdy przewoźnik zgłasza opóźnienie albo anuluje wizytę. Zmiana jest od razu widoczna w harmonogramie, a system może zaproponować zwolniony slot innemu transportowi z listy rezerwowej.

Wysyłka nie powinna blokować zapisu awizacji. Rozwiązaniem jest kolejka w bazie danych: zapis awizacji dodaje wiersz do tabeli powiadomień, a osobny proces pobiera je partiami. Blokada z opcją pomijania zajętych wierszy pozwala uruchomić kilka takich procesów bez podwójnej wysyłki.

WITH nast AS (
    SELECT TOP (50) *
    FROM dbo.KolejkaPowiadomien WITH (ROWLOCK, UPDLOCK, READPAST)
    WHERE Status = 'nowe'
    ORDER BY Id
)
UPDATE nast
SET Status = 'wysylane', PobranoO = SYSDATETIME()
OUTPUT inserted.Id, inserted.Kanal, inserted.Adresat, inserted.Tresc;

Poza SMS-em i e-mailem przeglądarka potrafi wyświetlać powiadomienia push, o ile użytkownik wyrazi zgodę. Interfejs opisuje dokumentacja Push API, a dostępność zależy od przeglądarki i systemu telefonu.

Aplikacja webowa czy natywna - wybór technologii

Wybór technologii zależy od tego, kto z aplikacji korzysta. Przewoźnik zgłaszający dostawę raz na kilka dni nie zainstaluje osobnej aplikacji dla jednego magazynu, więc portal w przeglądarce jest tu naturalny. Inaczej wygląda terminal bramowy albo urządzenie z wbudowanym skanerem, gdzie sprzęt narzuca sposób pracy.

Kompromisem jest aplikacja webowa osadzona w kontrolce przeglądarki aplikacji natywnej. Sposób osadzania opisuje dokumentacja WebView na developer.android.com. Takie rozwiązanie ma sens, gdy interfejs jest już gotowy jako strona, a jedyną potrzebą jest dostęp do skanera terminala. Aplikacje mobilne dla magazynierów, którzy pracują na terminalach, opisuje tekst o aplikacji magazynowej na Androida.

Bezpieczeństwo portalu i dane kierowców

Portal awizacyjny jest dostępny z Internetu, więc przetwarza dane osobowe kierowców i informacje handlowe o dostawach. Ochrona opiera się na szyfrowanym połączeniu HTTPS i sprawdzaniu uprawnień przy każdym żądaniu, a API zwraca tylko to, czego potrzebuje dana rola. Przewoźnik widzi wyłącznie własne awizacje, a filtr po identyfikatorze firmy nakłada serwer, nie przeglądarka.

Reguła: identyfikator firmy pochodzi z sesji zalogowanego użytkownika, nigdy z parametru przesłanego przez przeglądarkę.

Zakres danych kierowcy wynika z potrzeb bramy. Jeśli magazyn nie wymaga numeru dokumentu, pole nie powinno istnieć w formularzu. Okres przechowywania ustala administrator danych, a system powinien pozwalać na usuwanie lub anonimizację rekordów po jego upływie.

Wydajność kalendarza przy szczycie zgłoszeń

W poniedziałkowy poranek wielu dostawców otwiera kalendarz jednocześnie. Zapytanie o wolne okna wykonuje się wtedy bardzo często, więc musi być tanie. Indeks filtrowany obejmuje tylko okna z wolną pojemnością, dzięki czemu jest niewielki i szybko się aktualizuje. Kolumna Wolne jest zmieniana w tej samej transakcji co rezerwacja.

CREATE NONCLUSTERED INDEX IX_OknoCzasowe_Wolne
ON dbo.OknoCzasowe (RampaId, OknoOd)
INCLUDE (Pojemnosc, Zajete)
WHERE Wolne = 1;

Składnię i ograniczenia predykatów opisuje dokumentacja indeksów filtrowanych. Predykat nie może porównywać dwóch kolumn, dlatego potrzebna jest osobna kolumna bitowa zamiast warunku Zajete < Pojemnosc.

Odczyt kalendarza nie powinien też czekać na trwające zapisy. Włączenie opcji READ_COMMITTED_SNAPSHOT dla bazy sprawia, że zapytania czytające korzystają z wersji wierszy zamiast blokad współdzielonych. Rezerwacja nadal używa blokad aktualizacji, więc dwie osoby nie zajmą tego samego miejsca.

Integracja aplikacji z WMS i ERP

Aplikacja awizacyjna działająca w izolacji planuje tylko transport. Dane zyskują wartość dopiero wtedy, gdy płyną do magazynu i do systemu finansowego. Po zmianie statusu awizacji na zaakceptowaną Studio WMS.net odbiera pakiet danych i przygotowuje zlecenie przyjęcia. Magazynierzy widzą na kolektorach, które pozycje mają przyjechać i gdzie towar zostanie odłożony.

Wymiana działa też w drugą stronę. Jeśli WMS zablokuje przyjęcie z powodu braku miejsca albo niezgodności dokumentów, informacja wraca do systemu awizacji i tworzy alert dla planisty. Firmy z ERP takim jak SAP lub enova365 wymieniają dane przez API albo gotowe konektory. Mechanizm opisuje artykuł o integracji VSS z WMS i ERP.

Zgłoszenie dostawy z aplikacji korzysta z tych samych okien czasowych, które planista konfiguruje w panelu. Zasady ich definiowania i obłożenia porządkuje strona o oknach czasowych, a pełne omówienie oprogramowania do zarządzania dostawami zawiera tekst o oprogramowaniu do awizacji dostaw.

Wersje językowe dla kierowców zagranicznych

Standardowo interfejs działa po polsku, ale dostępny jest moduł obsługi wielojęzycznej. Kierowca otrzymuje formularz i wiadomości w swoim języku, na przykład po angielsku albo po niemiecku. Tłumaczenia kolejnych języków, na przykład tureckiego, definiuje się samodzielnie w panelu administracyjnym, bez udziału dostawcy oprogramowania.

Technicznie sprowadza się to do słownika tekstów z kluczami i tabeli tłumaczeń. Zapytanie wybiera tekst w języku kierowcy, a gdy tłumaczenia brakuje, zwraca wersję domyślną. Dzięki temu nowy język można uruchomić stopniowo, bez ryzyka pustych etykiet.

SELECT COALESCE(t.Tekst, d.Tekst) AS Tekst
FROM dbo.Slownik AS d
LEFT JOIN dbo.SlownikTlumaczenie AS t
       ON t.SlownikId = d.Id AND t.Jezyk = @jezyk
WHERE d.Klucz = @klucz;

Język dotyczy także powiadomień: SMS z kodem QR powinien być napisany tak, żeby kierowca zrozumiał go bez tłumacza. Szerzej opisuje to strona o wielojęzycznym programie magazynowym. Dyspozytor pracuje na tych samych rekordach po polsku, więc bariera językowa nie wpływa na harmonogram.

Hosting i wdrożenie aplikacji

Aplikację można uruchomić w modelu SaaS albo na własnych serwerach. Hosting w chmurze zdejmuje z firmy utrzymanie infrastruktury i zapewnia regularną kopię zapasową, natomiast instalacja lokalna odpowiada firmom, które z powodów wewnętrznych muszą trzymać dane u siebie.

Centrum logistyczne obsługujące wielu najemców tworzy osobne harmonogramy z osobnym dostępem dla każdego klienta. Żaden najemca nie widzi awizacji pozostałych. Taka architektura sprawdza się u operatorów 3PL i w dużych zakładach z kilkoma strefami dostaw.

Wdrożenie zaczyna się od analizy przedwdrożeniowej. Mapuje się w niej rampy i dobowy wolumen transportów, a także typy dostaw i istniejące integracje. Na tej podstawie konfiguruje się słowniki i parametry okien, a osobno szablony powiadomień. Szkolenie operatorów zamyka się zwykle w jednym dniu roboczym, a pierwsze awizacje w produkcji przyjmuje się w ciągu dwóch do czterech tygodni od podpisania umowy, zależnie od zakresu integracji. Informacje o platformie zawiera strona awizowanie dostaw w VSS.