Our monitor counts a completion again when it reconnects, although the PLC state was already high before the outage. This is sample-bracket acceptance reporting during commissioning. How do I connect the retained result to its job without clearing the evidence or automatically requesting more work?
Look for the job and attempt identity in the retained result. A high completion bit does not establish a new job, and completion does not necessarily mean an accepted bracket.
The retained record has an attempt identifier and result, linked to the bracket. Our report ignores the identifier on reconnect and increments its total from the initial high. Quality's reviewed dispositions are stored separately.
I'd derive the accepted total from those bracket dispositions, then keep attempts underneath for explanation. Otherwise fixing reconnect still leaves a rejected inspection looking productive because it completed normally.
Can the same retained result be replayed through the reporter without another inspection? That should expose the duplicate and preserve a repeatable example for the developer
Check the identifier lifetime too. A unique number within one session can become the wrong match after a restart. The test must use the identity the real interface provides.
The producer includes its retained session identity with the attempt counter. The developer found our wrapper dropping the session field. We are retaining the complete identity and deriving accepted brackets from reviewed dispositions, with the original results preserved.
If an old result has only the counter because the wrapper already discarded the session, leave that ambiguity visible. The new representation cannot recover information that was never saved.
Nina, that matters for the handover. I'd show a real ambiguous row and who reconciles it, not only a screenshot of the repaired happy path. People need to know when the monitor cannot decide.
Quality reconciled the one affected historical bracket using its retained inspection record and marked the report correction. The software did not infer the missing session. Future results now keep both identity fields.
Have you checked a result completed during the outage and first observed after reconnect? It should not be discarded merely because the initial high is no longer counted automatically
Those replay cases pass: already recorded results remain single entries, newly recovered results are added once, and repeats do not alter the item disposition. Unknown identity is held for review rather than assigned to the active bracket.
Does reopening the reporting application preserve those results and unresolved entries? The reconnect case alone would not show whether the new bookkeeping survives its own restart.
Reopen tests preserve both, and the maintainer verified the complete identity reaches the reporter through its normal read-only launch. We closed the duplicate-report defect. The acceptance total now follows quality dispositions, not the number of times a completion was observed.