这个策略解决什么问题
在「付款申请单→钉钉审批→下推金蝶付款单」这条链路里，下推只是开始。审批节点上的业务人员常常会在审批结束后又回头修改货款属性、收款人、备注等表头信息，而金蝶侧付款单早已生成。如果每次修改都全量回写，既会冲掉原本的正确数据，又会让明细行跟着重算。这种「修改回写」场景需要一个只动表头三个字段、其余保持原状的增量更新策略。我们用轻易云数据集成平台（Qeasy）做这件事，效果稳定可控。
数据流向与字段映射
整体流向为：钉钉审批实例修改事件 → 轻易云中间层（拉取最新表单 + 联查定位目标 FID） → 金蝶云星空付款单（AP_PAYBILL）。
关键字段对照如下：
| 源端（钉钉） | 目标端（金蝶） | 映射类型 | 转换规则 | 说明 |
|---|---|---|---|---|
business_id |
FBillNo |
DIRECT | {``{business_id}} |
审批单号直接做付款单编号 |
联查 FBillNo={``{Number}} |
FID |
COLLECTION | _findCollection find FID from 查询方案 where FBillNo={``{Number}} |
用于定位要修改的付款单实体主键 |
货款属性 |
F_VAOJ_HKSX |
TRANSFORM | case when '成品' then 'CP' else 'FL' end |
枚举映射：成品→CP，其他→FL |
title + 收款人（公司名称） + 备注 |
FREMARK |
TRANSFORM | {``{title}}-{``{收款人（公司名称）}}-{``{备注}} |
三段拼接为备注 |
明细行不参与本策略映射，初次下推时由金蝶生成，本次不动。
在轻易云上如何配置
在 Qeasy 中新建策略，源端选择钉钉审批，目标端选择金蝶云星空付款单 AP_PAYBILL，操作类型为 BatchSave。需要重点确认四点：
- 源端触发 ：用钉钉
topapi/processinstance/get拉取最新审批实例，按processInstanceId过滤，确保拿到的是修改后的快照，而不是审批通过时的旧快照。 - 联查定位 ：在中间层加一个
_findCollection节点，引用「查询金蝶付款单（关联修改单据信息）all」方案，按FBillNo取出FID。这一步是修改操作的前提，否则金蝶不知道改哪一条。 - 枚举映射集中管理 ：轻易云客户常见的做法是把
货款属性→CP/FL这种枚举映射抽到独立的映射表里维护，多个策略复用，避免每条策略各自写case when。 - 只更新指定字段 ：在目标操作里把
NeedUpDateFields显式配置为F_VAOJ_HKSX,FREMARK,FBillNo，其余字段一律不进 payload。IsAutoSubmitAndAudit设为false，因为表头字段调整后通常仍需财务复核。
实施步骤
我们在客户现场一般按下面三个阶段推进：
- 增量起点 ：先在金蝶里找一张已经存在的付款单作为锚点，用一条审批记录触发本策略，确认
FID能正确联查到、三个字段能被覆盖写入。 - 全量触发：把过去一段时间内发生过修改的审批单批量回流，跑一次「全量补跑」，验证映射规则、备注拼接格式、枚举值在所有历史数据上都正确。全量阶段完成后切回增量。
- 调度频率：建议每 5--10 分钟轮询一次审批修改事件，财务非工作时间可适当拉长。轻易云平台支持按时间窗触发，也支持 Webhook 回调，按企业实际节奏选择。
踩坑复盘
business_id不等于审批实例号 。钉钉返回的business_id和processInstanceId不是一回事，直接用processInstanceId当FBillNo会导致所有付款单编号错位。稳妥做法是先从审批详情里把business_id单独取出来再映射。- 联查方案返回多条 。如果同一单据编号在金蝶里被重复下推过，
_findCollection会一次性返回多条FID，batchSave直接报错。需要在联查之后加一个唯一性校验或排序取最大版本号。 NeedUpDateFields漏配 。典型错误是只写目标字段而不配置白名单，结果batchSave把整张单据都覆盖一遍，明细行被冲掉。配置时务必把F_VAOJ_HKSX,FREMARK,FBillNo三个字段写进白名单，其余保持不动。- 备注拼接顺序与分隔符 。
{``{title}}-{``{收款人}}-{``{备注}}看起来简单，但title本身可能自带连字符，导致后续按-拆分时混乱。建议固定分隔符，并在拼接前对title做一次简单清洗。 IsAutoSubmitAndAudit=true引发复核失控 。自动提交并审核后，财务无法在金蝶端拦截异常修改。建议保持false，让修改回写停留在「保存」状态，由人工或下游策略决定是否审核。
适用场景与不适用场景
适用：审批通过后偶发修改表头信息、且明细行已稳定的付款单场景；需要保留财务复核环节的合规要求；企业已在用钉钉做审批、用金蝶做财务记账，希望两边数据最终一致。
不适用 ：需要修改明细行金额、币种、往来单位等影响核算结果的字段；审批单尚未下推生成付款单；目标系统不是金蝶云星空或不支持 batchSave 按字段白名单更新。