W133: Delete work order

Wipes a WO and every inventory effect it produced on both the materials and FG ledgers. Triggered from Work Order Detail.

Steps

1. Load the WO. Call WorkOrders.getWoById.

2. Gather the WO's source ids. Before anything cascades, list the WO's items (wo_item), its input snapshots (wo_input), and its receipts' items (wo_receipt).

3. Physically delete the WO's ledger rows. Call deleteBySource on both ledgers for wo_item (the status-driven FG ORDER), wo_input (the input DEMAND/ALLOCATE), and wo_receipt (the receipt-driven CONSUME/PRODUCE). The rows are removed outright. Because every row tied to a line shares its source id, deleting by (source_type, source_id) sweeps forward, reverse, and edit-trail rows alike.

4. Detach documents. Call Documents.listByEntity('work_order', woId) and Documents.delete for each.

5. Delete the WO row. Call WorkOrders.deleteWo. Items, inputs (recipe snapshot), receipts, and receipt items cascade away at the DB layer.

Returns

Nothing.

Business rules

• Hard delete, not reversal. Deleting the WO removes its ledger rows entirely — the record never happened. Cancellation (W132, status → Cancelled) is the append-only path that reverses and keeps the audit trail.
• Atomic across both ledgers and the row delete. Steps 3 through 5 share a single transaction.
• Deleting produced-and-shipped inventory leaves the SO side hanging. Removing a WO's PRODUCE rows can drop FG on-hand below what a downstream SO already consumed. Practical guidance: do not delete WOs that have produced shipped inventory; cancel instead.
• Allowed at any status. Hard delete is rare; cancellation (W132) is the routine path.

Errors

• NotFoundError. The WO was not found.