TCA (Trading Community

Architecture) in R12 and Beyond

Presenter: Malik Aziz

Presenter Introduction
Malik Aziz, Rockland System Solutions
15 Years of experience in Financials and Supply Chain
12+ Years of experience in implementation of Oracle eBusiness Suite
and Oracle Certified Professional (OCP)
Numerous Oracle ERP Implementation projects varying in size
Currently with BCGOV as Solution Architect / Oracle Apps Specialist

Presenter Introduction
Rockland System Solutions
Specializes in ERP and application integration.
Core competencies include:

Management consulting and business advisory services

Project management services
Architecture services
ERP implementation services
Data warehouse solutions
System integration services
Business analysis and design services

Agenda
Trading Community Architecture (TCA)

What is TCA and its background

TCA data model and its components
TCA in R12 and beyond
Why TCA matters
Q&A

What is TCA and its Background

A Trading Community is
The participants in a community and their relationship to one another

Competitor

Competitor of

Partner of

Partner

Customer /
Organization

Employee

Employee of

Supplier of

Supplier

What is TCA and its Background

TCA = Trading Community Architecture
Provides a single, universal definition of trading partners
across applications and job function
TCA is an Data Model it is not a Module
Oracle E-Business Suite Application Families*

Sales

Service

Marketing Financials

TCA Enabling Infrastructure

Common Party UI, DQM, D&B Integration, APIs

TCA Data Model

HZ Schema

HR

3rd Party
Systems

What is TCA and its Background

A Trading Community Architecture
is a way to understand who our trading partners interact
with inside and outside the enterprise.
puts a foundation in place for a trading partner model
Linking Suppliers and Customers
Online Marketplace
Shared Service Centers

What is TCA and its Background

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

What is TCA and its Background

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

Old Model

TCA Model

AR
(Customer)

Organizations
(Organization)

AP/PO
(Supplier)

John, XYZ Inc

ABC Co.

John, XYZ Inc

Party:
ABC Co.

Customer of
Supplier of *

* Not currently implemented. Planned for R12:

Supplier tables move to TCA Model

Party:
John, XYZ Inc.

TCA Data Model

Old Model for

Customers

TCA Model

TCA Data Model: Implications

As we move towards the new TCA for all the tables, if you
have someone who is a customer and a supplier, youre going
to have to rationalize their definition. This means that you will
now have one definition for that participant.
Now you know that this customer owes you $X, while as a
supplier, you are trying to pay them $Y
If youve done any custom reporting or programming you may
need to re-work as underlying data model has changed

TCA Data Model: Major components

Party: defined as people, organizations, groups
or relationships. Represents the participants in the Trading
Community.
Account: defined as a financial roll-up point.
Contact point: defined as any electronic point that
you could use as a contact. For example, telephones,
URLs, email addresses, etc.
Location: a physical place.
Relationship: establishes the relationship between
any two parties.

TCA Data Model: Party Concept

A party is an entity/participant that can enter into a business

relationship

Person: A unique individual (dead or alive) of interest to the user.

Organization: A legal entity recognized by some government authority.
Group: A combination of two or more people, organizations or groups.
Relationship: User-definable link between two parties, regardless
of type.
A Party can belong to an unlimited number of relationships.
No duplication of entities

TCA Data Model: Account Concept

The financial roll-up point to track a customers purchases
and payments.
Stores details about a customer relationship between
a Party and your business.
A Party may have one or more Customer Accounts.
Because a party and accounts are separate entities,
no need to duplicate parties
Customer Account Sites: A Party Site that is used within the context
of a Customer Account (e.g., for billing or shipping purposes).
Customer Account Contacts: A Party Contact that is used
in the context of a Customer Account.

TCA Data Model: Contact Point

Concept

Contact Point - An identifier for a method of contact

(e.g., telephone, email, URL, fax, cell phone etc.)
This can be applied to:
A Party (person, organization, group or relationship)
A Site or Location
A Party at a Site or Location
An entity may have one or more Contact Points.

TCA Data Model: Location Concept

Location - A physical place, usually with an address.

Any number of location types. (e.g., bill-to, ship-to, mail-to).

No duplication of address
Maintain Customer History per address
Maintain Important Install Base info

Party Site
Links a Party with a Location and describes the usage of that Location
(e.g., mailing address, billing address, home address, etc.).
Parties may be associated to one or more Locations and any one
location may have one or more uses.

TCA Data Model: Relationship

Concept
Relationship Associates any two parties.

John is a customer of ABC Co.

John is a supplier to ABC Co.
TD Bank is a Competitor of Royal Bank
TD Brokerage is a Division of TD Bank

Has a Role Specifies the nature of the relationship

between parties (e.g., bill to, pay to, member of, contact at,
married to, Division of, Employee of).
Indicates the nature of the relationship
Tracks relationship history

TCA Data Model: Visualization

PARTY

Bill to
Ship to

SITE

Bill to

Bill to

Ship to

Bill to, Ship to

Account
Site

Site

Acct

Site

Acct

Bill to, Ship to

Account

Acct

Ship to

Account

SITE

PARTY

SITE

PARTY

Division Of

Bill to, Ship to

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

TCA in R12
New trading entities
Banks & Bank Branches
Suppliers
Legal Entity

TCA in R12: Leveraging centralized

data model
Payables
Purchasing
Suppliers

Payments

Global Tax

Party
Information

Governments,
Geographies,
Authorities, etc

Cash
Management
Banks and
Branches

Trading
Community
Architecture
Oracle Fusion Middleware

ERP

CRM

3rd Party

TCA in R12: Bank Account Model

Trading Community
Architecture (TCA)

Cash Management

Payables

Bank

Receivables
Bank Branch

Bank Account
Payroll
Treasury

TCA in R12
New Bank Account Model
Central place to define internal bank accounts
Keep track of all bank accounts in one place
Explicitly grant account access to multiple operating units/functions
and users

Multi-Org Access
In the new model, bank accounts are owned by Legal Entities with the
option to grant account use to Operating Unit (Payables, Receivables),
Legal Entity (Treasury), Business Group (Payroll)

TCA in R12: Bank Account Model

Pay invoices from different OUs with 1 instruction
New Payments Module
New Bank Module

OU A

New Bank & Credit Card Features

OU B

Payments
OU C

Single Payment
Instruction

Invoices

Bank

Sub Ledger
Accounting

TCA in R12: Bank Account

Model Benefits
Reduce number of access points to manage bank accounts
Centralized user interface

Improve visibility and control of bank accounts

Multi-org access control

Simplify bank reconciliation

Single bank statement can be reconciled across multiple
Operating Units

Increase percentage of automatically reconciled transactions

Bank account level reconciliation parameters add flexibility

TCA in R12: Supplier Representation

Supplier organizations are in TCA
Terms of doing business with the supplier are
in Purchasing / Payables
Supplier organization, address, contact, phone, email
etc. are all in TCA
Employees are already in TCA, Payables using the same
employee records in TCA
New supplier maintenance UI using TCA UI components

TCA in R12: Benefits of Supplier

Representation
Single repository for suppliers data
AR/AP netting
Oracle Payments serves as a payment data repository on top
of the Trading Community Architecture (TCA) data model. The
TCA model holds the party information. Oracle Payments then
stores all of the partys payment information and its payment
instruments (including credit cards, debit cards, customer
bank accounts, and supplier bank accounts).

TCA in R12: Supplier Data Mapping

TCA in R12: Legal Entities

Legal entity is created as a party of party type ORGANIZATION or
PERSON
An establishment is created as a party of party type
ORGANIZATION.
TCA creates a new classification category called Business
Function. It is used mainly to model what business functions a
party can perform in E-Business Suite
For modeling legal entities and establishments in TCA, classification
code Legal Entity and Establishment are created under the
Business Function class category.
An establishment is created as a party and always link to a party
that is classified as a legal entity through the relationship model

TCA in R12: Integration with HRMS

TCA creates the global view of person
TCA enables you to store person Information at a corporate
level
Person is stored as party in TCA
Comprehensive duplicate person check when entering a new
person Across the business group
Propagate some information entered in one business group to
the record in the other business group
PER_ALL_PEOPLE_F.PARTY_ID is a foreign key to the
HZ_PARTIES table, an integral part of Oracle's "Trading
Community Architecture" (TCA).

Why TCA Matters: What you get

Architecture to model your customers and other trading
partners as you see best for your business
Architecture that will grow with your requirements
Features to maintain extremely reliable customer information
(e.g. ABC Co. is now sure that their supplier John of XYZ Inc is
the same person as their customer, John of XYZ Inc)
Glue that ties several E-Business Suite flows in a seamless way
Customer Data Integration solution even if you are not
running a single E-Business Suite module
Platform that can play a key role in your IT landscape for
Master Data Management

Why TCA Matters: What you have to do

Take a close look at how you do business and how your
business processes are most efficiently performed
Ask questions about how you should model customer
information e.g. which entities should be modeled as parties;
when should you create an account; should you create
multiple accounts for some parties; should you create
multiple billing sites for an account; should you create
account relationships
Even if you are implementing few modules of E-Business Suite
to start with, keep in mind the bigger picture about customer
information

Q&A
Questions?

Contact :
malik@rocklandsolutions.com
Ali@rocklandsolutions.com