Calculation group using filter modifier looks like a bug

[Anonymous]

Hi, guys,

I have found a very strange calculation Percentage between the measure and Calculation Group.

I expected to see the same calculations using filter modifiers in Calculation Group.

I could not find any answer in your book about this feature in calculation group.

Can you help me?Is it a Bug?

And if I add the measure Sales% under the action of the calculation group, then the calculations become the same.

How one measure can influence to another measure?It is magic.

The dataset is here:https://fex.net/s/9rpnlb0

[OwenAuger]

Hi again @Anonymous 

I have tried to isolate the conditions required to reproduce this bug, so I created a very simple PBIX to demonstrate the issue (attached).

To reproduce this apparent bug, I believe these are the requirements:

1. Create a calculation group with a calculation item that uses ALLSELECTED (), the simplest example being:
   CALCULATE ( SELECTEDMEASURE(), ALLSELECTED () )
2. Create a a matrix with at least two fields in the Rows field well.
3. Place a measure which itself does not use ALLSELECTED in the Values field well.
4. Apply the above calculation item as a filter to the matrix visual.
5. Expand the rows of the matrix in a "ragged" fashion, so that some branches are expanded to lower levels than others.

The bug can be avoided by removing any of the above conditions, for example:

1. Expanding all branches of the matrix to the same level
2. Including a measure in the matrix that does use ALLSELECTED, even in a trivial way, such as
   Sales Modified = SUM ( Sales[Sales] ) + CALCULATE ( BLANK(), ALLSELECTED () )

Does this sound right?

I intend to raise this as an issue. Let me know if you have any other thoughts 🙂

My takeway at the moment is that it is risky to use ALLSELECTED () within calculation items.

Regards

[QueryQueen]

I ran into this bug just today and I can confirm that as of April 2024, it is still not fixed. The good news is that @OwenAuger's workaround also still works.

Very nasty issue that silently produces incorrect numbers.

[denis_Co]

Thank you, very interesting solution for avoiding the bug.

[OwenAuger]

@Anonymous 

Thanks for posting! This is puzzling and certainly looks like a bug at first glance.

I agree that we should expect the same result for (1) the measure with calc item applied, and (2) the measure with equivalent code.

Also, the presence of an additional shouldn't make a difference, but it does!

I'm keen to test further and will post back.