So great to get some fabulous news about upcoming enhancements to the Human Resources and Payroll modules in Dynamics GP 2013 from Terry Heley at Microsoft. On my list of things to be really excited about....
1. Including the deduction, benefit, and pay code modifier tools directly in the product! This is such a HUGE thing in terms of ease of use and end user satisfaction. So you will be able to change pay codes, deduction codes, and benefit codes using these tools. Very cool.
2. Another one that scores high in my book when it comes to end user satisfaction is the option to turn off the printing of alignments for checks and earnings statements. Yay! We are moving up in the world and past the age of dot matrix printers that needed alignment :)
3. All of the scripts I have saved over the years may not be needed any more, since we will also have the ability to edit pay history for FUTA, SUTA, and Workers Comp. So if pay codes are set up incorrectly, you will be able to fix previous payrolls through the interface itself rather than using scripts, or having to back out and re-enter transactions.
4. Enhancements for payroll extensions, too! We will be able to disable Deduction In Arrears reports from printing! And Payroll Integration to Payables can summarize federal taxes in to a single voucher, to minimize the number of entries in payables (I just had a client last week who was thrown off by the number of vouchers created by federal tax, so this is a timely announcement in my book).
.
Lots of quality report fixes too, including those in Benefit Self Service in Business Portal (we love those bug fixes!)
Also, just a reminder that a 2012 Year End Update will be provided for Dynamics GP 20.0 customers, as well as Round 1 tax tables for US for 2013. Then that will be the end of mainstream support (no more tax updates or code updates), although extended support will continue through 10/10/2017. As always, contact your Partner or Microsoft if you have specific questions about the product support lifecycle.
https://mbs.microsoft.com/customersource/support/selfsupport/hottopics/HOTTOPIC_MDGP10_SupportLifecycle
https://mbs.microsoft.com/partnersource/support/selfsupport/hottopics/HOTTOPIC_MDGP10_SupportLifecycle
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Showing posts with label payroll. Show all posts
Showing posts with label payroll. Show all posts
Saturday, March 31, 2012
Friday, November 18, 2011
My Favorite Payroll Support Articles
It seems like the vast majority of payroll issues are related to taxability, which in turn is related to the setup of the payroll module. So I thought I would share a couple of my favorite payroll support articles related to taxability.
How to correct overwithholding of payroll taxes
http://support.microsoft.com/kb/858712
I have used this article time and time again. It can be broken down in to three key steps:
http://support.microsoft.com/kb/862929
This article explains how both reports calculate, and the subtle differences between them. The key is that the 941 report uses the current tax status of deductions to recalculate taxable wages while the payroll summary relies on the taxable wages calculated at the time the payroll was posted.
To minimize tax issues in payroll in GP, you should (in my humble opinion)...
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
How to correct overwithholding of payroll taxes
http://support.microsoft.com/kb/858712
I have used this article time and time again. It can be broken down in to three key steps:
- Refund the overwithheld taxes
- Correct the tax summary information for total taxes and taxable wages
- Adjust the pay code used to pay back the taxes
http://support.microsoft.com/kb/862929
This article explains how both reports calculate, and the subtle differences between them. The key is that the 941 report uses the current tax status of deductions to recalculate taxable wages while the payroll summary relies on the taxable wages calculated at the time the payroll was posted.
To minimize tax issues in payroll in GP, you should (in my humble opinion)...
- Ensure that the payroll setup tax flags for pay codes, deductions, and benefits are set up correctly from the start (Setup-Payroll-Deduction, Benefit, Pay Code)
- Resist the urge to change tax flags at the individual employee level (Cards-Payroll-Pay Code, Deduction, Benefit)---simply because it becomes more complicated in terms of the variations in taxability that could exist for a single code
- Ensure that all pay codes that are marked as SUTA taxable also have a SUTA state specified (this is a required field when manually setting up a pay code, but the behavior can vary when rolling down pay code assignments)
- Ensure that a default state tax code is specified for the employee, this is DIFFERENT than setting the employee up for a state tax (Cards-Payroll-State Tax). You need to go to Cards-Payroll-Tax and make sure a default state tax code is specified for transaction entry.
- Print your 941 after every payroll when you first go live, and validate the results.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Thursday, October 27, 2011
TXSHANTY and Tax Sheltered Deductions
Whew! Back from vacation and a whirlwind week before and after!
I have been battling a bit of an odd issue for a client regarding FUTA and SUTA taxable wages. Let me start by giving you some background:
1. Deduction configured as non-TSA, no tax sheltered boxes marked (Setup-Payroll-Deduction, Cards-Payroll-Deduction)
2. Activity posted using the deduction code
3. Deduction setup changed to now be TSA, with three of the tax sheltered boxes marked (Setup-Payroll-Deduction) and change to set up rolled down
4. Deduction maintenance not updated with new tax sheltered settings, as their was already activity on the code (Cards-Payroll-Deduction)
So, the bottom line is that the employee deduction maintenance (Cards-Payroll-Deduction) showed no tax sheltered checkboxes marked but the setup did (Setup-Payroll-Deduction). Normally, this would not be a problem. New employees would get the new settings while older employees would not. But then the weirdness began :)
When printing the FUTA and SUTA summary reports, it was noticed that the wages were off by the amount of these deductions. Both FUTA and SUTA were set up (Setup-Payroll-Unemployment Tax) to NOT include any TSA deductions as wages. But, in this case, the deduction in question was NOT sheltered. So it should NOT have been excluded from wages.
If we changed the FUTA and SUTA setup to include the deduction as wages, it fixed the employees who did NOT have tax sheltered flags marked. But it created another problem, since it also now included the deduction as wages for employees who DID have the tax shelted flags marked. Eek. Fun.
So why was it sheltered the deductions that were NOT marked as tax sheltered? All 'cuz of TXSHANTY. Many thanks to Michelle Blaser at Microsoft, who asked the question and had us check this setting. In the UPR00500 field there is a field called TXSHANTY. This is a boolean field, with a zero if NONE of the tax sheltered checkboxes are marked (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) or a 1 id any of the tax sheltered checkboxes are marked.
In the case of these employees that had deductions that were NOT marked as tax sheltered, the TXSHANTY setting was 1 although the tax sheltered checkboxes were all zeroes (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX). How could this happen?
Well, with a little testing with Microsoft we found that the rolldown from the setup did not rolldown the tax sheltered checkboxes (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) because there was activity but it was still updating the TXSHANTY field behind the scenes. The interesting part of this is that there is not logical situation where TXSHANTY would be 1 while all of the other checkboxes are zero.
So we used the following scripts to identify and correct the affected records:
--Run select statement to verify number of records to be affected
select * from UPR00500 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Run update statement to set Tax Sheltered Annuity field to 0 where are all Tax sheltered tax fields are 0
update UPR00500 set TXSHANTY=0 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Verify number of affected rows against select statement rows
Once we did this, FUTA and SUTA now calculate correctly per the settings in GP. On an interesting side note, we also found that something in GP might be resetting the TXSHANTY to zero, although we could not figure out what-- we just noticed that over time (with no as zero. Odd.
Microsoft is working on writing this up as a quality report, but I thought I would share it with you all in case you run across the same oddity!
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
I have been battling a bit of an odd issue for a client regarding FUTA and SUTA taxable wages. Let me start by giving you some background:
1. Deduction configured as non-TSA, no tax sheltered boxes marked (Setup-Payroll-Deduction, Cards-Payroll-Deduction)
2. Activity posted using the deduction code
3. Deduction setup changed to now be TSA, with three of the tax sheltered boxes marked (Setup-Payroll-Deduction) and change to set up rolled down
4. Deduction maintenance not updated with new tax sheltered settings, as their was already activity on the code (Cards-Payroll-Deduction)
So, the bottom line is that the employee deduction maintenance (Cards-Payroll-Deduction) showed no tax sheltered checkboxes marked but the setup did (Setup-Payroll-Deduction). Normally, this would not be a problem. New employees would get the new settings while older employees would not. But then the weirdness began :)
When printing the FUTA and SUTA summary reports, it was noticed that the wages were off by the amount of these deductions. Both FUTA and SUTA were set up (Setup-Payroll-Unemployment Tax) to NOT include any TSA deductions as wages. But, in this case, the deduction in question was NOT sheltered. So it should NOT have been excluded from wages.
If we changed the FUTA and SUTA setup to include the deduction as wages, it fixed the employees who did NOT have tax sheltered flags marked. But it created another problem, since it also now included the deduction as wages for employees who DID have the tax shelted flags marked. Eek. Fun.
So why was it sheltered the deductions that were NOT marked as tax sheltered? All 'cuz of TXSHANTY. Many thanks to Michelle Blaser at Microsoft, who asked the question and had us check this setting. In the UPR00500 field there is a field called TXSHANTY. This is a boolean field, with a zero if NONE of the tax sheltered checkboxes are marked (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) or a 1 id any of the tax sheltered checkboxes are marked.
In the case of these employees that had deductions that were NOT marked as tax sheltered, the TXSHANTY setting was 1 although the tax sheltered checkboxes were all zeroes (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX). How could this happen?
Well, with a little testing with Microsoft we found that the rolldown from the setup did not rolldown the tax sheltered checkboxes (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) because there was activity but it was still updating the TXSHANTY field behind the scenes. The interesting part of this is that there is not logical situation where TXSHANTY would be 1 while all of the other checkboxes are zero.
So we used the following scripts to identify and correct the affected records:
--Run select statement to verify number of records to be affected
select * from UPR00500 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Run update statement to set Tax Sheltered Annuity field to 0 where are all Tax sheltered tax fields are 0
update UPR00500 set TXSHANTY=0 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Verify number of affected rows against select statement rows
Once we did this, FUTA and SUTA now calculate correctly per the settings in GP. On an interesting side note, we also found that something in GP might be resetting the TXSHANTY to zero, although we could not figure out what-- we just noticed that over time (with no as zero. Odd.
Microsoft is working on writing this up as a quality report, but I thought I would share it with you all in case you run across the same oddity!
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Wednesday, September 28, 2011
Adding Employer Tax Fields To Payroll Check Register
We had an issue pop up this month that was a bit puzzling on the surface. When a client printed the payroll Check Register when the payroll posted, they were getting different results than when they reprinted the same report using Reports-Payroll-Reprint Journals-Check Register.
On the standard Check Register and Reprint Check Register reports, the Employer FICA taxes are totaled in to one field called Employer FICA Owed. However, on the client's reports, this amount was also broken out in to two additional fields for Employer FICA/Social Security and Employer FICA/Medicare. Given that these fields are not standard on the report, we knew (and confirmed through Microsoft Dynamics GP-Tools-Customize-Customization Maintenance) that the reports were modified.
In looking at these modified versions of the reports, we noticed that all of the fields matched with the exception of the Employer FICA/Social Security and Employer FICA/Medicare fields that were added to the reports. But, why would the fields be different? If the same fields were added to the reports? Well, that is the big IF.
So, I opened each report in Report Writer, and here is what I found. There are a total of four fields that store Employer FICA information, two for Social Security and two for Medicare. When working with the Reprint Check Register report, the fields are located in the Payroll Check History table (for the Check Register report, the table is Payroll Work Header): Employer FICA/Med Tax On Tips, Employer FICA/Medicare Withholding, Employer FICA/SS Tax On Tips, and Employer FICA/Social Security Withholding.
In the client's case, one report was modified to pull only the "withholding" fields while the other report was modified with calculated fields to combine the "withholding" field with the corresponding "tax on tips" field (e.g., Employer FICA/Medicare Withholding + Employer FICA/Med Tax On Tips). And because the client had employees with tips, the amount displayed for each of the FICA fields was off by the FICA on tips.
So, lesson learned, if you want to add the Employer FICA/Medicare and Employer FICA/Social Security to the payroll check register reports, make sure you either display all four fields or create calculated fields to summarize them appropriately.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
On the standard Check Register and Reprint Check Register reports, the Employer FICA taxes are totaled in to one field called Employer FICA Owed. However, on the client's reports, this amount was also broken out in to two additional fields for Employer FICA/Social Security and Employer FICA/Medicare. Given that these fields are not standard on the report, we knew (and confirmed through Microsoft Dynamics GP-Tools-Customize-Customization Maintenance) that the reports were modified.
In looking at these modified versions of the reports, we noticed that all of the fields matched with the exception of the Employer FICA/Social Security and Employer FICA/Medicare fields that were added to the reports. But, why would the fields be different? If the same fields were added to the reports? Well, that is the big IF.
So, I opened each report in Report Writer, and here is what I found. There are a total of four fields that store Employer FICA information, two for Social Security and two for Medicare. When working with the Reprint Check Register report, the fields are located in the Payroll Check History table (for the Check Register report, the table is Payroll Work Header): Employer FICA/Med Tax On Tips, Employer FICA/Medicare Withholding, Employer FICA/SS Tax On Tips, and Employer FICA/Social Security Withholding.
In the client's case, one report was modified to pull only the "withholding" fields while the other report was modified with calculated fields to combine the "withholding" field with the corresponding "tax on tips" field (e.g., Employer FICA/Medicare Withholding + Employer FICA/Med Tax On Tips). And because the client had employees with tips, the amount displayed for each of the FICA fields was off by the FICA on tips.
So, lesson learned, if you want to add the Employer FICA/Medicare and Employer FICA/Social Security to the payroll check register reports, make sure you either display all four fields or create calculated fields to summarize them appropriately.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Wednesday, August 17, 2011
Sherlock Holmes I Am Not- Finding Missing Deductions and Benefits
This week I am spending a couple of days back in the old neighborhood (Denver, Colorado) training a client on reporting tools (Report Writer, SmartList Builder, and SQL Reporting Services). After spending this morning discussing table structure and selecting a reporting tool, we dove in to working on reports this afternoon. In our brainstorming session for reporting ideas/issues, I was asked for a way to "check" if employees had been set up for the occupational tax here in Denver. We do this by assigning to a benefit and deduction for the "head tax", rather than using the local tax feature in GP as there are some unique aspects to how Denver calculates the tax.
It is easy enough with SmartList or even Report Writer to test for those that do have the benefit or deduction. But it becomes a little more difficult to test for something that is not there. Especially when the employees would have other deductions and benefits, so we really only want to know those that are not set up for these specific codes. So after a lovely visit to the new IKEA store here in Colorado (oh, my, yes I love me IKEA), and a decent dinner, I came back to the hotel to chew on how to best test for something not existing. And in that, I found my answer...the NOT EXISTS function in SQL. Ah, yes.
Here is what I came up with to test for both scenarios. The first part tests for the OCCPAT deduction, and displays the employee ID, name, and a message if it does not exist for a record. And then the second part tests for the corresponding OOCCPUP benefit and returns a similar set of data. One lovely list. To be included in my lovely SQL report.
SELECT a.employid, a.frstname, a.lastname, 'NO OCCPAT Deduction' from UPR00100 as a where not exists (select * from UPR00500 as b join UPR00100 as c on c.employID=b.employID where c.employid=a.employid and b.deducton='OCCPAT') and a.inactive=0
UNION
SELECT a.employid, a.frstname, a.lastname, 'NO OOCCUP Benefit' from UPR00100 as a where not exists (select * from UPR00600 as b join UPR00100 as c on c.employID=b.employID where c.employid=a.employid and b.benefit='OOCCUP') and a.inactive=0
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
It is easy enough with SmartList or even Report Writer to test for those that do have the benefit or deduction. But it becomes a little more difficult to test for something that is not there. Especially when the employees would have other deductions and benefits, so we really only want to know those that are not set up for these specific codes. So after a lovely visit to the new IKEA store here in Colorado (oh, my, yes I love me IKEA), and a decent dinner, I came back to the hotel to chew on how to best test for something not existing. And in that, I found my answer...the NOT EXISTS function in SQL. Ah, yes.
Here is what I came up with to test for both scenarios. The first part tests for the OCCPAT deduction, and displays the employee ID, name, and a message if it does not exist for a record. And then the second part tests for the corresponding OOCCPUP benefit and returns a similar set of data. One lovely list. To be included in my lovely SQL report.
SELECT a.employid, a.frstname, a.lastname, 'NO OCCPAT Deduction' from UPR00100 as a where not exists (select * from UPR00500 as b join UPR00100 as c on c.employID=b.employID where c.employid=a.employid and b.deducton='OCCPAT') and a.inactive=0
UNION
SELECT a.employid, a.frstname, a.lastname, 'NO OOCCUP Benefit' from UPR00100 as a where not exists (select * from UPR00600 as b join UPR00100 as c on c.employID=b.employID where c.employid=a.employid and b.benefit='OOCCUP') and a.inactive=0
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Tuesday, August 16, 2011
Payroll 941 Mystery Solved (or The Case of Missing Table)
If I was asked by a payroll person for one piece of advice, I would tell them to always make sure they have a backup before printing and posting payroll. So much trauma could be avoided if restoring a backup after a payroll posting gone wrong was possible.
And then, if they allowed me, I would provide two more:
1. If you run in to problems printing and/or processing the payroll prior to posting, DO NOT go ahead and post it. Cancel out of it. Your transactions will be available to be included in a new build, and you won't have to worry about cleaning up a partial posting.
2. Any time you use manual checks to record adjustments or corrections, always make sure you check and double check the taxable wages and employer FICA taxes (as these are not detailed on the edit list). Mistakes in these two fields when manually entering payroll information account for many 941 and payroll summary reconciliation issues.
But, let's get back to payroll posting gone wrong :) Recently I had a case where the payroll printing was interrupted when the server was shut down accidentally. When the server came back up, the user attempted to post the payroll and received errors. Fortunately, they were able to send out the checks since they had already been printed successfully. And then we were able to set about fixing the posting.
We found that the posting interruption appeared to occur between updating the check history (UPR30100) and transaction history (UPR30300) tables. The check history had the checks listed, but the transaction history table was blank for the audit trail code. So we removed the stranded records from the UPR30100, and the users could then re-enter the payroll through manual checks (Transactions>>Payroll>>Manual Checks). Fortunately, they had all of the information to do this and a small number of employees.
After completing this task, though, the 941 was still off. Payroll Summary (Reports>>Payroll>>Period End) looked great. As did the wage amounts from the 941 (Reports>>Payroll>>Quarter End). It was all in the taxes, they appeared to be double what they should be, and the 941 schedule B also showed double for that payroll date.
Head-scratcher, huh? Probably not for those of you who know better. So I went looking in Utilities>>Payroll>>Edit Liabililties and I saw it! The check run had posted its information in the Payroll Tax Liabilities table (UPR30200). So once we removed the record from there as well, all was right with the world. So the lesson here is not forget about the UPR30200, particularly with posting interruptions as it seems that it posts the summary level info before the detail info.
As someone who has avoiding getting in to the realm of "fixing" payrolls that have gone wrong, it has been quite a learning experience for me to move beyond insisting users restore backups when these issues are encountered. I am still not sure what is better, though...losing the work associated with restoring a backup or the time involved (usually with a consultant) to clean it up if you don't. And then you add in the concern of making sure that the client understands what you are doing and why so that questions don't come up later regarding all the "back-end" fixin'. Jury is still out for me, but maybe I am more old-school than I thought ;)
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
And then, if they allowed me, I would provide two more:
1. If you run in to problems printing and/or processing the payroll prior to posting, DO NOT go ahead and post it. Cancel out of it. Your transactions will be available to be included in a new build, and you won't have to worry about cleaning up a partial posting.
2. Any time you use manual checks to record adjustments or corrections, always make sure you check and double check the taxable wages and employer FICA taxes (as these are not detailed on the edit list). Mistakes in these two fields when manually entering payroll information account for many 941 and payroll summary reconciliation issues.
But, let's get back to payroll posting gone wrong :) Recently I had a case where the payroll printing was interrupted when the server was shut down accidentally. When the server came back up, the user attempted to post the payroll and received errors. Fortunately, they were able to send out the checks since they had already been printed successfully. And then we were able to set about fixing the posting.
We found that the posting interruption appeared to occur between updating the check history (UPR30100) and transaction history (UPR30300) tables. The check history had the checks listed, but the transaction history table was blank for the audit trail code. So we removed the stranded records from the UPR30100, and the users could then re-enter the payroll through manual checks (Transactions>>Payroll>>Manual Checks). Fortunately, they had all of the information to do this and a small number of employees.
After completing this task, though, the 941 was still off. Payroll Summary (Reports>>Payroll>>Period End) looked great. As did the wage amounts from the 941 (Reports>>Payroll>>Quarter End). It was all in the taxes, they appeared to be double what they should be, and the 941 schedule B also showed double for that payroll date.
Head-scratcher, huh? Probably not for those of you who know better. So I went looking in Utilities>>Payroll>>Edit Liabililties and I saw it! The check run had posted its information in the Payroll Tax Liabilities table (UPR30200). So once we removed the record from there as well, all was right with the world. So the lesson here is not forget about the UPR30200, particularly with posting interruptions as it seems that it posts the summary level info before the detail info.
As someone who has avoiding getting in to the realm of "fixing" payrolls that have gone wrong, it has been quite a learning experience for me to move beyond insisting users restore backups when these issues are encountered. I am still not sure what is better, though...losing the work associated with restoring a backup or the time involved (usually with a consultant) to clean it up if you don't. And then you add in the concern of making sure that the client understands what you are doing and why so that questions don't come up later regarding all the "back-end" fixin'. Jury is still out for me, but maybe I am more old-school than I thought ;)
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Friday, May 6, 2011
Payroll and Tips (Run Screaming Away, NOW!)
Okay, so I rank payroll and tips up there with sales tax and analytical accounting in my list of "not so favorite" things to deal with. But I did learn an interesting tidbit about how tips are impacted by tax sheltered (TSA) deductions in Dynamics GP. Take the following example:
Adam Smith (Setup)
Now, here is where it gets interesting. Let's say that when the deduction (HEALTH) was set up (Setup>>Payroll>>Deduction), it was left as the default Based on Pay Codes- All (noted in screenshot below).
Huh? Well, because you said that the deduction is based on all pay codes (including the TIPS code), then GP prorates the tax sheltered deduction across all pay codes (wages and tips). So, in this example, tips accounted for 25% of the gross and wages were 75%. So the $10 deduction was allocated 25% ($2.50) to reduce the taxable tips, and 75% ($7.50) to reduce the taxable wages.
Adam Smith (Setup)
- Pay Code-HOUR
- $15/hr
- Pay Code- TIPS
- Reported Tips
- Deduction- HEALTH
- $10/fixed amount per pay period
- Tax Sheltered from Federal and FICA
- Gross Pay
- HOUR- $150
- TIPS- $50
- Deductions
- HEALTH- $10
Now, here is where it gets interesting. Let's say that when the deduction (HEALTH) was set up (Setup>>Payroll>>Deduction), it was left as the default Based on Pay Codes- All (noted in screenshot below).
Here is what happens when you review a payroll summary for the employee:
- Gross Pay $200
- Federal Wages $142.50
- Reported Tips $50
- Federal Tips $47.50
Easy enough to change if you don't want it to reduce tips, simply change the Based on Pay Codes setting for the deduction to Selected, and insert all pay codes except the tips pay codes. Viola! It will only prorate across the included pay codes.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers.
Tuesday, March 15, 2011
Forgot the FUTA? Slacking on SUTA? Fix it now!
I know, I know, I know...I am on a payroll bender lately. I promise more diverse topics soon :) But here is one last payroll fixin' blog post.
Despite our best efforts, pay codes are sometimes set up incorrectly. Pay codes that should have been marked as FUTA and/or SUTA taxable are not. Or, even worse, the Pay Code Setup (Tools>>Setup>>Payroll>>Pay Code) is correct but the employee record has been changed (Cards>>Payroll>>Pay Code). Unlike other taxes, FUTA and SUTA are not calculated and posted on a per payroll basis. These entries are generated from the Period End Payroll Reports window (Reports>>Payroll>>Period End). For this reason, discrepancies in FUTA and SUTA wages are often not uncovered until after payroll(s) has been completed.
So what do you do if you process a payroll (or multiple payrolls) for an employee (or multiple employees) with a pay code that has incorrectly NOT been marked as FUTA and SUTA taxable? Correcting manually can be a chore, especially if mulitple records are involved. You would have to back out the wages using a Manual Check/Beginning Balance (Transactions>>Payroll>>Manual Checks), while the pay code FUTA and SUTA boxes are NOT marked. Post. And then re-enter the wages in the same manner while the pay code FUTA and SUTA boxes ARE marked. Ugh. Time consuming and with a high potential for error.
Thinking that there has to be a better way, I went hunting in the payroll tables and found that the FUTA and SUTA summary reports (Reports>>Payroll>>Period End) rely on the Payroll Transaction History (UPR30300) table for two specific fields:
--Shows employee historical transactions that do not have a SUTA state, but the pay code setup record does have the SUTA tax flag marked
select UPR30300.EMPLOYID as EmployeeID, UPR30300.CHEKNMBR as CheckNumber, UPR30300.YEAR1 as TrxYear, UPR30300.CHEKDATE as CheckDate, UPR30300.PAYROLCD as PayCode, UPR30300.UPRTRXAM as TrxAmount, UPR30300.SUTASTAT as SUTAState, UPR30300.SBJTFUTA as SubjectToFUTA, UPR40600.PAYRCORD AS PayCodeSetup, UPR40600.SBJTFUTA AS SubjectToFUTASetup, UPR40600.SBJTSUTA AS SubjectToSUTASetup FROM UPR30300 INNER JOIN UPR40600 ON UPR30300.PAYROLCD=UPR40600.PAYRCORD WHERE UPR30300.SUTASTAT='' AND UPR40600.SBJTSUTA=1 AND UPRTRXAM>0.00
--Shows employee historical transactions that are not marked as subject to FUTA, but the pay code setup record does have the FUTA tax flag marked
select UPR30300.EMPLOYID as EmployeeID, UPR30300.CHEKNMBR as CheckNumber, UPR30300.YEAR1 as TrxYear, UPR30300.CHEKDATE as CheckDate, UPR30300.PAYROLCD as PayCode, UPR30300.UPRTRXAM as TrxAmount, UPR30300.SUTASTAT as SUTAState, UPR30300.SBJTFUTA as SubjectToFUTA, UPR40600.PAYRCORD AS PayCodeSetup, UPR40600.SBJTFUTA AS SubjectToFUTASetup, UPR40600.SBJTSUTA AS SubjectToSUTASetup FROM UPR30300 INNER JOIN UPR40600 ON UPR30300.PAYROLCD=UPR40600.PAYRCORD WHERE UPR30300.SBJTFUTA=0 AND UPR40600.SBJTFUTA=1 AND UPRTRXAM>0.00
Despite our best efforts, pay codes are sometimes set up incorrectly. Pay codes that should have been marked as FUTA and/or SUTA taxable are not. Or, even worse, the Pay Code Setup (Tools>>Setup>>Payroll>>Pay Code) is correct but the employee record has been changed (Cards>>Payroll>>Pay Code). Unlike other taxes, FUTA and SUTA are not calculated and posted on a per payroll basis. These entries are generated from the Period End Payroll Reports window (Reports>>Payroll>>Period End). For this reason, discrepancies in FUTA and SUTA wages are often not uncovered until after payroll(s) has been completed.
So what do you do if you process a payroll (or multiple payrolls) for an employee (or multiple employees) with a pay code that has incorrectly NOT been marked as FUTA and SUTA taxable? Correcting manually can be a chore, especially if mulitple records are involved. You would have to back out the wages using a Manual Check/Beginning Balance (Transactions>>Payroll>>Manual Checks), while the pay code FUTA and SUTA boxes are NOT marked. Post. And then re-enter the wages in the same manner while the pay code FUTA and SUTA boxes ARE marked. Ugh. Time consuming and with a high potential for error.
Thinking that there has to be a better way, I went hunting in the payroll tables and found that the FUTA and SUTA summary reports (Reports>>Payroll>>Period End) rely on the Payroll Transaction History (UPR30300) table for two specific fields:
- SBJTFUTA - Subject to FUTA: set to 1 if subject to FUTA, 0 if not
- SUTASTAT- SUTA State: populated with the approprate state if subject to SUTA, blank if not
--Shows employee historical transactions that do not have a SUTA state, but the pay code setup record does have the SUTA tax flag marked
select UPR30300.EMPLOYID as EmployeeID, UPR30300.CHEKNMBR as CheckNumber, UPR30300.YEAR1 as TrxYear, UPR30300.CHEKDATE as CheckDate, UPR30300.PAYROLCD as PayCode, UPR30300.UPRTRXAM as TrxAmount, UPR30300.SUTASTAT as SUTAState, UPR30300.SBJTFUTA as SubjectToFUTA, UPR40600.PAYRCORD AS PayCodeSetup, UPR40600.SBJTFUTA AS SubjectToFUTASetup, UPR40600.SBJTSUTA AS SubjectToSUTASetup FROM UPR30300 INNER JOIN UPR40600 ON UPR30300.PAYROLCD=UPR40600.PAYRCORD WHERE UPR30300.SUTASTAT='' AND UPR40600.SBJTSUTA=1 AND UPRTRXAM>0.00
--Shows employee historical transactions that are not marked as subject to FUTA, but the pay code setup record does have the FUTA tax flag marked
select UPR30300.EMPLOYID as EmployeeID, UPR30300.CHEKNMBR as CheckNumber, UPR30300.YEAR1 as TrxYear, UPR30300.CHEKDATE as CheckDate, UPR30300.PAYROLCD as PayCode, UPR30300.UPRTRXAM as TrxAmount, UPR30300.SUTASTAT as SUTAState, UPR30300.SBJTFUTA as SubjectToFUTA, UPR40600.PAYRCORD AS PayCodeSetup, UPR40600.SBJTFUTA AS SubjectToFUTASetup, UPR40600.SBJTSUTA AS SubjectToSUTASetup FROM UPR30300 INNER JOIN UPR40600 ON UPR30300.PAYROLCD=UPR40600.PAYRCORD WHERE UPR30300.SBJTFUTA=0 AND UPR40600.SBJTFUTA=1 AND UPRTRXAM>0.00
Monday, February 21, 2011
Maximizing Garnishment Minimums
Why does it seem like there are a million different ways for different agencies to calculate garnishments? As soon as I think I have a handle on one method, another method pops up. The garnishments feature in GP seems to work well when an employee has a single garnishment, but I have found that multiple garnishments often times requires the Greenshades Garnishments module.
But, let's focus on what Dynamics GP can do (which can be quite a bit, depending on your requirements) out of the box. Here are some requirements I encountered recently:
1. The first $150 of allowable earnings by the employee is not subject to the garnishment
2. If the employee earns between $150 and $200, the amount above $150 is garnished
3. If the employee earns more than $200, the earnings are garnished at 25%
Looking a bit closer, we could summarize this by saying that it is a 25% garnishment with a minimum net pay to the employee of $150 (what they must be left with). For example, if they made $180, the garnishment would calculate as $45 (25% of $180). But since there is a minimum net pay of $150, it would only withhold $30 (the difference between $180 and $150). I have found it is critical to the configuration of garnishments to distill the requirements down to the simplest parameters possible.
So, how do we then set this up in Dynamics GP? First, let's take the definition of "allowable earnings" or what might be called the wage base for the garnishment. In this case, allowable earnings is calculated as gross wages less taxes. So, we can configure an earnings code to match this wage base (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Earnings Setup). This will control how the garnishment is calculated, beyond the standard options of Gross Wages or Net Wages.
Next, we set up the deduction for the garnishment (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Deduction). We select a deduction type of Garnishment, and then select the appropriate Garnishment Category. For the method, we can select "Percent of Earnings" and select the earnings code created above. So, how does this differ from the "Percent of Gross Wages" or "Percent of Net Wages" method? Let's take the following example:
Gross Wages = $1000
Taxes = $200
Deductions = $300
Net Wages = $500
Following our example, the garnishment would calculate based on the earning setup which was defined as gross wages less taxes. So, therefore, the difference in the methods would be...
25% of Gross Wages ( 25% * $1000 = $250)
25% of Net Wages (25% * $500 = $125)
25% of Earnings (25% * $800 = $200)
Save the deduction you have created. And then we have to establish the minimum wages the employee must be left with ($150 per the scenario we have described). Now, for many people familiar with GP payroll, the impulse would be to put $150 in the minimum net pay field (Cards>>Payroll>>Employee>>Additional Info). But, unfortunately, this field is minimum net pay AFTER deductions. In this example, the $150 is the earnings that must be left (which does not include deductions). So this employee has to be left with $150 before deductions.
To establish this sort of minimum, we can use the Garnishment Maximum Setup window (Microsoft Dynamics GP>>Tools>>Setup>>Garnishment Maximum Setup). I select FED as the State/Fed code. The key here is to select the same method (Percent of Earnings) and Earnings Code, and to stipulate a Max Withholding Percent greater than the percentage you plan to use. Leave the Max Exempt Amount at zero. Of course, if you have valid maximums, you can definitely stipulate them here. But the field we are interested in is the Minimum Wage Rule Amount. In that field, we put the $150 that the employee must be left with (prior to deductions).
When you assign the garnishment deduction to the employee (Cards>>Payroll>>Deduction), you can then select the Garnishment Maximum for Federal. This will ensure that the $150 is left and not garnished according to the requirements discussed earlier.
Feel free to share any garnishment quandaries you have found yourself in and how you solved them creatively and I will update the post :) Happy Monday everyone, have a great week!
But, let's focus on what Dynamics GP can do (which can be quite a bit, depending on your requirements) out of the box. Here are some requirements I encountered recently:
1. The first $150 of allowable earnings by the employee is not subject to the garnishment
2. If the employee earns between $150 and $200, the amount above $150 is garnished
3. If the employee earns more than $200, the earnings are garnished at 25%
Looking a bit closer, we could summarize this by saying that it is a 25% garnishment with a minimum net pay to the employee of $150 (what they must be left with). For example, if they made $180, the garnishment would calculate as $45 (25% of $180). But since there is a minimum net pay of $150, it would only withhold $30 (the difference between $180 and $150). I have found it is critical to the configuration of garnishments to distill the requirements down to the simplest parameters possible.
So, how do we then set this up in Dynamics GP? First, let's take the definition of "allowable earnings" or what might be called the wage base for the garnishment. In this case, allowable earnings is calculated as gross wages less taxes. So, we can configure an earnings code to match this wage base (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Earnings Setup). This will control how the garnishment is calculated, beyond the standard options of Gross Wages or Net Wages.
Next, we set up the deduction for the garnishment (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Deduction). We select a deduction type of Garnishment, and then select the appropriate Garnishment Category. For the method, we can select "Percent of Earnings" and select the earnings code created above. So, how does this differ from the "Percent of Gross Wages" or "Percent of Net Wages" method? Let's take the following example:
Gross Wages = $1000
Taxes = $200
Deductions = $300
Net Wages = $500
Following our example, the garnishment would calculate based on the earning setup which was defined as gross wages less taxes. So, therefore, the difference in the methods would be...
25% of Gross Wages ( 25% * $1000 = $250)
25% of Net Wages (25% * $500 = $125)
25% of Earnings (25% * $800 = $200)
Save the deduction you have created. And then we have to establish the minimum wages the employee must be left with ($150 per the scenario we have described). Now, for many people familiar with GP payroll, the impulse would be to put $150 in the minimum net pay field (Cards>>Payroll>>Employee>>Additional Info). But, unfortunately, this field is minimum net pay AFTER deductions. In this example, the $150 is the earnings that must be left (which does not include deductions). So this employee has to be left with $150 before deductions.
To establish this sort of minimum, we can use the Garnishment Maximum Setup window (Microsoft Dynamics GP>>Tools>>Setup>>Garnishment Maximum Setup). I select FED as the State/Fed code. The key here is to select the same method (Percent of Earnings) and Earnings Code, and to stipulate a Max Withholding Percent greater than the percentage you plan to use. Leave the Max Exempt Amount at zero. Of course, if you have valid maximums, you can definitely stipulate them here. But the field we are interested in is the Minimum Wage Rule Amount. In that field, we put the $150 that the employee must be left with (prior to deductions).
When you assign the garnishment deduction to the employee (Cards>>Payroll>>Deduction), you can then select the Garnishment Maximum for Federal. This will ensure that the $150 is left and not garnished according to the requirements discussed earlier.
Feel free to share any garnishment quandaries you have found yourself in and how you solved them creatively and I will update the post :) Happy Monday everyone, have a great week!
Tuesday, January 25, 2011
Don't forget your keys (and the taxable wages)!
I have had a few support issues in the past couple weeks regarding the taxable wages field on the payroll manual checks window. Here is a few scenarios that come up, most often when beginning balances have been entered previously:
1. Federal taxes are correct, but Federal wages are not
2. FICA/S and/or FICA/M is correct, but the associated wages are not
3. Federal wages are off from FICA/M or FICA/S wages, but you can't identify why
How does this happen?
What else does this emphasize? It is very important that beginning balances be reconciled by printing the 941 report for the periods covered by the beginning balances and also by reviewing the employee summary windows. I have even suggested that users build the year end wage file early (you can then remove it under Tools>>Utilities>>Payroll>>Remove Year End) to see if the W-2s look correct. This reconciliation often takes a back seat, we think that we can deal with it at year end. And although that is technically true, the earlier you reconcile and resolve errors, the less stress you will add to your first year end process!
Oh, and before I leave, how do you fix the scenarios above? It is a pretty easy, albeit tedious, process. Simply enter another beginning balance transaction (Transactions>>Payroll>>Manual Checks). Enter a transaction for each of the taxes, leaving the amount field blank but populating the taxable wages as needed. Make sure you use the proper dates when entering the beginning balances, and that you only populate the taxable wages field and not the actual amount field used to record the tax amount.
Happy Year End!
1. Federal taxes are correct, but Federal wages are not
2. FICA/S and/or FICA/M is correct, but the associated wages are not
3. Federal wages are off from FICA/M or FICA/S wages, but you can't identify why
How does this happen?
- Beginning balances are entered using Transactions>>Payroll>>Manual Checks, select Beginning Balances
- Transactions entered by employee for the different transaction types related to taxes (Federal Tax, State Tax, FICA Social Security, FICA Medicare, etc)
- Tax amount entered properly
- Taxable Wage field (appears below the Amount field where you enter the Tax Amount) was not entered properly
- The result is that taxes are correct, and gross wages are correct, but the taxable wages (Fed Wages, State Wages, FICA/M Wages, etc) are not.
What else does this emphasize? It is very important that beginning balances be reconciled by printing the 941 report for the periods covered by the beginning balances and also by reviewing the employee summary windows. I have even suggested that users build the year end wage file early (you can then remove it under Tools>>Utilities>>Payroll>>Remove Year End) to see if the W-2s look correct. This reconciliation often takes a back seat, we think that we can deal with it at year end. And although that is technically true, the earlier you reconcile and resolve errors, the less stress you will add to your first year end process!
Oh, and before I leave, how do you fix the scenarios above? It is a pretty easy, albeit tedious, process. Simply enter another beginning balance transaction (Transactions>>Payroll>>Manual Checks). Enter a transaction for each of the taxes, leaving the amount field blank but populating the taxable wages as needed. Make sure you use the proper dates when entering the beginning balances, and that you only populate the taxable wages field and not the actual amount field used to record the tax amount.
Happy Year End!
Monday, January 17, 2011
Popular Payroll Year End Questions
Courtesy of a fabulous webinar by Microsoft and Terry Heley, here is the bottom line scoop on many of the questions that have been flying around with the change in the FICA rates:
Q. What do I do if I already applied the 2011 tax tables BEFORE I built the year end wage file?
A. Easy fix. Manually edit the FICA/Social Security tax table (Tools>>Setup>>System>>Payroll Tax) to set the rate back to 6.2. Build the year end wage file (Tools>>Routines>>Payroll). Then set the rate back to 4.2% (the new rate for 2011)
Q. Following the method above, can I rebuild the year end wage file even if I have processed payrolls in 2011?
A. Yes, yes you can! Just make sure to change the FICA/Social Security rate in the tax tables before, and then reset it after.
Q. Can I print my 941 for 2010 even if I have applied the tax tables for 2011?
A. Yes, prior to the release of the update from Microsoft (scheduled for 1/24), you can simply change the tax tables as noted above and set your user date back to 2010 to print the 941. Once the update has been released, the report will be date sensitive so you can print it for either 2010 or 2011 (based on your user date) without changing the tax tables.
Q. What manual adjustments do I need to make prior to the release of the update from Microsoft?
A. You only need to consider (2) things. First, that you adjust your tax deposit to the government to include an additional 2%. Second, you need to adjust the FICA employer expense and liability in the General Ledger for the same amount (for more information on this, refer to Mike Lupro's excellent post on this topic).
Good luck in finishing up your year end!
Take care,
Christina
Q. What do I do if I already applied the 2011 tax tables BEFORE I built the year end wage file?
A. Easy fix. Manually edit the FICA/Social Security tax table (Tools>>Setup>>System>>Payroll Tax) to set the rate back to 6.2. Build the year end wage file (Tools>>Routines>>Payroll). Then set the rate back to 4.2% (the new rate for 2011)
Q. Following the method above, can I rebuild the year end wage file even if I have processed payrolls in 2011?
A. Yes, yes you can! Just make sure to change the FICA/Social Security rate in the tax tables before, and then reset it after.
Q. Can I print my 941 for 2010 even if I have applied the tax tables for 2011?
A. Yes, prior to the release of the update from Microsoft (scheduled for 1/24), you can simply change the tax tables as noted above and set your user date back to 2010 to print the 941. Once the update has been released, the report will be date sensitive so you can print it for either 2010 or 2011 (based on your user date) without changing the tax tables.
Q. What manual adjustments do I need to make prior to the release of the update from Microsoft?
A. You only need to consider (2) things. First, that you adjust your tax deposit to the government to include an additional 2%. Second, you need to adjust the FICA employer expense and liability in the General Ledger for the same amount (for more information on this, refer to Mike Lupro's excellent post on this topic).
Good luck in finishing up your year end!
Take care,
Christina
Monday, January 3, 2011
Payroll FICA Fun!
Sharing Michael Lupro's recent post on the FICA changes (different rates for employee -vs- employer, oh my!) and the adjustments you will need to make in GP until the update is released to address different employer -vs- employee rates.
http://btosteam.blogspot.com/2011/01/manual-employer-fica-tax-calculations.html
http://btosteam.blogspot.com/2011/01/manual-employer-fica-tax-calculations.html
Thursday, December 30, 2010
Tax Free Holiday!
So, I had a client email last week because they had a number of employees with state tax but it was not calculating for that specific state. The strange part was that all of the setup seemed right....
Some quick scripts if you find yourself in the same boat. The first selects the records to update, and the second updates the filing status. Our situation was limited to employees in a specific department that worked in another state, but you could adapt these to limit by any other factor as well.
--identifies the records to be changed
select UPR00100.DEPRTMNT, UPR00700.employid, UPR00700.STATECD, UPR00700.TXFLGSTS from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'
--executes the change
UPDATE UPR00700 set UPR00700.TXFLGSTS='insert filing status here' from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'
For the filing status variable, you will have to set up one employee correctly and then look at the UPR00700 to see the proper value in TXFLGSTS (select * from UPR00700 where EMPLOYID='insert employee ID here' and STATECD='insert state tax code here') for the state code.
Hope everyone had a great holiday! And here's to a great new year!
Take care,
Christina
- Cards>>payroll>>state tax, assigned to the employee
- Cards>>payroll.>>tax information, default state code correct
- Cards>>payroll>>pay code, pay codes marked as subject to state tax
- Transactions>>payroll>>transaction entry, the state code was on the transaction
Some quick scripts if you find yourself in the same boat. The first selects the records to update, and the second updates the filing status. Our situation was limited to employees in a specific department that worked in another state, but you could adapt these to limit by any other factor as well.
--identifies the records to be changed
select UPR00100.DEPRTMNT, UPR00700.employid, UPR00700.STATECD, UPR00700.TXFLGSTS from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'
--executes the change
UPDATE UPR00700 set UPR00700.TXFLGSTS='insert filing status here' from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'
For the filing status variable, you will have to set up one employee correctly and then look at the UPR00700 to see the proper value in TXFLGSTS (select * from UPR00700 where EMPLOYID='insert employee ID here' and STATECD='insert state tax code here') for the state code.
Hope everyone had a great holiday! And here's to a great new year!
Take care,
Christina
Wednesday, December 1, 2010
Payroll Audit Summary SmartList POW!
I had a request last week for an audit report for payroll processing that would summarize the amounts and hours being paid by pay code. This report would be generated after a payroll was built and calculated, to confirm the amounts before checks are printed.
So, I turned to my favorite user-friendly tool: SmartList Builder. We were able to create the report in under 5 minutes, which I think deserves a POW :) Here are the steps:
So, I turned to my favorite user-friendly tool: SmartList Builder. We were able to create the report in under 5 minutes, which I think deserves a POW :) Here are the steps:
- Microsoft Dynamics GP>>Tools>>SmartList Builder>>SmartList Builder
- Enter a SmartList ID, Name, and Item Name
- Pick Product: Microsoft Dynamics GP, Series: Payroll
- Under Tables, click the + and choose to add a Microsoft Dynamics GP table
- In the Add Table window, choose Product: Microsoft Dynamics GP, Series: Payroll, and Table: Payroll Work Pay Code
- Click Save
- If you want to, you can also add the Payroll Master table as well using the same process, related on the Employee ID fields.
- In the SmartList Builder window, you can then mark the fields you want to default in the view. We picked Pay Record, Units to Pay, and Total Pay.
- Click Options at the top of the SmartList Builder window to open the Options window
- Mark the Summary SmartList checkbox
- For the Payroll Work Pay Code table, locate the Pay Record field and double-click. Change the Summary Method to Group By to group the summary for each pay code.
- Locate the Units to Pay and Total Pay fields to confirm that the Summary Methods are set to Sum.
- Click Save
- Save and close the Smartlist Builder window
- Launch SmartList, Microsoft Dynamics GP>>SmartList and include the changes.
- View the results! NOTE, this will only display results from a payroll that has been built and calculated but not yet printed and posted. You should see one line for each pay code in the payroll, with a summary of hours and total amount to be paid.
Tuesday, September 14, 2010
The Basics: Deductions in Arrears
New functionality often comes out, and I find it is ignored, or users think its "too complicated" to spend time or money on configuring. So I thought I would break down one of my favorites in recent years- Deductions in Arrears (DIA). This was part of Payroll Extensions in GP 10.0, and it makes life so much easier for payroll folks who have to deal with the impact of part time or seasonal employees when they do not earn enough to cover their deductions.
DIA will track when a deduction is not taken completely due to a shortage of wages. It will then attempt to collect the deduction until the obligation is met in subsequent payrolls. You can manage the arrears, and make manual adjustments (for example, if a portion fo the arrears is forgiven).
First, to view the DIA options, you must grant access to the alternate HRM Solution Series windows for Payrolls using Microsoft Dynamics GP>>Setup>>System>>Alternate/Modified Forms and Reports. These steps are covered in detail in the Payroll Extensions user guide.
In the spirit of keeping it simple, here are the fields available in Deduction Setup for DIA (Microsoft Dynamics GP>>Setup>>Payroll>>Deductions):
DIA will track when a deduction is not taken completely due to a shortage of wages. It will then attempt to collect the deduction until the obligation is met in subsequent payrolls. You can manage the arrears, and make manual adjustments (for example, if a portion fo the arrears is forgiven).
First, to view the DIA options, you must grant access to the alternate HRM Solution Series windows for Payrolls using Microsoft Dynamics GP>>Setup>>System>>Alternate/Modified Forms and Reports. These steps are covered in detail in the Payroll Extensions user guide.
In the spirit of keeping it simple, here are the fields available in Deduction Setup for DIA (Microsoft Dynamics GP>>Setup>>Payroll>>Deductions):
- Allow Arrears: Mark if arrears transactions should be tracked for this deduction. For example, DIA might be used for health insurance deductions but not for voluntary United Way contributions.
- Mandatory Deductions: These work in tandem with Transactions>>Payroll>>Mandatory Arrears, to create arrears transactions for an employee who was not paid in a payroll. For example, a part time employee has no hours to be paid but still needs to pay their health insurance premium. You can use mandatory arrears to create the arrears transaction for the employee.
- Collect When Possible: Mark this if you want the arrears to be collected even if the deduction is not included in the payroll build. For example, if an employee has an arrears transaction for health insurance, should it be collected during a bonus payroll which does not include a health insurance deduction?
Although all of these options are available in deduction setup, they can be modified per employee as well, Cards>>Payroll>>Deduction.
So, during a payroll, arrears transactions will automatically be created for deductions that are marked to allow arrears and cannot be fully collected from the employee during the pay run. You can then view the arrears transactions using Cards>>Payroll>>Arrear Transactions. By employee, you can view the number of arrears pending including the original, collected, and remaining amounts. There is also an adjusted column, which tracks any manual increases or decreases to the arrears amount. You can use the Trx # expansion to view detailed transaction information for the selected arrears, including amounts collected and dates.
Those are the basics. In most cases, it takes less than 15 minutes to configure DIA and it saves a tremendous amount of time and manual tracking. Plus, it increases the odds that correct amounts are collected from employees as quickly as possible!
Thursday, July 22, 2010
Speedy Speedy Payroll Entry
I have been in the midst of a payroll implementation, and led a training yesterday that got me to thinking about payroll quick entry tips. So here are some of my favorite ways to speed up the entry of payroll transactions.
#1. Payroll Mass Transaction Entry (Transactions>>Payroll>>Mass Entry)
I think this has to be one of the most underutilized windows in Dynamics GP. Enter or select a Batch ID to be used for the transactions. Then select a pay code, deduction, or benefit and enter a date range and range of employees by employee ID, class, department or position . You can enter an amount if applicable, or leave it set to zero and you can edit them individually in the standard payroll transaction entry window. You can then preview the transactions to be created (the system will only create transactions for employees in the range who are already assigned to the selected code) and delete the transactions that should not be created. In the Preview Mass Entry Transactions window, click Build Batch to create the transactions. You can then edit the transactions, including the amounts using the standard Payroll Transaction Entry window.
What can you do with this? Create holiday transactions for all of your salaried employees, create commission transactions for everyone in the sales department, and even create a year end batch of auto allowance benefits for employees in the manager position.
#2 Recurring payroll batches (Transactions>>Payroll>>Batches)
By default, when you set up a transaction batch, the frequency is set to Single Use. This means that once the batch is printed and posted in a payroll, it will disappear. But pick a frequency other than single use, and the batch will recur after posting with updated dates based on the frequency. You can then edit the batch and make any necessary changes before the next payroll. This is perfect in situations where the amounts may not change from month to month, or there are only minor changes. For example, deductions for uniforms, benefits for life insurance premiums, or regular bonus payments.
#3 Data Entry Defaults (Transactions>>Payroll>>Transaction Entry>>Data Entry Options)
Ever wonder what the Data Entry Default option on Cards>>Payroll>>Deduction (and Setup>>Payroll>>Deduction) means? Well, it comes in to play quite nicely on pay codes, deductions, and benefits that require transactions (in the case of benefits and deductions, the Transaction Required option must be marked). In Payroll Transaction Entry, click on the Options button in the Data Entry Options section and choose "Use Data Entry Defaults" and select which records to default. Then when you select an employee in the Payroll Transaction Entry scrolling window, the records that are marked as data entry defaults will automatically appear. This is a great option when you generally enter the same transactions for employees each time, and the amounts vary. For example, if you manually key timesheets in to the system, you could set up both the hourly and overtime pay codes as data entry defaults and then you only need to select the employee to create the transactions and then enter the amounts.
#4 Import it!
I am only half joking, integration manager is a GREAT tool for imports of payroll transactions from flat files. So if you have a download from a timekeeping system, or even just payroll transactions that you have calculated in Excel, think about using Integration Manager to reduce the keying.
Please share your own shortcuts, I would love to hear them!
Wednesday, July 14, 2010
Depositing Direct Deposit Information Directly
How's that for a tongue twister? When working on small-scale ( less then 250 employees) payroll implementations, manual entry is not necessarily a deal-breaker. And in some cases, it can be a good thing in terms of cleaning up and reviewing data. However, when working on larger implementations including one I am finishing up with over 1500 employees between three companies, manually entry is not possibly in many cases.
So, okay, fine. We use integration manager to import a lot of data including employee maintenance info, deductions, benefits, and pay codes. But what about direct deposit information? This is critical and subject to entry mistakes, so even if keying is possible...I don't know that I want to risk an incorrect account number or routing number. So, I use table import.
DISCLAIMER :) Always thoroughly test table imports in a test environment first, and also always make a backup prior to performing a table import.
Generally, I am not a fan of table imports because they can be prone to issues if you aren't completely confident of the table and field requirements. But this is one I have done repeatedly and with great success. Thousands of records can be loaded in seconds, and you can avoid carpal tunnel from the manually entry :)
Table import is located under Microsoft Dynamics GP>>Tools>>Integrate>>Table Import. And it should be noted that the import definitions are stored locally in the SY50o00.dat, SY50000.idx, SY50100.dat, and SY50100.idx files stored in \Program Files\Microsoft Dynamics\GP\Data. So if you plan to use the table import from more than one machine, you will need to copy these files from the machine used to create the import. Also, make sure you back up these files after creating the import in case they are accidentally overwritten during a new installation or are lost when a workstation is replaced.
To import to Cards>>Payroll>>Direct Deposit, you must create two table imports. One for the header and one for the detail record.
The destination table for the header record is Direct Deposit Employee Master. And the upload file should contain one record per employee with the Employee ID. The file can then be mapped to the header fields as follows:
So, okay, fine. We use integration manager to import a lot of data including employee maintenance info, deductions, benefits, and pay codes. But what about direct deposit information? This is critical and subject to entry mistakes, so even if keying is possible...I don't know that I want to risk an incorrect account number or routing number. So, I use table import.
DISCLAIMER :) Always thoroughly test table imports in a test environment first, and also always make a backup prior to performing a table import.
Generally, I am not a fan of table imports because they can be prone to issues if you aren't completely confident of the table and field requirements. But this is one I have done repeatedly and with great success. Thousands of records can be loaded in seconds, and you can avoid carpal tunnel from the manually entry :)
Table import is located under Microsoft Dynamics GP>>Tools>>Integrate>>Table Import. And it should be noted that the import definitions are stored locally in the SY50o00.dat, SY50000.idx, SY50100.dat, and SY50100.idx files stored in \Program Files\Microsoft Dynamics\GP\Data. So if you plan to use the table import from more than one machine, you will need to copy these files from the machine used to create the import. Also, make sure you back up these files after creating the import in case they are accidentally overwritten during a new installation or are lost when a workstation is replaced.
To import to Cards>>Payroll>>Direct Deposit, you must create two table imports. One for the header and one for the detail record.
The destination table for the header record is Direct Deposit Employee Master. And the upload file should contain one record per employee with the Employee ID. The file can then be mapped to the header fields as follows:
- Employee ID= Employee ID (from file)
- Inactive= 0 (Constant)
- DD Remainder=1 (Constant, always will use first account for remainder of DD. Can be supplied in file instead if different settings are needed.)
- Index=0 (Constant)
Now for the detail records, the destination table is the Direct Deposit Employee Accounts Master. The upload file should contain the employee ID, index (incremental per employee, so if the employee has two accounts then the first one would be labeled 1 for the index and the second one would be 2 and so on), percentage (make sure this is formatted as a number like 10 for 10%), amount (only one of these fields should be completed for each line- percentage or amount), account number, routing number, type (23 for checking, 33 for savings). The file can then be mapped as follows for the import:
- Employee ID=Employee ID (from file)
- Index=Index (from file)
- Inactive= 0 (Constant)
- Deduction Method= 0 (Constant)
- Deduction= -none-/blank (Constant)
- DD Prenote= 1 (Constant)
- DD Prenote Count= 1 (Constant)
- DD Percent= Percentage (from file)
- DD AmountDir=Amount (from file)
- DD Account Number= Account Number (from file)
- DD Transit Number= Routing Number (from file)
- DD Transaction Code= Type (from file)
After importng, I run check links (Microsoft Dynamics GP>>Maintenance>>Check Links>>select Payroll) on the Payroll Direct Deposit Master. The records will have a status of Prenote (Cards>>Payroll>>Employee) and when you are ready to make all records active you can run the following script against the company database in SQL Server Management Studio.
UPDATE DD00200 SET DDPRE=0
This will update all direct deposit records to an Active status.
Hope some of you find this helpful, and as always, please share your comments, questions, and experiences.
Thursday, September 17, 2009
Oh, where, oh, where, is my overtime?
So, this is more of a question post than an information post. And I am hoping that our loyal legion of followers might be able to help me out on this one :)
GP calculates overtime HOURS in a fairly simply fashion. You can specify a threshold for the pay period, and hours that exceed that threshold can automatically treated as overtime. Okay, fine. So let's look a the practical implication of that.
GP calculates overtime HOURS in a fairly simply fashion. You can specify a threshold for the pay period, and hours that exceed that threshold can automatically treated as overtime. Okay, fine. So let's look a the practical implication of that.
- Biweekly Pay Periods
- Automatic Overtime threshold set to 80 hrs
That works fine if the employee works 82 hrs in the pay period, it will automatically treat the 2 hrs over the threshold as overtime. But what about if the employee works only 80 hrs in the pay period, but it included one day that was 14 hrs long? In most states/jurisdictions, overtime is judged on a daily basis (or even sometimes on a duration basis, meaning if it crosses days if it exceeds a certain span of hours it is overtime) and on a weekly basis, but rarely on a pay period basis (in my experience). So GP does not recognize these measures, only the measure of hours per pay period.
So what to do? Yes, there is Overtime Rate Manager. But that only deals with the calculation of the rate used to pay the overtime, not the calculation of how many hours are to be paid. Every time a customer mentions overtime, I cringe, to be honest :) And I do the requisite third party product search. During that search, inevitably an ISV says "that would be a great product, but no, we don't have something that does that".
So it seems that I am left to hoping that the client's timeclock/timekeeping/timecard system will address the overtime calculation (and many do) but what about those that do not use a third party time solution?
Oh, and yes, there is customization of course. But I am still holding out for a simple solution :) Anyone want to comment and save me?
Wednesday, August 12, 2009
The Ever Expanding Payroll System
In the past couple months, I have fielded requests from a variety of clients for add-on modules for Payroll. The base payroll module in Dynamics GP has some great functionality; but as companies look for greater efficiencies and ways to streamline operations, they start to look for ways to expand the functionality of the system to better meet their needs. What was once a manual process may need to become an automatic process. What was once handled through printing, folding, and sending may now need to be sent through email or delivered through a portal.
So, I thought I would share some of the options I have put out there to help with the processing of payroll. This is by no means a complete list, so please share additional options in the comments and I will update the blog entry to include them :)
First, don't forget about the Payroll Extensions. Unless customers opted out of these, they get them automatically (for a small bump in their product list cost, and therefore enhancement costs). Functionality to track deductions in arrears, to pass liabilities from payroll to payables (e.g., deductions, taxes, etc), and to blend overtime rates is included in the Payroll Extensions.
Advanced Payroll is an additional module (which means additional cost) from Dynamics GP, that adds some specific functionality to the payroll module. It will not apply to everyone, but for those that have the need, it can be a great fit. Capabilities include posting payroll hours to unit accounts in the general ledger, managing pay policies which include different pay rates based on shift, department and/or position, calculation and reversal of payroll accruals, allocation of employee costs across departments, and advanced labor reporting functionality.
PTO Manager is a relatively new member of the family, and it can replace the standard payroll or human resources vacation and sick accrual functionality while adding functionality like allowing two accrual schedules to be applied to vacation time simultaneously (for example, a base schedule plus a bonus schedule given to select employees) and management of carryover hours.
If we move outside of the Dynamics GP client, in to Business Portal, there is a whole other world that opens up in terms of employee self service, including:
So, I thought I would share some of the options I have put out there to help with the processing of payroll. This is by no means a complete list, so please share additional options in the comments and I will update the blog entry to include them :)
First, don't forget about the Payroll Extensions. Unless customers opted out of these, they get them automatically (for a small bump in their product list cost, and therefore enhancement costs). Functionality to track deductions in arrears, to pass liabilities from payroll to payables (e.g., deductions, taxes, etc), and to blend overtime rates is included in the Payroll Extensions.
Advanced Payroll is an additional module (which means additional cost) from Dynamics GP, that adds some specific functionality to the payroll module. It will not apply to everyone, but for those that have the need, it can be a great fit. Capabilities include posting payroll hours to unit accounts in the general ledger, managing pay policies which include different pay rates based on shift, department and/or position, calculation and reversal of payroll accruals, allocation of employee costs across departments, and advanced labor reporting functionality.
PTO Manager is a relatively new member of the family, and it can replace the standard payroll or human resources vacation and sick accrual functionality while adding functionality like allowing two accrual schedules to be applied to vacation time simultaneously (for example, a base schedule plus a bonus schedule given to select employees) and management of carryover hours.
If we move outside of the Dynamics GP client, in to Business Portal, there is a whole other world that opens up in terms of employee self service, including:
- Benefit Self Service: Online access for employees to enroll in benefits. Refreshingly easy to configure and control, I am repeatedly surprised by what a simple, yet functional, add-on this can be. My husband works for a large corporation that uses a large product that is not nearly as easy to use, or as intuitive.
- Human Resources Online: Online access for employees and managers to access pay stubs, personal information, skills and training, as well as other HR features like recruitment.
- Greenshades: I used to think of them as primarily dealing with taxes, which they still do...offering a variety of tax solutions for integration with Dynamics GP payroll. However, they also have a variety of other products to address additional PTO management needs, paperless payroll (think sending pay stubs and W-2s electronically, and online access to employee information).
- Integrity Data: Another familiar face that also offers leave management (with online self service capabilities), position and FTE control features, employee allocation capabilities, and emailing of earning statements.
- JAT: Offering carrier interface (for those using HR) for benefit information, as well as electronic delivery of pay stubs and online access to W-2 information.
I am sure there are many more out there that I should mention, so I will also put a plug in for www.isv-central.com and the Microsoft Solution Finder as great tools to assist in your search for that perfect module :)
Have a great end of your week!
Subscribe to:
Posts (Atom)