After starting Control and Release of Transactions, a selection panel is displayed where various selection criteria can be entered. All transactions that match these criteria are displayed together with respective key information such as reference, signature required, signature obtained, transaction type, status, etc.

The user can release (or reject) the transaction directly from this panel. Alternatively, the user can switch to the more detailed “Transaction Header” panel by double-clicking a list entry. This provides additional information on the release status. The associated correspondence can also be started from here.

A user wanting to see additional transaction details can click on the [ Details] button to gain access to all transaction panels. These provide all the information related to the transaction being processed. Entries made and panels used by the processing user are underlined in red.

Marked fields or panels in display files can be underlined in different colors, which have the following meanings:

• Red: fields have been filled in by the user.
• Green: fields have been filled in via an incoming message, by copying a contract or in a previous transaction.
• Blue: the formatting of the field (not the content) has been modified (bold, italic, underlined).

The Maintaining System Parameters transaction can be used to change the colors of the underlining.

Clicking the icon prompts the system to check the user's release hierarchy and imports the signature of the user into the transaction. If all the signatures required for the transaction have been entered, the transaction will finally be released. Afterwards the system will continue to process the transaction in the workflow. If some signatures are still missing, the transaction will 'wait' for the pending signatures.

If the user cannot release the transaction due to errors contained in it, it can either be rejected using or set to correction using . A rejection deletes the transaction completely, rolls back all system activities that were triggered by the transaction, and moves the transaction to the recycling bin. The release flag for all dependent transactions generated for this contract after the creation of the transaction to be deleted is set to Reject. All remaining workflow entries for this transaction (except SRVCLN) are set to 'C'ancel or 'S'kip for the services SRVPDS or SRVPDP.The same process takes place in the case of a correction. However, an SPT entry is generated in the list of transactions to be corrected. This entry can be picked up from there, and a new transaction can be created using the data from the old transaction. The release flag for all dependent transactions is set to Correct. All remaining workflow entries for this transaction (except SRVCLN) are set to 'C'ancel or 'S'kip for the services SRVPDS or SRVPDP.

If a pending item exists for this transaction, the [Pending Item] button is displayed. The details of the pending item can be displayed on a separate panel by clicking this button. The current status of the item is displayed below the button.

If a transaction that created a contract is deleted or set to correction, the contract is not deleted. Instead, the contract is written to the database as an “eliminated” contract. The date the contract was created is deleted. This enables the system to recognize that this is not a valid contract. Associated data such as addresses, log entries, etc. are all deleted.

Selection Panel
Transaction Header
Workflow
Interface
Acknowledge
Events
Completion
Incoming Tag 72/79
Dependencies
Order
Acknowledgment
Order
Diary Details Panel