ORACLE_EBS_系統(tǒng)應用基礎概述

1、系列之三：ORACLE EBS 系統(tǒng)應用基礎概述一、前言二、表單與查詢(Form and Summary)三、事務處理(Transaction)四、并發(fā)流程(Current ProcesS)五、文件夾(Folder)六、彈性域(Flex field)七、值集與查找代碼(Value Set and Lookup Code八、配置文件(Profile)九、單據(jù)編號(Document Sequenee)十、工作流(Workflow)十一、預警(Alert)十二、應用開放接口( Ope n In terface and API)十三、結語一、前言有網(wǎng)友在論壇發(fā)帖驚呼：好不容易把EBS系統(tǒng)安裝好了，進去

2、一看傻眼了， 不知道從哪兒下手發(fā)出驚嘆的這位網(wǎng)友所遇到的問題，實際上也是很多人曾經(jīng)遇到或正在遇到的問題。長期以來，國內(nèi)的非專業(yè)人士(例如媒體)提及SAP或ORACLE勺時候，有不少人喜歡用“超級難懂”來形容。那么，國內(nèi)專業(yè)人士的 看法又如何呢筆者所聽到過的最“雷”的說法來自一位國內(nèi)軟件研發(fā)的高層主管： SAP/ORACL太復雜了，其背后的東西、深層次的東西，我們永遠不可能搞懂！真是太不可思議。一方面，國內(nèi)的業(yè)內(nèi)人士幾乎眾口一詞，我們與SAP/ORACL相比，技術上沒有多大差距，平臺工具都是公開的，也沒有什么奧 秘可言。SAP/ORACL由于產(chǎn)品做得早，我們在技術上甚至還有后發(fā)優(yōu)勢。另一 方面，

3、我們也常常聽到國內(nèi)有些人將 SAP/ORACL神秘化，認為其包含“復雜的、 深刻的管理思想”，是德國人/美國人的東西，我們中國人的企業(yè)管理水平低， 用不了是正常的。國情不同，模式不同，中國人應該尋找一條適合自己的道路！ 真的是這樣嗎SAP/ORACL產(chǎn)品真的是那么神秘、高不可攀今天專業(yè)從事 ERP工作的人員，若從個人背景角度來看，通常可以劃分為“技術出身”與“業(yè) 務出身”兩類?！凹夹g出身”的人在學習熟悉系統(tǒng)方面可能有一定優(yōu)勢，但與用 戶溝通交流的過程中，在迅速準確把握業(yè)務本質(zhì)要領方面可能存在一定困難；而“業(yè)務出身”的人，對于與用戶的業(yè)務溝通交流可能感覺比較容易， 但在研究掌 握系統(tǒng)方面則可能相

4、對困難一些。根據(jù)筆者曾經(jīng)做過的調(diào)查統(tǒng)計，國內(nèi)ERP從業(yè) 人員中“技術出身”的人似乎占了絕大多數(shù)。ORACLE EB作為一個有百多個業(yè)務應用模塊、高度集成的企業(yè)管理軟件系 統(tǒng)，它是現(xiàn)代計算機技術與企業(yè)管理實踐的高度融合。它不是模仿企業(yè)手工業(yè)務 過程的“電算化”簡單再現(xiàn)，或許正是讓很多人感到其“難懂難用”的根本原因 所在。因此，“從實踐中來，再到實踐中去”，或曰“從業(yè)務透視技術，再從技 術回歸業(yè)務”也許正是我們一步一步叩開ORACLE EB的大門，徜徉其間并游刃 有余的方法論。（這里的所謂“技術”意指“系統(tǒng)實現(xiàn)”）。業(yè)內(nèi)對于專業(yè)從事ERP工作的人員，大致有以下三種分類：一類是所謂“技 術顧問”，對

5、于這些人來說，掌握相應的軟件開發(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)、只會“紙上談 兵”的忽悠型“管理顧問”）。實際

6、工作中，上述三類人員前后之間可能并無明確的劃分界線，但大體上 有一個隨著系統(tǒng)認識水平的提高以及業(yè)務運作經(jīng)驗的積累，由低到高發(fā)展的過 程。因此，如何實現(xiàn)“從業(yè)務角度去透視技術，從技術角度去回歸業(yè)務 ”是業(yè)內(nèi) 人員所面對的永恒命題，能達到業(yè)務與技術的“融會貫通”則是追求的最高境界。 為此，本篇將從博大精深的 ORACLE EB系統(tǒng)最基本的應用基礎組成元素開始， 從業(yè)務一技術一業(yè)務，探討讓有些人高深莫測、妄自菲薄的所謂“其背后的東西、 深層次的東西”到底是些什么，以便能夠最終尋找到幫助我們登堂入室的鑰匙與 途徑。二、表單與查詢（Form and Summary）企業(yè)在手工模式下的業(yè)務運作過程中， 總

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

8、主要就是“單據(jù)新增與單據(jù)查詢”這兩項。其單據(jù) 在系統(tǒng)中的格式和內(nèi)容與紙面單據(jù)是如此近似相像，以致于大多數(shù)企業(yè)人員學習掌握它們不會感覺有多大困難。在ORACLE EB的每個模塊中，同樣也是要用到各種單據(jù)（Form）來錄入或 保存數(shù)據(jù)（對應于后臺數(shù)據(jù)庫中的“表”），并為之提供相應的查詢功能，但 ORACLE的系統(tǒng)單據(jù)已經(jīng)不是紙面單據(jù)的簡單再現(xiàn)。 系統(tǒng)的UI界面中可以見到 各種“表單”（據(jù)統(tǒng)計約有3000多種），它們不僅不同于紙面單據(jù)，相互之間 的性質(zhì)及查詢方式差別也可能很大。歸納起來，ORACL各模塊中的“表單”按性質(zhì)與作用大體可分為三大類：第一類是“業(yè)務流程”類表單例如“銷售訂單SO采購訂單PO

9、制造工單 WO、發(fā)票INVOICE等等，它 們有一個共同的特點是參與核心業(yè)務流程的運轉，是核心業(yè)務流程的一個環(huán)節(jié)、 不可或缺。這一點顯然也是和實際的企業(yè)業(yè)務過程是高度相對應的。作為業(yè)務的原始憑據(jù)憑證，它們是如此重要，即使是 IT系統(tǒng)化之后，大多數(shù)企業(yè)可能還是 要將它們的紙面形態(tài)予以保存、歸檔。在ORACLE EBS，“業(yè)務流程”類表單種類其實很少（每個模塊一般僅一、 兩個左右），但每種單據(jù)隨時間日積月累，業(yè)務數(shù)據(jù)量可能很大。業(yè)務流程類表 單是系統(tǒng)中最重要的表單，與紙面單據(jù)相比，內(nèi)容更為豐富和復雜，格式也有很 大的變化，它充分利用了數(shù)據(jù)庫技術所提供的可容納性、 可擴展性以及使用便利性。它來源于業(yè)

10、務實踐，但經(jīng)高度抽象并融入最新科技成就后， 其功能與作用又 遠遠高于原始的紙面單據(jù)。如圖1的PO表單：版本任務說明OE2G82MI5C. J5ES)GErrvoy UperifithafaDarMSG. MESjC岌運狀態(tài)子庫徉險Oracle應用產(chǎn)品- Vhion文件世編輯 查看腫 K辟麗 XMCI）登詞 潔動 伽亦 幫肋QP采購卡1=1D 分配(Vision Operations) -號的地其它 頂目丄*楓26編號1類型CM1O450P0,臟半供應商收賞方采購員說明止idei cam leli-Kine and 3 總VI- Nate Voti: Ci ty血itlx Hr. Jomtlun

11、2編號編號撮終收費方記錄.也值.，S.PO表單是一個典型的“業(yè)務流程”類表單，它有 “表頭與表體行”兩大部 分組成，這一點與紙面單據(jù)仍然類似。但不同的是系統(tǒng)表單的每一個“表體行”， 還可以擁有屬于自己的“二級子表行”；而每一個“二級子表行”，也可以擁有屬 于自己的“三級子表行”，如此類推。這種表單展現(xiàn)方式，紙面單據(jù)是無法實現(xiàn) 的，它極大地擴充了單據(jù)可以包含的信息容量，具有高度的靈活性與便利性。在 圖1中，PO的第一行采購總數(shù)量為36,對應到“發(fā)運”二級子表拆分為數(shù)量分 別為20與16的兩行（表示發(fā)到兩個不同收貨地點或同一地點但兩個不同發(fā)貨時 間）；“發(fā)運”二級子表的第一行數(shù)量為 20，對應到“

12、分配”三級子表拆分為數(shù) 量分別是10與10的兩行（表示對應到兩個不同的費用會計科目或費用由兩個不 同部門分別承擔）。第二類是“數(shù)據(jù)來源”類表單例如“0M模塊中的價目表、PO模塊中的報價單、”以及“物料、供應商、 客戶”數(shù)據(jù)表單等等，它們的共同特點是不參與核心業(yè)務流程的構建，但它們?yōu)闃I(yè)務流程表單提供可以參考的數(shù)據(jù)來源，例如采購訂單從物料表單取物料相關信 息，從供應商表單取供應商信息、從報價單取價格相關信息等等；這類表單在手 工業(yè)務模式下大多數(shù)都可能也存在，但手工狀態(tài)下的實際使用與管理可能無法做 到很嚴格規(guī)范；在ORACLE EB中，“數(shù)據(jù)來源”類表單在每個模塊中種類可能很多，每種表 單的內(nèi)容與格

13、式復雜程度，以及單據(jù)數(shù)量也差別很大。它們雖然并非不可或缺， 但它們體現(xiàn)的專業(yè)化分工與協(xié)作的管理思想，對于企業(yè)的業(yè)務流程運作效率有重 大影響。下圖2所示訂單管理/定價模塊中的“價目表”，就是一個典型的“數(shù)據(jù)來源類” 表單，它也可有復雜的結構：第三類是“業(yè)務控制”類表單例如“銷售的物料可訂購性、采購的批準供應商列表、系統(tǒng)參數(shù)設定”等等, 這類表單在手工業(yè)務模式下很少或根本不存在。事實上，手工方式下實際也很難 使用它們對業(yè)務進行有效控制。在ORACLE EB中, “業(yè)務控制”類表單在各模塊中的種類也比較少，單據(jù)數(shù)量也很有限，但它們體現(xiàn)的是企業(yè)管理的系統(tǒng)控制機制， 對于業(yè)務管理控制的效 率有重要影響。

14、如下圖3所示采購的批準供應商列表（控制可向哪些供應商采購），就是一個比 較典型的“業(yè)務控制類”表單，它也同樣可有復雜的結構。霜料30000物料EWXX)_ izitEtrxil ly a7dsed廠崗性（:魯Oracle應用產(chǎn)品-Vision文件 鋼羅 査看世7 K辟務 工凰luidffw稱助QPoittm的供應商列表cwt） 類璽說明廠-廠.Xbbilf phone - eLpaxsslile as；記錄：1/1值H1000A2000flWQO禁用直接GE Plasti esGE fUSTICS前Office Svuilies,CFFICEStimJE termed業(yè)爵供應衙地點狀態(tài)匸總竝瞋

15、的償應筒列 彊應簡狀盂 來嗨補充鎖則 分配來漲補充観鋤+供應簡用戶官理制造簡全.tit応曲0詢盡管在ORACLE EB中，統(tǒng)計后臺數(shù)據(jù)庫中所用到的“表”（Table）數(shù)量有一萬多個，前臺UI中可見的表單也形形色色、數(shù)量繁多，乍看令人生畏，但在分 析歸納劃分為以上三大類之后，事情就會變得簡單很多，它使得我們可以把每個模塊中種類很有限的“核心的業(yè)務流程表單”作為學習研究的“切入點”，通過對每種單據(jù)內(nèi)部業(yè)務內(nèi)涵與技術內(nèi)涵的分析， 以及各種單據(jù)之間業(yè)務邏輯與技 術邏輯的研究，逐步擴展并掌握系統(tǒng)的其它功能與應用。基于實際工作的需要以及系統(tǒng)設計的簡潔方便，ORACLE十對上述三種不同類型的表單分別提供了可

16、供選擇使用的不同 “查詢”方法，歸納起來也可分為三類：功能查詢方式所謂“功能查詢”方式，在系統(tǒng)中有“查詢”功能菜單項（例如 PO Summary 采購訂單匯總），點擊此菜單進入時，系統(tǒng)會首先彈出“查找條件”輸入窗口（控 件），如下圖4所示采購訂單功能查詢菜單與查詢條件控件：勵 Oracle Applications文件 輪輯 直看Q K件蘆 工具 査詢 窗口血 幫肋）Pur ch as mg:釆Kfi訂單：采強訂frfca釆購員工作臺+Adwiced+日期范園 農(nóng)態(tài) 相類單搦 收貨方 會計行清除（1）a菱找采購訂單業(yè)務實俸Jision Operatioi涌號17小V采購訂單匯議Pltuuiin

17、gFlanning Pl aiming收單方 收赍方En Ei-iiee ringFIouj ManufacturingCost申請匯總 申請-采砲訂單功能文檔瀟程Capac it yPurchasing+采哋員工作中心 供應商軻斜目錄 擺索榔料-申請采購if單發(fā)畝P0更改歷史亞 超出的價絡允二 待定采購訂單 菅理市場活動* 自動創(chuàng)建Mt U 記錄.i/i.,.1僵.然后根據(jù)輸入的查詢條件，給出查詢結果 LIST作為查詢功能擴展，系統(tǒng)還 在UI界面工具欄進一步提供關聯(lián)查詢（如采購訂單的上下游單據(jù)“采購申請” 和“采購發(fā)票”）和細節(jié)查詢功能，如下圖5所示采購訂單功能查詢方式的輸出 結果視圖：Q

18、Qrade Applica tions文件Cf）輪揖 查看 丈件夾1工具童詢窗口血稲肋）功罷Pure：釆購占編號說明I糞型0硼4嗣3fl6022D6021001601901業(yè)務實體編號岌放陰應商收弊且織收單方口來圖訂單題頭- ：601S - “00行QP0汀殆1：標推樂颶訂單6017601記錄：1/?查看行2 查書兼運CS） 査看分配Q） 查著渚動歷更記錄 査看境票U） 查看接收但） 查看申諸W 通過工作流査看審批広】 查看項目臺同信息 竟看合同條試 查看文檔織）尖型幣種地點顯示外都行類型采購員未完旗批沾批準標準樂颶訂單標準樂勉訂單標準垂跑訂單批準標準釆瓏訂單批準捕準樂購訂繪標范來購訂單批準標

19、潢采購訂單批準1:smrI批準批準新建發(fā)放追）Z2-06-Z099?5-ft9-20825-09-?00aStat25-09-200825-wy-2D08Corp1St ap25-09-200829-08-200829-08-20080-0-20081&-07-2008新建FO (F)Soft，AdvaAdv a:Si afSt a-f打于功能查詢方式通常只用于核心“業(yè)務流程”類單據(jù)的查詢，查詢功能強大。 由于業(yè)務流程類表單（以及部分數(shù)據(jù)來源類表單）的重要性，系統(tǒng)在菜單項中提 供了專門的“查詢”功能。快捷查詢方式所謂“快捷查詢”方式即在打開單據(jù)界面后，只需點擊UI界面工具欄內(nèi)的查詢“圖標”（手

20、電筒），查詢條件輸入方式有兩種：一種是無專用的“查詢條件”選 擇窗口，僅限于在查找界面的“查找欄”輸入常用的那些字段（即所謂“模糊查 詢”），系統(tǒng)在查找界面直接給出所有符合條件的條目LIST而詳細情況需選定條目后，再進入單據(jù)界面查看，如下圖6所示“采購訂單”在單據(jù)界面進行“快捷 查詢”的情況：另一種是在單據(jù)界面點擊查詢圖標（手電筒）后，也會出現(xiàn)“查詢條件”輸 入窗口，輸入查詢條件后，系統(tǒng)也可能會出現(xiàn)一個簡單的結果清單LIST界面或視圖（某些表單查詢則可能沒有），通過該LIST視圖界面可以再選擇打開相關條 目的表單。同時，也可以直接在單據(jù)界面按“翻頁”鍵（Page Down或Page Up， 在

21、已經(jīng)查詢出的不同條目間按順序直接切換。如圖7所示：物料快捷查詢方式的查詢條件控件與輸出結果視圖：Oracle Applications顯親屆性主層（恥詳細說醍負偏差系數(shù)十會計關閉周期*抿蓋記錄2_1/1_1, _ 值_.二， 上述（兩種）快捷查詢方式，適用于大多數(shù)業(yè)務數(shù)據(jù)量大的表單數(shù)據(jù)的查詢。 而后一種“快捷查詢”方式與“功能查詢”方式有些近似，只是其查詢結果的輸 出視圖的相關“功能”（如上查下查的追溯、匯總與明細的切換等）沒有“功能 查詢”方式那么強大。但對于大多數(shù)“數(shù)據(jù)來源”類表單，由于它們不參與構建 核心流程，信息也不如業(yè)務流程類表單那樣復雜，故“快捷查詢”方式已經(jīng)基本能夠滿足實際工作需

22、要。如按“功能查詢”方式為所有表單設計“查詢條件控件”與查詢“輸出結果視圖”（象某些國內(nèi)產(chǎn)品做的那樣），則系統(tǒng)設計工作的復雜性 將大大增加，后續(xù)系統(tǒng)維護也將十分麻煩，既不經(jīng)濟也無多大實際意義。簡便查詢方式所謂“簡便查詢”方式，即在打開單據(jù)界面后直接把“單據(jù)”界面的所 有字段作為“查找條件輸入窗口” 。要做到這一點，只需在打開單據(jù)界面后，于 UI的工具欄“查看”中選擇“查詢標準-輸入”（或按F11鍵），此時單據(jù)界面有 關字段即“灰顯”，允許輸入具體查詢值，再在“查看”中選擇“查詢標準-運行”（或按Ctrl+F11），則單據(jù)界面顯示查詢結果，按“翻頁”鍵（Page Down或Page Up）,在已

23、經(jīng)查詢出的不同條目間按順序直接切換。 如下圖8所示：物料清單BOM 的簡便查詢方式示意圖：臉Oracle應用產(chǎn)品-Yhion文件世編輯 直看W 衛(wèi):降務 工具 幵單IB）爼杵ID liniow稱助4Bills顯示瀏覽聽啣）縮散查詞標薩尊）彳世錄鞘換=m Lj4匯總/詳豊腦斛晉找忖 直找全部diO越料淸單覦消（CJ蟲蘇上扶棟準匹配1H錄討數(shù)冊詩用表單1.2，矮悅2矮悅雪務處理諸求7必謂求亠SE更改紅須通如仁總工悵覇監(jiān)私程序 通知列囊工性新潔臺野車Bills Of Ifatarials參圾淸單 比敦物料使用處 咸朮更改 導入文営創(chuàng)建公用淸單+工藝匱妓輸入査i甸：孩Ctrl+F ： 1執(zhí)行_. T4

24、盟消.值-記錄：1/1輸入-夠單位T班o J粗件詳細資料主要有效日期物料序號工序組件1規(guī)料說明這種查詢方式既不需要“查詢條件”控件，也不需要查詢結果輸出視圖，系 統(tǒng)設計上十分簡單節(jié)省，適用于幾乎所有表單。要注意的是對于系統(tǒng)中某些數(shù)據(jù) 量很少的表單，則有可能系統(tǒng)只提供“簡便查詢”作為唯一可使用的查詢方式。 此外，EBS中的某些表單，在 WEB下可能還有基于HTML的展現(xiàn)與查詢方式。 UI與HTML這兩種展現(xiàn)與查詢方式的優(yōu)劣，一方面與使用場合有關，另一方面也 與使用習慣有關?？傊私庀到y(tǒng)中各類表單的使用并熟練掌握各種查詢方式，是進一步學習研究系統(tǒng)的基礎，盡管EBS各模塊的表單展現(xiàn)與查詢方式因不同

25、業(yè) 務、不同設計者的風格偏好而可能有所不同，但核心本質(zhì)的東西還是共同一致的。三、事務處理(Transaction)如果說上述EBS的 “表單與查詢”的系統(tǒng)設計體現(xiàn)的正是“從業(yè)務到技術”： 比較容易理解與掌握，那么，所謂“事務處理”則是體現(xiàn)系統(tǒng)“從技術再到業(yè)務” 的一個典范，相對而言，理解起來要困難很多，原因是無法直接在手工業(yè)務模式 下找到相對應的處理方式與過程。以庫房接收采購物料為例，假定公司規(guī)定必須嚴格按PO來接收，并且公司為了嚴格控制庫存水平，接收必須小批量、多批次，則庫房人員就可能需要針對 同一個PO在短時期內(nèi)開出N多張的“入庫單”，工作量很大。為了減少工作量、 提高效率，庫房人員可能會

26、在供應商每次送貨時，僅在找出來的PO紙面單據(jù)上只簡單地做一個數(shù)量標識，最后累積起來匯總開一張“入庫單”。但這種“圖省 事”的做法顯然是一種“很不規(guī)范”的處理方式，雖可以提高工作效率，卻會因 為容易帶來很多其它管理問題而在實際工作中不被允許。ORACLE系統(tǒng)通過提供一個“事務處理”工作界面則很簡單地解決了上述難 題。如下圖9所示采購接收的事務處理工作界面：陸Lira已亡應/B產(chǎn)韶-Vlston文件11）查看也工具忌竝S軸幫肋QP訂申僧亙樸協(xié)匪備 潢邃倍目fJOOO)Lothar CaqjueooooRipab - Rh庫存fhpaL _ FndhI20G00wnoooRipw RnehffiOG

27、OOIpor _ FVncli04-01-汀單?iiHFF是險等圾丁軒揍應（囚UN編專 運箭谿鏡庫再費用W理gg- HmxIj日的地 糞蹙W(wǎng)ffiOOOO漆加至揆曠攜收日朝切H耶類似于“收貨時直接在PO紙面單據(jù)上簡單地做數(shù)量標識”，每次供應商送 貨來時，庫存人員只需在系統(tǒng)中查找出對應的 P0,簡單地輸入送貨數(shù)量并保存, 則系統(tǒng)會在后臺自動生成“事務處理記錄”（等同于是“入庫單”）。對于系統(tǒng)來 說，這種處理方式技術上實現(xiàn)非常容易， 但卻大大減少了操作人員的工作量， 有 效地解決了由于小批量、多批次所帶來的效率問題。ORACLE勺各業(yè)務模塊，大量地采用了上述類似的“事務處理”系統(tǒng)工作方 式，不僅保

28、證了系統(tǒng)高度的數(shù)據(jù)集成性，而且對于系統(tǒng)各業(yè)務環(huán)節(jié)的流程處理也 保證了高度的連貫性與集成性。例如0M系統(tǒng)的發(fā)貨處理、WIP系統(tǒng)的領料與入庫處理等等。系統(tǒng)中所提供的事務處理工作界面，有些可能會以“xxx作臺”（Workbench）來命名之（這取決于不同模塊系統(tǒng)設計人員的個人偏好）。更進一步，系統(tǒng)對于某些“業(yè)務流程”類表單，例如“銷售訂單、發(fā)票”等， 還在表單界面直接提供一個名曰“活動” （Action）的按鈕（Button），該按鈕 包含豐富的業(yè)務處理功能（不僅僅是輸入數(shù)據(jù)），以便用戶（User）對表單內(nèi)容作各種操作處理或獲取相關信息。如下圖 10所示，銷售訂單界面的“活動”按 鈕：此外，ORAC

29、LE EB在某些業(yè)務流程單據(jù)之間，也提供了類似的事務處理工作 界面，以幫助用戶方便地實現(xiàn)業(yè)務單據(jù)的轉換和業(yè)務流程的銜接。如下圖11所示的采購申請PR到采購訂單PO的所謂“自動創(chuàng)建” (Autocreate)功能。對于企業(yè)的一個系統(tǒng)用戶 User (事務處理型用戶)來說，掌握了與自己工 作相關的表單、表單查詢、事務處理，就基本上掌握了EBS的系統(tǒng)使用，系統(tǒng)就不再難懂難用。EBS中的“事務處理”在業(yè)務流程表單內(nèi)部解決了 “人與系統(tǒng)” 的統(tǒng)一問題，在業(yè)務流程表單之間解決了 “業(yè)務與業(yè)務、業(yè)務與系統(tǒng)”的統(tǒng)一問 題。從“純技術”的系統(tǒng)實現(xiàn)角度來看，它也沒有什么高深莫測的地方。很奇怪也很遺憾的是，迄今國內(nèi)

30、主流ERP產(chǎn)品的系統(tǒng)中，還很少看到這種系 統(tǒng)實現(xiàn)方式。曾有一網(wǎng)友通過 MSN向筆者發(fā)問：“ EBS的 WIP事務處理界面是 否要手工輸入item ”看起來這個問題似乎很“幼稚”，但對于很多剛開始接觸 EBS或過去用慣國內(nèi)產(chǎn)品的人來說，由于不了解或不習慣EBS的 “事務處理”系統(tǒng)實現(xiàn)方式，會不自覺、想當然地將所有 EBS的FORM界面都當成具有“實體” 作用、通?？梢詫埫鎲螕?jù)的“業(yè)務表單”來看待，才會發(fā)出這樣的疑問。四、并發(fā)流程(Current Process)從系統(tǒng)實現(xiàn)角度來看，“并發(fā)流程”或“并發(fā)處理”是較之“事務處理”技術味更濃的一個概念，它也是業(yè)務出身、不太懂“技術”的人學習掌握EB

31、S系統(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)機立即或成批

32、周期進行 處理，在不影響用戶做其它工作的同時，高度精確地完成著原本需要人工去做的“過賬登記”任務，并且手工模式下過賬之后為檢查錯漏而需經(jīng)常進行的“對賬” 工作也變得根本就不再需要。“并發(fā)處理”是EBS系統(tǒng)不可或缺的一個重要組成部分，上述“物料接收” 的并發(fā)處理只是一個很簡單的應用。在 EBS中，“并發(fā)”按處理的對象主要可分 為兩類：一類是“流程事務”，一類是“報表事務”。系統(tǒng)統(tǒng)一以“提交請求（Request） ”的方式提供人機交互。如下圖12所示“查詢或提交請求”：對于每一個并發(fā)“請求”，系統(tǒng)都可以允許輸入相關參數(shù)，并計劃其是按某 一周期運行，還是立即或預定在未來某一時刻運行。系統(tǒng)預置了大量的

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

34、它們就像城市的“血管”脈動一樣，奔流不息，維持著城市生命的運轉，生機勃勃。EBS的“并發(fā)處理”所承擔的角色或所起的作用正與之基本類似。EBS并發(fā)處理的另一項重要特性是其“系統(tǒng)級”的可計劃、可管理、可控制 特性，系統(tǒng)通過定義“并發(fā)管理器”、“請求集”等功能應用，對所有需要在后 臺運行的并發(fā)程序進行管理調(diào)度，以平衡系統(tǒng)負載，保證系統(tǒng)有高的使用性能。 如下圖13所示，定義“并發(fā)管理器”（包括運行規(guī)則、工作班次等等。這類似 于城市里的交通調(diào)度與控制）關于“流程事務”類的并發(fā)請求，因為涉及到系統(tǒng)各業(yè)務模塊的具體功能應 用問題，這里不便多講。以下主要來談一談“報表事務”類的并發(fā)請求問題。有 網(wǎng)友曾抱怨說，

35、“ ORACLE勺報表功能不好用，出一個簡單的報表都要到后臺去 提交一個請求，輸出的是一個文本，太麻煩。系統(tǒng)提供的標準報表，內(nèi)容不能滿 足企業(yè)要求，不符合國人的使用習慣”。這種說法可能是因為受某些國內(nèi)產(chǎn)品的 影響而產(chǎn)生的誤解。目前國內(nèi)的主流 ERP系統(tǒng)，對于“報表”基本上采取的是類 似“查詢”的實現(xiàn)方式。這種“查詢式報表”雖然方便了用戶使用，但卻惹出了 無窮的麻煩首先，報表是一種極端“個性化”的東西，不同的企業(yè)由于管理層次不一樣， 關注的管理重點也不同，針對同樣的問題所要求的報表也會不同。 即使同一個企 業(yè)在不同的發(fā)展階段，所要求的報表內(nèi)容也不會相同，因此即使已經(jīng)使用ERP若干年的企業(yè)，不斷地

36、開發(fā)新的（管理）報表，也是很正常的事情。如果ERP系統(tǒng)將報表功能“顯式化”，在系統(tǒng)標準功能中提供查詢條件控件及輸出結果視 圖，則意味著系統(tǒng)提供的這個所謂報表功能必須符合所有企業(yè)的使用要求，而實際這是不可能實現(xiàn)的。在這種情況下，企業(yè)就會理所當然地認為這是 ERP廠商的 責任，廠商必須負責解決。目前許多國內(nèi)ERP廠商產(chǎn)品研發(fā)的一項重要內(nèi)容就是 窮于應付為企業(yè)開發(fā)各種查詢式管理報表，這簡直是等于自掘火坑，陷進去無法自拔，其次，查詢式報表如果內(nèi)容復雜、耗用系統(tǒng)資源比較高，則用戶隨便自由使 用，而IT系統(tǒng)維護人員對“聯(lián)機式”查詢無法進行有效管理、干預，將可能嚴 重影響系統(tǒng)整體性能，導致其他用戶無法進行正

37、常工作。 從這個角度來看，目前 國內(nèi)的主流ERP產(chǎn)品實際上還沒有真正系統(tǒng)意義上的 “報表”功能，只有不加節(jié) 制、擴大化了的“查詢”功能。系統(tǒng)如此處理極不明智。ORACLE將“報表”功能以并發(fā)請求的形式放到后臺去處理，不僅有效地解 決了“報表”的個性化問題，分清了 ERP廠商與企業(yè)的責任界面，而且也為企業(yè) IT系統(tǒng)維護人員提供了系統(tǒng)可管理、可干預的便利。這實際上正是ORACLE系統(tǒng)的靈活性與功能強大之處（SAP也類似）。有網(wǎng)友針對國內(nèi)某些廠商聲稱自己的 ERP是“高端”產(chǎn)品時，質(zhì)疑“連并發(fā)都沒有，能算高端嗎”實際上是說到了要 害。一個連“電梯”都沒有的高樓怎能算得上是現(xiàn)代化的大廈呢！ORACLE

38、系統(tǒng)大量使用后臺“并發(fā)處理”程序，實現(xiàn)了系統(tǒng)用戶的流程操作 在“空間與時間”上的分離，免去了操作人員的無效等待時間。操作人員提交的 并發(fā)請求在后臺運行的同時，并不影響其處理其它系統(tǒng)事務，這樣可以大大提高 用戶的工作效率以及使用的方便性。并發(fā)”之于ORACLE EB系統(tǒng)好比人體內(nèi)的“心臟” 一樣重要，它是系統(tǒng)實現(xiàn)高度的數(shù)據(jù)集成與流程集成的核心工具，是企業(yè)依賴計算機系統(tǒng)實現(xiàn)業(yè)務運作與管理控制自動化的一個技術體現(xiàn)。五、文件夾（Folder）這又是一個ORACLE弄得有點學究氣的概念（可能也有中文翻譯不到位的 原因）。所謂“文件夾” （Folder）功能，簡單來說就是稍有點IT系統(tǒng)使用經(jīng)驗 的人都明白

39、的“用戶自定義查詢輸出界面視圖”功能。系統(tǒng)（可以）提供的查詢 條件控件或查詢輸出結果視圖的字段是如此之多，其中有很多可能并不是用戶希 望顯示出來的，每一個系統(tǒng)用戶 User可以根據(jù)個人的工作需要或偏好，使用文 件夾功能自由地定義自己可見的 UI界面。ORACLE系統(tǒng)為幾乎所有重要的表單、 查詢條件控件及查詢結果輸出視圖都提供了文件夾功能，這也是ORACLES統(tǒng)靈活性、易用性、方便性之所在。如下圖 14所示采購PR的查詢：蠢Grade應用產(chǎn)品-Vision文件CE輪需杏看萌十仲二匚1 XMfl)畑輛幫助血八a t； o壷新建 打幷另存如) 刪除(J).顯貳靜聯(lián)一隱蒲宇段右務左移Q上穗(U)下福冊

40、1|仙寬宇段縮短字段(E) 更改捉濟CC).- 自動調(diào)整全部大小.謐方廠關單據(jù)會計項目審批狀態(tài)創(chuàng)建日期0L-09-20095373533QL-09-2009 C18-00-2009 2己毆消21-O7-2OOS 1n玄杵來工具遼己呦消9L-O7-2COCJ 1已甌消2L-O7-2OOg 121-07-2006 117-07-2(X)9 115-07-ECO9 1呆完成00-07-2005 2數(shù)摒耕序.查看直詢&).重詈萱詢(g)dOSC記錄：1/7六、彈性域(Flexfield)所謂“彈性域”技術是人們每當提及 ORACLE產(chǎn)品技術的先進性時總會首先 想到的一個東西，

41、也是很多初學者（尤其是“業(yè)務出身”的人）開始接觸時可能 會感到有點“發(fā)怵”的東西，原因之一是它的技術味比較濃。但實際上，如果從 應用的角度去理解，它也并無多少神秘之處。前面我們已經(jīng)講到“表單”是組成 EBS系統(tǒng)的最重要基本元素之一，每個表 單都由“表頭與表體行”組成。系統(tǒng)在UI界面中所展示的是表單的“標準顯示”， 盡管這個“標準顯示”可能已經(jīng)包含了適合各行各業(yè)所使用的那些常用信息字段（Segme n）,但對于不同企業(yè)來說，總可能會出現(xiàn)需要添加一些本企業(yè)特殊需 要的信息字段的情況，這從系統(tǒng)角度通常稱為“自定義表單字段”。EBS的所謂“彈性域”技術實際就是為了解決這一常見的系統(tǒng)應用問題而應運而生，

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

43、該PR行的某些自定義補充信息，如關于所申購物料的“長寬高、顏色”題Oracle應用產(chǎn)品-Vision丈件編輯查看婕)兀泮產(chǎn)工具Window耕助助o 申請 iyi S 2血 Opr it L QT1 = J -編號I說明婁型狀態(tài)編制人來源明細詳細贄料ff祁種編號版本類別說明單位麵童費用何 tii, Jfr. JhrQltmiSeattle hbrufhcrtifing.M.-* Seattle外協(xié)膽算(QO龍配)申諳疔.-目的地糞型申請人組織地.點干庫髀目錄(C)_.,Fail til,JonUSD會計13-k TLA,+洵覧利報齡単十複應集軽+管理+物料+會計牛人鄭宜文件記錄.打1值要注意的是

44、，上述“自定義表單字段”是“系統(tǒng)級”而非“用戶級”的，也 就是說只有系統(tǒng)管理員才能做相關設置，而普通用戶只能在實際工作中使用。EBS 中所使用到的“彈性域”分為兩類：一類是所謂“ 鍵彈性域” (Key Flexfield), 一類是所謂“說明性彈性域”(Descriptive Flexfield)。而上述圖15與圖16采 購申請PR中的“彈性域”就是典型的“說明性彈性域”的范例。系統(tǒng)中幾乎所有的重要表單（尤其是業(yè)務流程類表單）都具有這種“自定義” 功能的說明性彈性域，系統(tǒng)說明性彈性域總數(shù)有二、三千之多。稱之為“說明性”（Descriptive）取其對標準表單字段作補充說明之意。用戶在說明性彈性

45、域中輸入的字段信息，通常只能作為統(tǒng)計分析、出報表使用，不參與系統(tǒng)業(yè)務流程的構 建，系統(tǒng)（應用程序）不對之在表單之間作跟蹤、追溯。如下圖 17所示是采購 申請PR表頭“說明性彈性域”的系統(tǒng)定義界面：臉Oracle應用產(chǎn)品-Vision文件世鉤輯（I）壹著腫 K怖齊 T JI rjj Iiadw幫助OPSDHEN：應用:彈性壩：識朋世:Define descii prtive fleifiel刼能文檔流程應用灤結理性域定良標題段分隔符旬電上下文宇段Accauits Recei valbQe Acwnrrts 內(nèi)yaHl 電 ASSEIGENERAL I.H JGI7ROtto必需（R）已顯示；SI

46、SADMLN 莽笈o段摘妻申諳題頭-全筒數(shù)據(jù)充：-：”：上下文耳編號十GLnlwl值集（Q代碼列名稱應用注冊+安疾TjfcJffl 乗單 + 驗證 -輝低繪+鏈Valxj十如帀種網(wǎng)韜側說窗口堤示系統(tǒng)所謂“鍵彈性域”的情況較之“說明性彈性域”就復雜、嚴格得多， 原因是它們參與業(yè)務流程的構建，系統(tǒng)的應用程序要對之進行跟蹤、 追溯，其作 用當然非?！瓣P鍵” （Key），故數(shù)量也比較少，在整個 EBS系統(tǒng)中總數(shù)不過約 35個。其中用得最多的例如“物料類別彈性域”、“會計科目彈性域”等等。與“說明性彈性域”屬于表單的用戶“補充字段”不同的是，“鍵彈性域”本身就屬于表單的系統(tǒng)標準字段，這個表單標準字段用戶

47、輸入的不是簡單的一個信 息，而是具有某種可在系統(tǒng)層面“自定義結構”的一組信息。如下圖18所示采購申請PR表單界面中“物料類別”字段，用戶輸入時將 彈出系統(tǒng)已經(jīng)定義的“物料類別鍵彈性域”界面，以供用戶（選擇）輸入具體信 息：騷Drade應用產(chǎn)品-Vision丈件叩 編輯 直看婕）TrF?- rr-工具幫助助；再逗令站屜暑題丨弋丿門妙泉丨/目鄉(xiāng)城丨？十詢齡和報供單+犠應來順+ 官睚十物料+會計個人配宣文忡記錄:1Z1值.如下圖19所示是系統(tǒng)層面定義“鍵彈性域”的界面。全部 35個鍵彈性域主 要集中在庫存、總賬、資產(chǎn)、人力資源等核心業(yè)務模塊中定義，其它模塊只是應 用時調(diào)用。鍵彈性域由于其系統(tǒng)地位與重

48、要性，其定義方式與內(nèi)容也要比說明性 彈性域來得復雜。對于每一個“鍵彈性域”，系統(tǒng)允許定義若干個不同結構的字段組合，以使用在系統(tǒng)中的不同場合（例如不同組織或帳套等等）。如下圖 20所示，表達了“會計科目彈性域”可以有若干不同結構（代碼）的情況，圖中“Vision Ch ind的5段式結構，可以和其它國家或地區(qū)的完全不同。區(qū)0恫匸1亡應用產(chǎn)品-甲討ion丈件世褊輯 查看M H鼬齊 工靈粘助QP；記-J灣區(qū)丨諱目（ ?應用產(chǎn)品彈性域標題Afestrrtit% Fl fi eld絡構代碼標題說明視罔名稱Vision Turkqr Accou-rting FlTHir_iUXX)IJNTITC_FLEK

49、 Ttsi Accohntiiie FIsIUF斫匚心OUMTING-FL Ttrk cccwting Fl erIE AOCOINIIN& FLEEVision UK (EhEA CorEnli c-tiiunus AOoonniNG FLEltriui 他 AccwtHf 叮包斤已-IVISION CHE凰 OOOLNIVEESTrVMJCOlllJIIM ltd. Vasily AcccurtLE Flee Vi si 口 n Univrsi 如 AccoLKrtinM si du IhslICWra Accoiiitiiqg Fie Vi；s；cjn Chlia AccouzitlF2

50、e InQ*段嘀要(Acctninting FlesfieldLj - Visi on China Accoimtin匡 Flex f 記錄：1/5詬 AOCOINTPK； FLEEM si on Beta巴凍結彈性域定義a）匕交艾驗證段（刃pCbCost Caits?CJCAc court?ECtRxiductFYodFutureftafaNT5fi謹世域眼定詞小編號名稱窗提示列段除戶捌名 交叉斷EEG3ENT4”_J.ORACLE勺彈性域應用技術作為系統(tǒng)最重要的基礎元素之一，歷經(jīng)多年發(fā)展， 其應用已遠非上述所例舉的“表單字段信息”那么簡單，它事實上已經(jīng)發(fā)展成為 一種重要的方法論。系統(tǒng)基于（

51、鍵）彈性域的某些重要技術特性，逐步發(fā)展出了 諸多使用靈活、功能強大的應用實現(xiàn)方式。（相關討論必須結合具體的系統(tǒng)應用 來進行，這里不再贅述）。七、值集與查找代碼（Value Set and Lookup Code日常工作中，用戶在表單的字段（包括彈性域字段）中輸入數(shù)據(jù)的方式無外 乎兩種：一種是直接手工鍵入，例如訂單中的數(shù)量（數(shù)值）或文字說明（字符） 等等；另一種就是所謂“LOV” （ List of Value），用戶只能從某個預先定義的“來 源單據(jù)”做選擇輸入（用戶如手工輸入，系統(tǒng)可能自動針對來源單據(jù)進行校驗以 確定輸入值是否允許）。表單字段的“ LOV輸入實際占了系統(tǒng)輸入操作的大部分情況，之

52、所以如此 的重要原因是業(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)中通常稱之為“值集”（Value Se）。在系統(tǒng)中定義一個完整的“值集”需要兩個相互獨立又相互關聯(lián)的階段，首 先是定義“