Scripting

I discovered an odd behavior in the UDS (User Defined Scripting) facility that I am hoping someone can shed light on. I've discovered that in multiple versions of MAS (2016 & 2017) there is a bogus CPV (Column Post Validate) event for the PriceLevel field when it is empty and ANY other field is changed on a detail line (including the comment). The event is triggered at the point that the current (changed) line loses focus. I need to be able to monitor changes to the PriceLevel, but I have difficulty distinguishing when the PriceLevel is actually changed to an empty field value versus some other field changing on the line.

I can't shed light on why it is happening but perhaps a work around. See if you use the following in the post validate event for the price level field. ---------------------------------------------------- sOldPriceLevel = """" sOldPriceLevel = oScript.Evaluate(""cOldVal$"") if sOldPriceLevel <> value then ' Put code here to handle if there is a change. end if ----------------------------------------------------- I can't recall off the top of my head if cOldVal$ is going the have the old value in the post validate but i know it works in the pre validate. So if it dosen't work in post, just assign it to a script storage variable in the pre.

Looks like when the line is normally written (and yes for existing lines where a field value is changed just like you noticed), the regular non-script Write function runs (and coincidentally checks if a PreWrite or PostWrite scripts needs to also run), there is in fact a non-script CPV done on PriceLevel when the current Price Level on the line doesn't match the Customer Price Level and the order was not created with RMA. It's part of a ValidatePriceLevel function in SO_CommonEntryDetail which means same thing occurs in Invoice Data Entry. In short it re-runs the Calculate Price routine if the conditions fit (below) and I presume that does the internal SetValue to PriceLevel which is double-firing your CPV script. As far as how to detect it, I don't see any object property being set that you can check for. I like Mr Speck 2's suggestions to SetStorageVar in the PreVal and check for it in PostVal. Alternately you can extend his cOldVal$ check further to match what the code is checking: sOldPriceLevel = """" : nInValidateAll = 0 : nCreateFromRMA = 0 sOldPriceLevel = oScript.Evaluate(""cOldVal$"") 'original Pricelevel nInvalidateAll = oScript.Evaluate(""cInvalidateAll"") 'internal Validate All flag nCreateFromRMA = oScript.Evaluate(""CreateFromRMA"") 'created from RMA or not IF sOldPriceLevel <> value AND nInvalidateAll = 0 AND nCreateFromRMA = 0 Then ' Put code here to handle if there is a change.

FYI, I got around to testing and cOldVal$ does work in the post validate event.

Thanks David and Alnoor. I'll try checking ""cOldVal$"". Wouldn't this be a bug? CPV scripts trigger on modified fields NOT on differences between similar fields (i.e. Customer Price Level versus sales order Price Level). Also, I'm not understanding what is meant by a ""non-script CPV"". Such an animal would seem to be unrelated to the function of a CPV script. Of course everything looks upside down here in New Zealand.

By non-script CPV I just meant the program itself SO_CommonEntryDetail potentially changes the PriceLevel when you leave the line.

Thanks @AlnoorCassim. What I find particularly troubling with this situation is that the price on the line, which has been set in a QuantityOrdered post CPV, is being recalculated due to the modification of an UDF on the same. I'm sure that I am not the only person to modify price in a CPV, so I am trying to determine what about this situation is unique to be triggering the price recalculation.