char in dso planning - key or data field?

[cornelia_lezoch]

Hi everyone,

I just tried to create a DSO planning.

I want to use the DSO because we want to read the data out of there using a function module to transfer the data to ECC and it is easier to do this with the DSO table instead of a cube.

I have put some char into key fields and some char and key figures into data fields.

key figures are summable, char do have attributes.

most of the char in data fields should be filed with derivation rules later.

now when I try to have some data records created with a planning function, the function works well in planning modeler with trace.

but if I want to save the data, I get the error message

Kategorie              ABAP-Programmierfehler

Laufzeitfehler         UNCAUGHT_EXCEPTION

Ausnahme               CX_RSR_PROPAGATE_X

ABAP Programm          CL_RSR_BASE===================CP

Anwendungskomponente   BW-BEX-OT

I think it is, because I read something in SAP help, that char in data fields will be used for this "char as key figure planning" which I don´t have yet, because I am on 7.3

If I move the char to key fields I get error messages, because some of the char will stay empty and the error says, that key fields may not be empty.

So the question is - can I use char with attributes as data fields? Then what do i do about this error message?

If I have to have them as key fields, why can I not use # as a value?

thanks

Cornelia

[cornelia_lezoch · Accepted solution]

I found this one and it pretty much tells what I already assumed - i have to use the char as key and I can not use #

http://www.erpchamps.com/qa-dso-planning/

[gregor_dieckmann · Accepted solution]

Hi Cornelia,

in releases 7.3x DSO planning only supports DSOs having all characteristics in the key part of the DSO. In 7.40 with SP08 you can also have characteristics in the data part of the DSO and then use these characteristics as key figures.

Please observe that with a DSO as a persistence some things change significantly:

- InfoCubes are insert-only, the system writes delta records

- DSO (planning enabled): this is just a flat table, the system writes after images.

To aggregate data from a basis InfoProvider, to change data on this 'aggregation level' and to write back delta records with characteristic values = # for characteristics not used in the aggregation level only works well for InfoCubes (delta records) and not for DSOs (after image). This is why the DSO key has to be known when data has to be stored in a DSO, just to be able to find the record (insert, update or delete; in an InfoCube one just has insert). It is possible to fill key fields of the DSO using derivation.

It is a good excercise to think what would happen if the value=# logic would be used in DSO with after-image logic: you would get a lot of data waste.

DSO planning should be used if one needs to store data that depend on an explicit notion of a key. Examples: Prices, comments, attributes (depending on a well defined set of characteristics like customer classification). If you don't have such a scenario use InfoCubes. To read data from InfoCubes is not much more difficult compared to DSO, just use RSDRI_INFOPROV_READ.

The characteristics as key figure feature was invented to support having characteristics in structure elements of queries (in other words to treat characteristics as key figures). A characteristic is always treated as a 'key' in the analytical engine, you can drill-down and filter such objects. Key figures in queries thus are never 'keys' but 'attributes'. So the gap is to treat characteristics as 'attributes' and this is exactly the 'characteristics as key figure' feature. To treat a characteristic in the data part of a DSO as a 'key' in a query in planning is in general not reasonable since this field is an attribute (a function of the key) and thus has 'update' logic.

Regards,

Gregor

[cornelia_lezoch · Accepted solution]

Hi Gregor,

thanks for the explanation.

I am not sure that I agree to the non-usage of the #.

My info object is emty because I want to have it that way. And I would not create any data junk. Because what I do now is insted of using # I fill it with XX=nothing. This means additional loops in my fox and additional fields to be changed. So the data record is not better and not worse using # or XX as a dummy value.

regards

Cornelia

[gregor_dieckmann · Accepted solution]

Hi Cornelia,

the system has to handle the general case; it might happen that in special cases it works to set characteristics values of characteristics not contained in the aggregation level to #, but nor in general.

Example: DSO has characteristics PG (product group), P (product) in key and the key figure K (revenue); the aggregation level contains PG, K, not P.

DSO data on DB

PG      P       K

pg1     p1     10

pg1     p2     20

so one will get one record in the aggregation level

PG     K

pg1    30 -> change to 40

Now your suggestion was to store

PG      P     K

pg1     #     40

in the DSO, so reading again one would get key figure value 70 in the aggregation level; this is wrong. A DSO has a key, a new record has to be inserted, an existing one has to be modified. If one stores delta values for key figures and allows duplictes with respect to PG, P one again has the InfoCube design. This is why in the InfoCube one will write K = 10 (the delta) and has to allow duplicates.

But a DSO is designed for after-image logic; assume K is not a key figure but a characteristic, what should be the 'delta' of a 'comment' or an ABC classification? Here the records have to be identified uniquely by the key and existing attributes in existing records are updated.

Regards,

Gregor