This table holds the links of addresses associated to a party, as a single party might have many usable addresses.
Name | Description | Data Type | Len | Dec. | View lines | View type | Inst. | Visible | Codetable |
---|---|---|---|---|---|---|---|---|---|
INR | Internal Unique ID of Party Address Association | Text | 8 | 1 | Edit | Yes | Public | ||
PTYINR | INR of Associated Party | Text | 8 | 1 | Edit | Yes | Public | ||
NAM | Externally Visible Name of Address | Text | 40 | 1 | Edit | Yes | Public | ||
PRI | Priority Marker | Text | 1 | 1 | Edit | Yes | Public | ||
ENO | Running Counter for External Identification | Text | 3 | 1 | Edit | Yes | Public | ||
OBJTYP | Type of Associated Address | Text | 6 | 1 | Edit | Yes | Public | ||
OBJINR | INR of Associated Address | Text | 8 | 1 | Edit | Yes | Public | ||
OBJKEY | Alternate Technical Key of Associated Address | Text | 24 | 1 | Edit | Yes | Public | ||
USG | Coded Usage of Address [xxxxxx] | Text | 3 | 1 | Edit | Yes | Public | Embedded | |
VER | Version Counter | Text | 4 | 1 | Edit | Yes | Public | ||
BIC | BIC of Address (Optional) | Text | 11 | 1 | Edit | Yes | Public | ||
ADRSTA | Address Status | Text | 1 | 1 | Edit | Yes | Public | Embedded | |
PTYTYP | Type of Party | Text | 15 | 1 | Edit | Yes | Public | ||
PTYEXTKEY | External Key Used to Uniquely Identify a Party | Text | 24 | 1 | Edit | Yes | Public | ||
TID | TradeConnect ID | Text | 23 | 1 | Edit | Yes | Public | ||
LOCCTY | Country of Domicile | Text | 2 | 1 | Edit | Yes | Public | CTYTXT | |
CLC | Clearing Code (for Banks) | Text | 35 | 1 | Edit | Yes | Public | ||
BICTAR | BIC of Address (Optional) Target2 Address | Text | 11 | 1 | Edit | Yes | Public | ||
SGPFLG | Party with sanctions | Text | 1 | 1 | Edit | Yes | Public | ||
LEI | Legal Entity Identifier | Text | 20 | 1 | Edit | Yes | Public | ||
ETGEXTKEY | Entity Group of Party Address Association | Text | 8 | 1 | Edit | Yes | Public | ||
GETFLDNRM | Field holding the normalized search fields | Text | 115 | 1 | Edit | Yes | Public |
Name | Fields | Properties |
---|---|---|
PTA_ADRSTA | ADRSTA | |
PTA_BIC | BIC | |
PTA_ETGEXTKEY | ETGEXTKEY | |
PTA_GETFLDNRM | GETFLDNRM | |
PTA_INR | INR | Unique |
PTA_NAM | NAM | |
PTA_OBJ | OBJINR, OBJTYP | |
PTA_OBJKEY | OBJKEY | |
PTA_PTYEXTKEY | PTYEXTKEY | |
PTA_PTYINR | PTYINR | |
PTA_PTYTYP | PTYTYP |
/
INR
Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter PTA. The field INR is used to maintain links from other tables into this table.
Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter of this table. The field INR is used to enable links from other tables to this table.
For contractdata the INR also links the two tables xxD and xxT as associated entries hold the same INR.
This field is used to define the identification number (INR) of the Party associated with this address. N.B.: Each address in the database is associated with a Party. Party refers to a legal entity. Each Party has at least one address associated with it, and a Party can have several addresses or locations.
Replicated copy of the column NAM of the ADR table or an otherwise created field used to describe the address.
Replicated copy of the Name column of the ADR table or an otherwise created field used to describe the address.
If multiple addresses are assigned to a party, the priority marker is used to designate an address as the main address for party. This address will then be taken for corresponding with the party in daily processing.
If multiple addresses have been assigned to a party, the counter shows the serial number of the current address associated to the party.
This field holds the table the associated address is stored in. Usually = “ADR”.
The object type designates the table name or some other descriptions that display the storage space of the addresses assigned to a party The default setting is ADR (internal address file of the application) The object type can vary if the addresses are not stored in an ADR file, for instance, but on a HOST computer or some other systems.
INR of the object stored in the table identified by OBJTYP. If this table has no INR this field is not used and the OBJKEY field is used to identify the entry in that table.
Unique ID (INR) of the object stored in the table identified by the Object Type field.
Primary key of the object stored in the table identified by OBJTYP. If this table has no INR this field is used to identify the entry in that table. In case the table has an INR the field should hold a replicated copy of the EXTKEY or a similar field used to identify the address.
AThis specifies the primary key of the object stored in the table identified by the Object Type field. If this table, however, has no identification number (INR) this field is used to identify the entry in the table. If the table does have an INR, the field holds a copy of the External Key or a similar field used to identify the address.
This field is used to specify the type of usage for the associated address. “Add. Local address” will enable the usage of the additional address only locally whereas “additional address” enables the usage of the additional address similar to the usage of the party.
Code | Text |
---|---|
MAA | Main Address |
MAB | Additional Address |
This field holds the version counter to keep track of the version history of a PTA entry. The individual versions are controlled by entries in the SLG table.
This field holds the version counter used to keep track of the history of an entry of this table. The individual versions are managed by entries in the SLG table.
Replicated copy of the column of the ADR table.
This field contains the optional ISO bank identifier code (BIC) of the address. Searching within a table is usually be done by entering parts of this field. All matching records are usually displayed to enable the selection of the desired address.
The BIC is used to uniquely identify the address in all S.W.I.F.T messages. The SWIFT BIC is made up of a maximum of 11 characters, and a minimum of 8 characters.
Copy of the column from the ADR table.
Replicated copy of the column of the PTY table.
This field identifies the IT-status of the party. If the field is empty, the party might be used as a normal party. Normally it is a party loaded from the host system. If this field is non-empty, the party is not loaded from the host system and should not be used for accounting purposes. It might be a locally created party (used in many contracts) or a temporarily created party (should normally be used in one contract).
Copy of the column from the PTY table.
Code | Text |
---|---|
T | Temporary |
Downloaded |
Replicated copy of the column of the PTY table.
Copy of the column from the PTY table.
Replicated copy of the column EXTKEY of the PTY table.
Copy of the External Key column from the PTY table.
Replicated copy of the column of the ADR table.
Copy of the column from the ADR table.
This field contains the name of the country for the address.
This field contains the code of the country for the address.
This field is used to indicate the national clearing system code of the address. E.g.: CHIPS universal identifier (US) , or CHAPS branch sort code (UK), etc . Exception: German BLZ should additionaly be entered to the separate field BLZ. Reason: BLZ has been defined in pre-IBAN-times to handle the german Bankleitzahl. When dealing with IBAN account numbers all clearing codes are expected the field CLC.
This field is used to indicate the national clearing system code of the address. E.g.: CHIPS universal identifier (US) , or CHAPS branch sort code (UK), etc . Exception: German BLZ should additionally be entered to the separate field BLZ. Reason: BLZ has been defined in pre-IBAN-times to handle the german Bankleitzahl. When dealing with IBAN account numbers all clearing codes are expected the field 'Clearing Code'.
This table is defined on entity group level with separate entries for each entity group. This field holds the EXTKEY of the entity group which is the logical owner of this entry. This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the entity group of the currently active entity are visible to the user.
This field holds the external key of the owning entity group to identify the logical owner of this entry. This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity group are visible to the user.
Replicated copy of the column of the ADR table.
Replicated copy of the column of the ADR table.
Field holding the concatenated and normalized sum of all search fields used by quick search. This is one of the fields set in a SdbSetNRMFields method defined in the table definition module.
Field holding the concatenated and normalized sum of all search fields used by quick search. This is one of the fields set in a SdbSetNRMFields method defined in the table definition module.
If this flag is not empty this party is a sanctioned party. This make a warning popup in business transactions. X = ticked empty = not ticked
If this flag is not empty this party is a sanctioned party. This make a warning popup in business transactions. X = ticked empty = not ticked
LEI is an important (but not mandatory) identifier for ISO.
The ISO 17442 standard defines the Legal Entity Identifier (LEI). It is a unique 20-character alphanumeric code assigned to all entities that are counterparties to financial transactions. The code itself is neutral, with no embedded intelligence or country codes that could create unnecessary complexity for users.
It should primarily be used as identifier for corporates. For banks the main identifier code should always be a BIC.
LEI is an important (but not mandatory) identifier for ISO.
The ISO 17442 standard defines the Legal Entity Identifier (LEI). It is a unique 20-character alphanumeric code assigned to all entities that are counterparties to financial transactions. The code itself is neutral, with no embedded intelligence or country codes that could create unnecessary complexity for users.
It should primarily be used as identifier for corporates. For banks the main identifier code should always be a BIC.