Over the weekend Epicor updated our system to the current to 2024.1 and it broke seems of our BAQs - it appears that custID was removed from jobhead
Does anyone know where it went
thanks
Wait, what?
Just from the BAQ, or is it missing from the jobhead table in the designer ?
1 Like
They were removed from the table:
This was an “idea” that was implemented in 2024.1.
They appeared in Job Entry as available display columns, but never displayed anything.
@timshuwy may be able to explain more.
Personally, I think they should have just fixed it instead of removing it. Being able to see the end customer from the job is pretty valuable. Now we have to find a creative way to do it.
You should be able to update your BAQ… I would assume adding JobProd + OrderHed + Customer would get you back on track.
1 Like
LMAO they implemented an idea with 1 vote?
6 Likes
It appears to be gone from the designer – at least I can’t find it
When I removed the custID from my BAQ it started working again then when I went to try to add it back from the job_head it was gone from the list
1 Like
It is gone from the table
2 Likes
I never knew it was there so I added my own customer field to jobhead. If you are make direct you can get the data from the order. I am make to stock, so I use PartDtl to find the orders this job will be used for. You can also use the pegging data.
2 Likes
It doesn’t really make sense to have that on the job header anyways. You can have a single job supplying multiple customers, so it logically breaks down pretty fast. Was it even populated?
7 Likes
No, I don’t think it was ever populated (that I saw when trying to view the columns in Job Entry). They were always blank. I think that’s why they were removed.
1 Like
The fact that it took an idea to get rid of it, and not simply a case reporting a bug is the frustrating part.
5 Likes
If you look at the schema there are a lot of fields that have been obsoleted and they were probably added for a very large customer or possible customer long ago.
In the future, they could easy pull a list of every cloud customer that is using a field about to be whacked in a BAQ or RDD and warn them
7 Likes
As someone familiar with database practices:
- That’s normal for a database product that’s experienced the concept of normalization.
- This isn’t a positive here, since indexing and statistics are also unaware of normalization strategy, so there’s likely no real performance to be gained.
Doing this right would improve performance and reduce storage and RAM consumption dramatically, but I can’t see that happening without refactoring Epicor. It is what it is. I’ve always been doing this join structure anyway, since job → customer is a one to many relationship, and copied values will always diverge from reality sooner or later.
There are 5589 ideas (as of 2024-06-11). Delivering ideas is a target, and there’s no shortage of low hanging fruit or things that were going to be done anyway available to boost that metric. 23% of delivered ideas have 1 vote. 5% of delivered ideas have zero votes.
5 Likes
I think you nailed this one square on the head about metrics. Noted, Epicor Ideas is not just customer ideas, though I think that’s what it’s advertised as.
2 Likes
Thanks, yes I was heading down that path but was hoping I was just missing something
I’m ok with them removing it from the JobHead table, if they put that in the release notes, it’s on me to make sure I have a plan for that change, but it completely broke our RDD - At first I thought ok, my issue I have to rebuild our custom RDD and report, which also has an APR component to grab visual work instructions for the Job Travelers, but we can’t even do anything with the RDD. Kinetic or Classic. Even the Standard Epicor RDD isn’t working right. Getting error about Row Already belongs to another Table. Both on the out of box and custom RDD. Support reported it as a problem as a defect with no work around. ERPS-255388. State is in Release planning so I hope they fix it quick. We are dead in the water at 4 mfg plants without that job traveler. The Standard JobTraver is not very useful for most of our mfg plants.
4 Likes
@vfeldt Do you have a solution with that RDD in it in a previous version? A consultant with access to a lot of environments could make a custom RDD and maybe a reportstyle without the custID and CustName field in it assuming it also does not have any custom fields.
@Chris_Conn had to send me a RDD a couple of upgrades ago when mine for MtlTags got whacked.
1 Like
I’ll check on that. I am working with a consultant on this issue because I was stuck. He removed the custID and Custname from the report design and the RDD & report still had issues. Next step was to start from scratch and rebuild it but then we ran into issues just trying to use the RDD form to create joins. Even the Epicor RDD out of box is having issues. with that error