Maintaining Transaction Configurations

This transaction is used to maintain transaction configurations.

Transaction configurations are used to override or complete the hard-coded requests of particular rules in business transactions.

By means of the configuration panel, the following types can be overridden:

• 'Save Diary' (rule TrnDiaSet) - for creating or modifying diaries
• 'Store fee' (rule AddFeeData) - for storing fees in the settlement

The following transactions can be started from here by clicking the icons in the list below for:

• Adding a Transaction Configuration
• Modifying Transaction Configuration
• Deleting Transaction Configuration
• printing a list of transaction configuration(s)
• creating Transaction Configuration List
• showing Version Log of the modifications to the transaction configuration(s).

After entering at least one search term in the fields Transaction, Type or Code, the transaction configuration matching the selection will be displayed in the table on the “Search Panel”.

By double-clicking an entry a definition will be displayed on the configuration panel.

If the checkbox “Display Default Entry to compare” is checked and a DTC record exists, a popup with the DTC details is popped up and displayed.

If the checkbox “Suppress Default from Transaction” is checked, then the execution of the programmed rule will be suppressed without substitution. In this case no further entries can be made.

In case the transaction configuration rule has to be executed only under specific conditions, it can be defined here as simple 'IF' request. In doing so, up to two fields, constants or functions (e.g. 'today') can be specified and compared with an operator.

The following conditions are available by default:

• Equal
• Not Equal
• Greater than
• Less than
• Is Empty
• Not is Empty
• Free Formula
• Unconditional

The specified condition is displayed as converted TradeDesign source code on the screen. No syntax check is performed. A condition defined in the sources will be ignored at any rate, in case there is a transaction configuration available for the relevant key, irrespective of whether there was a condition defined in the transaction configuration.

A transaction configuration overrides a concrete request of a TradeDesign rule in a business transaction. At present, requests of “TrnDiaSet” and “AddFeeData” can be overridden. The arguments for requesting the rule are specified in the same sequence as in the source code. The field that is used for assigning the transaction configuration to the relevant part of the source code is specified in the “Code” field. The user could create a new (diary/fee) transaction configuration by clicking the 'Add New' icon.

Similar to defining a new diary/fee entry, existing rules from source could also be modified through this transaction configuration. For example, GENDTC generates the transaction configuration from the source (see Generating Application Transaction Configuration from Source). If diary option is selected, it downloads the diaries that are specified in the source code into the ATC table. Thereby making it easy for the user to view and amend (i.e.override) the already existing diaries, if needed. The user upon selecting the 'default' record (entry from source code), could click on the 'Add New' icon, by which the generated DTC record is mapped to the panel. The user could do the required changes and save the changed entry.

For the rules described in more detail here, transaction configurations can be stored for overriding the source code:

Syntax of the rule within the source code:

• “TrnDiaSet(<Record Group>,<Code>,<Date>,<Coded Reason>,<Description Text>,<Target Description>,<Action>)”

In the source code, these calls are generally entered in the DIASAV rule.

• Record Group: The module group of the defined business transaction for which the diary is to be created is specified here.
• Date: The target date to be specified in the diary This will be the base date for diary calculation.
• Days: The number of days to be added/reduced to the base date defined. The processing of diary will be calculated accordingly.
• Code: Freely definable term that is used to identify the diary technically (e.g. when it is updated). Example: “EXPIRE”.
• Coded Reason: Combobox for selecting the reason of the diary (e.g. expiry warning).
• Automatic Processing: Checking this field allows the target transaction defined to be automatically processed on the date the diary is executed.
• Description Text: Longtext that is stored with the diary and which will always be displayed when the diary is shown.
• Target Transaction: Business transaction to be started when the diary is taken up for processing (e.g. in DIASEL).
• Target Role for Message: In case the target transaction defined is a common message, this field specifies the addressee/receiver of the message.
• Action: 'Replace' or 'Write'. Describes the action that has to be done, if an already stored diary has been found for the current contract and code when executing this rule.

Introduction of 'Automatic Processing' checkbox in the type 'Save Diary', enables automatic processing of the 'Target Transaction' provided. This generates automated (SPT) tracer/free message with a predefined text, at predefined intervals, to the 'Target Role for message' defined. Technically, setting this flag adds a “$” symbol to the argument code, for e.g. “FOL$” in the diary call function. Predefined text could be created from the text module transaction DBITXM (see Maintaining Text Modules) which will be automatically used when the diary is processed.

“Sample flow for STP generation of tracer:”

• Create a DBxATC 'Save Diary' record with 'Automatic processing' checked and selecting a receiver of the message in 'Target role for message'. Example ISS (Issuing bank)

• Define a text module in DBxTXM Maintaining Text Modules with details of the diary setup
  • Select 'Group' to be the target transaction of the diary setup (E.g. LETFRE)
  • 'Key'/Id of the text module to be input with below logic. Sample D#FOL or D#FOLISS
    • To start with 'D#' as fixed text, which reflects that the text module is used for diary processing.
    • 'FOL' reflects the code of the diary reason (FOL - Follow up)
    • 'ISS' reflects the target role for the message or receiver of the message
  • Define the 'Text' as required in the required language

• Upon setting up DBxATC and DBxTXM, start the business transaction for which DBxATC was defined
• The queue entry for execution of the diary will be created on the date defined in task manager 'QUETSK' Manager for interactive Queue Entries. On this date, the diary will be displayed in the To Do list of the contract
• The diary entry will also be listed in the task manager 'SPTTSK' Manager for Automatic Execution of Pending Items, where it is pending for automatic execution until the manager is executed/run.
• When the pending item is executed in 'SPTTSK', the diary is processed automatically and a message to the receiver with the defined text module is generated in the respective xxTFRE common message module.

• In case of any error in these steps, a paused entry of the common message with error is created in the 'To Do' list of the respective contract.

Syntax of the rule within the source code: “AddFeeData( <Code>, <Defaulting>, <Units>, <From-Date>, <To-Date>)“
Usually, the requests are in rule RegisterSettlement in the source code.

• Fee Code: Fee code of the fee to be defaulted (according to the FEE table)
• Fee Flag (Defaulting): Information on whether the fee has to be added in case an entry was already found for the specified code on the Settlement panel. Yes (Y) = add, all other values = do not add
• Units: Default value for the number of units in the fee settlement. Usually 1.
• From-Date: Start date for calculating the fee (for time-dependent fees)
• To-Date: End date for calculating the fee (for time-dependent fees)

Selection
Transaction Configuration