SAP 权限管理是项目里最容易被低估的一块：业务上线卡在"用户看不到菜单"，审计卡在"谁能改供应商银行账号"，事故卡在"某个 ID 拿着 SAP_ALL 跑了一年没人发现"。它不直接产生业务价值，但决定这套系统能不能安全交付、能不能过审计。

这篇把 MM 顾问和内部权限管理员真正会用到的四块内容串起来：权限的基本要素与架构 → 常用事务代码 → MM 模块主要权限对象 → 标准角色与派生角色的落地方法，最后补一节实践清单与常见坑。

一、权限管理的基本要素与架构

1.1 一句话讲清 SAP 权限

SAP 里所有权限判断最终都落到同一个句式：

某个用户，能用某个事务码，对某类数据（权限对象 + 字段值），做某个动作（活动）。

比如"采购员小张能用 ME21N 创建采购组织 1000、采购组 001 的标准采购订单"——这句话在系统里被翻译成：事务码 S_TCODE=ME21N，权限对象 M_BEST_EKO（EKORG=1000）、M_BEST_EKG（EKGRP=001）、M_BEST_BSA（BSART=NB）、M_BEST_WRK（WERKS=1000），活动 ACTVT=01。

权力不是直接挂在用户身上的，中间要经过角色 → 参数文件两级中转。这是 SAP 权限模型和"给用户配菜单"最本质的区别。

1.2 六个基本要素

补充两个高频概念：

• 事务码（T-Code）：菜单入口，本身通过权限对象 S_TCODE 检查。没有 S_TCODE，菜单点不动，后面所有对象检查都不会发生。
• 活动（ACTVT）：常用的几个值——01 创建、02 更改、03 显示、06 删除、77 暂存（Park，票据类场景常见）。

1.3 授权数据的层级架构

graph TD
    A["用户主记录<br/>SU01<br/>User"] --> B["角色 Role<br/>PFCG"]
    B --> B1["单一角色<br/>Single Role<br/>生成参数文件"]
    B --> B2["复合角色<br/>Composite Role<br/>只做打包，不生成参数文件"]
    B --> B3["派生角色<br/>Derived Role<br/>继承菜单，组织值可变"]
    B1 --> C["参数文件 Profile<br/>真正生效的权限容器"]
    B2 --> B1
    C --> D["授权 Authorization"]
    D --> E["权限对象<br/>Authorization Object"]
    E --> F["权限字段 + 值<br/>Field / Value<br/>如 WERKS=1000"]
    A -.分配.-> B

几个必须记牢的规则：

1. 角色是给人看的，参数文件才是给系统看的。 改完角色不"生成"参数文件，权限不会生效。
2. 复合角色只做打包，本身不生成参数文件；用户分到复合角色后，生效的是它下面挂的各个单一角色。
3. 多个角色之间是"或"关系：用户做某个操作，只要有任意一个角色提供了对应授权，检查就通过。这也是权限越配越大、最后没人说得清"这个用户到底能干什么"的根源。
4. 授权是"最小匹配 + 并集"：用户的最终权限 = 所有已分配角色（含参数文件）里所有授权的并集，不会因为另一个角色限制得更严而收紧。

1.4 权限是怎么被检查的

SAP 标准程序在关键动作前会调用权限检查（AUTHORITY-CHECK），检查点由开发决定，检查用的权限对象和字段可以在 SU24 里看到（它就是给每个事务码维护"该检查哪些对象"的默认值表）。典型的检查链路：

graph LR
    A["用户执行事务码<br/>如 ME21N"] --> B["检查 S_TCODE"]
    B --> C["检查业务权限对象<br/>M_BEST_* / M_BANF_*"]
    C -->|通过| D["业务继续"]
    C -->|不通过| E["报错：无权限"]
    E --> F["用户执行 SU53<br/>看最后一次失败的检查"]
    F --> G["找到对象+字段+值"]
    G --> H["PFCG 改角色<br/>生成参数文件"]
    H --> I["用户重新登录<br/>或检查用户缓冲"]

诊断时四个事务码按顺序用：

1.5 用户主记录里的关键字段

SU01 里除了用户名密码，这几个字段跟权限强相关：

参考用户（Reference User）：新建用户时指定一个参考用户，可以把角色、参数一并复制过来，是批量建号的标准做法。用户组配合权限对象 S_USER_GRP 使用，实现"总部管理员只能管总部账号，工厂管理员只能管工厂账号"——这是审计必查的分权点。

二、常用事务代码

2.1 用户管理

2.2 角色与权限维护

2.3 权限检查与查询

2.4 审计与批量报表（SUIM 里的标准报表）

审计场景的常见需求基本都是这几张报表 + SUIM 组合出来的：用户清单、角色清单、某事务码被给了哪些人、某权限对象的值都赋了哪些（有没有满天飞 *）、离职账号是否还在有效期。

2.5 权限相关核心表（排查用）

实用技巧：想查"某个事务码被哪些角色包含"，AGR_1251 按 S_TCODE 过滤最快；想查"哪些角色含某权限对象"，同样在 AGR_1251 里按对象名过滤。

三、MM 模块主要权限对象

3.1 命名规则与对象类

MM 的权限对象命名基本是 M_<业务对象>_<限定>：M_BEST（Bestellung，采购订单）+ _EKO（采购组织）→ 可猜出含义。对象类（Authorization Class）在 SU21 里查看，MM 相关的主要是：

3.2 采购凭证类权限对象（MM_E）

ME21N / ME22N / ME23N（采购订单）的标准检查对象就是 M_BEST_BSA + M_BEST_EKG + M_BEST_EKO + M_BEST_WRK 这四个，配 S_TCODE 一起检查；M_BEST_WRK 检查的是收货工厂（WERKS）。

3.3 采购审批权限对象

审批是权限设计里最容易翻车的地方，涉及两个对象：

落地要点：不同审批级别 = 同一个对象的不同字段值。一级审批给 FRGGR=FP, FRGCO=R1，二级给 FRGCO=R2，三级给 R3，配合 S_TCODE 里的 ME28/ME29N，就形成了"谁能批、批到哪一级"的矩阵。角色里写错一个字符（比如给了 R1 的人顺手给了 R2），等于审批链形同虚设。

3.4 货物移动与库存（MM_B）

移动类型（BWART）是库存权限的核心维度：只给 101（采购收货）和给 *（全部移动类型，含 551 报废、601 发货、309 转储）是完全不同量级的授权。仓库岗位的权限设计必须显式枚举移动类型，不允许用 * 兜底。

3.5 发票校验（MM_R）

发票校验是职责分离的重点区域：录发票的人（MIRO，活动 01）和审批放行的人（M_RECH_EKG / 审批策略）应当分开；M_RECH_AKZ（手工接受差异）单独给，避免"录入 + 放行 + 接受差异"全在一人手里。

3.6 物料主数据（MM_G）

物料主数据的权限设计要同时控制"物料类型/范围"和"视图（维护状态）"：采购员只该维护采购视图（维护状态 E），会计视图（B）归财务。只给 M_MATE_MAR 不给 M_MATE_STA，等于把物料的所有视图都敞开了。

以上字段以 SAP ECC 6.0 标准系统为准（SU21 / TOBJ 可实时核对）。S/4HANA 中部分对象和检查点有调整，实施时以实际系统 SU24 显示的检查对象为最终依据。

3.7 怎么快速找到"某个操作要什么权限"

三种办法，按效率排序：

1. SU24：输入事务码，直接列出该事务码会检查的权限对象和字段，还能看"检查标识"（是否强制检查）。这是最权威的映射表。
2. SU53 实测：让业务用户实操一次、截图 SU53 结果。生产环境排查最快，也能确认默认值之外的自定义检查。
3. SE16N 查 TOBJ：按对象类（如 MM_E）列出该类的所有权限对象和字段，适合做角色设计前的"扫一遍"。

四、标准角色与派生角色应用

4.1 标准角色：SAP 交付的模板，不是给用户用的

SAP 为大量业务场景交付了标准角色（PFCG 角色），例如 MM 采购相关就有：

正确用法是复制（Copy）：在 PFCG 里新建一个 Z* 角色，把标准角色里需要的菜单和权限段复制过来，再按企业实际的组织结构（采购组织、工厂、采购组）调整。不要把 SAP 标准角色直接分配给业务用户——理由很实在：

1. 标准角色是为演示/参考设计的，权限范围通常偏大（大量 *），过不了审计；
2. 升级时 SAP 会覆盖标准角色，你的调整会丢；
3. 多个标准角色堆在一起，用户的最终权限是不受控的并集。

4.2 派生角色：一次设计，多处复用

派生角色（Derived Role） 解决的是一个非常具体的重复劳动：

菜单和权限结构完全一样，只有组织级的值不同（工厂 1000 和 2000、公司代码 A 和 B）。

它的继承规则（来自 SAP 官方说明）：

再补三条实操才有价值的细节：

1. 母角色里点"生成派生角色"按钮：会把普通字段（非组织层次）复制到所有派生角色，并生成参数文件。组织级数据只有在派生角色的权限数据首次被修改时才传输，且如果派生角色已维护过组织级值，不会被覆盖（见 SAP Note 314513）。
2. 派生角色里点"传输数据"按钮：用于初始填充，把模板的所有一般授权值复制过来；派生角色中未填的组织级字段，也会带上参考角色的值。
3. 继承关系可以取消，但取消后不可撤销，被取消的角色从此当作普通角色处理（菜单也变成可编辑）。

4.3 创建派生角色的步骤

1. PFCG 输入派生角色名（如 Z_MM_PUR_BUYER_2000）+ 描述，回车新建；
2. 在描述页签的"派生自角色（Derive from Role）"字段填入母角色名（如 Z_MM_PUR_BUYER）；
3. 保存——菜单和事务码会立即从母角色填充过来（这一点比复合角色省事得多）；
4. 切换到权限页签 → 更改授权数据，只维护组织级字段（采购组织、工厂、采购组、公司代码等）；
5. 生成参数文件（Ctrl+F3 / 状态栏按钮"生成"），保存；
6. 用 SU01 把派生角色分配给对应用户，必要时跑 PFUD 做用户比较。

4.4 三种角色形态怎么选

4.5 MM 角色设计示例（含派生）

一个典型的采购部权限矩阵可以这么切：

命名建议：Z_<模块>_<业务域>_<岗位>_<组织值>，例：Z_MM_PUR_BUYER_1000。好处一眼能看出用途，SUIM 反查和离职清理都不会漏。

五、落地实践与常见坑

5.1 权限管理自身的权限（分权）

权限管理员不需要 SAP_ALL。管理权限的工作本身也由权限对象控制，常用的几个：

最低要求：用户管理员（建号改号）和权限管理员（改角色）分设两个人，且都不给 SAP_ALL。

5.2 高频踩坑清单

1. 改完角色没生成参数文件：PFCG 保存 ≠ 生效，必须生成参数文件（状态栏变绿）。
2. 角色菜单里加了事务码，但没分配对应业务权限对象：菜单能看到，点进去报"无权限"，新人最常犯。
3. 指望用户重新登录就万事大吉：先查 SU56 用户缓冲，必要时让用户重新登录/清理缓冲。
4. 组织级字段用 * 兜底：工厂写 *、采购组写 *，等于没做隔离，审计一抓一个准。
5. 派生角色里手改菜单：改不了（设计如此），要改必须回母角色，或者改用复制方案。
6. 复合角色 + 派生角色混用后搞不清来源：用户权限要靠 SUIM / AGR_1251 反查，不要靠记忆。
7. SU24 默认值被随意改动：会让"标准检查点"飘移，跨系统行为不一致；改动要有文档和传输。
8. 升级后不跑 SU25：新版本新增的权限检查点没有初始化，会出现"以前能用、升级后报权限"的批量问题。
9. 离职/转岗只锁账号不回收角色：USR02 的有效期和锁定状态要一起管，离职清单要和 HR 对账。
10. 生产环境直接改权限不留痕：角色变更用传输（PFCG 角色的传输）管理，配合 RSUSR100/SU2 查变更历史。

5.3 上线与传输检查清单

• 角色在开发系统维护 → 通过传输请求传到测试/生产（不要在生产线手改）；
• 传输后跑 PFUD（用户比较），确保用户主记录与角色的参数文件一致；
• 角色数量多时用 SUPC 批量生成参数文件；
• 每次升级后按 SAP 标准流程跑 SU25（两步：先初始化客户表，再对照调整）；
• 上线前用 SUIM + RSUSR003（初始密码）、RSUSR006（锁定/未登录）过一遍账号状态；
• 保留一份"角色-用户-组织值"清单，作为审计和交接材料。

5.4 S/4HANA 与 Fiori 的权限变化

S/4HANA 时代权限体系多了一层：业务角色（Business Role）→ 业务目录（Business Catalog）→ 业务组（Business Group），Fiori 应用的可见性由业务目录控制，而业务角色里的技术层最终仍然落到传统的 PFCG 角色和参数文件上。实务上要记住两点：

• 传统事务码（ME21N、MIGO 等）和 Fiori 应用可以共存，权限设计要保证"同一个人不管从哪个入口进来，权限边界一致"；
• 做 Fiori launchpad 部署时，"能不能打开应用（目录/组）"和"进去能做什么（后端权限对象）"是两件事，缺一个都会报错。

六、总结

1. SAP 权限的本质：用户 → 角色 → 参数文件 → 授权（权限对象 + 字段 + 值），事务码是最外层入口（S_TCODE）。
2. 工具链固定：PFCG 设计、SU01/SU10 分配、SU24 看检查点、SU53/ST01/SU56 排障、SUIM/RSUSR* 审计、SU25/PFUD 上线与升级。
3. MM 权限对象按域记：采购凭证 M_BANF_* / M_BEST_*、询报价 M_ANFR_* / M_ANGB_*、框架协议 M_RAHM_*、信息记录 M_EINF_*、审批 M_EINK_FRG / M_BANF_FRG、货物移动 M_MSEG_*、盘点 M_ISEG_*、发票校验 M_RECH_*、物料主数据 M_MATE_*。
4. 标准角色只当模板，复制改造后用；结构相同、组织值不同的场景用派生角色，一次设计多处复用。
5. 权限设计的三条底线：最小权限、职责分离、用 * 之前想清楚。

版本说明：本文基于 SAP ECC 6.0 与 S/4HANA 标准功能整理（标准事务码、权限对象、标准角色名以 SAP 交付内容为准）。ECC 与 S/4HANA 在标准角色命名（如业务角色 SAP_BR_*）和部分检查点上有差异，实施时请以实际系统的 SU21 / SU24 / SUIM 查询结果为准。

参考资料

• SAP Help Portal — Invoice Verification (MM-IV): Authorizations（标准权限对象清单）
• SAP Help Portal — Materials Management (MM): Authorizations（MM 标准角色清单：SAP_MM_PUR_*）
• SAP Help Portal — Roles and Authorizations（标准 PFCG 角色的定位与用法）
• SAP Learning — Implementing a Derived Role Strategy（派生角色继承规则、两种数据比较方式、SAP Note 314513）
• SAP Community — MM Authorization objects / MM Related Authorization Objects: How to Find out & Assign（MM 权限对象与字段、TOBJ 查法、SU53 排障流程）
• 枫竹丹青 — 采购订单的审批操作和权限管理（M_EINK_FRG 的 FRGGR/FRGCO 与 ME28/ME29N 实操）
• 知乎专栏 — SAP 如何查询 MM 模块标准权限对象（按对象类导出的 MM 权限对象/字段对照）
• SAP Security 事务码清单（BASIS 权限管理常用 T-Code 参考）