泛微OA生产订单审批同步到金蝶云星空采购订单:一条策略的落地全过程

这个策略解决什么问题

某制造企业的流程是:车间在泛微OA里提生产订单,走完审批后才到金蝶云星空落成采购订单。早期靠人工把审批单号抄过去,结果 OA 审批撤回时两边对不上,财务每月底要花两三天对账。我们用轻易云数据集成平台做了一条单向同步策略:盯住 OA 审批节点的最终态,把通过的生产订单按既定编码规则映射成金蝶采购订单写入,撤回/驳回自动失效,替代人工录入。

数据流向与字段映射

整体链路是 泛微OA-E9(源) → 轻易云中间层 → 金蝶云星空(目标),数据流方向为 A → B。

供应商名称到编码的映射是这张表里最容易出问题的环节,需要在轻易云里集中维护一份「供应商映射表」,两边系统各自有编码体系,中间层做翻译,不要把翻译逻辑散在每条策略里——这是轻易云客户现场最常见的应对模式之一:编码映射集中管理。

在轻易云上如何配置

登录轻易云 Qeasy 控制台,新建一条「源系统集成流」,源端选泛微OA-E9 Http 适配器,目标端选金蝶云星空适配器。几个关键配置点:

• 触发方式选「事件触发」,绑定 OA 审批结束的回调入口,而不是轮询——审批是低频但强实时的业务,轮询既慢又压库。
• 在轻易云的「字段映射」节点里,把源表头和表体分两段配:表头先写,拿到金蝶返回的 FID 后再回填表体。这套「表头表体分阶段」写法在客户的供应商类单据同步里几乎是标配。
• 映射脚本里加一道兜底:源端 wfStatus 不是 PASS 就直接走终止分支,既不调用金蝶接口,也不留脏数据。
• 异常处理策略选「重试 3 次 + 告警通知」,不要静默吞错。

实施步骤

我们通常把这套策略的调度拆成三段:

1. 增量起点:历史数据先一次性全量补跑,把已经审批通过但还没推过金蝶的生产订单批量推送。这一步在轻易云里用「全量触发」按钮手动跑一次,带分页参数防止单次请求过大。
2. 全量兜底校验:全量跑完之后,立刻跑一个对账任务,拿 OA 终态 PASS 的单据和金蝶采购订单的 FBillNo 比对,差值清零才正式切流。
3. 调度频率:日常调度走事件触发即可,不需要 crontab;另外配一个每晚低峰的对账巡检,发现差值自动建工单。这一套「增量与全量双轨」是轻易云客户在跑生产类同步时的常见做法,既保证实时性,又有夜间兜底。

踩坑复盘

• 典型错误是直接把 OA 的单号当金蝶的 FBillNo。金蝶有它自己的单据编号规则,直接塞进去会导致后续按单号查询全部失效。稳妥的做法是中间层用 flow_id 做主键,让金蝶自己生成 FBillNo,再回写到中间层用于对账。
• 数量字段精度翻车。OA 是文本型,金蝶是 decimal,如果不归一化就会出现 100.0 vs 100.00 的伪差异。中间层加一步 qty_decimal 统一精度。
• 供应商编码忘了维护。新供应商在 OA 里能提交,但金蝶那边没建档,直接推过去会被驳回。建议在映射脚本里加一个「供应商编码不存在则跳过并告警」的分支,而不是让整张单失败。
• 审批撤回没处理。OA 端支持审批人撤回,但撤回事件不一定触发金蝶端反向操作。我们采用单向同步策略,撤回时在金蝶端把对应采购订单置为「作废」状态,而非物理删除,保留审计轨迹。
• 时区与日期格式。OA 的日期字段可能带时分秒甚至时区偏移,直接落库会让 FRequireDate 不准。中间层统一裁剪到 YYYY-MM-DD。

适用场景与不适用场景

适用:审批节点明确、终态清晰、上下游编码体系已稳定、容许单向写入的生产/采购类业务同步。不适用:需要双向协同编辑、审批流经常回退且要求金蝶端同步撤回、或者物料/供应商主数据尚未在两套系统对齐的项目——后一类建议先做基础资料同步,再做单据同步。