As Microsoft Dynamics GP has the good fortune of being a mature product with many 3rd party add-in products available to augment overall functionality of the software, if end users do run into processing issue is often hard to determine if it is caused by default or add-on code.

This is an important distinction to the Microsoft Dynamics GP support team because as we don't have direct access to all alternate processing code and/or known quality issues with the additional products such issues are harder to troubleshoot when non-default items appear in processing logs and/or the code operates in a different manner than comparison logs produced under default code.

In such case, it is usually first case recommendation to omit the 3rd party code from the picture to help ensure default Microsoft Dynamics GP code can be tied to the erring performance so we would be able to pinpoint the exact code causing issue to address in future releases of the product.


The very best methods to do so are outlined in the following KB article:

How to disable third-party products in the Dynamics.set file in Microsoft Dynamics GP
https://support.microsoft.com/en-us/help/872087/steps-to-disable-third-party-products-or-temporarily-disable-additiona


As outlined in Method 1 the article, you can edit the dynamics.set file used to log into Microsoft Dynamics GP from the erring code folder to omit any non-default code being called when direct testing the processing issue in question.

In addition to the edit route outlined in the KB, an alternate route you may want to consider is to simply comment out the unwanted lines in the dynamics.set file prior to logging in from the erring Microsoft Dynamics GP folder.

This would be accommplashed in a similar method as while you would still edit the file to decrease the top 'total' value of modules in place, instead of completely removing the unwanted reference lines from the file you would comment them out using two dash (--) characters the beginning of each unwanted line.

For instance, the example that appears in the KB can instead be edited as the following to omit the SmartList module during log-in (note the top value of '2' loaded products changed to '1'):

1
0
Microsoft Dynamics GP
--1493
--SmartList
:C: Microsoft Dynamics GP/Dynamics.dic
:C: Microsoft Dynamics GP/Forms.dic
:C: Microsoft Dynamics GP/Reports.dic
--:C: Microsoft Dynamics GP/EXP1493.DIC
--:C: Microsoft Dynamics GP/EXP1493F.DIC
--:C: Microsoft Dynamics GP/EXP1493R.DIC


This may be helpful in that you won't be creating several different dynamics.set files when troubleshooting default code and instead working with one file that can be readily placed back to the prior build by removing the comment marks re-setting the top value prior to your next log-in.

As noted in the KB, if you are having issue logging in with the trucated dynamics.set file it is usually due to one of the files in the 'AddIns' folder of the erring Microsoft Dyanmics GP code folder needing content from the omitted dictionary(s) in order to function correctly during log-in activity.

As such, another good rule when testing with 'Method 1' of the KB is to create a 'TEMP' file in the existing 'AddIns' in which you can temporarily move the rest of the content of the 'AddIns' folder into to avoid such log-in error.


Once you do successfully log into Dynamics GP with the new dynamics.set file, it is also a good idea to use the Tools | Setup | System | User Security to assign an Alternate Modified Forms and Reports ID to the testing user that doesn't have access to any modified items in the installation.

This will help to ensure you are testing with the default windows and reports only and allow you to leave the current modified security assignments completely intact as well.

Last, in order to ensure you are completely omitting 3rd party code from your testing process it is highly recommended that you choose Method 3 from the KB to create an entirely new code folder containing default code only for testing purposes and leaving your default Microsfot Dynamics GP code folder installation 'as-is'.

This will allow you not only to make certain you are testing with default Microsoft Dynamics GP code, but it will allow you to re-add each additional product to the new installation once initial testing has been completed as if the issue can only be recreated after an alternate product has been re-introduced it often indicates a possible code mismatch between the version of the add-in product and the exact version of Microsoft Dynamics GP currently in use.


Jeff Grant
Microsoft Dynamics GP Support Team