← back to PO master wiki guide · wiki index ns-purchase-order-path-1-sales-order-connected · R593 · Path 1 detail

NS purchase order — Path 1 · connected to a Sales Order

SO entered → PO created FROM SO (preserves link + customer PO# thread) → transmit → vendor confirms → vendor ships → Item Receipt (when applicable) → SO Item Fulfillment → ★ Finance alert → Vendor Bill (thread) → pay → close

Path 1 is the PO process when triggered by a Sales Order — drop ship vendor orders or customer-specific fulfillment. For each dropship_line on the SO, a Purchase Order is created FROM the SO (purchaseorder.createdfrom = so.id), preserving the SO ↔ PO link. The customer PO# threads via PO.bodyFields.memo = SO.otherrefnum (e.g. "72622") and PO.lineFields.links[].tranid = "<so.tranid> / <customer_po>" (e.g. "1217 / 72622"). Vendor ships product (direct to customer for true drop ship, or to GFS for crossdock). Item Receipt closes the PO line (skipped when direct dropship truly bypasses warehouse). After Item Fulfillment ships the SO to the customer, the universal ★ automation alert fires to Finance. Vendor Bill carries the customer PO# thread on three fields: memo, tranid, and initialtranid. Workflow contract: po_lifecycle_sales_order_connected_path (risk 3). The customer-side invoice / dunning / payment cycle runs in parallel on the SO chain — see SO Path 3 dropship for that side.

PATH 1 REAL PO.memo + lineFields.links[].tranid + VendBill threading ★ Finance alert pending NS automation

Pipeline — Path 1 deep view (PO chain + vendor side)

idle
Layers:
Path 1 SO-connected — PO + vendor side, field-level depth + customer PO# threading 01 / SO origin (otherrefnum = customer PO#) 02 / PO created FROM SO (memo + lineFields.links[].tranid) 03 / Transmit · vendor confirms 04 / Vendor ships · Item Receipt (when applicable) 05 / SO Item Fulfillment to customer 06 / ★ Finance alert (STUB) 07 / Vendor Bill (memo + tranid + initialtranid) · pay 08 / Resolve issues · close PO + SO WHAT THIS DOES: The Sales Order is the starting point — it carries the customer's PO number on otherrefnum. That number will be threaded all the way through the PO chain into the vendor bill. NS RECORD: SalesOrd TECHNICAL DETAILS: SALES ORDER (NS SalesOrd) — origin of customer PO# threading. FIELDS WRITTEN bodyFields.tranid = "1217" bodyFields.otherrefnum = "72622" (customer PO#) bodyFields.entity = customer_id SAMPLE: Driscoll SO 1217 with 3 dropship lines via Cardinal Foods (vendor #891) STATUS: REAL Sales Order created in NetSuite otherrefnum = "72622" · tranid = "1217" entity = customer_id · 3 dropship lines D1: transactions + so_lines BACKEND · NS SalesOrd · THREAD START i WHAT THIS DOES: An operator (or rule) spots a drop-ship line on the SO and triggers Path 1. This says: 'this isn't coming from stock — open a PO to the vendor and have them ship.' NS RECORD: n/a TECHNICAL DETAILS: CLASSIFY — operator identifies dropship line on the SO. LOGIC: items.dropship = true OR items.special_order = true ACTION: trigger PO creation FROM this SO; dispatch po_lifecycle_sales_order_connected_path STATUS: REAL (operator) classify SO line · dropship = true vendor_id = 891 (Cardinal Foods) trigger PO creation FROM SO SECURITY · classifier · sub-contract i WHAT THIS DOES: Before opening the PO, confirm the vendor is active, terms are known (e.g. Net 30), and the vendor is set up to drop ship the item. NS RECORD: Vendor TECHNICAL DETAILS: VENDOR LOOKUP — confirm vendor is active and purchasable. LOOKUP vendors.status = "active" vendors.terms (e.g. Net 30) vendor capability for the item SAMPLE: Cardinal Foods #891 · Net 30 · drop ship capable STATUS: REAL vendor lookup vendors.status = "active" terms = Net 30 Cardinal Foods #891 EXTERNAL · vendor record i WHAT THIS DOES: The Purchase Order is created in NetSuite linked back to the Sales Order (createdfrom = SO id). The customer's PO# is copied onto the PO memo and into a combo string on the line links so the vendor can reference it. NS RECORD: PurchOrd TECHNICAL DETAILS: PURCHASE ORDER CREATED FROM SO — preserves SO ↔ PO link + threads customer PO#. NS RECORD: PurchOrd FIELDS WRITTEN bodyFields.tranid = "PO-7833" bodyFields.createdfrom = 1217 (SO id) bodyFields.memo = "72622" (CUSTOMER PO# THREADING) bodyFields.entity = 891 (vendor: Cardinal Foods) bodyFields.expected_delivery = datetime lineFields[].item = item_code lineFields[].quantity = qty lineFields[].rate = vendor cost lineFields[].links[0].tranid = "1217 / 72622" (SO tranid + customer PO# combo) THREADING PO.memo carries customer PO# forward to vendor lineFields.links[].tranid carries the combo string for vendor reference STATUS: REAL Purchase Order created FROM SO createdfrom = 1217 (SO id) · tranid = "PO-7833" bodyFields.memo = "72622" (customer PO# thread) lineFields.links[].tranid = "1217 / 72622" MESSAGEBUS · NS PurchOrd · PO# THREAD → i WHAT THIS DOES: The PO header and lines mirror to our D1 database within 2 minutes so we can query / display them fast without hitting NetSuite. An event fires (po.created). NS RECORD: events TECHNICAL DETAILS: D1 MIRROR (2-min hot tier). FIELDS WRITTEN purchase_orders.id, tranid, createdfrom, memo, entity, status, expected_delivery purchase_order_lines (per line) EVENT: events.po.created STATUS: REAL D1 mirror (2-min hot tier) purchase_orders + purchase_order_lines createdfrom = 1217 · memo = "72622" event: po.created DATABASE · D1 mirror i WHAT THIS DOES: PO is sent to the vendor — today by emailed PDF, future-state by EDI 850. The event po.transmitted is logged. NS RECORD: events TECHNICAL DETAILS: TRANSMIT PO TO VENDOR. TODAY: manual (email PDF to Cardinal Foods) FUTURE STUB: auto-transmit (EDI 850 outbound) EVENT: events.po.transmitted STATUS: REAL (manual) · STUB (auto) transmit PO to vendor manual: email PDF to vendor today STUB: EDI 850 outbound event: po.transmitted CLOUD · vendor channel i WHAT THIS DOES: Vendor replies with order acceptance, locked pricing, and expected ship/delivery date. Any subs or shortages are flagged here. NS RECORD: n/a TECHNICAL DETAILS: VENDOR CONFIRMS — order, pricing, expected ship/delivery date. CAPTURED order accepted vendor cost locked per line expected ship date / delivery date any subs / shortages flagged TABLES write: purchase_orders.vendor_confirmed = 1 write: purchase_orders.expected_delivery = datetime STATUS: REAL · operator records vendor confirms order / pricing / delivery order accepted · pricing locked expected ship / delivery date captured purchase_orders.vendor_confirmed = 1 EXTERNAL · vendor reply i WHAT THIS DOES: Vendor physically ships — either directly to the customer (true drop-ship) or to a GFS crossdock for a quick reroute. Tracking and ETA are captured. NS RECORD: n/a TECHNICAL DETAILS: VENDOR SHIPS — directly to customer (drop ship) or to GFS crossdock. EXTERNAL ACTION vendor: Cardinal Foods picks + packs + ships carrier: vendor-managed tracking + ETA captured ROUTE direct dropship → customer dock (skip GFS warehouse) crossdock → GFS warehouse (transient) STATUS: REAL (external) vendor ships Cardinal Foods picks + ships direct to customer OR crossdock tracking + ETA captured EXTERNAL · vendor side i WHAT THIS DOES: If goods touched GFS (crossdock case), the dock posts an Item Receipt against the PO. Direct drop-ship may skip this entirely. The Item Receipt inherits the PO's customer-PO-number link. NS RECORD: ItemRcpt TECHNICAL DETAILS: ITEM RECEIPT (when applicable) — closes PO line; inherits PO linkage. NS RECORD: ItemRcpt FIELDS WRITTEN bodyFields.createdfrom = "PO-7833" (PO id) bodyFields.status = "Received" bodyFields.received_at = datetime INHERITANCE inherits PO.memo + lineFields.tranid via NS std linkage INVENTORY EFFECT (crossdock case only) inventory_balance.quantityavailable += qty (transient, drops on IF) SKIP CASE Direct dropship may skip warehouse entirely — Item Receipt N/A STATUS: REAL Item Receipt against PO (when applicable) createdfrom = "PO-7833" (PO id) PO.memo "72622" inherits via NS std linkage PO line closes; crossdock transient OR skip on direct BACKEND · ItemRcpt · PO# threads via PO i WHAT THIS DOES: Once the Item Receipt posts, the PO line's status flips to Received and the event po.line_received fires. NS RECORD: events TECHNICAL DETAILS: CLOSE PO LINE. SQL: UPDATE purchase_orders SET status='Received' WHERE id=7833 EVENT: events.po.line_received STATUS: REAL PO line closed UPDATE purchase_orders status = 'Received' event: po.line_received DATABASE · PO close i WHAT THIS DOES: Separately, on the SO chain, an Item Fulfillment record posts to capture the customer-side ship. It carries the customer's PO# on otherrefnum (inherited from the SO). NS RECORD: ItemFulfill TECHNICAL DETAILS: SO ITEM FULFILLMENT — runs on the SO chain; PO chain side is complete after Item Receipt. NS RECORD: ItemFulfill FIELDS WRITTEN bodyFields.createdfrom = 1217 (SO id, NOT po.id) bodyFields.otherrefnum = "72622" (inherits from SO) CROSS-LINK See ns-sales-order-path-3-dropship.html for SO chain detail STATUS: REAL SO Item Fulfillment to customer ItemFulfill: createdfrom = 1217 (SO id) · otherrefnum = "72622" BACKEND · runs on SO chain · cross-link to SO Path 3 i WHAT THIS DOES: Universal handoff — receiving happens at the dock but billing/payment is Finance-owned. The automation alert tells Finance to pick up the next steps. NS RECORD: ItemRcpt TECHNICAL DETAILS: ★ FINANCE ALERT (STUB) — universal handoff. TRIGGER: Item Receipt (or fulfillment on direct dropship) EVENT: events.po.finance_alert_fired WHY: receiving at dock, billing at Finance STATUS: STUB until NS workflow build ★ automation alert → Finance events.po.finance_alert_fired · STUB until NS workflow FINANCE · ★ KEY HANDOFF i WHAT THIS DOES: Finance enters the Vendor Bill in NetSuite. On Path 1, THREE fields carry the customer's PO# — memo, tranid, and initialtranid — making the thread fully searchable. NS RECORD: VendBill TECHNICAL DETAILS: VENDOR BILL ENTERED — Finance posts against the PO. Carries customer PO# on THREE fields. NS RECORD: VendBill FIELDS WRITTEN bodyFields.tranid = "1217 / 72622" bodyFields.initialtranid = "1217 / 72622" bodyFields.memo = "72622" (customer PO# threading) bodyFields.createdfrom = "PO-7833" (PO id) bodyFields.entity = 891 (Cardinal Foods) THREADING (all three fields carry customer PO#) memo = "72622" tranid = "1217 / 72622" initialtranid = "1217 / 72622" STATUS: REAL Vendor Bill entered (Cardinal Foods) bodyFields.memo = "72622" bodyFields.tranid = "1217 / 72622" bodyFields.initialtranid = "1217 / 72622" createdfrom = "PO-7833" MESSAGEBUS · VendBill · CUSTOMER PO# THREAD i WHAT THIS DOES: Finance pays the vendor per agreed terms. NetSuite posts a Vendor Payment record applied to the bill. NS RECORD: VendPymt TECHNICAL DETAILS: VENDOR BILL PAID per vendor terms. NS RECORD: VendPymt FIELDS bodyFields.appliedto = "VB-2244" bodyFields.amount = vendor cost (lower than customer invoice) STATUS: REAL Vendor Bill paid VendPymt · per vendor terms appliedto = "VB-2244" DATABASE · VendPymt i WHAT THIS DOES: Once paid, the vendor side of the SO chain is complete and an event fires. NS RECORD: n/a TECHNICAL DETAILS: VENDOR SIDE COMPLETE. event: vendor_bill.paid STATUS: REAL vendor side complete event: vendor_bill.paid CLOUD · vendor cycle done i WHAT THIS DOES: Any open shortages, damages, substitutions, or pricing variances must be resolved before the PO can close — vendor credits issued, claims filed, etc. NS RECORD: n/a TECHNICAL DETAILS: RESOLVE SHORTAGES / DAMAGES / SUBS / PRICING — before close. CHECKS short-ships → vendor credit / rebill damages → claim substitutions → operator approves pricing variance → reconcile vs PO rate STATUS: REAL (HITL) resolve issues shortages · damages · subs pricing variance reconcile SECURITY · HITL i WHAT THIS DOES: PO status flips to Closed. Event po.closed logged. NS RECORD: n/a TECHNICAL DETAILS: CLOSE PO. ACTION: status: PO → 'Closed'; event po.closed STATUS: REAL close PO status = 'Closed' event: po.closed BACKEND · close i WHAT THIS DOES: The Sales Order itself closes only when BOTH vendor side and customer side are complete. (Customer side runs in parallel — see SO Path 3.) NS RECORD: n/a TECHNICAL DETAILS: CLOSE SO — once both customer side + vendor side complete. ACTION: status: SO → 'Closed' CROSS-LINK: SO Path 3 dropship for customer-side payment cycle STATUS: REAL close SO (both sides done) status = 'Closed' see SO Path 3 for customer side BACKEND · SO close i WHAT THIS DOES: On the SO chain, customer-side cycle is happening in parallel — customer invoice posted, dunning if past due, customer payment applied. See SO Path 3 for the detail. NS RECORD: n/a TECHNICAL DETAILS: SO SIDECAR — customer-side cycle (invoice + dunning + payment apply). DETAIL Customer invoice (CustInvc.otherrefnum = "72622") posted by Finance. Past due → ar_aging_action_plan dunning workflow. Customer payment received + applied. Runs in parallel to vendor-side cycle. SEE: ns-sales-order-path-3-dropship.html STATUS: REAL SO sidecar · customer side CustInvc + dunning + CustPymt parallel cycle on SO chain DATABASE · cross-link to SO Path 3 i classify vendor lookup createdfrom = so.id mirror sync send to vendor confirm reply vendor ships createdfrom = po.id close line fulfillment post-receipt alert memo + tranid applylist paid event wait for issues approve close SO sidecar LEGEND Path 1 SO-connected lanes ★ Finance handoff (STUB) HITL / issue resolve
Diagram glossary · colors, icons, line styles

Color codes (node fill)

Blue / data · D1 + NetSuite records
Green / backend · HITL / processing
Light blue / cloud · external service
Red / decision · classify / HITL gate
Orange / handoff · message bus / bill
Dark blue / Finance · key handoff

Line styles (arrows)

Path 1 (SO-connected) flow
Path 2 (inventory / build) flow
Finance handoff (heavy)
Optional / dashed link

Icons used (Lucide-style)

Database / NS read or write
Cloud / external service
Decision / close gate
Backend processing
Finance handoff / payment
Freight / shipping
Inventory / receipt
Review / VendBill
Read operation
Write / create record
Cross-record linkage
Flag for review
Send / transmit
Branching / dispatch
Vendor-side step

Tip: click a step number in the navigator above to highlight that node. Toggle HITL gates / Edge labels / Escalation paths with the layer buttons. Hover any node's "i" icon for plain-English popover.

NS records created / updated · field-level detail (Path 1)

StepNS recordFieldSample valueStatus
1SalesOrdbodyFields.otherrefnum (thread start)"72622"REAL
1SalesOrdbodyFields.tranid"1217"REAL
4PurchOrdbodyFields.tranid"PO-7833"REAL
4PurchOrdbodyFields.createdfrom1217 (SO id)REAL
4PurchOrdbodyFields.memo — customer PO# threading"72622"REAL
4PurchOrdlineFields.links[].tranid — SO+PO# combo"1217 / 72622"REAL
4PurchOrdbodyFields.entity — vendor891 (Cardinal Foods)REAL
4PurchOrdbodyFields.expected_deliverydatetimeREAL
9ItemRcptbodyFields.createdfrom"PO-7833"REAL
9ItemRcpt(inherits) memo via NS std linkage from PO"72622"REAL
11ItemFulfillbodyFields.createdfrom1217 (SO id)REAL
11ItemFulfillbodyFields.otherrefnum"72622"REAL
12(event)events.event_type"po.finance_alert_fired"STUB
13VendBillbodyFields.memo — customer PO# threading"72622"REAL
13VendBillbodyFields.tranid"1217 / 72622"REAL
13VendBillbodyFields.initialtranid"1217 / 72622"REAL
13VendBillbodyFields.createdfrom"PO-7833"REAL
14VendPymtbodyFields.appliedto"VB-2244"REAL
17PurchOrdbodyFields.status"Closed"REAL

Customer PO# threading on Path 1 (PO chain + vendor side)

Path 1 carries the customer PO# ("72622") through the PO chain into the vendor bill. The thread appears in 6+ field positions across 4 NS records on the vendor side alone (and threads into the SO sidecar for customer-side records):

Single-grep recipe across the Path 1 PO chain: grep "72622" across purchase_orders.memo + vendor_bills.memo + vendor_bills.tranid + vendor_bills.initialtranid lights up every record on the vendor side. Combine with transactions.otherrefnum + customer_invoices.otherrefnum for the full end-to-end trace.

Sub-contract structured detail

CTR po_lifecycle_sales_order_connected_path · risk 3 REAL

Sub-contract dispatched from the PO master when the PO origin is a Sales Order requiring drop ship or customer-specific fulfillment. Carries the customer PO# threading from the SO chain into the PO chain and onward into the Vendor Bill.
Fan-out targets
create_po_from_so · transmit_po · vendor_confirm · vendor_ships · item_receipt · so_fulfilled · finance_alert · finance_review · invoice_customer · vendor_bill_enter · vendor_bill_pay · customer_payment_apply · close_po · close_so
Tables touched
purchase_orders · purchase_order_lines · item_receipts · item_fulfillments · customer_invoices · customer_payments · payment_applications · vendor_bills · vendor_payments · transactions · events
Threading verify_check
PO.memo == SO.otherrefnum AND VendBill.memo == PO.memo AND VendBill.tranid LIKE '%' || customer_po_number — enforces customer PO# threading invariant end-to-end
Vendor-side
vendor bill + payment run in parallel to SO customer-side invoice/payment
← PO master Path 2 inventory/build →