ERP 与看店通商城的双向同步是连锁与品牌项目的核心集成。本文归纳主数据、库存、订单三种同步模式、对账方法与常见坑，供架构师与实施顾问在设计阶段对齐预期。
一、集成目标与边界
项目启动时必须先回答一个问题：每类数据的「单一事实来源」是谁。通常的划分是 ERP 管财务与库存账面，商城管面向消费者的促销、展示与交易。这个边界一旦模糊，最典型的后果就是双写互相覆盖——运营在商城改了价格，ERP 的定时任务把它刷回去了。
建议用一张表把所有权写进接口规格书，并要求双方签字确认：商品基础信息（名称、条码、规格）归 ERP；售价、促销价、详情页图文归商城；可售库存归 ERP 或 WMS；订单归商城，发货与出库状态归 WMS；退款审批归财务系统。凡是没写进这张表的字段，默认不同步，等到有需求时再走变更流程加，比一上来就全量双向同步稳妥得多。
二、同步模式
| 对象 | 推荐方向 | 触发方式 |
|---|---|---|
| 商品主数据 | ERP → 商城 | 定时 + 变更 Webhook |
| 可售库存 | ERP/WMS → 商城 | 实时或 5–15 分钟增量 |
| 销售订单 | 商城 → ERP | 支付成功 Webhook |
| 发货状态 | ERP/WMS → 商城 | 出库回写 |
| 退款 | 双向 | 售后单状态机对齐 |
三、字段映射
字段映射表是整个集成的地基，建议在编码之前就把它做完并双方评审。核心映射关系如下：
| 商城字段 | ERP 对应 | 映射要点 |
|---|---|---|
sku_id |
物料编码 | 一对一，建立独立映射表存储，不要用「商品名称」做关联键 |
barcode |
条形码 | 多规格商品需保证条码全局唯一，共用条码会导致出库串货 |
store_id |
门店 / 仓库编码 | 自提点、前置仓、总仓要分别建码，不能合并 |
order_no |
销售单号 | ERP 侧建议把商城订单号存为外部单号并加唯一索引，用于幂等 |
pay_amount_fen |
实收金额 | 商城以「分」为单位的整数，ERP 多为「元」的小数，换算必须显式处理 |
quantity |
数量 | 注意单位换算，商城按「件」售卖而 ERP 按「箱」管理时需配置换算系数 |
价格是最容易出问题的一环。原则是：促销价不回写 ERP 的标准售价，订单行上传的是实际成交价，ERP 用成交价做收入确认，用标准价与成交价的差额记促销费用。如果把促销价直接刷成标准价，财务的毛利报表会全面失真，而且这类错误往往要到月结时才被发现。
四、库存与超卖
库存同步的延迟是超卖的根源。ERP 到商城的库存推送即使做到 5 分钟一次，在大促的前几分钟里也足够卖超几百单。三层防御缺一不可：
- 预占库存：下单即锁定，不等支付。锁定后设置 15 至 30 分钟的超时，未支付自动释放。这一层解决的是「同一批库存被多人同时下单」。
- 安全库存系数：商城可售库存 = ERP 账面库存 − 安全库存。爆款和低单价商品的系数要调高，慢销品可以调到 0。这一层解决的是「同步延迟窗口内的透支」。
- 夜间全量校准：每天凌晨拉一次 ERP 全量库存与商城比对，差异超过阈值告警而不是静默覆盖。静默覆盖在大促期间会把刚扣减的库存刷回旧值，反而制造超卖。
另外要明确一点：负库存要不要允许。允许负库存能避免因同步延迟导致的误判缺货，但会把风险转移到履约端；不允许则更稳妥但可能少卖。这个决定应由业务方拍板并写进接口规格，不要由开发默认选择。
五、对账
对账要分三条线跑，任何一条出现持续差异都说明集成有缺陷，不能靠人工补数长期扛着：
- 单对单：当日支付成功的订单数应等于 ERP 的销售单数。允许跨零点的时间窗偏移，但偏移量应当稳定，如果偏移量逐日增大就是在漏单。
- 钱对钱：支付渠道账单金额 = 商城订单实收金额 = ERP 收款金额。三方对不上时先看退款是否计入了正确的日期。
- 货对货：发货单数量 = 物流签收数量 + 在途数量，退货入库数量 = 退款成功的商品数量。
差异按四类归因排查：漏单（回调丢失或 ERP 接口超时）、重复（未做幂等，同一订单写了两次）、状态不同步（事件乱序导致状态机停在中间态）、金额舍入（单位换算或分摊算法不一致）。排查时请保留Webhook
投递日志与每次调用的
request_id，这两样东西是还原现场的唯一依据。建议把对账做成每日自动任务并把结果推送到企业微信群，差异为零也要推，这样一旦某天没推就知道任务挂了。
六、技术方案要点
在商城与 ERP 之间加一层中间服务（或消息队列）几乎是必选项，直连的代价是任何一边抖动都会把对方拖垮。中间层负责三件事：削峰（大促时把瞬时的订单洪峰匀速投递给 ERP）、重试（ERP 维护窗口期间暂存消息而不是丢弃）、转换（字段映射与单位换算集中在一处，避免散落在各个接口里）。
接口调用遵循OpenAPI 总览的通用约定，推荐直接使用官方 SDK，省去自行实现签名与退避的成本。鉴权务必为 ERP 集成单独申请一个 AppId，只开通
order:read、order:write、inventory:write 三项权限，具体见API 鉴权说明。独立 AppId 的好处是出问题时能一眼看出是哪个系统在调，也便于单独限流和单独吊销。
七、上线切换
切换建议分三个阶段推进，不要一步到位。并行期（1 至 2 周）：两套系统同时运行，但只允许一侧写入，另一侧只读比对，每天核对差异；灰度期（1 周）：选 1 到 2 家门店真实切换，观察出库、对账、退款全流程；全量期：剩余门店分批切，每批之间留 2 个工作日的观察窗。
切流窗口内必须冻结主数据变更，包括商品上下架、改价、门店信息调整，否则并行的两套系统会产生无法归因的差异。上线前还有一件常被忽略的事：培训门店店员与客服，让他们认识「ERP 有单、商城无单」和「商城有单、ERP 无单」这两种典型异常，知道各自该找谁、该看哪个单号。这类培训做一次半天，能省掉上线后大量的无效沟通。支付相关的资质与结算要求见支付合规。
