Dispatch in two shapes, for two kinds of work
There is a per-vehicle timeline for when you drag an assignment from one place to another, and a grid for when you filter and sort. A dispatcher scans far more often than they drag, so the second is not a secondary view — it is the main screen on most days.
Maps and positions come from telematics. Provider connections are configured through environment variables, and when a provider is not configured the screen says so instead of showing an empty map.
Compliance is assessed on the server, not in the browser
Driving and rest times are checked against Regulation (EC) 561/2006. Cabotage and posting are assessed by reading the vehicle's whole operation history, not its last trip.
Both run server-side, deliberately: an operator must not be able to reach a different answer from the one an inspector would reach looking at the same data.
e-Transport as a proposal, not a form
The system reads the goods movements you already recorded, applies the fiscal rule and proposes the declarations that are due, with their UIT code. You do not fill a blank form and you do not depend on someone remembering — you start from what your own records already say.
Per-diem, with the taxable part separated
Per-diem is computed per trip, and the ceilings are relative to the driver's salary. The taxable and non-taxable parts are split at calculation time and stored that way — not estimated at month end, when it is too late to change anything.
Cost and revenue on the same trip
Fuel, subcontractors and rates attach to the trip. Transport orders become invoices, and margin is visible per trip rather than only per month. Drivers' personal data has its own screen, under the access regime it deserves.
Worth knowing
Fines in road transport rarely come from a badly driven trip; they come from a missing or late document. That is why compliance is not a report you run at the end, but something the system assesses as you record the trips.