调拨入库单同步方案实战:从旺店通到金蝶云星空
这个策略解决什么问题
调拨入库单,是仓库间调拨业务在目标仓库完成收货确认后生成的单据。我们在实际项目里碰到最多的痛点是:电商 WMS 里一张调拨单走完出库、入库,数据要回到 ERP 才能入账,但 WMS 的入库确认动作一旦没及时同步到 ERP,两边库存账就对不上,财务结账时差异一堆。
这个策略只做一件事:把旺店通·旗舰奇门里的调拨入库单,按"其他入库单 + 单据类型 DBRKD"落到金蝶云星空,自动提交并审核,把库存账和单据流在两套系统之间对齐。配合调拨出库单策略,就能形成完整的调拨闭环。
数据流向与字段映射
数据流向:旺店通·旗舰奇门(源) → 轻易云数据集成平台(中间层) → 金蝶云星空(目标)。
中间层负责按字段映射规则把源单结构转成金蝶的 STK_MISCELLANEOUS 表单能接受的格式,并通过 idCheck 机制保证增量同步不重复。
主表关键字段对照:
| 源字段(旺店通) | 目标字段(金蝶云星空) | 映射类型 | 说明 |
|---|---|---|---|
| order_no | FBillNo | DIRECT | 单据编号直接传递 |
| — | FBillTypeID | CONSTANT | 固定值 DBRKD,标识为调拨入库 |
| — | FStockOrgId | CONSTANT | 固定值 100,库存组织 |
| — | FStockDirect | CONSTANT | 固定值 1,普通入库方向 |
| check_time | FDate | TRANSFORM | 审核时间做日期格式转换 |
| — | FDEPTID | CONSTANT | 固定值 BM000032,部门 |
| — | FOwnerTypeIdHead / FOwnerIdHead | CONSTANT | 货主类型组织,货主编码 100 |
| operator_name | F_TPRO_Text5 | DIRECT | 源单操作人写入自定义字段 |
| — | F_TPRO_Text6 | CONSTANT | 固定值 调拨入库单,单据来源标识 |
| remark | F_UBGN_LargeText | DIRECT | 调拨入库备注透传 |
明细行字段对照(源 detail_list → 目标 FEntity,按行一对一):
| 源字段 | 目标字段 | 映射类型 | 说明 |
|---|---|---|---|
| detail_list.goods_no | FMaterialId | DIRECT | 物料编码 |
| detail_list.num | FQty | DIRECT | 实入数量 |
| to_warehouse_no | FStockId | DIRECT | 主表透传至明细行 |
| detail_list.price | FPrice | DIRECT | 成本单价 |
| detail_list.total_price | FAmount | DIRECT | 成本金额 |
| — | FUnitID | DIRECT | 取自明细行单位 |
| — | FOwnerTypeId / FOwnerId | CONSTANT | 货主类型与编码同主表 |
| — | FKeeperTypeId / FKeeperId | CONSTANT | 保管者类型与编码同主表 |
在轻易云上如何配置
在 Qeasy 的策略画布里,这一个策略主要配三块:源端查询接口、目标端保存接口、字段映射。
源端(Source):接口 wdt.wms.stockin.transfer.querywithdetail,类型 QUERY,POST 方法。主键字段配 stockin_id,业务编号字段配 order_no,开启 idCheck=true、autoFillResponse=true、buildModel=false。调度用 */50 7-20 * * *,覆盖业务时段。
目标端(Target):接口 batchSave,类型 EXECUTE,POST 方法。FormId 写 STK_MISCELLANEOUS(其他入库单),Operation 写 Save,并把 IsAutoSubmitAndAudit=true 与 IsVerifyBaseDataField=true 勾上,这样单据保存后会自动提交审核,省去人工。number 与 id 都配金蝶返回的主键 id。
字段映射:主表与明细都按上文的对照表配 DIRECT / CONSTANT / TRANSFORM 三类映射。日期字段 check_time → FDate 用表达式 {{check_time|datetime}} 做格式转换,避免字符串直接落到日期字段报错。这里没有跨方案的 _findCollection 或 _mongoQuery 联查,编码映射相对干净。
实施步骤
我们在客户现场通常按"建连接 → 配策略 → 灰度 → 切正式"四步走。
- 建连接:在轻易云里先建好旺店通·旗舰奇门和金蝶云星空两个数据源连接,测试连通和鉴权。
- 配策略:把上面这套调拨入库单策略落到一个策略里,源端、目标端、字段映射按本文配置。注意把
idCheck在源和目标两侧都打开,实现增量同步。 - 调度配置:启用
*/50 7-20 * * *的高频轮询,业务时段基本做到 50 秒一拉。需要全天跑的话,直接把小时范围扩成*即可,但要评估源系统压力。 - 灰度与全量:增量起点 先以"自部署当天起新增的调拨入库单"为起点,通过源端
idCheck自然过滤历史数据;全量触发 一般在历史数据需要补传时,临时关闭idCheck或用一次性补数脚本跑一次历史数据,完成后立刻恢复增量模式。
踩坑复盘
- 仓库字段取错:典型错误是看到"调拨"就把
from_warehouse_no(源仓库)塞到金蝶的FStockId。这里容易翻车——调拨入库单是在目标仓库做入库确认,FStockId必须取to_warehouse_no。from_warehouse_no只做业务参考,不参与映射。 - 日期字段直接传字符串:
check_time在源端是字符串,直接传会让金蝶报日期格式错误。稳妥的做法是配 TRANSFORM,用{{check_time|datetime}}转成金蝶能识别的日期。 - 货主/保管者编码漏配:明细行如果只配了主表的
FOwnerTypeIdHead,忘了明细行的FOwnerTypeId/FKeeperTypeId,保存时金蝶会提示基础资料校验失败。把明细行这两组字段都按 CONSTANT 补齐即可。 - 重复推送:两侧
idCheck必须都开。源端按stockin_id去重,目标端按金蝶返回的id去重,缺一就会出现"同一张单推两次"的现象,虽然IsAutoSubmitAndAudit会兜底,但日志里会留下一堆重复记录。 - 单据类型与库存方向不匹配:
FBillTypeID=DBRKD(调拨入库)对应FStockDirect=1(普通入库方向),这两个常量是绑定的,不要单独改其中之一,否则金蝶会判定单据类型与方向不一致而拒绝保存。
适用场景与不适用场景
适用:WMS 与 ERP 分离部署、需要在目标仓库确认收货后自动入账的调拨业务;希望免人工审核、追求库存账实时对齐的场景。
不适用:调拨出库(需要走单独的调拨出库单策略,本策略不处理);跨组织、跨法人调拨(本方案库存组织和货主都固定为编码 100,多组织场景需要按组织拆分策略);需要按批次/库位细粒度管理的调拨(本策略只到仓库级别)。