High-altitude master view of the entire WO process. WO is the production side of the transaction — used when the company assembles or builds finished goods. There are two main categories. Path 1 — from a Sales Order: one or more SO lines require assembly, WO is created FROM the SO (preserves SO ↔ WO link), production runs, Assembly Build is entered, FG credited, then the SO is fulfilled and Finance gets the handoff. Path 2 — inventory build: WO is created standalone for stock / future SOs, production runs, FG goes to inventory, WO closes — no customer side. The customer PO# field on the WO body is TBD pending Mike's review (expected pattern: bodyFields.memo mirroring the PO and Vendor Bill threading). Every WO Schema field reference is flagged TBD until confirmed.
workorderwork_orders · transactions (type='WorkOrd')origin = from_sales_order → wo_lifecycle_from_sales_order_pathorigin = inventory_build → wo_lifecycle_inventory_build_pathworkorder · assemblybuild · itemfulfillmentworkorder.createdfrom = so.id · assemblybuild.createdfrom = wo.id · itemfulfillment.createdfrom = so.idbodyFields.memo/assembly-build.html → proposed_actions → Mike approvesworkorder · assemblybuildworkorder.createdfrom = NULL · assemblybuild.createdfrom = wo.idassembly_bom · inventory_balanceinventory_balance (component debit)/assembly-build.html. NS posts the AsmBuild transaction; D1 mirrors. assemblybuild.createdfrom = wo.id.assemblybuild (AsmBuild)/assembly-build.html → proposed_actions → Mike approvesinventory_balance (FG credit at correct location_id)itemfulfillment (status='Shipped')itemfulfillment.createdfrom = so.id (NOT wo.id)events.wo.finance_alert_firedCustInvc, monitors AR terms, payment received + applied, order closed.CustInvc · CustPymtcustomer_invoices · invoice_lines · customer_payments · payment_applicationswork_orders.status = 'Built'Per Mike: a WO is considered complete when all of the following hold:
status = 'Built').| kind | name | purpose |
|---|---|---|
| D1 table | work_orders | WO mirror · createdfrom links Path 1 WOs back to parent SO |
| D1 table | assembly_bom | BOM per assembly_item · component qty + uom |
| D1 table | assembly_builds | AsmBuild events · createdfrom = WO id |
| D1 table | inventory_balance | per item × location · debit components, credit FG |
| D1 table | transactions | WorkOrd, WkOrdIss, WkOrdCls, Build rows |
| D1 table | item_fulfillments | Path 1 only · createdfrom = so.id |
| D1 table | customer_invoices | Path 1 only · CustInvc after Finance review |
| D1 table | proposed_actions | HITL gate for Assembly Build approval |
| D1 table | events | wo.finance_alert_fired on Path 1 IF completion |
| NS record | workorder | system-of-record for the WO |
| NS record | assemblybuild | FG production event · credits inventory |
| NS record | itemfulfillment | Path 1 only |
| Workflow contract | work_order_lifecycle (master dispatcher) | R593 · dispatches into 2 path sub-contracts |
| Workflow contract | wo_lifecycle_from_sales_order_path | Path 1 sub-contract · risk 3 |
| Workflow contract | wo_lifecycle_inventory_build_path | Path 2 sub-contract · risk 2 |
| HITL surface | /assembly-build.html | Mike approves Assembly Build proposed_actions |
Mike's notes confirmed PO# threading on SO (otherrefnum), PO (memo + lineFields.links[].tranid), Invoice (otherrefnum), Vendor Bill (memo + tranid + initialtranid). The WO field is TBD pending Mike's review.
bodyFields.memo (mirrors the PO threading)SO.otherrefnum)WO.memo field is the candidate carrier; verification awaits Mike's confirmationmemo (could be a customfield, custbody*, or no threading at all), the Path 1 verify_check needs to update post-Mike-reviewAction: Mike to confirm the WO body field that carries the customer PO# threading. Until then, every Schema field reference for WO is marked TBD — Mike review pending. Expected: bodyFields.memo.
bodyFields.memo. Until confirmed, every Schema reference is flagged./api/wo/create would auto-dispatch.WO is the only one of the three core pillars (SO / PO / WO) that needs explicit production scheduling — because we have to actually assemble. This is a side-step in the WO flow (not blocking, runs in parallel with the main lifecycle): when a WO is created, it lands on the production planning kanban for assembly scheduling.
| Aspect | Design |
|---|---|
| Surface | NetSuite Suitelet rendering a kanban board (planned · not built) |
| Columns | Backlog · Scheduled this week · In progress · Build complete · Variance review |
| Cards | One per Work Order · shows assembly item code · quantity · need-by date · component availability flag · assigned crew/line · estimated build hours |
| Drag-drop | Move card between columns → writes WO.custbody_production_status + WO.custbody_scheduled_build_date via NS user-event script |
| Component check | Card surfaces all components available · low inventory on N components · shortage — requires PO — pulled live from inventoryitemlocations |
| WO-source aware | Path 1 (from-SO) cards show parent SO# + customer PO# + need-by from SO → ranks higher when SO is bid/contract |
| Path 2 (standalone) | Cards show "build to stock" tag + target inventory level → scheduled when sell-through forecast dips below reorder point |
| NS custom fields needed | custbody_production_status · custbody_scheduled_build_date · custbody_assigned_crew · custbody_estimated_build_hours TBD pending Mike review |
| HITL gate | Drag-drop is HITL-approved per ADR-031 — Mike (or production lead) approves each schedule change before it writes back to NS |
| Why WO only | SO and PO don't need production scheduling — SO ships from inventory/dropship, PO arrives from vendor. Only WO has active assembly work that needs crew/line/time allocation. |
Not in scope for R594. Planned as a follow-up Suitelet build that mounts at /app/site/hosting/scriptlet.nl?script=customscript_gfs_production_kanban. The kanban does NOT replace any existing WO step — it's a sidecar surface for the production team to visualize + schedule build workload.