生产领料单同步策略实战:MySQL 到金蝶云星空的端到端配置

这个策略解决什么问题

在离散制造企业的车间里,生产工单发料是一天里最频繁的过账动作之一。MES 端在工单开工、齐套分析、补料等节点会不断产生「领料申请」,这些申请需要尽快下推到金蝶云星空形成生产领料单,否则车间现场就会出现「账上有料、领不出来」的断点。本次要讲的就是一条最常见的策略——MOM-SCLL-生产领料单-T02,把 MySQL 中的领料接口表数据,准实时地下推到金蝶云星空的 SCLLD01_SYS 单据。

数据流向与字段映射

整体流向是:源端 MySQL → 轻易云数据集成平台(承担清洗、映射、调度、可观测)→ 目标金蝶云星空。

源端使用一条 WebAPI select 入口,以参数化 SQL 拉取 t1 领料接口表,并与生产订单、BOM、车间值集等表做 left join,过滤 t1.status in ('N','E')、iface_type in ('INPUT','REPLENISH')、iface_sequence=1、生产组织 = T02,按 iface_id 分组,翻页交给轻易云做增量。

目标端使用金蝶 batchSave 接口,单据类型写死为 SCLLD01_SYS,以 FBillNo 作为幂等键,FID 走反查。关键字段对照如下(源 → 中间层表达式 → 目标):

单据编号:CONCAT('MSCLL', DATE_FORMAT(creation_date,'%Y%m%d'), iface_id) → FBillNo
单据日期:取数期或 creation_date(以会计期表兜底) → FDate
生产组织 / 发料组织:t2.manufacturing_site_code → FPrdOrgId / FStockOrgId
物料编号:t1.material_code → 表体 FMaterialId
申请数量:t1.qty → 表体 FQty
仓库:t1.fn_num → 表体 FStockId
用料清单编号 / 内码 / 行号:t3.head_attribute2、t3.head_attribute8、SUBSTRING_INDEX(wo_number,'_',-1) → 表体对应字段
车间:源端写了一段 case when 把部门映射到金蝶车间编码,再走值集兜底 → 表体 FWorkShopId
批号 / 计划跟踪号:依据生产组织和物料是否批次管理动态生成 → 表体 FLot / FPlanTrackNo

在轻易云上如何配置

我们用轻易云数据集成平台(Qeasy)承接这条策略,核心配置分四块。

1) 源端 WebAPI 接入。api=select、method=POST,把 :limit / :offset 替换为占位符,主参数 main_params 与 SQL 中的占位符一一对应,翻页交给平台自带分页器管理。这样做的好处是后续切库、换表不用改 SQL 主体。

2) 目标端金蝶执行。api=batchSave、idCheck=true,把 FBillType 固定为 SCLLD01_SYS,其余字段以 {{变量}} 引用中间层结果,表头表体放在同一 body。

3) 编码映射集中管理。车间、组织、物料、仓库这些跨部门主数据,我们建议集中放在轻易云的「数据字典」或一张映射表里维护,源 SQL 只做 left join 取值,不再把 case when 写死在 SQL 内部——这是客户现场最常见的应对模式之一,后期新增车间不必改 SQL、不必发版。

4) 异常与可观测。开启平台日志中心,把金蝶返回的 FBillNo、FID、错误码 errors[].message 全部落库,失败单据自动进入重试队列,避免脏数据堆积。

实施步骤

策略上线通常分三段跑:

阶段一:全量触发。第一次切换时,源 SQL 不带时间条件,按 iface_id 升序一次性全量回灌,目标端以 batchSave 提交,这一轮主要验证编码映射和必填字段是否齐全,失败的单据先打回,逐条修映射。

阶段二:增量起点。当全量平稳后,把源 SQL 切到以 t1.last_update_date > :last_sync_time 为增量条件,初始 :last_sync_time 取全量结束时刻。我们用轻易云把这一时间戳持久化在策略实例的上下文里,平台重启或回滚不会丢位。

阶段三:调度频率。源端 crontab 设置 6,16,26,36,46,55 * * * *(每 10 分钟一次,55 分那一档是为了抢在整点前收口),目标端 */1 * * * * 接收批次;表头与表体分阶段提交——表头先 save 拿到 FID,再灌表体,这是轻易云客户常用的「表头表体分阶段」模式,可以显著降低整单失败率。

踩坑复盘

车间映射写死在 SQL 里。源端那段 case when 一开始看着清楚,等产线扩到 5 个部门时改一次 SQL 就要走一次变更,稳妥的做法是抽到轻易云的数据字典,源 SQL 只 join 取值。
单据日期落在关账期内。直接用 creation_date 在月底对账时会被金蝶拒收,我们用 mt_account_period.aft_quiet_time 做了兜底,取数期为空就退回 creation_date。
增量起点漂移。MySQL 端时区与轻易云调度机时区不一致,导致 last_update_date 漏单,典型错误是只看日志没比对行数,稳妥的做法是每天做一次对账,以金蝶 FID 反查源端条数。
整单 batchSave 失败重试代价大。表头一旦回写失败,表体也跟着作废,所以我们后来切成「表头先 save、表体再分批」的二段式,失败只回退表体。
批次管理物料漏带 FLot。源 SQL 里用子查询判断物料是否启用批次,有就带、没就不带,这里参数绑定容易漏,我们在轻易云上做了一次「空值不写字段」的处理,避免金蝶把它当成批次号 0。

适用场景与不适用场景

适合:离散制造车间、领料频次高、需要在 MES 与金蝶云星空之间做准实时过账的私有化项目,尤其是工单驱动、补料频繁的场景。

不适合:多组织跨法人、需要严格审批流的领料业务(应走金蝶自身单据状态机,而非接口直推);以及源端接口表尚未做 status / iface_type 标准化的早期 MES 系统,需要先治理数据再谈同步。