Our UR5e coupon inspection dashboard says we're nearly finished, but several coupons had retries after restart and each successful attempt added another one. Same physical coupon, more than one tick.
I need the accepted-item count fixed without wiping out the failed attempts. The inspector keeps disposition records; the screen mostly shows a cheerful total. What would you make it count, and what would you still show the operator?
The dashboard found more accepted coupons than we physically have
AnikaCarter1030 · 2025年10月7日 08:25 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
20 条回复
Count distinct physical coupon IDs with an accepted reviewed disposition. Retain their linked attempts.
11分Does the stored data distinguish coupon identity from attempt identity already?
10分Also distinguish replayed messages from genuine repeat inspections. Both can inflate that total, but they need different treatment in the history: duplicate delivery is not another physical attempt.
8分We had a report that fixed the total by hiding every earlier failure. Inspection then lost the explanation for why an item had been held. Keep a readable route from the item to its attempts, including who reviewed the eventual disposition.
-8分Sam, yes, we have both IDs in storage. Amanda, the current replay also adds to the counter, so there are two mistakes. Sofia, failed attempts need to stay visible; that was exactly what the inspector was worried about.
22分Can the operator see held coupons without them looking accepted?
17分回复 JoBarnes0592
Give held and unresolved items their own visible state, with a route to the responsible reviewer. Do not rely on a smaller green total to explain where the missing pieces went.
20分回复 JoBarnes0592
Our sample list once used blank for both not inspected and awaiting review. Jo's question is worth keeping specific: what should the operator do with each group?
15分回复 AmandaBailey
Amanda, how would you retain evidence of duplicate delivery without showing it as another inspection? Support will still want to know it happened.
6分Keep delivery observations in an event log linked to the attempt. The operator's inspection history can show one attempt, while support can inspect its repeated deliveries. These are different views of the same retained evidence.
20分回复 AmandaBailey
And a later timestamp alone should not choose the accepted disposition.
5分Yes, especially after a restart. We had an older result delivered late and displayed as the latest inspection. Its arrival time was real; the story the screen told from it was wrong.
4分回复 AmandaBailey
Hazel and Nora, held coupons are physically separate and the inspector owns the review. The revised screen will distinguish not inspected, awaiting review and accepted. Thanks, Amanda, the event-log split lets us keep the duplicate evidence without inventing another attempt.
12分Try rebuilding the total from the stored records before changing the live display.
3分Sam, include an item still awaiting review in that rebuild. A test set containing only settled items can make the missing-state problem look solved before anyone has addressed it.
23分And have the inspector compare the resulting item list, not only the final number.
20分A matching total can conceal two wrongly assigned coupons. The list comparison is worth the extra few minutes, particularly with those retries in it.
12分The rebuilt list agrees with the inspector's settled dispositions. Two coupons remain awaiting review and are excluded from accepted. Failed attempts and repeated delivery observations remain available. Live display change is still being tested.
1分Much easier to explain two waiting than pretend two more passed.
-2分Anika, when the live test is done, try reopening the report as well as reconnecting the application. Our late-result problem showed up through a different report path from the one everyone had just repaired.
17分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .