Products, variants and release policies
Every later setup in Supply Chain Management depends on the product. Choosing the wrong product type is hard to undo and is a frequent exam scenario.
Product subtype
| Subtype | Use it when |
|---|---|
| Product (distinct) | One item, no variants. Simple and fast. |
| Product master | The item comes in variants, such as size, color, style, or configuration. |
A product master is not an item you transact on. Its variants (for example Shirt-M-Blue) are the transactable items.
Dimensions and variants
Dimensions come in three groups:
- Product dimensions: configuration, size, color, style. They define variants.
- Storage dimensions: site, warehouse, location, and others. They control where stock is held.
- Tracking dimensions: batch and serial number.
For a product master, you choose a product dimension group and a storage and tracking dimension group, add the dimension values (for example sizes S, M, L), then generate variants. Variants inherit most settings from the master.
Constraint-based configuration
When the possible combinations are too many to list, use a product configuration model with attributes, components, constraints (expression, table, or user requirement) and calculated BOM lines and route. The salesperson configures the product on the sales order, and a unique variant can be created on demand. Pick this when the question says “based on attributes and rules”.
Versions and release
Products that change over time use versions. Control them with:
- Product lifecycle states: for example Prototype, In production, Obsolete. Each state sets whether the product can be sold, purchased, produced, or planned, and whether the system warns or blocks.
- Release policies: decide which products can be released to which legal entities, and whether an engineering change order approval is required first.
- Version number rules: define how version numbers are generated.
Products are created in the shared product list and then released to each legal entity where they will be used. Release creates the released product with its own inventory, sales and purchase settings.
Engineering product categories
An engineering product category is a node in the category hierarchy. It determines how a product behaves in engineering change management, for example which attributes and version type apply. It does not control release.
Exam traps
- A product master with product dimensions is for variants. A tracking dimension is only for batch or serial numbers.
- A lifecycle state controls where a product may be used. A release policy controls which companies receive it and under what approval.
- Release is done per legal entity. Creating a shared product alone does not allow transactions.
- Constraint-based configuration is for rules and attributes. Do not choose it for a simple size and color matrix.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. A garment is sold in several sizes and colors. Each combination needs its own SKU, but you want to maintain the description and BOM once. What do you create?
Show answer
Answer: B.A product master with product dimensions generates product variants, and shared settings are kept on the master.
2. A product has many options that a salesperson picks on the sales order, and the system must validate combinations and calculate the BOM from them. What should you use?
Show answer
Answer: A.Constraint-based product configuration uses attributes, components and constraints to build a valid configuration at order entry.
3. Customer service must be warned if a prototype version of a product is placed on a sales order. What do you configure?
Show answer
Answer: B.Product lifecycle states control in which processes a product can be used and can raise a warning or an error.
4. Versioned products must only be released to a company after the engineering change is approved. What do you set up?
Show answer
Answer: A.A product release policy can require an approved engineering change order before release.