钉钉审批修改后回写金蝶付款单：单一策略实战教程

这个策略解决什么问题

在「金蝶付款申请单 → 钉钉审批 → 下推付款单」的链路里,经常会遇到一个让人头疼的场景:业务人员在钉钉端修改了审批单(比如货款属性从成品改成辅料,或者补充了备注),但金蝶侧已经下推生成的付款单还停留在旧值上,两边对不上,财务复核时一脸问号。我们这次要落地的「修改下推的付款单」策略,就是把钉钉审批环节的字段变更,增量回写到金蝶付款单的主表上,只更新我们关心的三个字段,其余字段保持不动。

数据流向与字段映射

数据流向比较干净:钉钉审批流程实例 → 轻易云中间层 → 金蝶云星空付款单(AP_PAYBILL)。

源端字段来自 topapi/processinstance/get 返回的审批实例,目标端是金蝶付款单的主表字段。关键字段映射如下:

源字段	目标字段	映射类型	转换规则
联查:`FBillNo={{Number}}`	`FID`	COLLECTION	`_findCollection find FID from <查询方案> where FBillNo={{Number}}`
`货款属性`	`F_VAOJ_HKSX`	TRANSFORM	`_function case '{{货款属性}}' when '成品' then 'CP' else 'FL' end`
`title` + `收款人(公司名称)` + `备注`	`FREMARK`	TRANSFORM	`{{title}}-{{收款人(公司名称)}}-{{备注}}`
`business_id`	`FBillNo`	DIRECT	`{{business_id}}`

这里有一个关键设计:FID 不是从源端直接拿到的,而是通过联查方案「查询金蝶付款单(关联修改单据信息)all」,按 FBillNo 反查回来的。因为金蝶 batchSave 修改接口必须传入 FID 才能定位到要更新的记录。

在轻易云上如何配置

我们用轻易云(Qeasy)承接这条策略,典型配置分四块:

源端采集器:钉钉审批触发器,监听到审批单修改事件后,调用 topapi/processinstance/get 把完整表单数据拉回来。注意 response 元数据里通常只显式声明了 business_id,实际执行时其他字段会从 extend 或表单控件里取。
中间层处理:用轻易云的「联查」节点配置 _findCollection,把 Number 当作 FBillNo 去另一个查询方案里捞 FID。这是整条策略最容易翻车的地方,后面踩坑复盘会展开讲。
字段映射:三个目标字段的映射按上表配,枚举转换用 _function 表达式,字符串拼接直接用模板语法即可。轻易云的编码映射支持集中管理,后续如果货款属性枚举增加(比如新增「包材」),改一处映射就能全部生效。
目标端写入:金蝶写入节点选 BatchSave,FormId=AP_PAYBILL,NeedUpDateFields 一定要填 F_VAOJ_HKSX,FREMARK,FBillNo——这是金蝶侧控制"只更新指定字段"的开关,留空会被识别为全量更新,明细行会被清空。

实施步骤

实施时我们通常按三阶段推进:

阶段一:增量起点对齐。先在轻易云上跑一次「查询金蝶付款单(关联修改单据信息)all」全量方案,把目标端已有付款单的 FBillNo → FID 映射缓存起来,确保联查节点首次执行就能命中。这步对历史已下推但从未跑过修改回写的付款单尤其重要。
阶段二:全量触发一次回写。上线当天,对最近一段时间内钉钉侧发生过修改的审批单,人工触发一次全量回写,核对金蝶侧 F_VAOJ_HKSX 和 FREMARK 是否与钉钉一致。这一步既是数据校验,也是对映射规则的回归测试。
阶段三:调度频率与触发器。日常运行阶段,推荐两种模式双轨:增量用钉钉审批修改事件实时触发(秒级),同时配一个兜底的定时任务(比如每 15 分钟跑一次,按审批最后修改时间过滤),防止事件漏触发造成数据漂移。

踩坑复盘

NeedUpDateFields 没填,明细被清空。最典型的翻车:工程师第一次配的时候图省事把这个参数留空,结果 BatchSave 被识别为"按完整模型更新",付款单原本的明细行被清空,财务当场炸锅。稳妥的做法是,永远显式列出本次要更新的字段,即使只更新一个字段也要写出来。
FID 联查返回多条。如果同一 FBillNo 在金蝶侧存在历史版本(比如作废重开过),联查可能返回多个 FID,后续 BatchSave 会报"目标记录不唯一"。处理方式是在联查节点后加一个去重+取最新的逻辑,或者在金蝶侧保证 FBillNo 的全局唯一性。
business_id 与 Number 错位。源端元数据只显式声明了 business_id,工程师习惯性直接把 business_id 同时当作 FBillNo 和联查条件 Number 用,大多数场景没问题,但在钉钉审批被复制或重发的边界场景下两者可能不一致,导致联查失败。建议两个字段分开取,联查条件用 Number,写入用 business_id。
枚举新增未同步。货款属性从"成品/辅料"扩到"成品/辅料/包材"后,如果映射规则只写 case 不留 else 默认值,新值写入金蝶会被拒绝。轻易云的编码映射支持集中管理,但前提是转换规则里保留 else 分支兜底,比如新枚举一律先映射为 FL,再人工复核。
IsAutoSubmitAndAudit=false 的取舍。本策略配置的是不自动提交并审核,这是有意为之——修改场景下需要财务人工把关,避免审批流程被绕过。但如果客户业务允许,且希望修改后立刻生效,可以改成 true,但务必和业务方对齐。

适用场景与不适用场景

适用:钉钉审批字段变更后需要回写金蝶,且只涉及主表字段的增量更新,明细行由金蝶系统独立维护的「审批 → 下推单据」回写场景。 不适用:明细行需要同步修改、跨组织/跨账套传递、或者金蝶侧需要重新走完整审批流的场景——这些需要更复杂的策略组合,不能套用本方案。