Hello all,

We are in our conversion testing cycle for go-live later this year. We are testing PR560 to import payroll history since beginning of year for about 5000 employees. The CSV file we are using for import is a little under 500,000 records. After letting it run for 70+ hours and only appearing to be about halfway finished, I opened a GSC case asking if this was normal, are we doing something wrong, etc. The response was that PR560 should never be run with more than about 50000 records.

How did everyone else handle this? We can split the file up into 10 pieces, but we still have to run them one at a time.

By the way, it's not CPU, disk, memory, database, or network that is the bottleneck - we went through that monitoring phase already. Everything is basically idle, PR560 just runs dog slowly.

Thanks,

Wade

Although I've performed a lot of conversions, shows how much I know - I always based the csv files on excel limitations so I, too, have always kept files to approximately 50,000 lines. Depending on how your data is sorted, you can run the PR560s concurrently - good luck :thumb:

Thanks for the response. Do you happen to recall (ballpark) how long your imports took for Excel-sized input files? We are thinking that 50,000 records will take about 16 hours to import.

Update mode was about an hour each

Can you elaborate a little on sorting the input file correctly so as to be able to run concurrent PR560 jobs? Do you basically mean sort it and split the files so that a given company, employee, check-id, process level, and department are all within one file? Sorry to be a little dense, I'm not the one actually running these jobs, so I'll need to communicate this to a co-worker, just want to make sure I'm clear. Thanks.

In order to run concurrently, I've made sure that all records for an employee are in the same file - for instance, working with a monthly payroll, all 12 months for employee A are in the same file. You still need to sort by PL, dept and check ID but the files are broken up by person, basically. As a head's up - beware the re-run feature - any converted records (not just the file you're working with) is purged. I found that out the hard way a ways back!

Thanks a lot for your comments.

No problem - just one other thought. Hopefully you haven't changed banks during the period that you're looking to convert? I ran into that in another life - we had "duplicate check" errors because numbers crossed banks.

Happy Friday

I ran the PR560 conversion in Sept 2005 with about 1.6 million records in the conversion file.
I don't remember how long it took but I know it was 48 hours or less.
This was on the 8.1 apps.
I think the sort is very important, I sorted by EMPLOYEE, PROCESSLEVEL,DEPARTMENT, CHECKID, RECORDTYPE.

Something weird we just discovered: if we down the environment completely (stoplaw, rmi, the whole 9 yards) and start it back up again, then run the jobs, we can get ~60,000 records imported in about 12 minutes. Otherwise, they take about 12 hours.

There is no one else in the system (we aren't live yet), so it doesn't have anything to do with competing for resources, and this result proves to me at least that it is not data-related on the CSV import files.

:bow: Kudos for posting the follow-up info.

Here's what we ended up doing:

We "untied" the LP service codes from the paycodes before running PR560. This cut down on the runtimes of the PR560 since service records no longer needed to be created. We'll recreate the service records after the fact by running LP554.

This cut PR560 import times for ~60,000 records from 12-14 hours down to 16 minutes.

:bow: Tnx for the info. Pls let us know what LP554 run time was...