This table holds diary entries which are usually associated to a
contract and to a user or a user group. These entries reflect
actions to be taken on certain dates.
| Name | Description | Data Type | Len | Dec. | View lines | View type | Inst. | Visible | Codetable |
|---|---|---|---|---|---|---|---|---|---|
| INR | Internal Unique ID of Diary | Text | 8 | 1 | Edit | Yes | Public | ||
| OWNUSG | Responsible Group | Text | 6 | 1 | Edit | Yes | Public | USGTXT | |
| OWNUSR | Responsible User | Text | 8 | 1 | 20 | Edit | Yes | Public | <fixed-length> |
| OBJTYP | Contract Type (Optional) | Text | 6 | 1 | Edit | Yes | Public | ||
| OBJINR | Contract INR (Optional) | Text | 8 | 1 | Edit | Yes | Public | ||
| OBJREF | Contract Own Reference (Optional) | Text | 16 | 1 | Edit | Yes | Public | ||
| DAT | Date of Diary | Date | 12 | 0 | Date | Yes | Public | ||
| COD | Coded Reason | Text | 3 | 1 | Edit | Yes | Public | DIATXT | |
| NAM | Name | Text | 50 | 1 | Edit | Yes | Public | ||
| FRM | Transaction to be Called | Text | 6 | 1 | Edit | Yes | Public | ATPTXT | |
| INFDSP | Info | Text | 1 | 1 | Edit | Yes | Public | INFDSP | |
| INFTXT | Infotext | Block | 65 | 4 | 4 | Block | Yes | Public | |
| USR | Entered by | Text | 8 | 1 | Edit | Yes | Public | ||
| CRETYP | Created by Object Type (TRN) | Text | 6 | 1 | Edit | Yes | Public | ||
| CREINR | Created by INR | Text | 8 | 1 | Edit | Yes | Public | ||
| DONFLG | Entry Done (Nonspace = Entry Done) | Text | 1 | 1 | Edit | Yes | Public | ||
| AUTFLG | Automatic processing Flag | Text | 1 | 1 | Edit | Yes | Public | ||
| FREROL | Role of the contract to be used for a free message | Text | 3 | 1 | Edit | Yes | Public | ||
| DIATYP | Type of Diary | Text | 6 | 1 | Edit | Yes | Public | ||
| SUBID | Sub ID of a Diary of equal Type | Text | 2 | 1 | Edit | Yes | Public | ||
| FLDMODBLK | List of Modified Fields in TRNDIA | Block | 6 | 25 | 25 | Block | Yes | Public | |
| SUBTYP | Subtype (Optional, e.g. PTE) | Text | 6 | 1 | Edit | Yes | Public | ||
| SUBKEY | KEY of Subobject (Optional, e.g. Tenor ID) | Text | 40 | 1 | Edit | Yes | Public | ||
| ORDINR | INR of Order | Text | 8 | 1 | Edit | Yes | Public | ||
| VER | Version Counter | Text | 4 | 1 | Edit | Yes | Public | ||
| DELNOTFLG | Do not automatically set to Done | Text | 1 | 1 | Edit | Yes | Public | ||
| ETYEXTKEY | Entity holding Diary | Text | 8 | 1 | Edit | Yes | Public |
| Name | Fields | Properties |
|---|---|---|
| DIA_CRE | CRETYP, CREINR | |
| DIA_DAT | DAT, DONFLG | |
| DIA_DAT | ETYEXTKEY, DAT, DONFLG | |
| DIA_INR | INR | Unique |
| DIA_NAM | ETYEXTKEY, NAM | |
| DIA_NAM | NAM | |
| DIA_OBJ | OBJTYP, OBJINR | |
| DIA_OWNUSG | OWNUSG | |
| DIA_OWNUSR | OWNUSR |
/
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 DIA. 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.
User group responsible to handle this diary entry. This field has to be set and handled according to the handling of USFMOD which handles the user definable filters.
This field identifies the user group responsible for this diary entry.
The user who is responsible for handling the diary entry. This field has to be set and handled according to the handling of USFMOD that handles the filters, which can be defined by the user.
This field holds the User ID of the person responsible for this diary entry.
If a contract is associated to the diary entry, the table ID of the contract is specified in this field. In this case the INR is stored in the field OBJINR and the reference number of the contract is stored in the field OBJREF.
If a contract has been associated to the diary entry, the table ID for the contract is specified in this field. In this event, the identification number is stored in the Object INR field and the reference number of the contract is stored in the Contract Own Reference field.
If OBJTYP is filled, a contract is associated. In this case this field holds the INR identifying the contract.
If the Object Type field has been filled in, there is a holding contract. In this event, this field holds the identification number to identify the contract.
If OBJTYP is filled, a contract is associated. In this case this field holds the reference number of the contract (usually OWNREF in the contract).
If the Object Type field has been filled in, there is a holding contract. In this event, this field holds the reference number of the contract (usually the Own Reference in the contract).
This field holds the target date of a diary entry.
This field holds the target date of a diary entry.
This code describes the user defined resubmission code which might be used for selection of diary entries. The associated codetable is modifiable by the bank and can be adopted to the needs of the specific installation.
The technical identification for automatic creation, maintenance and deletion of diary entries is done via the different field DIATYP.
This code describes the user defined resubmission code which might be used for selection of diary entries. The associated codetable can be modified by the bank and can be adopted to the needs of the specific installation.
The technical identification for automatic creation, maintenance and deletion of diary entries is done via the Type of Diary field.
A descriptive name of the diary entry. In manually created entries, this is an initially empty, descriptive field. On automatically generated entries, this field is automatically filled by the application with a descriptive text and might be modified later on.
The name of the diary entry used when displayed.
This field holds the optional transaction ID, which should be started when handling the diary entry.
This field holds the optional transaction ID which is started when working on the diary entry.
Flag to mark, whether the infotext of the field INFTXT should be displayed when processing the diary entry. Any non-blank entry will prompt the infotext before processing the diary entry.
This is a flag that marks whether information in the Infotext field should be displayed when the diary entry is used in daily processing.
This field holds an optional infotext. The handling of this infotext is controlled by the flag INFDSP.
This field is used to store any relevant information about the object.The information will be displayed to the user during daily processing, if the display info flag has been activated.
The user who entered or created this diary implicitly or explicitly, is available here.
The field identifies the user who entered or created this diary, either implicitly or explicitly.
Optional object type of the creating transaction. Currently this is either blank or fixed “TRN”.
This is an optional object type of the creating transaction. Currently this is either blank or fixed as “TRN”.
The INR identifying the object, which created this diary entry, in case CRETYP is not empty. As currently only TRNs might create diary entries this field holds the TRN\INR of the creating transaction, if CRETYP is not empty.
The field defined the identification number (INR) identifying the object, which created this diary entry (if the Created by Object Type field is not empty). As currently only TRNs might create diary entries this field holds the ID of the creating transaction.
Setting this field to a non-space value marks this entry as 'done'.
Setting this field to a non-space value marks this entry as 'done'.
This field holds the version counter to keep track of the version history of a diary 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.
Field to technically identify automatically generated diary entries to be able to maintain and/or delete those under program control. This field has to match to the codes used in the DiaSav rules implemented in the specific installation. For documentation purposes the embedded codetable is intended to be used to keep a list of all used codes. The delivered codetable describes the used codes of the MyModelbank. DIATYP together with SUBID has to be a unique key to identify all automatically generated entries within a contract. Manually created entries are marked with the special code 'MANUAL' and are not automatically maintained. The user-visible identification of different types of diary entries is done via the different field COD. Following types are used in MyModelbank: ORDREC - Order received EXPWRN - Will expire EXPIRE - Expired RAMPEN - Pending Request of Amendment FOLQUE - Reply to Query pending FOLPEC - Follow up 'pay or extend claim' EXPRMB - Expiry DOCACP - Documents accepted ? DOCREC - Documents received DOCMAT - Settlement to be prepared DRDREC - Export L/C received ? FOLCAS - Call actual status
Field to technically identify automatically generated diary entries in order to be able to maintain and/or delete those under program control. The respective codetable describes the codes used in the MyModelbank. The following types are used in the MyModelbank: ORDREC - Order received EXPWRN - Will expire EXPIRE - Expired RAMPEN - Pending Request of Amendment FOLQUE - Reply to Query pending FOLPEC - Follow up 'pay or extend claim' EXPRMB - Expiry DOCACP - Documents accepted ? DOCREC - Documents received DOCMAT - Settlement to be prepared DRDREC - Export L/C received ? FOLCAS - Call actual status
The field SUBID is used to uniquely identify multiple entries with the same DIATYP within a contract. It is implemented as a counter with a maximum value of 99.
It is needed to handle manually diaries or multiple diaries of the same DIATYP (e.g. after several xxFRE transactions).
This field is used to uniquely identify multiple entries of the same diary type in a contract. Basically, this It is a counter with a maximum value of 99.
List of modified fields of this DIA entry to keep track of all modifications in the past. Used in SetModFldinRec and GetModFldinRec.
When adding new fields, please note that the number of LINES is increased accordingly.
A list of modified fields for this entry used to keep track of all past modifications.
If a subobject (e.g. PTE) is associated to the diary entry, the table ID is specified in this field. In this case the INR is stored in the field SUBKEY.
If a subobject (e.g. one line of liability) is associated to the diary entry, the table ID (i.e. PTE) is specified in this field.
If SUBTYP is filled, an object (e.g. PTE) is associated. In this case this field holds the key identifying that object.
Filling in the Subtype field associates the field to an object (e.g. one line of liability). In this event this field holds the key that identifies that object.
This table is defined on entity level with separate entries for each entity. This field holds the EXTKEY of the owning entity 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 are visible to the user.
This field holds the external key of the owning entity 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 are visible to the user.
Reference to the order that is created to handle this diary entry, typically filled by QUETSK on activation.
ORDINR does _not_ reference the triggering order leadin to this diary, this this field remains empty when a DIA record is created.
Reference to the order opened to handle the diary event. This field is filled when starting QUETSK.
When set to a non space value, this diary will be automatically processed.
When this flag is set, the diary is set to be processed automatically.
This optional field might hold a role id, which shall be used in the free message target transaction.
This optional field might hold a role id, which shall be used in the free message target transaction.
This flag defines, if a diary entry has to be closed manually.
The checkbox can be set anytime during the lifecycle of the contract. When set, the diary entry will not be closed automatically when the contract is closed.