A common question from Dynamics GP users is how to determine the presence of customizations or third-party modules within their system. This knowledge is crucial for both clients and partners, especially during partner transitions or upgrades, to ensure proper support and compatibility.
Since Dynamics GP lacks a single feature to provide this information directly, pinpointing installed ISV solutions or customizations requires checking multiple areas and having a degree of familiarity with the system. Let’s explore some key areas to examine.
Customization Status
The Customization Status window, accessed through Tools -> Customize -> Customization Status, offers a starting point. It displays active Dynamics GP modules, Dexterity-based ISV solutions, and customizations. However, distinguishing standard GP modules from ISV solutions or customizations can be challenging without prior knowledge of the typical GP module list.
Dynamics.set
Located in the Dynamics GP application directory (typically C:\Program Files\Microsoft Dynamics\GP), the Dynamics.set file provides a more technical representation of the Customization Status list. Opened with Notepad, it reveals details like the total module count, individual module IDs, names, and dictionary file paths.
Examining this file helps identify third-party or custom Dexterity dictionaries. Maintaining a copy of the full Dexterity project and source code is crucial for modifications and upgrades involving Dex customizations.
The Dynamics.set file can also indicate if GP utilizes “shared dictionaries,” signifying that workstations reference a single, potentially modified, FORMS.DIC or REPORTS.DIC file. This setup suggests the presence of customized forms or reports. For instance, a shared dictionary setup might have a different path for FORMS.DIC or REPORTS.DIC compared to the Dynamics.dic path.
Customization Maintenance
Accessible via Tools -> Customize -> Customization Maintenance, this window lists active modified forms, reports, custom VBA code, and references. It covers customizations implemented using Modifier, VBA Editor, or the Dynamics GP Report Writer.
Understanding the storage locations of these customizations is essential. Modified Forms reside in the FORMS.DIC file, modified Reports in the REPORTS.DIC file, and VBA code, user forms, and references within .VBA files within the Dynamics GP application directory. While the primary file is Dynamics.vba, additional module-specific .VBA files (e.g., HR.vba, AA.vba) might exist if customizations are present.
The Customization Maintenance window offers a valuable feature: exporting and importing customizations using .package files. This allows for individual or comprehensive customization backups, separate from FORMS.DIC and .VBA files.
Add Ins
The AddIns directory (C:\Program Files\Microsoft Dynamics\GP\AddIns) houses DLL files created using Dynamics GP Visual Studio Tools and Visual Studio .NET. These customizations, resembling standard Dynamics GP windows, harness the capabilities of .NET while operating within the Dynamics GP environment. Identifying customizations is generally straightforward, as most default files in the AddIns directory start with “Microsoft.Dynamics.GP…”.
Other Customizations to Consider
Beyond the locations mentioned above, considering other customization forms is vital.
External Reports and Queries often involve tools like Crystal Reports, MS Access, Excel, SSRS reports, or others to access Dynamics GP data. While upgrades might not always impact these reports, “re-pointing” them to new SQL Server instances or databases after a GP upgrade is sometimes necessary. Maintaining an inventory of these custom reports is beneficial for support purposes. It’s important to ensure such reports use dedicated logins with restricted access and avoid relying on the ‘sa’ login.
Integrations, especially those facilitating data imports into Dynamics GP, require identification. For Integration Manager, backing up the IM.mdb database file and documenting integrations, including source files and import procedures, is recommended. A similar approach applies to tools like SmartConnect or Scribe.
For custom eConnect integrations, comprehensive documentation, installation files (exe or msi), and source code are essential. This includes any custom database objects like tables or stored procedures required by the integration.
Custom integrations pose unique challenges. Their existence might not be evident due to the lack of references in standard GP files. Their apparent simplicity can conceal complex underlying code, leading to unforeseen difficulties during support or upgrades. Upgrading custom integrations developed using Visual Studio necessitates the complete source code, which can be difficult to obtain, especially with multiple partner changes.