NS work order — master

The production side, two categories

The NS work order lifecycle is the production side of the transaction at GFS — the way the company assembles or builds finished goods. Per Mike's actual process, every WO falls into one of two categories.

Path 1 — WO created FROM a Sales Order. One or more lines on a customer SO require assembly. A Work Order is created FROM the SO so records stay linked end-to-end (workorder.createdfrom = so.id). Components are reviewed, production runs, Assembly Build is entered in NetSuite (Mike approves at /assembly-build.html), finished goods are added to inventory at the correct location, then the SO is fulfilled. Item Fulfillment fires the ★ automation alert to Finance, who reviews, invoices, monitors terms, applies payment, and closes the order. If the FG is already on hand, the shortcut is to fulfill from inventory and close the WO marked unused.

Path 2 — WO created for inventory build (for stock). When the company builds product into inventory for future sales / sell-through. WO is entered standalone in NetSuite (no parent SO), item / qty / location / components confirmed, production runs, Assembly Build completed, FG added to inventory, components consumed, WO closes naturally. No customer side. No Finance handoff on the WO itself — Finance enters later when a future SO sells the FG.

Diagram: ns-work-order-master.html. Path detail docs: Path 1 from sales order · Path 2 inventory build. Open TBD: Work Order customer PO# field — pending Mike's review (expected pattern bodyFields.memo).

Trigger conditions

• Customer SO contains a line with itemtype = Assembly — Path 1.
• An assembly's quantityavailable drops below its reorder_point — Path 2.
• Forecast / planned production for stock — Path 2.
• Bid pre-build ahead of a QBL (e.g. B5875 release order coming) — Path 2.
• USDA entitlement drawdown commit (e.g. barrel cheddar processing) — Path 2.
• R&D pilot run validating a new BOM — Path 2.

Two builds in one day

Intake → classify → build → close

Common intake steps run first. Then the WO branches into one of two paths based on origin. Both paths share the common production lane (components → build → Assembly Build → FG to inventory). Path 1 continues into SO fulfillment + Finance; Path 2 closes at FG availability.

Common steps (every WO)

1. 01

   WO intake (production side)

   Production request enters NetSuite. Sources: upstream SO with assembly_line, or inventory build need (reorder, forecast, bid pre-build, USDA, R&D pilot).

   Writes NS workorder, work_orders
2. 02

   Classify WO origin

   Operator (today) classifies by origin. SO-driven assembly → Path 1. Stock build for future demand → Path 2. Auto-classifier is a STUB.

   Decision from_sales_order · inventory_build

Path 1 — WO created FROM Sales Order

1. 1.1

   WO created FROM SO

   For each assembly line, a Work Order is created with workorder.createdfrom = so.id — preserves SO ↔ WO link end-to-end. Alternate: if FG already on hand at location, fulfill SO from inventory + close WO marked unused.

   WO PO# field TBD — expected bodyFields.memo = SO.otherrefnum
2. 1.2

   Component availability reviewed

   BOM lookup, on-hand check at correct location, warn if short components.

3. 1.3

   Production / assembly completed

   Crew executes build on production floor. Components debited per BOM.

4. 1.4

   Assembly Build completed in NetSuite

   NS AsmBuild record posted (createdfrom = wo.id, quantity_built, waste). Mike approves at /assembly-build.html.

5. 1.5

   FG added to inventory at correct location

   inventory_balance.quantityavailable += quantity_built at the WO's location_id.

6. 1.6

   SO fulfilled to customer · Item Fulfillment

   NS ItemShip posted with createdfrom = so.id (NOT wo.id), otherrefnum inherits from SO. ★ Automation alert fires to Finance.

7. 1.7

   Finance review · invoice · payment · close

   Finance reviews fulfillment, posts CustInvc, monitors AR terms, payment received + applied, order closed.

Path 2 — Inventory build for stock

1. 2.1

   WO entered in NetSuite (standalone)

   WO created with createdfrom = NULL — no parent SO. Build reason captured (reorder_point / forecast / bid_pre_build / usda_drawdown / rd_pilot).

2. 2.2

   Item, qty, location, component requirements confirmed

   Operator confirms item, quantity, location, component requirements derived from assembly_bom.

3. 2.3

   Component availability reviewed

   BOM lookup, on-hand check. If short, stage a purchase order (Path 2 has no customer pressure since no SO).

4. 2.4

   Production / assembly completed

   Crew executes build for target qty. Components debited per BOM.

5. 2.5

   Assembly Build completed in NetSuite

   NS AsmBuild record posted (createdfrom = wo.id). Mike approves at /assembly-build.html.

6. 2.6

   FG added to inventory at correct location

   FG credited at correct location_id; allocatable to future SOs.

7. 2.7

   Components consumed · WO closes naturally

   Formal component consumption posted (WkOrdIss). WO closes naturally (status='Built'). No customer side. No Finance handoff.

8. 2.8

   FG remains available for future SOs

   Finished goods sit on the shelf at the correct location, allocatable to any future Sales Order. Finance enters when that future SO sells the FG.

What's different after the cycle

• Required production / assembly completed.
• Assembly Build entered in NetSuite.
• Finished goods added to inventory at the correct location.
• Components consumed properly.
• Any production issues, shortages, variances reviewed.
• WO closed in NetSuite (status='Built').
• Path 1 only: SO fulfilled, invoice posted, payment applied, order closed.

What can go wrong

Adjacent flows + diagrams

Code paths + invariants

Dated trail · spot stale claims

Dated trail of when this doc was last touched, what changed, and what to look at if it feels stale.

The machine-readable spec

Canonical fields, table names, endpoint signatures. Master workflow_type · work_order_lifecycle · risk_level · 2. Sub-contracts: wo_lifecycle_from_sales_order_path (risk 3), wo_lifecycle_inventory_build_path (risk 2).

Customer PO# threading on WO — TBD pending Mike review

Mike's notes confirmed PO# threading on every other record in the SO chain. The WO body field is the only TBD. Expected pattern: bodyFields.memo (mirrors PO threading). Path 1 only; Path 2 has no customer PO# (no parent SO).

Trace recipe (Path 1): grep "72622" across transactions.otherrefnum + item_fulfillments.otherrefnum + customer_invoices.otherrefnum. The WO row is the missing link until Mike confirms which body field carries the threading. Action: Mike to confirm. Default placeholder: WO.memo = SO.otherrefnum.

WO origin classification (drives sub-contract dispatch)

Inputs (required + optional)

D1 tables touched (across both paths)

Endpoints called

Events fired

It broke at 2am — what now

Different from "how do I use this." This is the page Mike pulls up when something is wrong: logs to check, recovery steps, who to escalate to.

Logs to check

• workflow_run_log · top-level run audit (work_order_lifecycle and sub-contracts)
• workflow_step_log · per-step trace
• workflow_verify_results · post-window verify outcomes (incl. WO PO# TBD check)
• events · workorder.created / .built / wo.finance_alert_fired trail
• proposed_actions · Assembly Build HITL gate state
• npx wrangler tail · live Worker logs

Kill switch · emergency stop

• kill:ns_writes · stops every NS push platform-wide
• kill:proposed_apply · stops HITL approvals from executing fan-out
• kill:high_risk_ops · stops risk_level ≥ 4 fan-out

Escalation

Primary: Mike Levine (single-admin) · mikelevine@globalfoodsolutions.co. For production-floor outage during business hours, notify warehouse lead so dependent SOs can be re-planned.

What's not done · what's uncertain

What's not done, what's uncertain, what we punted. Captured so it survives context switches and doesn't die in someone's head.

• TBD
  WO customer PO# field — Mike review pending

  Every WO Schema reference is flagged TBD until Mike confirms which body field carries the customer PO# threading on Path 1. Expected pattern: bodyFields.memo. Once confirmed, add verify_check WO.memo == SO.otherrefnum to wo_lifecycle_from_sales_order_path.

• STUB
  Auto-classify WO origin (from_sales_order vs inventory_build)

  Today operator decides. Classifier on /api/wo/create could auto-dispatch based on the presence of a parent SO assembly_line.

• STUB
  NS workflow for Path 1 Finance alert

  Platform fires events.wo.finance_alert_fired today. The actual NS workflow trigger on itemfulfillment.status='Shipped' still needs to be built and verified in NS workflow studio.

• STUB
  Labor capture autoflow

  NS natively supports time-entries against WOs; we don't have an auto-capture surface (scanner / kiosk). Manual NS entry only today.

• DECISION
  Yield variance separate from cost variance

  Today we audit cost variance at 5% threshold. Mike's "production issues, shortages, variances reviewed" gate suggests we should also audit qty produced vs qty planned. Open whether to add a second variance threshold or fold yield into cost.

• OPEN
  Path 2 auto-stage PO if components short

  Today operator stages PO manually if Path 2 build hits component shortfall. Could auto-stage when review_components verify_check returns warn.

• DEFER
  Per-WO profitability snapshot

  Capture margin at WO completion for Path 1 (FG cost vs SO line revenue). Useful for Mike to see assembly-line margin in real time, not just at month-end.