Characteristic relationships aren't working...

[Former Member]

Hi all!

I was trying to set up the characteristic relationships based on a Data Store Object and faced a problem. It seems like I'm doing everything right (or at least I hope so), but the system gives me the following message: "Cannot find values for characteristic".

The structure I'm using is:

Real-time Infocube (setting char relationships on it) --> Multi-provider --> Aggregation Lvl --> BEx Query

I've loaded into the DSO all the possible combinations of the characteristic values, and I have the values in the characteristics themselves (as master data). When I chose the DSO in the Modeler, it accepted it and allowed me to "check" all the necessary fields, like everything was going alright... But when I created a BEx query and started it, it showed me an error: "Cannot find values for characteristic. Maintain the corresponding characteristic values for the characteristic '0CM_CDT1'".

I've checked everything twice and thrice, but can't find what I'm doing wrong.

I have a suspicion, though. I'm trying to do the char relationships for the article hierarchy (0CM_CDT1, 0CM_CDT2, 0CM_CDT3 and 0CM_HIEID) and all the chars have compounding with 0CM_HIEID (except 0CM_HIEID itself, of course).

Maybe there should be some special structure for DSO when the characteristics contain compounded characteristics?

Or maybe something else's wrong?..

I would appreciate any help.

Thanks.

[gregor_dieckmann · Accepted solution]

Hi,

I don't think this message comes from the characteristic relationship. Deactivate the relation and start the query again. Do you still get the messageß If yes, I think this comes from a master data check. Maybe you have not activated the master data for '0CM_CDT1'.

All InfoProviders in BW are 'closed' with respect to compounding, i.e using a compounding characteristic in an InfoProvider also the compiunding parents have to be in the InfoProvider. This is checked when you create the InfoProvider. This rule also applies to data stores.

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

Thanks for your suggestion, but unfortunately it seems not to be the case.

The master data is activated and when I set "Master Data" in the query for those characteristics, the executed query shows me all the master data they have.

The InfoProvider on which I set the characteristic relationships has all the characteristics included.

Best regards,

Andrey

[Former Member · Accepted solution]

The problem is solved... somewhat.

I checked the "Excl. #" flag for this char. relationship in the Planning Modeler and everything worked.

So now everything's working how I need it to work.

Although I don't really understand how the flag that "permits automatically valid combinations" can cause the error "Cannot find values for characteristic". If someone could clear out what this flag really does, I would be grateful.

[gregor_dieckmann · Accepted solution]

Hi Andrey,

I think that the messages come from a master data check in combination with componding. Assume you have a compounded characteristic B with compounding parent A. The master data table contains both fields A, B. The combination (#,#) is always contained in the master data table.

Depending on your data model and restrictions in the filter of queries or planning functions it may happen that you need combinations of the form (a,#) with a not equal #. These combinations are not contained in the master data table if not explicitly loaded or maintained in RSD1.

This topic is linked to 'automatically' valid combinations. Assume you have a relation containing A,B,C. Again B is compounded with compounding parent A. In addition assume that the relation is not a derivation relation. The system allows all kinds of aggregation levels. There is only a small set of rules valid for aggregation levels, e.g. a level has to be closed with respect to compounding parents and currency/unit characteristics.

So one can create a level A1 containing only the characteristics A, C. A record created/changed on this level leads to combinations of the type (a,#,c) with a a member of A, c a member of C. Here the master data value (a,#) has to be a valid record in the master data table! This is an example of an automatically valid combination, the above mentioned relation containing A,B,C will not(!) be called to check the above records since this relation needs all three characteristics.

With the 'EXCL#' feature for a relation the system also calls the relation for 'automatically valid' combinations if all relations fields can be filled; i.e. it disables the logic for automatically valid combinations: now the relations can decide what to do with these types of combinations. This feature can be used if all fields of the relation are included in all aggregation levels to have the full control of the valid combinations. In a sense, these fields then are 'duty' fields (but still the the system does not 'force' you to use 'duty' fields in all aggregation levels).

Automatically valid combinations play a special role in the following cases (cf. interface of cl_rspls_cr_exit_base)

- for automatically valid combinations derive is not called

- for automatically valid combinations check is not called

- create: besides the returned table (by the relation implementation) the system creates all automatically valid combination needed for a given selection (i.e. filter). This method is called e.g. in planning function 'create combinations' or in queries if the flag 'access mode for result values' is set to 'characteristic relationships'.

In short the 'EXCL#' flag disables this special treatment; in this case the relation implementation has the full responsibility.

The definition of automatically valid combinations in full generality is maybe too complex to be described here, but the basic idea was described above. There exist also other threads in this forum about this topic.

In your case - I think - you do not need the 'EXCL#' flag but you have to maintain the combinations of type (a,#) in the master data table and/or to exclude '#' in filters used in queries/functions if the 'create combinations' feature is used.

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

Thanks a lot for your answer, now the matter is perfectly clear!

I really appreciate it!

Best regards,

Andrey