Development Matters Blog

The Support Debugging Tool is a Dexterity-based suite of utilities and tools created to assist with the task of supporting Microsoft Dynamics GP.

Some examples of purposes where the Support Debugging Tool can be used are listed below:

• To identify the specific series of events which lead up to an issue or bug in the code occurring.
• To quickly and simply turn on all logging and profiling capabilities without restarting the application. This can be useful when looking at performance problems.
• To find details about dictionary resources.
• To identify resources (forms, reports and tables) causing security access issues.
• To enable and disable third party products or change the order of the products in the launch file.
• To export data from and import data to any table.
• To run SQL or Dexterity scripts without needing Dexterity or SQL Administration Tools installed.
• To capture and email or save screenshots of all open windows and a system status report.

The Support Debugging Tool is installed by copying the Debugger.cnk (self-installing dictionary), Debugger.txt (readme file) and Debugger.pdf (this user guide manual) to the Microsoft Dynamics GP application folder. When Microsoft Dynamics GP is next launched, select “Yes” to include new code. The Support Debugging Tool requires the version 8.00 Dexterity Runtime update 8.00m88 or version 9.00 Service Pack 3 or later. The Support Debugging Tool works with all builds of version 10.00.

Resource Information is one of the Standard mode features of the Support Debugging Tool.

By selecting Resource Information from the Options button drop list on the main window of the Support Debugging Tool, you can open the Resource Information window.

You can use the Resource Information window to show technical, display, and physical names and resource IDs for any form, window, field, table, table group or report resource in any dictionary currently installed in the Microsoft Dynamics GP application.

If you know any information about a resource, you can enter it into the appropriate field and the rest of the fields will be populated with the details for that resource.

For example, entering a window’s display name will identify the window’s technical name and resource ID; or entering a table’s physical name as it appears in SQL Server will identify the table’s dictionary,
technical and display names as well as the resource ID.

This window can be useful when working with table and column names in SQL Server, because it will quickly convert the physical names used in SQL back to the technical names used in Modifier, Report Writer and Dexterity.

We have recently added two new white papers to our Microsoft Dynamics GP Development page.

Microsoft Dynamics GP Architecture White Paper
This document describes the architecture for Microsoft Dynamics™ GP. It explains how the architecture’s features make Microsoft Dynamics GP an outstanding solution for organizations implementing a business management system today. The document also describes how the architecture allows Microsoft Dynamics GP to grow with these organizations in the future.

Microsoft Dynamics GP: Choosing a Development Tool White Paper
Several development tools are available to be used when creating integrations with Microsoft Dynamics
GP. This paper provides guidance when choosing which development tool to use to create an integration for Dynamics GP. A detailed description of each tool is provided in this document. You can use this information and the comparison charts at the end of the document to help you make a decision about the best tool to use for a specific integration.

Merit Solutions Advanced Lot Management (ALM) is the application that allows efficient control of lot tracked materials (raw or finished goods) within Microsoft Dynamics GP (versions 9 and 10).

The system requirements correspond to requirements of Microsoft Dynamics GP. ALM version 9 requires Dynamics GP’s Manufacturing module to run, while ALM version 10 does not require the Manufacturing module.

Lot Attribute Maintenance

The Lot Attribute Maintenance window is arguably the most used window of the ALM application. Its main purpose is to provide information on the lot properties of an item, including the Lot Status, Expiration Date, and Vendor Lot, as well as other lot attributes defined in the Lot Category for the item (Cards > Inventory > Item (Maintenance) > Item Maintenance Options > Lot Category) and provide a place for editing those attributes.

In the Lot Attribute Maintenance window, both types of lot tracked Items (Cards > Inventory > Item (Maintenance) > Item Maintenance Options > Track), Non-QA Controlled and QA-Controlled (Cards > Inventory > Item (Maintenance) > Additional > ALM Item QA Control Setup), are listed.

For Non-QA Controlled items, the default Lot Status always will be set to Approved and default Expiration Date always will be set to 0/0/0000. These settings for Non-QA Controlled (but lot tracked) items can be changed on Lot Attribute Maintenance window.

For QA Controlled items, the default Lot Status will be inherited from the Advanced Lot Management Configuration window > Default Lot Status for New Lots () option.

On the same window, the default value for Lot Status Attribute can be changed. The Expiration Date is by default set to the value of: System Date minus one day (for example: for all lots received on 5/7/2009, default expiration date will be 5/6/2009). This means that Item Lots can’t be forwarded along, before their attributes are reviewed by QA personnel, and the Expiration Date is at least changed to the present or any date in future.

Filter By option on the Lot Attribute Maintenance window affects only QA Controlled items. Set the Filter By value to “Rejected”, click Refresh and check lots of both QA Controlled and Non-QA Controlled items.

By the way, any changes made on this window to Lot Attributes, have to be saved by clicking Save button. Simple leaving or closing the Lot Attribute Maintenance window is not enough.

A Few days ago, I tried to install Dynamics GP web services. I thought that all of the prerequisites were satisfied (OS, ISO, IIS, ASP, etc) but when installation started I got an error:

ADAM Error – Error Code: 20038.The wizard could not access the registry. Error code: 0x800706fd. The trust relationship between this workstation and the primary domain failed.

I found some info on Internet that one person noticed that this error occurs when installation is run on computer which is joined to a domain. That was all…

What I did next was assign the computer on WORKGROUP and log in as local admin. After starting installation everything was just great. Installation was finished successfully!

Then I went back to WS Install Admin Guide and found interesting content about ADAM.

ADAM or Active Directory Application Mode is required by the Dynamics Security Service. In order to install Dynamics GP Web Services, the current user must be in ADAM administrator role. The user who installed Windows Server 2003 (in my case local admin) automatically is in this role. But if we want to enable some other users to install, update or modify GP Web services we should add them in this role.

Note: ADAM is related to Windows Server 2003 and ADMSL (Active Directory Lightweight Directory Services) is related to Windows Server 2008 and we have same situation for both.

For more details see Appendix A: ADAM or ADLDS Administrators in WS Install Admin Guide. You can find it here.

In short notes, to add new user in ADAM Administrator Role, follow next steps:

• You must we logged as ADAM administrator.
• Open All Programs->ADAM.
• Create connection: Action-> Connect To and define connection string to server onto which GP Web services were installed. If the Web Services for Microsoft Dynamics GP installer has installed ADAM or the ADLDS instance, it will use the default port 389. If you’ve used a different port, specify that port value. Choose Configuration as the well-known naming context.
• Click OK to connect.
• Find ADAM installation and expand tree to find CN=Roles node.
• In the list of roles, select Administrators. Choose Properties from the Action menu to display the properties for the Administrators role.
• In the list of attributes for the Administrators role, locate and select “member”. Click Edit. The Multi-valued Distinguished Name with Security Principal Editor window will be displayed.
• Click Add Windows Account to specify the user to add as an administrator.
• Click OK to save your changes.
• Click OK to close the Administrator role properties window and close ADSI Editor.

You probably already have experience with the Dynamics Debug function. To use this option, the Dex.ini file should be extended with the new statement, ScriptDebugger=TRUE, which allows you to see debug messages, scripts, procedures and functions in the background of Dynamics GP.

Let’s say that you have a client who gives you access to a test environment via Citrix. You want to check the script’s behavior by clicking CTRL+F1, but nothing happens.

• Resolution: Keep the SHIFT button pressed and using the mouse select Debug -> Script Debugger option.

And, Script Debugger is opened!

Merit Solutions Advanced Lot Management (ALM) is the application that allows efficient control of lot tracked materials (raw or finished goods) within Microsoft Dynamics GP (versions 9 and 10).

The system requirements correspond to requirements of Microsoft Dynamics GP. ALM version 9 requires Dynamics GP’s Manufacturing module to run, while ALM version 10 does not require Manufacturing module.

Expiration Date

Expiration Date is one of lot attributes tracked with ALM 10. In case the expiration date of a lot is in the past, then that lot can’t be used. Users should be careful with this, since every newly accepted lot automatically receives (expired) expiration date – the system date minus one day. This was made on purpose, to force QA users to manually enter valid expiration dates for each lot.

Once entered, these dates can be changed by QA users at any time. On the Lot Attribute Maintenance window, when selecting a lot, it’s Expiration Date is shown in the corresponding field. Simply overwriting the existing value with the new one and saving new setting is enough.

In case value in the Expiration Date field is empty, i.e. ‘00000000’ it means that the selected lot was accepted more than once, and that each time a different expiration date was set for it. By opening the Change Expiration Date window, a complete list of existing Expiration Dates for the lot will be listed. These values can be changed one by one on the Change Expiration Date window. On the Lot Attribute Maintenance window, the common Expiration Date can be set as already described above. A Warning message will inform the user that the previously set dates will be lost.

Merit Solutions Advanced Lot Management (ALM) is the application that allows efficient control of lot tracked materials (raw or finished goods) within Microsoft Dynamics GP (versions 9 and 10).
The system requirements correspond to requirements of Microsoft Dynamics GP. ALM version 9 requires GP’s Manufacturing module to run, while ALM version 10 does not require Manufacturing module.

ALM is focused on two pieces of information: Lot Status and Expiration Date. These information affect when and how material can be used.

Configuration

 Configuration of ALM should start in Advanced Lot Management Configuration window, the same one in which module was enabled for the company. Two options can be set on this window:

- Lot Status Missing Icon
- Default Lot Status for New Lots

 
The first option, “Lot Status Missing Icon”, defines the icon that will be shown in the Lot Status Maintenance window for new lots created (received) in situations when ALM was installed, but was not enabled for the company. Ten options are available to user, including: black, blue green, light blue, orange, pink, red and yellow dots, yellow triangle (named Warning) or empty field. The yellow triangle (Warning) is default value for the Lot Status Missing Icon.

The second option “Default Lot Status for New Lots” defines which status newly received lot will get by default. Four options are pre-created and available for the user: Approved, Hold, Quarantined and Rejected. The Quarantined option is the default value for the Default Lot Status for New Lots.

The Lot Status Maintenance window should be the second stop during the configuration process. Pre-created Lot Statuses can be found here and new statuses can be created.

 More importantly, on this window, the user can define for which transactions ALM can automatically assign a Status to a Lot. It is done by simply checking (un-checking) Allow boxes in the right side of the grid.

The QA User Setup window contains the list of all users of the company currently running Dynamics GP. In order to allow users to fully utilize all of ALM’s functionalities, the QA users should be defined. In QA User Setup window, double click on users name. The empty dot, left of the user name, should turn to a green dot. When finished click DONE button. The same procedure should be followed for assigning user classes. QA User Setup is company specific.

A User ID may have different privileges to Advanced Lot Management in different companies.

Finally, lot tracked items should be defined as ALM QA controlled. That way, for transactions defined in the Lot Status Maintenance window, new lot numbers for the item will receive the defined default lot status. Open the Item Maintenance window (Cards > Inventory > Item) and browse for the inventory item that will be ALM QA Controlled. Then open the QA Item Setup window (Item Maintenance window > Additional (menu) > ALM Item QA Control Setup) option.

On QA Item Setup window select Item is QA Controlled check box.

‘Pass through Dex’ code includes only using tables from the original Dynamics GP dictionary and tables from the Dynamics GP module that you want to include in using the execute command. If you need any other table, you have to submit it to code like the inout table, and you have to do the same for all other fields of that table which are used in this code. Otherwise, the table would not be recognized.

There is an example of ‘pass through Dex’ code. We use table SVC_RTV_MSTR in code, which belongs to the 949 module called in the execute() function and we use our table mxTable which neither belongs to Dynamics GP nor the 949 module.

The tables that will be passed to the procedure will have the address information but will not necessarily have the fields named Name_field, Address_field, like in ‘pass through Dex’ code.

local text code;
local string compile_message;
clear field code;
code = code + “inout anonymous table Table;“;
code = code + “inout anonymous field Name_field;“;
code = code + “inout anonymous field Address_field;“;
code = code + “range clear table SVC_RTV_MSTR;”;
code = code + “release table SVC_RTV_MSTR;”;
code = code + “clear table SVC_RTV_MSTR;”;
code = code + “get first table Table;”;
…

error_count = execute(949,

code,

compile_message,

table mxTable,

field mxName,

field mxAddress);

if error_count <> 0 then 

warning “Error in pass-through sanscript – ” + compile_message;

abort script;

end if;
 

As the knowledge of Dexterity and Microsoft Dynamics GP grows, the projects get bigger and more complicated. The customizations we produce are more and more tightly integrated with core Dynamics GP processes and very often they control and change those core processes and flows.

Such modifications are quite challenging for developers and they most often like to deal with such problems. The main pain point that rises from such customizations are bugs or issues which might appear due to the uniqueness of a customer’s environment or data. Such issues are very difficult to replicate which leads to very ineffective support.

Asking customers to enable the Script Debugger and create a log file or organizing Live Meetings with a demonstration of the issue can often be time consuming for both sides. The elegant solution for such cases may be creation of log files directly from our code. The Developer can incorporate the creation of log files directly in the code which calls the “risky” logic through ScriptLog_Start() and ScriptLog_End() functions of Dexterity.

Logging will overwrite the previous log file every time “risky” logic is initiated. In most cases the issue is identified immediately so if path where the log file is saved is documented, the customer can attach it to a support request and make identifying of the cause much easier.