Put both authors on the same call. You can't repair two incompatible meanings by adding a footnote for the operator
Our FR5 lathe drawing has two meanings for request received
NoahBrown0890 · 10 Apr 2026, 09:20 UTC
20 replies
Wonderful. A receipt issued before you've bought anything.
4 pointsIs the dispute only the word ready, or do the drawings actually change state at different times? Renaming it won't help if they disagree about when the job exists.
21 pointsWhat do the two drawings show when an offer arrives while the loading position is unavailable? That should expose whether one side expects the offer to remain present or expects the other side to send it again.
14 pointsSofia's distinction is useful. I'd bring one ordinary unavailable-position example to that call, not start by rewriting the entire interface document.
19 pointsSofia and Nathan, the timings differ too. The integrator keeps the offer pending; the machine drawing discards an offer made before availability and expects another one.
11 pointsThen who decided to retry it? Someone has made that part of the job, even if neither drawing admits it.
19 pointsI inherited a handover where the experienced operator supplied the missing retry by watching a lamp. The cover person didn't know the trick, naturally. We ended up documenting the actual sequence with both suppliers instead of teaching another person the trick.
5 pointsThat makes a good teaching example, Pavel. Draw the person in the flowchart if the flowchart secretly needs them
23 pointsAnd then ask whether that human task is wanted. Documenting a nuisance isn't the same as agreeing to keep it
18 pointsLewis, neither drawing names an owner for retry. We've booked the joint review around that unavailable-position example and asked them to agree the pending-job behaviour before we write the operator page.
16 pointsPlease include withdrawal of the pending job. Whoever covers the cell will eventually need to ask what is still outstanding after someone cancels an order.
15 pointsThey've agreed a pending offer with a separate receipt, plus explicit cancellation and its response. The machine supplier has removed the instruction to resend on availability; the integrator is updating the matching job references.
19 pointsDoes the receipt still get labelled ready on the screen?
7 pointsNo, received is now the proposed label. Position available is separate, and neither is being presented as a safety permission.
11 pointsIn the agreed tests, include an old receipt arriving after a later offer has been created. Matching the job reference should matter to the receiving logic, not only make the trace easier to read afterwards.
21 pointsThanks Nathan, that belongs beside cancellation in the test list. Otherwise the ordinary happy path can look right while the wrong job gets acknowledged.
9 pointsI'd like to see the covering person explain that cancelled-but-not-yet-confirmed state. That's the one I'd be tempted to read as finished.
25 pointsThe joint test session covered unavailable position, cancellation and an old mismatched receipt; both authors recorded the expected responses. Our cover operator also caught a misleading cancelled label before confirmation, which is now cancellation pending.
6 pointsThat's an operator review earning its place. Keep that wording in the handover too; no point fixing the screen and handing out the old explanation
19 pointsAdd to the discussion
Welcome to Application Robot
Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.