external_system_id
Columns
Rules
- Every row needs at least one of
vehicle_number/component_serial_number. - Every row needs at least one of
subsystem/product_group_code. vehicle_numberandcomponent_serial_numbermust resolve within the project, or the file 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.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.
product_group_code and slot_position are the only soft references in the entire
import. If either cannot be resolved, the row is still imported with that field empty and
a warning is logged rather than the file being rejected. Because it is only a warning, a
systematically wrong code will import silently for months.One exception: a row whose product_group_code does not resolve and whose subsystem
is empty has no classification left at all, and is rejected with a row number — such a row
could not be stored anyway. Note that on a component-only row the code resolves through
the mount-derived vehicle, so for this row shape a gap in the configuration history can be
what triggers the rejection.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 resolved position is never overridden by the mount history. - 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. 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; a missing covering mount
derives nothing and is silent.
Re-imports treat all four resolved links — vehicle, component, product group and slot —
identically: a resolved value overwrites the stored one, an unresolved value keeps it. A
warned row 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.
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 six, one per situation, and each is
emitted only when the field it names actually ends up empty (<ts> is the row’s
defect_datetime):