Scripting

Looking to set the Sales Order Header ""Order Type"" field using a Pre-Write script when accepting a Sales Order. If all items have a B/O quantity in full, so a total of zero for Quantity Shipped on all items, I want it to set the Order Type to B. I created this script that loops through the items & tallies up the Total Shipped. It is calculating the total qty shipped correctly & debugging is showing me that the total for all items is 0, yet it just will not change the Order Type to B. Is this a field that is just not allowed to be changed or set? I am not getting any errors; its accepting the order but keeping the Order Type set to S. I added the last couple of lines to the script to show me the new Order Type value, if it changed, during debugging, but I don't need that in there. I am testing this in ABC company on my test system.

Once you add lines to a Sales Order, I don't think you can change the order type to Back Order. What's the value of: retVal = oBusObj.SetValue(""OrderType$"", sBackorder)? You might try SetValueNoValidate but going around the business logic may cause other issues.

Using SO Entry if you can change the order type to Back Order, you should be able to do it in a script. If you can't in the UI, it is very unlikely you'll be able to in a script.

In the PO system, I know that if a line item has a received qty less than the ordered quantity, that line item will trigger the status of the PO as backordered. Perhaps a similar function exists in the SO programming to reset that flag in sales orders. Also, there is a QTY backordered field in the line items table. Makes me wonder if you set just one of those equal tot he QTY Ordered, if that will allow a status change on the order itself.

Once you add lines, you can't manually change the field. You can change it before line items are added, but who knows if the items are back ordered ahead of time? Not many. I am manually making all lines have the Qty Backordered = Qty Ordered during the initial entry, but it doesn't change the Order Type to Back Order; it leaves it Standard. The only way the system triggers it to Back Order is after part of the order is shipped & the rest is back ordered. It then goes from Standard to Back Order until the rest of the order is filled. It seems odd that a fully back ordered order remains a Standard order type or that it doesn't allow me to change it with a script.

I believe that a Sales Order gets to Back Order status when it is partially invoiced.

I wonder if setting a pseudo last invoice number / date would help.

Bummer, @DanaYoung . I was really hoping.............

@MichaelNottoli , yes this is the case, but I need it when the order is created. Not after an invoice is processed.

@KevinMoyes , I will try it

You may wish to try: retVal = oBusObj.SetValueNoValidate(""OrderType$"", sBackorder), but I'd watch out for bogeys.

This would be a good feature. The order appears on the back order report without having to be invoiced with 0 qty shipped. Please post if you get it working.

Dana - Some friendly thoughts here. To protect yourself I think it's a good idea to just take a step back and scope the potential implications of this project further before you get too far. That is, verify you wouldn't be creating new problems since you're going around a system restriction which may have an underlying purpose that's not obvious yet. Maybe what you do before any more scripting is in a copy company, create an order as Standard and set the lines that way you've described, then DFDM the OrderType = B (or set the pseudo Last Invoice No) knowing the front end doesn't allow this. Then step through the whole process of printing the order, the pick sheets, shipping d/e if it exists and packing lists, invoicing the order, verifying some of the Daily Sales Reports, and updating the invoice. See if you also get errors along the way especially during invoicing (especially if there's still backordered qty) and during updating. Then go back to S/O Entry and check your back-ordered lines. Check Order History too. Then decide if you want to script further. Having said that, maybe you've done this scoping already. I'm just mentioning because I've burned myself a few times not having scoped enough and realizing later a 9-headed lurking hyrdra was released.

I didn't think that the quantity on BO in the item warehouse table might not be maintained correctly. Excellent point Alnoor.

Thanks @AlnoorCassim , I will do further testing. I can say they have been marking the line items fully back ordered for years, so the only thing I am changing here would be the Order Type; the items themselves should perform the same way they have been. I will push some orders all the way through & see if it blows anything up.

Sorry, can't resist. :-)

Another thought is ""why do this""? If it is just a reporting requirement, I'd think a UDF and custom reports would be far less risky than trying to change a program controlled field value (the full impact of which may be difficult to determine in advance).

Maybe you have tried this.... Have you thought of initially setting the order to 'B' and using your logic to change it back to 'S'? I have not tried it, but if you can do that by hand, perhaps your script can as well. Perhaps I missed it, but what did your SetValue() in your original script return? Also useful to look at oLines'LastErrorMsg$ when you get an error returned. My two cents....