Solved: BOM TABLE WITH FLEXIBLE QTY AND UOM II

MikeGwin · ‎Sep 20, 2012

God Father - "Just when I think I am out, they pull me back in!"

For back ground purposes, you can find the original discussion here.

Here is the relation set up in the BOM TABLE:

IF EXISTS ("ASM_MBR_BOMQTY")

BOMQTY=asm_mbr_bomqty

ELSE

BOMQTY=rpt_qty

ENDIF

So, just when I think I was all done setting up the my new BOM TABLE so that I could use FLEXIBLE parts and use the LENGTH (or similar) as the qty for said component in the BOM REPEAT REGION...I run into an issue with the BOMQTY of the "FLEXIBLE" components not totaling

Components/Models:

MET-EA-1 is a "RIGID" part, that has BOMUOM="EA" and does not contain the BOMQTY parameter

MET-1 is a FLEXIBLE solid model BOMUOM="MM" and BOMQTY=d0 (length) through a RELATION, currently d0=25.4 (mm)

ENG-1 is a FLEXIBLE solid model BOMUOM="IN" and BOMQTY=d0 (length) through RELATION, currently d0=1 (in)

BULK_PART is a bulk item model, BOMUOM="IN" and does notcontain the BOMQTY parameter. As all "BULK" items in Pro/E, it contains a parameter called BOM_REPORT_QUANTITY,which is set for USER INPUT

Assembly:

The assembly has the following components and quantities...

MET-EA-1: two models assembled, therefore Qty=2 EA

MET-1: one model assembled, the length of the model is 25.4 mm, therefore Qty=25.4 MM total.

ENG-1: two models assembled, the length of each model is 1 in, therefore the Qty=2 IN total (at least it should be!)

BULK_item: this bulk item was added to the assembly twice, with the user input for the BOM_REPORT_QTY set to 1 (IN) each time, therefore the Qty=2 IN total. I did this on purpose because I wanted multiple instances.

Notice below all of the quantities total up correctly except for the ENG-1 part. The BOMQTY is not totaling correctly. The Qty should be 2 IN since there are 2 instances, each at 1 IN length.

FIGURE 1

Below is what happens when I take one of the ENG-1 parts and make it flexible, and change the length to 1.5 IN.

The total qty for the ENG-1 part should be 1 IN + 1.5 IN = 2.5 IN. The items are not totaled. They are instead listed separately.

I do have No Duplicates/Level set for the REGION.

FIGURE 2

So it looks like "BULK ITEMS" and "RIGID" components total up just fine,even if you have assemble multiple times (instances).

However, for the "FLEXIBLE" components if the length is the same for multiple instances, then it treats the two instances as "the same" or "a duplicate" and lists one row, however the QTY is not "totaled".

If the instances are of different lengths then it treats them as "not the same" or "not a duplicate" and lists them separately, as above.

I am once again blind-sided by PTC. Yet another quirk...

Any ideas folks? All files are attached.

Mike

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

MikeGwin · ‎Sep 21, 2012

All,

So after several discussion with PTC Technical Support it appears that there is a know issue with REPEAT REGIONS and the way FLEXIBLE MODELS are treated or at least the way they are or are not recogonized as unique (or not).

I was referred to SPR# 1353474. However, this SPR is not "customer viewable". Also, I am not clear as to wheter PTC will simply add my information to the existing SPR or create a new one. If they create a new one or send me a link to access the existing one, I will post an update.

The issue:

Even though the FLEXIBLE ITEMS are identical execpt for the "varied item(s)", the REPEAT REGION treats them as seperate models.

This is why the 1.500" long (2X) and 1.000" long (1X) ENG-1 PARTS show up on two different lines since the lengths are different.

This is also why the 25.4mm long (2x) MET-1 PARTS show up on one line since the lengths are the same.

The Work-Around:

Live with the FLEXIBLE items showing up on seperate lines if they are different lengths
The "adding" or "totaling" has been fixed by editing the equation to calculate the BOMQTY see below

IF EXISTS ("ASM_MBR_BOMQTY")

BOMQTY=asm_mbr_bomqty*rpt_qty

ELSE

BOMQTY=rpt_qty

ENDIF

As you can see below, the table is correct with respect to Total Qty, but may have the same partnubmer on multiple lines (one line per discrete length).

I have attached the updated files.

Will post updates from PTC if I receive them.

Mike

View solution in original post

MikeGwin · ‎Sep 21, 2012

All,

So after several discussion with PTC Technical Support it appears that there is a know issue with REPEAT REGIONS and the way FLEXIBLE MODELS are treated or at least the way they are or are not recogonized as unique (or not).

I was referred to SPR# 1353474. However, this SPR is not "customer viewable". Also, I am not clear as to wheter PTC will simply add my information to the existing SPR or create a new one. If they create a new one or send me a link to access the existing one, I will post an update.

The issue:

Even though the FLEXIBLE ITEMS are identical execpt for the "varied item(s)", the REPEAT REGION treats them as seperate models.

This is why the 1.500" long (2X) and 1.000" long (1X) ENG-1 PARTS show up on two different lines since the lengths are different.

This is also why the 25.4mm long (2x) MET-1 PARTS show up on one line since the lengths are the same.

The Work-Around:

Live with the FLEXIBLE items showing up on seperate lines if they are different lengths
The "adding" or "totaling" has been fixed by editing the equation to calculate the BOMQTY see below

IF EXISTS ("ASM_MBR_BOMQTY")

BOMQTY=asm_mbr_bomqty*rpt_qty

ELSE

BOMQTY=rpt_qty

ENDIF

As you can see below, the table is correct with respect to Total Qty, but may have the same partnubmer on multiple lines (one line per discrete length).

I have attached the updated files.

Will post updates from PTC if I receive them.

Mike

MikeGwin · ‎Sep 24, 2012

Here is the link to the TPI:

https://www.ptc.com/appserver/cs/view/solution.jsp?n=133763).

BrianMartin · ‎Oct 07, 2012

Hi Mike...

Sorry I didn't have a chance to get to this sooner, I could've saved you the time to investigate. I've had this same problem with flexible components in the BOM. Even more than this, though... I have to warn you that eventually the BOM relations will fail you no matter how clever we are.

They just... kind of "quit" on you sometimes. I could demonstrate if you wish but it's quite a lengthy demonstration. In essence, it seems that there's a limit to either the number or the complexity of BOM relations that will work. Once you hit that limit- they start to fail. They're really finicky to begin with- but then when you pile on more trickery like flexible components, you're really skating on thin ice.

The whole BOM relations and Pro/REPORT system needs a rewrite. Maybe sometime soon PTC will take a crack at it.

I'm glad you found a workaround for now. I guess that's the best you can hope for. Maybe your TPI/SPR will get something done. Anyway... good luck! Keep in touch if anything develops.

Take care...

-Brian

James62 · ‎Oct 07, 2012

Interesting. So they are basically saying this is not an issue and the way flexible components are working right with repeat regions is fine.

"as they are no longer duplicates due to the differences in flexibility"

Mike, I would actually also like to see this work the way you described cause sometimes I have to make assemblies with lots of pipes and it's time consuming to make new pipe part of each time new pipe length is needed and then filter the unecessary parts out of the repeat region based on their name.

I also need to type the total length of all pipes into the assembly bom and this length I have to count manually everytime.

It actually gets complicated when you try to add a new part to a complete assembly like this because you always have to keep in mind few things about the assembly and BOM.

But that's how we work these days...