I have issues with currency translation.Suppose 3 level entity hierarchy
Problem 1) Not able to get the first year(HFM application) translated opening(custom1) balance correctly because
it is not possible for us to calculate/get the exact rate to use for translation say from usd to sgd(parent).The reason is
These companies existed from last several yrs(say 20 yrs) and accounts traslated for these yrs at different rates.
If we translate this account with last yr closing rate(=opening rate) the financials are not matching for reason stated above.
So do we need to post unbalance journals for all accounts(A#account.C1#opening) for first yr of HFM application to match the
acounts with their already published results.
Problem 2) Before HFM implementation client used to translate usd entity directly to inr(grp) using excel.
But in HFM we had to consolidate as the hierarchy shown above.But we do not have rates to translate usd --> sgd and
then sgd to inr?Specially getting this done for HFM application first fiscal yr is very complex because of prolem 1)
Edited by: hyp big bee on May 17, 2013 12:32 AM
I assume you only talk about equity and investment, because BS closing balance should usually be converted @closing rate and IS @average rate.
For Equity, I would suggest that you create a filed in the MD, which is open for each equity account. There you enter the correct historic rate and you write a rule to use this rate for the conversion.
I am afraid this is not the case.Let me try to rephrase the issue. Companies are operating from say 1990.HFM application first yr start from 2010 whre we load closing data into additions member of 2010 so that we get opening of 2011.Now during conso and translation we usually donot have exact rates to be used.If we use say closing rate for bs translation the consolidated output will not match with the published figures. The reason for this is that from last 20 yrs different additions to the assets happened at different rates so there is no direct possible rate for 2011 opening to be translated(translating by closing rate will not give correct output).
ok, sounds like the usual fun of historic data migration :-)
Still I think that from an accounting perspective this is weird, because no matter what, a bs item should finally be converted at closing rate. Would you then in 2011 calculate the difference between the weird rate on the opening to the current closing rate as an fx differential to have CB 2011 at the corret rate or are you planning to carry this forward forever?
Anyhow, I could image 3 solutions:
- if you have 1 (strange) rate per entity, you can also enter the rate on the entity and it will overwrite the rates reported on entity [None]. The POV is the same, i.e. A#ClosingRate.C1#EUR.C2#CHF. No rules adjustement is needed, HFM detects this automatically.
- if you need to have a different rate per account line within one entity, you could create an element in the custom dimension where you enter the rate per account and then consider in the rules that it takes this rate if filled and the usual rate if nothing is entered on that element
- if it is a some kind unexplained difference from historic consolidation, you could also put it as a central adjustment in a journal. Therewith the regular system conversion would be working properly and you the effect singled out.
You could also combine the three effects above sequentially.
The issue has following relevant points:-
This issue is only specific to first year of HFM app.Later years, normal translation is done and difference is stated in Exchange diff account.
Identifying this weird rate for all accounts requires lot of backtracking(dividing published figures by current closing) and time taking considering budget and timelines.Also applying
different rates is not possible by custom dimension as suggested in option2 because this is not allowed in HFM.
option 3 is not possible because the aim is to match individual account values and not BS validation.
option 1 can only partly solve the issue .
This problem is generic and others must have faced it.
One option i can think of is to post <parent currency adjs> to all base level account opening balances (unbalance journal) to match it to publish figure.But i would like to be sure that i am in rite direction
Booking a journal is equal to solution 3. Having it per entity or on group level is only a question of granularity and efforts invested.
What is the problem with recording the rate in a custom dimension. Why should this not be allowed? You can enter a rate anywhere in the system, you only need to create a rule afterwards to get the (HS.GetCell) and create a rule to apply the rate. This is a very common approach.
If you are interested, you can email me under email@example.com and we can have a more detailed discussion including maybe a precise example.