We have multiple BO full client reports that need to be converted to C8 reports. Apart from designing a framework based on a set of BO universes, there is a grouping functionality of which I am not sure it exists in Cognos.
With BO full client I can create a grouping variable and assign multiple values of a dimension to this new grouping member.
example:
dimension: color
values: red,white,black,grey,yellow,blue,purple,brown,green
Suppose I want to group this into a higher hierarchy that designates the nature of the color:
new grouping variable: color-type
group1: basic color
group2: non-basic color
group3: no color
Assigning the list of colors would then yield:
basic color red
basic color yellow
basic color blue
non-basic color purple
non-basic color green
non-basic color brown
no color white
no color black
no color grey
For a fixed list I could either solve this in the framework by a CASE construction or by adding a grouping table.
However, in some cases grouping is performed on free-text fields (which one can no intercept prior to reporting)
Can this be solved in C8 (RS;QS;AS ?)
I just stumbled upon this functionality in QS. It seems that if I add a custom grouping to a QS report and re-open the report in RS then the grouping is compliled into a neat CASE construction.
Seems like a reasonable workaround..
It would seem to me that doing this at the database level would offer much ease. This would allow all reports to utilize this funcationality. We do this all the time with trying to group our business units through the heirarchies.
You could have a "color" dimension that contains attributes to color such as the color type. Then have your parameter acquire that attribute color type, cascade the prompt to color which then this will give you only what you're looking for based on the selection.
It is quite nice because you only have to change it in the database and it feeds to all reports consuming it.
Yes, you are definitely right about fixing this at database level. Unfortunately, a lot of grouping is performed on text-fields that allow for free input. The result is that new values keep popping up. A report writer needs to be able to group these new values 'on-the-fly' which makes it quite imposible to fix this at an earlier stage.
In BO this was working very nicely, although the limit in what the engine could handle was not that high. A few hundred values at most.
For fixed-list grouping I would indeed add a consolidation table to perform database-grouping.