Skip to main content
Condition measurements — wheel diameter, flange thickness and similar. Delivered daily. Update key: external_system_id This is the most strictly validated file in the import. Four separate rules can reject it beyond the usual reference checks, and they abort in stages, so fixing one class of problem can reveal another.

​
Columns

​
Rules

Every row needs at least one of vehicle_number / component_serial_number.

​
A threshold must be configured

A threshold must exist for the (measurement_type_code, component_type_code) pair, or the measurement is refused outright. This is a configuration step done in the application — the pair’s existence is what registers it as importable at all.

​
The value must be within bounds

value must fall inside that threshold’s minimum and maximum. Bounds are inclusive: a value exactly equal to the limit passes. Each bound is only enforced when it is configured, so a threshold with neither set enforces nothing while still satisfying the check above.

​
Position must match the active mount

position must equal the slot position of the component’s active mount at measured_at. Send it when the component was mounted; leave it empty when it was not. A mismatch, a missing position on a mounted component, and a position on an unmounted one all reject the file.
This check runs only for rows that resolve to a component. On a vehicle-only row, position is accepted without being checked. Note also that “empty” must mean a genuinely empty field — a whitespace-only value is treated as set, and will fail.

​
Values may not move against the progression rule

A measurement type may declare a progression rule. A DESCENDING type such as wheel diameter may not increase; an ASCENDING type may not decrease. An equal value never violates the rule. The exception is a reset action: if action_code is one of that type’s configured reset actions — a reframing resetting a wheel diameter, for instance — the movement is allowed. Comparison is per component and measurement type, across both the file and existing data, and deliberately follows the component between slots: position is not part of the comparison, so a wheelset moved to another position is still compared against its own history.
“Prior” means the single most recent measurement with a strictly earlier measured_at. Delivering measurements out of chronological order therefore compares against the wrong neighbour and can reject a perfectly valid file. Send them in order where you can.

​
Action codes must be allowed

When action_code is given it must be one of the measurement type’s allowed action codes. The check is skipped entirely if the type has no allowed list configured.

​
Example

A mounted wheelset, with position matching the active mount:
An unmounted component — no vehicle_number, empty position — and a reset action that permits the diameter to increase:

​
Why a file gets rejected

Required fields first:
Then reference resolution:
Then type matching and the threshold gate:
Finally position, bounds, action codes and progression together: