ERP 对接要同步哪些数据

ERP和商城分别维护哪些主数据？

先让业务负责人说明每类数据在哪里产生、由谁批准、在哪里更正。ERP可能负责财务编码、采购及结算，商城可能负责销售展示与消费者交易；实际分工取决于企业正在使用的系统。不能因为ERP已经有商品表，就直接让它覆盖商城所有商品信息。运营图片、销售标题、渠道分类与会计分类往往服务不同目的，需要分别定义。

同一属性应有明确的权威来源。其他系统保存的是副本或派生值，修改动作必须回到负责该属性的系统。若允许双向维护，应先讨论冲突优先级、修订号和人工裁决；单纯增加同步频率无法解决两边都认为自己正确的问题。把责任写成表格，再讨论接口字段，能够较早发现“谁都能改”和“谁都不管”的空白。

对接范围也要明确是否包含退货、财务凭证与历史补录。只把新订单送入ERP，不代表过去的订单和退款已经可以查到。企业若只需某些商城或某类商品参与集成，应把组织范围与生效边界放在契约里，而不是由开发人员在数据导出时临时过滤。

商品编号和销售规格怎么对应？

商品用例区分管理读取和公开读取，具有创建、修订、审核、上下架与带修订号的批量操作。

该事实可以在固定源码的商品服务中核对，但不证明外部ERP商品编号已建立关联。对接时应区分商品展示对象、可销售规格、仓库物料和供应商货号。一个展示商品可能包含多个规格；一个物料也可能出现在不同销售组合中。映射应使用稳定编号，名称只用于人工识别，不能充当统一关联键。

编号表应带来源系统、商城范围、原编号、目标编号和有效状态。某个规格停止销售时，历史交易仍需关联原对象，不宜直接删除映射。商品合并、拆分和换码应保存变更关系，以便订单回传和财务查询仍能找到过去的记录。若资料中存在前导零或大小写区分，双方须确认编码格式，不能在导入时自行转成数字。

新增商品的顺序同样影响业务：先收到售价却没有规格对应，可能生成无法下单的展示；先收到库存但归属未知，可能错误增加其他商品可售量。工程方案应明确缺少前置数据时是否暂存、拒绝或补齐后处理，并留下能够重新处理的引用。

价格要同步一个金额还是一组规则？

价格不是只有一个数值。先说明是含税或未税、建议价或成交价、面向哪个渠道及客户群，以及何时生效。币种、金额单位、有效期间和最低购买条件都可能影响报价。双方应先拿业务样本核对含义，再选择接口表达，不能用数据库字段名称相似来证明价格一致。

已经成交的订单需要保留成交时的价格快照；后续主数据价格变化不应覆盖历史付款与退款依据。临时促销、券优惠和会员折扣若由商城计算，ERP接收的是交易结果还是优惠明细，也应明确。不能同时在ERP和商城重复减同一优惠，再把差异解释为精度误差。

金额以元为单位、使用精确十进制和接口字符串；积分、会员折扣与数量退款各有计算器，退款从冻结成交金额按累计数量差额分配。

现有金额约定提供商城内部核对基础。外部系统若采用不同单位或精度，需要逐项约定转换和舍入点。转换规则更好能够按同一输入重复得到同一结果；规则调整时保留版本，不使用今天的规则重新解释昨天的订单。

库存和订单应该怎样选择同步方向？

库存先区分实物、冻结、预占、可售与在途数量。ERP或WMS的库存余额未必是商城允许消费者购买的数量。商城看到可售量后，下单仍需要处理并发竞争；库存页面更新较快，不等于订单阶段已经避免超卖。具体方法见库存同步与超卖防护。

订单方向则需明确触发点：提交、付款成功、人工审核或其他已批准的条件。ERP接收后应返回业务受理结果和外部单号，让商城能够查到该次动作。部分发货、取消、退款和拒绝也要有对应流程，不能只测试正常订单下发。若业务正在切换系统，还要确定旧订单后续动作由哪一侧继续负责。

接口失败时不要直接重新生成订单号发送。原操作可能已经被ERP接受但回执丢失；更换编号会使外部系统把它当成另一笔交易。双方应约定操作编号的统一范围、查结果入口和重复请求的语义。订单数据与财务凭证可有不同生命周期，分别对账比只看“同步成功条数”更可靠。

一份能验收的数据清单应该长什么样？

下表是需求讨论的工程记录，不是现成连接器字段定义。填写后应补充双方实际接口版本和脱敏样本。

对象	权威来源要确认什么	对接时必须说明什么	验收应比较什么
商品及规格	基础物料与销售属性分别归谁维护	稳定编号、停用、变更关联、组织范围	同一规格是否指向同一物料及销售对象
售价及优惠	谁决定生效和成交金额	单位、税口径、渠道、有效期、计算顺序	报价与订单冻结结果的含义是否一致
库存	谁可写实物与可售数量	仓库、预占、释放、更新版本、延迟判断	余额与未完成交易的关系是否可解释
订单及售后	哪个状态触发外部动作	操作编号、受理回执、撤销、退款关联	双方状态和金额是否能按业务单查证
财务结果	谁形成结算及凭证	会计日期、退款归属、手续费处理、批次	同一期间和相同集合的差异是否闭环

验收样本应包含属性变更、重复编号、未知规格、延迟回执和业务拒绝。缺少某个资料时，把它列为前置条件，而不是在报告中写成默认通过。每个结果都应能指出两侧查询位置、执行时间和负责人；接口返回成功只能证明该层请求处理，业务对象是否正确还需要单独查看。

CRM与其他系统需要怎样避免重复维护？

CRM可能维护客户组织、渠道关系或商机，商城可能维护登录身份和实际交易主体。两者的客户编号不能只按手机号关联，企业账户、联系人和消费者可能不是同一种对象。对接前应区分身份、组织与账务主体，并明确哪些资料可以在什么目的下流转。

若ERP、CRM同时发送客户变更，商城要知道哪条变化具有业务授权。可以按属性定义权威系统，也可以让某个流程统一批准后发布；应选适合现有团队的方案，而不是默认为全字段双向复制。删除、停用和匿名化也要参与设计，否则数据虽能新增，却无法完成后续治理。

从哪些资料开始推进比较稳妥？

先收集当前版本接口说明、真实业务流程和经过授权的脱敏样本，完成对象责任表，再选择一个边界明确的场景进行联调。把未覆盖的对象和异常公开列出，避免局部成功被当成全系统完成。后续加入新场景时，继续沿用同一编号、版本与对账方式。

返回系统集成专题查看整体步骤，使用ERP与WMS对接需求模板登记资料，通过系统集成服务沟通适配、异常恢复及验收范围。现有接口契约与权限说明可在外部系统工程文档核对。