MES工序委外发料(半成品材料)到金蝶其他出库同步方案实战教程

这个策略解决什么问题(场景与价值)

某制造企业生产现场,MES下达工序委外任务后,需要把半成品材料从原料仓发到委外供应商处。MES里这是「工序委外发料」,到了金蝶云星空要落地为「其他出库单」。两个系统的单据模型不一样:一张是工序任务附属的发料明细,一张是标准的库存出库凭证。如果靠人工二次录入,数据滞后、库存账对不齐,委外核销也会出问题。

我们在客户现场的做法是:把这张发料单从MES原样推到金蝶,中间用轻易云数据集成平台(Qeasy)做字段翻译和编码映射,做到发料即出库、库存账实时一致。下面把这条策略拆开讲清楚。

数据流向与字段映射(源 → 中间层 → 目标)

整体流向是 MES(Web API) → 轻易云中间层 → 金蝶云星空(batchSave)。

源端是MES的查询接口(common/search,POST方式),按 wsId + queryKey 拉取工序委外发料数据,分页参数 pageNum / pageSize 默认 100 条/页,业务单号字段是 business_no,主键是 id。目标端是金蝶的 batchSave 接口,典型的EXECUTE型调用。

关键字段对照如下:

业务含义	MES源字段	中间层处理	金蝶目标字段
单据编号	business_no	原值透传	FBillNo(`{{business_no}}`)
单据类型	—	固定值	FBillTypeID=`QTCKD01_SYS`(标准其他出库)
库存组织	—	固定值	FStockOrgId=`100`
领用组织	—	固定值	FPickOrgId=`100`
部门	createName	Mongo查表映射FPostDept	FDeptId
库存方向	—	按业务固定	FStockDirect
表体物料/数量	委外发料明细	行项目拆分	FEntity下的物料编码、实发数量

中间层最核心的工作是编码映射:MES的物料编码、部门、供应商业主数据,需要先在轻易云里做集中映射,否则金蝶那边会拒收或落到错误组织。

在轻易云上如何配置

这条策略在轻易云里按「源策略 + 目标策略」两步配置。

源策略:API 选 common/search,effect 设 QUERY,method 选 POST。number 填 business_no,id 填 id,开启 idCheck=true、autoFillResponse=true。buildModel 关闭,因为MES响应结构稳定,不需要轻易云自动建模。请求体里 params 走过滤条件、pageNum=1、pageSize=100、wsId 按客户现场填入、queryKey=2(对应工序委外发料视图)。

目标策略:API 选 batchSave,effect 设 EXECUTE。buildModel=true,让轻易云根据金蝶元数据生成请求模型。idCheck=true,防止重复推送。请求字段里,FBillTypeID 固定 QTCKD01_SYS;FStockOrgId、FPickOrgId 按客户组织编码填;FBillNo 用变量 {{business_no}} 引用源端单号;FDeptId 用轻易云的 _mongoQuery 能力按 createName 反查部门编码,这是轻易云客户常见的「编码映射集中管理」做法——把跨系统的主数据对照表放到Mongo里统一维护。

实施步骤(分阶段调度)

上线时建议分三个阶段跑:

第一阶段:增量起点对齐。在MES里挑一张当天的工序委外发料单,手工触发一次同步,确认金蝶端能正常生成其他出库单,且单号、表体数量一致。这一步重点验证字段映射,特别是部门和物料编码。

第二阶段:全量触发。把MES当天 7:00 之前的历史发料单按 business_no 升序跑一遍全量回灌。全量阶段 pageSize 可以调到 200 提速,但每页都要校验 idCheck,避免重复。

第三阶段:调度常态化。crontab 配 * 7-22 * * *,即每天 7:00 到 22:00 每分钟跑一次,覆盖一整个生产班次。增量与全量双轨运行:增量走 idCheck 自动去重,全量作为兜底,每周一次人工触发。表头先稳定,表体(物料行)在表头跑通一周后再放开,这是轻易云客户里常见的「表头表体分阶段」上线节奏,降低初期排错成本。

踩坑复盘

wsId 写错,接口返回空但 HTTP 200。MES的查询是按 wsId 隔离业务的,写错会导致静默空数据。建议在轻易云里把 wsId 抽成环境变量,每个客户独立维护。
pageSize 过大被MES限流。一次设到 500,接口直接超时。稳妥的做法是默认 100,大客户再单独调到 200,不要照搬别人的配置。
FDeptId 用 createName 反查时,遇到同名员工。Mongo里要按 FName + FOrgId 联合匹配,否则会把人推到错误的部门。这里容易翻车,务必把组织维度一起带进过滤条件。
FBillNo 直接透传 business_no,出现重复。MES允许同一单号被复用,金蝶不允许。中间层加一个 idCheck 的兜底,如果目标已存在就跳过该条。
委外发料撤销后,金蝶出库单没冲销。这是典型的双向同步遗漏。稳妥的做法是另外配一条「委外退料 → 其他入库」策略,而不是在出库单上做负数。

适用场景与不适用场景

适用:工序委外发料、需要金蝶实时记账、半成品材料从MES直推金蝶私有化环境。不适用:跨法人公司间调拨(走调拨单更合适)、需要审批流控制的场景(其他出库单不承载审批节点)、以及MES和金蝶不在同一时钟同步区间的弱网环境。