Skip to Content

When implementing RTC one of the fundamental decisions when modelling the consolidation model is what Currency Conversion method will be used. 9 out of 10 people approaching me to talk about RTC will have questions about the currency translation. In this post I will try to highlight the options and differences between them.

Currently RTC support three options for currency translation:

  • BPC Currency Translation
  • S/4 RTC Currency Translation
  • Accounting Currency Translation

 

BPC Currency Translation

In BPC Embedded, Currency Translation in is pretty much the same as BPC standard with the only difference being the execution: It is triggered only via Consolidation Monitor through a Task Sequence. Business Rule wise, is absolutely the same.

The RTC model with BPC Currency Translation will generate 5 calculation views:

  • 2 views from ACDOCA –  Universal Journal – Accounting
    • View 05 – FINAL version
    • View 07 – PRELIMINARY version
  • 3 views from ACDOCC – Consolidation Journal
    • View 06 – FINAL version to read actuals entered via Flexible Upload
    • View 08 – PRELIMINARY version to read actuals entered via Flexible Upload
    • View 09 – Consolidation Results (Manual and Automatic) for both versions

The difference between these views is that the FINAL version view will perform a check in the raise data submit request.

All first 4 views above will select HSL – Amount in Company Currency and hard code the currency as “LC” so BPC business rule can function as usual. This is absolutely fine for Legal Consolidation, however for management models this might not be the correct amount field as some organizational objects will cross company codes. An alternative for such cases is to rename one of the other amount fields that will have a consistent currency such as Group Currency or Controlling Area Currency to HSL in the foundation view.

Interface: Consolidation Monitor

Different from BPC standard where the user can specify the scope of the translation, such as the translation of specific accounts, via consolidation monitor only Group, Entity, Period and Version can be selected.

Rates: In a BW Info Provider

Translation Rules: In BPC – Business Rules

It allows the same workarounds as in BPC standard such as using flows to calculate FCTR.

Exchange Rate Type defined by GL in the RTC GL account extension – t-code: RTCGLA – Maintain Accounts – BPC Integration

FX Type maintained in the RTC entity extension – t-code: RTCENT – Maintain Entities 

 

S/4 RTC Currency Translation

With RTC a new Currency Translation tool was introduced. The S/4 RTC CT will read the data from ACDOCA and post the unconsolidated translated result to ACDOCC. Different from the BPC CT the RTC CT will be configured and performed in S/4 via transaction code.

With this option the system will only generate only 3 HANA calculations views, all 3 of them fetching ACDOCC data:

  • FINAL (View 10) and PRELIMINARY (view 11) and Consolidated results (View 09).

This is because when using the RTC CT, the translation result will be posted to ACDOCC with not only the Group Amounts but also the Local Currency Amounts, making ACDOCC the sole source of unconsolidated data.

Interface: Via t-code RTCCT – Currency Translation

Rates: From TCURR – No duplication of rates

The exchange rate types are selected from S/4. Remember that RTC is about accessing master and transactional data real-time from accounting, with this option, rates will also be leveraged from the same repository used by accounting without duplication.

Translation Rules: Via RTC configuration transaction codes.

A number of configurations are required to define the RTC CT:

  1. Define the Define Exchange Rate Indicator which is selecting the rate types in accounting to be used by RTC
  2. Define selections. In here you can define different filters for different currency conversions, e.g.: select Equity Accounts, P&L Accounts…
  3. Define Rounding Method, to remove rounding differences caused by the system.
  4. Define the Currency Translation Method – to bound all definitions in the previous points in create the translation entries.

Currently there are 5 different translation keys to support CT:

 CT Key Name Description
01  Using YTD amount Translation of cumulative amount at rate for current period
03 Using historical amount in invest. table Historical transaction using changes in investments
04 Using historical amount in equity table Historical transaction using changes in investee equity
05 Using current period amount Translation using the monthly rate in the exchange rate table
06 Using existing group cur. amount No retranslation of existing group currency value

 

Accounting Currency Translation

A third option has been released with note: 2554579 – Real-Time Consolidation Model Enhancement for Reusing Translated Group Amounts in ACDOCA

This note will allow you to re-use already translated amounts to group currency in FI for Consolidation.

This is extremely important given that in S/4HANA you can perform parallel translations at transaction level, at the same time that it would also eliminate any possible differences caused by different translation methods or exchange rates. Bear in mind that the consolidation process is also simplified as it eliminates the Currency Translation step. When executing Consolidation and Elimination business rule BPC will read the Group Amounts straight from ACDOCA (accounting data) and ACDOCC (flexible upload).

One particular thing about this option is that BPC CT can also be used, for Flexible Upload entities, consolidation manual adjustments etc.

In terms of calculation views generated, it will be the same as when using BPC CT, with the difference that it will map:

  • KSL – Amount in Global Currency as CONSL_SL – Amount in Group Currency
  • RKCUR – Global Currency as CONS_CUR – Group Currency

In cases where the group currency in accounting is stored in a different field, in the foundation view this field needs to be renamed to KSL.
E.g.: In a system where the Group Currency Amount is stored in OSL – Amount in Freely Defined Currency 1, in the foundation view rename:

  • OSL to KSL and
  • ROCUR to RKCUR

It is important to understand a few things when implementing this option:

  1. If you are planning to use Flexible Upload, make sure the data loaded is already translated to Group Currency (CONS_SL and CONS_CUR). Otherwise BPC CT would need to be executed for the submitted entities .
  2. If you have manual adjustments (journals) in Currencies other than Group Currency, BPC CT will need to be used.
  3. Make sure the Group Amount field is populated throughout the month, so Preliminary version consolidation can work. After period end, this can be re-valued at end rates.

 

Wrap up

Although all 3 options deliver the same outcome, each option will have pro and cons. It is important first of all to understand what is important for the Group Accountants, flexibility on defining rules, performance, consistency…

I personally like the accounting option because it leverages FI (a proven and stable functionality) and simplifies the consolidation process while keeping consistency across the financial landscape.  Additionally I believe the future is moving towards bringing consolidation to source, so by doing group CT in accounting, you will be jumping one step towards it.

 

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member

    Hey Lucas, a great blog post!!

    I had couple of important questions on both currency translation approaches classical and S4 Hana and even now the 3rd option is available with Accounting numbers in group currency.

     

    Translation in S4 Hana

    1. How will RTC get the following exchange rates values ?

    How system will get 1001, 1002 and 1003. Is this to be maintained manually? or any program will be available which will be calculating closing rate for month and average rate for the month and updating these rates? In S4 hana or even traditional ECC, we maintain M rate type with daily rate and then use a Z-program to calculate monthly closing and average rates for BPC. Now since we will be storing rates directly in rates table, so will these rates be directly maintained ? or there is any standard sap program which can do that?

     

    Translation in BPC Layer

    2. Historical Translation for Equity and Investment

    For Translation by historical rates we can either use historical rate or historical amount in group currency to calculate the difference.In case of S4 hana an option is available to store historical amounts for both equity and invesments.

    But in case of classic, how can we get group currency number from S4 hana in case of classic, as I don’t want to run extraction and perform validation like classic BPC. Do we need to create a new view and add in source infoprovider (may be using virtual provider)? or how do we get accounting numbers available in group currency for historical translation?

    Thanks

     

     

     

    (0) 
    1. Lucas Costa Post author

      Hi, when using the S/4 RTC CT the rates will be read from S/4 – you can check the exchange rates via OB08. Conceptually M type should not be used for consolidation. This is a daily rate used for operations. I recommend creating specific rate types for consolidation and maintaining it accordingly.

      For BPC CT you won’t be able to read the historical balances using RTCAFD

       

      (1) 
      1. Former Member

        Thanks Lucas,

        That sorts it. So for S4 hana translation user will have to maintain monthly rates .

        For historical translation in classic approach, some manipulation will have to be done to fetch historical numbers.

        Regards,

        Rakesh

         

         

        (0) 
  2. Krishnendu Pal

    Hi Lucas

    Thanks for the lovely explanation. Under what circumstances, a client will go for S/4 RTC Currency Translation, instead of Accounting translation?

    Hope, even we choose the mode 0 or mode 1, we still can load Functional currency (local currency) in RTC BPC for classification purpose, even though the LC data will not be used for any consolidation purpose.

    Appreciate your response.

    Regards

    Krish

     

    (0) 
    1. Lucas Costa Post author

      Usually, you’d use the RTC or BPC CT if you do not have the currency reval process in S/4 or if you have entities not in S/4.

      That’s by design (the LC) and to be honest I never liked it, because it can lead to errors as the “LC” is assigned to an entity, and this can be changed – there are no system restraints against changing the currency assigned to an entity. Furthermore, I had a situation where my entity was Profit Centre and in the group, in particular, PCs were cross-company codes – which could have multiple currencies, meaning the result in LC from the HANA views were aggregating multiple currencies amounts…

      (0) 
  3. Krishnendu Pal

    Thanks, Lucas. I think another reason can be if we want to make any FLOW correction in BPC at LC level, then we have to CT in BPC. If you have CT in RTC, can we leverage the features to perform CT when we make some changes in LC in BPC?

    But if in the RTC data model has the Company code and Profit Center(As matrix consolidation in 1709), the company code dimension will drive the local currency and the line item will look as below

    COCD1    PC1   TRADING PART  PPARTNERPC  LC (GBP)   ACCNTx    1000

    COCD2    PC1   TRADING PART  PPARTNERPC  LC (USD)   ACCNTY    525

    We can’t have a roll-up view by Profit Center but will have a roll-up view by company code.

    Yes, you are correct, if you see the above purely by Profit Center, then we are rolling up multiple Local currencies.

    Regards

    Krish

    (0) 

Leave a Reply