Script to only fire off Once

Before I start to write this script, is there a way to only allow a script to fire off once?  Background of the script I will create:  Need to populate the "SO DETAILS PURCHASEORDERNO" if blank with a "C" for all customers except 3 or 4, and only on lines with vendorno = "0001226".  However, I don't want the script to fire off every time an update is made to the SO, or if we delete the "C" in the POno field.  Basically, do not want the "C" to reappear if we delete it or for a legitimate POno to get overwritten by the "C".

Parents
  • Why couldn't you use a Column-Post Validate event on the ItemCode field to fill the PO No. field for your conditions. It would only fire once per ItemCode and not when otherwise changing the line. 

Reply
  • Why couldn't you use a Column-Post Validate event on the ItemCode field to fill the PO No. field for your conditions. It would only fire once per ItemCode and not when otherwise changing the line. 

Children
  • in reply to connex

    Sorry but I am not following you on this code wise.

  • in reply to jland47

    I said you can't prevent an event script from running more than once, but what connex is suggesting is using an event trigger (column post-validate on ItemCode) that naturally will only run once per line.  After you set a line's ItemCode, it never changes.

    If your business logic can be properly applied at that point, it is an excellent idea, and easier than the checkbox.

  • in reply to Kevin M

    I simplified the script without the checkbox and it populates the purchaseorderno field with the "C", however it does it no matter the customerno, so I have something wrong there.  Also curious on if I want the "C" value to be set only if a PO is not created, the column post-validate with this script fires off right after you enter the item code, I would think we would need it to look at the field after the record was written, gives the user a chance to create a PO if needed without going and deleting the "C".

    If oSession.CompanyCode = "ROI" then
    
    nCustomerNo = ""
    nVendorno = ""
    nPOno = ""
    
    rVal = oBusObj.GetValue("CustomerNo$", nCustomerNo)
    rVal = oBusObj.GetValue("VendorNo$", nVendorNo)
    rVal = oBusObj.GetValue("PurchaseOrderNo$", nPOno)
    
    	If nCustomerNo <> "2861000" or "2303006" then
    
    		If nVendorno = "0001226" then		
    
    			If nPOno = "" then			
    			rVal = oBusObj.SetValue("PurchaseOrderNo$", "C")
    			
    			End if	
    		End if
    	End if
    End if

  • in reply to jland47

    The business process is up to you.  For a pre-write event on the detail table you'd need the checkbox for control.

    Use oHeaderObj for your GetValue on CustomerNo (since it is a header field).

    Your filter on nCustomerNo is all wrong (and I'm surprised you don't get a VBScript syntax error).  Try something like this:

    variable <> "A" and variable <> "B"

  • in reply to connex

    Column Post Validate on ItemCode should work if on a version that allows selecting it (older versions didn't but I think 2020+ does in a detail script).

    A table Post Read event filtered by oBusObj.EditState = 2 also works and once the record is saved, the EditState will be equal to 1.

    Another event could be the Set Default Values one, I haven't used it much but it is supposed to run when default values are being set by the business object on new records.

  • in reply to David_Speck

    Column Post-Validate is in every version since script events were introduced in 2010 with version 4.40. I think it is your safest bet because any event that precedes setting the ItemCode will cause the PO number field to be cleared.

  • in reply to connex

    The event existed since 4.4 but in certain tables, certain columns were not selectable on column events.  I seem to recall at one point, the ItemCode column could not be selected on detail tables.  I can't recall what version was the last version I saw this on though, I did just check my 2018 install and it can be selected so it may have been corrected in 2018 or maybe 2017.

  • in reply to David_Speck

    Column-Post Validate and table pre-write both work good in every aspect except the script puts the "C" value in the PO field as soon as the item code is entered, I would like it to wait until the user decides if they want to generate a PO first.  Also tried the table post read with the "editstate" filter, couldn't get the script to fire at all.  Seems like I am close with the first two events maybe just a logic sequence problem?  Here's the corrected script .

    If oSession.CompanyCode = "ROI" then
    
    sCCheckBox = ""
    nCustomerNo = ""
    nVendorno = ""
    nPOno = ""
    
    rVal = oBusObj.GetValue("UDF_CCHECKBOX$", sCCheckBox)
    rVal = oHeaderObj.GetValue("CustomerNo$", nCustomerNo)
    rVal = oBusObj.GetValue("VendorNo$", nVendorNo)
    rVal = oBusObj.GetValue("PurchaseOrderNo$", nPOno)
    
    	If sCCheckbox = "N" then
    
    		If nCustomerNo <> "2861000" and nCustomerNo <> "2303006" then
    
    			If nVendorno = "0001226" then		
    
    				If nPOno = "" then			
    				rVal = oBusObj.SetValue("PurchaseOrderNo$", "C")
    				rVal = oBusObj.SetValue("UDF_CCHECKBOX$", "Y")
    				
    				End if
    			End if	
    		End if
    	End if
    End if

  • in reply to jland47

    If you want to give the user an opportunity to create a PO first, then a line level script is not the way to do this.  You'll want to switch to the pre-write event on the header table.  Grab the customer number and if appropriate, loop through each line using the same criteria against the checkbox and purchase order number and for each line that meets your criteria, set the purchase order number.  You can restrict this to new records only by checking if oBusObj.EditState = 2 so it doesn't run on existing orders.

  • in reply to jland47

    Remove the column trigger, and just leave the line pre-write.  They'd have to add the value before moving off the line for the first time, but that is the best you can do in a line script.

    David,

    I always recommend use of pre-totals for header scripts instead of pre-write, since $ changes in a header pre-write script cause serious problems.