X

Best Practices from Oracle Development's A‑Team

Best Practices to Model Customer, Supplier, and Partner Hierarchies in Oracle Fusion Cloud

Bala Mahalingam
Consulting Solution Architect A-Team

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.

Hierarchy Focus

Functional Area

Usages

Customer Hierarchy

Sales & Service

Territory Management

Financials

Payment Processing

Credit Check

Reporting

Revenue Roll-Ups

Dun & Bradstreet Hierarchy

Sales & Service

Legal Hierarchy

Reporting

Revenue Roll-Ups

Supplier Hierarchy

Procurement

Payments

Reporting

Tax Reports

Partner Hierarchy

Partner Relationship

Sales Organization

Partner’s Contacts

Financial Account Hierarchy

Financials

Chart of Accounts

General Ledgers

Cost Centers

Reference Data

Common References

Geographies

Codes & Values

Product Hierarchy

Product Life cycle

Inventory

Order Management

Product Management

Reporting

 

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.

Fusion Hierarchy Type Description
Customer Hierarchy Tree structure used to manage a hierarchy among a sales prospect, sales account, legal entity and customer.
Party Hierarchy Tree structure for a party hierarchy.
Partner Hierarchy Manage a hierarchy among a partner and inactive partner.
D&B Hierarchy Predefined tree structure for maintaining the D&B corporate hierarchy.

 

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

Benefits Guidelines
Simple hierarchy and sales team can easily define this while creating Customers (Accounts). OR Operations team can manage the customer hierarchy separately. Create a governance process for managing the hierarchies especially if the same hierarchy is used for different purposes such as Sales, Service, Order Management, Financials use cases.
Easy to maintain Visibility restrictions if enabled for sales users, there will be challenges in managing the hierarchies.
If you are using other application modules within Fusion Cloud such as Enterprise Resource Planning (ERP) Financials, Order Management and others, this hierarchy is available automatically where needed. When multiple application modules are used within Oracle Fusion Cloud, define your customer creation process thoroughly representing all business requirements such as sales, financials, reporting etc.
Customer Hierarchy can co-exist with other hierarchies such as Dun & Bradstreet hierarchy, and Trading Community Hierarchy. Every account can have one and only parent on Customer hierarchy. In other words, A customer can be present in only one active customer hierarchy.
Hierarchy information can be imported directly into Oracle Cloud if information is available already from your legacy applications  
You can create multiple versions of the same hierarchy, but only one of them can be active any time.  
Export and Import functionality may be configured  

 

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.

Benefits Guidelines
Same Customer/Prospect (Account) record can exist in multiple hierarchies. You can do version management as needed. Create a governance process and carefully design the different hierarchies. You don’t want to create too many hierarchies without having proper business needs & use cases.
Easy to create and manage hierarchies When you have more number hierarchies, the complexity of management also increases, for example if you want to delete a customer/prospect (Account) record or you need to make sure that proper sequencing is used to avoid leaving orphan records.
If you are using other application modules within Fusion Cloud such as Enterprise Resource Planning (ERP) Financials, Order Management and others, this hierarchy is available automatically where needed. When multiple application modules are used within Oracle Fusion Cloud, define your customer creation and hierarchy management process thoroughly representing all business requirements such as sales, financials, reporting etc.
Party hierarchy can co-exist with other hierarchies such as Customer hierarchy, and Dun & Bradstreet hierarchy. Every account can have one and only parent on Customer hierarchy. In other words, A customer can be present in only one active customer hierarchy.
Hierarchy information can be imported directly into Oracle Cloud if information is available already from your legacy applications  
Export and Import functionality may be configured  

 

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.

Benefits Guidelines
Automated integration between DaaS (Social Data and Insight Cloud) and Oracle Cloud applications (Engagement Cloud, and Marketing Cloud). Out-of-the-box mappings are provided. Plan a governance process to refresh D&B hierarchy periodically to keep the D&B data up-to-date.
Export from DaaS & Import process is automated. DaaS supports only export and import of hierarchies. If you want to refresh/update an existing D&B hierarchy, you need to delete and import the new hierarchy.
D&B hierarchy can co-exist with other hierarchies. D&B hierarchy is typically used for reporting. If you need the full D&B hierarchy created in Engagement Cloud, then you must export the complete hierarchy. You cannot choose only certain records in the hierarchy to export.

 

 

REST API’s are provided to integrate with other applications as well. Do not change the 3rd party data and hierarchical relationships.

 

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.

Benefits Guidelines
Simple hierarchy management, only Partner records can be included in this hierarchy. Plan a governance process on creating partner hierarchies, especially when a partner could be a customer/ supplier as well.
Export and Import functionality may be configured  

 

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

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha