轻易云
注册体验

金蝶付款申请单→钉钉供应商月结付款:单一策略同步实战教程

· 尹春锐· 集成方案库· 18 次浏览· 约 4 分钟读完
金蝶云星空钉钉泛微 OA付款申请单供应商主数据单一策略同步增量调度

这个策略解决什么问题

某零售企业的财务团队在使用金蝶云星空做供应商月结付款时,审核节点都在金蝶内部走完,但老板和业务负责人的签字必须在钉钉 OA 上完成。每次都是财务人员手工把单据编号、供应商、金额抄一遍到钉钉,既慢又容易出错。

我们用轻易云数据集成平台承接这件事:把金蝶里"审核通过"的付款申请单,按审核日期增量捞出来,自动在钉钉发起"供应商月结付款"审批流,实现财务审批与钉钉审批流的打通。

数据流向与字段映射

数据流向:金蝶云星空(CN_PAYAPPLY 付款申请单) → 轻易云中间层(转换 + 编码映射) → 钉钉 OA(topapi/processinstance/create 审批实例)。

关键字段对照表:

域目标字段(钉钉)源字段(金蝶)映射类型说明
顶层process_code固定常量 PROC-22EDF4E6-5CC9-4712-B9A3-34AEAF37B8ACCONSTANT供应商月结付款审批流程唯一码
顶层originator_user_id按 F_VAOJ_FQR 查 _findCollectionCOLLECTION姓名→钉钉 user_id
顶层dept_id按 F_VAOJ_FQR 查 leader_in_dept[0].dept_idCOLLECTION姓名→主部门 ID
表单单据编号FBillNoDIRECT金蝶单据编号
表单往来单位/供应商FCONTACTUNIT.fnameDIRECT基础资料取名称
表单申请付款金额FAPPLYAMOUNTFOR_HDIRECT表头本位币金额
表单应付金额FPAYAMOUNTFOR_HDIRECT表头应付金额
表单申请日期FDATEDIRECT业务日期
表单期望付款日期FEXPECTPAYDATEDIRECT预计付款日
表单结算组织FSETTLEORGID.fnameDIRECT基础资料名称
表单付款组织FPAYORGID.fnumberDIRECT编码
表单结算币别FSETTLECUR.FnumberDIRECT编码
表单单据类型FBILLTYPEID.fnumberDIRECT编码
表单对方账户名称FEACHCCOUNTNAMEDIRECT收款方账户
表单对方开户行FEACHBANKNAMEDIRECT收款方银行
表单对方银行账号FEACHBANKACCOUNTDIRECT收款方账号
表单备注FDescription / F_VAOJ_RemarksDIRECT分录或扩展备注

金蝶基础资料类字段都是对象结构,取值时要写 .fname 取名称、.fnumber 取编码,这是金蝶云星空的标准约定,新人最容易忽略。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略按"源 → 目标"两步配:

  1. 源端(QUERY):选金蝶云星空,接口 executeBillQuery,FormId 填 CN_PAYAPPLY,FilterString 写 FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' 实现按审核日期增量拉取。
  2. 目标端(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 分钟推一次),源端比目标端稍慢,可以避免堆积。

第三阶段:稳态运行

  • 跑一周后,看钉钉侧审批实例是否和金蝶单据一一对应,有无重复发起或漏发。
  • 表头先跑稳,表体(分录行)再分阶段接入,这是轻易云客户的常见节奏——一次只上一个变量,出问题好定位。

踩坑复盘

  1. dept_id 取不到值直接报错:典型错误是没考虑发起人属于根部门的情况。钉钉要求发起人所在部门,根部门要传 -1,稳妥的做法是在转换层加兜底:leader_in_dept 数组为空时,dept_id 落到 -1。
  2. _findCollection 联查命中多条:钉钉里偶尔会出现重名员工,按 name 查会返回多条,originator_user_id 拿到数组就报错。这里容易翻车,稳妥的做法是再加一个限定条件(比如工号或手机号后四位)做精确匹配。
  3. 金蝶基础资料忘了写 .fname:直接写 FSETTLEORGID,返回的是个对象不是字符串,传到钉钉表单里会变成 [object Object]。记住金蝶的约定:要名称写 .fname,要编码写 .fnumber。
  4. 增量起点写错字段:有人误把 FDATE(业务日期)当增量字段,结果一月份补录的单据全漏。增量必须按 FApproveDate(审核日期),因为业务日期可以补录,审核日期才代表"刚发生"。
  5. form_component_values 控件 name 写错:钉钉审批表单控件改名后,平台这边没同步,运行时钉钉返回"控件不存在"。稳妥的做法是把控件 name 也做成变量或参数化,改表单时只改一处。

适用场景与不适用场景

适用:金蝶云星空做 ERP、钉钉做 OA 审批,需要把已审核的单据自动推到钉钉走老板签字的场景;每月供应商月结付款、差旅报销、付款申请等审批流。

不适用:需要双向同步(钉钉审批结果回写金蝶)的场景——本策略只做单向发起,审批结果回写要走另一条策略;也不适用于金蝶里还没审核的单据,增量过滤用的是 FApproveDate,未审核的单据不会被拉取。

本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-kingdee-cloud-dingtalk-2294-nf65a3228-621d031b

评论