BPM enquiry

Hi Everyone,

I’m trying to build a BPM which seems simple but couldn’t get it to work.
I wanted to restrict user from receiving PO which is marked as Hold.

I created a BPM on receipt.updatemaster and created a condition to detect orderheld = true, then prompt an error, but it doesn’t seem to work.

Appreciate if someone can find out what is wrong :sweat_smile:


You need to be linking ttRecvHed with Pohead on ponumber and check pohead held

oh silly me, didn’t notice that.
you saved me once again :sweat_smile:


Full Analysis of Why

1 Like

Nice research. I understand, but I don’t quite agree with “never, never, never” :slight_smile:

This wasn’t performance dependent, (well at least I don’t think so?) and was easy to understand.

But yes, pulling out the primitive and using it in a where clause is probably better practice,
for when it does matter.


sad samwise gamgee GIF

if you are joining a TT table to the ABCCode table, then the join probably doesn’t matter, and you can do it… you will not see a performance hit that is measurable.
If you are joining a TT table to the PartTran table, then you might see a huge performance hit due to the number of records in PartTran…

So the word “never ever never” join is maybe overkill, but it is best practice not to do so. I have done it on occasion for quick tests where I dont want to take the extra 2 steps needed to avoid the bad practice.


mother of god danger GIF

1 Like

And that’s why I say “never ver never never never never never” because if you get used to drawing that little arrow between two boxes which is easy and painless one day you are going to draw it between PartTran and LaborDtl and ttLaborHed your server will catch on fire :joy:

it crowd maurice moss GIF

For reference current Production Record Count of those two respectivelly 1.4 mil rows and 1.3 mil rows

So I repeat


1 Like

:grimacing: , can someone advice the proper way for my scenario if there is a risk of performance degradation by joining the TT table?

Probably not much in your case, but →

Set criteria on POHeader, that matches the value of the PO from ttRecvHed.

I don’t use the query widget much, if you can’t reference the tt table directly in criteria,
use the set variable widget you to set one you can use.

Criteria in place, thanks again! :grinning:

Did I set the criteria wrongly? :roll_eyes:

That’s still the same.

More like this:

dsRcvHeadRow will be tt something in yours.

Appreciate the detailed explanation above!
Misunderstood your criteria that you mentioned initially, silly me :sweat_smile:


I found out that by creating the variable above, I wouldn’t be able to create save new receipt line due to the error “There are no records in the table ttRcvHead” in the screenshot below. Tried removing the variable and it worked, did I missed out any steps ? :slight_smile:


I don’t know, maybe I missed a step. I am NOT an expert with the widgets by far.

Calling @JasonMcD

Ha, not an expert either.

But this is just logic flow. For some reason the ttRcvHead dataset is empty at this point in the execution (duh, I know), and I mean you’re not going to change or “fix” that.

So the point here is what, we need the PO Number stored as a variable? (To be used as a criteria in the query.)

Can it be pulled from ttRcvDtl?

Also, I don’t think it applies here (being a new row), but the temp tables can store 2 rows per row, right - the original (RowMod = “” or something) and the new (RowMod = “A” or “U”)?

I really get hazy with that.