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.
Microsoft are posting the Microsoft Dynamics GP 2013 Feature of the Day series on the Inside Microsoft Dynamics GP Blog.
The fifty eighth feature they’ve announced is Reprint Payables Management Remittance.
Now, in Microsoft Dynamics GP 2013, you can reprint the vendor check stub or remittance form after you’ve processed the payment. You can see invoices that were paid, credits that were applied and other information that displays on the check stub or remittance.
Re-create Check Stub is available on the Payables Payments Zoom window;
This new feature is targeted at the following roles:
- Accounts Payable
- Certified Accountant
- Accounting Manager
In two previous posts I discussed testing Microsoft Dynamics GP 2010′s new Email Remittance functionality; first, by setting up creditors with an internal email address and, then, by transferring the email address from the INET1 field to the new EmailToAddress field.
The other script which I used, and forgot to post, was the one which configures all of the creditors, who are not currently configured for email remittances Continue reading
We heard back from the Development Team in Fargo, who David Musgrave contacted regarding the issue we encountered with the Microsoft ActiveX Data Objects 2.7 Library.
They recommend that packages should be moved around using the Customisation Maintenance (Microsoft Dynamics GP menu >> Tools >> Customise >> Customisation Maintenance) to Import/Export the modified reports. Rather than doing this, which runs the potential risk of leaving client machines with an outdated REPORTS.dic we have been pointing the clients at a centralised REPORTS.dic on a server and copying only the Dynamics.vba to each client (we change the reports more often than the VBA).
Using Customisation Maintenance to Import the package file to each client would have prevented the problem as it would use the Microsoft ActiveX Data Objects 2.7 Library reference on the local machine. Doing it the way we do, by copying the VBA, transfers the reference within the VBA file.
This is an issue for internal discussion and we perhaps need to change the process we use for dictionary files.
I implemented the VBA workaround for cheque remittances on a test system for another client site, to make sure they don’t see the undefined symbol error, the other day after I upgraded Microsoft Dynamics GP 10 to GP 2010 and tested the remittance to ensure it worked. amend VBA on Server 2008 R2 SP1
When the client came to test the remittance themselves on the test Citrix Server they got a type mismatch error;
A few days ago I posted about testing email remittances and supplied a SQL script for use on the test system to ensure emails remained internal and didn’t get sent to creditors.
I’ve also written a script which will transfer the email address from the current Internet Information column (with the assumption that the email address is in INET1) across to the new EmailToAddress column and then blank out the INET1 column so data is not being held, and therefore maintained, in two fields. Continue reading
As you’ve probably been able to tell from my previous posts, I’ve been assisting a client in configuring Microsoft Dynamics GP 2010 so they can test remittances by email.
One of the things I have done for them is produce two SQL scripts to ensure emails do not leave their organisation and reach suppliers telling them of payments being made in the test system. Continue reading
I upgraded a customer to Microsoft Dynamics GP 2010 a couple of weeks ago and they have started to explore some of the new features. After fixing their payment run problem they enabled the new functionality for emailing remittances. Continue reading
A recent customer who upgraded to Microsoft Dynamics GP 2010 wanted to enable the email functionality to allow them to email creditor remittances out rather than having to print them out and sending a hard copy.
As our support account did not have an associated Exchange email account on their system I was getting errors when loading the forms used in this new functionality. So rather than risk problems due to these errors, I put together a quick document for their IT department to enable it themselves. I thought it might also be useful to create an internet version to refer other customers to if they want documentation. Continue reading
Following on from yesterdays post about the Undefined Symbol error, where I discovered that Microsoft have removed the link from the check remittance tables to PM Creditor Master, I thought it might be useful to post the VBA workaround used to get the creditor address.
The first step was to create five Calculated Fields on the Check Remittance report; for simplicity I named them CreditorAddress1 through CreditorAddress5. No separate field for Post (Zip) Code was created as addresses can be of all different lengths and I like to output tidy addresses where I can.
Once the fields were created and added to the report, in the Remittance Header section, they were selected and made available to Visual Basic. Continue reading