| Before opening the report designer, create a report using the effective report design techniques covered in the previous hours of the book. Imagine the following end-user requirements, received in an email. Report Design Request Memo To: Report Designer From: Bob, the sales manager Subject: Sales Report Hey report designer, here are the requirements… Sales managers need an Employee Productivity Report. The sales managers want to see the status of all orders for an employee by the account that he or she works on. The order status will need to highlight late orders and the size of all orders. The managers will need to see what courier company is used for each order. Thanks Bob |
The previous request seems pretty straightforward. Although the requirements seem sensible, try applying some of the questions from the previous section to them. Clearly, more information is required to complete the report. After leveraging some of our newfound report design questions, the requirements end up looking more like the following: Response to the Report Design Request Memo To: Bob, the sales manager From: The report designer Subject: Sales Report Bob, After speaking with you, I found the following key requirements for your report. Please confirm these to be the case, along with the specified timeline for delivery. You need to see the order status for all orders for X employee. Each account and its total value that each employee works on must be represented and shown separately. Late orders (any order not shipped on the day of order) must be shown in red. Courier companies for each order must be seen. Also, my understanding is that the report needs to be completed one month before the end of this quarter, so you can use it to help wrap up account issues. Thanks, Report Designer |
Notice that this more personalized and direct list of requirements is much more like a database schema. That's because report designers tend to be "data-type" people and need to be more focused on this to make a report successful. Now that we have a more polished set of requirements, we can look at dividing up the tasks of creating the report in to its core pieces. This will help identify what information needs to go on the report and then translate this into specific fields and tables in the database. Some of them might seem obvious, but let's look at them in order: "all orders" = an Orders table "X employee" = an Employee table (with probably some user input to find out which employee to look for) "account"= a Customer table "must be shown separately" = Indicates a level of grouping that is required "its total value" = Indicates a summary will on the account is required "red" = Indicates a status level or condition that needs to be applied for bringing the reader's eye to pertinent information We have a list of basic tasks that need to be done to create the report successfully. Dividing the tasks into logical groupings would help us progress faster. Now let's categorize our findings: Tables Customer, Orders, Employees Groups Account Summaries Total orders for each Customer Parameters Employee's Name Condition Late Status Now that the tasks for creating this report are laid out, the process of report design can begin. |
