飞书审批→MySQL：日常付款申请单同步策略实战教程

这个策略解决什么问题

在某零售企业的财务共享中心，飞书审批承担了日常付款申请入口，但 ERP 与核算系统只认 MySQL 中结构化的付款单表。两边一旦对不上，月底对账就要逐单人工核对。我们用轻易云数据集成平台把这张单子从飞书拉到 MySQL，主键去重、付款类型按 ERP 编码落地、预算明细扁平化写入，业务侧只需要按一张视图对账。

数据流向与字段映射

数据流向：飞书审批 → MySQL 单表。源端是嵌套 JSON（主表 + 预算明细数组），目标端是扁平化的 tp_fs_daily_payment_application。关键字段对照：

源字段	目标字段	映射规则
serial_number	serial_number	原样
instance_code	instance_code	原样
widget17128167994660001_text	payment_type	CASE 映射付款类型文本为 ERP 编码
widget17586072778180001	application_payment_amount	原样
widget17576741086190001_text / widget17576741328350001_text	other_transaction_unit_code_name	COALESCE + SUBSTRING_INDEX 取下划线前编码
widget17576766148280001[0].*	budget_*	取预算明细数组首行扁平写入
end_time	end_time	0 占位为默认日期，否则毫秒转 datetime
bfn_num / status	bfn_num / status	原样

预算明细数组只取首行（索引 0），多行不展开。

在轻易云上如何配置

轻易云数据集成平台（Qeasy）里，这条策略是典型的「WebAPI 拉取 + SQL 批量写入」组合。

源端：选择飞书审批连接器，API 用 /open-apis/approval/v4/instances，approval_code 填死审批模板 ID，start_time/end_time 用 {{CURRENT_TIME}} 变量做增量窗口。
目标端：MySQL 连接器选 batchexecute，主键校验打开（idCheck: true），写入方式用 REPLACE INTO 实现 upsert，队列上限 200 条/批。
编码映射集中管理：付款类型文本→ERP 编码用 CASE 表达式直接落在字段映射里，不要分散到多份脚本里，便于一处改动、全链路生效——这是轻易云客户常见的应对模式之一。
表头表体分阶段：本策略因为目标端是单表扁平化，把预算明细首行直接拍到主表字段；如果未来要展开多行，建议先跑表头同步、再跑明细表单独入库，避免一次失败整批回滚。

实施步骤

增量起点：源端 crontab 默认按配置触发（1 1 1 1 1），第一次上线前手动指定 start_time 锚点，回灌历史单据；之后用 CURRENT_TIME 滚动窗口。
全量触发：在轻易云里手动执行一次全量回灌，观察目标表行数与飞书审批后台导出比对，差异应为零。
调度频率：目标端 crontab 设为 * * * * *（每分钟一次），源端拉取窗口对齐，确保审批状态变更能在 1–2 分钟内落库。
数据校验：抽取 3–5 个付款类型分别走一遍 CASE 分支，确认编码映射与金额来源（应付金额的实际分支逻辑）符合预期。
上线与监控：先灰度一个审批模板观察一周，再开放全部付款类型。

踩坑复盘

典型错误是直接把 widget 字段名当常量写死。飞书表单控件 ID 在表单调整时会变，稳妥的做法是在轻易云里把字段做成映射变量，便于一次性替换。
预算明细多行被忽略：源端是数组，目标端只取首行。如果财务侧实际需要逐行核算，必须改成独立明细表，而不是继续拍扁到主表——这是「表头表体分阶段」策略的典型应用场景。
end_time=0 的脏数据：审批未完成时 end_time 为 0，直接转 datetime 会得到 1970 年。需要在转换里加判断，0 占位成默认日期（如 1000-01-01 00:00:00），否则下游报表会按「远古单据」报错。
多源取一忘写 fallback：COALESCE 不写兜底值，全部为空时返回 NULL，目标端 NOT NULL 约束会直接失败。建议永远带一个 'fallback' 兜底字符串。
REPLACE INTO 的副作用：以主键 upsert 会覆盖整行，包括历史字段。增量场景下要确认目标表允许覆盖，或改成 INSERT ... ON DUPLICATE KEY UPDATE 只更新变化列。

适用场景与不适用场景

适用：飞书审批作为入口、目标侧是 MySQL 单表、只需要主表+预算明细首行做核算快照的场景。不适用：预算明细需要逐行独立核算、源端控件 ID 频繁变动且无版本管理、或目标端需要保留历史版本而非覆盖写入。