1、【精品文檔】如有侵權，請聯系網站刪除，僅供學習與交流高校學費收費管理信息系統分析與設計.精品文檔.高校學費收費管理信息系統分析與設計摘 要 隨著校園網環境的建設和學校教務管理改革的進一步深化，學生收費的工作模式已經從原來的學校院系二級管理模式轉變為學校一級管理模式。本文提出的基于校園網的學生收費系統，采用了Client/Server開發方式，給學生提供了靈活方便的收費服務，提高了學校收費管理部門的工作效率，并為其它部門和相關人員提供實時收費信息服務。關鍵詞 學生收費系統；綜合教務管理系統；結算中心；收費標準Abstract With the development of campus netw

2、ork and the reformation of educational administration, the mode of tuition administration has changed into one administrative level from two administrative levels. The tuition system based on campus network, described by this article, adopt the method of C/S, provides convenient service for students

3、, improves work efficiency of tuition administration department, and provides real-time information service for other departments and persons.Keyword tuition system; all-around educational administration system; center of settling account, tuition standard1 緒論1.1 開發背景近幾年，很多高校都在不斷擴招，擴招后的高校在加大硬件設備建設的同

4、時，也在不斷的調整、完善學校的教務管理，隨著學校教務管理改革的進一步深化，教務管理各個環節的相關數據都由各個院系集中到學校，形成了全校性的網絡共享數據庫，縮短了信息流通的渠道，在數據的及時性、一致性、共享性等方面上都取得了顯著成效。為適應學校集中管理模式開發西安石油大學網上綜合教務管理系統，大大促進了學校教務管理工作的規范化、科學化，為廣大教師和學生提供了大量的信息服務。學生收費作為學校綜合教務管理系統的一個重要環節，對教務系統的其它環節有著很大的影響，特別是針對學生的管理。舊的收費系統，功能簡單，只是在一定程度減輕操作員的計算量，任務仍然很繁重、過程復雜、統計量大，而且容易出錯、不方便管理。

5、顯然舊的系統已經不能滿足現在管理的要求，因此，學校決定采用新的收費軟件來完成操作人員大量的計算、統計、查詢工作，減輕操作人員的工作量，提高工作效率。同時能夠為相關的部門提供及時的、準確的、完整的信息。新的收費系統需要從教務處獲取學生類別和收費標準，給注冊、選課提供學生交費信息，同時給教務處、研究生部、財務處等部門提供收費信息服務和決策支持。(1) 相對于舊的收費系統，主要解決了以下問題：l 所有學生直接去收費中心交費，安全方便，同時省去了很多麻煩。l 學生可以根據實際情況通過現金、匯款、儲蓄存折、支票等方式交費。l 新的收費模式給其它部門和相關人員提供實時的統計查詢功能。l 學生交費與學生注冊

6、相關聯，而學生注冊與學生選課相關聯，從而解決了學生拖費欠費的老問題。(2) 社會上其它的收費系統應用對象比較廣，但功能不夠具體，無法滿足特定管理體制下的收費管理系統的要求在系統開發之前我們有必要對系統進行總體規劃，確定系統的目標并進行可行性分析。1.2 新系統規劃1.2.1 新系統總體目標設定及可行性分析(1) 新系統目標設定高校學費收費管理信息系統的主要目標是：實現相關部門之間的信息共享，保證信息傳遞的準確、完整；采用簡捷的圖形化人機界面，操作簡單、容易，提高工作效率；對各種數據匯總，進行輔助決策。(2) 可行性分析可行性分析主要是根據信息需求和資源環境等約束，判斷高校學費收費管理信息系統的

7、的必要性和可能性。分別在技術、經濟和開發環境上對高校的學費收費管理信息系統進行可行性研究。（1）技術上的可行性。一方面，學校有較好的科學管理基礎，現行系統基礎數據比較完整、合理。有利于歷史數據的轉換和載入；另一方面，學校具有較好的計算機配置和網絡實施，學校更有很好的內部局域網。新的系統無論在軟件還是硬件方面都不會有大的困難。（2）經濟上的可行性。經濟上的可行性包括資金上的可得性和經濟上的合理性。資金上的可得性。學校高層領導十分重視學校信息化建設，對各項信息建設都有足夠的資金投入，所以在資金上的需求不成問題。經濟上的合理性。系統帶來的經濟效益主要表現在間接的效益上，這些間接效益表現在：節省了人力

8、，降低了勞動強度；通過計算機管理，降低了成本和其他管理費用；提供很好的匯總和查詢功能，可以進行輔助決策；為相關的部門提供及時、準確的共享信息。（3）管理上的可行性。學校合理的管理體制，為現行系統提供了比較完整的基礎數據，也為新系統的運行提供了保障。（4）開發環境上的可行性。該系統的開發得到了組織中各層人員的支持配合，給系統開發提供了一個很好的開發環境。1.2.2 開發方法及工具的選用該系統采用客戶機/服務器體系結構。系統開發采用面向對象系統開發方法，程序設計按照應用層的不同分為前臺和后臺，前臺主要為數據收集、客戶端信息處理和信息查詢服務。后臺的程序主要完成數據更新和數據訪問。在后臺采用Micr

9、osoft SQL Server 2000 數據庫系統，系統開發工具選擇Microsoft Visual Studio 2003 .NET可視化集成開發環境在完成新系統的總體規劃和可行性分析以及可行性研究報告得到批準后，就進入了系統分析和設計階段。2 系統需求分析這部分主要完成系統的管理結構分析和功能需求分析。2.1 管理結構分析前面了解到學校的收費管理模式發生轉變，學校管理結構和領導層次關系也相應的發生改變。系統組織結構圖如下：學校財務處收費中心教務處注冊中心各院系圖2-1 組織結構圖其他部門2.2 系統功能需求分析學費收費管理系統能夠同時對本科生和研究生進行收費，但一些高校在本科生和研究生

10、收費管理模式上有較大的區別。2.2.1 本科生收費管理模式本科生收費管理模式的基本流程如下：1 招生辦發出錄取通知書后，新生就可以開始通過銀行匯款進行交費，收費中心從銀行獲得新生所有匯款記錄，手工錄入數據庫（也可以由銀行提供批量數據，系統自動導入）。2 新生報到前，收費中心從招生辦獲取新生數據和新生收費標準信息，以此核對新生匯款信息，最后確定所有正確匯款學生的名單。對學生匯款超過交費標準的部分進行“轉儲蓄”操作，轉入銀行帳號系統，并為其建立個人存折。新生報到時，收費中心負責為匯款學生打印收費收據，有轉儲蓄的打印存折（一般情況下，已經提前全部打完），沒有匯款的新生和匯款不夠的學生可以用現金和支票

11、現場交費。3 注冊中心維護在校本科生的收費標準，本科生的收費標準針對一類學生，即每個學生通過“所屬年級所屬專業”確定他的收費標準，“所屬年級所屬專業”在學生學籍信息里維護。4 本科生交費每年一次，一般要求一次能交清，但也允許先交一部分，在規定的時間內交清所欠部分，超過規定時間就按相關規定收取滯納金。對于未交清學費的學生不給注冊、一直欠費的學生禁止選課和期末考試。對于不用交費的學生通過設置收費標準應交為零實現。2.2.2 研究生收費管理模式研究生收費管理模式的基本流程如下：1 數據準備研究生部每學期從招生辦獲取新入學研究生名單和收費標準，并將數據轉入收費系統。每學期交費前對在校研究生進行收費數據

12、準備，并維護收費標準，一般按照上一年的收費標準確定本次的收費標準。2 研究生的收費標準是針對每個人的，應交費研究生所交費用包括每年應交和一次性應交兩部分，每年應交必須每年按時交納，否則不允許注冊，但一次性應交只要在畢業前交齊即可。3 研究生每學期均有一次收費，通常春季入學的研究生在春季交費，秋季入學的研究生在秋季交費。但欠費的學生可以在任何時間到收費中心交費。4 研究生到收費中心交費允許多交（即預先交納以后幾年的）、少交（雖然交費，但總數不夠，仍然欠費，不允許注冊），也允許一年內多次交費。但收費中心不負責給學生退費，需要退費的學生由收費中心和研究生部協商，手工處理。雖然在一些高校本科生和研究生

13、采用不同的收費模式，但是我校的本科生和研究生采用的是統一收費模式。即上述的本科生收費管理模式。因此，此收費系統采用本科生收費管理模式。2.2.3 基本信息和數據準備模塊(1) 學校組織結構信息錄入：一般的學校體系結構為“年級院系專業班級” ，針對組織結構的管理就是建立學校的各年級資料、各院系資料、各專業資料和班級資料檔案。實現資料的新建、修改和刪除。(2) 學生基本信息錄入：學生基本信息是該系統的重要資料，是收費處理中的最終對象。(3) 收費標準錄入：收費標準是實現收費的前提，也是收費的依據。此系統包括收費標準制定、查詢等；參照對象有：藝術類、非藝術類、專科、本科、研究生。在每次新任務建立時完

14、成收費標準的制定。(4) 收費項目：收費項目指在某項收費任務中的具體收款條目。如學費、住宿費、書本費等。(5) 收款方式：收款方式用于表示學生收/退款時的支付形式，主要是現金、學生帳戶（每位學生在學校都內置了一個帳戶）、轉出（將多繳的部分以轉出到學校一卡通或者校園銀行等的一種找補方式）。2.2.4 收費處理模塊(1) 管理收費任務：主要針對每次收費活動的建立、收費標準錄入、保存學生應收款、以及任務的結存(結轉)等，是一種有條件的為學生批量記費的一種業務處理。任務管理的一般步驟如下：新建任務錄入收費標準保存應收款生成應收款業務操作統計分析(2) 管理收費：管理日常收費（主要用于處理學生在校日常零

15、星的消費業務）、 學生預存（學生將現金預存到學校為每位學生開設的個人賬戶上，如：校園一卡通，以后學生在學校消費時可直接從該帳戶上扣除）。有個人收費和批量收費；批量收款是一種針對選定的收費任務進行批量收款處理的業務處理功能，默認情況下，批量收款的收款方式為“現金” 。(3) 退費管理：有個人退費和批量退費；批量退費主要用于處理成批的滿足退費條件的學生退費業務。默認情況下，批量退款的付款方式為“現金”。(4) 減免管理：根據特殊情況或其他規定實現費用減免。有個人減免和批量減免；批量減免主要用于處理成批的滿足減免條件的學生減免業務。2.2.5 統計分析模塊統計分析是此系統一個非常重要的環節，統計信息

16、給學校教務管理提供決策支持。大部分的報表查詢都是采用先設置查詢條件和范圍，再分析出結果的操作方式。如果有得到正確的查詢結果，就必需設置正確的分析條件。根據院系、年級、專業、班級條件進行收款統計、欠費統計、減免統計以及學生繳費、欠費歷史記錄查詢。2.2.6 系統管理模塊主要完成操作人員管理，數據維護等。(1) 收費系統的操作人員管理收費中心、注冊中心、各院系領導和教務員通過收費系統可以實時查詢學生交費的結果，但系統對不同的登入用戶有嚴格的權限控制，各類用戶使用不同帳號進入系統，各自操作權限范圍內的功能。出于安全性和財務結算制度的要求，收費中心內部不同終端使用不同帳號。收費系統的用戶共分成五類：1

17、 收費中心的管理員：維護收費公共信息，統計收費情況，生成財務統計表。2 收費中心的操作員：面向學生完成收費操作。3 注冊中心的管理員：負責維護本科生的收費標準，學生注冊。4 各院系的領導和教務員：只能查詢本系學生交費情況(2) 數據維護主要是完成數據庫數據的備份和恢復操作。2.3 系統流程分析系統流程分析主要主要包括業務流程分析和數據流程分析。2.3.1 業務流程分析本科生收費管理模式的業務流程分析圖如下：銀行匯款新生匯款單新生收費中心招生辦新生名單收費標準圖2-2 本科生收費業務流程分析核對新生匯款信息正確匯款學生名單轉儲蓄超額學生制定、維護收費標準核對學生信息處理學生收費交清學費學生名單學

18、生注冊注冊中心研究生收費管理模式的業務流程分析圖如下：招生辦研究生名單收費標準制定、維護收費標準數據錄入銀行匯款新生匯款單新生核對學生信息研究生部圖2-3 研究生收費業務流程分析注冊中心2.3.2 數據流程分析根據本科生收費管理業務流程圖，可以得出本科生收費管理頂層DFD圖。如下：招生辦注冊中心收費管理系統新生名單收費標準報表圖2-4 本科生收費管理頂層DFD圖教務處報表對頂層數據流程圖2-2進行細分招生辦新生名單圖2-5 本科生收費管理第一層DFD圖注冊中心收費標準報表2任務管理1基本信息管理3收費管理4統計分析院系教務處報表報表組織結構信息基本信息管理模塊的數據流程圖如下：招生辦新生名單1

19、.1錄入數據教務處注冊中心收費標準組織結構信息圖2-6 基本信息錄入DFD圖3收費管理收費管理的數據流程圖如下：新生名單3.2收費處理3.1核對信息3.3匯款學生統計匯款學生名單3.4收費統計注冊中心教務處圖2-7 收費管理DFD圖3.5退費處理3.6減免處理退費統計表減免統計表收費任務數據流程圖如下：注冊中心3收費管理收費標準2.1新建任務1.1錄入數據生成應收款圖2-8 任務管理DFD圖統計表2.3.3 數據字典前階段的分析收集了大量的數據載體，但這些數據還比較分散，只能局部反映組織的某項業務或部門對數據要求和現有的數據情況。為了對數據進行統一管理、存儲和操作，就應該在數據流程進行描述之前

20、將所有的數據進行統一的規范化處理。數據流程圖描述了系統的分解，即描述了系統由哪些部分組成以及各部分之間的聯系等，但沒有具體說明系統各部分的含義。借助數據字典可以描述數據流程圖中的數據流、數據存儲、處理過程和外部實體。系統建立的數據字典如下：表2-1 學生數據結構數據結構編號：001總編號：1-001名稱：學生基本信息相關數據流、數據存儲：說明：所有學生基本信息 班級信息、交費信息結構：學生編號數量：約20000份 學生姓名 性別 班級編號 當前狀態表2-2 班級數據結構數據結構編號：002總編號：1-002名稱：班級信息相關數據流、數據存儲：說明：所有班級信息 專業信息、年級信息結構：班級編號

21、數量：約300份 班級名稱 專業編號 年級編號 學制 學位 入學時間 當前狀態表2-3 收費項目數據結構數據結構編號：003總編號：1-003名稱：收費項目相關數據流、數據存儲：說明：所有收費項目信息 項目類別結構：項目編號數量：約40份 項目名稱 項目類別 當前狀態 備注表2-4 項目類別數據結構數據結構編號：004總編號：1-004名稱：項目類別數量：約40份說明：所有項目類別信息結構：類別編號 類別名稱 當前狀態表2-5 操作人員數據結構數據結構編號：006總編號：1-006名稱：操作人員數量：約50份說明：所有操作人員信息結構：操作員編號 操作員名稱 密碼 性別 聯系電話 備注表2-6

22、 操作員職務數據結構數據結構編號：006總編號：1-006名稱：操作員職務數量：約50份說明：所有操作員職務信息結構：職務編號 職務名稱 備注表2-7 收費任務數據結構數據結構編號：007總編號：1-007名稱：收費任務數量：約50份說明：所有收費任務信息結構：任務編號 任務名稱 創建時間 當前狀態3 系統設計在設計與開發高校學費收費管理系統過程中，我們遵循學校教務管理的思路，以校園網絡環境和全校性的網絡共享數據庫為基礎，采用Client/Serve開發方式。結算中心、注冊中心、研究生部等單位密切合作，為學生收費系統的順利運行創造了有利環境。3.1 功能結構設計按照收費系統與其它信息系統或數據

23、源之間的數據聯系，以及系統本身的業務流程，可以將系統劃分成四個功能模塊。收費系統的功能模塊圖如下：高校學費收費管理系統基本信息業務處理收費標準維護收費項目收款管理退費管理減免管理統計分析收款統計欠費統計減免統計歷史記錄查詢學校組織結構學生基本信息圖3-1 收費系統主要功能模塊圖系統管理操作員管理數據維護職務權限管理收費任務管理根據功能模塊的劃分可得功能使用者的用例圖，如下：業務處理圖3-2 系統用例示意圖基本信息統計分析系統管理操作員管理數據維護職權管理欠費統計減免統計收款統計歷史查詢減免管理收費管理退款管理收費項目學生信息學校信息收費標準 操作員任務管理3.1.1 基本信息模塊設計(1) 學

24、校組織結構管理：一般的學校體系結構為“年級院系專業班級” ，針對組織結構的管理就是建立學校的各年級資料、各院系資料、各專業資料和班級資料檔案。實現資料的新建、修改和刪除。(2) 學生基本信息：學生基本信息是該系統的重要資料，是收費處理中的最終對象。主要功能有新建、修改和刪除學生資料、學生轉班、休學、復學、退學、畢業等。(3) 收費標準：收費標準是實現收費的前提，也是收費的依據。此系統包括收費標準制定、查詢等；參照對象有：藝術類、非藝術類、專科、本科、研究生。在每次新任務建立時完成收費標準的制定。(4) 收費項目：收費項目指在某項收費任務中的具體收款條目。如學費、住宿費、書本費等。（預選收費項目

25、：學費、住宿費、書本費、體檢費、服裝費、學雜費、借書費、計算機信息費、臥具費、軍裝費、飯卡工本費、疫苗費、證書工本費、注冊費、統考招生費、文體衛生費、班費、自行車保管費、取暖費、畢業證工本費、電教教材代辦費）(5) 收款方式：收款方式用于表示學生收/退款時的支付形式，主要是現金、學生帳戶（每位學生在學校都內置了一個帳戶）、轉出（將多繳的部分以轉出到學校一卡通或者校園銀行等的一種找補方式）。3.1.2 業務處理模塊設計(1) 收費任務管理：主要針對每次收費活動的建立、收費標準錄入、保存學生應收款、審核學生應收款、以及任務的結存(結轉)等，是一種有條件的為學生批量記費的一種業務處理。(2) 收費管

26、理：管理日常收費（主要用于處理學生在校日常零星的消費業務）、 學生預存（學生將現金預存到學校為每位學生開設的個人賬戶上，如：校園一卡通，以后學生在學校消費時可直接從該帳戶上扣除）。有個人收費和批量收費；批量收款是一種針對選定的收費任務進行批量收款處理的業務處理功能，默認情況下，批量收款的收款方式為“現金” 。(3) 退費管理：有個人退費和批量退費；批量退費主要用于處理成批的滿足退費條件的學生退費業務。默認情況下，批量退款的付款方式為“現金”。(4) 減免管理：根據特殊情況或其他規定實現費用減免。有個人減免和批量減免；批量減免主要用于處理成批的滿足減免條件的學生減免業務。3.1.3 統計分析模塊

27、設計統計分析是此系統一個非常重要的環節，統計信息給學校教務管理提供決策支持。大部分的報表查詢都是采用先設置查詢條件和范圍，再分析出結果的操作方式。如果有得到我們想要的查詢結果，就必需設置正確的分析條件。(1) 收款統計：根據院系、年級、專業、班級條件統計分析收費情況。(2) 欠費統計：根據院系、年級、專業、班級條件統計分析欠費情況。(3) 減免統計：根據院系、年級、專業、班級條件統計分析減免情況。(4) 歷史記錄查詢：實現學生的繳費、欠費查詢。3.1.4 系統管理模塊設計主要完成操作人員管理，數據維護等。(1) 收費系統的操作人員管理收費中心、注冊中心、各院系領導和教務員通過收費系統可以實時查

28、詢學生交費的結果，但系統對不同的登入用戶有嚴格的權限控制，各類用戶使用不同帳號進入系統，各自操作權限范圍內的功能。出于安全性和財務結算制度的要求，收費中心內部不同終端使用不同帳號。(2) 數據維護完成數據庫數據的備份和恢復操作。3.2 數據流程設計下面處理系統主要功能模塊的數據流程設計。用戶登錄流程設計如圖3-3：判斷用戶信息用戶存在提示用戶不存在判斷用戶身份是否進入用戶界面圖3-3 用戶登錄流程設計學生收費管理流程設計如圖3-4：選擇學生滿足條件提示學生不滿足條件選擇收費方式是否處理學生收費圖3-4 收費管理流程設計退費管理流程設計如圖3-5：選擇學生滿足條件提示學生不滿足條件選擇退費方式是

29、否處理學生退費圖3-5 退費管理流程設計學費減免管理流程設計如圖3-6：選擇學生滿足條件提示學生不滿足條件選擇減免方式是否處理學生學費減免圖3-6 減免管理流程設計統計分析流程設計如圖3-7：選擇處理任務選擇統計范圍匯總處理圖3-7 減免管理流程設計選擇匯總方式統計表3.3 數據庫設計由系統分析報告可以設計以下的數據庫表。系號字段含義類型1AcademyID唯一編號uniqueidentifier2AcademyNamevarchar3Status可用|禁用bit4CreateDate院系創建時間dateTime表3-1 院系列表（AcademyList）表3-2年級列表（GradeList）

30、系號字段含義類型1GradeID唯一編號uniqueidentifier2GradeNamevarchar3Status可用|禁用bit4CreateDatedateTime表3-3班級列表（ClassList）系號字段含義類型1classIDuniqueidentifier2classNameVarchar3SpecialtyIDuniqueidentifier4GradeIDuniqueidentifier5EnrollmentTime入學時間datetime6SchoolingLength學制int7Degree學位varchar8Statusbit表3-4專業列表（SpecialtyL

31、ist）系號字段含義類型1SpecialtyIDuniqueidentifier2SpecialtyNameVarchar3AcademyIDuniqueidentifier4Statusbit表3-5學生基本信息表（StudentList）系號字段含義類型1StudentIDuniqueidentifier2StudentNameVarchar3ClassIDuniqueidentifier4Statusbit5Sexbit6OffTimedatetime7OffCausevarchar8Predepositionmoney9Balance帳戶余額money表3-6操作人員（Users）系號

32、字段含義類型1userIDuniqueidentifier2userNameVarchar3sexbit4phoneVarchar5mamoVarchar6userPWDvarchar表3-7職務列表（DutyList）系號字段含義類型1dutyIDuniqueidentifier2dutyNameVarchar3memovarchar表3-8收費項目（ChargeItems）系號字段含義類型1ItemIDuniqueidentifier2ItemNameVarchar3TypeIDuniqueidentifier4Statusbit5memoVarchar表3-9項目類別（ItemType）

33、系號字段含義類型1TypeIDuniqueidentifier2TypeNameVarchar3Statusbit表3-10收款方式（GatheringMode）系號字段含義類型1ModeIDuniqueidentifier2ModeNameVarchar3Statusbit4RelationBank是否與銀行關聯bit5mamoVarchar表3-11銀行列表（BankList）系號字段含義類型1BankIDuniqueidentifier2BankNameVarchar3StatusvarChar表3-12任務列表（ChargeTaskList）系號字段含義類型1TaskIDuniquei

34、dentifier2TaskNameVarchar3TaskTypetinyint4CreateDatedatetime5Statusbit6RelateTaskIDuniqueidentifier表3-13任務項目列表系號字段含義類型1TaskIDuniqueidentifier2ItemIDuniqueidentifier表3-14X任務列表（TaskList）系號字段含義類型1StudentIDuniqueidentifier2ItemIDuniqueidentifier3AccountReceivablemoney4Remissionmoney5Refundmentmoney6Gath

35、eringmoney7ReceivableGistVarchar8RemissionGistVarchar9RefundmentGistVarchar10CarryforwordMoneydecimal數據庫表關系圖3.4 輸入輸出設計系統主要使用的輸出方式是屏幕顯示，而系統的主要輸入方式是鍵盤輸入。對輸入的數據是通過程序進行驗證。完成系統設計階段后，就可以進入系統實施階段了。4 系統實施4.1 物理系統實施該系統采用客戶機/服務器體系結構，系統軟件采用windows server 2000或windows server 2000以上版本。4.2 程序設計該系統采用客戶機/服務器體系結構。程序設計按照應用層的不同分為前臺和后臺，前臺主要為數據收集、客戶端信息處理和信息查詢服務。后臺的程序主要完成數據更新和數據訪問。在后臺采用Microsoft SQL Server 2000 數據庫系統，系統開發工具選擇Microsoft Visual Studio 2003 .NET可視化集成開發環境4.3 系統主要程序代碼在具體的程序編寫之前，先對App.co