集成銀行核心業務的方法和系統的製作方法
2023-10-08 11:01:04 1
專利名稱：集成銀行核心業務的方法和系統的製作方法
技術領域：
本發明涉及金融交易系統，特別是涉及一種集成銀行核心業務的系統和方法。
近年來，金融機構大幅度變化。目前，銀行方面與以前相比能夠提供更多元化的產品與服務。這些產品和服務都和計算機技術的發展密切相關。例如建立在計算機和網絡基礎上的金融交易卡業務、自動存取款業務、銷售點自動轉帳服務、電子匯款、企業銀行、家庭銀行、電話銀行和衛星銀行服務等。但這些產品與服務自成一體，重複開發，於是造成了資源的浪費，並且各產品和服務不能共享客戶數據，無法為系統提供綜合的客戶、業務信息。
為了克服現有的銀行業務系統中存在的以上問題，本發明提供一種集成銀行核心業務的系統和方法，它涵蓋的主要銀行核心業務包括活期存款、定期存款、貸款、代理、結算、信用卡/儲蓄卡、會計、電子匯劃、清算、帳簿、客戶信息共用等。未來將涵蓋支付系統、外匯系統、投資系統等。本發明獨立於各個具體業務的架構模塊，同時還為開發各種新興銀行業務提供一個靈活而且功能強大的平臺。
根據本發明一個方面的集成的銀行核心業務系統包括用於提供應用業務開發環境的業務平臺，在該業務平臺中集成了對於各種銀行核心業務來說是共同的處理部分，以便對客戶情況、業務情況進行分析，為系統提供綜合的客戶、業務情況；基本業務規則庫和共同函數庫，基本業務是能夠獨立地完成某種完成的業務操作的最小單位，而共同函數是實現基本業務中可能被經常重複使用的功能的程序；和，應用業務子系統，通過對基本業務規則進行組合構成各種具體的應用業務。
根據本發明的另一個方面的集成銀行核心業務的方法包括步驟對應用業務進行分析，建立用於提供應用業務開發環境的業務平臺，在該業務平臺中集成了對於各種銀行核心業務來說是共同的處理部分，並為各種銀行核心業務共享數據建立核心業務共享數據資料庫，以便對客戶情況，業務情況進行分析，為系統提供綜合的客戶、業務情況；對應用業務進行分析，得出基本業務規則，建立基本業務規則庫並將共同處理功能設計成共同函數庫，其中基本業務是能夠獨立地完成某種完整的業務操作的最小單位，而共同函數是實現基本業務中可能被經常重複使用的功能的程序，和通過對基本業務規則進行組合構成各種具體的應用業務。
通過以下結合附圖對本發明實施例的詳細描述，可以使本發明的目的、特點和優點更加清楚。
圖1示出了根據本發明一個實施例的集成銀行核心業務系統的各組成部分。
圖2示出了架構控制模塊的結構。
圖3示出了架構控制模塊與其它模塊之間的關係。
圖4示出了架構控制模塊可以調用的各種功能。
圖5示出了消息格式器的工作流程。
圖6示出了應用伺服器的工作流程。
圖7示出了資料庫界面模塊。
圖8示出了CBS系統整體處理模型。
圖9示出了文件訪問模型。
圖10示出了連線批處理模型。
圖11示出了連線報表的處理流程。
圖12示出了預約報表處理流程。
圖13示出了系統外部接口模塊的架構。
圖14示出了模擬測試模塊的工作流程。
圖15示出了測試KB/CF的工作過程。
圖16示出了連線記帳處理模式。
圖17示出了批處理記帳流程。
圖18示出了衝正處理流程。
圖19示出了次日帳切點情況。
圖20示出了ATM軋帳情況。
圖21示出了ATM作業模式與整批時段(Time Slot)圖22示出了24小時交易控制流程。
圖23示出了KB連動處理流程。
如圖1所示，本發明的集成銀行核心業務的系統在設計上承接需求分析的數據模型(ERD)及處理模型(DFD)所產生的數據字典，以生成器(Generator)建立系統所使用的數據格式(Data Layout)及內存表格。同時開發銀行業務應用平臺(Business Platform)，以承載銀行複雜的應用交易(Application Transaction)，進而增進應用程式的開發及維護效率。在應用業務上，分析出銀行的基本業務處理規則，將規則設計成業務知識模塊(Knowledge Block)，並將共同處理功能設計成共用函數(Common Function)。最後由應用交易(Application Transaction)組合成業務運行(Operation)系統。
以下通過業務平臺，基本業務規則庫和共同函數庫以及應用業務子系統三個方面詳細地描述本發明的集成銀行核心業務系統CBS。
1．業務平臺(Business Platform)為了提供集成的銀行核心業務系統，根據本發明優選實施例，在業務平臺中集成了對於各種銀行業務來說是共同的處理部分，並為各種銀行核心業務共享數據建立核心業務共享資料庫，以便對客戶情況、業務情況進行分析，為系統提供綜合的客戶、業務情況。以下結合附圖描述業務平臺的主要模塊和關鍵的處理流程。其中主要模塊包括架構控制模塊(CCBMain)、資料庫界面模塊(DBIMain)、文件界面模塊(FAIMain)、連線批處理主控模塊(CenterCut Main)、連線報表模塊(Online Report)、外部接口模塊(External Interface)、模擬測試模塊(Testing Driver)關鍵的處理流程包括會計處理(Accouting Process)、衝正處理(EC Process)、24小時運行模式(24 Hours Mode)、KB的連動處理。
1．1架構控制模塊架構控制模塊是CBS中連線交易的主控模塊，也是整個系統的核心。圖2示出了架構控制模塊的結構。
在CBS系統中，與具體系統平臺，如主機、作業系統、中間件、通訊協議和資料庫等，相關的功能都集中在系統功能調用界面和資料庫界面模塊內，並將這些功能作為通過獨立於具體平臺產品的統一界面提供給系統內的其它模塊，從而避免了系統對平臺的依賴性，使得CBS系統具有很好的平臺獨立性和適應性。
同時CBS的大多數其它模塊，尤其是架構控制模塊、應用伺服器模塊、基本業務規則/共用函數和應用交易等，都僅使用了純COBOL語言，而且符合ANSI85標準，也使得CBS系統具有出色的可移植性。在移植過程中，大多數程序，特別是所有的應用業務程序，僅需重新編譯就可以立即使用。
圖3示出了架構控制模塊與其它模塊之間的關係。圖4示出了架構控制模塊可以調用的各種功能。
1．1．1消息格式器TDT(交易定義表)表每個應用業務子系統都各有一個TDT表。其中定義該子系統中每個交易的輸入信息中的欄位、欄位的順序、數據類型、長度、是否必輸、該欄位在TFT表中的位置、轉換後數據類型和長度。
TFT表每個應用業務子系統都各有一個TFT表，它是該子系統所有交易的輸入欄位的集合。各子系統的交易執行時，從TFT表中得到各自的輸入信息。
消息格式器工作流程圖5示出了消息格式器的工作流程·讀取對應子系統的TDT表·找到該交易對應的TDT表中的記錄
·根據TDT記錄中定義的輸入欄位順序、數據類型、長度和是否必輸，依次檢查各輸入欄位的取值是否合法·根據數據類型、長度、欄位在TFT中的位置、轉換後數據類型和長度依次轉換輸入欄位並置入該子系統的TFT表中1．1．2應用伺服器應用伺服器完成公共的業務處理，如帳務處理、重要憑證控管、客戶信息建立等等。其具體工作情況參見圖6。
1．2資料庫界面模塊本模塊通過統一的服務界面PDBIMAIN向其它模塊提供資料庫訪問服務。其主要作用包括·使其它模塊程序不包括依賴於特定資料庫形態或產品的語句。當改變底層資料庫產品時，所有應用程式不作任何變動就可以繼續使用。即實現CBS系統對資料庫的獨立性。
·使得CBS系統可以支持多種資料庫形態和產品，如層次型資料庫和關係型資料庫。進而在同一個系統中，可以同時使用多種資料庫管理系統，將不同的資料庫存放在不同的資料庫管理系統中，從而滿足特殊的業務和性能需要。
圖7示出了資料庫界面模塊，其包括·PDBIMAIN 資料庫界面模塊服務接口·GDBIMAIN 資料庫界面模塊主控程序·GDBI4IMS IMS資料庫服務主控程序·GDBI4RDB 關係型資料庫服務主控程序·Access Engine資料庫訪問引擎。
圖8示出了整體處理模型。
如圖所示，GDBIMAIN處理流程為1)初始化工作變量，取得所需的系統工作區2)輸入檢查，包括普通欄位檢查、二級索引檢查、DB名稱/分段名稱/欄位名稱檢查等3)非必輸參數預設處理
4)格式化資料庫訪問請求5)調用訪問引擎存取資料庫6)準備輸出結果7)錯誤處理下面介紹部分重要的相關系統工作區·TDBISIDX(二級索引搜索表)用於檢查二級索引是否存在，以及得到對應的資料庫名稱和資料庫序號·TDBISSEG(分段搜索表)用於資料庫名稱、分段名稱和欄位檢查，以及得到資料庫的根分段名稱或分段的關鍵字的名稱·CBAPAARE(訪問路徑區)記錄當前的資料庫訪問路徑。資料庫訪問路徑由到目前為止的本交易對該資料庫的操作所決定。GDBI4RDB根據CBAPAARE和應用程式本次資料庫操作指令(PDBIMAIN)決定操作資料庫的具體方式。
此外，在RDBMS環境中，對每個表的訪問都通過一個特殊的程序實現，這個程序就是該表的訪問引擎。所有的訪問引擎都由特殊的生成器(詳見生成器)自動產生。通過修改生成器的參數或擴展生成器功能可以產生具有不同功能的訪問引擎，而不必修改應用程式。
另外，GDBI4RDB具有可擴展性。根據GDBIMAIN的層次型架構和訪問引擎設計，未來增加新的功能時，尤其是RDBMS的獨特功能，如連接、求和和複雜查詢等，可以通過調整生成器增加訪問引擎的功能，增加新的PDBIMAIN的功能號，並在GDBI4RDB中作相應調整，即可迅速實現。
1．3文件界面模塊本模塊通過統一的服務界面PFAIMAIN向其它模塊尤其是整批處理作業程序提供文件訪問服務。文件界面模塊的設計使得應用程式不依賴於具體的文件系統，保證很好的可移植性。
圖9示出了文件訪問模型。在CBS中，對每個文件的訪問都通過一個特殊的程序實現，這個程序就是該文件的訪問引擎。所有的訪問引擎都由特殊的生成器(詳見生成器)自動產生。通過修改生成器的參數或擴展生成器功能可以產生具有不同功能的訪問引擎，而不必修改應用程式。
1．4連線批處理主控模塊連線批處理提供用戶或操作人員在批次(BATCH)的環境下利用連線交易繼續批處理，尤其是批量的帳務性處理，如批量轉帳等。圖10示出了連線批處理模型。如圖10所示1)連線批處理可以用三種方式啟動，即使用JCL、在CICS控制臺使用TCCC啟動交易和在連線交易中使用GCCBAJB應用伺服器等。
2)連線批處理主控模塊根據連線批處理啟動時傳入的不同命令調用特定的處理模塊。
3)連線批處理模塊根據當前連線批處理作業的定義控制記錄(Control Profile)，依次讀取連線批處理輸入文件中的記錄，並通過CICS向架構控制模塊請求執行指定的連線交易。
4)架構控制模塊根據輸入的交易代碼執行連線批處理作業指定的連線交易。
5)連線交易結束時，由架構控制模塊自動更新連線批處理定義控制記錄，記錄當前處理的輸入文件記錄序號，當前交易流水號，總成功筆數和總失敗筆數等。
6)架構控制模塊將交易處理結果返回給連線批處理，由連線批處理處理模塊寫入輸出文件，同時根據處理結果設置輸入文件中記錄的處理狀態標誌，以及更新連線批處理定義控制記錄的相關欄位。
7)連線批處理作業結束返回。對於TCCC啟動方式，連線批處理主控模塊會根據需要將處理是否成功的信息返回至CICS控制臺。
連線批處理命令是在啟動連線批處理作業時，由JCL、操作員或連線交易傳給連線批處理主控模塊，連線批處理主控模塊根據該命令完成不同的功能。
·開始(Start)－正常開始。
·重啟(Restart)－可指定某一筆交易記錄作為重開點。
·暫停(Pause)－處理設定數量交易後，暫時停止連線批處理，待一段設定時間過後，自動恢復執行原連線批處理指令。
·修復(Recover)－異常中斷後，修復輸入文件、輸出文件和控制記錄，為重啟作準備·更改(Change)－因應系統表現的變動，調校暫停的設定參數(筆數及暫停時間)。
·查詢(Display)－查詢連線批處理的定義控制記錄及處理狀況。
·停止(Stop)－終止目前連線批處理。若需繼續，則須下中斷後重開指令。
下面再介紹一下連線批處理的重啟和修復·重啟重啟是指，連線批處理作業在執行過程中，被操作員人工中斷或者程序異常退出，然後重新啟動該作業，並從上次中斷處繼續處理的過程。重啟開始處理的第一條輸入文件記錄可以由重啟命令的參數確定。當該參數未輸時，為定義控制記錄中當前處理記錄序號欄位指定的輸入文件記錄的下一條。
·修復在某些異常情況下，例如連線批處理主控模塊和架構控制模塊之間的連結中斷等，架構控制模塊成功執行連線交易後，連線批處理主控模塊可能不能成功的向輸出文件中插入對應的輸出記錄，以及更新輸入文件中的處理標誌欄位和控制記錄中的某些欄位。當發生這種情況時，如果直接重啟該作業，由於輸入文件、輸出文件和控制記錄沒有被正確更新，可能導致後續作業發生錯誤。
修復就是在發生這類情況後，根據連線交易結束前架構控制模塊在控制記錄中記錄的該記錄在輸入文件中的序號和交易流水號，恢復輸出文件中的輸出記錄，以及輸入文件和控制記錄中相應欄位的過程。當連線批處理作業由於Abend而中斷時，必須先修復，然後才可以重啟。上次處理狀態及中斷原因可以從控制記錄中的處理狀態欄位得到。
修復工作流程1)從控制記錄中取得上次處理的最後一筆記錄對應的交易流水號
2)根據交易流水號從重新認證資料庫(BCMVOHD)中取得對應交易的輸出記錄。連線交易是否在處理成功後記錄BCMVOHD由交易定義資料庫(BCMTXPD)中的重新認證標誌決定，因此需要將連線批處理作業對應連線交易的交易定義資料庫中的重新認證標誌欄位設為Y。
3)檢查上次處理是否未將最後一筆輸出記錄寫入輸出文件中，如果是，則根據BCMVOHD記錄將遺漏輸出記錄寫入輸出文件。
4)修復輸入文件和控制記錄中的相應欄位，並修改控制記錄中的處理狀態欄位，標誌修復已經成功完成可以重啟。
下面再介紹一下連線批處理的衝正。
連線批處理的衝正為另一個連線批處理作業，其處理流程與普通連線批處理作業相同。它執行其對應正常連線批處理作業的連線交易的衝正交易。它的輸入文件內容對應被衝正的正常連線批處理作業的輸出文件中的處理成功記錄。連線批處理模塊GCCBCEC就根據被衝正作業的輸出文件內容生成衝正連線批處理作業的輸入文件。其工作流程如圖10所示，1．5連線報表模塊連線報表的功能為將端末發出的列印請求放入主機的報表產生等待隊列中。由主機的報表數據產生程序產生報表後，通知端末啟動報表下傳功能，將報表下傳端末系統，由端末系統進行列印的管理。
等待序列可分為及時及預約兩種方式。
連線報表處理的基本原則為·報表序號－6位本日唯一，由主機自動產生。
·等待序列分為本日與預約兩種。
·排序方法為全分行採先進先出法。
·主機只處理原始數據，有關報表格式，表頭、表尾、分頁、合計、統計、及欄位編輯由端末系統處理。
·主機將記錄報表狀態，其狀況可分為排序中→產生中→可下傳→下傳中→可列印
·如果主機發現請求錯誤，將狀態置為請求異常。
·端末需執行報表列印的有關功能，例如狀態查詢、報表內容查詢、列印、重印、份數控制、刪除、安全控制、統計等功能。
圖11示出了連線報表的處理流程·報表請求(請求格式)·報表請求回應(回應格式)·生成報表通知(連線報表)·連線報表下傳(請求)·連線報表下傳(回應)·逐筆數據圖12示出了預約報表處理流程。
·異常處理當端末啟動查詢主機的報表數據產生狀態為『可下傳』但數據未傳至端末，此時端末提供下傳請求交易，直接啟動主機連線報表下傳交易，進行報表數據下傳。
·連線報表查詢連動下載請求(請求格式)·連線報表查詢連動下載回應(回應格式)1．6外部接口模塊圖13示出了系統外部接口模塊的架構。
該架構的基本原則·1/LINK，CAST，SPOT，OTHER的界面由架構控制模塊的前置處理系統(外部接口)所控制。
·由櫃檯啟動的對外接口交易透過應用伺服器啟動外部接口。
·1/LINK，CAST，SPOT等現行系統儘量不更改其內部處理。
外部接口連接方式1)架構控制模塊至外部接口由AP呼叫不同的應用伺服器來啟動外部接口。
2)外部接口至架構控制模塊通過CICS LINK方式啟動架構控制模塊，輸出輸入參數須符合端末設計說明書標準的輸入輸出格式。
1．7模擬測試模塊(Testing Driver)模擬測試模塊用於程序的單元測試。主要原理是在批處理環境執行JCL，模擬連線交易，驅動架構控制模塊、測試交易和被測程序。使用測試案例文件設定被測試程序的輸入參數。
圖14示出了模擬測試模塊的工作流程。
1)準備被測試交易的輸入消息。輸入消息按照標準的輸入消息格式存放在測試案例文件中。
2)按照JCL模板準備測試案例的JCL。JCL中可以包括傳給測試驅動程序GCCBUTDV的參數(Link Parm)，如機構號、櫃員號、終端號、業務別、CICS系統Id和CICS程序Id等。
3)使用JCL執行GCCBUTDV。GCCBUTDV從JCL和測試案例文件中得到Link Parm和輸入消息。如果Link Parm參數不為空，其值覆蓋輸入消息中的對應欄位。
4)GCCBUTDV使用CICS LINK啟動架構控制模塊，並將輸入消息傳給架構控制模塊。輸入消息的格式和從端末執行交易時完全相同。
5)架構控制模塊根據輸入消息中的交易代碼連動交易應用程式。交易程序處理完成後返回架構控制模塊。
6)架構控制模塊將處理結果按照標準的輸出消息格式傳給GCCBUTDV。
7)GCCBUTDV收到處理結果後，格式化收到的數據，輸出到標準輸出設備。通常為一個測試結果文件。測試結果文件中除交易輸出消息外還包括輸入消息，並且有字符和HEX兩種格式。
測試KB/CF圖15示出了測試KB/CF的工作過程。
測試KB/CF的方法
·將測試案例中KB/CF每個參數的取值設定在測試案例文件中，並且使用′@′延續符將所有的參數合併為輸入消息中的一個欄位，由GCCBUTDV傳給架構控制模塊·架構控制模塊將包含KB/CF參數的欄位的欄位存入TFT區的對應欄位，然後啟動測試交易測試交易調用被測試的KBCF，並將TFT區中的該欄位作為KB/CF的參數傳給KB/CF，從而達成測試目的1．8會計處理CBS是採用「會計伺服器」的方式來進行記會計帳的工作。「會計伺服器」的概念是讓各個交易或KB在進行記帳時，通過固定的界面來處理其會計分錄產生和記帳。在交易或KB而言就會變得很容易。從維護的角度來說，這模式也能更加體現系統的彈性。在沒有詳細介紹整個會計記帳的設計前，讓我們把目前CCBS在記會計帳方面的特點羅列出來，在後面的描述裡就可以加以引證。
·通過應用伺服器來記會計帳，而程序僅需關心直接相關的業務需求。
·伺服器為整個記帳的核心部分。當會計制度或其它相關需求發生變動時，通常只需要對會計伺服器作相應的調整。而交易或KB不需要或僅需作輕微的改動。這不僅降低了開發和維護的成本，也有效的保證了系統尤其是會計處理部分的質量。
·因為整個會計記帳模式是建立於不同的系統工作區表格中，所以會計分錄的改動，如科目的合併或拆分等，基本上不需要修改程序的。這使得維護會計科目方面的工作變得簡單，修改後的調試也容易許多。
·交易或KB在記會計帳時是通過一些標準、簡易和準確的方式來設定調用會計伺服器的參數，這使交易或KB在設定啟動會計伺服器參數時所引起的錯誤能減到最低。
·會計伺服器在記會計帳前是會統一的檢查整套會計分錄的平衡性，使整個會計系統保持平衡。一旦發生錯誤，會計伺服器會通過架構控制模塊提示錯誤代碼和原因，使用戶在最快的時間內發現系統所存在的問題，並加以糾正。
A會計制度及架構CBS的設計理念是要提供一個可用的、可維護的、可擴充的和完整的會計制度。我們是通過下面的元素來實現整個會計概念的·會計科目表每一個系統所用到的科目都需要在會計科目表中設好才能夠使用。會計科目表是BCMMSCM對應的一筆記錄。記錄內容包括科目號碼4-2-2的三級科目架構。三級科目的架構是指4位的一級科目，一級科目下可以細分為2位的二級科目而二級科目更可以細分為2為的三級科目以達到科、子、細目的三層架構來滿足建設銀行的會計需求。
科目名稱科目的中、英文名稱科目性質科目是資產、負債、損益等帳務性質科目是自營性或是政策性的科目餘額方向科目的餘額是借方、貸方、收方、付方或其他的控制使用級別該科目是那一個部門使用的(分行、支行等的控制)科目狀態該科目是目前可以使用的或是不能使用的狀態屬性標誌每一個科目表中的科目都有著一些特有的屬性，是整個會計系統能夠操作，科目的屬性是通過科目表中的屬性標誌來設定的·科目屬性科目表中有一系列的標誌來表示該科目的屬性(如繳納存款準備金、授權科目、銷帳科目、人民幣科目、外幣科目、各種計提科目、攤提科目、折舊科目、不計息科目、額度科目、衝帳允許科目、表內外科目、最明細科目、外匯買賣科目、聯行往來科目、匯總科目等)·多幣種支持一方面，系統通過多幣種的會計架構來支持銀行未來的業務需要；另一方面，多幣種的支持也使CBS能夠支持多個帳本別來區分政策性或商業性的業務。
·多機構支持核算中心或分行、支行、網點、營業機構·表內外科目系統支持表內外科目的處理模式·總帳系統支持了總帳與分戶帳的基本原則，使銀行可以通過總帳系統與各個業務子系統進行核對和相互監察·內部帳系統支持了一套完整的內部帳處理模式，使銀行能夠對總帳進行必須及足夠的控管及監察業務子系統的運作，增加了系統數據的可靠性。
·掛銷帳處理系統提供了完整的掛、銷帳的功能，使建設銀行能夠控制每一個掛銷科目交易的準確性·內、外部清算銀行的業務涉及眾多的外在金融機構進行各式各樣的業務，而這些金融機構可以在國內或是遍布全世界的。面對著這麼多的業務夥伴，強大的清算系統是不可缺少的。CBS的會計子系統就實現了完整的清算功能，包括分行與總行、分行與分行、分行與其他銀行、分行與清算團體、分行與支行、支行與支行、支行與下屬機構等的清算交易。
B．會計處理中表的應用在CBS會計記帳過程中，我們會常用到好幾個的表。每一個表都有其特殊的用途。在下面，我們就把這些表作一個簡單的描述·TSYSSART(會計分錄總表)會計分錄總表包含了每一個子系統每一個交易或KB可能產生的各種會計分錄。每一個交易都會產生一個或以上的會計分錄，這些分錄的詳細資料會在會計分錄總表中加以設定。如果交易沒有要求override的話，在會計分錄總表中的就是交易需要產生的整套會計分錄了。這個總表的特色是按交易或KB來設定，由於交易可能由多個KB組合構成，所以我們是不能夠從總表的內容來直接看到該交易所需要產生的整套會計分錄的。
·TSYSSOVT(會計分錄Override表)會計分錄Override表是一個「會計科目－(記帳條件1，記帳條件2)」對應表。它使得會計分錄的記帳科目可以在交易執行時根據記帳條件的取值動態產生，而不是在會計分錄總表中固定設定。它的主要作用是可以合併會計分錄總表和記帳條件判定表中互相類似和僅僅科目不同的記錄，便於這些表的維護。
·TSYSSCND(記帳條件判定表)記帳條件判定表記錄了每個子系統中的每個交易或者KB在不同的記帳條件取值組合情況下，應當產生的會計分錄在會計分錄總表中的序號。該表用於在交易和KB執行時，根據當時的各個記帳條件取值，確定應當產生會計分錄。每一個子系統最多可定義16個記帳條件。具體的處理會在後面有關GCCBACND的描述中詳細說明。
·TSYSSAMT(金額對照表)這個表是把每一個子系統預先設定好最多30個不同的金額收集而成的。這些金額用於在系統產生交易的會計分錄表時確定每條分錄的記帳金額。
·TSYSSMP(清算種類表)這個表是記錄了整個系統中目前支持的清算種類，以及各個子系統的交易或KB在該清算種類條件下應當產生的清算分錄。在後面有關產生清算會計分錄的描述會有更詳細的說明。
·TSYSSIAT(內部帳號序號Override表)會計分錄Override表是一個「內部帳序號－(會計科目，記帳條件1，記帳條件2)」對應表。它使得會計分錄的內部帳序號可以在交易執行時根據會計科目和記帳條件的取值動態產生，而不是在會計分錄總表中固定設定。
另外，在產生會計分錄的過程中，交易、KB或各會計界面的程序都需要使用下面的系統工作區來完成記會計分錄的功能·CBAIFARE(應用接口區)這個區間是讓交易或KB把與應用有關的數據送返架構控制模塊，讓架構控制模塊能夠進行其後續的處理。在記帳過程中，交易或KB是需要把與帳務有關的數據如交易的參考號、交易種類(現金、轉帳、交換)、帳本別(帳別+幣種)、轉出與轉入帳號(與清算處理有關)等設在這區間裡，讓架構控制模塊進行適當的處理。
·CBAMTARE(金額設定表)交易或KB進行記帳的第一步是要產生記帳所需的金額表，CBAMTARE就是用來把每一個交易或KB在起動記帳登記伺服器前把該交易或KB所產生的記帳金額設定好。
·CBARAARE(會計分錄表)這是一個臨時的交易會計分錄表，在記帳登記伺服器產生交易分錄表前，記帳登記伺服器是會先把會計分錄總表中屬於該交易或KB的會計分錄拷至這個臨時表中，以便進行產生該交易或KB所需要產生的會計分錄。
·CBAOAARE(會計分錄Override表)所有在會計分錄總表中的會計分錄都是可以通過交易的override的。Override的內容就是通過這個表在啟動記帳登記伺服器前設定好的。
·CBAEAARE(交易會計分錄記帳表)這個表是用來在正式記帳前暫存每一個交易應當產生的分錄。會計伺服器主程序就是用這個表來進行記帳處理的。每個交易最多產生24筆的會計分錄。
C．連線記帳過程
CBS系統的會計設計是讓交易在日間連線時，通過會計伺服器記各個會計科目的餘額，並產生相關的交易流水，然後在日終批處理時通過搜流水的方式來產生各會計科目的明細帳。在日終批處理產生會計明細帳前，批處理的作業是可以通過CentreCut方式起動某些帳務性交易來進行批量帳務處理，如代收、代付、代扣、還貸或結息等。
C．1會計伺服器主要組成部分·架構控制模塊會計流程控制·記帳金額設定應用伺服器(GCCBAAMT)·記會計帳條件設定應用伺服器(GCCBACND)·會計帳登記伺服器(GCCBAAR)·會計伺服器主程序(GCCBMAP)-架構控制模塊會計流程控制整個會計界面的控制核心是在架構控制模塊中進行的。首先，當架構控制模塊在收到從端末送過來的一個交易時，架構控制模塊就為記會計帳作準備。第一個動作就是把記會計帳所需的區間或表(CBAAOAAARE、CBAEAARE等)進行初始化，然後架構控制模塊會起動相關的交易來進行處理。交易也可能通過起動有關的KB來進行業務的處理。在整個業務處理的過程中，如果需要產生會計分錄，交易或KB會通過一系列的會計伺服器來把交易或KB所產生的會計分錄登記下來。當交易的處理正常結束後，架構控制模塊是會把交易所產生的交易流水登錄在帳務性交易流水中，然後會起動會計伺服器GCCBMAP進行記帳處理。
-記帳金額設定應用伺服器(GCCBAAMT)記帳金額設定應用伺服器把交易或KB輸入的各個記帳金額填入CBAMTARE中，用於在產生分錄時計算每筆分錄的記帳金額。該應用伺服器有效地降低了因為編程人員鍵入的錯誤而錯記金額的可能性。其設計概念會在後面的描述中詳細介紹。
-記會計帳條件設定應用伺服器(GCCBACND)
記會計帳條件設定應用伺服器根據記帳條件判定表，根據交易和KB輸入的記帳條件的具體取值，確定對應的會計分錄條件號，該條件號對應於會計分錄總表中的一套會計分錄。
-會計帳登記伺服器(GCCBAAR)會計帳登記伺服器根據GCCBACND得到的會計分錄條件號、CBAOAARE、CBAMTARE和各種清算條件取值，產生該交易或KB會計分錄，並登記在CBAEAARE中。
-會計伺服器主程序(GCCBMAP)會計伺服器主程序是整個連線記帳的最後一個過程。交易在產生整套會計分錄後返回架構控制模塊。架構控制模塊把交易所產生的會計分錄寫入交易流水，然後起動會計伺服器主程序進行記帳。伺服器在記帳前檢查該套會計分錄的準確性和平衡性。如果發現問題，則產生錯誤信息，交易失敗返回。否則，更新各個相關科目的餘額。
圖16示出了連線記帳處理模式。
1)端末起動主機交易端末系統把用戶的交易請求通過SNA、VTAM傳送到主機。主機系統通過CICS起動架構控制模塊對交易請求進行處理。
2)啟動CICS交易當架構控制模塊起動後，架構控制模塊會對輸入的交易信息進行必須的檢查，並進行必須的預處理(如生成交易的流水號、把交易記錄下來、初始化有關的會計資料表以便交易記帳)，然後起動對應的CICS交易來為輸入信息進行處理。
3)調用KB如果交易是不通過KB來進行業務處理，則交易就須要負責產生所有的會計分錄。
-設定金額表(CBAMTARE)在交易或KB處理業務個過程中，如果需要產生必須的會計分錄，則交易或KB就必須遵守會計界面的要求。第一步就是產生會計金額表。金額表的主要目的是要交易或KB通過標準規範的COBOL名稱(如LN-TX-AMT，SA-AMT-INT)設定到預先定義好的參數表中。調用GCCBAAMT就是把這些設好的參數載入金額表CBAMTARE中。每一個子系統最多能夠定義30個不同的金額。這個金額表在後面的處理中是需要用到的。
-設定記帳條件當記帳用的金額表設定好以後，下一步的工作就是設定記帳條件。交易或KB通過調用記會計帳條件設定應用伺服器(GCCBACND)設定記帳條件。在調用應用伺服器之前，交易或KB需要先把判斷記帳條件的各個要素的取值，即記帳條件，設定好。GCCBACND就是利用這些參數在記帳條件判定表中尋找與之匹配的記錄。比對的關係可以是大於(＞)、大於等於(≥)、小於(＜)、小於等於(≤)、等於(=)、不等於(≠)或其他。
記帳條件是具有業務含義的某些數據項，例如存款種類、交易類別、貸款種類、存期等到。
-產生和登記會計分錄在設定好記帳的條件後，最後的工作就是產生和登記該交易或KB所需要產生的會計分錄。KB只產生與其自身業務相關的會計分錄；交易的會計分錄是其調用的所有KB和交易自己產生的會計分錄的總和。例如轉帳交易是通過分別調用活期支取KB和活期存入KB來實現轉帳交易的。那麼，轉帳的整套會計分錄就是這兩個KB分別產生。每一個KB都只產生一半的會計分錄，但在交易的角度而言，整套的會計分錄是完整的和平衡的。
在調用會計帳登記伺服器(GCCBAAR)前，交易或KB需要先設定好調用的參數如帳本別、幣別、交易參考號、交易種類、轉入/轉出帳號等。另外，如果交易或KB需要override會計分錄總表中的任何一個欄位時，交易或KB可以通過填寫CBAOAARE(Override表)來覆蓋會計分錄總表中某一個欄位的內容。交易甚至可以使用CBAOAARE增加新的會計分錄(即在會計分錄總表中沒有預先設定的會計分錄)。唯一的限制就是整個交易所產生的會計分錄不能超過24筆。
當所需的參數或表設定好以後，交易或KB就可以調用會計帳登記伺服器(GCCBAAR)。GCCBAAR先根據GCCBACND等到的記帳條件號把會計分錄總表中對應的那套會計分錄拷到臨時會計分錄表中，然後與CBAOAARE、CBAMTARE等表合併起來產生交易會計分錄記帳表(CBAEAARE)。這個記帳表是當交易結束回到架構控制模塊後用來記帳用的。GCCBAAR還會產生與清算有關的會計分錄，清算會計分錄是會包括在24筆內的。清算的處理模式請參考後面有關清算的描述。
4)KB返回到交易當KB在完成它的處理並登記了有關的會計分錄後，KB就會結束並返回到調用它的交易。
5)交易返回到架構控制模塊當交易結束後，交易就會返回到架構控制模塊，讓架構控制模塊進行交易後的處理(如記帳、Rollback、交易輸出等)。
6)產生交易流水如果交易是成功的話，則架構控制模塊便會更新有關的交易流水。
7)記會計帳如果交易是會產生會計分錄的話，架構控制模塊便會起動會計伺服器主程序來進行真正的記帳動作。記帳包括整套會計分錄的平衡檢查、記總帳、掛銷帳和記內部帳。
D．批處理記帳流程圖17示出了批處理記帳流程。
當日間的處理結束，系統便會進入晚上批處理時段。晚上的主要處理是記總帳明細檔。
在記總帳明細檔之前，每一個子系統都需要把當天在連線批處理時需要產生的會計分錄都登記在交易流水中。主要的連線批處理作業包括代收、代付、代扣、還貸、結息等。
當所有當天的會計分錄都產生以後，系統會從交易流水檔中產生大傳票檔。這個大傳票檔用來產生個總帳科目和內部帳的明細記錄的。產生明細記錄的流程可以參照下圖。
E．清算處理在一個銀行的運作過程中，與外界銀行或金融機構有著業務的往來是非常普遍的事情。每一筆與外界銀行的交易都需要經過嚴格的跟蹤，同時也需要與外界銀行產生相對的財務關係。這財務關係便是「清算」活動。
因為銀行業務的不同或對清算概念的差異，清算模式有很多的種類(複雜或簡單的)。在CCBS的設計裡，所有的清算都是以核算中心(分行)為主。支行與支行的清算是透過分行來進行；支行與外界銀行的清算也是透過分行來進行。換句話說，分行就變成清算的核心了。
清算的過程是分為兩個部分進行處理的。第一步是數據的收集，第二步是產生清算的軋差，從而達到清算的目的。
在CCBS裡，我們是通過記清算會計分錄的方式來收集清算的數據。每一筆涉及兩個不同機構的交易都需要產生對應的會計分錄來反映清算活動的發生，並為日中的清算處理產生數據。清算用的會計分錄是透過「聯行往來」這個科目來記錄的。
我們在主機系統中建成一個清算種類表TSYSSSMP，其中包括每種清算種類會產生的作為清算用途的整套會計分錄，作為產生跟清算有關的會計分錄之用。
首先，在交易或KB調用GCCBAAR之前，交易或KB是需要把交易所牽涉到清算活動的支行通過AIF-TR-IN-ACCOUNT或AIF-TR-OUT-ACCOUNT設好。在GCCBAAR的處理中，GCCBAAR會從上面的兩個帳號和交易行的行號進行比較。如果這三個行號是一樣的話，則該交易就沒有任何的清算活動。如果這三個行號不完全是一樣的話，則會發生不同形式的清算動作。GCCBAAR就會按判斷出來的清算種類產生對應的會計分錄。這個過程是完全自動而不需要交易或KB做什麼的處理的。GCCBAAR所產生與清算活動有關的會計分錄是會記在交易會計分錄表中。當交易結束返回到架構控制模塊後，真正的會計分錄就會正式產生。
在晚上批處理時，日間記帳過程中所收集到有關清算活動的數據是會被用來產生各式各樣的清算報表的。這些清算報表是會與外界金融機構結算時作為參考比對的。
1．9衝正處理(EC Process)「衝正處理」指當日衝正處理。所謂衝正處理，是指由於櫃員誤操作或其它原因錯誤地執行了某筆交易，事後用執行一筆反向交易的方式取消原交易的錯誤效果的過程。
A．衝正的主要工作衝正須要完成如下工作·取消被衝正交易對應用資料庫產生的錯誤效果·取消被衝正交易產生的會計分錄對會計帳的錯誤更新·產生適當的憑證·其它與具體業務有關的處理B．衝正處理B．1架構控制模塊和交易/KB衝正處理由架構控制模塊和交易/KB諧調完成。架構控制模塊根據被衝正交易的交易流水為衝正交易恢復有關被衝正交易的信息，如交易請求、KB請求、TGS區和會計分錄的內容等，同時架構控制模塊在衝正交易處理成功後為其進行與被衝正交易反向的會計處理。交易/KB根據架構控制模塊提供的有關被衝正交易的信息恢復應用資料庫和完成其它與具體業務相關的處理。
正常交易和衝正交易使用的同一個交易或KB程序。交易和KB中應包括正常和衝正兩者處理邏輯。
B．2相關系統工作區·CBECIARE(衝正輸入信息)記錄衝正交易的部分輸入信息，如授權主管號、帳號、金額1、金額2、交易流水號等，也包括部分被衝正交易的交易流水記錄中的信息，例如交易營業日、系統日期和系統時間等。架構控制模塊根據衝正交易輸入信息填寫CBEICARE，供後續衝正處理使用。
·交易請求交易請求由交易填寫，交易結束時由架構控制模塊記入交易流水。衝正時，衝正交易可以通過架構控制模塊得到被衝正交易的交易請求的內容，用於恢復應用資料庫和其它處理。交易請求的作用類似與KB請求。
圖18示出了衝正處理流程。
1)端末使用統一的衝正交易代號CM0999800向架構控制模塊提交衝正交易請求，同時上傳被衝正交易的交易流水號、帳號、金額1和金額2等數據。帳號、金額1和金額2由櫃員輸入，用於和被衝正交易記錄在交易流水中的對應數據進行對比。只有當兩者相同是衝正才被允許進行。這種檢查可以減小由於誤輸交易流水號而將其它交易衝正的可能性。
2)架構控制模塊根據端末傳入的交易流水號，取得被衝正交易的交易流水，根據其內容填寫CBECIARE，恢復輸入消息交易輸入信息、CBAEAARE會計分錄、交易請求、CBTGSARE和KB請求等至被衝正交易結束時的內容。然後，檢查輸入的帳號、金額1和金額2是否和被衝正交易的交易流水中的對應欄位內容是否相同。最後，用輸入消息中的內容，即被衝正交易的輸入信息，啟動交易。
3)交易根據輸入信息和交易請求中的內容進行衝正處理。必要時調用KB對正常交易中的KB調用進行衝正。KB的輸入參數由交易的衝正處理邏輯產生，而不是像交易的輸入信息根據交易流水恢復至與被衝正交易完全相同，所有存在KB在衝正時輸入參數與在被衝正交易時不同的可能性。
4)當交易通過GSYSTRIG連動KB時，GSYSTRIG根據被衝正交易記錄的CBTGSARE中的信息找到被連動KB在被衝正交易中記錄的KB請求。然後，連動KB，並將KB請求傳遞給被連動KB。
5)交易和KB的衝正處理結束後返回架構控制模塊，架構控制模塊根據CBAEAARE中的內容，即被衝正交易產生的會計分錄，進行帳務處理。衝正交易的會計分錄的區別僅是記帳金額為原記帳金額的負值。
6)架構控制模塊將衝正交易的輸出表等回送端末。
1．10 24小時運行模式(24 Hours Mode)針對24小時不停業務運轉交易所設計的處理原則，其業務範圍包含ATM/POS，Voice/-Firm Banking，Home Banking等。
時段切割
時段切割主要目的在於JOB設計時各應用系統依其情況將其作業放入適當的時段。同時在24小時運作模式下執行次日帳切點。時段切點將記錄於系統的CMICTDAT控制檔中所有的交易知目前在何段中，而各時段的時間為邏輯切點，不因實際時間而影響，營業記帳日期。
圖19示出了次日帳切點情況。
1)24小時交易換日切點置於最早的網點結帳前。
2)採全分行統一切換。
3)切換之後所有交易所發生的帳務以次日帳處理。
4)未切換之前網點不能關帳。
圖20示出了ATM軋帳情況。
1)會計帳務以換日切點24小時為循環記錄帳務日的每一筆交易。
2)換鈔現金以換鈔切點(每一部機器不同)24小時循環記錄每一筆現金交易。
圖21示出了ATM作業模式與整批時段(Time Slot)圖22示出了交易控制流程。
1)在下午支行網點結帳前由中心執行Cut off(切換)次日。
2)架構控制模塊接到24hrsTx消息(TXP定義)，將ATM模態傳給24hrsTx。
3)該交易判斷連線或離線後更新主1DB or Temp DB。
4)在TN時啟動Catch up(追帳)程序，讀取TEMPFILE的消息傳入架構控制模塊的24hrsTx。
5)連續批處理作業可根據CMICT24C的設定的執行該區段，由此設定可啟動多個Center Cut同時執行追帳，縮短追帳時間。
1．11 KB連動處理圖23示出了KB連動處理流程正常交易1)端末向架構控制模塊提出交易請求2)架構控制模塊為CBKBRARE、CBTGSARE和其它系統工作區分配空間，然後根據端末提供的交易代碼調用被請求的交易3)交易調用GSYSTRIG連動KB4)GSYSTRIG檢查連動的KB的個數是否已經為6個。如果是，則交易失敗，輸出出錯信息；否則，取得CBKBRARE中下一個KB請求，並將APA-KBA-ADDR設為該KB請求的地址。然後，在CBTGSARE中記錄被連動KB的名稱和連動該KB的程序名稱，並將已連動KB個數加1。最後，調用KB。在某些子系統內部，KB之間可能需要使用TFT區傳遞連動信息，當這些子系統的KB被其它子系統連動時，GSYSTRIG將為其分配其原來所屬子系統的TFT區。
5)KB通過APA-KBA-ADDR取得KB請求，並將需要記錄在交易流水中的信息寫入正常KB請求中。KB處理完成後返回GSYSTRIG。
6)GSYSTRIG返回交易。如果4)中曾經分配TFT區，則先釋放該區域，然後返回。
7)交易處理結束後返回架構控制模塊。由架構控制模塊將正常KB請求和CBTGSARE中的內容寫入交易流水。架構控制模塊退出時，釋放CBKBRARE、CBTGSARE和其它系統工作區。
8)架構控制模塊將交易輸出表格或出錯信息回送到端末。
衝正交易1)端末向架構控制模塊提出交易請求2)架構控制模塊為CBKBRARE、CBTGSARE和其它系統工作區分配空間。然後架構控制模塊取得原正常交易記錄的交易流水，並根據交易流水的內容，恢復CBKBRARE和CBTGSARE至正常交易結束時的狀態。最後根據端末提供的交易代碼調用被請求的交易3)交易執行其衝正邏輯，並調用GSYSTRIG連動KB，對KB在原正常交易中進行的業務處理進行衝正。
4) GSYSTRIG根據CBTGSARE中的內容，以及目前被連動KB的名稱和連動該KB的程序名稱，找到該KB在正常交易中使用的KB請求，並且置CBTGSARE中對應該KB的記錄中的是否衝正標誌。GSYSTRIG將APA-KBA-ADDR設為該KB請求的地址。然後，調用KB。在某些子系統內部，KB之間可能需要使用TFT區傳遞連動信息，當這些子系統的KB被其它子系統連動時，GSYSTRIG將為其分配其原來所屬子系統的TFT區。
5)KB執行其衝正處理邏輯。在執行過程中，通過APA-KBA-ADDR取得KB請求。正常KB請求中的內容為KB在正常交易中記錄的內容。KB可以利用其中的信息進行衝正。同時，KB也可以將需要記錄在交易流水中的信息寫入反向KB請求中。KB處理完成後返回GSYSTRIG。
6)GSYSTRIG返回交易。如果4)中曾經分配TFT區，則先釋放該區域，然後返回。
7)交易處理結束後返回架構控制模塊。由架構控制模塊將反向KB請求和CBTGSARE中的內容寫入交易流水。架構控制模塊退出時，釋放CBKBRARE、CBTGSARE和其它系統工作區。
8)架構控制模塊將交易輸出表或出錯信息回送到端末。
2業務規則(Knowledge Block)和共用函數(Common Function)以下描述業務規則和共用函數的概念。
A．業務規則的定義業務規則(KB)是能夠獨立地完成某種完整的業務操作的最小單位。KB是構成應用子系統的基本單元。通常，KB具有如下特性·獨立完成完整的基本業務動作·KB的業務處理通常是帳務性的·更新應用業務資料庫·包含衝正處理邏輯·需要記錄交易流水·輸出表上述各項中，第一條是最重要的也是最基本的，也是KB區別於CF的最主要特徵。
根據CBS系統的設計觀念，所有的業務，即交易和交易的功能，是由某些基本的業務規則，或業務「知識」(Knowledge)構成。各種業務就是這些「知識」的不同組合。而這些基本的業務規則就是由KB實現的。一方面，交易可以用KB進行簡單的組合而構成，KB確定了其業務規則；另一方面，交易可以通過覆蓋(Override)KB輸出的表、增加與其業務相關的新的處理邏輯等方法調整交易的功能，適應具體的業務需求。
基本業務規則必須在連線環境中運行。
B．共用函數的定義共用函數，即共用函數，是一組實現可能被經常重複使用的功能的程序，這些功能主要包括各種計算、數據查詢/維護、數據檢查等。共用函數的設計可以簡化應用開發和提高應用的可維護性。
共用函數，與基本業務規則相比，有如下特點·CF實現的功能不能獨立成為完整的業務處理·不能進行帳務性處理·不能記交易流水·不能衝正·不輸出表，只通過輸入/輸出參數傳遞數據·CF如果不操作資料庫，則也可以在批處理環境中使用·CF中的應用邏輯錯誤不直接導致交易失敗。具體的錯誤處理由調用該CF的程序決定C.KB的連動處理KB是通過被交易或其他KB連動而運行的。交易和KB都必須通過GSYSTRIG連動KB。
KB請求是一組內存區域。KB在執行過程中可以將需要記錄交易流水的信息存放在KB請求中，交易成功後架構控制模塊負責將KB請求中的內容記入該交易的流水中。在交易衝正時，KB可以通過架構控制模塊得到原來的KB請求內容，用於衝正處理。所以KB請求的主要作用包括·為KB提供記錄交易流水的手段。交易流水中的內容將會在批處理作業中時被使用。
·記錄KB在正常執行中的某些與當時特定狀態相關的中間結果，為可能的衝正處理保留足夠的信息。
一個交易在執行過程中最多可以連動6個KB，其中包括KB連動KB。每個KB請求為256Byte。
重要的系統工作區·CBKBRARE(KB請求區)
包括全部6個正常KB請求、6個反向KB請求和KB索引。KB索引為當前KB使用的KB請求在CBKBRARE中的序號。在正常交易中，正常KB請求的內容將被記入交易流水；在衝正交易中，正常KB請求中為KB在正常交易中寫入KB請求的內容，反向KB請求中的內容將在衝正成功後寫入交易流水。
·CBTGSARE(Trigger Sequence Area)在正常交易中，GSYSTRIG在CBTGSARE中記錄每個被連動KB的名稱、連動該KB的程序的名稱、以及目前已經連動的KB的個數。CBTGSARE在交易成功後，由架構控制模塊寫入交易流水；在衝正交易中，CBTGSARE中返回GSYSTRIG在正常執行中記錄的內容，即正常交易連動的KB個數、KB名稱和連動KB的程序名稱等，以及在衝正過程中當前該KB是否已經被衝正。GSYSTRIG根據CBTGSARE中的內容在CBKBRARE中找到KB在正常交易中使用的KB請求，並將其傳遞給該KB。
·APA-KBA-ADDRCBAPALST中的一個欄位，指向當前KB使用的KB請求的指針，用於向KB傳遞KB請求。
3應用系統(Application System)在CBS系統中，銀行應用業務主要通過各子系統的連線交易和批處理作業實現。
4生成器(Generator)生成器是CBS系統提供的一組工具程序，用於自動生成部分原始碼、系統表和報表等。目前，生成器主要用於開發、維護和批處理報表。生成器的設計顯著地減少了應用開發的工作量，提高了應用質量。
生成器工作原理A．以數據字典為輸入源的生成器大多數生成器，包括所有的數據格式生成器和部分架構表生成器，都以數據字典為輸入源。這樣的設計保證了產生器產生的Copybook和架構表與前期設計和系統其它部分的一致性。
B．會計處理表生成器所有會計處理表生成器均以會計表格資料庫為輸入源。會計表格資料庫中的數據由用戶使用會計表格維護交易輸入和維護。如圖26B所示。
C．資料庫訪問引擎和COPYBOOK生成器對於RDBMS，所有的Table Copybooks、Host StructureCopybooks和訪問引擎程序均由生成器自動產生。
Table Copybooks和Host Structure Copybooks通常由數據字典(DDD)生成，保證與設計的一致性，但是生成器也允許從IMS SegmentCopybooks直接生成RDBMS Copybook，作為一種快速和應急途徑。
生成控制表控制訪問引擎生成結果，允許根據每個資料庫或Table的特性生成具有不同功能的訪問引擎D．文件訪問引擎生成器文件屬性定義文件中定義了每個文件的特殊屬性，包括文件名稱、文件類型、允許訪問方式、記錄最小長度、最大長度、記錄是否變長、數字欄位存放方式等等。
文件引擎生成器(FAI Generator)根據每個文件的屬性定義內容生成其各自的訪問引擎。
E．報表生成器批報表在系統開發中佔有一定程度的工作量，它的特點是數量多，但一般來說般來說功能上並不複雜。從過程上來看，要生成一個批報表可分為讀取資料庫、排序、產生報表三個階段。傳統做法一法一般是以個別的批處理功能(或含JCL)產生個別報表。其中除讀取資料庫及排序因功能需求各異，仍需個別處理外，最後的產生報表可用一標準化過程處理，可省卻大量在批基於上述考慮，故將批報表的流程程固定為a)讀取資料庫產生生報表數據檔b)報表數據檔排序
c)REPORT GT GENERATOR生成報表R生成報表其中REPORTGENERATOR的來源依據除報表數據檔外，尚需一個參數。
5程序模板(Skeleton)CBS系統為主要的應用程式種類，如KB、CF、各種交易程序、各種批處理程序、使用各種批處理工具的JCL程序、連線批處理JCL等等，提供程序模板(Skeleton)。程序模板(Skeleton)中包含該類程序的共同處理，並定義了程序結構。
開發人員在編寫應用程式時僅需要在對應的模板(Skeleton)內填入具體的功能邏輯即可。
程序模板(Skeleton)的使用使得開發出的應用程式規範化，提高了系統質量。同時，因為模板已經包括了所有的共同處理或規定了共同處理的格式，如初始化和錯誤處理等，開發人員只需要了解和實現具體的功能邏輯，從而減少了對開發人員在不必要技術領域的要求，顯著地提高了開發效率。
CBS系統為主要的應用程式種類，如KB、CF、各種交易程序、各種批處理程序、使用各種批處理工具的JCL程序、連線批處理JCL等等，提供程序模板(Skeleton)。程序模板(Skeleton)中包含該類程序的共同處理，並定義了程序結構。
程序模板的內容主要包括◆程序段落結構◆共同的處理和數據說明，如內存區初始化和Linkage Section的數據定義◆錯誤處理方式◆常用處理的示例開發人員在編寫應用程式時僅需要在對應的模板(Skeleton)內填入具體的功能邏輯即可。不需要了解業務平臺(Business Platform)內部處理方式和其他與硬體/軟體平臺相關的內容，只需要了解和實現具體的業務功能即可。
程序模板的使用使得開發出的應用程式規範化，提高了系統質量，減少了對開發人員在不必要的技術領域方面的要求，顯著地提高了開發效率。
以上結合具體實施例從業務平臺、基本業務規則和共用函數以及應用子系統三個方面詳細地描述了本發明。本領域技術人員應清楚，在不背離本發明的精神和實質的前提下，本發明具有許多實施方式，以上實施例只為了說明本發明，不應構成對本發明的限制、本發明的保護範圍由所附權利要求書來限定。
權利要求
1．一種集成的銀行核心業務系統，其特徵在於包括用於提供應用業務開發環境的業務平臺，在該業務平臺中集成了對於各種銀行核心業務來說是共同的處理部分，並為各種銀行核心業務共享數據建立核心業務共享數據資料庫，以便對客戶情況、業務情況進行分析，為系統提供綜合的客戶、業務情況；基本業務規則庫和共同函數庫，基本業務是能夠獨立地完成某種完整的業務操作的最小單位，而共同函數是實現基本業務中可能被經常重複使用的功能的程序；和應用業務子系統，通過對基本業務規則進行組合構成各種具體的應用業務。
2．根據權利要求1的銀行核心業務系統，其特徵在於所述銀行核心業務包括活期存款、定期存款、貸款、結算、信用卡/儲蓄卡、會計、電子匯劃、清算、帳簿等業務中的至少一項業務。
3．根據權利要求1的銀行核心業務系統，其特徵在於所述業務平臺包括連線交易主控模塊、資料庫界面模塊、連線批處理主控模塊、連線報表模塊、外部接口模塊以及模擬測試模塊中的至少一個模塊。
4．根據權利要求1的銀行核心業務系統，其特徵在於所述業務平臺包括會計處理、衝正處理、24小時運行模式中的至少一個處理。
5．根據權利要求4的銀行核心業務系統，其特徵在於所述會計處理是採用「會計伺服器」的方式來進行會計記帳的，讓各個交易或基本業務在進行記帳時，通過固定的界面來處理其會計分錄產生和記帳。
6．根據權利要求1的銀行核心業務系統，其特徵在於所述銀行核心業務系統基於所述基本業務規則實現業務的統一連動和全面自動轉帳。
7．根據權利要求1的銀行核心業務系統，其特徵在於還包括用於建立系統所使用的數據格式及內存表格的生成器。
8．根據權利要求7的銀行核心業務系統，其特徵在於所述生成器包括以數據字典為輸入源的生成器、會計處理表生成器、資料庫訪問引擎和Copybook生成器、文件訪問引擎生成器以及報表生成器中的至少一個生成器。
9．根據權利要求1的銀行核心業務系統，其特徵在於還包括程序模板。
10．一種集成銀行核心業務的方法，其特徵在於包括以下步驟對應用業務進行分析，建立用於提供應用業務開發環境的業務平臺，在該業務平臺中集成了對於各種銀行核心業務來說是共同的處理部分，並為各種銀行核心業務共享數據建立核心業務共享數據資料庫，以便對客戶情況，業務情況進行分析，為系統提供綜合的客戶、業務情況；對應用業務進行分析，得出基本業務規則，建立基本業務規則庫並將共同處理功能設計成共同函數庫，其中基本業務是能夠獨立地完成某種完整的業務操作的最小單位，而共同函數是實現基本業務中可能被經常重複使用的功能的程序；和通過對基本業務規則進行組合構成各種具體的應用業務。
全文摘要
本發明公開了一種用於集成銀行核心業務的系統,包括用於提供應用業務開發環境的業務平臺;基本業務規則庫和共同函數庫,基本業務是能夠獨立地完成某種完整的業務操作的最小單位,而共同函數是實現基本業務中可能被經常重複使用的功能的程序;和應用業務子系統,通過對基本業務規則進行組合構成各種具體的應用業務。該系統可以實現業務的統一連動和全面自動轉帳。
文檔編號G06Q20/00GK1284683SQ9911178
公開日2001年2月21日 申請日期1999年8月11日 優先權日1999年8月11日
發明者胡憲忠 申請人:國際商業機器中國有限公司