李翔
摘要:本文根據(jù)實際情況對學生收費管理系統(tǒng)進行需求分析,重點闡述學生收費管理系統(tǒng)的功能模塊設計,以完善、合理的功能模塊讓學生收費管理工作更規(guī)范、便捷和高效。
[關鍵詞]收費系統(tǒng) B/S模式 功能模塊 高等學校
1 研究背景
隨著高等教育的普及,學生總數(shù)不斷擴大,學生收費管理工作難度隨之增大,各項收費包括學費、醫(yī)療保險費、軍訓服裝費、體檢費等均由高校財務部門集中管理。龐大的學生數(shù)量,種類繁多的收費項目使得學生收費工作繁重且效率低下,人工管理方法、現(xiàn)金收費方式和傳統(tǒng)的C/S收費系統(tǒng)已經(jīng)無法適應現(xiàn)狀。使用基于B/S功能齊全的收費軟件,啟用多途徑收費方式、建立數(shù)據(jù)信息共享平臺等,方可提高收費效率、便于統(tǒng)計數(shù)據(jù),實現(xiàn)財務部們對學生收費的現(xiàn)代化管理。系統(tǒng)的功能模塊設計是否完整、合理,決定了系統(tǒng)性能的優(yōu)劣,根據(jù)實際情況對系統(tǒng)的功能模塊進行科學、系統(tǒng)的設計十分重要。
2 學生收費管理系統(tǒng)的需求分析
總結(jié)學生收費管理系統(tǒng)普遍存在的不足之處,并根據(jù)不足之處提出本系統(tǒng)希望實現(xiàn)的功能。
2.1 學生收費管理系統(tǒng)普遍存在的不足之處
傳統(tǒng)的基于C/S的學生收費管理系統(tǒng)普遍存在的不足之處有:用戶界面較呆板,設計美感較差;無數(shù)據(jù)接口,不方便有需要的部門或者個人對數(shù)據(jù)進行訪問;功能模塊不夠齊全、劃分不夠合理,系統(tǒng)管理者不能快速、較易學會使用系統(tǒng);學生無法自行查詢欠費和交費情況,無法獲取實時信息;無法自行通過計算機網(wǎng)頁和手機移動端進行繳費,繳費方式落后、單一。
2.2 本系統(tǒng)需要實現(xiàn)的功能
以滿足學生繳費的實際需求為目的,確定系統(tǒng)設計的基本要求:
(1)友好的用戶界面及數(shù)據(jù)接口,使軟件使用方便,易學易用。
(2)完善和合理劃分功能模塊,方便使用者能盡快理解和熟悉每個模塊的功能。
(3)對不同用戶設定相應的模塊權限,
方便收費人員的分工管理。
(4)學生通過登錄網(wǎng)頁進行繳費,查詢欠費、交費等情況的明細。
(5)查詢功能齊全,實時反映收費動態(tài),可根據(jù)用戶自行定義的條件查詢當期及歷史數(shù)據(jù)。
(6)推出微信公眾平臺、微信在線支付、一鍵查詢等功能,只要學生關注學校公眾號,綁定微信號,便可一鍵查詢自已的欠費情況,還可以接收到與學生收費相關的通知公告,可在第一一時間通過手機來完成各項操作。
3 學生收費管理系統(tǒng)的功能模塊
基于功能需求分析,本文進行了系統(tǒng)的功能模塊設計。如圖1。
3.1 系統(tǒng)的構(gòu)架
系統(tǒng)基于B/S的三層架構(gòu)體系,即瀏覽器和服務器結(jié)構(gòu)。這種模式統(tǒng)一了客戶端,將系統(tǒng)功能實現(xiàn)的核心部分集中到服務器上,在代碼上實現(xiàn)了高內(nèi)聚低耦合,并將應用邏輯層放置在應用服務器上,數(shù)據(jù)層和數(shù)據(jù)訪問層放置在數(shù)據(jù)服務器上,表現(xiàn)層在客戶機上體現(xiàn)的三層體系架構(gòu)。
3.2 系統(tǒng)模塊化實現(xiàn)
3.2.1 用戶管理模塊
(1)平臺角色管理。平臺角色可以自定義角色名稱,為每種角色勾選相應的權限功能,方便用戶管理時無需再重復設置,只需選定角色即可。
(2)平臺用戶管理。平臺用戶管理分為添加用戶以及用戶權限集管理,管理員可以登錄網(wǎng)頁后臺界面添加在校教職工并進行用戶權限管理。權限集管理可以勾選任何功能模板或者使用平臺已設置好的角色進行管理。多選角色類型時,權限功能進行疊加整合。為了滿足對權限有特殊需求的用戶,可以對用戶角色進行自定義授權,對權限進行單個勾選。
(3)密碼重置。密碼重置可以對在校教職工和在校學生進行密碼重置,重置后統(tǒng)一使用123456作為初始密碼,無需再手動重置密碼,方便快捷。當密碼重置后用戶登錄前臺界面將會彈出窗口進行修改密碼操作。
3.2.2 基礎數(shù)據(jù)模塊
(1)組織架構(gòu)管理。組織架構(gòu)分為組織樹和組織類型。系統(tǒng)中首先對高校組織類型即部門類型進行設置,一般高校分為教學部門、行政部門、業(yè)務部門、附屬單位等,各高校的可以根據(jù)具體情況進行增加或刪除。組織樹由學校各個部門組成,在組織樹里增加高校各種組織類型的具體名稱,如教學部門中各學院的名稱、行政部門中各部門的名稱等,并且在設置時選定組織類型,完成組織架構(gòu)的架設。
(2)學生屬性設置。學生屬性包括學生狀態(tài)、學生類型、所屬學院、學生專業(yè)和10個擴展屬性等。學生狀態(tài)根據(jù)在讀、畢業(yè)、退學等進行自定義增刪;學生類型也可以根據(jù)各高校情況自定義為本科生、研究生、??粕阮愋汀3吮匾淖侄瓮膺€可以根據(jù)需要自定義10個擴展屬性字段,例如住宿地址,住宿校區(qū)樓棟等。
(3)學生管理。學生管理對學生基礎信息如學號、姓名、身份證號等進行設置。對學生的詳細信息管理時,可以根據(jù)學生屬性設置的具體內(nèi)容進行選擇和填寫。學生屬性設置能方便學生管理信息的輸入,也保證了信息輸入的準確性。
(4)學生銀行卡管理。學生銀行卡管理適用于需要銀行代扣費用時進行添加,但必須在錄入學生信息后才能進行銀行卡數(shù)據(jù)的添加維護,并選擇銀行卡號和銀行卡名稱進行關聯(lián),以此來保證學生信息數(shù)據(jù)錄入的確準性。
3.2.3 業(yè)務管理模塊
(1)發(fā)票管理。發(fā)票管理針對沒有實現(xiàn)電子發(fā)票的地區(qū)進行非稅票據(jù)的管理,發(fā)票管理員在系統(tǒng)內(nèi)進行發(fā)票號的錄入,并根據(jù)需要分配給負責收費及打印票據(jù)的教工。
(2)應收管理。應收管理可針對學生每個學年或者學期設置各項收費項目的金額。為了滿足各大高校對按學期或者按學年收費的需i求,在應收界面可自定義添加需要收取費用的學年或?qū)W期,創(chuàng)建完成后進入當期應收的學生界面,界面內(nèi)可以根據(jù)查詢學號、學院、專業(yè)等字段進行批量修改,也可以通過電子表格的形式批量導入。
(3)結(jié)算管理。結(jié)算管理分為個人結(jié)算和批量結(jié)算,個人結(jié)算可以單獨通過學號、身份證號進行查詢,顯示當前學生的繳費明細,對沒交清的收費項目進行標注,對已交清的項目提示票據(jù)打印。批量導入可根據(jù)系統(tǒng)提供的電子表格模板導出,由收費管理員按電子表格模板規(guī)范寫入,再與系統(tǒng)進行匹配,校驗通過則導入,失敗則提示失敗信息,為大批量匯款的學生或者由高校輔導員統(tǒng)一代收等信息量大的導入工作節(jié)約大量的時間。
(4)退款管理。退款管理包括單人退費、批量退費和退費處理。收費管理員通過查詢學號和身份證號明確該學生的繳費記錄,需要退費時通過輸入需要退費項來辦理退款,也可通過電子表格的形式輸入包括退費的項目、金額等進行批量退費。當退費成功時會在退費處理頁面顯示退款的明細,最后進行確定退款操作,系統(tǒng)則生成退款明細便于導出操作。這樣可以與銀行進行批量退款的交接,最后通過銀行退款回單進行導入來確定哪些學生退款成功,哪些需要再次核實信息。,
(5)統(tǒng)計查詢。信息系統(tǒng)總少不了統(tǒng)計查詢功能,學生收費系統(tǒng)分為收費情況統(tǒng)計、收費記錄統(tǒng)計、退費記錄統(tǒng)計等模塊,選定特定時段,通過篩選學生屬性信息,選擇各類學生字段進行匯總,滿足了各類匯總統(tǒng)計的需求。3.3收費方式
信息時代的快捷高效,收費方式由最初的現(xiàn)金支付也慢慢過渡到刷卡支付的方式,但這都無法避免在開學季大量學生排隊繳費的情況。在移動支付迅速發(fā)展的當代,學生不但可以通過電腦登錄自行繳費,還可以使用移動支付完成繳費。以微信支付為例,只要申請微信公眾服務號即可開通微信支付接口,我們只需要在服務器應用層調(diào)用微信支付接口與數(shù)據(jù)庫進行實時對接,即可完成微信支付。網(wǎng)絡支付實現(xiàn)了實時對賬的功能,這樣不但解決了繳費時間久、繳費難的問題,還讓學生隨時隨地即可完成繳費,達到師生共贏的目的。
4 結(jié)束語
基于B/S的學生收費管理系統(tǒng)是現(xiàn)今高校學生收費管理系統(tǒng)的主流,推進學生信息化收費管理平臺建設是高校財務信息一體化建設的重要環(huán)節(jié)。基于B/S的學生收費管理系統(tǒng),具有科學、合理的模塊設計,不僅能讓學生收費工作更加便捷,還能讓高校收費管理更加透明,并且在信息化的無現(xiàn)金支付方式下降低財務風險,真正提高財務管理的效率。
參考文獻
[1]唐菁敏,高張寶?;贐/S架構(gòu)的企業(yè)綜合管理系統(tǒng)的研究與設計[J].信息技術,2019(03):144-148.
[2]謝僚僚.高等學校學生收費管理的信息化應用與對策[J].理論研究,2017(04):96-
[3]王曄斐。上海高校財務管理信息化改革探析[J].財務管理,2018(06):145-146.