旺店通其他出库单覆盖写入金蝶分步式调出单:库存同步实战教程

这个策略解决什么问题

某零售企业在用旺店通做前端仓储、用金蝶云星空做后端财务与库存核算。门店日常的"其他出库单"(比如调拨、报损、领用)在旺店通里产生后,需要落地成金蝶的分步式调出单,否则两边库存和单据号永远对不齐。我们用轻易云数据集成平台(Qeasy)做承接,把这条链路做成"源端单据号覆盖目标端、覆盖式写入"的策略,保证两边账实一致、可追溯。

数据流向与字段映射

数据流向:旺店通·旗舰奇门(Query)→ 轻易云中间层 → 金蝶云星空(Execute, batchSave)。源端用 wdt.wms.stockother.outquery.querywithdetail 拉取其他出库单详情,目标端通过 batchSave 覆盖写入 STK_TRANSFEROUT(分步式调出单)表单。

关键字段对照表:

语义	旺店通源端	金蝶目标端	处理要点
单据编号	`other_out_no`	`FID`	用函数表达式从 remark 末尾切片提取,实现覆盖式回写
单据标识	`other_out_no`	`number` / `id`	`idCheck=true`,按单据号去重
业务时间	`created`	目标单据日期	注意时区对齐
经办人	`employee_name`	表头人员	走编码映射
预留标识	`is_reserved`	自由字段	是否落账的控制位
明细分录	接口内嵌 detail 列表	`FSTKTRSINENTRY`(array)	表体绑定 `detail_list`
表单ID	—	`STK_TRANSFEROUT`	必须填写金蝶业务对象表单ID
操作类型	—	`BatchSave`	覆盖写入的核心动作

源端 idCheck=true,意味着按源端单据号作为幂等键,避免重复写入。

在轻易云上如何配置

在轻易云集成平台里,这条策略的配置要点有四个:

源端元数据:声明 metadata.type=QUERY、number/id=other_out_no,开启 autoFillResponse 让响应结构自动对齐,buildModel=false 走标准抓取路径。
目标端元数据:metadata.type=EXECUTE,FormId=STK_TRANSFEROUT,Operation=BatchSave,IsAutoSubmitAndAudit=false(先保存,审核由人工触发,留一道风控)。FID 通过函数 RIGHT(remark, INSTR(REVERSE(remark),'-')-1) 从单据编号尾段提取,这是覆盖写入成立的前提。
字段映射:把源端的 detail 直接绑到 FSTKTRSINENTRY,表头字段逐项映射,日期、人员走编码映射集中管理。
调度:源端 cron 0-59/30 7-22 * * *(每 30 分钟,从 7 点到 22 点),目标端 cron 1-59/30 7-22 * * *(错开 1 分钟,避免并发撞库)。

编码映射在轻易云里是集中管理的——门店、商品、仓库、人员这些主数据,都在一个映射表里维护,改一处全链路生效。

实施步骤

我们把这套策略上线分四步走:

第一步:增量起点。首次只拉近 7 天的单据,跑通链路、观察目标端落单是否正确。这一步先验证映射逻辑,不追求数据量。

第二步:全量触发。增量稳定后,触发一次历史全量回灌,把存量单据一次性写入金蝶。全量跑完后,系统会自动落位,后续只走增量。

第三步:日常调度。进入稳态后,源端每 30 分钟抽一次增量,目标端错峰 1 分钟写入,形成"近实时"的同步节拍。

第四步:异常兜底。轻易云会自动记录失败单据,提供重跑入口;idCheck 保证重跑时同号单据覆盖更新,不会产生重复。

这就是轻易云常见的"增量与全量双轨"模式:全量兜底、增量节流、重跑保底。

踩坑复盘

FID 表达式别想当然。我们最初直接拿 other_out_no 当 FID,结果金蝶那边单据号格式校验过不去。稳妥的做法是用 RIGHT + INSTR(REVERSE(...)) 从 remark 尾段切片,既符合金蝶规则,又保证覆盖式回写能命中已有单据。
表头表体一定要分阶段。表头先落、表体后落,中间靠 FID 关联。如果一次性提交,某一行物料映射报错,整张单就废了,排错很痛苦。
cron 不要同时整点。源端 0-59/30 和目标端 1-59/30 错开 1 分钟,看似无所谓,但在大促期间并发量上来时,这是避免目标端瞬时拥塞的关键。
IsAutoSubmitAndAudit 慎开。一旦设为 true,中间任何字段异常都会直接生成一张"已审核"的脏单,财务侧很难撤。生产环境保持 false,审核交给人工,稳妥得多。
编码映射集中管理。门店、仓库、商品、人员这些映射,务必放进轻易云的统一映射表,不要散落在策略里。3 个月后某家门店编码变了,你只需要改一个地方,而不是 27 个策略全改一遍。

适用场景与不适用场景

适用:旺店通作为前端仓、金蝶作为后端核算的私有化供应链项目;单据量适中、需要覆盖式回写源端单据号、对账时效要求在小时级以内的场景。

不适用:双向实时联动的仓储作业场景(需要的是双向锁库而非单向覆盖);金蝶侧不允许覆盖写入、必须严格留痕的合规审计场景。