企业官网建设流程全解析

简介：面向 SAP 仓储管理初学者与初入 WM 项目的顾问，这份文档聚焦仓库管理模块常用术语的中英文对应与概念解释，帮助读者在阅读英文资料、参与项目沟通或梳理系统配置时快速定位关键词。内容以对照表形式展开，涵盖 Plant（工厂）、Storage Location（存储地点）、Warehouse Number（仓库号）、Storage Type（存储类型）、Storage Section（存储分区）、Picking Area（拣货区）、Staging Area（集结区）、Storage Bin（仓位）、Quant（份）、Transfer Order（转储单）等条目，并对仓库号的组织层级、存储类型划分、存储分区与拣货区的强制或可选关系、仓位作为主数据等要点作了说明。资源包共 1 个 docx 文件，约 16KB，轻量易查，适合作为日常术语速查页或培训前的概念铺垫。已有 999 人学习，可帮助读者减少中英文术语混用带来的理解偏差，并为后续 WM 配置与仓储流程学习打基础。

1. 仓库管理里的那套中英文对照：为什么一堆名词能决定你上架走哪条路

搬过家的人都经历过这种对话：东西收好了吗？收好了。在哪？在箱子里。哪个箱子？然后两个人对着三十个纸箱干瞪眼。仓库管理里的大部分麻烦，本质上就是这句话的放大版——货确实在仓库里，但“仓库”这两个字太粗了，粗到没法指挥任何人干活。

SAP 的仓库管理模块 WM，干的第一件事就是把这句“在仓库里”拆成一层层能说出口的地址：哪个工厂、哪个存储地点、哪个仓库号、哪个存储类型、哪个存储分区，最后落到哪个仓位。这套中英文对应表看着像词汇表，其实是一张空间坐标系。搞懂它，你才知道一条上架指令到底在往哪走；搞不懂，配置出来的策略就是玄学。下面从最大的容器开始，一层层往里拆。

2. 仓库号与存储类型：从“一栋楼”到“一个区”的空间切分逻辑

2.1 仓库号到底是什么：一个号管一片仓库联合体

先把三个最容易打架的词摆在一起：Plant 工厂、Storage Location 存储地点、Warehouse Number 仓库号。工厂在最上层，是业务组织的根；存储地点挂在工厂下面，是库存管理层面的划分；仓库号则是 WM 模块自己的一套坐标，它不跟存储地点一一对应，而是站在“这一片地方由谁来做仓库作业”的角度重新划界。

原料里说得很直白：仓库号定义在 WM 模块中，一个完整的仓库会定义在单独一个仓库号下面。这句话里“完整的仓库”不是指一栋楼，而是指一套能独立运转的仓储作业体系。你可以用一个仓库号管理多个独立的仓库建筑，这种用法叫仓库联合。打个比方，仓库号像一个园区门牌，园区里可以有好几栋楼、好几个库房，但只要它们归同一套班底、同一套上架规则管，就可以共用一个门牌。

为什么要在仓库号这一层做聚合？因为仓库号级别承载了一批“只跟作业有关、跟财务和采购无关”的设置。原料里提到，在仓库号级别可以定义仓库管理使用的单位，可以定义 WM 和 PP 等其他模块的接口。这些设置是全局性的，一旦拆成两个仓库号，就得配两遍、维护两套、以后改规则还得改两次。所以推荐的做法是：用一个仓库号管理某一地域的一组仓库建筑群。判断标准就一条——地理上是不是挨得近、作业上是不是一拨人。如果几个仓库设施在地理区域上隔得很远，那就别硬凑，分别用仓库号管理更省心。一般同一个工厂区会用一个仓库号。

这里有个容易被忽略的细节：仓库号不是“越大越好”。仓库号拆得少，配置集中、接口统一，但作业范围一大，上架策略就得写得更绕；仓库号拆得多，每个仓的规则清爽，但主数据量和接口配置翻倍。这个取舍后面第 6 章会专门讲边界。

2.2 存储类型为什么不叫“类型”叫“区域”

存储类型对应的英文是 Storage Type，但原料里有一句很关键的纠正：存储类型实际上称作存储区域更合适。它指的就是一个存储区域，包括仓储设备和仓储区，在仓库号下面定义。

为什么名字叫类型、实质是区域？因为它的划分依据是“这一片地方用什么方式存货”。原料给了几种典型切法：按仓储技术分，可以是自动仓、半自动仓、高架货架；按使用空间区域分，可以是室内区、露天区；按组织形式或功能分，可以是拣货区、收货区。划分出来的每一个结果，落到物理世界里就是一块地方。所以你在系统里看到的是一个代码，在现场看到的是一片货架。

存储区域可以是物理的，也可以是逻辑的。物理的好理解，高架货架区就是那排十几米高的架子；逻辑的例子是差异区，它可能只是某个通道边上一小块用黄线划出来的地面，专门放盘点对不上的货，但从管理意义上它必须独立存在。

原料给了一个很具体的例子：某公司的仓库包括收货区、发货区、高架货架区、堆放区、固定仓位拣货区，外加一个外部存储区域，用于特别货物存储或者溢出。上述每一个区域在仓库管理中都是一个存储类型，WM 把所有这些存储类型用一个仓库号来管理。这段话把“仓库号装存储类型”的包含关系讲透了：仓库号是容器，存储类型是容器里的格子，格子的数量取决于你的仓库有多少种不同的存货方式。

常用的存储类型有这几类：Bulk storage 堆货区、Open Storage 开放区、High rack storage 高架货架区、Picking area 拣货区、Shelf storage 货架区。另外还有一类特殊的，是 WM 和 IM 共用的中间存储类型，比如 Goods receipt area 收货区、Goods issue area 发货区、Interim storage area for differences 差异区，以及 Posting change zone。这类中间区域的作用是给货物一个“过渡落脚点”，收货还没上架、发货还没装车的时候，货不能凭空消失，得有个地方挂着。

2.3 预定义存储类型为什么能直接拷贝用

标准系统里已经预定义了几个常用的存储类型，比如一个高架区、一个堆放区、一个拣货区。这些预定义类型不是空壳，它们已经配置好了不同的控制参数，如上架策略、下架策略、盘点方法。原料的建议是：可以参考这些设置并做一些适当的修改，以满足公司的需要。

拷贝这件事的价值在于省掉了“从零想参数”的过程。上架策略、下架策略、盘点方法这几个参数，每一个背后都是一套判定逻辑，凭空设计很容易漏。直接拷贝一份现成的，相当于拿到一份参考答案，你只需要判断“我们仓库跟它的假设差在哪”。

但拷贝也有坑，而且是血泪经验级别的坑：拷贝过来的存储类型会带着原主人的假设。比如预定义的高架区默认按托盘整进整出，你要是拿它去管拆零拣货，参数不改就会天天翻车。所以拷完之后至少要核对三件事：这个存储类型的上架策略是不是符合你现场的存放习惯，下架策略会不会把慢动销的货先扒出来，盘点方法跟你的盘点频率对不对得上。

提示：预定义类型是起点不是终点，拷贝完不改参数，等于把别人的仓库规则硬套在自己头上。

存储类型这一层还承担了一个隐性职责：它是控制参数的“源头”。后面要讲的存储分区，本身不允许定义任何控制参数，参数是从存储类型传下去的。这条规则决定了你在设计时的思考顺序——先想清楚这一片区域整体怎么管，再去想里面怎么细分。

3. 存储分区与拣货区：入库和出库的两套视角

3.1 存储分区：为“上架去哪”服务的细分

存储分区对应 Storage Section，它是在存储类型下面的一个细分组织结构，定义是一批具有共同入库管理特性的仓位的集合。注意这里的限定词是“入库”，它管的是货进来往哪放，不是货出去怎么拿。

划分方法相当灵活。原料给了三类思路：按货物重量分，可以划出底层重物分区、中层重货物分区、高层轻型货物分区；按货物移动频率分，可以划出快速移动货物分区、缓慢移动货物分区；复杂一点还可以把两个标准叠起来，比如快速移动重型货物分区、快速移动轻型货物分区、缓慢移动重型货物分区、缓慢移动轻型货物分区。这四种组合听着绕，但落到现场就是四句话：常用的重货放门口低位，常用的轻货放近处高层，不常用的重货往里挪，不常用的轻货扔最远。

存储类型和存储分区通常是一对多的关系，一个存储类型下面可以挂好几个分区。分区的主要用途是实现入库仓位定向选择，也就是说，系统在给一批货找位置的时候，先定存储类型，再在类型内部按分区缩小范围。正因为它是为“定向”服务的，原料特别强调：存储分区的定义一定要有目的性和实际意义，通常集中在同一个物理区域。如果你划出来的分区在物理上东一块西一块，那这个分区就没法承担定向职责，作业人员得满仓库跑。

这里有一条硬规则：WM 系统强制要求必须为每一个存储类型至少定义一个存储分区。哪怕你觉得没必要细分，也得建一个。只建一个分区，实际上相当于没有对存储类型进行细分，此时存储分区和存储类型是一对一的关系。这条规则对新手挺劝退的，但它保证了数据结构的一致性——系统在任何时候都能回答“这个仓位属于哪个分区”，不用处理空值。

还有一条容易踩的限制：存储分区里不能定义任何控制参数，这些控制参数通常是从存储类型传递下来的。换句话说，分区只能决定“范围”，不能决定“规则”。你要是想让某个分区用不同的上架策略，做不到，只能往上提到存储类型这一层，或者用仓位类型、托盘类型这类手段绕过去。

3.2 拣货区：为“下架怎么快”服务的可选集合

拣货区对应 Picking Area，原料对它的定性很干脆：定义与存储分区意义相反。它是一些具有共同出库拣货管理特性的仓位的集合，协助实现简单有效的出库策略。存储分区看的是“进来怎么放”，拣货区看的是“出去怎么拿”，方向正好反过来。

两者最直观的差别在强制性上：存储分区是强制要求定义的，拣货区却是可选的，可用也可用不用。这个差别不是随意设计的，它反映了两件事在业务上的确定性不同——货进来必须有个明确落点，否则上架指令发不出去；货出去则可以合并处理，一张拣货单能搞定的，没必要非得拆开。

拣货区的实际价值在单据层面。原料说，在 WM 中交货单里的所有行项目可以打印在一张拣货单上。如果你定义了几个拣货区，系统就可以根据拣货区不同自动把拣货单分拆成几张，这个动作是后台配置的，也可以选择不自动拆分。拆单的意义在于：几个拣货区域可以平行作业，加快发货流程。

举个具体场景。一个仓库分了三个拣货区，分别归三个班组管。来了一张有三十行的交货单，如果不拆，这张单子只能落到一个班组手里，另外两个班组闲着；拆成三张，三个班组同时动，发货时间直接压到三分之一。这种用法特别适合一个仓库划分几个区域、归不同的人管理的情况。

反过来说，如果你的仓库就一个班组通吃，或者订单量根本撑不起平行作业，那拣货区不建也完全没问题。这就是可选设计的好处：它不逼你为用不上的功能付出配置成本。

3.3 为什么系统强制要一个分区，却不强制拣货区

把这两条规则放在一起看，能看出设计者的取舍逻辑：强制的那一项，对应的是一条不能中断的链路；可选的那一项，对应的是一条可以合并的链路。

入库链路不能中断。一批货到了，系统必须给出一个具体仓位，这个仓位必须落在某个存储类型下的某个存储分区里。如果允许“没有分区”，那么仓位定向选择就少了一层筛子，策略配置也会出现无分区可引用的空档。所以哪怕你只建一个分区，也得建。

出库链路可以合并。拣货的本质是把多个行项目汇总成一次行走路线，一张单子能覆盖就覆盖，覆盖不了才拆。拣货区是在“需要平行作业”时才启用的加速器，不是必需品。

需要提醒一句：拣货区和存储分区不是上下级关系。存储分区是存储类型内部的细分，层级明确；拣货区是按出库作业视角把仓位重新归堆，它跨不跨存储类型取决于你怎么定义。把两者当成同一棵树的父子节点，是初学者最常见的理解偏差之一。

4. 仓位与托盘：仓库管理的最小空间单位和装载单位

4.1 仓位是主数据，不是组织结构

存储类型通常由很多个细分的存储单元构成，这些单元就叫仓位，英文 Storage Bin。仓位是仓库管理最小的空间单位。仓位信息描述的就是某一个仓库内某一货物将要存放、或者已经存在于的某个位置。

这句话里最要紧的是“主数据”三个字。原料明确说：在 SAP WM 中，仓位作为主数据存在，而不是仓库内部的组织结构。这个区别值得展开讲，因为它是很多人配置时翻车的地方。

组织结构是配置层面的东西，你建一个存储类型，它是配置；你改一个存储类型的上架策略，改的也是配置。配置的特点是数量有限、由少数人维护、改动影响面大。主数据不一样，主数据是业务运转中大量存在的记录，仓位的数量可能是几千上万个，每个仓位都有自己的属性。

分清这两者的实际意义在于：仓位可以承载“这一个位置特有的信息”，而存储类型只能承载“这一类位置共有的信息”。原料列了仓位里能定义的东西：Maximum weight 最大载重量、Total capacity 总能力（没有单位的纯数字）、Fire containment section 防火分区、Storage bin type 仓位类型。这些属性是逐个仓位填的，因为每个货架的承重、每个格子的容积、每面墙的防火等级都不一样。

最大载重量这条特别实用。高架货架底层能放一吨，顶层可能只敢放两百公斤，这个差别不可能靠存储类型表达，只能落到仓位级别。系统在上架时结合这个上限做校验，能避免把重货往高层塞这种既危险又难救的失误。

4.2 仓位编码 01-02-03 里藏着的取舍

仓位的命名通常定义成类似 01-02-03 的坐标值。原料给了默认解释：首两位可以表示货架编号，中间两位代表列号，后面两位代表层号。但也留了余地：你可以定义中间两位是层号、后面两位是列号，还可以定义省略分位符，也就是不写那两个短横。

省略分位符的利弊，原料讲得很实在：省略分位符可以减少 WM 作业中仓位的输入信息，但是增加了识读的难度，需要综合权衡。少敲两个字符，在每天上千次操作的场景下确实能省时间；但 010203 这种六位串，人眼扫过去很难立刻分辨哪两位是列、哪两位是层，一旦看错就是上错货架。

仓位可以用英文字母、数字和字符来混合定义，这给了编码很大的自由度。自由度大也意味着规范要提前定死，否则不同人按不同习惯建仓位，后面解析和维护都会乱。

# 把 01-02-03 这样的仓位号拆成 货架 / 列 / 层 bin_code = "01-02-03" # 分位符只是给人看的，解析前先去掉 raw = bin_code.replace("-", "") # 得到 "010203" rack = raw[0:2] # 货架编号 01 col = raw[2:4] # 列号 02（若你们约定这里是层号，改这行的含义即可） level = raw[4:6] # 层号 03 print(rack, col, level)

上面这段只是把编码规则写成可执行的判断，方便你在建仓位之前先验证一遍规则是否自洽。关键点在注释里：分段含义必须跟仓库实际的货架排布对齐，别照抄别人的分段方式。原料特意提到中间两位和后面两位的含义可以互换，这说明分段规则本身没有标准答案，只有“跟现场一致”这一个要求。真正要小心的是省略分位符之后的解析——代码里去掉短横很容易，现场人员肉眼分辨却很难，这个成本要提前算进去。

4.3 仓位类型与托盘类型的组合玩法

仓位里可以定义 Storage bin type 仓位类型，仓库管理里还有 Storage Unit 托盘和 Storage Unit Type 托盘类型这两个概念。原料指出：在仓库入库策略中，结合仓位类型、托盘类型可以实现灵活多变的入库方式。

这句话背后的机制是“搜索顺序”。系统找空位的时候不是随便挑一个，而是按预设的顺序逐条筛，筛到合适的就停。仓位类型和托盘类型都是筛选条件，把它们编进搜索顺序，就能实现“大托盘优先去宽货架、小托盘优先去窄货架”这类效果。

原料给了一个很具体的实践：某项目里的典型应用是用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。这个思路值得单独说一下，因为它体现了一种“用轻量手段解决重问题”的取向。

设想一个场景：仓库里有一片区域，重货该往里走、轻货该往外走。按常规思路，你会在这片区域里划两个存储分区，一个管重货一个管轻货，然后配两套上架策略。但如果你只是想让大托盘和小托盘走不同方向，其实不需要动分区——调整仓位搜索顺序，让系统先按托盘类型匹配，就能把货导到该去的地方。少建一套分区结构，后面少维护一套规则，改动时也少一处要同步的地方。

注意：搜索顺序是“优先级”不是“唯一条件”。顺序排错的表现往往是货没放错大类，但总放不到最该去的那个位置，排查时先看顺序表再看分区。

5. 易混概念辨析：这几组词看着像，管的事完全不一样

5.1 存储地点和仓库号

易混点：两个词都带“地点”“仓库”字样，中文读起来像是同一件事的两种说法。

为什么混：它们确实都描述“货在哪”，而且在实际业务里经常同时出现在一张单据上。再加上有些仓库的存储地点和仓库号数量刚好一样，更容易让人以为是同义反复。

怎么区分：看它属于哪一层。存储地点是库存管理层面的划分，管的是“这批货在账上归哪个地方”；仓库号是 WM 模块的作业坐标，管的是“这批货在物理上由哪套仓储体系处理”。一个仓库号可以跟多个存储地点发生关系，原料里说仓库号可以用来管理多个独立的仓库建筑，就是这个意思。判断方法很简单：如果一个调整只影响“货算谁的、账怎么记”，那是存储地点层面的事；如果影响“货上哪个架子、走哪条策略”，那是仓库号层面的事。

5.2 存储类型和存储分区

易混点：都是“把仓库切成块”，名字里还都带“储”字，层级上又是上下级，很容易当成同一件事的粗细两种叫法。

为什么混：因为它们切出来的结果在物理上可能长得一模一样。一个高架货架区，如果不细分，它就是一个存储类型加一个存储分区，两者覆盖的范围完全重合，看起来就是同一个东西。

怎么区分：看它承担什么职责。存储类型是控制参数的源头，上架策略、下架策略、盘点方法都在这一层定；存储分区不能定义任何控制参数，它只负责在类型内部缩小范围，服务于入库仓位定向选择。所以判断标准是：这个划分要不要带规则？要带规则就是存储类型，只是想把范围圈小一点就是存储分区。另外记住一条硬规则，存储分区每个类型至少得有一个，一个分区等于没细分。

5.3 存储分区和拣货区

易混点：两者都是“仓位的集合”，定义句式几乎一样，都说了“具有共同某某特性的仓位的集合”。

为什么混：句式太像了，原料在讲存储分区时用的是“共同入库管理特性”，讲拣货区时用的是“共同出库拣货管理特性”，一字之差，读快了直接串行。

怎么区分：看方向。存储分区服务入库，回答“货来了往哪放”；拣货区服务出库，回答“单子怎么拆、活怎么分”。再看强制性：存储分区强制，拣货区可选。还有一个实操层面的区别，拣货区的存在会直接影响拣货单的分拆和班组的平行作业，而存储分区不会改变单据形态，它只影响系统找位置的路径。

5.4 转储单和转储申请

易混点：Transfer Order 转储单和 Transfer Requirement 转储申请，中文都带“转储”，都描述货物移动。

为什么混：两者经常前后脚出现，一笔业务里可能先有申请后有单，看单据流的时候容易把它们当成一件事的两个名字。

怎么区分：按这个领域最通俗的说法，转储申请是“我想搬”的意向记录，转储单是“实际执行搬”的指令。申请是需求，单是动作，一个可以被合并、被调整、被拒绝，另一个对应具体的仓位到仓位的执行步骤。看单据状态就能分辨：还在等确认的是申请，已经明确到具体仓位的是单。

5.5 份（Quant）不是库存数量

易混点：Quant 中文常译作“份”，听起来像是一个数量单位，容易跟“有多少件”混起来。

为什么混：“份”这个字在日常语言里就是计量的，一份两份，天然带数量含义。

怎么区分：Quant 描述的是“同一堆货”这个概念，不是件数。通俗地说，同一个物料、同一批次、放在同一个仓位里的那些货，构成一个 Quant。一个仓位里可以有好几个 Quant，比如同一种物料的两个不同批次就会分成两份。所以看到“份”的时候，脑子里应该浮现的是“一堆”，而不是“几个”。这个区别在盘点和对账时特别关键，份数对不上和数量对不上是两类完全不同的问题，排查方向也不一样。

6. 什么时候该拆仓库号、什么时候别拆：几条边界判断

仓库号拆分的判断，说到底是回答一个问题：这些仓库建筑，是不是该由同一套规则管。原料给的原则很朴素——推荐用一个仓库号管理某一地域一组仓库建筑群，如果几个仓库设施在地理区域上隔得很远，就考虑用分别的仓库号。这句话可以拆成两条可操作的边界。

该拆的信号有三个。第一，地理上真的远，两个库区之间开车要半小时，收货发货各自独立，硬塞进一个仓库号只会让调拨逻辑变得别扭。第二，作业班底完全独立，两拨人、两套流程、互不干涉，这种情况共用一个仓库号，任何规则调整都要两边开会。第三，需要不同的仓库管理单位和不同的模块接口配置，这种差异是仓库号级别的，没法往下压。

别拆的信号同样清晰。同一厂区里几栋相邻的库房，只是楼不一样，作业是一拨人，那就一个仓库号，用存储类型区分不同楼栋或不同存放方式。只是货架区和高架区不同，也别拆，那是存储类型的活。想按班组分活，更不该拆仓库号，那是拣货区的用途——原料说得很清楚，拣货区适用于一个仓库划分几个区域归不同的人管理的情况。

还有一种情况介于两者之间：仓库确实在扩张，多了一个新库房，但新库房暂时只有存储功能、没有独立的收货发货。这种我倾向于先不拆，把它做成现有仓库号下的一个新存储类型，等它长出自己的作业班底和收发能力，再考虑独立。拆容易，合难，这个方向上多犹豫一下不亏。

另外一个常见误区是把“看起来整齐”当成拆分理由。有人觉得一个仓库号下面挂十几个存储类型太乱，想按区域拆成三个仓库号，每个号下面清清爽爽四五个类型。这种拆法在配置表上是好看了，但代价是接口配置三份、单位设置三份、以后改规则三处同步。整齐是给人看的，维护成本是给自己扛的，这笔账要算清楚。

提示：拆分决策一旦落地，后续所有主数据和接口都绑在这个选择上，改起来的代价远大于一开始多想半小时。

仓位编码规则也是同理。我在一个项目里见过省掉分位符的写法，当初想的是扫码枪少敲两个字符，效率高。结果现场有一批老员工习惯看纸质拣货单核对，六位数字他们得逐位念出来对照，反而慢了，还出过两次看错层的差错。后来改回带分位符，扫码那边多敲两下，整体反而顺了。从那以后我每次定仓位编码规则之前，都会强制走一遍“不看屏幕、只看纸质单据能不能读对”的验证，规则是给人用的，不是给系统看的。这份中英文对照和解释，正好可以当成建仓库号之前的一次预热，把每个词的边界想明白，再动手配置。希望帮到你。

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