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.
How to make BOM's awesome?
stevehess
Moderator, Onshape Employees, Developers Posts: 98 
OK, now that everyone has had a chance to look at drawings.... I'm taking a suggestion from @3dcad and starting a thread about BOM's, and how can we make BOM's awesome. There are as many opinions about BOM's as their are Engineers who create them so let's start off by laying down some basics to build on. Here are a few questions we have been kicking around:
1) What does the minimum useful BOM look like? Not the final vision, but something to start with? Something that you could get the job done with.
2) Where should the BOM be authored? In the drawing? In a tab associated to the assembly? Somewhere else?
3) What are some examples of how you use BOM's outside of drawings? Output to xml or CSV for example? other formats? ERP integration?
And, of course, what could we do to make BOMs totally awesome? Perhaps something that you would love to do in an installed CAD tool that just can't be done. But with Onshape & the cloud it's a new era. Think outside the PC.
I'll be taking notes.
1) What does the minimum useful BOM look like? Not the final vision, but something to start with? Something that you could get the job done with.
2) Where should the BOM be authored? In the drawing? In a tab associated to the assembly? Somewhere else?
3) What are some examples of how you use BOM's outside of drawings? Output to xml or CSV for example? other formats? ERP integration?
And, of course, what could we do to make BOMs totally awesome? Perhaps something that you would love to do in an installed CAD tool that just can't be done. But with Onshape & the cloud it's a new era. Think outside the PC.
I'll be taking notes.
Steve Hess \ Onshape Inc.
4
Comments
However if future capabilities are part of the early planning, they should be able to be integrated much more seamlessly and with a simpler UX when the time comes. In no particular order:
1) Ability to click on a BoM line entry, and go direct to the part or subassembly
2) Ability to edit part and subassy properties from the BoM
3) Ability to override number of instances of a subassy or part, eg where a higher level assy shows only selected instances. Override to be permanently flagged to the CAD operator
4) Sophisticated control over whether and how subassemblies 'dissolve' in the BoM to reveal nested subassies and parts. Hopefully as powerful as SW, but ideally less confusing for the uninitiated.
5) An easily accessed part property which sets an "Exclude from BoM" flag.
It would be great if there was also an ability to click on a BoM and see a list (even if only temporarily - we can grab a screenshot if need be) of excluded parts. The same, or a similar facility, could also list overrides in operation. (ref point 3)
6) Flexibility as to whether filenames constitute Part Nos for the purposes of the BoM
7) Ability to split balloon numbering sequences easily over a number of drawing sheets
8) Flexibility of balloon and box shapes (PLEASE either allow us to draw a master box ourselves, OR include options such as Obrounds, eg like a keyway or slot profile, and PLEASE don't shrink boxes tightly, unless we can override the amount of white space ... and ideally, perhaps allow for several 'compartments' per box, with vertical dividers, for segregated-designator item numbers)
- Minimum useful Bom would be export data to spreadsheet and insert back in. For me BoMs need to be perfect or I won't use them.
2) Where should the BOM be authored? In the drawing? In a tab associated to the assembly? Somewhere else?
- Separate TAB, choose parts/assemblies to include (from document). Insert into partstudio, assembly, drawings.
- Live link to view without login + possibility to embed into another webpage
3) What are some examples of how you use BOM's outside of drawings? Output to xml or CSV for example? other formats? ERP integration?
- I would like to use BoM as part list of assembly instructions. Include a piece of BoM within each assembly phase. (See Ikea asm instructions to get the idea)
- Output pdf, xml, csv + select & copy to clipboard as html table
- ERP integration, YES please.
@stevehess Can you please open up a bit what kind of mechanism flashed in your mind when you asked about ERP?
Some ideas in random order (created before above answers, apologies for possible duplicates):
1. Treat BoM as standalone feature, not just part of drawings. Separate TAB would be good.
- Export pdf, xml, csv + select & copy to clipboard as html table (that can be easily pasted into email)
- Link to googledocs and other online office apps
- Live link to view without login + possibility to embed into another webpage
- Insert into partstudio, assembly, drawings (which need the above link&embed functions too)
- Insert into named view
- View modes list and grid
- Show images of parts in BoM
- Link rows to model (click to open)
2. Full control over contents
- Custom templates
- Default columns: Item no, Image, Part no, Quantity, Part Name, Version, (Configuration,) Comment
- Add / remove columns
- Treat assembly as part if needed (buy-in modules)
- Add parameter columns (part dimensions etc.)
- Add, remove or edit values, choose to cut/reconnect link to part if needed
- Split / combine list/grid for perfect layout
- Full support for future configurations
- Align, Font etc. text tools
- Sort, Group (by material), Drag
- Easy manageable way to create BoM out of imported (dumb solid) models.
It's all about reuse.
Regarding our BOMs, we do NOT use item number. In fact, we hide the BOM on the drawing and the balloons are part numbers. It's working well here. I think item numbers are a hold over from days past. It seems silly to create a unique identifier in the drawing, that is matched to another identifier in ERP - all so they can point to the overall unique identifier, the part number. It's much more efficient to just have the balloon on the drawing call out the part number (done through metadata). We eliminate the item number shuffle as a result. Our assemblers like seeing the part number on the drawing, too. in ERP, the BOM can be sorted by part number ascending for ease of locating qty, info, and description. I would like if Onshape could comply with this and balloons could be linked to metadata, and not just item numbers. That would be awesome, and I think the world moves this way more in the future with augmented reality and all that
"Golden" post. Great point about item numbers (eg 1, 2, 3 etc) being (in production settings) an archaic holdover.
I had that in mind when I wrote my point 8 in my previous comment, but I waffled about "segregated-designator item numbers" instead of articulating the basic need clearly as you did.
Dashes, within "concatenated string" part numbers (as in your example), are a great separator in my opinion, but some companies use partitioned boxes with separate entry fields, and it seems preferable to accommodate multiple practices if possible.
Some companies use slashes as a separator in Part Numbers, in defiance of DOS legacy issues (arising in turn, I guess, from qwerty keyboard limitations?) which still hamper us today... and I've even seen (boo, hiss) underscore used this way.
Many European countries use the dot (period, full stop) , presumably reflecting their use of the comma as a decimal separator ...
Thank you kind sir. My day job is for a 78 yr old company. Part numbers here pre dated computers! We still have a little fanaticism about numbers here, too. I am a little bit more ambivalent, but tend to think a class code out in front of a non-intelligent number has a nice mix.
I think there is a lot here in Drawings and BOMs that are a holdover from past times. Often our tools tend to automate the routines of the past era, when if we really thought about the platform change with something like Onshape -we'd come to different conclusions. If we made the assumption that ERP was firmly in the cloud, then we might talk about data being streamed and accessed - but not copied. When you think of data being in this way, then we might not have to talk about which system is the system of record. I am too tired at the moment to write more on this, so ill wait until I'm better off and give it a stab then.
@stevehess I really think there could be a much better handling of what we call As Required items. Adhesives, paints, grease, ect. I'll write more later. Good night.
BOM's and drawings are different. Assembly drawings are an important part of documenting a design but they are not part of this discussion as far as I'm concerned. It's all about the meta-data.
1) fix the mismatch between onshape assemblies and parts that has been documented extensively here in the past. (the main one was that instances of two different bodies may represent the same thing/partnumber in the assembly. I think there were some other issues as well).
2) Did I say it's all about the meta-data? Finish custom properties and give us good import/export tools (json/yaml (it's a tree structure after all....), csv, REST) and you are most of the way there.
(the current implementation of properties is awkward and doesn't really work. Adding, editing, and viewing meta-data of entities in the model needs to be more immediate and fast. Closer to how you have implemented comments that how properties are currently implemented.)
(good custom properties will let us map two different bodies to the same part number, which would be a work around in the short term for the issues mentioned above.)
I like the idea of a separate tab that someone mentioned.
-Parametric editing between BOM Cells and Model Metadata
-Flag (color-code or icon) cells that have been manually overwritten or are not link to the model)
-Ability to have hidden columns that don't show on the drawing but they are exported (for ERP purposes)
-Ability to set a Default export destination and file type (this would be perfect to automate ERP transfer)
-Ability to create templates
-Ability to set required info (no empty cells)
-Ability to set rules and/or condition for some columns (Number field, all caps, no special characters, etc...)
-Have similar functionality to the Indent feature in SWX (Automatic roll up of components)
-Conversely, ability to set some assembly to always dissolve, when used.
CAD Engineering Manager
For the changes, we can do either. Load the BOM again in ERP as it was recently output from the CAD data, or make manual tweaks. Probably most changes are manual because they are onsie and twosies of components changing. If its a more major update (yikes on released things), then it would probably be loaded into ERP from a txt file.
I feel it would best be in a separate tab which could be inserted in a drawing or exported to use in a spreadsheet or text. We could elaborate from there. While on this subject @stevehess possibly you could start a thread on how we can make inspection reports awesome as well. This would be something that I could use in the machine shop for every project. Just a thought, Thanks.
Most important for me is ease of access to the BOM Info. I don't want to have to create the BOM, I just want to build my product in 3d with the correctly spec'ed parts and the BOM is there for me automatically. A Tab version would work OK but I'd also like to be able to drop it into my 3d assy and drawings as required. ERP link is also on my wish list.
Currently in my day job I am using BOM's in 3 places, on drawings using the meta properties from SW 3d parts, in our ERP system (manually entered) and in our parts manuals (copied across though excel). I have to manually enter and move data around and there is a lot of time wasted doing this, it would be great to have Meta-properties directly link to the ERP systems and the part manuals, I believe it can be done with our current system but has not been because of cost or lack of time or interest. It would be a real winner if Onshape can do this with ease.
I think it's important to get the the input of properties working right before BOM's. I like the way the properties nest out for the document at the moment but they are very limited. Untimely we are going to need some form of customisation however the less the better to enable interchange of parts/assy's between users, nothing worse than getting files with different meta-properties that don't match. It maybe that only company subscriptions have access to custom properties.
At some stage we will also need the ability to nest and dissolve with ease.
Configurations in assemblies would also be very helpful when structuring BOM's.
I also need to be able to add non model parts eg, glue or grease.
Exclude from BOM is also useful
Twitter: @onshapetricks & @babart1977
I must say that the use of spreadsheets for BOM templates that SolidWorks does is a great idea that we have made good use of at our company. We should be able to setup and save multiple company BOM templates in Onshape.
Adding virtual parts such as grease, thread locker, etc. is vital. It would be nice to be able to add this to the BOM by virtue of a RMB -> Insert Virtual Part and have a row appear in the BOM table that we can then populate with information.
Overwriting a value in the BOM is occasionally necessary, but it would be very helpful to have a visual indication that a cell has been overridden with the ability to reset it.
For what it's worth, our use of BOMs is primarily on the drawings, but in the assembly file itself has also proven more helpful in development than we thought it would be. We export the BOM as a spreadsheet and can then import that into our ERP system. We also use the exported spreadsheet for other information management.
Although, now I think about it, if it was available in its own tab, given that would always live in the same Onshape document, I think that would offer optimal access to the live BoM.
In cases where the top level assembly runs to hundreds or thousands of subassemblies, that live BoM can act as a really effective way of managing them, especially if is is powerful enough to rename individual parts and subassemblies.
Such a BoM can be a great way of ensuring consistency (and error checking/correcting) far-flung properties such as part nos, material description, and finish, as well as controlling which subassemblies dissolve, and this is especially true if multiple discontinuous selections can be made prior to entering a particular property.
And if it embodies hyperlinks to take the user straight from a BoM line to a particular part in a part studio OR assembly (al gusto), it's also potentially a huge navigation aid in big projects.
Some thought has to be given to splitting a large BoM over multiple drawing sheets. This is generally done late in the piece, when detailing is all but complete. Prior to that, large BoMs in other packages I've used are typically kept in a single block, dragged outside the boundary of the first sheet of the top level assembly drawing. But I do like the idea, in Onshape, of being able to keep it in a separate tab (even after it is distributed across drawing sheets) as a single entity.
For this to happen we need some form of Company Vault/Filing System to link approved company parts into doc's.
I also need a work flow for getting 3d parts from suppliers, I note Onshape already have partners for this and hopefully parts will come with their meta-properties intact.
Twitter: @onshapetricks & @babart1977
1. Part nos vs item nos. many industries don't use part numbers as the components are standard materials that are cut to length or fabricated to a specific format for a specific job. This is particularly true in things related to AEC. Example, we do glazed canopy structures for a customer and these use a combination of stock assemblies with bespoke material items. Standard BOM systems cannot handle this so we use Excel with Item Description/Type/Material/Cut length/qty/drawing number ref/check
bottom line is no off the shelf BOM system can handle everybody so the system needs to be adaptable and allow data links for key dimensions or qty...these are the things that fall out of sync in manyal updates. If I could (easily) live link a SolidWorks dimension or qty to an excel cell this would make things more reliable.
2. Pictures of parts in BOM cell. Sounds simple but for production a little thumbnail picture (and maybe live link to the part) would save so much confusion. Visual references are best.
3. Separate BOM. I agree with those above. Keep it as a seperate element that can be added to drawing sheets or standalone. I actually prefer BOMs as standalone documents rather than on drawing sheets. BOMs are there primarily for non designers to use, to stock check, or quote against, or build to. We started doing PDF BOMs years ago, with excel or indesign tables, with live links in the pdf to the part data file (click on the cell picture to switch to a 3D pdf of part) then live links to drawings and build instructions etc. lot of work to do but everybody in the production phases loved it, as did suppliers reponding to rfqs. In short, BOMs should be active docs, not static, and automatically link to the right things. The Onshape architecture allows this.
4. BOMs are often best when they are created in groups and in the build order for production. Noone on a production line or stock check needs a list of 500 lines in prt number order. They need to be able to arrange by assembly, sub assembly, product or, extending further, arrange by internal factory layout or warehouse aisle. A live link of bought in parts to Onshape BOMs would, well, likely sell more seats of Onshape than anything.
5. Linking to 4, the ability to extend the BOM into work orders or process procedures or RFQs for reorders would again extend the system nicely...so many small manufacturers these days have NOTHING in use except Excel or Sage...and Sage is rubbish. The market is screaming out for a cloud based system that can link all this together, simply. A lot of traditional systems grew up based on large company procedures where parts were made in house or bought in from other group companies or sub contractors using the same systems. These days, your typical SME manufacturer might only do final assembly and shipping, and buy in all the components. If there are only 20 people in the company, big systems fail dismally.
6. Design process management. Months ago I posted a series of posts on linking Onshape to cloud based project management systems with specific workflows for vertical industries like medical. There is a genuine need for this. The development BOM is critical to this process. During device development the BOM needs constant attention and updating. Total PIA to be frank.
I'm asking because I don't have experience in being professional designer, my intension is always to serve the in-house production (ie. from design to product).
@stevehess If Onshape is willing to go far enough to really hold the up-to-date part data, then we should be able to update the data in both; erp or cad environment. Both being in cloud, xml export/import is not the option, excel/spreadsheet is not the option, we would need onshape to access erp database or have an accessible database in onshape. I would prefer the latter since it is impossible for onshape to push the data into different erps. With few smart parameters this database could enable me to pull the product data from cad to production (erp) and maybe push data (stock, work orders or any non-cad info) into bom.
The main beauty of this database would be that excel/access/any spreadsheet connects easily and data would be always up-to-date (not copy).
I have built our erp, it has functions to receive orders in xml through ftp, send electronic invoices in xml, import bank account data in xml etc..
While building these features, I couldn't stop thinking how stupid and narrow minded all that filetransfer is.
For example sales order:
- sales man puts in the order in their system -> data is saved to their database
- background service runs every few minutes and creates the xml and saves to ftp folder
- our backround system scans the folder every few minutes and informs erp that there is new orders
- erp reads folder and creates unapproved sales order in our database
- person reviews order and makes changes to delivery time or so and approves --> order confimation.xml is created into ftp folder
- customer system scans the folder and reads confirmation xml back into their database
My way would be to have mutual access database:
- customer creates order into their system, at the same time system would create new instance on mutual collaborative_db
- we would see this instance immediately as unapproved, we would fill up our data in that row as approval
This way customer could easily change priority until we set status 'in production' or other interactive actions.
Reading and writing to database is the nature of erps, fileread/write is always a bit of a hack with having the correct path and filenames - it is much more sensitive to errors than database interactions not to even mention the speed if data amount is bigger.
I think this is one of the things that Onshape guys have already revealed, why use filesystem if you have database. I let myself believe that all our modeling data is stored in database? If so, wouldn't it be the most natural way to share the data also?
ps. Onshape data storage system is something I would like to read in 'under-the-hood' blogs.
I will circle back here to update you all as we move ahead. Thanks again.
Wherever a part must diverge from a plane (for instance if a sub-assembly or part has complex geometry and needs to be rotated in more than one plane, a navigator's compass could animate transparently over the plane to indicate necessary movements.
Basically, I want an animated BOM/Assembly view that can show me a clickable, interactive bill of materials list off to the side while I step through an animated assembly. A simple screen grab of live video or by conversion to .gif filetype would then serve as the BOM, work instructions (with commenting and audio or video support). This would be phenomenal.
I think meta data should be viewable over top of the digital defintion, and quite possibly be the augmented information on top of the physical world. This would be so much more efficient.
Nice work
Eduardo Magdalena C2i Change 2 improve ☑ ¿Por qué no organizamos una reunión online?
Partner de PTC - Onshape Averigua a quién conocemos en común
Aerospace Research & Development Group, LLC
www.aerornd.com
I managed to create a BOM of a simple whistle I made for the grandson. I added rows and columns easily and inserted things like the suppliers of raw materials and the cost.
I couldn't work out how to insert a tab into my Onshape document with the Onshape created BOM, so I saved it as an Excel Spreadsheet and inserted that. All anyone has to do now is RMB on the BOM Tab and download the BOM in Excel format. I'm not sure if the Excel Spreadsheet is saved in the cloud but I have a copy on my laptop.
Have a look here if you want to see the whistle design + BOM.
https://cad.onshape.com/documents/8f61fbb919ea4b39b4e6eb71/w/ded354bd618342989f7d3ad8
I just looked at your whistle document, very simple and nicely done. If you saved the BoM as a PDF from Excel you could upload that PDF and it would be viewable in the tab, unlike the .xlsx upload which cannot (yet) be viewed in the tab.
Ideally you want to see the Google sheet in a tab. As an alternative I copied a url of the sheet via the share button, then pasted this to a basic text file and loaded that file to Onshape. This then gives a quick reference to the BOM location.
Twitter: @onshapetricks & @babart1977
All good ideas. Onshape will definitely be expanding the types of documents which can be rendered in the tab which, we all agree, is likely the desired behavior.
A couple thing's I have noticed is suppressed parts still come into the BOM. This was not expected, I'd assume suppressed parts to be excluded.
I'd also love to see the BOM's for sub assemblies come in nested rather than flat.
Twitter: @onshapetricks & @babart1977