Departure conflict

What it is

A departure conflict is a disagreement between two flights on the same aircraft: a flight on a booking left from an airfield other than the one where the aircraft last landed before it. For the booking’s first flight that is the last landing before the booking; for each later flight it is where the flight before it, on the same booking, landed.

An aircraft can only leave from where it last landed, so the two should match. When they don’t, one of the two routes is wrong: a slip in the departure, a wrong arrival on the previous flight, or a flight in between that nobody logged. The arrival is what decides home-airfield landing fees, so Syndik8 holds the booking for an admin rather than billing on a route that may be wrong.

It is the route counterpart of a tacho-continuity conflict, which does the same for meter readings, and it is held the same way.

Who can use it

Admin: sees the booking held on the unfinalised bookings queue, receives the follow-on alert under the timing rules below, and resolves it.
Treasurer (admin): same.
Member: sees the booking as not yet finalised. A member who tries to close the booking is told “This flight didn’t leave from where the aircraft last landed. If your log is wrong, correct it and close the booking again. Otherwise an admin will review it and finalise the booking.” A pilot can correct their own flight log, not someone else’s, while the booking is still open.

Where to find it

On the Unfinalised bookings queue at /syndicates/:syndicateId/unfinalised-bookings, the booking shows Departure mismatch, or counts it in +N more when a higher-priority finding is present. Booking detail lists every established finding under Needs attention, names both airfields and links to the related booking. A disagreement between legs of the same booking needs no link. Meter and route findings are shown independently.

Fields / options

There are no fields to edit here. The check is worked out from the flights logged on the aircraft; it is not stored on the booking.

Behaviour rules

Where the aircraft last landed before the booking is the arrival of the flight that happened last on that aircraft, among bookings (not cancelled or rejected) that had started by the time this booking did. The latest booking comes first; within it, the leg with the highest end reading, then the one that ended last, then the one written last. A flight with no arrival recorded is passed over. Later-written repeats are also passed over, using the same rule as the meter check and the device pre-fills: overlapping flight times, or both meter readings matching within 0.01 h. Meter ranges that only partly overlap at different times remain separate flights.
Every flight on the booking is checked, in the order they were flown: by start meter reading, then off-blocks or take-off time, then when each was written. The first flight must leave from where the aircraft last landed before the booking; each later flight must leave from where the flight before it landed. The first flight that disagrees holds the booking, and the booking is held once however many of its flights disagree. A log that repeats another on the booking (one flight logged twice: their times overlap, or their start and end readings both match) is passed over, because the booking is held for that instead.
Ground runs are passed over. A log with Ground run: no takeoff selected never counts as a landing and is never the flight checked, whatever its route boxes say.
Nothing is checked when either side has no route. If nothing has been logged on the aircraft before, or a flight records no departure, there is nothing to disagree with. A flight with no arrival recorded leaves nothing to compare the next flight with.
A differing first departure waits when a flight in between has not been logged. If the booking’s first flight leaves from somewhere other than the last recorded landing, and since that landing an earlier booking on the aircraft has ended (or been completed) with no flight log at all, the booking waits rather than conflicts: that unlogged flight may explain the move. The booking shows Missing previous log instead of Departure mismatch, with “The flight in between has not been logged yet. Review the earlier unlogged booking.” Only a booking that is not cancelled or rejected and is not a maintenance booking counts; a booking with only a ground run logged has a log, so it never counts. A first departure that matches the last landing is clear whatever lies in between, and a later flight on the same booking that disagrees with the flight before it still conflicts directly. While it waits, auto-finalisation skips the booking, the pilot’s close is refused with “The previous flight on this aircraft hasn’t been logged yet, so yours can’t be checked against it. Try again once it has, or an admin will finalise the booking.”, bulk finalisation leaves it out, and no alert is sent. It clears once the missing booking’s flight is logged, when the routes are compared as usual, or when an admin finalises the booking individually.
The comparison ignores case and surrounding spaces, so egkb and EGKB match.
Maintenance bookings are never held by it, in the queue or anywhere else. They are closed by admins and bill nothing.
The pilot and active admins receive one follow-on alert while it stands. The Flight logs don’t follow on alert names the recorded routes and asks them to check both logs. When meter readings disagree too, the same alert names both. Relevant reading, route, time and date changes, insertions and deletions refresh the diagnosis. New between-booking alerts wait for ten minutes without a relevant server change on the aircraft, then the half-hourly sweep sends any alert that still stands. Internal-leg conflicts remain immediate, and standing alerts refresh or withdraw immediately. A booking waiting for a missing log (see above) sends no alert. Individual finalisation remembers the reviewed facts. A later change can need review again, including on a completed booking. The meter continuity page describes the full alert and review rules. It is a must-see alert: always emailed, and it cannot be muted.
Auto-finalisation skips the booking. The booking stays in the unfinalised queue. A booking held for a flight logged twice or a tacho-continuity conflict is held for that first.
The pilot’s close is refused, with the message quoted above.
Bulk finalisation leaves it out. Finalise All and Finalise No-Shortfall skip a row with the Departure mismatch badge. Each booking in the batch is checked again when the admin confirms; if a log changed after the queue loaded and a booking no longer follows on, the whole batch is refused and nothing is finalised: “Nothing was finalised: one booking’s flight no longer follows on from the one before. Find it marked Meter mismatch or Departure mismatch in the list, then try again.”
An admin finalising the booking individually always works. That is how a held booking is resolved once the admin has looked: the admin has decided. See Finalise a booking.
Correcting a route also clears it. Fix the wrong departure, or the previous flight’s wrong arrival, in the normal usage-log editor. Once they agree, the pilot can close the booking, bulk finalisation includes it, and the next auto-finalisation sweep picks it up (subject to its other conditions). If the previous flight is already finalised, correct it with Correct a finalised booking.

A late earlier route correction is diagnosed on the changed booking and links to the next genuine flight, even if that later booking is finalised. Ground runs and empty maintenance bookings are passed over when comparing routes; an empty personal booking in between makes a differing first departure wait, as above. The later booking and its charges are unchanged. See Meter continuity for alert timing and review behaviour.

Why Syndik8 checks this

The route on a flight log is part of the aircraft’s technical record, and the arrival decides whether landing fees are charged. A departure that doesn’t follow on from the last landing is the cheapest sign that one of those records is wrong.

The departure pre-fill prevents most of these conflicts at the point of entry: a new flight’s departure starts at where the aircraft last landed, so the pilot only changes it when something really is different. A conflict can still arise without anyone changing it, for example when the previous flight had not yet reached the pilot’s device, or was logged after this one.