Well, there's above(), but it only works within the context of the lowest dimension - quarters in this case. So each year would start over. If you created a Year Quarter field, though, then above() would work, though it would be sensitive to sorting, so you'd have to turn off dynamic sorting. And it would never report a value for the first quarter selected, even if there was a quarter previous to it. And if you selected two non-sequential quarters, it would still report a sequential change, which would be incorrect if it's intended to be a quarter on quarter change. A more complicated approach that fixes those problems is to handle it with data:
As of Year Quarter, Related Quarter Type, Year Quarter
2010 Q3, This Quarter, 2010 Q3
2010 Q3, Last Quarter, 2010 Q2
2010 Q2, This Quarter, 2010 Q2
2010 Q2, Last Quarter, 2010 Q1
...
dimension = As of Year Quarter
expression 1 = sum({<"Related Quarter Type"={'This Quarter'}>} Sales)
expression 2 = sum({<"Related Quarter Type"={'This Quarter'}>} Sales)
/ sum({<"Related Quarter Type"={'Last Quarter'}>} Sales) - 1
While the problem is solvable in QlikView, I do wish that QlikView had more native support for period comparisons, and that it understood that days still occur even when there is no data for them. I think I understand where they're coming from, which is that dates are just fields like any other. But when a substantial number of questions on the forum are about handling dates and date comparisons, and when the solutions are complicated like what I posted above, you know there's room for improvement in the product.
Still I don't think the biggest flaw in QlikView is that it doesn't act like Excel. If you want something that acts like Excel, use Excel. QlikView isn't a spreadsheet. It's something very different.
.png "Luminary Alumni"){kind=icon}
