Purchase requests

The Purchase requests screen opens the commitment chain of the Supply module (supply): turning an observed need into a purchasing act. This is where you formally state “I need this item, in this quantity, by this date”.

Founding principle: the plan proposes, a human creates. No purchase request is ever generated automatically — the requirements plan flags what will run short, but a person decides to commit.

A request’s life cycle

A request (numbered DA-NNNNN) follows a guarded cycle:

Draft — being entered, freely editable. This is the only status where lines can be changed or the request deleted.
To approve — submitted, awaiting a decision. Now frozen.
Approved — validated, ready to be turned into an order (next phase).
Rejected — refused, with a mandatory reason.
Cancelled — withdrawn before conversion.
Ordered — converted into a purchase order (coming soon).

The action buttons shown depend on the status: you only see the transitions that are actually possible.

Separation of duties

A hard rule, independent of permissions: the approver can never be the requester. Whoever created the request cannot approve or reject it themselves — this guarantees that a commitment always goes through two pairs of eyes. The rule is enforced server-side: even by forcing the interface, self-validation is refused.

Who can do what is carried by roles (see Roles & permissions): the requester creates and submits, the approver decides. Without authentication (demonstration environment), the interface stays permissive.

What a request carries

A supplier: a request targets a single supplier. It is optional in draft (you can frame a need before deciding the source), but required to submit.
A priority: routine, urgent, or AOG (aircraft on ground).
An optional need-by date and justification.
A destination: the site (and optionally the storage) where the supply must arrive. Like the supplier, the site is optional as a draft but required to submit — a requirement always originates from a site.
One or more lines: an item (searchable, never a raw identifier) and a quantity. Each line keeps its origin — manual entry, from the requirements plan, or from a reorder point — to measure how much of purchasing comes from anticipation rather than urgency.

Entry happens on a full-screen document (header then lines), not a cramped dialog: a request may carry many lines.

Estimated amount and approval status

Once saved, the request’s record shows, computed from the supplier’s catalog (nothing frozen):

the estimated amount per line and the total, in the supplier’s currency (single supplier ⇒ single currency) — this drives the required approval level;
the supplier’s approval status (ASL) per item — approved, not approved, suspended, expired, or covered by a derogation — with an “X/Y lines sourceable” summary. The actual block on buying outside approval happens at the order stage; here it is indicative, to catch a problem early.

Editing the request

The “PDF” button, on the record, produces a printable document of the request — useful for keeping a paper trail of the approval circuit (attached to a file, signed by hand, archived locally).

Its layout comes from your instance’s “Purchase request” edition template — composable block by block. Unlike an order acknowledgement, it is never frozen: the request is an internal working document, so it is always its current template that gets printed, even after approval.

Filters

Search by request number, plus status and priority as multi-select.