Transactions Generator

Development and Innovations
In the course of localizing the Equation system a facility has been required to relocate rules of accounting operations. Such facility has been developed. First EHI versions have been created for functioning jointly with the cashier system and, therefore, the product was called EHI, Enhanced CS Host Interface.). EHI has been applied to relocate rules of generating postings and executing thereof when performing cash operations. The next generation of the product has been enhanced and an opportunity appeared to use EHI in any application, where a flexible relocatable accounting of operations is required.

Accounting Module Development Objectives
In the course of creating a standard module for performing accounting functions the designer should account three major aspects:

• to analyze requirements to generating accounting actions. It’s necessary know what actions should be completed in the course of transaction applying;
• to design the format of calling such module. Such format should contain all parameters required for generating accounting actions (numbers of accounts, amounts, currencies, etc.);
• to procure such transaction integrity. In the event that any action cannot be completed then the entire transaction (actions completed before) should be cancelled.

All the above aspects should be accounted at the design and coding. When the development is completed the source text is created and it is subject to compilation in a programming module. In the event that the accounting rules, call formats or other requirements are amended it will be required to introduce amendments in the source text and recompile the program. Generally each functional field has its own requirements to performing accounting operations and this leads to a necessity to repeat the process described above. Having developed the Transactions Generator, we solved the task of creating a unified universal facility making it possible to relocate rules of completing accounting operations and generate transactions in conformity with definite relocations. In so doing it will not be required to introduce amendments in software programs.

Flexibility of Relocating Operations
EHI can be used as a universal accounting module since by virtue of this module the designer (or IT analyst) can relocate accounting rules, specify call parameters, enhance standard possibilities of the module by means of any additional business functions and integrate such accounting module in its application. While in operation the EHI core is interpreting relocations and completing transactions in conformity with such relocations. EHI is also procuring the transaction integrity. No necessity in rigid coding the accounting rules in a separate module. If requirements are changed the designer (or IT analyst ) is to only amend transaction relocations specified in the accounting module.

Accounting Module Integration
In order to integrate user modules in the required applications Equation standard mechanisms should be used. They provide for both possibility of integration in the Bank’s own developments and change in operation of standard modules of the system by calling user procedures. In order to call runtime of EHI module to process a predetermined transaction a respective application should furnish EHI with the following parameters: 1. a transaction type (or a "prototype" used to obtain transaction relocations) 2. Functioning mode (determines EHI operation mode) 3. A transaction code. A unified reference, making it possible to this transaction in EHI tables. It may be left empty and then the module will generate a reference in compliance with rules of reference generation ( it is customized in "EHI Prototype Determination" function) 4. Additional parameters. Additional parameters can be used to transfer specific business data to the transactions generator. A designer can define a structure of parameters in accordance with his requirements ( by means of " Relocation of variables maps" function) EHI forms transactions in compliance with relocations and generates a list of executed actions which will be transferred to a calling application (by means of a time-division table). They will be also transferred even if errors or warnings occur.

Functioning modes
EHI accounting module can operate in the following modes:

• Generate – Only building of a list of actions on a transaction is accomplished. Actions themselves are not accomplished.
• Validate – building of a list of actions is accomplished and each action is separately checked for a possibility of its execution. If any error or a warning occurs (different currencies, insufficient funds, etc.) they will be returned to a calling application.
• Post – building and application of a list of actions are accomplished. If an error occurs during processing of any action all previously applied actions are cancelled.
• Query – this mode is applied to obtain information on previously performed actions. A calling application should transfer a transaction code to EHI to search information.
• Delete is similar to Query mode, but all performed actions are deleted. For example, if a posting is generated today it will be deleted. If a posting was generated on previous days a reverse or updating posting will be generated.

Determination of call parameters
When EHI is called parameters are transferred in the form of a data area (array), which is composed of two major parts, i.e. standard parameters and additional parameters. Additional parameters may contain any business information specific for this application, for example numbers of accounts, amounts, etc. For EHI to understand the structure of additional parameters a designer should customize the so called "map of parameters " containing information on each component of additional parameters. On the basis of statistical additional parameters one can define "virtual" parameters being a result of computation of expressions. Such expressions can contain any of previously defined parameters.

Relocation of accounting rules
A set of rules used to account a transaction is composed of individual rules used while executing operations. Each rule has its own type and is composed of separate elements (depending on a rule type). For each element of a rule an algorithm of computation of its value is customized. An interpreter of expressions is built in EHI and it is the main reason of flexibility of EHI as a tool (see the next section).

Interpretation of Expressions
A facility is built in the accounting module making it possible to interpret expressions of a simplest BASIC-like language. It operates with three basic data types, i.e. character string, number and logical value. Major operators are supported such as plus, minus, divide, multiply, etc. Expressions may contain variables defined in the map of parameters. In addition such functions as SUBSTR, ROUND, MIN, MAX and others. Interpreter EHI can call additional EHI, EQUATION or OS400- related functions. For example, CONVERT is conversion of a sum from one currency into another on the basis of retail exchange rates, CHECKACC is checking of availability of an account, DAJOBCTL is obtaining the content of data area DAJOBCTL , etc. In addition a bank may define its own functions and integrate them in EHI interpreter.

Enhancement of accounting module basic functionality
If enhancement of accounting module basic functionality is required a bank may:

• Develop additional functions to be used in EHI interpreter of expressions. Along with EHI a development environment emerges containing documentation and patterns of programs in RPG and ILE C languages.
• develop additional types of actions. For the purpose it is necessary to create three additional modules, i.e. Action Addition Module, Action Checking Module, Action Cancellation Module. EHI documentation contains information on how it can be done. In addition along with EHI some utilities are supplied . They are used for quick creation of new types of actions based on EQUATION journals.
• Use points of calling user programs in an accounting module. EHI standard version contains no points of calling user programs , but this functionality can be supplied upon request of a bank.

Integration of External Systems
EHI makes it possible to use Equation standard mechanism for integration of external systems, i.e. Cashier Host Interface. Cashier Host Interface mechanism makes it possible to call a program object from external systems (Action Module), to which a standard list of parameters containing information required for operation execution in Equation is transferred. If so required Action Module performs additional data transformation and execution of the required operations. Along with EHI Action Module is supplied , making it possible to use functionality of the Transactions Generator from external applications using Cashier Host Interface, for example Cashier System, EBA and developments of a bank.