Oracle Apps TCA Tables
Oracle Apps TCA Tables
Introduction
Oracle Applications R12 Trading Community Architecture Tables
Background
What is TCA?
Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.
The code
PARTIES:
The related tables are as follows:-
HZ_PARTIES : Stores information about parties.
HZ_FINANCIAL_PROFILE : Stores information about the financial accounts.
HZ_CREDIT_RATINGS : Stores information about the credit rating of parties
HZ_REFERENCES : Stores information about reference given by one party about another.
HZ_CERTIFICATIONS : Stores information about the certifications given by other parties.
PARTIES – TYPE PERSON:
The tables are as follows:-
HZ_PERSON_PROFILES : Stores details information about people.
HZ_PERSON_LANGUAGES :Stores information about the language that a person speaks, reads or writes
HZ_PERSON_INTEREST : Stores information about a person’s personal interests.
HZ_ CITIZENSHIP : Stores information about a person’s claimed nationality.
HZ_EDUCATIONS : Store information about a person educations.
HZ_EMPLOYMENT_HISTORY : Stores information about where the person has been employed.
PARTIES – TYPE ORGANIZATION:
The tables are as follows:-
HZ_ORGANIZATION_PROFILES : Stores details information about credit rating, financial statistics, socio-economic and corporate linkage information.
HZ_STOCK_MARKETS :Stores information about the selling and buying of financial instruments.
HZ_SECURITY_ISSUED : Stores information about financial instruments such as stocks and bonds that has been issued by the organization.
HZ_INDUSTRIAL_CLASS_APP : It is a intersection tables that link industrial classifications stores in HZ_INDUSTRIAL_CLASSES .
HZ_INDUSTRIAL_CLASSES : Stores information about names and descriptions of industrial classifications.
HZ_FINANCIAL_REPORTS : Store information details of financial reports that describe the financial status of the party.
HZ_INDUSTRIAL_REFERENCE : Stores information about industrial reference for organization.
CUSTOMER ACCOUNTS:
The tables are as follows:-
HZ_CUST_ACCOUNTS : Stores information about the relationship, if a party becomes a customer. Basically stores information about customer accounts.
HZ_CUST_ACCT_SITES_ALL : Stores information about customer sites. One customer can have more then multiple sites.
HZ_CUST_SITE_USES_ALL : Stores information about site uses or business purpose. A Single customer site can have multiple sites uses such as Bill To or Ship To.
HZ_CUST_ACCT_RELATE_ALL : Stores information about relationships between customer accounts.
HZ_CUST_ACCOUNT_ROLES : Stores information about the roles that parties perform in customer accounts.
HZ_BILLING_PREFERENCES : It describe the invoicing format preferred by customer accounts or customer account sites.
HZ_CUSTOMER_PROFILES : Stores credit information for a customer account and customer account sites.
HZ_CUST_PROFILE_AMTS : Stores profile amount limits for every currency defined for a customer account or customer account site profile.
HZ_CUST_PROF_CLASS_AMTS :Stores customer profile class amount limits for currency.
HZ_CUST_PROFILE_CLASSES : Stores standard credit profile classes.
CONTACT POINTS:
The tables are as follows:-
HZ_CONTACT_POINTS : Stores electronic methods of communicating with entities such as parties, party site. Each record in this table represents s different means of contacting an entity.
HZ_CUST_CONTACT_POINTS : This table is used to tie a contact point to a customer account, customer account site or customer account role.
HZ_CONTACT_RESTRICTIONS : It stores information about restrictions on contacting parties.
SITES/LOCATIONS:
The tables are as follows:-
HZ_PARTIES_SITES : Stores information about parties and locations. Because there is a many-to-many relationship between parties and locations.
HZ_PARTIES_SITE_USES : Stores information about the party site uses and business purposes. A party site can have multiple site uses such as ‘bill to’ or ‘ship to’ and each site is stores as a record in this table.
HZ_LOCATIONS : Stores information about the locations, namely, address information
HZ_LOC_ASSIGNMENTS : It ties locations stored in HZ_LOCATIONS to a LOC_ID stored in AR_LOCATIONS_COMBINATIONS
Posted by ElangovanRagavan at 18:40 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: TCA R12
R12 TCA (Trading Community Architecture)
R12 TCA (Trading Community Architecture):
What is TCA?
· Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
· Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.
Note: Customer, Vendor, Supplier are the terms that we come across very frequently.
For instance: We buy goods from a Shop Vendor so we are the Customer to that Vendor and the Vendor is our Supplier for that good. The Vendor gets goods from a merchant who actually produces it (Manufacturer), so now the vendor in-turn becomes a customer to the Manufacturer who is the Supplier.
The complete TCA can be related and runs around all these terms, these may be people we meet generally who might be a Supplier or Customer in our perspective.
Now moving ahead lets go in details about TCA.
How TCA Matters?
Before TCA:
· There are multiple customer definitions across the enterprise.
· It was very difficult to track current and historical information about the customers.
· There was a lack of support for mixed business.
· It was quite tough 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, Contacts, Employees, Partners, Distributors, Suppliers, Banks, etc.
· Record complex business relationships between Trading Community entities (including 3rd party relationships).
· Support all business models, industries, and geographies.
·
TCA Data Model Components:
Party
Represents any entity that can enter into business relationships with your organization – Organization, Person, or Group
Party Relationship
A binary relationship between two parties such as a partnership. Example: Adam is a specific person party and Eve Inc. is an organization party. Adam at Eve Inc. is also treated as a party with the type relationship
Location
A Street Address
Party Site
Associates a party with a location, indicating that party’s usage of the location
Contact
A person related to an organization, this can be a relationship between an organization and a person as well as between two people
Contact Point
Your avenue of contacting a party i.e. a phone number ,e-mail address or fax number
Customer Account
Represents a customer relationship between your organization and a party
Customer Account Site
A party Site that you use in relation to a customer account, i.e, a bill-to or ship-to address
Customer Account Contacts
A party contact that is used as a means of contacting the customer regarding his/her account
TCA in 11i
· 11i TCA already equipped to handle the following entities
–>Customer
–>Employee
–>Student
Here is Summarize information of the tables Pre and Post 11i:
TCA in R12 Includes:
· New trading entities
–>Suppliers
–>Banks & Bank Branches
–>Legal Entity
TCA Data Model : Supplier & Customer
TCA in R12: Supplier Representation
· Supplier organizations are in TCA
· Terms of doing business with the supplier are in Purchasing / Payables
· Supplier organization, address, contact, phone, email etc. are all in TCA
· Employees are already in TCA, Payables using the same employee records in TCA
TCA – Suppliers:
· Technical details for R12 Supplier in TCA
TCA in R12: Supplier Data Mapping
TCA in R12: Bank Account Model
TCA in R12: Bank Model
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) .
R12 Multi-org access control
· MOAC is new enhancement to Multiple Organization feature of Oracle Application
· Enables Users to access the data from one or many Operating Units within a set of given responsibility
· Data Security is maintained using Multiple Organization Security Profile, Define in Oracle HRMS.
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
· 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.
The Changing model for Bank in Global working model
–> Release 12, what’s New:
TCA Bank Model in 11i and R12:
TCA in R12: Legal Entities
· 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
· For 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
TCA & Enhancement:
· The Trading Community Manager Responsibility, allows users to create a setup or update data sharing and security
· Customer Standard form that has been existing till R11i is finally gone.
· Oracle Introduced a brand new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
TCA API’s List:
Oracle Apps TCA Tables
Introduction
Oracle Applications R12 Trading Community Architecture Tables
Background
What is TCA?
Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.
The code
PARTIES:
The related tables are as follows:-
HZ_PARTIES : Stores information about parties.
HZ_FINANCIAL_PROFILE : Stores information about the financial accounts.
HZ_CREDIT_RATINGS : Stores information about the credit rating of parties
HZ_REFERENCES : Stores information about reference given by one party about another.
HZ_CERTIFICATIONS : Stores information about the certifications given by other parties.
PARTIES – TYPE PERSON:
The tables are as follows:-
HZ_PERSON_PROFILES : Stores details information about people.
HZ_PERSON_LANGUAGES :Stores information about the language that a person speaks, reads or writes
HZ_PERSON_INTEREST : Stores information about a person’s personal interests.
HZ_ CITIZENSHIP : Stores information about a person’s claimed nationality.
HZ_EDUCATIONS : Store information about a person educations.
HZ_EMPLOYMENT_HISTORY : Stores information about where the person has been employed.
PARTIES – TYPE ORGANIZATION:
The tables are as follows:-
HZ_ORGANIZATION_PROFILES : Stores details information about credit rating, financial statistics, socio-economic and corporate linkage information.
HZ_STOCK_MARKETS :Stores information about the selling and buying of financial instruments.
HZ_SECURITY_ISSUED : Stores information about financial instruments such as stocks and bonds that has been issued by the organization.
HZ_INDUSTRIAL_CLASS_APP : It is a intersection tables that link industrial classifications stores in HZ_INDUSTRIAL_CLASSES .
HZ_INDUSTRIAL_CLASSES : Stores information about names and descriptions of industrial classifications.
HZ_FINANCIAL_REPORTS : Store information details of financial reports that describe the financial status of the party.
HZ_INDUSTRIAL_REFERENCE : Stores information about industrial reference for organization.
CUSTOMER ACCOUNTS:
The tables are as follows:-
HZ_CUST_ACCOUNTS : Stores information about the relationship, if a party becomes a customer. Basically stores information about customer accounts.
HZ_CUST_ACCT_SITES_ALL : Stores information about customer sites. One customer can have more then multiple sites.
HZ_CUST_SITE_USES_ALL : Stores information about site uses or business purpose. A Single customer site can have multiple sites uses such as Bill To or Ship To.
HZ_CUST_ACCT_RELATE_ALL : Stores information about relationships between customer accounts.
HZ_CUST_ACCOUNT_ROLES : Stores information about the roles that parties perform in customer accounts.
HZ_BILLING_PREFERENCES : It describe the invoicing format preferred by customer accounts or customer account sites.
HZ_CUSTOMER_PROFILES : Stores credit information for a customer account and customer account sites.
HZ_CUST_PROFILE_AMTS : Stores profile amount limits for every currency defined for a customer account or customer account site profile.
HZ_CUST_PROF_CLASS_AMTS :Stores customer profile class amount limits for currency.
HZ_CUST_PROFILE_CLASSES : Stores standard credit profile classes.
CONTACT POINTS:
The tables are as follows:-
HZ_CONTACT_POINTS : Stores electronic methods of communicating with entities such as parties, party site. Each record in this table represents s different means of contacting an entity.
HZ_CUST_CONTACT_POINTS : This table is used to tie a contact point to a customer account, customer account site or customer account role.
HZ_CONTACT_RESTRICTIONS : It stores information about restrictions on contacting parties.
SITES/LOCATIONS:
The tables are as follows:-
HZ_PARTIES_SITES : Stores information about parties and locations. Because there is a many-to-many relationship between parties and locations.
HZ_PARTIES_SITE_USES : Stores information about the party site uses and business purposes. A party site can have multiple site uses such as ‘bill to’ or ‘ship to’ and each site is stores as a record in this table.
HZ_LOCATIONS : Stores information about the locations, namely, address information
HZ_LOC_ASSIGNMENTS : It ties locations stored in HZ_LOCATIONS to a LOC_ID stored in AR_LOCATIONS_COMBINATIONS
Posted by ElangovanRagavan at 18:40 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: TCA R12
R12 TCA (Trading Community Architecture)
R12 TCA (Trading Community Architecture):
What is TCA?
· Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
· Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.
Note: Customer, Vendor, Supplier are the terms that we come across very frequently.
For instance: We buy goods from a Shop Vendor so we are the Customer to that Vendor and the Vendor is our Supplier for that good. The Vendor gets goods from a merchant who actually produces it (Manufacturer), so now the vendor in-turn becomes a customer to the Manufacturer who is the Supplier.
The complete TCA can be related and runs around all these terms, these may be people we meet generally who might be a Supplier or Customer in our perspective.
Now moving ahead lets go in details about TCA.
How TCA Matters?
Before TCA:
· There are multiple customer definitions across the enterprise.
· It was very difficult to track current and historical information about the customers.
· There was a lack of support for mixed business.
· It was quite tough 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, Contacts, Employees, Partners, Distributors, Suppliers, Banks, etc.
· Record complex business relationships between Trading Community entities (including 3rd party relationships).
· Support all business models, industries, and geographies.
·
TCA Data Model Components:
Party
Represents any entity that can enter into business relationships with your organization – Organization, Person, or Group
Party Relationship
A binary relationship between two parties such as a partnership. Example: Adam is a specific person party and Eve Inc. is an organization party. Adam at Eve Inc. is also treated as a party with the type relationship
Location
A Street Address
Party Site
Associates a party with a location, indicating that party’s usage of the location
Contact
A person related to an organization, this can be a relationship between an organization and a person as well as between two people
Contact Point
Your avenue of contacting a party i.e. a phone number ,e-mail address or fax number
Customer Account
Represents a customer relationship between your organization and a party
Customer Account Site
A party Site that you use in relation to a customer account, i.e, a bill-to or ship-to address
Customer Account Contacts
A party contact that is used as a means of contacting the customer regarding his/her account
TCA in 11i
· 11i TCA already equipped to handle the following entities
–>Customer
–>Employee
–>Student
Here is Summarize information of the tables Pre and Post 11i:
TCA in R12 Includes:
· New trading entities
–>Suppliers
–>Banks & Bank Branches
–>Legal Entity
TCA Data Model : Supplier & Customer
TCA in R12: Supplier Representation
· Supplier organizations are in TCA
· Terms of doing business with the supplier are in Purchasing / Payables
· Supplier organization, address, contact, phone, email etc. are all in TCA
· Employees are already in TCA, Payables using the same employee records in TCA
TCA – Suppliers:
· Technical details for R12 Supplier in TCA
TCA in R12: Supplier Data Mapping
TCA in R12: Bank Account Model
TCA in R12: Bank Model
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) .
R12 Multi-org access control
· MOAC is new enhancement to Multiple Organization feature of Oracle Application
· Enables Users to access the data from one or many Operating Units within a set of given responsibility
· Data Security is maintained using Multiple Organization Security Profile, Define in Oracle HRMS.
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
· 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.
The Changing model for Bank in Global working model
–> Release 12, what’s New:
TCA Bank Model in 11i and R12:
TCA in R12: Legal Entities
· 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
· For 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
TCA & Enhancement:
· The Trading Community Manager Responsibility, allows users to create a setup or update data sharing and security
· Customer Standard form that has been existing till R11i is finally gone.
· Oracle Introduced a brand new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
TCA API’s List:
No comments:
Post a Comment