销售订单同步：营销云到ERP的出库单一体化落地实战

这个策略解决什么问题

某零售企业的销售链路通常是这样：营销云负责前端接单、要货方下单、协议号管理；ERP负责后端出库、库存扣减、应收核算。中间的「销售订单 → 出库单」同步看似只是一个推送动作，但只要编码映射、增量起点、调度频率任何一环没设计好，三个月后两边数字就对不上了。我们在客户现场用的是轻易云数据集成平台（Qeasy）来承接这类业务单据的流转，本篇围绕「新版订单-出库单」这一条具体策略，把数据流向、字段映射、配置要点与踩坑点逐项拆开。

数据流向与字段映射

整体走向是「营销云 → 轻易云中间层 → 目标ERP」，源端通过 POST /api/openapi/v1/erp/order/honour/agreement/header 拉取已生效的协议订单头表，目标端通过 POST /jdy/v2/scm/sal_out_bound 写入销售出库单。

客户档案、计量单位这些基础资料，建议提前以「基础资料同步」策略先跑一轮，出库单再去关联，避免边跑边查导致首批数据脏。

在轻易云上如何配置

在轻易云集成平台里，这条策略一般落在「业务单据」域下，配置要点集中在四处：

1. 数据源注册。 把营销云的 platform_id 和目标ERP的 platform_id 分别接入，授权方式按公有云标准走即可，连接信息只在平台内部可见，不落到调度脚本里。

2. 字段映射编辑。 轻易云的映射编辑器支持变量与函数两种写法。{{approveDt|date}} 是典型的时间格式化函数，把营销云返回的字符串转成目标ERP要求的 yyyy-MM-dd；{{clientAppNo}} 走 _findCollection 查客户档案集合，把外部编码转成ERP内部ID。这种「编码映射集中管理」是轻易云客户常见的应对模式——后续要换账套或者新增要货方，只改这一个集合就行。

3. 幂等与去重。 idCheck 打开，number 字段设为 id，确保同一笔订单不论重试多少次都不会重复生成出库单。

4. 异常与告警。 在轻易云上给目标ERP的写入失败配置重试策略（建议 3 次，指数退避），并把失败行落到「异常队列」，方便事后补单。

实施步骤

我们一般把这类业务单据同步拆成三个阶段上线：

阶段一：增量起点对齐。 先用 id 字段的最大值做一次截止位，源端从截止位之后开始拉；目标端同时清空测试数据，保证两边基线一致。这一步完成后进入冒烟测试。

阶段二：全量触发与表头表体分阶段跑。 轻易云客户常见的另一种应对模式就是「表头表体分阶段」：先跑订单头，确认每条都能生成对应的出库单头；再单独跑订单行项目，把商品、数量、单价带到出库单明细上。两段中间留 5–10 分钟观察窗口，避免一次性大批量触发把目标ERP压垮。

阶段三：调度频率与增量常态化。 源端 crontab 配 */2 8-21 * * *（白天营业时段每 2 分钟），目标端配 */3 7-23 * * *（覆盖整个业务时段每 3 分钟）。两边频次错开，形成「增量与全量双轨」：源端不断拉新单，目标端在空闲窗口跑一次小全量做对账。

上线第一周建议每小时人工核对一次单据量与异常队列，第二周降为每半天，稳定后转周报。

踩坑复盘

1. 时间字段格式不一致。 营销云返回的是带时区的完整时间字符串，目标ERP只接 yyyy-MM-dd。如果不在映射里用 |date 函数显式格式化，写入时会被目标系统拒收。典型错误是依赖目标系统自动识别。

2. 客户档案集合没就绪就先跑出库单。 _findCollection 找不到对应的客户ID，整条单据直接失败。这种情况下稳妥的做法是把基础资料同步的依赖关系显式声明在 depends_on 里。

3. 幂等键选错。 有人图省事用 no（单据号）做幂等键，结果同一笔订单被改单后再次推送，平台当成新单又生成了一条出库单。这里一定要用源端的 id，不要用业务单据号。

4. 调度频次撞上目标系统的结算窗口。 部分ERP在凌晨跑日结，如果源端 crontab 跨过零点还在拉数据，目标端写入会被日结任务阻塞。稳妥的做法是把源端调度窗口显式圈在业务时段内。

5. 异常队列没人盯。 第一版上线后异常队列里堆了几十条「客户档案缺失」没人处理，三天后才发现。配置里务必把异常告警接上企业微信或者钉钉。

适用场景与不适用场景

适用： 营销云/电商前台有协议订单、要货方和供货方明确、出库环节由ERP完成的零售、批发、医药保健类企业；订单量级在每天几千到几万单、对账延迟容忍在小时级以内。

不适用： 订单状态频繁来回变更（已审 → 反审 → 改价 → 重审）的复杂业务流，以及需要强实时库存联动的场景——这种建议走事件驱动而不是定时轮询。