ERP 与 Adobe Commerce 集成：把履约与库存做对

多数 ERP 与 Adobe Commerce 的项目，立项时被当作一个连接问题，最后却发现是一个共识问题。把一笔订单送进 ERP 的技术，多年前就已经解决了。没有被解决的，是在您这门具体的生意里，哪个系统被允许是对的。

本指南按照您必须做决定的先后顺序展开：这套集成究竟为何而建、要基于哪种模式来构建、订单履约与库存的数据应该如何流动，以及事后必须存在什么东西才能让它持续奏效。至于这类集成在生产环境中失败的具体方式——库存偏差、价格跳动、重复的销售订单——配套的文章是 Magento 与 SAP 集成：真正会出问题的地方。

从结果出发，而不是从对象清单出发

通常第一份产出物是一张要同步的东西的清单：商品、客户、订单、库存、发票。这是错误的起点，因为它产出的是一套「什么都搬、却什么都没有具体改善」的集成。

正确的起点，是您花钱想要消除的那些运营问题。落到实处，它们几乎总是出自下面这一组：

• 订单被人工二次录入 ERP，既占用人力工时，又引入错误。
• 网站承诺了仓库并没有的库存，造成取消与退款。
• 顾客不联系客服就看不到订单状态。
• 财务在月末人工核对两个系统。
• 价格变动抵达前台店铺太晚，或者抵达了两次。

其中每一条都对应一条具体的数据流、一个具体的方向，以及一个具体的时延要求。在开工之前，把每一条当前的成本写下来——每周多少工时、取消率多少、客服工单量多少。那条基线，正是日后判断这套集成是否奏效的依据，也是最常被所有人忽略的一件事。

然后用同样的措辞把验收标准定下来。「订单在五分钟内出现在 ERP 中，无需人工录入」是可测试的。「系统已集成」不是。

选择集成模式

大致有三种做法，而诚实的答案是三种都行得通——失败之处在于按偏好而不是按契合度来选。

有两个问题，比任何功能对比表都更可靠地决定了答案。

这套 ERP 被定制到什么程度？ 一个被扩展了十年的系统，很少能符合某个连接器的预设。到那一步，转换逻辑您无论如何都得写，于是问题就从「要不要写」变成了「这份逻辑该放在哪里」。

三年之内会有多少个系统？ 如果答案是「ERP 和前台店铺」，那么直接集成是相称的。如果答案是「ERP、POS、一套仓储系统，加上三个销售渠道」，那么一个中枢就值回它的成本——因为点对点连接的增长速度，比系统本身的增长速度更快。

第二种情况在马来西亚的多渠道零售中很常见，这也正是我们构建 WOW Sync（Bridzia 的渠道同步技术）的原因。对 Thunder Match Technology 而言，它连接了 ERP/SAP、网店、实体门店与各大销售渠道，让商品、价格、库存与订单的更新只发生一次，而不是一个渠道一个渠道地重复；同时提供智能订单路由，以及跨仓库与门店的库存池。TMT 反馈，多渠道订单管理的人力成本最高降低了 3 倍。

设计数据流

节奏不是对整套集成做的一个决定，而是按对象做的决定；朝任一方向弄错都代价不菲——把批量加载做成事件驱动会淹没 ERP，而把订单做成批量则会让顾客等待。

这张表里有三行承载了大部分风险。

可售库存是一条公式，不是一个数字。 ERP 中记录的非限制库存，并不是一个前台店铺可以承诺的数量：针对未清交货的分配量、冻结与质检库存、在途货物与安全库存，全都夹在两者之间。请与供应链团队一起把这条公式明确定义下来，在 ERP 侧完成计算，让前台店铺只接收一个数字、自己不做任何算术。

订单必须幂等。 危险的失败不是一个干净利落的报错，而是一次含混的超时——ERP 已经创建了凭证，而前台店铺始终不知道。给每一笔订单发送一个稳定的参考号，并让 ERP 在创建任何东西之前先检查是否已存在对应凭证。这才是让重试变得安全的东西，而安全的重试才让您敢于积极重试。

内容归属必须被强制执行，而不是靠默契。 一次夜间的 ERP 推送悄无声息地覆盖掉手写的商品文案与元描述，会安静地摧毁真实的工作成果，而通常要等到几周后有人注意到流量变化才被发现。逐字段决定归属，并让集成在结构上就无法写入它不拥有的字段。

还有一条适用于全局的设计规则：把 ERP 挡在请求路径之外。 加入购物车、结账与下单，其中任何一步都不应该去等待一个不受您控制的系统。把订单写入一个发件箱，与提交它的那个事务在同一事务中完成，再由后台工作进程去传输。结账从此不再依赖 ERP 是否可用，而每一笔订单都获得了一个可查询的状态。

常见的出错方式，以及对应的设计回应

各类失败模式在 SAP 专篇中有深入讨论；这里是简版，每一条旁边配上结构性的修法。

• 前台店铺与仓库之间的库存偏差。 用增量加上一个较慢周期的完整快照，为消息打时间戳，并对乱序到达的消息直接丢弃而不是应用它。
• 价格在两个数值之间跳动。 每个字段只有一个写入方。ERP 拥有基础价；前台店铺的规则引擎在其之上计算促销，并且从不回写。
• 重试之后出现重复的销售订单。 以稳定参考号为键实现幂等，并在 ERP 侧于创建凭证之前完成检查。
• 重试风暴让故障变得更糟。 把失败分为可重试与终止两类。前者用带随机抖动的指数退避并设置尝试次数上限；后者送入死信队列并发出告警。
• 主数据不匹配。 一个未扩展到某销售组织的物料、一处计量单位差异、一位没有账户的客户。请决定：只存在于一侧的记录是跳过、标记，还是禁止销售——并维护一张以稳定标识符为键的明确映射表，而不是靠 SKU 做字符串匹配。
• 总额相差一分钱。 在架构阶段就把小数精度、舍入方向与计税基数（按行还是按单）定死，然后用一个跨多种税率、并带一行打折运费的整单百分比折扣去测试。

对马来西亚的经营者，请在最后这一点上明确加入 SST 的处理方式：税在哪里计入、在两侧如何表示，必须一致，否则财务会以看起来像舍入缺陷的理由拒绝凭证。

上线之后如何运行它

集成不是一个交付物，而是一项服务。让它持续奏效的几个部分：

从第一天就开始对账。 每晚对活跃商品目录中的可售库存与基础价做一次比对，差异在商定容差之内自动修正、超出则告警；再加上一项每日的订单级检查，列出没有对应 ERP 凭证的前台订单，以及反过来的情况。产出应当是一份由指定的人来读的简短报告。平时总是空白的报告，一旦不空，才会被注意到。

能回答运营问题的监控。 队列深度、消息滞留时长、按类型统计的失败数，以及死信量——把它们呈现在客服与运营看得到的地方，而不是只放在工程仪表板里。

两侧都要有指名的负责人。 多数拖延不决的集成事故，本质上是组织问题：商务团队和 ERP 团队都以为对方正在排查。

变更纪律。 ERP 升级、新增销售组织、新增商品类型、新增销售渠道，全都会触及这套集成。它应当被纳入 ERP 团队的变更流程，而不是事后才被发现。

在大促高峰前做压力测试。 当队列深度增长得比工作进程排空的速度更快时，这类集成的表现会截然不同。请提前决定容量吃紧时先降级什么——通常输掉的是库存刷新频率，而不是订单传输。

下游系统会继承集成产出的一切。通过 EC Intelligence 建立的客户分层与生命周期营销，其质量上限就是抵达它们的订单与客户数据的质量——所以一笔只同步了一半的订单不会停留为集成问题，它会变成一场瞄错方向的营销活动。

常见问题

我们应该用中间件，还是直接与 ERP 集成？

对于两个系统、映射稳定、并且有团队愿意长期拥有这份代码的情况，直接集成是相称的。而一旦涉及多个系统，或者映射经常变动，中间件就值回它的许可费了。决定性的问题是：ERP 被定制得有多深，以及三年之内您预期会有多少个系统。

与 Adobe Commerce 的 ERP 集成需要多久？

它通常是整个项目的关键路径，而不是其中的一项任务。变数来自 ERP 被定制的程度，以及逐字段归属的决定多快能做出来——而不是来自开发速度。尽早把一条端到端的窄切片验证通过，是弄清自己面对的是什么的最可靠方式。

实时还是批量？

两者都要，按对象来选。订单、取消、发货更新，以及快速动销商品的库存变动，走事件驱动。完整的商品主数据、库存快照、价格加载、发票与贷项凭证，走定时调度。把批量操作当作事件来处理，会产生 ERP 当初根本没有按此容量设计的消息量。

商品内容应该由谁拥有——ERP 还是 Adobe Commerce？

ERP 拥有标识符、基础价、库存、单位与客户的财务记录。Adobe Commerce 拥有描述、图片、分类、SEO 元数据与陈列。请在集成中强制执行这一点，而不是指望一条约定俗成的默契。

我们如何同时保持销售渠道的库存准确？

各销售渠道持有它们自己那一份关于库存与订单的视图，因此它们是第二层同步，而不是第一层的延伸。集中解决它——由一个可售库存来源供给每一个渠道——才是让 Shopee、Lazada 与 TikTok Shop 不再各自漂移的办法。

我们该衡量什么，才知道它奏效了？

就衡量您在开工之前记录的那条基线：人工二次录入的工时、因超卖导致的取消率、关于订单状态的客服工单量，以及月末对账时间。让这四项动起来，正是当初买下这套集成要做的事。

简短版本

先定义结果，再列对象清单。依据 ERP 被定制的程度和未来会接入多少系统来选择模式，而不是依据偏好。逐字段决定归属，把可售库存做成一条明确的公式，让订单幂等，并把 ERP 挡在请求路径之外。然后从第一天就把对账建起来，因为每一套集成都会漂移，唯一的问题是您会不会比顾客先发现。

Bridzia 在 Adobe Commerce（Magento）上投入了 14 年，为亚洲各地的零售与快消品牌构建覆盖财务、库存与仓储模块的 ERP 集成。如果您正在筹划一次集成，或者正在弄清一套现有集成为何总是漂移，请把项目情况告诉我们。