GP Upgrades – know your environment

This is the 3rd post in my series about GP Upgrades. Today’s topic is what I refer to as “getting to know your environment”, as part of the planning process around your upgrade. If you are planning an upgrade, it’s important to understand where the moving parts are, and at least to have what I refer to as a “conversational” knowledge of your GP system, even if you aren’t familiar with the nitty gritty details. This is too long a section for one post so I will be breaking it up into smaller pieces.

Posts in the series

1. Series intro
2. Process overview

What do I mean by “environment”?

What I refer to as a Dynamics GP “environment” is the collection of things that make your ERP system function, including, in some cases, external applications that tie into Dynamics GP in some way. Another way of putting it, when I use the term environment, I also am referring to a system database and its related company databases. I hesitate to use the word “server” because you can have multiple system databases on the same SQL instance (since GP 2013 when named system databases came into play), so it’s not even defining an instance of SQL necessarily.

I imagine most client sites have 1 environment, or some may have a test environment (“test”, “development”, some other separate instance other than production). Having a “test company” is not at all the same as having a “test environment” though, do not mix the two up. “Test company” typically would be a company on the same system database as the production companies, at least in my experience.

I’ve worked with a client that had “dev”, “QA” and “production” environments as they did a lot of in-house development and had a more formal process than most with deploying changes to QA to test the deployment process as well as the underlying development bits, before deploying to production.

Parts of an “environment”

There are a few basic “moving parts” associated with a typical Dynamics GP installation. Here are some of the things that come to mind and some terminology to help those unfamiliar with all of this. Generally, if you have any sort of “complicated” environment, there is likely documentation somewhere to indicate what is where because someone, somewhere has been maintaining it. (Let’s hope that’s the case!)

• System database. This is the heart of Dynamics GP, the primary database where all system-centric (non-company specific) information is stored. Most commonly it’s the “DYNAMICS” database but with the introduction of named system databases, it could be named anything now. In hosted environments in particular it’s likely to be called something else.
• Company database(s). Everyone has at least one company database and often more than one depending on your corporate structure and setup. Typically (but not always) there will be one company database per legal entity. That’s most commonly what I’ve seen although with Binary Stream’s MEM (Multi-Entity Management) product, it can allow organizations to handle things in a single “company database”.
  • When you upgrade Dynamics GP, you’re starting with upgrading the system database and then all of the company databases that are associated with it. You cannot upgrade “part” of an environment to a new version just like you cannot apply a service pack to “one” company if you have several on the same system database.
  • To check what you have, if you are unsure if *you* can see all the companies, check the SY01400 table in the system database (DYNAMICS or otherwise). That will list the companies associated with that system database.
• Modules. What modules you are using, whether it’s a core GP module from Microsoft or ISV, is important to have a handle on when planning an upgrade. For the purpose of this section, I’ll limit the scope to the core modules & optional modules from Microsoft.
  • This can be slightly confusing as some modules “matter less” than others in the sense that there are core modules that are installed with GP and functionality unlocked merely by registration keys and there are optional modules (referred to as “features”) that whoever is installing Dynamics GP has to know to mark to install. Some of the larger examples of what is a separate “feature” install are Fixed Assets, Project Accounting, Manufacturing, Analytical Accounting and others. The “features” you can install depend on the country chosen during installation so if you choose Canada, you also have the option to install Canadian Payroll, for instance.
  • What I mean by “some matter less than others” is if I were to ask you what modules you are using, I don’t care if you are using GL, Bank Rec, AR, AP – that’s “the price of admission”, it’s the other bigger modules I’m interested in knowing about, that can have a significant impact on your upgrade in either time to upgrade, complexity etc.
  • The built-in modules are all “installed” by default and the tables all upgraded whether you use them or not; for example, you can’t “not” have inventory installed, it’s just there.
  • Long story a bit shorter: if the installer doesn’t know you’re using one of the features, and doesn’t install it, during the upgrade, the tables and procedures associated with that are simply ignored because no code is firing to update them. This may cause issues at some point, if not immediately when GP is launched. It’s a different conversation if you no longer use something, because you may need to continue to upgrade it OR work through removing it and all SQL objects related to it if so desired.
  • To check what you have: look at the Dynamics.set file on your server + a few workstations. First, identify if there are discrepancies – different things installed on different workstations. I prefer a simpler “everyone gets the same install and let security control access” but that’s just me. Ideally there is a pattern to who has what, like “only HR has Human Resources installed". (This gets into a grey area where you can’t always pick and choose this way depending on how the modules interact with other modules.).
• Dynamics.set file. This is also known as a launch file. This file can be opened in notepad, and lists a variety of things about a given install on a specific workstation. There are (roughly) 3 sections to the file itself:
  • First – how many products/dictionaries are installed. this is a number at the top of the file.
  • Second – a listing with Product ID and Name in pairs, for every item installed. If the top number in your file is 30, you will have 30 paired lines here, listing what those 30 items are.
  • Third – for each Product ID, there are 3 more lines of information with pathnames to where the Code, Forms and Reports dictionaries are for that Product ID. This is in the same order as the list above. Line 1 is the code which (I believe?) is always local on the workstation. The other 2 lines may be pointing somewhere else if the dictionaries are centralized somewhere. It’s that path you want to investigate to find IF there are dictionaries located there.
  • Sidebar: what’s in a typical Dynamics.set file has no direct correlation to what is a “core” module vs. optional feature though. This link lists most features (but not Canadian Payroll!) so anything similar to this in the dynamics.set file, that feature installed on that workstation where the .set file came from. Dexterity-based ISV products will also be listed in the Dynamics.set file although I haven’t gotten into ISV products yet!
• Dictionaries. There are 3 basic types of dictionaries – code, forms and reports.
  • Code – on every workstation installation, in the directory where GP is installed, you will see various “*.dic” files. These are dexterity code dictionaries. If they are in the root GP folder they are most likely “code” dictionaries (because by default reports and forms are in a Data subfolder).
  • Forms and Reports – this gets slightly more complicated but for the purpose of this conversation, I’ll attempt to simplify it. Forms and Reports dictionaries are only present if a modification has been made to a form or report. If you have no modified reports or forms, you may not see any forms or reports dictionaries. For each dexterity code dictionary, there can be a corresponding forms dictionary (“modified windows”) and a corresponding reports dictionary (“modified reports”). If I modify a report in Fixed Assets, Canadian Payroll and then a core GP module like SOP, I will have 3 reports dictionaries because FA and CPY each have their own code (and therefore reports) dictionary + the core “reports.dic” will be present.
  • My experience is mainly with clients having a centralized set of dictionaries but there are multiple ways to roll this out. Some clients simply have a shared central folder and all workstations point to the same set of reports and forms dictionaries. Some clients have set up systems to push down copies of centrally managed reports and forms so the dictionary is “local” for GP to run but still “centralized” and everyone technically running the same modified reports or forms. Beyond that, anything is possible including every workstation having their own (which would be chaos to me but I’m sure it exists!).
  • What’s important to remember for the context here, you need to know how many modified forms and reports dictionaries you have and where they are located. Those need upgrading if they are active and in use. If it’s central somehow, you have “one set” to upgrade which is the best case scenario.
  • To check what you have: start with the Dynamics.set file mentioned above, and the pathname for the 2nd and 3rd lines of each “3 line set” by product. Then, look at that particular folder to see if any .dic files exist. They may not, if you do not have modified reports or forms. Check multiple workstations and the server to see if all workstations are configured the same way or not.
  • The other place to check is Customization Maintenance. In GP, from any window, click on Tools, Customize, Customization Maintenance. This will show – based on the current launch file used – what is modified and/or if there is VBA BUT it will only be showing you what is on the workstation you are using based on the launch file you opened Dynamics GP with. (Having fun yet? )
• VBA. VBA or Visual Basic for Applications is possible to have with either a modified forms or reports dictionary OR stand-alone VBA that interacts with an unmodified resource in the code dictionary itself. See above for how to check, via the Customization Maintenance window. VBA is not referenced in the Dynamics.set file.
• Dex.ini file. The last of the “core” moving parts is the Dex.ini file. This is located in the Data folder on a workstation in the application directory where GP is installed. It too opens in Notepad.
  • Most times there is nothing special in here to worry about. It typically contains a variety of settings that GP uses when it launches, like where to find Letters (Letter Writing Assistant), or Notes (before DocAttach came into being). The things with pathnames are important to note if different workstations are using different paths. The reference to Letters for instance is important if you are using them, but irrelevant if you are not. If you are using them, ideally the reference to the path in the Dex.ini file is a shared location so everyone is sharing the same letter templates.
  • Sometimes there may be custom “switches” (as each line is referred to) added and it’s useful to know in case those need to be added to the new dex.ini after the install of the upgraded Dynamics GP. The most common one I’ve seen is “SmartlistEnhancedExcelExport=TRUE” (or FALSE).

At this point the post is getting long enough that I will end it here and continue next time.