WMS 仓库主数据同步实战：从 WMS 拉到 ERP 的单一策略落地

这个策略解决什么问题

仓库主数据是供应链集成的"地基"。某零售企业同时使用 WMS 与 ERP，两边都各自有自己的仓库档案，编码规则也不一致。结果是：单据流转时找不到对应的仓库、库存数据口径对不上、报表合并时一堆手工对账。

「WMS-仓库查询」策略只解决一件事：把 WMS 里的仓库档案定时拉到集成平台，作为后续物料、客户、订单等主数据同步的前置依赖。仓库没拉通，下游所有策略都跑不稳。

数据流向：WMS（源） → 轻易云数据集成平台（中间层） → ERP（目标）。

源端接口为 getWarehouse（POST），按仓库编码列表、是否支持分销、是否为某类特殊仓库等条件分页查询；目标端通过 batchSave 批量写入。关键字段对照如下：

业务含义	WMS 源端字段	类型	ERP 目标字段	类型	备注
仓库编码	warehouseCode	string	FNumber	string	主键，幂等依据
仓库名称	warehouseName	string	FName	string	必填
仓库 ID	warehouseId	int	id（id)	string	回写关联
仓库类型	warehouseType	string	FStockStatusType	string	枚举映射
使用组织	—	—	FUseOrgId	string	默认为 100
创建组织	—	—	FCreateOrgId	string	默认为 100
描述	remark	string	FDescription	string	可选

FUseOrgId 与 FCreateOrgId 在目标端是必填且默认 "100"，但源端并不存在这两个字段——这是典型的目标端补字段场景，配置时要写死或从上下文组织映射表中取。

在轻易云数据集成平台（Qeasy）上，配置思路分三块：

1. 源端连接器：选 WMS 平台对应连接器，填入认证信息（已脱敏），接口选 getWarehouse，请求体按数组传 warehouseCodeList，分页参数视接口规范而定。

2. 字段映射与清洗：

启用编码映射集中管理：把 WMS 的 warehouseCode 与 ERP 的 FNumber 显式绑定，存到统一映射表；后续任何主数据策略都能复用这张表，避免每个策略各写一份。
idCheck 打开：用 warehouseId 做幂等校验，重复拉取不重复写入。
FStockStatusType 等枚举字段，写转换函数，不要硬写在脚本里，方便后期维护。

3. 目标端写入：选 ERP 平台的 batchSave，组织字段 FUseOrgId、FCreateOrgId 走常量赋值；启用平台自带的「自动填充响应」按需关闭——本策略是基础资料写入，不依赖返回值，建议关闭以提升吞吐。

我们在一个实际项目里是这么推的：

阶段一：增量起点。首次配置不碰存量，只拉启用时间之后的仓库变更。在源端 getWarehouse 请求里加一个 updateTime 起止条件，确认数据通。

阶段二：全量触发。

阶段三：调度频率。

阶段四：依赖编排。仓库策略是 sequence=A，是所有下游基础资料（客户、供应商、物料）的前置。在轻易云的策略依赖图里把它放到最上游，下游策略 depends_on 引用它的策略 ID。

1. 组织字段没补，直接报错。 源端没有 FUseOrgId、ERP 又必填，第一次跑全量 100% 失败。稳妥做法是配置前先把目标端必填字段列出来，源端没有的全部走常量或上下文。

2. 编码映射散落在脚本里。 早期项目每个工程师各写一份映射规则，3 个月后两边对账差了几条仓库，谁也说不清规则在哪。后面所有项目统一走编码映射集中管理，变更只改一处。

3. 增量窗口错位导致漏数据。 WMS 与平台服务器有时区差，直接用 updateTime > 昨日 00:00 会漏掉边界附近的数据。稳妥做法是用「上次成功时间 - 5 分钟」做起点，留出重叠窗口。

4. 全量写入没分批，把目标端事务打爆。 一次性 batchSave 几千条仓库，ERP 端事务超时。稳妥做法是按 ID 分段，每批 200 条，失败可重试。

适用：单一组织或少量组织的 WMS-ERP 主数据拉通；以下游基础资料同步为前置；仓库档案变更频率不高（日均 < 百级）。

不适用：多组织、跨法人、需要走审批流的仓库档案；实时性要求 < 1 分钟的库存可用量查询（那是即时库存策略的活）；跨异构系统的双向同步（建议拆成两个单向策略）。