企業管理財務系統構建實施

李霞

摘要：近年來，我國企業的信息化建設越來越全面，充分提高了企業管理的效率。企業的資金管理是企業管理中較為重要的一個環節。對于企業資金的信息化管理，實時監控是一種科學化的企業管理手段。許多企業雖然認識到資金管理對企業發展的重要性，但是管理意識不足，管理方案缺乏，尤其是傳統企業對于企業信息化管理的認知程度不足。本文就以北京尚誠致遠科技有限公司資金管理為背景，采用J2EE技術對企業資金使用實現全方位的管理和監控。

關鍵詞：資金管理;信息化;J2EE

引言

自從全球脫離了經濟危機的霧霾之后，經濟的復蘇和跨國經濟活動也越來越多，利率和匯率對企業的經濟影響也越加深刻，企業單純的財務管理已經不能應對當今的經濟變化形式。財務管理漸漸轉變成了資金管理，隨著信息化建設的越來越全面，資金管理體系也越來越完善。資金管理是一個龐大的課題，包括現金管理、投資咨詢、風險評估、利率和匯率監控和銀行關系維護等等。伴隨著國外企業信息化建設的一步一步推進，國內企業傳統的管理方式導致企業信息化建設緩慢。資金管理作為企業管理的重中之重，資金管理體系逐漸成為一個衡量一個企業信息化的標準。

國內自動化辦公越來越普及，企業的信息化管理也進入快速推進時期。北京尚誠致遠科技有限公司在自動化辦公方面取得了巨大進展。資金集中管理、預算管理控制、財務集中核算、銀行和企業財務管理互聯早已有了解決方案，也為我們這套綜合的資金管理系統提供了基礎模塊。根據北京尚誠致遠科技有限公司的整體規劃，該公司的資金管理業務大致分為以下幾塊：資金計劃額度分配，資金收款認證，資金付款審核，以及資產分配管理。其中資產管理屬于公司信息化管理中除了金錢以外的公司財產的管理與使用。各個業務又有不同的子模塊，并且各個模塊之前也有相互交叉，同時與外圍的會計核算系統、TMS等系統集成。對于北京尚誠致遠科技公司資金管理系統的業務熟悉后，為了公司的信息化建設，決定開發這套資金管理監控系統。

上世紀40年代便開始有了企業資金管理體系，這個體系近年來也越來越成熟。尤其是計算機的誕生，直接將企業資金管理劃入到了自動化辦公板塊。國外也有很多公司專注于企業自動化辦公系統的研發。資金的實時管理是企業信息化管理的重要部分。在發達國家企業資金的實時管理和監控都已經比較成熟，企業都有成熟的解決方案。雖然國內部分企業生產力水平達到世界一流，但我國計算機發展起步較晚，企業信息化建設不全面，尤其是在企業資金管理上更是沒有權威的解決方案，這就難以推進國內基于計算機的資金實時監控系統的研究和應用。

國內越來越多的企業也認識到資金管理的重要性，而一批大型企業憑借雄厚的資金實力，借鑒銀行資金管理模式，運用理財手段、現代網絡技術，實行資金集中管理，取得了顯著的成效。他們特別注重用信息化的手段強化企業的資金集中管理。但是，較為完善和專業的企業資金管理解決方案卻一直沒有創新產品。本文就北京尚誠致遠科技有限公司的資金管理監控系統的設計進行簡要說明。

1 項目可行性分析

1.1可行性分析

本系統的設計將采用應用較為廣泛的B/S模式，技術支撐依托于J2EE體系結構。這個項目采用了現在比較流行的MVC模式，M層使用了javaBean來映射表單數據和對應數據表，V層使用了JSP技術以及大量的css與javaScript，C層使用了Servlet技術，完全滿足了這個項目的需求。另外，在操作數據庫時底層仍采用JDBC技術，但是得到了很好的封裝，使用已經封裝好的c3p0數據庫連接框架，只要將數據庫信息保存到配置文件中，便實現了數據庫連接，也實現了javaBean往數據庫的映射。這就是北京尚城致遠科技有限公司資金管理監控系統的基本技術概要。

軟件技術架構都比較完善，硬件方面windows系統都可以適應。現有硬件的處理速度足以滿足項目需求。現有機器大部分可以運行該項目，項目的運行基本不會改變原有計算機的運行狀態以及系統架構。而且項目整體操作類似現有大部分信息系統管理軟件，業務邏輯上不會有太大問題。并且前期項目搭建，會有專業人士來做。

1.2軟件工程設計理論和技術

每一個系統軟件在開發之前都要經過軟件設計，軟件設計具體又包括需求設計，詳細設計，系統架構設計。有需求設計來推出詳細設計，具體說明用戶需要哪些功能模塊，有詳細設計退出系統架構設計。在系統架構設計中項軟件開發人員具體介紹功能點的實現與難點的突破等。

下圖為大家簡單介紹軟件設計的主要組成。

（1）UML技術

UML建模技術，是用來將軟件進行可視化建模的一種技術。首先要了解模型是什么，模型就是將現實世界中的物體，進行抽象的模擬和簡化。為了使軟件系統更容易被理解，就出現了建模。建模有哪些有點：

可以對系統進行可視化分析，使其更接近需求。

可以看出系統構造的模板。

降低了軟件系統文檔化的難度。

UML建模包括七種視圖：

（2）J2EE技術介紹

目前的java平臺包括三個版本，一種是用于小型嵌入式設備上的軟件開發J2ME，還一種是簡單桌面應用的J2SE，以及最后一種用于企業級平臺搭建的J2EE。

J2EE平臺具有諸多優點，它具有很好的可伸縮性、靈活性、易維護性等。這幾點又體現在J2EE平臺能夠保存現有的IT資產，對于一些現有的基于J2EE平臺的項目可以進行迭代開發，既可以加入新的功能模塊，也能保留原來功能模塊。并且J2EE平臺的產品幾乎能在任何操作系統上運行，也就免去了對硬件環境的要求，現有的操作系統和硬件資源任然可以使用。

而我們的系統正采用了J2EE平臺，這里主要運用到J2EE規范中的JDBC、JSP、Java Servlet、XML等。

（3）Struts2

SSH（Struts +Spring +Hibernate）三大框架，今天來總結一下Struts2的一些知識。所謂框架么，其實就像我們蓋房子一樣，需要先搭建支架，然后再進行添磚加瓦，使之達到完美。而在軟件開發中，框架也是一樣的：就是將通用的代碼進行封裝，使我們可以重復利用，達到了高效開發的效果。當然既然已經搭建好的框架，用到我們的系統中，我們就需要學習它，怎么使我們自己獨有的代碼和框架進行完美的結合。因為大家都在用這些優秀的框架，所以框架的學習，其實就是框架規范的學習。有了規范，有個約束，有了統一，才能更加有利于合作的開發。

（4）Hibernate

這是一個數據庫的操作框架，Hibernate中提供了兩個級別的緩存

第一級別的緩存是 Session 級別的緩存，它是屬于事務范圍的緩存。這一級別的緩存由 hibernate 管理的，一般情況下無需進行干預

第二級別的緩存是 SessionFactory 級別的緩存，它是屬于進程范圍的緩存

SessionFactory 的緩存可以分為兩類：

內置緩存： Hibernate 自帶的， 不可卸載. 通常在 Hibernate 的初始化階段， Hibernate 會把映射元數據和預定義的 SQL 語句放到 SessionFactory 的緩存中， 映射元數據是映射文件中數據的復制， 而預定義 SQL 語句時 Hibernate 根據映射元數據推到出來的. 該內置緩存是只讀的.

外置緩存（二級緩存）： 一個可配置的緩存插件. 在默認情況下，SessionFactory 不會啟用這個緩存插件. 外置緩存中的數據是數據庫數據的復制， 外置緩存的物理介質可以是內存或硬盤。

（5） Spring

Spring是一個輕量級的IOC和AOP容器框架：a，輕量級：程序實現不是很復雜，代碼不是很多，占用資源不是很多，沒有侵入性;b，IOC（Inversion of Control 控制反轉）：對象創建責任的反轉（重點，核心）;c， Aop（Aspect Oriented Programming）：一種面向橫切面編程的思想方式，可以進行功能性擴展，看前邊的一篇轉載的博客：面向橫切面（AOP）編程d，容器：可以容納對象，并且可以控制對象的生命周期。

Spring框架是進行對象管理，對象關聯，解耦的一個中間層框架。SSH（Struts+Spring+Hibernate）三大Spring在中間就起著一個承上啟下的作用。好，首先我們先來看一下Spring框架的一些知識點，通過下邊這張圖來總括一下：

（6） JavaScript

JavaScript雖然是一種編程語言，但它非常簡單。它是處理html頁面的腳本語言。是由網景公司創建，JavaScript首次出現時功能非常有限，甚至編寫完的代碼只能運行在一種瀏覽器。直到W3C的出現，制定了一系列標準使得JavaScript得到了廣泛傳播。它可以增加頁面生動性并使其以全新方式與用戶進行交流。我們項目中也大量使用js來增加頁面效果。

（7） JQuery

jQuery是一套封裝了的IavaScript庫。jQuery只是腳本庫，并不是腳本框架。它并不能解決腳本的引用管理與功能管理中的問題，這是腳本框架要做的事。但腳本庫可以幫我實現很多業務邏輯上的問題，jQuery的出現提高了編寫JS腳本的效率，增強了代碼的健壯性，讓代碼看起來更加優雅。

jQuery有哪些特點：首先就是提供了強大的功能函數，讓代碼更整潔，尤其是其強大的選擇器，其次解決瀏覽器兼容問題，豐富絢麗的UI實現。

（8） MySQL

在互聯網技術中，MySql數據庫已經是非常普及的數據庫。MySql與其他數據相比有它自己獨具一格的一面，它的架構應用在多種場景時依然非常合適，能應對自如。MySql不僅性能指標出眾，實際裝機容量與應用領域都高于其他數據庫。MySql相比其他數據庫有著更加全面的測試，同時也有著更多的相關技術文檔。它的優勢體現在應用范圍廣，運行穩定，高性價比等。

（9） MVC

MVC是現代web開發中非常流行的一種設計模式，將整個應用劃分為三層結構：視圖層（V），模型層（M）與控制層（C）。

模型是企業數據和業務規則模型。在MVC里面，該模型要處理的任務最多。通過模型返回的數據是與數據格式無關的。該模型可為多個視圖提供數據。適用于模型的代碼只寫一次可復用的多個視圖，從而減少重復代碼。視圖是向用戶展示信息并做交互的頁面。

視圖層既可以顯示模型層的數據，也可以轉發到控制層將模型層的數據進行處理。視圖層也是三層中用戶可以直接看到的“層”。控制器層在項目中起到控制轉發的作用，其中也包含了對模式數據的操作，處理等事務。

控制層更多的是Servlet來實現，當今能實現控制轉發的框架有很多，不單單是Servlet，比如struts。控制層通過模型層來操作數據庫，然后將數據轉發到視圖層顯示給用戶。

總之，MVC三層是協調工作的，視圖層與用戶交互，接受用戶請求，模型層用于將實體映射到數據庫，起到封裝作用，讓開發者只面對事先封裝的模型，控制層來處理用戶請求和操作模型層，也是整個項目的難點所在，是整個項目業務邏輯的核心。

（10）JDBC

JDBC是一套API庫，專門用來建立數據庫連接，操作數據庫，它對多所有數據庫提供了統一的接口。 簡化了開發流程，統一的java接口。每一個支持java的數據庫生產商自己來做JDBC驅動程序，然后提供統一的接口供開發者使用，這樣簡化了java開發者操作數據庫的流程，這種做法也是java“一處編寫，處處運行”的思想。而需要更換項目的數據庫時，只需要修改數據庫驅動類即可，所以說JDBC的API有著很大的價值和意義。

（11）DBUtils

這是一個數據庫的操作組件，有點類似當今流行的Hibernate，能夠將數據庫操作結果轉換為各種數據集合，例如List，Map等，但是其底層仍然是JDBC實現的。那么這個數據庫操作組件有什么特色呢。首先是對于數據表的讀寫，結果集能很好的處理為java中的集合，比如List，Map，Set。其次，操作數據表時只需要傳入sql語句即可，同樣支持占位符。最后，這個組件能夠使用數據源，能通過JNDI和數據庫連接池技術來進行性能優化，尤其是對數據庫連接的重復使用。

1.3項目開發環境與運行平臺

（1）運行平臺

項目開發所使用的服務器是Tomcat，它是由Apache發起的，是一個開源免費的產品，我們就用它作為項目的服務器。同時，它還是SUN公司推薦的Servlet容器，它能夠跟大部分主流的HTTP服務器一起協同工作，并且可靠，穩定，效率高。

Tomcat服務器主要有以下特色：

免費開源，網上資料齊全很適合我們這種小型項目。

安裝部署簡單，體積小，是一個適合新手使用的WEB容器。

更新快，跨平臺。由于Tomcat本身是java寫的，所以具有跨平臺性。

除了服務器端，前段也用到了大量js與css技術。整體屬于JavaEE體系架構。

（2）開發環境

操作系統：Windows 7。

服務器軟件：Tomcat6.0。

瀏覽器：IE、Fire Fox、360。

開發工具：MyEclipse。

（3）C3P0

這是一個開源的連接池庫，仍使用JDBC，它實現了jdbc3和jdbc2的拓展與規范。現在流行的Hibernate與Spring都使用了這種連接框架。它的配置信息如下

數據連接配置

2需求分析

在軟件開發的過程中，首先要做的就是需求分析。一個項目最終能否符合用戶的需求，絕大部分在于需求分析工作做得是否到位。下面就對北京尚誠致遠科技有限公司的資金管理與監控系統進行業務上的需求分析介紹。

2.1 企業資金管理業務架構

完善的企業資金管理業務應該主要包括以下三個大的方面：現金管理（CashManagement），資金交易管理（Treasury Transaction Management），即管理企業在多頭寸時的投資以及在缺頭寸時的融資。風險管理（Risk Management），即對企業所面臨的資金風險進行識別和衡量，同時對于可能發生的風險進行有效的防范。對于企業資金管理人員來說，還需要考慮會計處理，和資金報告等相關工作內容。

企業資金管理的主要業務框架

2.1現金管理

企業資金管理之中，最原始的莫過于現金管理，現金管理是近現代企業資金管理中必不可少的一部分。其中包括企業現金流的預測，企業現金池的管理，銀行賬戶的管理，收款及付款的管理四大部分。下面章節中將分別對這四部分做進一步的介紹。

（1） 現金流預測

現金流預測是企業資金管理的基礎，企業工作人員應當對企業的現金流向做出一定預測，如果能對現金流作出準確的預測，就可以促進資金的流動，增大投資收益。在預測資金流向的同時，對企業的資金風險也能進行簡單的預測與評估。雖然單純的預測，缺乏理論知識，但是我們可以借助于企業信息化中的技術手段，對當前企業的資金模式進行建模，分析，最終得出資金流向的預測。

對于企業的流動性預測和現金計劃來說，首先需要獲取內部和外部銀行的數據。在獲取銀行數據后需要對數據進行對帳（銀行對帳放在后面章節描述）。然后對現金的頭寸和現金的預測進行查詢，編制現金計劃的報表。在這些工作的基礎上，分析實際與預測的匹配程度，對企業的融資成本進行分析，對企業面臨的流動性風險進行預測，在此基礎上進行投融資的決策。

對企業來說，現金流的預測信息收集主要通過以下四個途徑：

①企業的預算數據。一般企業都會制定一定經營周期（一年或半年）的預算數據，并進行滾動式（每季度或每個月）的更新。一般來說，預算數據可以提供給企業現金流的長期預測信息。

②企業的應收/應付信息。企業一般都會有類似供應商付款和銷售收入這樣的應收應付信息。應收應付周期一般都是一個月，所以應收/應付信息成了企業短期現金流預測的主要來源。

③企業的資金計劃。企業的各個分子公司或其他成員單位會定期提交資金計劃給資金中心或集團資金部。這類信息可以作為企業中期的現金流預測的主要來源。

④資金業務（Treasury Activity）。企業的資金業務也會影響到企業的現金流預測。舉例來說，某企業有一筆10 年長期貸款，每半年付息，到期還本付息，這也就意味著這個企業每半年會有一筆利息支出的現金流，10 年后到期還會有一筆歸還本金的現金流。

（2） 企業資金池

企業資金池是為了方便管理人員對企業當前的資金狀況有一定的把握。企業需要在資金池中建立多個子賬戶，并且為每個子賬戶分配特定的金額。在資金池的使用中需要加上審核流程，只有有相應權限的管理員審核通過后，資金才能在資金池中流轉與使用，既保障了企業資金的安全性，也對公司現金進行了高效的管理。

（3） 銀行賬戶管理

企業對銀行賬戶的管理的目的是為了高效地，準確地管理企業（包括總部和各個分公司）的銀行賬戶結構和信息，從而提高企業現金的流動性和有效利用率，為建立企業現金池提供基礎保障。企業銀行賬戶管理一般包括銀行賬戶開戶信息的維護，銀行賬戶結構的管理，銀行賬戶余額的管理，銀行賬戶交易管理和銀行賬戶對帳管理。如下圖所示：

其中收支兩條線是目前大多數企業所普遍采用的一種賬戶管理模式，收支兩條線模式的工作方式如圖3-2 所示：

從圖3-2 中可以看出在分公司有資金需求時可以提交付款申請，企業會從資金中心的總賬戶下撥資金到分公司支出賬戶;同時，資金中心也會定期將分公司的收入賬戶的盈余上收到資金中心總賬戶供企業內部賬戶使用。

（4） 資金調撥

資金調撥包括企業內部的資金調撥和企業對外的收付款。

企業內部的資金調撥保證了企業內部資金流轉的高效，有利于企業資金的有效利用，達到了企業利益的最大化。一般對企業的資金部門來說，最大的工作量就集中在對企業收款和付款的管理，所以對于收款和付款的管理也是現金管理中一個重要的組成部分。

對收款來說，企業需要及時地了解收入的情況，這是高效地利用資金的前提;對于付款來說，企業需要安全的，完善的流程控制，以降低資金支付的風險。同時企業需要一個集中的付款平臺，以保證企業可以使用一個統一的平臺通過不同的銀行進行資金的支付。

2.2 資金交易管理

企業資金交易管理又叫做投融資管理，是在建立良好現金管理的基礎上，企業利用各種金融工具在多頭寸的時候進行投資，缺頭寸時進行融資的過程。資金管理是資金管理的核心。在當前開放的國際金融市場上，企業在進行投融資的時候，有很多種選擇。

從投融資的市場業務角度來區分，主要可以分成四大類，分別是貨幣市場交易，資本市場交易，衍生品交易，外匯交易。

投資管理是對企業的各種金融投資進行跟蹤和管理。一般企業可投資品種包括：銀行存款、票據、基金（股票型基金、債券型基金等）、債券（國債、企債、金融債、債券回購）、股權投資等;融資管理是對企業的融資進行統一的管理和跟蹤，其中的融資工具包括上市、發債（普通債券、可轉債）、銀行貸款、票據、保函、信用證等。

當然，為了規避風險，企業還會利用各種對沖（Hedging）金融產品進行套期保值，比如利用外匯遠期規避匯率風險;利用利率掉期來規避利率風險等。

2.3風險管理

企業在建立有效現金管理的基礎上，會去進行投融資，那么風險管理對于企業來說是非常必要的。市場風險是指在資金融通和貨幣資金的經營過程中，由于金融市場變動帶來的影響，使資金所有者的收入與預期產生偏差。利率、匯率、商品和證券的市場風險是企業面臨的最主要的市場風險。對于市場風險，企業可以采用情景分析和對在險價值（VaR）的評估來測算市場風險對于企業資金頭寸的影響，以便企業及早地采取措施，降低風險發生所帶來的損失。對于流動性風險來說，目前企業主要是通過貸款和內部資金的調撥來解決流動性風險的問題。

操作風險是由于人員操作或者系統失效等外部因素帶來的風險。為了避免操作性風險，企業在進行資金交易的時候必須有完善的審核流程控制;同時，建立適合企業資金管理要求的信息系統。

對于法律風險，企業要加強自身法律意識，同時還要加強企業法律部門和審計部門的建設力度，提高法律部門和審計部門的人員素質。

2.4企業資金管理運作模式

借鑒銀行的資金管理運作模式，企業資金管理一般也分為對于資金管理部門前、中、后臺的管理， 如圖3-3 所示。

從圖中可以看出前臺人員（Front Office）負責交易的錄入和日常處理，其中包括貸款交易，債券交易，票據交易，外匯交易和金融衍生品交易等。中臺人員（Middle Office）負責風險管理和限額管理等。后臺人員（Back Office）負責交易的清算，會計出賬，資金報告等。

2.5企業資金管理業務流程

（1）業務流程概述

企業資金管理業務流程包括現金流預測，內部現金管理，資金運作，交易執行管理等，如圖3-4 所示：

圖3-4 中，現金流預測是基于業務產生的實際應收數據、銀行數據以及預算數據，企業根據這些數據進行現金流預測;內部現金管理在現金流預測的基礎上，對公司銀行賬戶進行管理，建立合理的資金池結構，并對資金頭寸進行管理，實現賬戶之間資金的調撥;資金運作是在準確的現金流預測和內部現金管理的基礎上，企業需要對風險進行分析，確定合理的投融資決策;交易執行管理是根據制定的投融資決策，進行交易的執行管理。在資金運作過程中，前、中、后臺人員對流程進行控制，分工合作。前臺進行交易的錄入、審核與授權，中臺進行風險的控制和限額的檢查，后臺進行結算和會計處理。

（2）資金交易流程分析

企業資金管理中核心的業務流程就是對于交易的生命周期的管理。這里對交易的定義是：一切可以導致企業資金頭寸發生變化的資金活動。它不僅包括投融資交易，還包括一般性付款和收款，利息的收入和支出等。交易可能產生企業資金頭寸的正向變化，也可能產生企業資金頭寸的負向變化，下面本文將以兩個實際的例子來解釋企業的實際交易流程，從而進一步分析和優化企業的交易流程。

我們先以企業長期貸款（Loan）為例。首先，企業因資金需求，需要向某銀行貸款，

銀行一般都會對企業授予一定的授信額度（Credit Line），也就是銀行愿意向企業貸款的最大限額。接著企業會確認該銀行授信額度是否能滿足此次貸款的需求，在不能滿足企業貸款需求的情況下，企業一般會要求銀行增加對其的授信，或者拆分貸款并向多家銀行貸款，直至滿足企業融資需求。其次，企業會和銀行商討貸款合同的細節，比如貸款利率，還本付息周期等具體內容。接著，雙方達成共識，簽署合同。最后，銀行根據合同金額提供給企業資金，企業根據合同還本付息，直至全部貸款償還完畢。對于企業來講，這些活動都涉及到相關業務角色的一系列活動，其中包括交易員錄入交易，到后臺的審核結算。

對 于 企 業 的 投 資 交 易 （Investment） 來說， 企業一般都會對于不同交易對手方（Counterparty）或者交易類型定義不同交易限額也就是企業在與某一對手方進行交易或者進行某種交易的最大值。以購買債券（Bond）為例。首先企業會檢查購買此類債券的限額，如在限額之內，企業可以購買該債券。接著，通過相關人員審核和授權后，交易員可以在市場上購買該債券。最后，企業支付現金并持有債券。在企業持有債券的期間，會獲得該債券的利息，同時債券在市場上價格是浮動的，企業也可以在確認獲利的情況下，將債券買出，這當然也會涉及到相關業務角色的授權。通過對企業資金管理的交易流程進行深入地分析，可以抽象出企業資金管理中交易的管理流程。圖3-5 描述了資金管理中的交易管理的主流程。

從圖3-5 中可以看出資金交易的主流程：首先，由前臺人員（Front Office） 建立資金交易;接著，中臺人員（Middle Office）進行風險的控制，其中包括交易限額或敞口的檢查，以及企業關注的其他一些風險指標，例如：VaR;然后，后臺人員（Back Office）一般會根據限額和各種風險指標來對交易進行審批。交易審批過后，后臺人員還會對交易的結算信息進行審批。企業都會有自身特色的交易和結算的審批流程;審批通過后，出納可以對交易進行最終地結算。

2.6基于CTR 模型的系統

本節將通過用例的方式闡述了基于 CTR 模型的資金管理系統的需求。

（1）需求概述

圖 3-6 用語境圖（Context Diagram）方式，概述了相關人員和系統對于企業資金管理系統的需求。

從圖中可以看出，IT 人員希望通過系統來維護企業資金相關的一些基礎數據，免去了他們手工維護的辛苦;現金管理人員系統通過系統來有效管理企業賬戶信息，管理企業資金池，提高企業現金的流動性，最好還能通過該系統進行收付款的支付，這樣可以減少他們大量的工作量;資金管理人員希望通過該系統管理企業資金交易，維護交易狀態并對交易進行估值等平時他們經常要做的工作;風險管理人員希望該系統能提供一個有效評估和控制企業資金風險的平臺;企業司庫或者財務總監則希望系統能夠提供制定企業發展和投融資決策的有效信息;外部系統要和企業資金管理交換數據和信息。

（2）基礎數據需求

在進行需求分析之前，首先必須要了解和企業資金管理相關的一些基礎數據，以及這些基礎數據的哪些信息是需要在本系統中維護的。表3-2 給出了資金管理系統中要維護的一些關鍵的基礎數據。

下面簡要介紹一下這些關鍵的基礎數據需要在系統中維護的主要信息：

①企業組織架構主要有業務單位名稱、地址、電話、傳真、郵件地址、層級、法

人實體、本幣幣種、報告幣種、以及各業務單位的層級關系等信息需要在系統

中維護;

②企業銀行賬戶主要有賬戶名稱，賬號，開戶人，開戶銀行名稱，賬戶幣種，電

子轉賬代碼，SWIFT 代碼等信息需要在系統中維護;

③交易對手主要有交易對手名稱、地址、電話、聯系人、傳真、郵件地址、層級、

交易對手類型等信息需要在系統中維護;

④交易對手銀行賬戶主要有賬戶名稱、賬號、開戶人、開戶銀行名稱、賬戶幣種、

電子轉賬代碼、SWIFT 代碼等信息需要在系統中維護

⑤貨幣信息需要在系統中維護的信息有：貨幣名稱、計息基準、小數位數、歸整

原則、貨幣發行國、以及貨幣之間報價方式（直接報價，間接報價）等

⑥市場數據主要有相關貨幣、報價日期、買入價（Bid Price）、賣出價（Offer Price），

最終價（Last Price）等信息需要在系統中維護;

⑦結算方式主要有結算名稱，結算類型需要在系統中維護;

⑧業務種類主要業務名稱、相關交易對手等信息需要在系統中維護;

⑨信用額度主要有幣種，匯率，復核日，到期日，有效期間，額度，保證金，費

率，使用單位，適用交易等信息需要在系統中維護;

⑩風險敞口主要有敞口值計算標準，敞口分組信息，適用交易，期限，敞口值等

信息需要在系統中維護;

（3）參與者

參與者（Actor）是具有行為能力的事物。參與者不僅可以由人來扮演，也可以是組織，軟件或機器。參與者并不屬于系統，它通過系統邊界直接和系統進行有意義的交互。表3-3 列出了系統的參與者。

表3-3 TMS參與者

（4）資金管理系統的互連

正如前文闡述的一樣，作為企業的核心系統，資金管理系統除了本身有若干個子系統構成以外，還要和其他的企業信息系統互連，以獲得系統需要的信息。圖3-4 展現了典型的資金管理系統與其他企業信息系統的互連情況。

圖 3- 4 典型資金管理系統互連

從圖中我們可以看出，企業資金管理系統要和以下四個系統互連：

①銀企直連系統：資金管理系統一般會作為企業的支付平臺與各個銀行的銀企直

連系統互連。目前國內大多數銀行都已經提供了銀企直連系統，但是不同的銀

行提供的接口會有差異，但是所有的銀行都會提供以下3 類接口：支付，賬戶

余額查詢和賬戶交易明細查詢。支付接口需要資金管理系統提供支付賬號，支付金額，支付目的等支付信息。賬戶余額查詢和賬戶交易明細查詢需要資金管理系統提供賬戶號，賬戶名和日期等信息。

②ERP：資金管理系統需要ERP（例如：SAP，Oracle）的應收/應付信息，從而可以

更準確和全面地進行現金預測和支付管理。

③行情系統：資金管理系統需要獲取行情系統（例如：Bloomberg，Reuters）的市場

數據（例如：利率，匯率，股票價等）以支持系統的運行。

④預算系統：資金管理系統也包括了預算系統，預算又分為月度資金預算與年度資金預算，從這兩方面結合來提高預算的準確性。

3系統設計

（1）系統公共模塊設計與開發

系統公共功能主要分為消息與待辦，審核流程，附件上傳下載，圖表統計，

用戶權限，綜合查詢。這里簡單為大家介紹消息、審核流程、附件上傳這三個比較常用且關鍵的模塊。

消息與待辦模塊是公用的模塊，每個用戶登錄進來會看到兩個頁面，分別是消息和待辦。消息主要是顯示當前用戶的消息和待辦事項。消息比如是資金緊張消息，待辦比如是資金下發需要審核的消息。消息和待辦為系統中共用接口，其他模塊來調用，同時需要傳遞代辦的內容和接收人，消息也是如此。

審核流程設計為xml配置模式，審核節點的選擇分為通過與駁回，在xml中來配置審核頁面與駁回之后的跳轉頁面。而審核通過頁面無需設置，通過代表流程結束。每個需要審核的模塊，在提交審核時會調用一個公用的方法，來啟動審核流程，但是需要向這個審核流程接口提供一個參數來告訴這個審核流程啟動哪一個模塊，這時系統就加載之前的xml來指定跳轉頁面。

附件上傳下載主要是針對一些資料的發送和下載。資料可是審核文件，也可以是發票之類的文件。附件作為系統中必不可少的數據元，附件的上傳與下載我們采用struts2特有的附件上傳功能，這里需要導入文件下載上傳的兩個文件，一個是commons-fileupload-1.2.2.jar，另一個是commons-io-2.0.1.jar。

企業具體業務模塊分析

企業具體的業務模塊分為資金計劃額度管理、收款管理、付款管理、公司業務管理以及數據集成五個主要模塊，各個模塊之前業務又有交叉。

資金計劃管理分為債權回收、資金籌集、資金預算控制、資金計劃發布審核等。債權回收主要是公司記錄外企業或個人對公司所欠債務的管理，包括債務清還時的數據增、刪、改、查以及債務是否到賬的審批流程，和賬務資料附件的上傳與共享等。資金籌集主要是發布公司資金籌計劃，吸納社會資源，資金籌集需走審核流程，與籌集資金得相關附件上傳和籌集計劃的增、刪、改、查。資金預算控制是資金計劃管理中對資金計劃發布的資金數進度最大最小以及是否發送提醒消息的控制。資金計劃發布審核則應用系統公共功能的審核流程。

收款管理主要是收款項目的增、刪、改、查以及收款確認的審核流程。

付款管理同收款管理類似，都是項目的增、刪、改、查以及付款項目的審核流程。

公司業務管理主要是公司內部的項目管理，事務管理。項目管理主要是項目成本預算，項目開支管理，項目收益管理，項目在公司收入來源上占有重要地位。事務管理主要是用戶管理，部門管理，角色管理等等子模塊的增、刪、改、查操作。

3.1總體設計

本節從功能架構，邏輯架構，部署架構三個方面闡述了企業資金管理系統的總體設

計思路和方案。

（1）系統功能架構

整個企業資金管理系統從功能上可以分為基礎數據管理，現金管理，資金交易管理，

風險管理和對外接口構成，如圖4-1 所示：

圖 4- 1 系統功能架構

基礎數據管理是企業資金管理的基礎，用于維護系統其他模塊所需要的一些基礎數據，包括企業組織架構，交易對手信息，交易類型信息，貨幣信息等。

現金管理是企業資金管理系統業務的基礎功能模塊。通過該模塊，企業可以進行現金管理的相關業務的操作。

資金交易管理是企業資金管理系統的核心功能模塊。通過該模塊，企業可以對其投融資交易進行管理。

對外接口子系統是企業資金管理系統對外的接口。通過該模塊，系統可以與諸如行

情系統，銀行系統，預算系統和ERP 系統交換數據。

（2）系統邏輯架構

本系統采用分層架構（Layered Architecture）的設計。從邏輯上分成三層，分別是數據訪問層，業務邏輯層和表現層。

數據訪問層（Data Access Layer）：數據訪問層實現了對數據操作的封裝，提供了對數據庫中的數據進行讀寫的接口。系統需要實現的數據層，就是提供對數據庫中的數據表進行抽象，對外提供對數據進行操作的接口。其他所有的組件都可以通過直接調用數據層接口的方式，獲得或修改數據庫數據，而不用考慮數據庫的具體實現。如圖 4-2 所示，為本系統數據訪問層的結構圖，其中DALFactory 為創建數據訪問層

對象的工廠;IDAL 定義了各種數據訪問操作的接口;SQLServerDAL 和OracleDAL 分

別實現了IDAL 中定義的接口，以支持SQLServer 數據庫的訪問和Oracle 數據庫的訪問;Entities 中定義了數據訪問層需要使用的業務實體對象，對象只有屬性，沒有行為。

圖 4- 2 數據訪問層結構圖

業務邏輯層（Business Rules Layer）：業務邏輯層是系統架構中主要部分。它位于數據訪問層與表示層之間。如圖4-3 所示，IBLL 定義了系統業務邏輯的操作的接口;BLL 是整個系統的核心，實現了整個系統的業務邏輯。從圖中還可以看出，業務邏輯層對數據訪問層的訪問是通過接口模IDAL 來完成的，與具體的訪問邏輯無關，實現了層與層之間的松散耦合。

圖 4- 3 業務邏輯層與數據訪問層的關系

表現層（Presentation Layer）：系統與最終用戶的接口，與用戶發生交互，接收用戶輸入，并將接收到的信息發送給邏輯層處理。展現形式可以是窗口模式（Windows Form），也可以是網頁形式（Web Form）。

（3）典型部署架構

圖 4-4 展示了系統的典型的部署圖。從圖中可以看出局域網用戶，通過使用局域網客戶端（LAN Client）訪問應用服務器，來使用本系統。應用服務器和數據庫服務器部署在企業內部的局域網內。遠程客戶端則可以通過使用VPN（Virtual Private Network）來訪問應用服務。

圖 4- 4 系統部署架構圖

3.2基礎數據管理

基礎數據管理子系統分別從用戶和組管理，用戶權限管理，企業組織架構管理，交易對手的管理，交易類型管理，貨幣管理，假期管理，市場數據管理，信用額度管理，風險敞口管理等數據進行管理。基礎數據管理的目的是對企業資金管理系統需要的基礎數據進行維護，設計上最主要的工作就是對基礎數據的增加（Add），刪除（Delete），修改（Update）和查詢（Query），以及建立相關基礎數據的關系。

3.3現金管理

現金管理子系統包含企業資金池，企業資金計劃，收付款管理，賬戶頭寸管理，賬戶交易管理等模塊，如圖4-7 所示。

圖4- 7 現金管理子系統功能架構

企業資金池是企業現金管理的關鍵和基礎，主要作用是建立企業銀行賬戶的結構和歸集關系;企業資金計劃是由相關人員填報的收付款預測信息，或由ERP 系統導入的應收應付信息（AP/AR）;收付款管理用于記錄企業實際收付款信息，其中付款還可以通過銀企直聯系統進行支付。具體方式將在4.6 對外接口章節中詳細介紹;賬戶交易管理是用于維護企業賬戶銀行對賬單的信息，可以人工輸入也可以通過對外接口導入系統。具體導入方式將在后面詳細介紹;賬戶頭寸管理是用戶維護企業銀行賬戶的可用余額的，可以人工輸入也可以通過對外接口導入系統。下面章節中將具體闡述企業資金池的設計。

現金管理的關鍵數據表及其關系如圖 4-11 所示。其中，表trsDEAL，trsDEAL_TRAN 和表trsDEAL_INPUT_CFLOW 用于存放由收付款管理模塊錄入的實際的收付款交易。表trsSETTLE 和trsSETTLE_DETAIL 存放了實際收付款交易所產生的結算數據;表trsCORP_BANKACCOUNT 用于存放企業銀行賬戶數據; 表trsACCOUNT_POOL 用于存放企業銀行賬戶池的數據; 表trsACCOUNT_POOL_GROUP 用于存放企業銀行賬戶池組的數據; 表trsCASH_FORCAST 用于存放由資金計劃產生的收付款預測數據，和從ERP 中導入的應收應付數據;表trsBANK_ACCOUNT_BALANCE 用于存放企業銀行賬戶的余額數據;

表trsBANK_TRAN 用于存放由賬戶交易管理輸入的銀行對帳單數據。

圖 4- 8 現金管理模塊關鍵數據表

3.4資金交易管理

資金交易管理模塊是企業通過各類金融工具進行資金交易的平臺。首先，在模塊的分類設計上，本系統考慮了交易市場、交易目的、交易期限的因素，將資金交易設計由五大模塊組成：

①外匯交易管理模塊：主要功能是負責外匯即期，外匯遠期，外匯掉期的錄入和交易后續的管理。

②債券交易管理模塊：主要功能是負責債券發行、債券買賣的錄入和交易后續的

管理。

③票據交易管理模塊：主要功能是負責票據發行、票據買賣的錄入和交易后續的

管理。

④對沖交易管理模塊：主要功能是負責利率期權，利率掉期，遠期利率協定這些

對沖交易的錄入和交易后續的管理

⑤長期資金交易管理模塊：主要功能是負責長期貸款和長期投資交易的錄入和交

易后續的管理。

⑥短期資金交易管理模塊：主要功能是負責短期貸款和短期融資交易的錄入和交

易后續的管理。

（1）交易審批流程

從資金交易的錄入到交易進入結算這個過程，系統在設計上可以最多支持配置兩個審批節點，分別是審核（Check）和授權（Authorize）。如圖4-16 所示為系統資金交易審批的流程。

首先前臺交易員通過系統進行交易錄入，錄入交易的基本信息。

接著系統會進行敞口或限額的檢查，如果額度超限，系統會提示交易員做限額的調整，待交易員調整限額或修改交易金額后，系統會再次進行限額檢查;

然后，如果交易沒有超限，系統會對交易作審核狀態的檢查，確定該交易是否需要審核。如果需要審核，則系統提交交易給交易審核員審核，如果交易被審核通過，則系統對交易進行授權狀態檢查;如果不需要審核，則系統直接對交易進行授權狀態檢查。

最后，待系統檢查授權狀態后，如交易需要授權，則系統提交交易給交易授權員進行授權，如果交易通過授權，則交易進入結算流程。如果交易不需要授權，則交易直接進入結算流程。

圖4-9 交易流程圖

（2）結算審批流程

同樣對于結算流程來說，系統在設計上可以最多支持配置兩個審批節點，分別是審核（Check）和授權（Authorize）。如圖4-9 所示為系統結算審批的流程。

首先結算人員通過系統錄入或修改結算信息。接著系統會根據錄入的結算信息判斷結算信息是否需要實際的結算。如果不需要，結算過程完成;如果需要，系統進行結算審核狀態檢查。

然后，系統會對結算信息做審核狀態的檢查，確定該結算信息是否需要審核。如果需要審核，則系統提交該結算信息給結算審核員審核，如果結算被審核通過，則系統對結算進行授權狀態檢查;如果不需要審核，則系統直接對結算進行授權狀態檢查。

最后，待系統檢查授權狀態后，如結算需要授權，則系統提交結算給結算授權員進行授權，如果結算通過授權，則交易結算成功。如果結算不需要授權，則交易結算完成。

圖4- 10 結算審批流程圖

3.5風險管理

本系統中風險管理子系統包括情景分析和在險價值（VaR）的計算。

（1）情景分析

目前本系統支持兩種情景分析，分別是利率情景分析和匯率情景分析，情景分析計算流程如圖4-211 所示

圖 4- 11 情景分析流程圖

圖 4-11 中，確定分析對象是用戶選擇需要進行情景分析的資產或者負債;接著，用戶需要確定分析的基準，比如利率情景分析，用戶需要選擇某一天的利率收益率曲線（Yield Curve）作為比較基準;然后，用戶需要確定分析情景，比如利率上移5 個基點（BasePoint）或下降5 個基點（Base Point）;最后，系統利用設定的情景，計算資產或負債在該情景發生時的貼現值NPV（Net Present Value）。系統專門設計了一個 NPVCalculator 類，來計算NPV。要計算資金或負責的NPV，最重要的就是要確定貼現因子（Discount Factor），計算Discount Factor 的公式如下：

Df =1/（1+ Rate×Days） / DIY （4-2）

其中 Df 代表貼現因子，Rate 代表市場利率，Days 代表估值日期到當前的天數，DIY

代表一年的天數，一般為365 或360。

（2）VaR 的計算

目前系統支持“方差-協方差”方式計算VaR 值

“方差—協方差”法是運用歷史數據，計算資產組合的 VaR 值。其基本思路為[21]：

首先，通過歷史數據計算出資產組合的收益的方差、標準差、協方差;

第二，將資產組合收益模擬為正態分布形式，可以計算得出反映分布偏離均值程度的臨界值;

第三，建立各個數值與風險損失的關系模型，推導 VaR 值。

系統設計了一個 VaRCalculator 的類，用于計算VaR 值。計算公式為：

VaR =ω *α *σ Δt

其中ω 為持有期初資產的價值，α 為置信水平，Δt為持有期，σ 為協方差，σ 可用以下公式計算

3.6對外接口

一般來說，企業資金管理系統對外接口主要包括以下4 個部分：銀企直連系統接口，ERP 應收/應付（AP/AR）數據接口，市場數據接口，以及預算數據接口。但是為了應對未來可能與其他企業信息系統接口的需求，所以系統的接口必須非常的靈活。本系統中對外接口的核心是數據傳輸引擎（Data Transfer Engine），其作用主要有兩點：

（1） 將系統內的一些基礎數據（例如：銀行帳號信息）和支付數據導出系統，并形成平面文件（例如：XML，CSV）。

（2） 將其他系統產生的平面文件所包含的信息，導入系統，供相關模塊使用。

數據傳輸引擎的結構

（1） 其中Data Definition 被稱為數據定義器，該數據定義器有兩個作用：

在數據傳輸引擎執行導出任務時，確定系統中哪些數據可以被導出;

在數據傳輸引擎執行導入任務時，確定哪些外部數據可以被導入。

（2） Data Mapping 被稱作數據映射器，其也有兩個作用：

在數據傳輸引擎執行導出任務時，確定導出文件的格式

在數據傳輸引擎執行導入任務時，確定導入的數據與系統的內部數據的對應關系。

（3） Data Transfer 被稱作數據傳輸器，其作用是執行已經被數據定義器定義過，并由數據映射器作過映射的數據傳輸任務。

4系統實現

4.1系統實現

（1）實現環境

本系統的開發的操作系統主要采用 Windows Server 2003 R2 Standard Edition &

Enterprise Edition。集成開發環境采用Visual Studio .Net 2005 Sp1，源代碼版本控制采用Visual SourceSafe 6.0d，數據庫采用SQL Server 2000SP4 和Oracle 10.2.0.3，開發語言C#.NET 和ASP.NET，報表工具為Crystal Report XI。

（2）功能實現

本章節將通過外匯交易管理為例，介紹系統的功能實現。

首先，外匯遠期交易的錄入。圖 5-1 顯示了系統外匯交易的錄入界面。

圖 5- 1 外匯遠期交易錄入界面

從圖5-1粗體字為必填項。填好所有的必填項，交易就可以保存了。保存交易時，系統會根據交易金額和所選風險敞口，計算交易是否超限，如果交易超限，系統會提示用戶。如沒有超限，系統會正常保存交易。

交易保存后系統會自動生成交易單（Deal Ticket），如圖5-2 所示

圖 5- 2 外匯遠期交易單

交易被保存以后，交易就進入審批流程，圖5-3 顯示了交易審批的主界面。

圖 5- 3 交易審核授權主界面

從圖5-3 中紅色橢圓標注的地方可以看出交易目前只需要授權（Authorize），而不需要審核（Check）。

待交易被審批通過后，用戶就可以在系統內管理交易的狀態和交易的頭寸信息了，

圖5-4 顯示了系統處理外匯遠期交易管理的主界面。從圖中標注紅色橢圓的地方可以看出，目前該交易可以進行的操作為提前交割（Pre-Deliver），展期（Roll Forward），交割 （Deliver）和查看交易歷史明細和產生的現金流（History）。

圖 5- 4 外匯交易狀態管理

圖5-5 顯示了交易的明細和產生的現金流。

圖 5- 5 外匯遠期交易明細

5系統測試

5.1測試的目的與目標

在此系統進行初步實現之后，開始進行對系統進行測試，找出系統中存在的Bug，通過測試，用提交的Bug報告來為以后軟件的改進提供標準和參考，能夠在以后的系統改進中找到依據。

測試后的軟件各模塊基本功能可以順利進行，盡可能的提高軟件的健壯性。

5.2測試方法

從是否關心軟件內部結構和具體實現的角度劃分：黑盒測試和白盒測試;

從是否執行程序的角度：靜態測試和動態測試;

從軟件開發的過程按階段劃分有：單元測試、集成測試、確認測試、系統測試、

驗收測試、回歸測試、Alpha測試、Beta測試，單元測試又稱模塊測試，是針對軟件設計的最小單位 ─ 程序模塊（這里所說的程序模塊在Java中一個模塊就是一個方法）。

5.3測試結論

把開始的代碼寫得越好，它出現的錯誤也就越少，你也就越能相信所做過的測試是徹底的。系統化測試以一種有序方式設法探測潛在的麻煩位置。同樣，毛病最可能出現在邊界，這可以通過手工的或者程序的方式檢查。自動進行測試是最理想的，用得越多越好，因為機器不會犯錯誤、不會疲勞、不會用臆想某此實際無法工作的東西能行來欺騙自己。回歸測試檢查一個程序是否能產生與它們過去相同的輸出。在做了小改變之后就測試是一種好技術， 能幫助我們將出現問題的范圍局部化，因為新問題一般就出現在新代碼里面。

測試和排錯常常被說成是一個階段，實際上它們根本不是同一件事。簡單地說，排錯是在你已經知道程序有問題時要做的事情。而測試則是在你在認為程序能工作的情況下，排錯是在你已經知道程序有問題時要做的事情。而測試則是在你在認為程序能工作的情況下，為設法打敗它而進行的一整套確定的系統化的試驗。

Edsger Dijkstra有一個非常有名的說法：測試能夠說明程序中有錯誤，但卻不能說明其中沒有錯誤。他的希望是，程序可以通過某種構造過程正確地做出來，這樣就不再會有錯誤了，因此測試也就不必要了。這確實是個美好生活的目標，但是，對今天的實際程序而言，這仍然還只是一個理想。所以應該集中精力討論如何測試，如何才能夠更快地發現程序錯誤，如何才可以使得工作更有成效、效率更高。

6結束語

本文首先介紹了系統的背景與意義，對于企業資金管理業務進行了細化和設計，接下來又簡單分析了這個系統的實現方式與數據庫設計。北京尚誠致遠科技有限公司的資金管理監控系統是本人應用所學計算機理論知識的一次成功實戰。深切理解了面向對象的變成思路與MVC的設計模式。更認識到計算機對人們生活的改變無處不在，對于傳統行業的轉型至關重要。傳統行業更加高效的運營與管理離不開企業的信息化建設，同時也希望我國各行各業的信息化建設也越來越完善。

參考文獻

[1]種新文.面向對象的管理信息系統分析與設計[J].科技信息，2007，02：23-25

[2]孫鑫.Struts2深入詳解[M].電子工業出版社，2008

[3]薩師煊，王珊.數據庫系統概論[M].北京：高等教育出版社，2002

[4]邵維忠，楊芙清.面向對象的系統分析[M].北京：清華大學出版社，2003

[5] Ray Harris. Murach’s JavaScript and DOM Scripting，2009.9

[6] Gordon S. Linoff， Michael J. Berry. Data Mining Techniques： For Marketing， Sales， and Customer Relationship Management，2011.4

[7] Jiawei Han， Micheline Kamber， Jian Pei. Data Mining： Concepts and Techniques， Third Edition，2011.7

[8] 張曉東.Java 數據庫高級教程[M].北京：清華大學出版社，2002.

[9] 姜芳艽.DBMS 與 DSMS 的比較研究[J].微計算機信息，2011，23（2）：158-160.

[10] Couch J 著.馬琳譯.JavaEE 寶典[M].北京：電子工業出版社，2012.

[11]魏從剛，何衛平，王建利等.基于 JavaEE 的分布式項目管理系統應用研究[J].制造業自動化，2010，26（11）：62—65.

[12]安淑名.加強流動資金管理的對策[J].發展，2006，11（2）：23-25.

[13]林祝春.銀企互聯模式探討[J].華南金融電腦，2006，9（4）：34-37.

[14]姬愛華.淺談對銀行承兌匯票的管理[J].煤碳經濟研究，2006，5（3）：18-19.

[15]朱小華，馬筱融.談談流動資金管理電腦化問題[J].上海金融，2006，8（6）：24-25.

[16]王儒.論強化公司流動資金管理[J].經濟與管理研究，2006，24（3）：56-58.

[17]桑楠.嵌入式系統原理及應用開發技術[M].北京：北京航空航天大學出版社，2002.

[18]賀貴明，定清.管理系統的面向對象模型設計[J].計算機研究與發展， 1994， 31 （09）： 61-65.

[19]謝子松.基于 UML 的工作流建模的研究與應用[J].計算機系統應用，2005，1（2）：57-58.

[20]林祝春.銀企互聯模式探討[J].華南金融電腦，2006，9（3）：45-47.

[21]Emit R Powell SG Manufacturer incentives to improve retail service level[J]. European Journal of Operational Research，1998，104：437-450.

[22]程剛.公司集團信息系統的建設[J].中國信息導報，1998，7（3）：13-16.

[23]Thomas Novak， Donna H off man， Adam Detached ，The Influence of Goal—Directed and Experiential Activities on Online Flow Experiences[J]， Journal of Consumer Psychology，2003.6

[24]程剛. 論公司集團信息系統的建設[J].決策借鑒，2007，16（3）：40-42.

[25]榮敦河.資金管理系統研究生論文.大連理工研究生論文，200868

[26]劉星星.基于 B/S 模式的學生信息管理系統[J].軟件導刊，2006.