ERP 数据同步。订单从电商平台到 ERP 的自动下推

写在前面

把电商平台的订单自动推到 ERP，看起来是一个「调个接口」的活。定时任务起来，拉一批订单，转成 ERP 的字段格式，POST 过去。真正做下来，会发现接口调用只占整个方案很小的一部分。

剩下的全是边界情况。同一笔订单推了两次怎么办？批次跑到第 400 条断了怎么办？平台上的「待发货」在 ERP 里对应哪个状态？客户临时改了地址，那条已经推过去的订单要不要追？

这些问题的共同点是。平时不出事，出事的时候往往已经积压了一批，而且往往没人第一时间知道。所以 ERP 数据同步自动化做得扎不扎实，判断标准不是「同步成功率」，而是「出问题多久能被发现、多久能定位、多久能补」。

本文按落地顺序拆六块。多系统集成的真实难点、幂等设计、断点续传、字段映射与脏数据、对账兜底、上线节奏建议。文中的配置取值是常见做法，需要按各自的平台接口和 ERP 字段核对，不要照抄。

一、多系统集成的真实难点

难点不在接口，在两边的模型不一样。

电商平台的一笔订单，是一条「买家 + 一堆商品 + 金额 + 收货信息」的记录。ERP 里的销售订单则是一张单头加若干订单行，行上挂的是物料编码、仓库、批次、价格。这不是字段改个名就能对上的，中间至少隔着三层转换。

• 商品映射。平台的 SKU 编码要映射到 ERP 的物料编码。有的企业能对应上，有的 SKU 是组合品、赠品、临时改价的活动品，根本没有对应物料。
• 组织与仓库映射。平台按「店铺 / 仓库」维度组织，ERP 按「公司 / 库存组织 / 货位」维度组织。多店铺多仓的组合会成倍增长，映射表就是在这时候失控的。
• 金额口径。平台金额含优惠券、平台补贴、运费；ERP 的应收金额口径通常不认这些。差出来的钱最终都会变成「对不上账」，而不是变成一次报错。

另一个常被低估的难点是状态机。平台的状态流转和 ERP 的流转是两套体系。平台有「待付款 / 待发货 / 已发货 / 已完成 / 已退款 / 已关闭」，ERP 可能有「创建 / 审核 / 备货 / 发货 / 收货 / 关闭 / 退货」。两边不是一一对应，一个平台状态可能对应 ERP 的两个状态，也可能反过来。

这里最容易犯的错，是把状态映射写成一张静态表，跑通了就不管了。真实的映射关系通常带着条件。金额为零的单子跳过「审核」，走特定渠道的单子额外走一步审批。静态表一旦遇到表外的组合，行为就是不可预测的。

二、幂等设计。重复推送怎么办

重复推送不是异常情况，是必然会发生的常态。来源至少有四个。网络超时后重试、定时任务上一轮没跑完下一轮又起、人工在后台手动补推、平台自己重复回调。

所以正确的目标不是「杜绝重复」，而是让重复变得无害。常见做法有三层，建议至少做前两层。

1. 业务幂等键。给每条同步记录一个唯一键。推荐用「平台 + 店铺 + 平台订单号 + 操作类型」的组合，而不是只用订单号。一笔订单可能被拆成多次不同的操作，键太粗会误判成重复然后跳过。
2. 去重表。同步前先查一次已处理记录，命中就走「已处理」分支，不再往下发。
3. 接收方兜底。ERP 侧如果支持按外部单号查重，让它在写入前自己再拦一道。这一层能救前面两层的漏网之鱼，代价是依赖对方的配合，值得争取。

顺带说一个容易忽略的坑。状态更新和新建订单不能用同一套幂等逻辑。新建订单重推是重复，状态更新重推则可能是必要的（第一次发送失败，第二次才成功）。把两者混在一个幂等键里，会出现订单永远推不过去的情况，表现为「有任务在跑，但 ERP 里没有单子」，排查起来很费时间。

三、断点续传

一个批次要拉几千条订单，中间任何一步失败都很正常。平台限流、网络抖动、ERP 数据库连接超时。处理方式决定了系统是「卡住等人救」还是「自己爬起来」。

不要用「第几条」做断点。 这个做法看起来简单，但只要中间有过滤条件（第 3 条脏数据被跳过），编号就和实际待处理集合对不上了，恢复的时候会漏单或重单。

更稳的做法是按业务键断点，把每批的边界记成「最后一条成功处理的订单号 + 该单的更新时间」，恢复时从「更新时间 ≥ 边界」重新开始。重复部分由幂等消掉，代价是多几次无效调用，换来的是不会漏。

配套的三件事。

• 失败要分级。超时、限流这类可重试的错误，指数退避后重试，常见上限取 3~5 次；字段校验不通过这种重试一万次也是一样的错误，直接标记失败转人工，不要占用重试配额。
• 单条失败不阻断整批。一条脏数据卡住整个批次，是最容易被忽视的可用性问题。
• 补数入口要留着。按日期范围手工补推是日常操作，不是应急手段。它应该一直在，而不是等出事再去开发。

四、字段映射与脏数据

字段映射表是这类项目里最容易变成「屎山」的部分。一张表几千行，谁都不敢改，每次出问题都在上面手工补两行。建议从一开始就分层。

第一层是映射规则，把平台字段映射到 ERP 的标准中间字段。这一层应该尽量贴近 1:1，多余信息放进扩展字段，而不是硬塞进 ERP 现有的字段里。

第二层是中间字段到 ERP 字段的转换，包括必填校验、默认值、格式转换（金额精度、日期格式、手机号脱敏还原）。

第三层是业务规则。金额拆分、运费归集、多行合并或拆分。

分层的好处是，改一条业务规则不用重新加载整个映射，改一个字段名不用动业务逻辑，出问题也能定位到具体哪一层。

脏数据要分类处理，不要一刀切丢掉。

脏数据类型	典型表现	处理方式
可自动修复	手机号带空格、日期格式不统一、金额精度多余、必填项为空但有合理默认值	在转换层修正，记录一条修复日志，不进人工
需映射补齐	SKU 找不到对应物料、店铺未绑定库存组织	进「待处理」队列并挂起这条订单，同时给映射维护人发提醒
无法处理	订单金额为负、收货地址缺失到无法发货、平台已全额退款但从未推送	标记失败原因，写入失败表，人工确认后决定作废还是补录

这里有个原则要提前和业务方说清楚。「已下单未支付」的订单要不要推。很多企业选择不推（推了会产生 ERP 端的备货占用），但这样一来，支付后推送的链路就要重新设计，不能假设 ERP 里已经有这张单。两种做法都成立，混着来会出大问题。

五、对账兜底机制

前面所有设计都是在减少差异，但差异一定会发生。多系统数据对账不是锦上添花的功能，是同步系统唯一的真相来源。

对账要比对什么，按优先级排。

1. 单量对账。某个时间窗口内，平台侧的订单笔数、金额合计与 ERP 侧的对应合计是否一致。这是发现漏单的最小单位。
2. 状态分布对账。把平台状态按映射规则折算后，与 ERP 状态分布对比。发现的是「单子在，但卡在某个环节没动」。
3. 逐单明细对账。对上面两轮筛出来的差异单，再逐字段比一次，确认是漏推、多推还是字段错位。

时间口径是这一步最容易出错的地方。平台的「订单创建时间」、ERP 的「单据日期」、以及跑批的时间，三者都不一定相等。如果对账只按其中一种时间戳切片，跨零点的单子就会一直挂着。建议用宽进严出的思路。对账时向前多取一段时间窗口，重叠部分由幂等消掉，宁可多比不要漏比。

对账的结果必须能落地成动作，否则又是一张没人看的表。差异单要能一键查 ERP 一键查平台，要能指派负责人，要能记录处理结论。否则它会安静地烂在那里。

六、上线节奏建议

这类项目的失败，多数不是技术问题，是节奏问题。常见的坏节奏是一上来就全量自动，结果第一周就积压了几百条差异，业务方失去信心，后面再推任何优化都推不动。

一个相对稳的顺序。

第一步，先只读不写。 让同步任务只把数据拉下来存到中间层，做字段映射和对账，不往 ERP 写。跑一到两周，确认映射表覆盖得住真实数据、脏数据比例在可接受范围内。这一步的产出是一份可信的差异清单。

第二步，试写小范围。 选一个店铺或一个品类开始真正写 ERP，人工逐单复核。这个阶段要盯的是「ERP 端业务同事的实际体感」，不是任务成功率。业务方一句「这个订单状态跟我想的不一样」，价值高于任何日志。

第三步，全量自动，人工兜底。 稳定后再放量大范围，但人工介入通道要一直保留。不是「以后不需要了」，而是「量大了以后人工只处理异常单」。

几个具体的建议。

• 上线前把「一键暂停」和「一键重推」做成后台的显眼按钮。事故时这两个按钮能省下大量沟通时间。
• 失败表要有积压监控和告警，别等财务对账的时候才发现同步三天没跑了。
• 映射表的每次修改要有变更记录，并能反查到影响了哪些历史订单。
• 给业务方一个自查入口。输入平台订单号就能看到同步到了哪一步、卡在什么位置。这比一张报表有用得多。

最后

ERP订单自动下推这个场景，接口调通是起点不是终点。真正的分水岭在三个地方。重复了会不会错、断了会不会漏、错了谁知道。

前面三块内容分别对应这三点，第四、第五块是发现问题的能力，最后一块是出问题时人能做什么。把它们补齐了，这个系统才算能长期跑下去，而不是上线第一周很漂亮、第三个月无人值守。

如果你正在评估自己的场景是否适合做，可以先从最简单的判据开始。把「人工同步」的流程完整走一遍，标出每一步的耗时和出错可能。如果出错的环节主要在映射维护而不是搬运，那自动化能解决的范围其实比预期小得多；如果主要在搬运，那这个场景就值得做。