I compared the PLC author's note with the inspection application's note. Both claim to clear the acknowledgement, and neither says how long the coupon request remains available. A missed request then looks like a rejected coupon on our screen. We are reviewing this ordinary job interface separately from the safety system.
Oliver, 'coupon rejected'. There is no inspection result behind that message. Hana, the application author says acknowledgement means request received; the PLC note calls it inspection accepted. That explains some of the disagreement.
Receipt only is agreed. Completion and its result are separate. The draft keeps the request identifiable until receipt and names which side writes and clears each part of the exchange.
Hana, late receipt is still an open design case. Oliver, the proposed screen says receipt uncertain and calls for the named support contact, without offering a blind repeat. We need to test that wording with our operator.
It is required. The authors have now defined the late-receipt handling against the original attempt identity and added a controlled delayed-reply test. I was too quick to describe the normal exchange as the main thing.
Delayed and duplicate receipt tests passed in the offline interface check. The operator correctly distinguished uncertain receipt from an actual rejected coupon in the walkthrough. Installed integration checks remain, but the contradictory note and misleading screen label are corrected.