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