Some thoughts on part numbers:
Appreciate any feedback/concerns with this approach or better ideas. I realize this can be a highly opinionated topic, and different people have different needs, so don’t claim there is one solution that fits all, but I think with some experience/thought we can always find better ways to do things.
Here is one idea:
If you have in-house part numbers, then do not limit it to the PCB. Cables, cable assemblies, boxes, screws or other mounting hardware and even packaging material can be part of such a numbering system.
Does your bare PCB have such a part number?
I’m guessing that a database of deprecated part numbers and replacement suggestions could also be a part of such a system.
Good point. I’ve updated the document to say:
I added:
Do you have any other suggestions?
Add a modification number. This is not the same as a version.
For example, a PCB can have a footprint for a terminator resistor which only needs to be placed in some assemblies, everything else is the same.
A length or value part could also be useful. For example maybe a connector of a cable changes slightly so the version has to changes, for all possible lengths. It is also helpful when you can read the length/value in the version. You should also consider the exponential increase of values (means, add something to know the number of decimal digits without adding a bunch of 0’s).
This could possibly be coded as such:
This would give you 99 assembly SKUs, plus 99 versions.
Is there a reason to limit the major category and sequential number to 3 characters/digits? 3 digits is a bit short
I see you sort screws and nuts in the same category, i think it would make more sense to separate them when you need a number for each length*head*thickness variant.
You are probably right – CCCC-NNNN-VVVV is probably a better place to start.
It probably depends what type of products you are building. If you are building an automobile, then likely need many different categories for fasteners. If you are mostly building electronics in an enclosure with minimal mechanical details, then perhaps less categories is better.
This brings up the fundamental question – can you have a universal list of categories that will scale from a garage shop operation building a simple electronic device to an automobile manufacturer? If not, then is this entire CCCC part of the PN invalid as you may eventually run into scaling issues as your product line grows?
It appears McMaster Carr uses a base PN, letter, and variation for their part numbers:
It is interesting they use different letters in the PN – wonder if the letter means anything?
Interesting discussion:
We currently use vendor part numbers in our models and in our parts lists (bom’s). In my opinion, it is NOT the way to go.
I am fairly new to this organization (3 years), and I have questioned others of the initial intent of this decision to use vendor part numbers. For the most part is was chosen for 3 reasons: 1) To eliminate the need to create a source control drawing. 2) To eliminate the need to pull a company part number. 3) So that the vendor p/n will appear on the parts list (not a non-intelligent company p/n).
These are not good reasons since you really do not need to create SCD’s for cross-referencing vendor numbers to company part numbers. If set up properly, it takes no time to pull a company part numbers. As far as the parts list goes, you can add columns as needed to your parts list…so you can have vendor p/n’s and company part numbers on your parts list in different columns.
Don’t do it, you will be sorry.
Some ideas on how to automatically generate different SKUs:
The proposed scheme is very similar to our in house numbering, the main difference being that the category code is a number rather than a contrived abreviation. Personally I am not in favour of the tool specifying how the category is implemented, that should be up to the user
For interest this is an editied version of our spec:
The Model Number shall consist of two fields separated by a colon. The first field is designated as the Item Number and the second field is designated as the Revision.
| Model Number Format | Item Number | Revision |
|---|---|---|
| 160-1234-001 : A0 | 160-1234-001 | A0 |
Table 1 – Model Number Format
The Item Number is also commonly referred to as the Part Number and is a unique identifier that is assigned to all items; components, parts, assemblies and sub-assemblies. It consists of three fields separated by hyphens in the format xxx-yyyy-zzz where;
xxx is the Part Category Code
yyyy is the Family Code
zzz is the Member (or Variant) Code.
| Item Number Format | Category | Family | Member (or Variant) |
|---|---|---|---|
| 160-1234-001 | 160 | 1234 | 001 |
Table 2 – Part Number Format
The part category is a 3-position numeric field which designates the type of item. A summary of part categories is shown in Table 3 with the full list in Appendix A.
| Category | Description |
|---|---|
| 0xx- | Not used |
| 1xx- | Assemblies |
| 2xx- | Kits, Cables, Packages, PCB Fab, Mechanical Parts |
| 3xx- | Optical Components |
| 4xx- | Active Electrical Components |
| 5xx- | Passive Electrical Components |
| 6xx- | Standard Hardware Components |
| 7xx- | Misc. As Required Items |
| 8xx- | Software |
| 9xx- | Documentation & Test |
Table 3 – Part Category Summary
The Family Code is a 4-position, usually numeric, field. This is a unique number within each individual part category representing a family or series of like items. Family Codes for the Submerged product line start with the letter A (see section 2.4).
The Member Code is a 3-position numeric field. It is also known as the variant code. This field is used to distinguish between similar items within the same family. An example would be different values within a family of surface mount resistors.
The last digit of the three would typically be used to identify the version of the item where a functionality change has dictated that a new part number be assigned.
For example,
230-1234-001 is a prototype item.
230-1234-002 is a production version of the same item that incorporates improvements identified during development.
The first two digits may be used to signify variants between similar items.
For example,
230-1234-102 might be a right-handed bracket.
230-1234-202 might be a left-handed version of the same bracket.
Even with the 3 character catagory code there are plenty of free slots so simply use one of those as appropriate. Adding a 4th character certainly adds considerable flexibility to potentially have more nuance in “high level” categories and plenty of sub-categories
Even with the best will this is an issue that is certain to arise in the early days as there will always be something you do not think of. The key is to ensure your category coding scheme is flexible enough to allow for it
Having said that, the admistrative pain of creating a new category can be high so once the system is considered mature expect considerable push back from the administrator. I would have a very hard time getting a new category added to our 20+ year old system
My opinion after using a number of different PLM / ERP tools: The best software in this space does not put more restriction than necessary on the user’s desire to customize the software to fit their needs.
Part number formats are myriad, and no company is going to want to change their part number format to meet the requirements of a software package they are considering. As an individual I’d also be hesitant do do so!
The basic requirements of a part numbering scheme are (in general):
People often (but not always!) want a categorization system, maybe with alpha or numeric prefixes. People often also want to track variants, maybe with alpha or numeric suffixes. The details of how they want these to be formatted will differ, so I think a PLM system needs to be flexible here to be useful to the most people.
Some examples to illustrate how this can work:
Perhaps the user wants a unified part number + revision field on a drawing in the following format:
AAA-BBBBBB-CC-DD
AAA is a category code, selected from a list of categories set up by the administrator.
BBBBBB is a unique 6-digit number.
CC is a variant code, maybe 00 for most parts that don’t have multiple variants
DD is the revision code, maybe 00 for the first revision, or maybe 01, or A, etc…
What’s more, some organizations want different part numbering schemes for different categories!
At the end, all the software needs is a unique key for its database. Any other restrictions placed on the ability to set up a part numbering scheme will inevitably run into some pre-existing scheme that is incompatible, meaning that organization won’t use your software.
What does this mean in practice? Maybe something like:
@stair do you feel your xxx-yyyy-zzz format offers significant advantages over a simple 7 digit number as proposed by this article:
I’m struggling to imagine how to manage variations of parts like resistors with a simple 7 digit number. Seems like it would just be a big free for all, but perhaps if you had consistent descriptions in your database, and can sort the parts list, it could work.
I actually don’t disagree with anything CraftyJohn says above, ideally there should be no constraints on the numbering system used.
If you think about it, the system I describe above does conform with the guidelines in the link you provided i.e. 7 digit unique code but with a category prefix. They don’t say anything about using structured or unstructured codes.
If you use an unstructured system where no information is coded in to the number then you are heavily dependent on the quality of the meta-data or description in the database and having access to that database. If you are doing searches you have to use relatively advanced search
I personally favour the structured approach and in fact would go 8 characters nnnn-mmmm which would allow directly readable coding of E96 values in the variant instead of having to do a lookup as you do wth only 3 characters. The structured codeing is most useful when you have clear families of items like screws or resistors but rather less so with general parts although being able to link related parts thorough its number is handy
e.g. when I take out a PBA code I also take out the PCB code so that the family part is the same 130-0381-001 is the PCB so its PCB is 217-0381-001. The variant might diverge as you have PBA build variants using the same PCB but I know that all 130-0381-nnn uses the latest 217-0381-nnn
Part numbering is a contentious issue, everyone has at least one opinion, there is no right answer, or even answers. You have to go with what works for you and that is quite likely different to everyone else!
The part number should not be the key in your database. The key should probably an automatically generated number (most SQL software have something like PRIMARY KEY for that). The user never has to interact with that number. You want the user defined part number to be just an unique string, in only 1 table you keep a list of every item and the user defined identifier. This makes it easier when the user want’s to change the part number.
Well, having used multiple internal partnumbering systems over the years, I came to conclusion that the Internal Partnumber should be just a unique number (e.g. 4 or 6 digit, always incrementing, never reused) which identifies an orderable or manufacturable item. I call such number an “Identifier”. Then in the database every such item would have properties (fields) which define everything we want to know about it (Manufacturer Partnumber, Description, other parameters etc).
Here is an example of such “database” as a spreadsheet: part - Google Sheets
What could help is to let the user to define restrictions on the format. A user may define a minimum and maximum length, can define that on some places there has to be a specific character or a character of a group (like only digits or only characters). But then it will be harder to define what happens when you have Characters that are made up from multiple different Unicode code points.
But a software should not restrict the user by its own. One of the most important rules for good software is: Do not do anything that is not requested. This includes restrictions on the part number: The software should only restrict when a user made configuration explicit told the software to do that or when it is technically necessary / make the software a lot simpler (for example, you can limit the length or limit it to ASCII when it helps you).
But implementing a feature where the user can restrict the part identifier is nice to have and not essential.
In most systems I’ve used, “changing the part number” is not allowed / not done. You would never change an item’s internal part number once it is created.
Thanks everyone for all the input – much appreciated!
This really cuts to the heart of the structured vs unstructured discussion.
Thanks for the great spreadsheet example. Having an extensive list of attributes in the CAD database and part library is very useful!
It seems the structured PN and part database with extensive list of attributes are not mutually exclusive. Then you have the best of both worlds – 1. ability to search on part attributes. 2. some meta information in the PN that allows you to find, group, memorize, and organize parts in the physical world.
To me, RES-020 is much easier to memorize and visually process than 102239. It seems one of the values of the PN is to be able to visually look at and quickly gather some information without a lot of processing. This is the same reason progressive manufacturing operations use tags with colors on the factory floor to identify material. It does not tell you everything, but at a glance gives you some information.
The argument is made for digits only PNs that they are easier to enter with less mistakes. However, how many times is a PN entered vs read? It seems like we should optimize for reading the PN. Hopefully with modern systems, automated processes take care of most of the PN entry for us. I could be wrong as I don’t have a lot of experience in manufacturing. On the design side, I can easily type a PN with letters just as fast or faster than numbers – my keyboard does not even have a number pad.
And structured PNs may be created automatically based on attributes.
