Trigger script during SO detail line addition

SOLVED

On Sage 100 Advanced 2018:

I have added a UDF checkbox to CI_Item and SO_SalesOrderDetail, linked so that when a new item is added to the Lines grid the default checkbox state from CI_Item is auto populated. If the value in CI_Item is checked I don't want a user to clear the box, but I can't set the SO Detail field to Read Only because the value is optional for other items so they user may need to change it.

Next I have a script which triggers if a user changes the value of the checkbox. The script will look up the default value in CI_Item and if checked will warn the user they can't change the value, and it restores the checked status. If the CI_Item default is cleared the user may be allowed to check an originally cleared checkbox.

This works beautifully on existing lines and on newly added lines--once the cursor leaves the new line in the grid. My problem is that when entering a new item, if the users tabs over to the checkbox before leaving that line, they are able to clear the checkbox without triggering the script. This is the case whether or not I set it to trigger on column pre-validate or post-validate. I can't use Table Pre-Write because then it would only trigger when saving the entire SO rather than when leaving a new line (it seems... I'm a little fuzzy on event triggers within a grid).

Is there a way to save the line when it is first entered, so that my event script will fire if a change occurs to this column? Or is there any other method I haven't thought of to prevent a user from clearing the box if originally checked, even during a new line entry--while allowing the box to be checked for other items?

Any help will be appreciated.

  • +1
    verified answer

    You should be able to use a combination of the UDF's column pre-validate event (use this to catch when a user attempts to change the value directly via the UDF column in the grid) and the Detail table's pre-write event (use this to enforce the value equals what it needs to before allowing the line to be saved). The Detail pre-write is triggered when a line is attempted to be saved, not the entire order, the Header table's pre-write is triggered when the order is attempted to be saved.

  • 0 in reply to David Speck

    FYI, if you are testing with the line UDF in the upper grid, SetValue doesn't necessarily change what is displayed on screen (even though the command works).  To be sure what is in the UDF, either put it in the lower grid or click to another tab and back to Lines for the screen display to be refreshed.

  • 0 in reply to David Speck

    Thank you for the confirmation, I had tried that but must have run into an unrelated error which thwarted my efforts the first time. This did work.

    I do have a related question. Programmatically, would it be a better practice to:

    1. Create two UDFs in SO_SalesOrderDetail: one to hold the CI_Item default (no user access) and the other to hold the user's potentially changed value

    2. Create only one UDF in SO_SalesOrderDetail, and use oItem to retrieve the current CI_Item UDF default value

    Long into the future I suppose we might change a CI_Item default value and so there might be an advantage in checking against the current default, unless repeated calls to CI_Item during script execution would negatively affect performance? Is there a general guideline or best practice that applies to this scenario?

  • 0 in reply to jcbaker

    When you have to create a new object for a lookup, you may gain efficiency with having the second UDF as you describe, but with SO lines already having a ChildHandle reference to the item record, you're not adding any extra script processing overhead by using it.

  • 0 in reply to jcbaker

    Since it doesn't affect performance, I think the deciding factor is in your explanation.  Is there any reason that you would need to know the value of the Item's field at the time the order was placed, such as for historical reporting?  If so, option #1 is best.