Embed Size (px)
Citation preview
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 – 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-Apr-
2011(-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 INACCURATE-
ENTRIES 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, USD-
12800-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, 10693-
20090402 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 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<AC.WORKING.BALANCE> *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<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. Transaction amount is 75000 and
falls within the range specified in EMP2 classificaton .
