Value Dimension

Oracle Hyperion Financial Management (HFM): The Value Dimension Explained! consolidation n tool, Hyperion Financial Management (HFM), (HFM) , offers a Oracle’s consolidatio number of system-generated system-generated dimensions. Perhaps the most important 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 and reconcile data. Simply put, the Value dimension is comprised of the different types of stored data in an HFM application. Input data, translated translated data, adjustment adjustment data, and consolidation consolidation data can all be viewed separately. separately. In this way, the Value dimension dimension provides an audit trail of data types. Below is a screenshot of the Value dimension. dimension. We will focus on the members members in the red box for this blog. blog. In the Value dimension, dimension, members are grouped grouped in triplets. The triplets we will look look at are Entity Currency->Entity Currency->Entity Curr Adjs->Entity 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 store the values for an entity in 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 will store the values values for an currency of an entity’s parent. Parent Currency will entity translated to the currency currency of its parent. This stored value will be generated when a consolidation consolidation is run in the system. This consolidation process 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 or ganizational 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 2,463.46.. Where ‘Canada Company’ is the lone descendant in the hierarchy of ‘US Parent’, 2,463.36 is the am ount 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 journal entries. The HFM journal journal process is a topic for a future blog, but understand that journal data is stored in a specific Value dimension journal entries have have member called “Entity Currency Adjust.” Here we see that journal 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 of Entity Currency Adjust). Adjust). This 100.00 gets added added to the 2,500.00 in Entity Entity Currency to give us 2,600.00 in Entity Curr Total. 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 value in Parent Currency Adjust. Adjust. The Value dimension does not not work that way. Entity Currency and Entity Entity Currency Adjust Adjust are first added together in the Entity Entity Currency Total triplet. triplet. The Entity Currency Total value is then translated translated to produce a value in Parent Parent Currency. Parent Currency Adjust is reserved for journals that are posted in the currency of an combined with Parent Currency Currency Adjust equals entity’s parent. Parent Currency combined 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 2,537.08 in Parent Currency, the amount in Parent Currency Total is calculated at 2,736.08 2,736.08..

There will be more to come on the other members of the Value Dimension, D imension, 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/201 http://www.performancearchitec ts.com/wp/2015/05/27/or 5/05/27/oracle-hyperio acle-hyperionn financial-management-h  financial-m anagement-hfm-the-valu fm-the-value-dimensio e-dimension-explained/  n-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, , , , , and are the pointers to the currency members. For example, if the entity and its parent's local c urrencies are HKD, the data will be stored in "HKD" member when input data in or translate data to . For the sub group rollup logic in Entity dimension, you can find the picture below. Sub Group's = Sum of the children Subsidiaries/Associates/Joint 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 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 EntityCurrAd EntityCurrAdjs. js.

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. EntityCurrAd js. 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 Contributio ContributionAdjs. nAdjs.

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, Elimination, and ContributionAdjs Contributio nAdjs 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 EntityCurrAd EntityCurrAdjs. js.

Note: If a parent is further consolidated into another parent, this sequence continues with step 5 from the child c hild consolidation sequence. sequence.

http://hyperioncenter.blogs http://hyperion center.blogspot.in/2014 pot.in/2014/12/hfm-value /12/hfm-value-dimension-a -dimension-andndrules.html 

The “subcube” describes the structure of data storage and retrie val in Hyperion’s Financial Management solution1 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 S UBCUBE 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 adjustments posted posted in the entity’s default 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 c an 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 fi eld 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/wpcontent/uploads/2013/05/Hyperion_System_9_Financial_Management_Subcub e_Architecture_0406.pdf 

About Subcubes Several Financial Management methods work with subcubes. A subcubes. A subcube consists of all the cells that share the same members of the following dimensions: dimensions: 







Year Scenario Entity Value

There are two types of subcubes—currency subcubes and subcubes and node subcubes. These 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 dimension members are as follows: 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

o

o

The triplet that poin ts to the entity’s default currency. This triplet consists of the , , and Value members. [None] Value member. Note: The non-node Value dimension members that point to parent entities’ default currencies —, , and —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: [Contribution [Contribution Total] [Contribution [Contribution Adjs] [Contribution] [Elimination] [Proportion] [Parent Total] [Parent Adjs] [Parent] o

o

o

o

o

o

o

o

This is nothing nothing more than Entity Entity Currency + Entity Curr Adjs. Adjs. It is the total local currency inclusive of adjustm adjustments ents and loaded/subm loaded/submitted itted data.

Parent Currency Next up the chain is Parent Currency. Currency. This member member takes total local currency 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. translated. Recall that Entity Entity Currency and Entity CurrAdjs 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. adjustments.

For the purpose of simplification, we will jump ahead to the Elimination Value dimension member. member. Though there are other Value dimension members between Parent Curr Total and Eliminat Elimination, ion, 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 can make anyone cringe when when it comes to data tie out or passing passing of data between systems. systems. Elimination Eliminationss 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 the appropriate consolidation 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 Elimination data if it just nets nets to zero? Valid question –   – if if it doesn’t net to zero, or if it zeroes out across levels, it is important to have have the detail to support support all of the activity. Enter the Elimination dimension.

To keep it simple, s imple, let’s say that Company A has a receivable from Company

B. Company B should should have the offsetting offsetting Payable on their books. books. That intercompany transactions 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 Company AB. This is where it will eliminate. eliminate.

Contribution Contribution represents what ultimately gets passed from child to parent. Keeping it simple, simple, it is equal to Parent Curr Total 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://platformspecialis http://platfor mspecialists.com/2015 ts.com/2015/03/30/the-real /03/30/the-real-value-of-co -value-of-consolidation nsolidations-ins-inhfm/