When developing Dynamics GP customizations in our WebSan environment, our development phase is contained within a local server configuration to ensure that all modifications to the forms and reports dictionaries are local and will not affect our hosted users. However, there are a few more items to note when separating a development from a production environment.
When enabling and granting access to modified forms and reports in GP, administrative users would navigate to the Microsoft Dynamics GP menu >> Administration >> Alternative/Modified Forms and Reports and grant access to the modified item by selecting the ID, Product, and Type (Windows: Forms or Reports), then checking the box beside the version they would like accessible:
The ID field at the top of this window is used to specify which group of users has access to the forms and reports chosen in the list underneath. Users are assigned an “Alternate Modified Forms and Reports ID” in the ‘User Security’ window:
Therefore, if you are customizing the ‘Payables Transaction Entry’ window and want to ensure that current GP users cannot view these changes until they are completed, you can add your own GP login to a new “DEV” group that has the customized form selected such that further work and testing can be performed without effecting production users. While the ID field handles what version of the form or report the user can view, any VBA code that is applied to the customization is made accessible through the “EventMode” property in the ‘Visual Basic Editor’ (Alt+F11), if the form or report has been added to VBA.
Within the VBA code, you can select the form or report that is using VBA and set the EventMode property to either “0-emOriginalOnly”, “1-emModifiedOnly”, or “2-emNever”. The first applies the VBA code to the original (un-modified) object only, while the second applies it to the modified version. The third ensures that VBA code is not run when that object is accessed:
By utilizing these two properties, it is possible to contain a customization to only a particular group of users until testing is completed, and is ready to be deployed to a production system. If development is occurring within a production environment, configuring these two settings will ensure that other users are unaffected.
I was recently deploying a number of GP customizations in the model of Forms and Reports with VBA, when I encountered the following error during package importing:
I had never seen this error before but upon review of the customized form, I realized that my VBA code failed to import along with the form itself. All users had logged out of the current environment and the customizations had been tested successfully in a test system. I was stumped. One common IT phrase came to mind when deciding on the next troubleshooting step: “Have you tried turning it off and on again?”
Although I did not restart the terminal server, I took to a similar strategy: I wiped all customizations and started clean. This step has worked in the past when users were navigating through customized GP windows, where the application would suddenly crash without warning. The following entry was logged in EventViewer on the server:
Any time you experience strange application crashes, or error messages when importing custom VBA packages, chances are there are corrupt dictionaries and VBA files sitting in your Dynamics GP program folders. The following are a number of steps to resolve most of these issues in a short period of time:
1) Export all custom packages from the instance of GP that you are experiencing said errors. If you imported a package and received an error, ensure that you do not include the half-imported customization within your exportation (you will be importing the necessary package separately).
2) Backup all DIC and VBA files (only VBA files greater than 4kb in size, meaning they are being used) located in the C:\Program Files(x86)\Microsoft Dynamics\GP2013, and GP2013\Data folders, respectively (this example uses the 2013 version of GP, however the GP2010 version would have a similar file path, and also assumes you are using a 64-bit system, otherwise the path would commence with ‘Program Files’).
3) Delete all the backed-up DIC and VBA files from the program folders.
4) Log into GP with a POWERUSER login and open the ‘Customization Maintenance’ window. You should see a blank list. First, import the package with which you were previously experiencing an issue, and then continue with the exported package from your working environment. Verify that all required custom forms and reports are set in the “Alternate Modified Forms/Reports” menu, and that the annoying '()' brackets are removed from the end of any VBA global modules.
5) Test all the customized items to ensure that the system is functioning as needed.
With everything backed up, there is no risk when running through these steps if you are puzzled by strange VBA issues.
Sometimes, you just need a fresh start.