Lead Time flow 3 — Kit item lead time, rolled up from members
Some products are sold as one thing but are made of several — a bed is a headboard, a footboard and a set of slats. This flow works out what to promise a customer for the whole kit, by rolling up what flow 2 has already worked out for each component, and sends the result to Shopify.
Active. Verified against the live Celigo flow, import and script, against NetSuite and against Shopify, on 2026-09-29. The chain was validated by replaying the deployed script over a fresh export and diffing every computed value against what NetSuite holds: 15,741 comparisons, 54 differences, 99.66% agreement — 4 kits whose stock moved between the run and the replay, and the 50 behind
LT3-D10, since closed.What runs today. Script content V3.6, deployed 2026-09-29 02:04 and byte-verified against the live record, but not yet run — the flow last ran 00:13 that day, so the
LT3-D16fix is in the code and not yet in the data. The kit import carries seventeen mapping rows; both Shopify imports send nine metafields, matching inventory items. Flow 3 is chained to flow 2, runs six times a day, and writes every kit on every run — by design for now,LT3-D13. How it got here, version by version, is in Change history.⚠️ The script record in Celigo is named "Lead Time: Kit V3.1 Sep 2026 - bonded warehouse". Only the content header says V3.6. Searching Celigo for "V3.6" finds nothing. Read the header.
The kit rules have not been aligned to the September 2026 rebuild of flow 1. The business has confirmed kits should follow the same supply rules as items, as a later phase, and that how a kit's buildable quantity is defined is still to be agreed.
Where the LT- numbers map. The September 2026 rule set —
LT-001toLT-081, confirmed 2026-09-17 — is crosswalked onto registry rules in flow 1 → Confirmed rule set.LT-080, which puts kits on these rules as a later phase, is still open.
Rules & IDs
| Rule ID | Rule | Reading |
|---|---|---|
LI-BL-INV-007 |
A kit's promise is its slowest component | Business logic |
LI-BL-INV-010 |
A kit's stock is its scarcest component | Business logic |
LI-BL-INV-012 |
Bonded stock is netted per component, and never guessed into a Sydney date | Business logic |
LI-BL-INV-013 |
Whether a kit can be bought out of stock | Business logic |
LI-BL-INV-015 |
How many kits each arrival brings, and when | Business logic |
Publishing to Shopify follows LI-BL-INV-009
exactly on the two routes and the conditions, implemented by a second pair of imports. What
each import actually sends, and the two metafields that ship unguarded, are in the developer
reading under Outputs & side effects and LT3-D9.
Where this runs
| What | Name in the system | |
|---|---|---|
| Celigo flow | 66c6c406b3e285ae9902bc5f — Lead times: Kits | open in integrator.io |
| NetSuite saved search | customsearch6188 — SCRIPT | LEAD TIMES | KIT ITEMS | V2 *live | open search 6188 |
| Celigo flow (retired)Celigo flow | 5faa31bea44bdf66ac8ae144 — [PROD] Update Back Order Checkbox - Kit Items — disabled 2026-08-28, superseded by LI-BL-INV-013 | open in integrator.io |
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 works out one promise for a product sold as a set — one lead time, one arrival date, one available quantity — by rolling up the components inside it, and publishes that to Shopify.
Why it exists. A customer buying a bed does not care that it arrives as three boxes. They need one date. The honest answer is the one governed by whichever part is slowest and scarcest, because the kit cannot ship until every part of it is there.
The governing idea, in one line. A kit is as slow as its slowest member and as scarce as its scarcest member.
When it runs. Flow 2 starts it on completion, so it follows the items inside it rather than
running to its own clock. It carries no schedule of its own. This corrects what this entry said
until 2026-09-21 — see LT3-D2.
Who it affects. Customers buying anything sold as a set. Sales and showroom staff quoting on those products.
How it decides.
- It re-reads the kit's members every run, so a change to what the kit is made of is picked up next time.
- Bonded stock is netted per component, never guessed into a Sydney date for the kit as a whole.
- The promise is the slowest member's: whichever part takes longest governs the whole kit.
- The available quantity is the scarcest member's: three headboards and no footboards is zero beds.
- If any one member's promise is unknown, the whole kit says "please contact showroom".
- Nothing on order means no arrival date is written at all.
- Whether the kit can be bought while out of stock is decided here too, on two tests: every component must allow it, and the kit's own supply type must allow it.
- It then compares against what the kit already carries and writes only real changes — but the
comparison is still only half honest, so most kits are rewritten anyway. That is
LT3-D8, not a decision.
Outcomes. The kit's promise, quantities and backorder setting are updated and pushed to Shopify · the kit is told to contact the showroom, because a member's promise is unknown or nothing is sellable · the kit updates in NetSuite but never reaches Shopify, having no Shopify id. The staleness outcome this entry used to list — a kit lagging its own components by up to twelve hours — no longer applies, because flow 2 now starts flow 3.
One piece of data entry decides whether any of this runs at all. A component only enters the lead-time chain if it is marked Part Only — the tick that says this is sold inside a kit, never on its own. Confirmed by the project owner on 2026-09-30. It reads like a description and behaves like a switch: leave it off, and that component is skipped entirely. Its promise, its quantities and its backorder setting stop at whatever they last held, and every kit built from it quietly inherits those old values. Nothing fails, nothing is flagged, and the kit page keeps answering — with yesterday's answer. See the limitation rows in the developer reading for the worked example and the exposure.
Bonded stock is netted per component, and never guessed into a Sydney date LI-BL-INV-012
Added 2026-08-18, at the same time as the equivalent rule for ordinary items
(LI-BL-INV-011). It deliberately behaves
differently, and the difference matters.
Netting happens per component, not per kit. Each component's own Sydney backorder is paid down by its own bonded stock — on hand first, then on order — and only what survives is treated as sellable. Netting at kit level would offset one component's backorder against a different component's bonded stock, which is not something anyone can ship: you cannot build a bed by covering a shortage of footboards with spare headboards.
No transit estimate is made. This is the deliberate divergence from items. Flow 2 turns bonded stock into a Sydney arrival date by adding a 35-day transit allowance. Flow 3 does not. It publishes the raw Vietnam date, unchanged, in its own separate field.
Ordinary items (LI-BL-INV-011) |
Kits (this rule) | |
|---|---|---|
| Bonded stock netted against backorder | Yes | Yes, per component |
| Bonded stock produces a Sydney arrival date | Yes — its date plus 35 days | No |
| What is published | One date, meaning "lands in Sydney" | Two dates: the Sydney date, and the raw Vietnam date |
The reasoning is recorded in the flow itself: no purchase order exists for the Sydney leg yet, so there is no real arrival date until someone raises the transfer order. A kit whose only inbound stock is bonded therefore shows no Sydney date at all, and a Vietnam date instead. That is honest — we know when it lands in Vietnam, we do not yet know when it lands in Sydney — but it is the opposite choice from the one made for ordinary items, and the two will disagree for the same stock.
The arrival-date gate. A date is only shown at all when a customer could act on it. Three tests, and any one of them opens the gate:
| # | The gate opens if… | Since |
|---|---|---|
| 1 | The kit has sellable stock | original |
| 2 | The kit can be back-ordered | original |
| 3 | The arrival itself brings a complete kit — the first arrival has a quantity | V3.6, live 2026-09-29 |
If none is true, every inbound unit is already committed to existing orders, so both dates are cleared and the customer is told to contact the showroom. Advertising an arrival then would promise stock that walks straight out to the existing queue.
Test 3 exists because the first two collapse on a split kit — one where some components hold
stock and others have stock coming. LI-BL-INV-010 case 2 forces the kit's
availability to zero by design in that state, so test 1 is false by construction and the gate falls
onto the backorder flag alone; a single component with its checkbox off then switched off a date the
kit could honour. That was LT3-D16, it affected 4 kits, and test 3 closes it. The gate's stated
rationale — that inbound units are already committed — was checked against production on those kits
and was false: quantitycommitted and quantitybackordered were 0 on every component.
Whether a kit can be back-ordered is decided here, for the purposes of that gate only: a kit
is back-orderable only if every one of its components is. That is deliberately the looser of
the two answers the flow now holds — the checkbox written to the record is decided separately and
more strictly by LI-BL-INV-013, so tightening the checkbox cannot take an
arrival date away from a kit that used to show one.
Whether a kit can be bought out of stock LI-BL-INV-013
Added 2026-08-28. Until then this decision was not made here at all: a separate flow,
[PROD] Update Back Order Checkbox - Kit Items, maintained the checkbox on the kit record twice
a day. That flow is now disabled, and this rule owns the decision — finishing for kits the merge
already done for ordinary items under
LI-BL-INV-008.
It is the same commercially dangerous question as for ordinary items: whether the storefront will take money for a kit we do not have. Two gates, and both must pass.
| Gate | Test | Because |
|---|---|---|
| 1 — the components | Every component's own backorder setting allows it | Each component's setting was already decided by flow 2 under LI-BL-INV-008, against that component's own supply type. Reading it carries the components' rules without re-deciding them |
| 2 — the kit itself | The same rules again, applied to the kit's supply type and the kit's rolled-up quantities | A kit is its own record with its own supply type, and it never passes through flow 2. Without this gate the kit's own supply type is ignored entirely |
Gate 2 is LI-BL-INV-008 read against kit figures:
| # | If… | Then… | Because |
|---|---|---|---|
| 1 | The second warehouse holds stock — the scarcest component's figure | Allowed, whatever else is true | Physical stock overrides every other consideration |
| 2 | In-Store Only, kit has nothing on order | Not allowed | It cannot be shipped at all |
| 3 | Drop Ship In-Stock Only, Seasonal Only or End Of Line, with nothing on order and no supplier stock | Not allowed | There is no path to fulfilling it |
| 4 | Drop Ship Seasonal Item with nothing on order anywhere | Not allowed | Same |
| 5 | Brand is McMullin & Co. and their stock is more than 70 days away | Not allowed | That brand's waits are long enough that the order would not be honoured in a reasonable time |
| 6 | Anything else | Allowed | Default is to take the order |
Where it deliberately reads differently from items. Every quantity in gate 2 is the scarcest
component's, because that is what caps how many kits exist — the same principle as
LI-BL-INV-010. The McMullin date in rule 5 is the latest across components, not a single
item's date, because a kit cannot land before its slowest part.
A kit can be refused even when every component allows it. That is the point of gate 2, and it is the behaviour that changes on the first run: a kit on an End Of Line or In-Store Only supply type whose components are individually backorderable will now have its checkbox turned off. Before this rule, the kit's own supply type was returned by the search on every row and discarded.
A kit's promise is its slowest component LI-BL-INV-007
Every component already carries its own promise, worked out by flow 2. This rule reduces those to one promise for the kit.
| # | If… | Then… | Because |
|---|---|---|---|
| 1 | Every component has a stated wait | The kit takes the longest of them | The kit cannot ship until the slowest part arrives |
| 2 | Any component says "please contact showroom" | The whole kit says "please contact showroom" | One unknown makes the total unknown; there is no honest number to give |
| 3 | Any component has no message at all | The whole kit says "please contact showroom" | Same reasoning — silence is not a promise |
| 4 | The kit has stock on the way | The arrival window uses the latest component arrival date | The kit is not complete until the last part lands |
| 5 | The kit has nothing on the way | It carries no arrival date | There is nothing to promise |
How "longest" is judged. The waits are written as sentences, not numbers, so the wait is read back out of the words — days, business days, weeks, months and years are each converted to a number of days, and the largest wins. A business day counts as 1.4 days.
One special case. When the components are in the particular mixed state described in
LI-BL-INV-010 — some available and some only on order — the "please contact" rule above is
skipped, and the arrival window is taken from whichever component has the latest date even
if another component's promise is unknown. This is the one place the two rules interact.
A kit's stock is its scarcest component LI-BL-INV-010
You cannot sell more complete beds than you have footboards.
| # | If… | Then the kit's stock is… | Because |
|---|---|---|---|
| 0 | A component is used more than once per kit | Its figures are first divided by how many the kit needs, rounded down | Twenty-two armless pieces build eleven two-armless sofas, not twenty-two. Live since 2026-09-24 |
| 1 | Normal case | The lowest figure across all components, after that division | The scarcest part caps how many kits exist |
| 2 | Components are split — some have stock on hand and none on order, others have none on hand but some on order | Available is set to zero, and on-order is set to the lowest of those positive figures | No complete kit can be assembled today, but one is coming |
| 3 | Any component has neither stock nor anything on order | Case 2 does not apply; falls back to case 1 | Nothing is coming, so there is nothing to promise |
| 4 | Brand is Ellison Studios | A longer route: our own stock first if every component has some, otherwise the supplier's, otherwise the plain lowest | That brand's stock is held differently |
Case 2 is checked against our own stock first, and only then against supplier stock.
Case 0 was missing until 2026-09-24. Every figure was compared in component units while the
answer was read in kit units, so any kit needing two or three of a part overstated by that factor.
Of 1,749 live kits, 160 use a component more than once and 34 published a wrong figure.
Worst case measured: kit 397096 Bowie Textured Velvet 4 Seat Sofa (Terracotta) showed 22 on
order against a true 11; kits 249829 and 390230 each showed stock in a showroom that could
not be assembled. Deployed 2026-09-24 and replayed over the live export beforehand: 1,748 of 1,749
kits reproduced production exactly, and only those 34 moved.
Showroom stock is rolled up the same way — the kit shows the lowest across its components, per showroom, so a kit is only "in" a showroom if every part of it is.
What is published. The kit's own figures plus the lowest supplier figures across components go to NetSuite and on to Shopify.
How many kits each arrival brings, and when LI-BL-INV-015
Live since 2026-09-24. A customer looking at a kit that is out of stock wants two things: how many are coming, and when. This rule answers both, twice — for the next arrival and the one after it.
The unit is complete kits, never boxes. A sofa that needs two armless pieces does not gain two sofas when two armless pieces land; it gains one, and only if every other part is there too. The division is real, not theoretical: of the live kits, 158 need two of a component and 6 need three, so a rule written as the lowest component figure without it would overstate those 164.
| # | If… | Then the arrival shows… | Because |
|---|---|---|---|
| 1 | A component is used more than once per kit | Its arriving quantity divided by how many the kit needs, rounded down | Six armless pieces build three two-armless sofas |
| 2 | Every component has an arrival | The lowest of those figures | The kit is capped by whichever part arrives in the smallest number |
| 3 | A component has no arrival but has stock on the shelf | It does not cap the kit; its stock caps it instead | It is already here. It cannot delay or limit what the arrival can build |
| 4 | A component has no arrival and no stock | The kit shows blank | You cannot build a kit whose part is neither here nor coming |
| 5 | No component has an arrival at all | The kit shows blank | Nothing is on the way. Publishing on-hand stock as an arrival would be false |
| 6 | The second arrival, and a component has nothing in it | It falls back to what that component received in the first arrival, then to its stock | Confirmed by the sales team 2026-09-24. A part that arrived and has not sold is still on the shelf |
| 7 | The kit cannot be bought at all, and the arrival does not bring a complete kit | Every arrival field is blanked | The arrival-date gate in LI-BL-INV-012. Stock already committed is not an offer — but since V3.6 an arrival that builds a whole kit opens the gate on its own, whether or not the kit can be bought |
The date is the last part needed, not the first to land. For each arrival, the kit shows the latest date among the components that are still waiting for one. A component covered by stock contributes no date, because it cannot delay anything.
Rule 6 makes the two quantities overlap. They describe the same stock from two points in time and must never be added — see the overlap warning and the row in Known limitations. On 2026-09-24, 53 live kits publish the same number twice, totalling 213 units that would be double-counted by anyone summing them.
The two quantities overlap. Never add them.
On kit
390191Daphne 4 Seater Modular Right Corner Sofa the first arrival says 1 and the second says 1. That is one sofa in total, not two. The second figure is the same sofa, re-dated: the single right corner from the first arrival, still unsold, paired with arms from the second.Read it as "one sofa, and if it has not sold by 7 December there is still one" — never as "one now and one more in December". A kit whose scarcest component gets nothing in the second arrival will repeat its first-arrival quantity, by design.
This was chosen with the trade-off understood. The alternatives — showing only what is physically in the second shipment, or showing how many extra kits it unlocks — were both put to the sales team on 2026-09-24 and declined, because either would go silent on a kit whose spare parts are already on the shelf and sellable. The six kits that demonstrate it are in the developer reading, under Worked examples.
What is published. Four fields on the kit record, and the same four as Shopify metafields:
custitemcust_receive_date, custitem_next_qty_on_order_available, custitem_po2_receive_date,
custitem_po2_qty_on_order_available.
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 IDKit Item | Which kit this row belongs to. | Rows are grouped by it. Every member of a kit shares one value, and one output record is produced per group. | confirmed |
| needs confirmingInventory Item | Which component of the kit this row describes. | None. Returned and never read — the members are distinguished only by their values, never by identity. | needs confirming |
| needs confirmingInventory Item | The component's name. | None. Returned and never read, so nothing records which member set a kit's promise. | needs confirming |
| Ships InInventory Item | The component's own dispatch estimate, as flow 2 left it. | The kit takes the member band with the longest time. Any member saying "please contact", or saying nothing, makes the whole kit "please contact". | confirmed |
| In Stock Lead Time MessageInventory Item | The component's in-stock message, as flow 2 left it. | The kit takes the member message with the longest time, under the same "please contact" rule. | confirmed |
| On Order Lead Time MessageInventory Item | The component's on-order message, as flow 2 left it. | Handled differently from the others — the date is read back out of the sentence and the latest one wins. | confirmed |
| Out Of Stock Lead Time MessageInventory Item | The component's out-of-stock message, as flow 2 left it. | The kit takes the member message with the longest time. | confirmed |
| Next Available Receive DateInventory Item | When the component's next stock is expected. | The kit's arrival date is the latest of these, among only those members whose on-order quantity equals the kit's chosen on-order quantity. | confirmed |
| Shopify Enable Out Of Stock SellingInventory Item | Whether the component may be back-ordered. | Read twice. It decides whether an arrival date is shown at all, and since 2026-08-28 it is also gate 1 of the kit's own backorder decision — every component's box must be ticked. | confirmed |
| Qty Available (Warehouse)Inventory Item | Capture the available quantity at this location, refreshed on a schedule rather than in real time. | The component's on-hand stock, added to warehouse2 and then reduced across members to the kit's figure. | confirmed |
| needs confirmingInventory Item | needs confirming | Added into the component's on-hand figure before any roll-up. Its lowest value across components also overrides the backorder decision outright — second-warehouse stock always allows backorder. | needs confirming |
| needs confirmingInventory Item | needs confirming | The component's on-order stock, reduced across members to the kit's figure, and used to pick which members' arrival dates count. | needs confirming |
| Supplier Quantity On HandInventory Item | The supplier's own stock on hand. Used for drop-ship items and local items from key suppliers. | Supplier stock for the component. Used as a fallback source of the kit's figures, added to the quantity published to Shopify, and — as the lowest across components — read by the backorder decision. | confirmed |
| Supplier Quantity On OrderInventory Item | The supplier's own stock on order. Used for local items from key suppliers. | Supplier stock on order for the component. Same three uses. | confirmed |
| Qty Available (Syd)Inventory Item | Stock on hand at the Sydney showroom. Refreshed on a schedule, so it is not real time. | Sydney showroom stock for the component. The kit gets the lowest across members. | confirmed |
| Qty Available (Mel)Inventory Item | Stock on hand at the Melbourne showroom. Refreshed on a schedule, so it is not real time. | Melbourne showroom stock. Same roll-up. | confirmed |
| Qty Available (Bris)Inventory Item | Stock on hand at the Brisbane showroom. Refreshed on a schedule, so it is not real time. | Brisbane showroom stock. Same roll-up. | confirmed |
| Qty Available (Gold Coast)Inventory Item | Stock on hand at the Gold Coast showroom. Refreshed on a schedule, so it is not real time. | The kit gets the lowest across members, written to custitem_qty_available_gc. Renamed from qtyAvailable_mia on 2026-08-18 to match flow 2 and the saved search; the import followed on 2026-08-28, resolving defect LT3-D5. | confirmed |
| Qty Available (Bonded Warehouse)Inventory Item | The component's stock sitting in the bonded warehouse in Vietnam. | Pays down that component's own Sydney backorder first. Whatever survives is added to its on-order figure. It never produces a Sydney arrival date. | confirmed |
| needs confirmingInventory Item | The component's stock on order into the bonded warehouse in Vietnam. | Pays down the component's backorder after bonded on-hand. The remainder counts as on order. | needs confirming |
| Next Available Receive Date (Bonded WH)Inventory Item | When the component's next stock is expected to land in Vietnam. | The raw Vietnam date. Deliberately never adjusted for transit — the kit publishes it as-is rather than guessing a Sydney date. | confirmed |
| Next Available Receive Date (Bonded WH)Kit Item | The Vietnam arrival date the kit currently carries. | Compared against the newly rolled-up Vietnam date. Since nothing ever writes that value, the comparison can never match — see defect LT3-D7. | confirmed |
| Brand - Life InteriorsKit Item | Which brand Life Interiors sells this product under. | Two brands are special-cased by name — Ellison Studios kits take a different route through the quantity roll-up, and McMullin & Co. kits are denied backorder when their slowest component's supplier date is more than 70 days out. | confirmed |
| Supply TypeKit Item | Which supply arrangement the product is on. Buying maintains the list of valid types. This is the **kit's** own value, not the component's — confirmed on kit 87401 *Norah King Bed*, whose components are Back Order Only while every row reports the kit's End Of Line. | Read since 2026-08-28 as gate 2 of the kit's backorder decision. It still plays no part in the lead time itself, unlike in flow 2 where it selects the whole rung. | confirmed |
| Supplier Next Available Receive DateInventory Item | When the supplier expects their next stock. Only meaningful when the supplier has quantity on order. | Read since 2026-08-28 for the McMullin & Co. backorder test only — the latest date across components. It still never competes with the Life date, unlike in flow 2. | confirmed |
| Default Made To Order 1 Lead TimeInventory Item | The supplier's standard made-to-order wait, in weeks. | None. Returned and never read. | confirmed |
| Default Made To Order 2 Lead TimeInventory Item | The supplier's second made-to-order wait, in weeks. | None. Returned and never read. | confirmed |
| ImportedKit Item | Whether the item comes from an overseas supplier and is stocked and shipped from our own warehouse. | None. Returned and never read. | confirmed |
| Qty Available To Sell On WebsiteKit Item | The website-available quantity the item currently carries. | One of the fifteen comparisons deciding whether the kit is written. Arrives as text, and since 2026-08-28 is converted to a number before comparing — resolved defect LT3-D1. | confirmed |
| Qty On Order Available To Sell On WebsiteKit Item | The website on-order quantity the item currently carries. | Same as above — text, converted before comparing since 2026-08-28. Resolved defect LT3-D1. | confirmed |
| Ships InKit Item | The dispatch estimate the item currently carries. | One of the fifteen comparisons deciding whether the kit is written. | confirmed |
| In Stock Lead Time MessageKit Item | The in-stock message the kit currently carries. | Compared against the rolled-up message. Note the capital I, which differs from the equivalent field in flow 2. | confirmed |
| On Order Lead Time MessageKit Item | The on-order message the item currently carries. | Compared against the rolled-up message. | confirmed |
| Out Of Stock Lead Time MessageKit Item | The out-of-stock message the item currently carries. | Compared against the rolled-up message. | confirmed |
| Next Available Receive DateKit Item | The arrival date the item currently carries. | Compared against the rolled-up date. | confirmed |
| Shopify Enable Out Of Stock SellingKit Item | Whether the storefront currently lets this be bought out of stock. | Compared against the newly derived kit backorder decision, and written back when they disagree. Read since 2026-08-28; before that it was returned and discarded. | confirmed |
| needs confirmingKit Item | The kit's id on the Shopify storefront. | Must be greater than zero or the kit never reaches Shopify. | confirmed |
| needs confirmingKit Item | The kit variant's id on the Shopify storefront. | Required for the variant route. | confirmed |
| needs confirmingKit Item | Whether the kit is published to Shopify as a product or a variant. | Chooses the Shopify route. Unlike search 6221 in flow 2, this search does return it. | confirmed |
| needs confirmingKit Item | The Vietnam arrival date rolled up for the whole kit. | Calculated, and included in the change detection, but the import has no mapping for it — so it is never written anywhere. The destination field exists on the kit record (custitem_receive_date_bonded_wh, confirmed 2026-08-28); only the mapping row is missing. See defect LT3-D7. | confirmed |
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 |
|---|---|---|---|
| Ships InKit Item | The dispatch estimate. If the item is in stock it dispatches in a couple of days; otherwise this shows the order's estimated arrival. | Taken from the slowest member. | confirmed |
| In Stock Lead Time MessageKit Item | The in-stock lead time across our warehouses and the supplier's. Falls back to the out-of-stock wording when there is nothing in stock. | Published to Shopify. Taken from the slowest member. | confirmed |
| On Order Lead Time MessageKit Item | The on-order lead time across our warehouses and the supplier's. Falls back to the out-of-stock wording when there is nothing on order. | Published to Shopify. Carries the latest arrival date across members. | confirmed |
| Out Of Stock Lead Time MessageKit Item | The out-of-stock lead time across our warehouses and the supplier's. | Published to Shopify. Taken from the slowest member. | confirmed |
| Next Available Receive DateKit Item | When the kit's next stock is expected. The same field flow 1 maintains on ordinary items. | The latest member arrival date among the members matching the kit's on-order quantity. Blank when the kit has nothing on order. | confirmed |
| Qty Available To Sell On WebsiteKit Item | Quantity available to sell, from our warehouses plus the supplier's stock on hand. This is what Shopify shows as available. | Kit on-hand plus the lowest supplier stock across members. Published to Shopify. | confirmed |
| Qty On Order Available To Sell On WebsiteKit Item | Quantity on order available to sell, from our warehouses plus the supplier's. This is what syncs to Shopify as on order. | Kit on-order plus the lowest supplier on-order across members. Published to Shopify. | confirmed |
| Qty Available (Warehouse)Kit Item | Capture the available quantity at this location, refreshed on a schedule rather than in real time. | Taken from the **first member in the group**, not the lowest across members, unlike every other quantity here — see defect LT3-D3. | confirmed |
| Qty Available (Syd)Kit Item | Stock on hand at the Sydney showroom. Refreshed on a schedule, so it is not real time. | Lowest Sydney showroom stock across members. | confirmed |
| Qty Available (Mel)Kit Item | Stock on hand at the Melbourne showroom. Refreshed on a schedule, so it is not real time. | Lowest Melbourne showroom stock across members. | confirmed |
| Qty Available (Bris)Kit Item | Stock on hand at the Brisbane showroom. Refreshed on a schedule, so it is not real time. | Lowest Brisbane showroom stock across members. | confirmed |
| Qty Available (Gold Coast)Kit Item | Stock on hand at the Gold Coast showroom. Refreshed on a schedule, so it is not real time. | Lowest Gold Coast showroom stock across members. The import was corrected to this field on 2026-08-28 — until then it mapped the retired new_qtyAvailable_mia onto custitem_qty_available_mia, which does not exist in NetSuite. Resolved defect LT3-D5. | confirmed |
| Shopify Enable Out Of Stock SellingKit Item | Whether the storefront lets a customer buy this kit when it is out of stock. | The kit's own backorder decision, written by this flow since 2026-08-28. It was previously maintained by a separate flow, now disabled. | confirmed |
Inputs
What it reads, and where from.
One NetSuite export, saved search 6188 on the item record, returning one row per kit
member. Rows are grouped by kit and reduced to one output record per kit. Every field is in the
field registry above; four of them are returned and never read — three fewer than before
2026-08-28, when LI-BL-INV-013 started reading the kit's supply type, the supplier's arrival
date and the kit's current backorder setting.
Confirmed live on 2026-08-17: kit 79187 Amelia Queen Bed (Oak, Light Grey) returns three
rows — headboard 79088, footboard 79090, slats 79092. The slats say "Ships in 2 - 3 days";
the other two say "Please contact showroom for lead time", so the kit says "please contact". That
is rule LI-BL-INV-007 case 2 working as intended.
Same caveat as flow 2. Reading search 6188 through a NetSuite API returns internal ids for
supplyType,brandandcurrent_shipsIn. Celigo receives the display text. Do not conclude from an API sample that text comparisons are broken.
Processing — LI-BL-INV-007 and LI-BL-INV-010
What it does with that, step by step.
Hand-written and language-neutral per CONVENTIONS §3.
when flow 2 finishes (six times a day):
export rows from saved search 6188 -- one row per kit member
group the rows by kit
for each kit:
remember each member's backorder before it is clamped away
tidy every quantity: text to number, negatives to zero, blanks to zero
fold each member's second warehouse into its first
for each member, net its bonded stock: -- LI-BL-INV-012
pay its own backorder down with bonded on hand, then bonded on order
whatever survives is added to that member's on-order figure
its Sydney date comes only from its own main-warehouse order;
bonded never contributes one
the raw Vietnam date is carried separately, untouched
decide which quantity rule applies:
some members have stock but nothing on order,
and others have nothing but stock on order,
and no member is empty on both -> mixed case
otherwise -> plain case
mixed case:
kit available = zero
kit on order = the lowest of those positive figures
arrival window = the latest member date, ignoring any unknown promises
plain case (brand Ellison Studios takes a longer route):
kit available = the lowest across members
kit on order = the lowest across members
arrival window = the latest member date, unless any promise is unknown
for each of the three customer messages:
any member's message says "please contact" -> the kit says that
any member has no message -> the kit says "please contact"
otherwise -> read the wait out of each
message and take the longest
kit arrival date:
kit has nothing on order -> no date
otherwise -> the latest date among the
members whose on-order figure
equals the kit's
showroom stock per city = the lowest across members
decide whether to show a date at all: -- LI-BL-INV-012
kit has sellable stock, or every member allows backorder -> show
otherwise -> clear both dates and say "please contact showroom"
decide whether the kit can be bought out of stock: -- LI-BL-INV-013
any member does not allow it -> no
the kit's scarcest second-warehouse stock is positive -> yes
otherwise, apply the kit's own supply-type rules to the kit's
rolled-up quantities, and to the latest supplier date across members
compare fifteen values against what the kit already carries
any differs -> mark for update
none differs -> skip
note: six of the fifteen compare a member's own quantity against the
kit's rolled-up figure, so they differ whenever the members do
-- LT3-D8
update the kit item, then publish to Shopify by the same routes as flow 2
Decision tree — one kit, from components to published values
The same logic as a path through the decisions, in the order they run.
Read top to bottom. Every branch is a rule in this entry. Nothing here is a shortcut: this is the order the script actually runs in, and the order matters — step 3 must happen before step 4, and step 4 before everything below it.
FOR EACH KIT, gather its component rows from search 6188
│
├─ 1. Stash backorders LI-BL-INV-012
│ a negative on-order is uncovered demand. Capture it
│ BEFORE the next step destroys it
│
├─ 2. Cast and clamp
│ every quantity to a number; negatives become 0
│
├─ 3. Fold WH2 into the warehouse figure
│ stock = qtyAvailable_warehouse + qtyAvailable_warehouse2
│ (reading the first column alone understates 13 kits)
│
├─ 4. Net bonded stock, PER COMPONENT LI-BL-INV-012
│ bonded on hand covers this component's backorder first,
│ then bonded on order. Spare folds into on-order.
│ MUST stay in component units - a backorder on a part is
│ covered by that part, one for one
│
├─ 5. Rescale to KIT units LI-BL-INV-010 case 0
│ every quantity ÷ memberQuantity, rounded DOWN
│ MUST come after step 4 and before everything below
│
├─ 6. Is the kit split - some parts have stock and no order,
│ │ others have order and no stock?
│ ├─ YES → available = 0, on-order = lowest of the positives
│ │ "no complete kit today, but one is coming"
│ └─ NO → is the brand Ellison Studios?
│ ├─ YES → longer route: our own stock if every part
│ │ has some, else the supplier's, else the
│ │ plain lowest LI-BL-INV-010 case 4
│ └─ NO → available = lowest across parts
│ on-order = lowest across parts LI-BL-INV-010 case 1
│
├─ 7. Arrivals LI-BL-INV-015
│ │
│ ├─ per component, capacity for the 1st arrival:
│ │ has a 1st arrival? → that figure
│ │ else has stock? → its stock
│ │ else → 0
│ │
│ ├─ per component, capacity for the 2nd arrival:
│ │ has a 2nd arrival? → that figure
│ │ else has a 1st? → its 1st arrival ← the overlap
│ │ else has stock? → its stock
│ │ else → 0
│ │
│ ├─ does ANY component have a real arrival in that slot?
│ │ ├─ NO → slot is BLANK, date blank
│ │ └─ YES → quantity = lowest capacity across parts
│ │ is it 0? → BLANK (a part is neither here nor coming)
│ │
│ └─ date = LATEST date among the parts still WAITING
│ for that arrival. A part covered by stock sets no date
│
├─ 8. The three sentences LI-BL-INV-007
│ any part unknown → whole kit says "please contact showroom"
│ otherwise → the slowest part's sentence wins
│
├─ 9. Ships-in LT3-D10
│ strip the trailing full stop - custitem_ships_in is a LIST
│ field and no list entry ends in one
│
├─ 10. Arrival-date gate LI-BL-INV-012
│ can the kit be bought at all - stock, or backorderable?
│ ├─ NO → blank every date AND every arrival quantity
│ └─ YES → keep them
│ ⚠ LT3-D16: the stock test reads the figure case 2 forces to
│ zero, so a SPLIT kit is refused a date it could honour.
│ 4 kits on 2026-09-29. V3.6 adds a third condition -
│ "the kit is buildable from the arrival" - deployed
│ 2026-09-29 02:04, not yet run
│
├─ 11. Backorder decision, two gates LI-BL-INV-013
│ every component allows it AND the kit's own supply
│ type allows it against the kit's rolled-up figures
│
└─ 12. Write
NetSuite: 17 mapped fields, no filter - every kit, every run
Shopify : only if requiresUpdate is true ← LT3-D12
Outputs & side effects
What it writes, and who reads it afterwards.
| Output | Written to | Downstream consumer |
|---|---|---|
| Dispatch band, three messages, arrival date, seven quantities, backorder setting | NetSuite kititem, matched on internal id |
Shopify push |
Nine metafields in namespace custom |
Shopify product or variant | The customer, on the kit's page |
The backorder setting is new on 2026-08-28 (LI-BL-INV-013) and is the thirteenth mapping row on
the import. The Vietnam arrival date is still calculated and still not mapped — LT3-D7.
What the two Shopify imports send, against inventory items. Both were widened to nine metafields on 2026-09-24, ahead of the script that supplies the values, and the gap was measured on 2026-09-23:
| Inventory items | Kits, before 2026-09-24 | Kits, now | |
|---|---|---|---|
| Metafields sent | 9 | 4 | 9 |
The three sentences, quantity_on_order |
✅ | ✅ | ✅ |
qty_available_wh |
✅ | ❌ | ✅ |
po1_receive_date |
✅ | ❌ | ✅ |
po2_receive_date |
✅ | ❌ | ⚠️ guarded, so it is skipped — the script emits nothing for it |
po1_qty_on_order_available, po2_qty_on_order_available |
✅ | ❌ | ⚠️ unguarded — see LT3-D9 |
Three of the nine read fields the deployed script does not produce. Two of those three are
unguarded, which is LT3-D9.
Worked examples
Real records carried end to end, so the logic can be checked against something that happened.
Walked through the documented roll-up. LI-BL-INV-007 and LI-BL-INV-010 are rules about
minimums and maximums, so the examples are stated as the rules state them, not lifted from a
named record.
Example 1 — the ordinary case: a bed in three boxes.
| Step | Value | Why |
|---|---|---|
| Members re-read | Headboard, footboard, slats | Members are read fresh every run |
| Slowest member | The footboard, on order | LI-BL-INV-007 — a kit is as slow as its slowest member |
| Scarcest member | Whichever has the fewest sellable units | LI-BL-INV-010 — a kit is as scarce as its scarcest member |
| Written | One promise and one quantity on the kit, pushed to Shopify | The customer needs one date, not three |
Example 2 — the case that is not obvious: three headboards, no footboards.
| Step | Value | Why |
|---|---|---|
| Input | Headboard qty 3, footboard qty 0 | |
| Decision | Available quantity = 0 | The minimum across members, not the first member's figure |
| Written | The kit reads as unavailable | Before the 2026-08-18 fix this reported 3 — resolved defect LT3-D3 |
Example 3 — bonded stock on a component, and where it disappears. Traced through
LI-BL-INV-012 and defect LT3-D7.
| Step | Value | Why |
|---|---|---|
| Netting | Each component's bonded stock is netted against its own backorder | Never rolled up and guessed into a kit-level Sydney date |
| Calculated | A Vietnam arrival date for the kit | LI-BL-INV-012 |
| Compared | Against the kit's stored bonded date, which is always empty | The import has no mapping for the field |
| Written | ⚠️ Nothing. The date is never saved, and the mismatch marks the kit changed on every run | LT3-D7, alongside LT3-D8 |
Example 4 — most kits, every run. The half-fixed change detection, traced through LT3-D1
(resolved) and LT3-D8 (open).
| Step | Value | Why |
|---|---|---|
| Was | current_qtyAvailable arrived as the text "0" and was compared strictly to the number 0 |
Confirmed against the live search on 2026-08-21 |
| Fixed | V3.2 converts both to numbers before comparing | LT3-D1, resolved 2026-08-28 |
| Still | Six other comparisons test a component's own quantity against the kit's roll-up | LT3-D8 — a kit with 3 headboards and 0 footboards rolls up to 0, which matches neither component |
| Written | Any kit whose components hold uneven stock is still rewritten and re-pushed on every run, six times a day | The import's requiresUpdate filter still filters very little |
Example 5 — a kit refused backorder that its components would have allowed. Traced through
LI-BL-INV-013. Kit 87401 Norah King Bed (Oak, Light Grey) is the shape this rule exists for:
its components are on a Back Order Only supply type while the kit itself is End Of Line.
| Step | Value | Why |
|---|---|---|
| Gate 1 | Every component's own backorder setting allows it | Flow 2 already applied each component's own rules |
| Gate 2 | The kit's supply type is read for the first time — End Of Line | Kits never pass through flow 2, so nothing had read it before |
| Test | End Of Line, nothing on order, no supplier stock | LI-BL-INV-008 rule 3, read against the kit's rolled-up figures |
| Written | ✅ The checkbox is turned off, though gate 1 said yes | Gate 2 is the whole reason the rule is not just "ask the components" |
| Not affected | The kit's arrival date | LI-BL-INV-012 keeps the looser gate-1 answer on purpose |
Worked example — kit 104468, the four arrival values
Kit 104468 Georgia Fabric King Single Bed (Light Grey), members read live 2026-09-23, one of
each per kit. This is the example the four arrival values were confirmed against.
| Member | On hand | 1st arrival | Qty | 2nd arrival | Qty |
|---|---|---|---|---|---|
| Headboard | 0 | 12/10 | 3 | 19/10 | 4 |
| Footboard | 0 | 12/10 | 5 | 19/10 | 4 |
| Slats | 29 | 25/9 | 5 | 12/10 | 5 |
| Kit field | Value | Working |
|---|---|---|
| 1st arrival date | 12/10/2026 | Latest member first arrival — max(12/10, 12/10, 25/9) |
| 1st arrival qty | 3 | min(3, 5, 5) ÷ 1 — the headboard is the constraint. The slats' 29 on hand do not raise it |
| 2nd arrival date | 19/10/2026 | The next date on which the buildable count rises |
| 2nd arrival qty | 4 | Buildable goes 3 → 7, so this arrival adds 4. Not 7 |
Read against the kit's other fields: qty_available_wh 0 and qty_on_order 7 are both the
scarcest member.
Worked example — every published field, one kit
Kit 390191 Daphne 4 Seater Modular Right Corner Sofa (Pasha Dune Boucle), read live
2026-09-24. Four components, one of each per sofa, none used more than once — so step 5 is a no-op
here and every figure below is already in kit units.
| Component | Stock | 1st arrival | Date | 2nd arrival | Date |
|---|---|---|---|---|---|
| Right Arm Modular | 0 | 4 | 30/11/2026 | 7 | 7/12/2026 |
| Left Arm Modular | 1 | 2 | 30/10/2026 | 3 | 30/11/2026 |
| Armless Modular | 0 | 1 | 30/10/2026 | 2 | 15/11/2026 |
| Right Corner Modular | 0 | 1 | 5/10/2026 | none | — |
| Published field | Value | How it got there | Rule |
|---|---|---|---|
custitem_qty_available_wh |
0 | No component has stock except one left arm; the lowest is 0 | LI-BL-INV-010 case 1 |
custitem_qty_on_order |
1 | Lowest on-order across parts | LI-BL-INV-010 case 1 |
custitemcust_receive_date |
30/11/2026 | Latest date among parts still waiting — the right arms. Not 5/10, which is only when the first box lands | LI-BL-INV-015 |
custitem_next_qty_on_order_available |
1 | capacities 4, 2, 1, 1 → min = 1 |
LI-BL-INV-015 rules 2–4 |
custitem_po2_receive_date |
7/12/2026 | Latest among the three parts that have a 2nd arrival | LI-BL-INV-015 |
custitem_po2_qty_on_order_available |
1 | The corner has no 2nd arrival, so it falls back to its 1st of 1. capacities 7, 3, 2, 1 → min = 1. The same sofa, re-dated |
LI-BL-INV-015 rule 6 |
custitem_ships_in |
list value, no full stop | Longest wait across parts | LI-BL-INV-007, LT3-D10 |
custitem_ships_in_celigo |
slowest part's in-stock sentence | LI-BL-INV-007 |
|
custitem_next_receive_date_celigo |
"New stock arrives in our warehouse from 30/11/2026 - 07/12/2026." | The arrival date plus a one-week window. The window end is always date + 7 and never refers to the second arrival | LI-BL-INV-007 |
custitem_out_of_stock_message |
slowest part's out-of-stock sentence | LI-BL-INV-007 |
|
custitem_celigo_shopify_enable_out_sto |
true | Every part allows backorder and the kit's supply type is Back Order Only | LI-BL-INV-013 |
custitem_receive_date_bonded_wh |
blank | No component holds bonded stock | LI-BL-INV-012 |
Read the two arrival quantities together: one sofa, not two. See the overlap warning.
Worked example per rule — six live kits
All read 2026-09-24, all reconciled against what NetSuite holds — 24 of 24 fields exact.
| Kit | What it demonstrates | 1st arrival | 2nd arrival |
|---|---|---|---|
390191 Daphne 4 Seater Modular Right Corner Sofa |
Rule 6 — the overlap. Corner has no 2nd arrival | 1 · 30/11/2026 | 1 · 7/12/2026 |
396379 Noir Oval Dining Table (280cm, Walnut) |
Rule 6 at scale. 19 bases arrive first, 2 tops; the base then falls back | 2 · 11/1/2027 | 19 · 11/1/2027 |
341585 Bowie Textured Velvet Sofa (Terracotta, 3 x 2) |
Rule 1 — armless used twice: 6 → 3 and 16 → 8 | 1 · 25/11/2026 | 4 · 4/1/2027 |
88217 Georgia Fabric King Bed (Cream) |
Rule 3 — footboard and headboard have no arrival but hold 12 and 13; they do not block and set no date | 10 · 25/9/2026 | 7 · 12/10/2026 |
392361 Amalfi Boucle King Bed (Oak, Camel Mixed Boucle) |
Rule 2 — slats cap the first at 9, the bed halves cap the second at 15 | 9 · 19/10/2026 | 15 · 19/11/2026 |
179873 Allocco Queen Bed (White Boucle) |
Rule 6 again, larger. 15 then 15 is fifteen beds, not thirty | 15 · 28/12/2026 | 15 · 28/12/2026 |
Rule 4 and 5, where the answer is blank:
| Kit | Components | Published |
|---|---|---|
79187 Amelia Queen Bed (Oak, Light Grey) |
Slats hold 6; headboard and footboard have neither stock nor arrival | blank — rule 5, nothing is inbound |
88220 Georgia Fabric Queen Bed (Light Grey) |
Slats arrive 1; headboard holds 1; footboard has 0 and none coming | blank — rule 4. 213 live kits are in this state |
Rule 1, worked in full — 341585 Bowie Textured Velvet Sofa (Terracotta, 3 x 2):
| Component | Per sofa | 1st arrival raw | ÷ per sofa | 2nd arrival raw | ÷ per sofa |
|---|---|---|---|---|---|
| Left Arm | 1 | 1 | 1 | 14 | 14 |
| Right Arm | 1 | 3 | 3 | 12 | 12 |
| Armless | 2 | 6 | 3 | 16 | 8 |
| Corner | 1 | 1 | 1 | 4 | 4 |
1st = min(1, 3, 3, 1) = 1. 2nd = min(14, 12, 8, 4) = 4. Without the division the second
would read 6 and 16, overstating by a factor of two.
Worked example — LT3-D16, the gate refusing a date it could honour
Kit 396981 Noir Oval Dining Table (220cm, Black Oak), read live from production 2026-09-29.
Two components, one of each per table.
| Component | Available | On order | Arrives | 1st arrival qty | Backorder allowed |
|---|---|---|---|---|---|
Top (136898) |
3 | 0 | — | 0 | No |
Base (136901) |
0 | 3 | 07/12/2026 | 3 | Yes |
The Base's own record carries the date and the sentence "New stock arrives in our warehouse from 07/12/2026 - 14/12/2026."
What the kit publishes today:
| Field | Value | Gated? |
|---|---|---|
custitem_qty_on_order |
3 | no — published |
custitem_ships_in |
"Ships in 10 - 12 weeks" | no — published |
custitem_qty_available_wh |
0 | no |
custitemcust_receive_date |
blank | gated |
custitem_next_qty_on_order_available |
blank | gated |
custitem_next_receive_date_celigo |
"Please contact showroom for lead time." | gated |
Three statements from one run that cannot all be true: three are on order, they ship in 10–12 weeks, and nobody can say when.
The trace:
LI-BL-INV-010 case 2 fires Top has stock with nothing on order
Base has nothing with stock coming
-> available FORCED to 0, on-order = 3 correct
LI-BL-INV-015 1st arrival = min(3 base, 3 top stock) = 3
date = 07/12/2026 correct
LI-BL-INV-012 gate showEta = qtyAvailable_allWarehouses > 0
|| every component allows backorder
= 0 > 0 <- case 2 set this
|| Top is No
= false
-> date, both arrival quantities and the
on-order sentence all blanked WRONG
Why the gate's premise fails here. It exists to stop advertising stock already committed to the
order queue. Production shows quantitycommitted 0 and quantitybackordered 0 on both
components — the three inbound bases are not spoken for. When they land on 7 December the kit becomes
buildable three times over.
What V3.6 changes, replayed against the deployed V3.5 over the live export 2026-09-29:
| Kit | 1st arrival, before → after | 2nd arrival |
|---|---|---|
396981 Noir Oval Dining Table (220cm, Black Oak) |
blank → 3 @ 07/12/2026 | — |
88604 Austen Double Bed (Oak, Light Grey) |
blank → 1 @ 12/10/2026 | blank → 1 @ 19/10/2026 |
269851 Noir Oval Dining Table (Black Oak, Marble, 220cm) |
blank → 1 @ 06/11/2026 | — |
422199 Camille Marble Console Table (Burgundy, Rosso Marble) |
blank → 10 @ 29/10/2026 | — |
Quantities, the backorder checkbox, ships-in, the in-stock and out-of-stock sentences, the bonded
date and all four showroom figures are unchanged on all 1,745 kits, and no kit loses a date or
an arrival quantity — the fix adds a third || condition, so it can only move kits onto the
"show it" side.
A narrower alternative was tested and rejected. Letting case 2 itself satisfy the gate missed
422199, where both components have 10 arriving 29/10/2026 and case 2 does not fire; and it wrongly
published a supplier sentence on 264782 Double Extendable Dining Table — "arrives in our
partners warehouse from 25/01/2027" — while leaving the date field blank.
One loose end it exposes rather than causes. On 422199 the kit gains a date and a quantity but
its on-order sentence still reads "Please contact showroom for lead time", because a component's
own sentence says that while 10 units arrive on 29/10/2026. That is a member-level gap in flow 2, not
a kit rule. Not tracked here yet.
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 |
|---|---|---|---|---|---|
LT3-TC-T1 |
needs confirming | A kit whose members have different lead times | The flow runs | The kit takes the slowest member's promise | LI-BL-INV-007 |
LT3-TC-T2 |
needs confirming | A kit with members at quantities 3, 0 and 5 | The flow runs | Available quantity is 0 | LI-BL-INV-010 |
LT3-TC-T3 |
needs confirming | A member with a negative quantity | The flow runs | Treated as zero, but its backorder is captured first so bonded can cover it | needs confirming |
LT3-TC-T4 |
needs confirming | A member with a blank quantity | The flow runs | Treated as zero — note this can silently make the kit look unavailable | needs confirming |
LT3-TC-T5 |
needs confirming | One member whose promise is unknown | The flow runs | The whole kit says "please contact showroom" | LI-BL-INV-007 |
LT3-TC-T6 |
needs confirming | One member whose promise is unknown, in the mixed quantity case | The flow runs | Today the unknown is ignored and a date is used anyway — inconsistent with T5, and unresolved | needs confirming |
LT3-TC-T7 |
needs confirming | A kit whose only inbound stock is bonded | The flow runs | A Vietnam date is calculated. Today it is never written — LT3-D7 |
LI-BL-INV-012LT3-D7 |
LT3-TC-T8 |
needs confirming | A kit where nothing at all has changed, and whose components hold equal stock | The flow runs twice | Skipped on the second run. Was rewritten before 2026-08-28 | needs confirmingLT3-D1 |
LT3-TC-T8a |
needs confirming | A kit where nothing has changed, but whose components hold uneven stock | The flow runs twice | Today: rewritten and re-pushed anyway (LT3-D8). Once fixed: skipped |
needs confirmingLT3-D8 |
LT3-TC-T9 |
needs confirming | A component updated by flow 2 five minutes ago | The storefront is read | Today: the kit is stale for up to twelve hours (LT3-D2) |
needs confirmingLT3-D2 |
LT3-TC-T10 |
needs confirming | Gold Coast stock changes on a member | The flow runs | The lowest figure across members is written to custitem_qty_available_gc |
needs confirmingLT3-D5 |
LT3-TC-T11 |
needs confirming | A kit's members are changed in NetSuite | The flow runs | The new membership is used — members are re-read every run | needs confirming |
LT3-TC-T12 |
needs confirming | A kit with no Shopify id | The flow runs | NetSuite updates; the kit is dropped before Shopify. Intended | needs confirming |
LT3-TC-T13 |
needs confirming | A kit showing "please contact showroom" | Someone asks which member caused it | Nothing records it — LT3-D6. Diagnosis is by hand |
needs confirmingLT3-D6 |
LT3-TC-T14 |
needs confirming | A kit whose components all allow backorder, on a kit supply type that does not | The flow runs | The checkbox is turned off — gate 2 | LI-BL-INV-013 |
LT3-TC-T15 |
needs confirming | A kit on a permissive supply type with one component that refuses backorder | The flow runs | The checkbox is turned off — gate 1 | LI-BL-INV-013 |
LT3-TC-T16 |
needs confirming | A kit whose scarcest component holds second-warehouse stock, on In-Store Only | The flow runs | Allowed — physical stock overrides the supply type | LI-BL-INV-013 |
LT3-TC-T17 |
needs confirming | A McMullin & Co. kit whose slowest component's supplier date is 200 days out | The flow runs | Not allowed. The latest component date is used, not the earliest | LI-BL-INV-013 |
LT3-TC-T18 |
needs confirming | A kit refused backorder by gate 2 that currently shows an arrival date | The flow runs | The date is unchanged — the arrival-date gate keeps the looser gate-1 answer | LI-BL-INV-012 LI-BL-INV-013 |
Derived from the rules and defects above. There is no automated test coverage for this flow. Where today's behaviour is a known defect, both today's and the intended result are given.
UAT
What a person checks, by hand, before it is trusted.
Signed off from the kit record and the storefront.
| # | Step | What to check | Signed off by | Date |
|---|---|---|---|---|
| U1 | Pick a kit and list its members in NetSuite | You can see each member's own lead time and quantity | ||
| U2 | Compare the kit's promise against its members | It matches the slowest member | ||
| U3 | Compare the kit's available quantity against its members | It matches the scarcest member | ||
| U4 | Open the kit on the storefront | The sentence matches the NetSuite kit record | ||
| U5 | Change one member's lead time and wait for the next flow 2 run, which starts flow 3 | The kit follows in the same chain | ||
| U6 | Look at a kit's change history over a day | ⚠️ If it was written on every run with nothing changing, that is LT3-D8 — check whether its components hold uneven stock |
||
| U7 | Check a kit with bonded stock on a member | ⚠️ Its bonded arrival date is blank on the record. That is LT3-D7 |
||
| U8 | Check the kit's backorder checkbox after the first run on or after 2026-08-28 | This flow now sets it. Confirm it matches both gates: every component allows it, and the kit's own supply type allows it | ||
| U9 | Pick a kit whose own supply type is In-Store Only or End Of Line | ⚠️ Its checkbox should now be off even if every component's is on. This is the behaviour that changes on the first V3.2 run | ||
| U10 | Confirm [PROD] Update Back Order Checkbox - Kit Items is disabled in Celigo | It must not run alongside this flow, or the two will fight over the checkbox |
Edge cases
The inputs that sit at the boundary, and whether each is handled.
| Case | Behaviour | Handled? |
|---|---|---|
| Kit is written on every run whether or not anything changed | Two comparisons tested text against a number. Fixed 2026-08-28 — but six others compare a member's quantity against the kit's roll-up, so most kits still qualify | ✅ fixed 2026-08-28 / ❌ LT3-D8 |
| Every component allows backorder, but the kit's own supply type does not | The kit's checkbox is turned off — gate 2 | ✅ intended, new 2026-08-28 |
| The kit's supply type allows backorder but one component does not | The kit's checkbox is turned off — gate 1 | ✅ intended, new 2026-08-28 |
| Kit's only inbound stock is bonded | No Sydney date is shown; the raw Vietnam date is calculated — but never written, see LT3-D7 | ❌ |
| Kit has no sellable stock and cannot be back-ordered | Both dates cleared, customer told to contact the showroom | ✅ intended |
| A component has no on-order message, in the mixed quantity case | Contributes no date. Before 2026-08-18 this threw and killed the whole page batch | ✅ fixed 2026-08-18 |
| Gold Coast stock changes on a kit | Calculated as the lowest across members and written to custitem_qty_available_gc |
✅ fixed 2026-08-28 |
| A member was updated by flow 2 | Flow 2 starts flow 3 on completion, so the kit follows in the same chain | ✅ fixed, verified 2026-09-21 |
| One member has an unknown promise | The whole kit says "please contact showroom" | ✅ intended |
| One member has an unknown promise, in the mixed quantity case | The unknown is ignored and a date is used anyway | ❓ inconsistent with the case above |
| A member has a negative quantity | Treated as zero, but its backorder is captured first so bonded can cover it | ✅ |
| A member quantity is blank | Treated as zero, which can silently make the kit appear unavailable | ⚠️ |
| Kit has nothing on order | No arrival date is written | ✅ |
| A kit has no Shopify id | Dropped before Shopify; NetSuite still updated | ✅ intended |
| Kit's members change in NetSuite | Picked up on the next run, because members are re-read every time | ✅ |
Failure modes
What breaks it, how that shows, and how to recover.
| Failure | Symptom | Detection | Recovery |
|---|---|---|---|
| A kit's promise disagrees with its components | Kit page and component pages show different waits | None automatic | Wait for the next flow 3 run, or run it by hand |
Constant rewrites (LT3-D8, LT3-D7) |
Most kits written on every run, six times a day; Shopify called for each one | Visible in kit change history and Celigo run volume, if anyone looks | Compare each value against what the kit stores, not against the roll-up; and map the bonded date |
The kit's backorder setting is wrong (LI-BL-INV-013) |
The storefront takes an order it cannot fill, or refuses one it could | None automatic. Compare the kit's checkbox against its components' and its own supply type | Correct the supply type or the component setting, then wait for the next run |
| A member's promise goes blank | The whole kit falls back to "please contact showroom" with no indication why | None automatic | Trace the members by hand — see LT3-D6 |
| Saved search 6188 edited or renamed | Kits silently stop updating | None automatic | Restore the search |
| Shopify write rejected | NetSuite and the storefront disagree | None — Shopify is never read back | Force a change so the kit requalifies |
How a failure is actually noticed today. As with flows 1 and 2, there is no automatic detection. The team raises a ticket, and the project owner reviews and applies a fix.
Known limitations
Scope that was deliberately chosen. A limitation is a decision.
Deliberate scope. The defect table above is what is wrong; this is what is simply how it works.
| Limitation | Why it is this way | What to do instead |
|---|---|---|
| A kit is as slow as its slowest member | The kit cannot ship until every part is there | Nothing — this is the whole point of the rule |
| A kit is as scarce as its scarcest member | Three headboards and no footboards is zero beds | Nothing |
| One unknown member makes the whole kit unknown | An honest "contact the showroom" beats a promise built on a gap | Fill the member's gap |
| Bonded stock is netted per component, never at kit level | Rolling it up would mean guessing a Sydney date for the kit | Nothing |
| It runs whenever flow 2 finishes | Flow 2 starts it on completion; it has no schedule of its own | Expect a kit to follow its components in the same chain |
| A kit can be refused backorder even when every component allows it | The kit is its own record with its own supply type, and nothing else applies it | Change the kit's supply type, not the components' |
| The backorder checkbox and the arrival-date gate can disagree | Deliberate: the gate keeps the looser component-only answer, so tightening the checkbox cannot remove a date a kit already showed | Nothing — read them as two separate questions |
| An arrival quantity counts complete kits, never boxes | A shipment of seven right arms and no corners builds nothing | Read the component rows if you need box counts |
floor, not round — spare parts are stranded |
Three of a part on a kit that needs two yields one kit and strands one part | Nothing. The stranded part is real and will be used by a later arrival |
| The arrival window in the sentence is always the date plus seven days | A fixed one-week spread, not a computed estimate. The window end never refers to the second arrival | Do not read the window end as a second date |
| A kit with no sellable stock and no backorder shows no arrival information at all | The arrival-date gate: stock already committed to the queue is not an offer | Correct for genuinely committed stock. Not correct when the kit is split — that is LT3-D16 |
| 213 live kits show a first arrival but no arrival quantity | Rule 4: a component has neither stock nor an arrival, so no complete kit can be built from it | Fill the component's gap, or accept the blank |
| A component that is not marked "Part Only" is skipped, and the kit inherits its stale values | Confirmed by the project owner 2026-09-30. custitem_part_only is the membership criterion for flow 2's export, not a description. A component that is neither Part Only nor a sellable product in its own right is read by nothing, so its lead-time fields freeze. The kit then rolls up frozen numbers without any error |
Treat the tick as a control, not a label. Worked example: 422097 Camille Marble Console Table (Top) held a 1st-PO quantity of 10 and an arrival of 29/10/2026 while its website on-order quantity stayed blank and all three sentences read "Please contact showroom for lead time", last written 2026-09-21. Ticking Part Only — with no script change — produced the correct quantity, all three sentences and backorder allowed on the next run, and kit 422199 went to backorder-allowed with it. Measured 2026-09-30: 503 components of 885 kits are unticked, of which 7 were visibly wrong; the rest are armed and break the moment a purchase order is raised against them |
| The published availability of a component can exceed what NetSuite actually holds | Not the Part Only gap — it occurs on both ticked and unticked components, and the cause is not established | Measured 2026-10-01: 140 of 2,443 kit components publish more availability than exists at any location, 1,025 phantom units in total. 128794 N701 Corner Seater Sofa (Dark Grey) publishes 9 against a real availability of 0. Do not size a kit decision from the published component figure — read InventoryItemLocations instead. Not yet raised as a defect |
| A kit's two arrival quantities overlap. They are not additive | Confirmed by the sales team on 2026-09-24. A component with nothing in the second arrival falls back to what it got in the first, on the basis that an unsold part is still on the shelf. So the second figure can be the same kit re-dated rather than an additional one | Never add the two. On kit 390191 Daphne 4 Seater Modular Right Corner Sofa, first arrival 1 and second arrival 1 means one sofa, not two. Read the second as "if it has not sold by then, there is still one". Do not quote a customer two sofas against the December date. Full reasoning at the overlap warning |
Known defects
Where it does something other than what was decided. A defect is a mistake.
| Ref | Status | Defect | Rule |
|---|---|---|---|
LT3-D1Resolved |
Resolved2026-08-28 | Resolved 2026-08-28. Two of the change-detection comparisons tested the kit's current available and on-order quantities, which arrive from search 6188 as text (confirmed live: current_qtyAvailable: "0"), against newly computed numbers under a strict comparison. They could never hold, so every kit qualified for update on every run. V3.2 converts both to numbers first, matching what flow 2 already did. The symptom is reduced, not gone — LT3-D8 and LT3-D7 each independently mark most kits as changed |
needs confirming |
LT3-D2Resolved |
Resolved2026-09-21 | Resolved, verified 2026-09-21. Flow 2 now starts flow 3 on completion, and flow 3 carries no schedule of its own — confirmed on the live flow configuration. A kit no longer lags the items inside it. When this was last checked the chain did not exist; when it was added is not recorded anywhere. The open question about flow 3's timezone falls away with it, since it no longer runs to a clock. Original description: ** Flow 3 is not chained to flow 2, so a kit's promise can lag its own components by up to twelve hours ** | needs confirming |
LT3-D3Resolved |
Resolved2026-08-18 | Resolved 2026-08-18. The kit's warehouse availability was copied from whichever member happened to be first in the group rather than the scarcest, so a kit with three headboards and no footboards reported three. It now takes the minimum like every other quantity | needs confirming |
LT3-D4Not a defect. Kept as a record of the correction |
Resolved | Withdrawn — this was wrong. The entry previously said kits never get a backorder decision. They do: a separate flow, [PROD] Update Back Order Checkbox - Kit Items (5faa31bea44bdf66ac8ae144, twice daily at 10:10 and 23:10 Sydney), maintained the checkbox on the kit record. This flow did not write it, which is what was observed, but the conclusion drawn from that was incorrect. Superseded 2026-08-28 — that separate flow is now disabled, and this flow owns the decision under LI-BL-INV-013 |
needs confirming |
LT3-D5Resolved |
Resolved2026-08-28 | Resolved 2026-08-28. The script was renamed on 2026-08-18 to compute qtyAvailable_gc, but the import kept mapping the retired new_qtyAvailable_mia onto custitem_qty_available_mia, a field that does not exist in NetSuite — so the figure was computed correctly and written nowhere. The import row now reads new_qtyAvailable_gc → custitem_qty_available_gc, confirmed present on the kit record. Both halves of the rename are in |
needs confirming |
LT3-D7Resolved |
Resolved2026-09-24 | Resolved 2026-09-24. The kit import gained the mapping row new_receiveDate_bonded → custitem_receive_date_bonded_wh, confirmed on the live import at 02:10. The calculated Vietnam date now reaches the kit record, and the comparison that could never match now can. Original description: The kit's Vietnam arrival date is calculated, drives updates, and is never saved. LI-BL-INV-012 produces new_receiveDate_bonded and the change-detection compares it against current_receiveDate_bonded. The import has no mapping for it, so it is never written to the kit record. The stored value therefore stays empty while the calculated one holds a date, the comparison can never match, and every kit with bonded stock is marked as changed on every run. Re-checked 2026-08-28: still open, and now one of the two reasons kits are rewritten regardless of change (LT3-D8 is the other). The destination field already exists — custitem_receive_date_bonded_wh, confirmed on the kit record — so this needs a mapping row and no script change |
needs confirming |
LT3-D8Most multi-component kits are still rewritten and re-pushed on every run — six times a day since the chain was added, not twice — so the import filter still filters very little |
Open | Change detection still fires on most kits, for a second reason. Raised 2026-08-28, on reading the deployed script. Six of the fifteen comparisons — warehouse on-hand, warehouse on-order, and the four showroom quantities — test each component's own figure against the kit's rolled-up figure, rather than against the value stored on the kit. Any kit whose components hold uneven stock therefore never matches, and qualifies as changed on every run. In the mixed quantity case (LI-BL-INV-010 case 2) the kit figure is forced to zero while components hold stock, so it always fires. This is pre-existing logic, untouched by V3.2; it was invisible while LT3-D1 pinned every kit to changed, and it is what remains now that LT3-D1 is fixed |
needs confirming |
LT3-D9Resolved |
Resolved2026-09-24 | Raised and resolved the same day, 2026-09-24. For roughly two hours the imports asked for values that did not exist. Both Shopify imports ask for three values the script does not produce. Raised 2026-09-24, on reading the live imports. Lead Time V2: Update Shopify Variant Metafields and ... Product Metafields were widened to nine metafields on 2026-09-24. Three of them read new_qtyOrder_po1, new_receiveDate_po2 and new_qtyOrder_po2, none of which the deployed script emits. po2_receive_date is wrapped in a conditional and is therefore skipped safely. po1_qty_on_order_available and po2_qty_on_order_available are not, so both render an empty string into a number_integer metafield on every kit. Shopify rejects an empty integer and reports it in userErrors while still returning HTTP 200, so Celigo records the run as successful — the same trap as LT2-D14 on inventory items. Whether the other seven metafields still land on a partial failure has not been verified. The imports cannot simply be guarded: the two objects sit last in the array with no trailing comma, so wrapping them leaves invalid JSON — the two objects must be removed until the script supplies the values. Closed by V3.4 at 02:08, which emits all three — the imports were correct, the script was behind them. Whether any kit push actually failed in the window between 00:53 and 02:08 was never established, and the flow's last run before V3.4 was 2026-09-23 22:50, so most likely none did |
needs confirming |
LT3-D10Resolved |
Resolved2026-09-24 | The ships-in value carries a full stop the list does not. Raised 2026-09-24 by replaying the live script and diffing against NetSuite. custitem_ships_in is a list field. All 23 CUSTOMLIST_SHIPS_IN entries are written without a trailing full stop — the fallback is id 22, "Please contact showroom for lead time". getMsgWithLongestTime returns the sentence form, which ends in one, so the value matches no list entry and the NetSuite import drops the write without raising a Celigo error. 50 kits hold a blank ships-in while the script computes a value, and because the stored value can never match, each is flagged as changed on every run — the same permanent-rewrite loop LT3-D7 had. The inventory script has always emitted the un-stopped form (// id = 22); kits never did. Only new_shipsIn is affected — the three message fields are free text, correctly keep their full stop, and 0 of 1,749 kits differ on them. Resolved — fixed in script content V3.5, deployed 2026-09-24 04:41 and verified against production 2026-09-29: kits holding a blank custitem_ships_in fell from 421 to 371, exactly the 50 this defect affected. The inventory script has always emitted the un-stopped form (// id = 22); kits never did. Only new_shipsIn is affected: the three message fields are free text, correctly keep their full stop, and 0 of 1,749 kits differ on them. Fixed in script content V3.5, deployed 2026-09-24 04:41 — not yet run, so not yet verified in data |
needs confirming |
LT3-D11Resolved |
Resolved2026-09-24 | The Ellison Studios branch counts the supplier pool twice. Raised 2026-09-24, same replay. When our own warehouse figures are empty the branch assigns qtyAvailable_allWarehouses / qtyOnOrder_allWarehouses from supplier_qtyAvailable / supplier_qtyOnOrder; the final two lines then add the supplier minimum again. The published figure is exactly twice the truth. Replayed over the live export: 117 of 256 Ellison kits affected, 1,199 units over-stated, every one a reduction once fixed and none increased. Worked example — kit 297076 Bell Floor Lamp (Chrome / Natural Rattan), two components at supplier 29/34 and 28/34: the branch takes min(29,28)=28 and min(34,34)=34, then adds 28 and 34 again, publishing 56/68 against a true 28/34. Also 397406 Float 4 Seat Sofa 136 → 68 on order and 372090 Alva Armchair 74 → 37. An earlier estimate of 58 kits / 569 units was wrong — it came from a hand-built model of the branch, not a replay. Fixed in V3.5, deployed 2026-09-24 04:41 — not yet run |
needs confirming |
LT3-D12The customer sees nothing while NetSuite says stock is coming. Recurs on every run |
Open | A kit's arrival values reach NetSuite but never Shopify, on 42 kits. Raised 2026-09-24, from the live flow configuration. The NetSuite import Lead Time V2: Import Kit Data had its filter emptied on 2026-09-24 (rules: []), so it writes every kit. The two Shopify branches on Lead times: Kits still require requiresUpdate == "true". requiresUpdate cannot see the three arrival fields, because search 6188 carries no read-back column for them — so a kit whose only change is an arrival value updates NetSuite and is skipped for Shopify. Measured 2026-09-24: of 375 kits with an arrival value, 333 reach Shopify and 42 do not. Worked example: kit 141511 Austen Double Bed (Oak, Cream) holds 5 arriving 12/10/2026 and 2 more on 19/10/2026 in NetSuite, and neither figure is on the storefront. Also 301580 Bowie Textured Velvet 2 Seat Sofa, 273950 Avery Arch Rattan Single Bed, 264661 Bok Extendable Dining Table. Adding the three read-back columns closes this and LT3-D13 together |
needs confirming |
LT3-D13NetSuite governance spent on writes that change nothing |
Open | Every kit is rewritten six times a day. Raised 2026-09-24. With the import filter emptied, all 1,749 kits are written on every run while only 802 are flagged as changed — 947 no-op updates per run, 5,682 a day. This was the safe direction for the arrival backfill and it makes LT3-D8 harmless in practice, but it is a temporary state, not a fix. Restoring the filter before the read-back columns exist would make LT3-D12 worse rather than better |
needs confirming |
LT3-D14Wrong stored data on records nobody is watching |
Open | 91 kit records hold an arrival quantity that nothing will ever correct. Raised 2026-09-24. Search 6188 returns 1,749 kits; NetSuite holds 4,485 kit records. The 2,736 outside the export are never touched by this flow, and 91 of them carry a value in custitem_next_qty_on_order_available left by something since retired. Blanks do clear correctly for kits inside the export — verified on 250 of 250 — so this is purely a scope gap, not a clearing failure. Whether any of the 91 are Shopify-linked is not established |
needs confirming |
LT3-D15Stage and arrival date can disagree on the same record |
Open | A kit's purchase-order stage can be a day behind its own arrival date. Raised 2026-09-24. custitem_po_stage on a kit is written only by Item Purchase Order Stage - Kit part 2/2, once a day at 05:05. Inventory items get theirs from flow 1 six times a day. So a kit can show an arrival date calculated at 16:05 today against a stage from 05:05 yesterday. This is the same class of problem LT3-D2 closed for lead times — the kit lagging its own components — still open for stage |
needs confirming |
LT3-D6Slow diagnosis, and it falls entirely on the person who notices |
Open | Nothing records which component set a kit's promise. The member id and name are returned and discarded, so when a kit shows "please contact showroom" there is no way to tell from the data which of its parts caused it. Diagnosing a wrong kit promise means re-deriving the roll-up by hand | needs confirming |
LT3-D16A kit advertises stock on order and a shipping band while refusing to say when, and tells the customer to phone instead |
Resolved2026-09-30 | A split kit is refused an arrival date it could honour. Raised 2026-09-29 by the project owner, from the kit record; confirmed against production the same day. The arrival-date gate asks "could a customer act on a date?" as qtyAvailable_allWarehouses > 0 || kitAllowBackOrder. But LI-BL-INV-010 case 2 forces that availability to 0 by design when a kit is split — some components hold stock with nothing on order, others hold nothing with stock coming. So for every case-2 kit the first test is false by construction and the gate collapses onto the backorder flag alone; one component with its checkbox off then suppresses the date, both arrival quantities and the on-order sentence. The gate's own stated rationale is that the inbound units are "already committed to existing orders" — checked against production and false here: on kit 396981 both components report quantitycommitted 0 and quantitybackordered 0. Measured 2026-09-29 over the live export: 4 kits are refused a date they could honour — 396981 Noir Oval Dining Table (220cm, Black Oak), 88604 Austen Double Bed (Oak, Light Grey), 269851 Noir Oval Dining Table (Black Oak, Marble, 220cm) and 422199 Camille Marble Console Table (Burgundy, Rosso Marble). Pre-existing since V3.0, and V3.4 widened it: the gate now blanks the two arrival quantities as well as the date. Fixed in V3.6, deployed 2026-09-29 02:04 and byte-verified against the live record — not yet run. Pre-run state confirmed the same day: all four kits still hold a blank arrival date, a blank arrival quantity and "Please contact showroom for lead time." Closed 2026-09-30, verified in production data. The flow has since run and kit 396981 now holds custitemcust_receive_date 2026-12-07, custitem_next_qty_on_order_available 3 and the sentence "New stock arrives in our warehouse from 07/12/2026 - 14/12/2026." The rules were brought level with the deployed gate the same day — LI-BL-INV-012 now states all three tests and LI-BL-INV-015 rule 7 carries the second condition. The kit remains unsellable on Shopify for a separate reason, raised as LT3-D17. |
LI-BL-INV-012 LI-BL-INV-015 |
LT3-D17A kit we hold the parts for cannot be bought at all, because a component sitting on stock is flagged no-backorder for having nothing on order |
Open | A component holding stock still vetoes the kit. Raised 2026-09-30 by the project owner from kit 396981, immediately after LT3-D16 was fixed: the arrival date publishes now, and the kit is still refused on the storefront. Gate 1 of LI-BL-INV-013 requires every component's own backorder setting to allow it, and that setting is decided by LI-BL-INV-008 on what is on order — never on what is on the shelf. So an End Of Line component (rule 3) or a Drop Ship Seasonal Item component (rule 4) sitting on real stock is refused, and refuses the kit with it. On 396981 the Top holds 3 in the warehouse with its checkbox off while the Base allows backorder and brings 3 on 07/12/2026 — three tables we could build and sell, and the storefront takes no order: inventoryPolicy DENY, availableForSale false, verified 2026-09-30 on variant DT-SQH-NOIR-OVA-BLAC-220. Measured the same day against live NetSuite: 49 kits are blocked by a component whose own checkbox is off; 31 of those would be allowed if a component covering at least one kit's worth of stock stopped vetoing — 27 blocked by a Drop Ship Seasonal Item component, 4 by an End Of Line one. The other 18 are refused by gate 2 on the kit's own supply type regardless. 12 of the 31 are unbuyable today (kit availability 0); the remaining 19 already sell up to their stock and would lose that ceiling. That ceiling is not the protection it first appears: 1,305 kits already publish backorder-allowed with no stock, nothing on order, no supplier stock and no arrival date — 1,033 of them Back Order Only, which is that supply type's whole purpose — so the 19 would be joining the majority, not leaving a safe state. Nothing has shipped. The 31 is modelled from NetSuite data against the gates as documented, not replayed against the deployed script, and must be replayed before anything is built. The same pattern exists one level down and is recorded as LT2-Q9: 140 standalone End Of Line items holding warehouse stock with nothing on order are refused against 12 allowed, so LI-BL-INV-008 rule 1 does not fire on custitem_qty_available_wh as that rule is written. Fixing the item rule rather than the kit gate would close both, at a much wider blast radius. The 31 must be re-measured before anything is built. It was counted from custitem_qty_available_wh, and on 2026-10-01 140 components were found to publish more availability than exists anywhere in NetSuite — see the limitation row. Two of the five worked examples used to argue this defect rested on those phantom figures: on 398954 N701 4 Seater Modular Corner Sofa (Dark Grey) the blocking components publish 10 and 9 against a real availability of 0 and 0. The examples verified against raw inventory — 396981, 399037, 88208 — still hold. |
needs confirming |
These are recorded as behaviour, not as proposals. Changing any of them is a change request; the registry is updated after that ships — CONVENTIONS §1.
Open questions
What could not be established. Recorded rather than guessed.
| Ref | Status | Question | Who can answer |
|---|---|---|---|
LT3-Q1 |
Moot2026-09-21 | needs confirming | |
LT3-Q2 |
Open | Is the mixed-quantity case (LI-BL-INV-010 case 2) still wanted? It is the most intricate rule in the chain and the only place the "please contact" safeguard is deliberately bypassed. |
needs confirming |
LT3-Q3 |
Answered2026-08-28 | LI-BL-INV-013. The separate flow that used to make it is disabled. |
needs confirming |
LT3-Q4 |
Open | How many kits does the first V3.2 run actually turn off? Gate 2 is new logic against the kit's own supply type, which nothing had read before, so the first run is the first time anyone sees the disagreement count. It should be checked against the run rather than assumed. | needs confirming |
Source references (read-only)
The code and searches this reading was written from.
Read directly from the live Celigo account on 2026-08-28 via the integrator.io API — the flow, the
script content, the kit import's thirteen mapping rows, and the disabled state of
[PROD] Update Back Order Checkbox - Kit Items — and on 2026-08-21 and 2026-08-17 before that.
Integration NetSuite Scripts (5ad5bad381aef80b5ae1ec10), flow grouping Lead Time
(620d943fb8184a400655ed19). Assets are listed in code_refs. Cross-checked against NetSuite on
2026-08-28: custitem_qty_available_gc, custitem_celigo_shopify_enable_out_sto and
custitem_receive_date_bonded_wh all confirmed present on the kit record (kit 87401).
The script record name lies. Celigo calls it Lead Time: Kit V3.1 Sep 2026 - bonded warehouse; the content header inside it reads V3.5. Anyone searching Celigo for "V3.5" will not find it. This entry follows the header. The previous record (
6a83e857e1756f4d79883a2f, Kit V3.0 Aug 2026) is orphaned at V3.2 — the export no longer references it, and editing it would change nothing.
The Lead Time flow grouping, read 2026-09-24. Six flows, zero open errors across all of
them. Nothing outside this chain writes a kit's lead-time fields: every legacy competitor is
disabled ([LEGACY] … Update In Stock / On Order / Pre Order Lead Time - Kit Items,
[PROD] Update Back Order Checkbox - Kit Items, Netsuite - Update Qty Available to Custom field - Inv/Kit). Two enabled flows touch kit records but not these fields:
Landed Cost - 3/3 - Update Kit Item Data with 180 days writes only the two landed-cost fields,
and Item Purchase Order Stage - Kit part 2/2 writes only custitem_po_stage — once a day,
which is LT3-D15. Original Lead Time V2 shares the grouping and the name but writes
custcol_agreed_due_date on sales order lines; it has nothing to do with item lead times.
Lead times: Inventory - Next Available Receive Date Update *old is disabled but still carries
the live chain's schedule and still points at flow 2 — re-enabling it by accident would feed flow 2
from two different scripts.
Open convention question. As with flows 1 and 2 — CONVENTIONS §7 assumes a commit to verify
against, and Celigo has none. exported_on stands in until a convention is agreed.
Change history
What moved on this page, and when.
| Date | Change | Change request |
|---|---|---|
| 2026-10-01 | "Part Only" recorded as the membership criterion for the lead-time chain, with its domino effect. Found by the project owner on 2026-09-30 while chasing why kit 422199 Camille Marble Console Table stayed unsellable after LT3-D16 was fixed. The component 422097 Camille Marble Console Table (Top) held a 1st-PO quantity of 10 and an arrival of 29/10/2026 while its website on-order quantity was blank and all three sentences read "Please contact showroom for lead time", last written 2026-09-21. Ticking Part Only — with no script change — produced the correct quantity, all three sentences and backorder allowed on the next run, and the kit followed to backorder-allowed. Six candidate causes had been eliminated first with evidence: backorder netting (0 on both components), the script's roll-up (Math.max(0, 10) = 10), the import mapping (present, row 1 of 12), change detection (0 !== 10 fires), a missing on-hand row (613 counterexamples) and simple staleness. The checkbox reads as a description and behaves as a switch, so a data-entry miss at item setup surfaces weeks later as a wrong promise on a kit page, with nothing logged. Recorded in the business reading, as a limitation row, and as glossary term LI-TERM-PART-ONLY. Measured 2026-09-30: 503 components across 885 kits are unticked — ~51% of the active kit catalogue — of which 7 were visibly wrong and the rest are latent until a purchase order is raised. Separately recorded as a limitation: 140 of 2,443 kit components publish more availability than exists anywhere in NetSuite, 1,025 phantom units, cause not established and not raised as a defect. LT3-D17 carries a caveat that its 31 kits must be re-measured from InventoryItemLocations, since two of its five worked examples rested on phantom figures. LT3-D16's fourth kit 422199 is now resolved by the data fix alone. No rule, script or behaviour changed. |
— |
| 2026-09-30 | LT3-D16 closed, LT3-D17 raised. LT3-D16 verified fixed in production data: the flow has run since the V3.6 deploy and kit 396981 Noir Oval Dining Table (220cm, Black Oak) now holds 2026-12-07, an arrival quantity of 3 and "New stock arrives in our warehouse from 07/12/2026 - 14/12/2026." The project owner then found the kit is still unsellable — inventoryPolicy DENY and availableForSale false on Shopify — which is a different rule and is raised as LT3-D17: gate 1 of LI-BL-INV-013 reads each component's backorder setting, and LI-BL-INV-008 decides that setting on what is on order, never on what is on the shelf, so the Top's 3 units in the warehouse veto the whole kit. Measured against live NetSuite the same day: 49 kits blocked by a component's checkbox, 31 would be allowed if a component covering a kit's worth of stock stopped vetoing, 12 of those unbuyable today. LI-BL-INV-013 itself was checked against production and needs no change — its two gates and six rules match what runs. Root cause recorded one level down as LT2-Q9 on the inventory entry: 140 End Of Line items with warehouse stock and nothing on order are refused against 12 allowed, so LI-BL-INV-008 rule 1's "the second warehouse holds stock → allowed, whatever else is true" does not fire on custitem_qty_available_wh. Nothing shipped — the 31 is a model of the documented gates, not a replay. |
— |
| 2026-09-30 | LI-BL-INV-012 and LI-BL-INV-015 corrected to the deployed V3.6 arrival-date gate. The gate had been described as two tests — the kit has sellable stock, or the kit can be back-ordered — since it was first written. V3.6 added a third, the arrival itself brings a complete kit, and it has been live and running since 2026-09-29 02:04: kit 396981 Noir Oval Dining Table (220cm, Black Oak) now publishes 7/12/2026 and an arrival quantity of 3 because of it, confirmed against production today. Until now the third test appeared only in the LT3-D16 register entry, the decision tree, a change-history row and a worked example — not in the rule, so the business reading still described the pre-V3.6 logic. LI-BL-INV-012 now states all three tests in a table and says why the third exists. LI-BL-INV-015 rule 7 was flatly wrong as written — the kit cannot be bought at all → every arrival field is blanked — and 396981 disproves it: refused on Shopify (inventoryPolicy DENY, availableForSale false, 0 available) while publishing both a date and a quantity. The row now carries the second condition. No behaviour, defect or measurement changed — this brings the rules level with code that was already deployed. last_reviewed not bumped: 396981, LI-BL-INV-013 and the Shopify variant were re-verified today, the rest of the entry was not. |
— |
| 2026-09-29 | Preamble cut back to the registry's standard shape — 203 lines to 50. Everything above ## Business logic renders ahead of the metadata card and the tab switcher, so this entry opened with a Shopify metafield table and the whole September-2026 arrival change log before a reader reached what it does. It was 4× the next largest preamble in the registry and 8× the median (21–49 lines across the other nine entries; the template allows a lede, the rules table and a rule). Three things moved, with no wording lost: the Shopify metafield comparison to Outputs & side effects, which also corrects a stale four metafields row to nine; the never add the two arrival quantities warning and its arrival-overlap anchor to LI-BL-INV-015, where the rule that causes the overlap is stated; and the 104468 Georgia Fabric King Single Bed worked example to Worked examples. The 158 need two, 6 need three measurement moved into LI-BL-INV-015 beside rule 1. Everything else removed was a second copy of something already in a rule, a defect or a change-history row — verified ref by ref before deletion, including the six-kit arrival table, which appeared twice. Two stale facts corrected on the way: the status box said verified 2026-09-24 and what runs today V3.5; both now read 2026-09-29 and V3.6. Recorded here because it lived nowhere else: 180 kit records held a stale first-arrival quantity before the arrival extension went live, left by something since retired; the kits with a real arrival value were overwritten, and the rest are cleared or stay stale depending on what the script emits. Anchors planned-arrivals and planned-arrivals-blockers are dropped — one was referenced only from inside the block removed, the other from nowhere. No rule, defect, measurement or behaviour changed. |
— |
| 2026-09-29 | Brought the LT3-D16 addition onto the current registry format. The defect linked its rules with rules:, which nothing reads — the register key is breaks: (CONVENTIONS §13), so the link was invisible on DEFECTS.md and the entry still counted as naming no rule. Corrected, and the rules it names corrected with it: the gate it breaks is defined in LI-BL-INV-012 and the fields it wrongly blanks are promised by LI-BL-INV-015 case 7. LI-BL-INV-010 was removed from the link — it behaves exactly as documented; the defect is the gate misreading its output, not the rule. The three worked examples added on 2026-09-29 also sat as ### headings outside the fourteen-section skeleton (CONVENTIONS §15); they are now #### inside Worked examples. Three anchors the 2026-09-28 restructure had orphaned — worked-example-every-field, decision-tree and known-defects — are re-attached to their own headings, so every in-page link on this entry resolves again. No behaviour, rule or measurement changed. |
— |
| 2026-09-29 | LT3-D16 raised, LT3-D10 and LT3-D11 closed against production. The project owner spotted kit 396981 Noir Oval Dining Table (220cm, Black Oak) publishing 3 on order and "Ships in 10 - 12 weeks" while showing no arrival date and telling the customer to phone the showroom. Confirmed live: the Top holds 3 with its backorder checkbox off, the Base has 3 arriving 07/12/2026. Cause recorded as LT3-D16 with a full worked example and trace — the arrival-date gate tests qtyAvailable_allWarehouses > 0, and LI-BL-INV-010 case 2 forces that figure to zero by design for a split kit, so the gate collapses onto the backorder flag and one component switches the date off. The gate's own rationale is that inbound units are already committed; checked against production and false here — quantitycommitted and quantitybackordered are both 0 on both components. 4 kits affected, measured over the live export. Pre-existing since V3.0, widened by V3.4 which made the gate blank the arrival quantities too. Fixed in V3.6, deployed 2026-09-29 02:04 and byte-verified against the live record but not yet run — the flow's last run was 00:13 that day, and all four kits were confirmed still blank afterwards. It adds a third condition, the kit is buildable from the arrival, and changes 4 kits while leaving quantities, the backorder checkbox, ships-in, both other sentences, the bonded date and all showroom figures untouched on all 1,745 — and no kit loses a date. A narrower alternative was tested and rejected: letting case 2 itself satisfy the gate missed 422199 Camille Marble Console Table and wrongly published a supplier-warehouse sentence on 264782 Double Extendable Dining Table with no date field behind it. Also closed: LT3-D10 — kits with a blank custitem_ships_in fell 421 → 371, exactly the 50 affected; and LT3-D11 — the Ellison figures have halved, 297076 Bell Floor Lamp 56/68 → 27/34, 260251 Earth Outdoor Dining Bench 20/16 → 10/8. One loose end noted but not tracked: 422199 would gain a date while a component's own on-order sentence still says "please contact showroom", which is a member-level gap in flow 2. last_reviewed bumped — re-verified against production, not skimmed. |
— |
| 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 | 19 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 LT3-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. 10 name no rule and 19 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 LT3-: 15 defects (8 open) and 4 open questions (2 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-24 | Brought up to script content V3.5 and validated against the whole live chain. New rule LI-BL-INV-015 — how many kits each arrival brings and when — recorded with its seven cases, including the sales team's confirmed fallback rule and the overlap it creates. New decision tree showing all twelve steps in the order the script runs them, because the order is load-bearing: bonded netting must precede the quantity-per-kit rescale, and the rescale must precede every minimum. New worked example covering every published field on kit 390191, and a worked example per rule across six live kits, all reconciled against NetSuite — 24 of 24 fields exact. Workflow diagram rebuilt: the old one still said the flow ran twice a day on its own clock, which stopped being true when LT3-D2 closed, and it knew nothing of the rescale, the arrivals or the Shopify gate. A second diagram traces where a kit's arrival quantity comes from, on the Daphne. Four defects raised from a full replay — 15,741 comparisons, 54 differences, 99.66% agreement: LT3-D10 (the ships-in value carries a full stop CUSTOMLIST_SHIPS_IN does not, so 50 kits hold nothing and are rewritten every run), LT3-D11 (the Ellison branch counts the supplier pool twice — 117 of 256 kits, 1,199 units, correcting an earlier estimate of 58 kits that came from a model rather than a replay), LT3-D12 (42 kits' arrival values reach NetSuite but not Shopify), LT3-D13 (the import filter was emptied, so 5,682 no-op kit writes a day), LT3-D14 (91 kit records outside the export hold a value nothing will clear) and LT3-D15 (kit PO stage updates once a day against lead times six times a day). D10 and D11 are fixed in V3.5, deployed 04:41 and not yet run; the rest are open. Five limitations added, including that an arrival counts complete kits and never boxes, and that the sentence window is always the date plus seven days. Grouping-wide check recorded in Source references: zero open errors on all six Lead Time flows, and nothing outside this chain writes a kit's lead-time fields. |
— |
| 2026-09-24 | The arrival extension went live the same day it was confirmed, and this entry is corrected to match. Script content V3.4 deployed 02:08 and the kit import widened from thirteen to seventeen mapping rows at 02:10; the flow has run. Everything the earlier entry that day recorded as not yet built is now live, and the section is rewritten accordingly. Verified against production: all six worked-example kits hold exactly the computed values, six of six, dates and quantities. The first-arrival date rule changed too — it is now the latest date among the components still waiting for one, rather than the latest among those whose on-order figure equals the kit minimum. Kit 390191 moved from advertising 5/10/2026 to 30/11/2026, the date its right corner can actually arrive; 10 kits moved later, 80 gained a date, none moved earlier. LT3-D7 resolved — the import gained new_receiveDate_bonded → custitem_receive_date_bonded_wh, so the Vietnam date the rule exists to publish finally reaches the kit record. LT3-D9 raised and resolved the same day — the Shopify imports were widened ahead of the script for about two hours; V3.4 closed the gap and the flow did not run in that window. Newly recorded: the kit import's requiresUpdate filter has been emptied, so every kit is now written on every run. That makes LT3-D8 harmless in practice and is the safe direction for a backfill, but the read-back columns are still absent, so restoring the filter later would strand the arrival fields on 38 kits. |
— |
| 2026-09-24 | The sales team chose how a kit's second-arrival quantity is counted, and memberQuantity went live. Three candidate rules were put to sales with worked examples on live stock; they chose the one where a component with nothing in the second arrival falls back to what it received in the first, then to stock on hand, because an unsold part is still on the shelf. This supersedes the "incremental" answer recorded on 2026-09-23, which was a different rule. Its consequence is recorded twice, deliberately: as the overlap warning beside the worked example, and as a row in Known limitations — the two arrival quantities overlap and must never be added. On kit 390191 Daphne 4 Seater Modular Right Corner Sofa, first arrival 1 and second arrival 1 is one sofa, not two. Separately, LI-BL-INV-010 gains case 0: a component used more than once per kit has its figures divided by how many the kit needs, rounded down. Deployed 2026-09-24 after a replay over the live export in which 1,748 of 1,749 kits reproduced production exactly; 34 kits moved, worst case kit 397096 from 22 on order to a true 11, and kits 249829 and 390230 had shown showroom stock that could not be assembled. The four member columns and memberQuantity are now present on search 6188, so the blockers recorded on 2026-09-23 are closed; the import mapping, the read-back columns and the script that emits the three new fields are not. LT3-D9 raised: both Shopify imports were widened to nine metafields ahead of the script, and two of them push an empty string into a number_integer metafield on every kit, which Shopify rejects behind an HTTP 200. One decision still open and blocking deployment — whether a kit's first-arrival date should be the last component needed rather than the first to land; kit 390191 currently advertises 5/10/2026 for a sofa that cannot exist before 30/11/2026. last_reviewed bumped: LI-BL-INV-010 was re-verified against production by replay, not skimmed. |
— |
| 2026-09-23 | Four confirmed answers recorded for the kit arrival extension, clearly marked as not yet built. The project owner confirmed: an arrival quantity means complete kits buildable from that arrival alone — min across members of floor(member qty ÷ quantity per kit), with stock on hand excluded; the second-arrival quantity is incremental, not cumulative, matching inventory items; a member with no arrival blanks the kit's date only if that member also has no stock; and kits should send all nine Shopify metafields rather than the four they send now. Recorded with a worked example on kit 104468 read live. Measured the same day: 0 live kits hold a second-arrival date and 71 hold a first-arrival quantity that nothing writes, left by something retired. Also corrected a claim in this entry that kits publish "the same four metafields" as inventory items — inventory items now publish nine, and kits do not even send qty_available_wh despite computing it. Flow name corrected in links: from Lead times V2: Kits to Lead times: Kits. Nothing is built: saved search 6188 supplies only the member first-arrival date, and four columns plus three read-backs must be added before the script can be written — the read-backs at the same time, or the extension repeats LT2-D15. |
— |
| 2026-09-22 | Five stale references to flow 3 running “twice a day” corrected — missed when LT3-D2 was closed on 2026-09-21. It is chained to flow 2 and therefore runs six times a day. This inflates nothing about the defects, but it understated LT3-D8 and LT3-D7 by a factor of three: the constant rewrites they cause happen six times a day, not twice. The historical note in LT3-D4 about the retired backorder flow's own twice-daily schedule is left as written, being a record of a different flow. |
— |
| 2026-09-21 | Linked to the confirmed rule set crosswalk in flow 1, and noted that LT-080 — kits on the same rules — is still open. Link only. |
— |
| 2026-09-21 | LT3-D2 closed. Flow 2 now starts flow 3 on completion and flow 3 carries no schedule of its own — read from the live flow configuration on 2026-09-21. Every statement that a kit lags its components by up to twelve hours has been corrected, depends_on replaced with runs_after, and the open question about flow 3's timezone closed as moot. When the chain was added is not recorded anywhere. Also noted at the head of the entry: the kit rules have not been aligned to the September 2026 rebuild of flow 1, which the business has confirmed as a later phase with the definition of a kit's buildable quantity still to be agreed. Only the chaining was re-verified against production, so last_reviewed is unchanged. |
— |
| 2026-08-31 | Placed on the order journey: journey_stage: supply (Supply), 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-28 | Brought up to the deployed script content V3.2 (deployed 2026-08-28), the corrected kit import, and the retirement of the standalone back-order flow, all read live from Celigo and cross-checked against NetSuite. New rule LI-BL-INV-013 — kits now get their own backorder decision, on two gates, and write custitem_celigo_shopify_enable_out_sto; the separate flow 5faa31bea44bdf66ac8ae144 is disabled. LT3-D1 resolved (the two text-vs-number comparisons are cast); LT3-D5 resolved (the import maps new_qtyAvailable_gc → custitem_qty_available_gc); LT3-D8 raised for the six comparisons that still test a component's figure against the kit's roll-up, which is what keeps most kits being rewritten now that LT3-D1 is fixed; LT3-D4 marked superseded; LT3-D7 re-checked and still open, with its destination field confirmed to exist. Open question 3 answered, question 4 raised. Field registry: custitem_qty_available_mia replaced by custitem_qty_available_gc, custitem_celigo_shopify_enable_out_sto added, and supplyType, supplier_receiveDate and current_allowBackOrder reclassified from returned-and-discarded to read. last_reviewed bumped — the entry was re-verified against production, not skimmed |
— |
| 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 66c6c406, created 2024-08-22, last modified 2026-08-20). Saved-search names moved from the body into links:. No logic change, and last_reviewed is unchanged. |
— |
| 2026-08-21 | Linked the entry to the glossary: 10 terms recorded in terms:, including bonded netting and the arrival-date gate this entry introduced, and the 1.4-day business-day conversion it relies on. Removed a stray </content> tag at the end of the file, which was rendering as an empty row on the published change-history table. Vocabulary and rendering only — no logic change, and last_reviewed is unchanged. |
— |
| 2026-08-21 | Verified directly against the live Celigo flow. Script V3.0 (deployed 2026-08-18) documented: new rule LI-BL-INV-012 for per-component bonded netting and the arrival-date gate. LT3-D3 resolved; LT3-D4 withdrawn as incorrect; LT3-D5 revised — the rename went in but the import did not follow; LT3-D7 raised |
— |
| 2026-08-18 | Confirmed live in production; status draft → active. Added links to the Celigo flow and saved search |
— |
| 2026-08-17 | Initial documentation of flow 3 from the Celigo export, verified against NetSuite and saved search 6188. Rules LI-BL-INV-007 and LI-BL-INV-010 recorded; defects LT3-D1 to LT3-D6 raised |
— |
Field registry — ids
Inputs
| Field id | Field name | Record | Source | Type | Read / written | Used by |
|---|---|---|---|---|---|---|
internalID |
Internal ID | Kit Item | Saved search 6188 | integer | read | A kit's promise is its slowest componentLI-BL-INV-007 A kit's stock is its scarcest componentLI-BL-INV-010 |
memberID |
needs confirming | Inventory Item | Saved search 6188 | integer | read | A kit's promise is its slowest componentLI-BL-INV-007 |
memberName |
needs confirming | Inventory Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_shipsIn |
Ships In | Inventory Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_inStockLeadTime |
In Stock Lead Time Message | Inventory Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_onOrderLeadTime |
On Order Lead Time Message | Inventory Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_outOfStockLeadTime |
Out Of Stock Lead Time Message | Inventory Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_receiveDate |
Next Available Receive Date | Inventory Item | Saved search 6188 | date | read | A kit's promise is its slowest componentLI-BL-INV-007 |
member_allowBackOrder |
Shopify Enable Out Of Stock Selling | Inventory Item | Saved search 6188 | checkbox | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 Whether a kit can be bought out of stockLI-BL-INV-013 |
qtyAvailable_warehouse |
Qty Available (Warehouse) | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
qtyAvailable_warehouse2 |
needs confirming | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 Whether a kit can be bought out of stockLI-BL-INV-013 |
qtyOnOrder_warehouse |
needs confirming | Inventory Item | Saved search 6188 | integer | read | A kit's promise is its slowest componentLI-BL-INV-007 A kit's stock is its scarcest componentLI-BL-INV-010 |
supplier_qtyAvailable |
Supplier Quantity On Hand | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 Whether a kit can be bought out of stockLI-BL-INV-013 |
supplier_qtyOnOrder |
Supplier Quantity On Order | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 Whether a kit can be bought out of stockLI-BL-INV-013 |
qtyAvailable_syd |
Qty Available (Syd) | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
qtyAvailable_mel |
Qty Available (Mel) | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
qtyAvailable_bris |
Qty Available (Bris) | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
qtyAvailable_gc |
Qty Available (Gold Coast) | Inventory Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
qtyAvailable_bonded |
Qty Available (Bonded Warehouse) | Inventory Item | Saved search 6188 | integer | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 |
qtyOnOrder_bonded |
needs confirming | Inventory Item | Saved search 6188 | integer | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 |
member_receiveDate_bonded |
Next Available Receive Date (Bonded WH) | Inventory Item | Saved search 6188 | date | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 |
current_receiveDate_bonded |
Next Available Receive Date (Bonded WH) | Kit Item | Saved search 6188 | date | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 |
brand |
Brand - Life Interiors | Kit Item | Saved search 6188 | select | read | A kit's stock is its scarcest componentLI-BL-INV-010 Whether a kit can be bought out of stockLI-BL-INV-013 |
supplyType |
Supply Type | Kit Item | Saved search 6188 | select | read | Whether a kit can be bought out of stockLI-BL-INV-013 |
supplier_receiveDate |
Supplier Next Available Receive Date | Inventory Item | Saved search 6188 | date | read | Whether a kit can be bought out of stockLI-BL-INV-013 |
supplier_defaultMadeToOrderLeadTime1 |
Default Made To Order 1 Lead Time | Inventory Item | Saved search 6188 | float | read | A kit's promise is its slowest componentLI-BL-INV-007 |
supplier_defaultMadeToOrderLeadTime2 |
Default Made To Order 2 Lead Time | Inventory Item | Saved search 6188 | float | read | A kit's promise is its slowest componentLI-BL-INV-007 |
imported |
Imported | Kit Item | Saved search 6188 | checkbox | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_qtyAvailable |
Qty Available To Sell On Website | Kit Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
current_qtyOnOrder |
Qty On Order Available To Sell On Website | Kit Item | Saved search 6188 | integer | read | A kit's stock is its scarcest componentLI-BL-INV-010 |
current_shipsIn |
Ships In | Kit Item | Saved search 6188 | select | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_InStockLeadTime |
In Stock Lead Time Message | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_onOrderLeadTime |
On Order Lead Time Message | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_outOfStockLeadTime |
Out Of Stock Lead Time Message | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_receiveDate |
Next Available Receive Date | Kit Item | Saved search 6188 | date | read | A kit's promise is its slowest componentLI-BL-INV-007 |
current_allowBackOrder |
Shopify Enable Out Of Stock Selling | Kit Item | Saved search 6188 | checkbox | read | Whether a kit can be bought out of stockLI-BL-INV-013 |
shopifyProductID |
needs confirming | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
shopifyVariantID |
needs confirming | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
shopifyItemType |
needs confirming | Kit Item | Saved search 6188 | string | read | A kit's promise is its slowest componentLI-BL-INV-007 |
new_receiveDate_bonded |
needs confirming | Kit Item | Celigo script output | date | read | Bonded stock is netted per component, and never guessed into a Sydney dateLI-BL-INV-012 |
Outputs
| Field id | Field name | Record | Source | Type | Read / written | Used by |
|---|---|---|---|---|---|---|
custitem_ships_in |
Ships In | Kit Item | NetSuite | select | written | A kit's promise is its slowest componentLI-BL-INV-007 |
custitem_ships_in_celigo |
In Stock Lead Time Message | Kit Item | NetSuite | string | written | A kit's promise is its slowest componentLI-BL-INV-007 |
custitem_next_receive_date_celigo |
On Order Lead Time Message | Kit Item | NetSuite | string | written | A kit's promise is its slowest componentLI-BL-INV-007 |
custitem_out_of_stock_message |
Out Of Stock Lead Time Message | Kit Item | NetSuite | string | written | A kit's promise is its slowest componentLI-BL-INV-007 |
custitemcust_receive_date |
Next Available Receive Date | Kit Item | NetSuite | date | written | A kit's promise is its slowest componentLI-BL-INV-007 |
custitem_qty_available_wh |
Qty Available To Sell On Website | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_on_order |
Qty On Order Available To Sell On Website | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_available_warehouse |
Qty Available (Warehouse) | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_available_syd |
Qty Available (Syd) | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_available_mel |
Qty Available (Mel) | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_available_bris |
Qty Available (Bris) | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_qty_available_gc |
Qty Available (Gold Coast) | Kit Item | NetSuite | integer | written | A kit's stock is its scarcest componentLI-BL-INV-010 |
custitem_celigo_shopify_enable_out_sto |
Shopify Enable Out Of Stock Selling | Kit Item | NetSuite | checkbox | written | Whether a kit can be bought out of stockLI-BL-INV-013 |
How to read this
Hover any box to see what it means. Click to pin it.
Start
Decision
Step
Written
Stops / held
Nothing selected
Hover a box
Each box carries a short explanation of what that step decides and why.
One kit, one run — as it runs on 2026-09-24
Flow 2 finishessix times a day
Kit members4,333 rows
Bonded nettingcomponent units
÷ quantity per kitrounded down
Split across parts?
Yes
0 availablelowest on order
No
Lowest stock wins
Arrival quantities1st and 2nd
Arrival dates
Any part unknown?
Yes
"Please contact showroom"
No
Longest wait wins
Arrival-date gate
No
Arrivals suppressed
Yes
Backorder decidedtwo gates
Kit record writtenno filter
requiresUpdate true?
No — 42 kits
Shopify skipped
Yes
Metafields pushed
Where a kit's promise comes from
Headboardplease contact
Footboardplease contact
Slats2 - 3 days
Amelia Queen Bedplease contact
Where a kit's arrival quantity comes from
Right Arm4, then 7
Left Arm2, then 3
Armless1, then 2
Right Corner1, then none
Daphne sofa1, then the same 1