PUD - Payment Undertaking Data

PUD is the main data table for the Payment Undertaking contract.
All technical important fields have to be defined here.
Large text blocks should be defined in PUT.

/

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 PUD. The field INR is used to enable links from other tables to this table. It also links the two tables PUD and PUT 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 Payment Undertaking being established. The reference number can have a maximum size of 16 characters. This field can be used to search for any Payment Undertaking from the database.

This field hold 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 is not modifiable by 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.

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 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 specifies the date when the payment undertaking is expiring and due for payment.

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 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 version counter to keep track of the version history of a PUD 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 defines whether the charges and commissions of the bank are borne by the buyer's side (=“U”), by the seller's side (=“B”) or others. According to the selection entered in this field, the roles in the second settlement grid (own commission/charges) are defaulted.

The field is defaulted with the country code of the buyer.

This field contains the type of goods shipped under the Payment Undertaking. 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 field contains the date when the payment undertaking is accepted by the buyer. If the contract is financed, this date is defaulted to be the starting date of the financing.

This field counts the number of all initiated amendments under the Payment Undertaking. 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 (PUTame), if no already existing amendment is further processed.

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.

The current status of the payment undertaking 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 reserved. That means, only a few basic fields have to be filled in. Visible on PUTP in PUTPOP and INFPUD. Invisible in all other transactions.

This field contains the date of the last amendment which has been processed under the Payment Undertaking

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.

Set in PUTPOP, 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.

The amount of tolerance by which the amount of contract could exceed or get decreased. The amount is taken into consideration for the total undertaking amount. Amount pre-fixed with - sign denotes a negative tolerance.

Currency of the Tolerance Amount

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.

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.