供应商主数据从领星ERP同步到金蝶云星空:一个策略的实战拆解

这个策略解决什么问题

供应链上线阶段,业务部门常常要面对两套系统:跨境电商侧的领星ERP是供应商档案的录入源头,金蝶云星空则是财务结算、采购订单的统一入口。供应商一旦在两边各录一遍,编码不一致、简称不统一、停用状态不同步,后续付款、对账、税务都会出问题。这条策略只做一件事:把领星侧的供应商主数据按编码为准,逐日推到金蝶侧,让金蝶成为唯一结算档案。

数据流向与字段映射

整体流向是 领星ERP → 轻易云数据集成平台 → 金蝶云星空,中间不落库,只做字段重塑与编码校验。

源端 is_delete 用 0 过滤未删除数据,避免把已作废的档案推过去;目标端走 batchSave,金蝶侧按编码决定新增或修改。

在轻易云上如何配置

源端接入选择 WebAPI 的 QUERY 类型,分页参数 offset 与 length 显式声明,默认单次 1000 条,避免一次拉过多触发限流。响应里只取真实用得到的字段,其余交给轻易云的 autoFillResponse。

目标端选择 EXECUTE 类型的 batchSave,组织、分组这些静态值做常量映射;编码、名称、简称做字段映射。其中 FName 用 {{supplier_name}} 模板语法,FShortName 用条件表达式回退。

轻易云客户里常见的两种应对模式:一是把所有编码转换、分组常量抽到「编码映射集中管理」,策略里只引用不写死,改一处生效全场;二是「表头表体分阶段」,本策略只同步表头,联系人、银行账号等表体信息留到二阶段,降低首版风险。

实施步骤

第一步,确认起点。全量触发:用 is_delete=0 把全量有效供应商首次批量拉过来,作为金蝶侧的初始化基线;增量起点:记录首跑成功的 supplier_id 集合,后续每天按 updated_at 或游标分页拉增量。

第二步,调度频率。源端策略 crontab 设为 15 0 * * *,目标端设为 29 0 * * *,两端错峰 14 分钟,目标晚于源是为了给中间层留出处理窗口,避免出现「源还没拉完,目标已经开始写」的竞争。

第三步,验证与回写。轻易云平台会自动比对响应里的 FNumber,已存在走更新分支,不存在走新增分支。首次全量跑完后,人工在金蝶侧抽样 5–10 条核对名称、简称、组织、分组四列,确认无误再切到日常调度。

第四步,监控与告警。每天看一次「源拉取条数 vs 目标写入条数」,两者长期偏差超过 1% 要立刻排查,典型原因是源端分页漏页或目标端某条因编码冲突被拒。

踩坑复盘

1. 编码当主键是底线。一旦让金蝶自生成编码,后续回写、改名都会乱。必须让领星的 supplier_code 原样落到 FNumber,idCheck 开关务必打开。
2. 名称超长被截断。金蝶的 FName 有字符上限,领星侧部分海外供应商名称很长,这里容易翻车。稳妥做法是同步前在轻易云的「字段映射」里加一层截断 + 告警。
3. 「已删除」不要硬删。源端 is_delete=1 的数据,别在金蝶侧真删,而是用 FForbidStatus 做禁用,留审计痕迹。
4. 组织、分组写死在策略里,后续多组织扩展会卡住。典型错误是直接把 100、CG 写进请求体,新加组织时得改 N 个策略。一次性抽到「常量管理」,后续只改一处。
5. 两端 crontab 同时整点跑,目标写库排队。我们做过实际项目,两策略都在 0 0 * * * 时金蝶侧偶发超时。错峰 10–15 分钟是稳妥做法。

适用场景与不适用场景

适用:单一集团、单一组织,供应商档案只由领星侧维护,金蝶侧仅消费。 不适用:多家子公司共用金蝶一套账且需要按组织隔离供应商;供应商档案在两边都会改,需要双向同步;联系人、银行账号等表体字段需要同写——这些场景要么换策略,要么拆成多个并行策略,不要硬塞到这一条里。