Oracle Demantra CTO Load

Oracle Demantra CTO Load
An Oracle White Paper

Dec 2010
Introduction........................................................................................................ 3
Demantra CTO Hierarchy ............................................................................... 3
Model BOM Data Conversion ........................................................................ 5
Step1 BOM Translation to Table Structure ........................................... 5
Step 2 - CTO Child & CTO Parent Conversion ...................................... 9
Step 3 Populate Staging Tables .............................................................. 11
1. Base Model .......................................................................................... 11
2. CTO Child and its Item attribute..................................................... 11
3. CTO ..................................................................................................... 12
CTO Data Integration .................................................................................... 15
Options Shipping and Booking History .................................................. 15
Options Price ............................................................................................... 16
CTO Level and Data Integration Interfaces Summary .............................. 17
Level Integration ......................................................................................... 17
Data Integration .......................................................................................... 17
CTO BOM Data Maintenance ...................................................................... 19
Effectivity Dates Maintenance .................................................................. 19
CTO BOM Population Maintenance ....................................................... 22
Purging Data from CTO Data table......................................................... 25
Custom CTO Series ........................................................................................ 25
Required Patches ............................................................................................. 25
Page 2
Introduction
Oracle Demantra provides out of the box Configure to Order solution (CTO) from version 7.3
with standard Model BOM integration support from EBS 12.1.1 and above. This white paper
details how to convert and load model BOM and its related data into Demantra CTO base tables
for non EBS customers as well as for customer who were in earlier version of EBS (i.e. 11.5.10)
and the document explains with an model BOM example.
Demantra CTO Hierarchy

Demantra CTO hierarchy is modeled using General levels platform capability. Out of the box
CTO hierarchy contains following levels.
CTO
An internal level which stores the relationship between Base Model, CTO Child, CTO
Parent and Parent Item for each node in the BOM
Internal Lookup Table: t_ep_cto_level
Page 3
Internal Data Table: t_ep_cto_data
Base Model
Stores Base Model information
Internal Lookup Table: t_ep_cto_base_model
CTO Child & CTO Parent
Stores options and options class information. Both these levels were introduced in 7.3.0.1
to handle multiple occurrences of same options and option class in the same BOM.
CTO Parent is an alias level on CTO Child.
Lookup Table: t_ep_cto_child and t_ep_cto_parent (synonym of t_ep_cto_child)
Data Table: N/A
CTO Child level has an item attribute and it refers to item level in Item hierarchy
Demand Type
Internal level used to distinguish whether a CTO level member is a Base Model or Option
Class or Option.
No conversion and data load is required for this level
Contains following predefined level members
Internal Lookup Table: t_ep_cto_demand_type
Parent Item
Alias level of Item level in the Item hierarchy
No conversion and data load is required for this level
Internal Lookup table: t_ep_cto_parent_item (synonym of t_ep_item table)
Page 4
Model BOM Data Conversion

This section details with an example how to translate a model BOM into Demantra required data
structure and to populate required CTO staging tables
E.G. BOM structure for Base Model ATO Model 1
ATO Model 1 ..Node 1 (Root Node)
Option Class 1..Node 2
Option A..Node 3 (Leaf Node)
Option B..Node 4 (Leaf Node)
Option A..Node 7 (Leaf Node)
Option B..Node 8 (Leaf Node)
Option C..Node 10 (Leaf Node)
Option D..Node 11(Leaf Node)
In Oracle Demantra, each node in the BOM structure requires an entry (member) in CTO level
(t_ep_cto). The above exampled BOM structure translates into 11 CTO level members and each of
the 11 CTO members requires correct mapping to all of the CTO Hierarchy parent levels namely
Base Model, CTO Child, CTO Parent, Demand Type and Parent Item.
Step1 BOM Translation to Table Structure

Translate the BOM structure of Base Model ATO Model 1 into below tabular format.
Page 5
Node
Base Model
CTO Parent
CTO Child
CTO Child
Item Attribute
(DM Item
Level Code)
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
Base Model
ATO Model 1
ATO Model 1
Option Class 1
Option Class 1
ATO Model 1
Option Class
ATO Model 1
Option Class 1
Option A
Option A
Option Class 1
Option
ATO Model 1
Option Class 1
Option B
Option B
Option Class 1
Option
ATO Model 1
ATO Model 1
Option Class 3
Option Class 3
ATO Model 1
Option Class
ATO Model 1
Option Class 3
Option Class 1
Option Class 1
Option Class 3
Option Class
ATO Model 1
Option Class 1
Option A
Option A
Option Class 1
Option
ATO Model 1
Option Class 1
Option B
Option B
Option Class 1
Option
ATO Model 1
Option Class 3
Option Class 2
Option Class 2
Option Class 3
Option Class
10
ATO Model 1
Option Class 2
Option C
Option C
Option Class 2
Option
Option D
Option D
Option Class 2
Option
11
ATO Model 1 Option Class 2
Table 1.1 BOM Structure in Tabular Format
Parent Item
Demand
Type
The below section details how to translate the ATO Model 1 base model BOM structure into
above table format
Base Model
ATO Model 1 is the Base Model for which BOM was defined hence ATO Model 1should be
populated for all the 11 nodes for Base Model column.
Demand Type
Populate demand type column with
Base Model for root node
Option for all the leaf nodes
Option Class for all other intermediate nodes
Page 6
Root Node
Node 1
Its the BOM root node and its represent Base Model item (ATO Model 1), hence populate
ATO Model 1 in CTO Parent, CTO Child & its item attribute and Parent Item columns
Intermediate and Leaf Nodes

For Intermediate & Leaf Nodes, first start with CTO Parent then arrive at CTO Child and its
attribute
Node 2
Represents Option Class 1 item
Populate Option Class 1 for CTO_Child and its item attribute
Option Class 1 immediate parent is ATO Model 1, hence populate ATO Model 1 in
CTO Parent and Parent Item column
Node 3
Represents Option A item
Populate Option A for CTO_Child and its item attribute
Option A immediate parent is Option Class 1, hence populate Option Class 1 in

Node 4
Represents Option B item
Populate Option B for CTO_Child and its item attribute
Option B immediate parent is Option Class 1, hence populate Option Class 1 in

Node 5
Page 7
Option Class 3 immediate parent is ATO Model 1, hence populate ATO Model 1 in
Node 6
Represents Option Class 1 item and its second occurrence in the same BOM structure
but under Option Class 3
Here Option Class 1 immediate parent is Option Class 3, hence populate Option
Class 3 in CTO Parent and Parent Item column
Node 7
Represents Option A item
Populate Option A for CTO_Child and its item attribute
Option A immediate parent is Option Class 1, hence populate Option Class 1 in

Node 8
Represents Option B item
Populate Option B for CTO_Child and its item attribute
Option B immediate parent is Option Class 1, hence populate Option Class 1 in

Node 9
Option Class 2 immediate parent is Option Class 3, hence populate Option Class 3
in CTO Parent and Parent Item column
Node 10
Represents Option C item
Populate Option C for CTO_Child and its item attribute
Option C immediate parent is Option Class 2, hence populate Option Class 2 in

Page 8
Node 11
Represents Option D item
Populate Option D for CTO_Child and its item attribute
Option D immediate parent is Option Class 2, hence populate Option Class 2 in

Step 2 - CTO Child & CTO Parent Conversion

This step is required only for BOMs where same option class and options occurs more than once.
Option Class 1 and its options A & B appears twice in the BOM structure one directly
under Base Model ATO_Model1 and another under Option Class 3. To enable system to
distinguish multiple occurrence of same Option Class 1 under different root in a given
BOM, CTO Child and CTO Parent column for Option Class 1 have to be unique for
each of its occurrence.
CTO Child column value for Option Class 1 in node 1 and node 6 should be changed
from Option Class 1 to concatenation of column Base Model, CTO Parent and CTO
Child of the given row. Similarly CTO Parent column in node 3, 4, 7, 8 also have to be
changed from Option Class 1 to concatenation of column Base Model, CTO Parent and
CTO Child of the given row
Before Concatenation
Node
Base Model
CTO Parent
CTO Child
CTO Child Item

Attribute (DM Item
Level Code)
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
Option Class 1
Option Class 1
ATO Model 1
Option Class 1
Option A
Option A
ATO Model 1
Option Class 1
Option B
Option B
ATO Model 1
ATO Model 1
Option Class 3
Option Class 3
ATO Model 1
Option Class 3
Option Class 1
Option Class 1
ATO Model 1
Option Class 1
Option A
Option A
ATO Model 1
Option Class 1
Option B
Option B
Page 9
ATO Model 1
Option Class 3
Option Class 2
Option Class 2
10
ATO Model 1
Option Class 2
Option C
Option C
11
ATO Model 1
Option Class 2
Option D
Option D
Table 2.1
After Concatenation
CTO Child Item Attribute
(DM Item Level Code)
Node
Base Model
CTO Parent
CTO Child
ATO Model 1
ATO Model 1
ATO Model 1
Option Class 1
ATO Model 1
Option A
Option A
ATO Model 1
ATO Model 1
ATO Model 1 | ATO
Model 1 | Option
Class 1
ATO Model 1 | ATO
Model 1 | Option
Class 1
ATO Model 1
ATO Model 1 | ATO Model
1 | Option Class 1
Option B
Option B
ATO Model 1
ATO Model 1
Option Class 3
ATO Model 1
ATO Model 1
Option A
Option A
ATO Model 1
Option Class 3
ATO Model 1 | Option
Class 3 | Option Class
1
1
Option Class 3
ATO Model 1 | Option Class
3 | Option Class 1
Option B
Option B
ATO Model 1
Option Class 3
Option Class 2
Option Class 2
10
ATO Model 1
Option Class 2
Option C
Option C
11
ATO Model 1
Option Class 2
Option D
Option D
ATO Model 1
Option Class 1
Table 2.2 After Conversion of CTO Parent and CTO Child
Page 10
Step 3 Populate Staging Tables

Populate the corresponding interface staging table for each level in the CTO hierarchy in the below
mentioned order
1. Base Model
Perform Distinct of Base Model column and populate the Base Model level integration
staging table (BIIO_CTO_BASE_MODEL)
CTO Base Model Staging Table: BIIO_CTO_BASE_MODEL
T_EP_CTO_BASE_MODEL_CODE
T_EP_CTO_BASE_MODEL_DESC
ATO_MODEL_1
ATO_MODEL_1
2. CTO Child and its Item attribute

CTO child Code and Description
o Perform Distinct of CTO Child column from table 2.2 and populate the code
(t_ep_cto_code) and description (t_ep_cto_child_desc) field in CTO Child level
Integration staging table (BIIO_CTO_CHILD)
CTO Child Item Attribute Populate the corresponding CTO Child level Item attribute
value for CTO Child in t_ep_item_id column
CTO Child Level Staging Table: BIIO_CTO_CHILD

T_EP_CTO_CHILD_CODE
ATO Model 1
ATO Model 1 | ATO Model 1 |
Option Class 1
Option A
Option B
Option Class 3
ATO Model 1 | Option Class 3
| Option Class 1
Option Class 2
Option C
Option D
T_EP_CTO_CHILD_DESC
ATO Model 1
ATO Model 1 | ATO Model 1 |
Option Class 1
Option A
Option B
Option Class 3
ATO Model 1 | Option Class 3
| Option Class 1
Option Class 2
Option C
Option D
T_EP_ITEM_ID
ATO Model 1
Option Class 1
Option A
Option B
Option Class 3
Option Class 1
Option Class 2
Option C
Option D
Page 11
3. CTO
CTO Level Staging Table: BIIO_CTO_LEVEL
T_EP_CTO_CODE
T_EP_CTO_DESC
ATO Model 1 | ATO

Model 1 | ATO Model 1
ATO Model 1 | ATO
| ATO Model 1 | Option
Class 1
ATO Model 1 | ATO
| Option Class 1 |
Option A
ATO Model 1 | ATO
| Option Class 1 |
Option B
ATO Model 1 | ATO
Model 1 | Option Class
3
Class 3 | ATO Model 1 |
Option Class 3 | Option
Class 1
ATO Model 1 | ATO
3 | Option Class 1 |
Option A
ATO Model 1 | ATO
Option B
Class 3 | Option Class 2
ATO Model 1 | ATO

ATO Model 1 | ATO
| ATO Model 1 | Option
Class 1
ATO Model 1 | ATO
| Option Class 1 |
Option A
ATO Model 1 | ATO
| Option Class 1 |
Option B
ATO Model 1 | ATO
3
Class 3 | ATO Model 1 |
Option Class 3 | Option
Class 1
ATO Model 1 | ATO
Option A
ATO Model 1 | ATO
Option B
2
Class 2 | Option C
Class 2 | Option D

Class 2 | Option C
Class 2 | Option D
T_EP_CTO_D
EMAND_TYP
E_CODE
Base Model
T_EP_CTO_B
ASE_MODEL_
CODE
ATO Model 1
Option Class
T_EP_CTO_CHILD
_CODE
T_EP_CTO_PA
RENT_ID
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1
ATO Model 1 | ATO

Model 1 | Option
Class 1
ATO Model 1
Option
ATO Model 1
Option Class 1
Option A
ATO Model 1 |
ATO Model 1 |
Option Class 1
Option
ATO Model 1
Option Class 1
Option B
ATO Model 1 |
ATO Model 1 |
Option Class 1
Option Class
ATO Model 1
ATO Model 1
Option Class 3
ATO Model 1
Option Class
ATO Model 1
Option Class 3
ATO Model 1 |
Option Class 3 |
Option Class 1
Option Class 3
Option
ATO Model 1
Option Class 1
Option A
ATO Model 1 |
Option Class 3 |
Option Class 1
Option
ATO Model 1
Option Class 1
Option B
ATO Model 1 |
Option Class 3 |
Option Class 1
Option Class
ATO Model 1
Option Class 3
Option Class 2
Option Class 3
Option
ATO Model 1
Option Class 2
Option C
Option Class 2
Option
ATO Model 1
Option Class 2
Option D
Option Class 2
ITEM
PLANNI
NG_PCT
Page 12
Perform concatenation of column Base Model, CTO Parent, and CTO Child from table 2.2 and populate the t_ep_cto_code and t_ep_cto_desc
column in CTO level staging table (BIIO_CTO_LEVEL). Note: t_ep_cto_code and t_ep_cto_desc doesnt need to be same but make sure
t_ep_cto_desc is unique to a given t_ep_cto_code.
Populate corresponding Demand Type column value from table 1.1 in column t_ep_cto_demand_type_code
Populate corresponding Base Model column value from table 1.1 in column t_ep_cto_base_model_code
Populate corresponding Parent Item column value from table 1.1 in column Item
Populate corresponding CTO Child column value from table 2.2 in t_ep_cto_child_code column
Populate corresponding CTO Parent column value from table 2.2 in t_ep_cto_parent_code column
Populate planning percentages in column planning_pct
BIIO_CTO_Level table has 2 additional data columns

o CTO_QUAN_PER_PAR - Default quantity per parent and its an internal flag available in EBS source system
o
IS_OPTIONAL Default optional flag and its an internal flag available in EBS source system
Page 13
CTO Population Staging table: BIIO_CTO_POPULATION
Population staging table defines the item and location population for a given CTO level
member. Hence all the CTO members in BIIO_CTO_LEVEL staging table should have
item and location population entry in this table
Level_Member Corresponds to T_EP_CTO_CODE column in BIIO_CTO_LEVEL
From_Date
o Refers to BOM Start Date
o It should not be < (Max_Sales_Date CTO_History_Periods), where
Max_Sales_Date is a system parameter refers to last time bucket where sales
history was loaded and CTO_History_Periods is a another system parameter and
it defined no of time periods of options history to be used in historical planning
percentages calculation
Until_Date
o Refers to BOM End Date
o It should not be > (Max_Sales_Date + Lead) where Max_Sales_Date is a system
parameter refers to last time bucket where sales history was loaded and Lead is
another system parameter and it defines the independent item forecast horizon
Filter_Level Population Item and Location level names
Filter_Member Population Item and Location level members code
LEVEL_MEMBER
ATO Model 1 | ATO
| ATO Model 1
ATO Model 1 | ATO
| ATO Model 1
ATO Model 1 | ATO
| ATO Model 1
ATO Model 1 | ATO
| ATO Model 1
ATO Model 1 | ATO
| ATO Model 1
ATO Model 1 | ATO
| ATO Model 1
Model 1
FROM_DATE
05/01/2010
UNTIL_DATE
04/01/2012
FILTER_LEVEL
Item
LEVEL_ORDER
1
FILTER_MEMBER
ATO Model 1
Model 1
05/01/2010
04/01/2012
Demand Class
Model 1
05/01/2010
04/01/2012
Organization
Org 1
Model 1
05/01/2010
04/01/2012
Site
Site 1
Model 1
05/01/2010
04/01/2012
Sales Channel
Model 1
05/01/2010
04/01/2012
Territory
Page 14
NOTE:
Be sure to specify all lowest-level dimensions for both item and location. If any lowest level (e.g.
Demand Class, Territory Retailer, Manufacturer) is not actively used then populate default member
code (i.e. 0) for that level in FILTER_MEMBER column. Also, above population staging table
contains rows only for a Base Model CTO member, all CTO level members in
BIIO_CTO_LEVEL staging table should have a population entry in this table for all lowest level
dimensions of Item and Location.
In regards to location population filter members, be sure to include only the location members
where the Base Model item is actively sold. For e.g. if you have 10 site/org combination in total but
if the concerned Base model is sold only in 5 site/org locations then include only those 5 location
level members in the population staging table for all of the CTO level members of that Base model.
CTO Data Integration

System provides couple of interfaces to load options shipment & booking history and to load
options price.
Options Shipping and Booking History
If there is no requirement to calculate historical planning percentage within Demantra then there is
no need to load options shipment & booking history. System needs options shipment & booking
history only for historical planning percentage calculations.
Staging Table Name: BIIO_CTO_DATA
Page 15
Staging Table Column Name

SDATE
LEVEL1
LEVEL2
LEVEL3
LEVEL4
LEVEL5
LEVEL6
EBS_BH_BOOK_QTY_BD_DEP
EBS_BH_BOOK_QTY_RD_DEP
EBS_BH_REQ_QTY_BD_DEP
EBS_BH_REQ_QTY_RD_DEP
ACTUAL_QUANTITY_DEP
EBS_SH_REQ_QTY_RD_DEP
EBS_SH_SHIP_QTY_RD_DEP
EBS_SH_SHIP_QTY_SD_DEP
CTO_PLN_PCT
Data Element to be
Populated
Sales Date (mm/dd/yyyy)
CTO Code
Item Code
Demand Class Code
Organization Code
Site Code
Sales Channel Code
Dependent Booking History
- Booked Items - Booked
Date
- Booked Items - Requested
Date
- Requested Items - Booked
Date
- Requested Items Requested Date
Dependent History
(Shipping HistoryRequested Items - Shipped
Date)
Dependent Shipping
History- Requested Items Requested Date
Dependent Shipping
History- Shipped Items Requested Date
Dependent Shipping History
- Shipped Items - Shipped
Date
Existing Planning
Percentage
Options Price
Staging Table: IMPORT_CTO_OPTIONS_PRICE
Integration Table
Column
SDATE
LEVEL1
OPTION_PRICE
Data Element
Sales Date (mm/dd/yyyy)
Item Code
Option_Price series data
Page 16
CTO Level and Data Integration Interfaces Summary

Level Integration
Level
Workflow
Base Model
Import CTO Base

Model
Import CTO Child
Import CTO Level
CTO Child
CTO Child
Integration
Interface
CTO
Integration Profile
Staging Table(s)
IMPORT_CTO_BASE_MODEL
BIIO_CTO_BASE_MODEL
CTO
CTO
IMPORT_CTO_CHILD
IMPORT_CTO_LEVEL
BIIO_CTO_CHILD
BIIO_CTO_LEVEL
BIIO_CTO_POPULATION
Data Integration
Data
Workflow
Options Shipping
& Booking History
and Planning %
Import CTO Data
Options Price
Import CTO
Option Price
Integration
Interface
CTO
Integration Profile
Staging Table
IMPORT_CTO_DATA
BIIO_CTO_DATA
CTO
IMPORT_OPTIONS_PRICE
BIIO_CTO_OPTION_PRICE
NOTE: Before importing CTO data, load all item, location, and independent sales history
via the EP_LOAD process. Item file (t_src_item_tmpl) should include independent items
as well as option and option class items.
After loading data into the Demantra staging tables, run the following workflows in the order
specified to import data into the Demantra CTO application tables
1. Import CTO Base Model
2. Import CTO Child
3. Import CTO Level
4. Import CTO Data
5. Import CTO Option Price
Page 17
Instead of running the above individual workflows, you can run either workflow CTO Download
Existing Planning Pcts available under CTO workflow schema group or workflow EBS
Full Download under EBS Workflows workflow schema group which in turn calls CTO
Download Existing Planning Pcts workflow from LaunchCTODownload workflow step
After running the CTO level and Data load workflows, execute Dependant Demand batch
calculation by running Calculate Dependant Demand workflow available under CTO
schema group. Calculate Dependant Demand workflow was also called with in Forecast
Calculation & Approval Process workflow available under Demand Management workflow
schema group.
Note: Calculate Dependant Demand workflow should have been run once before viewing
the BOM tree structure in worksheets
Page 18
CTO BOM Data Maintenance

Effectivity Dates Maintenance
Unlike Independent demand forecasting of end items where Demantra forecasting engine
creates required time buckets in the forecast horizon to store forecast, in CTO module time
buckets (both historical and future) for an CTO member is created during load of CTO
members (BOM definition load) via CTO level profile interface. For a given CTO member,
Level Integration creates all time buckets in t_ep_cto_data table between from_date and
until_date for the population members specified in the BIIO_CTO_POPULATION
staging table. Hence effectivity dates for CTO members should be maintained as part of
BOM data conversion process so the system would create required buckets in
t_ep_cto_data table to store options history, planning percentages and forecast.
On an ongoing basis, effectivity dates (From and Until Date) of all active base models
BOMs (All CTO Members of the active BOMs) should be moved forwarded by a
respective time period, as new period (week/month) of sales history gets loaded and
forecast horizon gets extended by additional period (week/month).
No forward extension is required for CTO Members if the BOM effective end date in the
source system is earlier than max_fore_sales_date (system parameter). Extension is required
only for BOMs which has either indefinite end date or end date greater than
max_fore_sales_date in the source system.
E.g. the below example illustrates how to maintain BOM effective dates for active base models
Assume a base model item Model A has couple of options Option X & Y and Model B has
options X, Y and Z, of which option X is getting replaced by option Z from Sep 2011.
Following were the converted CTO level code for corresponding CTO level members of Model A
& B base model
Page 19
CTO Level Member Codes
T_EP_CTO_CODE
Model A | Model A
Model A | Option X
Model A | Option Y
Model B | Model B
Model B | Option X
Model B | Option Y
Model B | Option Z
Following were the effectivity dates of Model A & B and its options in the source system.
Base Model
Options
Start Date
End Date
Model A
Jan 2008
Model A
Option X
Jan 2008
Model A
Option Y
Jan 2008
Model B
Sep 2010
Model B
Option X
Sep 2010
Aug 2011
Model B
Option Y
Sep 2010
Model B
Option Z
Sep 2011
CTO Level Members Effective Dates

Based on from date and until date conversion rules mentioned in page 14, from_date >=
max_sales_date CTO_History_Periods which is June 2010 and Until Date <=
Max_Fore_Sales_Date which is July 2012.
Following were the converted effectivity dates for CTO members of Model A & Model B base
models for December 2010 and Jan 2011 planning cycle.
Page 20
Dec Month Planning Cycle

Current Planning Month: Dec 2010
Max_Sales_Date: Nov 2010
Forecast Lead: 18 Months
Max_Fore_Sales_Date: July 2012
CTO History Periods: 6 Months
T_EP_CTO_CODE
FROM_DATE
UNTIL_DATE
Model A | Model A
June 2010
July 2012
Model A | Option X
June 2010
July 2012
Model A | Option Y
June 2010
July 2012
Model B | Model B
Sep 2010
July 2012
Model B | Option X
Sep 2010
Aug 2011
Model B | Option Y
Sep 2010
July 2012
Model B | Option Z
Sep 2011
July 2012
Jan 2011 Month Planning Cycle

Current Planning Month: Jan 2011
Max _Sales_Date: Dec 2010
Max_Fore_Sales_Date: Aug 2012
In Jan 2011 planning cycle, sales history will be loaded for the month of Dec 2010, hence
max_sales_date becomes Dec 2011 and max_fore_sales_date becomes Aug 2012 (max_sales_date
+ lead).
T_EP_CTO_CODE
FROM_DATE
UNTIL_DATE
Model A | Model A
July 2010
Aug 2012
Model A | Option X
July 2010
Aug 2012
Model A | Option Y
July 2010
Aug 2012
Page 21
Model B | Model B
Sep 2010
Aug 2012
Model B | Option X
Sep 2010
Aug 2011
Model B | Option Y
Sep 2010
Aug 2012
Model B | Option Z
Sep 2011
Aug 2012
CTO BOM Population Maintenance
Load BOM data only for locations where a Base Model is actively being sold. Scan the sales
independent history file for the base model item for a pre-determined time range (say
rolling last 12 months) and find the locations where its sold and include only those
locations in the CTO population.
Following example illustrates how to maintain CTO BOM population

Assume a base model item Model A has couple of options Option X & Y and its actively sold in
2 sites (Site 1 and Site 2) out of 10 total sites in the location master. All 10 sites belong to single
organization Org A. Following is the population table content of CTO level profile.
Jan 2011 Planning Cycle
Current Planning Month: Jan 2011
Max _Sales_Date: Dec 2010
Max_Fore_Sales_Date: Aug 2012
BIIO_CTO_POPULATION
T_EP_CTO_CODE
FROM_DATE
UNTIL_DATE
Filter Level
Filter Order
Filter Member
Model A | Model A
July 2010
Aug 2012
Item
Model A
Model A | Model A
July 2010
Aug 2012
Site
Site 1
Model A | Model A
July 2010
Aug 2012
Organization
Org A
Model A | Option X
July 2010
Aug 2012
Item
Model A
Model A | Option X
July 2010
Aug 2012
Site
Site 1
Model A | Option X
July 2010
Aug 2012
Organization
Org A
Page 22
Model A | Option Y
July 2010
Aug 2012
Item
Model A
Model A | Option Y
July 2010
Aug 2012
Site
Site 1
Model A | Option Y
July 2010
Aug 2012
Organization
Org A
Model A | Model A
July 2010
Aug 2012
Item
Model A
Model A | Model A
July 2010
Aug 2012
Site
Site 2
Model A | Model A
July 2010
Aug 2012
Organization
Org A
Model A | Option X
July 2010
Aug 2012
Item
Model A
Model A | Option X
July 2010
Aug 2012
Site
Site 2
Model A | Option X
July 2010
Aug 2012
Organization
Org A
Model A | Option Y
July 2010
Aug 2012
Item
Model A
Model A | Option Y
July 2010
Aug 2012
Site
Site 2
Model A | Option Y
July 2010
Aug 2012
Organization
Org A
If a given base model is no longer shipped to a location (site/org) or not going to be

shipped to a location from certain date (Discontinuation Date) in future and if such
information exists in the source system then you can leverage those information to build a
logic while populating BIIO_CTO_POPULATION table, to not extend the effectivity date
further of the CTO level members of the given BOM for the concerned locations or not to
extend the BOM until date for the concerned locations for the relevant CTO members of
the BOM beyond the discontinuation date.
For e.g. if it was planned that Model A is no longer going to be shipped to Site 2 effectively from
June 2011 instead it will sold to a Site 3 effective from June 2011. If this information exists in the
source system then you can populate BIIO_CTO_POPULATION table accordingly for the Feb
Planning cycle
Feb 2011 Planning Cycle
Current Planning Month: Feb 2011
Max _Sales_Date: Jan 2011
Max_Fore_Sales_Date: Sep 2012
Page 23
BIIO_CTO_POPULATION
T_EP_CTO_CODE
FROM_DATE
UNTIL_DATE
Filter Level
Filter Order
Filter Member
Model A | Model A
Aug 2010
Sep 2012
Item
Model A
Model A | Model A
Aug 2010
Sep 2012
Site
Site 1
Model A | Model A
Aug 2010
Sep 2012
Organization
Org A
Model A | Option X
Aug 2010
Sep 2012
Item
Model A
Model A | Option X
Aug 2010
Sep 2012
Site
Site 1
Model A | Option X
Aug 2010
Sep 2012
Organization
Org A
Model A | Option Y
Aug 2010
Sep 2012
Item
Model A
Model A | Option Y
Aug 2010
Sep 2012
Site
Site 1
Model A | Option Y
Aug 2010
Sep 2012
Organization
Org A
Model A | Model A
Aug 2010
May 2011
Item
Model A
Model A | Model A
Aug 2010
May 2011
Site
Site 2
Model A | Model A
Aug 2010
May 2011
Organization
Org A
Model A | Option X
Aug 2010
May 2011
Item
Model A
Model A | Option X
Aug 2010
May 2011
Site
Site 2
Model A | Option X
Aug 2010
May 2011
Organization
Org A
Model A | Option Y
Aug 2010
May 2011
Item
Model A
Model A | Option Y
Aug 2010
May 2011
Site
Site 2
Model A | Option Y
Aug 2010
May 2011
Organization
Org A
Model A | Model A
June 2011
Sep 2012
Item
Model A
Model A | Model A
June 2011
Sep 2012
Site
Site 3
Model A | Model A
June 2011
Sep 2012
Organization
Org A
Model A | Option X
June 2011
Sep 2012
Item
Model A
Model A | Option X
June 2011
Sep 2012
Site
Site 3
Model A | Option X
June 2011
Sep 2012
Organization
Org A
Model A | Option Y
June 2011
Sep 2012
Item
Model A
Model A | Option Y
June 2011
Sep 2012
Site
Site 3
Model A | Option Y
June 2011
Sep 2012
Organization
Org A
Page 24
Purging Data from CTO Data table
Since CTO level profile creates all possible time buckets between start and end date of the CTO
BOM into t_ep_cto_data table, there is a high probability to have empty rows in the data table.
Having these uneccessary rows will degrade the system performance. You can follow the below
guideline to purge those empty rows from t_ep_cto_data table.
Delete all rows from t_ep_cto_data table where options Shipment and/or Booking history
(whichever demand streams used) data are null in the historical time range (sales_date <=
max_sales_date).
If you are archiving options forecasts for accuracy calculation, then restrict time range of
deletion accordingly. Say if you archive last 3 options forecast version, then the historical
time range to be looked for deletion should be sales_date < max_sales_date 2 time
periods
Custom CTO Series

If solution necessitates custom series referring CTO data table (t_ep_cto_data), make sure to set
Edit Preservation Type of those series to Do Nothing
Required Patches
1. Demantra Patch 7301069 (ARU 13196040, Oracle Patch 10143338) contains fixes related
to Integration level profile performances.
2. Oracle Patch 10379237 (ARU 13225440) is an application patch and it fixes edit
preservation type settings of relevant data series
Page 25

Dec 2010
Author: Nagappan Periakaruppan
Contributing Authors: [OPTIONAL]
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2007, Oracle. 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 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,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Oracle Demantra CTO Load

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

Oracle Demantra CTO Load

Uploaded by

Copyright:

Available Formats

Oracle Demantra CTO Load

An Oracle White Paper