According to Engineering Documentation Control Handbook, by Frank B Watts, an Ideal Part Number is relatively simple: ########-[TAB]
The rule is "Put as little significance into the part number as possible, but absolutely include a tab suffix as part of the part number".
The Golden Rule is "A part number without a tab is like a ship without a rudder".
We all know why significant (or smart) part numbers break down, and why they should be avoided, so I don't need to reiterate those. But the tab suffix is where we can assign increments to versions of an item. As Watts writes: "The tab is a form of significance, although minimal... This is the portion of the part number that will change on non-interchangeable changes. This will save making a new document [number] each time we need to change part numbers"
In this case, the Document Number is the ######## portion. And the tab suffix represents a non-interchangeable version of the item. We can call "non-interchangeable version" as "major revision" if you'd like, also.
So for a document number 1556678, we could have major revisions of 01, 02, 03, 04,... , or A, B, C, D, ..., whichever format fits your business's needs.
So a full part number for the "third" major revision of the part could be 1556678-03, or 1556678-C.
For EINs
To make this part number format for the Enterprise Item Number in 3DX, we can break it down into three components:
- Sequential counter (1556678) can be handed by a COUNTER type item
- Dash ("-") is just a text string
- Major revision, ("C") is the open item
How to represent Major Revision in an EIN format?
There are two reasons for one to set a new EIN: a new item altogether, or a non-interchangeable version of an existing item.
For the former, when setting an EIN from scratch, one can simply assign "A" to the major revison, so the next EIN using the counter would be 1556679-A, and then 1556680-A, and so on.
Now for the latter, say I want to make a new, non-interchangeable version of 1556679-A: 1556679-B. It's still the same kind of part, so keeping the counter the same makes sense, but I need to increment the suffix to make a unique EIN, ideally in a defined sequence (A, B, C, D, E,... e.g.)
I could simply allow manual EIN entries and then have validation on promotion that requires the EIN to follow my PN format, but that opens up the possibility of users just making up their own PNs and potentially conflicting with the counter later in the sequence. It's also frustrating to everyone when an EIN gets rejected on promotion and the EIN needs to be updated, and potentially other artifacts that contain the EIN (say on a drawing, or in an emboss of the part's geometry).
What are some best practices for enabling users to efficiently increment the suffix of an EIN?
Is there business logic that can be implemented? Have you implemented some business logic to this effect that you can share or partially explain?
Feel free to drop your other thoughts related to this topic here, too.
