4. Maintaining Clearing Products

This chapter contains the following sections:

4.1 Define CG Product

This section contains the following topics:

4.1.1 Defining CG Product

In this chapter, we shall discuss the manner in which you can define attributes specific to a Clearing (CG) product.

You can create a clearing product in the ‘CG Product Definition’ screen. You can invoke this screen by typing ‘CLDFNPRD’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

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

The advantages of defining a product

Let us consider the steps involved in processing an outward clearing transaction (for example, your customer presents a check drawn on another bank) at your bank. Your specifications would include the following:

If you process a thousand such outward clearing transactions in a day, you would need to repeat these operations as many times. By defining outward clearing transactions as a product in Oracle FLEXCUBE, and defining standard attributes for it, you can simplify the task of processing clearing transactions.

Every time you process a clearing transaction under a product, Oracle FLEXCUBE automatically applies the attributes defined for the product.

However, if required, you can change the inherited attributes at the time of processing.

For any product you create in Oracle FLEXCUBE, you can define generic attributes, such as branch, currency, and customer restrictions, interest details, tax details, etc., by clicking on the appropriate icon in this screen. For a loans 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 loans product in the CG Product Definition Main screen and the CG 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 to the Product Definition User Manual under Modularity.

Product Type

A product you are creating can belong to either of the following categories:

These product categories are referred to as product types. When you create a product, you must specify its ‘type’.

Exchange Rate Variance

A clearing transaction may involve a currency conversion. For such transactions, the rate corresponding to the Rate Type that you specify for the product will be picked up. (Cash rate, Standard Rate, Spot Rate, etc., are examples of Rate Types). When processing a transaction, the rate value that is picked up can be changed.

You can define the limits within which this change can be made, as follows:

Normal variance

The rate variance can exceed the rate maintained for the Rate Type by the value you specify here (normal variance). In such a case, the system prompts the user with an override message before the contract is saved.

Maximum variance

For transactions involving the product, the exchange rate variance cannot exceed the rate corresponding to the Rate type by this value (Maximum Variance). If the rate that is input exceeds the maximum variance defined, the system will not allow storing of the contract.

4.1.2 Preferences Button

You can maintain preferences for clearing through the Preferences screen. To invoke this screen, click ‘Preferences’ button in the ‘Clearing Product Definition’ screen. The screen appears as shown below:

Referral Required

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

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 a clearing transaction breaches the limits, the details of all transactions processed during the day will also be moved to the Posted Entries section in the Referral Queue. You can choose to accept or reject the transactions. The details of the transaction which has breached the limits will be displayed in the Unposted Entries section of the queue.

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

Defer Liquidation

Check this box to defer liquidation of the selected clearing product.

Defer liquidation is applicable for outward Clearing products. If Defer liquidation sets to Y, System supports Stage wise accounting.

Indicating requirement for Referral

Clearing transactions can force an account to move into overdraft. You can indicate whether inward clearing transactions involving the product need to be considered for referral checks for exceeding their overdraft limit. Check this option to indicate that referral is required.

Consolidation Required

This field is enabled only for inward clearing products. Check this option to indicate consolidation for all transactions for a customer in an inward clearing batch, is required. Any inward clearing product which has Consolidation Required enabled, cannot be selected for a manual clearing entry.

Insufficient Funds Reversal

This field is enabled only for inward clearing products. The Transaction Code is used to reverse the accounting entry if an individual clearing transaction is reversed from the Referral Queue due to insufficient funds. Specify a Transaction Code for reversal. If the Transaction Code is left blank, the Transaction Code of the original clearing entry will be used for reversal.

CASA Reversal

This field is enabled only for inward clearing products. The Transaction Code is used to reverse the accounting entry if an individual clearing transaction is reversed due to any CASA error. Specify a Transaction Code for CASA reversal. If the Transaction Code is left blank, the Transaction Code of the original clearing entry will be used for reversal.

Only those Transaction Codes which have Cheque Mandatory set as ‘NO’ in the Transaction Code Maintenance screen, will appear for selection.

Consolidation Transaction Code

You need to specify the Transaction Code required for passing a consolidated clearing entry. The same Transaction Code should be maintained with Cheque Mandatory option as ‘No’, in the Transaction Code Maintenance screen.

Dispatch Days

Specify the number of days to be used to calculate the dispatch days from the booking date. System uses the local currency calendar to compute the dispatch days from the date of deposit.

For instance, if the dispatch days is given as 1 system fires DCLG on the next Local currency working day. In case that day is a local holiday, then the event is fired on the next business date.

Liquidation Days

Specify the number of days to be used to calculate the liquidation days from the booking date. System uses the local currency calendar to compute the liquidation days from the date of deposit.

For instance, if the liquidation day is given as 2, the system fires LIQD after 2 Local currency working days. In case that day is a local holiday, then the event is fired on the next business date.

4.1.3 Role to Head Button

You can maintain accounting roles for clearing products through the Role to Head mapping screen. To invoke this screen, click ‘Role to Head’ button in the ‘Clearing Product Definition’ screen. The screen appears as shown below:

The following accounting roles can be maintained:

The following amount tags can be maintained:

4.1.4 Events Button

You can maintain the events for clearing through the Events screen. To invoke this screen, click ‘Events’ button in the ‘Clearing Product Definition’ screen.

The screen appears as shown below:

The following events are maintained:

The CGBEOD batch is run for outward clearing to handle the accounting entries on Day 1 and Day 2. The batch is setup to run at the End of Transaction Input Stage to process eligible clearing contracts.

The system fires INIT event and passes the accounting entries based on the product setup and marks the status of the contracts as “Deposited” in case of deferred liquidation, This happens online during contract booking itself.

The system fires DCLG event and marks the status as “Dispatched” on the day of dispatch (Book Date + Number of Dispatch days),

The system automatically liquidates all the contracts which are in “Dispatched” status on Liquidation date (Book Date + Liquidation Days), On Liquidation Date the system reverses the accounting entries passed for INIT and DCLG events, i.e. it passes the REVR event, accounting entries and LIQD event, accounting entries and marks the status as ‘Liquidated’.

The system picks up the accounting entries setup for the events INIT and DCLG from Clearing Product and LIQD from ARC Maintenance.

For further information on Accounting Entries and Advices, please refer to the Product Definition User Manual under Modularity.

4.2 Processing Reversals

Reversal of individual clearing entries will be processed automatically by the system in case of any CASA related errors or any other error while processing the individual instruments. The CASA Reversal Transaction Code specified in the Clearing Product Preferences screen will be used for reversal due to CASA errors. If this Transaction Code is not maintained, the Transaction Code used for passing the consolidated clearing entry (of which this instrument was a part) will be used for reversal. The individual transaction will be marked as rejected in this case.

In case the Force Posting option has been checked in the Interface Clearing Details screen, and an individual transaction is posted to a referral queue because of insufficient funds (if the Referral option is checked in the Clearing Product Definition screen and the Customer Account Maintenance screen), you will have to manually reverse or accept the clearing transaction. In such a case, the individual clearing transaction will be marked as success.

In case a reversal needs to be done for a transaction which was part of the consolidated clearing process, the transaction will be reversed using the Insufficient Funds Reversal Transaction Code maintained in the Clearing Product Preference screen. In case the Transaction Code is not maintained, the Transaction Code used for passing the consolidated clearing entry (of which this instrument was a part) will be used for reversal. Charge entries, if any, will also be reversed using the Transaction Code of the individual clearing transaction.

In case of any other error the individual clearing transaction will be marked as rejected and the transaction will be reversed using Transaction Code used for passing the Consolidated Clearing Entry of which this instrument was a part.

Rejected transactions can be reprocessed as usual. Consolidated Clearing Entry will not be passed while reprocessing rejected transactions.

The values of Insufficient Funds Reversal Transaction Code and the CASA Reversal Transaction Code can be specified in the Clearing Product Preference screen. These fields are applicable only for Inward Clearing products only.

Each individual transaction (Upload table) will be marked with the Reference Number generated for passing the Consolidated Clearing Entry and an option indicating whether reversal has been done or not.

4.3 Notifying Cheque Collection and Clearance

Notifications are generated for successful credit of cheque collection and successful debit of cheque clearance. You can view notifications through the external system which is triggered during the successful processing of the ‘INIT’.A complete list of fields will be sent in the notification. However, the following minimum field level details that need to be sent for cheque clearing are: