We are running the Epicor Job Close process. I just want to understand what is the the trigger or flag that will tell the process to try to close the job. I am curious if it looks at the last operation to be completed or something else that indicates the process to try to close a job.
Commenting to move it back to top and have another question.
I guess I am wonder what makes it flag set to candidate (I am guessing this means the system thinks it could be closed and will try too)
New question: Does anyone know the order it process checks on job close? Does it look at labor first then DMR ETC…
I don’t know the sequence or that it matters. All the job close parameters are checked. So a Job “candidate” to close has to pass all the parameters and could fail one or multiple parameters.
I wish this topic had more info in it since we are having jobs show up as Candidates with only 2 of the 5 operations complete, the final op has no labor on it and there is no completed qty listed on the job closing screens. What on earth would be causing this to happen? I started a call with Epicor but I’m not holding my breath.
Did you look at the Job Close and Job Complete Logs?
We don’t have auto job completion and closing running right now so there are no logs to review. We manually complete and close out jobs. The problem I’m having is they review their Candidates for completion and this is visible when searching for a Candidate and the question is why? It is currently far from being a Candidate for completion.
I notice there is a completion date in the Job Completion/Closing Maintenance. Did someone accidentally mark it complete then removed it. I think it leaves that completion date. Maybe that is why. I would try it with a job in your test environment and see if it changes a job to candidate.
Sorry no answer for you, just confirming the same behavior when I search jobs with the candidate filter.
I don’t have any job complete/close parameters set so don’t see how that could be involved.
To add to the confusion, not sure how/when JobHead.Candidate gets set either.
Ref screen shot of a BAQ where I tried comparing OpComplete(s) and the Candidate field.
That date is always present, it shows the current date so if you were to check off the Complete box it would enter in that date, that is normal operation of the closing screen. I have found that in the Job Cost Adjusment screen the 999 operation is flagged as complete but there is absolutely no labor posted against it, and I can’t uncheck that box because it will error out stating “A valid employee ID is required”
Epicor’s response was a FAQ on how Candidate works which should be triggered off the completion of the final operation, but something is going wrong somewhere.
It appears you’re having almost the opposite issue than what I’m having. You have honest Candidates not being tagged as them, and I have open WIP jobs getting tagged as Candidates. Go figure.
I like to update threads when I discover a solution to my problem. I’m not sure how widespread this issue is, it may not apply to V9, but in 10.2.400.10 if you have a job released and an individual had clocked into it and worked on it, maybe just the first OP or the first two, no labor on the “last OP” and no completed qty on the last OP either. If you go to Job entry and un-check engineered to perhaps add an additional operation, or materials, when you do that the job is tagged as a candidate immediately. I found this by adding the Engineered box as a change log event for a different purpose, but I also added Candidate and Job Header Completed QTY as logging events, that’s when I noticed this on a job that was showing up as a candidate.
Seeing as how the Candidate check box is not user editable this shows there is a program glitch somewhere. I also noticed on jobs where there was a Sub Assembly with a completed qty on that, last OP on the SA was not tagged as last OP either, It would take that completed qty from the SA and post it to the job header.
Epicor has taken this problem to Development and we’ll see where it goes from there.
Can you tell me what case this is or the problem number? @FTI-SeniorAdmin
Problem number that originated after this case is PRB0217466
I try to look that up in epiccare, but I can’t find it, do you have a link to it by chance?
It does not appear to be public, since I can see it via links they posted in my calls but I can’t search for it in their problem repository. I think you will have to talk to support and tell them the number to get info on it if that’s what you’re looking for. The posted resolution is 10.2.600… So I’m assuming they fixed the code to not do that anymore.
Yeah I just got off the phone with them @FTI-SeniorAdmin thanl you so much for trying to help.
It is crazy though that they didn’t retro it… it is impacting .400 and .500 releases according to the support representative.
We’re dealing with this now too, wondering how to clear the candidate status of a job that’s not ready to complete.
I’ve argued with them to give me a generic fix program that will allow me to deselect the Candidate flag but they continue to only provide me a fix PER JOB when I want it corrected. As much of a pain in the A that is to process and get, I’ve just told the job managers to pay close attention and take note of the ones that are incorrectly flagged and just move on from them till they know they are completed. Crappy work around yes, but this is all they are giving me. I have 10.2.500.14 in a test environment that I need to see if this is still happening on, but with what utaylor stated it sounds like it’s still around for the long haul.
I just checked my fix files and it looks like I went back an forth with them 4 times and they couldn’t create a fix that would allow me to search by Job number and just un-check the candidate flag… Should NOT be a hard task… but they couldn’t do it. I’m willing to bet I just gave up in the support call due to frustration and said never mind this is taking you way too long to understand and I’m tired of the back and forth.
I got a problem update the other day on this. I did what you did for a workaround. We have a job closing report that gets sent out for jobs that need to be closed and there were jobs showing up on it that were not finished so I just threw a row rule in there to highlight them yellow when the complete qty was 0 but the job was in the jobclosinglog to make sure they really checked out those jobs. It already returned one false positive where they shipped the job, but didn’t punch it out properly, but it’s the best we can do.