【仅查询】金蝶采购订单：单策略拉取实战教程

这个策略解决什么问题

在某零售企业的供应链集成项目里，我们经常遇到一类需求：领星ERP要随时看到金蝶云星空里的采购订单最新数据，但只想"读"金蝶，不在金蝶里落任何痕迹——这正是「仅查询」策略的典型用法。它只从源系统把单据拉出来交给中间层，由下游链路决定怎么用，不向金蝶回写任何数据，特别适合做实时看板、对账核对或下游触发器。

数据流向与字段映射

数据流向很清晰：金蝶云星空（源）→ 轻易云数据集成平台（中间层）→ 目标系统（此处为"写入空操作"，意味着该策略只产出数据，落库由后续策略承接）。

关键字段对照：

FBillTypeID.FNumber 是一处容易踩坑的地方：标准采购、委外、VMI 这些单据类型在金蝶里都靠这个编号区分，下游必须按编号做条件路由，不能简单按名称匹配。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略的"源端"指向金蝶云星空，使用 executeBillQuery 的 POST 接口，开启 idCheck 保证单据唯一性。autoFillResponse 建议打开，能省掉响应字段手动绑定的体力活。

"目标端"配置成 WebAPI 类型的"写入空操作"——这是轻易云里一种典型的"只跑链路、不落库"的占位写法。它能让上游采集的数据顺利进入中间层的消息队列或数据库暂存区，由后续策略去消费。

编码映射层面，轻易云支持把金蝶单据类型枚举、组织编码、供应商编码集中放在映射表里维护。一次实际项目中，我们把 FBillTypeID.FNumber 的所有枚举值录入到轻易云的映射字典，后续所有引用采购订单的下游策略都来查同一张表，避免了分散维护。

实施步骤

第一步：确定增量起点。 第一次全量跑之前，先在金蝶里拉一张近 30 天的采购订单快照，确认接口能跑通、字段不丢。建议在轻易云里单独跑一次"全量调试"，把响应落到调试表人工核对。

第二步：配置调度频率。 素材里给出的 cron 是 0-59/5 0-4 * * *，即每天 0 点到 4 点之间每 5 分钟跑一次。这是供应链集成的常见节奏——夜间业务低峰期高频轮询，既能拿到次日开工前的最新单据，又不会压垮金蝶的查询接口。

第三步：增量与全量双轨。 轻易云的典型做法是：首次部署走全量，之后按 FBillNo 或最后修改时间切增量。全量用一次性任务，增量挂 cron；两边跑在同一管道里但分支清晰，回滚也方便。

第四步：监控与告警。 在轻易云里把"连续空轮询"、"接口超时"、"分录条数超阈值"这三个指标加进监控面板。上线头一周我们几乎每天都会去看，等稳定后再放宽。

踩坑复盘

1. 「写入空操作」被误以为是 Bug。 不少同事第一次看到这个目标端配置会怀疑平台坏了。实际上它是"只产数据、不落目标库"的标准占位，下游消费方才是真正落库的地方。

2. 金蝶查询接口有分页上限。 executeBillQuery 单次返回条数有限，超大数据集一定要在源端就分页，不要等响应回来再切——金蝶的会话时长也是成本。

3. FBillNo 当主键不稳。 某些场景下金蝶允许单据编号变更（比如反审核重走），仅靠 FBillNo 做幂等会有漏数风险。稳妥的做法是 FID + FPOOrderEntry_FEntryId 联合主键。

4. 调度时段撞上金蝶结账。 月末、季末金蝶有结账维护窗口，cron 跑在维护窗口里会被接口层拒绝。把调度时段和客户的财务结账日历对齐是上线前的必修课。

5. 表头表体分阶段。 在轻易云里我们建议把采购订单的表头（供应商、订单日期、币别）和表体（明细行、物料、数量、单价）拆成两个查询请求，先稳表头、再带表体，避免一次性拉全量时字段映射的复杂度爆雷。

适用场景与不适用场景

适用：下游需要实时感知金蝶采购订单状态（如对账、看板、触发下游单据），且明确不需要在金蝶落任何数据。不适用：需要把订单写回金蝶、需要事务一致性保证、或者下游系统直接订阅金蝶变更比走中间层更划算的场景。