Situation #
A person typed a reading with a slipped digit, or the instrument cluster was swapped and the new meter starts low. The asset shows a flag of regression ("Lower than before") or suspect ("Unusually large jump"), or the maintenance board shows a service far too early or too late. The Fleet screens arrive with the web console. Until then you work through the API.
What keeps working #
- Dispatch, jobs, fuel fills, inspections and every other Fleet record.
- New readings. The log only ever grows: a correction adds a new row that voids the old one, and the old row stays visible with
voided: true. - Reading
GET /fleet/assets/{id}, which shows the current reading, the lifetime distance and how many drops still need your confirmation (regressions_to_confirm).
Steps in order #
- Call
GET /fleet/assets/{id}/meters?meter=distance. Rows come newest first. Look for aflagofregressionorsuspect, and for a value that does not fit its neighbours. Note theidof the wrong row. - Choose what happened.
- The number was mistyped: correct it. Call
POST /fleet/meters/{id}/correctwith{"value": 10500}. The value is in the asset's own unit (kilometers or miles), and the reading keeps its original time. - The number is right and the drop is real, for example a clock reset you accept: call the same path with
{"confirm": true}. The row is flaggedconfirmedand stops counting as something to review. - The meter was replaced: call the same path with
{"replacement": true}on the first reading of the new meter. The row is flaggedreplacedand starts a new epoch.
- The number was mistyped: correct it. Call
- Add an optional
noteto any of these calls so the next person sees why. - When the new meter keeps counting, add readings as usual with
POST /fleet/assets/{id}/meters. They count from the new meter's first reading. - If the correction answer is
conflict(409), that reading was already corrected. Correct the newer row instead. It is the one withoutvoided: true.
How to confirm it worked #
GET /fleet/assets/{id}showsregressions_to_confirmat 0 and theodometeryou expect.- After a replacement,
lifetime_distanceequals the old meter's final value plus the distance since the swap. With 90,000 km before the swap and a new meter that reads 10 and then 510, lifetime distance reads 90,500 km. - The list from step 1 shows the old row as
voided: trueand the new row with itsvoids_id.
What changes afterwards #
- Maintenance due dates. The maintenance board works from the lifetime distance built from the readings still standing. A drop adds nothing to lifetime distance, and a replacement continues from the old total. After a correction the board shows the new figure the next time you read it. Check
GET /fleet/pm/board. A service you already completed keeps the reading that was recorded with it, so look at those rows too. - Fuel economy.
GET /fleet/assets/{id}/fuel/economymeasures distance between full fills from the same reading log, so a corrected reading corrects the segments built on it. A segment that was left out because of a bad reading is labeled with the reason and returns once the data is sound. - Estimates. A distance from GPS positions never writes the odometer. A typed reading is always the source.
Technical details
- Readings are stored in meters, hours in hundredths. The person sees the tenant's units.
- A drop is accepted and flagged, never refused. A jump above 2,000 km a day is flagged
suspectand never refused. - Lifetime distance adds only the positive step between consecutive readings of one epoch.
- A fuel fill with a typed odometer writes a reading with source
fuel. Correct that row in the meter log. - Needs the
dispatch_fleetlicense flag for writes.