销售出库单同步实战:从电商中台到 ERP 的端到端落地方案

这个策略解决什么问题

某零售企业的电商中台每天会产生成百上千张销售出库单,财务和供应链却只能依赖 ERP 里的数据做对账与发货确认。手动导单不仅效率低,还容易出现「中台已发货、ERP 未出库」的时间差,导致超卖或库存虚增。

我们用轻易云数据集成平台(Qeasy)承接这一同步链路,目标是把中台的销售出库单按既定规则推到 ERP,做到订单状态、发货时间、批次库存三者在两边一致。

整体链路是单向同步:源系统(电商中台)→ 轻易云中间层 → 目标系统(ERP)。中间层负责做编码转换、字段清洗、增量标记和异常暂存。

业务含义	源端字段(电商中台)	中间层处理	目标端字段(ERP)
单据编号	io_no	原值透传	销售出库单号
仓库编码	wh_code	编码映射表查找	仓库档案编码
店铺编码	shop_id	编码映射表查找	部门/销售组织
商品编码	sku	原值透传	物料编码
出库数量	qty	数值类型转换	实发数量
收货人/地址	receiver/address	字段拼接	客户及地址
单据时间	io_time	时区与格式归一	业务日期
物流单号	express_no	非空校验	物流信息
备注	remark	长度截断	表头备注

编码映射集中管理是轻易云客户常见的应对模式:商品、仓库、店铺这三类主数据,放在平台独立的「映射表」里维护,后续任何策略都能复用,避免散落在脚本里。

在 Qeasy 中,一条策略对应一个「集成流」,主要由四块组成:

源端取数器:配置电商中台奇门接口的调用方式,使用平台内置的「奇门」连接器,设置 appkey、secret、抓取时间窗口。这里建议把「按修改时间增量」作为默认模式,避免每次都拉全量。
数据处理管道:用平台自带的脚本节点做字段映射、编码查表、类型转换和表头表体的拆分。表头表体分阶段是轻易云客户常见的应对模式之一——先写表头(单据主信息),再循环写表体(明细行),失败时只重试表体,不影响已经成功的表头。
目标端写入器:选择 ERP 的标准接口,设置批量提交条数、超时时间和失败重试策略。建议开启「幂等写入」,即单据编号重复时跳过而非报错。
异常与告警:配置失败兜底到「异常表」,并对接企业微信或邮件告警,这样值班人员能在 5 分钟内看到问题。

我们在客户现场一般按三个阶段推进:

第一阶段:增量起点对齐 先和业务方确认「以哪个时间点作为起点」。常见做法是取历史最大单据时间为起始时间,然后每 5 分钟增量抓取。这一步最容易翻车——如果源端没有「修改时间」字段,只能退而求其次用「创建时间 + 单据状态」做筛选,边界条件要写清楚。

第二阶段:全量触发与对账 在轻量运行一段时间确认无遗漏后,做一次全量回灌。全量触发一般放在凌晨低峰期,轻易云的调度器支持「指定时间窗内一次性执行」。跑完后,用平台的对账报表核对单据编号、数量、金额三个维度,差异行进入人工复核队列。

第三阶段:调度频率与监控 稳定后,把调度频率从 5 分钟逐步放宽到 10–15 分钟,再配合「订单状态变更」的实时触发,实现增量与全量双轨。轻易云客户常见的应对模式就是这种双轨:日常靠增量,每月初做一次轻量全量校验,既保证时效又控制资源。

时区不一致:电商中台默认是东八区时间戳,ERP 业务日期取的是服务器本地时间。稳的做法是在中间层显式做时区归一,而不是依赖源端或目标端自己去转。
编码映射表未集中:把商品/仓库映射写在脚本里,3 个月后没人记得改过哪里,两边数字开始对不上。稳妥的做法是用轻易云的「映射表」组件,改一处全局生效。
表头成功表体失败导致单据悬挂:中间表先写表头再写表体,任一行失败整单会卡住。典型错误是没有事务补偿。这里我们让平台在表体失败时回滚表头标记,下次重跑时按「未完成」过滤,自然就闭环了。
幂等没开,重跑时目标端报主键冲突:同步策略天然要重跑,目标端接口必须支持「已存在则跳过」。
告警风暴:每次失败都发企业微信,值班同事直接静音。我们后来改成「同一类错误 5 分钟内只发一次」,体验立刻好起来。

适用:电商中台与 ERP 之间单向、增量、字段结构稳定的销售出库单同步,日单量从几百到几万均可。不适用:需要双向协同(两边都改)的订单状态机、强依赖实时库存可用量校验的链路,以及源端字段每周都在变的早期试点系统。

如果你的业务是「订单在中台创建,ERP 只读不写」,且两边的字段结构已经稳定,这条策略可以直接套用。反之,只要存在双向写、字段频繁迭代,就需要先做字段冻结和冲突解决机制,再考虑接入。