Anyone got any views comments even better reports or documents on what clients do to reconcile migrated data prior to Go Live. I'm thinking of the usual stuff Number of employees loaded match legacy Total starting point of balances match carried forward point of legacy etc.

Delboy . .We used P35 output from legacy and Oracle - this does only check a limited number of balances (NI Taxable Pay PAYE etc) but it was a good test to see if the oracle payroll engine can find your converted data especially terminations. . .The only hassel is a bit of a pain identify any problem employees but you can use a couple of views that get populated with P35 data pay_gb_year_end_assignments_v and pay_gb_year_end_values. If you use P35s as part of your recon remeber to roll them back. . .HTH . .Jay

Del boy . .In the past I've used a combination of stat-type reports e.g. count of emps loaded (by various criteria such as org payroll person-type) in conjunction with exception-type reports e.g. emps with no personal payment method emps with no address emps with no salary element or other regular payment element entry. It's also a good idea to select a random small percentage of records and inspect them in maximum detail (literally field for field) - a good excercise for the user community I find! . .It might be worth looking at Payroll Exception reporting as a reconcilliation tool but failing that you need a techie to put some simple reporting scripts together. . .For balances P35 as Jay says will cover you for statutory balances - any others will need a specific report. . .Bear in mind tho that the key to a successful reconcilliation is to be able to compare like with like between legacy and Oracle. P35 is an easy win as it's a statutory report so any payroll system should have a version of it with a consistent output. For anything else you need to be confident that the reporting capabilities of the legacy system can produce the legacy equivalent of the reports you're going to want to produce on Oracle. Ye ken whut ah mean Jim?

Aye the Noo! . .Thanks guys . .I'll progress on that basis

You have to be very careful here. . .Many of the comments are assuming a one to one match between legacy and what you are loading into Oracle. . .Remember often as not you are only loading a subset of the employees from a legacy system. . .Elements and balances often do not map on a one to one basis. . .Also you may find in legacy systems that an employee with 3 assignments could be 3 employees. If these are merged into one employee with 3 assignments in Oracle the totals do not match up. . .I can go on listing exceptions the list is virtually endless. . .You can only really reconcile the data migration to the files you are supplied with. if you are given a file with 5000 emps on it and you load 5000 emps the load is reconciled. The fact that you should have been given a file with 5200 emps is not your problem. . .You then throw back to the client the reconciliation of those files back to legacy. Most clients do not like this as it means going to legacy supplier to write reports which they have no interest in as they as losing the business. . .You can only load what you are given someone must prove you have been given the correct details. . .Agree on the point for a sample of employees you do the field by field check. . .Agree about the tehie and writing running lots of little scripts to check values. . .One way to get help the reconciliation back to legacy is to say 'give me all the data on legacy' then you can pick and chose what you required to load and you have the legcy data in a table which you can interogate and compare to oracle