Sage 100

Working on a Sage 2018 Adv upgrade with payroll from Sage 2016 Adv. During the data conversion I get an error ""The following conversion record failed while converting CNA: 02.17.00.00:DATA:PR_ConvertToFramework:000000:000 - The Employee Number is required. View the Activity Log to locate a specific conversion log.' The conversion log has the EXACT message as above with no other information!! I've rebuilt my PR files and sorts in 2016 and re-migrated. I read the Sage KB article That says there is a corrupt records in PR1 and to 'identify the corrupt record in 2018 by comparing PR_Employee.m4t and PRxxx.soa tables. Last record in PR_Employee.m4t is usually the bad record Note next record in pr1xxx as possible suspect.' I tried deleting the next records in PR1, but it fails on a different record each time I remigration it so not sure I'm gaining anything. Has anyone had any issues like this? I have a case with Sage, but am wondering if anyone else is experiencing issues.

Do you have Payroll 2.17 installed or Payroll 2.18 installed?

Payroll 2.18.

It sounds like the 2016 PR1 is still corrupted but in a way not detectable by Rebuild Key Files. You could try the *UFAR utility on your 2016 PR1xxx.SOA file after making a backup of it. In this thread is an old Sage KB doc (original version by yours truly while at the mothership) you can follow on how to run UFAR. You can ignore Step 6 because with PR1 unlike SY0CTL, the key should have only printable characters: https://90minds-com.socialcast.com/messages/25417612 Sometimes with legacy module data, the key inside the record (inside that Field 01 super-string as seen with DFDM) doesn't match the external key (what you see in the top left) causing this Error 11. Sometimes you can't visibly see that with DFDM.

One thing to check is for duplicate employee numbers in the database. That will halt conversion without identifying the source of the issue.

Thanks for the ideas - going to look for duplicate numbers first and then try the UFAR. Will let you know

I found an employee with a department but employee number was all zeros and it was an inactive employee so I renumbered. Got much farther in the conversion, to 1700 records out of 7000 before it errored out. I have found several with duplicate socials but none with a duplicate employee number.. I'll work next on cleaning up the duplicate socials.

Where is the conversion tool that highlights these type of show stopping issues? I wonder if Sage is hard at work developing this tool.

I hope Sage is working on something! They have this data.

I believe that it will stop and show you the number that causes the problem or the number before or after it. When I had this issue, the employee number was duplicated but the employee department was different.

There isn't any way to fix the data in 2016 - UFAR and UFAC both return 0 errors found. The only way I'm going to get through this is to run the conversion, when it stops remove the next record in 2016, remigrate and start conversion again and repeat. I might export everything out and remove some old terminated and inactive records and then re-init and import and see what that does.

Just to throw an option into the mix, you could get a M/D type to debug the conversion at the time of the error to identify the specific issue OR escalate with Sage Support to get their engineers to debug it.

@AlnoorCassim I can ask ours if he can help.

@MaryMays - Did you ever find a reason for this? I'm working on an upgrade with 6 companies and the one with the most employees is crapping out with 1106 of 1132 employees converted. I've rebuilt files, deleted the next employee on the list, still stuck. ETA - Deleted the LAST employee on the list and it appears to be working - at least it's gotten farther, Luckily it was a new employee who has only had 1 check to recreate.

@BethBowers Yes, it was because there was bad data in PR1. First, I exported the PR1 to Excel and identified all the duplicate social security # people and deleted them in employee maintenance. Then I just had to keep deleting the bad records with DFDM and starting conversion over again until done. My problem was the client NEVER terminated anyone so there were people that hadn't worked since 2001. Also this client has an import to bring in PR employee records so that caused some issues. Luckily, none of the bad records were remotely current, so no history at all. Next time I will request my client get rid of people that haven't worked for 10 years!

@MaryMays - I am now past the employee file, but it's crapping out on some history file - of course the error is practically the same and doesn't mention which file. ARGH.

Doesn't 90M have a 911 support number?

But I'm ENJOYING going through 3 support people because I'm such a hot potato no one wants to touch it...

IT IS A SIGN. While I'm on hold back with the Install group (where I started) since the Application group said IxNay to helping me, the client calls and tells me that their power just went out. Obviously this upgrade was not meant to be.

@BethBowers Sage has to come up with some better tool to check the data PRE-MIGRATION/Conversion.

@MaryMays - I'd be happy if it just told you which file had the error instead of the generic conversion error message!