Introduction

In continuation to my previous blog on Best Practices to model parties in Oracle Fusion Cloud, I will discuss common use cases, design considerations, and options around managing hierarchies (customer, supplier, partner) within Oracle Application Cloud.

My objective for this blog, is to discuss the hierarchy capabilities within Oracle Fusion application cloud that supports functional use of hierarchies across Customer Experience, Procurement and Financials cloud applications.

The details provided here are guidelines that can be leveraged as guidance during your customer / supplier / partner hierarchy design for your Oracle Fusion application implementation.

Hierarchies

Definition

A hierarchy is typically a tree like structure where branches and nodes are arranged according to the requirements. In a tree like structural formation, there will be one and only one parent for every child node or branch. The Root Node does not have parent and it will be the highest node in the hierarchy. A Parent node will contain other nodes. The bottom, or lower-most node does not have children and is called a Leaf Node. For any given node in a hierarchy, these nodes above it may be referred to as Ancestor nodes, and those below it may be referred to as Descendant nodes.

Customer/Prospect/Supplier/Partner hierarchy will contain the hierarchical relationship of an Organization/Business records. Account hierarchy in Customer Experience model typically represents Customer hierarchy. Account hierarchy in Financial applications functionalities represents General Ledgers, Chart of Accounts and Financial Accounts. Hierarchy is also used to represent products, product catalogs, reference data such as geographical data (Country, State, Postal Code combinations), List of Values and so on.

Common Functional use cases for hierarchies

While there are numerous potential use cases, and business requirements that use hierarchy and relationships to help in business planning and operations, the key use cases are given below.

This article focuses around design options of Customer/Prospect/Supplier/Partner hierarchy capabilities within Oracle Fusion application cloud.

A party hierarchy provides the relationships between parties. For example, organizing a corporate hierarchy to link how headquarters, branches, subsidiaries are related for an Organization. Typically, hierarchies are called Trees.

Advantages

• Enables you to get a better view of an organization

• Enables you to better analyze – related data

• Roll up transactions, and apply business rules

Hierarchies in Fusion Application

In Fusion Applications, the Hierarchy Tree is a distinct object, rather than a recursive join between nodes as one may see modeled in some other applications.  This architecture allows multiple distinct hierarchies to exist simultaneously and allows a given node to participate in multiple hierarchical structures if required.  Fusion provides a number of standard hierarchy types intended to satisfy the distinctive hierarchical requirements for different types of entities, such as Customers, Prospects, Suppliers, or Partners.

Customer Hierarchies: Parent / Child Relationship

Managing hierarchies within Oracle applications cloud is a standard and ready to use functionality. No additional configurations are required.

Oracle Engagement Cloud provides the ability to manage your customers (accounts) hierarchically. In a parent/child relationship group, every customer (account) can be associated to one and only one parent customer/Prospect (account). You may have any number of levels in your customer/Prospect (account) hierarchy.

A customer hierarchy captures the hierarchical relationships that a customer has with other customers, and consists of hierarchy members. A customer hierarchy can be used to process payments from one customer and apply them to another customer in the same hierarchy. It can also be used to create the revenue roll-up report that rolls up revenue numbers from opportunities for all customers in a hierarchy.

You can create multiple versions of a customer hierarchy; however, only one hierarchy version can be active on a specific date. You can create a new hierarchy to represent the structure of a new customer. If the customer has made minor changes to its organization, you can create a new version rather than edit the existing one.

Oracle Engagement Cloud has both a graphical chart view and a table view for account hierarchies

The example below shows the parent/child relationship definition of “ABC Corporation” accounts through the Engagement Cloud.

While creating customers/prospects (Accounts) in Engagement Cloud, users can assign the parent account attribute. Users may assign the parent account attribute as needed to define the hierarchy.

Typically, customer hierarchy is used differently for different business needs. For example,

• Territory management uses to define account dimensions

• Financials application uses customer hierarchy information to process payments

• Revenue roll-up report uses customer hierarchy information to roll-up revenue from opportunities across all customers in the hierarchy.

The example hierarchy defined below has 3 children all pointing to one Parent record. Users can define any number of levels on the hierarchy.

Once the hierarchy is defined in Engagement Cloud, it can be used in Financials (Receivables) application for credit checking process as needed.

If you use a party-level hierarchy, then the credit checking process uses the credit definitions in the party hierarchy to determine the customer credit limit.

If a party-level hierarchy is defined for a customer, then the credit checking process first derives a credit limit from the parent party in the hierarchy, and then considers the available credit for each child party in the hierarchy to find the actual credit limit.

For more details around the configuration refer to the standard documentation “Using Receivables Credit to Cash” guide - https://docs.oracle.com/en/cloud/saas/financials/18c/faofc/using-receivables-credit-to-cash.pdf

Party Hierarchies (Trading Community Party Hierarchy)

As the term reflects, Party Hierarchies provides a way to maintain multiple relationships between parties in a hierarchical representation.

Let us take the example of “ABC Corporation” information mentioned above.

In this example, the Sales team and the Service team have different requirements for how the Party Hierarchy is defined. Hence, we need to maintain two different hierarchies. This can be achieved by creating two different hierarchy instances with the hierarchical relationship as needed by the business. In this model, the same customer/prospect (account) can be included in different hierarchies.

You can create two hierarchies, one for Sales team (“BM_ABC_Corporation_Sales”), and another one for Service team (“BM_ABC_Corporation_Service”). These hierarchies can co-exist as well. Note that, how you are leveraging these hierarchies for downstream and other business processes is up to the corresponding business requirement. Only the hierarchies are defined and managed within Oracle Fusion Cloud. These hierarchies can be exported and passed on to other applications as needed.

The main advantage of Party hierarchies is to have the same customer/prospect (account) included in multiple hierarchies in different levels based on your business needs.

The screen shots below provide the view of these hierarchies.

Dun and Bradstreet Hierarchy

Many organizations use Dun & Bradstreet hierarchy as legal hierarchy and use it for reporting.

Oracle’s Data-as-a-Service (DaaS) provides access to more than 345 million global company and contact records, so that you can have the most up-to-date information. You can use Oracle Social Data and Insight Cloud Service (DaaS) to find up-to-date company and contact records and export the data and import into Engagement Cloud, Marketing Cloud or another Oracle cloud application.

The following figure shows the flow of records from our partner data providers (Dun & Bradstreet) to data consumers (Oracle Cloud applications). DaaS is the data aggregator, collecting and processing the company and contact data for consumers.

We will focus on the hierarchy functionality on this article. For more details on enrichment you may refer to the documentation. https://docs.oracle.com/en/cloud/saas/social-data-insight-cloud/csdsr/using-social-data-and-insight-cloud-service.pdf

When you export one or more companies from DaaS, you can select to include company hierarchies with the export. Hierarchies provide a more complete picture of account opportunities across all related businesses and help you stay up-to-date with changes in corporate structures. For more details around exporting D&B hierarchy from DaaS, refer to the documentation - https://docs.oracle.com/en/cloud/saas/social-data-insight-cloud/csdsr/using-daas.html#GUID-41E19B95-EE98-4A38-8D55-DC916201693C

D&B hierarchy will be stored within Engagement Cloud very similar to the other hierarchies.

Partner Hierarchy

Partner hierarchy will have Partner records similar to Customer hierarchy containing customers/prospects. In many cases a Partner can also be a Customer/Prospect or otherwise.

For example, when user tries to create a Partner record for “ABC Corporation” which already exists as a Customer record, user will be displayed with potential duplicates screen where user can either select the existing record or create a new Partner record. When user selects the existing (Customer) record, that record is now available for Partner Management as well.

Below screen shot shows, that “ABC Corporation” plays both Customer and Partner roles. You can create a Partner hierarchy to include “ABC Corporation” record as a member.

Note that Partner hierarchy can have other Partner records as well based on your business needs. For example, you could create different partner hierarchies based on your needs such as regional based, product-based partner hierarchies.

Supplier Hierarchy

Tax reporting and payments, grouping of suppliers providing similar products and services, Spend Analysis, Supplier-Customer cross over analysis are typical use cases for maintaining Supplier hierarchies.

Supplier records are created in Oracle ERP Procurement Cloud. When data quality functionalities are enabled, if there is already another customer/partner/supplier record similar to the newly being created Supplier, there will be a popup window displayed to the users with potential duplicates, wherein user can choose to select one of the existing record or can create new supplier. Bottomline, Supplier record is an organization record within Oracle Fusion data model, and stored as a Party. Supplier related information from Procurement Cloud will be stored within Procurement Cloud.

One way of maintaining Supplier Parent/Child hierarchy within Oracle Procurement Cloud for tax reporting and payment capabilities is configuring supplier records to share the taxpayer ID.

You can configure shared taxpayer IDs if the “Allow Taxpayer ID Sharing Across Suppliers” feature is opted in to and enabled. Define a parent child hierarchy for suppliers before sharing a taxpayer ID between them. Note that suppliers can be in the same parent child hierarchy without sharing the same taxpayer ID.

Another way of managing Supplier hierarchy, is to create a “Trading Community party hierarchy”, and add all the suppliers you would like to have in this hierarchy in the order your business needs. This hierarchy may be exported and used in reporting and analytics as needed.

Notice that above hierarchy may also allow Partners / Customers / Prospect records to be included in the hierarchy. It is recommended that if you use this type of hierarchy, make sure that you have a governance process in place to manage as per your business requirements with additional validations as needed.

Versioning

While creating hierarchies in Oracle Fusion applications cloud, 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.

• You need to support a new business process area that has distinctive customer hierarchy requirements that cannot be met by your existing hierarchies.

• 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 are 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.

Enterprise Data Management Cloud

Oracle Fusion application cloud provides

• Party hierarchy capabilities to support managing Organization / Business / Customer / Supplier / Partner hierarchies.

• Account hierarchy capabilities in Financial cloud application to manage financial account hierarchies.

If you have business requirements to create and manage enterprise data with comprehensive hierarchy capabilities, for managing your financial accounts, Chart of Accounts, General Ledgers, Cost Center, reference data hierarchy data centrally with governance, and to publish/share the enterprise data across applications, then Oracle Enterprise Data Management (“EDM”) Cloud would be the best fit for you. Additional comprehensive hierarchy capability provided by “EDM” is the ability to handle alternative prospective for any of the Party Hierarchies managed in Oracle Fusion and the ability to manage cross functional views like Sales Territory Management, Supplier Profitability Management, or Customer Profitability for example.

Oracle EDM Cloud manages changes in your business by ensuring consistency across enterprise data, even across disparate applications. With Oracle EDM Cloud, you can quickly import, manage, and export consistent and accurate enterprise data to multiple external applications.

References

Note: Always refer to the latest documentation.

Customer Data Management

https://docs.oracle.com/en/cloud/saas/sales/18c/faeim/using-customer-data-management.pdf

Data as a Service (Oracle Social Data and Insight Cloud Service)

https://docs.oracle.com/en/cloud/saas/social-data-insight-cloud/index.html

Partner Relationship Management

https://docs.oracle.com/en/cloud/saas/sales/18c/fasco/using-partner-relationship-management-for-channel-managers.pdf

Procurement

https://docs.oracle.com/en/cloud/saas/procurement/18c/oaprc/using-procurement.pdf

Receivables

https://docs.oracle.com/en/cloud/saas/financials/18c/faofc/using-receivables-credit-to-cash.pdf

Enterprise Data Management

https://docs.oracle.com/en/cloud/saas/enterprise-data-management-cloud/dmcaa/GUID-7807DB45-355D-4D01-88CB-2BAD75C433D4.pdf