店铺-客户主数据同步:从旺店通到金蝶云星空的单一策略实战
这个策略解决什么问题
零售企业在多平台开店时,店铺在前端电商系统是「店铺」,到了后端 ERP 就要变成「客户档案」,两边编码规则、组织归属完全不同。一次实际项目中,客户把前端店铺直接当客户写入 ERP,3 个月后财务对账发现某些平台欠款挂账不到对应客户,根因就是店铺没正确映射到客户主数据。店铺-客户同步就是把这种基础资料一致性问题,在中间层一次性解决。
数据流向与字段映射
整体流向是:旺店通(源)→ 轻易云数据集成平台(中间层)→ 金蝶云星空(目标)。中间层承担编码翻译、字段裁剪和分页调度。
| 业务含义 | 源端(旺店通)字段 | 中间层变量 | 目标端(金蝶云星空)字段 | 备注 |
|---|---|---|---|---|
| 平台标识 | platform_id | platform_id | — | 仅作过滤 |
| 店铺编号(唯一) | shop_no | shop_no | FNumber | 作为客户编码 |
| 店铺名称 | shop_name | shop_name | FName | 客户名称 |
| 创建组织 | — | 固定值 | FCreateOrgId | 按目标账套配置 |
| 使用组织 | — | 固定值 | FUseOrgId | 按目标账套配置 |
| 备注 | — | — | FDescription | 可空 |
稳妥做法是把编码映射集中放在轻易云的「映射表」里维护,而不是写死在脚本里,后期调整不影响主流程。
在轻易云上如何配置
在轻易云数据集成平台中,典型配置分三块:源端 API、目标端 API、调度策略。
源端选 wdt.shop.query(POST,QUERY 语义),分页参数 page_no / page_size 走内置分页变量 {{PAGINATION_START_PAGE}} 和 {{PAGINATION_PAGE_SIZE}},建议 page_size 取 40~50,既能压住 RT,又能保证断点续跑的恢复粒度。
目标端选 batchSave(POST,EXECUTE 语义),把 shop_no 灌进 FNumber、shop_name 灌进 FName,组织字段写常量。轻易云的「目标主键」一般勾选 id,启用 idCheck 后,已存在的客户会被覆盖更新而非重复新增,这一点在做增量同步时尤其重要。
最后给这条策略挂上调度:crontab 形如 */5 8-23 * * *,即营业时间段每 5 分钟跑一次。
实施步骤
- 全量初始化:在轻易云里手动触发一次全量,把源端所有店铺作为客户档案写入目标系统。运行前先在测试账套跑通,核对样本数据。
- 增量起点:以全量完成的「最后修改时间」或「最大店铺编号」作为增量起点。店铺主数据变化不频繁,但平台账号改名、店铺过户属于敏感场景,稳妥的做法是「全量 + 增量」双轨,每天低峰再补一次全量校验。
- 调度频率:营业时段每 5 分钟跑增量;凌晨做一次全量对账,差异进入告警通道。
- 异常处理:在轻易云里把目标端返回失败的单据重试 3 次仍失败的,转入人工补偿队列,避免脏数据堆积。
踩坑复盘
- 典型错误一:组织字段硬编码。不同目标账套的
FCreateOrgId/FUseOrgId不一样,一旦硬编码,换账套就全错。稳妥的做法是把这类「按环境变化的常量」抽成轻易云的「环境变量」,而不是写在映射里。 - 典型错误二:shop_no 直接当客户编码。前端店铺编号长度、字符集和 ERP 客户编码规则经常冲突,比如带横杠、带中文。中间层最好做一次「清洗 + 重编码」,而不是无脑透传。
- 典型错误三:忽略分页起 0 还是起 1。
page_no从 0 起还是 1 起,接口文档里写得很清楚,但现场翻车十有八九栽在这里。轻易云内置分页变量虽然能跑通,但建议在第一次联调时打印request body确认。 - 典型错误四:重复创建。关闭
idCheck后,已存在的客户会被重复插入,后续做销售订单时会一个店铺挂出多个客户档案。开启idCheck是基本盘。 - 典型错误五:营业外时段调度。凌晨源端可能维护,如果同步在那个时段触发,会拉到半截数据。建议把调度窗口收敛在
8-23,与营业时间对齐。
适用场景与不适用场景
适用:多平台开店、店铺作为结算主体写入 ERP、需要把店铺和客户档案保持一一对应的供应链集成场景。不适用:店铺数量极大(十万级以上)且需要实时秒级同步;以及需要把店铺拆成「多客户/多结算主体」做复杂分账的场景,这种更适合走自定义主数据模型而不是这条标准策略。