Web 版 ERP 与电商平台集成方案
对很多企业来说，电商店铺是订单的诞生地，ERP 是订单的归宿。集成在白板上看很简单——订单进来、库存出去——然后现实就到了：限流、webhook 风暴、部分失败、SKU 对不上。本文介绍我们用来保持 ERP 与平台同步、全程无人二次录入的模式。
三个同步面
把平台集成当成三条独立的管线，各有方向、节奏和失败处理：
- 订单同步（入站）——平台订单变成 ERP 销售订单。
- 库存同步（出站）——ERP 可用库存变成平台 listing 的可售数量。
- 商品同步（出站、更慢）——物料、价格、描述从 ERP 流向平台，通常由主数据驱动。
订单同步：拉取胜过推送
平台为新订单提供 webhook，webhook 当通知用没问题——但绝不能当唯一数据源。webhook 会丢、会乱序、会重复。可靠的模式：
- webhook（或每几分钟一次的定时轮询）触发一次增量订单拉取，从平台 API 按持久化的
last_synced_at水位线取数。 - 每个订单映射为 ERP 销售订单，平台订单 ID 存为唯一外部键。
- 唯一键让摄取幂等：重复拉取同一订单是更新已有 ERP 单据，而不是新建重复单。
- 订单状态变化（已付款、已发货、已退款）走同一条水位线管线反方向——ERP 发货确认回传运单号到平台。
每两到五分钟轮询对除秒杀外的所有场景都够用，它把"我们是不是丢了 webhook"从事故变成一个不是问题的问题。
库存同步：防抖加优先
可用库存一直在变——每次收货、发料、调整都可能触发推送。每次变化都推会刷爆平台 API 撞上限流。替代方案：
- 防抖——每个 SKU 累积一小段时间（30–60 秒）的变化，只推最新值。
- 分优先级——低于安全库存的 SKU 立即推；动销慢的进防抖批次。
- 留预留，不超卖——推
可用 = 现存 - 预留 - 安全库存。两个渠道同时卖最后一件的竞态交给平台在下单时兜底；你要做的是让这个竞态罕见。
商品同步：主数据契约
商品同步比任何其他同步都更常静默失败：一边有一边没有的 SKU、对不上的计量单位、凭感觉映射的类目。用显式契约解决：
- 一个 SKU 字段是两边的事实源，不可变，不接受"差不多"的变体。
- 映射表覆盖真正不同的字段（平台类目 ID、listing 标题、税收分类），映射表要被评审，而不是临场发挥。
- 同步以批处理 diff 报告的形式运行：推送前生成"将要改变什么"的差异清单；流程没赢得信任之前，先过人眼。
幂等与重试是底线
每个出站调用带幂等键；每条入站消息按外部 ID 去重。重试用带抖动的指数退避，失败的作业进死信队列并配一个重试界面——运营可以查看、修正映射、重新跑失败的同步，而不是来找开发。同样的纪律也用在 ERP 自己的过账管线上；幂等模式在财务侧的应用见总账与业务单据一体化设计。
结语
平台集成是一场不信任练习：不信任 webhook（水位线加轮询）、不信任只投递一次（幂等键）、不信任流量（防抖加优先）。从第一天起把这三个习惯做进去，即使平台倒霉的那一天，ERP 仍是唯一事实源。同样的可靠性思维用在屏幕上时，企业级 Web 界面模式对集成监控大屏一样适用。