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 it 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 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 one 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 creating a vendor manually, there are a couple of fields that users would complete information on, and this triggers other fields to be filled in automatically. 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 a site uses Project Accounting, and lets it create vendors for the 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 the user. 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
For those not 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 a user saves the employee card, a vendor is created, using the Employee ID as Vendor ID, and Address ID from the card. The screenshots 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
The short-term 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, filling 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 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).
