(Updated Feb 2013)
There was an issue identified last week with the 2012 year end tax update that affects T4s. This issue is being worked on and a hotfix should be available soon. (more…)
Welcome to my annual “hey the tax tables are out” blog post! Like clockwork – or like death and taxes – yet another certainty is each year end there are tax table updates to apply! Here are the details for those Canadian Payroll users of Microsoft Dynamics GP! Special note to you GP2013 users as well…
First – an important note although I doubt this will affect anyone already: Dynamics GP 2013 RTM did not release with the 2013 tax rates! So in the unlikely event that you are considering upgrading to GP2013 immediately (since it’s launch yesterday!), I would recommend holding off until the first hot fix is released. The hotfix is expected the week of January 21, 2013. New clients – same goes for you… the RTM build has the 2012 tax rates and thus any payrolls run in it, will not reflect the new tax rates yet. (more…)
I was asked this question from someone a few days ago and I have a little bit of information about this. At some point I will expand on this article but for now, it’s a short one!
This article is simply about using Cdn Payroll and US Payroll together, as in “can you use them together”?
The short version is the supported method is not to have both in the same environment, i.e. same SQL instance. There is a KB article that spells out all of the “how to”, and describes two installs, two instances, one US English, one Canadian. That KB article is here. (more…)
… Otherwise known as OMG it’s already July???? I talked to two clients today and yesterday about this and both of them forgot too… so apparently I’m not the only one not paying attention to time these days!
Yes, I, too, fell into the trap this year of letting time merrily fly by without realizing I didn’t blog about the Cdn Payroll tax updates for mid year.
So, now to the not-so-new-news! Yes there is mid-year 2012 tax update as there is every year, and this year the provinces affected are: Ontario and Nova Scotia.
There is only one bug fix in this update which is for Quebec employees, QPIP exceeding the maximum limit based on rounding in certain situations. I don’t know much about that one, that’s just what’s in the notification email I got when the update was published. (more…)
This is a repeat of an article I wrote in November 2011 with updated information.
Issue #2 in that blog was regarding permissions during the Generate Cheques routine and the message “There is an error in the Transmission Header – Incorrect Length”.
At that time, the fix seemed pretty obvious and it worked during testing on Windows 7 machines. I wrote about it, forgot about it, and moved on. Months later I learned the client doesn’t use Windows 7 on the machines that they use payroll for (those machines happen to be older Windows XP machines) so the error never came up again and I had completely forgotten about it. (more…)
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…)
The folks in Fargo are thrilled to say they have no snow yet as of today – December 21, 2011. And even better news! The Canadian Payroll 2011 year end updates are out! Wheeee… let the fun begin!
Reminder for those of you (hopefully none of you) who are running GP9 or earlier – there are no tax updates for your version anymore… hopefully you're in the midst of an upgrade to GP10 or GP2010.
On to the real content now… here are the details for the tax updates.
Versions after install:
Versions after install:
No table changes! Woohoo!
There are the usual tax rate changes for 2012 and a handful of changes specifically relating to year end:
Here is some information on the Volunteer Firefighters pieces. It would require table changes and they HAVE NOT made the necessary table changes to accomodate this. (I won't say “yet” because there is no plan at the moment to make the table change – clearly that means there aren't enough customers affected to push this through development).
The workaround if you need these features (tax credit and exempt amount)
Hopefully this is an uneventful year… the last few years we've dealt with table changes of varying degrees!
Third time’s the charm… 🙂 Gotta love computers, I’ve written this twice already and lost it completely, the draft didn’t even save. Argh!
Today I have 2 issues to write about relating specifically to Canadian Payroll in Dynamics GP; things that a couple of my clients have recently run into that are fairly common and easy fixes.
Issue #1 is regarding stuck batches and the message “The batch is currently in use – Please wait until the other user is finished”.
Issue #2 is regarding permissions during the Generate Cheques routine and the message “There is an error in the Transmission Header – Incorrect Length”.
This first issue is incredibly easy to resolve yet one of those things that consultants are not looking for something this simple; the solution is different than for nearly every other module which requires a SQL script to be run.
The issue is trying to do something to a batch in Canadian Payroll and receiving the following message: “The batch is currently in use – Please wait until the other user is finished”.
The solution is to open the Payroll Batch Setup window, select your batch and click the Reset Button. This resets the batch’s status from In Process to Available, freeing it up for the user to proceed with it. When you click Reset, you will get a message to confirm that says something like “are you sure you want to perform a general cleanup of the batch file?” and the answer is Yes.
This second error, which occurs during the Generate Cheques process, is permissions related. Of course you wouldn’t know that by the error message though! We really should help those developers with improving the text on error messages some day!
The error is: “There is an error in the Transmission Header – Incorrect Length”. Meaningful isn’t it? Well, when this first happened, it was with a client who had just upgraded from GP9 to GP2010 and this was on processing their first payroll. They didn’t get the error during their test upgrade so it was a little surprising.
The solution ended up being that the user – now that GP2010 was installed on her own workstation with her normal permissions – didn’t have “write” permissions on the application directory (C:\Program Files\Microsoft Dynamics\GP2010). During the Generate Cheques routine, for most Canadian Payroll users, there are two files being generated – a direct deposit file which you sent to the bank, and a Canada Savings Bond file which you send to the bank or manually transmit in other ways.
Years ago, both files defaulted to the application directory without giving the user the option where to save it; nor was there an option to configure a default location like most other file-based things in other modules. After many complaints and suggestions, Microsoft finally fixed the issue on the Direct Deposit file, which now prompts the user for a location to save the output file. Unfortunately they didn’t do the same for the CSB file and it continues to default to the application directory.
At this client, they switched to Windows 7 with the upgrade so the workstations were using default User Account Control settings. A simple switch to give the users permission to create a file in that directory solved the problem.
Hopefully this helps someone out there when they get one or more of these error messages!
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.
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 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:
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.
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).
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).
A client of mine had a great question for me last week on the ROE (Record of Employment) form that I couldn’t answer off the top of my head. I took the opportunity to research and test to answer the question and figured it is not an uncommon question, so I may as well share the info.
Before I begin, I am not a payroll guru, I simply understand how the payroll modules work in Dynamics GP. This is not meant to be a “how to complete your ROE” form article. I worked for a few years with an actual payroll guru, who in her own words, could make Canadian Payroll sing! (RW, you know who you are!)
Why is the insurable earnings listed in the pay period boxes (section 15C) not the same as the Total Insurable Earnings in box 15C? And why does 15C not tie in to the T4 insurable earnings on the employee card?
For the most part, the short answer is there are timing differences (ROE’s usually will span more than one calendar year and T4s are calendar year only). The interesting thing which I didn’t know is the specific rules around how 15A, 15B and 15C sections are calculated.
Full rules are available here in this PDF guide or if the link to the PDF file ever changes, this is Service Canada’s website and all of this information and much more is under the links to Employer information. My examples are based on a weekly pay period, which was this particular client’s pay cycle.
Box 15A Total Insurable Hours
Box 15B Total Insurable Earnings
Box 15C Insurable Earnings by Pay Periods
The example the client provided me with is for an employee on weekly payroll who started in early December 2010, and finished her employment in July 2011.
The ROE (partially shown):
The T4 window on the Canadian Payroll employee card (year to date T4 values, not the actual T4 creation window).
On the ROE, 15A shows total insurable hours of 1027.50 which is EI insurable hours from, in this case, the employee’s start date of Dec 8, 2010 to last date worked of July 24, 2011. Had she been working for a longer period, it would be the last 53 weeks of EI insurable hours.
Field 15B shows total insurable dollars of $12,948.68 yet box 24 on the T4 shows EI insurable earnings of $14,067.17 – why? Well, further to my explanation above, the T4 window is showing year to date (as in CALENDAR year to date – the basis for T4 records) so it is covering pay dates January 1, 2011 to July 24, 2011 (employee’s end date). Box 15B only is showing the last 27 pay periods for a weekly payroll, which means it is only showing earnings from approximately mid January 2011, not all 2011 pay dates.
Field 15C is the list of the last 53 pay periods, so the sum of those fields also does not match 15B, by design. 15C is in reverse order so to tie the numbers back together, you simply have to add the first 27 pay periods to get to the number in box 15B, and add in the remaining 2011 pay periods to match the T4 window value.
Only in select cases will the T4 window and the ROE every “align” – it would have to be for employees with short employment durations, like summer students perhaps, and within the same calendar year. In fact, this client does not have a lot of turnover and most of their ROEs are for summer students so in the past, nearly every ROE matched to the T4 window. They assumed it would always match and started “reconciling” using that window’s data, until this particular time when they didn’t align (and for good reason).
Hopefully that helps clear up a bit of confusion on the ROE forms for someone out there!