Cheque Issue Management

  • Uploaded by: abu huraira
  • 0
  • 0
  • January 2021
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Cheque Issue Management as PDF for free.

More details

  • Words: 4,896
  • Pages: 52
Loading documents preview...
How to Issue Cheque and it’s management? T24 provides functionality for banks that have requirements to manage the issuing and registration of cheques and bank drafts issued to their clients. Banks can record requests for chequebooks ordered by customers and when these cheques are received from the vendors, issue them to the appropriate customer. When a chequebook is issued to the client, the range of the cheque numbers will be recorded into a cheque register. Furthermore, when cheques are stopped or returned, this can also be recorded in the cheque register. When cheques are presented, this is stored in a CHEQUES.PRESENTED file. There is also the functionality to charge the client for the issuing of cheque books, for charges to be applied on the usage of cheques by the customers, and also a periodic charge for possession of a cheque book. On the presentation of a cheque, the cheque register is consulted to confirm that:  

The Cheque number is valid for the account on which it is drawn; The Cheque has not been stopped by the client

Furthermore, the CHEQUES.PRESENTED file is also consulted to confirm that the cheque has not already been presented elsewhere. When a cheque does not conform to the above rules, an override is requested. If the override is accepted the cheque may still be used. On completion of the above transaction the cheque register and CHEQUES.PRESENTED file is updated with the last status on the cheque. Banks can issue cheques and drafts drawn on them. Details for these are stored in a similar manner to customer cheques. Further details regarding the following could be obtained from the system if required.    

The The The The

name of the client to whom the cheque/draft was issued. beneficiary of the cheque. amount and currency of the cheque. date and place of issue.



The cheque number.

Processing Initial Set up There are 2 parameter files which can be used for cheque processing; CQ.PARAMETER and ACCOUNT.PARAMETER. The system will first check the CQ.PARAMETER record, if the system does not find the required setting here it will check the ACCOUNT.PARAMETER record. However, not all of the functionality available on CQ.PARAMETER is available on ACCOUNT.PARAMETER.

Figure 1 – Example CQ.PARAMETER record

Figure 2 – ACCOUNT.PARAMETER for cheque processing

To enable cheque-processing, the CHEQUE.REGISTER field on the CQ.PARAMAETER or ACCOUNT.PARAMETER application needs to be set to a value of ‘YES’. CHEQUE.TYPE The first step towards issuing cheques on accounts is to set up a CHEQUE.TYPE record. This record will allow you to specify certain default parameters associated with a class of cheques.

Figure 3 – CHEQUE.TYPE

CHEQUE.STATUS The CHEQUE.STATUS record ‘90’ is delivered and is the default record. Additional CHEQUE.STATUS records should be created within the range 01-99. Various cheque status like Cheque request received, Cheque sent for printing, Issued etc can be maintained. This will then be used to track the request in the CHEQUE.ISSUE application.

Figure 4 – Example of potential CHEQUE.STATUS records

Figure 5 – CHEQUE.STATUS record

Setting up a charging structure for the issuing of cheques The user can set up the charging rules in the CHEQUE.CHARGE application to levy charges on cheques issued, cheques used, and also a periodic charge for having the cheque facility. FT.CHARGE.TYPE and FT.COMMISSION.TYPE can be used in this application in field CHARGE.CODE, the value in the field CHARGE.CODE must be a valid entry on either FT.CHARGE.TYPE or FT.COMMISSION.TYPE table and this has been linked to CHEQUE.ISSUE application.

Figure 6 – CHEQUE.CHARGE

Linking a transaction code to a cheque type In order to invoke the processing that will validate cheques issued to a client account, a TRANSACTION record will need to be linked to the CHEQUE.TYPE. The transaction code used in the accounting entry raised for the cheque transaction must be linked into a CHEQUE.TYPE record for the system to perform the extra validation associated with cheque issue and management. An example of this has been illustrated as under:

Figure 7 – Linking cheque processing to TRANSACTION code

Issuing & Registering of Cheques Cheques are issued to clients through the CHEQUE.ISSUE application. This application has been linked to soft delivery by triggering delivery messages on cheque status change.

Figure 8 – Issuing cheques CHEQUE.STATUS REQUEST RECEIVED

In the example above the client account 10178 has requested an issue of Cheques, of the cheque type ‘CURR’. The field CHEQUE.STATUS is used to keep track of cheque issue status. When entering CHEQUE.STATUS in CHEQUE.ISSUE the system will not allow a status less than the existing status for the record. Input of a new record is allowed for the account only when the cheque status is more than ‘90’ (i.e. issued). In the above example a status of 70 is REQUEST.RECIEVED. Once the cheques have been issued

Figure 9 –CHEQUE.ISSUE status ‘90’ issued

The CHEQUE.REGISTER is updated as shown below:

Figure 10 – Cheque register

As seen in the figure above account number 10178 now has cheque 100001100025 issued to it. An additional request has been placed on the account 10178, in this example you can see that the client is being charged for the issue of these cheques.

Figure 11 – Additional request for CHEQUE.ISSUE

The CHEQUE.REGISTER is updated as below.

Figure 12 – CHEQUE.REGISTER

The history of charges debited under various stages and the history of date of statuses will be stored in CHEQUE.CHARGE.BAL for reference by the Bank.

Figure 13 – Example CHEQUE.CHARGE.BAL for issue of cheques

Presenting a Cheque

Once a cheque has been presented through FT, TELLER or DATA.CAPTURE, (the field CHEQUE.NUMBER in the application must be input) the file CHEQUES.PRESENTED is updated with the date that it was presented on. The key to this file is the account number and the cheque number.

Figure 14 – CHEQUES.PRESENTED

RE-ORDER PROCESS Cheques can be reordered manually using the CHEQUE.ISSUE application as detailed previously or, during COB, the accounts that have reached the minimum holding level of cheques will be identified and new cheque issue records will be automatically created with status as defined by user. Banks can follow this record, for automatic delivery of chequebooks to customers as a reorder process. Issuing Bank Drafts Bank drafts and cheques issued by the bank may be registered using the same procedure as that detailed above, with the difference of using a Nostro account instead of a client account. Thus a new cheque type for bank drafts would need to be set up (with “Nostro accounts” as the category field), and a TRANSACTION record to be used when issuing drafts. The TRANSACTION record would have to have ‘CREDIT’ flagged in the DEBIT/CREDIT indicator (as opposed to debit for client cheques). No CHEQUE.CHARGE record would be required. It should be noted that at present it is not possible to run a TELLER or FUNDS.TRANSFER deal where both sides of the transaction refer to TRANSACTION records where the CHEQUE.IND field is set to YES. In other words, it is not possible for a client to buy a registered bank draft, using their own registered cheques.

Presenting a cheque presented earlier The following screen shot depicts how the system responds when attempting to present a cheque already presented earlier to the system.

Figure 15 – Cheque already presented

This is because in the CHEQUES.PRESENTED file there is already a record of this cheque having been used. If we say ‘Yes’ to the override; the CHEQUES.PRESENTED file gets updated, and the REPRESENTED.COUNT field is updated.

Figure 16 – CHEQUES.PRESENTED

Stopped Cheques The PAYMENT.STOP.TYPE application is used to enter different reasons for placing a stop. The following is an example of a typical PAYMENT.STOP.TYPE

Figure 17 – Example PAYMENT.STOP.TYPE

The PAYMENT.STOP table allows all payment stop instructions to be recorded. These are input against the account to which they relate. All stop instructions for one ACCOUNT number is maintained on the same record. The DATA.CAPTURE, TELLER and FUNDS.TRANSFER applications then use this record to validate against when processing a cheque. Charges and taxes can now be collected for the stop payments recorded. Charges can be a valid charge or commission code

from FT.CHARGE.TYPE or FT.COMMISSION.TYPE and can be defaulted from the PAYMENT.STOP.TYPE or can be defined by the user for the particular stop payment. If a tax is associated with these charges then the tax is also booked. When the WAIVE.CHARGE field is set to ‘NO’ or holds no value then the charges can be defaulted from the above PAYMENT.STOP.TYPE.

Figure 18 – Stopping a cheque

When the payment stop record is authorised the details of the charges and taxes collected are moved to a live file PAYMENT.STOP.BALANCES whose id is the same as the PAYMENT.STOP file.

Figure 19 – PAYMENT.STOP.BALANCE record

The field MOD.PS.CHQ.NO in PAYMENT.STOP can be used to revoke either a single cheque or a range of cheque numbers can be entered

Figure 20 – Revoking a PAYMENT.STOP

The details of the revoked PAYMENT.STOP are populated in PAYMENT.STOP.HIST. The user will have the option to revoke the stop payment instructions for a particular cheque number or a range of cheque numbers at his discretion.

Figure 21 – History of stopped payment

The CHEQUES.STOPPED file as shown under:

Figure 22 – CHEQUES.STOPPED record for cheque no. 000005

Now when an attempt is made to use a stopped cheque on a transaction the system responds with an override message that has been illustrated in the figure below:

Figure 23 – Attempted presentation of a stopped cheque

If the answer to this override were ‘Y’ then the FUNDS.TRANSFER record would record this message into its OVERRIDE fields. SWIFT MT111 SWIFT message MT111 (Request for Stop Payment of a Cheque) can be produced from the application EB.MESSAGE.111. Incoming SWIFT MT111 is processed using OFS.GLOBUS.MANAGER and a PAYMENT.STOP record is automatically created. SWIFT MT112 SWIFT Message MT112 (Status of a request for Stop Payment of a Cheque) is produced from the PAYMENT.STOP application, via Soft Delivery. Setting the field RAISE.ACTIVITY to ‘Yes’ will: 1.

Allow input to be made in the following fieldsDATE.OF.ISSUE ACTION.DATE OUR.REFERENCE MESSAGE.REC PAYEE ANSWERS 2. Populate the following system Delivery fields – MT112.CHEQUE.NO MT112.AMOUNT 3. Raise a Delivery Activity. Inward MT112 will be directed to print by the system. Returned Cheques If a cheque is to be returned, then, by entering ‘YES’ in the RETURN.CHEQUE field on FUNDS.TRANSFER, it automatically returns a cheque, taking the payment from a return suspense account as set in either the CQ.PARAMETER or ACCOUNT.PARAMETER. The account that the transfer was originally to have been from is then stored in DRAWN.ACCOUNT, which is found on both the FUNDS.TRANSFER and STMT.ENTRY applications. The ranges in CHEQUE.REGISTER are maintained as normal.

Deposited Cheque Collection The system handles the collection of deposited cheques; this is in addition to the normal method of clearing cheques. The cheque clearing system takes cheques entered through TELLER, FUNDS.TRANSFER or DATA.CAPTURE and creates a Cheque Collection Record for each cheque. The cheque collection record can be processed individually or through CHEQUE.BATCH, that groups batches of cheques together for processing. The processing caters for cheques deposited into the T24 bank that clear in a certain or uncertain number of days. For example foreign cheques may take an uncertain number of days to clear, with this functionality T24 can deal with this. While the cheques are waiting to be collected the funds are posted to a Suspense account. Upon the successful collection, the funds are then credited to the customer. If the cheque is returned then funds in suspense to are returned to a suspense account. Set-up The cheque collection functionality is triggered by TRANSACTION codes. New transaction codes are created to indicate whether processing is required or not. After the new transaction codes have been created they are input onto the Account parameter record. For every transaction created through FUNDS.TRANSFER, DATA.CAPTURE or TELLER, the system checks the CQ.PARAMETER and ACCOUNT.PARAMETER record for the transaction code. If the transaction code is not found on the either record, the Cheque Collection processing is by-passed. Transaction codes New transaction codes must be created as a means of identifying the transaction to be processed through the cheque collection processing. There are three methods of deciding which suspense account the funds go to for clearing and returns, the suspense category is either defined on the BC.SORT.CODE record, the CQ.PARAMETER or ACCOUNT.PARAMETER record with the transaction code. The transaction code decides where the funds should be posted, there are a minimum of three transaction codes required on the CQ.PARAMETER and ACCOUNT.PARAMETER record. A transaction code must be created for the Collection of Cheques, the Clearing of Cheques and the Return of Cheques. Multiple transaction codes can be set for each of the mentioned cheque actions. The CQ.PARAMETER and ACCOUNT.PARAMETER accepts

multiple TRANSACTION codes as a unique transaction code could be created for FUNDS.TRANSFER, DATA.CAPTURE and TELLER. For example a cheque is deposited using a TRANSACTION code that is on the ACCOUNT.PARAMETER record, the transaction is then posted to the collection suspense account (as defined by the collection category code on the ACCOUNT.PARAMETER record) and a CHEQUE.COLLECTION record is created.

Figure 24 – Cheque deposited sent for collection transaction code

Figure 25 – Example TRANSACTION record

Figure 26 – Example TRANSACTION record

The above example transaction codes will be used through the remainder of this manual. The transaction codes are entered onto the ACCOUNT.PARAMETER record and also used by the Teller Transaction codes. Category Code New CATEGORY codes will need to be created to enable the set up of the new suspense accounts. These category codes specify which suspense account the funds should be held in. The category codes can be defined on the CQ.PARAMETER, ACCOUNT.PARAMETER record and/or the Bank sort code record, the differences will be explained later on. There must be at least one category code for each transaction code. The category codes must be between the range of 10000 and 19999, thus defining them as internal accounts.

Figure 27 – Cheque collection suspense category

Category Codes and Interest Adjustments It is possible through fields on the ACCOUNT.PARAMETER application to configure the CATEGORY codes used to book adjustments to the previous year and month, for all types of interest (Debit, Debit2, Credit and Credit2). At correction time of a previous capitalisation the system will compare the capitalisation date against the last FINANCIAL YEAR.END. In the COMPANY record and if the correction date falls in the last year the P&L adjustment will be posted to the last year category, if not it will be posted to this year. Debit interest adjustment categories must be in the range 51000 to 51999 and credit interest adjustment categories must be in the range 50000 to 50999.

Figure 28 – Cheque categories entered onto the ACCOUNT.PARAMETER

Suspense Accounts Internal suspense accounts need to be created for each CATEGORY code. These internal suspense accounts are updated when the corresponding transaction codes are used in a transaction. As there are three main category types required so too is there a need to create a minimum of three internal Suspense accounts. As the cheque progresses through the deposited Cheque Collection system, the funds move with it through the internal suspense accounts until the cheque is cleared. If the cheque is returned then the returned suspense account will contain the value of the returned cheque.

Figure 29 – Cheque Collection Suspense Account

CQ.PARAMETER and ACCOUNT.PARAMETER Either the CQ.PARAMETER or ACCOUNT.PARAMETER record determines whether or not the deposited cheque collection functionality should be invoked. If the CQ.PARAMETER or ACCOUNT.PARAMETER record has the CHQ.DEP.TXN, DEF.COLL.SUSP, CHQ.COLL.TXN, CHQ.RTN.TXN and the DEF.RTN.SUSP fields entered then the deposited cheque collection functionality is invoked. The system decides what processing to invoke by locating the transaction code in the transaction code fields (CHQ.DEP.TXN, CHQ.COLL.TXN and CHQ.RTN.TXN) on these records. If the TRANSACTION code is found the system then assigns a CATEGORY code to the transaction. The category code can come from three places; the BC.SORT.CODE record for the bank sort code used in the transaction, from the CQ.PARAMETER or ACCOUNT.PARAMETER record (transaction codes can have associated category codes).

Figure 30 – Linking transaction codes with suspense categories

Bank Sort code Bank sort code records can be created with CATEGORY codes. The category codes are only used for suspense deposited cheque collection transactions if the ACCOUNT.PARAMETER record is set. If the ACCOUNT.PARAMETER record has been set, and a bank sort code is used by the transaction, the system will firstly check the sort code record for a category code to suspend the funds. If there is no CATEGORY code the ACCOUNT.PARAMETER record.

it

will

use

the CATEGORY code

from

Having the CATEGORY codes on the BC.SORT.CODE records allows the funds to be posted to individual suspense accounts for each bank.

Figure 31 – Individual suspense accounts for a sort code

FT LOCAL CLEARING and FT BC PARAMETER The FT.BC.PARAMETER and the FT.LOCAL.CLEARING files go hand in hand. If you need to create or modify the FT.BC.PARAMETER record then the FT.LOCAL.CLEARING record should also be checked and/or updated. For further information on the FT.BC.PARAMETER file and the FT.LOCAL.CLEARING file see the Funds Transfer and/or Local Clearing User Guides. Cheque Collection The cheque collection records are created through FUNDS.TRANSFER, DATA.COPTURE and TELLER. The normal processing for these applications occur, however if the transaction code is found on the account parameter record the system will also create a cheque collection record. In Teller the TELLER.TRANSACTION code record contains the TRANSACTION code used in the contract, and in FUNDS.TRANSFER the FT.TXN.TYPE.CONDITION code record contains the transaction code used in the contract.

Figure 32 – Incoming payment by cheque

In the above example the FT.TXN.TYPE.CONDITION record IC has a TRANSACTION code of 221 (Incoming Cheque Payment), therefore a cheque collection record has been created. For every Funds Transfer, Data Capture and Teller transaction created the system searches through the list of TRANSACTION codes on the ACCOUNT.PARAMETER trying to locate the TRANSACTION code of the deal. The field on the ACCOUNT.PARAMETER where the TRANSACTION code is found determines what processing is required for Cheque collection. Normal account processing takes place on the transaction. In the example below you will see that the USD Nostro account has been debited $2500.00, while the internal suspense account has been credited with the $2500.00, the customer

account has not been credited. The internal suspense account has been derived from the BC.SORT.CODE record 100000301123 which has a Collection suspense CATEGORY of 14820.10400.

Figure 33 – Debiting the Nostro

Figure 34 – Crediting suspense

On the credit STMT.ENTRY record the CHQ.COLL.ID the CHEQUE.COLLECTION id – Customer Account number

field

indicates

Figure 35 – FWD.STMT.ENTRY raised by CHEQUE.COLLECTION record

The record is now available for processing through CHEQUE.COLLECTION. The CHEQUE.COLLECTION record shows the cheques status. CHEQUE.COLLECTION records are created with a status of Deposited, this indicates a cheque has been entered into T24 and is waiting to be processed. Cheques can be processed individually in CHEQUE.COLLECTION or in batches through the CHEQUE.BATCH application (see Cheque Batch section). A Cheque can be Clearing, Cleared or Returned. The cheque collection CHQ.STATUS field indicates what status the cheque is at. Cheques are usually sent for Clearing, and can come back either returned or cleared. The CHEQUE.COLLECTION record then has the CHQ.STATUS field changed to the appropriate status.

The CHEQUE.COLLECTION record CHQ.STATUS to the required status.

is

processed

through

changing

the

There are 4 different statuses:    

DEPOSITED – When the cheque is initially deposited CLEARING – This status indicates that the cheque has now been batched in the CHEQUE.BATCH application CLEARED – This status indicates that the funds on the cheque have been collected RETURNED – This status indicates that the funds on the cheque could not be cleared and the cheque was returned

Figure 36 – Cleared Cheque – CHQ.STATUS – DEPOSITED

Figure 37 – CHQ.STATUS changed to CLEARED

The cheque collection record with a CHQ.STATUS of cleared will create the following accounting entries. The accounting entries will credit the customer account and debit the internal suspense account completing the transaction. Note that no accounting entries are generated when the cheque status changes from deposited to clearing.

Figure 38 – Debiting suspense

Figure 39 – Crediting customer

Cheques can be returned by the other bank and this result’s in the funds being transferred from the internal cheque collection suspense account to the returned cheque collection suspense account. The returned suspense account can be derived from the either the BC.SORT.CODE file, the CQ.PARAMETER or the ACCOUNT.PARAMETER file.

Figure 40 – Returned cheque

Along with the normal accounting entries for the FUNDS.TRANSFER there is the debiting of the cheque collection suspense account and the crediting of the returned cheque collection suspense account.

Figure 41 – Accounting entries for returned cheque

Cheque Batch CHEQUE.BATCH is the application that provides a method of clearing multiple deposited cheques. Cheques can be of varying currencies and denominations with the validation ensuring the entered total of each currency matches the calculated total for the batch. The cheques are then returned by the external banks and are either cleared or returned. The entire batch can be updated, or individual items can be updated. CHEQUE.COLLECTION records can only be added to the CHEQUE.BATCH record if they have a status of Deposited, which will be changed to Clearing, as they are entered into the CHEQUE.BATCH record. The CHEQUE.COLLECTION record can be added in either by entering the CHEQUE.COLLECTION id’s individually into the CHEQUE.BATCH record or they can be entered in a group by selecting a group from an ENQUIRY and then dropping the group into the CHQ.COLL.ID field. The later method of populating the CHEQUE.BATCH record automatically opens a new multi-value for each item in the group. This can be done using the standard Windows selection methods. Hold down the CTRL key, highlight the selected items with the mouse pointer, drag the selection to the CHQ.COLL.ID field then drop the selection into the field.

Figure 42 – Creating a CHEQUE.BATCH

The five items from the enquiry that are highlighted are dragged to the CHQ.COLL.ID field, which expands. The cheque batch record will look as below:

Figure 43 – Populated CHEQUE.BATCH

The CHEQUE.BATCH application will update the status of all the CHEQUE.COLLECTION records on the batch automatically. The record will stay with a status of clearing until a cheque or all the cheques have been either cleared or returned.

Figure 44 – Cheque in clearing

If a CHEQUE.COLLECTION record is part of a CHEQUE.BATCH, the status of the record can only be updated through the CHEQUE.BATCH application. In CHEQUE.BATCH it is possible to update the status of individual CHEQUE.COLLECTION records or to update the whole batch by changing the OVERALL.STATUS field to the desired status. Changing the overall status field will update every CHEQUE.COLLECTION record that currently has a status of clearing with the status entered in the OVERALL.STATUS field. In the below example the cheque for USD 2000.00 is returned, the individual status of the CHEQUE.COLLECTION record has been updated leaving the status of all other CHEQUE.COLLECTION records unchanged. The returned cheque funds will be posted to the return Cheque Suspense account.

Figure 45 – Returned cheque in CHEQUE.BATCH

If the remaining cheques come back cleared then the OVERALL.STATUS can be updated to cleared, this will populate all remaining status fields that have a status of clearing to Cleared.

Figure 46 – Mixed status cheques in a batch

All CHEQUE.COLLECTION records on this CHEQUE.BATCH record that have a status of clearing have been set to ‘cleared’. Below is the CHEQUE.COLLECTION record that has been returned noting that this record has not been updated since the status had been set to ‘returned’.

Figure 47 – Cleared cheque from batch

Figure 48 – Cheque in clearing from the batch

Figure 49 – Returned cheque from batch

CHEQUE.CHANGE In Outward clearing process, whenever clearing entries created through front ends like Teller, FT, DC etc, the system generates CHEQUE.COLLECTION records for each entry with details of the outward clearing. These CHEQUE.COLLECTION records can be grouped into a single batch according to requirements. By using the supported: 







application CHEQUE.CHANGE,

the

following

processes

are

All or selected Cheque Batches can be combined into a single batch. The ID of the new batch created will be displayed by the system. All the cheque collection records of the new batch will bear the new batch ID for future reference. Cheque collection records or batches meeting a certain selection criteria, can be processed further; for RE-BATCH, or changing status to CLEARED/ RETURNED Through the operation DATE.CHANGE it is possible to change the value/exposure dates of cheques. i.e. change the entire CHEQUE.COLLECTION record to either a fixed absolute date or increment the respective dates by one more day or more using REAL dates (+01C or +01W). An existing enquiry based on Cheque Collection or Cheque Batch also can be used for selection and further processing.

CHEQUES RE-BATCH CHEQUE.CHANGE is used to select CHEQUE.COLLECTION records or CHEQUE.BATCH’S and groups them for further processing. If CHEQUE.BATCH is selected as APP.ID and no further selections are made, all the open cheque batches will be grouped together. This will be useful at a Service Branch of the bank to combine the batches received from various branches and present them to Clearing House. The regrouped new batch ID will be displayed as a no input field in BATCH.ID. Grouping of CHEQUE.BATCH’S can be done using the fields, SELECTION.FIELD, OPERAND and DATA. On Verify mode, the process like RE.BATCH will be done. Changing the status of Cheque’s in CHEQUE.BATCH If the status of the individual cheques in CHEQUE.BATCH is required to be changed online and the accounting entries are to be processed this can be done through CHEQUE.CHANGE by inputting BATCH in OPERATION. The TSA.SERVICE record BNK/CHEQUE.PROCESS is then set to START and the service is run. This will update the status of the cheques in CHEQUE.BATCH and will process the entries online. If any records in CHEQUE.BATCH are left in INAU and the service is run the cheques will be returned to their previous status. The record in CHEQUE.BATCH will be purged and moved to history after all of the cheques included in the CHEQUE.BATCH record have been actioned based on the number of days in CB.POST.HIST setup in CQ.PARAMETER. CHEQUE.COLLECTION ACCOUNTING If the credit side transaction code of the TELLER.TRANSACTION relating to Clearing is defined in the CQ.PARAMETER, and the DEF.COLL.SUSP field is left blank, then the credit of CHEQUE.COLLECTION record will go directly to the customer account. Otherwise it will follow the usual path defined in either the CQ.PARAMETER or ACCOUNT.PARAMETER. The CHQ.DEP.TXN field in the CQ.PARMETER will not allow a value that has already been entered in the same field in the ACCOUNT.PARAMETER.

CHEQUE.COLLECTION records are created by the system for the full amount, without deducting charges. If the credit side transaction code matches the transaction code defined in ACCOUNT.PARAMETER or CQ.PARMETER under CHQ.DEP.TXN, and if YES is defined in the field DEFER.CHARGES in TELLER.TRANSACTION, then the charges defined at Teller level will be carried over to CHEQUE.COLLECTION record and will be processed at the time of regularising the credit as CLEARED or RETURNED. Otherwise the charges will be collected at the Teller entry level itself.

Stock Management STOCK.PARAMETER The STOCK.PARAMETER table holds information relating to ID component of STOCK.REGISTER, and the masking pattern of stock number. The STOCK.PARAMETER application will only allow the set-up of the following records;     

CHQ BCHQ DRAFT FDR CARD

It is possible to define the ID of the STOCK.REGISTER in a flexible way by specifying a value in the field STOCK.REG.ID. Once a value is defined here, it will be validated with the ID of the Stock Register. For example, if COMPANY.CODE is specified in this field, then the system will validate for the presence of Company Code in Stock Register

Figure 50 – STOCK.ENTRY record Input screen

Figure 51 – Example STOCK.PARAMETER record CHQ

STOCK.ENTRY The STOCK.ENTRY is used to record inward/outward Printed stock of stationeries like Cheque’s, FDR’s for both numbered and blank stokes. Through this application stock details like cheque type, series, start no, quantity and account no can be captured. Movement from one stock register to another can also be entered.

On input in the STOCK.ENTRY, system adds a record in a live file STOCK.REGISTER if the stock register id is valid as per STOCK.PARAMETER. It also forms the STOCK.SERIES based on STOCK.SERIES*STOCK.ACCT.NO*CHEQUE.TYPE. In STOCK.ENTRY; stock register id, stock series id, start no and quantity of stock are captured. Any movement from / to the stock register which has been input through STOCK.ENTRY, will update the STOCK.REGISTER. STOCK.REGISTER A live file is updated with total stock available for an “ID”. based on the STOCK.PARAMETER.ID *STOCK REG.ID. Below is an example STOCK.ENTRY record, the STOCK.PARMATER record CHQ in the above example

The stocks are listed

which

is

using

Figure 52 – Example STOCK.ENTRY RECORD

Below is the system generated STOCK.REGESTER record created by the above STOCK.ENTRY record SE035700003.

Figure 53 – STOCK.REGISTER record created by previous STOCK.ENTRY

When cheques are issued against an account, if the fields STOCK.REG and SERIES.ID are entered the field CHQ.NO.START is defaulted. The STOCK.REGISTER is also updated. In order for this to happen the field AUTO.REORDER.TYPE must be CHEQUE.NUMBER in the application CHEQUE.TYPE.

Figure 54 – Example CHEQUE.ISSUE with STOCK.REG

Below the STOCK.REGISTER record has been updated

Figure 55 – Example updated STOCK.REGISTER record

Copyright © TEMENOS

Related Documents

Cheque Issue Management
January 2021 1
Cheque Issue & Mgmt
January 2021 1
El Cheque
March 2021 0
Carta-pago Por Cheque
January 2021 1
Monografia El Cheque
March 2021 0
El Cheque Monografia
March 2021 0

More Documents from "MayerlisCinthiaLandeoAguirre"