MES质检入库到金蝶其他入库单:基于轻易云的同步策略实战

这个策略解决什么问题

某制造企业的车间里,MES在每道工序完工后会生成一条质检记录(inspectNo),但只有当这道工序有具体工序编号、不是空值时,这条记录才意味着"产线上真的做出了可入库的成品或半成品"。问题是:这些质检数据如果不实时落进ERP,财务成本、库存账、车间报工都跟不上。在金蝶云星空里,这一类业务用的是"其他入库单"。我们用轻易云数据集成平台(Qeasy)承接,做一条策略:从MES侧按工序非空过滤,把质检单据转成金蝶其他入库单,实现以质检驱动的入库闭环。

数据流向与字段映射

整体流向是:四化智造MES(WEB) → 轻易云中间层 → 金蝶云星空。

源端(MES,WebAPI common/search,POST,QUERY 语义)用 inspectNo 作为业务单据号,以 id 作为主键,带分页和 wsId、queryKey 等请求参数;目标端(金蝶云星空,batchSave,EXECUTE 语义)用 FBillTypeID=QTRKD01_SYS 这一标准其他入库单类型。

关键字段对照(节选):

业务含义	MES 源字段(示例)	金蝶目标字段	备注
业务单据号	inspectNo	FBillNo	模板里用 `{{checkNo}}` 占位
库存组织	—	FStockOrgId	目标端固定值
领用组织	—	FPickOrgId	目标端固定值
货主类型	—	FOwnerTypeIdHead	BD_OwnerOrg
货主	—	FOwnerIdHead	与货主类型配套
物料编码	materialCode	FMaterialId	走编码映射
数量	qty	FQty	表体逐行
工序	processNo	FEntryNote / 备注	用于追溯

编码映射(物料、组织、仓库、货主)是这套策略最容易出问题的地方,我们用轻易云的"编码映射集中管理"统一维护,避免散落在每个策略里。

在轻易云上如何配置

在轻易云(Qeasy)的策略画布里,这个策略的节点大致是三段:源查询 → 字段映射/过滤 → 目标写入。

源节点:选 WebAPI,common/search,POST,启用 autoFillResponse 让返回结构自动解析;分页 pageSize 设 100,pageNum 用表达式从上下文递增;关键是把 inspectNo 标为 number 字段,把 id 标为 id 字段,idCheck=true 用于幂等去重。
过滤节点:加一个"工序非空"的判断,只放行 processNo 不为空且非空白字符串的记录;空值记录只走统计不入库。
映射节点:表头字段直填常量或表达式({{checkNo}} 取源单据号);表体按行展开,物料编码走映射表替换为金蝶侧的 FMaterialId,数量、批号、备注、库存状态等按对应关系填。
目标节点:金蝶 batchSave,buildModel=true 让轻易云按金蝶的模型自动校验必填项,出现 FBillTypeID 之类的硬错会立刻返回。
异常处理:开启失败重试与告警,失败单据入死信队列,方便事后补推。

实施步骤

我们把这个策略的落地分成三段:

增量起点:策略上线前,先确定一个 inspectNo 起点,比如最近 7 天已完工的工序记录,作为首次启动的最小数据集,确认目标侧能成功生成单据。
全量触发:在确认增量无误后,手动触发一次全量回灌,分页循环直到源端没有新数据;这一步要盯着金蝶侧的消息中心,确认单据状态都为"已审核"或预期中间态。
调度频率:策略的 crontab 设的是 * 7-22 * * *,即每天 7:00 到 22:00 之间每分钟轮询。这个频度匹配生产节奏,白天高频,夜里停跑,降低对源系统压力。表头表体分阶段,先推表头再推表体,这样即便表体失败也不会留下没有明细的"半张单"。

踩坑复盘

工序字段没去空就入库。早期我们直接全量同步,结果金蝶里多了一批 FEntryNote 空的入库单,反查发现是工序记录没填。稳妥的做法是在过滤节点硬约束:不仅非空,还得是有效工序编号(在码表内)。
编码映射散落,三个月对不上。物料、组织、仓库映射一开始写在每个策略里,改了之后忘了同步别处。我们后来的应对模式是:编码映射集中管理,放在轻易云的"映射中心"统一维护,跨策略引用。
金蝶的 FBillTypeID 写错,被当成出库单。金蝶其他入库、出库、调整单据的编码前缀很像(QTRKD01_SYS / QTCKD01_SYS),一旦填错就是负向影响。配置时建议在策略上加一个"单据类型自检"步骤,出参时把目标单据类型和最终生成的单据状态一起回写日志。
分页漏页。源端 pageSize=100,但我们一度在分页表达式里把 pageNum 写死成 1,导致每次只拉第一页。表头表体分阶段推之后,表体用源单据号做锚点重拉,问题才暴露。
幂等键选错。源端 id 适合做幂等键,inspectNo 是业务号不要混用。我们让 idCheck=true 走源端主键,业务号 inspectNo 只用作 FBillNo 与追溯。

适用场景与不适用场景

适用:离散制造里"按工序报工 + 完工质检"驱动的入库,希望以质检结果为口径生成金蝶其他入库单;对账周期短、需要按工序追溯入库来源。不适用:流程行业按批次自动入库、不需要逐工序追溯;以及质检结果仅用于判定、不需要落账的场景。