Dear FI/CO Expert,

    My question is in regard to changing the group currency in our SAP system. In our current FI/CO module (release 3.1I), we use NLG (Netherlands guilder) for one of our company codes as both the local (legal) and the second (group) currency.

    We are in the process of an upgrade to 4.6C. We have changed our corporate structure and with the global changes in the euro, I would like to change the group currency from NLG to euro. I have been unable to find any documentation that details what needs to be configured in the system or if this change can be made. Currently, the configuration will not allow me to change the field.

    Are you aware of any other companies that have had this issue with changing to the euro in the group currency?

Hi Gail,

Thanks for your question. We’ve all been frustrated at times by a grayed-out field in a customization screen. "If only the system would let me change this one value!" For our other readers, I’ve put an example screenshot of the transaction you are referring to in Figure 1. It is from an IDES client, so you don’t see a Dutch guilder setting. But it is clear that the Currency field in the second Local Currency section is gray and cannot be changed, even though you are in the Change view.

Figure 1

The Change View "Additional Local Currencies for Company Code" Screen

I have researched your question with our SLO (System Landscape Optimization, new SAP tools and concepts that deal with changes to productive R/3 systems) experts and have come up with the following answer to your question.

Unfortunately, there is no standard report or button for changing your second currency setting. However, using the SLO toolset, the second currency’s values that are currently stored in your G/L transaction tables can be purged and then rebuilt/recalculated for a new second currency, such as the euro. The process of rebuilding the second currency values would convert values from the first local (legal) currency of that company code to this new second currency using a fixed rate, and not with historical exchange rates. In your case, this should work, since there has always been a fixed exchange rate between euro and NLG (Netherlands guilders) since the inception of the euro.

The process requires expertise with the SLO tool, and the effort involved is highly dependent on the specifics of your system (database size, etc.). It will take preparation and a few weeks of tweaking and testing. It’s not as quick as clicking a magic button, but once finished, your "live" R/3 system will look and act as if the second currency setting had always been euro. As part of that process, you can use the SLO programs to also change your customization setting for group currency from NLG to EUR, so that all of your G/L postings going forward store the value of your debits and credits in euro as well.

Figures 2 and 3 are reminders of why synchronization between the FI customization setting and the FI transaction history is enforced by the system in the first place (via that grayed-out Currency field shown in Figure 1). Notice how the header data of an FI document stores the currency codes and how the detail (line item) data of the same document stores just a raw number that represents the value of those currencies. If you were to ever have in those database tables some FI documents for Company Code 2000 that had a second local currency of EUR and some FI documents that had a second local currency of NLG, your ability to run interpretable standard reports that show the total second currency values posted to a given G/L account would disappear. Some of the debits and credits in the BSIS table column called LC2 Amount (Figure 3) would refer to a header document Local Curr. 2 value of EUR (Figure 2), and some would refer to NLG. It’s the problem of apples mixed in with oranges, and the data in the standard report, as a result, would be meaningless.

Figure 2

An Example FI Document — Header Data

Figure 3

An Example FI Document — Line Item Detail Data

You have lots of ways to change customization and master data settings during a project implementation before the actual "go live" event. But once a system is productive, transaction data is being stored every day. The system sometimes does not allow changes to your design at that point as a way to protect data integrity.

Of course, the reality is that SAP R/3 is a business application, and business organizations change. Companies are bought, sold, and merged, and standards such as fiscal calendars and charts of accounts are revisited. In your case, a change in the European environment is prompting your company to revisit an earlier decision to set up a group currency in Dutch guilders. SAP R/3 does not come with a standard transaction or program for implementing that kind of a change to your FI customization.

In recognition of these kinds of issues, SAP over the past year or so has quietly assembled a group of internal and partner experts that specialize in this dilemma. The work they do is called System Landscape Optimization, or SLO. For more information or an opinion on how SLO might be able to help, you can contact me at the e-mail address shown in my bio. Or visit SAP’s SLO Web site at https://service.sap.com/slo. I have also put some information on common uses of SLO in the sidebar titled, What is SLO?