This chapter describes how to resolve duplicate parties or duplicate information within a party.
This chapter covers the following topics:
Merge duplicate parties in the Oracle Trading Community Architecture (TCA) Registry.
Cleanse a specific party so that it does not have any duplicate information.
The TCA Registry is the single source of party information for all Oracle E-Business Suite applications. These applications provide user interfaces, batch data entry functionality, and other features for you to enter party information. Multiple points of data entry can result in duplicate and inaccurate information.
Each application must quickly, accurately, and consistently retrieve information from the TCA Registry for transaction processing. Duplicate data in the Registry can reduce the efficiency and accuracy of party processing and reports.
De-duplication provides functionality for the entire process of resolving duplicate parties and information in the TCA Registry:
Identify duplicates: Create merge requests, which contain information about the duplicate parties that you want to merge or the party that you want to cleanse.
Automatically merge duplicates: Optionally run Automerge to automatically merge parties identified as definite duplicates. Automerge bypasses manually creating, mapping, and submitting merge requests.
Manage merge requests: Review, assign, and reject specific requests.
Map merge requests: Determine the results of the merge by specifying the information that remains after the merge. You map the duplicate information to merge either among parties or within the party that you are cleansing.
Submit merge requests: Run the Party Merge process to perform the actual merge, either for duplicate parties or within a party to cleanse it.
Note: If you have source system information in the TCA Registry, de-duplication uses the Single Source of Truth record. See: Single Source of Truth Overview, Oracle Trading Community Architecture Administration Guide.
Related Topics
Introduction to Oracle Customer Data Librarian
Major Features of De-Duplication
The System Duplicate Identification (SDI) feature lets you create SDI batches that contain potential sets of duplicates. De-duplication runs a program to identify duplicates based on criteria that you specify. You can use any duplicate set in a batch as the basis for a new merge request.
You can run Automerge as part of creating SDI batches to automatically merge definite duplicates. This process bypasses manually creating, mapping, and submitting merge requests for obvious duplicates. Parties in the SDI batch that are not merged are included in a new batch, for manual review at a later time.
You can create two types of merge requests:
Multiple: Contains a duplicate set of two or more parties to merge.
Single: Contains a single party to cleanse.
De-duplication provides three methods for creating merge requests. Each Multiple type request must contain parties of the same type, such as Person or Organization.
Aside from reviewing merge requests, you can:
Assign requests to specific users
Unassign requests
Reject requests
For each merge request, you map the duplicate information to determine the results of the merge. For both Single and Multiple type requests, you map address and relationship information. De-duplication can provide default suggestions for either mapping.
For Multiple type requests, you also map party profile attributes, which describe the party. For example, for the D-U-N-S Number attribute, you specify which number from the duplicate set should remain after the merge.
After reviewing your mapping, you can submit the merge request for the Party Merge process.
Related Topics
These examples illustrate using de-duplication to merge multiple duplicate parties or cleanse a party.
Related Topics
You create a merge request with a set of four duplicate parties to merge, each with its own party sites or addresses, relationships, and party profile attribute values. Your merge request is automatically assigned the Multiple type.
This table shows the duplicates, addresses, and attribute values for Registry ID, CEO Name, and Number of Total Employees.
Duplicate | Registry ID | CEO Name | Number of Total Employees | Party Site |
---|---|---|---|---|
Party A | 102 | Joe Smith | 100,000 | Address 1 Address 2 |
Party B | 101 | Joseph Smith | 200,000 | Address 3 Address 4 |
Party C | 101 | Joseph Smith | 100,000 | Address 5 Address 6 |
Party D | 102 | Joey Smith | 100,000 | Address 7 Address 8 Address 9 |
Party D is defaulted as the master party that remains after the other three duplicates merge into it.
Map Party Profile Attributes
The default party profile attributes are determined by profile option settings. You can, however, designate a value from any duplicate to remain after the merge, as shown for example in this table.
Attribute | Party | Attribute Value |
---|---|---|
Registry ID | Party D | 102 |
CEO Name | Party B | Joseph Smith |
Number of Employees | Party D | 100,000 |
As a result, Party D remains after the merge with these party profile values.
Map Addresses and Relationships
You decide to use the default mapping suggestions:
Address 1 and 7 are duplicates, and Address 1 is the master address that remains after the merge.
Address 2 and 3 are duplicates, with Address 2 as the master.
Address 4, 5, and 9 are duplicates, with Address 9 as the master.
Address 6 is not a duplicate and should transfer to Party D after the merge.
Address 8 is not a duplicate and should remain in Party D.
As a result, Party D remains after the merge with these party sites:
Address 1, which Address 7 merged into
Address 2, which Address 3 merged into
Address 6, which transferred to Party D
Address 8, which remained in Party D
Address 9, which Address 4 and 5 merged into
This diagram illustrates the address mapping and the result after the merge:
Note: Address 7 merged into Address 1, which remained after the merge even though Address 7 is the site from Party D. De-duplication lets you specify the master address no matter if it is from the master party or not.
For this merge request, you would also similarly map relationships among the four parties.
You create a merge request with one party to cleanse address and relationship information for. Your merge request is automatically assigned the Single type.
This party has these employee relationships, in which the party is the employer of these employees:
Jennifer Smith
Joey Lee
Jenny Smith
Janie Smythe
Joseph Lee
Map Addresses and Relationships
The suggested mapping defaults for the employee relationships include the duplicate sets shown in this table.
Duplicate Employees | Master Employee |
---|---|
Jennifer Smith Jenny Smith |
Jennifer Smith |
Joseph Lee Joey Lee |
Joseph Lee |
The master employee is randomly defaulted. You can select another employee as the master or override the default groupings themselves. In this case, you designate Jenny Smith as the master employee for the first duplicate set and determine that Joseph and Joey Lee are not duplicates.
As a result, these employees remain after the merge:
Jenny Smith
Janie Smythe
Joseph Lee
Joey Lee
For this merge request, you would also similarly map the party's addresses.
System Duplicate Identification (SDI) is a process that produces batches of system-identified duplicates to merge. Each duplicate set within a batch can have either multiple parties to merge together or just one party to cleanse. De-duplication runs the DQM Duplicate Identification program to generate the duplicate sets in each batch, based on your criteria.
As part of creating an SDI batch, you can run Automerge to automatically merge definite duplicates. Parties are included in Automerge processing if they reach an automatic merge threshold. Parties that are not automatically merged are included in a new SDI batch.
Note: You can run Automerge only as part of creating an SDI batch. You cannot first create a batch and then run Automerge on it.
You can use any of the duplicate sets in an SDI batch as the basis of a new merge request. See: Merge Requests Overview and Creating Merge Requests.
From the System Duplicate Identification Batches page, you can:
Create New Batch: See: Creating System Duplicate Identification Batches.
Phase: Review the details of the DQM Duplicate Identification program, for example the error log.
Detail: See: Reviewing System Duplicate Identification Batches. You can also create merge requests based on duplicate sets from the SDI batch you are reviewing. See: System Duplicates.
View Report: See: Viewing System Duplicate Identification Batch Reports.
Administration: Manage the list of parties marked as not duplicates of selected parties. See: Administering Nonduplicate Mappings.
The System Duplicate Identification Batches page shows SDI batches created by the user. To restrict the list, you can search for batches by:
Batch Name: The name of the batch.
Batch ID: The number that is automatically appended to the batch name when the batch is created.
Phase: The status of the DQM Duplicate Identification program that generates the duplicate sets after the batch is submitted.
Running
Pending
Inactive
Completed
Note: Duplicate sets are sequentially generated and immediately available, even if the program is still identifying more duplicates.
Created By: The user who created the SDI batch.
The search results provide additional information about the SDI batches:
Status: Status of the phase of the DQM Duplicate Identification program, for example Normal or Error.
Source
Import: Batch was created as a result of Registry de-duplication during an import process. If Automerge was part of the de-duplication, the batch contains only the parties that were automatically merged.
Import AM: Batch was created as a result of Registry de-duplication, with Automerge, for an import process. This batch contains only parties that were not automatically merged.
See: Registry De-Duplication.
System: User manually created the batch. If Automerge was part of the batch creation, the batch contains only the parties that were automatically merged.
System AM: Batch was created as a result of Automerge run as part of creating a batch. This batch includes only parties that were not automatically merged.
Automerge: Batch contains duplicate sets that were automatically merged, when Automerge was run as part of:
Creating the SDI batch. See: Automerge in System Duplicate Identification.
Registry de-duplication for an import process. See: Registry De-Duplication.
Related Topics
You can create System Duplicate Identification batches that contain sets of system-identified duplicates. De-duplication generates SDI batches based on:
The Data Quality Management match rule that you specify. See: Match Rules Overview, Oracle Trading Community Architecture Administration Guide.
Your conditions for a subset of parties to use for identifying duplicates. See: Defining Subset for Identifying Duplicates.
When you define and submit a SDI batch, the DQM Duplicate Identification program sequentially generates duplicate sets for the batch, using your match rule and conditions. A unique batch number is automatically appended to the batch name when you submit the batch. The batch appears in the System Duplicate Identification Batches page as soon as you submit the batch, even if the program has not yet finished running.
You can optionally run Automerge as part of creating the batch. Automerge lets you merge parties that are definite duplicates without going through the process of creating, mapping, and submitting merge requests. See: Automerge, Oracle Trading Community Architecture Administration Guide.
For the batch, you select a match rule that is enabled for Automerge, and then select Run Automerge. Automerge is not run if you do not select both. You should be familiar with how your selected match rule works, and especially aware of the automatic merge threshold.
Caution: You cannot undo automatic merges. For Automerge, use only match rules that provide exact matches.
After the duplicate sets are identified for the batch, Automerge automatically merges the sets in which all parties have match scores that exceed the automatic merge threshold defined in your selected match rule. Merge requests are automatically created with these duplicate sets. You can view and track these Automerge merge requests in the Merge Request Queue, as well as resubmit failed Automerge processes. See: Merge Requests Overview.
If any party in an Automerge merge request already exists in another merge request, the request would result in error. Even if one request fails, the other requests from the same SDI batch would continue to process accordingly.
If the System Duplicate Identification batch includes parties that do not reach the automatic merge threshold, a new batch is created to include those duplicate sets.
Note: When you create a batch with Automerge selected, the batch name is automatically prefixed with AM. If a new batch is created for the duplicate sets that were not merged, that batch has the same batch name, only without the AM.
Define conditions that a record must meet to be an input record used to identify duplicates within your entire system. For example, you can specify that the Registry ID must be less than 1001. All parties with such a Registry ID are compared to one another, as well as to all other parties in your system, to determine duplicates for the System Duplicate Identification batch.
If you select to match only within the subset, then the records that meet the criteria are compared only to one another, not to all records. From the above example, the SDI batch would contain only parties with a Registry ID less than 1001.
You can create the System Duplicate Identification batch as soon as possible or at a specific date and time. Optionally also schedule the repeat this batch creation at a regular interval. For example, you can specify to repeat every 20 days, from the first run (whether that is as soon as possible or at a specific date and time) until your specified end date.
Related Topics
System Duplicate Identification
You can review any System Duplicate Identification batch that was submitted, even if the DQM Duplicate Identification program is still running to generate all duplicate sets.
Subset for Identifying Duplicates specifies filtering criteria used to create the SDI batch, if any. See: Creating System Duplicate Identification Batches.
Optionally create a merge request using any of the duplicate sets in this batch.
Tip: Select multiple duplicate sets to create separate merge requests with each set, at the same time.
You can also update duplicate sets only, or create a merge request using the duplicate set you are updating. See: System Duplicates.
Related Topics
System Duplicate Identification
The report for any submitted or completed System Duplicate Identification (SDI) batch shows the number of parties with a specified number of duplicates. You determine the duplicate categories to report on, for example, parties with two other duplicates, five to seven, or more than ten. The report displays the number of parties in each category, as well as the ratio to the total number of parties in the batch, expressed as a percentage.
For example, you define a category for five duplicates. The report shows that there are 36 parties in the SDI batch with five duplicates, and 72 total parties in the batch, and that 50% of the parties in the batch have five duplicates.
In the graphical view of the report, the duplicate categories lie along the x-axis and the number of parties in each category along the y-axis. In this example, for the 5 category, the bar would go up to 36. The tabular view for this category is as follows in this table:
Duplicates Per Customer Record | Frequency | Percentage |
---|---|---|
5 | 36 | 50 |
When you configure the duplicate categories to report on, you must divide up the categories in a sequential and gapless manner. This table provides an example:
Starting Duplicate Count | Meaning | Description |
---|---|---|
0 | 0 | No Duplicates |
1 | 1 | One Duplicate |
2 | 2 - 5 | Two to Five Duplicates |
6 | 6 - 9 | Six to Nine Duplicates |
10 | 10+ | More Than Ten Duplicates |
You cannot, for example, start the duplicate count at five, then two, then ten. Each duplicate category ranges from its starting duplicate count to the next category's starting duplicate count. The last category in the sequence always means duplicates of more than its starting duplicate count, in this example, more than ten duplicates.
To get an accurate count of all the parties in the SDI batch, start the sequence at zero. If you start the sequence at 2, for example, the report does not include parties with no or one other duplicate.
Note: The meaning that you enter is displayed in the report to represent the duplicate category. The entered description is not displayed.
Related Topics
System Duplicate Identification
Parties are marked as nonduplicates of other parties as part of creating merge requests from System Duplicate Identification batches, or just updating duplicate sets in SDI batches. Nonduplicate mappings ensure that the parties are not selected as duplicate candidates in the future. See: System Duplicates.
For the selected party, only nonduplicates with an end date of today or later are displayed. To administer mappings, you can change the end date:
To make the mapped parties available to be selected as duplicates again.
To update the duration of the nonduplicate mapping.
So that the two parties to be always mapped as not duplicates of each other.
You can display certification levels and reasons through personalization. Certification assignments indicate the quality of records, and the meaning of each level is based on your organization's business needs. See: Assigning Certifications.
Related Topics
System Duplicate Identification
A merge request contains all the information for a specific merge process, including:
The party or parties involved in the merge
The intended results of the merge
For an overview of the entire merge process, see: De-Duplication Overview.
A merge request of type Multiple contains a set of duplicate parties to merge. Each Multiple type request has a designated master party that remains after the other duplicates merge into it. A request of type Single involves cleansing one party.
When you create or update a merge request, the Create Merge Batch process runs to create or re-create the request, including generating the suggested mapping defaults. For example, if you remove a duplicate from the request, the process runs to regenerate the merge request. Running the Create Merge Batch process is called preprocessing in de-duplication.
After you map the merge request to determine the results of the merge, you submit the request for the actual Party Merge process.
Caution: You cannot undo a merge. Use only match rules that provide exact matches.
Start at the Merge Request Queue page to:
Create Request or Create Merge Request: See: Creating Merge Requests.
Merge Request Name: See: Reviewing Merge Requests.
Assign: Assign and unassign merge requests of any phase, no matter whom the request is currently assigned to or who created the request.
Tip: You can click Remove from Set to remove any merge request from the assignment. You are not deleting or rejecting the request.
Reprocess: Reprocess selected merge requests to regenerate default master records, as well as default profile attributes and default relationship and address groupings for mapping. You might want to reprocess, for example, if you change profile option settings or match rules that affect merge requests.
Map: Map and submit merge requests, or reject the request. See: Mapping Merge Requests.
If the HZ: Data Sharing and Security Rules for Data profile option is set to:
Apply Rules at Mapping and Do Not Show Access Column: Then Data Sharing and Security (DSS) rules determine mapping access. You can map a merge request only if the DSS rules assigned to your user ID allow you to update all the parties in the request.
Apply Rules at Mapping and Show Access Column: Then, in addition, the Access column is displayed to indicate your access status.
See: Data Sharing and Security Overview, Oracle Trading Community Architecture Administration Guide.
Status: If the request has a status of Submitted for Merge, Completed, or Error, you can see details of the Party Merge process, for example the error log.
Resubmit Requests: Rerun processes that originally resulted in error. See: Resubmitting Requests.
The Merge Request Queue page shows all merge requests. To restrict the list, you can search for requests by:
Merge ID: The merge request ID.
Name: The master party of Multiple type requests or the party to cleanse in Single type requests.
Note: Merge request names with the SUGG: prefix are for suggested merge requests that the system creates after merging parties. These requests contain parties related to the originally merged parties. See: Relationships.
Source: The method used to create the merge request.
Import: Manually from a System Duplicate Identification batch that import Registry de-duplication created. If Automerge was part of the de-duplication, then the merge request was automatically created to contain a duplicate set that was automatically merged.
Import AM: Manually from a SDI batch that resulted from import Registry de-duplication with Automerge. The batch contains the duplicate sets that were not automatically merged.
See: Registry De-Duplication.
System AM: Manually from a SDI batch that resulted from creating a batch with Automerge. The batch that contains only parties that were not automatically merged was used to create this merge request.
System: Manually from a SDI batch that was also manually created. If Automerge was part of the batch creation, then the merge request was automatically created to contain a duplicate set that was automatically merged.
User: Using Smart Search, Registry ID selection, or other manual user selection.
Phase: The mapping phase of the request, which corresponds to the Status column in the table.
AM Queue: Request is in the queue to be automatically merged by the Automerge program.
Completed: Party Merge process successfully completed.
Error: Party Merge process resulted in error.
Mapping: Request has been modified since creation.
Preprocess: Create Merge Batch process is running to create or regenerate the request, which is not yet ready for mapping.
Rejected: Request has been rejected.
New: Create Merge Batch process has successfully completed, and the request has not been modified since but is ready for mapping.
Submitted: Request has been submitted for the Party Merge process.
Tip: Refresh the status to see the latest values.
Assignment: The user assigned to the request, or Unassigned.
From the Resubmit Requests bin on the Merge Request Queue page, you can resubmit preprocessing, the Create Merge Batch process, or the Party Merge process for appropriate merge requests. If either process previously resulted in an error, you resubmit the process for that merge request after you fix the problem.
For merge requests that are automatically created and then merged, as part of System Duplicate Identification batch creation, you can also resubmit Automerge processes that resulted in error. For the Batch parameter, select the SDI batch ID that the merge request originates from. See: Automerge in System Duplicate Identification and Automerge, Oracle Trading Community Architecture Administration Guide.
You can create merge requests:
Registry ID: By selecting specific parties. See: Registry ID.
From a Registry ID list of values, you select at least one party to include in your new merge request.
Smart Search: Using Smart Search to find potential duplicates. See: Smart Search.
Smart Search provides a list of parties based on your criteria. You select at least one party to include in a new merge request.
System Duplicates: From duplicate sets in a System Duplicate Identification (SDI) batch. See: System Duplicates.
A SDI batch contains sets of duplicates that de-duplication identifies based on your criteria for the batch. You select duplicate sets from any batch to create one or more merge requests. See: System Duplicate Identification.
Note: To create a merge request of type Single, use any of the methods to create a request with only the party that you want to cleanse.
In your new merge request, you cannot include parties that already belong to either another merge request or a merge batch in Oracle Trading Community Architecture Party Merge. A message would inform you if you select such a party. See: Creating Merge Batches, Oracle Trading Community Architecture User Guide.
Before you submit the new request for creation with the System Duplicates or Registry ID method, you can still remove parties from Multiple type requests. You do not delete the party from the TCA Registry, and the party is available to be included in other SDI batches, duplicate sets, or merge requests.
After you submit a new merge request, the Create Merge Batch process runs to create the merge request. Depending on the request type, the name of your new merge request is:
Multiple: The name of the master party.
Single: The name of the one party in the request.
For merge requests of type Multiple, the HZ: Merge Master Party Defaulting profile option determines the master party, which remains after the merge. You can change the master party when you map the merge request. See: Request Summary.
In the Merge Request Queue page, select the Registry ID method for the Create Request field.
Tip: You can also click Registry ID in the Create Merge Request bin from the Merge Request Queue.
You can specify the exact party or parties to include in a new merge request by Registry ID. Click Remove from Set to remove any party from the duplicate set.
The certification levels indicate the quality of records, and the meaning of each level is based on your organization's business needs. See: Assigning Certifications.
Related Topics
In the Merge Request Queue page, select the Smart Search method for the Create Request field.
Tip: From the Merge Request Queue page, you can also click Smart Search in the Create Merge Request bin.
Smart Search is a powerful search engine which finds parties that not only exactly match but are similar to your criteria. The available search criteria depends on the Data Quality Management (DQM) match rule that is assigned to the HZ: Match Rule for Identifying Duplicates profile option. See: Setting Up De-Duplication, Oracle Customer Data Librarian Implementation Guide. Run the search with at least one criterion.
You browse the search results and create a merge request either with parties that are in fact duplicates or with a single party that you want to cleanse.
The certification levels indicate the quality of records, and the meaning of each level is based on your organization's business needs. The status is also set as part of party maintenance. See: Maintaining Parties.
Related Topics
Use the Merge Request Queue or System Duplicate Identification Batches page to start the process of creating a merge request from a duplicate set in a System Duplicate Identification batch.
You can also use the party merge request Web service to create a party merge request for duplicate party IDs and/or a combination of the source system and the source system IDs. See: Web Services Implementation Overview, Oracle Trading Community Architecture Administration Guide.
Merge Request Queue: Select the System Duplicates method for the Create Request field. Search for and select the SDI batch to use.
System Duplicate Identification Batches: Review the batch that you want to use. See: Reviewing System Duplicate Identification Batches.
Tip: You can also click System Duplicates in the Create Merge Request bin, and select the batch to use.
Subset for Identifying Duplicates specifies filtering criteria used to create the SDI batch, if any. See: Creating System Duplicate Identification Batches.
Select at least one duplicate set from the batch.
Tip: Select multiple duplicate sets to create separate merge requests with each set, at the same time.
Alternatively, click Details to view and update a duplicate set, and optionally use that as the set to create a merge request. Duplicate sets already used to create merge requests are not available. You can update duplicate sets without creating merge requests with them.
View all parties in the duplicate set that are designated for merge. If the match rule used to create the SDI batch has an automatic merge threshold, parties with scores that exceed the threshold are marked as Automerge candidates.
Note: Automerge candidates would have been automatically merged as part of creating the SDI batch if the option was selected. See: Automerge in System Duplicate Identification.
Certification levels indicate the quality of records, and the meaning of each level is based on your organization's business needs. See: Assigning Certifications.
To update duplicate sets with multiple parties, you can:
Remove From Set: Remove any party from the duplicate set so that it is not part of the merge request.
Important: Any party that you remove from a set cannot be selected for a merge request again using this duplicate set.
Restore parties to include in the merge request.
Mark any removed party as not a duplicate of the parties that remain in the created merge request. The nonduplicate mapping ensures that the parties are not selected as duplicate candidates in the future. You define a date range for this mapping to be active, and can leave the end date blank for the mapping to always be active.
After you create the merge request, you can still update the end date for nonduplicate mappings. See: Administering Nonduplicate Mappings
Match Details: View details about how a specific duplicate was identified, based on the DQM match rule used to create the System Duplicate Identification batch. The party marked as the master is the input record that DQM used to identify the other duplicates in the set.
For each attribute that is a match between the master and the duplicate, you can see the attribute value from both parties, and the match score for that attribute. The total score is used to compare against the thresholds in the match rule used to create the SDI batch.
Match Threshold: The duplicate is selected for the duplicate set because the total match score between that party and the master party meets or exceeds the match threshold.
Automerge Threshold: The duplicate is an Automerge candidate if the total match score meets or exceeds the Automerge threshold.
Related Topics
System Duplicate Identification
The Request Review page provides a summary of the merge request, including the involved party or parties and any cumulative notes that were made during the request mapping process. The certification levels indicate the quality of records, and the meaning of each level is based on your organization's business needs. See: Assigning Certifications.
Use the party merge Web service to retrieve details about a party merge. See: Web Services Implementation Overview, Oracle Trading Community Architecture Administration Guide.
The operating unit parameter is displayed when the Customer Merge process is submitted as a concurrent program. If there is more than one operating unit, then the first five operating units are displayed and, if there are more than five operating units, then “…” is appended after the fifth operating unit.
Note: The notes are available only if the IMC: Display Notes for Merge Request Mapping profile option is set to Yes.
Related Topics
A new merge request contains information about the included parties to merge or the party to cleanse, but you can map the request to determine the results of the merge. For all aspects of the merge result, de-duplication provides defaults which you can review and modify as needed.
Set the profile option HZ: Enable DQM Merge Suggestion to 'No' to disable DQM suggestion. This will reduce time lag and improve performance during the during the Create Merge Batch process.
Note: You cannot update the mapping of requests that are already submitted for the Party Merge process.
As you go through the mapping process, you can:
Save your work at any time: When you navigate out of a mapping step, your work for that step is automatically saved. For substeps with an Apply or Save Note button, you must click that button to save your work.
Cancel your work at any time: When you click the Cancel button, you discard all mapping for the merge request, and mapping defaults are regenerated.
Record cumulative notes: You record comments for any step of the mapping process. These notes are cumulative and displayed in each subsequent step.
Note: The notes are available only if the IMC: Display Notes for Merge Request Mapping profile option is set to Yes.
For Single type requests, you map sets of duplicate addresses and relationships for the party and determine the master address or relationship that remains after the merge for each set.
For Multiple type merge requests, you map sets of duplicate addresses and relationships among the parties and determine the master address or relationship that remain for each set. The master address or relationship does not need to come from the master party.
Party profile attributes, such as First and Last Names, SIC Code, and CEO Name, describe the parties in the TCA Registry. Each party can have attribute values for any of the attributes, for example a number for the D-U-N-S Number attribute.
For Multiple type requests, you map each attribute to determine which value remains after the merge. For example, if the request contains five duplicates, each with a D-U-N-S Number, you specify the number that remains after the merge. That number does not need to come from the master party. Party profile attribute mapping does not apply to Single type requests.
Related Topics
Addresses, relationships, and party profile attributes can be mapped in any sequence, at different times, and by different data librarians. For Multiple type requests, the request summary should be reviewed first to confirm the master party, which affects defaults for the other mapping steps.
If the HZ: Data Sharing and Security Rules for Data Librarians profile option is set to Apply Rules at Merge Submission, then you can submit the request for merge only if the Data Sharing and Security (DSS) rules assigned to your user ID allow you to update all the parties in the merge request. See: Data Sharing and Security Overview, Oracle Trading Community Architecture Administration Guide.
Tip: After you submit a merge request, you can access details of the Party Merge process in the Merge Request Queue page. See: Reviewing Merge Requests.
Review and submit the request for the Party Merge process.
Review and submit the request for the Party Merge process.
The Request Summary page provides an overview of the merge request that you are mapping, of type Multiple or Single.
You can reject merge requests from the Request Summary page, no matter whom the request is assigned to. You cannot reject a merge request with a Completed phase.
Caution: A rejected merge request is no longer available for mapping and cannot be reactivated. To view rejected requests, search for requests with the Rejected phase. See: Merge Request Queue.
For Multiple type merge requests, you also see the included duplicates and the master party that is currently selected for the request. You can select a different master party or remove duplicates from the request. If the merge request contains both active and inactive parties, you can select only an active party as the master. For more information about master parties and removing duplicates, see: Creating Merge Requests.
Important: If you change the master party or remove any party, you must click Apply and Reprocess, return to the Merge Request Queue page, and wait for mapping defaults to regenerate before continuing with the mapping process.
The certification levels indicate the quality of records, and the meaning of each level is based on your organization's business needs. The status is also set as part of party maintenance. See: Maintaining Parties.
You can personalize this page and display the number of source systems, which is hidden by default. The number indicates how many source systems the party is mapped to. See: Source Systems, Oracle Customers Online User Guide.
Optionally enter any notes, if available, for the request summary step and click Save Note.
Related Topics
For merge requests of type Multiple, use the Profile Attributes page to determine the party profile attribute values that remain with the master party after the merge. Specify the category to display, and optionally specify the number of candidates to display per page. The default selected values depend on the HZ: Default Profile Attributes for Merge and HZ: Default Secondary Profile Attributes for Merge Mapping profile options, but you can choose values from another party, or candidate, in the duplicate set.
The type of attributes you map, Organization Profile attributes or Person Profile attributes, depends on the type of parties in the merge request. The attributes for each party type are also categorized, and you can specify the category to display in the Profile Attributes page.
Some attributes belong to attribute groups, and all attribute values in a group must come from the same party. Every group has a primary attribute, and the candidate that its value comes from also determines the values for the other attributes in the group.
For example, SIC Code is the primary attribute and SIC Code Type is the other attribute in the group. In the Profile Attributes page, only SIC Code is enabled for you to select an attribute value. If you specify that the value for SIC Code comes from Candidate 2, the value for SIC Code Type would also come from Candidate 2.
Note: Any attribute with disabled selection is a nonprimary attribute in a group, with the first enabled attribute above it as the primary attribute.
Optionally enter any notes, if available, for the profile attributes mapping step and click Save Note.
Related Topics
Use the Addresses page to map addresses either within a party for Single type merge requests or among the parties in Multiple type requests. You determine which addresses are duplicates by creating duplicate address sets and specify the master address that remains after the other addresses merge into it. When you submit the request for the Party Merge process, the duplicate address sets would be merged based on your mapping, with the resulting master addresses.
Every address has a grouping status:
Mandatory: Addresses in a Mandatory duplicate set must merge together because they have the same location ID.
Optional: Addresses in an Optional duplicate set can be removed from the group and included in another set.
Not Grouped: Addresses are not currently mapped to any duplicate set. These addresses will exist after the merge as an address either of the one party for Single type merge requests or of the master party for Multiple type requests.
If the HZ: Show Address Mapping Suggestions profile option is set to Yes, all suggested address mapping is shown by default. If not, the Addresses page displays addresses without any groupings except for the Mandatory duplicate sets. You can use the search to narrow down the list of addresses and subsequently find more addresses to map, or select Apply Suggested Groupings for the Change Grouping option.
Note: If you already have duplicate sets of addresses and run a search for more addresses, any search results would be added without disrupting the existing groupings.
At any point of the address mapping process, you can:
Apply the mapping suggestions and override whatever groupings you currently have, if any.
Clear all groupings, including suggested defaults, except for Mandatory duplicate sets.
The Addresses table shows duplicate address sets in a hierarchical manner. For each set, the master address is the parent and the other duplicates are its children. Any address that does not belong to a hierarchy is not included in any duplicate address set and is automatically transferred to the resulting party after the merge.
Important: If every 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.
The validation adapter and level are displayed if the address has been validated. See: Address Validation, Oracle Trading Community Architecture User Guide.
You can personalize this page and display the number of source systems, which is hidden by default. The number indicates how many source systems the address is mapped to. See: Source Systems, Oracle Customers Online User Guide.
To map addressees, you can:
Update Set:
Select another master address if the current master is not Mandatory.
Remove Optional or Not Grouped addresses from the set.
If you remove all addresses other than the master, you ungroup the entire set and all addresses in the set would have the Not Grouped grouping.
Merge: Select at least two addresses to create a duplicate address set to merge. If you select a master address from any duplicate address set, the other addresses in that set are also included.
Note: Addresses from a purchased source such as D&B can only be merged into addresses of the same source.
For Mandatory duplicate sets:
You must select the master to merge the set with other addresses because the Mandatory addresses must merge together.
You can select only one Mandatory master to include in the new duplicate set.
You must keep the Mandatory master as the master in the new set.
Select the master address if applicable and optionally remove any Optional or Not Grouped address from the set. You do not delete the address from the TCA Registry, and the removed address is available to be included in other duplicate address sets.
Optionally enter any notes, if available, for the address mapping step and click Save Note.
Related Topics
For tax purposes, you can only merge addresses within the same tax jurisdiction:
If the addresses are set up for tax validation in Geography Hierarchy then the address elements with a tax validation usage must match. See: Managing Validations, Oracle Trading Community Architecture Administration Guide.
For example, Address 1 is created in a country that is set up with City, County, and State selected for tax validation. Address 2 is created in the same country. To merge these two addresses, the city, county, and state for both addresses must be exactly the same, as validated against geographies set up in Geography Hierarchy.
If the addresses are not set up for tax validation in Geography Hierarchy, then you can merge the addresses as long as the country is the same.
If you have both types of addresses, with and without addresses set up for tax validation in Geography Hierarchy, then you cannot merge the addresses.
Use the Relationships page to map relationships either within a party for Single type merge requests or among the parties in Multiple type requests. You determine which relationships are duplicates by creating duplicate relationship sets and specify the master relationship that remains after the other relationships merge into it. When you submit the request for the Party Merge process, the duplicate relationship sets would be merged based on your mapping, with the resulting master relationships.
If the HZ: Create Suggested Merges from Party Merge profile option is set to Yes, then the system automatically creates suggested merge requests with parties related to the parties that are merged. For example, Joe Smith and Joseph Smith are merged, along with these selected relationships:
Joe Smith (ID: 123) as employee of Oracle (ID: 100)
Joseph Smith (ID: 125) as employee of Oracle (ID: 101)
The system would then create a suggested merge request with Oracle (ID: 100) and Oracle (ID: 101).
For each relationship role, the Relationships table shows the number of original relationships in the merge request and the number of relationships that will exist after the actual merge. You can resolve duplicates within each relationship role.
If the HZ: Show Relationship Mapping Suggestions profile option is set to Yes, all suggested relationship mapping for the relationship role is shown by default in the Resolve Duplicates page. If not, the page displays all relationships in the role without any groupings except for the Mandatory duplicate sets. You can use the search to narrow down the list of relationships and subsequently find more relationships to map.
At any point of the relationship mapping process, you can:
Apply the mapping suggestions and override whatever groupings you currently have, if any.
Clear all groupings, including suggested defaults, except for Mandatory duplicate sets.
Select the relationship role that you want to map and click Resolve Duplicates.
The table in the Resolve Duplicates page shows duplicate relationship sets in a hierarchical manner. For each set, the master relationship is the parent and the other duplicates are its children. Any relationship that does not belong to a hierarchy is not included in any duplicate relationship set.
You can personalize this page and display the number of source systems, which is hidden by default. The number indicates how many source systems the related party is mapped to. See: Source Systems, Oracle Customers Online User Guide.
If no suggested duplicate sets are defaulted, optionally search for relationships to limit the list. If you are resolving duplicate contacts, you can search to see any or all relationship roles in the Party Contacts relationship group. You can merge relationships with different roles within this relationship group. See: Introduction to Contacts, Oracle Customers Online User Guide.
Note: If you already have duplicate sets of relationships and run a search for more relationships, any search results would be added without disrupting the existing groupings.
Every relationship has a grouping status:
Mandatory: Relationships in a Mandatory duplicate set must merge together because they involve the same parties.
Optional: Relationships in an Optional duplicate set can be removed from the group and included in another set.
Not Grouped: Relationships are not currently mapped to any duplicate set. These relationships will exist after the merge as a relationship either of the one party for Single type merge requests or of the master party for Multiple type requests.
To map relationships, you can:
Update Set:
Select another master relationship if the current master is not Mandatory.
Remove Optional or Not Grouped relationships from the set.
If you remove all relationships other than the master, you ungroup the entire set and all relationships in the set would have the Not Grouped grouping.
Merge: Select at least two relationships to create a duplicate relationship set to merge. If you select a master relationship from any duplicate relationship set, the other relationships in that set are also included.
Note: Relationships from a purchased source such as D&B can only be merged into relationships of the same source.
For Mandatory duplicate sets:
You must select the master to merge the set with other relationships because the Mandatory relationships must merge together.
You can select only one Mandatory master to include in the new duplicate set.
You must keep the Mandatory master as the master in the new set.
Select the master relationship that remains after the merge, if applicable. If the duplicate set has both active and inactive relationships, you can select only an active relationship as the master.
Optionally remove any Optional or Not Grouped relationship from the set. You do not delete the relationship from the TCA Registry, and the removed relationship is available to be included in other duplicate relationship sets.
Return to the Relationships page. Optionally enter any notes, if available, for the relationship mapping step and click Save Note.
Related Topics
Relationships Overview, Oracle Trading Community Architecture User Guide