Retail analysis models often include a competing outlet indicator to improve the quality of the model. The indicator does this by allowing the user to manage the effect that is associated with partial trading periods. For example, the true / false indicator shows whether the store has traded for all available weeks in a month. This post looks at how the competing store indicator can be implemented using powerpivot and DAX.

**The Competing Store Definition**

There are a few definitions of competitive stores (and perhaps another post to follow). In this post, the definition of competitive is a store that trades for every week in the month. If the store has not traded for all weeks, it is not considered competitive and this permits the identification of sales that occurred when;

- The store was open or closed for the month in question
*or*
- The store didn’t trade for some other reason (eg refurbishment)

**The Model**

The underlying model considers a store dimension, date dimension, and sales data. The grain for sales is { store x day } à sales amount. Although, this implementation treats the sales relation {store x day} as unique, there is no requirement to do so. The dates table follows standard structure of a date dimension table (grain of day) with the fiscal calendar attributes aligned along a 445 Calender. The fields fiscal_fullweek_key has the format YYYYWW and fiscal_fullmonth_key has the format YYYYMM. These are standard implementations where YYYY refers to the century, WW refers to the week of year and MM refers to the month of year.

The store table is a type 1 dimension (showing the ‘current’ state of the store). There is a strong argument to show the [competing store] as an attribute of the store dimension however, this would require a type 2 store dimension and intensive ETL. This is outside the management of the end user who consumes available data as it would require more intensive resources and relational constructs.

**Method**

The approach to determine whether the sale is competing or not is based on the comparison of the stores actual trading weeks in a month compared to the available trading weeks. When the two values are the same the sale is competitive, otherwise it is not. Additionally, note that this formula is applicable to each row of the sales fact because the sales fact is the only table that combines both store and date data and can therefore be used as the auto-exists cross-join of stores and dates.

For each row in the sales fact, we must determine;

- weeks_in_month as the number of weeks in the current month,
*where current refers to the row context of date (ie the number of weeks in the month of the sales date). *
- sales_in_month as the number of weeks in the current month that the store traded.
*Again, current refers to the row context of sale date.*

In order to improve readability of the formula the sales table has been extended to include a field full_month_key (formula = RELATED(fiscal_fullmonth_key)) and full_week_key (formula = RELATED(fiscal_fullweek_key))

*Formula 1 – Available Trading Weeks in Current Month (weeks_in_month)*

The available weeks in the current month are the distinct count of weeks for the related month. We can achieve this by removing the filter context of the dates table and reapplying it so that the row sales month equals the dates month (below)

CALCULATE(
DISTINCTCOUNT(Dates[fiscal_fullweek_key])
, filter(all(Dates), Sales[fullmonth_key]=Dates[fiscal_fullmonth_key])
) |

If the sales table did not include the fullmonth_key field, we could use the related function directly in the formula.

CALCULATE(
DISTINCTCOUNT(Dates[fiscal_weeks_key])
, filter(all(dates), RELATED(Dates[fiscal_fullmonth_key])=Dates[fiscal_fullmonth_key])
) |

Alternatively, we can remove the row filter context of the dates table to the extent that it only includes the current month. This is done with the ALLEXCEPT function so that the dates table filters are removed except for the listed column restrictions (as below)

CALCULATE(
DISTINCTCOUNT(Dates[fiscal_fullweek_key])
, ALLEXCEPT(Dates,Dates[fiscal_fullmonth_key])
) |

*Formula 2 – Weeks Traded in the Current Month (weeks_sales_in_month)*

To determine the number of weeks that a store traded for (in the current month), we use a similar restriction but apply it to the sales table. That is, count distinct weeks after we remove the current row filter context and reapply it based on the current month of the rows sale date.

CALCULATE(
DISTINCTCOUNT(sales[week_key])
, ALLEXCEPT(sales,sales[store_key], sales[fullmonth_key])
) |

*Formula 3 – Continuing Sales*

The final (and only visible formula) is a simple if function that compares the trading weeks to those available for a true/false output.

=if([weeks_in_month]=[weeks_sales_in_month], “Yes”, “No”)

**Final Model**

The final schema for the model is shown below. The measure [Sales Amount] is simply the sum of the sales_amount field.