Videos

Configure-to-Order

A Configure to Order environment is one in which the product or service is assembled or kitted on receipt of the sales order. Oracle Applications supports the Configure to Order environment with a range of features in order entry, demand forecasting, master scheduling, production, shipping, and financial accounting.

Configure to Order:

  • Includes Pick-to-Order (PTO) and Assemble-to-Order (ATO) items, ATO models, PTO Models and hybrids.
  • Supports building configurations using other configurations as subassemblies (multilevel configure to order).
  • Supports internal sourcing of ATO models at any level of Bill of Material (BOM).
  • Supports purchasing of ATO models and items at any level of the BOM.
Standrad/Option
An optional item component in an option class or model bill of material.

Model (Model Item)
An item whose bill of material lists option classes and options available when you place an order for the model item.

Option Class
A group of related option items. An option class is orderable only within a model. An option class can also contain included (standard) items.
An Option Class is a list of choices

Assemble–to–Order (ATO)
An environment where you open a final assembly order to assemble items that customers order. 
Assemble–to–order is also an item attribute that you can apply to standard, model, and option class items.

1. Assemble–to–Order (ATO) Model
A configuration you make in response to a customer order that includes optional items.
Assemble-to-Order model consists of:
  • Model bill of material with optional items and option selection rules
  • Configuration manufactured from mandatory components and selected options
Shippable - NA, Stock able - NA, Transact able – NA, Ship Model Complete - Yes.
BOM Allowed : Yes
BOM Item Type : Model
Build in WIP:  No

Customer Ordered : Yes
Custmer Order Enabled: Yes
OE Transactable : Yes
Assemble to Order : Yes
Pick Components : No

Planning Method : MPS Planning
Forecast Control : Consume or Consume & Derive

2. Assemble–to–Order (ATO) Option classSet of options present in a Model.

Shippable - NA, Stockable - NA, Transactable - NA
BOM Allowed : Yes
BOM Item Type : Option class
Build in WIP:  No

Customer Ordered : Yes
Custmer Order Enabled: Yes
OE Transactable : Yes
Assemble to Order : Yes
Pick Components : No

Planning Method : MRP Planning
Forecast Control : Consume and derive if manufacturing the model. Null if it belongs to a purchase model

3. Assemble–to–Order (ATO) Item
An item you make in response to a customer order.
Shippable - Yes, Stock able - Yes, Transact able - Yes
Assemble-to-Order item consists of:
  • Standard bill of material with standard components
  • Item manufactured from standard components
BOM Allowed : Yes
BOM Item Type : Option class
Build in WIP:  Yes, if using the autocreate program to generate supply—even if it is a buy item. Otherwise, it depends.

Customer Ordered : Yes
Custmer Order Enabled: Yes
OE Transactable : Yes
Assemble to Order : Yes. This value should be the same in all organizations
Pick Components : No

Planning Method : MRP Planning
Forecast Control : Consume.

There are three types of ATO items:
1. Standard ATO Items: These are standard items with the ATO flag checked on the OM tab of the item master.

2. Preconfigured Items:  An item defined by the user with a "Base Model" and a configured bill of material. These items have the following attributes:
  • The ATO flag checked on the OM tab of the item master
  • A Base Model defined on the BOM tab of the item master

3. AutoCreated Configuration Items:  Configuration items created by CTO for a sales order which was placed for a model and options. These items have the following attributes:
  • The ATO flag checked on the OM tab of the item master
  • A Base Model defined on the BOM tab of the item master
  • The Autocreated Configuration flag is checked

Pick–to–Order (PTO)
A configure–to–order environment where the options and included items in a model appear on pick slips and order pickers gather the options when they ship the order.
Alternative to manufacturing the parent item on a work order and then shipping it.
Pick–to–order is also an item attribute that you can apply to standard, model, and option class items.

Pick–to–Order (PTO) Model
An item with an associated bill of material with optional and included items.
At order entry, the configurator is used to choose the optional items to include for the order.
The order picker gets a detailed list of the chosen options and included items to gather as separately finished items just before the order is shipped.
Shippable - NA, Stock able - NA, Transact able – NA & Ship Model Complete - Yes
BOM Allowed : Yes
BOM Item Type : Model
Build in WIP:  No
OE Transactable : Yes
Assemble to Order : No
Pick Components : Yes
Planning Method : Not Planned
Forecast Control : Consume

Pick–to–Order (PTO) Option class
Set of options present in a PTO Model
Shippable - NA, Stock able - NA & Transact able - NA
BOM Allowed : Yes
BOM Item Type : Option class
Build in WIP:  No
OE Transactable : Yes
Assemble to Order : No
Pick Components : Yes
Planning Method : Not Planned
Forecast Control : Consume & Derive

Pick–to–Order (PTO) Item (Kit)
A predefined configuration order pickers gather as separately finished included items just before they ship the order. Also known as a kit.
A kit is an item that has a standard list of components (or included items) you ship when you process an order for that item.
A kit is similar to a pick–to–order model because it has shippable components, but it has no options and you order it directly by its item number, not using the configuration selection screen.

New tab

Setup

BOM Parameters
The following table lists the fields in the BOM Parameters form that are relevant to configurations.


 
Inactive Status
The list of value consists of all the item statuses that are defined in the system.
The Deactivate Configuration Items program sets item status of configuration items to this value.

Numbering Segment
The list of value consists of all the item segments.
The item field is a flexfield that may contain multiple segments.
Let’s say you have a two segment item field. The two segments are Item-Group. Item, Group will show up in the LOV. The segment you choose here will be the field that the ‘Numbering Method’ applies.
NOTE: The numbering segment parameter must be set in the OE validation organization. The setting in all other organizations will be ignored

Numbering Method
Possible values: Append with sequence / Replace with sequence / Replace with order, line number, shipment # / User defined
Using the above example, let’s say you choose the Item segment in the Numbering Segment. For an ATO model CN97444-Laptop, the configured item number will be the following for each Numbering Method:
CN97444*1236-Laptop / 1236-Laptop /45623*1*1-Laptop (45623 is the sales order number, 1 is the line  number, 1 is the shipment number.)

User defined: The user defined method can be used to generate customized numbering for configuration items. Customized method can be implemented in the packages BOMCFGI.pls and CTOCUCNB.pls. For details on how to use these packages see Custom CTO Packages.
NOTE: The numbering method parameter must be set in the OE validation organization. The setting in all other organizations will be ignored

Create Lower Level Supply
Possible values: No / Auto-created Configuration items only / ATO items and Auto-created Configuration Items.
This parameter is used to indicate whether or not the system should create supply for lower level configurations and ATO items when progressing an order on-line in order management, or when using the Autocreate FAS batch program.
If set to No, the system will create supply only for the top level ATO item or configuration. This is the default value for this
parameter.
If set to Auto-created Configuration items only, it will create supply for any lower level configuration that was generated because of the specific sales order configuration.
Note that it will NOT create supply for any lower level configuration that was matched to a preconfigured item.
If set to ATO items and Auto-created Configuration Items, it will create lower level supply for all ATO items, preconfigured items and autocreated configured items. Note that supply will be created even for ATO items setup as standard Mandatory
components on the model Bill. This option should be used only if you do not expect to have on hand for your ATO items and preconfigured items.

Config BOM Creation Allowed
Possible values: Yes / No
The default is set to Yes.
Set this to Yes in all organizations in which you plan to manufacture or purchase your configurations. It can be set to No in other organizations where a model BOM exists, but a config BOM is not necessary. For example, an OM validation  organization that is not a manufacturing organization can be set to No.

Include Model/ Option Class Items in Lead Time Rollup
Possible values: Yes/No
The default is set to No.
This parameter determines if a lead time rollup is performed on the model and option class items in the organization. This defaults to no, as rolling up a lead time on the model or option class results in a highly inflated model lead time, which affects the "Estimated manufacturing start date" calculation in AutoCreate Configuration, and affects the offset used by planning with Planning to Forecast and used by ATP against the model.

WIP Parameters
Respond to Sales Order Changes
You can choose one of the following values: Never/Always/When linked 1 to 1
This parameter determines whether or not a work order that is reserved to a sales order will be put on hold after a configured item is de-linked from a sales order line or the order is put on hold.
Never: The work order(s) will not be put on hold if you de-link the configured item from the sales order or the sales order is put on hold.
Always: The work order(s) will be put on hold if you de-link the configured item from the sales order or the sales order is put on hold.
When linked 1 to 1: The work order will be put on hold if it is the only work order reserved to the sales order.
Note: Work Orders will be linked to sales orders if the shipping organization is the same as the manufacturing organization. In addition, in a multi-level environment, only the top level configuration work order would be linked to the sales order.

Default Discrete Class
You must have a default discrete class defined in your manufacturing organizations or Autocreate FAS and create flow schedules will fail.

Inventorym Item Attribute
Create Configuration Item, BOM Attribute
The Create Configuration Item, BOM attribute on the ATO model defines how items, BOMs and routings are created according to the following values:
  • Based on Sourcing : This value creates Items, BOMs and Routings based solely on the ship from organization's sourcing.
  • Items Based on Model, BOMs and Routings Based on Sourcing : This value creates Items in all organizations where the Model item exists, and create BOMs and Routings based on the ship from organization's sourcing only.
  • Based on Model : This value creates Items, BOMs and Routings in all organizations where the model item, BOM and Routing exist.
Use of the following features requires you to use the setting Based on Model:
  • Multiple sources
  • Global ATP
  • Match with PDS ATP when sourcing models
  • Add warehouse changes after config item creation
OM : Price list
Add all the ATO/PTO Models, Option classes and options to the prce list.
 
Item Validation Organization
In Order Management, the Item Validation Organization parameter indicates the Oracle Manufacturing organization against which items are validated. You must define all transactable items (models, option classes, and options) in this organization.
Caution: If you maintain your bills of material in any organization other than the Item Validation Organization, you need to ensure the consistency between the bills.  A common practice is to set up the bill in the item primary manufacturing organization, then common it in all other organizations that need to use it.

If an operating unit has multiple OE responsibilities, then those OE responsibilities must have the same OE validation  rganization in order for AutoCreate Configuration to work properly.
 

New tab

Model and Option Class Bills of Material

Model Bills of Material
An ATO model can have another ATO model as its component. The decision as to whether or not to create a config item for a lower level model is determined by the BOM supply type on the lower level model in the item validation organization.
If the supply type is set to phantom, no configuration item will be created during autocreate config, and the model and all it’s components will become part of the top level configuration BOM.
If the supply type is set to anything other than phantom, auto create config will create a configuration item for that model and only the config item will appear on the parent configuration BOM.
Note: ATO models exist in organizations that are not part of any sourcing chain for the model if the organization is:
■ The OM validation organization, but never used to manufacture, stock, ship or transact the model
■ The PO validation organization, but never used to manufacture, stock, ship or transact the model
■ The Purchasing organization for global procurement, but never used to manufacture, stock, ship or physically transact the
model
■ Part of an enhanced intercompany transaction flow, but never used to manufacture, stock, ship or physically transact the
model If the model attribute “Create config item, BOM” attribute is set to Based on Model, or item based on model, BOM based on sourcing, The configuration item will also be created in these organizations.

Set the following attributes on the model item to prevent the configurations from being accidentally transacted or planned in these organizations: ATP, ATP Components = none Planning Method = Not Planned Model Items, Bills, and Routing
A PTO model can have another PTO model or an ATO model as its components.

New tab

ATO - Preconfigured Items

Inventory and BOM
1. Create an ATO Model.

2. Create an ATO item and put the above created model as base model in bom item attribute.


3. Switch to bills responsibility and create the required routing for the ATO model.
 
 
4. Switch to bills responsibility and create the bom of ATO Model and make it common bill if required.
 
4. Create a preconfig bom for the ATO item by using configure bill and make it common bill so that the same bill structure exists in both the OM item validation org and manufacturing org.

Order Manegment and WIP
1.  Go to OM and add the pre configured item to the price list and crate a sales order for it.

2. Book the sales order and the line status 'll be changed to Supply Eligible.
 
3. Create supply order
Actions -> Progress Order -> Create supply order
Go to Actions, select Progress Order and click on ok. 
In elligible activities select Create supply order and click on Ok.


After the request AutoCreate Final Assembly Orders completes the line status would be changed to Production Open. from the request out put we can get the wip job number.
 
 
4. Release, move and partially complete the WIP job i.e. complete part of the sales order quantity.
 



5. Change responsibility to OM and check the status of the sales order. The status should be Production Partial
 

go to WIP and complete the rest of the quantities, the status of the SO should now change to Awaiting Shipping
 
 

6. Pick and ship the sales order.
Launch pick release in shipping transaction form.

 
Create deliver & trip as required and pack it before doing the ship confirmation.
 
 

New tab

ATO/CTO Cycles

Following are the basic four ATO cycles that are used in industry.

New tab

Oracle Configurator

Oracle Configurator is a strategic guided selling and configuration product providing next generation, state-of-the-art Configurator technology with Oracle Configurator, customers can configure custom products and services that meet their needs. Through an interactive guided selling session, customer requirements are gathered and mapped to a set of product options. As the customer provides information, follow-on questions and options are focused to include only the choices that meet the customers’ requirements. Oracle Configurator interactive configuration engine provides real-time feedback about the impact of each selection in the form of prompts and warning messages that guide the customer to a valid solution.

Oracle Configurator application integrates with Oracle CRM and Supply Chain Management so you can offer guided selling to your customers. It actively gathers customer requirements and  then maps them to a set of product or service options. Oracle Configurator supports Internet sales and telesales as well as other channels.

Oracle Configurator consists of the following:

  • The CZ schema: A subschema within the Oracle Applications database that stores configuration model data.
  • Oracle Configurator Developer: An application based on the Oracle Applications (OA) Framework that is used to develop a configuration model and a configurator.
  • The runtime Oracle Configurator: The end-user environment in which users configure orderable products or service

If you are installing Oracle Applications Release 12 for the first time, the CZ schema, Oracle Configurator Developer, and the runtime Oracle Configurator are installed by running Oracle Rapid Install. If you are upgrading an existing Oracle Configurator installation, see Upgrading to this Release.

Oracle Configurator & Configurator Developer
Oracle Configurator Developer is an Oracle Applications product that enables you to rapidly develop a configuration model and a configurator.


 

A configurator is the part of an application that provides custom configuration capabilities. A configurator is usually launched from a host application, such as Oracle Order Management or iStore, and displays the selected configuration model to the end user. During an Oracle Configurator session, an end user makes selections and specifies requirements for the product or service being configured. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground. Oracle Configurator collects the customer's requirements and, using the Model definition and rules you defined in Configurator Developer, ensures that the end user creates a valid configuration.

  • A configurator can be thought of as a selling tool. The Model bill serves as a guide to selecting configuration options. A configuration created during an Oracle Configurator session is based on an already existing Model bill and results in a standard manufacturing bill of materials. Configurations do not have to be based on existing Model bills of material, although that is currently necessary for ordering and downstream ERP applications

 

  • Oracle Configurator Developer consists of a Repository and a Workbench. These areas provide the tools you use when creating and maintaining configuration models.

Repository
Use the areas of the Configurator Developer Repository to organize Models and manage objects such as Effectivity Sets, Usages, UI Templates, Items and Item Types, Properties, Configurator Extensions, and Model Publications

Workbench
The different areas of the Configurator Developer Workbench provide tools for creating, modifying, and testing Model structure, configuration rules, and UI definitions. In the User Interface area, for example, you can generate a User Interface that is based on the Model structure, and then edit it to meet your product's unique requirements.

Hierarchical Structure
Oracle Configurator Developer displays many objects, such as the Model, configuration rules, and a generated User Interface, in a hierarchy. This structure shows how elements are related to each other and indicates which objects contain other objects. When an object contains other objects, a parent and child relationship exists between them. For example, within a Model, Component A contains Feature X, Y, and Z. In this relationship, Component A is the parent and the Features are its children.

Each object within the Model structure is called a node. The node at the top of this structure is always a Model, and is called the root node. The Rules area of the Workbench and the User Interface area of the Workbench also display objects in a hierarchy (for example, rules, Folders, and UI elements), to indicate how they are organized and their relationship to other objects.

New tab

About Oracle Configurator

Oracle Configurator is a strategic guided selling and configuration product providing next generation, state-of-the-art Configurator technology with Oracle Configurator, customers can configure custom products and services that meet their needs. Through an interactive guided selling session, customer requirements are gathered and mapped to a set of product options. As the customer provides information, follow-on questions and options are focused to include only the choices that meet the customers’ requirements. Oracle Configurator interactive configuration engine provides real-time feedback about the impact of each selection in the form of prompts and warning messages that guide the customer to a valid solution.

Oracle Configurator application integrates with Oracle CRM and Supply Chain Management so you can offer guided selling to your customers. It actively gathers customer requirements and  then maps them to a set of product or service options. Oracle Configurator supports Internet sales and telesales as well as other channels.

Oracle Configurator consists of the following:

  • The CZ schema: A subschema within the Oracle Applications database that stores configuration model data.
  • Oracle Configurator Developer: An application based on the Oracle Applications (OA) Framework that is used to develop a configuration model and a configurator.
  • The runtime Oracle Configurator: The end-user environment in which users configure orderable products or service

If you are installing Oracle Applications Release 12 for the first time, the CZ schema, Oracle Configurator Developer, and the runtime Oracle Configurator are installed by running Oracle Rapid Install. If you are upgrading an existing Oracle Configurator installation, see Upgrading to this Release.

Why Configurator
One can create a configuarion out of a model in OM only by defining the correct bom structure, then why one need to use configurator?
Configurator can be used as a guided tool for the end customer to help in selecting the exact configuration with the help of  populators, Instances, properties and rules.

Enable Guided Selling
Guide customers through a series of features and options that meet their stated requirements. Provide real-time feedback with automatic prompts and warnings.

Gain Multi-Language Capabilities
Efficiently create interface with content in language appropriate to end-user.

Provide Real-time Pricing and Order Promising
Support complex pricing strategies through integration with Advanced Pricing. Provide order promising based on real-time material and resource constraints.

Oracle Configurator & Configurator Developer
Oracle Configurator Developer is an Oracle Applications product that enables you to rapidly develop a configuration model and a configurator.


 

A configurator is the part of an application that provides custom configuration capabilities. A configurator is usually launched from a host application, such as Oracle Order Management or iStore, and displays the selected configuration model to the end user. During an Oracle Configurator session, an end user makes selections and specifies requirements for the product or service being configured. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground. Oracle Configurator collects the customer's requirements and, using the Model definition and rules you defined in Configurator Developer, ensures that the end user creates a valid configuration.

  • A configurator can be thought of as a selling tool. The Model bill serves as a guide to selecting configuration options. A configuration created during an Oracle Configurator session is based on an already existing Model bill and results in a standard manufacturing bill of materials. Configurations do not have to be based on existing Model bills of material, although that is currently necessary for ordering and downstream ERP applications
  •  Oracle Configurator Developer consists of a Repository and a Workbench. These areas provide the tools you use when creating and maintaining configuration models.

Repository
Use the areas of the Configurator Developer Repository to organize Models and manage objects such as Effectivity Sets, Usages, UI Templates, Items and Item Types, Properties, Configurator Extensions, and Model Publications

Workbench
The different areas of the Configurator Developer Workbench provide tools for creating, modifying, and testing Model structure, configuration rules, and UI definitions. In the User Interface area, for example, you can generate a User Interface that is based on the Model structure, and then edit it to meet your product's unique requirements.

Hierarchical Structure
Oracle Configurator Developer displays many objects, such as the Model, configuration rules, and a generated User Interface, in a hierarchy. This structure shows how elements are related to each other and indicates which objects contain other objects. When an object contains other objects, a parent and child relationship exists between them. For example, within a Model, Component A contains Feature X, Y, and Z. In this relationship, Component A is the parent and the Features are its children.

Each object within the Model structure is called a node. The node at the top of this structure is always a Model, and is called the root node. The Rules area of the Workbench and the User Interface area of the Workbench also display objects in a hierarchy (for example, rules, Folders, and UI elements), to indicate how they are organized and their relationship to other objects.

The Overall Process

New tab

Oracle Configurator

Oracle Configurator is a strategic guided selling and configuration product providing next generation, state-of-the-art Configurator technology with Oracle Configurator, customers can configure custom products and services that meet their needs. Through an interactive guided selling session, customer requirements are gathered and mapped to a set of product options. As the customer provides information, follow-on questions and options are focused to include only the choices that meet the customers’ requirements. Oracle Configurator interactive configuration engine provides real-time feedback about the impact of each selection in the form of prompts and warning messages that guide the customer to a valid solution.

Oracle Configurator application integrates with Oracle CRM and Supply Chain Management so you can offer guided selling to your customers. It actively gathers customer requirements and  then maps them to a set of product or service options. Oracle Configurator supports Internet sales and telesales as well as other channels.

Oracle Configurator consists of the following:

  • The CZ schema: A subschema within the Oracle Applications database that stores configuration model data.
  • Oracle Configurator Developer: An application based on the Oracle Applications (OA) Framework that is used to develop a configuration model and a configurator.
  • The runtime Oracle Configurator: The end-user environment in which users configure orderable products or service

If you are installing Oracle Applications Release 12 for the first time, the CZ schema, Oracle Configurator Developer, and the runtime Oracle Configurator are installed by running Oracle Rapid Install. If you are upgrading an existing Oracle Configurator installation, see Upgrading to this Release.

Oracle Configurator & Configurator Developer
Oracle Configurator Developer is an Oracle Applications product that enables you to rapidly develop a configuration model and a configurator.


 

A configurator is the part of an application that provides custom configuration capabilities. A configurator is usually launched from a host application, such as Oracle Order Management or iStore, and displays the selected configuration model to the end user. During an Oracle Configurator session, an end user makes selections and specifies requirements for the product or service being configured. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground. Oracle Configurator collects the customer's requirements and, using the Model definition and rules you defined in Configurator Developer, ensures that the end user creates a valid configuration.

  • A configurator can be thought of as a selling tool. The Model bill serves as a guide to selecting configuration options. A configuration created during an Oracle Configurator session is based on an already existing Model bill and results in a standard manufacturing bill of materials. Configurations do not have to be based on existing Model bills of material, although that is currently necessary for ordering and downstream ERP applications

 

  • Oracle Configurator Developer consists of a Repository and a Workbench. These areas provide the tools you use when creating and maintaining configuration models.

Repository
Use the areas of the Configurator Developer Repository to organize Models and manage objects such as Effectivity Sets, Usages, UI Templates, Items and Item Types, Properties, Configurator Extensions, and Model Publications

Workbench
The different areas of the Configurator Developer Workbench provide tools for creating, modifying, and testing Model structure, configuration rules, and UI definitions. In the User Interface area, for example, you can generate a User Interface that is based on the Model structure, and then edit it to meet your product's unique requirements.

Hierarchical Structure
Oracle Configurator Developer displays many objects, such as the Model, configuration rules, and a generated User Interface, in a hierarchy. This structure shows how elements are related to each other and indicates which objects contain other objects. When an object contains other objects, a parent and child relationship exists between them. For example, within a Model, Component A contains Feature X, Y, and Z. In this relationship, Component A is the parent and the Features are its children.

Each object within the Model structure is called a node. The node at the top of this structure is always a Model, and is called the root node. The Rules area of the Workbench and the User Interface area of the Workbench also display objects in a hierarchy (for example, rules, Folders, and UI elements), to indicate how they are organized and their relationship to other objects.

New tab

About Oracle Configurator

Oracle Configurator is a strategic guided selling and configuration product providing next generation, state-of-the-art Configurator technology with Oracle Configurator, customers can configure custom products and services that meet their needs. Through an interactive guided selling session, customer requirements are gathered and mapped to a set of product options. As the customer provides information, follow-on questions and options are focused to include only the choices that meet the customers’ requirements. Oracle Configurator interactive configuration engine provides real-time feedback about the impact of each selection in the form of prompts and warning messages that guide the customer to a valid solution.

Oracle Configurator application integrates with Oracle CRM and Supply Chain Management so you can offer guided selling to your customers. It actively gathers customer requirements and  then maps them to a set of product or service options. Oracle Configurator supports Internet sales and telesales as well as other channels.

Oracle Configurator consists of the following:

  • The CZ schema: A subschema within the Oracle Applications database that stores configuration model data.
  • Oracle Configurator Developer: An application based on the Oracle Applications (OA) Framework that is used to develop a configuration model and a configurator.
  • The runtime Oracle Configurator: The end-user environment in which users configure orderable products or service

If you are installing Oracle Applications Release 12 for the first time, the CZ schema, Oracle Configurator Developer, and the runtime Oracle Configurator are installed by running Oracle Rapid Install. If you are upgrading an existing Oracle Configurator installation, see Upgrading to this Release.

Why Configurator
One can create a configuarion out of a model in OM only by defining the correct bom structure, then why one need to use configurator?
Configurator can be used as a guided tool for the end customer to help in selecting the exact configuration with the help of  populators, Instances, properties and rules.

Enable Guided Selling
Guide customers through a series of features and options that meet their stated requirements. Provide real-time feedback with automatic prompts and warnings.

Gain Multi-Language Capabilities
Efficiently create interface with content in language appropriate to end-user.

Provide Real-time Pricing and Order Promising
Support complex pricing strategies through integration with Advanced Pricing. Provide order promising based on real-time material and resource constraints.

Oracle Configurator & Configurator Developer
Oracle Configurator Developer is an Oracle Applications product that enables you to rapidly develop a configuration model and a configurator.


 

A configurator is the part of an application that provides custom configuration capabilities. A configurator is usually launched from a host application, such as Oracle Order Management or iStore, and displays the selected configuration model to the end user. During an Oracle Configurator session, an end user makes selections and specifies requirements for the product or service being configured. At the end of a configuration session, the Oracle Application dialog page is displayed before the host application returns to the foreground. Oracle Configurator collects the customer's requirements and, using the Model definition and rules you defined in Configurator Developer, ensures that the end user creates a valid configuration.

  • A configurator can be thought of as a selling tool. The Model bill serves as a guide to selecting configuration options. A configuration created during an Oracle Configurator session is based on an already existing Model bill and results in a standard manufacturing bill of materials. Configurations do not have to be based on existing Model bills of material, although that is currently necessary for ordering and downstream ERP applications
  •  Oracle Configurator Developer consists of a Repository and a Workbench. These areas provide the tools you use when creating and maintaining configuration models.

Repository
Use the areas of the Configurator Developer Repository to organize Models and manage objects such as Effectivity Sets, Usages, UI Templates, Items and Item Types, Properties, Configurator Extensions, and Model Publications

Workbench
The different areas of the Configurator Developer Workbench provide tools for creating, modifying, and testing Model structure, configuration rules, and UI definitions. In the User Interface area, for example, you can generate a User Interface that is based on the Model structure, and then edit it to meet your product's unique requirements.

Hierarchical Structure
Oracle Configurator Developer displays many objects, such as the Model, configuration rules, and a generated User Interface, in a hierarchy. This structure shows how elements are related to each other and indicates which objects contain other objects. When an object contains other objects, a parent and child relationship exists between them. For example, within a Model, Component A contains Feature X, Y, and Z. In this relationship, Component A is the parent and the Features are its children.

Each object within the Model structure is called a node. The node at the top of this structure is always a Model, and is called the root node. The Rules area of the Workbench and the User Interface area of the Workbench also display objects in a hierarchy (for example, rules, Folders, and UI elements), to indicate how they are organized and their relationship to other objects.

The Overall Process

New tab

CZ Schema

The runtime Oracle Configurator and Oracle Configurator Developer use the CZ schema within the Oracle Applications database to access and store data. There is only one CZ schema within an Oracle Applications database instance.

The CZ schema contains an Item Master subschema. The Item Master is a set of your enterprise data, structured into Items and Item Types, and is the primary source of data for your application. The Item Master consists of Items, which are specific elements of a product, and Item Types, which are logical groupings of Items. An example of an Item Type is "TV Set". The available models are the Items within the TV Set Item Type, such as 19" Black and White, 21" Color, and 42" Wide Screen. When building configuration models in Oracle Configurator Developer, you can use data in the CZ schema's Item Master to build Model structure.

Items and Item Types also have Properties. Properties are associated with imported Items and Item Types when you import a BOM Model. You manually assign Properties to the Items and Item Types that you create in Configurator Developer.

In Configurator Developer, Item Master data appears in the Item Master area of the Repository. This area of the Repository is described in Introduction to the Item Master Area of the Repository
Note:
1. Do not confuse the CZ schema's Item Master with the Oracle Applications Item Master. In this user's guide, the term Item Master always refers to the CZ schema's Item Master, unless otherwise indicated

2. Item Properties are grouped into Catalog Groups. Each Catalog group can have multiple catalog elements (properties). At the most one catalog group can be assigned to a given item. While defining product structure for ATO Model and related Option classes one must design option class and its properties in such a way that end user should be able choose various property value in Configurator. In Configurator, these catalog groups are termed as Item Types. We can define property based rules to choose components for various option classes.


Items in CZ Item Master
The Items in the Item Master are either created from scratch in Configurator Developer or are imported from source data in the Oracle Applications Item Master and other tables. In most development situations, Item Master data is imported.

Imported Items
Imported data in the CZ schema represents the source data and is only used for defining the configuration model. At runtime, after a configuration has been created and passed back to the host application, items are ordered from the source data. Legacy data, such as Bills of Material or pricing information, can be imported into the Item Master. Generally, the data source is either an Oracle Applications database or a non-Oracle Applications database. For consistency, imported data should be maintained in the source database. You can see whether an Item was imported by viewing its details page. (In other words, click on the item's name in the Item Master area of the Repository, or open it for editing.) If the item was imported, you cannot delete it, or modify its name, description, or other information.

Items Created in Configurator Developer
You may want to create Items and Item Types in Oracle Configurator Developer to automate the process of creating and updating Model nodes. For example, you may need to reuse nodes that represent customer requirements questions across multiple Models. Instead of manually recreating the nodes, you can create them once as Items and Item Types and then use the data to automatically create them as many times as necessary.

Orderable Items
The Orderable setting appears in the details page for all imported and manually created Items. This setting indicates whether the Item appears in the Configuration Summary page when it is selected at runtime.

The Orderable setting is automatically selected for all imported BOM Items and is read-only in Configurator Developer. By default, the Orderable setting is not selected for Items that you create in Configurator Developer. You can select this setting if you want the Item to appear in the Configuration Summary page when it is selected at runtime.
Only BOM Items can be ordered from a host application that is part of Oracle Applications (for example, Order Management). Custom implementations may want to use the Orderable setting, for example, to process non-BOM Items downstream in a non-Oracle system.

Modeling Items
There are multiple ways of defining or designing catalog groups. We can have separate catalog groups defined for each option class/component items. Let’s discuss this with example of Model “Sentinel Custom Desktop” Item Code CN-92777. This model has various components viz. Software, Memory, Hard Disk etc. Each option class and its related item can have related catalog group attached to it. E.g. Hard Disk Catalog Group can have properties (elements) like Manufacturer, Size, type etc. All items which come under hard disk options can have this catalog group assigned to it. Finally the MODEL item can have a new catalog group e.g. CTO Sentinal or Laptop which will contain all the catalog elements of individual option classes.

Second type of Product design can be MODEL and all its option classes/components can have the same catalog group assigned to them e.g. Desktop Catalog and individual components have values only for related properties/catalog elements.

A product can be configured (by calling Configurator) from Oracle Order Management, Order Entry screen. This order can be progressed to create a new configured item (typically called STAR item because the new item code is Model item code and a sequence number separate by ‘*’). Newly created item is standard item with standard bill of material containing actual components (as against the option classes for MODEL item). The new star item also get the catalog group assigned to Model and the catalog element values come from individual component’s catalog element values. For example, newly configured star item CN92777*12245 has “CTO Sentinal or Laptop” group of which is same as base MODEL and individual value like Memory, Hard Disk Size etc will get values from individual components.

While designing catalog element one has to take care that all option class catalog elements names are unique. E.g. Manufacturer property will be present for all option class catalog groups, to make it unique we should name it like HD. Manufacturer for Hard Disk, FD. Manufacturer for floppy disk, RM. Manufacturer for RAM etc. So when final star item gets created all catalog elements for individual components get clubbed to gather automatically.

New tab

Models

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.

Types of Models
There are two kinds of Models: Models that you create in Configurator Developer, and 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.
  • 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". 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.
Guided Buying or Selling
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.

Imported BOM Models
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.

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.

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.

Imported BOM Model Names
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.

Imported BOM Data
When you populate the CZ schema, the following information about each BOM item appears in Configurator Developera
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.
  • The item is required in the configuration when its parent is selected.
  • The item allows decimal quantities,  The item is Trackable.
Properties: Item Catalog Descriptive Elements (Property Names) and Descriptive Element Values (Property Values) that are defined in 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.

Decimal Quantities and BOM Items
In Configurator Developer, the Decimal Quantity is Allowed setting appears in the details page for all imported BOM items. 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.

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.

Item Types and Imported BOM Properties
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.
 
 

New tab

Model References

To reduce the time and effort required to create and maintain configuration models, a Model may contain one or more References to other Models. References allow a Model to be used as a subassembly within other Models. For example, your organization sells many different styles of trucks and automobiles, but some of them use the same 200 horsepower, V6 engine. You can create and maintain one Model for this engine in Oracle Configurator Developer, and then simply create a Reference to that Model from all other Models (automobiles) that use it. When the referenced Model is modified, the changes automatically propagate to all Models that refer to it.

Within the structure of a Model, a Reference node functions like a Component node. Like a Component, you can modify a Reference node's name and effectivity, and specify how many instances of the referenced Model are available and can be created in a configuration.

When you work in a Model that contains a Reference, the structure of the referenced Model appears as a subtree of the parent Model. All of the referenced Model's settings, structure, rules, and UIs are read-only when viewed from the parent Model. 

References and Rules
Like Model structure, the rules in a referenced Model are read-only when you are working in the parent Model. However, you can use referenced Model nodes when defining configuration rules for the parent Model. All rules defined this way, even those whose participant nodes are all part of the referenced Model's structure, belong to and reside with the parent Model (that is, they do not belong to the referenced Model). You can create new rules for the parent Model, but all of the referenced Model's rules are read-only when viewed from the parent Model.

References and BOM Models
One important use of References is to represent the relationship between a BOM Model that contains other BOM Models when you populate the CZ schema with BOM Model data. When you import a BOM Model that contains other BOM Models, Configurator Developer creates a Reference node for each child Model in the parent's structure. You can assign one or more Usages to a BOM Model Reference node and modify its instantiability settings, but all settings that are defined in Oracle Bills of Material are read-only in Configurator Developer (for example, the node's BOM Item Type, its Minimum, Maximum, and Default Quantity, and so on).

When a BOM Model is a child of (referenced by) several other BOM Models, it is not imported into Configurator Developer multiple times. The import procedure populates the CZ schema with the child BOM Model only once, and then creates References to it from each parent BOM Model. This allows the rules and UI for the referenced Model to be maintained in one place and ensures that no duplicate BOM Models exist in the database.

New tab

Properties

All Model structure nodes have attributes called Properties. An end user cannot select or modify Properties in a runtime Oracle Configurator, but Properties and their values can be used when defining rules or to create runtime UI captions for Model structure nodes.

There are two types of Properties:

  • User Properties
  • System Properties
User Properties
You can create User Properties in Configurator Developer, or they may be created in either Oracle Inventory or Oracle Advanced Product Catalog (APC) and then added to the CZ schema by importing a BOM Model. Examples of User Properties include Size, Weight, Length, Diameter, and Color.

In Configurator Developer, User Properties appear in:
  • The Main area of Repository
  • The details page of an Item or Item Type
  • In a Model node's details page
By default, all imported User Properties appear in the Main area of the Repository, in the root Folder. You can also manually create User Properties in this area, or in any user-created Folder. In this area, you can delete a User Property that was created in Configurator Developer, or modify its Name, Description, or Default Value. Imported User Properties can be modified or deleted only in the application in which they were created. That is, in Oracle Inventory or Oracle Advanced Product Catalog (APC).

Changes to any imported Properties do not appear in Configurator Developer until you refresh the BOM Model to which they are associated.

System Properties
System Properties are implicit attributes of both BOM and non-BOM Model nodes that vary based on the node's type. Examples of System Properties include Name, Description, Quantity, and Value.
You can use System Properties when defining:
  • Logic, Numeric, and Comparison Rules
  • The source for a UI element's caption
  • A runtime condition
When you select a Property from a list in Configurator Developer (for example, when defining a rule), an open and closed parenthesis is appended to each System Property. For example:
Name(), Description(), MinInstances(), MaxInstances(), Weight, Length & Diameter

New tab

Effectivity

Effectivity allows you to model a product that changes over time. The effectivity you assign to Model nodes and rules determines whether a node is available or a rule is active in a runtime Oracle Configurator, or when unit testing a configuration model from Configurator Developer. Oracle Configurator and Oracle Configurator Developer use the database date and time when evaluating an object's effectivity.

You control effectivity for a node or rule in Configurator Developer by indicating that it is either Always Effective or Never Effective, or by specifying either a date range or an Effectivity Set. You can also optionally assign one or more Usages to control effectivity of structure nodes and rules.

The root node of a Model is always effective, and its Effectivity settings are read-only. The Effectivity settings on a BOM Model References are also read-only because they are imported with the BOM Model. However, you can modify the effectivity on a Reference to a non-imported Model.


Effectivity also controls the availability of a Model publication to host applications. The application that is hosting the runtime Oracle Configurator specifies the date, time, and a Usage in an initialization message. All nodes that are not effective when the Model is invoked do not appear in the runtime UI, and all configuration rules that are not effective are ignored. However, it is important to note that ineffective Model nodes that have logic state (that is, Options, Option Features, all BOM nodes, and Boolean Features) are False at runtime. If such an ineffective node participates in a rule that is effective, it participates with a False logic state.

Date Ranges
The effectivity for imported BOM nodes is defined as a date range in Oracle Bills of Material, and cannot be changed in Configurator Developer. You can specify an effective date range for a rule or any node created in Configurator
Developer. A date range may include both a start date and an end date (day, month and year) and time (hours, minutes, and AM or PM), or you can select either No Start Date or No End Date. (Selecting both No Start Date and No End Date is the same as selecting Always Effective).

Effectivity Sets
Create an Effectivity Set to define an effectivity date range that can be shared by manyModel structure nodes and configuration rules simultaneously. When you modify an Effectivity Set's date range, the change affects all nodes and rules that are assigned to the Effectivity Set. Therefore, if you expect to use a specific effectivity date range for more than a very limited number of nodes, it is better to define and assign an Effectivity Set rather than specifying an effective date range for each node and rule in your Model.

You can assign Effectivity Sets to rules, Components, Features, Options, Totals, Resources, Model publications and References to non-imported Models. The effectivity assigned to imported BOM nodes is read-only in Configurator Developer, and can be changed only in Oracle Bills of Material. An Effectivity Set can be always effective, never effective, or effective only within the range of dates that you specify.

Usages
Like effective dates and Effectivity Sets, Usages provide a method of controlling the effectivity of Model structure, rules, and the availability of Model publications to a host application. A host application may pass a Usage as a parameter in its initialization message, but it is not required. You can assign Usages independently or in addition to date effectivity (in other words, either an explicit date range or an Effectivity Set).

Usages consist of any text string that you specify, and you create them in the Main area of the Repository. You can create a maximum of 64 Usages. By default, all Model structure nodes and any rules that you define are effective for all Usages. Setting a Usage on a node or rule means that it is effective for all Usages except the Usage(s) that you specify.

For example, Component A and Logic Rule X are effective for all Usages except the Usage called "Experienced User." At runtime, Oracle Order Management specifies this Usage in the initialization message. As a result, Component A does not appear in the UI and Logic Rule X is ignored.

Usages are a powerful tool for manipulating the effectivity of Model structure, rules, and Model publications based on a variety of business requirements. Therefore, be sure to plan for and implement Usages very carefully when developing configuration models. For example, it is not advisable to assign a Usage on a Reference to a required BOM Model because the item will not be available when the host application passes the Usage at runtime.

Effectivity Examples
Following are some examples of how effectivity affects a configuration model in a runtime Oracle Configurator or when unit testing from Configurator Developer:
  • Model structure nodes that are not effective do not appear, and therefore are not available for selection.
For example, a specific item in the Model will be obsolete as of May 1, 2004. You want to automatically discontinue that item as of that date so it will not be offered as an option to your end users. By specifying an effective end date of 05/01/2004 for the item, it no longer appears in the configuration model on that date or in any future configuration sessions.
  • Configuration rules that are not effective are ignored (do not propagate) at runtime.
For example, your configuration model contains a Logic Rule that selects several options based on a guided buying or selling question. However, several of these options will not be available (are no longer effective) after the end of the fiscal year.
You define effectivity for the rule so it is ignored as of the date you specify. This prevents your end users from seeing any unnecessary warnings or error messages that may appear because some items are unavailable.
  • Rules that contain ineffective participants may be unable to perform their intended actions at runtime.

New tab

Instantiation

Instantiability refers to an end user's ability to create and individually configure one or multiple occurrences (instances) of a Model or Component in a runtime Oracle Configurator. A Model Reference or Component node's Instantiability settings
determine how many instances of the component exist when the configuration session begins, and whether an end user can create additional instances at runtime.

At runtime, the end user accesses an instance of a configuration model, as well as an instance of each component contained within the Model. The end user configures each component instance separately by selecting from available options within that component.
Note: This user's guide uses the word "component" when referring to an instance of a Model or a Component node in a runtime Oracle Configurator.

For example, a computer system can be represented by a Model. A computer may contain a number of different servers, printers, and personal computer (PC) workstations, all of which are child Models of the computer system Model. Each PC workstation represents one instance of a child Model, and each instance of the PC workstation can be configured differently.

To continue the example, one instance of the PC workstation can be configured with a 21 inch flat screen monitor, 10GB of disk space and 512 KB RAM, whereas another instance of the PC workstation has a 17 inch screen, ergonomic keyboard, 256 KB RAM and 4 GB of disk space. These two workstations are part of the computer system Model.
Note: The Generic Configurator UI does not support multiple instantiation. An Oracle Configurator end user can create multiple instances of components only in User Interfaces that you create in Configurator Developer

New tab

Model Structure

Populating the CZ schema with data from Oracle Bills of Material creates one or more BOM Models in Configurator Developer. You can open a BOM Model in Configurator Developer and extend it by creating additional structure. You may want to do this if you:

  • Want to present guided buying or selling questions to your Oracle Configurator end users
  • Need objects to support Totals, Resources, and rules
A Model's structure appears in a table that, when expanded, shows where parent and child relationships exist between product elements. For example, a Component may be a child of a Model, while Options are children of a Feature.
You can create Model nodes from scratch or create them using Items in the CZ schema's Item Master. You do this either by selecting "Item-based Nodes" in the Create Nodes page, or by defining and running a Populator.

Note: To view a summary of your Model's structure, rules, and Item Master, generate a Model Report.

Features
A Feature can either be selected or accept input (depending on its type) at runtime when configuring a Component. Features can have either a value or enumerated Options. For example, an end user might be able to enter a value between 5 and 20 for an Integer Feature called Length, while an Option Feature called Color might contain Options called Red, Green, Blue, and Yellow.
You can create the following types of Features in Configurator Developer:
  • Option Features
  • Integer Features
  • Decimal Features
  • Boolean Features
  • Text Features
Connectors
In a runtime Oracle Configurator a Connector enables an end user to define connections between component instances. You can create a Connector node under either a Model or a Component node, but the Connector's target must be a Model. A Model can have one or more Connectors.

Initial Values
Use this setting to specify a node's value when the configuration session begins (that is, before any quantities are contributed or consumed, and before any rules propagate). By default, the Initial Value for Totals, Resources, and Numeric Features is blank (null) in Configurator Developer. If you do not enter an Initial Value for a Total or a Resource, the initial value is a 0 (zero) at runtime. If you do not enter an Initial Value for a Numeric Feature (that is, an Integer or Decimal Feature), the Feature has no initial value at runtime.

When the initial value of a Total or Count Feature is zero, configuration rules that involve these nodes do not propagate.
For Boolean Features, the initial value is essentially a default, which like all defaults can be overridden by the end user. Therefore, the end user can select a Boolean Feature that is initially Logic False and it will appear as User True in the runtime UI.  The Initial Value of a Text Feature is any default text that you enter. The end user can overwrite this text at any time.

New tab

Populators

You can define a Populator on a non-BOM node to automatically create child structure for that node using Items, Item Types, and Properties in the CZ schema's Item Master.

For example, you can create a Populator on Component X and specify the following criteria: "Create Options from Items where the Item is of Type 'Processor Speed'." Running this Populator creates a Feature for each Item that matches the specified criterion. In other words, if there are 10 Items in the CZ schema whose Item Type is Processor Speed, then the Populator creates 10 Features as children of Component X. By default, the nodes that a Populator creates have the same names, descriptions, and Properties as the data used to create them.

When you use a Populator to build Model structure from Items in the CZ schema's Item Master, any Properties and Property values that are associated with the Items are also associated with the new Model structure.

The primary benefit of using Populators is that Configurator Developer maintains a permanent link from the nodes that the Populator creates to the source data in the Item Master. Therefore, when data in the Item Master changes, such as when new options are added to an BOM Option Class in Oracle Inventory, you can update the Model simply by re-running the Populator (that is, after refreshing the BOM Model). This is called "repopulating" the Model. Additionally, if the source data no longer exists in the Item Master, repopulating the Model deletes the corresponding nodes.


You can delete a Populator, but it is important to remember that doing so also deletes any Model structure that was created by running the Populator.
The Properties section on a Model node's details page displays a table with two columns: Inherited and Imported. A check mark in the Inherited column next to a Property indicates that the Property was attached to the node by running a Populator.

Inherited Properties can be used in the same way as User Properties that you create manually (for example, when defining rules).
Note: You can repopulate one or more Models without logging into Configurator Developer by running an Oracle Applications concurrent program.

You can also create Model structure using Items and Item Types in the CZ schema's Item Master without using a Populator. Nodes created using this method are also linked to data in the Item Master, but they cannot be easily updated when data in the CZ schema's Item Master changes. Additionally, Properties and their values are not incorporated into the Model when you use Item Types to build Model structure.

New tab

Types of Nodes Created by Populators

A Populator can create structure on any Configurator Developer node that can have children. These include:

  • A non-imported Model
  • A Component
  • An Option Feature
You cannot define a Populator on a BOM Model, BOM Option Class, or BOM Standard Item. When you run a Populator, it creates new nodes as children of the node on which the Populator is defined.
The type of nodes a Populator can create depends on the node on which it is defined.

Tip: You can create nodes from an imported BOM item using a Populator. However, when you do this Configurator Developer does not maintain a permanent link from the nodes that the Populator creates to the source data in the Item Master. For example, to create an Option Feature from a BOM Option Class, define a Catalog Group in Oracle Inventory containing the Option Class's items. When you import the BOM Model, the Items in the Option Class are imported into the CZ schema and an Item Type is created in Configurator for the Catalog Group. You can then define a Populator that creates Options based on the Item Type's Items.

New tab

Moving and Copying Nodes with Populators

You can move a node that has one or more Populators from one location in the Model structure to another location in the same Model, or to another Model. When you do this, the node retains its Populator(s). However, when you copy a node, Configurator Developer does not assign any of the node's Populators to the new node. In this case, you must manually define the Populator(s) on the new node.

New tab

Configuration Rules

One of the most critical activities in constructing a configuration model is to design and construct the rules that govern what the end user can select to make a valid configuration. You need to define rules that express relations and compatibilities among the Components, Features, Options, BOM Option Classes, and BOM Standard Items in your Model. Configuration rules are essential in ensuring that a configured product can be ordered and manufactured successfully.
In a configuration model, rules identify Model elements that are:

  • Used as general defaults
  • Automatically selected when an end user selects another option
  • Permitted when an end user selects another option
  • Excluded when an end user selects another option
Types of Configuration Rules

 
Creating Rules
You create all types of rules (except Java code for a Configurator Extension Rule) in the Rules area of the Workbench. The steps to create a rule vary depending on the rule's type.

Rule Folders
In the Rules area of the Workbench, each Model contains a default Configuration Rules Folder. Within this Folder, you can create as many sub-Folders as you need to organize a Model's rules.
Rule Folders that you create can contain any type of rule. You can copy rules and move them from one Folder to another. However, the same rule cannot reside in more than one Folder. Copying a rule to a different Folder creates a new, separate rule that can be modified independently of the original.

Rule Sequences
A Rule Sequence is a set of rules that are active according to their order in the sequence, which is determined by each rule's effectivity dates.

Enabling and Disabling Rules
Enabling and disabling rules can be a useful tool when unit testing and debugging a configuration model. Rules that are disabled are ignored when you generate logic and when you unit test a Model in a runtime Oracle Configurator or the Model Debugger.
You can enable or disable any type of rule.

The Disabled column in the Rules area of the Workbench shows whether a rule is currently active. When you enable or disable a rule, Configurator Developer updates this column only after you regenerate logic.
 

New tab

Imported BOM Rules

Basic rules that are inherent in a BOM Model are imported and automatically applied in Oracle Configurator Developer. These rules include settings that indicate whether components in the BOM are optional or mutually exclusive, as well as any Quantity Cascade calculations. For example:

Required rules apply to child nodes that become required in the configuration when their parent node is selected. The name of this setting in Configurator Developer is "Required when Parent is Selected." For example, if this setting is Yes
for Option Class X, Oracle Configurator automatically selects it when the end user selects its parent BOM Model.

Mutually Exclusive rules apply to nodes that allow only one of their optional child nodes to be selected at a time. The name of this setting in Configurator Developer is "Optional Children are Mutually Exclusive." For example, if the options within a
BOM Option Class are mutually exclusive, an Oracle Configurator end user can select only one of them. This is similar to an Option Feature with a Maximum Selections of 1.

In Oracle Bills of Material, BOM Models that are children (components) of a BOM can be mutually exclusive. However, when you import such a BOM Model, Configurator Developer sets the Mutually Exclusive setting to No for each child (referenced) BOM Model. This is not an issue for most installations, and you can define rules that require a BOM Model's children to be mutually exclusive, if necessary.

In Configurator Developer, you can view how these rules are defined by viewing a BOM node's definition in the Structure area of the Workbench.

All of an optional BOM Model's required children have an initial logic state of Unknown. Any required child items under the root BOM Model have an initial logic state of true, due to the inherent BOM rules described in the preceding paragraphs.
Note that the root BOM Model cannot be optional, and any BOM item that is required has the "Required when parent is selected" setting set to Yes. 

New tab

Profiles

BOM: Automatic Reservation
This profile determines whether CTO attempts to reserve available on-hand when matching during autocreate configuration batch or online modes. If the profile is set to Yes, the program found a match, and the schedule date is within the number of days defined by the profile, OM: Reservation Time Fence, Autocreate Configuration attempts to reserve any quantity available on-hand.

BOM: Buy Cost Type
This profile determines the Buy Cost Type that is used during the Configuration Cost Rollup.
Important: This profile should not be set to CTO or clear (null). Create a user-defined cost type and update this profile value with that cost type.

BOM: Configuration Item Delimiter
When you choose any numbering method other than User Defined, Append with sequence, or Replace with Order, line number Numbering Method, the system inserts a delimiter before the sequence number or between the sales order number and line number. Use this profile to define the delimiter to be used by the system.
Anything can be entered as the delimiter character. Do not choose the same delimiter as the item segment delimiter if you have a multisegment item number. It will cause the configuration item process to fail.

BOM: Configuration Item Type
This profile indicates the user item type of the new configuration items created by the Create Configuration Item program. A typical setting is ATO item.

BOM: Configurator URL for UI Manager
In order to preconfigure items using BOM, this profile must be set to the proper URL for the configurator in your instance.

BOM: CTO Perform Cost Rollup
This profile determines if a cost rollup is performed when progressing an order to create a configuration item. The value of this profile also determines the default settings of the corresponding parameter in the AutoCreate configuration concurrent program.
This profile is optional. If the profile is null, a cost rollup is performed when a configuration item is created by progressing the sales order. However, the parameter in the AutoCreate Configuration concurrent program defaults to No.

BOM: CTO Perform List Price and Purchase Price Rollup
This profile determines if list price and purchase price rollup is performed when progressing an order to create a configuration item. The value of this profile also determines the default settings of the corresponding parameter in the autocreate
configuration batch program. This profile is optional. If the profile is null, a purchase price rollup is performed when a configuration item is created by progressing the sales order. However, the parameter in the AutoCreate Configuration concurrent program defaults to No.

BOM: Match to Existing Configurations
This profile controls whether a match is performed during AutoCreate Configuration, Create Configuration Item workflow activity, Match from Sales Order Pad, and match during PDS based ATP. If the profile value is Yes, the program uses the Enable Configuration Matching attribute on the model to determine if the match is performed. If set to No, then a match is not performed regardless of the setting of Enable Configuration Matching.

BOM: Model Item Access
Indicates if a holder of this responsibility can define and update bills of material for model and option class items.

BOM: Perform Lead Time Calculations
In a discrete manufacturing environment, this profile determines if lead time calculations are performed when progressing an order to create a configuration item.
The value of this profile also determines the default settings of the corresponding parameter in the autocreate configuration batch program. Lead time is not calculated if the configuration item has a flow routing, regardless of this profile.This profile is
optional. If the profile is null, a lead time rollup is performed when a configuration item is created by progressing the sales order. However, the parameter in the AutoCreate Configuration concurrent program defaults to No.

OM: Reservation Time Fence
This profile option controls automatic reservations during scheduling. The profile option represents the number of days into the future that scheduling will reserve. The default value is Null, which means that scheduling will not automatically reserve.
This profile option is used during autocreate configuration if the BOM: Automatic Reservations = Yes

OM: Use Configurator
This profile option determines whether the configurator window or the order management options window is used to select the options for all ATO and PTO Models (SL, ML) entered in order management.
Use the configurator window when you want to set up validation rules, or you want to use the Java interface to choose your options. Use the forms-based options window when you do not need validation rules, but just need to select options.
order is originally configured using the configurator through I-Store or another interface.

WSH: Retain ATO Reservations
This profile option controls whether or not reservations will be maintained when backordering an ATO item or model.
If the profile is set to Yes, then reservations will not be removed for backordered ATO items/Models, but will be updated to Unstaged.
If the profile is set to No, then the delivery detail status will be changed to N (Not Ready to Release) and reservations will be deleted. Note that you will lose the ability to track that this item was backordered and these items will not show up on the Backorder Detail Report or the Backorder Summary Report.

New tab

Preconfiguring Items

Invoke Oracle Configurator from within Oracle Bills of Material to create a configured bill of material and routings for a predefined ATO item. This is useful in a business to business environment where the same configuration is ordered repeatedly. Preconfigured items can be built to forecast and kept on hand. Customers can order the preconfigured items directly, as they would a standard ATO item.

Preconfigure BOM respects the new organization level BOM parameter Create Configuration BOM. An error message displays if you try to preconfigure in an organization where this parameter is set to No.

You can preconfigure multilevel structures within BOM in a manner similar to that done in Order Management. The configurator uses the item validation organization defined in the OM parameters form for the current organization to determine the BOM to present during the configuration session. Once the options are chosen, the sourcing rules on the models, the setting of the Create Configuration Item, BOM, and Routing attribute, and any Option Specific Source definition are used to determine the organizations in which to create the BOM and routings.

The profile option BOM: Use OM Validation Organization When Pre-Configuring Single Level Items determines whether the current organization or the OM validation organization is used when preconfiguring a single level BOM. Usually, this value
should be set to Yes.

The Preconfiguration process matches to existing configurations, if the profile BOM: Match to Existing Configuration is set to Yes, and the model is set to perform matching. If the program finds a match for the top-level model you will be asked if you want to use the matched item id or create a new configuration for the new item. If you choose to use the match, no BOM is created for the current item. If you choose to create a new configuration for the new item, the new configuration replaces the old configuration in the match tables, and future matches in OM or BOM will match to the new predefined
configuration.

If a match is found for any of the lower level models, the matched configuration item is used by default.

Enabling Items
It is recommended that you enable the preconfigured item in all organizations that require it for the configuration process. If you do not enable the preconfigured item, the preconfiguration process automatically enables it in all organizations identified by the base model's item attribute Create Configured Item, BOM, and the base model's sourcing chain from this organization.

These items are created as autocreated items by setting AutoCreated Configuration to Yes in these organizations. If you want these items to be treated as preconfigured items, enable them in all organizations before preconfiguring the BOM
deselect the configuration item attribute AutoCreated Configuration on the preconfigured item in all organizations.

When the item is automatically enabled in an organization, for attributes that have the attribute control set at the organization level, attribute values for these items are inherited from the base model in that organization. Item attributes are copied from the preconfigured item if the attribute control is set at the master level.

Note: Child configuration items are created as autocreated items with all attributes set as in Create Configuration Items.
If you want the child configurations to be treated as preconfigured items, you must either:

  • Preconfigure them before the parent configuration You must use the match functionality and then configure all levels ofconfigurations from the bottom up.
  • Clear the AutoCreated Configuration attribute on the configurations you want to treat as preconfigured items.
Note: For preconfigured items, because the item is created by the user, item attributes are not copied from or validated against the base model item attributes. It is up to the user to set them appropriately. The Assemble to Order and Build in WIP flag must be selected. It is recommended that you use the ATO item template for these items.

New tab

Sourcing Setup for ATO Models

Sourcing rules assigned to models are used during the planning of the model forecast, and during ATP of a model sales order. These same rules are used during autocreate configuration to determine the correct sourcing for the configured item. Once the configuration item is created, its sourcing rules are used for all planning and execution.





Option Specific Sourcing (OSS)
Option specific sourcing allows you to restrict the sourcing of a configuration based on a specific option or options that are ordered. For example, you may have a model that can be manufactured in three organizations. But if a specific option is chosen, it can be made only in one of the three, as they have the specialized machinery to build it.
If you have restricted options, specify the list of valid organizations and vendors where the model can be manufactured, stocked, transferred or procured, if that option is chosen. This list of organizations is overlaid with the model sourcing chain, during the ATP and Autocreate configurations processes, to restrict the sourcing of a specific configuration based on the options that were chosen.

This section is intended to give you a feel for situations in which you may need to setup  option specific sourcing for your models:
OSS setup is notrequired
There are three organizations, set according to regions of the world:
• Japan Org
• US Org
• Europe Org
The model is a Make item in all three, but the BOM in each is different, and contains only options pertinent to its respective region.
For previous releases, you manually chose the warehouse on the sales order based on where the order originated (or used OM defaulting rules to do so). In this case, CTO creates the BOM only in the org against which the order is placed. This is still true if the model's Create Configuration Item, BOM attribute is set to Based on Sourcing (the default). No further set up is required.

You can use this attribute even if you are doing PDS based ATP with matching, because the ship from organization is always defaulted, and there is no variation in sourcing once that organization is picked. No OSS setup is required. OSS setupis required The ATO model can be made in any of six manufacturing organizations, and you want the choice of the manufacturing organization to be based on GOP, rather then simple defaulting rules. However, if the customer chooses a specific option (for example a specific specialty coating for the product) it can only be made in Org1. Match is used on this model.

For 12.0, if you want to use GOP to pick the warehouse or want to match during ATP, the model's Create Configuration Item, BOM attribute must be set to Based on Model so that the item, BOM, and routing are created in all six manufacturing organizations, and future matches to the configuration item are valid and ATPable in all six manufacturing organizations.
If you do not set up OSS for the model with the specialty coating, CTO attempts to create the bill for these configurations in all six organizations no matter which one is shipping the material. Because the speciality coating option does not exist on the model BOMs in organizations 2-5, autocreate configuration completes with a warning and puts the order on hold for all sales orders with this option.

To avoid this, set up OSS for the Model with the specialty coating as a component to restrict ATP to choose only Org 1, and to restrict the BOM creation for that item to Org1. This is required even if you are not using ATP or APS.

New tab

Create and Process Configurations

Orders entered via iStore or Order Management can be configured using Oracle Configurator. Users enter a model on the order, then click Configurator to open the Configurator window to select options.

orders entered in Order Management can be configured using either Oracle Configurator or the Order Management Options
Window. The profile option OM: Use Configurator (which can be set only at site level and accessible from sys admin responsibility) determines weather you Configurator or option window in order management


The options displayed in the OM options window or in the configurator are based on the model structure in the OM validation organization. It is important that the entire model and option structure in the validation organization matches the structure in your manufacturing organizations. This can be achieved by either commoning all levels of your model and option class bills to the OM validation organization, or by ensuring changes to the model, option class, or options are made in all organization BOMs simultaneously. Standard, mandatory components can vary between organizations

Whether you use Oracle Configurator or the Order Management Options Window to select options or import a configured order, you can view and delete selected options along with their option classes from the Sales Order Pad line region.
The View Line Detail option from the Tools menu in Sales Order Pad lets you toggle between displaying the model line only or model line plus all the configuration detail.

Dropshipping Configurations
ATO items, Configurations and components of non ship model complete (SMC) PTOs can be dropshipped.
If you always dropship an item, you can designate it as a dropship item by setting up its supply source type to ‘External’ in on the OM tab in the item master. All orders for this item by default will be dropship orders. You can also explicitly choose the ‘External’ supply type on the order line in the sales order pad. Each line of a Non ship model complete PTOs may be dropshipped from a different supplier based on your sourcing rules.

As with standard items, planning can not be used for External ATO orders. You can not perform an ATP inquiry or reserve on-hand to a dropship ATO order. The  schedule date is defaulted from the request date. Shipsets or Arrival sets can not be drop-shipped.

New tab

PTO Cycle

KIT Steps

1.    Item Creation: Creae a KIT item by copying the KIT template.
Create 2 purchased items to be used as component of the KIT.

2.    Create BOM: Assign the two components to the BOM of the KIT item and make common BOM in the item validation organization.

3.    Price List: Add all the items to the price list.

4.    Enter the sales order: Enter a sales order line for the KIT item (Line Number 1.1). The price of the line would be the price as given in price list.
Once you save the line, child components ‘ll be attached automatically to the line with line number 1.1..1 and 1.1..2
Book the sales order.
All the lines with the component‘ll be assigned with the same fulfillment set


5.    Picking: The sales order ‘ll now be available in SE for pick release (only the lines with child item)

6.    Shipping: Ship the components

7.    Run the auto invoice to create the invoice

New tab