# Production Order Lifecycle

## Overview

Production Order Lifecycle governs how a manufacturing request is created, planned, released, executed, and closed. A `ProductionOrder` records what item should be produced, at what quantity, for which company and site, against which BOM and routing definition, and on which planned dates. It is the manufacturing control document that turns a planning decision into executable shop-floor work.

The production order tracks both control state and execution progress. Release freezes the selected BOM and routing into an order snapshot, generates operation-level work orders, and prepares material requirements for inventory coordination. Subsequent work-order reporting, material issue, scrap, and completion update production progress until the order is physically completed, marked `TECHNICALLY_COMPLETE` for cost and administrative review, and then formally closed.

## Business Purpose

- Turn manual planner intent or upstream demand signals into a controlled manufacturing commitment
- Freeze recipe and process assumptions at release time so execution stays auditable
- Provide a single source of truth for planned quantity, completed quantity, scrap quantity, and remaining open work
- Coordinate material readiness, work-order generation, and production scheduling around one document
- Support make-to-stock and make-to-order scenarios without moving sales or purchasing ownership into manufacturing
- Prevent incomplete, invalid, or unauthorized production requests from reaching execution

## Process Flow

```mermaid
flowchart TD
    A[Create Production Order] --> B[DRAFT]
    B --> C[Select item, quantity, site, BOM, routing, and dates]
    C --> D{Ready to release?}
    D -->|No| C
    D -->|Yes| E[RELEASED]
    E --> F[Snapshot BOM and routing]
    F --> G[Generate work orders and material requirements]
    G --> H{Execution started?}
    H -->|No| I[Remain RELEASED or reschedule]
    H -->|Yes| J[IN_PROGRESS]
    J --> K{Completed quantity and final receipt posted?}
    K -->|No| J
    K -->|Yes| L[COMPLETED]
    L --> M[Freeze execution and mark TECHNICALLY_COMPLETE]
    M --> N[Review variances and administrative exceptions]
    N --> O{Cost review settled?}
    O -->|No| N
    O -->|Yes| P[CLOSED]
    B --> Q[CANCELLED]
    E --> Q
```

The `ProductionOrder.status` lifecycle in the initial scope is:

- `DRAFT`: Planner can create, edit, or delete the order before any execution commitment exists
- `RELEASED`: BOM and routing are snapshotted, work orders are generated, and the order is ready for shop-floor execution
- `IN_PROGRESS`: At least one work order has started or execution evidence exists against the order
- `COMPLETED`: Physical production is complete because required work orders, final output reporting, and finished-goods receipt handoff have been submitted
- `TECHNICALLY_COMPLETE`: The order is execution-frozen and no additional production activity is expected, but cost review, variance approval, and downstream accounting handoff are still pending
- `CLOSED`: Administrative close is finished after the linked manufacturing cost summary reaches its required settled state
- `CANCELLED`: The order is abandoned before meaningful execution and cannot accept further execution updates

The allowed transitions are:

- `DRAFT -> RELEASED`
- `DRAFT -> CANCELLED`
- `RELEASED -> IN_PROGRESS`
- `RELEASED -> CANCELLED`
- `RELEASED -> DRAFT` only through an explicit controlled unrelease or replan workflow if no execution evidence exists
- `IN_PROGRESS -> COMPLETED`
- `COMPLETED -> TECHNICALLY_COMPLETE`
- `TECHNICALLY_COMPLETE -> CLOSED`

The following gating rules apply:

- `COMPLETED` requires all mandatory work orders complete plus the final output reporting and receipt handoff required by policy
- `TECHNICALLY_COMPLETE` requires that no additional execution, rescheduling, or material issue is still expected on the order
- `CLOSED` requires the linked manufacturing cost summary to finish variance review and reach its settled lifecycle state through a recorded `ManufacturingCostSettlementAcknowledgment`
- Any attempt to resume execution after `TECHNICALLY_COMPLETE` must use a controlled reopen workflow rather than direct shop-floor updates

## Scenario Patterns

- **Make-to-stock replenishment**: A planner creates a production order to rebuild finished-goods inventory to target levels without linking ownership to a specific sales order
- **Demand-driven production**: A production order is created in response to prioritized downstream demand while remaining a manufacturing-owned document
- **Release after shortage review**: A planner keeps the order in draft until material availability and work-center timing are acceptable, then releases it for execution
- **Reschedule before execution**: A released order is moved to a later date because a bottleneck work center or inbound material is not ready yet
- **Partial completion**: A production order reports some finished quantity and scrap before the remaining balance is completed later
- **Cancellation before execution**: A production order is cancelled because demand disappears and no meaningful execution or inventory posting has occurred yet
- **Technical completion before close**: The order finishes physical production, then enters `TECHNICALLY_COMPLETE` so cost review and downstream settlement can occur without reopening shop-floor execution
- **Close after review**: The order is closed only after variance review, `ManufacturingCostSettlementAcknowledgment`, and administrative checks are finished

## Test Cases

- Creating a production order for an ACTIVE manufactured item with positive quantity and valid company or site scope should succeed
- A production order must not be released without an ACTIVE BOM and ACTIVE routing selection or resolvable default
- Releasing a production order must snapshot the chosen BOM and routing definitions onto the order
- Releasing a production order must create the expected work-order structure based on the snapshotted routing operations
- A cancelled production order must not accept new execution updates
- Rescheduling a production order should be allowed before execution starts and must remain auditable after release
- Execution progress on work orders must roll up to production-order started, partial, or completed state correctly
- Completing a production order should require final output reporting and the finished-goods receipt handoff required by policy
- Marking a production order `TECHNICALLY_COMPLETE` should require that all planned execution is done and should block further shop-floor reporting unless the order is formally reopened
- Closing a production order should be blocked while open work orders or unresolved execution exceptions remain
- Closing a production order should be blocked until the linked manufacturing cost summary reaches `SETTLED` through a valid `ManufacturingCostSettlementAcknowledgment`
- Production-order data must be isolated by company and must not reference BOMs, routings, or work centers from another company
- Only authorized manufacturing users should be able to release, cancel, complete, technically complete, or close production orders

## Reference Links

- [Oracle work orders overview](https://docs.oracle.com/en/cloud/saas/supply-chain-and-manufacturing/25d/faumf/overview-of-work-orders.html)
- [Odoo manufacturing features](https://www.odoo.com/app/manufacturing-features)
- [SAP S/4HANA Cloud manufacturing overview](https://help.sap.com/docs/SAP_S4HANA_CLOUD/2bba750d1e124e1ea2a039bb1cd9b6c5/03659e8e0c9d4f37afb3c5f3b37cabc3.html)