We have a UD field on JobHead that is going to be changed frequently, but we have the company set up so jobs can’t be changed when engineered. We don’t want to disable the Prevent Changes option just for this one UD field.
I assume the ideal method is to use ChangeJobHeadJobEngineered, but if I send a couple of requests to un-engineer and re-engineer the job via the endpoint …/Erp.BO.JobEntrySvc/JobEntries(Company,JobNum), would I get a virtual slap on the wrist for doing so? Are there any risks doing it this way?
1 Like
How are you updating the field? From the UI? Where are you trying to fire those methods from?
If it were me I would just do a Db update and change the field directly since it’s your UD field. There’s no risk of Epicor having logic that’s going to get messed up by you changing a UD field that’s engineered. I wouldn’t do that for Epicor fields, but UD fields doesn’t really pose a risk.
4 Likes
Thanks Brandon.
I’m going to send the request via Javascript. My main concern is with changing JobEngineered to false so I can edit the UD field and changing to back to true when I’m done, since doing it while the job is engineered doesn’t seem to work. I thought of doing this with a PATCH request without using ChangeJobHeadJobEngineered via REST, but wasn’t sure if that would be a good idea
1 Like
Use a function and do a DB update there. Don’t use an epicor BO to make the change (to your UD field). That’s what I’m suggesting. Skip the engineered thing altogether.
3 Likes
Ah I see what you’re saying, my brain just wasn’t turned on. Thanks for the help!
2 Likes