I just have that meme from this post in my head every time I read ttTables @josecgomez
Donāt touch the third rail
Donāt eat yellow snow
Donāt join to a tt table.
Some rules just stick.
one of my prouder ones.
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:
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).
Or to be even more direct:
Check for a single part number in the table.
Message fires on any part that is updated.
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.
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.
- Joining
JobHead
toPartCost
makes sense enough - How are they joined?
Company
andPartNum
? - Letās go with your criteria of
StdMaterialCost <> 0
- The line/connector thing is coming from
True
- this makes sense - Condition should be āNumber of rows⦠is exactly zeroā (not more)
Check on #2.
But #5 is what is messing you up I think.
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
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!
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.