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 – it’s 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 won’t be
built for the accounts so there won’t 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. It’s 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 id’s 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.B
AL,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 day’s 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 doesn’t
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

From G13 Onwards

No of steps involved

12

Applications/Files involved

EB.API, PGM.FILE, VERSION, OVERRIDE, OVERRIDE.CLASS.DETAILS and USER

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 *assign the DEBIT.ACCT’s 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 = R.AC:VM:ABS(DEBAMT): VM :ACCID
TEXT = R.AC TEXT = ABS(DEBAMT) TEXT = ACCID

TEXT = R.AC 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. Transaction
amount is 75000 and falls within the range specified in EMP2 classificaton .