Logic used in Rate App doubt

[Former Member]

Hello Everybody,

I´m using the Rate Application for currency conversion but i still dont understand the logic applied when we run the FX_trans calc, i have 2 Business Rules one for Average and other for . Does anyone knows whats the logic applied? i need to understand this in order to get the value i want when a charge the different rate types.

Thanks in Advance

Nidia

[Former Member]

Hi,

Please refer to the below link from SMP to understand the currency conversion.

https://websmp210.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000726400&_SCENARIO=011000358700000002...

Hope this helps.

[Former Member]

Thanks for your responses,

Maybe i need to explain better. I´m using BPC for Microsoft v7.5 SP4 and configured all the dimensions, properties, Business Rules and Fx_trans.lgf as shown : *RUN_STORED_PROCEDURE=SPRUNCONVERSION('%APP%','%VERSION_SET%','USD','GLOBAL','%SCOPETABLE%','%LOGTABLE%').

Using BPC for Excel, when i load the rate type values, for example in order to convert MXN to USD i load 10 in this CV:

Flow dim- non flow member

Currency dim- USD member

Datasource dim- calculated values

Rate-account dim- Average

Then i go back to the Financial Application and run the FX trans package, but the values obtained do not match with the exchange rate of 10 that i have stored in rate application. For example i have 83 392 in one account in MXN, after the calc is runned i'm supposed to get 8 339.2 but instead i get 43 781.

The MD property in input currency dim is set as "D"

What value do i have to store inside the rate application in order to get the correct amount? what's the logic (and i mean like mathematical logic) used for currency convertions?

Thanks a lot

[Former Member]

You load data in the local currency using LC as the member in your currency type dimension on your Finance application

BPC will look up the rate type (AVG or END) from the ratetype property on your Account type dimension and it will look up the Currency from your Entity dimension (it uses this to pull back the rate that's stored in the Rate application) and then multiplies or (divides this value into 1) then multiply by the amount it finds in the LC record to create the record in the Reporting Currency--which you defined using the Currency_Type property on your Finance Currency dim. This is basically how BPC logic knows how to pull the correct rate from the Rate application.

[Former Member]

I believe the answer to you question has more to do with how the rates are stored in the rate cube. When you submit rates the rate cube, there logic that is applied when the values are written. It looks at the value being written, determines where the multiply or divide flag and applies it as a result. If you aren't seeing the proper result after the rates are recorded, I would advise that you

1) go into the dimension where the flags' are stored, change them from D to M (or vice versa)

2) process the dimension

3) log into to BPC for Excel into the Rate application

4) run the default formulas package against the intersections where the flags were changed - this will update the records stored in BPC rate cube with the appropriate values based on the flags set above

5) log into the financial application and re-run the fx logic to see if you get the correct result.

As an alternative, you might check the database to see what values are stored in the rate input and rate calc members. If you find that the correct rate conversion factor is in one or the other, then all you need to do is update the logic to tell the lookup factor to look at rate input versus rate calc.

Hope this helps.

Barton

[Former Member]

Hi Nidia,

Are you talking about LOGIC.LGF ?

As you mentioned you have 2 BRs for the FX, you do not have to apply LOGIC.LGF, as I remember it is script Logic to do FX, it is working as same as BRs you have.

That is, you may use RUN_STOREDPROCEDURE = SPRUNCONVERSION instead of Logic.LGF. The RUN_ST... is table driven logic and Logic.lgf is script logic. The table driven logic is tricky to use but it definitely shows better performance since it introduced Stored Procedure, it runs in DB layer with passed argument from script logic(RUN_Sto..). The script logic is text driven logic, the query(create, update, delete and so on) is created in Application server and do execute thru data service in appserver. Therefore the performance is not good as the Stored Procedure.

But it is only for 7.0 and 7.5 I think. And if you have a lot of concurrent users, we cannot say the Stored Procedure is better than script logic. The script logic is twice faster then now in EPM 10(I heard), and it is more valuable for the scalability.

Regards,

YH Seo