I’m working on a BPM to restrict deleting an order if it’s been more than one business day since the order was created. The condition is not picking up the
statement, and always goes False.
I tried simplifying it to ‘today’ for testing. What am I missing? How would I test this (so I can get better at troubleshooting)?
First off, OrderHed.OrderDate is user changable. So if an Order was entered on Friday 3/13, (with an Order date of 3/13), you could just change it on Monday to 3/16, and then delete it.
Make a BPM to set OrderHed.UserDate4 to the current date when the order is saved created. Then compare that date to the current date when checking if it can be deleted.
That still allows deleting lines and releases, but not the order head.
edit
one more thing. Not only can a user change the OrderHed.OrderDate, they can delete it. So how would you know how old the order is then? And comparing a date to a null, might throw an error.
Other ways to do the “freezing” of the order date:
secure the OrderDate so that it cannot be changed from anything other than “Today”… This can be done with a BPM… OR a UI change (not preferred by me).
Create a new UD Field called EnteredDate_c which is auto filled (with BPM) with the date that the order was entered. This way the Order date could be yesterday, but the Entered date could be today.
It’s now working (thanks for the example, Calvin) - I think the error was PICNIC, as I had my user in the security group that allows deletion. Oops!
Calvin & Tim - Thank you. I’ll be adding something to handle the potential for the OrderDate being able to be changed.
My next step for this BPM is to make sure the cancellation reason is set, but that’s not firing (BPM on Erp.SalesOrder/CloseOrder/Pre). I did a trace on Action > Orders > Close Order, and it doesn’t seem to be passing any data at all. I was hoping to check for CancelReason_c being “” or Null, and popping up an exception if it was not set.
I then tried checking if it’s closed using the VOID field, and that goes FALSE every time as well:
This is all I get with a trace, even with Write Full DataSet selected:
May need to use an in-trans data directive for this part. It looks like the CloseOrder call only gets access to the required info in its returnValues data set, so you won’t be able to access anything from the SalesOrderTableset unless you use a post-processing directive (which doesn’t do you much good since you are trying to check and possibly stop the transaction).
Since we like to make everything complicated, I’d like to do this for lines as well (sometimes we cancel some lines from an order, but need to keep the lines that may have already been manufactured).
When someone chooses a cancel reason on the header, I’d like to push that UD field from the OrderHed to all lines on the OrderDtl table. What’s the simplest way to do that? My search-fu didn’t find anything…
All of the ines for that order? Or just open lines? (I don’t think you’d want to set the CancelationReason_c field on a line that was already fulfilled.
And to update the OrderDtl records, an InTran could set ttOrderDtl.CancelationReason_c based on the value found in the OrderHed record. Conditional on the line status going from Open to Closed, and maybe some other checks to make sure its being closed from the OrderEntry UI, and not from a shipment.
Thanks - Good point. The devil is in the details, eh? All open lines should have the OrderDtl.CancelReason_c field set to the OrderHed.CancelReason_c when you go to Actions > Order > Cancel Order.
I’ll try that, using the OrderDtl.VoidLine = TRUE for the condition. Thanks!