Quick How-To Guide: BPC Net Weaver Currency Conversion
Key Concept |
Referencing my blog post in SAP SDN this is a "how many licks does it take to get to the center of a tootsie roll" post. Many will think they know how something works, but you learn by actually doing. Refer to the Number 1 item in the above blog post and its translation Know by Doing! |
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 and its true requirements.
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 C_CATEGORY as delivered, checking the guide from SAP for this information is appropriate.
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 error is produced. The documentation shows the following:
*RUN_PROGRAM CURR_CONVERSION
CATEGORY = %VERSION_SET%
CURRENY =%RPTCURRENCY_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
OTHER = [ENTITY=%ENTITY_SET%]
*ENDRUN_PROGRAM
The form above would be best used in NON DEFAULT logic where in a data manager package, you pass the proper report currency set.
The form above would be best used in NON DEFAULT logic where in a data manager package, you pass the proper report currency 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 at all and moreover in Default Logic Calls it is not likely that you have requested the correct currencies for conversion in the Current View Scope! The proper form of the call to the program when in default logic therefore is:
*RUN_PROGRAM CURR_CONVERSION
CATEGORY = %VERSION_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
OTHER = [MYENTITYNAME=%MYENTITYNAME_SET%]
*ENDRUN_PROGRAM
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 need, but also have a few subsidiaries that enter data in LC to translate to, for example, USD because they are in some other currency like Mexican Pesos or Canadian Dollars, there are a few other features that need to be set in order to limit the currency conversion to just those entities required or more properly stated to get the program provided by SAP in the Net Weaver version to function as you wish.
The logic above still holds, but we must us the dimension member for ENTITY of 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. 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. This is a valid program concept from SAP. Understand it.
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 for those entities that require the standard LC to Reporting Currency conversion such as C_FX
2. Enter into the Entity Dimension property FX_TYPE a value for those entities that do NOT require conversion but are entered in the ENTITY CURRENCY such as C_NOFX
3. Establish for example the business rules for AVG as follows
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. AS_IS essentially ques the logic that this entry is in the entity or reporting currency. 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 a practical implementation causing clients to properly consider settings for limited currency conversion.
Richard Jabbour, C.F.A. is a senior FICO and BPC consultant with Tata Consultancy Services. Prior to this, he worked at Buckeye Technologies, helping implement complex data warehouses and business scenarios in SAP ECC. He has worked with several BI tools including SAP NetWeaver BW, SAP BusinessObjects, and is a certified associate consultant in BPC for NW. He has extensive experience in data modeling, design, configuration, and performance tuning having held many professional certifications in Oracle technologies. You may contact Richard via email at rbjabbour@bellsouth.net. |
Very useful information....
ReplyDeleteThanks a ton and have a nice day.
Paresh
Thanks a lot..saved my day...been strugling to get this
ReplyDelete