oracleebs安全性管理系統基礎設置要點簡介(編輯修改稿)

　

【文章內容簡介】 統中按照業務的相似性，把多個不同公司（包括LE）的業務處理過程及數據劃分成相對獨立的“管理單元”。在每個管理單元內部，各公司的業務運作共享相關數據并執行統一的業務策略。例如，有一個業務多元化的企業既生產醫院使用的X光機也生產普通電視機，并且其下屬在全國各地有多家生產X光機或電視機的分公司、子公司。由于這兩種產品所使用的物料、供應商以及針對的客戶群差異很大，企業為方便管理，可以將“業務運營”劃分為兩個相對獨立的“業務管理群組”，對應到EBS系統中就是兩個業務實體OU。從企業日常業務運作管理的角度來看，對于單純的電視機業務，全國范圍內就設一個公司負責計劃、生產、采購、銷售等運營管理最為簡便，但企業從非運營管理角度例如“稅收優惠、地方政策”等等因素考慮，有時不得不在全國各地乃至世界各地注冊若干所謂“公司”，以便向當地政府納稅并接受其財務會計方面的監管。EBS在一個業務實體OU下，例如“電視機管理群組”，包含了全國各地所有負責生產或銷售電視機的分公司、子公司（LE）的日常業務運作，在業務運作的組織層面忽略了作為法人實體的公司信息，但在反映業務運營最終結果的財務階段（GL），仍能夠方便地按照各地的法規要求提供財務數據與結果。而對于負責具體業務的系統用戶來說，日常工作幾乎不用關心或考慮“公司”的設置問題。EBS中LE的數量可以根據需要任意增加，但對于OU的數量基于管理方便性則要求盡可能精簡。EBS產品早期在實施過程中，存在一個公司（LE）對應一個OU的做法或一個OU只能屬于一個LE的說法，這種做法或說法并不恰當。某些國內產品的設計由于未能有效區分“法律實體（公司）”與“業務實體（運營）”兩者在系統中既相連接又有本質區別的特殊關系，只好采取一個法人公司對應一個系統業務實體的“笨辦法”，企業規模小倒還能對付，一旦規模變大，注冊公司增多，所謂的“系統多組織架構”就變得根本不具可用性。ORACLE EBS業務實體OU的這一系統特性極大地方便了企業運作的日常管理，具有高度的靈活性與可擴展性。如下圖27是R11的OU定義界面：圖中的“業務實體信息”中，必須而且只能為之設定一個“帳套”，即一個OU只能屬于一個帳套（反之，一個帳套可以分配給多個OU）。要注意的是，上述業務實體信息中的法人實體設定，并不代表OU只能屬于一個LE，它只是表示在“業務實體”中進行業務操作需要法人實體信息時提供默認值（在R12中明確了是“默認值”這一點）。R12中的業務實體定義同R11基本相同，只是將帳套改為“主要分類帳”。在EBS中，一個OU可以同時指定給多個LE，上面“電視機管理群組”的例子已經說明了這一點；一個LE也可以有多個OU，這相當于一個注冊的法人實體公司下，有多個需要獨立運營的“事業部”（如X光機和電視機）。OU與LE是“多對多”的關系，但有一個限制性的前提條件，即OU與LE必須屬于同一個SOB或Ledger。由于LE與OU的設置在系統中可以獨立進行，因此如果雙方的SOB或Ledger不同，則不能建立連接關系。如果說法人實體LE與真實世界的企業行政管理組織架構還有點關系的話，業務實體OU則是與行政管理幾乎無關，企業內部的行政組織變化對OU的設置沒有直接影響。在EBS中有關采購管理、銷售訂單履行、應收應付管理等業務模塊的功能均是建立在OU基礎之上的。用戶在執行上述相關模塊的業務處理時，總是必須進入確定的OU（上下文環境）才可以進行，EBS的所謂“多組織”功能（MOAC）也是針對多OU而言的，與真實世界中的“多公司”（LE）沒有直接關系。實際上，SAP的“采購組織、銷售組織”設置也是與真實世界的行政組織“采購部、銷售部”無關的，ORACLE拋棄了“采購組織、銷售組織”的概念，OU實際上就起到了類似的組織分隔作用。ORACLE的某些相關文檔中，如果因描述需要而提及所謂“采購組織、銷售組織”等概念，有時實際指的就是業務實體OU（或OU下的庫存INV組織）。（四）庫存組織（INV） ORACLE EBS的庫存組織（INV）是系統組織設置的最基礎、也是最重要的工作之一。庫存組織的內涵遠不是真實世界的“倉庫部門”那么簡單，它除了是有關“物料接收與發出”等業務功能的基礎之外，更重要的是，它還是EBS系統有關計劃（MPS/MRP）、在制品管理（WIP）、物料清單（BOM）等模塊業務功能的操作與管理平臺。如下圖28所示：EBS中的庫存組織INV的作用與功能可以與SAP中的工廠Plant參看。一個庫存組織INV只能屬于一個確定的帳套SOB、一個確定的法人實體LE、一個確定的業務實體OU，具有唯一性的關系（注意：R11的設置界面未考慮SOB/LE/OU的關聯限定，容易產生錯誤；R12作了改進，在選定Ledger之后，可用的LE/OU就被限定）。反之，一個“帳套/法人實體/業務實體”組合則可以有多個庫存組織INV。此外，一個OU下的多個INV可以對應屬于該OU的不同LE，這相當于將分屬于兩個法人公司的生產兩種產品的四個工廠，按相同產品兩兩組合抽取出來，分屬于兩個不同OU進行日常業務管理。在EBS中還有兩個組織概念“MRP組織、WIP組織”，它們實際是必須構建于庫存組織之上的組織概念，表示該庫存組織還可以進行MRP或WIP的功能。系統之所以如此處理，主要是為了控制某些INV不能做MRP或WIP而已，因為基于物料接收或發出需要所設定的INV數量可能比較多。對于絕大多數基于庫存組織INV的業務功能（個別除外），系統用戶在做業務操作時，均必須首先進行INV的選擇切換，以便進入確定的INV上下文環境。庫存組織的作用是如此基礎，以至于EBS的相關文檔在提及組織（Org）概念時，如果未作特別說明，默認就是指INV組織。（五）公司成本中心（Cost Center） EBS的所謂“成本中心組織”并沒有業務處理的功能，它的設置主要是考慮與“會計科目彈性域結構”中的“公司段值”與“成本中心段值”的對應關系問題。如下圖29所示：在系統中創建“公司成本中心組織”后，可以運行一個“并發檢查程序”，以校驗“會計科目彈性域結構”中的段值是否與所有的“公司成本中心”組織的設置保持一致。當在“會計科目彈性域結構”中的“成本中心段”值集中添加LOV值并重新編譯后，可以運行系統的“自動組織”并發程序功能，由系統自動創建“公司成本中心”組織。應當注意的是，一個公司成本中心組織及其成本中心段值，不可能屬于不同法人實體LE及其公司段值，這與真實世界中的管理要求是一致的。庫存組織INV與會計科目彈性域中的“成本中心”段（部門）則具有“一對一或多對一”的關系，即一個“成本中心”段值可以有多個庫存組織INV，但一個庫存組織INV只能屬于一個確定的成本中心。（六）HR組織 系統的HR組織設置是與HRM模塊的相關業務處理功能相關，與核心業務/財務處理功能關系不大，主要是需要注意其是否和“成本中心”關聯，需要時可以輸入“成本中心”代碼，其LOV就是“會計科目彈性域”結構中成本中心段的值集。如下圖30所示：（七）多組織接入控制在圖30的EBS組織設置界面中，所謂的組織“類型”（Type）劃分僅是基于組織自身的統計分析工作需要而定義的一個“維度”，例如“公司總部、產品線”等等，并不影響系統的業務處理功能。真正起作用的是設置界面中的“組織分類”（Classification），系統預置的組織分類LOV除了上述“業務組、法律實體、業務實體、庫存組織”等之外，還有諸如“資產組織、運營公司、雇主”等等選項。在EBS系統中各應用模塊所具有的業務處理功能通常需構建在一個確定的“組織分類”之上，“組織”是相關業務處理功能的平臺，企業是否需要作相關組織分類設置、如何設置，取決于企業所需要使用到的應用模塊功能。例如所謂“資產組織”的設置，它是在企業需使用到資產管理模塊FA時才涉及到。“資產組織”實際上是所謂“資產賬簿”的代名詞，它只是表示有關資產信息的一個數據維度，作用主要在于分隔數據范圍，用戶進入系統作業務處理時，并不需要作上下文業務環境的切換。對于這類并不涉及“上下文”環境切換的所謂“組織”，ORACLR系統的設計主要是為了借用“組織”所具有的“層次結構”（Hierarchy）概念來達到“多組織接入”權限的控制功能。需指出的是，這里的組織“層次結構”與真實世界企業的行政管理組織層次結構沒有直接關系（盡管可能有所參考），它只是企業根據某種需要（如權限管理控制、數據統計匯報等）而人為設定的一個“層次結構”，例如將系統中已經設置的任意數量的“業務實體”或“庫存組織”等等組織Name，人為地設定一個具有上下級關系、自頂向下的金字塔形多層結構。如下圖31所示：上圖中開始定義時，一旦選定（最）頂端組織Name，則就只能為之分配下屬組織Name，如要給下屬組織分配更下一級的組織，則需點擊“向下”按鈕，將當前該下屬組織上升到“頂端組織”位置。點擊“向上”按鈕，則將當前“頂端組織”下降到下屬組織位置。企業可以根據實際需要設定若干個具有不同內部結構的“組織層次結構”Name，以供定義系統所謂“安全性配置文件”時調用。如下圖32所示：上圖所定義“安全性配置文件”是系統用以控制包括“組織安全性”等在內的各種安全性控制的基礎，它具體規定了系統安全性控制的范圍與實現方式，所有定義的“安全性配置文件”Name構成系統多組織接入控制參數“MO：安全性配置文件”的LOV。如下圖33所示：EBS 通過“MO：業務實體”、“MO：安全性配置文件”、“MO：默認業務實體”這三個系統配置文件的共同作用，實現所謂“多組織接入”控制功能MOAC。但上述三個配置文件在R11與R12中的作用有比較大的差別。對于“MO：業務實體”， 在R11中必須設定，而且起決定性控制作用，其LOV由系統基于創建的OU name自動創建，用戶登錄時系統自動定位于指定OU。而在R12中，一旦設定“MO：安全性配置文件”，則此配置文件失效而不起作用。對于“MO：安全性配置文件”， 在R11中雖有，但實際不起OU接入的控制作用，只針對FA等模塊的得某些應用如數據統計等起作用。因此，一般認為R11并不具有完善的多組織接入控制功能。在R12中，該參數如果不設定，則必須設定“MO：業務實體”參數；一旦該參數被設定，則就起決定作用，系統主要依賴其實現MOAC。對于“MO：默認業務實體”， 在R11中雖有但實際不起作用。在R12中，隨“MO：安全配置文件”起作用后才起作用，其LOV是所有已定義OU，但如果設定值不在“MO：安全配置文件”所選擇的“組織層次架構”的范圍內，則仍不起作用（即在與OU相關諸如PO、OM等的FORM界面，OU字段的默認值仍然為空）。這似乎是ORACLE 系統設計方面的一個難題，即“MO：默認業務實體”的LOV值集無法與“MO：安全性配置文件”中“組織層次架構”中的OU值范圍保持一致。ORACLE強調其“多組織接入MOAC”功能主要是針對業務實體OU而言，其另外一層含義是，所有構建于庫存組織INV上的應用功能，實際是與上述配置文件無關的。庫存組織的可接入性是在“組織訪問”控制功能中，專門設定“庫存組織”與“責任”的關聯性，如下圖34所示：按照ORACLE的說法，如果系統在初始的時候，不定義庫存組織的“組織訪問”控制，則所有“責任”可訪問所有INV，一旦限制或分配其中一個，則其余均必須逐個進行分配以建立“庫存組織”與“責任”的鏈接關系。總之，EBS系統通過“彈性域段值安全性”、“帳套/分類帳安全性”、“多組織接入安全性（MOAC）”、“庫存組織訪問控制”等多維度、多方面的組合系統設置，提供了靈活、方便的用戶權限管理功能，厘清并掌握它們的復雜關系是系統實施的一項重要基礎性工作。五、基礎數據基礎數據通常是指與具體業務關系不大且具有全局性、基礎性的一些基本數據，例如日歷Calendar、幣種Currency、匯率Rate、單位UOM、地點Location等等。這些基礎數據的系統設置有些比較簡單如“幣種”，有些與真實世界的情況相似如“日歷”，有些則可能比較抽象復雜如“地點”等等，情況多種多樣。以下擇其要者，作簡要說明。（一）關于“日歷”。EBS中的日歷設置，實際包括兩大類，一類是與會計工作相關的，包括“會計日歷”、“會計事務處理日歷”等，它們的使用范圍較小，有專門用途，一般是在總賬模塊設置（這里不贅述）。一類是工作日日歷，它與企業的日常業務工作相關，使用范圍廣泛，大多數涉及庫存組織的業務模塊都可能與之相關，如下圖35所示：需要注意的是，在新設置工作日日歷或更新已存在工作日日歷后，需要通過在工具欄的“建立”功能啟動一個后臺并發程序，以最終完成設置工作。（二）關于“幣種”。各國或地區的“貨幣”是一種客觀存在，EBS系統已經預置幾乎所有企業可能使用到的幣種，必要時還可以添加。用戶可以決定哪些幣種需要啟用，以及維護其使用時的“精確度”。如下圖36所示：（三）關于“匯率”。企業對于不同幣種匯率轉換的管理是一項重要的基礎性工作，它對企業的經營結果有重要影響。為方便該項工作的開展，EBS系統專門提供了一個名為“幣種管理器”的工具，如下圖37所示：企業可以根據工作需要設定多個“匯率類型”（系統