泛微OA采购订单审批同步至金蝶云星空的实战教程

这个策略解决什么问题

在不少企业的采购流程里,审批动作发生在泛微OA,但真正的订单执行与后续收货、付款都沉淀在金蝶云星空。我们常看到这样的场景:OA里审批人点完「同意」,采购员还要手动把订单头、行项目、单价数量再敲一遍进金蝶,稍不留神就出现两边数量对不上、供应商档案错位的情况。本策略要解决的就是:审批一通过,订单自动按既定口径写入金蝶云星空,头与体一次性落库,后续单据流转不再依赖人工重复录入。

数据流向与字段映射

整体流向是「源系统(泛微OA) → 中间层(轻易云数据集成平台,Qeasy) → 目标系统(金蝶云星空)」。

业务含义	泛微OA侧(源)	金蝶云星空侧(目标)	处理要点
订单编号	申请单号	单据编号	由金蝶生成,OA侧只做回写
供应商	供应商名称	供应商编码	走编码映射,集中管理
采购组织	申请部门	采购组织	按部门与组织对应表转换
物料编码	物料编号	物料编码	同供应商,集中映射
数量	申请数量	数量	单位需统一,避免「箱/个」混算
单价	参考价	含税/不含税单价	税别与税率一致后再落
审批状态	审批结果	仅取「已通过」	驳回与撤回不向下游推

补充几点容易漏掉的字段:交货日期、收料组织、付款条款、币别,这四个字段在OA审批流里往往只是辅助信息,但落到金蝶后直接影响后续收货与结算,务必显式映射,不要默认填空。

在轻易云上如何配置

我们在客户现场,通常建议在轻易云数据集成平台(Qeasy)里按"源资源库 → 目标资源库 → 策略编排"三段式落地。

源资源库:接入泛微OA-E9的HTTP接口,拉取审批完成的采购订单。常见做法是按审批流结束节点触发,而不是定时轮询,这样可以减少空跑。
目标资源库:接入金蝶云星空的采购订单保存接口,建议先在测试账套验证。
策略编排:这是最容易翻车的一段。典型配置包括:编码映射(供应商、物料集中维护在一张映射表里,后续所有策略复用)、表头表体分阶段(头先行,体按行号循环写入)、字段清洗(去空格、统一日期格式、税别归一)。

轻易云上比较省心的一点是:编码映射、字段转换规则都可以集中放在「映射中心」,新策略复用旧映射,避免每个策略各自一套规则,几个月后自己也看不懂。

实施步骤

我们通常把上线切成三段,而不是"一刀切全量上线":

第一阶段:增量起点对齐。先和业务方约定一个明确的起点时间(例如"今天零点之后审批通过的订单才同步"),把存量订单留在OA与金蝶各自的人工核对期,不在第一波里掺和历史数据。
第二阶段:全量触发开关。增量稳定运行一到两周后,开放全量触发,但只针对"审批通过但未写入金蝶"的订单补单。补单完成后立即关掉全量开关,回到只走增量的状态。这是「增量与全量双轨」的常见做法。
第三阶段:调度频率收敛。前期为兜底,可能每几分钟跑一次;稳定后,改成"OA审批结束节点触发 + 失败重试补偿"。轻易云本身支持失败自动重试,补偿策略不必自己写脚本。

调度频率没有标准答案,但有一条经验:不要依赖高频轮询去弥补业务侧的延迟,触发式比轮询式更省资源,也更贴近业务实际。

踩坑复盘

编码映射没集中管理,3个月后两边对不上。典型错误是每个策略各自维护一份供应商、物料映射表,某次只改了策略A的表,策略B还在用旧值。稳妥做法是在轻易云的映射中心统一维护,所有相关策略共用。
表头过了表体没过,出现"有头无体"的脏单。往往是循环写入体时遇到一条行项目报错,但表头已经落库。稳妥做法是"头体事务化"或至少在体写入失败时回滚头;在轻易云上可以通过"先暂存中间表、整体提交"的写法规避。
单位与税别没统一,数量对得上金额对不上。例如OA里单位是"箱",金蝶里是"只",审批时数量10,落库后变成10只,金额立刻翻几倍。稳妥做法是在字段清洗环节强制做单位换算,并把税别、税率与金蝶保持一致后再落库。
驳回与撤回的订单也被推了下去。原因是把"审批状态"字段当作过滤条件,但前端传的是最后一个节点的"同意",而不是整条流的最终结论。稳妥做法是取整流结束后的最终状态,而不是任一节点的局部状态。
失败重试没有上限,出现"幽灵重试"。订单明明已经在金蝶成功落库,但因为接口偶发超时,轻易云又重推了一次,产生重复单。稳妥做法是开启"按单据编号幂等"校验,重试前先查金蝶是否已存在。

适用场景与不适用场景

适用:采购审批在泛微OA、后续执行在金蝶云星空的企业;每天审批通过的订单量在两位数到三位数之间;有清晰的供应商与物料主数据。

不适用:审批流本身还需要在OA里长期跟踪的(此时仅做状态回写即可,不必把整张单推下去);以及供应商、物料主数据尚未在金蝶建档的情况,这种情形下应先跑主数据同步策略,再跑订单同步。