BPM | Prevent Duplicates with Multiple Criteria

@josecgomez Thanks for the link to Tim’s post. I’m using method 4 right now, but will take a look at implementing the latest method in my customizations.

My concern isn’t so much how to autonumber, but how do I verify that the new record being created isn’t a duplicate entry based on specific criteria that I define. The BPM query I’m using right now works perfectly, but its the tt table join that has me concerned.

if you remove the join, then add a criteria to eh ice.UD100A table, for each of those things, you can return rows for when those things match. That will work better than the join for TT table.

Plus, That join to the TT table has been used by a lot of things for a long time. If you aren’t having problems with it now, I don’t think I would worry about it too much. If you start having performance problems, that’s when I would start looking at that.

1 Like

We need to start another discussion around the TT Table join… I have done some internal research hear at Epicor, and I think that there may be too much made over this… I will start the new thread.

2 Likes

@Banderson Thank you for your suggestion. This works perfectly.

1 Like

So what’s the rule on how long you have to know something that you learned from someone else before you get to take credit for it? (since we learn pretty much everything from someone else at sometime right?) I learned this from @josecgomez :+1:

1 Like

Hi @Banderson as a note @timshuwy and I did some more testing on this this week and that approach is not any better. Epicor in its infinite wisdom does a CROSS Join in the back end where 1==1. :frowning:
See

Though you did learn that from me, now un-learn it. The best approach is to assign the ttKey1, etc to a variables and then use the filter.

HA, good thing I gave you credit!!

1 Like

I’m not sure I am understanding what you mean by this. Can you give me a quick explanation? I was looking through the other post, and I didn’t quite get it.

In the BPM you can create variables and assign the current ttXX. Value to that variable then use that variable in your BAQ Condition.

image

Then you can use this guy
image

To Set the value of that variable
image
Like So

image

Then in your BAQ Condition, Add your table (not the ttTable) and use that variable in your condition (filter)

1 Like

well isn’t that the long way around.

Good to know. Thanks.

You can always say F* it all and go Code first it’s what I do…

1 Like

image
LoL

1 Like

Did you mean F# ?

The only F# I ever hit is the notes in the song while I’m showering #Shudder

1 Like

It works!
V2.0
Runs < .5 sec faster than V1.0 (Soooo much speedz)

2 Likes

Look at that a whole half second gained… multiply times many times a day and you’ll be saving minutes in no time LMAO

how long did V1 take?

.5 seconds longer
image

2 Likes

I just re-did a BPM that is on the OrderRel table… average size order is 25 lines… save time per line for this ONE BPM was .2 seconds… times 25, becomes 5 seconds.
After refactoring, and changing to no TT Join: .02 per release… now it is only 1/2 second for 25 lines. still could be better, but it does quite a bit of work.
image

1 Like