生产退料单同步实战:MySQL 到金蝶云星空的增量配置与踩坑复盘
这个策略解决什么问题
某制造企业的生产现场每天都会产生大量退料单:车间发现多发料、错料,需要把物料退回仓库。源端 MES 落到 MySQL 后,财务和仓库核算依赖金蝶云星空,如果两端数据不通,库存就会出现「账面有、实物无」的尴尬。这条策略做的事情很朴素:把 MySQL 里生产退料单的新增数据,按调度节奏推到金蝶云星空,生成对应的退料单据。
数据流向与字段映射
整体走「MySQL → 轻易云数据集成平台(Qeasy)中间层 → 金蝶云星空」三段式。源端通过 SQL 拉数,中间层做清洗与映射,目标端通过 batchSave 批量写入。
| 业务含义 | MySQL 源字段(中间层变量名) | 金蝶云星空目标字段 | 备注 |
|---|---|---|---|
| 单据编号 | 单据编号(由 MSCTL + 日期 + iface_id 拼接) | FBillNo | 编码规则集中在中间层生成 |
| 单据日期 | 单据日期(按账期取数) | FDate | 走账期表 mt_account_period |
| 生产领料单主键/单号 | 生产领料单主键、生产领料单号 | 表体关联字段 | 用于追溯源头 |
| 生产订单号/行号 | 生产订单号、生产订单行号 | 表体生产订单字段 | 通过 _ 拆分 |
| 物料编码 | 物料编码 | 表体物料 | 编码映射集中管理 |
| 退料数量 | qty | 表体数量 | 数值字段 |
| 退料原因 | return_reason | 表体备注 | 文本字段 |
| 仓库 | fn_num | 表体仓库 | |
| 生产车间 | 部门→车间映射(case when) | FWorkShopId | 部门编码转车间编码 |
| 生产组织 | manufacturing_site_code | FStockOrgId、FPrdOrgId | 收料组织与生产组织同源 |
| 计划跟踪号 | tracking_num(T02 时为空) | 表体跟踪号 | 条件赋值 |
值得强调的是:编码映射我们采用「集中管理」模式,部门到车间的 case when 写在源 SQL 里看起来方便,但车间一旦变动就要改 SQL。在轻易云上更稳妥的做法是把这类映射下沉到平台的字典表,由运维同学维护,SQL 里只做匹配。
在轻易云上如何配置
源端(Source)节点:
- 平台选 MySQL,API 类型
select,请求方式 POST,effect 设为QUERY。 main_sql写入主查询,关键过滤条件:iface_type = 'RETURN'、status in ('N','E')、iface_sequence = 1、源租户过滤,按t1.iface_id去重。- 关键过滤:
and t5.wo_input_record_id > 0 and t5.attribute15 <> '',这是表头与领料单关联的必要条件,缺一不可。 - 分页参数
:limit、:offset走中间层自动注入,初次全量靠这个翻页。
目标端(Target)节点:
- 平台选金蝶云星空,API 用
batchSave,effectEXECUTE,method POST。 FBillType写死SCTLD01_SYS,这是金蝶侧生产退料单的标准单据类型。- 单据头字段用
{{变量名}}引用中间层结果,例如{{单据编号}}、{{生产组织}}。 idCheck打开,平台会根据FBillNo去重,避免重复入账。
中间层:轻易云会自动生成字段映射、类型转换、变量绑定;需要人工介入的只有车间映射、组织编码、日期格式这几处。
实施步骤
我们一般按「先全量、后增量」双轨上线。
第一阶段:全量起点。源端 main_sql 不带时间条件,让中间层按分页拉完历史数据。目标端 crontab 临时调成 0 */1 * * *(每小时一次),避免一次性大批量冲击金蝶接口。全量跑完后,核对两边单据编号数量。
第二阶段:切换增量。在源 SQL 末尾追加时间窗口条件(例如按 creation_date > 上次最大时间),把分页的起点切换到「上次游标」。这一步通常在中间层的「增量配置」里勾选,平台会帮你记录游标。
第三阶段:调度频率定型。源端 crontab 设为 */5 * * * *,每 5 分钟拉一次;目标端 crontab 设为 */1 * * * *,每 1 分钟执行一次写入。源端频率低于目标端,目的是让目标端「攒一批、写一批」,提升吞吐。
第四阶段:容错与重试。轻易云默认会重试失败任务,我们额外设置金蝶侧的「单据编号已存在」为幂等成功,避免重复推送。
踩坑复盘
第一,部门到车间的映射写在 SQL 里。典型错误是车间新增时 SQL 改漏一处,导致部分退料单生产车间为空。稳妥的做法是把映射抽到轻易云的字典表,SQL 里只做 join,改一处全量生效。
第二,日期取数没走账期。直接用 creation_date 在月末会出问题:跨账期的退料单会被错误归到下个月。我们用 mt_account_period 的 aft_quiet_time 做边界判断,小于账期截止时间的走账期日期,否则保留原日期。
第三,源 SQL 漏掉 t5.attribute15 <> '' 这一过滤条件,会让没有上游领料单号的退料单也被推送过去,金蝶侧直接报错。这是生产退料与领料联动的硬约束。
第四,生产订单号拼接方式被改过。早期用 SUBSTRING_INDEX(t1.wo_number, '_', 1) 取前半段,但源系统升级后 wo_number 格式变了,所有订单号字段变成空值。建议在中间层加一层正则校验,异常直接进告警,而不是静默写入。
第五,crontab 没分阶段就上线,全量第一次跑就把金蝶接口打挂了。表头表体分阶段上线非常关键:先上线表头映射、跑通单据创建,再追加表体的物料、数量、仓库字段。
适用场景与不适用场景
适用:生产退料、领料、补料这类「单据新增」型同步,数据量稳定、字段结构清晰的制造业 MES 到 ERP 链路。不适用:需要复杂审批流、状态机往返的场景(比如退料审核后回写 MES),以及需要实时逐笔推送的高频物联网写入(建议走消息队列而非定时轮询)。