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 reference number of the import collection (BC = Bills for Collection) being established. The reference number can be up to 16 characters long. This field should be defined as a database key field to optimize performance. It can be used to search for a BC from the database.

This field holds the descriptive name displayed in the application to describe and to search for a contract. Within the standard version, this field is set by a default rule based on the contract amount and main party and cannot be modified by the user.

This flag indicates the name of the person requesting the release of the goods.

This field holds the INR of the transaction which opened/issued the contract.

This date specifies when the bank using the application issued the release of goods.

This field contains the date on which the documents were received by the collecting bank (date of receipt stamp).

This field contains the order date/date of the remittance letter of the drawer (or a remitting bank before the bank using the application).

This field contains the date of shipment as per the transport document presented.

This date field identifies the date the entry was physically added to the database.

This field contains the date when the documents were advised to the drawee (or a second collecting bank).

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 specifies the date when the usance documents are due for payment.

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 field specifies the type of collection, e.g. whether sight or usance documents have been presented.

This field is required for the documentary collection and specifies part of the maturity period. The maturity period indicates when documents are due for payment (in text). The maturity period consists of 3 fields. Together, these fields represent the maturity period, from which the maturity date of the collection can be calculated.

This field is required for the documentary collection and specifies part of the maturity period. The maturity period indicates when documents are due for payment (in text). The maturity period consists of 3 fields. Together, these fields represent the maturity period, from which the maturity date of the collection can be calculated.

This field is required for documentary collection and specifies part of the maturity period. The maturity period indicates when documents are due for payment (in text). The maturity period consists of 3 fields. Together, these fields represent the maturity period, from which the maturity date of the collection can be calculated.

This field holds the User ID of the person responsible for handling this contract.

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.

This field indicates the type of transport document (e.g. bill of lading, air waybill etc.) which is presented under this collection.

This field indicates the number of the transport document (e.g. number of bill of lading, air waybill).

This field indicates the date of the transport document (e.g. bill of lading, air waybill) which is presented under this collection.

This field indicates how the goods have been shipped (e.g. via sea, air or a combination of different transport modes).

This field specifies the place of transfer (in the case of a multimodal transport document), the place of receipt (in the case of a road, rail or inland waterway transport document or a courier or express delivery service document), the place of dispatch or the place of shipment to be indicated on the transport document.

This field specifies the final destination of the goods shipped under the underlying contract.

This field defines whether the fees and commissions of the bank using using the application is to be borne by the drawee side or 'borne by client' (='U'), of the issuer side or 'borne by abroad' (='B') or by other parties. Depending on the selection made in this field, the roles in the second settlement table (own commission / fees) are proposed.

Meaning 'borne by client': If, in the fee settlement field, 'borne by client' was selected or if the field is not completed, then own fees will be proposed in the settlement to the debit of the drawee SIDE. (In the case of import collections, the DRE or CO2 would be available).

Meaning of 'borne by abroad': Own fees in the settlement are proposed to the debit of the issuer SIDE (In the case of an import collection, the DRR or RMI would thus be available).

Meaning of 'Others': No role is proposed on the fees in the settlement panel.

This field contains instructions on how long a payment can be deferred by the drawee.

The field is defaulted with the country code of the remitting bank, being the sender of the collection. It can be used for statistical purposes.

This field contains the type of goods shipped. The goods code is used to evaluate contracts by the type of goods. The codetable can be customized by the bank according to their needs.

This field contains the date when usance documents were accepted by the drawee. If the contract is financed, this date is defaulted to be the starting date of the financing.

This field is used to store the number of amendments made to the contract so far. This field is automatically updated from the relevant amendment transaction.

This flag indicates that the documents are accompanied by a draft which is to be guaranteed by the bank using the application. If done so, the bank undertakes a liability and the liability booking is handled accordingly.

This field is used to differentiate whether goods are released under shipping guarantee or air waybill, etc.

If a shipping guarantee is issued under the import collection, this date specifies the expiry date of the shipping guarantee.

If this flag is set, goods are released to the drawee. Otherwise, goods can be released to another party entered in 'Release to Address'.

This field is set to a non-empty value, if the document set holds more than one tenor.

This field specifies whether the documents are handled free of payment, i.e. whether documents are presented to the drawee without him having to pay for them.

This field indicates whether the collecting bank's charges may be refused upon payment of the collection.

This field indicates whether the remitting bank's charges may be refused upon payment of the collection.

This flag indicates that the original documents have been presented to the drawee ('Original Documents Passed to Drawee'). The flag is set when the contract is issued e.g. ('Advising Documents'), with the documents being paid later ('Accept and Settle Documents').

Banks will only allow their best customers to receive the original documents without paying for them.

If the documents are presented in a 2nd mail, these original the documents may also be sent to the drawee directly. This is handled in the transaction 'Advising Documents in 2nd Mail'.

When documents are sent directly, the liability is booked to the account of the drawee.

The current status of the document set is stored in this field.

Contract status flag. If not empty, the contract has been reserved and only a few basic fields have to be filled in. Visible in 'Pre-Opening an Import Collection' (BCTPOP) and 'Info Import Collection' (INFBCD). Invisible in all other transactions.

This field contains the date of the agent's invoice. If entered, the information is mapped to tag 43C of the outgoing T40 TradeConnect message.

This field contains the date of the last amendment processed under the contract. If it is empty the contract is still in its original condition. This date is automatically updated by the relevant amendment transactions.

This flag is used to indicate whether the collection underlies the “Uniform Rules for Collection” or not. When the flag is checked, it means that the URC apply. his field is used to display the fact that the collection is subject to the Uniform Rules for Collections (URC). If the box is checked, the outgoing correspondence will contain a paragraph refering to the URC.

This flag is set in the (pre)opening transaction in case an incoming message is rejected. The contract is closed directly.

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.

Initial version to support the differentiation of predefined bank products cross business sectors. This organizational solution is made up of three fields PRDCOD, PRDSUB and PRDVAR providing a bank product, a sub differentiation and individual variants if needed. Here the PRDCOD shall identify the business sector together with some key criteria like confirmed or unconfirmed LC in a cross business sectors unique identification.

Initial version to support the differentiation of predefined bank products cross business sectors. This organizational solution is made up of three fields PRDCOD, PRDSUB and PRDVAR providing a bank product, a sub differentiation and individual variants if needed. Here the PRDSUB shall identify the business sector specific bankside defined products adding some key sub criteria in a cross business sectors unique identification.

Initial version to support the differentiation of predefined bank products cross business sectors. This organizational solution is made up of three fields PRDCOD, PRDSUB and PRDVAR providing a bank product, a sub differentiation and individual variants if needed. Here the product variant is intended as possible extension to setup specific variants below the product and subproduct code.

The bank using DOKA must issue the ALADI Reimbursement code on customer request when a contract is opened.

This flag will be visible only if entity group is in the LATAM region.

Also, this will be enabled for input only if the current entity has an ALADI member ID and the counter-party bank is also defined as an ALADI member in the party table.

Checking this flag denotes this contract is under ALADI Inter-bank Settlement and therefore: a) System auto generates the ALADI Reimbursement code for (Import LC and Export Collection contracts). b) System allows the user to manually input the ALADI Reimbursement code for (Export LC and Import Collection contracts)

Alternate reference number. I.e. old reference if contract is migrated from another system.