Clock in / out

[Torturednacho]

I'm making this for my brothers small business.
He wants a simple clock in/out
I created a form with 2 buttons In and Out
But I'm not into scripting. I want the Clock in to Pull up a Dialog box where the employee would enter in their empid then it would clock them in
On the clock out
I want it to pull up a form
That will clock them out after they enter in a couple peices of information.
However inside this form I need to place a yes/no box.
If employee has expenses (check box yes) then another form comes up to place in the req. information
I know I need to link the YES/NO box to the table with the fields i need. I'm not worried to much about that 1. My big problem is the scripting the clock in/out

Can anyone help me on this please?

 

[kjv1611]

Hmm, are you sure they don't need a password for clocking in/out, seeing as how anyone could type in anyone else's userid?

--

"If to err is human, then I must be some kind of human!" -Me

 

[Torturednacho]

No, It's a very small company and right now its all friends. So something like that wouldn't happen. Since it's a very time sensitive business, we would know if something like that happened. ... But a password has nothing to do with my question at hand.

 

[kjv1611]

Actually, I very much disagree with your last post:
1. Mixing family and friends is a VERY GOOD reason to include passwords. There's a reason that the saying, "never mix business with family." has been around for so long.

2. A password has EVERYTHING to do with your question at hand. Generally, people on these forums don't just say, okay, click this, that, yer done. We all tend to work together, with what information we have available, to offer the best possible solution as advice. The design and methodology of a database or application is probably THE most important piece. The reason? That's your foundation. If the foundation is crummy, then it doesn't matter how good the rest is, it's going to fall/break.

--

"If to err is human, then I must be some kind of human!" -Me

 

[adalger]

scripting the clock in/out" depends very much on what you want to do with the information. To do it *right*, you'll want to design your app so it remains useful if your brother's business is successful to the point that he needs more employees than he has friends than can be implicitly trusted with the ability to alter each other's time records.

At the very least, you'll want to defensively program against someone mistyping their id and clocking someone else out, because the consequences of that could range anywhere from a few moments of confusion to arguments, lawsuits, and permanently destroying friendships and possibly the business itself.

This consideration will have implications that need to be addressed as part of the decision of what to do with the data, and if you're storing it in a table, what columns that table has. It also makes a difference whether everyone's using the same computer, or the same database on a networked drive, or local copies of a front end with a shared back end.

TMTOWDI - it's not just for Perl any more

 

[Golom]

Aside from the Password/NOT Password issue, you also need to consider the purpose of this information.

If, as in many companies, you want to use it for payroll purposes, then a whole mess of issues come up. Just off the top of my head

- What happens when someone fails to clock in or out?

- Are you allowed to perform the same action twice in succession ... that is can you (for example) clock out twice in succession without clocking in?

- Are there specific times that people are supposed to start or leave work? If so, is there a grace period when they are counted as being "on time"?

- Is this going to tied to some employee scheduling function? If it is, can you clock in even if you are not scheduled to work?

These issues are just for starters. You need to be keenly aware that anything that potentially affects people's paycheck needs to be very well thought through and completely auditable.

 

[redwoodly]

Just to answer your question, without going into the implications of doing it one way or another:

Have your two buttons (in & out) on your start form open a modal form (let's call it frmClock) in ADD mode and pass it an arguement (in or out) depending on which button they click.

so for your cmdIN button, in the CLICK EVENT:

DoCmd.OpenForm "frmClock", acNormal, , , acFormAdd, acDialog, "In"

For your cmdOut button, in the Click Event:

DoCmd.OpenForm "frmClock", acNormal, , , acFormAdd, acDialog, "Out"

frmClock should have 4 fields from your table: id (autonumber), empid (control = txtEmpId), timein (date/time field, control = txtTimeIn), timeout (date/time field, control = txtTimeOut)....with txtEmpId being the only control visible on your form (the rest are NOT visible).

in the txtEmpid - afterupdate event:
add something like:

If Not IsNull(Me!txtEmpid) Then
    strInOut = Forms!frmClock.OpenArgs
    If Len(strInOut) > 0 Then
        If strInOut = "In" Then
            Me!txtIn = Now()
        ElseIf strInOut = "Out" Then
            Me!txtOut = Now()
        End If
    End If
End If

 

[redwoodly]

oops - forgot something - that last bit of code
in the txtEmpid - afterupdate event should be:

Dim strInOut as string
If Not IsNull(Me!txtEmpid) Then    
    strInOut = Forms!frmClock.OpenArgs
    If Len(strInOut) > 0 Then
        If strInOut = "In" Then
            Me!txtIn = Now()
        ElseIf strInOut = "Out" Then
            Me!txtOut = Now()
        End If
    End If
End If