Special Characters in Part Number Descriptions

system · November 15, 2012, 2:27pm

Thank you all for the feedback and advice!

Ree

Group:

We are working on uploading our companyâ€™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.

Engineering maintains a very extensive part description on some parts. Here is an example:

#18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)

We are being advised that all special characters need to be stripped out of our part descriptions â€“ that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?

We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?

Thanks!

Ree

[Non-text portions of this message have been removed]

system · November 13, 2012, 9:59am

I have a custom form that we created that has 3 tabs and obviously all ud fields on it. When launched from the menu i have it on we get a
"Layer Verification Failure" error. "Customization TrainTrack905-1 for the application App.UD01Entry.UD01 Form failed validation for build 9.05.700C."
If I go to customization maintenance and try to force the validation there is a whole page of warnings like:
Â
Control NameÂ Â Â Â Â Â Prop NameÂ Â Â Â Â Â Â Â Â Â Prop ValueÂ Â Â Â WarningÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â KeyÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Record Type
Â lblEpiCustom6Â Â Â Invalid ParentÂ Â Â Â Â Â Â Â Â -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Parent is not validÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Controls
Â lblEpiCustom6Â Â Â Â TopÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 29Â Â Â Â Â Â Â Â Â Â Â Â Â Â Control is not create. Could notÂ Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Properties
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â set the propertyÂ Â Â Â
Â
There is a whole page of these with similar messages. I would really hate to have to recreate these 3 tabs and all of the fields and BPMs that go along with it. Any 'easy button' solutions any one of you have?
Â
If I go into Developer and run it it runs fine. When I come out I can then run it okay as well. But as soon as someone else tries to open it and gets that message then I can launch it anymore either...
Â
Thanks in advance for any direction you can provide.

Melissa Hietala
UMC, Inc.
melissah@...

[Non-text portions of this message have been removed]

system · November 13, 2012, 11:46am

Didn't appear to post the first time...

Melissa Hietala
UMC, Inc.
melissah@...

----- Forwarded Message -----
From: melissa hietala <kevmel822@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Tuesday, November 13, 2012 8:59 AM
Subject: UD Form Customizations failed the 700C patch

I have a custom form that we created that has 3 tabs and obviously all ud fields on it. When launched from the menu i have it on we get a
"Layer Verification Failure" error. "Customization TrainTrack905-1 for the application App.UD01Entry.UD01 Form failed validation for build 9.05.700C."
If I go to customization maintenance and try to force the validation there is a whole page of warnings like:
Â
Control NameÂ Â Â Â Â Â Prop NameÂ Â Â Â Â Â Â Â Â Â Prop ValueÂ Â Â Â WarningÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â KeyÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Record Type
Â lblEpiCustom6Â Â Â Invalid ParentÂ Â Â Â Â Â Â Â Â -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Parent is not validÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Controls
Â lblEpiCustom6Â Â Â Â TopÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 29Â Â Â Â Â Â Â Â Â Â Â Â Â Â Control is not create. Could notÂ Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Properties
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â set the propertyÂ Â Â Â
Â
There is a whole page of these with similar messages. I would really hate to have to recreate these 3 tabs and all of the fields and BPMs that go along with it. Any 'easy button' solutions any one of you have?
Â
If I go into Developer and run it it runs fine. When I come out I can then run it okay as well. But as soon as someone else tries to open it and gets that message then I can launch it anymore either...
Â
Thanks in advance for any direction you can provide.

Melissa Hietala
UMC, Inc.
melissah@...

[Non-text portions of this message have been removed]

system · November 14, 2012, 12:41am

Hi Melissa,

I have encountered a similar issue on UD100 whereby when u select the form customization to ALL Companies it attaches well but when u load the form it returns the base UD100. Apparently this is a bug in E9.700 that has been fixed in E9.701. Read through the E9.701 Release Notes and you shall see many bugs have been fixed that i had come across. I have attached a copy here.

hope this helps

Regards

Anthony

________________________________
From: melissa hietala <kevmel822@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Tuesday, November 13, 2012 7:46 PM
Subject: [Vantage] Fw: UD Form Customizations failed the 700C patch

Â
Didn't appear to post the first time...

Melissa Hietala
UMC, Inc.
melissah@...

----- Forwarded Message -----
From: melissa hietala <kevmel822@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Tuesday, November 13, 2012 8:59 AM
Subject: UD Form Customizations failed the 700C patch

I have a custom form that we created that has 3 tabs and obviously all ud fields on it. When launched from the menu i have it on we get a
"Layer Verification Failure" error. "Customization TrainTrack905-1 for the application App.UD01Entry.UD01 Form failed validation for build 9.05.700C."
If I go to customization maintenance and try to force the validation there is a whole page of warnings like:
Â
Control NameÂ Â Â Â Â Â Prop NameÂ Â Â Â Â Â Â Â Â Â Prop ValueÂ Â Â Â WarningÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â KeyÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Record Type
Â lblEpiCustom6Â Â Â Invalid ParentÂ Â Â Â Â Â Â Â Â -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Parent is not validÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Controls
Â lblEpiCustom6Â Â Â Â TopÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 29Â Â Â Â Â Â Â Â Â Â Â Â Â Â Control is not create. Could notÂ Â Â Â Â a4d47e34-d527Â Â Â Â Â Â Properties
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â set the propertyÂ Â Â Â
Â
There is a whole page of these with similar messages. I would really hate to have to recreate these 3 tabs and all of the fields and BPMs that go along with it. Any 'easy button' solutions any one of you have?
Â
If I go into Developer and run it it runs fine. When I come out I can then run it okay as well. But as soon as someone else tries to open it and gets that message then I can launch it anymore either...
Â
Thanks in advance for any direction you can provide.

Melissa Hietala
UMC, Inc.
melissah@...

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

system · November 14, 2012, 8:31am

Group:

We are working on uploading our companyâ€™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.

Engineering maintains a very extensive part description on some parts. Here is an example:

#18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)

We are being advised that all special characters need to be stripped out of our part descriptions â€“ that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?

We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?

Thanks!

Ree

[Non-text portions of this message have been removed]

system · November 14, 2012, 8:43am

You're being advised to strip special char's out of your Part *description*? That doesn't sound right to me. You're right, it's just a text field. Did you challenge their advice and ask "why" ?

Part NUMBER, different story. It's a good idea to keep it alpha-numeric only. I prefer alphanumeric and no special characters in my PN. For me, it's for barcoding. However, Code39 does support the full ASCII character set including underscores and backslashes.

I don't know why you'd be advised to replace one special character for another special character in your Part Number. Doesn't make sense to me at all.

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ree Pruehs
Sent: Wednesday, November 14, 2012 8:31 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Special Characters in Part Number Descriptions

Group:

We are working on uploading our companyâ€™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.

Engineering maintains a very extensive part description on some parts. Here is an example:

#18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)

We are being advised that all special characters need to be stripped out of our part descriptions â€“ that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?

We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?

Thanks!

Ree

[Non-text portions of this message have been removed]

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2441/5394 - Release Date: 11/14/12

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2441/5394 - Release Date: 11/14/12

[Non-text portions of this message have been removed]

system · November 14, 2012, 9:00am

We have all kinds of characters in both our part numbers and descriptions.
We've never had any issues because of it.

*John Driggers*
**
*Chief Data Wrangler*
*
*
*I have an Epicor blog <http://usdoingstuff.com/>. How useful is that?*
*
*:: 904.404.9233
:: waffqle@...
:: http://www.usdoingstuff.com <http://www.usdoingstuff.com/>

*

*

On Wed, Nov 14, 2012 at 8:31 AM, Ree Pruehs <rpruehs@...> wrote:

> **
>
>
> Group:
>
>
>
> We are working on uploading our companyï¿½s data into Epicor 9.05.604 (we
> are currently using eBackOffice 7.2.03 sp5, so the process is an adventure
> all on its own) and have run into a snarl.
>
>
>
> Engineering maintains a very extensive part description on some parts.
> Here is an example:
>
>
>
> #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)**
> BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
>
>
>
> We are being advised that all special characters need to be stripped out
> of our part descriptions ï¿½ that they can cause issues in E9. Why would
> special characters cause issues in E9 in what is, essentially, a text
> field? Is this true of all special (non-alpha-numeric, plus dash and
> underscore) characters?
>
>
>
> We are also being advised that we need to change some of our part numbers
> to replace backslash characters with underscores. Is there any workaround
> for this?
>
>
>
> Thanks!
>
>
>
> Ree
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>

[Non-text portions of this message have been removed]

system · November 14, 2012, 9:22am

Ree,

The only issue I can think of is if you were to dump your files down to a csv or XML, you may have to do some translation on those characters. But the Epicor 9 application itself shouldnâ€™t care whether you have any special characters.

Kevin Simon

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ree Pruehs
Sent: Wednesday, November 14, 2012 8:31 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Special Characters in Part Number Descriptions

Group:

We are working on uploading our companyâ€™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.

Engineering maintains a very extensive part description on some parts. Here is an example:

#18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)

We are being advised that all special characters need to be stripped out of our part descriptions â€“ that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?

We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?

Thanks!

Ree

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

system · November 14, 2012, 9:30am

Whoever said that for the DESCRIPTIONS doesnâ€™t know what they are talking aboutâ€¦.now the part NUMBER is another story. We use dashes and underscores in our part NUMBERS without issues. But this is all we use.

M. Manasa Reddy
manasa@...<mailto:manasa@...>
630.806.2000 x1515

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ree Pruehs
Sent: Wednesday, November 14, 2012 7:31 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Special Characters in Part Number Descriptions

Group:

We are working on uploading our companyâ€™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.

Engineering maintains a very extensive part description on some parts. Here is an example:

#18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)

We are being advised that all special characters need to be stripped out of our part descriptions â€“ that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?

We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?

Thanks!

Ree

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

system · November 14, 2012, 9:37am

One character I would recommend staying away from is the tilde ~, Epicor uses it as delimiter at times and while the description is probably safe just a good practice overall in relationship to Epicor. Asterisks can bite you from time to time if used in a search as depending on the search approach it is treated as the wildcard. Dashes can be seen as ranges in some situations.

I tend to recommend that part numbers just use numbers and letters as much as possible. If the part numbers will be used by other systems, especially older systems, special characters can present challenges.

If you use bar-coding special characters can also be an issue depending on the bar-code symbol/font you use

Vaguely I remember hearing the recommendation on backslashes but can't recall the details. Did they give a reason for the backslash issue with the part number?

Jim Kinneman
Encompass Solutions, Inc

--- In vantage@yahoogroups.com, "Ree Pruehs" <rpruehs@...> wrote:
>
> Group:
>
>
>
> We are working on uploading our companyÃ¢Â€Â™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
>
>
>
> Engineering maintains a very extensive part description on some parts. Here is an example:
>
>
>
> #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
>
>
>
> We are being advised that all special characters need to be stripped out of our part descriptions Ã¢Â€" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
>
>
>
> We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
>
>
>
> Thanks!
>
>
>
> Ree
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

system · November 14, 2012, 9:37am

The only hitch I have ever seen is an asterisk not playing nice with the "Where Part Description" contains field. However there are about 1 million other ways to skin that cat, and I haven't tested it since 607A

--- In vantage@yahoogroups.com, Manasa Reddy <manasa@...> wrote:
>
> Whoever said that for the DESCRIPTIONS doesnÃ¢Â€Â™t know what they are talking aboutÃ¢Â€Â¦.now the part NUMBER is another story. We use dashes and underscores in our part NUMBERS without issues. But this is all we use.
>
>
>
> M. Manasa Reddy
> manasa@...<mailto:manasa@...>
> 630.806.2000 x1515
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ree Pruehs
> Sent: Wednesday, November 14, 2012 7:31 AM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Special Characters in Part Number Descriptions
>
>
>
> Group:
>
>
>
> We are working on uploading our companyÃ¢Â€Â™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
>
>
>
> Engineering maintains a very extensive part description on some parts. Here is an example:
>
>
>
> #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
>
>
>
> We are being advised that all special characters need to be stripped out of our part descriptions Ã¢Â€" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
>
>
>
> We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
>
>
>
> Thanks!
>
>
>
> Ree
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> [Non-text portions of this message have been removed]
>

system · November 14, 2012, 10:51am

Some of our part descriptions are similar to yours: #18 3/8â€etc â€¦ Not a problem. As noted, the â€œwhere part description containsâ€ search doesnâ€™t work well with them.

A lot of reports & screens will cut off the end of long descriptions, but thatâ€™s a trivial formatting/screen space issue.

Brian.

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of jgiese1988
Sent: Wednesday, November 14, 2012 9:38 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Special Characters in Part Number Descriptions

The only hitch I have ever seen is an asterisk not playing nice with the "Where Part Description" contains field. However there are about 1 million other ways to skin that cat, and I haven't tested it since 607A

--- In vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>, Manasa Reddy <manasa@...> wrote:
>
> Whoever said that for the DESCRIPTIONS doesnÃ¢â‚¬â„¢t know what they are talking aboutÃ¢â‚¬Â¦.now the part NUMBER is another story. We use dashes and underscores in our part NUMBERS without issues. But this is all we use.
>
>
>
> M. Manasa Reddy
> manasa@...<mailto:manasa@...>
> 630.806.2000 x1515
>
> From: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com> [mailto:vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>] On Behalf Of Ree Pruehs
> Sent: Wednesday, November 14, 2012 7:31 AM
> To: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Special Characters in Part Number Descriptions
>
>
>
> Group:
>
>
>
> We are working on uploading our companyÃ¢â‚¬â„¢s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
>
>
>
> Engineering maintains a very extensive part description on some parts. Here is an example:
>
>
>
> #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
>
>
>
> We are being advised that all special characters need to be stripped out of our part descriptions Ã¢â‚¬" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
>
>
>
> We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
>
>
>
> Thanks!
>
>
>
> Ree
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]

system · November 14, 2012, 10:53am

In addition to the other great comments, if you plan to display your
descriptions on web pages, you may have to substitute some characters with
HTML entities like &QUOT; or &AMP;

Mark W.

[Non-text portions of this message have been removed]

system · November 15, 2012, 7:07am

If you are following the DMT Labs for importing data, I believe they use csv. That part description with the comma in it will cause you issues.

When importing with DMT we have been using excel spreadsheets not csv files and we have had no issues with descriptions, although one version we had trouble with project numbers when we had some project numbers that were all numeric and then the next row had a project number that was prefixed with an alpha in the same import, basically the DMT blanked out the project numbers for the alpha projects and then it tried to import duplicate projects with a blank project number which was rather mad.

We got around that issue by doing two imports one with projects that had the alpha prefix and the others with all numeric project numbers.

I agree with previous comments with things like *, ~ and any XML syntax that might be misinterpreted by the system.

Cheers
Simon Hall

--- In vantage@yahoogroups.com, "jckinneman" <jckinneman@...> wrote:
>
> One character I would recommend staying away from is the tilde ~, Epicor uses it as delimiter at times and while the description is probably safe just a good practice overall in relationship to Epicor. Asterisks can bite you from time to time if used in a search as depending on the search approach it is treated as the wildcard. Dashes can be seen as ranges in some situations.
>
> I tend to recommend that part numbers just use numbers and letters as much as possible. If the part numbers will be used by other systems, especially older systems, special characters can present challenges.
>
> If you use bar-coding special characters can also be an issue depending on the bar-code symbol/font you use
>
> Vaguely I remember hearing the recommendation on backslashes but can't recall the details. Did they give a reason for the backslash issue with the part number?
>
> Jim Kinneman
> Encompass Solutions, Inc
>
> --- In vantage@yahoogroups.com, "Ree Pruehs" <rpruehs@> wrote:
> >
> > Group:
> >
> >
> >
> > We are working on uploading our companyÃ¢Â€Â™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
> >
> >
> >
> > Engineering maintains a very extensive part description on some parts. Here is an example:
> >
> >
> >
> > #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
> >
> >
> >
> > We are being advised that all special characters need to be stripped out of our part descriptions Ã¢Â€" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
> >
> >
> >
> > We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Ree
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

system · November 15, 2012, 8:55am

We have had a nasty performance issue that I THINK (can't find hard evidence, but lots of circumstantial evidence) may be caused by NON-PRINTING characters in large text fields (Part.Description, Part.PurComment, Part.MfgComment, and the like). Much of this data was originally DMT'd in from Excel spreadsheets, and if there was a hard return in a cell, it got uploaded as a non-printing character.

Our Shipping department would frequently get the dreaded 7175 and 7224 errors, killing their session, usually during the heavier usage times of the day. Out of desperation I dumped every single part number and those three fields, removed the non-printing characters (using the Excel CLEAN function), and re-uploaded the changed fields. Probably about 3-4 dozen part numbers were affected.

Shipping's session drops have significantly declined.

I can't prove a link, since I can't get them to tell me what packing slip number they're working on when they die, so I can investigate the cause... but the evidence does point that way.

Moral of story, non-printing characters can be hazardous to your health.

Good luck!

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com, "s1mhall" <s1mhall@...> wrote:
>
> If you are following the DMT Labs for importing data, I believe they use csv. That part description with the comma in it will cause you issues.
>
> When importing with DMT we have been using excel spreadsheets not csv files and we have had no issues with descriptions, although one version we had trouble with project numbers when we had some project numbers that were all numeric and then the next row had a project number that was prefixed with an alpha in the same import, basically the DMT blanked out the project numbers for the alpha projects and then it tried to import duplicate projects with a blank project number which was rather mad.
>
> We got around that issue by doing two imports one with projects that had the alpha prefix and the others with all numeric project numbers.
>
> I agree with previous comments with things like *, ~ and any XML syntax that might be misinterpreted by the system.
>
> Cheers
> Simon Hall
>
>
> --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> >
> > One character I would recommend staying away from is the tilde ~, Epicor uses it as delimiter at times and while the description is probably safe just a good practice overall in relationship to Epicor. Asterisks can bite you from time to time if used in a search as depending on the search approach it is treated as the wildcard. Dashes can be seen as ranges in some situations.
> >
> > I tend to recommend that part numbers just use numbers and letters as much as possible. If the part numbers will be used by other systems, especially older systems, special characters can present challenges.
> >
> > If you use bar-coding special characters can also be an issue depending on the bar-code symbol/font you use
> >
> > Vaguely I remember hearing the recommendation on backslashes but can't recall the details. Did they give a reason for the backslash issue with the part number?
> >
> > Jim Kinneman
> > Encompass Solutions, Inc
> >
> > --- In vantage@yahoogroups.com, "Ree Pruehs" <rpruehs@> wrote:
> > >
> > > Group:
> > >
> > >
> > >
> > > We are working on uploading our companyÃ¢Â€Â™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
> > >
> > >
> > >
> > > Engineering maintains a very extensive part description on some parts. Here is an example:
> > >
> > >
> > >
> > > #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
> > >
> > >
> > >
> > > We are being advised that all special characters need to be stripped out of our part descriptions Ã¢Â€" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
> > >
> > >
> > >
> > > We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > Ree
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>

system · November 15, 2012, 9:24am

Iâ€™ve had issues with special characters on DMT before â€“ when theyâ€™ve hit the RETURN character for blank lines. Iâ€™ve ran a BAQ against the Part table, exported to Excel, and on the reimport via DMT, we lost the RETURN characters. It wasnâ€™t completely gone, but it didnâ€™t show as a new line. I forget what it was, but I had to run a 4GL program and replace one character (maybe character code â€˜013â€™, something like the CR without the CRLF) to the new line character.

Kevin

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of s1mhall
Sent: Thursday, November 15, 2012 7:07 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Special Characters in Part Number Descriptions

If you are following the DMT Labs for importing data, I believe they use csv. That part description with the comma in it will cause you issues.

When importing with DMT we have been using excel spreadsheets not csv files and we have had no issues with descriptions, although one version we had trouble with project numbers when we had some project numbers that were all numeric and then the next row had a project number that was prefixed with an alpha in the same import, basically the DMT blanked out the project numbers for the alpha projects and then it tried to import duplicate projects with a blank project number which was rather mad.

We got around that issue by doing two imports one with projects that had the alpha prefix and the others with all numeric project numbers.

I agree with previous comments with things like *, ~ and any XML syntax that might be misinterpreted by the system.

Cheers
Simon Hall

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , "jckinneman" <jckinneman@...> wrote:
>
> One character I would recommend staying away from is the tilde ~, Epicor uses it as delimiter at times and while the description is probably safe just a good practice overall in relationship to Epicor. Asterisks can bite you from time to time if used in a search as depending on the search approach it is treated as the wildcard. Dashes can be seen as ranges in some situations.
>
> I tend to recommend that part numbers just use numbers and letters as much as possible. If the part numbers will be used by other systems, especially older systems, special characters can present challenges.
>
> If you use bar-coding special characters can also be an issue depending on the bar-code symbol/font you use
>
> Vaguely I remember hearing the recommendation on backslashes but can't recall the details. Did they give a reason for the backslash issue with the part number?
>
> Jim Kinneman
> Encompass Solutions, Inc
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , "Ree Pruehs" <rpruehs@> wrote:
> >
> > Group:
> >
> >
> >
> > We are working on uploading our companyÃ¢â‚¬â„¢s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
> >
> >
> >
> > Engineering maintains a very extensive part description on some parts. Here is an example:
> >
> >
> >
> > #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
> >
> >
> >
> > We are being advised that all special characters need to be stripped out of our part descriptions Ã¢â‚¬" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
> >
> >
> >
> > We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Ree
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

[Non-text portions of this message have been removed]

system · November 15, 2012, 10:02am

The number and characters issue I believe is more a .net/Microsoft issue. The methods that read the Excel file make an assumption on the type of data in a column based on the first few rows. If the column has numbers for the first few rows it treats the rest of the column as having numbers and then when it runs across letters it treat them as numbers which results in zero. I wrote an import routine using Excel and found that I had to make all columns in Excel be formatted as text and make any conversion based on the target of the data inside of my routine. I am guessing DMT probably uses the standard .net routines to read Excel so may suffer from the same issue.

Jim Kinneman
Encompass Solutions, Inc

--- In vantage@yahoogroups.com, "s1mhall" <s1mhall@...> wrote:
>
> If you are following the DMT Labs for importing data, I believe they use csv. That part description with the comma in it will cause you issues.
>
> When importing with DMT we have been using excel spreadsheets not csv files and we have had no issues with descriptions, although one version we had trouble with project numbers when we had some project numbers that were all numeric and then the next row had a project number that was prefixed with an alpha in the same import, basically the DMT blanked out the project numbers for the alpha projects and then it tried to import duplicate projects with a blank project number which was rather mad.
>
> We got around that issue by doing two imports one with projects that had the alpha prefix and the others with all numeric project numbers.
>
> I agree with previous comments with things like *, ~ and any XML syntax that might be misinterpreted by the system.
>
> Cheers
> Simon Hall
>
>
> --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> >
> > One character I would recommend staying away from is the tilde ~, Epicor uses it as delimiter at times and while the description is probably safe just a good practice overall in relationship to Epicor. Asterisks can bite you from time to time if used in a search as depending on the search approach it is treated as the wildcard. Dashes can be seen as ranges in some situations.
> >
> > I tend to recommend that part numbers just use numbers and letters as much as possible. If the part numbers will be used by other systems, especially older systems, special characters can present challenges.
> >
> > If you use bar-coding special characters can also be an issue depending on the bar-code symbol/font you use
> >
> > Vaguely I remember hearing the recommendation on backslashes but can't recall the details. Did they give a reason for the backslash issue with the part number?
> >
> > Jim Kinneman
> > Encompass Solutions, Inc
> >
> > --- In vantage@yahoogroups.com, "Ree Pruehs" <rpruehs@> wrote:
> > >
> > > Group:
> > >
> > >
> > >
> > > We are working on uploading our companyÃ¢Â€Â™s data into Epicor 9.05.604 (we are currently using eBackOffice 7.2.03 sp5, so the process is an adventure all on its own) and have run into a snarl.
> > >
> > >
> > >
> > > Engineering maintains a very extensive part description on some parts. Here is an example:
> > >
> > >
> > >
> > > #18 BLK #8522 X 5IN (W18-30) C/O & STRIP .25 EA END, **(USE 8509708)** BARREL LOCK (F) TYPE W/ WEATHER SEAL - AS PURCHASED (TG #2500094-AS)
> > >
> > >
> > >
> > > We are being advised that all special characters need to be stripped out of our part descriptions Ã¢Â€" that they can cause issues in E9. Why would special characters cause issues in E9 in what is, essentially, a text field? Is this true of all special (non-alpha-numeric, plus dash and underscore) characters?
> > >
> > >
> > >
> > > We are also being advised that we need to change some of our part numbers to replace backslash characters with underscores. Is there any workaround for this?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > Ree
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>

Topic		Replies	Views
Symbols in Part Numbers Yahoo Archive	1	677	September 17, 2015
E9 - Quote symbol in PartNum not joining in Report Data Definiti Yahoo Archive	7	746	February 22, 2013
Symbols in Part Numbers Yahoo Archive	4	680	September 16, 2015
Part description search Yahoo Archive	11	559	September 11, 2012
Part Number advise - 5 OPTIONS Yahoo Archive	0	446	August 30, 2001

Special Characters in Part Number Descriptions

Related Topics