Fleet & Vehicle Logistics Master Data

A design reference for the vehicle, driver, and license-category records that support delivery-trip assignment

1. Requirements

1.1 Functional requirements

Maintain a Vehicle master record per physical vehicle: plate, make/model, an odometer reading set once and never reset, fuel type and unit, an optional responsible employee, and optional insurance/physical-spec fields.
Maintain a Driver master record per person assignable to a delivery: name, status, an optional link to an internal employee (staff drivers) or an external transporter (contracted drivers), contact details, and license categories held.
Maintain Driving License Category as a reusable child-row shape (class, description, issuing/expiry dates) attached to a driver.
Keep a driver’s login account in sync with the linked employee’s login account, when one exists.
Let both Vehicle and Driver be selected by a delivery trip’s fleet-assignment step (documented in the delivery-and-shipment-logistics reference in this set) rather than re-typed per trip.

1.2 Non-functional requirements

Referential reuse: a vehicle or driver is entered once and referenced by every trip that uses it, rather than copied.
Data-entry guardrails: implausible dates (an insurance end date before its start, a future carbon-check date) are rejected at save time.
External-driver support: a driver need not be an employee at all — a contracted driver linked to a transporter is a first-class case, not a workaround.

1.3 Constraints

This document covers the master data only; the delivery-and-shipment-logistics reference already establishes how a trip’s driver/vehicle selection is written back onto the delivery documents it serves, and that mechanism is not re-derived here.
Neither record carries a state machine — Vehicle has no status field at all, and Driver’s status is a bare three-value label with no transition logic anywhere in this tree.
No fuel-consumption, mileage-cost, or maintenance-scheduling logic exists — the odometer is captured once and never updated by any code path read for this document.

2. High-Level Design

2.2 What the master data actually connects to

Vehicle and Driver are simple, standalone masters with exactly one live consumer each: a delivery trip’s fleet-assignment step.

A vehicle’s dashboard also lists a second consumer, a vehicle-log record type, but no such record type exists anywhere in this codebase — a stale link to a record removed when this functionality was reorganized.
Driving License Category has no consumer outside Driver — a pure shape declaration for the child table, never queried independently.
Neither Vehicle nor Driver is scoped to a specific trip participant list; either can be selected on any trip regardless of which entity created it. Vehicle carries an optional legal-entity field for reporting/filtering; Driver carries none at all.

The single real coupling — Vehicle and Driver feeding a trip’s mandatory driver/vehicle fields, which the trip writes back onto the note(s) it serves as a plain identifying string, not a live link — is the same field-level, one-directional write-back already established in the delivery-and-shipment-logistics reference. The master-data side of it is two flat records with no logic of their own.

3. Deep Dive

3.1 Data model

Vehicle Named by its own license plate. Required: plate, make, model, an odometer value set only once, fuel type (a small closed list), and a fuel unit of measure. Optional: acquisition date, free-text location, chassis number, a currency value, a responsible employee, and an insurance block (company, policy number, start/end dates), plus a few physical-spec fields. No status field, no lifecycle beyond the standard submit/cancel/amend envelope every submittable record carries.

Driver Named by an auto-generated series, not its own data. Required: full name and a status (Active, Suspended, or Left — a plain label with no code anywhere read for this document that transitions it automatically). Optional: a link to an internal Employee, a link to a Supplier flagged as an external transporter, contact fields, license number and dates, plus the license-category child table. If an employee link is set, the driver’s login-account field is overwritten from that employee’s on every save — the one piece of active logic in the record.

Driving License Category A child-row shape (class, description, issuing date, expiry date) with no logic of its own — always read and written as part of a driver record.

3.2 Consumption contract

The only production code path reading either master is the trip’s fleet-assignment step: it requires a vehicle and (to submit) a driver, and on save/submit/cancel copies the driver’s identity, display name, and the vehicle’s plate onto every note the trip serves — as plain fields, not links back to Vehicle or Driver. Neither master is otherwise read, computed from, or written to elsewhere in scope.

3.3 Error handling

Vehicle: an insurance start date after its end date is rejected, and a carbon-check date in the future is rejected. No other field-level validation exists.
Driver: the only active rule is the login-account sync from a linked employee; nothing guards license-category dates, and no cross-check exists between a driver’s own license number and its category rows.
Driving License Category: no validation at all — expiry before issuing date is representable and accepted.

4. Scale and Reliability

Volume is inherently small and administrator-driven. Vehicle and Driver counts track a fleet’s physical size, not transaction volume, so neither is a load-bearing path the way a transactional document is.
No caching or precomputation is needed or present: both are looked up directly by name/plate whenever a trip references them.
The stale vehicle-log dashboard reference is latent maintenance debt, not a reliability risk today — it costs nothing at runtime, but will produce a broken link if that connections list is ever rendered against a fresh install missing the removed record type.

5. Trade-off Analysis

Decision	Trade-off
Vehicle and Driver carry no status/lifecycle field	Nothing to model or keep consistent — but no way to represent “temporarily out of service” other than deleting or renaming the record, so a dispatcher relies on outside knowledge.
Driver supports both an internal employee link and an external transporter link on one record	One shape covers both staffing models without a second record type — at the cost of a record whose meaning shifts by which optional link is filled in, with nothing forcing exactly one.
License-category expiry is captured but never validated against today’s date	Simple to enter, no false rejections — but an expired category raises no warning, so using it as a compliance control needs a separate report.
The trip writes the vehicle’s plate and driver’s identity onto the note as plain fields, not live links	The note keeps a durable snapshot even if the master record is later renamed or removed — at the cost of never reflecting a later correction to it.

6. What to Revisit as the System Grows

Add an availability/status concept to Vehicle and Driver (out of service, on leave, decommissioned) once fleet size outgrows tracking availability by memory or a side spreadsheet.
Validate license-category expiry against the trip’s date at assignment time, if this master data is ever meant to double as a compliance control rather than a reference list.
Remove or replace the stale vehicle-log dashboard reference before it surfaces as a broken link on a fresh install.
This document stays short by design: three small, logic-thin master records and one real external seam are the whole of what exists here, and padding the write-up further would misrepresent how little mechanism backs this part of the system.