YTD routine in update or transformation rules

[Former Member]

I'm currently on BI 7.0. I have an ODS that contains a monthly balance key figure. When moving this data to an infocube, I'd like to create a YTD key figure based on that monthly balance. I have 0FISCYEAR, 0FISCPER, and 0FISCPER3 time characteristics in my ODS and infocube.

Can someone provide me an ABAP code sample that I could use in my transformation routine that could calculate the YTD value based on the monthly balance key figure?

Thanks,

K-D Vo

[Former Member · Accepted solution]

Take a look at the code for the standard sap YTD variable for 0CALYEAR. You can copy it and just change the source characteristic (from 0CALYEAR to 0FISCYEAR)

[Former Member]

Eugene,

That is one option we have explored and there are some downsides to that. This option would work if it can be guaranteed that people do not go back and make adjustments to prior closed periods. In best practice and a perfect world, that should be the case. But in reality, people do go back and make adjustments to closed periods. That means if we do a periodic upload, there has to be a manual process to notify the BCS person and he/she has to reconsolidate any periods that are adjusted. Feeding a YTD value, would make sure thay any adjustments to prior periods are "automatically" accounted for. If there is an easy way to calculate a YTD value in the infocube from monthly values from the ODS, then this would be a better route. If there is not an easy or efficient way to calculate the YTD value, then we may have to go with the back up plan of a periodic upload as you suggest.

K-D

[Former Member]

Hi K-D,

I always prefer the cumulative methods (especially data load ones) because of the reasons you just described.

And, IMHO, there is no possibility to control the human factor in case of periodic data.

SO, I would prefer requesting from the data provider employees to submit data on CUMULATIVE basis. In this case they would correct their past errors that would be reflected in the YTD data provided by them.

And I see a little controversy in yor explanation. -- As I see, your data is periodic, monthly basis. When the employees correct data in past, close periods, AND THE SYSTEM IS'NT FED BY THIS DATA, you have to provide all corrections to past periods in the current month load! (Don't beleive that you can change data in the past).

In other words, even leaving the situation with the monthly, periodic, data load, just request from employess to provide all of data (current and for past periods) in the CURRENT period only!

So, repeating:

1. Periodic load.

2. All changes/corrections of the prior periods in the current loaded data only. No changes in the past!

OR:

1. Cumulative load. All cumulatives are to be calculated by employees (including all their corrections).

Hope this helps.

[Former Member]

Why don't you leave it as monthly data and use PERIODIC upload of data in SEM-BCS?

[Former Member]

Thank you all for your responses. Your suggestions are for a front-end YTD customer exit variable solution and I already have a YTD customer exit variable for that. What I'm asking for is a back-end solution in the infocube itself via transformation (update) rules. I know it is inefficient, but I don't need it for reporting purposes. I need it to feed BCS a cube that requires the values I send to be YTD values and not monthly values. This doesn't have anything to do with reporting.

K-D

[Former Member]

Hi KD,

Instead of calculating YTD value in update rules, create variabel(customer exit) on fiscal year and use.

check : <a href="http://sapbwneelam.blogspot.com/2007/10/how-to-create-populate-user-exit.html">How to... Create & Populate User Exit variable</a>

Hope it Helps

Srini

[Former Member]

Hello K-D

This is very strange to implement YTD in back-end...can you think of your data volume in cube ...its going to be huge...the same thing you can do at query level very easily and efficiently...

For YTD exit code there are so many post on SDN.

Thanks

Tripple k