There is a job number beside it. Our monitor only remembers the last counted number in memory, so restarting the monitor loses that comparison.

Then a reconnect isn't the only trigger. A monitor restart can forget the same job without any PLC outage.

You're right. I called it a reconnect problem because that is how we found it. Restarting the application against the saved record produces the extra count too.

Keep the accepted completion in durable storage. Ask the developer how recording it and updating the count stay together if the application stops between them

We once stored the last number but not its production order. Number one returned after a reset and confused the next run. Find out when yours can repeat before treating it as a permanent identity.

You can replay that saved record twice without touching the cell, Ella, then stop the monitor between recording the result and updating its display (if your test setup exposes that point).

The developer has confirmed the job number restarts with the production order. We need both values. I had not included the order in my first example, so that was worth asking.

And a completion with a missing order stays doubtful. Don't borrow whichever order happens to be on screen.

Who reviews those doubtful records at handover? Someone needs to see them without opening a database

Quality will review a visible pending list. The offline replay now counts the repeated order-and-job pair once, including after a monitor restart. Missing-order handling is on that list; we still need the interrupted-write check.