Log in

Login to your account

Username *
Password *
Remember Me

An Affiliate of OAUG

MDM SIG Banner


{tab Queries}

Here are some of the most recent queries on the CDM SIG Yahoo! Group.

1) Posted by Paul Goldstein on 8/3/2009

What is best practice with regards to TCA for setting up entities that do business with multiple segments of your company? For example, my company has an Interactive division and a Retail division. IfGeneral Electric (a customer) does business with both of those divisions in my company should we:Create a single General Electric Party and have 2 Customer Accounts for that Party - One for Retail, One for Interactive 
Create Account Sites as needed for each of those accounts.Or should we create 2 Parties (GE-Retail & GE-Interactive) with some relation between them? Or should we create 1 Party with 1 Account but then use Account Sites and Account Site Uses to determine which side of the business they are placing an order with?Responses:
From Tamer Chavusholu

"Given that you have two separate Operating Units (OU) for Interactive and Retail Divisions, you will be segregating based on the Account Site. Your GE party and account record will be global. You will set up an account site for each operating unit. Login using the specific responsibility tied to the OU and setup the account site and site use. You do not need to re-enter the location (address) after doing it once. You just re-use it from list of values when you are in the OU-specific account site setup.

Eg. Interactive Division will only be able to create an invoice for GE if GE has an account site setup using your Interactive Division OU responsibility. So you are really segregating based on OUs and transactions for your reporting."

From Oren Bierkatz

"The Oracle correct way to go is to have one single, all encompassing Party.
Then, as per your divisions, create accounts (several under the same party).
Why this way?
First, because of roll ups:
You can report on financial activity per account and per party, you'd have a hard time using any vanilla functionality in Oracle Finance going on the account site level.
Second, you might want to buy customer information in the future.
Good examples are D&B and Equifax.
In both cases, outside vendors will expect Oracle approved structures, so any deviation from that will make it real hard for you to use them, thus loosing a big potential business advantage."

From Mani Kumar Manda

"While I will make an attempt to answer your question related to having multiple business units without getting much into the issue of Party Centric vs. Site Centric approaches.   The solution design should take more scenarios into consideration apart from the question of how many accounts or accounts should be created, especially which customer model to follow – party centric or site centric approach. 

Let’s first take a look at the TCA design and driving principles and use them as a basis for arriving at the solution design.

Per TCA Axioms, “An account represents the attributes of the deploying company’s selling relationship with a party.  A real thing, such as a person or organization, cannot be an account.”  Accordingly an Account should be created every time you have a unique relationship with the Customer” – i.e., when multiple contracts or agreements or signed, or billing terms are different, or payment terms are different, and so on.

Party Information and Account information is shared across Operating Units, where as Account Site information is Operating Unit specific.

A new Account Site can reuse existing Address information by means of reusing the already existing Party Site, where multiple divisions belong to the same Operating Unit or different Operating Units.  However, please keep in mind that, you can not create multiple Account Sites for a single Account in a specific Operating Unit with all of the Account Sites pointing to the same party site.

The following questions are important for the scenario you have given:

How many accounts should be created when there are multiple business units/lines that deal independently with the same customer?

How many accounts should be created when there is a single business unit/line in your firm but your customer has multiple business units/lines and each of them is independent?  (or the variation is that only one business unit/line of your firm is transacting with multiple business units/lines of your customer)

Do both of your business units – Retail and Interactive Division belong to the same operating Unit or different Operating Units?

While the first question applies to only some companies, the second question is applicable to more companies implementing Oracle E-Business Suite (EBS) or CDH.  The solution can be determined by answering following questions:

Does having multiple business lines/units in your firm result in multiple agreements or contracts (written or otherwise), one each for each business unit/line of your firm?

Answer:  Create multiple Accounts – one Account associated for each Agreement or Contract if the answer to the above question is Yes.  Otherwise create one Account as long as there are no other differences (such as in billing terms, payment terms, etc.)

Does your Customer require signing of multiple contracts or agreement for each of their business unit or line that you are doing business with?

Answer:  Create multiple Accounts – one Account associated for each Agreement or Contract if the answer to the above question is Yes.  Otherwise create one Account as long as there are no other differences (such as in billing terms, payment terms, etc.)

With multiple accounts, you will have to create Account Site specific to each Account whether there are multiple Operating Units are involved or only one Operating Unit is involved.

You will also have to recreate Account Sites under each Operating Unit even if you have only one Account was created to represent the single contract signed with the customer.

You can further classify accounts (using Customer Class Code) into Interactive Account or Retail Account.  This classification will facilitate the easier identification of the Division given account information.  The classification of an Account is even more important if both of your divisions are under the same Operating Unit.

However, you do not want to create multiple Account Sites under single Account to represent multiple divisions of your firm, when only one contract and one Operating Unit exists but multiple divisions are there in your firm.  Unless you duplicate some of customer data at one or more of the levels (Account or Account Site, …), you will have to resort to transaction level data (probably order type for an Order, or transaction type for an Invoice),to identify which division of your company a particular transaction belongs to.

Whether to create one Party that represents all sites of the Customer or multiple parties one each for each site of the Customer or some where in between is another debate that you must go through by taking several aspects into consideration.  For example:

Importance of Customer data quality (Party Centric approach is more conducive for data quality)

What modules of EBS and specifically what functionality of these modules are being used?  (Refer to Customer Modeling: It's your call between Rock and Hard Place !!!  for some examples).  Some of the functionality in EBS requires you to use Site Centric approach.


What are your reporting requirements across multiple business units/lines, accounts, etc.?  (Site Centric approach is more suitable for aggregated reporting)

Are you using CRM Modules such as Oracle Sales?

Are your Sales teams Business Unit specific and/or Geographic Specific?  More specifically, the Retail Division and Interactive Division at your company share the same sales team or they have their own specific sales teams?

And many other questions like above need to be raised before an answer can be arrived at.

No matter what approach you take, you will have to make some compromises from the perspective of requirements given the way the current TCA design is implemented in Oracle EBS."

2) Posted By: Arif Girniwala on 9/16/2008

"What is the best practice around Customer creation when it comes to a single instance strategy :i.e 

1. Create Party in OCO and then create an Account using AR Forms

2. Create an Account in AR forms (and let TCA create the Party in the back end)"

There were numerous responses to this query.

From: Mani Kumar Manda

"Which UI (Customers Online, i.e., OCO or AR Customer Standard form) you use to create the customer data has less bearing on the customer model like Party Centric Model or Site Centric Model.  You can create customer data using either of the UI’s per both models that are on either ends of the spectrum or any where between.  The main difference is the data attributes you are capturing for these entities.

In R11i, the AR Customer Standard form is very limited in terms of what you can capture and maintain at Party layer, where as it is the best layer to capture and maintain account layer.  The same is true even in R12, except that the AR Customer standard form is more flexible and has more information, but not the complete information at the Party layer than R11i.

What this means is that you will probably have to use both AR Customer Standard form as well as OCO for one.  Which UI you use to create the customer first may also depend upon the overall sales process at your organization for some cases.  If you capture prospects first, you may probably be using Sales UIs which are very similar to OCO UIs.  If you are using only Financials part of E-Business Suite, then you can create the customer in AR Customer standard and augment the customer with more data at party layer in Customers Online UI.

More important factor that determines what model you can use within the context of E-Business Suite application is (especially in a single instance platform) is the foot print of Oracle E-Business Suite that you are using, and does this single instance covers only North America or Global and if it is Global, does it include Latin America.  For example, your choices about the model you can use are impacted in Latin America due to regulatory reasons, if your verdict is to go with Party Centric Model (You can refer to Ken Blanz’s presentation at OAUG Collaborate 2008 titled “Emerson Process Management: Migration of TCA to Best Practice” for some insight about Latin America).  In terms of an application footprint, if you use iStore and would like to allow customers sharing shopping carts with colleagues for example, you can not create the customer data per Party Centric Model, rather you will have to create as per old Site Centric Model.  You can have many use cases addressing the application functionality in the white paper titled “Customer Modeling:  It’s your call between Rock and Hard Place” in the Conference Paper Archive folder under Files section of the CDM SIG Group."

From: Tushar Kureishi

"Oracle's recommended best practice, if possible, is to have a stand-alone Hub for customer mastering. That way you do not have to make compromises on  your customer modeling best practices and take sub optimal decisions in order to take care of visibility, roll-ups and usability of data in some transactional application which happens to sit on the same customer model and then, carry along that decision to ALL of your other subscribing systems.

May I suggest that you strongly consider this approach (of deploying a stand alone hub)?
Sure, it doesnt come for free, it requires extra hardware and the mapping of your Hub to your EBS instance which is made easier with our Business Object APIS and Busines Object events and the Ebiz adaper in Jdeveloper. But it may be worth the endeavor.
Cant deploy a stand-alone hub, read on..
Here is the crux of the matter in Mani's words:
"Which model you can use within the context of E-Business Suite application is (especially in a single instance platform) is the foot print of Oracle E-Business Suite that you are using, and does this single instance covers only North America or Global and if it is Global, does it include Latin America. "

Remember, CDH is a real-time, operational data hub, if you want optimal performance and use of the operational Hub you dont want to encumber it with challenged modeling practices."

OAUG on Twitter

No recent Twitter posts to display.

A Message from OAUG