Skip to content
Syndik8

Tacho-continuity conflict

A tacho-continuity conflict is a disagreement between two consecutive usage logs on the same asset: the start meter on the later log does not equal the end meter on the earlier log. If nobody flew the asset in between, those two numbers should be identical — when they are not, something is off (a missed log, a typo, an undocumented ground run, or a genuine data error).

The word “tacho” here is generic — the check uses whichever engine meter the asset is configured with. It only fires on assets whose billing basis reads the engine meter.

How a conflict is resolved

Section titled “How a conflict is resolved”

The two finalisation paths handle a conflict differently, but neither lets it slip through unnoticed:

  • Auto-finalise on submit uses a look-back check: when a member submits a usage log, the booking’s start meter is compared to the previous booking’s last log end. A mismatch skips finalisation, leaves the booking in the unfinalised queue, and fires a tacho_continuity_detected notification to the submitter and all syndicate admins. The notification is critical-tier — its delivery toggle is locked on.
  • Admin bulk finalise uses a look-ahead check: at reconciliation time, each booking’s end meter is compared to the next booking’s first log start. A mismatch tags the row with a “Junction conflict” badge in the unfinalised queue and excludes it from the Finalise All batch. The admin investigates with the full chronological context.

Either way, a conflict surfaces in the unfinalised queue with an explicit reason badge, and an admin’s normal recovery move is to edit the historical log to truth + post an adjustment for the financial difference — see correct a finalised booking.

Manual finalisation from the booking detail screen always still works; the admin has already decided.

See also

Section titled “See also”