销售在CRM里提交了一个折扣申请，审批要流转到OA系统走部门经理审批，结果OA那边状态变了，CRM里还显示“审批中“——这种状态不一致的问题，根因在于跨系统流转的设计缺失。
一、接口规范：统一审批状态码体系
跨系统流转的第一步是统一状态语言。OA系统的审批状态通常包括“待审批““审批中““已通过““已驳回““已撤回“，而业务系统可能只认“处理中“和“已完成“。做API集成时，必须定义一套双方都遵守的状态映射表，而且要明确每个状态对应的可执行操作。比如“审批中“状态下，发起人是否还能撤回？两个系统的规则必须一致，否则就会出现数据矛盾。
判断标准：如果两个系统对同一状态的行为定义不同，以业务系统为准，OA系统做适配。因为业务系统的流程规则通常更贴近实际管理需求。
二、状态同步：推拉结合比单纯推送更可靠
很多OA集成方案采用事件推送做状态同步，但推送可能因为网络问题丢失。更稳妥的方案是推拉结合：OA审批状态变更时主动推送，同时业务系统每10分钟做一次全量状态拉取，兜底处理遗漏的推送。这个补偿机制的代价很小，但能把状态不一致的概率从5%降到0.1%以下。
具体实现上，推送接口要做幂等设计——同一个审批单的同一个状态变更，推送三次和推送一次的效果完全相同。用“审批单ID+状态码+时间戳“做唯一键去重就行。
三、异常补偿：设计回滚而非重试
跨系统审批流转遇到异常时，盲目重试可能造成数据混乱。比如OA审批已通过但CRM回写失败，这时候重试回写是合理的；但如果OA审批被驳回而CRM已经预占了库存，就需要设计补偿逻辑——释放预占库存而非重新提交审批。
落地建议：为每个跨系统审批流程画一张状态流转图，标注每个节点的正常路径和异常路径。异常路径上明确写清补偿动作：是回滚、是重试、还是转人工。这张图既是开发依据，也是后期排查问题的利器。
OA系统的API集成看起来是技术活，本质是业务流程的跨系统对齐。流程对齐了，接口对接就是水到渠成的事。