Time dependent EXCHANGERATE in Currency calculation

[AyanBishnu]

Hey Gurus

This is in continuation to my previous post on Base Currnecy similar to UOM. Exchnagerate in IBP currency calculation is a AAK where we generally use the current exchangerate as attribute and the same is available for the defined horizon. technically we can also maintain exchangerate as time dependent in the KF.

The requirement expectation is to maintain time dependent exchange rate for a horizon of 4 yrs ( 2 yrs in past and 2 in future all in weekly period). So this means we will need to maintain the rate per bucket and each bucket will have different exchangerate.Now i will have to maintain the from and to currency for all possible currency combination which the business need. So in a way the count of time series object will increase exponentially once we start to maintain it. Adding more complexity to the requirement is the ask for maintaining currency at the prodloc or prodcust level.as 1 product can have different base currency based on the location combination. So below are my questions or concern about performance impact

1) IF we maintain EXCHANGERATE on a per period basis and start maintaining rates between CURR to CURRTO on time scale and that for all possible combination, what should be my limit that I need to conisder before I start getting performance issues while loading planinng views from the UI ?

2) Is thier any option to maintain currency as base currency for a prodloc combination (similar to UOM) ? Can we acheive this techincally taking into account how the CURRENCY and EXCHANGERATE is structured in IBP as default ?

3) Any other points to consider before deciding that we can use EXCHANGERATE on a per period basis and use CURR like UOM where we have the concept of BASE UOM ?

Waiting for your feedbacks and exprience with similar requirement. And as usual tagging my favourite advisors irmhild.kuntze and mkorndoerfer for thier insight.

Regards

Ayan Bishnu

[former_member194529]

Hi Ayan,

Have you found an optimal solution for your requirement already? If yes, please feel free to share it here.

Best,

Ivan

[former_member602633]

Hello Ayan,

Could you pl share the details on how the Time Dependent Exchange Rate functionality was achieved?

We have a similar requirement where the business wants to see the Revenue being calculated based on forecasted/future exchange rates.

Appreciate your insights.

Thanks,

Mangesh Kulkarni

[AyanBishnu]

Hello ocmangeshrk

time dependent exhange rate was done by creating a KF at CURRCURRTO planning level (e.g in our case it was CALWKCURRCURRTO and KF name was ZEXCHANGE). Once you create a similar KF at the above mentioned planning level then in the use conversion field you will see that KFID ZEXCHANGE as an option. Use that option and you are good go.

Basically we are not using the currency MDT, where the EXCHANGERATE is an attribute and is being used as AAK. Instead we are using a KF and loading the conversion rate for current and future.

[AyanBishnu · Accepted solution]

Q1) IF we maintain EXCHANGERATE on a per period basis and start maintaining rates between CURR to CURRTO on time scale and that for all possible combination, what should be my limit that I need to conisder before I start getting performance issues while loading planinng views from the UI ?

In general conversion (UOM or CURRENCY) is a really simple calculation with almost negligible performance penalty. Any query that contains conversion relevant key figure(s) is always contains the information of the output currency/uom. From technical point of we this allows the DB to filter and work with small datasets. As long as you don't have filter block for the conversion target attribute, conversion should not be the root cause of any performance issue. Filter blocks for conversion target attribute are usually a sign of an invalid modeling and in 99% of the cases it will lead to unexpected calculation result.

Q2) Is there any option to maintain currency as base currency for a prodloc combination (similar to UOM) ? Can we acheive this techincally taking into account how the CURRENCY and EXCHANGERATE is structured in IBP as default ?

You can follow the pattern of the sample PRODUCT master data type of IBP and apply it to your LOCATION master data type by adding the base currency attributes (CURRID, CURRDESC) as non key attributes of the master data and using these in the planning levels of your planning area.

3) Any other points to consider before deciding that we can use EXCHANGERATE on a per period basis and use CURR like UOM where we have the concept of BASE UOM ?

You have to comply with the same principles as of today when you have a PRODLOCCURR planning level. From calculation point of view the most important is that if you aggregate in the LOCATION dimension you'll lose the base CURR information thus you have to add the conversion calculation before the aggregation.

And as I mentioned in the 1 point, make sure you do not create filter block for conversion target attribute, because it most likely will cause unexpected calculation results.