Chris:
I should have provided a bit more information concerning my solution. Correct - this is a customization for UD11 (Ice.UI.App.UD11Entry.UD11Form).
So, we have this additional level of data tracking that we need to perform specific to FAA requirements relating to decisions made within the NonConf-to-DMR-to-Disposition process. Our engineers and QC staff need to provide substantiations (according to FAA regulations and various other engineering best practices) for dispositions on scrap, or perhaps if a part is to be used “as is”, or if the part should be reworked. Our team needs a way to enter those decisions, the substantiations behind them, who made the call on the Quality side, who made the call on the Engineering side. So, even though Epicor ERP has a nice way to enter non-conformances and track dispositions through DMR, my company has all of these extra steps we also need to track.
The best way I thought to do this was to make a few small customizations in NonConf… and… then work in the disposition and substantiation model via a UD table.
That’s the piece I’m working through now. I chose UD11 and had already set up the table and a few fields on the UD11Entry form to correspond with UD11’s available fields. The NonConf search was needed so that our engineers could simply look up the originating non-conformance record as a reference. Various required NC data would then be included in the final disposition/substantiation report.
I wanted “Key1” to hold an auto-generated number (that’s a discussion for another time ) that represents a PK for the UD11 table and use “Key2” as a FK to the NonConf table… which also makes me wonder if there might be some additional UD configuration I need to be doing to ensure the Epicor system knows about the [UD11.Key2]-to-[NonConf.TransID]" relationship.
Anyway, the three-panel screen grab I started with above is depicting the UD11Entry form as it stands now. An engineer can open the form, reference the originating NonConf… then get to work on entering disposition and substantiation. All of this saves nicely back to the UD11 table in the appropriate fields (nothing is done to the NonConf table, as it’s merely a lookup).
However, the UD11Entry form leaves all of the fields accessible to adjust or modify directly after the data on the form is saved. I’d prefer to adjust all form controls to “read-only” when a record-save is enacted.
What I don’t know how to do is “detect” when a form save has been called in order to adjust the read-only property on all controls on the form. Row Rule Wizard has been suggested. Perfect… but how is a form save “detected” using Row Rule when it appears the Row Rule (at least in my interpretation of it) is merely looking at conditions that can be defined on a field?
Where does “UD11.RowMod != ‘A’” (where the RowMod property of the UD11 table does not equal ‘add’) fit in to evaluating a condition on a field? Which field(s) should this evaluation of the entire table be applied?
My confusion is… how does an evaluation of conditions on a field (this is what I believe the purpose of Row Rule is) fit in with saving an entire record/row on the UD11Entry form?
Ok… in keeping with the dreaded Star Wars theme I morosely started, I feel like tossing up a Princess Leia GIF with the caption, “Help me, Obi Wan Chrisnobi. You’re my only hope”… but that would be even more cheesy than the Palpatine reference.
Postscript:
The two main drivers behind this are that [1] saving the record with no visible change in form/controls state might confuse the user concerning whether or not his/her data had been saved at all and [2] I’d like to prevent accidental data modifications should the user keep hitting the save button during his/her confusion.