Start a trial
Color

A wrong odometer reading was entered

Find a wrong meter reading, correct it, confirm a flagged drop, or mark a replaced meter so lifetime distance stays right.

For
OwnerFleet manager
Hosting
Any hosting
Devices
All devices
Business
Fleet

Checked against Pop Dispatch 0.1.0

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 #

  1. Call GET /fleet/assets/{id}/meters?meter=distance. Rows come newest first. Look for a flag of regression or suspect, and for a value that does not fit its neighbours. Note the id of the wrong row.
  2. Choose what happened.
    • The number was mistyped: correct it. Call POST /fleet/meters/{id}/correct with {"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 flagged confirmed and 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 flagged replaced and starts a new epoch.
  3. Add an optional note to any of these calls so the next person sees why.
  4. 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.
  5. If the correction answer is conflict (409), that reading was already corrected. Correct the newer row instead. It is the one without voided: true.

How to confirm it worked #

  • GET /fleet/assets/{id} shows regressions_to_confirm at 0 and the odometer you expect.
  • After a replacement, lifetime_distance equals 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: true and the new row with its voids_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/economy measures 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 suspect and 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_fleet license flag for writes.