As I understand, the recommended setting for UsePVAForFlowAccounts is Y.
In this context, I have the following three queries:
1. I would like to understand, under which circumstances, should we have UsePVAForFlowAccounts as No - i.e YTD Translation for Flow Accounts.
2. In an application, (we have about 3 years of data), we have set UsePVAForFlowAccounts as N. I am evaluating a change in this setting to the recommended setting of UsePVAForFlowAccounts as Y. This is to address an issue of exchange differences arising for a period for which no transaction has happened, but a difference is coming because the exchange rate has changed between the reporting period and the prior period. What are the issues, or changes in load patterns, that I need to be aware of, before I go about changing the Metadata setting. Currently PnL data is loaded in YTD.
3. Are there any alternate options available - that is, handle it only thru Rules and not make any Metadata changes. For instance, changing my formulae in Sub Translate from Hs.Trans to Hs.TransPeriodic, for Flow specific accounts.
Below are the answer,
1. By not selecting the UsePVAForFlowAccounts, the P&L type account will translate using the default method(defaultRateforBalanceAccounts)
2. If Use PVA settings will be checked for Flow Accounts. This setting tells HFM to perform translations by using the Value at Exchange Rate (VAL) or the Periodic Value Method (PVA).
The PVA method takes the periodic value and multiplies that by the exchange rate for that period. It then adds this result to the translated value from the prior period. It does not change the exchange rate amount or look to the prior period for the exchange rate at all.
3. I am not sure about the third question.
I understand how UsePVAForFlowAccounts works.
Question 1, I had asked from a Design perspective. Under which circumstances, should we have UsePVAForFlowAccounts as No - i.e YTD Translation for Flow Accounts. I wanted to understand, for what business requirement, do we set the UsePVAForFlowAccounts as "No", when the usual recommendation is to set it as "Yes"
Question 2, I had asked from a Design perspective, as well as an end-user's data load (operational) perspective: What are the issues, or changes in load patterns, that I need to be aware of, before I go about changing the Metadata setting. Currently PnL data is loaded in YTD.
Question 3, I had asked from a Design perspective, to minimise impact of changing the Metadata - whether handling it thru Rules, would be less complex
1) The business requirement that you should focus on is to study on how it is done currently. Do the business users take the periodic P&L figures and multiply by that period's AVG rate or they do it on YTD basis? Also ask user what do they mean by AVG rate? If avg rate for USD/INR May 2012 is say XX.XX then you should ask if average rate is monthly average (May 1 to May 31 ) or yearly average rate (Jan 1 to May 31). normally, finance dept who use monthly average exchange rates will use periodic translations and those who use yearly average rate use YTD method. as you can imagine, periodic translation on monthly exchange rate will be a bit more correct translation (if you are talking of big figures and volatile exchange rate fluctuation scenario).
2) If you are using periodic translations than your data load will have to be of all months of an year. any month where data is not loaded, or any month where exchange rate is not loaded will impact all subsequent months. In YTD this problem is not there (Also depends of default frequency of scenario, has to be YTD). This situation (when subs/JV dont report at all for a month) may not be applicable for mature clients.
3) Change in metadata will impact all months and all years. If you have historical translated data and you do not want to change it, it is esier to manage through rules (put an If condition based on period > your cutoff time) and use TRANS and TRANSPERIODIC as appropriate.
Hope it helps.