Unchecking “Prevent Changes” in Company Configuration allowed this Update call to work. But, this is not really a solution because we need this field checked for our business processes. Why does this flag prevent setting JobEngineered to false via a call to Update? Seems self defeating…
Yeah did you set the actual.field to false in your call? Sometimes even though you call ChanStatus you need to set the flag in the dataset too
Yes I set the field in the dataset to false before the call to ChangeJobHeadJobEngineered. What and where is the ChanStatus call in the REST API?
I’m wondering what purpose the ChangeJobHeadJobEngineered Method serves other than to set the JobReleased flag in the dataset to false. It doesn’t update the database record until Update is called and Update doesn’t work if Prevent Changes flag in Company Configuration is set.
After unchecking the Prevent Changes flag in Company Configuration I was able to call skip calling ChangeJobHeadJobEngineered and just call Update.
I’m getting this same issue in Epicor 10.2.400.12 through the API. I can’t release/unrelease/unengineer jobs over the API because of the same error. The same calls from the client side work fine. Did anybody find a workaround other than toggling the flag in company maintance?
I don’t know why I didn’t do it sooner (as this is exactly what the Ext methods are for) but I got around the Update issue by using the UpdateExt and just sending in the key fields and the fields I wanted to change.
Thanks @josecgomez.
By missing do you mean the API calls aren’t able to replicate how the BOs sometimes expect the dataset? Or could I have solved it by sending the original JobHead row in with no RowMod and the updated JobHead row with RowMod = U in the same dataset? Similar to how the tt tables work in bpms?
I’ve found a couple of other calls in my travels that don’t seem behave correctly using the API where the Epicor client signals changes to data using the DataRow rowstate rather than the value of RowMod.
Yeah you should be able to solve it by sending both the Updated and the NotUpdated row. (though haven’t tested it in REST)
But that does work on the BPM / UI side.
I’ve just had a quick play and not been able to get it working.
I’ve duplicated the row from a GetByID and changed JobReleased to true, ChangeDescription to ‘Released’ and RowMod to ‘U’ and sent both rows back in but still get ‘Update not allowed, Engineered and Prevent Changes.’.
I’ve not bothered support with API queries before, will there be any benefit in sending this in?
Just like the online form, you cannot make some changes to a job until to Un-Engineer it. Unless of course, you allow it in your Company Settings…which is appears that you done. This is regular Epicor and not a REST issue.
You’re right but I’m trying to make an allowed change in releasing it. It just seems the Update API call is too rigid. The same calls in the Epicor client work.
I doubt it.
Really? You can use Job Entry to make changes without un-engineering the job? They should be using the same underlying business objects.
For what it’s worth, this is a company setting you can turn off if desired.
You can release an engineered job, yes. Not sure what the other allowed changes are but that was the one I was after.
I suspect there is a disconnect between the REST service end point interacting with the BO and the screen interacting with the BO. UpdateExt works so it’s not the end of the world.
Unfortunately (or fortunately depending on how you look at it), we’ve decided that this needs to be left on.
How did you create / populate the “UpdExtJobEntryTableset” that the UpdateExt method takes, as opposed to the JobEntryTableset that the regular Update() method uses?
You don’t really populate an UpdateExt dataset, with a BO. You populate all the key fields, and your
changes, and it in theory should handle the rest for you. (Sometimes it’s dumb.)
What that means is, add just your changes and all of the required fields with code or widgets, and
let it fly.
Here is a good post for you:
OK I see how to use it through the widgets. However I now get the following error:
There is at least one compilation error.
error CS0433:
The type 'JobHeadRow' exists in both 'Erp.Contracts.BO.JobEntry, Version=10.2.700.0, and 'Erp.Contracts.BO.MassIssueToMfg, Version=10.2.700.0
Bah. The only way around it for me so far is to change a setting in Company Config regarding “engineered and prevent changes”, then I don’t need to try this UpdateExt to force release on an engineered job. Also, can’t use JobEntry.UpdateExt() method in this directive because I am already using the MassIssueToMfg BO which contains the same tableset names I suppose. SOL! Haha.
There are ways around that. I’ll hit you up later.