Preventing personal info. from being overwritten in a DCM import

[R. Butler]

Is there anyway to be warned of duplicat personal information in a DCM import. We've got a few plans that never enter rehires as a rehire, but rather a new hire. If I enter census info. by hand I will get a warning if duplicate information is on the system; thus I know the rehires. If I use the DCM import, I don't get that warning, is there anyway to get that warning using DCM? I've pretty much given up on the client to enter rehires correctly & they have several rehires each year so it is difficult to catch everyone.

Thanks in advance for any guidance.

[Tom Poje]

the best I have is a census report that will indicate people who have compensation but also have a term date prior to plan year begin. logically those would be rehires, but thats about the close as I can come to generating something.

[R. Butler]

My problem is that in most cases they're entering new term dates, so the old term date is also being overwritten. Its a restaurant so turnover is fairly high & 10-15 rehires a year isn't unusual.

[Guest mariecummiskey]

in your der date format you are able to choose not to have dates overwritten - uncheck the box that says "replace existing dates with input". then go back to the "new " dates manually. that is how i solve it, although a hassle with larger cases.

[Tom Poje]

when you are doing the dcm (or for that matter the download) are you downloading the 'term date' into term date or into status date? If it is downloaded into status date, then you should be able to run a census report before eligibility to check for possible changes.

I don't remember if census audit records changes on the download, but I never liked the length and format of that report.

[R. Butler]

I download into the term date field & then manually enter into the status date.

I had never notice that I had the option to not have dates overwritten. I will look for that. It will be a hassle, but it will make mistakes less likely.

Thanks for the suggestions.

[Guest mariecummiskey]

we don't enter term dates, just status date and code. i don't like to copy over any dates. we work to get correct dates in the system, and i would rather import NOT copying dates and then go back and review rehires.

if you choose not to copy over dates the audit report doesn't work.

i don't like the format or the information that the audit report gives. i would like to see it improved. we are not at 9.0- i read the new features, audit report isn't mentioned..

[Tom Poje]

ah,time for a bit of explanation.

the term date field.

this is one of those fields that rarely should be entered by hand. I have had to slap people across the wrists for doing things like that.

this field does not actually mean 'termination date' but rather, 'termination date from the plan'.

thus, an ineligible ee who quits would never have a date in this field.

and the category code on an ineligible will list the reason why ineligible.

if data is enetered in status date and status, then running eligibility will set the term date field (if ee is an actual participant)

in the same vain, if ee quit one year and is paid out the next, changing status to paid out and changing status date will not change the term date.

if ee is rehired (changing status date and status), system will delete the term date when eligibility is run.

.....................

on another note, a common problem I have seen in coding plan specs is

plan entry requirements -

initial participation - the same value should be entered across the board. never an X for terminees, even if terminees are excluded from contributions. this is an entry field, not an allocation field. enetering an X will produce incorrect results on coverage and nondiscrim testing.