Vehicle and driver assignment without clashes

Assigning the wrong driver, or a vehicle with an expired document, to a transfer trip is usually noticed not at assignment time but with a guest waiting at the airport. This article explains which checks run automatically in transfer software when a driver and vehicle are assigned to a trip, how document validity stops an assignment outright, and which information stays visible versus hidden.

Two checks run the moment you assign

When a driver or vehicle is assigned to a trip, the system checks two things: whether that same driver or vehicle already has another open trip (planned or on the way, drafts excluded) in an overlapping time window, and whether the passenger count exceeds the vehicle’s seat capacity. Both work on a “warn, don’t block” basis — the system will not stop you, but it will not let you miss it either, because some overlaps are a deliberate choice, such as one vehicle running two short trips back to back. The capacity warning is read straight from the vehicle’s record in fleet management, so you never enter a separate capacity field on the trip side.

Document validity: a hard gate, not a warning

Unlike the clash and capacity checks, the validity check that document tracking provides is a hard gate, not a warning. If the vehicle’s inspection, its compulsory insurance, or the driver’s professional licence (SRC) has expired, the trip cannot move to “on the way” — the document’s validity date is checked and, if it has lapsed, the transition is blocked outright, not merely flagged. This distinction is deliberate: a time clash is an operational choice, while setting out with an invalid document is a real problem at a roadside inspection, and a firm cannot soften that on its own.

Sensitive documents: validity, not content

Some documents — a driver’s criminal record, a psychological fitness report, a health certificate — fall into the category KVKK treats as special category personal data. What the assignment screen shows for these is only the validity state, “valid” or “expired” — never the document’s own content, such as a report’s result or a record’s detail. Anyone who needs to see the document itself requires a separate, narrower permission; this separation lets the assignment gate function without requiring everyone who assigns a trip to also have access to sensitive data.

Extra rules for D2

For transfer companies holding a D2 authorisation — those reporting to U-ETDS — the assignment gate asks for two more fields: a complete driver identity number and a validly recorded vehicle plate. Without these, a trip cannot move to “on the way,” because U-ETDS reporting cannot be submitted without this data either; the gate here satisfies two different obligations at once — road safety and regulatory reporting.

“Who was on this vehicle at this hour”

When a traffic fine arrives, or a customer complaint opens with “the driver who picked me up yesterday morning,” the answer is already sitting in the trip record: which driver was assigned to which vehicle, at what date and time, resolves in a single query. Keeping this information in the trip record instead of scattered notebooks or a driver’s memory is what lets you answer that question in minutes rather than hours.

Example: a double-assignment attempt in a two-vehicle fleet

In a two-vehicle transfer business, a dispatcher tries to assign a 07:00 trip to vehicle 34 ABC 123; the system warns that the same vehicle is already assigned to another trip between 06:45 and 07:30. The dispatcher assigns the second vehicle instead, but notices its inspection expired three days ago — the system will not let this vehicle move to “on the way” either. The dispatcher temporarily adds a third, rented vehicle to the system and assigns the trip to it; since its inspection and insurance are valid, the assignment completes without issue and the guest is picked up on time. For businesses running rented or subcontracted vehicles, this matters too: a subcontracted vehicle added temporarily to the system goes through the same document and capacity checks as one of your own fleet, with no different treatment.

How this works in Rotenta

1. When a driver and vehicle are selected on the trip screen, seat capacity read from filo (fleet) and the time-clash check both run at once; both surface as warnings.
2. At the moment of assignment, the belge takibi (document tracking) module checks the driver’s and vehicle’s valid documents; the result shows only as “valid” or “expired,” never the document’s content.
3. If a document has expired, the trip cannot move to “on the way”; the system states which document is the problem.
4. With the D2 profile switched on, the sefer (trip) module also checks the driver’s identity number and the vehicle’s plate format.
5. Every completed assignment stays permanently on the trip record; “who was on this vehicle at this hour” can be answered later with a single query.

Frequently asked questions

Does a clash warning block the assignment?

No; a time clash or a capacity overrun only shows as a warning, and you can proceed deliberately. Document validity is different and genuinely blocks the assignment.

Can we never assign a driver whose document has expired?

The assignment can be made while the trip is still “planned,” but the trip cannot move to “on the way” — this is the same state-transition mechanism we describe in airport transfer day.

Who can see the content of a criminal record or health certificate?

That requires a separate, narrower permission than the one needed to make an assignment; the assignment screen only ever shows validity.

Are these checks connected to U-ETDS reporting?

Yes, the driver identity number and plate information the assignment gate requires under the D2 profile are the same fields U-ETDS reporting needs.

Is this useful for a small fleet too?

Yes; even with two or three vehicles, automated document tracking beats remembering an expiry date by hand. Reach us on the contact page with questions about which modules fit your setup.