网上有不少关于权限的文章，多是转来转去，COPY的台湾某个人N年前的PPT。这里用平实的语言另启一个版本。
直观的说，权限就是“某人能干某事”和“某人不能干某事”之合。在SAP系统中，用事务码（也称交易代码、或者TCODE、或者Transaction Code）表示一个用户能干的事情。比如MM01这个TCODE是用来维护物料数据的、MIGO是用来收货的、FS00是用来维护会计科目的等。
用SU01新建一个ID时，默认的权限是空白，即这个新建的ID不能做任何事情，不能使用任何事务代码。这样只需要为相应的ID赋上相应的TCODE，即可实现“某人能干某事”了，其补集，则是“某人不能干的某些事”。
但是我们不能直接在SU01里面给某个ID赋上TCODE，要通过ROLE中转一下。即：一堆TCODE组成了一个ROLE，然后把这个ROLE分给某个ID，然后这个ID就得到一堆TCODE了。
上面这些，仅仅是SAP权限控制的初级概念，要理解SAP权限控制的全部，必须还要明白下面的概念。
1、角色（ROLE）、通用角色（Common Role）、本地角色（Local Role）
上面讲了，角色，即ROLE，是一堆TCODE的集合，当然还包含有TCODE必备的“权限对象”、“权限字段”、“允许的操作”及“允许的值”等。我们使用PFCG来维护角色。
为了系统的测试与SAP实施项目的阶段性需要，进一步将角色分为“通用角色”和“本地角色”。
举个例子便于理解：通用角色好比“生产订单制单员”，本地角色对应就是“长城国际组装一分厂生产订单制单员”。所以，本地角色较之通用角色的区别就是，在同样的操作权限（事务代码们）情况下，前者多了具体的限制值。这个限制值可能是组织架构限制，也可能是其他业务的限制。如，一分厂的制单员不能维护二分厂的制单员；一分厂的制单员甲只能维护类型为A的单据，而不能维护类型为B的单据，诸如此类。
具体请看下面的概念。
2、权限对象（">Authorization Object）、权限字段（Authorization Field）、允许的操作（Activity）、允许的值（Field Value）
上文粗略说了构成ROLE的是若干TCODE。其实，在ROLE和TCODE之间，还有一个中间概念“权限对象”：
角色包含了若干权限对象，在透明表AGR_1250中有存储二者之间的关系；
权限对象包含了若干权限字段、允许的操作和允许的值，在透明表AGR_1251中体现了ROLE/Object/Field/Value之间的关系；
有一个特殊的权限对象用来包含了若干事务码。这个权限对象叫“S_TCODE”，该权限对象的权限字段叫“TCD”，该字段允许的值（Field Value）存放的就是事务代码；
有一种特殊的权限字段用来表示可以针对该权限对象做哪些操作，是允许创建、修改、显示、删除或者其他呢。该权限字段叫“ACTVT”，该字段允许的值（Field Value）存放的就是允许操作的代码，01代表创建、02代表修改、03代表显示等；
SAP的权限控制是控制到字段级的，换句话说，其权限控制机制可以检查你是否有权限维护某张透明表的某一个字段。
SAP系统自带了若干权限对象、默认控制了若干权限字段（对应到透明表的某些字段）。可以用事务码SU20来查看系统有哪些权限字段，用SU21来查看系统有哪些默认的权限对象。
于是我们知道了事务代码与权限对象的区别。从权限控制的范畴来看，事务代码属于一种特殊的权限对象；一个事务代码在执行过程中，为了判断某个ID是否有权限执行此事务代码，还可能检查其他若干普通的权限对象。使用SU22来查看某个事务代码包含了哪些权限对象。在透明表USOBX中，存放了事务码与权限对象的对应关系。
3、自定义权限对象
上文所说的系统自带权限对象与权限字段仅能满足有限的需要，其权限审核的逻辑也是系统硬编码了的，我们能做的只是是否启用某项权限对象的检查（使用SU22）。如果需要自定义，通过SU20、SU21定义即可。调用的时候在程序中加入类似代码：
AUTHORITY-CHECK OBJECT 'Z_VKORG' ID 'VKORG' FIELD 'REC_VKORG-VKORG'. IF SY-SUBRC <> 0. MESSAGE 'No Authorization!' TYPE 'E'. ENDIF.
结语：
本文仅对系统本身做了技术性叙述，并未结合业务实际，但是11545.html">我们有勾勒出了一个大致的权限矩阵，纵向是操作人（ID），横向是某些权限对象，权限对象再细分成若干事务代码、允许动作、权限字段及其允许的值等。
而实际业务中是否需要将权限划分的如此细致，完全取决于某领导的喜好、跳不过的律法、和企业内部的规章制度。