Skip to main content
M
MikeGwin1-Visitor
1-Visitor
September 20, 2012
Solved

BOM TABLE WITH FLEXIBLE QTY AND UOM II

  • September 20, 2012
  • 1 reply
  • 5865 views

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

bom total issue1 .JPG

 

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

bom total issue2.JPG

 

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.
Best answer by MikeGwin

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).

bom total work around.JPG

I have attached the updated files.

Will post updates from PTC if I receive them.

Mike

1 reply

M
MikeGwin1-VisitorAuthorAnswer
1-Visitor
September 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).

bom total work around.JPG

I have attached the updated files.

Will post updates from PTC if I receive them.

Mike

M
MikeGwin1-VisitorAuthor
1-Visitor
September 24, 2012

Here is the link to the TPI:

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

B
BrianMartin13-Aquamarine
13-Aquamarine
October 7, 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

Terms & ConditionsCookie settingsAccessibility statement