Finalise multiple bookings at once

Finalise multiple bookings at once

When the unfinalised queue is large and most bookings are clean, bulk-finalise in one action instead of opening each booking. Bulk uses a look-ahead continuity check — every booking’s end meter is compared to the next booking’s first log start on the same asset — so a junction conflict on either side keeps both rows out of the batch until you investigate.

This is the path syndicates that leave auto-finalisation off use to reconcile at month-end. Auto-finalise covers the eager case; this page covers the prudent one.

Before you start

• You must be an owner or admin.
• Bookings with a shortfall are flagged with a Shortfall badge in the list — finalising them here applies the calculated shortfall charge as-is. To waive or override a shortfall, finalise that booking individually first.
• You must be online. Both bulk buttons (Finalise No-Shortfall and Finalise All) write to the financial ledger and disable when the device is offline.

How the look-ahead check classifies each row

Before the batch runs, each booking in the queue is classified by comparing its last log’s end value to the next booking’s first log start. A reason badge appears next to every row so you understand at a glance whether it will be picked up:

Badge	What it means	Goes into “Finalise All”?
Junction confirmed	The next booking on the asset has been logged and its start meter matches this booking’s end.	Yes
Trailing flight	This is the most recent flight on the asset — there is no next booking to verify against. Included on admin trust; the badge is informational, not a warning.	Yes
Junction conflict	The next booking has been logged but its start meter disagrees with this booking’s end beyond tolerance (0.01 h). Excluded — the admin investigates which side is wrong.	No
Awaiting next log	The next booking exists but its pilot has not logged yet. Excluded — the junction will become verifiable once the next log arrives. Also covers transient lookup failures.	No

The “Trailing flight” inclusion is deliberate: every asset always has a most-recent flight, so excluding trailing rows would turn “Finalise All” into “Finalise Most” almost every cycle. The badge calls them out so you can glance over the meter values during reconciliation. If a trailing reading later turns out to be wrong, the recovery path is correct a finalised booking.

The badges update live as members submit logs — if the Awaiting next log row’s downstream pilot files their log while you are looking at the queue, the row reclassifies in place to Junction confirmed without you needing to refresh.

When every row in the queue is excluded, the Finalise All button shows greyed out as Finalise All (0) rather than disappearing — so the action stays discoverable and the count makes it obvious why nothing happens if you tap it.

Steps

1. Open the syndicate.
2. Go to Unfinalised Bookings. Route: /syndicates/:syndicateId/unfinalised-bookings.
3. Review the summary header: Sessions, Hours, Landings, T&Gs, and With shortfall counts.
4. Scan the badges. Each row carries one of the four reasons above. Anything excluded (Junction conflict / Awaiting next log) needs separate attention before it can finalise.
5. Choose a bulk action:
   • Finalise No-Shortfall (N) — finalises only included and includedTrailing rows that also have no shortfall. Skips anything excluded by continuity, anything with a non-zero shortfall, and anything otherwise ineligible.
   • Finalise All (N) — finalises every included and includedTrailing row in the queue, applying the calculated shortfall where it exists. Excluded rows stay queued.
6. Confirm in the Confirm Bulk Finalisation dialog. The dialog repeats the counts and warns how many bookings will have shortfall charges applied.
7. Tap Finalise All to commit.

You see N bookings finalised. The finalised bookings drop off the queue; any bookings that failed to finalise stay in the queue for you to open individually.

Resolving the excluded rows

Junction conflict

The two consecutive bookings disagree about the meter at the boundary between them. Open the conflicting booking, identify which side has the wrong reading (sometimes by talking to the pilots), edit the historical log to truth using the normal usage-log editor, and re-run bulk — the row reclassifies as Junction confirmed once the values agree. If you would rather not wait, finalise the booking individually with finalise a booking — the manual path bypasses continuity checks.

Awaiting next log

The next pilot has not logged yet. Bulk waits for them. If you need the booking finalised now (typical reason: month-end and the next pilot is on holiday), finalise it individually with finalise a booking. The manual path bypasses the look-ahead, on admin trust.

Offline behaviour

The bulk Finalise No-Shortfall and Finalise All buttons watch connectivity, the same way single-booking finalisation does. When the device is offline both buttons disable and show Settlements need a connection — try again when you’re online if you tap them. They re-enable automatically when the connection returns. Bulk finalisation cannot be queued — the underlying RPC writes to the financial ledger atomically per booking, and queueing it offline would risk a partial or double settlement.

If it goes wrong

• Some bookings remain in the queue after a bulk action. Check the badge on each one. Junction conflict and Awaiting next log are deliberate exclusions — the look-ahead is doing its job. Resolve them per the section above.
• “Finalise All (0)” is greyed out. Every row in the queue is excluded by the look-ahead check. Either resolve the conflicts (or wait for downstream logs) so rows reclassify to Junction confirmed, or finalise individual bookings using finalise a booking.
• The bulk buttons are disabled. Either there are no eligible bookings (the no-shortfall count is zero, or the queue is empty), or the device is offline. See Offline behaviour above.
• “All bookings finalised” empty state — the queue is clear; nothing to do.
• A bulk-finalised booking later turned out to have been wrong (typically a Trailing flight whose successor disagreed with the recorded end-tacho once it eventually flew). Use correct a finalised booking to edit the historical log and post an adjustment.

See also

• Finalisation rules — what bulk finalisation actually does per booking, and how each path handles a junction
• Tacho-continuity conflict — the meter-junction concept the look-ahead check enforces
• Unfinalised bookings queue — the admin view
• Finalise a booking — per-booking version with shortfall override and continuity-bypass on admin trust
• Enable auto-finalisation — eager look-back alternative for pay-as-you-go syndicates
• Correct a finalised booking — recovery when a finalised booking later turns out to have been wrong