Name | Helptext Description | Data Type | Len | Codetable |
---|---|---|---|---|
INR | Internal Unique ID | Text | 8 | |
OWNREF | Reference | Text | 16 | |
NAM | Name of Check Contract | Text | 80 | |
OWNUSR | Responsible User | Text | 8 | <fixed-length> |
OPNTRNINR | TRNINR which opened contract | Text | 8 | |
CREDAT | Date Created | Date | 12 | |
OPNDAT | Opening Date | Date | 12 | |
CLSDAT | Date Closed | Date | 12 | |
ORDDAT | Order Date | Date | 12 | |
RESFLG | Reserved Contract | Text | 1 | Embedded |
CHKTYP | Payment Document | Text | 1 | <fixed-length> |
CONTYP | Contract Type | Text | 1 | Embedded |
STACTY | Country Code (for Statistics) | Text | 2 | CTYTXT |
CHKCNT | Check Count | Numeric | 4 | |
VALDAY | Default Valuta | Numeric | 2 | |
FEECOD | Additional Fee | Text | 6 | |
VER | Version | Text | 4 | |
OPNVALDAT | Value Date for CHR booking | Date | 12 | |
DIRTYP | Direction | Text | 1 | Embedded |
COLUSE | Use Collecting Bank for all Checks | Text | 1 | |
CHKDAT | Date of Check | Date | 12 | |
ETYEXTKEY | Entity | Text | 8 |
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 contains the unique reference number of the check contract being established. The reference number can be up to 16 characters long and will be created during save of the initiating transaction. This field can be used to search for any check handling contract in the database.
The name of the contract will automatically be created when a new contract is stored in the database. Currency, amount, country and name of the remitter are part of the contract name. Any information within this field may be used for search within the info system.
This field holds the User ID of the person responsible for handling this contract.
This field holds the INR of the transaction which opened/issued the contract.
This date field identifies the date the entry was physically added to the database.
If a payment document is submitted by the presenter, this field will contain the opening date of the submission contract. If the payment document is forwarded to the collecting bank, this field will contain the opening date of the remittance. The field holds the opening/issuing date of the contract. If this field is set, the contract has been legally established and it might be used for business transactions. This date describes the point in time when this contract became legally binding. This might be a date prior to the creation date, when the contract was legally binding before it was stored in the database.
This fields indicates the closing date of a contract. If an entry has been made, the contract is closed and may no longer be used to process business transactions except special transactions like Settling Charges or Common Messages.
This field contains the order date of the check remittance from the remitter. Under a check remittance contract, i.e. if the payment documents are sent to the collecting bank, there will be no order date.
Contract status flag. If not empty, the contract has been reserved and only a few basic fields have to be filled in.
Code | Text |
---|---|
Normal Contract | |
X | Reserved Contract |
This field represents the type of the payment document, e.g traveller checks, order checks or debit notes. Based on this field, the country and currency of the payment document, a collecting bank is determined automatically when a check routing definition has been set up in the static data.
This field describes the kind of check contract: Differentiation is dones between Presentation (i.e. presentation of checks), Remittance (i.e. remittance of checks) and Special Handling.
Code | Text |
---|---|
P | Presentation |
R | Remittance |
B | Special Handling |
This field contains the country code of the collecting bank.
This field is for the total number of checks remitted by the presenter within a single remittance.
This field contains the number of future working days for which the Collecting Bank promised to pay the equivalent of remitted payment documents resp. authorized the sender of the payment documents to debit their account. The number of days entered will be used within the check-transactions to calculate future value dates.
This field is for foreign fees, i.e. Collecting Bank's fee. This fee will be charged to the Remitter of checks and credited to the Collecting Bank when the check presentation contract is opened. The charge is loaded from the check routing definition in the static data.
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.
The value date of the credit booking towards the remitter is stored in this field. The value date will be stored from the initializing transaction to be used again in future transactions. For example it will be used for return of payment documents to reverse booking entries.
A check presentation is distinguished between import and export checks. Export Checks are payment documents which are sent for collection to a bank abroad. Import Checks are payment documents which are sent by the bank using the application to the collecting bank which has issued the payment document.
Code | Text |
---|---|
E | Export |
I | Import |
For handling import check presentations, each check could have its own collecting bank. This can entered on the check panel. In case all checks are drawn on the same collecting bank, this checkbox can be checked. As a consequence, the collecting bank is set for all checks of the presentation.
This field contains the date of the individual check.
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.