Configure-To-Order Setup White Paper R11

CTO – Configure to Order
A Guide to Key Application Setups

ORACLE WHITE PAPER | APRIL 2017
Table of Contents
Introduction 3
Configure to Order Functional Flow 3
Setup 15
Items 16
Item Classes 16
Item Specifications 18
Model Structures 23
Configurator 25
Work Definitions 25
Operation Items 26
Applicability Rules 27
Lead Time Calculations 28
Reports 28
Configured Item Work Definition and Work Order 28
Collections 29
Promising and Sourcing 31
Availability to Promise 31
Sourcing 33
Blanket Purchase Agreements 37
Pricing 40
Troubleshooting 40
FAQ 42
Conclusion 43
1 | CTO – CONFIGURE TO ORDER

Table of Figures
Figure 1: CTO Functional Flow ___________________________________________________4
Figure 2: Selected Options in Configurator __________________________________________5
Figure 3: Configuration Item Number _______________________________________________6
Figure 4: Check Availability of ATO Model and Options_________________________________7
Figure 5: Release Planning Recommendations _______________________________________7
Figure 6: Supply Order Access from Sales Order _____________________________________8
Figure 7: Supply Order 'Make' Flow ________________________________________________9
Figure 8: Supply Order 'Make' Execution Documents __________________________________9
Figure 9: Supply Order 'Buy' Flow ________________________________________________10
Figure 10: Supply Order 'Buy' Execution Documents__________________________________10
Figure 11: Manufacturing Dispatch List ____________________________________________11
Figure 12: Manufacturing Completion Confirmation ___________________________________11
Figure 13: Ship Confirmation ____________________________________________________12
Figure 14: Packing Slip (first pages) ______________________________________________13
Figure 15: Configured Item Invoice _______________________________________________14
Figure 16: Item Class: Configuration Item Number Generation __________________________16
Figure 17: Item Class Transactional Item Attribute Definition ___________________________17
Figure 18: Model Item Specifications - Manufacturing _________________________________18
Figure 19: Model Item Specifications: Sales and Order Management _____________________19
Figure 20: Model Item Specifications – Planning _____________________________________20
Figure 21: Model Item Specifications – Purchasing ___________________________________21
Figure 22: Model Item Categories ________________________________________________22
Figure 23: Model Item Structure __________________________________________________23
Figure 24: Model Item Structure - Optional Components _______________________________24
Figure 25: Enhancing model presentation in configurator ______________________________25
Figure 26: Work Definition - Visual Editor __________________________________________26
Figure 27: Collections - Items and Work Definitions __________________________________29
Figure 28: Collections - Approved Supplier List ______________________________________30
Figure 29: Refresh Repository ___________________________________________________31
Figure 30: Availability to Promise Rules - Criteria ____________________________________32
Figure 31: Availability to Promise Rules - Assignment _________________________________33
Figure 32: Sourcing Rules - Buy _________________________________________________34
Figure 33: Sourcing Rules - Option and Option Class Exclusions with Make Rule ___________35
Figure 34: Sourcing assignment: Make (local) rule ___________________________________36
Figure 35: Sourcing assignment - Buy (global) rule ___________________________________37
Figure 36: Blanket Purchase Agreement - CTO Template ______________________________38
Figure 37: Generate approved supplier from purchase agreement _______________________39
Figure 38: Hierarchical pricing of model items _______________________________________40
Figure 39: Manage configured Item exceptions at run time _____________________________41

Introduction
Configure to Order (CTO) is the process of ordering and fulfilling configured products. “Configured products” is an
umbrella term for pick to order (PTO) models, assemble-to-order (ATO) models and hybrid configurations (PTO and
ATO combined). Pick to order models consist of already manufactured products that are ready to be shipped either
from in-house inventories or sourced from suppliers’ warehouses. ATO models are always either procured or made
to order. Hybrid configurations are models that have both pick to order components and assemble to order
components.
Configure to Order Functional Flow

A model structure defines the list of options and option classes that customers can select when ordering a product
that can be configured. A model structure also can specify mandatory components or included items that are
required for each configuration of the model. One does not order or build the model itself, one orders and builds
configurations of the model. A model structure can be either assemble-to-order or pick-to-order, as noted in the
previous section. Note that a pick-to-order model can contain assemble-to-order components, but an assemble-to-
order model cannot contain pick-to-order components.
A configured item is the result of the choices that a customer makes at run time in configuring an assemble-to-order
(ATO) product. The unique final assembly based on order choices is modeled as a unique item. The configured
products, also referred as configured items, are either procured or made to order. Warehouses rarely stock every
set of options of an ATO model. Instead, they source the specific configuration required by a sales order after the
order is received. Sourcing choices include:
» Purchasing the configured item from a supplier (drop-ship or back-to-back delivery)

» Manufacturing the item to the specifications on the sales order (back-to-back delivery)

Figure 1: CTO Functional Flow
The sequence of processing at runtime is presented in the figure above and described in the following sequence of
operations:
1. A sales order is configured and submitted in Oracle Order Management Cloud. CTO orders can be
created in the Order Management UI or imported. If it is a PTO item with only standard components or a
drop ship sales order, all are fulfilled within Order Management.

Figure 2: Selected Options in Configurator
2. If it is an ATO item or a PTO item with at least one ATO component, Oracle Fusion Supply Chain
Orchestration checks the configuration to see if the corresponding configured item for the ATO component
was created previously. If not, Supply Chain Orchestration sends a request to Oracle Fusion Product
Model to create a new configured item.
a. If a match is found, the requested configuration selection is assigned the existing configuration
item name.
b. If a match is not found, a new configured item is created in PIM and the new configuration item
name is assigned to the configuration.
c. The organizations from which the item will be sourced are identified.
d. The configuration item name and organization are passed to the downstream applications.
i. Subinventories and locators
ii. Item transaction defaults
iii. Inventory consumption rules
iv. Units of measure, both intraclass and interclass

Figure 3: Configuration Item Number
3. Then, Oracle Fusion Global Order Promising generates a supply recommendation and schedule.
a. Promise assemble-to-order (ATO), pick-to-order (PTO), and hybrids (ATO within PTO).
b. Consider model, option class, and option lead times when determining lead time for the
configured item.
c. Consider resource capacity and availability for manufactured configured items when promising.
d. Consider existing availability of matching configured items before promising an order.
e. Consider option-specific and option class-specific sourcing exclusions.
f. Generate supply recommendations for configured items marked back-to-back.
g. Support drop ship promising of configured items.
When one checks availability in Order Management Cloud, one sees details of the order promise as
seen in the screenshot below of the Check Availability page. The multi-level lines for the model
appear. Global Order Promising also shows you the lines for the mandatory components that are
associated with the model, which are not visible in Order Management. As in any other order, one
can change input attributes of the sales order on the Check Availability page to simulate order
promising. However, one can edit attributes only at the model level. If similar configurations already
exist, then the names of these configurations are passed to Global Order Promising by Order
Management Cloud and are seen in the Configuration Item field. Global Order Promising tries to
consume supply for these configuration items before trying to promise using capable to promise
(CTP) functionality.

Figure 4: Check Availability of ATO Model and Options
4. Oracle Supply Chain Planning Cloud uses the sales order data in planning for component availability.
Planning recommendations are released and supply requests created through a scheduled process.
Figure 5: Release Planning Recommendations

5. If the item is to be drop-shipped, Order Management creates a procurement request which will also include
supplier shipment to the customer. Otherwise, for back-to-back shipment, a supply request is created.
Figure 6: Supply Order Access from Sales Order
6. Supply Chain Orchestration then creates the supply request documents for the configured item and
delivers them to the appropriate application,
a. Oracle Fusion Manufacturing (Back-to-back Make) or
b. Oracle Fusion Purchasing (Back-to-back Buy).
c. In certain cases, the exact configured product may be available in another warehouse location.
Global Order Promising may recommend that supply be transferred to the appropriate
warehouse or be shipped from the location where it is currently available. Supply Chain
Orchestration creates the supply request documents and delivers them to Oracle Fusion
Inventory Management, if a transfer is recommended.
d. A Reservation is also requested with Oracle Fusion Inventory Management for the requested
supply.
e. Users can view the supply order details and information regarding the related supply request
documents by clicking on the Supply Order Number link on the sales order.

Figure 7: Supply Order 'Make' Flow
Figure 8: Supply Order 'Make' Execution Documents

Figure 9: Supply Order 'Buy' Flow
Figure 10: Supply Order 'Buy' Execution Documents

7. Supply Creation
a. Manufacturing builds the item and delivers to the inventory location associated with site.
Figure 11: Manufacturing Dispatch List
Figure 12: Manufacturing Completion Confirmation
b. Purchased supply is received (inspected, put away) into inventory and readied for shipping to
customer. A configured item is usually intended for a specific customer sales order. Therefore, it
can be automatically picked and moved directly to a shipping lane from receiving, rather than put
into stock. The receiving agent has visibility to the associated sales order. The configured item

does not require any unique processes or special treatment to be transacted in logistics
applications.
Note that the details of the configuration, including the base model and optional components, are
captured and communicated to the supplier as structured data on the purchase order.
8. Shipping: The details of the configured product are printed on the packing slip and commercial invoice
throughout the receiving, inventory, and shipping processes. This helps avoid confusion when shipping
configured products because the contents of the shipment are indicated on the documents. ASNs that are
sent by suppliers, third-party logistics providers, and internal material transfer shipping organizations are
used and supported for configured items.
Figure 13: Ship Confirmation

Figure 14: Packing Slip (first pages)

9. Invoicing: Configured item details are also available on the invoice, allowing the customer to view details
related to charges.
Figure 15: Configured Item Invoice

Setup
The following are the core Cloud applications that support the functional flow presented in the previous section. Not
all of these applications have required setup activities. Some do not require setup at all and for some, setup
activities are optional, depending upon the functional run time requirements.
» Oracle Supply Chain Management Cloud

» Product Model
» Configurator
» Pricing
» Supply Chain Planning (includes Global Order Promising)
» Order Management
» Supply Chain Orchestration
» Global Order Promising
» Common Work Setup (Manufacturing)
» Purchasing
» Inventory Management (Shipping & Receiving)
» Cost Management
» Oracle Financials Cloud
» Receivables
The following section provides more detail about required and optional setup activities, starting with an ordered
checklist to provide an overview and to place the setup activities within the appropriate applications.
1. Items (Setup Manager/Product Model/Configurator)
a. Item classes
b. Component items
c. Option classes
d. Models
e. Model structures
f. Configurator
2. Work Definition (manufactured items only – Manufacturing)
a. Release 11 – 1 hierarchy level of model
b. Separate work definition for each included ATO or assembly that is a manufactured item
3. Collect Items, Item Structures, Work Definitions; Refresh Repository (Planning)
4. ATP & Sourcing – items must be collected first (GOP)

a. ATP
i. Supply chain (component) availability
ii. Model, components, category
b. Sourcing
i. Make – local, manufacturing org
ii. Buy – global or local
iii. Exclusions based on options or option classes
c. Sourcing Assignment
d. Refresh Repository
5. Blanket Purchase Agreement (Purchasing)
6. Pricing – model and components for order management (Pricing)

7. Submit sales order to create configuration item (Order Management)
Note that one can add additional setup for costing details, add more elaborate configurator rules for display, and so
on. Shipping and invoicing setups are no different than for standard products. Forecasting and planning can take
component availability into consideration as well as margin and lead time tradeoffs.
Items
Before creating an ATO or PTO model, all of the component standard options and option classes should be
available so that the model structure can be assembled easily. Option class structures are created in a similar
manner to models. It is just the initial item creation template that differs. The item class that will also be used for the
model should also be created before the model itself is created, but since there are specific aspects that affect the
behavior of the model, they will be described here.
Item Classes
Figure 16: Item Class: Configuration Item Number Generation
The first setup requirement is to ensure that an appropriate item class exists for the model and that the item number
generation details are properly populated. Key fields on the setup screen above are:
» Item Number Generation Method: Inherited from Parent, Rule Generated, Sequence Generated, User Defined
» Configured Item Number Generation Method: None, Sequence
Required Details:
» Starting Number: e.g., 100

» Increment By: e.g., 10

Optional Details:
» Prefix Type: Model Item Number, None, User Defined

» Suffix Type: Model Item Number, None, User Defined
» Delimiter: Asterisk, Hash, Hyphen, None, Underscore
Based on the selections in italics above (also shown in the figure below), configuration items based on the model
item AT6751000 would have item numbers such as AT6751000*120*, AT6751000*130*, AT6751000*140*.
Figure 17: Item Class Transactional Item Attribute Definition
During the sales order entry process, customers may select from a list of configurable item attributes when selecting
their specific configuration. These attributes can represent a color, some personalization such as a monogram or
any attribute established for the item that does not warrant a separate component specification. Transactional item
attributes (TIAs) represent these factors and are set up as part of the item class. They are inherited by any child
classes, so it is a good idea not to place them on the root item class. They actually constitute a separate
hierarchical entity and are carried through order management, but may not be supported by all fulfillment systems.
They can be utilized to create unique configurations for a model, but care should be taken during the design process
so that an excessive number of records are not created at run time if that level of specificity is not really warranted.
When setting up a TIA, the user must specify both a name and a display name. There are several data types listed,
but in Release 11, the only the Number and String data types display in the product configurator. It is a good
practice to select a value set because that will provide validation during the configurator session. These can be set
up using the FSM task, Manage Value Sets. An enumerated value set will even provide a pick list for customer
selection of values. Note that numerical values sets must have the minimum and maximum values set or
configurator will throw and error when the model snapshot is imported..

It is important to set the correct set of application scopes for each TIA. The figure below is a screenshot of the
setup. The first 4 application scopes – Distributed Order Orchestration, Order Entry, Configurator, Pricing – are
required if one is using order management. Configuration Matching is required if the TIA selection on the sales
order grants uniqueness to the item. In this case, a new configuration item will be created for each unique TIA value
for that attribute and the TIA value will be saved along with the option selections for the configured item.
Configuration Matching is required if a TIA is intended for use in a work definition. Both Configuration Matching and
Manufacturing Execution are required if a TIA is intended for use in a work order.
Note that if you add TIAs to your item class for selection at run time, you must import the model into the product
configurator and release a workspace before the TIAs will be visible for configuration in order management.
Item Specifications
Figure 18: Model Item Specifications - Manufacturing
The figure above provides the details of the general and manufacturing specifications for an ATO model. The
following are the important parameters to set:
» Structure Item Type: Model

» Autocreated Configuration: No
» Pick Components: No

» Assemble to Order: Yes
» Build in WIP = Y (if the item is to be manufactured)
Note that for a PTO model

» Structure Item Type: Model
» Autocreated Configuration: No
» Pick Components: Yes
» Assemble to Order: No
» Build in WIP = N
Figure 19: Model Item Specifications: Sales and Order Management
The sales and order management specifications for an ATO model item are shown in the figure above. The item
must be shippable, orderable and invoiced. Unless a drop shipment flow is used for an ATO model, the Back-to-
Back Enabled flag must be set to Yes.
For a PTO model item, the shippable flag is set to No because the model itself only represents the collection of
items to be shipped and is not shipped itself. The Back-to-Back Enabled flag is also set to No for a PTO model item.
Note that order management only supports shipping all PTO model items together from the same warehouse, so the
Ship Model Complete flag must be set to Yes. This is not relevant for an ATO model as it is a single item.

Figure 20: Model Item Specifications – Planning
The primary specification to set at the model level if one intends to use forecasting for ATO items and their
components is Forecast Control, which should be set to Consume then Explode. To cause the model, option
classes, options and components to appear in Planning Central, then in PIM on the item attribute Planning section,
under MRP/MPS Planning, set Planning Method = MRP Planning or MPS Planning at each level.
The planning percentages for the option class and the options are maintained on the item structure and can be seen
in the figure in the section below on creating model structures. Planning uses these percentages which it gets from
the organization-specific item structure or bill of material.
Users can create and process organization-specific forecasts for ATO models in Oracle Planning Central Cloud.
» Generate statistical forecasts for ATO models: Use shipment and booking history to forecast.
» Consume model forecasts: Sales orders for configured products consume model forecasts.
» Explode remaining model forecast: Generate production forecasts for option classes and options.
» Create supply for organization-specific forecasts: Source components and subassemblies using
standard planning sourcing rules.

Figure 21: Model Item Specifications – Purchasing
The purchasing specifications for a CTO model are displayed in the figure above. The model and all of its
components, including the option classes, must have the Purchasable flag set a Yes and a default Purchase Price
must be set for the model item itself. Other parameters are optional.

Figure 22: Model Item Categories
The figure above shows the categories to which the model item is assigned. For ATO models, when the
configuration item is created at run time, the standard categories assigned to the model will be copied to the newly
created configured item. It is important to ensure that if a catalog is configured for single assignment that the item
not be set up multiple category assignment or an error will occur during configured item generation at run time. The
configured item will usually be created, but additional downstream processing may fail. Corresponding errors can
be found in the SCO CTO tab (see troubleshooting).
Catalog information is also used to facilitate promising for newly created configuration items. When assigning
categories to the model, ensure that one of the catalogs is assigned to the Global Order Promising profile “Catalog
for Sourcing Assignments.” A callout to the Vision Slimline category, for example, says to ensure that models are
assigned to an ATP rule using this category. This way each configured item does not have to be assigned
individually to an ATP rule.

Model Structures
Figure 23: Model Item Structure
Mandatory components, options and options classes are added to the model on the Structures tab of the Item
definition. It is important to have all of these components created in advance so that they can be added to the
model structure easily. Otherwise, model creation will be interrupted so that the missing component can be created.
Only one level can be added, so the structure is essentially built from the bottom up with lower level components
built first and then inserted into their assemblies (standard items) and option classes (models). For example, in the
figure above, the highlighted option class and its standard item components would be added as a single unit using
the Select and Add action.
Option classes are created in the same manner as models, except that they start with a different template. Refer to
the Product Model documentation for more details. Multiple levels of nesting of assemblies (for standard items) and
multiple levels of ATO models and option classes (for ATO models) are supported. PTO models containing ATO
component are also supported.
To the far right of the figure you can see the Planning Percent column. This attribute was mentioned previously and
is used to identify what percentage of the each selection in the option class should be used for forecasting. In the
highlighted example, there are two possibilities, one weighted at 70% and one at 30%. Note that the values must
sum to 100%.

Figure 24: Model Item Structure - Optional Components
There are additional parameters to set for the model structure. It may be necessary to open the View dropdown
menu to expose additional subsets to the UI in order to access these parameters. One of the most critical subsets is
the Component Order Management set where one specifies whether a component is optional or mandatory and the
quantity range that is allowable. Once the parameters are visible on the screen, select the child item and then use
the edit button to bring up the popup window where you can set the value.
If a model component is mandatory (optional = No) at any level, it will not show in the product configurator at run
time or on the sales order or be part of the configured item definition. Downstream, it will not be on the purchase
order, but it will be part of the work order if it is a manufactured item. This is because it is considered part of the item
structure and it has no part in the customer’s selection process.
If an option class is set as mandatory (optional = No), it will show in the product configurator because the customer
still needs to make an option selection. At least 1 option under the option class should have the Optional flag set to
Yes for this to be true. Note that it is not necessary to have an option in an option class. It can have another model
item as its parent.

The minimum and maximum number of choices allowed for an option class are also set under Component Order
Management. Note that if the Optional flag is set to Yes, the minimum only applies if the customer selects the
option. If the component is not optional the minimum and the maximum are the same because the component is
essentially selected by the system.
Configurator
Figure 25: Enhancing model presentation in configurator
After the model structure is complete, the model can be imported into Configurator to set up rules and to enhance
the run time UI for the configurations. Refer to the Product Model and Configurator documentation for more details
on these setup requirements.
The first time that a model imported, the Import Snapshot action on the Manage Snapshots task should be used to
make the model available for further enhancement. This will create the initial workspace for viewing, modifying, and
testing the model. If the model contains TIAs (transactional item attributes) the snapshot must be imported and the
workspace released (at a minimum) in order for the TIAs to be visible and active in order management at run time.
If any changes are made to the model or to the item class after the workspace has been released, it is important to
refresh the snapshot and the other objects in the workspace. It will be necessary to create a new workspace to test
and release before the changes will be available at runtime. Make sure that the item class is refreshed and added
as well as the model, especially if there have been changes to TIAs.
Work Definitions
An ATO model work definition defines the manufacturing process to build any of the resulting configured items. It
consists of operations, items, and resources. In the configured item fulfillment flow, the configured item work order is
created dynamically based on the primary ATO model work definition, that is, the work definition with Production

Priority = 1. Transactional item attributes (TIAs) are supported in ATO model work definitions and configured item
work orders.
Operation Items
In an ATO model work definition, you can define an operation either as mandatory or option dependent. A
mandatory operation always is included in the configured item work order. An option-dependent operation is
included in the configured item work order if the optional components that are assigned to the operation are selected
in the configuration or if the criteria as defined in the applicability rule associated with the operation are met.
An ATO model work definition must use the primary structure of the model. The item structure visualization displays
only the first-level components of the ATO model, which are either option classes, optional components, mandatory
components, or child ATO models. These first-level components must be assigned to the operations. If an option
class is assigned to an option-dependent operation, then the operation is included in the configured item work order
if any of the options under the option class is selected. Splitting the quantity of a component to multiple operations
and ad hoc item assignments (items that are not components of the ATO model structure) are not allowed for ATO
model work definitions.
Planning Percent and Operation Item are operational material attributes that are specific to ATO model work
definitions. These attributes are referenced from Oracle Product Model and cannot be updated.
Figure 26: Work Definition - Visual Editor
The figure above presents the visual work definition editor. Six operations have been created for this work definition,
starting with Tablet Assembly and ending with Tablet Packing. Each operation can have model components and
manufacturing resources assigned.
If the vertical tab selected is the Item Structure tab, then one can view the components of the ATO model item
structure that are available for assignment at the right of the figure. If the vertical tab selected is the Resources tab

(below the Item Structure tab), then one can view the resources that are available for assignment. The work
definition region shows that two resource selections have already been made for operation 30, one for a piece of
equipment and one for an operator.
Applicability Rules
An applicability rule can be assigned to an option-dependent operation. This means that the operation should be
included in the configured item work order only if the rule criteria are met. For example, Operation 21 Test Rear HD
Camera is applicable only if the option Rear HD Camera is selected.
One can create an applicability rule using an option class, optional component, a transactional item attribute, or any
combination of these elements. The application displays the component hierarchy of the selected item or
transactional item attribute in the rule text. It is important to assign only optional components or an applicability rule
to an option-dependent operation. If both are assigned, then the applicability rule is not evaluated.
The multilevel structure of the ATO model is available when one defines an applicability rule. Current and future-
effective components and transactional item attributes appear based on the work definition as-of date. From the
first-level components, the option classes can be expanded to view the lower-level optional components. If
transactional item attributes exist, then they appear as child nodes of the component, and expanding the
transactional item attribute node shows the attribute values. Note that the transactional item attributes that
applicability rules use are defined with application scope “Configuration Matching.” If they do not have this
application scope, they are not available to manufacturing.
You can define an applicability rule using transactional item attributes with either numeric or string data type, as long
as the associated value sets have a validation type of either independent or subset.
For numeric attributes, the valid operators are:
» Equal to
» Not equal to
» Less than
» Less than or equal to
» Greater than
» Greater than or equal to
For string attributes, the valid operators are:
» Equal to
» Not equal to
» STARTSWITH
» ENDSWITH
» CONTAINS
» DOESNOTCONTAIN
Item and transactional item attributes can be combined in rules to build complex expressions using AND and OR
conditions. As an example, one can create the following rule: If the option selected is Rear HD Camera AND the
Edition selected is Premium. The system automatically displays the component hierarchy of the item or transactional
item attribute in the rule text when a rule is created using the drag-and-drop action or contextual action.
In this example, if the ATO model is AS49000C, the Camera option class is CM65011, and the Rear HD Camera
option is CM65002, then for the rule above, the rule text displays the following: ITEM=‘AS49000C’.
‘CM65011’.’CM65002’ AND ‘AS49000C’TRANSACTIONALATTRIBUTE[“Edition”]=“Premium”.

The rule is validated to ensure that the rule engine can understand and process it. If the validation fails, then an
appropriate error message is displayed. The error must be corrected before the rule can be saved.
Lead Time Calculations

After the ATO model work definition is complete, the same scheduled process that calculates standard item
manufacturing lead time can optionally be submitted to calculate the ATO model lead time. Ensure that the Include
ATO Model parameter is set to Yes. The scheduled process updates the fixed, variable, and processing lead times
in the item master. Manufacturing does not support configured item manufacturing lead time calculation. The
application copies the ATO model lead time to the configured item lead times during the configured item creation
process.
Because the ATO model lead times may be highly inflated, consider updating the configured item lead time
manually in the item master. You can enter more realistic values based on manufacturing history.
Reports
The work definition report is most useful to help verify that the work definition is set up correctly. It presents the
complete view of a work definition, grouped by operations. For each operation, one can view the assigned materials
and resources, along with their attributes.
For printing the report using the scheduled process, ensure that the Assemble to Order Model Attributes parameter
is set to Yes. It is then possible to view operation attributes that are specific to an ATO model work definition, such
as Option Dependent, Planning Percent, and Applicability Rule. For the operation materials, it is possible to view
whether a component is an optional component, and the planning percentage for it. If printing the report from the
work definition user interface, then the Assemble to Order Model Attributes parameter is defaulted to Yes.
Configured Item Work Definition and Work Order

A configured item work definition is created dynamically based on the primary ATO model work definition
(Production Priority = 1), selected options, and transactional item attributes. The work definition header is created
based on the base ATO model work definition header. All the mandatory operations, mandatory components, and
related resources are included. Based on the options and transactional item attributes that are selected during the
configuration process, the application also includes the corresponding option-dependent operations, along with the
optional components and related resources. The application also explodes standard items with supply type as
phantom under the ATO model and includes the components that make up the phantom according to the item
structure. The configured item work definition is not stored. One cannot search for a configured item work definition
on the user interface.
The configured item work order is then created based on the configured item work definition. The Build in WIP
attribute for the configured item must be Yes to allow work order creation. When the work order is completed, the
reservation is transferred to Oracle Fusion Inventory Management.
The transactional item attributes that the configured item work order and execution user interfaces display are
defined in the Product Model for an item class with application scope "Configuration Matching" and "Manufacturing
Execution." The Configuration Transactional Attributes region appears on the page only if you select a transactional
item attribute value during the configuration process. If the transactional item attribute value is translatable, then the
translated value appears on the page.
You can view the transactional item attributes in the following places on the user interface:
» Work Order Header

» Edit Work Order Operation
» Complete with Details

Collections
At run time, Global Order Promising provides real time availability-to-promise and sourcing decisions while a sales
order is being placed. It also allows the user to explore trade-off scenarios to increase margin and/or customer
responsiveness in delivery decisions. To do this, an extremely well-tuned engine containing the most up-to-date
supply and demand data is required.
Through data collections, the application takes data from various other Oracle Cloud modules into Oracle Supply
Chain Planning Cloud and Global Order Promising. Global Order Promising collects the following types of data:
» Static: Such as structures, routings, suppliers, and transit times
» Dynamic: On-hand supply and purchase orders also are collected from other Cloud modules.
The data contained within this engine must be refreshed periodically because it is an in-memory engine. During the
initial setup, several rounds of targeted collections are run to bring in organizations, items, and other business data
so that they will be in the correct context with their reference keys. As new items are added, they and their
structures must be collected, along with their work definitions if they are to be manufactured. The Net Change
setting, as shown in the figure below, is sufficient for the newly added items as the previously added items have not
changed.
Figure 27: Collections - Items and Work Definitions
New configured items that are created during sales order processing are not automatically refreshed within Global
Order Promising. Therefore, at an established frequency, they must be collected as well.

Figure 28: Collections - Approved Supplier List
Other entities have to be collected as well to support the end-to-end processing of configure to order items. Once a
blanket purchase agreement has been set up and approved for a supplier and the supplier added to an approved
supplier list, the approved supplier lists need to be updated through collections. The selections for the collections
service can be viewed in the following figure.

Figure 29: Refresh Repository
Finally, any time that collections have been run or that promising or sourcing rules have been created or updated,
the order promising server data must be refreshed. Data that are collected into Supply Chain Planning are
refreshed in Global Order Promising only when the Global Order Promising server is restarted using the “Perform
order promising server data refresh” scheduled process. The Global Order Promising architecture ensures
continuity of order promising, even when its data are being refreshed.
Promising and Sourcing

Global Order Promising promises orders that are received from Order Management Cloud using supply chain
network data and supplies that are collected into the application using collections programs, as specified in the
previous section. Order promising is based on rules that are created within Supply Chain Planning Cloud.
All data are collected into the Supply Chain Planning data repository. The Supply Chain Planning data repository
also stores setups made within Global Order Promising, such as sourcing, available-to-promise, and supply
allocation rules. Promising and sourcing work together to define what can be made available to a customer within
the requested timeframe of a sales order.
Availability to Promise
Global Order Promising enables companies to promise sales orders in different modes:
» By assuming infinite availability for items that are not constrained

» Based on lead times for items that have a very reliable supply chain
» By looking at detailed supply availability

Figure 30: Availability to Promise Rules - Criteria
ATP rules must be set up and assigned to models, option classes, and options before the items configured from the
models can be fulfilled. The recommended Promising Mode for CTO is ‘Supply chain availability search’. This
setting informs the availability engine that it should take supplies of components into consideration when promising
the availability of configured items. For manufactured ATO models, to allow Global Order Promising to consider
components and resources when promising an order, enable the ATP rule criterion called Search Components and
Resources.
The time fence specifies the point beyond which the configuration can be considered generally available. It is often
set to a lead time in excess of what is customary to allow for smooth processing of advance orders.
At run time, depending on which option classes and options are selected for a model, Global Order Promising
dynamically determines the lead time that is associated with the model and all of its applicable components
(selected and mandatory). To determine lead time, Global Order Promising traverses various paths within the item
structure and determines the longest path to determine the lead time associated with the model. Global Order
Promising considers the fixed and variable lead times that were modeled for items across the model structure. The
lead time that is associated with the model influences order promising behavior. For example, if a sales order for a
model is requested today, and there are no existing supplies, then Global Order Promising ensures that the sales
order is promised only on or after the model lead time.
A similar setup can be used for promising PTO models. Only PTO models with the Ship Model Complete flag set to
Yes are supported, so all components must be available on a specific date before the model can be promised for
that date. If there is a delay in the warehouse later in receiving some components a decision may be made to ship
the items that are already available. That action will lead to a remnant situation which may need special processing
and that has nothing to do with promising.

Figure 31: Availability to Promise Rules - Assignment
All components of the model must have an ATP assignment at some hierarchical level. ATP rules for models should
be assigned at the category level, which enables configured items to be recognized by the same ATP rule
assignment. The other levels are: Item, Organization, Item and organization
When configured items are created at run time, they are also automatically associated with the same categories to
which the model items belong. During item setup the model and thus configured items should be associated with a
category within the same catalog that Global Order Promising uses through the Catalog for Sourcing Assignments
profile attribute. Associate the model item with a category in this catalog, and use the same category to assign the
ATP rule to models (and thus to configured items). This setup ensures that when you create configured items,
Global Order Promising recognizes them after they are collected, without requiring them to be assigned explicitly to
an ATP rule.
Sourcing
Sourcing rules provide the information required to determine where and under what circumstances a model and its
components can be made available to a customer. Sourcing types include buy, make, and transfer. Since ATO
models are not kept in inventory, but made to order, the transfer type is not a primary option for the root item, but
may be used for component sourcing.

Figure 32: Sourcing Rules - Buy
If the sourcing type is ‘Buy from’, the Organization Assignment type for the rule can be either Global or Local. This
kind of rule is normally used for an ATO model or components of ATO or PTO models. Another sourcing type that is
available is ‘Transfer from’, but that is usually used for made-to-stock items such as components. The supplier must
also be provided if the sourcing type is ‘Buy from’. If there is more than one supplier, then a separate sourcing rule
must be set up for each supplier.
Global sourcing rules define from where sales orders will be fulfilled or shipped. Global sourcing rules are not
defined at any specific organization. They contain only transfer or buy sources. The buy sources correspond to drop
ship suppliers. Local sourcing rules define how additional supply can be created at an internal organization. Local
sourcing rules are created at an org, by definition. They contain transfer, buy, and make sources.

Figure 33: Sourcing Rules - Option and Option Class Exclusions with Make Rule
The incremental functionality when defining sourcing for CTO is the ability to define exclusions for options and
option classes. This is presented here in the context of a ‘Make at’ sourcing type, but it can also be used with a ‘Buy
from ‘ sourcing type. Global Order Promising respects sourcing exclusions when promising a sales order. As in the
above example of the Edit Sourcing Rule page and Manage Exclude for Option and Option Classes window, you
can specify sourcing to allow manufacturing and transfer of the model from a particular organization (002) in all
cases, except when the model has the Vision Tablet Accessories (ATO) option class selected. Use this window to
specify exclusions either at the option class or option level.
Note that this is a local sourcing rule. Only by setting the Organization Assignment Type to Local at the top of the
screen does the Type ‘Make at’ become available in the pick list for the actual sourcing rule.

Figure 34: Sourcing assignment: Make (local) rule
In general, sourcing rules can be reused and can be assigned at multiple hierarchical levels, as shown in the figure
above. Global Order Promising considers the sourcing rule associated with the most granular assignment level and
fulfills sales orders only from sources corresponding to this sourcing rule. Ensure that there is at least one sourcing
rule assigned at the global level, however. Supported assignment levels:
» Global
» Region
» Demand Class
» Customer
» Customer/Site
» Category
» Category-Region
» Item
» Category-Demand Class
» Category-Customer
» Category-Customer/Site
» Item-Region
» Item-Demand Class
» Item-Customer
» Item-Customer/Site

Figure 35: Sourcing assignment - Buy (global) rule
For drop shipment of ATO model items or PTO model component, ensure that a global sourcing rule is in place for
the items that will be shipped. For PTO items, all components must be sourced from the same supplier.
Blanket Purchase Agreements

In the supply order flow, after global order promising determines that a sales order must be fulfilled by an external
supplier, SCO sends purchasing a requisition and then after successful processing of the requisition, a request is
sent to create a purchase order. A purchase order can be created manually, but for automated creation, a blanket
purchase agreement (BPA) must exist. The price of the configured item is calculated from an existing blanket
purchase agreement. To create a blanket purchase agreement that covers any configured item derived from an
ATO model:
» Select the Configure to Order Blanket Purchase Agreement document style.

» Select or enter the supplier and site.
» Add a base model to the agreement and specify a price for it.
» Add options to the agreement and specify prices for them.
Note that one cannot combine ATO and standard items on the same BPA, so to cover all of the components of a
PTO model, two blanket purchase agreements may be required. ATO models require the CTO-based template and
an additional BPA may be needed to cover any standard items that are PTO components.
Blanket purchase agreements store prices for ATO models and options that are used to procure configured items.
Because a blanket purchase agreement contains only the models and options, the purchase price of the configured
item is calculated each time it is procured externally, ensuring that the most accurate prices are considered in the
calculation. Note that all model options must be added to the blanket purchase agreement for it to be valid. Option
classes and mandatory items are not added.
When creating a blanket purchase agreement for configured items, ensure that the document style that is selected is
enabled for configuration ordering. Document styles allow organizations to control the look and feel of the
application to match the usage of the purchasing document. A document style that supports purchased configured
items is available by default. If, however, a new document style is needed, set Configuration Ordering Enabled to

Yes before creating the blanket purchase agreement. This field enables the Parent Item and Top Model fields that
are applicable for this type of purchase to be displayed.
Figure 36: Blanket Purchase Agreement - CTO Template
By default, the Configure to Order Blanket Purchase Agreement style is available to use. This style provides the
ability to specify whether the price of an option is specific to a parent item or to a top model. A top model is the item
from which the configured item is built.
The following additional attributes can be found on the Configure to Order Blanket Purchase Agreement document
style:
» Parent Item: The buying organization's identification number or code for the immediate parent item that is
associated with the option or submodel
» Top Model: The buying organization's identification number or code for the top model item that is associated
with the option or submodel
» Price: The purchase price for the model or option as negotiated between the buyer and the supplier. For
blanket purchase agreements that are used to price and source configurations, the price can be zero or a
negative value to reflect discounts. If you provide a price for an item that is associated with a parent item or top
model, then the price takes effect only when the item is included with the specified parent item or top model.

Price is a required field, but Parent item and Top Model are both optional. Note that negative pricing, providing a
discount for a component when it is part of a model, is also allowed. An example of this practice can be seen in the
figure below. Note also that you can use both parent item and top model in approval rules to route these
agreements to specific individuals.
Figure 37: Generate approved supplier from purchase agreement
Once the blanket purchase agreement has been created, one can optionally add the supplier to the approved list for
provision of this item through the task, Generate Approved Supplier List Entries. The agreement number is one of
the arguments for this service, as shown in the figure above. Once this service is complete, collections must be run
again, as described in the planning section, this time for the approved supplier lists.
This is one of the steps required to allow tracking supplier capacity or a supplier specific lead time. Once the
approved supplier list (ASL) is created one must also:
» Collect ASL to planning (see selection on collections).

» Use CSV upload to upload a supplier calendar, supplier lead time and supplier capacity to planning.

Pricing
Figure 38: Hierarchical pricing of model items
The figure above presents an example of setting up pricing the components of an ATO model for use on sales
orders. The pricing application displays the hierarchy for an ATO or PTO model so that the user can designate
component pricing in context. If a component were to be present in more than one position in the hierarchy, it could
actually be priced differently. This allows for differential pricing strategies based on component usage. During
setup, the user searches for the root model item and then drills down through each level of components to set the
pricing. Base Price, Calculation Method (defaulted), and Start Date must be set for each component, although the
value may be zero. Prices are not set for option classes.
Troubleshooting
1. Symptom: Transactional Item Attributes (TIAs) do not display in order management/configurator.

Explanation: The default configurator UI for a model does not include TIAs. The model must be imported
into the product configurator to expose the TIAs so that they may be populated at run time.

Resolution: Configurator: Manage Snapshots task - Import the model into the product configurator (Import
Snapshot) and release the workspace if it is a new model. For models that have been revised, update the
item class then add it and the model to an unreleased workspace, then release the workspace.
2. Symptom: Error in configured item generation, sales order remains in draft status.
Explanation: If the configured item itself cannot be created, then the sales order is rejected. After you
correct the cause of the error, Order Management must resubmit the sales order which will resubmit the
configuration matching request.
Resolution: Some investigation is required to determine the root cause of the error. If all systems are on
line, it is likely to be a setup error. Examine the error message and revise the item setup. (Product Model:
Manage Items)
3. Symptom: Error in configured item generation, but sales order is submitted

Explanation: The configured item was created, but an error occurred in additional background processing
of the new configured item.
Resolution: Supply Chain Orchestration: Manage Configured Item Exceptions tab
Figure 39: Manage configured Item exceptions at run time
If the item is created but the rest of the processing associated with creating a new configured item is not
completed, then the sales order is not rejected but an exception is logged in Supply Chain Orchestration.
One can view these exceptions on one of the three main tabs of the Supply Chain Orchestration
application. Once the root cause of the issue is identified and fixed, one can resubmit the configured item
to finish the data processing. Alternatively, exception can be ignored, the tasks were completed
manually. The following fields display details of each exception:
 Base Model and Base Model Description: Model item that is used for configuration on the sales
order
 (Configured) Item and Description: Configured item that results in the generation error
 Organization: Organization that is associated with the configured item that contains the generation
error
 Exception Date: Date that the error occurred
 Resubmit Count: Number of times the configured item is resubmitted to complete the creation
process
 Exception Type: Predefined exception categories

• Consumption Rules
• Item Attachments
• Item Categories
• Item Locators
• Item Inventories
• Item Subinventories
• Item Transaction Defaults
• Related Items
• Units of Measure Interclass
• Units of Measure Intraclass
 Exception Message: Popup to display error message
4. Symptom: Supply order is not created
Explanation: A number of scenarios can result in the lack of a supply order. All of these are similar to
those seen in back-to-back fulfillment scenarios with standard products. If one has access to interface
table records, more information can be gathered, but issues can be resolved even without this access.
The most common causes are the following:
a. Scheduled process to release planning recommendations has not been run
b. Issue with GOP rules; e.g., conflicting or missing sourcing rules
c. Component supply not available in requested timeframe
d. Issue with work definition so GOP cannot produce ‘Make’ recommendation
e. Collections not run
Resolution: Identify and correct the root cause. In most cases, planning recommendations will have to be
(re)released, which, if successful, will trigger the creation of the supply order.
5. Symptom: Purchase requisition is created but no purchase order results from the request
Explanation: If a blanket purchase agreement is in place with the supplier, a purchase order is created
automatically after a purchase requisition is sent. If this does not occur within a reasonable amount of
time, log into the purchasing application to view the state of the requisition. If there is an error about
missing pricing, there could be a setup issue with the item definition.
Resolution: Product Model: Manage Items: Drill through the item structure and ensure that each
component has a price on the Specifications tab .
Purchasing: Check the blanket purchase agreement to make sure that it is in an approved state. If not,
correct any errors and resubmit it.
FAQ
1. Question: Where is structure of configuration item stored?
Answer: The configured item itself is stored in Product Model as a standard item with no structure. This is
to avoid duplication of structural elements on these tables. Supply Chain Orchestration (SCO) stores the
customer selections, the sales structure, which include the transactional item attributes (TIAs) that are
enabled for configuration matching on its ‘match’ tables. SCO regenerates this structure on request for
internal applications. The complete instance structure, which also includes mandatory items is also
generated on request using the stored data plus structure information from the model.
2. Question: How are phantom items (Manufacturing) treated?

Answer: Items that are designated ‘phantom’ for processing by manufacturing are still stored as part of the
configuration item structure if they are customer selections. Manufacturing replaces these non-physical

items with their physical counterparts at the next level of the model hierarchy when the work order is
generated. Standard items, as well as ATO sub-models can be marked as phantom.
3. Question: How do downstream applications such as purchasing and shipping get the component
information for a configured item?
Answer: Downstream applications request either the sales view or complete instance view components for
a specific configured item from Supply Chain orchestration.
4. Question: What components are supported for PTO models?

Answer: Standard items, kits, and ATO models are all supported as components of PTO models. The
individual components can be in stock or supplied through back-to-back processing as long as they are
shipped to the end customer together from the same warehouse.
5. Question: Can matching be disabled?

Answer: No. Matching is considered critical for efficient processing. Transactional item attributes (TIAs)
that are enabled for configuration matching can be added to item classes at any level of the model to
provide greater specificity to individual configurations. Note that the attribute related to matching on the
item specifications is meant for EBS compatibility and has no effect within Cloud applications.
6. Question: Is a separate work order created for a child ATO model?

Answer: If the supply type of the child ATO model is phantom, then a separate work order is not created.
The components of the child ATO model are put on the parent work order. If the supply type of the child
ATO model is not phantom, then a separate work order is created by Planning.
Conclusion
Assemble-to-order and pick-to-order configured items, as well as hybrids of the two types, can be ordered by
customers and fulfilled as manufactured or purchased items. There is flexibility in setup to allow for different naming
conventions and sourcing strategies.

Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
CONNECT WITH US
blogs.oracle.com/oracle
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
facebook.com/oracle warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
twitter.com/oracle means, electronic or mechanical, for any purpose, without our prior written permission.
oracle.com Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0417
CTO – Configure to Order

April 2017
Author: Leah Reed
Contributing Authors: Yuana Kumala, Milind Phadke, Michael Cummings, Manjula Evans, Rod Sernett, Ram Menon

Configure-To-Order Setup White Paper R11

Uploaded by

Copyright:

Available Formats

Configure-To-Order Setup White Paper R11

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configure-To-Order Setup White Paper R11

Uploaded by

Copyright:

Available Formats

CTO – Configure to Order

A Guide to Key Application Setups

Lead Time Calculations 28

Configured Item Work Definition and Work Order 28

Promising and Sourcing 31

Blanket Purchase Agreements 37

1 | CTO – CONFIGURE TO ORDER

2 | CTO – CONFIGURE TO ORDER

Configure to Order Functional Flow

» Purchasing the configured item from a supplier (drop-ship or back-to-back delivery)

3 | CTO – CONFIGURE TO ORDER

4 | CTO – CONFIGURE TO ORDER

5 | CTO – CONFIGURE TO ORDER

6 | CTO – CONFIGURE TO ORDER

Figure 5: Release Planning Recommendations

7 | CTO – CONFIGURE TO ORDER

Figure 6: Supply Order Access from Sales Order

8 | CTO – CONFIGURE TO ORDER

Figure 8: Supply Order 'Make' Execution Documents

9 | CTO – CONFIGURE TO ORDER

Figure 10: Supply Order 'Buy' Execution Documents

10 | CTO – CONFIGURE TO ORDER

Figure 11: Manufacturing Dispatch List

Figure 12: Manufacturing Completion Confirmation

11 | CTO – CONFIGURE TO ORDER

Figure 13: Ship Confirmation

12 | CTO – CONFIGURE TO ORDER

13 | CTO – CONFIGURE TO ORDER

Figure 15: Configured Item Invoice

14 | CTO – CONFIGURE TO ORDER

» Oracle Supply Chain Management Cloud

4. ATP & Sourcing – items must be collected first (GOP)

15 | CTO – CONFIGURE TO ORDER

Figure 16: Item Class: Configuration Item Number Generation

» Starting Number: e.g., 100

16 | CTO – CONFIGURE TO ORDER

» Prefix Type: Model Item Number, None, User Defined

Figure 17: Item Class Transactional Item Attribute Definition

17 | CTO – CONFIGURE TO ORDER

Figure 18: Model Item Specifications - Manufacturing

» Structure Item Type: Model

18 | CTO – CONFIGURE TO ORDER

Note that for a PTO model

Figure 19: Model Item Specifications: Sales and Order Management

19 | CTO – CONFIGURE TO ORDER

20 | CTO – CONFIGURE TO ORDER

21 | CTO – CONFIGURE TO ORDER

22 | CTO – CONFIGURE TO ORDER

Figure 23: Model Item Structure

23 | CTO – CONFIGURE TO ORDER

24 | CTO – CONFIGURE TO ORDER

Figure 25: Enhancing model presentation in configurator

25 | CTO – CONFIGURE TO ORDER

Figure 26: Work Definition - Visual Editor

26 | CTO – CONFIGURE TO ORDER

For numeric attributes, the valid operators are:

27 | CTO – CONFIGURE TO ORDER

Lead Time Calculations

Configured Item Work Definition and Work Order

» Work Order Header