It is meant to show accepted coupons. Each has an item label. An unsuccessful check can be followed by a reviewed retry, but the current screen just adds another result

Link attempts to the coupon identity and count its current authorised disposition, not the number of result messages. Keep the failed attempts underneath that record. Repeated delivery of a result mustn't create another coupon.

Can you make a tiny offline example before changing the whole dashboard? A couple of labelled coupons, one retry and one repeated message should expose whether you're counting records or actual items.

Can quality withdraw an earlier acceptance? That affects what current means.

I need to ask them. We discussed a successful retry, but not a later changed decision

Noah's question matters to the display too. A current accepted total may legitimately fall after a reviewed change. The operator needs to understand why, rather than assume another restart has broken the count.

I've built a small offline example with two identified coupons. One is accepted first time. The other fails, then is accepted after review. Sending that second result twice currently shows three accepted

Expected item total is two for that example. Preserve the failed attempt and the reviewed acceptance, but repeating the same result doesn't add another accepted item.

Now rebuild the screen from the stored records and repeat it after a restart, Beth. Fixing the live increment while the reload path still counts rows would leave you with two different totals.

And check an unreviewed retry. A new attempt doesn't itself authorise acceptance.

Quality confirms an acceptance can be withdrawn by an authorised review. We need the current decision plus its history. The earlier acceptance must remain visible as history, not keep the coupon in the current total

How will the person reading the batch screen reach that explanation? I'd keep the item identity and review trail accessible from the changed total, not make them hunt through raw attempts to guess what happened.

Yes. Keep the later decision as a later decision; don't rewrite the first attempt to make the history agree with today's status. Those records answer different questions.

Who checks the example's expected decisions before it becomes the regression test?

I'd have quality review the small example with the developer, then replay copies of suitable records read-only. No need to alter the production batch just to discover the new query counts retries again.

The reviewed example now stays at two after the duplicate and after restart. A later withdrawal takes it to one, with the old acceptance retained in the history. Those are offline test results, not a correction to our production report

Thanks Harish for the small-example suggestion. Quality owns the report correction and is reviewing the new screen with us. I've stopped calling the old total nearly finished in the handover

Include a case with no accepted coupons in that screen review too. It should still distinguish waiting for review from failed inspection, even though neither contributes to the accepted total.