財務轉賬流程精品(七篇)

序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇財務轉賬流程范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

目前，政府部門、高校、事業單位等一般均有財務核算中心。隨著國家對預算資金監管和使用的相關規范文件出臺，財務集中核算日益發揮著重要的核算和監督作用。財務結算中心一般承擔著本部門或者本企業全部資金的結算任務，資金量很大。日常財務報銷中，根據財務制度規定1 000元以上要求轉賬支付，1 000元以下可以使用現金結算。隨著公務卡強制使用制度的落實，財政預算資金公務卡結算日益增多。面對復雜的結算方式，?x擇一種安全、高效、便捷的結算方式至關重要，非現金報銷方式不失為一種好的結算方式。

一、財務結算中心報銷現狀分析

（一）報銷支付方式多樣。根據預算資金管理相關規定，中央部門日常經費使用，屬于公務卡刷卡目錄的支出，強制使用公務卡刷卡結算，保留刷卡小票報銷，屬于中央財政零余額資金的，記入“待清算公務卡報銷額度”往來科目，每月集中還款一次，通過零余額網銀系統公務卡還款功能支付，方便快捷。屬于非零余額資金的，報銷當時直接用單位卡支付，直接還款到個人公務卡賬戶，隨報隨清。對于現金業務，一般報銷人員提前報用款計劃，報銷時隨報隨清現金。

（二）支付現金存在隱患。根據財務管理規定，為保證資金安全，一般單位當日庫存現金不能超過規定限額，通常要求在800元以下，不同單位可能會有所不同。出納人員根據報銷用款計劃當日支取現金，當日超限額資金要送存銀行。每日取現金需要專車和保安護送，由于銀行業務處理需要一定時間，每天上午時間被取現金占用，下午報賬后現金還要在銀行下班前入庫，導致報賬效率低下，服務質量下降，報銷人員意見很大。同時單位還需要保障車輛和保安人員時刻待命，人力物力浪費很大。出納工作效率不高，疲于在銀行和單位間奔波。被服務單位滿意度很低，形成報賬難、排長隊現象。

（三）財務軟件功能模塊利用率低。財務核算一般都使用了財務核算軟件，有些部門還開發了本部門專用的財務核算軟件。例如氣象部門使用的是某軟件公司開發的A++報賬系統，根據氣象部門特點和具體要求，增加相應模塊滿足日常使用。但是各單位使用中，特色化模塊要求具體使用單位進一步細化和調試。大部分使用單位只使用了系統化模塊，特色化部分懶于使用開發，使軟件利用率低，很多數據分析功能未使用，只開通了日常核算功能模塊。

（四）網銀使用普及不夠。電子支付和銀行網銀支付日益普及，新型結算方式取代傳統方式是時展趨勢。核算中心推行網銀結算方式可以提高支付效率，但是在推行過程中遇到很大阻力：被核算單位領導不重視，認為資金不安全，對開通網銀比較抵制；核算中心出納認為使用程序復雜，不如直接報銷開票便捷，安于現狀，導致網銀普及率低，結算方式不能適應當前信息化核算要求。

（五）崗位分工不能適應信息化要求。傳統崗位分工是會計和出納分管具體核算單位，是按照單位進行崗位分配，具體核算單位業務量多少不一，造成崗位分工不均，需要定期輪崗，不利于被核算單位日常業務精細化管理和長遠發展，影響財務人員工作積極性。信息化條件下，根據財務信息化平臺系統，將財務基礎工作按照標準化、流程化的作業方式進行流程再造，每個崗位流程都有明確職責和分工，每位財務人員可以負責報銷流程的某一環節，實行大平臺管理，使財務報銷實現程式化、標準化、精細化管理。

二、財務結算中心非現金報銷解決方案

（一）開發依托于財務報銷系統的取數軟件。該軟件按照日常報銷中不同結算方式進行分流，尤其是現金業務，在報銷時，根據現金所屬資金來源自動抓取數據，登記領取人信息，定期匯總，集中進行轉賬匯款。例如差旅費報銷中，住宿費使用公務卡報銷、差旅補助使用現金報銷。在出納報銷流程中，公務卡登記在“待清算公務卡報銷額度”科目，現金部分登記在“待清算儲蓄卡報銷額度”，同時按照報銷人分明細登記，定期生成報銷人匯總單。出納根據匯總單資金來源，通過網銀轉賬，上傳發放表，在網銀系統財務發放模塊，支付報銷現金。具體流程如下：

1.單據報銷[公務卡報銷零余額]出納登記零余額網銀錄入會計網銀審核網銀還款打印單據會計記賬。

2.單據報銷[公務卡報銷非零余額]出納單位卡直接還款打印單據會計記賬。

3.單據報銷[現金報銷零余額（非零余額）]出納登記網銀轉賬出納上傳發放表會計網銀審核網銀還款打印發放成功單據會計記賬。

4.單據報銷[匯款報銷零余額（非零余額）]出納錄入網銀轉賬會計網銀審核網銀還款打印發放成功單據會計記賬。

5.工資發放出納錄入網銀轉賬會計網銀審核網銀轉賬出納上傳發放表會計網銀審核網銀發放打印發放成功單據會計記賬。

（二）開通銀行網銀結算。通過開通銀行網銀結算，核算中心率先實行工資全部網銀轉賬發放。根據工資發放流程，使用網銀工資發放模塊，上傳工資數據，工資即刻到賬，發放成功單據及時打印，差錯每筆可查，提高了效率。日常財務現金報賬，做到了每日報賬，每周匯總還款，節約了出納去銀行送單據時間，銀行網銀轉賬一分鐘到款，同時銀行短信設有到款提醒，發放差錯能實時檢測，及時更正，財務報銷基本實行無現金庫存。對于日常轉賬業務，實行網銀轉賬，報銷人員不再拿支票，杜絕了人工填寫錯誤退票現象，報銷人不用再去送支票，節約了時間和金錢。對出納人員，基本不用再去銀行，直接網銀操作就完成了報銷業務，單位車輛費用和安保、司機人員工作量大幅下降。這些措施的施行，被服務單位普遍反映效率提高，職工非常滿意。

（三）制訂崗位職責和內控制度。按照當前信息化管理要求，制訂網銀操作崗位內控流程，銀行網銀密匙有三人保管，錄入員、審核員、主管三人負責，相互牽制，分工明確。制訂各報賬崗位具體崗位職責，做到不相容崗位分離。細化崗位分工，嚴格執行崗位責任制，使日常業務工作統籌化、集約化、程式化管理，提高核算準確度。對每個崗位職責權限有明確規定，出現問題能落實到具體崗位人員。對每筆網銀支付和現金還款都通過電子支付和報賬平臺操作，做到有據可查。

（四）建立財務共享服務結算平臺。適應信息化管理環境，電子發票和網上報賬已經運用到日常結算中，電子支付和無紙化財務報銷新模式正在逐步推廣。財務單據通過報賬錄入終端，原始發票通過高拍?x掃描，存儲電子數據，上傳會計結算中心。結算中心審核人員實時審核，動態顯示票據審核狀態，使報賬直觀高效。電子數據實時存儲，每項業務存儲電子檔案，可以追蹤每筆資金使用情況。電子數據存儲要求單位硬件系統必須足夠強大，網絡設施和網絡資金安全監控要制定嚴密的內控制度，保證資金和數據的安全。同時通過共享服務結算方式的轉變，可以實現財務數據資源共享，在大數據分析系統幫助下，對數據進行多次加工，為單位發展和決策提供數據支持。

三、財務集中核算未來發展方向

（一）電子結算模式更加普遍。財務集中核算已實行很多年，在不斷發展的信息化環境下，財務核算中心要與時俱進。在財務報銷軟件和網銀支付方式普遍被大眾接受的情況下，大力發展電子商務結算模式，充分利用網絡條件，提高支付準確性、效率性，做到每筆業務有跡可查，減少差錯。

（二）財務信息大數據分析被廣泛應用。運用財務大數據分析平臺，對財務數據進行分析、整理，為單位提供更加真實、可靠的參考數據，為領導決策提供數據支持。運用科學化、流程化、標準化的會計結算管理方式，可以保證財務數據核算口徑統一，高效準確。積極設立財務核算軟件系統二次開發項目，對日常財務數據特色化模塊進行開發利用，提高軟件使用率，減輕會計人員工作量。

（三）會計人員業務培訓常態化。國家各項制度和財務核算要求更新迅速，國家對財務數據質量要求越來越嚴格，對預算和決算編制工作更加重視。為了發揮會計監督功能，縮小預決算執行差異率，應重視財務人員的日常業務培訓，狠抓落實審計檢查發現的問題，從源頭入手，加強會計骨干人才培養，制定激勵考評措施，使核算中心能以制度為準繩，以操作流程為主線，規范核算，強化責任，確保各項資金使用安全、合規。

（四）“互聯網+”多種新型服務方式并存。財務核算不僅對核算數據要求準確，服務質量也要求有更高的水平。

1.“碼”上知道?；ヂ摼W時代財務共享服務中，通過把被服務單位需要了解的相關政策梳理拆分，形成便于報賬人理解和使用的知識點，并以二維碼為載體向報賬人推廣。報賬人使用移動終端掃描二維碼即可獲取相關財務報賬政策。通過局域網政務系統平臺鏈接單位財務平臺，使分管單位能隨時查詢資金使用情況、預算執行情況。

篇(2)

[關鍵詞] 網絡銀行；數字化校園；信息化；財務繳費系統；

[中圖分類號] F832.2 [文獻標識碼] A [文章編號] 1006-5024(2007)12-0166-03

[作者簡介] 申 凱，東華理工大學教授，研究方向為財務管理；

侯志才，東華理工大學教師，研究方向為財務管理；(江西 撫州 344000)

李忠青，江西投資房地產有限公司總經理，研究方向為企業管理。(江西 南昌 330096)

現代化的學校離不開現代化的管理。管理信息化水平正在成為衡量學?？傮w水平的重要因素之一， 也是學校管理能否達到國內高水平大學的重要標志。校園一卡通系統作為數字化校園的基礎工程，是數字化校園中有機的、重要的組成部分；為數字化大學提供全面的數據采集平臺，結合大學的管理信息系統和網絡，形成全校范圍的數字空間和共享環境；為大學管理人員提供具有開放性、靈活性的應用服務管理平臺，是管理與管理科學化的必要前提和基本途徑。將給全校師生帶來一種全新的、現代化的生活。

一、基于個人網絡銀行的財務繳費系統架設總體規劃

1.財務繳費系統的總體結構拓撲圖。本系統采用多層C/S架構，由于在客戶端與數據庫之間加入了一個“中間層”，就使得業務規則、數據訪問、合法性校驗等工作放到了中間層進行處理。客戶端不直接與數據庫進行交互，而是通過中間層建立連接，再經由中間層與數據庫進行交互，建立在中心數據庫服務器上的連接數量將大大減少，并且是動態建立與釋放連接，因此客戶端數量將不再受到限制。當業務規則發生改變時，只需更改中間層服務器上的某個組件，而客戶端應用程序不需做任何處理，有時甚至不必修改中間層組件，只需要修改數據庫中的某個存儲過程。

2.基于個人網絡銀行的財務繳費系統功能模塊設計

二、架設基于個人網絡銀行的財務繳費系統硬件及軟件條件

通用硬件設備包括發卡中心數據庫服務器、前置機、銀校轉賬服務器、一卡通應用服務器、接入服務器、磁盤陣列、交換機、路由器、加密機、發卡中心發卡設備。專用硬件設備包括消費POS、圈存機、自助終端、讀卡器、充值機。通用軟件包括SCO Unix系列操作系統、Oracle 數據庫、Win2000操作系統、SQL Server2000數據庫。應用軟件即各類子系統。

三、各功能模塊設計

(一)網上交易的必要條件和客戶端界面設計說明。本系統的上位機是依附于銀行的安全機制，用戶的銀行卡消費全部發生于銀行系統內部，因此具有極高的安全性，商戶與網銀中心的數據交互的特點：數據金額比較小，交易后對賬機制，鑒于以上特點，在這一塊上安全不要求太高，因此數據傳輸采用URL方式，即本系統形成含有網銀規定的接口參數FORM，用POST方式向網銀中心提交，返回信息同理，數據傳輸過程采用數字簽名和DM5加密方式。歸結如下：

1.網上支付使用條件?？蛻粢言诮ㄔO銀行簽約，申請網上支付服務，簽約的賬戶(信用卡或儲蓄卡賬戶)可用于網上支付，網上支付的結算范圍不能超過建行網上銀行的轄區范圍。

商戶與建設銀行簽定協議，銀行為其提供結算賬戶與網上預申請密碼等，網銀中心受理并核發CA證書，建立商戶信息維護表。

2.網上支付流程

(1)客戶登錄學校WEB網站，選擇需辦理轉賬業務類型。

(2)客戶選擇付款的銀行――建行，確認后，商戶代碼、訂單信息、合計金額通過瀏覽器URL傳到建行網上銀行站點；網上銀行自動顯示支付頁面，客戶首先選擇是否使用建行證書，然后輸入龍卡號和密碼，選擇“確定”。支付信息經加密后傳送到網銀中心。

(3)網銀中心接收客戶支付信息，轉發到銀行后臺業務處理系統。

(4)銀行后臺業務系統處理后，返回處理結果給網銀。

(5)網銀通知客戶支付(扣賬)是否成功。如果扣賬成功，提示客戶注意接收商戶返回的送貨信息；立即響應的商戶，如果支付成功，網銀將成功結果反饋給商戶。若支付失敗，不返回給商戶信息。

日結時，商戶與開設結算賬戶的建設銀行(網銀成員行)進行流水核對，對已支付但未得到商戶確認的交易進行相應的處理。

3.客戶使用建行證書。客戶在商戶網站選擇建行支付后，被鏈接到建行網上銀行網站。該鏈接將商戶名、柜臺號、定單號、金額，驗證信息傳到網上銀行系統(建行提供無密鑰的MAC算法)。客戶進入建行網上銀行系統時選擇是否使用建行證書進行支付。如果是建行簽約客戶，可以選擇有證書支付。如果客戶沒有與建行簽約，只能使用無證書支付。

4.網銀系統返回信息。網銀系統返回給商戶成功或失敗信息(按商戶類型，分兩種情況進行處理)。

(1)對于不需要實時反饋支付結果的商戶，直接將支付結果通過瀏覽器顯示給客戶。

(2)對于需要實時反饋支付結果的商戶，將支付結果返回客戶，同時，如果支付成功，將結果和數字簽名信息(注：簽名算法和簽名內容由建行指定)反饋給商戶，簽名校驗成功后，進行后續處理；如果支付失敗，不再通知商戶。

5.學校的交易款結算與對賬流程。學校在建行開設專用結算賬戶?？蛻粼诮ㄐ芯W上銀行支付功能下付款，貨款記入學校的專用結算賬戶(含定單號信息)。學?？赏ㄟ^瀏覽器登錄建行網上銀行，可實時查詢網上支付流水，也可在商戶本地數據庫中查到支付信息(但建議登錄網上銀行查詢)，學校也可通過瀏覽器下載對賬文件(支付流水清單)，該文件上的每筆貨款已成功支付。

(二)WEB客戶端前臺模塊。WEB客戶端提供用戶與銀行之間的轉賬服務，提供校園一卡通轉賬、學費繳納轉賬及轉賬信息查詢功能。登陸時默認為一卡通轉賬頁面，用戶只需在下拉菜單選擇所需服務即可。

一卡通充值轉賬、學費轉賬兩者類似，用戶需填寫自身驗證(如：學號)及其他的相關信息，點擊確定之后即可通過鏈接進入網銀系統，最后用戶填寫銀行的相關資料器，點擊提交之后，由網銀中心向學校銀行接口機發送相應的轉賬信息，并返回轉賬成功信息。否則，返回失敗信息，如：驗證信息不正確、轉賬金額超出銀行卡余額等。

轉賬信息查詢：用戶輸入自己的學號，銀行服務器根據學號查詢相應的轉賬信息，如果有轉賬，向用戶界面發送轉賬信息，否則，返回查詢不存在。

用戶消費查詢：用戶可根據一定的條件查詢自己在校園的消費情況。

(三)后臺管理模塊。主要完成系統消息，如一些校內繳費、充值情況、站內公告內容管理等；系統參數修改，如修改商戶、銀行代碼、等級考試等相關參數；數據校對，主要校對學校銀行接口機上的交易記錄與銀行的記錄是否一致。

(四)銀行接口機模塊設計。本子模塊主要實現與銀行服務器和圈存機的通信和數據處理，是整個系統的通信樞紐，接口機的設計主要包括：

接口機socket通信程序：接收并處理來自圈存機的驗證信息。

接口機數據庫設計：存儲轉賬信息，以及基本的數據庫操作語句。

PC機與89C51單片機的串口通信程序：實現與單片機的串口通信程序，主要用于設定圈存機的IP地址。

1.繳納學費處理流程。銀行服務器在接到繳納學費的信息后，在更改用戶的龍卡余額的同時，將接收到的相關用戶信息生成唯一標識的訂單號(這是個非常重要的序列號)。然后將訂單號經相關處理后(如md5加密和數據字簽名)，傳送給學校銀行接口機交由其進行相關的處理。學費繳納不存在學生圈存的行為，當接口機接收到成功的轉賬信息后，財務中心的服務器會實時地接收到轉賬記錄，為了確保正確性，財務處還需做數據校對工作。

2.“一卡通”充值處理流程。與學費繳納的處理流程相似，銀行服務器在接到轉賬充值的信息后，在更改用戶的龍卡余額的同時，將接收到的相關用戶信息生成唯一標識的訂單號(這是個非常重要的序列號)。然后將訂單號經相關處理后(如md5加密和數據字簽名)，傳送給學校銀行接口機交由其進行相關的處理。當接口機接收到成功的轉賬信息后，提示用戶充值成功，學生在確認轉賬成功后，到圈存機上進行圈存，為確保學生轉賬信息的安全和準確的到達接口機上，財務部門要采取相關的校對措施對數據進行有效快速的校對。

(五)圈存機模塊設計。圈存機上用于控制信息的顯示和信息數據包的通信，數據的通信包括：單片機與單片機的通信，單片機和PC機(銀行接口機)的通信。主要工作有電路的連接，相關部件的控制和邏輯控制。

(六)系統后臺數據庫模塊設計?？傮w設計思路：所有上位機軟件只操作銀行接口機上的數據庫，銀行接口機數據庫中的表分二部分：(1)本地創建的信息表；(2)來自于一卡通中心服務器和財務處服務器上的表(通過合并復制技術保持這些表在三個不同數據庫服務器上的同步和一致，即當銀行接口機上對應的表數據發生變化時，一卡通中心服務器和財務處中心服務器的表數據也要發生相應的變化，反之亦然)。

1.數據安全保密設計。采用用戶名和密碼對SQL2000服務器進行登錄驗證，充分利用WINDOWS操作系統的安全機制來彌補數據庫安全漏洞，防止偽造非法登錄數據庫服務器。

只有特定的用戶可以訪問和查看數據。具有相應修改權限的用戶才能更改數據，即基于角色分配權限模式，堅持“最小權利”原則。使用視圖和存儲過程以分配給用戶訪問數據的權利，盡可能不讓用戶編寫一些直接訪問數據的特別查詢語句。

建立完善數據規則、關聯性，維護數據的統一、完整性，形成一條健康的數據訪問規則和數據之間的關系鏈。充分使用存儲過程，減少網絡中的流通量，加強數據的安全性。

2.網絡通訊與數據安全。本系統的上位機是依附于銀行的安全機制，用戶的銀行卡消費全部發生于銀行系統內部，因此具有極高的安全性。數據傳輸采用URL方式，即本系統形成含有網銀規定的接口參數FORM用POST方式向網銀中心提交，返回信息同理，數據傳輸過程采用數字簽名和DM5加密方式，上位機軟件采用基于角色的權限代碼防問、強名稱制、驗證碼等技術。

上位機與下位機數據交互采用SOCKET通訊，對接發數據進行加密，采用何安全方式待定。

讀卡機與卡片的信息交互采用無線通訊，運用密碼驗對的機制，如：其卡的KEY-A密碼/ KEY-B密碼必須與售飯機的密碼一致)，KEY-A密碼=“XXXXXX”； KEY-B密碼=“XXXXXX”；操作控制C10 C20 C30=XXX，另根據卡片出廠唯一的地址號進行加密設計即一卡一密，以保證讀卡數據的正確性、合理性、防偽造性。

四、基于個人網絡銀行的財務繳費系統應用前景

以校園卡系統為平臺，充分利用銀行的金融服務，實現以人為本，從大學環境、資源到活動的全部數字化管理，將滿足大學數字化建設的需求及目的，將大大降低辦學成本。

參考文獻：

篇(3)

市場需求和教學現狀分析

傳統的出納實務教學主要存在以下問題：一是教學內容上，出納實務沒有作為一門獨立系統的課程進行學習，出納知識只是作為會計的部分章節；或者有的院校雖然單獨開設了出納實務課程，但教學內容還是以會計核算為主，涉及出納的教學內容比較單一，多以現金業務和銀行結算業務為主，與現實性、前沿性不符合，與實踐聯系不緊密。二是教學方式上，大多依靠多媒體課件講授，雖然部分教材按項目和工作任務編排，也設計了崗位實訓所需的一些單據，但在實訓教學中，重點多停留在簡單的單據書寫填制上（且單據多以黑白色仿真為多，接近實際單據較少），案例講解也是狹隘的簡單業務操作案例，沒有聯系生活實際進行知識拓展。三是教學師資上，部分院校雖然建造了財務仿真實驗室，提出了工作情境模擬、角色扮演法等實訓方法，但是由于大多數教師本身沒有企業實踐經歷，對業務操作中實際工作環節講授不夠具體細致，導致學生只是大致了解基本流程卻無法清楚流暢完成具體業務，缺乏實際的職業能力。

而隨著信息化時代的到來，中小企業出納崗位，不僅需要掌握基本的現金和銀行業務的處理技能，而且要對企業資金運作做出合理安排：比如比較多種銀行票據結算方式，選擇對企業最有利的方案；對企業資金運行規律心中有數，做到既保證款項使用，又達到效益最大化；對企業融資需求和途徑提出有效方案……要能對企業管理者提供信息和建議。經濟越發展，財務越重要。所以，如何讓出納教學滿足實際崗位需要，如何面對新的機遇和挑戰進行教學改革勢在必行。

解決思路

信息技術的持續發展，大大推動了教育信息化改革進程。微課、慕課、網絡自學平臺紛紛興起，學習資源前所未有的豐富，學習方式和學習環境發生巨大變化，建構主義學習理念再次升級，以學習者為中心，課前進行教育資源的自主線上學習、課中以師生互動、問題探究、教師引導答疑解惑為主的翻轉課堂模式從美國興起，迅速引起國內教育界的關注和摸索實踐，成為學生提升自主學習能力的有效模式。

出納實務課程是一門綜合性課程，在要求具備熟練的點鈔、假幣識別、票據填寫和貨幣結算等基本技能的同時，由于在經濟業務辦理過程中涉及內外部人員眾多，還需要掌握熟練的業務流程操作，而且，隨著大數據時代的到來，還必須能夠進行數據分析和判斷，為企業管理者做好參謀。因此，出納實務有很強的現實性，必須通過對真實工作情境的模擬實現大量理論知識的學習運用。由于出納實務涉及的技能知識點比較多也比較散，知識點之間連貫性較弱，因此，非常適合按不同的技能進行視頻拍攝，充分利用微課堂進行自主學習，完成基礎知識點的掌握。

綜合以上分析，筆者認為，對出納實務課程教學進行改革，切實提升學生的出納崗位綜合職業能力，應采用工作情境化翻轉課堂教學模式。

翻轉課堂教學模式設計方案

出納實務工作情境化翻轉課堂教學模式設計總體流程如下表所示：

下面以轉賬支票付款業務處理能力訓練模塊為例加以具體說明：

課前準備 教師的工作：課前一周，教師對轉賬支票付款業務處理能力訓練模塊學習內容進行分析，主要包括：空白支票請購單的填制、轉賬支票的簽發、轉賬支票的結算特點、票據管理法中關于轉賬支票的使用條例、轉賬支票的結算程序、購買空白支票的賬務處理、轉賬支票付款的賬務處理、轉賬支票使用糾紛案例分析。將相應內容制作成教案、課件并錄制微視頻，提供案例庫、習題庫和單元測驗，均上傳至網絡自主學習平臺，下達學生學習任務單。

學生的工作：課前一周，學生登錄網絡自主學習平臺，根據學習任務單，觀看課件、微視頻，進行轉賬支票付款業務處理知識的學習，通過習題庫進行知識點的鞏固練習，運用單元測驗進行知識掌握程度自測，并通過網絡資源進行知識拓展并進行案例分析。記錄學習中遇到的問題，在網絡平臺上進行交流。

課堂教學 第一步，先由教師進行簡要的課程講解，對重點難點進行強調，回答學生在課前學習中遇到尚未解決的問題，并通過提問檢查學生的知識掌握程度。第二步，教師下達工作任務，設置工作情境。轉賬支票付款業務處理能力訓練模塊包括兩個工作任務：一是空白支票的請購；具體涉及情境有：出納填寫空白支票請購單，加蓋財務章；復核會計蓋法人章；出納到銀行遞交給銀行柜員；銀行柜員審核并收取工本費和手續費，發給空白支票；出納領取空白支票和回單返回；制單會計根據回單編制記賬憑證；復核會計復核；出納登記日記賬。二是用轉賬支票結算方式付款；具體涉及情境有：出納填寫結算方式申請審批單；財務主管審批；出納填制轉賬支票并蓋財務章；復核會計加蓋法人章；出納到銀行辦理結算；制單會計根據存根編制記賬憑證；復核會計復核；出納登記日記賬。在整個工作情境中，既有票據的基本填寫，又有經濟業務流程演示，既有印鑒雙人保管的規則了解，又有突發事件的存在，充分學習了知識，掌握了技能，熟悉了工作情境，而且，又有個體與團隊的協作學習，充分發揮個性、合作性和創新性，鍛煉了綜合職業能力。第三步，學生分小組進行工作情境模擬。每個小組五個同學，分別擔任出納（保管財務章）、制單會計、復核會計（保管法人章）、財務主管、銀行柜員（保管銀行業務章）。并準備空白支票請購單、收費回單、結算申請審批單、轉賬支票、記賬憑證、銀行日記賬、財務章、法人章、銀行業務章等資料。小組成員根據情境任務進行討論并分工協作完成模擬。教師對各小組進行輔導。第四步，教師抽取一個小組上臺展示模擬過程，其他同學進行觀摩并負責發現問題解決問題。教師對易出錯的環節、重點環節、細節環節進行點評。第五步，學生思路進一步清晰之后，再次分小組進行討論，并按角色進行輪換，直至順利完成工作任務。第六步，按小組進行工作匯報，成果共享。教師進行檢查點評。第七步，教師布置課后作業。提供課外學習資源網站，由學生自行選取某個案例進行分析并按照工作情境化模擬解決。

課后延伸 課后一周內，學生按小組將作業上傳至平臺，教師批改作業，并在學習平臺與學生進行互動交流。

考核方式 出納課程實踐性很強，單憑考試測評已經無法衡量一個學生對知識和技能的掌握水平，所以必須形成過程性考核。在《出納實務》課程的考核上，可以結合專業知識、專業技能、方法能力三方面進行考評，課前課后的利用網絡平臺進行考核，課中結合小組工作模擬表現和水平進行考核，并可結合學生課外參與各種競賽、各種社會實踐等成績作為最終成績。

參考文獻

[1]何克抗.建構主義──革新傳統教學的理論基礎[J].電化教育研究.1997（3）

[2]葉波.翻轉課堂顛覆了什么.課程?教材?教法[J].2014（10）

[3]趙宇.高校出納實務課程建設.教育與職業[J].2013（9）

篇(4)

關鍵詞：訂單號；人工轉帳；自動對賬；數據安全

中圖分類號：TP311 文獻標識碼：A文章編號：1009-3044(2007)16-30902-02

The Study and Design ofthe System of Bank-school and Transfer

RUAN Qun-sheng,TANG Bin,DAN Xiao-dong

(Donghua Polytechnic Universty Information Engineering Institute , Wuzhou 344000, China)

Abstract:The System of Bank-school and Transfer is web transaction platform which the bank and the school field cooperating develop, The article introduce the design mentality of Artificial Transfer System on base of order No, At the same time, it propose the successful method of solving automaticaccount problem, which guaranteeing the consistency and correctness between the bank and the school.

Key words:Order no;Artificial Transfer System;Automatically Reconciliation System;Data Safety

1 引言

目前市上網上轉賬系統數量繁多，有人工轉賬也有自動轉賬，所有的設計思路就是每次用戶消費都要同銀行發生交易，自動轉賬的方式只能發生在消費特點固定的情況下，如自動圈存等。除此之外，大部分還是要采用人工轉賬方式，由于頻繁地與銀行發交易，且基本上都是采用網頁參數提交的傳送方式，這勢必會有一極小部分的銀行成功的交易的記錄無法達到商戶WEB服務上，為了解決這些情況，常用的手段就是人工查詢某段時間內的交易記錄，然后進行數據導出，最后通過個性化軟件進行銀校數據一致性調整。此種對賬方式實時性差、手續繁瑣。由此可知以上網上轉賬處理方式，弊端突出，亟待一種全自動對賬系統的出現，因此，為了盡可能克服這些缺點本文設計出一種新的轉賬思路。

2 訂單號方式的設計思路

2.1 生成含有訂單號URL地址字符串

據圖1可知，第一步，自動生成與每一個用戶號一一對應的訂單號，并進行綁定。第二步，生成一個符合銀行要求的字符串。第三步，把前一步生成的字符串用MD5算法進行加密為32個字符的字密文字符串，MD5加密目的就是防止非法者在傳輸過程中篡改數據。最后，把第二步生成的字符串加上第三步加密生成的摘要密文以網頁的形式通過POST或GET提交，向銀行發出提交請求。

圖1 訂單號生成和數據提交流程圖

2.2 訂單號從銀行返回

從銀行返回時，為了保證數據的安全，運用了MD5withRSA（建行所使用的算法）數字簽名算法，在銀行端首先對即將要傳輸的字符用MD5算法加密為32個字符的密文字符串，然后用RSA算法加上私鑰對該密文字符串進行數字簽名，簽名后生成256個字符的密文字符串，最后把加上了簽名密文的字符串也是以網頁的形式以POST方式向學校WEB服務提交，學校WEB服務器端的應用程序接受提交后，將簽名和銀行發配給學校的公鑰轉換成二進制格式，與簽名的原文一起對簽名的正確性進行校驗，校驗步驟如下：

（1）使用公鑰進行簽名的逆運算

（2）使用標準MD5算法運算原文

（3）比較（1）、（2）結果

如果結果相等，則表示數字正確，沒有被非法修改過，可以把銀行返回來的金額寫入數據庫中對應訂單號，流程見圖2。

圖2 訂單號從銀行返回的數據處理流程圖

2.3 根據訂單號進行消費支付

由于從銀行返回對應訂單號的金額，用戶輸入訂單號和密碼，即可在學校內進行一切費用的支付，比如學費、飯卡充值、繳納考試費用等，如果訂單號上的錢用完，又可對該訂單號進行轉賬操作。

3 后臺自動對賬系統

3.1 全自動對賬的研究

當前建設銀行、工商銀行等相繼推出了商戶批量查詢接口，而令人鼓舞的就是提供了交易記錄的XML形式的顯示頁面，這就為自動處理提供了有利條件，該格式頁面上顯示的元素和頁面后臺源碼是一模一樣的，因此，就可以通過封裝了SOCKET了HttpWebResponse應答類和HttpWebRequest請求類向銀行WEB服務器發出請求和接受輸出數據流，把接受到的輸出數據流寫入XML文件，寫完之后，接著就對XML文件中的每條記錄同學校數據庫中數據記錄進行比較，以XML記錄為準（因為XML中的記錄都是來自于用戶在銀行交易成功的記錄），如果學校數據庫中不存在，就把對應著的XML中的記錄插入數據庫中。應該注意的是由于銀行網站都是通過SSL加密訪問的，所以當我們通過HttpWebRequest構造的類給其發出請求時，須加載證書，查詢時不需要證書的，也需要做忽略證書的說明，否則當通過HttpWebResponse類構造的對象去接受的數據流時，就會出現不是為空就是無法訪問的之類的情況或提示，整個流程見圖3。

圖3 自動對賬流程圖

3.2 全自動對賬的實現

//注：實現語言：C# 以下為精簡出來的代碼

//建造HttpRequest.cs讀取網頁內容的關鍵類 以下是該類中的關鍵函數和說明

// HttpRequest網頁請求方法

public bool OpenRequest(string requestUriString, string requestReferer)//帶參數的請求函數

{// 用requestUriString, requestReferer對一些參數賦值

return OpenRequest();

}

private bool OpenRequest()//真正向網站發出數據請求的Request函數

{__HtmlText__.Remove(0, __HtmlText__.Length);

HttpWebRequest Request = (HttpWebRequest)WebRequest.Create(Uri);

Request.AllowAutoRedirect = AutoRedirect;

{Regex __RegexUri_ = new Regex("^", RegexOptions.IgnoreCase);

if(__RegexUri_.IsMatch(Uri))

ServicePointManager.CertificatePolicy = new TrustAllCertificatePolicy();

}

//此處設置一些屬性

Request.ContentType = "application/x-www-form-urlencoded";

byte []Bytes = Encoding.GetEncoding(Charset).GetBytes(Post);

Request.ContentLength = Bytes.Length;

using(Stream writer = Request.GetRequestStream())

{writer.Write(Bytes, 0, Bytes.Length);

writer.Close();}

HttpWebResponse Response;

Response = (HttpWebResponse)Request.GetResponse();

{HtmlText.Append(theException.Message);

return false;}}

private void ReadHtmlText(HttpWebResponse _Response_)//寫成XML文件函數

{using(Stream reader = _Response_.GetResponseStream())

{StreamReader sr = new StreamReader(reader, Encoding.GetEncoding(Charset));

path = Application.StartupPath;}}

public class TrustAllCertificatePolicy : ICertificatePolicy//加載證書或忽略證書

{public TrustAllCertificatePolicy()

{// TODO: 在此處添加構造函數邏輯}

public bool CheckValidationResult(ServicePoint _ServicePoint_, X509Certificate _Cert_, WebRequest _WebRequest_, int _Problem)

{return true;}

{path = Application.StartupPath;

if (path.Substring(path.Length - 1) != "\\")

{path = path + "\\";}

path = path + "DataFromBank.xml";

xmlDoc.Load(path);

XmlTextReader reader = new XmlTextReader(path);

XmlNode xn = xmlDoc.SelectSingleNode("DOCUMENT");

XmlNodeList xnl = xn.ChildNodes;

foreach (XmlNode xnf in xnl)

{XmlElement xe = (XmlElement)xnf;

XmlNodeList xnf1 = xe.ChildNodes;

temp = xnf1.Item(6).InnerText;

orderNo = xnf1.Item(3).InnerText;

money = Convert.ToDouble(xnf1.Item(5).InnerText);

//調用庫存儲過程，由它判斷該訂單號是否在庫中存在,并進行相應的處理

}}//對應foreach

}

4 結束語

本文研究了人工網上銀行轉賬訂單號方式設計思路和全自動化的銀校對賬系統，目前本人并在該設計思路的下設計出了應用程序，并在我校投入使用，結果表明，該系統能夠較好滿足用戶在銀行和學校之間、學校內的交易，數據準確，銀校數據能夠保持一致性、實時性，學校財務處工作人員毋須人工干擾，真正做到了財務工作自動化。

基于訂單號方式的后臺自動對賬的人工網上銀行轉賬系統有著很大的商業價值，目前，越來越來多的企業、商家推出網上電子展銷平臺，網上購物如雨后春筍般涌現，與銀行交易的原理與本人設計的轉賬和處理方式有著一定的類似性，因此本文具有一定的借鑒意義。

參考文獻：

[1]中國建設銀行項目開發組.書名： 中國建設銀行網上支付查詢接口操作手冊,2001.

[2]Simon Robinson, Christian Nagel,李敏波譯著.C#.NET 高級編程[M].清華大學出版社.

[3]Anthony work Programming for Microsoft Windows[M].Microsoft Press.

[4]Gary P. Schneider.Electronic Commerce(4th Edition)[M].Thomson.

篇(5)

關鍵詞：無現金報賬；財務管理；高校

中圖分類號：F812.7文獻標志碼：A文章編號：1673-291X（2011）19-0090-02

隨著高校教學、科研等各項事業飛速發展，高校財務部門每日現金流量不斷增大，學校應逐步改變傳統的現金收付方式，借助銀行卡、網上銀行等先進手段，大力推行資金收支業務的電子劃轉，最大限度地減少現金流動，提高工作效率與服務質量。作為高校財務部門承載著經費核算的重任，尤其到年末和學期結束前，財務現金收付流量每日達上百萬，如何提高工作效率與服務質量；如何預防和降低現金周轉風險、確保資金安全，這是值得思考的問題，因此推行無現金報賬的方式勢在必行。

一、無現金產生的背景

貨幣電子化是國際潮流，無現金結算是發展方向。無論從國家對經濟運行宏觀調控的角度看，還是從個人使用資金安全方便的角度看，電子貨幣必然要取代現鈔。貨幣發展史告訴我們，隨著商品經濟的發展，人類創造了貨幣，貨幣的形式首先是現金，由于現金在流通、結算、儲存、運輸等過程中的種種不便，人們又創造以支票為代表的轉賬貨幣，大大減少了現金的使用。隨著科學技術的發展，又出現了新的形式――信用卡。信用卡的轉賬功能進一步減少了現金在社會上的流通。從物物交換到使用現金，這是一個很大的進步，用電子流代替現金流，這是一個更大的進步。現金從產生到發展到消亡，這也是一個不以人們的意志為轉移的客觀規律。

二、無現金報賬的會計核算

為了保證會計核算的準確性和無現金報賬的明確性，在不改變會計科目總體框架的情況下增設相關明細科目。例如：某學院購辦公用品，其會計處理如下：

借：商品和服務支出/辦公費

貸：銀行存款/?菖?菖校區/無現金

三、無現金報賬的業務流程圖

四、無現金報賬與傳統報賬方式的區別

通過銀行卡結算取代以往的現金結算，未改變原有的財務報銷審批制度。不同之處主要有四點：（1）傳統報賬后領到的是現金，采用無現金報賬后，錢款直接打到了領款人的銀行卡上。（2）由于報賬方式的不同減少了經辦人攜帶和管理現金的風險。（3）在傳統報賬方式下，為保持合理的現金庫存，財務處與銀行一樣實行大額現金支取預約制度，比如提5萬元以上須提前一天預約。采用無現金報賬后，財務部門與銀行合作，采用的是與銀行一樣的轉卡系統，已經確認的報銷轉卡金額由現金出納通過轉卡方式支付，一般在五分鐘內即時劃入指定銀行卡中。（4）每日報銷工作結束后，在傳統報賬方式下，出納須盤點核對庫存現金；采用無現金報賬后，出納只需核對當日無現金轉卡支付清單及匯總表，與有關銀行支付匯總金額進行核對。

五、無現金報賬的優點

無現金報賬是指在報賬過程中利用網絡信息技術，將現金收付方式轉變為銀行卡轉賬方式，不到現金出納處繳、領現金就完成報銷的一種報賬方式。財務人員在辦公室即可實現資金的劃轉和報銷。因此無現金報賬方式的優點顯而易見。

1．優化財務報銷流程，提高工作效率，緩解報賬人員排隊擁擠的現象，縮短了報銷人員的等待時間。隨著高校跨越式發展，經濟總量不斷增長，財務報銷業務日益繁忙，師生員工普遍需要較長時間才能辦理完業務。使用無現金報賬，能有效地改善此現狀。

2．減少相關的現金風險，加強內控機制。采用無現金報賬，可以進一步完善內控機制，減少現金流量，保障資金流動安全，規避涉及現金的各類風險，如出納配款的差錯風險、保管現金的風險以及假鈔風險等，同時也減少了前來報銷的師生員工攜帶和保管現金的風險。

3．不必提前預約現金，隨時確保教學科研業務順利進行。由于無現金結算不涉及現金，是通過財務系統與銀行網絡對接實現資金劃轉，所以采用無現金報賬則無須預約，支取大額現金報銷款項直接打入銀行卡，確保教學科研業務的順利進行，師生員工無須事先預約現金，可以直接到財務辦理報銷業務。

篇(6)

關鍵詞：SGI86；營銷系統；賬務管理

引言

當今時代是信息化時代，信息化建設是國家電網公司工作的重要組成部分，為建設“一強三優”現代公司，完成公司“兩個轉變”的宏偉目標，國家電網公司于2006年提出了在全公司系統實施信息化“SGI86”工程，為落實國家電網公司SGI86工程建設，加強企業核心資源人、財、物的集約化管理，深化公司發展方式轉變的要求，我公司2007年開始進行SGI86營銷系統建設，經過多年的建設，已能較好地支撐營銷業務的開展，但由于銀行在途資金的時差、營銷業務系統“實收”與財務“實收”的定義不一致，營銷部門和財務部門的電費帳務總是不能一致，月結月清難以實現。本文從我公司電費管理和財務管理的現狀出發，分析了我公司在電費管理和財務管理中存在的問題，并在此基礎上，提出了解決對策和建議，以期能對企業各項管理起到一定的作用。

一、公司電費管理和財務管理現狀

當前，我公司財務管理部門與營銷部門在電費管理中普遍存在脫節的現象，特別是在銷售電量、銷售電費和銷售電價，已收回電費和未收回電費等賬務數據上反映尤為突出。

1.財務部門與營銷部門之間信息傳遞實時性不強

退費、未達賬管理過程未實現全過程的系統管理。通常在進行電力企業銷售管理中，應當依據營銷部門所提供的月報數據進行相應的財務管理工作，營銷系統只記錄了退費原因及結果，而退費財務審批、退費時間、退費方式等均未實現系統管理，只由人工負責跟蹤處理。電費收入賬戶的對賬過程在財務系統中處理，發現企業未達賬或銀行未達賬，由財務部門口頭通知營銷部門處理。而財務部門賬單上所顯示的銷售電量和電費數據往往不夠全面，財務人員只能簡單的依據銀行回單或繳款憑證來確認相關收入，對營銷系統內的業務情況不清楚，造成營業收費業務資金缺乏有效管理，不能正確反應企業的實際銷售情況，

根據國網集成技術規范，營銷系統每日將確認到賬后的實收電費及業務費進行分類匯總后，傳送財務ERP管控系統，也就是只有當日在營銷系統中做了到賬確認的數據才作為當日數據發送，不同于現有的按解款日期進行核算，目前大部分銀行都是第二天才反饋前一天的銀行文本，營銷系統收到銀行文本后才做到賬確認，特別是月末日銀行文本無法當日傳遞，營銷系統當日不能做到賬確認處理，實收數據無法在財務賬上反映。

2.營銷SGI86系統內不能及時了解所收電費資金的到賬和未達賬情況

當前，營業收費主要依賴SGI86營銷系統平臺，營銷SGI86系統采用單一記賬模式，如，銀行代收電費，客戶到銀行窗口用現金或轉賬支票繳納電費，銀行通過銀電聯網系統實時進行電費銷賬，銀行當日營業終了之后進行清賬，次日將前天代收的電費資金轉入電費收入戶，也就是說，從客戶繳了錢之后到電費資金到賬有一定的時間差，使得收費人員無法及時判斷轉賬資金是否已經到達銀行賬戶。我公司曾經出現這樣一個案例：

在2012年3月11日，甲客戶到供電營業廳，用一張2萬元的轉賬支票繳納了3月的電費?；貑紊限D賬時間是2012年3月10日（這筆資金沒有到達我公司銀行賬戶）。同時，新增用戶乙客戶，在3月11日通過網銀。向我公司銀行賬戶上轉了2萬元的預購電費，當天該筆資金到達我公司銀行賬戶：乙客戶沒有及時到供電營業廳開具發票，收費人員也未做帳。3月底，財務人員在手工進行銀行到賬資金確認時，把乙客戶所轉的2萬元誤認為是甲客戶的，將兩筆賬進行購銷。5月21日乙客戶拿著銀行轉賬支票到供電營業廳，要求開具預購電費發票，收費人員看見是3月11日的銀行回單，通知財務人員查詢是否有2萬元企業未達賬，通過查賬才暴露甲客戶所轉資金未達賬。

目前用戶直接網上轉賬，又未到營業廳打印發票，財務只能一直掛帳而不能及時確認收入。這種情況出現較多。財務與營銷管理脫節是造成企業未達賬問題關鍵所在。此外，營業收費的繳款要求日清日結，而進賬單、繳款單及相應的收款記賬憑證不能有效保證每天及時送達至財務部門。電費資金在途管理上的真空地帶，企業未達賬、銀行未達賬信息沒有在系統中進行管理，容易造成月末大量的銀行未達帳項，月度現金流量預算難以控制，使得公司的會計信息出現失真，不利于公司對營銷信息的快速掌控。

3.財務部門與營銷部門之間電費資金對賬時間不一致

財務部門與營銷部門之間電費資金到賬時間不一致對賬不及時，存在重復對賬的問題。營銷根據銀行紙質進賬回單與營銷系統中的電子信息進行對賬，財務再根據營銷手工報送的匯總實收報表及銀行紙制進賬回單與銀行對賬單進行對賬，兩邊重復對賬，且由于財務一般每月末才進行一次銀行到賬情況對賬，對賬不及時。

二、原因分析

長期以來電力行業的信息化基本上是分散建設，沒有形成統一的信息化標準規范，沒有整體的考慮。各職能部門各自為政，習慣于只根據自身的需求單獨立項，開發功能單一、開放性較差的專用系統，最大的問題就是數據的不可兼容，信息被嚴重割裂開來，最終形成了數量眾多的信息“孤島”。不同的系統數據來源不同，處理方法也有差異，往往不同系統產生的同一口徑的數據卻天壤之別。

1.在業務管理應用系統中營銷管理的收費與財務核算業務管理關系較為緊密，這種被稱作緊耦合的管理業務，是通過ERP一體化來實現的，而且也有這樣的成熟套裝軟件，因此財務管理通過成熟套裝軟件的技術路線來實現：對于營銷管理，無疑也與ERP所包括的業務管理有著緊密的關系，但這個部分有著突出的行業特征，ERP中沒有相應的功能，加上兩個系統都非常復雜，實時性要求相對較高，各省市公司均有比較成熟的系統，所以采用走分系統建設，再進行集成的技術路線。由于我公司還未實現營財一體化這就帶來了營銷業務應用系統與財務業務管理應用系統就不可避免的出現在有的項目上定義不一致的問題。

2.ERP它是由制造業的物料供應、生產、銷售全過程的價值鏈管理經驗發展而來的，以財務為中心，將資源“換算”成價值量，通過業務流程產生準確的、精細的量值，再對數據進行統計、分析、挖掘、處理，形成生產過程的價值控制和企業經營管理決策的輔助支持。目前，國內外的ERP軟件和解決方案主要是針對金融財務、電子制造業、IT業和大型機電制造業，在電力行業的應用比較少。由于不是專門為電力系統設計，而是在制造業軟件的基礎上修改而成，過分強調業務處理，對電力系統生產的安全性、可靠性考慮不足，對電力行業企業現有的或將來的應用系統連接需要二次開發。

3.由于財務與營銷兩個專業對電費獨立管理，業務流程獨立運作，數據交互通過手工傳遞，營銷電費核算、收費等業務生成的會計信息主要以人工處理方式為主，因此財務系統的銀行到賬信息不能滿足營銷達賬確認的需求，營銷的達賬確認采取根據回單而非銀行電子對賬單的方式進行處理，容易形成財務與銀行的未達賬項，財務部門的ERP系統中不能及時了解營銷部門的銷售情況，影響企業對賬戶資金的監控，這違背了ERP以財務為核心的管理模式。

三、采取措施

1.將財務部門的ERP核算系統，與營銷部門的SGI86營銷信息系統有機結合

將財務部門的ERP系統，與營銷部門的SGI86營銷信息系統有機接軌，在生成應收數據時，營銷系統按ERP中的核算要求匯總用戶數據，提供給ERP進行賬務處理。使得兩部門在電費管理問題上能互為補充，保證一致，逐步建立起全局統一、簡潔高效、反應快速的專業化營銷體系，從而進一步增強對電費管理的穿透力，提高電價電費管理的整體績效。按照財務集約化管理“深化應用、提升功能、實時管控、精益高效”的目標要求，深化財務與營銷系統集成應用，推進營銷賬務與財務賬務協同和集約化管理，實時轉換業務信息和財務信息，實現財務ERP與營銷SGI86系統的業務費集成，進一步提升業務費管理水平。

2.對營銷收費流程進行優化和規范，增加營銷系統中“銀行到帳查詢”功能

在SGI86營銷信息系統中增加“銀行到賬查詢”功能。在收費過程中，銀行資金到賬后，通過資金系統將資金到賬信息傳遞給ERP，ERP確認資金到賬，并將資金到賬明細信息傳遞給營銷系統，營銷系統根據從ERP傳遞的資金到賬信息對用戶確認達賬后，將達賬信息按ERP需求分類匯總后提供給ERP，在ERP中確認應收或預收科目進行達賬處理。營業收費人員在進行電費收取時，能及時查詢客戶轉賬資金是否已經到賬：同時，對財務人員開放營銷系統數據查詢權限?？蓪崟r了解營銷前端業務進展情況，通過對資金流的監控及早識別前端業務風險，要求及時收費，及時解款，及時入賬，嚴格執行收支兩條線的規定，做到各項費用應收盡收，應退即退。

3.加強SGI86營銷信息系統中的功能延伸

積極完善企業SGI86營銷管理信息系統，將其查詢和驗查等功能與財務部門進行拓展和延伸。通過協調和數據整合，保證企業的財務管理部門與營銷部門在電費管理的數據保持信息的一致性，從而使得企業財務管理部門可以實時查詢和核算企業電費的信息。具體包括：一是通過加強企業SGI86營銷管理信息系統的功能擴充，實現企業財務管理與SGI86營銷數據之間的共享，并保證兩者的數據一致性。企業財務管理部門可以隨時準確地企業的對電費欠費、交費等情況進行查詢和核算，及時掌握企業的電費管理情況。二是通過企業ERP財務系統與SGI86營銷信息系統的軟件升級。針對企業ERP財務核算系統與SGI86營銷管理系統之間存在的核算獨立的弊端，要在企業SGI86營銷管理系統中引進企業財務會計科目和復式記帳的機理，將企業的電費信息保存成企業的經營憑證，并通過SGI86營銷信息系統與企業ERP財務核算系統的模塊接口將企業的電費信息準確實時傳給企業財務管理部門。

篇(7)

關鍵詞：移動支付；J2ME；MVC；安全

引言

移動終端和無線通訊技術在高校校園的普及，為校園無線移動應用提供了大量的用戶群。同時由于校園中存在著很多小額支付的情況，例如支付圖書館借書的超期費用、補選課程的差額費用、班費、印刷學習資料費等。這些煩瑣的小額支付既增加了管理人員的開銷也給學生帶來了不便。因此本文考慮使用無線移動技術來解決高校的小額支付問題，以提高辦事效率。

目前，在我國移動在線的手機支付業務比較多的是基于智能手機終端。在這些移動終端技術中，能處理移動支付的有J2ME、WAP、SMS或SAT技術。J2ME技術具有可移植性、網絡資源消耗與服務器負載低、事務保護、安全性、容易安裝等特點，在手機支付領域中占了比較大的優勢。因此我們擬采用J2ME技術實現高校移動小額支付系統。

1、系統需求分析和用例設計

1.1手機小額支付相關概念和問題

手機支付也稱為“移動支付”，它是在移動運營商和商業銀行之間加入第三方構筑的轉接平臺，實現“一點接入、多家服務”的業務模式。通常基于手機的業務項目可以分為四大類：查詢、繳費、消費、轉賬。例如，現在信息查詢可以包括：股票行隋、商品防偽編碼、考分查詢、交通信息、天氣預報等。第三方的介入，使銀行和移動運營商之間在技術、業務等合作領域有了更為廣闊的發展空間，它對移動電子商務的市場開拓起到了催化劑的作用。

在手機支付中一個極其重要的問題是安全問題。為此，一方面需要銀行對用戶的交易密碼和一些敏感數據做加密處理，同時又要讓業務系統獨立處理業務往來，對于系統業務的訪問要有安全日志等監測措施。校園小額支付系統可以作為第三方移動業務服務提供商來促進移動電子商務在高校的發展，并且在財務的結算上可以與原有校園網中的財務管理系統相結合，獨立于銀行的業務往來。因此它將更具有高校內部網特性，更能滿足安全性的要求。

1.2系統需求分析和用例設計

本系統向普通用戶(包括手機終端用戶和PC瀏覽器終端用戶)和管理員提供小額支付業務服務。整個系統分為普通用戶子系統和管理員子系統。其中向普通用戶提供在線注冊、個人信息管理、在線充值、查詢公告、在線支付、賬單查詢功能；向系統管理員提供包括個人信息管理、在線查詢、在線生成充值卡等功能。

1.2.1服務器端主要用例

服務器端面向系統管理員，主要有以下用例：

公告管理向系統管理員提供公告的添加、查詢、修改和刪除功能。

交易信息管理提供交易信息的統計和查詢。

免值管理提供生成充值卡功能。系統生成一定數量的充值卡，并將充值卡信息寫入數據庫?？梢杂贸渲悼▽崿F學生賬號的充值。并能進行充值卡和學生賬戶資金一致性檢查和查詢。管理員可以查詢系統記錄的所有充值記錄，以便日后核對業務總量。

賬號管理提供學生賬號的管理、查詢、掛起和注銷功能。一些高校已經建立了學生的財務賬號，例如：很多高校已經給學生開設了校園卡，學生有惟一的賬號，校園卡可以由學生充值。否則，需要給每個學生設立一個惟一識別的財務賬號，賬號可以和學生證號相關聯。

交易信息的合法性檢查提供對交易信息的合法性管理，防止出現非法的交易事件，可以采用手工的或自動的檢測和過濾機制。在本系統中目前還是采用了手工的方式。

1.2.2客戶端主要用例

在客戶端面向手機用戶或PC瀏覽器用戶，以下針對手機用戶給出客戶端的主要用例：

用戶管理提供用戶數據的存儲和管理功能。用戶通過注冊，登錄后可以使用各個模塊的功能。同時用戶也有權利將開通的賬號注銷掉。

在線繳費提供在線支付和轉賬功能。主要是實現校園各服務機構的在線小額費用收取。在線支付費用，包括支付借書超期費用、支付圖書賠償費用、支付重修費用、支付等級考試費用、支付圖像采集費用、支付水費、支付電費等。金額的輸入可通過購買和輸入充值卡兩種方式進行。轉賬是指賬面金額在兩個手機賬號之間的轉移。

在線查詢提供各種賬目的明細查詢。在系統上使用支付和買賣功能或者轉賬功能后會產生相應的賬單，用戶可以查詢一定時間內的賬單。

在線服務向注冊用戶提供天氣的查詢，新聞通告以及投訴建議的和相關信息查看功能。

在線交易提供類似于有線網絡的信息平臺，系統采用手機客戶端交易信息并同時提供買賣商品的功能。

系統存儲及安全管理提供本地數據的存儲管理和安全管理。

1.3主要的業務流程

在圖1中，我們給出了系統的主要業務流程分析。

2、系統主要類圖設計

2.1服務器端系統設計和主要類圖

為實現上述的用例分析和業務流程，在服務器端主要設計了普通用戶類、管理員類、支付賬單類、充值卡類、充值記錄類、公告類、部門類、轉賬賬單類。類之間的關系如圖2所示。

2.2基于J2ME技術的客戶端支付界面的主要類圖

客戶端除了用戶、賬號、天氣、商品、部門、賬單、轉賬、在線服務、充值卡以及對應于本地存儲的對象賬單存儲，卡號存儲類外，基于J2ME的技術的手機端支付界面的主要類圖如圖3所示。

客戶端界面包含了Form、List、TextBox、Alert類等，這些類繼承Screen父類，而Screen類又實現Displayable接口。Form類中命令主要實現CommandListener接口，提供相應按鈕事件。Canvas類，通過指針繪制接受用戶的輸入，觸發keyPressed()事件相應用戶請求，通過paint方法繪制需要繪制的對象。

3、關鍵技術

3.1基于MVC模式設計方法

本系統在設計時采用了MVC模式，如圖3所示。在模型層封裝了模型的狀態、負責響應模型狀態的查詢、應用程序的功能，如卡號、賬單等信息，或者保存對象的狀態。當狀態改變的時候通知視圖改變模型狀態。