This post is about an issue that I found when testing the ROE (Record of Employment) functionality for a client in Dynamics GP. (Since “ROE” is a generic term, this post is specifically about a bug in the Dynamics GP Canadian Payroll module). I opened a case for it and it was quickly confirmed and written up as a quality issue (#91928 in case you need to add yourself or your customer to the list of affected clients).
What’s the issue?
The TL;DR version: Box 15B does not generate the correct value when using the ROE Creation window for weekly payroll. As far as I know this is specific to weekly payroll though I have not tested with other pay frequencies!
** Important to note ** this is only an issue if you print the report to give to an employee because that’s where 15B is printed. If you record ROEs strictly to generate the XML file for uploading to the CRA site, there is no issue, as 15B is not a field in the XML file.
The longer version is this:
- Box 15B is “Total Insurable Earnings”. For weekly payroll this should be the sum of the last 27 weeks of insurable earnings.
- Box 15C is the “by week” last 53 weeks of insurable earnings. For weekly payroll this should show up to the last 53 weeks.
The disconnect is the issue is only present with one method of generating the ROE in Dynamics GP. Specifically, when you use ROE Creation to create the ROE, box 15B is incorrect, but using Mass ROE creates it properly. Go figure.
ROE Creation method
The ROE Creation window is the one-at-a-time ROE method. I would have assumed most clients use this for one-off ROEs, and I was testing the functionality with it and recognized that the value was wrong. That was really strange to me, Canadian Payroll has been around for years, how can there possibly be a bug no one has yet found?
(Don’t @ me on this… I know there are issues that people have found over the years in various modules that will never be fixed. My point is it’s unusual to find “new” issues at this point in this product’s lifecycle!).
Here’s the result of doing an ROE for a weekly payroll employee. For simplicity with the math, their weekly insurable earnings were $1,000. The amount in box 15B should be $27,000 (27 periods x $1,000).
PS: This is fake data from Fabrikam, nothing in here is from a real employee or client!
Mass ROE method
The Mass ROE window is for, you guessed it, mass-creation of ROEs. In my client’s case, it didn’t even occur to me to test this since “mass layoffs” aren’t a thing there. However, you can easily use the Mass ROE window and only process 1 person’s ROE, it just seems like the long way to do it, hence I never tried it.
I posted the case to Microsoft Support and Cheryl W. very quickly tested and confirmed my findings, but since it hadn’t been reported yet, she tested Mass ROE as she, too, wondered how it was possible that no one had reported this yet. That’s when she realized Mass ROE works. She knows there are users using the ROE functionality so her only guess is they don’t use ROE Creation to do it. ¯\_(ツ)_/¯
Here is the result from Mass ROE, with the same employee:
Another workaround for this is if you need to edit the ROE at all in the ROE Creation window, you could modify the ROE Prep Report to not show the amount in the 15B box. It’s not the *best* option in the world, but it’s an option. Anything requiring that amount would be cross-checked and calculated anyway.
Another thought is this: in working with a client on this issue, they walked me through the process of uploading the XML file to CRA so I could see that side of the process. Not having employees myself, I haven’t had to actually do that part before. As part of the process, they do have the option to pull a PDF of the ROEs generated in the file so if someone needs a report in paper form, the option would be to upload the XML then print the ROEs as needed from the PDF from the CRA site.
At this time, this issue will not be fixed as it clearly does not affect enough people to warrant the development of a fix. Something similar was reported for monthly payroll a few years ago, but they deemed that also too infrequent a scenario to fix. It’s unclear if that and this are the same issue. Overall they have had something like 5 customers log cases about the monthly issue, too few to put development hours into it.
The Mass ROE method is considered a valid workaround to the issue and thus the quality report will stay unresolved!
Reminder: this does not affect the XML file for the ROE at all since 15B is a calculation by CRA and that field isn’t even in the XML file itself. It’s purely the table value problem which means the underlying report is incorrect.