I had initially gone that route, but I couldn't get it to work on the Customer form. I called Epicor support and they told me that they did initially intend for this to be the way to do mandatory fields, but later discovered it caused performance issues. From the support log:
**********************
When you set an extended property on field using the Extended Properties utility program this is a global setting that is used by the product on any form. Think of it is a global setting. When setting an extended property using the Extended Properties utility program you must completely exit Epicor 9 before testing as the extended properties will not be in effect until your session and cache is refreshed.
Additionally, my research of known issues shows that there are some limitations to the use of the "Required" extended properties. This is from development:
To clarify the use of the Extended Properties Required field. For example the OrderDtl.NeedbyDate can't be set to required by using an extended property. Development indicates that this is a design limitation because the BizRule engine is written the way it is for performance reasons. We do not want to revaluate every field on every write. Development will not be changing the BizRule engine changed to support this functionality.
We did submit enhancement request 8220ESC asking that development gray-out the required checkbox in the Extended Properties utility when the BizRule engine doesn't recognize the field and we asked them to document this limitation in the help. To date the enhancement request is still open.
*************************
Given the hit or miss capability, I have opted to use BPMs as the standard approach for us.
**********************
When you set an extended property on field using the Extended Properties utility program this is a global setting that is used by the product on any form. Think of it is a global setting. When setting an extended property using the Extended Properties utility program you must completely exit Epicor 9 before testing as the extended properties will not be in effect until your session and cache is refreshed.
Additionally, my research of known issues shows that there are some limitations to the use of the "Required" extended properties. This is from development:
To clarify the use of the Extended Properties Required field. For example the OrderDtl.NeedbyDate can't be set to required by using an extended property. Development indicates that this is a design limitation because the BizRule engine is written the way it is for performance reasons. We do not want to revaluate every field on every write. Development will not be changing the BizRule engine changed to support this functionality.
We did submit enhancement request 8220ESC asking that development gray-out the required checkbox in the Extended Properties utility when the BizRule engine doesn't recognize the field and we asked them to document this limitation in the help. To date the enhancement request is still open.
*************************
Given the hit or miss capability, I have opted to use BPMs as the standard approach for us.
--- In vantage@yahoogroups.com, "mattcald_73" <matt@...> wrote:
>
> If you have Epicor 9.05, you can make fields required via the Extended Properties under System Management --> Utilities...
>
> --Matt
>
> --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@> wrote:
> >
> > I have a BPM intended to enforce mandatory fields running as a pre-process Customer.Update and the code looks like this:
> >
> > FOR EACH ttCustomer:
> > IF ttCustomer.State = "" THEN DO:
> > {lib\PublishEx.i &ExMsg = " ' State is Required.' "}
> > {&THROW_PUBLIC}.
> > END.
> > IF ttCustomer.Zip = "" THEN DO:
> > {lib\PublishEx.i &ExMsg = " ' Zip is Required.' "}
> > {&THROW_PUBLIC}.
> > END.
> > END.
> >
> >
> > What I'm seeing, this BPM is being called twice during the Customer update. First time through, ttCustomer contains the database data and the second pass, ttCustomer appears to be using the form data. This is causing a problem for us when we stumble across legacy data that does not have anything in these fields. Basically, the first pass data will trigger the exception and we can never update these fields for those records. I just wanted to check if this is expected behavior and what the recommend solution might be before I hacked something up.
> >
> > Tim
> >
>