Understand the core HZ tables: Parties, Accounts, Sites, and Relationships.
Trading Community Architecture (TCA) is not a standalone module; it is the universal data model used across Oracle E-Business Suite and Fusion to store information about Parties (Customers, Suppliers, Banks, Employees). It was introduced to solve the problem of fragmented customer data, providing a single, unified repository for all entities your business interacts with.
Prior to R12 (in 11i), Suppliers were NOT in TCA. They were stored in AP_SUPPLIERS. In R12 and Fusion, Suppliers, Customers, and Banks all share the same TCA architecture.
The "Trading Community Manager" responsibility is used to manage the core TCA setup, including relationships and geographies.
Data Steward
Data Steward
AR/AP Setup User
AR/AP Setup User
Data Steward
Actor: Data Steward | Module: Trading Community Architecture (TCA)
A Party is the highest level entity. It represents a real-world entity (a Person, an Organization, or a Group) independent of any business relationship you have with them. A Party has a Name and a Type, but no financial data.
Example: Create a Party of type "Organization" named "Acme Corp". You don't know yet if they are a buyer, a seller, or both.
Navigation Path:
Receivables > Billing > Manage Customers (Profile tab)
Key Actions:
A Party is global. It is NOT linked to a Business Unit.
Actor: Data Steward | Module: Trading Community Architecture (TCA)
A Location is a physical address (123 Main St, NY). A Party Site is the link that connects a specific Party to a specific Location. Multiple parties can share the same location.
Example: Create Location "123 Main St". Link "Acme Corp" (Party) to "123 Main St" (Location). This creates a Party Site record.
Navigation Path:
Receivables > Billing > Manage Customers (Addresses tab)
Key Actions:
Locations are global. They are defined in the Geography hierarchy.
Actor: AR/AP Setup User | Module: Trading Community Architecture (TCA)
An Account establishes a financial/business relationship between your enterprise and the Party. A single Party can have multiple Accounts (e.g., a "Commercial" account and a "Retail" account). This is where financial attributes (Payment Terms, Credit Limits) are stored.
Example: Create a Customer Account for "Acme Corp" with Payment Terms of "Net 30".
Navigation Path:
Receivables > Billing > Manage Customers (Accounts tab)
Key Actions:
Same as R12. The Account holds the overarching financial relationship.
Actor: AR/AP Setup User | Module: Trading Community Architecture (TCA)
An Account Site connects a Customer Account to a Party Site. Most importantly, it is linked to a specific Operating Unit (OU). The "Site Use" defines the business purpose of that address (e.g., "Bill-To", "Ship-To").
Example: Link the "Acme Corp" Account to the "123 Main St" Party Site for the "US Operations" OU. Define the Site Use as "Bill-To".
Navigation Path:
Receivables > Billing > Manage Customers (Account Sites > Site Purposes)
Key Actions:
This level is tied to the Business Unit (BU).
Actor: Data Steward | Module: Trading Community Architecture (TCA)
Relationships connect two Parties together. This is used to build complex corporate hierarchies (Parent/Subsidiary) or personal contacts (Employee/Employer).
Example: Create a Party of type "Person" named "John Smith". Create a relationship: "John Smith is an Employee of Acme Corp".
Navigation Path:
Receivables > Billing > Manage Customers (Contacts tab)
Key Actions:
Fusion uses the same relationship model for contacts and hierarchies.