金蝶付款申请单同步至钉钉供应商月结付款审批:实战配置教程
这个策略解决什么问题
供应商月结付款场景下,某制造企业的财务在金蝶云星空完成付款申请单审核后,还需要再到钉钉 OA 里手工发起一遍供应商月结付款审批。两边来回抄单,既慢又容易把金额抄错。这个策略做的就是:金蝶侧审核一过,自动在钉钉侧生成对应的月结付款审批单,把财务审批流和钉钉审批流在源头打通。我们在做客户现场时,通常会把它放在"金蝶云星空 × 钉钉"集成方案里,作为供应商主数据同步之后的下一道衔接。
数据流向与字段映射
整体流向是单向的:金蝶云星空(CN_PAYAPPLY)→ 轻易云数据集成平台(Qeasy)转换层 → 钉钉 OA 审批(topapi/processinstance/create)。金蝶侧通过 executeBillQuery 按审核日期 FApproveDate 增量拉取,平台负责把基础资料字段拆解出来,再组装成钉钉审批发起接口所需的请求体。
顶层参数中,process_code 是钉钉供应商月结付款审批模板的固定编码,直接以 CONSTANT 写入。originator_user_id 和 dept_id 是动态值,源端给的只是员工姓名(F_VAOJ_FQR),需要通过 _findCollection 从"钉钉通讯录→金蝶员工"集线器里把 user_id 和主部门 dept_id 查出来。
form_component_values 是钉钉审批流的表单控件数组,典型映射如下:
| 钉钉表单控件 | 源字段 | 映射类型 | 说明 |
|---|---|---|---|
| 单据编号 | FBillNo | DIRECT | 金蝶单据编号 |
| 往来单位/供应商 | FCONTACTUNIT.fname | DIRECT | 基础资料取 fname |
| 申请付款金额 | FAPPLYAMOUNTFOR_H | DIRECT | 表头本位币金额 |
| 应付金额 | FPAYAMOUNTFOR_H | DIRECT | 表头本位币金额 |
| 申请日期 | FDATE | DIRECT | 业务日期 |
| 期望付款日期 | FEXPECTPAYDATE | DIRECT | 预计付款日 |
| 到期日 | FENDDATE | DIRECT | 申请截止日 |
| 结算组织 | FSETTLEORGID.fname | DIRECT | 基础资料名称 |
| 付款组织 | FPAYORGID.fnumber | DIRECT | 组织编码 |
| 结算币别 | FSETTLECUR.Fnumber | DIRECT | 币别编码 |
| 单据类型 | FBILLTYPEID.fnumber | DIRECT | 单据类型编码 |
| 对方账户名称 | FEACHCCOUNTNAME | DIRECT | 收款方账户名 |
| 对方开户行 | FEACHBANKNAME | DIRECT | 收款方开户行 |
| 对方银行账号 | FEACHBANKACCOUNT | DIRECT | 收款方银行账号 |
| 备注 | FDescription / F_VAOJ_Remarks | DIRECT | 分录备注或扩展备注 |
| 源单编号 | FSRCBILLNO | DIRECT | 上游单据编号 |
映射类型上,轻易云里常见的四种都用到了:DIRECT 直传、CONSTANT 常量、COLLECTION 集线器联查,以及必要时用 TRANSFORM 表达式做兜底。
在轻易云上如何配置
在轻易云数据集成平台(Qeasy)里新建策略时,源端选金蝶云星空的 executeBillQuery,FormId 填 CN_PAYAPPLY,FilterString 写成 FApproveDate>='{{LAST_SYNC_TIME|dateTime}}',交给平台自动维护增量游标即可。目标端选钉钉的 topapi/processinstance/create,认证走钉钉开放平台的 AccessToken。
字段映射这一层,推荐用"编码映射集中管理"的做法:所有 _findCollection 查询都引用同一个"钉钉通讯录→金蝶员工"集线器,后续员工离职、调岗都只改一处,不会散落在多个策略里。form_component_values 这一坨控件,有两种实现路径:一是在平台 UI 控件列表里逐个绑定 source 字段;二是在"转换→后置脚本"里把单条记录构造成 details 数组,再赋给 form_component_values。后者在字段多、需要做格式规范化时更顺手。
实施步骤
我们做这类策略一般分三步走,顺序错了很容易返工:
- 先做基础数据,再做单据同步。钉钉通讯录→金蝶员工这条集线器要先跑稳,员工姓名、user_id、主部门这三样东西对得上,F_VAOJ_FQR 才能查到值。建议先全量刷一遍,再开增量。
- 增量起点对齐。金蝶侧第一次跑,把 LAST_SYNC_TIME 设到一个明确的时间点(比如系统上线日的前一天 23:59:59),避免把历史单据一股脑全推过去压垮钉钉审批流。
- 分阶段调度上线。源端 crontab 建议
*/7 9-22 * * *(工作时段每 7 分钟),目标端*/5 9-22 * * *(每 5 分钟),两段错开避免同一时刻挤压。先用影子模式跑两三天——金蝶单据确实生成,但钉钉侧只走"测试流程模板",确认字段、金额、收款方信息都对得上,再切到正式审批模板。
踩坑复盘
现场踩过的几个典型坑,值得提前避一避:
- FApproveDate 不是创建日期。增量过滤用错了字段是高频错误——按创建日期拉会漏掉"先创建、后审核"的单据,按审核日期才能保证"审核通过即同步"。
- 基础资料字段直接当字符串用。FCONTACTUNIT、FSETTLEORGID 这种是对象,不写 .fname / .fnumber 出来的是
[object Object],钉钉侧表单会直接显示异常。这是新手最常翻车的地方。 - leader_in_dept 是数组,不是单值。取主部门要写
leader_in_dept.0.dept_id,如果该员工没有主部门或属于根部门,要在转换层兜底传-1,否则钉钉会报"发起人部门不合法"。 - process_code 复制粘贴漏字符。钉钉模板的 process_code 是带连字符的 UUID 串,粘贴时漏一个字符审批就直接 404,这种错误非常隐蔽,务必从模板详情页复制,不要凭记忆手敲。
- form_component_values 控件 name 写错。钉钉表单控件的 name 是模板里定义的标识,跟中文标题不一样。控件 name 写错,值是传过去了,但钉钉侧表单里就是空的,排查时要回到钉钉模板设计器核对。
适用场景与不适用场景
适用:金蝶侧已有规范的付款申请单审核流程、钉钉侧需要按月结维度走 OA 审批、且供应商主数据已经完成双向同步的企业。 不适用:需要表体分录逐行审批的场景(本策略只搬运表头字段);金蝶与钉钉不在同一审批体系内的临时性同步;以及金蝶侧本身尚未稳定审核流,源数据频繁回退的情况。