Calculated field in Forms

  • Thread starter Thread starter dar
  • Start date Start date
D

dar

Hello-
I would like to see how I can add a calcualted field to my forms that would
show me when an employee is eligible for benefits. I have employee who
qualify in 30 days, others are 90 days.

Your help is appreciated!
Thank you,
 
Hello-
I would like to see how I can add a calcualted field to my forms that would
show me when an employee is eligible for benefits. I have employee who
qualify in 30 days, others are 90 days.

Your help is appreciated!
Thank you,
Click to expand...

30 days from.... what? Hiredate? How can you determine (from data in the
table) whether it should be 30 or 90 days? What do you want to see on the
form: a date, the word ELIGIBLE in a textbox, both, something else?

Remember - we know nothing about either your business or your database except
what you tell us.
 
One option would be to create a query based on the relevant table
then add a calculated field to the query. You would then use the query
as the record source of the form. You could also put a calculated control
on the form, but, depending on the design of the form, the query
may be the better choice.

It's difficult to give much advice on how to calculate the value you
need since we don't know anything about your tables/data, but it
might look something like the following (as a calculated field
in a query);

EligibleDate: IIf([EmployeeType] = "Full Time", DateAdd("d", 30, [HireDate],
DateAdd("d", 90, [HireDate]))

(the above would be all on one line in the field row of a column in
the query design grid).
 
You omitted some information so I will guess. You need a HireDate and
Eligible field with the number of days, or a category for eligiblity.

With Eligible field having number of days for eligibility --
Benefits Eligible: IIF(DateDiff("d", HireDate, Date()) >= [Eligible],
"Yes", [Eligible] - DateDiff("d", HireDate, Date()) & " Days")

For a category in the Eligible field then you need an IIF statement to
translate category to days or a table to do it if you have a lot of different
possibilities.
 
Hello, yes I will have the below fields that you mentioned.

KARL DEWEY said:
You omitted some information so I will guess. You need a HireDate and
Eligible field with the number of days, or a category for eligiblity.

With Eligible field having number of days for eligibility --
Benefits Eligible: IIF(DateDiff("d", HireDate, Date()) >= [Eligible],
"Yes", [Eligible] - DateDiff("d", HireDate, Date()) & " Days")

For a category in the Eligible field then you need an IIF statement to
translate category to days or a table to do it if you have a lot of different
possibilities.

--
Build a little, test a little.


dar said:
Hello-
I would like to see how I can add a calcualted field to my forms that would
show me when an employee is eligible for benefits. I have employee who
qualify in 30 days, others are 90 days.

Your help is appreciated!
Thank you,
Click to expand...
Click to expand...
 
Yes, managers are 30 days from hire date, clerks are 90 days from hire date.
Click to expand...

That's a business rule.

It's not a database rule.

I can see how you would enforce that in your office, but since you have chosen
not to post any information about your tables, I cannot tell how you would
enforce it in a database.

I'd love to be able to help, but I can't unless you tell me what's in your
database!
 
Sorry about that I am new to this forum.

Tabel: Employee

My fields are:
LName
FName
Hire Date

I would like to set the rule based off of the Hire date.
 
John i forgot the other fields

Table: Employee
LName
FName
Hire Date
Office Staff 30 days for eligibilty from hire date
Transport 30 days for eligibility from hire date
Manager 30 days for eligibility from hire date
Maint 30 days fro eligibilty from hire date
Clerk 90 days for eligibility from hire date

Will this help?
Thank you John
 
On my last reply I forgot to put the Eligibility date goes with the info on
put on the titles. Office, transport etc. Eligibility date will be based
off the hire date.
 
John i forgot the other fields

Table: Employee
LName
FName
Hire Date
Office Staff 30 days for eligibilty from hire date
Transport 30 days for eligibility from hire date
Manager 30 days for eligibility from hire date
Maint 30 days fro eligibilty from hire date
Clerk 90 days for eligibility from hire date
Click to expand...

This isn't making sense. Does each employee have a Office Staff field, a
Transport field, a Manager field??? What is contained in this field - a date?
If an employee is a clerk, why does she need a Transport field?
 
I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?

Thank you
 
I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?
Click to expand...

Again:

What is the datatype of hiredate30 and hiredate90?
Does every employee have a Hiredate30 and also a Hiredate90?
If so why?

I really think you may be misunderstanding how tables work. They're not
spreadsheets! A Table represents a particular type of Entity - real-life
person, thing or event. Each Field in the table contains the value of some
specific Attribute of that entity - the person's FirstName, their LastName,
their HireDate, their PositionID and so on. If you have several mutually
exclusive attributes (i.e. if someone has a Hiredate30 then their Hiredate90
must be blank), your table structure is wrong.

I don't understand your business model, but if you'll allow me to grope in the
dark with a possible idea... consider the following tables:

Employees
EmployeeID <autonumber primary key>
LName
FName
HireDate
PositionID

Positions
PositionID <autonumber primary key>
Position <e.g. Clerk, Manager, High Muckamuck>
DaysToEligibility

You could then create a query joining these two tables and calculate the
eligible date. The SQL view of the query (copy and paste it into a new query's
SQL view) would be

SELECT LName, FName, DateAdd("d", [DaysToEligibility], [HireDate]) AS
DateEligible
FROM Employees INNER JOIN Positions
ON Employees.PositionID = Positions.PositionID;

You can put criteria on the DateEligible calculated field if that's what
you're trying to do.
 
This isn't making sense. Does each employee have a Office Staff field, a
Transport field, a Manager field??? What is contained in this field - a date?
If an employee is a clerk, why does she need a Transport field?
Click to expand...
 
I have either an employee who will qualify in 30 and other in 90 days. When
the data entry person enters the information she will either enter their hire
date in the HireDate30 or the HireDate90. Based off of the Hire date info i
want it to calculate in the BenifitsEligibilityDate.

John W. Vinson said:
I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?
Click to expand...

Again:

What is the datatype of hiredate30 and hiredate90?
Does every employee have a Hiredate30 and also a Hiredate90?
If so why?

I really think you may be misunderstanding how tables work. They're not
spreadsheets! A Table represents a particular type of Entity - real-life
person, thing or event. Each Field in the table contains the value of some
specific Attribute of that entity - the person's FirstName, their LastName,
their HireDate, their PositionID and so on. If you have several mutually
exclusive attributes (i.e. if someone has a Hiredate30 then their Hiredate90
must be blank), your table structure is wrong.

I don't understand your business model, but if you'll allow me to grope in the
dark with a possible idea... consider the following tables:

Employees
EmployeeID <autonumber primary key>
LName
FName
HireDate
PositionID

Positions
PositionID <autonumber primary key>
Position <e.g. Clerk, Manager, High Muckamuck>
DaysToEligibility

You could then create a query joining these two tables and calculate the
eligible date. The SQL view of the query (copy and paste it into a new query's
SQL view) would be

SELECT LName, FName, DateAdd("d", [DaysToEligibility], [HireDate]) AS
DateEligible
FROM Employees INNER JOIN Positions
ON Employees.PositionID = Positions.PositionID;

You can put criteria on the DateEligible calculated field if that's what
you're trying to do.
Click to expand...
 
I have either an employee who will qualify in 30 and other in 90 days. When
the data entry person enters the information she will either enter their hire
date in the HireDate30 or the HireDate90. Based off of the Hire date info i
want it to calculate in the BenifitsEligibilityDate.
Click to expand...

Sorry, but that's INCORRECT DESIGN.

The person's hire date is their hire date, and it should be in the HireDate
field... and noplace else.

You need to have in your database, somewhere, the information that will
distinguish a 30 day employee from a 90 day employee. I'm *guessing* that
information is implied by the position into which that employee is hired; that
guess was the source of my previous suggestion.

Rather than having two unnecessary and redundant fields in your table, just
store the 30 or 90 days someplace - in the positions table, in the employee
table, even just as a combo box on a form - and *CALCULATE* the
BenefitsEligibilityDate using DateAdd. It is unnecessary and inappropriate to
store that date in any table (unless you want to make exeptions, say to make
the boss's nephew eligible in three days instead of ninety).
 
Thank you I will try that.

John W. Vinson said:
Sorry, but that's INCORRECT DESIGN.

The person's hire date is their hire date, and it should be in the HireDate
field... and noplace else.

You need to have in your database, somewhere, the information that will
distinguish a 30 day employee from a 90 day employee. I'm *guessing* that
information is implied by the position into which that employee is hired; that
guess was the source of my previous suggestion.

Rather than having two unnecessary and redundant fields in your table, just
store the 30 or 90 days someplace - in the positions table, in the employee
table, even just as a combo box on a form - and *CALCULATE* the
BenefitsEligibilityDate using DateAdd. It is unnecessary and inappropriate to
store that date in any table (unless you want to make exeptions, say to make
the boss's nephew eligible in three days instead of ninety).
Click to expand...
 
Back
Top