1、ORACLE EBS系統應用基礎概述一、前言二、表單與查查詢（Forrm andd Summmary）三、事務處理理（Trannsactiion）四、并發流程程（Currrent PProcesss）五、文件夾（Folder）六、彈性域（Flex field）七、值集與查查找代碼（VValue Set aand Loookup Code）八、配置文件件（Proffile）九、單據編號號（Docuument Sequeence）十、工作流（Workflow）十一、預警（Alert）十二、應用開開放接口（OOpen IInterfface aand APPI）十三、結語（注：網站批量量發圖有問題題

2、，上傳后顯顯示不清楚。點點擊圖片打開開后，質量尚尚可）一、前言有網友在論壇發發帖驚呼：好好不容易把EEBS系統安安裝好了，進進去一看傻眼眼了，不知道道從哪兒下手手？發出驚嘆嘆的這位網友友所遇到的問問題，實際上上也是很多人人曾經遇到或或正在遇到的的問題。長期期以來，國內內的非專業人人士（例如媒媒體）提及SSAP或ORACLLE的時候，有有不少人喜歡歡用“超級難懂”來形容。那那么，國內專專業人士的看看法又如何呢呢？筆者所聽聽到過的最“雷”的說法來自自一位國內軟軟件研發的高高層主管：SSAP/ORRACLE太太復雜了，其其背后的東西西、深層次的的東西，我們們永遠不可能能搞懂！ 真是太不可思議議。一方

3、面，國國內的業內人人士幾乎眾口口一詞，我們們與SAP/ORACLLE相比，技技術上沒有多多大差距，平平臺工具都是是公開的，也也沒有什么奧奧秘可言。SSAP/ORRACLE由由于產品做得得早，我們在在技術上甚至至還有后發優優勢。另一方方面，我們也也常常聽到國國內有些人將將SAP/OORACLEE神秘化，認認為其包含“復雜的、深深刻的管理思思想”，是德國人人/美國人的東東西，我們中中國人的企業業管理水平低低，用不了是是正常的。國國情不同，模模式不同，中中國人應該尋尋找一條適合合自己的道路路！真的是這樣嗎？SAP/OORACLEE產品真的是是那么神秘、高高不可攀？今今天專業從事事ERP工作的的人員，

4、若從從個人背景角角度來看，通通?？梢詣澐址譃椤凹夹g出身”與“業務出身”兩類?！凹夹g出身”的人在學習習熟悉系統方方面可能有一一定優勢，但但與用戶溝通通交流的過程程中，在迅速速準確把握業業務本質要領領方面可能存存在一定困難難；而“業務出身”的人，對于于與用戶的業業務溝通交流流可能感覺比比較容易，但但在研究掌握握系統方面則則可能相對困困難一些。根根據筆者曾經經做過的調查查統計，國內內ERP從業人人員中“技術出身”的人似乎占占了絕大多數數。ORACLE EBS 作作為一個有百百多個業務應應用模塊、高高度集成的企企業管理軟件件系統，它是是現代計算機機技術與企業業管理實踐的的高度融合。它它不是模仿企企業手

5、工業務務過程的“電算化”簡單再現，或或許正是讓很很多人感到其其“難懂難用”的根本原因因所在。因此此，“從實踐中來來，再到實踐踐中去”，或曰“從業務透視視技術，再從從技術回歸業業務”也許正是我我們一步一步步叩開ORAACLE EEBS的大門門，徜徉其間間并游刃有余余的方法論。（這這里的所謂“技術”意指“系統實現”）。業內對于專業從從事ERP工作的的人員，大致致有以下三種種分類：一類類是所謂“技術顧問”，對于這些些人來說，掌掌握相應的軟軟件開發技能能是必要條件件，其工作領領域的重點一一般主要是在在系統后臺，類類似開發系統統接口、業務務報表，解決決一些系統的的技術問題等等等；二類是是所謂“功能顧問”

6、，這些人對對于系統的相相關模塊有不不同程度的熟熟悉，通常是是在指導企業業使用系統，或或努力地在把把企業的業務務要求變為系系統的實現方方案；三類是是所謂“管理顧問”，這些人通通常有比較豐豐富的企業管管理實戰經驗驗積累，同時時對ERP系統也也有比較深刻刻的認識，能能夠從企業管管理業務流程程的整體高度度給出咨詢建建議，最大限限度地發掘出出ERP系統對對于企業管理理水平提高的的重要作用（這這里的“管理顧問”是特指，有有別于市面上上眾多不懂系系統、只會“紙上談兵”的忽悠型“管理顧問”）。實際工作中，上上述三類人員員前后之間可可能并無明確確的劃分界線線，但大體上上有一個隨著著系統認識水水平的提高以以及業務

7、運作作經驗的積累累，由低到高高發展的過程程。因此，如如何實現“從業務角度度去透視技術術，從技術角角度去回歸業業務”是業內人員員所面對的永永恒命題，能能達到業務與與技術的“融會貫通”則是追求的的最高境界。為為此，本篇將將從博大精深深的ORACCLE EBBS系統最基基本的應用基基礎組成元素素開始，從業業務技術業務，探討討讓有些人高高深莫測、妄妄自菲薄的所所謂“其背后的東東西、深層次次的東西”到底是些什什么，以便能能夠最終尋找找到幫助我們們登堂入室的的鑰匙與途徑徑。二、表單與查詢詢（Formm and Summaary）企業在手工模式式下的業務運運作過程中，總總有各種各樣樣的用于記錄錄業務數據或或

8、管理信息的的紙面單據，例例如“銷售訂單、采采購訂單、入入庫單、出庫庫單”等等。隨著著業務量的增增加，這些紙紙面單據的數數量是如此之之多，以致于于企業不得不不花費大量人人力，將每張張單據上的重重要信息摘要要出來（例如如采購訂單上上的供應商、物物料、數量、價價格、金額、日日期等），另另外建立一個個數據記錄的的“索引、清單單或臺賬”等， 以方便能在在需要時對它它們進行查詢詢或統計。一個最簡單的軟軟件管理系統統，就是把上上述紙面單據據“電子化”后放入系統統，然后再提提供一個在系系統里查找這這些單據的“查詢”功能。如果果你去研究一一下目前國內內的主流ERRP產品，你你就會發現這這些主要用于于中低端市場場

9、的國內ERRP產品，其其每個模塊中中的應用功能能實際主要就就是“單據新增與與單據查詢”這兩項。其其單據在系統統中的格式和和內容與紙面面單據是如此此近似相像，以以致于大多數數企業人員學學習掌握它們們不會感覺有有多大困難。在ORACLEE EBS的的每個模塊中中，同樣也是是要用到各種種單據（Foorm）來錄錄入或保存數數據（對應于于后臺數據庫庫中的“表”），并為之之提供相應的的查詢功能，但但ORACLLE中的系統統單據已經不不是紙面單據據的簡單再現現。系統的UUI界面中可可以見到各種種“表單”（據統計約約有30000多種），它它們不僅不同同于紙面單據據，相互之間間的性質及查查詢方式差別別也可能很大

10、大。歸納起來來，ORACCLE各模塊塊中的“表單”按性質與作作用大體可分分為三大類：第一類是“業務務流程”類表單，例如如“銷售訂單SOO、采購訂單單PO、制造工工單WO、發票INVVOICE”等等，它們們有一個共同同的特點是參參與核心業務務流程的運轉轉，是核心業業務流程的一一個環節、不不可或缺。這這一點顯然也也是和實際的的企業業務過過程是高度相相對應的。作作為業務的原原始憑據憑證證，它們是如如此重要，即即使是IT系統化之之后，大多數數企業可能還還是要將它們們的紙面形態態予以保存、歸歸檔。 在ORRACLE EBS中，“業務流程”類表單種類類其實很少（每每個模塊一般般僅一、兩個個左右），但但每種

11、單據隨隨時間日積月月累，業務數數據量可能很很大。業務流流程類表單是是系統中最重重要的表單，與與紙面單據相相比，內容更更為豐富和復復雜，格式也也有很大的變變化，它充分分利用了數據據庫技術所提提供的可容納納性、可擴展展性以及使用用便利性。它它來源于業務務實踐，但經經高度抽象并并融入最新科科技成就后，其其功能與作用用又遠遠高于于原始的紙面面單據。如圖圖1的PO表單:PO表單是一個個典型的“業務流程”類表單，它它有“表頭與表體體行”兩大部分組組成，這一點點與紙面單據據仍然類似。但但不同的是系系統表單的每每一個“表體行”，還可以擁擁有屬于自己己的“二級子表行行”；而每一個個“二級子表行行”，也可以擁擁有

12、屬于自己己的“三級子表行行”，如此類推推。這種表單單展現方式，紙紙面單據是無無法實現的，它它極大地擴充充了單據可以以包含的信息息容量，具有有高度的靈活活性與便利性性。在圖1中，PO的第一行行采購總數量量為36，對應到到“發運”二級子表拆拆分為數量分分別為20與16的兩行（表表示發到兩個個不同收貨地地點或同一地地點但兩個不不同發貨時間間）；“發運”二級子表的的第一行數量量為20，對應到到“分配”三級子表拆拆分為數量分分別是10與10的兩行（表表示對應到兩兩個不同的費費用會計科目目或費用由兩兩個不同部門門分別承擔）。第二類是“數據據來源”類表單，例如如“OM模塊中的的價目表、PPO模塊中的的報價單

13、、”以及“物料、供應應商、客戶”數據表單等等等，它們的的共同特點是是不參與核心心業務流程的的構建，但它它們為業務流流程表單提供供可以參考的的數據來源，例例如采購訂單單從物料表單單取物料相關關信息，從供供應商表單取取供應商信息息、從報價單單取價格相關關信息等等；這類表單在在手工業務模模式下大多數數都可能也存存在，但手工工狀態下的實實際使用與管管理可能無法法做到很嚴格格規范；在ORACLEE EBS中中，“數據來源”類表單在每每個模塊中種種類可能很多多，每種表單單的內容與格格式復雜程度度，以及單據據數量也差別別很大。它們們雖然并非不不可或缺，但但它們體現的的專業化分工工與協作的管管理思想，對對于企

14、業的業業務流程運作作效率有重大大影響。 下圖22所示訂單管管理/定價模塊中中的“價目表”，就是一個個典型的“數據來源類類”表單，它也也可有復雜的的結構:第三類是“業務務控制”類表單，例如如“銷售的物料料可訂購性、采采購的批準供供應商列表、系系統參數設定定”等等，這類類表單在手工工業務模式下下很少或根本本不存在。事事實上，手工工方式下實際際也很難使用用它們對業務務進行有效控控制。在ORACLEE EBS中中，“業務控制”類表單在各各模塊中的種種類也比較少少，單據數量量也很有限，但但它們體現的的是企業管理理的系統控制制機制，對于于業務管理控控制的效率有有重要影響。如下圖3所示采采購的批準供供應商列

15、表（控控制可向哪些些供應商采購購），就是一一個比較典型型的“業務控制類類”表單，它也也同樣可有復復雜的結構。盡管在ORACCLE EBBS中，統計計后臺數據庫庫中所用到的的“表”（Tablee）數量有一一萬多個，前前臺UI中可見的的表單也形形形色色、數量量繁多，乍看看令人生畏，但但在分析歸納納劃分為以上上三大類之后后， 事情就會變變得簡單很多多，它使得我我們可以把每每個模塊中種種類很有限的的“核心的業務務流程表單”作為學習研研究的“切入點”，通過對每每種單據內部部業務內涵與與技術內涵的的分析，以及及各種單據之之間業務邏輯輯與技術邏輯輯的研究，逐逐步擴展并掌掌握系統的其其它功能與應應用?；趯嶋H

16、工作的的需要以及系系統設計的簡簡潔方便，OORACLEE針對上述三三種不同類型型的表單分別別提供了可供供選擇使用的的不同“查詢”方法，歸納納起來也可分分為三類：功功能查詢方式式、快捷查詢詢方式、簡便便查詢方式。所謂“功能查詢詢”方式，在系系統中有“查詢”功能菜單項項（例如POO Summmary，采采購訂單匯總總），點擊此此菜單進入時時，系統會首首先彈出“查找條件”輸入窗口（控控件），如下下圖4所示采購訂訂單功能查詢詢菜單與查詢詢條件控件：然后根據輸入的的查詢條件，給給出查詢結果果LIST。作作為查詢功能能擴展，系統統還在UI界面工具具欄進一步提提供關聯查詢詢（如采購訂訂單的上下游游單據“采購

17、申請”和“采購發票”）和細節查查詢功能，如如下圖5所示采購訂訂單功能查詢詢方式的輸出出結果視圖：功能查詢方式通通常只用于核核心“業務流程”類單據的查查詢，查詢功功能強大。由由于業務流程程類表單（以以及部分數據據來源類表單單）的重要性性，系統在菜菜單項中提供供了專門的“查詢”功能。 所謂“快快捷查詢”方式即在打打開單據界面面后，只需點點擊UI界面工具具欄內的查詢詢“圖標”（手電筒），查查詢條件輸入入方式有兩種種：一種是無無專用的“查詢條件”選擇窗口，僅僅限于在查找找界面的“查找欄”輸入常用的的那些字段（即即所謂“模糊查詢”），系統在在查找界面直直接給出所有有符合條件的的條目LISST，而詳細細情

18、況需選定定條目后，再再進入單據界界面查看，如如下圖6所示“采購訂單”在單據界面面進行“快捷查詢”的情況：另一種是在單據據界面點擊查查詢圖標（手手電筒）后，也也會出現“查詢條件”輸入窗口，輸輸入查詢條件件后，系統也也可能會出現現一個簡單的的結果清單LLIST界面面或視圖（某某些表單查詢詢則可能沒有有），通過該該LIST視圖圖界面可以再再選擇打開相相關條目的表表單。同時，也也可以直接在在單據界面按按“翻頁”鍵（Pagee Downn或Page Up），在在已經查詢出出的不同條目目間按順序直直接切換。如如圖7所示：物料料快捷查詢方方式的查詢條條件控件與輸輸出結果視圖圖：述（兩種）快捷捷查詢方式，適適

19、用于大多數數業務數據量量大的表單數數據的查詢。而而后一種“快捷查詢”方式與“功能查詢”方式有些近近似，只是其其查詢結果的的輸出視圖的的相關“功能”（如上查下下查的追溯、匯匯總與明細的的切換等）沒沒有“功能查詢”方式那么強強大。但對于于大多數“數據來源”類表單，由由于它們不參參與構建核心心流程，信息息也不如業務務流程類表單單那樣復雜，故故“快捷查詢”方式已經基基本能夠滿足足實際工作需需要。如按“功能查詢”方式為所有有表單設計“查詢條件控控件”與查詢“輸出結果視視圖”（象某些國國內產品做的的那樣），則則系統設計工工作的復雜性性將大大增加加，后續系統統維護也將十十分麻煩，既既不經濟也無無多大實際意意

20、義。 所謂“簡便查詢”方式，即在在打開單據界界面后直接把把“單據”界面的所有有字段作為“查找條件輸輸入窗口”。要做到這這一點，只需需在打開單據據界面后，于于UI的工具欄欄“查看”中選擇“查詢標準-輸入”（或按F111鍵），此時時單據界面有有關字段即“灰顯”，允許輸入入具體查詢值值，再在“查看”中選擇“查詢標準-運行”（或按Ctrrl+F111），則單據據界面顯示查查詢結果，按按“翻頁”鍵（Pagee Downn或Page Up），在在已經查詢出出的不同條目目間按順序直直接切換。如如下圖8所示：物料料清單BOMM的簡便查詢詢方式示意圖圖：這種查詢方式既既不需要“查詢條件”控件，也不不需要查詢結結

21、果輸出視圖圖，系統設計計上十分簡單單節省，適用用于幾乎所有有表單。要注注意的是對于于系統中某些些數據量很少少的表單，則則有可能系統統只提供“簡便查詢”作為唯一可可使用的查詢詢方式。此外，EBS中中的某些表單單，在WEBB下可能還有有基于HTMML的展現與與查詢方式。UI與HTML這兩種展現與查詢方式的優劣，一方面與使用場合有關，另一方面也與使用習慣有關。總之，了解系統中各類表單的使用并熟練掌握各種查詢方式，是進一步學習研究系統的基礎，盡管EBS各模塊的表單展現與查詢方式因不同業務、不同設計者的風格偏好而可能有所不同，但核心本質的東西還是共同一致的。ORACLE EBS 系系統應用基礎礎概述三、

22、事務處理（Transaction）四、并發流程程（Currrent PProcesss）五、文件夾（Folder）六、彈性域（Flex field）七、值集與查查找代碼（VValue Set aand Loookup Code）八、配置文件件（Proffile）九、單據編號號（Docuument Sequeence）十、工作流（Workflow）十一、預警（Alert）十二、應用開開放接口（OOpen IInterfface aand APPI）十三、結語（注：網站批量量發圖有問題題，上傳后顯顯示不清楚。點點擊圖片打開開后，質量尚尚可）三、事務處理（Transaction）如果說上述EBBS的

23、“表單與查詢詢”的系統設計計體現的正是是“從業務到技技術”，比較容易易理解與掌握握，那么，所所謂“事務處理”則是體現系系統“從技術再到到業務”的一個典范范，相對而言言，理解起來來要困難很多多，原因是無無法直接在手手工業務模式式下找到相對對應的處理方方式與過程。以庫房接收采購購物料為例，假假定公司規定定必須嚴格按按PO來接收，并并且公司為了了嚴格控制庫庫存水平，接接收必須小批批量、多批次次，則庫房人人員就可能需需要針對同一一個PO在短時期期內開出N多張的“入庫單”，工作量很很大。為了減減少工作量、提提高效率，庫庫房人員可能能會在供應商商每次送貨時時，僅在找出出來的PO紙面單據據上只簡單地地做一個

24、數量量標識，最后后累積起來匯匯總開一張“入庫單”。但這種“圖省事”的做法顯然然是一種“很不規范”的處理方式式，雖可以提提高工作效率率，卻會因為為容易帶來很很多其它管理理問題而在實實際工作中不不被允許。ORACLE 系統通過提提供一個“事務處理”工作界面則則很簡單地解解決了上述難難題。如下圖圖9所示采購接接收的事務處處理工作界面面：類似于“收貨時時直接在PO紙面單據上上簡單地做數數量標識”，每次供應應商送貨來時時，庫存人員員只需在系統統中查找出對對應的PO，簡單地地輸入送貨數數量并保存，則則系統會在后后臺自動生成成“事務處理記記錄”(等同于是“入庫單”)。對于系統統來說，這種種處理方式技技術上實

25、現非非常容易，但但卻大大減少少了操作人員員的工作量，有有效地解決了了由于小批量量、多批次所所帶來的效率率問題。ORACLE的的各業務模塊塊，大量地采采用了上述類類似的“事務處理”系統工作方方式，不僅保保證了系統高高度的數據集集成性，而且且對于系統各各業務環節的的流程處理也也保證了高度度的連貫性與與集成性。例例如OM系統的發發貨處理、WWIP系統的的領料與入庫庫處理等等。系系統中所提供供的事務處理理工作界面，有有些可能會以以“工作臺臺”（Worrkbencch）來命名名之（這取決決于不同模塊塊系統設計人人員的個人偏偏好）。更進一步，系統統對于某些“業務流程”類表單，例例如“銷售訂單、發發票”等，

26、還在表表單界面直接接提供一個名名曰“活動”（Actioon）的按鈕鈕（Buttton），該按鈕包包含豐富的業業務處理功能能（不僅僅是是輸入數據），以以便用戶（UUser）對對表單內容作作各種操作處處理或獲取相相關信息。如如下圖10所示，銷銷售訂單界面面的“活動”按鈕：此外，ORACCLE EBBS在某些業業務流程單據據之間，也提提供了類似的的事務處理工工作界面，以以幫助用戶方方便地實現業業務單據的轉轉換和業務流流程的銜接。如如下圖11所示的采采購申請PRR到采購訂單單PO的所謂“自動創建”（Autoccreatee）功能。對于企業的一個個系統用戶UUser（事務處處理型用戶）來來說，掌握了了與

27、自己工作作相關的表單單、表單查詢詢、事務處理理，就基本上上掌握了EBBS的系統使使用，系統就就不再難懂難難用。EBSS中的“事務處理”在業務流程程表單內部解解決了“人與系統”的統一問題題，在業務流流程表單之間間解決了“業務與業務務、業務與系系統”的統一問題題。從“純技術”的系統實現現角度來看，它它也沒有什么么高深莫測的的地方。很奇怪也很遺憾憾的是，迄今今國內主流EERP產品的的系統中，還還很少看到這這種系統實現現方式。曾有有一網友通過過MSN向筆者者發問：“EBS的WIP 事務務處理界面是是否要手工輸輸入itemm？”看起來這個個問題似乎很很“幼稚”，但對于很很多剛開始接接觸EBS或過去去用慣

28、國內產產品的人來說說，由于不了了解或不習慣慣EBS的“事務處理”系統實現方方式，會不自自覺、想當然然地將所有EEBS的FORM界面面都當成具有有“實體”作用、通常常可以對應紙紙面單據的“業務表單”來看待，才才會發出這樣樣的疑問。四、并發流程（Current Process）從系統實現角度度來看，“并發流程”或“并發處理”是較之“事務處理”技術味更濃濃的一個概念念，它也是業業務出身、不不太懂“技術”的人學習掌掌握EBS系統的的難點之一。但但實際上，對對于今天的計計算機系統而而言，“并發”其實是一個個再普通不過過的應用，例例如我們邊在在電腦上寫文文章邊聽音樂樂等等。ORRACLE 弄得有點學學究氣

29、，相對對于“聯機事務”或“聯機處理”方式，并發發處理稱為“后臺事務”或“后臺處理”似乎更好理理解一些。以企業的實際業業務過程為例例，在手工業業務模式下，庫庫房接收了物物料并開具“入庫單”后，庫房人人員后續必須須還要做的一一項工作是：“手工”將入庫單上上的物料接收收信息逐份“過賬”到“庫存物料信信息臺賬”上去，以更更新庫存物料料的余額數量量。在EBSS系統中，這這項枯燥、乏乏味的工作就就完全由系統統代勞了，系系統通過后臺臺運行的一個個名為“接收事務處處理處理器”的并發程序序，聯機立即即或成批周期期進行處理，在在不影響用戶戶做其它工作作的同時，高高度精確地完完成著原本需需要人工去做做的“過賬登記”

30、任務，并且且手工模式下下過賬之后為為檢查錯漏而而需經常進行行的“對賬”工作也變得得根本就不再再需要。“并發處理”是是EBS系統不不可或缺的一一個重要組成成部分，上述述“物料接收”的并發處理理只是一個很很簡單的應用用。在EBSS中，“并發”按處理的對對象主要可分分為兩類：一一類是“流程事務”，一類是“報表事務”。系統統一一以“提交請求（RRequesst）”的方式提供供人機交互。如如下圖12所示“查詢或提交交請求”：對于每一個并發發“請求”，系統都可可以允許輸入入相關參數，并并計劃其是按按某一周期運運行，還是立立即或預定在在未來某一時時刻運行。系系統預置了大大量的為業務務流程服務的的“流程事務”

31、類后臺事務務處理程序，同同時還提供了了部分可供企企業參考的“報表事務”類輸出請求求。用戶使用用系統提供的的開發工具，也也可以很容易易地自定義某某些“個性化”的后臺程序序或報表輸出出，其運行管管理和使用方方式與系統預預置的并發程程序幾乎完全全相同。“并發處理”相相對于用戶來來說，實際上上是屬于在系系統后臺運行行的相關工作作，剛剛開始始接觸的人可可能會對之覺覺得陌生或使使用不順手，原原因主要是手手工業務或低低檔的管理軟軟件根本沒有有這種工作處處理方式。這這就好比相對對于交通主要要還是靠騎車車或步行的小小城鎮，今天天對于生活在在現代化大城城市的人們來來說，往來穿穿梭的地鐵、周周而復始的公公交、招手即

32、即停的出租車車已經成為全全部生活不可可或缺的一部部分，它們就就像城市的“血管”脈動一樣，奔奔流不息，維維持著城市生生命的運轉，生生機勃勃。EEBS的“并發處理”所承擔的角角色或所起的的作用正與之之基本類似。EBS并發處理理的另一項重重要特性是其其“系統級”的可計劃、可可管理、可控控制特性，系系統通過定義義“并發管理器器”、“請求集”等功能應用用，對所有需需要在后臺運運行的并發程程序進行管理理調度，以平平衡系統負載載，保證系統統有高的使用用性能。如下下圖13所示，定定義“并發管理器器”（包括運行行規則、工作作班次等等。這這類似于城市市里的交通調調度與控制）關于“流程事務務”類的并發請請求，因為涉

33、涉及到系統各各業務模塊的的具體功能應應用問題，這這里不便多講講。以下主要要來談一談“報表事務”類的并發請請求問題。有有網友曾抱怨怨說，“ORACLLE的報表功功能不好用，出出一個簡單的的報表都要到到后臺去提交交一個請求，輸輸出的是一個個文本，太麻麻煩。系統提提供的標準報報表，內容不不能滿足企業業要求，不符符合國人的使使用習慣”。這種說法法可能是因為為受某些國內內產品的影響響而產生的誤誤解。目前國國內的主流EERP系統，對對于“報表”基本上采取取的是類似“查詢”的實現方式式。這種“查詢式報表表”雖然方便了了用戶使用，但但卻惹出了無無窮的麻煩。首先，報表是一一種極端“個性化”的東西，不不同的企業由

34、由于管理層次次不一樣，關關注的管理重重點也不同，針針對同樣的問問題所要求的的報表也會不不同。即使同同一個企業在在不同的發展展階段，所要要求的報表內內容也不會相相同，因此即即使已經使用用ERP若干年年的企業，不不斷地開發新新的（管理）報報表，也是很很正常的事情情。如果ERRP系統將報報表功能“顯式化”，在系統標準準功能中提供供查詢條件控控件及輸出結結果視圖，則則意味著系統統提供的這個個所謂報表功功能必須符合合所有企業的的使用要求，而而實際這是不不可能實現的的。在這種情情況下，企業業就會理所當當然地認為這這是ERP廠商的的責任，廠商商必須負責解解決。目前許許多國內ERRP廠商產品品研發的一項項重要

35、內容就就是窮于應付付為企業開發發各種查詢式式管理報表，這這簡直是等于于自掘火坑，陷陷進去無法自自拔，其次，查詢式報報表如果內容容復雜、耗用用系統資源比比較高，則用用戶隨便自由由使用， 而IT系統維護護人員對“聯機式”查詢無法進進行有效管理理、干預，將將可能嚴重影影響系統整體體性能，導致致其他用戶無無法進行正常常工作。從這這個角度來看看，目前國內內的主流ERRP產品實際際上還沒有真真正系統意義義上的“報表”功能，只有有不加節制、擴擴大化了的“查詢”功能。系統統如此處理極極不明智。ORACLE 將“報表”功能以并發發請求的形式式放到后臺去去處理，不僅僅有效地解決決了“報表”的個性化問問題，分清了了

36、ERP廠商與與企業的責任任界面，而且且也為企業IIT系統維護護人員提供了了系統可管理理、可干預的的便利。這實實際上正是OORACLEE系統的靈活活性與功能強強大之處（SSAP也類似似）。有網友友針對國內某某些廠商聲稱稱自己的ERRP是“高端”產品時，質質疑“連并發都沒沒有，能算高高端嗎？”實際上是說說到了要害。一一個連“電梯”都沒有的高高樓怎能算得得上是現代化化的大廈呢！ORACLE系系統大量使用用后臺“并發處理”程序，實現現了系統用戶戶的流程操作作在“空間與時間間”上的分離，免免去了操作人人員的無效等等待時間。操操作人員提交交的并發請求求在后臺運行行的同時，并并不影響其處處理其它系統統事務，

37、這樣樣可以大大提提高用戶的工工作效率以及及使用的方便便性?！安l發”之于ORRACLE EBS系統統好比人體內內的“心臟”一樣重要，它它是系統實現現高度的數據據集成與流程程集成的核心心工具，是企企業依賴計算算機系統實現現業務運作與與管理控制自自動化的一個個技術體現。五、文件夾（FFolderr） 這又又是一個ORRACLE弄弄得有點學究究氣的概念（可可能也有中文文翻譯不到位位的原因）。所所謂“文件夾”（Foldeer）功能，簡簡單來說就是是稍有點ITT系統使用經經驗的人都明明白的“用戶自定義義查詢輸出界界面視圖”功能。系統統（可以）提提供的查詢條條件控件或查查詢輸出結果果視圖的字段段是如此之多

38、多，其中有很很多可能并不不是用戶希望望顯示出來的的，每一個系系統用戶Usser可以根根據個人的工工作需要或偏偏好，使用文文件夾功能自自由地定義自自己可見的UUI界面。ORAACLE 系系統為幾乎所所有重要的表表單、查詢條條件控件及查查詢結果輸出出視圖都提供供了文件夾功功能，這也是是ORACLLE系統靈活活性、易用性性、方便性之之所在。如下下圖14所示采購購PR的查詢：六、彈性域（FFlexfiield）所謂“彈性域”技術是人們們每當提及OORACLEE 產品技術術的先進性時時總會首先想想到的一個東東西，也是很很多初學者（尤尤其是“業務出身”的人）開始始接觸時可能能會感到有點點“發怵”的東西，原

39、原因之一是它它的技術味比比較濃。但實實際上，如果果從應用的角角度去理解，它它也并無多少少神秘之處。前面我們已經講講到“表單”是組成EBSS系統的最重重要基本元素素之一，每個個表單都由“表頭與表體體行”組成。系統統在UI界面中所所展示的是表表單的“標準顯示”，盡管這個個“標準顯示”可能已經包包含了適合各各行各業所使使用的那些常常用信息字段段（Segmment），但但對于不同企企業來說，總總可能會出現現需要添加一一些本企業特特殊需要的信信息字段的情情況，這從系系統角度通常常稱為“自定義表單單字段”。EBS的所謂謂“彈性域”技術實際就就是為了解決決這一常見的的系統應用問問題而應運而而生，對于初初學者

40、來說，把把它簡單地理理解為“自定義表單單字段”就容易多了了。如下圖15與圖圖16所示的采采購申請PRR表單，在表表頭部分“標準顯示”的UI界面（角角落）中有一一個“方框”（“【 】”），在表體體行部分的末末端也有一個個“方框”（“【 】”）。系統用用戶在需要輸輸入有關特殊殊信息時點擊擊“方框”，系統便會會分別彈出一一個包含若干干個自定義信信息行（相當當于為表單擴擴展了若干列列的字段）的的界面框，以以供用戶輸入入某些特殊信信息。 圖15所示采采購申請PRR表頭的“彈性域”方框與彈出出界面。用戶戶可在其中輸輸入關于該PPR的某些自自定義補充信信息，如“申請部門、申申請用途”等等。圖16所示采購購申

41、請PR表體行的的“彈性域”方框與彈出出界面。用戶戶可在其中輸輸入關于該PPR行的某些些自定義補充充信息，如關關于所申購物物料的“長寬高、顏顏色”等等。要注意的是，上上述“自定義表單單字段”是“系統級”而非“用戶級”的，也就是是說只有系統統管理員才能能做相關設置置，而普通用用戶只能在實實際工作中使使用。EBSS中所使用到到的“彈性域”分為兩類：一類是所謂謂“鍵彈性域”（Key FFlexfiield），一類是所所謂“說明性彈性性域”（Descrriptivve Fleexfielld）。而上述圖圖15與圖16采購申請請PR中的“彈性域”就是典型的的“說明性彈性性域”的范例。系統中幾乎所有有的重要

42、表單單（尤其是業業務流程類表表單）都具有有這種“自定義”功能的說明明性彈性域，系系統說明性彈彈性域總數有有二、三千之之多。稱之為為“說明性”（Descrriptivve）取其對對標準表單字字段作補充說說明之意。用用戶在說明性性彈性域中輸輸入的字段信信息，通常只只能作為統計計分析、出報報表使用，不不參與系統業業務流程的構構建，系統（應應用程序）不不對之在表單單之間作跟蹤蹤、追溯。如如下圖17所示是采采購申請PRR表頭“說明性彈性性域”的系統定義義界面：系統所謂“鍵彈彈性域”的情況較之之“說明性彈性性域”就復雜、嚴嚴格得多，原原因是它們參參與業務流程程的構建，系系統的應用程程序要對之進進行跟蹤、追

43、追溯，其作用用當然非?！瓣P鍵”（Key），故故數量也比較較少，在整個個EBS系統中中總數不過約約35個。其中中用得最多的的例如“物料類別彈彈性域”、“會計科目彈彈性域”等等。與“說明性彈性性域”屬于表單的的用戶“補充字段”不同的是，“鍵彈性域”本身就屬于于表單的系統統標準字段，這這個表單標準準字段用戶輸輸入的不是簡簡單的一個信信息，而是具具有某種可在在系統層面“自定義結構構”的一組信息息。 如下下圖18所示采購購申請PR表單界面面中“物料類別”字段，用戶戶輸入時將彈彈出系統已經經定義的“物料類別鍵鍵彈性域”界面，以供供用戶（選擇擇）輸入具體體信息：如下圖19所示示是系統層面面定義“鍵彈性域”的

44、界面。全全部35個鍵彈性性域主要集中中在庫存、總總賬、資產、人人力資源等核核心業務模塊塊中定義，其其它模塊只是是應用時調用用。鍵彈性域域由于其系統統地位與重要要性，其定義義方式與內容容也要比說明明性彈性域來來得復雜。對于每一個“鍵鍵彈性域”，系統允許許定義若干個個不同結構的的字段組合，以以使用在系統統中的不同場場合（例如不不同組織或帳帳套等等）。如如下圖20所示，表表達了“會計科目彈彈性域”可以有若干干不同結構（代代碼）的情況況，圖中“Visioon Chiina”的5段式結構，可可以和其它國國家或地區的的完全不同。ORACLE的的彈性域應用用技術作為系系統最重要的的基礎元素之之一，歷經多多年

45、發展，其其應用已遠非非上述所例舉舉的“表單字段信信息”那么簡單，它它事實上已經經發展成為一一種重要的方方法論。系統統基于（鍵）彈彈性域的某些些重要技術特特性，逐步發發展出了諸多多使用靈活、功功能強大的應應用實現方式式。（相關討討論必須結合合具體的系統統應用來進行行，這里不再再贅述）。ORACLE EBS 系系統應用基礎礎概述七、值集與查找找代碼（Vaalue SSet annd Loookup CCode）八、配置文件件（Proffile）九、單據編號號（Docuument Sequeence）十、工作流（Workflow）十一、預警（Alert）十二、應用開開放接口（OOpen IInter

46、fface aand APPI）十三、結語（注：網站批量量發圖有問題題，上傳后顯顯示不清楚。點點擊圖片打開開后，質量尚尚可）七、值集與查找找代碼（Vaalue SSet annd Loookup CCode）日常工作中，用用戶在表單的的字段（包括括彈性域字段段）中輸入數數據的方式無無外乎兩種：一種是直接接手工鍵入，例例如訂單中的的數量（數值值）或文字說說明（字符）等等等；另一種種就是所謂“LOV”（List of Vaalue），用用戶只能從某某個預先定義義的“來源單據”做選擇輸入入（用戶如手手工輸入，系系統可能自動動針對來源單單據進行校驗驗以確定輸入入值是否允許許）。表單字段的“LLOV”輸

47、入實際占占了系統輸入入操作的大部部分情況，之之所以如此的的重要原因是是業務實踐與與系統實現的的“標準化”需要。例如“人力資源管管理部”這個官方正正式名稱，在在人們的日常常工作與交流流中，可能被被簡化為“人力資源部部、人事部、HR”等等，大家都知道它們是一回事，一般不會引起誤解。但對于系統來說就完全不同了，細微的差別在系統中都是兩個不同的對象，所以說LOV實際上也是系統實現“數據共享與集成”的基礎。表單字段LOVV的來源單據據值種類，有有些可能比較較復雜，例如如象“物料、供應應商、客戶”等等，這些些字段的值被被從來源單據據帶過來時，系系統可能還會會帶過來其它它若干相關重重要信息到表表單的其它相相

48、關字段上去去。而有些可可能就比較簡簡單，例如屬屬于通用基礎礎數據范疇的的“單位UOM、幣別別Curreency以及及日期Datte”等。還有些些雖然也比較較簡單，但通通常需要用戶戶預先做好定定義，例如企企業的“部門名稱列列表”等，這些LOOV在系統中中通常稱之為為“值集”（Valuee Set）。在系統中定義一一個完整的“值集”需要兩個相相互獨立又相相互關聯的階階段，首先是是定義“值集名”，系統中可可以定義若干干個不同用途途的值集名，對對于每一個值值集（名），在在定義界面可可以對其相關關屬性（如“驗證類型：無、獨立、從從屬、表”等）做出相相應規定，以以使其符合實實際工作的需需要。如圖221所示

49、為“部門名稱”的“值集名”定義（或查查找）界面：其次，就是為已已經定義好的的“值集名”賦予具體的的值（驗證類類型為“無”的除外），以以組成系統可可用的LOVV。如下圖222所示，其中中，有些值之之間還可以根根據需要定義義形成某種“層次結構”，“父子值”之間具有“匯總與被匯匯總”的關系。驗證類型為“從從屬”或“表”的值集定義義比較特殊，前前者需先定義義所從屬的“獨立”值集。后者者則是將某個個系統內的“應用表”作為自己的的LOV來源（如如“定義供應商商”表單維護的的供應商名稱稱表），值集集定義時，需需規定使用哪哪些表，并定定義 WHEERE 子句句來限制值集集要使用的值值。使用值集LOVV的表單字

50、段段的值幾乎都都有一個共同同的特性是，一一般不直接參參與業務流程程的構建，或或不直接影響響業務流程的的運行。然而而系統表單的的某些字段是是需要承擔“流程構建”工作的，這這些表單字段段有些需要手手工輸入，有有些則可能是是系統流程運運行時自動賦賦值或在不同同流程階段自自動改寫（例例如，表單狀狀態“未完成、已已保存、已批批準、已拒絕絕”等等），有有些值在表單單中通常“可見”，有些則可可能是在特殊殊情況下才可可見。 上述這這些表單的特特殊字段（域域）的LOVV，一般是由由系統在所謂謂“查找代碼”（Lookuup Codde）功能中中定義的。OORACLEE在系統層面面于一個統一一的界面（FForm）中

51、中按模塊、按按引用字段進進行全部Loookup Code定定義。如圖223所示庫存存相關表單中中使用到的物物料的“需求類型”定義：Lookup Code系系統的定義分分為三種情況況（訪問級別別），一種是是“系統級”，屬于ORAACLE預定定義且不允許許用戶添加。這這種情況下的的“代碼值”（Code）基基本都屬于系系統的應用程程序中需要引引用到的，影影響或決定著著系統業務流流程的運行；二種是“用戶級”，屬于非系系統預定義而而由用戶自己己添加，這種種情況下的代代碼值一般不不被應用程序序所引用，其其作用與前述述值集LOVV值大體相同同；三種是“可擴展級”，屬于ORAACLE預定定義但允許用用戶添加。

52、這這種情況下的的系統預定義義值與“系統級”的定義值作作用基本相同同，而用戶添添加的部分，其其作用則與“用戶級”基本相同。八、配置文件（Profile）ORACLE的的所謂“配置文件”實質上就是是人們已經耳耳熟能詳的所所謂系統“參數”（不明白當當初的中文翻翻譯為何弄得得如此奇怪）。ORACLE中的配置文件或參數涉及兩個過程：一是配置文件的本身定義（Definition）；二是配置文件的應用設置（Setup）。ORACLE系系統的預定義義配置文件數數量雖達七、八八千之多，但但這些配置文文件對于用戶戶來說都是透透明可見的，并并不神秘。系系統提供“配置文件”定義界面，供供用戶對配置置文件的某些些屬性（

53、甚至至應用程序）進進行調整或修修改，用戶也也可以根據自自己的需要自自定義新的配配置文件。如如下圖24所示配置置文件的定義義：值得指出的是，系系統預定義的的“配置文件名名”有一定命名名規則（適用用于大多數配配置文件，少少數例外），例例如“MRP：忽略略替代BOMM/工藝路線線”，前面的MRRP是模塊代代碼，代表屬屬于哪個應用用模塊，后面面的部分則是是代表具體用用途。這種“命名規則”使我們很容容易查找到針針對不同模塊塊的相關參數數。盡管系統統預定義配置置文件或參數數的數量是如如此之多，令令人生畏，但但歸納起來，可可以發現按用用途大致劃分分為三類：一類是真正起到到控制業務流流程運作或事事務處理方式式

54、的部分，這這些參數就如如人們通常所所津津樂道的的所謂“流程開關”；二類實際際并不直接控控制流程運作作或事務處理理，只是起到到一個向表單單上默認某些些值的作用（這這些默認過去去的值，有些些參與流程構構建，有些僅僅起參考作用用。用戶在表表單上還是可可以修改的）；三類是起到到某些特殊控控制作用，例例如改變系統統的某些工作作方式、控制制UI界面的顏顏色字體等等等，通常與具具體業務關系系不大。所有有參數中前兩兩類占了絕大大部分數量（其其中第一類又又占主要部分分），第三類類數量很少。而而系統應用的的難點與重點點則是“第一類”、屬于“流程開關”那部分參數數。 ORRACLE系系統的配置文文件的“設置”（Se

55、tupp）非常方便便靈活，組合合起來的應用用功能十分強強大。系統的的配置文件設設置具有“結構層次性性”，對于某一一個具體的配配置文件，系系統允許最多多可以在6個層級進行行設置并發揮揮作用：地點點層（系統安安裝）、應用用產品（模塊塊）、責任（自自定義的責任任）、服務器器、組織（包包括OU/IINV等）、用用戶（自定義義的用戶）。具具體能在上述述6個層級中的的哪些層級“可見、可設設置”，取決于這這些配置文件件的原始定義義的相關屬性性。并且實際際應用程序訪訪問時，將按按照從“地點”逐步到“用戶”由低到高的的“優先級”順序發揮作作用。如下圖圖25所示配置置文件的設置置：最高優先級的“用戶層”如果留空不

56、不賦值，則系系統將默認上上一層級（責責任層）的值值作為自己的的值。逐級前前移直至最低低優先級的“地點層”，通常系統統在安裝后于于“地點層”有初始化的的默認值。盡盡管看起來配配置文件數量量有七八千，設設置工作量巨巨大，但實際際系統實施時時，對于大部部分企業來說說，好在使用用系統安裝時時的默認初始始值就能基本本符合要求，故故也并不十分分困難可怕。企企業在實際工工作過程中遇遇到問題時，如如希望系統能能實現某種功功能或希望系系統流程能按按某種方式運運行等等情況況，則通常首首先應該基于于系統配置文文件的不同設設置來尋求合合適的解決方方案。此外，系統對于于配置文件提提供了“系統”與“用戶”兩種“安全性”（

57、權限）的的控制功能，前前者一般由系系統維護人員員（如管理員員）進行控制制，后者普通通用戶就直接接可以作設置置修改，例如如“UI界面的顏顏色、字體”等。九、單據編號（Document Sequence） 與手工業業務模式下做做單據一樣，系系統中的所有有業務流程類類表單以及大大部分的數據據來源類表單單，由于業務務數據量巨大大，當然也需需要進行編號號管理。ORRACLE為為此提供了單單據的編號控控制功能：自自動編號、人人工編號或無無間隙（人工工編號必須連連續不斷號）。單單據編號具體體包括三個既既相互獨立又又相互關聯的的三個步驟：一是定義“單據序列”（發生器）；二是定義具具體的“單據類別”，三是將“單

58、據序列”分配給“單據類別”。如圖26所示為為定義“單據序列”（發生器）如圖27所示是是定義具體的的“單據類別”如圖28所示，是是將單據序列列發生器分配配給單據類別別，使兩者關關聯值得指出的是，事事實上系統中中的某些業務務流程表單（例例如銷售訂單單），系統允允許其自定義義若干數量的的“單據類別”（例如銷售售訂單中的“訂單類型”或“事務處理類類型”），這些自自定義的“單據類別”可以擁有（被被分配）各自自不同的單據據序列號發生生器（相當于于使用時系統統對它們各自自獨立編號），也也可以共同擁擁有同一個單單據單據序列列號發生器（相相當于使用時時系統對它們們混合共同編編號），這為為單據編號的的實際使用與與

59、管理提供了了很大的靈活活性與方便性性。另外要注注意的是，系系統中的某些些單據如采購購申請、采購購訂單以及供供應商等也可可以有其專門門的編號管理理機制，不能能一概而論。十、工作流（WWorkfllow）在企業的實際管管理工作中，一一個員工填寫寫好一份“費用報銷單單”后，后續可可能還需要經經過多個環節節例如直接主主管、上級主主管、財務主主管的審批，才才可能到達會會計（入賬）、出出納（付款）手手中，以完成成整個工作過過程。把這個個工作過程“電子化”后放入系統統，就形成一一個所謂的“工作流”過程。通常常這個報銷單單“工作流”需要經過哪哪些環節，是是系統需要預預先設置好的的，并且可能能不同的費用用類別所

60、需經經過的審批環環節也是不同同的。作為流流程的參與者者，例如“提交人、審審批人”等，可以查查詢、監控單單據的工作流流處理過程，系系統也可以在在流程環節移移動過程中，向向下一環節的的處理人發送送提醒通知（如如郵件等）。單據的“審批流流”實際是一個個很簡單、很很直觀的“工作流”應用。推而而廣之到系統統中其它業務務流程類表單單的事務處理理過程，所謂謂系統的“工作流”技術應用就就是：根據不不同的業務單單據類別，事事先定義好需需要經過的不不同業務處理理環節，單據據在做事務處處理時，按規規定順序在相相關環節間移移動。用戶可可監控，即普普通用戶可以以查看工作流流的處理過程程狀態；系統統可管理，即即系統工作流