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.

Routing information, used as 'class' to identify groups of payment documents.

Unique INR of corresponding party address (PTA).

Actual amount, used for search functions and to make entries unique.

Complete no. of the check or part thereof. The user must enter this field in order to allow the system to search in the checkpool for contracts with ambiguous data.

This field is used to identify the payment document as unique. The reference field can be used to search for a payment document that is already stored in the database.

This field holds the descriptive name of the check entry displayed in the application to describe and to search for a contract.

This is the unique INR of the initiating transaction holding the specific CHK-information.

The field is normally empty. If set, it means that this check dataset is invalid and has to be replaced by another, newly captured dataset. This is a special case that can arise, for example, if a check has been assigned an incorrect check route or captured in the wrong presentation.

Contains the INR of the check contract (CHD), which handles the payment document in direction of the presenter. Normally this is the presentation contract, created in CHTOPN.

The field holds the INR of the contract used to send the check and the remittance to the collecting bank.

Date and Time of Creation of the CHK-dataset.

This field contains the date on which the payment document left the bank for the last time.

For example, the date is set if the payment document is sent to the collecting bank . When the payment document is returned by the collecting bank, the date is not deleted. When the payment document is returned to the presenter, the current date is entered.

This means that every time a payment document leaves the bank, the date is set and once the field has been filled, it is never deleted again. 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.

Contains the number of checks handled. For traveler checks this is the number of checks handled, for all other payment document types the value is '1'.

If not empty, this check is handled in a single remittance.

This field describes where the physical payment document (as 'paper') is currently located.

This field contains the number of future working days for which the Collecting Bank promised to pay the equivalent of remitted checks resp. authorized the sender of the checks to debit their account. The number of days entered will be used within the check-transactions to calculate future value dates.

This field represents the type of the payment document and is part of the determination for the collecting bank

This field is used within statistics and holds the country, where a payment document is payable.

This field contains the currency of the presented payment document.

This is the type of object the check entry refers to. This is the table the object is stored in (CHD).

A check presentation is distinguished between import and export checks. Export Checks are payment documents which are sent for collction 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.

This field is used to indicate the national clearing system code of the address. For example “CHIPS universal identifier” (US) or “CHAPS branch sort code” (UK).

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.

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.