Aggregation level includes filter objects...

Question

Hi,
We are using a BO universe on top of a BEX query to create WebI reports.
We now run into the following problem when filtering on a certain characteristic in the BO query.
The result set of rows is limited to the correct values, but not aggregated up to the requested aggregation level. The problem exists whether the key figure is defined as having an aggregation to be database delegated or sum.
In the query results we see the number of rows being pulled back is too high, the results displayed are correct (because aggregated by WebI). In the example below we selected three stores, but not store as a result object.
*** Query Name:Query 1 ***
** Query Properties:
Universe:Retail Sales and Stock
Last Refresh Date:9/2/10 2:29 PM
Last Execution Duration: 33
Number of rows: 4,947
Retrieve Duplicate Row: ON
** Query Definition:
Result Objects: Style Code, NSLS @ PCS
Filters ( Only RMS Billing Documents Infoprovider
AND Given Legacy Division Set
AND Given Currency Conversion Type
AND Store Key In List { 1001; 1002; 1003 }
AND NSLS @ PCS Not Equal 0
We cannot attach a document, but the actual amount of rows should have been 2,856,
the number of different style in these 3 stores.
When we include the store object in the results, we can see the number of rows stays the same (proof that it did indeed return rows on a store level and not aggregated upt to the style code...
*** Query Name:Query 1 ***
** Query Properties:
Universe:Retail Sales and Stock
Last Refresh Date:9/2/10 2:09 PM
Last Execution Duration: 13
Number of rows: 4,947
Retrieve Duplicate Row: ON
** Query Definition:
Result Objects: Style Code, Store Key, NSLS @ PCS
Filters ( Only RMS Billing Documents Infoprovider
AND Given Legacy Division Set
AND Given Currency Conversion Type
AND Store Key In List { 1001; 1002; 1003 }
AND NSLS @ PCS Not Equal 0
Is this behaviour fixed in any fix pack? Or did noone address this problem?
The problem becomes a real problem when the user wants to select everything u/i a certain date.
The number of rows are then pulled back on a style/store/day combination and easily reached 100.000 rows.
Thanks for any insight you can give on this,
Marianne

Answer 1

Hi Rik,
Thanks for at least trying
I didn't try this before, so I just did, despite the fact that the aggregation level only has something to do with the way data aggregates within webi. (I'm that desperate)
No difference, other then the fact that I now get #MULTIVALUE in the cells with multiple underlying rows.
Anyone else?
Marianne