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: