0845 643 64 63

# Calculating Run Rate in DAX for PowerPivot

In my previous post I explained how to create a calculated MDX member that projects full year data (sales etc.) based on existing year to date data.

In this post I’ll be doing exactly the same but in DAX, the new expression language used to enhance PowerPivot data. As it’s the same desired outcome, I’m not going to repeat the background, you’ll have to look at my previous post for that.

The expressions below assume that you have a single table ‘Sales’ with a [Date] column and an [Internet Sales Amount] column.

Step 1 – What are our total sales so far this year?

We use the TOTALYTD function to work this out for us

```
=TOTALYTD(SUM(Sales[Internet Sales Amount])
,Sales[Date], all(Sales))
```

The first parameter is the expression we want to calculate, i.e. the sum of internet sales.
The second parameter specifies the date we’re calculating up to.
The third parameter is one that catches a lot of people out. We have to tell DAX the context of the date. As it stands the expression can only see the data in the selected row, by specifing all(Sales) in the filter we expand the expression to be able to look at all of the data.

Step 2 – How far are we though the year?

It’s here where DAX really shows an improvement in the functions available over and above what’s available in MDX. There’s a YEARFRAC function which calculates how far we are through the year.

```
=YEARFRAC(
CONCATENATE("01/01/"
,year(Sales[Date]))
,Sales[Date]))
```

The first parameter is the start date, i.e. the 1st January. We have to build this using the year of the selected row to ensure we get the right year.
The second parameter is the date of the record we’re looking at, Sales[Date].

Step 3 – Project the value to the end of the year

We combine the two values by simply dividing the YTD figure by how far we are through the year

```
=TOTALYTD(SUM(Sales[Internet Sales Amount])
,Sales[Date], all(Sales))
/ YEARFRAC(
CONCATENATE("01/01/"
, year(Sales[Date]))
,Sales[Date]))
```

CORRECTION
Thanks to Sandeep Nallabelli in the comments below or pointing out a bug in this, YearFrac should actually be calculated from 31st Dec instead of 1st Jan. Updated calculation should be:

```
=TOTALYTD(SUM(Sales[Internet Sales Amount])
,Sales[Date], all(Sales))
/ YEARFRAC(
CONCATENATE("31/12/"
, year(Sales[Date])-1)
,Sales[Date]))
```

Also, it is worth adding the YearFrac calculation as a calculated column in your date table so that you can use it in measures.

This chart shows how the full year run rate is adjusted throughout the year as the cumulative sales to date grows. At the start of the year it’s quite volatile, but from February it settles down with an acurate projection.

And it really is as easy as that.

Frog-Blog Out

# Calculate Run Rate (Full Year Projection) in MDX

This post explains how to create an MDX calculated member that will take a value from the cube and project it forward to the end of the year. This provides a simple mechanism for calculating what your expected total will be at year end, based upon current performance.

To do this more accurately you should use time series data mining models in SSAS and use DMX expressions to query the results, but this method is very simple and requires little effort, and will be pretty accurate so long as the data you’re modelling is fairly linear. Please note though that the more cyclical and seasonal your data is the less effective this will be.

The basic idea is that we take what we have done so far (i.e. year to date sales), look at how far through the year we are, and extrapolate the value of future months (or days/weeks/etc.) based upon values so far.

i.e. If we’re at March month end and we’ve sold 100 widgets so far this year, we’re 1/4 of the way through the year so we multiply 100 by 4 and get a prejected yearly total of 400.

This chart shows the concept of what we’re doing, and shows the full year prejections calculated in March (with 3 months of available data) and June (6 months of data). The projections obviously get more accurate the further you are through the year.

One of the points to note is that when creating a calculation like this, based upon a time dimension, the calculation should always work with any level of the dimension hierarchy selected. i.e. The user shouldn’t care whether they’re looking at a month, week, quarter or a day, the calculation should always work the same. To achieve this we simply use the .currentmember of the time hierarchy.

The following examples are based upon projecting the Internet Sales Amount measure found within the SQL Server 2008 Adventure Works DW sample cube.

Step 1 – What are our total sales so far this year?

MDX helpfully provides us with the YTD function which takes care of this for us.

```
MEMBER [Measures].[YTD Sales] AS
AGGREGATE(
YTD([Date].[Calendar].CurrentMember)
,[Measures].[Internet Sales Amount])
```

This takes the current member of the Calendar hierarchy, and creates a set of all dates before it (this year) using YTD. It then aggregates (in this case sums) the Internet Sales Amount for all of these dates to calculate YTD Sales.

Step 2 – Which period are we in?

Here we’ll use the same YTD function to create a set of all dates so far this year, but in this case we’ll count the number of resulting members. Note that because we’re using the .CurrentMember of the hierarchy, it doesn’t matter if we’re looking at a date, week or month, the MDX will work. i.e. If we’re looking at 21 Jan it will return 21. If we’re looking at Q3 it will return 3, August will return 8 etc.

```
MEMBER [Measures].[CurPeriod] AS
COUNT(
YTD([Date].[Calendar].CurrentMember)
,INCLUDEEMPTY)
```

Step 3 – How many periods are in the year?

If we coded this to only work with months then we could hard code this to 12 however we need to keep it generic to all levels of the hierarchy. So, we have to count all the cousins of the current time member [within this year]. Unfortunately there isn’t a Cousins function in MDX, and Siblings will only return other members within the same parent. i.e. siblings of May 4th would include May 1 through to May 31. To get around this we find the year of the current member by using the Ancestor function.

```
ANCESTOR([Date].[Calendar].CurrentMember
, [Date].[Calendar].[Calendar Year])
```

Then we find all of the descendants of the year, at the same level of the hierarchy (week/day/etc.) as the current member. We can then take a count as before.

```
MEMBER [Measures].[TotalPeriods] AS
COUNT(
DESCENDANTS(
ANCESTOR([Date].[Calendar].CurrentMember
,[Date].[Calendar].[Calendar Year])
,[Date].[Calendar].CurrentMember.level)
,INCLUDEEMPTY)
```

Step 4 – Calculate the Run Rate

Calculating the prejected yearly total (run rate) is then a simple calculation

```
MEMBER [Measures].[Full Year Run Rate] AS
[Measures].[YTD Sales]
* ([Measures].[TotalPeriods]
/[Measures].[CurPeriod])
```

You can then put the whole lot together and see the results…

```
WITH

MEMBER [Measures].[YTD Sales] AS
AGGREGATE(
YTD([Date].[Calendar].CurrentMember)
,[Measures].[Internet Sales Amount])

MEMBER [Measures].[CurPeriod] AS
COUNT(
YTD([Date].[Calendar].CurrentMember)
,INCLUDEEMPTY)

MEMBER [Measures].[TotalPeriods] AS
COUNT(
DESCENDANTS(
ANCESTOR([Date].[Calendar].CurrentMember
,[Date].[Calendar].[Calendar Year])
,[Date].[Calendar].CurrentMember.level)
,INCLUDEEMPTY)

MEMBER [Measures].[Full Year Run Rate] AS
[Measures].[YTD Sales]
* ([Measures].[TotalPeriods]
/[Measures].[CurPeriod])

SELECT
{
[Measures].[Internet Sales Amount]
,[Measures].[YTD Sales]
,[Measures].[Full Year Run Rate]
,[Measures].[CurPeriod]
,[Measures].[TotalPeriods]
} ON 0,
{
DESCENDANTS([Date].[Calendar].[CY 2003])
} ON 1
FROM [Direct Sales]
```

In my next blog I’ll be diong the same calculation in DAX for use with PowerPivot, stay tuned…

Frog-Blog Out

The Frog Blog

Team Purple Frog specialise in designing and implementing Microsoft Data Analytics solutions, including Data Warehouses, Cubes, SQL Server, SSIS, ADF, SSAS, Power BI, MDX, DAX, Machine Learning and more.

This is a collection of thoughts, ramblings and ideas that we think would be useful to share.

Authors:

 Alex Whittles(MVP) Jeet Kainth Jon Fletcher Nick Edwards Joe Billingham Lewis Prince Reiss McSporran

Data Platform MVP