Transaction Descriptions & POP to PM MS Connect Suggestion

Time for one of those obscure issue blogs, that won’t affect very many people, but the odd person might find this very useful to clarify what they are or are not seeing happen (and give me a couple of years, I’ll forget, and find my blog post!).

This story starts at a client, who requested that the Transaction Description prints on a cheque/EFT remittance. Sounds easy right? Well, the client found out at some point when first using GP that any descriptions in POP transactions they typed in were not updating PM tables, therefore no descriptions for the reviewers or vendors. So, they called their VAR for help.

Cue the VAR, who at some point early in their original implementation with Dynamics GP 2010, added an Extender window on the Invoice Match Entry window, for A/P Clerks to type in a transaction description, and a SQL trigger on the POP30300 table, to update the PM20000 table with that description after posting completes. Last year, during an upgrade to Dynamics GP 2013, I was new to this client and the issue came up during testing because (of course) the trigger wasn’t upgraded/replaces after the upgrade, no one knew it existed, and the descriptions stopped populating PM tables again.

When the client noticed the problem, I made a note to look into this in the future. First of all, they didn’t need an Extender window when there is an out of the box Reference field in all the POP transaction windows! Second of all, why should we be using a trigger on something so basic? It warranted looking into further to see why this was needed in the first place. (I understand the end goal of the description pushing down to payables but the smelled like something that should just occur out of the box, no trigger, no add-on windows…)


Bug month! Issues with Project Accounting employee vendors & EFT

It must be bug month for me, as I have another issue.  One is reported as a bug – kind of – and the other, reading between the lines, will not be considered a bug when all is said and done.

The Issue

There are 2 actual problems but both are caused by the same thing as it turns out.  The client told me initially about one issue which was when they started paying employee expenses (Project Accounting) via EFT, the EFT Payment Register didn’t show the employee “vendors” on the list (but the report total was correct).  A while later, while I was still troubleshooting this, they added that when they use the new email vendor remittance option, the employee vendors are not getting their remittance emails.

This case was odd, in that is didn’t affect all vendors, nor did it affect everything in EFT.  The EFT Payment Register is one of the posting journals that comes up, and it clearly was missing these employees’ payments.  The EFT file itself was fine, and generated a complete EFT payment file for all vendors in the batch, employee or not.  Additionally the Marked EFTs report, one of the reports available during EFT file generation, also showed everyone as you would expect.  So, it was a little odd to say the least.

The Cause

The short story is when the Remit To address is blank on the vendor card, this causes the EFT Payment Register to ignore it (except in the footer, where the totals were correct), and it uses that same field to find the vendor’s email address to email a vendor remittance form.

On to the best part, which is, what causes the Remit To address to be blank?  This is my bone of contention with Microsoft if they end up declaring this is not a bug to be fixed.  When you create a vendor manually, there are a couple of fields that you would complete information on, and this triggers other fields to be filled in auto-magically, as they say.  One is the Name field (auto-fills in Short Name and Cheque Name).  The other is the default Address ID field (auto-fills in Purchase, Remit To and Ship From addresses in the bottom left hand corner).  Guess what happens if you use Project Accounting, and let it create vendors for your employees automatically?  This is what the vendor card looks like, when PA creates it:


The highlighted areas are the fields that Project Accounting does not complete for you.  However, most clients I’ve seen don’t go to the vendor card to update these or other settings very often, or they merely update the Class ID to roll down some default settings.

How Project Accounting creates Vendors

If you are not too familiar with Project Accounting, here is the background to the story.  On the employee card, there is a place under the Project button to identify if an employee files employee expenses or not.  If this is enabled, when you save the employee card, a vendor is created, as above, using the Employee ID as Vendor ID, and Address ID from the card.  Screen shots below show the Employee Maintenance window (US Payroll), and the PA Employee Options window.  NOTE this PA options window is also available from the Canadian Payroll employee card, with a different name (same fields).



The Resolution

Short term the resolution was to update every employee’s vendor card to populate the fields that were blank in the Address ID section.  That was simple to correct the previous employees; however the next time a new employee is created, they may forget, and this will happen again.  Fortunately for the client, since they are using EFT for the vendors, they have to go to the vendor card anyway to add EFT payment information and the Email remittance address – so it’s not exactly a huge time-waster to fill in a couple of extra fields.

Long term, I am lobbying gently for Microsoft to fix this.  Project Accounting should create a vendor that looks exactly like a vendor keyed in manually – with the fields it is aware of.  That means, fill in all name fields, and all Address ID fields.

An even better suggestion would be to add new functionality to the Project setup.  It would be great to see “Default Vendor Class ID” for employee vendors, on one of the setup windows, and then the vendor, when created, would be populated with that default vendor class, and the corresponding settings.  Why have half-baked functionality?  It’s no use to customers to “kind of” create the vendor and then have to complete some basic steps.  I understand that EFT and other unique items require manual setup as they should, but Names, Address IDs and Class IDs could easily be incorporated to save clients some manual workaround effort.

I am smiling as I finish this post, because literally my client just emailed me this, word for word: “We just did an EFT (which included an employee) and it WORKS! YES!!”.  I love to solve problems, it’s a big part of my job, but I also love to find ways to improve the product and in this case, it’s minor but could be a great improvement!  (PS I will be putting in an enhancement request on Microsoft Connect for this one).

Adopting new GP2010 features

I'm behind on my blogging this week!  Usually my weekends are my writing time, but instead of writing blogs, I was doing my own month-end and billings for January.

One of the clients I sent an invoice to emailed me today via the new GP2010 EFT Remittance email functionality with my remittance advice for their January invoice.  

This client has been using GP's EFT for Payables for years but only with a handful of vendors each month, the majority of their payments were still via cheque.  They had been paying me via EFT but without any remittances or notifications so far.  They started asking me about EFT remittance/email functionality as they wanted to expand this to more vendors but needed to have a plan for the remittance advice.  

Last year, I had gathered information for them on a few of the leading third party add-ons out there.  However, once the beta of GP2010 was released and the new functionality was announced, I went back to the client and introduced the upcoming functionality to them.  I could have easily sold them some third-party software add-on that would allow emailing of EFT remittances, they would have proceeded and been off to the races.  However, being on GP9, with Canadian Payroll and a product lifecycle end in sight, I recommended they wait until they upgrade and evaluate the “free” functionality they would get before committing to a software purchase they may not ultimately require anymore.

So, last summer the “test” upgrade began and once the usual upgrade formalities were out of the way and the core project deliverables were met, I worked with them on testing the EFT functionality.  It turns out they were happy with the functionality it provided.  They did their own testing and documented the configuration they found worked best, to use in the live upgrade.  We discussed the how this would change the existing A/P process, to re-design their existing process to incorporate this change.

Late last year, I completed their upgrade from GP9 to GP2010.  After the year end tax updates were done and out of the way, based on the testing work we did during the sample upgrade, the client took their configuration notes, and set up the new functionality.  

Being a little bit patient allowed them to take advantage of a new GP2010 feature – without purchasing additional software, and with relatively minimal additional consulting cost.  

How cool is that?!

By | 2017-08-13T11:46:31+00:00 February 2nd, 2011|General Stuff, Payables Management, Process Redesign|2 Comments