金蝶付款申请单同步钉钉供应商月结付款:轻易云单策略实战教程
这个策略解决什么问题
某制造企业财务在金蝶云星空审核完一张供应商月结付款申请单后,还要在钉钉里手动建一遍月结付款审批——金额、供应商、银行账户全是手动抄写,月底 200 多张单子要抄到半夜,抄错一次就退回重走流程。我们要解决的,就是把「金蝶已审核 → 钉钉发起审批」这段完全自动跑起来,避免人为抄录与延迟。
数据流向与字段映射
整体流向是单向的:金蝶云星空 CN_PAYAPPLY(付款申请单)→ 轻易云数据集成平台 → 钉钉 topapi/processinstance/create(OA 审批发起)。金蝶侧通过 executeBillQuery 拉取已审核数据,中间层做转换,钉钉侧拿到的是一份完整的审批实例请求体。
关键字段对照(DIRECT 表示直接取值,CONSTANT 表示常量,COLLECTION 表示联查):
| 目标端字段(钉钉) | 源端字段(金蝶) | 映射类型 | 说明 |
|---|---|---|---|
| process_code | PROC-22EDF4E6-5CC9-4712-B9A3-34AEAF37B8AC | CONSTANT | 供应商月结付款审批流程唯一码 |
| originator_user_id | F_VAOJ_FQR(发起人姓名) | COLLECTION | 联查「钉钉通讯录→金蝶员工」集线器,按 name 取 user_id |
| dept_id | F_VAOJ_FQR(发起人姓名) | COLLECTION | 同集线器取 leader_in_dept.0.dept_id |
| 单据编号 | FBillNo | DIRECT | 金蝶单据编号 |
| 往来单位/供应商 | FCONTACTUNIT.fname | DIRECT | 取名称属性 |
| 申请付款金额 | FAPPLYAMOUNTFOR_H | DIRECT | 表头申请付款金额(本位币) |
| 应付金额 | FPAYAMOUNTFOR_H | DIRECT | 表头应付金额 |
| 申请日期 | FDATE | DIRECT | 业务日期 |
| 期望付款日期 | FEXPECTPAYDATE | DIRECT | 预计付款日期 |
| 到期日 | FENDDATE | DIRECT | 申请截止日期 |
| 结算组织 | FSETTLEORGID.fname | DIRECT | 基础资料取名称 |
| 付款组织 | FPAYORGID.fnumber | DIRECT | 基础资料取编码 |
| 申请组织 | FAPPLYORGID.fnumber | DIRECT | 基础资料取编码 |
| 结算币别 | FSETTLECUR.Fnumber | DIRECT | 基础资料取编码 |
| 单据类型 | FBILLTYPEID.fnumber | DIRECT | 基础资料取编码 |
| 备注 | FDescription / F_VAOJ_Remarks | DIRECT | 备注或扩展备注 |
| 货款属性 | F_VAOJ_HKSX | DIRECT | 扩展字段 |
| 源单编号 | FSRCBILLNO | DIRECT | 上游单据号 |
| 对方账户名称 | FEACHCCOUNTNAME | DIRECT | 收款方账户名 |
| 对方开户行 | FEACHBANKNAME | DIRECT | 收款方银行名 |
| 对方银行账号 | FEACHBANKACCOUNT | DIRECT | 收款方银行账号 |
金蝶云星空的基础资料字段取值时要带子属性(如 .fname 取名称、.fnumber 取编码、Fnumber 取币别编码),这一点是新人最常踩的坑,下文会再强调。
在轻易云上如何配置
我们在客户现场基本都这么做:先把源端和目标端接口分别落到轻易云的「数据源」里——源端填金蝶云星空的账套授权信息和 executeBillQuery 的 FormId(CN_PAYAPPLY),目标端填钉钉开放平台的 AppKey/AppSecret 与 topapi/processinstance/create。
接下来在策略画布里分三层处理:
- 源端拉数:FilterString 设为
FApproveDate>='{{LAST_SYNC_TIME|dateTime}}',按审核日期增量;调度配*/7 9-22 * * *。 - 中间层映射:把金蝶响应里的表头字段按上表一对一映射到钉钉审批发起参数。钉钉顶层 4 个参数里,
process_code直接写常量;originator_user_id和dept_id用_findCollection从「钉钉通讯录→金蝶员工」集线器里查;form_component_values在平台 UI 里逐个控件配置。 - 目标端推送:请求体走 EXECUTE 类型 POST,调度配
*/5 9-22 * * *,比源端略快一点把队列消化掉。
编码映射这一块,轻易云客户常见的应对模式是「编码映射集中管理」——把钉钉 user_id、部门 ID 之类的映射都收敛到「钉钉通讯录→金蝶员工」那个集线器策略里,本策略只引用,不重复拉数,这样上游通讯录变了,下游所有引用方自动同步,不用改一堆策略。
实施步骤
我们在客户现场基本分三阶段推进:
第一阶段:增量起点确认。 第一次上线先明确 LAST_SYNC_TIME 从哪个时刻起算。通常做法是在金蝶里查一条最近已审核的付款申请单,把它的 FApproveDate 作为起点,避免一上来就把历史数据全拉一遍。建议直接把这个时间点写进策略变量里做「冷启动」,跑通后再切换为正常增量。
第二阶段:全量触发验证。 冷启动完成、确认中间层映射没问题后,再单独跑一次全量——把 FilterString 改成时间区间或留空(视金蝶接口是否支持),拉一段历史数据批量推到钉钉。这一步主要是校验大批量下编码联查的命中率、银行账号字段是否截断、金额精度是否丢失。
第三阶段:分阶段调度上线。 源端 */7 9-22 * * * 拉数,目标端 */5 9-22 * * * 推送,两者错开避免「边拉边推」的并发冲突。轻易云客户常见的另一个模式是「表头表体分阶段」——本策略先只推表头(因为钉钉月结付款审批本身就是表头单),后续若要扩展到表体行项目,再开第二条策略,避免一次改动把表头表体全带翻。
跑稳之后再切到「增量与全量双轨」:每 7 分钟增量日常跑,每月 1 号凌晨触发一次全量校对,把漏单的兜底补回来。
踩坑复盘
- 基础资料忘了带子属性。 典型错误是直接把
FSETTLEORGID整个对象往钉钉字段里塞,结果钉钉那边收到一个 JSON 串,审批流打不开。稳妥做法是金蝶的基础资料类字段统一取.fname或.fnumber,具体取哪个看钉钉表单控件是文本还是下拉。 _findCollection取leader_in_dept漏了兜底。 钉钉通讯录里有人没挂部门,或者主部门就是根部门时,leader_in_dept.0.dept_id可能为空或不存在,钉钉接口会直接报错。这里容易翻车——我们通常在转换层加一行兜底,空值就传-1(钉钉约定的根部门 ID),别让单子卡在发起人 ID 这一步。- 增量起点选错字段。 用
FDATE(业务日期)做增量是错的,因为业务日期早于审核日期、且会被反审修改;应该用FApproveDate,且按服务器时间严格大于上一次同步时间,不能用「大于等于」(否则同一时刻的边界单会漏)。 form_component_values控件名对不上。 钉钉审批流的表单控件name是审批流模板里写死的,金蝶那边叫「申请付款金额」,钉钉那边可能叫「付款金额」——配错一个就整张审批表单字段为空。在配置前我们一定会先把钉钉审批模板的控件 JSON 导出来逐个对一遍名字。
适用场景与不适用场景
适用:金蝶云星空已有付款申请单作为唯一审批源、希望用钉钉 OA 跑月结付款审批、且钉钉侧只需要表头信息的场景。不适用:需要在钉钉里维护分录行项目明细(如多笔付款明细合并)、或者钉钉侧审批流控件与金蝶字段无法一一对应的场景——后者建议改用主数据预生成 + 审批触发分策略组合。