企业官网建设流程全解析

简介：这份文档面向SAP实施顾问、仓储业务分析师及MM/WM模块初学者，系统梳理WM模块从主数据到策略配置的完整落地路径，帮助读者理解仓库编号参数、存储类型与存储段划分、编号范围分配等基础设置，并掌握存储类型搜索、固定仓位、开放存储、托盘及先进先出等策略的启用逻辑。资源包共1个doc文件，约572KB，内容以配置步骤说明与项目实现文档为主，章节按MASTER DATA与STRATEGIES两大板块组织，便于按配置顺序查阅。已有789人学习下载，适合作为WM配置的对照手册与项目参考。读者可从中获得仓库主数据结构的设计思路、各类搜索与上架策略的适用场景，以及配置清单式的检查框架，用于梳理实施要点、排查配置遗漏，并为后续测试验证提供依据。

1. 仓库号不是"建个仓库"：SAP WM 配置的第一层抽象

很多人第一次打开 SAP WM 的配置树，会以为"定义仓库号"就是给物理仓库起个名字。翻车往往从这里开始：仓库号（Warehouse Number）在系统里根本不是地理概念，而是一个独立的组织单元，它把存储类型、存储区、仓位、编号范围、移动类型搜索全部收拢到自己名下。换句话说，仓库号是一套"仓库运行规则"的命名空间，物理位置只是它附带描述的东西。这份配置文档之所以从Define control parameters for warehouse number开篇，而不是从建仓位开篇，原因就在这里——控制参数决定了这个仓库号下 SU 管理是否启用、重量单位默认取什么、批次缺失时怎么处理，后面所有策略都建立在这些开关之上。搞懂这层抽象，才能理解为什么 WM 和 MM 的库存能对得上、又为什么经常对不上。

1.1 仓库号控制参数：几个开关决定了后面所有行为

文档里Define control parameters for warehouse number用事务码 SPRO 进入，给出的系统方案是一张参数表：仓库号 D01、重量单位 KG、第一默认单位 L、第二默认单位 A、分散仓库管理激活、SU 管理激活为 Yes、阻塞方式 B、部分拣配、容量检查、批次缺失（TR）等。这张表看着像填空题，实际上每一项都在给后续机制"定调"。

最值得盯的是SU management active = Yes。SU（Storage Unit，存储单元）管理一旦打开，系统在收货上架时就不是按"物料数量"找位置，而是按"一个存储单元占多少仓位容量"来找位置。这直接决定了后面存储单元类型（SUT）、仓位类型（Bin Type）、仓位搜索三者必须串起来配，否则上架策略会找不到可用仓位。常见的实现思路是：SU 管理开启后，仓位容量以"允许放几个 SU"计量，而不是以数量或体积计量，所以 SUT 的容量使用系数（Capacity usage）必须和仓位的最大 SU 数匹配。

Blocking method = B也容易被忽略。阻塞方式决定系统用哪套阻塞原因表来冻结仓位或库存，方式选错，后面"定义阻塞原因"章节即便标了 No changes，实际冻结行为也会和预期不一致。文档里 1.6 写"No changes"，意思是沿用模板 0001 复制过来的默认值，但前提是控制参数里的阻塞方式和模板一致——这是复制模板时最隐蔽的坑。

Batch Missing (TR)这一项控制的是：当转移需求（TR）涉及批次管理物料而批次尚未确定时，系统是报错还是放行。它属于"业务容错开关"，配置文档把它列在控制参数里而不是批次章节里，说明它影响的是 TR 生成阶段的校验强度，不是批次主数据本身。

提示：控制参数是仓库号的"宪法"，改一项可能让已上线的策略集体失效。上线后动这一页，必须连带回归上架、下架、盘点三条链路。

1.2 编号范围：为什么 TR、TO、Quant 要分开编

Define number ranges用事务码 OMLW，文档给了两组内容：1.2.1 Assignment 和 1.2.2 Intervals。Assignment 表里列了 Wh（仓库号）、Quan（Quant 编号范围）、NR-TO（转移订单）、NR-TR（转移需求）、Posting Change（过账变更）、RefNo（参考号），系统方案统一给 D01 分配了 01；Intervals 表里区间号 01，从 3000000001 到 3999999999，四类对象共用同一段区间。

这里的设计动机值得说透：TR（Transfer Requirement）是"需求"，TO（Transfer Order）是"执行指令"，Quant 是"仓位上的库存实例"，过账变更通知是"账务动作的载体"。它们是仓库内部四种不同生命周期的对象，但共用一段编号区间并不冲突，因为编号范围是按对象类型分别维护的，区间相同只是省事，系统不会把 TR 号和 TO 号混在一起。真正要小心的是 Assignment 和 Intervals 必须成对配：只配区间不分配给仓库号，创建 TR 时会报"编号范围未分配"；分配了但区间被别的仓库号占用，则会撞号。

文档里区间起点定在 30 亿段，是典型的"给历史数据留空间"做法——低位段留给从旧系统迁移或模板复制产生的号，新号从高位起，避免和已有数据冲突。这种细节文档不会解释，但从区间选择能反推出实施时的迁移策略。

1.3 存储类型：上架策略的挂载点

Define storage type的表里，902 是"GR Area From Vendor"、911 是"GI Area for Cost Center"、914 是"GI Area Production"、916 是"Shipping Area Deliveries"、921 是"Stock Transfers (StLoc)"、922 是"Posting Change Area"、998 是"Init. entry of stock bal."、999 是"Differences"，另外还有 ZM1"Storage Area"和 ZM2"Issue Precedence Area"，两者都标了 SU 管理激活、上架策略 PF、下架策略 PF。

这张表透露了 WM 的一个核心设计：存储类型分两类，一类是"物理存储区"（ZM1、ZM2），一类是"功能过渡区"（902、911、914、916、921、922、998、999）。过渡区不参与真实上架策略，它们是收货、发货、过账变更、盘点差异这些动作在仓库内部的"落脚点"。比如 902 收货区，货物从 MM 过账后先落到 902，再由上架策略搬到 ZM1；911 发料区则是下架的目标暂存区。理解这一点，才能明白为什么 2.1 的存储类型搜索表里，移动类型 101 要指向 902、201 要指向 911——搜索表本质上是"移动类型 → 目标存储类型"的路由表。

ZM1 和 ZM2 都配了Stock placement strategy = PF和Stock removal strategy = PF。PF 在标准策略里代表"托盘上架/下架"相关策略族，具体走哪条由后面的策略激活和排序决定。这里的关键是：存储类型上的策略字段只是"允许哪族策略"，真正生效要靠 2.x 章节的激活表和搜索顺序。很多人配完存储类型就以为策略生效了，结果上架还是走默认，问题就出在没激活搜索。

1.4 存储区与仓位类型：把仓库切成可搜索的格子

Define storage sections给 D01 定义了 ZM1001 普通仓位区、ZM1002 过渡仓位区、ZM1003 仓库工作区、ZM2001 总计区。存储区是存储类型内部的细分，作用是让"存储区搜索"（2.2 节，事务码 OMLZ）有粒度可查。文档 2.2 的表里，存储类型 ZM1、存储区 0001、存储区类别 002，说明搜索是按"存储区类别"匹配的，不是按存储区编号硬编码。

Define storage bin types定义了 D01 下的 D01 普通仓位类型、E1 过渡仓位、B1 返工区、P1 拣配区。仓位类型描述的是"仓位的物理形态"，和存储单元类型（SUT）配合使用：2.3.3 把 SUT S1 分配给仓位类型 E1、B1、P1，2.3.4 又把 SUT S1 分配给存储类型 ZM1、ZM2。这两步方向不同——前者是"这种仓位能放哪种 SU"，后者是"这个存储类型允许哪种 SU"，双向约束都满足，仓位搜索才会返回结果。

Define storage bin structure（事务码 LS10）是这一层最有技术含量的部分。表里每个存储类型对应一个结构模板，比如 ZM1001 的模板是AANNNNCCCCABCCDD，起始 AA0101，结束 AB0302，增量 11；ZM1006 是CNNCCCCCCC，起始 AAF01，结束 F99，增量 01。模板串里的字母是占位符：A 段、N 段、C 段分别代表仓位编号的不同位，系统按模板生成仓位主数据。增量 11 表示每生成一个仓位，编号按 11 递增，这决定了仓位的物理排布节奏。

注意：仓位结构模板一旦生成仓位并被库存引用，就不能随意改模板串。改结构等于改仓位编号规则，已存在的仓位不会自动重排，新旧编号会混在一起，后续按结构搜索会漏仓位。

1.5 存储单元类型与指示器：容量计算的输入

Define storage unit types只给了一条：D01 下 SUT S1，名称 Normal SU，容量使用系数 1。这个系数是容量检查的乘数——仓位允许的 SU 数乘以系数，得到实际可用的容量单位。系数配 1 是最朴素的"一托一位"，如果业务里有混托、半托，系数就要按实际占用调整，否则容量检查要么过松（允许超放）要么过严（明明有空位却报满）。

1.8 到 1.12 这几节——存储类型指示器、存储段指示器、特殊移动指示器、阻塞存储指示器——文档全部标了"No changes"。这不是说它们不重要，而是说这套配置沿用了模板 0001 的默认值。默认值能用的前提是：仓库的移动类型、阻塞原因、特殊流程没有超出标准范围。一旦业务要求"某些物料只能进特定指示器标记的仓位"，这几节就必须回头补配，而且要和 2.x 的策略搜索联动，否则指示器配了也没人查。

2. 上架策略：搜索表才是真正的路由引擎

配置完主数据，很多人以为策略是在存储类型上"选一个"就完事。实际机制是反过来的：存储类型只声明"允许哪族策略"，真正决定货物去哪的是三张搜索表——存储类型搜索（OMLY）、存储区搜索（OMLZ）、仓位类型搜索（OMM1），加上一张上架排序表（OMLM）。这四张表按顺序逐层收窄，像路由器一样把一次移动类型拆解成"目标存储类型 → 目标存储区 → 目标仓位类型 → 具体仓位"。搞不清这个顺序，策略配了也是玄学。

2.1 存储类型搜索：移动类型到目标类型的第一跳

2.1 的表结构是：Wh（仓库号）、ActTy（激活类型/搜索标识）、Ind（指示器）、SS（搜索顺序）、Stor（存储类型）、WP Ref（工作区参考），后面 1 到 0 十列是搜索步骤。D01 下配了多行：200对应 200 步、2K对应 2K 步、2Q对应 2Q 步、A对应 A 步，其中 A 步指向 ZM2 和 ZM1，AK 步指向 ZM1，AQ 步指向 ZM1，E 步指向 ZM1，EK、EQ 步也指向 ZM1。

这套编码的含义是：搜索标识（如 200、2K、2Q、A、E）代表不同的"上架场景类别"，系统按移动类型先找到对应的搜索标识，再按标识下的步骤顺序逐个尝试存储类型，第一个满足容量和约束的就被选中。文档紧接着列了一张"Define Movement Type References"大表，把 101、103、201、261、301、311、319、321、501、521、551、561、601、651、711、911、919、920、921、922、961、998、999 等移动类型逐一映射到搜索标识。比如 101 收货映射到 101 标识，201 发料映射到 201，319 生产补料映射到 319，919 线边补料映射到 319，920 生产退料映射到 319。

这张映射表是整个 WM 上架逻辑的"黑匣子入口"。移动类型在 MM 侧只是一个过账代码，进了 WM 就变成"该走哪条搜索路径"的指令。常见的实现思路是：标准移动类型自带默认搜索标识，实施时通过这张表覆盖或补充，让特殊业务（比如退货、返工、线边补料）走不同的存储类型序列。文档里 202 取消发料映射到 999、256 取消一般发料映射到 999、552 取消报废映射到 999，说明"冲销类"移动统一落到 999 差异区，这是标准做法——冲销不产生真实上架，只做账务回退。

提示：搜索表里同一搜索标识下的步骤顺序就是优先级。把 ZM1 放在 ZM2 前面还是后面，直接决定货物先进哪个区。调整顺序前先确认两个区的容量和 SUT 约束是否都满足，否则第一跳就被容量检查挡回来，顺序等于没调。

2.2 存储区搜索与仓位类型搜索：第二跳和第三跳

2.2 节Activate storage section search用事务码 OMLZ，表里只有一行：Wh D01、NTy ZM1、Ssec 0001、Class 002，后面 1 到 0 十列。含义是：存储类型 ZM1 下，按存储区类别 002 去搜索存储区 0001。存储区类别是存储区主数据上的分类字段，搜索时按类别匹配而不是按编号，这样新增同类别存储区时不用改搜索表。

2.3 节Activate storage bin type search用事务码 OMM1，文档在这一节下拆了四个小节：2.3.1 定义仓位类型（D01、E1、B1、P1）、2.3.2 引用 1.9 的 SUT、2.3.3 把 SUT S1 分配给仓位类型 E1/B1/P1、2.3.4 把 SUT S1 分配给存储类型 ZM1/ZM2。2.3.4 的表头是 Wh、Ty、1 到 0 十列，D01 下 ZM1 对应 S1、ZM2 对应 S1。

这里有个容易看漏的细节：2.3.3 和 2.3.4 是双向分配，但文档在 2.3.4 标题写的是"Assign Storage unit types to Storage bin types NA"，正文表却填了 ZM1/ZM2。这说明原始模板里这一节可能标了不适用（NA），实施时又补了值。双向分配的意义在于：仓位搜索时，系统既要确认"这个仓位类型能放这种 SU"，也要确认"这个存储类型允许这种 SU"，两个方向任一不满足就跳过该仓位。只配一边，搜索会静默失败——不报错，只是找不到仓位，然后回退到下一个存储类型，表现为"货莫名其妙进了别的区"。

2.4 上架排序与策略族：PF 到底走哪条

2.4 节Define Sort Sequence for Putaways用事务码 OMLM，表里只有表头 Wh、Ty 和 1 到 0 十列，没有填值。排序表的作用是：当同一存储类型下有多个候选仓位时，按什么字段排序（比如仓位编号、容量、存储区）。不填就走系统默认排序。

2.5 到 2.10 这几节——固定仓位策略、开放存储策略、追加现有库存策略、空仓位策略、托盘策略、散装存储策略——文档大多写"See 1.3 or refer directly to customising"，意思是策略的具体参数挂在存储类型主数据上，1.3 已经配了 PF，细节按需在定制里补。2.9 托盘策略单独展开：2.9.1 存储类型控制引用 1.3，2.9.2 定义仓位分区，2.9.3 把仓位分配给 SUT。这三步是托盘策略能跑起来的最小闭环——存储类型声明策略族，仓位分区给出物理分区，SUT 分配给出容量约束。

2.11 到 2.18 是下架策略族：FIFO、严格 FIFO、LIFO、部分托盘数量、大小数量、到期日，以及自开发扩展（2.11.1 开发策略、2.11.2 激活策略；2.18.1 开发拣配策略、2.18.2 激活）。文档对标准策略大多写"See 1.3"，对自开发只写"Refer to programming request, if needed"。这透露了一个实施现实：标准策略覆盖不了的场景（比如按客户定制批次规则、按产线优先级下架），才走自开发，而自开发策略必须先在存储类型上激活对应标识，否则代码写了也不会被调用。

3. 避坑与排查：配置文档里那些"No changes"背后的雷

这份文档大量出现"No changes"和"See 1.3"，看起来省事，实际是踩坑高发区。下面几条是按"现象 → 原因 → 解决"整理的常见翻车记录，都是配置顺序和联动关系没对齐导致的。

现象一：收货后货物进了 902，但上架 TO 一直生成不出来。原因：存储类型搜索表里 101 映射的搜索标识下，目标存储类型 ZM1 的容量检查不通过，或者 SUT 双向分配只配了一边（2.3.3 配了、2.3.4 没配）。系统找不到可用仓位时不会硬报错，而是停在 902 等待人工处理。 解决：先用仓位搜索的模拟功能确认 ZM1 下有没有满足 SUT 和容量的空仓位；再核对 2.3.3 和 2.3.4 两张表是否都填了 S1；最后检查 ZM1 的容量使用系数是否和实际托盘数匹配。

现象二：改了仓位结构模板，新生成的仓位编号和旧仓位撞号。原因：LS10 的模板串和增量改了，但已存在的仓位不会重排，新号从新起点生成，和旧号落在同一段。 解决：改结构前先查该存储类型下已有仓位的最大编号，把新模板的起始值放到最大编号之后；如果必须重排，走仓位主数据迁移而不是直接改模板。

现象三：冲销移动类型（202、256、552）过账后，库存回到了 ZM1 而不是 999。原因：2.1 的移动类型引用表里，冲销类移动映射到了 999，但 999 存储类型的 SU 管理或容量检查配置和 ZM1 不一致，系统回退到了默认存储类型。 解决：核对 999 存储类型的控制参数，确认它允许无 SU 管理的过账；再检查搜索表里冲销标识的步骤顺序，确保 999 排在第一位。

现象四：批次管理物料收货时，TR 生成报"批次缺失"。原因：仓库号控制参数里Batch Missing (TR)设成了严格校验，而收货时批次尚未确定。 解决：按业务容忍度调整该开关，或在 TR 生成前先做批次确定；不要直接关掉校验，否则批次追溯会断链。

现象五：自开发下架策略写了代码，但下架还是走标准 FIFO。原因：存储类型上只激活了标准策略标识，自开发策略的激活标识没配，或者 2.18.2 的激活步骤漏了。 解决：在存储类型的下架策略字段里加上自开发标识，并在策略搜索顺序里把它排到标准策略之前；用下架模拟验证代码是否被调用。

4. 设计取舍：为什么 WM 要把"策略"和"主数据"拆成两层

回头看这套配置，最值得琢磨的设计取舍是：为什么存储类型只声明"允许哪族策略"，而把真正的路由逻辑放到搜索表和移动类型引用表里？如果按直觉设计，完全可以在存储类型上直接写"101 进这里、201 出那里"，一张表搞定。WM 没这么做，是因为仓库的移动类型有几十上百个，存储类型也有几十个，如果两两硬编码，配置量是乘积级，改一个移动类型要动所有相关存储类型。

拆成两层之后，存储类型只回答"我允许什么"，搜索表回答"这次移动该去哪"，移动类型引用表回答"这个移动属于哪类场景"。三者解耦，新增一个移动类型只需要在引用表加一行，新增一个存储类型只需要在搜索表加一列，互不影响。代价是配置分散在四五个事务码里，排查问题时必须沿着"移动类型 → 搜索标识 → 存储类型序列 → 存储区 → 仓位类型 → 仓位"这条链一路查下去，任何一环断了都表现为"找不到仓位"这种没有明确报错的玄学现象。

这也是为什么这份文档把 1.x 主数据和 2.x 策略分开写：主数据是"静态约束"，策略是"动态路由"，两者的变更节奏不同。主数据改一次影响面广、要回归测试；策略改一次只影响特定移动类型，可以灰度。实施时把这两层分开评审，比混在一起改要稳得多。

我自己的习惯是：每次动搜索表或移动类型引用表之前，先把受影响的移动类型列出来，沿着链路做一遍模拟上架和下架，确认每一跳都有候选仓位再保存。血泪经验是，WM 的配置错误很少当场报错，它总是安静地回退到默认行为，等你发现库存对不上时，已经过了好几个账期。从那以后我每次改完策略配置，都强制走一遍"模拟上架 + 模拟下架 + 冲销"三件套再放行。希望帮到你。

本文还有配套的精品资源，点击获取