同一张订单，在两个系统里可能有两个编号
假设销售系统中的订单 SO1047，客户编号为 C018，订购商品 P03 共 100 件。仓库系统接收后生成单号 WH2086，并已出库 40 件。两边都记录订单信息，但承担的工作不同：销售系统负责客户订购了什么，仓库系统负责实际发出了什么。
对接需要保存 SO1047 与 WH2086 的对应关系。客户名称和商品名称可以用于展示，不能仅凭它们建立匹配：名称可能重名、简称不同，也可能被后续修改。如果没有稳定编号，先建立并确认映射表，再讨论自动同步。
每个字段只能有清楚的数据归属
| 字段 | 负责系统 | 对接处理 |
|---|---|---|
| 客户、商品、订购数量 | 销售系统 | 仓库接收确认后的订单数据 |
| 实际出库数量、出库日期 | 仓库系统 | 回传销售端用于查看履约进度 |
| 订单取消或数量修改 | 销售端发起业务变更 | 已出库时转人工处理，不能覆盖历史 |
| 两端编号对应关系 | 对接记录 | 保存来源编号、目标编号与处理状态 |
在例子中，订购 100 件与已出库 40 件并不冲突。若直接把两个系统同名的“数量”字段双向覆盖，就可能把订购数量错误改为 40。字段名称相似，不代表业务含义相同。
把一次同步拆成可追踪的几个阶段
建议为每次操作记录来源订单号、操作类型和业务版本。流程先读取 SO1047 的已确认版本，再检查客户和商品映射，随后发送创建请求，最后记录仓库单号并核对关键字段。正式接口通常把底层数据封装为服务能力，应遵循其字段、权限和状态约定，而不是直接猜测数据库结构。
如果目标返回“已受理”，任务应停留在等待结果。Microsoft 的 API 设计资料说明，异步请求被受理与处理完成是不同状态。对于订单创建，取得目标单号后，还要核对商品、数量与目标业务状态，才有足够依据更新本次对接记录。
超时之后，先查有没有创建成功
最容易制造重复订单的情况是：仓库已经创建 WH2086，但回传途中断开，销售端只看到超时。此时直接重发“新建订单”，可能生成第二张单。对接设计应优先使用接口明确支持的去重或幂等机制；若没有，就按来源订单号查询目标系统，并在无法判断时转入待核查队列。
删除与取消也不能当成同一动作。销售人员取消 SO1047 时，仓库若已出库 40 件，应触发业务确认，保留发生过的出库事实。对接程序负责传递变更请求和显示结果，不自行决定退货、冲销或删除历史。
先做一份不写入的差异报告
接入前先取一批真实但经适当脱敏的订单，只读取两端数据，生成三类结果：编号无法对应、关键字段不一致、仅一端存在。假设抽取 20 张订单，其中 16 张一致、2 张商品映射缺失、2 张未出现在仓库，这份报告说明下一步需要修复什么；它不能直接证明后两张都应该新建。
完成映射和业务确认后，再用少量获准订单验证创建、更新、重复请求与中途失败。日常对账继续按来源编号比较，而不是只检查“两边总数相同”。两个系统各有 20 张单，也可能缺了不同的订单。