Entities need to be administered to determine the environment in which the application is used. This may also contain information on certain entities that are included in main branch offices as well as on several logical systems. In the application, an entity is a defined unit: a user is permitted to process business transactions and access data relevant to this entity. The “Multi Entity” capability facilitates the use of different concepts for headquarters, multi-bank processing, etc. A user is usually assigned to a relevant entity (see also “Maintaining User Profiles”).

Besides this, other system settings also have to be made. Such settings are made by the support staff during the implementation phase, in line with the needs and requirements of the bank. This includes the allocation of basic data, contracts and transactions to an entity. These then need to be taken into account whenever an existing entity is modified or deleted.

Entities are usually headquarters or similar processing centers that process common business transactions.

Entity Groups comprise multiple entities and constitute a self-contained accounting methodology. Usually, an entity group is a complete bank. A base currency is defined for each entity group (e.g. for determining rates).

Entity address administration enables various addresses to be stored (for branches and/or user groups) that differ from the main address contained in the current installation of the application. The main address and all other data related to the headquarters' address were entered during system implementation. The concept of entity addresses was introduced to allow the use of different addresses. Details that differ from headquarters' settings can be stored in the database.

User and user groups can be allocated to an existing entity address. When printing out correspondence, it is possible to define specific printers for specific entity addresses (see also “Printing”).

If users (or user groups) located at different physical sites around the world work together on transactions and/or if the PC on which the application is installed is not located at the same location as the user/user group, it makes a great deal of sense to use the time zones feature .

The application provides the option of defining time zones. Details of the process of defining time zones can be found under “Maintaining Timezones” .

The application displays timestamps in various transactions in the application. This can include the date and time an order was received, for example, or when a transaction was entered. Timestamps are used to document when something happened or is due to happen. In contrast, data such as value dates, dates of issue, due dates, etc. are always stored from the perspective of the user entering the data.

Distinctions need to be made between:

• the actual time of the PC on which the application is running: as a rule, this is the local time for the actual physical location of the PC.
• the system time: it is set using “Maintaining System Parameters” (DBITDP);
• the user time: this corresponds to the user's time zone set via “Maintaining System Parameters” (DBITDP). The system time is defaulted, if no setting is made. The user time can be overridden for each entity;
• the actual time of the client: this is used independently of time zones to display the clock in the Office and to calculate dates using '+' or '*'.

Timestamps are physically stored in system time. However, when displayed to the user, they are converted to user time. Thus, the receipt of an order entered and stored in Germany on March 1 at 10.05 local time (CET), will be displayed in Hong Kong at local time (7 hours ahead of Germany), i.e. March 1, at 17.05. Time zones are only applied with timestamps. Date fields are not converted when displayed. The issuing date of March 1 always remains March 1, for all locations.