This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
I had been planning to write this post after I was able to resolve a recent support case really quickly using the Support Debugging Tool. Then Christina wrote her post on Troubleshooting Tips and Tricks and it makes this post even more relevant.
The case I was working on was an error dialog generated on the Receivables Cash Receipts window. However, if the window was opened directly from the navigation pane or menus, there was no error. If the window was opened using the Transaction Button from the Receivables Batch Entry window, the error dialog was generated.
As per standard procedure, we always ask if there are any customizations involved, and were told by the partner that there were no customizations to the Receivables Cash Receipts window.
So, after some research into the source code to confirm the possible reasons for the dialog to show, I was unable to find anything that could explain the behaviour we were seeing. I decided that we needed to double check if a customization was involved.
A screen sharing session was organised and the customer was able to demonstrate to the partner and I that the issue still occurred. I asked the partner if the Support Debugging Tool was installed at the site and was please to find that it was (this partner is now install the SDT on all sites by default).
So we activated the Security Profiler window (example window shown below) and recreated the issue.
The first thing that I noticed was Receivables Batch Entry window was an alternate window. So even though the Receivables Cash Receipts window was the original version and this is where the error occurred, it was being opened from a custom version of the Receivables Batch Entry window.
However, we now needed to prove that the error was caused by this customization.
So using the Support Debugging Tool’s Dictionary control window (example window shown below), we disabled the customization.
The advantage of using this window is that not only can we disable the triggers (similar to the Customization Status window), but we can also disable the alternate window without making any changes to security. This can remove the effects of the third party product without needing the edit the Dynamics.set Launch File or modify security settings. On a terminal server system, we can disable the product for the current session without affecting other users. We can also set the Dictionary Control settings to Disable After Login, which will keep a product disabled for all sessions until re-enabled.
Anyhow, as soon as we disabled the customization, we were no longer able to replicate the issue and the error dialog was not displayed. After enabling the customization again, the problem returned.
So we identified the cause of the issue and were able to suggest to the partner that they report the issue to the developer of the third party customization.
The Support Debugging Tool did its job and helped solve an issue simply and quickly.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.