cancel
Showing results for 
Search instead for 
Did you mean: 

Dis Aggregation in DP

Former Member
0 Kudos

Hi there,

I've set a KF (Stat FC) with calculation type P and DisAgg KF being used is the sales history. But it's not disaggregating as i would expect.

My simple test (with 5 different CVC's).

At plant/product level I've deleted the data from the Stat FC KF and then copied the sales history directly into Stat FC (so history (moved forward 12 months with a macro) = Stat FC) and saved. Now when I drill down to the lowest level, the disaggregated Stat FC does not equal the sales history (which I thought it should do). The values are almost the same (vary by 3 or 4) but I expected that they should be the same. Can someone explain why this would be.

APODPDANT Test

A second test, i change the DisAgg KF to APODPDANT and this did split evenly between the 5 didfferent CVC's.

And if one of my CVC's has a zero month in the sales history, should I expect the corresponding stat FC value to be zero given its disaggregation is based on the history?

Is disaggregation done on a month by month basis or does it use the total for the forecast period?

thanks for your help.

Paul

Accepted Solutions (1)

Accepted Solutions (1)

rajkj
Active Contributor
0 Kudos

Hi Paul,

First Test (sales history as disaggregation key figure):

The difference between system calculated value and your sales history might be due to decimals and rounding method SAP uses to distribute the fraction. Please check the following link for details

http://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/fe/80a934908685479f084e9621749a0a/content.htm

http://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/26/53f1f3758211d398490000e8a49608/content.htm

Second Test (APODPDANT as disaggregation key figure):

Since you did not mention of anything related to proportions, I assume you did not generate or manually maintained the proportions. In that case, SAP disaggregates the values evenly. If you don't generate the proportions, the disaggregation method will not change even with 0 value in the history.

Please refer the following link for details on proportional factors generation based on selected key figure (i.e. sales history as per your question).

http://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/66/29fb672fbe11d398240000e8a49608/frameset.htm

  1. If you use t.code /SAPAPO/MC8V (Calculate proportional factors) and calculate time-dependent detailed proportions, the zero value will be considered and proportion factor for that specific CVC for that time period will be zero.
  2. Your last question related to period by period or total forecast horizon is also related to 2 options available with t.code /SAPAPO/MC8V.  Please refer the above link for details.

Thanks,

Rajesh

Answers (2)

Answers (2)

rico_frenzel
Advisor
Advisor
0 Kudos

Paul,

additionally to DB49's reply, you will find a (rather technical) explanation of how these differences may occur in note 410680. The main reason is that values need to be rounded up or down and the "remainder" is added to the next bucket / Detail.

Best regards

Rico Frenzel

Former Member
0 Kudos

Paul,

I can think of a couple of reasons for your first question.  If you are using any type of time disaggregation, then small differences between the periods of last year and the periods of this year can affect your detailed figures, depending upon the nature of your Storage Bucket profile.  Also, when you copy data from last year to this year, you must copy at the detailed level, if you want the detail to be identical.  Generally, though, such small differences, which are a result of rounding errors during aggregation and disaggregation, are insignificant, and can normally be ignored.

For your second question, Disaggregation is done based upon the Time Based disaggregation methods you have configured.  Behavior is dependent upon your Time based settings (Proportional?  Equal?  None? etc etc), the settings in the Storage Bucket Profile, and the Time bucket profile in your planning book data view.

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

My storage buckets profile is monthly. And I'm actually at plant/product/sales group (an intermediate) level.

I'm copying the agrregated total from the sales history into the stat FC (for testing and verification) so I can see that dissagregation is working. I still would have thought that disaggregation would be done correctly from top down. It just doesn't fill me with confidence when the dissagregation differs from the data in the Dis KF.

Yes I can see this would work from bottom up (copying the lowest level) but our forecasts are generated at the intermediate level.

And yes, the adoptant test was proportional which work exactly right when values where divisible by 5.

Our goal is that when we create a Stat FC using DP we have 100% confidence that it disaggregates in the same propportion as the sales month from 12 months earlier. Then at the lowest (customer) level we can manage the forecasts as per customers (group) requirements.

thanks

Paul

Former Member
0 Kudos

Paul,

Naturally you should validate that all of your disaggregation/aggregation design logically makes sense.  However, you seem to be falling into the trap of pursuing precision rather than accuracy.

If you could somehow calculate every value to the precision of a thousand decimal places, and make all figures disaggregate/re-aggregate to accuracy of a hundred decimal places, what additional value do you gain?  Remember, we are talking about a demand plan.  It is usually derived from a number of sources, one of which is often a statistical forecast.  In the end, will ultra-precise calculations actually make your demand plan any more useful?  As long as the numbers generally make sense, your final output is still just a prediction of future events.  Unless you have made major errors in your logical methodology, 'precision' will be a very minor business issue. Better to focus on determining the forecast models that best describe your marketplace.  Or, better still, try to get some marketplace intelligence info from non-mathematical sources.

Best Regards & Good Luck,

DB49