Real World Oracle Apps: Oracle Trading Community Architecture (TCA)

I have seen many clients who do not understand the power of TCA architecture and how they can effectively use the TCA model to design their customer master. In this post I will explain the key TCA concepts and I will also try (in later posts) to take a real world example of customers and model it in the Oracle Release 12.1.3 environment.

TCA = Trading Community Architecture; Data Model and not Module. TCA provides a single, universal definition of trading partners across applications and job function.

A Trading Community Architecture is a way to understand who our trading partners interact with inside and outside the enterprise. TCA puts a foundation in place for a trading partner model:

Linking Suppliers and Customers
Online Marketplace
Shared Service Centers

How did TCA come about?

First introduced in 11i
Introduction of Oracle CRM application
Requirement for a common customer model for all Oracle Applications
Model evolved from working with ERP and CRM teams to create a view of the customer base which supports all flows throughout the E-Business Suite
To support both B2B and B2C business models
Re-architected to enable future support for entire trading Community

Guiding Principles of TCA:

Create a central repository for the entire E-Business Suite to store information relating to all members of a trading community versus separate tables for each member
Prospects, Customers, Contacts, Employees, Partners, Distributors, Suppliers, Banks, etc.
Record complex business relationships between Trading Community entities (including 3rd party relationships)
Support all business models, industries, and geographies

TCA Data Model: Parties vs. Accounts:

From an application perspective, one of the most important things to understand about the TCA model is that the concept of “customer” is separated into two layers: The Party layer and the Account layer.
When CRM applications refer to “Customer” they are referring to the Party Layer.
On the other hand, when ERP applications refer to “Customer” they are referring to the Account Layer.
Thus, confusion arises because both are using the word “Customer” to refer to two different things.

Other features of TCA:

Public API’s for data manipulation of TCA tables
Common Party User Interface Components
Hierarchy Model
Bulk Import of customer data and D&B Integration
DQM for duplicate prevention
Party and Account Merge

TCA data dictionary:

HZ Parties - Stores basic information about parties and their relationship. Party ID is the primary key. Party id, Party Number, Party Name and Party Type are key columns. Establishes the Business Relationships.
HZ Locations - Stores delivery or postal address. Location ID is the primary key. Not to be used for modeling party hierarchical relationships (use party relationships). Identifies the Party and its Account. Location can cross Parties and a Party can have multiple Locations. Account (beneath the Party) inherits the Locations defined for the Party.
HZ Party Sites - Table that links HZ Parties with HZ Locations. Party Site ID is the primary key.
HZ Cust Accounts - Different instances of Business Relationships (Selling, etc). Multiple Accounts can exist for a Party. Cust Account ID is the primary key.
HZ Cust Acct Sites All - Site reference to the Account . Partitioned by Org Id. Primary Key is Cust Acct Site Id.
HZ Cust Site Uses All - Stores business purpose usage (Bill To, Ship To, etc) for the Customer Account. Site Use Id is the Primary Key. Integrated with HZ Cust Acct Sites All.
HZ Customer Profiles - Stores credit characteristics of Party, Account, Site.
HZ Party Relationships - Stores relationships between parties.