Production Orders

The production order is simultaneously a work instruction, a material reservation, a capacity booking, and a cost object. That quadruple role is what makes it complex.

Lifecycle 

Planned order ──▶ Production order ──▶ Released ──▶ In process ──▶ Confirmed
   (from MRP)         (created)         (REL)                      (partially/fully)
                                          │                              │
                                    Materials issued              Goods receipt of FG
                                    Capacity booked                      │
                                                                    Technically complete
                                                                         │
                                                                      Settled
                                                                         │
                                                                       Closed

Status management

Orders carry system statuses (set by the system) and user statuses (customer-defined):

Status Meaning Effect
CRTD Created Exists, not released No goods movements allowed
REL Released Approved for execution Material issue, confirmations, printing allowed
PCNF Partially confirmed Some operations done —
CNF Confirmed All operations confirmed —
DLV Delivered Full quantity received into stock —
PDLV Partially delivered — —
TECO Technically complete Production finished Open reservations and capacity deleted; costs still collectable
SETC Settled Costs transferred —
CLSD Closed Fully done No further postings at all
DLFL Deletion flag Marked for deletion Excluded from reports

TECO vs CLSD is a distinction people get wrong. TECO stops production and frees capacity and material reservations but still allows late invoices and cost postings to land. CLSD stops everything. Closing too early strands costs; never closing leaves orders open for years, which distorts WIP.

Order creation 

production_order(
  id, order_number, order_type, plant_id,
  material_id, target_quantity, uom,
  production_version, bom_alternative, routing_group,
  basic_start_date, basic_finish_date,
  scheduled_start, scheduled_finish,
  actual_start, actual_finish,
  delivered_quantity, scrap_quantity,
  status, mrp_controller, production_supervisor,
  sales_order_id, wbs_element_id,      -- for MTO
  settlement_rule, costing_variant,
  created_from_planned_order
)
production_order_component(
  order_id, item, material_id, required_quantity, withdrawn_quantity,
  requirement_date, storage_location, batch,
  operation_number, backflush_flag, bulk_flag, item_category
)
production_order_operation(
  order_id, operation_number, work_center_id, control_key,
  setup_time, machine_time, labour_time,
  earliest_start, latest_finish, scheduled_start, scheduled_finish,
  confirmed_yield, confirmed_scrap, confirmed_activities,
  status
)

Note: components and operations are copied from the BOM and routing at order creation, not referenced. The order is a snapshot. If the BOM changes tomorrow, running orders keep the old structure — which is correct, because that’s what the shop floor is actually building. A “read master data” function re-copies deliberately when you do want the change.

Order types

Type Purpose
Standard production order Normal make
Process order Process industries; phases, recipes, control recipes to the DCS
Rework order Fix defective units; consumes labour, maybe extra parts, no new base material
Refurbishment order Repair a returned serialised unit — receives a damaged unit, issues a good one
Maintenance order Not production; equipment maintenance (EAM/PM)
Make-to-order Linked to a sales order; stock is segregated as sales-order stock
Engineer-to-order Linked to a WBS element

Release and availability check

Releasing an order checks:

  • Material availability — are the components there?
  • Capacity availability — is the work centre free?
  • PRT availability — production resources/tools (jigs, moulds, fixtures)
  • Batch determination — which specific batches to consume (FEFO, characteristics)

Configuration decides whether a missing component blocks release, warns, or is ignored. Releasing orders that can’t be built is the classic cause of shop-floor chaos — the order enters the queue, hits operation 20, and stops. A “no partial release without full material availability” policy is usually right.

Release also triggers: shop papers printing, material staging (transfer requests to the warehouse), and capacity confirmation.

Material issue

Three mechanisms:

1. Manual goods issue

Storekeeper issues against the order reservation. Accurate, labour-intensive.

2. Backflushing

Components are consumed automatically when output is confirmed:

Confirm 100 units produced
  → system issues 400 legs, 100 seats, 800 screws (per BOM)

Fast, no paperwork. Requires accurate BOMs, because errors are invisible until a physical count reveals a big discrepancy. Best for stable, high-volume production with reliable BOMs.

3. Pull list / staging

Warehouse stages material to the line based on the order’s requirements; consumption is backflushed from the line stock.

Post-processing of backflush errors is a real operational queue: backflush fails when there’s insufficient stock in the issuing location, and the order proceeds while the consumption sits unposted. Monitor that queue; a growing backlog means inventory and WIP are both wrong.

Confirmations

Reporting progress from the shop floor:

confirmation(
  id, order_id, operation_number,
  confirmation_type,     -- PARTIAL | FINAL | AUTOMATIC
  yield_quantity, scrap_quantity, rework_quantity,
  scrap_reason_code,
  setup_actual, machine_actual, labour_actual,
  personnel_number, work_center_id,
  posting_date, execution_start, execution_finish,
  reversed_by
)

Confirmation triggers:

  • Activity cost posted to the order (hours × activity rate)
  • Backflush of components assigned to that operation
  • Automatic goods receipt at the last operation (if configured)
  • Capacity load reduction
  • Status update

Confirmation is the shop floor’s only interface with the ERP for most workers, so it must be fast and forgiving. Barcode scanning, tablet UI, or MES integration — never a 40-field SAP screen for a machine operator. If confirmation is painful, operators batch it up and confirm a week’s work on Friday, and every WIP number you produce is fiction.

Milestone confirmation

Confirm only at key operations; the system auto-confirms all preceding ones. Reduces data entry dramatically at the cost of intermediate visibility.

Goods receipt of finished goods 

  Finished goods inventory   Dr  (quantity × standard cost)
    Production order (WIP)      Cr

Options: automatic at final confirmation, or a separate manual receipt (better when QC must pass first). Over/under delivery tolerances apply, same as purchasing.

The receipt captures: batch number (assigned or generated), serial numbers, production date, expiry date, and the storage location.

WIP — Work in Process

At period end, orders that are started but not finished hold value:

WIP = actual costs debited to the order − value of goods already received

Order 4711:
  Materials issued           45,000
  Activities confirmed       18,000
  Overhead applied            9,000
  Total debits               72,000
  Goods received (50 of 100 units × 500 std)   (25,000)
  ─────────────────────────────────────────────────
  WIP                        47,000

WIP calculation is a period-end job that posts:

  WIP (balance sheet asset)   Dr 47,000
    WIP change (P&L)             Cr 47,000

…and reverses it next period. When the order completes, WIP goes to zero and the remaining difference becomes a variance.

Two methods:

  • WIP at actual cost — total debits minus credits, as above. Simple.
  • WIP at target cost — value the confirmed operations at standard. More accurate, separates WIP from variance earlier.

Order settlement 

Order costs (actual)          72,000
Goods received at standard   (70,000)
─────────────────────────────────────
Variance                       2,000  → settled to COGS / price difference

Settlement:
  Production variance   Dr 2,000
    Production order       Cr 2,000
Order balance now zero.

Settlement runs monthly. An order that never settles keeps a balance forever and inflates WIP. A standard report is “orders with a balance, technically complete, not settled” — chase it every month.

Order changes

Real production changes constantly:

  • Quantity increase/decrease → components and operations rescale
  • Date change → reschedule
  • Component substitution → material shortage workaround
  • Operation added (unplanned rework)
  • Split into two orders

Every change is logged. Change logs on production orders are audit evidence in regulated industries and the raw material for “why did this order cost 40% more” analysis.

Metrics

Metric Meaning
Schedule adherence Orders finished on the planned date
Order cycle time Release to completion vs planned
First pass yield Good units first time, no rework
Scrap rate by reason Where material is lost
Confirmation lag Time between actual work and its confirmation — measures data trustworthiness
Open orders past due Backlog health
WIP value and ageing Stranded value
Cost variance by category Where the standard is wrong or execution failed

Developer notes

  1. Orders snapshot the BOM and routing. Don’t join to master data at runtime.
  2. Status is a set of flags, not one enum. An order can be REL + PCNF + PDLV simultaneously.
  3. Confirmations are append-only; a wrong confirmation is cancelled with a reversal confirmation.
  4. Backflush failures need a visible queue and an owner.
  5. Settlement is a period job with the standard requirements: idempotent, restartable, test mode.
  6. The shop-floor confirmation UI is the most important UI in the module. Optimise it ruthlessly.
  7. Never delete an order. Deletion flag, then archive.

Next