On Drawing BOMs

The parametric BOM is one of the very best tools for keeping accurate BOMs in the company's ERP system. In fact my personal experience is that the companies that don't use parametric BOMs have the biggest problems maintaining accurate BOMs in their ERP systems. One major company I worked at fed their ERP system directly from the parametric BOM, and had the most accurate BOMs in their ERP system I've seen, as well as assembly models. Every place I've worked that didn't utilize the parametric BOM, had the biggest problems with accurate models and BOMs. It did force discipline in creating accurate CAD assemblies and part models, something that a lot of places simply don't have or do. I've seen such extreme disconnects between the models and the BOMs, that it was virtually impossible for someone to determine what was supposed to be in it, what wasn't, and to best determine it's place, purpose and identity, especially for people coming in months and years later.

It probably has a lot to do with what you first learned, as far as what you prefer. Of course if you learned prior to 3D, you learned to type in manual BOMs, so that's probably what you're most comfortable with. I learned, from the very begining using 3D models, and there's simply no better, more accurate, and less error prone method.

If this seems too long, skip to the last paragraph.

Philosophy wise, it is ideal if the model directly drives the entire process. However, this presumes the model is exactly accurate and can exactly represent every condition. When the model is incorrect or there are situations that are not exactly represented, the directly-driven output needs a method to discover the errors and a means to represent that which cannot be exactly represented. In addition, not all processes benefit from being gated by model creation.

My preference is to extract the BOM from the models and dump it into an independent document. The independent document has places to record the location of each balloon and related flag note, bounces the manual list against the extracted BOM, allows for mis-named/custom name part conversion, and generally tracks and explains why everything is where it is, both in paper space (sheet and zone) and function space (bracket with attaching hardware.)

I export the information from the model tree, in which I generally keep items in groups. Want to know what a certain screw is used for? Look and see what it's grouped with. This just gets dumped as-is as input to the workbook. If someone thinks there is a need, just dump out another copy of the model tree and import again. Include in the dump any parameter fields desired - part names, material, color, description, et al.

The next level up is the names correction page. Because PTC (and all other CAD companies I think) have a problem making arbitrary alterations to parts on installation, it's pretty common to have to make custom models of things like cables, one for each of the various installations.

The names corrections page is where the base part names are, by equation, stripped of suffixes, where underscores in filenames get replaced with slash characters, and so on. Anything more than that the user can type in. When it's manually entered, the cell format indicates it's a manual entry overriding the model.

The next step collects all the balloon and flag locations per item number. This is a manual process as PTC doesn't have an easy means to report this information, but since the coordinates of the first balloon sets the sheet and zone, there's a lot of copy/paste. These are used to accumulate the total that is identified on the drawing, compared to the qty in the model, and to the qty that is shown on the PL. In addition, it reflects back the item number and item name from the PL, so that groups of balloons can be seen to contain expected items - nut, bolt, washer rather than nut, nut, washer.

The PL itself is a standalone sheet. One can type in anything, but I prefer to just copy and paste from the model tree dump. As items are added to the PL, comparisons with the corrected model information and conditional formating indicates process status.

It seems like a lot of effort, but it includes verification that the on-drawing BOM doesn't/can't have. In addition, I never experience lost balloons, balloons that wouldn't show in a view, BOMs where fixed items that were removed from the assembly left unexpected gaps in the BOM listing. It never required complex relations or filters. It makes obvious that the balloons are correctly grouped, so this provides a check for that as well as a way to check that note flags are correctly applied. It provides independent traceability for not only what items are used, but also how they are used together. Nothing on the drawing BOM will indicate the .250-UNC nuts are used with the .375-UNF screws, but that info comes along for the ride from the model tree.

Because the PL front part can be completely generated and released before any assembly is done, but remains useable to validate against the model, exceptions and discrepancies can be discovered and managed, Purchasing can be off purchasing things that Engineering hasn't had the need or time to build models of. Example, a pneumatic/electronic anti-lock braking system needs all the items the supplier suggests for the PL, but engineering doesn't need to build the 30-40 models of little piece parts and assemble them in order to get that done, but will in the future need to verify that all the parts are in the model so that Tech-pubs can create the documentation.

Being Excel, it's readily accessible for other groups to use, review, copy and reformat. It always gets printed full size, at least more often than trying to get a J-Size BOM onto A-size paper. It doesn't require an expert to manage; it doesn't need a Pro/E trained user to make use of most of it.

If you are creating PLs with hundreds plus unique items and thousands of components spread across perhaps dozens of J-size sheets and someone wants to validate it, the method above has been more reliable due to self-check and accessibility than any on-drawing auto-BOM. If you are dealing with D-size drawings with five or ten parts, the above method may be break-even, unless you have to create custom complicated relations to get what you want to appear where you want it. There must be organizations that can cradle-to-grave it from Engineer to Shipped product without leaving the fully electronic farm, for which this would not be useful, but for those not experiencing error-free, hands-off, no hassle BOM management, I can say it works well.

It reads like a Rube Goldberg process.

I've never understood the signifigance so many people put on "find number" or index numbers, and getting them into the database. I started off working someplace where they weren't tracked or used in their ERP system. I think they determined, and agree, that they are of no real consequence. They really are just an indicator on the drawing, flagging it's location. If a very large successful company gets by without them in their ERP system, it seems to me like others can as well. For most of the people I've personally interacted with, it was more about being trained by someone to enter the item number, so that's what they "think" is required. I know from experience that there are times when it can be convenient to reference them, but if you consider all of the time people spend entering them, making errors, fixing indexes and doing revisions to correct or change them, it seems like they're mostly just expensive.

In Reply to Don Senchuk:

It reads like a Rube Goldberg process.

I know!

It seems complicated when explained, but almost trivial when used. The main thing is that repeat regions don't scale up or perform all the functions this does and the method looks odd scaled down.



How do the following problems get solved with repeat regions?



1) An item is no longer used on the assembly. With the index fixed to prevent reuse, the BOM has an unexpected gap in numbering; which is identical to having the basis for the table changing, even though the same item is used. How does one identify the difference when it's the result of someone else working on parts that feed the assembly? How does one indicate in the BOM when the gap was intentional?

2) How does one ensure that all the items on the BOM have related balloons on the field of the drawing? How does one ensure that reference balloons and notes that repeat the item number are correctly related and updated?

3) When balloons are merged to indicate local stackups, how does one validate that the merges were done correctly - nut, screw, washer; not nut, nut, washer? Where is the validation stored?

4) When a change is made that changes where the balloons are attached, eliminating the balloon and the quantity is automatically added to another balloon, how long does it take to identify the balloon with the incorrect quantity?

5) When the filename cannot match the part number, how is this configured in the on-drawing BOM? If it is by using a parameter, how is the filename that matches that parameter found? How are duplicates fo the parameter value in multiple parts avoided/validated?

6) New items are added to the assembly. By default, their index is not fixed. They are in unknown order. Before the parts are added, what does an ECO say about adding a note that includes an index number?

7) How does one work the BOM in advance of model construction?

😎 How does one handle an imported or 2D print-based drawing package?

9) How can one user stop in creating a drawing and the next user know exactly what remains to be done with the on-drawing BOM?

10) If there is some benefit from a comment about why or how an item is used, where can that comment appear in the repeat region?

To be a real Rube Goldberg mechanism, it needs to do some very simple task in an unnecessarily complicated, but interesting way. When the need to deal with the above conditions is considered, a workbook with a few formulas that never needs equation/relation customizing is as simple as it gets.



When the above steps, mostly having to do with validation, are not needed tasks, then it is in R G territory, but I dislike having to re-do work, guess what others have done, trace through complicated customized programs to figure out why an item that should be on the list is not on the list.

Cost:

It adds about 1-5% to balloon note placement; altogether a tiny fraction of what I've spent diagnosing and repairing repeat regions. It's all information a checker needs to use, a cross-index of item, by qty and to location. Most of it is work that can be done by anyone with a readable copy of the drawing without using Pro/E, though it requires a dumb text file dump to validate the model against the drawing.

Value:

I started using the basis of this method on a 12 sheet J-size from-the-board drawing and had zero errors at PCA after finding dozens of miscounts, and balloon omissions, in spite of numerous checks by engineering, manufacturing, QC, QA, and of course, the Check group. How much does PCA cost? How much does the customer trust the remainder of the process when getting the drawing to match the hardware is a problem? As the on drawing BOM does not contribute to this, it can't remove any PCA costs.

It is a process that can run without any custom software development intervention on a per-assembly basis.

tl;dr

If there is value in knowing where items are on drawings, then there needs to be a container for that information. PTC has not provided a comprehensive container. If there is no value to finding items, then why bother with find numbers?