Anda di halaman 1dari 45

CTO – Configure to Order

A Guide to Key Application Setups


ORACLE WHITE PAPER | OCTOBER 2018
Table of Contents

Introduction 3
Configure to Order Functional Flow 3
Setup 14
Items 15

Item Classes 15

Item Specifications 17

Model Structures 22

Configurator 24

Work Definitions 25

Operation Items 25

Applicability Rules 26

Lead Time Calculations 27

Reports 27

Configured Item Work Definition and Work Order 28

Collections 28

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) ______________________________________________ 12
Figure 15: Configured Item Invoice _______________________________________________ 13
Figure 16: Item Class: Configuration Item Number Generation _________________________ 15
Figure 17: Item Class Transactional Item Attribute Definition ___________________________ 16
Figure 18: Model Item Specifications - Manufacturing ________________________________ 17
Figure 19: Model Item Specifications: Sales and Order Management ____________________ 18
Figure 20: Model Item Specifications – Planning ____________________________________ 19
Figure 21: Model Item Specifications – Purchasing __________________________________ 20
Figure 22: Model Item Categories ________________________________________________ 21
Figure 23: Model Item Structure _________________________________________________ 22
Figure 24: Model Item Structure - Optional Components ______________________________ 23
Figure 25: Enhancing model presentation in configurator ______________________________ 24
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

2 | CTO – CONFIGURE TO ORDER


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)

3 | CTO – CONFIGURE TO ORDER


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.

4 | CTO – CONFIGURE TO ORDER


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 can 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

5 | CTO – CONFIGURE TO ORDER


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 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.

6 | CTO – CONFIGURE TO ORDER


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

7 | CTO – CONFIGURE TO ORDER


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 all 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.

8 | CTO – CONFIGURE TO ORDER


Figure 7: Supply Order 'Make' Flow

Figure 8: Supply Order 'Make' Execution Documents

9 | CTO – CONFIGURE TO ORDER


Figure 9: Supply Order 'Buy' Flow

Figure 10: Supply Order 'Buy' Execution Documents

10 | CTO – CONFIGURE TO ORDER


7. Supply Creation
a. Manufacturing builds the item and delivers to the inventory location associated with the 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 the
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.

11 | CTO – CONFIGURE TO 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)

12 | CTO – CONFIGURE TO ORDER


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

13 | CTO – CONFIGURE TO ORDER


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 13 – visibility to ATO model multilevel item structure
b. Separate work definition for each included ATO or assembly that is a manufactured item
3. Collect Items, Item Structures, Catalogs, 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)

14 | CTO – CONFIGURE TO ORDER


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 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

15 | CTO – CONFIGURE TO ORDER


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 and in the figure above, 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 13, 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 value sets must have the minimum and maximum values provided or the product
configurator will throw an error when the model snapshot is imported.

16 | CTO – CONFIGURE TO ORDER


It is also 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 along with Manufacturing Execution is 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. If you
then make any changes to the TIAs, you must create a new configurator workspace, add your model and an
updated item class snapshot and release the new workspace for the changes to take effect at run time.

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

17 | CTO – CONFIGURE TO ORDER


» Pick Components: No
» Assemble to Order: Yes
» Build in WIP = Y (if the item is to be manufactured); used if the value on the configuration item template
is not set

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 should be set to Yes. This attribute can be set differently for different inventory organizations
depending on the planned fulfillment strategy for the item.

18 | CTO – CONFIGURE TO ORDER


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.
The components themselves can be back-to-back enabled or not, depending on the planned fulfillment strategy.
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 figure above shows a subset of Planning specifications for an item. 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.

19 | CTO – CONFIGURE TO ORDER


» 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 to Yes and a default Purchase Price
must be set for the model item itself. Other parameters are optional.

20 | CTO – CONFIGURE TO ORDER


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 functional area categories assigned to the model will be
copied to the newly created configured item. The standard functional area catalogs include:
• Inventory
• Purchasing
• Planning
• Cost
• Order Entry
• Product Line Accounting
• Asset Management
• Distributed Order Orchestration
• Order Capture
• Pricing
• Configurator
• Supply Chain Financial Flow Orchestration

It is important to ensure that if a catalog is configured for single assignment that the item not be set up for 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 the one assigned to the Global Order Promising profile
attribute “Catalog for Sourcing Assignments.” This catalog will also be copied to configuration items when they are
created. A callout to the Vision Slimline category, as in the figure, 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. When collecting configured items, also collect catalogs to ensure the catalog and category assignment is also
added to the GOP repository.

21 | CTO – CONFIGURE TO ORDER


Model Structures

Figure 23: Model Item Structure

Mandatory components, options and option 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 up to 235 nested levels. (Note
that deeper levels can be created, but will not be returned by the queries to the CTO service for configured items.)
PTO models containing ATO components are also supported. Note that for ATO items, the structure must be the
same in every organization in which the model is defined.

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

22 | CTO – CONFIGURE TO ORDER


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 standard 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 or the shipping documents, 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 or can be associated directly to the root of the model.

23 | CTO – CONFIGURE TO ORDER


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. And also on this view is an attribute labeled ‘Instantiability’, which can only be
set for a child ATO. The value of this attribute determines whether a separate instance is required for each child
ATO if the quantity of the component is greater than one in a single instance of the model.

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 run time. Make sure that the item class is refreshed and added
as well as the model, especially if there have been changes to TIAs.

24 | CTO – CONFIGURE TO ORDER


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 item structure of the model. Prior to Release 13, you could view
only the first level components of the model in the Item Structure vertical tab. Starting with Release 13, you can view
the ATO model multilevel item structure. You can expand option classes to view the options. If the supply type of a
component is phantom, whether the component is optional or mandatory, you can also expand the phantom to view
its components. There can be multiple levels of phantom hierarchy, and you will be able to keep expanding until you
hit a non-phantom component. However, you cannot expand a child ATO model even when its supply type is
phantom.

You have the flexibility to assign any component from any level of the item structure to an operation. This is
governed by a couple of simple business rules. The first rule is that if you assign the parent, then you cannot assign
its children. The second rule is that if you have already assigned the children, you can still assign the parent,
however the system will delete the children assignments. This means for an option class, you can choose whether
to assign the option class or the options. Similarly for a standard item phantom, you can choose whether to assign
the parent phantom or the components. If you assign an option class 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.

You must assign the entire component quantity to an operation. You cannot update or split the quantity to multiple
operations. Except for Supply Type attribute, all other operation item attributes of an ATO model work definition are
referenced from Product Model and cannot be updated. These attributes are Basis, Quantity, Inverse Quantity,
UOM, Item Yield, Planning Percent, and Optional. You cannot assign ad hoc items to operations, which are items
that are not components of the ATO model item structure.

There cannot be missing operation item assignments in an ATO model work definition. This will cause the
configured item work order creation to fail. To ensure that operation item assignments are complete, perform Export
Operation Item Assignments from the Edit Work Definition Details page, and verify that the assignment status for the
top level ATO model is complete.

When the supply type of a child ATO model is not phantom, then you need to have a separate work definition for the
child ATO model. Planning should be used to generate the supply for the configured item of the child ATO. When
the supply type of a child ATO model is phantom, you don’t need to have a separate work definition for the child
ATO model. The components of the configured item of the child ATO will be included in the parent configured item’s
work order.

25 | CTO – CONFIGURE TO ORDER


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. Setting resources is optional and depends on whether the resources constrain
the operation.

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.

26 | CTO – CONFIGURE TO ORDER


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

27 | CTO – CONFIGURE TO ORDER


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 and catalogs 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. There is an additional setting in Release 13, Automatic selection, that allows the engine itself to
decide which of these choices is most appropriate when the collection is being run.

28 | CTO – CONFIGURE TO ORDER


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. This is important for
recognition of on hand quantities in cases of returns or over-supply (e.g., order cancellations). Catalogs should also
be collected at this time since category assignment is recommended for configured item availability-to-promise
considerations.

29 | CTO – CONFIGURE TO ORDER


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 should be updated through collections if that functionality is being used.
Note that this is optional. The selections for the collections service can be viewed in the figure above.

30 | CTO – CONFIGURE TO ORDER


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 “Refresh
and Start the Order Promising Server” 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
Note that for back-to-back orders, only the supply chain availability mode should be used.

31 | CTO – CONFIGURE TO ORDER


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. If the item is to be sourced through a back-to-back flow, this is the only option that will produce a
planning recommendation, required to create a supply order.

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 in the specified warehouse 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, but that has nothing to do with promising.

32 | CTO – CONFIGURE TO ORDER


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
also 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 many of the same
categories to which the model items belong. These include the functional area catalogs used by downstream
processes and the Global Order Promising default catalog set through the Catalog for Sourcing Assignments profile
attribute. During item setup the model and thus configured items should be associated with a category within the
same catalog that Global Order Promising uses as its default. 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.

33 | CTO – CONFIGURE TO ORDER


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.

34 | CTO – CONFIGURE TO ORDER


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.

35 | CTO – CONFIGURE TO ORDER


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

36 | CTO – CONFIGURE TO ORDER


Figure 35: Sourcing assignment - Buy (global) rule

For drop shipment of ATO model items or PTO model components, 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 all 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. Be careful to include the version of each item.

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

37 | CTO – CONFIGURE TO ORDER


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.

38 | CTO – CONFIGURE TO ORDER


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 above. 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.

39 | CTO – CONFIGURE TO ORDER


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 or mandatory items.

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.

40 | CTO – CONFIGURE TO ORDER


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, the exception can be ignored because 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

41 | CTO – CONFIGURE TO ORDER


• 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 the structure of configuration items 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 default values set to override values on the model when configured items are created?

42 | CTO – CONFIGURE TO ORDER


Answer: An item template that can be customized is used to specify the default values that will be used for
configured items. This is the ATO Item template. Note that only the template in the master organization is
used to specify the default values. Other attributes will be copied from the model instance corresponding
to the organization where the configured item instance is being created.

3. 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.

4. 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.

5. Question: Can users access the component information for a configured item?
Answer: Users can access component information for a configured item in one of two ways. They can
request either the sales view or complete instance view components for a specific configured item from
Supply Chain orchestration through the use of the public Configured Item SOAP service, or they can view
the components of the sales view from the Supply Chain Operations UI using the View Configured Item
Sales Structure menu action.

6. Question: What components are supported for PTO models?


Answer: Standard items, option classes, 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. PTO models can also be
drop shipped as long as all components are sourced from the same supplier.

7. 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 facilitated by Planning through a new supply
request for the component.

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.

43 | CTO – CONFIGURE TO ORDER


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 W ITH 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 means,
twitter.com/oracle 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. 1118

CTO – Configure to Order


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

Anda mungkin juga menyukai