This chapter covers the following topics:
Party Merge provides the capability to merge parties and their related entities in the TCA Registry, eliminating duplicate data in the Registry. Because the TCA Registry shares information across the E-Business Suite, you must maintain the quality of the data in the Registry. Duplicate data can reduce the efficiency and accuracy of your party processing and reports.
With Party Merge, you can:
Consolidate duplicate parties or party sites.
For example, you can merge Vision Corp. into Vision Corporation.
Merge duplicate party sites for a party.
Note: Even though you can also use Party Merge to integrate an acquired party into the acquiring party, Party Merge is primarily for finding and resolving duplicates. Before using Party Merge for mergers and acquisitions, you must fully test and prepare for the results of merging.
For example, after merge, all existing transactions are repointed to the surviving party. You cannot reconcile transactions or audit transactions details for the acquired party, or reprint invoices for that party. If you still need to perform various tasks for the acquired party, you might not want to merge it into the acquiring party.
In Party Merge, merge batches are sets of parties or party sites to merge, and the Party Merge process runs on one merge at a time. A merge batch determines the records involved in the merge as well as the general outcome of the merge.
When you submit parties or party sites for merge, the Party Merge process runs as a concurrent request to complete the actual merge. You can review the log to check the results and any errors that might have occurred.
To identify the duplicate parties to include in a merge batch, you can:
Use batch duplicate identification to automatically find batches of duplicates. See: Batch Duplicate Identification Overview.
Manually determine and enter the duplicates into merge batches in Party Merge.
In addition to Party Merge, you can use the Customer Account Merge feature to merge transactions from a source customer account to a target customer account. After the merge-from account is merged into the merge-to account, you can either inactivate or delete the source customer account. See: Merging Customers.
Your administrator can set up Party Merge. See: Setting Up Party Merge, Oracle Trading Community Architecture Administration Guide.
The Party Merge process involves four procedures to resolve duplicate parties and party sites in the TCA Registry:
Related Topics
Party and Customer Account Merge
Using Oracle Trading Community Architecture
In Party Merge, the merging parties are referred to as the merge-from party and the merge-to party, or the source and the target respectively. After the merge-from party is merged into the merge-to party, you can delete the merge-from, or source, party. By default the merge-from party is set to a Merged status.
The related child entities that get merged or transferred include party relationships, contact information, party profiles, customer accounts, extended attributes, and information obtained from third-party sources. For more information about what information is merged or transferred, see: Duplicate Checking.
You can merge parties or party sites that belong to a party. You cannot merge party sites between parties, however, until you merge the parties that they belong to. Before the Party Merge process begins, you can choose to delete the merge-from party when the process ends. If you merge party sites for the same party, you cannot choose to delete the merge-from party because the merge-from and merge-to parties are the same party.
Deleting a party changes its status to Deleted. You cannot retrieve a deleted party in any search or transaction window unless the application is specifically designed to include deleted parties in any query results.
If a merge-from and merge-to party site are not duplicates, the merge-from party site is essentially transferred to the merge-to party. The actual process, however, involves a copy and merge, for legal auditing requirements.
A copy of the merge-from party site is created for the merge-to party.
The merge-from party site is then merged with that copy.
The merge-from party and party site have the Merged status.
For example, this table shows the parties before the merge, with two party sites that are not duplicates.
| From Party Name | From Party Site | To Party Name | To Party Site |
|---|---|---|---|
| Vision1 | 500 Vision Parkway | Vision2 | 100 Vision Parkway |
During the merge, a copy of 500 Vision Parkway is created for Vision2, so both parties now have duplicate party sites. As with all duplicate party sites, the 500 Vision Parkway site from Vision1 is merged into the copied site of Vision2. After the merge, both Vision1 and the original 500 Vision Parkway have a Merged status.
You can merge Person or Organization party types. You can, however, only merge parties with the same party type. This implies that an organization can only be merged with another organization, a person with a person, and so on.
You must process and merge or appropriately transfer other Oracle Applications information of the duplicate party, such as transactions and attributes, into the merge-to party. Before using the Party Merge feature, your administrator must register all applications and entities that interact with Oracle Trading Community Architecture to ensure that all transaction and attributes are merged when the party is merged. See: Merge Dictionary Overview, Oracle Trading Community Architecture Administration Guide.
Related Topics
This example of a party merge shows both the before and after conditions.
ABC Company has implemented the Oracle Applications E-Business Suite. While checking the quality of its data, ABC Company determines that duplicate records exist for a party, Vision Corporation. Data for this party were entered into the database under the names Vision Corp. and Vision Inc. Using Party Merge, ABC Company plans to merge the two Vision parties.
Before the Merge
This table shows the from and to parties and their party sites.
| From Party Name | From Party Site | Site Use | To Party Name | To Party Site | Site Use |
|---|---|---|---|---|---|
| Vision Corp. | 500 Vision Parkway |
|
Vision Inc. | 100 Vision Parkway | Bill-to |
| 600 Vision Parkway |
|
600 Vision Parkway | Ship-to |
The 600 Vision Parkway party site exists for both parties and is considered to be duplicated.
During the Merge
The party site 500 Vision Parkway is transferred to Vision Inc. The details of 500 Vision Parkway, for example the bill-to, ship-to, and marketing party site uses stay with the party site.
The party site 600 Vision Parkway is merged with 600 Vision Parkway on Vision Inc. The bill-to site use is transferred because it does not exist for Vision Inc. The ship-to site use is merged because it already exists for Vision Inc.
After the Merge
Vision Corp.
Vision Corp. is set to a status of Merged.
The party site 600 Vision Parkway is set to a status of Merged.
The ship-to party site use for 600 Vision Parkway is set to a status of Merged.
Vision Inc.
Vision Inc. has three party sites:
100 Vision Parkway with a bill-to site use.
500 Vision Parkway with a bill-to, ship-to, and marketing site use.
600 Vision Parkway with a bill-to and ship-to site use.
In Party Merge, you can either merge or transfer the child entities that belong to the merge-from party. These entities can include party sites, contacts, relationships, and profile information. The merge procedures automatically handle the merge or transfer of other child entities.
Below are some of the TCA entities and the rules that are applied to them to determine whether the entities should be merged or transferred. In general, if the Party Merge process determines that the entities are exact duplicates based on the concatenation of table columns, the merge-from record will be merged with the merge-to record. If the entities are not exact duplicates, the merge-from entity is transferred to the merge-to entity.
The contact points and preferences, which determine whether the entities should be merged or transferred are as follows:
You must transfer contact points unless they are exact duplicates. Only exact duplicates are merged.
Contact points can point to a party site. These contact points are transferred or merged the way that the contact points are at the party level.
Contact preferences are always merged.
The customer information, which determines whether the entities should be merged or transferred are as follows:
Customer accounts are transferred to the merge-to party. After the parties are merged, you can use the Customer Merge program to merge customer accounts. This is a separate process that requires a separate concurrent request. See: Merging Customers.
Customer account sites are related to party sites. How customer account sites are merged depends on how the party site is processed.
Party site merge: The customer account site must be modified to point to the existing merge-to party site.
Party site transfer: The customer account site should point to the merge-from party site, which now points to the merge-to party.
Each role in a customer account points to a party. A customer account role can be processed during the Party Merge process in either of these situations:
The role points to the merge-from party. In this case, the role must be modified to point to the merge-to party.
The role points to an organization contact or other relatable party relationship. This relationship is being merged or transferred as the relationship's subject or object in a party merge.
Customer contact points point to party-level contact points. The customer contact point refers to the merge-to contact point on the merge-to party. This contact point is either a pre-existing contact point for the merge-to party or a contact point that has been transferred from the merge-from party.
If the duplicate check procedure identifies the following as exact duplicates, these entities are merged, otherwise they are transferred. The additional party information depends on whether the party is an organization, person, or either.
If the duplicate check procedure identifies the following as exact duplicates, they are merged.
Financial Numbers: If there is a duplicate financial number in the merge-to party's financial report data, that financial number is merged with the duplicate.
Financial Reports: The procedure checks for duplicates in the HZ_FINANCIAL_REPORTS table.
Industrial Reference: The procedure checks for duplicates in the HZ_INDUSTRIAL_REFERENCE table.
Organization Indicators: The procedure checks for duplicates in the HZ_ORGANIZATION_INDICATORS table.
Securities Issued: The procedure checks for duplicates in the HZ_SECURITY_ISSUED table.
If the duplicate check procedure identifies the following as exact duplicates, they are merged.
Citizenship: The procedure checks for duplicates in the HZ_CITIZENSHIP table.
Education: The procedure checks for duplicates in the HZ_EDUCATION table.
Employment History: The procedure checks for duplicates in the HZ_EMPLOYMENT_HISTORY table.
Person Interest: The procedure checks for duplicates in the HZ_PERSON_INTEREST table.
Person Language: The procedure checks for duplicates in the HZ_PERSON_LANGUAGE table.
Work Class: The procedure checks for duplicates in the HZ_WORK_CLASS table.
If the duplicate check procedure identifies the following as exact duplicates, they are merged.
Certifications: The procedure checks for duplicates in the HZ_CERTIFICATIONS table.
Credit Ratings: Credit ratings are always transferred unless the application providing the credit rating information has a duplicate check in its merge procedures.
Financial Profiles: The procedure checks for duplicates in the HZ_FINANCIAL_PROFILE table.
References: The procedure checks for duplicates in the HZ_REFERENCES table.
Related Topics
A party can have mappings to the source systems that the record originated from. A source ID is the ID of that record in the original system. For example, the Oracle party has the ID 12345 in the Gorman source system. When this Oracle record is imported from Gorman into the TCA Registry, 12345 becomes the source ID. See: Source Systems Overview, Oracle Trading Community Architecture Administration Guide.
When you merge two parties with source IDs, the IDs of the merge-from party are transferred to the merge-to party. If multiple source IDs from the same source system are not allowed to map to one TCA record, then only the merge-to party's mapping is kept active.
Note: D&B is the one source that can never be set to allow multiple mappings to one TCA record.
For example, this table shows source system mapping records for the Oracle 1 and Oracle 2 parties. The Gorman source system was set to allow multiple mappings from that source. As always, D&B allows only one source ID to map to a party.
| Party | Source System Name | Source ID | Status |
|---|---|---|---|
| Oracle 1 | Gorman | 10001 | Active |
| Oracle 1 | D&B | 22222 | Active |
| Oracle 2 | Gorman | 10002 | Active |
| Oracle 2 | D&B | 33333 | Active |
This table shows the result of Oracle 1 merging into Oracle 2.
| Party | Source System Name | Source ID | Status |
|---|---|---|---|
| Oracle 1 | Gorman | 10001 | Inactive |
| Oracle 1 | D&B | 22222 | Inactive |
| Oracle 2 | Gorman | 10001 | Active |
| Oracle 2 | Gorman | 10002 | Active |
| Oracle 2 | D&B | 33333 | Active |
The Oracle 1 mapping record for Gorman is inactivated, and a new mapping record is created for Oracle 2 and source ID 10001. Because a party can have multiple mappings to Gorman, Oracle 2 ends up with the mapping transferred from Oracle 1.
The mapping to D&B from Oracle 1 is inactivated and does not transfer over to Oracle 2 because a party cannot have multiple mappings to D&B. Oracle 2 remains with the same mapping to D&B, before and after the merge.
Related Topics
Oracle Trading Community Architecture lets you purchase data from D&B's global business databases. Information purchased from D&B is stored in the party tables at the party level and is also merged with other party information when you run Party Merge.
Party Merge resolves and merges D&B data for the merge-from and merge-to parties, and retains as much of the D&B data about the parties as possible. When two parties with D&B data are merged, these situations might arise:
D-U-N-S Numbers Are Different: If the D-U-N-S Numbers for the merge-from and merge-to parties are not the same number, the data for the merge-to party is retained. The D&B data for the merge-from party is set to the Merged status.
D-U-N-S Numbers Are the Same: If the D-U-N-S Numbers for the merge-from and merge-to parties are the same number, the latest D&B data, whether for the merge-from or merge-to party, is retained. If the latest D&B data is stored for the merge-from party, that data overwrites the D&B data stored for the merge-to party.
No D&B Data Exists for the Merge-To Party: If D&B data exists for the merge-from party but not the merge-to party, the D&B data for the merge-from party transfers to the merge-to party as a result of the merge process.
Merge-From Party is a Branch of Merge-To Party: If the merge-to party is the headquarters for the merge-from party, which is a branch, and the merge-to party contains the D&B data, this data is retained. The status of the merge-from party is set to Merged.
Merge-From Party is the Headquarters of Merge-to Party: If the merge-from party is the headquarters and the merge-to party is its branch, the D&B data for the merge-from party is copied to the merge-to party. The merge-to party becomes the headquarters. All branches associated with the merge-from party now belong to the merge-to party.
Related Topics
Third Party Data Integration Overview
Use the Merge Batch window to set up a merge batch for the parties or party sites that you are merging. See:
You can only merge parties of the same party type. You can merge or transfer party sites, organization contacts, party relationships, and profiles related to a party. All other entities related to a party are either always merged or always transferred based on the merge procedures defined for that entity.
When you select a party as the merge-from or merge-to party in a batch, the records for that party are locked and cannot be selected as a merge candidate for this or any other batch until after this batch is submitted and processed.
Note: For your merge batch, you cannot include any party that is already part of a de-duplication merge request. See: Merge Requests Overview, Oracle Customer Data Librarian User Guide.
Set the HZ: Enable DQM Merge Suggestion profile option to 'No' to disable DQM suggestion. This will reduce time lag and improve performance during the Create Merge Batch process.
Aside from manually creating merge batches in the Merge Batch window, you can also use batch duplicate identification to automatically determine duplicate parties based on match rules. You create merge batches from the suggested duplicate candidates. See: Batch Duplicate Identification Overview.
In the Merge Batch window, you can specify if you want to delete the merge-from party after the merge process completes. Otherwise, the merge-from party is set to a status of Merged.
The results of the merge are saved only after the entire batch has completely processed. If one record results in error, none of the parties in the batch are merged. If you want to save the resulting party after each merge, you must create a separate batch for each pair of parties to merge.
If the merge batch creation itself results in error, review the log of the Create Merge Batch program in Standard Request Submission. After fixing the errors, you can manually rerun the Create Merge Batch program.
Before you create a merge batch, you should decide if you want to delete all of the records of the merge-from party.
Use this parameter when you submit the Create Merge Batch program to re-create a merge batch that previously resulted in error.
Enter the merge ID of the merge batch that you want to re-create. Only failed merge batches are available. The merge ID is the number automatically appended to the end of the merge batch name.
Related Topics
When you create a merge batch with parties to merge, you can also define the merge of entities from the merge-from and merge-to parties, including:
You can also view party profile attributes of the merge-from and merge-to parties. See: Viewing Profile Information.
If you used batch duplicate identification to create the merge batch, all the details of the merge-from and merge-to parties are already determined and cannot be changed. See: Batch Duplicate Identification Overview.
See: Party Merge Deployment Category,, Oracle Trading Community Architecture Administration Guide for information on the profile options that must be set to use party merge.
Navigate to the Merge Batch window.
Enter a batch name that is unique and related to the parties that you are merging.
Enter a reason for the merge, either a predefined reason or your own.
Check Delete Merged Records to delete the merge-from party records after the batch merge completes. Do not check this box if you do not want to delete the merged records. These records are instead assigned a Merged status.
In the Party Details region, enter pairs of parties that you want to merge, including the party type and merge reason for each pair.
Save your work before moving on to the tabbed regions.
Related Topics
You can merge party sites either within a single party or between a pair of parties that you are merging.
Note: If every party site address to be merged is also an account site address for the same respective party, then tax validation applies to the merge. See: Tax Validation for Merge.
Navigate to the Party Sites tabbed region after you enter the basic merge batch information. See: Merging Parties or Merging Party Sites of a Party.
Enter the from site's address and the appropriate merge operation, Merge or Transfer Party Merge.
If you enter the Merge operation, you must enter an address for the merge-to party site.
Party relationships are binary roles between two parties, such as a partnership. You can merge or transfer relationships that the merge-from or merge-to party has, as part of the merge of the two parties. If the same party relationship exists for these two parties, the relationships are automatically selected to be merged and cannot be transferred.
Note: You cannot use Party Merge to merge parties of type Relationship, or to independently merge relationship records without a merge batch with at least one organization or person involved in those relationships.
Example
If Joe is your contact at Vision Corporation, you can record this as a relationship between the person Joe and the organization Vision Corporation. This table shows details of this sample relationship.
| Party ID | Subject ID | Object ID | Type of Relationship |
|---|---|---|---|
| 789 (Joe, contact for Vision Corp.) | 456 (Joe) | 123 (Vision Corp.) | Contact Of |
After reviewing your database, you might determine that Vision Corporation and Vision Inc., another party in your database, are duplicates that should be merged.
After the merge process, the contact information would be changed as shown in this table.
| Party ID | Subject ID | Object ID | Type of Relationship |
|---|---|---|---|
| 789 (Joe, contact for Vision Inc.) | 456 (Joe) | 123 (Vision Inc.) | Contact Of |
Navigate to the Party Relationships tabbed region after you enter the basic merge batch information. See: Merging Parties.
Note: This tab does not show relationships in which a person is a contact, employee, or member of an organization, or any other role in the Party Contacts relationship group. For these relationships, see: Merging Organization Contacts.
For each relationship to be transferred or merged for a party, enter that relationship's subject, object, and type in the From Relationships region.
For example, if a type of relationship exists called Subsidiary of and Vision Manufacturing is a subsidiary of Vision Corporation, then Vision Manufacturing would be the subsidiary of Vision Corporation. Vision Manufacturing would be the subject of the relationship and Vision Corporation would be the object of the relationship.
Party relationships do not require a hierarchical relationship like a parent-child relationship. For example, party relationships defined as Partner of, Colleague of, Competitor of, and so on do not imply a hierarchical relationship, but you have to identify a subject and object of the relationship before you can merge relationships.
Enter either Merge or Transfer for the operation.
You can merge only if the same party relationship exists for the merge-from and merge-to parties.
Enter a relationship for the merge-to party in the To Relationships region.
You can merge organization contacts between parties that you are merging. See: Merging Parties.
If the same organization contact exists for the merge-from and merge-to parties, that contact is automatically selected to be merged.
Navigate to the Org Contacts tabbed region after you enter the basic merge batch information. See: Merging Parties.
Note: This tab shows only relationships in which a person is a contact, employee, or member of an organization, or any other role in the Party Contacts relationship group. For all other relationships, see: Merging Party Relationships.
In the From Org Contact region, for each organization contact for the merge-from party, enter that contact's name and title. You can enter the type, department, and party site to identify a group of organization contacts.
Enter either Merge or Transfer for the operation.
You can merge only if a similar organization contact exists for the merge-to party.
If you enter Merge as the operation, enter an organization contact for the merge-to party that the party in the From Org Contact region is to be merged into.
For the parties that you are setting up to be merged in a merge batch, you can view the merge-from and merge-to parties' profile information. See: Merging Parties.
Party profile information differs depending on whether the parties to merge are organizations or people. You can see the taxpayer ID and tax registration number for both, but the date of birth for parties of type Person and the D-U-N-S Number for parties of type Organization.
Navigate to the Person Profiles or Org Profiles tabbed region after you enter the basic merge batch information. See: Merging Parties.
For either the person or the organization, you see the profile of the merge-from party that is to be merged with the profile of the merge-to party.
Use the Merge Batch window to create merge batches for merging duplicate party sites within a single party. For each batch, you can include multiple parties to merge party sites for.
After the merge process, all entities associated with the merge-from party site, including customer account sites, refer to the merge-to party site.
To submit a merge for two sites of the same party, you cannot check Delete Merged Records. Checking that check box implies deleting both the merge-from and merge-to parties.
If the merge-from address is the identifying address, you must confirm that the merge-to address should be used as the identifying address to continue with the merge. If you want to merge the identifying address of a customer account, you can use Customer Account Merge to merge the account sites that point to these party sites only after you merge the party sites. See: Merging Customers.
Navigate to the Merge Batch window.
Enter a batch name that is unique and related to the party for which you are merging the party sites.
Enter a reason for the merge, either a predefined reason or your own.
Make sure that Delete Merged Records is not checked.
In the Party Details region, enter one or more from-parties for which you want to merge the party sites, including the party type.
Check Site Merge. The To Party fields are automatically populated with information from the From Party fields.
Alternatively, you can just enter the party name or party number of your from-party in the To Party fields.
Enter the reason for merging these party sites.
Save your work.
Enter all party sites to be merged in the Party Sites tabbed region. See: Merging Party Sites.
The other tabbed regions are disabled.
Related Topics
After you create the merge batch to merge either different parties or party sites of the same party, you have three options to process your merge batch:
Preview your merge batch and the outcome of the merge process before submitting the Party Merge process.
Submit the Party Merge process immediately after entering your merge details.
Save your work and submit the Party Merge process at a later time.
After a merge batch is successfully processed, you cannot reverse the results.
Create the merge batch in the Merge Batch window. For more information, see: Creating Merge Batches.
Click Preview Batch.
The Party Merge process runs and merges the appropriate parties and other entities, but does not save the merged records to the database. The request number is displayed in the Last Request ID field.
In Standard Request Submission, find the Party Merge process and preview the expected effect of the merge process on the merging parties and their entities. See: Reviewing the Party Merge Log.
If you query for the merge batch at this point in the Merge Batch window, the Merge Done check boxes are not checked. Even if you checked the Delete Merged Records check box, no records are deleted because the merge process is submitted in the preview mode.
Create the merge batch in the Merge Batch window. See: Creating Merge Batches.
Optionally save the merge batch and submit it later.
Click Run Batch.
The Party Merge process runs and merges the appropriate parties and other entities. The entire batch must be successfully processed before the merged records are saved to the database.
The request number is displayed in the Last Request ID field.
In Standard Request Submission, find the Party Merge process and view the results and status of the merge process. See: Reviewing the Party Merge Log.
If you query for the merge batch at this point in the Merge Batch window, the Merge Done check box is checked. If you checked Delete Merged Records, the merge-from parties are set to the Deleted status.
If the Party Merge process results in error, you can rerun it from Standard Request Submission after you fix the errors. See: Identifying Types of Errors.
Use this parameter when you submit the Party Merge process to remerge a batch that previously resulted in error.
Enter the merge ID of the merge batch that you want to remerge. Only failed merge batches are available. The merge ID is the number automatically appended to the end of the merge batch name.
Related Topics
You can use the log of the Party Merge process to review the parties and related entities affected by the process. This output file is automatically generated after you run the Party Merge process. The report body displays Merged or Deleted for each merge-from party to indicate the status of the merge-from party or party site. The report displays an error message if the Party Merge process fails.
This table shows the report headings and the corresponding values.
| Heading | Value |
|---|---|
| Request ID | The request ID for your concurrent process. |
| Log Message | The sequence of processes that run to execute the merge batch, including:
|
| Execution status | The possible execution status combinations are:
|
The log message displays the details of the entities that have been merged or transferred. The entities that are merged or transferred are based on the merge procedures that were registered with the Merge Dictionary. See: Merge Dictionary Overview, Oracle Trading Community Architecture Administration Guide.
The entities include, but are not restricted to, parties, party sites, relationships, contacts, profiles, contact points, customer accounts, customer account sites, and so on.
In addition to these standard TCA entities, other Oracle Applications and legacy system entities can be registered with the Merge Dictionary. These entities are also merged during the Party Merge process. You can also view the details about these entities in the Party Merge Request log file.
Related Topics
The Party Merge process encounters two types of errors: data errors and procedure errors. After you fix the errors, you can resubmit the Party Merge process from Standard Request Submission. See: Processing Merge Batches.
The Party Merge process might fail at the batch or party level if any record contains corrupt data. If the Party Merge process encounters corrupt data, the entire batch fails, and none of the parties are merged. Users should be able to correct most data errors.
The Party Merge process can fail if any procedures were not correctly coded, registered, and tested. The Party Merge log identifies the procedure that caused the Party Merge process to fail. Procedure errors must be corrected by an application developer or administrator who has access to the error log, Merge Dictionary, and PL/SQL procedures.
Related Topics
Oracle Trading Community Architecture allows you to merge parties and customers, or customer accounts. You can use the Customers Merge window and the Customer Merge program to merge customer accounts. See: Merging Customers.
You can use the party merge Web service to merge two or more customer parties and get details of the party merge. The Party Merge Web service has two operations – the Create Party Merge Request, to create a request for merging parties and the Get Party Merge Details to retrieve details about a party merge.
You can use the account merge Web service to retrieve details of the customer account merge. The Account Merge Web service has one operation – Get Account Merge Details to retrieve details about a customer account merge. See: Web Services Implementation Overview, Oracle Trading Community Architecture Administration Guide.
If you find duplicate parties, you should determine if duplicate customer accounts exist between the merge-from and merge-to parties. If you find duplicate customer accounts, duplicate parties might exist for these customer accounts. You should verify that duplicate parties exist and merge those duplicate parties.
When two customer accounts are merged and the corresponding parties are verified as duplicates, the parties can be merged.
When two parties are merged and the corresponding customer accounts are verified as duplicates, the customer accounts can be merged.
Related Topics
ABC Company has implemented the Oracle Applications E-Business Suite. While checking the quality of its customer data, ABC Company determines that duplicate records exist for a party, Vision Corporation. Data for this party were entered into the database under the names of Vision Corp. and Vision Inc. Using Party Merge, ABC Company plans to merge the two Vision parties.
Before Party or Customer Account Merge
This table shows the from and to parties and their customer accounts and account party sites.
| From Party Name | From Acct Num | From Acct Party Site | Site Use | To Party Name | To Acct Num | To Acct Party Site | Site Use |
|---|---|---|---|---|---|---|---|
| Vision Corp. | 765432 | 500 Vision Parkway (ID: 1VISCORP) |
|
Vision Inc. | 234567 | 100 Vision Parkway (ID: 1VISINC) | Bill-to |
| 600 Vision Parkway (ID: 2VISCORP) |
|
600 Vision Parkway (ID: 2VISINC) | Ship-to |
The 600 Vision Parkway party sites exist for both Vision Corp. and Vision Inc. and are deemed to be duplicates.
Merging the Parties
The 500 Vision Parkway party site is transferred to Vision Inc. The details for 500 Vision Parkway, such as the bill-to, ship-to, and marketing party site uses stay with the party site.
The 600 Vision Parkway party site from Vision Corp. is merged with 600 Vision Parkway for Vision Inc. The bill-to site use is transferred because it does not exist for Vision Inc. The ship-to is merged because it already exists for Vision Inc.
After Party Merge and Before Customer Account Merge
Vision Corp.
Vision Corp. is set to a status of Merged.
The 600 Vision Parkway party site is set to a status of Merged.
The ship-to party site use for 600 Vision Parkway is set to a status of Merged.
Vision Inc.
Vision Inc. has two customer accounts with these account numbers:
765432
234567
Vision Inc. has three party sites:
100 Oracle Parkway with a bill-to site use.
Customer account site ID: 1VISINC.
500 Oracle Parkway with a bill-to, ship-to, and marketing site use.
Customer account site ID: 1VISCORP.
600 Oracle Parkway with a bill-to and ship-to site use.
Customer account site ID: 2VISCORP.
Customer account site ID: 2VISINC.
Merging the Customer Accounts
Customer account 765432 is merged with customer account 234567. Customer account site 2VISCORP is merged with customer account site 2VISINC.
After Customer Account Merge
Customer account 765432 is set to a status of Inactive.
Customer account site 2VISCORP is set to a status of Inactive.
The bill-to and ship-to site uses on customer account site 2VISCORP are set to a status of Inactive.
Vision Inc. has one customer account, 234567.
Vision Inc. has three party sites:
100 Oracle Parkway with a bill-to site use.
Customer account site ID: 1VISINC.
500 Oracle Parkway with a bill-to, ship-to, and marketing site use.
Customer account site ID: 1VISCORP.
600 Oracle Parkway with a bill-to and ship-to site use.
Customer account site ID: 2VISINC.
Merging the Customer Accounts
Customer account 765432 is merged with customer account 234567. Customer account site 2VISCORP is merged with customer account site 2VISINC.
After Customer Account Merge and Before Party Merge
Customer account 765432 has the status of Inactive.
Customer account site 2VISCORP has the status of Inactive.
The bill-to and ship-to site uses for customer account site 2VISCORP have the status of Inactive.
Vision Corp. has the following party sites:
500 Vision Parkway, with three uses: bill-to, ship-to, and marketing.
600 Vision Parkway, with two uses: bill-to and ship-to.
Vision Corp. does not have any customer accounts or customer account sites belonging to it.
Vision Inc. has one customer account, 234567.
Vision Inc. has two party sites:
100 Vision Parkway, with one use: bill-to.
Customer account site ID: 1VISINC.
600 Vision Parkway, with one use: ship-to.
Customer account site ID: 2VISINC.
Merging the Parties
The 500 Vision Parkway party site is transferred to Vision Inc. The details of the party site uses for 500 Vision Pkwy, such as bill-to, ship-to and marketing stay with the party site.
The 600 Vision Parkway party site is merged with 600 Vision Parkway to Vision Inc. The bill-to site use is transferred because it does not exist for Vision Inc. The ship-to is merged because it already exists for Vision Inc.
After Party Merge
Vision Inc. has one customer account, 234567.
Vision Inc. has three party sites.
100 Oracle Parkway with a bill-to site use.
Customer account site ID: 1VISINC.
500 Oracle Parkway with a bill-to, ship-to, and marketing site use.
Customer account site ID: 1VISCORP.
600 Oracle Parkway with a bill-to and ship-to site use.
Customer account site ID: 2VISINC.