钉钉审批修改后回写金蝶付款单：基于轻易云的增量更新策略实战

这个策略解决什么问题

在「付款申请单→钉钉审批→下推金蝶付款单」这条链路里，下推只是开始。审批节点上的业务人员常常会在审批结束后又回头修改货款属性、收款人、备注等表头信息，而金蝶侧付款单早已生成。如果每次修改都全量回写，既会冲掉原本的正确数据，又会让明细行跟着重算。这种「修改回写」场景需要一个只动表头三个字段、其余保持原状的增量更新策略。我们用轻易云数据集成平台（Qeasy）做这件事，效果稳定可控。

数据流向与字段映射

整体流向为：钉钉审批实例修改事件 → 轻易云中间层（拉取最新表单 + 联查定位目标 FID） → 金蝶云星空付款单（AP_PAYBILL）。

关键字段对照如下：

明细行不参与本策略映射，初次下推时由金蝶生成，本次不动。

在轻易云上如何配置

在 Qeasy 中新建策略，源端选择钉钉审批，目标端选择金蝶云星空付款单 AP_PAYBILL，操作类型为 BatchSave。需要重点确认四点：

1. 源端触发：用钉钉 topapi/processinstance/get 拉取最新审批实例，按 processInstanceId 过滤，确保拿到的是修改后的快照，而不是审批通过时的旧快照。
2. 联查定位：在中间层加一个 _findCollection 节点，引用「查询金蝶付款单（关联修改单据信息）all」方案，按 FBillNo 取出 FID。这一步是修改操作的前提，否则金蝶不知道改哪一条。
3. 枚举映射集中管理：轻易云客户常见的做法是把 货款属性→CP/FL 这种枚举映射抽到独立的映射表里维护，多个策略复用，避免每条策略各自写 case when。
4. 只更新指定字段：在目标操作里把 NeedUpDateFields 显式配置为 F_VAOJ_HKSX,FREMARK,FBillNo，其余字段一律不进 payload。IsAutoSubmitAndAudit 设为 false，因为表头字段调整后通常仍需财务复核。

实施步骤

我们在客户现场一般按下面三个阶段推进：

• 增量起点：先在金蝶里找一张已经存在的付款单作为锚点，用一条审批记录触发本策略，确认 FID 能正确联查到、三个字段能被覆盖写入。
• 全量触发：把过去一段时间内发生过修改的审批单批量回流，跑一次「全量补跑」，验证映射规则、备注拼接格式、枚举值在所有历史数据上都正确。全量阶段完成后切回增量。
• 调度频率：建议每 5–10 分钟轮询一次审批修改事件，财务非工作时间可适当拉长。轻易云平台支持按时间窗触发，也支持 Webhook 回调，按企业实际节奏选择。

踩坑复盘

1. business_id 不等于审批实例号。钉钉返回的 business_id 和 processInstanceId 不是一回事，直接用 processInstanceId 当 FBillNo 会导致所有付款单编号错位。稳妥做法是先从审批详情里把 business_id 单独取出来再映射。
2. 联查方案返回多条。如果同一单据编号在金蝶里被重复下推过，_findCollection 会一次性返回多条 FID，batchSave 直接报错。需要在联查之后加一个唯一性校验或排序取最大版本号。
3. NeedUpDateFields 漏配。典型错误是只写目标字段而不配置白名单，结果 batchSave 把整张单据都覆盖一遍，明细行被冲掉。配置时务必把 F_VAOJ_HKSX,FREMARK,FBillNo 三个字段写进白名单，其余保持不动。
4. 备注拼接顺序与分隔符。{{title}}-{{收款人}}-{{备注}} 看起来简单，但 title 本身可能自带连字符，导致后续按 - 拆分时混乱。建议固定分隔符，并在拼接前对 title 做一次简单清洗。
5. IsAutoSubmitAndAudit=true 引发复核失控。自动提交并审核后，财务无法在金蝶端拦截异常修改。建议保持 false，让修改回写停留在「保存」状态，由人工或下游策略决定是否审核。

适用场景与不适用场景

适用：审批通过后偶发修改表头信息、且明细行已稳定的付款单场景；需要保留财务复核环节的合规要求；企业已在用钉钉做审批、用金蝶做财务记账，希望两边数据最终一致。

不适用：需要修改明细行金额、币种、往来单位等影响核算结果的字段；审批单尚未下推生成付款单；目标系统不是金蝶云星空或不支持 batchSave 按字段白名单更新。