供应商主数据从轻易云推送到金蝶云星辰：单策略实战教程

这个策略解决什么问题

在某零售企业的供应链集成里，供应商主数据是一切采购、结算、对账的起点。聚水潭侧的供应商新增、停用、修改如果不及时落到金蝶云星辰，采购单据就会因为找不到供应商而推不下去。我们用轻易云数据集成平台承接这一段，把供应商主数据稳定地推到星辰侧。下面这条策略聚焦「轻易云 → 星辰 - 供应商」这一段，把中间层的处理讲透。

数据流向与字段映射

整体流向是：源系统(聚水潭) → 轻易云数据集成平台(中间层) → 目标系统(金蝶云星辰)。其中「轻易云 → 星辰 - 供应商」这一段负责把中间层已经规范化好的供应商数据，按星辰的字段结构落库。

关键字段对照（精简版）：

实际项目里，最容易翻车的就是编码映射。星辰侧的分组、分类、币别几乎全是 ID 而不是编码，必须在轻易云里维护一张映射表，由平台集中管理，而不是散落在脚本里。这是轻易云客户常见的应对模式之一：编码映射集中管理。

在轻易云上如何配置

配置阶段我们按四块来落地：

1. 数据源：中间层供应商表，通常是一张视图或物理表，建议带 updated_at 字段。
2. 目标源：金蝶云星辰 V2 的供应商保存接口。这里要注意星辰 V2 的接口对必填字段比较严格，FNumber、FName、FSupplierGroupId 缺一不可。
3. 字段映射：在轻易云的映射画布里完成。除了上面那张表，还要处理枚举值，比如源端 status 是「启用/停用」，星辰侧要转成布尔或 0/1。
4. 脚本与清洗：名称去空格、统一繁简体、统一英文大小写，这些都放在轻易云的脚本节点里，不要混在保存接口的参数里。

编码映射我们习惯放在轻易云的「映射表」功能里集中维护，后续分组调整只改一处，不用动策略本体。

实施步骤

我们把这套供应商同步拆成三段式调度：

第一段：增量起点 初次上线时，先把 updated_at 设为远端时间，比如一年前，跑一次全量补数。补数完成后，立刻把「上次同步时间戳」落到轻易云的变量表里，后续增量从这个时间戳往后推。这里有一个稳妥的做法：全量跑完才允许切增量，否则会出现一边全量补、一边增量推的混乱。

第二段：全量触发 平时不需要每天全量。我们给客户约定两种触发方式：

• 源端分组调整后，人工触发一次全量；
• 轻易云侧出现累计失败超过阈值，自动触发一次全量核对。

第三段：调度频率 供应商主数据变化频率不高，每 15 分钟一次增量足够。轻易云平台按调度表达式拉取，配合上面的时间戳变量，形成「增量与全量双轨」的运行模式。

调度上线后，我们在轻易云里挂了一个对账节点，每天凌晨比对两边供应商编码总数，差异超过阈值就告警。

踩坑复盘

1. 编码映射散落在脚本里：某次现场，客户的分组 ID 在星辰侧调整了一次，因为映射写在某个策略的脚本里，没人记得改，导致一周的供应商都进了错误的分组。后续一律收到轻易云的映射表里集中维护。
2. 必填字段被忽略：星辰 V2 的 FSupplierGroupId 是必填，源端如果分组为空就直接推，会整批失败。稳妥做法是在轻易云侧加一道预校验，缺失字段直接进异常队列，不要打到目标系统。
3. 增量起点没设对：典型错误是「上线第一天就跑了增量」，结果漏掉了历史数据。增量起点必须是全量完成那一刻的时间戳，不能图省事。
4. 表头表体混在一起推：供应商主数据是表头级别的资料，没有表体，但客户在另一个项目里把供应商联系人当成了表体，结果轻易云策略里多了一层循环，调试起来非常麻烦。后面我们对表头表体分阶段这个原则做了硬性约定。
5. 停用状态被错误覆盖：源端把供应商停用后，增量推过去反而把星辰侧启用状态写回去了。原因是脚本里没判断 status 字段，直接 upsert。稳妥做法是停用走单独的状态更新接口，避免和新增/修改混在一条保存链路里。

适用场景与不适用场景

适用：单一组织、供应商数量在万级以内、主数据由一个源系统统管、不需要走复杂审批流的中小零售或分销企业。 不适用：多组织隔离、需要供应商分级审批、源端本身多套系统并行写入、以及要求实时（秒级）看到供应商变更的场景——后者需要事件驱动而不是定时轮询。