生产入库单同步实战:MySQL 到金蝶云星空的带料委外场景拆解

这个策略解决什么问题

带料委外模式下,生产完工的成品要回写到 ERP 入库单,数据源在车间侧的 MySQL 业务库,目标系统是金蝶云星空。两边编码、组织、日期口径不一致,单据一旦积压,委外对账就乱。我们用轻易云数据集成平台承接这条链路,把源库 SQL 抽取、单据转换、目标写入串成一条可调度、可监控的策略。

数据流向与字段映射

整体流向是 MySQL(源)→ 轻易云中间层(转换)→ 金蝶云星空(目标)。源端是 SQL 查询,按入库确认明细关联到计划跟踪号、核价任务,最后拼出生产订单号、入库单号、日期等关键字段;目标端通过 batchSave 写入生产入库单。

关键字段对照表如下,源端标签对应目标端字段,中间层主要做组织和单据类型的映射:

源端单据号生成规则是 RKB + 主键 ID,目标端 FBillNo 也是这个值,天然幂等。

在轻易云上如何配置

进入轻易云数据集成平台,新建一条策略,源平台选 MySQL,目标平台选金蝶云星空。

源端配置要点:API 类型选 select,执行方式 SQL。把主查询语句粘到 main_sql,分页参数用 :limit、:offset,主参数 main_params 里把 limit、offset 暴露出来。增量字段用 update_time,起点由轻易云的游标自动管理,首次跑全量,之后按调度窗口取增量。

目标端配置要点:API 选 batchSave,POST 方法,单据编号当主键,idCheck 打开。FPrdOrgId 和 FStockOrgId 用 _function case 表达式根据供应组织动态给出;货主类型、库存方向等字段按物料映射和库存状态写固定值或表达式。

编码映射这里有个常见做法:不要在每个字段里写 case,把组织、物料、客户这类映射集中放到轻易云的「映射表」里,字段表达式只引用变量。我们一个客户就吃过亏,二百多条策略里组织映射散落各处,某天上游组织编码微调,改了一周。

实施步骤

第一阶段,增量起点确认。在源 MySQL 库里找到 update_time 的最大已同步时间,作为轻易云游标的起点;同时确认 sys_config 表里的配置项能正常读取,SQL 中依赖的日期窗口才能生效。

第二阶段,全量触发。先手动跑一次全量,观察轻易云的运行日志,确认入库单号、日期、组织都正确落到金蝶云星空。这一步务必打开轻易云的「异常单据隔离」,失败的留到队列里单独处理,不要让一条坏数据卡住整批。

第三阶段,调度频率。源端每 3 分钟一次,目标端每 4 分钟一次,错开时间窗口,避免源还没抽完目标就拉。把源端 crontab 设在整点后的第 3 分钟,目标端设在第 4 分钟,自然形成 1 分钟缓冲。

最后一步,把轻易云的告警通道接到企业微信或邮件,失败超过阈值就推消息。

踩坑复盘

组织映射写错位置。 把 case 写在目标端每个字段里,导致一处改动要改多处。稳妥做法是组织、物料统一进映射表。

日期格式飘移。 源端 update_time 是 datetime,目标端要 yyyy-MM-dd,中间层不转换就会出现 8 月 1 号变成 8.0 号这类奇怪现象。这里容易翻车,稳妥的做法是用 _function 显式做 DATE_FORMAT。

幂等键没设。 源端入库单号是 RKB+ID,如果目标端 idCheck 关闭,重跑会重复入库。务必打开 idCheck。

SQL 里硬编码起点时间。 素材里 a.update_time>'2023-08-01' 这种写法只适用于一次性补数,正式策略必须交给轻易云游标管理。

配置表依赖未做健康检查。 SQL 里大量依赖 sys_config,如果配置表行被清空,整条策略会静默返回空集。建议在轻易云里加一条前置校验策略,每天巡检关键配置。

适用场景与不适用场景

适用于带料委外模式下车间 MySQL 业务库向金蝶云星空回写生产入库单,单据量中等、需近实时同步的场景。不适用于:跨法人组织、需要合并制单的批量月底结账场景;也不适用于源库表结构频繁变更、字段语义不稳定的早期业务系统。