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.


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 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.  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.


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!

(originally posted on, and migrated to this site in October 2017)

7 thoughts on “Report Writer demystified – part 1 – dictionaries and launch files

  1. Reply
    Les Wright - November 13, 2010


    Great post!  Explaining this content at the beginning of any Report Writer training class is both essential and ‘boring’ as you say.  I find that explaining the differences between what Report Writer can do versus the myriad other BI/reporting tools is also an important consideration for aspiring Dynamics GP Report Writers.

    Looking forward to the next post!


    1. Jen Kuntz - November 18, 2010

      Thanks Les! I definitely agree with you, there are so many tools to choose from, many of which overlap in what functionality they can provide.

  2. Reply
    Abhay - November 29, 2010

    Great blog. I look forward seeing more of these. I always train my colleagues to first understand the basics that will help to lay the foundation to understand the technicalities of any applications.

  3. Reply
    Charles Siele - May 11, 2011

    I meant how to do it so that all clients can access same modified reports from one central location. i can do them perfectly in client station but i want to have only one modification in the server then all the clients can access from there. Show me the way.

    1. Jen Kuntz - May 12, 2011

      I’m hesitant to make specific recommendations without knowing your install structure etc., which is why I recommend calling your partner to discuss the situation.
      The high level answer is you put the dictionaries in a shared folder where all GP users can access them, and you modify the dynamics.set files on everyone’s machine to point to that location for the modified resources. My post above has a clear example of this.
      There are nuances to this depending on whether you have customizations, VBA etc. so it’s not a one-size-fits-all answer.

  4. Reply
    Charles Siele - May 11, 2011

    How to assign modified reports and forms so that they can be accessed from all locations/client stations without encountaring error message..‘cannot access dictionary…’ in gp.

    1. Jen Kuntz - May 11, 2011

      If you are getting a ‘cannot access dictionary’ type of message then the issue is likely permissions to the folder where the dictionaries are located. Make sure every user has permission to read/write to that folder location on the network and the files themselves. Then, make sure that pathname is used in the dynamics.set file using either a mapped drive or UNC pathnames.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top