08-29-2016 12:18 PM
This one has come up quite a bit recently. The issue surrounds using Measures in Table visualizations with a Total row. The complaint is that the "Total" row is "wrong" for the measure. Technically, the total row is correct for the measure, it's just not what most people expect. What people expect is for the "Total" to display the sum of the values in the column. Measures do not do this. Measures respect the context of the Total row and is calculated within that context. Therefore, a Measure used in a column in a table visualization will likely have an unexpected value in the Total column.
There are a couple ways of fixing this. The easiest is to turn off the Total row.
Assuming that is not what you want, you can use the HASONEFILTER function to get around this issue. However, the ultimate solution will depend on how your measure is calculated.
For example, given the following data:
We wish to find the total extra Amount spent above 1000 for each year. If the amount is not over 1000, we wish to display 0. To this end, we create a measure:
MyMeasure = IF(SUM(Table[Amount])<1000,0,SUM(Table[Amount])-1000)
Adding this to a Table visualization along with Year, we get the correct answer for each of the rows, but the Total line displays 3900, not 1500 as we would expect. The figure 3900 is calculated because the Measure is performing its calculation for ALL of the rows in the table, so the calculation is (500 + 1500 + 2000 + 100 + 800) - 1000 = 3900.
Correct, but not what was expected.
To get around this problem, use HASONEFILTER to calculate the Measure one way within a row context and another way within the Total row context, such as:
MyMeasure2 = IF(HASONEFILTER(Table[Year]),
Breaking this down, we essentially wrap our original measure in an IF statement that has the HASONEFILTER function as the logical test. If HASONEFILTER equals true, we calculate our Measure as before. However, if HASONEFILTER is false, we know that we have a Total row and we calculate our Measure a different way.
08-30-2016 12:36 AM
I tend to avoid measures that are designed with a specific visualization in mind, but indeed, in the case of non-standard totals it's inevitable. In your example, the assumption is that the years are the identifiers for the rows in the table. When an additional level, e.g. Month, is added, then the behaviour of the measure will be - different.
But this aside, the part of your formula for the total would work just as well on the detail rows when iterating over VALUES(Table[Year] instead of Table itself:
MyMeasure3 = SUMX(FILTER(VALUES(Table[Year]),[Amount]>1000),[Amount]-1000)
On a detail row, VALUES(Table[Year]) would contain only one row and the filtered table is empty when [Amount]<=1000. This means that rows for years with [Amount] lower than 1000 will have a blank value. If you do want to have 0 instead of blank, just add 0 to the result:
MyMeasure3 = SUMX(FILTER(VALUES(Table[Year]),[Amount]>1000),[Amount]-1000) + 0
Great post. It give insight into why PBI is the way it is. My attempt to apply the knowledge above is failing. This matrix has muliple at a page level so the HASONEFILTER is not working out? The HASONEVALUE is not working out for me either.
Here is the measure. Edit tips appreaciated. (Credit to @Ashish_Mathur)
Forecast = if(MIN('Calendar'[Date])<[First month in which data is available],BLANK(),if(EOMONTH(MAX(Workfront[Due On]),0)>=EOMONTH(MAX('Calendar'[Date]),0), CALCULATE([3 month av],DATESBETWEEN('Calendar'[Date],[Month till where data is available],[Month till where data is available])),BLANK()))
Sorry for all the posts. Sending form my cell phone browswer was a nightmare. Here is a sample file
It would be great if there was only one subtotal row that respected the data. For example 2017-07 would be 45.34 not 78.67