客户是一家区域食品加工企业，过去也有进销存，但批次追溯主要靠纸质记录。一旦客户投诉某批产品，质检、仓库和生产要翻好几本台账，才能定位原料和出货去向。
半天翻台账，暴露的是批次关系断了
食品追溯不只是把更多数据录进 ERP。原料批次、生产批次、半成品批次、成品批次和出货批次之间没有稳定关系，扫码再多也只能记录动作，无法支撑召回。
项目第一阶段因此只处理追溯闭环：原料入库生成批次，生产投料关联原料批次，成品入库生成生产批次，出库记录客户和渠道，质检报告挂到对应批次。
客户一开始也想把采购、库存、生产、质检、销售和成本核算一次做完。评估后先收窄到批次追溯，因为监管、客户投诉和召回演练是更硬的业务底线；这条链没有跑通，库存与成本报表也缺少可靠基础。
先把追溯必须字段录准
第一阶段保留的字段包括原料批次、供应商、入库日期、质检结果、生产批次、投料关系、成品批次、出库客户和出库日期。采购、库存、生产、质检、销售和成本核算没有一次全部铺开，避免完整 ERP 的范围压垮追溯主线。
批次规则先于设备。原料入库必须记录供应商、到货日期、检验状态和批次；生产投料关联工单和原料批次；成品入库关联生产批次；出货关联客户和成品批次。这样某个原料批次出问题时，系统才能反查受影响成品和客户。
实施时按四个关键节点核对批次关系：
| 节点 | 必须建立的关系 | 一线动作 |
|---|---|---|
| 原料入库 | 供应商、到货日期、检验状态与原料批次关联 | 仓库扫码入库 |
| 生产投料 | 工单与所用原料批次关联 | 生产确认投料 |
| 成品入库 | 成品与对应生产批次关联 | 仓库扫码入库 |
| 出货 | 客户、渠道与成品批次关联 | 仓库扫码出库 |
任一节点只记录动作却没有建立上下游批次关系，都不能算追溯完成。
一线每个岗位只多做一步
团队最担心的是一线员工不会用。实际设计中把扫码和下拉选择减到最少：质检上传报告、仓库扫码出入库、生产确认投料，其他字段由系统带出。
扫码也没有一次覆盖所有节点，而是先用于原料入库、投料、成品入库和出货；其他环节保留人工确认，等流程稳定后再增加设备和标签。每个关键岗位只处理自己那一步，比要求所有人维护一套复杂表单更容易执行。
验收不看页面，直接做正反向召回
项目验收做两类演练：从成品批次往前追原料和质检，从原料批次往后追受影响成品和客户。两边都能在规定时间内出清单，追溯链才算成立。
上线后的一次模拟召回中，从成品批次反查原料批次、质检记录和出货客户，原来要半天，现在 15 分钟内能拿到清单。验收以这条追溯链是否完整为准，不用其他展示指标替代。
追溯系统上线后还要查什么
定期抽查漏扫、手工补录、批次混用和异常未审批，比继续增加展示报表更重要。随机选一个原料批次，应该能查出供应商、检验记录、使用工单、成品批次、库存剩余、已发客户和责任人。
批次追溯的价值不在于平时多一张报表，而在出问题时快速、准确、可审计地缩小影响范围。采购、库存和成本核算可以后续接入，但不能破坏已经跑通的批次关系。
