I looked at the nearly-done counter, then at the coupons waiting for inspection. They don't agree. Our UR5e fixture-inspection dashboard counts retries after a restart towards the planned 57 items, including checks that failed before a reviewed retry. I need the accepted-item total without scrubbing out how each item got there.
What identifies the coupon across the restart? Not its latest attempt, the actual coupon. I'd settle that before arguing about whether to count the first pass or the last one
Keep an attempt ledger and derive the item total from reviewed item status. Don't increment the accepted-item counter just because a completion arrives. You also need a defined response when the same completion is received again.
Priya, does reviewed item status mean the most recent attempt wins? I would be wary of a late older result changing a decision that has already been reviewed.
No, I mean an explicit disposition linked to the relevant evidence, not whichever result was last delivered. The review rule must decide which attempt supports acceptance. Arrival order is not that rule.
Coupons have identifiers on the inspection sheets that survive restart. The dashboard stores them too, but it adds one for every finished attempt. I exported the records without altering them, so we can reconcile by coupon instead of guessing from the headline.
Good. What happens where the sheet and dashboard disagree on the identifier? Not expecting you to have such a case, but the reconciliation should have somewhere to put it other than making up a match to get a tidy total.
The retained set has 52 attempts for 44 identified coupons. Quality has confirmed 41 accepted and three still held. That leaves 13 of the planned 57 without an attempt in this set. The old counter was showing 52 done, which was a very generous interpretation of done.
That makes the scale of the error clear. Are those three held coupons visibly separate from the 13 not attempted? Sorry, I mean on the replacement dashboard as well as in your reconciliation sheet.
Test the derived view against that exact retained set before importing any new work. Expected accepted total 41, with repeat attempts still searchable and no dependence on the order in which the records are loaded.
The replacement view shows all three categories and returns those counts from the retained set. Replaying the same attempt records didn't add accepted items. It did expose a second issue: our CSV export still used the old completed-attempt total.
Please fix the export before anyone uses it to promise the batch is ready. A correct screen won't rescue the spreadsheet someone already sent to planning
Export corrected, and I sent planning the reconciled position with the previous file marked superseded. The failed checks remain in the attempt history, including those belonging to coupons later accepted after review.
Yes. Loaded an older failed attempt after its reviewed successful retry and the item remained accepted with both attempts visible. Repeated acceptance events also leave the total unchanged. Thanks, Owen; planning had already started working from that export.
Keep the reconciliation set with the reporting tests. That gives the next maintainer a concrete contract for accepted items, held items and untouched work instead of another counter named done.