BASIS權(quán)限的設(shè)定-達沃旗SAP課件

目錄1.總述2.職能/TemplateRole/設(shè)定的分工3.三種不同的常規(guī)權(quán)限的設(shè)定方法4.常規(guī)以外的權(quán)限設(shè)定方式5.如何快速檢查權(quán)限設(shè)定的情況目錄1.總述總述1.在開始學(xué)習之前2.SAP權(quán)限的架構(gòu)總述1.在開始學(xué)習之前在開始學(xué)習之前在開始了解權(quán)限前,有幾點是要大家注意的1.權(quán)限設(shè)定非常重要﹐而且權(quán)限的DEBUG操作非常繁瑣,耗時,所以請大家設(shè)定時一定要非常謹慎,每次更改都要記錄。2.權(quán)限設(shè)定除非特殊情況﹐不允許在正式環(huán)境直接更改﹐請在測試環(huán)境修改好再傳到正式環(huán)境。3.MIS不是決定user權(quán)限的人﹐而是user大大小小的leader﹐所以﹐要變更權(quán)限設(shè)定﹐務(wù)必要求user提供經(jīng)過簽核的申請表。（當然﹐對user不合理的權(quán)限要求﹐MIS也有責任退回）4.權(quán)限的設(shè)定,是MIS的工作.（廢話）所以﹐本教材是MIS內(nèi)部教材﹐請不要隨便泄漏在開始學(xué)習之前在開始了解權(quán)限前,有幾點是要大家注意的SAP權(quán)限的架構(gòu)Roletemplate-Description-Menu-Authorizations……………Authorizationprofile-Objectclass-Authorizationobject-Authorizations………………..AssigntoBindwithAssigntoSAPUseraccount-Address-Logondata-Group............這是SAP權(quán)限的架構(gòu)圖﹐大家也接觸過。請大家一定要記住他們的關(guān)系。SAP權(quán)限的架構(gòu)RoletemplateAuthorizaSAP權(quán)限的架構(gòu)名詞解釋（英譯中﹖）﹕Useraccount﹕就是我們平常說的“帳號”﹐也稱為“USERID”。Role﹕同類的USER使用SAP的目的和常用的功能都是類似的﹐例如業(yè)務(wù)一定需要用到開S/O的權(quán)限。當我們把某類USER需要的權(quán)限都歸到一個集合中﹐這個集合就是“職能”(Role)。 所謂的“角色”或者“職能”﹐是sap4.0才開始有的概念﹐其實就是對user的需求進行歸類﹐使權(quán)限的設(shè)定更方便。(面向?qū)ο蟮臋?quán)限!!)

分為singlerole和compositerole兩種﹐后者其實是前者的集合。SAP權(quán)限的架構(gòu)名詞解釋（英譯中﹖）﹕SAP權(quán)限的架構(gòu)Profile:真正記錄權(quán)限的設(shè)定的文件﹐從sap4.0開始是與Role綁定在一起的。雖然在sap4.6c還可以單獨存在﹐但按sap的行為推測﹐以后將不能“一個人活著”TemplateRole:Role的模板﹐一般是singlerole.但這個模板具有一個強大的功能﹐能通過更改模板而更改所有應(yīng)用(sap稱為Derive“繼承”）此模板的Role(sap稱之為adjust)SAP權(quán)限的架構(gòu)Profile:真正記錄權(quán)限的設(shè)定的文件﹐SAP權(quán)限的架構(gòu)例外權(quán)限﹕這是公司創(chuàng)造的名詞。當一個USER除了其職位一般所需的權(quán)限外﹐還需要一些特殊的權(quán)限﹐我們把這些權(quán)限稱之為這個USER的例外權(quán)限。 例如開工單對生管來說是其職能應(yīng)有的權(quán)限﹐但對倉庫來所就是例外權(quán)限。SAP權(quán)限的架構(gòu)例外權(quán)限﹕這是公司創(chuàng)造的名詞。當一個USERRole的命名和分類Role的命名規(guī)則和分類如下:以“G+”開頭都是TemplateRole(模板)﹐都不會直接assign給userid。G+職能名稱 ﹕全球共同TemplateRoleG+職能名稱-1 ﹕地區(qū)TemplateRole以“Z+”開頭都是UserRole,直接assign給userid。Z+UserID+職能名稱 :繼承全球共同TemplateRoleZ+UserID+職能名稱-1:繼承地區(qū)TemplateRoleZ+UserID+Exception :沒有繼承任何Role,例外權(quán)限以“Y+”開頭都是BasisRole,直接assign給userid。Y+職能名稱 :全球共同BasisRoleRole的命名和分類Role的命名規(guī)則和分類如下:Role的命名和分類附件是一張職能/Rolename對照表我們以其中一個職能“AR作業(yè)人員”做解釋﹕職能中文名稱職能英文名稱全球共同TemplateRole地區(qū)TemplateRole全球共同BasisRoleRole的命名和分類附件是一張職能/Rolename對照表職Role的命名和分類全球共同TemplateRole﹕是指此職能在全球任何一個地區(qū)都一致的那部分權(quán)限的模板。命名特征是以“G+”開頭﹐非“-1”結(jié)尾。 例如“G+CO–CO”地區(qū)TemplateRole﹕是指此職能根據(jù)不同地區(qū)而不同的那部分權(quán)限的模板。命名特征是“G+”開頭﹐“-1”結(jié)尾。 例如“G+CO–CO–1”Role的命名和分類全球共同TemplateRole﹕是指Role的命名和分類UserRole﹕是指根據(jù)每個user的具體需求進行設(shè)定的權(quán)限的Role.命名特征是﹕“Z+”USERID開頭（東莞﹑臺灣地區(qū)）“W+”USERID開頭（吳江地區(qū)） 例如“Z+PSC1-ACT01+CO-CO”全球共同BasisRole﹕是指此職能關(guān)系到整個系統(tǒng)的安全的那部分權(quán)限的Role.命名特征是“Y+”開頭 例如“Y+CO–CO”Role的命名和分類UserRole﹕是指根據(jù)每個user權(quán)限設(shè)定者分工一.以Role類型分1.TemplateRole

即“G”開頭的:臺北本部的APMIS2.UserRole:

以Z開頭的:東莞APMIS

以W開頭的:吳江APMIS3.BasisRole:

即以Y開頭的:臺北和東莞BasisMIS權(quán)限設(shè)定者分工一.以Role類型分權(quán)限設(shè)定者分工二.以USERID分從USERID可以區(qū)分出這個ID所屬的廠別和模組。例如﹕PSC1-ENG01這是PSC1廠的帳號﹐屬于PP模組﹐所以這個帳號申請的權(quán)限將由東莞PP模組的MIS主要負責和監(jiān)督。權(quán)限設(shè)定者分工二.以USERID分權(quán)限設(shè)定者分工三.以所申請的權(quán)限歸屬的模組分 由于user所申請的權(quán)限通常涉及多個模組﹐這就需要多個模組的MIS共同合作設(shè)定user的權(quán)限﹐這時先按第二條執(zhí)行,由ID所屬模組MIS接受申請﹐并從始至終跟進。然后具體的權(quán)限屬于哪個模組就由那個模組的MIS作設(shè)定。 但無論如何﹐作為跟進的MIS都是負主要責任的。權(quán)限設(shè)定者分工三.以所申請的權(quán)限歸屬的模組分權(quán)限設(shè)定的操作

上面說過﹐權(quán)限的大架構(gòu)由UserID,Role,Profile三層組成﹐那么﹐權(quán)限的設(shè)定自然也會有三層。但由于sap4.6是Profile與Role是捆綁在一起的﹐所以在建立Role的時候﹐Profile是會自動創(chuàng)建的（具體見后文）。而UserID的建立比較簡單。所以﹐我將主要說明Role的部分。權(quán)限設(shè)定的操作 上面說過﹐權(quán)限的大架構(gòu)由UserID,USERID的建立TCODE﹕SU01單擊建立圖標2輸入要創(chuàng)建的UserID1USERID的建立TCODE﹕SU01單擊建立USERID的建立填好這些欄位USERID的建立填好這些欄位USERID的建立設(shè)定組別﹐這對MIS非常重要﹐MIS能否管理此UserID就看這里設(shè)定初始密碼有效期一般不設(shè)定USERID的建立設(shè)定組別﹐這對MIS非常重要﹐MIS能USERID的建立按圖設(shè)定（印表機按實際設(shè)定）USERID的建立按圖設(shè)定（印表機按實際設(shè)定）USERID的建立接著按save﹐就把USERID創(chuàng)建好了 USERID創(chuàng)建好了﹐但這時這個ID沒有賦予(Assign)任何權(quán)限﹐是什么都不能做的。USER得到這樣的帳號沒有任何意義。 如何Assign權(quán)限給一個帳號﹖主要就是Assign一個Role給這個帳號了。下面我們看看如何建Role和給權(quán)限。USERID的建立接著按save﹐就把USERID創(chuàng)建Role的建立新創(chuàng)建Role主要有三種方式。TCODE﹕PFCG1.由始至終新建;

可以對應(yīng)所有新建Role。主要對應(yīng)例外權(quán)限Z+USERID+EXCEPTION2.繼承;

主要對應(yīng)設(shè)定Z+USERID+職能名稱3.復(fù)制（COPY）﹔

主要對應(yīng)設(shè)定Z+USERID+職能名稱-1Role的建立新創(chuàng)建Role主要有三種方式。TCODE﹕Role的建立—完全新建

我們假設(shè)有一個帳號“FORTEST”,他申請了例外權(quán)限VA01和YF30。 下面我將會一步一步向大家說明操作的步驟和應(yīng)該注意的地方。 看到PFCG的畫面了嗎﹖沒有﹖

哦﹐在下一頁。Role的建立—完全新建 我們假設(shè)有一個帳號“FORTERole的建立—完全新建輸入Rolename注意選第二項Role的建立—完全新建輸入Rolename注意選第二項Role的建立—完全新建描述一般與Rolename一致記錄此Role的創(chuàng)建者記錄此Role的最后修改者把描述填好后﹐按save然后點擊menu頁簽Role的建立—完全新建描述一般與Rolename一致記錄Role的建立—完全新建建立新目錄修改TEXT項目下移項目上移刪除項目手動增加Tcode從SAPMenu中增加Tcode從其他Role中CopyMenu這些是常用的功能Menu頁簽定義的是USERMENU（個人化菜單）的內(nèi)容。Role的建立—完全新建建立新目錄修改TEXT項目下移項目上Role的建立—完全新建請大家按圖所示建立目錄﹐第一層是職能﹐這里是EXCEPTION﹐下面分“標準”(Standark)和“外掛”(AddOn)兩個目錄。讓菜單保持清晰﹐可以令User的個人菜單清楚﹐不混亂。我們MIS檢查權(quán)限也比較方便。Role的建立—完全新建請大家按圖所示建立目錄﹐第一層是職Role的建立—完全新建大家可以對比下面兩個USER的個人化菜單﹐左邊職能清晰﹐右邊非常混亂﹐同名的目錄大量出現(xiàn)﹐但里面的內(nèi)容又不盡相同﹐這對依賴路徑執(zhí)行指令的user是很麻煩的。Role的建立—完全新建大家可以對比下面兩個USER的個人化Role的建立—完全新建菜單的殼子有了﹐如何往里面添加內(nèi)容呢﹖比較常見的是﹕從SAP菜單添加和直接添加TCODE。從SAP菜單添加﹕所有標準的TCODE和沒有TCODE的標準程式都可以用這種方法添加。好處是可以尋找﹐可以一次添加標準菜單的一個目錄﹐Tcode在標準菜單中的位置也可以顯示出來。缺點是很浪費時間﹐而且外掛的程式無法添加。Role的建立—完全新建菜單的殼子有了﹐如何往里面添加內(nèi)容呢Role的建立—完全新建直接添加﹕所有TCODE(包括外掛）和沒有TCODE的標準程式都可以用這種方法添加。好處是比較快缺點是必須知道Tcode﹐不能帶出路徑。Role的建立—完全新建直接添加﹕Role的建立—完全新建從SAP菜單添加Role的建立—完全新建從SAP菜單添加Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建OBJECT完全沒有給值OBJECT只有部分給值OBJECT已經(jīng)全部有值請注意﹕綠燈只是表示全部有值而已﹐但不一定就是我們所需要的值這時﹐標準Tcode所需要的Object﹐系統(tǒng)會自動帶出來。Role的建立—完全新建OBJECT完全沒有給值OBJECTRole的建立—完全新建這個Object是任何權(quán)限設(shè)定文件中都應(yīng)該有的﹐這是給予啟動Tcode的權(quán)限﹐如果Tcode沒有出現(xiàn)在這個列表中﹐user連這個指令的畫面都無法進入Role的建立—完全新建這個Object是任何權(quán)限設(shè)定文件中Role的建立—完全新建在這里﹐需要向大家介紹一個很重要的概念﹕Org.level.在權(quán)限設(shè)定中﹐有許多地方的控制點是一致的﹐sap公司為了方便權(quán)限的設(shè)定﹐把這些地方設(shè)計為與全局變數(shù)關(guān)聯(lián)。當改變?nèi)肿償?shù)時﹐這些地方就可以全部改變過來。這個全局的變數(shù)就是﹕Org.levelRole的建立—完全新建在這里﹐需要向大家介紹一個很重要的概Role的建立—完全新建當Org.Level給值后﹐相應(yīng)的Objectvalue的值也變了Role的建立—完全新建當Org.Level給值后﹐相應(yīng)的ORole的建立—完全新建

對Org.Level都給值之后﹐會發(fā)現(xiàn)相當一部分的Objectvalue都已經(jīng)給值了﹐但還有一些Object是紅燈或者是黃燈﹐這些Object是要單獨給值的。Role的建立—完全新建 對Org.Level都給值之后﹐會Role的建立—完全新建

按一下標志﹐就可以輸入值﹐按保存 在這里介紹一下的作用﹐點擊它﹐就相當於給這個Object一個“*”(star)﹐“*”的意義是AllAuthorization﹐不卡任何權(quán)限。Object給值后﹐就變成綠色﹐不能點擊了。Role的建立—完全新建 按一下標志﹐就可以輸入Role的建立—完全新建

如果是外掛的Tcode﹐就只能用“直接添加”的方式加入到菜單中﹐需要注意的是﹐外掛的Tcode的Object不會自動帶出來﹐需要自己手工添加。 按﹐點擊Y-AUTH-PRT前的Role的建立—完全新建 如果是外掛的Tcode﹐就只能Role的建立—完全新建變?yōu)楹螬o按屏幕上方的﹐插入Object.注意﹕外掛的Tcode﹐除了前面所說的列表中要有外﹐這里框住的地方要給Tcode﹐否則user還是不會有權(quán)限Role的建立—完全新建變?yōu)楹螬o按屏幕上方的Role的建立—完全新建都給好值后﹐按保存﹐按“勾”。然后按激活。退出。Role的建立—完全新建都給好值后﹐按保存﹐按Role的建立—完全新建Authorization已經(jīng)變成綠燈﹐這表示權(quán)限的設(shè)定已經(jīng)可用了。點擊USER,AssignUSERID給這個RoleRole的建立—完全新建Authorization已經(jīng)變成綠Role的建立—完全新建點擊USERCOMPARE﹐再點擊Completecompare﹐就完成了COMPARE。至此﹐此權(quán)限已經(jīng)Assign完畢﹐FORTEST這個帳號已經(jīng)具有VA01和YF30的權(quán)限Role的建立—完全新建點擊USERCOMPARE﹐Role的建立—繼承

所謂“繼承”,是指兩個Role形成這樣的母子關(guān)系﹕子Role的所有Menu,Authorization（Org.level除外)都源于母Role,并與母Role保持一致。 母Role與子Role是

1對多的。Role的建立—繼承 所謂“繼承”,是指兩個Role形成這Role的建立—繼承下面﹐我們來學(xué)習用“繼承”方式建立Role.我們假設(shè)有一個帳號“FORTEST”,他申請了職能“AP立帳員”﹐“AP立帳員”的TemplateRole是“G+CO-AP”。我們先來按命名規(guī)則Create一個新Role。Role的建立—繼承下面﹐我們來學(xué)習用“繼承”方式建立RolRole的建立—繼承大家注意這個地方﹐建立“繼承”關(guān)系就是靠這里了Role的建立—繼承大家注意這個地方﹐建立“繼承”關(guān)系就是靠Role的建立—繼承填入TemplateRole,按Enter.是否建立繼承關(guān)系﹖回答當然是“YES”了﹐否則我們怎樣上課﹖如果在此前沒有做過存檔﹐系統(tǒng)會詢問是否存檔﹐回答同樣是“YES”Role的建立—繼承填入TemplateRole,按EntRole的建立—繼承可以看到﹐菜單已經(jīng)自動根據(jù)TemplateRole生成了,點擊Authorization頁簽﹐設(shè)定權(quán)限去。Role的建立—繼承可以看到﹐菜單已經(jīng)自動根據(jù)TemplatRole的建立—繼承進入Profile里面了﹐請注意下面所說的操作﹐如果做錯了﹐可能要拉倒從新開始的喲。點擊這個按鈕1.系統(tǒng)會自動進入Org.level﹐請點擊“X”,退出Org.level。2.按“SAVE”對Profile存檔。Role的建立—繼承進入Profile里面了﹐請注意下面所說Role的建立—繼承3.執(zhí)行菜單Edit中的Copydata,系統(tǒng)會提示這個操作不可反轉(zhuǎn)。按“勾”繼續(xù),執(zhí)行完畢后我們會看到﹐許多Object已經(jīng)變成綠燈了。Role的建立—繼承3.執(zhí)行菜單Edit中的CopydatRole的建立—繼承現(xiàn)在可以維護Org.level的設(shè)定了。進入的方法如上。當Org.level每一個欄位都賦值之后﹐應(yīng)該每一個Object都是綠燈﹐如果還有紅黃燈﹐請通知臺北修正。Role的建立—繼承現(xiàn)在可以維護Org.level的設(shè)定了。Role的建立—繼承

當所有權(quán)限（其實只是設(shè)定Org.level)都設(shè)定完畢后﹐按激活設(shè)定﹐Assign給USERID,就完成了。Role的建立—繼承 當所有權(quán)限（其實只是設(shè)定Org.leRole的建立—繼承大家是否覺得“繼承”的方法好簡單﹐幾下就做完了。其實這種方法思路最復(fù)雜了﹐后面的處理還隱藏不少陷阱。不過現(xiàn)在大家先掌握Role的建立方法﹐其它的問題等一下再說。那么﹐我們來看看第三種方法—復(fù)制。Role的建立—繼承大家是否覺得“繼承”的方法好簡單﹐幾下就Role的建立—復(fù)制復(fù)制其實是一種從思想到操作都很簡單的操作。它的核心就是—……復(fù)制!(雞蛋和番茄飛了起來……）我們來看看如何操作吧。先告訴大家﹕“AP立帳員”的TemplateRole還有一個﹐是“G+CO-AP-1”﹐我們就用它來學(xué)習。Role的建立—復(fù)制復(fù)制其實是一種從思想到操作都很簡單的操作Role的建立—復(fù)制一開始當然是進入PFCG了﹐先把TemplateRole名輸進去﹐然后按COPY按鈕Role的建立—復(fù)制一開始當然是進入PFCG了﹐先把TempRole的建立—復(fù)制Role的建立—復(fù)制Role的建立—復(fù)制把描述改成與Role名一樣要注意“-1”的Role的menu是空的這里是空的Role的建立—復(fù)制把描述改成與Role名一樣要注意“-1”Role的建立—復(fù)制紅色框住的都是要填入值的地方﹐最好先填完Org.levelRole的建立—復(fù)制紅色框住的都是要填入值的地方﹐最好先填完Role的建立—復(fù)制與其它方式建立的Role一樣,當所有權(quán)限都設(shè)定完畢后﹐按激活設(shè)定﹐Assign給USERID﹐一個Role就設(shè)定完成了Role的建立—復(fù)制與其它方式建立的Role一樣,當所有權(quán)限Role的建立—繼承與復(fù)制小結(jié)﹕非“-1”的那種TemplateRole﹐用繼承的方式建立新Role,繼承后﹐只需要填入Org.level﹐Object就全部是綠燈了﹐而“-1”的那種是用復(fù)制的方式﹐還需要在Object里填入值﹐才能全部綠燈。這是兩者操作上的最大特點。Role的建立—繼承與復(fù)制小結(jié)﹕Role的修改1.Merge2.新增/刪除TCode3.從其它Role導(dǎo)入4.AdjustRole的修改1.MergeRole的修改

對Role的修改最常見的是有TCode的新增/刪除。這種改動﹐一般是從Menu開始﹐當Menu改變?nèi)魏胃淖儵o系統(tǒng)都會偵測到﹐Authorization和User會變成紅燈。 在Authorization頁簽里有兩個按鈕﹐他們有什么不同呢﹖Role的修改 對Role的修改最常見的是有TCode的新Role的修改我們先點擊﹐會出現(xiàn)一個小窗口﹐里面是三個選項﹐他們的意義是不同的。第一項﹕刪除此Role的Profile后重建第二項﹕編輯原有的Profile第三項﹕讀取原有Profile并根據(jù)Menu的變化對Profile進行更改Role的修改我們先點擊﹐會出現(xiàn)一個小窗口﹐里面Role的修改第一項會把Profile整個重建﹐并且會把已經(jīng)被屏蔽掉或刪除的Object重新顯示出來﹐極容易造成權(quán)限設(shè)定錯誤﹐反對使用。第二項完全保留之前可用的Profile﹐即使新的權(quán)限沒設(shè)好﹐還有原有的權(quán)限可用。推薦使用。缺點是Object的變更需要手動進行。第三項重新讀取Role的Menu﹐按菜單的變化變更Object﹐具有一定的智能﹐但會把已經(jīng)Merge的Item彈開﹐造成設(shè)定者的混亂。不反對使用。Role的修改第一項會把Profile整個重建﹐并且會把已經(jīng)Role的修改

這個按鈕相當與前面所說的第三項。 由于已經(jīng)包含這個選擇﹐而且第三項不是最優(yōu)選擇﹐所以我們一般不建議使用它?？偟膩碚f﹐我們認為選的第二項比較穩(wěn)當﹐保留原有的可用設(shè)定?？梢钥吹阶兓暗腜rofile。詳細細節(jié)請繼續(xù)看后面的章節(jié)。Role的修改 這個按鈕相當與前面所說的第三項。Role的修改—Merge

當Role所包含的TCode經(jīng)過多次修改后﹐可能產(chǎn)生多個同樣的Object﹐其Value可能互相包含。 這時可以通過Merge（合并）的動作使同一個Object內(nèi)Value相同或者互相包含的Item合并起來﹐使權(quán)限的條目更清晰Role的修改—Merge 當Role所包含的TCode經(jīng)Role的修改—Merge紅框框住的兩個Object,是同樣的Object,而且其Value又是第一個包含第二個。Role的修改—Merge紅框框住的兩個Object,是同樣Role的修改—Merge上頁紅框里的兩項被合并了。選擇菜單Utilities里的MergeRole的修改—Merge上頁紅框里的兩項被合并了。選擇菜單Role的修改—Merge的規(guī)則我們來看一個簡單的Object﹐它只有兩項﹕Activity和下面的Group。 我稱Acitivity為“動作”﹐它下面的Group等項目為“參數(shù)”。Merge的規(guī)則﹕當兩個相同Object的Item的動作或參數(shù)完全一致時﹐這兩個Item可以Merge。Role的修改—Merge的規(guī)則我們來看一個簡單的ObjecRole的修改—Merge

當一個Role經(jīng)過Merge后﹐這個Role的Object會比較精簡。但當Menu發(fā)生改變后﹐系統(tǒng)會提示菜單已經(jīng)變化﹐Authorization和User會從綠燈變成紅燈。 現(xiàn)在我來舉一個例子﹐假設(shè)新增一個TCode:FSS0。Role的修改—Merge 當一個Role經(jīng)過Merge后﹐Role的修改—Merge這時﹐如果我們選擇的第二項﹐進入Profile﹐會發(fā)現(xiàn)所有的Object都和菜單沒有變化前一樣。到底FSS0對Object的影響有哪一些﹐需要自己的經(jīng)驗。這里我就不詳細介紹。(如果一點都不知道﹐可以做一個測試用的Role﹐只含有這一個TCode﹐看看系統(tǒng)自動為它帶出的Object即可)Role的修改—Merge這時﹐如果我們選擇的第Role的修改—Merge如果選擇的第三項﹐進入Profile﹐我們會發(fā)現(xiàn)﹐不少Object變成了黃燈。但如果有經(jīng)驗的話﹐仔細看看﹐會發(fā)現(xiàn)有好幾個Object其實都是以前Merge過﹐現(xiàn)在給彈開或者刪除過﹐再次帶出.Role的修改—Merge如果選擇的第三項﹐進入Role的修改—Merge對于熟悉的人來說﹐這些多余的Item可以刪除就可以了﹐但也要費時間確認。對于不熟悉的人來說﹐就可能無法區(qū)分那些Object是新增TCode所需要的﹐哪些是因為不能開放而刪除的。耗費的時間可能更多。所以﹐我們不推薦這種做法。Role的修改—Merge對于熟悉的人來說﹐這些多余的IteRole的修改—新增和刪除TCode新增和刪除TCode其實在前面都有提到。在Menu頁簽的操作這里就不再重復(fù)了﹐細節(jié)請參照《Role的新建—完全新建》在Authorization頁簽的操作請參考《Role的修改》這里只重點提醒一件事。Role的修改—新增和刪除TCode新增和刪除TCodeRole的修改—新增和刪除TCode在每一個有Menu的Role里﹐必定有一個叫S_TCODE的Object﹐這個Object里記錄的是這個Role所有可以執(zhí)行的TCode。當Menu變化﹐這里也要相應(yīng)變化。但這個Object永遠是綠燈﹐所以大家一定要記得檢查這里。Role的修改—新增和刪除TCode在每一個有Menu的RRole的修改—新增和刪除TCode經(jīng)過測試﹕

在Menu新增TCode后﹐在進入Profile時選擇第二項時﹐系統(tǒng)不會在此Object自動增加TCode﹔選擇第三項﹐系統(tǒng)會自動增加TCode。

在Menu刪除TCode后﹐無論選擇第二項還是第三項﹐系統(tǒng)都不會自動刪除TCode。必須手工刪除﹗﹗

這一點請大家務(wù)必注意。Role的修改—新增和刪除TCode經(jīng)過測試﹕Role的修改—從其它Role導(dǎo)入當我們要處理的RoleA與某個RoleB的設(shè)定十分相似﹐可以通過Insert功能把RoleB的Object設(shè)定導(dǎo)入到RoleA中。請留意﹐實際上是導(dǎo)入Profile哦﹐所以一般還要去看RoleB的ProfileName﹐不是很方便。Role的修改—從其它Role導(dǎo)入當我們要處理的RoleARole的修改—從其它Role導(dǎo)入需要注意的是﹕這樣導(dǎo)入進去的Object的設(shè)定都跟RoleB的一樣﹐一定要把其中對RoleA不適用的部分更正過來。 對RoleB不熟悉不要亂用這功能哦。還是那句老話﹕欲速不達﹐不熟的事﹐沒有把握的事一定要謹慎。Role的修改—從其它Role導(dǎo)入需要注意的是﹕這樣導(dǎo)入進去Role的修改—AdjustAdjust是專門針對存在繼承關(guān)系的母子Role的一項功能。在《Role的建立》一章﹐我們學(xué)習到﹐從子Role可以通過CopyData從母Role得到ObjectValue?，F(xiàn)在﹐我們看看從母Role傳送ObjectValue到子Role的功能Adjust。Role的修改—AdjustAdjust是專門針對存在繼承關(guān)Role的修改—Adjust用Display模式進入TemplateRole的Profile﹐選擇菜單上的Generatederivedroles即可。從操作來看﹐十分簡單。注﹕不要用Change進入TemplateRole﹐否則Adjust會造成TemplateRole本身最后修改日期和最后修改人發(fā)生改變﹐對查對權(quán)限產(chǎn)生誤會Role的修改—Adjust用Display模式進入TempRole的修改—Adjust簡單比較CopyData和Adjust從子Role發(fā)出CopyData僅影響執(zhí)行此功能的子Role﹐其它繼承同一母Role的子Role不受影響同一Client下所有繼承此母Role的子Role均受影響從母Role發(fā)出AdjustRole的修改—Adjust簡單比較CopyData和Role的傳輸1.產(chǎn)生RequestNum2.Release3.TransportRole的傳輸1.產(chǎn)生RequestNumRole的傳輸—產(chǎn)生RequestNum在PFCG的開始畫面﹐可以看到。由于單個Role的傳送比大批量的傳送從操作上來說要簡單而且類似﹐所以我們重點說大批量傳送的操作。大批量的傳輸單個Role的傳輸Role的傳輸—產(chǎn)生RequestNum在PFCG的開始畫Role的傳輸—產(chǎn)生RequestNum選擇SingleRole選擇要傳輸?shù)腞oleRole的傳輸—產(chǎn)生RequestNum選擇SingleRole的傳輸—產(chǎn)生RequestNum確定要傳輸Role的傳輸—產(chǎn)生RequestNum確定要傳輸Role的傳輸—產(chǎn)生RequestNum如果這個Role第一次傳輸這里一定要打勾﹐否則傳輸?shù)狡渌點lient后會沒有Assign到UserID。但如果不是第一次傳輸請不要打勾﹐因為只要打了勾就要到目標的Client端去做一次Compare的動作﹐權(quán)限才能激活沒有起用Role的傳輸—產(chǎn)生RequestNum如果這個Role第Role的傳輸—產(chǎn)生RequestNum如果要新建一個Request﹐按如果現(xiàn)在已經(jīng)有一個還沒有Release的可用的RequestNum﹐請在這里輸入﹐然后打勾Role的傳輸—產(chǎn)生RequestNum如果要新建一個ReRole的傳輸—產(chǎn)生RequestNum簡要說明傳輸?shù)膬?nèi)容或目的Role的傳輸—產(chǎn)生RequestNum簡要說明傳輸?shù)膬?nèi)容Role的傳輸—產(chǎn)生RequestNumRequestNum產(chǎn)生,C00K開頭的都是大陸地區(qū)產(chǎn)生的﹐T00K開頭的都是臺灣地區(qū)產(chǎn)生的.Role的傳輸—產(chǎn)生RequestNumRequestNRole的傳輸—產(chǎn)生RequestNum單個Role的傳輸RequestNum產(chǎn)生的過程與打批量的相似﹐只是開始不一樣而已。單個傳輸直接KeyRole名字﹐按按鈕﹐其它操作就一樣了Role的傳輸—產(chǎn)生RequestNum單個Role的傳輸Role的傳輸—ReleaseRelease的TCode﹕SE10輸入RequestNum的產(chǎn)生者﹐選擇查看ModifiableRole的傳輸—ReleaseRelease的TCodeRole的傳輸—Release可以看到﹐其實是有兩個RequestNum的,一個記錄Header﹐一個記錄ItemRole的傳輸—Release可以看到﹐其實是有兩個RequRole的傳輸—Release先ReleaseItem的Num（在下面﹐作為子項的那一個）﹐再Header的Num方法是﹕點擊Item的Num﹐然后按按鈕﹐會進入另一個畫面﹐按﹐會回到原來的畫面﹐然后再ReleaseHeader的Num。同樣是點擊Header的Num﹐然后按﹐進入另一畫面后﹐不用存盤﹐按即可Role的傳輸—Release先ReleaseItem的NRole的傳輸—傳送這一部分是Basis的工作。本來是在Unix下進行﹐但我們開發(fā)了兩支外掛程式。從測試環(huán)境到正式環(huán)境是YATP從測試環(huán)境到QAS是YATPQA進行傳送的RequestNum必須是已經(jīng)Release的NumberRole的傳輸—傳送這一部分是Basis的工作。Role的傳輸—傳送兩者的畫面很象﹐填入RequestNum﹐選擇好目標Server﹐按就可以了Role的傳輸—傳送兩者的畫面很象﹐填入RequestNuRole的傳輸—刪除如果發(fā)現(xiàn)Role搭錯了一個RequestNum﹐在沒有Release前可以補救。同樣是在SE10,點擊Num后使用就可以了。Role的傳輸—刪除如果發(fā)現(xiàn)Role搭錯了一個RequesRole的傳輸—刪除如果已經(jīng)Release就沒有辦法刪除了﹐只能整個Number作廢﹐所謂“作廢”其實是不做最后的傳送動作﹐讓這個Number閑置而已。Role的傳輸—刪除如果已經(jīng)Release就沒有辦法刪除了﹐Role的刪除在PFCG中填好Role的名字﹐按按鈕﹐確認﹐即可把Role及其專屬Profile刪除。Role的刪除在PFCG中填好Role的名字﹐按Role的刪除請注意﹕如果需要利用傳輸功能在多個環(huán)境中刪除Role﹐一定要按以下順序進行﹕1.對Role產(chǎn)生傳輸?shù)腞equestNum﹔2.刪除本環(huán)境的Role﹔3.Release;(此時本環(huán)境中已經(jīng)沒有這個Role了）4.傳輸Role的刪除請注意﹕如果需要利用傳輸功能在多個環(huán)境中刪除R帳號刪除

帳號（UserID）的刪除操作也十分簡單﹐在SU01中﹐輸入帳號名稱﹐按就可以了帳號刪除 帳號（UserID）的刪除操作也十分簡單﹐在S帳號刪除

刪除一個帳號后﹐為其專設(shè)的Role（即Z或W開頭的）也要刪除（包括測試和正式環(huán)境）﹐減少系統(tǒng)無用的資料﹐也減少不必要的查對。 或許有人會認為﹕保留這些Role﹐雖然占用一點硬盤﹐但如果以后這個帳號再次起用﹐不就可以不用重設(shè)權(quán)限嗎﹖

這個理由咋看起來很有道理。實際上USER一旦決定刪除某個帳號﹐在相當長的時間內(nèi)都不會再起用（一個帳號的費用不菲﹐決定不會輕易下的）﹐在經(jīng)過長時間后即使需要再次起用﹐其權(quán)限需求也要重新審視﹐與其把其新需求與舊有設(shè)定一項一項對比修改﹐還不如重新設(shè)定來得方便快捷﹐而且更安全。帳號刪除 刪除一個帳號后﹐為其專設(shè)的Role（即Z或W開頭Debug/查看有一些工具對權(quán)限的問題處理很有幫助

1.SU53 2.SUIM雖然還有一些其它工具﹐但一般很少用或者不實用﹐這里就不介紹了。Debug/查看有一些工具對權(quán)限的問題處理很有幫助Debug/查看—SU53當一個帳號反映沒有某個應(yīng)有的權(quán)限時﹐我們可以在系統(tǒng)出現(xiàn)沒有權(quán)限的信息時﹐馬上輸入“/NSU53”Debug/查看—SU53當一個帳號反映沒有某個應(yīng)有的權(quán)限時Debug/查看—SU53Debug/查看—SU53Debug/查看—SU53上頁紅色框住的就是沒有權(quán)限的地方﹐而藍色框住的是跟這個帳號已經(jīng)有的權(quán)限。但是請注意﹕SU53給出的信息并不詳細﹐大部分情況只能作為一個大方向的參考﹐有時還可能指示不出來問題所在。但無論如何﹐有一個參考總比沒有好。Debug/查看—SU53上頁紅色框住的就是沒有權(quán)限的地方﹐Debug/查看—SUIMSUIM其實就是Information系統(tǒng)的一個集合界面。我們最常用的功能是﹕已知某個TCode﹐查找含有這個TCode的Role。Debug/查看—SUIMSUIM其實就是InformatiDebug/查看—SUIMDebug/查看—SUIMDebug/查看—SUIM輸入TCode后執(zhí)行﹐就可以得到含有這個Tcode的Role的列表。請注意﹕其判斷條件是Role的Menu﹐而不是ProfileDebug/查看—SUIM輸入TCode后執(zhí)行﹐就可以得到特殊的權(quán)限設(shè)定SD的權(quán)限在SD模組﹐有一個解S/OBillingBlock權(quán)限的設(shè)定﹐它是在YS08中設(shè)定特殊的權(quán)限設(shè)定SD的權(quán)限其它知識1.Object的狀態(tài)Standard/Manually/Maintained/Changed2.ObjectValueVSOrg.level其它知識1.Object的狀態(tài)Standard/Manual其它知識—Object的狀態(tài)其它知識—Object的狀態(tài)其它知識—Object的狀態(tài)當我們用第三項進入一個Profile的時候﹐我們可以看到每個Object的描述前有都有兩個狀態(tài)?，F(xiàn)在我來給大家解釋一下他們的含義。右邊的狀態(tài)共有兩種﹕NEW和OLDNEW﹕此Object有新的Item或Value,ProfileSave后會變成OLDOLD﹕此Object的Item是以前建立的其它知識—Object的狀態(tài)當我們用第三項進入一個Profi其它知識—Object的狀態(tài)左邊的狀態(tài)有好幾種﹕Standard﹕由系統(tǒng)帶出后沒有經(jīng)過任何更改Maintained﹕對系統(tǒng)初次帶出時Value為空的Item進行過變更或補充Changed﹕對系統(tǒng)初次帶出時Value為非空的Item進行過變更其它知識—Object的狀態(tài)左邊的狀態(tài)有好幾種﹕其它知識—ObjectValueVSOrg.level大家可能對ObjectValue與Org.level的關(guān)系有一些疑問﹐對Adjust時子Role到底那些地方會被母Role控制變更有點把握不住。那么下面介紹的東東對大家可能有點幫助1.Adjust大原則﹕Org.level﹕子Role有值時﹐Adjust時以子Role為準﹐ 子Role無值時﹐Adjust以母Role為準Object.Value﹕一律強制以母Role為準其它知識—ObjectValueVSOrg.level其它知識—ObjectValueVSOrg.level2.Value與Org.level

我們可以發(fā)現(xiàn)﹐在Object里有些Item的Value是與Org.level相關(guān)聯(lián)的﹐其值在沒有手工更改前都是以“$”開頭﹐這類值都是變量﹐指向?qū)?yīng)的Org.level。 當Org.level給值后﹐Object就通過這些變量把Org.level的值顯示出來﹐但實際上Object的值仍然是原來以“$”開頭的那個值。 其它知識—ObjectValueVSOrg.level其它知識—ObjectValueVSOrg.level

在子Role中﹐如果這些ObjectValue被手工更改﹐在母Role沒有做Adjust之前﹐子Role的ObjectValue是可以與Org.level不一致的﹐實際權(quán)限以O(shè)bjectValue為準。但一旦母Role做了Adjust﹐子Role的ObjectValue就強制與母Role一致。而母Role一般對這類ObjectValue的處理是保持其變量狀態(tài)﹐那么子Role的Value就變會變量狀態(tài)（$XXXX)﹐然后根據(jù)子RoleOrg.level的值顯示出新的值。其它知識—ObjectValueVSOrg.level其它知識—ObjectValueVSOrg.level3.如果不小心變更了與Org相連的Value﹐但又想恢復(fù)其變量狀態(tài)﹐怎么操作﹖

首先﹐簡單地把Value清空是不行的﹐這樣的操作只是把當前值變?yōu)镹ULL(空)﹐第二﹐把其原有的$開頭的值Key進去也是不行的﹐主要原因是輸入欄位的長度不夠。 正確操作是﹕把這個Object整個刪除﹐然后手工添加這個Object。其它知識—ObjectValueVSOrg.level請大家把自己的發(fā)現(xiàn)告訴我這個教材是我在工作之余測試編寫的﹐因為看到不少兄弟姊妹包權(quán)限的時候還有不少的疑問﹐所以希望能總結(jié)一下﹐對大家有點幫助因為時間很不夠用﹐斷斷續(xù)續(xù)寫了一個多月﹐本來有些東西想寫﹐但由于沒有時間進一步了解﹐怕寫出來誤人子弟。只好作罷。同時由于時間和精力﹐美觀方面就不做多的修飾了。(反正是內(nèi)部教材^_^)請大家把自己的發(fā)現(xiàn)告訴我這個教材是我在工作之余測試編寫的﹐因請大家把自己的發(fā)現(xiàn)告訴我這不是客套話﹕這個教材雖然是我很辛苦寫出來的﹐但可能還是有不對的地方﹐請大家發(fā)現(xiàn)后告訴我﹐我有時間的時候會修正。同時如果大家有自己的心得也請不吝賜教﹐特別是各個模組特有的權(quán)限設(shè)定﹐輔助工具的使用﹐Basis組所負責的權(quán)限部分﹐權(quán)限的傳輸?shù)确矫姗o我還有些地方了解的很不足夠﹐希望各位能告訴我。請大家把自己的發(fā)現(xiàn)告訴我這不是客套話﹕這個教材雖然是我很辛苦目錄1.總述2.職能/TemplateRole/設(shè)定的分工3.三種不同的常規(guī)權(quán)限的設(shè)定方法4.常規(guī)以外的權(quán)限設(shè)定方式5.如何快速檢查權(quán)限設(shè)定的情況目錄1.總述總述1.在開始學(xué)習之前2.SAP權(quán)限的架構(gòu)總述1.在開始學(xué)習之前在開始學(xué)習之前在開始了解權(quán)限前,有幾點是要大家注意的1.權(quán)限設(shè)定非常重要﹐而且權(quán)限的DEBUG操作非常繁瑣,耗時,所以請大家設(shè)定時一定要非常謹慎,每次更改都要記錄。2.權(quán)限設(shè)定除非特殊情況﹐不允許在正式環(huán)境直接更改﹐請在測試環(huán)境修改好再傳到正式環(huán)境。3.MIS不是決定user權(quán)限的人﹐而是user大大小小的leader﹐所以﹐要變更權(quán)限設(shè)定﹐務(wù)必要求user提供經(jīng)過簽核的申請表。（當然﹐對user不合理的權(quán)限要求﹐MIS也有責任退回）4.權(quán)限的設(shè)定,是MIS的工作.（廢話）所以﹐本教材是MIS內(nèi)部教材﹐請不要隨便泄漏在開始學(xué)習之前在開始了解權(quán)限前,有幾點是要大家注意的SAP權(quán)限的架構(gòu)Roletemplate-Description-Menu-Authorizations……………Authorizationprofile-Objectclass-Authorizationobject-Authorizations………………..AssigntoBindwithAssigntoSAPUseraccount-Address-Logondata-Group............這是SAP權(quán)限的架構(gòu)圖﹐大家也接觸過。請大家一定要記住他們的關(guān)系。SAP權(quán)限的架構(gòu)RoletemplateAuthorizaSAP權(quán)限的架構(gòu)名詞解釋（英譯中﹖）﹕Useraccount﹕就是我們平常說的“帳號”﹐也稱為“USERID”。Role﹕同類的USER使用SAP的目的和常用的功能都是類似的﹐例如業(yè)務(wù)一定需要用到開S/O的權(quán)限。當我們把某類USER需要的權(quán)限都歸到一個集合中﹐這個集合就是“職能”(Role)。 所謂的“角色”或者“職能”﹐是sap4.0才開始有的概念﹐其實就是對user的需求進行歸類﹐使權(quán)限的設(shè)定更方便。(面向?qū)ο蟮臋?quán)限!!)

分為singlerole和compositerole兩種﹐后者其實是前者的集合。SAP權(quán)限的架構(gòu)名詞解釋（英譯中﹖）﹕SAP權(quán)限的架構(gòu)Profile:真正記錄權(quán)限的設(shè)定的文件﹐從sap4.0開始是與Role綁定在一起的。雖然在sap4.6c還可以單獨存在﹐但按sap的行為推測﹐以后將不能“一個人活著”TemplateRole:Role的模板﹐一般是singlerole.但這個模板具有一個強大的功能﹐能通過更改模板而更改所有應(yīng)用(sap稱為Derive“繼承”）此模板的Role(sap稱之為adjust)SAP權(quán)限的架構(gòu)Profile:真正記錄權(quán)限的設(shè)定的文件﹐SAP權(quán)限的架構(gòu)例外權(quán)限﹕這是公司創(chuàng)造的名詞。當一個USER除了其職位一般所需的權(quán)限外﹐還需要一些特殊的權(quán)限﹐我們把這些權(quán)限稱之為這個USER的例外權(quán)限。 例如開工單對生管來說是其職能應(yīng)有的權(quán)限﹐但對倉庫來所就是例外權(quán)限。SAP權(quán)限的架構(gòu)例外權(quán)限﹕這是公司創(chuàng)造的名詞。當一個USERRole的命名和分類Role的命名規(guī)則和分類如下:以“G+”開頭都是TemplateRole(模板)﹐都不會直接assign給userid。G+職能名稱 ﹕全球共同TemplateRoleG+職能名稱-1 ﹕地區(qū)TemplateRole以“Z+”開頭都是UserRole,直接assign給userid。Z+UserID+職能名稱 :繼承全球共同TemplateRoleZ+UserID+職能名稱-1:繼承地區(qū)TemplateRoleZ+UserID+Exception :沒有繼承任何Role,例外權(quán)限以“Y+”開頭都是BasisRole,直接assign給userid。Y+職能名稱 :全球共同BasisRoleRole的命名和分類Role的命名規(guī)則和分類如下:Role的命名和分類附件是一張職能/Rolename對照表我們以其中一個職能“AR作業(yè)人員”做解釋﹕職能中文名稱職能英文名稱全球共同TemplateRole地區(qū)TemplateRole全球共同BasisRoleRole的命名和分類附件是一張職能/Rolename對照表職Role的命名和分類全球共同TemplateRole﹕是指此職能在全球任何一個地區(qū)都一致的那部分權(quán)限的模板。命名特征是以“G+”開頭﹐非“-1”結(jié)尾。 例如“G+CO–CO”地區(qū)TemplateRole﹕是指此職能根據(jù)不同地區(qū)而不同的那部分權(quán)限的模板。命名特征是“G+”開頭﹐“-1”結(jié)尾。 例如“G+CO–CO–1”Role的命名和分類全球共同TemplateRole﹕是指Role的命名和分類UserRole﹕是指根據(jù)每個user的具體需求進行設(shè)定的權(quán)限的Role.命名特征是﹕“Z+”USERID開頭（東莞﹑臺灣地區(qū)）“W+”USERID開頭（吳江地區(qū)） 例如“Z+PSC1-ACT01+CO-CO”全球共同BasisRole﹕是指此職能關(guān)系到整個系統(tǒng)的安全的那部分權(quán)限的Role.命名特征是“Y+”開頭 例如“Y+CO–CO”Role的命名和分類UserRole﹕是指根據(jù)每個user權(quán)限設(shè)定者分工一.以Role類型分1.TemplateRole

即“G”開頭的:臺北本部的APMIS2.UserRole:

以Z開頭的:東莞APMIS

以W開頭的:吳江APMIS3.BasisRole:

即以Y開頭的:臺北和東莞BasisMIS權(quán)限設(shè)定者分工一.以Role類型分權(quán)限設(shè)定者分工二.以USERID分從USERID可以區(qū)分出這個ID所屬的廠別和模組。例如﹕PSC1-ENG01這是PSC1廠的帳號﹐屬于PP模組﹐所以這個帳號申請的權(quán)限將由東莞PP模組的MIS主要負責和監(jiān)督。權(quán)限設(shè)定者分工二.以USERID分權(quán)限設(shè)定者分工三.以所申請的權(quán)限歸屬的模組分 由于user所申請的權(quán)限通常涉及多個模組﹐這就需要多個模組的MIS共同合作設(shè)定user的權(quán)限﹐這時先按第二條執(zhí)行,由ID所屬模組MIS接受申請﹐并從始至終跟進。然后具體的權(quán)限屬于哪個模組就由那個模組的MIS作設(shè)定。 但無論如何﹐作為跟進的MIS都是負主要責任的。權(quán)限設(shè)定者分工三.以所申請的權(quán)限歸屬的模組分權(quán)限設(shè)定的操作

上面說過﹐權(quán)限的大架構(gòu)由UserID,Role,Profile三層組成﹐那么﹐權(quán)限的設(shè)定自然也會有三層。但由于sap4.6是Profile與Role是捆綁在一起的﹐所以在建立Role的時候﹐Profile是會自動創(chuàng)建的（具體見后文）。而UserID的建立比較簡單。所以﹐我將主要說明Role的部分。權(quán)限設(shè)定的操作 上面說過﹐權(quán)限的大架構(gòu)由UserID,USERID的建立TCODE﹕SU01單擊建立圖標2輸入要創(chuàng)建的UserID1USERID的建立TCODE﹕SU01單擊建立USERID的建立填好這些欄位USERID的建立填好這些欄位USERID的建立設(shè)定組別﹐這對MIS非常重要﹐MIS能否管理此UserID就看這里設(shè)定初始密碼有效期一般不設(shè)定USERID的建立設(shè)定組別﹐這對MIS非常重要﹐MIS能USERID的建立按圖設(shè)定（印表機按實際設(shè)定）USERID的建立按圖設(shè)定（印表機按實際設(shè)定）USERID的建立接著按save﹐就把USERID創(chuàng)建好了 USERID創(chuàng)建好了﹐但這時這個ID沒有賦予(Assign)任何權(quán)限﹐是什么都不能做的。USER得到這樣的帳號沒有任何意義。 如何Assign權(quán)限給一個帳號﹖主要就是Assign一個Role給這個帳號了。下面我們看看如何建Role和給權(quán)限。USERID的建立接著按save﹐就把USERID創(chuàng)建Role的建立新創(chuàng)建Role主要有三種方式。TCODE﹕PFCG1.由始至終新建;

可以對應(yīng)所有新建Role。主要對應(yīng)例外權(quán)限Z+USERID+EXCEPTION2.繼承;

主要對應(yīng)設(shè)定Z+USERID+職能名稱3.復(fù)制（COPY）﹔

主要對應(yīng)設(shè)定Z+USERID+職能名稱-1Role的建立新創(chuàng)建Role主要有三種方式。TCODE﹕Role的建立—完全新建

我們假設(shè)有一個帳號“FORTEST”,他申請了例外權(quán)限VA01和YF30。 下面我將會一步一步向大家說明操作的步驟和應(yīng)該注意的地方。 看到PFCG的畫面了嗎﹖沒有﹖

哦﹐在下一頁。Role的建立—完全新建 我們假設(shè)有一個帳號“FORTERole的建立—完全新建輸入Rolename注意選第二項Role的建立—完全新建輸入Rolename注意選第二項Role的建立—完全新建描述一般與Rolename一致記錄此Role的創(chuàng)建者記錄此Role的最后修改者把描述填好后﹐按save然后點擊menu頁簽Role的建立—完全新建描述一般與Rolename一致記錄Role的建立—完全新建建立新目錄修改TEXT項目下移項目上移刪除項目手動增加Tcode從SAPMenu中增加Tcode從其他Role中CopyMenu這些是常用的功能Menu頁簽定義的是USERMENU（個人化菜單）的內(nèi)容。Role的建立—完全新建建立新目錄修改TEXT項目下移項目上Role的建立—完全新建請大家按圖所示建立目錄﹐第一層是職能﹐這里是EXCEPTION﹐下面分“標準”(Standark)和“外掛”(AddOn)兩個目錄。讓菜單保持清晰﹐可以令User的個人菜單清楚﹐不混亂。我們MIS檢查權(quán)限也比較方便。Role的建立—完全新建請大家按圖所示建立目錄﹐第一層是職Role的建立—完全新建大家可以對比下面兩個USER的個人化菜單﹐左邊職能清晰﹐右邊非?；靵y﹐同名的目錄大量出現(xiàn)﹐但里面的內(nèi)容又不盡相同﹐這對依賴路徑執(zhí)行指令的user是很麻煩的。Role的建立—完全新建大家可以對比下面兩個USER的個人化Role的建立—完全新建菜單的殼子有了﹐如何往里面添加內(nèi)容呢﹖比較常見的是﹕從SAP菜單添加和直接添加TCODE。從SAP菜單添加﹕所有標準的TCODE和沒有TCODE的標準程式都可以用這種方法添加。好處是可以尋找﹐可以一次添加標準菜單的一個目錄﹐Tcode在標準菜單中的位置也可以顯示出來。缺點是很浪費時間﹐而且外掛的程式無法添加。Role的建立—完全新建菜單的殼子有了﹐如何往里面添加內(nèi)容呢Role的建立—完全新建直接添加﹕所有TCODE(包括外掛）和沒有TCODE的標準程式都可以用這種方法添加。好處是比較快缺點是必須知道Tcode﹐不能帶出路徑。Role的建立—完全新建直接添加﹕Role的建立—完全新建從SAP菜單添加Role的建立—完全新建從SAP菜單添加Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建Role的建立—完全新建OBJECT完全沒有給值OBJECT只有部分給值OBJECT已經(jīng)全部有值請注意﹕綠燈只是表示全部有值而已﹐但不一定就是我們所需要的值這時﹐標準Tcode所需要的Object﹐系統(tǒng)會自動帶出來。Role的建立—完全新建OBJECT完全沒有給值OBJECTRole的建立—完全新建這個Object是任何權(quán)限設(shè)定文件中都應(yīng)該有的﹐這是給予啟動Tcode的權(quán)限﹐如果Tcode沒有出現(xiàn)在這個列表中﹐user連這個指令的畫面都無法進入Role的建立—完全新建這個Object是任何權(quán)限設(shè)定文件中Role的建立—完全新建在這里﹐需要向大家介紹一個很重要的概念﹕Org.level.在權(quán)限設(shè)定中﹐有許多地方的控制點是一致的﹐sap公司為了方便權(quán)限的設(shè)定﹐把這些地方設(shè)計為與全局變數(shù)關(guān)聯(lián)。當改變?nèi)肿償?shù)時﹐這些地方就可以全部改變過來。這個全局的變數(shù)就是﹕Org.levelRole的建立—完全新建在這里﹐需要向大家介紹一個很重要的概Role的建立—完全新建當Org.Level給值后﹐相應(yīng)的Objectvalue的值也變了Role的建立—完全新建當Org.Level給值后﹐相應(yīng)的ORole的建立—完全新建

對Org.Level都給值之后﹐會發(fā)現(xiàn)相當一部分的Objectvalue都已經(jīng)給值了﹐但還有一些Object是紅燈或者是黃燈﹐這些Object是要單獨給值的。Role的建立—完全新建 對Org.Level都給值之后﹐會Role的建立—完全新建

按一下標志﹐就可以輸入值﹐按保存 在這里介紹一下的作用﹐點擊它﹐就相當於給這個Object一個“*”(star)﹐“*”的意義是AllAuthorization﹐不卡任何權(quán)限。Object給值后﹐就變成綠色﹐不能點擊了。Role的建立—完全新建 按一下標志﹐就可以輸入Role的建立—完全新建

如果是外掛的Tcode﹐就只能用“直接添加”的方式加入到菜單中﹐需要注意的是﹐外掛的Tcode的Object不會自動帶出來﹐需要自己手工添加。 按﹐點擊Y-AUTH-PRT前的Role的建立—完全新建 如果是外掛的Tcode﹐就只能Role的建立—完全新建變?yōu)楹螬o按屏幕上方的﹐插入Object.注意﹕外掛的Tcode﹐除了前面所說的列表中要有外﹐這里框住的地方要給Tcode﹐否則user還是不會有權(quán)限Role的建立—完全新建變?yōu)楹螬o按屏幕上方的Role的建立—完全新建都給好值后﹐按保存﹐按“勾”。然后按激活。退出。Role的建立—完全新建都給好值后﹐按保存﹐按Role的建立—完全新建Authorization已經(jīng)變成綠燈﹐這表示權(quán)限的設(shè)定已經(jīng)可用了。點擊USER,AssignUSERID給這個RoleRole的建立—完全新建Authorization已經(jīng)變成綠Role的建立—完全新建點擊USERCOMPARE﹐再點擊Completecompare﹐就完成了COMPARE。至此﹐此權(quán)限已經(jīng)Assign完畢﹐FORTEST這個帳號已經(jīng)具有VA01和YF30的權(quán)限Role的建立—完全新建點擊USERCOMPARE﹐Role的建立—繼承

所謂“繼承”,是指兩個Role形成這樣的母子關(guān)系﹕子Role的所有Menu,Authorization（Org.level除外)都源于母Role,并與母Role保持一致。 母Role與子Role是

1對多的。Role的建立—繼承 所謂“繼承”,是指兩個Role形成這Role的建立—繼承下面﹐我們來學(xué)習用“繼承”方式建立Role.我們假設(shè)有一個帳號“FORTEST”,他申請了職能“AP立帳員”﹐“AP立帳員”的TemplateRole是“G+CO-AP”。我們先來按命名規(guī)則Create一個新Role。Role的建立—繼承下面﹐我們來學(xué)習用“繼承”方式建立RolRole的建立—繼承大家注意這個地方﹐建立“繼承”關(guān)系就是靠這里了Role的建立—繼承大家注意這個地方﹐建立“繼承”關(guān)系就是靠Role的建立—繼承填入TemplateRole,按Enter.是否建立繼承關(guān)系﹖回答當然是“YES”了﹐否則我們怎樣上課﹖如果在此前沒有做過存檔﹐系統(tǒng)會詢問是否存檔﹐回答同樣是“YES”Role的建立—繼承填入TemplateRole,按EntRole的建立—繼承可以看到﹐菜單已經(jīng)自動根據(jù)TemplateRole生成了,點擊Authorization頁簽﹐設(shè)定權(quán)限去。Role的建立—繼承可以看到﹐菜單已經(jīng)自動根據(jù)TemplatRole的建立—繼承進入Profile里面了﹐請注意下面所說的操作﹐如果做錯了﹐可能要拉倒從新開始的喲。點擊這個按鈕1.系統(tǒng)會自動進入Org.level﹐請點擊“X”,退出Org.level。2.按“SAVE”對Profile存檔。Role的建立—繼承進入Profile里面了﹐請注意下面所說Role的建立—繼承3.執(zhí)行菜單Edit中的Copydata,系統(tǒng)會提示這個操作不可反轉(zhuǎn)。按“勾”繼續(xù),執(zhí)行完畢后我們會看到﹐許多Object已經(jīng)變成綠燈了。Role的建立—繼承3.執(zhí)行菜單Edit中的CopydatRole的建立—繼承現(xiàn)在可以維護Org.level的設(shè)定了。進入的方法如上。當Org.level每一個欄位都賦值之后﹐應(yīng)該每一個Object都是綠燈﹐如果還有紅黃燈﹐請通知臺北修正。Role的建立—繼承現(xiàn)在可以維護Org.level的設(shè)定了。Role的建立—繼承

當所有權(quán)限（其