On our Sales Entry screen we have an additional UD field called “Related Order” so we can reference child orders to a parent order. We are currently working on a simple BPM to make sure the “Related Order” entered is an existing order in the table.
When testing the BPM, it works as expected and I am getting an error when saving with a Related Order that doesn’t exist(99999). But right after I save a Related Order with a correct Sales Order, I can change the Related Order to any nonexistent order number and the BPM won’t raise an exception. I actually get my Message saying it worked, meaning it is passing by my condition?
I used the tracer and it is using the “MasterUpdate” method. I tried using this Pre-Processing BPM on both the “MasterUpdate” and “Update” method and I am getting the same results. I am new to Epicor and creating BPMs so I apologize if I get confused by any suggestions or questions asked.
On your query, are you getting more than one row? Sometimes the TT table has 2 rows. The changed and unchanged one.
To find out, do a message box and add a field query, or row query (right click in the message) and see what rows are being returned. If you have 2 rows, your condition is going to fail. Or if the unchanged row has what you are changing from, you’ll get one. You probably need to add a filter to the ttTable for only rows with a rowmod. (A, or U).
Actually, when I am able to get the error to pop up for the first save, I still see the changed row here. So I am not sure why it is being accepted after the first save.
I just added a filter to the Query to set rowmod to “U”. Now the BPM is working as expected!
However, I am still pretty confused as to how the solution happened.
the problem as previously stated is that there are TWO rows returned when you modify something vs only ONE row when it is being added. You only want the row with RowMod <> “” (the A or U valued row).
BUT
there is another problem with your BPM. You did a query that links the TT row with a real database row, and that can be bad and very inefficient (taking lots of time). It would be better to:
create a variable for Order Number
Populate the Order number from the TT row with a setter widget
THEN in your condition, instead of connecting the tt row to the Order Header row, you simply filter the order header row by the order number. This will return the value much faster.
There are multiple discussions on this forum about this. example: E10 BPM Slow due to Join?
@Banderson I have seen the tt record joins in BPMs make a HUGE difference… we are talking about BPMs that were taking 200-400 milliseconds reduced down to 5-10 milliseconds. It all depends on the size of the table that you linked the tt record to.
and not all the speed is noticable at first. your test server may not have any load, so the SQL query that is run can run very fast… but in a production environment where the server is already busy, adding a bad query that must execute can take its toll on the entire system.
What I am told is that when you “join” the tt table, it really doesn’t join it the same way as a normal SQL join. Instead it uses it as a filter, so it results in returning the entire database table back, and then filtering off the tt table the “actual” results needed. But if you instead give it a single value to look for, then SQL only returns that one row, making it very quick.
