RMD - Reimbursement Data

RMD is the main data table for the Reimbursement contract.
All technical important fields have to be defined here.
Large text blocks should be defined in RMT.

/

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 RMD. The field INR is used to enable links from other tables to this table. It also links the two tables RMD and RMT as associated entries hold the same 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 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 own reference number of the reimbursement authorization contract. The reference number can have a maximum size of 16 characters. This field can be used to search for any export letter of credit contract from the database.

This field contains the reference number of the Reimbursement.

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

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

This date field holds the date when the entry was physically added to the database. This may happen when opening the contract, when reserving the reference number or when, for other reasons, a contract is added to the database.

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

The reference of the issuing bank of the reimbursement authorization. This field is filled from PTS\REF of ISS.

This field contains the number of the L/C.

This field contains the date of the last amendment which has been processed under the reimbursement.

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 field counts the number of all initiated amendments under the Reimbursement Authorization. An amendment is initiated when the first transaction of an amendment is finally stored.

The field is technically incremented after loading of the contract in init of amending transactions.

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 field indicates the bank authorized to pay, accept, negotiate or incur a deferred payment for the L/C under which the reimbursement authorization is received.

This field contains the bank/role that is authorized to pay, accept, negotiate or transfer an obligation under a deferred payment for the contract.

This field indicates whether the L/C under which the reimbursement authorization is received, is available by sight payment, deferred payment, acceptance, negotiation or mixed payment.

This field indicates whether the contract is available by sight payment, deferred payment, acceptance, negotiation or mixed payment.

This fields holds the closing date of a contract. If this field is set, the contract is closed and may no longer be used for transaction processing of business transactions. The date specifies the date when the closing took place.

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 holds the confirmation status of the reimbursement contract.

Possible Values: Y = reimbursement undertaking issued S = silent reimbursement undertaking issued = no reimbursement undertaking issued == Helpinformation == 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 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 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 documentary credit amount under which the reimbursement authorization is received. If the code “not exceeding” is used, no amount tolerance is allowed. If the code “according to UCP” is used, allowances in credit amount are granted according to what is stipulated in article 39 of the UCP.

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.

This field specifies the positive tolerance to the documentary credit amount under which the reimbursement authorization is received as percentage plus that amount. In order to calculate the maximum amount (e.g. the maximum risk of the advising bank), the positive tolerance amount is added to the document amount.

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 documentary credit amount under which the reimbursement authorization is received as percentage minus that 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 a 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.

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 who is responsible for handling this contract. This field is an optional field. Within Demobank it is initially filled with the user ID of the user creating/opening the contract.

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 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 to keep track of the version history of an RMD 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.

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 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 Reimbursement authorization is subject to the latest version of the Uniform Rules for Bank-to-Bank Reimbursements under documentary credits, International Chamber of Commerce, Paris, France, which are in effect on the date of issue.

Content of URR Article 7: If subject to Article 7 this means that the reimbursement authorization is NOT linked to the validity of the Letter of Credit.

Therefore flag can only be set if APPRULRMB = URR. If not subject to Article 7 (ERAFLG empty), the Expiry Date must be entered.

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, contract is reserved. That means, only a few basic fields have to be filled in. Visible on RMTP in RMTPOP and INFRMD. Invisible in all other transactions.

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.

The field can be used for statistical reasons and allows the reimbursing bank to evaluate reimbursement authorizations by the types of goods that were shipped under the L/C. The codetable for this field can be customized by the bank according to their needs.

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 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 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, if the amount or the percentage is confirmed in a partially confirmed contract.

Based on this information, the percentage or amount are protected and calculated from the other field.

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.

This field specifies the rules the credit is subject to (for reimbursements).

This field specifies the rules governing the reimbursement authorization.

This field holds the Expiry Date of our reimbursement undertaking (confirmation)

Expiry Date of our reimbursement undertaking (confirmation)

Set in RMTPOP, if incoming message is rejected / contract closed directly.

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

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.

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 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

This field is automatically set when Cash Cover is booked on a 'hold account' under the reimbursement.

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

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

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 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 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.

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.