Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
BOM Structure - CAD vs Manufacturing
BOM structure is a tricky problem. What is convenient and useful for one team/application is wrong for others.
On a current project we have a top level assembly which has 11 subassemblies. These make a lot of sense from a development and CAD perspective, but they're wrong when it comes to how it's actually assembled. A simple example is that there are mounting screws included in a subassembly. These really should be at the top level - the same as the subassembly. Similarly, there's a major subassembly which has some cover plates on it. These really don't get assembled until late in the final assembly.
It's certainly possible to move all these parts out of the lower level assemblies and add them at the top level, but it's often useful to see these parts in the subassemblies. It also keeps the number of mates lower in the top level.
If we move the mounting hardware and final assembly parts out of the subassemblies, I'm tempted to keep them in the lower levels for reference, but with "exclude from BOM" set.
What are ways that work well in Onshape to deal with this BOM structure issue?
On a current project we have a top level assembly which has 11 subassemblies. These make a lot of sense from a development and CAD perspective, but they're wrong when it comes to how it's actually assembled. A simple example is that there are mounting screws included in a subassembly. These really should be at the top level - the same as the subassembly. Similarly, there's a major subassembly which has some cover plates on it. These really don't get assembled until late in the final assembly.
It's certainly possible to move all these parts out of the lower level assemblies and add them at the top level, but it's often useful to see these parts in the subassemblies. It also keeps the number of mates lower in the top level.
If we move the mounting hardware and final assembly parts out of the subassemblies, I'm tempted to keep them in the lower levels for reference, but with "exclude from BOM" set.
What are ways that work well in Onshape to deal with this BOM structure issue?
Tagged:
0
Best Answers
-
adrian_vlzkz
Member Posts: 266 PRO
SolidWorks has an option to "Promote" components in an Assembly which is exactly what your asking for: ""Add to Next Higher Level"S1mon said:@nick_papageorge073
"Welcome to product development" - yep, 30+ years and it's still loads of fun.
At some level the solution is a real PLM system. That said, if Exclude from BOM worked, and/or there was an attribute like "Add to Next Higher Level", it might be easier in Onshape than it is right now. I'm not a huge fan of creating a lot of configurations, just because of the management overhead, but that's probably where I need to go. A development config with all the reference parts, and then the default is the actual assembly.
That would be an IR a would certainly vote for.Adrian V. | Onshape Ambassador
CAD Engineering Manager2 -
adrian_vlzkz
Member Posts: 266 PRO
Well, there you go! no you can "Disolve" a sub-assembly level in the BOM only and just list the components. This provides a solution for most of the scenarios discussed here. I think the "Promote" option from the component is still desirable, but less of an urgent need now.Adrian V. | Onshape Ambassador
CAD Engineering Manager1
Answers
"Welcome to product development" - yep, 30+ years and it's still loads of fun.
At some level the solution is a real PLM system. That said, if Exclude from BOM worked, and/or there was an attribute like "Add to Next Higher Level", it might be easier in Onshape than it is right now. I'm not a huge fan of creating a lot of configurations, just because of the management overhead, but that's probably where I need to go. A development config with all the reference parts, and then the default is the actual assembly.
Then we have a separate spreadsheet which is a somewhat flattened BOM, all purchased parts and fasteners go in a 'purchased' BOM with a lot qty + spares
And all of the manufactured parts go to a separate BOM (less sub assemblies) with operation steps and completion satus.
The export and refactoring into these two spreadsheets takes a few steps, but the result is fairly clear in each department
We call it the "ACS" which is "Actual Cost Sheet" and is where all the tracking occurs.
this should be in a database, but it works for us.
Purchased:
MFG:
Customers in the past, this was a long time ago, would do production documentation with a camera and a word processor. These camera images came from prototypes builds from engineering. This is totally obsolete in today's world. Back then there just weren't enough CAD operators to keep up with the change orders and anyone can use a camera and a word processor. Having engineers handle production changes was just too expensive.
I like what @john_mcclary is doing creating more logic in the engineering structure to handle the production side. One thing that I do is tag machined, sheet metal, printed & purchased parts. When you're done with the design, it's nice to automatically generate BOM's for each supplier without having to figure it out. I usually do all the purchasing so I want this to be easy. If I have to figure out the sheet metal purchase, I'll forget one and receive 14 brackets when I needed 15 brackets.
What about having 2 sets of documents one for engineering and the other for production? I know it's more work, but why try to combine them?
I'm thinking one of the major issues in all industries is the lack of documentation about how all this is put together. Production doesn't know what engineering is doing. I can't say I've ever seen a documentation package come out of engineering that's well thought out and can be used in production. In SW that top assembly with a million mates is useless to anyone other than the guy who created it.
From my experience and talking with 100's of business owners, the push to make this work just isn't there. Most owners will say that they've hired professionals and they don't need to tell them how to construct documentation. I don't even comment anymore.
John if you left your company, what would happen to the company?
@S1mon keep pushing this subject because it's needed so badly in our industry.
@pete_yodis and I locked horns in the early days of OS when I accused production about destroying my engineering layouts. I think in OS these 2 groups can get along and live in harmony. I haven't seen anyone do it yet.
One initial thought from years ago in OS was to handle this issue with 2 branches: engineering, production. Could OS handle this issue? Possibly merge changes into each branch. Could this also handle revisions? I think OS can handle this, or, is it mongo? It's just data right and maybe a better database creates a better CAD solution? I think this is true.
It is nice since we can filter by process and print a todo list for everyone.
My biggest hurdle is exporting BOMs from 'any cad' including Onshape. Since some purchased parts are assemblies, and some weldments are assemblies. So it ends up being two or three exports, some flattened, some structured and double checking weldments and purchased parts aren't mis counted or forgotten completely.
From there a single export into a spreadsheet, sort by partnumber, filter by Purchased/Mfg/SubAsm then copy each into their respective BOMs would be ideal.
A struggle I have is when a part is used in multiple sub assemblies. When filling in the BOM part numbers and such in "structured" mode. Then I end up numbering the same part multiple times by accident. Or pasting from a spreadsheet into the BOM would fail if you try and modify the same part twice in the same command. (that error at least lets me know there is a part used multiple times, but I still have to scan through the sea of text looking for that duplicate part. . .)
I use a lot of datums in my engineering layouts and they pop up in my BOMs. Keep in mind my datums are mostly surfaces and not planes or axis. How do you buy a datum? I exclude them from my BOMs.
I don't like exporting to a spreadsheet, although that's how we've done it the past. Why can't we generate a BOM that works without exporting it?
Does production really care about design intent? That's the first thing that goes when converting to production documentation. Have you ever gone into a company and the only data they have is production stuff. You struggle trying to find the original engineering layout that created the production documentation. It's hard to reconstruct a good engineering layout with design intent from a bunch of production documentation. It's a long day, week sometimes month trying to put it all back together. I wish there was a law that says you have to check in the engineering layout before you begin production documentation. PDMworks was mostly production documentation and very few times could you find the engineering data. Helpfully it's gotten better.
I recorded myself in real time so you can get an Idea of what a typical export looks like. And where some confusion sets in a couple of times.
Ideally, I'd like to click one button and all suppliers receive a package and I go back to designing.
In my mind, it should all flow something like this:
Define Designs In CAD (CAD BOMs are ONLY annotation tools) --> PLM tools manage revisions/releases and push data into --> ERP and MRP systems.
The ERP/MRP systems should contain the "source of truth" data that runs the business, and include a lot of important information that's not relevant to CAD. CAD tools are used to design things. And the PLM system is used to help manage the design process and the transfer of information from the CAD world to the ERP/MRP tools.
The problem is that integrations are hard (expensive) and if any of these three tools deviates from it's core competency, quality and functionality often suffers quickly.
That's why I'm still excited about the Arena acquisition by PTC (even though I haven't heard any news about it lately)...
I also checked the OS app store for a data transfer hook between OS & Arena. Seems like an easy integration since both are cloud products. Would you just point to the OS data from Arena versus a data transfer? Seems like this would be more efficient and better suited than a file based system. OS's DWE has all the versions already contained.
Let's see if they respond...
Also remember that you can get to the config's by adding a query to DWE+config blah, blah, blah. I agree with S1mon that configs shouldn't be in a project structure. Did you know that a DVE can still have configurations. I always thought DVEs were immutable. If you're going to use configurations, you need to add in the notes what the config settings were set to for a version.
DWE is document workspace element
DVE is document version element
Both these are addressable URLs.
Bit things like fasteners should be bom driven since they may be there for reference on some jobs, but not others. It was interesting before I realized that since i would exclude all the fasteners while renumbering the bom, which messed with guy #2 who had some of the same fasteners comming in and out of the bom he was working on..
Twitter: @onshapetricks & @babart1977
Parametric feature based modeling is about predictable change. Can you share how you structured your top assembly to control the design, skeletons, what's your referencing scheme and how do you get everyone on board?
There's a lot of static models out there and I feel they're missing out on the true power of parametric feature based modeling. Being able to iterate the design makes a better product and with tri-associate documentation, it's a powerful concept.
Do your 11 sub-assemblies have design intent?
Unfortunately, the model I'm referring to was originally developed with other CAD systems. I don't know how parametric it was then, but now it's fairly messy. The updates we're doing are mostly taking existing CAD and modifying it. That work is typically in part studios with anywhere from 1 to 40 parts in them, depending on how they were imported and structured to begin with. Within those part studios, we're trying to keep features together in folders related to the parts in question. Some things like some cabling are being recreated in context.
That would be an IR a would certainly vote for.
CAD Engineering Manager
That is exactly what I'm looking for. I never used that when I was doing Solidworks, but the concept makes perfect sense. It's especially useful if you have multiple copies of the same subassembly with mounting parts etc.
@S1mon That's exciting you get to start over maybe switching CAD systems is a benefit. It sounds like you're on top of setting up a good project structure for people to follow. I wish there was more discussions about this because its not happening in industry. Everyman for themself is not a good way to handle a project. Even with OS collaboration, without a plan you'll end up with chaos.
I'm hoping someone starts a thread about how to structure large projects.
Assemblies seem to slow down exponentially with each mate added to the list. This is especially true with SW, but I am so against the one assembly method because of that, I haven't tried a gigantic monolithic assembly in OS yet. I know even with sub-assemblies, the top level can be overwhelmed and immovable in OS, so I would be very hesitant to try. Perhaps it is because OS treats all sub-assemblies as 'flexible', so it is always solving all the mates constantly anyway...
Anyway, that seems like a heavy workaround. I would just like to have a 'By Component' BOM filter that shows the count of every component no matter what it is, asm, part, item, surface, sketch... if it was inserted into the assembly and was not excluded from BOM, then it should recursively parse the tree and spit out a comprehensive list of components with qty.
You shouldn't need to restructure your entire project just to get a list of components. Especially if some of the components you need to see are sub-assemblies, like a pneumatic cylinder drawn as an assembly does not show up on a flattened list! I can't tell you how many times those types of components never got ordered because someone (including myself) exported a flattened BOM for purchasing and forgot about the 2 sub-assembly based components.
If people want to go paperless, manufacturing (or purchasing, or any other non-CAD master users) would love to click a part, then look at a BOM that shows the qty for the entire project to make their parts in bulk while the machine is still set up for it, rather than just how many appear in that assembly and need to manually go through each sub assembly and add them up. There also may be times where they would want to see how many are just for that assembly in a warranty work situation where they only need to build one of the sub-assemblies.
BOM filters are perfect for this stuff, but nobody I know has a BOM filter that adds every component to the table only once.
I've created a public document with all dependencies public.
https://cad.onshape.com/documents/e6f897aee0df0293fc0f561c/w/0fd1e8114234244cd8572995/e/0119073c23c0921005ad3b06
I've also created notes on my website:
notes
Public doc showing assembly techniques allowing configurations to control parts in a BOM:
Unfortunately with a public document you can't share it. If you PM me your login email, I'll share it with you.
John, I have your login email and have shared this with you. If you add anything to this document, please branch the initial version. This way we can collaborate on these concepts and not clobber each other.