If there are parts/items marked "Exclude from bill of materials" and one uses the API to get a computed BOM of the assembly, those items are included in the returned rows. (BUG) I'm just wondering if there is anyone out there that would be willing to share how you've overcome this problem.
Thanks.
There is an open SPR; 743362.
I use derived BOMs. SW is far better at presenting an accurate BOM than EPDM. For my users, I am working on an add-in that will provide a 'Print BOM' right click menu option for drawings and assemblies. It will get the derived BOM from the drawing (or associated drawing) and display it in a nicely formatted Excel document ready to print. The SW BOM is outside the drawing border so that no attention has to be paid to formatting it nicely and it doesn't take up drawing real estate. It simply has to have the correct data.
The only caveat with this approach is that you have to make sure your drawings are up to date with respect to the model. So, if you make a change to the model that affects order or content of the BOM, you have to also check out the drawing and rebuild it. You can use IEdmFile7::NeedsRegeneration to detect this problem, but this should be a requirement of your process anyway to prevent out of date drawings.
The other problem with computed BOMs is that they pay no attention to the ordering of the items in the model. The computed BOM is ordered by document ID, which is useless.
Jim S.
Hey Jim - I don't care so much about the order; I'm only interested in the quantity.
I'll give derived BOMs a shot. I was hoping I wouldn't have to use them but I guess it's either that or the document manager API.
Thanks.
One thing I forgot to mention. There can be more than one derived BOM for a drawing even though there is only one BOM on the drawing. I have found that if you rename the drawing file, there will be a derived BOM for each. You can see this in the BOM tab:
The derived bills are the ones at the top. There is only one BOM in the drawing, but because the file was renamed, two entries are listed. To ensure I am using the newest bill, I get the EdmBomInfo object (from the array returned by IEdmFile::GetDerivedBOMs) with the highest value for the mlBomID variable. EPDM doesn't guarantee that the highest value is the newest, but it is a safe bet that mlBomID is an ever increasing integer value, just like the document ID.
Jim S.
I use derived BOMs. SW is far better at presenting an accurate BOM than EPDM. For my users, I am working on an add-in that will provide a 'Print BOM' right click menu option for drawings and assemblies. It will get the derived BOM from the drawing (or associated drawing) and display it in a nicely formatted Excel document ready to print. The SW BOM is outside the drawing border so that no attention has to be paid to formatting it nicely and it doesn't take up drawing real estate. It simply has to have the correct data.
The only caveat with this approach is that you have to make sure your drawings are up to date with respect to the model. So, if you make a change to the model that affects order or content of the BOM, you have to also check out the drawing and rebuild it. You can use IEdmFile7::NeedsRegeneration to detect this problem, but this should be a requirement of your process anyway to prevent out of date drawings.
The other problem with computed BOMs is that they pay no attention to the ordering of the items in the model. The computed BOM is ordered by document ID, which is useless.
Jim S.