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.
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.
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.
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.