金蝶云星空调拨单对接旺店通其他出库:一条策略的实战拆解

这个策略解决什么问题

某零售企业在多仓运营时,仓库之间日常会有大量调拨:调拨单在金蝶云星空里审核通过后,需要立刻在旺店通里生成一张「其他出库」单据,才能触发后续的拣货与发货动作。看似只是两张单据的对接,真正落地时却有三件事绕不开:仓库编码在两边不一致、增量起点选错了会丢单、调度频率和源系统业务高峰错开就会拖慢整条链路。这条策略就是用轻易云数据集成平台(Qeasy)把上述三件事一次配齐。

数据流向与字段映射

整体链路是单向的:源系统金蝶云星空 → 轻易云中间层 → 目标系统旺店通·企业奇门。源端调用 executeBillQuery 查询已审核的调拨单,中间层做字段清洗与编码映射,目标端调用 wdt.stockout.order.push 写入其他出库单。

关键字段对照如下:

在轻易云上如何配置

在 Qeasy 控制台里,这条策略配成「源集成 + 目标集成 + 中间映射」三段式。源集成选 WebAPI 查询,接口 executeBillQuery,把 FBillNo、FID、FDocumentStatus、FStockOrgId_FNumber、FDate 这些字段勾选出来;目标集成选 WebAPI 执行,接口 wdt.stockout.order.push,请求体里把 outer_no 绑到 {{FBillNo}},warehouse_no 绑到 {{FSrcStockId_FNumber}},明细走 detail_list 数组节点。

中间层是真正花心思的地方。我们用轻易云自带的「编码映射集中管理」能力,把所有仓库、货品的编码对应关系放在一张可维护的映射表里,源端一查,目标端一改,两边都不用动。这是轻易云客户里很常见的一种应对模式——主数据治理和同步逻辑解耦,后续加仓库或换编码都不会牵动整条链路。

另外一个小细节:is_check 直接写死为 "1",意味着源端只取已审核单据,这一行配置其实把「状态过滤」和「目标标记」合并成了一个常量,不必再写复杂的判断。

实施步骤

第一步,先跑通全量。 把 crontab 临时改成一次性触发,把近 90 天的调拨单一次性同步到旺店通。这一步的目的不是上线,而是验证映射和写入逻辑都正确——库存类集成一旦表体错位,后续排查会非常痛苦。

第二步,切增量起点。 全量跑通后,清空旺店通侧临时生成的其他出库单(测试态),把增量起点切到源系统最新的 FDate,然后把 crontab 调成 */5 8-22 * * *,覆盖业务作业时段。源端的轮询节奏是每 5 分钟一次,目标端我们错峰 2 分钟,设成 2-59/5 8-22 * * *,避免两端在同一秒集中请求源库。

第三步,稳定运行观察。 连续运行 3 个工作日,核对单据编号、仓库、货品三个维度是否完全对齐,确认无误后再把全量触发按钮从运维手册里移除。这是「增量与全量双轨」的典型做法:全量用于演练和应急,增量用于日常。

踩坑复盘

• 典型错误一:增量起点选了 FID 而非 FDate。 早期版本我们图省事用单据内码做游标,结果某次源系统重排后,游标跳号导致一周内的单据全部漏推。稳妥的做法是用 FDate + FBillNo 复合游标,轻易云里直接配成查询条件即可。
• 典型错误二:表头和表体一次性同步,失败重试造成重复行。 表头失败整单重推是合理的,但表体行一旦部分成功部分失败,重试就会重复写明细。我们后来改成「表头表体分阶段」:表头先写,成功后再写明细,失败只重试明细段。
• 仓库编码一对多。 一个金蝶组织对应旺店通多个逻辑仓时,只靠源端 FStockOrgId 是不够的,必须在中间层按业务规则再分一次,否则会出现「调拨去向正确,但落库仓库错」的情况。
• crontab 没避开业务高峰。 源系统上午 9 点是单据集中审核时段,如果把源端查询也压在同一时刻,会拖慢审核。错峰 2 分钟看似不起眼,实际生产环境里收益明显。
• 幂等键只看 outer_no 不够。 旺店通按 outer_no 去重,但我们这边如果同号改单(数量、仓库调整),目标端会拒绝更新。轻易云里需要把 outer_no 和 detail_list 的内容做一次哈希,作为二次幂等依据。

适用场景与不适用场景

适用于:多仓零售/分销场景下,跨仓库调拨需要实时驱动下游拣货流程,且两边主数据治理已经具备一定基础的团队。 不适用于:需要双向回写库存可用量的场景(本策略只做单向推送),以及调拨双方组织架构尚未在源系统冻结的客户——后者建议先做主数据治理再做集成。