Thursday, November 28, 2013

HFM Dimensions and Metatada

In this article, we shall first clear up a confusion observed frequently between HFM Dimensions and Metadata and explore their relationships. We shall close by examining a peculiarity of the Value dimension.

Note that all presented information refers to Oracle Hyperion Financial Management version or earlier.

HFM Dimensions and Metadata
When training people in designing or maintaining HFM applications, all too often there is confusion between metadata items and dimensions. It is probably because for the most part of the application design, we populate members in Entities, Accounts and Custom dimensions through using our metadata design tools, which seem to be in one-to-one relationship with the dimensions used and selected in the application.

It may be helpful to separate between the two by visualizing metadata as an abstract concept related to application design and dimensions as the incarnation of the design in a working application. One thing is for sure: there is no one-to-one correspondence between a metadata item and a dimension.

In addition, not all dimensions behave the same. The following table summarizes the similarities and the differences in nature and behavior of both metadata items and dimensions pertaining to an HFM application.

A common HFM application uses 12 dimensions. More custom dimensions may be added in newest versions of the software; still the 12 dimensions are the core. Our first observation then, is that the number of metadata items does not equal to the number of core dimensions (refer to the first column).

Second, there are no dimensions for Currency, ConsolidationMethod, SecurityClass and Alias. We could have also added the AppSettings item found in the classic metadata designer, still this is so obvious that this item does not relate to any dimension whatsoever.

Our third observation is that there are also differences in the degree that we can customize each metadata item. For example, while we can freely add members almost to any metadata item, though ICP, Value and View metadata items (and their corresponding dimensions) limit what we can do with them. We can add members to the ICP dimension only indirectly, by adding Entities and marking them with the IsICP flag.

In addition, there is no way to add members in the Value dimension directly. Though for each new member we add to the Currency metadata item, three new members appear in the Value dimension -e.g. by adding GBP in the currencies list, we get GBP, GBP Adj and GBP Total in the Value dimension.

Finally, the View metadata item can be customized only to provide with the strictly defined members YTD, HYTD, QTD, MTD etc. Here we are restricted to the keywords that we can use as well as to the number of members which must equal to the number of levels set in the Period dimension.

Next, we observe that not all dimensions support hierarchical structure and those that do, may not support hierarchical aggregation. Even though we can structure Scenarios in hierarchies, the members of those hierarchies will not roll-up to their parent. Even though Entities can form hierarchies which aggregate, the aggregation calculations are performed only when consolidation is executed and they are dictated by the consolidation rules logic.

ICP and Value dimensions form fixed structures that cannot be customized. In addition the Value dimension has a complex hierarchical aggregation, whereby adjustment members are dynamically added with their corresponding members, while other members like <Parent Currency> and [Proportion]/[Elimination] are populated by executing translation or consolidation logic.

Value - Is it Really a Dimension?
Finally, I should mention another important peculiarity with HFM dimensionality. Value is not a “real” dimension. It behaves like a normal dimension as regards a single entity. However, when we roll-up to parent entities, it stops to behave like any other dimension. For example, consider a custom dimension member; let's call it Road bikes being part of the Total Products hierarchy in Custom1.

When you input a number in the Road bikes member in the Entity NY, you expect that this number will be part of the total found in the Road bikes, of the parent entity US.

Now consider the Value dimension, part of it is shown below:

When you post an adjustment to the <Entity Curr Adjs> member in the Entity NY, it will not be part of the <Entity Curr Adjs> member in the parent entity US. Instead, the adjustment number will be part of the total in the <Entity Currency> member of the parent entity. What you should keep in mind from the above discussion is that the Value dimension limits its behavior as a dimension within a single entity.

You can find more detail on how the value dimension works in a fine article here:

A Final Word

As mentioned above the present article refers to versions of HFM, earlier than In we have a few changes related to our discussion worth mentioning:
1. A new metadata item has been added corresponding to the cell text
2. The core dimensions have been decreased to 10, leaving Custom3 and Custom4 out of the core. It would not make sense to also leave Custom1 and Custom2 out as well, since they hold the currency members which hold the exchange rates.

Special thanks to Thanos Antzoulatos for reviewing and commenting on the above content.

No comments:

Post a Comment