Purchase orders

The Purchase orders screen is the culmination of the commitment chain in the Supply module (supply): where an approved request becomes a firm commitment to a supplier. An order (numbered CMD-NNNNN) targets a single supplier and a single currency.

The engagement gesture: from need to order

An order is not keyed from scratch: it consolidates approved purchase-request lines. The “Workload to engage” button opens the workload to engage screen, which shows all approved PR lines still to be engaged (those whose remainder is positive), grouped by supplier.

In each supplier block:

  • you tick the lines to engage (all ticked by default);
  • you adjust each line’s quantity — the default is the remainder (what is left to order on the PR line);
  • if the supplier’s catalog does not impose a currency, you enter it (3-letter code, e.g. EUR);
  • “Create order” consolidates the selection into a single draft order. Lines with the same (item, site) are merged; the PR→order link stays traced and quantified.

A single PR line can be engaged in several steps (partial orders): as long as a remainder is left, it reappears in the workload.

An order’s life cycle

An order follows a guarded cycle:

  • Draft — resulting from the engagement, still adjustable.
  • To approve — submitted, awaiting a decision.
  • Approved — validated, ready to be sent to the supplier.
  • Sent — transmitted to the supplier.
  • Acknowledged — the supplier has acknowledged receipt.
  • Partially received / Received — as receptions come in (next phase).
  • Closed — settled.
  • Cancelled — withdrawn before reception.

The action buttons shown depend on the status: you only see the transitions that are actually possible (Submit, Approve, Send, Acknowledge, Cancel). The order’s revision is shown in the header: it increments on each major change after issuance.

Sending: the final agreement check

Send transmits the order to the supplier — and this is when the agreement check happens. Each item on the order is re-evaluated at that moment against the supplier’s

approved sources: an active and valid approval must cover the item. The check runs at send time (not at creation), so an order can be prepared while an approval is being renewed.

If an item is not covered, the send is refused — unless an active sourcing derogation exists for that item, in which case the send goes through and the derogation used is traced on the order (evidence that the block was lifted). The order stays Approved while the send is blocked.

Acknowledgement

When the supplier confirms the order, Acknowledge opens a window where you record:

  • the supplier’s order reference (their acknowledgement number, “AR”);
  • for each line, the firm promised delivery date — pre-filled from the already-promised date or, failing that, the need date.

For a split delivery, replace the single date with a schedule of several installments (“Add an installment”: a quantity + a date), e.g. 3 on 09/15, 5 on 09/30, 2 on 10/15. Each installment becomes a distinct dated arrival in the requirements plan.

Entry is partial: you can record only a reference, or confirm only some of the dates. The order then moves to Acknowledged, and the acknowledgement date is time-stamped.

Even before acknowledgement, a sent order already appears in the

requirements plan as an estimated arrival (sent date + supplier lead time), flagged “(estimated)”. Acknowledgement replaces that estimate with the firm date(s).

Revision: no silent change

An order that has already been sent (or acknowledged) cannot be changed quietly. The Revise button opens a window to adjust each line’s quantities, prices, dates, the incoterm and the notes. The supplier and currency stay fixed (changing them is a different order).

Saving a revision increments the revision number (shown in the header), sends the order back to “Sent” and voids the previous acknowledgement: the supplier must re-acknowledge the new version. This keeps a clear trace of what was renegotiated after issuance.

Separation of duties

As with the purchase request, the decision goes through two pairs of eyes: who can submit and who can approve is carried by roles (see Roles & permissions). The rule is enforced server-side; without authentication (demonstration environment), the interface stays permissive.

What an order carries

  • A supplier and a currency — single supplier, single currency.
  • An optional supplier reference and incoterm.
  • One or more lines, each with: the item, the destination site, the ordered quantity, the received quantity, the cancelled quantity, and the derived remainder (= ordered − received − cancelled, never stored), the unit price, the requested / promised dates, and a “conformity certificate required” flag (Form 1 / CoC) — it gates the goods-receipt certificate at reception. This flag is inherited from the item (a catalog attribute) when the line is created, and stays adjustable on revision.
  • Rich-text notes.

Filters

Search by order number, plus status as multi-select.

See also