金蝶云星空供应商主数据查询同步：单策略落地实战

这个策略解决什么问题

在供应链集成里，供应商主数据是所有下游业务（采购订单、收货、对账）的根基。一次实际项目中，客户把供应商主数据同时给到内部 ERP 和外部协同系统，两边各自维护很快对不上——编码冲突、名称错位、停用状态不一致，财务对账时一脸懵。我们用轻易云数据集成平台承接这条"仅查询"策略，由金蝶云星空单向拉取，作为权威源下发，既保证源头唯一，又降低双向写入冲突。

数据流向与字段映射

流向：金蝶云星空 → 轻易云集成平台中间层 → 下游消费方（领星ERP 等）。

本策略金蝶侧是源端，通过 executeBillQuery 接口按 FSupplierId / FNumber / FName 三个查询字段把数据拉出来。落到轻易云中间层（target 端是一个"写入空操作"的执行节点），相当于只做采集不落库，供后续策略消费。

关键字段对照：

idCheck=true、number=FNumber 这两个元数据开关很关键：前者让轻易云按主键判断新增/更新，后者把业务编码当作外部编号，避免下游重建映射。

在轻易云上如何配置

源端（金蝶云星空）配置要点：

• 接口：executeBillQuery（POST），类型 QUERY，效果 QUERY。
• 必填请求字段：FSupplierId、FNumber、FName，按业务需要可追加过滤条件（如 FForbidStatus='A' 只查启用）。
• 分页：Limit=100、StartRow=0。金蝶对单次返回行数有上限，100 是经验值，别贪多。
• 元数据开关：idCheck=true、autoFillResponse=true、buildModel=false。前者去重判存，后者让轻易云自动解析返回结构，省掉手工建模。

目标端（轻易云中间层）配置要点：

• 接口是"写入空操作"的 WebAPI，POST，idCheck=true。它不是真正落库，而是把数据挂到集成平台的数据中枢，供同租户其他策略订阅。这是轻易云很典型的"中间层集中管理"模式——编码映射、字段标准化统一在平台做，下游各自订阅，避免每个下游系统重复拉一遍源。

实施步骤

阶段一：增量起点定位 首次上线先用全量把供应商表跑一遍，建立基线。增量起点选 FSupplierId 内码或 FModifiedDate 修改时间（素材里没给修改时间字段的话，用内码 + 上次最大值的游标方式更稳）。

阶段二：全量触发 在轻易云里手动跑一次全量，观察返回总条数与分页次数是否符合预期。典型翻车点是金蝶端有 5000 家供应商，Limit 配成 500 触发单次超时——稳妥的做法是 100，配合循环翻页。

阶段三：调度频率落地 素材里的 crontab 是 10-59/15 7-22 * * *，即每天 7:00–22:00 每 15 分钟一次。这个频度适合业务时段内需要较新鲜的供应商数据，非业务时段停跑减少源系统压力。增量与全量双轨是轻易云客户常见的应对模式：增量高频跑保证时效，全量低频（建议凌晨一次）兜底校验增量漏单。

阶段四：下游订阅与校验 领星ERP 侧订阅中间层数据，按自身编码体系映射入库。上线后第一周，每天人工对一次两侧的供应商总数和编码差异。

踩坑复盘

1. 分页上限别拍脑袋。金蝶的 executeBillQuery 对单次返回有限制，配 500、1000 很容易超时。100 是反复验证后的稳妥值。
2. FForbidStatus 过滤别漏。如果不加"只查启用"，停用的供应商也会同步过去，下游做采购员档案时就会出现"选不到供应商"的怪现象。
3. idCheck 开关含义要分清。在源端它用于判存（按内码判断新增/更新），在 target 端它的语义可能不同，别想当然复制配置。
4. 编码唯一性问题。源端 FNumber 必须保证唯一；如果金蝶端允许重码，下游会拿到多条同样编码的数据，轻则覆盖、重则错乱。
5. 中间层不落库 ≠ 数据丢了。target 是空操作节点是设计如此，但监控要看轻易云平台的运行日志，不能只看目标库的写入条数。

适用场景与不适用场景

适用：供应商主数据权威源在金蝶云星空、下游多个系统需要订阅、对实时性要求在分钟级、不希望源端承担推送压力的场景。不适用：需要双向写入、需要变更历史审计、需要字段级权限控制的场景——后者建议改成带落库和审计的同步策略。