商品主数据从电商中台到财务ERP：基于轻易云的单策略增量同步实战

这个策略解决什么问题

商品主数据从电商中台推到云ERP，看似只是"建个物料"的活，但在真实项目里，3 个月后两边对不上账的案例比比皆是。某零售企业把电商中台的商品作为唯一源头，下游财务ERP 的物料档案、单位、分类全部以它为准——这就要求同步策略必须稳定、可重跑、出问题能定位。我们用轻易云数据集成平台（Qeasy）承接，落地成一条独立的同步策略，既不影响其他基础资料，也方便单独维护。

数据流向与字段映射

整体流向为「电商中台 → 轻易云中间层 → 云ERP」。电商中台作为源，提供商品编码、名称、规格、单位、分类、修改时间等关键字段；轻易云负责拉取、清洗、映射；云ERP 接收并落库为物料档案。

关键字段对照如下（仅展示业务关心的核心字段）：

在轻易云上如何配置

源端接口为查询商品列表（GET），分页参数 page / page_size 默认 20；按修改时间区间增量拉取，输入参数 modify_start_time 与 modify_end_time，平台会自动用 {{LAST_SYNC_TIME}} 与 {{CURRENT_TIME}} 替换。详情接口作为 detailAPI 关联触发，用于补全扩展字段。

目标端按云ERP 物料写入接口配置（POST / EXECUTE），请求体按目标系统 schema 组装。我们在轻易云里把编码映射集中管理：商品分类与单位的映射表放在平台的「映射表」模块，而不是散落在脚本里——这样客户业务人员后续调整时不需要开发介入。

实施步骤

第一阶段：增量起点。首次运行时，取一个明确的历史时间点作为 LAST_SYNC_TIME，全量回灌一遍；之后每次调度都用上次成功时间作为起点，CURRENT_TIME 作为终点。这条策略在源端 crontab 配置为每 3 小时一次（4 */3 * * *），高频跑能保证增量窗口短、出问题容易补救。

第二阶段：全量触发。除了定时增量，轻易云还允许手工触发一次全量回灌，用于初始化或修复数据漂移。我们建议把全量与增量做成两个入口，调度上分开治理。

第三阶段：调度频率。商品主数据变化不算频繁，3 小时一次比较稳妥；如果客户量级大、变更密集，可以缩到 1 小时。轻易云这边按客户常见的应对模式，是「增量与全量双轨」：增量保新鲜度，全量兜底对账。

踩坑复盘

坑 1：游标时间戳精度。 源接口的时间戳是毫秒级，但入参模板里要补三个 0 变成微秒字符串，否则源系统会按字符串字典序比对，时间窗口直接错乱。

坑 2：分页深翻漏数据。 商品按修改时间排序后翻页，如果同一秒内有多条更新，可能被重复拉取或漏掉。稳妥的做法是在轻易云里用商品编码做幂等键，重复进入忽略。

坑 3：单位与分类编码不一致。 电商中台给的是中文名，云ERP 要的是编码。我们见过客户现场把映射硬编码在脚本里，后期改一次要动代码——所以强烈建议集中放在轻易云的映射表。

坑 4：详情接口超时不报错。 detailAPI 偶尔会返回空体但 HTTP 200，源配置里 autoFillResponse=true 会把它当成成功跳过，导致扩展字段为空。需要在轻易云的「空响应检测」里加上判定。

坑 5：调度时区。 crontab 表达式按服务器时区解释，跨时区项目一定要在轻易云的策略上确认时区设置，否则凌晨窗口会漂到白天。

适用场景与不适用场景

适用：电商中台作为唯一商品源头，下游财务ERP 需要稳定物料档案；商品变更不频繁但要求次日可用；需要可重跑、可追溯的单策略维护。

不适用：商品实时影响下单与库存（应走即时库存或订单策略）；商品量极大且变更密集（建议改为变更日志订阅）；上下游编码体系完全无法对齐的情况（要先做主数据治理再谈同步）。