cancel
Showing results for 
Search instead for 
Did you mean: 

KF disaggregation/calculation type "A" - new CVCs

Former Member
0 Kudos

Hi,

Do you have any experience with key figure disaggregation for calculation type "A"? As you might know, using this disaggregation values are copied to the lower levels. That is ok, until you have a new combination created in your hierarchy, where this KF will be empty (as a default). Once the new combination created the KF value on higher (aggregted) levels are already recalculated (average from one level below) and therefore these are not correct.

I was wondering if there is a std or easy way "forcing" a new disaggregation (in release 4.1) without changing the existing values so the new combinations will "inherit" their parent's value.

Example:

Product group

A KF value : 100

/ \

B C

Product KF values : 100 - 100

Now, you have a new product created for product group A. Product D's KF value will be zero, therefore the KF value on the Product Group level will be 66,6666..

The new combinations are also created manually by planners but mostly generated by background jobs during the night. I am searching for a solution whereby newly created combinations will "immediately" get their parents "old" KF value (100 instead of 66,666).

Any idea would be helpful.

Thanks,

Maria

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

See, in your case say Product Group A having value 100 which is get saved in to Live cache & because of calculation type "A-Average" sub group "B & C" having same value of 100 & which is also get saved in to live cache. Now if you add a new combination or new sub group under "A" then also data will not change for A, B & C values. If you want to change the value for D is 100 then you have to enter 100 in to A value, so automatically data will disaggregate to B,C&D.

I think this is the way you can fulfil your requirement. You requirement is quite interesting.

Regards

Sujay

Former Member
0 Kudos

Hi Sujay,

Thanks a lot for the quick response. I forgot to mention, that the old value (100) on Product group level should not be changed manually. It would have been quite some manual work from planners to re-enter values for the each period.

I am looking for some kind of automatic way.

So far I could only think of storing "old" values on product group level in an a separate KF (@ end of the working day) and copy them back (@ begining of working day). This way the new combinations created would have the same value. Maybe there is an easier way. Also we need to consider job runtimes (during the night) as we have already quite a long job schedule to execute every night.

Do you have any other idea? I was thinking SAP should have thought about this possibility when designing the system but could not found anything so far.

Thanks,

Maria

Edited by: Nagy Maria on Jun 17, 2009 11:44 AM

Former Member
0 Kudos

Hi,

Do one thing, May be this one is quite diffrent solution.

E.g. Key figure Forecast, Group is "A", Sub Group is "B & C". Copy the aggregate value in to the New Key figure say "New Forecast". Now after running job for new combination, Run new Job for Macro which is at aggrgated level only for coping aggregate value from "New forecast" Key figure to "Forecast Key figure".

This means, E.g.

Forecast "A"-- 100

Forecast "B" -- 100

Forecast "C" -- 100

Copy Forecast to "New Forecast" A-- 100

Now if you create a new combination after that you have run Job for macro which is at aggregated only ( Dont put macro in ti Default) which copy "New forecast" values to "Forecast" Key figure.

Forecast "A"-- 100

Forecast "B" -- 100

Forecast "C" -- 100

Forecast "D" -- 100

Hope this will help you

Regards

Sujay

Former Member
0 Kudos

Hi Sujay,

My idea described above is similar to yours but instead of a macro I would use key figure copy (that runs faster than a macro) to copy back the values on aggregated level.

I am wondering why we have to think about all kinds of "tricks" and there is no SAP standard way for this scenario. I do not think the scenario I described is a very unique one. Do you agree?

I have also tried calculation type "D" that works similar - for disaggregation - as calculation type "A" but the aggregation should be averaging values from the lowest level (instead of one level below). I have tested it but could not work out how does it work (experienced strange disaggregation/aggregate not according to SAP documentation). Anyway, even with this type we would still have the same issue

Do you have any other idea?

Thanks,

Maria

Answers (0)