Wednesday, June 29, 2011

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.


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.


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.


Andy Nifong said...

Great post Steve, very helpful reference to what can be a tricky process.

Slaw said...

Tools -> Customize -> Customization Status

Do you know which tables this list is created from?

Steve Endow said...

Hi Slaw,

The information displayed in the Customization Status window is not stored in a table. As I mention in the section on the Dynamics.set file, the window essentially displays the same list of dictionaries that are present in Dynamics.set.

If you see something listed in Customization Status, you should be able to trace it to your Dynamics.set file to identify the corresponding dictionary.


Steve Endow

Bron Tamulis said...

Hi Steve -

Thanks for your post. I am wondering if you can help me with something.

We have GP9 - someone (long ago and no longer available) create a completely new SOP Transaction Screen.

It shows up under customization maintence as 'SOP_Entry'.

I upgraded from V9 to V10 upgraded the modified forms and reports - got lots of error messages. Particularly on the SOP_Entry form.

I go to Visual Basic Editor (and this really throws me) I don't see any projects under Dynamics GP - ??? Shouldn't I be able to open this form in Visual Basic editor (version 10) to see what has been done?

I did copy the dynamics.vba from GP9 to GP10......

Any guidance would be appreciated.

Steve Endow said...

Hi Bron,

SOP_Entry is the standard Dynamics GP Sales Transaction Entry window.

If the modification is only cosmetic, i.e. they added a label or text or moved some fields on the form, there may not be any VBA code associated with the window.

If you open the MODIFIED version of the SOP Entry window, check to see if there is a period at the beginning or end of the window name in the upper left corner of the window. So you might see:

".Sales Transaction Entry"


".Sales Transaction Entry."

If there is a period at the beginning of the window name, that means that it has been modified using Modifier.

If there is a period at the end of the window name, that means that it has VBA code.

If there is no period at the end, then there shouldn't be any VBA code.

Hope that helps.


Matt Cullen said...

Steve this is great information, even many years later. Thanks!

I'm looking to figure out a quick way to look at a Dynamics.set file and distinguish what's part of GP (like Smartlist) and what is not (like Mekorma MICR). Is there some kind of standard list?



Steve Endow said...

Hi Matt,

I'm not aware of a good way to quickly identify third party products in the SET file.

I primarily identify them based on familiarity with the standard GP modules and dictionaries--if it isn't one of the standard GP modules, then it is usually a third party product.


julfs said...

I am new in Microsoft dynamics gp 10.0. customized bank transaction entry form using visual studio sdk tools .using export import method tried to deploy these, but changes not reflected in client machine.may i know what are the steps to depoly modified form

Steve Endow said...

Hi @julfs,

If you modified a Dynamics GP for using Modifier and imported them into a GP install, you will need to make sure that the Modified Form is selected in the user's GP security role.

Here is a Microsoft article on providing access: