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.

Filters