Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
Could you please give me some clarifications concerning this issue above ?
I expected to obtain the same between
sum({<TYPE={1,3}> NETWR_SOC}
and
sum({<TYPE={1}> NETWR_SOC} + sum({<TYPE={3}> NETWR_SOC}
Thank your for your help and for any link
Adrien
You mean "are almost in the same table" like in "are in different tables"?
So what's the difference in your application then compared to my above sample (having two tables linked by a third-party field)?
I noticed that your field MATNR-ZVEN1 may link to both TYPEs 01 and 03 for some values, which I think explain the difference in your sums (and again looks similar to my above sample).
For example, check production section 008 ...., MATNR-ZVEN1 values 000000000005315694 and 000000000000260519
Have a nice evening,
Stefan
Fields TYPE and NETWR_SOC are probably not located in the same table, right?
Look at this example using your sums
LOAD * INLINE [
Type, Value
A, 10
B, 10
];
and compare to this:
LOAD * INLINE [
Type2, ID2
A, 1
B, 1
];
LOAD * INLINE [
ID2, Value2
1, 10
];
Consider where you set your selections in your set expression and what you are summing up.
Does this clarify your issue?
I have tested your example. No it doesn't help. TYPE and NETWR_SOC are almost in the same table (they are joined by a third-part field). Have a look in the .qvw attached. To help the reader :
- Have a look at the intial question : http://community.qlik.com/message/250615
- The TYPE field is in the table ZVEN182
- The NETWR_SOC field is in the table X_CDESAP
Many thanks,
Adrien
You mean "are almost in the same table" like in "are in different tables"?
So what's the difference in your application then compared to my above sample (having two tables linked by a third-party field)?
I noticed that your field MATNR-ZVEN1 may link to both TYPEs 01 and 03 for some values, which I think explain the difference in your sums (and again looks similar to my above sample).
For example, check production section 008 ...., MATNR-ZVEN1 values 000000000005315694 and 000000000000260519
Have a nice evening,
Stefan
I just solved the problem by myself. You are right, it was because some products (MATNR_ZVEN182) were in both TYPEs (01 & 03) (which is an unexpected behavior ; I will notice this point to my service). I was not able to interpret correctly your first post.
Example :
if a product belongs to TYPE 01 and 03, and his sale value is 10, then
Sales (all TYPEs) = 10
Sales (TYPE 01) = 10
Sales (TYPE 03) = 10
.. one can understand that TOTAL (all TYPEs) is not equal to 10+10 !
In other words, ({} means a selection)
sum({A,B}) != sum({A}) + sum({B}) [Cf. the title of this post]
because some elements belongs both to A and B selections.
Thank you very much for your contribution !
You're welcome.
Set analysis is different from plain old arithmetic, it's -like the name says- set theory.
For example, think of two intersecting circles. The area that is covered by both is different from the sum of the areas covered by each circle.