8. Payments and Collections - Operations and Pro­cesses

This chapter contains the following sections:

8.1 Batch Process for the Payments and Collections Mod­ule

This section contains the following topics:

8.1.1 Invoking Mandatory Batch Program Maintenance Screen

Batches are run automatically. In the mandatory programs, all batches whichever are required will be maintained in sequence and that is triggered automatically as based on the maintenance in the ‘Mandatory Batch Program Maintenance’ screen.

You can invoke this screen by typing ‘EIDMANPE’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

Module

Choose the module code from the adjoining option list.

Function Identification

Choose the function ID of batch that you wish to run. The adjoining option list displays all batch processes available for the module. Select the appropriate one.

You can configure the batch to be run at various stages of day like EOD, EOTI etc.

For further details about this screen, refer the chapter ‘Setting- up Mandatory Programs for EOD’ in the AEOD User Manual.

The batch process for the Payments and Collections module contain the following sub-functions:

8.1.2 Periodic Instructions

This process identifies all periodic payments and collection instructions that need to be generated on the current date and generates contracts for those instructions. These contracts are automatically authorized. If the event processing parameter has been set to ‘Online’, then these events are also processed online.

Any failures in generation of contracts are logged into the Periodic Exception queue, from where you can process them at a later juncture.

For details about the Periodic Exception Queue, refer the chapter titled Processing a Payment or Collection Transaction, in this user manual.

If there are failures in online event processing the contracts are generated notwithstanding; the exceptions are logged into the respective exception queue from where you can process them at a later juncture.

8.1.2.1 Approval

This process identifies all outgoing direct debit transactions satisfying the following conditions and marks the collection status as ‘approved’ and the contract status as ‘liquidated’:

8.1.2.2 Redispatch

This process identifies all outgoing direct debit transactions satisfying the following conditions and marks the contract status as ‘liquidated’ and automatically generates corresponding new transactions for redispatch:

For all outgoing request for debit transactions satisfying the following conditions, this process marks the contract status as ‘liquidated’ and automatically generates the corresponding new transactions for redispatch:

8.1.2.3 Closure

This process identifies all outgoing request for debit transactions satisfying the following conditions and marks the collection status as ‘closed’ and contract status as ‘liquidated’:

It also identifies all outgoing request for debit transactions satisfying the following conditions and marks the collection status as ‘closed’. However, the contract status of the transactions remains ‘outstanding’, to enable redispatch of such transactions at a later date:

8.1.2.4 Dispatch to Clearing

This process identifies all contracts that meet the following conditions and dispatches them to clearing using the interface system (Oracle FLEXCUBE Clearing Gateway):

If the Dispatch Accounting option has been enabled for PC products, the system posts the netted (consolidated) entry on the Debit Liquidation Date or Credit Liquidation Date of the PC contracts involving the product. Against each dispatch file reference number a consolidated credit and debit entry will be passed to the Nostro account and multiple debit and credit entries are passed to respective suspense accounts.

Incoming Payments, Outgoing Collections, Reject Of Outgoing Collections and Recall of Outgoing Collections product types are processed on the Debit Entry Liquidation date. Similarly, Outgoing Payments, Incoming Collections, Reject of Incoming Collections and Recall Of Outgoing Collections are processed on the Credit Entry Liquidation date.

For rejected DDs the entries are posted into Nostro Account as Contra entries.

In respect of contracts whose dispatch date is the same as the application date, involving Outgoing Collection Products who’s clearing mode is either external or internal clearing, the dispatch event is triggered before the DRLQ / CRLQ events.

Note

If no dispatch has occurred during the course of a business day for the contracts with dis­patch date as the current business day, for the contracts having dispatch date as the cur­rent business day, a warning message indicating the same during End of Transaction (EOTI) batch process.

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

8.1.2.5 Batch for raising DDs for Tax Relief at Source (TRS)

This process generates a direct debit for Tax Relief at Source (TRS) rebate availed by customers on mortgage loans. It is executed during the End of Day (EOD) process after the LD batch processes. The following details are picked up by the process for raising the direct debit:

You must also consult the Core Services user manual for information about the maintenance in the Bank Wide Parameters, for TRS DD generation.

8.1.3 Periodic Instruction Execution Batch

Periodic Instruction Execution batch is run during BOD to create PC transaction from periodic instruction. The transaction amount for the periodic instruction execution batch is fetched from CL module. Once the transaction is created successfully, the activation date of the periodic instruction will be updated by fetching the next schedule due date of the loan account. The activation date of the PC transaction is the activation date of the periodic instruction.

If the there are no further schedule to be paid then the periodic instruction, maturity date will be updated as the activation date and the next execution date will be derived as Activation Date - Dispatch Date. If there is any change to the schedule due date, the collection due date in the periodic instruction will be modified accordingly.

Note

The PC transaction is created only if the amount due is greater than zero.

The accounting entry posting to the loan account will replace the loan account with Settlement Bridge as maintained in the CL module. During this posting, system also initiates the manual payment transaction in CL for the transaction amount posted in PC.

8.2 Background Processes

This section contains the following topics:

8.2.1 Viewing Background Processes

The Payments and Collections module processes large volumes of transactions during a given business day. In such a scenario, the processing can be configured to run in a background or JOB mode. This mode involves very little or no front-end processing in the online screens, all processing being done by the various background processing jobs of the system.

The following background processes (or jobs) comprise the JOB mode:

You can view the details of progress of jobs executed by the background processes in the System Monitor. Account is displayed for transactions in each stage of their life cycle.

You can invoke the ‘Payment and Collections System Monitor’ screen by typing ‘PCSONMON’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

The following details can be maintained in this screen:

8.3 Jobs Browser

This section contains the following topics:

8.3.1 Invoking the Jobs Browser Screen

You can trigger a background process using the ‘Jobs Browser’ screen. You can invoke this screen by typing ‘CSSJOBBR’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

Here you can query on jobs based on the following criteria:

Job Module

Choose the appropriate one from the adjoining drop-down list.

Process

Specify the process for which you wish to run a job.

Status

Indicate the status of the process.

Click ‘Search’ button. All jobs and processes satisfying the specified criteria will be displayed along with their status and sequence numbers.

Check the box adjoining the desired job and then click ‘Start’ button to run the job(s).

8.4 The Online Mode

When the volume of transactions being processed is not inordinately high, the system can be configured to run in an online mode, wherein all transaction validations are done in the front-end online screens, with user-driven resolution of errors and overrides.

8.5 Contract Partitions

This section contains the following topics:

8.5.1 Invoking the Payments and Collections Partition Sequence Maintenance Screen

Another facility provided by Oracle FLEXCUBE for processing large volumes of payments / collection transactions is data division of the contract tables using range partitioning.

The use of range partitioning divides very large tables and indexes into smaller and more manageable pieces called partitions. Once the partitions are defined, SQL statements can access and manipulate the partitions rather than entire tables or indexes. The method of partitioning used in the Payments and Collections module is Range Partitioning, which maps rows to partitions based on ranges of column values.

The contract table is partitioned based on the column SEQ_NO. The module supports a maximum of ten partitions of the table. The business logic used in the partitioning is that certain customers (institutional) would have extremely high volumes of contracts.

Therefore, for each customer, the value for the SEQ_NO column is maintained, and for contracts of all customers for whom the SEQ_NO is not maintained, the value of SEQ_NO is 1.

The value for SEQ_NO, for a customer, is maintained in the ‘Payments and Collections Partition Sequence Maintenance’ (PCDSQMNT) screen, which you can invoke from the Application Browser.

In the screen above you can maintain the following details:

The important background processing jobs namely, BOOK_INIT, INIT, MISC run on specific partitions only. Multiple copies of these jobs are submitted for each of the partitions. Only data pertaining to the partition applicable to the job is picked up in each of these copies, ensuring parallel processing architecture.

If the number of partitions required is less than ten at an installation (or for that matter, no partitioning), the contract table is created normally at installation without any partitioning. The SEQ_NO for all of the contracts is always 1 and only one copy of each of the background processing jobs is present.

8.6 Customer Consolidation Batch

This section contains the following topics:

8.6.1 Processing of Logging the Batch into Consolidation Summary Screen

You can create a customer consolidation batch at file level based on the following parameters:

You can create more than one consolidation batch for a same customer consolidation reference based on the aggregation parameters.

The closure of the file consolidation batch can be either manually or automatically.

For automatic closure of file consolidation batch:

While closing a consolidation batch manually the system displays an error message if:

During transaction processing the transactions with Customer Consolidation Across Products as 'Yes' will be grouped under a consolidation batch and get logged into the existing Consolidation summary screen. This consolidation batch will have the product code value as 'Null'. The 'CONS' event will be triggered for all transactions that are logged in to Consolidation Summary screen.The Customer consolidation batch at file level shall be created based on the following parameters:

The system can create more than one consolidation batch for a same Customer consolidation reference based on the aggregation parameters.The accounting entry reference number for the file consolidation batch is based on the process code "ZFCN". The closure of file consolidation batch will be through both automatic and manual.

The system will not allow automatic closure of consolidation batch during the day for transactions that are consolidated across products during manual input. The system will internally refer the following logic to consider the automatic closure of consolidation batch:

The system will follows the below logic for automatic closure of File Consolidation batch.

If all the above condition satisfies, then the system performs the automatic closure considering that as the last transaction for the file reference number.

If any transaction is pending in TR queue for the same file reference number, and if the transaction is repaired and processed, the system performs the above processing logic while logging into consolidation summary screen. If transactions are not pending for the same file reference number, then the system performs the automatic closure of the file consolidation batch.

During manual closure of consolidation batch across products, system validate based on the below conditions:

The customer entry date has to be the transaction date for the transactions under the consolidation batch. Otherwise the system will display an error message on click of close button.

If there are any transactions that are yet to consolidated (transaction pending in TR queue) for the same file reference number and if you try to close the batch manually, system will display an error message indicating that the transactions are still pending for consolidation under the same file reference number.

8.6.2 Processing EOD for Expiry of Beneficiary Registration

The EOD will mark all the ‘Customer Debit’ payments and ‘Amount Block’ requests in Beneficiary Registration Queue as ‘Expired’ on the end date for the beneficiary registration if the beneficiary has not registered. This will process reversal of payments for ‘Customer Debit’ payments.

8.7 Notify KYC Status of P2P Beneficiary

You can view the KYC status of the P2P beneficiary through the external system.The system notifies the KYC status of the P2P Beneficiary as ‘Verified’ or ‘Verification Failure’. You can view the following in the notification screen:

The system creates a database trigger to initiate the notification task based on the KYC status of the P2P beneficiary. This displays the data in the notification data store. The existing notification job considers this notification also to notify about KYC status.

8.8 Notify Successful P2P Final Payment

You can view the notification for the successful P2P final payment in the external system.The system notifies the liquidated status of the P2P final payment.This notification displays the entire contract details.

The system creates a database trigger to initiate based on the contract status of the payment.This displays the transaction data in the notification data store.The existing notification job considers this notification also to notify about the liquidation of contracts.

8.9 Notify Rejected Test Transaction and P2P Final Pay­ment

You can view the notification for rejected test transaction and P2P final payment from the beneficiary bank in the external system.This notification displays the contract details.

The system creates a database trigger to initiate based on the contract status of the payment.This displays the transaction data in the notification data store.The existing notification job considers this notification also to notify about the rejection of transactions.

Note

While generating account statement the beneficiary account number will not be displayed for all the P2P payments. During the account statement data assignment for all 'Customer Debit' and 'P2P Final Payment' transactions, beneficiary account number will be replaced by the following:

The EOD PC batch process marks all the customer debit payments and amount block requests, for which beneficiary is not registered, as ‘Expired’ on the end date of beneficiary registration.

8.10 Notify Rejected Status of Payment Request

You can view the notification for Rejected status through the external system. For a payments and collections transactions, the system will generate the reject notification based on the final outcome of the contract processing. If payment gets into the exception queue, then the notification will be generated once the status of the contract changes to reject. If a contract is rejected, then a notification with rejected status is sent.

8.11 Notify for Split Event

You can view the notifications of successful processing of DRLQ and CRLQ event through the external system. In case of split event processing, where debit and credit leg has different value dates, the notification is generated for both debit as well as credit leg of payment processing. Notification is generated only if one of the accounting entries has a customer account. If both debit as well as credit is between a GL and Nostro account, then a notification is not generated.

8.12 Notify for Reversal of Payment

You can view the reversal of payment request notification through the external system. This notification is generated when the contract is reversed, that is the status of the contract becomes ‘V’.

8.13 Notify on Consolidation of Contract

You can view notifications relating to consolidation of contracts through the external system. The notification is generated for the consolidated contract status where in only the customer account processing details are shared and beneficiary details are ‘Null’. Notifications of Rejected Status of Payment, Reversal of Payment, and Split Events are suppressed, if the contract is a consolidated contract.

8.14 Transaction Processing

You can process the following transaction activities for Incoming Payment and Outgoing Collection for the Loan Account.