external_system_id
Columns
Rules
- Every row needs at least one of
vehicle_number/component_serial_number. vehicle_numberandcomponent_serial_numbermust resolve within the project, or the file is rejected.product_group_codemust resolve to a product group of the vehicle’s type, or the file is rejected. On a component-only row the vehicle is the one in the configuration record coveringdefect_datetime; a component with no covering record, or with overlapping ones, has no vehicle type to resolve the code on and the row is rejected.slot_positiononly means something together withproduct_group_code— the pair identifies a slot on the vehicle’s type. The vehicle type comes from the vehicle; never send it.- A
slot_positionthat is sent must resolve, or the file is rejected. Leave it empty when the source does not know the position; the mount history fills the slot where it can. locationis free text and is never parsed. Send the position inslot_positionif you want it recorded as a position; writingBogie 1inlocationdoes not resolve a slot, and neither field replaces the other.
Every reference in this file is hard: a value that is sent must resolve, or the file is
rejected. Optional references may be left empty.
Resolution rules
The import resolves the fields the row names first, then fills those still empty from the configuration record coveringdefect_datetime — mounted_at at or before it, and either
still open or dismounted after it. Derivation reads whatever mount history is already
loaded, so vehicle_configurations must be imported before defects.
- Explicit values win.
slot_positionis matched against the slots defined on the resolved product group or any of its ancestors on the vehicle’s type; the nearest node wins. The search never descends — a code above the slot’s node does not resolve. Surrounding whitespace is trimmed before matching. A position that matches nothing rejects the file; the mount history never stands in for a wrong position, and never overrides a resolved one. - A component derives its vehicle and slot. A row with a
component_serial_numbertakes its missingvehicle_numberand slot from the covering mount, and through the derived vehicle resolves itsproduct_group_codeas well; without exactly one covering mount the row is rejected (see Rules). A mount on a different vehicle than the row resolved leaves the slot empty; the warning names both vehicles. - A slot derives its component. A row with a resolved vehicle and slot but no serial
takes the component mounted there at
defect_datetime.
defect_datetime derive nothing and
warn, and a missing covering mount derives nothing and is silent. A component-only row in
either situation is rejected, because its product group cannot resolve.
Re-imports treat the three derived links — vehicle, component and slot — identically: a
resolved value overwrites the stored one, an unresolved value keeps it. A row whose mount
history derived nothing can therefore still carry a value from an earlier import, and an
empty column never clears a link — corrections require re-sending a row that resolves. The product group always
resolves, so it is always replaced.
Example
slot_position empty —
the traction inverter is not a slotted position on this type, and location carries what is
known about where it sits.
Why a file gets rejected
N is the row number in the file, and the quoted values are echoed from that row.
Warnings, which do not reject the file. There are three, one per situation, and each is
emitted only when the field it names actually ends up empty (<ts> is the row’s
defect_datetime):