订单处理流程图用于说明订单何时可以进入履约、每次交接由谁负责，以及订单无法继续时如何处理。它应当让异常先被团队发现，而不是等客户来问包裹在哪里。
真正有用的产出是有证据支持的放行决定：商品已分配、付款达到要求、地址与配送方式可用、必要审核完成。只画“付款→拣货→发货”，会隐藏这些工作。
先确定边界与状态
先限定一个具体场景，例如一个商城的国内现货订单。从订单记录创建开始，到各包裹达到团队规定的完成或客服交接条件结束。退货可以连接到独立子流程，避免主图过于拥挤。
分别记录订单、付款、库存和配送状态。订单可以已创建但待付款；付款可以已授权但尚未扣款；库存可以显示有货却尚未分配给这个客户；平台中的已履约包裹也可能仍在运输途中。这些组合不一定是错误。
在图旁写术语表。“允许仓库放行”是内部条件，不应代替平台本来的付款或履约状态。平台使用其他名称时，在操作说明中保留准确名称。
绘制订单处理主流程
1. 接收并校验订单。 记录订单号、商品、数量、地址、配送服务和联系方式。地址无效和缺货需要不同的异常出口。
2. 判断付款状态。 区分待处理、失败、已授权和已扣款。重试分支应有到期时间及客户通知。授权可能过期，不能当成已经收款。
3. 分配库存。 检查指定仓库的可销售数量及已有预留。两个客户可能同时看到最后一件商品，真正控制分配的是库存系统，流程图只描述规则。分配失败时，只提供商城实际支持的等待、替换、拆单或取消选项。
4. 检查放行条件。 确认付款、库存、地址、配送及必要审核均符合要求。结果不明确时交给有权限的负责人，不能只因其中一项通过就发给仓库。
5. 创建拣货与打包任务。 交接订单号、包裹号、数量、库位和包装说明。发现差异时返回库存检查或异常负责人，不能由拣货人员临时替换商品。
6. 确认发运交接。 记录承运商、服务、包裹内容和物流号。创建面单不等于交给承运商，已履约也不应直接改称已送达。
7. 跟进配送异常。 物流扫描延迟不能直接证明丢件。缺少轨迹、投递失败、退回发件人应进入相应客服规则，由负责人确认依据并告知下一步。
8. 关闭相应工作。 仓库任务、包裹和主订单可以在不同时间关闭。正常履约结束后，仍应保留退货或争议处理入口。
完整示例：一个订单拆成两个包裹
假设客户购买一盏台灯和两本笔记本。台灯分配在 A 仓，笔记本在 B 仓；客户选择的服务允许拆单，商城要求实际扣款后才放行。
支付服务最初返回待处理。订单存在，但两个仓库都没有收到放行任务。客服负责待付款队列，库存预留按商城规定到期。若始终未达到付款条件，到期分支释放库存并通知客户。
付款转为已扣款后，系统再次确认两个仓库的分配仍有效，分别创建 A、B 两个履约任务。它们共享主订单号，但各有数量和物流号，不能让第一个包裹代表整个订单完成。
B 仓发现一本已分配笔记本损坏，暂停这个任务并进入差异分支。有权限的负责人核对替代库存和客户选项；拣货人员不自行退款、换货或标记整单发出。
台灯此时已经交给承运商，可以按平台规则推进自己的履约状态，而笔记本问题仍保持开放。客户通知应准确说明分开发货，不能用一条“订单已全部完成”掩盖未完成部分。
检验图是否有效，要看每件商品是否有明确状态和负责人。团队应能直接回答：哪一部分被阻塞、原因是什么、谁有权继续处理。
给异常分支设置终点
| 触发条件 | 处理路径 | 离开该路径所需依据 |
|---|---|---|
| 待付款 | 按付款规则等待或联系客户 | 达到规定状态，或记录已到期 |
| 库存分配失败 | 可用性审核 | 有效分配或客户同意的方案 |
| 打包差异 | 仓库异常负责人 | 商品数量正确，或替代方案获批 |
| 请求取消 | 检查当前发货阶段 | 是否还能拦截，以及谁批准结果 |
| 物流异常 | 配送客服 | 承运商依据和下一次客户更新时间 |
“再试一次”必须有停止条件。付款可能按重试上限或预留到期停止，缺货可能按客户接受的等待期限停止。请使用实际规则，不要直接套用示例中的小时数。
取消和退款也是两个动作。取消未发出的任务不一定自动退回已扣款项，退款也不能证明运输中的包裹已被拦截。应分别检查，并在对应系统留下记录。
用图形和泳道说明责任
矩形表示动作，菱形表示有明确出口的问题。“检查付款”是动作，“付款达到放行条件了吗”才是判断。箭头标清条件，不让新人猜哪条线代表通过。
涉及多个团队时，可按客服、商城或库存系统、仓库、配送客服分泳道。每次跨泳道交接都写清任务和记录。“通知仓库”不如“发送含订单号与分配结果的包裹任务”明确。
不必把每个字段都画成节点。主路径保留关键决策，输入字段放在旁边的清单。复杂退货流程连接独立图，避免塞进一个配送判断框。
用六个场景验收
依次走查正常单包裹、待付款、最后一件库存争抢、打包差异、拆单发货、面单创建后取消。使用虚构订单号，避免把客户信息放到公开图中。
让每次交接的接收方复述下一步。若两人对“完成”理解不同，应修改术语和放行条件，而不是只整理版式。
还要对照实际平台配置。流程图不会实现库存锁定、付款重试、自动退款或通知。手动动作标明手动；系统动作写清由哪个系统在什么条件下执行。
创建并维护自己的版本
打开流程图模板，先替换为实际放行条件和异常负责人，再调整颜色。图形含义可参考流程图符号指南。
CodePic 用于记录流程，不负责执行订单系统操作。可以导出 PNG 放入手册，保留可编辑 JSON，或通过只读分享链接请同事检查。
记录流程负责人、修订日期和当前操作规程链接。当扣款规则、库存分配或配送服务变化时重新走查。只更新日期，不能让失效流程重新有效。
常见问题
付款失败必须立即取消吗？
仅在商城规则和平台配置如此要求时取消。否则应画出重试或待处理状态、负责人、到期条件，以及预留库存的处理。
一个订单可以有多个履约分支吗？
可以。分别跟踪各包裹的数量和状态，再按主订单规则判断完成，不能用第一个物流号代替整单结果。
