采购退料单提交审核：从 MySQL 到金蝶云星空的实战同步策略

这个策略解决什么问题

在某制造企业的供应链场景中，采购退料单在业务系统（MySQL 承载）流转并完成一级审核后，需要把已审单据推送到金蝶云星空做二次提交审核，驱动后续的库存退库与财务核算。看似只是「审一下」，但如果状态同步走错时序或编号对不齐，会导致星空端重复审核、库存错乱。本策略的核心价值在于：通过轻易云数据集成平台（Qeasy）建立一条「按状态过滤、定时巡检、批量提交」的稳定通道，让提交审核动作变成可观测、可重放、可追溯的工程化操作。

数据流向与字段映射

整体流向是单向 A→B：MySQL → 轻易云中间层 → 金蝶云星空。

源端（MySQL）只拉取「待提交审核」的退料单头表，筛选条件有两个：fdocumentstatus='C'（已审核）和 is_success<>'1'（尚未成功提交）。SQL 形如：

select fid as sourceid, FBillno as 单据编号
from kingdee_pur_mrb_head
where fdocumentstatus='C' and is_success<>'1'
limit :limit offset :offset

通过 :limit、:offset 做分页，避免一次拉太多。中间层把 单据编号 透传给目标端的目标调用。

目标端（金蝶云星空）调用的是 Audit 操作（PUR_MRB 表单），关键入参如下表：

稳妥起见，idCheck 建议保持开启，让金蝶侧校验单据状态，避免错单被误审。

在轻易云上如何配置

在轻易云平台里，这条策略由两个核心节点串起来：源端的查询节点（SELECT，WebAPI，POST 方法）+ 目标端的执行节点（Audit，EXECUTE，POST 方法）。

实操要点：

• 源节点：把上面的 SQL 填进「主 SQL 语句」，main_params 设成 1（占位参数）。autoFillResponse 打开，自动把 sourceid 和 单据编号 注入响应字段，省掉手写映射。
• 目标节点：FormId 写死 PUR_MRB；Numbers 字段用变量绑定源端的 {{单据编号}}，这一步千万别手填常量。
• 调度：源端 */7 * * * *，每 7 分钟巡检一次；目标端 */2 * * * *，更密集执行提交审核，保证积压快速消化。源稀目密，是处理「状态型任务」的常见模式。
• 结果回写：建议在中间层再加一步「回写成功标志」，把 is_success 更新成 1，否则下次巡检还会重复拉——这是后面要单独讲的踩坑重点。

实施步骤

我们一般把上线分成三段走：

阶段一：增量起点定位。 第一次跑全量，把历史所有 fdocumentstatus='C' and is_success<>'1' 的单据先压平。在中间层加个批次号字段，按创建时间升序分批执行，每批 200 条左右，避免金蝶侧并发限流。

阶段二：全量触发与回写验证。 全量跑完后，抽查 20 单到星空端核对审核状态；同时回看 MySQL 的 is_success 是否被正确置 1。轻易云客户常见的应对模式之一，就是把「编码映射 + 成功标志」集中管理在一个状态表里，后续策略直接复用。

阶段三：切换到增量调度。 启用上面那两个 cron。源端 7 分钟巡检，目标端 2 分钟执行；进入稳态后每日核对一次星空审核流水与 MySQL 状态表是否一致即可。

踩坑复盘

1. 回写标志忘了加，最常见。同一条退料单会被反复拉到目标端，金蝶返回成功后又重试，导致库存多次冲销。务必在中间层做完目标调用后立刻更新 is_success。
2. Numbers 与 Ids 二选一时不要混用。本策略靠单据编号定位，如果某天业务方改了编号规则，会全部失败。建议在源端先做一次编号格式校验再投递。
3. idCheck 关闭后风险陡增。关闭后即使单据已作废也会被提交审核，触发流程黑洞。第一次上线宁可慢一点，也把它打开。
4. 源端 SQL 不要带事务中未提交的数据。MySQL 那边如果有长事务，巡检会读到「已审但还没落库」的数据，传到金蝶会查不到。建议源端 SQL 加 FOR UPDATE 跳过或改为读已提交副本。
5. 调度间隔别拍脑袋。源端 7 分钟、目标端 2 分钟是经验值；如果单据量级是日均万单以上，目标端要降到 1 分钟甚至拆多实例并行。

适用场景与不适用场景

适用：单据状态机明确（已审 → 待提交审核 → 已审核）、需要从业务系统向 ERP 单向同步动作类操作、数据量在日均万单以内。 不适用：需要双向同步、源端状态会被金蝶回写覆盖的场景；以及单据体量极大、需要走异步队列削峰的场景，这类应改用事件驱动而不是定时巡检。