Census Input for Ineligibles, and if deemed an override.

[Guest DottleC2]

My question is whether or not I'm keying Term inels properly, or if there's a better way.

We have six fields that we use to set up a matrix for status overrides data entry at year end for plans. Entry Date Overide, Stat Date, Emp Stat, Plan Cat, Reason Inel, and Term Date.

The hitch is that the person doing the input seems to have to determine whether or not an employee that terminated is in fact ineligible. It seems like Relius should be making that decision.

A complicating factor is that internally, one of the requirements that we have tried to adhere to is that input has to be done the same way in the case of a plan that is running for the first time on Relius, as in subsequent plan years. In other words, the matrix used for data entry at year end has to remain the same for takeover plans, versus _ongoing_ plans.

Description Term Ineligible *

Entry Date ORide - Not applicable

Status Date - 07/01/2002

Employee Stat - 'T'

Plan Cat - Inel

Reason Code - B

Term Date - 07/01/2002

*Example uses an employee Hired 01/01/2002, Term Inel 07/01/2002, 1 yr svc requir't assumed

I set hours for entry as follows:

init 0 0 0 0 0

cred 1k 1k 1k 1k

vest 1k 1k 1k 1k

Does that look right? The term date won't show unless it's keyed.

Thanks in advance,

Bill

[Tom Poje]

In Relius the census element 'term date' refers to termination from the plan, and thus should only be populated if an employee was actually in the plan.

The only census elements you would normally enter would be Status Date and status. by running eligibility the system should populate all other fields - category, term date, entry date, etc.

The only exception would be a takeover case, in which other fields should be populated, mainly for terminees in a prior year (or period)

click on Help, type 'takeover plans' and then choose

census data required.

These will tell you exactly what fields you should be entering.

[pmacduff]

Bill - I actually changed the Employee Status report format so that the status for those who terminate before entering the plan show a status of "Terminated Ineligible". Like Tom says, I let the system work as normal on all the data fields, and I have just manipulated my reports to show the status I wanted. I did something in Crystal like - "If category = "Ineligible" (or "8") & Status = "Terminated" (or "T") & Status Date >0, then category = "Terminated Ineligible". This way Relius is doing the calculation, I am just using my own terminology for the reports. Would this work for what you need? Hoped it might help...Patti

[Guest DottleC2]

Good viewpoints, but I'm still hammering. Term date isnt showing for term inels unless term date is posted as an override _before_ the last valuation transaction. There isn't any help file info on this particular subject. The bible that we use is found in help files by searching on Rules for entering Census data.

My first reflex Patti also was to continue on that route of changing the report to reflect term date - having already changed to the more descriptive 'term inel' status showing on the report, we thought of going one step further and calculating a term date.

However that would be forcing data that wasn't actually there. In other words, if term date isn't in the term date field for term inels, then the administrator has to commit to importing it and posting as an override.

An override by the way is defined in our/my world as Data Entered After The First Eligibility transaction, there being two eligibility transactions for each val period, one at the beginning, one at the end.

Because the term date isn't showing up for term inels, the census report isn't really a census report any more, it is an eligibility calculation report. In the long run, it may be easier to just delete term inels immediately before finalizing the report.

And the argument that a census report shouldn't contain any calculated fields in an effort to normalize the data doesn't fly either - there are several calculated fields (albeit ones that nobody ever looks at, like Retirement age.)

You can see the dilemma; yes, one can reasonably conclude that a term inel isn't terminated from 'The Plan', but then why have hours and comp on the census, and, what will the Client see. The census report that we use probably shows too much.

Bill

[pmacduff]

Good points, too Bill - I forgot that I actually use the "Status Date" for term date in my reports, not the formal term date (which doesn't update until the plan year end). Again - I modified the report to only show the "Status Date" (ie., term date) when the status code is "Terminated" by using a formula in the field. That way, when you have a status date for rehires or newly eligibles, etc., it doesn't print out the status date, only for my terms and term ineligibles.

[Guest DottleC2]

<<"Status Date" for term date in reports, not the formal term date (which doesn't update until the plan year end). >>

That would seem the route to take. I wish the Relius RW Reports had Status Date as term date. Frequently the RW reports are used to check things after a transaction is run (at year end) and it would be nice to mirror Custom reports with RW reports.

Bill

[Tom Poje]

good grief, I show both status date and term date. that way when someone gets paid out he will have status Z, a status date, and his old term date.

But then, I always have been a bit twisted.

enclosed is report for non 401k plan (no deferrals are listed)

count at bottom of report will be total census

then total ineligibles and a net census, I figure that should be the number of bodies on the billing.