Dear Epicor, it's time to abandon leading spaces as valid characters

Kinetic ERP
1

This has come up a couple times lately on this forum.

Doing this in part numbers is intensely discouraged by Epicor itself and is often fixed by support.

But what I find to be the worst effect of this is bin names.

As I mentioned in passing a few months ago, Epicor will use the first bin alphabetically when all other defaults have failed. If it’s a bin with a space that was an accident, it doesn’t take but a few minutes before there’s a transaction against it, and now the bin is locked in forever. Of course I know this from experience.

I asked for a data fix and was denied because this is intentional to the design.

But WHY is it still intentional?

Is it truly too late to abrogate this? Can Epicor not institute this rule and handle the violations with a conversion program as part of an upgrade?

Like, if the rule existed today and you were migrating from some other system that allowed leading spaces for some reason, you’d just deal with the limitations and rename some bins. Done.

I mean, there are only so many bad decisions that I can continue to apologize to my coworkers for. I mean, is Epicor’s business plan really to keep kicking these bizarre design choices down the road for decades ad infinitum?

Epicor, be a leader, not a follower here. Take a stand against a universally hated idea. Or people will move to an ERP that learns from your mistakes and doesn’t carry this legacy baggage.

Edit 3/30/23: Ideas portal idea for this is here: https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-3355

5 Likes
2

PS, about the DMT thing that I alluded to.

After my data fix request was denied, the ticket went to DMT support and they created PRB0264094 for this. So perhaps someday they will fix DMT to allow leading spaces. This PRB was specific to bins. Perhaps you might care about part numbers and want to add that to the fire or make your own separate request.

I mean, changing DMT to allow this madness is kind of necessary, since we are in this bind already. But that’s not really what I want the outcome of all of this to be.

3

Agreed, we had this issue at a previous company with a Supplier ID made DMTs to their price lists impossible.

4

Trailing spaces is also a problem…

3 Likes
5

And embedded spaces IMHO…

And non web-safe characters…

And other non-printable characters…

Maybe we could create a community solution that creates Data Directives for “Like” items and descriptions to prevent (or fix) before entry?

:person_shrugging:

5 Likes
6

Even better, make it a Function that any process could use.

4 Likes
7

I have often thought we needed a separate topic for something called “Starter Kit for Epicor”.
Everything like no spaces in parts, jobs, revisions, etc.

2 Likes
8

You mean like a Wik…never mind. :roll_eyes:

3 Likes
9

That’s a good idea, sure.

But who would know they need a thing to fix an ERP - unless they have already suffered from the problem?

It’s just another thing that should never happen - users (admins, really) should never have to know about all the bad decisions a developer didn’t make.

  1. Are you sure you want to transact this standard-costed part that has no standard cost?
  2. Are you sure you want people to receive 2 POs against the same pack slip?
  3. Are you sure you want to allow people to receive more than is on the release?
    (Yes on that one I know it asks the user, but if you ask management, they might have a different answer…)
1 Like
10

Yes

1 Like
11

Function to do the heavy lifting with Data BPMs to call it perhaps?

2 Likes
12

Explain Like I’m 5.

1 Like
13

I believe what @Mark_Wonsil is saying is to have a BPM that could be used to check ID fields and strip out spaces and other unwanted characters before it gets saved to the DB.

14

I prefer preventing and notifying. Just blind stripping can cause unintended side effects.

15

mc hammer rap GIF VS mc hammer rap GIF

1 Like
16

As you all know, I’m always going for the brass ring…

If I were the ERP Monarch, I would have a Business Rule Builder. Each company has different rules of course. The BRB…

…OK I’m back. (Sorry, too much messaging with the kids…)

The BRB would take low-code/no-code to a new level. Users would enter business rules and BRB would transform the rules into the necessary directives to protect the data and BAQs to monitor the data. This would apply to processes too. There could be a rule that all purchased parts must have a standard cost before receipt. This would build some directives to maybe block during PO entry or warn and allow entry but block at receipt and also build a dashboard to focus users on missing costs.

So if the company decides to strip characters, then that’s their rule. Warn about dangerous characters but allow it? It’s up to them.

The BRB would also be tightly-coupled with the security setup too so SOX rules could be baked into the product.

But that’s only the ERP dreamer’s opinion.

breakfast lol GIF by Justin Gammon

^^^^ Full Stack Developer

2 Likes
17

From my experience, the root cause is Microsoft Excel… when you copy the value in a cell and then paste it somewhere, it comes out copied with that leading space. The biggest issues I’ve had through the years were people copying information from an Excel cell and pasting it into Epicor… so if Microsoft would unscrew that issue, most of this problem would disappear overnight.

18

While probably true, data validation in Epicor should have never allowed it.

4 Likes
19

We created a bunch of simple PRE BPMs to TRIM and also detect invalid hex characters which will crash Multi-Company and Epicor always gives you a DataFix… figured we just stop them from being added…

We did BPMs on:

  • Part
  • CustShip
  • Receipt
2 Likes
20

Every software company does something not normal,
There is one company that does not allow a “memo” to print on a check.