Be careful with Advanced Field Settings.  If you make a field in SO header required, without checking existing SO, you will end up breaking the invoice posting process which updates SO.  If you make a field in CI_Item required, you just might break the ability to add / edit Miscellaneous Items / Charge codes (because they are stored in the same place).

Scripts give the most control because the logic can be filtered many different ways.

Good to know! So in addition to using a script to avoid these issues, we should probably run a VI job to update any blank values in the to-be-required field?

VI job or manual entry.  Think it through for each situation.  What could break by making a field in that table required?  Go through every business process.  If you generate PO from SO, making a PO field required will probably break that function unless you handle it.  If you use RMA, that may break by adding a required field certain SO / SO invoice tables.  What about posting?

Kevin is right, a super useful way to filter a script using the header or main table's Pre-Write event and the oScript.SetError method is by filtering on the UI object's screen name (nomads library).  This allows you to make sure it is only enforced when the user is actually in a specific task, such as Sales Order Entry (SO_SalesOrder.m4l).  the oSession.StartProgram can work but you have to be careful of tasks that can be spawned from another task, like clicking the "Customer No." hyperlink in Sales Order Entry will still cause the oSession.StartProgram property to equal "SO_SalesOrder_UI".

Below is an excerpt from another one of my posts.

A lot of things of may trigger an object's post read event so you need to further filter your script, one way to do it is checking the oSessionStartProgram but this is always accurate when a user drills down to an item from another task, so another way to do it is check for the presence of the UI object using oScript.UIObj <> 0, then if it isn't 0, you can use oSession.AsObject(oScript.UIObj).GetScreenName() and check that it is equal to "IM_Item.m4l".  Below is an example of what is returned by the GetScreenName, GetPanelName, and GetFolderName methods of the UI object when in Item Inquiry/Maintenance.  Whenever I do a check against stuff like this, I always convert both strings to upper case to avoid case sensitive mismatching.  It wouldn't hurt to also filter for oSession.Updating = 0.

Another helpful one that you can use is coSession.Updating which is a flag that is set when a register/update process is what began the session.  This will account for things like updating orders within the Sales Journal process.  This should have a 1 (True) or 0 (False).

If we are posting a list of filters, here's mine.

---------------------------------------------------

oSession.Updating

Are we in the middle of an update? Value returned as numeric

1 = Yes 0 = No

If oSession.Updating = 0 Then

'Run script code

End If

---------------------------------------------------

oSession.ModuleCode

Module code (e.g. A/P). For Library Master the module code is SYS

if oSession.ModuleCode = "V/I" then

' do stuff

end if

---------------------------------------------------

oSession.CompanyCode

if oSession.CompanyCode = "TST" then

' do stuff

end if

---------------------------------------------------

IsMember of a Role

retVal = oSession.AsObject(oSession.Security).IsMember("rolename")

Will return a value > 0 if user belongs to specified security role or 0 if not a member.

---------------------------------------------------

oSession.StartProgram

If oSession.StartProgram <> "SO_SALESORDER_UI" Then

Exit sub

End If

*** TIP ***

Find the StartProgram with a simple pop-up:

retVal = oSession.AsObject(oSession.UI).MessageBox(oSession.StartProgram)

---------------------------------------------------

oSession.UI

if oSession.UI = 0   'this means that UI is not running

if oSession.UI <> 0   'this means that UI is running

---------------------------------------------------

oBusObj.SecurityAccess

if oBusObj.SecurityAccess = 0 then ' Inquiry screen or user only has View permission.

0 equals View only.

2 equals Modify with View implied.

3 equals Create with View and Modify implied.

4 equals Remove with View implied.

6 equals Modify and Remove with View implied.

7 equals Create, Modify, and Remove with View implied.

---------------------------------------------------

ScanForce

if oBusObj.FromScanForce <> 1

' this means that the process thread is not a ScanForce import... may need to use oHeaderObj if a detail table event trigger.

---------------------------------------------------

retval = 0

if oBusObj.EditState = 1 then 'existing record

retVal = oSession.AsObject(oSession.UI).MessageBox("Existing Record")

else if oBusObj.EditState = 2 then 'new record

retVal = oSession.AsObject(oSession.UI).MessageBox("New Record")

else ' edit state 0 the only other option

retVal = oSession.AsObject(oSession.UI).MessageBox("No Record in memory")

end if

end if

FYI, the last time I had to observe oSession.Updating on a 2018 install, it was 0 for not updating and either a 5 or 6 digit number if it was updating so filtering for a 1 would not give you the results you are expecting so now I check if it is 0 (not updating) or not 0 (is updating) instead of is 1

If oSession.Updating = 0 Then
    ' Not updating
End If

If oSession.Updating <> 0 Then
    ' Is updating
End If

You can check if the current session is through the Sage 100 desktop or through the COM object using the following.

If oSession.ObjectInterface = 0 Then
    ' Launched from Sage 100 Desktop
End If

If oSession.ObjectInterface <> 0 Then
    ' Launched from COM object
End If

That Updating filter has been hit and miss for me... that might explain why!

I think it probably varies, so your method David Speck is the best.