Skip to main content
Mount and dismount events — which component is fitted in which position on which vehicle. Delivered daily. Update key: external_system_id — one identifier per mount period, reused to close it
This file must be loaded before the others. Defects and measurements cross-check against configuration data, and vehicle readings recompute component mileage from the active mounts. Loading readings first corrupts recorded component mileage whenever a component is swapped in the same batch.

​
Columns

​
A dismount is not a new row

This is the most common mistake with this file. To record a dismount, re-send the original mount row with the same external_system_id, now carrying dismounted_at, dismounted_mileage_km, dismount_reason and depot, and a newer last_updated. Sending a separate row with a new identifier creates a second mount period rather than closing the first.
The reverse also applies: re-sending a row whose dismounted_at is empty, with a newer last_updated, re-opens a closed mount period. Your exporter must carry the dismount fields forward once they are set.

​
Rules

  • The slot must resolve from the combination of vehicle type, product_group_code and slot_position — and here the product group must match the slot’s node exactly, and a miss rejects the file. This is stricter than the same column pair on defects, where the code may sit below the slot’s node (the ancestor walk) and a miss only warns: a configuration row defines where a component sits and must be precise, while a defect merely quotes the code its reporter had.
  • The component’s type must be among the slot’s allowed component types.
  • The component must not be in a repair-workflow status — IN_TRANSIT, IN_TRANSIT_BACK, UNDER_REPAIR or SCRAPPED. A part in any of those states cannot physically be on a vehicle. MOUNTED, DISMOUNTED and IN_STORE are accepted.
  • A component can be actively mounted in only one place, and a slot can hold only one active component. Dismounts in a file are applied before mounts, so a slot handover can be delivered in a single file.
depot on a dismount is enforced by a database constraint, not by validation. It is not in the required-field list, so a dismount missing its depot passes validation and then fails at load time as a raw constraint violation — without a row number. If a file fails with an error that names no row, this is the first thing to check.

​
Side effects

Importing this file sets the component’s status (MOUNTED or DISMOUNTED) and its current_location — the vehicle number while mounted, the depot once dismounted — and finalises the component’s lifetime mileage on dismount.

​
Example

A mount:
The same mount period later closed — note the identical external_system_id, the retained mount fields, and the bumped last_updated:

​
Why a file gets rejected

Required fields are checked first and abort before anything else runs:
Then references, types and status together: