Internal (house) part number formats

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:

Item Numbers and Revisions

Model Number

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

Item (Part) Number

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

Part Category

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

Family Code

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).

Member or Variant Code

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.

3 Likes

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):

  • A part number must be unique within the system
  • The software must have a way to generate the next available part number
  • In most cases, users want to track revision separately from identity in some way, although sometimes they want both revision and identity presented in a single field.

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:

  • Start by having a way to generate unique numbers, of a user-specified length (zero-padded)
  • Add configurable prefixes and suffixes to the unique number
  • Separate out the revision, and allow flexibility in how revisions work (alphabetic? numeric? both?)
  • If your system supports the concept of categories, allow different categories to have different rules.
1 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!

1 Like

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

4 Likes

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.

2 Likes

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.

We create a MISC category and review it from time to time, if there are more than a few items in it that all can be categorized in a way that makes sense, we create a new category at that point.

2 Likes

Situations where i changed the part number: I created one, saw that is was wrong and changed it. Before it was used anywhere.

Even when you don’t want to allow changed, the user given string should not be a key in your database. This is bad practice and it is slower.

Maybe we are talking about different concepts here.

In the systems I have used, internal part number (shortened to “part number” in my other posts, and different from Manufacturer’s part number or MPN) is not something user-given – the PLM system generates it for the user.

2 Likes

I refined the PN document some after this and various other discussions.

The TLDR is that part numbers are really designed for human use, not machine, so they should be optimized as such. Another revelation is to call them “semi-structured” part numbers instead of structured – that really defines best what most people are doing.

Thanks for all the input thus far!

My experience was with a simple unique number, about 7 digits ISTR.
It was important that this did not include revision as half the reason for its use was that component standards could add new vendors or change a suppliers part number without having to modify BOMs.
Any change that was not backwards compatible would mean a new house number was created.

1 Like

Keep it simple. Trying to make your internal part numbers meaningful by incorporating part parameters is inevitably going to fail at some point because either something will come along that just doesn’t fit, or something will come along that is close enough to an existing part that it ends up with the same number, because the distinguishing parameter is not part of the part number formula.
If you must, use broad classifications (eg Electrical / Mechanical, Pcb etc) then just add sequential numbering. The part number then becomes an index into a database that holds all the other data.

2 Likes

By the way, it might be beneficial to use UUID version 4 (random) as internal partnumbers. The advantage is that UUID4 may be generated anywhere by anyone and still they all will be unique (i.e. no duplications)

That is an interesting idea – being able to have multiple people generate numbers without collisions would be handy. The drawback is UUIDs are long – good for computers, but difficult for humans to process when dealing with parts out on the plant floor, etc.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.