aggregates vs CVCs

[Former Member]

Hi APO Gurus,

I am an APO consultant currently working on DP after a loong time spent exclusively on SNP.

I am doing some auditing for a client who has no record of the conception proccess of their DP, and I feel like the design needs to be changed at the lowest level, but I’d like to be sure I got this right:

- you need CVCs to be able to call Time Series for those CVCs and to be able to store data at those CVCs level.

- you need aggregates to speed up the data access process (for instance if I call a selection at the Sales org Level the Sales Org aggregate could be directly queried from the LiveCache instead of aggregating all the way from the material level)

I read everything I could, inluding Disckersback and the notes I could find (inlcuding note 503363 on aggregates), but really I get mixed up between those two in some cases.

=> I have a case where the client works a lot at Sales Org / Partner Level, so what they did was to create a characteristic Sales Org / Partner that is included in the CVCs on top of Sales Org and Partner being there on their own, and I feel it’d be better to have only Sales Org and Partner being in the CVC, and to create a Sales Org/Partner aggregate. (plus I feel it’d be good to compound Sales Org in the Partner InfoObject, since the Partner can only ever be called with the sales org.)

also, they integrated in the CVCs some other couples : Sold To/Material, for instance, or Plant/Material, even if Sold To, Plant and Material are already there on their own in the CVCs.

Am I right in thinking I should:

- withdraw all those combinations from the and leave only single characteristics in the MPOS?

- create those combinations as aggregates?

Could someone explain what negative effects compounding could have?

[rajkj · Accepted solution]

Hi Hugues,

APO DP does not support the compounding feature of characteristics as in BW. However, you can use the compounded characteristics like normal characteristics in your master planning object structure.

As you mentioned, it would be a good idea to remove combinations and build aggregates based on the single characteristics. You may not restrict the eligible characteristic values based on another characteristic's value as allowed by compounding in BW. However, you may use BAdI to filter the results before they are shown in the screen.

You may also use navigational attributes judiciously to simplify the design. They will be available in the data view and for the reporting. But, they can't be used in the aggregates (similar to the SNP aggregate 9AMALA).

Thanks,
Rajesh

[Former Member · Accepted solution]

Hi Rajesh,

thanks for your confirmation and explanations. After some thoughts, I think not having the compounding function won’t be a problem.

about navigational attributes, from what I understand (and from note 413526) that means I don’t include those in CVCs but still be able to use them to navigate. what would be your recommendation for "judicious" use?

Regards,

Hugues

[rajkj · Accepted solution]

Hi Hugues,

The use of navigational attributes is advantageous from DP perspective as it reduces the master data (i.e. CVC) maintenance effort. On the flip side, there will be extra table joins that can impact the performance. Please check the following links on navigational attributes impact on performance.

http://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/4a/3b5059502e0451e10000000a421937/frameset.htm

http://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/4a/1afabdc7e1044ee10000000a421937/frameset.htm

Thanks,
Rajesh

[Former Member]

Hello Hugues,

I would suggest  you to take all the common characteristics together and create CVC's and then for all the distinct/detailed level values create aggregates for those CVC's.

That will be the better option.

But make sure that you cover all the given combinations in the CVC/Aggregate combinations.

Regards,

Anurag