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 something to look out for if using the Canadian Payroll import processes; the second is more of a head-scratcher type of error where a user doesn'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 us 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 users 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 result: the error was a Canadian Payroll issue. When posting a Timesheet batch with integration to Payroll (Canadian Payroll at least), users 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. 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 users 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 the batch for what they are set up for). The employee pay periods must match the batch they are in.
Canadian Payroll import does not appear to populate Project Accounting tables
This one was strange. I don't recall us having this issue originally with 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 are 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 GP 2010 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 users 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.
Lessons Learned
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, employee records looked fine and they were focusing 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 through the cycle.
