Batch Payroll

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have a payroll database that requires a batch payroll form. I am having
a bit of trouble getting the functionality of it to work right... The source
of the form is:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber,
tblEmployees.EmpFirstName, tblEmployees.EmpMiddle, tblEmployees.EmpLastName,
tblPayroll.PayrollID, tblPayroll.EmpID, tblPayroll.PayDate,
tblPayroll.PayTypeID, tblPayroll.Hours, tblPayroll.PayRate FROM tblEmployees
INNER JOIN tblPayroll ON tblEmployees.EmpID=tblPayroll.EmpID ORDER BY
tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber;

The problem being is that I will get a seperate record for each PAYTYPEID
related to each employee... This is not what I want. I want to have a
continous form that lists the employee name, payrate, ect. as well as each
paytype on that same line... The way it is now I get a seperate line with
the employee name, payrate, ect each time...

If an employee has 40 reg hours and 10 OT hours I want:

EmpFirst EmpLast $10.00 'Regular' 40.00 'OT' 10.00

and so on... Is there a way to query the data to create a dataset like this?

Thanks,
Ernst.
 
Hi Ernst,

I'm assuming it's OK for the form to be read-only?

If that's true then this should work:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate,
Sum(RegHours([Hours],[PayTypeID])) AS Regular,
Sum(OTHours([Hours],[PayTypeID])) AS OT
FROM tblEmployees INNER JOIN tblPayroll ON tblEmployees.EmpStatusID =
tblPayroll.EmpID
GROUP BY tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate;

What you then need to do is to create the functions
RegHours(Hours,PayTypeID) and OTHours(Hours,PayTypeID)For example:

Public Function RegHours(Hours, PayTypeID) as double
If PayTypeID = 1 then
RegHours = Hours
Else
RegHours = 0
EndIf
End Function

(Assuming the 'PayTypeID' for regular hours is 1)

Good Luck - let me know if this answers your problem, and if you need any
further help.
 
I'm assuming it's OK for the form to be read-only?

No actually I want to use it as a data entry form... Best way I can
describe it is spreadsheet like... Names down the side and hour types accross
the top... I can do this quite fine if I restructure the payroll table like
so:

tblPayroll
PayrollID(PK)
EmpID(FK)
PayDate
RegHours
OTHours
VacHours
SickHours
HolHours
PerHours
PayRate

but this will not allow any future pay types... Everything I am told says
DO NOT build it this way...

Ernst.
SELECT tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate,
Sum(RegHours([Hours],[PayTypeID])) AS Regular,
Sum(OTHours([Hours],[PayTypeID])) AS OT
FROM tblEmployees INNER JOIN tblPayroll ON tblEmployees.EmpStatusID =
tblPayroll.EmpID
GROUP BY tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate;

What you then need to do is to create the functions
RegHours(Hours,PayTypeID) and OTHours(Hours,PayTypeID)For example:

Public Function RegHours(Hours, PayTypeID) as double
If PayTypeID = 1 then
RegHours = Hours
Else
RegHours = 0
EndIf
End Function

(Assuming the 'PayTypeID' for regular hours is 1)

Good Luck - let me know if this answers your problem, and if you need any
further help.


--
Laury Burr a.k.a. Doogle
data dot dynamics at virgin dot net

Ernst Guckel said:
Hello,

I have a payroll database that requires a batch payroll form. I am having
a bit of trouble getting the functionality of it to work right... The source
of the form is:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber,
tblEmployees.EmpFirstName, tblEmployees.EmpMiddle, tblEmployees.EmpLastName,
tblPayroll.PayrollID, tblPayroll.EmpID, tblPayroll.PayDate,
tblPayroll.PayTypeID, tblPayroll.Hours, tblPayroll.PayRate FROM tblEmployees
INNER JOIN tblPayroll ON tblEmployees.EmpID=tblPayroll.EmpID ORDER BY
tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber;

The problem being is that I will get a seperate record for each PAYTYPEID
related to each employee... This is not what I want. I want to have a
continous form that lists the employee name, payrate, ect. as well as each
paytype on that same line... The way it is now I get a seperate line with
the employee name, payrate, ect each time...

If an employee has 40 reg hours and 10 OT hours I want:

EmpFirst EmpLast $10.00 'Regular' 40.00 'OT' 10.00

and so on... Is there a way to query the data to create a dataset like this?

Thanks,
Ernst.
 
Ernst, hi!

Hmm, problem.

Possible solutions:

1 - to allow a single record for each employee within the relevant period,
you'd need to have a field for each type of time spent (eg 'normal',
'overtime' etc). I totally agree - not the best way forward, and it means you
(or, worse, another developer!) need to be called in every time the client
needs a different type of time coded in.

2 - set up multiple records for each employee, with one record for each type
of time recorded in the period. Yes, we're talking 'continuous forms' here.
And, unfortunately, you can't have a continuous subform within a continuous
form - therefore at any one time you'd only see one person's data.

As I see it, only option 2 is acceptable, even though it too has
disadvantages.

So each record would only contain one 'time type'. Then as I see it the
source query for the form would include the 'person table' (linked to the
tblPayroll via EmpID, I assume). The form header section could then show the
employee's name etc, with the detail section allowing date, hours, pay rate &
time type. You could set up some simple coding to copy any common data (date
and - if it's the same for all pay types - pay rate) each time you set up a
new record. You'd also have, I suggest, a separate table listing all the
valid 'time types' (normal, overtime, sick, ...) and use this to populate a
combobox for the user to select. (Make it LIMIT TO LIST = TRUE,
so that subsequent processing isn't scewed up by typos!!) You could then,
maybe, allow the user to add new time types to the lookup table, depending on
how you then derive pay from the recorded hours.

To move to other records for other employees, you could either:
- rely on tabbing through the records (by having the navigation buttons
visible);
- by having a lookup list
- by having an unbound combo with all the employee names and use its value
as the criterion for the query behind the form (plus a 'requery' button or an
'OnChange' event to force refreshing of the form data).

Unless you were using the form in 'Add Nrew Records Only' mode you'd also
need to think about filtering on date.

Is this helpful? - please let me know!

All the best

--
Laury Burr a.k.a. Doogle


Ernst Guckel said:
I'm assuming it's OK for the form to be read-only?

No actually I want to use it as a data entry form... Best way I can
describe it is spreadsheet like... Names down the side and hour types accross
the top... I can do this quite fine if I restructure the payroll table like
so:

tblPayroll
PayrollID(PK)
EmpID(FK)
PayDate
RegHours
OTHours
VacHours
SickHours
HolHours
PerHours
PayRate

but this will not allow any future pay types... Everything I am told says
DO NOT build it this way...

Ernst.
SELECT tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate,
Sum(RegHours([Hours],[PayTypeID])) AS Regular,
Sum(OTHours([Hours],[PayTypeID])) AS OT
FROM tblEmployees INNER JOIN tblPayroll ON tblEmployees.EmpStatusID =
tblPayroll.EmpID
GROUP BY tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate;

What you then need to do is to create the functions
RegHours(Hours,PayTypeID) and OTHours(Hours,PayTypeID)For example:

Public Function RegHours(Hours, PayTypeID) as double
If PayTypeID = 1 then
RegHours = Hours
Else
RegHours = 0
EndIf
End Function

(Assuming the 'PayTypeID' for regular hours is 1)

Good Luck - let me know if this answers your problem, and if you need any
further help.


--
Laury Burr a.k.a. Doogle
data dot dynamics at virgin dot net

Ernst Guckel said:
Hello,

I have a payroll database that requires a batch payroll form. I am having
a bit of trouble getting the functionality of it to work right... The source
of the form is:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber,
tblEmployees.EmpFirstName, tblEmployees.EmpMiddle, tblEmployees.EmpLastName,
tblPayroll.PayrollID, tblPayroll.EmpID, tblPayroll.PayDate,
tblPayroll.PayTypeID, tblPayroll.Hours, tblPayroll.PayRate FROM tblEmployees
INNER JOIN tblPayroll ON tblEmployees.EmpID=tblPayroll.EmpID ORDER BY
tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber;

The problem being is that I will get a seperate record for each PAYTYPEID
related to each employee... This is not what I want. I want to have a
continous form that lists the employee name, payrate, ect. as well as each
paytype on that same line... The way it is now I get a seperate line with
the employee name, payrate, ect each time...

If an employee has 40 reg hours and 10 OT hours I want:

EmpFirst EmpLast $10.00 'Regular' 40.00 'OT' 10.00

and so on... Is there a way to query the data to create a dataset like this?

Thanks,
Ernst.
 
Hmm, problem.

This is where I am... :)
Possible solutions:

1 - to allow a single record for each employee within the relevant period,
you'd need to have a field for each type of time spent (eg 'normal',
'overtime' etc). I totally agree - not the best way forward, and it means you
(or, worse, another developer!) need to be called in every time the client
needs a different type of time coded in.

This is what the end user is expecting But I REALLY DO NOT want to do this.
2 - set up multiple records for each employee, with one record for each type
of time recorded in the period. Yes, we're talking 'continuous forms' here.
And, unfortunately, you can't have a continuous subform within a continuous
form - therefore at any one time you'd only see one person's data.

I prefer this method but...
As I see it, only option 2 is acceptable, even though it too has
disadvantages.

So each record would only contain one 'time type'. Then as I see it the
source query for the form would include the 'person table' (linked to the
tblPayroll via EmpID, I assume). The form header section could then show the
employee's name etc, with the detail section allowing date, hours, pay rate &
time type. You could set up some simple coding to copy any common data (date
and - if it's the same for all pay types - pay rate) each time you set up a
new record. You'd also have, I suggest, a separate table listing all the
valid 'time types' (normal, overtime, sick, ...) and use this to populate a
combobox for the user to select. (Make it LIMIT TO LIST = TRUE,
so that subsequent processing isn't scewed up by typos!!) You could then,
maybe, allow the user to add new time types to the lookup table, depending on
how you then derive pay from the recorded hours.

I have it set up like this now but for 50+ employees payroll becomes very
time consuming... Still trying to come up with another solution... What about
puting multiple subforms side by side filtering by paytype?
To move to other records for other employees, you could either:
- rely on tabbing through the records (by having the navigation buttons
visible);
- by having a lookup list
- by having an unbound combo with all the employee names and use its value
as the criterion for the query behind the form (plus a 'requery' button or an
'OnChange' event to force refreshing of the form data).

I use this method for looking up payroll data by employee... works well for
retrieving past data....
Unless you were using the form in 'Add Nrew Records Only' mode you'd also
need to think about filtering on date.

I use a similar method in our Inventory Database...
Is this helpful? - please let me know!

Yes the information confirms some methods already in use... I have seen
some payroll database applications use a 'Batch Payroll' method but not sure
how it is done...

Thanks,
Ernst.


--
Laury Burr a.k.a. Doogle


Ernst Guckel said:
I'm assuming it's OK for the form to be read-only?

No actually I want to use it as a data entry form... Best way I can
describe it is spreadsheet like... Names down the side and hour types accross
the top... I can do this quite fine if I restructure the payroll table like
so:

tblPayroll
PayrollID(PK)
EmpID(FK)
PayDate
RegHours
OTHours
VacHours
SickHours
HolHours
PerHours
PayRate

but this will not allow any future pay types... Everything I am told says
DO NOT build it this way...

Ernst.
SELECT tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate,
Sum(RegHours([Hours],[PayTypeID])) AS Regular,
Sum(OTHours([Hours],[PayTypeID])) AS OT
FROM tblEmployees INNER JOIN tblPayroll ON tblEmployees.EmpStatusID =
tblPayroll.EmpID
GROUP BY tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate;

What you then need to do is to create the functions
RegHours(Hours,PayTypeID) and OTHours(Hours,PayTypeID)For example:

Public Function RegHours(Hours, PayTypeID) as double
If PayTypeID = 1 then
RegHours = Hours
Else
RegHours = 0
EndIf
End Function

(Assuming the 'PayTypeID' for regular hours is 1)

Good Luck - let me know if this answers your problem, and if you need any
further help.


--
Laury Burr a.k.a. Doogle
data dot dynamics at virgin dot net

:

Hello,

I have a payroll database that requires a batch payroll form. I am having
a bit of trouble getting the functionality of it to work right... The source
of the form is:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber,
tblEmployees.EmpFirstName, tblEmployees.EmpMiddle, tblEmployees.EmpLastName,
tblPayroll.PayrollID, tblPayroll.EmpID, tblPayroll.PayDate,
tblPayroll.PayTypeID, tblPayroll.Hours, tblPayroll.PayRate FROM tblEmployees
INNER JOIN tblPayroll ON tblEmployees.EmpID=tblPayroll.EmpID ORDER BY
tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber;

The problem being is that I will get a seperate record for each PAYTYPEID
related to each employee... This is not what I want. I want to have a
continous form that lists the employee name, payrate, ect. as well as each
paytype on that same line... The way it is now I get a seperate line with
the employee name, payrate, ect each time...

If an employee has 40 reg hours and 10 OT hours I want:

EmpFirst EmpLast $10.00 'Regular' 40.00 'OT' 10.00

and so on... Is there a way to query the data to create a dataset like this?

Thanks,
Ernst.
 
Hello again Ernst!

I'm not sure that multiple subforms would help much. Either you'd need s
separate subform for each paytype (in which case you're back to the problem
of needing a new subform every time a new time type was created) or you'd
need a combo on each subform to select "what type of time shall we use on
this subform this time?"

I don't think the second alternative would provide a "good user experience"!
The first could be developed maybe - how about this idea? (It's strictly 'off
the top of my head' but I think it's workable):

Have a tabbed control, with a subform on each page. Use a strict naming
convention for the page name, the page caption, the query driving each
subform, based on the name of the paytype.

Have a form whose source is the lookup table of 'time types'. Set up an
event procedure (has to be VBA - it's way beyond the scope of a macro!)
which, when a new time type is created, it AUTOMATICALLY creates a new page
for the tabbed control, a new copy of the subform to insert into it (also
creating the query to populate it), sets up the master field/child field
links, and sets the page name & caption. You'd also need to set up some
coding to trap cases where the user decides to change existing 'time type'
names since that would screw the relaterd query. Maybe just limit the form to
allow new records only.

Alternatively, and I know you'll hate me for saying this, 'bite the bullet'
and go with the client's preferences! (It's a great marketing tool to be able
to say something like "Software that works the way you want - not you working
the way the software demands!". Can I be really rude and ask why you don't
want to do it that way??!!

All the best - hear from you soon! And hope you have/had a good weekend!

--
Laury Burr a.k.a. Doogle


Ernst Guckel said:
Hmm, problem.

This is where I am... :)
Possible solutions:

1 - to allow a single record for each employee within the relevant period,
you'd need to have a field for each type of time spent (eg 'normal',
'overtime' etc). I totally agree - not the best way forward, and it means you
(or, worse, another developer!) need to be called in every time the client
needs a different type of time coded in.

This is what the end user is expecting But I REALLY DO NOT want to do this.
2 - set up multiple records for each employee, with one record for each type
of time recorded in the period. Yes, we're talking 'continuous forms' here.
And, unfortunately, you can't have a continuous subform within a continuous
form - therefore at any one time you'd only see one person's data.

I prefer this method but...
As I see it, only option 2 is acceptable, even though it too has
disadvantages.

So each record would only contain one 'time type'. Then as I see it the
source query for the form would include the 'person table' (linked to the
tblPayroll via EmpID, I assume). The form header section could then show the
employee's name etc, with the detail section allowing date, hours, pay rate &
time type. You could set up some simple coding to copy any common data (date
and - if it's the same for all pay types - pay rate) each time you set up a
new record. You'd also have, I suggest, a separate table listing all the
valid 'time types' (normal, overtime, sick, ...) and use this to populate a
combobox for the user to select. (Make it LIMIT TO LIST = TRUE,
so that subsequent processing isn't scewed up by typos!!) You could then,
maybe, allow the user to add new time types to the lookup table, depending on
how you then derive pay from the recorded hours.

I have it set up like this now but for 50+ employees payroll becomes very
time consuming... Still trying to come up with another solution... What about
puting multiple subforms side by side filtering by paytype?
To move to other records for other employees, you could either:
- rely on tabbing through the records (by having the navigation buttons
visible);
- by having a lookup list
- by having an unbound combo with all the employee names and use its value
as the criterion for the query behind the form (plus a 'requery' button or an
'OnChange' event to force refreshing of the form data).

I use this method for looking up payroll data by employee... works well for
retrieving past data....
Unless you were using the form in 'Add Nrew Records Only' mode you'd also
need to think about filtering on date.

I use a similar method in our Inventory Database...
Is this helpful? - please let me know!

Yes the information confirms some methods already in use... I have seen
some payroll database applications use a 'Batch Payroll' method but not sure
how it is done...

Thanks,
Ernst.


--
Laury Burr a.k.a. Doogle


Ernst Guckel said:
I'm assuming it's OK for the form to be read-only?

No actually I want to use it as a data entry form... Best way I can
describe it is spreadsheet like... Names down the side and hour types accross
the top... I can do this quite fine if I restructure the payroll table like
so:

tblPayroll
PayrollID(PK)
EmpID(FK)
PayDate
RegHours
OTHours
VacHours
SickHours
HolHours
PerHours
PayRate

but this will not allow any future pay types... Everything I am told says
DO NOT build it this way...

Ernst.

SELECT tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate,
Sum(RegHours([Hours],[PayTypeID])) AS Regular,
Sum(OTHours([Hours],[PayTypeID])) AS OT
FROM tblEmployees INNER JOIN tblPayroll ON tblEmployees.EmpStatusID =
tblPayroll.EmpID
GROUP BY tblEmployees.EmpStatusID, tblEmployees.EmpFirstName,
tblEmployees.EmpLastName, tblPayroll.PayRate;

What you then need to do is to create the functions
RegHours(Hours,PayTypeID) and OTHours(Hours,PayTypeID)For example:

Public Function RegHours(Hours, PayTypeID) as double
If PayTypeID = 1 then
RegHours = Hours
Else
RegHours = 0
EndIf
End Function

(Assuming the 'PayTypeID' for regular hours is 1)

Good Luck - let me know if this answers your problem, and if you need any
further help.


--
Laury Burr a.k.a. Doogle
data dot dynamics at virgin dot net

:

Hello,

I have a payroll database that requires a batch payroll form. I am having
a bit of trouble getting the functionality of it to work right... The source
of the form is:

SELECT tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber,
tblEmployees.EmpFirstName, tblEmployees.EmpMiddle, tblEmployees.EmpLastName,
tblPayroll.PayrollID, tblPayroll.EmpID, tblPayroll.PayDate,
tblPayroll.PayTypeID, tblPayroll.Hours, tblPayroll.PayRate FROM tblEmployees
INNER JOIN tblPayroll ON tblEmployees.EmpID=tblPayroll.EmpID ORDER BY
tblEmployees.EmpStatusID, tblEmployees.EmployeeNumber;

The problem being is that I will get a seperate record for each PAYTYPEID
related to each employee... This is not what I want. I want to have a
continous form that lists the employee name, payrate, ect. as well as each
paytype on that same line... The way it is now I get a seperate line with
the employee name, payrate, ect each time...

If an employee has 40 reg hours and 10 OT hours I want:

EmpFirst EmpLast $10.00 'Regular' 40.00 'OT' 10.00

and so on... Is there a way to query the data to create a dataset like this?

Thanks,
Ernst.
 
Have a tabbed control, with a subform on each page. Use a strict naming
convention for the page name, the page caption, the query driving each
subform, based on the name of the paytype.

just don't see tnat working for the client...
Alternatively, and I know you'll hate me for saying this, 'bite the bullet'
and go with the client's preferences! (It's a great marketing tool to be able
to say something like "Software that works the way you want - not you working
the way the software demands!". Can I be really rude and ask why you don't
want to do it that way??!!

Sure... I am developing the payroll application for a company that has 700
employees in 23 locations... about 30 per location... implementing the
software the first time is a nightmare to begin with but to have to update
the Back-End because of a table structure change? Oh my... DO NOT want to
have to be there...

So how's this for an idea... create the table with say about 15 pay types
and name them PayType1 PayType2 and so on and just have a seperate table that
allows you to name them for Label perposes? Might this be feasable?

Thanks,
Ernst.
 
Hi Ernst

Given your other comments I think your idea (15 or so fields named paytype1,
paytype2 etc) is the best solution. You could then set up the forms etc so
that any paytype without a 'label' field doesn't display on the main input
screens. Then all you'd need is an 'admin' form (only accessible to ceretain
key personnel) for the paytype 'label' to be entered.

There's at least one accounting package in the UK that uses this approach
for some of its features (namely, has 'spare' fields which the user then
customiuses by adding their own 'label' fieldnames.)

Good luck - let me know how it goes!
 
Back
Top