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 actually venturing into Report Writer to start working. It’s rather boring stuff but it’s important to protect the report dictionaries 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 the person writing or editing reports has to log out and log in as a special user, they are more likely to follow a proper process once they put their "report writing" hat on.  If they can go into Report Writer on a whim at any point in the day, that is when I often see people taking shortcuts (not making 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 them, they will kick themselves for not following a consistent process. I recommend having a methodology or process documented for report-writing users to follow. Mine looks something like this:

1. Create a backup of the report dictionaries (all of them) and save them in a subfolder by date with a note to what the planned changes are. If I am doing extensive changes, I will create a text file outlining (at a high level) the changes I am making, who asked for them and why. (There is also the option to export the modified reports and forms via Customization Maintenance instead of copying dictionary files).
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. While others' processes may be different than mine, the bottom line is, don’t wing it! For new users to report writing, write down these steps or get a process from a partner/consultant and follow it every time until it is second nature. Users who have used Report Writer enough, have likely been burned once or twice already from taking shortcuts… and know the pain in recreating a dictionary or report!

Tracking Report Changes

Keep a log or notebook on the history of report modifications.  It is surprising how often during an upgrade there are a lot of modified reports that no one knows about (what was modified or why and whether they are being used right now or not). Ideally, 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 someone is reviewing why certain reports are modified.

The Customization Maintenance window shows all modified resources based on the launch file used; regardless of what reports or forms the logged-in user has security/access to. Remember my previous post relating to launch file configurations, depending on the configuration, a user may not see the same list as another user on another workstation depending on how the workstations are configured and installed. 

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 stays the same; the third section of it with the pathnames is where one would edit the locations of the report 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, in 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 has been potentially modified in some way, which is now stored in that product or module’s reports dictionary. There can only be 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. 

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 is that possible? One common reason is lax security: users have access to Report Writer that perhaps shouldn't, and the same user at some point will click on the Modify button on a screen output (preview) screen of a report, generating a "modified" version of whatever report was on screen. 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 to their regular job. The result? Whatever report they clicked the Modify button on is now in the reports dictionary.

The issue is it is difficult to really tell easily if a report has been modified or not. If someone is responsible for tracking report changes, they 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.

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 (to the tool that is “Report Writer”). 
• Second, there is security to the modified reports. Users who do not know this part 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 modifying a report for the first time – i.e., it has not been previously modified – to test the report, security needs to be granted for the user to see it. This is done in the Alternate/Modified Forms and Reports window. 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 access is granted, the user can continue to modify the report over and over again without having to go back into security and re-grant access.  Security would only need to be revisited when the user is 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”.  This is assigned within the Alternate/Modified Forms and Reports window. In previous versions of GP, it falls under Alternative, Modified and Custom in Advanced Security. The screenshot below is the GP2010 window showing an example of a report that has been modified. 

• Select an "Alternate/Modified Forms and Reports" ID. In most environments, two IDs could be sufficient to configure: one for day-to-day use with reports that all users have access to that have been tested already, and one for testing that is just to limit the number of people who see a report during the development phase. This approach is especially important if the user creating the report changes is working on a copy of the reports dictionary that other users don't have access to yet.  There is nothing worse than granting 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!
• This ID is assigned to a user at a user-company level, in User Security.

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. The quickest way to tell that is in the window above: if the "(Modified)" isn't the version assigned to any Alt/Mod IDs, that is a good sign it may not be needed.

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