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:

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.