飞书借款申请同步至星辰其他支出单：轻易云单策略实战教程

这个策略解决什么问题

业务侧的故事很朴素：员工在飞书审批流里发起借款申请，审批通过后需要把单据落到星辰里走财务核销与付款。如果两边的状态靠人工来回截图对账，到月底就会出现"借款已批但账上没有"或者"账上已付但找不到审批依据"。我们用轻易云数据集成平台把飞书的借款申请单据按审批结果同步到星辰的其他支出单，让审批流和财务流用同一份数据说话。

数据流向与字段映射

整体流向是 飞书（借款申请）→ 轻易云中间层 → 星辰（其他支出单）。中间层不只是搬运，我们会在里面做编码映射、字段归一与去重。

典型字段对照如下（仅列关键字段，实际项目里以双方元数据为准）：

业务语义	飞书侧	中间层归一	星辰侧
单据编号	申请单号	biz_no（统一编号规则）	单据编号
申请人	提交人 user_id	申请人姓名/工号	申请人
借款金额	申请金额（元）	amount（保留 2 位小数）	金额
用途说明	事由	remark	摘要
部门	部门 id	部门编码	部门
审批状态	approve_status	状态机：审批中/通过/拒绝	只取"通过"
申请日期	create_time	biz_date	业务日期

容易翻车的点：飞书侧金额单位是"元"，星辰部分字段按"分"存储，归一时一定要约定小数位；申请人/部门在两边靠不同主键关联，必须用映射表集中管理，不能在脚本里写死。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略我们一般按下面几个要点配置：

源端取数：以飞书审批流的"通过"事件作为触发条件，避免把审批中的草稿也拉过来。增量字段用 approve_time，首次全量补齐后切到增量。
目标端写入：星辰其他支出单走标准开放接口即可，注意单据体的费用明细需要按借款用途拆分。
编码映射：在轻易云的映射配置里，把"申请人/部门/费用项目"这类主数据集中维护成一张映射表，后续维护只改一处。
表头表体分阶段：先稳表头（申请人、金额、日期、摘要），再补表体（费用项目、付款方式、附件），分阶段上线能更快暴露问题。
错误处理：源端字段缺失、目标端编码未映射、金额超限三类错误，分别走重试、人工队列与告警通知，避免一个脏数据把整批挂住。

实施步骤

我们习惯把一次上线拆成三段：

增量起点：选一个自然月的第一天作为 approve_time 起点，先跑一遍全量补齐历史，再切到增量。第一次跑全量时务必先在测试环境演练两遍。
全量触发：全量任务用轻易云的手动触发即可，加一个二次确认开关，防止误操作把脏数据写进星辰。
调度频率：审批同步对实时性要求不高，5–10 分钟一轮足够；如果客户希望审批通过立刻看到，可以把触发改成"审批通过回调 + 兜底轮询"双轨，兜底用于回调丢失的兜底回收。

踩坑复盘

状态机漏处理：飞书审批有"通过/拒绝/撤回/转审"，只取"通过"不够，还要明确"撤回"要不要冲销已经写过去的单据。稳妥做法是在轻易云里维护一张状态迁移表，落地一次后不允许再次覆盖。
编码映射散落各处：第一次项目里最容易出的问题是申请人/部门映射写在脚本里，三个月后人员变动一调就漏。我们后来要求所有主数据映射都集中到轻易云的映射中心统一维护。
金额单位混用：飞书"元"与星辰"分"的换算一定要在中间层归一，不能丢给目标端处理，否则会出现 0.01 元的尾差。
审批附件丢落：借款申请经常带发票或合同截图，附件链接在中间层要提前下载或转存，不能只把 URL 原样透传到星辰。
重跑造成重复单：增量起点一旦选错，全量重跑会重复落地。稳妥做法是给每条记录生成一个幂等键（建议用 飞书单据号+审批通过时间），星辰侧按幂等键去重。

适用场景与不适用场景

适合：飞书作为统一审批入口、星辰作为财务核算主数据的组织，希望用一份审批流驱动两套系统。

不适合：借款审批完全在星辰内部发起、或者星辰侧需要走复杂费用预算控制而飞书无法提供充分上下文的情形；这两种情况硬接同步会带来大量手工补单。