ORACLE-EBS-系統(tǒng)設計應用基礎概述

-.z.系列之三：ORACLEEBS系統(tǒng)應用基礎概述一、前言二、表單與查詢（FormandSummary）三、事務處理（Transaction）四、并發(fā)流程（CurrentProcess）五、文件夾（Folder）六、彈性域（Fle*field）七、值集與查找代碼（ValueSetandLookupCode）八、配置文件（Profile）九、單據(jù)編號（DocumentSequence）十、工作流（Workflow）十一、預警（Alert）十二、應用開放接口（OpenInterfaceandAPI）十三、結語一、前言有網(wǎng)友在論壇發(fā)帖驚呼：好不容易把EBS系統(tǒng)安裝好了，進去一看傻眼了，不知道從哪兒下手？發(fā)出驚嘆的這位網(wǎng)友所遇到的問題，實際上也是很多人曾經(jīng)遇到或正在遇到的問題。長期以來，國的非專業(yè)人士（例如媒體）提及SAP或ORACLE的時候，有不少人喜歡用“超級難懂”來形容。則，國專業(yè)人士的看法又如何呢？筆者所聽到過的最“雷”的說法來自一位國軟件研發(fā)的高層主管：SAP/ORACLE太復雜了，其背后的東西、深層次的東西，我們永遠不可能搞懂！真是太不可思議。一方面，國的業(yè)人士幾乎眾口一詞，我們與SAP/ORACLE相比，技術上沒有多大差距，平臺工具都是公開的，也沒有什么奧秘可言。SAP/ORACLE由于產品做得早，我們在技術上甚至還有后發(fā)優(yōu)勢。另一方面，我們也常常聽到國有些人將SAP/ORACLE神秘化，認為其包含“復雜的、深刻的管理思想”，是德國人/美國人的東西，我們中國人的企業(yè)管理水平低，用不了是正常的。國情不同，模式不同，中國人應該尋找一條適合自己的道路！真的是這樣嗎？SAP/ORACLE產品真的是則神秘、高不可攀？今天專業(yè)從事ERP工作的人員，若從個人背景角度來看，通常可以劃分為“技術出身”與“業(yè)務出身”兩類?！凹夹g出身”的人在學習熟悉系統(tǒng)方面可能有一定優(yōu)勢，但與用戶溝通交流的過程中，在迅速準確把握業(yè)務本質要領方面可能存在一定困難；而“業(yè)務出身”的人，對于與用戶的業(yè)務溝通交流可能感覺比較容易，但在研究掌握系統(tǒng)方面則可能相對困難一些。根據(jù)筆者曾經(jīng)做過的調查統(tǒng)計，國ERP從業(yè)人員中“技術出身”的人似乎占了絕大多數(shù)。ORACLEEBS作為一個有百多個業(yè)務應用模塊、高度集成的企業(yè)管理軟件系統(tǒng)，它是現(xiàn)代計算機技術與企業(yè)管理實踐的高度融合。它不是模仿企業(yè)手工業(yè)務過程的“電算化”簡單再現(xiàn)，或許正是讓很多人感到其“難懂難用”的根本原因所在。因此，“從實踐中來，再到實踐中去”，或曰“從業(yè)務透視技術，再從技術回歸業(yè)務”也許正是我們一步一步叩開ORACLEEBS的大門，徜徉其間并游刃有余的方法論。（這里的所謂“技術”意指“系統(tǒng)實現(xiàn)”）。業(yè)對于專業(yè)從事ERP工作的人員，大致有以下三種分類：一類是所謂“技術顧問”，對于這些人來說，掌握相應的軟件開發(fā)技能是必要條件，其工作領域的重點一般主要是在系統(tǒng)后臺，類似開發(fā)系統(tǒng)接口、業(yè)務報表，解決一些系統(tǒng)的技術問題等等；二類是所謂“功能顧問”，這些人對于系統(tǒng)的相關模塊有不同程度的熟悉，通常是在指導企業(yè)使用系統(tǒng)，或努力地在把企業(yè)的業(yè)務要求變?yōu)橄到y(tǒng)的實現(xiàn)方案；三類是所謂“管理顧問”，這些人通常有比較豐富的企業(yè)管理實戰(zhàn)經(jīng)驗積累，同時對ERP系統(tǒng)也有比較深刻的認識，能夠從企業(yè)管理業(yè)務流程的整體高度給出咨詢建議，最大限度地發(fā)掘出ERP系統(tǒng)對于企業(yè)管理水平提高的重要作用（這里的“管理顧問”是特指，有別于市面上眾多不懂系統(tǒng)、只會“紙上談兵”的忽悠型“管理顧問”）。實際工作中，上述三類人員前后之間可能并無明確的劃分界線，但大體上有一個隨著系統(tǒng)認識水平的提高以及業(yè)務運作經(jīng)驗的積累，由低到高發(fā)展的過程。因此，如何實現(xiàn)“從業(yè)務角度去透視技術，從技術角度去回歸業(yè)務”是業(yè)人員所面對的永恒命題，能達到業(yè)務與技術的“融會貫通”則是追求的最高境界。為此，本篇將從博大精深的ORACLEEBS系統(tǒng)最基本的應用基礎組成元素開始，從業(yè)務—技術—業(yè)務，探討讓有些人高深莫測、妄自菲薄的所謂“其背后的東西、深層次的東西”到底是些什么，以便能夠最終尋找到幫助我們登堂入室的鑰匙與途徑。二、表單與查詢（FormandSummary）企業(yè)在手工模式下的業(yè)務運作過程中，總有各種各樣的用于記錄業(yè)務數(shù)據(jù)或管理信息的紙面單據(jù)，例如“銷售訂單、采購訂單、入庫單、出庫單”等等。隨著業(yè)務量的增加，這些紙面單據(jù)的數(shù)量是如此之多，以致于企業(yè)不得不花費大量人力，將每單據(jù)上的重要信息摘要出來（例如采購訂單上的供應商、物料、數(shù)量、價格、金額、日期等），另外建立一個數(shù)據(jù)記錄的“索引、清單或臺賬”等，以方便能在需要時對它們進行查詢或統(tǒng)計。一個最簡單的軟件管理系統(tǒng)，就是把上述紙面單據(jù)“電子化”后放入系統(tǒng)，然后再提供一個在系統(tǒng)里查找這些單據(jù)的“查詢”功能。如果你去研究一下目前國的主流ERP產品，你就會發(fā)現(xiàn)這些主要用于中低端市場的國ERP產品，其每個模塊中的應用功能實際主要就是“單據(jù)新增與單據(jù)查詢”這兩項。其單據(jù)在系統(tǒng)中的格式和容與紙面單據(jù)是如此近似相像，以致于大多數(shù)企業(yè)人員學習掌握它們不會感覺有多大困難。在ORACLEEBS的每個模塊中，同樣也是要用到各種單據(jù)（Form）來錄入或保存數(shù)據(jù)（對應于后臺數(shù)據(jù)庫中的“表”），并為之提供相應的查詢功能，但ORACLE中的系統(tǒng)單據(jù)已經(jīng)不是紙面單據(jù)的簡單再現(xiàn)。系統(tǒng)的UI界面中可以見到各種“表單”（據(jù)統(tǒng)計約有3000多種），它們不僅不同于紙面單據(jù)，相互之間的性質及查詢方式差別也可能很大。歸納起來，ORACLE各模塊中的“表單”按性質與作用大體可分為三大類：第一類是“業(yè)務流程”類表單例如“銷售訂單SO、采購訂單PO、制造工單WO、發(fā)票INVOICE”等等，它們有一個共同的特點是參與核心業(yè)務流程的運轉，是核心業(yè)務流程的一個環(huán)節(jié)、不可或缺。這一點顯然也是和實際的企業(yè)業(yè)務過程是高度相對應的。作為業(yè)務的原始憑據(jù)憑證，它們是如此重要，即使是IT系統(tǒng)化之后，大多數(shù)企業(yè)可能還是要將它們的紙面形態(tài)予以保存、歸檔。在ORACLEEBS中，“業(yè)務流程”類表單種類其實很少（每個模塊一般僅一、兩個左右），但每種單據(jù)隨時間日積月累，業(yè)務數(shù)據(jù)量可能很大。業(yè)務流程類表單是系統(tǒng)中最重要的表單，與紙面單據(jù)相比，容更為豐富和復雜，格式也有很大的變化，它充分利用了數(shù)據(jù)庫技術所提供的可容納性、可擴展性以及使用便利性。它來源于業(yè)務實踐，但經(jīng)高度抽象并融入最新科技成就后，其功能與作用又遠遠高于原始的紙面單據(jù)。如圖1的PO表單:PO表單是一個典型的“業(yè)務流程”類表單，它有“表頭與表體行”兩大部分組成，這一點與紙面單據(jù)仍然類似。但不同的是系統(tǒng)表單的每一個“表體行”，還可以擁有屬于自己的“二級子表行”；而每一個“二級子表行”，也可以擁有屬于自己的“三級子表行”，如此類推。這種表單展現(xiàn)方式，紙面單據(jù)是無法實現(xiàn)的，它極擴充了單據(jù)可以包含的信息容量，具有高度的靈活性與便利性。在圖1中，PO的第一行采購總數(shù)量為36，對應到“發(fā)運”二級子表拆分為數(shù)量分別為20與16的兩行（表示發(fā)到兩個不同收貨地點或同一地點但兩個不同發(fā)貨時間）；“發(fā)運”二級子表的第一行數(shù)量為20，對應到“分配”三級子表拆分為數(shù)量分別是10與10的兩行（表示對應到兩個不同的費用會計科目或費用由兩個不同部門分別承擔）。第二類是“數(shù)據(jù)來源”類表單例如“OM模塊中的價目表、PO模塊中的報價單、”以及“物料、供應商、客戶”數(shù)據(jù)表單等等，它們的共同特點是不參與核心業(yè)務流程的構建，但它們?yōu)闃I(yè)務流程表單提供可以參考的數(shù)據(jù)來源，例如采購訂單從物料表單取物料相關信息，從供應商表單取供應商信息、從報價單取價格相關信息等等；這類表單在手工業(yè)務模式下大多數(shù)都可能也存在，但手工狀態(tài)下的實際使用與管理可能無法做到很嚴格規(guī)；在ORACLEEBS中，“數(shù)據(jù)來源”類表單在每個模塊中種類可能很多，每種表單的容與格式復雜程度，以及單據(jù)數(shù)量也差別很大。它們雖然并非不可或缺，但它們體現(xiàn)的專業(yè)化分工與協(xié)作的管理思想，對于企業(yè)的業(yè)務流程運作效率有重大影響。下圖2所示訂單管理/定價模塊中的“價目表”，就是一個典型的“數(shù)據(jù)來源類”表單，它也可有復雜的結構:第三類是“業(yè)務控制”類表單例如“銷售的物料可訂購性、采購的批準供應商列表、系統(tǒng)參數(shù)設定”等等，這類表單在手工業(yè)務模式下很少或根本不存在。事實上，手工方式下實際也很難使用它們對業(yè)務進行有效控制。在ORACLEEBS中，“業(yè)務控制”類表單在各模塊中的種類也比較少，單據(jù)數(shù)量也很有限，但它們體現(xiàn)的是企業(yè)管理的系統(tǒng)控制機制，對于業(yè)務管理控制的效率有重要影響。如下圖3所示采購的批準供應商列表（控制可向哪些供應商采購），就是一個比較典型的“業(yè)務控制類”表單，它也同樣可有復雜的結構。盡管在ORACLEEBS中，統(tǒng)計后臺數(shù)據(jù)庫中所用到的“表”（Table）數(shù)量有一萬多個，前臺UI中可見的表單也形形色色、數(shù)量繁多，乍看令人生畏，但在分析歸納劃分為以上三大類之后，事情就會變得簡單很多，它使得我們可以把每個模塊中種類很有限的“核心的業(yè)務流程表單”作為學習研究的“切入點”，通過對每種單據(jù)部業(yè)務涵與技術涵的分析，以及各種單據(jù)之間業(yè)務邏輯與技術邏輯的研究，逐步擴展并掌握系統(tǒng)的其它功能與應用?；趯嶋H工作的需要以及系統(tǒng)設計的簡潔方便，ORACLE針對上述三種不同類型的表單分別提供了可供選擇使用的不同“查詢”方法，歸納起來也可分為三類：功能查詢方式所謂“功能查詢”方式，在系統(tǒng)中有“查詢”功能菜單項（例如POSummary，采購訂單匯總），點擊此菜單進入時，系統(tǒng)會首先彈出“查找條件”輸入窗口（控件），如下圖4所示采購訂單功能查詢菜單與查詢條件控件：然后根據(jù)輸入的查詢條件，給出查詢結果LIST。作為查詢功能擴展，系統(tǒng)還在UI界面工具欄進一步提供關聯(lián)查詢（如采購訂單的上下游單據(jù)“采購申請”和“采購發(fā)票”）和細節(jié)查詢功能，如下圖5所示采購訂單功能查詢方式的輸出結果視圖：功能查詢方式通常只用于核心“業(yè)務流程”類單據(jù)的查詢，查詢功能強大。由于業(yè)務流程類表單（以及部分數(shù)據(jù)來源類表單）的重要性，系統(tǒng)在菜單項中提供了專門的“查詢”功能?？旖莶樵兎绞剿^“快捷查詢”方式即在打開單據(jù)界面后，只需點擊UI界面工具欄的查詢“圖標”（手電筒），查詢條件輸入方式有兩種：一種是無專用的“查詢條件”選擇窗口，僅限于在查找界面的“查找欄”輸入常用的那些字段（即所謂“模糊查詢”），系統(tǒng)在查找界面直接給出所有符合條件的條目LIST，而詳細情況需選定條目后，再進入單據(jù)界面查看，如下圖6所示“采購訂單”在單據(jù)界面進行“快捷查詢”的情況：另一種是在單據(jù)界面點擊查詢圖標（手電筒）后，也會出現(xiàn)“查詢條件”輸入窗口，輸入查詢條件后，系統(tǒng)也可能會出現(xiàn)一個簡單的結果清單LIST界面或視圖（*些表單查詢則可能沒有），通過該LIST視圖界面可以再選擇打開相關條目的表單。同時，也可以直接在單據(jù)界面按“翻頁”鍵（PageDown或PageUp），在已經(jīng)查詢出的不同條目間按順序直接切換。如圖7所示：物料快捷查詢方式的查詢條件控件與輸出結果視圖：上述（兩種）快捷查詢方式，適用于大多數(shù)業(yè)務數(shù)據(jù)量大的表單數(shù)據(jù)的查詢。而后一種“快捷查詢”方式與“功能查詢”方式有些近似，只是其查詢結果的輸出視圖的相關“功能”（如上查下查的追溯、匯總與明細的切換等）沒有“功能查詢”方式則強大。但對于大多數(shù)“數(shù)據(jù)來源”類表單，由于它們不參與構建核心流程，信息也不如業(yè)務流程類表單那樣復雜，故“快捷查詢”方式已經(jīng)基本能夠滿足實際工作需要。如按“功能查詢”方式為所有表單設計“查詢條件控件”與查詢“輸出結果視圖”（象*些國產品做的那樣），則系統(tǒng)設計工作的復雜性將大大增加，后續(xù)系統(tǒng)維護也將十分麻煩，既不經(jīng)濟也無多大實際意義。簡便查詢方式所謂“簡便查詢”方式，即在打開單據(jù)界面后直接把“單據(jù)”界面的所有字段作為“查找條件輸入窗口”。要做到這一點，只需在打開單據(jù)界面后，于UI的工具欄“查看”中選擇“查詢標準-輸入”（或按F11鍵），此時單據(jù)界面有關字段即“灰顯”，允許輸入具體查詢值，再在“查看”中選擇“查詢標準-運行”（或按Ctrl+F11），則單據(jù)界面顯示查詢結果，按“翻頁”鍵（PageDown或PageUp），在已經(jīng)查詢出的不同條目間按順序直接切換。如下圖8所示：物料清單BOM的簡便查詢方式示意圖：這種查詢方式既不需要“查詢條件”控件，也不需要查詢結果輸出視圖，系統(tǒng)設計上十分簡單節(jié)省，適用于幾乎所有表單。要注意的是對于系統(tǒng)中*些數(shù)據(jù)量很少的表單，則有可能系統(tǒng)只提供“簡便查詢”作為唯一可使用的查詢方式。此外，EBS中的*些表單，在WEB下可能還有基于HTML的展現(xiàn)與查詢方式。UI與HTML這兩種展現(xiàn)與查詢方式的優(yōu)劣，一方面與使用場合有關，另一方面也與使用習慣有關。總之，了解系統(tǒng)中各類表單的使用并熟練掌握各種查詢方式，是進一步學習研究系統(tǒng)的基礎，盡管EBS各模塊的表單展現(xiàn)與查詢方式因不同業(yè)務、不同設計者的風格偏好而可能有所不同，但核心本質的東西還是共同一致的。三、事務處理（Transaction）如果說上述EBS的“表單與查詢”的系統(tǒng)設計體現(xiàn)的正是“從業(yè)務到技術”，比較容易理解與掌握，則，所謂“事務處理”則是體現(xiàn)系統(tǒng)“從技術再到業(yè)務”的一個典，相對而言，理解起來要困難很多，原因是無法直接在手工業(yè)務模式下找到相對應的處理方式與過程。以庫房接收采購物料為例，假定公司規(guī)定必須嚴格按PO來接收，并且公司為了嚴格控制庫存水平，接收必須小批量、多批次，則庫房人員就可能需要針對同一個PO在短時期開出N多的“入庫單”，工作量很大。為了減少工作量、提高效率，庫房人員可能會在供應商每次送貨時，僅在找出來的PO紙面單據(jù)上只簡單地做一個數(shù)量標識，最后累積起來匯總開一“入庫單”。但這種“圖省事”的做法顯然是一種“很不規(guī)”的處理方式，雖可以提高工作效率，卻會因為容易帶來很多其它管理問題而在實際工作中不被允許。ORACLE系統(tǒng)通過提供一個“事務處理”工作界面則很簡單地解決了上述難題。如下圖9所示采購接收的事務處理工作界面：類似于“收貨時直接在PO紙面單據(jù)上簡單地做數(shù)量標識”，每次供應商送貨來時，庫存人員只需在系統(tǒng)中查找出對應的PO，簡單地輸入送貨數(shù)量并保存，則系統(tǒng)會在后臺自動生成“事務處理記錄”(等同于是“入庫單”)。對于系統(tǒng)來說，這種處理方式技術上實現(xiàn)非常容易，但卻大大減少了操作人員的工作量，有效地解決了由于小批量、多批次所帶來的效率問題。ORACLE的各業(yè)務模塊，大量地采用了上述類似的“事務處理”系統(tǒng)工作方式，不僅保證了系統(tǒng)高度的數(shù)據(jù)集成性，而且對于系統(tǒng)各業(yè)務環(huán)節(jié)的流程處理也保證了高度的連貫性與集成性。例如OM系統(tǒng)的發(fā)貨處理、WIP系統(tǒng)的領料與入庫處理等等。系統(tǒng)中所提供的事務處理工作界面，有些可能會以“××工作臺”（Workbench）來命名之（這取決于不同模塊系統(tǒng)設計人員的個人偏好）。更進一步，系統(tǒng)對于*些“業(yè)務流程”類表單，例如“銷售訂單、發(fā)票”等，還在表單界面直接提供一個名曰“活動”（Action）的按鈕（Button），該按鈕包含豐富的業(yè)務處理功能（不僅僅是輸入數(shù)據(jù)），以便用戶（User）對表單容作各種操作處理或獲取相關信息。如下圖10所示，銷售訂單界面的“活動”按鈕：此外，ORACLEEBS在*些業(yè)務流程單據(jù)之間，也提供了類似的事務處理工作界面，以幫助用戶方便地實現(xiàn)業(yè)務單據(jù)的轉換和業(yè)務流程的銜接。如下圖11所示的采購申請PR到采購訂單PO的所謂“自動創(chuàng)建”（Autocreate）功能。對于企業(yè)的一個系統(tǒng)用戶User（事務處理型用戶）來說，掌握了與自己工作相關的表單、表單查詢、事務處理，就基本上掌握了EBS的系統(tǒng)使用，系統(tǒng)就不再難懂難用。EBS中的“事務處理”在業(yè)務流程表單部解決了“人與系統(tǒng)”的統(tǒng)一問題，在業(yè)務流程表單之間解決了“業(yè)務與業(yè)務、業(yè)務與系統(tǒng)”的統(tǒng)一問題。從“純技術”的系統(tǒng)實現(xiàn)角度來看，它也沒有什么高深莫測的地方。很奇怪也很遺憾的是，迄今國主流ERP產品的系統(tǒng)中，還很少看到這種系統(tǒng)實現(xiàn)方式。曾有一網(wǎng)友通過MSN向筆者發(fā)問：“EBS的WIP事務處理界面是否要手工輸入item？”看起來這個問題似乎很“幼稚”，但對于很多剛開始接觸EBS或過去用慣國產品的人來說，由于不了解或不習慣EBS的“事務處理”系統(tǒng)實現(xiàn)方式，會不自覺、想當然地將所有EBS的FORM界面都當成具有“實體”作用、通?？梢詫埫鎲螕?jù)的“業(yè)務表單”來看待，才會發(fā)出這樣的疑問。四、并發(fā)流程（CurrentProcess）從系統(tǒng)實現(xiàn)角度來看，“并發(fā)流程”或“并發(fā)處理”是較之“事務處理”技術味更濃的一個概念，它也是業(yè)務出身、不太懂“技術”的人學習掌握EBS系統(tǒng)的難點之一。但實際上，對于今天的計算機系統(tǒng)而言，“并發(fā)”其實是一個再普通不過的應用，例如我們邊在電腦上寫文章邊聽音樂等等。ORACLE弄得有點學究氣，相對于“聯(lián)機事務”或“聯(lián)機處理”方式，并發(fā)處理稱為“后臺事務”或“后臺處理”似乎更好理解一些。以企業(yè)的實際業(yè)務過程為例，在手工業(yè)務模式下，庫房接收了物料并開具“入庫單”后，庫房人員后續(xù)必須還要做的一項工作是：“手工”將入庫單上的物料接收信息逐份“過賬”到“庫存物料信息臺賬”上去，以更新庫存物料的余額數(shù)量。在EBS系統(tǒng)中，這項枯燥、乏味的工作就完全由系統(tǒng)代勞了，系統(tǒng)通過后臺運行的一個名為“接收事務處理處理器”的并發(fā)程序，聯(lián)機立即或成批周期進行處理，在不影響用戶做其它工作的同時，高度精確地完成著原本需要人工去做的“過賬登記”任務，并且手工模式下過賬之后為檢查錯漏而需經(jīng)常進行的“對賬”工作也變得根本就不再需要?！安l(fā)處理”是EBS系統(tǒng)不可或缺的一個重要組成部分，上述“物料接收”的并發(fā)處理只是一個很簡單的應用。在EBS中，“并發(fā)”按處理的對象主要可分為兩類：一類是“流程事務”，一類是“報表事務”。系統(tǒng)統(tǒng)一以“提交請求（Request）”的方式提供人機交互。如下圖12所示“查詢或提交請求”：對于每一個并發(fā)“請求”，系統(tǒng)都可以允許輸入相關參數(shù)，并計劃其是按*一周期運行，還是立即或預定在未來*一時刻運行。系統(tǒng)預置了大量的為業(yè)務流程服務的“流程事務”類后臺事務處理程序，同時還提供了部分可供企業(yè)參考的“報表事務”類輸出請求。用戶使用系統(tǒng)提供的開發(fā)工具，也可以很容易地自定義*些“個性化”的后臺程序或報表輸出，其運行管理和使用方式與系統(tǒng)預置的并發(fā)程序幾乎完全相同。“并發(fā)處理”相對于用戶來說，實際上是屬于在系統(tǒng)后臺運行的相關工作，剛剛開始接觸的人可能會對之覺得陌生或使用不順手，原因主要是手工業(yè)務或低檔的管理軟件根本沒有這種工作處理方式。這就好比相對于交通主要還是靠騎車或步行的小城鎮(zhèn)，今天對于生活在現(xiàn)代化大城市的人們來說，往來穿梭的地鐵、周而復始的公交、招手即停的出租車已經(jīng)成為全部生活不可或缺的一部分，它們就像城市的“血管”脈動一樣，奔流不息，維持著城市生命的運轉，生機勃勃。EBS的“并發(fā)處理”所承擔的角色或所起的作用正與之基本類似。EBS并發(fā)處理的另一項重要特性是其“系統(tǒng)級”的可計劃、可管理、可控制特性，系統(tǒng)通過定義“并發(fā)管理器”、“請求集”等功能應用，對所有需要在后臺運行的并發(fā)程序進行管理調度，以平衡系統(tǒng)負載，保證系統(tǒng)有高的使用性能。如下圖13所示，定義“并發(fā)管理器”（包括運行規(guī)則、工作班次等等。這類似于城市里的交通調度與控制）關于“流程事務”類的并發(fā)請求，因為涉及到系統(tǒng)各業(yè)務模塊的具體功能應用問題，這里不便多講。以下主要來談一談“報表事務”類的并發(fā)請求問題。有網(wǎng)友曾抱怨說，“ORACLE的報表功能不好用，出一個簡單的報表都要到后臺去提交一個請求，輸出的是一個文本，太麻煩。系統(tǒng)提供的標準報表，容不能滿足企業(yè)要求，不符合國人的使用習慣”。這種說法可能是因為受*些國產品的影響而產生的誤解。目前國的主流ERP系統(tǒng)，對于“報表”基本上采取的是類似“查詢”的實現(xiàn)方式。這種“查詢式報表”雖然方便了用戶使用，但卻惹出了無窮的麻煩。首先，報表是一種極端“個性化”的東西，不同的企業(yè)由于管理層次不一樣，關注的管理重點也不同，針對同樣的問題所要求的報表也會不同。即使同一個企業(yè)在不同的發(fā)展階段，所要求的報表容也不會相同，因此即使已經(jīng)使用ERP若干年的企業(yè)，不斷地開發(fā)新的（管理）報表，也是很正常的事情。如果ERP系統(tǒng)將報表功能“顯式化”，在系統(tǒng)標準功能中提供查詢條件控件及輸出結果視圖，則意味著系統(tǒng)提供的這個所謂報表功能必須符合所有企業(yè)的使用要求，而實際這是不可能實現(xiàn)的。在這種情況下，企業(yè)就會理所當然地認為這是ERP廠商的責任，廠商必須負責解決。目前許多國ERP廠商產品研發(fā)的一項重要容就是窮于應付為企業(yè)開發(fā)各種查詢式管理報表，這簡直是等于自掘火坑，陷進去無法自拔，其次，查詢式報表如果容復雜、耗用系統(tǒng)資源比較高，則用戶隨便自由使用，而IT系統(tǒng)維護人員對“聯(lián)機式”查詢無法進行有效管理、干預，將可能嚴重影響系統(tǒng)整體性能，導致其他用戶無法進行正常工作。從這個角度來看，目前國的主流ERP產品實際上還沒有真正系統(tǒng)意義上的“報表”功能，只有不加節(jié)制、擴大化了的“查詢”功能。系統(tǒng)如此處理極不明智。ORACLE將“報表”功能以并發(fā)請求的形式放到后臺去處理，不僅有效地解決了“報表”的個性化問題，分清了ERP廠商與企業(yè)的責任界面，而且也為企業(yè)IT系統(tǒng)維護人員提供了系統(tǒng)可管理、可干預的便利。這實際上正是ORACLE系統(tǒng)的靈活性與功能強大之處（SAP也類似）。有網(wǎng)友針對國*些廠商聲稱自己的ERP是“高端”產品時，質疑“連并發(fā)都沒有，能算高端嗎？”實際上是說到了要害。一個連“電梯”都沒有的高樓怎能算得上是現(xiàn)代化的大廈呢！ORACLE系統(tǒng)大量使用后臺“并發(fā)處理”程序，實現(xiàn)了系統(tǒng)用戶的流程操作在“空間與時間”上的分離，免去了操作人員的無效等待時間。操作人員提交的并發(fā)請求在后臺運行的同時，并不影響其處理其它系統(tǒng)事務，這樣可以大大提高用戶的工作效率以及使用的方便性。“并發(fā)”之于ORACLEEBS系統(tǒng)好比人體的“心臟”一樣重要，它是系統(tǒng)實現(xiàn)高度的數(shù)據(jù)集成與流程集成的核心工具，是企業(yè)依賴計算機系統(tǒng)實現(xiàn)業(yè)務運作與管理控制自動化的一個技術體現(xiàn)。五、文件夾（Folder）這又是一個ORACLE弄得有點學究氣的概念（可能也有中文翻譯不到位的原因）。所謂“文件夾”（Folder）功能，簡單來說就是稍有點IT系統(tǒng)使用經(jīng)驗的人都明白的“用戶自定義查詢輸出界面視圖”功能。系統(tǒng)（可以）提供的查詢條件控件或查詢輸出結果視圖的字段是如此之多，其中有很多可能并不是用戶希望顯示出來的，每一個系統(tǒng)用戶User可以根據(jù)個人的工作需要或偏好，使用文件夾功能自由地定義自己可見的UI界面。ORACLE系統(tǒng)為幾乎所有重要的表單、查詢條件控件及查詢結果輸出視圖都提供了文件夾功能，這也是ORACLE系統(tǒng)靈活性、易用性、方便性之所在。如下圖14所示采購PR的查詢：六、彈性域（Fle*field）所謂“彈性域”技術是人們每當提及ORACLE產品技術的先進性時總會首先想到的一個東西，也是很多初學者（尤其是“業(yè)務出身”的人）開始接觸時可能會感到有點“發(fā)怵”的東西，原因之一是它的技術味比較濃。但實際上，如果從應用的角度去理解，它也并無多少神秘之處。前面我們已經(jīng)講到“表單”是組成EBS系統(tǒng)的最重要基本元素之一，每個表單都由“表頭與表體行”組成。系統(tǒng)在UI界面中所展示的是表單的“標準顯示”，盡管這個“標準顯示”可能已經(jīng)包含了適合各行各業(yè)所使用的那些常用信息字段（Segment），但對于不同企業(yè)來說，總可能會出現(xiàn)需要添加一些本企業(yè)特殊需要的信息字段的情況，這從系統(tǒng)角度通常稱為“自定義表單字段”。EBS的所謂“彈性域”技術實際就是為了解決這一常見的系統(tǒng)應用問題而應運而生，對于初學者來說，把它簡單地理解為“自定義表單字段”就容易多了。如下圖15與圖16所示的采購申請PR表單，在表頭部分“標準顯示”的UI界面（角落）中有一個“方框”（“【】”），在表體行部分的末端也有一個“方框”（“【】”）。系統(tǒng)用戶在需要輸入有關特殊信息時點擊“方框”，系統(tǒng)便會分別彈出一個包含若干個自定義信息行（相當于為表單擴展了若干列的字段）的界面框，以供用戶輸入*些特殊信息。圖15所示采購申請PR表頭的“彈性域”方框與彈出界面。用戶可在其中輸入關于該PR的*些自定義補充信息，如“申請部門、申請用途”等等。圖16所示采購申請PR表體行的“彈性域”方框與彈出界面。用戶可在其中輸入關于該PR行的*些自定義補充信息，如關于所申購物料的“長寬高、顏色”等等。要注意的是，上述“自定義表單字段”是“系統(tǒng)級”而非“用戶級”的，也就是說只有系統(tǒng)管理員才能做相關設置，而普通用戶只能在實際工作中使用。EBS中所使用到的“彈性域”分為兩類：一類是所謂“鍵彈性域”（KeyFle*field），一類是所謂“說明性彈性域”（DescriptiveFle*field）。而上述圖15與圖16采購申請PR中的“彈性域”就是典型的“說明性彈性域”的例。系統(tǒng)中幾乎所有的重要表單（尤其是業(yè)務流程類表單）都具有這種“自定義”功能的說明性彈性域，系統(tǒng)說明性彈性域總數(shù)有二、三千之多。稱之為“說明性”（Descriptive）取其對標準表單字段作補充說明之意。用戶在說明性彈性域中輸入的字段信息，通常只能作為統(tǒng)計分析、出報表使用，不參與系統(tǒng)業(yè)務流程的構建，系統(tǒng)（應用程序）不對之在表單之間作跟蹤、追溯。如下圖17所示是采購申請PR表頭“說明性彈性域”的系統(tǒng)定義界面：系統(tǒng)所謂“鍵彈性域”的情況較之“說明性彈性域”就復雜、嚴格得多，原因是它們參與業(yè)務流程的構建，系統(tǒng)的應用程序要對之進行跟蹤、追溯，其作用當然非?！瓣P鍵”（Key），故數(shù)量也比較少，在整個EBS系統(tǒng)中總數(shù)不過約35個。其中用得最多的例如“物料類別彈性域”、“會計科目彈性域”等等。與“說明性彈性域”屬于表單的用戶“補充字段”不同的是，“鍵彈性域”本身就屬于表單的系統(tǒng)標準字段，這個表單標準字段用戶輸入的不是簡單的一個信息，而是具有*種可在系統(tǒng)層面“自定義結構”的一組信息。如下圖18所示采購申請PR表單界面中“物料類別”字段，用戶輸入時將彈出系統(tǒng)已經(jīng)定義的“物料類別鍵彈性域”界面，以供用戶（選擇）輸入具體信息：如下圖19所示是系統(tǒng)層面定義“鍵彈性域”的界面。全部35個鍵彈性域主要集中在庫存、總賬、資產、人力資源等核心業(yè)務模塊中定義，其它模塊只是應用時調用。鍵彈性域由于其系統(tǒng)地位與重要性，其定義方式與容也要比說明性彈性域來得復雜。對于每一個“鍵彈性域”，系統(tǒng)允許定義若干個不同結構的字段組合，以使用在系統(tǒng)中的不同場合（例如不同組織或帳套等等）。如下圖20所示，表達了“會計科目彈性域”可以有若干不同結構（代碼）的情況，圖中“VisionChina”的5段式結構，可以和其它國家或地區(qū)的完全不同。

ORACLE的彈性域應用技術作為系統(tǒng)最重要的基礎元素之一，歷經(jīng)多年發(fā)展，其應用已遠非上述所例舉的“表單字段信息”則簡單，它事實上已經(jīng)發(fā)展成為一種重要的方法論。系統(tǒng)基于（鍵）彈性域的*些重要技術特性，逐步發(fā)展出了諸多使用靈活、功能強大的應用實現(xiàn)方式。（相關討論必須結合具體的系統(tǒng)應用來進行，這里不再贅述）。七、值集與查找代碼（ValueSetandLookupCode）日常工作中，用戶在表單的字段（包括彈性域字段）中輸入數(shù)據(jù)的方式無外乎兩種：一種是直接手工鍵入，例如訂單中的數(shù)量（數(shù)值）或文字說明（字符）等等；另一種就是所謂“LOV”（ListofValue），用戶只能從*個預先定義的“來源單據(jù)”做選擇輸入（用戶如手工輸入，系統(tǒng)可能自動針對來源單據(jù)進行校驗以確定輸入值是否允許）。表單字段的“LOV”輸入實際占了系統(tǒng)輸入操作的大部分情況，之所以如此的重要原因是業(yè)務實踐與系統(tǒng)實現(xiàn)的“標準化”需要。例如“人力資源管理部”這個官方正式名稱，在人們的日常工作與交流中，可能被簡化為“人力資源部、人事部、HR”等等，大家都知道它們是一回事，一般不會引起誤解。但對于系統(tǒng)來說就完全不同了，細微的差別在系統(tǒng)中都是兩個不同的對象，所以說LOV實際上也是系統(tǒng)實現(xiàn)“數(shù)據(jù)共享與集成”的基礎。表單字段LOV的來源單據(jù)值種類，有些可能比較復雜，例如象“物料、供應商、客戶”等等，這些字段的值被從來源單據(jù)帶過來時，系統(tǒng)可能還會帶過來其它若干相關重要信息到表單的其它相關字段上去。而有些可能就比較簡單，例如屬于通用基礎數(shù)據(jù)疇的“單位UOM、幣別Currency以及日期Date”等。還有些雖然也比較簡單，但通常需要用戶預先做好定義，例如企業(yè)的“部門名稱列表”等，這些LOV在系統(tǒng)常稱之為“值集”（ValueSet）。在系統(tǒng)中定義一個完整的“值集”需要兩個相互獨立又相互關聯(lián)的階段，首先是定義“值集名”，系統(tǒng)中可以定義若干個不同用途的值集名，對于每一個值集（名），在定義界面可以對其相關屬性（如“驗證類型：無、獨立、從屬、表”等）做出相應規(guī)定，以使其符合實際工作的需要。如圖21所示為“部門名稱”的“值集名”定義（或查找）界面：其次，就是為已經(jīng)定義好的“值集名”賦予具體的值（驗證類型為“無”的除外），以組成系統(tǒng)可用的LOV。如下圖22所示，其中，有些值之間還可以根據(jù)需要定義形成*種“層次結構”，“父子值”之間具有“匯總與被匯總”的關系。驗證類型為“從屬”或“表”的值集定義比較特殊，前者需先定義所從屬的“獨立”值集。后者則是將*個系統(tǒng)的“應用表”作為自己的LOV來源（如“定義供應商”表單維護的供應商名稱表），值集定義時，需規(guī)定使用哪些表，并定義WHERE子句來限制值集要使用的值。使用值集LOV的表單字段的值幾乎都有一個共同的特性是，一般不直接參與業(yè)務流程的構建，或不直接影響業(yè)務流程的運行。然而系統(tǒng)表單的*些字段是需要承擔“流程構建”工作的，這些表單字段有些需要手工輸入，有些則可能是系統(tǒng)流程運行時自動賦值或在不同流程階段自動改寫（例如，表單狀態(tài)“未完成、已保存、已批準、已拒絕”等等），有些值在表單常“可見”，有些則可能是在特殊情況下才可見。上述這些表單的特殊字段（域）的LOV，一般是由系統(tǒng)在所謂“查找代碼”（LookupCode）功能中定義的。ORACLE在系統(tǒng)層面于一個統(tǒng)一的界面（Form）中按模塊、按引用字段進行全部LookupCode定義。如圖23所示庫存相關表單中使用到的物料的“需求類型”定義：LookupCode系統(tǒng)的定義分為三種情況（訪問級別），一種是“系統(tǒng)級”，屬于ORACLE預定義且不允許用戶添加。這種情況下的“代碼值”（Code）基本都屬于系統(tǒng)的應用程序中需要引用到的，影響或決定著系統(tǒng)業(yè)務流程的運行；二種是“用戶級”，屬于非系統(tǒng)預定義而由用戶自己添加，這種情況下的代碼值一般不被應用程序所引用，其作用與前述值集LOV值大體相同；三種是“可擴展級”，屬于ORACLE預定義但允許用戶添加。這種情況下的系統(tǒng)預定義值與“系統(tǒng)級”的定義值作用基本相同，而用戶添加的部分，其作用則與“用戶級”基本相同。八、配置文件（Profile）ORACLE的所謂“配置文件”實質上就是人們已經(jīng)耳熟能詳?shù)乃^系統(tǒng)“參數(shù)”（不明白當初的中文翻譯為何弄得如此奇怪）。ORACLE中的配置文件或參數(shù)涉及兩個過程：一是配置文件的本身定義（Definition）；二是配置文件的應用設置（Setup）。ORACLE系統(tǒng)的預定義配置文件數(shù)量雖達七、八千之多，但這些配置文件對于用戶來說都是透明可見的，并不神秘。系統(tǒng)提供“配置文件”定義界面，供用戶對配置文件的*些屬性（甚至應用程序）進行調整或修改，用戶也可以根據(jù)自己的需要自定義新的配置文件。如下圖24所示配置文件的定義：值得指出的是，系統(tǒng)預定義的“配置文件名”有一定命名規(guī)則（適用于大多數(shù)配置文件，少數(shù)例外），例如“MRP：忽略替代BOM/工藝路線”，前面的MRP是模塊代碼，代表屬于哪個應用模塊，后面的部分則是代表具體用途。這種“命名規(guī)則”使我們很容易查找到針對不同模塊的相關參數(shù)。盡管系統(tǒng)預定義配置文件或參數(shù)的數(shù)量是如此之多，令人生畏，但歸納起來，可以發(fā)現(xiàn)按用途大致劃分為三類：一類是真正起到控制業(yè)務流程運作或事務處理方式的部分，這些參數(shù)就如人們通常所津津樂道的所謂“流程開關”；二類實際并不直接控制流程運作或事務處理，只是起到一個向表單上默認*些值的作用（這些默認過去的值，有些參與流程構建，有些僅起參考作用。用戶在表單上還是可以修改的）；三類是起到*些特殊控制作用，例如改變系統(tǒng)的*些工作方式、控制UI界面的顏色字體等等，通常與具體業(yè)務關系不大。所有參數(shù)中前兩類占了絕大部分數(shù)量（其中第一類又占主要部分），第三類數(shù)量很少。而系統(tǒng)應用的難點與重點則是“第一類”、屬于“流程開關”那部分參數(shù)。ORACLE系統(tǒng)的配置文件的“設置”（Setup）非常方便靈活，組合起來的應用功能十分強大。系統(tǒng)的配置文件設置具有“結構層次性”，對于*一個具體的配置文件，系統(tǒng)允許最多可以在6個層級進行設置并發(fā)揮作用：地點層（系統(tǒng)安裝）、應用產品（模塊）、責任（自定義的責任）、服務器、組織（包括OU/INV等）、用戶（自定義的用戶）。具體能在上述6個層級中的哪些層級“可見、可設置”，取決于這些配置文件的原始定義的相關屬性。并且實際應用程序訪問時，將按照從“地點”逐步到“用戶”由低到高的“優(yōu)先級”順序發(fā)揮作用。如下圖25所示配置文件的設置：最高優(yōu)先級的“用戶層”如果留空不賦值，則系統(tǒng)將默認上一層級（責任層）的值作為自己的值。逐級前移直至最低優(yōu)先級的“地點層”，通常系統(tǒng)在安裝后于“地點層”有初始化的默認值。盡管看起來配置文件數(shù)量有七八千，設置工作量巨大，但實際系統(tǒng)實施時，對于大部分企業(yè)來說，好在使用系統(tǒng)安裝時的默認初始值就能基本符合要求，故也并不十分困難可怕。企業(yè)在實際工作過程中遇到問題時，如希望系統(tǒng)能實現(xiàn)*種功能或希望系統(tǒng)流程能按*種方式運行等等情況，則通常首先應該基于系統(tǒng)配置文件的不同設置來尋求合適的解決方案。此外，系統(tǒng)對于配置文件提供了“系統(tǒng)”與“用戶”兩種“安全性”（權限）的控制功能，前者一般由系統(tǒng)維護人員（如管理員）進行控制，后者普通用戶就直接可以作設置修改，例如“UI界面的顏色、字體”等。九、單據(jù)編號（DocumentSequence）與手工業(yè)務模式下做單據(jù)一樣，系統(tǒng)中的所有業(yè)務流程類表單以及大部分的數(shù)據(jù)來源類表單，由于業(yè)務數(shù)據(jù)量巨大，當然也需要進行編號管理。ORACLE為此提供了單據(jù)的編號控制功能：自動編號、人工編號或無間隙（人工編號必須連續(xù)不斷號）。單據(jù)編號具體包括三個既相互獨立又相互關聯(lián)的三個步驟：一是定義“單據(jù)序列”（發(fā)生器）；二是定義具體的“單據(jù)類別”，三是將“單據(jù)序列”分配給“單據(jù)類別”。如圖26所示為定義“單據(jù)序列”（發(fā)生器）如圖27所示是定義具體的“單據(jù)類別”如圖28所示，是將單據(jù)序列發(fā)生器分配給單據(jù)類別，使兩者關聯(lián)值得指出的是，事實上系統(tǒng)中的*些業(yè)務流程表單（例如銷售訂單），系統(tǒng)允許其自定義若干數(shù)量的“單據(jù)類別”（例如銷售訂單中的“訂單類型”或“事務處理類型”），這些自定義的“單據(jù)類別”可以擁有（被分配）各自不同的單據(jù)序列號發(fā)生器（相當于使用時系統(tǒng)對它們各自獨立編號），也可以共同擁有同一個單據(jù)單據(jù)序列號發(fā)生器（相當于使用時系統(tǒng)對它們混合共同編號），這為單據(jù)編號的實際使用與管理提供了很大的靈活性與方便性。另外要注意的是，系統(tǒng)中的*些單據(jù)如采購申請、采購訂單以及供應商等也可以有其專門的編號管理機制，不能一概而論。十、工作流（Workflow）在企業(yè)的實際管理工作中，一個員工填寫好一份“費用報銷單”后，后續(xù)可能還需要經(jīng)過多個環(huán)節(jié)例如直接主管、上級主管、財務主管的審批，才可能到達會計（入賬）、出納（付款）手中，以完成整個工作過程。把這個工作過程“電子化”后放入系統(tǒng)，就形成一個所謂的“工作流”過程。通常這個報銷單“工作流”需要經(jīng)過哪些環(huán)節(jié)，是系統(tǒng)需要預先設置好的，并且可能不同的費用類別所需經(jīng)過的審批環(huán)節(jié)也是不同的。作為流程的參與者，例如“提交人、審批人”等，可以查詢、監(jiān)控單據(jù)的工作流處理過程，系統(tǒng)也可以在流程環(huán)節(jié)移動過程中，向下一環(huán)節(jié)的處理人發(fā)送提醒通知（如等）。單據(jù)的“審批流”實際是一個很簡單、很直觀的“工作流”應用。推而廣之到系統(tǒng)中其它業(yè)務流程類表單的事務處理過程，所謂系統(tǒng)的“工作流”技術應用就是：根據(jù)不同的業(yè)務單據(jù)類別，事先定義好需要經(jīng)過的不同業(yè)務處理環(huán)節(jié)，單據(jù)在做事務處理時，按規(guī)定順序在相關環(huán)節(jié)間移動。用戶可監(jiān)控，即普通用戶可以查看工作流的處理過程狀態(tài)；系統(tǒng)可管理，即系統(tǒng)工作流管理員，必要時可以對單據(jù)的工作流過程進行干預，例如跳過*些環(huán)節(jié)、改變參與人等等。ORACLE系統(tǒng)核心業(yè)務模塊OM中關于銷售訂單的處理，就是一個典型的“工作流”技術使用例。系統(tǒng)根據(jù)實際業(yè)務處理的需要，先定義好不同的銷售訂單“行類型”。例如“Shiponly”，表示發(fā)給客戶的這個貨物免費、不需開票（例如因為貨物質量問題而補發(fā)等原因）；“Service”，表示這是向客戶提供的無形服務，無需發(fā)貨，但需根據(jù)訂單行開票向客戶收費等等。再給這些訂單“行類型”分配一個合適的系統(tǒng)已經(jīng)定義好的“行工作流”。如圖29所示OM銷售訂單“行類型—行流”分配定義：上述系統(tǒng)用于分配給“行類型”的行工作流，ORACLE提供了預定義的多種不同類別供用戶在設置系統(tǒng)時做選擇。更進一步，ORACLE還提供“WorkflowBuilder”軟件包工具（這個軟件可以到ORACLE官網(wǎng)上自由下載使用），以便用戶對于系統(tǒng)所有預定義的流程進行復制修改，或自定義符合使用要求的特殊流程。對于具體的每一個銷售訂單，同一訂單中可能包含不同行類型的訂單行，這些訂單行將循著各自的“行工作流”而進行事務處理。系統(tǒng)在表單界面的工具欄提供“工作流狀態(tài)查詢”的功能，用戶可以隨時對訂單中的每一個訂單行的系統(tǒng)處理過程實施監(jiān)控、查詢。如下圖30所示銷售訂單行的工作流監(jiān)控功能使用界面：在上圖中點擊“工作流狀態(tài)”功能，則系統(tǒng)將打開屬于訂單行1.1的工作流WEB查詢頁面。系統(tǒng)提供“活動歷史記錄”與“狀態(tài)圖”兩種主要查詢方式，分別如下圖31與圖32所示。圖31表示訂單行的活動歷史記錄，系統(tǒng)從用戶輸入訂單開始，對于后續(xù)幾乎每一步事務處理操作都做了記錄。圖32所示以直觀圖形方式顯示的訂單行流程狀態(tài)。需要指出的是，并非所有業(yè)務流程類表單都要采用類似銷售訂單的“工作流”處理方式，例如“采購訂單”的處理等。系統(tǒng)應用模塊是否使用、如何使用“工作流”技術，與具體的業(yè)務實踐以及采用之的優(yōu)缺點取舍有很大關系，不能一概而論。從系統(tǒng)開發(fā)設計的角度來看，盡管“工作流”于技術層面并不難掌握，但要與業(yè)務實踐實現(xiàn)很好的結合則并非易事。目前國主流產品基本都宣稱具有“工作流”技術，但真正在系統(tǒng)核心業(yè)務流程中用得比較好的并不多見，大多只是在“單據(jù)審批”或非核心的事務處理型業(yè)務諸如“費用報銷”等領域中有所應用。此外，在EBS中有關“單據(jù)審批”的工作流應用只是“單據(jù)審批”的系統(tǒng)實現(xiàn)方式之一。為滿足企業(yè)的復雜業(yè)務環(huán)境的需要，結合工作流技術，系統(tǒng)還專門提供了一個審批功能更為強大且相對獨立的引擎模塊“審批管理”（AME）作為“外圍產品”供企業(yè)選擇使用。(待續(xù))十一、預警（Alert）今天在企業(yè)的辦公場所或酒店的房間等很多地方，我們都可以見到天花板上裝有“煙感報警器”以及“自動噴淋器”，國家對建筑物的消防安全有明確的法律法規(guī)，因此這些“報警或滅火”裝置幾乎已成了建筑物的標準配置。與之類似，預警平臺對于今天的ERP系統(tǒng)來說也幾乎是一個標準裝備，無論是從系統(tǒng)實現(xiàn)角度還是從業(yè)務應用角度來看，它都不是很復雜，比較容易掌握。ORACLE的系統(tǒng)預警分兩種方式，一是“事件預警”，二是“周期預警”。兩者的基本工作方式均是使用SQLSelect語句基于對數(shù)據(jù)庫中的相關值作出條件判定，以決定是否執(zhí)行*種活動（發(fā)出信息，執(zhí)行并發(fā)程序、執(zhí)行操作系統(tǒng)程序、執(zhí)行SQL語句）。更進一步，對于“發(fā)出信息”類預警，系統(tǒng)在收到對此信息的符合規(guī)定格式的“回復”后，還可以據(jù)此自動執(zhí)行相關活動并完成相關事務處理。所謂“事件預警”，即當用戶在相關數(shù)據(jù)表中“插入”或“更新”*些值時，系統(tǒng)自動啟動已定義的“SQLSelect語句”的檢查，已確定是否需要發(fā)出預警信息或執(zhí)行*種活動，如下圖33所示的一個事件預警定義：在采購管理系統(tǒng)模塊中，當出現(xiàn)一個巨大數(shù)量的申請行數(shù)量被輸入時，系統(tǒng)需要向相關責任人發(fā)出預警通知（以提醒諸如做好資源準備等）。所謂“周期預警”，即系統(tǒng)按照事先定義好的周期間隔或頻率，自動啟動已定義的“SQLSelect語句”針對數(shù)據(jù)庫中表的*些值作檢查，已確定是否需要發(fā)出預警信息或執(zhí)行*種活動，如下圖34所示的一個周期預警定義：在采購管理系統(tǒng)模塊中，系統(tǒng)按每兩個工作日的間隔頻率對所有“一攬子采購協(xié)議BPA”的到期情況進行檢查，并將需要關注的檢查結果（例如*些BPA將在一周之類過期）通知到相關責任人。十二、應用開放接口（OpenInterfaceandAPI）任何ERP系統(tǒng)都無法做到在任何情況下都能滿足企業(yè)實際使用的各種要求，企業(yè)有時可能需要從其它來源向系統(tǒng)中批量輸入數(shù)據(jù)，如從物料的E*cel電子數(shù)據(jù)表格向EBS的INV系統(tǒng)導入Item信息等等，或者需要與其它第三方應用系統(tǒng)建立業(yè)務數(shù)據(jù)的交換機制，如從專用的“費用報銷或發(fā)票申付”管理系統(tǒng)向EBS的AP系統(tǒng)導入事務處理數(shù)據(jù)并將事務處理執(zhí)行結果反饋回來源系統(tǒng)等等。理論上，使用相關數(shù)據(jù)庫工具可以向數(shù)據(jù)庫的數(shù)據(jù)表中直接批量寫入數(shù)據(jù)，但這樣做無法對寫入的數(shù)據(jù)進行正確性、合規(guī)性校驗，無法保證寫入數(shù)據(jù)的質量以及對存在問題進行有效管理。為此，ORACLE提供了接口表InterfaceTable作為“中間表”過渡，并在此基礎上，根據(jù)*些業(yè)務需要提供業(yè)務視圖BusinessView，以便對導入的數(shù)據(jù)進行修改、更正、重新導入等等管理。如下圖35所示“OpenInterfaceDiagram”：更進一步，ORACLE將*些數(shù)據(jù)的導入導出功能進行封裝，成為一個應用程序可以調用的接口（API），以實現(xiàn)在各模塊之間以及部模塊與外部系統(tǒng)之間的數(shù)據(jù)與流程集成。如下圖36所示“OpenApplicationProgrammaticInterface（API）Diagram”：開放接口（API）的基本工作模式分為兩個階段：一是先將來源數(shù)據(jù)裝入（Load）接口表。如果是在兩個應用系統(tǒng)之間，這通常是由專用的裝入程序完成，例如EBS部采購申請要轉成部銷售訂單，需先運行“創(chuàng)建部銷售訂單流程”，以便將部采購申請發(fā)送并插入訂單管理系統(tǒng)的接口表。如果是從*些電子表格如E*CEL等導入，則需要先使用專門的SQL*Load工具將數(shù)據(jù)格式轉換后直接插入相關接口表，例如要通過物料的E*CEL數(shù)據(jù)表直接批量裝入Item數(shù)據(jù)，必須先通過SQL*Load工具如DataLoad等將來源數(shù)據(jù)插入Item數(shù)據(jù)接口表。在將數(shù)據(jù)插入接口表的過程中是否對數(shù)據(jù)進行校驗（或是在將接口表數(shù)據(jù)導入正是表時再校驗），取決于系統(tǒng)各應用模塊的不同設計；二是系統(tǒng)將存在于接口表中的數(shù)據(jù)導入正式的業(yè)務數(shù)據(jù)表，如EBS訂單管理模塊的“訂