Parts with same part name to have different item numbers in BOM

[Anonymous]

I have read older posts dated back to even 2010/2012 about the merging part rows when part numbers with same file name and file paths are the same....No real solution presented itself or even a good work around so posing the question as Inventor 2018 is now released. 

Our Structured BOM's will be exported through a third-party tool and I have been researching, attempting to write vb.net or VBA code to manipulate the BOM to separate line items of merged parts that have the same file name and file path as a way to read raw material parts and based on the 'parent' item number assign the raw material part number the .1 item number value and external exporting tool reads it and  transfers fine into ERP. However, I cannot assign a merged part multiple item numbers for example 1.1, 2.1, 3.1...and when changing the file path but keeping the file name it creates an error when attempting to transfer of "key already added"

Is there a work-around or solution with the new releases of Inventor to help with this issue?

Any help will greatly be appreciated!!!

Respectfully Submitted,

Dominique 

[MechMachineMan]

I'm not entirely following what you are trying to do, but the only row merge supported is part number.

[Anonymous]

Yes, it only merges based on part numbers. However, if you save a copy of a file into another folder and place both parts from different folders into your BOM it can unmerge because it is two distinct files even though part numbers are the same...

I need separate line items of parts with varying quantities of the same part number (same file path) placed into BOM so that I can assign them separate line item numbers...An external source is reading the parts by line item numbers to import data into an ERP system...

So, I am trying to find a work-around to either separate the line items of part numbers that are merged.. or find a work-around to assign multiple line item numbers to one line item in the BOM like you can do in a parts table (1.1, 2.1, 3.1)

[MechMachineMan]

I cannot reproduce these issues. See below.

If you have verified the part numbers are IDENTICAL (including any invisible spaces that may be present) and that you have the row merge box CHECKED, then it points to there being a bug I'm sure autodesk would want to follow up and get the bug fixed.

[Anonymous]

I am probably not explaining the issue clearly...

The Goal:

Manipulate the BOM to create connections between parts (basically creating a connection of raw material parts to formed parts through the item-numbering system)

One way I attempted to achieve goal:

I placed the two identical part numbers with two distinct files in the BOM to see if those identical part numbers can be exported with two different BOM item numbers...

Like your example of the two parts being unmerged because of the two distinct file paths...

The Issue:

However, the exporting tool is generating an exception error stating "An item with the same key has already been added"

In other words, the logic in the exporting tool is recognizing that I am attempting to export the same part number as a different file and basically informing me that I cannot export the same part as two separate files... 

Another way I attempted to achieve goal:

I am attempting to manipulate the BOM by rearranging my item numbers so that merged raw material part number(Example: SHT4X12-12GA - Item 12.1) can be attached or connected to a part (Example: PEP-BLDG Part B - Item 12) and the other merged raw material part number (Example: SHT4X12-12GA - Item 29.1) can be attached or connected to a part (Example: PEP-BLDG Part A - Item 29)  when exported into an ERP system...

The Issue:

When parts are merged....The Item field is a number field (integer) and doesn't recognize anything but one number/integer per line item. So, I cannot numerically designate each merged part separately. I attached a snapshot of the numbering structure of parts to create connections between the parts for exporting...

[MechMachineMan]

I don't think Inventor isn't really set up to handle the material sub level, like an ERP system.

Inventors BOM think in terms of exposed levels

Having a field act as a flag for a material then adding in a material sub-level using VBA would probablly get you further.

Or using a derived component and writing code to extra the derived part information as material information and add it as a new line.

OR use each part as an assembly, with it's only BOM visible sub-part as the material.

Or along your current train of thought:

Read the lines item number, ADD a new line per item number as the material, and then append the appropriate .1 or whatever material identifier you need. I would't try to put all of the material numbers of one line though, as that seems like it would get messy/very manual for rolling up quantities. And total quantity isn't as important as each individual parts cut length and the length of the stock material.

[Anonymous]

         MechMachineMan, 

Thank you so much for all of your insight and input and its really helping me think through all of this and possibilities....

Yes, I agree that Inventor is not set up to handle the material sub-level. That is why I have been thinking of various ways to work around this through customization.

I also agree that creating the formed part and raw material part together as an assembly seems the best route to handle these types of sub-levels...However, for years of work, completed before the thought of even implementing an ERP system, all past parts will have to convert to assemblies and with the myriad of current assemblies and subassemblies comes the messiness of losing constraints and the re-structuring of layers upon layers of work....

I've attempted to achieve the goal with derived parts, but couldn't get both parts to read in the BOM (not sure if I am doing something wrong in that area)

         Also, we have a list of raw material part numbers, like a content center library almost, and do not need a new part number every time that same raw material part number is utilized (the quantity per assembly is where we capture the differentiation of area per material size instead of capturing it with distinct part numbers). Therefore, material part numbers will be used multiple times and across levels in one top-level assembly. With that said, Item Numbers and Quantities is what I can come up with so far and the 'part number row merge settings' is deterring this... There should be some flexibility with the settings that still allows the choice of breaking out parts whether same file or not (I get that calculating the quantities is the primary logic behind it but still) 🙂

         Utilizing VB.net has been great so far however with BOM Customization there isn't much flexibility...I will try VBA again and use your thoughts to see how far I can go...  I will keep updating!!!! 

         If you think of anything else please share your thoughts and ideas 🙂

[MechMachineMan · Accepted solution]

I would consider looking into using Excel API and VBA directly.

Also, it appears you are only concerned about a Parts Only BOM, and not having a structured BOM? These function a bit differently than the structured BOM so that might be important to mention.

One way you could do it with the structured BOM:

Have a custom property set up in inventor that identifies material name. A second one that identifies material quantity.

After exporting the BOM to Excel, have the rule (or an external excel rule) run through each line of the Excel document. If it find a material name, have it add a row directly below that one, assigning an item number as required, and adding the material quantity - now making it a new row.

Also make your VBA to multiply the quantities from top level components down through their tree to have a "flat qty" BOM.

Then simply use the filter/sort commands to group items by part number. Then use the SUM feature to establish total quantities.

[Anonymous]

I thought about using Excel to customize the BOM and may still be an option...

We are using a third party to export into ERP, so have to work with their tool as well.. Therefore, I would have to import the customized Excel BOM back into Inventor and then all of the same Inventor settings and rules apply once more....

Importing the customized Excel 'parts list' works perfectly for Inventor .dwg or .idw 'Part Lists' which are slightly more flexible than an assembly's BOM structure...

If I personally just exported the BOM into xml or other format then I can easily manipulate the data but any customization on my end must be done before the data is exported by third party....

[MechMachineMan]

Ahhh yeah, that doesn't seem like it would really work then with the ERP system then.

So the ERP system is grabbing the structured BOM then?

If it's exporting the structured BOM alone, then Inventor won't really give you much flexibility to add sub-levels without resorting to the promoted-to-assembly method 😞

Perhaps making your rule create a dummy drawing and adding in a structured parts list with all rows expanded then adding in the materials afterwards similar to the iProperty method I described would be your best solution then, as you get the information nicely from the BOM, but the flexibility of the Parts List, all while functioning within inventor and working with your BOM system. It would also mean you probably don't need to interact with excel either!

[Anonymous]

I created two custom Iproperties that will read arrays to account for multiple item numbers and differentiating quantities to create sub-levels for raw materials. 

The third party team then reads those quantities and item numbers and does the connecting of parts to raw materials...

There is only so much flexibility within Inventor!

Thank you so much MechMachineMan for your assistance!!

[jesus.zas]

I have a similar issue (maybe not the same issue of this original thread) but these content center parts appear twice in the BOM, automatically (not by me manipulating anything). It clearly seems a software bug. One is a Bolt, the other a nut. See the image below straight from the structured BOM list:

I wonder if Autodesk knows about this rare bug issue, and if there is any solution to fix it properly (not work-arounds).

Thanks