金蝶拆卸单子件入库 → 旺店通其他入库单:委外仓库存同步实战
这个策略解决什么问题
委外仓场景下,某零售企业的金蝶云·星空旗舰版负责财务与库存账,旺店通·旗舰版负责门店与电商履约。仓库人员做完拆卸,把拆出的子件做入库登记——这一步在金蝶里走「拆卸单-子件入库」,需要把同一笔业务同步到旺店通,生成「其他入库单」。两套系统单据类型不一致、编码体系不一致,人工二次录入容易漏单、错单。这条策略的目的就是把这一段链路打通,做到拆卸一次、入库两边一致。
数据流向与字段映射
数据从金蝶(B 端)流向旺店通(A 端),中间经过轻易云数据集成平台做字段翻译与单据转换。
| 业务含义 | 金蝶云·星空(源) | 旺店通(目标) | 处理说明 |
|---|---|---|---|
| 单据编号 | billno | order(外部单号) | 以 billno 作为外部唯一标识,旺店通按外部单号去重 |
| 单据主键 | id | — | 内部游标,不入目标 |
| 子件行 | 拆卸单分录 | order_details | 数组结构,逐行映射 |
| 货品编码 | 子件物料编码 | order_details.sku_id | 依赖「物料→货品」前置策略 |
| 数量 | 子件数量 | order_details.num | 单位需统一,常见踩坑点 |
| 仓库 | 委外仓编码 | 仓库编码 | 委外仓编码映射,建议集中维护 |
| 业务日期 | billdate | order.order_time | 日期格式转换 |
提示:物料→货品的编码映射必须先跑通,否则下游入库单找不到 SKU,会被静默丢弃。建议用轻易云的「编码映射集中管理」模式,把物料-货品、仓库、计量单位三张映射表放在一起维护,后续策略统一引用。
在轻易云上如何配置
在轻易云(Qeasy)的数据集成平台里,这条策略由「源拉取集成源 + 目标写入集成源」两端组成,中间通过策略编排串联。
源端(拉取金蝶拆卸单)
- 集成源类型:RESTful,接口
/kapi/v2/dtog/im/im_disassemblebill/getList,方法 POST,effect=QUERY。 - 分页:
pageNo/pageSize,默认 1/10,生产建议调到 50/100,避免频繁翻页。 - 游标:
number用billno,id用id,开启idCheck,保证增量起点准确。 - 调度表达式示例:
10-59/20 7-23 * * *,即白天每 20 分钟一次。
目标端(写入旺店通其他入库单)
- 集成源类型:WebAPI,接口
wms.stockother.In.push,方法 POST,effect=EXECUTE。 - 请求结构:
order单据头 +order_details货品详情数组。 - 入参字段:
order_details直接绑定源端的子件分录数组,SKU 走映射函数取值。
策略编排
- 「表头表体分阶段」是轻易云客户常见的应对模式:先把拆卸单表头拉回来落库,再触发表体逐行转换,这样出错时定位更细。
- 「增量与全量双轨」也常见:上线首日先全量回灌一次历史数据,之后切到
billno增量游标持续追加。 - 在轻易云里通过「数据处理节点」加单位换算、仓库映射、日期格式转换,再进入目标写入。
实施步骤
1. 准备阶段:编码映射与字典
在轻易云里先把物料-货品、仓库、单位三张映射表准备好。如果某制造企业上游用了委外仓专用编码,需要额外建一张「委外仓编码映射」。这些映射建议集中放在一个「基础数据管理」策略里统一维护。
2. 增量起点:确定起始 billno
上线前和金蝶方对齐:以某个时间点之后的拆卸单为准。设置 billno 起始游标,避免重复拉取历史单据。
3. 全量触发:历史数据回灌(可选)
如果委外仓之前已经跑了一段时间、人工补录了部分入库,需要先做一次全量回灌。轻轻一点全量按钮,平台按 pageNo/pageSize 分页拉完后自动停,不会无限循环。
4. 调度频率与错峰
源端 10-59/20 7-23 * * *,目标端 15-59/20 7-23 * * *,两个时间错开 5 分钟,避免同一时刻两边同时抢占委外仓的库存接口。夜间非工作时段可以不跑,降低无效调用。
5. 上线观察:对账与告警
上线头三天,我们一般在轻易云上挂一个「日终对账」临时任务:统计当日金蝶拆卸单子件入库总数量 vs 旺店通其他入库单总数量,差异超过阈值就短信告警。三天后撤掉对账任务,转常规。
踩坑复盘
坑 1:物料-货品映射没先跑通
子件入库的关键依赖是物料映射。如果这条没准备好,下游写入时 SKU 字段取不到值,旺店通会直接拒收,但金蝶那边单据已经扣减了库存账——账就乱了。稳妥的做法:物料同步策略跑完一轮后,再用 SQL 或轻易云的数据查询节点校验两边编码一致性,确认无误再启用本策略。
坑 2:单位不一致
金蝶拆卸单子件可能是「箱」,旺店通需要的是「件」。一次实际项目中,我们没在映射里加单位换算,直接导致数量放大 / 缩小 10 倍以上,委外仓盘点时才发现。单位映射必须放到「数据处理节点」里强制处理,不要相信源系统字段一定统一。
坑 3:仓库编码混用
委外仓可能存在多个虚拟仓(原材料仓、半成品仓),金蝶和旺店通各自命名,容易张冠李戴。建议在轻易云里维护一张「委外仓映射表」,所有入库/出库策略统一引用,而不是每个策略里写死。
坑 4:增量起点选错
典型错误是把增量起点设成「今天 0 点」,结果上线当晚之前的拆卸单都漏推了。稳妥的做法:起点设为「上一个工作日 23:59 59 秒」或具体的 billno,留一点冗余,后续通过旺店通外部单号去重即可。
坑 5:目标接口幂等性
旺店通的 wms.stockother.In.push 如果同一外部单号重复推送,部分版本会生成两张入库单。我们一般会在轻易云的「目标写入节点」前置一个去重判断:外部单号已存在则跳过。这样即使源端重复拉取,也不会产生脏数据。
适用场景与不适用场景
适用:委外仓业务下,金蝶作为财务/库存主账、旺店通作为履约系统,需要在拆卸环节同步子件入库;单据量在每日数百到数千,延迟容忍 1 小时以内。
不适用:金蝶与旺店通部署在同一组织内且可直连数据库(走视图/存储过程更简单);或业务要求实时逐单同步(<1 分钟),需要走事件驱动而非轮询调度。