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;
After dealing with an obscure and unhelpful Integration Manager error recently, I’ve also had a Management Reporter one; when trying to generate a report the following error was consistently produced;
The part of the announcement which surprised me was the announcement that there would be a “Feature of the Day” starting in September; I thought that, usually, “Feature of the Day” only occurred for major releases and not service packs. Let me say though: this is not a complaint!
In SP2 the Web Client will see the see releases for the Project, Manufacturing and Field Service series as well as the expansion of ISV Extensibility to allow Visual Studio forms to be presented in the Web Client in the same way as Dexterity forms.
Document Attach will be extended to allow attachments to be included in emails and to allow documents attached to cards to be rolled down to the transactions. So a terms and conditions file attached to a customer record could be rolled down to the sales invoices and attached to the email.
One really nice feature is the ability in SmartList to hide the navigation tree; here’s hoping this is a button on the toolbar to quickly expand and shrink the nav pane.
For full details of the announcment check the original blog post.
Sometimes I find Integration Manager to be very trying. It can be a very useful tool but it can also be incredibly frustrating.
A client we have taken over support for logged a call about an integration they couldn’t run and hadn’t been able to run for a couple of months after their upgrade to Microsoft Dynamics GP 2010. The error message they were receiving was this;
As the title says, “you cannot print an unauthorized purchase order”. This is an error message which I encountered the other day on my demo system when I was trying to print a PO. Now, I’m largely not surprised to see errors occur on that VM and regularly either build a new one or, more often, redeploy the Fabrikam, Inc. sample company, but in this case I was a little surprised to see this message;
A client who upgraded to Microsoft Dynamics GP 2013 a few weeks ago began encountering a problem when switching between modules. In particular when they loaded the Purchasing area page they received the following message;
Fortunately, there are two solutions to this problem outlined in the Microsoft Support KB Article 2843273. The first is to upgrade to Microsoft Dynamics GP 2013 which at very short notice isn’t really an option, or to use the script in the KB article to both remove the corrupt entry in SY07140 and add a trigger to the table to prevent another corrupt entry being created.
As we needed the client up and running without the error quickly, we opted for the second approach and will look to schedule in the upgrade from 2013 RTM to SP1.
This is not a book I have written, but rather one that, like the Microsoft Dynamics CRM 2011 Applications (MB2-868) Certification Guide, I have done some technical reviewing on behalf of the publisher, Packt Publishing. This is basically assisting the publisher to verify that the content of the book is technically accurate and can be successfully followed. Well, while I was working on the Microsoft Dynamics GP 2013 Cookbook I was also doing technical reviewing of the Microsoft Dynamics CRM 2011 Cookbook by Dipankar Bhattacharya;
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.
Prior to the first copy, we used a script to load the users into SQL Server and then restored the databases and had no problems.
Later on, after changing some of the permissions to databases we had need to remigrate some of them over. However, we found that users could not access some databases and when we tried to add them we got the following error;
Msg 15023, Level 16, State 1, Line 1
User, group, or role 'pidev' already exists in the current database.
It was looking very like we would need to go through each database and remove access and then regrant it all; a labourious process. A quick Google found me a page from Julian Kuiters which introduced me to the ALTER USER command. The following code will run against the selected database and tie together the SQL Server user with the user in the database without any other work;
ALTER USER pidev WITH LOGIN = pidev
The first highlighted element needs to be changed to the database you want to update the user on and then the following two entries are the usernames which need to be linked (these should be set to the same value).
Update: if your usernames contain a space (e.g. I Grieve) then wrap them in square brackets: e.g.