为什么易飞用户需要扫码报工
易飞 ERP 的工单、工艺路线（工单工艺）和移转、入库单据本身很完整，问题出在数据进 ERP 的那一段：大多数工厂仍然是流转卡跟着产品走，工人手写数量，文员每天或每周集中补录。结果是：
- ERP 里的在制数量、完工数量滞后几天，生管排产只能靠打电话问现场；
- 补录时数量对不上，超转、漏转要到月底盘点才发现；
- 谁在什么时候做了多少，事后无从追溯。
扫码报工要解决的就是：现场发生的那一刻，单据就进入易飞，并且和人工在易飞里录单走同一套校验。
三种实现方式对比
| 方式 | 做法 | 优点 | 风险 / 限制 |
|---|---|---|---|
| 原厂方案 | 向鼎捷或当地代理商采购官方条码 / 移动模块 | 原厂支持，版本兼容有保障 | 费用与实施周期需评估；现场界面与流程按标准产品，个性化有限 |
| 直写数据库 | 第三方程序直接往易飞业务表插入单头、单身 | 开发快、看起来灵活 | 绕过取号、单别、权限、超量和审核逻辑，易漏关联表与库存流水，升级后易出错 |
| 调用原程序的中间平台 | 平台只读查询易飞，写入调用易飞原保存、审核程序 | 数据一致性与人工录单相同；现场界面可按工厂定制 | 需要按单据逐项适配和验收；吞吐受 ERP 原程序串行处理限制 |
维钉云 MES 扫码报工采用第三种方式。直写数据库的具体风险可以看另一篇：易飞 ERP 接口开发：为什么不建议直接写数据库？
标准扫码报工流程
- 打印二维码：按工单或每道工艺打印标签，内容例如
01|20260923001|0020|02（单别 | 单号 | 工序 | 加工地点）。 - 扫码定位：APP 或 PDA 扫码，平台按账套配置的条码格式解析，定位到工单和工序。
- 回 ERP 查询：实时读取工单状态、品号规格、当前与移入工序、在制数量、单别规则和授权仓库。
- 录入现场数量：只填现场真实发生的验收、验退、报废、破坏数量。
- 提交写入：平台按幂等编号持久受理，调用易飞原程序取号、保存，按配置直接审核或待审核。
- 回读核对：回读 ERP 单号与数量；回执不确定时进入「待核对」，人工依据 ERP 实际结果结案。
上线前必须确认的 9 件事
| 确认项 | 为什么重要 |
|---|---|
| 易飞版本与原程序组件 | 写入依赖易飞原保存与审核组件，版本不同组件行为可能不同 |
| 移转单别、入库单别规则 | 单别决定编号、审核方式和控制参数，不能写死某个单别 |
| 工单工艺是否完整维护 | 没有工单工艺记录的工单无法按工序扫码报工 |
| 哪些工单状态可以报工 | 通常只允许已审核、已发料或生产中的工单；未发料工单原程序会拒绝 |
| 二维码内容与分隔符 | 要和平台条码规则一致；二维码只定位，不放数量 |
| 现场设备 | 普通手机即可；红外 PDA 需支持键盘仿真输入，只发厂商广播的需按型号适配 |
| 操作员与 ERP 用户映射 | 谁在现场提交、以哪个 ERP 身份执行，必须一一对应并留痕 |
| 特殊场景 | 批号、库位、序列号、双单位、返工、委外、多行等需用真实样本逐项验证 |
| 吞吐与网络 | 原程序逐笔串行处理，适合逐单报工；高速批量采集要单独设计 |
最常见的 5 个坑
- 把数量写进二维码：二维码打印后数量就变了，入账一定要以 ERP 实时数据为准。
- 把在制数当可提交量：列表上的在制数只是参考，最终能否提交以原程序检查为准。
- 没有幂等：车间网络不稳，重发一次就多一张单。每次提交必须带唯一编号。
- 一失败就重提：网络超时不代表 ERP 没执行，应先核对再处理。
- 所有场景一次上线：先上最普通的自制单行场景，跑顺后再逐项开放复杂场景。
常见问题
易飞 ERP 扫码报工需要买专用 PDA 吗？
不一定。普通 Android 手机装 APP 或打开 H5 即可；车间连续扫码多的工位可配红外 PDA（需支持扫码键盘输入）。
扫码报工会不会影响易飞 ERP 的性能？
查询为参数化只读，写入逐笔串行调用原程序，与人工录单的负载相当。上线前建议用测试账套评估高峰时段的提交量。
多久能上线？
环境检查、安装和普通场景联调通常可以较快完成；复杂场景（批号、委外、返工等）取决于样本准备和逐项验收进度。