Product configuration
Model product family, model, variant, configuration items and released baselines for the as-designed product. It never creates physical inventory or an as-built record.
Screen orientation
Engineering/Configuration permissions determine which authoring and independent baseline release actions appear. Source selections remain site and classification scoped.
Use the screen sections in order: family/model/variant establishes the product hierarchy, configuration items describe the controlled parts of the design, baselines freeze an approved snapshot, and product units register a serialized context.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Family code / Family name | Text | Required to create a product family. | Use the durable product-family identity and readable name. Do not use a serial number or build order. | Creates the top-level as-designed product grouping. |
| Model code / Model name | Text | Required to create a model under a family. | Use the controlled model identity. A model is a definition, not a physical unit. | Creates the next hierarchy level under the selected family. |
| Variant code / Variant name | Text | Required to create a variant. | Use the configured variant identity and associate it with the correct model. | Provides the source for a baseline and registered product-unit context. |
| CI number / CI type | Text and select | Required for a configuration item. | Use the controlled configuration-item identifier and its role/type. Link the approved catalogue revision rather than duplicating item data. | Adds a defined configuration component to the variant context. |
| Quantity per product unit | Positive decimal in the hardware item's base unit | Required for each selected hardware CI; defaults to one for legacy baselines. | Enter how many of this exact item revision the configured product requires. Product units per product and component units must be compatible before planning can net the requirement. | Snapshots a quantity that released-baseline customer demand can use for dated material planning. |
| Effectivity | Select | Required for a baseline. | Choose ALL, date or serial effectivity. Supply dates or serial limits only for the selected effectivity type. | States where the released baseline may apply without rewriting historical snapshots. |
| Released BOM / Controlled document | Select | Required when the baseline requires those governed sources. | Select the exact released source/evidence version; never paste a free-text replacement for a controlled record. | Pins the baseline to its authoritative source. |
| Product-unit serial | Text | Required to register a serialized product unit. | Enter the exact product serial and select its released baseline. Registration does not prove material installation or create stock. | Creates product context for later governed configuration evidence. |
Actions and effects
When to use: When authoring the as-designed model under the appropriate controlled parent.
What it does: Creates definition records only; no stock, BOM issue or manufacturing execution occurs.
When to use: After the snapshot and sources are complete, then by an independent decision-maker.
What it does: Freezes the exact configuration snapshot and effectivity as a released baseline.
When to use: When a governed serialized product context is needed.
What it does: Associates a serial with a released baseline; it does not create as-built installation history.
Lists and states
- Baselines: version, status, effectivity and included CIs identify the exact released snapshot; hardware rows retain their required quantity per product unit.
- Product units: serial and released baseline provide product context; they do not display inferred installation/removal facts.
Authority boundary
Product configuration owns as-designed context. It does not create MBOMs, work orders, stock, physical custody or a historical as-maintained configuration ledger.