FastTrac: BadPrimary
RecTrac 10.3 Migration: How to run the BadPrimary Program
Table of Contents
Introduction:
Join Brian Hatch as we review how to run the Bad Primary program leading up to your RecTrac 3.1 Migration.
Video:
Transcription:
Welcome. In this video, we are going to review the bad primary step for your 3.1 pre migration. Under tasks, I'm in the Teamwork project, there is a task for bad primary. And the instructions are for running it are listed here. And this is probably where you would have access the video. The first step is really acquiring the bad primary dot our file. So at the top, I can go to the Files tab. And then I'm just clicking on the Download icon to the right of bad primary, this will just pull the file down into my downloads folder. And from there, I can now actually go to RecTrac. You will want to do this on a machine with RecTrac. It doesn't have to be the server, any machine with RecTrac work. And under Utilities system, there is the RecTrac Quick Fix processor. And from there, I can just right click in the green field. And I can select that file I just downloaded. And just hit process. So this won't hurt anything, you can run it multiple times, this is really just creating a report in the database that we can now kind of pull out as a second step to review any potential issues within accounts. So now that we've run the bad primary, we can go access the report by going to utilities, system. And then the RecTrac file explorer option. If I expand all files and RecTrac database, option, there is a pre migration or pre upgrade, sorry, and you can see the bad primary file that was just created. From here, I can hit extract and you can really export it out to whatever location you want on your local machine. I'll just choose my local C drive, and I'll hit OK. And now that should be located out on my local hard drive, refresh my folder. So now I have a CSV file that can actually open up in Excel and it'll basically list I'll drag it over to your Screen, the potential problem accounts in the database. So in this case, just pick the second one here, Harold household 17. So within RecTrac, I can go to household maintenance, and I'll just open 17. If we review this account, we can see that Harold is the primary guardian. And we don't have a secondary Guardian listed here. And if I go to members, you'll notice there is another person in the household. And the only question really is is Jenny, who's number two, is she a secondary guardian or she dependent in the household? Judging just looking at account, you might be able to determine one way or the other. The there's the reason they're showing up on his bad primary report is because there's not a direct match there, right, Jenny's here on this Screen, and she's not here on this Screen. So that may or may not be an issue, depending on the account. So it's one of those things you can take a look at maybe based on the birthday, you can kind of determine whether they're, you know, again, a household with parents or have household with a parent and a dependent on her underneath it. So if you were to look at this account in 3.1, in your test database, you'd see the two family members were created during the migration process. And the one is going to be listed as a primary and the other one is just gonna be listed as a regular family member. If we look at another example. Just look it up here. So one of the more common examples we'd see would be an example like this, I pulled the John Denver household, and John Denver is the primary in this case. And if I drill down into the members, I've got one option there for John Denver as well. Now the problem and the reason it's showing up are going to show up on this export is the name match isn't exact. So if I go back, this is JON. If I go back to the main household, it's JOH. So it's not finding an exact match. And what does that mean with the migration? After your 3.1 migration, you're actually gonna end up with two John Denver's right one with the JOHN and spelling and one with the JON spelling. And again, the assumption is probably the same person and it just was updated on one Screen and probably not the other, which is, unfortunately pretty typical in 10.3. So it's one of those things if we just correct the spelling either on this Screen or on the Screen at the member level so that they do match, then the migration will run and you'll only have one of that family member record listed. So just a couple of different scenarios that we want you guys to basically review in your 10.3 database to get cleaned up to cut down on potential confusion in 3.1. Thanks for watching.
Delete