Job Operations not Completing - 10.1.500


(Aaron Willett) #1

So, I’m being told that a few times per week, production comes across some operations that weren’t completed, but were marked to be in MES or T&E. Every time I try to recreate the behavior, it works as expected. Mark the box in MES and upon hitting OK, the op is completed. Similarly, mark the “Op Complete” box in T&E and the operation is completed. Interestingly, the screenshots provided to me from production show the boxes in T&E marked and approved, but job adjustment shows the Op Complete box as unchecked.
I’m hesitant to go to support since I cannot replicate it and they’ll want to see the issue.
Has anyone experienced this?





(Joshua Giese) #2

Known issue with the sync between operation status and sometimes qty and job head. According to Epicor they can’t reproduce it, but know it exists, and don’t know how to fix it. I see what you see infrequently, by more frequently see Labor Detail sum with say 10 completed but oper and head will say 0 completed.

Whether it’s been fixed by current patch 10.2 I can’t say.


(Aaron Willett) #3

Hmmm. Go figure.

I guess I’ll write a BPM to see if I can force the completion.


(Gil Violette) #4

Wow, that is ugly! Most ERP systems use the operation completed flag to indicate that the operation does not require scheduling.

If it’s truly a bug, then the dispatch reports are likely to be inaccurate - listing items that have been completed!

Only using V8 here, but curious what other users are seeing - since we are actively pursuing upgrading.


(Aaron Willett) #5

So far, I’ve experienced this in versions 8.00, 9.05.702A and now 10.1.500.16.
Seems they’re having troubles rectifying the issue, which is understandable if they cannot replicate what’s causing it. Slightly annoying, though.


(Gil Violette) #6

From my view, it’s more than “slightly annoying”. We must provide clear and accurate schedules to the shop, and the best way to mismanage that is to present a dispatch that lists items already run.

In our version of the software (8.03.406A), this problem has not been seen.

I’d be interested in hearing others weigh in on this.


(Yelena Tuzikova) #7

Definitely more than slightly annoying. We got dinged on our last two ISO audits for having incomplete operations that were really completed. We resolved it by creating a dashboard that shows operations that have the op complete checkboxes not matching between the two different tables.


(Aaron Willett) #8

Here’s Epicor Support’s response when I opened a case:

We have some similar situations reported but all of the to correct what happened with the completed quantities and operations, this is a random situation and cannot be reproduced at will and normally happen with the setup of the Check boxes for completed quantities that may vary depending on your operation.
In order to correct this situation and mark as complete the operation you can do a Updatable BAQ to the JobOper and set the complete check box as updatable to update the status.
We have a fix also that can help us to update hte Completed quantity for the JobOper table.
Please try the updatable BAQ and if this does not work we can run the Fix.

I just wrote an in-trans BPM that when the LaborDtl.OpComplete goes from False to True, then force the JobOper.OpComplete equal to True. We’ll see how that goes as far as a workaround.


(Joshua Giese) #9

They also have a datafix for the workbench that tries to sync everything. They admit the issue has been there since V8, but believe it’s linked to a mixed use of certain modules, but they don’t know which ones.

I spent over 16 hours trying to troubleshoot this and recreate the issue, I could never do it. “Trying” defined by doing different things out of sequence that a user might do.


(Mark Bernhardt) #10

Aaron did you ever get your BPM to work? We tried something similar and the changes don’t ‘stick’ when we refresh. Would you mind sharing the business object you used?

Thanks,

Mark


(Aaron Willett) #11

Mark,

The BPM I have seems to work, but it did not solve the issue. We’re still trying to find the cause.
I did an in-trans that checked if the labordtl.Complete when from false to true, then ran this code:

        var ttLaborDtlR = ttLaborDtl.FirstOrDefault(r=>r.Added() || r.Updated());

        if( ttLaborDtlR != null )
        {
           string jNum = ttLaborDtlR["JobNum"].ToString();
           int assemSeq = (int)ttLaborDtlR["AssemblySeq"];
           int oprSeq = (int)ttLaborDtlR["OprSeq"];
           bool opComp = (bool)ttLaborDtlR["OpComplete"];

           foreach(var jobs in(
              from jo in Db.JobOper.With(LockHint.UpdLock)
              where jo.Company==Session.CompanyID && jo.JobNum==jNum && jo.AssemblySeq==assemSeq && 
                      jo.OprSeq==oprSeq
              select new {jo}))
           using(var scope = IceDataContext.CreateDefaultTransactionScope())
           {
              if( jobs.jo != null )
                 jobs.jo["OpComplete"] = opComp;
              scope.Complete();
           }
        }

(Mark Bernhardt) #12

Thanks Aaron, it’s certainly a pain how this works. We have other issues with using report quanity. Often the assemblies remain in the previous op and material 10 moves instead to the next op. Support isn’t being much help so we’re just going to use move wip to move the wip around. Since move wip doesn’t complete operations, we just want to manually flag the completion but the system is not cooperating.

Mark


(Andris Skulte) #13

@aidacra @Bart_Elia - Will the new telemetry capability provide detailed-enough data to let Epicor figure out the root cause in 10.2?


(Bradley Hathcock) #14

We are experiencing this issue as well in 10.1.500.20 and I have reached out to Epicor for Help. I wish we had more to offer to help.