The application transaction profile contains the configuration details of each and every transaction available in the application.

The core data derived directly from the function of the transaction are saved to data table ATP and can be displayed and changed via transaction “Maintaining Application Transaction Profiles” (DBIATP).

The configuration data which depend on the relevant specialized requirements of the bank using the application is saved to data table ETP and can be displayed and changed via transaction “Maintaining Entity Group Transaction Profiles” (DBIETP). The settings applied in in this transaction can be done separately for each entity group.

NOTE: Each transaction used in the application must be correctly defined in data tables ATP and ETP, otherwise system malfunctions may occur; changes therefore need to be carried out very carefully.

In addition, there is an option of carrying out additional settings regarding the specialist function of a business transaction. The rules programmed in the source code regarding the handling of diaries and fees can be modified, supplemented or ignored without changing the programming in the source code. These settings can be made with transaction “Maintaining Transaction Configurations” (DBIATC).

The application provides many of the customizable features via built-in rules which are called to trigger certain features, such as diaries entries that are created in a particular business transaction that are triggering a follow-up transaction at a certain future date.

For example, in the issuance transaction of a Letter of Credit, a diary is created 5 working days after the expiry date of the contract, triggering the Closing transaction. Such a diary entry is coded in the sources of the application and the details are documented in the business transaction itself, e.g. Opening an Import L/C. From a business perspective, it is clear that most banks will have such a diary entry to streamline the handling of the business and to reduce the number of open contracts that are expired. But not all banks will require a diary exactly after 5 working days. For some it should be after 10 working days and for others it might be after 90 calendar days.

DBxATC allows maintaining (i.e. suppressing, overwriting, adding) the diary and fee defaulting in business transactions. Further information is available in Maintaining Transaction Configurations.

From a technical perspective, the Application Transaction Configuration (ATC) has been set up to provide the possibility to display the built-in usage of certain rules as well as allowing to switch off and add new virtual calls to those rules. Doing so, the behavior of the application can be adjusted without changing the source code.

To get the built-in calls to rules, a source extraction tool “Generating Application Transaction Configuration from Source (GENDTC)” is provided, which analyses the sources and generates entries in the DTC (Default Transaction Configuration) table showing the default implemented calls. The transaction GENDTC is only used to analyze the product source to update the DTC table as provided in the MyModelbank.

The layout of the transaction Maintaining Transaction Configurations (DBIATC) is set up with the intention to provide a maximum of functionality and a look and feel close to that of a developer. It allows to show the used default values of an entry in a separate popup beside the normal transaction screen to have a visual comparison of the different values of an entry. When accessing fields in the definition of an entry, the available fields can be selected by writing the field name either in the technical reference or the long text description of the field. When typing, all matching fields will be displayed in a selection box.

When using ATC, it is important to understand that entries must be added in order to suppress or change an existing default diary or fee code. Besides suppressing or overwriting existing entries, it is possible to add additional new entries on top of the default entries. All ATC entries are using a short ID for identification and to be linked to the matching rule calls used in the product source code.