金蝶云星辰与飞书供应链集成方案：16条策略打通采购、销售与财务审批闭环

场景与价值

在中大型企业的日常经营中,采购、销售与费用报销通常同时涉及 ERP 系统与移动审批平台。金蝶云星辰承担业务单据与财务凭证的落库职责,飞书则承担审批流、人员与部门等组织资料的承载职责。两者若各自孤立,会出现以下典型问题:业务人员在 ERP 中发起采购订单后,需要切换到飞书手工填写审批单;审批流结束后,审批结果需要人工回到 ERP 执行审核操作;供应商、员工、费用项目等主数据在两端维护不一致,导致编码冲突或挂账失败。

本方案以轻易云数据集成平台为枢纽,在金蝶云星辰与飞书之间构建 16 条同步策略,覆盖基础资料、采购订单、销售订单、财务单据与其他支出五大业务域。价值体现在三点:第一,业务单据发起后自动流转至飞书审批,审批通过后自动回写 ERP 完成审核,减少人工搬运;第二,人员、部门、供应商、费用项目等编码在平台集线器中统一缓存与映射,避免跨系统主数据漂移;第三,所有策略具备重试、幂等、补偿与告警能力,可在公有云环境稳定运行。

集成架构与数据流

方案的整体架构以金蝶云星辰、飞书、轻易云集成平台三者构成,数据流分为三个方向:

第一,星辰 → 飞书(共 4 条策略)。星辰采购订单、销售订单、预付款单、付款单经策略 3、6、10、11 同步至飞书,生成对应审批实例。同步过程中,平台会从「获取飞书人员」集线器中按 creator_name 联查 user_id,并把星辰单据编码 bill_no / billno 回写到飞书审批表单的 form6 字段,供后续审核策略读取。

第二,飞书 → 星辰(共 10 条策略)。飞书审批通过后,策略 4、5、12 调用星辰审核接口 /jdy/v2/sys/common_operate 完成采购订单、销售订单、预付款单与付款单的审核操作;策略 7、8、9、13、14、15、16 则将预付申请、付款申请、差旅费报销、日常费报、借款申请、借款核销、预付冲销等单据同步为星辰预付款单或其他支出单。这些策略普遍依赖「查询星辰供应商」「查询星辰员工」「查询星辰费用项目」等集线器按名称联查主数据 ID。

第三,飞书 → 集成平台集线器(共 2 条策略)。策略 1、2 每日凌晨调用飞书开放接口,把人员与部门缓存到平台集线器,供所有依赖 user_id 与部门归属的策略联查使用。

策略之间存在明确的执行依赖:策略 1、2 必须先于采购订单、销售订单、支付货款等策略运行;策略 3、6、10、11 必须先于其对应的审核策略运行;财务类策略依赖供应商、员工、费用项目集线器。

接口清单

实施要点

字段映射与编码规则。采购订单、销售订单、采购/销售订单审核等策略的主表字段以直接传递为主,关键字段是发起人 user_id(COLLECTION 联查飞书人员集线器)与单据编码 bill_no(DIRECT,回写至飞书 form6 供下游审核定位)。预付申请、付款申请、差旅费报销等财务类策略使用 TRANSFORM 转换:日期经 datetime 过滤器标准化,单据编码按业务前缀拼接(YFSQ-、FKSQ-、CLFBX-、RCFB-、JKSQ-、JKHX-、YFCX-),供应商 ID 按名称联查。支付货款审核策略 12 通过 form6 单据编码前缀判断 entity_number(YFKD%→ap_prepaybill,其余→ap_paybill),再调用 common_operate 完成审核。明细行普遍使用 ARRAY 数组映射,把飞书明细控件整组写入星辰 pay_entry_list 或物料明细表。

主数据前置。所有依赖 user_id 与部门归属的策略都必须在策略 1、2 首次执行完成后再启用,否则会出现发起人无法匹配、单据挂在默认审批人名下的问题。供应商、员工、费用项目等主数据需在星辰侧先行维护,平台仅做按名查 ID 的联查,不维护新的主数据。

异常处理。网络超时采用指数退避(5s/15s/45s,共 3 次),接口限流(429)等待 60s 后重试最多 2 次。单条失败不阻断整批,失败记录写入失败表,主键(serial_number、bill_no、billno)做幂等,重复推送走更新而非新增。联查无结果时记录缺失值并告警,不抛出阻断流程。

调度策略。基础资料策略(1、2)每日凌晨 3 2 * * * 执行一次;星辰 → 飞书的 4 条业务策略在 7-21 点按 1-59/2 节奏执行;飞书 → 星辰审核类策略在 7-22 点按 0-59/2 执行;飞书 → 星辰财务类策略覆盖至 23 点。首次部署或数据修复后按阶段执行全量对账,日常切换为基于 start_time、modify_time 的增量同步。

最佳实践

第一,把基础资料同步策略视为整个集成链路的「水龙头」。只要策略 1、2 出现异常,后续所有依赖 user_id 与部门的策略都会产生告警甚至失败,需要最先纳入监控告警面板。

第二,单据编码前缀必须在方案设计阶段就与业务侧约定一致。飞书侧的 form6 字段不仅是回显字段,更是策略 12 判断预付款单还是付款单的唯一依据;一旦中途修改前缀定义,需要重新评估历史未审核单据的处理方式。

第三,供应商、员工、费用项目等主数据由星辰作为唯一可信源,飞书仅传递名称。平台集线器只做按名查 ID 的缓存,不做双向维护,避免两端主数据漂移导致挂账失败。

第四,告警阈值建议按业务节奏设置:单次同步失败率超过 10% 触发警告,连续 3 次全部失败触发严重告警(优先排查凭证与接口变更),单策略连续 24 小时无成功记录触发提示(确认业务是否有新数据或增量条件是否合理)。

第五,所有凭证、密钥、组织 ID 在轻易云平台连接器中按租户隔离存储,严格遵循最小权限原则;方案文档与策略配置中不出现真实客户名称、公司名称、凭证、密钥等敏感信息。