3. Defining Attributes of FT Product

3.1 Introduction

In this chapter, we shall discuss the manner in which you can define attributes specific to a Funds Transfer product.

This section contains the following topics:

3.2 Funds Transfer Product

You can create an FT product in the ‘Funds Transfer Product Definition’ screen. You can invoke the ‘Funds Transfer Product Definition’ screen by typing ‘FTDPRMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen, you can enter basic information relating to a FT product such as the Product Code, the Description, etc.

For any product you create in Oracle FLEXCUBE, you can define generic attributes, such as branch, currency, and customer restrictions, tax details, etc., by clicking on the appropriate icon in the horizontal array of icons in this screen. For a FT product, in addition to these generic attributes, you can specifically define other attributes. These attributes are discussed in detail in this chapter.

You can define the attributes specific to a FT product in the FT Product Definition Main screen and the FT Product Preferences screen. In these screens, you can specify the product type and set the product preferences respectively.

For further information on the generic attributes that you can define for a product, please refer the following Oracle FLEXCUBE User Manuals under ‘Modularity’:

Product Type

An important detail in defining a product is to specify the type of product you are creating. The product type identifies the basic nature of a product. This helps to classify the product.

The entries that are passed, the messages that are generated and the processing of contracts depend on the Product Type. An FT product that you create can either be:

An Incoming Transfer is one in which the beneficiary of the transfer is a customer of your bank. Since funds are coming into your bank, it is termed as an incoming transfer.

An Outgoing Transfer on the other hand, indicates a transfer initiated by your bank, either for itself or on behalf of its customers. As the beneficiary of the transfer is not a customer of your bank, you will have to pass on these funds to the ultimate beneficiary through another bank or a series of banks. Such a transfer of funds is termed as an outgoing transfer since funds are going out from your bank.

An Internal Transfer involves funds that are transferred from one account to another within your bank or between the branches of your bank.

A few instances of Internal Transfers have been listed below:

Therefore, internal transfers do not involve funds that are transferred through a chain of banks, or payments made from or to a correspondent bank account. As the transfer of funds does not involve a party outside the circle of your bank, it is termed as an internal transfer. The customers involved in the transfer will be kept informed by means of debit or credit advices.

Product Description

Give the narration about the product.

Slogan

Enter the text that should appear in the report or an advice generated with regard to this product.

Start Date

Specify the date from which this product should be open for contracts to be created under it.

End Date

Specify the date until which contracts should be created using this particular product.

3.3 Preferences for Product

This section contains the following topics:

3.3.1 Specifying Preferences for Product

‘Preferences’ are the attributes or terms related to core processing that you define for a product. By default, a transfer involving a product inherits all the attributes defined for the product. However, some attributes (preferences) that are defined when the product was created can be changed during the processing of individual FT contracts (i.e., at the contract level) involving the product.

Click ‘Preferences’ button to invoke the FT Product Preferences screen. Through this screen you can define the following Preferences for a product:

 

The product code together with a brief description that you specified for the product in the product definition screen will be displayed at the top of the screen. The FT Product- Preferences screen contains nine sections. Each of these sections captures specific information about the product.

Note

Not all product preferences are allowed to be amended, after the product has been author­ized once. So care needs to be taken before authorization of the product to ensure that the product attributes (preferences) have been maintained correctly.

3.3.2 Specifying Message Related Details for Product

In this section you can define message related details for outgoing transfers.

Transfer Type

Indicate the type of transfers that the product can be associated with. From the option list you can choose any of the following options:

Note

The type of transfer that you indicate, will determine the type of payment message that will be generated for contracts involving the product.

Suppress BV Payment messages

Indicates whether or not the system should suppress by default, the payment message for all back valued contracts (contracts with debit value date less than the system date) of the product. This would be enabled only for outgoing funds transfers. By default, this option would be unchecked for all outgoing FT products.

For instance, if the bank wishes not to generate and send outgoing payment message for a back valued dated contracts, then the bank can check this option to enable the option.

Multi Credit Transfers

Enabling this option indicates that the particular FT product can be used for Multi Credit Transfers and also to generate MT201 message A Multi Credit Transfer may be either a Multi Customer Transfer or a Multi Financial Institution Transfer or Multi Transfer for Own Account. In case of a Multi Customer Transfer, the payment message sent will be MT102 not MT103. In case of a Multi Financial Institution Transfer, the payment message sent will be MT203. In case of a Multi Financial Transfer for Own Account, the payment message sent will be MT201. Multi Credit Transfer will be allowed in the following instances:

Cover Required

Indicates whether a cover message needs to be sent for the transfer or not. Check against ‘Cover Required’ to indicate that a cover is required. Leave it unchecked to indicate otherwise.

Generate 103+

Indicate whether MT 103 messages for outgoing transfers using the product must be generated in the MT 103+ format.

As a result of this maintenance, the system will generate payment messages in the MT 103 + format for all contracts involving the product.

Note

If you are enabling the MT 103+ option for a product, also ensure to enable the same op­tion for the branch, customer and currency involved in the transaction. The criteria for val­idation will be as follows:

If the validation criteria fail due to some reason the system displays an error message informing you about its inability to generate the payment message in the preferred MT 103 + format.

Generate MT102+

Check this box to indicate that MT 102+ messages can be processed for the Product code you are maintaining. On checking this box, you must also select Multi Customer Transfer so as to process MT102+ messages.

Remit Message

Check this field to send remit messages using this product. Also, If you wish to send the envelope contents, you need to check this field.

The following validations will be carried out in Oracle FLEXCUBE if the ‘Remit Message’ box is checked:

The remit message will be displayed in the message in the Block 119 as 119:REMIT.

Note

The ‘Remit Message’ box is enabled only for customer transfer.

3.3.3 Processing Back Values Payment Messages for Outgoing FT Contracts

In case of an outgoing FT contract which is back-dated (debit value date of the contract is earlier than the system date) and the ‘Suppress BV payment message’ option is checked for the product, the system will set the Generate Message option as ‘No’ for both the credit and debit legs of the contract.

Upon saving the contract, the system will show an over-ride saying ‘The contract is Back Valued’. If you press ‘OK’, another over-ride indicating ‘Message will be Suppressed will be displayed. Click OK to Proceed?’ will be displayed. If you press ‘OK’ again, you will continue to save suppression of the messages. If you press ‘CANCEL,’ you will cancel suppression of the messages. However, you can still generate the payment message by visiting the Settlements screen and checking the ‘Generate Message’ option there.

The option ‘Suppress BV payment message’ at the product level will decide the default value of the ‘Generate Message’ option for backdated outgoing funds transfer. However, the generation of payment message can be controlled at the contract level by checking or un-checking the ‘Generate Message’ option manually in the Contract Settlements screen.

Note

For more details on FT contracts, please refer the Contracts chapter.

3.3.4 Specifying Payment Related Preferences

For an FT product, you can specify the mode in which the payment processing would be put through, for contracts involving the product. The mode may differ based on the classification of the contract – whether incoming or outgoing, whether bank or customer, and so on.

Message

For instance, in an outgoing customer funds transfer, payment may be made (i.e., the transfer of funds can be effected) through SWIFT messages such as MT 103. To specify this, indicate the payment option as ‘Message’ type, in the Preferences screen.

Instrument

For manager’s check type of funds transfer product, the payment could be typically effected through a payment instrument. To specify this, indicate the payment option as ‘Instrument’, in the Preferences screen.

3.3.5 Specifying Rate Related Details for Product

In this section you can specify rate related details for the product. The rate details that you define for the product will be defaulted to all contracts involving this product. However, you have the option to change them for the contract.

Rate Type

Specify a valid exchange rate type that has to be applied to the transfer amount for contracts involving the product, from the adjoining option list.

If you choose 'Standard Rate', the system computes the transfer amount by picking up the exchange rates from the currency table maintained in the Core Services module of Oracle FLEXCUBE.

The system applies the spread that you define for the product to the standard exchange rate.

Refer to the chapter ‘Batch Processes’ for details of the Rate Update function

Spread Code

The Standard exchange rate is the Mid Rate advised by the Central bank of the country for all foreign exchange operations. Based on the Mid Rate quoted for a currency and other market trends each bank determines its spread.

Spreads are nothing but the margins on either side of mid rate (plus or minus) calculated to determine the rate at which your bank will buy or sell currencies. Spreads are maintained in the Currency Spread table of the Core Services module.

For a product, you can specify the fraction of the spread that should be applied to contracts involving this product. The options available are:

Rate as of

After you have defined preferences for the exchange rate pickup, you can indicate the date or the day as of when these rates should be picked up and applied to the transfer amount. This preference is applicable only for outgoing and internal product types. Also, the rate pick-up preference applies only cross currency contracts (contracts in which the debit and credit legs are in different currencies) and for the conversion between the two contract amounts (debit amount and credit amount).

The possible dates for Rate pickup
Booking date
Spot date
Value date
Dr. Value date
Cr. Value date
Instruction date

Booking date - If you indicate ‘Booking Date’, the rate type prevailing as of the date you entered the contract will be picked up. In the case of a normal contract (a contract that is liquidated on the booking date) you should specify that the rates should be picked up as of the booking date. For future valued transfers you can specify that the exchange rates can be picked up as of the booking date, value date or spot date.

Spot date - For each currency that your bank deals with, you have also specified a spot date. The spot date for the currency is maintained in the Currency Definition Maintenance table of the Core Services module.

If you specify that the exchange rate should be picked up as of the ‘Spot Date’, then messages will be generated on the spot date (depending on the spot date you have maintained for the currency involved in the transfer.

Value date - If you specify value date, exchange rates prevailing as of the date on which the transfer becomes effective will be applied to the transfers. The Accounting Entries for the contract will be passed as of this date.

You can also enter the value date of your choice here. The date that you enter can be one of the following:

The Value Date (transfer initiation date) should not be earlier than the Start Date or later than the End Date of the product involved in the transfer.

Dr. Value date - If you specify this option, exchange rates prevailing as of the value date of the debit leg of the contract will be applied to the transfer.

Cr. Value date - If you specify this option, exchange rates prevailing as of the value date of the credit leg of the contract will be applied to the transfer.

Instruction date - If you specify this option, exchange rates prevailing on the date on which the customer placed the instruction to debit the customer account will be applied. This is similar to debit value date.

Message as of

You can specify the date on which messages for the contracts linked to the product should be generated and accounting entries be posted. This is applicable only for outgoing and internal product types.

Possible dates for Message generation
Booking date
Spot date
Value date
Dr. Value date
Cr. Value date
Instruction date

3.3.6 After Rate Refresh

After Rate refresh indicates that the standard exchange rate maintained in the Core Services module of Oracle FLEXCUBE should be used to compute the transfer amount, only after the rate refresh program has been run for the day.

If you check this check box, the contracts linked to this product will not be processed, until the Rate Refresh process has been run and authorized for the day. Until then the contract remains as if on hold and cannot be authorized.

Further operations on such a contract are possible only by means of the FT Rate Update function. When this function is run, the contract gets displayed and if you confirm that you want to process the contract using the rates now available, then the contract is processed, entries will be passed and messages generated.

Allow Message before Accounting

You can indicate whether the system must allow generation of messages before the relevant accounting entries are passed for contracts using the product. This preference is only applicable for outgoing product types.

If this option is set for a product, it is defaulted to all contracts using the product. When you enter a contract using such a product, you can specify whether accounting entries must be passed on the date of message generation or on the debit value date.

A Note on Rate Picks Up and Message Generation Dates

There exists a definite link between the rate pick up and the message generation code. The Rate pickup and message generation codes need to be combined in a fashion to facilitate the following flow:

  1. Rate pickup
  2. Message Generation

Based on the combination that you specify, exchange rates will be picked up and messages generated. Accounting entries will be passed and then messages will be generated.

All the possible combinations between the rate pickup and the message generation codes have been explored and detailed below.

Standard rate as of Booking date - Message as of Spot date

If you select this combination;

Rate as of Spot - Message as of Spot

If you choose this combination;

Rate and Message as of Value date

If you choose this combination the transfer amount will be converted based on;

Rate as of Booking date - Message as of Booking date

If you select this combination, the system converts the transfer and commission amount based on the:

3.3.7 Specifying Clearing Related Details for Product

If you indicate the Payment Type as ‘Clearing’, you have to identify the Clearing Network. Further, if the FT product you are creating is used for processing ‘ZUS’ transactions, select the ‘Special Clearing’ option under Clearing Related information.

3.3.8 Specifying Instrument Related Details

In this section you can define Instrument related details for the product:

Instrument Number Required

Check against this option to indicate whether the Managers Check No should be a mandatory input at the Contract level. This would typically be applicable only for funds transfer product types such as Demand Drafts / Managers Check Issuance.

Managers Check Payable GL

If you have specified that an instrument number is required, you should also indicate the Managers check payable GL to be used by transfers involving the product. This GL would be used to park the outgoing funds till liquidation is done, whereby the amount in this GL would be washed out to the credit of the appropriate nostro account.

This field will be activated only if you had indicated that an Instrument Number is required. You can select a valid foreign and local currency type GL from the pick list that is available.

DAO GL

In the case of incoming transfers where the payment is routed to the ultimate beneficiary through a suspense GL (which is an intermediary parking account), you must specify the DAO GL number.

You can select a DAO GL from the option list that is available.

Note

The DAO GL is also credited when an Incoming FT is received, in case the credit account is closed or the account number mentioned is invalid.

3.3.9 Specifying Contract Authorization Details for Product

You can specify whether certain important details of the contract involving this product need to be re-keyed at the time when the contract is being authorized. If you indicate positively then the fields that you specify will have to be re-keyed at the time the contract is authorized.

Under ‘Fields’ you will have to check against the specific fields that need to be re-keyed during contract authorization.

This facility has been incorporated as a safety measure. It would do you well to indicate positively in these fields as the possibility of human error cannot be discounted. For instance let us assume that the value date has been input incorrectly for a contract. If you have specified 'Yes' at the Re-key Required field and checked on Value date under 'Rekey Fields' then at the time when the contact is being authorized this field will have to be re-keyed and the error which would have otherwise cost you dearly can be corrected.

3.3.10 Specifying Other Preferences for Product

Split Dr/Cr Liquidation

Check this option, then both initiation and liquidation events get triggered for any outgoing FT product. By default, this option is not enabled.

Future Value Allowed

Check this option if the future valued contracts can be input using this product

Cross Currency Allowed

Check this option if the Cross-currency transactions can be input using this product

Process Overdraft for Auto Book

Check this option if the Process overdraft for Autobook facility should be made available for the product. This field is applicable to future dated contracts involving this product. The Autobook function automatically liquidates future dated contracts. There could be a situation where a customer requests you transfer an amount that actually exceeds the amount in his account. In this field you can specify whether contracts involving this product which is picked up by the Autobook function can be processed in spite of the overdraft.

Validate Beneficiary Name

Check this option if the Beneficiary Name should be validated against the authorized variations of the customer’s name maintained in the Customer Names screen. This feature is applicable only for incoming funds transfers. If you enable this option, all incoming FTs involving the product are processed only after the customer’s Account Number and Name correspond to the authorized variations of the customer’s name.

Beneficiary IBAN mandatory

You can indicate whether IBAN validation needs to be done in respect of the Beneficiary account number of the contract. If the IBAN validation fails, an error message is displayed by the System.

The following details can be specified:

3.3.10.1 Indicating whether Referral is Required

Referral refers to the process of handling customer transactions which force the accounts involved in such a transaction to exceed the overdraft limit. Funds Transfers are examples of typical transactions, which can force an account to move into overdraft. While maintaining the details of an FT product you can indicate whether transactions involving the product need to be considered for referral checks. Enabling this option indicates that transactions involving the product need to be considered for referral.

The referral process is handled for the future dated contracts through the FT Auto batch process.

For more details on the referral function in the batch process, refer to the chapter ‘Automatic Processes’ of the Funds Transfer user manual.

If a product is marked for referral, the details of transactions resulting in the account (involved in the transaction) moving into Overdraft will be sent to the Referral Queue.

Note

If an FT transaction breaches the specified limits, the details of the transaction will be dis­played in the Unposted Entries section of the queue. You can either choose to accept or reject it.

For further details on Referrals refer to the Processing Referrals in Oracle FLEXCUBE chapter of the Core Entities manual.

3.3.11 Maintaining Product Event Accounting Entries for Outgoing Funds Transfer

Oracle FLEXCUBE will route all outgoing funds transfer through suspense GL called INTMD_SUSPENSE. This is a liability type of GL. The accounting entries passed in this GL for an initiation event would be as follows:

Dr/Cr Indicator Accounting Role Amount Tag Value Date
Dr REMITTER AMT_EQUIV Dr Value Date
Cr INTMD_SUS­PENSE AMT_EQUIV Dr Value Date

The accounting entries for a liquidation event would be as follows:

Dr/Cr Indicator Accounting Role Amount Tag Value Date
Dr INTMD_SUS­PENSE AMT_EQUIV Cr Value Date
Cr BENEFICIARY TFR_AMT Cr Value Date

If the Split Dr/Cr Liquidation option is unchecked, then charges, other than Liquidation Charges, would be defined for the Book event and liquidated during initiation

If the Split Dr/Cr Liquidation option is checked, then the Charge Accounting Entries would be defined for both initiation and liquidation events. The corresponding Charge Accounting Entries would be passed and the charge liquidated during initiation, provided, Charge Whom is ‘Remitter’ or ‘Shared’. In case Charge Whom is ‘Beneficiary’,’ then the corresponding charge accounting entries would be passed at the time of liquidation.

3.3.12 Processing Split Dr/Cr Liquidation for FT Contracts

If the ‘Split Dr/Cr Liquidation’ option is enabled for a product, then the system will trigger initiation and liquidation event simultaneously, even if the value date for both the debit and credit legs is the same. If the credit value date for a contract is after the system date, then liquidation will not be triggered immediately.

The following cases are possible.

Case I – The value of ‘Accounting as of’ is a message date.

In such a case, the entries would be passed along with the message.

The system would trigger the initiation event ‘INIT’ along with the message generation.

The liquidation would be deferred and event ‘LIQD’ would be triggered only on the Credit Value date.

Case II – The value of ‘Accounting as of’ is a Debit value date.

The initiation event ‘INIT’ would be triggered on the Debit Value date.

The liquidation would be deferred and the event ‘LIQD’ would be triggered only on the Credit Value date.

Note

For more details on FT contracts, please refer the corresponding chapter.

For further details on generic attributes that you can define for liquidation of a FT contract, please refer the ‘Liquidation’ User Manual under Modularity.

3.3.13 Batch Processing of FT Contracts

FT batch would be enhanced to pick up those contracts with credit value date less than or equal to the current date and trigger Liquidation event for those contracts.

In case the Split Dr/Cr Liquidation option is enabled, then the corresponding Charge Accounting Entries would be passed and the charge, liquidated, during initiation of the contracts. This would happen, provided, Charge Whom is ‘Remitter’ or ‘Shared’. In case Charge Whom is ‘Beneficiary’, then the charge accounting entries would be passed during liquidation.

Note

For more details on FT contracts, please refer the corresponding chapter.

3.3.14 Applying Currency Cut-off Checks on Transactions Involving Product

You can choose to restrict the time within which (or before which) funds transfer transactions involving a customer, in the product, involving a specific currency, must be received for processing. For a specific customer, product, and a currency, you can specify a certain number of days before which a transaction involving the combination must be received, as well as a cut-off time before which transactions must be received. These parameters are known as currency cut-off parameters, and you maintain these parameters in the Value Dated Spread maintenance. You also maintain cut-off parameters to be applied for each currency, in the Currency Definition.

To specify that such cut-off checks must be performed in respect of a funds transfer transaction, select the option ‘Cut-off Days Check’ in the ‘Product Preferences’ screen. The cut-off days and the cut-off time that is to be applicable, for each currency, is picked up from the Value Dated Spread maintenance, if available, and if not, from the Currency Definition specifications.

3.3.15 Specifying Rate Variance

For an FT product you can specify the Rate type to be either Standard, Standard (after rate refresh). These values will be defaulted to all contracts involving this product. At the time you input a contract you have the option of changing the default and specifying an exchange rate of your choice. This field is applicable only if you have decided to change the product default and if the contracts linked to the product are cross currency transfers.

In this section you can specify the minimum and maximum limit by which the exchange rate you input for contracts involving this product can exceed the standard exchange rate.

3.3.15.1 Specifying Charge Details

There are obvious costs involved in transferring funds from one location to another. You need to indicate who will actually bear these service charges. You can select an option from the option list that is available.

Identify the party that would bear the charges in respect of a funds transfer contract that is processed using this product. The following options are available:

This specification is inherited by all contracts using the product. If you require not allowing this specification to be changed when a contract is entered using the product, you must check the ‘Allow Change in Contract’ box.

3.3.16 Specifying Back Value Date Preferences for Funds Transfer Transac­tions

You can post back value dated transactions in Oracle FLEXCUBE. However, for the purpose of risk tracking, you can specify a limit beyond which users will be prevented from posting a back value dated transaction in the system.

3.3.16.1 Specifying Dr Back Value Days

This is the number of days within which a user will be allowed to post a back value dated debit funds transfer transaction. In other words, for a back value dated FT, the date on which the remitter’s account is to be debited, should fall within the limit maintained here.

3.3.16.2 Specifying Cr Back Value Days

Likewise, for a back value dated FT, the date on which the beneficiary’s account is to be credited, should fall within the limit maintained here.

If the value dates do not fall within the Debit or Credit Back Value Days maintained, the system will display the message as ‘The Debit or Credit value date is earlier than the Permitted value days’.

These validations are also carried out for transactions that are uploaded from external systems.

Note

You will be allowed to specify the ‘Dr Back Value Days’ and ‘Cr Back Value Days’ only if the ‘Dr Back Valuation Check Required’ and ‘Cr Back Valuation Check Required’ options are enabled. If the options are not enabled, the system will allow you to post back-valued transactions up to any date in the past (no check will be done). Further, if the option is checked but you have not maintained the ‘Back Value Days’ (maintained as NULL), the system will interpret it to be ‘Zero’ days allowed (for back valued transactions).

3.3.16.3 Specifying RTGS Preferences for Product

You need to specify the following RTGS preferences:

RTGS Product

Click this box if the product is of RTGS type.

Note

This field is applicable only for outgoing and incoming transfers. It will not be enabled for internal type of transfers.

Sender Notification Required

Check this box to indicate whether a notification is to be sent to the sender from the PM on the status of the original payment message.

When this box is checked and the original payment message is settled in the PM, the sender will receive an incoming MT012 message and if the original payment message is rejected in the PM the sender will receive an incoming MT019 message.

Network

Specify the FIN Y – copy network if the product is intended for FIN – Y Copy message generation. FIN Y copy payments are mostly used for sending a copy of a message or parts thereof to a third party, for example a Central Bank.

Note

This field is enabled only for outgoing and incoming transfers and for RTGS type of prod­ucts. It will not be enabled for internal type of transfers.

Payment Type

Select the types of payment available in case of TARGET-2 FIN Y-Copy from the adjoining drop-down list. This list displays the following values:

By default, the payment type is shown as ‘All’.

For TARGET2 payments, an error will be displayed if the beneficiary bank is not consistent with the product level payment type (domestic, within EU or outside EU).

Banking Priority

Select the priority of the payment messages from the adjoining drop-down list. This list displays the following values:

The banking priority is chosen as ‘Normal’ by default. However, you can modify this value.

You will not be allowed to amend the RTGS preferences, after the product has been authorized once.

Note

The Priority will be displayed in the RTGS messages in tag 113 as 4 Alphabets. For ex­ample, 113:NNNN – For a Normal Priority.

Duplication Recognition

You can specify the following details related to duplication check for transactions. The duplication check is carried out based on the combination of the preferences maintained at the FT product level.

Product Code

Check this box to indicate that the product code needs to be considered while checking for duplicate transactions.

Booking Date

Check this box to indicate that the booking date needs to be considered while checking for duplicate transactions.

Dr Amount

Check this box to indicate that the Dr amount needs to be considered while checking for duplicate transactions.

Cr Amount

Check this box to indicate that the Cr amount needs to be considered while checking for duplicate transactions.

Dr Value Date

Check this box to indicate that the Dr value date needs to be considered while checking for duplicate transactions.

Cr Value Date

Check this box to indicate that the credit value date needs to be considered while checking for duplicate transactions.

Ultimate Beneficiary Account

Check this box to indicate that the ultimate beneficiary account details need to be considered while checking for duplicate transactions.

Ultimate Beneficiary Address

Check this box to indicate that the ultimate beneficiary address details need to be considered while checking for duplicate transactions.

Note

If the field ‘Ultimate beneficiary Account’ is checked, the system checks for duplication and the following logic is applied:

Dr Currency

Check this box to indicate that the Dr currency needs to be considered while checking for duplicate transactions.

Cr Currency

Check this box to indicate that the Cr currency needs to be considered while checking for duplicate transactions.

The check for duplicate transactions is carried out based on the duplication check days maintained at Branch Parameter level. An override message gets displayed if any duplicate transaction is encountered.

Note

If none of the above checkboxes are selected, duplication check will not be performed, even if duplication check details have been specified at branch parameter level.

For more details on the duplication check preferences maintained at branch level, refer the section titled ‘Maintaining Duplication Check Details’ in Core Services user manual.