Product configuration models overview
Product configuration models overview
This article defines terms and concepts that are relevant to product configuration models. Product configuration models let you build a generic product structure that can be used to configure many product variants for a single product.
Product configuration models are created to represent a generic product structure. After you've set up a product configuration model, you can configure a distinct product variant that has a unique bill of materials (BOM) and a unique route. Product configuration models use both declarative constraints and imperative calculations to handle the relations and limitations between different product variants. You can configure items on sales orders, sales quotations, purchase orders, and production orders. The following table describes the table constraint–based terms and concepts.
Components | Components are the main building blocks of a product configuration model. Components are displayed in a tree structure on the Constraint-based product configuration model details page. Components can contain the following elements:
| ||||||||||||||||
Attributes | Attributes describe all the features of the product configuration model. You can use attributes to specify the features that can be selected when a distinct product is configured. Attributes are used in constraints and conditions. When attributes are created and added to a product configuration model, the related attribute types are referenced. A default value can be set for an attribute. The default value is used in the configuration user interface (UI) when the product configuration model is configured. You can specify that an attribute is mandatory, read-only, or hidden.
| ||||||||||||||||
Attribute types | Attribute types specify the set of data types for attributes that are used in a product configuration model. The following attribute types are used:
| ||||||||||||||||
Constraints | Constraints describe the restrictions of the product model configuration. Constraints are used to guarantee that only valid values are selected when a product is being configured. Constraints can be either expression constraints or table constraints:
| ||||||||||||||||
Calculations | Calculations represent a supplement to constraints. You can use a calculation to perform arithmetic operations on attributes of the Decimal and Integer types, or logical operations that involve attributes of the Text with a fixed list and Booleantypes. A calculation has a target attribute that will hold the result of the calculation expression. The calculation expression is built by using the expression editor. | ||||||||||||||||
Subcomponents | Subcomponents reflect the tree structure of the product configuration model. You can use subcomponents to build the structure of the product configuration model. Subcomponents reference existing components. Therefore, subcomponents encourage the reuse of components in multiple product configuration models. On the BOM line details page for a subcomponent, you can select a distinct value for the subcomponent. Alternatively, you can select an attribute that the value is selected for when the product configuration model is set up. To include a product as a component or subcomponent, you must specify the following information on the Create product page when you create the product:
| ||||||||||||||||
User requirements | User requirements represent an abstraction between user requirements and specific components and attributes. You can't map a user requirement to an item. For example, a customer is shopping for a home theater system. The sales representative might ask about the size of the room where the customer plans to install the system, to determine how many watts are required. In this example, the room size can be a user requirement that helps determine the appropriate attribute value for a specific component. You can hide user requirements so that they aren't displayed to the user during a configuration session. Attributes, subcomponents, and user requirements that are related to the user requirement are also hidden. You can write a condition to control whether a user requirement can be hidden. You must write the condition by using Optimization Modeling Language (OML) syntax. | ||||||||||||||||
BOM lines | BOM lines represent the individual materials of the components in the product configuration model. On the BOM line details page, all items are available for selection. A condition can be added to the BOM line, so that the BOM lines that are selected for a distinct product variant can vary, based on the user's selection when the product configuration model is set up. Conditions are expressions that must be met for attributes, BOM lines, and route operations to be included in a product configuration model. On the BOM line details page, you can select a distinct value. Alternatively, you can map to an attribute that the value is selected for when the product configuration model is set up. | ||||||||||||||||
Route operations | On the Route operation details page, you can select a distinct value. Alternatively, you can map to an attribute that the value is selected for when the product configuration model is set up. Conditions are written like expression constraints. Conditions are expressions that must be met for attributes, BOM lines, and route operations to be included in a product configuration model. |
Comments
Post a Comment