Creating Parties, Customer Accounts and Sites and creating party relationships

Creating Parties, Customer Accounts and Sites and creating party relationships:

The customer data is an important master data for all enterprises. The Oracle Trading Community Architecture (TCA) creates a central repository for the entire E-Business Suite to store information relating to all members of a trading community (including customers) versus separate tables for each member. The TCA model helps enterprises to record complex business relationships between Trading Community entities (including 3rd party relationships) and it supports all business models, industries, and geographies.

Yum Brands is the parent company for Pizza Hut and Taco Bell. This post explains how your company can think of modeling these three companies in your customer master based on industry best practices.

If your company has ‘Business Relationship’ with all three companies, they will need to be individually created as separate parties.

If your company has ‘Selling Relationship’ with all three companies, they will also need to be individually created as separate accounts.

The below screen shots explains how the three companies can be defined as three separate parties with individual customer accounts and sites. All of the invoices for all the three companies will be sent to Yum Brands headquarters in Delray Beach, FL. But the services are performed at 3 separate locations which are modeled below:

Once the parties, customer accounts and sites are created, we are now ready to assign relationships to the three parties. For this we navigate to ‘Relationship Manager’ and setup YUM BRANDS as a Parent of PIZZA HUT and TACO BELL as below:

Why TCA Matters for Clients running Oracle Ebusiness Suite

Why TCA Matters - What clients get from the TCA architecture:

• Architecture to model your customers and other trading partners as you see best for your business
• Architecture that will grow with your requirements
• Features to maintain extremely reliable customer information (e.g. ABC Co. is now sure that their supplier John of XYZ Inc is the same person as their customer, John of XYZ Inc)
• Glue that ties several E-Business Suite flows in a seamless way
• Customer Data Integration solution even if you are not running a single E-Business Suite module
• Platform that can play a key role in your IT landscape for Master Data Management

Why TCA Matters - What clients have to do:

• Take a close look at how you do business and how your business processes are most efficiently performed
• Ask questions about how you should model customer information e.g. which entities should be modeled as parties; when should you create an account; should you create multiple accounts for some parties; should you create multiple billing sites for an account; should you create account relationships
• Even if you are implementing few modules of E-Business Suite to start with, keep in mind the bigger picture about customer information

Oracle TCA uptakes in Oracle Release 12

TCA update in R12 to additional entities:

• Banks & Bank Branches
• Suppliers
• Legal Entity

TCA in R12 - 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)

TCA in R12 - Bank model benefits:

• Reduce number of access points to manage bank accounts - Centralized user interface
• Improve visibility and control of bank accounts - Multi-org access control
• Simplify bank reconciliation - Single bank statement can be reconciled across multiple Operating Units
• Increase percentage of automatically reconciled transactions - Bank account level reconciliation parameters add flexibility

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
• New supplier maintenance UI using TCA UI components

TCA in R12 - Benefits of Supplier representation:

• Single repository for suppliers data
• AR/AP netting
• Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. The TCA model holds the party information. Oracle Payments then stores all of the party’s payment information and its payment instruments (including credit cards, debit cards, customer bank accounts, and supplier bank accounts).

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 in R12 - Integration with HRMS:

• TCA creates the global view of person
• TCA enables you to store person Information at a corporate level
• Person is stored as party in TCA
• Comprehensive duplicate person check when entering a new person – Across the business group
• Propagate some information entered in one business group to the record in the other business group
• PER_ALL_PEOPLE_F.PARTY_ID is a foreign key to the HZ_PARTIES table, an integral part of Oracle's "Trading Community Architecture" (TCA).

Oracle Trading Community Architecture (TCA) - key concepts

I have seen many clients who do not understand the power of TCA architecture and how they can effectively use the TCA model to design their customer master. In this post I will explain the key TCA concepts and I will also try (in later posts) to take a real world example of customers and model it in the Oracle Release 12.1.3 environment.

TCA = Trading Community Architecture; Data Model and not Module. TCA provides a single, universal definition of trading partners across applications and job function.

A Trading Community Architecture is a way to understand who our trading partners interact with inside and outside the enterprise. TCA puts a foundation in place for a trading partner model:

• Linking Suppliers and Customers
• Online Marketplace
• Shared Service Centers

How did TCA come about?

• First introduced in 11i
• Introduction of Oracle CRM application
• Requirement for a common customer model for all Oracle Applications
• Model evolved from working with ERP and CRM teams to create a view of the customer base which supports all flows throughout the E-Business Suite
• To support both B2B and B2C business models
• Re-architected to enable future support for entire trading Community

Guiding Principles of 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: Parties vs. Accounts:

• From an application perspective, one of the most important things to understand about the TCA model is that the concept of “customer” is separated into two layers: The Party layer and the Account layer.
• When CRM applications refer to “Customer” they are referring to the Party Layer.
• On the other hand, when ERP applications refer to “Customer” they are referring to the Account Layer.
• Thus, confusion arises because both are using the word “Customer” to refer to two different things.

Other features of TCA:

• Public API’s for data manipulation of TCA tables
• Common Party User Interface Components
• Hierarchy Model
• Bulk Import of customer data and D&B Integration
• DQM for duplicate prevention
• Party and Account Merge

TCA data dictionary:

• HZ Parties - Stores basic information about parties and their relationship. Party ID is the primary key. Party id, Party Number, Party Name and Party Type are key columns. Establishes the Business Relationships.
• HZ Locations - Stores delivery or postal address. Location ID is the primary key. Not to be used for modeling party hierarchical relationships (use party relationships). Identifies the Party and its Account. Location can cross Parties and a Party can have multiple Locations. Account (beneath the Party) inherits the Locations defined for the Party.
• HZ Party Sites - Table that links HZ Parties with HZ Locations. Party Site ID is the primary key.
• HZ Cust Accounts - Different instances of Business Relationships (Selling, etc). Multiple Accounts can exist for a Party. Cust Account ID is the primary key.
• HZ Cust Acct Sites All - Site reference to the Account . Partitioned by Org Id. Primary Key is Cust Acct Site Id.
• HZ Cust Site Uses All - Stores business purpose usage (Bill To, Ship To, etc) for the Customer Account. Site Use Id is the Primary Key. Integrated with HZ Cust Acct Sites All.
• HZ Customer Profiles - Stores credit characteristics of Party, Account, Site.
• HZ Party Relationships - Stores relationships between parties.
• HZ Cust Profile Classes - Stores credit characteristics that is common across a group of Accounts