Military Airfields / Flight Planning Room
Flight Planning Room (FPR) Checks
A per-shift Flight Planning Room check against a locally configured checklist, with a reviewable history and monthly PDF export.
A check that runs every shift, recorded as one free-text line
The Flight Planning Room check happens every shift: FLIP currency, charts, forms, the NOTAM display. When the only record of it is a single free-text Events Log entry, there's no way to show afterward which items were verified, which had a problem, or what that problem was.
And because the wording is up to whoever typed it, no two entries describe the check the same way. A month of them can't be compared, and an issue found at 0200 survives only in whatever words the mid shift happened to choose.
One card per shift, one row per item
Your checklist, not a national one
The check is a locally developed procedure, so the item list is yours: build it in Base Setup, or load the suggested starting point (FLIP currency, charts, forms, NOTAM display, airfield diagram, weather access, and more) and rename, reorder, or retire items to match local procedure.
Work the check from the shift's card
Each active shift (Day, Swing, Mid, however many the base runs) gets its own card that stays amber until the check is logged. Mark every item Satisfactory, Issue, or N/A; an Issue can't be saved until it has notes describing the problem.
The Events Log entry writes itself
Logging the check posts a one-line summary to the Events Log, naming any issues found, and a preview shows the exact line before you commit it.
History and the monthly PDF
The past 30 days sit below the shift cards, each check expandable to its full per-item results. The monthly PDF lists every check with date, shift, completion time, and initials, plus a footnote for every issue and its notes.
What it automates
A record instead of a sentence
Every check keeps its per-item results: what was Satisfactory, what was an Issue and why, what was N/A. The one-line Events Log summary stays, but the detail behind it no longer evaporates.
Issues arrive with their own notes
A check can't be logged while an Issue row has no notes, so every problem found comes with a written description, on the check, in the Events Log summary, and on the monthly PDF.
History that survives checklist edits
Completed checks keep each item's label as it read when the check was logged. Renaming or retiring an item never rewrites what a past check says.
Straight answers
Where does the checklist come from?
Each base builds its own in Base Setup. A Load Default Checklist button inserts a suggested starting point (FLIP currency, charts, forms, NOTAM display, airfield diagram, weather access, planning-area equipment, local flight guides), meant to be renamed, reordered, and trimmed to local procedure.
What happens when an item has a problem?
Mark it Issue and a required notes box opens; the check can't be saved until every Issue row has notes. Issues appear in the Events Log summary and as footnotes on the monthly PDF.
Can a completed check be corrected?
Yes. Re-run / Edit reopens the same check with its saved statuses and notes, and logging it again updates that check instead of creating a second one for the shift.
Is the module on by default?
No, it ships opt-in. An Airfield Manager or Base Administrator enables it under Base Configuration, and the sidebar entry and its Base Setup checklist step appear automatically.