MIN/MAX aggregation in Planning DSO not input-ready?

[Former Member]

Dear colleagues,

I'm on BW 7.31 and created a planning DSO, see:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/5093eca5-ba21-3010-b881-f48c471c8...

... now I have several questions:

FYI:

I created a DSO with one SUM, MAX and MIN key figure and first forgot to tick the checkbox "Planning Enabled".

In that way I was able to create data manually via t-code RSINPUT... and a query on top of the DSO displayed all key figures correctly.

Then, I cleared the DSO and activated the checkbox "Planning Enabled".

Now, I'm getting an error message in RSINPUT, saying I cannot enter data anymore, due to this checkbox.

Q1) Why is it not possible to use RSINPUT here?

Then I created an aggregation level on top of the DSO, everything 1:1 and created an input ready query on top of that.

I put the settings to "input-ready" in all three key figures, and when I open it in RSRT or in AO, only the SUM key figure column is input ready.

Q2) What is the reason that the MAX and MIN key figure columns are not input ready?

Basically there is no difference and I don't know why it should not be possible to plan MIN/MAX in a DSO?

(Is it because the zero values - in case of an "error record" - would disturb the real MIN value? But for MAX this does not matter).

According to the link above only "NO2" aggregation should be possible besides SUM.

Q3) Really and if yes, why?

So far I only planned on infocubes, but I have a requirement about a MIN key figure, so I just wanted test the possibility.

Thanks a lot, Martin

[gregor_dieckmann · Accepted solution]

Hi Martin,

here are the answers:

Q1)

Transaction RSINPUT is very old (BW 7.00?), not released for production and got no further investments for new types of InfoProviders. To support planning enabled DSOs one would have to enhance RSINPUT since planning enabled DSOs have to ensure that for all records in the DSO the SIDs of the characteristics values have to exist. This is why planning enabled DSOs can only handled via planning (or APD).

Q2)

Key figures with MIN/MAX aggregation are always read-only in planning enabled InfoProviders. The reason for InfoCubes is quite clear since there delta records can be written on any 'level' (with unassiged values for characteristics not in the aggregation level, ignoring 'derivation', so simplify). But MIN/MAX only behaves well with respect for aggregation if records are written on the lowest level. For DSOs this is the case, so there seems to be not logical problem. There are only two technical problems:

a) MIN/MAX key figures not contained in the aggregation level have to have a defined value that in neutral with respect to the aggregation. The system uses +ininity/-infinity. The technical problems is that the buffer is still using a delta mechanism in the user session and uses the DB data types, so there might be overflows. Of course, one can handle this using other data types as DECFLOAT (-> dev. effort)

b) In general all features in the query should work as well, e.g. disaggregation. With MIN/MAX this is hard to understand for end users since changed values on different levels would overwrite each other (this disaggregation would be 'copy'). Ok, one might disable disaggregation.

Q3)

Aggregation NO2 works in planning enabled DSOs since there exist use cases with high priority, this is why this was developed, e.g. prices in CRM planning. NO2 does not have the disaggregation problem in b)

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

thanks for the detailed answers... so, to get it right:

1) SAP just did not complete the RSINPUT functionality for "Planning Enabled"-DSOs, right? For Direct Input DSOs without this setting it still works.

2) Basically my settings are correct and MIN/MAX are never input ready on DSO, because SAP did not provide the functionality for that, right?

Let me explain what my intention was:

I want to plan e.g. 8 key figures on detailed level as SUM, because I want to show the average of them in the query. In addition I want to fill the same values in a MIN key figure, since on an aggregated view I'm supposed to reflect the minimum of those 8.

(for testing this, I just wanted to insert data via RSINPUT)

Question: Would it be possible to write the values to the MIN key figure via planning function or will this lead to an error and it is just not possible to fill such a key figure in a planning DSO?

Thanks,

Martin

[gregor_dieckmann · Accepted solution]

Hi Martin,

1) To my knowledge RSINPUT works for transaction InfoCubes and old transactional DSOs; consider this transaction 'as is', anyway it is not released to be used in production.

2) As I said MIN/MAX key figures are read only in planning InfoProviders, thus this is valid also for planning functions.

If you what to display SUM key figures with MIN/MAX aggregation why do you want to replicate the key figure values? You can use exception aggregation in the query to compute the MIN/MAX values.

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

thanks for your feedback. No. 1 & 2 are clear now 🙂

Regarding your question why I don't use exception aggregation:

Let's assume I have several characteristics: Month / Plant / Segment / Region / Country.

I'm going to plan 3 months for 1 plant for 2 segments in the same Region & Country.

My key figure is defined as aggregation SUM / exception aggr. MIN, related to Month

When I display the planned values for one month and want the minimum of "plant", then BW sums up the two segments and the minimum is the sum, not the real single minimum.

The same is if I plan for more Regions or Countries. I always want the real single minimum of all my records.

Reason: I need to plan a key figure as a "rating" (1-5).

Each Characteristic combination can reflect only values between 1 and 5.

If I report my data on higher aggregation, also my result is supposed to be the overall minimum between 1 and 5. If the two segments have a rating 3 and 4, I must not display 7, but I need to see the 3, because this is the single minimum. That is why I wanted use a MIN/MIN key figure, not SUM/MIN.

I tried this example via an input-ready query, it shows 7, not 3.

Of course I could change the relation from Month to Segment, but I think the issue remains if I check the result on Plant, Region or Country aggregations.

Do you understand my issue? I cannot really see the solution here?

Thanks, Martin

[gregor_dieckmann · Accepted solution]

Hi Martin,

exception aggregation can be nested, though I see that it is not very convenient to add all characteristics maybe to the lowest level you have.

Since by now it is not possible to update key figures with MIN/MAX aggregation with planning functions or input-ready queries one idea might be to replicate the SUM key figures with WHM methods in another (reporting) DSO.

Regards,

Gregor