435,190 Members | 1,063 Online
Need help? Post your question and get tips & solutions from a community of 435,190 IT Pros & Developers. It's quick & easy.

# Time-keeping rules

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS Nov 13 '05 #1
5 Replies

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS" "Chuck Grimsby" wrote in message news:ed********************************@4ax.com... 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. Nov 13 '05 #2

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS" "Chuck Grimsby" wrote in message news:ed********************************@4ax.com... On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb" 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. Nov 13 '05 #3

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS" "Chuck Grimsby" wrote in message news:ed********************************@4ax.com... On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb" wrote:Regular Hours are any hours less than the number of hours that can beworkedbefore the hours begin to be counted as overtime in the period.Overtime Hours are any hours more than the number of hours that can beworked 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 andtwelve hours is overtime and anything more than twelve hours isdoubletime.This one is easy and I have three functions that work together to give methe 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 areanything less than the regular hour limit.It's overtime and doubletime per week that is frying my brain. I tend toovercomplicate things and at the moment I have a contorted If End ifconstruct that looks at four break points. The first is the regular hourslimit, the second is regular hours limit plus eight, the third is theovertime limit less eight and the fourth is the overtime limit. I havedifferent arithmetic depending on how many hours that week and where thattotal falls in my four break points. Is there a simplier logic &companionarithmetic? 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 Nov 13 '05 #4

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS "Alan Webb" wrote in message news:fN********************@comcast.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*******@SPAMhotmail.com "It's not IT, it's IS Nov 13 '05 #5

 P: n/a 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*******@SPAMhotmail.com "It's not IT, it's IS "Chuck Grimsby" wrote in message news:gr********************************@4ax.com... 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" wrote:Once I get something I am happy with I'll post documentation on what Idecided. I was really hoping to have someone step up and tell me what thetypical best practice solution is. I get paid by my employer with payrollsoftware so at least one bunch of programmers has solved this in a waythatworks. It would be nice to know what logic my boss' software uses. -- (A)bort, (R)etry, (S)mack The Friggin Thing Nov 13 '05 #6

### This discussion thread is closed

Replies have been disabled for this discussion.