agg level

[Former Member]

Hello All

we are working on a a prototype and am getting the same results with any aggregation level that i define in the planning job.

we have got 2 levels - material and sales organization.

M1   S1 

M2   S1

M1   S2

M2   S2

M3   S3

how does this aggr level in the planning job work ?

we have sel id on sales org. No restrictions here.

thanks in advance.

regards

kk

[rajkj · Accepted solution]

Hi KK,

Based on your input, we can expect the following results.

Selection profile - Sales Org = S1

Data view result = M1 S1 + M2 S1

Selection profile - Sales Org = S2

Data view result = M1 S2 + M2 S2

Selection profile - Sales Org = S3

Data view result = M3 S3

Selection profile - No restriction

Data view result = M1 S1 + M2 S1 + M1 S2 + M2 S2 + M3 S3

Since you used same levels in your input, the agg level result is same for both material and sales org.

Thanks,
Rajesh

[Former Member · Accepted solution]

hello

thank you for the answer.

you are right , we are getting

Data view result = M1 S1 + M2 S1 + M1 S2 + M2 S2 + M3 S3

but the agg level that we are selecting ( at the planning job ) is only product.

should not the system again filter the data view result with respect to the agg level and then process the result ?

regards

kk

[rajkj · Accepted solution]

Hi KK,

Since you use same levels for both material and sales org, there won't be any difference. The system does not apply any filter apart from selection profile restriction.

e.g.

Sales Org      S1                        S2

Material       M1 M2 M3           M1 M3 M4

Selection profile - Sales Org

Material             - M1

Then,

Data view result: M1 S1 + M1 S2

Selection profile - Sales Org

Material             - * (or no restriction on product)

Then,

Data view result: M1 S1 + M2 S1 + M3 S1 + M1 S2 + M3 S2 + M4 S2

Had you used product hierarchies, then it would have been a different type of calculation based on the hierarchies that were maintained in the system.

Thanks,

Rajesh

[Former Member · Accepted solution]

hi Rajesh

then whether the selection profile is what is looked at and has a higher preference than the aggregation level defined in the planning job ?

how are the Sel profiles and the agg level different ?

thank you for the time

regards

KK

[rajkj · Accepted solution]

Hi KK,

The selection profiles are similar to filters and restrict the data to be selected for further processing. Whereas aggregation level allows you to choose the characteristics to roll up the values and pass them to the macro.

Since your selection profile is based on sales organization but with no restriction, all the CVC are eligible for macro execution. Then, your aggregation level considers 'Product' characteristic, the system tries to roll up the values of each product at different sales organization level. Then, it sums up the values as M1{ S1 + S2} + M2 { S1 + S2 } + M3 {S3} (from your own example).

Assume you have 100 records, with appropriate selection profiles, you can select 10 records for macro execution. Then, based on your characteristics selection for aggregate level, these 10 records will be rolled up and passed to your macro as one or few records.

Please check an example at http://help.sap.com/saphelp_scm70/helpdata/EN/02/7650ee353611d398290000e8a49608/content.htm

Thanks,

Rajesh

[former_member209769]

Hi KK,

Whether you would see any difference in calculations would depend on your selection ID, maintained aggregation levels and also your aggregation type that you define for the specific KF (Key Figure) in your planning area.

Selection ID is for selecting the CVCs. Based on whatever selection you maintained, the relevant CVCs would get picked, and then from background job perspective, the use of selection ID is over. If you had loaded the data using a selection in foreground (planning view), then the characteristic which you had maintained against "display" while defining the selection would have also served as your aggregation level, but this is not relevant for background.

For background job, you would maintain Aggregation level in the variant of the background job. So, for whatever KFs you do some calculation in macro, that would happen at your relevant aggregate level. e.g. If you only specify Sales Org as aggregate level, the calculations for your KFs would happen at the Sales Org level, and would then get disaggregated to your other levels e.g. material, based on your disaggregation settings in planning area. If you select all the Characteristics as aggregation level (e.g. both Material and Sales Org), then your calculations would happen at most detailed level, and then when you see data at any level, aggregation would kick in and you would see the data at the level you specify in "display" of your selection ID.

Check out your aggregation type. In your scenario, I think that for pro-rata disaggregation, your results would remain the same irrespective of the aggregation level. Think about the above and bring aggregation/disaggregation into picture. Results would be clear for you.

If you have some doubts, also share the KF data against the CVCs, and we could help byexplaining.

PS: Apart from the above logic, if there are default macros or other kind of macros, they might affect the results which you would view when loading data in the planning view. Only FYI. I am not  sure if this applies for your current case.

Thanks - Pawan

[Former Member]

hi

thanks for the detailed explanation by both Rajesh and Pawan.

Pawan - One query.

You had said - So, for whatever KFs you do some calculation in macro, that would happen at your relevant aggregate level. e.g. If you only specify Sales Org as aggregate level, the calculations for your KFs would happen at the Sales Org level, and would then get disaggregated to your other levels e.g. material, based on your disaggregation settings in planning area.

--------------------What i feel is that disaggregation takes place only within the char itself. Not with any other char.

We have a KF - Corrected Forecast

At the Sales Org level - there are currently 3 Sorg's.    KF total = 4500 ( macro output )

M1  S1   

M2  S1    

M3  S2    

M4  S3   

Regards

KK

[former_member209769]

Hi KK,

If you noticed, the aggregation type is maintained for the KF, not for the characteristic. Let me try to explain with an example.

Assume that you have specified Sales Org as aggregation level, and also assume that the macro calculated 1500 for S1, 1500 for S2, and 1500 for S3. (I am assuming some simple data in line with your sum of KF for the 3 Sales Orgs 4500).

So, when you would make a selection in your planning view as "display" 'Sales Org'. Sales Org = S1, S2, S3, and then load the data for all the 3 Sales Org together, you would see 4500.

Remember in above that since your aggregation level was Sales Org, data calculation in the macro happened for S1, S2 and S3 separately. It's only that you CHOSE to DISPLAY them together, hence you saw the sum of the 3 Sales Org.

Now, coming to the data that would actually be stored in the planning area based on disaggregation (data is stored at the detailed CVC level, or at aggregate level. I am assuming that you don't have any aggregates to keep the explanation simple):

Macro calculated 1500 for S1. You have 2 CVCs having S1 -  M1 S1 & M2 S1. Assuming a simple scenario where KF was zero for both of them initially, and you have pro-rata disaggregation, you would see 750 for M1 S1 and 750 for M2 S1 (750 = 1500/2).

Macro calculated 1500 for S2. There is only one CVC - M3 S2. If you would see the data for M3 S2, you would see the whole 1500 at this level.

Macro calculated 1500 for S3. There is only one CVC - M4 S3. If you would see the data for M3 S2, you would see the whole 1500 for this CVC.

If you would select only S1, then you would see 1500. Similarly if you only select S2 and S3, you would see KF as 1500.

Hope this simple example explains the aggregation/disaggregation to you.

Thanks - Pawan