I have a request to add a UD field with a special function: once data has been saved to that field, prevent future users from changing it. In this case, this is for a new field named “Original Ship By Date” on the Order Release. The purpose is that someone can modify the actual “Ship By Date” on an Order Release based on production limitations but preserve a record of the original ship by date for easy reference. Then they are going to run a BAQ to see the difference between these two values over time.
What is the best way to approach this? The rough idea of a BPM that locks a field if its value is non-null seems to make sense, but I don’t know how one would/could actually implement that. I am open to other ideas as well. Perhaps a UI customization that makes the entry field non-editable in the UI if non-null? Though I prefer a BPM approach if possible since those tend to be more compatible for upgrades (from classic UI to kinetic UI for example).
That makes sense. I know how to add a Condition to check the value, but how do I in a BPM tell it to “not write it”. That isn’t in the list of options in BPM Workflow Designer.
Just throw an exception with a nice Sorry message. You want the user to know it was not done.
I have the same field, but have a security group that IS allowed to update the field on the occasion the customer and us settle on a new Original ship by date.
I have also done this with row rules, but that is classic only.
I have a few custom fields like this. I never let the users set them directly. What I do instead is add a BPM on the Update method that will (say) check if the UD Date is null (or if the order is new, or if the order was created that day, etc.), and if it is, set it equal to the order date.
Because there’s already too damn many fields on those pages. Users don’t need to set the same basic thing twice.
This is a great idea @aaronssh. In fact, having an Original Promise date on Purchase Orders might be cool too if it doesn’t already exist. It’s such a good idea, and so many others seem to do it with a BPM, I would certainly vote for such a thing if it appeared on Epicor Ideas.
@Mark_Wonsil , you’re not wrong but if I submit the idea and it gets implemented, then we’ll all have to remove our BPMs and redo our reporting. It would be nice for everyone new to Epicor but not nice for the rest of us with BPMs like this already built out. So I won’t be submitting it, but maybe someone else will.
Aside from that, it takes less than 30 min to implement such a BPM and (speaking from first hand experience) it takes YEARS for anything to make it from Epicor ideas into the version that we’re actually using (if ever). That incredible time delay makes Epicor Ideas mostly of little to no value to me. Sure, its good for new Epicor customers signing up 8 years from now, but Epicor Ideas has no tangible impact on the companies I work for. Most of us have a real business need and need something implemented now, not 6 years from now.
FWIW, the date a Part was added (CreatedOn and CreatedBy) used to be BPMs for many. The EUG put it on the enhancement request and it was done in about a year. It’s not displayed anywhere, it just gets populated. These fields would be similar.
I have eleven ideas. One has been delivered (now called the Share links) and it appears that INCOTERMS is in development.
You want the user to know it was not done.
