Price planning problem

[Former Member]

Hi all!

We're doing a BI-IP planning project, and we need to implement price planning.

Prices have to be planned like any other key figure.

But I've faced a problem - it seems that since price isn't a cumulative value, it can't be stored in planning cubes, and aggregation levels, and therefore can't be planned... It kinda makes sense but it seems weird that this common task cannot be done using BI-IP.

Could anyone please advise me what can be done for price planning, and what's usually done?

The only option that occurs to me is adding price as an attribute of a characteristic, but then it won't be possible to enter the planning values in web or Excel... And it's required to enter price planning values on different levels (store, region etc.) - and this probably won't be possible with master data as well.

If anyone had already faced similar problem, please share your experience.

Thanks.

Best regards,

Andrey

[Former Member · Accepted solution]

Hi Andrey,

which infoobject are you using for price.

Thanks and Regards,

Jerry

[Former Member · Accepted solution]

Hi Jerry,

I'm using the standard 0RTPLCST (Cost Price) and 0RTPLRTL (Retail Price) key figures

Best regards,

Andrey

[Former Member · Accepted solution]

You are right. You can't plan on non-cumulative KFs for the Aggregation levels but you can use them as reference in planning layouts. Could you check if the 2nd option in the link fits? http://goo.gl/X73u1

[gregor_dieckmann · Accepted solution]

Hi Andrey,

prices usually can be modeled as ratios, cf. the following blog

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/20715

In this case 'price' is an input ready formula. For mor information about this topic:

https://service.sap.com/sap/support/notes/1236347

(attached PDF document).

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

Thanks for your reply.

I'm aware of inverse formulas, but to use one I'll have to have two additional key figures, in our case - "Sales at Retail" and "Sales @ UOM", and at least one of them has to be entered by user.

We have only one KF planned - the price - and there's no other key figures on that level.

So unfortunately that doesn't seem to be an option in our case...

Maybe there's another solution for planning an "isolated" KF like this?

Best regards,

Andrey

[gregor_dieckmann · Accepted solution]

Hi Andrey,

most retail customers I know use the 'quota' or 'ratio model', i.e. prices are planned in connection with e.g. sales retail, sales unit, then the price is usually called AUR and is an input-ready formula.

'Pure' prices do not fit to InfoCubes since prices don't aggregate (normal DB aggregation is SUM,MIN or MAX), don't disaggregate and should be maintained on a well defined level. I know this scenario from CRM-TPM use cases, one plans 'prices' and 'discounts' (absolute and % values) and 'uplift' (promotion planning):

- aggregation: in BW terminology NO2, i.e. the value if it is homogeneous and 'NONEX' if it is not homogeneous

- disaggregation: copy, i.e. changed aggregated values will be copied to lower levels

Thus prices should be stored in data stores, i.e. flat tables (no delta handling but after images).

This is an easy model but has the disadvantage that all calculations have to be performend on the lowest level.

Development is working on these type of scenarios, but by now this is not supported.

Of course, you can use a key figure with aggregation SUM and change values only on the lowest level, but aggregated values make no sense here. One might use reporting features to calculate more reasonalbe aggregated values, e.g. using exception aggregation (for all characteristics except 'product' if you plan product prices). But this is not very nice but doable.

Non-cumulatives are ususally used in other scenarios and are not supported in planning, though one can simulate the behaviour also with inverse formulas. In short, use the 'stock' value in period 0, put deltas in 'real' periods; compute these deltas with inverse formulas. But aggregation with respect to non-time characteristics will still lead to not meaningful values.

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

thanks a lot for your answer.

Best regards,

Andrey

[Former Member]

Might be some useful info -

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70bb4739-e492-2c10-f39b-cf49e57a0...

(make sure to check pages 15, 16)

[Former Member]

Hi Mayank,

thanks for your reply.

I've already looked through the MAP Performance Guide, and if I understood it right, it doesnu2019t suggest anything for that kind of planning, it only gives recommendations for showing the actual values of non-cumulative key-figures in queries and (if I got it right) suggests that we use them as cumulative key-figures (?)

So this doesn't exactly resolve my problem... Or I just didn't understand it right...

Best regards,

Andrey