MES生产补料同步到金蝶云星空：单一策略实战教程
这个策略解决什么问题
在离散制造车间里，MES 是执行层的"事实来源"，ERP 是财务与供应链的"权威账本"。生产补料单一旦在 MES 端生成——比如某道工序发现物料不够、工序补领、车间异常领料——就必须尽快落到 ERP 里，否则库存账、成本归集会失真。我们这次落地的策略是：将四化智造 MES（WEB）的内部生产补料单，按增量方式实时同步为金蝶云星空的生产补料单，并关联到 ERP 侧的生产订单。
实际场景里最容易翻车的是"看起来同步了，但三个月后两边数字对不上"——根因往往是编码映射没设计好、单据编号冲突、表头和表体分阶段写入失败。这次我们用轻易云数据集成平台（Qeasy）做这件事，把源端接口、分页查询、目标端 batchSave 这些动作封装成可观测、可重跑的策略。
数据流向与字段映射
整体流向是单向的：源端 MES（WebAPI / common/search）→ 轻易云中间层（清洗、映射、去重）→ 目标端 金蝶云星空（batchSave）。
关键字段对照如下：
| 业务含义 | 源端 MES 字段 | 中间层处理 | 目标端 金蝶字段 |
|---|---|---|---|
| 单据编号 | orderNo | 直接透传，作为幂等键 | FBillNo（{{pickNo}}） |
| 日期 | createTime | 格式化为 yyyy-MM-dd | FDate（{{createTime}}） |
| 单据类型 | （源端无） | 常量补齐 | FBillType = SCBLD01_SYS |
| 发料组织 | wsId / 组织编码 | 编码映射表 | FStockOrgId = 100 |
| 生产组织 | 组织编码 | 编码映射表 | FPrdOrgId = 100 |
| 物料编码 | 物料编号 | 物料映射表 | FMaterialId |
| 数量、批号 | 子表行项目 | 表体分阶段写入 | FQty、FLot |
| 关联生产订单 | 生产订单号 | 关联键映射 | FMoBillNo |
中间层最关键的两件事：编码映射集中管理（物料、组织、货主类型、仓库统一放一张映射表），以及表头表体分阶段写入（先 batchSave 表头拿 FID，再回填表体的 FEntryId）。这是轻易云客户常见的两种应对模式。
在轻易云上如何配置
在 Qeasy 上配置一个策略，本质就是"源端连接器 + 目标端连接器 + 转换流 + 调度"四件套。
源端连接器：选 WebAPI 适配器，把 common/search 接口注册进来，请求体包含 params、pageNum=1、pageSize=100、wsId、queryKey=2。注意 wsId 是工作站点标识，决定了能拉到哪个车间的补料数据，每次切换车间要同步更新。
目标端连接器：选金蝶云星空的 batchSave 接口，单据类型写死 SCBLD01_SYS，这是生产补料的标准单据类型。
转换流（核心）：
- 字段映射：用轻易云的表达式编辑器，把 MES 的
orderNo映射成FBillNo，把createTime格式化后传给FDate。 - 编码映射：物料、组织、货主类型这三类，强烈建议在 Qeasy 的「映射表」里集中维护，不要写在转换脚本里。原因后文踩坑环节会讲。
- 表体处理：开启"分阶段写入"，先落表头，再循环写表体行。
- 幂等控制：以
FBillNo作为去重键，已存在的单据跳过。
调度：建议初始阶段用全量回灌把历史数据补齐，之后切换为增量。
实施步骤
我们把这个策略的实施拆成三个阶段，避免一上来就跑增量导致历史漏单。
第一步：增量起点对齐。在源端 MES 拉取一次全量，确定增量起点时间戳（一般是最近一次成功同步的时间）。在轻易云里把这个时间戳存到策略的「游标变量」中，后续每次运行基于游标过滤 createTime > last_sync_time。
第二步：全量触发（一次性）。手工触发一次全量回灌，把策略上线前积压的补料单一次性推到金蝶。典型做法是先在测试账套跑一遍，验证编码映射、单据类型、组织 ID 都对得上，再切到正式账套。
第三步：调度频率。MES 的补料操作集中在白班 7:00–22:00，所以我们把 crontab 设为 * 7-22 * * *（每 5–10 分钟一轮，具体看业务量），夜间停跑以减少对 MES 性能的影响。增量与全量双轨运行是轻易云客户的常见做法：平时增量、每月一次全量核对，防止游标漂移。
上线后第一周，建议每天人工核对一次金蝶侧补料单数和 MES 端日报数。
踩坑复盘
坑 1：编码映射写在脚本里，后期改不动。 第一次做这个项目时，我们把物料编码映射直接写在 Python 脚本里，结果组织调整时改了 3 天。稳妥的做法是用 Qeasy 的映射表集中维护，物料、组织、仓库、货主类型分开建表，跨策略复用。
坑 2：表头写成功、表体静默失败。 金蝶的 batchSave 如果表头校验通过但表体某一行报错，接口可能只返回部分成功。典型错误是只看 HTTP 200 就认为同步成功。稳妥的做法是开启轻易云的「行级回执解析」，逐行比对成功标志，失败的行单独重投。
坑 3：wsId 切换车间后没同步更新。 MES 是多车间多工作站的，wsId 决定了数据范围。一次现场事故就是：策略里写死了某个 wsId，结果新车间上线后所有补料单都同步不进来。建议把 wsId 也做成可配置的映射变量，按组织维度切换。
坑 4：单据编号冲突。 MES 的 orderNo 规则和金蝶的 FBillNo 规则不同，直接透传可能撞号。稳妥的做法是在中间层加一个 pickNo 转换逻辑，把 MES 单号加上策略前缀（比如 BL_），既能保持可追溯，又避免冲突。
坑 5：游标漂移导致漏单。 MES 的 createTime 是服务器时间，如果跨时区或服务器时间不准，增量过滤会漏掉边界单。稳妥的做法是加上 id 字段的 idCheck=true，用主键做二次校验，发现 ID 不连续时自动触发补偿。
适用场景与不适用场景
适用：MES 执行层产生补料、领料业务，ERP 需要做库存账与成本归集；生产订单已在 ERP 端建立，MES 只负责执行反馈；车间数量可控（≤ 几十个），编码映射表能维护得住。
不适用：MES 和 ERP 都允许独立创建补料单、需要双向同步；车间数量极多且物料编码规则混乱；或者补料业务要求秒级实时（轻易云这一策略是分钟级，秒级场景需要走消息队列直连）。