The business I am working for wants to have all entrys into the tables to be capitalized. the project manager said this could easily be done with a bpm. anyone done this before??
um… “all” entries into “all” tables? It would be easier to just weld the caps lock key on all the keyboards.
11 Likes
This cannot be easily done with a BPM it would require many many BPMS / Data Directives… I would go back to whomever made this request and find out the reason behind it. It is generally bad practice to arbitrarily set the case on all your data.
This is old school AS-400 style behavior but that is no longer needed
6 Likes
All joking aside, there is value in ensuring all your Part Numbers are all caps (even though Epicor is NOT case sensitive in the PartNum field, it’s a lot easier on the eyes of we mere humans when things are consistent). Part Descriptions, on the other hand, should RARELY (if ever) be all caps. Some companies like that customer/supplier names and addresses appear as all caps on documents. I’ve done LOTS of those types of BPMs, and they are pretty easy to do. Find out EXACTLY what data your management wants in all caps, and more importantly, why. As @josegomez.sixs says, this is mostly old-school stuff and the SHIFT key is quite useful. Lack of SHIFT key is equally useful.
Wow, that’s quite a requirement, any business reason for it?
I should make the point that there is a distinction between how data is STORED and DISPLAYED. There is the Data and then there is how the data is Displayed. Sometimes it matters where case is enforced, depending on what the data is, like say Serial Numbers and VIN’s. Just remember that a capital A and a lower case a is not the same value.
… A BPM… Not a chance, LOTS of BPM’s maybe.
Though I wonder if there was a way to setup a Culture or Language setting in Epicor to do this.
I checked the Runtime Styler and Extended Properties but I didn’t see a way to modify how values are displayed.
Just curious? Is he using a green[1] ASCII only screen too?
- Or amber?
4 Likes
We’ve come across the same need. Root cause seems to be that Epicor is case-agnostic on many fields, but behind the curtain, the SQL cares. We’ve had processes error out as well as things getting stuck that need un-sticking with conversion programs, fixes, updatable BAQ’s, and lots of time spent trouble shooting.
Two I can think of off the top of my head is Warehouse Bins entered as all caps, but someone manually typed a bin as lower case for an inventory transaction, and Epicor allowed it. Another one is I’ve found MES labor entries with various capitals (should be F-###### for all jobs, and I’ve found f-###### in labor detail. Not sure if that’s the cause of errors, but my theory is folks keyed them in that way, and a process somewhere didn’t find a match against a job number, and $ got left behind in WIP and didn’t make it to the general ledger…
We’re on 10.0.700.4 at the moment, and I’m looking to make a BPM to force all caps as we find discrepancies… Time to learn.
SQL only cares about caps if you tell it to, otherwise it shouldn’t. It has to do with your encoding.
Has someone been mucking about with column collation?
1 Like
Jose & Simon - Interesting. This is what I was told by one of the Epicor support folks. AFAIK, all of our configurations and performance tune-ups were done by Epicor… We were provided either a data fix or sql script to update the case to match what was originally set up in the bins so a process would run, so Epicor is aware of this issue.
I haven’t heard the term Column Collation before. Here’s a nice intro I found: Questions About SQL Server Collations You Were Too Shy to Ask - Simple Talk
The more I learn, the more I realize I don’t know!
2 Likes
I had similar issues in early 10.0, think it was 10.0.700.4. Whilst my SQL DB was in the correct collation and wasn’t case sensitive, SOME but not all Epicor screens were ignoring rows with incorrect capitalisation. Company and Plant columns were the ones that seemed mostly affect to me.
Epicor fixed the affected screens with point release updates to not worry about case, and since 10.1 I haven’t found it to be a problem on any form.
1 Like
I have not done all, but in E9 we do part and revision initial entry which then carries them throughout the system like that. In E10 if you set each value that needed to be set to .toUpper of itself in a data directive, but doing everything would be daunting.
I recall seeing some anomalies in E9 with regards to case…But can I remember which fields the where case sensitive…It was one of those “That’s look odd” moments, but you were busy doing something else at the time.
We are on 10.1.600.16 and this case issue is a problem for us…the stock status report will not report stock in bins that don’t match the master table, ie Bin is 1AB1 and the stock was transferred to 1ab1. Epicor provided a script to fix the data, but as soon as someone transfers to a bin that doesn’t match the master then its ignored. We are going to 10.2 rather than adding BPM’s to prevent this…apparently the case related issue have been fixed in this version.
1 Like
Resurrecting this post…Just came across Lots being case sensitive. Which is an issue for us as we use lots to distinguish between packed product with a unique Lot number and “Unpacked/Loose” product which gets a Lot number of “LOOSE” somehow we ended up with a LOOSE lot and a Loose Lot. That’s just too loose for me 
2 Likes
As Mark/Andris says SQL/Epicor 10.0.7.4 does actually care about case - in the early days of testing data migration, I had a lack of inconsistency in whether I capitalized the first character of the company field. I did several imports using variable formats and there were boms that could not find parts that were in part master, methods that could not be imported etc because the company field had inconsistent case - DMT all processed fine.