Program dla firmy transportowej, który scala dane floty w jednym modelu

Program dla firmy transportowej a rozproszone dane floty

W typowej firmie transportowej dane o flocie leżą w kilku miejscach. Lokalizacje pojazdów pokazuje panel dostawcy GPS, czas pracy kierowców zapisuje tachograf, wydatki na paliwo widać w rozliczeniu kart, a zlecenia siedzą w arkuszu albo w programie do spedycji. Każde z tych źródeł odpowiada na jedno pytanie i żadne nie odpowie na pytanie o rentowność konkretnego kursu.

Koszt takiego rozproszenia jest widoczny dopiero przy zestawieniu. Dyspozytor ręcznie przepisuje numery rejestracyjne, księgowość dopasowuje faktury paliwowe do kursów po dacie i kwocie, a menedżer dostaje raport z opóźnieniem tygodnia. Artykuł o tym, dlaczego arkusze kalkulacyjne w transporcie prowadzą do strat, opisuje ten mechanizm od strony finansowej.

Reguła: dane floty stają się użyteczne dopiero wtedy, gdy każdy rekord da się przypisać do pojazdu i kierowcy, a zarazem do konkretnego kursu.

Wspólny model danych floty i zleceń

Encje i klucze

Program dla firmy transportowej opiera się na czterech encjach o stabilnych kluczach. Pojazd i kierowca opisują zasoby, zlecenie opisuje zobowiązanie wobec klienta, a kurs łączy te trzy elementy, więc na nim zapisuje się przebieg i koszty. Pozycje GPS oraz tankowania są rekordami podrzędnymi, a zdarzenia z tachografu dołączają do kursu po tym samym kluczu: pojeździe i czasie.

Poniższy szkic w T-SQL pokazuje układ dwóch głównych tabel. Nazwy są przykładowe i nie odpowiadają schematowi żadnego konkretnego produktu.

CREATE TABLE dbo.Pojazd (
    PojazdId  int IDENTITY PRIMARY KEY,
    NrRej     nvarchar(16) NOT NULL UNIQUE,
    Typ       nvarchar(30) NOT NULL,
    Aktywny   bit NOT NULL DEFAULT 1
);

CREATE TABLE dbo.Kurs (
    KursId     int IDENTITY PRIMARY KEY,
    ZlecenieId int NOT NULL,
    PojazdId   int NOT NULL REFERENCES dbo.Pojazd (PojazdId),
    KierowcaId int NOT NULL,
    Start      datetimeoffset NOT NULL,
    Koniec     datetimeoffset NULL,
    Km         decimal(9,1) NULL,
    Status     varchar(20) NOT NULL
);

Klucz naturalny, czyli numer rejestracyjny, przydaje się przy imporcie z urządzeń, a klucz sztuczny zabezpiecza relacje przed zmianą tablic. Pojazd sprzedany i zarejestrowany ponownie nie może zmienić historii kursów, dlatego rekord oznacza się jako nieaktywny, a nie usuwa.

Historia przypisań i ślad audytowy

Kierowca i pojazd zmieniają się w czasie, więc przypisanie zapisuje się jako rekord z datą początku i końca, a nie jako pole w tabeli pojazdu. Dzięki temu raport za miesiąc ubiegły nie zmieni wyniku po zmianie przydziału, a każda korekta danych ma autora i znacznik czasu. Ślad audytowy przydaje się także przy sporze z klientem o termin dostawy.

Uprawnienia i dane osobowe kierowców

Ten sam model danych obsługuje różne role. Dyspozytor widzi wszystkie pojazdy, kierowca tylko własny kurs, a księgowość koszty bez pozycji GPS. Uprawnienia definiuje się na poziomie rekordu, nie ekranu, bo ten sam raport otwarty przez inną osobę powinien pokazać inny zakres.

Lokalizacja pojazdu przypisanego do kierowcy jest daną osobową. Zasada minimalizacji wymaga więc, by pozycje starsze niż okres potrzebny do rozliczeń były agregowane albo usuwane, a dostęp do szczegółowych tras miały tylko osoby, które ich potrzebują do pracy.

Kurs jako jednostka rozliczenia

Kurs jest najmniejszą jednostką, dla której da się policzyć przychód oraz koszt, a z nich marżę. Zlecenie może się składać z kilku kursów, na przykład przy przeładunku, a jeden kurs może obsługiwać kilka zleceń przy zbiórce drobnicy. Model musi to dopuszczać, więc relacja zlecenie-kurs bywa wiele do wielu, a nie jeden do jednego.

Od tego wyboru zależy raportowanie. Jeśli koszt trasy jest przypisywany do zlecenia bez podziału na kursy, nie da się porównać dwóch pojazdów obsługujących ten sam ładunek. Dlatego pomiar kosztu zaczyna się od kursu, a agregację do zlecenia wykonuje się dopiero w raporcie.

Integracja źródeł GPS przez integrator

Wiele urządzeń, jeden strumień

Firma z flotą kupowaną w kilku okresach ma zwykle lokalizatory różnych dostawców. Integrator sprowadza ich dane do jednego formatu, dzięki czemu program transportowy odczytuje pojazd tak samo bez względu na producenta urządzenia. Zasadę opisuje artykuł o integratorze GPS dla flot, a pełniejszy przegląd - tekst o kontroli danych GPS w linkway.INTEGRATOR.

Przykładem jest system AKTKC do zarządzania danymi GPS i telematyką. Jego producentem jest firma AKT, a Linkway nie prowadzi kont ani paneli logowania tego systemu. Integracja polega na tym, że dane z AKTKC trafiają do platformy linkway.INTEGRATOR i dalej do modułu TMS, o czym informuje strona integracji AKTKC z Linkway.

Co daje integracja z telematyką

Po połączeniu źródeł dane telemetryczne trafiają do jednego miejsca. Zamiast przełączać się między aplikacjami, dyspozytor widzi lokalizację ciężarówek i parametry ich pracy w jednym widoku. Poniższa tabela zestawia funkcje integratora z korzyścią dla floty.

Jakość danych telematycznych

Przyjmowanie danych w formacie JSON

Dane z urządzeń przychodzą najczęściej jako komunikaty JSON. SQL Server potrafi rozłożyć je na wiersze funkcją OPENJSON, bez pisania parsera po stronie aplikacji. W przykładzie wstawiane są tylko pozycje, których jeszcze nie ma w tabeli, co chroni przed duplikatami po ponownym wysłaniu paczki.

DECLARE @json nvarchar(max) = N'[
  {"vehicle":"PO12345","ts":"2026-03-02T08:15:30Z",
   "lat":52.406,"lon":16.925,"fuel":312.5}
]';

INSERT dbo.PozycjaGps (NrRej, Czas, Lat, Lon, Paliwo)
SELECT j.vehicle, j.ts, j.lat, j.lon, j.fuel
FROM OPENJSON(@json)
     WITH (vehicle nvarchar(16) '$.vehicle',
           ts      datetimeoffset '$.ts',
           lat     float '$.lat',
           lon     float '$.lon',
           fuel    float '$.fuel') AS j
WHERE NOT EXISTS (
    SELECT 1 FROM dbo.PozycjaGps AS p
    WHERE p.NrRej = j.vehicle AND p.Czas = j.ts);

Numer rejestracyjny w przykładzie jest wymyślony, a struktura pól ma charakter poglądowy. W rzeczywistości identyfikator z urządzenia mapuje się na pojazd tabelą powiązań, bo ten sam lokalizator bywa przenoszony między ciężarówkami.

Deduplikacja i znaczniki czasu

Największe źródła błędów w danych telematycznych to duplikaty i rozbieżne czasy. Urządzenia po utracie zasięgu wysyłają zbuforowane paczki, które nakładają się na wcześniejsze. Sortowanie po czasie urządzenia, a nie czasie odbioru, przywraca poprawną kolejność, a unikalny indeks na parze pojazd i czas odrzuca powtórzenia.

Czas należy przechowywać z przesunięciem strefowym. Kurs międzynarodowy przekracza granice stref, a przy zmianie czasu na letni lokalny znacznik bez przesunięcia daje godzinne rozbieżności w czasie pracy kierowcy.

Od zlecenia do rozliczenia - statusy kursu

Cykl życia kursu w systemie

Ręczne przetwarzanie zleceń jest czasochłonne i prowadzi do błędów. Program automatyzuje ten proces od przyjęcia zlecenia do rozliczenia, a po drodze przypisuje pojazd i monitoruje realizację. Każdy etap ma własny status, więc żadne zlecenie nie znika bez śladu, a stan realizacji jest udokumentowany.

Najważniejszy jest moment przejścia z „dostarczony” do „rozliczony”. Skoro informacja o dostawie trafia do systemu od razu, dział księgowości może wystawić fakturę bez czekania na dokumenty papierowe, co poprawia płynność finansową. Aplikacja kierowcy, opisana w artykule o aplikacji dla kierowcy i kosztach opóźnień, jest tu głównym źródłem potwierdzeń.

Koszt kilometra i rentowność trasy

Zapytanie liczące koszt kilometra

Wspólny model danych umożliwia policzenie kosztu kilometra dla każdego pojazdu jednym zapytaniem. Koszty kursu sumuje się najpierw osobno, żeby złączenie z kursami nie zdublowało kilometrów, gdy do jednego kursu przypisano kilka pozycji kosztowych.

WITH koszt AS (
    SELECT KursId, SUM(Kwota) AS Kwota
    FROM dbo.KosztKursu
    GROUP BY KursId
)
SELECT k.PojazdId,
       SUM(k.Km)    AS Km,
       SUM(c.Kwota) AS Koszt,
       SUM(c.Kwota) / NULLIF(SUM(k.Km), 0) AS KosztKm
FROM dbo.Kurs AS k
LEFT JOIN koszt AS c ON c.KursId = k.KursId
WHERE k.Start >= '20260301' AND k.Start < '20260401'
GROUP BY k.PojazdId;

Wynik pokazuje pojazdy, które odbiegają od średniej floty. Odchylenie wymaga jednak interpretacji: wyższy koszt kilometra może wynikać z gorszego stanu technicznego, ale także z trudniejszych tras albo z dłuższych postojów przy załadunku.

Koszty bezpośrednie i pośrednie

Do kursu przypisuje się koszty bezpośrednie, na przykład paliwo i opłaty drogowe. Koszty pośrednie, takie jak amortyzacja czy ubezpieczenie, rozdziela się według przyjętego klucza: kilometrów albo dni użytkowania. Wybór klucza zmienia wynik, więc musi być jawny i stały w całym okresie porównania.

Wskaźniki do oceny floty

Informacje gromadzone przez program transportowy przekształcają się w wiedzę dzięki modułom analitycznym. Menedżer może analizować rentowność poszczególnych tras, oceniać efektywność kierowców i monitorować koszty eksploatacji każdego pojazdu. Aby wyniki były porównywalne, wskaźniki liczy się według stałych definicji.

• Koszt kilometra - suma kosztów kursu podzielona przez przejechane kilometry.
• Przebieg pusty - udział kilometrów bez ładunku w całym przebiegu pojazdu.
• Zużycie paliwa - litry na sto kilometrów, porównywane z normą dla typu pojazdu.
• Wykorzystanie czasu pracy - udział czasu jazdy i obsługi w dostępnym czasie kierowcy.

Wyniki ma sens porównywać w obrębie tej samej klasy pojazdów i podobnych tras, bo inaczej zestawia się rzeczy nieporównywalne. Wnioski z takich analiz są podstawą decyzji o wycofaniu nierentownych połączeń i planowaniu inwestycji w tabor, w duchu opisanym w tekście o kryteriach zwrotu z integratora dla flot.

Wymiana danych z księgowością i ERP

Faktury sprzedażowe wynikają ze zleceń, a kosztowe z paliwa i usług podwykonawców. Aby księgowość nie dopasowywała ich ręcznie, numer kursu powinien być polem dokumentu w obu kierunkach. Wtedy koszt trafia na właściwy kurs w chwili zaksięgowania faktury, a status „rozliczony” może zmienić się automatycznie.

Wymiana odbywa się zwykle przez interfejs API albo przez pliki. REST z formatem JSON pozwala przekazywać pojedyncze zdarzenia niemal na bieżąco, natomiast eksport plikowy sprawdza się przy starszych systemach i przy rozliczeniu wsadowym na koniec dnia. W obu wariantach potrzebny jest klucz idempotencji, czyli identyfikator dokumentu, po którym system rozpozna powtórzenie.

Ustalenia między systemami trzeba też zapisać w regułach: który z nich jest źródłem prawdy dla kontrahenta, a który dla kursu. Brak takiego podziału bywa częstą przyczyną rozbieżności, gdy oba systemy pozwalają edytować te same dane.

Flota a magazyn i planowanie transportu

Dane o flocie mają znaczenie także poza transportem. Planista magazynu potrzebuje informacji o liczbie pojazdów oraz godzinach przyjazdu, żeby przygotować rampy i obsadę. Studio WMS.net, opisany w artykule o systemie WMS i jego zakresie funkcji, prowadzi stany i dokumenty magazynowe, a dane o planowanych dostawach można wymieniać z modułem transportowym, co opisuje artykuł o stanach magazynowych i tekst o planowaniu transportu.

Po stronie firmy transportowej odpowiednikiem jest kalendarz okien, w którym kurs ma zarezerwowany termin rozładunku. Sposób prowadzenia takiego kalendarza przedstawia artykuł o kalendarzu dla firmy transportowej, a ogólny przegląd zadań programu transportowego - tekst o oprogramowaniu, które porządkuje pracę firmy transportowej.

Zakres integracji i jego granice

Nie każde źródło warto integrować od razu. Rozsądna kolejność zaczyna od danych, które bezpośrednio wpływają na koszt kursu, czyli od pozycji i paliwa, a dopiero potem obejmuje zdarzenia z czujników pomocniczych. Każde kolejne źródło zwiększa liczbę reguł jakości danych, którymi ktoś musi się zajmować. Moduł zbierający dane z tych źródeł opisuje strona linkway.INTEGRATOR u producenta.