How do you get around the issue of a customer sending in a purchase order with a certain price and then you charging them a price that was not agreed to when accepting the purchase order.

Hello BigLouie,

We send out price change notifications to our customers. We've got a database publishing system for that. 

Normally i train the newest office person on how to look up each item and then each sales order and hit the "calc" button. But this morning I imported price changes to over 1200 existing items in MAS and so it seems crazy to manually go in and hit that "calc" button.

best wishes, Kristin

Well, i had the newest guy go through all the sales orders and hit "recalc". Someday it would be good to figure out how to do the scripting for this.

The SO_SalesOrder_bus object does have a PriceRecalculation() funciton.  I haven't tried using it, but you could theoretically call it on PreWrite() of the SO business object and/or create a script that runs on a scheduled basis that browses through all open SO's, recalcs the prices, and saves the changes.

As a safe option, I'd go with a header table post-read script, filtered to the SO Entry UI... to invoke the recalc button, so the user would not have to remember to do this each time.  Using something in the business object you'd have to be careful to avoid problems during posting, but invoking the button doesn't have this kind of complication.

here is a thought. A bit late but could be fun. Export to Access the Sales Order header and detail tables. Import your file with price changes. Create a query building a new file. All you really need is for the header is the sales order number, division number, customer number, for the lines just the item number, Line Key and Line Sequence Number and the new price. The frame work will take care of the rest when importing.

Here's another idea, set up a VI import with ODBC as the source and point it to the SOTAMAS90 DSN or a custom DSN with credentials and company saved it in, if using SOTAMAS90, you can click the "Key" button to save the credentials, to specify the company code, enter it in the login user name field following the actual user login name but separated by the vertical pipe ("|").

Next click the Tables button and add the SO_SalesOrderHeader table, then click the Fields tab and add the SalesOrderNo field, then click the Accept button. This will target all sales orders.

Back on the main screen, click the Data tab and add the H.SalesOrderNo field. 

Add a temp field and configure it like the following.

Here's the calculation's code.

"";IF cTest=0 AND coBusiness'EditState=1 THEN {coBusiness'PriceRecalculation()}

This uses the business objects PriceRecalculation method to do exactly what you want while leverage VI to do the heavy lifting of cycling through the records. 

You can use any combination of a SQL WHERE clause, VI Select Logic, and VI Skip logic to narrow down the records.

Based on your post, you even use the following SQL (remove all fields and tables, click the SQL tab then click the Modify button).

SELECT "SO_SalesOrderHeader"."SalesOrderNo"
FROM "SO_SalesOrderHeader" "SO_SalesOrderHeader", "SO_SalesOrderDetail" "SO_SalesOrderDetail", {oj "CI_Item" "CI_Item" LEFT OUTER JOIN "IM_PriceCode" "IM_PriceCode" ON "CI_Item"."ItemCode"="IM_PriceCode"."CustomerPriceLevel"}
WHERE ("SO_SalesOrderHeader"."SalesOrderNo"="SO_SalesOrderDetail"."SalesOrderNo") AND ("SO_SalesOrderDetail"."ItemCode"="CI_Item"."ItemCode") AND (("CI_Item"."DateUpdated">={Fn CurDate()}-30) OR ("IM_PriceCode"."DateUpdated">={Fn CurDate()}-30))
GROUP BY "SO_SalesOrderHeader"."SalesOrderNo"
ORDER BY "SO_SalesOrderHeader"."SalesOrderNo"

The above SQL will group by the sales order and also only pick up records where a matching item that exists on a sales order who's price code record has been updated in the last 30 days or if the item itself was updated in the last 30 days. This was just for fun but you can see how granular you can get with this.

A combination of Justin's idea to use PriceRecalculation and Kevin's idea of the event (post read) along with filtering for the program is a good way to make sure that when a sales order is pulled up in sales order entry, the prices are recalculated automatically but the user would still need to click Accept to commit the changes. To filter it down so that it only executes in Sales order Entry, check if the oSession.StartProgram is SO_SalesOrder_UI and oBusObj.SecurityAccess is greater than or equal to 2

If it would be problematic for every order opened to be recalculated, i.e, overwriting a legitimately reduced price for an item, then you could narrow it down with conditional logic in the script.

BigLouie's idea is good too if you have a list of the items that actually got updated prices, you can use his entire approach and import the price or just use his approach to identify the orders that need to be recalculated and use my approach to trigger the PriceRecalculation method.