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.
1 Like
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.
1 Like
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:
3 Likes
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.
1 Like
I would love to know how to get around that because it has hurt me more than once! And my client is not OK with changing the company setting for engineered and prevent changes on jobs so I’d love to figure out a workaround.
For anyone snooping on this thread / issue, I was able to get around the error regarding the same named tableset(s) / row(s) in 2 different business objects by not adding the second BO assembly in the “usings and refs”, and instead declaring the Svc Contract and Tableset with the full path(s). At least I am 99% sure this is why it worked. Only other change was that I moved the code to a new “Execute Custom Code” widget before the code that’s using the MassIssueToMfg BO instead of putting the code in the same widget…
That worked because the method had them referenced already in the background.
Like any method on the JobEntry BO, will have the JobEntrySvcContract etc already referenced.
Many thanks to everyone who participated with this thread. Literally started with the top issue, hit every issue on the way down.
Ultimately solved each issue. Duct tapes helps. And so does the advise.
1 Like