Skip to main content
Daily absolute odometer snapshots. Delivered daily. Update key: (vehicle_number, reading_date)not external_system_id

Columns

Rules

  • The update key is the vehicle and date, not external_system_id. Re-sending the same vehicle and date overwrites the earlier value.
  • Values are absolute, not deltas. Missing a day is harmless — the next delivery self-corrects.
  • The odometer must not go backwards. mileage_km must be greater than or equal to the highest stored mileage for that vehicle on any earlier date. A lower value rejects the whole file.
The monotonic check compares against stored readings only, not against other rows in the same file. Two conflicting readings delivered together will both pass validation, and the one with the later reading_date becomes the vehicle’s current mileage. There is also no upper-bound check, so an erroneously large value imports without complaint and will not be correctable by a later, smaller one.

Side effects

This is the file with the widest reach. Importing it:
  1. Updates the vehicle’s current_mileage_km, current_operating_hours and last_reading_update.
  2. Recomputes lifetime mileage for every component currently mounted on that vehicle, as the component’s mileage at mount plus the distance the vehicle has travelled since.
That second effect is why load order matters. If readings are imported before vehicle_configurations in a batch where a component was swapped, the mileage is attributed to the wrong component.

Example

Why a file gets rejected

Validation stops at the first failing stage, so you may see only one of these groups at a time.