Thursday, September 3, 2009

Should you backup your database before processing payroll?

A client called yesterday and were in a bit of a tizzy. They processed payroll last month and in the middle of things GP crashed. They said a few cuss words, logged back into GP then continued processing. When they went to do their period end reports they were a little taken back because gross wages was off by $13,000,000. I had to write that out just to see how many zero's that is.
A few questions came out of the CFO's mouth such as:
  • How could this be?
  • Did they really send a check out to an employee for that amount?
  • Is our bank reconciliation off?
  • Is our GL amounts off?

We discovered an employee with the below information:

My first question was - "Are you sure this employee is still in the country because if I received a check like that, I'm heading straight to Samoa for an indefinite period of time."

They chuckled a bit but I don't think they found my comments to helpful.

The payrun that caused this was of course two weeks ago so restoring from a backup was not really an option. This made me pull out my SQL skills and go to work. I used tech doc 948268 to resolve the issue but here are the basic steps:
  1. Backup Company databases
  2. Make sure you backed up the correct company database
  3. Delete the payrun in question from the following tables using these scripts. Replace XX with the correct Audit trail code. delete UPR30100 where AUCTRLCD='XX' delete UPR30200 where AUCTRLCD='XX' delete UPR30300 where AUCTRLCD='XX' delete UPR30400 where AUCTRLCD='XX' delete UPR30401 where AUCTRLCD='XX'
  4. Delete the employee's summary information by using this script, replacing YY with the employee ID and ZZZZ with the year in question. delete UPR30301 where EMPLOYID = 'YY' and YEAR1 = 'ZZZZ'
  5. Run Reconcile in payroll - Point to Tools on the Microsoft Dynamics GP menu, point to Utilities, point to Payroll, and then click Reconcile.
  6. Deal with bank reconciliation module and GL as necessary

I ended up deleting one table that had 450,000 rows duplicated for one transaction. Thus the 13 million dollar employee card.

Now the real question is should a backup be done before processing a payroll batch? The answer is a resounding YYYYYYYEEEEEEESSSSSSS!!!!! Does that mean everytime? Let me be clear. Everytime you process payroll you are at risk of having your payroll module blow up. The above was a fairly easy fix compared to what can happen. I wish I could be more upbeat about how great GP is and how solid payroll is as a module.

Another thought. We have a couple of clients that all they do is payroll. They process thousands of transactions a week and in any given day they have several people posting payroll batches. To back up their database takes 10 to 20 mins. To do a backup each time is not really feasible. So after explaining the situation clearly they have decided to risk a days worth of work for irregular event of having the payroll module messed up with a posting interruption.

Talking with Mike from our office about this event and he told me how he fired someone when he was a controller when they processed payroll without doing a backup. The one and only time they didn't have a backup resulted in heartache, gnashing of teeth, Mike flying off the top ropes with a 10 key....you get the drift.

Here is a link to backing up your GP system.

Please consider making a backup before processing your payroll. One time in a thousand you'll actually need it but you'll thank your lucky stars when you do.

Labels: , ,

1 Comments:

At September 3, 2009 6:29 PM , Blogger Mariano Gomez said...

Doug,

This is a fantastic article! I hope we get more DBAs and system administrators paying attention to backups and their ability to restore those backups.

MG.-
Mariano Gomez, MVP

 

Post a Comment

<< Home