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. Oracles 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, legal entity, 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 Nonbusiness relationships too Are reciprocal Unlimited in number Dynamic in nature Both seeded or user-defined Relationship Types Relationship itself is stored as a party Any number of relationships between two organizations (org-to-org) or two persons (person-to-person) or an organization 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 Partys 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 organizations 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 or Importing Customer Data into TCA:

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 across 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 address 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 eBusiness 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.