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, for those who are "in charge" of the environment in any meaningful way. Reading this series isn't intended for customers to bypass utilizing a partner or consultant. Hopefully, it gives 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
First of all, ISV stands for "Independent Software Vendor", and is 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 ISVs (creating/selling their own products or modules) and implementers ("resellers" of Dynamics GP).
Are there any ISV products in the 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 at least one ISV. Even the customer that only had a 1 user license on a standalone "workstation/server" had an ISV product. If by chance this post does not apply, feel free to skip right past this part in terms of planning for upgrades. Also, there are a lot fewer things to worry about if there are not any ISV products in place!
How can I tell if I have ISV products?
The short version is, that 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 by 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 ISV 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 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 the Revenue/Expense Deferrals version info is on the Additional menu of About Microsoft Dynamics GP. Go figure.
- Within Dynamics GP, check what Navigation Panes are listed. 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 the user logging in uses 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 what is on THAT workstation that is being logged into.
- Lastly, if the install files are centralized, many times the folder structure will provide clues 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 the 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 listed 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 installation (and choosing "yes" to include new code).
All modules of this type, that I am aware of, would appear in the 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. 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 the next one in the series.
Summarizing
Back to the original purpose of the series - upgrades - and getting to know your environment, the reason it is important to understand what ISV products exist, 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 planning an upgrade with a partner, typically they will be all over this. They need to know what modules are present to get the newest compatible module to install for the upgrade. For customers doing their own upgrades or doing their own annual updates (for payroll tax compliance for instance), a few minutes spent reviewing the ISV vendor sites for information about product compatibility goes a long way to ensuring the upgrade or update will be successful. 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 the ISV solutions have newer builds, for compatibility reasons or otherwise, I do recommend trying to stay up to date.
Most ISVs publish version-specific compatibility, i.e. "last tested with 18.3.1245" or something along those lines. If doing the work in-house, ask the ISV vendor. At the same time, 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 that exist, the more important this becomes. Install each ISV, and test it thoroughly to make sure there are no issues.
Next time I'll continue with the external applications angle, and then get into other elements of the environment to be aware of.
