How to unengineer a job using a BPM?

[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.