7. Fast Accounting

To reduce the accounting processing time during transaction window, the transaction customer account withdrawal balance is updated after performing necessary checks/validations and other functions such as posting accounting entries are processed later, out of the transaction window, as part of an asynchronous job/batch. This is achieved through the Fast Accounting Hand-off routine.

• Fast accounting service is based on the module preference.
• Only the customer balance is updated first and the actual entries are processed later in asynchronous mode.
• Customer entries are processed online but the accounting entry and the related IB/ Position/Revaluation/ FGL hand-off/ Balancing entries get posted on the scheduled Job processing or Batch processing. Similarly GL Entries are logged into an intermediary centralized processing data store and are processed offline through the same scheduled Job / batch process.

This chapter contains the following sections:

• Section 7.1, "Fast Accounting Hand-off routine"
• Section 7.2, "Accounting Entry Monitor"
• Section 7.3, "Intraday Batch Processing"
• Section 7.4, "EOD Batch Processing"
• Section 7.5, "Closure/Redemption/Online Liquidation"
• Section 7.6, "Processing Authorization and Delete Requests"
• Section 7.7, "Handling ECA Request from External Systems"

7.1 Fast Accounting Hand-off routine

The fast accounting service is enabled based on the module preference, and the Module ID is referred from the accounting hand-off. Fast accounting can be opted separately for Online and batch process operations.

Customer Entries are processed online but the accounting entry and the related IB/ Position/Revaluation/ FGL hand-off/ Balancing entries get posted on the scheduled Job processing or Batch processing. Similarly GL Entries get logged into an intermediary centralized processing data store and is processed offline through the same scheduled Job / batch process.

System does the basic accounting validations and all the customer account validations in case of Customer Entry. On successful completion of validations, customer withdrawal balance is updated. In case of multiple entries to the same account, the balance is updated after consolidation.If netting or balancing is enabled, system does the netting or balancing or both and then does the fast accounting process.

Note:

• The ACBCUTOF batch is used to set the Cut Off to tank the subsequent postings. This batch is run before ICEOD Post EOTI batch.
• Marking the branch availability to ‘No’ is done in ACBCUTOFF batch, which has to be configured prior to ICEOD batch.
• Batches ACBCUTOF, ICEOD, DABHOFF to be maintained in the same sequence as mentioned.
• Accrual entries posted during ICEOD batch are processed to accounting tables, in DABHOFF batch, This batch processes all Unprocessed entries till this stage.
• DABHOFF batch to be maintained as first batch at PBOD stage, to perform untank­ing of entries

Dormancy status and Instrument status gets updated immediately after updating the Customer Withdrawal Balance in case of customer entries posted with Instrument number.

Note

• Account available balance, Uncollected balance, Withdrawable Uncollected balance, Receivable, Blocked amts are referred from Fast accounting tables.
• Entries posted through Fast accounting routine can be identified with Group reference no. in accounting tables.
• Posting of Suspense Entries, Accounting fin balance mismatch checks happens at EOFI stage, since all hand-off will be completed only after PEOTI stage in DAB­HOFF stage.

7.2 Accounting Entry Monitor

This section contains the following topics:

• Section 7.2.1, "Re-submitting Failed Jobs"

7.2.1 Re-submitting Failed Jobs

The failed posting due to some reason) entries can be retried/re-submitted after manual corrections using the 'Accounting Entry Monitor' screen. Re-submitted entries get picked up by the same Asynchronous/Intraday Job and are processed. "Process Online" posts the entries in synchronous mode.

The query criteria should be Group Reference Number, Transaction Reference Number, Account Number, Account Branch.

You can invoke the ‘Accounting Entry Monitor’ screen by typing ‘ACDENTRY’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You can specify the following query criteria in this screen:

• Account Branch
• Account
• Transaction Branch
• Transaction Reference Number
• Group Reference Number

Enter any or all of the above query criteria and click ”Execute Query”. The following details of matching records will be displayed:

• Group Reference Number
• Transaction Reference Number
• Account No\GL Code
• Account
• Account Branch
• Currency
• Related Account
• Action

Note

If the accounting entry process fails due to Insufficient IB maintenance, for example, then the same will be listed in ACDENTRY screen and you can make the required corrections and can Re-submit / Process Online. The retry count in the screen is updated based on the no. of times the process gets submitted for hand-off processing.

7.3 Intraday Batch Processing

The intraday batch process AC_DAHOFF runs at regular intervals to post the un-processed entries. This batch will not do the Withdrawal Balance update as it was already updated prior to this.

Once the branch availability status becomes ‘No’, the intraday batch processes only the tanked entries. The job can be started or stopped using the Jobs Browser (CSSJOBBR) - Jobs Browser].On successful completion of entries processing, the status is changed to "P" from "U". On failure it gets updated as "E" with Failure reason.

The batch picks up and process the Save or Authorize/Delete requests alternatively based on the commit frequency and job intervals maintained at the accounting parameterization. When processing the authorization/delete request, system verifies whether all the entries related to that transaction are processed or not. If it is not processed, system will post it first before Authorization/Deletion.

7.4 EOD Batch Processing

The batch program ACBCUTOF changes the branch availability as "No" and processes all the pending transactions. This batch is a predecessor for ICEOD Post EOTI batch. Any subsequent postings done by module would be tanked.

If the IC is enabled for Fast Accounting, the batch DABHOFF should be configured as last batch in Post EOTI (after ICEOD batch) to process all the entries posted by IC. Once the branch cut-off is marked by ACBCUTOF, the scheduled Job excludes this particular branch for processing [except the tanked entries]. The EOD batch processes all the pending entries if any.

Note

It’s recommended to maintain ICEOD & PROVBATCH after ACBCUTOFF, since accruals are to be posted only after hand-off of all balances.

7.5 Closure/Redemption/Online Liquidation

On account closure or TD redemption or IC online Liquidation system posts online and proceeds with any un-processed entries for that Account.

On Period Closure or GL closure, system throws and error if there are any un-processed entries for that Period/GL.

7.6 Processing Authorization and Delete Requests

When system receives an authorization or delete request, below listed operations happen immediately and remaining operations happen as part of deferred centralized job process.

• Basic validations
• Legacy module operations like CL down payment, Salary block, Receivable Blocking for CL guarantor, Group Netting process, CL Accounting process and reconciliation process in case of Delete request
• Update for uncollected fund in case of Delete request
• Instrument update
• Updating account balance
• AML process
• US regulation process
• DD component tracking - IC Owing amount
• Project Accounting entry
• Escrow processing
• Release Tracking if any

Note

• The deferred job process would have action code as either A - for Authorization request / D - for Delete request.
• FA Enabled and FA batch enabled to Be set as L. It should be Y only for Payments and Corporate lending modules.
• For ICEOD batch, FA batch enabled has to be set as N.

Once the accounting is processed, then accounting under Process is cleared and moved to accounting entries block of CSDACENT screen.

You can view the accounting entries maintained for an event in the ‘Accounting Entries’ screen by selecting an event and clicking on ‘Accounting Entries’ button in the’ Events’ screen.

Till the time accounting is in Unprocessed state, accounting entries under process can be viewed in ‘Accounting Under process’ block under ‘CSDACENT’ subsystem (Events -> Accounting Entries subsystem). This block is common for all screens which has the Accounting Entries (CSDACENT) subsystem.

To invoke the screen type ‘CSDACENT’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

7.7 Handling ECA Request from External Systems

ECA requests from external systems are handled in accounting in the following two stages:

• ECA request for Accounts
• Debit on Accounts for the transactions against ECA

This section contains the following topics:

• Section 7.7.1, "ECA Block Request"
• Section 7.7.2, "ECA Cancellation"
• Section 7.7.3, "ECA Debit"

7.7.1 ECA Block Request

On request, balance check and account related validation are done for upcoming debit. The amount for the debit requested is blocked from the account, and the response is send to the external system.

The blocked amount is used for ECA Debit. The block would be active till the approved amount is debited or ECA is cancelled on request. The amount block type “Account” is used for the same.

Note

• No Branch operations are allowed on the Block type - Account.
• Block will have open ended expiry date.

ELCM is utilized in case the account does not have enough balance for the ECA approval. Once the amount block is created successfully the amount block reference number is provided in response.

An open ECA Request which is approved can be cancelled. System would process the ECA cancel request and release the amount block created on ECA approval.

7.7.2 ECA Cancellation

Undo ECA is allowed only if there is an open ECA amount block available. On cancellation of ECA approval, system releases the block amount. Amount block which was created on approval would be marked as ‘Closed’ on ECA Undo.

• If any sweep transaction has been done on ECA approval same would be reversed.
• If any ELCM utilization has been done during ECA approval same would be un-utilized, if the line is revolving.
• Any Debit request on closed ECA request is rejected.
• Partial cancellation of ECA request cannot be done with Undo ECA option
• Once the cancel ECA is successful the confirmation is provided in response.
• ECA debit is a debit transaction which is done against the ECA approval. On ECA debit request system would release the amount block and debit amount from the account. Once the amount is used block would be marked as closed.

7.7.3 ECA Debit

• ECA Debit would be done against a valid ECA ref no and amount block no.
• ECA Block is closed on full ECA release request.
• Once the ECA block is closed system does not allow any additional debit on the ECA approval.
• No account related validations are performed during normal ECA debit.
• Once ECA debit is done system does not allow an ECA undo, and same needs to released.
• In case an ECA Debit is reversed, the same would follow the normal debit reversal flow.
• Once debit is performed, though it is reversed a new ECA approval has to be taken in case the debit is re-done post reversal.
• Overrides during ECA Block creation would be logged
• In case multiple ECA Debit requests are received, same are processed in the order its received
• If the “Amount Block Number” provided is not pertaining to the corresponding debit account number the debit would be rejected