ORACLE EBS 系統應用基礎概述
三、事務處理（Transaction）
四、併發流程（Current Process）
五、文件夾（Folder）
六、彈性域（Flex field）
七、值集與查找代碼（Value Set and Lookup Code）
八、配置文件（Profile）
九、單據編號（Document Sequence）
十、工作流（Workflow）
十一、預警（Alert）
十二、應用開放接口（Open Interface and API）
十三、結語
（注：網站批量發圖有問題，上傳後顯示不清楚。點擊圖片打開後，質量尚可）
如果說上述EBS的“表單與查詢”的系統設計體現的正是“從業務到技術”，比較容易理解與掌握，那麼，所謂“事務處理”則是體現系統“從技術再到業務”的一個典範，相對而言，理解起來要困難很多，原因是無法直接在手工業務模式下找到相對應的處理方式與過程。
以庫房接收採購物料爲例，假定公司規定必須嚴格按PO來接收，並且公司爲了嚴格控制庫存水平，接收必須小批量、多批次，則庫房人員就可能需要針對同一個PO在短時期內開出N多張的“入庫單”，工作量很大。爲了減少工作量、提高效率，庫房人員可能會在供應商每次送貨時，僅在找出來的PO紙面單據上只簡單地做一個數量標識，最後累積起來彙總開一張“入庫單”。但這種“圖省事”的做法顯然是一種“很不規範”的處理方式，雖可以提高工作效率，卻會因爲容易帶來很多其它管理問題而在實際工作中不被允許。
ORACLE 系統通過提供一個“事務處理”工作界面則很簡單地解決了上述難題。如下圖9所示採購接收的事務處理工作界面：
類似於“收貨時直接在PO紙面單據上簡單地做數量標識”，每次供應商送貨來時，庫存人員只需在系統中查找出對應的PO，簡單地輸入送貨數量並保存，則系統會在後臺自動生成“事務處理記錄”(等同於是“入庫單”)。對於系統來說，這種處理方式技術上實現非常容易，但卻大大減少了操作人員的工作量，有效地解決了由於小批量、多批次所帶來的效率問題。
ORACLE的各業務模塊，大量地採用了上述類似的“事務處理”系統工作方式，不僅保證了系統高度的數據集成性，而且對於系統各業務環節的流程處理也保證了高度的連貫性與集成性。例如OM系統的發貨處理、WIP系統的領料與入庫處理等等。系統中所提供的事務處理工作界面，有些可能會以“××工作臺”（Workbench）來命名之（這取決於不同模塊系統設計人員的個人偏好）。
更進一步，系統對於某些“業務流程”類表單，例如“銷售訂單、發票”等，還在表單界面直接提供一個名曰“活動”（Action）的按鈕（Button），該按鈕包含豐富的業務處理功能（不僅僅是輸入數據），以便用戶（User）對錶單內容作各種操作處理或獲取相關信息。如下圖10所示，銷售訂單界面的“活動”按鈕：
此外，ORACLE EBS在某些業務流程單據之間，也提供了類似的事務處理工作界面，以幫助用戶方便地實現業務單據的轉換和業務流程的銜接。如下圖11所示的採購申請PR到採購訂單PO的所謂“自動創建”（Autocreate）功能。
對於企業的一個系統用戶User（事務處理型用戶）來說，掌握了與自己工作相關的表單、表單查詢、事務處理，就基本上掌握了EBS的系統使用，系統就不再難懂難用。EBS中的“事務處理”在業務流程表單內部解決了“人與系統”的統一問題，在業務流程表單之間解決了“業務與業務、業務與系統”的統一問題。從“純技術”的系統實現角度來看，它也沒有什麼高深莫測的地方。
很奇怪也很遺憾的是，迄今國內主流ERP產品的系統中，還很少看到這種系統實現方式。曾有一網友通過MSN向筆者發問：“EBS的WIP 事務處理界面是否要手工輸入item？”看起來這個問題似乎很“幼稚”，但對於很多剛開始接觸EBS或過去用慣國內產品的人來說，由於不瞭解或不習慣EBS的“事務處理”系統實現方式，會不自覺、想當然地將所有EBS的FORM界面都當成具有“實體”作用、通常可以對應紙面單據的“業務表單”來看待，纔會發出這樣的疑問。
從系統實現角度來看，“併發流程”或“併發處理”是較之“事務處理”技術味更濃的一個概念，它也是業務出身、不太懂“技術”的人學習掌握EBS系統的難點之一。但實際上，對於今天的計算機系統而言，“併發”其實是一個再普通不過的應用，例如我們邊在電腦上寫文章邊聽音樂等等。ORACLE 弄得有點學究氣，相對於“聯機事務”或“聯機處理”方式，併發處理稱爲“後臺事務”或“後臺處理”似乎更好理解一些。
以企業的實際業務過程爲例，在手工業務模式下，庫房接收了物料並開具“入庫單”後，庫房人員後續必須還要做的一項工作是：“手工”將入庫單上的物料接收信息逐份“過賬”到“庫存物料信息臺賬”上去，以更新庫存物料的餘額數量。在EBS系統中，這項枯燥、乏味的工作就完全由系統代勞了，系統通過後臺運行的一個名爲“接收事務處理處理器”的併發程序，聯機立即或成批週期進行處理，在不影響用戶做其它工作的同時，高度精確地完成着原本需要人工去做的“過賬登記”任務，並且手工模式下過賬之後爲檢查錯漏而需經常進行的“對賬”工作也變得根本就不再需要。
“併發處理”是EBS系統不可或缺的一個重要組成部分，上述“物料接收”的併發處理只是一個很簡單的應用。在EBS中，“併發”按處理的對象主要可分爲兩類：一類是“流程事務”，一類是“報表事務”。系統統一以“提交請求（Request）”的方式提供人機交互。如下圖12所示“查詢或提交請求”：
對於每一個併發“請求”，系統都可以允許輸入相關參數，並計劃其是按某一週期運行，還是立即或預定在未來某一時刻運行。系統預置了大量的爲業務流程服務的“流程事務”類後臺事務處理程序，同時還提供了部分可供企業參考的“報表事務”類輸出請求。用戶使用系統提供的開發工具，也可以很容易地自定義某些“個性化”的後臺程序或報表輸出，其運行管理和使用方式與系統預置的併發程序幾乎完全相同。
“併發處理”相對於用戶來說，實際上是屬於在系統後臺運行的相關工作，剛剛開始接觸的人可能會對之覺得陌生或使用不順手，原因主要是手工業務或低檔的管理軟件根本沒有這種工作處理方式。這就好比相對於交通主要還是靠騎車或步行的小城鎮，今天對於生活在現代化大城市的人們來說，往來穿梭的地鐵、週而復始的公交、招手即停的出租車已經成爲全部生活不可或缺的一部分，它們就像城市的“血管”脈動一樣，奔流不息，維持着城市生命的運轉，生機勃勃。EBS的“併發處理”所承擔的角色或所起的作用正與之基本類似。
EBS併發處理的另一項重要特性是其“系統級”的可計劃、可管理、可控制特性，系統通過定義“併發管理器”、“請求集”等功能應用，對所有需要在後臺運行的併發程序進行管理調度，以平衡系統負載，保證系統有高的使用性能。如下圖13所示，定義“併發管理器”（包括運行規則、工作班次等等。這類似於城市裏的交通調度與控制）
關於“流程事務”類的併發請求，因爲涉及到系統各業務模塊的具體功能應用問題，這裏不便多講。以下主要來談一談“報表事務”類的併發請求問題。有網友曾抱怨說，“ORACLE的報表功能不好用，出一個簡單的報表都要到後臺去提交一個請求，輸出的是一個文本，太麻煩。系統提供的標準報表，內容不能滿足企業要求，不符合國人的使用習慣”。這種說法可能是因爲受某些國內產品的影響而產生的誤解。目前國內的主流ERP系統，對於“報表”基本上採取的是類似“查詢”的實現方式。這種“查詢式報表”雖然方便了用戶使用，但卻惹出了無窮的麻煩。
首先，報表是一種極端“個性化”的東西，不同的企業由於管理層次不一樣，關注的管理重點也不同，針對同樣的問題所要求的報表也會不同。即使同一個企業在不同的發展階段，所要求的報表內容也不會相同，因此即使已經使用ERP若干年的企業，不斷地開發新的（管理）報表，也是很正常的事情。如果ERP系統將報表功能“顯式化”，在系統標準功能中提供查詢條件控件及輸出結果視圖，則意味着系統提供的這個所謂報表功能必須符合所有企業的使用要求，而實際這是不可能實現的。在這種情況下，企業就會理所當然地認爲這是ERP廠商的責任，廠商必須負責解決。目前許多國內ERP廠商產品研發的一項重要內容就是窮於應付爲企業開發各種查詢式管理報表，這簡直是等於自掘火坑，陷進去無法自拔，
其次，查詢式報表如果內容複雜、耗用系統資源比較高，則用戶隨便自由使用， 而IT系統維護人員對“聯機式”查詢無法進行有效管理、干預，將可能嚴重影響系統整體性能，導致其他用戶無法進行正常工作。從這個角度來看，目前國內的主流ERP產品實際上還沒有真正系統意義上的“報表”功能，只有不加節制、擴大化了的“查詢”功能。系統如此處理極不明智。
ORACLE 將“報表”功能以併發請求的形式放到後臺去處理，不僅有效地解決了“報表”的個性化問題，分清了ERP廠商與企業的責任界面，而且也爲企業IT系統維護人員提供了系統可管理、可干預的便利。這實際上正是ORACLE系統的靈活性與功能強大之處（SAP也類似）。有網友針對國內某些廠商聲稱自己的ERP是“高端”產品時，質疑“連併發都沒有，能算高端嗎？”實際上是說到了要害。一個連“電梯”都沒有的高樓怎能算得上是現代化的大廈呢！
ORACLE系統大量使用後臺“併發處理”程序，實現了系統用戶的流程操作在“空間與時間”上的分離，免去了操作人員的無效等待時間。操作人員提交的併發請求在後臺運行的同時，並不影響其處理其它系統事務，這樣可以大大提高用戶的工作效率以及使用的方便性。“併發”之於ORACLE EBS系統好比人體內的“心臟”一樣重要，它是系統實現高度的數據集成與流程集成的核心工具，是企業依賴計算機系統實現業務運作與管理控制自動化的一個技術體現。
這又是一個ORACLE弄得有點學究氣的概念（可能也有中文翻譯不到位的原因）。所謂“文件夾”（Folder）功能，簡單來說就是稍有點IT系統使用經驗的人都明白的“用戶自定義查詢輸出界面視圖”功能。系統（可以）提供的查詢條件控件或查詢輸出結果視圖的字段是如此之多，其中有很多可能並不是用戶希望顯示出來的，每一個系統用戶User可以根據個人的工作需要或偏好，使用文件夾功能自由地定義自己可見的UI界面。ORACLE 系統爲幾乎所有重要的表單、查詢條件控件及查詢結果輸出視圖都提供了文件夾功能，這也是ORACLE系統靈活性、易用性、方便性之所在。如下圖14所示採購PR的查詢：
所謂“彈性域”技術是人們每當提及ORACLE 產品技術的先進性時總會首先想到的一個東西，也是很多初學者（尤其是“業務出身”的人）開始接觸時可能會感到有點“發怵”的東西，原因之一是它的技術味比較濃。但實際上，如果從應用的角度去理解，它也並無多少神祕之處。
前面我們已經講到“表單”是組成EBS系統的最重要基本元素之一，每個表單都由“表頭與表體行”組成。系統在UI界面中所展示的是表單的“標準顯示”，儘管這個“標準顯示”可能已經包含了適合各行各業所使用的那些常用信息字段（Segment），但對於不同企業來說，總可能會出現需要添加一些本企業特殊需要的信息字段的情況，這從系統角度通常稱爲“自定義表單字段”。EBS的所謂“彈性域”技術實際就是爲了解決這一常見的系統應用問題而應運而生，對於初學者來說，把它簡單地理解爲“自定義表單字段”就容易多了。
如下圖15與圖16所示的採購申請PR表單，在表頭部分“標準顯示”的UI界面（角落）中有一個“方框”（“【 】”），在表體行部分的末端也有一個“方框”（“【 】”）。系統用戶在需要輸入有關特殊信息時點擊“方框”，系統便會分別彈出一個包含若干個自定義信息行（相當於爲表單擴展了若干列的字段）的界面框，以供用戶輸入某些特殊信息。
圖15所示採購申請PR表頭的“彈性域”方框與彈出界面。用戶可在其中輸入關於該PR的某些自定義補充信息，如“申請部門、申請用途”等等。
圖16所示採購申請PR表體行的“彈性域”方框與彈出界面。用戶可在其中輸入關於該PR行的某些自定義補充信息，如關於所申購物料的“長寬高、顏色”等等。
要注意的是，上述“自定義表單字段”是“系統級”而非“用戶級”的，也就是說只有系統管理員才能做相關設置，而普通用戶只能在實際工作中使用。EBS中所使用到的“彈性域”分爲兩類：一類是所謂“鍵彈性域”（Key Flexfield），一類是所謂“說明性彈性域”（Descriptive Flexfield）。而上述圖15與圖16採購申請PR中的“彈性域”就是典型的“說明性彈性域”的範例。
系統中幾乎所有的重要表單（尤其是業務流程類表單）都具有這種“自定義”功能的說明性彈性域，系統說明性彈性域總數有二、三千之多。稱之爲“說明性”（Descriptive）取其對標準表單字段作補充說明之意。用戶在說明性彈性域中輸入的字段信息，通常只能作爲統計分析、出報表使用，不參與系統業務流程的構建，系統（應用程序）不對之在表單之間作跟蹤、追溯。如下圖17所示是採購申請PR表頭“說明性彈性域”的系統定義界面：
系統所謂“鍵彈性域”的情況較之“說明性彈性域”就複雜、嚴格得多，原因是它們參與業務流程的構建，系統的應用程序要對之進行跟蹤、追溯，其作用當然非常“關鍵”（Key），故數量也比較少，在整個EBS系統中總數不過約35個。其中用得最多的例如“物料類別彈性域”、“會計科目彈性域”等等。與“說明性彈性域”屬於表單的用戶“補充字段”不同的是，“鍵彈性域”本身就屬於表單的系統標準字段，這個表單標準字段用戶輸入的不是簡單的一個信息，而是具有某種可在系統層面“自定義結構”的一組信息。
如下圖18所示採購申請PR表單界面中“物料類別”字段，用戶輸入時將彈出系統已經定義的“物料類別鍵彈性域”界面，以供用戶（選擇）輸入具體信息：
如下圖19所示是系統層面定義“鍵彈性域”的界面。全部35個鍵彈性域主要集中在庫存、總賬、資產、人力資源等核心業務模塊中定義，其它模塊只是應用時調用。鍵彈性域由於其系統地位與重要性，其定義方式與內容也要比說明性彈性域來得複雜。
對於每一個“鍵彈性域”，系統允許定義若干個不同結構的字段組合，以使用在系統中的不同場合（例如不同組織或帳套等等）。如下圖20所示，表達了“會計科目彈性域”可以有若干不同結構（代碼）的情況，圖中“Vision China”的5段式結構，可以和其它國家或地區的完全不同。
ORACLE的彈性域應用技術作爲系統最重要的基礎元素之一，歷經多年發展，其應用已遠非上述所例舉的“表單字段信息”那麼簡單，它事實上已經發展成爲一種重要的方法論。系統基於（鍵）彈性域的某些重要技術特性，逐步發展出了諸多使用靈活、功能強大的應用實現方式。（相關討論必須結合具體的系統應用來進行，這裏不再贅述）。