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: 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

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.

HZ(TCA) Tables in Oracle Receivables

HZ_PARTIES:
The HZ_PARTIES table stores basic information about parties that can be shared with any relationship that the party might establish with another party
key for this table is PARTY_ID.
Few Important Columns are
· PARTY_ID: Party identifier
· PARTY_NUMBER: Unique identification number for this party
· PARTY_NAME: Name of the party
· PARTY_TYPE: The party type can only be Person, Organization, Group or Relationship.

HZ_PARTY_SITES:
The HZ_PARTY_SITES table links a party (HZ_PARTIES) and a location (HZ_LOCATIONS) and stores location-specific party information. One par
optionally have one or more party sites. One location can optionally be used by one or more parties. The primary key for this table is PARTY_SITE_ID
Few Important Columns are
· PARTY_SITE_ID: Party site identifier.
· PARTY_ID: Identifier for the party. Foreign key to the HZ_PARTIES table.
· LOCATION_ID: Identifier for the party site. Foreign key to the HZ_LOCATIONS table.
· PARTY_SITE_NUMBER: Party site number.
· PARTY_SITE_NAME: User-defined name for the site.
· ADDRESSEE: Addressee information.

HZ_LOCATIONS:
The HZ_LOCATIONS table stores information about a delivery or postal address such as building number, street address, postal code, and directions t
This table provides physical location information about parties (organizations and people) and customer accounts. The primary key for this table is LO
Few Important Columns are
· LOCATION_ID: Unique identifier for this location
· COUNTRY: Country code from the TERRITORY_CODE column in the FND_TERRITORY table
· ADDRESS1: First line for address
· ADDRESS2: Second line for address
· ADDRESS3: Third line for address
· ADDRESS4: Fourth line for address
· CITY: City
· POSTAL_CODE: Postal Code
· STATE: State
· ADDRESS_KEY: Derived key that facilitates fuzzy searches

HZ_CUST_ACCOUNTS:
The HZ_CUST_ACCOUNTS table stores information about customer accounts , or business relationships that the deploying company establishes with
type Organization or Person. This table focuses on business relationships and how transactions are conducted in the relationship. Since a party can hav
customer accounts, this table might contain several records for a single party. For example, an individual person can establish a personal account, fami
and a professional account for a consulting practice. The primary key for this table is CUST_ACCOUNT_ID.
Few Important Columns are
· CUST_ACCOUNT_ID: Customer account identifier
· PARTY_ID: A foreign key to the HZ_PARTY table.
· ACCOUNT_NUMBER: Account Number
· CUSTOMER_TYPE: Receivables lookup code for the CUSTOMER_TYPE attribute. I for internal customers, R for revenue generating extern
· CUSTOMER_CLASS_CODE: Customer class identifier

HZ_CUST_ACCT_SITES_ALL:

The HZ_CUST_ACCT_SITES_ALL table stores all customer account sites across all operating units. Customer account sites are addresses, for custom
where the deploying company does business with its customers. One customer account can have multiple customer account sites, and customer accoun
customer account can belong to multiple operating units. The primary key for this table is CUST_ACCT_SITE_ID.
Few Important Columns are
· CUST_ACCT_SITE_ID: Customer site identifier
· CUST_ACCOUNT_ID: Identifier for a customer account. Foreign key to the HZ_CUST_ACCOUNTS table
· PARTY_SITE_ID: Identifier for a party site. Foreign key to the HZ_PARTY_SITES table
· BILL_TO_FLAG: Indicates if this is a Bill-To site.
· SHIP_TO_FLAG: Indicates if this is a Ship-To site.
· MARKET_FLAG: Indicates if this is a Marketing site.
HZ_CUST_SITE_USES_ALL:
The HZ_CUST_SITE_USES_ALL table stores business purposes assigned to customer account sites, for example Bill-To, Ship-To, and Statements. E
account site can have one or more purposes. This table is a child of the HZ_CUST_ACCT_SITES_ALL table, with the foreign
key CUST_ACCT_SITE_ID. The HZ_CUST_SITE_USES_ALL table also stores operating unit identifier, though the HZ_CUST_ACCT_SITES_AL
stores the operating unit for customer account sites. The primary key for this table is SITE_USE_ID.
Few Important Columns are
· SITE_USE_ID: Site use identifier
· CUST_ACCT_SITE_ID: Identifier for the customer account site. Foreign key to the HZ_CUST_ACCT_SITES_ALL table
· SITE_USE_CODE: Business purpose assigned to customer site account, such as Bill-To, Market, and Statements.
· PRIMARY_FLAG: Indicates if this site is the primary site for this customer account. Y for the primary customer account site. N for other cust
sites.

HZ_CUSTOMER_PROFILES:
The HZ_CUSTOMER_PROFILES table stores information about the credit characteristics of a single customer account or a customer account site or a
profile class defined in the
HZ_CUSTOMER_PROFILE_CLASSES table can be used to provide default values for the attributes in this table. The primary key for this table is
CUST_ACCOUNT_PROFILE_ID.
Few Important Columns are
· CUST_ACCOUNT_PROFILE_ID: Unique identifier of this customer profile
· CUST_ACCOUNT_ID: Identifier for the Customer Account. Foreign key to the HZ_CUST_ACCOUNTS table.
· STATUS: Indicates whether the profile is active or inactive

HZ_CUST_PROFILE_CLASSES:
The HZ_CUST_PROFILE_CLASSES table stores information about the credit characteristics that are common across a group of customer accounts. T
characteristics specified in this table can be used as default characteristics for similar customer accounts. The primary key for this table is PROFILE_C

HZ_PARTY_RELATIONSHIPS:
The HZ_PARTY_RELATIONSHIPS table stores information about relationships between parties.


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

Auto Invoice In AR

AUTOINVOICE and Its's Usage
Auto Invoice Program is run once the Sales order is fulfilled in the shipping execution module of order management. It is used to used to import and validate transaction data from other financial systems from which one can create invoices, debit memos, credit memos, and on-account credits. It rejects transactions with invalid information to insure the integrity of the data. This fits well with in Oracle ERP or to integrate with any third party application.
(OR )
Auto Invoice is a tool you can use to import and validate transaction data from other financial systems and create invoices, debit memos, credit me account credits in Oracle Receivables. You use a custom feeder program to transfer transaction data from an external system into the Auto Invoice in Auto Invoice then selects data from the interface tables and creates a transaction in Receivables. Receivables reject transactions with invalid inform the integrity of your data.


Oracle Receivables can create invoices from the following Oracle applications: OM, Projects, Service contracts, Property Manager. It also invoices from non-Oracle applications too. Eg: Legacy system, Non-Oracle billing applications, Non-Oracle Order Entry applications.

Following are the three interface tables for Auto Invoice:
• RA_INTERFACE_LINES
 • RA_INTERFACE_DISTRIBUTIONS
• RA_INTERFACE_SALESCREDITS

AutoInvoice consists of 3 main programs. Each program will have unique nature of work to do and they are called internally except Purge program whose execution is derived on the setup otherwise ready to execute stand alone.

•    Master (RAXMTR)
•    Import (RAXTRX)
•    Purge (RAXDEL)

Auto Invoice Master program RAXMTR

1. Selects and marks records in the interface tables to be processed based on the parameters the user entered and then calls the Auto Invoice Import program. Auto Invoice Master Program has no report output.

•Gathers statistics, it means it gathers the stats on interface tables and set the stats on certain indices on interface tables
•Marks interface records for processing by marking request_id
•Submits multiple workers for Parallel Processing by creating instances for request.

2.    Auto Invoice Import Program

Validates the selected record and creates a transaction if it passes validation. Any record that fails validation is left in the interface table with an error code. Depending on the setup, related records may be rejected as well. This program has an output file called Auto Invoice Execution report, which you can view by clicking the View Report button in the Requests window.

•    Validates data
•    Inserts records
•    Deletes interface data
•    Only when system option purge set to ‘Y’

3.    Auto Invoice Purge Program

Deletes records from the interface tables. If you set the Purge Interface Table system option to No in Define System Options window, Auto Invoice does not delete processed records from the interface tables after each run, and we must submit Auto Invoice Purge Program periodically to clean up the interface tables. This program only deletes transaction lines that have been successfully imported.
•Deletes all rows where interface_status =‘P’
•Ra_interface_lines
•Ra_interface_distributions
•Ra_interface_salescredits

 4. AutoInvoice Exception Handling:
Records that fail validation are called Exceptions ·
   Exceptions stay in Interface Tables which is RA_INTERFACE_ERRORS_ALL.
· Errors can be corrected in the Exception Handling window. ·
  Once corrections are made, Auto invoice must be resubmitted. ·
 Records that pass validation get transferred to Receivables tables.


 AutoInvoice import Process

A custom feeder program is required to transfer data from the legacy system or Oracle modules (OM , Priojects etc ) and populate the Auto Invoice interface tables (RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL).If there is need to run populate sales credit into RA_INTERFACE_SALESCREDITS_ALL table.

When run, AutoInvoiceproduces the AutoInvoice Execution Report and the AutoInvoice Validation Report.

Any entries which failed validation can be reviewed in Oracle Receivables’ AutoInvoice Interface Exceptions window. Depending on the error, changes may need to be made in Receivables, the feeder program or the imported records in the interface tables.

The main three steps for AR Invoice Interface are:
1] Put the data into your staging tables.
2] Call your package to validate the data and load into AR Interface tables (RA_INTERFACE_LINES_ALL & RA_INTERFACE_DISTRIBUTIONS_ALL).
3] Then submits a concurrent request for AutoInvoice.
If any errors occur it can be found in the ra_interface_errors_all table. The concurrent program has 2 stages. First the Master program fires which intern kicks of the Import Program. Once this is completed data is inserted into the following tables.
1) ra_customer_trx_all (Invoice Header Info)
2) ra_customer_trx_lines_all (Invoice Line Level Info)
3) ra_cust_trx_line_gl_dist_all (Accounting Info. One record for each Account Type is inserted into this… ex. Receivable Revenue Tax Freight etc)
4) ar_payment_schedules_all (All Payment related info)

Validations:

Some validation are generally done on the below columns.
•    Batch_source_name
•    Set_of_books_id
•    Orig_sys_batch_name
•    orig_system_bill_customer_ref
•    orig_system_bill_address_ref
•    Line_Type
•    Currency_Code
•    Term_name
•    Transaction_type
•    Interface_line_attribute1-7
•    Account_class
•    Accounting Flexfields segments

1- AR Transaction Type Validation: Check if the Transaction type provided in data file is defined in AR transaction types (RA_CUST_TRX_TYPES_ALL)
2- Transaction Batch Source Validation: Check if the source provided in data file is defined in AR transaction Batch source (RA_BATCH_SOURCES_ALL).
3- Invoice Currency Validation: Check if the currency provided in data file is defined in AR Currency (FND_CURRENCIES).
4- Customer Validation: Check if the Bill to Customer Number, Ship to Customer Number, Bill to Custom Location, Ship to Customer Location provided in the data file is defined in AR Customer (RA_CUSTOMERS).
5- Primary Sales Representative Validation: Sales representative number to be hardcode to “-3” for “No Sales Credit.”
6- Term Name: Check if the Term name provided in the data file is defined in Payment terms (RA_TERMS)
7- Inventory Item Validation: Check if the Item provided in data file is defined in Inventory Items (MTL_SYSTEM_ITEMS).
8- Unit of Measurement validation: Check if the UOM provided is defined in MTL_UNITS_OF_MEASURE Table
9- Invoice Tax Code Validation: Check if the Tax Code provided in data file is defined in AR_VAT_TAX_ALL_B Table.
10- Invoice GL Date Validation: Check if the GL Data of provided invoices is in open period.

What happens when AutoInvoice run?

Once the Auto invoice Program gets called, the following activity takes place is part of the execution process. When imported transactions are processed through the AutoInvoice program, the following  events happen:

• Line, accounting, and sales credit information populate three Receivables interface tables.

• Transaction lines are ordered and grouped by the grouping and line ordering rules defined.

• If the Contingencies for the Invoice lines are passed in AR_INTERFACE_CONTS_ALL

table, then a contingency is created on the appropriate line. Additionally, In the process

of creating invoice line via Autoinvoice, all the enabled rules for Revenue Contingencies

will get evaluated. If the matching criteria of the rules are met, the default contingencies

are assigned to the invoice line. The Revenue Management Engine will immediately

defer revenue for invoice lines that have contingencies assigned.

• The transaction is stamped with legal entity information. Because each transaction can only

belong to one legal entity when multiple legal entities exist the system optionally

defaults a legal entity from the transaction type or transaction batch source, if defined. If

legal entity defaults are not defined, then the user must enter the legal entity manually.

AutoInvoice performs the following payment terms validations for imported balance

forward billing (BFB) transactions:

- Transactions with balance forward billing payment terms have a balance forward

billing enabled at the account and site profiles.

- Transactions with non-balance forward billing payment terms for balance forward

billing customers have the Override Terms check box selected.

- Transactions with balance forward billing payment terms having the External

billing cycle have a billing date.

• Tax is calculated by Oracle E-Business Tax.

• GL (General Ledger) date is determined by the accounting rules or, if rules are not used,

from the ship or sales order date.

• GL accounts are assigned using AutoAccounting, except where accounting is provided on

the transaction.

• Tax, freight, commitments, and credit memos are linked to transaction lines based on the

Reference ID or Reference flexfield.

• All transactions are batched by batch source name and request ID.

• Validated lines are used to create the transactions.

• Error lines remain in the Interface Table for correction.

How Data is flowing?
Select, insert and update and delete take place on certain tables once it is logged out.

Selects– RA_INTERFACE_LINES_ALL
– RA_INTERFACE_DISTRIBUTIONS_ALL
– RA_INTERFACE_SALESCREDITS_ALL

Updates/Insert– RA_INTERFACE_ERRORS_ALL
– RA_CUSTOMER_TRX_ALL
– RA_CUSTOMER_TRX_LINES_ALL
– AR_PAYMENT_SCHEDULES_ALL
– AR_RECEIVABLE_APPLICATIONS_ALL

Inserts– RA_INTERFACE_ERRORS_ALL

AutoInvoice Exception Handling

Records that fail validation are called ‘Exceptions’

Exceptions stay in Interface Tables which is RA_INTERFACE_ERRORS_ALL
Errors can be corrected in the Exception Handling window
Once corrections are made, Auto invoice must be resubmitted
Records that pass validation get transferred to Receivables tables

AutoInvoice Exception Handling Windows
-Interface Exception window displays exception messages associated with all invalid records
-Interface Lines window displays records that fail validation, provides an error message and can be used to correct the errors
-The Line Errors windows displays errors associated with a specific line, and can only be opened from Interface Lines window
-Interface Exceptions window displays Interface Id, Exception Type, Error Message and Invalid Value associated to the error
-Data cannot be edited in this window, but error can be viewed and corrected by clicking the Details button
-Error Message and Column name with invalid data are displayed in the Message column, and the invalid value that needs to be corrected is displayed in the Invalid Value column

Refrences # http://www.ibizsoftinc.com/blog/auto-invoice-program-to-create-ar-invoices-in-oracle-ebs/