Best practices from group request

[Malekish]

I've got a series of reports I'm tasked with maintaining, I know there has to be a better way of doing this but I don't know how to go about it.

The existing reports are all organized with sub-reports, each distinct product is in it's own sub-report. These are problematic to maintain, especially since every few years the person gets promoted, leaves, whatever and then the next person (currently me) has to pick up and learn them.

I would like to put all the various groups in one place, so I can leave documentation saying go Here and change these values instead of digging into all these sub reports and change them.

Example Data:

Queue_ID      ACD     Abandon
17001         100         5
17002          50         3

Product A (sub report)
Queue ID in (17001, 17005, 17010, etc)
Sum(ACD), sum(Abandon), etc

Product B (sub report)
Queue ID in (17002, 17011, etc)
sum(ACD), sum(Abandon), etc.

Output of report sample

              Header
Product Group 1
         Project A   xxx   yyy   zzz
         Project B   xxx   yyy   zzz
Product Summary      XXX   YYY   ZZZ

Product Group 2
         Project C   xxx   yyy   zzz

Etc...

All of this data comes from the same table, is it really necessary to have them each in their own sub report? The various Queues in each product can change fairly frequently, I'd like to make it as easy to maintain going forward as possible. I cannot write to the source database so I can't put a table there with the various groupings.

Are individual sub reports the best or what does the collective wisdom offer?

Thanks much for your time, it is appreciated.

 

[lbass]

What happens if you start a new report and insert a group #1 on Product and a group #2 on Project? If you can match the results of the existing report, you are all set.

I wonder though whether subs are used because one row needs to appear in the report more than once for some reason.

-LB

 

[Malekish]

The subs were used because the first guy that made them (2 generations ago) made them that way. There's no row that needs to appear more than once, everything is a sum of fields in the database.

Some of the reports needed to reference different sources, in that case each sub is for each source, then passes the values to the main report via a shared numbervar command. Other reports use only a single data source and he just copied existing report style and kept with it.

All of our various phone systems will be replicating data into one Oracle database, therefore all of these reports will no longer need to access each system individually, they'll just point to one source.

I can make various groups of Projects / Products, but I want it to be easy to update the Products (they need to be updated a few times / year). The larger category of Projects will rarely change.

Thank you for your time,

 

[lbass]

You said that all subs were accessing the same table, and now it sounds like they don't now, but will in the future. If you have Projects and Products fields, they will automatically update when you add new projects/products when you verify the database. I'm not sure what help you are looking for.

-LB

 

[Malekish]

There is a whole series of reports, some of them access multiple data sources, some currently access only one. In the near future all will access only one data source.

The Project / Products aren't defined anywhere, at least not in machine readable format. The leadership team tells me to group various Queues into the different projects. For the ones that have already been converted to a single data source should I keep the various sub reports to organize them or is there a better way?

As always, thank you for your time, it is appreciated.