Trading Community Architecture (TCA) 101

Posted on October 22nd, 2008 by Sanjit Anand |  Print This Post |  Email This Post

Have you joined Hub Community Network Forums of OracleaApps professionals? Don't wait. Do

ittoday

Trading Community Architecture (TCA) is a structure which was based out of R11 Customer

Model designed to support complex trading relationships to cater additional need which further

extended in R12 with Supplier and Bank. So, TCA is a data model that allows you to manage

complex information about the parties, or customers or suppliers or bank who belong to your

commercial community, including organizations, locations, and the network of hierarchical

relationships among them.

What is Trading Community Architecture (TCA)?

What is TCA, the Trading Community Architecture? Is TCA an Oracle Applications module? Is it

functionality within an Oracle module? These are few common question, and there are often

many answers given.

The TCA is a data model that supports the entry and management of entities that you interact

with. So lets revisit the concept.

Trading Community Architecture is a Very flexible, very robust model which defines the

components involve in trading within in E-business Suite.

The implementation of technology and applications to allow users to create and maintain

relationships among entities

The universal data schema for customers, prospects, suppliers, distributors, resellers,

consortiums, bank across all Oracle EBS applications

TCA not only allows for the tracking of relationships between the implementing organization

and its trading partners, but also tracks relationships between the trading partners

themselves.

You should also note, TCA is neither an Oracle Applications module nor requires separate

license.

If you see TCA guide, you can find these are the key features of TCA

Provides a foundation for a single source for customer information.

Ability to represent all business entities as a “Party” (organizations, people, groups,

relationships) and to handle them the same way. This approach provides flexibility to

accommodate all B2B, B2C and hybrid models in the same repository.

Many-to-many relationships between Parties and Locations, that allows for less

duplication and easier updating.

Capability for advanced relationship modeling between entities within the trading

community. Any party can figure in any number of Party Relationships even within

matrix hierarchies (relationship networks).

Ability to setup and maintain any number of party classifications which can be used for

reporting and assignment purposes.

Extensible data model to enable various business data requirements.

In reality , three entities Drive in the TCA model , which are Party, Account, and

Relationships.

 TCA Terminologies

Partyo The concept of ‘Party’ enables the Customer Model to treat all business entities

equally, regardless of type. It easily handles B2B, B2C.

Parties of type ‘Group’ allow for the grouping of any number of other parties

into a single entity which enable modeling of households and buying

consortiums.o Parties of type ‘Relationship’ allow for the relationship between two parties to

be viewed as a party in its own righto Party - A Party is an entity that can enter into a business relationship and can

be of four types.

Person - A unique individual (dead or alive) of interest to the owner of

the software.

Organization - A legal entity recognized by some government

authority.

Group - a combination of two or more people, organizations or groups

of created for the use of the owner of the software.

Relationship - The association between an individual person and an

organization. Usually a contact at an organization or group.

Fig 1: TCA Logical Diagram

Accounto Account - Is a financial roll-up point to track the monitory portion of a

customer’s purchases and payments. Stores details about a customer

relationship between a Party and your business.

This Represents selling-buying relationship such as billing and shipping

events

Accounts required for a transaction

A account cannot exist without a partyo A Party may have one or more Customer Accounts

Account Role - The relationship that a Party has in regard to controlling

or using an account.

Customer Account Site is a Party Site that is used within the context of

a Customer Account (e.g., for billing or shipping purposes).

A Customer Account Contact is a Party Contact that is used in the

context of a Customer Account.

Customer

A customer account represents the business relationship that a party can enter in to

with another party. The account has information about the terms and conditions of

doing business with the party. For example, you could open a commercial account for

purchases to be made by Vision Distribution for its internal use and a reseller account

for purchases made by Vision Distribution for sales of your products to end-users .

You can also define contact people, bank accounts, payment methods, telephone numbers,

and relationships for each customer account.

You can also maintain multiple customer accounts for a customer that transacts business with

more than one line of business in your organization. You maintain separate customer profiles,

addresses, and contacts for each customer account.

A party site is the location where a particular party is physically located. Every party has only

one identifying address, but a party can have multiple party sites.

A customer address is a party site used in the context of a customer account for billing,

shipping, or other purposes.

A contact communicates for or acts on behalf of a party or customer account. A contact can

exist for a customer at the account or address level. A person usually acts as a contact for an

organization, but can also be a contact for another person. For example, an administrative

assistant could be the contact for an executive.

Old Model vs New Customer Model

Fig 2; Customer old model and TCA model

 

Locations/site :A Location is a point in geographical space described by an address. A

party site is a location.

Party Relationship :Any relationship between two parties of the above type (person

and organization) that needs to be stored as its. own record. Data that directly

corresponds to this relationship (contact info etc.) is stored as well. Relationships are

stored in the HZ_PARTY_RELATIONSHIPS table.

Factors which you can consider for TCA entities

Business requirement including your reporting

System/application requirement

Country or Organization Legal Requirement

Global Consideration

Process standardization

TCA Setup Considerations

When you are doing TCA customer Modeling, keep these things in mind;

Party be any real Person or Organization.

Party sites are locations for Party or Organization.

Relationships are generally used to construct hierarchical structure of Organizations.

Party becomes a Customer/Account, once a selling relationship is established.

An account should typically have at least one active ‘bill_to’ site. It helps for

accounting and reporting purposes.

When creating Parties, what all party sites can be or should be created as Parties.

Generally, if you want to see activities for site level separately from your parent level

party, you should create that Site as a separate Party/Entity.

An account is a separate entity. Create account only where you have selling

relationship i.e. only for customers. It identifies selling attributes e.g.payment terms,

shipping and billing preferences etc. of the relationship.

You can have multiple accounts, for each relationship between external party and your

business entity. It enables you to have multiple

sets of selling attributes e.g. payment terms etc.

You can build relationship between accounts and have one account to pay for another.

If transaction needs to be segregated within a party to perform granular analysis based

on selling or business relation,separate accounts with a party should be created.

TCA Integration with Other Oracle Products

This is how TCA data is tighten with other Oracle products.

 TCA Technical Tables

TCA - Customer : Here are Technical details for 11i/R12 customer in TCA. You can

also refer old post for customer model.

TCA - Suppliers

Here are Technical details for R12 Supplier in TCA. You can also refer old post for more details.

TCA - Bank

R12 : Bank & Trading Community Architecture(TCA)

Posted on November 26th, 2007 by Sanjit Anand |  Print This Post |  Email This Post

Have you joined Hub Community Network Forums of OracleaApps professionals? Don't wait. Do

ittoday

Read this:

1. http://www.oracleappshub.com/account-payable/r12-ebs-banking-model-in-demanding-

and-changing-world/

2. http://www.oracleappshub.com/account-payable/welcome-to-r12-account-payable/

Three key CE tables now as:

CE_BANK_ACCOUNTS for bank accounts

CE_BANK_ACCT_USES_ALL for account uses by Operating Units & Legal Entities

CE_GL_ACCOUNTS_CCID for bank account use accounting data

TCA and Bank

The TCA party model is being used to model banks and bank branches as parties with the

associated attributes of Relationships, Address, Contact and Locations. The TCA tables used by

Cash Management for modeling Banks and Bank Branches are listed below:

1. HZ_PARTIES

2. HZ_RELATIONSHIPS

3. HZ_RELATIONSHIP_TYPES

4. HZ_ORG_CONTACTS

5. HZ_ORG_CONTACT_ROLES

6. HZ_CONTACT_POINTS

7. HZ_PARTY_SITES

8. HZ_LOCATIONS

9. HZ_ORGANIZATION_PROFILES

The HZ_ORGANIZATION_PROFILES table stores additional attributes of banks and bank

branches along with the history of changes made to Banks and Bank Branches. The contact

person at the bank, bank branch and bank account is defined as a party in HZ_PARTIES, while

the contact details will be stored in HZ_CONTACT_POINTS (stores contact methods),

HZ_ORG_CONTACTS (stores the contact’s title) and HZ_ORG_CONTACT_ROLES (stores the

contact’s purpose or role). The address details of Banks and Bank Branches will be in

HZ_LOCATIONS (stores addresses) and HZ_PARTY_SITES (stores party sites).

The new table CE_BANK_ACCOUNT stores bank account attributes while the

CE_BANK_ACCT_USES_ALL table stores the bank account use attributes specific to Operating

Unit (AR, AP) and Legal Entity (Treasury).

The accounting data pertaining to the bank account use will be stored in the

CE_GL_ACCOUNTS_CCID table.

All of the bank, branch and bank account related attributes in AP_BANK_BRANCHES and

AP_BANK_ACCOUNTS_ALL tables will be upgraded to HZ_PARTIES and the new tables in Cash

Management.

Within TCA model, here is various attributes how they fits inside the model.