Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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

S1monS1mon Member Posts: 709 PRO
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?

Best Answers

  • adrian_vlzkzadrian_vlzkz Member Posts: 169 PRO
    Answer ✓
    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.
    SolidWorks has an option to "Promote" components in an Assembly which is exactly what your asking for: ""Add to Next Higher Level"

    That would be an IR a would certainly vote for.
    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • adrian_vlzkzadrian_vlzkz Member Posts: 169 PRO
    Answer ✓
    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 Manager
«1

Answers

  • S1monS1mon Member Posts: 709 PRO
    So I just remembered, "Exclude from BOM" is broken in Onshape. So that's not a solution.
  • Nath_McCNath_McC Member Posts: 35 PRO
    I used to like the envelope feature in Solidworks to keep items in lower assemblies but not show when looking in the top-level assembly.
  • nick_papageorge073nick_papageorge073 Member Posts: 178 PRO
    Welcome to product development. If there is a solution for this, I'm all ears. How things are designed in CAD rarely coincides with how they are assembled in the factory, how they are packaged in the box, how they are ordered from suppliers, etc.
  • S1monS1mon Member Posts: 709 PRO
    @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.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    edited April 8
    What i end up doing is creating sub assemblies with the fasteners, each sub assembly gets its own part number and drawing sheet with BOM. 

    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:

  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    edited April 30
    I think this is a really old problem and it's going to be interesting to see how people solve this with OS. Thanks for posting.

    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.

     

  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    If I left the company the ACS would live on. It is something that was developed by many people over the years. It started out as just an itemized list of purchased parts. And slowly more and more people added in what they wanted to see. 

    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.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    edited April 9
    actually, I think a BOM filter that would list each instance (Parts/Assemblies/Items/Standard Content) only once with total Qty as seen from the current assembly tree would be all that is needed.

    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. . .)
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    edited April 9
    Trying to generate a correct BOM has always been an issue for me. I struggle with flattened or structured and seem to want something in between. I've used "exclude in bom", sometimes in access, not sure if it's the correct way. @S1mon why doesn't that work? 

    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.



  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    actually, I'm working on a BOM export right now.
    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.


  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    That's a tremendous amount of manipulation. Do you think you'd ever be able to create a BOM that doesn't require all that busy work?

    Ideally, I'd like to click one button and all suppliers receive a package and I go back to designing.

     
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    Ideally a one click export would be nice (of course) but how can it be made to accommodate everyone's company needs 
  • tim_hess427tim_hess427 Member Posts: 648 PRO
    To me, it seems like all of these BOM problems really come down to a lack of communication between design tools, (CAD) and the production/business tools like ERP and MRP systems. Design tools are good at making simple tables used to annotate pictures on a piece of paper. They are not good at creating or managing the complex data structures required to run a business. That's where ERP and MRP systems should come into play. 

    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)... 
  • S1monS1mon Member Posts: 709 PRO
    @tim_hess427
    There's an integration in the works with Arena, but it's not ready yet. PLM systems are much better suited to manage a lot of these issues, but they don't really help with things like exploded views. The CAD BOM really needs to be structured much like the manufacturing BOM for it to be easy to manage exploded views, SOPs, etc.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    edited April 30
    I've spent the morning trying to understand the relationship between CAD/ERP/MRP/PLM and it appears to be smeared without any distinct boundaries. Arena looks really good at the whole data management challenge yet they don't really get specific. I sent an email to them about their communication protocols in hoping they offer up a rest interface. 

    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.
     
  • lougallolougallo Member, Moderator, Onshape Employees, Developers Posts: 1,995
    S1mon said:
    So I just remembered, "Exclude from BOM" is broken in Onshape. So that's not a solution.
    So this was an understood limitation that the setting was global to start.  We wanted to have this for things that are always excluded. We will be addressing this so that exclude is a function of the BOM and not the item.
    Lou Gallo / PD/UX - Support - Community / Onshape, Inc.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    I like it to be both. There are things that are good to always exclude. Like the pieces that come with a purchased part that never appear on the bom. Like the nut on a sensor, or the cable ends. 

    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.. 
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,119 PRO
    I'd like the ability to save a structure and also the ability to flatten the numbers while excluding/or phatoming expanded assemblies on that saved structure, plus a BOM based exclude and I think this would cover it for me for these tricky ones. 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    edited April 11
    @brucebartlett yeap, I like that
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    While we're at it, "exclude from BOM", if you have fifty things to exclude that becomes pure CAD punishment. RMB each item to exclude isn't friendly. Please add multi-select to BOM actions. I think I've already asked for this and it's been marked as an enhancement.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    @S1mon more important than bom's is your project structure.

    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?


  • S1monS1mon Member Posts: 709 PRO
    @billy2

    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.

    We will have future projects which are all native Onshape. At that point I want things to be much more top down. There will be an overall "skeleton" which is a bunch of sketches to drive basic geometry and major interfaces between subassemblies, and then subassemblies will likely mostly be built in part studios which are related to the "skeleton" through derived sketches. At least that's my nominal plan now.
  • adrian_vlzkzadrian_vlzkz Member Posts: 169 PRO
    Answer ✓
    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.
    SolidWorks has an option to "Promote" components in an Assembly which is exactly what your asking for: ""Add to Next Higher Level"

    That would be an IR a would certainly vote for.
    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • S1monS1mon Member Posts: 709 PRO
    @adrian_vlzkz

    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. 
  • S1monS1mon Member Posts: 709 PRO
    I found an existing improvement request which covers this. Somehow I didn't understand what it was asking for. Now that I do, I would ask people to vote for it.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    @adrian_vlzkz I voted it up, I like it and it could help create a useful BOM without needing to edit inside a spreadsheet.

    @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.



  • CBowersCBowers Member Posts: 50 PRO
    S1mon said:
    I found an existing improvement request which covers this. Somehow I didn't understand what it was asking for. Now that I do, I would ask people to vote for it.
    I forgot I even made that request...3 years ago. Anyways, my process currently is that I create an assembly with all the parts in it with several configurations for suppressing components to create my subassemblies (sub1, sub2, sub3...) and one configuration with nothing suppressed (full). In my top level assembly I create 2 configurations; shipping and fabrication. The shipping configuration contains all the subassemblies, hardware and other loose components. For the fabrication configuration, I suppress all the hardware and loose components and all but the first subassembly which is also configured. I change that one from sub1 to full. Then I have 2 BOMs in my drawings, shipping and fabrication.
    I know this process won't work for everyone, but we can't ship a fully assembled 150' long bridge, so it's the best thing I could come up with to work for us.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    I was hoping others would agree to handling parts in a BOM with configurations. Any other using configurations to manage BOMs?


  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,634 PRO
    edited April 16
    Creating one large assembly and using configurations to mimic sub-assemblies is a dangerous game IMHO.
    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.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,779 PRO
    edited April 17
    @john_mcclary I totally agree with everything you're saying and I worry how we're going to not only control a BOM but all the other stuff that is needed. I could never get SW to work right and I'm hoping OS has the right underlying stuff to make it happen. Beyond a BOM we need so much more. OS sits on top of mongoDB and the data is accessible to all, can we get this to work? I know featurescript and the API, this should be possible.

    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.


Sign In or Register to comment.