早就听说SAP Authority Object 对权限控制比较好用，今天有幸实践下。
下面是一个简单但是完整的Authority-check的小例子：
1.创建Data Element-------（T-Code SE11）
Name: Z_ELE_01
2. 为Z_ELE_01创建一个Domain -------（T-Code SE11）
一般用现有的Domain就可以了，我这里用CHAR04
*如果将来希望配置权限的时候是可选的效果，这里就要使用自己创建的Domain。具体方法如下：
a.ME11创建
b.设置字段属性
c.设置可选值
3.创建Authorization Fields-----（T-Code SU20）
这里可以做一些设置，将此Field作为可选项或对Search Help做些设置
Field Name
Z_ATH_FLD_01
Data element
Z_ELE_01
4. 创建一个Object class -----（T-Code SU21）
多个Authorization Object是被归在一个Authorization Class中的, 其实Class用处不大仅仅是用来归类Authorization Object而已。所以可以在现有的Class中添加要创建的Authorization Object，当然也可以新建
Object Class
Z_ATH_CLS_01
Text
Authorization class 01
5. 创建Authorization Object-----（T-Code SU21）
多个Authorization Fields是被归在一个Authorization Object中的,创建好Object后需要把Z_ATH_FLD_01 assign给它.
6. 将Authorization Object Assign到T-Code上/编辑Authorization Object
-----（T-Code SU24）
此步骤可根据需要选择操作，也就是说Authorization Object不分配到T-code上当然也是可以的。
另外，可以用T-Code SU22进行管理
7.创建Role,设置Role的Authorization Object-----（T-Code PFCG）
这些其实Basis就可以了，作为Coder只是建立一个Role来测试下是不是成功assign到想要的T-code上了
8.创建测试程序
REPORT ZATH01.
DATA: ZATH_FLD(20) VALUE '01'.
AUTHORITY-CHECK OBJECT 'Z_ATH_OBJ_01'
ID ' Z_ATH_FLD_01' FIELD ZATH_FLD.
WRITE:/ ZATH_FLD.
*这个函数只能判断是否有权限，不能返回权限字段中设置的值
9.运行程序
用户必须先退出系统然后登录后前面设置的Role才会生效.
*今天测试权限费了我好大劲儿，就是因为忘记了权限的继承用了一个“不干净”的账号。
--------------------------------------------网上对于权限的文章-----------------------------
直观的说，权限就是“某人能干某事”和“某人不能干某事”之合。在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.
结语：
本文仅对系统本身做了技术性叙述，并未结合业务实际，但是我们有勾勒出了一个大致的权限矩阵，纵向是操作人（ID），横向是某些权限对象，权限对象再细分成若干事务代码、允许动作、权限字段及其允许的值等。
而实际业务中是否需要将权限划分的如此细致，完全取决于某领导的喜好、跳不过的律法、和企业内部的规章制度。