DE10038289A1 - Core banking activities integration system, involves preparing application-development environment business platforms for integration into the various processes usually required in separate core banking systems - Google Patents

Abstract

The difficulty associated with providing common data utilization between computer systems, with the result of it not being possible to supply composite information on the customers and business position of a bank for analysis has led to integrated core banking systems covering the main basic products and services in banking, such as saving, credit card, debit card, accounting, electronic credit transfers etc. and the use of business platforms for preparing an application-development environment are integrated into the various processes usually required in separate core banking systems. Data banks, used in common, are created so as to supply the system with the composite information about customers or business and in which data on customers or business are analyzed.

Description

This invention relates to a processing system of banking transactions and in particular on one Process and system for integrating Core banking system (CBS).

With the rapid development of the financial industry, banks are in able to offer more and more products and services. Examples include bank card, automatic saving, automatic deposit, automatic transfer, electronic Wire transfer, corporate banking, home banking, Telephone banking and satellite bank etc. called. All of these are based on the development of information technology. So far, computer systems that use these products and Support services, in most cases developed independently. A common Data usage between these systems is mutually difficult. That means no compound Information about the customers and the business situation of a bank can be delivered.

To solve these problems mentioned above, the present invention an integrated system and method for basic banking activities, which the main basic products and services in Banking, such as saving, time deposit account, loan, Brokerage, billing, credit / debit card, Booking, electronic transfer, billing, book, Customer information, etc. A payment system, a Currency system and an investment system will be in the near future  implemented. This core covered by this invention Modules that are independent of specific business products or services are also flexible and deliver strong platform for the development of new application systems for the support of banking products and next generation services.

With the above-mentioned and other tasks, the Invention a system for integrating basic banking activities, which includes: a business platform, the one Development environment for the application business delivers, in of the different processes that the individual Basic banking activities are common, integrated, and Shared databases for basic banking activities for Data shared by individual base banking activities be used to create the system with the composite information from customers or business supply by analyzing the data from customers or business become; a rule library for basic business and one Shared function library, the Basic business represents the smallest unit that is used for Is able to implement a certain business process, and the common function of the implementation program the function that is used repeatedly by the underlying transaction, represents; and an application business subsystem for Establishment of various specific shops Combination of the rules of the basic business.

In addition, the invention provides a method for Integration of basic banking activities available, which includes the following steps: Analysis of the Application business to create a business platform for Providing a development environment for the To create application business in which different processes, which are common to the individual basic banking activities,  be integrated and shared databases for Basic banking activities for data provided by the individual Basic banking activities are shared to the system with the composite information from customers or business to supply by the data of Analyzing customers or business; Analysis of the Application business to create a rule library for that Basic business and a library for the common function to create in which the basic transaction is the smallest unit represents the implementation of a particular Business process is capable, and the common function that Program to implement the function that is used repeatedly by the underlying transaction; and the establishment various specific businesses by combining the Rules for basic business.

The invention will be better understood from the following detailed description and by accompanying Drawings of embodiments of the invention.

To the drawings

Fig. 1 is a diagram illustrating all parts of the system for integrating basic banking activities according to an embodiment of this invention;

Fig. 2 is a diagram illustrating the architecture of the online control module group;

Fig. 3 is a diagram illustrating the relationship between the online control module group and others;

Fig. 4 is a diagram showing the functions called by CCBMain;

Fig. 5 is a diagram illustrating the workflow of the message formatter;

Figure 6 is a diagram illustrating the workflow of the application server;

Fig. 7 is a diagram illustrating the interface module for database access;

Figure 8 is a diagram illustrating the overall transaction processing model;

Fig. 9 is a diagram illustrating the file access interface module;

Fig. 10 is a diagram illustrating the CenterCut process model;

Figure 11 is a diagram illustrating the workflow for online reports;

Figure 12 is a diagram illustrating the workflow of the schedule report;

Fig. 13 is a diagram showing the module for the external interface;

Fig. 14 is a diagram illustrating the workflow of the test driver;

Fig. 15 is a diagram illustrating the workflow in the KB / CF unit test;

Fig. 16 is a diagram showing the model of the booking process;

Fig. 17 is a diagram illustrating the process model for the general ledger;

Figure 18 is a diagram illustrating the error correction workflow;

Fig. 19 is a diagram showing business day closing;

Fig. 20 is a diagram showing the situation of ATM account checking;

Fig. 21 is a diagram showing the ATM job mode and the time interval;

Figure 22 is a diagram illustrating the model for the 24 hour transaction;

Fig. 23 is a diagram showing the flow of the KB triggering process.

As can be seen in Fig. 1, the integrated system for basic banking activities is based on the database description generated by the data model and process model of the business requirement, and the data layout and storage tables are generated by the generator. The business platform is now being developed to support the complex application transaction and to improve development and maintenance efficiency. In the application transaction, the rules of the underlying transaction are obtained after analysis, and the knowledge block (KB) and the library for the common function (CF) are generated.

The integrated system according to the invention is described below for Basic banking activities that the business platform, KB / CF and covers the application subsystem, presented in detail.

1. Business platform

To provide an integrated system for basic banking activities implement common system processing and Basic business management integrated into the business platform. Critical business data such as customer information become central saved and managed. In this way, they can different business applications can be shared. The main modules in the business platform close the Online control module group, database interface module (database interface module, DBIMain), file interface module (file interface module, FAIMain), CenterCut control module, Online report, external interface and test driver. The critical process flows include the booking process that Processing the error correction (EC), the 24-hour mode and processing when KB is triggered.

1.1 Online control module group

The online control module group as the main control module group for online transaction processing in the CBS is at the same time the core of the entire system. Fig. 2 shows the architecture of the online control module group.

In the CBS, all functions are different from the specific Platform, such as host, operating system, middleware, Communication protocol and DBMS, depend, in the system service Call and DBIMain integrated by unified and platform-independent interfaces services for other modules provide. This is the type of design that the CBS platform does independent and adaptable.  

Most other modules in the CBS, especially CCBMain, Application servers, KB / CFs and application transactions are in written in pure ANSI 86+ COBOL. This is what most do CBS programs are fully transferable between different platforms.

Figure 3 illustrates the relationship between the online control module group and others, and Figure 4 illustrates the functions invoked by CCBMain.

1.1.1. Message formatter Transaction definition table (TDT table)

Each application subsystem has a TDT table, each Entry field of all transactions related to this subsystem defined, such as its under all input fields Sequence number, data type, length, how it is converted and converted to TFT area is shifted etc.

Transaction field table (TFT area)

Each application subsystem contains a TFT area that consists of all input fields of all transactions that belong to belong to this subsystem. The transaction receives yours Input data from the TFT area of the current subsystem.

Message formatter workflow

Fig. 5 illustrates the workflow of the message formatter:

• 1. Get suitable TDT table
• 2. Find the record that contains the current transaction corresponds to the TDT table
• 3. Validate input fields according to the TDT table
• 4. Convert the input fields and copy them from Input message area to the TFT area

1.1.2. Application server

Application servers implement the management functions of the basic business, such as account processing, generating customer information, management of important documents, etc. Fig. 6 illustrates the workflow of the application server.

1.2. Database interface module (DBIMain)

This module makes the database access service available to others Modules are available via a standardized interface. The design of the DBIMain makes it for programs in others Modules unnecessary to use commands from any depend on special database product. During a change to another database management product, none of the Application programs are changed. DBIMain makes CBS DBMS independently.

This type of design also makes it possible to have several different database management systems in one To use the application system. Different databases can according to the application requirements in different Database management systems are saved to special To meet business and performance requirements.

Fig. 7 illustrates the access modules of the database interface:

• 1. PDBIMAIN, DBIMain interface
• 2. GDBIMAIN, DBIMain control program
• 3. GDBII4IMS, IMS database service control program
• 4. GDBI4RDB, RDB service control program
• 5. Access machine, database access machine

Fig. 8 shows the entire transaction processing model.

As can be seen in Fig. 8, the GDBIMAIN workflow consists of

• 1. the initialization of all variables and the acquisition of required working areas of the system
• 2. the input check, like standard check one Field, secondary index review, review of DB Name / segment name / field name etc.
• 3. Setting default values for optional parameters
• 4. The formatting of the database access request
• 5. the call of the access machine to access the Database
• 6. the preparation of the output result
• 7. error handling

Important tables and working areas of the system

• 1. TDBISIDX, secondary index search table, which is the existence checks the secondary index, and query the corresponding one Database name and the database sequence.
• 2. TDBISSEG, segment search table, for checking Database names, segment names and field names, and query of the Root segment name and keyword.
• 3. CBAPHARE, access path area to the current Record database access path. The current access path is supported by the previous database operations within the current transactions determined. GDBI4RDB decides according to the CBAPHARE area and the PDBIMain Parameters to actually perform database operation.

In addition, a special program that Table access machine, access to each table. The Access machine is through a special generator automatically generated. By modifying the parameters of the Generator or by expanding its function Access machines with different functions generated become.

GDBI4RDB is also expandable. According to the  hierarchical architecture of GDBIMain and the design of the Access machine, new DB access functions, such as Linking, sum and complex request, in a simple way to be added.

1.3. Interface module for file access (FAIMain)

This module provides through the unified interface PFAIMAIN the file access service, especially batch job Programs available for other modules. The design of the File application module makes the application program regardless of the specific type of file system.

Figure 9 illustrates the file access model. In the CBS, a special program, the file access engine, implements access to every file. The file access machine is generated automatically by a special generator. Without having to modify the application program, access machines with various functions can be generated by modifying the parameters of the generator or by expanding the function of the generator.

1.4. CenterCut control module

CenterCut processes batch jobs, such as automatic ones Batch transfer using online transactions.

Fig. 10 illustrates the CenterCut process model.

• 1. Centercut processing can be called by JCL, CICS transaction TCCC or online transaction through GCCBAJB- Application server.
• 2. The CenterCut control module calls the appropriate module Processing of the CenterCut command.
• 3. The CenterCut control module reads the CenterCut input file Record by record and send a request to CCBMain, to find the appropriate online transaction to process a call each record.  
• 4. CCBMain carries out the online transaction carried out by the CenterCut job was requested.
• 5. When the online transaction is completed, the suitable fields in the CenterCut control profile according to the Processing result updated.
• 6. CCBMain indicates the result of the transaction processing the CenterCut control module. Then write that CenterCut control module an output record in the Output file and updates the processing status in the Input file and the appropriate fields in the CenterCut Tax profile.
• 7. After all records are processed in the input file the centercut job has been completed. If he's from TCCC was called, the CenterCut control program, though necessary to inform the CICS console whether the processing was successful or not.

The CenterCut commands are passed to the CenterCut control program when a CenterCut job is called. Different functions are performed on different commands.

• 1. Start - normal start
• 2. Restart - a specific record in the input file can be specified as a restart point
• 3. Pause - when a specified number of records in the input file was processed, the CenterCut job for stop for a period of time and then the Resume processing
• 4. Recovery - input file, output file and Restore control profile after a crash to the Prepare to restart
• 5. Change - the pause parameters in the CenterCut control profile to adjust
• 6. Display - the current content of the CenterCut Show tax profile  
• 7. Stop - stop the current CenterCut job processing

Restart

The restart is the procedure of the Resume a job after the CenterCut job is through the operator or crash has ended.

The record in the input file from which the job is new can be started by a parameter of the restart command be specified. If this parameter is omitted, the job starts from where it ended the last time has been.

Restoration

Under some exceptional conditions, for example the connection between the Centercut control module and the Online control module collapses after the online Control module has successfully executed the transaction the CenterCut control module when writing the Output data record, when updating the processing mark in the input file or when updating some fields in the CenterCut Tax profile fail. In this case, if the job restarted immediately, some output records lost go, and the status of some input records may be incorrect his. And jobs that follow the current job can thereby failing.

If this happens, the recovery process can the output record, the processing mark of the Input data set and specific fields in the control profile, according to the last processed record number and the Transaction log number, in the CenterCut control profile recorded, restore. If a job ends early, the recovery must be done before restart become. The processing status and the cause of the Interruption can be found in the processing status field of the CenterCut-  Tax profile can be found.

Restore process flow

• 1. Get the last transaction log number processed data record from the CenterCut control profile.
• 2. Get transaction output message from the Document reprint database (BCMVOHD) according to the Transaction log number. Whether the output message an online transaction in the document reprint database is written by a specific marker in the transaction profile database (BCMTXPD). For a CenterCut job to be restored this marking of the corresponding online Transaction set before the start of the CenterCut job become.
• 3. Check if the output record of the last processed record is written to the output file has been. If not, generate the output data set from the Output message in BCMVOHD and write it in the Output file.
• 4. Make the necessary fields of the input data record and of the control profile.

Error correction (EC) for CenterCut

A CenterCut job is corrected by Execution of another CenterCut job. The EC CenterCut job follows the same process flow as other Centercut jobs. He asks CCBMain to execute EC transactions for Error correction of the transactions of the normal CenterCut job, to be corrected. Every record in the The input file of the EC CenterCut job corresponds to one Input data record of the normal CenterCut job that was created at the last Times was successfully processed. The CenterCut module GCCBCEC generates the input file of the EC CenterCut job accordingly  the output file of the normal job.

1.5. Online reporting module

This module provides the print job from the terminal was sent to the reporting queue in the Host. After the report is generated by the report generator he notifies the terminal of the report to download and control expression.

There are two types of queues: the online Report queue and the job report queue.

Some principles of online report processing

• - Report number (6 bytes) is within one business day unique and is created automatically
• - Online or on schedule
• - First-in-first-out
• - The host only generates raw data. The report format, like Report header, footer, page layout, Summary and field editing are done by the terminal processed
• - The host maintains report execution status. The possible Condition includes: queued, in progress, done to download, download and ready to go To press.
• - The host sets the status on incorrect request, if he finds a request error
• - The terminal is responsible for functions that the Print the report, such as status query, Report content query, print, reprint, Print number control, deletion, security control, Statistics etc.

Figure 11 illustrates the workflow of online reporting, and Figure 12 illustrates the flow of reports.

Exceptional handling

If the terminal finds the status of the report generation ready for download but does not receive the data, the terminal immediately starts the download transaction of the online report in order to download the report data.

• - the online report request solves the download request (Request format)
• - the online report request triggers the download response (Response format)

1.6. External interface module

Fig. 13 illustrates the architecture of the module for the external interface

Some principles

• - The interface of 1 / LINK, CAST, SPOT, OTHER is from External interface module controlled.
• - The transaction calls specific application servers to to control the external interface.
• - This type of design is usually not necessary to modify existing external systems.

Operation of the external interface 1) CCBMain to the external interface

The application calls various application servers to run the control external interface.

2) External interface to CCBMain

The external interface starts CCBMain via CICS-LINK. The The format of the input / output parameters (I / O parameters) must be the Follow standard I / O formatting of the online transaction.  

1.7. Test driver

The test driver is used for program unit testing. The basic work idea is that a unit that JCL tests, calls the test driver and the test driver one Request to CCBMain that sends the online environment simulated to run the program under test. The Input parameters of the program to be tested are within the unit test case file.

Fig. 14 illustrates the test driver's workflow.

• 1. Prepare the input message of the program that is being tested should be in the test case file according to the Format of the standard input message.
• 2. Prepare JCL of the test cases according to the JCL template in front. JCL contains the parameters (link parm) for the Test driver program GCCBUTDV, such as the organization ID, Cashier ID, Terminal ID and Business ID, CICS System ID and CICS program ID.
• 3. Run GCCBUTDV. GCCBUTDV gets the parameters Link Parm, the input message from JCL and the test case file. If link parm is not NULL, its value becomes the corresponding one Overlay field of input messages.
• 4. GCCBUTDV starts CCBMain using CICS-LINK and transfers the input messages to CCBMain. The format the input message is identical to that for the Execution of transactions from the terminal.
• 5. CCBMain releases the application program of the transaction according to the transaction code in the input message. After the processes have been completed, the transaction program returns CCBMain back.
• 6. CCBMain transfers the processing results to GCCBUTDV according to the standard output message format.
• 7. Formatted after receiving processing results GCCBUTDV the data received and passes it to the  Standard output device, usually a Test result file is out. In the test results file are not only contain the transaction output messages, but also the input messages, the two formats, CHARACTER and HEX.

Testing KB / CF

Fig. 15 illustrates the workflow of the KB / CF test.

Procedure for testing KB / CF

• - Set the value of each test case parameter in the Test case file. The "@" character should be any value go ahead. This way, GCCBUTDV will all values in concatenate a single input field and it into CCBMain transfer.
• - CCBMain stores the field containing the KB / CF parameters contains, in the corresponding field of the TFT area and starts the test transaction.
• - The test transaction calls the tested KB / CF and transfers the field as a parameter to the TFT area KB / CF.

1.8. Booking processes

CBS handles booking processes using Booking application servers. These application servers provide one unified interface for transaction and KB for Available to generate the booking entries and the To manage booking processes. This simplifies the Booking processes for transaction and KB very and improved also the flexibility of the system.

Main features

• - The booking application server is responsible for the Booking processes. Application programs just have to look around  take care of your business needs.
• - Booking application servers are the core of the booking system. If the booking system or others related to it existing requirements have to be changed, only the Booking servers are adjusted accordingly while the Transaction or KB no or only minor Changes required. This will be the cost of the design and the maintenance and reduce the quality of the Systems, especially in the part that the Booking transactions.
• - The booking rules are in several system tables saved. While booking rules e.g. B. due the merging or splitting of account keys change, the program source code is normally not Change may be necessary. This makes it easy that Manage booking processes of this system and adapt.
• - There are interfaces for these booking application servers simple and by default. This reduces the possible Errors, such as that transaction or KB's parameters the booking application server incorrectly.
• - The booking server checks the balance sheets of the whole Posting record. If an error occurs, CCBMain Generate error codes and causes, and users can find out the current problem of the system and correct it as soon as possible.

A. Booking system and architecture

The philosophy behind the design of CBS is to provide a usable, maintenance-friendly, expandable and integrated booking system. We implement it through the following elements:

• - Account key table
  Each system account key must be defined in the account key table in advance. The account key table is saved in BCMMSCM. The content of the record includes:

Account key: a three-tier 4-2-2 booking architecture. The three-tier architecture consists of a 4-byte key in the first tier, a 2-byte key in the second tier, and a 2-byte key in the third tier.
Account Key Name: The Chinese and English name of the account key
Account key property: whether the account key is part of the assets or liabilities etc.
Financial property: Account key is a normal or a governmental account key.
Balance sheet side: whether the balance sheet is debit or credit etc.
Usage level: Which department can use this account key (branch, subordinate branch etc.)?
Account key status: whether or not this account key can be used.
Property tags: Each account key has a set of tags that indicate its properties. These tags are stored in the account key table.

• - Account key properties
  A set of tags in the account key table that describes the properties of the account key.
• - Multiple currency support
  Supports multiple currencies.
• - Support for multiple organizations
  Clearinghouse or branch, subordinate branches on several levels
• - On / off account key
  The system supports on / off account keys.
• - General ledger
  The system supports the general principles of accounting. The bank can cross-check the general ledger and individual application subsystems.
• - Intermediate account processing
  The system supports a complete group of cross-account processing
• - voting
  The system supports account deferral / approval and other account reconciliation functions.
• - Internal / external accounting
  Support for multi-tier payment settlement among banks

B. Some important system tables and system work areas

• - TSYSSART (booking rules table)
  TSYSSART manages booking rules for all transactions and KB. Booking rules can also be overwritten by application programs.
• - TSYSSOVT (account key override table)
  TSYSSOVT is used to dynamically generate account keys for some booking entries in accordance with the terms and conditions at runtime. This helps reduce the redundancy of the booking rules table.
• - TSYSSCHD (booking conditions table)
  TSYSSCHD manages the correspondence between the business condition and the set of posting entries to be generated. The booking servers use this table to determine which sets of booking entries should be generated in TSYSSART in accordance with the terms and conditions.
• - TSYSSAMT (booking amount table)
  TSYSSAMT defines the names of the amounts, such as account balance, interest, etc., which the application program must provide to the booking server in order to calculate the amount of each booking entry.
• - TSYSSSMP (allocation type table)
  TSYSSSMP defines clearing types that are supported by the system and their posting entry records.
• - TSYSSIAT (overriding table for overarching account numbers)
  TSYSSIAT is used to dynamically generate cross-account numbers according to the account key and the terms and conditions. It also helps to simplify the TSYSSART table.
• - CBAIFARE (application interface area)
  In this area, the transaction or KB returns the data related to the application to CCBMain so that CCBMain can continue its subsequent actions. During the booking process, the transaction or KB provides some related data in this area, such as the reference ID, the transaction type, the account number, the number of the account to be credited or debited, etc. for processing by CCBMain.
• - CBAMTARE (posting amount range)
  CBAMTARE is the area in which the application program enters the amount defined in TSYSSAMT so that the booking servers calculate the booking amount for each booking entry.
• - CBARAARE (posting control area)
  This area contains the set of booking entries that the booking servers find in the TSYSSART table according to the runtime condition.
• - CBAOAARE (overwrite table for account entries)
  This area is used by the application program to overwrite some fields in CBARAARE, such as the account key etc.
• - CBAEAARE (transaction account entry table)
  This area contains the booking entries generated for the current transaction. The content of this area is used to update the booking databases and is also included in the transaction log.

C. Process of booking processing

The booking processing consists in that the online Transaction calls the booking application server to the Booking entries and the amount of the account key too generate, then the balance of the appropriate account key updated; during batch processing Details of the transaction for the account key from Transaction log generated.

C1. Main components of the booking application server

• - CCBMain booking processing workflow
  • - Booking amount application server (GCCBAAMT)
  • - Booking terms application server (GCCBACND)
  • - Booking rule application server (GCCBAAR)
  • - Main Booking Processing Program (GCCBMAP)

CCBMain booking processing workflow

CCBMain controls the entire process of booking processing. If CCBMain a transaction request from the terminal receives, it prepares the booking process. The first Step is to initialize the system Work areas or tables (CBAAOAARE, CBAEAARE and similar) that are required by the booking process; then CCBMain starts the corresponding transaction for the Application processing. The transaction can also start KBs. Both the transaction and the KBs can Create booking entries. If they do, they will Booking entries held in CBAEAARE. If the Transaction processing completes successfully CCBMain GCCBMAP to perform the balance sheet review update the balance of account keys as well as others Carry out booking processing and then the Enter booking entries in the transaction log.

Booking Amount Application Server (GCCBAAMT)

The transaction or KB calls GCCBAAMT to everyone Enter booking amounts in CBAMTARE that will be used later be the amount of booking entries for each Calculate account key.

Booking Terms Application Server (GCCBACND)

GCCBACND looks up the TSYSSCHD table to find the sequence number of the Fetch booking entry record that corresponds in TSYSSART the terms and conditions should be generated. A Business terms are determined by the values of a sentence specified condition factor fields.

Booking rule application server (GCCBAAR)

GCCBAAR generates the booking entries according to the  Sequence number from GCCBACND, CBAOAARE, CBAMTARE, Billing factors etc. and saves the booking entries in CBAEAARE.

Main Booking Processing Program (GCCBMAP)

GCCBMAP verifies the booking entries made during the Transaction were generated. If no error is found GCCBMAP has updated the relevant Booking databases, such as the account key balance, corresponding.

C2. Process of booking processing

Fig. 16 illustrates the model for booking processing

1) Request of the host transaction by the terminal

The terminal system sends the transaction request to the host.

2) Start the host transaction

After CCBMain is started, CCBMain checks the Input message and performs necessary preparatory Process steps through. Then it calls the appropriate one Application transaction based on the request of the terminal to process.

3) Call KB

If the transaction does not call any KB at all, the transaction will be responsible for generating all booking entries by calling appropriate booking application servers. The processing is the same as that of the KB.

• - Set the booking amount area (CBAMTARE)
  Calls GCCBAAMT to enter the values of the appropriate posting amounts in the posting amount area (CBAMTARE). A maximum of 30 booking amounts are allowed.
• - Set the booking conditions
  Calls GCCBACND to set the booking condition. It will then look for a suitable entry in TSYSSCHD that contains the sequence number of a set of booking entries in TSYSSART.

The terms and conditions represent a number of business-related information, such as type of deposit, Transaction type, deposit period, etc. These data fields are predefined. Setting the terms simply means to set the values of the suitable ones under these data fields.

Each data record in TSYSSART consists of a sequence number and an expression. The expression has the format {(field 1 operator value 1) and (field 2 operator value 2) and. , , and (field n operator value n). , .}. Field n is the data field mentioned above. Operator can be <, <=, =, <=, or not =. While the values of the data fields that are filled in by the transaction or KB are sufficient to print out a data record in TSYSSART, GCCBACND stores the sequence number in a system work area. This number will be used in later steps to generate booking entries.

• - Generate the booking entries
  GCCBAAR looks for the set of suitable booking entries in TSYSSART according to the sequence number received from GCCBACND. The application can overwrite some fields of these booking entries by using CBAOAARE. Additional clearing entry entries can also be generated according to the clearing condition of the current transaction.
  The full set of booking entries for a transaction consists of booking entries for KBs that it calls and those that belong to it. The number of booking entries for a transaction is currently limited to 24.

4) Return KB to transaction

KB returns control to the transaction if it is the Processing completes and the booking entries are generated have been.

5) Return the transaction to CCBMain

The transaction returns control to CCBMain.

6) Main booking processing program

GCCBMAP verifies the generated booking entries and updates the relevant booking databases.

7) Write the transaction log 8) Return the output message to the terminal D. Batch booking processing

Fig. 17 illustrates the workflow of batch processing.

During batch processing, the system creates the transaction details for each account key from the transaction log. Then the general ledger database is updated. Further information for general ledger processing can be found in Fig. 16.

E. Offsetting

Offsetting is important for a bank's business with other banks or with financial institutions. For every  Transaction related to external organizations generates a range of special information and recorded the accounting relationships between the bank and make it understandable to external organizations. This information is vital for some subsequent processing steps or business functions.

The view of offsetting and its implementation is different from bank to bank. In the CBS it is Billing system hierarchical. A branch runs Offsetting with other branches via the Clearing center in the main office. A Sub-branch carries out billing with other sub-branches through the branch. Any organization within the bank carries out billing with external organizations via the Clearing center through. The billing center is the Root of the hierarchical allocation tree.

The billing process includes two steps: the Collection of data and calculation of accumulated Clearing balances.

In the CBS, the system collects the clearing data using Clearing entry entries. Each transaction, the multiple Includes organizations Clearing entry entries that indicate the clearing between reflect these organizations. Account key in Clearing entry entries are only for Used for billing purposes. During the booking process of Transaction and KB GCCBAAR decides whether to clear has taken place, corresponding to several fields in the AIF Area filled in by the transaction or the KB become. These fields include AIF-TR-IN-ACCOUNT (account number for incoming transfer), AIF-TR-ACCOUNT (account number for outgoing transfer) etc. If an offset  GCCBAAR has generated booking entries under Using the TSYSSSMP account balancing type table, all of them supported billing types and rates of Booking entries that can be generated by any type Are defined. Clearing entry entries are in CBAEAARE saved together with other booking entries. The subsequent processing steps Clearing entry entries are the same as for normal booking entries.

1.9. Error correction process (EC)

EC here refers to the error correction of the transactions of the current business day. Error correction means that if a transaction is erroneous due to faulty Operation by the cashier or for other reasons was performed, then a reverse process was performed to reverse their effect.

A. The main functions of the EC

• - Do the effect on application databases that caused by the transaction to be corrected was undone.
• - Make the update of account key balance sheets through the transaction to be corrected.
• - Print error correction receipts.
• - Other business-specific functions if required

B. Error correction B.1 CCBMain and transaction / KB

CCBMain and Transaction / KB handle the error correction in cooperation. According to the transaction log of the normal transaction that needs to be corrected CCBMain the data necessary for the error correction transaction, such as B. input terminal message, Transaction request area, KB request areas, TGS-  Areas and booking entries. At the same time, CCBMain leads the Booking processing in reverse order as usual by. The transaction or KB represents the Application databases restored and completed others business-related processing in accordance with CCBMain prepared information.

The same transaction or the same KB program called to correct the original. Every transaction and each KB program contains two separate process logics for normal and EC processing.

B.2. Important system work areas

• - CBECIARE (EC input information)
  CBECIARE contains part of the EC transaction's input message, such as the authorizing director ID, account number, amounts for backup verification, transaction log number, etc., and also contains part of the transaction log of the normal transaction, such as business date, system date and system time of the normal transaction Transaction etc. This area is prepared by CCBMain for the subsequent EC processing.
• - transaction request
  The transaction prepares the transaction request. Similar to KB requests, it contains the information that the transaction would like to have written to the transaction log. The error correction takes the content of the transaction request for normal transaction by CCBMain to restore the application databases.

Fig. 18 illustrates the error correction procedure.

• 1. The client sends a request to  Error correction transaction to CCBMain. The request contains the transaction log number of the normal Transaction, an account number and one or two amounts. The Account number and the two amounts are provided by the cashier entered. You will see the corresponding fields in Transaction log compared by normal Transaction has been filed to ensure that the correct transaction is corrected.
• 2. CCBMain gets the transaction log from normal transaction according to the Transaction log number, enters in CBECIARE and sets the input terminal message, the CBAEAARE area, the Transaction request, CBTGSARE and the KB Requirement areas for requirements of normal Transaction restored. It also checks the account number and the amounts mentioned above. Then CCBMain calls that Transaction program on to correct the error perform.
• 3. The transaction carries out the error correction procedure using the input data and the Transaction request from the normal transaction. If necessary, KB is called to its own effect in the correct normal transaction.
• 4. When transaction KB is triggered by GSYSTRIG, catches up GSYSTRIG the KB request during normal Transaction generated KB according to the CBTGSARE area of normal transaction. Then the request area becomes the KB forwarded.
• 5. After the error correction procedure of transaction and KB returns control to CCBMain. She will Update of the booking databases for the normal  Undo the transaction in accordance with the CBAEARE Area of normal transaction.
• 6. CCBMain sends the output message to the terminal.

1.10 24 hour mode

The 24-hour mode meets the requirement of non-stop operation for ATM / POS, telephone banking, corporate banking, home banking etc.

The main purpose of the time interval method is that of similar Batch processes are carried out in the same period. The helps the design and operation of batch processing to simplify. The closing of the business day is in the 24-hour Mode performed, which means that ATM and other 24- Hourly transactions are still in progress.

Fig. 19 illustrates the business day close.

• 1. The business day closing for 24-hour transactions before the first branch closes.
• 2. Both the business day closing for 24-hour  Transactions as well as that apply to normal transactions for all branches of the bank.
• 3. A transaction that occurs after the close of business takes place as one of the next business day treated.
• 4. A branch cannot close the business day Close accounts.

Figures 20 and 21 illustrate the situation when ATM checks the accounts, as well as the ATM job mode and the time intervals.

Figure 22 illustrates the model for processing 24-hour transactions.

• 1. The 24-hour degree is held by the DB headquarters Afternoon before the first branch closes carried out.
• 2. While CCBMain meets the requirements for 24-hour Receives transaction, it calls the transaction program and passes the 24-hour mode to the transaction.
• 3. The transaction will determine accordingly whether it is in Online or offline mode. Then it is decided which database type, the original application database or temporary databases for 24-hour mode, is used.
• 4. During offline mode, the acquisition for a 24- Hourly transaction carried out in the time interval Tn. The basic step is to apply and booking databases according to the content of the update temporary 24-hour database.
• 5. To reduce processing time, several Centercut jobs are started to capture perform.

1.10. KB triggering

Fig. 23 illustrates the workflow of the KB triggering.

In a normal transaction:

• 1. The terminal sends a transaction request to CCBMain.
• 2. CCBMain allocates space for CBKBRARE, CBTGSARE and other system work areas and then calls the program for the requested transaction.
• 3. The transaction calls GSYSTRIG to trigger KB.
• 4. GSYSTRIG checks whether the number of KBs triggered is the Number 6 has reached. If this is the case, she suggests Transaction fails and an error message becomes the terminal sent back. Otherwise the next free area received in CBKBRARE for KB requests and APA-KBA-ADDR to the address of this KB request. Subsequently will be the name of the triggered KB and the triggering one Program recorded in CBTGSARE and the number of triggered KBs increased by 1. The KB is called.
• 5. The KB gets its KB request area via APA-KBA-ADDR and writes those for normal KB requirements Information to be recorded in the transaction log. After processing is complete, the KB returns to GSYSTRIG back.
• 6. GSYSTRIG returns control to the transaction.
• 7. After transaction processing is complete, the transaction program gives control to CCBMain back. It gets the normal KB requirements and the Information in CBTGSARE in the transaction flow write. When CCBMain is finished, CBKBRARE, CBTGSARE and other system work areas released.
• 8. CCBMAin sends the transaction output message to Terminal.

The following happens in an error correction transaction (EC):

• 1. The terminal sends a transaction request to CCBMain.
• 2. CCBMain allocates space for CBKBRARE, CBTGSARE and other system work areas. Then CCBMain calls that Transaction log of the normal, to be corrected Transaction and puts CBKRARE and CBTGSARE the normal Transaction, according to the transaction log, again forth. CCBMain then calls the transaction program.
• 3. The transaction program executes its EC logic. It calls GSYSTRIG to trigger KB.
• 4. GSYSTRIG makes the KB request from the current KB during normal CBTGSARE transaction was generated again. APA-KBA-ADDR relies on the Address of this KB request.
• 5. The KB executes its EC logic. The KB requirement that is generated during the normal transaction APA-KBA-ADDR available. The KB can save the data in the KB Use request to perform error correction. When processing is complete, the KB closes GSYSTRIG back.
• 6. GSYSTRIG goes back to the transaction.
• 7. After transaction processing is complete, she goes back to CCBMAin. CCBMain writes the EC-KB Requirements areas and CBTGSARE in that Transaction log. When CCBMain is finished CBKBRARE, CBTGSARE and other system work areas Approved.
• 8. The CCBMain sends the transaction output message to Terminal.

2. Knowledge block (KB) and common function (common function, CF) A. Definition of the knowledge block (KB)

KB is the smallest entity capable of performing a full business operation. KB is the basic building block of an application subsystem. KB has the following properties:

• - KB independently performs a function of the basic business completely through.
• - This business function is financial.
• - KB updates the application databases.
• - KB includes EC processing logic.
• - KB writes transaction log.
• - KB generates output forms.

Among the above properties, the first one is most important and basic. It distinguishes KB from CF.

In the system, KB stands for the business rules of all banking products and services that the system supports. The Transaction is built up by putting together more suitable ones KBs. So a transfer transaction can be done using a Payout KB and a deposit KB can be put together. On the one hand, the transaction can be made up of KBs just be developed. On the other hand, the transaction also overwrite functions provided by the KB and customize to meet special business needs when needed fulfill.

The knowledge block (KB) only works online.

C. Definition of the common function (CF)

Common functions are a group of programs that implement some repetitive functions, such as Interest calculation, data query / data maintenance, data verification etc. The design of the common function can be the development and simplify the maintenance of applications.  

Compared to the knowledge block (KB), the common function (CF) has the following properties:

• - She is unable to complete one Conduct business operations independently.
• - It is not financial.
• - You cannot write a transaction log.
• - It cannot be corrected become.
• - Output takes place only via output parameters. she can do not generate output forms.
• - It can also be used in a batch environment if no DB operation is required.
• - An application error in CF does not lead to Transaction failed. The program that this CF calls, takes care of error handling.

B. Release of the KB

To run, the KB must be through a transaction or triggered by another KB. The transaction or the KB triggers the KB by calling GSYSTRIG.

The KB request areas are a group of system work areas in which the KB can store the information that must be contained in the transaction log. In a normal transaction, CCBMain will save the contents of the KB request areas in the transaction log after the transaction has successfully completed. In an EC transaction, the KB can fetch the KB request that it generated during the normal transaction via CCBMain and use it to carry out the error correction process. The main functions of the KB request include the following:

• - Deliver the necessary batch processing information  
• - Keep the intermediate result during a normal one Error correction transaction

A transaction can trigger a maximum of six KB. Each KB Request has a length of 256 bytes.

Important working areas of the system

• - CBKBRARE (KB request area)
  Contains all 6 normal KB requirements; 6 Reverse KB requirements and KB index. The KB index is the ID of the current KB request in CBKBRARE. During a normal transaction, the content of a normal KB request is recorded in the transaction log. In an EC transaction, the normal KB request contains the KB request that was generated during the normal transaction and the contents of the reverse KB request are written to the transaction log.
• - CBTGSARE (trigger sequence area)
  In a normal transaction, GSYSTRIG records the name of each KB that was triggered, the name of the triggering program, and the number of KBs that were triggered in CBTGSARE. After the transaction is completed, CCBMain writes this data to the transaction log. In an EC transaction, CBTGSARE returns the content of the same area of the normal transaction. GSYSTRIG receives the KB request area that was created in the normal transaction for a KB for content in CBTGSARE.
• - APA-KBA-ADDR
  A field in CBAPALST. Used to access KB request areas.

3. Application system

In a CBS system, business functions are Transactions and batch jobs from any application subsystem implemented.

4. Generator

A generator is one provided by the CBS system Set of tool programs that can be used to some Types of source codes, system tables, reports etc. produce. A generator is mainly used during the Development, maintenance and generation of batch reports used. A generator reduces the workload at the Application development and also improves quality.

The working model of the generator A. Generators that input data directories to use

Most generators, including all data format Generators and some system table generators Data directories as input. This design represents the Consistency between the generated results, the design in earlier project phases and the rest of the system.

B. Generators for booking tables

Generators for booking tables use booking table Databases as input. These databases are used by users using maintenance transactions for booking tables groomed.

C. Database access engine and copybook generators

For RDBMS all tables-copybooks, host structures- Copybooks and programs for access machines automatically generated. Typically spreadsheet copybooks and host Structures copybooks generated from the data directory to the Ensure design consistency.  

D. Generators of database access machines

The file is defined to define the file properties Properties for each file, such as file name, file type, allowed access method, minimum record length, maximum Record length, fixed or variable length, the data format numeric fields etc. The generator for file access machines generates the access engine for each file according to their Property definition file.

E. Report generator

The report generator is a utility that runs from the batch job is used to get the report file from the result of the job create. Different reporting functions are about customized parameters of the report generators are available posed.

5. Draft

CBS provides a draft program for all major types of Application programs, such as KB, CF, various types of Transactions, batch programs, batch tools JCL programs, CenterCut job etc. are available. The design contains the processing logic that is common for this type of program, and also defines the program structure.

During the development of an application program one needs Developers only use the special business processing logic for enter this program in the template.

Drafts standardize the developed programs. she also simplify development, improve Development efficiency and the quality of the system.

In most cases, a draft includes the following:

• - Program structure  
• - Uniform processing and uniform Data definition, such as B. the for Memory initialization, and data definition of Application interfaces.
• - error handling
• - Sample keys for some commonly used ones Processing

It will be clear to the person skilled in the art who benefits from this explanation be that many more within the scope of the present invention Variations on the foregoing description and drawings can be made. Accordingly, the following are Claims including all supplements that the Define scope of the invention.

Claims (10)

1. A system for integrating basic banking activities, which includes:
Business platform to provide an application development environment that integrates various processes common to individual base banking activities and shared databases for base banking activities for data shared by individual base banking activities to create the system with the composite Provide customer or business information by analyzing customer or business data;
Rule library for the underlying transaction and library for the shared function, the underlying transaction being the smallest unit capable of a particular business operation, and the shared function being the program for implementing the function that is repeatedly used by the underlying transaction;
and an application business subsystem for establishing various specific businesses by combining the rules of the basic business. 2. The system of claim 1, wherein said base banking activities include at least one of the following: ongoing Deposit, fixed deposit, loan, settlement, Credit card / debit card, booking, electronic transfer, Billing, account book and the like. 3. The system of claim 1, wherein said business platform includes at least one of the following: Master module for  Online transaction, database interface module, master Module for online batch processing, module for online Reporting, module for external interfaces, Test driver module. 4. The system of claim 1, wherein said business platform includes at least one of the following: booking process, Error correction process, 24 hour mode. 5. The system of claim 4, wherein said booking process through a booking server the account through various Transactions, or the underlying transaction of the account the fixed interface leads. 6. The system of claim 1, wherein said rule library for the basic business, the overall business triggering and automatic transfer implemented. The system of claim 1, wherein said system further includes a generator to layout and data Generate memory tables for the system. 8. The system of claim 7, wherein said generator includes at least one of the following: one Generator that uses the data directory as an input source used a generator to generate the Booking process tables, a generator for the Database access engine, a copybook generator, one File Access Engine Generator, one Report generator. 9. The system of claim 1, wherein said system of Includes other program drafts. 10. A process for integrating basic banking activities, which includes the following steps:
Analysis of the application business in order to create a business platform for providing a development environment for the application business, in which various processes that are common for the individual base banking activities are integrated and shared databases for base banking activities for data that are shared by the individual base banking activities to provide the system with composite customer or business information by analyzing customer or business data;
Analysis of the application business to create a basic business rule library and a shared function library, the basic business being the smallest unit capable of implementing a particular business operation, and the shared function being the program to implement the function that is used repeatedly by the underlying transaction; and
Establishment of various specific businesses by combining the rules for the basic business.