Report Writer demystified - part 1 - dictionaries and launch files

This is the first in a series of posts about Microsoft Dynamics GP's built-in reporting tool - Report Writer. However, I am starting with some background that is more general to Dynamics GP before I dig into Report Writer itself. Hopefully, some of these posts will add some new tricks to a report writer's repertoire or give someone the confidence to try modifying a report on their own!

The first two articles contain some background and key information to keep in mind. In future posts, I will document different tips and tricks on some fine-tuning, how to make reports look nicer, etc.

Background

Report Writer is the built-in reporting tool in Dynamics GP. In comparison to other reporting tools out there, it is not the most user-friendly report-writing tool. It does have its advantages (a few, really, it does!) and for the moment it is the source for all posting journals and those types of core reports.

Security in GP controls who is allowed to use Report Writer and modify reports.

Dictionaries

To be successful with Report Writer, it helps to know a little bit about dictionaries. Dictionaries (.dic files) are groups of resources, more commonly referred to as "code" dictionaries, "reports" dictionaries or "forms" dictionaries. Each product or module that has its own code dictionary will also have the possibility of having its own modified reports and/or forms.

• Code dictionaries are the literal code that contains the resources for the application to run. Dynamics.dic is the primary "code" dictionary which encompasses virtually all of the core functions inside of Dynamics GP (GL, AP, AR, etc.). Most of the larger Dynamics GP modules have their own dictionaries – Canadian Payroll, Project Accounting, Human Resources, Field Service etc. Third-party products always have their own as well.
• Reports dictionaries contain modified and custom reports for their respective products or modules.
• Forms dictionaries contain modified and custom forms (windows etc.) for their respective modules.

If there are no modified reports or forms yet, there would be no dictionary files for reports or forms, there would only be code dictionaries. The forms and reports dictionary files get created the first time a user goes into Report Writer (or Modifier for forms) for a given product or module.

Code dictionaries are typically local – on each workstation in the application directory. Reports & Forms dictionaries could be in various places depending on the system configuration. Here are the most common configurations:

1. Reports and forms dictionaries are in a central shared folder.  This means the dictionaries are in one location (on the GP server perhaps) and all users’ launch files point to that location.  Everyone uses the same report versions.
2. Reports and forms dictionaries are kept local on the machine where GP is installed.  This means the launch file is possibly unchanged from the default install and the reports and forms are local to each workstation.  Users could be running different versions of reports, if GP is installed on multiple machines in this scenario.
3. Use a utility/batch file approach to copy a shared "master" set of dictionaries to local workstations when Dynamics GP is launched.  This can give the best of both worlds to prevent possible corruption of reports dictionaries and controls the versions of reports available to users however makes report editing a little more interesting depending on how this was set up!

Launch Files

Dynamics GP uses a file called the dynamics.set file as its "launch file".  This is a text file that tells Dynamics GP what products and modules to launch, where to find the code dictionaries and where the reports and forms dictionaries are located if there are modified resources.  The "set" file as it is commonly referred to, is in the application directory.

The dynamics.set file contains 3 to 4 identifiable parts (typically 3):

1. The first row contains a number which is the number of dictionaries.
2. The next "section" is a list of alternating numbers and names.  They are pairs indicating a product number followed by the product name.  In my example below, there are 19 dictionaries so this section would be 38 lines long, with 19 pairs of product numbers and names.
3. The next (and often, the last) section is another list with pathnames to the dictionaries in the same order as the products listed in the section above. There are 3 lines per product/module: code dictionary location, forms dictionary location and reports dictionary location. The heading on this part is titled "Windows".
4. In some advanced scenarios, there could be a second set of dictionary locations but that is very rare.  When Dynamics GP is launched with two sets of pathnames, the user would be prompted to select which set of dictionaries to use in this instance.

The first two parts of a launch file are shown below (in this case 19 products/modules):

Part 3 of the launch file is in the next screenshot (only part of the section is shown due to the size of it).  In this configuration, the code dictionaries are kept local, and the reports and forms dictionary paths are in a shared location on a different machine.  

Why do I care about all of this?

Those wondering why the heck do I care and when is some real advice coming? Well… some basic understanding will go a long way in ensuring report writing attempts are successful and don't accidentally corrupt the report dictionary while making a change to a report.

When Report Writer is launched, the first thing the user is prompted with is to select a product/module dictionary to enter. Look for a future post on how to identify which dictionary a report or window is in.

In an ideal scenario, users are editing dictionaries only when no other user is accessing them at the moment.  That means having an understanding of where the dictionaries are located, finding them to make backups or take copies and knowing whether to consider making a "local" launch file to point elsewhere temporarily.

The next post will cover a little more background to finish off the boring stuff, then we will dig into some Report Writer tips and tricks!