企业官网建设流程全解析

简介：SAP 仓库管理模块 WM 基本中英文对应和解释资源面向 SAP 仓储管理初学者、实施顾问及物流仓储业务人员，帮助读者厘清 WM 模块常见术语的中英文表达与基本概念，解决英文界面阅读、项目沟通和配置理解中的术语障碍。资源包共 1 个 docx 文件，约 16KB，内容以术语对照和概念解释为主，轻量便于查阅。资料围绕工厂、存储地点、仓库号、存储类型、存储分区、拣货区、集结区、仓位、托盘及转储单等核心对象展开，并延伸到仓库联合、存储类型划分、拣货区用途、仓位主数据与入库策略等知识点，对理解仓库组织结构和主数据配置有一定参考价值，可作为日常速查或入门梳理材料。已有 999 人学习，适合需要快速建立 WM 术语框架、查阅中英文对应关系并辅助项目沟通的读者。

1. 仓库号到底建几个：从一张 SAP 仓库管理模块 WM 中英文对照表说起

拿到一份 SAP 仓库管理模块 WM 的中英文对照表，很多人的第一反应是背单词：Plant 是工厂，Storage Location 是存储地点，Warehouse Number 是仓库号，Storage Type 是存储类型。背完之后坐到系统面前，仍然不知道第一个配置该点哪里。问题不在翻译，而在这张表没有告诉你对象之间的层级关系。某制造企业上线 WM 时，项目组按建筑数量建了四个仓库号，结果跨建筑的转储单在系统里要拆成四段走，盘点周期也对不齐，返工两周才并回一个仓库号。这份 SAP WM 基础对象的中英文对应与解释，价值在于把「仓库号管到哪一层、存储类型切到什么粒度、仓位编码怎么定」这三件事在动配置之前讲清楚。它适合刚接触 WM 的顾问、内部 Key User 和运维人员，不适合已经能做到库位优化算法层面的老手。

2. 仓库号与仓库联合：Plant、Storage Location 的三层落位与判定表

2.1 三层落位：工厂、存储地点、仓库号各管什么

Plant（工厂）是生产、采购和库存估价的组织单位，Storage Location（存储地点）是工厂之下管理库存的地点，这两个对象属于 IM 库存管理层面。Warehouse Number（仓库号）是 WM 层面的组织单位，存储类型、存储分区、仓位都挂在它下面。同一个物料在 IM 里看到的是存储地点级的总库存，在 WM 里看到的是拆到具体仓位的 Quant（份），两套视图靠接口同步。

配置上的落位动作只有一步：把仓库号分配给工厂加存储地点的组合。常见路径是 SPRO > Enterprise Structure > Assignment > Logistics Execution > Assign Warehouse Number to Plant/Storage Location。一个存储地点只能分配给一个仓库号，一个仓库号可以覆盖同一工厂下的多个存储地点，这也是后面讨论「仓库联合」的前提。很多人在这里翻车，是因为把「仓库号」理解成了物理建筑，于是每栋楼建一个号，单据流立刻碎掉。

2.2 一个仓库号还是多个：仓库联合的判定标准

原资料给出的推荐很明确：一个仓库号管理某一地域的一组仓库建筑群，称为仓库联合；几个仓库设施在地理上离得很远，才考虑分别建仓库号；同一个工厂区一般用一个仓库号。这句话听起来简单，落地时需要一张判定表，否则会上会吵成一团。

这张表里最容易被忽略的是「单据流」。转储单（Transfer Order）和转储申请（Transfer Requirement）都以仓库号为边界，跨仓库号的移动在系统里表现为两段甚至多段，库存中间状态会多出一层在途。只要业务上希望「从收货区到高架区」是一张单走完，就应该放在同一个仓库号下，用存储类型区分建筑，而不是用仓库号区分建筑。

2.3 建仓库号之前必须定下的参数

仓库号不是建完就完的对象，它级别上挂着几类参数，建之前不定，后面改起来要停作业。原资料提到仓库号级别可以定义仓库管理使用的单位，也可以定义 WM 和 PP 等其他模块的接口，这两项都属于「定了就不好动」的类型。

我一般的做法是先让业务画一张建筑平面图，标出收货区、发货区、高架区、堆放区、拣货区，再拿 2.2 的表逐项打分，最后在纸上写出「仓库号 → 存储类型 → 存储分区」三级清单，确认没有跨仓库号的日常移动，再进系统点配置。这个顺序反过来做，后面补存储类型时就会发现仓位编码规则和建筑编号打架，只能删数据重来。

3. 存储类型与存储分区：强制一条分区背后的搜索逻辑

3.1 存储类型是「区域」，不是「货架」

原资料里有一句容易被跳过的话：存储类型实际上称作存储区域更合适，它包括仓储设备和仓储区，在仓库号下面定义。它可以是物理区域，也可以是逻辑区域，划分依据是仓储技术（自动仓、半自动仓、高架货架）、使用空间、组织形式或功能。收货区、发货区、高架货架区、堆放区、固定仓位拣货区，每一个区域在 WM 里都是一个存储类型。

标准 SAP WM 系统预定义了几个常用存储类型，比如一个高架区、一个堆放区、一个拣货区，这些类型已经配好了不同的控制参数，包括上架策略、下架策略和盘点方法。落地时不要从零新建，常见做法是拷贝预定义类型到自己的仓库号下，再按公司实际修改。这样做的好处是控制参数有一套可用的默认值，坏处是拷贝时容易把示例仓位的编码规则一起带过来，所以拷贝完第一件事是检查仓位编码长度和分隔符是否符合自己的规则。

存储类型这一层承载的是控制参数，这一点必须记住。上架策略决定一批货进来往哪类仓位建议，下架策略决定出库先取哪类仓位，盘点方法决定这个区域用连续盘点还是年度盘点。后面讲的存储分区不能定义这些参数，原因就在这里。

3.2 存储分区为什么必须有一条：一对多与强制约束

Storage Section（存储分区）是存储类型下面的细分组织结构，指一些具有共同入库管理特性的仓位的集合。划分方法比较灵活：可以按存放货物的重量分，底层重物区、中层中等重量区、高层轻型区；可以按货物移动频率分，快速移动区、缓慢移动区；也可以组合，比如快速移动重型货物区、快速移动轻型货物区、缓慢移动重型货物区。存储类型和存储分区通常是一对多的关系。

这里有一个系统约束：WM 强制要求为每一个存储类型至少定义一个存储分区。只建一个分区，实际上等于没有对存储类型做细分，此时分区和存储类型是一对一。为什么强制？因为上架时的仓位定向选择落到分区这一级，系统需要在存储类型内部有一个可供搜索的粒度，哪怕这个粒度就是整个区域。分区里不能定义任何控制参数，这些参数从存储类型传递下来，分区只负责「把仓位分组」。

实际项目里最常见的误用是：为了满足「至少一个」的检查，随手建一个编码为 0001 的分区，把所有仓位都挂进去，然后抱怨上架策略不生效。策略本身没坏，是分区没有提供任何区分度，搜索顺序再细也筛不出东西。

3.3 分区划分的实操步骤与判定表

划分分区不要追求细，追求「每一刀都有业务含义」。原资料说得很直白：存储分区的定义一定要有目的性和实际意义，通常集中在同一个物理区域。我在项目上一般控制在 2 到 5 个分区，超过 5 个，维护成本和现场培训成本会明显上升。

具体步骤可以照着走：

1. 打印仓库平面图，用不同颜色标出物理区域和仓储设备类型，先确认哪些区域本身就不能混放。
2. 对每个区域按入库特性打标：承重区间、周转频率、是否允许混批次。
3. 合并标签相同的区域，形成 2 到 5 个候选分区，给每个分区起一个带含义的两位编码，比如 01 重货、02 中件、03 轻件。
4. 在仓库号下建存储类型，再在存储类型下建分区，把仓位按物理位置挂到对应分区。
5. 拿三到五笔真实入库单做测试，看转储单建议的仓位是否落在预期分区；落错就回查搜索顺序，而不是先改分区。

提示：分区编码一旦有库存再改，已存在的仓位需要重新挂接，测试环境先跑一遍再动生产。

4. 仓位主数据与上架搜索：坐标、载重与仓位类型的组合打法

4.1 仓位坐标怎么定：01-02-03 的编码权衡

Storage Bin（仓位）是仓库管理最小的空间单位，描述某一货物将要存放或已经存放的位置。最常见的编码是 01-02-03 这种坐标值，首两位表示货架编号，中间两位表示列号，后面两位表示层号。也可以把中间两位定义成层号、后面两位定义成列号，取决于现场怎么看货架。仓位可以用英文字母、数字和字符混合定义，没有强制格式。

真正需要权衡的是分隔符。省略分隔符可以减少 WM 作业中仓位的输入信息，但增加了识读难度。纸质拣货单上，010203 和 01-02-03 对现场作业员来说是两种体验，前者快，后者不容易看错行。我的经验是：如果仓库以手持终端扫码为主，可以省分隔符；如果还有大量纸质单据和口头报位，保留分隔符更稳。

4.2 仓位主数据字段：载重、总能力、防火分区、仓位类型

在 SAP WM 中，仓位作为主数据存在，不是仓库内部的组织结构，这一点和存储类型、分区都不同。仓位主数据里有几个字段直接决定上架能不能过：

总能力这个字段是最容易出问题的地方。它是纯数字，系统不知道你填的 1000 代表 1000 公斤还是 1000 箱。如果仓库里一部分人按托盘数填、一部分人按件数填，容量检查就形同虚设。上线前必须出一份填写规范，写清楚「总能力 = 标准托盘数」，并在主数据导入模板里加校验。

4.3 用仓位类型加托盘类型做上架搜索

原资料提到一个很实用的做法：在入库策略中结合仓位类型和托盘类型，可以实现灵活多变的上架方式；某个项目里用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。这句话展开就是一套替代方案。

Storage Unit Type（托盘类型）描述装载单元本身，比如标准托盘、大尺寸托盘、小件周转箱。Storage Bin Type（仓位类型）描述仓位能接什么，比如重型货位、轻型货位、窄巷道货位。存储类型里配置上架搜索顺序，把仓位类型作为搜索条件之一，系统就会按托盘类型把货导向不同的仓位类型，而不需要把存储类型切成很多分区。

落地步骤：

1. 按现场实际载具定义托盘类型，不要按物料定义，否则主数据量会失控。
2. 按货架承重和巷道尺寸定义仓位类型，并在仓位主数据里逐个挂上。
3. 在存储类型的上架策略里配置搜索顺序，把仓位类型作为条件，顺序按「先满足承重、再满足路径」排。
4. 用不同托盘类型的入库单各测三笔，检查转储单建议仓位是否落在对应类型，落错先看搜索顺序的优先级，不要急着加分区。

注意：搜索顺序是「建议」不是「强制」，现场仍然可以手工改仓位，所以测试时要看建议值，不要看最终确认值。

4.4 用 LGPLA 和 LQUA 核对仓位与库存

配置完之后，最直接的验证是从表里拉数据对一遍。仓位主数据在 LGPLA，Quant 在 LQUA，前者看编码和类型，后者看某物料实际分布在哪。

" 按仓库号和存储类型拉仓位清单，核对编码规则与仓位类型 SELECT lgnum, lgtyp, lgpla, lptyp FROM lgpla INTO TABLE @DATA(lt_bins) WHERE lgnum = @p_lgnum AND lgtyp = @p_lgtyp. " 查某物料在该仓库号下的 Quant 分布，确认上架结果 SELECT lgnum, lgtyp, lgpla, matnr, lenum, menge, meins FROM lqua INTO TABLE @DATA(lt_quants) WHERE lgnum = @p_lgnum AND matnr = @p_matnr.

逻辑说明：第一段按仓库号加工存储类型筛选仓位主数据，LGNUM 是仓库号，LGTYP 是存储类型，LGPLA 是仓位编码，LPTYP 是仓位类型，用来检查有没有仓位类型为空、编码位数不统一的情况。第二段按仓库号加物料查 Quant，LENUM 是存储单位号，MENGE 是数量，MEINS 是单位，用来确认某批货实际落在哪个分区对应的仓位，和上架建议是否一致。

参数说明：p_lgnum、p_lgtyp、p_matnr 是选择屏幕参数，测试时先用一个仓库号加一个存储类型跑，数据量大的仓库不要全量拉。字段名以实际系统版本为准，不同版本可能有增减，跑之前先在 SE11 里看一眼结构。

5. 避坑与排查：五条从仓库号到仓位的血泪记录

5.1 仓库号按建筑建，跨楼转储单碎成多段

现象：从 A 楼收货区到 B 楼高架区的移动，系统里生成两张转储单，中间还有一段在途库存，盘点时对不上。原因：项目组把仓库号理解成物理建筑，每栋楼建了一个号。解决：按 2.2 的判定表合并成一个仓库号，用存储类型区分建筑，历史单据通过调整库存方式归并，之后跨楼移动就是一张转储单。

5.2 存储类型只建一个分区，上架策略像失灵

现象：配了上架策略，转储单建议仓位却总是随机落在同一片区域，现场说系统「不听话」。原因：为了满足系统强制检查，只建了一个编码 0001 的分区，所有仓位挂在一起，搜索顺序没有区分度。解决：按重量或周转频率补建 2 到 4 个分区，把仓位重新挂接，再回查搜索顺序的优先级；补完之后先在测试仓库号跑几笔再切生产。

5.3 仓位总能力填了带单位的数，容量检查拦不住超载

现象：仓位明明标了 1000，现场放了 1200 也没报错，或者反过来，轻货刚放上去就提示超容。原因：Total capacity 是无单位纯数字，一部分人按公斤填、一部分人按托盘数填，口径不一致。解决：出一份填写规范，统一成标准托盘数，导出 LGPLA 全量核对异常值，改完在测试环境用超重托盘验证拦截是否生效。

5.4 省了仓位分隔符，现场拣货频繁走错排

现象：纸质拣货单上的仓位是 010203，作业员看成 01 排 02 列 03 层，实际是 01 排 20 列 3 层，走错排的情况一周出现好几次。原因：编码省略分隔符，位数固定但肉眼容易错位。解决：评估手持终端覆盖率，覆盖率不足就恢复分隔符，或者把列号改成三位、层号改成一位，用长度差异帮助识读；改编码规则要同步主数据和打印模板。

5.5 托盘类型和仓位类型不匹配，上架搜索找不到仓位

现象：某类大托盘入库时，系统提示无可用仓位，但现场明明有空的重型位。原因：搜索顺序里先匹配了窄巷道仓位类型，大托盘被排除后没有回退到下一优先级。解决：调整搜索顺序，把承重和尺寸约束放在第一优先级，路径优化放第二；同时检查仓位主数据里的仓位类型有没有漏填，漏填的仓位在搜索时等于不存在。

6. 拣货区与集结区：用拆分拣货单验证前面五章配得对不对

Picking Area（拣货区）和 Storage Section 的意义相反，它是一些具有共同出库拣货管理特性的仓位的集合，用来协助实现简单有效的出库策略。存储分区是强制要求定义的，拣货区却是可选的。这个可选项在多人分区作业的仓库里价值很大：交货单中的所有行项目本来可以打印在一张拣货单上，定义了多个拣货区之后，系统可以根据拣货区不同自动把拣货单拆成几张，后台配置里也可以关掉自动拆分。拆分的意义是几个拣货区域平行作业，加快发货流程，适合一个仓库划分几个区域、归不同的人管理的情况。

我一般的验证顺序是：先在仓位主数据里给每个仓位挂上拣货区，只挂物理上确实由同一组人负责的区域；再配好拣货单拆分规则；然后建一张跨三个拣货区的交货单，观察系统生成几张拣货单、每张是否只包含一个区的行项目；最后让现场按拆出来的单子各走一遍，确认不会出现两个人抢同一个仓位的情况。这一步做完，前面配的存储类型、分区、仓位类型才算真正闭环，因为出库路径会把入库时的分组问题全部暴露出来。

血泪经验是：不要在生产仓库号上直接开自动拆分。有一次我在测试环境验证通过就切了生产，结果某个拣货区只挂了一半仓位，剩下的一半仓位没有拣货区，系统把它们归到默认组，拣货单拆出来的张数和现场人数对不上，当天发货延迟了两个小时。从那以后我每次配拣货区，都先用 LGPLA 拉一遍仓位清单，筛出拣货区为空的记录，确认没有漏挂，再开拆分开关。希望帮到你。

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