Name | Helptext Description | Data Type | Len | Codetable |
---|---|---|---|---|
INR | Internal Unique ID | Text | 8 | |
OWNREF | Own Reference | Text | 16 | |
NAM | Name | Text | 80 | |
OPNTRNINR | TRNINR which opened contract | Text | 8 | |
CREDAT | Date Created | Date | 12 | |
ISSREF | L/C Number | Text | 16 | |
AMEDAT | Date of Last Amendment | Date | 12 | |
AMENBR | Number of Amendments | Numeric | 3 | |
AVBWTH | Available with | Text | 1 | AVBWTH |
AVBBY | Available by | Text | 1 | AVBBY0 |
CLSDAT | Date Closed | Date | 12 | |
CNFSTA |
This field holds the confirmation status of the reimbursement contract.
Possible Values: Y = reimbursement undertaking issued S = silent reimbursement undertaking issued '' = no reimbursement undertaking issued
This date field specifies when the L/C under which the reimbursement authorization is received, expires and therefore indicates the latest date for presentation of documents under the Letter of Credit. A reimbursement claim may be received after that date.
This field specifies where the L/C under which the reimbursement authorization is received, expires. The expiry place is closely linked to the expiry date as it specifies more detailed the place where documents have to be presented under the Letter of Credit.
This field further qualifies the contract amount and becomes important when checking documents presented under the contract. If the code “not exceeding” is used, no tolerance is permitted. If the code “according to UCP” is used, allowances are granted based on stipulations provided in Article 30 of the UCP.
Code | Text |
---|---|
N | NOT EXCEEDING |
X | Accord to UCP |
This field specifies the positive tolerance to the nominal amount of the underlying contract as percentage plus that amount. In order to calculate the maximum amount (e.g. the maximum risk of the bank), the positive tolerance amount is added to the nominal amount.
This field specifies the negative tolerance to the nominal amount of the underlying contract as percentage minus that amount.
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 holds the User ID of the person responsible for handling this contract.
This field holds the number of reimbursement claims received under the contract. The number is raised by 1 automatically with every new claim and is never reduced.
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 contains the information about by whom charges under the reimbursement authorization are payable.
Possible Values: “CLM” = our charges are payable by claiming bank “OUR” = our charges are payable by issuing bank
This field specifies whether the Reimbursmenet authorization is subject to the latest version of the Uniform Rules for Bank-to-Bank Reimbursements under documentary credits, issued by the International Chamber of Commerce.
In this field the user can select whether the confirmation of the reimbursement contract was requested by the issuing bank or the claiming bank.
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' (RMTPOP) and 'Info Reimbursement Authorisation' (INFRMD). Invisible in all other transactions.
Code | Text |
---|---|
Normal Contract | |
X | Reserved Contract |
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 holds the number of pending claims received under the reimbursement authorization. The number is automatically raised by 1 with every new claim received and decreased by 1 with every claim settled or closed unpaid.
This field indicates the risk country of the reimbursement undertaking. It is used for statistical reasons and allows the reimbursing bank to evaluate the country risks it may have entered by issuing an reimbursement undertaking.
This (invisible) field defines, whether the amount or the percentage has been confirmed in a partially-confirmed contract.
Based on this information, the percentage or amount is protected and calculated via on the other field.
Code | Text |
---|---|
A | amount is confirmed |
P | percentage is confirmed |
nothing is confirmed |
This field specifies the rules governing the reimbursement authorization.
Code | Text |
---|---|
URR LATEST VERSION | URR LATEST VERSION |
NOTURR | NOT SUBJECT TO URR |
Expiry Date of our reimbursement undertaking (confirmation)
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.
This fields contains the percentage of the partial reimbursement undertaking if any. It is enabled for user entries, only if a reimbursement undertaking has been issued by the bank using the application.
This field is automatically set when Cash Cover is booked on a 'hold account' under the reimbursement.
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.