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.
No comments:
Post a Comment