I need to correct our FR10 batch display. It adds passing inspection rows, including repeated results after reconnect. A plate can also fail and later pass a reviewed retry. Quality wants one current acceptance per plate, with the failed history still available. How should those records be separated?
Keep an item record with its current quality disposition and separate attempt records linked to it. Deduplicate repeated messages by attempt identity, then calculate the accepted-item total from current dispositions rather than summing every historical pass.
We have plate identities on the traveller. Application saves attempt results but does not preserve a separate disposition. A withdrawn acceptance still contributes to its count, which is another error in our total.
Agree the disposition rules with quality, including withdrawal and unresolved items, before revising the count. Reconcile the existing batch against their register; missing identities in older rows may need explicit review rather than automatic merging.
Could you manually work through a small group with a failed retry and a withdrawn pass before coding the whole change, so everyone agrees which number the screen should show?
We did that with quality and the developer. Repeated message adds nothing, reviewed retry changes that plate's disposition, withdrawal removes it from accepted. Failed attempts remain visible. Old ambiguous rows are held for review.
Use those examples as regression tests and include the exported report, not just the screen. The handover can otherwise fix one total while leaving the old interpretation in the file people send to planning.