生产报工看起来像一件简单的自动化：托盘经过读头，Odoo 更新工单。它并不简单，因为工单记录的不只是数量，还有时间；而一次读取对「工序何时开始」「谁做的」一无所知。
工单是关于时间的声明，不只是数量
账务与分析都依赖时间维度。
- 开始与结束时间决定产能、交付周期与每小时成本。
- 只有数量没有时长，既算不了 OEE，也做不了返工分析。
- 线尾的一次读取只说明产出，说明不了中间那二十分钟的等待。
- 「工序完成」与「良品数量」是两个独立事件。
- 先把事件模型设计好，再去选读取点。
一次读取能诚实地声明什么
对每次读取所能支撑的结论要严格。
- 某个特定周转箱或托盘在某个时刻出现在某个位置。
- 经过某个卡点；只要覆盖完整，这是一个强命题。
- 批次或序列号的身份；前提是标签绑定正确且经过验证。
- 除非作业者随身带标签、且流程把动作归属到人，否则它对「谁」一无所知。
- 除非检验工序自己写入事件，否则它对质量一无所知。
生产路线上的读取点
每个读取点只应服务于一个决策。
- 进入工作中心：工序开始，在制品已到位。
- 离开工作中心：工序完成，可以记数量。
- 缓冲与排队位：知道物料在等，才能解释延迟。
- 返工回路入口：东西回来了，所以这批不算良品产出。
- 报废箱：这是一次主动处置事件，而不是出口处丢了读取。
开始、暂停、完成：把状态建模
状态机能挡掉大多数报工争议。
- 排队、进行中、暂停、阻塞、完成——五个状态覆盖多数车间。
- 暂停必须有原因码，否则停机分析只是装饰。
- 阻塞意味着等料或等质量判定，其成本与空转不同。
- 状态迁移必须带责任人与时间戳，并且允许迟到到达。
- 对不可能的状态迁移要大声拒绝，而不是悄悄修补。
数量、报废与返工回路
数量需要来源，也需要时刻。
- 良品数量在完成时记账，使用该工序的计量单位。
- 报废在发现点记账，带原因与工作中心。
- 返工是一道工序，不是一次更正；按工序建模，否则工艺路线会说谎。
- 部分完成是常态；允许它，并让剩余数量保持可见。
- 组件消耗与产出的对账要分开做，因为两者的失败方式不同。
作业者身份与工时拆分
在多班次的工厂里，「谁做的」是个真问题。
- 在工作中心刷工牌可以开启一个会话，但它不能证明人一直在。
- 事务要归属到确认的那一刻，而不是登录的那一刻。
- 共享工作中心需要工时拆分，一次读取变不出来。
- 间接工时通常在自动报工里缺失，而那往往才是有意思的部分。
- 手动确认必须足够方便，否则作业者会在班末一次性补完所有确认。
倒冲与时间陷阱
倒冲很方便，但在边界上会悄悄出错。
- 倒冲在记产出时消耗组件，稳态下没问题。
- 长工序上，倒冲把消耗在时间轴上挪了位，扭曲在制品。
- 工序中间的组件报废，除非作业者主动上报，否则是看不见的。
- 倒冲容差会把系统性超耗藏起来，直到盘点把它挖出来。
- 高价值或受监管组件要显式报消耗，哪怕多花点人工。
产线停摆时的异常处理
自动化必须能扛过「什么都出问题」的那个班次。
- 缺失的读取必须产生一个待答问题，而不是悄悄记零。
- 明确谁可以手动确认，并要求填写原因。
- 缓冲事件必须能按顺序重放，并保留原始时间戳。
- 读头坏掉时产线仍要能纸面报工，事后再对账。
- 统计手动确认的使用频率，它是这套自动化的健康指标。
同步模型：事件，而不是计数器
Odoo 的工单有状态，集成就应该用「迁移」来说话。
- 发送带标识的工序事件，让 Odoo 拥有最终数量。
- 绝不要直接累加进度百分比；让它从已记账数量推导出来。
- 入库接口必须幂等，因为车间网络会重试。
- 保留原始事件日志，有争议的数量才能被重建。
- 每天对账：收到多少事件、记了多少数量、差异怎么解释。
序列号与谱系
线尾贴出的序列号，是对组件的一份承诺。
- 一次序列号读取会产生一条谱系声明，而这条声明在召回时必须站得住。
- 组件批次必须在装配当时就绑定到序列号，绝不能事后重建。
- 序列号在多个产品间重复使用，会毁掉召回分析与任何保修立场。
- 谱系的质量取决于上游组件报工；如果上游是粗略倒冲，召回清单就是废纸。
- 打印并贴序列号标签本身就是一道工序，标签错误是谱系失败的主要原因之一。
指标与试点
要证明报工「更好」，而不只是「更自动」。
- 测报工延迟、手动确认率，以及有多少工序拥有真实的开始时间。
- 对比前后 OEE，并判断变化来自测量方式还是来自现实。
- 在一个工艺路线稳定、班组长愿意配合的工作中心做试点。
- 首月盯住异常率，它预示团队会不会继续用下去。
- 事先定好「多高的人工回退比例可以接受」。
