Overview

This chapter covers the following topics:

• Introduction to Oracle Trading Community Architecture
• Introduction to Administration

Introduction to Oracle Trading Community Architecture

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.

This information is maintained in the TCA Registry, which is the single source of trading community information for Oracle E-Business Suite applications. These applications, as well as TCA itself, provide user interfaces, batch data entry functionality, and other features for you to view, create, and update Registry information. See: Using Oracle Trading Community Architecture.

The key entities in TCA include:

• Parties: Entities of type Person or Organization that can enter into business relationships. Parties can also be of type Relationship. For example, Joe as himself is a party of type Person, but Joe as a contact for Vision Corporation is a party of type Relationship. Every party in the TCA Registry has a unique Registry ID.

  TCA includes an extensive variety of information for parties, for example party name, addresses, contacts, and contact points. Joe as a person can have a personal phone number that differs from the phone number for the relationship of Joe as a contact.

• Party sites: Addresses that parties use for specific purposes, or uses.

• Customers: Parties with whom you have a selling relationship.

• Customer accounts: The business relationships between you and your customers.

• Customer account sites: Party sites used in the context of customer accounts for specific purposes, or uses, for example ship-to and bill-to account sites.

• Locations: Geospatial points, usually defined by an address.

• Contacts: People who have a contact or employment relationship with an organization or person.

• Contact points: Means of contact, for example, phone and e-mail address.

TCA also includes conceptual functionality that helps you manage and understand your trading community. For example, you can use relationships to model the roles that parties play with respect to one another, and classifications to classify entities.

Entities and Attributes Details

Entities in the TCA Registry consist of logical groups of descriptive, related attributes. For example, the Person Profile entity contains attributes, such as last name and date of birth, that describe parties of type Person. Likewise, the Organization Profile entity consists of attributes that describe parties of type Organization, the Address entity has address-related attributes, and so on.

An entity corresponds to one or more tables in TCA. For example, attribute values for a party record are stored in the HZ_PARTIES table.

Related Topics

Oracle Customer Data Management

Customers Overview

Customers Overview

Use the Customers set of pages to manage customer information in Oracle Receivables.

You create customers so that you can properly record and account for sales transactions, as well as all other attributes of your selling relationships. Recording a sales transaction requires that a customer, stored as a party in Oracle Trading Community Architecture, has an account as well as an account site. Consequently, to understand the role of a customer in the context of your trading community, you should also understand other concepts such as party, customer account, and account site.

• Party: An entity that can enter into a business relationship, such as buying and selling, and can be of the type Organization or Person. A party exists separately from any business relationship that it enters into with another party. For example, Vision Distribution could be a party within your trading community.

• Customer: A party, either an organization or person, with whom you have a selling relationship. This selling relationship can result from the purchase of products and services or from the negotiation of terms and conditions that provide the basis for future purchases. For example, a division of Vision Distribution could become one of your customers.

• Customer Account: A customer account represents the attributes of the business relationship that a party can enter into with another party. The account has information about the terms and conditions of doing business with the party. For example, you could open a commercial account for purchases made by Vision Distribution for its internal use and a reseller account for purchases made by Vision Distribution for sales of your products to end-users.

  You can create multiple customer accounts for a party, to maintain information about different categories of business activities. For example, to track invoices for different types of purchases, you can maintain an account for purchasing office supplies and another account for purchasing furniture.

  You can also maintain multiple customer accounts for a customer that transacts business with more than one line of business in your organization.

  Information about a party such as profile, addresses, and contacts can be shared across a party's customer accounts. In addition, you can also maintain separate profiles and contacts, along with the contacts' contact addresses and contact points, for each customer account.

• Sites/Addresses:

  • A location is a point in space described by an address.

  • A party site is the location where a party is physically located. Every party has only one identifying address, but a party can have multiple party sites.

  • An account site is a party site that is used in the context of an account. An account can have multiple account sites.

  • A customer address is an account site that is used for billing, shipping, or other purposes.

• Relationship:

  • A party relationship is a party's role in the context of another party. Party relationships can be either seeded or user defined. Examples include, affiliate, subsidiary, partner, employee of, or contact of.

  • An account relationship is established between different accounts of a party to allow sharing of billing, shipping, and pricing information.

• Contact: A person who communicates for or acts on behalf of a party or customer account. A contact can exist for a customer at the account or address level. A person usually acts as a contact for an organization, but can also be a contact for another person. For example, an administrative assistant could be the contact for an executive.

For a detailed discussion of these Oracle Trading Community Architecture concepts and examples of how to model your customers using the Customers set of pages, see: Oracle Trading Community Best Practices Setting Up Customer and Prospect Data (Note 269124.1 on My Oracle Support).

Process Flow

This diagram shows the process flow for managing, searching, creating, and updating customer information.

Introduction to Administration

Oracle Trading Community Architecture (TCA) administration features let you set up, control, and manage functionality that affect data in the TCA Registry. You can administer these TCA tools and features to best fit your business needs. See: Introduction to Oracle Trading Community Architecture, Oracle Trading Community Architecture User Guide.

Most of the administration features are available in the Administration tab, a one-stop access for TCA administration, in the Trading Community Manager responsibility. This tab is also available in Oracle Customers Online and Oracle Customer Data Librarian.

TCA administration includes:

• Relationships: Manage the relationship types that can be used to create relationships among entities in the TCA Registry. See: Administering Relationships.

• Classifications: Manage the class categories and codes that can be used to classify entities in the TCA Registry. See: Administering Classifications.

• Data Quality Management: Set up Data Quality Management, which provides powerful search and duplicate identification functionality. See: Administering Data Quality Management.

• Security: Manage data sharing groups and control how specific entities in the TCA Registry can be accessed depending on user and responsibility privileges. See: Administering Data Sharing and Security.

• Adapters: Configure third party or custom-made adapters that are used to process data in the TCA Registry. See: Administering Adapters.

• Phones: Specify time zone information for phones, and define phone formats. See: Administering Phones.

• Extensions: Extend the TCA Registry by creating user-defined attributes. See: Administering Extensions.

• Source System Management: Define the source systems, such as legacy or third party systems, that provide data for specific TCA entities, and control how data from various sources is used and displayed. See: Administering Source System Management.

• Certification: Define certification levels and reasons, and manage the display of levels. See: Administering Certification.

Many of the administration steps are also performed as part of implementing TCA. See: General Implementation and Feature-Specific Implementation.