銀行核心系統(tǒng)入門簡介銀行核心系統(tǒng)入門簡介本文的目標讀者是準備從事銀行核心系統(tǒng)開發(fā)、維護的從業(yè)人員。請注意，是“準備”，換句話說，可以理解為一份對科技人員，尤其是對新入門的科技人員業(yè)務知識方面的培訓手冊，旨在讓諸位從業(yè)務方面迅速上手（從技術角度上手的手冊我已經(jīng)貼過一份了，所以如果是用400的同行，可以結合本手冊雙劍合璧，效力倍增）。這里的著重點將會主要在于簡單的銀行會計原理，以及銀行整體的業(yè)務流程，還有相應的模塊實現(xiàn)手法和注意事項，對金融的會計知識方面應該可能會比較粗淺，這一點與金融系統(tǒng)常見的業(yè)務培訓手冊有所不同，注意體會?；诖耍疚膶僭O讀者具備一定的計算機技術，具備少量銀行方面的業(yè)務知識，所以如果有從事非IT部門的讀者（比如財務信貸的同事們），就請不要太計較里面的表述。當然如果有錯誤，還是非常歡迎指出的。對于已具備了若干開發(fā)、維護知識，或者是即將采用國外系統(tǒng)來建設的同行們而言，本文的內(nèi)容可能就過于淺顯了，看得不爽不要怪我沒有事先提醒?？紤]到某方面的問題，這里的系統(tǒng)簡介將盡可能的脫離某個具體的系統(tǒng)，僅就銀行業(yè)務核心系統(tǒng)的共性，進行介紹以及探討。最后再說一下，沒有什么手冊、心得是萬能的，個人的LEVELUP始終是要靠自己的領悟，這里只是希望能讓諸位新人不用象很多人當年一樣，獨自摸索與徘徊。科目常識基本法則之一：資產(chǎn) =負債+所有者權益。比如說，我們手頭上有 40萬，買了一個 100萬的房子，找銀行貸款了60萬，那么資產(chǎn)就是100萬，負債是60萬，所有者權益是40萬。可以簡單的把所有者權益就理解成為是真正屬于自己的錢。再引申一下，早些年乃至現(xiàn)在，香港人所謂的“負資產(chǎn)”的說法是非常錯誤的，因為“負資產(chǎn)”實際上是指房子的市值比向銀行貸的錢還要小，也就是負債大于資產(chǎn)，所以嚴格的來說，應該稱之為“負所有者權益”才對。資產(chǎn)，從理論上來說，是不可能為負的，最多也就是零。一個號稱是金融中心的地方，實在是不應該出現(xiàn)這種失誤，不過算了，不要和他們計較。就銀行業(yè)務而言，會使用會計科目號來對賬務進行標識，會計科目號最長為5位，國家標準，通常分為下面六種，這里只做簡單介紹，詳細科目可結合著名的的“業(yè)務狀況表”來進行理解。再次重申，下面的說法絕對不嚴謹，僅僅只是為了便于IT人員理解銀行的會計原理、業(yè)務知識。1.1資產(chǎn)資產(chǎn)類的科目，用“1”作為首位科目號，如“1011”，表示現(xiàn)金。所謂資產(chǎn)，也就是說“理論上屬于銀行的錢”，比如說現(xiàn)金，貸款等。比如說某家分行，有100萬現(xiàn)金，然后把這100萬都貸出去了，那么資產(chǎn)仍是100萬，只不過歸屬（科目）由現(xiàn)金變成了貸款。至于這筆貸款能不能收回，這個不歸我們管，就算不能回收，只要沒被核銷（核銷，術語之一，可以理解為銀行不要這筆貸款了），那么就仍然屬于資產(chǎn)，所以我們稱之為“理論上屬于銀行的錢”。資產(chǎn)類科目都是借方科目，也就是借記時余額增加，貸記時余額減少。1.2負債負債類的科目，用“2”作為首位科目號，如“2011”，表示對公存款。本來不屬于銀行的錢，就稱之為“負債”。比如說我們存在銀行的錢，雖然銀行可以使用這筆錢，比如說把它貸款貸出去啊，比如說打新股啊，買QDII啊，但是這筆錢只要我們?nèi)ト?，原則上銀行就應該給我們，也即是大家常常在營業(yè)大廳里看到的“存款自愿，取款自由”之類的意思。這類錢，可以簡單的理解為“本來不屬于銀行的錢”，也就銀行欠我們的錢。負債，很有趣的東西喔，銀行是負債經(jīng)營的，比如說一家銀行貸款有100億，其實它本身是沒有那么多錢的，這些錢都是來自于我們存在它那的錢。如果大家一起都去銀行的錢取出來，那它就經(jīng)營不下去了，這種惡劣的行為，稱之為“擠提”，是很不友善的，是要負責任的，我們不要去做。負債類科目都是貸方科目，也就是借記時余額減少，貸記時余額增加。1.3所有者權益所有者權益類的科目，用“3”作為首位科目號，如“3121”，表示利潤分配。上面說過了，所有者權益，也就是真正屬于銀行的錢，即是所謂的“核心資本”。原則上，它包括了一家銀行注冊時的資金，歷年來的盈利（假設有盈利的話，當然還要扣除各類成本開銷），如果是股份制銀行的話，還包括股本金之類的吧。這類科目相對數(shù)量較小，金額較大?？颇繉傩酝?。1.4資產(chǎn)負債共同類（往來類）資產(chǎn)負債共同類，通常表示往來賬戶，用“4”作為首位科目號，如“46411”，表示通存通兌。這類科目，通常是指一些往來類賬戶，所謂往來類賬戶，嗯，就是金融往來的賬戶嘍。這個科目有點麻煩，可能要結合具體業(yè)務來解釋一下：比如說我們在招行有個賬戶，然后跑到工行的ATM上去取錢（招行也是，中山這種偉人的故鄉(xiāng)居然都不開個點，嚴重BS一下），那么取款成功之后，我們的招行上的賬戶的錢就少了，工行ATM里面的現(xiàn)金也少了。這筆錢是工行替招行先支付的，要找招行要的。所以工行一定會有一個科目，用來標記它有多少錢要找招行要；而招行也要有一個科目，也是要用來標記它有多少錢要給工行。（怎么要，那在后面清算一節(jié)里面會提到。至于跨行ATM的取款原理，就不用再細說了吧。）這個用來標記應付，應收的科目，就是往來類科目，對于工行方而言，當時使用到的就是一個類似于資產(chǎn)類的科目（有點類似于應收賬款的意思，或者也可以理解成一種短期的貸款，總之就是工行先付出的資金）；招行當時使用的就是類似于負債類的科目。上面提到的，因為是銀行與銀行之間的業(yè)務往來，所以用來標識資產(chǎn)與負債的科目會有分別，如果是行內(nèi)之間的往來，那么不會搞得那么復雜（或者也可以說搞得更復雜），就會用一個科目來搞定，這個科目根據(jù)具體需要，臨時用的，有時表示資產(chǎn)，有時表示負債（其實也就是科目上的余額有時是借方，有時是貸方。因為這個科目既不是資產(chǎn)，也不是負債，只是臨時用來表示營業(yè)往來的，通常每天會清零，也就是所謂的清算。一般而言，城市級別的商業(yè)銀行因為是一級法人，所以清算之后，行內(nèi)往來賬戶上余額為不為零都沒什么關系，反正都是自已家的錢；而信用社會比較麻煩一點，因為通常一個聯(lián)社都是由多個信用社組成，每個信用社都是一個法人，所以聯(lián)社內(nèi)部的往來類賬戶原則上每天應該都清零，否則賬務上就不好看了。（注意，這里指的只是行內(nèi)的往來賬，如果是銀行與銀行間的，那每天一定是要清零的，否則就是屬于錯誤的情況了）這類科目在我們做過的項目里，基本上都簡化了，只有一個軋差類型的。也就是把當天的借方發(fā)生額和貸方發(fā)生額一減，哪個大就誰記在哪邊。我記得以前還有一種雙方類的科目，那真是玩死人。雙方類的科目是指這個科目既有貸方余額，又有借方余額；對應貸方余額，既有借方發(fā)生額，又有貸方發(fā)生額，同理，對應借方余額，也是既有借方發(fā)生，又有貸方發(fā)生，如果只有上期的借貸方余額，以及當期的借貸方發(fā)生額，那是無論如何也推算不出當期的借貸方余額各是多少的。（必須根據(jù)發(fā)生賬務時，是借方余額，還是貸方余額來判斷），不知道這類科目的起因為何，總之如果有的而且可能的話，最好能拆分之幾個性質單純一點的子目來處理。不好意思，因為對這類科目感觸頗深，也被玩過很多次，被玩很久，一時激動，就多說了幾句。1.5損益類損益類的科目，用“5”作為首位科目號，如“5011”，表示利息收入。損益類科目，理解起來應該不難，就是指銀行在一年的業(yè)務里面的收支科目。比如的存款利息，對于銀行來說是一筆支出；貸款利息，對于銀行來說，是一筆收入。這兩個科目就都屬于損益類科目。一般來說：收入類科目屬貸方科目，借記時增加，貸記時減少；支付類科目屬借方科目，貸記時增加，借記時減少。在理解上，可能與資產(chǎn)、負債類的科目有些相反：資產(chǎn)是指屬于銀行自己的錢，是借方科目；對應于這里，收到的錢是銀行自己的，卻又是貸方科目。這里，按會計原理來理解可能會更簡單一點，下面一章會講到。1.6或有資產(chǎn)負債類或有資產(chǎn)負債類的科目，用“6”作為首位科目號，如“6011”，表示承兌匯票。聞歌知雅意，顧名思義，“或有”，那自然就是“或者有”，也就是可能沒有了，所以如果沒見過也不奇怪。這類科目見得少，一般可以忽視它的存在。1.7其它這里再羅嗦一下，在科目下面呢，一般為了便于分類統(tǒng)計，所有的銀行都會再設子目（一個子目一般又會對應多個小子目，或者說是說是多個賬戶），這個子目，有的地方叫“業(yè)務代號”，有的地方叫“結算碼”，總之都是一個意思。要注意一下，科目號是國標，子目通常是自己內(nèi)定的，對應于信用聯(lián)社，就有可能是省里統(tǒng)一定的。也就是說科目這個東西走遍全國大致上都是一樣，子目這個東西可能出省，出了城市，或者說一個市里不同的銀行，可能都不一樣。簡單會計原理2.1內(nèi)部賬戶這個問題，我在剛學的時候，曾經(jīng)頗疑惑了一段時間，所以雖然很簡單，但還是單獨拿出來說一下。所謂內(nèi)部賬戶，是與客戶賬戶相對應的。也就是說這些賬戶不是用來登記、反應客戶的賬戶信息，而是反應行內(nèi)的賬務情況，比如說損益類科目的賬戶，就都是內(nèi)部賬戶?？蛻舻馁~戶，一般是客戶來銀行開戶的時候，才建立的用來登記賬務的賬戶；內(nèi)部賬戶，一般是分行成立之初，統(tǒng)一生成的。（一般都一個專門的程序，由操作人員來調(diào)用的吧）其實對于內(nèi)部賬，在會計原則上，登記個科目發(fā)生可以。至于增加子目，乃至內(nèi)部賬戶的概念，主要是為了后續(xù)的分類統(tǒng)計以及相應的分析。說到這個賬戶，就順便想起了表內(nèi)表外的問題。表內(nèi)賬，都是正正式式，真金白銀的錢；比如我們的存款什么之類的。而表外賬，通常是一些統(tǒng)計之類的東西，比如說現(xiàn)在分行里有多少本存折啦，還有已經(jīng)核銷的貸款之類的。表內(nèi)賬的單位，都是“元”；表外賬的單位，就百花齊放了，有的是“元”（比如說已核銷貸款），有的是“本”或者是“張”，比如說存折或者說什么有價單證。 而最后，表外賬在匯總統(tǒng)計的時候，不管是什么單位，就是統(tǒng)統(tǒng)一加了事，對于不是財會專業(yè)的，尤其是我們搞計算機的人來說，這種加法簡直有些不可理喻，總之銀行會計上就是這樣處理。所以說，一般報表里面，大家會對表內(nèi)賬比較關注，對表外賬的要求不是太嚴格（我是這樣偷偷的說，各位怎么處理是大家自己的事）。2.2復式記賬法只要是與會計有關的書，就一定會提到復式記賬法，也稱為借貸記賬法，這里就不多解釋，簡單說一下?！坝薪璞赜匈J，借貸必相等”，這兩句經(jīng)典的話，是針對表內(nèi)賬的。對于表外賬，用的其實是單式記賬法，有的叫“收”、“付”，也的也還是用“借”，“貸”，要結合具體的業(yè)務來理解，這里就不展開了。如果沒有特別說明，下面的描述都是針對表內(nèi)賬的。對于銀行業(yè)務來說，最簡單的是一借一貸，此外，還有一借多貸，一貸多借。多借多貸在銀行業(yè)務里中不允許的，因為這樣無法精確的體現(xiàn)賬務的起始與流向。不過在企業(yè)會計中，多借多貸又是允許的，所以說凡事無絕對。有些時候，基于某些特殊的的原因（常見的主要是頻繁的鎖表問題），可能會臨時采用單邊記賬，但是最后一定會匯總補齊，否則就會出現(xiàn)“借貸不平”這樣的嚴重問題。2.3沖賬做錯了賬，要改正它，就可以理解為沖賬。沖賬有兩種，一種是藍字沖賬，一種是紅字沖賬。所謂的藍字沖賬，是指與原賬務方向相反，金額為正的一種記賬方式。而紅字沖賬，就是指與原賬務方向相同，金額為負的一種記賬方式。藍字沖賬，本質上是做一筆新的業(yè)務，僅僅只是實現(xiàn)了最終的余額正確，發(fā)生額會虛增，所以一般的明顯有錯的賬務，會要求使用紅字沖正。紅字沖賬因為是負數(shù)發(fā)生，所以在統(tǒng)計的時候，發(fā)生額將會與原來的交易抵銷， 這樣的話發(fā)生額就很嚴謹了。實際上，對于一個系統(tǒng)而言，通常一筆業(yè)務的發(fā)生，并不僅僅只包括賬務的登記，還會更改許多表中的數(shù)據(jù)。比如說一筆簡單的取款交易，除了登記賬務之外，客戶的賬戶上的余額還會減少，這個很好理解吧。那么在沖賬的時候，還需要將客戶上的錢給它加回去。所以，關于沖賬業(yè)務的設計，其實也是一個比較有趣的話題，這一點，將會在后面的章節(jié)中進行探討。業(yè)務流程描述對于一個沒有在柜面實習過的人，描述一下銀行的業(yè)務流程，可能是有助于理解系統(tǒng)架構的。銀行的業(yè)務，大致上可以分為財務類的業(yè)務，以及非財務類的業(yè)務。非財務類的業(yè)務這里不做討論。財務類的業(yè)務，又可分為自動業(yè)務，以及非自動業(yè)務。非自動業(yè)務，就是那些必須在柜臺辦理的業(yè)務，比如說一些轉賬業(yè)務，或者金額較大的存取款業(yè)務之類的。這類業(yè)務，因為是由柜員發(fā)起的，所以會有一些單據(jù)打印留底，以做傳票使用。而自動類業(yè)務，就是由系統(tǒng)自動處理的，比如說我們在A分行有個賬戶，然后非要跑到B分行去取錢，那么B分行那部分的賬務，對于B分行而言就是非自動業(yè)務；而A分行那部分的賬務，對于A分行而言就是自動業(yè)務。自動業(yè)務因為是自動發(fā)生，所以需要業(yè)務人員打印報表的時候，才能知道發(fā)生了什么業(yè)務。柜員日間做各種各樣的業(yè)務，然后到了下午關門以后，打印一份“科目日結單”，然后用柜員手頭留存的傳票，按科目逐一匯總累計，與打印出的科目日結單上的金額進行比對。有錯一定要一查到底。所以原則上，這時打印的科目日結單，應該不包括自動業(yè)務，否則就會對應不上。業(yè)務系統(tǒng)在批處理的時候，還會進行一些自動的賬務處理，然后最后系統(tǒng)還應該會再打印一份完整的科目日結單，以及日計表（可以理解為業(yè)務狀況表的簡潔版）。至于那些自動業(yè)務，系統(tǒng)在批處理的時候，或者是柜員主動查也行，總之就是會有一份“他代本”的傳票（對應于上面提到的業(yè)務，A分行的自動業(yè)務就應該屬于A分行的“他代本”傳票。而B分行的傳票因為是非自動業(yè)務，所以在交易當時就會有相應傳票產(chǎn)生并打印了）到了第二天，分行開門后開始營業(yè)前，業(yè)務人員需要下載打印各類報表，不過主要的就是前面說的那兩份，然后再看看，如果借貸發(fā)生、余額都相等，所有的非自動業(yè)務都有傳票，而且和整個科目日結單都可以對應上，那么就表示昨天的賬務完整無誤，然后大家就可以歡天喜地的開始新一天的業(yè)務了。常見規(guī)范及檢測4.1傳票以及日志從最基本的說起，通常來說，所有的賬務程序都需要打印傳票,傳票格式通常都是統(tǒng)一的，找份以前看看就可以了。對應于轉賬業(yè)務，需要打印轉賬借、貸方雙方的傳票。而對于現(xiàn)金業(yè)務，則只打印一張傳票就可以了，借貸方向采用非現(xiàn)金科目的方向。 （我個人認為，可能是因為標識了現(xiàn)金傳票， 所以對方科目就自然是現(xiàn)金，于是就不需要再打印了，猜的）所以我們在開發(fā)程序的時候，打印傳票這一步，一般不會特別強調(diào)，都是默認要做的。如果不太清楚的時候，一定要主動向需求設計人員詢向，千萬不要嫌麻煩，抱有僥幸心理。這種東西如果測試的時候漏掉了，是一定會有人要求補上的。（我在N多項目里都見過漏寫傳票，然后在程序上線前夕被人要求趕緊加班補制的，所以千萬不要嫌麻煩）在日終批處理的時候，可能有些數(shù)量龐大的業(yè)務，比如說代收付，結息什么之類的，動不動就是幾十萬筆，一張張生成、打印太不經(jīng)濟，通常會考慮采用打印一張匯總傳票，然后加上一份明細清單的方式。還有的時候，如果上百萬的話，可能明細清單都省掉，想辦法導成電子數(shù)據(jù)都是有可能的。上面說的是賬務相關的業(yè)務。而非賬務類的業(yè)務，如果涉及到修改類的業(yè)務的話，比如說修改密碼，修改客戶名之類的，通常需要登記日志LOG），用來記錄，以便查詢。有的時候，為了統(tǒng)計業(yè)務量，或者是為了分析排障，還有可能要求對每一筆發(fā)送到主機的業(yè)務數(shù)據(jù)都登記下來，這時候最好采用一種統(tǒng)一的方式來進行登記，以及數(shù)據(jù)的定期清除，因為這類數(shù)據(jù)量應該比較大。4.2常見檢測內(nèi)容發(fā)生一筆業(yè)務的時候，是一定需要進行若干檢查的。比如最起碼，我們?nèi)ト″X的時候，就一定會檢查密碼。這里對一些經(jīng)常見到的，較為普遍的檢查簡單介紹如下，套用一句合同上流行的話，叫做--包括但不僅限于以下條款：1、賬號/卡號是否存在，是否可以正常使用2、賬號與客戶所提供的憑證（通常這是指存折客戶，對于卡用戶而言，賬號就是卡號，或者是可以根據(jù)卡號查詢出相應的賬號）是否匹配。3、密碼、證件號碼（如果需要檢查的話）是否與主機數(shù)據(jù)一致（印鑒什么的需要業(yè)務人員肉眼核對?，F(xiàn)在又出了一種加密機，如果采用了這種先進技術，那當然還需要檢查這種加密后的信息是否一致了）4、在轉賬的時候，一定要檢查轉出轉入方的戶名與賬號/卡號中的戶名是否一致。（對私客戶還好辦一點，如果是對公客戶的話，名字又長，括號什么的再一加，經(jīng)常會出現(xiàn)問題，總之是一定要檢查）5、如果是取款類業(yè)務（比如轉賬業(yè)務的轉出方也算），一定要檢查賬戶的可用余額是否足夠。6、大家一起來。系統(tǒng)架構及部分模塊常見設計方案5.1常見總體架構這里如果用圖可能效果會更好，不過我不會用VISIO，所以就算了。一般硬件架構，都是一個主機，一個前置機（大前置），前置機就對外了，比如業(yè)務人員用來作業(yè)務的終端啦，ATM，網(wǎng)銀，電話銀行什么之類的可能就都對應這個大前置了。大前置，或者是中間業(yè)務平臺，也是一個很值得探討的問題，可以做得很大，比如建行的大前置，又比如X天的中間業(yè)務平臺其實也不錯，這里不做深究。就軟件架構而言，核心系統(tǒng)一般可以分為業(yè)務模塊，賬務模塊，和總賬模塊。總賬模塊通常記錄了一些賬務的匯總信息，比如說科目總賬的日、月、年的發(fā)生、余額。銀行中大部分的報表都需要通過取總賬模塊中的數(shù)據(jù)來生成?？傎~模塊的數(shù)據(jù)一般是取自賬務模塊中，當天的賬務數(shù)據(jù)。（當然，也有很多報表，需要整合業(yè)務模塊與總賬模塊兩部分的數(shù)據(jù)一起來出）賬務模塊，就是用來登記賬務的，這部分一般會做得比較通用化，方便各個業(yè)務模塊來調(diào)用。業(yè)務模塊，當然就是實現(xiàn)各個業(yè)務的子模塊了，通常模塊之間相對獨立又互有關聯(lián)，如果是賬務類業(yè)務，當然就要調(diào)用賬務模塊中的程序。如果是非賬務類的業(yè)務，那可能業(yè)務模塊內(nèi)部處理一下就可以了吧。一般業(yè)務模塊的數(shù)據(jù)會對實時性要求較高，而總賬模塊沒有什么實時性的要求，不過總賬模塊重在統(tǒng)計分析，所以數(shù)據(jù)量一般會比較大。5.2計息有的系統(tǒng)可能沒有把計息單獨列為一個模塊，而是直接嵌套在各個業(yè)務模塊之間了，不過設計成一個模塊，個人認為可能會顯得比較專業(yè)一點，至于到底好不好用那就見仁見智了。剛接觸銀行業(yè)務的時候，曾經(jīng)很執(zhí)著，很傻很天真的想過活期賬戶到底是怎樣計息的，因為定期賬戶的計息方式相對簡單，余額乘天數(shù)就對了，但是活期賬戶的余額是常常在發(fā)生變動的，所以前20多年我一直都不知道銀行每年給我算的活期利息到底對不對。銀行會計上，通常都會通過“積數(shù)”這個東西來計息。何謂積數(shù)？就是余額＊天數(shù)，所以積數(shù)的單位應該是“元天”比如說利息=（賬戶余額＊天數(shù)＊利率）/360，在這個公式里，賬戶余額＊天數(shù)就等于積數(shù)，于是這條公式也可以寫為利息=（積數(shù)＊利息）/360。定期賬戶因為賬戶余額通常不發(fā)生變化，所以一般不會涉及到積數(shù)?；钇谫~戶采用動戶累計積數(shù)的方式來計息。也就是說賬戶余額沒有發(fā)生變動，就什么事都不干；當賬戶余額需要發(fā)生了變動時（比如說取款），那么業(yè)務模塊里就將上次賬戶變動日，到當前日期的天數(shù)計算一算，然后用變動之前的賬戶余額乘以這個天數(shù)，然后把這個積數(shù)累加到之前的積數(shù)上。最后計息的時候，就使用這個積數(shù)乘以利率再除360。在設計的時候，就需要把每次賬戶變動的日期都登記下來，還需要有地方記錄賬戶的當前積數(shù)。對公計息，或者是一些需要計息內(nèi)部賬，有可能是每天計積數(shù)，也就是每天把賬戶余額累加到積數(shù)中。之所以這樣設計，是因為對公以及內(nèi)部賬戶的數(shù)量遠小于對私賬戶，每天把每個賬戶都過一遍，花不了太多時間；而要是每天把儲蓄賬戶都過一遍，就有點類似于結息了。（對私賬戶多的銀行，有可能達到上千萬戶，尤其是些代理了社保，醫(yī)保的銀行，不可小看）不過現(xiàn)在有些很好很強大的國外系統(tǒng)，對于利息的處理，是每日計提，當然，這樣設計也應該會有它的獨到之處。剛才這里提到的了需要計息的內(nèi)部賬，那么一般而言，什么樣的內(nèi)部賬需要計息呢，我想，應該是不同法人之間上存下放的款項需要計息。對應于一般的商業(yè)銀行以及統(tǒng)一了法人的信用聯(lián)社，因為全市是一級法人，可能就沒有需要計息的內(nèi)部賬了。而對于沒有統(tǒng)一法人的聯(lián)社，因為每個信用社都是一個獨立的法人，那么信用社存放在聯(lián)社的用來做往來清算用的資金，就是需要計算利息的。還有的銀行，對于貸款的處理，也會有資金池的概念，這時總行下?lián)芊中械挠糜谫J款錢，也是要計息的。這里可以看到，對于計息模塊而言，積數(shù)是一個很好用的東西。積數(shù)除了計息，還有很多其它的用途。比如說招行的金卡，說的是“日均存款5萬元以上不收取賬戶管理費”，那么，這個日均存款5萬是如何判斷呢，我很久以前曾經(jīng)問過一個大堂里的MM（跟我同姓喔，惜乎已經(jīng)有BF了），她說是根據(jù)積數(shù)來判斷的，也就是每個月需要增加150萬的積數(shù)，這樣聽起來就很合理了吧。對于某些業(yè)務來說，可能需要登記利息的明細。比如說貸款的復利的計算， 就是根據(jù)利息來的。無論是正常貸款，還是逾期貸款，都會生成利息。生成的利息如果未及時歸還， 則會再根據(jù)這筆利息生成相應的復利。復利的復利，喔，太可怕了，也還是視為復利吧?？傊?，我的意思就是說，儲蓄、對公賬戶這樣的結息，在計息模塊中可以不用登記利息的明細，因為最后結息的時候根據(jù)積數(shù)一次搞定；而對于貸款（或者是其它有需要的模塊），可能需要在每一筆利息產(chǎn)生之后，都把它登記下來，已保留行使進一步措施的權利。除了貸款之外，還有一些定期賬戶，也最好采用明細的方式進行處理，越細越好，比如什么零存整取，教育儲蓄之類的，要是沒有詳細的每期存款登記，漏存登記等等，是很容易就被它玩死的。通知存款以前覺得它很可怕，現(xiàn)在想想，突然又覺得沒那么可怕，無非就是通知取款，通知期限內(nèi)的積數(shù)登記，然后取款又或者取消通知?？赡茏钪饕?，就在于通知期限內(nèi)的積數(shù)計算?？傊崛∫粋€計息模塊，為這類業(yè)務特別定制一些明細文件是很好的一個選擇。提到計息，也就順便說一下利息稅。國家在這十年來，調(diào)整了兩次利息稅稅率，一次是漲成兩分，一次是降成五厘，就那么一點錢，調(diào)來調(diào)去累不累，要收就收，不收拉倒，還搞什么分段計稅，煩死個人。在這里，不知道有沒有人是負責搞利息稅這部分程序的，也不知道去年改這部分程序的時候，有沒有很不爽過。其實要是早考慮到這種情況，倒是可以一開始就通過設置利息稅參數(shù)表，然后修改計息程序，讀取利息稅參數(shù)表，最后根據(jù)不同階段的參數(shù)，分段計息算稅。這個方法倒是可行的，也實現(xiàn)過，對于整存整取的定期來說，算得上是一勞永逸，不過對于活期而言，每次調(diào)整利息稅稅率的時候可能就要搞一次類似于結息的東西了，好象沒有一勞永逸的方法。在國外的先進系統(tǒng)中，還有一種精采的倒起息可以讓人一籌莫展。這種玩法的意思，就是說當客戶來柜臺前做個什么交易的時候， 允許賬戶的起息日期在業(yè)務發(fā)生日之前。比如說有人 7月號來到柜臺前還一筆貸款的款，然后說我這筆錢明明7月7號就到賬上了啊，為什么銀行不給我扣，非得讓我貸款逾期之類的話。然后核查，如果屬實，那就倒起息一把，現(xiàn)在雖然是 7月14號，但還是當它是 7月7號還的。（好象是這樣，也可能是我說錯了，大家對這段解釋千萬不要太放在心上）總之，如果有倒起息的需求，那必須在最開始設計的時候就與其它計息，以及業(yè)務流程整合在一起來考慮，如果中途加入這個需求，那改起設計來會比較費勁，改起代碼來更是難上加難。最后，我們再來說說計提，這個也和利息有關。計提常用于利息支出，比如說利息支出是5211，字頭，即是一個用于營業(yè)收支的損益類的科目。計提的會計分錄中，對應的科目是應付利息2611，2字頭，是一個負債類的科目。所以說，計提的含義就在于，雖然當前客戶利息并未產(chǎn)生（是結息的時候才產(chǎn)生），但是這筆利息（尤其是整存整取的定期利息）遲早是會產(chǎn)生的，所以這里預先計算，或者說估算出營業(yè)支出，計到負債的科目上（負債嘛，本來不屬于銀行的錢，遲早是要被取走的錢），然后到這類賬戶結息的時候，就直接從應付利息中支出，計到客戶賬戶上，而不走利息支出這個科目了?？炊税?，這里其實也就包含了管理會計中的概念，實際上是產(chǎn)生一個提前測算成本的動作。諸位搞IT的朋友們，你們看過《會計學原理》嗎？5.3儲蓄/對公這部分模塊一般沒太多可講的，通常的設計，都是搞個主文件，保存針對每個賬戶的信息（比如說賬號，賬戶余額，當前積數(shù)什么之類的，總之就是與賬戶有關的信息），然后再搞個賬戶明細，用來記錄每個賬戶發(fā)生過的業(yè)務。聽聞有的系統(tǒng)設計，不知道是不是考慮到鎖表的問題，計劃取消主文件，直接上明細，愕然之余只能感嘆自己見識淺薄，因為我總覺得明細要考慮沖賬的問題，在讀取上不如主文件一下搞定那么暢快。而且主文件可以有鎖表保護，可以更好的保障數(shù)據(jù)的正確性。所以私底下，我還是很推崇這種“主+明細”的設計方式。以前曾經(jīng)很無奈地見過有人在新增業(yè)務模塊時，把主文件和明細混在一起來搞，于是整個業(yè)務流向悵然若失，需求有變動時改動幾乎無從下手，若非我多年功力，是斷斷不可能在加兩天班后就理順通過測試的。說起儲蓄呢，又忍不住再提一下招行，不可否認，它的一卡通做得真的挺好，本外幣，定活期，一張卡全部搞定。我以前就經(jīng)常把活期轉成三個月定期。根據(jù)我本人看法，三個月定期從利率差與時間存放差上來說，性價比是最高的，也就是說一年期利率雖然高，但很難保障這點錢在一年內(nèi)不用。所以推薦大家把5K以上的存款轉成三個月定期，一般忍忍也就可以拿到利息了，當然了貨幣基金也是一個不錯的選擇。還有一次自做聰明搞了個一年期的零存整取，性價比不高，而且還得到柜臺去辦取款手續(xù)，把自己麻煩死了，不推薦使用。扯遠了，其實本來是想說，活期、定期、外幣賬戶，這些都是一個又一個的賬戶， 而在招行的設計之中，這些賬戶，都會與我們的那一張小小的卡片關聯(lián)起來。換句話說，人家的卡號，應該只含具體的卡的信息，比如說卡的有效期，密碼，磁道信息什么之類的，不直接對應某個具體賬戶的；而各個具體賬戶則應該會有一個與卡號的對應關系。然后到寄對賬單的時候啊， 打電話介紹買保險等等附加服務的時候，就還是根據(jù)卡號來提供服務。不過還是要根據(jù)賬戶的資金流動來分析消費習慣，以及貢獻度的高低等等。至于怎么實現(xiàn)，就根據(jù)各位自己的核心系統(tǒng)慢慢體會，不過這么多年了，也可能大部分銀行都實現(xiàn)了這種功能或者是類似的一卡通，那就當我這段沒有講過吧，總之我覺得這種理念很好很強大，讓我用得覺得很方便。至于對公，好象就更加沒什么可說的了。5.4客戶信息客戶信息，卡號，賬戶號，這三者是層層細化的關系。所以說，整合好三者的關系也是一個不容易的事情。在我見過的幾套系統(tǒng)之中，最常見的問題，就是同一個客戶對應多個客戶信息。這通常又是個歷史遺留問題，比如在手工或單機年代，開戶時對于身份證明證件要求不是很嚴格，一個人可能開了很多賬戶，還可能是用化名開的賬戶。在移植上線的時候，常常由于重要信息不齊，又要考慮客戶層面的因素，很少能強制性補齊客戶資料，通常只能在移植時自動生成一些客戶信息，這樣就造成了很多冗余，而且也不好再做深層的數(shù)據(jù)挖掘和客戶分析。相比較而言，新開立的分行可能這種情況會好一點，而且面對的客戶高端一點的，又會更好一點。在新系統(tǒng)上線，做數(shù)據(jù)移植的階段，一般客戶信息的問題是最先體現(xiàn)出來的，通常新系統(tǒng)會要求得比較理想化，而實際情況千奇百怪。這里說說常見的，比如說新系統(tǒng)一般會要求證件號碼唯一，但是因為很多客戶的證件信息缺失，所以這個號碼唯一可能會有困難；再比如說有時可能會出現(xiàn)證件號碼重復，而且還真的不是同一個人?？傊@些問題，它不是新系統(tǒng)的錯，也不能完全說是舊系統(tǒng)的錯，最關鍵的是在移植的時候如何處理利用好這部分客戶信息。再一個問題，就是客戶信息的更新。個人認為最好能有一個有效的途徑來更新客戶信息，尤其是工作單位，電話號碼，對于很多流動人員來說，經(jīng)常會變換。如果每次都要來柜臺更新，我想那基本上就可以認為它是形同虛設了?？梢哉f，隨著現(xiàn)在以客戶為中心的概念的提出以及越來越多的實現(xiàn)，客戶信息這個模塊也應該會越來越受到重視，以前設計的表結構應該會有些不夠用了。目前如果沒有新系統(tǒng)要上的同行們，恐怕是要等著改結構加字段了，保重。5.5貸款很多地方都會把一般的商業(yè)貸款與按揭貸款和消費貸款（比如車貸、分期付款之類的，總之有點類似于按揭貸款的）區(qū)分開來，這樣自然有它的道理。我在這里只談我個人的設計方案?，F(xiàn)在的商業(yè)貸款常常采用一筆發(fā)放，一筆回收的概念（當然有時會有提前還款，但不象按揭貸款這樣有個具體還款計劃），然后用合同號，或是借據(jù)號做為貸款的一個類似于唯一關鍵字這樣的東西。但是有時公司的商業(yè)行為中，一個大項目里會包含多個子項目，然后對應不同的子合同，這些合同對應的貸款之前其實都是有關聯(lián)的，尤其是在算逾期什么之類的時候，有的是一逾全逾，有的又不是。所以我個人覺得，貸款最好做成多筆發(fā)放，多筆回收的形式，發(fā)放與回收不必一一關聯(lián)。但最好在貸款錄入時（這時不一定已放款），就錄入相應的還款計劃。貸款的賬號，最好與具體的業(yè)務信息剝離，類似于儲蓄里面“一卡通”的概念一樣，每個貸款，有它自己獨立的貸款號，然后正常、逾期、兩呆，以及相應的利息賬號都與這個貸款號關聯(lián)起來，便于以后的跟蹤追查。而對于按揭貸款來說，因為期限長（常常是二三十年），而且比較具有規(guī)律性，所以一般就不用列出還款計劃的明細了。不過要注意，一般按揭貸款的首月還款是按天算息的，稍微注意一下就可以了。最后，特別強調(diào)提出一點，見過兩家行，都推出過“等本等息”這種經(jīng)典的業(yè)務產(chǎn)品，也就是客戶每月按等額法算出的金額還款，但本金的計算則按等本的方式來算。這里要大聲疾呼，這種東西從原理上來說就已經(jīng)是錯誤的！因為同樣金額，同樣期限的貸款，等額法的利息是要大于等本法的利息的。等本法計算方便，理解簡單；而等額法是數(shù)學家們經(jīng)過精確的計算，推導出公式，最后計算出的一種還款方法。也就是每個月的還本、還息都要嚴格按照計算出的公式，這樣才能達到等額的效果。試想想，這個月還了一定的本金之后，下個月計算出的利息就不一樣了吧，這時要求下個月還的本金與還的利息加起來還是和這個月的一樣多，而且還要求每個月還的本金加上利息都是一樣多。所以，除非是數(shù)學學得特別好的同學，咱們一般的程序員不要妄想自己能推導出公式來，照著公式算就行了。如果強行按等額法計算出的錢來制訂還款計劃，又按等本法的方式還計算每期還款本金，雖然是方便了，但是在每年利率變更，重算利息時，必然會導致利息總和由等額法的利息漸漸趨近于等本法的利息，也就是總利息額將會越來越少，于是要么在本金與利息的問題上無法自圓其說，要么可能會出現(xiàn)利率上調(diào)還款金額反降，甚至負利息的問題，不可不查。5.6清算與結算清算與結算本來是兩種業(yè)務，不過因為結算中通常又會包括清算，要分成兩小節(jié)，每小節(jié)又說不了太多話，所以干脆放在一起算了，而且這一節(jié)只談流程，不講設計，這種業(yè)務流程理順了自然就可以設計了。先約定一下，商業(yè)銀行的級別，一般是 分行—支行兩級，有的可能還會有儲蓄所這種第三級。簡化起見，暫時就分兩級來說吧。如果對應到信用社，那就是聯(lián)社營業(yè)部—信用社營業(yè)部。分社一級省略。先從結算說起，這里的結算業(yè)務，指的就是跨行轉賬，至少我是打算這么說。每家商業(yè)銀行，都會在當?shù)氐娜嗣胥y行有一個資金賬戶，可以理解為結算業(yè)務用的備付金賬戶。然后在自己行內(nèi)，也會開立一個與之對應的“上存人行款項”的賬戶。理論上，人行的這個賬戶和我們自己行內(nèi)的這個賬戶，表達的都是“該銀行存放在人民銀行的錢”的這個意思，所以金額也應該相等。那么，這兩個賬戶在不同的銀行（也即不同的系統(tǒng)中），如何保障它的一致性？這一般就是通過日終，營業(yè)終了時的對賬來保障。所以對賬是很重要的，這個后面再說。至于結算業(yè)務的流程，先從遙遠的手工賬/單機賬年代說起吧。在那個時候，結算的途徑、概念、術語可以說是五花八門，什么先直后橫，先橫后直，提出借方，提出貸方，提入借方，提入貸方，信匯，電匯等等等等，不把人轉暈誓不罷休?，F(xiàn)在好象大小額支付橫空殺出，倒是簡化了不少。當然也還有行間轉賬，同城支付，省金融平臺，不過概念上漸漸趨向統(tǒng)一化，先不多說，先談談當時我理解中的流程：首先如果要轉賬，我們要在柜臺前填一份一式五聯(lián)的單（一定要用力填喲，不然最后一張紙上看不到什么字跡的），然后這筆錢就從我們的賬戶上扣下來，劃到銀行內(nèi)部的某個往來賬戶上了。然后這些單據(jù)，再手工傳遞到上一級，上一級再手工傳遞到人行（當然，也可能上一級就是人行，這里不要太較真），每傳一次，這筆資金都會在當前做業(yè)務的這一個銀行的往來賬戶中流動，最后通過人行，流到你想轉入的銀行中，那個你手工填的單，也流到那家銀行中。最最后，轉入行的業(yè)務人員核對單據(jù)，賬號，戶名都沒問題，這筆錢就從往來賬戶劃到我們所填的轉入賬戶上去了。在這些過程中，結算的同時就已進行了清算，資金的流向是A銀行的某支行行 B地人行 B行

A銀行的當?shù)胤中蠥地人銀行當?shù)胤中蠦銀行的某支也就是每一筆轉賬，在行間的這一步，都是通過它們在人行的資金往來賬戶，實現(xiàn)了資金的流動。如果是上述的資金流向，就叫先直后橫。如果是A地人行B銀行A地分行B銀行B地分行B銀行某支行這種方式，就叫先橫后直。這些單據(jù)的傳遞，都是手工的，或者說是落地的。如果是用信件的方式傳遞，那就是信匯；如果是用打電報的方式傳遞，那就是電匯。手工的傳遞都是有場次的，比如一天兩場，或是一天一場之類的。所以這個轉賬的效率有多快，我就不說了?，F(xiàn)在科技進步了，手段豐富了，社會于是也就和諧的。先從我個人較為欣賞的大額支付說起。我一向認為大額這個業(yè)務設計得是相當?shù)暮侠?，因為資金是點對點，清算行對清算行，大大縮短了流程，更重要的是，信息的傳遞是自動的。還是上述的CASE，假設轉出行與轉入行都開通了大額業(yè)務，那么資金的流向是：A銀行的某支行 人行 B銀行的某支行原則上是這樣的實現(xiàn)，當然行內(nèi)的設計怎么處理我們就不多考慮了。行內(nèi)當然也可以設計成為先從A銀行的支行轉到上級分行然后再發(fā)出，總之人行收到一筆大額的轉賬信息之后，是會自動、直接發(fā)向指定的轉入行（假設轉入行也開通了大額業(yè)務的話）大額系統(tǒng)的對賬，不考慮具體的客戶賬戶，只考慮清算行。通俗的說，人行只管A銀行今天給B銀行轉過去多少錢，轉過去了，人行就不管了。至于B銀行什么時候把這筆錢入到客戶賬戶中，那是B銀行的事，人行不管。聽起來責任還是很清晰的吧，而且這樣也有助于減少賬戶鎖表而造成的行間轉賬失敗。因為大額的這種設計，所以實際轉賬中，幾乎是實時的。我從某地信用社轉到異地招行，在柜臺還沒最后簽字，收款短信已經(jīng)來了。因為大額業(yè)務發(fā)生的時候，是支行對支行的，所以每發(fā)生一筆業(yè)務之后，實際上這筆資金是暫時體現(xiàn)在該支行的某個行間往來賬戶上。所以每天大額業(yè)務結束后，還需要按清算的流程，將這筆資金按往、來分別清算到上一級分行（或是總行吧，總之就是當?shù)氐淖罡吖?jié)點），然后分行與人行發(fā)下來的電子對賬文件進行對賬，檢查匯總往、來數(shù)、金額是否相等。如果相等，那就可以把往來一軋差，轉出多的時候就從存放在人行的賬戶里扣錢，轉入多的時候就往那個賬戶里加錢。至于這個清算的步驟，通常還是由手工發(fā)起，不過這里的手工，就不是指傳遞單據(jù)，而是指運行程序。當然，清算程序也可以自動運行，這個根據(jù)系統(tǒng)的不同，要求的不同，自行調(diào)整設計。5.7額度控制和計息類似，可能有的系統(tǒng)沒有把額度單列為一個模塊來處理，而是僅僅作為業(yè)務模塊之中的一個判斷項。早期的業(yè)務中，的確可以這樣處理。不過隨著現(xiàn)在金融產(chǎn)品的不斷推出，我個人認為還是把額度拿出來單獨搞一下會更好處理一點。比如說，一個賬戶，可能會有幾次凍結，也能會有多項額度控制，每次的解凍，又或者是解除控制，都可能會對賬戶的額度造成不同的影響，如果夾雜在業(yè)務模塊中，字段的設計，狀態(tài)的控制可能都會有些問題，單獨整成一個模塊，或者說是一個大公函，在賬務交易（或是賬務模塊中）的時候，用額度模塊來進行一下判斷，可以更方便的檢測賬戶的可用額度是否足夠。另外，一些賬戶相關的透支什么的，也可以比較好的按客戶來處理，而不是針對每個賬戶設置是否允許透支。以至于循環(huán)授信額度，這些概念都可以拿出來使用，簡單的來說，有點類似于儲蓄卡向貸記卡的管理方式傾斜，不過我沒做過貸記卡，所以這里也提不出太多東西，只好拿個概念出來大家一起參詳一下。5.8沖賬本著想到哪里就說到哪里的原則，剛才突然想起沖賬還沒有說，那么這里就說說沖賬。沖賬的概念前面已經(jīng)提過，這里我們指的，就是紅字沖賬。因為藍字沖賬就是再做一筆別的賬務，從IT人員的角度出發(fā)，其實是另一個合法的正交易，不能算是沖賬。在設計程序的時候，只要是財務類的業(yè)務，就一定要考慮沖賬的問題，不能偷懶，不能妄想測試人員會遺漏。就算別人忘記了測試，如果在真實業(yè)務中發(fā)生了問題，是很麻煩的，所以要養(yǎng)成良好的設計、測試的習慣。（這里不談編碼，因為設計好了自然就會寫代碼的）關于沖賬的實現(xiàn)，我知道的有兩種方式：第一是正反交易的概