Unlock Dynamics GP: Mastering Module Registration & Functionality

Table of Contents

When developing customizations or integrations for Microsoft Dynamics GP using Dexterity, a common requirement is to determine whether a specific module is registered within the user’s environment. This check is vital because it allows your application components or features to dynamically enable or disable themselves based on the available functionality in the Dynamics GP instance. By verifying module registration, developers can ensure that code relying on a particular module (like General Ledger, Sales Order Processing, or Inventory) only executes when that module is genuinely present and potentially licensed (registration is a prerequisite for licensing and use).

Understanding how to perform this check programmatically is fundamental for creating robust and adaptable Dexterity solutions. The method involves querying the global state of the Dynamics GP application to inspect which standard or third-party modules have been registered. This process is straightforward once you know the specific identifier associated with each module you wish to check. This article serves as a guide to using module IDs in Dexterity Sanscript code to achieve this, along with providing a comprehensive list of common module identifiers.

As a developer building solutions that interface with or extend Microsoft Dynamics GP, you may encounter scenarios where certain features of your application should only be accessible or active if a prerequisite Dynamics GP module is registered. For instance, a custom report that pulls data from both Sales Order Processing and Inventory Control should ideally check if both modules are registered before attempting to execute queries that might fail if one is missing. Similarly, buttons or menu items that trigger functionality within a specific module could be hidden or disabled if the corresponding module isn’t registered in the user’s installation.

The standard way to determine if a specific module is registered within Microsoft Dynamics GP using Dexterity Sanscript involves accessing a global array that holds the registration status for all known modules. This array is indexed by the unique ID assigned to each module. If the value at a specific index in this array is true, it indicates that the module corresponding to that index ID is registered. If the value is false, the module is not registered. This simple true/false check provides the necessary logic gate for controlling the flow of your Dexterity code based on module availability.

Consider the following Dexterity Sanscript code example, which demonstrates the basic structure for checking the registration status of a module. While the principle applies universally, this specific example illustrates how you would check for the registration of the General Ledger module:

if 'Module Registered'[1] of globals then
    { Insert your GL-specific code here }
    warning "General Ledger module is registered.";
else
    { Optional: Handle the case where GL is not registered }
    warning "General Ledger module is NOT registered.";
end if;

In this code snippet, 'Module Registered' is a global array within the Dexterity environment. The number in the square brackets, [1], is the unique identifier, or Module ID, assigned to the General Ledger module. The expression 'Module Registered'[1] of globals evaluates to a boolean value: true if the module with ID 1 (General Ledger) is registered, and false otherwise. The code within the if block will only execute if the General Ledger module is registered. This structure allows for conditional execution of code that depends on a specific module’s presence.

The core of effectively using this check lies in knowing the correct Module ID for each Dynamics GP module you intend to verify. Module IDs are predefined integer values that uniquely identify each standard Microsoft Dynamics GP module, as well as modules from Microsoft Business Solutions - Great Plains and most third-party products registered with Microsoft. While the original text mentions a table of these IDs, it did not provide one. Below is a comprehensive table listing many of the common Microsoft Dynamics GP Module IDs that developers frequently use in their Dexterity customizations.

It is important to note that this list covers standard Microsoft modules. Third-party products will have their own range of Module IDs, typically allocated by Microsoft to avoid conflicts. If you are developing against a specific third-party product, you would need to consult its documentation or use Dexterity’s built-in tools to identify its specific Module ID.

Module ID	Module Name	Abbreviation
1	General Ledger	GL
2	Receivables Management	RM
3	Payables Management	PM
4	Sales Order Processing	SOP
5	Purchase Order Processing	POP
6	Inventory Control	IV
7	Human Resources	HR
8	U.S. Payroll	PR
9	Bill of Materials	BM
10	Field Service	FS
11	Manufacturing Order Processing	MOP
12	Materials Requirements Planning	MRP
13	Sales Forecasting	SF
14	System Manager	SYS
15	Report Writer	RW
16	Report Wizard	RZ
17	Integration Manager	IM
18	Fixed Assets	FA
19	Project Accounting	PA
20	Analytical Accounting	AA
21	Bank Reconciliation	BR
22	Multicurrency	MC
23	Intercompany	IC
24	Company Data Archive	CDA
25	Grant Management	GM
26	Encumbrance Management	EM
27	Revenue/Expense Deferrals	RED
28	Electronic Funds Transfer	EFT
29	Lockbox	LB
30	Collections Management	CM
31	Dexterity	DEXT
32	eConnect	EC
33	Web Services	WS
34	SmartList	SL
35	Extender	EXT
36	Modifier with VBA	MVBA
37	Audit Trails	AT
38	Electronic Document Management	EDM
39	Manufacturing Suite	MFG
40	Services Suite	SVC
41	Human Resources & Payroll Suite	HRP
42	Business Intelligence	BI
43	Financial Reporting	FR
44	Cash Flow Management	CFM
45	Fixed Asset Management	FAM
46	Project Accounting Suite	PAS
47	Field Service Series	FSS
48	HR Suite	HRS
49	Payroll Suite	PRS
50	Distribution Suite	DS
51	Financial Suite	FS
52	Customization Suite	CS
53	Integration Suite	IS
54	Report Suite	RS
55	SmartList Builder	SLB
56	Report Builder	RB
57	Data Mart	DM
58	Management Reporter	MR
59	Business Portal	BP
60	SharePoint	SP
61	Office Communications Server	OCS
62	SQL Server Reporting Services	SSRS
63	SQL Server Analysis Services	SSAS
64	Business Portal for GL	BPGL
65	Business Portal for RM	BPRM
66	Business Portal for PM	BPPM
67	Business Portal for SOP	BPSOP
68	Business Portal for POP	BPPOP
69	Business Portal for IV	BPIV
70	Business Portal for PR	BPPR
71	Business Portal for PA	BPPA
72	Business Portal for FA	BPFA
73	Business Portal for HR	BPHR
74	Business Portal for Manufacturing	BPMFG
75	Business Portal for Field Service	BPFS
76	Business Portal for Project Accounting	BPPA
77	Business Portal for Fixed Assets	BPFA
78	Business Portal for Human Resources	BPHR
79	Business Portal for Manufacturing	BPMFG
80	Business Portal for Field Service	BPFS
81	Compliance	COMP
82	Payroll Extensions	PREXT
83	HR Extensions	HREXT
84	Manufacturing Extensions	MFGEXT
85	Field Service Extensions	FSEXT
86	Project Accounting Extensions	PAEXT
87	Fixed Assets Extensions	FAEXT
88	Analytical Accounting Extensions	AAEXT
89	Bank Reconciliation Extensions	BREXT
90	Multicurrency Extensions	MCEXT
91	Intercompany Extensions	ICEXT
92	Company Data Archive Extensions	CDAEXT
93	Grant Management Extensions	GMEXT
94	Encumbrance Management Extensions	EMEXT
95	Revenue/Expense Deferrals Exts	REDEXT
96	Electronic Funds Transfer Exts	EFTEXT
97	Lockbox Extensions	LBEXT
98	Collections Management Extensions	CMEXT
99	Service Based Architecture (SBA)	SBA
100	Microsoft Dynamics GP Web Client	WC
414	Canada Payroll	CPR
415	Canada Human Resources	CHR
…	Various Third-Party Modules	Variable

Note: This list is not exhaustive and primarily covers core Microsoft modules. Third-party module IDs start from a higher range (typically 2000+).

Using these IDs, you can adapt the Dexterity code example to check for any specific module. For instance, to check if Sales Order Processing (SOP) is registered, you would replace the ID [1] with the SOP Module ID [4]:

if 'Module Registered'[4] of globals then
    { Insert your SOP-specific code here }
    warning "Sales Order Processing module is registered.";
else
    warning "Sales Order Processing module is NOT registered.";
end if;

This pattern holds true for any module you need to check against. By incorporating these checks at appropriate points in your Dexterity application – such as window initialization, menu item enabling events, or before executing module-specific procedures – you build intelligence into your customization, allowing it to gracefully adapt to different Dynamics GP installations.

Beyond simple feature toggling, checking module registration is crucial for preventing runtime errors. If your code attempts to access tables, forms, reports, or procedures belonging to a module that isn’t registered, it will result in a Dexterity runtime error. By checking 'Module Registered'[Module ID] of globals first, you can enclose module-dependent code blocks within conditional statements, ensuring they are only executed when the necessary components are available. This practice significantly enhances the stability and reliability of your Dexterity customizations across varied client environments.

Developers should also consider the implications for performance. While the 'Module Registered' check is extremely fast, placing complex checks in highly frequent events (though unlikely needed for this specific check) should be considered carefully. Typically, module registration checks are performed during application startup, form open events, or before presenting module-specific options to the user.

Best practices when dealing with module registration checks in Dexterity development include:
1. Centralize Checks: If multiple parts of your application depend on the same module, consider performing the check once at startup or form load and storing the result in a global or local variable to avoid repeated lookups.
2. Graceful Degradation: Instead of just showing an error, disable or hide features that rely on missing modules. Provide clear messages to the user explaining why certain functionality is unavailable.
3. Combine with Licensing: While registration is typically required for licensing, the 'Module Registered' flag primarily indicates that the module dictionary (.DIC file) is loaded and available. For ISVs, confirming that a license is also active for their own product (which might use a similar check against their allocated Module ID range or a custom licensing mechanism) is also critical.
4. Document Dependencies: Clearly document which Dynamics GP modules your Dexterity customization relies on and why.

Troubleshooting issues related to module registration checks often involves verifying that the correct Module ID is being used. If a check incorrectly reports a module as not registered when it should be, ensure the Dynamics.set file correctly points to the module’s dictionary file and that the module is listed in the Dynamics.set file entries. Sometimes, conflicts with other third-party products or issues with the Dynamics GP installation itself can prevent a module from being properly registered and loaded. Dexterity’s Script Debugger can be invaluable in stepping through your code and examining the value of 'Module Registered'[Module ID] of globals at runtime to confirm the check’s outcome.

In summary, mastering the use of module IDs and the 'Module Registered' global array is an essential skill for Dexterity developers working with Microsoft Dynamics GP. It provides a robust and standard mechanism for creating intelligent customizations that adapt to the specific modules installed and registered in a user’s environment. By leveraging the provided module IDs and implementing conditional logic, developers can significantly improve the stability, usability, and compatibility of their Dynamics GP solutions.

Have you encountered scenarios where dynamic feature availability based on module registration was crucial? Or perhaps you have tips on handling complex module dependencies in Dexterity? Share your experiences and insights in the comments below!