Hello All,
I have a question on qualification of an object.
I have calculated field (Quantity*Rate). I dont see any difference whether I declare this object as Dimension or as a Measure when I pull that object in my report along with few of the Dimensions.
Why do we need to declare the calculated objects as Measure. Why cant we declare it as a Dimension.
Thanks.
MSR_BO (BOB member since 2009-05-01)
You can do what you want :).
Its a bit the same as an object called price, i.e. it means nothing aggregated.
You can make it a dimension, non aggregate measure, or even a detail, if you wish.
Mak 1 
(BOB member since 2005-01-06)
If you bring in:
Colour, Size, Value (as Quantity * Rate) as a dimension then when you display
Colour, Value you’ll see a row per Colour and Size, where as if it’s measure it’ll miraculously sum values. frinstance:
Colour;Size;Value
Red;10;34
Green;12;23
Red;11;12
Blue;10;56
Green;11;23
Lose the Size and have Value as a dimension:
Colour;Value
Red;34
Green;23
Red;12
Blue;56
Green;23
But if Value is a measure:
Colour;Value
Red;46
Green;46
Blue;56
Damocles (BOB member since 2006-10-05)
There are situations where you want to declare a number datatype as a dimension and also as a measure. Here are two scenarios to explain:
As a measure - If you want to report at a summary level, by putting sum on the object it will roll it up to the level required. This is ideal if you are looking to bring back a single row per instance of an object
As a dimension - If you want to bring back every row and not have the data summarised, then a dimension is useful. This can also be achieved by making it a measure without a sum clause, but by specifying dimenson you can do more in the report with it like merging it to another dimension in a different data provider.
I guess the best way to look at it is to ask yooourself whether you want to maniuplate the object as a number with funcitns like sum, avg etc… or if you want it behave like a dimension.
jonathanstokes (BOB member since 2004-09-17)
Sorry, I misunderstood, you are creating the measure, it is not a pre-calc singular field in the DB.
This would have been bad design, but it can happen… 8) .
Yours looks like a line by line example, i.e. it could be like number of hours worked - Hours*Rate, for example, an invoice.
You should declare it as a measure if it makes sense when aggregated, with the dimensions, look at Damocles final example for one that, IMO, doesn’t.
An example, that I stated, that doesn’t is Item price, what would this mean aggregated, you could say it was a detail of the item?
Mak 1 (BOB member since 2005-01-06)
If it was shoe colour and the report was for the manager of the shoe shop and he wanted to see what the total value of shoes was per colour regardless of size that would be an excellent way of doing things. Excellent.
Damocles (BOB member since 2006-10-05)
Would be an unusual business question, but…fair enough, don’t know if it warrants the use of the word “Excellent” twice, though…:).
Mak 1 (BOB member since 2005-01-06)
Well it’s mainfestly obvious that you’ve never worked in the shoe industry.
Damocles (BOB member since 2006-10-05)
Correct :).
RK_BO,
I think the bottom line is it depends what the business questions are being asked of the data.
Does your measure make sense when additive or not?
Mak 1 (BOB member since 2005-01-06)
See this post of mine regarding measures in BusinessObjects, please.
To be clear i[/i] should defined as properly with a SQL aggregation SUM (in the SELECT box of Designer) as:
SUM (Quantity*Rate)as a measure with projection set to SUM as well, period.
Andreas 
(BOB member since 2002-06-20)