SAP 權限的設定 QiQi V 張穎祺 內部教材 CONFIDENTIAL

目錄 1.總述 2.職能/Template Role/設定的分工 3.三種不同的常規權限的設定方法 4.常規以外的權限設定方式 5.如何快速檢查權限設定的情況

總述 1.在開始學習之前 2.SAP權限的架構

在開始學習之前 在開始了解權限前,有几點是要大家注意的 1.權限設定非常重要﹐而且權限的DEBUG操作非常繁瑣,耗時,所以請大家設定時一定要非常謹慎,每次更改都要記錄。 2.權限設定除非特殊情況﹐不允許在正式環境直接更改﹐請在測試環境修改好再傳到正式環境。 3.MIS不是決定user權限的人﹐而是user大大小小的leader﹐所以﹐要變更權限設定﹐務必要求user提供經過簽核的申請表。（當然﹐對user不合理的權限要求﹐MIS也有責任退回） 4.權限的設定,是MIS的工作.（廢話）所以﹐本教材是MIS內部教材﹐請不要隨便泄漏

SAP權限的架構 SAP User account -Address -Logon data -Group . . . . . . . . . . . . Role template -Description -Menu -Authorizations …………… Assign to Assign to Bind with 這是SAP權限的架構圖﹐大家也接觸過。 請大家一定要記住他們的關系。 Authorization profile -Object class -Authorization object -Authorizations ………………..

SAP權限的架構 名詞解釋（英譯中﹖）﹕ User account﹕就是我們平常說的“帳號”﹐也稱為“USER ID”。 Role﹕同類的USER使用SAP的目的和常用的功能都是類似的﹐例如業務一定需要用到開S/O的權限。當我們把某類USER需要的權限都歸到一個集合中﹐這個集合就是“職能”(Role)。 所謂的“角色”或者“職能”﹐是sap4.0才開始有的概念﹐其實就是對user的需求進行歸類﹐使權限的設定更方便。(面向對象的權限!!) 分為single role 和 composite role兩種﹐后者其實是前者的集合。

SAP權限的架構 Profile: 真正記錄權限的設定的文件﹐從sap4.0開始是與Role綁定在一起的。雖然在sap4.6c還可以單獨存在﹐但按sap的行為推測﹐以后將不能“一個人活着” Template Role:Role的模板﹐一般是single role.但這個模板具有一個 強大的功能﹐能通過更改模板而更改所有應用(sap稱為Derive“繼承”）此模板的Role(sap稱之為adjust)

SAP權限的架構 例外權限﹕這是公司創造的名詞。當一個USER除了其職位一般所需的權限外﹐還需要一些特殊的權限﹐我們把這些權限稱之為這個USER的例外權限。 例如開工單對生管來說是其職能應有的權限﹐但對倉庫來所就是例外權限。

Role的命名和分類 Role的命名規則和分類如下: 以“G+”開頭都是Template Role(模板)﹐都不會直接assign給user id。 G+職能名稱 ﹕全球共同Template Role G+職能名稱-1 ﹕地區Template Role 以“Z+”開頭都是User Role,直接assign給user id。 Z+User ID+職能名稱 :繼承全球共同Template Role Z+User ID+職能名稱-1:繼承地區Template Role Z+User ID+Exception :沒有繼承任何Role,例外權限 以“Y+”開頭都是Basis Role,直接assign給user id。 Y+職能名稱 :全球共同Basis Role

Role的命名和分類 附件是一張職能/Rolename對照表 我們以其中一個職能“AR作業人員”做解釋﹕ 職能中文名稱 職能英文名稱 全球共同Template Role 地區Template Role 全球共同Basis Role

Role的命名和分類 全球共同Template Role﹕是指此職能在全球任何一個地區都一致的那部分權限的模板。 命名特征是以 “G +”開頭﹐非“-1”結尾。 例如 “G + CO – CO ” 地區Template Role﹕是指此職能根據不同地區而不同的那部分權限的模板。 命名特征是 “G+”開頭﹐“-1”結尾。 例如 “G + CO – CO – 1 ”

Role的命名和分類 User Role﹕是指根據每個user的具體需求進行設定的權限的Role. 命名特征是﹕ “Z+”USER ID開頭（東莞﹑台灣地區） “W+” USER ID開頭（吳江地區） 例如“Z+PSC1-ACT01+CO-CO” 全球共同Basis Role﹕是指此職能關系到整個系統的安全的那部分權限的Role. 命名特征是 “Y+” 開頭 例如 “ Y + CO – CO ”

權限設定者分工 一.以Role類型分 1.Template Role 即“G”開頭的: 台北本部的AP MIS 2.User Role: 以Z開頭的:東莞AP MIS 以W開頭的:吳江AP MIS 3.Basis Role: 即以Y開頭的:台北和東莞Basis MIS

權限設定者分工 二.以USER ID分 從USER ID可以區分出這個ID所屬的廠別和模組。 例如﹕PSC1-ENG01這是PSC1廠的帳號﹐屬于PP模組﹐所以這個帳號申請的權限將由東莞PP模組的MIS主要負責和監督。

權限設定者分工 三.以所申請的權限歸屬的模組分 由于user所申請的權限通常涉及多個模組﹐這就需要多個模組的MIS共同合作設定user的權限﹐這時先按第二條執行,由ID所屬模組MIS接受申請﹐并從始至終跟進。然后具體的權限屬于哪個模組就由那個模組的MIS作設定。 但無論如何﹐作為跟進的MIS都是負主要責任的。

權限設定的操作 上面說過﹐權限的大架構由User ID, Role, Profile 三層組成﹐那么﹐權限的設定自然也會有三層。但由于sap4.6是Profile與Role是捆綁在一起的﹐所以在建立Role的時候﹐Profile是會自動創建的（具體見后文）。而User ID的建立比較簡單。所以﹐我將主要說明Role的部分。

USER ID 的建立 T CODE ﹕ SU01 輸入要創建的User ID 1 單擊建立圖標 2

USER ID 的建立 填好這些欄位

設定組別﹐這對MIS非常重要﹐MIS能否管理此User ID就看這里 設定初始密碼 設定組別﹐這對MIS非常重要﹐MIS能否管理此User ID就看這里 有效期一般不設定

USER ID 的建立 按圖設定（印表機按實際設定）

接著按save﹐就把USER ID創建好了 USER ID創建好了﹐但這時這個ID沒有賦予(Assign) 任何權限﹐是什么都不能做的。USER得到這樣的帳號沒有任何意義。 如何 Assign權限給一個帳號﹖主要就是Assign一個 Role 給這個帳號了。下面我們看看如何建Role和給權限。

Role的建立 新創建Role主要有三種方式。T CODE ﹕PFCG 1.由始至終新建; 可以對應所有新建Role。主要對應例外權限Z+USERID+EXCEPTION 2.繼承; 主要對應設定Z+USERID+職能名稱 3.復制（COPY）﹔ 主要對應設定Z+USERID+職能名稱-1

Role的建立—完全新建 我們假設有一個帳號 “FORTEST”,他申請了例外權限 VA01和YF30。 下面我將會一步一步向大家說明操作的步驟和應該注意的地方。 看到PFCG的畫面了嗎﹖沒有﹖ 哦﹐在下一頁。

Role的建立—完全新建 輸入Role name 注意選第二項

Role的建立—完全新建 記錄此Role的創建者 記錄此Role的最后修改者 把描述填好后﹐按save 然后點擊menu頁簽 描述一般與Role name一致 記錄此Role的創建者 記錄此Role的最后修改者 把描述填好后﹐按save 然后點擊menu頁簽

Menu頁簽定義的是USER MENU（個人化菜單）的內容。 Role的建立—完全新建 Menu頁簽定義的是USER MENU（個人化菜單）的內容。 建立新目錄 這些是常用的功能 修改TEXT 項目下移 項目上移 刪除項目 手動增加T code 從SAPMenu中增加T code 從其他Role中Copy Menu

Role的建立—完全新建 請大家按圖所示建立目錄 ﹐第一層是職能﹐這里是EXCEPTION﹐下面分“標准”(Standark)和 “外挂” (Add On) 兩個目錄 。 讓菜單保持清晰﹐可以令User的個人菜單清楚﹐不混亂。 我們MIS檢查權限也比較方便。

Role的建立—完全新建 大家可以對比下面兩個USER的個人化菜單﹐左邊職能清晰﹐右邊非常混亂﹐同名的目錄 大量出現﹐但里面的內容又不盡相同﹐這對依賴路徑執行指令的user是很麻煩的。

Role的建立—完全新建 菜單的殼子有了﹐如何往里面添加內容呢﹖ 比較常見的是﹕從SAP菜單添加和直接添加T CODE。 從SAP菜單添加﹕ 所有標准的T CODE和沒有T CODE的標準程式都可以用這種方法添加。好處是可以尋找﹐可以一次添加標准菜單的一個目錄﹐T code在標准菜單中的位置也可以顯示出來。缺點是很浪費時間﹐而且外挂的程式無法添加。

Role的建立—完全新建 直接添加﹕ 所有T CODE(包括外挂）和沒有T CODE的標準程式都可以用這種方法添加。好處是比較快

Role的建立—完全新建 從SAP菜單添加

Role的建立—完全新建

Role的建立—完全新建

Role的建立—完全新建

Role的建立—完全新建 這時﹐標准T code所需要的Object﹐系統會自動帶出來。 OBJECT完全沒有給值 請注意﹕綠燈只是表示全部有值而已﹐但不一定就是我們所需要的值 OBJECT只有部分給值 OBJECT已經全部有值

Role的建立—完全新建 這個Object是任何權限設定文件中都應該有的﹐這是給予啟動T code的權限﹐如果T code沒有出現在這個列表中﹐user連這個指令的畫面都無法進入

在這里﹐需要向大家介紹一個很重要的概念﹕Org.level. Role的建立—完全新建 在這里﹐需要向大家介紹一個很重要的概念﹕Org.level. 在權限設定中﹐有許多地方的控制點是一致的﹐sap公司為了方便權限的設定﹐把這些地方設計為與全局變數關聯。當改變全局變數時﹐這些地方就可以全部改變過來。 這個全局的變數就是﹕Org.level

當Org.Level給值后﹐相應的Object value的值也變了 Role的建立—完全新建 當Org.Level給值后﹐相應的Object value的值也變了

Role的建立—完全新建 對Org.Level都給值之后﹐會發現相當一部分的Object value都已經給值了﹐但還有一些Object是紅燈或者是黃燈﹐這些Object是要單獨給值的。

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

Role的建立—完全新建 如果是外挂的T code﹐就只能用“直接添加”的方式加入到菜單中﹐需要注意的是﹐外挂的T code的Object不會自動帶出來﹐需要自己手工添加。 按 ﹐點擊Y-AUTH-PRT前的

Role的建立—完全新建 變為 后﹐按屏幕上方的 ﹐插入Object. 注意﹕外挂的T code﹐除了前面所說的列表中要有外﹐這里框住的地方要給T code﹐否則user還是不會有權限

Role的建立—完全新建 都給好值后﹐按 保存﹐按“勾”。 然后按 激活。退出。

Role的建立—完全新建 Authorization已經變成綠燈﹐這表示權限的設定已經可用了。 點擊USER,Assign USER ID 給這個Role

至此﹐此權限已經Assign完畢﹐FORTEST這個帳號已經具有VA01和YF30的權限 Role的建立—完全新建 點擊 USER COMPARE ﹐ 再點擊Complete compare﹐ 就完成了COMPARE。 至此﹐此權限已經Assign完畢﹐FORTEST這個帳號已經具有VA01和YF30的權限

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

Role的建立—繼承 下面﹐我們來學習用“繼承”方式建立Role. 我們假設有一個帳號 “FORTEST”,他申請了職能 “AP立帳員”﹐“AP立帳員”的Template Role 是 “G+CO-AP”。 我們先來按命名規則Create一個新Role。

大家注意這個地方﹐建立“繼承”關系就是靠這里了 Role的建立—繼承 大家注意這個地方﹐建立“繼承”關系就是靠這里了

Role的建立—繼承 填入Template Role,按Enter. 如果在此前沒有做過存檔﹐系統會詢問是否存檔﹐回答同樣是“YES” 是否建立繼承關系﹖ 回答當然是“YES”了﹐否則我們怎樣上課﹖

可以看到﹐菜單已經自動根據Template Role生成了,點擊Authorization 頁簽﹐設定權限去。

Role的建立—繼承 進入Profile里面了﹐請注意下面所說的操作﹐如果做錯了﹐可能要拉倒從新開始的喲。 點擊這個按鈕 進入Profile里面了﹐請注意下面所說的操作﹐如果做錯了﹐可能要拉倒從新開始的喲。 1.系統會自動進入Org.level﹐請點擊“X”,退出Org.level。 2.按“SAVE”對Profile存檔。

Role的建立—繼承 3.執行菜單Edit中的Copy data,系統會提示這個操作不可反轉。按“勾”繼續 ,執行完畢后我們會看到﹐許多Object 已經變成綠燈了。

Role的建立—繼承 現在可以維護Org.level的設定了。進入的方法如上。 當Org.level每一個欄位都賦值之后﹐應該每一個Object都是綠燈﹐如果還有紅黃燈﹐請通知台北修正。

Role的建立—繼承 當所有權限（其實只是設定Org.level)都設定完畢后﹐按 激活設定﹐Assign給USER ID,就完成了。

Role的建立—繼承 大家是否覺得“繼承”的方法好簡單﹐几下就做完了。其實這種方法思路最復雜了﹐后面的處理還隱藏不少陷阱。 那么﹐我們來看看第三種方法—復制。

Role的建立—復制 復制其實是一種從思想到操作都很簡單的操作。 它的核心就是—……復制! (雞蛋和番茄飛了起來……） 我們來看看如何操作吧。 先告訴大家﹕“AP立帳員”的Template Role 還有一個﹐是 “G+CO-AP-1”﹐我們就用它來學習。

一開始當然是進入PFCG了﹐先把Template Role名輸進去﹐然后按COPY按鈕

Role的建立—復制

Role的建立—復制 把描述改成與Role名一樣 這里是空的 要注意“-1”的Role的menu是空的

紅色框住的都是要填入值的地方﹐最好先填完Org.level Role的建立—復制 紅色框住的都是要填入值的地方﹐最好先填完Org.level

Role的建立—復制 與其它方式建立的Role一樣,當所有權限都設定完畢后﹐按 激活設定﹐Assign給USER ID﹐一個Role就設定完成了

Role的建立—繼承與復制 小結﹕ 非“-1”的那種Template Role ﹐用繼承的方式建立新Role,繼承后﹐只需要填入Org.level﹐Object就全部是綠燈了﹐ 而“-1”的那種是用復制的方式﹐還需要在Object里填入值﹐才能全部綠燈。 這是兩者操作上的最大特點。

Role的修改 1.Merge 2.新增/刪除T Code 3.從其它Role導入 4.Adjust

Role的修改 對Role的修改最常見的是有T Code的新增/刪除。這種改動﹐一般是從Menu開始﹐當Menu改變任何改變﹐系統都會偵測到﹐Authorization和User會變成紅燈。 在Authorization頁簽里有兩個按鈕﹐他們有什么不同呢﹖

Role的修改 我們先點擊 ﹐會出現一個小窗口﹐里面是三個選項﹐他們的意義是不同的。 第一項﹕刪除此Role的Profile后重建 我們先點擊 ﹐會出現一個小窗口﹐里面是三個選項﹐他們的意義是不同的。 第一項﹕刪除此Role的Profile后重建 第二項﹕編輯原有的Profile 第三項﹕讀取原有Profile并根據Menu的變化對Profile進行更改

Role的修改 第一項會把Profile整個重建﹐并且會把已經被屏蔽掉或刪除的Object重新顯示出來﹐極容易造成權限設定錯誤﹐反對使用。 第三項重新讀取Role的Menu﹐按菜單的變化變更Object﹐具有一定的智能﹐但會把已經Merge的Item彈開﹐造成設定者的混亂。不反對使用。

Role的修改 這個按鈕相當與前面所說的第三項。 由于 已經包含這個選擇﹐而且第三項不是最優選擇﹐所以我們一般不建議使用它。 由于 已經包含這個選擇﹐而且第三項不是最優選擇﹐所以我們一般不建議使用它。 總的來說﹐我們認為選 的第二項比較穩當﹐保留原有的可用設定。可以看到變化前的Profile。詳細細節請繼續看后面的章節。

Role的修改—Merge 當Role所包含的T Code經過多次修改后﹐可能產生多個同樣的Object﹐其Value可能互相包含。 這時可以通過Merge（合并）的動作使同一個Object內Value相同或者互相包含的Item合并起來﹐使權限的條目更清晰

Role的修改—Merge 紅框框住的兩個Object,是同樣的Object,而且其Value又是第一個包含第二個。

選擇菜單Utilities里的Merge Role的修改—Merge 選擇菜單Utilities里的Merge 上頁紅框里的兩項被合并了。

Role的修改—Merge的規則 我們來看一個簡單的Object﹐它只有兩項﹕Activity和下面的Group。 我稱Acitivity為“動作”﹐它下面的Group等項目為“參數”。 Merge的規則﹕當兩個相同Object的Item的動作或參數完全一致時﹐這兩個Item可以Merge。

Role的修改—Merge 當一個Role經過Merge后﹐這個Role的Object 會比較精簡。但當Menu發生改變后﹐系統會提示菜單已經變化﹐Authorization和User會從綠燈變成紅燈。 現在我來舉一個例子﹐假設新增一個T Code : FSS0。

Role的修改—Merge 這時﹐如果我們選擇 的第二項﹐進入Profile﹐會發現所有的Object都和菜單沒有變化前一樣。 到底FSS0對Object的影響有哪一些﹐需要自己的經驗。這里我就不詳細介紹。(如果一點都不知道﹐可以做一個測試用的Role﹐只含有這一個T Code﹐看看系統自動為它帶出的Object即可)

Role的修改—Merge 如果選擇 的第三項﹐進入Profile﹐我們會發現﹐不少Object變成了黃燈。 但如果有經驗的話﹐仔細看看﹐會發現有好几個Object其實都是以前Merge過﹐現在給彈開或者刪除過﹐再次帶出.

Role的修改—Merge 對于熟悉的人來說﹐這些多余的Item可以刪除就可以了﹐但也要費時間確認。對于不熟悉的人來說﹐就可能無法區分那些Object是新增T Code所需要的﹐哪些是因為不能開放而刪除的。耗費的時間可能更多。 所以﹐我們不推荐這種做法。

Role的修改—新增和刪除T Code 新增和刪除T Code其實在前面都有提到。 在Menu頁簽的操作這里就不再重復了﹐細節請參照《Role的新建—完全新建》 在Authorization頁簽的操作請參考《Role的修改》 這里只重點提醒一件事。

Role的修改—新增和刪除T Code 在每一個有Menu的Role里﹐必定有一個叫S_TCODE的Object﹐這個Object里記錄的是這個Role所有可以執行的T Code。當Menu變化﹐這里也要相應變化。 但這個Object永遠是綠燈﹐所以大家一定要記得檢查這里。

Role的修改—新增和刪除T Code 經過測試﹕ 在Menu新增T Code后﹐在進入Profile時選擇第二項時﹐系統不會在此Object自動增加T Code﹔選擇第三項﹐系統會自動增加T Code。 在Menu刪除T Code后﹐無論選擇第二項還是第三項﹐系統都不會自動刪除T Code。必須手工刪除﹗﹗ 這一點請大家務必注意。

Role的修改—從其它Role導入 當我們要處理的Role A與某個Role B的設定十分相似﹐可以通過Insert功能把Role B的Object設定導入到Role A中。 請留意﹐實際上是導入Profile哦﹐所以一般還要去看Role B的Profile Name﹐不是很方便。

Role的修改—從其它Role導入 需要注意的是﹕這樣導入進去的Object的設定都跟Role B的一樣﹐一定要把其中對Role A不適用的部分更正過來。 對Role B不熟悉不要亂用這功能哦。 還是那句老話﹕欲速不達﹐不熟的事﹐沒有把握的事一定要謹慎。

Role的修改—Adjust Adjust是專門針對存在繼承關系的母子Role的一項功能。 在《Role的建立》一章﹐我們學習到﹐從子Role可以通過Copy Data從母Role得到Object Value。 現在﹐我們看看從母Role傳送Object Value到子Role的功能Adjust。

Role的修改—Adjust 用Display模式進入Template Role的Profile﹐選擇菜單上的Generate derived roles即可。從操作來看﹐十分簡單。 注﹕不要用Change進入Template Role﹐否則Adjust會造成Template Role本身最后修改日期和最后修改人發生改變﹐對查對權限產生誤會

Role的修改—Adjust 簡單比較Copy Data 和 Adjust 從子Role發出 Copy Data 僅影響執行此功能的子Role﹐其它繼承同一母Role的子Role不受影響 同一Client下所有繼承此母Role的子Role均受影響 從母Role發出 Adjust

Role的傳輸 1.產生Request Num 2.Release 3.Transport

Role的傳輸—產生Request Num 大批量的傳輸 在PFCG的開始畫面﹐可以看到。 由于單個Role的傳送比大批量的傳送從操作上來說要簡單而且類似﹐所以我們重點說大批量傳送的操作。

Role的傳輸—產生Request Num 選擇Single Role 選擇要傳輸的Role

Role的傳輸—產生Request Num 確定要傳輸

Role的傳輸—產生Request Num 如果這個Role第一次傳輸這里一定要打勾﹐否則傳輸到其它client后會沒有Assign到User ID。 但如果不是第一次傳輸請不要打勾﹐因為只要打了勾就要到目標的Client端去做一次Compare的動作﹐權限才能激活 沒有起用

Role的傳輸—產生Request Num 如果現在已經有一個還沒有Release的可用的Request Num﹐請在這里輸入﹐然后打勾 如果要新建一個Request﹐按

Role的傳輸—產生Request Num 簡要說明傳輸的內容或目的

Role的傳輸—產生Request Num Request Num產生, C00K開頭的都是大陸地區產生的﹐T00K開頭的都是台灣地區產生的.

Role的傳輸—產生Request Num 單個傳輸直接Key Role名字﹐按 按鈕﹐其它操作就一樣了

輸入Request Num的產生者﹐選擇查看Modifiable Role的傳輸—Release Release的 T Code ﹕SE10 輸入Request Num的產生者﹐選擇查看Modifiable

可以看到﹐其實是有兩個Request Num的,一個記錄Header﹐一個記錄Item Role的傳輸—Release 可以看到﹐其實是有兩個Request Num的,一個記錄Header﹐一個記錄Item

Role的傳輸—Release 先Release Item的Num（在下面﹐作為子項的那一個）﹐再Header的Num 方法是﹕點擊Item的Num﹐然后按 按鈕﹐會進入另一個畫面﹐按 ﹐會回到原來的畫面﹐然后再Release Header的Num。同樣是點擊Header的Num﹐然后按 ﹐進入另一畫面后﹐不用存盤﹐按 即可

Role的傳輸—傳送 這一部分是Basis的工作。 本來是在Unix下進行﹐但我們開發了兩支外挂程式。 從測試環境到正式環境是YATP 從測試環境到QAS是YATPQA 進行傳送的Request Num必須是已經Release的Number

Role的傳輸—傳送 兩者的畫面很象﹐填入Request Num﹐選擇好目標Server﹐按 就可以了

Role的傳輸—刪除 如果發現Role搭錯了一個 Request Num﹐在沒有Release前可以補救。同樣是在SE10,點擊Num后使用 就可以了。

Role的傳輸—刪除 如果已經Release就沒有辦法刪除了﹐只能整個Number作廢﹐所謂“作廢”其實是不做最后的傳送動作﹐讓這個Number閑置而已。

Role的刪除 在PFCG中填好Role的名字﹐按 按鈕﹐確認﹐即可把Role及其專屬Profile刪除。

Role的刪除 請注意﹕如果需要利用傳輸功能在多個環境中刪除Role﹐一定要按以下順序進行﹕ 1.對Role產生傳輸的Request Num﹔ 2.刪除本環境的Role﹔ 3.Release;(此時本環境中已經沒有這個Role了） 4.傳輸

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

帳號刪除 刪除一個帳號后﹐為其專設的Role（即Z或W開頭的）也要刪除（包括測試和正式環境）﹐減少系統無用的資料﹐也減少不必要的查對。 這個理由咋看起來很有道理。實際上USER一旦決定刪除某個帳號﹐在相當長的時間內都不會再起用（一個 帳號的費用不菲﹐決定不會輕易下的）﹐在經過長時間后即使需要再次起用﹐其權限需求也要重新審視﹐與其把其新需求與舊有設定一項一項對比修改﹐還不如重新設定來得方便快捷﹐而且更安全。

Debug/查看 有一些工具對權限的問題處理很有幫助 1.SU53 2.SUIM 雖然還有一些其它工具﹐但一般很少用或者不實用﹐這里就不介紹了。

Debug/查看—SU53 當一個帳號反映沒有某個應有的權限時﹐我們可以在系統出現沒有權限的信息時﹐馬上輸入“/NSU53”

Debug/查看—SU53

Debug/查看—SU53 上頁紅色框住的就是沒有權限的地方﹐ 而藍色框住的是跟這個帳號已經有的權限。 但無論如何﹐有一個 參考總比沒有好。

Debug/查看—SUIM SUIM其實就是Information 系統的一個集合界面。 我們最常用的功能是﹕ 已知某個T Code﹐查找含有這個T Code的Role。

Debug/查看—SUIM

Debug/查看—SUIM 輸入T Code后執行﹐就可以得到含有這個T code的Role的列表。 請注意﹕其判斷條件是Role的Menu﹐而不是Profile

特殊的權限設定 SD的權限 在SD模組﹐有一個解S/O Billing Block權限的設定﹐它是在YS08中設定

其它知識 1.Object的狀態Standard/Manually/Maintained/Changed 2.Object Value VS Org.level

其它知識—Object的狀態

其它知識—Object的狀態 當我們用第三項進入一個Profile的時候﹐我們可以看到每個Object 的描述前有都有兩個狀態。現在我來給大家解釋一下他們的含義。 右邊的狀態共有兩種﹕NEW 和 OLD NEW﹕此Object有新的Item或Value, Profile Save后會變成OLD OLD﹕ 此Object的Item是以前建立的

其它知識—Object的狀態 左邊的狀態有好几種﹕ Standard﹕由系統帶出后沒有經過任何更改 Maintained﹕對系統初次帶出時Value為空的Item進行過變更或補充 Changed﹕對系統初次帶出時Value為非空的Item進行過變更

其它知識—Object Value VS Org.level 大家可能對Object Value與Org.level的關系有一些疑問﹐對Adjust時子Role到底那些地方會被母Role控制變更有點把握不住。 那么下面介紹的東東對大家可能有點幫助 1.Adjust大原則﹕ Org.level﹕子Role有值時﹐Adjust時以子Role為准﹐ 子Role無值時﹐Adjust以母Role為准 Object.Value﹕一律強制以母Role為准

其它知識—Object Value VS Org.level 2.Value與Org.level 我們可以發現﹐在Object里有些Item的Value是與Org.level相關聯的﹐其值在沒有手工更改前都是以“$”開頭﹐這類值都是變量﹐指向對應的Org.level。 當Org.level給值后﹐Object就通過這些變量把Org.level的值顯示出來﹐但實際上Object的值仍然是原來以“$”開頭的那個值。

其它知識—Object Value VS Org.level 在子Role中﹐如果這些Object Value被手工更改﹐在母Role沒有做Adjust之前﹐子Role的Object Value是可以與Org.level不一致的﹐實際權限以Object Value為准。但一旦母Role做了Adjust﹐子Role的Object Value就強制與母Role一致。而母Role一般對這類Object Value的處理是保持其變量狀態﹐那么子Role的Value就變會變量狀態（$XXXX)﹐然后根據子Role Org.level的值顯示出新的值。

其它知識—Object Value VS Org.level 3.如果不小心變更了與Org相連的Value﹐但又想恢復其變量狀態﹐怎么操作﹖ 首先﹐簡單地把Value清空是不行的﹐這樣的操作只是把當前值變為NULL(空)﹐第二﹐把其原有的$開頭的值Key進去也是不行的﹐主要原因是輸入欄位的長度不夠。 正確操作是﹕把這個Object整個刪除﹐然后手工添加這個Object。

請大家把自己的發現告訴我 這個教材是我在工作之余測試編寫的﹐因為看到不少兄弟姊妹包權限的時候還有不少的疑問﹐所以希望能總結一下﹐對大家有點幫助 因為時間很不夠用﹐斷斷續續寫了一個多月﹐本來有些東西想寫﹐但由于沒有時間進一步了解﹐怕寫出來誤人子弟。只好作罷。同時由于時間和精力﹐美觀方面就不做多的修飾了。(反正是內部教材 ^ _ ^)

請大家把自己的發現告訴我 這不是客套話﹕這個教材雖然是我很辛苦寫出來的﹐但可能還是有不對的地方﹐請大家發現后告訴我﹐我有時間的時候會修正。同時如果大家有自己的心得也請不吝賜教﹐特別是各個模組特有的權限設定﹐輔助工具的使用﹐Basis組所負責的權限部分﹐權限的傳輸等方面﹐我還有些地方了解的很不足夠﹐希望各位能告訴我。