BOD - Export Collection Data

BOD is the main data table for the Export Collection contract.
All technical important fields have to be defined here.
Large text blocks should be defined in BOT.

/

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 BOD. The field INR is used to enable links from other tables to this table. It also links the two tables BOD and BOT as associated entries holding 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 reference number of the export collection being established. The reference number can have a maximum size of 16 characters. This field can be used to search for any export collection from the database.

This field contains our reference number for this collection.

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 descriptive name displayed in the application to describe and to search for a contract. Within the default configuration, this field is set by a default rule based on the contract amount and the main party and cannot be modified by the user.

This field contains the reference of the agent as received in the incoming TradeConnect T41 message.

This field contains the agent's reference as received in the incoming TradeConnect T41 message.

This field contains the account of the agent as received in the incoming TradeConnect T41 message.

This field contains the agent's account as received in the incoming TradeConnect T41 message.

This field contains the commission of the agent as received in the incoming TradeConnect T41 message.

This field contains the agent's commission as received in the incoming TradeConnect T41 message.

TAG 44C (Shipment Date) of incoming T41 TradeConnect message

Date of shipment TAG 44C (Shipment Date) of incoming T41 TradeConnect message

Date on which the bank using the application has received the collection order from the customer (e.g. drawer). PREDAT is the date of receipt stamp, NOT date of customer order - that is RCVDAT.

Date when the bank using the application has received the collection order from the customer (e.g. Drawer). The presentation date is the date of the receipt stamp and NOT the date of the customer order - that is the order date of the documents.

This field contains the order date of the presenter (e.g. drawer or a remitting bank before the bank using the application).

This field contains the order date of the presenter (e.g. drawer or a remitting bank before the bank using the application).

The field holds the opening 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 contains the date on which documents have been sent out to the collecting bank/drawee and the export collection is opened.

This field contains the date on which documents were sent to the collecting bank/drawee and the export collection was created.

This field is required for clean and documentary collection and specifies the date when the relevant documents are due for payment.

This field is required for clean and documentary collections and specifies the date when the relevant documents are due for payment.

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

This field specifies the type of collection, e.g. whether sight or usance documents have been presented.

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: MATPERCNT - MATPERTYP- MATPERBEG (such as 90 - days -after sight) Together, these fields present the maturity period, from which the maturity date of the collection can be calculated.

This field is required for documentary collections 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 present 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: MATPERCNT - MATPERTYP- MATPERBEG (such as 90 - days -after sight) Together, these fields present 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 present 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: MATPERCNT - MATPERTYP- MATPERBEG (such as 90 - days -after sight) Together, these fields present 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 present the maturity period, from which the maturity date of the collection can be calculated.

This field is relevant for documentary collections only. It indicates the type of transport document (e.g. bill of lading, airway bill etc.) which is presented under this collection.

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

This field is relevant for documentary collections only. It indicates the number of the transport document (e.g. number of bill of lading, airway bill).

This field is relevant for documentary collections only. It indicates the number of the transport document (e.g. number of bill of lading, air waybill).

This field is relevant for documentary collections only. It indicates the date of the transport document (e.g. bill of lading, airway bill) which is presented under this collection.

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

This field is relevant for documentary collections only. It indicates how the goods have been shipped (e.g. via sea, air or a combination of different transport modes).

This field is relevant for documentary collections only. It indicates how the goods have been shipped (e.g. via sea, air or a combination of different transport modes).

TAG 44A (Shipment From) of incoming T41 TradeConnect message

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.

TAG 44B (Shipment To) of incoming T41 TradeConnect message

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

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

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 field indicates whether the remitting bank's charges may be refused upon payment of the collection.

This field defines whether the charges and commissions of the issuing bank are borne by the drawer side (=“U”), by the drawee side (=“B”) or others. According to the selection entered in this field, the roles in the second settlement grid (own commission/charges) are defaulted.

This field defines whether the fees and commissions of the bank using using the application is to be borne by the issuer side or 'borne by client' (='U'), of the drawee 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 abroad': If, in the fee settlement field, 'borne by client' was selected or if the field is not completed, then the own fees will be proposed in the settlement to the debit of the issure SIDE. (In the case of export collections, the RMI or DRR would thus be available).

Meaning of 'borne by abroad': Own fees in the settlement are proposed to the debit of the drawee SIDE (In the case of an export collection, the COL or DRE would thus be available).

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

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

The field is defaulted with the country code of the risk country of the collecting bank, as the receiver of the collection. It can be used for statistical purposes.

This field contains the genus of goods shipped under the export collection. This field 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 date field holds the date when the entry was physically added to the database. This may happen when (pre)opening the contract, when reserving the reference number or when, for other reasons (such as data migration), a contract is added to the database.

This date field identifies the date the entry was physically added to 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 version counter to keep track of the version history of a BOD 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 specifies if the documents are handled free of payment, meaning that the documents are presented to the drawee without him having to pay for them. In German, this is called “Dokumente ohne Zahlung/wertfrei aushändigen”.

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

If not empty, this flag indicates that documents are presented directly to the drawee.

If filled, the documents are sent directly to the drawee (importer) by the issuer (exporter). The bank using the application is instructed to process payment.

This field is required for Clean Collections only.

(Clean collection: In case financial documents (such as bill of exchange, checks etc.) and no transport documents are presented for collection.)

The bank can choose to pay the clean collection amount the drawer prior to having received the funds from the collecting bank. This is called “payment under reserve”, as the bank reserves the right to debit the drawer if no funds are received from the collecting bank.

If payment under reserve is selected, a credit payment is made to the drawer side, while the internal account of the bank using the application (OWN) is debited in the contract issuing transaction (BOTSCC). Upon receipt of funds lateron (e.g. in BOTPAY), the collecting bank side is debited and the internal account of the bank using the application is credited.

This field is required for Clean Collections only.

(Clean collection: when financial documents (such as bill of exchange, checks etc.) and no transport documents are presented for collection.)

The bank can choose to pay the clean collection amount to the drawer prior to having received the funds from the collecting bank. This is called “payment under reserve”, as the bank reserves the right to debit the drawer should no funds be received from the collecting bank.

If payment under reserve is selected, a credit payment is made to the drawer side, while the internal account of the bank using the application (OWN) is debited in the contract issuing transaction ('Sending a Clean Collection'). When funds are subsequently received (e.g. in 'Accept and Settle Documents'), the collecting bank is debited and the internal account of the bank using the application is credited.

If not empty, this flag indicates that financial documents are kept with the remitting bank (bank using the transaction) and are not presented to the collecting bank.

Under bilateral agreements between the banks they may actually send only an electronic message with all relevant information of the financial document(s) and hold on to the actual document just in case there are problems to collect it. This is called “Truncation”. The drawee knows about the documents drawn against him and will pay against a receipt from his bank. This way the transactions can be handled much faster and much more cost efficient compared to the use of paper documents, that have to be mailed via the collecting bank to the drawee abroad.

The used electronic message can be a SWIFT MT 405. A SWIFT MT405 is currently not supported in DOKA, as this message can only be used by banks that subscribe to the Message User Group (MUG).

If not empty, this flag indicates that financial documents are kept with the remitting bank (bank using the application) and are not presented to the collecting bank.

Under bilateral agreements between the banks, only electronic messages containing all information relevant to the payment document(s) can be sent. The real documents are held by the Presenting Bank should problems arise in collection. This is called “Truncation”. The drawee knows about the documents drawn against him and will pay against a receipt issued by his bank. In this way, transactions can be handled much quicker and more cost effective compared to the use of paper documents that would first have to be mailed via the collecting bank to the drawee located abroad.

The electronic message used can be a SWIFT MT 405. A SWIFT MT405 is currently not supported in the application, as this message can only be used by banks that subscribe to the Message User Group (MUG).

This field is required for clean collection only. (Clean collection: In case financial documents (such as bill of exchange, checks etc.) and no transport documents are presented for collection).

Under a clean collection, the ISSDAT specifies the date when the relevant payment document has been issued.

This field is required for clean collections only. (Clean collection: when financial documents (such as bill of exchange, checks etc.) and no transport documents are presented for collection).

Under a clean collection, the issuing date specifies the date when the relevant payment document has been issued.

This field is required for clean collection only.

(Clean collection: In case financial documents and no transport documents are presented for collection.)

Under a clean collection, this field indicates the number of the financial document (e.g. check number).

This field is required for clean collection only.

Clean collection: If financial documents (e.g. bills of exchange, checks, etc.) and no transport documents are presented for collection.

Under a clean collection, this field indicates the number of the financial document (e.g. cheque number).

This field is required for clean collection only.

(Clean collection: In case financial documents and no transport documents are presented for collection.)

Under a clean collection, this field indicates the type of document (such as bill of exchange, checks etc.)

This field is required for clean collection only.

Clean collection: when financial documents (such as bill of exchange, checks etc.) and no transport documents are presented for collection.

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

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

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

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

The current document set status is stored in this field. This field is set via default in the panel module.

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

Contract status flag. If not empty, contract is reservated. That means, only a few basic fields have to be filled in. Visible on BOTP in BOTPOP and INFBOD. 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 an Export Collection' (BOTPOP) and 'Info Export Collection' (INFBOD). Invisible in all other transactions.

This field counts the number of all initiated amendments under the Export Collection. 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 all 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 holds the receiver of second mail, if documents are sent out in two mailings. The receiver of the second mail can be a contract party, such as collecting bank, 2nd collecting bank or drawee (if it has been entered into the contract) or a further party (RSM - Receiver of second mail) which is stored in the database.

This field holds the receiver of second mail, if documents are sent out in two mailings. The receiver of the second mail can be a contract party, such as collecting bank, 2nd collecting bank or drawee (if it has been entered into the contract) or a further party (RSM - Receiver of second mail) which is stored in the database.

This field contains the date of the last amendment which has been processed under the export collection

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 set to an nonempty value, it means that the URC apply.

This flag is used to indicate whether the collection underlies the “Uniform Rules for Collection” or not. When the flag is set to an nonempty value, 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.

Rejection Type Discription is empty, for this is a radio-group with a label.

Description is empty, for this is a radio-group with a label.

This field contains the date on which documents have been taken up, i.e. transaction BOTPAY has been executed.

This field contains the date on which documents have been taken up, i.e. transaction BOTPAY has been executed.

Set in BOTPOP, 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 field holds the INR of the transaction which opened the contract.

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

allNETT Send Documents via Field send D2A in export collection issuance Mandatory

How to send the Collection to the Collecting Bank

Instruction what to do with accepted draft

Non-Payment protest instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Non-Payment protest instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Non-Acceptance protest instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Non-Acceptance protest instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Keep documents in case of non payment instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Keep documents in case of non payment instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Store goods in case of non payment instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Store goods in case of non payment instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Level of instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

How to deal with information or instructions received from the contact.

Interest instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Should interest be collected

Interest rate for non payment penalty interest received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Interest rate for non payment penalty interest received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Startdate for non payment interest calculation received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Startdate for non payment interest calculation received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Non-Payment interest refusal instructions received from allNETT.

Value is not used in DNG, but is required to be send back to allNETT. Therefore we need to store it in the contract data.

Instruction whether to release documents to the Drawee in case interest payment is refused.

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.

The bank using DOKA must issue the ALADI Reimbursement code on customer request when an Export Collection is opened.

The bank using DOKA must issue the ALADI Reimbursement code on customer request when an Export Collection is opened.

Marks, that the current contract had been issued under ALADI.

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. Can i.e. contain the old reference number of migrated contracts.

Alternate reference number. Can i.e. contain the old reference number of migrated contracts.