Home » Applications » Oracle Fusion Apps & E-Business Suite » Trading community Architecture
|
|
| Re: Trading community Architecture [message #184020 is a reply to message #183974] |
Mon, 24 July 2006 22:39   |
shashidhar.k
Messages: 127
Registered: January 2006
Location: India
|
Senior Member |
|
|
HI ..Priyadharsini
TCA Model:
-------------
Trading Community Architecture (TCA) is a structure
designed to support complex trading relationships within
an organization.
Trading Community Architecture (TCA) is an architecture concept designed to support complex trading communities. The goal of TCA is to provide a shared data foundation for Oracle ERP, CRM, and eBusiness applications.
Features:
-----------
* Single Source of Information /
Truth
* Party Concept
* Common Location / Address
Entity
* Ability to Model Complex
* Trading Relationships
* Any third party (i.e. which have customer data) Integration.
Benefits:----------------
* Ensure Data Consistency
* Model Various Customer Bases
* Ease of Data Maintenance
* Respond to Changing Business
Trends.
The following are some definitions that have an important role in the functionality:::
RACUST ::
Customer Interface is a concurrent program that is responsible for the import and update of AR customer information from open interface tables to AR Customer tables.
HZ::
Prefix used to distinguish 11i Customer Model objects using TCA such as tables, views, and APIs from previous customer model objects such as those used within R10.7, and R11.
PARTY ::
A party is an entity that can enter into a business relationship and can be of two sub types; Person and Organization.
PERSON PARTY ::
A person party is a unique individual of interest to the owner of the software.
ORGANIZATION PARTY::
An organization party is a legal entity generally recognized by some government authority.
RELATIONSHIP::
Relationships in TCA allow for the linking of any two parties. When two parties are connected via a party relationship a relationship type is assigned which describes the relationship.
Tht's all about "TCA"., which i know.
Thanks
Shashidhar K
[Updated on: Mon, 24 July 2006 22:43] Report message to a moderator |
|
|
|
|
|
| Re: Trading community Architecture [message #185091 is a reply to message #184987] |
Mon, 31 July 2006 00:10 |
shashidhar.k
Messages: 127
Registered: January 2006
Location: India
|
Senior Member |
|
|
HI..
I guess u can the data from help files. due some lack of time iam not able to explain the topic.
Actually i was also not worked completely. In past Project it was their.But due to some tech problem's we were not implemented this item.
any way here with iam sending some addtional information ., it could usefull to you..
The "Party" Concept
The concept of party enables the customer model to treat all business entities equally. This means that each customer, regardless of type (organization, person, group, or relationship), is handled in the same way by the model.
Because all business entities are treated alike, the customer model can easily handle B2B, B2C, or mixed business models. Although the model tracks attributes for people different from those it tracks for organizations (e.g., date of birth, title, and gender for people; DUNS number, SIC code, and fiscal year end for organizations), both people and organizations are parties, and their records are therefore stored in the same physical table in the database. This in turn means that the same business relationships that can be formed with an organization can be formed with a person.
Any number of parties can be grouped into a single entity. This allows the modeling of complex business entities such as households and buying consortiums. A group can be viewed as a single entity; meanwhile, each of its members can still be viewed as a distinct entity.
The relationship between two parties may be viewed as a party in its own right. For example, if John works at Oracle, three parties could exist: John (party of type person), Oracle (party of type organization), and John@Oracle (party of type relationship). Because John@Oracle is a party in its own right, addresses, phone numbers, and customer accounts can be directly associated with the John@Oracle entity.
The customer models of other products typically treat organizations and people as entities of two distinct types, which makes dealing with mixed business models difficult. Many CRM products on the market today were originally designed to support only a B2B business model In a pure B2B environment, customers are always organizations and people are simply contacts for those organizations. For such models, it makes sense to distinguish organizations from people and to provide functionalities specific to each. For example, in a pure B2B environment, the data model would probably support associating leads, opportunities, and accounts with organizations but not with people (because people would be simply contacts for organizations, not customers).
As CRM vendors came to realize that their models needed to support B2C and mixed models as well, they began trying to reshape their existing B2B-only models. In many cases, the result is a data model designed for B2B with a few patches to support basic B2C functionality.
The "party" data is maintained by the Oracle business applications (TeleSales, Customer Care, etc.), and it is populated into a list by Oracle Marketing on a one "party" per list entry basis. Based on the source type, different data will be pulled into the list entry.
Thanks
Shashidhar K
[Updated on: Mon, 31 July 2006 00:10] Report message to a moderator |
|
|
|
| Re: Trading community Architecture [message #419679 is a reply to message #185091] |
Tue, 25 August 2009 02:26 |
|
|
Hi Sashidhar,
I have 2 question please :
1. If a person exists in TCA can he be added as a Task Contact ?
2. In a Given Scenarion : Jay johnson works for abc corp , jay johnsons phone number is 123-456-7890, used for his personal purpose ... How can this be mapped to TCA ?
Thanks in Advance,
Sandesh
[Updated on: Tue, 25 August 2009 02:28] Report message to a moderator |
|
|
|
| Re: Trading community Architecture [message #438799 is a reply to message #419679] |
Tue, 12 January 2010 05:39 |
vikasraoyatam
Messages: 1
Registered: January 2010
Location: Hyderabad
|
Junior Member |
|
|
Hi Sandesh,
I am not sure if its already adressed but just in case if its not
For the question, there has to be two entities that needs to be created in hz_parties, one for person "Jay johnson" with person_type and one for org "abc corp" with org_type, There is a seperate table to create relationships, create a relationship between these two parties and regarding jay johnson's phone number - can be an attribute in hz_parties.
Regards,
Vikas Yatam
|
|
|
|
| Re: Trading community Architecture [message #465075 is a reply to message #184987] |
Mon, 12 July 2010 08:26 |
uday_3393
Messages: 2
Registered: October 2007
|
Junior Member |
|
|
Hi,
The difference between party and customer in technical term is when we create orgranization, person or relationship it insert records in hz_parties table and it treat as party. But When we create the account or create record in hz_cust_accounts table then party becomes customer.
Regards,
Uday
|
|
|
|
| Re: Trading community Architecture [message #466040 is a reply to message #465075] |
Fri, 16 July 2010 09:57 |
jerryvn01
Messages: 9
Registered: June 2010
|
Junior Member |
|
|
uday_3393 wrote on Mon, 12 July 2010 08:26Hi,
The difference between party and customer in technical term is when we create orgranization, person or relationship it insert records in hz_parties table and it treat as party. But When we create the account or create record in hz_cust_accounts table then party becomes customer.
Regards,
Uday
Hi,
I agreed with you. Any way, your ideal make me thinking about some thing for my project.
Please try to keep posting. Tks and best regards
|
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:17:17 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
