Since the introduction of the web client in Microsoft Dynamics GP 2013, I have tried to minimise the use of VBA as it is not supported by the web client. However, some clients don’t intend to use the web client and prefer to have a quick customisation to a window done using VBA rather than full development in Dexterity.
As such, I do still sometimes get work with Modifier and VBA. I recently did a change to a client where I added several fields to VBA on the Sales Transaction Entry window.
A little later I needed to add a new checkbox and add it to VBA. I customised the window in Modifier to add the field, but when I tried adding it to VBA I received an error I had not seen before:
Microsoft Dynamics GP
You are manipulating a modified window whose EventMode is set to EmOriginalOnly. You must change this window's EventMode to emModifiedOnly before you can add this field.
I was working onsite with a client during an upgrade of Microsoft Dynamics GP from version 10 to 2013 recently, and after doing some work on a client we started receiving an error when trying to log out..
The error we received was the following:
After a little testing to see if we could easily determine the problem, I did a quick online search and came up with this post from Vaidy Mohan which was the same error, but for a different VBA project.
The steps I tried and found to be successful were slightly shorter and easier than those Vaidy needed:
- Launch GP and open the Visual Basic Editor
- Opened modified report in the Microsoft Dynamics GP VBA project
- Added and removed a space from the end of one line
- Compiled the entire project to check for errors
- Save VBA project
- Log off from GP
To verify the problem was resolved we closed and reopened Dynamics GP and didn’t see the error when closing it again.
I had a colleague (actually the First Minion, Erebus) using Modifier with VBA to create a customisation of the Account Maintenance window ( ) in Dynamics GP 2013 R2 (for a client who does not and will not be using the web client). This customisation required a small number of fields and the save button to be added to VBA.
When he was adding the fields everything was fine, but as soon as he tried to add the save button the cursor changed to a standard one and did not allow the save button to be added. Microsoft Dynamics GP 2013 R2 saw the introduction of the action pane (or ribbon bar as I keep on calling it):
While VBA is falling out of favour with Microsoft Dynamics GP (by dint of not being supported in the web client) it is still useful for those clients who do not use, and have no intention of using, the web client.
One such client was recently installing some new XenAPp servers using Windows Server 2012; when they tried to open a window with a VBA customisation they received the following error:
I have received a copy of the newly published Microsoft Dynamics GP 2013 Reporting, by David Duncan and Chrisopher J Liley, from Packt Publishing to review. This is an update of a previous book the pair wrote for Microsoft Dynamics GP 2010:
The book covers an extensive range of the reporting tools in, or available with, Microsoft Dynamics GP 2013:
- SmartList Builder including Excel Report Builder
- Report Writer and Word Templates
- Reporting Services Reports
- Analysis Cubes
- Management Reporter
I realise that the use of VBA in modifications and customisations is something that needs to be carefully considered with Microsoft Dynamics GP 2013 including a Silverlight based Web Client which cannot use VBA. I had a requirement from a client for a modification to the Debtor Enquiry (Customer Inquiry to the Americans reading) to include the sum of the displayed transactions on the window and as this was a small client with GP installed locally on each PC there is no requirement for the web client, I felt able to perform this change using Modifier using some VBA.
I added the required fields to the VBA project but encountered an error message when writing the VBA code to concatenate the fields into the SQL statement I was going to use to get the data;
At the end of December, Developing Microsoft Dynamics GP Business Applications, written by Leslie Vail and published by Packt Publishing was released.
I got a copy of the book in order to do a review and have decided to break the review down into multiple parts. The reason for this is that the book includes some practical examples which I have decided to do and then include the results of this in the review; after all if it is a book on developing how can you accurately review the book if you don’t use what you learn to build something?
The book is aimed at developers new to working with Microsoft Dynamics GP, so bear in mind that I am not a developer when reading my reviews. Quick synopsis of my background: I started my career as a trainee developer and moved through a variety of roles such as developer and support analyst before moving to my current position as consultant and project manager.
I oversee development teams working on additions or amendments to Microsoft Dynamics GP as well as personally undertaking some modifications using Report Writer or Modifier with VBA. So despite not being a developer, I am used to working with them and did, once upon a time, be one myself.
The first chapter of the book covers the Microsoft Dynamics GP Architecture from a high level perspective.
It covers the history of the GP interface from it’s origins with Great Plains Software, an overview of Dexterity and the development environment. There is a detailed explanation of the launch file (Dynamics.set), which included a couple of points of which I wasn’t aware, and the configuration/preferences file (Dex.ini).
The explanation of the Dex.ini file included the ExportOneLineBody switch which I didn’t know about, but for which I have an immediate use.
Leslie then goes on to explain about the structure of the tables in the SQL Database which always strikes newcomers as arcane and overly complex. Leslie explains this well with plenty of detail on both the structure, including both the physical and technical names, and how transactions move between tables as their state changes.
Chapter 1 wraps up with a detailed explanation of the UI covering how forms are constructed, how the scrolling windows work and the common buttons used on forms, scrolling windows and individual buttons.
The second chapter of the book focuses on the fundamentals of integrating applications with Microsoft Dynamics GP.
This book will teach you how to create and customize Dynamics GP Applications by taking you through the initial steps of setting up a development environment through to customising and developing an example application using tools such as Dexterity, Visual Studio Tools and sanScript starting with an overview of Microsoft Dynamics GP architecture.
Fred Webb posted a question on the Dynamics GP Community Forum asking if it was possible to prevent the User Date being changed in Dynamics GP 2010.
One response was to use Field Level Security which would work but seems a little excessive. I had a think on alternatives and, because we’re dealing with GP 2010, the one I came up with was to prevent the User Date window being opened by using a little VBA.
The package for Microsoft Dynamics GP 2010, which also works for Microsoft Dynamics GP 2013, can be downloaded at the bottom of the post.
The VBA I used was:
Private Sub Window_BeforeActivate()
Private Sub Window_BeforeOpen(OpenVisible As Boolean)
Me.Hide causes the UserDate window to be hidden from the user as it starts to open, and Me.Close forces it to close.
I could have put both the Me.Close and Me.Hide in the sub Window_BeforeOpen, but I found the main GP window didn’t get focus back. By splitting the Me.Close into Window_BeforeActivate focus was returned to GP when the UserDate window was closed.
The downside of using VBA asa solution is that it will not work with the Microsoft Dynamics GP 2013 Web Client, although it will work with the standard 2013 client.
In July, as part of his weekly MS Connect suggestion series, Mark Polino raised the issue of SmartList Favourites and the default Visible To which is set to System.
Mark’s suggestion was to have the default changed to User which would leave a generally tidier list. To be honest I’d rather have a setting which allowed the default to be chosen by each client. The reason for this is we’re currently in the middle of an upgrade project where a few Microsoft Dynamics GP systems will be merged into one and it would be good to have the default Visib le to set to Company.
Following on from my recent post on a fixed width SmartList left pane I decided to have a fiddle and see if I could force the default to something else. And it turns out with some simple VBA that you can do exactly that;