Sequential Part Number

Matthew_Holling

I like the built in numbering scheme but is there a way to have more options for sequential numbering?  For example:

9000-XXXX is for top level master assembly 

• Weldment Assemblies: 1000

• Manufactured Parts: 2000

• Sub Assemblies: 3000

• Sourced Parts: 4000

• Purchased Component: 7000

• Spec Components: 8000

Any help or suggestions are welcome. Thank you in advance for any contributors

nick_papageorge073

Not that I found in the professional license. My company went back to spreadsheets to assign numbers, with a different prefix for different part categories. I don't know if there is an add-on that offers more choices.

S1mon

If you hook it up with Arena, I think that sort of semi-intelligent part number is possible. 

Urs_Egger_REACT

@Matthew_Holling why don't you just create a custom property for this? You could call it like "part classification" and fill in a list of value.
So you don't have the need to learn the meaning of the codes and can directly choose what type of part it is. It is also possible to make it a required property. 

philip_7

@S1mon is right about Arena PLM: you set up Onshape categories in enterprise settings to match your categories in Arena and then Onshape can pull part numbers automatically based on the category-based numbering rules you set up in Arena.

Duro PLM works similarly, but you don't need enterprise or to set up categories in Onshape first - you just set the category for your parts in the Duro tab that runs within the Onshape document and Duro generates the PN based on the rules you've set in Duro and writes it into Onshape.

If you're not using a dedicated PLM program, you could do your own implementation from your own part number database via API, or you might be able to do something with featurescript - I haven't tried this, but I would guess you could pull the category and use that to write to the part number property in a similar way to how the Part Name (Ovyl) feature by Evan_Reese can write to the part name property based on parameter inputs.

[Edit to add:  if you're working with an established system, hopefully the above can help, although if you're setting up a new system from scratch you might consider whether category-based numbering really make sense, below]

That all said, I'm with @Urs@Urs_Egger_REACT in that I like to use short, non-significant part numbers and prefer to put "categories" or "classification" in a metadata property. In the "old days" when all we might have was a part number, I think category-based numbering made a lot of sense to give some clue as to what a part was. Even so, people inevitably mis-categorize parts, or we decide that the categorization system should change as a company grows, and its much harder to fix or change things because the part numbers are tied in with the categories. If category is metadata, fixing/changing is easy and keeping the part numbering system simpler makes it easier to teach and maintain. It is also often pretty straightforward today to have category, name, description, etc. available alongside the part number all the way from CAD through to an MES system on the shop floor. Ever company is unique, and categories might still make a lot of sense for your application, but in most places I've seen, this ubiquity of metadata makes it not worth the trade-off to use category-based numbering any more.

Matthew_Holling

@S1mon you are correct about Arena, I was initially on the beta program for that and I loved it.  @Urs_Egger_REACT Thank you for your suggestion as well, I may give that a try and see how it works for a small project, if it goes well then I can roll it out to other team members.  

@philip_7 I appreciate your contribution as well, sounds like a conversation I will be having in the near future, and you gave me some great talking points

Matthew_Holling

@philip_7 I've heard of Duro Labs but I haven't worked with any suppliers who interface with it. Maybe a separate thread could be started with them in mind? also with PTC's acquisition of Arena maybe they (Duro) are looking to capture market share independently from partnering with a CAD system. Personally, I think the integrated PLM is the way to go, but it needs to look and feel like the UI/UX of your native CAD 

nick_papageorge073

Did you guys see pricing on some of these systems? I think the last time I checked a year ago it was about 5k. Double the cost of the OS license. My company didn't get it.

Urs_Egger_REACT

@nick_papageorge073 indeed PLM seems to be for enterprise only. For ARENA you need Onshape Enterprise which is a massive cost increase and second you need a ARENA subscription which is not cheap neither.
What's missing is kind of a Onshape integrated PLM with only core PLM functionality at a cost smaller companies can bear. There was a sneak peak of that a few years ago at the first Onshape Live event. Unfortunately never heard of this again.
Maybe Duro could be this or also OpenBom has an interesting approach.

philip_7

@Matthew_Holling - agreed about integrated PLM being the way to go. It avoids lots of non-value-added work by engineers manually re-recreating BOMs and exporting and importing files from CAD to PLM. Similar logic applies to PLM integration with ERP/MRP.

In terms of integrations to Onshape, I think your options are Arena, Duro, Propel, and Open BOM. They're all good with different strengths (I've used all but OpenBOM). Quick summaries:

• Arena: older UI (but improving) with loads of features (QMS, requirements, projects, etc.). More complex to learn, set up, and administer. Rest API. Requires Onshape Enterprise. Integration requires setting up of categories in Onshape to match categories in Arena (this can trigger work to version / re-release existing parts and assemblies to get them into the proper categories) but once set up, you get single-click sync integration from Onshape BOMs directly to Arena, auto-generation of part numbers from Arena directly within Onshape, and it supports release management sync to change orders and pulls .step and .pdf files automatically on release.
• Duro: newer, with a very clean and intuitive UI. Easier to learn, set up, and administer. Not as full featured as Arena natively (relies more on partner integrations to extend its capabilities). Modern graphQL API with webhook support. Does not require Onshape enterprise. Does not require categories to be set up in Onshape. Integration by adding a Duro tab within your documents: assign categories and part numbers in the Duro tab and it writes them to Onshape and/or syncs to Duro. Supports release management sync to change orders and pulls .step and .pdf automatically on release.
• Propel: built on saleforce; looks and feels like salesforce. I'm less familiar with Propel and have I've only used it with SolidWorks, but I'm impressed with its search capability - easily the best of the PLM systems I've used. Onshape integration is advertised but I haven't used it.
  
• OpenBOM: looks very easy to use. Not exactly a "traditional" PLM but includes much of the core capability, including ECO/ECR if you go for the "company" plan level. Charges by concurrent user (vs. named users) so it may be your most cost-effective option if it will do what you need. Not sure how part number generation works with OpenBOM.
  

shawn_crocker

When I see these things relating to part numbers being used to organize data, I immediately wonder, what will you do if a part that is a purchased part someday becomes something that you make in house(and I cringe inwardly)?  Like, if you need to outsource something because you don't have tooling ATM but eventually one day your company acquires the correct tooling?  Do you just leave the part incorrectly part numbered?  Do you change the part and then input time and effort correcting the whole data trail?  Might I suggest just letting part number's be what they are but use categories?  In onshape you can categorize items and then you can also search for them by category.  If you use metadata to organize your design elements, you get the flexibility of reorganizing things with a simple minor part revision.  You could even create your own list based custom property and assign it as editable in versions.  Then you could change what category the item is in without even needing to make a part revision.

shawncrocker

When I see these things relating to part numbers being used to organize data, I immediately wonder, what will you do if a part that is a purchased part someday becomes something that you make in house(and I cringe inwardly)?  Like, if you need to outsource something because you don't have tooling ATM but eventually one day your company acquires the correct tooling?  Do you just leave the part incorrectly part numbered?  Do you change the part and then input time and effort correcting the whole data trail?  Might I suggest just letting part number's be what they are but use categories?  In onshape you can categorize items and then you can also search for them by category.  If you use metadata to organize your design elements, you get the flexibility of reorganizing things with a simple minor part revision.  You could even create your own list based custom property and assign it as editable in versions.  Then you could change what category the item is in without even needing to make a part revision.

Urs_Egger_REACT

philip_7 said:

@Matthew_Holling - agreed about integrated PLM being the way to go. It avoids lots of non-value-added work by engineers manually re-recreating BOMs and exporting and importing files from CAD to PLM. Similar logic applies to PLM integration with ERP/MRP.

In terms of integrations to Onshape, I think your options are Arena, Duro, Propel, and Open BOM. They're all good with different strengths (I've used all but OpenBOM). Quick summaries:

• Arena: older UI (but improving) with loads of features (QMS, requirements, projects, etc.). More complex to learn, set up, and administer. Rest API. Requires Onshape Enterprise. Integration requires setting up of categories in Onshape to match categories in Arena (this can trigger work to version / re-release existing parts and assemblies to get them into the proper categories) but once set up, you get single-click sync integration from Onshape BOMs directly to Arena, auto-generation of part numbers from Arena directly within Onshape, and it supports release management sync to change orders and pulls .step and .pdf files automatically on release.
• Duro: newer, with a very clean and intuitive UI. Easier to learn, set up, and administer. Not as full featured as Arena natively (relies more on partner integrations to extend its capabilities). Modern graphQL API with webhook support. Does not require Onshape enterprise. Does not require categories to be set up in Onshape. Integration by adding a Duro tab within your documents: assign categories and part numbers in the Duro tab and it writes them to Onshape and/or syncs to Duro. Supports release management sync to change orders and pulls .step and .pdf automatically on release.
• Propel: built on saleforce; looks and feels like salesforce. I'm less familiar with Propel and have I've only used it with SolidWorks, but I'm impressed with its search capability - easily the best of the PLM systems I've used. Onshape integration is advertised but I haven't used it.
  
• OpenBOM: looks very easy to use. Not exactly a "traditional" PLM but includes much of the core capability, including ECO/ECR if you go for the "company" plan level. Charges by concurrent user (vs. named users) so it may be your most cost-effective option if it will do what you need. Not sure how part number generation works with OpenBOM.
  

Thanks for that overview. 

e_g_e

@Matthew_Holling
In my company we want part number schemes very similar to the ones you list in your original message.

I am currently working on setting up a Onshape-OpenBOM integration for my company. OpenBOM uses catalogs as databases, and each catalog can be linked with a catagory in Onshape. And you can have a unique part number scheme for each catalog.

For instance our Weld Assembly category in Onshape is linked with the Weld Assembly catalog in OpenBOM, and has a serial part number WLD-XXXXX.

Regardless of what option you choose, it looks like you should start to use Onshapes categories, if you haven't done that yet.