Lead Time flow 4 — Original Lead Time on the sales order line
The other three lead-time flows keep the current promise up to date. This one does the opposite: it records what the customer was actually told at the moment they ordered, on the order line itself, so that promise survives even after the item's live lead time has moved on.
Partly documented. The NetSuite side — the saved search, its columns, and the field written — is verified against production. The Celigo internals are not: the connector was unavailable when this entry was written, so the flow's script and mappings have not been read. The entry stays
draftuntil they have been. Everything unestablished is marked as such rather than guessed.
Rules & IDs
| Rule ID | Rule | Reading |
|---|---|---|
LI-BL-ORD-001 |
Stamp the promised lead time onto the order line | Business logic |
Why ORD and not INV. The other lead-time rules are inventory rules — they describe when
stock becomes available. This one describes a property of an order: what we committed to, on
a particular line, on a particular day. It would still mean the same thing if the inventory
system were replaced. Domain codes follow meaning, not folder (CONVENTIONS §4), which is why it
sits in the lead-time folder with an order-domain ID.
| What | Name in the system | |
|---|---|---|
| Celigo flow | 65e048814579398b59bcf267 — Original Lead Time V2 | open in integrator.io |
| NetSuite saved search | customsearch5948 — SCRIPT | SALE ORDERS | ALL | UPDATE ORIGINAL LEAD TIME V2 *live | open search 5948 |
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.
Stamp the promised lead time onto the order line LI-BL-ORD-001
What it does. It writes the lead time a customer was promised at the moment they ordered onto the order line itself, as Original Lead Time, so the promise survives every later change to the product's live lead time.
Why it exists. A lead time changes. Stock arrives early, a container is delayed, a supplier re-quotes — and the number on the product page moves with it. None of that changes what the customer was told when they paid. Without a record of the original promise there is no way to answer the only question that matters when an order runs late: what did we actually say?
This rule writes that answer down, once, on the order line, at Original Lead Time.
Who it affects. Customer service and showroom staff first, because they are the ones asked "when was I told this would arrive?". Supply chain feels it next, because the delay notifications are measured against this value. The customer feels it last, in whether the answer they get is the one they were actually given.
Who reads it afterwards.
| Reader | Uses it to |
|---|---|
| Supply chain notifications | Work out when an order has slipped past what was promised, and what to send next |
| Delay emails | Decide that a delay has happened at all, and how late it is |
| Sales, customer service and showroom staff | Answer "when was I told this would arrive?" without reconstructing it |
When it runs. Three times a day, Sydney time — 11:50am, 6:50pm and 11:50pm. It is not part of the flow 1 → flow 2 chain, and it does not trigger anything else. It runs on its own schedule and looks at orders.
What it looks at. One row per sales order line, with the order's date, the line's item, the lead time the line already carries, and the item's own live lead-time figures — arrival date, dispatch band, our stock, the supplier's stock and the supplier's date.
How it decides. Not yet established, and deliberately not guessed at. What is known:
- It reads one row per sales order line, three times a day.
- Each row carries the order's date, the line's current Original Lead Time, and the item's own live lead-time figures — arrival date, dispatch band, our stock, the supplier's stock and the supplier's date.
- One of those inputs becomes the stamped promise. Which one, and how the order date factors in, is in the Celigo script, which has not been read.
- Whether an existing value is ever overwritten is also unknown — and it is the question that matters most, because a promise that moves is not an original promise.
Outcomes. The line is stamped with an Original Lead Time · the line is left as it is — whether that second outcome exists at all is open question 2.
The one-line version. A lead time is a promise; this is where the promise is kept.
Not yet established. Exactly which of those inputs decides the date, and whether an existing value is ever overwritten, is in the Celigo script — which has not been read yet. The shape of the rule is recorded here; the arithmetic is not. See Open questions.
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 stamp is written back to. | confirmed |
| Document NumberSales Order | The order number the customer and the team quote, e.g. S319344. | Identification and traceability only. | confirmed |
| Line IDSales Order line | Which line of the order this is. | The stamp is per line, not per order — every item on an order can carry a different promise. | confirmed |
| DateSales Order | When the order was placed. | The point the promise is measured from. | confirmed |
| Original Lead TimeSales Order line | The Original Lead Time the line already carries. | The existing value. Whether the automation only writes when this is empty, or overwrites it, is not yet established — see the open questions. | confirmed |
| Next Available Receive DateInventory Item | When the next stock of the item is expected — the value the lead-time chain maintains. | The most likely basis for the promise. This is the field flows 1 and 2 write. | confirmed |
| Ship DateSales Order line | The ship date currently on the line. | Not yet established. | confirmed |
| Ships InInventory Item | The dispatch band the item carried at the time — "Ships in 6 - 8 weeks" and so on. | The item-level promise as flow 2 last set it. | confirmed |
| Qty Available (Warehouse)Inventory Item | Stock on hand for the item. | Not yet established. The sample returns several rows per line with different values here — see the open questions. | confirmed |
| needs confirmingSales Order line | needs confirming | Not yet established. | needs confirming |
| needs confirmingInventory Item | needs confirming | Not yet established. | needs confirming |
| Supplier Quantity On HandInventory Item | The supplier's own stock on hand. | Not yet established. | confirmed |
| Supplier Quantity On OrderInventory Item | The supplier's own stock on order. | Not yet established. | confirmed |
| Supplier Next Available Receive DateInventory Item | When the supplier expects their next stock. | Not yet established. | confirmed |
| needs confirmingInventory Item | needs confirming | Not yet established. Likely the purchase order stage, which a separate flow maintains. | needs confirming |
| Preferred SupplierInventory Item | Which supplier the item is normally bought from. | Not yet established. | confirmed |
| Lead SourceSales Order | Where the order came from — the website, a showroom, and so on. | Not yet established. Likely distinguishes a promise made online from one made in a showroom. | confirmed |
| needs confirmingItem | Whether the line is a stocked item, a kit, and so on. | Not yet established. Kits and items carry their lead times differently, so this probably matters. | 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 |
|---|---|---|---|
| Original Lead TimeSales Order line | The maximum lead time for the item as shown on the website, or as communicated to the customer in a showroom. | The record of what the customer was told when they ordered. Read afterwards by supply chain notifications, delay emails, and by the team when a customer asks what they were promised. | confirmed |
Inputs
What it reads, and where from.
One NetSuite export, saved search 5948 on the transaction record, returning one row per
sales order line. Confirmed live on 2026-08-21. Every column is in the field registry above; the
ones that matter most are the order date, the line's current Original Lead Time, and the
item's Next Available Receive Date — the field flows 1 and 2 maintain.
This is where the chain closes. Flow 1 writes the item's arrival date, flow 2 turns it into the customer-facing promise, and this flow copies a promise onto the order. The same underlying date therefore reaches the customer twice: once as a live estimate on the product page, and once as a fixed commitment on their order.
Processing
What it does with that, step by step.
Not yet documented. The Celigo script attached to this flow has not been read. Recording a plausible calculation here would be worse than leaving it blank — CONVENTIONS §1, production wins, and nothing has been verified against production yet.
What is known without it:
on schedule (11:50, 18:50, 23:50 Australia/Sydney):
read sales order lines from saved search 5948
work out the lead time originally promised for each line -- rule not yet read
write it to the line's Original Lead Time
Outputs & side effects
What it writes, and who reads it afterwards.
| Output | Written to | Downstream consumer |
|---|---|---|
custcol_agreed_due_date — Original Lead Time |
The sales order line in NetSuite | Supply chain notifications, delay emails, and the team |
The flow does not trigger any other flow, and nothing in the lead-time chain reads this value back. It is written for people and for the notification automations, not for the chain.
Worked examples
Real records carried end to end, so the logic can be checked against something that happened.
Not yet available, and not invented. Tracing an example end to end means knowing which input becomes the stamped value, and that is the open question this entry has not answered. One real observation from the live read on 2026-08-21 is worth recording, because it is the thing that makes a trace ambiguous today:
| Step | Value | Why it matters |
|---|---|---|
| Search read | Order S319344, line 1 |
Live read of saved search 5948, 2026-08-21 |
| Rows returned | Three, identical except for the item's available and on-order quantities | A single line should be a single row |
| Consequence | It is not knowable from the data which row the flow acts on, so no example can be traced honestly | Open question 3 |
A full worked example is owed once the script has been read.
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 |
|---|---|---|---|---|---|
OL-TC-T1 |
needs confirming | A sales order line with no Original Lead Time | The flow runs | The line is stamped with a value | LI-BL-ORD-001 |
OL-TC-T2 |
needs confirming | A sales order line that already carries an Original Lead Time | The flow runs | Unknown — this is open question 2. The test exists to force the answer: re-read the line and record whether the value moved | needs confirming |
OL-TC-T3 |
needs confirming | The same order line, read from search 5948 | The search is run | Today three rows come back for S319344 line 1. Expected: one |
needs confirming |
OL-TC-T4 |
needs confirming | An order for a kit item | The flow runs | Unknown — kits carry lead times differently. Open question 5 | needs confirming |
OL-TC-T5 |
needs confirming | An order placed while flow 1 or flow 2 had failed | The flow runs | The stamp records whatever the item's lead time said at that moment — including if it was wrong | needs confirming |
OL-TC-T6 |
needs confirming | The value calculated for a line | The line is compared to what the customer saw at checkout | They match. This is the test that actually matters, and it cannot be written until the calculation is documented | LI-BL-ORD-001 |
Written against what the entry can currently assert. The calculation is undocumented, so there is no test here for the value itself — pretending otherwise would give false confidence.
UAT
What a person checks, by hand, before it is trusted.
Sign-off is limited by the same gap. These steps confirm the field is being maintained; they cannot yet confirm it is being maintained correctly.
| # | Step | What to check | Signed off by | Date |
|---|---|---|---|---|
| U1 | Place a sandbox order for an item with a known lead time, and note what the product page said | You have a written record of the promise as the customer saw it | ||
| U2 | Wait for the next run — 11:50am, 6:50pm or 11:50pm Sydney time | Original Lead Time on the order line is populated | ||
| U3 | Compare it against what you noted in U1 | They agree. If they do not, stop — that is the whole rule failing | ||
| U4 | Change the item's lead time, and wait for a later run | ⚠️ Original Lead Time on the existing order line has not moved. If it has, open question 2 is answered badly | ||
| U5 | Open a delay notification for that order | It measures lateness against the stamped value, not the live one |
Edge cases
The inputs that sit at the boundary, and whether each is handled.
Not yet established. The questions that need answering are in the field registry as not yet established and in the open questions below.
Failure modes
What breaks it, how that shows, and how to recover.
| Failure | Symptom | Detection | Recovery |
|---|---|---|---|
| The flow stops running | Orders placed since carry no promise, so a later delay cannot be measured against anything | None automatic | Re-run; the gap has to be backfilled or accepted |
| The stamp is written from a stale item lead time | The order records a promise the customer was never actually shown | None automatic | Correct the line by hand |
| Flow 1 or 2 failed before an order was placed | The item's live lead time was wrong at the moment of sale, so the wrong promise is recorded as the right one | None automatic | See LT1-D1 and the flow 2 defects |
At the time of writing the flow reports no open errors in Celigo.
Known limitations
Scope that was deliberately chosen. A limitation is a decision.
| Limitation | Why it is this way | What to do instead |
|---|---|---|
| The calculation is not documented | The Celigo script has not been read. Recording a plausible one would be worse than leaving it blank — CONVENTIONS §1 | Read the script, then update this entry |
This entry is draft |
Nothing here has been verified against production behaviour beyond the search, the schedule and the written field | Do not quote it as settled |
| Nothing reads the value back into the lead-time chain | It is written for people and for the notification automations | Do not expect it to affect the storefront |
| Up to eight hours between runs | It runs three times a day on its own schedule | An order placed just after a run waits |
Known defects
Where it does something other than what was decided. A defect is a mistake.
None recorded. The flow reports no open errors in Celigo as at 2026-08-21. That is not the same as "no defects" — the calculation has not been read, so nothing about it has been checked. Open question 2, in particular, describes a condition that would be a serious defect if true.
Open questions
What could not be established. Recorded rather than guessed.
| Ref | Status | Question | Who can answer |
|---|---|---|---|
OL-Q1 |
Open | What calculates the date? The candidates are all in the search — the item's arrival date, its dispatch band, the supplier's date — but which one wins, and how the order date factors in, is in the script. | needs confirming |
OL-Q2 |
Open | Is an existing value overwritten? The search returns the line's current Original Lead Time, which suggests the flow compares against it. If it overwrites, the "original" promise is not original — it moves. That would undermine the entire point of the field and is the first thing to check. | needs confirming |
OL-Q3 |
Open | Why does the search return several rows per line? The sample returned three rows for order S319344 line 1, identical except for the item's available and on-order quantities. Either the search joins across something, or those rows are not what they appear to be. |
needs confirming |
OL-Q4 |
Open | What does leadSource do here? A promise made on the website and one made in a showroom may not be the same promise. |
needs confirming |
OL-Q5 |
Open | Are kits handled? itemType is returned, and kits carry their lead times differently. |
needs confirming |
Source references (read-only)
The code and searches this reading was written from.
NetSuite side read directly from production on 2026-08-21: saved search 5948 run live, and the
written field confirmed as CUSTCOL_AGREED_DUE_DATE, Original Lead Time, a date field on the
sales order line, described in NetSuite as capturing "maximum lead time for each item shown on
the website or communicated to customer in showrooms".
Celigo side not yet read — the integrator.io connector was unavailable. The flow's id,
name, schedule, grouping and error count come from a flow listing taken on 2026-08-21; its
export, script and import have not been opened. That is why exported_on is blank on the Celigo
code_ref and the entry is draft.
Change history
What moved on this page, and when.
| Date | Change | Change request |
|---|---|---|
| 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. 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 | 6 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 OL-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. 4 name no rule and 6 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 OL-: 5 open questions (5 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. No behaviour was re-documented, no defect status was reinterpreted, and last_reviewed is unchanged. |
— |
| 2026-09-28 | Front-matter id: LI-BL-ORD-001 replaced by ids: [LI-BL-ORD-001]. Both forms are valid per CONVENTIONS §6, but registry-index.json was a raw front-matter dump, so this entry reached the index with no ids key at all — LI-BL-ORD-001 rendered on this page, was referenced by three other entries, and was invisible to anything reading the index, including the next person allocating an ORD number (§4). The build now normalises the two forms and npm run check errors on a rule heading the front-matter does not declare. Front-matter only — no logic change, 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. depends_on: [LI-BL-INV-006] records what must already have run — a precondition, which is a weaker claim than runs_after and is drawn differently on the map. Front-matter only — no logic change, and last_reviewed is unchanged. |
— |
| 2026-08-21 | Restructured to the current registry shape: the business reading now answers what / why / who / when / how it decides / outcomes in that order; the developer reading gains worked examples, test cases, UAT, known limitations as named sections. Front-matter: version removed (nobody kept it accurate), replaced by documented_on / documented_updated for this page and script_created / script_updated for the source; links: added so the saved searches and flows are one click away. Script dates read from Celigo on 2026-08-21 (flow 65e04881, created 2024-02-29, last modified 2026-08-21). The new sections say plainly that no worked example can be traced and no test of the value can be written until the Celigo script is read — the gap is now visible rather than absent. Still draft; last_reviewed unchanged. |
— |
| 2026-08-21 | Initial entry. Business rule, purpose and downstream consumers recorded from the project owner; saved search 5948, its columns and the written field verified against NetSuite. Celigo internals not yet read, so the calculation is deliberately left undocumented | — |
Field registry — ids
Inputs
| Field id | Field name | Record | Source | Type | Read / written | Used by |
|---|---|---|---|---|---|---|
internalID |
Internal ID | Sales Order | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
SOnumber |
Document Number | Sales Order | Saved search 5948 | string | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
lineID |
Line ID | Sales Order line | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
Date |
Date | Sales Order | Saved search 5948 | date | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
OLD OLT |
Original Lead Time | Sales Order line | Saved search 5948 | date | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_receiveDate |
Next Available Receive Date | Inventory Item | Saved search 5948 | date | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_shipDate |
Ship Date | Sales Order line | Saved search 5948 | date | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_shipsIn |
Ships In | Inventory Item | Saved search 5948 | select | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_qtyAvailable |
Qty Available (Warehouse) | Inventory Item | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_qtyBackordered |
needs confirming | Sales Order line | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_qtyOnOrder |
needs confirming | Inventory Item | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_SQOH |
Supplier Quantity On Hand | Inventory Item | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_SQOO |
Supplier Quantity On Order | Inventory Item | Saved search 5948 | integer | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_SRD |
Supplier Next Available Receive Date | Inventory Item | Saved search 5948 | date | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_poStageID |
needs confirming | Inventory Item | Saved search 5948 | select | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
item_prefferedSupplier |
Preferred Supplier | Inventory Item | Saved search 5948 | select | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
leadSource |
Lead Source | Sales Order | Saved search 5948 | select | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
itemType |
needs confirming | Item | Saved search 5948 | string | read | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
Outputs
| Field id | Field name | Record | Source | Type | Read / written | Used by |
|---|---|---|---|---|---|---|
custcol_agreed_due_date |
Original Lead Time | Sales Order line | NetSuite | date | written | Stamp the promised lead time onto the order lineLI-BL-ORD-001 |
Hover any box to see what it means. Click to pin it.