生产计划临时变了。

原本要送到三号线的一箱料，突然不用了。

计划员在系统里点了取消。

很干脆。

问题是，AGV五分钟前已经把货取走，现在正在去三号线的路上。

这时候如果系统也很干脆，直接把任务状态改成“已取消”，麻烦才刚开始。

系统觉得事情结束了。

车上那箱货没有。

自动物流里，撤单最容易被忽略的一点就是：软件任务可以瞬间消失，实物不会。

所以取消任务之前，先要知道任务走到哪一步。

如果还没分配车辆，取消通常比较简单；车已经接单但没取货，可以停止后续执行；一旦货已经被取走，就不能只处理“任务”，还要处理“这箱货接下来去哪”。

现场通常需要提前定义几种去向。

一种是继续送原目标，交给现场再处理；一种是转到指定退料区或缓存区；还有一种是在业务允许、系统支持的情况下，改派新的目标位置。

具体用哪一种，没有行业统一答案，但一定要把规则写清。

不然最容易出现三套口径：

生产：我已经取消了。

仓库：货早就发出去了。

系统：任务不存在。

最后大家只能问机器人。

机器人：我只负责搬，你们先把家庭关系理顺。

这里还涉及一个很实际的问题——谁有权限取消。

如果任何人都能在任务执行中随手撤单，自动物流会变得特别像外卖骑手刚到楼下，顾客突然改地址。

所以建议把撤单按状态分权限：没取货前可以直接取消；取货后需要确认实物去向；涉及关键物料或自动交接时，最好留下操作记录。

还有异常恢复。

如果任务取消时网络刚好中断，车辆端和调度端状态不一致，恢复以后要避免旧任务又继续执行，或者同一箱货生成第二个回收任务。

这类问题平时不显眼。

直到第一次真有人“不要了”。

到那天再围着一箱货开会，多少有点晚。

这件事还要和库存账对上。

货已经从仓库库位取走，系统如果因为订单取消直接把库存“退回原位”，而实物还在机器人上，账和货就会出现短暂分家。后面再有人按系统位置去找货，就会发现数据库很自信，货架很空。

所以执行中的撤单最好同时考虑物流状态和库存状态：货还没取，可以直接释放原库位；货已经取走，要等退回、转存或重新交接完成后，再把库存位置改成真实所在。

项目验收时，这种“反悔场景”也值得故意测一次。正常任务大家都会演，临时取消更接近日常生产。

尤其是多品种、小批量、计划变动比较快的现场，撤单不是边角功能。它只是平时不说话，真用到的时候特别希望它别临场发挥。