金蝶其他入库单到 MES 送检签收：一条策略的同步实战

这个策略解决什么问题

在很多制造企业的现场,质检环节往往夹在 ERP 入库与 MES 生产之间。ERP 一端已经审核了一张「其他入库单」,MES 一端却迟迟收不到送检触发,质检员靠人工翻单据、录系统,既慢又容易漏。这一条策略要做的事情很具体:把金蝶云星空里已审核的其他入库单,按分录行拆开,自动推到四化智造 MES,生成送检任务,作为质检入库签收与送检的统一入口。

数据流向与字段映射

数据从金蝶云星空出发,经轻易云数据集成平台(Qeasy)中间层,落到四化智造 MES 的送检签收接口。源端通过 executeBillQuery 拉取分录级数据,目标端按行调用 creatQmsInspectTaskDto。整体是「一进一出、行级扁平」的结构。

源字段(金蝶)	目标字段(MES)	映射类型	说明
FBillNo	inspectNo	DIRECT	入库单号作为送检单号,用于业务追溯
FBillNo	purchaseOrderNo	DIRECT	入库单号复用至采购单号字段,非采购场景需业务确认
FMATERIALID	materialUuid	DIRECT	物料主键,通常需联查基础资料获取 MES UUID
FSTOCKID	receiveInvDetailUuid	DIRECT	仓库 ID,通常需联查签收明细
FQty	inspectNum	DIRECT(int)	实收数量转送检数量
FUnitID	weightUnitName	DIRECT	单位 ID,可能需联查名称
FDEPTID	deptName	DIRECT	部门 ID,可能需联查名称
FSUPPLIERID	supplierUuid	DIRECT	供应商 ID,通常需联查
-	companyCode	CONSTANT	目标系统多租户标识,固定值
-	inspectWeight / processCode / orderNo	EMPTY	当前未启用,预留扩展

唯一性上,源端用 FBillNo + FEntity_FEntryID,目标端以 inspectNo 与物料、数量组合形成业务唯一键。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这一策略通常按以下要点配置:

源端动作:选择金蝶云星空的 executeBillQuery,设置字段选择集,把 FEntity_FEntryID、FID、FBillNo、FDocumentStatus、FDate、FMATERIALID_FNumber、FSTOCKID_FNumber、FQty、FUnitID、FDEPTID、FSUPPLIERID、FLOT 等纳入返回,既满足当前映射,也为后续扩展留余量。
过滤条件:FilterString 写 FApproveDate>='{{LAST_SYNC_TIME|datetime}}',按审核日期增量拉取。建议补充 FDocumentStatus='C',把已审核作为硬性门槛,避免草稿态数据误推。
目标端动作:选择四化智造 MES 的 creatQmsInspectTaskDto WebAPI,POST 方式,idCheck=true,确保同一 inspectNo 不重复创建。
编码映射集中管理:物料、仓库、供应商的 ID 到 UUID 映射,不要散落在每个策略里。轻易云客户常见的做法是单独建「金蝶物料→MES 物料」等基础资料策略,在送检策略里用 _findCollection 或 _mongoQuery 联查,后续物料主键体系调整时只改一处。
表头表体分阶段:本期只推分录行级别的送检任务,主表级字段(如单据状态、备注)在后续阶段再补。

实施步骤

增量起点初始化:在金蝶侧选定一个明确的时间点(例如月初、启用日),把 LAST_SYNC_TIME 设为该时刻,先跑一次冷启动,把窗口内的历史已审核单据一次性同步过来。
全量触发:冷启动完成后,立即触发一次全量重跑,核对两边单据号与数量;若发现漏单,通常集中在审核时间在边界附近的记录,补一轮按 FApproveDate 重拉。
调度频率:策略 crontab 设为 * 7-22 * * *,工作时段每小时一次,平衡及时性与源系统压力;非工作时段停跑,避免夜间审核数据在次日上班瞬间冲击 MES。
校验与对账:在轻易云上开启 autoFillResponse,把 MES 返回的送检单号回写到轻易云日志,作为后续对账依据;每周末做一次单据号级对账,确认两边数量一致。
扩展与冻结:稳定运行一段时间后,把 inspectWeight、processCode、orderNo、FPrice/FAmount、FLOT 等字段按业务优先级逐步启用,每启用一批就冻结前一版的映射,避免静默回滚。

踩坑复盘

直接传 ID 翻车:物料、仓库、供应商如果只是把金蝶的主键 ID 原样塞给 MES,前两周看着没问题,等 MES 端做了编码清理或迁移,数据就对不上了。稳妥的做法是「编码映射集中管理」,用基础资料策略统一维护 UUID。
状态过滤缺失:源端只按 FApproveDate 拉数据,没加 FDocumentStatus='C',会把暂存态的单据也推过去,MES 出现一批「无送检单号的幽灵任务」。典型的工程师教训:增量条件不能只靠时间,业务状态必须叠加。
单位/部门 ID 与名称混用:MES 接口文档示例值是「KG」这样的名称,而金蝶给的是 FUnitID,直接传 ID 会被目标端当成无效值丢掉,需要联查金蝶计量单位表;部门同理。
crontab 横跨整天:把调度设成 * * * * * 每分钟跑,看似更及时,实际会给金蝶 executeBillQuery 造成不必要的压力,且夜间无人审核时产生大量空跑。7-22 工作时段是经验值。
送检重量与生产订单号「能填就填」:inspectWeight、orderNo、processCode 当前映射为空,有些工程师会顺手把其他字段塞过去,反而破坏目标端业务语义。这种字段,宁可空着,等业务确认后再补。

适用场景与不适用场景

适用:已有金蝶云星空做账、其他入库单是质检入口主来源,MES 需要按行触发送检任务的多组织制造企业;适合「编码映射集中管理 + 表头表体分阶段 + 增量与全量双轨」的落地节奏。

不适用:业务要求把生产订单、销售订单直接驱动送检,无需经过 ERP 入库单中转的场景;也不适用于金蝶与 MES 物料主键已统一、不存在 ID-UUID 映射需求的简单集成。