“Danger, Will Robinson!”

I’m seeing this pop up a lot now, both in our hosting business and on forums.

If you have gone to PowerPivot.com lately and downloaded PowerPivot, you downloaded a beta (a release candidate) of PowerPivot v2, and probably didn’t know it.

That’s not a big deal except for:

1. The release candidate likely isn’t as stable as the most up-to-date release of PowerPivot  v1
2. Workbooks created in v2 CANNOT be opened by v1, and that includes v1 server!
3. There is no way to “downgrade” a v2 workbook to v1, so if you want to use a v2 workbook on v1, you have to start over

So be careful – v2 is awesome but using it unknowingly may have side effects you didn’t expect, at least until v2 is official released and the rest of your organization upgrades.

I’ve notified MS of this problem but so far they haven’t fixed it.  Both v1 AND v2 should be available for download, with v1 the default, and both clearly marked.

If you want to download v1, here is the link:

V1 PowerPivot for Excel – Download Here

“…then they start thinking that, ‘where there’s smoke there’s fire’ logic…”

Continuing the Impromptu Series of Simple Real World Examples

The Mr. Excel PowerPivot Forum has inspired me to change gears a little bit and focus more time on simple techniques that don’t break the DAX Spicy Scale while still being very useful, everyday stuff. I sometimes take this stuff for granted and end up looking for topics that are much more “clever” when in reality we all can use a good dose (or two, or ten) of basic useful examples.

Medical Treatments – Are They Effective?  Counterproductive?

A user over at the forum named “Mirknin” posted the following question:

I have a relatively simple data set where each row represents a week, each week has a number of data columns. Occassionally, however, we have treatments and I set up Excel with a column where the treatment is recorded as 1 – i.e. a treatment occurred that week, otherwise the cells are left blank.

I AddColumn in PowerPivot to generate a unique identifier (through the usual ampersand formula) to represent whether a treatment occurred in a specific week. Using the Slicer, I can PivotTable to see the data from the row where the treatment took place because all this info is related to that week, but seeing the data for following four weeks would let me see whether the treatment had made an effect.

I guess my query is whether the Slicer can be modified in such a way as to report the row it’s associated with plus subsequent rows…

Data Set:  Let’s Use Trees Rather than People

When I was manufacturing sample data for this I got a bit squeamish about it.  Not for the obvious reasons though – I’ll explain at the end of the post.  But for now, just know that we’re going to work with Trees, like in a Botany lab, and some experimental treatment they are receiving.

We have a calendar of treatments – a list of dates and Yes/No for each:

Calendar of Treatments

And then a table of health readings taken for various trees in the lab on specific dates:

Tree Health Measurements

Normal Slicer Function Across Relationships

Notice that the two tables have the little “relationship” icons on the Date column?  These two tables are related on that column.  So if I write an “average health” measure and put the Yes/No treatment field on a slicer, I get:

But if I put Date on rows, we’ll see that all I am “getting” in my health scores is the health of the tree on the day the treatment was applied:

But I Want the Health Scores Over the Two Days AFTER Treatment!

I want to track a range of dates after a treatment is applied, so I need to do something different here.

What I need is a new column in the TreatmentCalendar table:

If I use THAT column as a slicer, or even better, put it on rows of the pivot, I get what I want:

Hey, check it out!  Trees are doing a little bit better in the two days after they receive treatment!  (That’s lucky, since this sample data was created using RANDBETWEEN).

But how did I build that “Recently Treated” Calculated Column?

Did I say up front that this was going to be LOW on the DAX Spicy Scale?  Hmm.

First let me repeat a longstanding recommendation:  if you are using a database as your data source for PowerPivot, you should seriously consider having this calculated column generated in the database and NOT in PowerPivot.  There are multiple benefits of that, as long as it’s an option.

If it’s not an option, you still have two choices.  For something relatively quick and dirty, you can do the calc column in Excel and just paste an entirely new TreatmentSchedule table into PowerPivot.

But for larger data sets, or cases where you can’t have that manual intervention step every time you get new data, you’re gonna have to write the calc column in PowerPivot.

And since PowerPivot lacks A1-style reference, and this calc column has to look at rows other than just the current row in order to get its answer, you have to use the dreaded EARLIER function.

Primer:   Simple Use of the EARLIER Function

Before we do something advanced with EARLIER, let’s cover the basic usage first:

Say I have the following VERY simple table like this:

And I want to add a third column that is the total for each customer:

How do I do that?

The calc column formula for that third column is this:

=CALCULATE(SUM([Amt]),
           FILTER(ALL(‘Table’),
             ‘Table’[Customer]=EARLIER(‘Table’[Customer])
                 )
          )

Explaining EARLIER() in depth may be its own post.  Yeah.  This was probably the LAST function I learned to use.  It’s an ongoing joke between me and the Italians actually.

Here’s the Formula for the RecentTreatment Yes/No Column

With that background in mind, here is the formula for the Yes/No column.  I actually did it in two columns:

That 1/0 column is the tricky one.  The Yes/No column is just a “cosmetic” column built using IF.

Here’s the 1/0 formula:

=CALCULATE(COUNTROWS(TreatmentCalendar),
           TreatmentCalendar[IsTreatmentDay]=”Yes”,
           FILTER(ALL(TreatmentCalendar),
                  TreatmentCalendar[Date] <
                       EARLIER(TreatmentCalendar[Date])
                       &&
                  TreatmentCalendar[Date] >=
                       EARLIER(TreatmentCalendar[Date])-2))

Easy right?

I Promise to Come Back and Explain This!

EARLIER isn’t all that bad really and neither is the formula above.  But it definitely feels a lot harder than an Excel pro wants it to be.  Given the length of this post however I think I’ll do that next time.

Calling Marco and Alberto!

There are a couple of obvious questions here that my simplified example just outright skipped:

1. What if I have more than one kind of treatment?
2. What if not all “patients” receive the same treatment, and/or on different days?
3. Can I use a slicer to control how “wide” the range of dates is rather than hardcoding 2 into my formulas?

The fact that I was dodging those problems in this post is why I was squeamish about using people as the example rather than trees.  And all three of those make this problem a lot harder.

And what do we do when we hit a problem that goes beyond the powers of mortal Excel Pros?  We throw up the Boot Signal of course:

I’ve been spending some time on the Mr. Excel PowerPivot forum over the past few days and I must say I am enjoying the experience.  The blog is essentially a one-way form of communication, given that far less than 1% of views result in comments.

But a forum!  Aha!  That is different!  I encourage you to head over there and drop a question, or maybe even try your hand at answering a question or two when they pop up.

Comparison Across Trials:  A Simple and Useful Example

Here’s one that I particularly liked because it’s practical and ultimately pretty simple on the DAX Spicy Scale after a few posts of higher complexity (but also extreme utility). 

A user over there on the forum named “TopDown” asked a question that I will paraphrase here.  Imagine you have a dataset like this:

Measurements Table:  A Series of Measurements Loaded into PowerPivot

Basically you have a set of sensors (111 through 115 in this data) and you take a set of measurements at each sensor (temperature and pressure in this example).  Then you repeat the measurements over multiple experiments – trials 1, 2, 3, 4, etc.

Topdown had a few questions:

1. How do I compare the results of each trial back to the first trial?  Absolute difference versus trial #1 and percent difference versus trial 1.
2. Do I have to create calculated columns for the absolute and percent difference for each measurement like temperature?  (Topdown said he has MANY more than two measurements)
3. And if the answer to 2 is “yes,” then how is PowerPivot useful?  Once I have the calc columns, I can create this in a normal pivot.

I think intuitively, Topdown sensed that this is a great place to use PowerPivot, and just couldn’t put his finger on the how.  He was right.  And I really liked this problem because it is so different from the sorts of problems I work on most of the time.

Solution #1:  Nothing Fancy

Hey, if you ALWAYS want trial #1 to be the baseline, this is pretty easy.  Let’s focus on Temperature for a moment, with the understanding that Pressure will be solved the same way.

First we create a basic measure, AvgTemp:

[AvgTemp] = AVERAGE(Measurements[Temperature])

Then we create a version of that measure that ALWAYS returns the value for Trial 1:

[Trial1Temp] =
CALCULATE([AvgTemp], Measurements[Trial Number]=1)

Put both of those on a pivot with Trial Number on rows:

The AvgTemp measure respects the Trial Number filter on rows, just like normal measures do.  But the Trial1Temp measure, by virtue of CALCULATE(), overrides that filter and sets it to Trial 1.  The only place the two measures “agree” is for Trial 1, as expected.

A couple of quick subtraction and division measures follow:

[Delta Temp] = [AvgTemp]-[Trial1Temp]

[Pct Change Temp] = [DeltaTemp]/[Trial1Temp]

Yielding:

Again, that first row (Trial 1) is pretty useless, but the others are doing what we expect.  If that’s distracting, we can filter the pivot to NOT display Trial 1, or we can put Trial on a slicer.

No calc columns required.  You just can’t do this in “normal” Excel.

We can stop here and have a quite useful solution, but let’s get just a bit fancier

Solution #2:  Let the report consumer choose which trials to compare!

Folks, I am addicted, yes, ADDICTED to what I call “disconnected slicer tables.”  What do I mean by that?  I mean, tables that I import into PowerPivot for the sole purpose of parameterization.  Let the report consumer make a selection, I “harvest” that selection via a simple formula, and then I feed that parameter into my other measures.

I call these tables “disconnected” because I do NOT create relationships between them and the other tables – they are islands.

Here’s one I just pasted into the model.  Note that TrialSlicer2 is identical.

TrialSlicer1 Disconnected Slicer Table
(TrialSlicer2 Table is IDENTICAL)

Put both of these new single column tables on slicers and they have ZERO impact on my pivot, since there are no relationships:

No matter what I select on those slicers, [AvgTemp] keeps returning 50.65, because there is no relationship to the Measurements table.  The field list is warning me about that, but I don’t want to create one.

Instead, I write measures to “harvest” the user’s selections on those slicers, so that I can use them as parameters:

[SelectedTrial1] =
IF(COUNTROWS(VALUES(TrialSlicer1[Compare To Trial]))>1,BLANK(),
    MAX(TrialSlicer1[Compare To Trial]))

[SelectedTrial2] =
IF(COUNTROWS(VALUES(TrialSlicer2[Compare To Trial]))>1,BLANK(),
   MAX(TrialSlicer2[Compare To Trial]))

The measures are identical except for the tables they reference, and which tables I “anchor” them to in the field list.  The results look like:

OK, now that I have those two parameter measures, I can modify the [Trial1Temp] measure from above to no longer be “hard-coded” to Trial 1.  Now I can make it variable by parameterizing it using [SelectedTrial1]:

[Trial1Temp] =
CALCULATE([AvgTemp],
   FILTER(Measurements,
          Measurements[Trial Number]=[SelectedTrial1]
   )
)

Note that I only have to use FILTER() inside the CALCULATE simply because the “normal” parameters to calculate will NOT accept a measure name on the right side of the equals sign.

This new measure responds nicely to the selections made on the first slicer, whereas AvgTemp keeps ignoring it as always:

Now I can write a new [TrialXTemp] measure that is exactly the same as Trial1Temp except that it respects [SelectedTrial2] instead of [SelectedTrial1].  Update my Delta and Pct Delta measures and now I have a completely interactive pivot:

Neat huh?  And still pretty simple.

Download the workbook, more variations, etc.

Download the workbook here

And for another example of disconnected slicer tables, see here.

And naturally, if you wanted to write a measure that automatically returns the delta between trial N versus trial N-1, you can always use the Greatest Formula in the World.

Yes, That IS a Measure

Third and Final Mini-Post for Today

Got a question from a friend yesterday that made me realize I should share this:  in PowerPivot, your formulas do NOT have to return numbers.  As I’ve shown several times, they can return dates, but they can also return just plain and simple text.

For instance, check out the formula for that Trend measure above:

[Trend] = IF([$ - Sales] > [$ - Sales YAG], “Up”, “Down”)

[$ – Sales] and [$ – Sales YAG] are both measures (“current sales” and “sales year ago.”)  So this IF() is 100% dynamic and responds to whatever fields and filtering/slicing you’ve done on your pivot!  If sales have gone up since last year, it returns “Up,” otherwise it returns “Down.”

One of those cool little tricks that comes in handy from time to time

Click Image to Visit the Forum

The other day I suggested to Bill Jelen that he might want to add a PowerPivot-dedicated forum on MrExcel.com.  I wasn’t sure what he would say, to be honest.  I mean, he didn’t have a dedicated forum for really anything else – there wasn’t one for VBA, wasn’t one for formulas, wasn’t one for charts.  Instead basically all of those are combined in one single forum.

I respect that approach, really.  If my question involves formulas, charts, and VBA, where would I put such a question?  If he’d segmented the forums like that, it may have fragmented the discussion and ultimately resulted in an ineffective forum.

So I was perfectly prepared for him to say “good idea Rob but I’d rather not introduce noise with a new forum.”  Grudgingly I would have been forced to accept that.  But I was hoping he’d bend the rules just a bit here and make an exception, since PowerPivot still IS very new to the Excel audience.

I was overthinking it.  He loved the idea.  And the forum is already off to a decent start.

So if you have a question, pop on over there and post it.  Also, feel free to answer questions as well – I’m pretty sure I’m going to fall behind soon.

Oh, and be kind to newcomers.  One of the benefits of this new forum is that the legions of Excel pros who frequent MrExcel.com will undoubtedly notice all the activity and wonder what this whole “PowerPivot” thing is all about.

Here’s the link again:

http://www.mrexcel.com/forum/forumdisplay.php?f=29

“I have detailed files.”

A few quick mini-posts today.  First up, I was recently asked if there was a way to see the title of every post and its URL all in one place for reference.  And the answer is…  no, but there should be.

Next week I hope to add a page to the site that provides that sort of index.  In the meantime, here’s a really rough export of all 300+ post titles and URL’s.  It’s not perfect by any stretch but you may find it useful in the meantime.

It is, of course, in Excel format

Click here to download the list of all
300+ posts and their URL’s

Guest Post by David Churchward 

You’ll often hear us Accountants referring to things like adjusting for timing differences or prepaying costs or deferring revenue.  This is often interpreted as “massaging the numbers”, but, believe me, there is a very reasonable theory behind it.  These sort of adjustments can be made for a number of reasons, but the main underlying concept is that adjustments have to be made to ensure that the transaction is reflected in the period to which it relates.

In this post, I’ll explain how prepayments and revenue deferrals work together with the DAX measures that drive these calculations.

What are Timing Differences?

It’s worthwhile just taking the time to understand what we’re trying to do here.  Take, for example, a support contract that you bill to your customer in advance for 12 months.  You invoice the customer in advance and the customer duly pays.  However, as per accounting principles, you have to reflect the fact that the invoice relates to 12 months worth of support.  In it’s simplest sense, your Profit and Loss should therefore see 1/12th of that revenue in each reporting month.  Since the invoice is for a full 12 months, we have to create transactions to defer the element that relates to future periods, entering the balance onto the Balance Sheet.

As a quick example of the calculation, at the end of the first month to which the support contract relates, you would defer 11/12ths of the invoice value:

Deferral Value = Invoice Value * (Number of Future Months / Total Months on Invoice)

We would therefore see 1/12th of the invoice value on our Profit & Loss and the remaining 11/12ths would be sat on our balance sheet.

Referring to Prepayments separately from Deferred Revenue (or Deferred Costs) for that matter is simply a matter of terminology.  The underlying concept of the calculation is the same.  I consider everything to be a Prepayment in this sense.  The only difference is where the transactions sit in the Profit & Loss and Balance Sheet statements.

Note – Accountants may defer revenue or costs for other reasons.  This post is simply a calculation to reflect the timing difference adjustment.

Days or Months

In the simplified example above, I’ve used a monthly concept that allows for a simple allocation of the transaction value to the Profit & Loss in equal monthly values.  However, as we know, the number of days in each month can differ.  For this calculation to be more accurate, we should pro-rata the calculation based on the number of days in that month.

The DAX measures that I show in this post will allow for selection of Monthly Deferral / Prepay or Daily Deferral / Prepay.  Which you use depends on your accounting policy.

Data Structure

My data structure is as follows:

Fact Table (Prepayments)

I have a core fact table which contains all transactions that require a prepayment or deferred revenue adjustment.  I have called this table Prepayments.

The key elements to this table are as follows:

Date – This is the transaction date of the invoice posting

Nominal_PandL – This is the Profit & Loss Nominal Ledger account that the invoice was posted to

Nominal_Prepay_BS – This is the Balance Sheet Nominal Ledger account where the prepayment or deferral will be posted to.

Start / End – These are the start and end dates of the transaction.  If the invoice relates to a period from 1st Jan 2012 to 31st Dec 2012 then these dates would be 01/01/2012 and 31/12/2012 respectively.

Method – This is either MONTH or DAY depending on the level of granularity that you want your calculation to be calculated at.

PandL_Values – This is the total value of the invoice charge.

Prepay_Start / Prepay_End – I’ll come onto these alternative dates shortly.  In brief, these exist because your prepayment timeframe may differ from the strict dates to which the invoice relates.

Days Table

This table holds a sequential, unbroken list of dates (Date) together with associated attributes including Month End Date, Previous Month End Date, Month Start Date and Next Month Start Date.  These attributes become relevant in our measures and, whilst these can be calculated at run time, it’s easier to take care of them this way.  The purest would be correct in suggesting that there’s a potential performance impact, but dealing with these aspects in our measure may confuse the issue for now!

Months Table

Similar to the Days table, this table holds a collection of attributes relevant at the month level including Month End Date, Previous Month End Date, Month Start Date and Next Month Start Date.

Start Dates Table

This is another sequential list of dates which is joined to the Start field on the Prepayments table.  I’ll come on to the PrepayStartdate field shortly.

End Dates Table

This is another sequential list of dates which is joined to the End field on the Prepayments table.  You’ll notice the absence of a third field which, again, I’ll come on to.

Table Relationships

The only relationships that exist are between the Prepayments table and the Start_Dates and End_Dates tables.

Dates That Span Periods

A charge period can be anything.  In it’s simplest form, it would be for complete months starting on the first day of a month and ending on the last day of a month.  However, things are never that simple.  Unfortunately, you could get a charge that is for 3 months from 14th Jan 2012 to 13th Apr 2012 as an example.  The time between these two dates is indeed 3 months, but the charge covers 4 discrete calendar months.

If you’re using a Days method of apportionment, this isn’t a problem.  However, if you’re apportioning on the basis of months, you have 3 options in this example:

1. Take the 3 equal months charges as Feb, Mar and Apr
2. Take the 3 equal months charges as Jan, Feb and Mar
3. Take equal monthly charges for Feb and Mar with a pro-rata charge for Jan and Apr.

In truth, if you’re going to even attempt option 3, you would probably be better off jumping straight for the Days apportionment and circumvent the problem!  Options 1 and 2 depend on accounting policy and president.  The prudent option would probably be to go for option 2 for costs (taking them as early as possible) and option 1 for Revenue (taking later rather than earlier).  On the basis of consistency, I feel it’s best to prescribe this in your accounting policies and then use the same method for everything.  Having said that, the best option is almost certainly to take a Days approach.

For the purpose of this post, I’m going to use option 1.  This means that I’ll translate any start date that isn’t the first day of the month to the first day of next month.  I create two calculated fields on my Prepayments table as follows:

Prepay_Start

=IF(Prepayments[Method]=”MONTH”,RELATED(Start_Dates[PrepayStartdate]),Prepayments[Start])

Prepay_End

=IF(Prepayments[Method]=”MONTH”,RELATED(End_Dates[MonthEndDate]),Prepayments[End])

These measures retrieve an alternative date from the Start_Dates and End_Dates table.  For any mid-month dates, this table holds a PrepayStartdate of the first of the next month.

The Months Approach

Firstly, let’s just remember our simplified equation to give us the deferral value:

Deferral Value = Invoice Value * (Number of Future Months / Total Months on Invoice)

And now we’ll jump straight into the DAX

Month_Prepayment

=IF(COUNTROWS(VALUES(Months[MonthEndDate]))=1,

IF(LASTDATE(VALUES(Prepayments[Prepay_Start]))<LASTDATE(VALUES(Months[MonthEndDate]))

&&LASTDATE(VALUES(Prepayments[Prepay_End]))>LASTDATE(VALUES(Months[MonthEndDate])),

CALCULATE(

SUMX(Prepayments,

Prepayments[PandL_Value]

*(

(CALCULATE(COUNTROWS(Months),

DATESBETWEEN(

Months[MonthEndDate],

LASTDATE(VALUES(Months[MonthEndDate])),

LASTDATE(End_Dates[MonthEndDate])

         )

       )-1

     )/

CALCULATE(COUNTROWS(Months),

DATESBETWEEN(

Months[MonthEndDate],

LASTDATE(Start_Dates[PrepayStartdate]),

LASTDATE(End_Dates[MonthEndDate])

         )

   )

  )

),

Prepayments[Method]=”Month”

    )

)

)

The first two IF statements in this measure calculate when we want the rest of the measure to evaluate.  We want this measure to evaluate when:

1. The number of month end dates on our report is 1 (because anything else is likely to return an error)
2. The prepayment start and end dates fit within the range of our report.  This, essentially, tells the report which month end dates to display and the rest of the measure uses these dates to evaluate the correct result to display.

We then use a CALCULATE statement to calculate our basic equation:

Deferral Value = Invoice Value * (Number of Future Months / Total Months on Invoice)

Invoice Value = SUMX(Prepayments,Prepayments[PandL_Value]

Number of Future Months =

*(

(CALCULATE(COUNTROWS(Months),

DATESBETWEEN(

Months[MonthEndDate],

LASTDATE(VALUES(Months[MonthEndDate])),

LASTDATE(End_Dates[MonthEndDate])

         )

       )-1

    )

This calculates the number of month values in the Months table using the COUNTROWS function that sit between the MonthEndDate on our report and the MonthEndDate of the end date of our transaction.  I then subtract 1 to reflect that the MonthEndDate of the report is not included as it is the current reporting month.

Total Months on Invoice =

/

CALCULATE(COUNTROWS(Months),

DATESBETWEEN(

Months[MonthEndDate],

LASTDATE(Start_Dates[PrepayStartdate]),

LASTDATE(End_Dates[MonthEndDate])

         )

   )

Once again, I’m counting the number of entries in the Months table that sit between the start and end dates of our prepayment timeframe.

I then apply a filter to the CALCULATE statement to ensure that this measure is only applied to transactions where the Method is set to “MONTH”.

So why do we have to use SUMX for the Invoice Value?

The simple answer is that we need to conduct this equation at the transaction level of granularity and then SUM the results.  The main reason for this is that we’re using a division calculation which is only relevant at that level and becomes confused and meaningless when aggregated.

In order to show this, I’ll explain a simple example of converting USD to GBP with some theoretical exchange rates:

What are the values for X and Y?  We obviously know that Y needs to be 150, being the sum of the two GBP values.  However, if we use SUM, we wouldn’t get that answer.  The answer that you would get depends on how you condition your measure but you wouldn’t get an answer of 150, it’s more likely to be 150/2=75 (where MAX is used in the equation) or 250/3.5=71.42 (where SUM is used) or 250/1.75=142.86 (where SUM and AVERAGE is used).  The correct value only comes about when you use SUMX which sums the underlying outcomes of the equation and evaluates at the granularity level of the table that you specify (in our case the base level fact table – Prepayments).

This is a very brief outline of a very complex and clever function.  In short, if you want to simply add the outcome of underlying equations, SUMX is the way to go.

It’s worth checking out one of my favourite ever posts to start getting to grips with SUMX – SUMX() – The 5 point palm exploding fxn technique.

The Days Approach

This uses the same methods and concepts as the Month approach.  The only difference is that we’re evaluating to the number of days in the relevant periods of time.

Days_Prepayment

=IF(COUNTROWS(VALUES(Months[MonthEndDate]))=1,

IF(LASTDATE(VALUES(Prepayments[Prepay_Start]))<LASTDATE(VALUES(Months[MonthEndDate]))

&&LASTDATE(VALUES(Prepayments[Prepay_End]))>LASTDATE(VALUES(Months[MonthEndDate])),

CALCULATE(

SUMX(Prepayments,

Prepayments[PandL_Value]

*(

(CALCULATE(COUNTROWS(Days),

DATESBETWEEN(

Days[Date],

LASTDATE(VALUES(Months[MonthEndDate])),

Prepayments[Prepay_End])

                    )-1

  )/

CALCULATE(COUNTROWS(Days),

DATESBETWEEN(

Days[Date],

Prepayments[Prepay_Start],

Prepayments[Prepay_End]

      )

             )

         )

      )

,Prepayments[Method]=”Day”

  )

       )

  )

Prepayments Total

We now have two measures to evaluate our Days Prepayments and our Months Prepayments.  We can bring these together in one measure as follows:

Prepayments_Total

=SUMX(Prepayments,[Month_Prepayment]+[Days_Prepayment])

Once again, I have to use SUMX to ensure that this measure sums the total of the underlying calculations.

The “Values Not Prepaying”

So we’ve dealt with the reducing balances associated with Monthly and Daily Prepayments and Deferred Revenues.  However, what about a situation where the invoice charge relates to future months that haven’t yet been reached?  For example, we receive an invoice in January that relates to April and beyond, as in the screen shot above where the last entry has a transaction date of 10th Jan but relates to a period April to October.  In this instance, we have to prepay (or defer) the full amount of the invoice for January, February, March and April.

Value_Not_Prepaying

=CALCULATE

(

SUMX(Prepayments,

Prepayments[PandL_Value]

),

FILTER(Prepayments,

Prepayments[Date]<LASTDATE(VALUES(Months[MonthEndDate]))

            ),

FILTER(Prepayments,

Prepayments[Prepay_Start]>LASTDATE(VALUES(Months[MonthEndDate]))

  )

   )

In this measure, we once again use SUMX to ensure that we SUM the outcome of the underlying evaluations.  However, we apply two filters to limit the selection to situations where certain criteria hold.  This is an alternative to preceding the CALCULATE with an IF statement to conduct this evaluation first.

1. The first filter evaluates when transaction date is less than the MonthEndDate of the report column
2. The second filter evaluates when the Prepay_Start date is greater than the MonthEndDate of the report column.

We then add this into our Prepayments_Total measure as:

Prepayments_Total

=SUMX(Prepayments,[Month_Prepayment]+[Days_Prepayment]+[Value_Not_Prepaying])

And there you have it.  Our Balance Sheet layout above shows the total value of each transaction that needs to be prepaid or deferred in each month.

What This Means to Accountants

For those Accountants amongst you, you’ll no doubt have cottoned onto the fact that, if you’re careful, this could be your prepayments and deferred revenue reconciliations conquered.  The process that I’ve always implemented is as follows:

1. Ensure that all transactions are posted to the Profit and Loss in full, as if the P&L was going to take the whole value in one period.
2. Capture prepayment start and end dates on each transaction
3. Extract the data into a PowerPivot application such as this.
4. Refresh to give you the values that need to be prepaid (as per the above screenshot)
5. Journal the appropriate values between the Profit and Loss and Balance Sheet on a reversing journal.
6. Next month the previous transaction will reverse and you do the same again.

By doing this, you’ve got a self reconciling Balance Sheet for Prepayments and Revenue Deferrals (and all transactions for that matter that have a straight line release – for example, you could use this for elements of Fixed Asset Depreciation but that’s a whole other post).

And One More Thing

You may have noticed in the first graphic that there was also a Profit & Loss impact section to the report.  I’ll come onto this in a future post but it uses similar concepts to the measures in this post.  With this in place, you’ve got elements of a forecast P&L, you’re on course for Recurring Revenue Assurance analysis and you’re putting in place the building blocks of a full Finance Business Intelligence Application that’s just dying to be exposed in SharePoint as per Rob’s post In the Browser Aesthetics Yield a Greater Return.

Sales Measure Returns the Same Value for Everything:  We Solved the Calendar/Periods
Problem But Now We Have a Products/Category Problem

Quick Recap:  We Created a Separate “Periods” Table

In last week’s post, I explained how PowerPivot can very easily help you solve the “Budget vs. Actuals” problem or any other problem where you have data sets of different granularities that you want to compare in a single report.

The crux of the problem in my example was that my Budget table only budgeted down to the Month level whereas my Sales table went down to the day level.

To solve that, I created a separate table that only contained months (no sales or budget data, just months), and assigned a “PeriodID” to each month.  (I could have just as easily called it MonthId).

The Newly-Created Periods Table

I then linked that PeriodID column to the PeriodID column that already existed in my Budget table:

And then created a new PeriodID column in my Sales table using a formula:

Resulting in a three-table setup that looks like this:

Which then allows me to use fields from that Periods table on slicers (or on rows or columns) while using measures from both Sales and Budget in the same pivot:

And that, my friends, is a very useful thing indeed.

Could I have just added the PeriodID column to Sales and Stopped?

This is an important question for us to stop and consider.  Once I had a PeriodID column in both Sales and Budget, could I have skipped the creation of the Periods table and just moved on?

No.  I could not.  And there are two reasons.

Reason #1:  I can’t create a relationship between Sales and Budget.

Each PeriodID Appears More than Once in Each Table, So You Can’t Relate
Sales Directly to Budget or Vice Versa

That’s just the way relationships work.  The matching column needs to be unique (no value appears more than once) in at least one of the two tables.  No need to really worry about why, but if you think about how VLOOKUP works when you set the last argument to FALSE, it’s pretty similar.

Reason #2:  Without a relationship, PeriodID from one table doesn’t work with measures from the other.

Look what happens to Budget measures if I use PeriodID from the Sales table:

PeriodID from Sales Table Results in Broken Budget Measures
(and a relationship warning)

Yep, all busted.  And if I use PeriodID from the Budget table, I’ll get good Budget numbers but the Sales numbers will be hosed instead.

THAT is why the third, new, separate Periods table is required.  When I use fields from THAT table on my pivot, I can use measures from both Sales and Budget at the same time and nothing is broken.

So we use the Periods table as a master filter of sorts, one that can drive filters down into both Sales and Budget.

“Master Filter” Table is a MUCH better description than “Bridge”

I debated using a “bridge” metaphor to describe the role of the Periods table but I think that’s misleading – a bridge helps you travel from point A to point B:  A –> Bridge –> B.  That would make you think that we’re “starting” on the Sales table and “traversing” the Periods table to get to the Budget table.

But that’s not how it works.  Neither Sales nor Budget is “in charge” here – neither is the starting point.  There are two separate paths here:  Periods –> Sales, and Periods –> Budget.  The diagram drives that home:

So you should think of the Periods table as being “in charge” here.  Which makes sense, since you have to use it on the pivot, and can’t use PeriodID from either Sales or Budget.

Extending that Rule to Fields Other than PeriodID

This is the crux of what I left out of my previous post, and it’s an important rule to drive home:

When you have separate data tables that cannot be combined into a single table (as is the case with Sales and Budget), you CANNOT use row/column/slicer fields from one table in a pivot with measures from the other table.  You MUST have a separate “master filter” table, and use fields from THAT table in your pivot.

So does that apply to fields other than PeriodID?  You betcha.  Guess what happens if you use a Product Subcategory or similar field from the Budget table in a pivot that contains a Sales measure (or vice versa)?  Yeah, same problem as trying to use PeriodID from Sales as we did above:

What’s the solution?  A separate master filter table for Products!

And that may be as simple as a single column:

Wash, Rinse, Repeat

Once you have measures from two different data tables, every row/column/slicer field you use requires a separate master filter table.

It may sound tedious but it’s actually quite quick.  To easily create such a table you can even just use  a pivot: 

1. Put the ProductSubCat field from either Sales or Budget on rows.
2. Copy/paste that column of unique values into PowerPivot as a new table.
3. Create the relationships to Sales and Budget.  
4. Use fields from the newly created master filter table in your pivot.  Done.

(Better to get someone to add a new view or table to a database for you if that’s available, but copy/paste works well otherwise).

Also Useful for Single Table Situations!

One last point:  even when you only have a single table of data, like Sales, it’s often still quite useful to create separate master filter tables.

Why is that?

Because when you create master filter tables, it gives you the opportunity to remove lots of columns from your “big” table.

Imagine a sales table that, in addition to columns like Quantity and Amount, also contains columns like CustomerID, CustomerGender, CustomerAge, CustomerAddress1, CustomerAddress2, etc.

If you leave CustomerID in the sales table but “move” all of the other customer columns into a separate Customer table, and then link the two tables by Customer ID, you can reduce the number of columns in your Sales table by a significant number.

And that can sometimes shrink your files dramatically, AND speed them up.  See this post for an example.

–

Last week’s post about the importance of formatting spreadsheets published to SharePoint drew a lot of interest, including from some of my old colleagues on the Excel team back in Redmond.

Dan Battagin is one of those guys who seems to have a special deal worked out with Time.  As in, Time has agreed NOT to apply to him.  While often doing the work of two or three people at MS, Dan was typically completely remodeling his house, staying super-fit, and as a hobby, programming a number of robust applications in his “free time” at home.

So when Dan sent me a list of tips he’d been compiling on spreadsheet formatting and related topics, naturally I pressed him to expand that into a blog post.  He said “well I’m not sure how long it will take me, no promises,” then sent me the following opus about 36 hours later.  Showoff.

Yes, it is possible to create nice looking spreadsheets

Guest post by Dan Battagin

As a member of the Excel team I’ve been known to wear clothing that says “recalc or die,” (yes, I’m a geek) and one thing that makes me smile is a great looking spreadsheet. Luckily, I smile other times too, because basic spreadsheets don’t generally look that great – like everything, Excel gives you the tools, but leaves it up to you to use them.

Today, I’ve pulled together 15 tips that can help you step up your spreadsheet design So let’s jump right in and create some sweet looking spreadsheets!

Here’s a pretty typical spreadsheet. It shows data about a Windows Phone 7 application, to help understand how much it’s getting downloaded, and what its rankings are in the phone marketplace.

I see a lot of spreadsheets like this – it works, and has all the data you need. But boy is it ugly. In fact, I’d call it ugly three ways:

1. Layout – nothing is really organized. It’s like someone threw up data in the sheet.

2. Style – it has the default Excel style – another way of saying it doesn’t have any.

3. Structure – it uses the grid, but Excel’s got a lot more tools than that folks!

So, let’s see how we can turn this into a great looking spreadsheet by addressing these three areas. In the end, here’s what I’d like to see instead – these screens show the same data, but using the tips below to make this spreadsheet something that I wouldn’t mind looking at each time it was open (and not just because of the kittens).

Tip 1: Don’t use row 1 or column A

Just because the grid looks like a table doesn’t mean you need to use all the cells. Using row 1 and column A almost always puts your data too close to the row and column headers (A, B, C, … and 1, 2, 3, …) and things look squished. Do yourself a favor and use the first row and column for spacing. Personally, I size them to 10px and then start in B2.

Note from Rob:  I sometimes go one step further and make the first row and column a single pixel, THEN make the second row/column about 10 pixels as Dan does here.  That way I can park selection in that first cell and have it be barely noticeable:

That “dot” in the upper left is cell A1

The other thing I often do is select a cell that is completely hidden behind an image.

Tip 2: Resize rows and columns

You can make your spreadsheet look a lot better if you space things out a bit, and leave room to read the info it contains. Make cells that contain data wide enough to read most of the content. Leave empty rows or columns between data as a visual separator. For finer grained control, leave multiple rows or columns, and size them to just a few pixels, so you can adjust later.

Tip 3: Merged cells are evil, instead use Center Across Selection

This one surprises a lot of people, but it’s true. When you merge a cell in Excel, you’re really limiting what you can do in the future because Excel still “thinks” in rows and columns, and merged cells muck that up. For instance, you can’t insert a cell if any of the cells in that column are merged across multiple columns; you can’t create a table if there are merged cells in the range; and you can’t sort or filter a range with merged cells either. There is a workaround however and it looks exactly like merged cells once it’s applied – it’s called “Center Across Selection” and it’s available on the Cell Format dialog. To use it follow the steps below, or check out this video from Mr. Excel.

1. Select the cells you were going to merge

2. Open the Format Cells dialog (Home Ribbon, Font group, little button in bottom right)

3. On the Alignment tab, set the Horizontal alignment to “Center Across Selection” and click OK.

4. Type the value you want centered into the left-most cell of the selection from step 1.

Note from Rob:  I admit, I still use a lot of merged cells to center titles and such.  I know about merge across but old habits die hard.  That said, I think the unspoken tip here is to center your titles in the first place.  Consider these examples:

Uncentered Title

Centered Title

Tip 4: Align everything, and keep related data close

All too often, data ends up wherever you clicked and then pasted it into the spreadsheet. Charts end up “near” the data. Shapes and images are placed semi-randomly. Spend some time to align everything and you’ll get a much cleaner look. If you have two tables of data, make sure they start in the same row. If you have a chart, set it to Snap to Grid, and then make it the exact width of the columns you want it to span. If you have multiple charts, line them up. The human eye gets distracted when objects aren’t aligned because our brain tries to align them internally…so help your brain.

Tip 5: Keep it to 3-5 colors – white, gray, and 1-3 accents

When it comes to color in your spreadsheet, less is more. For the background, use white. Studies have shown that dark text on white is much easier to read (and looks better to most people). For most text, and for anything that’s black by default in a chart (labels, axis, gridlines, etc.) use a shade of gray – it’s less jarring than black, and it “feels” modern. And when it comes to colors, don’t go overboard – choose an accent and stick with it throughout the entire workbook. I tend to like a shade of green but any accent will do (and less saturated ones tend to look better). If you’re building charts, you may need a second or third color too to differentiate the series – that’s fine. Note that Excel doesn’t actually help you here – we added a lot more colors in Excel 2007 (from 64 to infinite) and that tends to make people want to use them (all). More colors are good, but only because you can pick the few that you like.

Tip 6: Don’t use more than 2 fonts

By default, everything in Excel is one font (and that font depends on your version – it might be Arial, Calibri, or even Segoe UI), but the font picker is so prominent in all versions that I see a lot of workbooks with a dozen or more fonts. Like colors, it turns out that less is more here. Choose a couple of fonts and stick with them – use font size (as opposed to different fonts or bolding) to differentiate parts of the spreadsheet. A clean, modern looking combination is Segoe UI for “normal” cells, and Segoe UI Light for any headers. And remember – make most of your text gray (you can do this easily – right click on the Normal style in the ribbon and change its color).

Note from Rob:  Whoa!  Multiple fonts!  Never occurred to me.  Hmmm….

Tip 7: When you’re done, turn off gridlines and headers, and chart borders

Nothing can do more for your spreadsheet than turning off the gridlines and row/column headers. If you structure your data right (use tables – see Take advantage of tables) then you have all the borders you need and the gridlines just make things look busy. And the row/column headers might remind you that you’re in Excel, but when you’re viewing (as opposed to authoring) a workbook, you just don’t need them. While you’re at it, turn off any borders on charts – it looks a lot better when the graph is just “on the background” of the sheet.

Tip 8: Don’t forget the images

With the prominence of the grid in Excel, it’s easy to end up with a spreadsheet that’s just text and numbers – boring. Spice it up a bit with your company logo – or better yet, the logo of the subject of the spreadsheet. Don’t go overboard here, but a few representative images will go a long way to making the end result nice to look at. Oh, and if you can, try to get ones with white backgrounds, so you don’t end up with a bunch of intrusive rectangular images.

Tip 9: Ignore the fancy formatting options

This is a follow-on from Tip 8: Don’t forget the images, but applies to other elements of the spreadsheet as well (charts, shapes, WordArt, etc.) Nearly all the time you think that a drop shadow or reflection or glow or rotation or gradient or perspective or bevel would look good, it usually won’t. What it might do is distract from the clean simplicity of a modern spreadsheet. So, rather than look for “cool formatting to add,” remember that “simple formatting is cool formatting.”

Tip 10: Take advantage of tables

Tables were introduced in Excel 2003, but didn’t really become useful until Excel 2007. Now, if you have tabular data, it should be in a table. This gives you quick access to sorting and filtering, makes the data easy to reference into, and – even if you don’t use them for any of the data capabilities – gives you a bunch of nice formatting options. When you choose a format, choose one that uses your accent color, and try to grab one of the Light or Medium styles. Remember – less is more.

Tip 11: Flatten your data

This tip is a bit more advanced, but the idea is that any data you enter in the spreadsheet should be completely un-aggregated. This means that each row should stand completely on its own. For instance if you know that on 3/11/2012, you had 12 downloads from the United States, and 82 from the United Kingdom, you should enter that as two rows with columns named “date,” “country” and “downloads” rather than one row with “date,” “United States,” and “United Kingdom.” The reason for this is that Excel is GREAT at aggregating data for you (with less mistakes)…which we’ll get to in Tip 12: Let Excel do the math and Tip 13: Don’t be scared of PivotTables.

Tip 12: Let Excel do the math

Spreadsheets aren’t just a big table that you can enter values into – they all support formulas, which can do almost anything you want to do, faster than you can do it yourself. Need to add 100 values? Excel can do that for you. Need to find the average of some value for each month? Excel can do that for you.

Note from Rob:  Or let PowerPivot do the math of course

Tip 13: Don’t be scared of PivotTables

PivotTables in Excel are a way to group and summarize your data. If you’ve entered your data as suggested in Tip 11: Flatten your data, you probably have several categories of data in your table. By putting this into a PivotTable, Excel will automatically sort the data into those categories and show you a grouped view. Plus, just like Tables, PivotTables give you some really nice formatting options that make it easy to see where each group starts and stops, as well as totals for each group way faster than you could do the totals by hand. Handy, fast, and clean.

Note from Rob:  most people reading my blog love pivots of course, but as I mentioned Friday, pivots are probably the most under-used feature of Excel.  It was (and is) one of the ongoing missions on the Excel team to help a broader audience adopt pivots.

Tip 14: Use charts, but do not use 3D charts

You should always use charts – a quick visual representation of data is always easier to understand and looks better than a big table of numbers – but when you do, make sure they are 2D (“flat” charts). Not only do 2D charts look cleaner and more modern (see Tip 9: Ignore the fancy formatting options), but you can actually read the data in them. Because of the way 3D charts work, it’s nearly impossible to see the size of bars or columns, and lines look like they are floating in space. Do yourself and the people who are looking at your spreadsheets a favor and just don’t use 3D charts.

Note from Rob:  3d charts don’t render as 3d in the browser either.  See this post.

Tip 15: Name everything (esp. sheets and tables)

OK, this last tip doesn’t actually make your spreadsheet more visually pleasing from a “pretty” sense, but the more things you name, the easier it is to use the spreadsheet. It’s a lot easier to know what’s on the “Download Dashboard” sheet than it is to know what’s on “Sheet 2.” Likewise, if you name cells, tables, and other objects, you can refer to them by name in formulas, which makes it a whole lot easier to see what’s going on in the formula – =SUM(DataTable[Downloads]) is a lot easier to understand than =SUM(C17:C753).

In Summary

So, those are my tips. Each tip by itself is pretty small – but once you embrace the lot, my guess is that you’ll be happy with the result. Plus, I’m sure there are more, and even some that I don’t know yet. And, if you’ve got a favorite (that I did or didn’t mention), let me know – post a response!

Oh, and if you’d like a copy of the sample spreadsheets I used, feel free to download them here.

Today’s Scene  (Just add a Foot of Snow)

An obsessive and intrusive habit

Quick anecdote.  For a couple of years now I have been accosting people in public places when I see them using Excel.  On an airplane?  In an airport?  In a doctor’s office waiting room?  You aren’t safe in any of those places.

If you’re using Excel, some weirdo is gonna walk up to you and ask you two questions:

1. Do you use PivotTables?
2. (If Yes) Do you use PowerPivot?

The first answer tends to be “Yes” about a third of the time.  That’s disproportionately high relative to the broader population, in which only about 5-10% of people use pivots.  There’s a selection bias in play here of course, because someone who uses Excel enough that it’s on their screen when I walk by is more likely than average to be an Excel pro, and therefore more likely than average to use pivots.

But for two years the second answer has always been “no.”  I then explain that they should be, they express shame, they promise to check it out.  Sometimes they even get a demo.

Until Today!

Recall that just a few days ago, I predicted this would be the year where we start running into PowerPivot via random personal connections and conversations.

This morning, at 10:15 eastern time, at the Starbucks on Cedar and Fairmount in Cleveland Heights OH, I noticed a well-dressed man sitting with his laptop, engrossed in Excel 2007 or 2010 (couldn’t tell, just saw the Ribbon).

Being a “work from home day,” I took stock of my own ensemble:  Unshaven?  Check.  T-shirt and tennis shoes under a coat covered in dog fur?  Check.  Beanie-style snowboarding hat with a pom-pom ball on top?  Check.

Perfect.  I moved in for the kill.

I’m positive he thought I was going to ask him for money or something, and the smile that came over his face when he heard the pivot question was one of sheer joy and relief

OK, so “yes” he uses pivots.  Now for the second question, the one that engenders shame when the person has to say “no” to a question that so clearly, I think they should say “yes” to… 

ME:  “Do you use PowerPivot?”
HIM:  “No, I don’t, but my team does.  We use a lot of SharePoint.”

Quite the rollercoaster in that sentence.  In sequence, my brain flashes the following reactions:

1. “He said no.  Yep, just like every other random sample to date.”
2. “Whoa, his team does???  Wait, he doesn’t know what PowerPivot is does he?  He’s bluffing!”
3. “Hold it hold it!  Anyone who follows up a PowerPivot question with a SharePoint reference actually DOES know it.  And quite well!”

Fantastic.  I let him get back to work rather than chatting him up.  Took some serious willpower.