Oracle Fusion General Ledger

Hierarchies: Recommendations
and Best Practices
An Oracle White Paper
April, 2012

Oracle Fusion General Ledger Hierarchies:

Recommendations and Best Practices

INTRODUCTION

This white paper describes the best practices of maintaining and publishing the account
hierarchies. Account hierarchies are used throughout Oracle Fusion General Ledger for
creating financial reports, Smart View ad hoc inquiries, allocation definitions, cross
validation rules, and revaluation definitions.

ACCOUNT HIERARCHIES, TREES, AND TREE VERSIONS

Account hierarchies are defined in Oracle Fusion applications using tree functionality.
Each account hierarchy is defined as a tree with one or more versions. Tree versions
are used to track account hierarchies as they change over time. For example, an
account hierarchy to summarize cost of goods has different accounts for 2011, versus
2010, based on changes in the business operations and newly added chart of accounts
values
Chart of accounts values can be associated with multiple hierarchies by defining
multiple trees. Using multiple trees allows you to create financial reports for different
target audiences. For example, you can use different hierarchies to track cost centers
either by geography or line of business.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 2

HIERARCHY PURPOSES
Before setting up hierarchies, you may want to consider different hierarchy
requirements for financial reporting, allocations, cross validation rules, revaluations, and
chart of accounts mapping.
Financial Reporting and Allocations
You can use the same hierarchy or different hierarchies for both reporting and
allocations purposes. Hierarchies that are used in financial reporting and
allocations must be published to Oracle Essbase. You can select which
hierarchies you publish to Essbase. Any hierarchy that is published to Essbase
cannot have a single child value roll up to multiple parents. If you have
requirements to have a single child roll up to multiple parents, it has to be
defined using multiple hierarchies.
Cross Validation Rules, Revaluations, and Chart of Accounts Mappings.
You need one hierarchy for each segment that is used for cross validation rules,
revaluation, and chart of accounts mapping. Hierarchies used for cross
validations, revaluations, or chart of accounts mapping have to be defined within
the same hierarchy. The hierarchy must then be associated with a chart of
accounts instance. You can only associate one hierarchy with a chart of accounts
instance, per segment.
You can optionally publish this hierarchy to Essbase if you want to use the same
hierarchy for reporting and allocations too, but note the restriction that any
hierarchy that is published to Essbase cannot have a single child value roll up to
multiple parents. If you have requirements to have the same child to roll up to
different parents within this hierarchy, then you should have a different hierarchy
for reporting and allocation rules.
In rare cases where you can use the same hierarchical account relationships for
financial reporting, allocations, cross validation rules, revaluations, and chart of
accounts mapping definition, you can define just one hierarchy. However, if you need
multiple hierarchies, it is recommended that you define them using multiple trees.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 3

MEMBER NAMES IN FINANCIAL REPORTING AND ALLOCATIONS

HIERARCHIES
You must publish hierarchies for financial reporting and allocations to Oracle Essbase
cubes. When a hierarchy is published to an Essbase cube, a fully qualified member
name is generated for each node in the hierarchy. This fully qualified member name is
used to refer to the node in the hierarchy in financial reports and allocation rules.
Each combination of tree plus tree version is published as a different account hierarchy
to Essbase cubes. When a chart of accounts child or parent value is assigned to multiple
hierarchy versions, the fully qualified member name includes the hierarchy version
name.
You must consider the implications to your financial reports, allocation rules, and Oracle
Hyperion Smart View templates if the fully qualified member name changes due to
hierarchy changes. The points to considered are:

The fully qualified member name for a member may change if you originally
published a single hierarchy to a cube and later published another hierarchy that
includes the same chart of accounts value.
If the fully qualified member name changes, you must update existing financial
reports, allocation rules, and Smart View templates that refer to that member.
Otherwise, such processes have errors.

For example, only a single hierarchy version, V1, existed when you defined a financial
report. The hierarchy version includes the chart of accounts value of 500 for a cost
center. The path does not include a hierarchy version name, since there is only one
hierarchy version in the cube. The fully qualified name path is 500.
Later, you publish a new hierarchy version, V2. The fully qualified member name
changes since there are now two versions and cost center 500 is associated with two
hierarchy versions, V1 and V2. When selecting the value 500, the cube has logic to
uniquely identify the member. The fully qualified member name for the two hierarchy
versions is now:

[All VF Cost Centers-V1].[999].[500]

[All VF Cost Centers-V2].[999].[500]

Note
The fully qualified member can also be shortened by the cube logic, such as
[Cost_Center]@[Cost Center Level 29 Code]|[500].

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 4

You must update any configurations, such as financial reports, allocation rules, or Smart
View queries that referenced the original fully qualified name path of 500 to use the
correct name.

RECOMMENDATIONS FOR INITIAL PUBLISHING AND

MAINTENANCE OF ACCOUNT HIERARCHIES
If you start with only one version of a hierarchy and you add multiple versions of the
hierarchy later, then the fully qualified member name changes. Therefore it is
recommended that you always create at least two hierarchy versions before creating
any financial reports or allocations. This will force the fully qualified member name path
to be generated and refers to the full tree name, tree versions, and minimize the report
maintenance, if you must add another version in future.
To avoid maintenance efforts when more hierarchies are published, it is recommended
for you to follow these recommendations:

Create two tree versions of the same tree before creating any financial reports or
allocations to force the fully qualified name to be generated.
Keep the two tree versions in sync always to guarantee fully qualified names are
used in financial reports and allocations.
Use the same tree version names over time to avoid breaking your reports or
configurations.
Use different hierarchies if you have requirements to roll the same child to more
than one parent.

The initial configuration steps must be completed before the definition of any financial
reports, allocation rules, or Smart View queries
Initial Configuration Steps:
1. Create a hierarchy version for the account hierarchy. Name the hierarchy version
with a name that is consistently used across versions. For example, use Current
or other similar naming conventions. Use an effective start date equal to the
beginning of the financial reporting period.
2. Set the status to Active.
3. Copy the hierarchy version. Name the hierarchy version to indicate that this
version is just a copy. For example, Baseline.
4. Set the copied hierarchy version status to Active as only active versions can be
published to the cube.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 5

5. Provide the copied hierarchy version with an effective date range earlier than the
original to ensure no effective date is overlapped.
6. Make no hierarchy changes to the hierarchy version which is copied (baseline) so
that the two hierarchy versions are consistent.
7. Publish both tree versions to the cube.
8. Review the published results using Smart View.
Once these steps are complete, you can create financial reports, allocations, and Smart
View queries, using the version called Current in this example. The Baseline version is
published to enforce the fully qualified name to be generated and minimize changes in
the future.
Maintenance of hierarchies
As your organization changes or there are updates to your chart of accounts values,
you can make updates to your hierarchy versions. These changes must also be
reflected in two hierarchy versions for each hierarchy, both published to the cube, to
minimize errors related to the fully qualified member name path in financial reports,
allocation rules, or Smart View queries.
If you want to keep an audit history, it is recommended that you copy the hierarchy
version and use the copy as the version for audit history. After you copy the hierarchy
version, modify that same version to use as the latest version. You do not have to
change reports.
Perform the following steps before updating the current hierarchy version:
1. Copy the current hierarchy version to create a new hierarchy and name it with
another name, for example Cost Center 2011 if you want to keep an audit history
for year 2011.
2. Update the effective date for the Current hierarchy version to the current period
and set the effective dates for the copy hierarchy version to what the past dates
were.
3. Make all of your current hierarchy changes to the Current hierarchy version.
4. Set the status for the Current hierarchy to Active again.
5. Delete the Baseline hierarchy version in the Manage Account Hierarchies
page. You do not need to unpublish the hierarchy from the cube, as long as you
follow the naming conventions discussed in the following steps.
6. Copy the Current hierarchy version and name it Baseline. You must name it
the same exact name because Baseline still exists in the cube. The procedures
overwrite the hierarchy version named Baseline in the cube.
7. Use effective dates that do not overlap and that are before periods used by
previously active hierarchy versions.
8. Set the status for the Baseline hierarchy version to Active.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 6

9. Publish both hierarchy versions, Current and Baseline, to their respective cube.
10. Publish the cost center 2011 to the cube if it is still needed for financial
reporting, Smart View queries, or allocation rules.
11. Review the published results using Smart View.
You have the following three versions:
1. New copied version: This version is used to track the history of the old master
version, for example, cost center 2011 and have been end dated.
2. Current version: This version has been modified to reflect the new hierarchy
and is now active.
3. Baseline version: This version should continue to be the duplicate of the
master version. Rather than modifying this manually, it is recommended that you
delete the old baseline version and create another copy of the master. Modify
the master version. These steps should be followed each time when there are
hierarchy changes that must be published.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 7

EXAMPLE
The following example illustrates how to maintain your hierarchy.
Your organization, Vision Operation begins using Oracle Fusion General Ledger,
effective January 1, 2011. Vision Operations use a single chart of accounts named
Corporate Chart of Accounts. Since there is only one chart of accounts, this is also the
name of the cube. Vision Operations uses a hierarchy to capture its cost center roll ups
by line of business. The name of this hierarchy is Cost Centers Hierarchy.
The following graphic displays the relationships between the hierarchy versions and the
cube:
Initial Configuration:
Step 2: Publish both versions

Step 1: Copy and create a baseline

Hierarchy Version: Cost

Center Current
Effective Dates: 01-Jan-2011
(blank)
Status: Active

Publish

Cube: Corporate
Chart of Accounts

Copy
Hierarchy Version: Cost
Center Baseline
Effective Dates: 01-Jan-2000
31-Dec-2000
Status: Active

Publish

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 8

At the end of 2011, your organization, Vision Operations, makes organizational changes
to its lines of business. You add new cost centers and a new line of business. As a
result, you must update your cost center hierarchies to ensure that financial reporting
reflects the new organization structure.
You do not have to make any changes to the Cost Center Master hierarchy version if
there are no organizational or chart of accounts value changes and the current
hierarchies are working.
However, since there are changes you need to:
1. Copy and back up the Cost Center Current hierarchy version to maintain
history.
2. Make changes to the Cost Center Current hierarchy version and change it to
the new effective dates.
3. Delete the hierarchy version named Baseline. You do not need to unpublish the
hierarchy from the cube, as long as you follow the naming conventions discussed
in the following steps.
4. Copy the Current hierarchy version after changes are completed and name it
Baseline.
5. Publish the Current hierarchy version again.
6. Publish the new Baseline hierarchy version again.
Note
After publishing both versions, there are still only two hierarchy versions in the cubes.
Important

The version name must always be the same, for example, Cost Center Current
and Cost Center Baseline, across all periods, months, and years because that
is what is referenced in the financial reports, Smart View queries, and allocation
rules. For example, do not have a version named 2011 Cost Center, or 2012
Cost Center Current, or 2012 Cost Center Baseline.
This example assumes an annual change. It can also be quarterly, monthly, or as
needed. You should follow these steps for any hierarchy changes at any time for
even regular maintenance, such as adding values or moving values in the
hierarchy. It is recommended to always keep your current and baseline hierarchy
versions in sync.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 9

The following graphic displays steps to update your hierarchy versions:

Step 1:(Optional)Copy Cost Center

Current to Cost Center 2011 to
maintain history

Hierarchy Version: Cost

Center Current
Effective Dates: 01-Jan-2011
(blank)
Status: Active

Modify

Hierarchy Version: Cost

Center Current
Effective Dates: 01-Jan-2012
(blank)
Status: Active
First delete

Step 3: Publish
both versions

Publish

Then
Recopy

Copy
Hierarchy Version: Cost
Center 2011
Effective Dates: 01-Jan-2011
31-Dec-2011
Status: Active

Step 2: Modify Cost Center Current to create

new version,
Delete old Cost Center Baseline
Create a new Cost Center Baseline

Hierarchy Version: Cost

Center Baseline
Effective Dates: 01-Jan-2000
01-Jan-2000
Status: Active

Publish

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 10

Cube:
Corporate
Chart of
Accounts

HIERARCHIES FOR CROSS VALIDATIONS, REVALUATIONS, AND CHART OF

ACCOUNTS MAPPING
Hierarchies you create for reporting or allocations may not be suitable for setting up
cross validations, revaluation, and chart of accounts mapping rules.
For example, if you must enforce a cross validation rule that a set of 20 departments is
applicable only to a certain company, then you can group the 20 departments under a
hierarchy node and refer to that hierarchy node in the cross validation rule.
For hierarchies for cross validations, revaluations, and chart of accounts mapping:

Create hierarchies for cross validations, revaluation, or chart of accounts

mapping within one hierarchy. Associate this hierarchy to the chart of accounts
segment instance in the chart of accounts instance setup page. You can only
associate one hierarchy with the chart of accounts instance. You can create
separate root nodes for each segment of the hierarchy.
Create an account hierarchy for each of the segments that are used in the rule
set ups. Depending on your requirements, not all segments may need a
hierarchy.
Use the same child to roll up to different parents if you need different roll ups for
cross validations, revaluations, and chart of accounts mapping.
Flatten and audit the hierarchy after the hierarchies are complete and set it to an
active status.
Associate the hierarchy to the chart of accounts segment instance.
Redeploy the accounting flexfield after the chart of accounts instance is updated.

If you have the duplicate segment values in a hierarchy, you should not publish the
hierarchies to Oracle Essbase.

About Oracle Fusion Applications

Oracle Fusion Applications leverage industry standards and technologies to transform organizations into nextgeneration enterprises. Oracle Fusion Applications are service-enabled, enterprise applications that can be easily
integrated into a service-oriented architecture and made available as software as a service.
For more information about Oracles Fusion Accounting Hub, please contact us today at 800-273-9913. To learn
more about Oracle Fusion applications, please visit oracle.com/fusion.

Oracle Fusion General Ledger Hierarchies: Best Practices and Recommendations Page 11

Oracle Fusion General Ledger Hierarchies: Recommendations and Best Practices

Authors: Mei Siauw, Greg Roth, Matt Skurdahl, Kathryn Wohnoutka
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2012, Oracle and/or its affiliates. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners. 0409