As discussed in previous articles (see references at the end of this post), the HFM Value dimension is a special dimension displaying unique behavior, which facilitates the transformation of financial numbers of entity level financial statements, to those numbers contributing to the parent entity. This transformation occurs in several steps, involving adjustments, currency translations and consolidation/elimination calculations. Each transformation step is represented by a specific member in the Value dimension.
The Value dimension is said to be a system dimension, which means that the HFM application designer cannot change or add members. With an exception: for each currency added to metadata, HFM automatically adds three members in the value dimension. Suppose for instance that we create a currency named XXX in metadata. HFM automatically creates the following members to the value dimension:
Now, lets see what happens to the next level of the Value dimension. To see how it works, we'll use two more entities B and C. Both entities are supposed to be parents of A, which means that entity A is shared as a child to both entities B and C. We need to use two parents in our example to show the difference among parents of the same or different currency. Assume that entity B's DefCurrency property is also XXX, while C's DefCurrency property is YYY.
When referring to the <Parent Currency> member of the Value dimension, HFM needs us to specify which parent it is about. If we choose B as the parent (or select the entity B.A in HFM), HFM resolves the member <Parent Currency> to XXX. Therefore, in the case of entity B having the same DefCurrency property as entity A, HFM does not duplicate the value, but resolves both Value members <Entity Currency> and <Parent Currency> to the same member XXX. The same is true for the Adjs and Total members of the angle bracketed Value members.
An interesting observation is that the Journals module of HFM does not resolve currencies the same way. Namely, if we select <Entity Curr Adjs> in Manage Journals, the list contains journals related to functional currency of all different entities without any concern what those currencies are. To exhibit how the Manage Journal works, consider creating a journal on A in <Entity Currency>. If we post this journal, we can observe the posted numbers using a data grid and find the same numbers in both <Entity Curr Adjs> and in <Parent Curr Adjs> which means both resolve to the XXX Adjs Value member.
However, if we select <Parent Curr Adjs> in Manage Journals, the journal is not there!!! Similarly, if we chose to post the same journal to <Parent Curr Adjs> in Manage Journals instead of <Entity Curr Adjs>, the journal would exist only in the <Parent Curr Adjs> realm of Manage Journals. Still, when posting the journal, the effect would be exactly the same as before: the numbers should be seen in <Entity Curr Adjs>, <Parent Curr Adjs> and XXX Adjs, keeping in mind that HFM does not duplicate data.
Now, lets see what happens if the parent entity is C instead of B. C's DefCurrency property is YYY, so the entity C.A combined with <Parent Currency> resolves to YYY. This Value member is initially empty, until currency translation is run. After running translations, YYY contains the result of the execution of translation rules and can be viewed whether choosing <Parent Currency> or YYY directly. This means that HFM stores <Parent Currency> values separately only for parent.entity combinations with different default currencies. Note that the numbers translated by rules before being stored in <Parent Currency> are those in <Entity Curr Total> or XXX Total Value member.
It easily follows that for C.A parent-entity combination, adjustment members are separate members as well: <Entity Curr Adjs> resolves to XXX Adjs while <Parent Curr Adjs> resolves to YYY Adjs.
Conclusion
In this article we have exhibited that the angle bracketed members of the value dimension are not "real" members or placeholders for saving values, but rather they are dynamic names resolving to the real members representing actual currencies.
We have also seen that in Journal terms, the angle bracketed Value members <Entity Curr Adjs> and <Parent Curr Adjs> are separate locations for storing journal entries, irrespective to the actual members where data is stored when individual journals are posted.
References:
..Value dimension
HFM Dimensions and Metatada
