I saw reference in other posts, but could not get it to work in my case… I’m having issues with Part Search (Kinetic/Classic) ignoring dashes in Part Number.
Image Below:
Even after trying to sort by Part (per other thread recommendations), note that Parts starting with “14-” appear before parts with “1-6”. Basically the dash is not being counted as a character in the sort order.
Any ideas on correcting this?
Thanks Scott.
I reviewed that posting… it shows the “default” is stringSort, which means it SHOULD be counting the dash in the sort. I checked my .sysconfig, and my default IS stringSort. However, per my screen shot, it doesn’t appear to be functioning in that manner.
Am I misreading / misunderstanding?
Interesting… this may be a SQL Sorting algorithm… it might be removing the dash from the part number as part of the sort. Note that most sorting systems DO have some form of data modification. for example, it may eliminate the upper/lower case before sorting, otherwise the letter “Z” would sort earlier than the letter “a” (see table below for ascii codes).
the dash is an ascii 45, which should sort to the top before all letters… but if you look at how the data sorted, it is as if the dash was not even there. This is yet ANOTHER reason to suggest that part numbering standards (search here for “Part Numbering Standards”) should have consistent formatting.
I agree, Tim. I’ve read through the PN White Paper multiple times. Unfortunately, we have over 100k parts in our system that have “dashes”.
Per the White Paper’s “Conclusion: Part Number Formatting”, 2.a.
Recommended: an all-numeric format with a “dash” in the middle (and no leading zeros). This allows for enough variation, while breaking the number into manageable, memorable segments…
This is exactly our format… the search / sort just isn’t cooperating for some reason.
Ironically, adding a leading zero WILL correct the sorting order, but I’d like to avoid this as it is not a recommended practice.
Interesting, while I have been aware of some of the quirks in part search, I hadn’t noticed some of the behavior related to dashes before.
Had some time to play and some of my (weird) part numbers were not even returned in part searches… hmmm.
I have entered a Case this morning with EpicCare. I’ll follow-up with details if they come up with a solution.
Thanks to all who took time to look and attempt to find a resolution!
UPD. Not, full text is not used in Stating at, it is in Part Description contains…
Do it is not your case
Thanks Olga. Is there anyway to implement these changes in the background of Epicor’s searches?
See attached image. Even the basic search (not using a “starting at” value), sorts/lists the parts out of order. See that 1-685 appears after 14-2502 instead of after 1-1941.
Worse, is that my engineers are now entering leading zeros to get these to show up correctly in “sort” order. (See blue squares). This means they’re now duplicating parts for no reason!
Well, unfortunately, it appears there’s no solution. Below is the response from EpicCare:
Looking into this, Epicor search engine does not read the dashes. The dashes are meant to make a number more readable to the consumer. So it sorts by the alphanumeric characters and dashes are not part of that, and it reads as the full number, not as separate numbers. So the search is working by design. I’ve attached a KB on how to submit an enhancement through Epicor Ideas as this would be a perfect idea for an enhancement. Let me know if you have any questions on this.
Try enabling tracing and looking at what the whereClause value is. Maybe you can make a BPM to alter it to work better.
And you’re lucky you don’t have an part numbers with underscores… They add another dimension to this sorting.
Another option would be to make a BAQ search, and set it as the primary search for the forms.
One more thing to try. After the results are returned, what happens if you toggle the sort order on the grid twice? I found that that order a search fetches and the order the grid displays them in don’t necessarily agree. I’ve had parts that don’t show up in the first 100 results, but after clicking “Next 100”, they are now not only included, but in the first 100 rows of displayed records.
