BI IP - use of referenced InfoObjects in aggregation level

[Gunter_Cokl]

Dear all,

in a aDSO (planning mode) I use 2 InfoObjects:

0CUST_SALES and ZCUST_SAL

ZCUST_SAL uses 0CUST_SALES as referenced characteristic.

Now I face several problems, e.g. when both InfoObjects are on the same aggregation Level. I have a planning filter using a navi-attribute from ZCUST_SAL and when I run a FOX Formula based on this filter it  doesn't find any data.

Characteristic Relationships of Type Exit do not work, if I use 0CUST_SALES as target.

It looks like planning system has a problem when you use an InfoObject with another "referenced" one in the same planning area.

Has someone faced a similiar problem?

A workaround could be to create an InfoObject without reference, but maybe there are other ideas.

BR

Gunter

[gregor_dieckmann]

Hi Gunter,

you description does not contain enough details. A referencing characteristic just references the master data values and hierarchies (and attributes), this does not mean that you automatically have values for the referencing characteristic in your base InfoProvider, i.e. referencing characteristic B (referencing A) usually don't have the same value in the base InfoProvider. Do you want to achieve this (e.g. with a characteristic relationship)?

No data found: check whether data exists in the base InfoProvider for the filter based on B, e.g. using a query (or on the DB level).

Characteristic relationship: Describe what you want to achieve in the exit implementation: derivation(?), check only(?), source and target characteristics. E.g. a derivation relation (DERIVE) is not called when source and target are in the aggregation level; in this case CHECK is called (and may CREATE based on planning function or query settings).

Regards,

Gregor

[Gunter_Cokl]

Hi Gregor,

thank you for your answer. I try to give more details. My planning is based on ZCUST_SAL (this objects shows "Sold-to" on Sales view, references on 0CUST_SALES) and Material. But for Reporting I need also Bill-To and Ship-to. (Standard-InfoObjects based on 0Customer).

I have an aDSO which includes Keys how to distribute ZCUST_SAL / Material combination to different ZCUST_SAL / Bill-To / Ship-to / Material combinations. This works fine using standard planning function.

But for Reporting I need also 0CUST_SALES as this object shows "Bill-To" on Sales view Level. I tried to derivate this Infoobject from "BILL-TO" using the exit, but whenever I include ZCUST_SAL as Source (next to others) and 0CUST_SALES as target, exit is not called.

Another try was to include 0CUST_SALES in lookup aDSO (mentioned above) and derive it like mentioned above. But this does not work. whenever I include 0CUST_SALES into the aggregation level and the planning function no more data are found when executing the sequence. No change of filter, just this new field in the planning function (as "field to be changed").

Is there a problem because both Infoobjects are compounded to the same salea area (0SALESORG,...)? Master data are in the same sales area, so this cannot be the problem.

Best regards

Gunter

[gregor_dieckmann]

Hi Gunter,

you want to plan on ZCUST_SAL (and other characteristics) and for reporting you need 0CUST_SALES to be filled with the same values as ZCUST_SAL.

This is a derivation scenario. Don't use 0CUST_SALES in your aggregation levels but only ZCUST_SAL. Create an exit relation on your base planning InfoProvider and use ZCUST_SAL as source and 0CUST_SALES as target. Compounding parents of ZCUST_SAL are sources as well.

At run time, the system uses CHECK of a characteristic relationship to check consistency of all characteristics in the aggregation level and DERIVE to fill the target characteristics not in the aggregation level based on source characteristics contained in the aggregation level. Derivable characteristics are redundant, this is why you don't need them in the aggregation level; this is the definition of derivation.

Observe also the concept of 'automatically valid combination' (search this forum about details), for derivation this means that an initial value in the source characteristic will also not call DERIVE (by default).

Regards,

Gregor

[Gunter_Cokl]

Hi Gregor, thank you for this explanation. I checked again and made some changes, now it looks like result is fine. I don't know exactly what was the problem, I think I mixed source and target fields in Aggregation level. BR Gunter