采购订单同步：MySQL 到金蝶云星空的单策略实战教程

这个策略解决什么问题

在制造业的供应链链条里，采购订单常常要同时落在车间 MES 侧的 MySQL 业务库与金蝶云星空的财务库存侧。两边系统关注点不同：MES 关心订单的可执行性，星空关心财务与库存入账。看似只是同步一张单，但只要编码口径、单据状态、回写时机任一处不一致，3 个月后对账就会发现数量、价格、供应商都对不齐。

这条策略的核心目标是：把 MySQL 中已生效的采购订单按增量方式推入金蝶云星空，并在目标端完成审核入账后，把星空返回的结果号、状态、消息回写到 MySQL 源端接口表，形成闭环。下面展开。

数据流向与字段映射

整条策略是「MySQL → 轻易云 → 金蝶云星空 → 轻易云 → MySQL」的双向闭环，中间所有进出都经过轻易云作为承载。

这里要特别说一句：物料编码、供应商编码、部门的跨系统映射，轻易云上常见的做法是「编码映射集中管理」——把映射表维护在一处，统一引用，避免散落在多个策略里三个月后谁也改不动。

在轻易云上如何配置

一次实际项目中，我们用轻易云做这件事，配置要点有四块：

1. 源端数据源：登记 MySQL 的连接信息（私有化环境下的内网地址脱敏后只保留 host 与端口占位），按接口表 + 增量字段抽取。

2. 目标端 API：调用金蝶云星空的「采购订单保存与审核」类 WebAPI。素材里采用分阶段方式，先保存、再审核、再返回，因此轻易云策略会拆成「推送」「审核触发」「结果回写」三段式编排，而不是一次性大而全的脚本。

3. 字段映射与编码转换：在轻易云的映射器里完成 FSupplierId → 星空供应商、FMaterialId → 星空物料的查表转换，金额、税率、单位按星空侧字段类型做格式归一。

4. 回写策略：星空返回 FBillNo、审核结果、错误消息后，由轻易云回写到 MySQL 接口表的 status、message 字段。这里素材里直接给出了 UPDATE ... status not in ('S','A') 的条件——避免覆盖已经成功或人工干预过的记录，这是稳妥的做法。

实施步骤

阶段一：增量起点对齐 首次上线前，先与业务方核对一次「起算时间点」。我们一般用「近 30 天已审核未推送」做首轮全量，把历史包袱清掉；之后按 modified_time 增量。

阶段二：全量触发 在轻易云上配置「全量同步任务」，跑完一轮核对两边单据号、金额汇总，再切换到增量调度。

阶段三：调度频率 采购订单的同步频率通常按业务节奏——不是越快越好。车间录入高峰是 8:00–10:00 和 14:00–16:00，我们一般把这段时间的调度压到 1–3 分钟一次，低谷放宽到 5–10 分钟一次。素材里这种类型回写类策略用 */1 * * * * 一分钟一次是常见做法，因为它只是状态回写，量小；推送主策略通常不必这么密。

阶段四：监控与告警 轻易云上对每条策略都有运行日志与失败告警。我们通常在「推送失败」「星空审核失败」「回写失败」三个环节各设一个独立告警点，便于值班工程师一眼定位是哪个环节断了。

踩坑复盘

1. 编码映射不要写在策略里。早期我们把供应商映射直接写在轻易云单条策略的脚本里，结果半年后另一条销售订单策略也用到同一份映射，怎么都找不到源头。后面统一上「编码映射集中管理」，按业务域切片维护。

2. 表头表体分阶段推送，不要一把梭。采购订单有表头 + 多分录，星空保存接口对分录数量、字段长度敏感。一次推送超过 200 行分录就容易踩到接口超时。稳妥的做法是「表头先建，分录分批」。

3. 回写时一定要带状态条件。素材里 status not in ('S','A') 这一句看着不起眼，但少了它就会出现「星空审核完成后，回写覆盖了用户手工修改的状态」。典型错误是直接 UPDATE 不带条件。

4. 增量字段必须要有索引。MySQL 接口表如果 modified_time 没建索引，调度一上来就全表扫描，跑两小时谁都受不了。这是和 DBA 一定要提前对齐的事。

5. 私有化环境的网络抖动要有重试。金蝶云星空私有化部署在内网，跨网段调用偶尔超时。轻易云的策略级重试 + 退避建议打开，不要全靠人工介入。

适用场景与不适用场景

适用：采购订单从业务侧 MySQL 推到财务/库存侧金蝶云星空，单据结构相对稳定、供应商与物料主数据已在两侧建立映射、单据量在每日数百到数千单级别。

不适用：跨法人组织、跨账套的多套星空同时接收同一张采购订单的场景；以及供应商编码在两侧尚未建立映射、规则未达成一致的早期阶段，强行同步只会放大混乱。