Count distinct physical coupon IDs with an accepted reviewed disposition. Retain their linked attempts.
The dashboard found more accepted coupons than we physically have
AnikaCarter1030 · 7 Oct 2025, 08:25 UTC
20 replies
Does the stored data distinguish coupon identity from attempt identity already?
10 pointsAlso 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 pointsWe 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 pointsSam, 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 pointsCan the operator see held coupons without them looking accepted?
17 pointsGive 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 pointsOur 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 pointsAmanda, how would you retain evidence of duplicate delivery without showing it as another inspection? Support will still want to know it happened.
6 pointsKeep 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 pointsAnd a later timestamp alone should not choose the accepted disposition.
5 pointsYes, 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 pointsHazel 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 pointsTry rebuilding the total from the stored records before changing the live display.
3 pointsSam, 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 pointsAnd have the inspector compare the resulting item list, not only the final number.
20 pointsA matching total can conceal two wrongly assigned coupons. The list comparison is worth the extra few minutes, particularly with those retries in it.
12 pointsThe 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 pointsMuch easier to explain two waiting than pretend two more passed.
-2 pointsAnika, 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 pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .