Requirements plan

The Requirements plan screen answers the question every supply manager asks: “what will I run out of, and when?”. It is the first deliverable of the Supply module (supply) — a read-only screen: it creates no order, no reservation, no commitment.

Its value: the requirement is derived from the maintenance plan. The screen crosses each aircraft’s and component’s maintenance plan, the bill of materials of each operation (required parts and consumables) and real stock — including its shelf life. A generic purchasing ERP cannot do this calculation, because it knows neither the maintenance plan nor its bill of materials.

The three honesty counters

At the top of the screen, three clickable tiles are not decorative — they tell you by how much the plan is wrong, and in which direction:

Undatable requirements — real requirements, of known quantity, but whose date is not known (a due date driven by a usage meter). They need the Flight missions module to be dated; until then they are counted, never silently omitted.
Upper-bound due dates — a mixed due date (calendar or meter, whichever comes first) is dated “at the latest”: the real requirement can occur before the displayed date. This is the only dangerous direction of uncertainty — underestimating the lead time means missing the order.
Items without a known lead time — in V1, every item uses the instance’s default procurement lead time (no per-item or per-supplier lead time yet, planned for phase 2). This counter therefore always equals the total number of items in the requested scope — that is the honest answer, not a bug.

Clicking a tile filters the table to the items concerned.

The table

One row per item, sorted by default on the trigger date (shortage minus procurement lead time) — the date the buyer cares about. Columns: item (RA:CE + designation), net stock available today, total dated requirement over the horizon, undatable requirement (distinct badge when present), shortage date, trigger date, and criticality.

Criticality (none when all of the item’s requirements are undatable — no fake calculation):

Level	Meaning
Order now	Trigger date already reached or passed
Order soon	Trigger within 30 days
Watch	Shortage expected over the horizon, but trigger beyond 30 days
OK	No shortage expected over the horizon

Filters

Horizon — 3, 6, 12 (default) or 24 months of projection.
Display scope — three levels, “To order” by default:
- To order — items needing action: with a dated shortage over the horizon (to order or to watch) or carrying an undatable need (shown, tagged “undatable” — a real need is never hidden). Answers “what to act on” directly.
- With a need — every item that has a need, even already covered ones (criticality “OK”). Dormant stock stays hidden.
- Everything (incl. dormant stock) — also lists items that have stock but no need at all: inert inventory, excluded by default because it is not a need.
Criticality — multi-select chips.
Scope — the whole instance, a site (with an “include descendants” option) or a specific storage. Only one active at a time.
Include interchangeable — aggregates net stock with the interchangeable items from the reference data (see the availability foundation).
Break down by site — instead of one row per item aggregated over the whole scope, one row per (item, site): net stock, shortage date and criticality become specific to each site. A single item short at two bases then appears on two rows — you see at a glance where to order, and how much. Requirements whose site can’t be resolved are grouped under “Unresolved site” (never hidden). Available in a broad view (not on a specific storage); mutually exclusive with “Include interchangeable” (V1). Auto-split: when you generate purchase requests from a broken-down selection, they are automatically split by (supplier, site) — one PR per supplier and site, with no destination to enter. “Unresolved site” rows can’t be selected (no destination).
Search for an item — this screen’s API exposes no free-text search; searching is done by direct selection of item(s) from the catalog (server typeahead). An explicit search overrides the display scope: the selected items are shown whatever their state.

The item detail

Clicking a row opens the detail view, which shows:

The projected stock curve, as a step chart: stock stays constant between two events then changes instantly on their date (not a continuous interpolation, which would wrongly suggest steady consumption). The shortage line (zero) and the shortage/trigger dates are marked on it. The reorder point of the effective policy is drawn as a horizontal line (see Stock policies): you read at a glance the crossing (normal operational signal) versus the shortage (crisis).
The list of dated events, each with its traced source (maintenance-plan due date, material line of a work or repair order, lot expiry, expected receipt), a direct link to the item or aircraft concerned, and the site where the requirement is located (the aircraft’s current site, or the item’s storage site). A single part can thus be needed at several sites — the column makes it visible.
The “Undatable requirements” block, explicitly separated from the curve and dated events — never merged into a fake date calculation.

Interchangeable coverage and potential stock

When the “Include interchangeable” option is on, the detail goes beyond the item’s own stock:

A “Potential stock · to be validated” card appears at the top (next to net stock) as soon as equivalents are in stock: it sums the stock of the item and its equivalents (from both referentials). It is an indicative figure; net stock remains the firm number.
An “Interchangeable technical coverage” section, placed right after the dated events (it answers the shortage that drives the rupture), flags that an interchangeable item in stock could cover the need. It reduces neither net stock nor the shortage date.

Technical interchangeability is contextual: it holds only for a top product (aircraft or equipment) and a specific employment point. Coverage is therefore filtered by the need’s aircraft — A ≈ B on a RAFALE M may be false on a RAFALE B, or at another employment point. A need without an aircraft shows the equivalent as “context unknown”. In all cases a technical substitution carries mountability conditions the system does not evaluate: it stays to be validated by a human.

Creating purchase requests from the plan

The plan bridges requirement analysis to commitment. Two gestures create

purchase requests (PRs):

From an item detail — the “Create a purchase request” button opens the pre-filled editor (item, missing quantity, preferred supplier).
From the list, multi-select — tick several short items, then “Create purchase requests”. The system resolves each item’s preferred supplier (best-ranked catalog offer) and groups by supplier: a selection spanning three suppliers yields three PRs (one per supplier — a request is single-supplier). A recap shows the grouping, approval status and estimated amount before creating. Items without an approved supplier are gathered into a “to complete” PR.

The delivery destination (site) is chosen in the creation dialog — pre-filled if you filtered the plan by site or storage, entered otherwise. The gesture is therefore available even without a filter (“whole instance” view). PRs are created as drafts — nothing is committed, everything stays editable before submission.

Out of scope (V1)

Airworthiness campaigns (service bulletins, directives, modifications) do not yet generate a requirement here: their date is known but no parts kit is modeled.
The procurement lead time is the instance’s, not yet per item or per supplier.