We have experienced an issue where more than one resource ID is appearing on the operation 10 of many jobs. We have seen that as the labor for each employee is being entered in Time and Expense entry, the original Resource ID associated with the job is not populating on the Daily Time Detail location Resource.
For Example NC Finish Fluting Machine 66 is on the Job Details -Operations-Detail tab for Job F175895 under Labor Reporting Resource, but NC Pear Fluting Machine 83 populated the location Resource when labor for an employee was being recorded on the
Time Daily Time Detail Detail tab of the Time and Expense Entry.
Because of this, I have more machine hours being applied to a particular job than should be, generating negative burden variances. I am not certain if this is an error in our procedure or set up, or a true software issue.
It sounds like someone manually entered machine 83 when entering labor. Perhaps this was truly the case: that it was run on 83 instead of 66?
Was this rescheduled before the operation was finished?? If so, perhaps the first time it was on 83 and after the reschedule, 66 was used for scheduling.
I was told that the job was not re-scheduled on a different machine. The resource ID from the job should auto-populate on the Time>Daily Time> Detail>Detail tab with the same resource ID that was created on the Job Details>Operations>Scheduling Resources>Detail tab.
We have had 4 instances of this since we reported the issue, but I believe I can find hundreds of instances. Epicor Support was not able to replicate the issue on a copy of our database. I mentioned to them if they could query our labor detail table you can see the errors. I have a machine ID that had 113 hours of uptime reported against it on 02/01/2016. It seems to be a pervasive issue, and I am tending to think it is some kind of a set up issue.
I will definitely look into whether or not the job was rescheduled though.
We sat on that version (with sql) for years and never saw anything like that, for what its worth. Id look hard at your set up and other environmental factors.
My company was on it too, for probably a year and a half, and never saw what is being described.
However, we see pretty often where people don’t want to get blamed for doing something they aren’t supposed to do so they blame the system.
However, in this case, people might deny that it was rescheduled because they don’t know that someone else rescheduled or that global rescheduling happens automatically at night; I don’t know if your company does that, but we do it and so do most places running Epicor that I know about.
Below is the response from our senior planner who is in charge of production control…
"And yes, they do in instances where the tech feels he can run the part better on another machine for whatever reason or if the machine is down. This will happen in a manufacturing environment. HOWEVER, these are not part of the issues I logged for EPICOR. If the job resource id does not match where the part is being fluted, that is not an issue for EPICOR.
The problem that I submitted the help ticket for is that, at the point of data entry, the job notes one machine number, it matches the machine the part is made on and it comes up differently in time and expense entry. By this I mean, even if the part was rescheduled as this gentlemen notes below, the JOB resource id matches where the part WAS FLUTED as noted on the production paperwork.
Kathy, we’d like EPICOR to help us with a fix for this issue. For them to do so, according to them, the condition needs to be replicated.
In the interim, we are correcting every instance when we see it in Time and Expense Entry. "
My comments to you are:
I too am leaning toward a process or setup issue. I may need to hire a consultant if I can’t figure this out soon. It has been going on for years, and the process managers have difficulty explaining their high burden variances, which seem to be offset by favorable variances in overhead applied.
@BoostERP:
Unfortunately, the table in question (JobOpDtl) is not available for change logging. However, a Data Directive BPM could be designed to add an entry to the change log for the job so that it will appear in the change log for the job. I’ve done this before for Sales Order Lines and Releases and Allocations.
@kboras:
In the “My comments to you” section, is this directed at me, or part of the quote? What is meant by a “process or setup” issue? Is it in the context of Epicor or Production process or setup?
As for the original issue,
If someone used one machine instead of the one scheduled as I suggested, that shouldn’t change anything in terms of how many hours are recorded unless the machine or operator used is less efficient. Is this quote implying that there are double transactions logged (resulting in more hours)? If this was logged twice, then someone must have logged in twice for this operation.
However, I did notice something during our implementation that may be relevant here. We wanted to estimate labor for both our machines and labor, and so experimented with putting two parallel resource groups onto our scheduling resources: one for machine and one for labor. It looked good for our scheduling; however, when we looked at our reports, the job was estimating double hours: once for machine and once for labor. We stopped that before we took Epicor live, and went with only machine scheduling. Perhaps someone has put two resources onto the method thinking that it would choose one of the two, but it schedules double because it uses both? And perhaps someone signs in for both machines, creating double labor entries for those jobs? Otherwise the scheduling would show double hours but not the labor transactions.