The solution that’s marked on this thread was for helping to narrow down the root cause of the problem for submitting to Epicor support. This problem is still open with support and development and the final update is here: Reporting Quantity from Multiple Workstations - #10 by tsmith
I’ve got a support case submitted and waiting to hear back on whether this will be accepted as a bug, but wanted to see if anyone else has run into this and how you’ve prevented this from happening barring a fix from Epicor. This is on 2025.2.13 and it only started happening after our update from 10.2.700.
We have manufacturing cells where one operation may have up to 6 employees clocked into it at once. Each operator is doing the same activity - in this case they’re assembling parts that come off an automated line. Because there are multiple operators working, we have two workstations next to the cell to help reduce the time it takes for people to report quantity and clock out at the end of the shift.
We’ve found that if multiple employees open the Report Quantity screen for that operation at the same time, fill in their individual completed amounts, and both hit submit around the same time (haven’t figured out if the timing matters or just having Report Quantity open), the Job Operation’s Completed Quantity will get clobbered and only updated by one of the entries. I have change logs showing how the QtyCompleted field is updated from 0 → 15 and then from 0 → 10 instead of 0 → 15 → 25.
Looking at Job Tracker after the fact shows that the Completed Qty is lower than the sum of the labor entries.
It looks like it’s got something to do with the Report Quantity method not handling JobOper’s row revision like it should, but I haven’t thought of a good way yet to either force JobOper to update correctly or to prevent the second Report Quantity from going through without closing and reopening the screen. Has anyone tried kicking data back or affecting other tables in a BO like Report Quantity?
I wasn’t sure if SysRevID would show in ChangeLog. But good to pull it out from SQL before and after. That’s the angle I’d take if I were going to pursue it as a bug. We’d have to prove SysRevID is not being honored when updating the second record. I follow your thought process. If it just “overwrites” the first transaction on JobOper, that’s what it sounds like might be happening.
I’d agree that it is a bug - and the SysRevID is probably the cause. You could check that in a BPM using a lookup and then throw an exception if the ds row SysRevID doesn’t match server.
I have had to do this for a screen for a customer… but I can’t recall which screen and don’t have access to the environment right now.
It makes sense that SysRevID is excluded from the change logs…not usually any time you’d want to track it since it’s just extra data to fill the logs.
I worked around this using an email BPM that pulls the SysRevID from the dataset that’s captured in a JobOper data directive. I’m pulling the SysRevID and encoding it to hex to display for both the unchanged row (BeforeImage) and the changed row.
If I submit both Report Quantities at the same time, both emails have the same unchanged record SysRevID. Both calls are using the same BeforeImage:
If I wait until the first Report Quantity screen closes (even if I had Report Quantity open and waiting to submit), then submit the second report quantity, the SysRevIDs follow along and are different. The second call got the new version of the JobOper row for the BeforeImage:
For anyone curious, this is open in EpicCare as case CS0005391642.
Support was able to reproduce (yay!) the issue in 2025.2.14, but it looks like a “fix” was put in place in 2026.1. Now the system will throw a “There was an internal error…” error message to the user. Plus side: data stays consistent. Down side: that error message has no information for the user on the floor to work with.
I’m pushing for development to either change the behavior to add some actionable information to that message (not holding my breath there based on previous posts about error messages) or to have the system update JobOper in a way that should handle multiple users updating related tables. I wonder if this has to do with other areas in the system that end up out of sync…“Refresh PartBin” anyone?
In the meantime I’ll be working on a BPM to let users know to wait a few seconds and try to submit their quantity reporting again. Once that’s working, I’ll flag a solution here.
Problem PRB0315089 has been opened with development.
A BPM to verify the SysRevID in this situation is very tricky to get right. Pre-Method directives on ReportQuantity are too early, and In-Trans Data directives on JobOper changes are too late to capture the data accurately. We ended up just changing some of the critical reports that use JobOper.QtyComplete to manually add up LaborDtl.LaborQty for approved labor entries since that was easier to figure out.
Creating a function or other process for manually updating JobOper.QtyComplete on a schedule or after the fact had other problems: The JobEntry business object doesn’t let you just change values willy-nilly on an engineered job (based on company settings), but having the function un-engineer/re-release would slow things down while running this function. Using Db.SaveChanges() to force a field update works, but this also triggers Auto Receipt to Inventory that ends up duplicating the quantity received to stock from the job, since the original receipts to stock were correct.
Overall, just a very messy thing to try to get corrected during the transaction or after the fact. Hopefully the problem is accepted and this is cleaned up in the actual business objects.
