How to unengineer a job using a BPM?

[tstein01 (Tanner Stein)]

Does anyone know of a way to unrelease/unengineer a job using a BPM?
I seem to always get the “JobHead not changed” error when trying to run ChangeJobReleased method.

Any help would be useful!

[NateS (Nate Schoonover)]

You need 4 widgets to do this in a BPM: JobEntry.GetDatasetForTree, Update Table by Query, JobEntry.ChangeJobHeadJobEngineereed, and JobEntry.Update.

The only tricky part is setting the Update Table by Query. I have attached a BAQ with the BPM in it for example.

teste.baq (48.7 KB)
I have hardcoded this for one job, so you will have to change that filter. Otherwise the BPM part is pretty simple.

Good luck!

[jtownsend (John Townsend)]

This is using a function (which you should be using for anything complicated anyway), but it walks you through the whole process of taking an existing job, unengineering it, re-pulling details, and re-engineering. If you stick to BPM’s, the method calls will be pretty much the same.

Note that this specific example was meant to be run on a list of JobHead records. For your needs you’d need to call JobEntry.GetByID() or use a LINQ query to create the variable “job”.

Using Epicor Custom Functions to Update PartOpr and JobOper

That doesn’t look like Function syntax. There’s also a few caveats with JobEntry specifically, at least if you don’t allow edits to engineered jobs. This is from a function I wrote that uplifts the revision on a job. This snippet first unengineers the job, then runs the update of the now-editable record. Note the lambda (=>) syntax vs the using statement more common in BPM’s, foreach (var job in jobs) { try { //Placing the txScope here instead of at the function itself …

The quick answer to your question is that JobEntry.Update() does not like having any child rows in the dataset of engineered jobs. You have to strip out everything except the JobHead record.

[tstein01 (Tanner Stein)]

@NateS I appreciate the response. I tried to run it the way you said, but cant seem to get around this error:

[tstein01 (Tanner Stein)]

Update**

I currently have been able to get passed the “JobHead not changed” error - by updating the “Rowmod” field to “U” -

Now I just cant get the Update to run -:> it produces the Job engineered , prevent changes error.

here is what my BPM flow looks like currently, any tips?

[jtownsend (John Townsend)]

Like I said above, Update() gets angry about engineered jobs when you hand it a dataset that has anything more than just the JobHead row. You can’t just call GetByID or GetDataSetForTree, edit it, and pass it along to Update. Those will have the entire job populated (assemblies, ops, opDtls).

You have to copy header row only to a 2nd blank dataset. Then call the methods referenced in my link to properly unengineer and save the job.

[NateS (Nate Schoonover)]

@jtownsend

You can’t just call GetByID or GetDataSetForTree, edit it, and pass it along to Update

This did work for my example BPM. I didn’t extract the header row as you said. Perhaps running this as a Method directive yields different results than the way I ran it. I just had a BAQ with BPM as a test.

[jtownsend (John Townsend)]

Assuming you lock changes to engineered jobs, it might be a version thing. It was always weird that the system made a huge stink over rows with a blank RowMod. Epicor normally ignores those rows. They might have fixed that inconsistency in 2024.

Could also be an Update vs UpdateExt thing. Not sure how exactly you implemented your test.

[NateS (Nate Schoonover)]

@jtownsend

Not sure how exactly you implemented your test.

I used Update, not UpdateExt. My BAQ is posted above if you are curious. I think you are on the right track with the lock changes thing. In my Company Configuration > Modules > Production > Job > Change Engineered Jobs: The Prevent Changes flag is not checked!

[jtownsend (John Townsend)]

@NateS

Change Engineered Jobs: The Prevent Changes flag is not checked!

Haha, yeah. That will make all the difference here.

[NateS (Nate Schoonover)]

So, what does this mean for jobs updated this way? With that flag turned off, I can use this simple BPM to unengineer and unrelease a job. Does this mean that I am breaking something in the background? I don’t use this process, but I assumed it works.

[jtownsend (John Townsend)]

No, I don’t think you’re breaking anything in terms of the system. This is more of a policy/process thing.

If you don’t check “prevent changes” then the system is a lot more lax about editing engineered jobs. Pretty sure you can go into Job Entry and edit whatever whenever. The backend stuff is certainly unrestricted.

If Prevent Changes is checked, then JobEntry module will hard reject any changes to the job unless you go through the aforementioned steps to unengineer the job first. ScheduleEngine and JobManager modules will allow limited access to a a few fields (mostly dates and in the case of JobManager JobHead_UD fields) largely for the purposes of scheduling.

Even then, ScheduleEngine is not going to (for example) write back Resource changes in the schedule table to the JobOpDtl table when you flex to a different resource.

[tstein01 (Tanner Stein)]

@jtownsend Yes, unfortunately we have to keep that checked for our company, since we are in the med device industry.

So is your solution about having a 2nd dataset only having the Jobhead row, possible using only the BPM workflow designer? Or does this require manual coding input / functions?

[jtownsend (John Townsend)]

I don’t really use widgets for stuff like this, but I think you can use Fill Table By Query widget instead of a method call to GetDataSetForTree to populate your dataset with only the JobHead table. You only have to grab the fields highlighted in my code sample. You can ignore everything else.