Designing Account Hierarchies in Oracle Fusion Application- Part 1

Objective:

In this training article we will understand what account hierarchies are and why we require those. In the subsequent articles we will learn how to design Account hierarchies in Oracle Fusion applications step by step. We will also discuss the recommendations and best practices followed for designing the same.

What are account hierarchies? :

We need to create account hierarchies in order to reflect managerial, legal or geographical relationships between the value set values. The financial balances are pre-aggregated at each parent level in the hierarchy, thus allowing fast and robust account inquiry and drill. An organization operating at multiple levels always need a track on the account balances at each level for various managerial purposes. Say for example a company has multiple sales departments selling IPAD, IPHONE, laptop, etc at various geographic locations. The top level management may not be interested on sales at granular level. They want to track the overall sales which the company has registered. In that case we need account hierarchy. Again in the said company a regional manager for a particular region responsible for IPAD and IPHONE only would be generating report from only two divisions operating in the particular allocated region using account hierarchies. In a nutshell we use account hierarchies to track the figures country wise, department wise, regional wise, territory wise, product wise and so on using Account hierarchies.

Why we create Account Hierarchies? :

Account hierarchies can be created for various requirements-

• Creating multiple hierarchies for different purposes e.g. define three different hierarchies to be used for each chart of accounts segment that has roll ups, each for a particular purpose.

• Hierarchies for financial reporting. It must be published to Essbase cubes. Child values in these hierarchies cannot roll up to different parents within a hierarchy as this functionality is not support when publishing such hierarchies to Essbase.

• Hierarchies for allocations. It must be published to Essbase cubes. Used with Allocation Manager in creating allocation rules.

• Hierarchies for cross-validation rules, revaluation and chart of accounts mapping :

a)    Created within the same hierarchy and must be associated with a chart of accounts instance.

b)    Only associate one hierarchy with a chart of accounts instance, per segment

c)    Such hierarchies can have the same child to roll up to different parents.

d)  Do not publish to the Essbase cube since multiple child assignments are not supported in the Essbase cube.

How many hierarchies should we define? :

Hierarchies are built on top of value set values. We can define as many as we want per value set. However the best practice is to creating different hierarchies for trees that serve different business purposes (e.g. management versus geographical hierarchy), and within each hierarchy define date-effective versions to reflect changes over time.

Account hierarchies:

We can perform the following task-

• Create account hierarchies (trees) to identify managerial, legal or geographical relationships between the value set values. A segment in the chart of account can have multiple hierarchies and each hierarchy can have multiple versions.

• Define date effective tree versions to reflect organizational changes within each hierarchy over time.

• Publish multiple hierarchies to balances cubes to allow for financial reporting and analysis of past, present or future data.

Anjan Mukerji

Add comment