金蝶即时库存到吉客云盘点单:一条策略的实战配置教程

这个策略解决什么问题

某零售企业把 ERP 放在金蝶云星空、仓配与门店要货走吉客云,两边库存长期对不齐。业务希望按"仓库"维度,把金蝶每日的库存快照聚合成盘点单,定期推给吉客云做对账与校准。这一策略的核心是"按仓库分组成单",而不是一物一单,落地难点集中在字段映射、批次维度、增量起点三件事。

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

数据流:金蝶云星空 STK_Inventory → 轻易云数据集成平台(Qeasy)中间层(按仓库分组)→ 吉客云 erp.stock.quantityadjust 库存调整单。源端每条记录是一个"物料+仓库+批次"的库存快照,中间层按 FStockId_FNumber 分组,每个仓库生成一张盘点单,组内所有记录作为 detail 明细行。

主表关键字段对照:

源字段(金蝶)	目标字段(吉客云)	映射类型	转换规则	业务说明
FStockId_FNumber	warehouseCode	DIRECT	`{{FStockId_FNumber}}`	仓库编码,目标端若配置为 `{{FStockId}}` 需平台支持 ID→FNumber 自动解析
—	matchType	CONSTANT	`1`	货品编码类型固定为 1
源记录集合(按仓库分组后)	detail	COLLECTION	引用源端数组字段	盘点明细数组

明细行字段对照:

源字段	目标字段	映射类型	业务说明
FMaterialId_FNumber	货品编码/goodsCode	DIRECT	与吉客云货品档案一致
FBaseQty	数量/quantity	DIRECT	库存量(基本单位),盘点场景取账面数
FLot.FNumber	批次号	DIRECT	启用批次管理时必传
FMaterialId_FName	物料名称	DIRECT	辅助展示
FSpecification	规格型号	DIRECT	辅助展示

在轻易云上如何配置

源端配置:API 选 executeBillQuery,表单 ID 写 STK_Inventory,模式 QUERY,增量条件 FUpdateTime >= '{{LAST_SYNC_TIME|datetime}}',分页 Limit=2000 配合 StartRow 递增。请求字段按上表勾选,注意 FStockId 配 FStockId.FNumber、FLot 配 FLot.FNumber 这种"对象.属性"的取值方式。
目标端配置:API 选 erp.stock.quantityadjust,模式 EXECUTE。warehouseCode 的 value 写 {{FStockId_FNumber}};matchType 写常量 1;detail 配成数组,value 留空,引用源端的记录集合。
分组逻辑:本策略没有自定义脚本,所有聚合由平台的"按字段分组"能力完成——按 FStockId_FNumber 分组,每组触发一次目标端调用。这是轻易云客户常见做法:不写脚本,优先用平台内置分组,降低维护成本。
编码映射集中管理:仓库、物料编码映射放在主数据策略里(例如「金蝶-仓库→吉客云-仓库」),本策略直接引用映射结果;若两套编码不一致,可通过 _findCollection 联查主数据方案。

实施步骤

阶段一:全量初始化。首次上线时不带 LAST_SYNC_TIME,把历史库存一次性拉过来,按仓库分组成盘点单,推送至吉客云做期初对账。建议在业务低峰期执行,避免脏数据。
阶段二:增量起点切换。全量成功后,改用 FUpdateTime >= '{{LAST_SYNC_TIME|datetime}}' 拉增量,记录首次成功时间作为新的 LAST_SYNC_TIME。
阶段三:调度频率。源端设为 0 13,23 * * *(13 点、23 点整点拉取),目标端延后 15 分钟设 15 13,23 * * *,给源端拉取与分组留出窗口。生产环境也可按业务量改成小时级。
阶段四:校验与对账。每周期抽样核对目标端盘点单数量与源端 FBaseQty 一致,关注批次号是否完整、仓库维度是否漏单。

踩坑复盘

FStockId 还是 FStockId_FNumber 没分清。金蝶 FStockId 是对象,直接 {{FStockId}} 序列化出来是 JSON 而不是编码,会推过去一堆乱码。稳妥做法是统一用 {{FStockId_FNumber}} 取扁平编码。
盘点数量取错字段。FBaseQty 是库存量(账面),FBaseAVBQty 是可用量。盘点场景应当取 FBaseQty,否则会把已分配未出库的量算进来,导致两边数字对不上。
批次号漏传。启用了批次管理的物料如果不传 FLot.FNumber,吉客云会把不同批次的库存合并到一行,后续批次追溯就乱了。建议在源端请求字段里把 FLot 显式勾上,目标端对应字段必填。
一次性全量把目标端打爆。某次客户现场没分阶段,直接把全量库存推到吉客云,触发了对方限流,部分盘点单丢失。稳妥做法是表头表体分阶段:先推表头确认能落地,再批量推明细;或者在轻易云里配并发限速。
增量起点没对齐。全量跑完后忘了切换增量条件,下一次又拉了一次全量,产生了重复盘点单。运维交接时必须把"什么时候从全量切到增量"写进变更记录。

适用场景与不适用场景

适用:ERP 与 WMS 库存需要定期对账、跨仓库按仓汇总盘点、批次管理严格的零售与分销场景。不适用:需要实时秒级库存(本策略是小时级)、有复杂库存状态转换(如在检、冻结多状态)需要逐状态推送,以及源端没有可靠 FUpdateTime 增量字段的情况。