Time-keeping rules

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Alan Webb

    Time-keeping rules

    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
    knoNOgeek@SPAMh otmail.com
    "It's not IT, it's IS


  • Alan Webb

    #2
    Re: Time-keeping rules

    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
    knoNOgeek@SPAMh otmail.com
    "It's not IT, it's IS"

    "Chuck Grimsby" <c.grimsby@worl dnet.att.net.in valid> wrote in message
    news:ednu615q70 5t4bp6f4ct002ia 2jv0pv477@4ax.c om...[color=blue]
    > 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.[/color]


    Comment

    • Alan Webb

      #3
      Re: Time-keeping rules

      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
      knoNOgeek@SPAMh otmail.com
      "It's not IT, it's IS"

      "Chuck Grimsby" <c.grimsby@worl dnet.att.net.in valid> wrote in message
      news:ednu615q70 5t4bp6f4ct002ia 2jv0pv477@4ax.c om...[color=blue]
      > On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb"
      > <knoNOgeek@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.[/color]


      Comment

      • Alan Webb

        #4
        Re: Time-keeping rules

        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
        knoNOgeek@SPAMh otmail.com
        "It's not IT, it's IS"

        "Chuck Grimsby" <c.grimsby@worl dnet.att.net.in valid> wrote in message
        news:ednu615q70 5t4bp6f4ct002ia 2jv0pv477@4ax.c om...[color=blue]
        > On Tue, 26 Apr 2005 21:17:13 -0400, "Alan Webb"
        > <knoNOgeek@hotS PAMmail.com> wrote:[color=green]
        >>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?[/color]
        >
        > 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
        >[/color]


        Comment

        • Alan Webb

          #5
          Re: Time-keeping rules

          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
          knoNOgeek@SPAMh otmail.com
          "It's not IT, it's IS
          "Alan Webb" <knoNOgeek@hotS PAMmail.com> wrote in message
          news:fNOdnbJPMv 2OdfPfRVn-pA@comcast.com. ..[color=blue]
          > 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
          > knoNOgeek@SPAMh otmail.com
          > "It's not IT, it's IS
          >[/color]


          Comment

          • Alan Webb

            #6
            Re: Time-keeping rules

            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
            knoNOgeek@SPAMh otmail.com
            "It's not IT, it's IS
            "Chuck Grimsby" <c.grimsby@worl dnet.att.net.in valid> wrote in message
            news:gre6715rhv ipn99np82hvhons 4v1akap0b@4ax.c om...[color=blue]
            >
            > 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"
            > <knoNOgeek@hotS PAMmail.com> wrote:[color=green]
            >>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.[/color]
            >
            >
            > --
            > (A)bort, (R)etry, (S)mack The Friggin Thing
            >[/color]


            Comment

            Working...