Skip to main content
Version: v1.0.0(int)

W129: Create work order

Opens a new work order to produce finished goods from materials and (optionally) sub-assembly SKUs. Triggered from the Work Orders page, "New WO". The workflow validates inputs, rolls up the material unit cost recursively through the BOM, snapshots the recipe into work_order_inputs so later BOM edits do not affect this WO.

Steps​

  1. Generate the next WO number. Use the per-tenant counter for this org to produce WO-2026-0001, WO-2026-0002, and so on (sequence resets each calendar year).

  2. Validate the work-site location. Confirm it exists and is active.

  3. Validate output SKUs have a BOM. For each output line, confirm the SKU exists and has a BOM in this org. A SKU without a BOM cannot be produced.

  4. Create the WO header. Call WorkOrders.createWo with header fields (woNumber, orderDate, optional expectedDeliveryDate, workSiteLocationId, notes) and the initial status (Draft by default).

  5. Add each output line with its rolled-up cost. For every line, call WorkOrders.addItem with the SKU id, quantity, computed materialUnitCost, and the user-supplied conversionCost. The cost rollup recurses through the BOM: each bom_input contributes quantity × unit_cost, where unit_cost for a material input is the FIFO weighted-average from the materials ledger (covering the next quantity units to be consumed from the oldest layers at the work-site location), and for a SKU sub-assembly input is recursively computed via the same formula against that SKU's BOM (a SKU input with no BOM contributes its FG-ledger FIFO weighted-average instead). Multi-level BOMs work the same way at any depth.

  6. Snapshot the recipe into work_order_inputs. For every output line, call WorkOrders.addInputsForItem with the resolved inputs from step 5. Each snapshot row carries material_id XOR input_sku_id, the per-output-unit quantity from BOM, and the computed unitCost at snapshot time. This freezes both identity and quantity (BOM edits afterwards do not affect this WO) but leaves cost values updatable by W027's cascade.

  7. Reconcile the inventory ledger to the seed status. Run the status → ledger reconciliation projector. For the current status it writes: an FG ORDER per output line and a DEMAND per BOM-snapshot input — materials or FG ledger per input kind — once status leaves Draft (and is not Cancelled); and an ALLOCATE per input once status reaches Production or beyond (In Transit, Partial, Received, Completed). A WO created at the default Draft writes nothing. CONSUME and PRODUCE stay receipt-driven (W137).

Returns​

The new WO with hydrated items and recipe snapshot.

Business rules​

  • BOM is required for every output SKU. WOs without recipes are rejected at step 3.
  • materialUnitCost is computed by L3, not user-supplied. The cost rollup is the workflow's job; L2 just stores what it's given. Conversion cost is user-supplied.
  • Snapshot freezes identity and quantity, not cost. The work_order_inputs rows are the consumption contract for this WO; later BOM edits do not affect them. Cost values on the snapshot are updated by W027's cost cascade as upstream prices change.
  • Ledger reconciliation is idempotent. Step 7 computes the desired FG ORDER / DEMAND / ALLOCATE set from the seed status and only writes what's missing, so create and later updates (W132) share the same projector and re-runs are no-ops. CONSUME / PRODUCE stay receipt-driven (W137).
  • Multi-level BOMs are supported. A SKU sub-assembly input recurses through its own BOM during cost rollup. Cycle detection is out of scope for v1; the team relies on data hygiene.

Errors​

  • NotFoundError. The location, an output SKU, or its BOM was missing.
  • ValidationError. An output SKU has no BOM.