Cumulative Transactions

As Greg rightly said you would need a disconnected table for this, the logic behind this is that:

behind the scenes SUMMARIZECOLUMNS prepares the matrix and when you have a selection on a slicer then that code will filter query generated by SUMMARIZECOLUMNS, which will result in only those months that are selected in a slicer.

Before your DAX code in PBI starts working, SUMMARIZECOLUMNS has completed its task and gives you a matrix visual on which your DAX code has to work/iterate, so in order to get running total up to and including the month selected in the slicer you will need months selection coming from a separate table that doesn’t generate a query that filters the visual and also doesn’t have a data lineage of main Dates table.

Here is how a running total like the following works, when you select multiple values it works as you want because all the selected months are returned by SUMMARIZECOLUMNS and in the filter context created by SUMMARIZECOLUMNS, MAX check for the MAX month:

Summary

This is the query generated behind the scenes.

Summary

Problem is when you select only 1 value, SUMMARIZECOLUMNS returns only 1 selected value and that is always the MAX value, it is like being only student in a night class, you are the first, last, mean, median, mode, Standard deviation etc, lol!

Summary

image

When you use disconnected table here is what happens:

Summary

And when I uncomment the measure it gives the desired result, because of the statement

IF ( MAX ( Dates[Month Number] ) <= MaxMonthCurrentlySelected, Result ) 

Which returns BLANK if Month Number in the matrix is greater than the disconnected month selected in the slicer, and DAX engine automatically removes the blank rows from the visual:

Summary

I hope this gives you some perspective. Go disconnected table!

5 Likes