金蝶收料通知单同步至旺店通采购单：单一策略实战教程

这个策略解决什么问题

在某零售/制造企业的实际业务里，仓库在金蝶云星空做了收料登记之后，门店侧的采购员和供应商对账却还停留在旺店通·旗舰版的采购单上。两边数字一旦对不上，追单、补单、结算就会层层卡壳。这条策略要做的，就是把金蝶云星空的「收料通知单」按一定节奏推成旺店通侧的「采购单」，让上游收料动作和下游采购履约在同一根链条上走通。

数据流向与字段映射

数据流向非常清晰：金蝶云星空作为源系统，通过 executeBillQuery 接口按单据编号增量拉取收料通知单；中间经过轻易云数据集成平台的转换层做清洗与映射；最后调用旺店通·旗舰版的 purchase.PurchaseOrder.createOrder 接口写入采购单。

源侧用 FDetailEntity_FEntryID 做表体行唯一性判断，目标侧则是 idCheck=true 配合接口幂等性保证「同号不重推」。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略落到一个集成任务下，配置要点有四个：

第一，源端取数。选择金蝶云星空的 executeBillQuery，把单据编号、单据状态、物料编码、收料组织、物料名称、业务日期等字段勾出来，过滤条件固定为「已审核」状态，避免把草稿推过去。

第二，编码映射集中管理。客户现场我们观察到最常见的翻车点是供应商编码、仓库编码在两边不一致。稳妥的做法是在轻易云的「映射表」里单独维护一套组织-仓库-供应商对照表，由业务方定期核对，而不是散落在每一次同步里硬编码。

第三，表头表体分阶段处理。第一阶段先把表头（采购单号、供应商、仓库、采购员、预计到货时间）落进旺店通，触达率稳定后再叠加物料明细行。这样出了问题能更快定位是表头写不进去，还是行项目被拒。

第四，目标端写回。调用 purchase.PurchaseOrder.createOrder，开启 idCheck，确保同一张收料通知单重跑不会重复创建采购单。

实施步骤

分阶段调度是这条策略能不能稳跑的关键。

第一步：增量起点。 以单据状态变更为「已审核」的时间作为增量游标，首次全量回灌时设定一个业务起点时间（例如月初或上线日），之后只拉新增和修改。

第二步：全量触发。 上线当晚用一次全量把历史未推送的数据补齐，便于业务侧一次性对账。

第三步：调度频率。 源端 crontab 配置为 5-59/10 7-22 * * *，也就是工作时段每 10 分钟一轮；目标端写库设置在 10-59/10 7-22 * * *，错峰 5 分钟执行，避免源端还没拉完就把同一批单据二次提交。两边错峰 5 分钟，是客户现场比较常见的应对模式。

第四步：补数与重跑。 提供按单据号手工触发的补数入口，遇到上游重审、字段调整时，单据级重推即可，不必全量重来。

踩坑复盘

第一，状态字段不过滤。典型错误是直接按 FDate 拉取，结果把草稿、作废单也推到了旺店通，导致大量无效采购单。稳妥的做法是源端 SQL 强制带上 FDocumentStatus='已审核'。

第二，仓库编码一对多。金蝶侧的收料组织和旺店通侧的仓库不是 1:1 的关系，尤其在多组织企业里，一个收料组织下挂多个实体仓。映射表必须支持多对多，不能写死成常量。

第三，日期格式不归一。金蝶返回的日期可能是带时间的，也可能是纯日期字符串。建议在中间层统一格式化，避免旺店通侧解析失败整单丢弃。

第四，幂等性只看单号不够。源端 FDetailEntity_FEntryID 才是行项目唯一键，只用 FBillNo 去重，重审后行项目变更会漏推。

第五，调度错峰不够。源、目标同分钟调度，源端数据还没落库，目标端已经在写库了。错峰 5 分钟是工程上非常划算的小投入。

适用场景与不适用场景

适用：金蝶云星空作为 ERP 主数据源、旺店通·旗舰版承担门店采购履约、收料与采购需要一一对应的供应链场景；单据体量在每天数千单以内的企业。不适用：采购单完全由旺店通侧发起、金蝶侧仅做财务核算的场景；以及需要实时秒级同步、对延迟极度敏感的业务流（建议走消息队列而不是定时拉取）。