Oracle Hyperion Financial Management (HFM): The Value Dimension Explained!

Oracle’s consolidation tool, Hyperion Financial Management (HFM), offers a

number of system-generated dimensions. Perhaps the most important of these
dimensions is the “Value” dimension. You’ll really do yourself a favor if you can
understand how the Value dimension works in HFM, as this dimension drives
the consolidations performed by the system. The Value dimension can seem
complex, especially when trying to validate and reconcile data. Simply put, the
Value dimension is comprised of the different types of stored data in an HFM
application. Input data, translated data, adjustment data, and consolidation
data can all be viewed separately. In this way, the Value dimension provides an
audit trail of data types.
Below is a screenshot of the Value dimension. We will focus on the members in
the red box for this blog. In the Value dimension, members are grouped in
triplets. The triplets we will look at are Entity Currency->Entity Curr Adjs->Entity
Curr Total and Parent Currency->Parent Curr Adjs->Parent Curr Total.

Every member of the Entity dimension is assigned a currency in the

metadata. Entity Currency will store the values for an entity in its assigned
currency (sometimes referred to as “default currency” or “local currency”). An
entity’s Parent Currency is actually what it sounds like – it is the default
currency of an entity’s parent. Parent Currency will store the values for an
entity translated to the currency of its parent. This stored value will be
generated when a consolidation is run in the system. This consolidation process
performs currency translations based on exchange rates that have been entered
in the application. Shown below is a ‘Canada Company’ entity which is the lone
descendant of ‘US Parent’ in the organizational structure. For ‘Canada
Company’ in the Cash account, Entity Currency (which is CAD) is 2,500.00 and
Parent Currency (which is USD) is 2,463.46. Where ‘Canada Company’ is the
lone descendant in the hierarchy of ‘US Parent’, 2,463.36 is the amount in Entity
Currency (USD) for ‘US Parent’ as well.

Now to add a wrinkle: let’s look at the idea of adjustments being put into the
application via journal entries. The HFM journal process is a topic for a future
blog, but understand that journal data is stored in a specific Value dimension
member called “Entity Currency Adjust.” Here we see that journal entries have
their own home because the Value dimension acts like an audit trail!
The simple mathematical formulas to keep in mind are as follows:
Entity Currency + Entity Currency Adjust = Entity Currency Total
Entity Currency Total x foreign currency rate (which in this example is 0.9758) =
Parent Currency
Below we see journal entry data in the amount of 100.00 in Entity Curr Adjs (the
system abbreviation of Entity Currency Adjust). This 100.00 gets added to the
2,500.00 in Entity Currency to give us 2,600.00 in Entity Curr Total. The 2,600.00
is then translated to 2,537.08 at Parent Currency by the system.

Clients often want to know why a journal posted to Entity Currency Adjust does
not show up as a translated value in Parent Currency Adjust. The Value
dimension does not work that way. Entity Currency and Entity Currency Adjust
are first added together in the Entity Currency Total triplet. The Entity Currency
Total value is then translated to produce a value in Parent Currency. Parent
Currency Adjust is reserved for journals that are posted in the currency of an
entity’s parent. Parent Currency combined with Parent Currency Adjust equals
Parent Currency Total in this triplet.
The mathematical formula to would be:
Parent Currency + Parent Currency Adjust = Parent Currency Total
Building on our previous example, below we have added a Parent Curr Adjs (the
system abbreviation for Parent Currency Adjust) in the amount of
200.00. Combined with the translated value of 2,537.08 in Parent Currency, the
amount in Parent Currency Total is calculated at 2,736.08.
There will be more to come on the other members of the Value Dimension, but
if you can grasp what I have covered so far you are well on your way to
understanding the intricacies of HFM dimensionality.
Author: Joseph Francis, Performance Architects

http://www.performancearchitects.com/wp/2015/05/27/oracle-hyperion-
financial-management-hfm-the-value-dimension-explained/
HFM - Value Dimension and Rules
Maybe the complex part of HFM is the value dimension and rules, after you
understand these two parts of HFM elements I am sure you will get a better
understand of HFM's consolidation logic. So let me introduce the value
dimension first.

Value dimension is a system-defined dimension, it represents the types of value

stored in your application. You can find the following image for your quick
understanding if this dimension.

Actually, you will find the dimension shows in HFM system as below, depending
on how many currencies you have set up for the application. (5 currencies in this
example.)
Technically, <EC>, <ECA>, <ECT>, <PC>, <PCA> and <PCT> are the pointers to the
currency members. For example, if the entity and its parent's local currencies
are HKD, the data will be stored in "HKD" member when input data in <EA> or
translate data to <PA>.

For the sub group rollup logic in Entity dimension, you can find the picture
below. Sub Group's <EC> = Sum of the children Subsidiaries/Associates/Joint
Ventures' [Contribution Total]
After the understanding the value dimension, we can move to the HFM rule's
calculation logic. Actually, the HFM admin guide describes very clearly about the
rules so I just copy some of the contents here.

You use Financial Management rules to automate the calculations of data

within an application. You can use rules for these purposes:

 Calculate data entry level amounts for a specific entity, scenario, and
period.
 Prevent data entry for a specific cell in a specific entity, scenario, and
period.
 Allow input at the Parent entity level.
 Calculate data that cannot be calculated through a hierarchical
aggregation, such as ratios or variance analysis.
 Perform allocations from a parent entity to a list of base entities.
 Perform complex currency conversions, calculate exchange rate
differences, or perform other calculations necessary for your consolidation.
 Define formulas to dynamically calculate accounts.
 Specify the accounts in the application that support intercompany
transactions.
HFM provides the following rule types
 Calculation
 Translation
 Consolidation
 Allocation
 Input
 NoInput
 Dynamic Calculation
 Transactions
 Equity Pickup
 OnDemand (From version 11.1.2.3)
During the consolidation process, rules are executed in a pre-defined sequence.
For each base child of a specific parent, the calculation sequence for the various
elements in the Value dimension takes place in this order:
1. Accounts defined as IsCalculated in the metadata are cleared in
EntityCurrency.
2. Accounts defined as IsCalculated in the metadata are cleared in
EntityCurrAdjs.
3. The Sub Calculate() routine is executed on EntityCurrency.
 4. The Sub Calculate() routine is executed on EntityCurrAdjs.
5. The ParentCurrency data is cleared.
6. Default translation is applied to all accounts defined as Revenue,
Expense, Asset, Liability for the total amount of EntityCurrency and
EntityCurrAdjs. For accounts with the Flow or Balance attribute,
translation is not applied by default, the total amount of EntityCurrency
and EntityCurrAdjs is rolled up into Parent Currency.
7. The Sub Translate() routine is executed.
8. The Sub Calculate() routine is executed on ParentCurrency.
9. Accounts defined as “IsCalculated” in the metadata are cleared in
ParentCurrAdjs.
10. The Sub Calculate() routine is executed on ParentCurrAdjs.
11. Accounts defined as “IsCalculated” in the metadata are cleared in
ParentAdjs
12. The Sub Calculate() routine is executed on ParentAdjs.
13. Proportion and Elimination data are cleared.
14. Default consolidation and eliminations are performed for the total
amount of Parent and ParentAdjs.
15. The Sub Calculate() routine is executed on Proportion and
Elimination.
16. Accounts defined as “IsCalculated” in the metadata are cleared in
ContributionAdjs.
17. The Sub Calculate() routine is executed on ContributionAdjs.
After the previous steps have been repeated for each base child, this sequence
takes place for the parent entity:
1. The EntityCurrency data is cleared.
2. The sum of the total of Proportion, Elimination, and
ContributionAdjs for every child is written into EntityCurrency of the
parent entity.
3. The Sub Calculate() routine is executed on EntityCurrency.
4. Accounts defined as “IsCalculated” in the metadata are cleared in
EntityCurrAdjs.
5. The Sub Calculate() routine is executed on EntityCurrAdjs.
Note: If a parent is further consolidated into another parent, this sequence
continues with step 5 from the child consolidation sequence.

http://hyperioncenter.blogspot.in/2014/12/hfm-value-dimension-and-
rules.html

The “subcube” describes the structure of data storage and retrieval in

Hyperion’s Financial Management solution1 (HFM). The approach to subcube
management in HFM has changed significantly with this release to improve
performance and to facilitate much larger subcube sizes than were previously
possible.

DEFINING THE SUBCUBE HFM stores data in one of three table types: • DCE
(Currency subcube)—Stores Entity Currency and Parent Currency values and
their adjustments. These are often referred to as the currency triplets in the
Value dimension: o The triplets are formed by the entity default currency,
journal adjustments posted in the entity’s default currency, and the total
aggregated value of the two. o If the entity’s parent has a different default
currency, a second triplet of data is provided for the parent currency. o It is also
possible for a user to force a translation into another currency in addition to the
. The result of this forced translation is a set of stored data in the additional
currency. • DCN (Parent subcube)—Stores the remaining Value dimension
members. o All data in the Parent cube is specific to a parent-child combination,
and as such can only be stored or retrieved by specifying this relationship. DCN
tables are structurally similar to DCE tables, with one exception: DCN tables
contain an additional field for the parent entity ID (LPARENT). • DCT (Journal
transactions)—Stores the journal transactions, which when posted, transfer
data values to DCE (for and ) or DCN tables (for [Parent Adjs] and Contribution
Adjs]). The following graphic shows the Value dimension and which members
are grouped into each subcube:

http://charlescbeyer.com/ccb_wp/wp-
content/uploads/2013/05/Hyperion_System_9_Financial_Management_Subcub
e_Architecture_0406.pdf

About Subcubes

Several Financial Management methods work with subcubes. A subcube consists

of all the cells that share the same members of the following dimensions:

 Year
 Scenario
 Entity
 Value

There are two types of subcubes—currency subcubes and node subcubes. These
types of subcubes differ in how they use Entity and Value dimension members:

 A currency subcube contains cells that share applicable non-node Value

dimension members. For currency subcubes, the parent of the Entity
member is irrelevant. The applicable non-node Value dimension members
are as follows:
o Members for user-defined currencies. There is one triplet of Value
dimension members for each user-defined currency. For example, if
an application contains a currency named USD, the currency’s
triplet of Value dimension members will be USD, USD Adjs, and USD
Total.
 o The triplet that points to the entity’s default currency. This triplet
consists of the <Entity Currency>, <Entity Curr Adjs>, and <Entity
Curr Total> Value members.
o [None] Value member.

Note: The non-node Value dimension members that point to parent entities’
default currencies—<Parent Currency>, <Parent Curr Adjs>, and
<Parent Curr Total>—are irrelevant to currency subcubes.

 A node subcube contains cells that share a common node Value

dimension member. For node subcubes, both parent and child Entity
members must be specified. The node Value dimension members are as
follows:
o [Contribution Total]
o [Contribution Adjs]
o [Contribution]
o [Elimination]
o [Proportion]
o [Parent Total]
o [Parent Adjs]
o [Parent]
This is nothing more than Entity Currency + Entity Curr Adjs. It is the total
local currency inclusive of adjustments and loaded/submitted data.

Parent Currency
Next up the chain is Parent Currency. This member takes total local currency
(Entity Curr Total)and translates it to the currency of its immediate parent in
the entity hierarchy.

Back to our good old friends across the pond in the London sales office, since
they roll up to a Euro parent company, the system will translate from GBP to
EUR when the consolidation goes from Entity Curr Total to Parent Currency.
The above shows a translation from GBP to EUR using a currency rate of €1.25
to £1.00
Parent Currency Adjustments
Up from Parent Currency is Parent Curr Adjs.

Parent CurrAdjs is an intersection that allows users the ability to book an

adjusting journal in the currency of the entity’s parent. It is NOT the Entity
CurrAdjs translated. Recall that Entity Currency and Entity CurrAdjs get
added together at Entity Curr Total, which then translates to Parent
Currency.
Let’s assume that the London sales office had to book a 150K EUR
adjustment. Instead of figuring out what that amount is in GBP and booking
in Entity CurrAdjs, the sales office has the option of booking the 150K EUR
straight to Parent Curr Adjs.

Parent Currency Total

As before, the totals for Parent Currency and Parent CurrAdjs are added
together to get to Parent Curr Total, which is the total post-translated amount
inclusive of any parent currency adjustments.
For the purpose of simplification, we will jump ahead to the Elimination
Value dimension member. Though there are other Value dimension members
between Parent Curr Total and Elimination, these are not typically used other
than for percent ownership, equity pickup, and blah blah, accounting speak,
blah debit, blah, credit. We’ll save that for another time.

Elimination
Elimination. The one word that can make anyone cringe when it comes to
data tie out or passing of data between systems. Eliminations are necessary
when two entities that belong to the same organization have activity with one
another. Though it is important to be able to see that activity at the entity
level, it has to be zeroed out at the appropriate consolidation point. After all,
a company can’t make money off of itself (we’re not running a Ponzi scheme
here).

Why do we need to load Elimination data if it just nets to zero? Valid

question – if it doesn’t net to zero, or if it zeroes out across levels, it is
important to have the detail to support all of the activity. Enter the
Elimination dimension.
To keep it simple, let’s say that Company A has a receivable from Company
B. Company B should have the offsetting Payable on their books.

That intercompany transactions between Company A and Company B are not

eliminated (zeroed above) until the first common parent of each company is
met. To keep things simple, let’s just say that both companies roll up to
parent Company AB. This is where it will eliminate.

Contribution
Contribution represents what ultimately gets passed from child to
parent. Keeping it simple, it is equal to Parent Curr Total +
Elimination. This total then gets sent up the chain to its parent’s Entity
Currency member.Seen below, Entity Currency for the parent entity (Total
Europe) is the sum of the Contribution amounts from each of its children
(London & Zurich).
Now, putting it all together, hopefully you should be able to make some sense
of Oracle’s diagram of the Value dimension, seen below.

And then the process starts all over again…

…with Total Europe at Entity Currency and continues upwards through the
Value dimension and, ultimately, gets to total company consolidated financial
statements.

http://platformspecialists.com/2015/03/30/the-real-value-of-consolidations-in-
hfm/