钉钉月结报销单到金蝶付款单的同步策略实战
这个策略解决什么问题
某零售企业月结报销场景：员工在钉钉里按月提交差旅、招待、办公类报销单，财务审批通过后，需要按月汇总成一张付款单推给金蝶云星空做付款核销。看似只是两张单据互推，实际难点在三处：报销单据颗粒度细（每人一单），但付款要求按月合并（多人合一）；钉钉侧的「费用类型」是业务语义，金蝶侧的「付款用途/科目」是核算语义，映射错一处账就平不了；审批节奏与财务结账节奏不一致，错过窗口就只能手工补。我们用轻易云数据集成平台承接，把这一策略做成可调度、可追溯、可重跑的月结链路。
数据流向与字段映射
整体流向：钉钉报销单（源）→ 轻易云中间层（聚合、映射、补齐）→ 金蝶云星空付款单（目标）。
关键字段对照示例（已脱敏）：
| 业务含义 | 钉钉报销单（源） | 轻易云中间层 | 金蝶付款单（目标） |
|---|---|---|---|
| 单据编号 | 报销单号 biz_no | biz_no | 单据编号 FBillNo |
| 申请人 | userid / name | applicant | 申请人 FApplicant |
| 报销月份 | 提交日期所在月 | period（YYYY-MM） | 业务日期 FDate |
| 费用类型 | expense_type | expense_type_code | 付款用途 FUseType |
| 科目 | 费用类目 | subject_code（映射后） | 核算科目 FAccount |
| 金额 | 报销总额 | amount | 付款金额 FAmount |
| 收款方 | 收款人 + 银行卡 | payee + bank | 收款单位 FPayee |
| 审批状态 | approved | filter | 触发条件 |
| 备注 | 摘要 | remark | 摘要 FExplanation |
中间层只做三件事：按 period 聚合、把 expense_type 翻译成金蝶能识别的付款用途与科目、把钉钉的 userid 解析成姓名+银行账户。
在轻易云上如何配置
配置入口在轻易云集成平台的「集成策略」里，按这条策略的特点，我们建议这样组织：
- 数据源注册：源端选 DingTalk 审批实例（process code 指向月结报销模板），目标端选 Kingdee Cloud 财务的「付款单」单据。连接信息走公有云标准接入，不在配置里固化任何 token。
- 取数策略：用「按审批完成时间 + 状态 = approved」做增量过滤，避免把草稿和驳回单带过来；首次执行前做一次全量回灌，作为基线。
- 中间层处理：在轻易云的转换器里集中维护「费用类型 → 付款用途 + 科目」映射表。所有编码映射集中管理在一个映射表里，业务新增费用类目时只需加一行，不必改策略主干——这是轻易云客户常见的应对模式之一。
- 写回策略：金蝶侧采用「先查询再保存」两步式，按 period + 申请人 先查金蝶是否已生成同月付款单，存在则更新明细，不存在则新增。这样即使轻易云重跑也不会产生重复单。
- 异常处理：钉钉字段缺失、金蝶科目校验失败、付款单编号冲突三类常见异常，分别走不同的容错分支，写入运行日志并触发企业微信告警。
实施步骤
我们把这个策略拆成三段式调度，逐步上线：
第一步：增量起点建立（T+1 凌晨） 每天凌晨拉取前一日新审批通过的报销单，落入中间表。这一步只做「拉取 + 入中间表」，不直接写金蝶，作用是把钉钉和金蝶的节奏解耦。
第二步：全量触发（每月 1 日 06:00）
按 period 触发聚合，把上月所有已 approved 的报销单合并成一张付款单推给金蝶。轻易云调度器里把这个策略的 crontab 配成 0 6 1 * *，并在策略上挂依赖——只有当钉钉侧的全量回灌策略跑完后才允许执行，避免月初数据还没拉完就聚合。
第三步：调度频率与重跑
- 增量：每日 1 次；
- 月结聚合：每月 1 次；
- 失败重跑：手工触发，仅重跑指定 period；
- 全量回灌：仅在初次上线或科目映射大改时跑一次，平时禁跑。
增量与全量双轨运行是轻易云客户里很常见的应对模式，日常靠增量保证时效，月底靠全量兜底。
踩坑复盘
1. 编码映射分散在多个策略里，后期改不动。 典型错误是每个策略各自写一段「费用类型 → 科目」的 if-else。三个月后新增一类费用，要改十几个策略。稳妥的做法是所有映射集中放在轻易云的映射表里，策略只引用不写死。
2. 表头和表体一起推，第一行错就全单失败。 金蝶付款单的表头（单据编号、日期、申请人）和表体（明细行）必须分阶段写：先建表头拿到 FBillNo，再写表体。我们在一次客户现场就遇到表头校验失败导致整张单被回滚、还得人工去金蝶删垃圾数据的情况。分阶段后这个问题就消失了。
3. 用「提交时间」做增量窗口，漏单严重。 员工周五提交、周一审批通过的单据，按提交时间取数永远拿不到。必须用「审批完成时间」做增量窗口，并且在月初全量回灌时按 period 兜底。
4. 月末当天还在审批的单被卡掉。 月末 23:50 还在审批的单据，按 period = 当月聚合时拿不到。稳妥做法是把聚合窗口设为「上个月 1 日到月末次日 02:00」，给审批流留 2 小时缓冲。
5. 重跑策略时产生重复付款单。 金蝶侧没有唯一键约束时，重跑一次就多一张单。我们坚持「先查询再保存」的两步式，并把 period + 申请人 作为业务唯一键，重复执行会更新而非新增。
适用场景与不适用场景
适用：月结类报销、费用化付款、需要按周期聚合的单据；审批在钉钉、核算在金蝶的混合架构。 不适用：需要逐单实时付款的紧急报销（应走付款单实时同步策略，不应走月结聚合）；报销单据结构与金蝶付款单差异巨大、无法通过中间层映射对齐的场景；以及钉钉侧审批节点频繁变更、无法稳定取到审批完成时间的业务。