三条订单发出去，只落下两条
假设一批导入包含 O101、O102、O103 三张待创建的内部订单草稿。程序成功打开页面并上传了文件，目标系统接受 O101 和 O102，却因商品编号无效拒绝 O103。如果任务只按“上传动作没有报错”判断，界面就可能显示成功，但业务结果实际只完成了三分之二。
需要改变的是成功条件：三条来源记录都应有明确去向。接受两条、拒绝一条可以是一份准确的处理结果，却不能显示为“三条全部创建成功”。业务人员必须能找到失败的那一条及原因。
任务编号负责串起过程，业务编号负责找回记录
一次运行可以有批次编号 B0613-01，每条记录保留来源订单编号、目标草稿编号和本次操作。批次编号让人找到同一次运行的日志，订单编号帮助判断某一张单是否已经存在。只保存“第 3 行失败”不够，因为文件排序变化后，第 3 行可能已经是另一张单。
任务记录还应保留输入文件、启动时间、规则版本和操作结果。无需把所有客户资料复制进日志；保留足以定位和核对的信息即可，避免日志变成另一份无人管理的业务数据库。
用业务状态替代一个万能的绿色标记
| 状态 | 表示什么 | 操作员下一步 |
|---|---|---|
| 待校验 | 尚未核对必填字段与编号 | 查看缺失或冲突项 |
| 执行中 | 正在提交获准的创建操作 | 等待，避免另开一批重复提交 |
| 等待结果 | 目标已受理，最终状态尚未确认 | 查询结果或等待处理完成 |
| 全部完成 | 每条记录均取得并核对目标结果 | 查看结果清单 |
| 部分完成 | 部分成功，其他有明确失败原因 | 仅处理失败记录 |
| 结果未知 | 中断后无法确定目标是否已处理 | 先核查，暂不重复创建 |
API 的异步受理与处理完成也存在这种区别。状态命名应反映实际证据，而不是把“收到响应”直接翻译成“业务办完”。
重试要从失败处继续，不能让成功部分重做
在例子中，业务人员修正 O103 的商品编号后，重试范围应只有 O103。O101 和 O102 已经有目标草稿号，应继续保留成功记录。再次上传完整文件前，需要确认目标系统是否提供可靠的重复检测或明确的幂等约定，不能靠操作员记忆避免重复。
更棘手的是超时：提交 O103 后网络断开，目标系统可能已经创建，也可能尚未处理。应按来源业务编号查询，或进入人工核查。一个“重试”按钮必须说明重试哪些记录、可能发生什么；在结果未知时，不宜直接执行新的创建动作。
把核对做成输出的一部分
本批次的结果清单应明确列出：输入三条、创建成功两条、业务拒绝一条、结果未知零条，并逐条给出来源编号与目标编号。数量相加应等于输入数量，每条记录只能归入一个最终类别。对高影响的动作，还要核对金额、数量或状态等关键字段。
验收时故意测试“上传成功但一条被拒绝”“提交后断开”“重复执行同一批次”三种情况。用户看见的提示、实际目标结果和恢复操作一致，流程才具备日常可用性。