Cannot call our FR10 coupon total accepted while every retry adds one

AishaAli0257 · 27 Dec 2025, 18:41 UTC

Closed
AI
AishaAli0257
Our FR10 report keeps a useful history of coupon checks, but its accepted total rises when a failed coupon is checked again after restart. Quality reviews the retry separately. I want the accepted count to follow the physical coupons and their current decisions, not the number of result rows, without losing the failed attempts.

11 replies

AL
AlexChan1081
Replying to AishaAli0257

Show one troublesome coupon with its source records first; I recently found extra rows that were duplicate imports rather than extra inspection attempts, so I wouldn't label every surplus row a retry yet.

8 points
AI
AishaAli0257
Replying to AlexChan1081

One coupon has a failed check, a genuine second check and the second result imported again after reconnect. Both imports currently add to the total. Same physical coupon throughout.

1 points
AL
AlexBrown0907
Replying to AishaAli0257

Separate the duplicate delivery from the second attempt. The second attempt belongs in the history even when it follows a failure. The duplicate delivery should not create another attempt, and neither event should decide acceptance without the quality disposition.

25 points
IS
IsabelAbbott0039
Replying to AishaAli0257

Also test a later change to quality's disposition, including withdrawal of acceptance; counting each identity once is insufficient if an earlier accepted state can never be removed from the current total.

-2 points
LU
LuisAli0260
Replying to AishaAli0257

Will the operator still be able to see why the coupon was retried, Aisha? A smaller total is welcome, but don't make them open three unrelated screens to find the failed check

9 points
AL
AlexChan1081
Replying to LuisAli0260

Luis, I'd want a linked history from the item, not three screens whose only connection is somebody remembering the coupon number.

-1 points
AI
AishaAli0257
Replying to IsabelAbbott0039

Luis, the proposed item view keeps both genuine attempts and the review together. Isabel, withdrawal of acceptance is in the test list. Developer is also using batch plus coupon identity because coupon numbers repeat between batches.

16 points
AL
AlexBrown0907
Replying to AishaAli0257

That repeated-number case is worth a test of its own. Make two batches contain the same coupon number and different dispositions. Otherwise a fix can stop duplicate counting inside one batch by incorrectly joining two separate physical items.

2 points
LU
LuisAli0260
Replying to AlexBrown0907

And show the batch on the item page, not just in the developer's key; the person looking at a failed coupon needs to know which one they're reading about

16 points
AI
AishaAli0257
Replying to LuisAli0260

Replaying our retained example now gives two attempts and one accepted coupon. Duplicate import stays traceable without becoming a third attempt. Batch is visible on the item page. Acceptance-withdrawal testing hasn't finished.

15 points
IS
IsabelAbbott0039
Replying to AishaAli0257

Keep that last test outstanding in the handover, with the successful replay described as the specific case completed rather than approval of every disposition change.

13 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .