Thanks great that works - though not entirely sure what is happening ! Presumably the inner SUMMARIZECOLUMNS table gets evaluated first then the other columns are referring to the values returned from the inner table and not the base table Table1 ?
ie "Products_w_no_Sales" DISTINCTCOUNT(Table1[Product]) is working on the rows returned from the inner SUMMARIZECOLUMNS table or have i misunderstood ? . If so it would be nice if you could rename the columns to reflect where they are coming from but this does not seem possible ?. The column "ZERO_S" for example cannot be referenced outside the inner SUMMARIZECOLUMNS table.
Thanks @johnfa for accepting it as the solution and the kudo,
its ready great to try to understand what is happening, so lets try:
Presumably the inner SUMMARIZECOLUMNS table gets evaluated first then the other columns are referring to the values returned from the inner table and not the base table Table1 ? YES
ie "Products_w_no_Sales" DISTINCTCOUNT(Table1[Product]) is working on the rows returned from the inner SUMMARIZECOLUMNS table or have i misunderstood ? . YES , it is doing a distinct count on column of base table Table1[Product] after the inner summarise after the filter. Then we assign this new(final) agregation (which would be show to the users) as "Products_w_no_Sales". if you change "Products_w_no_Sales" to "PPP" you see "PPP" in your final table field. https://docs.microsoft.com/en-us/dax/summarizecolumns-function-dax
groupBy_columnName: Table1[Date] ( thats why finally we see the rows for all our grouped(unique) dates)
filterTable: the chuck of prehaps confusion which is your basetable after a 1st summarise follow by a filter
The column "ZERO_S" for example cannot be referenced outside the inner SUMMARIZECOLUMNS table. It can be referenced outside the inner SUMMARIZECOLUMNS table but not outside the Tb_Products_w_no_Sales table(afaik)
Minus the issue of been chucky with a couple of uncessary tables, you can break it down in steps for understanding. And in this way if you need to refer to it outside the table, Example ZERO_S can now be refered elsewhere
TB_P1xx: Which in my opinion is the crucial part, it identifies wether each group have zero summation of the sales. the IF here is not absolute necessary, its more of to go along with your concept of "groups things by date and product returning 1 if there are no sales and 0 if there are sales for the day." although i just realised that i did the opposite ....=)
TB_P2xx: Filter only those with no sales
TB_P3xx: Count how many have no sales in each date group.
Hope it helps, let me know if you have more question or need the PBIX.
Thanks for taking the time to explain it fully thats really helpful. Being new to DAX it is certainly easier to follow if every step is broken down explicitly into a separate table although obviously a bit long winded. It is frustrating that you cant refer to columns created in the inner table in the outer table in the same block ie "Products_w_no_Sales" - I am used to working with SQL where you can easily create aliases for datasets and columns and refer to them later. Would it be possible to assign the inner table to a variable and then use that later to refer to all the columns we want ?
Of course with the indentation in powerbi it should look clearer there.( i am sorry that i didnt indent it well )
I understand how you feel , for something similiar to SQL, (use VAR as above)
but for alias , SELECT * from BASETABLE as ALIAS_MYTABLE, i think there is nothing similiar...
My personal preference when working with Powerbi and SQL is to have a view or table function on the SQL server and have powerbi query from that to do measures, YTY , simple agregation and reporting. But i am sure this is subjective 😃