Project Accounting: Misc Log eConnect import issue

My last post about the good and the ugly of the Update Budget Lines feature had a continuing theme to it. I was telling the story of the client who mass updated 650+ projects with a new cost category only to find the budget sources set to Specific didn’t get populated with the default “specific” GL account.

What I didn’t get into was HOW they found the problem. I built some integrations for them for Misc Logs, which they’ve been using for a while now and having no issues with.  It’s been a huge timesaver for them, and they love it.  Great!  So, fast forward to how they found out they had an issue was during the Misc Log import and posting.  The problem was, eConnect didn’t fail and alert them of the problem with the missing accounts, it allowed the creation of the transaction without GL distributions and they posted it without thinking to check! Uh oh x2!

This article is explaining the issue, another possible bug, in Project Accounting Misc Log Entry eConnect node (not a problem with Misc Logs themselves). (more…)

By | 2017-08-13T11:46:29+00:00 June 8th, 2012|General Stuff, Project Accounting, Troubleshooting|0 Comments

Project Accounting: Update Budget Lines – the good and the ugly

The other day a client asked me if there was a way to mass-add a new cost category to all projects at once.  I actually didn’t know there was a new function to do this starting with GP10, but a quick google search resulted in a post from Mark Polino describing this exact thing.

Wow.  That doesn’t happen every day… I was thinking of the alternatives I would explain the client, but was really happy to see this added functionality.

Until… today, after the client used the new window, and rolled down a new cost category to every project they have, they found a problem. Uh oh!

This particular article relates to the Project Accounting module in Dynamics GP, and the Update Budget Lines window under the Routines menu. (more…)

By | 2017-08-13T11:46:29+00:00 June 6th, 2012|General Stuff, Project Accounting, Troubleshooting|0 Comments

Some Canadian Payroll & Project Accounting gotchas!

Recently, a client of mine experienced a couple of weird things when we started to configure another Dynamics GP company for them with Canadian Payroll and Project Accounting in action.  One of them is definitely something to look out for if you use the Canadian Payroll import processes; the second is more of a head-scratcher type of error where you don’t know what the real problem is.

I call these things “gotchas” – I’m not sure that translates into all languages but generally means to me at least, something that “GOT” me, that I wasn’t expecting or didn’t think to look out for. (more…)

By | 2017-08-13T11:46:30+00:00 February 16th, 2012|Canadian Payroll, Project Accounting, Troubleshooting|0 Comments

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:

Pic_EEVendorCard

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).

Pic_EECard

Pic_EEProjectSettings

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).