MES半成品入库同步到金蝶云星空其他入库单(虚拟仓库)实战教程
这个策略解决什么问题
在某制造企业的实际现场,MES负责车间现场执行,金蝶云星空负责财务与库存账。半成品在车间完工下线时,需要在MES中登记入库,并把结果回流到金蝶的库存账——但金蝶侧并不希望按真实仓库产生业务单据,而是希望用「虚拟仓库」+「其他入库」单据的方式做过程性记账。
这个策略要解决的就是:把MES侧的内部生产半成品入库单,准实时地推送到金蝶云星空,落地为一张标准的其他入库单(单据类型 QTRKD01_SYS),库存组织、领用组织、货主等按规则写入指定值,实现车间完工与ERP库存的轻量闭环。
数据流向与字段映射
数据流向很清晰:MES(源) → 轻易云数据集成平台(中间层) → 金蝶云星空(目标)。中间层不承担业务逻辑,只做字段翻译、编码映射与异常路由。
关键字段对照(源 → 中间层处理 → 目标)大致如下:
| 业务含义 | MES侧字段/来源 | 轻易云处理 | 金蝶侧字段 |
|---|---|---|---|
| 业务单据号 | business_no(单据号字段) | 原值透传 | FBillNo |
| 单据类型 | — | 常量映射 | FBillTypeID = QTRKD01_SYS |
| 库存组织 | — | 常量 | FStockOrgId = 100 |
| 领用组织 | — | 常量 | FPickOrgId = 100 |
| 货主类型 | — | 常量 | FOwnerTypeIdHead = BD_OwnerOrg |
| 货主 | — | 常量/映射 | FOwnerIdHead |
| 物料编码 | MES物料编码 | 编码映射(虚拟物料映射表) | FMaterialId |
| 仓库 | MES入库仓库 | 编码映射至虚拟仓库 | FStockId |
| 数量、批次 | MES表体 | 直接透传 | 表体对应字段 |
实务中,我们用轻易云做一张「编码映射集中管理表」:把MES物料编码 → 金蝶虚拟物料编码、MES仓库 → 虚拟仓库两个映射关系单独维护,后续其他策略(如成品入库、虚拟物料基础资料同步)都引用同一张映射表,避免每个策略重复配置。
在轻易云上如何配置
在轻易云数据集成平台(Qeasy)里,这条策略的典型配置要点如下:
- 源平台:四化智造MES(WEB),使用
common/search这个WebAPI接口(POST,分页查询pageNum/pageSize),以business_no作为业务单据号字段,以id作为主键,勾选idCheck,并启用autoFillResponse自动把分页结果合并到响应结构里。 - 目标平台:金蝶云星空,调用
batchSave(POST,EXECUTE 类型,buildModel: true),构造一张其他入库单的整单模型。 - 请求体:在轻易云的请求编排里,把单据头(
FBillTypeID、FStockOrgId、FPickOrgId、FOwnerTypeIdHead、FOwnerIdHead、FBillNo等)与表体(物料、数量、仓库、批次等)分别组装;FBillNo通过{{business_no}}引用源单的业务单据号。 - 编码映射:在轻易云的「数据加工」或「字段映射」节点里,把物料、仓库的统一映射引用到前面提到的集中管理表,这样新增/调整编码只改一处。
- 异常处理:在轻易云上配置「表头失败整单回滚、表体失败仅跳过该分录」的策略——这一步在客户现场经常被忽略,导致半张单子落到金蝶侧,排查极痛苦。
实施步骤
我们建议分三个阶段推进,这也是轻易云客户常用的「增量与全量双轨」做法:
第一阶段:全量初始化。 用 pageSize=100 把MES侧历史未推送的半成品入库单一次性捞回来,在轻易云里手动触发一次全量执行,先解决「历史欠账」问题。这一步务必先和业务确认存量范围,否则会把很老的、已经关结的单据也带过来,污染账期。
第二阶段:增量起点定标。 取全量结束时刻作为增量起点,MES接口以「最后修改时间 > 起点」为过滤条件。轻易云里把起始时间戳写到策略的「增量游标」字段,后续每次调度从这个游标往后推。
第三阶段:稳定调度。 素材里给的 cron 是 * 7-22 * * *,覆盖早7点到晚10点每分钟一次,匹配车间的实际生产节拍。我们建议生产环境下至少跑一周观察「成功/失败/重试」的分布,再根据金蝶侧的写入压力调整间隔——如果金蝶 batchSave 出现排队,把频率从每分钟降到每2–5分钟往往就能稳住。
踩坑复盘
- 表头表体分阶段失败:一次实际项目中,MES侧表头没问题、表体某一行物料在金蝶侧未启用,轻易云只把表头成功写入了,留下一张「无表体的其他入库单」。稳妥的做法是在轻易云里把整单建模(
buildModel: true)放在一个事务节点里,任一行失败就整单回滚,事后人工补单。 - 虚拟仓库被错关停:金蝶侧的「虚拟仓库」如果被人为在组织间禁用,该策略会突然大面积失败,但错误信息只显示「仓库无效」,现场很容易误判成MES数据问题。建议在轻易云里加一个前置校验,先校验目标仓库和组织状态,再下发。
- 业务单据号重复:MES侧允许同一
business_no被多张单据复用,推送到金蝶后FBillNo撞重,导致金蝶侧的整单写入被拒。这里的稳妥做法是把business_no + 序号拼成一个全局唯一的FBillNo,避免冲突。 - 映射表没人维护:编码映射集中管理后,新增车间或新增虚拟物料时,如果映射表没人负责,新数据就会在轻易云里落到「未映射」桶里长期积压。我们建议给映射表指定唯一责任人,变更走工单。
- cron 设置覆盖不到夜班:素材里
* 7-22 * * *是早7点到晚10点,如果客户后续开夜班,这个 cron 就会漏推夜间入库数据。排期前务必和车间确认生产时段。
适用场景与不适用场景
适用:车间有MES、金蝶作为库存/财务主账,半成品需要轻量记账、不需要走完整生产入库流程的离散制造场景。不适用:半成品需要参与成本核算、需要按真实仓库做库位管理的场景,这种应当走标准的生产入库单而非「其他入库+虚拟仓库」。