金蝶付款申请单→钉钉供应商月结付款:单一策略同步实战教程
金蝶云星空钉钉泛微 OA付款申请单供应商主数据单一策略同步增量调度
这个策略解决什么问题
某零售企业的财务团队在使用金蝶云星空做供应商月结付款时,审核节点都在金蝶内部走完,但老板和业务负责人的签字必须在钉钉 OA 上完成。每次都是财务人员手工把单据编号、供应商、金额抄一遍到钉钉,既慢又容易出错。
我们用轻易云数据集成平台承接这件事:把金蝶里"审核通过"的付款申请单,按审核日期增量捞出来,自动在钉钉发起"供应商月结付款"审批流,实现财务审批与钉钉审批流的打通。
数据流向与字段映射
数据流向:金蝶云星空(CN_PAYAPPLY 付款申请单) → 轻易云中间层(转换 + 编码映射) → 钉钉 OA(topapi/processinstance/create 审批实例)。
关键字段对照表:
| 域 | 目标字段(钉钉) | 源字段(金蝶) | 映射类型 | 说明 |
|---|---|---|---|---|
| 顶层 | process_code | 固定常量 PROC-22EDF4E6-5CC9-4712-B9A3-34AEAF37B8AC | CONSTANT | 供应商月结付款审批流程唯一码 |
| 顶层 | originator_user_id | 按 F_VAOJ_FQR 查 _findCollection | COLLECTION | 姓名→钉钉 user_id |
| 顶层 | dept_id | 按 F_VAOJ_FQR 查 leader_in_dept[0].dept_id | COLLECTION | 姓名→主部门 ID |
| 表单 | 单据编号 | FBillNo | DIRECT | 金蝶单据编号 |
| 表单 | 往来单位/供应商 | FCONTACTUNIT.fname | DIRECT | 基础资料取名称 |
| 表单 | 申请付款金额 | FAPPLYAMOUNTFOR_H | DIRECT | 表头本位币金额 |
| 表单 | 应付金额 | FPAYAMOUNTFOR_H | DIRECT | 表头应付金额 |
| 表单 | 申请日期 | FDATE | DIRECT | 业务日期 |
| 表单 | 期望付款日期 | FEXPECTPAYDATE | DIRECT | 预计付款日 |
| 表单 | 结算组织 | FSETTLEORGID.fname | DIRECT | 基础资料名称 |
| 表单 | 付款组织 | FPAYORGID.fnumber | DIRECT | 编码 |
| 表单 | 结算币别 | FSETTLECUR.Fnumber | DIRECT | 编码 |
| 表单 | 单据类型 | FBILLTYPEID.fnumber | DIRECT | 编码 |
| 表单 | 对方账户名称 | FEACHCCOUNTNAME | DIRECT | 收款方账户 |
| 表单 | 对方开户行 | FEACHBANKNAME | DIRECT | 收款方银行 |
| 表单 | 对方银行账号 | FEACHBANKACCOUNT | DIRECT | 收款方账号 |
| 表单 | 备注 | FDescription / F_VAOJ_Remarks | DIRECT | 分录或扩展备注 |
金蝶基础资料类字段都是对象结构,取值时要写 .fname 取名称、.fnumber 取编码,这是金蝶云星空的标准约定,新人最容易忽略。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略按"源 → 目标"两步配:
- 源端(QUERY):选金蝶云星空,接口
executeBillQuery,FormId 填CN_PAYAPPLY,FilterString 写FApproveDate>='{{LAST_SYNC_TIME|dateTime}}'实现按审核日期增量拉取。 - 目标端(EXECUTE):选钉钉 OA,接口
topapi/processinstance/create,四个顶层参数照表配,form_component_values通过 UI 映射或脚本构建成[{name, value}, ...]数组。
编码映射集中管理是轻易云客户常用的应对模式:把"姓名→user_id""姓名→dept_id"这两条联查统一放在集线器(策略"钉钉通讯录→金蝶员工")里维护,本策略只做引用,不重复维护字典。当钉钉那边有人离职或调岗,只需要刷新那一条策略,本策略自动跟上。
实施步骤
第一阶段:全量触发(首次上线)
- 在轻易云里手动触发一次全量拉取,FilterString 临时改成
FApproveDate>='2024-01-01',确认金蝶侧字段返回完整、钉钉侧审批流能正常发起。 - 全量跑完后,把
LAST_SYNC_TIME重置到当前时间。
第二阶段:增量起点
- 调度源端 crontab:
*/7 9-22 * * *(9:00–22:00 每 7 分钟拉一次),覆盖业务审核高峰,夜里停跑省资源。 - 调度目标端 crontab:
*/5 9-22 * * *(每 5 分钟推一次),源端比目标端稍慢,可以避免堆积。
第三阶段:稳态运行
- 跑一周后,看钉钉侧审批实例是否和金蝶单据一一对应,有无重复发起或漏发。
- 表头先跑稳,表体(分录行)再分阶段接入,这是轻易云客户的常见节奏——一次只上一个变量,出问题好定位。
踩坑复盘
- dept_id 取不到值直接报错:典型错误是没考虑发起人属于根部门的情况。钉钉要求发起人所在部门,根部门要传
-1,稳妥的做法是在转换层加兜底:leader_in_dept数组为空时,dept_id 落到-1。 - _findCollection 联查命中多条:钉钉里偶尔会出现重名员工,按
name查会返回多条,originator_user_id 拿到数组就报错。这里容易翻车,稳妥的做法是再加一个限定条件(比如工号或手机号后四位)做精确匹配。 - 金蝶基础资料忘了写
.fname:直接写FSETTLEORGID,返回的是个对象不是字符串,传到钉钉表单里会变成[object Object]。记住金蝶的约定:要名称写.fname,要编码写.fnumber。 - 增量起点写错字段:有人误把
FDATE(业务日期)当增量字段,结果一月份补录的单据全漏。增量必须按FApproveDate(审核日期),因为业务日期可以补录,审核日期才代表"刚发生"。 - form_component_values 控件 name 写错:钉钉审批表单控件改名后,平台这边没同步,运行时钉钉返回"控件不存在"。稳妥的做法是把控件 name 也做成变量或参数化,改表单时只改一处。
适用场景与不适用场景
适用:金蝶云星空做 ERP、钉钉做 OA 审批,需要把已审核的单据自动推到钉钉走老板签字的场景;每月供应商月结付款、差旅报销、付款申请等审批流。
不适用:需要双向同步(钉钉审批结果回写金蝶)的场景——本策略只做单向发起,审批结果回写要走另一条策略;也不适用于金蝶里还没审核的单据,增量过滤用的是 FApproveDate,未审核的单据不会被拉取。
本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-kingdee-cloud-dingtalk-2294-nf65a3228-621d031b