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.
Version Independent Metadata (Custom Properties)?
S1mon
Member Posts: 3,044 PRO
I think I'm finally getting the idea of how "Edit in version" and "Edit in workspace" are supposed to work. However, I can see types of data that I would like to see in Onshape, but doesn't necessarily correspond to any particular version or revision. BOM Cost per part (or assembly) is an obvious one. The value may fluctuate based on raw material costs etc. or might be renegotiated periodically or change depending on MOQs etc...
One could argue that cost doesn't belong in Onshape, or at least it should not be the source of truth. It should be in a PLM system or an ERP system or accounting system or something else. This is likely the correct answer, but what if as an engineer I'd like to see some representative price directly in Onshape to help think through design decisions?
So let's say I have this magical source of truth for pricing, how do I sync it with Onshape in a way that I can see a cost value for a part for some reasonable set of versions/revisions? If something is written via the APIs is it possible to set a value for a property that is independent of the revision history (besides the obvious need for the part/assembly to exist)?
Maybe a more concrete question: with the new Arena integration, could I easily solve this problem?
One could argue that cost doesn't belong in Onshape, or at least it should not be the source of truth. It should be in a PLM system or an ERP system or accounting system or something else. This is likely the correct answer, but what if as an engineer I'd like to see some representative price directly in Onshape to help think through design decisions?
So let's say I have this magical source of truth for pricing, how do I sync it with Onshape in a way that I can see a cost value for a part for some reasonable set of versions/revisions? If something is written via the APIs is it possible to set a value for a property that is independent of the revision history (besides the obvious need for the part/assembly to exist)?
Maybe a more concrete question: with the new Arena integration, could I easily solve this problem?
Tagged:
0
Comments
With multiple documents with versioned instances in higher level assemblies, this kind of change requires touching a lot of parts and assemblies, and creating new versions. If everything were at RevA, it would be even harder to fix this small naming cleanup. This seems really stupid.
In general, I wouldn't want some intern at a large company to accidentally change the names of a bunch of parts with search/replace, so I get that this shouldn't necessarily be easy to do for anyone, but shouldn't there be an Admin level override for things like this?
Again, is this something which could be done with the APIs, or Arena Integration, or OpenBOM, or ???