One BOM, three readers. Purchasing scans it for what needs to be ordered and when it has to arrive. The shop floor wants to know what will be sawn, bent and welded. The warehouse only looks at the bolts, nuts and washers that come out of bin stock. Hand all three the same unsorted list and you will see the same ritual everywhere: print it, grab a highlighter, and strike out the lines that belong to someone else.
That ritual is not a law of nature. If you record make and buy parts separately in your BOM, along with the standard parts, every department gets its own list in a few clicks, straight from the model. In this article you will read how to capture the distinction in Inventor with BOM structure and iProperties, how to handle the edge cases, and how to export a list per group. A toolbox such as Thundercad mainly speeds up the filling in and the publishing; the thinking about the classification you do once, and that is where this story starts.
Three groups, three routes through your company
The distinction is not an administrative hobby. After release, the three groups genuinely travel different routes, with different risks and different information needs:
- Make parts have their own drawing and go to your shop floor or to a machining supplier. Lead time depends on your own capacity; without a drawing number and material, the line is worthless.
- Buy parts are ordered per project from a supplier: cylinders, motors, linear guides, sensors. Delivery time rules here; a forgotten buy part is almost always the line that brings assembly to a halt.
- Standard parts come from stock: fasteners and other grab-bin material that nobody orders per project. The warehouse replenishes at a minimum level and mostly wants to see totals.
A list that mixes these groups forces every reader to classify on their own. And classifying by description is guesswork: "Shaft D20x340" could be a turned part from your own workshop, but just as easily a purchased precision shaft.
Why sorting afterwards always loses
Many companies solve it in Excel. The work planner receives the complete list, adds a column and types M, B or S line by line. On a machine of roughly 250 lines that is an hour of work, assuming you know the origin of most lines by heart. That hour returns with every revision, because the list gets regenerated and the manual column is gone.
Worse than the time is the error rate. One buy part accidentally read as a make part gets ordered by nobody: purchasing assumed the workshop would make it, the workshop was waiting for a drawing that never came. It only surfaces when the fitter finds the shelf empty, and then you are talking rush charges and days of delay instead of one mistyped letter. That is why the distinction belongs at the source: in the model, recorded once, then carried into every export automatically.
How to record the distinction in Inventor
Three places do the work together: the part's BOM structure, a custom iProperty and the Content Center. They complement each other.
BOM structure: set buy parts to Purchased
Every part and every assembly in Inventor has a BOM structure. For this purpose two of them really matter: Normal for what you make yourself and Purchased for what you buy. Purchased has a pleasant side effect on bought-in assemblies: a gear motor you modeled as an assembly shows up as one orderable line instead of loose gears and housing parts. The BOM starts matching the way you actually order.
A dedicated field for the part type
BOM structure alone is not enough, because a standard part and a buy part both sit on Purchased. So add a custom iProperty, for example "Part type", with three fixed values: make, buy, standard. Fixed values are half the battle; free text gives you "Buy", "buy part" and "BP" side by side within a month, and then nothing filters anymore. With the iProperty Panel from Thundercad you manage this kind of metadata through a configurable data card per document type, with a pick list instead of an empty text field, so every engineer uses the same three values.
Standard parts: let the Content Center pitch in
Parts from the Content Center already default to Purchased and carry their family information with them. Give them the type "standard" in the family or through the data card, and engineers never have to look at them again. Which numbers those items get and how you build them up is deliberately a separate story; we covered it earlier in Part numbers that scale with you: meaningful or meaningless numbering?.
Consistent input is half the work here. With the data cards of the iProperty Panel your team fills in the part type correctly in one movement, set up per document type the way you work.
Try 30 days freeOne list per group with Export BOM
Once the type lives in the model, exporting is the easy part. With Export BOM you push the bill of materials to Excel in your own template, with the columns your readers need. In practice a fixed three-way split works well:
Purchasing gets the buy parts: item number, description, quantity and the remarks column that holds the ordering notes. The shop floor gets the make parts: drawing number, material, quantity and the size of the raw stock. The warehouse gets the standard parts summed across the whole machine, because nobody picks bolts per subassembly. For purchasing and the warehouse a flat, summed list usually beats the assembly structure; for the shop floor the structure can be valuable because it follows the build order.
How those lists then land at purchasing and in your ERP without retyping is covered in One source of truth: your BOM into purchasing and ERP without retyping. The separation you create here is the foundation for that: an ERP wants to know per item whether it is a purchased or a manufactured item, and that information now comes along for free.
Edge cases: decide them once, not per project
Every classification has fuzzy borders. The classics: a purchased profile you cut to length, a cylinder the workshop welds a sensor bracket onto, a make part you outsource once because of workload. Do not debate these per project, write down ground rules. A modified buy part becomes a make part with the buy part underneath it in the BOM as raw material: after all, there is a drawing of the modification. An outsourced make part stays a make part, because you are buying capacity, not a catalog item; the drawing remains yours. And a standard part you have to order per project in an unusual size is simply treated as a buy part.
Put those ground rules on a single sheet next to the pick list. New colleagues then classify the same way as everyone else from day one, and the lists stay predictable.
Frequently asked questions
Is Inventor's BOM structure not enough to mark buy parts?
Purchased takes you a long way, but it cannot tell a project-bound buy part from a standard part in stock. And that is the very difference that decides who has to act on the line. The combination works best: BOM structure for counting behavior in the bill of materials, a dedicated type field for routing to purchasing, shop floor or warehouse.
Where do I record supplier information for buy parts?
Preferably not in CAD. Suppliers, prices and delivery times change outside engineering's field of view; that data belongs in your ERP or purchasing system. From CAD you deliver the stable facts: item number, description, quantity and type. Everything that follows is linked on the item number.
What if a part shifts from buy to make?
It happens, for example when a supplier drops out and you start making the part yourself. Adjust the part type and the BOM structure in the source file, and every next export is right immediately. Want to see how quickly that switches with a data card and Export BOM: try Thundercad 30 days free.