BPM enquiry

[CCK (Chun Kit)]

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

Thanks.

[klincecum (Kevin Lincecum)]

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

[CCK (Chun Kit)]

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

[josecgomez]

@klincecum

You need to be linking ttRecvHed

E10 BPM Slow due to Join?

@knash that same issue does apply to custom code. You should NEVER EVER NEVER join to a ttTable. Weren’t you at our talk? Did ya fall asleep? LoL In this case though the joins are not to the ttTable they are using a primitive within the ttRecord to as a whereClause and that is ok.

[josecgomez]

Full Analysis of Why

Joining "TT" records to regular DB records in BPMs

Ran it in 10.2.100.5 with the Same Results First Test: [image] Ran SQL Profiler Yielded the following SQL Statement SELECT 1 AS [C1], [Extent1].[Company] AS [Company], [Extent1].[ABCCode] AS [ABCCode] FROM [Erp].[ABCCode] AS [Extent1] WHERE ([Extent1].[Company] IN (N'',@p__linq__0)) Note that the above SQL yields 1 record per each entry in ABCCode table for the given Company As a test I decided to create a variable which holds the current ttABCValue [image] Then …

[klincecum (Kevin Lincecum)]

@josecgomez

Full Analysis of Why

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

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.

[josecgomez]

@klincecum

but I don’t quite agree with “never, never, never”

[klincecum (Kevin Lincecum)]

[timshuwy (Tim Shoemaker)]

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.

[klincecum (Kevin Lincecum)]

@timshuwy

joining a TT table to the PartTran table

[josecgomez]

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

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

So I repeat

[CCK (Chun Kit)]

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

[klincecum (Kevin Lincecum)]

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.

[CCK (Chun Kit)]

Criteria in place, thanks again!

[CCK (Chun Kit)]

Did I set the criteria wrongly?

[klincecum (Kevin Lincecum)]

That’s still the same.

More like this:

dsRcvHeadRow will be tt something in yours.

[CCK (Chun Kit)]

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

[CCK (Chun Kit)]

Hi,

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 ?

[klincecum (Kevin Lincecum)]

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

Calling @JasonMcD …

[JasonMcD (Jason McDermott)]

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?

[Edit]
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.