I am trying to do a logging for sales orders when they are closed or opened. It is working, except that I am getting a duplicate entry error. I understand the Open one because I need help figuring out a clean way to make it check only the first time the order was entered—the closing one; I do not understand unless something runs twice.
I am currently trying to run open on Erp.SalesOrder.GetNewOrderHed, but the problem there is the sales order number is not generated yet, even during Post-Processing. Which is one of my primary keys. I also tried to run this on the update, but that was worse. I was then going to make a 4th primary key that incremented by one, but then during the reporting phase, I would have to search for the highest record. Then, I would be putting useless data into that table because I only need one record.
invoke BO to UD04.GetaNewUD04
Set key1 to OrderHed (for reporting purposes)
Set key2 to OrderNum
Set key3 to CustNum
Set Charater1 to PONum
Set Date1 to OrderDate
Set Shortchar3 to callContextClient.CurrentUserID
Set Character3 to DateTime.Now.ToString()
invoke BO to UD04.update
The closing one I do not understand at all. I am doing it on Erp.SalesOrder.CloseOrder Post-Processing.
Condition OrderHed.OpenOrder all rows is equal to false
invoke BO to UD04.GetaNewUD04
Set key1 to OrderHed (for reporting purposes)
Set key2 to OrderNum
Set key3 to CustNum
Set Charater1 to PONum
Set Date1 to OrderDate
Set Shortchar4 to callContextClient.CurrentUserID
Set Character4 to DateTime.Now.ToString()
invoke BO to UD04.update
I assume you have a full client trace (with full data set)? I am guessing, but the CloseOrder method may fire for each line item on the order, but only get to the second line when it gets the error and then stops execution. I would also check that the CloseOrder method retains the dataset data where you can use the Order Closed flag. The trace’s full data set would show if you’re missing something.
It is logging and displaying the data. I had dummy error messages in there at first displaying each field i was trying to track and write to a table to ensure the data was good.
The client trace doesn’t show the CloseOrder method firing more than once? then I’m stumped, unless the server trace shows something else. I suppose the server could be doing it without logging it to the client trace.
Just before you do the UD04.Update, you could do a UD04.Get method call to see if the record exists, then decide how to proceed…
Sorry, no. I’ve not run into this problem though you should post back here when you figure out what the problem is. I’d give in a few hours though - some of the guys who may have an answer for you might not have seen your post yet.
@jrhodesMVP - what is the end goal? Data Directives have a ChangeLog widget that automatically logs whatever fields on whatever tables you tell it. I’m assuming this is not sufficient but I wanted to ask the question at least.
The end goal is to be able to report on this via a dashboard. The company I was at before decided to go the route are parsing the change log and that was a mess and the query ran so SLOW. This time around I am looking to write to UD04 and create a simple BAQ and dashboard that they can pull up any and all orders and see open and close times.
How was it worse? In theory, you could use the Update method for both ends but just look for when the OpenOrder field changes from true to false. Or to follow the logic of the ChangeLog, you could fire it at the Data Directive level doing the same thing. Then it wouldn’t matter what method opened/closed the order.
this is the OpenOrder tracking on Update. If I am thinking about it how @dr_dan explained it. The flag goes from False to True when the order first get opened.
Since you’re doing it post processing, I bet it’s losing visibility of what changed. Do a test where you just pop up a message box and show the table ds.OrderHed and select the fields that you are trying to use and make sure they are actually showing data. I’ve experienced issues numerous times on PostProcessing where stuff that you would expect would be there is not.
The order number will never be available to the GetNewOrderHed method. That just gets the new order, sets defaults and displays it to the UI. At that point, your UI is still showing 0 as the order number. You’d have to wait until the post-processing method Update or MasterUpdate on a new record to have the order number available.
As far as closing sales orders, while you can close sales orders from Order Entry, most of the time orders get closed via the shipping process, so the SalesOrder methods aren’t a factor. If you’re looking for it in the SalesOrder.Update method, that’s not firing when it’s closed because a shipment was created that closes the order.
I’d go with the recommendation to use the change logs. If it’s running painfully slow, my guess is that you’re not using the indexes to the tables correctly. Check your BAQ and your links among tables.
they are specifically looking for when sales people close orders and how often. That is why I am doing it on the salesorder side instead of the shipping side.
Could be. Do you have the option to include unchanged rows in your message? It may be that the value is present but that it doesn’t see the unchanged value. In theory, you’d see both an updated row and non-updated row. If this is the case, you can probably enable the post-processing directive from a pre-processing where you listen for the OpenOrder field to change from true to false. Then when that condition is met, use the Enable Post-Processing widget. Then in Post-Processing, you could set a condition that says “when enabled from XXX pre-preprocessing”
I do not believe it’s possible to create a new order and have it be closed. So, on the update, if you condition is “there is at least one added row” in your pre-processing, set an action to enable post-processing directives. Then, in the post, you’d have your order number and the OpenOrder flag should be false.
Or, your condition in the update could be:
there is at least one added row
OR the OrderHed.OpenOrder field has been changed from any to any
You’ll still want your logic in the post as the order number would not be available for new records in the pre.
