销售订单发货通知单同步：ERP 推 OA 审批流的实战拆解

这个策略解决什么问题

某制造企业的发货环节长期卡在一道「跨系统流程」上：仓库在 ERP 里完成发货过账后，物流单据必须再由业务员手工录入 OA 走审批，结果同一份发货通知单要在两个系统里维护两次。一个月下来，OA 流程与 ERP 台账经常出现 1–2 天的时延，偶尔还会出现数量、单位不一致的情况。

我们要做的，就是把 ERP 的发货通知单按照单据编号同步到 OA，发起对应的审批流程，并在 OA 回写审批结果。整件事压在一条同步策略里。

数据流向与字段映射

整体流向是单向推：ERP → 中间层 → OA。源系统在 ERP，发起方是单据保存事件；目标系统在 OA，落地为一个流程实例。

关键字段对照（精简版）：

这里有个真实工程里容易忽略的点：明细行的「物料+数量」必须在同一笔 payload 里提交，OA 端不允许后补行。

在轻易云上如何配置

我们在客户现场用的是轻易云数据集成平台（Qeasy），把这条策略作为一个独立集成流处理。配置时通常分三块：

1. 源端事件接入：在 ERP 侧启用单据保存事件，把发货通知单的整张单（含表头表体）通过标准接口一次性推送，避免分次拉取。
2. 中间层转换：在轻易云的转换器里完成编码映射、单位换算、日期格式化。编码映射我们习惯「集中维护」——单独维护一张映射表，后续物料、客户、组织变动只改这一处，不再改流程。
3. 目标端落地：OA 端用审批流发起接口，把整理好的字段写进流程表单，并把 OA 返回的流程实例 ID 回写到 ERP 自定义字段，方便后续对账。

稳妥的做法是：表头字段先跑通，单跑稳之后再加表体；表体阶段先全量验证，再切增量。

实施步骤

我们通常把上线切成四段，逐段验证：

1. 增量起点：先确认 ERP 已有单据的「最后修改时间」，以这一刻为增量起点，避免把历史单据全部重推到 OA。
2. 首轮全量：在增量起点之后，跑一次小范围全量（比如某个组织或某个客户），把映射表、字段、单位一次性校验完。
3. 分阶段调度：
   • 表头先上线，每 5 分钟拉一次增量；
   • 表体稳定后，把频率收紧到 1 分钟；
   • 异常单据进重试队列，单独处理。
4. 回写与对账：OA 流程结束后，把审批结果与最终发货时间回写到 ERP，每天一次对账，差异清单发给业务确认。

整条链路我们坚持「增量与全量双轨」：平时跑增量兜底，每周末跑一次小批量对账，确保漏单能被补抓。

踩坑复盘

1. 编码映射分散维护。早期有客户把物料映射写死在转换器脚本里，物料新增或调整时只能逐条改脚本，改了 3 个月就漏改。稳妥的做法是统一收口到映射表，集中变更。
2. 表头表体一起跑导致排错困难。一次性把整张单全推，失败时不知道是表头脏数据还是表体越界。稳妥的做法是先表头、再表体，分阶段上线。
3. 增量起点定错导致历史重推。如果起点时间被回退或被手工改过，会触发历史单据重推，OA 流程被重复发起。稳妥的做法是把增量起点配置锁死，并加一个「单据编号去重」兜底。
4. 审批流超时未回写。OA 流程长时间不结束，ERP 这边看不到最终状态。稳妥的做法是设置超时熔断与人工介入节点，而不是无限等待。
5. 单位与精度被忽略。ERP 的基本单位与 OA 流程表单里的数量精度不一致，明细行会出现小数位异常。稳妥的做法是在中间层统一一次精度与单位换算。

适用场景与不适用场景

适用：单据结构稳定、业务量中等、需要走跨系统审批与留痕的企业；ERP 与 OA 都有标准接口、字段能一对一映射的供应链场景。

不适用：需要复杂分支条件审批或并行会签的场景；ERP 与 OA 字段结构差异过大、必须做大量二次开发的场景；以及对实时性要求低于分钟级、可走人工录入的轻量场景。