销售退货单同步实战:从电商中台到ERP的落单与回写

这个策略解决什么问题(场景与价值)

电商退单要进财务账、退货要回仓库,中台与 ERP 之间如果只靠人工导出导入,三天之内就会出现「库存对不上、单据状态不一致」。我们这次做的是单条策略:把电商中台的销售退货单推送到 ERP,并把 ERP 的审核状态与单据号回写到中台。这是零售企业里看似不起眼、但每月跑量最大的一个回流环节。

整条链路是双向的:正向推送退货单主表+明细,反向回写 ERP 单号与审核状态。

维度	电商中台(源)	轻易云中间层	ERP(目标)
单据头	退货单号、退款单号、店铺、会员、原销售单号、退货时间、退货原因	标准 JSON,统一编码与字段名	业务日期、单据类型、源单编号、客方名称、退货原因
单据体	SKU、名称、数量、单价、税额	物料编码统一走「编码映射集中管理」	物料编码、仓库、数量、含税单价、税率
状态回写	期望收到 ERP 单号、审核结果	回写包挂唯一业务单号	审核后返回单据号、审核人、状态

这里有个关键点:物料编码映射要在中间层集中维护。中台 SKU 与 ERP 物料编码往往不是一一对应,有的 SKU 在 ERP 是组合件,有的 ERP 物料在中台早已下架。一次性把映射表做在轻易云里,后续 31 条策略共享同一套编码,新接入业务直接复用。

在轻易云数据集成平台(Qeasy)里,这条策略按「源系统适配器 → 转换器 → 目标系统适配器」三段式搭建。

轻易云客户常见的应对模式里,**「表头表体分阶段」**在退货场景特别重要:中台接口的明细往往依赖主表返回的内码,如果一锅炖,失败重试会把明细重复提交。我们做法是主表先单独过,失败不重试整张单;明细按 ERP 单号分批提交,失败按行重试。

我们把这个策略拆成三段上线节奏,避免一上来就全量开跑。

增量起点:历史数据先用全量脚本灌一次,灌完取「最大修改时间」作为增量起点。之后所有线上数据只走增量,大幅减少接口压力。
全量触发:每天凌晨低峰跑一次全量兜底,对账前一天中台与 ERP 状态差异,差异单走补推队列。增量与全量双轨是轻易云客户里最稳的玩法。
调度频率:退货单对实时性要求不高,源端每 10 分钟轮询一次;目标端 ERP 写入走异步队列,避免并发过高触发 ERP 限流;回写状态在中台侧每 5 分钟拉一次更新。

典型错误:不分离表头表体,失败整单重试。一次实际项目中,客户因为明细里某一行物料在 ERP 已停用,整张退货单被反复重投,导致 ERP 侧重复单据。稳妥的做法是表头与表体分阶段提交,失败按行隔离重试。
典型错误:忽视 ERP 的库存可用量校验。退货入库会影响即时库存,如果 ERP 侧库存被其他任务占用,推单会失败。建议在轻易云转换器里预校验仓库与批次的可用量,失败的单走人工兜底队列。
典型错误:状态回写只回一次。ERP 审核是异步的,有时 30 秒、有时 5 分钟。配置回写任务时要做指数退避轮询,不能假定一次成功。
典型错误:退货退款金额字段直接照搬。电商中台的退款金额含平台优惠券抵扣,ERP 入账口径是按订单实付,这两者经常不一致。我们在中间层做了显式的金额拆分,避免财务月结对不上账。
典型错误:忽略「已关账」期间。ERP 月结后通常禁止修改单据,如果策略不感知期间状态,会在关账期堆积失败单。配置里要加上期间判断,关账期间走挂起,不报错。

适用:电商中台与 ERP 之间的零售退货主链路,尤其是多店铺、多 SKU、月退单量在千单以上的企业。不适用:跨主体的分销退货(需要走分销商单独结算)、跨境退货(涉及海关与多币种,需要单独策略),以及 ERP 还未上线财务模块的过渡期。