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

Oracle TCA - R12

TCA- What's New in R12:
======================
What is Oracle TCA:

Trading Community Architecture (TCA) is a model for maintaining
information about parties and customers who belong to an
enterprise's commercial community. Parties can be people or
organizations that can enter into business relationships accross
the e-Business Suite.

The main purpose of TCA is to provide a single source of information
in the TCA Registry for all Oracle e-Business Suite Applications.


















R12 - Intergration Capabilities:












R12- TCA:

















Trading Community Manager:















This is predefined for country United States in any new instance as
STATE, COUNTY, CITY and POSTAL CODE. For other countries,
you can simply create the geography structure depending on your
requirement or just use the Copy Structure feature to create the
geography structure based on the geography structure of another
country.

First query the country for which you want setup Address Validation
by Country Code or Name.

















Real-time address validation validates addresses during address
entry. For Oracle Trading Community Architecture, and other
Oracle E-Business Suite applications, this validation is based on the
information and setup of Geography Hierarchy.

Real-time address validation is performed only for addresses created
in the HZ_LOCATIONS table and countries that are set up in
Geography Hierarchy.

Geography Hierarchy Overview:
Geography Hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. Oracle Trading Community Architecture (TCA) and other Oracle E-Business Suite applications can leverage Geography Hierarchy for various uses related to locations, such as real-time address validation and tax calculation.

The geography information is centrally located in TCA and share among all the applications.

An ability to create and maintain hierarchies between multiple address elements or tax authorities for the purpose of real time address validation and/or tax calculation.

- Does not include street level Data. - Hierarchies can be created from Tax Vendor provided Data using utility provided by eBusiness Suite Tax Application. - Users can further extend the hierarchies that were created based on data provided by Tax Vendors.

Configuration: - Define Country specific structures for geographic hierarchies. - Manage Geography Details. - Manage Data Validation Levels during Data Entry.

Geography Validation: For example, for the United States, you specified the North America address style for HZ_LOCATIONS addresses. Then for that combination, you map the US country structure to HZ_LOCATIONS attributes, and specify that Country, State, and Postal Code values are used for geography validation.

When the user enters a US address using this address style, the address must have the correct country , state, and postal code combination, based on Geography Hierarchy data, to be considered geographically valid. Use the Geography Validation check box to specify which address elements are mandatory during address entry, based on the geography validation level for country selected.

The Geography Validation Level for Country can be:
1. Error: Only completely valid addresses can be saved, with all mandatory address elements entered.
2. Mandatory Fields Only: Invalid addresses can be saved without warning users, but only if users enter a value for all mandatory addresses elements, as defined by the geography types selected for Geography Validation usage.
3. No Validation: All addresses can be saved including incomplete and invalid addresses.
4. Warning: Invalid addresses are saved after warning users.

The Geography Validation usage determines which address elements re mandatory during ddress entry, based on the geography validation level selected. For example, if the validation level is Mandatory Fields Only, then users must enter address elements that have Geography Validation usage, but the address can still be saved if values are invalid.

Tax Validation: For example, for the United States, you had specified the North America address style for HR_LOCATIONS_ALL. Then for that combination, you map the US country structure to HR_LOCATIONS_ALL attributes, and specify that County, State, and City are used for tax validation. When a sales transaction involves an address with the North America address style, the address must have the correct county, state, and city combination, based on Geography Hierarchy data, to be considered valid for tax calculation.

Important: For either usage, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least City for geography or tax validation.

AR - New Customer User Interface:
- Customer Standard form that has been existing till R11i is finally gone.
- Oracle Introduced a brank new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
- New UI Displays both Party Level as well as Account Level information
which is sepearted into Customer Overview and Account Overview.



















Find Customer screen now uses DQM (Simple and Advanced Search
Match Rules) similar to what you see in Customers Online 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.


R12- Customer Tab Structure:


















R12 Supplier is part of TCA:

Supplier can be setup from many different application, but the
datails stored in a single repository called the Trading Community
Architecture.

TCA Provides a single, common definition that can be used to
identify customer,suppliers and organziations that provide you with
goods or services.

Supplier information is shared by the following applications.

1. TCA:
All Supplier information is defined in TCA.

2. Purchasing:
Purchasing uses supplier defaults, such as freight terms, shipping
details,on requisitions, purchase orders, request for Quotations, etc.

3. Payables:
Payables uses supplier defaults, such as method of payment and bank
account information during invoice entry and payment processing.

4. Fixed Asssets:
Assets maintains the supplier name and number for each asset record.

5. Property Manager:
Property Manager exports lease invoces for suppliers to payables so
they may be paid.

6. iSupplier Portal:
iSupplier Portal allows you to grant acces to supplier to review order,
receipt and payment details for the supplier. Supplier can enter
planned (with PO) or unplanned (without PO) invoices and update
supplier information.

MOAC: if you are using Multi organization support feature, you
cannot enter the following information at the supplier level, only at
the supplier site level they can be entered.

- Liability Account
- Prepayment Account
- Distribution set
- Invoice Tax Code
- Future Dated Payment Account.

As we know in R12 Supplier is part of TCA , thus the link between
PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
The link betweenPO_VENDOR_SITES_ALL and
HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
When a Supplier is createdRecord 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.

Bank Model is part of TCA in R12.

If we compare the bank setup in R11i and R12, we can notice
that banks was utilized into three different places Finance ,
Payroll and Treasury, which requires altogether a different
setup.

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.

Bank Account Data Model in R12 is consolidated in TCA Model.

Overview of Bank Model:

The Bank Model feature allows you to define and keep track of all
banks accounts in the e-Business suite in one place and explicity
grant account access to multiple operating Units and users.

The bank model is based on the following concept:

- Centrally located in Cash Managment.
- TCA Parties associated with bank branches.
- Owned by LE's.
- Applications that use Bank Accounts are AR, AP, Treasury
and Payroll.
- Grouped by Country.

In Prior release AP owned banks, bank branches and bank accounts,
such bank accounts could be used by AR, Payroll and Treasury.
In R12, Banks and Bank Branches are created as TCA parties,
The bank Accounts are associated with Bank Branches but reside
with in the Cash Management Application.
During the Bank Account creation, you are able to define in which
application this bank account can be used.
















TCA Tables:




















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.

Oracle Trading Community Architecture (TCA)

Trading Community Model:
Trading Community is defined as a group of entities taking part
in commerce.
Trading Community includes both persons and Organization.

What is Oracle TCA?
TCA: Trading Community Architecture.
Oracle’s Central Customer Data Repository underlying all
Oracle Applications. TCA is a Model, an Architecture and
NOT a Module.

Evolution of TCA Release:











Oracle Trading Community Architecture (TCA) is a data model
that allows you to manage complex information about the
parties, or customers, who belong to your commercial community,
including organizations, locations, and the network of hierarchical
relationships among them.











The below diagram depicts the relationship among the entities
of Trading Community.

Entity Relationship:















TCA Key Entities:

1. Parties:
“Party” is an entity in the Trading Community Model that can
enter into business relationships.
A party is a person, organization (branch, subsidiary, legalentity,
holding company, etc) or relationship (this is a relationship
between two parties).

2. Party Relationships:
A relationship is a state of connectedness between two parties ,
Each relationship consists of two entities; a subject and an object.
Relationship - Associates any two parties

Binary relationship between two parties Inter-Company and
Intra-company relationships Non-business relationships too Are
reciprocalUnlimited in number Dynamic in natureBoth seeded or
user-defined Relationship Types Relationship itself is stored as a
partyAny number of relationships between two organizations
(org-to-org) or two persons (person-to-person) or anorganization
and a person (org-to-person).

The relationship model enables you to :
- Understand the complex relationships among members of your
trading community.
- Use this information to make better business decisions.

3. Customer Accounts:
“Customer Accounts ” is used to represent a party with whom
the deploying company has a selling relationship, regardless of
whether anything has actually been purchased or serviced.
An Account cannot be created without party.

4. Locations:
A geographic location, physical place, usually with an address.
Any number of location types. (e.g., bill-to, ship-to, mail-to).
Allows for restricted use of a location (begin / end date).

Is a Party Site with one or more site uses Only one of the
Party Sites can become an “Identifying Address” for the Party
An Account Site in the context of an Account .

Geographic location including Spatial content Many to Many
relationship between party and location.

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.

5. Contracts.
A Person related to an Organization, this can be a relationship
between an organization and a person as well as between two people.















Party Vs Account:
====================

The Concept of Customer is sepearted in two layers ,
- Party Layer.
- Account Layer.

CRM applications are referring to the Party layer when they
refer to “Customer”.
ERP Applications, on the other hand, are referring to the
Account layer, when they refer to “Customer”.

The word “Customer” is the combination of both the “Party layer”
and the “Account layer”.
- Party layer exists independent of any selling or buying relationship.
- Customer Account layer exists in the context of a Party and only
when a selling relationship exists.

The Party Layer captures intrinsic truths about a person or
organization. The Account Layer captures the details describing
the Party’s financial relationship with the implementing
organization. The Account Layer cannot exist without the Party Layer.

Party:
The unique set of truths about a person, organization, group or
relationship. An entity that can enter into a business relationship.

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 - links two Parties, regardless of type.

Once a Party Relationship is formed, it may become a Party
in its own right. A Party can belong to any number of relationships.

The combination of a party and its account(s) is considered a customer

Customer Module Overview:
• TCA is designed to encapsulate all members of a ‘trading community.’
• A trading community may include customers, prospects, suppliers,
distributors, resellers, consortiums, etc.
• 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.














Customer Standard Strucutre in 11i.:

















Account Layer - Components:
===========================
Account:
The attributes of the implementing organization’s financial
relationship with a party, Cannot exist without a Party.
Account Site:
A Party Site that is used within the context of an Account.
Account Site Use:
Use of an Account Site (e.g.billing, shipping).
Account Relationships:
Established between accounts to allow sharing of billing, shipping,
and pricing information.
- One way or bi-directional,
- 1:1 Relationships – not used for multiple levels of a hierarchy .

Party Layer components:
================================
Party: An entity that can enter into a business relationship
- Person (Mr SMITH).
- Organization (ABC) .
Party Relationship: A relationship between two parties .
- Mr. Smith “Contact Of” ABC
- ABC Handhelds “Division Of” ABC - HQ
Location: Essentially an address.
Party Site: The connection between a location and a party that
indicates that a particular location is valid for that party.
Party Site Use: Use of a Party Site (e.g. billing, shipping, purchasing).

Entering orImporting Customer Data into TCA: