Supply Chain — Item Stage

Every open sales order line carries a short message telling the customer where their item is up to. Once a day this automation rewrites that message, by asking two questions in order: what is happening on the order line itself, and — only when stock has been earmarked against a shipment that has not landed yet — how far along that shipment is. It also stamps which purchase order the stock was matched to, and it writes nothing at all when none of the three values has changed.

Rules & IDs

Rule ID	Rule	Reading
`LI-BL-CMS-001`	What the order line says on its own	Business logic
`LI-BL-CMS-002`	Finding the shipment behind the stock	Business logic
`LI-BL-CMS-003`	What the shipment's progress says	Business logic
`LI-BL-CMS-004`	When we bother writing it back	Business logic

Project owner: Kim Hoang Nguyen
Developer: Kim Hoang Nguyen
For department: Customer Service
Status: draft
Documented: created 2026-08-31 · updated 2026-09-28this registry entry
Script created / updated: created 2026-08-31 · updated 2026-08-31from Celigo — flow 6a94df5d, scripts 6a94e0c8 and 6a94e131
Verified against production: 2026-08-31no version control — verified by re-reading the flow
Systems touched: celigonetsuite
Rules: What the order line says on its ownLI-BL-CMS-001 Finding the shipment behind the stockLI-BL-CMS-002 What the shipment's progress saysLI-BL-CMS-003 When we bother writing it backLI-BL-CMS-004
Terms: Item StageDelay CommsAllocated PO#Purchase Order StageAllocated supplyCommittedDrop shipBackorder

Where this runs

What	Name in the system
Celigo flow — the daily runCeligo flow	`6a94df5dc9aff11647cf8b4f` — Supply Chain - Item Stage Update V3	open in integrator.io
NetSuite saved search — the order lines it looks atNetSuite saved search	`customsearch4085` — SCRIPT \| SUPPLY CHAIN \| STAGE 1 \| ITEM STAGE UPDATES V2.1/2 Live do not edit	open search 4085
NetSuite saved search — the purchase order lookupNetSuite saved search	`customsearch4084` — SCRIPT \| SUPPLY CHAIN \| STAGE 1 \| ITEM STAGE UPDATES V2.2/2 Live do not edit	open search 4084
Celigo script — pass oneCeligo script	`6a94e0c89a510cb208a77826` — Supply Chain - Item Stage 1/2 V3 Sep 26	no direct link recorded
Celigo script — pass twoCeligo script	`6a94e1313b486275b545093c` — Supply Chain - Item Stage 2/2 Look up V3 Sep 26	no direct link recorded

The NetSuite links use the account-neutral host, which redirects a signed-in user to this account. Ids and names are exact, so a search stays findable by name even if a link does not resolve.

Three readings of the same rules. Nothing is duplicated between them. Printing gives you the business reading followed by the diagrams.

What it does. It decides the one-line message a customer sees against each item on their order — Ready to be shipped, On its way to our warehouse, Delayed - Item is in production, and a dozen others — and writes that message onto the order line. Alongside it, it records which purchase order the item's incoming stock was matched to, and the expected ship date for drop-ship items. It never changes quantities, dates on the order, or anything the customer is charged.

Why it exists. It is the answer to "where is my order", produced for every open line every day without anyone having to look. The same message is also read by the automation that sends delay emails, so it is not just wording — it decides who gets contacted. When it is wrong the cost lands in two places at once: a customer is told their item is on its way when it has not been made yet, and Customer Service spends the call rebuilding the true picture from the purchase order by hand. The most expensive failure is the quiet one, where a line sits on a stale message for weeks because nothing about it changed enough to be noticed.

Who it affects. Customer Service notices first, because the message is what customers quote back on the phone. Customers see it directly. Supply chain relies on the recorded purchase order to trace which shipment an item is on, and fulfilment relies on the drop-ship date. The delay email automation consumes the message downstream.

When it runs. Once a day, on a schedule, overnight Sydney time. It looks at open sales order lines supplied by a saved search — the exact conditions that search applies have not been read, and are recorded as an open question below. Nothing about it is real-time: a change made at 11am does not show on the order line until the following morning. A stale-looking message in the middle of the working day is almost always waiting for tonight's run rather than broken.

How it decides.

It reads the order line first, and asks seven questions in a fixed order — is it cancelled, has it all shipped, is it all sitting committed in our warehouse, is it partly shipped with nothing behind the rest, is there nothing reserved at all. The first question that fits decides the message and it stops there. Most lines never get past this point.
Only one answer sends it further: stock has been reserved against a shipment that has not landed yet. That line is held back and the automation goes looking for the purchase order that stock is coming in on.
It finds candidate purchase orders by the item's exact name, then accepts the first one whose expected landing date matches the line's ship date and which has enough allocated to cover what the line is waiting on. Candidates that fail either test are skipped.
Once a purchase order is accepted, the message describes the shipment, not the order — sorted into "still in production", "in transit", or "only just ordered", with three stages handled on their own.
The words "Delayed" and "Partially Shipped" are layered on top of that: Partially Shipped when some of the line has already gone out, and Delayed only when a delay email or delay call has already been recorded against the line. Nothing about how late the item actually is enters into it.
If no purchase order can be accepted, it gives up and writes the catch-all, Please contact us for more details. If a purchase order is accepted but its stage is one nobody has mapped, it leaves the existing message alone rather than blanking it.

Outcomes.

Outcome	What the customer sees
Settled by the order line alone	One of seven messages, from Cancelled through to Item is on order with Life Interiors
Settled by the matched shipment	One of eleven messages describing where the shipment is up to
No purchase order could be accepted	Please contact us for more details
A purchase order was accepted but its stage is unmapped	No change — the line keeps whatever it already said
Nothing changed	No change, and nothing is written to NetSuite at all
The line is not in the saved search	Never looked at; the message stays as it is indefinitely

Every message, and what it means

Start here if you have an order line in front of you. The rules below this are ordered the way the automation decides; this table is ordered the way a customer's question arrives. {brand} is replaced by the brand on the item — Mustard Made, Globe West, Life Interiors, and so on.

Nothing more is coming.

Message	What it means	When it appears	Rule
`Cancelled`	The line has been closed on the order. Nobody is picking, making or shipping it.	The line was closed in NetSuite. This beats every other check — a closed line reads `Cancelled` even with stock sitting committed against it.	`LI-BL-CMS-001`
`Item shipped`	The full quantity on this line has left our warehouse.	Everything ordered has been fulfilled.	`LI-BL-CMS-001`

It is here, waiting to go out.

Message	What it means	When it appears	Rule
`Ready to be shipped`	The stock is available to this order and only a delivery booking is missing.	Either the whole quantity is committed in our warehouse, or the purchase order behind it is ready for local collection at the supplier.	`LI-BL-CMS-001`, `LI-BL-CMS-003`

Watch out. This does not mean a delivery has been booked, and it does not always mean the stock is in our building. Booking is a separate process. If the line carries an Allocated PO#, the stock is at a supplier waiting to be collected, not on our floor.

It is on its way to us.

Message	What it means	When it appears	Rule
`On its way to our warehouse`	The shipment the stock is coming in on is moving — in a container, on a truck, or booked with the freight forwarder.	Stock is reserved, the shipment is in the transit bucket, and no delay has been recorded on the line.	`LI-BL-CMS-003`
`On its way to our partner's warehouse`	The supplier is still waiting on the stock arriving at their warehouse. It has one more leg to travel after that.	The purchase order sits at Local: Awaiting Stock Arrival.	`LI-BL-CMS-003`
`Item shipped by {brand}`	The supplier has dispatched it — to us, or straight to the customer.	The purchase order is marked Local: Order Shipped. This is checked before every other shipment check.	`LI-BL-CMS-003`
`Partially Shipped - Remaining item is in transit to warehouse`	Part of the line has already gone out. What is left is on a shipment that is moving.	Some quantity fulfilled, some outstanding, and the shipment behind the remainder is in transit.	`LI-BL-CMS-003`

Watch out. An item can be badly overdue and still read On its way to our warehouse. The word Delayed is not produced by dates — see the late group below.

It is still being made, or only just ordered.

Message	What it means	When it appears	Rule
`Item is on order with Life Interiors`	It is one of our own lines and we are waiting on it.	Either nothing is reserved for the line at all, or stock is reserved and the shipment is still in production with no delay recorded.	`LI-BL-CMS-001`, `LI-BL-CMS-003`
`Item is on order with {brand}/ our partner`	Nothing has been reserved yet, and it is an item a partner ships or holds for us.	No stock reserved, and the item is drop ship or is not one we import ourselves.	`LI-BL-CMS-001`
`Item is on order with {brand}`	A real purchase order exists with that supplier, placed or booked, but nothing has been made or moved.	The purchase order sits at Order Placed (Local), Local: Order Ready To Be Placed or Fully Booked by FT (Local).	`LI-BL-CMS-003`
`Remaining items incoming from our {brand} partner`	Part of the line has shipped, and the rest has nothing reserved against it at all.	Partly fulfilled, and no stock reserved for the balance.	`LI-BL-CMS-001`
`Partially Shipped - Remaining item is in production`	Part of the line has gone out. The rest is still being made.	Some quantity fulfilled, some outstanding, and the shipment behind the remainder is in production.	`LI-BL-CMS-003`

Watch out. The / our partner on the end is the tell. With it means nothing is reserved yet and no purchase order was involved. Without it means a real purchase order was found and read.

It has been flagged as late.

Message	What it means	When it appears	Rule
`Delayed - Item is in transit to warehouse`	We have already told the customer about a delay, and the shipment is now moving.	A delay email was sent or a delay call scheduled on the line, and the shipment is in transit.	`LI-BL-CMS-003`
`Delayed - Item is in production`	We have already told the customer about a delay, and the item is still being made.	A delay email was sent or a delay call scheduled on the line, and the shipment is in production.	`LI-BL-CMS-003`

Watch out — this is the one that catches everybody. Delayed is not calculated from dates. It appears only because someone recorded a delay email or a delay call against that line. An item three months overdue with nothing recorded reads On its way to our warehouse; an item recorded as delayed keeps saying Delayed until its shipment moves into a different bucket, even if it has since caught up. To make a line read Delayed, record the communication.

We could not work it out.

Message	What it means	When it appears	Rule
`Please contact us for more details`	Stock is reserved for this line, but the automation could not tie it to a purchase order it trusted — so it deliberately says nothing definite. It does not mean the item is stuck.	Almost always one of three things: no purchase order came back for that item; the purchase order's expected receipt date does not equal the line's ship date; or the purchase order does not have enough allocated to cover what the line is waiting on.	`LI-BL-CMS-002`

What to do. Open the line and compare its ship date against the expected receipt date on the purchase order the stock is really coming in on. One day out is enough to produce this message. If the dates match, check that the purchase order has enough allocated to cover the quantity the line is waiting on.

What the order line says on its own LI-BL-CMS-001

Seven checks, in this order. The first one that fits wins and nothing below it is considered. Where {brand} appears, the brand on the item is dropped into the message.

#	If…	Then the message is…	Because
1	The line is closed	`Cancelled`	A closed line is finished regardless of what stock sits against it. This deliberately beats everything below.
2	Everything ordered has been fulfilled	`Item shipped`	Nothing is outstanding, so there is nothing to describe.
3	Everything ordered is committed in our warehouse	`Ready to be shipped`	The stock is ours to give; only a delivery booking is missing.
4	Partly shipped, and nothing reserved for the rest	`Remaining items incoming from our {brand} partner`	Part has gone; the balance has no supply behind it yet.
5	Nothing reserved, and the item is drop ship or not one we import	`Item is on order with {brand}/ our partner`	It will come from the partner, not from our own stock.
6	Nothing reserved, and the item is one of ours	`Item is on order with Life Interiors`	It is our own line and we are waiting on it.
7	Some stock is reserved against an incoming shipment	(no message yet)	The order line cannot answer it. Hand over to `LI-BL-CMS-002`.
8	None of the above	`Please contact us for more details`	Deliberate refusal to guess.

Finding the shipment behind the stock LI-BL-CMS-002

Only lines that reached check 7 above get this far.

#	If…	Then…	Because
1	Candidate purchase orders are searched for	By the item's exact name	It is the only handle the search is given. An item renamed since the order was placed matches nothing.
2	A candidate's expected landing date does not equal the line's ship date	Skip it, try the next	The two dates are compared as text, so they must be identical.
3	A candidate has nothing on order, or not enough allocated to cover what the line is waiting on	Skip it, try the next	A purchase order too small to cover the line is not the one the stock is coming on.
4	A candidate passes both	Accept it, stop looking	The first acceptable candidate wins. There is no notion of a better one further down the list.
5	No candidate passes	The message becomes `Please contact us for more details`	Better to say nothing definite than to describe the wrong shipment.
6	A candidate is accepted	Its number is recorded against the line	So supply chain can trace which shipment the customer's item is on.

What the shipment's progress says LI-BL-CMS-003

Once a purchase order is accepted, its stage is sorted into a bucket and the bucket picks the wording. The checks run in this order and the first that fits wins.

#	If…	Then the message is…	Because
1	The supplier has shipped it	`Item shipped by {brand}`	It has physically left the supplier; nothing else matters.
2	The order has only just been placed or booked	`Item is on order with {brand}`	Nothing has been made or moved yet.
3	Partly shipped, and the rest is in transit	`Partially Shipped - Remaining item is in transit to warehouse`	Both facts matter to the customer, so both are said.
4	Partly shipped, and the rest is in production	`Partially Shipped - Remaining item is in production`	As above.
5	A delay has been communicated, and it is in transit	`Delayed - Item is in transit to warehouse`	We have already told them it is late, so the wording stays consistent with what they were told.
6	A delay has been communicated, and it is in production	`Delayed - Item is in production`	As above.
7	No delay communicated, and it is in transit	`On its way to our warehouse`	Neutral, accurate, and does not introduce the word "delay" to a customer who has not heard it.
8	No delay communicated, and it is in production	`Item is on order with Life Interiors`	Still being made.
9	Ready for collection locally	`Ready to be shipped`	Physically available; only collection is outstanding.
10	The supplier is waiting on stock arriving at their own warehouse	`On its way to our partner's warehouse`	It has one more leg to travel before it is even at the partner.
11	The stage is one nobody has mapped	No change — the line keeps its existing message	An unknown stage must never blank a customer-facing message.

Which stages sit in which bucket. The bucket, not the stage name, decides the wording.

Bucket	Purchase order stages	Wording it produces
In production	(Overseas) Currently in Production · (Overseas) Scheduled Booked · (Overseas) VMI ready to ship · (Overseas) Ready to Ship	rows 4, 6 and 8 above
In transit	In Transit (Local) · (Overseas) Delivery to warehouse · (Overseas) in transit · Partially Booked by FT (Local) · (Overseas) Production Complete · (Overseas) Ready to book with freight forwarder	rows 3, 5 and 7 above
Only just ordered	Order Placed (Local) · Local: Order Ready To Be Placed · Fully Booked by FT (Local)	row 2 above
Handled on their own	Local: Order Shipped · Ready For Collection (Local) · Local: Awaiting Stock Arrival	rows 1, 9 and 10 above

Two messages, two different stories. These are the ones the team gets caught by, because the same words are produced by two unrelated situations. The tell is whether the line carries a matched purchase order.

Message	Settled by the order line	Settled by the shipment	How to tell
`Ready to be shipped`	The whole quantity is committed in our warehouse	The purchase order is ready for local collection at the supplier	The order-line version has quantity committed; the shipment version has an Allocated PO# and nothing committed
`Item is on order with Life Interiors`	Nothing is reserved for the line at all	Stock is reserved, the shipment is in production, no delay communicated	The shipment version has an Allocated PO#; the order-line version has none

When we bother writing it back LI-BL-CMS-004

#	If…	Then…	Because
1	The worked-out message differs from the one on the line	Write it	This is the point of the run.
2	A new drop-ship date is supplied and differs from the one on the line	Write it	Fulfilment schedules from it.
3	A purchase order was matched and it is not the one already recorded	Write it	Supply chain traces shipments from it.
4	None of the three has changed	Write nothing	Every needless write is noise in the order's history and a wasted call to NetSuite.
5	The two drop-ship dates look different but mean the same day	Write nothing	`- None -`, blank and missing all mean "no date", and `8/12/2025` and `08/12/2025` are the same day.
6	No new drop-ship date is supplied	Leave the existing one alone	This automation never clears a date it did not set.
7	A purchase order was not matched	Leave the recorded one alone	Same reasoning — it never blanks a value it could not replace.

Field registry

Every field this automation reads or writes, by the name it carries in the system — what it means, and what changes when it changes. Field ids are in the developer reading.

Inputs — what it reads

Values the automation looks at to make its decision. Change one of these and the decision changes.

Field	What it means	What it changes	Status
Internal IDSales Order	Which sales order the line belongs to.	Identifies the order the message is written back to.	confirmed
Document NumberSales Order	The order number the customer and the team quote, e.g. S297046.	Identification and traceability only. Nothing is decided from it.	confirmed
Line IDSales Order line	Which line of the order this is.	The message is per line, not per order — every item on an order can carry a different message. This is also the key the write-back matches on, so the wrong line ID would stamp the wrong item.	confirmed
needs confirmingSales Order line	The full item name, parent and variant, exactly as it reads in NetSuite.	This is the only thing the purchase order search is given to find the incoming shipment. An item renamed after the order was placed finds nothing, and the line falls to the catch-all message.	needs confirming
Item StageSales Order line	The message the line is currently showing the customer.	Read to decide whether anything has actually changed, and overwritten when it has. If it already matches the worked-out message, nothing is written at all.	confirmed
QuantitySales Order line	How many the customer ordered on this line.	Compared against fulfilled and committed to decide whether the line is finished, ready, or partly out the door.	confirmed
Quantity FulfilledSales Order line	How many have already left the warehouse on this line.	Equal to ordered means the line is done. Between zero and ordered means the line is partly shipped, which changes the wording to "Partially Shipped…".	confirmed
Quantity CommittedSales Order line	How many are physically in our warehouse and set aside for this order.	Committed equal to ordered short-circuits everything else and produces "Ready to be shipped". Also subtracted from allocated supply when testing whether a purchase order is big enough.	confirmed
needs confirmingSales Order line	How many are earmarked for this line against stock that has not arrived yet.	The single most consequential input. Zero sends the line down the "nothing reserved" branches; greater than zero is what makes the automation go and look up a purchase order at all.	needs confirming
Delay CommsSales Order line	Whether a delay email has been sent or a delay call scheduled for this line. Blank means neither.	The only thing that turns a message into a "Delayed…" message. Nothing about dates is consulted. A genuinely late item with nothing recorded here reads as if it is on track.	confirmed
needs confirmingSales Order line	The date this line is expected to ship.	Compared character-for-character against the purchase order's expected receipt date. They must be identical for a purchase order to be accepted, so one day out sends the line to the catch-all message.	needs confirming
ClosedSales Order line	Whether the line has been closed off on the order.	Beats every other check. A closed line always reads "Cancelled", even with stock committed against it.	confirmed
needs confirmingSales Order line	Whether the item ships to the customer from the supplier rather than through our warehouse.	With nothing reserved, this is what decides between "on order with our partner" and "on order with Life Interiors".	needs confirming
needs confirmingSales Order line	Whether the item is one we import ourselves.	Read alongside drop ship to choose between the partner wording and the Life Interiors wording.	needs confirming
needs confirmingSales Order line	The brand the item belongs to.	Dropped straight into the customer-facing message. When it is empty the message renders the literal text "- None -" to the customer — see the known defects.	needs confirming
Drop Ship Expected Ship DateSales Order line	The drop-ship date the line is currently carrying.	Compared against the new date to decide whether a write is needed. "- None -", blank and missing are all treated as no date.	confirmed
needs confirmingSales Order line	The drop-ship date the saved search believes the line should now carry.	When it is present and different from the current one, the line is written back. When it is empty, the existing date is left alone — this automation never clears a drop-ship date.	needs confirming
Allocated PO#Sales Order line	The purchase order this line's incoming stock is currently recorded against.	Compared against the purchase order the automation matched. A difference is on its own enough to trigger a write, even when the message itself has not changed.	confirmed
needs confirmingItem	The item name the purchase orders are being found for.	The lookup is keyed on an exact match of this against the order line's item name.	needs confirming
Document NumberPurchase Order	The purchase order number the incoming stock is on.	Written to the order line as the allocated purchase order when the match succeeds.	confirmed
Purchase Order StagePurchase Order	How far along the incoming shipment is, in supply chain's own words.	Carried for readability. The decision is made on its internal id, not this text.	needs confirming
needs confirmingPurchase Order	The internal number behind the purchase order stage.	Sorted into one of three buckets — in production, in transit, on order — and that bucket picks the customer's wording. Three stages are handled individually instead. A stage in no bucket leaves the line's existing message untouched.	needs confirming
QuantityPurchase Order	How many are on the purchase order.	Must be greater than zero for the purchase order to be considered at all.	confirmed
needs confirmingPurchase Order	How much of the purchase order is already spoken for by orders.	The line's outstanding reserved quantity must fit inside this figure, or the purchase order is rejected and the next one is tried.	needs confirming
needs confirmingPurchase Order	When the purchase order is expected to land.	Must equal the line's ship date exactly, as text, for the purchase order to be accepted.	needs confirming

Outputs — what it writes

Values the automation puts back. Everything downstream of this rule reads them, so a wrong value here travels.

Field	What it means	What it changes	Status
Item StageSales Order line	The message the line is currently showing the customer.	Read to decide whether anything has actually changed, and overwritten when it has. If it already matches the worked-out message, nothing is written at all.	confirmed
Drop Ship Expected Ship DateSales Order line	The drop-ship date the line is currently carrying.	Compared against the new date to decide whether a write is needed. "- None -", blank and missing are all treated as no date.	confirmed
Allocated PO#Sales Order line	The purchase order this line's incoming stock is currently recorded against.	Compared against the purchase order the automation matched. A difference is on its own enough to trigger a write, even when the message itself has not changed.	confirmed
Item StageSales Order line	The message shown to the customer about where their item is up to.	The customer-facing answer to "where is my order". Also read by the delay email automation, so a wrong value here can send the wrong email.	confirmed
Allocated PO#Sales Order line	The purchase order this line's incoming stock has been matched to.	How supply chain traces which shipment a customer's item is on. Written only when a purchase order was matched — never blanked.	confirmed
Drop Ship Expected Ship DateSales Order line	When a drop-ship item is expected to leave the supplier.	Used by fulfilment for drop-ship scheduling. Written only when a new date is supplied — never blanked.	confirmed

Inputs

What it reads, and where from.

Field / source	System	Type	Notes
Saved search 4085 (Transaction)	NetSuite	one row per open sales order line	The page generator. Pulled 1,000 rows a page over a RESTlet. Its selection criteria have not been read — see open questions.
Saved search 4084 (Item)	NetSuite	zero or more purchase order rows per item	The lookup. Keyed `itemid is {{{itemMemberName_LOOKUP}}}`. Runs only for records flagged as needing it.
`CUSTOMLIST33` — Purchase Order Stage	NetSuite	22 values, 16 active	The stage ids the bucketing is built on. Read from production 2026-08-31.
`CUSTOMLIST_DELAY_COMMS` — Delay Comms	NetSuite	2 values, both active	`1` Stage 1: Delay Email Sent · `2` Stage 2: Delay Call Scheduled. Blank is neither.

The full field registry is rendered above from front-matter. Every unlabelled field is one whose NetSuite UI label has not been confirmed and is deliberately left blank rather than guessed.

Processing

What it does with that, step by step.

Two hand-offs, one per script. Pass one runs on every exported page; pass two runs on the lookup response.

PASS ONE  — on each order line, before anything is saved

  if line closed                                   -> "Cancelled"
  else if ordered - fulfilled = 0                  -> "Item shipped"
  else if ordered = committed                      -> "Ready to be shipped"
  else if partly fulfilled and reserved = 0        -> "Remaining items incoming from our {brand} partner"
  else if reserved = 0 and (drop ship or not ours) -> "Item is on order with {brand}/ our partner"
  else if reserved = 0                             -> "Item is on order with Life Interiors"
  else if reserved > 0                             -> HOLD, needs a purchase order
  else                                             -> "Please contact us for more details"

  normalise both drop-ship dates:
      "- None -" / blank / missing        -> no date
      d/m/yyyy or dd/mm/yyyy              -> yyyy-mm-dd
      anything else                       -> passed through, tagged unparsed

  needs lookup  = HOLD, or the drop-ship date moved
  needs write   = HOLD, or message changed, or drop-ship date moved


PASS TWO  — on each held line, against the purchase orders returned for its item

  for each candidate purchase order, in the order returned:
      if candidate landing date <> line ship date            -> skip, note date mismatch
      if candidate has nothing on order                      -> skip, note shortfall
      if reserved - committed  >  candidate allocated demand -> skip, note shortfall
      otherwise -> accept it, record its number, stop looking

  if a candidate was accepted:
      stage 18                                  -> "Item shipped by {brand}"
      stage in {5, 6, 19}                       -> "Item is on order with {brand}"
      partly fulfilled and stage in TRANSIT     -> "Partially Shipped - Remaining item is in transit to warehouse"
      partly fulfilled and stage in PRODUCTION  -> "Partially Shipped - Remaining item is in production"
      delay comms set and stage in TRANSIT      -> "Delayed - Item is in transit to warehouse"
      delay comms set and stage in PRODUCTION   -> "Delayed - Item is in production"
      no delay comms and stage in TRANSIT       -> "On its way to our warehouse"
      no delay comms and stage in PRODUCTION    -> "Item is on order with Life Interiors"
      stage 14                                  -> "Ready to be shipped"
      stage 15                                  -> "On its way to our partner's warehouse"
      stage 0                                   -> "Please contact us for more details"
      anything else                             -> keep the line's existing message

  if no candidate was accepted                  -> "Please contact us for more details"

  needs write = message changed
                or a new drop-ship date differs from the current one
                or the accepted purchase order differs from the recorded one

  where   PRODUCTION = {2, 9, 16, 17}
          TRANSIT    = {3, 10, 11, 20, 21, 22}
          ON ORDER   = {5, 6, 19}

Message comparison is case- and whitespace-insensitive on both sides, so a message differing only in spacing or capitalisation does not count as a change.

Decision tree — one order line, from what it says on its own to what gets written

The same logic as a path through the decisions, in the order they run.

Four stages, and they run in this order: what the line says on its own · which shipment the stock is on · what that shipment's progress says · do we write it back. Most lines are answered and finished in stage 1; only a line with stock reserved against an incoming shipment ever reaches stages 2 and 3.

Every branch names the rule it implements. The codes down the right margin are this entry's test cases — prefix them with IS-TC- to find one (T12 is IS-TC-T12). Where an open defect changes what actually happens, the branch says so and names it.

Stage 1 — what the order line says on its own. LI-BL-CMS-001

Eight checks, first match wins, nothing below it is considered. The order is the rule: a closed line reads Cancelled even with stock committed against it, and that is deliberate.

order line
 ├─ 1. line closed ?                        ──► "Cancelled"                        T1
 │        beats everything below, on purpose
 ├─ 2. ordered − fulfilled = 0 ?            ──► "Item shipped"                     T2
 ├─ 3. ordered = committed ?                ──► "Ready to be shipped"              T3
 │        ⚠ not a booked delivery, and not necessarily in our building
 ├─ 4. partly fulfilled AND reserved = 0 ?  ──► "Remaining items incoming
 │                                                from our {brand} partner"        T4
 ├─ 5. reserved = 0 AND (drop ship
 │        OR not one we import) ?           ──► "Item is on order with
 │                                                {brand}/ our partner"            T5
 │        ⚠ IS-D1: an empty brand is substituted literally, so the customer
 │          reads "on order with - None -/ our partner"                            T18
 ├─ 6. reserved = 0 ?                       ──► "Item is on order with
 │                                                Life Interiors"                  T6
 ├─ 7. reserved > 0 ?                       ──► HOLD — the line cannot answer it.
 │                                                Go to stage 2
 └─ 8. none of the above                    ──► "Please contact us for more details"

The / our partner suffix is the tell. With it, nothing was reserved and no purchase order was ever read (check 5). Without it, a real purchase order was found and matched (stage 3).

Stage 2 — which shipment is the stock on? LI-BL-CMS-002

Only lines that reached check 7 get here. Candidates are searched by the item's exact name — the only handle the search is given — and walked in the order returned.

for each candidate purchase order, in the order returned
 ├─ candidate landing date ≠ line ship date ? ──► skip, note a date mismatch        T8
 │      ⚠ compared AS TEXT. One day out is enough, and so is one format apart
 ├─ candidate has nothing on order ?          ──► skip, note a shortfall
 ├─ (reserved − committed) > candidate's
 │     allocated demand ?                     ──► skip, note a shortfall            T9
 └─ otherwise ──► ACCEPT IT, record its number, STOP LOOKING                        T7

 no candidate accepted ──► "Please contact us for more details"
                            a deliberate refusal to guess, not a stuck item

The first acceptable candidate wins — there is no better one. Which candidate comes first depends on saved search 4084's sort order, which has not been read. Two acceptable candidates and the second is never evaluated. T10

An item renamed since the order was placed matches nothing, so the line falls to the catch-all. That is a recorded unhandled edge case, not a stuck shipment.

Stage 3 — what the shipment's progress says. LI-BL-CMS-003

The accepted purchase order's stage is sorted into a bucket, and the bucket, not the stage name, picks the wording. First match wins again.

accepted purchase order · stage
 ├─  1. stage 18 — supplier has shipped   ──► "Item shipped by {brand}"
 ├─  2. stage 5, 6 or 19 — only just
 │         placed or booked               ──► "Item is on order with {brand}"
 ├─  3. partly fulfilled + TRANSIT        ──► "Partially Shipped - Remaining item
 │                                              is in transit to warehouse"
 ├─  4. partly fulfilled + PRODUCTION     ──► "Partially Shipped - Remaining item
 │                                              is in production"                  T13
 ├─  5. delay communicated + TRANSIT      ──► "Delayed - Item is in transit
 │                                              to warehouse"                      T11
 ├─  6. delay communicated + PRODUCTION   ──► "Delayed - Item is in production"
 ├─  7. no delay + TRANSIT                ──► "On its way to our warehouse"        T12
 ├─  8. no delay + PRODUCTION             ──► "Item is on order with
 │                                              Life Interiors"
 ├─  9. stage 14 — ready for local
 │         collection                     ──► "Ready to be shipped"
 ├─ 10. stage 15 — supplier awaiting
 │         stock at their own warehouse   ──► "On its way to our partner's warehouse"
 ├─ 11. stage 0                           ──► "Please contact us for more details"
 └─ 12. any stage nobody has mapped       ──► NO CHANGE — the line keeps its
                                              existing message                     T14
                                              an unknown stage must never blank a
                                              customer-facing message

 where  PRODUCTION = stages 2, 9, 16, 17
        TRANSIT    = stages 3, 10, 11, 20, 21, 22

The one that catches everybody: Delayed is not calculated from dates. It appears only because someone recorded a delay email or a delay call against that line. An item three months overdue with nothing recorded reads On its way to our warehouse; an item recorded as delayed keeps saying Delayed until its shipment moves buckets, even if it has caught up. To make a line read Delayed, record the communication. T11 T12

⚠ IS-D2, and it is under review. Three overseas stages that have not physically shipped are split across the two buckets: (Overseas) Ready to Ship counts as in production while (Overseas) Production Complete counts as in transit. So one reads as still being made and the other as on its way, from the same physical situation.

The same words, two different stories. Two messages are produced in both stage 1 and stage 3, meaning different things. The tell is whether the line carries an Allocated PO#.

Message	From stage 1 it means	From stage 3 it means
`Ready to be shipped`	The whole quantity is committed in our warehouse	The purchase order is ready for collection at the supplier
`Item is on order with Life Interiors`	Nothing is reserved for the line at all	Stock is reserved, the shipment is in production, no delay communicated

Stage 4 — do we write it back? LI-BL-CMS-004

worked-out line
 ├─ message differs from the one on the line ?        ──► write
 ├─ a NEW drop-ship date differs from the current ?   ──► write
 │      the two are normalised first, so "- None -", blank and missing are
 │      one thing, and 8/12/2025 = 08/12/2025                                      T16
 ├─ a purchase order was matched and it is not the
 │     one already recorded ?                         ──► write
 └─ none of the three changed                         ──► WRITE NOTHING            T15
                                                           the record is dropped
                                                           before it reaches NetSuite

It never blanks what it could not replace. No new drop-ship date supplied leaves the existing one alone T17; no purchase order matched leaves the recorded one alone. Blanking a value on the strength of a failed lookup is worse than leaving it stale. Message comparison ignores case and spacing, so a message differing only in those does not count as a change.

Outputs & side effects

What it writes, and who reads it afterwards.

Output	Written to	Downstream consumer
`custcolcust_item_stage` — Item Stage	Sales order line, matched on line id	The customer-facing message, and the automation that sends delay emails
`custcol_allocated_po` — Allocated PO#	Sales order line, only when the extract is not empty	Supply chain, tracing which shipment an item is on
`custcol_drop_ship_date` — Drop Ship Expected Ship Date	Sales order line, only when the extract is not empty	Fulfilment, for drop-ship scheduling

The write is a line-level update. Lines are not created and existing lines are not replaced, so a line the automation has no row for is untouched. Records that did not need a write are dropped before the import step, so they never reach NetSuite at all.

Worked examples

Real records carried end to end, so the logic can be checked against something that happened.

All three are real records, taken from the flow's own captured output on 2026-08-31, order S297046 (internal id 13557993).

Example 1 — the ordinary case: already ready, nothing written

Step	Value	Why
Input	Line 10 · Sol Round Side Table (Rosa, Travertine Finish) · ordered 1 · committed 1 · fulfilled 0
Decision	Check 3 of `LI-BL-CMS-001` fits — ordered equals committed	Checks 1 and 2 do not fit; 3 does, and it stops there
Message	`Ready to be shipped`
Written	Nothing	The line already said `Ready to be shipped`, no new drop-ship date, no purchase order matched

Example 2 — the awkward case: a message V2 could not produce

Step	Value	Why
Input	Line 14 · Palermo Fabric Dining Chair (Walnut, Chocolate Weave) · ordered 36 · committed 0 · reserved 36 · fulfilled 0 · no delay comms · ship date 4/11/2026 · currently `Please contact us for more details` · Allocated PO# `P50917`
Decision — pass one	Checks 1 to 6 all fail; check 7 fits — 36 reserved	Held for a purchase order lookup
Candidates returned	`3631` (stage 22, on order 37, allocated 36, landing 4/11/2026) then `P50917` (stage 17, on order 36, allocated 36, landing 30/9/2026)	Two purchase orders carry this item
Decision — pass two	`3631` accepted: 4/11/2026 equals 4/11/2026, and 36 − 0 fits inside 36	The first acceptable candidate wins; `P50917` is never reached
Message	Stage 22 is in the transit bucket, nothing partly shipped, no delay comms → row 7	`On its way to our warehouse`
Written	Item Stage → `On its way to our warehouse`, Allocated PO# → `3631`	Message changed and the purchase order changed. No drop-ship date was supplied, so that field is left alone

Two things worth reading twice here. First, this line was showing the catch-all message before the run — stage 22 was not in any bucket until V3 added it, so V2 left the existing message in place. Lines sitting at (Overseas) Production Complete or (Overseas) Ready to book with freight forwarder are the population whose wording V3 changes. Second, the recorded purchase order moves from P50917 to 3631 purely because 3631 came back first and passed; P50917 was rejected on its landing date.

Example 3 — a matched purchase order that is never consulted

Step	Value	Why
Input	Line 40 · Clay Stacking Dining Chair (Olive Green) · ordered 15 · committed 15 · fulfilled 0 · Allocated PO# `P50989`
Decision	Check 3 of `LI-BL-CMS-001` fits	Fully committed stock settles it before any lookup happens
Message	`Ready to be shipped`
Written	Nothing	Already correct. `P50989` is left exactly as it is — no lookup ran, so nothing could replace it

Test cases

What to run to know the behaviour is intact. Expected values, never “should work”.

Case ID	Layer	Preconditions	Input	Expected output	Rule ref
`IS-TC-T1`	needs confirming	Line closed, 5 committed, reserved 5	The run executes	Message is `Cancelled`; no lookup performed	LI-BL-CMS-001
`IS-TC-T2`	needs confirming	Ordered 3, fulfilled 3	The run executes	Message is `Item shipped`	LI-BL-CMS-001
`IS-TC-T3`	needs confirming	Ordered 3, committed 3, fulfilled 0	The run executes	Message is `Ready to be shipped`; no lookup performed	LI-BL-CMS-001
`IS-TC-T4`	needs confirming	Ordered 4, fulfilled 1, reserved 0, brand `Weave`	The run executes	Message is `Remaining items incoming from our Weave partner`	LI-BL-CMS-001
`IS-TC-T5`	needs confirming	Ordered 2, reserved 0, drop ship, brand `Kave Home`	The run executes	Message is `Item is on order with Kave Home/ our partner`	LI-BL-CMS-001
`IS-TC-T6`	needs confirming	Ordered 2, reserved 0, not drop ship, imported	The run executes	Message is `Item is on order with Life Interiors`	LI-BL-CMS-001
`IS-TC-T7`	needs confirming	Reserved 36, committed 0, ship date 4/11/2026; candidate PO landing 4/11/2026, on order 37, allocated 36, stage 22	The run executes	PO accepted; message is `On its way to our warehouse`; Allocated PO# written	LI-BL-CMS-002 LI-BL-CMS-003
`IS-TC-T8`	needs confirming	Same as T7 but the candidate's landing date is 5/11/2026	The run executes	PO rejected; message is `Please contact us for more details`	LI-BL-CMS-002
`IS-TC-T9`	needs confirming	Same as T7 but the candidate's allocated demand is 20	The run executes	PO rejected on quantity; message is `Please contact us for more details`	LI-BL-CMS-002
`IS-TC-T10`	needs confirming	Two candidates, both acceptable, landing dates identical	The run executes	The first returned is written; the second never evaluated	LI-BL-CMS-002
`IS-TC-T11`	needs confirming	Reserved 5, PO stage 3, delay comms `Stage 1: Delay Email Sent`	The run executes	Message is `Delayed - Item is in transit to warehouse`	LI-BL-CMS-003
`IS-TC-T12`	needs confirming	Reserved 5, PO stage 3, delay comms blank	The run executes	Message is `On its way to our warehouse` — not `Delayed…`, regardless of how overdue the line is	LI-BL-CMS-003
`IS-TC-T13`	needs confirming	Ordered 10, fulfilled 4, reserved 6, PO stage 2	The run executes	Message is `Partially Shipped - Remaining item is in production`	LI-BL-CMS-003
`IS-TC-T14`	needs confirming	Reserved 5, PO stage 1 (Working on Buy, inactive)	The run executes	Message unchanged from whatever the line already said; nothing blanked	LI-BL-CMS-003
`IS-TC-T15`	needs confirming	Message unchanged, drop-ship date `- None -` → blank, PO unchanged	The run executes	Nothing written to NetSuite for that line	LI-BL-CMS-004
`IS-TC-T16`	needs confirming	Line drop-ship date `8/12/2025`, new value `08/12/2025`, message unchanged	The run executes	Nothing written — the two normalise to the same day	LI-BL-CMS-004
`IS-TC-T17`	needs confirming	Message unchanged, new drop-ship date blank, existing date `4/11/2026`	The run executes	The existing date is left in place, not cleared	LI-BL-CMS-004
`IS-TC-T18`	needs confirming	Reserved 5, brand blank, nothing reserved path	The run executes	Today: `Item is on order with - None -/ our partner`. Intended: the brand, or wording that omits it	LI-BL-CMS-001`IS-D1`

UAT

What a person checks, by hand, before it is trusted.

Steps a Customer Service or supply chain user can follow with no access beyond the sales order screen.

#	Step	What to check
U1	Open a sales order with a line fully committed in the warehouse	Item Stage reads `Ready to be shipped` and Allocated PO# is untouched by the run
U2	Open a line whose stock is on an overseas purchase order marked (Overseas) in transit, with Delay Comms blank	Item Stage reads `On its way to our warehouse`
U3	On the same line, set Delay Comms to Stage 1: Delay Email Sent and wait for the next overnight run	Item Stage now reads `Delayed - Item is in transit to warehouse`
U4	Open a line reading `Please contact us for more details`, find the purchase order the stock is on, and compare its expected receipt date with the line's ship date	The two dates differ, or the purchase order's allocated quantity is short — one of the two explains the message
U5	Open a line whose purchase order is at (Overseas) Ready to book with freight forwarder	Item Stage reads `On its way to our warehouse`. Confirm with supply chain that this is the wording the business wants for that stage
U6	Change nothing on any line and let the run execute	The order's system notes show no update against those lines

Edge cases

The inputs that sit at the boundary, and whether each is handled.

Case	Behaviour	Handled?
Line closed while stock is committed against it	Reads `Cancelled` — the closed check beats everything	✅
Purchase order stage is inactive or unmapped	Existing message kept, nothing blanked, and the record is tagged in the run log	✅
No purchase order returned for the item at all	Catch-all message, and the run log distinguishes this from a purchase order that was returned and rejected	✅
Purchase order returned but rejected on date, on quantity, or on both	Catch-all message; the run log names which test failed	✅
More than one acceptable purchase order	The first one returned wins. Which one that is depends on the saved search's sort order, which has not been read	❌
Item renamed after the order was placed	The lookup matches nothing, so the line falls to the catch-all message	❌
Ship date and landing date differ by one day	Purchase order rejected; catch-all message	❌
Drop-ship date in a format the normaliser does not recognise	Passed through as text and tagged in the run log, so the comparison may be unreliable	⚠️ recorded, not corrected
Brand empty on the item	The literal text `- None -` is shown to the customer	❌ — see defect `IS-D1`
Checkbox arriving as `T`/`F` rather than a real boolean	Both forms accepted, along with `true`/`yes`/`1` and their opposites	✅
Purchase order data missing entirely because the line was never sent to the lookup	Treated as no candidates, rather than failing	✅

Failure modes

What breaks it, how that shows, and how to recover.

Failure	Symptom	Detection	Recovery
Saved search 4085 changed or renamed	The run returns no rows, or the wrong population; messages silently stop updating	None automatic. The flow completes without error	Re-check the search, re-run the flow
Saved search 4084 changed	Every reserved line falls to the catch-all message	None automatic, but the run log shows the no-purchase-order count jumping	Re-check the search, re-run the flow
A new purchase order stage is added in NetSuite and not added to a bucket	Lines on that stage keep their previous message indefinitely	The run log names it as an unmapped stage	Add the stage id to the right bucket in the pass-two script
NetSuite unavailable mid-run	Partial page written; remaining lines keep their previous message	Celigo job errors	Re-run the flow — it is safe to re-run, since it writes only differences
The flow is disabled	Every message freezes, with no error anywhere	None automatic	Re-enable it

The run log is the primary instrument. Both scripts write a single summary line per page, counting records by why they matched a purchase order or did not, by which purchase order stage they landed on, and by why they did or did not need a write, plus one worked example per distinct reason. That log is how a wrong outcome is traced back to the rule that produced it.

Known limitations

Scope that was deliberately chosen. A limitation is a decision.

Limitation	Why it is this way	What to do instead
"Delayed" depends on someone recording a delay email or call — never on dates	The field it reads exists to track whether the customer has been contacted. The wording is meant to stay consistent with what they were told, not to announce a delay they have not heard about	Treat the Delay Comms field as the switch. To make a line read `Delayed…`, record the communication
A "Delayed" fallback for lines with no matched purchase order exists in the script but is switched off	Turning it on changes what customers are told, so it is deliberately parked behind a switch	Leave it off until the business asks for it. Turning it on is a customer-facing change, not a fix
The first acceptable purchase order wins; there is no notion of the best one	Simplicity. In the common case there is only one candidate	Where a line is stamped with a surprising purchase order, check the saved search's sort order
Dates are compared as text, so formats must match exactly	Both dates come from the same NetSuite RESTlet and are formatted identically	Do not change the date format on either saved search without re-testing
The run does not filter no-change records out at the first step, so they travel through the flow before being dropped	Deliberate, for the V3 rollout: it keeps every record visible in the run log for comparison against V2	Nothing — it affects run volume and logging only, not what is written
It never clears a drop-ship date or an allocated purchase order it could not replace	Blanking a value on the strength of a failed lookup is worse than leaving a stale one	Clear them by hand where they are genuinely wrong
The message is per line, and nothing rolls it up to the order	Different items on one order legitimately sit at different stages	Read the lines, not the order
Under review, not yet confirmed as intentional: (Overseas) Ready to Ship counts as in production, while (Overseas) Production Complete and (Overseas) Ready to book with freight forwarder count as in transit — none of the three has physically shipped	The two stages were added to the transit bucket in V3; the reasoning has not been recorded	Raised as `IS-D2` below. Do not change the bucketing until supply chain confirms which wording each stage should produce

Known defects

Where it does something other than what was decided. A defect is a mistake.

Ref	Status	Defect	Rule
`IS-D1`	OpenOpen. No ticket raised yet	When the brand on an item is empty, the brand is still substituted into the message and the customer sees the literal text `- None -`. Observed in production on 2026-08-31: one open line reading `Item is on order with - None -/ our partner`	needs confirming
`IS-D2`	OpenTo be confirmed with supply chain. Raised 2026-08-31	Three overseas purchase order stages that have not physically shipped are split across the production and transit buckets, so (Overseas) Ready to Ship reads as still being made while (Overseas) Production Complete reads as on its way. May be deliberate	needs confirming

Open questions

What could not be established. Recorded rather than guessed.

Ref	Status	Question	Who can answer
`IS-Q1`	Open	What are the selection criteria on saved search 4085?Why it matters: It decides which lines are looked at at all. A line outside it keeps its message forever with no error anywhere	Whoever maintains the search
`IS-Q2`	Open	What sort order does saved search 4084 return purchase orders in?Why it matters: It decides which purchase order wins when more than one is acceptable	Whoever maintains the search
`IS-Q3`	Open	Should `IS-D2`'s stage bucketing change?Why it matters: It changes what customers are told about overseas orders	Supply chain
`IS-Q4`	Open	Which NetSuite labels sit behind the unlabelled fields above?Why it matters: The business reading of the field registry is incomplete until they are filled in	Whoever maintains the searches

Source references (read-only)

The code and searches this reading was written from.

Celigo · NetSuite Scripts › Supply Chain › Supply Chain - Item Stage Update V3 (6a94df5dc9aff11647cf8b4f) — the flow, its schedule and its step wiring (read 2026-08-31)
Celigo · script Supply Chain - Item Stage 1/2 V3 Sep 26 (6a94e0c89a510cb208a77826) — pass one (read 2026-08-31)
Celigo · script Supply Chain - Item Stage 2/2 Look up V3 Sep 26 (6a94e1313b486275b545093c) — pass two (read 2026-08-31)
Celigo · export Supply Chain: Export NSSS (6a94e00fb29e704a0f51a918) — saved search 4085, 1,000 rows a page
Celigo · export Supply Chain: PO/TO look up (6a94e377dd4eaaa042ebc59c) — saved search 4084, keyed on item name
Celigo · import Supply Chain: Import Item stage (6a94e9c5b29e704a0f51ae10) — the sales order line update and its filter
NetSuite · CUSTOMLIST33 Purchase Order Stage, CUSTOMLIST_DELAY_COMMS Delay Comms — list values (read 2026-08-31)
NetSuite · custom fields custcolcust_item_stage, custcol_allocated_po, custcol_drop_ship_date, custcol_delay_comms — labels and types (read 2026-08-31)

Change history

What moved on this page, and when.

Date	Change	Change request
2026-09-28	Added a decision tree in the skeleton's slot (CONVENTIONS §15, §16): four stages — what the line says on its own, which shipment the stock is on, what that shipment's progress says, do we write it back — in the order they run, each branch naming the rule it implements and the test case that proves it. All 18 cases are cited, and every rule, defect and case ref was checked to resolve. It restates what this entry already documents and asserts nothing new, drawn from the four rules' own tables and the two-pass pseudocode; the stage numbers and bucket sets come from the pseudocode, which is more precise than the business tables about which stage sits where. Three things the entry itself flags as catching people are called out where they happen: Delayed is recorded, never calculated from dates; `Ready to be shipped` and `Item is on order with Life Interiors` are each produced by two unrelated situations, told apart by whether the line carries an Allocated PO#; and the `/ our partner` suffix is the tell for "no purchase order was ever read". Both open defects follow deployed behaviour rather than intent — `IS-D1` on the branch that substitutes `{brand}`, `IS-D2` on the bucket split that is still under review. No logic change, no defect status reinterpreted, and `last_reviewed` is unchanged: a restatement is not a re-verification.	—
2026-09-28	Developer sections reordered to the registry's skeleton (CONVENTIONS §15): Inputs · Processing · Decision tree · Outputs · Worked examples · Test cases · UAT · Edge cases · Failure modes · Known limitations · Known defects · Open questions · Source references · Change history. The entries had drifted into two house styles — four put the proof after the outputs, four put the problems there — so every shared heading sat at a different position depending on which entry you opened; `Test cases` alone appeared at five different ones. Every section moved whole and byte-identical: nothing inside any of them was touched, and no wording changed. This entry was already in skeleton order and nothing moved. The one-line description the site now prints under each heading is generated from `build.mjs`, not written here, so it reads the same on every entry. `npm run check` warns on a wrong order and on a missing section. No logic change, and `last_reviewed` is unchanged.	—
2026-09-28	18 test cases moved from the body table into the `test_cases:` front-matter register and restated in the shape a test pack uses — Case ID · Layer · Preconditions · Input · Expected output · Rule ref. Ids become `IS-TC-<case>`, which keeps every case id the table already used while making them unique across the registry. The build renders them back under `### Test cases`, and they now also appear on the generated Test cases page, so a pack spanning two entries no longer has to be retyped. 18 name no layer — neither is inferred, and `npm run check` now counts them. No expected value was changed. No behaviour was re-documented and `last_reviewed` is unchanged.	—
2026-09-28	Defects and open questions moved from body tables into the `defects:` and `open_questions:` front-matter registers, namespaced `IS-`: 2 defects (2 open) and 4 open questions (4 still open). The build renders them back under the same headings, so the page reads as it did; the prose around those tables is unchanged. They now also appear on the generated DEFECTS and Open questions pages, which is the point — the same list was unreadable spread across nine entries in five different column shapes. Every existing ref is preserved. Its two defects were bare `D1` and `D2` — the only refs in the registry that were not unique across it — and become `IS-D1` and `IS-D2`, with every reference to them moved, including the open question that asks about one by name. No behaviour was re-documented, no defect status was reinterpreted, and `last_reviewed` is unchanged.	—
2026-08-31	Placed on the order journey: `journey_stage: order` (Order), the stage confirmed with the business. The Organisation Map now groups and orders entries by journey stage rather than by folder. Front-matter only — no logic change, and `last_reviewed` is unchanged.	—
2026-08-31	Added Every message, and what it means to the business reading — an index of all fourteen customer-facing messages grouped by what they mean to the customer, rather than by the order the automation decides them in, with the watch-outs against each group. The rules below it were already complete, but they are ordered for auditing the logic, not for someone holding an order line and a message; finding a message meant scanning four tables ordered by something other than the message. No behaviour was re-read and nothing about the logic changed.	—
2026-08-31	Initial documentation of existing behaviour, written against V3 of the flow, which replaced V2 in production the same day — V2 is now disabled. Verified against production on the same date: the purchase order stage list and the Delay Comms list were read from NetSuite; the three written fields' labels and types were read from NetSuite; the range of Item Stage values actually in use was read from open order lines, which is where defect `IS-D1` was found. The worked examples are real records from order S297046 captured by the flow itself. Not verified: the selection criteria and sort order of saved searches 4085 and 4084, which is why several field labels are blank and the entry stays `draft`.	—

Field registry — ids

Inputs

Field id	Field name	Record	Source	Type	Read / written	Used by
`SOInternalID`	Internal ID	Sales Order	Saved search 4085	integer	read	When we bother writing it backLI-BL-CMS-004
`SONumber`	Document Number	Sales Order	Saved search 4085	string	read	—
`itemLineID`	Line ID	Sales Order line	Saved search 4085	integer	read	When we bother writing it backLI-BL-CMS-004
`itemMemberName_LOOKUP`	needs confirming	Sales Order line	Saved search 4085	string	read	Finding the shipment behind the stockLI-BL-CMS-002
`itemCurrentStage`	Item Stage	Sales Order line	Saved search 4085	free-form text	read-written	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003 When we bother writing it backLI-BL-CMS-004
`itemQtyOrdered`	Quantity	Sales Order line	Saved search 4085	number	read	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003
`itemQtyFulfilled`	Quantity Fulfilled	Sales Order line	Saved search 4085	number	read	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003
`itemQtyCommitted`	Quantity Committed	Sales Order line	Saved search 4085	number	read	What the order line says on its ownLI-BL-CMS-001 Finding the shipment behind the stockLI-BL-CMS-002
`itemQtyAllocatedSupply`	needs confirming	Sales Order line	Saved search 4085	number	read	What the order line says on its ownLI-BL-CMS-001 Finding the shipment behind the stockLI-BL-CMS-002
`itemDelayCommsID`	Delay Comms	Sales Order line	Saved search 4085	list	read	What the shipment's progress saysLI-BL-CMS-003
`itemShipDate`	needs confirming	Sales Order line	Saved search 4085	date	read	Finding the shipment behind the stockLI-BL-CMS-002
`itemClosed`	Closed	Sales Order line	Saved search 4085	checkbox	read	What the order line says on its ownLI-BL-CMS-001
`itemDropShip`	needs confirming	Sales Order line	Saved search 4085	number	read	What the order line says on its ownLI-BL-CMS-001
`itemImported`	needs confirming	Sales Order line	Saved search 4085	checkbox	read	What the order line says on its ownLI-BL-CMS-001
`itemBrand`	needs confirming	Sales Order line	Saved search 4085	string	read	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003
`currentPODropShipDate`	Drop Ship Expected Ship Date	Sales Order line	Saved search 4085	free-form text	read-written	When we bother writing it backLI-BL-CMS-004
`newPODropShipDate`	needs confirming	Sales Order line	Saved search 4085	date	read	When we bother writing it backLI-BL-CMS-004
`currentAllocatedPO`	Allocated PO#	Sales Order line	Saved search 4085	free-form text	read-written	Finding the shipment behind the stockLI-BL-CMS-002 When we bother writing it backLI-BL-CMS-004
`itemName`	needs confirming	Item	Saved search 4084	string	read	Finding the shipment behind the stockLI-BL-CMS-002
`PONumber`	Document Number	Purchase Order	Saved search 4084	string	read	Finding the shipment behind the stockLI-BL-CMS-002 When we bother writing it backLI-BL-CMS-004
`POStage`	Purchase Order Stage	Purchase Order	Saved search 4084	list	read	What the shipment's progress saysLI-BL-CMS-003
`POStageID`	needs confirming	Purchase Order	Saved search 4084	integer	read	What the shipment's progress saysLI-BL-CMS-003
`POQtyOrdered`	Quantity	Purchase Order	Saved search 4084	number	read	Finding the shipment behind the stockLI-BL-CMS-002
`POQtyAllocatedDemand`	needs confirming	Purchase Order	Saved search 4084	number	read	Finding the shipment behind the stockLI-BL-CMS-002
`POExpectedReceiveDate`	needs confirming	Purchase Order	Saved search 4084	date	read	Finding the shipment behind the stockLI-BL-CMS-002

Outputs

Field id	Field name	Record	Source	Type	Read / written	Used by
`itemCurrentStage`	Item Stage	Sales Order line	Saved search 4085	free-form text	read-written	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003 When we bother writing it backLI-BL-CMS-004
`currentPODropShipDate`	Drop Ship Expected Ship Date	Sales Order line	Saved search 4085	free-form text	read-written	When we bother writing it backLI-BL-CMS-004
`currentAllocatedPO`	Allocated PO#	Sales Order line	Saved search 4085	free-form text	read-written	Finding the shipment behind the stockLI-BL-CMS-002 When we bother writing it backLI-BL-CMS-004
`custcolcust_item_stage`	Item Stage	Sales Order line	NetSuite	free-form text	written	What the order line says on its ownLI-BL-CMS-001 What the shipment's progress saysLI-BL-CMS-003 When we bother writing it backLI-BL-CMS-004
`custcol_allocated_po`	Allocated PO#	Sales Order line	NetSuite	free-form text	written	Finding the shipment behind the stockLI-BL-CMS-002 When we bother writing it backLI-BL-CMS-004
`custcol_drop_ship_date`	Drop Ship Expected Ship Date	Sales Order line	NetSuite	free-form text	written	When we bother writing it backLI-BL-CMS-004

Supply Chain — Item Stage

Rules & IDs

Every message, and what it means

What the order line says on its own LI-BL-CMS-001

Finding the shipment behind the stock LI-BL-CMS-002

What the shipment's progress says LI-BL-CMS-003

When we bother writing it back LI-BL-CMS-004

Field registry

Inputs — what it reads

Outputs — what it writes

Inputs

Outputs

Pass one — what the order line says on its own

Pass two — what the shipment's progress says

Does anything actually get written?