结论先行
制造现场最怕的一种错误，是把“质检”理解成工单结束前的一个附带弹窗。企业版实际上把它做成了一条跨模块流水线：工单推进决定什么时候触发检查，质量模块定义检查点与通过/失败逻辑，IoT 模块负责把现场设备的读数或图片带回来，最后再由 work order display 决定是否允许继续过站。
第一层：入口或表面动作
quality_mrp_workorder_worksheet.models.quality 里的 action_worksheet_check 很能说明问题。它不是简单打开一张质检表，而是先在必要时创建 quality.check.wizard，再调用父类流程；如果这个 check 绑定的是 workorder_id 且不是从 worksheet 回流，它会直接走 _next()。换句话说，worksheet 不是附件，而是工单推进器的一部分。质检动作做完没有、做完后能不能推进，都被绑定到工单状态机里。
第二层：真正的业务护栏
再看 IoT 接力。mrp_workorder_iot.models.quality._compute_boxes 会根据 workcenter.trigger_ids 把可用设备整理成 box/device/action 映射；action_print 则把 quality point 上挂的设备 id 带给后续动作。到了前端，quality_mrp_workorder_iot 补丁覆写 QualityCheck.clicked()：测量类检查会走 iot_http.action(..., {action: "read_once"}) 把设备数值回写到 record.update({measure: data.value})；图片类检查会触发相机采集，再把结果塞回当前质检记录。也就是说，前端按钮点下去后，并不是“直接通过”，而是先取现场证据，再更新 quality.check，再继续工单。
第三层：状态落点与边界
这条链里最重要的边界有两个。第一，工单只决定“下一步做什么”，并不自己解释设备返回值；解释权在 quality check 类型与规则。第二，IoT 只负责拿到事实数据，不负责决定工单放行。这样做的好处是，设备离线时你看到的是明确的失败提示，工单也不会假装已经完成质检。
为什么这套设计更稳
如果你在自定义里直接在 workorder 按钮里调设备接口，跳过 quality.check，短期看很省事，长期会马上失去审计链：谁测的、测了什么、图片/数值是否留痕、失败后是否阻断过站，都会变成散落在 JS 里的临时逻辑。企业版把它收进 quality 模型，就是为了让制造、质检、设备三方说的是同一份状态。
实战启示
调试建议也很明确：先看 quality point 是什么类型，再看 quality.check 是否带了正确的 iot_box_id/identifier，接着看前端 clicked() 是走了 super 还是 IoT 分支，最后再看工单有没有因为 _next() 被推进。把这些节点连起来，你看到的就不是“某个按钮坏了”，而是一条完整的制造现场接力链。
DISCUSSION
评论区