HFM typically does currency translation when the parent entity and the child entity have different currencies. A hierarchy for a division may go up through several levels before translation occurs. The problem is users want to see the lower level entities in the translated currency even though the hierarchy says no translation should occur.
HFM offers users the manual ability to set the value dimension to the desired currency and then use an action aptly named "Translate" to run the translation. But users must remember to do this every time the data changes. Doesn't really work well if users forget.
A traditional approach, going back to HFM's predecessor products, is to create an alternate hierarchy, full or partial, with new parent members that are all the desired currency. Like this:
This worked well, as users would just consolidate both hierarchies after data changes (usually have a single "dummy" parent at the top that consolidated all hierarchies underneath). But there's a big problem in that users have to change the entity, like going from RegA1 to RegA1_KYD.
So, what to do? A better approach is to create a parent entity with the desired currency and then add all needed entities directly to the parent - no hierarchy, no new entities. Like this:
Can still use the single "dummy" parent to make consolidations easy. With this approach, the consolidation of KYDTranslations forces the translation of each child entity to the desired currency. To avoid any confusion, change the consolidation rule to not run if the parent entity is KYDTranslations, as any number there is meaningless and not needed.
Best of all, the users don't have to change entity labels - they can view RegA1 in either EUR or KYD just by changing the value dimension.
HFM offers users the manual ability to set the value dimension to the desired currency and then use an action aptly named "Translate" to run the translation. But users must remember to do this every time the data changes. Doesn't really work well if users forget.
A traditional approach, going back to HFM's predecessor products, is to create an alternate hierarchy, full or partial, with new parent members that are all the desired currency. Like this:
This worked well, as users would just consolidate both hierarchies after data changes (usually have a single "dummy" parent at the top that consolidated all hierarchies underneath). But there's a big problem in that users have to change the entity, like going from RegA1 to RegA1_KYD.
So, what to do? A better approach is to create a parent entity with the desired currency and then add all needed entities directly to the parent - no hierarchy, no new entities. Like this:
Can still use the single "dummy" parent to make consolidations easy. With this approach, the consolidation of KYDTranslations forces the translation of each child entity to the desired currency. To avoid any confusion, change the consolidation rule to not run if the parent entity is KYDTranslations, as any number there is meaningless and not needed.
Best of all, the users don't have to change entity labels - they can view RegA1 in either EUR or KYD just by changing the value dimension.
