企业官网建设流程全解析

简介：SAP EWM110基础定制课程官方参与者手册，面向SAP EWM实施顾问、仓库管理及供应链从业者，旨在帮助快速掌握SAP EWM的基础配置与核心功能。内容以五天讲师指导培训为脉络，课程版本为17，依次讲解基本设置、仓库结构定义、库存管理策略、物料移动过程、仓库任务管理，并拓展设备集成、质量管理、报告分析以及与其他模块和第三方系统的接口配置；同时强调变更管理和最佳实践，为实际项目定制提供有力参考。资源为单个PDF文件，大小约17.84MB，内容结构完整，便于离线查阅。目前已有667人浏览学习，适合希望系统入门SAP EWM基础定制的技术人员，也可作为项目实施中的配置手册。

1. EWM110：一套能少走三个月弯路的基础定制手册

如果你刚接手SAP EWM的实施，拿到的第一份学习材料很可能就是这份EWM110 Basic Customizing SAP EWM参与者手册。别小看“基础定制”四个字——不少有MM或WM多年经验的顾问，第一次进EWM的SPRO照样懵：Storage Bin、Putaway Rule这些词都有印象，但配置入口、数据结构跟WM完全是两套逻辑。这份手册的价值，是把离散的定制步骤串成一条完整实施主线：先弄清系统环境和数据集成，再搭结构元素和主数据，然后定义流程类型、配置收货发货，最后落到存储控制和PPF。适合正在做EWM实施或刚转方向的顾问，也适合甲方项目经理用来核对配置范围。

2. 部署形态与系统集成：先弄清EWM跑在哪、数据怎么过来

2.1 三种部署方式怎么选

SAP EWM从设计上就是按分散式系统来做的。手册开篇就反复强调：SAP EWM generally run as a de-centralized system。这里的“basic environment”不是客套话，它直接决定了后面的数据结构、过账逻辑和接口配置。常见部署方式有三种，选错了后面每一步都别扭。

我一般会这样判断：如果历史包袱不重、ERP也确定走S/4HANA，嵌入式短期最省事；但如果仓库有自动化设备、复杂波次和劳动管理需求，分散式EWM的定制自由度明显更高。手册里建议把EWM和APO这类生产计划应用分开服务器，不是耸人听闻——EWM的仓储订单创建和PPF队列在高频业务下很吃资源，跟APO抢机器只会互相拖垮。

2.2 CIF主数据传输：从SAP ERP到SAP EWM的唯一通道

主数据的流动方向只有一个：从SAP ERP到SAP EWM。ERP是主数据主导系统，物料主数据、供应商主数据这些不在EWM里直接创建。负责搬运的就是APO Core Interface（CIF）。

CIF的配置走的是“逻辑系统 + RFC + 数据模型”这条链。常见步骤如下：

1. 在ERP和EWM两端分别定义逻辑系统，并写入各自的系统配置文件。
2. 建立RFC连接，确保QA、生产环境的RFC账号都有足够权限，不只是能ping通。
3. 在SPRO的SCM Basis里创建CIF版本（version），指定ERP逻辑系统。
4. 把需要的对象类型（物料主数据、批次、供应商等）加入CIF模型。
5. 激活模型，执行初始化传输。
6. 日常增量数据用CIF队列监控，发现积压先查qRFC是否堵塞。

逻辑说明：第3步的版本号不是简单标签，系统运行时会把模型中的对象按类型拆到不同队列，版本决定了同步优先级。第5步的初始化传输决定了ERP存量数据能否一次性搬到EWM，漏掉这一步，后续增量同步就不会带出历史数据。

参数说明：物料主数据在CIF里常见对象有MATMAS（物料）、BATCH（批次），字段增强走业务数据模型需要额外配置，不要随便改标准映射。初次实施建议把数量单位、重量、体积、存储条件这些字段先核对一遍，它们直接影响后面的库存类型和库位容量计算。

2.3 事务数据分发与qRFC：为什么实时传输不走IDoc

主数据走CIF，事务数据（交货单、收货历史等）则靠独立的distribution model。EWM和ERP之间不像传统IDoc丢给中间件就完事——内向交货单、外向交货单的实时状态必须严格按顺序到达EWM。所以手册里用一句带过：technically, both the CIF and the transactional data distribution model are based on qRFC。

qRFC（queued remote function call）的核心是把整批调用排队，保证按序执行。用个直白例子：ERP发出“创建内向交货单”和“修改交货单状态”两条消息，如果第一条还没到EWM，第二条就不能先执行，否则EWM会拿着一张不存在的交货单做收货确认。IDoc也能传，但格式转换和乱序问题上需要额外控制，优先级不如qRFC平滑。

嵌入式EWM里不存在这个传输问题，主数据和事务数据都在同一个S/4HANA系统内，CIF这步省掉，但反过来也没法像分散式那样把EWM升级到不同版本——这是选型时最容易忽略的取舍。

3. 仓库结构元素与主数据：把货架、库位和工作中心建出来

3.1 结构元素：从Warehouse Number到Storage Bin的层级

SAP EWM的仓库结构比WM多了一层Storage Section和Storage Bin Type，层级关系如下：

结构元素的创建顺序在手册Unit 3里是：先Storage Section，再Storage Bin Type，最后再生成Storage Bin。实际实施时我见过有人先建了Storage Bin再回来补Storage Section，结果仓储类型上的库存和可用性检查全为零——因为Storage Section是可用性检查的关键维度，顺序反了后面只能推倒重来。

创建Storage Bin Type的SPRO路径大致是：EWM → Master Data → Storage → Storage Bin Types。Bin Type里有一组Capacity和Blocking字段值得花时间设置。Capacity不仅用于校验物理容量，还参与Putaway Rule决策——系统会优先选空余容量合适的库位。Blocking用于临时封锁库位，比如大促前把通道两侧的仓位先占住，防止放到低效位置。

3.2 Storage Bin批量生成：坐标规则与存储类型

Storage Bin是EWM里最基础的库存落点。手工一个一个建不现实，生产性仓库一次就是上万库位，通常用坐标批量生成。

常见做法是定义好Storage Bin Type的编号规则后，在SPRO里执行批量生成功能，输入起始和结束坐标，例如：

• 通道A到D，排1到20，层1到5
• 库位编号规则：存储类型-通道-排-层，例如Z-NA-01-12-03

这样换算出来的库位总数相当可观。生成后系统自动把库位挂在对应Storage Bin Type下，并通过容量字段从Bin Type继承物理限制。

参数说明：坐标的“层”建议放在编号最后一段，因为后续的上架策略常按层区分可达性；如果仓库上层是自动化设备到不了的位置，Bin Type里要勾掉手动可达标记，避免仓储订单创建时把人分配去高空作业。

3.3 Work Center：资源与作业位置绑定

Work Center在EWM里不是SAP PP里的产能概念，而是描述一个物理作业位置——比如收货月台、拣货区起点、打包台。配置Work Center时，需要指定它连接哪个Storage Bin、哪个Storage Bin Type，以及支持哪些Warehouse Process Type。

这里最关键的坑是Work Center与Storage Bin的关联。如果Work Center绑定的Bin Type和该区域实际库存不一致，RF手持终端作业会一直报找不到工作项。排错时先看Work Center关联的queue定义，再看该queue包含的Bin是否为空Bin。

3.4 CIF主数据转移与仓库产品主数据

结构建好，得让ERP物料主数据进EWM。CIF模型把物料视图加入分发范围后，EWM端会生成对应仓库产品主数据（Warehouse Product）。注意EWM的仓库产品主数据有几个字段不是自动从ERP来的：

• 重量/体积：ERP端没维护，CIF传过来也是空，影响运输单元打托
• 包装规格（Packaging Specification）：需要在EWM手工维护，说明产品能按哪几种包装规格打包
• 存货类型相关参数：比如是否允许混放、是否要求批次独立

仓库产品主数据还有一个特征是“默认存储类型”。它决定产品首次上架时优先放到哪个Storage Type，通常和Putaway Rule配合使用。如果新产品没有维护默认存储类型，收货时系统会直接报错而不是自动落位——这套逻辑第一次遇到时特别容易翻车。

4. 流程类型与入出库策略：从收货到发货的配置主线

4.1 Warehouse Process Type：每个作业动作都要先定义

Warehouse Process Type（仓库流程类型）是EWM里最容易被忽视又最关键的配置对象。简单理解，它就是仓库内每一次具体操作的行动代码：比如E-1000上架、P-2000拣货、G-3000发运。每个流程类型决定了：

• 对应的Warehouse Order类型
• 是否需要RF/手工确认
• 是否允许数量偏差
• 库存过账方向

配置时一般分块维护：先定义类型编号，再维护它的Activity Type，最后在相关入出库策略里引用。如果几个流程类型之间的Activity Type重复，系统在生成仓储订单时会串号，最常见的现场是拣货单跑到了收货流程里。

4.2 收货侧：Availability Group与Direct Putaway

收货侧核心是到货怎么放下来。手册Unit 5里先讲Availability Group——它控制库存管理中哪些库存类型可以合并、哪些必须分离。比如A组是可用库存，B组是质检库存，二者不能混在一起参与可用性计算。

Direct Putaway的配置逻辑是：收货后系统直接根据Putaway Rule算出目标库位。配置入口通常维护号码段，再在Storage Type级别指定策略。Putaway Rule分两类：一是基于规则的，比如固定库位（Fixed Bin）、空库位优先（Empty Bin）、基于数量的最优分布；二是基于仓库产品主数据的默认存储类型。

我一般建议新手先把固定库位和基于数量的规则各配一遍，用一个小数据量场景验证，再查系统日志里Putaway解决方案的计算过程。常用Putaway Rule对比如下：

4.3 发货侧：Stock Removal策略与两步拣货

Stock Removal策略控制拣货时从哪个库位拿货。常见策略有FIFO、LIFO（基于入库时间）、按数量、按剩余库位等。和Putaway Rule类似，Storage Type上要配置Stock Removal规则，系统按策略编号去计算。

配置时最容易踩的坑是策略优先级：如果一个Storage Type同时配了FIFO和按数量，系统按策略序列来判断而不是并行。实际出库发现拣货单总是从老批次拿货，但业务想先拿大数量的新批次，就要调整策略序列，把数量策略排到FIFO前面。

Two-Step Picking是货架区常见做法：第一步整箱从存储区拣到拣货缓存区，第二步在缓存区按订单拆分到具体箱子。两步各配一个Warehouse Process Type，第二步通常配合Wave使用。

4.4 Wave：把多张出库交货单合并成一个拣货波次

Wave的价值在于把同一时间窗口、同一装运区域的多张外向交货单合并成一次拣货任务。建议先按“装运截止时间+客户区域”两个维度切Wave，而不是只按时间。配置Wave时有几个条件决定了哪些单能进同一个Wave：

• 出库交货单类型一致
• 装运点和收货方一致
• 同一Storage Type区域
• 同一Work Center

Wave创建失败，优先检查这四项是否都满足，尤其不要忽略Work Center。手册Unit 6里“Combining Items in Waves”那节也强调：Wave类型和Item类别不匹配时，系统根本不会把单子拉进来。

5. EWM110配置避坑指南：五个最常见的翻车现场

5.1 Capacity Check配了但系统不校验

现象：Storage Bin Type里明明维护了最大容量和重量，但没仓位的物料还是继续往同一个库位上架，直到库存报表显示超容。

原因：Capacity Check不是一个总开关，它分入库时可检查、出库时可检查以及后台并行检查，而且必须在Storage Bin Type的容量字段上勾选检查标记，同时Storage Type层面的容量检查也要打开。只改Bin Type那一层，系统默认还是不校验。

解决：在SPRO中把Storage Bin Type和Storage Type两个层级的容量检查都改为manual/posting模式，保存后执行一次后台重算。从那以后我每次配完Capacity都会用一笔测试收货去触发库位建议，确认超容仓位不再被选为目标。

5.2 CIF同步完成但EWM没有仓库产品主数据

现象：CIF队列显示传输成功，ERP物料主数据也带出来了，但EWM里查不到对应的Warehouse Product。

原因：EWM的仓库产品主数据依赖Storage Type和Storage Bin先存在。如果仓库结构还没建全就同步主数据，CIF只会传ERP侧数据，不会在EWM端自动建仓储维度。另外，如果CIF模型的筛选条件只选了物料类型，没包含工厂/库存地点范围，产品也到不了EWM。

解决：先确认仓库结构元素已激活，再回CIF模型重新添加工厂-库位范围，触发增量同步。遇到遗留坏数据，先在EWM侧删除对应的Warehouse Product缓存再重新同步，比在CIF里反复刷增量有效得多。

5.3 Putaway Rule怎么配都不生效

现象：产品主数据里维护了默认Storage Type，Putaway Rule也配了Fixed Bin，但收货时系统仍然给了一个完全不相关的库位。

原因：Putaway的决策顺序是Storage Type级别Putaway Rule优先于产品主数据默认Storage Type，Bin Type上的候选序列又会影响最终落位。常见情况是Storage Type上配置了数量相关规则并且策略序列排在前面，系统认为数量参数优先，把Fixed Bin规则挤掉了。

解决：在SPRO里检查Storage Type的Putaway策略序列，把Fixed Bin排到前面，或把数量规则限定到特定阈值再触发。配置完成后执行一次上架模拟，看系统计算的库位链是否符合预期。

5.4 Wave创建时总提示item不兼容

现象：新建Wave时，无论手动还是自动，总有一部分交货单没被拉进来，报错提示item category not compatible。

原因：Wave类型和交货单Item类别必须有匹配关系。通常是在后台定义Wave Type时，没把该出库交货单的Item Category加进允许列表；另一种常见情况是两张交货单的装运点不一致，被拆到不同Wave过滤条件里。

解决：对照Wave Type维护的Item Category范围，把该交货单品类加进去，同时检查装运点和收货方是否一致。注意不要为了省事把所有Item Category都勾上——跨品类合并在过账时会带来库存归属混乱。

5.5 PPF Action不触发，单据卡在某个状态

现象：交货单到了EWM，但预期的PPF行动（比如生成Wave、触发拣货）一直没有执行。

原因：PPF在EWM里分Condition和Action两层。Action定义做什么，Condition定义什么时候做。最常见的配置错误是只配了Action没配Condition，或者Condition里的处理时间点设置的触发时机晚于单据到达时间。

解决：在PPF维护界面里查看该Action的Condition记录，确认触发条件（如交货单保存、仓储订单确认等）与时间窗口。调试时用追踪功能跟踪PPF执行，看条件是否被命中。定义好Action之后，跑一笔测试单，用PPF检查工具直接看到该单据的Action实例和结果，就不再依赖事后猜测了。

6. 把存储控制和PPF串起来：一条完整的端到端验证路径

这门课最后几个单元——Storage Control、Slotting和PPF——其实是把前面所有配置串起来的粘合剂。Storage Control负责库位到库位的动作控制，Slotting决定什么产品放哪最合理，PPF是所有后处理事件的调度中心。三者单独看都能说清，但配置顺序有一个隐含的先后关系：先建结构元素，再配流程类型，然后才能配Storage Control，最后做Slotting。因为Slotting的优化结果是写回Storage Bin的，如果Storage Control还没定义好，Slotting算出来的库位候选没有实际意义。

我的习惯是：所有基础配置完成后，用一组模拟数据从“ERP创建内向交货单 → EWM收货 → 上架 → 创建外向交货单 → 波次 → 拣货 → 发货过账”走一遍，每步记录系统生成的仓储订单号、库存变化和PPF动作。这样一次端到端验证，能把前面所有章节里埋的坑全部暴露出来：Putaway Rule不生效、容量不对、PPF没触发，都会在这一遍里现形。如果某一步卡住，优先回查对应的Warehouse Process Type是否被正确引用。

另外把Storage Control里的Layout-Oriented和Process-Oriented两种方向搞清楚，是区分EWM顾问水平的常见分水岭。Process-Oriented关注动作序列，Layout-Oriented关注物理路径，两者不是互斥而是叠加。我在某跨平台系统的实施里被坑过一次——只配了Process-Oriented，结果RF终端让操作员先走到货物旁边再走上架库位，路线规划完全反了。从那以后我每次做完结构配置，都强制用一笔测试HU和一笔测试拣货单验证物理路径，确认路径顺序符合预期，再往下走。希望这套思路能帮你在自己的EWM项目里少走几步弯路。

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