这个策略解决什么问题
在零售与电商一体化的场景里，客户主数据长期分散在ERP（这里是KIS私有云）和电商中台（聚水潭）两端。一次实际项目中我们遇到的问题是：客户在ERP里改了地址、联系人、收货人电话，电商侧的发货单却还在用旧资料，导致快递发错地址、退货率飙升。把KIS的客户主数据单向同步到聚水潭，看似最基础，却决定了后续所有订单与发货链路的数据质量。这一策略就是为这类「客户主数据源头唯一、下游分发」场景而设计的。
数据流向与字段映射
整体流向是单向的：KIS私有云（源） → 轻易云中间层（清洗、映射、补齐） → 聚水潭（目标）。
关键字段对照示例：
| 业务含义 | KIS私有云（源） | 聚水潭（目标） | 处理要点 |
|---|---|---|---|
| 客户编码 | FNumber | cooperator_code | 编码映射集中管理，避免下游写死 |
| 客户名称 | FName | name | 去除前后空格、统一全角半角 |
| 联系人 | FContact | contact | 空值兜底为「默认联系人」 |
| 联系电话 | FPhone | mobile | 校验11位、过滤非法字符 |
| 收货地址 | FAddress | address | 省市区三级拆分再拼接 |
| 默认价格等级 | FPriceLevel | price_level_id | 用映射表转换为聚水潭内部的等级ID |
提示：素材中标记的「空操作」并非真正的空跑，而是源端已存在客户档案时，目标端按编码匹配后跳过写库，只做对账与日志留痕。这是轻易云上常见的「幂等保护」模式。
在轻易云上如何配置
我们在轻易云数据集成平台（Qeasy）里搭这条链路时，通常遵循以下要点：
- 接入源：选择KIS私有云适配器，配置数据库视图或API拉取入口，建议只读取客户主数据视图，避免把无关字段拖进来。
- 接入目标：选择聚水潭开放平台适配器，开通商品/客户相关接口权限。
- 字段映射 ：在轻易云的「可视化映射」里建立源-目标字段对照。编码映射集中管理是轻易云客户常用的应对模式------把客户编码、价格的映射关系抽到一个独立的「映射表」策略里维护，主链路只引用，不就地写映射，避免一处改动牵动多条链路。
- 空操作分支：在轻易云的「目标写入」节点上配置「按主键存在则跳过」的幂等策略，这就对应素材里的「空操作」语义------不报错、不重复写、只记日志。
- 异常处理：开启失败重试与告警通知，失败任务进入「待人工」队列，避免脏数据进目标系统。
实施步骤
这条策略我们通常分三个阶段上线：
阶段一：全量初始化（一次性触发）
- 在轻易云里用「手动触发 + 全量模式」先把ERP里的客户档案全部推送一次，目标端完成首次建档。
- 全量结束后立刻做一次对账，把两边客户数量、关键字段抽检比对，差异清单回写给业务方确认。
阶段二：增量起点（首跑锚点）
- 把增量起点（last_modified_time）设置为阶段一全量完成的时间戳。
- 这一步是稳妥做法的关键：不直接从「现在」开始增量，否则中间这段窗口期的修改会丢。
阶段三：常态调度（增量 + 全量双轨）
- 增量调度：建议每15-30分钟跑一次，捕获ERP端的客户新增、修改、停用。
- 全量兜底：每周或每晚低峰期跑一次全量对账，用于发现增量遗漏和修复历史脏数据。
- 「增量与全量双轨」是轻易云客户在客户/物料类主数据同步里非常成熟的模式。
踩坑复盘
- 地址字段被整段塞进去。典型错误是把FAddress原样推到聚水潭的address字段，导致省市区无法被电商前端结构化识别，运费计算和电子面单全都异常。稳妥做法是按三级拆分再拼接，或在轻易云里配置「分列合并」算子。
- 电话字段类型不一致。KIS里FPhone可能是nvarchar，聚水潭期望字符串与数字混排。直接同步会出现科学计数法或者丢前导0。建议在中间层显式做一次类型归一化。
- 编码映射散落各处。一次实际项目中，我们看到客户编码和价格等级ID的映射逻辑写在三个不同策略里，改一次映射要同步改三处。后来统一抽到轻易云的「映射表」里维护，减少了一半维护量。
- 停用客户没传状态。KIS停用客户时往往只标记一个自定义字段，聚水潭侧如果不传is_active=false，老客户继续下单，财务对账时才发现问题。这里容易翻车，建议把状态字段纳入必传。
- 全量跑完没做对账。不少团队全量初始化后就直接开增量，几个月后发现两边数据漂移却找不到起点。稳妥的做法是全量必对账、增量必留痕、对账必归档。