12Manage Hierarchy Information

This chapter contains the following:

Manage Hierarchy Information

A hierarchy captures the hierarchical relationships a party, such as a customer, has with other parties. This capability is frequently used to capture your customer's corporate hierarchy and to show how headquarters, branches, subsidiaries, and so on are related. It can be used to capture the hierarchy of any entity, such as a prospect, supplier, or partner, and not just of customers.

Organizing customer data as hierarchies offers the following advantages:

  • Enables you to understand and get a better view of your customer's organization.

  • Enables you to better analyze customer-related data.

  • Application modules using the hierarchy can use hierarchies to roll up transactions, and apply business rules.

You can leverage the hierarchy of your customers in many business processes. For example, the territory management functionality uses customer hierarchy information to define account dimensions. Financial applications use customer hierarchy information to process payments from one customer and apply them to another customer in the same hierarchy. The revenue roll-up report uses customer hierarchy information to roll up revenue numbers from opportunities across all customers in a hierarchy.

Oracle Cloud Applications have a common framework to manage various hierarchies called the Tree framework. The party hierarchy uses this common framework.

You can create or modify hierarchies, using the Manage Hierarchies UI. You can access the Manage Hierarchies UI as follows:

Navigator > Customer Data Management > Hierarchies

Create Hierarchies

To create hierarchies:

  1. Navigate to the Manage Hierarchies UI.

  2. Click the Create option or button on the Actions menu. The Create Hierarchy: Enter Basic Information page appears.

  3. Complete the mandatory fields. You can use the following sample data:

    • Hierarchy Name: Green Corp.

    • Hierarchy Type: Customer Hierarchy

    • Hierarchy Status: Active

    • Effective Start Date: Enter appropriate date and time.

  4. Click Next. The Create Hierarchy: Add Parties page appears.

  5. Click the Add option or button on the Actions menu. The Add Tree Node pop-up appears.

  6. Select one of the following as the Tree Node Type:

    • Specific value

    • Values from referenced hierarchy

  7. Click Next. The Create Hierarchy: Review page appears. Verify the hierarchy information and click Back to make any modifications.

  8. Click Finish to complete creating the new hierarchy.

Edit Hierarchies

To edit hierarchies:

  1. Navigate to the Manage Hierarchies UI.

  2. Search and select the hierarchy you want to edit.

  3. On the Actions menu, select one of the following options:

    • Edit Hierarchy Version: Lets you make the changes to the hierarchy available immediately.

    • Create New Version: Lets you make the changes to the hierarchy available at a later point in time.

  4. Click Add or Remove option or button on the Actions menu as required to update the tree nodes.

  5. Click Save and Close to complete editing the hierarchy.

Hierarchy validation rules ensure that newly created or updated hierarchies are properly structured. These rules are run each time you create or modify hierarchies.

All hierarchy types, including the predefined hierarchy types: Party Hierarchy, Dun and Bradstreet Hierarchy, and Customer Hierarchy, enforce the following validation rules in active versions of customer hierarchies.

  • A hierarchy can't contain a merged party.

  • A hierarchy can contain parties with only certain party usages such as sales account, sales prospect, (internal) legal entity, external legal entity, and buying customer. A buying customer is also considered as an external legal entity.

  • If a party is an external legal entity, its parent can only be an external legal entity.

  • If a party is an (internal) legal entity, its parent can only be a (internal) legal entity.

  • If a party isn't an external legal entity or (internal) legal entity, its parent can only be an eligible customer. For example, a sales prospect, sales account, external legal entity, (internal) legal entity or a buying customer.

  • A party can be present in only one active tree across all trees in the customer hierarchy.

  • If there are sales accounts organized in a customer hierarchy, all nodes in that hierarchy must be sales accounts. Sales accounts that appear within larger sales accounts are called in-between sales account nodes.

  • A Named Sales Account can only have named sales accounts as ancestors.

Note: 'Named' is a sales account attribute stored in the Sales Account Profile entity.

These validation rules are enforced in the Hierarchy UI as much as possible while users select nodes to add to the hierarchy. Also, a background audit job implements these rules to ensure that all hierarchies that don't pass the validation are marked inactive.

While creating hierarchies, you have to decide whether you want to create a new hierarchy or use a new version of an existing hierarchy.

When to Create a New Hierarchy

You can create a new hierarchy when any of the following is true:

  • You have a new customer, and a new hierarchy is required to represent the corporate structure of the new customer.

  • Your existing customer has changed the structure of its organization radically. It is quicker and more efficient to create a new version rather than edit the existing one.

When to Create a New Hierarchy Version

You can create a new version of a hierarchy when any of the following is true:

  • You have minor changes to make to an existing version of a hierarchy, such as adding a new customer, or removing or repositioning an existing customer in the hierarchy.

  • You must make extensive changes to an active hierarchy, but want to render the changes active only when they're all incorporated into the hierarchy. Then, create a new version of the hierarchy and set it to become active after a reasonable window period. You can make all the required changes and have the new version ready for activation by the scheduled date.

While editing a hierarchy, you must decide whether you want to edit the existing version of the hierarchy or create a new one. The changes you make to the existing version become active immediately, but the new versions of a hierarchy become active only on the date on which the hierarchy becomes active.

Edit Active Hierarchies

When you edit the existing version of a hierarchy, the changes are saved instantly and are available to users even as you edit them. However, you can't cancel any changes while editing existing hierarchy versions.

Two ways to deal with the changes while editing active hierarchies are:

  • You can render hierarchies inactive before you edit them. Once you have made your changes, you can change their status to active again.

    Note: The hierarchy isn't available to users while it's inactive.
  • You can create a new hierarchy version and set it to be active the next day. Thus, while the existing version is active, you can make your changes to the new version and activate it the next day.

Edit Merged Hierarchies

The merge process consolidates the duplicate parties and updates the hierarchies to which these parties belong. If the updates to the hierarchies done by the merge process aren't as expected, then edit the updated hierarchies in the Manage Hierarchy Types task.

FAQs for Manage Hierarchy Information

You can create a new hierarchy type using the Manage Tree Structures task. Select Trading Community Model as the application, an existing data source or new custom data source, and any labeling scheme you want. The next step is to, enter the other required details, such as the appropriate usage of the new hierarchy type. Finally, add the newly created hierarchy type under the Party Hierarchy Type lookup to include the new hierarchy type in the lookups for hierarchy types.

Yes. You must ensure that the date on which the new version is active doesn't overlap with the date of any existing active version of the same hierarchy.

How can I respond to a merge completion notification if I don't have the privileges to edit hierarchies?

If you don't have the privileges to edit hierarchies, reassign the merge completion notification to a user with the appropriate privileges. So, if you're a sales person you can reassign a merge completion notification to the Sales Administrator.

When you create a hierarchy type, you must also update the list of hierarchy lookups. You can't use the new hierarchy type, unless you have updated the hierarchy lookup list.

You can update the list of hierarchy types using the Manage Hierarchy Lookups task. Select Party Hierarchy Type (PARTY_HIERARCHY_TYPE) lookup type to edit. Add the new hierarchy type to the Party Hierarchy Type lookup type. After updating the list of hierarchy type lookups and saving your changes, you can view the new hierarchy type under the list of hierarchy types.

Why is an active hierarchy version that has been saved recently sometimes set automatically to inactive?

The newly edited hierarchy is saved as an auto-commit process, even before you save and close it. The application triggers the tree flattening service and the audit job, when you save and close your changes. It doesn't wait for the job to complete, and notifies you to revisit the version after the audit job is complete, to check the version status of the hierarchy.

If the audit job identifies any errors at the time of hierarchy validation, then the status of the hierarchy is set to Inactive. However, the application doesn't notify you of this. You must revisit the hierarchy management interface and rectify issues in the previously saved version, if the status is inactive.