"Relationship may be needed" although relationship is set

Question

I have two simple table in Excel 2010 - Products and Sales:

I then linked them into PowerPivot - and here created the relationship from Sales.ProductId to Products.Id - like this:

Now I'm trying to build a Pivot that for each productId in the Sales table also shows me the Category and the PurchasePrice from the ProductTable. However, here I'm stuck - because the relationship is somehow faulty. When configuring the Pivot, I get a message Relationship may be needed even if the relationship already exists. The resulting - wrong - pivot table looks like this:

though I'm actually trying to achieve this:

I know that I could create calculated columns in the Sales table of PowerPivot and pull all required data using the RELATED DAX function - but as the real world project requires a lot of joins and fields I'm hoping that there's a better solution than this workaround...

I uploaded the example file here.

Answer 1

Peter,

Your question was a bit more tricky than I first though and I spent quite some time digging around, but I think I found the solution after reading this article about making distinct count in related tables.

I have updated your source file (so that Sales table contains more than 1 sales per product) and uploaded it to my public Dropbox folder.

You can see that I created 4 new calculated measures to illustrate my solution and to make it a bit easier to understand (Excel 2010 terminology, in 2013 it's Calculated Field):

Sales Price Total

=SUM(Sales[SalesPrice])

Products Sold

=COUNT(Sales[ProductId])

Purchase Price per Item

=CALCULATE(SUM(Products[PurchasePrice]),Sales)

Purchase Price Total

=[Purchase Price per Item] * [Product Sold]

The key difference here is the formula for calculating purchase price per item. The reason why you should SUM the product purchase price within CALCULATE function is explained in great detail in the linked article (even though in a bit different context):

In this way, any filter active on Sales (the related table) propagates to the lookup table.

There might be some other parts I missed, but I have tried this in couple other examples and it simply works as it should: