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 the upgrade. When 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 the GP system, even if the nitty-gritty details are not familiar. This is too long a section for one post so I will be breaking it up into smaller pieces.
Posts in the series
What do I mean by "environment"?
What I refer to as a Dynamics GP "environment" is the collection of things that make the ERP system function, including, in some cases, external applications that tie into Dynamics GP in some way. Another way of putting it is 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 there can be 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", or 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 there is 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 the 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 upgrading Dynamics GP, it starts with upgrading the system database and then all of the company databases that are associated with it. One cannot upgrade "part" of an environment to a new version just like it is not possible to apply a service pack to "one" company if there are several on the same system database.
- To check what exists, get a list of all the companies, and check the SY01500 table in the system database (DYNAMICS or otherwise). That will list the companies associated with that system database.
- Modules. What modules are used, whether it's a core GP module from Microsoft or ISV, is important to have a handle on when planning an upgrade. For 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. Some "features" installed depend on the country chosen during installation so if the installed chose Canada, there is an option to install Canadian Payroll, for instance.
- What I mean by "some matter less than others" is if I were to ask what modules are being used, I don't care about GL, Bank Rec, AR, or 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 the upgrade in either time to upgrade, complexity etc.
- The built-in modules are all "installed" by default and the tables are all upgraded whether they are in use or not; for example, inventory is installed whether it's in use or not.
- Long story a bit shorter: if the installer doesn't know that one of the features is being used, 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 something is no longer used because it may be necessary to continue to upgrade it OR work through removing it and all SQL objects related to it if so desired.
- To check what is there: look at the Dynamics.set file on the 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 the installer 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 installation 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 the file is 30, there are 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 that should be investigated 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 features 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, various "*.dic" files will be present there. 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 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 no modified reports or forms exist, there may not be 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 runs the same modified reports or forms. Beyond that, anything is possible including every workstation has its own (which would be chaos to me but I'm sure it exists!).
- What's important to remember for the context here is how many modified forms and reports dictionaries are present and where they are located. Those need upgrading if they are active and in use. If it's central somehow, that means there is "one set" to upgrade which is the best-case scenario.
- To check what exists: 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 there are no 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, and 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 what is on the workstation being based on the launch file Dynamics GP was launched with. (Are we having fun yet? 😄)
- VBA. VBA or Visual Basic for Applications is possible to have 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 using them, but irrelevant if not. If they are in use, 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 installation 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.
