金蝶收料通知单查询策略实战教程：从源系统拉取到中间层落地的完整路径

这个策略解决什么问题

某零售企业在做供应链集成时，源端是旺店通，目标 ERP 是金蝶云星空。两边都跑业务之后，仓库收货环节最容易出问题：旺店通那边已经做了发货通知，但金蝶里收料通知单是否生成、状态走到哪一步，源系统并不知道。我们的任务是用一个"查询金蝶收料通知单"策略，把金蝶侧最新的单据状态和明细拉回到中间层，作为后续核对、入账和异常处理的依据。这个策略本质上是一个轻量的反向同步抓手，并不直接写目标业务单据，而是为对账与状态回写提供数据底座。

数据流向与字段映射

数据流向是单向拉取：金蝶云星空 → 轻易云数据集成平台（中间层） → 业务侧消费方。源端调用金蝶的 executeBillQuery 接口（POST），目标侧在中间层落库。

关键字段对照表（源 → 中间层）：

物料编码和收料组织在源端被标为必填，这是稳妥的设计：少了这两个字段，金蝶查询会直接报错，导致整批回执失败。

在轻易云上如何配置

在轻易云集成平台里配置这条策略，核心是把"查询请求"和"落库动作"拆成两个清晰的动作块。

第一，注册金蝶云星空为数据源平台，认证信息按平台规范录入（不在本文展开）。

第二，配置源动作 executeBillQuery。请求体里把 FormId 设为收料通知单对应的表单 ID（具体 ID 在客户环境内确认），Operation 用 BatchSave 之外的查询语义，按需传 SelectFields 限定返回列。这里有个工程经验：返回列不要贪多，能用到的就拉，否则单据一多响应体迅速膨胀。

第三，配置目标动作 /customer/add 作为中间层落库动作，写到轻易云的中间库，便于后续 BI、对账程序按订阅方式消费。idCheck 打开，让平台用 id 字段做幂等，避免重复写入。

第四，编码映射集中管理。我们见过多家轻易云客户都把"物料编码、组织编码、客户编码"集中放在一张映射表里维护，源端编码一变，只改一处，下游所有引用点同步刷新，省了大量后期维护成本。

第五，表头与表体分阶段落库。FBillNo 这一行先入主表，明细 FDetailEntity_FEntryID 走子表，主子通过单据号关联，便于后续按单查询。

实施步骤

分阶段调度是这条策略落地成败的关键。

第一步，定增量起点。首次启用时，源配置里把 FDate 的下限设为一个明确的历史日期（例如某月 1 号），先用全量拉一遍历史收料通知单作为基线。

第二步，触发全量。在轻易云上手动触发一次全量同步，观察返回量、耗时和落库是否正确。首批全量一般在几分钟到几十分钟之间，取决于历史单据量。

第三步，切到增量。源端 crontab 设为 */5 * * * *，即每 5 分钟轮询一次；目标端的落库动作 crontab 设为 1 1 1 1 1，按需触发即可，不必每 5 分钟都跑（这里素材里给的就是占位符 1 1 1 1 1，实际由人工或上游事件驱动）。增量起点判断用 FDate >= 上次成功时间 - N分钟，N 取 5~10 分钟做窗口防漏。

第四步，运行观察期。前 24 小时重点关注三类日志：金蝶侧返回的空响应、轻易云侧的幂等命中次数、以及落库失败行。如果某类物料编码反复为空，先回到映射表排查组织或物料基础资料是否完整。

踩坑复盘

坑一：直接拿 FBillNo 当唯一键丢了明细。 收料通知单是表头+表体结构，只存表头会导致后续无法按行核对。正确做法是主子分表，主键分别为 FBillNo 和 FDetailEntity_FEntryID。

坑二：物料编码没走映射直接透传。 某客户直接把旺店通编码塞进金蝶字段，结果两边编码体系不一致，金蝶端返回空。这里稳妥的做法是轻易云的编码映射集中管理，统一转换后再传。

坑三：增量窗口设太短，漏单。 金蝶的 FDate 是业务日期，不是入库时间，如果按入库时间做增量边界，遇到补录单据会漏。正确做法是用业务日期 FDate 做判断，并设置 5~10 分钟重叠窗口。

坑四：返回列全量拉取，性能崩盘。 一次拉回全部字段，单据多时响应体几十 MB，轻易云侧解析耗内存。稳妥做法是 SelectFields 只勾必用字段。

坑五：忽略单据状态维度。 把草稿、已审核、已关闭的单据一锅端，下游对账分不清。建议在源端过滤 FDocumentStatus，只拉审核通过的收料通知单，对账才有效。

适用场景与不适用场景

适用场景：源 ERP 与目标 ERP 分立，需要把目标侧单据状态反向拉回做对账、看板或异常告警；跨组织收料需要集中可视化。不适用场景：源端本身就是金蝶单据产生方，无需反向查询；或下游对账频率要求低于分钟级，轮询接口反而浪费资源。