这个策略解决什么问题
很多企业的报销审批跑在钉钉里,但财务核算与资金支付在金蝶云星空。审批结束后,财务人员每周要把同一批报销单重新录入金蝶生成付款单------重复劳动、漏单、对不上账是常态。我们这次要落地的一条策略:钉钉端"月结贷款"类报销单审批完成后,自动把付款信息推到金蝶生成付款单,直接进入财务待付款池。
数据流向与字段映射
整体流向:钉钉(报销单) → 轻易云(Qeasy)中间层 → 金蝶云星空(付款单)。
源端只取钉钉审批流通过且结算方式为"月结贷款"的报销单;目标端写入金蝶付款单,组织按业务实体分别落到对应的财务账套下。
| 维度 | 钉钉报销单 | 轻易云中间层 | 金蝶付款单 |
|---|---|---|---|
| 单据编号 | 报销单号 | 报销单号(原值透传) | 单据编号(同源) |
| 申请人 | 员工姓名 | 申请人 + 工号编码 | 收款人/申请人 |
| 结算方式 | 月结贷款 | 月结贷款(过滤条件) | 付款方式 |
| 业务实体 | 部门 | 部门编码映射后落账套 | 付款组织 |
| 金额合计 | 申请金额 | 申请金额 + 币别 | 付款金额 |
| 摘要 | 事由 | 事由 + 单据来源标记 | 摘要 |
编码映射是这条策略的命门------员工、部门、供应商三类编码都要在轻易云里集中维护,源端过来后做一次映射转换,否则两边数字对不齐,3 个月后业务就找上门了。
在轻易云上如何配置
源端用钉钉开放平台的审批实例接口,按审批状态和结算方式过滤;目标端调金蝶云星空的付款单保存接口。
几个典型配置点:
- 过滤条件:审批结果 = 通过,且结算方式 = 月结贷款;不满足的直接跳过。
- 映射器:员工编码、部门编码、供应商编码三类映射集中放在轻易云的映射表里,运行时只查不写,方便业务侧维护。
- 幂等控制:用钉钉报销单号作为外部单据号,目标端启用重复校验,同一单号二次推送直接报错拦截。
- 异常分支:落账套失败、编码映射缺失、金额异常三类常见问题分流到不同告警通道,便于值班快速定位。
实施步骤
我们按"先全量兜底,再增量常态化"的节奏分三步走:
- 全量触发阶段。一次性回填近 90 天的月结贷款报销单,用于初始化金蝶付款单历史数据。这一轮只跑一次,完成后关闭,避免重复。
- 增量起点设置。以全量跑批的截止时间为起点,启用按审批完成时间增量拉取。
- 调度频率。生产环境按小时调度,每小时拉取一次增量;对账类任务单独按日终运行,核对当日生成的付款单是否齐全。
编码映射先行、过滤条件优先、幂等键提前规划,这三件事做扎实,后面运维压力会小一个量级。
踩坑复盘
- 编码映射散落在多个策略里。早期我们把映射直接写死在策略脚本,后来业务调整部门,改一个部门得改十几处。稳妥做法是集中放到轻易云的映射表,一次修改全局生效------这也是轻易云客户常见的应对模式。
- 忽略月结贷款的过滤条件。如果不过滤结算方式,所有报销单都会进金蝶,导致重复支付。这里容易翻车,务必把过滤条件放在源端拉取的第一道关卡。
- 幂等键设计不足。钉钉报销单号是天然的幂等键,但如果单据允许修改,要注意以最终版本为准,否则会出现"老版本覆盖新版本"。
- 账套路由不显式化。不同业务实体的付款单要落到不同账套,必须在中间层显式路由,不能依赖默认逻辑,否则月底对账一定乱。
- 告警未分级。编码缺失和金额异常混在同一个告警通道,值班人员容易被噪音淹没。建议在轻易云上为不同异常类型配置独立的告警通道。
适用场景与不适用场景
适用 :报销审批在钉钉、财务核算在金蝶云星空,且存在月结/批量结算业务的企业。 不适用:需要逐张人工复核的报销场景、对账精度要求极高的资金业务,以及钉钉与金蝶不同版本兼容有差异的环境。