http://sns.cio360.net/b/6_100140_178.html
銀行核心系統
入門簡介
科目常識
資産類科目的處理
負債類的科目處理辦法
所有者權益 處理方法
資産負債共同類 處理方法
損益類 處理方法
或有資産負債類
如何防止借貸不平
如何 沖賬
沖賬業務流程描述
傳票以及日志的處理
常見檢測内容
常見總體架構
計息子產品的處理
儲蓄子產品的設計
系統裡的客戶資訊處理
系統裡的貸款業務的一個常見錯誤
系統的清算與結算
系統裡的額度控制
系統裡的沖賬
入門簡介
本文的目标讀者是準備從事銀行核心系統開發、維護的從業人員。請注意，是“準備”，換句話說，可以了解為一份對科技人 員，尤其是對新入門的科技人員業務知識方面的教育訓練手冊，旨在讓諸位從業務方面迅速上手（從技術角度上手的手冊我已經貼過一份了，是以如果是用400的同 行，可以結合本手冊雙劍合璧，效力倍增）。這裡的着重點将會主要在于簡單的銀行會計原理，以及銀行整體的業務流程，還有相應的子產品實作手法和注意事項，對 金融的會計知識方面應該可能會比較粗淺，這一點與金融系統常見的業務教育訓練手冊有所不同，注意體會。
基于此，本文将會假設讀者具備一定的計算機技術，具備少量銀行方面的業務知識，是以如果有從事非IT部門的讀者（比如财務信貸的同僚們），就請不要太計較裡面的表述。當然如果有錯誤，還是非常歡迎指出的。
對于已具備了若幹開發、維護知識，或者是即将采用國外系統來建設的同行們而言，本文的内容可能就過于淺顯了，看得不爽不要怪我沒有事先提醒。
考慮到某方面的問題，這裡的系統簡介将盡可能的脫離某個具體的系統，僅就銀行業務核心系統的共性，進行介紹以及探讨。
最後再說一下，沒有什麼手冊、心得是萬能的，個人的LEVEL UP始終是要靠自己的領悟，這裡隻是希望能讓諸位新人不用象很多人當年一樣，獨自摸索與徘徊。
科目常識
基本法則之一：資産 = 負債 + 所有者權益。
比如說，我們手頭上有40萬，買了一個 100萬的房子，找銀行貸款了60萬，那麼資産就是100萬，負債是60萬，所有者權益是40萬。可以簡單的把所有者權益就了解成為是真正屬于自己的錢。 再引申一下，早些年乃至現在，香港人所謂的“負資産”的說法是非常錯誤的，因為“負資産”實際上是指房子的市值比向銀行貸的錢還要小，也就是負債大于資 産，是以嚴格的來說，應該稱之為“負所有者權益”才對。資産，從理論上來說，是不可能為負的，最多也就是零 。一個号稱是金融中心的地方，實在是不應該出現這種失誤，不過算了，不要和他們計較。
就銀行業務而言，會使用會計科目号來對賬務進行辨別，會計科目号最長為5位，國家标準，通常分為下面六種，這裡隻做簡單介紹，詳細科目可結合著名的的“業務狀況表”來進行了解。
再次重申，下面的說法絕對不嚴謹，僅僅隻是為了便于IT人員了解銀行的會計原理、業務知識。
資産類科目的處理
資産類的科目，用“1” 作為首位科目号，如“1011”，表示現金。
所謂資産，也就是說“理論上屬于銀行 的錢”， 比如說現金，貸款等。比如說某家分行，有100萬現金，然後把這100萬都貸出去了，那麼資産仍是100萬，隻不過歸屬（科目）由現金變成了貸款。至于這 筆貸款能不能收回，這個不歸我們管，就算不能回收，隻要沒被核銷（核銷，術語之一，可以了解為銀行不要這筆貸款了），那麼就仍然屬于資産，是以我們稱之為 “理論上屬于銀行的錢”。
資産類科目都是借方科目，也就是借記時餘額增加，貸記時餘額減少。
負債類的科目處理辦法
負債類的科目，用“2”作為首位科目号，如“2011”，表示對公存款。
本來不屬于銀行的錢，就稱之為“負債 ”。比如說我們存在銀行的錢，雖然銀行可以使用這筆錢，比如說把它貸款貸出去啊，比如說打新股啊，買QDII啊，但是這筆錢隻要我們去取，原則上銀行就應 該給我們，也即是大家常常在營業大廳裡看到的“存款自願，取款自由”之類的意思。這類錢，可以簡單的了解為“本來不屬于銀行的錢”，也就銀行欠我們的錢。
負 債，很有趣的東西喔，銀行是負債經營的，比如說一家銀行貸款有100億，其實它本身是沒有那麼多錢的，這些錢都是來自于我們存在它那的錢。如果大家一起都 去銀行的錢取出來，那它就經營不下去了，這種惡劣的行為，稱之為“擠提”，是很不友善的，是要負責任的，我們不要去做。
負債類科目都是貸方科目，也就是借記時餘額減少，貸記時餘額增加。
所有者權益 處理方法
所有者權益類的科目，用“3”作為首位科目号，如“3121”，表示利潤配置設定。
上面說過了，所有者權益，也就是真正屬于銀行的錢，即是所謂的“核心資本”。原則上，它包括了一家銀行注冊時的資金，曆年來的盈利（假設有盈利的話，當然還要扣除各類成本開銷），如果是股份制銀行的話，還包括股本金之類的吧。
這類科目相對數量較小，金額較大。
科目屬性忘了。
資産負債共同類 處理方法
資産負債共同類，通常表示往來賬戶，用“4”作為首位科目号，如“46411”，表示通存通兌。
這類科目，通常是指一些往來類賬戶，所謂往來類賬戶，嗯，就是金融往來的賬戶喽。
這個科目有點麻煩，可能要結合具體業務來解釋一下：
比 如說我們在招行有個賬戶，然後跑到工行的ATM上去取錢（招行也是，中山這種偉人的故鄉居然都不開個點，嚴重BS一下），那麼取款成功之後，我們的招行上 的賬戶的錢就少了，工行ATM裡面的現金也少了。這筆錢是工行替招行先支付的，要找招行要的。是以工行一定會有一個科目，用來标記它有多少錢要找招行要； 而招行也要有一個科目，也是要用來标記它有多少錢要給工行。（怎麼要，那在後面清算一節裡面會提到。至于跨行ATM的取款原理，就不用再細說了吧。）這個 用來标記應付，應收的科目，就是往來類科目，對于工行方而言，當時使用到的就是一個類似于資産類的科目（有點類似于應收賬款的意思，或者也可以了解成一種 短期的貸款，總之就是工行先付出的資金）；招行當時使用的就是類似于負債類的科目。
上面提到的，因為是銀行與銀行之間的業務往來，是以用來辨別資 産與負債的科目會有分别，如果是行内之間的往來，那麼不會搞得那麼複雜（或者也可以說搞得更複雜），就會用一個科目來搞定，這個科目根據具體需要，臨時用 的，有時表示資産，有時表示負債（其實也就是科目上的餘額有時是借方，有時是貸方。因為這個科目既不是資産，也不是負債，隻是臨時用來表示營業往來的，通 常每天會清零，也就是所謂的清算。
一般而言，城市級别的商業銀行因為是一級法人，是以清算之後，行内往來賬戶上餘額為不為零都沒什麼關系，反正都 是自已家的錢；而信用社會比較麻煩一點，因為通常一個聯社都是由多個信用社組成，每個信用社都是一個法人，是以聯社内部的往來類賬戶原則上每天應該都清 零，否則賬務上就不好看了。（注意，這裡指的隻是行内的往來賬，如果是銀行與銀行間的，那每天一定是要清零的，否則就是屬于錯誤的情況了）
這類科目在我們做過的項目裡，基本上都簡化了，隻有一個軋差類型的。也就是把當天的借方發生額和貸方發生額一減，哪個大就誰記在哪邊。
我 記得以前還有一種雙方類的科目，那真是玩死人。雙方類的科目是指這個科目既有貸方餘額，又有借方餘額；對應貸方餘額，既有借方發生額，又有貸方發生額，同 理，對應借方餘額，也是既有借方發生，又有貸方發生，如果隻有上期的借貸方餘額，以及當期的借貸方發生額，那是無論如何也推算不出當期的借貸方餘額各是多 少的。（必須根據發生賬務時，是借方餘額，還是貸方餘額來判斷），不知道這類科目的起因為何，總之如果有的而且可能的話，最好能拆分之幾個性質單純一點的 子目來處理。
不好意思，因為對這類科目感觸頗深，也被玩過很多次，被玩很久，一時激動，就多說了幾句。
損益類 處理方法
損益類的科目，用“5”作為首位科目号，如“5011”，表示利息收入。
損益類科目，了解起來應該不難，就是指銀行在一年的業務裡面的收支科目。比如的存款利息，對于銀行來說是一筆支出；貸款利息，對于銀行來說，是一筆收入。這兩個科目就都屬于損益類科目。
一般來說：
收入類科目屬貸方科目，借記時減少，貸記時增加；
支付類科目屬借方科目，貸記時減少，借記時增加。
在了解上，可能與資産、負債類的科目有些相反：
資産是指屬于銀行自己的錢，是借方科目；對應于這裡，收到的錢是銀行自己的，卻又是貸方科目。
這裡，按會計原理來了解可能會更簡單一點，下面一章會講到。
或有資産負債類
或有資産負債類的科目，用“6”作為首位科目号，如“6011”，表示承兌彙票。
聞歌知雅意，顧名思義，“或有”，那自然就是“或者有”，也就是可能沒有了，是以如果沒見過也不奇怪。
這類科目見得少，一般可以忽視它的存在。
這裡再羅嗦一下，在科目下面呢，一般為了便于分類統計，所有的銀行都會再設子目（一個子目一般又會對應多個小子目，或者說是說是多個賬戶），這個子目，有的地方叫“業務代号”，有的地方叫“結算碼”，總之都是一個意思。
要注意一下，科目号是國标，子目通常是自己内定的，對應于信用聯社，就有可能是省裡統一定的。也就是說科目這個東西走遍全國大緻上都是一樣，子目這個東西可能出省，出了城市，或者說一個市裡不同的銀行，可能都不一樣。
如何防止借貸不平
隻要是與會計有關的書，就一定會提到複式記賬法，也稱為借貸記賬法，這裡就不多解釋，簡單說一下。
“有借必有貸，借貸必相等”，這兩句經典的話，是針對表内賬的。對于表外賬，用的其實是單式記賬法，有的叫“收”、“付”，也的也還是用“借”，“貸”，要結合具體的業務來了解，這裡就不展開了。如果沒有特别說明，下面的描述都是針對表内賬的。
對于銀行業務來說，最簡單的是一借一貸，此外，還有一借多貸，一貸多借。多借多貸在銀行業務裡中不允許的，因為這樣無法精确的展現賬務的起始與流向。不過在企業會計中，多借多貸又是允許的，是以說凡事無絕對。
有些時候，基于某些特殊的的原因（常見的主要是頻繁的鎖表問題），可能會臨時采用單邊記賬，但是最後一定會彙總補齊，否則就會出現“借貸不平”這樣的嚴重問題。
如何 沖賬
做錯了賬，要改正它，就可以了解為沖賬。
沖賬有兩種，一種是藍字沖賬，一種是紅字沖賬。
所謂的藍字沖賬，是指與原賬務方向相反，金額為正的一種記賬方式。
而紅字沖賬，就是指與原賬務方向相同，金額為負的一種記賬方式。
藍字沖賬，本質上是做一筆新的業務，僅僅隻是實作了最終的餘額正确，發生額會虛增，是以一般的明顯有錯的賬務，會要求使用紅字沖正。
紅字沖賬因為是負數發生，是以在統計的時候，發生額将會與原來的交易抵銷，這樣的話發生額就很嚴謹了。
實 際上，對于一個系統而言，通常一筆業務的發生，并不僅僅隻包括賬務的登記，還會更改許多表中的資料。比如說一筆簡單的取款交易，除了登記賬務之外，客戶的 賬戶上的餘額還會減少，這個很好了解吧。那麼在沖賬的時候，還需要将客戶上的錢給它加回去。是以，關于沖賬業務的設計，其實也是一個比較有趣的話題，這一 點，将會在後面的章節中進行探讨。
沖賬業務流程描述
對于一個沒有在櫃面實習過的人，描述一下銀行的業務流程，可能是有助于了解系統架構的。
銀行的業務，大緻上可以分為财務類的業務，以及非财務類的業務。
非财務類的業務這裡不做讨論。
财務類的業務，又可分為自動業務，以及非自動業務。
非自動業務，就是那些必須在櫃台辦理的業務，比如說一些轉賬業務，或者金額較大的存取款業務之類的。這類業務，因為是由櫃員發起的，是以會有一些單據列印留底，以做傳票使用。
而自動類業務，就是由系統自動處理的，比如說我們在A分行有個賬戶，然後非要跑到B分行去取錢，那麼B分行那部分的賬務，對于B分行而言就是非自動業務；而A分行那部分的賬務，對于A分行而言就是自動業務。
自動業務因為是自動發生，是以需要業務人員列印報表的時候，才能知道發生了什麼業務。
櫃員日間做各種各樣的業務，然後到了下午關門以後，列印一份“科目日結單”，然後用櫃員手頭留存的傳票，按科目逐一彙總累計，與列印出的科目日結單上的金額進行比對。有錯一定要一查到底。是以原則上，這時列印的科目日結單，應該不包括自動業務，否則就會對應不上。
業 務系統在批處理的時候，還會進行一些自動的賬務處理，然後最後系統還應該會再列印一份完整的科目日結單，以及日計表（可以了解為業務狀況表的簡潔版）。至 于那些自動業務，系統在批處理的時候，或者是櫃員主動查也行，總之就是會有一份“他代本”的傳票（對應于上面提到的業務，A分行的自動業務就應該屬于A分 行的“他代本”傳票。而B分行的傳票因為是非自動業務，是以在交易當時就會有相應傳票産生并列印了）
到了第二天，分行開門後開始營業前，業務人員 需要下載下傳列印各類報表，不過主要的就是前面說的那兩份，然後再看看，如果借貸發生、餘額都相等，所有的非自動業務都有傳票，而且和整個科目日結單都可以對 應上，那麼就表示昨天的賬務完整無誤，然後大家就可以歡天喜地的開始新一天的業務了。
傳票以及日志的處理
從最基本的說起，通常來說，所有的賬務程式都需要列印傳票, 傳票格式通常都是統一的，找份以前看看就可以了。
對應于轉賬業務，需要列印轉賬借、貸方雙方的傳票。
而對于現金業務，則隻列印一張傳票就可以了，借貸方向采用非現金科目的方向。（我個人認為，可能是因為辨別了現金傳票，是以對方科目就自然是現金，于是就不需要再列印了，猜的）
所 以我們在開發程式的時候，列印傳票這一步，一般不會特别強調，都是預設要做的。如果不太清楚的時候，一定要主動向需求設計人員詢向，千萬不要嫌麻煩，抱有 僥幸心理。這種東西如果測試的時候漏掉了，是一定會有人要求補上的。（我在N多項目裡都見過漏寫傳票，然後在程式上線前夕被人要求趕緊加班補制的，是以千 萬不要嫌麻煩）
在日終批處理的時候，可能有些數量龐大的業務，比如說代收付，結息什麼之類的，動不動就是幾十萬筆，一張張生成、列印太不經濟，通 常會考慮采用列印一張彙總傳票，然後加上一份明細清單的方式。還有的時候，如果上百萬的話，可能明細清單都省掉，想辦法導成電子資料都是有可能的。
上面說的是賬務相關的業務。而非賬務類的業務，如果涉及到修改類的業務的話，比如說修改密碼，修改客戶名之類的，通常需要登記日志（LOG），用來記錄，以便查詢。
有的時候，為了統計業務量，或者是為了分析排障，還有可能要求對每一筆發送到主機的業務資料都登記下來，這時候最好采用一種統一的方式來進行登記，以及資料的定期清除，因為這類資料量應該比較大。
常見檢測内容
發生一筆業務的時候，是一定需要進行若幹檢查的。比如最起碼，我們去取錢的時候，就一定會檢查密碼。這裡對一些經常見到的，較為普遍的檢查簡單介紹如下，套用一句合同上流行的話，叫做 -- 包括但不僅限于以下條款：
1、 賬号/卡号是否存在，是否可以正常使用
2、 賬号與客戶所提供的憑證（通常這是指存折客戶，對于卡使用者而言，賬号就是卡号，或者是可以根據卡号查詢出相應的賬号）是否比對。
3、 密碼、證件号碼（如果需要檢查的話）是否與主機資料一緻（印鑒什麼的需要業務人員肉眼核對。現在又出了一種加密機，如果采用了這種先進技術，那當然還需要檢查這種加密後的資訊是否一緻了）
4、 在轉賬的時候，一定要檢查轉出轉入方的戶名與賬号/卡号中的戶名是否一緻。（對私客戶還好辦一點，如果是對公客戶的話，名字又長，括号什麼的再一加，經常會出現問題，總之是一定要檢查）
5、 如果是取款類業務（比如轉賬業務的轉出方也算），一定要檢查賬戶的可用餘額是否足夠。
6、 大家一起來。
常見總體架構
這裡如果用圖可能效果會更好，不過我不會用VISIO，是以就算了。
一般硬體架構，都是一個主機，一個前置機 （大前置），前置機就對外了，比如業務人員用來作業務的終端啦，ATM，網銀，電話銀行什麼之類的可能就都對應這個大前置了。大前置，或者是中間業務平 台，也是一個很值得探讨的問題，可以做得很大，比如建行的大前置，又比如X天的中間業務平台其實也不錯，這裡不做深究。
就軟體架構而言，核心系統一般可以分為業務子產品，賬務子產品，和總賬子產品。
總賬子產品通常記錄了一些賬務的彙總資訊，比如說科目總賬的日、月、年的發生、餘額。銀行中大部分的報表都需要通過取總賬子產品中的資料來生成。總賬子產品的資料一般是取自賬務子產品中，當天的賬務資料。（當然，也有很多報表，需要整合業務子產品與總賬子產品兩部分的資料一起來出）
賬務子產品，就是用來登記賬務的，這部分一般會做得比較通用化，友善各個業務子產品來調用。
業務子產品，當然就是實作各個業務的子子產品了，通常子產品之間相對獨立又互有關聯，如果是賬務類業務，當然就要調用賬務子產品中的程式。如果是非賬務類的業務，那可能業務子產品内部處理一下就可以了吧。
一般業務子產品的資料會對實時性要求較高，而總賬子產品沒有什麼實時性的要求，不過總賬子產品重在統計分析，是以資料量一般會比較大。
計息子產品的處理
有的系統可能沒有把計息單獨列為一個子產品，而是直接嵌套在各個業務子產品之間了，不過設計成一個子產品，個人認為可能會顯得比較專業一點，至于到底好不好用那就見仁見智了。
剛接觸銀行業務的時候，曾經很執着，很傻很天真的想過活期賬戶到底是怎樣計息的，因為定期賬戶的計息方式相對簡單，餘額乘天數就對了，但是活期賬戶的餘額是常常在發生變動的，是以前20多年我一直都不知道銀行每年給我算的活期利息到底對不對。
銀行會計上，通常都會通過“積數”這個東西來計息。何謂積數？就是餘額＊天數，是以積數的機關應該是“元 天”
比如說 利息 = （賬戶餘額＊天數＊利率）/ 360，在這個公式裡，賬戶餘額＊天數就等于積數，于是這條公式也可以寫為 利息 = （積數 ＊ 利息） / 360。
定期賬戶因為賬戶餘額通常不發生變化，是以一般不會涉及到積數。
活 期賬戶采用動戶累計積數的方式來計息。也就是說賬戶餘額沒有發生變動，就什麼事都不幹；當賬戶餘額需要發生了變動時（比如說取款），那麼業務子產品裡就将上 次賬戶變動日，到目前日期的天數計算一算，然後用變動之前的賬戶餘額乘以這個天數，然後把這個積數累加到之前的積數上。最後計息的時候，就使用這個積數乘 以利率再除360。
在設計的時候，就需要把每次賬戶變動的日期都登記下來，還需要有地方記錄賬戶的目前積數。
對公計息，或者是一些需要計息内部賬，有可能是每天計積數，也就是每天把賬戶餘額累加到積數中。之是以這樣設計， 是因為對公以及内部賬戶的數量遠小于對私賬戶，每天把每個賬戶都過一遍，花不了太多時間；而要是每天把儲蓄賬戶都過一遍，就有點類似于結息了。（對私賬戶 多的銀行，有可能達到上千萬戶，尤其是些代理了社保，醫保的銀行，不可小看）不過現在有些很好很強大的國外系統，對于利息的處理，是每日計提，當然，這樣 設計也應該會有它的獨到之處。
剛才這裡提到的了需要計息的内部賬，那麼一般而言，什麼樣的内部賬需要計息呢，我想，應該是不同法人之間上存下放的 款項需要計息。對應于一般的商業銀行以及統一了法人的信用聯社，因為全市是一級法人，可能就沒有需要計息的内部賬了。而對于沒有統一法人的聯社，因為每個 信用社都是一個獨立的法人，那麼信用社存放在聯社的用來做往來清算用的資金，就是需要計算利息的。還有的銀行，對于貸款的處理，也會有資金池的概念，這時 總行下撥分行的用于貸款錢，也是要計息的。
這裡可以看到，對于計息子產品而言，積數是一個很好用的東西。積數除了計息，還有很多其它的用途。比如說招行的金 卡，說的是“日均存款5萬元以上不收取賬戶管理費”，那麼，這個日均存款5萬是如何判斷呢，我很久以前曾經問過一個大堂裡的MM（跟我同姓喔，惜乎已經有 BF了），她說是根據積數來判斷的，也就是每個月需要增加150萬的積數，這樣聽起來就很合理了吧。
對于某些業務來說，可能需要登記利息的明細。比如說貸款的複利的計算，就是根據利息來的。無論是正常貸款，還是逾 期貸款，都會生成利息。生成的利息如果未及時歸還，則會再根據這筆利息生成相應的複利。複利的複利，喔，太可怕了，也還是視為複利吧。總之，我的意思就是 說，儲蓄、對公賬戶這樣的結息，在計息子產品中可以不用登記利息的明細，因為最後結息的時候根據積數一次搞定；而對于貸款（或者是其它有需要的子產品），可能 需要在每一筆利息産生之後，都把它登記下來，已保留行使進一步措施的權利。
除了貸款之外，還有一些定期賬戶，也最好采用明細的方式進行處理，越細越好，比如什麼零存整取，教育儲蓄之類的，要是沒有詳細的每期存款登記，漏存登記等等，是很容易就被它玩死的。
通知存款以前覺得它很可怕，現在想想，突然又覺得沒那麼可怕，無非就是通知取款，通知期限内的積數登記，然後取款又或者取消通知。可能最主要的，就在于通知期限内的積數計算。總之提取一個計息子產品，為這類業務特别定制一些明細檔案是很好的一個選擇。
提到計息，也就順便說一下利息稅。國家在這十年來，調整了兩次利息稅稅率，一次是漲成兩分，一次是降成五厘，就那 麼一點錢，調來調去累不累，要收就收，不收拉倒，還搞什麼分段計稅，煩死個人。在這裡，不知道有沒有人是負責搞利息稅這部分程式的，也不知道去年改這部分 程式的時候，有沒有很不爽過。其實要是早考慮到這種情況，倒是可以一開始就通過設定利息稅參數表，然後修改計息程式，讀取利息稅參數表，最後根據不同階段 的參數，分段計息算稅。這個方法倒是可行的，也實作過，對于整存整取的定期來說，算得上是一勞永逸，不過對于活期而言，每次調整利息稅稅率的時候可能就要 搞一次類似于結息的東西了，好象沒有一勞永逸的方法。
在國外的先進系統中，還有一種精采的倒起息可以讓人一籌莫展。這種玩法的意思，就是說當客戶來櫃台前做個什麼交易 的時候，允許賬戶的起息日期在業務發生日之前。比如說有人7月14号來到櫃台前還一筆貸款的款，然後說我這筆錢明明7月7号就到賬上了啊，為什麼銀行不給 我扣，非得讓我貸款逾期之類的話。然後核查，如果屬實，那就倒起息一把，現在雖然是7月14号，但還是當它是7月7号還的。（好象是這樣，也可能是我說錯 了，大家對這段解釋千萬不要太放在心上）總之，如果有倒起息的需求，那必須在最開始設計的時候就與其它計息，以及業務流程整合在一起來考慮，如果中途加入 這個需求，那改起設計來會比較費勁，改起代碼來更是難上加難。
最後，我們再來說說計提，這個也和利息有關。計提常用于利息支出，比如說利息支出是5211，5字頭，即是一個用 于營業收支的損益類的科目。計提的會計分錄中，對應的科目是應付利息2611， 2字頭，是一個負債類的科目。是以說，計提的含義就在于，雖然目前客戶利息并未産生（是結息的時候才産生），但是這筆利息（尤其是整存整取的定期利息）遲 早是會産生的，是以這裡預先計算，或者說估算出營業支出，計到負債的科目上（負債嘛，本來不屬于銀行的錢，遲早是要被取走的錢），然後到這類賬戶結息的時 候，就直接從應付利息中支出，計到客戶賬戶上，而不走利息支出這個科目了。看懂了吧，這裡其實也就包含了管理會計中的概念，實際上是産生一個提前測算成本 的動作。諸位搞IT的朋友們，你們看過《會計學原理》嗎？
儲蓄子產品的設計
這部分子產品一般沒太多可講的，通常的設計，都是搞個主檔案，儲存針對每個賬戶的資訊（比如說賬号，賬戶餘額，目前積數什 麼之類的，總之就是與賬戶有關的資訊），然後再搞個賬戶明細，用來記錄每個賬戶發生過的業務。聽聞有的系統設計，不知道是不是考慮到鎖表的問題，計劃取消 主檔案，直接上明細，愕然之餘隻能感歎自己見識淺薄，因為我總覺得明細要考慮沖賬的問題，在讀取上不如主檔案一下搞定那麼暢快。而且主檔案可以有鎖表保 護，可以更好的保障資料的正确性。
是以私底下，我還是很推崇這種“主+明細”的設計方式。以前曾經很無奈地見過有人在新增業務子產品時，把主檔案和明細混在一起來搞，于是整個業務流向怅然若失，需求有變動時改動幾乎無從下手，若非我多年功力，是斷斷不可能在加兩天班後就理順通過測試的。
說 起儲蓄呢，又忍不住再提一下招行，不可否認，它的一卡通做得真的挺好，本外币，定活期，一張卡全部搞定。我以前就經常把活期轉成三個月定期。根據我本人看 法，三個月定期從利率差與時間存放差上來說，成本效益是最高的，也就是說一年期利率雖然高，但很難保障這點錢在一年内不用。是以推薦大家把5K以上的存款轉 成三個月定期，一般忍忍也就可以拿到利息了，當然了貨币基金也是一個不錯的選擇。還有一次自做聰明搞了個一年期的零存整取，成本效益不高，而且還得到櫃台去 辦取款手續，把自己麻煩死了，不推薦使用。
扯遠了，其實本來是想說，活期、定期、外币賬戶，這些都是一個又一個的賬戶，而在招行的設計之中，這些 賬戶，都會與我們的那一張小小的卡片關聯起來。換句話說，人家的卡号，應該隻含具體的卡的資訊，比如說卡的有效期，密碼，磁道資訊什麼之類的，不直接對應 某個具體賬戶的；而各個具體賬戶則應該會有一個與卡号的對應關系。然後到寄對賬單的時候啊，打電話介紹買保險等等附加服務的時候，就還是根據卡号來提供服 務。不過還是要根據賬戶的資金流動來分析消費習慣，以及貢獻度的高低等等。
至于怎麼實作，就根據各位自己的核心系統慢慢體會，不過這麼多年了，也可能大部分銀行都實作了這種功能或者是類似的一卡通，那就當我這段沒有講過吧，總之我覺得這種理念很好很強大，讓我用得覺得很友善。
至于對公，好象就更加沒什麼可說的了。
系統裡的客戶資訊處理
銀行核心系統客戶資訊
客戶資訊，卡号，賬戶号，這三者是層層細化的關系。是以說，整合好三者的關系也是一個不容易的事情。
在 我見過的幾套系統之中，最常見的問題，就是同一個客戶對應多個客戶資訊。這通常又是個曆史遺留問題，比如在手工或單機年代，開戶時對于身份證明證件要求不 是很嚴格，一個人可能開了很多賬戶，還可能是用化名開的賬戶。在移植上線的時候，常常由于重要資訊不齊，又要考慮客戶層面的因素，很少能強制性補齊客戶資 料，通常隻能在移植時自動生成一些客戶資訊，這樣就造成了很多備援，而且也不好再做深層的資料挖掘和客戶分析。相比較而言，新開立的分行可能這種情況會好 一點，而且面對的客戶高端一點的，又會更好一點。
在新系統上線，做資料移植的階段，一般客戶資訊的問題是最先展現出來的，通常新系統會要求得比較 理想化，而實際情況千奇百怪。這裡說說常見的，比如說新系統一般會要求證件号碼唯一，但是因為很多客戶的證件資訊缺失，是以這個号碼唯一可能會有困難；再 比如說有時可能會出現證件号碼重複，而且還真的不是同一個人。
總之這些問題，它不是新系統的錯，也不能完全說是舊系統的錯，最關鍵的是在移植的時候如何處理利用好這部分客戶資訊。
再一個問題，就是客戶資訊的更新。個人認為最好能有一個有效的途徑來更新客戶資訊，尤其是工作機關，電話号碼，對于很多流動人員來說，經常會變換。如果每次都要來櫃台更新，我想那基本上就可以認為它是形同虛設了。
可以說，随着現在以客戶為中心的概念的提出以及越來越多的實作，客戶資訊這個子產品也應該會越來越受到重視，以前設計的表結構應該會有些不夠用了。目前如果沒有新系統要上的同行們，恐怕是要等着改結構加字段了，保重。
系統裡的貸款業務的一個常見錯誤
很多地方都會把一般的商業貸款與按揭貸款和消費貸款（比如車貸、分期付款之類的，總之有點類似于按揭貸款的）區分開來，這樣自然有它的道理。我在這裡隻談我個人的設計方案。
現 在的商業貸款常常采用一筆發放，一筆回收的概念（當然有時會有提前還款，但不象按揭貸款這樣有個具體還款計劃），然後用合同号，或是借據号做為貸款的一個 類似于唯一關鍵字這樣的東西。但是有時公司的商業行為中，一個大項目裡會包含多個子項目，然後對應不同的子合同，這些合同對應的貸款之前其實都是有關聯 的，尤其是在算逾期什麼之類的時候，有的是一逾全逾，有的又不是。是以我個人覺得，貸款最好做成多筆發放，多筆回收的形式，發放與回收不必一一關聯。但最 好在貸款錄入時（這時不一定已放款），就錄入相應的還款計劃。
貸款的賬号，最好與具體的業務資訊剝離，類似于儲蓄裡面“一卡通”的概念一樣，每個貸款，有它自己獨立的貸款号，然後正常、逾期、兩呆，以及相應的利息賬号都與這個貸款号關聯起來，便于以後的跟蹤追查。
而對于按揭貸款來說，因為期限長（常常是二三十年），而且比較具有規律性，是以一般就不用列出還款計劃的明細了。不過要注意，一般按揭貸款的首月還款是按天算息的，稍微注意一下就可以了。
最後，特别強調提出一點，見過兩家行，都推出過“等本等息”這種經典的業務産品，也就是客戶每月按等額法算出的金額還款，但本金的計算則按等本的方式來算。
這 裡要大聲疾呼，這種東西從原理上來說就已經是錯誤的！因為同樣金額，同樣期限的貸款，等額法的利息是要大于等本法的利息的。等本法計算友善，了解簡單；而 等額法是數學家們經過精确的計算，推導出公式，最後計算出的一種還款方法。也就是每個月的還本、還息都要嚴格按照計算出的公式，這樣才能達到等額的效果。 試想想，這個月還了一定的本金之後，下個月計算出的利息就不一樣了吧，這時要求下個月還的本金與還的利息加起來還是和這個月的一樣多，而且還要求每個月還 的本金加上利息都是一樣多。是以，除非是數學學得特别好的同學，咱們一般的程式員不要妄想自己能推導出公式來，照着公式算就行了。如果強行按等額法計算出 的錢來制訂還款計劃，又按等本法的方式還計算每期還款本金，雖然是友善了，但是在每年利率變更，重算利息時，必然會導緻利息總和由等額法的利息漸漸趨近于 等本法的利息，也就是總利息額将會越來越少，于是要麼在本金與利息的問題上無法自圓其說，要麼可能會出現利率上調還款金額反降，甚至負利息的問題，不可不 查。
系統的清算與結算
清算與結算本來是兩種業務，不過因為結算中通常又會包括清算，要分成兩小節，每小節又說不了太多話，是以幹脆放在一起算了，而且這一節隻談流程，不講設計，這種業務流程理順了自然就可以設計了。
先約定一下，商業銀行的級别，一般是 分行—支行兩級，有的可能還會有儲蓄所這種第三級。簡化起見，暫時就分兩級來說吧。如果對應到信用社，那就是聯社營業部—信用社營業部。分社一級省略。
先 從結算說起，這裡的結算業務，指的就是跨行轉賬，至少我是打算這麼說。每家商業銀行，都會在當地的人民銀行有一個資金賬戶，可以了解為結算業務用的備付金 賬戶。然後在自己行内，也會開立一個與之對應的“上存人行款項”的賬戶。理論上，人行的這個賬戶和我們自己行内的這個賬戶，表達的都是“該銀行存放在人民 銀行的錢”的這個意思，是以金額也應該相等。那麼，這兩個賬戶在不同的銀行（也即不同的系統中），如何保障它的一緻性？這一般就是通過日終，營業終了時的 對賬來保障。是以對賬是很重要的，這個後面再說。
至于結算業務的流程，先從遙遠的手工賬/單機賬年代說起吧。在那個時候，結算的途徑、概念、術語 可以說是五花八門，什麼先直後橫，先橫後直，提出借方，提出貸方，提入借方，提入貸方，信彙，電彙等等等等，不把人轉暈誓不罷休。現在好象大小額支付橫空 殺出，倒是簡化了不少。當然也還有行間轉賬，同城支付，省金融平台，不過概念上漸漸趨向統一化，先不多說，先談談當時我了解中的流程：
首先如果要轉賬，我們要在櫃台前填一份一式五聯的單（一定要用力填喲，不然最後一張紙上看不到什麼字迹的），然後這筆錢就從我們的賬戶上扣下來，劃到銀行内部的某個往來賬戶上了。
然 後這些單據，再手工傳遞到上一級，上一級再手工傳遞到人行（當然，也可能上一級就是人行，這裡不要太較真），每傳一次，這筆資金都會在目前做業務的這一個 銀行的往來賬戶中流動，最後通過人行，流到你想轉入的銀行中，那個你手工填的單，也流到那家銀行中。最最後，轉入行的業務人員核對單據，賬号，戶名都沒問 題，這筆錢就從往來賬戶劃到我們所填的轉入賬戶上去了。
在這些過程中，結算的同時就已進行了清算，資金的流向是
B銀行的某支行B銀行當地分行B地人行A地人行A銀行的當地分行A銀行的某支行
也就是每一筆轉賬，在行間的這一步，都是通過它們在人行的資金往來賬戶，實作了資金的流動。
B銀行某支行這種方式，就叫先橫後直。B銀行B地分行B銀行A地分行如果是上述的資金流向，就叫先直後橫。如果是A地人行
這些單據的傳遞，都是手工的，或者說是落地的。如果是用信件的方式傳遞，那就是信彙；如果是用打電報的方式傳遞，那就是電彙。手工的傳遞都是有場次的，比如一天兩場，或是一天一場之類的。是以這個轉賬的效率有多快，我就不說了。
現在科技進步了，手段豐富了，社會于是也就和諧的。先從我個人較為欣賞的大額支付說起。我一向認為大額這個業務設 計得是相當的合理，因為資金是點對點，清算行對清算行，大大縮短了流程，更重要的是，資訊的傳遞是自動的。還是上述的CASE，假設轉出行與轉入行都開通 了大額業務，那麼資金的流向是：
B銀行的某支行人行A銀行的某支行
原則上是這樣的實作，當然行内的設計怎麼處理我們就不多考慮了。行内當然也可以設計成為先從A銀行的支行轉到上級分行然後再發出，總之人行收到一筆大額的轉賬資訊之後，是會自動、直接發向指定的轉入行（假設轉入行也開通了大額業務的話）
大 額系統的對賬，不考慮具體的客戶賬戶，隻考慮清算行。通俗的說，人行隻管A銀行今天給B銀行轉過去多少錢，轉過去了，人行就不管了。至于B銀行什麼時候把 這筆錢入到客戶賬戶中，那是B銀行的事，人行不管。聽起來責任還是很清晰的吧，而且這樣也有助于減少賬戶鎖表而造成的行間轉賬失敗。
因為大額的這種設計，是以實際轉賬中，幾乎是實時的。我從某地信用社轉到異地招行，在櫃台還沒最後簽字，收款短信已經來了。
因為大額業務發生的時候，是支行對支行的，是以每發生一筆業務之後，實際上這筆資金是暫時展現在該支行的某個行間 往來賬戶上。是以每天大額業務結束後，還需要按清算的流程，将這筆資金按往、來分别清算到上一級分行（或是總行吧，總之就是當地的最高節點），然後分行與 人行發下來的電子對賬檔案進行對賬，檢查彙總往、來數、金額是否相等。如果相等，那就可以把往來一軋差，轉出多的時候就從存放在人行的賬戶裡扣錢，轉入多 的時候就往那個賬戶裡加錢。
至于這個清算的步驟，通常還是由手工發起，不過這裡的手工，就不是指傳遞單據，而是指運作程式。當然，清算程式也可以自動運作，這個根據系統的不同，要求的不同，自行調整設計。
系統裡的額度控制
和計息類似，可能有的系統沒有把額度單列為一個子產品來處理，而是僅僅作為業務子產品之中的一個判斷項。早期的業務中，的确可以這樣處理。不過随着現在金融産品的不斷推出，我個人認為還是把額度拿出來單獨搞一下會更好處理一點。
比 如說，一個賬戶，可能會有幾次當機，也能會有多項額度控制，每次的解凍，又或者是解除控制，都可能會對賬戶的額度造成不同的影響，如果夾雜在業務子產品中， 字段的設計，狀态的控制可能都會有些問題，單獨整成一個子產品，或者說是一個大公函，在賬務交易（或是賬務子產品中）的時候，用額度子產品來進行一下判斷，可以 更友善的檢測賬戶的可用額度是否足夠。
另外，一些賬戶相關的透支什麼的，也可以比較好的按客戶來處理，而不是針對每個賬戶設定是否允許透支。以至 于循環授信額度，這些概念都可以拿出來使用，簡單的來說，有點類似于儲蓄卡向貸記卡的管理方式傾斜，不過我沒做過貸記卡，是以這裡也提不出太多東西，隻好 拿個概念出來大家一起參詳一下。
系統裡的沖賬
銀行 核心系統裡的沖賬
本着想到哪裡就說到哪裡的原則，剛才突然想起沖賬還沒有說，那麼這裡就說說沖賬。
沖賬的概念前面已經提過，這裡我們指的，就是紅字沖賬。因為藍字沖賬就是再做一筆别的賬務，從IT人員的角度出發，其實是另一個合法的正交易，不能算是沖賬。
在設計程式的時候，隻要是财務類的業務，就一定要考慮沖賬的問題，不能偷懶，不能妄想測試人員會遺漏。就算别人忘記了測試，如果在真實業務中發生了問題，是很麻煩的，是以要養成良好的設計、測試的習慣。（這裡不談編碼，因為設計好了自然就會寫代碼的）
關于沖賬的實作，我知道的有兩種方式：
第 一是正反交易的概念。也就是普通的賬務交易，稱之正交易。每一個正交易，都需要有一個與之比對的反交易，如果是按交易碼來管理的話，可能會有一個标準來定 義反交易的交易碼，比如說正交易碼加上5000就是相應的反交易之類的。（這裡隻是随便舉個例子，比如說0001表示取款，那麼5001就表示取款的反交 易）因為沖賬在賬務處理上，具有一些共性，比如說都是按原來的财務的會計分錄，隻是金額為負發生賬務即可，是以有可能會有一些公共函數來調用，不過總的來 說，都是小函數的概念。這種設計的缺點很顯而易見，就是交易碼，代碼量都要翻倍。業務人員在沖賬的時候也需要稍微算算交易碼，有可能會輸錯。好處也是很明 顯的，就是程式之間互相不影響，修改維護都很容易。
第二種設計思路就是大函數的概念，也就是使用一個交易來實作沖賬。因為前面說過，沖賬業務具有 一些普遍的共性，就基本原則來說，找到這筆正交易最初的賬務，就可以了。是以使用一個大交易來實作。至于各個業務子產品沖賬後，在财務處理完之後的業務沖 賬，那可能就需要不斷的在這個大交易中挂上各類外挂了。這種設計的缺點也很明顯，就是維護起來很不友善，因為相當于把業務子產品的沖賬都內建到一個大交易 中，在版本控制，大量測試的時候可能會有較多沖突。好處就是不占用交易碼，也可以減少很多代碼量，對于很标準的沖賬，甚至不需要特别去考慮沖賬的問 題。（不過怕的就是不那麼标準的沖賬）
這兩種方法各有優缺點，不知道大家的系統中，使用的哪種方式。這裡我提出一個集合兩者的第三種方法，一起來參詳一下：
仍 然考慮以大交易為主，不過大交易按某個參數表，來決定調用業務子產品中的部分程式解決業務子產品的沖賬問題。如果是非常标準的沖賬，就不需要刻意寫沖賬程式。 如果是不标準的沖賬，就在參數表中按設計中自已定義好的各類辨別符，使大交易可以判斷出何時調用業務子產品中的沖賬子程式（這些沖賬子程式可以随時新增，名 字也可以自定義，總之是在參數表中來定義）。至于大交易與沖賬子程式中間的程式入口參數的傳遞，因為各個業務子產品要求都有所不同，是以可考慮使用一個大字 符型字段，或是資料隊列傳遞字元流的方式來解決。
暫時先想到這麼多，其實還有其它的東西。比如說日終批處理，不過做到這一塊的同行們想來不是技術骨幹就是業務能 手，也就沒必要看這份入門級的東西了。還有拆借，貼現，不過這部分在核心系統裡面占的份量很小，業務了解起來也不難，抓住一個熟悉業務的人多問問就問出來 了。還有代理業務，不過這種業務的設計也多半是主+明細的方式（比如說代理機關的彙總資訊，以及相應代理業務的明細記錄），麻煩的可能反而主要在資料的交 互上，也就是什麼倒盤啊，資訊錄入啊什麼的，又或者是具體的程式運作效率上，和這個整體設計的關系倒不大。
關于批處理，我做得比較多，還是再簡單說兩句。一般來說，會要求維護人員按各自的業務子產品，維護批進行中的相應程式。不過最後，仍然需要一個總體上能把握的人來協調排程。批處理的程式大緻上可以分為三種功能：
實 現各類日終自動業務。比如說到期自動扣款（用過信用卡的朋友們應該深有體會吧），貸款的形态轉移，儲蓄結息（居然現在變成一年四結，有些先進的國外系統還 要天天計提，我隻能說系統的設計出發點各有不同啊），可能還會有上面提到的日終清算。當然，還包括了各類的日初業務初始化。
實作賬務子產品資料向總賬子產品資料的轉換，也就是更新總賬子產品的資料。嚴謹一點的系統，在更新了總賬子產品的資料之後，還會用程式來檢查一下總賬子產品的資料與業務子產品中的資料是否比對，一緻。（也就是傳說中的總分核對）
生成各類報表。這部分可能主要是從總賬子產品中出，也可能需要綜合一下業務子產品中的資料。
批處理的發起，是由固定的操作人員來執行，沒見過設計成按時間點自動運作的。
剛才說到批處理的三項基本功能，而其實在各類功能中，程式的運作順序還是頗有講究，不能随意亂放，否則可能會出現無法預知的問題。
批處理的排障，也是一個比較痛苦麻煩的事情，這裡真誠的建議各位維護批處理的同行在有大子產品上線前，做好心理準備，多多祈禱，實在不行還可以試試拜拜土地。