Report Writer demystified - part 2 - other considerations

My last post was the introduction to dictionaries and launch files for those new to Report Writer (or GP).  This post is all about things to keep in mind before you actually venture into Report Writer to start working.  It’s rather boring stuff but it’s important to protect your reports from becoming corrupt or damaged due to poor process or lack of understanding.

Thoughts on Report Writer access

My recommendation is to create a special userID that is for report writing only - and grant it access only to a test company or Fabrikam (TWO) just to be on the safe side.  Why?  Well, if you have to log out as yourself and log in as a special user, you are more likely to follow a process once you put your “report writing” hat on.  If you can go into Report Writer on a whim at any point in your day, that is when I often see people taking shortcuts (no backups, editing live dictionaries etc.) and bad things can happen!

Process? Can’t I just click the Modify button?

There are right ways and wrong ways to do a lot of things in life and Report Writer is no different.  People can get away with doing things that are not recommended but that one time it backfires on you, you will kick yourself for not following a consistent process.  I recommend having a methodology or process for report writing.  Mine looks something like this:

1. Create a backup of the reports dictionaries (all of them) and save in a subfolder by date with a note to what the planned changes are.  If I am doing extensive changes I will actually create a notepad text file outlining at a high level the changes I am making, who asked for them and why.  (You can also export the modified reports and forms via Customization Maintenance instead of copying dictionary files if you prefer).
2. Take the same copied dictionaries and paste them into my development folder (a folder where I can edit reports without affecting the production/live reports).
3. Close Dynamics GP (if it’s open) and re-launch with a local dynamics.set file pointing to this development folder (I create a special “report writing” dynamics.set file and a special GP shortcut on my desktop with that launch file as a shortcut just for report writing).
4. Log in with my report-writing userID in a test company and begin my work.

I have another process for bringing the reports back into production when they are tested.  Your process may be different but the bottom line is, don’t wing it!  If you are new to report writer, write down these steps or get a process from your partner/consultant and follow it every time until it is second nature.  If you have used report writer enough, you have likely be burned once or twice already from taking shortcuts… and you know the pain in recreating a dictionary or report!

Tracking Report Changes

Keep a log or notebook on the history of report modifications.  You would be surprised how often during an upgrade, we see a ton of modified reports that no one knows about (what was modified or why and whether they are being used right now or not).  If you want to do yourself a favour, assign someone the task of managing the reports and tracking changes.  Because security is required to get to modified reports, it makes sense that the person who tracks this is the person who manages security since they will know based on who asks them to grant access to a new report, what has been modified. It doesn’t need to be exhaustively detailed but a simple log of report name, date changed, reason for change and who requested it would suffice.  It would go a long way in the future during upgrades and other times when you are reviewing why certain reports are modified.

TIP: use the Customization Maintenance window to get a quick list of what is modified on your workstation (under the Dynamics GP menu, Tools, Customize, Customization Maintenance).  This window shows all modified resources based on the launch file you used; regardless of what reports or forms you have security/access to.  Remember my previous post relating to launch file configurations, depending on your configuration, you may not see the same list as another user on another workstation depending on how your workstations are configured and installed.  Spot check other machines to compare their lists from time to time.

Make a special launch file for report writing

Review my last post to see how the launch file is designed.  To make another launch file, simply open the default one in notepad or another text editor and copy it with a new name.  I recommend using a name without spaces in it for the GP shortcut purposes.  Example: dynamics-reportwriting.set

The top two parts of the dynamics.set file stay the same; the third part is where you would edit the pathnames of the reports dictionaries to point to a separate folder.  The folder can be anywhere, and keep in mind the syntax differences for local vs. UNC pathnames with slashes etc.

Types of Reports

Now we are finally getting into some actual Report Writer information!  There are three types of reports within Report Writer – original reports, modified reports and custom reports.

• Original Reports – these are the unmodified reports that come with Dynamics GP and they are stored in the “code” dictionary.  In Report Writer, when you view the reports list, the original reports are those on the left hand side of the window.
• Modified Reports – this is a copy of an original report which you have made changes to, stored in that product or module’s reports dictionary.  You can only have one modified version of an original report.  See “Is It Really Modified?” below for some sidebar notes on this!
• Custom Reports – this is either a report created from scratch in Report Writer or a copy of a modified report.  NOTE: you cannot make a duplicate of a report that uses temporary tables so not all reports can be “copied”.

Is It Really Modified?

In my description above, I defined a Modified Report as a report in a reports dictionary for a given module.  However, to clarify, sometimes a report is in the reports dictionary that has not been touched.  How did it get there if no one has touched it?  One common reason is lax security: users who don’t know better are given access to Report Writer. Then the same user at some point will click on the Modify button on a screen output (preview) screen of a report, and clicking on that sends that report and you into Report Writer mode.  Typically the user didn’t realize what the Modify button was for, and didn’t know what to do once they got into Report Writer, and simply closed Dynamics GP and returned back to their regular job.  The result?  Whatever report they clicked the Modify button on is now in the reports dictionary.

The issue: you cannot really tell easily if a report has been modified or not.  If you have followed my advice and someone is responsible for tracking report changes, you will know pretty easily if there are reports not on the logbook that are in the report list.  My tip?  Use Security to try to identify if a report is really modified or not.  Read the next section and I’ll explain what I mean!

Security and Report Writer

The last topic of this post is an overview of security as it relates to Report Writer.  First there is security to allow a user access to Report Writer itself – as in access to the tool that is “Report Writer”.  Secondly, there is security to the modified reports themselves.  Users who do not know this often “mess” around in Report Writer only to get frustrated that they cannot see their report changes when it’s simply a matter of granting security.

I’ll back up one step to a previous comment: there are original reports and there are modified reports (I’ll deal with custom reports in a separate note).  Any given user can be granted access to the original report OR the modified report but not both at the same time in the same company.

When you modify a report for the first time – i.e. it has not been previously modified – when you are ready to test the report, you need to grant security to see it.  Typically my process is I will be working under a separate userID for report writing so I will grant access to the report to that userID in the test company to review it and ensure the changes are what I am expecting.  Once you grant access, you can continue to modify the report over and over again without having to go back into security and re-grant access.  You would only need to revisit security when you are done with report editing and ready to move the reports to production - to grant access to the report(s) to other users.

Modified Reports (and Forms) fall into the security category of “Alternate, Modified and Custom”.  In GP10/GP2010 security, this is within the Alternate/Modified Forms and Reports window.  In previous versions of GP, it falls under Alternative, Modified and Custom in Advanced Security.  The screen shot below is the GP2010 window showing an example of a report that has been modified.  You would select which user(s) or in this case which Alternate/Modified ID’s should have access to the modified report, and choose either the original or the modified report.  TIP: if you only have one Alternate/Modified ID, I recommend creating a copy of it for your special report writing user only for the temporary time when the new report is not yet in production.  There is nothing worse than granted security to a report while using a local launch file only to have a production user get an error because the modified report does not exist in production yet!

Now, back to the question Is It Really Modified?  My tip is to look at security as one way to try to identify if a report is modified or not.  If a report has been accidentally placed in the reports dictionary (via clicking Modify on the screen output window), chances are good that no one has security to that report.  If no one has security to the modified report and no one knows why it is in the list, chances are it is safe to remove from the reports dictionary!

Next time: I’ll start to dig into Report Writer itself for some tips and tricks.