RL11 Batch
RL11 Batch
Introduction
The events that are to take place automatically are triggered off during what is
called the Batch Process. The batch process is an automatic function that is run as
a mandatory Beginning of Day (BOD) and/or End of Day (EOD) process. During
EOD, the batch process should be run after end-of-transaction-input (EOTI) has
been marked for the day, and before end-of-financial-input (EOFI) has been
marked for the day.
In this screen, you can amend the order of the various operations in the CL batch
and choose to trigger them at EOD or BOD or both.
Retail Lending
378 FLEXCUBE Corporate
Calculation EOD/BOD
Accruals EOD/BOD
FEES BOD
Revaluation EOD
Readjustment EOD
Retail Lending
Batch Processes 379
Loan accounts maintained in the system are classified into two types:
Active
Inactive
When loan accounts become Active, the BOOK event is triggered for the Loan
and you can specify a Value Date for the loan during this event.
This batch identifies all the accounts that are due for initiation on that day, at
BOD and the INIT event is triggered for these accounts. The current system date
will be taken as the value date for these accounts.
Re-Calculation
Loan parameter alterations directly affect the computation of accruals. This batch
identifies such changes made to loan accounts, both at BOD and EOD. Further, it
recalculates the accruals based on the altered loan components.
Accruals
This batch passes all the recalculated accrual changes required for the
components. It is triggered, both at BOD and EOD.
Auto Liquidations
This batch processes the payments that are configured as auto payments and is
triggered both at BOD and EOD.
Auto Disbursements
Retail Lending
380 FLEXCUBE Corporate
This batch processes these schedules at BOD, which enables the DSBR events of
the accounts to be initiated.
Rate Revision
As part of BOD program, this batch processes the Floating Rate revision
schedules for products.
UDE Cascade
This batch is triggered at EOD in case of UDE value changes. The changes in
UDE values are applied to all the affected accounts.
Maturity Processing
Auto Closure: Loans that are liquidated on maturity are subject to Auto
Closure, during maturity processing.
Rollover: Loans that have auto rollover maintained are rolled over during
maturity processing.
Certain accounts have automatic status changes, wherein the SDEs required for
status change are evaluated. In such cases, this batch detects status changes at
BOD. Once this is done, appropriate status change activities are triggered.
For each loan, the number of days prior to which a Notice is to be generated is
evaluated. In case of loans that carry dues, the Notice is generated as specified in
the notice days maintained for the product. This batch is processed at BOD.
Retail Lending
Batch Processes 381
Statement Generation
Forward VAMI
At BOD, this batch processes all value dated amendments that are booked with
the date as Value Date.
Penalty
Penalty computations are evaluated at BOD by this batch. Any grace period
maintained will have to be considered during this calculation. On completion of
the grace period, the penalty components are computed from the due date till the
current date.
Revaluation
At EOD, revaluation of assets and liabilities to the LCY are carried out.
Readjustment
If you have opted to trigger the CL batch programs at EOD, the same will be
executed as part of the ‘End of Cycle Operations’ after marking the ‘EOTI’ for the
day. If the trigger is maintained as ‘BOD’, the programs will be executed before
the start of ‘Transaction Input’. However, the programs will be triggered both at
EOD and BOD if you opt to trigger it at both the instances.
You also have the option to execute the batch programs through the ‘CL Batch’
screen. To access this screen from the Application Browser, select Retail Lending,
choose CL Batch and then select End of Cycle.
Retail Lending
382 FLEXCUBE Corporate
You can opt to execute the processes as per the sequence maintained in the
‘Automatic Process Definition’ screen. To do this, check the ‘Run Sequentially’
option.
The CL Batch process handles multi threading. The number of parallel processes
and the interval between processes is maintained as part of ‘CL Branch
Parameters’.
Refer the section titled ‘Maintaining Branch Parameters’ in the ‘Maintenances and
Operations’ chapter of this User Manual for details.
The accounts are split into multiple groups which can be processed in parallel for
a particular sub process. Hence, all non conflicting parallel groups will complete
the sub process after which the next sub process is taken up and so on. There is
also an option to run it purely sequentially as shown above.
Retail Lending
Batch Processes 383
A member account is owned by a single member, but a loan account can be co-
owned by several members in a certain ratio. Each member could be a borrower
in multiple loans. For these reasons the amount allocations are necessitated.
To enable this fund allocation the rebate batch is run at the bank level. Common
Settlement Account maintained in ‘Rebate Account Preferences’ screen is used as
the ‘Common Bridge Account’. This will have the combined balance of all the
member accounts, which can be utilized for loan re-payment. The Rebate account
processing batch will provide the details like the member account number
(CASA account), the member (CIF number) and the excess amount for the
member. This data will act as the input for this batch program.
It will get the due details for the next schedule of each loan, along with the
Liability Split %. This will include the overdue amount, if any.
Allocate the excess amount of each member to his loans, with the earliest
unpaid schedule first.
Retail Lending
384 FLEXCUBE Corporate
The due date of the schedule will be considered by the allocation batch for
allocating the payments. The batch will ensure that the available amount is
used to make advance payment for the immediate next component due
before considering the next.
While allocating the amount for the next schedule, the available amount
will be available amount minus the amount already allocated against the
previous schedule.
With this info, CL payment will be triggered for each loan account. This will
be an advance payment (not Pre payment) for an aggregate amount and
will be initiated according to the liquidation order maintained for the
components.
On successful payment, process status will be changed to ‘P’ for all the
records with this Loan account number.
Status will be changed to ‘E’, in case of any error during the payment. As
per the current functionality, the error details will be available in the
exception table.
After correcting the errors, you can re-initiate the process which will
exclude the already processed loan accounts.
Further generation of Payment advice will derive the amount after
considering the amount paid through this batch process.
You need to make a provision to post an income into a separate GL. This income
is the interest which you pay to the customer who has a loan account. On the
interest posting date, a transaction occurs to move the receivable and the income
from one GL to another. This transaction distinguishes between receivables from
the income which is due and not due. Also, this interest posting is applicable for
the main interest component only.
The INTP event runs at the BOD for a loan product against which it has been
defined.
Retail Lending
Batch Processes 385
You can pick the INTP event during the loan product definition and
maintain the accounting entries against this event. To recall, you need to
click on the ‘Events’ tab in the ‘Consumer Lending Product’ screen where
you specify the various events which need to be run.
At the time of loan account creation, FCC populates the events diary with
one record of the INTP event for each schedule due date. This has the status
as ‘Unprocessed’. This is done for the main interest component schedule
only.
The system also creates a record for the end of each calendar quarter during
the moratorium period in the case of amortized loan products.
Any rebuilding of repayment schedules results in the rebuilding of records
in the events diary.
The batch process picks up all the unprocessed INTP records from the
events diary having the execution date on or before the current application
date. The process is limited to the active accounts belonging to the current
branch.
The amount and date of due for the main interest component is fetched
from the component schedule due details.
The accounting entries get passed on the schedule due date or the calendar
quarter end, as defined for the event INTP through the ‘Consumer Lending
Product’ screen under the ‘Events’ tab pertaining to a loan product
maintenance.
For term loans, the transaction posting date is the same as schedule due
date of the main interest component. The same is followed for amortized
loans also.
For an amortized loan with a moratorium period, the transaction posting
date is the end of the calendar quarter and the end of the moratorium
period. If the moratorium period is different from the end of the calendar
quarter, the entries passed will not tally with the actual amount due. This
difference gets passed on the schedule due date of the moratorium period.
There are no changes in the INTP event execution behaviour in case of a
partial pre-payment.
Retail Lending
386 FLEXCUBE Corporate
Retail Lending