系列之三：ORACLE EBS 系統(tǒng)應用基礎概述(B)參考模板

1、系列之三：ORACLE EBS 系統(tǒng)應用基礎概述（B）Oracle ERP 2010-08-09 16:23:59 閱讀133 評論0   字號：大中小 訂閱 ORACLE EBS 系統(tǒng)應用基礎概述  三、事務處理（Transaction） 四、并發(fā)流程（Current Process） 五、文件夾（Folder） 六、彈性域（Flex field） 七、值集與查找代碼（Value Set and Lookup Code） 八、配置文件（Profile） 九、單據編號（Document

2、 Sequence） 十、工作流（Workflow） 十一、預警（Alert） 十二、應用開放接口（Open Interface and API） 十三、結語（注：網站批量發(fā)圖有問題，上傳后顯示不清楚。點擊圖片打開后，質量尚可） 三、事務處理（Transaction）如果說上述EBS的“表單與查詢”的系統(tǒng)設計體現(xiàn)的正是“從業(yè)務到技術”，比較容易理解與掌握，那么，所謂“事務處理”則是體現(xiàn)系統(tǒng)“從技術再到業(yè)務”的一個典范，相對而言，理解起來要困難很多，原因是無法直接在手工業(yè)務模式下找到相對應的處理方式與過程。以庫房接收采購物料為例，假定公司規(guī)定必須

3、嚴格按PO來接收，并且公司為了嚴格控制庫存水平，接收必須小批量、多批次，則庫房人員就可能需要針對同一個PO在短時期內開出N多張的“入庫單”，工作量很大。為了減少工作量、提高效率，庫房人員可能會在供應商每次送貨時，僅在找出來的PO紙面單據上只簡單地做一個數量標識，最后累積起來匯總開一張“入庫單”。但這種“圖省事”的做法顯然是一種“很不規(guī)范”的處理方式，雖可以提高工作效率，卻會因為容易帶來很多其它管理問題而在實際工作中不被允許。ORACLE 系統(tǒng)通過提供一個“事務處理”工作界面則很簡單地解決了上述難題。如下圖9所示采購接收的事務處理工作界面：1 / 22類似于“收貨時直接在PO紙面單據上簡單地做數

4、量標識”，每次供應商送貨來時，庫存人員只需在系統(tǒng)中查找出對應的PO，簡單地輸入送貨數量并保存，則系統(tǒng)會在后臺自動生成“事務處理記錄”(等同于是“入庫單”)。對于系統(tǒng)來說，這種處理方式技術上實現(xiàn)非常容易，但卻大大減少了操作人員的工作量，有效地解決了由于小批量、多批次所帶來的效率問題。ORACLE的各業(yè)務模塊，大量地采用了上述類似的“事務處理”系統(tǒng)工作方式，不僅保證了系統(tǒng)高度的數據集成性，而且對于系統(tǒng)各業(yè)務環(huán)節(jié)的流程處理也保證了高度的連貫性與集成性。例如OM系統(tǒng)的發(fā)貨處理、WIP系統(tǒng)的領料與入庫處理等等。系統(tǒng)中所提供的事務處理工作界面，有些可能會以“××工作臺”（Workben

5、ch）來命名之（這取決于不同模塊系統(tǒng)設計人員的個人偏好）。更進一步，系統(tǒng)對于某些“業(yè)務流程”類表單，例如“銷售訂單、發(fā)票”等，還在表單界面直接提供一個名曰“活動”（Action）的按鈕（Button），該按鈕包含豐富的業(yè)務處理功能（不僅僅是輸入數據），以便用戶（User）對表單內容作各種操作處理或獲取相關信息。如下圖10所示，銷售訂單界面的“活動”按鈕：此外，ORACLE EBS在某些業(yè)務流程單據之間，也提供了類似的事務處理工作界面，以幫助用戶方便地實現(xiàn)業(yè)務單據的轉換和業(yè)務流程的銜接。如下圖11所示的采購申請PR到采購訂單PO的所謂“自動創(chuàng)建”（Autocreate）功能。 

6、0;   對于企業(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)方式。曾有一網友通過MSN向筆者發(fā)問：“EBS的WIP 事務處理界面是否要手工輸入item？”看起來這個問題似乎很“幼稚”，但對于很多剛開始接觸EBS

7、或過去用慣國內產品的人來說，由于不了解或不習慣EBS的“事務處理”系統(tǒng)實現(xiàn)方式，會不自覺、想當然地將所有EBS的FORM界面都當成具有“實體”作用、通?？梢詫埫鎲螕摹皹I(yè)務表單”來看待，才會發(fā)出這樣的疑問。 四、并發(fā)流程（Current Process）從系統(tǒng)實現(xiàn)角度來看，“并發(fā)流程”或“并發(fā)處理”是較之“事務處理”技術味更濃的一個概念，它也是業(yè)務出身、不太懂“技術”的人學習掌握EBS系統(tǒng)的難點之一。但實際上，對于今天的計算機系統(tǒng)而言，“并發(fā)”其實是一個再普通不過的應用，例如我們邊在電腦上寫文章邊聽音樂等等。ORACLE 弄得有點學究氣，相對于“聯(lián)機事務”或“聯(lián)機處理”方式，并發(fā)

8、處理稱為“后臺事務”或“后臺處理”似乎更好理解一些。以企業(yè)的實際業(yè)務過程為例，在手工業(yè)務模式下，庫房接收了物料并開具“入庫單”后，庫房人員后續(xù)必須還要做的一項工作是：“手工”將入庫單上的物料接收信息逐份“過賬”到“庫存物料信息臺賬”上去，以更新庫存物料的余額數量。在EBS系統(tǒng)中，這項枯燥、乏味的工作就完全由系統(tǒng)代勞了，系統(tǒng)通過后臺運行的一個名為“接收事務處理處理器”的并發(fā)程序，聯(lián)機立即或成批周期進行處理，在不影響用戶做其它工作的同時，高度精確地完成著原本需要人工去做的“過賬登記”任務，并且手工模式下過賬之后為檢查錯漏而需經常進行的“對賬”工作也變得根本就不再需要?！安l(fā)處理”是EBS系統(tǒng)不可或

9、缺的一個重要組成部分，上述“物料接收”的并發(fā)處理只是一個很簡單的應用。在EBS中，“并發(fā)”按處理的對象主要可分為兩類：一類是“流程事務”，一類是“報表事務”。系統(tǒng)統(tǒng)一以“提交請求（Request）”的方式提供人機交互。如下圖12所示“查詢或提交請求”：對于每一個并發(fā)“請求”，系統(tǒng)都可以允許輸入相關參數，并計劃其是按某一周期運行，還是立即或預定在未來某一時刻運行。系統(tǒng)預置了大量的為業(yè)務流程服務的“流程事務”類后臺事務處理程序，同時還提供了部分可供企業(yè)參考的“報表事務”類輸出請求。用戶使用系統(tǒng)提供的開發(fā)工具，也可以很容易地自定義某些“個性化”的后臺程序或報表輸出，其運行管理和使用方式與系統(tǒng)預置的并

10、發(fā)程序幾乎完全相同。“并發(fā)處理”相對于用戶來說，實際上是屬于在系統(tǒng)后臺運行的相關工作，剛剛開始接觸的人可能會對之覺得陌生或使用不順手，原因主要是手工業(yè)務或低檔的管理軟件根本沒有這種工作處理方式。這就好比相對于交通主要還是靠騎車或步行的小城鎮(zhèn)，今天對于生活在現(xiàn)代化大城市的人們來說，往來穿梭的地鐵、周而復始的公交、招手即停的出租車已經成為全部生活不可或缺的一部分，它們就像城市的“血管”脈動一樣，奔流不息，維持著城市生命的運轉，生機勃勃。EBS的“并發(fā)處理”所承擔的角色或所起的作用正與之基本類似。EBS并發(fā)處理的另一項重要特性是其“系統(tǒng)級”的可計劃、可管理、可控制特性，系統(tǒng)通過定義“并發(fā)管理器”、“

11、請求集”等功能應用，對所有需要在后臺運行的并發(fā)程序進行管理調度，以平衡系統(tǒng)負載，保證系統(tǒng)有高的使用性能。如下圖13所示，定義“并發(fā)管理器”（包括運行規(guī)則、工作班次等等。這類似于城市里的交通調度與控制）關于“流程事務”類的并發(fā)請求，因為涉及到系統(tǒng)各業(yè)務模塊的具體功能應用問題，這里不便多講。以下主要來談一談“報表事務”類的并發(fā)請求問題。有網友曾抱怨說，“ORACLE的報表功能不好用，出一個簡單的報表都要到后臺去提交一個請求，輸出的是一個文本，太麻煩。系統(tǒng)提供的標準報表，內容不能滿足企業(yè)要求，不符合國人的使用習慣”。這種說法可能是因為受某些國內產品的影響而產生的誤解。目前國內的主流ERP系統(tǒng)，對于“

12、報表”基本上采取的是類似“查詢”的實現(xiàn)方式。這種“查詢式報表”雖然方便了用戶使用，但卻惹出了無窮的麻煩。首先，報表是一種極端“個性化”的東西，不同的企業(yè)由于管理層次不一樣，關注的管理重點也不同，針對同樣的問題所要求的報表也會不同。即使同一個企業(yè)在不同的發(fā)展階段，所要求的報表內容也不會相同，因此即使已經使用ERP若干年的企業(yè)，不斷地開發(fā)新的（管理）報表，也是很正常的事情。如果ERP系統(tǒng)將報表功能“顯式化”，在系統(tǒng)標準功能中提供查詢條件控件及輸出結果視圖，則意味著系統(tǒng)提供的這個所謂報表功能必須符合所有企業(yè)的使用要求，而實際這是不可能實現(xiàn)的。在這種情況下，企業(yè)就會理所當然地認為這是ERP廠商的責任，

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

14、面，而且也為企業(yè)IT系統(tǒng)維護人員提供了系統(tǒng)可管理、可干預的便利。這實際上正是ORACLE系統(tǒng)的靈活性與功能強大之處（SAP也類似）。有網友針對國內某些廠商聲稱自己的ERP是“高端”產品時，質疑“連并發(fā)都沒有，能算高端嗎？”實際上是說到了要害。一個連“電梯”都沒有的高樓怎能算得上是現(xiàn)代化的大廈呢！ORACLE系統(tǒng)大量使用后臺“并發(fā)處理”程序，實現(xiàn)了系統(tǒng)用戶的流程操作在“空間與時間”上的分離，免去了操作人員的無效等待時間。操作人員提交的并發(fā)請求在后臺運行的同時，并不影響其處理其它系統(tǒng)事務，這樣可以大大提高用戶的工作效率以及使用的方便性。“并發(fā)”之于ORACLE EBS系統(tǒng)好比人體內的“心臟”一樣重

15、要，它是系統(tǒng)實現(xiàn)高度的數據集成與流程集成的核心工具，是企業(yè)依賴計算機系統(tǒng)實現(xiàn)業(yè)務運作與管理控制自動化的一個技術體現(xiàn)。 五、文件夾（Folder）     這又是一個ORACLE弄得有點學究氣的概念（可能也有中文翻譯不到位的原因）。所謂“文件夾”（Folder）功能，簡單來說就是稍有點IT系統(tǒng)使用經驗的人都明白的“用戶自定義查詢輸出界面視圖”功能。系統(tǒng)（可以）提供的查詢條件控件或查詢輸出結果視圖的字段是如此之多，其中有很多可能并不是用戶希望顯示出來的，每一個系統(tǒng)用戶User可以根據個人的工作需要或偏好，使用文件夾功能自由地定義自己可見的UI界面。

16、ORACLE 系統(tǒng)為幾乎所有重要的表單、查詢條件控件及查詢結果輸出視圖都提供了文件夾功能，這也是ORACLE系統(tǒng)靈活性、易用性、方便性之所在。如下圖14所示采購PR的查詢：  六、彈性域（Flexfield）所謂“彈性域”技術是人們每當提及ORACLE 產品技術的先進性時總會首先想到的一個東西，也是很多初學者（尤其是“業(yè)務出身”的人）開始接觸時可能會感到有點“發(fā)怵”的東西，原因之一是它的技術味比較濃。但實際上，如果從應用的角度去理解，它也并無多少神秘之處。前面我們已經講到“表單”是組成EBS系統(tǒng)的最重要基本元素之一，每個表單都由“表頭與表體行”組成。系統(tǒng)在UI界面中所展示的

17、是表單的“標準顯示”，盡管這個“標準顯示”可能已經包含了適合各行各業(yè)所使用的那些常用信息字段（Segment），但對于不同企業(yè)來說，總可能會出現(xiàn)需要添加一些本企業(yè)特殊需要的信息字段的情況，這從系統(tǒng)角度通常稱為“自定義表單字段”。EBS的所謂“彈性域”技術實際就是為了解決這一常見的系統(tǒng)應用問題而應運而生，對于初學者來說，把它簡單地理解為“自定義表單字段”就容易多了。如下圖15與圖16所示的采購申請PR表單，在表頭部分“標準顯示”的UI界面（角落）中有一個“方框”（“【 】”），在表體行部分的末端也有一個“方框”（“【 】”）。系統(tǒng)用戶在需要輸入有關特殊信息時點擊“方框”，系統(tǒng)便會分別彈出一個包含

18、若干個自定義信息行（相當于為表單擴展了若干列的字段）的界面框，以供用戶輸入某些特殊信息。 圖15所示采購申請PR表頭的“彈性域”方框與彈出界面。用戶可在其中輸入關于該PR的某些自定義補充信息，如“申請部門、申請用途”等等。圖16所示采購申請PR表體行的“彈性域”方框與彈出界面。用戶可在其中輸入關于該PR行的某些自定義補充信息，如關于所申購物料的“長寬高、顏色”等等。要注意的是，上述“自定義表單字段”是“系統(tǒng)級”而非“用戶級”的，也就是說只有系統(tǒng)管理員才能做相關設置，而普通用戶只能在實際工作中使用。EBS中所使用到的“彈性域”分為兩類：一類是所謂“鍵彈性域”（Key Flexfield

19、），一類是所謂“說明性彈性域”（Descriptive Flexfield）。而上述圖15與圖16采購申請PR中的“彈性域”就是典型的“說明性彈性域”的范例。系統(tǒng)中幾乎所有的重要表單（尤其是業(yè)務流程類表單）都具有這種“自定義”功能的說明性彈性域，系統(tǒng)說明性彈性域總數有二、三千之多。稱之為“說明性”（Descriptive）取其對標準表單字段作補充說明之意。用戶在說明性彈性域中輸入的字段信息，通常只能作為統(tǒng)計分析、出報表使用，不參與系統(tǒng)業(yè)務流程的構建，系統(tǒng)（應用程序）不對之在表單之間作跟蹤、追溯。如下圖17所示是采購申請PR表頭“說明性彈性域”的系統(tǒng)定義界面：     系統(tǒng)所謂“鍵彈性域”的情況較之“說明性彈性域”就復雜、嚴格得多，原因是它們參與業(yè)務流程的構建，系統(tǒng)的應用程序要對之進行跟蹤、追溯，其作用當然非常“關鍵”（Key），故數量也比較少，在整個EBS系統(tǒng)中總數不過約35個