Is there a way to globally change the Seq field to accept more than 4 digits? i always assumed it was limited to 8 digits like most of the other ID fields but now the only way for me to hit 5 digits is by letting Epicor add it on. once i try and modify it though, it blocks any input and then errors out saying it exceeds the field limit.
I wouldn’t do this because I’m thinking that limit is there for a reason. Plus, Epicor may have that check in other places so it may break other things. The first thing I would be concerned is the link between PartOper, JobOper and ECOOper. So, if you want this, do it in all 3.
I was able to do this in my version. You need to go in Extended Properties for JobOper table and change the Format there:
Then, in you job entry customization, change the Mask Input for OprSeq:
It will let you save with the new format:
1 Like
That’s what I’d be concerned about too, since OprSeq is a key field that has many references in the system. I’d probably want to perform a LOT of simulations in a test system before deploying in production.
(I have looked at extending some other “key” fields a few times but… always decided against it)
Just curious, why do you need the extra digits?
That’s my first thought. If my engineering group came to me with this request my response would be “No, you split that into assemblies like a sane person. Nobody wants a thousands ops per BOM level.”
That or I’d suspect they’re trying to turn the OpSeq into some hidden code. Which would make me leave the room on the spot, for the gods demand blood for that level of sacrilege and I don’t want to be in the impact radius when the meteor hits.
2 Likes
I wonder how that will work with all the other tables using OprSeq also.
Dragos I would be interested to see if you could record labor against that op without changing the format on LaborDtl also.
I found 83 unique db tables with a OprSeq column, you would probably have to modify all of them to avoid any data corruption issues.
I am wondering if this question falls into the category of an XY PROBLEM.
I would highly discourage anyone from attempting to change this field’s length. It supports 4 digits. It is an integer. this means that it will support up to 9999 materials in a BOM (in theory IF a JOB could properly do this).
One time, a very long time ago, a customer wanted to put over 20,000 material lines onto a job. Of Course, this was not possible as a flat BOM, BUT we figured we could make 20 Assemblies with 1000 components each. We Tried… yes, the database supports this, but having one job with that many materials is just inefficient. Doing the “get Details” on the job took a long time, and the users were not happy. My recommendation was to simplify this and not try to put everything into one job. Make Sub assembly jobs and roll them into the upper jobs.
So… what is your reason for needing a bigger number?
2 Likes
That would be enough for me not to do it. I mean, even if you get away with it, I’m sure it will bite back on the next upgrade(s). Plus, OprSeq is a primary key and, once you have records added in that table, it will be a mess changing them back.
Anyway, it doesn’t work. I get the same error Opr is too large for its format of ‘>>>9’ in both MES and Time & Expense Entry (I only changed the JobOper table).