TCA Architecture
TCA: - Trading Community Architecture
Ø 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.
Terminologies used 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.
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.
Ø 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.
Ø Contact
points: Means of contact, for example, phone and
e-mail address.
Reason behind introduction of 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).
Ø The
static and independent customer and supplier models typical of other ERP and
CRM applications cover only a limited slice of the trading community and cannot
adequately represent the reality of today’s complex business communities and
its relationships. The TCA architecture was designed to address these gaps and
provide a flexible architecture that can accommodate stakeholders in a trading
community and the complicated relationships among them.
What is
Trading Community?
Ø Trading community may
be anything with whom we use to do business with. It might be person, supplier, organization.
Trading Community Architecture
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.
What could be difference between
customer and party? Give some examples.
You go to Diamond Electronics shop and ask for some
information about an electronic item. You are interested to buy, but first you
want to get information and decide later. They will show you the item and
explain the details and after that they take your personal details, so that
they contact you later or it would be easy when you buy later. That’s part of
Customer Relationship Management. When they enter in Oracle ERP, you become a
party in TCA, not customer because you have not yet decided to purchase.
The same case happens, if somebody from orchid
hotel goes to them and tells them that, he is representing orchid hotel and
they are planning to buy lot of electronic items to their new hotel. Here, 3
things are entered in Oracle TCA. orchid hotels information, the person (ex:
XYZ) who is representative of orchid hotels, and the relationship between that
person and the orchid hotels. Here orchid hotels is a party, JOHN is party
contact and the relationship is AGENT.
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.
After some time, you or orchid hotel decided to buy
electronics and you go again and make a purchase. That time, you become
customer.
What could be difference between
customer accounts and customer account sites?
You are buying 2 items, but you want them to go to
different places and billing address is also different. This way, it is easier
for your financial consolidation. So, you give them different credit cards and
different shipping and billing addresses. That time, they would create 2 customer
accounts for you.
The same case may happen to orchid hotel, they may
have Corporate Hotel Address, but they want to these expenses to be calculated
at their new hotel. So they create a new account based on this new hotel
address.
Generally, site is logical representation of the
location. Their new hotel physical address is location and it can be
represented as site. Now, depending on the use it can be BILL-TO or SHIP-TO.
The site use determines where the items to be shipped physically and where the
invoice should go.
What could be difference between site
and location?
Location is the physical address which needs to be
created first. Then attach account site to the address based on the usage.
Usage is at the site level and not at the location level. One physical address
can be site for COMMUINCATION, CORPORATE, BILL-TO , SHIP-TO etc. I would say,
site determines the purpose of the physical location.
What could be difference between
contacts and contact points?
In the above case, XYZ is the Contact of orchid
hotel.
Contact Points are ways to reach that person. Like
his phone numbers, email address etc. They also take phone numbers of orchid
hotel.
These contact points applicable to you also. When
you give them your phone numbers while buying the item, they are attached to
your party record as contact points.
TCA Setup Considerations
When you are doing TCA customer Modelling, keep
these things in mind;
Ø Party
is real Person or Organization.
Ø Party
sites are locations for Party or Organization.
Ø Relationships
are generally used to construct hierarchical structure of Organizations.
Ø Party
becomes a Customer/Account, once a selling relationship is established.
Ø An
account should typically have at least one active ‘bill_to’ site. It helps for
accounting and reporting
purposes.
Ø When
creating Parties, what all party sites can be or should be created as Parties.
Ø Generally,
if you want to see activities for site level separately from your parent level
party, you should create that Site as a separate Party/Entity.
Ø An
account is a separate entity. Create account only where you have selling
relationship i.e. only for customers. It identifies selling attributes
e.g.payment terms, shipping and billing preferences etc. of the relationship.
11i
TO R12 Replaced tables for customers.
RA_CUSTOMERS
The table
below lists the corresponding HZ table and column for various columns in the
current RA_CUSTOMERS view
Column in RA_CUSTOMERS
|
Corresponding Table
|
Column
|
customer_name
|
hz_parties
|
party_name,
|
customer_id
|
hz_cust_accounts
|
cust_account_id
|
customer_number
|
hz_cust_accounts
|
account_number
|
status
|
hz_cust_accounts
|
status
|
Join Conditions:
HZ_CUST_ACCOUNTS..Party_Id
= HZ_PARTIES.Party_Id
RA_ADDRESSES
Column in RA_ADDRESSES
|
Corresponding Table
|
Column
|
address_id
|
hz_cust_acct_sites_all
|
cust_acct_site_id
|
status
|
hz_cust_acct_sites_all
|
status
|
address1
|
hz_locations
|
address1
|
address2
|
hz_locations
|
address2
|
address3
|
hz_locations
|
address3
|
address4
|
hz_locations
|
address4
|
city
|
hz_locations
|
city
|
state
|
hz_locations
|
state
|
postal_code
|
hz_locations
|
postal_code
|
county
|
hz_locations
|
county
|
country
|
hz_locations
|
country
|
language
|
hz_locations
|
language
|
Join Conditions:
HZ_CUST_ACCT_SITES_ALL.party_site_id =
HZ_PARTY_SITES.party_site_id
HZ_LOCATIONS.location_id =
HZ_PARTY_SITES.location_id
RA_SITE_USES
The table below lists the corresponding HZ table
and column for various columns in the current RA_SITE_USES view
Column in RA_SITE_USES
|
Corresponding Table
|
Column
|
site_use_id
|
hz_cust_site_uses
|
site_use_id
|
site_use_code
|
hz_cust_site_uses
|
site_use_code
|
status
|
hz_cust_site_uses
|
status
|
address_id
|
hz_cust_site_uses
|
cust_acct_site_id
|
RA_CONTACTS
Column in RA_CONTACTS
|
Corresponding Table
|
Column
|
contact_id
|
hz_cust_account_roles
|
cust_account_role_id
|
customer_id
|
hz_cust_account_roles
|
cust_account_id
|
address_id
|
hz_cust_account_roles
|
cust_acct_site_id
|
first_name
|
hz_parties
|
person_first_name
|
last_name
|
hz_parties
|
person_last_name
|
Join Conditions:
HZ_CUST_ACCOUNT_ROLES.party_id =
HZ_PARTY_RELATIONSHIPS.party_id
HZ_CUST_ACCOUNT_ROLES.role_type = 'CONTACT'
HZ_PARTIES.party_id =
HZ_PARTY_RELATIONSHIPS.subject_id
RA_CONTACT_ROLES
Column in RA_CONTACT_ROLES
|
Corresponding Table
|
Column
|
contact_id
|
hz_role_responsibility
|
cust_account_role_id
|
usage_code
|
hz_role_responsibility
|
responsibility_type
|
primary_flag
|
hz_role_responsibility
|
primary_flag
|
API’s Used for customer conversion….