Party vs. Customer
Suppose a person wants to buy computer from xyz shop. That person may go to that shop and ask for quotation details. Now he is a party to that computer shop. Now there are two chances like that person may buy a computer or may not. If that person not buy anything, then he will be in the party list only. Suppose if he bought any computer from that shop, he become a customer to that shop.
All customers will become as parties. But all parties will not become as customers.
Modeling multiple customer relationships for one party
It is very common for a deploying company to have more than one selling relationship with the same customer. For example, different divisions of the deploying company might negotiate their own relationships with the same external party, thus representing these different selling relationships by different accounts. Or, the deploying company might create multiple relationships with the same party if the customer negotiates unique terms to purchase different products or services from that organization. In either scenario, Oracle’s Trading Community Architecture allows you to thoroughly and accurately represent these more complex situations by recording multiple accounts with the same trading partner.
Intended Perspective
Every set up decision carries ramifications, but some are more significant than others. In addition, the same implication may be considered a benefit from one perspective and a liability from another perspective. For example, a CRM-only perspective might lead to different set up decisions than would an ERP-only perspective. Because TCA supports all Oracle Applications, it was designed from the perspective of the complete E-Business Suite. Therefore, set up decisions approached with an E-Business Suite perspective will best match the intentions of the model and will ultimately result in the most advantageous data structure.
Entity Definitions
• Party – an entity that can enter into business relationships. A party is a real person, organization, branch, subsidiary, legal entity, holding company, etc. Any real thing that you would want to put a name to is a party. The attributes of a party are universal. In other words, they are independent of your selling (or ultimately buying) relationship with the party.
There are different types of parties such as:
- Organization
- Person
- Party Relationship
• Party Relationship – A binary relationship between two parties such as a contact, employee, etc. Party relationship types can be seeded or user-defined. A party relationship is optionally a party itself, meaning certain party relationships can engage in various transactions across the E-Business Suite. The following example is indicative of Party Relationship functionality: Joe is an individual consumer of Business World, purchasing B2C goods directly for his personal use. Business World stores information on Joe such as his home address (for billing and shipping) as well as his personal email address and phone number. XYZ is a B2B customer of Business World, and purchases goods on behalf of their entire organization. Business World stores information on XYZ such as their global purchasing agreement, their bill-to and ship-to information, and additional organizational information (e.g. website, phone number, etc.) Joe works for XYZ, and is linked via a Party Relationship. The information Business World stores on Joe at XYZ is separate from the information stored on Joe as a Person or the information stored on XYZ as an Organization. As a Party Relationship type “Employee Of”, Business World stores information such as Joe’s position at XYZ, his contact information (e.g. phone number, email, etc.) at XYZ, as well as his address at XYZ. Joe, as an Employee of XYZ can enter into transactions with Business World separately from Joe as an individual. For example, if Joe calls into to place a B2C order for his own personal use, Business World would record this transaction at the “Joe” level, whereby if Joe called in on behalf of XYZ to place a B2B order, Business World would track this information at the “Joe at XYZ” level.
• Location – a point in geographical space described by a street address.
• Party Site – the link between a party and a location that indicates the location is valid for that party. Party sites should not be used to model the hierarchy or organizational structure of a company. The organizational hierarchy should be modeled using party relationships.
• Contact Point – a means of contacting a party other than sending mail; e.g., a phone number, e-mail address, URL, or fax number. • Account – the attributes of the selling relationship between the company deploying Oracle Applications and a party. Account attributes do not describe a party; they only exist when a selling relationship is present between the deploying company and the party.
Account Site – a party site that is used within the context of an account; e.g., for billing or shipping purposes.
• Party Role in Account - allows multiple parties to play various roles in an account; e.g., a “ship to” contact for an account. • Classifications - a means of categorizing a party into a pre-defined classification scheme. You can classify a party using seeded class categories (such as SIC codes or NACE codes) or you can define your own classifications scheme that is more appropriate for your organization.
To set up data correctly, it is critical that you understand the intended meanings “party”, “party site“, and “account”. As defined above, a “party” is meant to represent a real thing with which you can do business and a “party site” is simply meant to identify that a particular location is valid for the party. A party site is not intended to represent a distinct business entity with which you can do business.
