Ok, this is definitely something that only Baan could provide, however, I'll go and post it here...


When defining an aggregate function in a report field, the report compiler internally assigns a variable for it (eg. "total..1"). So, you may do calculations in the report like value = total..1 / total..3, but this is generally not advisable, since the field names are likely to change if you introduce new report fields.

This could easily be overcome if one could enter a variable name that should be used for such an aggregate field. The report compiler would then use that particular variable name instead of a generated one.

With this litte enhancement e.g. percentage calculation on total fields would be much faster to implement than today.

Couldn't you just write your own aggregate function in the report script? You would then have the control you are looking for.

Sure I could (and actually I have to do this right now, because there is no better way). But were talking about enhancements here, and it would be a great enhancement if I wouldn't have to code such a "standard" functionality from scratch each time I need it. And I need it a lot...

Ok. I see your point. It doesn't seem like a big deal to me because I don't have to do it that often but if I did, I can see how it would get a little tedious.

I've been programming lots of "high sophisticated" reports for our controlling department. The typical demand is exactly what ulrich likes.

I guess that *lots* of reports out there do their own total calculation, again and again.

If you are familiar with other reporting tools (e.g. Crystal) you know that this is really a pain.

Another examle:
Imagine a user wants to see the total on the first line, and then the details. How would you do that in Baan; 10 Lines of Code, 100 Lines?