Picking up from Part 1, now we are getting into tips and tricks for modifying reports. I am walking through a specific example of taking a report that was in text format (General Posting Edit List), converting it to a graphical report, then modifying it to make it better looking!
The starting point
Here is where I left off last post, with the report layout simply with the Text Report checkbox unchecked. The fields that were on the right side of the layout before now appear off the page.
Altering fonts & moving fields
My first step was to select all (CTRL+A) and then go into Drawing Options (CTRL-D), to change the font from Courier 11pt to Calibri 9pt. I figured that 9pt gave me a reasonably-sized font for reading the report and fitting things into a portrait page layout.
Second, I dragged all of the fields that were “off the page” to within the page boundaries as well as making a few field size changes. Notice even though I’ve moved my fields, there are lots of fields that aren’t in their final spot yet, such as Page Number and User ID fields in the headers.
Fine-tuning the layout
Next, I began to fine-tune things. I’m taking advantage of the Arrange tab on the Toolbox. I’ll describe these tools in more detail in my next post. What I use all the time are the Align and Size tools. If you are editing reports in Report Writer and manually lining fields up, you are wasting your time… seriously! Keep reading and use the Align tools and Size tools to quickly and easily line things up and make field-size changes easier by matching other related field-sizes.
So, I started to fine-tune by re-arranging the fields to fit things into where I wanted them. I moved some of the “legend” fields in the headers to make room for the Page # and UserID. Using Align features, I lined up the fields with the other Date/Time stamp fields. I re-arranged the H1 fields (first header, below the page header) to present the information in more of a tabular format (headings above the data). I also made the titles of these fields Bold to make them visually different from the data. Re-arranging the data this way allowed me to save a bit of space and reduce the overall size of the H1 section. This doesn’t make a huge difference but overall reduces paper in the long run, with more information fitting on the page.
I added a black thin line under the primary heading titles (Journal Entry #, Transaction Type, Date, etc.) to visually separate the body from the headers. I also added a medium grey colour thin line at the bottom of the F2 section, which is the end of one journal entry. This will visually separate the individual transactions without it seeming too much like a big grid of lines.
On the titles for the body data, the original report had two text fields for a two-row heading/title. I preferred to save space and came up with shorter titles and eliminated one row of unnecessary text fields.
Last, I changed the error message fields to italic – that way if and when they do appear they may stand out a little more than if they are the same font style as everything else.
Here is what the layout looked like after the fine-tuning:
A caution on removing fields and sections from a report
On many reports you may want to modify, often there may be LOTS of unnecessary fields for your business. The default reports have a lot of data on them, primarily because every business has slightly different needs. Since modification is fairly easy, it’s up to the organizations to tweak reports as needed for their specific uses.
One thing to avoid is a wholesale deletion of fields you don’t need. Why? Well, there are two reasons I can think of.
- The field may be required by Report Writer for some reason.
- You never know when you need that field back!
If you take a close look at a sample of reports, you will see a lot of already-invisible fields and some yellow invisible fields plus other legend-type fields that only appear when certain criteria are met. Often these are calculated fields. If there are fields that are purely data fields that you want to remove, first try to simply hide them by going into Field Options (CTRL+F) and making them invisible. Some fields are safe to remove, some are not and unfortunately it’s something you get a feel for over time after modifying many reports. This is my simple guideline (not a hard-and-fast rule though!):
- Text fields are usually safe to delete. By “text field” I mean a field that you can edit with the “A” text editor tool.
- Data fields are also generally safe to delete BUT if I don’t know what it is, I don’t delete it. By “data field” I mean a field from a table or global field that was dragged onto a report.
- Calculated fields I often watch out for, normally are there for a reason! If I don’t know or can’t figure out the reason behind a calculated field, I leave it alone. Better safe than sorry. If a field on the report is ALREADY invisible, don’t delete it – again: it is there for a reason.
Now what do I do?
Start with making a field invisible and hiding it behind another field in the same section. Don’t drag a seemingly-unnecessary field from one section to another section; if it’s a meaningless field that won’t matter but if that field is used for some reason, moving it to a different section of the report could alter how the report generates and cause other issues.
Sections work similarly, if there is a report that contains a lot of sections that you want to remove, make a backup of the report before taking a section out first so you can go back to a previous iteration if necessary. Many times the sections may not make sense to you, but they are grouping, totalling, or otherwise summarizing data at a certain level that you may need. Most data on reports falls into a “one-to-many” table relationship scenario so moving a field from one section to another may not result in the right result.
When removing a field or section you don’t know about, try to back up your dictionary or export your report to a package file first, then delete the section you think you don’t want, then test it. If all seems ok at that point, then proceed with your changes. If you delete a bunch of things then continue making other changes, and realize there is an issue later, it’s harder to narrow down exactly which field removed caused the problem.
Ready for testing
Once I feel I am nearly done a report, it’s time to test it out. I test at different times, depending on the kinds of changes I am making. On a report such as this where the majority of the changes are cosmetic, I will make the majority of changes first before switching back to GP to take a look. It’s a different story if I am creating a lot of formulas, adding a lot of new fields or otherwise changing more than fonts and styles; in those cases, I don’t wait too long before testing a formula out. I don’t want to get too ahead of myself if something isn’t working, the further ahead I go, sometimes the harder it is to determine what went wrong.
Testing highlights a lot of things that you can’t see in the report writer interface, such as text field alignment. Here are some examples of what you may find if you are close to done. I’ve highlighted a few issues with field alignment, where it’s hard to see what the field is for, it is so far removed from the title.
A quick note on security for testing
If you are following my recommendations so far, you have made backups AND are editing reports either without others in the system or on a copy of the live reports (with no one else accessing them). If you are re-modifying an existing report, there is less of an impact because security, in theory, has already been set up and the “production” dictionary already has “a” modified version of the report in it.
The challenge is when you are modifying a report for the first time, you need to be careful how you set security and test. In this scenario what I recommend is to grant security only to yourself on this newly modified report. Until a report modification is in the current, active production dictionary, don’t give security to other users otherwise they may get errors if they try to run that report before you are done modifying it. If you forget to copy the report into production, and YOU get the error, you won’t freak out because you will know what the issue is. The ultimate I believe is to give yourself access to this modified report only in a test company so that scenario doesn’t come up. If you end up going back into a production company, you can do your regular work and not be impacted.
The report is complete!
After making some of the highlighted changes and a few other minor tweaks, my report modification was complete. The last step then is to arrange to bring it into my production reports dictionary and grant security to the appropriate users. All told, this was a simple report modification and it took probably an hour or so to complete the changes. Here is the final report output:
Next post I will dive more into some of the specific tools in Report Writer and continue to “demystify” Report Writer!
(originally posted on www.kuntzconsulting.ca, and migrated to this site in October 2017)