物料主数据从金蝶云星空同步到吉客云:单一策略实战教程
这个策略解决什么问题
物料主数据是企业供应链的"地基"。某零售企业用金蝶云星空做财务与计划,前端业务跑在吉客云上,两边都要维护同一套货品档案——一旦编码或名称不一致,后续订单、库存、对账全部错位。这个策略只做一件事:把金蝶云星空审批通过的物料,按增量方式推到吉客云货品档案,确保上下游主数据统一。
数据流向与字段映射
数据流向为单向:金蝶云星空(源) → 吉客云(目标),中间不落库,直接走轻易云数据集成平台的流式管道。
源端对象是金蝶的物料主数据表单 BD_MATERIAL,通过 executeBillQuery 拉取;目标端是吉客云的货品档案,通过 erp.goods.skuimportbatch 批量写入。
关键字段对照如下:
| 目标字段(吉客云) | 源字段(金蝶) | 映射类型 | 说明 |
|---|---|---|---|
| goodsName | FName | DIRECT | 货品名称 |
| goodsNo | FNumber | DIRECT | 货品编码(业务主键) |
| outSkuCode | FNumber | DIRECT | 外部编码,与物料编码一致 |
| unitName | FSaleUnitId | DIRECT | 销售单位(注意嵌套结构) |
| skuName | FSpecification | DIRECT | 规格型号 |
| skuBarcode | FNumber | DIRECT | 当前用物料编码占位 |
| isBatchManagement | 常量 0 | CONSTANT | 暂按否处理,可扩展 |
| cateCode / cateName | 空 | CONSTANT | 暂留空,后续通过编码映射扩展 |
源端还有 FMATERIALID、FBARCODE、FCategoryID、FExpPeriod 等字段未映射,在轻易云里属于"已拉取但未启用",后续按需启用即可。
在轻易云上如何配置
在轻易云数据集成平台(Qeasy)中,这个策略拆成两个节点:源端 QUERY + 目标端 EXECUTE。
源端(Source)配置要点:
- api 选
executeBillQuery,FormId 写死BD_MATERIAL - FieldKeys 勾选 FNumber、FName、FSpecification、FSaleUnitId 等本次用到的字段,没用的不要勾,减少响应体
- number 和 id 都填 FNumber,idCheck 设为 false(源端不强制校验)
- FilterString 写
FApproveDate>='{{LAST_SYNC_TIME|datetime}}',这是增量过滤的核心 - Limit 设 2000,StartRow 用平台变量
{{PAGINATION_START_ROW}}自动翻页
目标端(Target)配置要点:
- api 选
erp.goods.skuimportbatch,method POST - idCheck 设为 true,让目标端按 goodsNo / outSkuCode 判定新增还是更新
- 字段映射按上表填写,常量字段直接写值
编码映射集中管理:轻易云支持把跨方案的编码对照(如后续要做的 FCategoryID → cateCode)放在集线器或独立方案里,通过 _findCollection 联查。这是轻易云客户常见的做法之一——编码规则集中维护,避免散落在每个策略里改一处忘一处。
实施步骤
分三个阶段推进。
阶段一,增量起点初始化。第一次跑全量拉取历史物料:把 LAST_SYNC_TIME 设为一个很早的时间(例如 2000-01-01),让平台把当前所有已审批物料推到吉客云。跑完之后,LAST_SYNC_TIME 会被自动更新为本次同步时间点。
阶段二,全量触发与校验。全量完成后,人工抽样核对两边编码、名称、规格是否一致。重点查两类物料:一是单位字段异常(FSaleUnitId 返回嵌套对象时 unitName 会被原样写入),二是条码用了物料编码占位的 SKU。
阶段三,进入稳态调度。把 crontab 设为 */15 7-23 * * *,工作时间内每 15 分钟跑一次。轻易云的调度器会自己维护 LAST_SYNC_TIME,不用人工干预。
增量与全量双轨运行:这是轻易云客户的另一个常见模式——全量只在初始化或修复数据时手工触发,日常完全靠增量跑,既稳又快。
踩坑复盘
第一,单位字段嵌套结构。FSaleUnitId 在金蝶里通常返回嵌套对象,如果直接写 {{FSaleUnitId}},目标端收到的会是 JSON 字符串,导致单位名变成 [object Object] 之类。稳妥的做法是先在轻易云里展开,写 {{FSaleUnitId.FName}},或者通过 COLLECTION 联查单位表。
第二,条码占位的隐患。当前的 skuBarcode 用 {{FNumber}} 占位,上线后业务方一旦发现扫码扫出来的不是真实条码,排查会非常费劲。建议第一次上线就把 skuBarcode 切到 {{FBARCODE}},并用 _function 处理空值:条码为空时回退到物料编码。
第三,增量起点回退风险。如果某天源端 LAST_SYNC_TIME 被误改到很早的日期,会触发全量重推,目标端可能因重复数据报错。在轻易云里建议开启目标端 idCheck,并观察首次推送后的告警日志。
第四,FCategoryID 暂留空的扩展点。素材里 cateCode、cateName 都填了空常量,这是"先跑通再补全"的妥协。后续要做分类映射,务必用 COLLECTION 而不是硬编码,否则分类一变两边就对不上了。
第五,调度时段的取舍。*/15 7-23 * * * 是经验值,夜间的物料审批很少,把窗口收窄到 7–23 点能减少无效调用。但如果客户有跨时区夜班,需要把窗口扩到全天。
适用场景与不适用场景
适用:单一 ERP 主数据源、目标端需要镜像物料档案、增量按审批日期即可覆盖变更。不适用:需要双向同步物料、需要把供应商或客户等关联主数据一起联查推送、目标端有大量手工维护的本地化字段(此时需要专门设计冲突合并策略)。