Epicor update Broke BAQ

Kinetic ERP
21

I don’t have a solution to offer, however I have used this BAQ in the past to find issues like this:

select 
	[QueryHdr].[QueryID] as [QueryHdr_QueryID],
	[QueryHdr].[AuthorID] as [QueryHdr_AuthorID],
	[QueryHdr].[Description] as [QueryHdr_Description],
	[QueryHdr].[DisplayPhrase] as [QueryHdr_DisplayPhrase]
from Ice.QueryHdr as QueryHdr
where (QueryHdr.DisplayPhrase like '%JobHead.Cust%')

In this case I searched my BAQs for any instances of “JobHead.Cust”. This would catch CustID and CustName. Thankfully, I didn’t have any BAQs that utilized those fields.

3 Likes
22

Sounds like a bunch of hassle they could avoided by just leaving that unused field in there.

1 Like
23

They probably get a couple of tickets a month asking why it’s not populated.

3 Likes
24

“Can we please make it go away so they’ll stop asking?!” …

“Sure, that’ll work. Nothing could go wrong…” (Supervisor hides with big grin…)

3 Likes
25

Is the consultant working in 24? I would go back to the previous version where it worked and remove them and then try to upload that to the new with all new RDD, reportstyle and rdl. I would offer to try, but I just overwrote my 23.2.8 with 24.1

1 Like
26

Query phrase may not be always saved, also your query does not check aliases for tables. Better to look into Ice.QueryField, something like:

select Company, QueryID from Ice.QueryField where DBTableName = 'JobHead' and FieldName like 'Cust%'
3 Likes
27

Yeah, would be great if the Data Dictionary was good about noting these…

@aosemwengie1 has a good Idea in the system for this:
Epicor should maintain the data dictionary | Epicor Ideas Portal (aha.io)

3 Likes
28

Better make that an Idea. :rofl:

29

Thought since i was referenced multiple times in this dialog, and since I was involved in this to begin with that I would address the subject.
Here are some facts:

  1. Yes, idea: KIN-I-3802 was submitted, and only had one vote.
  2. Yes, the idea came from an Epicor Employee (Someone in Support) who reported it because this is a subject that continually comes up in Support.
  3. Yes, Epicor does create its own ideas to promote Enhancements. In fact, we only do enhancements to core software if there is an idea now. (Formerly, we had a separate Enhancement list to do this with).
  4. We DID do research on these deprecated fields. we searched through the millions of lines of code, and found that there were exactly ZERO lines of code that pointed to these fields.
  5. To my knowledge, these fields have never been used, and were probably mistakenly added sometime in the past (20+ years ago). There is no need to have a customer id/name on the JobHead table because there is a JobProd table that has this information. JobProd allows for a one to many (one jobhead to many jobprod) records, thus, a single jobhead record could be making parts for multiple customers and multiple customer orders.
    One of the primary reasons for removing the fields is to eliminate confusion. People would look at the data, and incorrectly assume they could see the customer… then they would call support when the data was “missing”.
    One of the reasons why this may have become more apparent is due to the “new” Landing Pages, which shows all the data in the JobHead. people may have turned on those fields in a personalization or customization hoping to see it, and then complained when it didn’t work.
    SO… since someone in Tech Support reported it, THEY probably did so due to one or more customers reporting it, and we (Epicor Product Management and Product Development) felt it was best to clean up this confusion.
    Obviously, it was not our intent to cause problems with any BAQs or Reports out there… But I will also point out that it is not considered good practice to select data fields and push them to reports unless they are actually used. (We are as guilty of this as you all are sometimes). We want to clean this up to help improve performance. Extra data sent in datasets (Json) does increase the data size, even if the data elements are null.
    Hope that answers you questions.
7 Likes
30

And since we can create our own fields, not good practice to ever repurpose an Epicor field. Too many battle scars on that one…

6 Likes
31

I can see, though, that this could be easily done in an RDD if you choose to “include all columns”. Down the road, columns get scrapped and… bad things happen.

Not saying its a good practice… just saying its easy to do.

2 Likes
32

Now THAT’S a big ten-four good buddy…

1 Like
33

Woops. We created the UD field then saw it existed then saw it wasn’t used and used the JobHead field rather than the UD field since that was one less table join. Now we have to go back on our upgrade and fix them all and copy data over to the UD variant.

1 Like
34

Coming back to this one after the 2024.2 update to note that the number of ‘Expired’ ideas is lower than it was before the update. Expired ideas are also getting fished out of the bin and applied to work that’s happening anyway.

There’s a silver lining though - the goal of using ideas incentivizes tidying things that already got done out of the Ideas backlog in a somewhat timely way. That’s a good thing and more of that would be better! Ideas are accumulating at a rate over 150 per month. 6533 as of now. Or 6421 if you add up the list? One of those.

1 Like