4th BOM Type - "Flat" & Comprehensive

[MechMachineMan]

The current 3 BOM types have limitations and are not user friendly to the fullest extend. Adding a 4th type of BOM (or 2 options to the model BOM) would provide users with much more flexibility.

The biggest drawback to the current BOM types is that we can NEVER see all parts in the model in a "flat" layout, with each part appearing only once. 

Implications:

- If you are editing iProperties, you line count is drastically higher than it needs to be as each item can be duplicated multiple times throughout multiple levels.

- If you are exporting component information, there is not a single way to export all of the information for parts AND assemblies at once, with their "flat" quantities, with each item only appearing once.

Implementing these changes would be great, but I have 2 further suggestions:

1. For this 4th BOM type, add the option to include Reference components and to Exclude them.

    - This helps with model processing and establishing how much "fluff" reference components are in the document)

2. For ALL BOM types, add the option to include "derived components". This way, if a part that has a derived component, they can control is visibility with the BOM structure, but also have "sub-levels" of parts available in order to give the part materials.

     - This helps so that it more closely matches ERP systems, and allows for quick & direct exports.

3. Optional: Add an "ancestry" iProperty that establishes the "chain of usage" to the TOP level, and includes the quantity required for that chain as it pertains to the assembly.

      - This is useful for logistics and planning during ordering.

(My current workaround for iProperty editting is to run a rule which places one of each document in a NEW assembly, at the top level, so all iProperties are exposed. I then leave the rows collapsed and edit iProperties as I like.)

(My current work-around for gather document properties is to use a complex Excel macro that is ran on the structured BOM in order to "flatten" quantities. This macro also handles ancestry)

[Anonymous]

Any changes to increase the flexibiity of the BOM that already have macros or rules available to create the upgrade should be a slamdunk!

I do find Inventor's BOM to be superior to other programs I have used but agree that we need greater flexibility in how we bring in the parts and this sounds like a superior plan!

[DRoam]

Great idea. Having more BOM customization and control is always helpful. Here's another idea along that same vane: Custom BOM lists with filters.

@MechMachineMan, could you explain #2 of your further suggestions more? It's my understanding that once you Derive out from a source part to recipient one, the recipient one can be assigned any desired material and BOM structure like any other Part. Do you mean you'd like for exported solids in a multi-body part to appear in the BOM? If so, wouldn't it be better to derive those solids out into actual individual Part files? Or are you asking for something else?

[MechMachineMan]

@DRoam

It's more a concern about adding SUB-levels to part files so that it more closely matches the MATERIAL, PAINT, ADDITIONAL PROCESS lines that would be under the same part number in ERP software.

If you go into any part, and use "Derive Component" command (or the similar one that adds the derived part to the active file), you effectively add a secondary document reference to that file, while keeping all of the part environment functionality. However, this secondary document reference is never exposed to BOMS, which I think it should be. At the same time, it would also be neat to be able to add "virtual" sub-levels to the parts, so that the document retains the functionality of the part environment, but can have sub-levels for in the BOM.

[DRoam]

@MechMachineMan that makes a lot of sense, thanks for clarifying. That does sound really useful.

There are a few ideas floating around that touch on something similar...

• Bill of materials in ipt for multibody
• Constraints in muti body part environment
• Multi-Body iProperty Support
• Different Materials for Each Solid Bodies

When you consider all of this, the line between Assembly and Part really starts to blur -- and I think that's to be expected. It's the natural progression once you have modeling features in Assemblies, and multiple bodies in Parts. As people begin to utilize these tools, they're going to want more and more out of them, requiring more Assembly-type functionality in Parts and Part-like functionality in Assemblies, until they're essentially the same thing.

I think this is similar to how Fusion operates. It has one type of model file, which can behave as both an assembly and a Part, and therefore it doesn't force you to choose between Part functionality and Assembly functionality for a given component.

Inventor may be too far down the rabbit hole to fully go there, but that's the direction I see things heading. And your request about derived components is a good example of that trend.

[MechMachineMan]

@DRoam

I'm sort of opposed to utilizing the multi-body system to any more capacity than it currently is, just because the whole premise of Inventor is 1 file, 1 set of properties. However, I do see the frustrations with the multi-body system and do think it should have a better system of linking parts 2 ways.

Adding additional "component properties" into multi-bodies (a single part file) which are for more than one part, seems to completely go against this.

My suggestion of adding the derived parts only adds LINKS to other files, or in the case of Virtual Component, embeds line item information that isn't intended to be for a separate physical part.

[cadman777]

Interesting discussion on BOM's.

Sideline:

Here's my 2-cent's worth on MultiBody parts.
I quit using them.

Why?
B/c all the down-line work that has to go into fixing the iPros in each and every part for the BOM.

Also, when things change in the model that affect the MBP, the changes to the MPB multiply the down-line changes that were already made that you then LOSE. BIG time eater!

There are many other problems w/MBP's that I won't get into.

The sole use I have for MBP's is for 'quick-and-dirty' proposals to shove them out the door for approval, which get 'shelved' after that point in the customer-process.

Otherwise, MBP's are way too limited to be of any use to my work-flow.

Cheers ...