MCD - Manual Contract Data

MCD is the main data table for the Manual contract.
All technical important fields have to be defined here.
Large text blocks should be defined in MCT.

/

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

This field contains the reference number of the manual contract 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. This field can be used to search for a manual contract within the database.

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 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 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 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 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 point in time 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 date field specifies the expiry date of the manual contract.

This field contains the date of expiry of the manual contract.

This field contains the date of the received order.

This field contains the date of the instruction order received.

This field holds the reference of the Addressee. Replicated copy of the field PTS\REF of the associated entry of the role “ADE”. This field is only used to speed up search and database access.

This field contains the reference of the addressee.

This field holds the reference of the Applicant. Replicated copy of the field PTS\REF of the associated entry of the role “APL”. This field is only used to speed up search and database access.

This field contains the reference of the applicant.

This field holds the version counter to keep track of the version history of an MCD 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.

The field can be used for statistical reasons and allows the bank to evaluate the country risks it has entered by issuing the manual contract.

The field can be used for statistical reasons and allows the bank to evaluate the country risks it has entered by issuing the manual contract.

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.

The field can be used for statistical reasons and allows the issuing bank to evaluate L/C's 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.

If this flag is activated, automated periodic settlements can be generated per SPT.

If this flag is checked, automated periodic settlements can be generated per system pending transaction (SPT).

If this flag is activated, automated balance statements can be generated per SPT.

If this flag is checked, automated balance statements can be generated per system pending transaction (SPT).

If Balance Statements are created per SPT the date set in MCBSPT(REFDAT) is used. Manuel execution sets this date to today.

If balance statements are created per system pending transaction (SPT), the date set in reference date is used. Manuel execution sets this date to today.

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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (PRDVAR), providing a bank product, a sub differentiation and individual variants if needed.

Here the “product code” 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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (PRDVAR), providing a bank product, a sub differentiation and individual variants if needed.

Here the “product code” 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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (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 the three fields “product code” (PRDCOD), “product subtype” (PRDSUB) and “Product Variant” (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.