客户主数据从CRM同步到ERP：一条策略的落地全流程

这个策略解决什么问题

客户主数据从CRM推到ERP，看似只是「建一个客户档案」。但只要业务跑起来就会发现：两边编码规则不一样，CRM里是潜客+正式客户混在一起，ERP要求按往来单位分类；CRM改了客户名称，ERP没跟上，财务对账直接卡壳；新增客户ERP里查不到，销售开单要手工补录。

这一次我们要拆解的，就是「小满OKKICRM客户主数据 → 畅捷通T+往来单位」这条单一同步策略。它解决的核心问题是：在私有化部署环境下，把CRM里发生变更的客户档案，按统一编码规则写入ERP的往来单位档案，并保证后续变更持续同步。

整体流向分三层：源系统（CRM）→ 轻易云数据集成平台中间层 → 目标系统（ERP往来单位）。

关键字段对照（典型项，实际以业务确认为准）：

CRM侧字段	中间层映射	ERP往来单位字段	备注
客户编码	`CUST_CODE` 原值透传	客户编码	必须全局唯一
客户名称	去除首尾空格、全角转半角	单位名称	ERP对名称敏感
客户等级（潜客/正式）	映射到分类码	客户分类	集中维护映射表
联系电话	正则清洗后写入	移动电话	防止脏数据污染ERP
详细地址	拼接省/市/区+详细地址	地址	拆分还是拼接看ERP字段定义
备注	透传	备注	长度需注意ERP上限

注：编码映射集中管理是轻易云客户最常见的应对模式之一。把所有「CRM值→ERP值」的对照表放在中间层的映射表里，后续规则调整只改一处，不动源和目标两端。

在轻易云数据集成平台（Qeasy）里，这条策略的配置可以拆成四块：

1. 源系统连接：配置CRM侧的接口访问凭证与数据范围。客户主数据一般走「客户档案列表」接口，按最后修改时间增量取数。

2. 目标系统连接：配置ERP侧的往来单位写入接口。私有化环境下，注意是连接内网地址，并且凭证要走加密存储。

3. 字段映射与转换规则：除了上面那张对照表，建议在轻易云里：

4. 异常处理与告警：轻易云支持把同步失败、编码冲突、字段超长等情况路由到告警通道。客户现场常见的做法是：失败记录先落临时表，告警推给运维群，人工介入后再补推。

这条策略我们一般分三阶段上线：

第一阶段：全量初始化。上线前一次性把CRM现有的正式客户全量推到ERP。轻易云上用「全量触发」模式，按编码升序分批写入，避免一次性大批量触发ERP的接口限流。这里有个稳妥做法：先在小范围账套跑一遍，观察编码冲突和字段超长的比例，确认规则无误再正式全量。

第二阶段：增量起点对齐。全量完成后，记下最后一条记录的最后修改时间 T0，作为增量起点。轻易云的增量策略一般有两种模式：

客户现场实际经验是：时间戳模式简单可靠，但要注意源端时区与轻易云中间层时区的一致；变更流模式更实时，但需要源系统有稳定的变更事件接口。

第三阶段：常态化调度。建议把调度频率设置成 5–15 分钟一轮的轮询，按业务量调整。轻易云客户常见的应对模式是「增量与全量双轨」：平时跑增量，每周日低峰期再跑一次小范围全量校验，用来发现增量过程中漏掉的数据。

坑一：编码规则不一致。CRM里客户编码是字母+数字混合，ERP要求纯数字。这里稳妥的做法是在中间层做一次编码映射，而不是直接拿CRM的编码写入ERP。映射规则集中放在轻易云的映射表里，后续调整方便。

坑二：客户名称里的全角空格和特殊字符。CRM里 张三 这种带全角空格的名称，ERP导入后会变成另一个客户，财务对账时对不上。必须在转换层做清洗。

坑三：增量起点的时区问题。源端时区是UTC+8，中间层如果按UTC取，最后一条记录容易漏掉。一定要在轻易云的策略里明确写明时区偏移。

坑四：表头与表体分阶段。客户主数据本身只有表头，没有表体；但后续要同步的销售订单是表头+表体结构。客户现场常见的做法是：先把表头的同步策略稳定跑一个月，再上线表体相关策略，避免一上线就处理两类问题。

坑五：私网部署下的网络抖动。私有化环境里，CRM到轻易云、轻易云到ERP之间的网络偶尔会抖。这里建议在轻易云里加重试机制（指数退避），而不是一次失败就告警。

适用：CRM作为客户主数据源头，ERP需要按统一编码和分类管理往来单位；CRM端有规范的「最后修改时间」字段或变更事件流；业务对客户档案的一致性要求高。

不适用：CRM和ERP之间双向修改客户档案（双向同步是另一类策略）；CRM里有大量历史脏数据需要先清洗再同步；ERP要求按多组织、多账套分别维护客户档案，但源端没法提供组织维度字段。