When working with addresses, a distinction can be made between main addresses (“Parties”) and subordinated postal addresses (“Addresses”). An address is always assigned to one party, while a party can have several addresses.

The group head office can be defined as the party, for example, with affiliated addresses representing the addresses of the branches. The same applies with a bank as the party, for example, with the addresses representing the corresponding departments and relevant contacts.

Conditions, account numbers and such like are assigned to a specific party, while in principle an address is simply the postal address for this particular party (i.e. no further information is included under an address). Most of the time, the relationship will be 1:1 with a party having just the one address. However, in cases where several addresses have been assigned to a particular party, a user enters a party and receives a selection list of the addresses assigned to it from which a selection can be made.

Each party is assigned to one or more address types which in fact describes the nature of the party, e.g. customer, bank, and so on. Each time an address field is to be filled in during a transaction, the particular field definition identifies which types of address can be used. Only those addresses permitted are included in selection lists.

There are two entry/display formats for addresses in transactions:

1. Direct Display
   
   The main parties to a contract are displayed directly in a business transaction - either in one, two or four lines. Only with a four-line display can the address block be entered directly. In all other cases, an address block that differs from one in the database is entered using the Details panel.
2. List of Additional Addresses
   
   Parties that are not explicitly displayed on one of the contract panels are automatically included in the list of additional addresses and can be edited via the appropriate grid.

When editing addresses in the transaction, the following icons are available for each address both in the direct (main) display and in the list display:

1. “Search/Detailed view”
   If no address has been selected, the search is activated. If an address has been selected, then the address details will be displayed. Additional details displayed are the type of participant-specific data that may be available, such as accounts, limits, mailing instructions, conditions, etc. Clicking on the [Info] button next to it will display this data in a grid. The address in question is stored in the database as the address of a participant or as an additional address for a participant.
2. “Editing”
   This can be used to edit the properties of an address, such as the default account or the contact person. If the address in the contract differs from the address stored in the database (indicated by a red pencil ) then the address from the database can also be copied into the contract.
   Also, if the address in the contract differs from the address mapped from the imported incoming message, it is indicated by a green pencil . By clicking the pencil, user could see both the addresses.
3. “Create”
   If temporary addresses are permitted, then these can be created using this icon.
4. “Structured Infotext”
   If Structured Infotext is activated in transaction Maintaining System Configuration, the Structured Infotext and Attachment(s) associated with the selected party is displayed. Further information is available in Maintaining Parties and Maintaining Categories.

If an address is entered manually (by entering the address on the subpanel “Create temporary <Party>”), the user is prompted to confirm whether the address is to be saved as so-called temporary address. If the request is confirmed, the address is stored as a temporary address under an internal code in the database. Later on, it can be retrieved from the database in the same way as a “normal” address.

In this context, multiple message types (like e.g. SWIFT-BIC numbers or TradeConnect IDs) can be entered directly on the panel. Address details are displayed on the “Authentication of Address” panel and can be edited in the editing transactions of the static data system.

A temporary address can be edited by clicking [ Modify] on the display panel for temporary addresses. The modification is stored directly. Thus, it remains available, even if the registration of the transaction is paused or canceled.

To retrieve an address from the database, either the number under which the party has been stored is entered, part of the name of the party or part of the BIC of the party are required. In the latter cases, a selection list is displayed, which relates to the information the user has entered, from which he can then make his choice. The respective information is then displayed in the field below.

These “parties” (also, “roles”) are set for each business sector and carry with them certain significances. These include the “applicant”, the “presenting bank”, etc. For each role there is a 3-digit code used to refer to the party in processing. These role codes are only displayed in the application when, for technical reasons, it is not possible to display the correct banking description of the role. The role is visible in the settlement transactions, for example, and in the summary of messages to be sent.

Valid roles are defined in the “ROLALL” codetable. There are various types of party/role:

These are the standard parties such as presenting bank, applicant, etc.

Some parties to a contract can simply be copies of another party, with the user deciding which party is to be copied. Alternatively, with such parties, a new address not previously entered in the contract can be used. With these parties, there is also a role field on top of the normal party data that controls which party can be copied. If the role field contains the value “FRE”, this is a new address entered in the contract. If the role field does not contain the value “FRE”, then the original address and the dynamic party will always be synchronized. Thus, if, for instance, the reference of the dynamic party is changed, this is copied back in the details of the original party.

Wherever possible, settlement panels and messages should always use dynamic parties to a contract instead of transferring the original party depending on the role field.

Typical dynamic parties include the “presenter of documents” (PRB) and the “party responsible for payment” (PYR).

These parties are distinguishable from dynamic parties by only being used in a single transaction and are not stored in the contract. A typical example would be the “recipient of a message” in xxxFRE transactions, for instance.