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

ServiceMarketing
Financials

HR

TCA Enabling Infrastructure

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

TCA Data Model

HZ Schema

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)

Organization
s
(Organizatio
n)

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

SITE

Ship to

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
Payable
Purchasi s
ng
Suppliers

Global
Tax
Governments,
Geographies,
Authorities, etc

Payment
s
Party
Informatio
n

Cash
Manageme
nt and
Banks
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

Bank Branch

Bank Account

Receivables

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
Accounti
ng

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 EBusiness Suite to start with, keep in mind the bigger
picture about customer information

Q&A
Questions?

Contact :
[email protected]
[email protected]