cancel
Showing results for 
Search instead for 
Did you mean: 

Time based disaggregation

Former Member
0 Kudos

Hi All,

The requirement is to dis-aggregate from months to weeks for the current month plus next month, based on last months historical data.

There are two data views

1. having the data in (forecasting is done in this data view)

2. having data in months and weeks. ( last months history is available in weeks and the current & current +1 month in weeks)

The forecast that is in months needs to be disaggregated into weeks for the first 2 months based on last months history.

I have created another KF to copy the last month history into the current and current +1 month in the weekly view.

Also no calendar is defined.

during disaggregation based on the KF the system is throughing unexpected values especially when the last and the next month overlap.

Ex: these are the disaggregated values

W 31.2010 W 32.2010 W 33.2010 W 34.2010 W 35.2010 M 09.2010

3747 2214 2554 3406 14258

here in W35 the value is 14258 which is wrong as the value for M092010 is also added into this week.

Kindly through some light on this weird behavior.

Regards

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

In reply to your first post............

The requirement is to dis-aggregate from months to weeks for the current month plus next month, based on last months historical data.

For this, please check if the Storage Bucket Profile is defined in Weeks. If so, then, just use some of the pre-defined time-bucket profiles in the data view (by clicking to the left side of header) and see the data in weeks.

The forecast that is in months needs to be disaggregated into weeks for the first 2 months based on last months history.

this can easily be done by creating your own time-bucket profile, where you specify your forecast period and how the data has to be viewed for the entire forecast period (say, in weeks for first 2 months, then in months for next three months, and then, in days for the sixth month....assuming your forecast period is for 6 months).

here in W35 the value is 14258 which is wrong as the value for M092010 is also added into this week.

If you want the W35 not to take the value of Sept month, then, I suppose you need to create the calendar (which you have not done yet, right) where you define the Sept month.

Regards,

Guru Charan.

Former Member
0 Kudos

Hi Guru,

I have weeks defined in the storage bucket profile, else how can i disaggregate into weeks.

As for the calender i have not defined any calendar; but i am not sure how this is going to affect the disaggregation. As i mentioned earlier if we use the prorata method then it disaggregates properly and the value for sep appears in month sep.

IF calendar is going to help can you help in understanding the logic and how to go about it.

Regards,

Nitin

Former Member
0 Kudos

Hello Nitin,

Sorry to intrude into this old thread that I read with much hope but I find this unanswered as I just happen to post a ditto issue.

Would you recall how this was resolved :-). Pardon if this sounds irritating and unrelated to you know 🙂

This is what I asked a while ago

http://scn.sap.com/message/14565886#14565886

My settings for KF1 are P-KF2 and K-KF2 but in my case KF2 has 0 values for some selections (new products). In human language, I am trying to disaggregate an "adjustment" to the statistical forecast that is 0 for new products. The adjustment itself is done in month buckets. Simple solution though is to do the adjustments in weeks but that is like multiplying effort by 5 times.

SAP is doing some dumb thing here as this is a logic of convenience. To me it doesn't appear to be a storage bucket setting issue as I am only expecting a sane result in week buckets and I do have week (and also month) checked in storage bucket profile

Here is what is happening. Hoping some consultant from SAP looks into this and acknowledges this as a bug as I didn't manage to find a note. I will have to grope for key words all night. This is such a common unavoidable scenario.

Step1: System finds the COUNT of week buckets (NOT calendar weeks- just the weeks that FALL in the month) in EACH calendar month separately. E.g. Feb 2014 has 5 weekly buckets, incl.1 partially in Jan and 1 partially in March. The week of 27th Jan 2014 is a “week bucket” for BOTH Jan 2014 and Feb2014.

Step2: It then divides the monthly value of KF1 by the number of weeks in Step1 to calculate EQUAL values per bucket week belonging to respective calendar months, IRRESPECTIVE of whether the week is a WHOLE or PARTIAL week.

Step3: It then simply adds the EQUAL values of resp. week buckets of step1, WHENEVER, the week is spread across months. e.g. In the week beginning 27th Jan 2014, that transcends to next month (Feb 2014), it adds up the results calculated in step2 for W-1 and W+1.

Thanks

BS

Former Member
0 Kudos

Hi,

I think you would like to give more details on what kind of time based disaggregation type you are using so that we can understand how you have approached the disaggregation to be based on the previous month history.

In the meanwhile few queries.

I have created another KF to copy the last month history into the current and current +1 month in the weekly view.

Also no calendar is defined.

At what level of detail have you copied this data? Detailed level or aggregate level? I assume you have the 'to be disggregate' KF time based disaggregate on this 'another KF'?

Another note, While the data is loaded in the 'to be disaggregate' KF the 'another KF' should already be populated with the history for Current and Current Month + 1. This is because the system looks up for disaggregation only at the time of loading data into the KF. If incase you have loaded the data first into the 'to be disaggregated' KF and then loaded the history data into the 'another KF' the proportions wont be considered for disaggregation.

Hope this is getting us somewhere.

Thanks

Mani Suresh

Former Member
0 Kudos

Hi Mani,

thanks for the quick reply.

Here is the scene.

I am currently testing this scenraio.

I am testing on 2 products.

I have the historical data, this is at the lowest level. Now i have another KF (disaggregation logic) into which i am copying this historical data. for M0 and M1 months.

Now the forecast is at the aggregated level which is 2 products in monthly bucket.

The KF for forecast is ZAFCST; the KF to store the time based disaggregation proportions is ZAPROP.

I first copy this forecast into anothe KF called ZACFCST. this i do so that i can check how the disaggregation works. This KF does not have any time disaggregation method.

The disaggregation methods for KF ZAFCST used is 'P' for structural disaggregation KF IS APODPDANT and K for time based disaggregation KF is ZAPROP.

As i said earlier the forecast is generated in the Monthly bucket data view.

The planner views the data in the dataview which has weeks and months as the time bucket.

Now the disaggregation problem arises once the technical period of the week and month meet.

in my example W35 has has 3 days from Aug and 4 days from Sep and Month Sep should have the remaining days as per sap.

But in the planning book even the value that should be assigned in the month Sep period is assigned to the W35 period.

the structural disaggregation is happening fine.

First does SAP support time based disaggregation when we use a Dataview with 2 technical periods in it.

Also one more that i noticed was,

when the monthly data was disaggregated to the weekly time buckets;

for KF ZACFCST: the Forecast sits on the 1st monday of the week which is fully in the month Technical period.

Ex: if a week1 is overlapping with june and july, then this fcst sits in the week 2 monday of july.

But for the ZAFCST when it disaggregates the problem arises on the last week - month period.

How this explanation is helful.

if not let me know i will restate it. This needs to be closed at the earliest.

regards

Nitin

Former Member
0 Kudos

I am able to follow what you are saying and you are on the right track.

First does SAP support time based disaggregation when we use a Dataview with 2 technical periods in it.

It does, otherwise the purpose of having split time profiles is defeated.

The disaggregation methods for KF ZAFCST used is 'P' for structural disaggregation KF IS APODPDANT and K for time based disaggregation KF is ZAPROP.

From this I understand that time based disaggregation of ZAFCST is based on ZAPROP. From your first post I understand that the data for the 1 month history is also available in Weekly. Also, I understand ZPROP is the KF into which you are loading CM & CM +1 the PM history.

I am also assuming that you copied over data into ZAPROP at weekly level and the detail level of CC. Having done all of this, we shud expect CM & CM + 1 of ZAFCST which is TBD on ZAPROP to be in the same proportion as ZAPROP. Possible reasons why this is not happening...

1) You could be using 2 different calendars/fiscal variants for your weekly buckets and your monthly buckets.

2) The 2 different calendars have different start and end dates to the months. For example the weekly calendar only ends the month of August on the 3rd of September but the monthly calendar ends it on 31st August itself.

Pls check if this is the case.

Thanks

Mani Suresh

From your first post

Thanks

Mani Suresh

Former Member
0 Kudos

Hi Mani,

thanks for the reply,

I am not using any calendars or fiscal variants here. The system does it on workday basis. If i use the S type or P type for time based disaggregation it works absolutely fine.

As u said the week 35 ends on 3rd sep and the month sep should begin on 4th sep and end on 30th sep.

As per standard SAP methods based on the workday calculation and the disaggregation ratios the month of Sep should have the remaning values in it. but unfortunately it gets added to the week 35 values.

Could there any other reason for the system to behave like this.

I am copying the data at the lowest level. I have a macro to copy from week 22 to 26 into week 27 to week 30 and another to copy it from week 31 to week 34.

could it be a problem with the macros.

Regards

Nitin