Configurable models

4 models

One configurator, four product families. Each is a row in the model record — adding the fifth is data entry, not development.

CustomerNorthbank Fitout Pty Ltd

DocumentEstimate #EST1042

Configured byM. Modh

StatusIn progress

0 of 0 options selected

Configured SKU

Incomplete

Derived specification

Assembly BOM

—

Component	Qty	Rate	Ext.
Component total			—

Pricing

—

Qty Amount —

Transaction

Estimate #EST1042

Northbank Fitout Pty Ltd · Level 4 tenancy, 88 Collins St · Date 03/09/2026

SubsidiaryICON Lighting

Sales repM. Modh

StatusOpen

Items

Item / configured SKU	Description	Qty	Rate	Amount
Estimate total				—

No configured lines yet

Build a fixture on the Configurator tab and choose Add to Estimate.

What this shows. Each configured fixture lands as one estimate line, whatever family it came from. The configured code is the item; every chosen option is written to line-level custom columns so it flows through to the sales order, work order, item fulfilment and the customer PDF without anyone re-keying it. Lines built as assemblies also carry their component BOM.

Source data

ICON item catalogue

The full item search export, loaded into the prototype. The configurator prices its components from these records and resolves configured codes against them — nothing here is invented.

Items

—

ID	Name	Description	Type	Base price

The finding that matters. The export already contains fully-configured codes entered as one-off items — iRING-1.5-SS-D4-DHO-ULO-85-35K-1C-D10-UNV-RAL-NONE-CPWH-HC, iCYL-4-R-WH-2500LM-D10-80-35K-36D-WH-AC48-HC, iBEAM-2-PM-SR-D1000LM-DF-U1000LM-1C-D10-UNV-35K-WH-CWH-CPWH-HC-AC48. They are marked in the list. Their segment order is not consistent between families — the iBEAM code ends with the suspension, the iSLIM matrix puts it second from last — which is what happens when configured codes are typed by hand instead of assembled from a matrix.

Administration

Configuration Setup

Nothing in the configurator is hard-coded. Every model, category, option value and BOM rule below is a NetSuite custom record. Adding a lens optic, a diameter or a whole new product family is a data entry job for a product manager.

Models

Model	Family	Categories	Values	Pricing basis	Provenance

Option categories & values

Showing the model selected on the Configurator tab

Seq	Category	Code	Value	Label	Engineering data	Prompt	Only when	Adder

BOM rules

for the selected model

Component template	Label	Quantity formula	Applies when

Validation rules

Rule	Condition	Effect
Parameterised option needs its value	Any value with a prompt (CR, RR, RAL, CPCC, corner counts)	Block until entered; the value is written into the SKU
Cross-category availability	e.g. GZ optic only on the 1.18" Vektor profile; MM magnet mount only on 0.59"	Option is greyed with the reason shown, and cleared if it becomes invalid
Diameter belongs to the ring type	iRING TYPE → DIAM	Only the diameters ICON actually stocks for that type are offered
Suspension needs a pendant mount	iCYL MOUNT = WM	Aircraft cable options hidden; suspension set to Not Applicable
Driver sizing	iSLIM, always	Load = run ft × W/ft; smallest stocked iDRX with 20% headroom
Component missing from the item master	A BOM line resolves to an item that does not exist	Line flagged, BOM marked incomplete, assembly creation blocked
Non-standard shape review	iSLIM RR / WC / WCW / X	Fabrication charge; mark for drawing approval

Solution design

How this is built in NetSuite

The public web configurator is a marketing tool: it produces a code string a customer emails in. This prototype puts the same matrices inside NetSuite so a configured fixture becomes a priced, orderable, manufacturable line — and, where the components exist, an assembly with its BOM already built.

Runtime flow

Launch from the transaction

A Configure button on the estimate / sales order line opens the configurator Suitelet, passing the transaction, line and customer. A client script keeps the parent record in context.

Pick the model, load its matrix

The Suitelet lists the active models and loads the chosen one’s categories, values, rules and BOM lines with a single N/query SuiteQL call, so the form always reflects current product data.

Select and validate

Options are chosen in any order. Rules run live: prompts appear where a value is parameterised, cross-category availability is enforced, and the selections drive load, driver size and price.

Build the BOM

Each BOM rule resolves its component from the option codes — VT{PROFILE}-{FINISH}-96 becomes VT059-BK-96 — and computes a quantity from the run. Components are looked up in the item master; anything missing blocks the assembly rather than silently shipping a hole in the BOM.

Resolve or create the item

If the configured code already exists, the line uses it. If not, the script creates it — an assembly item with its member list where a BOM was built, an inventory or non-inventory item where it was not — from the base template, with the generated description and price.

Write the line

Item, quantity, rate and every option value are written back to the line, plus the derived engineering data. The full configuration is stored as JSON so the line can be reopened and edited.

Downstream

The option set flows to the sales order, work order / assembly build, purchase order and the customer PDF. Reporting can then slice sales by CCT, optic or finish — not just by item.

Record model

customrecord_vnmt_cfg_model

Configurator Model

One per configurable family — four in this prototype. Holds the base item, code separator, pricing basis, description template and spec block.

customrecord_vnmt_cfg_category

Option Category

The steps within a model. Sequence, whether it is fixed, required, and where its code sits in the SKU.

customrecord_vnmt_cfg_value

Option Value

The selectable options. Code, label, hint, engineering data (W/ft, lm/ft, run ft, diameter), prompt type, price adder, and the categories it is available under.

customrecord_vnmt_cfg_bomline

BOM Rule

Component template, quantity formula and the condition it applies under. This is what turns a configuration into an assembly member list.

customrecord_vnmt_cfg_rule

Configuration Rule

Requires / excludes / warns, plus derived-field rules such as driver sizing.

Transaction line columns

Configured line fields

Model, one column per category, derived engineering data, and the stored configuration JSON.

Scripts

Script	Type	Purpose
vnmt_sl_configurator	Suitelet	Renders the configurator, resolves or creates the item and its assembly, writes the line back.
vnmt_cs_configurator	Client Script	Live SKU assembly, availability and rule evaluation, BOM and price roll-up in the browser.
vnmt_ue_txn_configure	User Event	Adds the Configure button and guards manual edits of configured lines.
vnmt_lib_config	Library	Matrix load, code assembly, validation, BOM resolution and derived-spec logic, shared by all three.

What the item export tells us

Observation	Evidence in the export	What it means for the build
Configured codes are already being created by hand	Long configured SKUs exist as one-off inventory items across iRING, iCYL, iBEAM and iRL	The resolve-or-create step is replacing an existing manual habit, not introducing a new one. Those items become the first matches.
Segment order is not consistent between families	iBEAM ends its code with the suspension; the iSLIM matrix puts it second from last	The category sequence per model has to be agreed and then enforced, or old and new codes will not reconcile.
Vektor Track is already component-based	32 items: profiles, end caps, optics, clips, connectors — and VT059 already exists as an Assembly/BOM item	This is the family to build first. The BOM and its price come entirely from stocked components.
The driver ladder is real and small	Five stocked iDRX drivers: 30W, 60W, 96W, 2×96W, 288W	Driver sizing selects from these, not from a theoretical range. Anything above 288W needs multiple drivers.
iRING is a priced size ladder	64 items across four types, 18"–300", each with a list price	Base pricing comes straight from the catalogue; only the option tail needs a price rule.
Most families have no components loaded	No extrusion, lens or end cap items for iSLIM, iCYL or iRING	Those families can be configured and priced, but cannot be built as assemblies until the components are added to the item master.

Prototype vs. the public web configurator

Capability	iconlighting.com	This prototype
Scope	One product page at a time	Four families in one form, driven off one record model
Selection order	Strictly sequential — later steps stay locked	Any order, with the outstanding steps always listed
Parameterised options	Placeholder only, e.g. CR-__FT	Prompts for the value and writes it into the SKU
Compatibility	Not enforced	Cross-category availability from the real catalogue, with the reason shown
Engineering output	None	Run length, load, delivered lumens, stocked driver selection
Bill of materials	None	Assembly member list resolved against the item master, with gaps flagged
Price	None	Per-foot, catalogue ladder or component roll-up, depending on the family
Result	A code string on the clipboard	A priced estimate line with its full option set and BOM

Assumptions in this demo. The customer and estimate are invented. iSLIM option pricing is illustrative — ICON publishes none; Vektor prices are the real component list prices, and iRING and iCYL base prices are the real catalogue prices, with illustrative adders on top. Option structures marked inferred were reverse-engineered from existing item names and need confirming before build. Driver sizing assumes 20% headroom on the stocked iDRX range.