# Work Order Execution ## Overview Work Order Execution tracks the operation-level progress of manufacturing work after a production order is released. A `WorkOrder` represents one executable routing step with assigned work-center context, planned quantity, status, actual start or finish data, and the execution evidence needed to move the parent production order forward. Work orders provide the operational unit for supervisors and operators to start, pause, report, and complete shop-floor activity. This feature also defines how manufacturing coordinates with inventory during execution. Material issue may occur explicitly before work starts or implicitly through backflush on completion, while final or intermediate output completion triggers receipt handoff to inventory. Scrap reported during execution can also trigger an inventory scrap handoff. Manufacturing owns the operational intent and recorded progress; inventory owns stock movement persistence and valuation consequences. ## Business Purpose - Break a released production order into operation-level executable steps with clear status and ownership - Provide auditable tracking of actual start, stop, completion, quantity, time, and scrap at each operation - Support both manual material issue and backflush-style material consumption - Coordinate finished-goods or intermediate receipt with inventory without embedding storage-location ownership in manufacturing - Expose operation-level exceptions that explain why production is late, paused, or under-yielding - Roll execution progress into parent production-order status and cost collection ## Process Flow ```mermaid flowchart TD A[Production Order Released] --> B[Open Work Orders by Operation] B --> C[Start Work Order] C --> D{Manual issue required?} D -->|Yes| E[Send material issue request to inventory] D -->|No| F[Continue execution] E --> F F --> G[Report time, completed qty, and scrap] G --> H{Backflush at completion?} H -->|Yes| I[Send backflush issue request to inventory] H -->|No| J[Keep manual issue basis] I --> J J --> K{Final or intermediate output complete?} K -->|Yes| L[Send production receipt handoff to inventory] K -->|No| M[Move to next operation] L --> M M --> N{All required operations complete?} N -->|No| C N -->|Yes| O[Parent Production Order progresses toward completion] ``` ## Scenario Patterns - **Pre-issued materials**: Components are issued to the line before the first operation starts, and the work order records execution without backflushing those same quantities again - **Backflush assembly**: Standard components are consumed automatically when an operation or order reports completion, reducing operator transaction burden - **Partial operation reporting**: An operator reports some completed quantity and some scrap, leaving the work order open for the remaining balance - **Paused bottleneck operation**: A work order is started, paused due to machine or staffing constraints, and later resumed with the pause history preserved - **Intermediate output step**: A routing produces an intermediate quantity at one operation that must be receipted before the next step continues - **Final receipt handoff**: The final operation completes and sends finished-goods receipt intent to inventory while keeping manufacturing as the owner of execution evidence - **Manufacturing scrap handoff**: A work order reports nonrecoverable scrap and sends a named scrap contract to inventory so stock and valuation can be reduced through the inventory-owned adjustment flow - **Exception note capture**: A supervisor records an exception reason on a delayed or abnormal work order to explain variance and schedule slippage Manufacturing uses two named handoff contracts during execution. `ManufacturingReceiptHandoff` is sent when a work order reports intermediate or finished output that must be receipted into inventory. The minimum payload is: - `productionOrderReference` - `workOrderReference` - `itemReference` - `quantity` - `unitOfMeasure` - `siteReference` - `postingDate` Optional and conditional fields: - `storageLocationReference`: optional when inventory can derive the receiving location from site or production policy; otherwise required Inventory owns final storage persistence. Manufacturing owns only the execution evidence and the handoff intent. The same receipt handoff contract is used for both intermediate and final receipts. `ManufacturingScrapHandoff` is sent when a work order reports scrap that must reduce usable stock in inventory. The minimum payload is: - `productionOrderReference` - `workOrderReference` - `itemReference` - `scrapQuantity` - `unitOfMeasure` - `scrapReasonCode` - `siteReference` - `postingDate` Optional and conditional fields: - `sourceStorageLocationReference`: optional when inventory can derive the source location from prior issue or backflush context, or from a site-level manufacturing scrap policy; otherwise required - `scrapDispositionCode`: optional classification used by downstream inventory or accounting policies Manufacturing creates the handoff once per submitted scrap transaction. Inventory is responsible for translating the handoff into an inventory-owned `InventoryAdjustment` approval flow and for rejecting the handoff if location resolution is incomplete. For any stock-loss event that originates from manufacturing execution and can be traced to a `productionOrderReference` or `workOrderReference`, `ManufacturingScrapHandoff` is the only valid inventory path in the initial scope. A direct inventory `InventoryAdjustment` with reason code `Production Variance` is reserved for fallback situations where the manufacturing module is not deployed or the discrepancy is discovered after the fact with no resolvable manufacturing source document. This rule prevents the same physical production loss from being posted through two asymmetric flows and preserves work-order traceability. ## Test Cases - Starting a work order should succeed only when its parent production order is in a releasable execution state - A work order must not be completed before it is started unless an explicit bypass policy exists - Reported completed quantity and scrap quantity must be zero or greater, and at least one must be positive for a completion transaction - Completing a work order must update parent production-order progress correctly - Material issue requested manually from manufacturing must call the downstream inventory contract exactly once per submitted issue transaction - Backflush consumption must not duplicate quantities already issued manually - Final or intermediate receipt handoff payloads must include production-order reference, work-order reference, item reference, quantity, unit of measure, site, and posting date at minimum - Reporting positive scrap quantity must emit `ManufacturingScrapHandoff` exactly once per submitted scrap transaction - Scrap handoff payloads must include production-order reference, work-order reference, item reference, scrap quantity, unit of measure, scrap reason code, site, and posting date at minimum - Manufacturing-originated stock loss with a resolvable production-order or work-order reference must not bypass `ManufacturingScrapHandoff` through a direct inventory adjustment - A paused work order must be resumable without losing prior execution history - Completing a later sequential operation before a required earlier operation should be rejected unless the routing policy explicitly allows it - Work-order execution must remain isolated by company and site context - Only authorized manufacturing users should be able to start, pause, resume, report, or complete work 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 work centers and manufacturing execution concepts](https://www.odoo.com/documentation/19.0/applications/inventory_and_mrp/manufacturing/advanced_configuration/using_work_centers.html) - [SAP Digital Manufacturing execution routing](https://help.sap.com/docs/sap-digital-manufacturing/execution/routing)