MOM项目实施工厂把普通亮灯料架换成了感应式亮灯料架。这套系统上线后，操作员的扫码次数从每盘一次降到每张单据一次，回调异常的处理方式也全部重做了一遍。
这次改造的技术细节不复杂，复杂的是怎么让一条新流程在现场跑得住。本文记录业务流程怎么重新设计、前后端怎么分工、现场异常怎么分诊、以及管理规范怎么定。
01 业务流程：一条新流程怎么立起来
先说清楚新旧流程到底差在哪。这决定了后面所有设计的出发点。
普通料架的流程是"人驱动"的：操作员扫库位码，系统亮灯；操作员扫物料条码，系统入库并灭灯。灯的亮灭完全跟着系统的操作序列走。
感应式料架的流程是"物驱动"的：系统亮灯，操作员放料，探头探测到，回调来了才灭灯。
亮灯还是系统决定，灭灯变成现场物理动作决定。两者解耦，这是所有变化的源头。
操作员每盘只扫条码，库位码每张单据只扫一次
一个物理料架对应系统里的一个库区。系统在料架内找空闲库位，就是在库区内找。这个对应关系是整套自动找库位逻辑的基础。
新流程里有三个东西是旧流程没有的。
✓ 灯色分配。一张单据占一个颜色，从扫载具码那一刻开始，到过账才释放。操作员一眼就能确认自己操作的是哪个料架。
✓ 自动找库位。灭灯之后系统在当前料架内找下一个空闲库位并点亮，操作员不用翻找库位编码。
✓ 全生命周期留痕。每次亮灯到灭灯都写一条历史，灭灯方式、回调是否异常都记下来。
"灯色占用到过账才释放"这个规则值得单拎出来说。
颜色是工厂内共享的有限资源。如果中途释放，同一个料架可能同时被两张单据占用，灯光颜色一乱，现场就分不清哪个料架是自己的。
所以中途手动灭灯只灭物理灯，不释放颜色。颜色跟着单据走到底。
02 前后端分工：页面该管什么，不该管什么
App 端和后端的职责划分必须明确，后面处理异常的机制才会清晰。
页面只管显示与提示，是否落库由后端校验决定
App 端负责三件事
✓ 采集：扫码枪或手输，拿到库位码和物料条码
✓ 呈现：把后端返回的灯色、库位、提示原样显示出来
✓ 引导：光标该在哪一行、什么时候该提示，全部由页面控制
后端负责四件事
✓ 校验：这个库位能不能用、这次扫描合不合法
✓ 落库：库存、扫描记录、任务明细
✓ 设备：下发亮灯灭灯指令，找下一个空闲库位
✓ 兜底：页面传错了参数时，后端自己判断该怎么办
凡是"数据对不对"的判断，一律放后端。页面的校验是为了体验好，不是为了正确性。
这条线在回调超时的处理上体现得最明显。
感应装置探测到物料，通知 MES，MES 转发给 WMS，WMS 灭灯并找下一个库位。App 端全程收不到这个通知，只能每 2 秒轮询一次 WMS 查询状态，最多轮询 30 次。
轮询超时的处理，前端和后端各做了一遍，判据是同一个：
回调超时的前后端分工
App 端
再次扫码时发现库位是空的，先查一次状态。查到了就回显库位继续入库，没查到就提示"料架系统回调异常，请稍后操作"，不允许入库
后端
入库时如果库位参数为空，从亮灯记录推断。推断不出来同样抛"料架系统回调异常，请稍后操作"
后端这道是数据正确性的兜底。页面可能被绕过，接口可能被直接调用，但库位必须落在正确的位置。
前端那道是体验。操作员不需要知道后端有兜底，他只需要看到一句能指导下一步的提示。
页面上清空的库位，和后端记录的库位，是两处独立存储。前端清空了自己的变量，后端的记录纹丝不动。这次踩的坑基本都从这个事实长出来。
举个具体的例子。条码入库成功后，页面会清空库位输入框，把光标留在条码行。回调返回下一个库位时，页面回填库位、清空条码，光标再回到条码行。
条码保留到回调返回，是刻意设计的。操作员扫完条码，页面立刻清空，他会以为没扫成功，再扫一次。条码留着，他能看出这一盘已经扫了但还没完成。
保留期间重复扫同一条码，系统会拦住并提示"当前标签已扫描，无需再次扫描"。
03 现场异常：四类情况，四种处理
感应料架在现场会遇到的问题比普通料架多。探头会不动作，物料会放错位，人会忘记扫码。这四类问题有明确的分诊方式。
前三类操作员自己能处理，第四类要靠管理规范兜住
异常一：回调超时
现象是灯一直亮着，页面库位是空的，条码还留着。提示"未收到料架侧反馈，请确认物料是否已放入"。
✓ 第一步：看亮灯的库位，物料到底放了没有。没放就放进去，探头一动作回调就来了
✓ 第二步：确认后直接扫下一盘的条码。库位是空的，系统会先查一次状态
✓ 第三步：看结果。回调恢复了会自动回显库位直接继续；没恢复就提示稍后操作，等一会儿再扫一次
有一件事不能做：回调没恢复的时候，不要往当前亮灯的库位里塞料。那个库位已经放过一盘了，灯没灭说明系统认为它还在用，硬放会造成账实不符。要么等灯切走，要么用手动灭灯把记录清掉再重新扫。
异常二：扫错库位
扫了不是当前亮灯的库位，系统会拦下来，而且灯不会亮。提示分两种，让操作员知道该做什么：
记录里的库位已经放过料，灯还没切
提示 操作失败，该库位已放入物料但指示灯未切换，请等待指示灯切换后再扫描其他库位
操作员该做 等灯切换，看哪个库位亮了扫哪个
记录里的库位库存是空的，灯已经切到新库位
提示 操作失败，当前亮灯库位为 XXX，请扫描该库位
操作员该做 按提示扫那个库位
提示要说原因，不是重复位置。
异常三：未扫码就放了料
探头探测到物料放入并回调了，但系统发现这个库位这个单据下没有待入库的条码任务，判定为未扫码放料。
处理是：灯不灭，历史表记为异常回调并写明原因，App 端提示"当前库位没有扫描入库条码，不允许放入实物，请扫码后再放入"。
灯不灭这个选择值得说一下。如果这时候把灯灭了，系统就认为这个库位已经用完，实际上里面还放着一盘没登记的料，账实立刻对不上。
正确做法是把实物取下来，扫完条码再放回去。
异常四：料架已满
当前料架的库区里已经没有空闲库位了。系统弹出模态框"操作成功，当前料架已满，请扫描下一个空闲料架！"，操作员点确定。
这里有两个决定：提示用模态框不用自动消失的轻提示，点击遮罩不关闭，不给取消按钮；返回结果是成功不是失败。
料架满是正常的作业结果，不是异常。入库已经成功了，物料已经在库里了。这时候提示"失败"会让操作员以为要重扫，重扫就会重复入库。
还要等人工确认才清掉满标识。原来是查询到标识就立即清零，如果操作员在提示框出现前退出页面，标识已经丢了，重新进页面不再提示，他根本不知道上一个料架满了。
换架之后颜色不变，操作员换用同一个灯色继续干。
异常时灯的状态必须和实物状态一致。灯亮着说明系统认为这个库位还在用，灯灭了说明可以放了。不能让操作员靠猜，也不能让灯的状态和实际脱节。
04 管理规范：谁负责什么
感应料架的管理规范比普通料架多了一层。普通料架只有入库动作，感应料架多了灯、探头、回调、灯色占用这几样东西，每一样都会产生需要有人负责的残留状态。
需要管理员介入的只有两件事：灯色配了没有，记录卡住了没有
操作员：只做他判断得了的事
操作员的职责边界定得很窄：扫码、放料、按提示处理异常。他不需要理解灯色和库位的对应关系，也不需要判断这个库位对不对——系统会拦，提示会告诉他该做什么。
这个设计是有代价的：页面要承担更多判断逻辑，提示文案要写得更清楚。但收益是操作员培训成本低，异常处理不会因为人而异。
中途退出再回来，系统会复亮上次那个库位并回填库位码，光标直接定位到条码行，可以接着干。灯色不变，不用重新记。
库管员：查得清就查得清
每一次亮灯到灭灯都写进历史表。库管员在 Web 端按单据号、库位编码模糊查询，按回调处理状态筛出异常记录，列表按单据分组、组内按亮灯序号倒序。
历史表里记了什么：单据号、库位编码、亮灯序号、灯色、亮灯时间、灭灯时间、灭灯方式、回调是否异常、异常原因。
"灭灯方式"分三种：感应回调、手动灭灯、过账释放。这三个值能回答一个关键问题——这个库位的灯为什么灭了。
有了这张表，"这个灯到底是谁关的"变成一个可以查的事实，不用去问操作员或者翻监控。
管理员：两件必须定期做的事
第一件是维护灯色基础数据。灯色没配，操作员扫载具码就会看到"当前尚未维护亮灯颜色信息，请联系管理员维护基础数据！"。
这里有个约定：红色是现场保留色，永不分配给入库单据。红色留给料架异常提示用。
第二件是清理长期未过账的亮灯记录。因为颜色占用到过账才释放，某张单据要是卡住不过账，它占的颜色就一直占着。
等所有颜色都被占完，操作员扫载具码就会看到"操作失败，灯色均被占用，已无可用灯色"。
所以管理规范上应该有一条：亮灯中记录要定期查，有长期不动的就清掉。回滚的时候也有一条：回滚代码后，残留的"亮灯中"记录会持续占用颜色，要用现有的清理接口批量清一次。
历史表不在清理范围内。历史数据是追溯资产，删了就查不到了。回滚时保留表，不影响代码运行。
这两件事做不好，操作员那边的感受就是"系统说没颜色了"，但他不知道为什么。
05 可复用的做法
这次改造里有几条做法，换个场景还能用。
✓ 先画流程再写代码。把一次完整作业画成闭环，把循环和出口标清楚，代码只是这张图的翻译。画不清楚的流程，代码写出来也是乱的。
✓ 凡涉及现场动作的，都要设计异常分支。设备会不动作，人会忘记扫码，探头会误报。这些不是极端情况，是常态。
✓ 提示文案说原因和下一步，不重复位置。操作员扫的码就是系统记的库位，再说一遍位置只会让他困惑。
✓ 正常结果不要报成失败。料架满是正常作业的结束，提示成失败会诱发重扫，重扫就会重复入库。
✓ 凡是需要人判断的，就给判断依据。回调恢复了没有，用库位有没有库存就能推出来，不用再加一个标志位。
✓ 设计规范要考虑回滚。状态表和历史表分开，代码回滚时历史数据能留住，状态残留要有清理入口。
感应料架比普通料架多了一层设备逻辑，也就多了一层异常可能。但真正决定这套系统能不能用得住的，不是设备逻辑写得多精巧，是操作员遇到问题时，屏幕上那行字能不能告诉他该干什么。