Hi Meg,

Weird and 'every once in a while' is a developers worst problem. :)  Without seeing the scripts, i have a few questions:

1) Are all of the script's on post-validate events?  

2) Does it only happen for this one user?  Is there workflow different then other people? Are the orders they modify different in anyway?

3) Do you do writing in the scripts? or reading of other lines, that type of thing?

4) Are you doing anything based on security in these scripts (ie user or role specific)?

Hope some of these questions may point us to something.

Elliott

Hi Elliot,

Thanks for your reply. Here are the answers to your questions:

- Yes, all the scripts are on column post-validate events.

- It has only happened to one user. Interestingly, she is also the same user that encountered issues with totals being inconsistent on the Lines and Totals tabs (see sagecity.na.sage.com/.../74743.aspx). However, her workflow seems standard. She also does the majority of our sales orders, so statistically she’s more likely to encounter problems.

- Yes, one script reads from UnitPrice and another writes to UnitPrice.

- No, there isn’t any security checking, or at least there wasn’t at the time these problems arose. Now I have set all the scripts not to fire if the user is the salesperson who has encountered the issues (using oSession.UserCode).

I’ve pasted the three scripts below in case you’re feeling masochistic :-). At the time I didn’t realize the SO Detail table had a PriceOverridden field, so the code could be simplified. But I’m still not sure why it doesn’t work.

Script #1: LINE_RESET Script (a post-validate on Item Code, which I figured would always trigger):

Dim ScriptFiredVar

retVal = oSession.AsObject(oSession.ScriptObject).SetStorageVar("ScriptFiredVar", FALSE)

Script #2: CAPTURE_PRICE Script (a post-validate on Unit Price):

Dim ScriptFiredVar

Dim SalesOrderNum

Dim SalesOrderVar

retVal = oSession.AsObject(oSession.ScriptObject).SetStorageVar("ScriptFiredVar", True)

'Set global variable ScriptFiredVar to True so we know this script fired.

retVal = oBusObj.GetValue("UnitPrice", Price)

retVal = oSession.AsObject(oSession.ScriptObject).SetStorageVar("PriceVar", Price)

'Set global variable PriceVar to price user has entered

retVal = oBusObj.GetValue("SalesOrderNo$", SalesOrderNum)

retVal = oSession.AsObject(oSession.ScriptObject).SetStorageVar("SalesOrderVar", SalesOrderNum)

‘Set global variable SO to current SO number.

Script #3: SET_PRICE Script (a post-validate on BillOption9):

Dim Price

Dim PriceVar

Dim ScriptFiredVar, ScriptFired

Dim SalesOrderNum, SalesOrderVar, CurSalesOrderNo

ScriptFired=FALSE

retVal = oSession.AsObject(oSession.ScriptObject).GetStorageVar("ScriptFiredVar", ScriptFired)

retVal = oSession.AsObject(oSession.ScriptObject).GetStorageVar("SalesOrderVar", SalesOrderNum)

RetVal = oBusObj.GetValue("SalesOrderNo$", CurSalesOrderNo)

if (ScriptFired < 0 and SalesOrderNum = CurSalesOrderNo) Then

'if Capture_Price script fired on this line, do the following. We want to exit the current script if Capture_Price did not fire.

‘The Sales Order check was added in case user has two sales orders open at once. I’m not sure if this matters, but I didn’t want a global price variable set in one SO to be used in a different SO.

RetVal = oSession.AsObject(oSession.ScriptObject).GetStorageVar("PriceVar", Price)

'Retrieve globally stored price that was captured in Capture_Price script

RetVal = oBusObj.SetValue("UnitPrice",Price)

'Set Unit Price to this price

End if

Thanks Meg,

I don't see anything that leaps off the page for me as being a problem.  As you stated there could be some refinement, but should work fine as you said.  Just another couple of questions before I try some of this out here for myself.

1) The purpose is so that after our (Sage) business logic changes the price after the user enters something in BillOption9, that you put back what was previously overridden, correct?

2) Would this user's typical entry be.... Enter an Item Code, Quantity, then override the Price (optionally) and then enter the Bill options?

I'll see if I can get some of the same strange results here using your scripts.

E

Hi Elliott (sorry for misspelling your name the first time) --

1.) Yes, that's the purpose. I am not sure where along the line MAS changes the price back to the default, but it seems to be in the options somewhere. So I have the script override the default after BillOption9.

2.) Yes. Both times it happened it was modifying a pre-existing order, and the second time, she entered a comment-type item in the Item Code, e.g. "/MISC." She didn't edit the other lines.

Hope that helps.

Meg

Hi Elliott,

Just wondering if you'd had any luck replicating this.

One thing I wondered afterwards was whether the Item Code post-write event trigger is at all tied to the Item Code being a standard item code. E.g., maybe an Item Code that begins with the "/" escape character doesn't always initiate a post-write column validation. This might explain some of the behavior I've seen.

Meg

Hi Meg,

Sorry for the delay.   I have played around with your scripts and could not reproduce your results.  The "/" items do generate the post-validate event as well, so I'm not sure that would be it.  

1) Do you have required Bill Options?  If so, does the user press the options button to enter them or do they just try to enter the line and the dialogue appears by itself?

2) In your 3rd script you are testing If ScriptFired<0 and ...  Is this correct?  I had to change this to be a boolean check to get the script to work.  Also, you may want to test with SalesOrderNo + LineKey to ensure you are still on the same line, but that doesn't seem to be our issue either.

Elliott

Hi Elliott,

When I did my testing, I also couldn't get the script to misbehave on the "/" items. But it's good to know those items should always trigger a post-validate event.

To answer your questions:

1.) We do have required Bill Options, which appear automatically after the last column is entered. No button.

2.) I know that seems weird, but that's the code I have. I tried the Boolean first and as I recall I had some problems with it. So I switched to the "<0" comparison, which seemed to work.

So is SalesOrderNo + LineKey one variable, or some kind of combined variable? The scripts do check SalesOrderNo, but not LineKey. That's a good suggestion.

Thanks again for looking at this. I don't want you to go to too much trouble, since it misbehaves pretty rarely. But let me know if anything occurs to you.

Meg

Hi Elliott,

I have a little more info for you. This happened again to a different user. Like with my other colleague, he had been editing a pre-existing sales order. He deleted one line and added another line or two. Once he had put in a custom price for the item on the very last line, the script overrode all the other prices with this same customized price. So all the other lines had the same price as the last item. It seems odd that a script firing off the last line would influence values on earlier lines, but that is obviously what's happening.

Meg

Meg,

I know this issue is a little older, but in case you are still running into this issue..

I wonder if a little validation could fix this issue?  In Script#2 you can set a storage variable to capture the ItemCode or, better yet, the LineKey, and have Script#3 verify that the detail record LineKey matches the storage variable set in Script#2.

Another thing you could try, to narrow your margin for errors:

Right now, it seems possible for a user to alter pricing on one item, then change the option on different line item.  I don't know if you have tried running Script#2 as a PRE VALIDATE on BillOption9, and then setting ScriptFiredVar if detail PriceOverridden = 'Y', but it should also catch a case where the user opens an order that had overridden pricing on it and doesn't change the pricing, but just BillOption9.  

I know i might be making assumptions about your business process, but based on your issue, I think these suggestions could solve your issue.

Hi Wyatt, just wanted to say thanks. I have not yet had a chance to implement your suggestions, but they sound like a good check. Meg