Part Numbering Standards

Thought I would publish this here… Over four years ago I created this document, and it was published as a White Paper… I still stand by the best practice “rules” in this document. It doesn’t matter what version (Vantage, Epicor 9, Epicor 10, etc), the rules still apply…
Most people don’t get to change their standard, BUT they can apply a standard to all NEW items…

Have fun.Part-Numbering-Standards-WP-ENS-0614.pdf (1.0 MB)


Very helpful Tim… Thanks! …Monty.

1 Like

Nice Guide. Our method is to use the customer PN for manufactured parts and a sequential non-intelligent number for purchased parts. On import they all had leading zeroes. Lots of fun.
At another facility we use a sequential number for purchased parts but there is a class prefix first. So for capacitors CAPS-00001 and if someone makes a new resistor it will start with RESS-00001. I guess they didn’t want mix-ups. And I hope a part never changes class :confused:

One problem we had was double quotes in part numbers so wrote a BPM to stop it. Looks like I’ll be adding more, thank you for the list. I believe our quotes caused a problem with scripting bartender.

Wars have been started over less.
To me the biggest problem with using MFR part numbers is that you’re putting yourself at the mercy of someone else. Part labels are small. Machine programs might break. Even revision blocks on a document might be too small. Often the MFR will change one letter in the middle of their long alphanumeric part number which causes mix-ups.
I tend to think a non-intelligent sequential number is the best way to go for purchased parts. Think about the time spent typing a 16 character alphanumeric part number correctly vs an 8 digit number on numeric keypad. Multiply that by 100,000. This adds up to man-weeks over the course of a year. The description, class and analysis code are the best ways to sort and search for parts.

1 Like

You don’t even know.

I prefer sequential, non-significant part numbers too.
While “significant” part numbering schemes seem “nice” at first… they always end up breaking down over time ( at least every site I’ve seen them used ) .

I’d rather use separate fields for grouping/coding… e.g. Reference Category, Attributes, UD’s, etc… “Usually” makes it easier to deal with the changes/exceptions as they start creeping in.

Reminds me in the 80’s being assigned to the engineering group tasked with applying Brisch codes to all their parts (AmHoist - 100 years worth of part numbers).
Interesting for those on the project but… in the end proved to be too complicated for ends users, the intended audience.

Also reminded of coding for hydraulic hose assemblies used in another eng dept. It really was nice with one glance to be able to know hose/fittings/length.
System died a slow death though, mostly due to employee turnover.


Pie in the sky for the electronics world for me would be a bunch of custom fields to build a part function set based on the part class. For example a resistor might have Ohms, Watts, Tolerance. Then use the Material Analysis code to capture package. Whenever the part is saved, the description is overwritten to concatenate all of the attributes and the Material analysis into something like Resistor,10k,50W,5%,SMT 0402. It would make crossing parts very easy. But setting it up for the 100,000 parts library would be hard.

One customer who made doors, defined all the sub-components as “door parts”… later, they started making Windows. the product group and part class pointed to DOOR parts. the part number said it was a door part, but the part was really generic “door or window part”. Sometimes when classifying things, it is “just a material” and should not be classified for its final purpose. What starts as a “Drill Powercord” may later be repurposed for “Computer Power Cord”. Thus, you should not have meaningful parts ESPECIALLY based on where it is used.

Reminds me of something like this I did for part entry once.
Involved multiple UD fields and logic to enable/require fields during data entry.
At the bottom of the sheet, added a button to concatenate those UD values and populate a “review” UD field, allowing manual adjustments as needed.
Finally another button would copy that string over to the parts description.
The hardest part, most time was used in getting everything defined.
I remember this dragging out due to there being a LOT of “evolution” along the way.
If it could have been better defined up front, then I’m sure there wasn’t anything very complicated in the actual building of the thing.

1 Like