R12 Oracle Trading Community Architecture (TCA)

Oracle TCA:

• Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
• The TCA  information is maintained in the TCA Registry, which is the single source of trading community information for Oracle E-Business Suite applications.
• TCA is a data model not a module.
• Oracle Trading Community Architecture (TCA) is a product owned by Oracle Accounts Receivable (AR), and is used extensively within the Oracle Financials and Manufacturing applications.
• Oracle Trading Community Architecture (TCA) is Product Code = 1137.
•  The TCA tables are tagged with the naming convention of HZ_ tables
  

Centralized Data Model in  TCA R12

Before TCA:

• There are multiple customer definitions across the enterprise.
• Difficult to track current and historical information about the customers.
• Lack of support .
• Difficult to understand relationships between customers and others (suppliers, partners, competitors)

After 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,Suppliers/Vendors,  Contacts, Employees, Banks, Partners, Distributors etc.
• Record complex business relationships between Trading Community entities (including 3rd party relationships).
• Support all business models, industries, and geographies.

In R12 the TCA defines all as parties under HZ_parties so  for each it will create an Party_id which can be sahred across LE's & OU's .

TCA Components:

Customer Intergration with R12 TCA:

• Old Customer standard form that has been existing from ages is
finally gone.
• Oracle introduced a brand new HTML user interface built using
Oracle Applications framework leveraging TCA that can be used to manage Customers, Accounts, Account Sites, etc.
• New UI is fully backward compatible with the form
• Has more features than the form
• UI’s built using OA Framework can be personalized
• New UI displays both Party level as well as account level
information which is separated into Customer Overview and Account Overview
• Find Customer screen now uses DQM (Simple and Advanced Search Match Rules) similar to what you see in CustomersOnline or Customer Data Librarian.
• After search, you can create new customer or see customer overview. From here you can add accounts or modify accounts and so on.
• You can update customer information from customer overview
page.

Party Vs Customer:

• In the TCA Model the concept of "customer" is separted into 2 layers, The party layer and the Account Layer.
• CRM Application are refering to Party Layer when they refer tocustomer
• ERP Application on the other hand are referring to Account layer when they refer to Customer.

Customer Details  in 11i TCA:

Customer Details in R12  TCA

Supplier Integration with R12 TCA:

Release 12 Suppliers have moved to the TCA Data Model.

Supplier organizations are in TCA

Terms of doing business with the supplier are in Purchasing / Payables

Suppliers are now integrated with TCA.

Supplier entity level (party) level information can be viewed inOracle Customers Online.

Employees who were created as Suppliers for expense reimbursement now are associated with Person Parties.

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

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 party’s payment information and its payment instruments (including credit cards, debit cards, customer bank accounts, and supplier bank accounts).

Suppliers can have multiple addresses and each address can be used by an operating unit through a supplier site record.

In Release 11i , creation of supplier record in Accounts Payable records were inserted into PO_VENDORS. In Release 12 these tables are now updated when creating a Supplier Record.

 1. Creating a supplier in AP now creates a record in HZ_PARTIES. In the create Supplier screen, you will notice that that Registry_id is the party_number in HZ_Parties.

2. The table hz_party_usg_assignments table stores the party_usage_code SUPPLIER, and also contains the given party_id for that supplier. Running this query will return if customer was a SUPPLIER or CUSTOMER
3.Payment related details of supplier are also inserted in  iby_external_payees_all as well as iby_ext_party_pmt_mthds
4. The master record that replaces PO_VENDORS is now AP_SUPPLIERS. PO_VENDORS is a view that joins AP_SUPPLIERS and HZ_PARTIES.
5. The table that hold mappings between AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID is PO_SUPPLIER_MAPPINGS. Query by party_id.

The following sql  can be used to find out Party details from Supplier tables

SELECT DISTINCT a.party_number, ps.party_site_number, a.party_id,

'CUST-' ||a.party_id||'-'||ass.org_id AS customer_ref,

'ADD-'||ps.party_site_id||'-'||ass.org_id AS address_ref,

ps.party_site_id,

ass.address_line1,

ass.city, ass.state, ass.zip, ass.country,

a.orig_system_reference AS party_ref,

a.party_name AS customer_name,

ass.org_id

FROM ap_suppliers ap,ap_supplier_sites_all ass,

hz_parties a,hz_party_sites ps

WHERE ap.vendor_id = ass.vendor_id

AND a.party_id = ap.party_id

AND ps.party_id = ap.party_id

AND ass.party_site_id = ps.party_site_id

AND a.party_name = ap.vendor_name

and a.party_id = 12345 -- Please pass your Party_id or Comment this line

and NOT Exists (select 1 from hz_cust_accounts a

where a.party_id = a.party_id);

TCA Supplier:

TCA Supplier Site:

In R12 in the Suppliers Entry screen all the addresses in the address book are available to all responsibilities regardless of the Operating Unit the responsibility is attached to.

The supplier addresses come from HZ_LOCATIONS, which is not Operating Unit specific

Therefore all the addresses from the suppliers address book are available in the suppliers screen regardless of the supplier sites they may be attached to, what is not available are the sites attached to those addresses if the security profiles does not allow the user on that responsibility access to those operating units.

 In the supplier address book if the address is attached to a site; for any given responsibility, only the sites that responsibility has assigned to via the MO Profile Options / Security Profile will be shown; if the site that the address is attached to is restricted for that responsibility, that site will not be shown, however, the address is always shown.

Banks Model 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).
• 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.
  

  




Three key CE tables now as


1. CE_BANK_ACCOUNTS
==> Stores bank account attributes
2. CE_BANK_ACCT_USES_ALL
 ==> Stores the bank account use attributes specific to Operating Unit (AR, AP) and Legal Entity (Treasury).
3.CE_GL_ACCOUNTS_CCID 
===>Accounting data pertaining to the bank account use

Legal Entities in R12 TCA: 

• 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
• 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.

HRMS Intergration with R12 TCA: 

• 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).

If you create a supplier for an employee, you cannot change the Supplier Type from an Employee. The TCA Person Party that represents the employee is also used to represent the supplier. TCA does not allow you to change a Person Party into an Organization party. For standard suppliers, you can update the Supplier Type after the supplier has been created. However, you cannot change it to Employee.

Within the HRMS application we carry the PARTY_ID value within some of the  tables as a foreign key. Conversely the TCA product carries the PERSON_ID value within some of their tables as a foreign key  within column PERSON_IDENTIFIER.

 Responsibilites in TCA:

• Trading Community Manager

Reference My Oracel Support:
Note#:159393.1,1447883.1,230753, 1409305.1, 1160816.1