R12-TCA -Trading Community Architecture

1.Overview 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.

TCA is a universal data schema for

1. Customer
2. Bank and Branch
3. Supplier
4. Student
5. Employee
6. Legal entity & intercompany
7. Prospects
8. Distributors
9. Resellers
10. Consortiums

TCA Terminology

A Party is any entity with which you could potentially do business. It could be an organisation, an individual or

a relationship (like a partnership or consortium).

A Location is a point in geographical space described by a street address. In previous releases of Oracle, there

was a risk of some data redundancy if more than one customer shared the same site or location. The new

model eliminates this redundancy.

An Account represents the business (selling) relationship that a company deploying Oracle Applications has with

a party. (Thus your customers have become accounts as you migrated to 11i and your old Accounts

Receivable customer number is now the new TCA account number.). You can have more than one account

with a single party, if you need to model separate selling relationships. For example two of your lines of

business might conduct business with a party on different terms.

A Relationship between 2 parties is also treated as a party of the type relationship. Relationships can be

independent of you (the deploying company), thus you can now capture the link between a partner who sells

on your behalf and their customers, as well as relationship between your customers like “competitor of”.

A Party Site links a party with a location, indicating that party’s usage of the location.

An Account Site is a party site that is used by a customer account, for example, for billing or shipping purposes.

(Account Sites are Organisation specific in Multi-Org terms, just as Customer Sites were.)

A Contact is a person in the context of an organisation, modelled as a relationship between an organisation and a

person or between two people, (this can be either a party contact or an account contact).

A Contact Point is a means of contacting a party, for example, a phone number, e-mail address, or fax number.

2 . Suppliers – Moved to TCA

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

 

TOI : Solution Overview

The Supplier, Sites/Locations, and their Contact information will be migrated to TCA. As part of the migration we have introduced three new tables: AP_SUPPLIERS, AP_SUPPLIER_SITES_ALL, and AP_SUPPLIER_CONTACTS. These tables will hold the attributes that represent the terms and conditions of the deploying company doing business with this supplier and the necessary transaction defaults. To minimize the impact to the other products, views are provided with the names PO_VENDORS, PO_VENDOR_SITES_ALL, and PO_VENDOR_CONTACTS. These views will be based on the information from TCA and Payables Suppliers tables.

As a result of this, the Suppliers (AP_SUPPLIERS) will represent the Supplier account and will carry all Supplier level profile information that will default to the transactions. The Suppliers Sites (AP_SUPPLIER_SITES_ALL) will represent the supplier site account information in the context of an operating unit. The Contacts (AP_SUPPLIER_CONTACTS) are created to support backwards compatibility, so that impacted products (such as Purchasing ) do not have to upgrade transaction data that carries the reference to vendor contact IDs.

Note: The existing Suppliers tables PO_VENDORS, PO_VENDOR_SITES_ALL, and PO_VENDOR_CONTACTS are obsoleted and renamed as PO_VENDORS_OBS, PO_VENDOR_SITES_OBS, and PO_VENDOR_CONTACTS_OBS.

• Suppliers — With the new architecture, the Supplier entity will represent the supplier account for a party record in TCA. The Suppliers table will be updated with the unique Party identifier for reference purposes.
• Supplier Sites — The supplier sites table will store the Site account attributes per Operating Unit, which will default into transactions. Going forward, supplier site creation will involve either selecting an existing location for the supplier or creating a new location in HZ_LOCATIONS. The user will then have to select the Operating Unit based on the security profile, and enter the site attributes as they are entered today.
• Contacts — Contacts are modeled as a child entity to Supplier Sites in Release 12. Since the Supplier Sites are striped by Operating Unit, the contact records are implicitly striped by Operating Unit. This required our customers to enter/maintain the same contact information more than once if the implementing company did business with the same Supplier Site in more than one Operating Unit.
  For example: Adam Smith is the Contact in the San Mateo site of ABC supplier. If Company A does business with ABC supplier from two operating units, then the contact Adam Smith should be entered as a contact twice, once for the San Mateo Site – OU1 and another for the San Mateo Site – OU2. In an ideal case, Contacts could be defined for Supplier or for a particular Location of the Supplier. There is no need to stripe the contact information by Operating Unit. With the decision to move the address information to TCA, the suggested approach for modeling contacts would be to leverage the TCA contacts model completely.
  Contacts in TCA are modeled differently. Each contact (person) is represented as a party first. A relationship is then created between the person party and the organization party (customer, supplier, etc). This relationship itself is reflected as a party record in TCA. All the contact points (for example, email, fax, phone) are tied to the party record, which represents the relationship. The contact information can be defined for a Party, Party Site, and Party Relationship in TCA. Since contact information is maintained at the Supplier Site level for a particular Operating Unit, Payables will do an as-is approach to replicate the data into TCA. TCA does not have the relationship party reference with respect to the Site (it is not required), AP will have to link Supplier Site contact to the TCA Relationship party using the TCA’s HZ_ORG_CONTACTS table. The HZ_ORG_CONTACTS table will carry some information about the contact such as department information.
  If we take the case mentioned above, Adam Smith will be defined as a person party. One new relationship record will be created between Adam Smith and ABC Supplier. This relationship is also a party. All the information about Adam’s Departments will be moved to Org Contacts with reference to the San Mateo Site and Adam’s relationship with ABC Supplier. All contact details will be represented as Contact Point records against the relationship party reference.

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

Suppliers open interface tables in Release 12

There is a new interface table for banks in R12 ,IBY_TEMP_EXT_BANK_ACTS. If records are populated in the IBY External Payee Accounts table, then the program will call the necessary APIs from Oracle Payments to create the Supplier Bank Accounts for the supplier/site.

3 . Banking Details – Moved to TCA

 

If we compare the bank with 11i vs R12, we can notice the bank was utilized into three different places,which requires altogether a different setup.

• finance
• payroll
• treasury

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

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.
• Internal Bank Account in Cash Management which is owned by a Legal Entity. Here the Operating units have granted usage rights
• 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
• 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

 

Three banks you can manage in EBS

• House Bank or internal bank – 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.
• External bank for supplier and Customer – 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.
• Intermediary bank for SEPA payment : An intermediary bank is a financial institution that as a relationship with the destination bank (in this case the supplier bank account you are setting up) which is not a direct correspondent of the source bank (the disbursement bank in AP/Payments), which facilities the funds transfer to the destination bank.

• This is important when paying a foreign supplier from a domestic disbursement account, there may be an intermediary bank used, and it would be set up on the supplier bank account. Although the intermediary bank UI is owned by Payments, the implementation is as embeddable UI components in pages owned by i-supplier Portal (suppliers) and AR/Collections (customers). You can enter intermediary bank accounts on Suppliers->Entry->Banking Details->Bank Account Details

In Release 12, bank accounts can be assigned at the following four levels:

1. Supplier

2. Site

3. Address

4. Address-Operating Unit

New accounts can be created using existing bank and branch details or new bank/branches can also be entered.The bank accounts for a supplier can also be setup from iSupplier portal and this initiates a change request process. The buyer administrator is notified of the bank account addition in the “To-Do List” and can either approve the account, verify the account or reject the account assignment.

TCA Model – Bank  

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

Key Tables in Cash Management & TCA

• CE_BANK_ACCOUNTS 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 for bank account use accounting data

Bank accounts, bank account uses are migrated into cash management. Bank Accounts will be stored in a new table called CE_BANK_ACCOUNTS and will be located at a Bank Branch

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.

 

 

ER Diagram(Bank Model) TCA ,Bank & Suppliers

Table level information

• The supplier bank account information is in the table: IBY_EXT_BANK_ACCOUNTS, the bank and bank branches information is in the table HZ_PARTIES.
• 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.
• 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
• Payment related details of supplier are also inserted in iby_external_payees_all as well as iby_ext_party_pmt_mthds
• IBY_EXT_BANK_ACCOUNTS, the bank and bank branches information is in the table: HZ_PARTIES.
• The master record that replaces PO_VENDORS is now AP_SUPPLIERS. PO_VENDORS is a view that joins AP_SUPPLIERS and HZ_PARTIES.
• The table that hold mappings between AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID is PO_SUPPLIER_MAPPINGS. Query by party_id.
• The bank branch number can be found in the table: HZ_ORGANIZATION_PROFILES .The HZ_ORGANIZATION_PROFILES table stores a variety of information about a party. This table gets populated when a party of the Organization type is created.

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

Obsolete Tables

Table Name	Feature Area	Replaced By
AP_BANK_BRANCHES	Bank/Bank Branches	CE_BANK_BRANCHES_V
AP_BANK_ACCOUNTS_ALL	Bank Accounts including Internal and External	CE_BANK_USES_OU_V/IBY_EXT_BANK_ACCOUNTS_V
AP_BANK_ACCOUNTS_USES_ALL	Remit to Bank Account Uses