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 your repertoire or give you the confidence to try modifying a report on your own! The first two articles contain some background and key information to keep in mind. In future posts I will give you different tips and tricks on some fine tuning, how to make your 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 definitely not the most user-friendly report-writing tool. It does have its advantages (a few, really, it does!) and for the moment it is thesource for all posting journals and those types of core reports. Security in GP controls who is allowed to use Report Writer and modify reports. TIP: if you run a report to screen, and the “Modify” button is greyed out, you do not have access to get into Report Writer.

Dictionaries

In order to be successful with Report Writer, you need to know a little bit about dictionaries. If you are unsure what a dictionary is (and no, I don't mean the dusty book on your bookshelf with word definitions!), here is a basic primer for you. 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 literally the 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, payables, receivables 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 hold modified and custom reports for their respective product/module.
• Forms dictionaries hold modified and custom forms (windows etc.) for their respective modules.

If you have no modified reports or forms yet, you would see no dictionaries on your system for reports or forms, only code dictionaries. These dictionary files get created the first time you go 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 your configuration. (This is where you should consult your partner or a consultant if you are unsure). Here are the most common configurations:

1. Use “shared” reports and forms dictionaries. This means the dictionaries are in one central location (on the GP server perhaps) and all users’ launch files point to that location. Everyone uses the same report versions.
2. Use "local" reports and forms dictionaries. 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.
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 it's "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. Line 1 is the number of dictionaries (products/modules).
2. The next "section" is a list of numbers and names. They are pairs - product number followed by the product name. There needs to be the same number of pairs of product #'s/names as the original number in line 1.
3. The bottom section - there could be two of these sections - is another list of the same dictionaries with pathnames. It's in the same order as the product list in part 2 but this time 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 you could have a second set of dictionary locations beneath this section. When you launch Dynamics GP, it recognizes this and would prompt you to select which set of locations to use in this instance.

The first two parts of a launch file, in this case 19 products/modules:

Part 3 of the launch file (part of it - snipped for size). 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. Note: notice how the syntax for slashes and pathnames differs for local paths vs. UNC paths... one anomaly of the launch file!

Why do I care about all of this?

If you've read this far and are 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 you are successful and don't accidentally corrupt your reports dictionary while making a change to a report. When you launch Report Writer, your first task is to select a product/module dictionary to enter. The dictionary dictates what reports you see, what can be modified, what tables are visible etc. Look for a future post on how to identify which dictionary a report or window is in. If you don't know what the drop-down list is when you open Report Writer, then you may not find the report you want to modify! In an ideal scenario, you are editing dictionaries which no other user is accessing 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 you need to consider making a "local" launch file to point elsewhere temporarily. 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!