Why is there a field value to track a LaborDtl ClockIn date… but none for a ClockOut date?
Better yet – is there a hidden/magical way to obtain a clock-out date value?
Why is this important to me?
– Some of our production processes run on mill resources that start before midnight and end after midnight.
– We will be tracking 2nd-shift labor that may start before midnight and end after midnight
Can’t you use ClockOutMinute?
The system puts all of the labor on the date that you clock in. I think it will still get the total number of hours, but it won’t split them between 2 dates.
edit:
actually, this field should get all you need.
The idea on how this works is that you clock in and out within one 24 hour period of time, so there should never be a need to have a clock-out date. Even if you are on the late-night shift, you clock in at 9:00 PM on 4/19, you will clock out at 6:00 AM the next day (assumed 4/20). The system keeps track of how long you were clocked in.
Note that it is vital that everyone clocks out every day.
If you need to get the clock out date, you can use:
dateadd(minute,ClockOutMinute,‘1953-10-30’)
@AndrewM / @Banderson / @timshuwy :
I think I’m still a bit confused, but I’ll take a better look at the values sitting in the ClockOutMinute field and see if it’ll clear the cob-webs. I’ll let you guys know (likely tomorrow) if I’m back on the right path. I think it’ll be clearer for me when I align everyone’s input with what I’m seeing directly in the [LaborDtl] table.
Also, @timshuwy — I see you’ve been practicing for your upcoming gig at the comedy club:
“Note that it is vital that everyone clocks out every day.”
Ha! Funny guy… 
I was wondering about this too.
What about using shifts?
Someone is legitimately working for more than 24 hours? If not, put in something to automatically clock people out.
To make reporting and date comparisons simpler I created a UD Field CLockOUtDate_c (with all the screwy camel casing so it looked native 
) and added a data directive that fills that field on clock out. It’s nice to not have to do calculations all the time especially if you are then using those calculated dates on other calculations. Just makes life easier, low overhead, and simple.
I was thinking of this approach, as well - as I had used a similar method to record the date when a DMR is closed (seems Epicor has a voodoo-aversion to recording “out”, “closed”, “finished”, “done”, “over”, “kaput”, or “I quit” types of activity).
Anyway, I tried to trace clock-outs through the MES module and seemed to have a bit of trouble. I t-h-i-n-k the BO and method is:
businessObject : Erp.Proxy.BO.LaborImpl
methodName : Update
… but I cannot confidently validate this.
If you have already been through this exercise (using a UD “ClockOutDate_c” field), would you mind sharing the salient data directive logic illustration that you implemented?
Not to take anything away from what the other contributors have already addressed in this thread (which I am still trying to wrap my head around), it’s just, for me, a simple clock-out date is easier to address concerning internal labor reporting.
Additional Notes:
[1] We cannot rely, to any trustworthy degree, on employees clocking out… at all. Even if we enlisted HR to send a company-wide announcement that - should you continue to fail to clock out of your operations, you will be fired immediately, taken out to the woodshed for a beating, and fined $100,000 USD - there will be absolutely no change in the clock-out failure rate.
[2] Because of point [1], there will always be labor records extending past midnight, or past 24 hours, or 48 hours, or until someone notices it during month-end Accounting processes.
[3] Why don’t we simply auto-clock-out open operations? Well… we’ve tried that strategy but, I remember that, in doing so, we caused a fair amount of headaches for Accounting (I don’t recall the specifics). In addition, we had no true way of determining if a labor record should be clocked out automatically based on human forgetfulness versus a labor record that is intended to run past a typical 8-hour shift… not to mention we had some personnel resources working 5-8s and some working 4-10s… and then there’s the concept of “mandatory overtime”. It was way more conditional logic than it was worth.
A data directive is on a table, not a method
make the logic that if they are clocked in for more than 16 hours, or whatever the longest legal shift is. Then send an e-mail on that they were auto clocked out and go fix the error. (because the time will be wrong). The run it on a schedule every hour or something.
I misspoke I don’t have it on a data directive but on the EmpBasic.ClockOut method. Just setting it in preprocess.
I do the same for LaborDtl but on Labor.Update if end activity is true I set my clock out UD field.
We also implemented this method. After 14 hours we auto clock out and mark a UDField on LaborHed (MissedPunch_c) for review.
I’m sure I have my terminology incorrect there. I always have trouble determining if a data directive, or a method directive should be used and under what conditions (or how I would be able to validate that from the trace log)… but the trace I collected indicates:
<tracePacket>
<businessObject>Erp.Proxy.BO.LaborImpl</businessObject>
<methodName>Update</methodName>
“make the logic that if they are clocked in for more than 16 hours, or whatever the longest legal shift is. Then send an e-mail on that they were auto clocked out and go fix the error. (because the time will be wrong).”
From an administrative standpoint, this actually sounds pretty do-able… and simple. I will introduce this idea back through management channels and see what they think of it.
Thanks, Brandon.
right, the traces are always going to show you the methods.
Method directives and data directives are just 2 different tools, and many times either can be used to accomplish the same thing.
Data directives are more resource intensive, as they fire a lot (for every record on that table). BUT they will catch anything and everything.
Method directives give you more control, and are less resource intensive since they don’t fire as often, but you can have more than one method writing to the same table, so if you don’t get every method that writes to that table, you may not get the update that you want.
@jgiese.wci – Thanks. I’ll take a look at EmpBasic/ClockOut, as well as Labor/Update and see if I can write to a UD field on end activity. Seems fairly straight-forward.
I think the MissedPunch flag to indicate the record needs review is a great idea. There should be supervisors reviewing this regularly so the finance team don’t hit the roof at the end of month.
Wanted to report back to you concerning your suggestion on administrating clock-outs:
“make the logic that if they are clocked in for more than 16 hours, or whatever the longest legal shift is. Then send an e-mail on that they were auto clocked out and go fix the error.”
I quickly discussed this idea with my supervisor and his response was… “Ahhh… haaaa” - and you could feel the epiphany swell in his voice. So - thanks for that because I think it addresses the difficult administrative side of our clock-out issue quite easily. Plus, it sets the onus on the production managers (instead of IT or Finance) to make sure their people are clocking out of operations.
I’m also going to try to do a better job of understanding how a clock out date can be extracted from the “ClockOutMinute” value, as previously suggested here in the thread, because I’ll need to find a way to report total labor hours per job, per assembly, and per complete product build.
Did you end up doing this through a method directive? I’m curious what the logic looks like if so.
I am still working at ironing out the data-driven behavior that occurs when “clocking in” and “clocking out” of operations on a particular job.
It seems that I didn’t do a terrific job of explaining (in this thread) my intentions. I started from a position of confusion concerning how Epicor records total labor hours on a specific job. More precisely, I have several internal departments who are interested in knowing how much time our production personnel are spending:
Why? Because we are interested in performing down-to-the-minute time studies so that we can adjust our MoM expectations and make proper production determinations on resources and scheduling. For this to happen - we need accurate data entry at the labor sequence level (start/stop activity).
There are two immediate problems with this:
Employees never “end activity” after starting it in MES
I have a very intimate issue with the manner in which Epicor interchanges the idea/concept of “clocking in/out”, versus “starting/stopping” a labor sequence activity.
I’ve only been developing solutions in Epicor ERP for (coming up on) 5 years. Throughout this time, I’ve consistently heard the phrase “clocking in” to a job… or “clocking out” of a job. From all of my work in this specific arena of Epicor thus far, I will say that that phrase is felonious in nature (my opinion only).
Why would I say this? ----> The only two MES buttons that have anything to do with logging actual work time against an operation (not a job, but an operation) are “Start Production Activity” and “End Activity”, highlighted in yellow below…
My understanding is, any data entry having to do with a “clock” is strictly for those Epicor environments that are also using the payroll module — because you “clock in” to your shift to work and then “clock out” of your shift for breaks, or for leaving work at the end of the day. So, again, “clock in/out” has to do with payroll… not for recording time spent performing work on an operation (my personal understanding at this time).
Notice above that I’ve technically “started activity” on operation #30 for Job #150620 on Monday, May 17th… and like a disciplined employee, I forgot to “End Activity” on this operation two days later (today). This aspect of “starting/stopping” a labor activity is ongoing regardless of whether, or not I’m technically “on the clock” and getting paid.
For those Epicor environments who do not use the payroll module (like mine), the button highlighted above in red is ignored, because it is irrelevant to starting and stopping work on an operation. As a matter of fact, I looked through the Epicor Help collection under “MES” and that button isn’t even addressed. It’s possible that I overlooked some information about it somewhere, but I saw nothing mentioned about the “Clock Out” button. Epicor Help does, however, explain the “Log Out” button:
To end your MES session, click the Log Out button on the MES menu.
Now, let’s assume that the “Clock Out” button on the MES screen is strictly for clocking out of my shift (I have to do some extra reading on this, of course, because I’ve found no information concerning what this button actually does)… then, where’s the “Clock In” button? Why is it that I can clock out for breaks and for ending my shift (again – payroll related), but I cannot clock IN to my shift?
Now, let’s add to this, the phrase, “clock out of a job”. If I’m a production worker and I have this phrase ingrained through repetition, then instead of selecting “End Activity” to complete my labor sequence, I might choose “Clock Out” instead. Personally, I have no idea what this does to the data and the overall accuracy of recording time against an operation/assembly/job. All I know is, this seems unnecessarily confusing.
To me, this is akin to a chess match, where two players sit down before a chess board. Well - they’ve just “clocked in” to the match to begin play. Each player will then log their play time during the match by slapping a time-keeper, back and forth, between turns:
I’m no expert on chess, but I believe slapping the time-keeper device will stop logging time for a player and automatically start recording play time for that player’s opponent. This is how I interpret that nature of “starting/stoppiing” activity for an operation, with each slap of the time-keeper recording an individual labor sequence against that operation.
But let’s get to the data…
Right now, the labor activity that was started on operation #30 (shown above) looks like this in the database:
It shows the correct “ClockInDate” (even though this is not a “clock in”, it’s a “start activity” [meaning: the beginning of a new labor sequence]) and it shows the correct “ClockInTime” (again, it’s not a “clock in”). Notice how the Epicor system automatically assigns a “ClockOutMinute” value (again, it’s not a “clock out”) to the labor sequence record for precisely 24 hours after the “start activity”. It also records the date that the labor sequence was created, which would typically correlate with the “start activity”.
Now, I’m going to “End Activity” on this operation (at 9:43 AM this morning, roughly 47 hours and 51 minutes from when the labor sequence was started).
… and here is how that labor sequence record is altered in the database:
Notice how the [ClockiOutMinute] value (again, it not a “clock out”) changes to indicate the correct “end activity” time - BUT - it keeps the original date of May 18 that was inserted when the labor sequence record was created, rather than when I actually ended the activity today, May 19. Notice also that [LaborHrs] is just that —> hours. So, not only does it not record the presumed 47 hours on the labor sequence (from start to end), it completely drops the remainder of 51 minutes, as well.
In any event, I believe this is why other developers have suggested to use an “auto-clockout” (again, it’s not a “clock out”) strategy, so that labor sequences on an operation do not extend past 24 hours.
All I’m trying to do is capture what ACTUALLY occurs in real-time when an employee starts a work activity on an operation and then ends that exact same activity - regardless of when they are “supposed to”, or when our internal Production Department rules state that they need to by procedure… because - that NEVER happens in reality.
[TLDR] —
So, to answer your question more directly,… because of the confusion I, personally, have with how Epicor records TRUE/ACTUAL activity on a labor sequence against an operation… I have yet to decide how to address this issue. In addition, because of what I’ve seen thus far, it also makes me question the validity of ANY report using the [LaborHrs] field.
There has also been a suggestion in the thread to create a UD field to capture the “end activity” date (via BPM) when that particular action occurs. This seems doable to me, but I have yet to isolate when the “ClockOutMinute” (again, it’s not… ) value changes via the MES module during an “End Activity” action. I’m still working on that.
I’ll post more to the thread when I finally get some headway on this.
