Browser version scriptSkip Headers

Oracle® Fusion Applications Customer Data Management Implementation Guide
11g Release 7 (11.1.7)
Part Number E20433-07
Go to Documentation Home
Home
Go to contents  page
Contents
Book<br />List
Book
List
Go to Feedback page
Contact
Us

Go to previous page
Previous
Go to previous page
Next
PDF

30 Define Customer Hub Configuration

This chapter contains the following:

Run Request Dispatch Job

Manage Customer Hub Profile Options

Manage Survivorship Rules

Manage Party Center Trees

Manage Customer Data Hub Notes

Manage Agreement Rules

Enter Merge Request

Run Request Dispatch Job

Configuring the Data Quality Management Request Dispatcher: Explained

Use the request dispatcher to process cleansing and duplicate identification batches, and duplicate resolution requests. The Run Request Dispatcher process can be scheduled to run as one time process or at a repeat schedule. This task can also be used to monitor the cleansing and duplicate identification batches and duplicate resolution requests.

You can configure the request dispatcher to run in the following two modes:

Running the Dispatcher in the Basic Mode

Run the dispatcher in this mode to submit the request dispatcher job for immediate processing of the duplicate identification batches, cleansing batches, or resolution requests

Running the Dispatcher In the Advanced Mode

This mode lets you schedule the request dispatcher job to be run either immediately or at a specified intervals, such as, every 15 minutes to process duplicate identification batches, cleansing batches, or resolution requests.

Manage Customer Hub Profile Options

Customer Hub Profile Options: Explained

The Customer Hub profile options provide data access and processing options related to data governance, duplicate identification processes, data cleansing processes, and duplicate resolution requests.

Note

The Hub profile option values can be set only at the site level using the predefined profile option definitions.

Navigate to Manage Customer Hub Profile Options page using the Setup and Maintenance option on the Tools menu to configure the following profile options:

Address Cleansing Configuration

Specify the data quality address cleansing configuration used by the data cleansing process.

Default value: BT_LOC_CLEANSE

Data Cleansing Process Batch Size

Control the transaction batch size for the data cleansing process. Set this value based on available system resources. Set this value based on available system resources.

Default value: 100

Resolution Request Type Default

Specify the default request type value for duplicate resolution requests.

Default value: Merge

Duplicate Identification Organization Configuration

Specify the data quality organization match configuration used by the duplicate identification process.

Default value: BT_ORG_DUP_BASIC

Duplicate Identification Person Configuration

Specify the data quality person match configuration used by the duplicate identification process.

Default value: BT_PERSON_DUP_BASIC

Duplicate Identification Process Batch Size

Control the transaction batch size for the duplicate identification process. The value is used to chunk records in the batch and process each chunk in a loop as a separate transaction.

Default value: 100

User Merge Requests

Specify the processing of merge requests, such as, process without approval and approval needed. The different values of this profile option are explained below.

Note

The default value of the User Merge Requests profile option , Unspecified or NULL, will enable the user to submit the merge request to be processed immediately without the need for Data Steward approval only if the user has the Submit Trading Community Merge Request privilege in addition to the Enter Trading Community Merge Request privilege.

Sales accounts merges initiated from the Customer Center, or the Enter Merge Request setup task, or the Automerge web service, DuplicateResolutionRequestService, cannot happen immediately without Data Steward processing. Note that to allow Data Steward processing the User Merge Requests Profile Option should be set to Process Subject to Approval , otherwise the merge requests will error.

Manage Survivorship Rules

Survivorship Rules: Explained

Survivorship rules are a collection of business rules defined for selecting master record and attributes to be retained during merge or link, or update operations.

Survivorship rules facilitate intelligent creation of the best version record from multiple source systems, based on business rules. You can configure survivorship rules to determine how conflicts should be resolved while merging or updating duplicate records from different source systems to create the best version record. You can specify criteria to determine the master (or the surviving) party record for duplicate resolution. The survivorship rules criteria determine the attributes of the best version record that should be retained from a particular source system. The rules use the priority assigned to different source systems, as well as other criteria to determine which values to retain for certain attributes.

Managing Surviviorship Rules

Use the UI available from the Manage Survivorship Rules Setup and Maintenance task to view, create, edit, and delete survivorship rules.

The survivorship functionality is disabled by default. To enable survivorship, set the ZCH_ENABLE_SURVIVORSHIP profile option to Yes using the Manage Customer Hub Profile Options Setup and Maintenance task.

Importing and Exporting Surviviorship Rules

Use the Import Survivorship Rules Dictionary web service to import the survivorship rules dictionary XML file created or stored elsewhere into the Oracle Fusion Applications environment. Use the Export Survivorship Rules Dictionary web service to export survivorship rules dictionary from the Oracle Fusion Applications environment.

Defining Survivorship Rules: Worked Example

This example demonstrates how to create a survivorship rule. Survivorship rules enable intelligent creation of the best version record, especially from multiple source systems, by specifying criteria for selecting the record to be retained during a merge operation.

Use the UI available from the Manage Survivorship Rules Setup and Maintenance task to create a survivorship rule and to specify the criteria for selecting the master record.

Create Survivorship Rule

  1. Navigate to the Manage Survivorship Rules page.
  2. Click Create.
  3. Enter the following sample information.

    Field

    Value

    Rule Name

    PickPersonMasterRule

    Description

    Select the master person record based on original source system of the record.

    Rule Type

    Set_Master

    Object Type

    Person

    Note

    You can create a survivorship rule for the following two types of party records: person and organization.

  4. Click Apply. You are taken to the Define Survivorship Rules: Select Master Record page.

Specify Criteria for Selecting the Master Record

  1. On the Define Survivorship Rules: Select Master Record page, enter the following IF/THEN rules condition.

    Rule Condition

    Value

    IF Condition

    IF PersonParty is a TCHFactTypeDictionary.PersonPartyVO
    and  there is a case where {
       OrigSourceSystem != null and
       OrigSourceSystem.OwnerTableId == PersonParty.PartyId and 
    OrigSourceSystem.OrigSystem == "GSI"
    }
    

     

    THEN Condition

    THEN
       Assert new Result (name:"masterId", value:"PersonParty.PartyId)

     

    Note

    If survivorship rules conflict with a real life situation, an error message is displayed and the merge fails. In the context of this example, the survivorship rule in use states that if a person party record is from the source system GSI, it should be set as the master record. Consequently, if at runtime a merge request has more than one person record from GSI, the survivorship engine returns multiple master records, which is incorrect. In such a situation, an error message is displayed stating that the merge request failed because conflicting survivorship rules are defined and that the administrator should modify the rules to ensure that only one master record is returned.

  2. Verify that the effective date of the rule is set to the rule's creation date and, if required, modify it as appropriate.
  3. Select Medium as the priority for the rule.
  4. Select the Rules Active option.
  5. Click Save or Save and Close.
  6. Click Submit.

FAQs for Manage Survivorship Rules

What's the difference between survivorship rules and merge agreement rules?

Survivorship rules are a collection of business rules defined for the creation of the best version record intelligently, especially from multiple source systems, by specifying criteria for selecting record and attributes to be retained during merge or link, or update operations.

A merge agreement rule is a collection of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Merge requests that violate these rules are either rejected or end in error.

Manage Party Center Trees

Party Center: Explained

The party center functionality enables a comprehensive management of party information. A party is a physical entity, such as a person, organization or group, that the deploying company has an interest in tracking. The party center functionality lets you bring a particular party into context, fetch data from various systems about the party in context, and review and edit the data in one location.

The party center enables you to do the following:

Party Center Tree

You can select a party from the organizations, person, or groups lists to bring it into context. Once a party is in context, you can fetch, review, and edit its data in the party center. The party entities are displayed as nodes in the party center tree. A party center tree comprises nodes that let you fetch data related to the party in context from various systems, and review and edit the data displayed in each node.

The party center nodes display information, such as profile, profile history, party usage assignments, relationships, classifications, source system references, and linked trading community members, about the party in context.

Party Center Trees: Explained

A party center tree comprises nodes that let you fetch data about the party in context from various systems, and review and edit the data displayed in each node. You can also customize a party center tree by showing or hiding its various nodes as required, reviewing and editing the node names as appropriate, and determining the need for entering additional parameter values to gain access to a node.

There are three types of party center trees:

Each tree displays slightly different nodes, and the information that you can view and edit on each node depends upon your security privileges.

A party center tree may include the following nodes:

Note

The profile history information for a group party type is displayed in the Profile node.

Some of them are explained below:

Profile

This node lets you review and edit party profile information such as name, party usage, additional names, additional identifiers, addresses, and contact points.

Profile History

This node lets you view the history of changes to profile records of the party, person or organization, in context in the party center.

Usage Assignments

This node launches a task flow that gives visibility into what party usages have been currently assigned to the party. Party usages that allow manual create, manual update, and unconditional assignment are maintainable through this user interface.

Relationships

This node lets you view, create, edit, and delete all relationships for the party in context in the Party Center. The node also displays the contact details of a relationship.

Classifications

This node lets you view, create, edit, and delete classifications for the party in context in the Party Center. The displays the primary classification first in the list of classifications.

Source System References

This node lets you view, create, edit, and delete all source system references contributing to the master organization party record in context in the Party Center.

Linked Parties

This node lets you manage the parties linked to the party in context.

Managing Party Center Trees: Explained

Use the Setup and Maintenance option on the Tools menu to navigate to the Define Customer Hub Configuration tasklist. Go to the Manage Party Center Tree task to manage a party center tree. Alternatively, use the Actions menu options in the regional area of the Oracle Fusion Trading Community Hub to personalize a party center tree.

Specify the following attributes for each node in the party center tree:

Name

Set this attribute to specify the name of the node that you want to display in the party center tree.

Visible

Set this attribute to specify the display status, hidden or visible, of a node in the party center tree.

Parameter

Specify the additional parameter values required to gain access to a node.

Manage Customer Data Hub Notes

Defining Notes: Points to Consider

A note is a record attached to a business object that is used to capture nonstandard information received while conducting business. When setting up notes for your application, you should consider the following points:

Note Types

Note types are assigned to notes at creation to categorize them for future reference. During setup you can add new note types, and you can restrict them by business object type through the process of note type mapping.

Note Type Mappings

After note types are added, you must map them to the business objects applicable to your product area. Select a business object other than Default Note Types. You will see the note types only applicable to that object. If the list is empty, note type mapping doesn't exist for that object, and default note types will be used. Select Default Note Types to view the default note types in the system. Modifying default note types will affect all business objects without a note type mapping. For example, you have decided to add a new note type of Analysis for your product area of Sales-Opportunity Management. Use the note type mapping functionality to map Analysis to the Opportunity business object. This will result in the Analysis note type being an available option when you are creating or editing a note for an opportunity. When deciding which note types to map to the business objects in your area, consider the same issues you considered when deciding to add new note types. Decide how you would like users to be able to search for, filter, and report on those notes.

Note

Extensibility features are available on the Note object. For more information refer to the article Extending CRM Applications: how it works.

Manage Agreement Rules

Agreement Rules: Explained

An agreement rule is a collection of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Merge requests that violate these rules are either rejected or end in error.

Agreement rules let you check a merge request for any veto conditions that can prevent a merge from occurring. These rules save resources and time by obviating the need to review merge request to prevent undesired merge from being processed. Besides, agreement rules prompt you to consider alternative duplicate resolution mechanism such as linking.

Agreement rule can be of the following two types:

Predefined Agreement Rules

These are agreement rules that are predefined in the application. You can only view the predefined agreement rules.

The following table describes the predefined agreement rules for the Oracle Fusion Trading Community Hub. Merge requests that violate these rules are automatically rejected.


Name

Description

HR_APPLICANT_VETO

Prevents a person party with an active party usage of HR_APPLICANT from merging with another party.

HR_EMPLOYEE_VETO

Prevents a person party with an active party usage of HR_EMPLOYEE from merging with another party.

HR_CONTINGENT_WORKER_VETO

Prevents a person party with an active party usage of HR_CONTINGENT_WORKER from merging with another party.

HR_PARTY_SITE_VETO

Prevents a party site with active original system reference from Fusion HCM system from merging with another party site.

RESOURCE_PERSON_VETO

Prevents a person party with an active party usage of RESOURCE from merging with another party.

BANK VETO

Prevents an organization party with an active party usage of BANK from merging with another party.

CLEARINGHOUSE_VETO

Prevents an organization party with an active party usage of CLEARINGHOUSE from merging with another party.

BANK_BRANCH_VETO

Prevents an organization party with an active party usage of BANK_BRANCH from merging with another party.

BRANCH_CLEARINGHOUSE_VETO

Prevents an organization party with an active party usage of CLEARINGHOUSE_BRANCH from merging with another party.

LEGAL_EXTLEGAL_PARTYUSGRULE_VETO

Prevents an organization party with active party usage of LEGAL_ENTITY from merging with another organization party with active party usage of EXTERNAL_LEGAL_ENTITY.

IC_PARTICIPANT_PERSON_VETO

Prevents a person party with an active party usage of INCENTIVE_COMP_PARTICIPANT from merging with another party.

IC_PARTICIPANT_ORG_VETO

Prevents an organization party with an active party usage of INCENTIVE_COMP_PARTICIPANT from merging with another party.

PARTNER_VETO

Prevents an organization party with an active party usage of PARTNER from merging with another party.

INACTIVE_PARTNER_VETO

Prevents an organization party with an active party usage of INACTIVE_PARTNER from merging with another party.

CUST_CONTACT_DIFF_RESOURCE_ORG_VETO

Prevents two partner owned contacts belonging to different resource organizations from being merged.

CUST_CONTACT_INTERNAL_PARTNER_VETO

Prevents a partner owned contact that does not belong to a resource organization from merging with another partner owned contact that belongs to a resource organization.

CUST_CONTACT_INTERNAL_PARTNER_ORG_VETO

Prevents a contact owned by an internal user from merging with a contact owned by a partner user.

CARD_ISSUER_VETO

Prevents an organization party with an active party usage of CREDIT_CARD_PROVIDER from merging with another party.

LEGAL_ENTITY_VETO

Prevents an organization party with an active party usage of LEGAL_ENTITY from merging with another party.

ESTABLISHMENT_VETO

Prevents an organization party with an active party usage of ESTABLISHMENT from merging with another party.

HIERARCHY_CYCLE_PREVENTATION_VETO

Prevents merge from happening when the master party record is at a level lower than the nonmaster party record within the same active tree version.

NAMEDACCOUNT_UNNAMEDACCOUNT_VETO:

Prevents merge from happening when the master party record is not a named account whereas the nonmaster party record is a named account and these are in active hierarchies.

User-defined Agreement Rules

These are additional agreement rules that you can define to determine whether a merge request should be vetoed by the application. You can create, view, update, and delete user-defined agreement rules.

Defining Agreement Rules: Worked Example

This example demonstrates how to create user-defined agreement rules that you can use to prevent a merge request from being processed.

Agreement rules are collections of patterns and conditions that are defined to determine whether a merge request should be vetoed by the application or not. Perform the following tasks to define agreement rules:

For more information on agreement rules, see Oracle Fusion Middleware User's Guide for Oracle Business Rules on Oracle Technology Network at http://www.oracle.com/technetwork.

Select Agreement Rules Dictionary

An agreement rules dictionary is a collection of predefined terms and attributes for which agreement rules can be defined. Use the following steps to select the relevant agreement rules dictionary:

  1. Navigate to Manage Agreement Rules: Define Dictionary page as follows: Set Up Tasks - Manage Agreement Rules - Define Dictionary
  2. Select the relevant agreement rules dictionary from the Select Dictionary drop down list and click Load to load its predefined terms.
  3. Select Visible for the terms and term attributes that you want to be available when defining rules later on in the flow.
  4. Click Save or Save and Close.

Add a New Agreement Rule

  1. Navigate to Manage Agreement Rules: Define Rules page.
  2. Add a new rule and provide a rule name.
  3. Click on Define Pattern.
  4. In the Justification Reason, enter the reason for creating the agreement rule.
  5. In the Justification Area enter the scope of the agreement rule.
  6. Add a new pattern and complete the fields, using the sample information provided in this table. Use the default values except where indicated. Note that the relation is always AND between patterns and cannot be edited.

    Pattern

    Dictionary Term

    Term Alias

    Relation

    for each case where

    PersonPartyVO

    Person

    AND

    for each case where

    OrganizationPartyVO

    NonmasterParty

    AND

    there is a case where

    PartyUsageAssignmentVO

    PartyUsageAssignment

    AND


  7. To define term conditions for each pattern defined, select the pattern in the Patterns table and navigate to the Conditions table underneath.
  8. Add a new condition and complete the fields using the sample information provided in this table. Use the default values except where indicated.

    Term Attribute

    Operator

    Value

    Relation

    Person.PartyNumber - missing PartyNumber

    is not

    1234

    AND

    NonmasterParty.MergeType

    =

    Nonmaster

    AND

    UsageAssignment.PartyUsageCode

    =

    HR_APPLICANT

    AND


  9. Click Save or Save and Close.
  10. Click Submit.

Enter Merge Request

Manual Merge: Explained

Manual merge involves selection of duplicate records directly by the user of a merge functionality consuming application. Examples of such applications include Oracle Fusion Sales and Receivables.

Manual merge is unlike the system merge in which duplicates are selected automatically using a matching configuration. Another difference is that while only two records can be merged as part of manual merge multiple records can be merged as part of system merge.

Manually merge the two records that you think are duplicates as in one of the following two ways:

Immediate Manual Merge

Involves specification of one of the two duplicate records as the master record for an immediate merge. In an immediate merge, while you can specify some of the attributes from individual records to be mapped to the master record, other attributes are automatically transferred.

Deferred Manual Merge

Involves submission of merge request to be reviewed and processed later by a data steward.

Merging Records Manually: Worked Example

This example demonstrates how the business user of a merge functionality consuming application, such as Oracle Fusion Sales or Receivables, can merge manually two duplicate records. This example illustrates only the generic process for merging records manually from the Enter Merge Request task in the Define Customer Hub Configuration central setup task list. Alternatively, as the business user of a merge functionality consuming application, you can merge two records that you think are duplicate from your own application UI pages that you use to manage customer information.

Merging records manually involves the following tasks:

Identifying Duplicate Records

  1. Navigate to the Search and Select: Record to Merge page as follows: Set Up Tasks Enter Merge Request Search and Select: Record to Merge.
  2. To search and select the record to be merged, complete the search criteria using the sample information provided in the given table. Use the default values except where indicated.

    Name

    Registry ID (Optional)

    John

    15918


  3. Click Search.
  4. From the search results, select the first record to be merged.
  5. Select Merge Record from the Actions menu

Selecting the Master and Duplicate Records

Note

The function privilege Enter Trading Community Merge Request controls whether the Merge secondary window appears at all.

  1. In the Merge secondary window, specify the selected record either as master or duplicate.
  2. To select the second (master or duplicate) record to be merged, in the Party Picker enter the sample information provided in the given table. Use the default values except where indicated.

    Name

    Registry ID (Optional)

    John

    10854


  3. Click Search.

Submitting the Merge

  1. On the Map Profile Attributes page, specify the attributes from each of the two records, such as name and gender, that should be mapped to the master record. Any child entities, such as addresses, accounts, account addresses, relationships, and contact points, are transferred to the master record.
  2. Click Submit. The merge happens immediately if the data governance profile: User merge requests is set to Allow Processing Without Approval. If the profile is set to Process Subject to Approval, the merge is reviewed and processed later by a data steward.