物料主数据从ERP同步到电商中台:一个供应链集成策略的实战拆解

这个策略解决什么问题(场景与价值)

在零售与分销场景里,某零售企业的物料主数据长期沉淀在 ERP(此处为金蝶云星空),而门店、电商、仓储环节则在聚水潭上跑业务。两边一旦长期各写各的,3 个月后就会出现"两边 SKU 数量对不上、品牌字段不一致、单位乱套"的问题。

我们这次只拆解一个具体策略:把金蝶云星空的物料基础资料,按增量方式同步到聚水潭的 jushuitan.itemsku.upload 接口。策略名通常写作"物料对接聚水潭"。它不是全量搬迁,也不是双向同步,而是 ERP 作为唯一源、聚水潭作为下游消费方的一次单向流动。

数据流向与字段映射

整体流向是单向的:金蝶云星空(源)→ 轻易云数据集成平台(中间层,负责映射与调度)→ 聚水潭(目标)。轻易云在这个策略里不承担存储,只负责拉取、转换和推送。

源端调用的是金蝶云星空的 executeBillQuery,按 FMasterId 与 FNumber 取物料视图,关键字段如下:

源端字段(ERP)	含义	目标端字段(聚水潭)	含义
`FNumber`	物料编码	`sku_id` / `i_id`	商品编码、款式编码
`FName`	物料名称	`name`(由平台模板生成)	商品名称
`FBaseUnitId.FName`	基本单位	`unit`	单位
`FSpecification`	规格型号	`properties`(模板内)	规格
`F_XC_ASSISTANT.FDATAVALUE`	品牌(辅助资料)	`brand`	品牌
`F_XC_DECIMAL`	批发价	`price`(模板内)	价格
`F_XC_Integer`	保质期(天)	`shelf_life`	保质期

目标端调用 jushuitan.itemsku.upload,使用聚水潭的 id 作为幂等键(idCheck: true)。其中 shelf_life 还做了一段轻函数:case when '{{F_XC_Integer}}' = 0 then '' else '{{F_XC_Integer}}' end,把 0 当成空值处理。

在轻易云上如何配置

我们在客户现场搭建这个策略时,通常按四个模块来组织:

1. 源端连接器。 选择金蝶云星空的官方连接器,填入租户地址、账套信息(已脱敏),并测试 executeBillQuery 的连通性。这里建议先在轻易云里保存一份字段快照,后续排查时非常有用。

2. 目标端连接器。 选择聚水潭连接器,绑定商家授权,确认 jushuitan.itemsku.upload 在该租户下处于可用状态。注意 idCheck 必须打开,否则重复推送会产生脏数据。

3. 字段映射。 在轻易云的映射画布里完成上面表格的对应关系。容易出错的几处:品牌是辅助资料,需要 .FDATAVALUE 取值而不是直接取 ID;单位是基础资料字段,要走 FBaseUnitId.FName 这种链式路径。轻易云客户常见的做法是把这些特殊字段的取值规则集中放在一张"映射常量表"里,后续物料、客户、供应商复用同一份规则。

4. 调度与编排。 源端 crontab 写作 */15 7-23 * * *,每 15 分钟拉一次;目标端 */6 7-23 * * *,每 6 分钟推一次。两端时间窗口一致,目的是让"取数"始终领先"推送"。轻易云负责把两次调度串成一条流水线,中间失败会自动重试。

实施步骤

阶段一:增量起点初始化。 第一次上线前,以 ERP 中 FMasterId 的快照作为增量起点。后续策略只取 FMasterId > 上次最大ID 的记录,避免一上来就做全量。

阶段二:全量触发(可选)。 在历史数据缺失或大规模初始化时,可以临时切换到全量模式,分批回灌。建议每次 1000~2000 条,跑完后立刻切回增量。

阶段三:日常调度。 增量 + 定时双轨运行,源端每 15 分钟、目标端每 6 分钟,系统自动衔接。这里有个稳妥的做法:在轻易云里把"源端完成 → 目标端执行"配置成串行依赖,任何一端异常都会暂停另一端,避免漏单或重复。

阶段四:异常处理。 聚水潭对编码、品牌为空的物料会拒收,因此轻易云侧需要把"必填校验"前置,失败记录写回日志,人工补全后重推。

踩坑复盘

品牌字段直接用了 ID。 ERP 里品牌是辅助资料,如果取的是 F_XC_ASSISTANT.FNumber,推到聚水潭就会变成一串系统编码,运营根本看不懂。这里一定要 .FDATAVALUE 取展示值。
保质期 0 被当成有效值。 物料里保质期未填时,ERP 默认是 0,如果不处理,聚水潭会出现"保质期 0 天"的商品。前面那段 case when 函数就是为了解决这个。
单位字段走了 ID 而不是名称。 FBaseUnitId 是个对象,直接取出来是主键,聚水潭接不住。要走 FBaseUnitId.FName。
调度频率错配。 一开始两端都用 15 分钟,结果推送速度跟不上取数,积压严重。后改成源 15 分钟、目标 6 分钟,负载才均衡。
重复推送没去重。 idCheck 默认是关的,如果不打开,同一个 SKU 会被反复覆盖。这里一定要显式开启幂等检查。

适用场景与不适用场景

适用: ERP 作为物料唯一来源、电商或分销中台作为下游消费方,需要近实时(分钟级)同步,且业务以新增、修改为主、不需要反向回写。

不适用: 需要双向同步(比如电商端的 SKU 状态回写 ERP)、需要同步图片或附件、对实时性要求在秒级以下,这些场景要换更复杂的方案。