SAP WM仓库管理：六级组织结构与仓位定位解析

简介：围绕 SAP 仓库管理（WM）模块整理的中英文术语对照与概念说明文档，面向仓储顾问、实施人员及刚接触 WM 的学习者，帮助解决专业词汇理解不一致、仓库组织结构与核心对象概念混淆等问题。压缩包共 1 个 docx 文件，约 16KB，内容以逐条术语表和概念解释为主，便于快速检索、对照记忆和培训备课。资料覆盖工厂、存储地点、仓库号、存储类型、存储分区、拣货区、集结区、门、仓位、货架类型、托盘、份、转储单与转储申请等常用词，并延伸说明仓库联合体的组织方式、存储类型的物理与逻辑划分、存储分区和拣货区的区别，以及仓位主数据中的最大载重量、总能力、防火分区、仓位类型等字段含义。已有 999 人学习，适合用来建立 WM 基础概念框架，也可作为项目沟通、配置讨论和术语速查时的参考。

1. 一句话说清 SAP WM：仓库管理里到底在管什么

搬进新家那天，最常听到的一句话是“东西放哪儿了”。答案通常不是“在储藏室”，而是“储藏室左边铁架子第二层那个蓝箱子里”。SAP WM 干的就是同一件事：把仓库里“货放哪儿”从一句口头描述，变成系统里能查、能算、能被规则自动调用的地址。WM 是 Warehouse Management 的缩写，在 SAP 这套企业软件里，它专门负责仓库内部的位置级管理，颗粒度细到某一个货架的第几层第几格，也就是仓位。搞懂它之后，你再看 Plant、Storage Type、Storage Bin 这一长串中英文对照，就不会觉得是一堆孤立的单词，而是一张从“公司有多少个厂”一路缩小到“这箱货在第几格”的地图。

2. 从工厂到仓位：一套六级地址怎么把货“定位”住

把仓库想象成一座城市，地址体系从来不是一步到位的。快递单上写“某某市某某区某某路某某号某某室”，少一级就送不到。SAP WM 的组织结构也是同样的思路，每一层都回答一个不同尺度的问题，只不过它的层级名字换成了英文缩写，看着唬人，拆开看其实就是“省、市、区、街道、门牌号”的仓储版本。这一章按从大到小的顺序，把这六级地址逐个拆开。

2.1 工厂与存储地点：账面上的落脚点

Plant，中文对照是工厂，它是企业组织结构里最基础的一层，生产、采购、库存核算基本都挂在这个层级上。Storage Location，中文对照是存储地点，它是工厂下面的一层细分，用来区分同一个工厂里不同性质的存货区域，比如原料库、成品库、备件库。

需要留意的是，这两个概念主要服务于库存的“账面管理”：系统要能回答“这个工厂的这个存储地点里，某个物料一共有多少件”。它管的是数量和金额，不管具体位置。你可以把存储地点理解成“这个仓库里大概有多少货”的统计口径，它知道自己有一批螺丝，但不知道螺丝在哪个货架。

真正开始管“位置”的，是接下来的仓库号。这也是很多人第一次接触 WM 时最容易卡住的地方：明明已经有存储地点了，为什么还要再来一个仓库号？

2.2 仓库号：为什么要用“仓库联合体”来管

Warehouse Number，中文对照是仓库号，它是 WM 模块自己的组织单位。原文里有一句关键定义：在 WM 模块中，一个完整的仓库会定义在单独一个仓库号下面，你可以使用一个仓库号管理多个独立的仓库建筑，通常称之为仓库联合。

打个比方，一个物流园区里有三栋楼，一号楼放整托货，二号楼做拆零拣货，三号楼是临时周转区。这三栋楼在物理上是分开的，但在业务上是一个整体，人员、设备、流程都打通。这时候用三个仓库号分别管，等于把一套流程拆成三份维护；用一个仓库号把它们“联合”起来，才是更省事的选择。

原文对这个取舍给得很清楚：推荐使用一个仓库号来管理某一地域的一组仓库建筑群；如果几个仓库设施在地理区域上隔得很远，就考虑用分别的仓库号。一般同一个工厂区会用一个仓库号。这句话背后的判断标准其实就是两条——地理上是否集中、业务流程是否统一。距离近、流程通，就合并；距离远、各管各的，就拆开。

仓库号这一层还承担着一些“跨模块”的职责。原文提到，在仓库号级别可以定义仓库管理使用的单位，也可以定义 WM 和其他模块之间的接口。通俗地说，仓库号不只是一个地理位置标签，它还是这套仓库管理规则的作用范围：单位怎么算、跟外部模块怎么对接，都在这一层定下来。

2.3 存储类型与存储分区：区域划分的两把尺子

Storage Type，中文对照是存储类型。原文特别提醒了一句：叫“存储类型”其实不如叫“存储区域”更合适，它指的就是一个存储区域，包括仓储设备和仓储区。这个提醒很有价值，因为“类型”两个字容易让人以为是给货物分类，实际上它是给空间分类。

存储类型定义在仓库号下面，可以是物理区域，也可以是逻辑区域。划分依据有好几种：按仓储技术分（自动仓、半自动仓、高架货架），按使用空间分，按组织形式分，按功能分。原文给的例子是一个公司仓库包含收货区、发货区、高架货架区、堆放区、固定仓位拣货区，还有外部的特别货物存储区或溢出区，每一个区域在仓库管理里就是一个存储类型。

这里有个很实在的好处：标准系统里已经预定义了几个常用的存储类型，比如高架区、堆放区、拣货区，这些预定义类型已经配置好了不同的控制参数，包括上架策略、下架策略、盘点方法。你可以直接拷贝到自己的仓库号下，再按公司实际情况做适当修改。这相当于别人已经写好了一套模板，你拿来改改就能用，不用从零开始调参数。

Storage Section，中文对照是存储分区，它是存储类型下面的进一步细分。原文的定义是：一些具有共同入库管理特性的仓位的集合。划分方法很灵活，可以按货物重量分，比如底层放重物、中层放中等重量、高层放轻货；也可以按货物移动频率分，快速移动的放一块、缓慢移动的放一块；复杂一点还能组合，比如“快速移动的重型货物区”“缓慢移动的轻型货物区”。

存储类型和存储分区通常是一对多的关系。有一点必须记住：存储分区是强制要求定义的，系统要求每一个存储类型至少要有一个存储分区。如果你觉得没必要细分，就建一个分区，这时候两者变成一对一，等于没细分。另外，存储分区里不能定义控制参数，这些参数是从存储类型继承下来的。这个设计很合理——分区的职责只是“划范围”，规则统一由上一层给。

2.4 仓位：最小的一格，却是主数据

Storage Bin，中文对照是仓位。存储类型下面有很多细分的存储单元，这些单元就是仓位，它是仓库管理最小的空间单位。仓位信息描述的是某一货物将要存放、或者已经存在于的某个位置。

仓位的编码通常是坐标式的，像 01-02-03 这样。原文给了两种常见约定：首两位表示货架编号，中间两位表示列号，后面两位表示层号；也可以中间两位是层号、后面两位是列号。分隔符也可以省略，写成 010203。原文对这个取舍说得很到位：省略分隔符能减少作业中的输入量，但增加了识读难度，需要综合权衡。这确实是个很现实的取舍，扫码枪时代可能无所谓，手工录入为主的场景里，少敲两个字符就是实打实的效率。

仓位在 SAP WM 里有一个特殊身份：它是作为主数据存在的，而不是仓库内部的组织结构。这个区别听起来抽象，实际影响很大。组织结构是配置层面的东西，改起来要谨慎；主数据是可以一条条维护、批量导入、单独挂属性的。因为仓位是主数据，所以它身上能挂载一批物理属性：最大载重量、总能力（一个没有单位的纯数字）、防火分区、仓位类型。这些属性后面会直接参与入库策略的计算。

原文最后提到一个项目里的典型做法：用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。这句话信息量很大，它说明存储分区和仓位搜索顺序在某种程度上是可以互相替代的——你可以用“分很多区”来实现精细化入库，也可以用“仓位属性加搜索顺序”来实现同样的效果，后者维护成本可能更低。哪种更好，取决于你的仓库复杂度。

3. 出库侧与流转：拣货区、集结区、门和那些单据

上一章讲的是“货放在哪”，这一章讲“货怎么动”。仓库管理真正的难点往往不在静态存放，而在动态流转：一批货从收货区进来到最终装车出门，中间要经过好几次位置变化，每一次变化都要有人知道、有单据记录、有规则约束。SAP WM 里那几个看着眼生的词——拣货区、集结区、门、托盘、份、转储单——就是为这段流动过程准备的。

3.1 拣货区：跟存储分区反着来的设计

Picking Area，中文对照是拣货区。原文对它的定义很有意思：与存储分区的意义相反，它是一些具有共同出库拣货管理特性的仓位的集合，协助实现简单有效的出库策略。

把这两句话对照着看就明白了。存储分区服务的是“进”，它把仓位按入库特性分组，影响的是上架时往哪儿放；拣货区服务的是“出”，它把仓位按出库拣货特性分组，影响的是取货时怎么走、谁来走。一个朝里，一个朝外，这就是“意义相反”的意思。

两者在强制性上也不一样：存储分区是强制要定义的，拣货区是可选的，可用可不用。这个差异很合理——每批货总得有个地方放，所以分区必须有；但不是每个仓库都需要按区域拆分拣货任务，所以拣货区留给有需要的人。

拣货区的实际用途，原文讲得很具体：交货单里的所有行项目本来可以打印在一张拣货单上，如果你定义了几个拣货区，系统就能根据拣货区的不同，自动把拣货单拆成几张，这个拆分是后台配置的，也可以选择不自动拆。拆分的意义在于，几个拣货区域可以平行作业，加快发货流程，特别适合一个仓库划分成几个区域、归不同的人管理的情况。

举个具体场景：一个仓库东区和西区各有一拨拣货员，如果所有订单打在一张单子上，两个人得抢同一张纸；按拣货区拆成两张，各干各的，互不干扰。这就是拣货区存在的价值——它不是为了管货，是为了管人和活。

3.2 集结区与门：发货前的最后一段路

Staging Area，中文对照是集结区；Door，中文对照是门。这两个词在对照表里只占了短短两行，但在实际动线里位置很关键。

通俗地说，集结区是货物从仓位移出来、等待装车之前的临时集中区域。拣货员把货从各个仓位取出来，不会直接搬上车，而是先集中到一个地方，等这一车的货齐了、点数对了、单据核了，再统一往车上装。这个“集中”的地方就是集结区。它的作用是缓冲和核对，避免车在门口干等，也避免货装到一半发现少了。

门就是装车口。一个仓库可能有几个门，不同的门对应不同的运输方向、不同的承运商、不同的车型。门的数量和管理方式，直接影响装车效率。

这两个概念在很多仓库里是“有实无名”的：现实中确实有这么块地方，也确实有几个装车口，只是没人给它们编号，也没人在系统里维护。当仓库规模小、车次少的时候，靠喊一嗓子就能协调；规模一上来，没有系统里的位置概念，调度就只能靠经验。这也是为什么仓库管理模块要把它们纳入地址体系——让“货在集结区等某某车”这件事，变成系统里查得到的状态。

3.3 托盘、份、转储单：货物流转中的三个角色

Storage Unit，中文对照是托盘；Storage Unit Type，中文对照是托盘类型。在仓库里，货物很少是一件一件搬的，通常以托盘为搬运单位。一个托盘连同上面的货，在 WM 里就是一个存储单元。托盘类型则用来区分不同规格的托盘，比如尺寸、载重能力不同的几种。

Quant，中文对照是份。这个词不好直译，通俗地说，它指的是某个仓位里的一批货，是 WM 里库存的最小计数单位。同一个物料、不同批次，放在同一个仓位里，可以算作几个份。你可以把它理解成“这一格里有几堆货”，而不是“这一格里有几件货”。这个区分在处理批次、保质期、盘点差异的时候特别重要——光知道数量对不上不够，还得知道是哪一堆对不上。

Transfer Requirement，中文对照是转储申请；Transfer Order，中文对照是转储单。这两个是最容易被混为一谈的一对。用最直白的话说，转储申请表达的是“我想把这批货从这儿挪到那儿”这个需求，转储单则是“具体怎么挪”的执行指令，里面会写清源仓位、目标仓位、数量，执行并确认之后，库存才真正在 WM 层面完成转移。

打个比方，转储申请像一张请假条，写着“我明天想休息”；转储单像排班表，写着“明天你的班由谁接、几点到几点”。前者是意图，后者是落地。理解了这个区别，再看系统里为什么两个单据都要有，就不会觉得是多此一举了——需求可能来自很多地方，但执行必须统一收口。

还有一个细节值得注意：在入库策略里，结合仓位类型和托盘类型，可以实现灵活多变的入库方式。原文提到有项目就是用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。这句话把前面几个概念串起来了：托盘类型是条件，仓位类型是条件，搜索顺序是规则，最后决定货往哪个仓位走。整套机制不需要你手工指定位置，规则跑完，位置就出来了。

4. 易混概念辨析：这几组词最容易搞反

对照表最大的问题是它只给对应关系，不给边界。十几个术语排成两列，看着整齐，读起来却容易串味。这一章挑出五组初学者最容易混淆的概念，每一组都说清楚混在哪儿、怎么分。

4.1 存储地点和仓库号：一个管账，一个管位置

易混点：两个词都带“仓库”的意思，中文看着像上下级，实际是两套体系里的东西。

为什么混：因为它们确实经常成对出现，一个工厂下有几个存储地点，一个仓库号又对应某个范围，看配置的时候挨得很近，很容易以为是同一件事的两种叫法。

怎么区分：记住职责分工。存储地点服务于库存的账面管理，回答“有多少”；仓库号服务于仓库内部的位置管理，回答“在哪里”。一个物料在某个存储地点有 100 件库存，这是账面事实；这 100 件分别放在哪几个仓位的托盘上，这是 WM 的事实。前者没有 WM 也能成立，后者必须有 WM 才有意义。判断方法很简单：如果一个问题只关心数量和金额，它在存储地点层面就能答；如果关心具体位置和搬运路径，就必须下沉到仓库号。

4.2 存储分区和拣货区：一个管进，一个管出

易混点：两者都是“把仓位分成一组一组”，名字里都带“区”，形式上几乎一样。

为什么混：形式上确实一样，都是一批仓位的集合。如果不看用途，只看配置界面，很难说出差别。

怎么区分：看方向。存储分区是按入库管理特性划分的，影响上架策略，而且系统强制要求每个存储类型至少有一个；拣货区是按出库拣货特性划分的，影响拣货单的拆分和作业分工，属于可选项。还有一个更实用的判断：存储分区里不能定义控制参数，参数从存储类型继承；拣货区的作用则体现在作业组织上，比如拆单、分区平行作业。如果你的目的是“让货上架时有个倾向”，那是存储分区；如果目的是“让拣货的人分开干活”，那是拣货区。

4.3 仓位和存储类型：门牌号和楼栋不是一回事

易混点：仓位是最小空间单位，存储类型是存储区域，两个都是“放货的地方”，层级感不明显。

为什么混：因为中文里“仓位”和“区域”都可以泛指地方，日常说话不会那么精确。

怎么区分：用地址类比最清楚。存储类型是楼栋，仓位是门牌号。一栋楼里有很多门牌号，一个存储类型下有很多仓位，这是标准的父子关系。判断方法是看能不能直接放货：货最终一定落在某个仓位上，而不是落在“存储类型”上；存储类型只是给这些仓位划了个范围、定了一套规则。所以你在系统里查某个物料的库存位置，查到的永远是仓位号，不会是存储类型。

4.4 转储申请和转储单：想做和真做

易混点：两个词都带“转储”，中文只差一个字。

为什么混：字面太像，而且两者在流程上前后相连，看单据流的时候容易看成同一个东西的两个状态。

怎么区分：转储申请是需求凭证，转储单是执行凭证。申请可以来自多个源头，可能被合并、被拆分、被取消；转储单则是真正下达到仓库执行的那张指令，带明确的源仓位和目标仓位。一个实用的判断标准：如果这条记录还停留在“打算挪”，它是申请；如果已经到了“按这个路线挪”，它是转储单。仓库现场干活的人看的是转储单，不是申请。

4.5 仓位类型和货架类型：名字像，指的东西不一样

易混点：对照表里 Storage bin type 对应“仓位类型”，Bin Type 对应“货架类型”，两个词长得几乎一样，中文却给了两个说法。

为什么混：这是翻译带来的困扰。英文里 bin 就是仓位，bin type 直译过来是仓位类型，但对照表里给的中文写成了货架类型，于是同一件事出现了两种中文叫法，读表的人自然会对不上号。

怎么区分：别被中文绕进去，抓住它们指向的是同一类东西——对仓位这个最小单元做的类型划分，用来支撑入库策略里的组合判断。真正需要区分的是“仓位类型”和“托盘类型”：前者描述的是仓位这一格适合放什么，后者描述的是搬运用的是什么托盘。入库策略就是拿这两个条件去匹配，再加上搜索顺序，最后定下货进哪个仓位。所以看到“货架类型”这个词，直接把它理解成“仓位的类型”就行，不要真的去联想货架本身的材质或者品牌。

5. 为什么这么设计：编码、颗粒度和共用区域背后的取舍

一套用了很多年的组织结构，往往不是因为最优，而是因为每一步取舍都被现实打磨过。这一章不罗列概念，专门讲几个“为什么这么定”的问题：仓位编码为什么要留分隔符，为什么仓位要做成主数据，收货区和发货区为什么能和库存管理模块共用，仓库号到底该开一个还是几个。

5.1 仓位编码：省两个字符还是留两个字符

仓位编码看着是件小事，实际影响每天几千次操作。原文提到两种写法：01-02-03 带分隔符，010203 省略分隔符。前两位货架、中间两位列、后面两位层，这个顺序也可以调换成货架、层、列。

省略分隔符的好处很直接：减少作业中的输入信息。手工录入或者语音报读的场景里，每次少敲两个字符，一天下来就是可观的量。代价是识读难度上升，010203 这串数字，人眼要停顿一下才能断句，新人更容易看错位。

用一小段代码可以看得更清楚这种定宽编码的解析逻辑：

# 定宽仓位编码解析：分隔符可有可无，位序可配置 bin_code = "01-02-03" # 带分隔符时直接按符号切分 shelf, column, level = bin_code.split("-") # 省略分隔符时按固定宽度切片，宽度必须提前约定好 compact = bin_code.replace("-", "") shelf2 = compact[0:2] # 货架号，2 位 column2 = compact[2:4] # 列号，2 位 level2 = compact[4:6] # 层号，2 位 print(shelf, column, level) # 01 02 03 print(shelf2, column2, level2) # 01 02 03

这段逻辑里有个隐含前提：每一段的宽度必须固定，否则切片就会错位。这正是定宽编码的软肋——一旦某天仓库扩到 100 列，两位宽放不下，整个编码规则就得改，历史数据全部受牵连。所以选编码方案时真正要问的不是“能不能省分隔符”，而是“未来三五年这个仓库的规模会不会撑破位数”。规模稳定、录入量大，省分隔符划算；还在扩张、人员流动大，留着分隔符更稳。

5.2 仓位做成主数据：一次设计换来多少灵活

把仓位当主数据而不是组织结构，这个决定的价值在后面会慢慢显现。主数据可以一条条维护、可以批量导入、可以挂载业务属性。原文列出的那几个属性——最大载重量、总能力、防火分区、仓位类型——都不是摆设，它们会直接参与入库策略的匹配。

最典型的用法就是原文提到的那个例子：用托盘的仓位搜索顺序来影响入库方向，从而避免定义复杂的存储分区。这句话值得展开。假如一个仓库里重货要放底层、轻货放高层，按常规思路，你得在存储类型下面定义一堆存储分区，把底层仓位划一个区、高层仓位划一个区，再配规则。但如果仓位本身带着“最大载重量”这个属性，再配合托盘类型和搜索顺序，系统在找仓位的时候就能自动筛掉承重不够的格子，往合适的方向走。规则写一次，仓位属性维护好，以后新增仓位只要填属性，不用再回头改分区结构。

这个思路的启发是：能用主数据属性解决的问题，尽量别用组织结构去解。组织结构改动成本高，牵一发动全身；主数据属性改动成本低，加一条改一条。当然，前提是属性本身要维护得准，承重填错了，规则再漂亮也是白搭。

5.3 中间存储类型：为什么收货区能和库存模块共用

原文提到一类特殊的存储类型：可以和库存管理模块共用的中间存储类型，比如收货区、发货区、差异区、过账变更区。这几个区域的共同特点是“临时”：货在这儿只是路过，不会长期停留。

为什么它们要共用？通俗地说，因为这些区域的库存状态需要两个模块都看得见。货刚收进来、还没正式上架的时候，库存管理模块要认这笔账，仓库管理模块要知道这批货在收货区哪一格。如果两边各记一套，对账就成了日常功课。共用一套中间区域，等于给两个模块开了一扇互通的门。

这个设计也解释了为什么收货区和发货区既是存储类型，又不像普通存储类型那样长期占用。它们的定位是过渡，是流程上的缓冲带。理解了这一点，在配置的时候就不会纠结“收货区到底该划多大、该分几个分区”——它的大小取决于到货节奏，而不是存储策略。

5.4 仓库号开一个还是几个：判断标准其实只有两条

回到最开始那个问题。原文给的推荐很明确：一个仓库号管理某一地域的一组仓库建筑群；地理上隔得远，就考虑分别的仓库号；一般同一个工厂区用一个仓库号。

把这段话翻译成决策逻辑，其实就是两条：地理是否集中，业务是否统一。地理集中意味着人可以走动、设备可以调度、流程可以共用，这种情况下拆成多个仓库号，只会让配置翻倍、接口翻倍、报表合并变麻烦。地理分散意味着运输成本高、现场管理独立，硬凑成一个仓库号，反而让单位定义和接口配置变得别扭。

还有一层容易被忽略：仓库号级别定义了仓库管理使用的单位，也定义了和其他模块的接口。这意味着仓库号不只是一个地理标签，它是规则的作用域。两个业务差异很大的仓库硬塞进一个仓库号，单位定义和接口配置就会打架。所以在做这个决定之前，先问自己：这几个仓库建筑，是不是共用一套作业规则？答案如果是“是”，合并；如果是“各有一套”，拆开。规模大小反而是次要因素。

6. 什么时候该用这套体系，什么时候别硬套

概念讲清楚之后，真正难的是判断边界。SAP WM 这套位置级管理体系不是万能的，它有明确的适用前提，也有明确的力所不及之处。下面这张表可以当作一个粗略的对照，左边是适合上位置级管理的场景，右边是硬套上去只会增加负担的场景。

从这张表可以看出来，判断的核心并不是“仓库大不大”，而是“位置信息有没有被真正使用”。如果一个仓库配备了仓位管理，但现场人员每次都是随便找个空地放，系统里的仓位数据永远是摆设，那这套体系的维护成本就白花了，还不如老老实实只做账面库存。

反过来，如果仓库已经出现了这几种信号，就该考虑上位置级管理了：找货靠老员工记忆、新人上手要跟三个月、盘点时数量和位置对不上、不同区域的活分配不均、某批货要召回却不知道分散在哪几格。这些信号背后是同一个问题——位置信息没有被结构化地记录，只能靠人的经验补齐。

具体到落地顺序，我踩过的坑是先建仓位编码，再回头想存储类型怎么划。结果编码规则定死了，才发现存储类型和分区的划分逻辑跟编码对不上，返工重来。更顺的顺序应该是反过来的：先想清楚这个仓库按什么逻辑分区（按重量、按频率、还是按功能），把存储类型和存储分区定下来，再根据分区结构去设计仓位编码的位数和位序，最后才是批量建仓位、填属性。属性能填的尽量填，最大载重量和仓位类型这两项，后面配入库策略时一定会用到。

还有一个经常被低估的细节：拣货区虽然是可选项，但只要仓库里有两个人以上分区域拣货，它就值得配。因为拣货单拆不拆，直接决定现场是各干各的还是一起抢单。这个配置改起来不难，难的是改之前没人意识到问题出在这儿。

至于存储分区，如果一时想不清楚怎么划，就先建一个分区，让一对一的关系跑起来。系统强制要求每个存储类型至少有一个分区，这个“强制”其实是个善意的提醒：先有个默认值，等业务真的复杂到需要细分了，再拆。别为了显得规范，一上来就按重量、频率、功能三个维度交叉划出十几个分区，最后规则互相打架，谁也说不清某批货该进哪个区。分区的作用是让上架有方向，方向太多等于没有方向。

那份中英文对照表的价值，也正在这里。它本身只是词汇表，但当你知道 Plant 管账、仓库号管位置、存储类型划区域、存储分区定方向、仓位是最终落点、拣货区管出库分工、转储申请和转储单一个是意图一个是执行之后，这张表就变成了结构图。遇到一个没见过的术语，你能大概猜出它在哪一层、管什么事，而不是死记硬背。

从那以后我每次接手跟仓库有关的需求，都会先强制走一遍“仓库号、存储类型、存储分区、仓位”这条链，确认每一层到底有没有被真正使用，再决定要不要往下配。走过一遍，很多看起来复杂的问题会自己简化掉。希望帮到你。

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