In my last post in this Dynamics GP upgrade series, I talked about getting to know your environment. The importance of understanding some of the moving parts cannot be understated, if you are “in charge” of your environment in any meaningful way. Reading this series won’t allow you to bypass utilizing a partner or consultant for some things, but hopefully it gives you more background to understand different parts of the environment, and perhaps fill some knowledge gaps.
In this blog post, I will continue on the Know Your Environment angle, continuing from where I left off. I covered most of the core Dynamics GP “Microsoft” elements of a given environment but ignored ISVs plus many other parts of the environment to be aware of. Overall this part of the upgrade series may still take more than 2 posts to adequately cover!
Posts in the series
What is an “ISV”?
First of all, ISV stands for “Independent Software Vendor”, and often also referred to as a “Third Party Vendor”. In the Dynamics GP community, there have always been a TON of ISVs creating products either specifically for GP or for multiple ERP solutions including GP. There are far too many to even attempt to list. Some partners are both an ISV (creating/selling their own products or modules) + an implementer (“reseller” of Dynamics GP).
Do you have any ISV products in your environment? Odds are yes. I’ve been implementing Dynamics GP for 20+ years and I have never been at a client that didn’t have an ISV. Even the customer that only had a 1 user license on a standalone “workstation/server” had an ISV product. If you do not have any, you can skip right past this part in terms of planning for upgrades. Also, there are a lot fewer things to worry about if you don’t have any ISV products in place!
How can you tell if you have ISV products?
The short version is, there is no “obvious” single place to identify them, as the whole point of (most) ISV solutions that are modules within the Dynamics GP client is that they operate seamlessly as if they are core functionality. The development tools allow ISVs to make products that look and feel exactly like a native Dynamics GP form (window).
I would start with asking my partner but if that’s not an option, here are some of the places I would look that may reference other products/modules, at least the dexterity-based ones (more on this below). I recommend starting with analyzing the server “client”, most frequently this is on the SQL server. In most cases, the server client will have every single dexterity-based ISV module installed on it. (In my experience, it does, because that’s where the upgrades occur). There are exceptions, not everything has a “server” component but upgrades and updates are much easier if there is 1 workstation that has everything.
- Dynamics.set file. If the ISVs name is not explicitly mentioned in the registered product name, it may not be obvious to an end user; most experienced consultants should be able to tell you from the .set file what is an ISV and what is not.
- AddIns folder underneath the GP application directory (i.e. C:\Program Files (x86)\Microsoft Dynamics\GP). Some ISV products also have DLLs that exist here in AddIns which can be a clue. (See below for more on this)
- Within Dynamics GP, go to Help > About. ISVs tend to have their own “about” window either right on the Help itself (Key2Act does this, for example), and many have a link to their “about” window under an Additional menu on the “About Microsoft Dynamics GP” window. Of course, there are exceptions! I just checked my own “vanilla” install that doesn’t have any ISV products and Revenue/Expense Deferrals version info is on the Additional menu of About Microsoft Dynamics GP. Go figure.
- Within Dynamics GP, check what Navigation Panes you can see. If the ISV product is significant enough, it often may have its own navigation pane. Or, within the out of the box navigation panes, take a look at the core panes like Financial, Sales, Purchasing, Inventory etc. and ISV products that tie into those series may be visible on the menus. (Of course, this is assuming you are logging in with a user ID that has POWERUSER or an equivalent role that can see all of the menus and panes).
- Remember this: all of the above items are only showing you what is on THAT workstation you are logged into.
- Lastly, if your install files are centralized, many times the folder structure will tell you as there could be a “Dynamics GP” install and then subfolders for the various ISV products that get installed. When I’m organizing install folders, I use the ISV name, and subfolders underneath for module/product name.
Product Types
What I’ve been describing above is great if it’s a “dexterity-based” ISV product or module. Not all are, but I would say that’s the most common type, if the ISV solution is accessed from within Dynamics GP.
Dexterity is the programming language that Dynamics GP is written in, and “dexterity-based” products are the things you see in the Dynamics.SET file along with out of the box Microsoft dexterity modules. When a dexterity based product is installed, one of the elements is referred to as a “chunk” file, since its file type is *.cnk. The .CNK file gets extracted to a .DIC (dictionary) file once launching Dynamics GP the first time after install (and choosing “yes” to include new code).
All modules that are of this type, that I am aware of, would appear in your dynamics.set file on that workstation. If an ISV product is not dexterity-based, it will not appear there but might be in the form of one or more DLL files in the AddIns folder instead.Myself, I have seen this a handful of times - but it is somewhat rare.
If the product or module is accessed from within Dynamics GP (as a module of some sort), then it should fall into one of the two types above - dexterity based or DLL in the AddIns folder. The other product type would be things that are external applications that interact either solely with Dynamics GP or otherwise. I’ll leave that alone for this post and continue with that in my next one in the series.
Summarizing
Back to the original purpose of the series - upgrades - and getting to know your environment, the reason you want to understand what ISV products you have, particularly “modules within Dynamics GP” is planning for the technical upgrade of those modules. Even within the Dynamics GP “18.x” layer, there is always a chance that there is a change to something in core Dynamics GP updates that may break an ISV product. Every ISV product has a chance to get advanced copies of new builds of Dynamics GP to test their products against.
When you are planning an upgrade with a partner, typically they will be all over this. They need to know what modules you have to get the newest compatible module to install for your upgrade. If you are typically doing your own upgrades, or doing your own annual updates (for payroll tax compliance for instance), a few minutes spent in reviewing the ISV vendor sites for information about product compatibility goes a long way to ensuring you are successful in your upgrade OR your update. The more “integrated” an ISV module is, the greater the risk of a GP change impacting it. I tend to know which ISV solutions I want to pay attention to that are more likely than not to have an update corresponding with a new release of GP, and which are unlikely to have compatibility issues. Either way, if your ISV solutions have newer builds, for compatibility reasons or otherwise, I do recommend trying to stay up to date.
Side note: by “Integrated” I mean the ISV products that often have alternate versions of Dynamics GP windows, vs. ISV products that have their own standalone function. The highly integrated modules can be impacted more by underlying changes to the core GP code.
Most ISVs publish version-specific compatibility, i.e. “last tested with 18.3.1245” or something along those lines. If you’re not sure and doing the work yourself, ask them. At the same time you’re researching this, find out what is new/fixed/changed with that module or product. It’s easy to find “what’s new” for Dynamics GP but often there are also product improvements or bug fixes in ISV solutions too.
I mentioned in my first post “always do a test upgrade”. The more ISV products you have, the more important this becomes. Install each ISV, test it as thoroughly as you would test GP during an upgrade to make sure there are no issues.
Next time I’ll continue with the external applications angle, and then get into other elements of your environment to be aware of.