11. Batch Processes

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.

This chapter contains the following sections:

11.1 Batch Processes for Islamic Financing

This section contains the following topics:

11.1.1 Configuring the Batch Processes for Islamic Financing

You have the facility to configure the batch processes to be executed either at EOD or BOD or both, as per the bank’s requirement. This is achieved through the ‘Automatic Process Definition’ screen. You can invoke this screen by typing ‘CLDTPROC’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

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.

The default configuration is given below:

Batch Operation

BOD/EOD

Forward Init of Finance Accounts

BOD

Calculation

EOD/BOD

Accruals

EOD/BOD

Auto Liquidations

EOD/BOD

Auto Disbursements

BOD

Rate Revisions

BOD

UDE Cascade

EOD

Maturity processing – Rollovers, Auto Closures

BOD/EOD

Automatic Status Change Processing

BOD

FEES

BOD

INTP (Profit Posting)

BOD

Billing & Payment Notices

BOD

Statements generation

EOD

Compensation Computation

BOD

Forward VAMIs

BOD

Revaluation

EOD

Readjustment

EOD

Handover date extension

EOD

These batch processes are factory shipped for your bank. Note that you need to set the ‘UDBATEVT’ batch as a predecessor to the Islamic Financing batch ‘CIDBATCH’.

11.1.2 Defining Batch Processes

The batch processes are explained briefly:

Forward Init of Finance Accounts

Finance accounts maintained in the system are classified into two types:

When finance accounts become Active, the BOOK event is triggered for the Finance and you can specify a Value Date for the finance 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

Finance parameter alterations directly affect the computation of accruals. This batch identifies such changes made to finance accounts, both at BOD and EOD. Further, it recalculates the accruals based on the altered finance 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

Disbursement schedules are maintained for products. As part of BOD process, the DSBR events for the accounts will be triggered.

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.

In case, a single account requires a UDE Change/Cascade, it can be performed online for that account alone. Such accounts are then excluded from this batch.

Maturity Processing

Maturity processing of finances is performed if the maturity date falls at BOD of a particular day. This results in either Auto Closure or Rollover of finances.

Status Change 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.

Notice Generation – Billing, Payments

For each finance, the number of days prior to which a Notice is to be generated is evaluated. In case of finances that carry dues, the Notice is generated as specified in the notice days maintained for the product. This batch is processed at BOD.

Statement Generation

At EOD, the statement is generated depending on the statement frequency and other statement based maintenance actions specified.

Forward VAMI

At BOD, this batch processes all value dated amendments that are booked with the date as Value Date.

Compensation

Compensation 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 compensation 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.

Note

During collateral revaluation, if the collateral/collateral pool amount falls below the linked amount of the account, then the system automatically takes appropriate action.

Readjustment

This batch is processed at EOD. It is triggered in the presence of Index currencies that are not treated as a part of revaluation. It handles readjustments based on new index rates.

Force Final Disbursement

This batch is triggered at BOD and is executed after auto disbursement process in the CL batch. In this process the system validates the amortization start date and check whether the amount financed is equal to the amount disbursed for the particular account. If not, the system will make the final disbursement automatically.

Handover Date Extension

This batch initiates automatic extension of the property handover date. In a forward Ijarah and Musharaka under construction account, if the ‘Property Handover’ box is not checked till the specified handover date, then on the handover date this batch will extend the handover date to a new date. The new date will be arrived based on the values of the fields ‘Unit’ and ‘Frequency’ given for auto extension of handover date in the product preferences. Holidays will be ignored for the handover date derivation. The system will also move the first installment date and maturity date of the account. Post this extension; the system will also recalculate the profit and schedules for the period from construction end date to the new handover date and from new handover date to maturity date.

The system will also trigger the event for the additional profit calculated due to this extension.

11.1.2.1 Batch Process for Rental Advice

System generates rental advice during CI batch processing. Rental advice is generated 'N' days prior to the due date of the schedule type maintained in the ‘Notice and Statements’ screen at product level.

Time based advice process will fetch the rates i.e. effective as on the actual rate revision date and calculate the rental amount for the next rental period.

If ‘Adjust Compensation to Next Rental’ field is checked at product level (CIDPRMNT), then the system, will modify auto liquidation process to recover the compensation amount only till last billing notice generation date.

Moving the overdue rental to next rental period is applicable for auto liquidation only.

11.2 CL Batch

This section contains the following topics:

11.2.1 Initiating the Batch Process

If you have opted to trigger the 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. Note that you can process the transactions booked under the Retail lending module too using this batch process. You can invoke this screen by typing ‘CLDBATCH’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

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.

11.2.1.1 Multi-threading of batch processes

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.

11.2.2 Status Change Batch Processing (CSDSTBTC)

For the CI module the Status change batch will be run along with the customer/Group and apply worst status change for the customer. This batch will use the status change events.

You can trigger the batches to run before the Common Status Change batch (CSDSTBTC).
The following given batches can be run in any order:

The Process of Provisioning is handled by the following batches for CL, MO and CI modules respectively:

Note

The provisioning process is detached from the CLBATCH, MODBATCH and CIDBATCH.

If ‘Status Processing’ is at Individual Contract Level, then system will trigger status change based on the Customer Credit rating for the customer of the Contract /Account booked. The other contracts of the customers in the same Group will not be impacted. However if the ‘Status Processing’ is at CIF/Group level individual module (LC,CL, CI, MO, CA, IA and BC) batches will be updating common storage with the derived status of each contract and CIF/Group level status will be triggered by the common status change batch. The common status change batch will call the individual module function for status change processing.

11.2.3 Profit Posting (INTP Event)

You need to make a provision to post an income into a separate GL. This income is the profit which you pay to the customer who has a finance account. On the profit 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 profit posting is applicable for the main profit component only.

The INTP event runs at the BOD for a finance product against which it has been defined.

The following points are noteworthy:

In case of any failures during the INTP batch process, the system logs the error details for the account and processes the subsequent accounts.

11.2.4 Intra Day Accruals

The Intra Day Accruals is a batch process that computes accruals for different kinds of investments made by funds. This batch includes processing of fixed asset depreciation. The intraday accruals / depreciation are performed only for those products for which accruals / depreciation cycle is due for the day. In case of inter-fund subscriptions, the system does not calculate the profit for the investing fund. You can invoke ‘Intra Day Batch Start’ screen by typing ‘BABIDBAT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

This is an intra day process that is applicable only to fund branches.

Intra Day Accruals work in line with the normal end of day accruals. Intra day accrual will process in the same manner as an End of Day (EOD) batch. In this module, it is processed based on the branch level accrual parameters.

11.2.5 Insurance Renewal Batch

Oracle FLEXCUBE allows you to execute a batch process ‘INSR’ to renew insurance for all active Islamic Financing accounts automatically. When you run this batch process at EOD, the system will pick up all active records, for which the option ‘Insurance Required’ is selected in the ‘Product Maintenance – Main’ screen and the insurance renewal is due. Note that the system computes the date of renewal for the applicable records based on the value maintained in the ‘Insurance Renewal Before days’ field in the ‘Consumer Lending – Branch Parameters’ screen. If the renewal is due on the current date, the system will renew the policy for the next year by updating the policy expiry date.

As part of the renewal, the system will trigger the INSR event and transfer the insurance premium collected from the customer to the insurance company account maintained in the ‘Bills and Collections Insurance Company Maintenance’ screen. In case of short collection in the customer’s insurance account, the system will credit the customer’s insurance account with the differential amount i.e ‘premium for the year – sum of monthly premiums collected’ and debit the receivable account. When the payment is recovered from customer, the system will credit the receivable and debit the customer’s insurance account for the differential amount.

11.3 CL User Defined Events Triggering

This section contains the following topics:

11.3.1 Triggering User Defined Events

You can use the ‘CL User Defined Events Triggering’ screen to manually trigger the user defined events for Islamic Financing accounts. You can this screen by typing ‘UDDCLEVT’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Here you need to specify the following details:

Account Number

Specify the account for which you want to trigger the user defined event. The adjoining option list displays all valid account numbers available in the system. You can select the appropriate one.

Branch Code

The system displays the code of the branch where the account resides.

Click ‘Default’ button. The system fetches values for the following fields based on the selected contract and displays them:

Event Sequence Number

The system displays the event sequence number.

Event Code

Specify the event that needs to be triggered for the selected account. The adjoining option list displays all events linked to the account. You can select the appropriate one.

Value Date

If the value date derivation rule has been maintained for the event code, the system will calculate the value date and display it here. However, you can change it.

Payment Remarks

Specify remarks pertaining to the payment on the account.

Amount Details

Specify the following details.

Amount Tag

The amount tag is displayed based on the product-level maintenance of the specified account.

Description

The system displays a brief description of the amount tag.

Currency

If a derivation rule has been maintained for the event code, the system will derive the currency as per the rule and display it here. However, you can change it.

Amount Paid

If a derivation rule has been maintained for the event code, the system will derive the amount as per the rule and display it here.

Settlement Branch

Specify the branch where the settlement account resides. The adjoining option list displays all valid branch codes maintained in the system. You can select the appropriate one. Alternatively, if you have specified the settlement account, the system will display the corresponding branch code here.

Settlement Account

Specify the account that should be debited or credited. The adjoining option list displays all valid accounts maintained in the system. If you have specified the settlement branch, the option list will display all accounts available in that branch. You can select the appropriate one.

11.3.2 MIS Button

Click ‘MIS’ button the screen and invoke the ‘MIS’ screen.

You can view the following details:

The ‘Transaction MIS’ tab opens by default.

Here you can view the transaction MIS codes.

11.3.2.1 Composite MIS Code Tab

Click this tab to view composite MIS codes.

11.3.2.2 Fund MIS Tab

Click this tab to view fund MIS codes.

11.3.2.3 Viewing Rate Details

Click ‘Rate’ button on the ‘MIS’ screen and invoke the ‘Rate Details’ screen.

Here you can view the following details:

11.3.2.4 Viewing Amendment Rate Details

Click ‘Amendment Rate’ button and invoke the ‘Rate Details’ screen.

Here you can view the following details:

11.3.2.5 Viewing Change Log

Click ‘Change Log’ button on the ‘MIS’ screen and invoke the ‘Change Log’ screen.

If MIS reclassification occurs, through changing the MIS codes for transaction or composite classes, the System stores the changes made, in a Contract MIS Change Log. The following details are stored in the Contract MIS Change Log for the contract in respect of which the MIS reclassification occurred:

11.3.2.6 Viewing Balance Transfer Log

Click ‘Balance Transfer Log’ button on the ‘MIS’ screen and invoke the ‘Balance Transfer Log’ screen.

When an MIS reclassification occurs in respect of a the account, the balances in a GL associated with the old MIS code in each case are transferred to the GL for the new MIS code, if the option of transferring MIS balances upon reclassification has been set in the ‘Chart of Accounts’ screen for the GL.

You can view the following details:

11.3.3 Charge Button

Click ‘Charge’ button on the ‘CL User Defined Events Triggering’ screen and invoke the ‘Charges’ screen.

You can view the following details:

11.3.4 Events Button

Click ‘Events’ button on the ‘CL User Defined Events Triggering’ screen and invoke the ‘Events Diary’ screen.

11.3.4.1 Unprocessed Tab

Click this tab to view the unprocessed event details.

Refer the section ‘Events Diary’ in the chapter titled ‘Account Creation’ in this User Manual for details about the ‘Events Diary’ screen.

11.3.5 Event Fields Button

Click ‘Event Fields’ button on the ‘CL User Defined Events Triggering’ screen and invoke the ‘Fields’ screen.Here you can view the UDFs and their values linked to the account.

Click save icon after specifying the details in order to trigger the event for the specified account. This record needs to be authorized for the event to be triggered.

Note that, you will not be able to perform any operation on the account on which there is an unauthorised event triggering record.