I would like to translate consolidated results in two different currencies. Let's say, for example, USD and EUR.
Do I need to create two alternative entity hierarchies whose parents def currencies are USD and EUR? Is there any other possible solutions?
Any customized solution would do the job... even if highlight me main technical choices, avoiding to disclosing details of your implementations.
It's very useful to us because we wish to would like to maintain the opportunity to post Contribution Adjs.
You mean to schedule the run the standard translation routine?
But I think this would not solve the problem because:
1. Translation routine will not involce Contribution Adjs --> we'll need to duplicate them
2. Standard translation will not split Currency Translation Reserves between Group and Minorities.
Did I correctly got your point?
I will better explain my request:
No Org by Period app; YTD consolidation
Sub translation manages the convertion applying average YTD rate, opening or closing rate. Some accounts are translated at historical rate. Translation also manages the calculation of the currency translation reserve in equity.
Consolidation manages the split of equity reserves between minority and group shares. This split involves also the currency translation reserve, by debiting the "Currency Translation Reserve" account and crediting the "Currency Translation Reserve - Minority Share" account.
Users need to analyze contribution of each single legal entity (including the split effect) both in USD and EUR. In order to properly translate and consolidate figures the quickest and most reasonable solution would be that of creating two alternative hierarchies (one in USD and in EUR). However this turns into headakes when you have to post Contribution Adjs as these must be posted twice, one time in EUR and the other time in USD.
My question is:
is there a customized approach that allows me to avoid redundancy in posting Contribution Adjs and also reduce the number of alternative hierarchies? Have you ever faced similar issues? How did u solve them?
Many thanks again
We had this same challenge. We used the alternative hierarchy approach as you describe above. Contribution Adjs must be posted to both trees unfortunately because the contribution adjustment is node specific. The question we asked is why are these contribution adjustment entries necessary? If the system is performing the translation/consolidation logic correctly, it should not be necessary. We were able to eliminate all need for these entries through these discussions.
Could I suggest listing out the underlying reasons these contribution adjustments are necessary.
Based on the details, you need to create an alternative hierarchy. On main point is that you should make sure that you have the correct data for the translations in both currencies. For example, if you have historical rates at USD, you will required to find historical rates at EUR too.
As Hyp201207 said, it is usually not advised to created Contribution Adjs journals. I will add that it is not also suggested to create Parent Curr Adjs journals. If your translation is correct and assuming that you have developed correct consolidation rules for the calculation of non-controlling interest, you will need only the Entity Curr Adjs journals. The main reason is that Contribution Adjs journals are posted on the node while the Parent Curr Adjs journals are posted on the currency of the parent entity. This means that you may have to post duplicate Parent Curr Journals too.