Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
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'):
10Microsoft 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 GrantMicrosoft Dynamics GP Support Team
Business Applications communities