Batch Processing

6.1 Introduction

The End of Cycle process constitutes a set of programs that mark the logical beginning or end of a cycle of events. You are required to execute many routine functions everyday as part of the End of Cycle process. These functions can be classified as:

 Beginning of Day (BOD) programs; and  End of Day programs (EOD)

The various BOD and EOD functions that are processed by the system are documented in this chapter.

6.2

Processing Daily Events

As part of the batch processes the following are the events that will be selected and processed:

 Settlements

 Accruals/Amortization  Revaluation population  Revaluation processing

The batch function identifies the previous process till date (the date till which the previous batch was run) and the current process till date (the date till which the current batch is being run) for the current batch run. It then considers the type of batch being run. This can be either Beginning of Day(BOD) batch run or End of Day(EOD) batch run.

Based on the parameters you have specified at the time of maintenance, the function selects the various events in the following order:

 Events that have to be processed only once in a batch run and are applicable for the

type of batch being run whether BOD or EOD.

 Events that have to be run for all holidays falling between the previous process till date

and the current process till date.

 Events that have to be run on every processing date and are applicable for the current

type of batch being run for all the working days of the batch

6.2.1

Invoking the Automatic Daily Program

To run the Derivatives Daily Events program, it is necessary that you first maintain it as a Mandatory Program. For example, you need to maintain the function ‘DVBAUDLY’ as a mandatory program to execute the End of Day batch. You can invoke the screen by typing ‘EIDMANPE’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Refer the Automated End of Day User Manual for further details about running an EOD batch.

6.3

Triggering the Year-end Batch process for collecting

Contract-wise Data

The year-end batch process can be triggered to collect data pertaining to the unrealized income booked for each contract during the year. You will be allowed to trigger this process only if you have enabled the Track PY PnL Adjustment option for your branch through the Preferences section of the ‘Branch Parameters’ screen.

During liquidation the information that is collected using the batch process is used to post adjustment entries to the previous year adjustment GL.

You must ensure that you execute this batch process prior to executing the Year-end P and L balance transfer batch. The balances pertaining to the unrealized income booked for each contract during the year will be stored at the Contract, Component and Currency level. For unrealized accruals the batch process stores data for the in leg and out leg interest components and for the unrealized accrual of termination gain/loss. For advance contracts, unrealized accrual signifies accruals for those schedules which have liquidated but for which accruals have not been completed. For arrears contracts, unrealized accrual is indicative of the amount accrued until date for those interest schedules which are yet to be liquidated. For

termination gain or loss, unrealized accrual is the amount accrued for a terminated contract, which has not yet reached maturity.

6.3.1

Upload of DV Contracts

Oracle FLEXCUBE provides the facility of holiday treatment for principal schedules, interest and interest revision schedules of a DV online contract based on Multiple-currency and Multiple-financial center if the following conditions are satisfied.

 The derivative type for the product allows combined holiday treatment.

 The holiday treatment at the contract level (for principal, interest or revision schedules)

is specified as Currency or Financial Center.

You can specify the details of currencies or financial centers for combined holiday treatment for uploaded DV contracts in the table shown below:

If the value of CCY_OR_FINCENTER is C, then the value provided in CCY_FIN_CENTER must be an authorized and open currency.

If the value of CCY_OR_FINCENTER is F, then the value provided in CCY_FIN_CENTER must be an authorized and open clearing house.

You must provide details of the list of currencies or financial centers from the above table if the derivatives type for the uploaded product supports combined holiday treatment and the holiday treatment for a specific component and schedule type is set as currency or financial center.

Column Name Data Type Lengt_h Description

BRANCH_CODE Character 3 Branch Code

SOURCE_CODE Character 20 Source Code of the external sys- tem

EXTERNAL_REF_NO Character 16 Unique Reference Number of the contract being uploaded

COMPONENT Character 10 INLEG_PRN => Principal of the in leg

OUTLEG_PRN => Principal of the out leg

DV_IN_INT => => Interest of the in leg

DV_OUT_INT => Interest of the out leg

CCY_FIN_CENTER Character 3 Currency code or Clearing house CCY_OR_FINCENTE

R

Character 1 C => Currency F => Financial Center SCHEDULE_TYPE Character 1 P => Principal

I => Interest R => Revision

When holiday treatment has been set as combined but schedule holiday treatment has been set as ‘ignore’ or ‘Local’ at the specific component level then the data provided in the combined holiday treatment table will not be considered by Uploaded schedules.

In case of synchronous schedules for principal or interest supported by the derivative type, the OUT leg holiday preference will be defaulted from the IN leg and the already provided OUT leg will be ignored. While in case of synchronous revision for IN or OUT legs for interest revision supported by derivative type, IN/ OUT revision holiday preference will be defaulted from IN/ OUT interest holiday preference.

In case of asynchronous schedules if you have to specify the holiday treatment in the existing upload tables as Currency/ Financial center for IN and OUT legs and the holiday treatment in type maintenance is defined as combined, then you must provide for combined holiday treatment details for IN and OUT leg separately else an error is displayed. If the holiday treatment has been specified as Ignore/ Local for the component in the existing table, then the new upload table for combined holiday treatment will be ignored for that component and schedule type.