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 recently assisted a client with an upgrade of Microsoft Dynamics GP 10 to GP 2013 R2. As part of the upgrade we assisted the client to create some Word Template versions of sales invoice, purchase order, and cheque remittance (or check remittance to the American readers).
Everything appeared fine during development and initial testing. Fine that is until we tried producing a batch of twenty remittances which produced the following two error messages:
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:
In Microsoft Dynamics GP 2010, Microsoft changed the underlying tables used by the Check Remittance; I believe this was for purposes of efficiency. However, the downside is that the table, pmRemittanceTemp, used to replace PM_Payment_WORK did not contain the vendor’s address or a link to a table which did.
In the past I have tended to use VBA to add the vendor’s address to the Check Remittance because it was quick and easy to do and I didn’t revisit this approach until Microsoft Dynamics GP 2013 was released. And the reason I revisited, was because of the new Web Client which does not support VBA customisations.
As always, I figured I might as well do a blog post about this and had it scheduled in to write when Richard Wheeler asked the question on the Community Forum. So, here is the step-by-step guide to adding the vendor address back onto the Check Remittance modified report.
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;
While importing a customised Form with VBA I encountered a problem and received a Component write exception;
The form itself had imported but the VBA element had not.
Not having seen this error before I hit up Bing and soon found a blog post from Dex Master David Musgrave where he discusses this exact issue on GP9 (I was loading a customisation from GP9 to GP 2010 to upgrade).
The answer was not quite what I wanted. I was hoping for something nice and simple, but instead I needed to export all the customisations, delete the forms.dic, reports.dic and dynamics.vba files and then reimport all of the customisations.
After I did this the import worked fine.
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.
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;