E10 - BPM to prevent record update and revert record/screen

Epicor ERP 10
1

There are a few topics regarding this issue, but none quite address my specific case, and I just can’t seem to figure out the best way to accomplish my objective - based on a triggering event (SalesOrderEntry.ChangeShipToID) I inspect a field on the desired ShipTo record, and if flagged, should be rejected with an alert to the user.

Using both pre and post-processing directives, I can perform the inspection and launch the error message.
I can’t, however, revert the screen back to state before the change. This means the change ultimately proceeds if the user clicks save.

In an older post, someone suggested that this should be accomplished via a customization where access to the UI is available. I can do this, but I’ve updating all of my BPMs, pre-E10 migration, and it sure would be nice to keep all my record handling ‘stuff’ under the BPM umbrella.

Question: BPM or customization?

In anticipation of the “Of course, Customization” response, I believe this involves writing a short routine, under the “AfterAdapterMethod”, to get the ShipTo record ByID, perform the inspection/rejection, followed by oTrans.Refresh(). Sound correct?

Any thoughts re: best practices here?

2

Have you tried Data Directive In Tran instead?

1 Like
3

Are you throwing an informational message or an exception. An exception should prevent the method from completing.

That or…
Set the tt feild back to the previous value. Which should be the Db record.

ttOrderHedRow.ShipTo = ( from row in Db.OrderHed Where row.OrderNum == ttOrderHed.OrderNum select row.ShipTo).FirstOrDefault();

1 Like
4

Thank you @anyac my eyes glaze over whenever I’m forced to think of dealing with transactions, and I don’t understand what you’re recommending here.

@zwilli526, to answer your question, I tried throwing an exception with my message as the payload. This did not prevent the method from changing the data OR terminate the method - probably because the selection of a new ShipTo record did not cause an error. I believe I’d need to add error handling (duh!) and incorporate the recommendation in the last part of your post. I’m not sure if that would update the user interface… but it might!

I’m going to try this and get back to you!

5

If you put your validation logic into the “PRE” processing of changing the address, then you can put an exception message and it should automatically revert. But when you do it pre processing, it probbably has the new value passed to you in a parameter.

2 Likes
6

I don’ t think that is the way it works with the exception message. You can do it with an informational message and fill in the previous data like @zwilli526 mentioned. The exception message terminates the method and does not revert the data in the UI.
** Disclaimer ** Unless there is some undocumented feature :slight_smile: or maybe one I did not read

1 Like
7

So, I have a post-proc directive with a try/catch block which allows me to implement @zwilli526’s recommendation. Thanks @danbedwards for the info on the informational message, because the exception message does not display. So I send the info message, then throw the exception and fill in the previous ShipToNum.

It ‘sortof’ works; Because the ShipToNum field is correctly reverted, the original shipto record data is reverted - even though the UI still shows data fields from the incorrectly-selected ShipTo record. Since these are bound to the associated ShipTo table, I cannot update these.

@timshuwy’s recommendation does the trick. Since it is a pre-proc directive, reverting the ShipToNum before the BO grabs the incorrect ShipTo record ensures that the screen doesn’t get populated with the bad shipto data in the first place.

Thanks to all for your comments!

Edit: The Pre-Proc reverts the ShipToNum before the BO UPDATES the DB (I incorrectly said ‘grabs’).

1 Like