Oracle HFM - Value Dimenstion and its Mechanism

Value Dimension and its Mechanism

Purpose

The Value dimension is not used for a single purpose. The three purposes that I have identified are:

It is used to store and identify the different types of data within HFM (Data and Journals)

It is used to translate the values from local currency to parent currency and eventually calculate the contribution to the parent entity.

 Finally, it is used to maintain all the foreign currencies that the application can support.

Structure

The Value dimension is a system defined dimension. The Value dimension members are:

The member Entity Currency (EC) is used to input data in local currency.

The member Entity Curr Adjs (ECA) is used to post journals in local currency.

The member Entity Curr Total (ECT) is used to aggregate the previous members.

The member Parent Currency (PC) is used to translate the data from the default currency to the parent currency. This means that if the parent entity has a different currency from the child, the value of ECT will be translated into Parent Currency. In order to trigger the calculation of the PC, the entity should be active in the ownership management.

The member Parent Currency Adjs (PCA) is used to post journals in parent currency of the entity. The journals in PCA are not linked with the parent entity but with the currency of the parent entity. This means that in case that you have a base entity with two different parent entities which have the same currency, when the users post a journal in the PCA, the journal will affect both the parent entities. If there is a parent with a different currency, the specific parent will not be affected.

The member Parent Currency Total (PCT) is used to aggregate the previous members.

The member [Parent] is used in a similar way with PCT. The difference is that technically, the [Parent] member is related with the node and not with the entity.

The member [Parent Adjs] is used to post journals on top of the [Parent] member for the specific node only. Parent adjustments are available only for parent entities for which the AllowAdjFromchildren application setting is selected. Consider two members in the entity dimension "A" and "B" now both these members have a child as "C". Where "C" is the shared member. Now if you pass a Journal at of "C" then this journal entry has an effect on both the parents "A" and "B". Whereas if you pass an entry at of"C" then you can also select the parent which you want to get affected by the same.

The member [Parent Total] is used to aggregate the previous members.

The member [Propotion] is used to store the contribution of the entity to the parent entity before the elimination. At this point, consolidation rules will apply. Depending on the set of consolidation rules, the application can store the whole number of the [Parent Total] or only a proportion of the [Parent Total] in [Proportion] member.

The member [Elimination] is used to store the data that will be eliminated during the calculation of the entity’s contribution to the parent entity. If the application does not support any consolidation rules, the [Elimination] member will only store the intercompany data that should be eliminated at the first common parent level with the intercompany partner entity. However, if the application supports more complex consolidation rules (like calculation of minority interest), the [Elimination] member can also store any data that will be used for calculating the consolidation journals.

The member [Contribution] is the sum of the previous members.

The member [Contribution Adjs] is used to post journals for the specific node in order to change the data after the completion of the consolidation rules. These adjustments are available only for parent entities for which the AllowAdjFromchildren application setting is selected.

The member [Contribution Total] is used to aggregate the previous members. This is the value that will be aggregated to the parent entity. The data from [Contribution Total] of all the parent’s children entities will be aggregated to the of the parent entity and the process will start again.

Finally for every currency that is added in the system, the system will create 3 value dimension members. If the currency has the label ABC, the system will create the members ABC, ABC Adjs and ABC Total.

Mechanism :

The data in the Value dimension can be either related with the entity or with the node or can be calculated on the fly.

The data stored at members EC, ECA, PC and PCA  are related with the entity and are common for all the parents with the same currency.

On the other hand the members, the data stored at members [Parent], [Parent Adjs], [Proportion], [Elimination], [Contribution], [Contribution Adjs] and are related with the node of the parent entity and the entity and are not common for all the parents. This means that a value stored in any of these members is unique for the combination of the parent entity and the entity. If an entity has two parents, the user must consolidate both the parents in order to populate the value members [Parent], [Parent Adjs], [Parent Total], [Proportion], [Elimination], [Contribution], [Contribution Adjs] and [Contribution Total].

Finally, the data presented at members ECT, PCT, [Parent Total], [Contribution Total] are not stored at the entity or node level but these are calculated on the fly.

In order to visually identify the different levels of storing the data, the value members that present the data on entity level are marked with angle brackets “< & >” while the members that present the data on node level are marked with square brackets “[ ]”

In the graphs, the black circles represent value dimension member in which data can be inputed, posted or created by calculation and consolidation rules, the grey circle represent the value dimension member in which translation rules are applied and finally the white circles represent aggregation of previous members.