As far as I know, this is the easiest solution.
Another way to do that is to use taskflows or a 3rd party tool to schedule the translation of these entitites to USD or EUR.
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 believe that I interpreted your question on a different way. Can you please give us more details on your application? How you translate and consolidate for example is crucial for such answers.
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.
1 person found this helpful
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.
Hi All, you're right, PCA and CA must be avoided. We were just wondering whether there are other options we didn't consider yet.
Many thanks to everyone.