You are on page 1of 31

Question From which applications can account balance figures like Monthly account balances, daily account balances

be fetched? Answer I. You can get this information from ACCT.ACTIVITY file which is a live file. It updates online, shows the day wise daily credit and debit and closing balance. II. You can use Enquiry STMT.ENT.BOOK or VAL.STMT.ENT.BOOK based on your system. If it is a value-dated system then use VAL.STMT.ENT.BOOK, and if Trade dated then you can use STMT.ENT.BOOK enquiry. These enquiries will give you balance of accounts for different date criteria. Question Is there any parameter which can restrict the account to go into debit balance? Answer No, there is no parameter to restrict the account getting into debit balance, however if any transaction tries to make balances of account to debit then an override Unauthorised overdraft will be generated by the system. If you wish to stop such kind of transaction you can make use of Dispo officer setup / Overrides to restrict users to authorise transactions with such override. Please refer to the How to link for the setup. Question GENERAL.CHARGE based on account balance Answer Query: Levy a flat amount month end charge(GENERAL CHARGE) on all active accounts based on account balance. Answer: Kindly be note that according to T24 functionality it is not possible to levy general charges for the active accounts only, leaving the dormant/inactive accounts. Any type of general charges will also affect the dormant/inactive accounts. Also if charges are setup for an account in the GENERAL.CHARGE record then system will collect full charge amount from the account irrespective of whether the account has the available balance or not. Hence it is not possible to debit charges based on account balance. Question What is the difference among OPEN.ACTUAL.BAL, OPEN.CLEARED.BAL, ONLINE.ACTUAL.BAL, ONLINE.CLEARED.BAL and WORKING.BALANCE in account application?

Answer ONLINE.ACTUAL.BAL: This field contains the current Actual Balance of the Account. This is exactly the same as the actual balance at the start of day (Open Actual Balance) plus the value of all the fully authorised entries since the start of day. In a value dated accounting system, this balance is updated by future value dated entries only during start of day processing of the value date, unlike the trade dated systems where this field would be updated immediately on generation of the entry. In both systems, forward entries or F entries would update this balance only during batch processing of the respective value dates. ONLINE.CLEARED.BAL: This field contains the current Cleared Balance of the Account. This is the same as the cleared balance at the start of day (Open Cleared Balance) plus the Value of all fully authorised entries since the start of day, except any credit or reversal debit entries with future Exposure Dates. Of all the future dated entries in a trade dated system, only debit entries update this balance on the BOOKING.DATE itself. The future dated credit entries hit this balance only during start of day processing on the EXPOSURE.DATE. In a value dated accounting system, both debit and credit future value dated entries update this balance during start of day processing on the EXPOSURE.DATE. For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day on the appropriate date (EXPOSURE.DATE) by the program AC.FWD.EXPOSURE.

WORKING.BALANCE: This field contains the present balance of the Account which is used for checking by the Limit System etc. At the start of day this is the same as the cleared balance (Online Cleared Balance). For Nostro and Internal Accounts, it is updated by all entries when they have been fully authorised. For Customer Accounts are updated by debit entries when they are validated, and by credit entries when they have been fully authorised, except for any credit or reversal debit entries with Exposure Dates in the future. For credit and reversal debit entries with future Exposure Dates, this field is updated at start of day on the appropriate date by the program FWD.EXPOSURE.

OPEN.ACTUAL.BAL: This field contains the Actual (unclear) Balance or Ledger Balance of the Account as on start of day. In a trade dated accounting system, the future dated entries will update this balance during batch processing on the booking date of the entries. In a value dated accounting system, future dated entries will update this balance during batch processing on the value date. OPEN.CLEARED.BAL: This field contains the Cleared Balance of the Account as on start of day. This includes the value of all entries over the Account except any credit entries or reversal debit with Exposure Dates in the future. In a trade dated system, future dated debit entries will update this balance during COB processing on the BOOKING.DATE. Future dated credit entries hit this balance only during start of day processing of the EXPOSURE.DATE. In a value dated accounting system, both debit and credit future dated entries update this balance during start of day processing of the EXPOSURE.DATE. For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day on the appropriate date by the program FWD.EXPOSURE.

Question ACCOUNT.STATEMENT enquiry showing wrong balance while viewing for specific ACCOUNT. Answer For getting the ACCOUNT balances for any specific period kindly use the enquiry STMT.ENT.BOOK and where as ACCOUNT.STATEMENT enquiry is designed to use HANDOFF id as selection to view the STATEMENT for the HANDOFF generated in AC.STMT.HANDOFF. Question How to rebuild Available balance ladder in the Account record Answer Available balance ladder can be rebuilt using the application AF.REBUILD.REQUEST and the job REBUILD.AVAIL.FUNDS. We can rebuild ladder just for one account, or a group of accounts or for all accounts based on the setup done in AF.REBUILD.REQUEST template. We need to create a record in AF.REBUILD.REQUEST application with ID as NEXT.WORKING.DATE (T24 date), and during the SOD stage of the subsequent COB, REBUILD.AVAIL.FUNDS job Question What is the difference between the RE.ACCT.OPEN.BAL, OPEN.ACTUAL.BALANCE and the OPEN.CLEARED.BALANCE fields in the account table? Answer The RE.ACCT.OPEN.BAL is an application, used to maintain the Opening Balance of the customer and internal accounts. The OPEN.ACTUAL.BALANCE and the OPEN.CLEARED.BALANCE are the fields in the account table. The OPEN.ACTUAL.BALANCE contains the Actual (unclear) Balance or 'Ledger Balance' of the Account as at the start of the day and the field OPEN.CLEARED.BALANCE contains the Cleared Balance of the account as at the start of the day. This includes the value of all entries over theccount except any credit entries or reversal debit with Exposure Dates in the future. Question Is it possible in R7 that the balance of account xxxxx differs from the account OPEN.ACTUAL.BAL? Answer From R7, contract balances for report will be arrived from EB.CONTRACT.BALANCES file. Check this file for the particular account Question

Can a T24 system have different dates as TODAY in DATES record, across the Lead Companies and run COB using TSA.SERVICE record COB? Answer The answer is NO.As per the standard functionality of T24, only with GP (Global Processing) product installed, the T24 system can have different dates in the DATES records across companies. This will enable to group companies of same region together and run COB separately for them. During COB, the job EB.CYCLE.DATES will create a record named COB in the F.LOCKING record. It will update the TODAY date based on the company for which it is run. When the job EB.CYCLE.DATES runs for other companies after when it runs for the company BNK, it will update the F.LOCKING record COB with the date of the other company. The date in this record is used to populate the common variable C$BATCH.START.DATE, which is used across several jobs of the COB like IC.COB, etc. Since there will be a mismatch between the date assigned to C$BATCH.START.DATE and the date available in the DATES record for that company, there are chances that the COB jobs fail to process any records. Any of these procedures should be followed to solve the above scenario, 1) Synchronise the DATES for all companies and run COB. Or 2) If GP product installed, group companies together and create a separate TSA.SERVICE record for each and every group or company and run COB separately for them. Question Opening balance on Enquiry ACCT.ENTRY.STMT always displays value 0, even though there is balance on the account on a specific date. Answer The enquiry ACCT.ENTRY.STMT is actually designed to be executed only upon verifying the ACCT.ENTRY.STMT template. The selection criteria like START.DATE and END.DATE, which is mandatory to produce an ACCOUNT.STATEMENT for a particular period and to determine its Opening balance are present in ACCT.ENTRY.STMT template and not in the enquiry. Hence when we verify ACCT.ENTRY.STMT, the routine ACCT.ENTRY.STMT.RUN will get triggered, which in turn executes the enquiry ACCT.ENTRY.STMT and displays the relevant output. Since, you have not verified this enquiry, the opening balance is displayed as 0 Question Incorrect opening balance and entries in un-sorter order when enquiring for master account. Answer Kindly use the field SORT.REQ to YES in the enquiry STMT.ENT.BOOK or as an alternate option to BOOKING.DATE, use the criteria PROCESSING.DATE

Question How does the Account balance get updated when NS is installed and FT is input during COB? Answer Non Stop Processing(NS) and Close Of Business(COB) complement each other.

Close Of Business disallows input and processing of records in all applications other than the one supported by Non-Stop service. The applications that are available in NS service will be available without any restrictions and will be using the next working date for processing. This ensures concurrent transactions are not picked up for processing by COB that is running parallell. Case 1: Working balance of Account with reference 123456 is 500 Euro before the COB. We start the COB. During the COB a User is inputting an FT transaction debiting the account with reference 123456 with 300 Euro. How the system will be checking the balance at that stage (assuming that at that moment no txns have come from the COB for that account its at the early stages)?

The system will consider the next working date for processing the FT transaction inputted during COB to debit the account with reference 123456 with 300 Euro. For the current date the system will process the account with reference 123456 with 500 Euro. i.e., the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL fields are updated with 500 Euro and the WORKING.BALANCE fields with (500-300) = 200 Euro

Case 2: What will happen if after the FT transaction is authorized and during the later stages of the COB a charge will be posted on the account (with amount Euro 400). What will happen to the balances in this case?

The posted charge on account with amount 400 Euro will be processed with the next working date. At this stage, after the authorization of FT the fields ONLINE.ACTUAL.BAL, ONLINE.CLEARED.BAL and WORKING.BALANCE are updated with (500-300-400) = -200 Euro and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL fields with 500 Euro. Question We have WORKING.BALANCE problem for a particular account whose INAU transaction has been deleted from backend Answer

As per the standard T24 Design, deletion of a transaction in INAU status, from backend, is not recommended. Doing so will result in Account balance problem leaving the problematic ENTRY.HOLD intact. The normal procedure is to delete the INAU transaction from Globus prompt, even if the number of such transactions is large. Question How the Account balance would be updated when NS is installed and FT is input during COB? Answer Non Stop Processing and Close Of Business complement each other. Close Of Business not allow input and processing of records in all applications other than one supported by Non-Stop service. The applications that are available in NS service will be available without any restrictions and will be using the next working date for processing, thus ensuring the concurrent transactions are not picked up for processing by the Close Of Business which is running in parallel. Question How can I set up a flat monthly account maintenance charge in T24 (the charge is a flat amount charged independently of the balance of the account)? Answer Calculation of flat charges for an account independent of account balance can be achieved through IC.CHARGE application setup. Question In some cases account balances fields are displayed in Account application. In the same time according to R12 User Guides we find this type of information in EB.CONTRACT.BALANCE. Answer As per the T24 functionality in R12, the balance fields in the account are removed and they will be updated in the EB.CONTRACT.BALANCES record. There is a field BALANCE.MOVED in the EB.CONTRACT.BALANCES application, which will be set to 'YES' if the balances are moved from Account to EB.CONTRACT.BALANCES record during upgrade. In case the balance in the account record is not moved, then the balance will be moved only once it has movement/transactions. Question Suppress -Available Balance Override ? Answer

The overdraft on available balance will be triggered if you have the AVAILABLE BALANCE ladder for the account ,So to supress the override we should set the CASH FLOW DAYS to NULL and CREDIT.CHECK to WORKING in the ACCOUNT.PARAMETER file. Due to this setting the AVAILABLE BALANCE ladder wont be built for the accounts so there wont be any AVAILABLE BALANCE override and only unauthorized overdraft based on working balance will be raised. Question When OPEN.ACTUAL.BAL of an account is updated? Answer Open actual balance Contains the Actual (uncleared) Balance or 'Ledger Balance' of the Account as at the start of the day. This balance is equal to the BK.BALANCE FOR PREVIOUS DAY IN ACCT.ACTIVITY (INCLUDE FUTURE DATED CREDIT) = ECB.OPEN.BALANCE( EB.CONTRACT.BALANCES file ) . and this balance will be updated by the JOB EOD.ACCT.ACTIVITY in the BATCH AC.SYS.END.OF.DAY in the stage S010 based on the file ACCT.ENT.TODAY. Hope this clarifies you better Question Credit interest as not calculated for minimum balance type setup. Answer As per the query, interest was not calculated when the GCI is defined with MINIMUM balance. Kindly consider the below sample example with the explanation. For the problematic account "0000000438332" group level interest has been defined in the GROUP.CREDIT.INT record "20 MWK 18 SEP 2010". CAPITAL CITY GROUP.CREDIT.INT SEE

GROUP.CY.DATE..... 20 MWK 18 SEP 2010 Special Saver Accts Malawi Kwacha -----------------------------------------------------------------------------1 INTEREST.DAY.BASIS E 366/365 2 TAX.KEY........... *WHT 3 CR.BALANCE.TYPE... MINIMUM 4 CR.CALCUL.TYPE.... LEVEL 5 CR.MINIMUM.BAL.... 1,000.00 7. 1 CR.BASIC.RATE.. 41 Base Rate 1% 0.5% 25 INTEREST.TAX.MIN..10,000.00 -----------------------------------------------------------------------------In the above record we could see the CR.BALANCE.TYPE is set as "MINIMUM" and "CR.MINIMUM.BAL" is set as "1,000.00". As per the above interest setup system will calculate interest for the minimum amount that is maintained in the whole interest period and the minimum amount should be greater

than 1000 for the whole interest period as well. In our case the interest period for the year 2011 is from 01-Jan-2011 to 31-Dec-2011. Since the balance was less than 1000 for the days from 01-Apr-2011(from 1st Apr to 3rd Apr "-34,877.27") to 04-Apr2011(-54,877.27) system has not calculated the interest and this is the standard T24 functionality for minimum balance type interest calculation. NBM HO Account Activity SEE MWK Spl Saver ACCT.NO.YEAR.MONTH 438332 - 2011-04 SHABA MANNIX W N -----------------------------------------------------------------------------1. 1 DAY.NO......... 01 3. 1 TURNOVER.DEBIT. -45,000.00 4.1 BALANCE........ -34,877.27 1. 2 DAY.NO......... 04 3. 2 TURNOVER.DEBIT. -20,000.00 4. 2 BALANCE........ -54,877.27 ------------------------------Question ACCOUNT.CLOSURE AND LIQUDATION ACCOUNT Answer Upon Account Closure online, the interest amount is capitalised to the Liquidation Account. As it is an Account Closure event, The FT generated should contain the outstanding balance, Interest and Fees to be settled. pacs reference :PACS00094603 Explanation : We would like to explain the functionality , When an account with liquidation account set is closed online with closure charges, charges would be booked to the main account. Only interest and other charges(general) will be booked to the liquidation account. This applies for normal closure as well. Question Why is the core enquiry MB.RG.BALANCE.LIST not generating any output in our system? Answer The enquiry MB.RG.BALANCE.LIST gets the data form the record RG.BALANCE.LIST present in HOLD. The value BALANCE.LIST from the field DATA under the job PRINT.ACCOUNT.REPORTS was removed from

higher releases. If we need to update BALANCE.LIST then adding the value in the field DATA will solve the problem. Question Account SWEEPING Answer Maintenance Sweep Sweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is less than the amount defined in MIN.AMT of AC.ACCOUNT.LINK Surplus Sweep Sweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is greater than the amount defined in MAX.AMT of AC.ACCOUNT.LINK Two-Way Sweep There are two cases, Case 1 - If RETURN.AT.SOD is Yes Sweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is either greater than MAX.AMT or less than MIN.AMT defined in AC.ACCOUNT.LINK at End Of Day. Sweep of balances back from FROM.ACCOUNT to TO.ACCOUNT at Start Of Day Case 2 - If RETURN.AT.SOD is No Sweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the amount is either greater than MAX.AMT or less than MIN.AMT defined in AC.ACCOUNT.LINK at End Of Day alone. If you need to move only debit balances from ACCOUNT1 to ACCOUNT2, you can make use of Maintenance Sweep If you need to move balances from ACCOUNT1 to ACCOUNT2 irrespective of debit or credit, you can make use of Two-Way Sweep with AC.SWEEP.TYPE>RETURN.AT.SOD as No. Question How to make the system consider only the WORKING.BALANCE for CREDIT CHECK? Answer To make the system consider only the WORKING.BALANCE for CREDIT.CHECK do the following settings CREDIT.CHECK to '', AVAIL.BAL.UPD to none and VDATE.BAL.CHK to '' Question Some amounts in T24 balance is different from the amounts calculated with STMT.ENTRY and CATEG.ENTRY Answer

The T24 account balance will be the sum of STMT.ENTRY alone for a particular account. Hence, we are not supposed to sum the CATEG.ENTRY. Also for the Accrual categories (51007, 52210, 54401, 61090, 63205), CATEG.ENTRY should alone be checked and compared with balance shown in CATEG.ENT.BOOK Question Question on overdraft override for the Nostro account Answer The system will raise the override message "yyyymmdd customer account OVERDRAFT ON AVAILABLE BALANCE currency xxxxxxxx.xx" only for the customer accounts. The processing of override is skipped if it is Internal or Nostro account irrespective of the Account/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER setup. Question Why does enquiry output show different amount in the LIAB enquiry compared to the sum of balance in the accounts for customers? Answer Generally, the LIAB enquiry adds the balance of the accounts which have credit balance in it for a customer and displays it in the ENQ LIAB output. When the credit balance is displayed in the ENQUIRY LIAB, the corresponding drilldowns will display different amount as summation of balance will consider both credit and debit balances. If the ENQ LIAB output needs to display the sum of account balance irrespective of credit or debit. The ALLOW.NETTING field should be set to Y in LIMIT record and ACCOUNT records respectively. Question Few fields & and its purpose in ACCOUNT.PARAMETER Answer LOCKED.WITH.LIMIT: ================= A New field LOCKED.WITH.LIMIT introduced in ACCOUNT.PARAMETER,ACCT.GROUP.CONDITION and ACCOUNT to check Limit on an account in the Locked amount checking New functionality in the system will also allow the option to include the Limit in the Locked amount checking. The locked amount check is done on the current balance and then on the future cashflows if there are any. If Locked amount checking with Limit is allowed, then the Limit or Balance available refers to Working.Balance or T24 Available Balance after taking the locked amount and Limit into consideration. This functionality may be set at ACCOUNT.PARAMETER, ACCT,GROUP.CONDITION or on an individual

ACCOUNT record using the field LOCKED.WITH.LIMIT. The default setup is to ignore limit for locked amount processing. Priority is given to the set up at the lowest level. If this setting is set as YES, Limit will be included for Locked amount checking. If a transaction is put through in Locked account, the system will arrive at working balance by substracting locked amount from available limit. Default setting is NO where Limit is not included for checking USE.SESSION.NO ============== This field is used to include session number in the ID for the CONSOL.UPDATE.WORK file , this file is the base file to update the CAL , By updating session number we can avoid the problem of partial updation and locking problem. BYPASS.TXN.JOURNAL ================= For a Heavy volume client and if the TJ report is not used , By switch off this field will not update the TXN.JOURNAL work file , this is the base file to generate the TRANS.JOURNAL report.This is to avoid the hit in reporting job performance. BYPASS.JOURNAL.SUM For a heavy volume client and if the EB.JOURNAL.SUMMARY is not used by the client, By switch off will not update the file EB.JOURNAL.SUMMARY.WORK. This is to avoid the hit in reporting job performance. Question Does it exist any parameter in order to control on how many days in advance is computed the available balance for the above override message (for example can we shorten this period to 1 day in advance) ? Answer Issue desc: On 17 aug 2011 we tried to debit one customer account with FT, we obtained the following override message : 22/08/11 47527 OVERDRAFT ON AVAILABLE BALANCE RON -86996279.32" Explanation provided: The number of days for which the available ladder should be built can be set in CASH.FLOW.DAYS field of ACCOUNT.PARAMETER. If you want the system to check only one day forward then you can set CASH.FLOW.DAYS to 1. The override OVERDRAFT ON AVAILABLE BALANCE, will be based on the available balance ladder of the account, the updates to available balance ladder can be controled using the fields CREDIT.CHECK and AVAIABLE.BAL.UPD in ACCOUNT/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER. When CREDIT.CHECK is set to "AVAILWORK" in ACCOUNT/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER, system will check working balance of the accounts for any transaction posted to the account. When CREDIT.CHECK is set to "AVAILABLE", then UNAUTH debit movements will be updated in available balance ladder.

By default system will update unauth debit movements to available balance ladder. AVAILABLE.BAL.UPD field allows the values BOTH, NONE, CREDITS or DEBITS, this specifies which type of movement should be udpated to avaialble balance ladder, whether credit movement or debit movement or both credit or debit or no update. Also we would like to let you know that when you change the no of days in CASH.FLOW.DAYS, say from 10 to 1, then the available balance ladder of the accounts should be rebuilt based on the new value. To do this kindly set the job REBUILD.AVAIL.FUNDS to 'D' daily an Question PREV.OPEN.BAL in the R07 release is not matching with the EB.GET.ACCT.BALANCE output in the upgraded R10 environment. Answer In R7 release for back dated transaction, BK.BALANCE ladder will get updated only from the booking date (today's date). But in higher release (from R10 onwards), this design has been modified. Even the BK.BALANCE ladder will get update from the back value date itself. Hence routine EB.GET.ACCT.BALANCE is returning the amount, including the total of all entries posted today with VALUE.DATE back dated beyond PREV.DATE. From R10 release onwards, to get the correct booking(trade) balance we have introduced new ladder in ACCT.ACTIVITY record - BOOKING.DAY ladder. (Fields BOOKING.DAY, BK.TRADE.DATE, BK.TRADE.TOVR.CR and BK.TRADE.TOVR.DB are part of this ladder). But this ladder will get updated only if we set the field ADJ.TRADE.DATE.BAL in the ACCOUNT.PARAMETER record to 'Y'. So to solve this problem, while you upgrade, kindly set the field ADJ.TRADE.DATE.BAL to 'Y' in the ACCOUNT.PARAMETER record. This will update the new ladder in the ACCT.ACTIVITY and Question Can STMT.ENT.BOOK enquiry be used to check account balances? Answer No, if you are in a value dated system, you should not use STMT.ENT.BOOK enquiry to check account balances, this is only for trade dated system. Use VAL.STMT.ENT.BOOK enquiry instead. Question ACCOUNT.PARAMETER AND CREDIT.CHECK :WORKING Answer

Available balance override will be thrown based on the available balances in the ACCOUNT. If the CREDIT.CHECK is working and then the CASH FLOW DAYS is null , System will not update the ladder balances and it will not throw the override Question Purpose of CASH.FLOW.DAYS in ACCOUNT.PARAMETER Answer ACCOUNT>AVAILABLE LADDER will be updated based on the setting in ACCOUNT.PARAMETER>CASH.FLOW.DAYS. Setting ACCOUNT.PARAMETER>CASH.FLOW.DAYS to (null) will not update available ladder of the customer accounts (for NOSTRO accounts, CASH.FLOW.DAYS will be considered as 10 days even if the field is blank) and hence the override OVERDRAFT ON AVAILABLE BALANCE override will not be raised. Question Account opening and closing by month required, we need to know is there any existing report. Answer In order to achieve the requirement, kindly change the frequency of the Account to M01 (Monthly once) in the ACCOUNT.STATEMENT record, so that the AC.STMT.HANDOFF record will be generated with FROM.DATE and TO.DATE once in a month based on the frequency set. During that frequency end date's COB, system will generate Account statement report with Opening balance and Closing balance by month. Question Allow netting not working when limit record attached to the account has zero as overdraft limit Answer As per the functionality, Limit record should have limit amount. If limit record does not contain any balance then its not considered as valid limit record. Since overdraft limit amount is "0", system not netting the account balances belongs to the customer.System throws the override message even though customer has funds in other accounts. In order to net the account balances limit record shoul Question Will there be any impact when changing the category of an account from normal savings to staff savings? Answer

The result of changing the category will be a change in account group (consol key). But this change will not happen online and will happen only during COB. There will be no impact because the account will be removed from the old link file and added to the new consol key and the CAL balance changes accordingly. Question Account not overdrawn as seen in STMT.ENT.BOOK but interest debited for the customer Answer In order to get the balance and entry listing with reference to interest calculation, we request you to use the field PROCESSING.DATE instead of BOOKING.DATE in the enquiry STMT.ENT.BOOK. This will list entries as per the processing date/value date since the interest calculated based on value date. Question In an account closure, the system reports override: CALCULATED INTEREST MAY BE INACCURATEENTRIES POSTED TODAY. If we accept it, how do we know the interest is correct? Answer The override "CALCULATED INTEREST MAY BE INACCURATE - ENTRIES POSTED TODAY" is actually for informative purpose only and this won't affect your ACCOUNT closing whatsoever. While committing the ACCOUNT.CLOSURE record, the system will consider balances up to the previous day and post interest accordingly. It will also check if there are any entries for this account in the ACCT.ENT.TODAY file. If so, then the override 'CALCULATED INTEREST MAY BE INACCURATE - ENTRIES POSTED TODAY' will appear for your information. Its because, the account balance will be updated during EOD and based on the ONLINE.ACTUAL.BAL interest amount is calculated and updated in the field TOTAL.CR.INTEREST/DEBIT in the ACCOUNT.CLOSURE record. But anyway the entries for the account in the ACCT.ENT.TODAY file will get processed during today's EOD, hence the amount for these entries will reflect the account balances only during EOD. Capitalization of the interest for this closing account will happen during EOD based on the calculated account balances. Question We would like to know the format of internal account ids in multi-company and multi-book environment Answer Multi-Company internal accounts ================================ Format is CCY-CATEG-NNNN CCY - is the currency code CATEG - is the 5 digit category code NNNN - is 4 digit sequence number between 0001 to 9999 Here the sequence number part can be any number between 0001 to 9999 and it

is not dependent to the Company sub-division code. Consider an account USD100010001, this account can be created in BNK and in FCB but both are different accounts and will be located physically under different files FXXX.ACCOUNT Interco accounts - For the case of balance inter-company internal accounts, the sequence number (NNNN) identifies the other company involved in the transaction. Eg, USD128002000 in BNK refer to the Interco account residing in BNK and that will be used if transactions happen between BNK and 2000 (FCB) Multi-Book internal accounts ============================= Format is CCY-CATEG-NNNN-xxxx CCY - is the currency code CATEG - is the 5 digit category code NNNN is 4 digit sequence number between 0001 to 9999 xxxx - is the branch sub-division code Here xxxx is the branch sub-division code and this will be unique for each branch. Consider an account USD1000100011005, this account belongs to the branch 1005 (RAJ) and the same account cannot be used in any other branch. Interco accounts - In a multi-book system, for Interco accounts, the NNNN and xxxx part are under to identify the branches involved in the transaction. Consider the account, USD12800-1005-0001, here NNNN = 1005 is the other branch code (RAJ) involved in the transaction and xxxx = 0001 identifies the branch to which this account belongs. Question When i try to reverse the ACCOUNT.CREDIT.INT/ADI/GCI/GDI the system throws the error "REVERSAL NOT ALLOWED FOR THIS RECORD ID". Answer Kindly note that according to the T24 functionality the system will not allow the reversal of the last ACCOUNT.DEBIT.INT record. For example , if there are four ACCOUNT.DEBIT.INT records as follows, 10693-20090302 10693-20090402 10693-20090502 10693-20090602 Then the system will allow the reversal of the records 10693-20090602, 10693-20090502, 1069320090402 but will not allow the reversal of last record 10693-20090302. In case if you like the system not to follow this ACCOUNT.DEBIT.INT (100000017797-20100801) record but to follow the GROUP.DEBIT.INT record then in the field INTEREST.DAY.BASIS of the ACCOUNT.DEBIT.INT specify the value as G (GENERAL). Account Debit Interest SEE ACCOUNT.NO.DATE... 10693 - 03 APR 2009 Michael Dell -----------------------------------------------------------------------------1 CHARGE.KEY........ 33 NO CHARGES 2 INTEREST.DAY.BASIS G GENERAL ===> By setting this value the system will follow the GROUP.DEBIT.INT and not this ACCOUNT.DEBIT.INT 4 DR.BALANCE.TYPE... DAILY

5 DR.CALCUL.TYPE.... LEVEL 7. 1 DR.INT.RATE.... 15.00 22 APR.REQUIRED...... NO 36 CURR.NO........... 1 -----------------------------------Question is it possible to achieving the report with the Lines descriptions and details such as actual account numbers instead of the consol key on the report Answer It is not possible to print the account numbers in the reports instead of consol keys. As per the T24 functionality, the CRF report will displays only the consol keys & it does not shows the Account balance in the CRF report. This is also applicable for PC report. Hence it is not possible to have the account details in CRF report. Also, please be noted that for PC database we can generate only CRF & CRC report. we cannot generate CRB report. Question We want to develop a local enquiry, which will fetch the entries for a particular account and for a particular date. Can we make use any core routines to achieve this functionality? Answer To fetch the statement entries for a particular account for the particular time period, the following core routine EB.ACCT.ENTRY.LIST can be used instead of the routine E.STMT.ENQ.BY.CONCAT. The core routine EB.ACCT.ENTRY.LIST returns the OPENING BALANCE of the account for the given start date and the statement entries for the mentioned period( START.DATE to END.DATE). Question If every transaction on FBNK.STMT.ENTRY should found in STMT.ACCT.CR or STMT.ACCT.DR ? Answer STMT.ACCT.CR/DR , this file holds the details of interest capitalisation details Every transaction STMT.ENTRY will be updated in the STMT.PRINTED file , By selecting this file we can fetch the STMT.ENTRY. In core an routine is used to fetch the entries from STMT.PRINTED SUBROUTINE

EB.ACCT.ENTRY.LIST(ACCOUNT.NUMBER,FROM.DATE,END.DATE,YID.LIST,OPENING.BAL,ER) * * Passed Parameters. * * ACCOUNT.NUMBER :- Account for which balance & entries is to be returned. * FROM.DATE :- Start date for opening balance and entries. * END.DATE :- The last date to be considered. * * Outgoing : * ========== * * YID.LIST :- List of statement entry ids. * OPENING.BAL :- Opening balance on the startt date. * ER :- Any errors found Question ACCT.ENT.TODAY not raised Answer Setting the field ENT.TODAY.UPDATE to "YES" in ACCOUNT.PARAMETER will make the system to update the ACCT.ENT.TODAY file. This will contain the account wise entries inputted on TODAY's date. In COB, system will update OPEN.ACTUAL.BALANCE and OPEN.CLEARED.BALANCE , based on the entries in ACCT.ENT.TODAY file. Question Explain the functionality of position accounting with an example? Answer The functionality of position accounting with an example. Consider two position accounts is updated for the transaction involving buying of 100USD by selling 200GBP. Note: Here GBP is considered as local currency. Position accounts hold value as shown: POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -200 GBPUSD140160201000 -200 100 Now the exchange rate for USD is changed. On running COB, revaluation for USD is processed. Say, due to revaluation Position account will have a balance of GBP 250 which reflects correctly the new price of the USD position of 100 USD at the new price. POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -250 GBPUSD140160201000 200 100 For achieving this, system will revalue the local equivalent of the USDGBP account and post revalued amount to the GBPUSD account. The corresponding opposite leg will be posted in P&L. This will happen for all the NC position accounts. For forward FX, since the contract contributes to the off balance GL, separate category is used for position account (19022). In this case, the USDGBP CAL will be revalued. But the GBPUSD posting will not happen as the posting to P&L will be carried on with FX

revaluation of unrealized profit which will be carried out based on forward position. This is the functionality of position accounts for forward FX. Question Explain the functionality of position accounting with an example? Answer The functionality of position accounting with an example. Consider two position accounts is updated for the transaction involving buying of 100USD by selling 200GBP. Note: Here GBP is considered as local currency. Position accounts hold value as shown: POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -200 GBPUSD140160201000 -200 100 Now the exchange rate for USD is changed. On running COB, revaluation for USD is processed. Say, due to revaluation Position account will have a balance of GBP 250 which reflects correctly the new price of the USD position of 100 USD at the new price. POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -250 GBPUSD140160201000 200 100 For achieving this, system will revalue the local equivalent of the USDGBP account and post revalued amount to the GBPUSD account. The corresponding opposite leg will be posted in P&L. This will happen for all the NC position accounts. For forward FX, since the contract contributes to the off balance GL, separate category is used for position account (19022). In this case, the USDGBP CAL will be revalued. But the GBPUSD posting will not happen as the posting to P&L will be carried on with FX revaluation of unrealized profit which will be carried out based on forward position. This is the functionality of position accounts for forward FX. Question Can the accounts category be amended? What are the implications? Answer Yes, accounts category can be changed. Following are the implications of changing the category: I) Condition group of Account will change based on new category. II) Change in CONDITION.GROUP will affect the Cr & Dr interest rate. III) Consol key of account may change based on new category. IV) Balance in old CAL will be moved to new CAL. Question When will the commitment available amount increase? Answer When LD loan under LD revolving commitment contract goes to PD in amount type PR during batch or online, the commitment available amount is not increased. The commitment available is increased only when LD loan is paid by debiting account or PD PR has been paid in PD module.

Whenever PRIN.INCREASE is done in LD LOAN contract, the balance in the account is checked and depending upon the availability of funds, appropriate override message is generated. Under no circumstances, PD record is created or updated for PRIN.INCREASE operation. The principal decrease in LD contract does not generate or update PD contract. Instead, irrespective of the liquidation mode, if balance is available in the liquidation account STMT.ENTRY is generated. If not, suitable override message is given by the system. This functionality is available only from the release R09 Question What are SGN entries and why they are raised Answer Query: 1) Why are the Special Entry records made? At which situation could we expect more of these entries? Response: 1. If the Closing balance of particular account changes from CREDIT to DEBIT or from DEBIT to CREDIT, when compared to the previous days closing balance, then system will raise SGN entries during the subsequent COB. Query: Is it possible to configure T24 not to make these SGN entries. Response: 2. These entries are raised in order to update the correct asset type based on current balance. These entries are essential for T24 as per its current architecture and for the proper updation of the files EB.CONTRACT.BALANCES and CAL. Question RE.CONSOL.SPEC.ENTRY with transaction code SGN meaning Answer For example : Account having the balance of DEBIT asset type Day 1:DEBIT asset type in CAL Day 2:By depositing cash makes the balances as CREDIT During DAY2 COB , System reverse the DEBIT asset in CAL and update the CREDIT balance under CREDIT asset type in CAL. For this changes SGN entries will be raised , there will not be any corresponding STMT.ENTRY. Question The effects of changing this field in ACCT.GROUP.CONDITION from AVAILABLE to WORKING

Answer Setting the CREDIT.CHECK to blank or WORKING in ACCT.GROUP.CONDITION, the Available funds will be updated with all transactions, except unauthorised credits and Overdraft check uses only working balance for this group of accounts. Future cash flow check uses the Available balance ladder as from the value/exposure date of the transaction. Question PL CLOSE OUT process work flow prior and after R08 Answer The year end process has been changed from r08 release. Kindly find the below process in lower release and the higher release. Below R08: 1. The system will close the CPL by posting the reversal entry(CATEG.ENTRY) for each group of CPL key balances. 2. Consolidated PL closing balances of that respective year will be directly updated to the balance of the PL category 69999. 3. Then the system will post the CATEG.ENTRY to move the consolidated closing amount (one for CREDIT and the other for DEBIT) from PL category 69999 to the PL CLOSE category account by raising the STMT.ENTRY. From R08: The system will close the CPL by posting the reversal entry(CATEG.ENTRY) for each group of CPL key balances and the balance will moved to the PL CLOSE category account by posting a STMT.ENTRY. Example : Hope the below example will be more clear. Consider, CPL balance pertaining to group 1 = 1000 USD CPL balance pertaining to group 2 = 500 USD Then, in the lower releases, a) The system will post a CATEG.ENTRY for -1000 USD to the group 1 category. b) The CATEG.ENTRY will be posted for -500 USD to the group 2 category. b) 1500 USD will be directly updated to the category 69999 without any entry. c) Then the CATEG.ENTRY will be posted for the amount -1500 to the 6999 category and a STMT.ENTRY will be posted for 1500 USD to the PL CLOSE category account. In higher release, a) 1000 USD pertaining to the group 1 category will be moved to the PL CLOSE category by post a CATEG.ENTRY for -1000 USD to the group 1 category and a STMT.ENTRY for 1000 USD to the PL CLOSE category. b) Similarly 500 USD pertaining to the group 2 category will be moved to the PL CLOSE category by post

a CATEG.ENTRY for -500 USD to the group 2 category and a STMT.ENTRY for 500 USD to the PL CLOSE categ Question Accrued interest and capitalized interest for LD.LOANS.AND.DEPOSITS Answer To get the Interest amount Already Capitalized: FIELD NO 38. = INT.RECEIVED (LMM.SCHEDULES.PAST ) This field gives the interest amount that has been collected from the customer. To get the Daily Outstanding Balance for LD: FIELD NO 11 = OUTS.ACCRUED.INT (LMM.ACCOUNT.BALANCES) : This field holds the balance of accrued interest, that is yet to receive from the customer. Often called 'interest earned not collected' and current interest receivable'. Question What is the need for EB.FINANCIAL.SYSTEM? Answer The purpose of EB.FINANCIAL.SYSTEM, is to handle the creation of unbalanced accounting entry. Based on the setup done in this table, system will either throw error the accounting entries created by transaction is not balanced (or) will create an automatic balancing entry for internal account category defined. You can balance the COB entries and/or online entries based on the flag set in the below fields. 3. 1 AUTO.BL.SYS.ONL Y 4. 1 AUTO.BL.SYS.COB Y A category must be reserved for only posting such self-balancing entry. And a local currency internal account must exist for this category. If you choose to balance accounting entry automatically, then this internal account will be used to post the balancing entry. 6. 1 BALANCING.CAT.. 14012 The balancing entry created will have the below transaction code. 7. 2 BLNCING.TXN.CDE 11 If you do not want to create self-balancing entry, set the fields AUTO.BL.SYS.ONL & AUTO.BL.SYS.COB to NO. In this case, system will create fatal error for transactions producing unbalance accounting entry. If you set the fields to Y, in event of unbalanced transactions (assume FT transaction has produce only credit entry), system will create a self-balancing entry. A message like "Self Balancing Entry Raised Contract" will be registered in EB.EOD.ERROR for creating self-balancing entry.

Question Penal Charges on Recurring deposits Answer Penal charges on a recurring deposit are processed during COB by the batch job AZ.FIND.LATE.PAYMENT. Defaulted repayment schedules are identified by comparing the scheduled balance for the date with the actual working balance of the account. Also, the defaulted schedule amounts are populated in the fields LAST.PAY.DATE and AMOUNT.DUE in the AZ.SCHEDULES record. Penal charges in AZ are calculated based on the setup in the corresponding AZ.PRODUCT.PARAMETER. The following fields are referred to in AZ.PRODUCT.PARAMETER while processing penal charges. LIAB.TO.PENALTY - Based on the value given under this field, the number of delayed instalments liable to penalty will be arrived and corresponding charges defined under LATE.PMT.FEE will be charged. Numbers specified in this field refers to number of instalments. For example, if 2 is defined here, the account will be liable for late fee after 2 instalments are missed. LATE.PYMT.FEE - Defines the charges to be levied on the Savings Plan/ Recurring Deposit type of accounts for having paid the instalments late. Based on the value given under LIAB.TO.PENALTY, the delayed instal Question What are the possible values of CRF TYPE field in STMT.ENTRY and their scenarios/explanations. Answer For account related asset types are Offbalance Sheet Accounts indicated by CONTINGENT.INT field OFFSUSP - Suspensed(INT.NO.BOOKING set) OFFDB - < zero OFFCR - > zero On Balance Sheet SUSPENS - Suspensed DEBIT - > zero CREDIT - < zero Question How does the concept of Balanced Accounting Entries work? Answer T24 follows double entry book keeping principles with a single base currency. Applications should therefore provide financial movements that net to zero in local currency. There is currently no validation that the application supplies balanced entries.

If unbalanced accounting entries are generated it can result in an out of balance financial system that requires a manual data correction procedures. Question What are the entries involved during EB.COMPANY.CHANGE? Answer Whenever we move contracts/account from one company to another using EB.COMPANY.CHANGE, system will raise RE.CONSOL.SPEC.ENTRY with TRANSACTION.CODE eq 'APP' for the new company and old company. Along with these entries system will raise STMT.ENTRY against the interco category (interco-entries)to keep the GL of each company in balance. Question When one loan goes into overdue, then the other loans of the same customer need to be classified as past due ? Answer As per the existing T24 functionality the Past due will be created when LIQUIDATION.MODE in underlying contract is set as Semi-automatic or Manual. If the LIQUIDATION.MODE is set as Semi-automatic and the corresponding Liquidation Account doesnt have enough balance to repay the contract then the system will create the PD for the remaining amount for the underlying contract. If the LIQUIDATION.MODE is set as Manual then it will not consider the Liquidation Account, the system will directly create the PD for the schedule amount for the underlying contract.

It is not possible to create the PD records for all the LD contract of the customer when a PD record is created for one LD contract of that same customer. So it is not possible with the existing design Question In Treasury menu model bank, core have enquiry nostro (ENQ NOSTRO.SUMMARY and ENQ NOSTRO.POSITION). Can you explain us, what function for this enquiry and can you guide how to trace from where system take the balances? Answer ENQ NOSTRO.SUMMARY The ENQ NOSTRO.SUMMARY will display the consolidated balance Nostro accounts on Currency wise for the next five working days from current date by picking details from the available ladder of the Account

(fields 149 - 156). ENQ NOSTRO.POSITION The ENQ NOSTRO.POSITION is the next level enquiry to be invoked when descending the enquiry levels of the ENQ NOSTRO.SUMMARY, displaying the next five working days Nostro balances of the respective banks Currency wise from the available ladder of the Account. This can also be launched separately without drilling down from the ENQ NOSTRO.SUMMARY for the specified currency in the selection criteria. Question How does the system act for unexecuted standing order with type FI? Answer If a Standing Order fails due to insufficient funds (System will check STO amount with the Account balances), the associated funds transfer record generated is placed on hold status pending manual intervention. Standing Orders can be set for automatic resubmission if failure is due to insufficient funds. Two methods exist to retry process. These methods can be combined to create a continuous retry process that runs all day every day until funds become available or until the limit of 10 days is reached. The maximum limit at the moment is only 10 days. Method 1: Daily resubmission is enabled in FT.APPL.DEFAULT by entering a value for the number of days in the field NO.RESUBMSSN.DAYS. This field will allow the maximum 10 days of resubmission. For up to 10 days maximum within the COB batch processing daily system will check the availability of funds. When the retry limit is reached without sufficient funds, the funds transfer record is created in hold, and T24 can generate a delivery advice message to this effect. The message to be used is specified in FT.APPL.DEFAULT application SO.MESSAGE.TYPE field value. Method 2: We can enable online resubmission of STO by specifying RETRY.START.TIME and RETRY.END.TIME in a 24-hour clock notation, within the FT.APPL.DEFAULT record. To start the online process the EB.SO.RETRY.CHECK record in EB.PHANTOM needs to be verified. This record contains the field parameter SLEEP.SECS to allow the user to indicate a time interval in seconds between retry attempts. For example, to retry failed Standing Orders every hour enter an interval of 3600 (60 seconds x 60 minutes). If any moment in the account balances of the STO then this phantom will check the STO balance with the account balance and if sufficient funds are available to process STO system will execute the STO. When the retry limit is reached without sufficient funds, the funds transfer record is created in hold as

before, and T24 can generate a delivery advice message to this effect. The message to be used is specified in FT.APPL.DEFAULT application SO.MESSAGE.TYPE field value. Question What is the purpose of Dummy entries created in STMT.ENTRY file, how and why are they generated? Answer When you are running a stmt.entry related enquiry (eg. STMT.ENT.BOOK or STMT.ENT.VALUE), stmt.entry will be generated with id as DUMMY in below scenarios. i. When enquiry launched for the account that doesn't exist in the system. ii. When enquiry launched for an existing account and the selected date doesn't hold any entries. The enquiry is designed in such a way to display the balance at period. start and period. end to '0'. In order to achieve this, a DUMMY STMT.ENTRY id is generated. If you want to remove the DUMMY stmt.entry records from the STMT.ENTRY file, you can do the below from your jbase prompt. Replace 'XXX' with the company mnemonic. Jsh>SELECT FXXX.STMT.ENTRY WITH @ID LIKE DUMMY XX records selected. >DELETE FXXX.STMT.ENTRY XX records deleted. Question Please explain the difference between the CRB and CRD report? Answer CRB reports are based upon the flat CRF report but contain details of the individual contracts and accounts that make up each line. The CRB report will have the line balances, as well as the contract balances. It has the Asset & Liabilities and Profit & Loss related information and CONTRACT level details. CRD reports are the investigation reports that provide details of mismatches between CAL key level balances and underlying Contract / Account level balances for a particular line or lines on a report. The CRD report is classified into two types RE.STAT.MISMATCH and RE.STAT.BAL.REC RE.STAT.MISMATCH - Reports the consol key which is having difference between ECB and CAL balances. RE.STAT.BAL.REC - Reports the consol key and contract balances related to all the lines. It also reports the balance mismatch Question

We are unable to modify the existing record MONTHLY from STMT.GEN.CONDITION. System throws the error CONDITION EXIST ERROR MESSAGE. How to rectify this? Answer The error will be shown because of the following two reasons: a) The value(CATEGORY) entered the field VALUE has been already used in the other STMT.GEN.CONDITION records b) If there is only one value(CATEGORY) in the record and if you try to delete that category and authorize the same will result in the same error. Instead of deleting the value from the record where there is only one value, kindly reverse the particular record (MONTHLY). After reversing the record, kindly delete the value from the concat file FXXX.STMT.GEN.COND.PRTY Eg., >JED FXXX.STMT.GEN.COND.PRTY 1990 0001 }]MONTHLY After this press ESC and type FD. This will delete the particular record Question What is the need for running REGEN? Answer For generation of CONSOLIDATE.ASST.LIAB (CAL) and CONSOLIDATE.PRFT.LOSS (CPL) keys, we will be using the application CONSOLIDATE.COND. Whenever there are any changes made in the CONSOLIDATE.COND record, then there will be changes in the CAL and CPL keys. Also there will be an impact in the system, the same contract or account balance will be present under 2 consol keys. In order to resolve the problem we need to run the REGEN, to move the balances from the old keys to new key.

When we make any changes in CONSOLIDATE.COND record which are ASSET&LIAB or PROFIT&LOSS and if there is no CAL and CPL key present in the system, then there is no need of running the REGEN, since changes are done in an empty database. But when we make any changes in CONSOLIDATE.COND record which are ASSET&LIAB or PROFIT&LOSS and if there are CAL and CPL keys present in the system, then we need to run REGEN in order to change the format of the CAL and CPL keys. Question

What is the use of field CAP.INT plus REPAY.CAP set to YES for an LD contract? Please explain with an example. Answer CAP.INT is a capitalisation flag in LD.SCHEDULE.DEFINE record to identify interest capitalisation so that for every I schedule, the user can set a flag to indicate whether that particular I schedule should be capitalised or not. If CAP.INT set to YES for particular I-Schedule then it is added to the corresponding Principal Schedule. If set to NULL then interest will be debited from the Customer account. Consider below example: ---------------------------- CAP.INT in LD.SCHEDULE.DEFINE for each I schedule TRANSACTION DATE AMOUNT BALANCE CAP.INT Loan Drawdown 30/6/04 500,000.00 500,000.00 Interest Capitalised 1/8/04 2,191,78 502,191.78 CAP.INT set to YES. So interest is capitalised with Principal Payment 1/8/04 (2,500.00) 499,691.78 Interest 1/9/04 2,121.98 499,691.78 CAP.INT is NULL So interest is not capitalised. Payment 1/9/04 (2,500.00) 497191.78 The field REPAY.CAP has no impact on CAP.INT field. If field REPAY.CAP is set to YES then CAPITALISATION field cannot be set to YES. If CAP.INT field set to YES then CAPITALISATION field cannot be set to YES. Question What are the entries involved during EB.COMPANY.CHANGE? Answer Whenever we move contracts/account from one company to another using EB.COMPANY.CHANGE, system will raise RE.CONSOL.SPEC.ENTRY with TRANSACTION.CODE eq 'APP' for the new company and old company. Along with these entries system will raise STMT.ENTRY against the interco category (interco-entries)to keep the GL of each company in balance.

How to create user-defined OVERRIDE and use it with OVERRIDE.CLASS.DETAILS


How to create user-defined OVERRIDE and use it with OVERRIDE.CLASS.DETAILS? Purpose This document describes the creation of user-defined OVERRIDE and its setup using

OVERRIDE.CLASS.DETAILS. This setup is used where a user's access to input some kind of transaction and not to authorize transactions which have some specific overrides. The OVERRIDE.CLASS.DETAILS setup is used to give permission to users to authorize the transactions based on value entered in corresponding field. Procedure

Applicable and Involvement

T24 Release applicable No of steps involved

From G13 Onwards 12 EB.API, PGM.FILE, VERSION, OVERRIDE, OVERRIDE.CLASS.DETAILS and USER

Applications/Files involved

The following steps are used to create user-defined OVERRIDE and set OVERRIDE.CLASS.DETAILS for a specific field.

The user defined OVERRIDE is triggered in INPUT.ROUTINE by comparing the corresponding field value of the current application with field value of the relevant application. Step 1: Compile and catalog the INPUT ROUTINE - TEST.AUTH (Sample routine)
* Local input routine to raise OVERRIDE message based on the DEBIT.AMOUNT * Field in the FT record.

SUBROUTINE TEST.AUTH

$INSERT I_COMMON $INSERT I_EQUATE $INSERT I_F.FUNDS.TRANSFER $INSERT I_F.ACCOUNT

GOSUB INITIALISATION GOSUB PROCESS

INITIALISATION:

FN.FT="F.FUNDS.TRANSFER"

F.FT="" FN.AC="F.ACCOUNT" F.AC="" RETURN

PROCESS:

CALL OPF(FN.FT,F.FT) CRT "FT ID":ID.NEW ACCID=R.NEW(FT.DEBIT.ACCT.NO)*assign the DEBIT.ACCT.NO to variable ACCID CALL OPF(FN.AC,F.AC) CALL F.READ(FN.AC,ACCID,R.AC,F.AC,Y.ERR)*Read the corresponding DEBIT.ACCT.NO record to R.AC DEBAMT=R.NEW(FT.DEBIT.AMOUNT) *assign the DEBIT.AMOUNT to variable DEBAMT AMTINACC=R.AC<AC.WORKING.BALANCE> *assign the DEBIT.ACCTs WORKING.BALANCE to variable AMTINACC *Here we are checking whether the transaction amount is greater than the *account balance and TEXT is the common variable which is used to build the *values to the OVERRIDE which is to be generated. IF DEBAMT > AMTINACC THEN TEXT="ACCT.NEW.OVERRIDE" *Passing the values to the OVERRIDE message TEXT<2> = R.AC<AC.CURRENCY>:VM:ABS(DEBAMT): VM :ACCID TEXT<3> = R.AC<AC.CURRENCY> TEXT<4> = ABS(DEBAMT) TEXT<5> = ACCID TEXT<6> = R.AC<AC.CUSTOMER> CURR.NO=1

CALL STORE.OVERRIDE(CURR.NO) END RETURN

Step 2: Create a record in EB.API for input routine TEST.AUTH

Step 3: Create a record in PGM.FILE for input routine TEST.AUTH

Step 4: Create a VERSION record for FUNDS.TRANSFER application and attach the INPUT routine

Step 5: Create a new OVERRIDE.CLASS.DETAILS record NEWOVER

Step 6: Create a new OVERRIDE record ACCT.NEW.OVERRIDE and attach OVERRIDE.CLASS.DETAILS to Detail.1 field:

Step 7: Create USER - USER1(ANAND11)


USER1 has rights to approve the ACCT.NEW.OVERRIDE override. OVERRIDE.CLASS field of this USER record has value EMP1. Hence USER1 can approve this override when the transaction amount falls between 1 and 50000

Step 8: Create USER - USER2(ANAND12)

USER2 has rights to approve the ACCT.NEW.OVERRIDE override. OVERRIDE.CLASS field of this USER record has value EMP1 and EMP2. Hence USER2 can approve this override when the overdraft amount falls between 1 to 100000.

Step 9: CREATE USER - USER3(INPUTTER)


USER3 has rights to approve the ACCT.NEW.OVERRIDE override .OVERRIDE.CLASS field of this User record has value EMP1,EMP2 and EMP3. Hence USER3 can approve this override when the transaction amount falls between 1 and 500000.

Step 10: USER1(ANAND11) inputs a FT (for with DEBIT.AMOUNT for 75,000) and on validating the transaction, the local override ACCT.NEW.OVERRIDE is generated and when the record is tried to authorized using USER1(ANAND11), the record is moved to INAO status.

Step 11: When USER1 tries to authorize the record, the record is moved to INAO status

Step 12: When USER2 tries to authorise ,the record moves to live status. USER2 has rights to approve this
override. Since OVERRIDE.CLASS field of USER2 record has value EMP2. Transacti on amount is 75000 and falls within the range specified in EMP2 classificaton .

You might also like