Blocking transactions for parts without STD cost

I just have that meme from this post in my head every time I read ttTables @josecgomez :laughing:

4 Likes

Don’t touch the third rail

Don’t eat yellow snow

Don’t join to a tt table.

Some rules just stick.

3 Likes

one of my prouder ones.

4 Likes

i think this worried me in the past before i started making bpms. From the few ive made, my understanding is that the bpm only pulls the active data. So in this case its pulling the part number i have in the job, not all of them like a normal query would so theres no need for filtering.

That is… hard to believe.

Especially with Job Entry. The job has a part number, and the material has part numbers, as do the assemblies and JobProd and on and on… And all of that is in the JobEntry data set.

So, which part(s) would it know that you meant to check the cost on?

maybe its something to do with the ā€œCheckPrePartInfoā€ method code? Does that just look at the job part and it disregards anything else attached to the job?

edit: this has worked for me at 2 different companies, one on 10.2 and one on kinetic 2024

I’m not looking at it but you may be right that that particular method is streamlined to one part. Maybe.

But I am pretty sure that that BPM query editor is wide open and you need to filter it.

To make the point.

BPM on Part Update. Check if Inventory UOM is ā€œINā€ (inches). Fire message if query returns one or more rows…

As expected, this part is in inches, message fires:

Screenshot 2024-11-08 124915

This part is not in inches; message still fires. (I cleared the screen to be safe.)

Conclusion: BPM is checking all parts in the table that meet the condition(s).

1 Like

Or to be even more direct:

Check for a single part number in the table.

Message fires on any part that is updated.
image

image

1 Like

We kept it very simple and only allow a part to be activated if there is standard material cost at a minimum (preprocess BPM). That prevents it from getting on jobs without a cost estimate (or transacted in any way). It also keeps cost roll ups clean as we have a simple query tool showing any active parts with inactive parts in their BOMs.

1 Like

Hi,
I joined JobHead like below to filter the Part. But still, all parts are blocked whether they have STD or not. How do I join it?

It looks like if it has a std cost (true) based on your query that it will stop. You are looking to stop if it does not have one I’m guessing you would need to change your condition to be either less than 1 OR raise exception from the FALSE side of the condition block.

Sure, but I mean it depends on the criteria on PartCost.StdMaterialCost - whether it is = 0 or <> 0. Last pic I see he had it as = 0.

@pilio.lee is literally half a world away, so I don’t know when he will read this - usually about 12 hours after many of us reply.

My point is, I know it would make more sense for him to answer, but it will be a little while…

Actually, I tried everything you mentioned. I think I tried about 100 cases in the last 3 days. And in every case, whether or not I had an STD, I got the same result.
All parts passed, or all parts were blocked.
So I’m thinking of giving up if I don’t make any more progress.


  1. Joining JobHead to PartCost makes sense enough
  2. How are they joined? Company and PartNum?
  3. Let’s go with your criteria of StdMaterialCost <> 0
  4. The line/connector thing is coming from True - this makes sense
  5. Condition should be ā€œNumber of rows… is exactly zeroā€ (not more)

Check on #2.

But #5 is what is messing you up I think.

3 Likes

Looking at this looks like you are using the ENTIRE JobHead table and not just the row for your JobHead.PartNum as it has no condition.

You should possibly set a condition on the ERP.JobHead where JobHead.PartNum = @partNum

2 Likes

Awesome! It was this one. My previous BPM was using the ENTIRE JobHead table. After I set it up like this, the parts with and without STD work differently. Something that I’ve been struggling with for a week has been resolved. Good!

2 Likes

Thanks Jason,
I changed the criteria to ā€œ<>ā€ and changed the exception throwing way to ā€œFalseā€.
And with CSmith’s help, I filtered on JobHead.PartNum and then everything worked fine.

2 Likes

Ah, that, too!

@pilio.lee Glad you got it all worked out.