审批通过只是开始。真正决定项目成败的，是审批结果有没有变成业务系统里那条正确的记录。
一、为什么必须集成
只做审批不做落地，会得到两种典型后果：
- 审批完了，业务人员再去系统里手工录一遍，错漏与重复劳动都在这一步
- 两边数据不一致，财务按 OA 算、业务按系统算，对账时互相不认
集成的目标很明确：一次录入、全程流转、结果可核对。审批是流程，业务系统是账，两者必须闭环。
二、三种集成方式怎么选
| 方式 | 特点 | 适用 |
|---|---|---|
| API 直连（推荐） | 实时、可校验、可返回业务单号 | 两边都有开放接口，主流做法 |
| 中间表 / 数据库对接 | 实现快，耦合紧 | 老系统无接口，且能接受准实时 |
| 消息队列 | 解耦、可重试、削峰 | 多系统订阅同一事件，如"合同生效" |
中间表能不用就不用：它把两个系统的表结构绑死，任何一边升级都容易出问题。实在要用，也走只读视图 + 定时任务，别让两边同时写。
三、一致性：三个必须处理的场景
- 审批通过但业务系统调用失败：不能只弹个错误就结束。要有重试队列，并在 OA 侧标红提示"待落地"，允许人工重推。
- 业务系统已创建但 OA 未收到回执：业务侧要用审批单号做唯一键，重复推送直接返回原单号。
- 审批撤销或驳回：业务侧要能反向处理（作废草稿单），不能只处理"通过"。
核心原则：以审批单号为全局唯一键，所有接口幂等；任何一步失败都要能被发现并补齐。
四、权限与代理人
- OA 账号与业务系统账号做映射，避免"审批人是张三、业务操作人是李四"
- 代理人机制：请假期间代理审批，代理关系要有起止时间与日志
- 跨部门审批：按组织架构取上级，不要在流程里写死具体人名
- 敏感单据（付款、采购）加金额分级，超阈值自动加签
别把组织架构写进流程定义
人员一变动，几十条流程要改。用组织架构变量取审批人，人员调整时改组织即可。
五、上线与日常运维
- 灰度：先选一个部门或一类单据跑两周，再全量
- 对账：每天比对"OA 已通过单量"与"业务系统生成单量"，不一致就告警
- 监控：接口成功率、平均耗时、重试队列积压量
- 留痕：每次落地记录请求报文摘要，出了问题能还原
最后提醒：集成项目的范围要写清楚哪些单据、哪些字段、哪些反向场景。模糊的"全面打通"通常意味着无限返工。
#OA集成#审批流#系统集成#行业解决方案
