This post is a bit of a “blast from the past” which I am posting as it seemed quite hard to find and you never know when I’ll need it again.
A client on Microsoft Dynamics GP 10 (we’re talking to them now about an upgrade to GP 2015) is in the process of setting up a new company and needs to be printing out a few of reports (SI, SR, PO and Remittance) with different logos for the new company.
If you’re a long new GP user you’re probably used to the Word Templates which have the logo supplied from the library in Template Configuration ( ) or by assigning different Word Templates to the different companies.
However, as longer time GP users are aware, the Word Templates were introduced in Dynamics GP 2010; before that all reports were produced using the modified reports created in Report Writer where it wasn’t really possible to have different logos.
That is, it wasn’t possible to have different logos in the same place. Way back in 2008 David Musgrave (while a Microsoftie) did a post on the Developing for Dynamics GP blog on how to have a conditional logo on the modified report by using a conditional field to show or hide logos.
It’s not really a solution that can be called elegant (hey it involves Report Writer!), but it was most certainly a useful one. So until this client gets their upgrade performed (hopefully first quarter 2015) I need to get their modified reports customised to hide the logo for their main company when producing documents and the exact steps had faded from memory somewhat.
So I needed to hunt out the old post I remembered David writing (I also remember using it back in 2008) and it actually took a little finding (found it through a question on the Community Forum).
A client on Dynamics GP 2010 R2 has been configuring email for the RM statements recently, but after configuring the system were still receiving an error message:
Path for the E-mail Status Report is Not Setup
When we were assisting to diagnose the problem, we found that while they did have the EmailStmtStatusPath line in their Dex.ini file (as detailed in this KB article), the specified path did not have a trailing slash; as soon as this was done the report started working without issue.
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.
We upgraded a client from Microsoft Dynamics GP 9 to Microsoft Dynamics GP 2010 recently, and the first time they tried to run the VAT 100 report they received a number of errors:
Microsoft Dynamics GP – An error occurred executing SQL statements.
A client reported an issue the other day with figures being incorrect in Management Reporter when compared to the equivalent report in FRx and also to the figures in Microsoft Dynamics GP (which matched FRx).
I think the original cause of this problem is that when the calendar for the current year was created, there was a gap accidentally left between the end of last year and the start of the current one. This was fixed and a reconciliation run in GP, but this did not allow the data to be trickled out into the Management Reporter Data Mart.
In an attempt to resolve the issue, I removed and re-added the Data Mart (deleting the DDM database between removing and re-adding) using the Management Reporter Configuration Console, waited for the initial extract and ended up with figures that were even more different to FRx; a slightly worrying moment I have to admit.
I checked the version and discovered the client was running Management Reporter 2012 RU4 which is known to have an issue populating the DDM database during the initial data extract. Fortunately, Microsoft Support KB 2831693 details how transactions posted from the open years in Dynamics GP are not included during the initial data load and links to the hotfix for RU4 which resolves this problem.
I again removed the Data Mart, deleted the database, installed the hotfix and added the Data Mart back and, after the initial data load completed, all of the data needed to make the report match both GP and FRx was present.
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;
Integration Manager – Object reference not set to an instance of an object
While importing a customised Form with VBA I encountered a problem and received a Component write exception;
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.
I was recently on site with a client doing an upgrade from Microsoft Dynamics GP 2010 to 2013 and implementing Management Reporter 2012 to replace FRx 6.7.
The upgrade of Dynamics GP to 2013 went through without issue, once I sorted out the overlapping periods which are no longer allowed (I hope Microsoft will be updating the exam question), but I ran into an issue with Management Reporter.
When I was entering the details for the SQL Server I got an error that the password provided was incorrect. I reentered it and got the same error and then entered it a third time very slowly and carefully. Again, it was rejected.
Now because I was onsite and therefore using a customer supplied password there was every possibility that I had entered it incorrectly. I verified the password with the customer and then copied and pasted it in from Notepad so that I was certain it was correct, but it was, again, rejected.
It was at this point a memory fired that someone had recently told me about this. I checked emails I’d received a few weeks ago and found the answer in one from Andrew Cooper, my former colleague. The problem is when Enforce password policy in Microsoft SQL Server is enabled for the user account.
This should not be a problem, but with Management Reporter 2012 RU4 it is because the password is verified against SQL Server as each letter is typed in order to populate the database selection box and if the password policy is being enforced then the user account gets locked out after the third letter. I haven’t had a change/remembered to test this against RU5.
After unlocking the user account via SQL Server Management Studio, I copied and pasted the password into the Management Reporter Configuration window and was able to progress with the installation.
He somehow slipped it out without me noticing, but David Musgrave of the Developing for Dynamics GP blog released Support Debugging Tool Build 17 before Christmas; this is the build which added support for Microsoft Dynamics GP 2013.
He was back yesterday with a hotfix release to fix a couple of issues.
Partners can download SDT from PartnerSource (login required); if you’re a customer you’ll need to contact your partner to obtain it for you.
David has links to SDT for Microsoft Dynamics GP 10 and 2010 here.
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.