Hi friends!!!! In part I on FCTR we have seen the functional aspect of when translation reserve arises and how is it calculated. Now we will have a look at how to handle FCTR in HFM.
Identifying account is to be translated at historical rate
Storing historical rate
Calculating FCTR
Posting FCTR
There can be multiple approaches to handle each of the activity and I have seen diverse approaches seen implemented successfully. Some of the approaches were good while some were really confusing for a layperson to understand and even for many HFM resources it was a challenge to understand. So in the current discussion we will focus on approach on how to handle FCTR instead of how not to. Also please note that the current discussion is limited to HFM and does not cover FCCS. (FCCS has inbuilt capabilities for handling FCTR and can be understood separately).
1. Identifying account is to be translated at historical rate
There may be one or more account which needs to be translated at historical rate and there might new account added in future which may be required so it's prudent to have some mechanism which will be flexible and future proof.
I suggest to use UDA 'Hist_Rate' in accounts dimension to mark those account to be so translated. A member list can be created for all accounts for which the UDA is 'Hist_Rate'. The rule to calculate FCTR will run in loop for each member in the member list.
I also recommend to build a hierarchy to capture moments in the accounts and FCTR.
Eg. (Please note that this is an indicative hierarchy and can be different based on the client requirements)
Since each account will have its unique rates for each addition/deletion it will be required to captured to rate separately for every account. While some prefer to have a separate rate account for each account having historical translation, I prefer to have a Historical rate, say HR0000 - Historical-Rate, as a node in custom dimension (preferably where moment in the account are captured as shown above). Further children can be added to the Historical Rate hierarchy if there are different historical rates for addition of deletion during a single period.
Using custom dimension to capture historical rate will help in capturing rates for each account without creating account and it will be easy to retrieve and track historical rate for each account.
A data entry grid can be created for entering historical rates, for accounts having historical rate (use the member list created above) with Custom 1, 'For Currency' and custom 2 'To Currency'.
3. Calculating FCTR
In the current discussion I will not cover how to write FCTR rule but will discuss the logic how to calculate the FCTR in HFM. In the below example you will see how FCTR will be calculated based on the flow and rate accounts defined above. However you will observe that in the month of May and April the calculation gets complicated as there is an addition and deletion to the account. So different historical rates will be applicable to different amounts.
I suggest an alternative which is easier. Since we will be calculating FCTR for every period, the difference the EOM and Historical rate is already calculated and posted as FCTR. So for subsequent periods we require to do the following:
Calculate the difference between translated values at current EOM rate and previous period EOM rate.
Calculate Difference between translated values at EOM rate and historical rate for all addition/deletion during the period.
The total of above differences is the change in FCTR for the period and should be added or reduced from the previous period FCTR which is brought forward.
You can use difference in EOM rate for current period and previous period to get the same result as arrived in (h) below.
Please note:
Separate rates may be applicable for additions and deletions in the same period so have to be handled accordingly.
The previous period for which the EOM rates/EOM amount is considered will depend upon if the data is YTD or MTD. For YTD data the previous period will be always last period of previous year while for MTD data it will be the previous period of the same year (except for the 1st period).
All FCTR calculations will be at Parent Currency level and not at Entity Currency level.
4. Posting FCTR
Once the FCTR is calculated it will be posted in the accounts at Custom1 nodes as defined above, FCTR2000 (addition) or FCTR3000 (deletion) as the case may be. The previous period balances need to be brought forward using a rule (please ref the note above for previous period balance).
For posting FCTR you can create a single account FCTR or two account as FCTR_Assets, and FCTR_Liabilty and will be grouped in Liability/Asset or in passed through the Income statement based on the accounting policy of the client.
Based on the calculations above:
Any +ve FCTR on Assets account will have to be reduced from the asset account (-ve value in node FCTR2000 of the account) and added to FCTR_assets account, while -ve FCTR will be added to the asset and added to FCTR_Liability account.
Any +ve FCTR on Liability account will have to be reduced from the liability account (-ve value in node FCTR2000 of the account) and added to FCTR_Liability account, while -ve FCTR will be added to the liability and added to FCTR_asset account.
To achieve the above either the rule should multiply the amount by -1 before posting to FCTR2000/3000 or alternatively the node FCTR2000/3000 should me marked as 'Switch Sign' as 'Yes' in custom 1 dimension.
If a single account FCTR is defined it is suggest to be defined as account type Liability so any addition to FCTR_asstes account above will be deletion in FCTR account and vice versa.
I hope I am able to simplify one of the most complicated topic as far as possible. In the pursuit of keeping it simple I have not get in too much details but hope it gives you sufficient insight. In case you have any queries please do write to me and I will try to get back at the earliest possible. Till then keep consolidating J.