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.

Backup, Backup, Backup your Dynamics GP System

I've been a lazy blogger the past month or so. Seems like my writers block coincided with our move to our new blogging location on RoseBizInc.com so hopefully this entry will get me back in the spirit. If I fail miserably to excite, inspire, inform or educate anyone who reads these blogs please don't tell me so. I'd rather live in a spirit of happy ignorance than to really hear your true opinion.


Had an interesting happening a few weeks ago. Had a client that has project accounting, purchasing etc. We were seeing some rather interesting results in the POP module so we ran check links on the purchasing transaction table. No problem. We then ran it on the purchasing historical transaction table and let it run during the night. Looked at it in the morning and noticed a check links report that had 4500 pages of removed historical transactions. Yikes. If you don't know GP:


1. Why are you reading this blog

2. That is not a good thing

3. Check links is sometimes refered to as "Break Links". It's a tool used to verify data in the tables and will either say it's all good, add back in info that's missing, or remove data not needed.


So no sweat, lets restore to last nights backup. System guys says, cool, I'll let you know when it's restored. Now in this situation what would be the worst possible thing that you could hear when you pick up a call from the systems guy. In my case it was "uh, we got a problem." Turns out they have been doing backups to the same tape drive for the last month. Each night it wrote over the previous nights backup. And when they went to restore the backup some how they managed to delete their one and only backup for the last month and a half. Turns out the guy responsible for backups was in Costa Rica on vacation for another week so.... It's funny now that I look back on it.


There's more to the story but I'll leave this post with a moral:


When in doubt (or even if you are not), BACKUP, BACKUP, BACKUP your Dynamics GP system. Here is an older post I did about backing up GP in case you want to make sure you are backing up all aspects of your GP system.