【文章內容簡介】 于分隔數(shù)據(jù)范圍，用戶進入系統(tǒng)作業(yè)務處理時，并不需要作上下文業(yè)務環(huán)境的切換。對于這類并不涉及“上下文”環(huán)境切換的所謂“組織”，ORACLR系統(tǒng)的設計主要是為了借用“組織”所具有的“層次結構”（Hierarchy）概念來達到“多組織接入”權限的控制功能。需指出的是，這里的組織“層次結構”與真實世界企業(yè)的行政管理組織層次結構沒有直接關系（盡管可能有所參考），它只是企業(yè)根據(jù)某種需要（如權限管理控制、數(shù)據(jù)統(tǒng)計匯報等）而人為設定的一個“層次結構”，例如將系統(tǒng)中已經(jīng)設置的任意數(shù)量的“業(yè)務實體”或“庫存組織”等等組織Name，人為地設定一個具有上下級關系、自頂向下的金字塔形多層結構。如下圖31所示：上圖中開始定義時，一旦選定（最）頂端組織Name，則就只能為之分配下屬組織Name，如要給下屬組織分配更下一級的組織，則需點擊“向下”按鈕，將當前該下屬組織上升到“頂端組織”位置。點擊“向上”按鈕，則將當前“頂端組織”下降到下屬組織位置。企業(yè)可以根據(jù)實際需要設定若干個具有不同內部結構的“組織層次結構”Name，以供定義系統(tǒng)所謂“安全性配置文件”時調用。如下圖32所示：上圖所定義“安全性配置文件”是系統(tǒng)用以控制包括“組織安全性”等在內的各種安全性控制的基礎，它具體規(guī)定了系統(tǒng)安全性控制的范圍與實現(xiàn)方式，所有定義的“安全性配置文件”Name構成系統(tǒng)多組織接入控制參數(shù)“MO：安全性配置文件”的LOV。如下圖33所示：EBS 通過“MO：業(yè)務實體”、“MO：安全性配置文件”、“MO：默認業(yè)務實體”這三個系統(tǒng)配置文件的共同作用，實現(xiàn)所謂“多組織接入”控制功能MOAC。但上述三個配置文件在R11與R12中的作用有比較大的差別。對于“MO：業(yè)務實體”， 在R11中必須設定，而且起決定性控制作用，其LOV由系統(tǒng)基于創(chuàng)建的OU name自動創(chuàng)建，用戶登錄時系統(tǒng)自動定位于指定OU。而在R12中，一旦設定“MO：安全性配置文件”，則此配置文件失效而不起作用。對于“MO：安全性配置文件”， 在R11中雖有，但實際不起OU接入的控制作用，只針對FA等模塊的得某些應用如數(shù)據(jù)統(tǒng)計等起作用。因此，一般認為R11并不具有完善的多組織接入控制功能。在R12中，該參數(shù)如果不設定，則必須設定“MO：業(yè)務實體”參數(shù)；一旦該參數(shù)被設定，則就起決定作用，系統(tǒng)主要依賴其實現(xiàn)MOAC。對于“MO：默認業(yè)務實體”， 在R11中雖有但實際不起作用。在R12中，隨“MO：安全配置文件”起作用后才起作用，其LOV是所有已定義OU，但如果設定值不在“MO：安全配置文件”所選擇的“組織層次架構”的范圍內，則仍不起作用（即在與OU相關諸如PO、OM等的FORM界面，OU字段的默認值仍然為空）。這似乎是ORACLE 系統(tǒng)設計方面的一個難題，即“MO：默認業(yè)務實體”的LOV值集無法與“MO：安全性配置文件”中“組織層次架構”中的OU值范圍保持一致。ORACLE強調其“多組織接入MOAC”功能主要是針對業(yè)務實體OU而言，其另外一層含義是，所有構建于庫存組織INV上的應用功能，實際是與上述配置文件無關的。庫存組織的可接入性是在“組織訪問”控制功能中，專門設定“庫存組織”與“責任”的關聯(lián)性，如下圖34所示：按照ORACLE的說法，如果系統(tǒng)在初始的時候，不定義庫存組織的“組織訪問”控制，則所有“責任”可訪問所有INV，一旦限制或分配其中一個，則其余均必須逐個進行分配以建立“庫存組織”與“責任”的鏈接關系?？傊珽BS系統(tǒng)通過“彈性域段值安全性”、“帳套/分類帳安全性”、“多組織接入安全性（MOAC）”、“庫存組織訪問控制”等多維度、多方面的組合系統(tǒng)設置，提供了靈活、方便的用戶權限管理功能，厘清并掌握它們的復雜關系是系統(tǒng)實施的一項重要基礎性工作。（一）業(yè)務組（BG）（二）法律實體（LE）（三）業(yè)務實體（OU）（四）庫存組織（INV）（五）公司成本中心（Cost Center）（六）HR組織（七）多組織接入控制在企業(yè)管理實踐的過程中，“組織”（Organization） 一詞是個經(jīng)常需用到的概念，一般與“人員”與“職能”這兩個要素密切相關，反映某種行政管理關系，例如“財務部、銷售部、采購部、生產部、倉儲部”等等。 企業(yè)內部行政組織（部門）的劃分是企業(yè)基于“職能驅動”業(yè)務管理模式進行運作的基礎。目前，國內適用于小企業(yè)使用的大多數(shù)低端管理軟件并不考慮系統(tǒng)中的 “組織”設置問題，其系統(tǒng)應用模塊的劃分，例如采購模塊、倉管模塊、銷售模塊等等，實際上就已經(jīng)基本反映了企業(yè)運作的“組織職能”劃分問題。但 是，對于業(yè)務復雜、規(guī)模較大的企業(yè)（如所謂“集團企業(yè)”），管理軟件使用與實施的系統(tǒng)“組織設置”問題將是一個首要的重要問題。一個常見的、也是錯誤的系 統(tǒng)實現(xiàn)方式就是將企業(yè)的“行政組織設置”直接映射到系統(tǒng)中，以“行政組織”代替“業(yè)務組織”。這種系統(tǒng)實現(xiàn)方式雖有理解、掌握比較容易的優(yōu)勢，但卻完全違 背了大企業(yè)運作必須基于“流程驅動”業(yè)務模式的基本管理原則。國內有所謂高端管理軟件在系統(tǒng)實施過程中，常常出現(xiàn)有幾十個財務、采購組織，幾百個銷售組 織，乃至上千個庫存組織的“盛況”，導致系統(tǒng)幾乎沒法使用的困境，其癥結正在于此。與企業(yè)的“行政組織”設置與人員規(guī)模密切相關且復雜多變不同，軟件系統(tǒng)的“組織設置”必須以業(yè)務流程運作為核心，要求盡可能簡單并保持相對穩(wěn)定，在公司（人員）規(guī)模擴大的過程中具有延續(xù)性與繼承性。作為ERP鼻祖的SAP將系統(tǒng)組織簡單地分為“集團（Client）、公司代碼（Company Code）、采購組織（Purchase Org）、銷售組織（Sale Org）、工廠（Plant）”等類別。ORACLE的組織設置本質上與之基本相似，但作為后來者作了進一步抽象與簡化，系統(tǒng)組織劃分為“業(yè)務組（Business Group）、法律實體（Legal Entity）、業(yè)務實體（Operating Unit）、庫存組織（Inventory Org）”等。如果說SAP的組織模型字面上多少還帶有一點“行政組織”痕跡的話（這可能是某些聲稱學SAP的國內產品誤入歧途的原因），ORACLE系統(tǒng)的組織模型字面上已經(jīng)幾乎看不出與“行政組織”還有什么關系，其中的“Inventory Org”現(xiàn)今中文翻譯成“庫存組織”，容易令人望文生義和企業(yè)的“倉庫管理部門（Warehouse）”混淆，但Inventory的本義實際應該是“存貨”，稱之為“存貨組織”或許更好一些。如下圖22所示ORACLE系統(tǒng)有關核心業(yè)務的多組織模型：上圖中的“財務、銷售、采購”并非系統(tǒng)的“組織實體”，它僅表示業(yè)務實體（OU）具有的相關業(yè)務處理功能?！白訋臁笔翘厥獾南到y(tǒng)組織實體，沒有上下文環(huán)境可進入，主要表示庫存組織之下的某種業(yè)務功能。（一）業(yè)務組（BG） “業(yè) 務組”的概念可以與企業(yè)的“集團”概念參看，但不同的是一個企業(yè)在系統(tǒng)中可以設置多個“業(yè)務組（集團）”。通常對于一個企業(yè)來說，系統(tǒng)中有一個“業(yè)務組” 就夠了，這表示企業(yè)就是一個“集團公司”。而對于某些業(yè)務“多元化”的特大型公司（如跨國公司），則可能需要在系統(tǒng)中設置多個“業(yè)務組”，表示企業(yè)由多個 “集團公司”組成。業(yè)務組設置是系統(tǒng)組織設置的第一步，是最高層級的組織形態(tài)，但它主要是與人力資源信息的分隔有關，即“人員信息”的設置在一個BG范圍內是由各業(yè)務模塊共享的（如果需要）。一旦系統(tǒng)設置的用戶名（User）被與“人員”（Employee）關聯(lián)，無論使用什么“責任”進入系統(tǒng)，都會定位至一個確定的BG中，任何責任在任意時刻只能關聯(lián)一個BG。EBS安裝好后，系統(tǒng)里面已經(jīng)預置了一個名為“Setup Business Group