An Oracle White Paper

April 2013

Distributed Order Orchestration

Cross-Reference
 Cross-References

Disclaimer
The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracle’s products remains at the sole discretion of
Oracle.
 Cross-References

Overview ........................................................................................... 2
Introduction ....................................................................................... 2
Setting up Source System ................................................................. 2
Create Source System................................................................... 3
Manage Orchestration Source System .......................................... 4
CROSS-REFERENCING FOR MASTER DATA ................................ 6
Customer Master Data................................................................... 6
Product Master Data: ..................................................................... 8
Cross-Referencing Items Using Source System Item Relationships8
Cross-Referencing Items Using ‘Cross-Reference’ Item Relationships for non
Product Data Hub Customers ........................................................ 9
Reference Entities -Order Orchestration and Planning(OOP) Repository 12
Domain Value Maps: ................................................................... 14
Usage of Cross Reference Data ...................................................... 19
 Cross-References

Overview
This whitepaper will focus on the process of establishing the cross-reference within the various sources
of Fusion Applications for the purpose of integrating capture and fulfillment systems with DOO. This
document will also provide an overview of the usage of the cross-reference by DOO while integrating
with those systems.

Introduction
Cross-referencing is a key concept when integrating systems and applications. It enables us to identify
correlated information across independent applications and, therefore, is required in almost every
integration scenario. Cross-referencing can be implemented at the integration or application layer.
Distributed Order Orchestration (DOO) leverages the cross-reference capabilities supported at the
Application Layer by the various Fusion Applications. Distributed Order Orchestration uses the cross-
reference capabilities supported by the respective Master Data Management Applications for
customers and products. For all of the other reference entities, DOO collects the reference data along
with the Cross Reference information into a repository referred to as ‘Order Orchestration and
Planning Repository’. When DOO integrates with different systems, DOO looks up the cross-
reference data from various cross-reference sources for the entities which are cross-reference enabled
to resolve it to either a common value or to a source system specific value depending on the direction
of the interaction.

Setting up Source System

Source systems are used to import data into Oracle Fusion Applications, and are used within the
application to identify source data information. You can specify whether the source system is a Spoke
system, such as a legacy system, or a Purchased system, such as data from a third party provider. You
can also specify what type of data will be imported using the source system, for example, you can
specify that a source system will import trading community members.

A source system in the context of Distributed Order Orchestration is also a system that DOO
integrates with and is a prerequisite step for establishing the cross-reference values for various entities.
The source system could be a capture system from which DOO receives sales orders or a Fulfillment
system to which DOO sends the Fulfillment request and receives the Fulfillment responses. Each
Source System has a representation of their reference and master data in Fusion by means of having
the source system representation of the data to be either a system of record in Fusion or through a
cross-reference to a common value if a different source system representation of that record is
considered to be the system of record.
All the Fusion Fulfillment Applications running on the same instance as DOO are represented as one
logical source system in Fusion as the data is self collected into the same instance where both DOO
and other Fusion Fulfillment Applications are running.

2
 Cross-References

Create Source System

Setting of Source System for Distributed Order Orchestration constitutes of two steps. The first step
involves creating the Source system as DOO uses the Source System Management (SSM) from Oracle
Fusion Trading Community Model and which is used as the common registry of source systems in
Fusion. This source system registry is also used by other Fusion applications like Oracle Fusion
Trading Community Model and Product Data Hub (PDH) that require a source system definition.

You should select which types of the entities will be imported from the source system as part of
creating the source system in Source System Management. Some of the entities that can be specified
while creating the source system are

 Items
 Trading Community Members
 Order Orchestration and Planning

You can select one or more of these entity types as required for the source system. For example, if a
source system is enabled for Trading Community Members, Items, and Order Orchestration and
Planning, then the source system can be selected as a data source in the Trading Community Members,
Items, and Order Orchestration and Planning UIs.

“Enable For Items”, “Enable for Trading Community Members” and “Enable for Order
Orchestration and Planning” should be enabled in order for the source system to be eligible for
integrating with DOO in the Create Source System UI. “Enable For Items” determines if the source
system can be used for establishing the source system item. “Enable for Trading Community
Members” determines if the Original System Unique reference (OSR) can be established in Oracle
Fusion Trading Community Model for the customer related entities.
The following screen in figure.1 shows the creation of source system and enabling the entities that are
relevant and dealt by that source system.

3
 Cross-References

Figure 1. Create Source System

Manage Orchestration Source System

The Source System is further defined in the Manage Orchestration Source System UI to also classify
the purpose of that source system in the context of the system integrating to DOO. In the example
below, Siebel (SEBL) which is playing the role of Order Capture is setup to be a Order Orchestration
system type of ‘Order Capture’. The version is identified be ‘Others’ for all non-Fusion systems.
A system which is playing a role of Fulfillment system is defined similarly in the Source System
Registry (SSM) and the only difference being it is classified as “Fulfillment” in the Manage
Orchestration Source System through the Order Orchestration Type attribute.

Figure 2. Manage Orchestration Source System

4
 Cross-References

A Source system from which the reference data is collected for the purpose of Order Orchestration
should have the “Enable Data Cross-Reference” as shown in figure.2 at the source system level for
DOO to be able to integrate with that system using the source system specific values or identifiers.
Additionally in the Manage Collections Process Parameters as shown in figure.3, the entities for which
the cross-reference should be performed during collections should also have the “Enable Cross-
References” checked against those entities that are to be cross-referenced for each of the source
system.
Most of the reference entities that DOO depends on are grouped under the “Order Orchestration
Reference Objects. The exceptions being Shipping Methods, UOM and Currencies. The list of all the
reference entities which are collected into Order Orchestration and Planning repository that DOO
depends on are documented in the subsequent sections in table.1 under the section “Reference
Entities- Order Orchestration and Planning Repository”.

Figure 3. Manage Orchestration Data Collection Process

5
 Cross-References

CROSS-REFERENCING FOR MASTER DATA

Distributed Order Orchestration depends on the Fusion Trading Community Model for the Customer
related data needs. Likewise DOO also depends on the Common Product Model for the Product
related data needs. So for cross-referencing of product and customer related Data, DOO uses the
cross-reference support provided by the Product Model and Trading Community Model.

Customer Master Data

A Source system or Originating source for customer master data is any data system or application
outside of Fusion Applications that provides information to the Trading Community Architecture.

Source System Management maintains references between the Oracle Fusion Trading Community
Model Registry and any defined source system, such as a legacy or third party system that loads data
into the Registry. It records the Originating System and the Original System Unique reference (OSR)
for each record provided. The source ID, or ID of the record in that external system, is mapped to the
Registry ID of the Oracle Fusion Trading Community Model record, such as the party or contact point
through the OSR.

For example, a record is loaded with the ID 12345 from the Legacy system into the Oracle Fusion
Trading Community Model Registry. That record is assigned the Registry ID 100 in the Customer
Registry. The source ID, 12345, is referenced to Registry ID 100.

The following figure 4 shows an order capture and fulfillment system from which the customer related
information is mapped using OSR to the Registry ID in the Fusion Customer Registry.

Figure 4. Usage of OSR by Capture and Fulfillment System

6
 Cross-References

DOO depends on this capability from Oracle Fusion Trading Community Model that enables tracking
between a Fusion Customer record and its data sources. In the upstream integrations when an order is
received, DOO using the originating system unique reference (OSR) resolves it to the Registry ID
created for that record in the Fusion Trading Community Registry.

Similarly when the Fulfillment requests are initiated by DOO in the downstream integrations, DOO
resolves the Originating system unique reference for that Originating system using the on Registry ID.

Source System Entities are the entities, such as addresses and parties, which can be imported using a
specified source system. Within the Source System Entities UI, you can chose to allow multiple source
references, which allows multiple records from a source system to map to a single trading community
record.

Allowing multiple source system references means that when you import data from a source system
you can merge multiple, or duplicate, source system records and create one record in the Oracle
Fusion Applications database.

If you do not allow multiple source system references then an Oracle Fusion Applications database
record will be created for every source system record. This means that you could potentially create
duplicate records in the Oracle Fusion Applications database.

As DOO passes a single source system reference for a given instance of the customer related entity
downstream, currently it is recommended to setup for a single source reference.

Please refer to the Oracle Fusion Trading Community Model Source System Management feature,
Customer creation processes (customer import and web services) for further details on associating the
source references to the customer data either while synchronizing the customer data or associating it to
the existing customers.

The following screen shot in figure.5 shows the Manage Source System Entities UI.

7
 Cross-References

Figure 5. Manage Source System Entities

Original System Unique reference can be imported through the Customer Import Process or through
the web services. For details related to the customer import and services, please refer to the relevant
Oracle Fusion Trading Community Model documentation.

Product Master Data:

DOO leverages the Oracle Fusion Product Model for the product definition. For the Product Item
cross-references, the Item Relationship Model in Fusion Product Model is used for modeling the
product related cross-reference. Item relationship model enables to relate internal item with another
item or reference the item with a source system item, Global Trade Item Number (GTIN) or cross-
reference.

Depending on whether customers implement Oracle Fusion Product Hub vs. Oracle Fusion Product
model, the product related cross-reference is modeled differently in the item relationship model. When
customers are implementing Oracle Fusion product data hub, the cross-reference for the products are
modeled using the ‘source system items’ Item Relationship Type. It establishes a relationship between
an internal item and a source system item. This relationship is helpful in mapping and identifying items
that have been consolidated from multiple source systems into a single master item.

Cross-Referencing Items Using Source System Item Relationships

The Items and source system item relationship or the item cross-references depending on if customers
are implementing Product Hub or using only CPM can be imported using the item import process or
through the Manage Item relationships UI.

8
 Cross-References

When setting up the source system Item relationship through the UI, the Fusion Item to which the
Source System Item is being cross-referenced is entered along with the source system as shown in
figure.6. The value used for the Source System Item can be an internal identifier or user key that is
used by that source system to uniquely identify the item during the interactions with the DOO system.

Figure 6. Manage Item Relationships-Create Source System Item Relationship

Cross-Referencing Items Using ‘Cross-Reference’ Item Relationships for non Product

Data Hub Customers

When customers are up taking only the product model, the cross-references are modeled using the
Item relationship Type of ‘Cross-References’. Product Model provides the functionality to map
additional information about an item in the form of a value and cross-reference type. Cross-Reference
Types are part of item relationships where the item relationship type is Cross-Reference. For example,
the cross-reference can map between an item and a part number in the source system, where the value
is the value of the part number in the source system and the type is Source Item. There are no values
seeded for cross-reference types. You define the values using the Manage Cross Reference Types task.
The lookup code should match that of the Orig System(ORIG_SYSTEM) value in the source system
definition.

The following screen in Figure.7 shows the look up type of ‘Item Cross Reference Types’ that needs to
be extended to add the source system.

9
 Cross-References

Figure 7. Manage Standard Lookups

The next screen in figure.8 and 9 shows Manage Item Relationships and for Item
Relationship Type of ‘Cross References’

Figure 8. Manage Item Relationships

10
 Cross-References

Figure 9. Create Cross Reference Relationship

While creating a Cross-Reference Relationship through the UI for the Item relationship Type of
‘Cross-References’ , the relationship type should be same as the source system as DOO uses the source
system while determining the cross-reference of the item for that source system.

The Item relationships of both Source System Item Relationship and Item Cross-Reference can be
managed through the item import or through the Item Service. For the details on how to use the item
import or the service, please refer to the documentation from PIM.

11
 Cross-References

Reference Entities -Order Orchestration and Planning (OOP)

Repository
Order Orchestration and Planning Repository is a data store into which the data is collected from
different capture and fulfillment systems for various reference entities that DOO depends during the
Order Orchestration. Collections also collect the Transactions related to supply and demand for the
purpose of Planning and Promising. To manage this collection and consolidation process, information
about the source of particular records or partitions of records must be stored. This requires defining
source systems which is explained under the Source System Management. With this information, the
OOP repository is able to track which piece of information came from which source system. The key
information here are the cross-references to the base records in the source systems.
The reference entities that have a representation in multiple systems are collected into OOP repository,
validated and consolidated to the so-called “single blended record”. These entities are also referred to
as Global Entities. Some of the examples of these entities are Payment Terms, Freight Terms,
Currency and UOM.
There are also a second category of reference entities that are considered typically to not have
representation of the same data in multiple systems. i.e. The data from multiple systems for that entity
is not consolidated to a so-called “Single blended record” as the instance of that data or records for
those entity are considered to be distinct. These are referred to as Source Specific Entities. Warehouse
which is also referred as organization is treated as a Source Specific Entity currently by Order
Orchestration and Planning Repository.
The comprehensive list of the reference entities that are collected into OOP repository and which
DOO depends are captured in the below table.1. The reference entities are also classified to be global
vs. Source specific in the following table. If it is a global entity, then the Domain Value map where the
maps are setup, which then results in the cross-references being established in cross-reference entity of
Order Orchestration and Planning Repository, are also identified below.

12
 Cross-References

Entity Name Global vs. Source Specific DVM

Currencies Global mscCurrCode
mscCurrName
Conversion Types Global mscCurrConvType
Payment Terms Global mscPaymentTerm
Invoicing and Accounting Rules Global mscInvoiceAcctRule
Demand Classes Global mscDemandClass
FOB Global mscFOBPoint
Freight Carriers Global mscCarrier
Ship Class of Service Global mscServiceLevel
Ship Mode of Transport Global mscShipModeTransport
Warehouses Source System Specific
UOM Global mscUOMCode
mscUOMName
Return Reasons Global mscReturnReason
Document Categories Global mscDocCategory
Reason Global
Receipt Methods Global mscReceiptMethod
Shipment Priority Global mscShipmentPriority
Sales Credit Types Global mscSalesCreditType
Freight Terms Global mscFreightChargeTerms
Tax Classification Codes Global mscTaxCode
Tax Exemption Reason Global mscTaxExmptReason
Activity Types Global mscDOOActivityType

Table 1. Reference Entities Used by DOO

13
 Cross-References

Domain Value Maps:

Domain Value Maps are used in the context of integrations when information is exchanged between
different domains/systems as each system might use different terminology or processing codes or
identifiers to describe an instance of an entity or a record which is setup in multiple systems. A
Payment terms in a capture system which is “Net 30 days” may be referred to as “30 Days” in the
billing system that the billing request is sent to.
For almost every established integration scenario, cross-referencing is a key requirement to map entities
between integrated systems. The instance of the reference data that is considered to be a representative
of that record in Fusion is referred to as a common value in the scope of this document. It is also
referred to as a system of record or base record or blended record. The instance of the reference data
in the source systems which is considered to be same is cross-referenced to the common value in the
DVM and then collected.
Domain Values are used by the Collections Framework to enable mapping of values from one
vocabulary used in a given domain/system, to another vocabulary used in a different domain/system.
Collections during the process of collecting the data into Order Orchestration and Planning Repository
looks up at the DVMs to determine if there is a row to map the incoming reference data with a
Common Value and based of which the cross-reference entity in OOP are populated to store the
cross-reference for the internal and the user key values. The domain value maps have to be pre-defined
during implementation for each of the reference entities that are considered to be global entities and
have a single blended representation of record. The user keys for the various entities are typically used
for the mapping in the DVM which drives the cross-reference data that gets populated in the OOP
repository cross-reference entity.
The next table.2 represents the attributes that gets cross-referenced in Order Orchestration and
Planning schema for each of the reference entity. The domain value map (DVM) column identifies if
that attribute is used for setting up the map based of which the cross-references are established in the
Order Orchestration and Planning cross-reference entity.

14
 Cross-References

Reference Entity Cross-referenced DVM Mapping

Attribute
Invoicing and accounting rule Rule_id No
Name Yes
Receipt method Receipt_method_id No
Name Yes
Sales credit type Sales_credit_type_id No
name Yes
Currency conversion type Conversion type Yes
Currency Currency_code Yes
name Yes
Payment term Term_id No
name Yes
Document category Category_id No
Category_name Yes
Carrier Carrier_id No
Name Yes
Unit of measure Uom_code Yes
Unit_of_measure Yes
Service Level Lookup_code No
meaning Yes
Mode of transport Lookup_code No
meaning Yes
Tax classification code Lookup_code No
meaning Yes
Tax exemption reason Lookup_code No
meaning Yes
Activity type Lookup_code No
meaning Yes
Payment method Lookup_code No
meaning Yes
Demand class Lookup_code No
meaning Yes

15
 Cross-References

FOB point Lookup_code No

meaning Yes
Shipment priority Lookup_code No
Meaning Yes
Return reason Lookup_code No
Meaning Yes

Table 2. Cross-Referenced Attributes in OOP Repository

The screen shot in figure.10 shows the various domain value maps that can be setup through the SOA
Composer for mapping an instance of source system specific entity to a common value based of which
the cross-reference in the OOP repository gets established.

Figure 10. Selecting the DVM in SOA Composer

16
 Cross-References

The next screen in figure.11 shows the UOM name DVM that customers use for setting up the map
between each of the source system UOM names to a UOM name that will be considered to be
Common Value which is shown below under the TargetUOMName column.

Figure 11. Domain Value Map for UOM Name

Once the DVM’s are setup, the data can be collected through the services or using the staging tables.
For the Fusion sources, the data is collected from the Fusion sources through the ESS. Please refer to
the Collections documentation for the detailed steps for each of these methods. The following example
illustrates collecting of the data for one of the entity (payment term) through the web service approach.

The high level steps for collecting the payment term entity involves the following.

 Setup the DVM to map the source value to a target value if the payment term which is being
collected is already a payment term which has been collected from a different system and
which it should be mapped to. In the following example the payment term N30 was collected
earlier from a different system to which the payment term Net 30 is being mapped to. The
DVM mapping has to be setup to map the source payment term name to the target payment
term name as per the following table.

17
 Cross-References

Source System – LEG

Master Reference Entity Cross- Defined Source_Value Target_Value
referenced In DVM
Attribute
Payment term name Yes Net 30 N30

Table 3. Sample Data needed for setting up Payment Term Domain Value Map

 Invoke the Collections web service. The following is a sample payload for Collecting “Net 30”
payment terms from the source system “LEG”.

Payload:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body
xmlns:ns1="http://xmlns.oracle.com/apps/scm/advancedPlanning/collection/configuration/publicS
ervice/types/">
<ns1:processOrderManagementCodesLBO>
<ns1:instanceCode>LEG</ns1:instanceCode>
<ns1:omcList
xmlns:ns2="http://xmlns.oracle.com/apps/scm/advancedPlanning/collection/configuration/publicS
ervice/">
<ns2:srInstanceCode>LEG</ns2:srInstanceCode>
<ns2:PaymentTerms>
<ns2:sourceTermId>155</ns2:sourceTermId>
<ns2:name>Net_30</ns2:name>
<ns2:language>US</ns2:language>
<ns2:setId>155</ns2:setId>
<ns2:srInstanceCode>LEG</ns2:srInstanceCode>
<ns2:PaymentTermBase>
<ns2:startDateActive>2011-01-01</ns2:startDateActive>
<ns2:name>Net 30</ns2:name>
<ns2:srInstanceCode>LEG</ns2:srInstanceCode>
</ns2:PaymentTermBase>
<ns2:PaymentTermTranslation>
<ns2:srInstanceCode>LEG</ns2:srInstanceCode>
<ns2:name>Net 30</ns2:name>
<ns2:language>US</ns2:language>
<ns2:sourceLang>US</ns2:sourceLang>
<ns2:description>Net_30</ns2:description>
</ns2:PaymentTermTranslation>
</ns2:PaymentTerms>
</ns1:omcList>
</ns1:processOrderManagementCodesLBO>
</soap:Body>
</soap:Envelope>

18
 Cross-References

The below query shows the cross-reference data which gets populated in the MSC_XREF_MAPPING
entity for the attributes which are considered to be cross-referenceable attributes for the payment term
entity and based on the mapping done in the DVM. When DOO looks up the source system values or
the common values during integrating with fulfillment system or capture systems uses the cross-
reference data that gets populated into the MSC_XREF_MAPPIN entity during collections.

Figure 12. Cross-Reference Data in OOP Repository

Usage of Cross Reference Data

Once the reference data is collected along with the cross-references, Distributed Order Orchestration
uses the cross-reference data while the systems are interacting with DOO.

When an Order is received from an Order Capture system, the service that receives the order resolves
the source system to the Common Value based on the cross-reference data that is held in the Order
Orchestration and Planning repository. If the cross-reference between the source system value to the
Common Value is not established for the various attributes that are cross-referenced, the Order
submission process fails with an error.

Likewise when the fulfillment request is sent downstream, various task layers also cross-references the
values from the common value back to the source system specific value. Task Layer goes into an error
state if the source system specific value is not found in the OOP repository or in the Trading
Community model or product model.

With Fusion Apps Rel.5, there is an option provided in the Task Layers to bypass Cross-referencing
for customer related attributes. This rule will let implementers to publish the fulfillment request
downstream even if the customer cross-references are not established for that system. If such rule is
setup, DOO will send the fusion Id's for the customer data elements to the downstream system
without cross referencing. However if cross reference values exist, both the source system specific
values and Fusion identifiers will be sent. This allows supporting the scenarios where the fulfillment
request is for a new customer which doesn’t exist in the downstream system by allowing to create and
synchronize the customer information in the downstream integration layer/connector prior to sending
the fulfillment request to that system.

The following screen in Figure.13 shows the rule that was defined so that the cross-referencing of the
customer related attributes is not performed to allow the downstream integration layer to take the

19
 Cross-References

responsibility of creating or synching the customer information prior to sending the fulfillment request
to that system.

Figure 13. Sample Customer Xref Business Rule in EIL

Also when a response is received from a Fulfillment system, cross-reference is carried out in order to
convert the source system specific identifiers to the Fusion Common Values.

20
White Paper Title Copyright © 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
April 2013 contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
Author: warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
Contributing Authors: 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
Oracle Corporation
means, electronic or mechanical, for any purpose, without our prior written permission.
World Headquarters
500 Oracle Parkway
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Redwood Shores, CA 94065
U.S.A.
AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.
Worldwide Inquiries: Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license
Phone: +1.650.506.7000 and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open
Fax: +1.650.506.7200 Company, Ltd. 1010

oracle.com