is FOB a UDF that you added?  If it was added to SO_SalesOrderHeader, it should automatically be included in the selection grid.  UDFs added to SO_SalesOrderDetail however will not be available to use in the selection grid.  If you must filter at the detail level, you may want to consider adding a run time parameter to the crystal report for the form code used.

No it's not a UDF, I think it's part of the SO_SalesOrderDefaults table.

While looking at the table for something else, i saw the standard FOB field.  Since it is a standard field, you have two options,

1. Create a mirrored UDF for the FOB field and use a script to handle mirroring the data from the standard FOB field to the UDF so the UDF will show up in the selection grid.
2. Modify the crystal report behind the form code and add a runtime parameter to prompt for the FOB to be entered by the user and then use the parameter in the group selection.

While looking at the table for something else, i saw the standard FOB field.  Since it is a standard field, you have two options,

1. Create a mirrored UDF for the FOB field and use a script to handle mirroring the data from the standard FOB field to the UDF so the UDF will show up in the selection grid.
2. Modify the crystal report behind the form code and add a runtime parameter to prompt for the FOB to be entered by the user and then use the parameter in the group selection.

Like this?

sFOB = ""
sUDF = ""

retVal = oBusObj.GetValue("FOB$", sFOB)
retVal = oBusObj.GetValue("UDF_FOB$", sUDF)

if sFOB <> "" Then

retVal = oBusObj.SetValue("UDF_FOB$", sFOB)

end if

You may want to remove the check against the sFOB value in case a user blanks out the standard field, i'm assuming you want the UDF to blanked out as well if this occurs but your script as is will not do that.

So, just no IF statement?

Correct. 

You can assign the script to the post validate event of the FOB field and/or the pre write event of the SO_SalesOrderHeader table.

Assigning it to both events will make sure the UDF will always be updated in case you have some sales orders out there where the FOB has been set already but might get additional changes made to fields other than the FOB field.

Alternatively, you could just assign it to the post validate of the FOB field and then after you implement the script, do an export and import to populate the UDF with the FOB value for all existing orders so moving forward from this point onward, the script will handle mirroring the value.

This isn't working, is it because that FOB field is not in SO Header? It's in SO Defaults...so maybe that "retVal = oBusObj.GetValue("FOB$", sFOB)" is not working?

Yes it is in the Header table.

Defaults are just what they sound like, values used for new SO.

Is scripting turned on?  Check Allow External Access in Company Maintenance.

Is "Allow External Access" checked in company maintenance?  In its simplest form, you should be able to use the following script either on the SO_SalesOrderHeader table's pre-write event AND/OR on the SO_SalesOrderHeader table's FOB column's post-validate event.

sFOB = "" : oBusObj.GetValue "FOB$", sFOB
oBusObj.SetValue "FOB$", sFOB

I got it...didn't realize everything was case sensitive

VBScript isn't case sensitive and you won't have to worry about case most of the time you deal with the sage 100 business object but their are a few exceptions.  GetValue and SetValue are not among the exceptions.

My UDF was not the right case