飞书付款申请单到金蝶云星空付款单的同步实战：以日常付款申请单为例

这个策略解决什么问题

某零售企业的费用报销与日常付款走飞书审批，但财务记账在金蝶云星空。审批流结束后，业务部门希望审批结果自动变成金蝶里的付款单，避免人工二次录入。这一条策略就是把飞书侧「日常付款申请单」按单据类型拆分为日常费用付款、采购付款、工资税金付款等，再写入金蝶云星空。价值在于把审批和记账连成一条链，财务在月末对账时不再追着业务部门要单据。

数据流向与字段映射

数据从飞书审批实例流向金蝶云星空付款单，中间经过轻易云做字段重命名、组织/单据类型编码转换、表头表体拆分。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略属于「飞书 → 金蝶云星空」的 EXECUTE 写回链路。配置思路有四点：

1. 源端配置：源平台选飞书，API 用 /open-apis/approval/v4/instances，主键取 serial_number，autoFillResponse 打开后回包字段会被自动解析，省去手工建模。
2. 增量窗口：源端用 start_time / end_time 做时间窗拉取，建议绑定相对变量 {{CURRENT_TIME}}000，不要写死。
3. 目标端配置：目标平台选金蝶云星空，调用 batchSave，主键 FBillNo 走 idCheck，避免重复提交。
4. 集中管理编码映射：单据类型、组织、币别这一类「文本 → 编码」的转换，建议放在轻易云的「编码映射」集中维护，不要散落在每个字段表达式里，后续新增单据类型时改一处即可。

实施步骤

我们把这套同步拆成三段上线，节奏踩稳。

• 阶段一：增量起点核对。先在轻易云里跑一次「近 7 天数据回溯」，把飞书已审批通过且未生成付款单的申请单一次性补齐到金蝶。补齐脚本单独跑，不要和正式调度混用，避免脏数据混进日常。
• 阶段二：全量触发上线。核对无误后，把策略切换为正式调度，飞书侧用准实时轮询（分钟级）拉审批完成事件，金蝶侧用 batchSave 批量落库。
• 阶段三：调度频率与重跑机制。日常付款申请单建议 5–10 分钟一轮，夜间低峰再补一次全量兜底。轻易云侧配置失败重试 3 次，幂等键用 FBillNo，重复触发不会产生重复付款单。

踩坑复盘

1. 时间戳单位不一致。飞书返回毫秒，金蝶 FDATE 期望秒级字符串。这里直接 FROM_UNIXTIME(LEFT(...,10),'%Y-%m-%d %H:%i:%s')，错一个数量级就会日期整体偏移 40 多年。
2. 组织字段带后缀。飞书侧组织字段形如 xxx_编码，必须 SUBSTRING_INDEX(..., '_', 1) 取前段，否则金蝶侧会报「组织不存在」。
3. 单据类型分支没兜底。业务新增一种付款类型但 CASE WHEN 没覆盖，金蝶侧会按默认类型落库，造成科目错误。建议 ELSE 显式给一个默认类型，并配异常告警。
4. 表头表体一锅炖。飞书的明细组件是一个 JSON，金蝶侧需要拆成多条分录行。建议在轻易云里把表头表体分阶段处理：先落表头，再循环落表体，单独看每一步的日志。
5. idCheck 关闭导致重复。调试期关掉 idCheck 方便反复跑，但上线前一定要打开，否则网络抖动重试就会重复提交付款单，财务对账时非常麻烦。

适用场景与不适用场景

适用：审批在飞书、记账在金蝶云星空，且审批结果可以直接转成付款单主数据的中小型零售或服务企业；单据字段相对稳定，新增类型不频繁。 不适用：审批流里还有复杂的预算占用、合同核销前置逻辑，或者金蝶侧要求走工作流而非直接 EXECUTE 的场景；以及审批单据结构频繁改版、字段语义不稳定的早期业务。