CRMEB 怎么对接 ERP 与进销存？三种同步方案对比（2026）
CRMEB 对接 ERP 不是一件事，而是五条数据流：商品、库存、订单、发货、售后。这篇对比实时接口、定时任务、中间表三种同步方式，给出以 ERP 回调为代表的对接形态、防超卖的安全库存设计，以及必须做的幂等与对账机制。
一、先想清楚：要同步哪五类数据
「CRMEB 对接 ERP」听起来是一件事，实际上是五条独立的数据流。分开设计比当成一个整体去做要可靠得多。
| 数据流 | 方向 | 不同步的后果 |
|---|---|---|
| 商品档案 | ERP → 商城为主 | 两边商品名、规格不一致，订单无法自动匹配 |
| 库存 | ERP → 商城 | 商城按旧库存卖，超卖后无法发货 |
| 订单 | 商城 → ERP | 仓库不知道要发货，订单卡在商城 |
| 发货与物流 | ERP → 商城 | 用户收不到物流信息，客服被反复追问 |
| 售后与退款 | 双向 | 退款了但仓库照发，或退货入库了商城没退款 |
其中库存和订单最关键。库存没同步好会产生无法履约的订单；订单没同步好会让仓库变成人工录单。
二、三种对接方式怎么选
| 方式 | 怎么工作 | 适合场景 | 代价 |
|---|---|---|---|
| 实时接口（API 双向） | 双方通过 REST 接口互相推送与拉取 | 库存要求准、订单要即时下传 | 需要双方系统都可稳定对外提供服务 |
| 定时任务批量同步 | 按固定周期批量拉取或推送 | 非实时数据：商品档案、日报表、历史订单 | 有延迟，不适合秒级库存 |
| 中间表数据交换 | 约定一张中间表，一方写一方读 | 复杂业务场景，或 ERP 不便开放接口 | 需处理并发与锁，维护成本较高 |
实践中的组合通常是：库存与订单走实时接口，商品档案与报表走定时任务，个别字段走中间表兜底——三种方式可按数据流分别选。
CRMEB 侧对外接口是独立的一层（官方目录结构里体现为 controller 下的「对外接口控制器」与 services 下的「对外接口」，不同版本目录名可能略有差异）。控制器只做薄转发，业务逻辑落在服务层——新增对外数据流的正确做法是「加控制器 + 加服务方法」，而不是把逻辑堆在控制器里。
三、以 ERP 对接为例：需要哪几个回调
CRMEB 官方文档里有一份较完整的开放平台对接说明，以聚水潭 ERP 为例给出了消息推送的接口地址约定，展示了这类对接「需要哪几个回调」。
| 业务动作 | 回调路径（官方文档约定形式） | 作用 |
|---|---|---|
| 物流同步 | /erpapi/order/deliver_callback |
ERP 出库后把运单信息回传给商城 |
| 取消订单 | /erpapi/order/cancel_callback |
ERP 侧取消时通知商城同步取消 |
| 库存同步 | /erpapi/stock/callback |
库存变动推送，防止商城超卖 |
| 售后收货 | /erpapi/refund/receive_callback |
退货入库后回传，触发商城退款流程 |
官方文档还提到两件前置配置：需要先在 ERP 侧申请开发账号拿到对接凭据；店铺设置时需勾选自动同步，且门店与店铺一一对应。这说明 ERP 对接从来不是纯技术问题，一半工作量在两边系统的账号与配置对齐上——很多对接卡住，卡的不是代码，而是某一侧的配置没准备好。具体接口地址与参数以 CRMEB 与对应 ERP 的当前官方文档为准，不要照抄旧项目的路径。
四、库存同步：防超卖的核心设计
库存是这类对接里最容易出事故的一条：商城和 ERP 是两套独立系统，两边数字在任意时刻都可能不一致。
| 设计要点 | 具体做法 | 为什么重要 |
|---|---|---|
| 以谁为准 | 明确「ERP 是库存的权威源」，商城侧是副本 | 两个权威源必然打架 |
| 下单时的占用 | 下单即占用库存，超时未付自动释放 | 否则并发下单会穿透库存 |
| 同步延迟容忍度 | 接受「秒级到分钟级」延迟，用安全库存缓冲 | 完全实时不现实，缓冲比追求实时更有效 |
| 异常兜底 | 同步中断时降级为「仅可下单不可超卖」策略 | 避免同步故障导致大规模超卖 |
最实用的经验是留安全库存。与其花大力气把延迟压到毫秒级，不如在商城侧预留一小部分缓冲库存——成本低得多，效果也更稳定。
五、订单与发货的顺序问题
订单下传和物流回传是两个方向，但有隐含的顺序依赖：先有商城订单才有 ERP 出库，先有 ERP 出库才有物流回传。顺序错乱会产生三类故障。
| 故障现象 | 根因 | 处理方式 |
|---|---|---|
| ERP 里有订单，商城没收到回传 | 订单下传成功了，但发货回调失败 | 补发机制：按订单号定期对账并补拉 |
| 商城显示已发货，实际没出库 | 把「ERP 已接收订单」误当成「已发货」 | 严格区分状态语义，用出库单号而非接单回执作为发货依据 |
| 同一订单重复下传 | 重试没有幂等，ERP 收到两笔 | 用商城订单号作为唯一键，ERP 侧做去重 |
关键认知：状态语义必须两边对齐。「已接单」「已出库」「已发货」是三个不同状态，很多对接事故的根源就是把它们混成了一个。退款退回 ERP 也要小心：如果 ERP 已把货放回库存，商城侧就必须完成退款，否则会账实不符。
六、字段与主数据对齐
对接失败有一大半其实不是接口问题，而是字段对不上。
| 要对齐的项 | 常见冲突 | 建议做法 |
|---|---|---|
| 商品唯一标识 | 商城用商品 ID，ERP 用 SKU 编码 | 建立映射表，两边都存对方的键 |
| 规格与单位 | 一边按「箱」，一边按「件」 | 统一到最小计量单位，换算在中间层做 |
| 金额口径 | 含不含运费、含不含优惠 | 明确约定，并在文档里写死 |
映射表要落库，不要硬编码在代码里。映射关系会随业务新增，写死在代码里意味着每加一个商品规格就要改一次程序、发一次版。
七、必须做的幂等、对账与监控
对接系统最怕的不是偶尔失败，而是失败了没人知道。
| 机制 | 要解决什么 | 实现要点 |
|---|---|---|
| 幂等 | 重试导致的重复下单、重复发货 | 用业务唯一键（订单号 + 动作类型）去重 |
| 重试队列 | 对方系统临时不可用 | 失败进队列，指数退避重试，超阈值转人工 |
| 对账任务 | 两边数据长期不一致 | 按订单号定期比对，输出差异清单 |
| 日志留痕 | 出问题无法定位 | 每次同步记录请求、响应、结果与耗时 |
「对账任务」是必备项，不是可选项。接口成功不等于业务成功——接口返回成功但对方处理失败完全可能发生，只有定期对账才能发现这类「无声的失败」。
这套「幂等 + 异步 + 对账」的思路和资金类功能一致，我们在多商户分账那篇里也从另一个角度讲过。
八、常见问题
Q1：CRMEB 对接 ERP 要改核心代码吗？
正确做法是走对外接口层新增控制器与服务方法，不直接改核心业务文件，这样后续官方升级时冲突面最小。
Q2：库存怎么防止超卖？
三件事：明确 ERP 是库存权威源、下单即占用库存、商城侧预留安全库存缓冲。追求毫秒级实时意义不大，缓冲机制更实用。
Q3：需要做哪些回调？
至少四类：物流同步、取消订单、库存同步、售后收货。具体路径以 CRMEB 与对应 ERP 的当前官方文档为准，不要照抄旧项目地址。
Q4：接口返回成功就等于同步成功吗？
不等于。接口返回成功只表示「请求被接收」，不代表对方处理成功，所以要定期跑对账任务才能发现无声的失败。整体周期取决于要打通几条数据流、对方系统的开放程度以及主数据是否需要清洗，建议先打通「库存 + 订单 + 发货」这三条核心流。
九、服务说明
澄渔工作室提供 CRMEB 二次开发服务：
需求评估、影响面分析、定制开发、联调上线、运维支持。
我们长期在生产环境运维与二开 CRMEB 6.x 体系，覆盖 B2C 与多商户两条产品线，承接 ERP、进销存、WMS 等后端系统的对接与改造。
案例包括美聚云仓（基于 CRMEB 改造的电商与私域一体化系统）。
微信咨询：goooooono1
延伸阅读
- CRMEB 微信公众号怎么配置？服务号对接、JSAPI 支付与二开完整指南——本系列的支柱文章
- CRMEB 二开怎么做才不破坏升级——对接改造的工程规范
- CRMEB 微信支付报错怎么排查——支付链路
- 软件开发定制：从需求梳理到上线的完整路径——对接项目的推进方法
- 联系我们——微信 goooooono1
参考资料
- CRMEB 官方文档 · 开放平台（含 ERP 消息推送接口约定）：doc.crmeb.com/pro/crmebprov2/2326
- CRMEB 官方文档 · 对外接口层与目录结构：doc.crmeb.com/pro_s/pro_single/4755
- CRMEB 官方文档 · 开发规范：doc.crmeb.com/single/v5/7902
鄂公网安备42010502001286号