"Required" UD field, best practices

Epicor ERP 10
1

Looking for input on managing the various ways of making a UD field required.

We have several UD fields (via Extended UD Table Maint), that we consider “required”. By “required” We mean that folks must enter the info during data entry. But may be blank for pre-existing records, or when records are updated via other processes.

1. The “Required” field in Extended UD Table Maint.
I generally avoid making UD fields required this way, as it’s tough to know all the potential processes that could create or update the record. And unless all those processes are customized to populate that field, you have the potential for a process to get hung up.

For example, A required UD field on the InvcHeader would be easily handled by a custom field on the AR Invoice Entry screen. But a Counter Sale order (set to Auto Invoice), would fail as there’d be no values in the UD field when the record was created.

2. Form event customization to prevent saving record on blank (or invalid) value
This requires customizing every form that might create the record. Maintaining these customizations can be a real pain. And there’s always the chance that a menu item didn’t get updated to use the latest customization.

3. BPM to Raise an Exception
This is usually my go to method. Seems to provide the most flexibility. The exception can display a message guiding the user to exactly what needs to be corrected. However, it does suffer a similar problem as #1, as if the process is called from some unexpected initiator, it may prevent the process from completing - unless the BPM code dynamically determines if a blank is acceptable, based on the calling context.

A very nice thing about BPM’s over form customization’s, is that independent BPM’s can exist for the same process, and can easily be disabled one at a time.

And although not a “hard stop”, I’ll often customize the forms to highlight UD fields (or even builtin ones) to aid data entry in not missing a field that we’d really, really , really, like to be populated.

Thoughts?

2

another option is through Extended Property Maintenance which is my preference everything else being equal. Requiring a field to be populated through the UI is just a checkbox.

image.png917×482 29.5 KB

1 Like
3

That’s similar to the 1st point of mine.

What happens if that field is required, and an existing record (that existed before the implementation of this new field) has to be updated.

Example: If that was the UserChar1 field of OrderHed, and you decide that existing orders don’t have to have the field back populated. Order 1234 existed before the UD implementation, but then the Order is closed - automatically when the last line is closed from being shipped.

Would Order 1234 close properly?

Or would the fact that the field is blank prevent the closing process to complete?

1 Like
4

Extended Properties is closer to the second point than the first. It should only enforce the required property during record creation through the UI.

1 Like
5

So if InvcHed has a field with an extended property set to Required, A counter sale (which can create an Invoice) would fail, unless Order entry was customized to set that field prior to saving?

6

I am not familiar enough with the sale/invoice process to speak to how the counter sale creates the invched record behind the scenes- if the creation process is through a direct call to the server BO then it wouldn’t fail.

Best way to know how it actually works is to test it out :slight_smile:

1 Like
7

Here’s my test (all in our test environment App)

  1. Created an Extended UD Field (i’m in E10, so Userxxxx fields are rare) in table InvcHead. FieldName= SubmittedDate_c, Column type = Date, Required=Y
  2. Regenerated Data model on App Server & cycle IIS
  3. Launch E10 (the test environment App)
  4. Create a new AR Invoice Group, using the base form (the UD field wasn’t added to the form)
  5. Create a Misc Invoice, saving before adding any lines. This creates the InvcHead record.
  6. Get the following message when trying to save Invoice Header.

So it looks like it’s tied to the actual DB, and not to the UI.

I did some more testing and it turns out that DMT won’t process unless that field is set.

image.png704×488 18.8 KB

So with a UD filed set as “Required”, attempts to create a new record with that field blank will fail. I have no reason to believe that an update of a record (with that required field being blank) wouldn’t have the same result. (failure to update the record)

8

Have you tried to update a record where submitteddate_c is NULL and have it throw an error? I tested this before I commented earlier on two different tables; Part and QuoteHed. If I enabled the property after the record was created and updated it with the field having the default value for its datatype- no error. If I tried to create a new record while leaving the field blank - error.

9

Hmmm … Thought I already replied to this …
(turns out I had, but to the wrong topic, so here it is)

Did a test of adding a Required UD field, and how it affects creating new, vs updating existing records.

New Record:
Record is not created when the required field is left blank, get a warning like

Updating a pre-existing record, without touching the required field
The record can be updated, regardless of the field being displayed via a UI object, or not. The UD field value remains NULL

Updating a pre-existing record, after changing (and saving) the required field
The record can be updated after changing the UD field value to non-Null. But deleting the UD value (making it NULL after it was saved as non-NULL), does not update, and a message similary the one above
("< fieldname > is required") is displayed.

This is not what I expected. Historically, I would back populate the UD field (via DMT) with a value that indicated it predated the addition of the UD field. Seems like this wasn’t necessary.

10

Going geek a minute on the plumbing so forgive me…

The framework under all BO services has ‘core methods’ we probably have seen in BPM - GetRows, GetByID, GetList, Update, DeleteByID. The Extended properties mentioned above are validated during the Update core method. So if the UI goes thru a service using the core service Update method the ‘Biz Rule Engine’ fires and validates the Extended Properties.

If however the UI does custom updating as they need to in many cases, the Biz Rule Engine will not catch the validation automatically. The service needs to opt into that check - or ignore it as makes Biz sense for the logic they are trying to perform.

You probably have seen this when trying to use an ‘Update’ BPM and find out it is sneaking around the side door to another UpdateFoo or ChangeBar kind of method.

In the case where you absolutely positively have to enforce a field the Data Directive is your solution. This is the equivalent of putting a validation in a SQL trigger. On any update done thru the data layer, a data trigger will fire and you can validate things in the data directive. On that record in the db you absolutely have to satisfy ‘x’.

I’ll give the same warning to everyone I stand on a soap box internally…
Data triggers are the last line of defense not the first. They can be massively abused and have caused many performance problems in the past when misused.
The problem with them is the same as exists with triggers in SQL. The context of what is happening is a single row. When you look at a service Update method, it’s a hierarchical graph of data - a Tableset / DataSet. You know the context of what is going on. You have the header and the line items. In a data triggers (or sql) you don’t have that context You are forced to do extra lookups, some calculations, etc to figure out the context of why am I here. That costs cpu cycles. Potentially lots of them.

So this may be a good candidate for a data trigger -> If column required = Y then value != null. Perfectly fine data trigger.
If it was if header column = Y and sum of all lines must be >500… that is a great way to slow down the system …

9 Likes
11

When we are trying to make UD field mandatory through “Extended Property Maintenance”. But Required checkbox is showing disable refer to below screen

ExtendedProperty
ExtendedProperty.JPG1107×813 84.8 KB

Please suggest how to make this field mandatory.

12

I did it in the Extended UD Table Maint.

(ignore the highlighted part)
image

I’d guess that a Data Regen would be required after making that change.

1 Like
13

Ditto

1 Like
14

That being said I really love the odd SQL Update trigger artifact left by the previous incombent to really wreck your day.

15

I’m not clear on what creates these SQL triggers.

Does my post that said to mark the field as Required (in Extended UD Table Maint), create an SQL trigger? And if so, why would Epicor allow users to enable such a “bad” thing?

16

Good Stuff