【文章內容簡介】 加，經常會出現問題，總之是一定要檢查） 如果是取款類業(yè)務（比如轉賬業(yè)務的轉出方也算），一定要檢查賬戶的可用余額是否足夠。 大家一起來。5 系統(tǒng)架構及部分模塊常見設計方案 常見總體架構這里如果用圖可能效果會更好，不過我不會用VISIO，所以就算了。一般硬件架構，都是一個主機，一個前置機（大前置），前置機就對外了，比如業(yè)務人員用來作業(yè)務的終端啦，ATM，網銀，電話銀行什么之類的可能就都對應這個大前置了。大前置，或者是中間業(yè)務平臺，也是一個很值得探討的問題，可以做得很大，比如建行的大前置，又比如X天的中間業(yè)務平臺其實也不錯，這里不做深究。就軟件架構而言，核心系統(tǒng)一般可以分為業(yè)務模塊，賬務模塊，和總賬模塊?？傎~模塊通常記錄了一些賬務的匯總信息，比如說科目總賬的日、月、年的發(fā)生、余額。銀行中大部分的報表都需要通過取總賬模塊中的數據來生成?？傎~模塊的數據一般是取自賬務模塊中，當天的賬務數據。（當然，也有很多報表，需要整合業(yè)務模塊與總賬模塊兩部分的數據一起來出）賬務模塊，就是用來登記賬務的，這部分一般會做得比較通用化，方便各個業(yè)務模塊來調用。業(yè)務模塊，當然就是實現各個業(yè)務的子模塊了，通常模塊之間相對獨立又互有關聯，如果是賬務類業(yè)務，當然就要調用賬務模塊中的程序。如果是非賬務類的業(yè)務，那可能業(yè)務模塊內部處理一下就可以了吧。一般業(yè)務模塊的數據會對實時性要求較高，而總賬模塊沒有什么實時性的要求，不過總賬模塊重在統(tǒng)計分析，所以數據量一般會比較大。 計息有的系統(tǒng)可能沒有把計息單獨列為一個模塊，而是直接嵌套在各個業(yè)務模塊之間了，不過設計成一個模塊，個人認為可能會顯得比較專業(yè)一點，至于到底好不好用那就見仁見智了。剛接觸銀行業(yè)務的時候，曾經很執(zhí)著，很傻很天真的想過活期賬戶到底是怎樣計息的，因為定期賬戶的計息方式相對簡單，余額乘天數就對了，但是活期賬戶的余額是常常在發(fā)生變動的，所以前20多年我一直都不知道銀行每年給我算的活期利息到底對不對。銀行會計上，通常都會通過“積數”這個東西來計息。何謂積數？就是余額＊天數，所以積數的單位應該是“元 天”比如說 利息 = （賬戶余額＊天數＊利率）/ 360，在這個公式里，賬戶余額＊天數就等于積數，于是這條公式也可以寫為 利息 = （積數 ＊ 利息） / 360。定期賬戶因為賬戶余額通常不發(fā)生變化，所以一般不會涉及到積數?；钇谫~戶采用動戶累計積數的方式來計息。也就是說賬戶余額沒有發(fā)生變動，就什么事都不干；當賬戶余額需要發(fā)生了變動時（比如說取款），那么業(yè)務模塊里就將上次賬戶變動日，到當前日期的天數計算一算，然后用變動之前的賬戶余額乘以這個天數，然后把這個積數累加到之前的積數上。最后計息的時候，就使用這個積數乘以利率再除360。在設計的時候，就需要把每次賬戶變動的日期都登記下來，還需要有地方記錄賬戶的當前積數。對公計息，或者是一些需要計息內部賬，有可能是每天計積數，也就是每天把賬戶余額累加到積數中。之所以這樣設計，是因為對公以及內部賬戶的數量遠小于對私賬戶，每天把每個賬戶都過一遍，花不了太多時間；而要是每天把儲蓄賬戶都過一遍，就有點類似于結息了。（對私賬戶多的銀行，有可能達到上千萬戶，尤其是些代理了社保，醫(yī)保的銀行，不可小看）不過現在有些很好很強大的國外系統(tǒng)，對于利息的處理，是每日計提，當然，這樣設計也應該會有它的獨到之處。剛才這里提到的了需要計息的內部賬，那么一般而言，什么樣的內部賬需要計息呢，我想，應該是不同法人之間上存下放的款項需要計息。對應于一般的商業(yè)銀行以及統(tǒng)一了法人的信用聯社，因為全市是一級法人，可能就沒有需要計息的內部賬了。而對于沒有統(tǒng)一法人的聯社，因為每個信用社都是一個獨立的法人，那么信用社存放在聯社的用來做往來清算用的資金，就是需要計算利息的。還有的銀行，對于貸款的處理，也會有資金池的概念，這時總行下撥分行的用于貸款錢，也是要計息的。這里可以看到，對于計息模塊而言，積數是一個很好用的東西。積數除了計息，還有很多其它的用途。比如說招行的金卡，說的是“日均存款5萬元以上不收取賬戶管理費”，那么，這個日均存款5萬是如何判斷呢，我很久以前曾經問過一個大堂里的MM（跟我同姓喔，惜乎已經有BF了），她說是根據積數來判斷的，也就是每個月需要增加150萬的積數，這樣聽起來就很合理了吧。對于某些業(yè)務來說，可能需要登記利息的明細。比如說貸款的復利的計算，就是根據利息來的。無論是正常貸款，還是逾期貸款，都會生成利息。生成的利息如果未及時歸還，則會再根據這筆利息生成相應的復利。復利的復利，喔，太可怕了，也還是視為復利吧?？傊业囊馑季褪钦f，儲蓄、對公賬戶這樣的結息，在計息模塊中可以不用登記利息的明細，因為最后結息的時候根據積數一次搞定；而對于貸款（或者是其它有需要的模塊），可能需要在每一筆利息產生之后，都把它登記下來，已保留行使進一步措施的權利。除了貸款之外，還有一些定期賬戶，也最好采用明細的方式進行處理，越細越好，比如什么零存整取，教育儲蓄之類的，要是沒有詳細的每期存款登記，漏存登記等等，是很容易就被它玩死的。通知存款以前覺得它很可怕，現在想想，突然又覺得沒那么可怕，無非就是通知取款，通知期限內的積數登記，然后取款又或者取消通知?？赡茏钪饕模驮谟谕ㄖ谙迌鹊姆e數計算?？傊崛∫粋€計息模塊，為這類業(yè)務特別定制一些明細文件是很好的一個選擇。提到計息，也就順便說一下利息稅。國家在這十年來，調整了兩次利息稅稅率，一次是漲成兩分，一次是降成五厘，就那么一點錢，調來調去累不累，要收就收，不收拉倒，還搞什么分段計稅，煩死個人。在這里，不知道有沒有人是負責搞利息稅這部分程序的，也不知道去年改這部分程序的時候，有沒有很不爽過。其實要是早考慮到這種情況，倒是可以一開始就通過設置利息稅參數表，然后修改計息程序，讀取利息稅參數表，最后根據不同階段的參數，分段計息算稅。這個方法倒是可行的，也實現過，對于整存整取的定期來說，算得上是一勞永逸，不過對于活期而言，每次調整利息稅稅率的時候可能就要搞一次類似于結息的東西了，好象沒有一勞永逸的方法。在國外的先進系統(tǒng)中，還有一種精采的倒起息可以讓人一籌莫展。這種玩法的意思，就是說當客戶來柜臺前做個什么交易的時候，允許賬戶的起息日期在業(yè)務發(fā)生日之前。比如說有人7月14號來到柜臺前還一筆貸款的款，然后說我這筆錢明明7月7號就到賬上了啊，為什么銀行不給我扣，非得讓我貸款逾期之類的話。然后核查，如果屬實，那就倒起息一把，現在雖然是7月14號，但還是當它是7月7號還的。（好象是這樣，也可能是我說錯了，大家對這段解釋千萬不要太放在心上）總之，如果有倒起息的需求，那必須在最開始設計的時候就與其它計息，以及業(yè)務流程整合在一起來考慮，如果中途加入這個需求，那改起設計來會比較費勁，改起代碼來更是難上加難。最后，我們再來說說計提，這個也和利息有關。計提常用于利息支出，比如說利息支出是5211，5字頭，即是一個用于營業(yè)收支的損益類的科目。計提的會計分錄中，對應的科目是應付利息2611， 2字頭，是一個負債類的科目。所以說，計提的含義就在于，雖然當前客戶利息并未產生（是結息的時候才產生），但是這筆利息（尤其是整存整取的定期利息）遲早是會產生的，所以這里預先計算，或者說估算出營業(yè)支出，計到負債的科目上（負債嘛，本來不屬于銀行的錢，遲早是要被取走的錢），然后到這類賬戶結息的時候，就直接從應付利息中支出，計到客戶賬戶上，而不走利息支出這個科目了。看懂了吧，這里其實也就包含了管理會計中的概念，實際上是產生一個提前測算成本的動作。諸位搞IT的朋友們，你們看過《會計學原理》嗎？ 儲蓄/對公這部分模塊一般沒太多可講的，通常的設計，都是搞個主文件，保存針對每個賬戶的信息（比如說賬號，賬戶余額，當前積數什么之類的，總之就是與賬戶有關的信息），然后再搞個賬戶明細，用來記錄每個賬戶發(fā)生過的業(yè)務。聽聞有的系統(tǒng)設計，不知道是不是考慮到鎖表的問題，計劃取消主文件，直接上明細，愕然之余只能感嘆自己見識淺薄，因為我總覺得明細要考慮沖賬的問題，在讀取上不如主文件一下搞定那么暢快。