Checks of the application's input fields should be run as early as possible, providing the user - by means of error messages - with direct information about occurring errors.

These checks should not simply remove the incorrect/erroneous values which have been entered. The user should still have the chance to view and identify errors made before they are corrected.

Error messages should also give some notes about the specific input field or at least about a group of fields being checked. This supports the user, giving him/her a visual feedback of the error.

Error messages or other messages should all be displayed from the user's perspective, i.e. the message should state more than just 'An error has occurred'. A message such as 'The account number is incorrect, please enter a valid number.' is much more supportive.

The visual layout of the panel should follow the details given in the style guide.

In a given available space, the usage of technical or internal codes for fieldnames must be avoided. The long text version should be used wherever possible. If, due to lack of space, codes have to be used, these should also be decoded with the help of appropriate hints. With a simple mouseover, a describing hint should become visible.

The only exceptions to this rules are those, that have more or less become part of daily speech habits, such as ISO currency codes or the transaction mnemos (e.g. 'LETOPN' instead of 'Advising / Confirming an Export L/C') in transactions.

In all business sectors are fields, that are always repeated and that have a uniform usage and significance. These fields are:

• EXTKEY or OWNREF
• NAM
• Amounts (xxxCUR and xxxAMT)

The EXTKEY (or OWNREF in contracts) is an easily readable, unique keyword, which can be used by the user to search for an object. This is, for example, a personal, own reference for contracts, or a customer reference number for parties and addresses, or an account number.

These keywords are standard unique keywords in DOKA. They can be removed or restricted for individual customers and they can normally not be amended after delivery. Even this restriction can be lifted in individual cases, because the internal access routines refer to keyword references via the EXTKEY, but via implemented INR coupling.

In reverse, this also means, that the EXTKEY is not used when the user is carrying out an internal technical search for associated contracts/parties/accounts. When technical data records are to be linked, linking is to be done via INR coupling.

In nearly all tables, a NAM field is part of the keyword. This field describes the relevant data object and also serves as an internal description of the data element for the department/bank. The NAM field is not intended to be used externally. It can be formed automatically through defaulting rules from other datafields, and can also be entered freely.

The NAM field is used for searching and displaying selected records.

As a matter of principle, amounts are always stored and displayed together with a currency. Therefore, for each amount field (abbreviated to AMT) there is a similarly named currency field (CUR). The amount field is defined as a 'Currency' field and as such it is always assigned to a relevant currency field. After this, TradeDesign carries out the necessary preparation for the amounts with the correct number of decimal places.

All static data system panels are to be divided into the following elements:

This is a field, or fields, which can be entered to uniquely identify a data record. These fields can be entered in 'Info' transaction panels (DBI) and in 'Data Capture Transaction' panels (DBA) for new data records.

These fields can be filled in/amended in DBA transactions (capturing new data records) and DBE transactions (amending data records). With DBI (info on a data record) and DBD (deleting a data record) transactions, these fields cannot be amended.

These are the buttons and are located next to a keyfield. They enable the user to carry out an advanced search - if an entry can be made in the keyfield - or to access information on a data record - if content is displayed in the keyfield. Logically, these buttons become active when either the corresponding field is enabled or the corresponding field is disabled but filled.

These are the buttons with the 'i' in square brackets and are usually located next to a keyfield. They enable the user to carry out an advanced search - if an entry can be made in the keyfield - or to access information on a data record - if content is displayed in the keyfield. Logically, these buttons become active when a database record has been assigned to the field. In other words, the [Search] Button is enabled in DBI, DBE and DBD transactions, while it is inactive or disabled in DBA transactions - since there are no data records available. Any other Info buttons on the panel are enabled when the relevant datafield next to it has been filled in. Whether a button is enabled or not, is not dependent on the condition or nature of the panel, but primarily on the assignment of data to the field. The basic principle is that when a datafield next to a Search/Info button is open, i.e. a search can be executed, the button has to be enabled. The button is also disabled, when the field is disabled and a record has been opened, i.e. a corresponding key has been entered.

When returning from DBExxx, DBAxxx, DBDxxx to DBIxxx the current record has to be reloaded incl. all dependent records. When changing from DBIxxx into the transaction, the following has to be considered:

* If a record is loaded in DBIxxx, all data fields (except the parent key parts) have to be deleted. For example, the party has to be passed in the accounts, but the currency, account type and account number have to be deleted. In this case, the party is the subordinate key. This applies also analogical to the fee conditions. There, the fee is the subordinate key. * If no record is loaded in DBIxxx, the key values entered in DBIxxx have to be passed and the other data fields have to be deleted. Thus, if no record was found, the searched key values remains available, when creating a new record.

The Drag & Drop sender icon is normally found left of the NAM field of the according record and allows to take up the currently read record with Drag&Drop. This icon is enabled in DBD and DBI transactions. In DBA transactions the icon is disabled, since no records are available.

Normally, there is a so-called (not visible) Drag & Drop receiver over a key field, which can receive a record transported via Drag & Drop. A Drag & Drop receiver is always enabled when the relevant field can be amended, i.e. when a record can be selected.

These buttons reflect the actions available to a user given the current status of the panel.

The buttons [Add New] and [Report] are enabled in DBI, since both functions do not rely on the existence of an open data record.When a data record is opened in the panel, the buttons [Modify], [Delete] and [Log Display] are also enabled.

Navigation buttons found in the middle section (these can vary according to the nature of the transaction) should always be active when cross linking is possible. Normally this is always possible in DBI transactions, but not normally available in editing transactions. With editing transaction, attention needs to be given to ensure that the standard support system does not run an update of the adding/amending, started when the user exits the panel using these cross link transactions. Normally, these cross links are only possible in DBI transactions and are not available in DBA, DBE, and DBD transactions.

[Exit] always has to be enabled: it must always be possible to exit the panel. With adding and amending transactions, the [Break] button should be located directly above the [Exit] button.

In order to provide the relevant key field information in a static data system, the corresponding tables need to be taken into account. Normally, these tables will contain a field EXTKEY or COD. These represent the main keywords searched for.For multiple keyword searches, or for tables with additional definitions for Party, Country, Currency, or Account Type, additional fields appear prompting the user to refine the search, so that several fields must be entered before the actual search can begin.This means in this case, that either the logically superordinated keywords in the tab sequence are retrieved before the actual search term, or it is requested, which type of amendment is necessary. Depending on the query type, that are required for each type, the additional fields become visible.In static data systems, data record selection is, in principle, not based on comboboxes, but rather on free input fields. By entering a question mark (?), all the contents of the table are displayed. If a keyword is entered in the search, all data records fitting this keyword are displayed in the selection.

When another transaction has to be started via a function, LNKCALL/LNKCHAINTransaction has to be called in the EventRule when starting this transaction.

• “LnkCallTransaction” is used, if - after exiting the called transaction - the has to return to the transaction from where the called transaction was started. “LnkCallTransaction” should be used for logically subordinate transactions (e.g. editors, display functions, etc.).
• “LnkCallTransactionAndSetReturn” sets another, aberrant return transaction (rare exception). This function is used when re-routing messages by directly starting the entered transaction.
• “LnkChainTransaction” is used, when the user has to be returned to the Office after exiting the called transaction. This function “must” be used, in case further transactions can be started from the called transaction.