ERP与CRM客户编码不一致怎么办

用主数据责任、映射表和冲突复核，让两个系统的客户关系能够追踪，而不是凭名称直接合并。

CRM把客户叫“示例甲公司”，ERP里却有“甲公司总部”和“甲公司华南分部”。做接口时如果只按名称匹配，很容易把不同结算主体混在一起，也可能把同一主体拆成两份。系统衔接首先要确认业务上什么算一个客户，再确定编码怎样映射。本文适合已有多个系统、客户资料存在重名或分支关系的企业，不涉及替客户改变开票、财务或法律主体规则。

先区分业务对象，再谈统一编码

联系人、集团、交易客户、收货门店和结算主体可能是不同对象。某位采购联系人服务于多家门店，不应因为手机号相同就把门店合并。先由业务负责人确认哪些对象独立建档、哪些保持父子关系、哪些允许多对多关联。技术人员把规则转成字段和约束，不应凭接口方便决定客户归属。遇到历史资料不清楚时保留待复核状态，不用自动猜测制造一份“干净数据”。

让稳定内部身份与外部编码分开

建议在集成边界保留稳定客户标识，同时记录各来源系统的客户编码。旧系统更换编码时，映射可以更新，历史业务仍能追到原对象。下面是纯假设样例，不含真实企业和号码：

映射表还应记录确认人、确认时间和变更原因。不要只留一张Excel然后直接覆盖程序里的编码；当来源系统新增客户、撤销客户或合并档案时，需要有可追踪的更新入口与失败记录。

冲突分成候选、确认和拒绝

名称相近、统一社会信用代码一致、联系人重叠可以用于生成候选，但每种依据的可靠性和使用范围应分别确认。尤其历史字段可能缺失或填写错误，不能宣称一个匹配规则适合全部企业。对于同名不同主体、旧名与新名、一个编码对应多个对象等冲突，应输出待复核清单，说明冲突理由与受影响记录。业务人员批准后再写入正式映射，拒绝候选也保留理由，减少下次重复提示。

接口传递的是业务对象而不只是文本

创建订单时，应明确接口需要交易客户、结算主体还是收货地址，字段名叫customer_id并不足以说明语义。请求在服务端检查身份、权限及对象归属，不能让客户端随意指定其他客户的数据。OWASP的REST安全指南提供服务端控制与输入检查方向。接口安全依据 本文据此建议把编码映射的读写权限列入接口评审，而不是把映射表当作所有用户可下载的公共资料。

迁移和日常同步采用不同检查节奏

首次对接可以集中盘点客户档案，建立差异清单并演练；日常同步则关注增量创建、改名、合并和停用。同步失败时先确认是否已有映射，避免重复创建客户。报表核对应同时比较客户数、订单归属和关键例外，而不能仅凭两个系统记录数量相等宣布一致。涉及财务归属或历史订单改变时，必须由相应业务负责人决定处理口径。

一个可交接的成果包应包含对象定义、映射规则、冲突清单、批准记录和回退办法。企业可通过软件开发服务讨论集成范围；对ERP、CRM、OA关系尚未厘清时，先参考企业管理系统集成。真正的目标是让客户身份与业务记录能解释、能复核，而不是把所有编码强行改成同一串字符。

合并档案前先检查引用关系

准备合并两份档案时，先列出关联订单、报价、联系人、地址和权限，确认历史记录怎样保留与展示。一个档案停用不等于可以删除所有映射，因为旧单据仍可能引用它。可以先生成影响预览，由业务负责人核对，再在批准范围内执行。演练中使用虚构档案，分别测试同名不同主体、改名不改身份、停用后创建新单等情景。若合并结果未知，先核查已发生的修改，不连续重复执行合并来碰运气。