Skip to Content

Key Concept

The platform for BPC has changed at a rapid rate.  Many are not growing with the toolset and remain locked in old style currency conversion scripts.  Too, many have not used the business rules effectively to produce the kinds of results they want.  Certainly entering data in a currency other than Local Currency (LC) and desiring that currency be translated into LC from some input is not within the scope of this guide, but we will address that in a later post.

What clients need to know is how something really works in plain English.  This tip guide gives you some insight into the script form for currency conversion, and this guide explains how FX_TYPE is used for limited currency conversion and its true requirements.  While not purely a how to guide it is more informative as a “you need to do it to know” demonstration than just a pure how to.

See the Currency Guide Here.

I offer 3 tips for getting you started using business rules and currency conversion in a couple of the basic standard ways.

Tip 1. Understand The Basics

The application documentation and the dimensions provided by SAP in APSHELL produce an accurate view of the properties required in the ENTITY, ACCOUNT, CATEGORY and DATASRC dimensions as well as the core structure of the RATE application.   Except that one must focus on changing the category dimension in the delivered RATE application to the C_CATEGORY as delivered, the guide from SAP for this information is appropriate and the information there is complete.  In SP06 of NW 7.5 you also need to review the spelling of STORED_CALC in the Inputcurrency dimension.  It is delivered mis-spelled.

Tip 2. Understand the Logic

The Logic for running currency conversion has long since been in a stored procedure in the Microsoft Platform.  Many do not know how to use that.  Many remain on the advanced script logic delivered by Outlooksoft in version 5.1 and prior for currency conversion.

There are a few different forms of currency conversion logic in Net Weaver.

The first form seems to produce the most forum posts where people are always wondering why “LC” Member Not Exists (the error from SAP as it appears) error is produced.  The documentation shows the following:




      TID_RA = %TIME_SET%




In plain spoken English, the ABAP or stored procedure version of rate logic takes the LC entry provided, examines the account to which data is to be posted for the RATETYPE, looks to the business rules for that RATETYPE and converts by default to the currencies marked as reporting currencies in the RPTCURRENCY dimension. 

Most people copy and paste this into the logic for FX and wonder why it does not work in default logic calls.  It does not work first because unless your ENTITY dimension is named ENTITY you need to supply the correct name.  Secondly, in order to get conversion to ALL the report currencies in the RPTCURRENCY dimension, you do not pass the parameter CURRENCY.   Attempting to pass the currency parameter in default logic is what leads to the error above.  The proper form of the call to the program therefore is:



      TID_RA = %TIME_SET%




The above can be in FXTRANS.LGF and can be referenced from DEFAULT Logic and it will execute properly.

Tip 3. Limited Currency Conversion Equivalent

Many organizations continue to desire to enter plan data in a direct single reporting currency member like USD or EUR.  In this case, there is no need to translate to other currencies because the entered currency is the reporting currency.

For organizations that have one single reporting currency who engage in this process but also have a few subsidiaries that enter data in LC, there are a few other features that need to be set in order to limit the currency conversion to just those entities required.

The logic above still holds, but we must us the dimension property in ENTITY called FX_TYPE to control this process. 

The standard behavior of currency conversion expects LC to be entered.  If one does nothing but installs the program call in FXTRANS and Default logic, an entry in NON LC currency members will result in an immediate offsetting negative amount negating the entry.

Why?  Because SAP has built in the assumption that YOU have made a mistake.  They have assumed you have left open the dimension RPTCURRENCY in the current view and that a user was able to change from LC to some other currency.

What SAP would like you to do is OVERTLY allow for this concept.  Here is how.

1.      Enter into the Entity Dimension property FX_TYPE a value such as C_FX for those entities that require the standard LC to Reporting Currency conversion

2.     Enter into the Entity Dimension property FX_TYPE a value such as C_NOFX for those entities that DO NOT require conversion but are entered in the ENTITY CURRENCY

3.     Establish the business rules for AVG as follows

Currency Conversion

4.     Note the line for Formula [AVG] will apply to those requiring conversion with property FX_TYPE in ENTITY equal to C_FX

5.     Note the line for Formula [AS_IS] which will apply to only those Entities with FX_TYPE equal to C_NOFX.  Those not marked but entered in the ENTITY CURRENCY will FAIL by producing an equal but opposite signed entry immediately on conversion.  The client should be aware of this basic behavior.  We do not expect this to change even though it is not adequately documented.  It is better to continue to cause clients to fully understand the decisions they are making with regards to currency conversion.

To report this post you need to login first.


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

  1. Former Member
    Excellent Blog! Nice job Richard. You’ve explained clearly about the missing info in SAP HTG. However, I had a quick question about using the historical rate. Suppose I have the transaction data in LC for 2011.JAN and I want to convert them using the exchange rate of 2010.MAR. How can I achieve that as I believe the logic above looks at the exchange rate based on the Time period for the entered actuals? Please explain how we can apply the historical rate on the current actual.
    Also, is it necessary to share the time dimension between RATE and Financial application?  Can we have P_TIME (Quarter Level) in the financial planning application while RATE application has TIME (Period Level)?
    1. Former Member Post author

      The historical rate normally associated with a BALANCE in Non Current Assets for example has to be carried forward in the rate model to each successive period.  This also often requires the use of the FLOW dimension.  So you would carry say…the year end balance of a fixed asset in Opening Balance for the new Year….and carry the historical exchange rate of that to group currencies / reporting currencies.   For new acquisition or additions to that fixed asset, they would be translated at the current rate of the period resulting in the blended ending balance.  The result is a NEW BLENDED historical rate to carry forward from, that period on.  This is complicated.  More often than not, companies will have these amounts translated prior to being in BPC and simply translate them AS IS during the consolidation or reporting process.  While Complicated as a business process, I prefer the former as it is more accurate from an Accounting perspective, but it comes with baggage…like historical rates per ACCOUNT….can be a result of this approach.    But in short unless you NO TRAN the accounts in question, you have to do something.  Otherwise you can add properties to dimensions and create your own historical rate conversion script based on the “old” style of currency conversion.  With some thinking and creativity you could do that…..many ways to go as always….but remember your end client has to OWN the business process you create so make it a BUSINESS PROCESS and not an IT process….thanks


Leave a Reply