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.
