Using navigation attributes in planning queries

[Former Member]

Hi all!

In one of the SAP demos I saw something like: we've got a "Store" char in planning query, and Region, Format and Climate added as free characteristics. Region, Format and Climate are navigation attributes of the Store characteristic. And when user drags, for example, Region into the planning table, he or she can enter the values on region level, and when saving the data it's being automatically distributed by all the Stores that have that Region as an attribute.

I have a somewhat similar task - I have a "Branch" characteristic that has "Country" as a navigation attribute. I have to plan data for that navigation attribute, the country, and I expect the data to be distributed by all the branches that have that country as an attribute. But when I add it to the planning query, I've got repeating rows for each branch in each country even though I don't see the branches.

What should I do to accomplish this task?

Thanks!

Best regards,

Andrey

[gregor_dieckmann · Accepted solution]

Hi Andrey,

maybe you have marked 'Country' as a navigation attribute in the cube and also contained 'Country' as a characteristic in the cube.

For your purpose it should be enough to mark 'Country' as a navigation attribute.

Example:

Branch := B in the cube

Country := B__C as a navigation attribute

Create a query with B__C, B drilled-down in the rows. Then you should get exactly the combinations of posted value you have in the cube consistent with combinations of B, B__C in the master data table. The system automatically uses system defined characteristic relationships that check the consistency of (b,c) tupels with value b in B and c in B__C.

To create all valid B__C, B combinations in the query use the flag 'acess mode for result values' based on characteristic relationships in the query (not master data!).

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor!

Thanks a lot for your help!

It's almost working as I want it to work.

But there's something I'm probably doing wrong.

I'm selecting B as a "free characteristic" in the query and hide it, and put B__C in the rows section, then choose "Master Data" for both "Access Type for Result Values" and "Filter value selection..." for both characteristics. After that I execute the query and see that everything seems to be as it should be, and after I enter data for something, it automatically distributes by the branches that have that country as an attribute.

That's weird. Because when I do as you told me to, using the flag "Characteristic Rel-ps" for "Access Type for Result Values", put B__C and B in rows (B is hidden) and execute the query, I get multiple repeating rows for each branch that has the selected country as an attribute. And system tells me that "3 characteristic combinations generated successfully" (that is correct - I have 3 branches for the selected country).

I've tried setting "Char rel-ps" for both of the characteristics, then for only one each of them - and I still get the same picture.

Could you please tell me what I might be doing wrong here? And why it seems to be working with "Master data" chosen for "Acc. type for result values"?..

Thanks!

Best regards,

Andrey

Edited by: Andrey Makeev on Feb 3, 2012 6:45 AM

[gregor_dieckmann · Accepted solution]

Hi Andrey,

you observe just a 'rendering effect'.

1. You use B as free (i.e. it is not in the list and aggregated!) and B__C in the rows. This means you only a list of B__C values.

2. You use both B__C and B in rows, and you hide B. Hide only means that the values for B will not be rendered. But in fact you have a list of combination of B__C, B values but only the B__C values will be rendered. Unhide B and put it in the free characteristics you will get the same result as in 1.

I suggested to put both B__C, B in the rows to be able to check that the correct combinations will be created. If the users are not interested in B, you should use it as a free characteristic as in 1. Then the user can drill-down B to check details if needed.

My recommendation to use the 'characteristic relationship' setting instead of 'master data' comes from the fact that before note 1478638 the latter setting created 'too many' combinations. The first setting always creates the master data, attributes combinations from the master data table.

Regards,

Gregor

[Former Member · Accepted solution]

Hi Gregor,

thanks for the explanation!

Best regards,

Andrey