商城与 ERP、WMS、CRM 对接：方案、接口与验收

为什么商城对接不能从接口字段直接开始？

企业已经运行ERP、WMS或CRM时，商城会加入现有业务链，而不是取代所有系统。接口开发之前，需要说明哪些资料以哪个系统为准，交易在哪个节点被接受，失败后由谁判断。先写清这些决定，才能知道接口应同步什么、如何表达状态，以及怎样验证结果。

同一字段名称可能代表不同业务概念。例如“客户”可能是消费者、联系人、企业组织或账务主体；“库存”可能是实物余额、可售量或某个渠道额度。若只按数据库列名连接，数据虽然能传过去，后续订单和财务仍可能出现无法解释的差异。需求讨论应使用业务场景与脱敏样本，让技术、运营和财务一起核对。

ERP、WMS 和 CRM 按客户的开放接口实施适配。具体厂商的接口、版本、权限与网络条件，需要客户提供授权资料后才能判断。文内引用的商城事实有固定源码依据，客户环境和外部系统是否通过运行验收，是另外一组证据。

怎样确定一个可以实施的对接范围？

将目标拆成明确业务动作，例如维护商品主数据、接收可售库存、下发已满足条件的订单、接收出库回执或核对退款结果。每个动作要有发起条件、输入、期望结果和例外情况。不能只写“所有数据双向同步”，因为这句话没有定义修改权，也没有说明冲突后谁做裁决。

范围还包括哪些组织、商城、仓库和历史期间参与。某个客户仅需新订单对接时，历史单后续退款可能仍由旧系统处理；若连历史单一起接管，就要把外部编号、在途任务和原付款关系纳入设计。将排除项公开列出，比联调后才发现遗漏更利于安排工作。

边界确定后，补充客户配合事项：当前接口文档、测试账号的有权管理者、隔离环境、脱敏样本及业务确认岗位。没有资料的部分应保持沟通记录，不能依据同类产品的经验替客户宣布兼容。项目报价与安排也应基于这些条件沟通，不给出未经确认的固定时效。

免费获取方案

ERP、WMS与CRM的角色如何区分？

ERP可能承接物料、采购、结算和财务结果，WMS可能负责具体仓库任务与出入库过程，CRM可能维护组织和客户关系。各企业实际使用方式不同，不能按系统名称推定责任。建议按对象的产生、批准、更正、读取和归档分别登记，再将动作分配给实际系统。

商城通常需要面向消费者表达交易状态，但表达依据应来自真实业务结果。仓库已受理还不是已出库；付款渠道已接收申请还不是资金已完成；CRM联系人更换也不等于登录账号应被合并。需要在跨系统状态表中保留这些区别，避免一个“成功”状态包办所有业务含义。

主数据关系同样不能忽略。商品规格、仓库物料、企业客户和结算主体应使用稳定编号关联，名称用于展示与人工识别。编号应带来源和业务范围，变更后仍能追溯过去的交易。具体数据清单见ERP对接要同步哪些数据。

源码里已有的基础怎样进入方案？

当前单体在 单体应用 中装配 UMS、PMS、OMS、CMS；四域保留各自迁移与公开类型，共享单体数据源和本地事务管理器。

单体版仓库保留 OpenAPI 契约，管理端和 PC 端提供依据该契约生成接口类型的命令。

这些基础有助于定位商城业务入口和契约边界，但不能证明客户连接器已经存在。新增适配应通过业务服务和约定接口协作，避免外部系统直接改商城数据库而绕过权限、状态和金额规则。需要扩展哪些入口，应先追踪已有调用路径，再在项目范围里登记。

不同版本与部署形态需要分别核对。不能因为单体版某个契约存在，就假定微服务版具有完全相同的运行路径；也不能因为有配置文件，就声称公网认证、通知、生产高可用和外部业务已验收。工程记录应同时标注源码版本、构建材料、运行环境和具体业务用例，防止证据层级混淆。

接口契约至少需要表达哪些内容？

字段表只是契约的一部分，还需表达身份范围、业务编号、动作版本、前置状态、受理结果、查结果方式、拒绝原因以及重复和乱序语义。尤其是改变库存、付款或履约的操作，应明确超时后的未知结果如何查证，不能把网络异常简单转成再发一次。

金额、数量和时间需要写清单位与口径。内部使用精确十进制，并不能保证外部接口的换算天然一致；会计日期和业务发生时间也可能不同。双方应选取可解释的样本，验证转换规则是否重复稳定，再保存规则版本，便于后续定位历史差异。

接口权限应按实际主体和商城范围核验。读取某张表的能力，不等于有权重放订单、发起退款或变更库存。高影响动作需要明确执行岗位与批准条件。秘密资料应通过受控配置交接，不放入日志、需求附件或公开截图；阅读和范围讨论使用脱敏资料。

库存与履约应先作哪些业务决定？

库存需要先定义实物、可售、预占与释放之间的关系，确认统一写入责任或明确额度划分。展示数量更新及时，并不能替代订单提交时的并发约束。若订单必须得到外部仓库批准，接口不可用时是暂停销售、等待处理还是采用其他经业务批准的策略，应提前说明。

履约需要明确下发触发点和受理、拣货、出库等状态。部分发货、合包、面单作废、取消竞争和退货入库都可能改变后续行为。工程验收应看订单行、外部任务和包裹之间的关联，而不是只看调用次数。对应细节分别见库存同步与超卖防护和订单下发WMS与状态回传。

支付及物流还需核对账号所属主体、测试生产隔离和真实回调。模拟付款或配置保存成功只能证明相应局部链路，不可以替代渠道验收。可按支付与物流接口对接清单准备资料，将未获得条件的项目保留为未执行。

失败补偿和对账为什么要分开设计？

重试处理已经看见的失败任务，对账则从权威业务集合发现遗漏和差异。某个事件没有产生任务时，队列不会知道它存在；某个任务显示成功，也可能关联了错误对象。需要同时设计运行恢复和业务核对，才能解释跨系统结果。

未知结果先查证，资料错误先修正，已经产生业务影响的动作则按实际规则补救。补偿可能是撤销、退款、恢复额度或人工工单，并不等于数据库事务回滚。原动作与补救动作的编号和证据应关联保存，便于业务人员判断当前真实状态。更多方法见接口失败重试、补偿与对账。

一条实施链应留下什么证据？

以下记录用于项目执行与复核，不代表任何客户已经通过。

阶段	主要决定	形成的工程证据	进入后续工作的条件
现状与范围	对接对象、组织范围、历史边界	系统角色图、业务场景和排除项	业务负责人确认责任归属
契约与映射	字段含义、编号、状态和单位	版本化契约、对象关联与样本	双方能解释正常及拒绝结果
隔离联调	身份、网络和基本业务路径	脱敏业务单及两侧查询记录	不混用测试与生产资料
异常验证	重复、超时、乱序和冲突	原操作编号、恢复过程与差异	终止结果可查、人工路径明确
业务验收	库存、履约、资金和财务口径	分组核对表与未通过项	关键差异有明确处置和批准
运行交接	查询、告警、重放与变更岗位	操作说明、权限及升级路径	运行人员能定位未完成业务

验收时应检查正常结果和异常边界，避免只提交一组成功请求截图。测试覆盖哪些接口、哪些版本和哪些范围，必须可复查；沙箱通过与真实渠道通过分别记录。若需要补充适配、监控或人工工具，将其作为范围变更处理，不能悄悄把未完成工作写进既有交付结论。

客户已有开发团队时怎样协作？

已有团队可以继续负责企业差异规则、ERP侧资料和业务确认，商城工程侧负责相应入口与适配设计。双方应共同审查契约和异常用例，约定接口变更如何通知及回归。源码交付能够让客户掌握实现，但不会消除资料授权、外部配合和运行责任。

从ERP与WMS对接需求模板形成初稿，通过系统集成服务讨论实际工作，再核对外部系统文档与API契约说明。源码授权与标准工程服务均明码标价，详见价格页。 查看价格。标准对接包含两轮联调，范围见系统集成服务。