Not a takeover plan or startup

[Guest DottleC2]

It's been so long since I've done a plan that wasn't a takeover or having been a 'start-up' on Relius (first valuation year on Relius Administration system). I was wondering what administrators were setting the 'Plan Entry Requirements' screen parameters at, specifically which of the two:

- 'half-years' credited or

- 'not computed - use as entered' option

... is being chosen for an ongoing plan in which a valuation _has_ already been run on Relius for the prior year.

I see to recall that setting the system to 'not-computed - use as entered' had its drawbacks (I don't remember what though), but I would think that after the first estimated eligibility transaction, that the parameter would just as well be set to actual rather than estimated, am I correct?. Because we run only one annual payroll, varied, the system only has that one temp file field to look back to for hours, assuming a second or 'post takeover' plan year is being run.

After the first (startup/takeover) year, after the raw census data is imported, we input only termination date in the status field, and change the employee status to T - we'd like the system to do the rest of the work. We also input comp prior to entry if applicable.

Thanks,

Bill

[Sue H]

Hi Bill,

Except in a takeover year, the half/whole year/not computed option will not affect service calculations. This option only dictates how to calculate service when none exists (service, vesting and participation years are all zero).

Sue

[Guest DottleC2]

Thanks for that, well put.

Okay, It's starting to come back -

My primer sheet would read ...

If any of the service fields are overridden to a value above zero, then no estimation occurs.

A partial time employee who never works 1000 hours will initialize vesting using the '1/2 year' because a zero resides in all service fields, requiring an override after the first eligibility transaction. (This operates so in a start-up year, I'm not sure if it operates so in second and subsequent years.)

The first eligibility transaction assume is processed as of the First day of the plan year, and the 'Override zero service people' can be kept in a text file for import . The second and subsequent eligibility transactions will contain the rollback for these inputs.

For Eligible participants entry date required if 'Date elig met' is overridden to a date prior to the first day of the plan year.

...something like that.

Bill

[Guest Tbrown]

Bill,

what do you mean with your last one?

"For Eligible participants entry date required if 'Date elig met' is overridden to a date prior to the first day of the plan year. "

That one has me baffled.

[Guest DottleC2]

From what I can extract from my notes, the Relius system won't assign an entry date prior to the first date of the plan year on its own. (I presume that it won't assign any date outside the range of the begin and end plan year dates for that matter.)

As an example, a 2001 plan year. A participant hired in 1995 was hired in part time, then changed to a full time employee in say 1997. If you change only her 'Date Entry Met' date to 12/31/1997, then run the transaction, the system will assign an entry date of 01/01/2001, which is incorrect.

So if a date met is overridden, you'll want to also override entry date, in the case of someone who was eligible prior, but whose entry date cannot be estimated.

I haven't tested this completely, and have only tested this in a start-up year; also there are safeguards that would prevent any transactional problems - the example above still has the participant eligible on the valuation - the date just needs adjusting upon finalization in order to be completely accurate.

Bill

[Sue H]

Hi Bill,

Have you tried using the Estimate prior entry dates option on the eligibility transaction? Might still need to adjust from time to time but on the whole it would be easier than overriding everyone's entry date -- particularly since you do a lot of takeovers.

Sue

[Guest DottleC2]

I may not have been clear that I always run estimate entry; so that when the situation arises such as the example above ee hired in 1995 was hired in part time, then changed to a full time employee in say 1997, I'm forced to override both date met _and_ date of entry for a startup plan. In other words, I only override entry for those people that had inconsistent service and entered sometime after the first two anniversaries - the Relius system can't estimate this in a startup year.

This initializing of entry fields only comes into play in startup/takeover years, and the exceptions always seem to cost the most time, so having a set method of dealing with dates that 'don't estimate' seem to render good results.

As these start-up plans mature and move onto desks that are accustomed to having data evaluated as entered, there sometimes arises situations where people need to know exactly how a particular field was calculated, example people with zero vest service. (Also, I'm reading vesting reports without ineligible participants on them ).

Bill