Extend Part number past 50 characters?

Is there a way to extend the PartNum field in the part table past x(50) ?

Hello Jeremy. Welcome!

No, that is not possible. But every APICS CPIM wants to know:

“Why man? For the love of Pete, why?!!!”

:wink:

What’s the business case you’re trying to solve?

1 Like

Hi Mark,
we use “Smart Part” numbers and they can go past 50. We will be implementing an online configurator (home grown) that puts parts together to create this and at times will likely go past 50

And will you be making these in advance and storing them in Inventory? Or are they always made to order?

We have lengthy smart part numbers, but use a lot of codes in place of “spelling out” specific configuartion info.

One of our parameters is current (the electrical units) and can be: 16mA, 25mA, 50mA, 100mA, 200mA, 400mA, 500mA, 1000mA, or 1500mA.

Originally we were going to go with 4 characters to hold the current in mA. Like:

   XYZ-QWRTY-0400

for the 400 mA version.

But ended up with a table: A= 16mA, B= 25mA, etc…

So those 4 characters are replaced with 1

   XYZ-QWRTY-A
1 Like

Mostly made to order though they are setup. We are moving our current system, non Epicor, to Epicor and these finished good products also are being carried over.

Plus youd be surprised how many Epicor Reports out-of-the-box won’t even show 20 characters, it will truncate it and not auto-grow :smiley:

1 Like

Hi Calvin,
Are you using a BPM or is this on the configurator side?

Fun…

Preach …

Here’s the default Part Search window. I have to widen the column to see which of these Is the one I want.

image

And here’s the Part Transaction History Tracker. It only shows the first 13 characters.
The full P/N is SPLF-A1000-BH020-020K

image

(I never bothered making a customization to make the field wider)

FWIW - the numbers are fields that specify lengths of various aspects in FT (the 1st is for active length = 1000 FT, the 2nd and 3rd are the lead lengths - each are 20 FT.) And all those parameters are available at 1 foot intervals.

OK… first of all… Quick answer: NO, Absolutly not. In fact, I do not like users going above 20 chars…
The Part NUMBER (AKA Stock Keeping Unit, or SKU) is simply an identifier for that part number internally… the LONG part number (AKA Config String, Significant part Number, or Description, or Attribute) can be used to FIND the SKU, but the Part Number itself does not need to have any significance in it. Sometimes it is nice to have part numbers with some form of category, or size, or color code, but trying to have a significant digit for each attribute that might make it different from others can become an exercise in futility.
What it sounds like you need is a way to FIND the part number from a configuration string… THIS is achievable by creating a cross reference between the part number and the config string

  1. assign a reasonable length part number, create a description and save it to the part table
  2. Create a UD Field or Table:
  • If you choose the TABLE method, you create the UD FIeld in the table to hold your config string, and a UD field to hold the cross referenced Short Part Number.
  • If you choose a simple UD Field in the Part Table, you can simply add the UD Field in Db.Part, and populate this field with the Config String
  1. Create a quicksearch that allows you to search for parts by the config string.

Other considerations:

  1. Barcodes - if you ever plan on barcoding your PN, you do not want it too long…
  2. Customers - Remember, your customers will need to reference your part numbers… on their POs. Their system probably will not support long part numbers.
  3. SUPPLIERS - Remember, your Supplier will need to reference your PN too… their system may not support the long part number.

It is best to figure out a way to keep your part number short and sweet.

3 Likes

We mostly use the configurator. But have a couple of rare products that are “configured” in Excel.

The excel file takes user inputs and generates the P/N. Then uses some look-up tables and “hard coded” formulas to populate the BOM. The BOM is in a format that makes for “easy” copying from Excel and Paste Insert into the Job or Quote details.

edit

One thing to know… If you’re multi-site and want to build in site A, but ship from site B, the part will have to go into inventory, so a Part record will be required. Even if it is a one-off sale :frowning:

We have a button on Part Entry that’s called Next Part an it requires you to select the Product Group, Class and Material Classification (UDCodes), once we have those 3, we generate you the next PREFIX-SUBPREFIX-00001 PartNumber.

In the past at other locations we had a Part Number Configurator, which was a single-page HTML that asked you to pick options for your part and it generated the PartNum and Description (just a html form). Then Submitted it to Epicor using API or Service Connect.

1 Like

I, too, have worked with large “smart” part numbering systems - also a highly configurable part. The smart system broke down so many times. The part number got so long that it was impossible to get reps to create it without some application and don’t even think about reading one over the phone. Like Calvin, we created a short-cut for some items but then also kept the old system. :roll_eyes:

So what we did is we tried to strike a balance to make a good part number and still be descriptive. So the part number became a family of parts. We could usually create a part with significant meaning but then just added the date at the end and stayed under 20 characters. BUT, we used the Description field to put in the full “Smart” string. Now we could put the part into inventory, still be able to reference it with a customer, and still do some reporting based on the description.

What I would do differently today is that I would generate a JSON string that completely describes the part and then write a routine to correctly format the smart string for the description.

Basically, everything that @timshuwy said… :rofl:

1 Like

Similar to @timshuwy’s suggestion is what Phoenix Contact does.

The have a “Part Number” and a “Catalog Number” Their Catalog Num is really their Part Number (usually a 7 or 8 digit number) And their “Part Num” is the one that kind of indicates what it is.

“Part Num”: PT 1,5/ 5-PVH-5,0 (1.5 mm^2 cross setion, 5 Pos, … 5.0 mm pitch…)
Catalog Num: 1934890

STORY TIME:
Back in 1985 (wow… 35 years ago)… someone asked me to change the system I had programmed. I had made the part number field 12 digits (to support our “10 digit part number” which was really 12 digits including the two dashes in the middle of the 10 digits… long story).
Anyway… back to the story… A Salesman said I needed to expand the part number to 32 digits in order to fit in the new part numbering scheme they needed. The new product line was a new type of “delay line” transformer/inductor thingy… he needed the 32 digits to express variable delay settings/outputs for the product so that they could easily order the parts.
I asked: “How Many different delay lines do you expect to sell over the next year?” - Answer: “Oh, maybe a couple of dozen”… Guess what… they got their own new series of 10-digit part numbers… something like “4215-0001-00”, “4215-0002-00”, “4215-0003-00”… That should last another 10-20 years before we need a new series.
The first 4 digits signified the “Delay line”… the second 4 serial digits signified which style. the last two were something we always added to support slight variations in design, packaging, or special quality requirements that made the part different (rarely anything other than “-00”).
Story done.

2 Likes

Maybe I’ll just get the company to change what they’ve been doing for the last 20 years :rofl:
I agree, however, non-inventoried parts should not be longer than 20 char.

How many past 50 do you need?

We have a few product groups that can go past 50 characters. Currently loaded 4 groups and only 1 FG smart part number gave an issue. But from what I understand the series where the problem will be is in future ones. I can’t actually get at the old system as we have an on site tech pulling the data out. It’s a home grown system (Unix) that is way out of date. This is the first of many I believe.

unfortuantely the old system does not consider the smart part number an actual part number. Instead it’s used to only identify the materials needed due to the systems limitations. Moving forward we will need to change some things to fit Epicor and a better business model in general. I’ll just be difficult to get everyone on board to make a clear decision.