Kevin M Just curious, does the oLines.MoveFirst() fail?  (I'm guessing it doesn't and returns the first line  of the first order on file)  This is a chicken and the egg issue, because the Warehouse Validation is being kicked off because of the warehouse being set in the SetDefaults() which happens before the lines are actually loaded into memory.  Off the top of my head, this will not be an easy fix, however, let me have a look.  You could also grab the order number from the .MoveFirst() call and see if it matches your current order, but your band-aid is probably a better one.  

Stay tuned.

E

Elliott,

There is no failure (retVal = 1).  The MoveFirst ends up in the first open SO detail record, then MoveNext effectively scrolls through the entire table. 

Luckily the SetValue / Write in the Live script fails to change anything (because those lines are not entered through the associated SO header), which is why we didn't notice it earlier.  (When I wrote the script on my ABC system, scrolling through all rows is not a big deal, but on the customer system it is a delay of over a minute).

Edit:

And thanks for taking a look. 

Kevin, I know you were able to work around this by setting the browse filter yourself but have you tried calling the header's SetCurrentKey method and passing it the value from the header's GetKeyPadded method?

Sage 100 File Layouts and Object Reference - SY_LineEntryHeader_BUS

David,

I'd be wary of messing with the header key while creating a new record. 

Remember, this is triggering during the setting of default values when clicking # Next SO, and everything may not be in place yet, plus the header record should already be in an edit state.  I just needed the Lines object to not have unfiltered access to all Lines (which for existing SO is pre-filtered as expected... but wrongly unfiltered for new SO).

From the documentation, SetCurrentKey should set up the lines.  I have ran into 1 or 2 situations where I had to call it but can't recall exactly why and what they were.  Just thought that maybe it was worth testing because it might accomplish additional things which could be good or bad at that point.  Would probably need jepritch to weigh in.

I thought I would add to this, same exact issue but it actually caused a pop-up box to appear in 2022 after moving to 64-bit on the server that you could only see if running as an application.  A pop-up appeared after hitting next number and waiting a few seconds that said the script you are executing is taking longer than expected to run.  This was a post validate script on the warehouse code meant to update the lines.  The adding of the retVal = oLines.SetBrowseFilter(sSalesOrderNo) right before the .movefirst did resolve it for me as well.

Thanks Kevin for the post, still relevant two years later :)