Trading Community Architecture (TCA) 101

Trading Community Architecture (TCA)

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

Party
- 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.
- Parties of type ‘Relationship’ allow for the relationship between two parties to be viewed as a party in its own right
- 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

Account
- 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 party
- 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)

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:

HZ_PARTIES

HZ_RELATIONSHIPS

HZ_RELATIONSHIP_TYPES

HZ_ORG_CONTACTS

HZ_ORG_CONTACT_ROLES

HZ_CONTACT_POINTS

HZ_PARTY_SITES

HZ_LOCATIONS

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.

R12 : EBS Banking Model in demanding and Changing World

Hey did you notice there is one thing that keep changing since last 2 releases ...the bank. We have seen there was once from pre 10.x to 11i when supplier bank separated from suppliers data and now its again in R12 when it become part of TCA.This time , because of changing business need and high demand of global partners working model. Not only your company is operating globally,your partner too operating global,then why not use them. In typical business cost model, if corporate office is using Citibank for payroll for USA operation then why not Citibank Singapore branch is used for payroll for Singapore if they are operating there. Sound bit low...why ..

As we aware the key message of R12 while release was .

Think Globally - using business intelligence and analysis tools

Work Globally - using the global capabilities of the applications

Manage Globally - using the latest system architecture and middleware

so what , think globally and work globally is factor driving for the changes .This release have witness the great changes ever into the bank model. Now the bank accounts is attached to your legal entity level rather than Operating Unit in which current and existing versions Offers. This makes bank with strong capability to pay across operating units. More over its important to understand banks accounts can be shared by applications and can be designed for use by Payables, Receivables and Payroll.

What is new in R12 for Bank

These changes make easier and more reliable by

Single access point

Single Legal Entity ownership

Usage rights granted to one or more Organizations

Reconciliation option defined at Bank Account level

More flexibility and control

Take a looks of some of the releases

Release 10.6 character/10.7 NCA to 11i
How 10.x supplier banks are mapped to 11i

Bank Namepo_vendor_sites.bank_number => ap_bank_branches.bank_name
po_vendor_sites.bank_number => ap_bank_branches.bank_number

Bank Number
po_vendor_sites.bank_num => ap_bank_branches.bank_num
po_vendor_sites.bank_num => ap_bank_branches.bank_branch_name

Bank Account Namepo_vendor_sites_all.bank_account_name => ap_bank_accounts_all.bank_account_name

Bank Account Numberpo_vendor_sites_all.bank_account_num => ap_bank_accounts_all.bank_account_num

Release 11i

These are tables which hold the bank details irrespective of supplier or internal banks.

ap_bank_branches

ap_bank_accounts_all

Comparing the 11i Vs R12

If we compare the bank with 11i vs R12, we can notice the bank was utilized into three different places , finance ,payroll and treasury, which requires altogether a different setup. It was one of the big issues with integration aspect, as significant problem was recognized once the Expense management and payroll uses same bank for the respective person.

There was a common question/confusion between the Integration Existence between Bank Data in Accounts Payable and Bank Data In Payroll ?

As discussed above , you know most of release of 11i family of oracle Application does not have integration between HR and AP for bank account data.

We have notice in 11i there was functionality in which Payables in which we will create an employee type supplier from HR data and it will contain name and address info but not bank information. The reason for this is that HR/Payroll does not store the bank information in a standard way that makes the integration possible.

So now r12 this was well taken care and integration is built. There are plans under way for all bank account data models in the various products to be consolidated in the new TCA architecture. The Cash Management team is working on this project. Payables and HR/Payroll are working so that the eventual idea will be that you can set up bank accounts in one place and then indicate the usage (pay, expense reimbursement, etc).

For understanding it is comparison between 11i and release 12 , where TCA community take cares of every things.

Release 12 , what is new than

Bank Accounts will be stored in a new table called CE_BANK_ACCOUNTS and will be located at a Bank Branch.

The new table which hold the bank information are as:

CE_BANK_ACCOUNT:stores bank account attributes

CE_BANK_ACCT_USES_ALL : This stores the bank account use attributes specific to Operating Unit (AR, AP) and Legal Entity (Treasury).

CE_GL_ACCOUNTS_CCID :The accounting data pertaining to the bank account use will be stored in the table.

This new data model allows the bank and bank branch entities to be defined separately allowing users to establish a hierarchical relationship between them.

Missing link between Supplier And Supplier Banks?

You should know

The link between PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.

The link between PO_VENDOR_SITES_ALL and HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.

When a Supplier is created Record will be Inserted in HZ_PARTIES. When the Supplier Site is created Record will be Inserted in HZ_PARTY_SITES. When Address is created it will be stored in HZ_LOCATIONS

When a bank Is Created, the banking information will be stored in

IBY_EXT_BANK_ACCOUNTS IBY_EXT_BANK_ACCOUNTS.BANK_id = hz_paties.party_id

When the Bank is assigned to Vendors then it will be updated in HZ_CODE_ASSIGNMENTS.

HZ_CODE_ASSIGNMENTS.owner_table_id = IBY_EXT_BANK_ACCOUNTS.branch_id.

Internal Bank Accounts & Supplier and Customer Bank Accounts in R12

Internal Bank Accounts
In Release 12, each internal bank account is assigned to a Legal Entity. Any or all operating units associated with that legal entity are permitted to use that bank account.
Supplier and Customer Bank Accounts
In Release 12 provides a centralized repository for suppliersâ€™ and customersâ€™ bank account and credit card information. All data is stored in one, secure place, providing shared service centers and collection departments consistent information that they need.

Welcome to R12 Account Payable

As we learnt during Release 12, the E-Business Suite has couple of new products like Subledger Accounting, E-Business Tax thus significant changes have been observed in Account Payable data module as some of functionality is shared by some other products. Thus it is important to understand what is new. I would like to briefly outline the details of some of new changes and underlying impact on the objects. More details can be found in R12 release documents published by Oracle a month ago.

Let’s have a dissection view of R12 payable, with some of its core objects

Supplier

We have seen in 11i

Suppliers defined in AP.

Supplier contacts replicated for each supplier site.

Where as in R12

Supplier becomes as TCA Party.

Suppliers Sites as TCA Party Site for each distinct address.

Contacts for each supplier/address , it means Single supplier address and contact can be leveraged by multiple sites, for each OU

A single change to an address can be seen instantly by all OUs

No longer need to manually 'push' updates across OUs.This can be best understood by the figure below.

Then the question is what will happen if any one can come from existing financial products. The Impact from upgrade can summarize as:

1. When we upgrade supplier tables replaced with backward compatible views.

2. One party site for each distinct supplier site address

Country and address line1 are required, this is because creation of suppliers in Party in TCA data model would requires Country and address information, but it also understood if there is no country or address line 1 specified for a supplier site in cases when upgrades takes place, Payables derives the country based on the most frequently used operating unit of the Supplier's historical transactions.

3. Employee as suppliers: address NOT migrated to party site in TCA remains in Oracle HR for data security reasons.

As we know in 11i employees are part of internal supplier's record in order for Oracle Payables to create payments for their expense reports. Employees defined in Oracle Human Resources and associated with an Oracle Payables supplier record have existing party information. During the upgrade, Oracle Payables updates the existing party information to have a party usage of supplier but it does not migrate the employee address to the party site in TCA, they remain in Oracle Human Resources for data security reasons.

4. Utilize TCA Party relationships for franchise or subsidiary and its parent company.

Invoice

Till 11i version, we have seen invoices:

Had only distributions line.

Allocation of freight and special charges are captured at the distribution level only

Tax and payment and Project accounting Payment was captured through global Descriptive Flexfields.

But in R12,

1. Invoice Lines as a new additional line accommodated in Invoice data model.

Because of introduction of invoice line there is significant improvement of data flow with n other oracle modules like

Fixed Asset - Asset Tracking

Business Tax - Tax line

Payment - Payment

SubLedger Accounting - Accounting

2. Allocate freight and special charges are captured to the lines on the invoice
3. Invoice distributions created at the maximum level of detail similar to 11i.
4. Core functionality

The impact with Upgrade can be summarized as:

1. One invoice line for every distribution in 11i
2. Sub Ledger Accounting requires that Payables transform the invoice distributions to be stored at the maximum level of detail
3. Global Descriptive Flexfields migrated to named columns.

That's means functional testing is more required while upgrade takes place.

Banks and Bank Details

Now a days corporate treasury role has been greatly enhanced thus picking up a global bank as partner for all banking need is demand of time in global working model. The recent couple of years have seen drastic increase in acquisition and merger of company thus global working as well as global instance get popularity in ERP areana, and this is one of reason of the reason bank data model has been significant changes from 11 to 11i and 11i to R12.

Internal Bank AccountsIn 11i we have seen internal Banks defined in AP and that is shared by AP/AR/CE, Payroll and Treasury and they are bank accounts often replicated in multiple OUs

Where as in R12,

Bank and Branch become part of TCA Parties.

Internal Bank Account in Cash Management which is owned by a Legal Entity. Here the Operating units have granted usage rights.

Suppliers Bank Accounts
In 11i

Banks/Branches defined in AP

Bank accounts often replicated in multiple OUs Before

R12

Suppliers, Banks and Branches are defined as Parties in TCA

Supplier (party's) payment information and all payment instruments (Bank Accounts, Credit Cards) moved into Oracle Payments.

The typical data model for bank can be summarized as:

Impact of Upgrade

1. With Upgrade banks and branches migrated to TCA parties
2. Banks merged if the following attributes are all the same:

a. Bank Number
b. Institution type
c. Country
d. Bank admin email
e. Bank name alt
f. Tax payer ID
g. Tax reference number
h. Description, Effective dates

3. Bank accounts, bank account uses are migrated into cash management.
4. Transactions are stamped with the bank account uses identifiers as part of the upgrade

Integration with Oracle E-Business Tax

In 11i

Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was controlled at underline code.

There was global descriptive flex fields were captured for country-specific tax attributes.

More importanta most of the setup performed at OU level.

In R12

A new module eBusinessTax determines tax based on facts about each transaction, this is reason why Oracle has introduced additional line information at invoice level.

The module "ebusiness Tax" set and configure Tax rules which can be viewed

Tax attributes collected in fields on key entities

Configure tax rules once per regime and share with your legal entities

Impact of Upgrade
1. Payables Tax setup, Tax Code defaulting rules defined per OU are migrated to eBusiness Tax.
2. OUs migrated to tax content owner in R12
3. Tax information in tax codes are transformed to Regime-Rate flow.
4. E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in the E-Business Tax repository.

Multi Org Access Control

MOAC is new enhancement to the Multiple Organizations feature of Oracle Applications.

This feature enables user to access data from one or many Operating Units while within a set given responsibility. Due to this change, all processing and some Reporting in Oracle Payables is available across Operating Units from a single Applications responsibility. Hence you can isolate your transaction data by Operating unit for security and local level compliance while still enabling shared Service centre processing.Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

Impact of UpgradeR12 Upgrade does not automatically create security profiles, thus is important if any one want to use Multiple Organizations Access Control, the first things is to define security profiles, then link them to respective responsibilities or users.

Reference: Details can be found more on R12 RCD documents, from Oracle site