We are pressed to get our 2007 payroll history into the system and I had a few questions.

The consultants made this sound as if it was going to require extensive testing. If my upload sheet passes in report mode, I'm assuming that it will pass in update mode. I'm also assuming that the system will then take the data and properly add to the current totals in the system (though I plan to query to check)...but is this really supposed to be this complex of a project? I know that we've worked hard to get the sheets error free and was expecting that this would be the hardest part.

Any advice?

We have to upload payroll 1 - 8 as we implemented Lawson in April. Would it be recommended to upload these at different times, or should we wait until we have all 8 sheet ready and error free before uploading them (I'll upload them one at a time)...but did not think it a good idea to do them days or weeks apart.

Any Advice?

Any advice given is greatly appreciated and I hope one day to return the favor once we get this Lawson stuff under our belt.

I would have said it would take extensive verification, rather than extensive testing because getting the upload to work error-free is not hard, but error-free does not mean accruate data.

I've seen PR560 loads result in incorrect gross wages, incorrect taxable wages and a mess of other things.

I'm not sure what you mean when you say that your sheets are error free. I can picture a scenario where the spreadsheets are accurate from a payment detail (wages, deductions, gross, net, etc) perspective but aren't ready for PR560. One example is when loading a Federal tax deduction record, you need to include a value in the deduction amount, the taxable wage and the gross wage fields to get good results in Lawson. I also had a situation where a deduction was non-taxable pre-Lawson and taxable post-Lawson. Because we didn't take the difference into consideration when we mapped the historical deductions to the Lawson deductions, Lawson thought the historical deductions were pre-tax, throwing off the ytd taxable wage data (I don't remember whether it was PR560 or our reconciliation programs that threw the error on that one.

I figure you've already done run your data through PR560 and run verifications so have already found and fixed issues like these, but you asked, so I thought throw my two cents worth in. If you haven't done extensive verification of converted data in a test run, then I would recommend you do so before loading into production.

Karen is right: Just because the input files look good does not mean that the data will all land in the right places in the application.

And yes, the PR560 can be very complex -- it depends on your circumstances.
If the consultants' recommended extensive testing, then you should identify and validate all your assumptions for your PR560 circumstances. (For example, PR560 does not load Adjustments or Reversals -- were any Payroll checks Voided in the first quarter?)

Before running PR560 in Update Mode in your production environment, run it into a test area that is an up-to-date copy of production.
Then get the Payroll dept involved and verify EVERYTHING:
~High Level totals (per Reporting Entity, per Pay Code and Ded Code, Gross and ~Taxable and Excess Wages)
~Per Employee Totals (PR52) and Detail (PR260)
~PR85
~PR294 and other balancing reports

Question: At the April go live, had all active employees reached their Taxable Wages Limit for ceiling-based deductions like SUI?

Good luck.

WOW - my eyes are opened a lot wider now. I've not yet loaded anything in test, just report mode. What is meant by pr560 NOT loading voids or reversals. We are showing voids and reversals as negative #'s.

My concern now is the various comments about things not landing where you expected. Is the pr560 buggy or flawed or does this comment refer to those preparing the sheets not having all items showing correctly?

For example if my gross ytd is 13,000 and I upload $2000...wouldn't/shouldn't I expect the pr560 to then show 15000 - or is that too much to as from it? LOL

All of your advice and insht thus far has been very helpful and I appreciate it so much.

Using your example, if you have a YTD gross wage of $13,000 and upload a wage record (meaning a record with a paycode) of $2,000 you gross wages will be correctly updated to $15,000. However, if that is all you did, your gross wages and taxable wages on the quarterly balancing reports like PR290/PR294 will be wrong because those values are updated only if you pass deduction records with the gross and taxable wages.

Here's an example of where I've seen this specific situation go awry. In the pre-Lawson system, an employee received a paycheck for a small amount, say $100 (like overtime pay that was missed during the normal payroll run). Some payroll systems would have a wage record for the $100, but no deduction record for Federal Income tax since the amount is low enough that there would be no withholding from that paycheck. If your old system is one of those, unless you've addressed this specifically, your PR560 file probably has a wage record for $100 but no federal income tax deduction record.

Lawson would expect to see a wage record for the $100 and a deduction record for the Federal Income tax (and all other taxes) with a deduction amount = 0, taxable wage = 100 and gross wage = 100. If the deduction records are not in the PR560 file, the quarterly deduction file will not include that payment and the quarterly, ytd and W2 reports will be wrong.

This is not necessarily something you would catch on a spreadsheet because it's not really a "mistake". It's just a difference in the way payroll sytems store and calculate wages for quarterly and W2 reporting.

It's been quite a while since I've done a PR560 load, so it's possible you would get an error message if you loaded a wage record with no deduction records, but I don't think you would. I think PR560 is happy as long as the gross-to-net calculations balance for each paycheck - which would happen in this example.

Did that help?

You are so wonderful. Thanks so much for that info. I had no idea on that one and would have HATED to learn that while under the pressure to get these uploaded.

You have saved me some real headaches!

I owe you both LUNCH & DINNER... The next time you are Jacksonville, give me a ring.

When I tested my upload, the adjustments ARE actually being posted. Only issue is that they show as a system check instead of a reversal. In this case system check for -500, which I think we are o.k. with. Any cons to letting the history show reversals, voids, etc (whether resulting in a negative or positive distribution) as a system check versus void, reversal, adjustment??

I can't figure out if we are supposed to show the pr560 parameter for CREATE PAYMENTS as a yes or no for history. This is what populates the PRcheck table, which I believe is only used for bank reconciliation. Any pros/cons to having this as a No??

Thanks - we are getting close - 7 days till we upload in LIVE....yikes!!