Adding logic to Behavior Required When for a Field and receiving Property xx in Action could not be

EricWorcester

We are adding logic to the Customer Orders form, Customer PO field where if the value of a field (ue_NW_CustomerPoRequired) is checked, then make the Customer PO field required.

The ue_NW_CustomerPoRequired field is new (type check box) that we have added to the Customers form, where our users can check or let unchecked.

I added the ue_NW_CustomerPoRequired field to the IDO collection for the Customer Orders form and then the needed logic.  I was getting the error box displayed below when the Customer Orders form opened.

I finally got this working by adding the ue_NW_CustomerPoRequired to the Customer Orders form as a hidden field.

Is this the right way to do this?

lcleroux

Yes, I do recall that under specific circumstances, the property needs to be in the form (visible or not) for it to be accessed elsewhere in the form. This is why there are so many hidden Edit components in certain forms.

Be careful, to be Cloud compatible, meaning for your developements to be able to go through the various updates/releases, you should create an extension to the IDO and extension to the forms you want to add visibility to your new field. Best practice, add a new tab on the forms that you name ue_....... to be protected against updates and relases from Infor.

Personnaly, I would make your ue_NW_CustomerPoRequired visible on the new tab of Customer Orders but in read-only, for reference. This will allow your users to see that this is a requirement defined at the Customer level and make appropriate inquiries if they feel that this requirement should neot be there for a specific Customer. You could even create a new Edit field to capture the Customer PO when mandatory and copy it on the Infor field. This way you do not have to modify the Vendor part of the form.

GLUG December Final Agenda 2020.xlsx