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.
Batch errors that don’t tell you anything
I love this one: “Batch level errors exist” type of error when posting a project accounting Timesheet transaction batch. Most times the batches will tell you what the exact error is. However, in this case the client was getting a mysterious error but only when posting the batch. If they printed the edit list, there were no errors.
The end result: the error was a Canadian Payroll issue. When you post a Timesheet batch with integration to Payroll (Canadian Payroll at least), you select the batch in Payroll to post the timesheets into. In this case, the payroll batch had mistakenly been set up with a different Pay Period Type compared to what the employees are set up as. I.E. the employees were set up as being paid 52/53 pay periods, and the batch was set up as 26/27 pay periods. The pay periods didn’t match, therefore the timesheets didn’t post. Since it was not a Project Accounting issue, all it knew to tell the client was “batch level errors exist”!
So if you run into something like this, do a quick check on the payroll batch setup as well as the employees (randomly check some of the employees in your batch for what they are set up for).
Canadian Payroll import does not appear to populate Project Accounting tables
This one was strange. I don’t recall us having this issue originally at the client during our initial configuration. That was years ago and I may have forgotten that we fixed something at that time. Anyway, this time, we were creating a new company and configuring everything, naturally using the CanPay import utilities to import our employees and paycode information. Normally that is very easy – the spreadsheets and format is a little time consuming to get right, but it’s quick and generally works fine. However, in this case, it did not populate the PA Employee Options table (PA00601), and even more importantly, it left the Employed By field empty. Normally this field defaults to “Company”. This was in GP2010 R2 – I haven’t pursued it any further to see if this applies to other versions.
When the field is anything other than Employed By Company, the timesheets you enter in Project Accounting do not post to Payroll! So when they initially went to test their payroll configuration, they created some timesheets and posted them only to find a handful of employees only made it through to the Canadian Payroll side in Quick Transaction Entry. When they noticed that the people that made it to payroll were relatively new employees, we then looked at the tables and sure enough, the employees that were missing were from the original import and the Employed By field was blank. We changed it to Company and all was good again.
I see too many clients NOT go through thorough testing, especially when they are used to the system and perhaps adding some new module or configuration, or in this case, creating a new company. Had my client not tested this thoroughly, they would have been surprised on “day 1” to find a bunch of issues. The first issue has nothing to do with testing of course but the second one is a good reminder that nothing replaces proper testing. The first glance at employee records looked fine and they were focussing on the day to day stuff – did the rates and paycodes come in ok, etc. The smaller stuff like Project Options seem so trivial in comparison that they get overlooked, until you run a payroll and test it all the way through the cycle.