Part.PartNum field special characters

Epicor ERP 9
1

Epicor version 9.05.701

Is there an official list of what characters NOT TO use in the part.partnum field?
I’ve read its recommended to stay with alpha-numeric but wondered what specific characters to definitely avoid and what impact it could have if used.

Thanks in advance.

1 Like
2

My personal favorite? Numbers and optional dashes. It works with all bar-coding schemes (UPC is only numeric), quick entry on a keypad, you can checksum it to prevent “one-off” errors, it’s web-safe (no quotes, ampersands, angle brackets) and easy to remember in small groups, like a phone number or government ID.

And anyone who uses mixed-case has a special place in HeLL… :slight_smile:

Mark W.

3 Likes
3

I’m with @Mark_Wonsil KISS is the best approach. Numeric or Alpha Numeric nothing else but dashes. I don’t get the obsession with part numbers.
I have dealt with hundreds of customers a lot of them have these “magic schemes” on part naming and in theory it all sounds great, but they are a nightmare to implement and always someone screws up and gets it out of sequence or there are special exceptions. Keep it Simple is the best approach.

3 Likes
4

Thank you for the responses.
I was just curious if there is anything official documented about this.
I’ve emailed epicor support too and awaiting their response.

5

There are multiple things at play here… keeping in mind that the Part.PartNum field is a TEXT field, it can physically accept any text character. Including an asterisk. And yes, I’ve had customer who used BOTH asterisks and question marks in their part numbering scheme.

BEST PRACTICE is an entirely separate animal, and since Windows has things like “special characters” that have their own magic incantations, using those characters (which are “legal” in Epicor) makes it extremely difficult to export a list of part numbers to Excel, for instance.

I’m with @Mark_Wonsil and @josecgomez, Simple. Numbers 0-9, letters A-Z (stick with caps for easier readability), and a dash (in printer terms, it’s an n-dash). Any other character, to me, would require a really legitimate business need (and “because we’ve always done it this way” is NOT a legitimate business need), and will most likely at some point require a workaround for something.

1 Like
6

We had so many issues that we had to create a Data directive on part table with this condition code which if true, is generating an exception message to the user, preventing the save.
“If new added row, and the condition of the personilized code is valid:”

foreach(var part in ttPart)
{
	if(!new System.Text.RegularExpressions.Regex("^[a-zA-Z0-9_-]*$").IsMatch(part.PartNum))
	{
		return true;
	}
}

return false;
2 Likes
7

Just one small adjustment…

if(!new System.Text.RegularExpressions.Regex("^[A-Z0-9_-]*$").IsMatch(part.PartNum))

There, that’s better. :wink:

3 Likes
8

Epicor consulting did create an “Epicor Part Numbering Standards.pdf” doc with this section from it:

image
image.png918×734 112 KB

EDIT: shout out to @timshuwy who put it together :slight_smile:

6 Likes
9

Attached is the complete document on Part Numbering Standards… it was written in 2013, but nothing has changed. It explains all the reasoning:
Part-Numbering-Standards-WP-ENS-0614.pdf (1.0 MB)

5 Likes
10

Em dashes, quotes, and fancy quotes kill us.
An Em dash (the fancy longer dash) worked its way in, and we ended up with 2 p/n’s that looked the same, but only the one with the regular dash could be entered from the keyboard.

Quotes and apostrophes can causes issues when exporting. People used them for inch and foot ( XPED3/8" was an actual p/n in our system :confounded: )

I may implement that data directive to prevent “bad characters”

1 Like
11

Clipped off a very important part of that page …
Screenshot_20180622-174420

2 Likes
12

we send out a data fix that removes leading spaces on a not infrequent basis because " partnumhere" and “partnumhere” look the same in the UI, but, are really two different things. Please, avoid spaces in the part number field!

2 Likes
13

Thank you for all the replies on this. This is most useful.
To go “full circle” on this, we were using costing workbench, loading parts but not all were appearing in the purchased / manufactured tabs.

14

offical epicor reply:

image
image.png1734×417 49.1 KB

15

They honestly suggest against using a hyphen (which I assume they mean the minus sign)???

16

Seems that way …

17

The “Engineers” at work have finally forced my hand.

//Barcode 39 Only, without space, percent, dollar, or asterisk(* which is not a true Barcode 39 Character)
if(new System.Text.RegularExpressions.Regex("^[A-Z0-9._+-]*$").IsMatch(matchThis))
{
    //Good Part
}
else
{
    //Are you serious? 
}

Edit:

Old 
//Barcode 39 Only, without space or asterisk(* which is not a true Barcode 39 Character)
if(new System.Text.RegularExpressions.Regex("^[A-Z0-9._+%\\$-]*$").IsMatch(matchThis))
{
    //Good Part
}
else
{
    //Are you serious? 
}
18

You allow the percent symbol? How would your users do a search for that when the underlying SQL query uses ‘LIKE’?

19

No, we decided against it about 5 minutes after I posted it.
We got rid of the dollar too. :rofl:

So FIFY. :wink:

1 Like
20

just a warning… if you happen to use that carrot symbol in the middle of a bunch of numbers, it looks like a math statement and some systems might try to inturpret it, causing an error:
12345^12345 can become a very (too) large number.
Same goes for the letter E… I had this happen to me on one system.
12345E12345 is also inturpreted as a large number.
all that said, warning included, i approve of the approach.