钉钉审批完成后下推金蝶付款单：单一策略实战教程

这个策略解决什么问题

在一次零售企业的财务集成项目里，客户反馈了一个很典型的痛点：付款申请单先从金蝶云星空同步到钉钉发起审批，审批通过后，业务人员还得手动回到金蝶做"下推付款单"的操作——一天几十张单据，每张都要重复点几次按钮，月末集中付款时更是累到崩溃。

这个策略解决的就是审批闭环的最后一公里：钉钉审批流程结束后，由集成层自动调用金蝶 Push 接口，把已审批的付款申请单（CN_PAYAPPLY）下推生成付款单（AP_PAYBILL）。集成侧只负责把"单据编号"等关键参数递过去，字段级转换由金蝶内部的下推规则自动完成。配合轻易云数据集成平台，整个过程不需要人工干预，财务从"申请→审批→付款"形成完整闭环。

数据流向与字段映射（源 → 中间层 → 目标）

整条链路的形态是审批事件 → 集成层 → 金蝶下推：

[钉钉审批流程实例] --topapi/processinstance/get--> [轻易云中间层] --Push--> [金蝶付款单 AP_PAYBILL]
       单据编号                                          下推参数装配                  (由金蝶内部规则生成)

关键字段对照表（这是这一策略的精髓，因为没有明细行映射，主表参数就是全部）：

需要特别强调的是：本策略没有明细行映射。付款单的明细行完全由金蝶根据付款申请单和默认转换规则在系统内部自动生成，集成侧不参与字段级转换。这也是它和普通单据同步策略最不一样的地方。

单据编号和status的来源在钉钉侧元数据里是空的，集成工程师需要结合上游策略推断——典型来源是 extend.business_id 或钉钉表单控件里存储金蝶 FBillNo 的字段。

在轻易云上如何配置

在轻易云数据集成平台上配置这条策略时，我们建议按"触发器 → 取数 → 映射 → 下推"四段式来组织：

1. 触发器：选择「钉钉审批流程完成」事件触发（或通过定时轮询 topapi/processinstance/get 拉取已完成的实例）。如果上游已经有事件推送机制，建议优先走事件触发，避免轮询带来延迟。
2. 取数节点：源端选 DingTalk 的 topapi/processinstance/get，传入流程实例 ID，把审批详情取回来。这里有个小细节：request/response 元数据为空时，平台需要手动维护一份"推断字段表"，方便后续维护时查阅。
3. 映射节点：本策略映射非常薄——只有 4 个有效参数（FormId、Numbers、Ids、TargetFormId 等都是常量或直接映射）。轻易云支持把常量集中管理在「编码映射中心」，FormId、TargetFormId、RuleId、IsEnableDefaultRule、IsDraftWhenSaveFail 这些常量建议集中存放，避免散落在多个策略里日后改不动。
4. 下推节点：目标端选 Kingdee 的 Push 操作，把装配好的参数 POST 过去。下推失败时由于 IsDraftWhenSaveFail=true，会在金蝶侧生成草稿单据，便于事后排查。

实施步骤

我们建议分三个阶段推进，避免一次性配置带来排查困难：

阶段一：增量起点（灰度期） 先在测试环境跑通单条下推链路。手动在钉钉发起一笔付款申请审批，审批完成后观察集成日志，确认 Numbers 被正确传递、金蝶侧是否成功下推并生成付款单。灰度期建议只放少量真实单据，便于人工对账。

阶段二：全量触发（并行期） 灰度稳定后，把触发器从"手动触发"切换为"审批完成事件触发"，让所有完成的审批都自动下推。这一阶段强烈建议开启增量与全量双轨：增量走实时事件保证时效，全量每天定时跑一次对账，补齐事件漏掉的单据。轻易云客户里这个模式用得最多，特别适合审批量大、不能容忍漏单的场景。

阶段三：稳定调度（运营期） 调度频率建议设为「事件触发 + 每日一次全量兜底」。事件触发保证分钟级时效，全量兜底保证 24 小时内一定能落单。同时配置好失败告警——下推失败通常意味着金蝶侧业务校验不通过（比如供应商未启用、付款申请单未审核），需要人工介入。

踩坑复盘

这一类"轻映射、重流程"的策略，看似简单，实际上踩坑点不少。我们整理了几条典型的：

1. 单据编号来源没对齐是头号翻车点。钉钉审批表单里如果不显式保存金蝶的 FBillNo，下推时 Numbers 就是空的，金蝶侧会直接报"单据不存在"。稳妥的做法是在上游策略"金蝶→钉钉发起审批"时，就约定好用一个固定的表单控件（比如 extend.business_id）存储 FBillNo，并写入文档规范里。
2. 下推失败的"静默草稿"容易掩盖问题。IsDraftWhenSaveFail=true 虽然友好，但太多草稿堆积后，财务根本不知道有单据没下推成功。建议在集成层做一层失败计数，连续失败超过阈值就发告警，而不是只看金蝶返回 200。
3. 审批驳回也会触发下推。钉钉审批被驳回时，如果不加判断直接下推，金蝶会报错。稳妥的做法是在触发器里加一层"仅审批通过才下推"的过滤，或者在映射前用脚本判断 status。
4. 同一单据被多次下推会生成重复付款单。钉钉审批完成事件可能因为网络重试触发多次，集成侧必须做幂等——轻易云里通常用 id 作为幂等键，写入前先查一下是否已经下推过。
5. 金蝶下推规则被运维改过没通知。这条策略依赖金蝶内部的"付款申请单→付款单"默认转换规则，如果财务或运维调整了规则（比如改了默认收款科目），集成侧不需要改代码，但必须在变更通告里同步过来，否则两边对账会对不上。

适用场景与不适用场景

适用场景：上游是金蝶云星空付款申请单、中间经过钉钉（或类似 OA）审批、审批完成后需要回到金蝶落付款单的财务闭环场景；单据量适中、审批流稳定、对幂等性要求高的环境。

不适用场景：付款单需要在审批流中追加自定义字段的场景（本策略无法干预明细行映射）；审批驳回或转交时也需要触发金蝶动作的复杂流程；金蝶侧未启用单据转换规则的环境。