on 08-23-2016 10:39 PM
Hi,
We are working with Lumira 1.30/ BW 7.4.
There's a requirement to display % which are already calculated in the BW-BEx Structures.
However, due to the incorrect aggregation in Lumira, these are not displayed correctly in the visualizations.
Has anyone encountered such an issue? Would appreciate any insights.
Thanks.
Ashish - could you please be more specific or post some examples? We are also running in a BEx-based environment and have run into issues with percentages not matching correctly. Typically for us, we run into this when we pull in aggregations based upon other aggregations. If you are pulling in values directly from the query, I'm not sure why you would encounter issues.
It might be a data grain issue - the BEx query may be at a grain of data that Lumira either does not support or cannot access.
As for dimensional member calculations, if I am following you correctly, you will most likely unfortunately have to build those up as separate columns of calculations, which you can then pull together into a final column.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To add to what Jay said, please review the BI/BW SAP Support matrix note at https://launchpad.support.sap.com/#/notes/1869560/E - there are some limitations with BEx and Lumira
Thanks for your response, Jay!
I feel the same that it could be a data grain issue. The BEx query and Lumira visualizations are indeed at different levels.
In our case, Lumira is getting the aggregated values from BEx at a higher level than BEx.
I'll try to explain the situation below. Please note that the fields are modified from our real scenario to simplify the content in this forum.
Hope this provides the details you are looking for.
BEx Query Design
Rows contain Key Figures - Gross Sales and Net Sales
Columns contain a structure.
Structure comprises of Restricted columns Actual and Plan.
Structure also contains a calculated column Actual % Plan.
Free Characteristics contain Company Code, Customer and Month
Data Acquisition in Lumira
Rows contain Measures - Gross Sales and Net Sales
Both have aggregation set to "SUM".
Columns contain the Structure (with values Actual, Plan, "Actual % Plan") and Company Code.
Visualization
This contains a cross tab displaying Dimensions in columns and Measures in Rows.
In our case, we have chosen to display only one Dimension i.e. "Structure" in columns.
The other Dimension "Company Code" is used as a filter only.
This looks somewhat like this:
Measures | Actual | Plan | Actual % Plan |
---|---|---|---|
Gross Sales | xxx (matches BEx) | yyy (matches BEx) | xxx % yyy is not calculated correctly |
Net Sales | abc (matches BEx) | def (matches BEx) | abc % def is not calculated correctly |
Issue
Aggregation in Lumira is set on Measures (and not columns within the Structure). Hence "Actual % Plan" tries to aggregate and SUM up the values resulting in values that do not match with BEx.
Thanks, Tammy!
I did refer this document earlier. I wasn't sure about a couple of things, though:
1. Does this document also apply to version 1.30 and later?
2. Does this specifically mention anything what calculations are not supported? I may not have understood it that well. I could see that it talks about Local calculations not supported. However, based on my experience, I could infer that only % type calculations do not work. Calculations involving "+" or "-" either show up correctly or can be created in Lumira itself.
Anyways, thanks for your time to respond.
Based on my experience with Bex queries in Lumira, I am almost positive that you will not be able to get your rate calculations to match between Lumira and Bex if you are not getting the same grain of data in both. This was a hugely frustrating issue for us because we could not figure out why it was happening. Once we did, we were not able to solve the issue until Lumira 1.31 because of the data extraction governors that were in place on the BOBJ side. We wound up increasing our cell limits on both the BOBJ side as well as on the Lumira client side to be able to pull enough data to make the values match, and then we ran into a different problem that nearly caused me to go on a rampage.
I believe that Lumira does some (or all) of the calculations locally rather than just taking the calced valued directly from BEx, which is why if your grains don't match you get the wrong answer. It's also why your counts and simple sums are fine - because they are straightforward additions of extracted data rather than calculations (as you have in your rate calcs).
Thanks, Jay! for confirming.
It was very interesting to note when we observed this first. I was hoping that there would be a workaround to this in version 1.30 itself as we can not move to 1.31 at this time. But this scenario will be a definite motivation to move to a higher version of Lumira.
Hi Ashish,
Lumira does have some limitations when acquiring BEx queries.
SAP Lumira, desktop edition User Guide
But there are workarounds available. How different is the aggregation when acquired into Lumira ?
Thank you,
Varun Anand
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Varun,
We do not have any separate aggregation.
Here's the scenario:
Rows - Contains Key Figures (Measures) - Gross Sales, Net Sales
Columns - Structure which contains Dimensions and Calculation - Actual, Plan, Actual % Plan
It's the calculation "Actual % Plan" which is not showing the right numbers in Lumira (with an aggregation set to "SUM").
Also, I thought of having a workaround to calculate it in Lumira. But fell short on it as Lumira is not very flexible when it comes to performing calculation using specific dimension members.
Thanks for responding.
Hi Varun,
Thanks again for responding. Please refer to my response to Jay below.
In our scenario, we can not change the "Aggregation" as we need both "SUM" and "%" for the measures.
Also, I'm not sure if there's a way to create Calculated Columns and aggregate based on two separate values of a Dimension (as is in our case).
If I have missed any document or post describing this, would appreciate your help in pointing me to that. Thanks.
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.