Requesting a Report

In order to make the most of limited development resources, and in order to expedite the creation of reports in Datatel it is important to approach reporting needs in a methodical way. The more planning done in advance will make the report easier to provide and of greater value. This document presents a few concepts that can be used when planning and requesting a report:

Provide the Background –

Give WCTS some idea of the background for the report - What is the report for? What role does it play in your operation, and are there regulatory needs or competitive needs for the report. This will give us some idea as to what priority needs to be given to the development.

Who needs the report? Is it for off-campus or only on-campus consumption? This helps us determine what flexibility we will have in putting the report together (often reports needed for off-campus have rather narrow definitions).

Also reports for executives or public constituents might need more explanatory text and a prettier façade.

When is the report needed? Obviously, the more lead-time given before the report is needed, the better for writing and testing a report program.

How often is the report needed? Is the report run once and used as a reference? The more frequently a report is needed it usually gets a higher priority. The more often a report is run, the more important it is to make sure it processes quickly.

Do other reports depend on information provided by this report? Again the priority increases, as the role of the report takes on expanded importance in business operations.

Provide a Template –

Do you have an example of an older report? Or one that is similar in format? If you do not have an existing sample report, make a mock up of the report, showing headers, data grouping, subtotals and totals. Take pains to include all the needed data.

Is there an existing report that has what you need? Or one that has some of the information needed? Provide samples of those reports in order to help map out the data sources (see below)

Specify data formats, give the exact size of the fields, include currency marks (if applicable), decimals, commas and any special formatting that needs to be applied to text, numbers or dates.

Map the Sources –

What criterion needs to be applied to the selection of data for inclusion in the report? What conditions need to be met? Is there an existing query that you have been using, if not, then create a query and run it to test that it does supply the necessary data set.

For every piece of information needed on the report determine the file and fields from which to pull the data. On a screens where the data resides, press field help twice to get the field name. Use RFEI, enter the field name to bring up the file it is located in.

Specify which mnemonic you would like to use (should not already exist) and which menus you would like to have it under. Who will need to have the ability to run the report? Where should the report print?

Test, Test, Test –

When the report is released to the COLTEST account it needs to be tested and retested, every item needs to be checked. It is possible that 1) There were some mistakes made in writing the report 2) That some items were misunderstood by WCTS 3) That the system has changed (patches, etc) 4) Something was overlooked in the planning. So testing is very, very important.

When should we make a custom Report –

* Is it too complex for query builder?

* Is the report something that needs a polished format?

* Does it require statistical manipulation of data?

* Does it pull from multiple files?

* Is it too complex for Virtual Fields?

* Is it dealing with large blocks of data?

Ó Copyright 2002