Question: Difference between Epicor Support/onsite version of Job Tracker?
All, I’ve run into an issue Epicor Support is stumped on, and thought I’d ask if anyone else has run into it. On Job Tracker, there is a field named DispSysTime on the Job Details/Material/Material Transactions grid that is hidden in the base version. If you create a Personalization to unhide the field, the field displays the value “hh:mm tt”(the format for displaying the SysTime field as a string) in the grid. It’s been doing this since our switch to E10( Epicor says this was fixed prior to the .35 patch, and sent us a screenshot showing the field value displaying correctly in with our database from a backup. However, we have NOT been able to get the same results, even after replacing Erp.UI.JobTracker.dll on my system with one directly from Support. Any help or info would be greatly appreciated!

Kind of a spooky one… :ghost:
Does that happen for every user who creates that particular Personalization? What happens if you query that field? Does it have the data you would expect? Have you cleaned up all of the Personalizations and started from base? Just some thoughts…

What ends up in Excel if you use the right-click “Copy to Excel”?

Although I dont know the bug/fix itself, the fix is almost certainly server side. As a general rule, UI’s are “dumb” in that they display stuff and if something needs doing they ask the server to do it - its the server that generates the data that is displayed. Therefore if any dll were responsible, it’d rekon it’d be Erp.Services.BO.JobEntry.dll on the server (or possibly the contract/adapter but I think that unlikely). However do not replace the dll without confirming with support, often it’ll be fine but it is possible that sometimes really obscure errors could be introduced.

Thanks, Jon! I was beginning to think that myself yesterday. I looked for a separate contract, adapter, or service DLL but could not find one. Below is the result in Excel from the Material Transactions grid:

I suspect there are two options; one is to update the system to .35, however the alternative would be to work around the existing issue, you’d need to hide the column again, add a new UD column and then in a BPM set the column to the correct string to display in the grid. The one fly in the ointment is I think the table involved is a temp table so you cant add UD fields, however it is possible to add etxra columns “on the fly” though you will need to do a small bit of c# for that.

Jon, we’re already on the .35 patch in all of our environments. This issue was SUPPOSED to be fixed at or prior to the .35 patch. Also, Support does NOT see this issue at the same patch level, which is really odd. I appreciate your input!