Time-keeping rules

[Alan Webb]

Guys,
I get this:

Regular Hours are any hours less than the number of hours that can be worked
before the hours begin to be counted as overtime in the period.

Overtime Hours are any hours more than the number of hours that can be
worked as regular hours in the period.

Doubletime is similar to overtime but at a higher limit.

If we are doing this on a per day period then anything between eight and
twelve hours is overtime and anything more than twelve hours is doubletime.
This one is easy and I have three functions that work together to give me
the numbers I want for counting regular, overtime and double-time per day.

And if we are counting by week it's still similar: regular hours are
anything less than the regular hour limit.

It's overtime and doubletime per week that is frying my brain. I tend to
overcomplicate things and at the moment I have a contorted If End if
construct that looks at four break points. The first is the regular hours
limit, the second is regular hours limit plus eight, the third is the
overtime limit less eight and the fourth is the overtime limit. I have
different arithmetic depending on how many hours that week and where that
total falls in my four break points. Is there a simplier logic & companion
arithmetic?

--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS

[Alan Webb]

Chuck,
I built a table called PROJECT that contains attributes of each employee's
job. Since I've done contract work in the past I built it with the
assumption that an employee under the same employer could work on different
projects at different pay rates, compensation packages, etc. I include a
ParentProject column so I can run PaidTimeOff under a primary
project/employer and allow for changes in compensation over time.

My current idea is something like:

If WeekTotalHours >= RegLimit and WeekTotalHours < (RegLimit + 8) Then
'Some of this day's hours may be overtime.
OTHours = WeekTotalHours = RegLimit
ElseIf WeekTotalHours >= (RegLimit + 8) And WeekTotalHours < OTLimit Then
'Everything is overtime.
Else
'Nothing is overtime.
End If

This is in a class module as a Property Get statement called OTHours. The
hope was that the class would contain all the business rules and simplify
things for other programmers because you could just create an instance of
this class, give it the data it needs to figure all this out, and get back
the correct numbers. I was hoping to find a simpler, more elegant bit of
logic than my own so suggestions are still appreciated.
--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS"

"Chuck Grimsby" <c.*******@worl dnet.att.net.in valid> wrote in message
news:ed******** *************** *********@4ax.c om...

On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb"

The last time that I did something like this, it was a convoluted mess.

[Alan Webb]

Chuck,
To save myself the processor time needed to run this each time a user wants
it I have a trigger built in to the Hours data entry form which kicks off a
procedure to post the totals to a table. This way reports can be run
against the table and until my user comes up with a contorted request for a
view that supports their analyis--"Give me total hours for all employees
that have Aries as thier Moon Sign and the Sun was in Mercury or they have a
first name of Star and they earn more than 10% of scale but worked less than
full-time in quarter 3 of 1927"--the SQL needed is easier and consequently
faster.

--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS"

"Chuck Grimsby" <c.*******@worl dnet.att.net.in valid> wrote in message
news:ed******** *************** *********@4ax.c om...

On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb"
<kn*******@hotS PAMmail.com> wrote:
The solution was to separate the data-entry task from the calculation
task, and handle
each employee as a separate entity, "walking" the recordset(s) to do
each sum of period for each "employee", depending upon what "type" of
an employee they were.

[Alan Webb]

Guys,
Once I get something I am happy with I'll post documentation on what I
decided. I was really hoping to have someone step up and tell me what the
typical best practice solution is. I get paid by my employer with payroll
software so at least one bunch of programmers has solved this in a way that
works. It would be nice to know what logic my boss' software uses.
--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS"

"Chuck Grimsby" <c.*******@worl dnet.att.net.in valid> wrote in message
news:ed******** *************** *********@4ax.c om...

On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb"
<kn*******@hotS PAMmail.com> wrote:

Regular Hours are any hours less than the number of hours that can be
worked
before the hours begin to be counted as overtime in the period.
Overtime Hours are any hours more than the number of hours that can be
worked as regular hours in the period.
Doubletime is similar to overtime but at a higher limit.
If we are doing this on a per day period then anything between eight and
twelve hours is overtime and anything more than twelve hours is
doubletime.
This one is easy and I have three functions that work together to give me
the numbers I want for counting regular, overtime and double-time per day.
And if we are counting by week it's still similar: regular hours are
anything less than the regular hour limit.
It's overtime and doubletime per week that is frying my brain. I tend to
overcomplicat e things and at the moment I have a contorted If End if
construct that looks at four break points. The first is the regular hours
limit, the second is regular hours limit plus eight, the third is the
overtime limit less eight and the fourth is the overtime limit. I have
different arithmetic depending on how many hours that week and where that
total falls in my four break points. Is there a simplier logic &
companion
arithmetic?

The last time that I did something like this, it was a convoluted
mess. I suspect that you're in the same situation. The solution was
to separate the data-entry task from the calculation task, and handle
each employee as a separate entity, "walking" the recordset(s) to do
each sum of period for each "employee", depending upon what "type" of
an employee they were.

--
(A)bort, (R)etry, (S)mack The Friggin Thing

[Alan Webb]

Guys,
What I found to work in Excel was to keep a running total by week of the
number of hours worked. Then if the running total was between forty and
forty eight hours some of that day's hours were regular time and some were
overtime. Similarly, if the running total for that week was between sixty
and sixty-eight hours some of the day's hours were overtime and some were
doubletime. The only other cases I needed to worry about were hours that
fell below the threshold and hours that exceeded the threshold plus eight
hours. A running total less than forty hours and everthing was overtime. A
running total between forty-eight and sixty hours and everything is overtime
for that day. A running total that was more than sixty-eight hours and
everything is double-time. The rest of the possibilities all return zero in
my logic.
I have three business rules implemented in three Property Get statements
that contain the above logic. I gave up the idea of trying to run all this
each time the timesheet report is run and am keeping these numbers in a
table. My data entry form has an event which triggers a bit of VBA that
posts a new row to my totals table for each employee/project/day worked. On
the output side I use my results table to slice & dice the data to my
heart's content.
It works, it isn't perhaps the prettiest way to do this, but I am happy with
it for now. I still hope someone else out there knows what the accepted
best practice is.

--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS
"Alan Webb" <kn*******@hotS PAMmail.com> wrote in message
news:fN******** ************@co mcast.com...

Guys,
I get this:

Regular Hours are any hours less than the number of hours that can be
worked before the hours begin to be counted as overtime in the period.

Overtime Hours are any hours more than the number of hours that can be
worked as regular hours in the period.

Doubletime is similar to overtime but at a higher limit.

If we are doing this on a per day period then anything between eight and
twelve hours is overtime and anything more than twelve hours is
doubletime. This one is easy and I have three functions that work together
to give me the numbers I want for counting regular, overtime and
double-time per day.

And if we are counting by week it's still similar: regular hours are
anything less than the regular hour limit.

It's overtime and doubletime per week that is frying my brain. I tend to
overcomplicate things and at the moment I have a contorted If End if
construct that looks at four break points. The first is the regular hours
limit, the second is regular hours limit plus eight, the third is the
overtime limit less eight and the fourth is the overtime limit. I have
different arithmetic depending on how many hours that week and where that
total falls in my four break points. Is there a simplier logic &
companion arithmetic?

--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS

[Alan Webb]

Chuck,
Ok. I understand that. So I didn't build something thinking it would be
used to pay people with. Mostly I wanted it so I could track my hours and
get a feel for how much my next paycheck would be. Within the limited scope
of estimating my next paycheck it works well enough. I worked for a few
months with Again Technologies, who had a product that they marketed which
would do payroll for employees that were compensated with some sort of
variable pay. I am aware of the potential complexities. So, I punted and
built something that would work for me and not necessarily for a company.
Even with that limited scope it is taking me a while to debug my stuff and
get it working to my satisfaction.
--
Alan Webb
kn*******@SPAMh otmail.com
"It's not IT, it's IS
"Chuck Grimsby" <c.*******@worl dnet.att.net.in valid> wrote in message
news:gr******** *************** *********@4ax.c om...

Payroll software is interested, but it's almost never a "hard and
fast" set of rules. There are many, many variables, and (just so you
know) setting up "canned" payroll software can take _weeks_ of work to
implement. There are very, very few rules that translate from one
company to another.

Payroll is as unique a job path as just about any other form of
accounting, like Tax Accounting. In both cases, 1 + 1 doesn't always
= 2, or 11 for that matter. Too many other "hidden" variables apply.

On Wed, 27 Apr 2005 19:38:25 -0400, "Alan Webbed"
<kn*******@hotS PAMmail.com> wrote:

Once I get something I am happy with I'll post documentation on what I
decided. I was really hoping to have someone step up and tell me what the
typical best practice solution is. I get paid by my employer with payroll
software so at least one bunch of programmers has solved this in a way
that
works. It would be nice to know what logic my boss' software uses.

--
(A)bort, (R)etry, (S)mack The Friggin Thing