This chapter covers the following topics:
This chapter defines the term "configuration model" and presents the types of Models that are available in Oracle Configurator Developer.
To learn about designing a configuration model for an Oracle Configurator, see the Oracle Configurator Modeling Guide. For information about optimizing the performance of your runtime Oracle Configurator, see the Oracle Configurator Performance Guide.
A configuration model is Model structure, configuration rules, and optionally a User Interface from which an Oracle Configurator end user makes selections to configure a valid, orderable item. You build configuration models in Configurator Developer based on products or services that can be configured according to validation rules that you define.
Model structure is the hierarchical view of the data that represents the product or service, and is the starting point from which a configuration model is developed. You typically use the Model structure to define configuration rules and generate a runtime User Interface. For details, see Introduction to Model Structure.
There are two kinds of Models: Models that you create in Configurator Developer, and imported BOM Models. Imported BOM Models are described in Imported BOM Models.
Models that you create in Configurator Developer are often created to provide guided buying or selling questions and may reference, or be referenced by, other Models. Guided buying or selling is described in Guided Buying or Selling.
Important: You can also create Models that use the Fusion Configurator Engine (FCE), or convert existing Models to use the FCE. The FCE is an alternative to the configuration engine described in this document. For all information about FCE Models, and the procedure for creating them, see the Oracle Configurator Fusion Configurator Engine Guide.
Within a Model you can create any type of structure node, including Components, Features, Options and so on. You can also create References to other Models, or to a BOM Model.
Note: In this user’s guide, the term "Model" also refers generally to the hierarchical structure of data required to create a configuration model. (In other words, the data that appears in the Structure area of the Workbench.) This structure may consist of a Model that you create in Configurator Developer, an imported BOM Model, or both. To avoid confusion with imported Models, this guide refers to a Model that you create in Configurator Developer as either a non-imported Model or a non-BOM Model.
When viewing a Model in the Structure area of the Workbench, you may notice that a Model that you create in Configurator Developer has a node type of "Component". (You can see this by applying a View that includes the Node Type column. Views are described in Views.) This is because a Model you create in Configurator Developer has the same characteristics as a Component node; the only difference is that a Model can be referenced by another Model, while Components cannot.
To create a Model, see Creating a Model.
Guided buying or selling refers to customer needs-assessment questions that are built into your configuration model to guide and facilitate the configuration process in a runtime UI. It also refers to the Model structure that defines these questions, such as Components, Features, Totals, Resources, and so on, and configuration rules that automatically select some product options and exclude others based on the end user’s responses.
For example, in a configuration model for an automobile, you create a Feature whose UI caption is "Select the stereo system you want." The Feature’s Options represent the Premium System with 8 speakers and 5 CD changer, the Enhanced System with 6 speakers and single CD, and the Basic System with 4 speakers and no CD player. Using these Options, you define rules that select or exclude specific options from the configuration. At runtime, the end user’s selections guide the process of configuring a product that best meets their needs.
Typically, an integrated Oracle Configurator in Oracle Applications is based on an existing BOM Model that is defined in Oracle Bills of Material, and then imported into the CZ schema’s Item Master. The integration with Oracle Applications supports the Configure to Order (CTO) process, which includes order entry, demand forecasting, master scheduling, production, shipping, and financial accounting. For details about CTO, see the Configure to Order Implementation Guide.
The import process populates the hierarchical Model tree and the CZ schema’s Item Master with BOM Model data. Imported BOM data usually includes the root BOM Model and all of its optional components, which may include other BOM Models, BOM Option Classes, BOM Standard Items, and any associated Properties. Imported Properties are discussed in Item Types and Imported BOM Properties.
Required BOM components are not imported into Oracle Configurator Developer with the BOM Model, since they are not configurable. However, there is one exception to this rule: a required component is imported into Configurator Developer if it contains optional components, since in this case the required component is configurable. For more information about optional and required components, see Imported BOM Rules.
Importing BOM Models is described in the Oracle Configurator Implementation Guide.
A BOM Model can be ordered from a host application without launching Oracle Configurator to select specific options. In other words, an end user does not have to configure a BOM Model before it can be added it to a sales order and processed by downstream ERP applications. In this case, only required items within the BOM Model are ordered.
Note: Do not confuse BOM components with Component nodes that you create in Oracle Configurator Developer. BOM components are Oracle Inventory Items - such as BOM Models, BOM Option Classes, and BOM Standard Items - that are part of a BOM Model. For more information about Component nodes, see Components.
Note: For an important note about the initial logic state of BOM items in the runtime UI, see Indicating Logic State in the Runtime User Interface.
When you import a BOM Model, Configurator creates a corresponding Model node in the top level of the Main area of the Repository (that is, in the root folder). You can then copy or move the Model into a specific folder, or open it for editing in the Workbench.
Each BOM Model imported from Oracle Bills of Material corresponds to one BOM Model in Oracle Configurator Developer. The name of the BOM Model corresponds to the name in Oracle Bills of Material, and the hierarchical structure in Configurator Developer mirrors the BOM Model’s structure that is defined in Oracle Bills of Material.
When a BOM Model contains other BOM Models, the child BOM Models appear as Reference nodes in Configurator Developer. For more information, see References and BOM Models.
Important: The BOM import process cannot resolve a parent-child relationship if the relationship is created after the child BOM Model is imported into Configurator Developer and the child BOM Model exists in a Folder.
For example, you import BOM Model C into Configurator Developer and then move it to a Folder. In Oracle Bills of Material, BOM Model C is then added as a component of BOM Model P (Model C is now a child of Model P). When you import BOM Model P into Configurator Developer, the import process imports BOM Model P and creates a new version of BOM Model C in the Main area of the Repository. The import process can associate the parent BOM Model with the original version of the child Model only if the child still exists in the Main area of the Repository.
The types of BOM Models that are configurable include Assemble to Order (ATO) and Pick to Order (PTO) BOM Models. These BOM Models are defined in Oracle Bills of Material using item data defined in Oracle Inventory. The imported data is read-only in Configurator Developer because it must correspond to the BOM Model defined in Oracle Bills of Material throughout the business process. However, you can use Configurator Developer to add Components, Resources, Totals, and so on to meet your configuration requirements.
Note: A PTO BOM Model may also be a Container Model. See Container Models.
Oracle Configurator Developer uses different icons for each type of Model structure node so you can differentiate between imported BOM Model structure nodes and nodes that you create in Configurator Developer. You can also define or modify the View used in the Structure area of the Workbench so it displays the Type column. This column indicates whether each node is a BOM Model, BOM Option Class, non-BOM Model, Component, and so on.
In Configurator Developer, the BOM Model name consists of the Model name defined in Oracle Inventory, followed by its Inventory organization ID and Inventory Item ID.
For example:
Production V1 Test (203 52144)
In this example, Production V1 Test is the BOM Model name, 204 is the organization ID, and 52144 is the Oracle Inventory Item ID. (The organization ID and Item ID are internal values and are therefore not visible in Oracle Inventory.)
In the Main area of the Repository you can modify the name or description of a BOM Model, and you can change the name of a Reference to a BOM Model in the Structure area of the Workbench, but you cannot modify any information that is imported from Oracle Bills of Material.
When you populate the CZ schema, the following information about each BOM item appears in Configurator Developer:
Name: The name of the item.
Description: A brief description of the item.
Definition: A basic definition of the item, including the BOM Item Type, Minimum and Maximum Quantity, Default Quantity, and whether:
The item’s optional children are mutually exclusive (see Imported BOM Rules)
The item is required in the configuration when its parent is selected
The item allows decimal quantities (see Decimal Quantities and BOM Items)
The item is Trackable (for details, see the Oracle Telecommunications Service Ordering Process Guide)
Properties: Item Catalog Descriptive Elements (Property Names) and Descriptive Element Values (Property Values) that are defined in Oracle Inventory (see Item Data Imported from Oracle Inventory).
Property Values: Item Catalog Descriptive Element values defined in Oracle Inventory.
Effective date: The range of dates in which the item can be added to a configuration.
An imported BOM Model also contains several implicit rules and behaviors that you should understand. For details, see Imported BOM Rules.
In Configurator Developer, the Decimal Quantity is Allowed setting appears in the details page for all imported BOM items. (See Definition.) This setting indicates whether an Oracle Configurator end user can enter a decimal value when entering a quantity for the item at runtime. The Decimal Quantity is Allowed setting is set for each BOM item when you import a BOM Model, and it cannot be changed in Configurator Developer.
When importing a BOM Model into the CZ schema, the profile option CZ: Populate Decimal Quantity Flags controls whether an Oracle Configurator end user can enter a decimal quantity for BOM Standard Items that are defined as accepting decimal quantities in Oracle Bills of Material. For details about this profile option, see the Oracle Configurator Installation Guide.
Whether an item accepts decimal quantities or an integer also depends on the BOM Item Type of the item’s parent Model. If the item’s parent is an ATO BOM Model, the item was defined as accepting decimal quantities in Oracle Inventory, and the profile option CZ: Populate Decimal Quantity Flags is set to Yes, then the item accepts a decimal quantity in a runtime Oracle Configurator. (In this case, the Decimal Quantity is Allowed check box is selected in Configurator Developer.) If the item’s parent is a PTO BOM Model, an end user cannot specify a decimal quantity for the item at runtime, regardless of the profile option’s value, or how the item was defined in Oracle Inventory.
If an item accepts decimal quantities, an end user can enter up to 9 digits after the decimal character at runtime. For more information about importing BOM Models that use decimal quantities, see the Oracle Configurator Implementation Guide.
Warning: Oracle Bills of Material allows you to create BOM Models in which a divisible (decimal) parent has one or more indivisible (integer) children. However, Oracle Order Management does not allow users to order a BOM that is defined this way. Additionally, Oracle Configurator Developer displays an error when you generate logic for such a Model. For example, a BOM Option Class that allows decimal quantities must not contain Options that are defined as integers.
If the Enable Option Quantities setting is selected for an Option Feature, an Oracle Configurator end user can enter a quantity for each Option. This type of Option Feature is called a Counted Option, and it accepts only an integer at runtime.
Integer Features accept only integers at runtime, while Decimal Features accept either decimals or integers.
Totals and Resources can display up to two digits after a decimal point (for example, 3.12) while Numeric Features display up to nine digits after a decimal (for example, 3.123456789).
Item Catalog Groups and Descriptive Elements are defined in Oracle Inventory. An Item Catalog Group is used to specify descriptive information about a group of related Items. Descriptive Elements are defined for an Item Catalog Group to provide additional information about all of the Items in the group. For example, an Item Catalog Group called Desktop PC has a Descriptive Element called RAM Memory. Values for the RAM Memory Descriptive Element include 256MB, 512MB, and so on.
When you populate the CZ schema by importing data from Oracle Bills of Material, Item Catalog Groups become Item Types in Configurator Developer. The Descriptive Elements and their values in an Item Catalog Group become each BOM item’s User Properties and Property values, respectively, in Configurator Developer. This mapping is shown in Item Data Imported from Oracle Inventory.
| Oracle Inventory | Oracle Configurator Developer |
|---|---|
| Item (Models, Option Classes, and Standard Items) | Item |
| Item Catalog Group | Item Type |
| Descriptive Element | Item Property |
| Descriptive Element Value | Item Property Value |
Items are children of Item Types. Therefore, an Item’s parent indicates its type. If a BOM Item is not assigned to an Item Catalog Group in Oracle Inventory, it does not belong to an Item Type when you import it into the CZ schema. In this case, the Item’s Item Type is set to Default Type. You can see to which Item Type an Item belongs by viewing the Item’s details page. For details, see Introduction to the Item Master Area of the Repository .
A profile option controls the default Item Type Name for each Item Catalog Group that is imported from Oracle Inventory. For more information, see the Oracle Configurator Installation Guide.
For more information about Item Catalog Groups and Descriptive Elements, see the Oracle Inventory User’s Guide.
For more information about Properties, see Introduction to Properties .
Descriptive Element values do not have a data type in Oracle Inventory. Properties imported from Bills of Material have a data type of either Text or Decimal Number in Configurator Developer. The database setting ResolvePropertyDataType controls whether an imported Property’s data type is set to Text or Decimal Number. This setting is described in the Oracle Configurator Implementation Guide.
For more information about data types, see Property Data Types.
Because you can use Properties when defining some types of rules, it is important to consider whether you want Descriptive Element values to be imported as text or as numbers. It is also important to understand how changing a Descriptive Element’s value in Oracle Inventory can have unintended results Configurator Developer.
For example, some of your configuration models contain Numeric Rules that use imported Properties. These Properties are derived from an Oracle Inventory Item Catalog Group called "Aluminum Pipe", which contains a Descriptive Element called "Length". All of the Descriptive Element values are numbers, such as 10, 15, 20, and so on. An Oracle Inventory user adds a Descriptive Element and, instead of just entering a number as its value, enters "20 meters". After refreshing any BOM Models that use the "Aluminum Pipe" Item Catalog Group, logic generation will fail for all of the Numeric Rules that use Properties from the Aluminum Pipe Item Type. All other configuration models that use this Item Type will also be affected.
Because Oracle Bills of Material data must remain consistent, you cannot delete or modify imported BOM Items, Item Types, or User Properties in the Main area of the Repository. For example, you cannot change the name or description of an imported Item or Item Type or modify the value of an imported User Property in the Main area of the Repository.
However, you can perform the following in the Item Master area of the Repository:
You can add imported or non-imported Properties when editing an Item Type, and modify Property values when editing an Item.
If you or another Configurator Developer user assigned a Property to an Item Type in Configurator Developer, you can:
Remove the Property’s association with the Item Type by editing the Item Type (this also removes the Property’s association with all of the Item Type’s child Items)
Modify the Property’s value by editing the Item
If a Property was imported with the Item, you cannot remove its association with the Item Type or modify its value.
For more information, see Editing User Properties Assigned to Items or Item Types.
You cannot export any Properties that you add to an Item Type to Oracle Bills of Material (that is, to update the BOM Model).
For more information about Properties, see Introduction to Properties .
In Oracle Bills of Material, you can define a BOM Model in which the same item (component) appears more than once beneath the same parent item, as long as the combination of operation sequence number and item number for each item is unique. However, to configure such a Model in a runtime Oracle Configurator, the effective dates for the duplicate items must not overlap.
For example, in Oracle Bills of Material, Standard Item A appears multiple times as a component (child) of BOM Option Class X, and each instance of the item has a different operation sequence number. A runtime Oracle Configurator supports this structure only if the effective dates for each instance of Standard Item A do not overlap.
If the effective dates (or times) overlap at all, Oracle Configurator displays an error when an end user clicks Finish to save the configuration. This is true even if the effective date defined in Oracle Bills of Material disables all but one instance of Standard Item A at runtime.
Advanced Product Catalog (APC) is part of the Oracle Product Lifecycle Management application. If you have installed APC and have defined user-defined attributes for items that are part of a BOM Model, you can add these attributes to the CZ schema when importing a BOM Model.
Like Catalog Descriptive Elements (which are defined in Oracle Inventory), user-defined attributes appear as User Properties in Configurator Developer and can be used in the same ways as other User Properties, such as when defining rules, Populators, or captions for UI elements. Any user-defined attribute values are also imported and appear as User Property values.
In Configurator Developer, user-defined attributes appear as User Properties in:
The Main area of the Repository
The details page of their associated BOM items, Items, and Item Types
The names of Properties created from user-defined attributes have the following syntax in Configurator Developer:
AttributeGroupName.AttributeName
Like imported BOM Properties, Properties created from user-defined attributes are read-only in Configurator Developer. Unlike imported BOM Properties, you cannot associate a Property that was created from a user-defined attribute with other Items or Model nodes. In other words, a Property created from a user-defined attribute can only be associated with the BOM item to which it was originally assigned in Oracle APC.
For more information about Properties, see Introduction to Properties .
To be imported into the CZ schema, a user-defined attribute:
Must be flagged in APC as usable in Configurator (by modifying its usage)
Cannot be defined as a "multi-row" attribute
For details about multi-row attributes, refer to Oracle Product Lifecycle Management documentation.
Must have a data type of String, Number, or Translatable Text
Attributes that have a data type of either Date or "Date and Time" are not imported into the CZ schema.
For details, see Data Types.
Only Attributes associated with base Items are imported; Attributes associated with Item Revisions are not imported.
Data Types in Oracle Advanced Product Catalog and Configurator Developer shows how the data types for user-defined attributes appear in APC and in Configurator Developer.
| Data Type in Advanced Product Catalog | Data Type in Configurator Developer |
|---|---|
| String | Text |
| Number | Decimal Number |
| Translatable Text | Translatable Text |
For more information about data types, see Property Data Types.
For more information about user-defined attributes, see the Oracle Product Lifecycle Management documentation.
You can include additional aspects of your configuration problem by adding structure to extend an imported BOM Model. For example, you might want to create Totals and Resources to keep track of a quantity or add nodes to present guided buying or selling questions to your Oracle Configurator end users. You can create nodes within a BOM Model, but not within a BOM Option Class or BOM Standard Item. When a BOM Model contains nodes created in Configurator Developer, the non-BOM nodes appear before the BOM nodes in the hierarchical structure (that is, as children of the BOM Model node itself).
For more information about building Model structure, see Introduction to the Structure Area of the Workbench.
A Container Model is a type of BOM Model that contains BOM Models, BOM Option Classes, and BOM Standard Items that are tracked in Oracle Install Base. This type of Model enables you to reconfigure installed instances of telecommunication services by moving, adding, changing, or disconnecting a customer's services in a runtime Oracle Configurator. Container Models are typically part of the Oracle Telecommunications Service Ordering (TSO) solution.
For more information about TSO, refer to the Oracle Telecommunications Service Ordering Process Guide.