How SO + PO + WO work together

The system of three — Mike's framing

Three NetSuite transaction lifecycles run the business. Together they are the operating system; separately they are easy to misunderstand.

• Sales Order — the customer side of the transaction. Starts with the customer order and ends with customer fulfillment, invoicing, payment, and order closure.
• Purchase Order — the vendor side of the transaction. Used when the company needs to buy product, ingredients, packaging, components, finished goods, or drop-ship items. Ends with Item Receipt, vendor bill entry, vendor payment, and PO closure.
• Work Order — the production side of the transaction. Used when the company needs to assemble or build finished goods. Ends when Assembly Build is completed and finished goods are added back into inventory.

The three flows interconnect through two cross-lane bridges and one universal convergence. SO Path 2 (assembly) creates a Work Order from the SO — WO.createdfrom = SO.id preserves the link. SO Path 3 (dropship) creates a Purchase Order from the SO — PO.createdfrom = SO.id preserves the link. WO Path 1 (from-SO) is the consuming side of SO Path 2; PO Path 1 (SO-connected) is the consuming side of SO Path 3. All three converge at the Finance handoff post-fulfillment / post-receipt. Finance reconciles SO + PO + WO at monthly close.

Diagram: sales-purchase-work-order-integration.html. Lane masters: SO master · WO lifecycle. Cross-lane bridges live in SO Path 2 and SO Path 3.

Decision logic — when does an order spawn each combination?

A single Sales Order routinely spans multiple lifecycles because lines often differ in item type. The decision happens at SO entry — today operator-driven, tomorrow auto-classified.

Driscoll orders 50 cases of Right Start RS-12

Four scenarios — from simplest to most complex

Same SO entry, four different fan-out shapes. The path classification at step 04 decides which lifecycles fire.

Scenario 1 — Simple inventory order (SO only)

1. 01

   SO entered with all-inventory lines

   All lines fall under inventory_item. No assembly, no dropship. Path 1 only.

2. 02

   Lane 1 SO Path 1 runs

   Reserve qty → pick → pack → stage → Item Fulfillment closes. Inventory decrements.

3. 03

   ★ Finance handoff fires once

   SO side only. Invoice posted, AR open, payment received, SO closed. PO and WO lanes never engaged.

Scenario 2 — Assembly order (SO + WO chain)

1. 01

   SO entered with assembly lines

   One or more lines are assembly_item. SO Path 2 dispatches.

2. 02

   Lane 3 WO spawned from SO

   WO.createdfrom = SO.id. WO entered → released → components reserved against BOM.

3. 03

   Assembly Build completes

   HITL at /assembly-build.html. BOM consumed, FG credited back to inventory. WO closes.

4. 04

   Lane 1 SO fulfills from new FG

   Now that the assembly is on hand, the SO ships. Item Fulfillment closes.

5. 05

   ★ Finance handoff fires twice

   WO close fires the WO-side roll-up (COGS + variance). SO fulfillment fires the SO-side alert (invoice posting).

Scenario 3 — Dropship order (SO + PO chain)

1. 01

   SO entered with dropship lines

   One or more lines are dropship_item or special-order. SO Path 3 dispatches.

2. 02

   Lane 2 PO spawned from SO

   PO.createdfrom = SO.id. PO.memo = customer PO#. PO transmitted to vendor.

3. 03

   Vendor ships · Item Receipt posted

   Vendor ships direct to customer (or to GFS crossdock). IR.createdfrom = PO.id. PO line closes.

4. 04

   Lane 1 SO fulfills

   Item Fulfillment closes for the dropship line.

5. 05

   ★ Finance handoff fires twice

   PO side: Item Receipt queues 3-way match for vendor bill entry. SO side: fulfillment fires invoice posting. Both alerts are by design — not duplicates.

6. 06

   Vendor bill cycle runs in parallel

   Finance enters VendBill against PO. Paid per vendor terms (separate cycle from customer-side invoice).

Scenario 4 — Mixed order (SO + WO + PO, most common)

1. 01

   SO entered with multi-line, multi-type

   SO has lines that fall into ALL three buckets — some inventory, some assembly, some dropship. This is the common case at GFS.

2. 02

   The SO fans out into BOTH a WO AND a PO from the same SO

   Path 2 spawns Lane 3 WO with WO.createdfrom = SO.id. Path 3 spawns Lane 2 PO with PO.createdfrom = SO.id. Path 1 lines pull from existing inventory in parallel. All three threads run concurrently.

3. 03

   Production + vendor + inventory all converge

   WO closes → FG in inventory. PO ships → Item Receipt posts. Inventory lines stay reserved. Once all three threads are ready, Lane 1 Item Fulfillment closes for the whole SO.

4. 04

   ★ Finance handoff fires THREE TIMES

   SO-side alert (fulfillment), PO-side alert (Item Receipt), WO-side alert (close + variance). Finance reconciles all three at monthly close. The customer PO# threads through every record.

What's different after the cycle

• Customer received the entire mixed order in a single shipment (or coordinated drops).
• FG inventory reflects new assembly builds; raw inventory reflects component consumption.
• AR open for customer-side invoice; AP open for vendor-side bill; COGS adjusted for build variance.
• Customer PO# threads through every record — single grep lights up the whole chain.
• Events ledger: so.created, workorder.created, purchaseorder.created, itemfulfillment.completed, so.finance_alert_fired, po.finance_alert_fired, wo.closed, order.closed, po.closed.

What can go wrong — cross-lane edition

Adjacent docs + 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, cross-record linkage. What code should match, what tests should assert.

Cross-record linkage (the bridge table)

D1 tables involved (across the 3 lifecycles)

Events fired across the 3 lifecycles

It broke at 2am — what now

Cross-lane incidents. Different from a single-lane failure — here the linkage between lifecycles is what broke.

Logs to check

• events · cross-lifecycle event trail — trace by so_id or customer_id
• sync_log · D1 mirror freshness for transactions table
• ns_pending_pushes · write-backs queued but not yet drained
• workflow_run_log · assembly_build_review, ar_aging_action_plan
• npx wrangler tail · live Worker logs for /api/so/create and /api/sync/run

Kill switch · emergency stop

• kill:ns_writes · stops every NS push platform-wide (halts all 3 lifecycles)
• kill:so_fanout · stops the SO → WO/PO fan-out (lifecycles still work independently)
• kill:finance_alerts · suppresses the ★ handoff (Finance fails closed, manual reconcile)

See kill-switches-state-machine.html for the full state machine + recovery procedure.

Escalation

Primary: Mike Levine (single-admin) · mikelevine@globalfoodsolutions.co. For prolonged cross-lane outage, notify warehouse lead (Lane 1 + 3) and accounting lead (Lane 2 + 4) so they can defer dependent work.

What's not done · what's uncertain

Open punch list captured so it survives context switches.

• TBD
  WO customer PO# field

  WO has no canonical place for the customer PO# yet. Expected pattern is bodyFields.memo. Pending Mike's review — once decided, the universal thread becomes complete across all 3 lifecycles.

• STUB
  Finance alert NS automation

  SO/PO/WO finance alerts fire as platform events today. The NS workflow build that delivers them into Finance's review queue is planned for R594. Until then Finance gets the events ledger view, not a queued task.

• STUB
  Auto-classification of which path/combination applies

  Today operators classify each line by item type mentally. A classifier on intake would surface mixed-path orders earlier and auto-stage WO + PO from the SO via a single fan-out endpoint.

• DECISION
  Monthly close reconciliation as a 27th v2 workflow contract

  The Finance step that ties SO + PO + WO together at month-end is Finance-manual today. Promoting it to a workflow contract would automate the variance roll-up + cross-lane reconcile. Pending Mike's call.

• OPEN
  De-duplicate Finance alerts in the review UI

  Mixed orders fire 2-3 alerts (SO + PO + WO). Each is meaningful and shouldn't be suppressed at source, but Finance UI should group them visually by customer/SO id.

• DEFER
  Real-time cross-lane visibility dashboard

  One screen that shows, for a given customer order, the live state of all 3 lifecycles + Finance posture. Defer until the NS workflow alerts land (R594) so we have something real to surface.