How to find Dynamics GP Customizations or Third Party Modules

One question that I have to answer frequently for Dynamics GP customers is "How can I tell if I have any Dynamics GP customizations or third party modules?"

When a client gets a new partner, or when a customer is looking to upgrade Dynamics GP, it's important for both the customer and partner to know if any customizations or ISV solutions might be installed so that they can be properly supported or can be upgraded.

So how can you tell what ISV solutions or customizations are installed in your GP environment?  Since there is no single window or feature in GP that completely answers this question, you have to check a few places, and ideally have some familiarity with your GP system to adequately answer this question.

I've listed the things that come to mind when I need to look for customizations or third-party products.  If I missed anything, please post a comment and let me know.


Customization Status

Tools -> Customize -> Customization Status

An easy place to start is the Customization Status window.  It lists the Dynamics GP modules and Dexterity-based ISV solutions or customizations that are installed and active.  Although handy, the problem with this window, or more specifically the list it displays, is that it isn't always obvious which items are standard GP modules, and which items are ISV solutions or customizations.  If you are familiar with the standard list of GP modules, then you can usually pick out the items that are ISV or custom.


Dynamics.set

C:\Program Files\Microsoft Dynamics\GP  (or the application directory where you installed GP)

Locate the Dynamics.set file and open it with Notepad.  The Dynamics.set file is essentially the same list that is displayed in the Customization Status window, but it includes additional technical info, such as the number of modules installed (the number at the very top), the module IDs (the number above each name), and then the module names.  The set file also includes the paths where the dictionary files are located.


This file would allow you to identify the specific third-party or custom Dexterity dictionaries that might be in use.  If you have Dex customizations, make sure that you have a copy of the full Dexterity project and source code, as you will need that to make modifications and upgrade.

One thing to look for in a Dynamics.set file is whether GP is setup to use "shared dictionaries", meaning that all workstations point to a single copy of a modified Forms.dic and Reports.dic.  A standard set file looks something like this:

:C:Program Files (x86)/Microsoft Dynamics/GP2010/Dynamics.dic
:C:Program Files (x86)/Microsoft Dynamics/GP2010/Data/FORMS.DIC
:C:Program Files (x86)/Microsoft Dynamics/GP2010/Data/REPORTS.DIC

If you notice that the path for the FORMS.DIC or REPORTS.DIC is not the same as the Dynamics.dic line above, it's a sign that GP is setup to use shared dictionaries, which usually means that there are modified forms or reports.



Customization Maintenance

Tools -> Customize -> Customization Maintenance

The customization maintenance will list modified forms, modified reports, and custom VBA code and references that are  active on the workstation.  These would be customizations made using Modifier, VBA Editor, or the Dynamics GP Report Writer.  Although this window displays a list, you still need to understand where these customizations are stored.

Modified Forms are stored in the FORMS.DIC file referenced in Dynamics.set file.

Modified Reports are stored in the REPORTS.DIC file referenced in Dynamics.set file.

VBA code, user forms, and references are stored in .VBA files located in the Dynamics GP application directory.  The main file for GP VBA customizations is Dynamics.vba; however, if VBA was added to modules that are not included in Dynamics.dic, then there may be multiple .VBA files with customizations, such as HR.vba or AA.vba.  Note that there are usually many .vba files in the GP application directory--most of those are 'empty' and do not contain any customizations.

One very nice thing about the Customization Maintenance window is that you can export and import customizations using .package files.  This is a great way to backup individual customizations, or all customizations, independent of your FORMS.DIC and .VBA files.


Add Ins

C:\Program Files\Microsoft Dynamics\GP\AddIns

Add Ins are DLL files that were developed using Dynamics GP Visual Studio Tools and Visual Studio .NET.  These are customizations that can offer all of the power and flexibility of .NET, yet run within the context of Dynamics GP and look very much like a standard Dynamics GP window.

By default with GP 2010, it looks like there are 15 files installed in the AddIns directory, most of which are named "Microsoft.Dynamics.GP...", making them easy to rule out as customizations.



Other Customizations to Consider

External Reports and Queries

Many customers use Crystal Reports, MS Access, Excel, SSRS reports, or other tools to query Dynamics GP data.  While GP upgrades may not change database tables enough to cause those reports to break, you may need to 're-point' those reports to the new SQL Server instance or databases after you have upgraded to GP.  And if you have a problem with any of those reports and need support, it's always good to know which custom reports are out there.

One common issue I have seen is that a lot of clients develop and deploy such external reports using the 'sa' login.  When the 'sa' password needs to be changed, it breaks these reports and users complain.  Such reports should never use the 'sa' login, so it's good to review those reports and make sure that they use a dedicated reporting login with limited access.


Integrations

If any data is being imported to Dynamics GP, you will want to identify those integrations.

If you use Integration Manager, you should make sure to backup your IM.mdb database file and have some documentation of your integrations, including source files and an import procedure.

If you have any other tools, such as SmartConnect or Scribe, a similar backup + documentation procedure is recommended.

If you have any custom eConnect integrations, you should ideally have full documentation, an installation (exe and/or msi), and source code, including any database objects (custom tables, stored procs) that the integration may require.


Custom integrations can be challenging for a few reasons.  First, because they are not referenced in any of the standard GP files discussed above, you may not know they exist.

Second, even though an integration may look simple on the surface, it may have horrendously complex and intricate code behind the scenes--something that I've seen numerous times.  This can lead you to believe that they will be simple to support and upgrade, when they will actually be very difficult to deal with.

Finally, custom integrations, such as those developed using Visual Studio, require the full source code to be upgraded.  If a customer has switched partners one or more times, it may be difficult to get the source code for those custom integrations.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com