T24 Account Group Parameters R16 PDF

T24 Account Group Parameters R16.
T24 Accounts R16.1 1

T24 Account Group Parameters R16.1


This learning unit is aimed to give an understanding on the set up of parameters relating
to interest, charge and statements functionalities for Accounts Application.
Further we will also know how to link the charges to table called General Charge.


GROUP.CAPITALISATION table is used to specify the next date and subsequent frequency
of capitalisation of debit and credit interest, for a group of Accounts.
GROUP.CREDIT.INT table allows the specification of interest rate and method for credit
interest for groups of accounts.
GROUP.DEBIT.INT table allows the specification of interest rate and method for debit
interest for groups of accounts and provides the link to the GENERAL.CHARGE table
where the charges applicable to the same groups of Accounts are specified.
GROUP.CONDITION table is used to define Group Level conditions for the calculation
and application of interest, charges and Annual Payment Rate.
ACCOUNT.ACCRUAL table is to provide the system with information at Company level
about how and when to process accruals of interest and charges on Customer Accounts
and whether interest capitalisation is inclusive or exclusive of the balance on
capitalisation date, the value dates of interest entries generated and the day on which
the entries are booked. More on Account.accrual will be covered in the Module –
Account Parameters.

Preferential conditions for application of interest and charges can be set for different
products to different Customers. Charges could be based on transactions, or on any
debit exceeding a particular value, or on the turnover of debit transactions in a period,
or on the number of debit transactions in a period, or similar rules for credit operations
or on not maintaining a minimum balance or on statements or any Government levy.
As a first step, charges rules for a Bank are defined in tables like TRANSACTION.CHARGE,
HIGHEST.DEBIT, TURNOVER.DEBIT, NUMBER.OF.DEBIT, GOVERNMENT.MARGIN,
DEBIT.INT.ADDON, ACCT.STATEMENT.CHARGE, BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT, TURNOVER.CREDIT and INTEREST.STATEMENT.
The charges defined under these tables are grouped under GENERAL.CHARGE Table and
the General Charge Table can be linked to an account group.

Statement related tables are AC.STMT.PARAMETER, CONDITION.PRIORITY and

STMT.GEN CONDITION. AC.STMT.PARAMETER table is used to define defaults for
account statement details when opening new accounts. When a new account is
opened, an ACCOUNT STATEMENT record, specifying the date and frequency for
printing account statements is generated automatically by the system.
CONDITION.PRIORITY Table is used to define the data elements for grouping for
statement purpose. STMT.GEN.CONDITION table is used to define rules for
determining the default statement frequency when opening new Accounts.


It is possible to set preferential service conditions for maintenance and servicing of

accounts. The conditions are related to various activities which happen during the
lifecycle of an account . Preferential conditions may be set for interest, charges, other
tariff structure, accrual, and statements production. Groups are determined based on
the selected elements from CUSTOMER and ACCOUNT record. The priority data items
from customer and accounts are defined in the CONDITION.PRIORITY table for the
record ACCOUNT.
Conditions for the calculation and application of interest and charges may be specified
at the group level. If an account is set up with different service conditions from the
group to which it belongs, the group conditions are overridden with special conditions
set for individual account level. When ever an account is opened, it is linked to the
appropriate group based on the details of underlying Customer and nature of account.
There must always be a default group created for accounts.

It is possible to control the statement entries appearing in the customer statement.

APP.POSTING.DAY Field specifies whether interest is to appear on a customer statement
on the date it is calculated or on the following day.
If NEXT is specified, details for producing the interest entries are written in a temporary
file. The entries are booked at part of start of day processing on the next working day,
by the program INT.POST.NEXT.
The Profit and Loss entries are booked on Capitalisation day, regardless of the contents
of this field.
It is possible to specify whether account maintenance charges are to be accrued every
month end or only booked to Profit and Loss when they are applied. This is achieved
through INCLUDE.CHARGES Field.
Account maintenance charges may be applied monthly, quarterly or six monthly as
specified in the Company table, but always at the end of a calendar month.


The set up of interest and charges grouping for Accounts structure starts with
CONDITION.PRIORITY table. T24 permits us to decide the order of priority to apply
criteria for creating groups for differential treatment.
Based on the priority and criteria chosen in CONDITION.PRIORITY, the actual fields are
created in ACCT.GEN.CONDITION. Rules and values to criteria, when specified in this
table, will group account records when opened into appropriate groups. It is mandatory
that a default group with no conditions should be setup before we go on to create
conditions attached groups.
Based on these groupings, Capitalisation rules, debit interest conditions and credit
interest conditions for each group need to be setup in GROUP.CAPITALISATION,
GROUP.DEBIT.INT and GROUP.CREDIT.INT. If needed, account specific rules for all or
some of the above 3 can be defined in ACCT.CAPITALISATION, ACCOUNT.DEBIT.INT and
ACCOUNT.CREDIT.INT files.
Charges related setup is done in related files and linked to GENERAL.CHARGES which is
then attached to GROUP.DEBIT.INT or ACCOUNT.DEBIT.INT. At least one record for
default charges is mandatory in GENERAL.CHARGE.


CONDITION.PRIORITY table with Id as ACCOUNT is used to specify data elements

from CUSTOMER and ACCOUNT applications that are used to determine
grouping conditions for accounts.
CONDITION.PRIORITY table is used to define criteria like nationality, industry ,

sector etc available in the CUSTOMER application and product category, currency
from the ACCOUNT application.
For example, groups could be saving account of residents , saving account of non
residents , current account of corporates engaged in software industry and
current account of private citizens of US nationality. In these examples, criteria
used are residence , nationality , industry and sector from CUSTOMER
application and savings and current accounts from ACCOUNT application.
Separate rules should be setup for interest and charges and statement purposes
with record Id in CONDITION.PRIORITY as ACCOUNT and STATEMENT
respectively. If company wise rules are required to be set up then the record Id
of CONDITION.PRIORITY is suffixed with a “-” (hyphen) and company code
namely ACCOUNT-company code and STATEMENT-company code. Else the data
items will default from ACCOUNT and STATEMENT record Ids .
For example: If separate rules for interest and charges are required for a
company GB0010001 and GB0010002, then two records with ids
ACCOUNT.GB0010001 and ACCOUNT.GB0010002 are required.
If 3 companies setup with defaulting rules different only for third company
namely GB0010003, then 2 records namely ACCOUNT and ACCOUNT-
GB0010003 is setup, where the former is default conditions applied to first 2
companies.

In CONDITION.PRIORITY , you can rank the proposed selection criteria and indicate the
applications from where the data is to be chosen. Allowed applications are ACCOUNT
and CUSTOMER. Any single value or local reference fields from these applications can be
chosen for making the selection criteria.
PRIORITY.ITEM is a multi value Field which defines the file and field from that file used
for criteria definition. The format is APPLICATION>FIELD.NAME. For example, in the
CONDITION.PRIORITY record for ACCOUNT, the PRIORITY.ITEM field with
ACCOUNT>CATEGORY implies that CATEGORY Field from the application ACCOUNT is
an element of criteria.
PRTY.VALIDATION Field indicates details of validation to be displayed as enrichment for
the group definition. For example: In the above when field is set as
“CATEGORY>DESCRIPTION”, then for a value entered in ACCT.GEN.CONDITION , System
validates with CATEGORY table and DESCRIPTION in that CATEGORY record would be
displayed as an enrichment. It is also possible to attach a routine for validation. The
order in which PRIORITY.ITEM is defined in the multi value set determines the priority of
the item. For example : PRIORITY.ITEM.1 and PRIORITY.ITEM.2 when defined as
ACCOUNT>CATEGORY and CUSTOMER>SECTOR implies that Category from Account is of
higher priority than the other.

The selection criteria for preference groups can be amended along with or without
change in the ranking conditions. Dated CONDITION.PRIORITY records are required to
be created to achieve this. The effective date could be either processing date or future
date.
Id will be of the format ACCOUNT--<DATE>. The value in the middle field of Id can be
used for company specific definition. Based on the previous selection criteria, general
and group specific conditions would have been built. As a result of the new selection
criteria there would be a need to re-define rules for some or all of the groups.
While defining CONDITION.PRIORITY records applicable in future , it is possible to
specify which ACCT.GEN.CONDITION and ACCT.GROUP.CONDITION records need to be
retained by specifying their Ids in GEN.COND.KEEP and GROUP.COND.KEEP Fields.
During COB processing on the specified date, these ACCT.GEN.CONDITION records would
be automatically modified with priority data items applicable for the new structure,
existing priority data items and their values will be retained...New priority items will be
updated with null values.
Advised to leave GEN.COND.KEEP as null so that old records are removed and new ones
redefined. GROUP.COND.KEEP can also be set as ALL to retain all existing records.


This workshop solution is meant to have hands on setting a Condition Priority Record


Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is dependent on the

settings made in CONDITION.PRIORITY for ACCOUNT and STATEMENT, respectively.
ACCT.GEN.CONDITION table is used to define rules for grouping together Accounts for
which the same interest and charges conditions apply. T24 allows the user to form up to
999999 groups with IDs up to 6 numeric digits. One default group must be defined.
STMT.GEN.CONDITION table is used to define rules for determining the default
statement frequency when opening new Accounts. Accounts that require the same
statement generation frequency are grouped together.
Id for STMT.GEN.CONDITION is pre-determined and indicates the frequency of statement
generation namely . Daily, Monthly, Quarterly, Six-Monthly and Yearly. Accounts whose
details match the conditions specified for Condition Code 'DAILY' will have a default
statement frequency of 'BSNSS' i.e. every working day.
When CONDITION.PRIORITY record is created with an effective date , after COB
processing on the specified date, the dated Gen condition records would replace the
corresponding record. Those Gen condition records whose IDs are not included in the
GEN.COND.KEEP of the corresponding dated CONDITION.PRIORITY or those records
which do not have corresponding Gen condition record, would be dropped after the COB
processing.
Note: Till R12, only 9999 groups can be formed but since R13 T24 allows 999999 groups
to be formed.


This workshop solution is meant to have hands on setting a new Category


This workshop solution is meant to have hands on setting a new Account Gen Condition


Like forming groups for interest and charges, separate grouping is done for generation of
statements.
CONDITION.PRIORITY with Id as STATEMENT specifies, which data elements in
CUSTOMER and ACCOUNT tables records are used to determine preference condition
groups for statement generation.
The Id for STMT.GEN.CONDITION is pre-determined and indicates the frequency of
statement generation - Daily, Monthly, Quarterly, Six monthly and Yearly.
Daily frequency generates statements on every working day (every Business day).
When there is need to set up separate statement generation rules, it is possible to
change the frequency at account level using ACCOUNT.STATEMENT table which will
override the conditions set at group level.

Accounts that need to have the same statement generation frequency are grouped
together. For example DAILY frequency may be set up for current accounts of private
individuals residing in USA. It could also be for all current accounts of all Corporates.
FREQUENCY.TYPE Field identifies whether the statement due date is to be according to
the anniversary of the opening date of the account or the period end date.
For period end date, the end date depends upon the key of the record.
Monthly - Calendar end date of the month.
Quarterly - Calendar end date for the end of March, June, September or December.
Six Monthly - Calendar end date for the end of June or December.
Yearly - Calendar end date for the end of December.
If set as ANNIVERSARY, statement are produced on the same day on which the account
was opened . If the account was opened on 15th, then statement would be produced on
15th of every month under monthly option and 15th of every quarter under quarterly
option.


This workshop solution is meant to have hands on setting a new Statement Gen
condition


Purpose of GROUP.CAPITALISATION table is to specify the next capitalisation date and

subsequent frequency for application of debit and credit interest, for a group of
Accounts. Id is same as that of the corresponding ACCT.GEN.CONDITION record. It is
possible to set separate frequencies for first and second interest for both debit and
credit interest. Out of the four required frequencies only first debit capitalisation
frequency is mandatory. Interest may be applied any day of the month. Cycles may be
different for debit and credit interest, for example debit interest may be charged
monthly and credit interest paid quarterly unless when credit interest is only calculated
as an offset to debit interest. Frequency can be D(aily) - Every day , B - Every business
day , T - Twice a month on 15th and last day of the month , Wn - Every n weeks and
Mnndd - Every nn months on the dd day. If start of day capitalisation is needed, then
START.OF.DAY.CAP is set as Y. Normally, when capitalisation date is the first of the month
which falls on a holiday, then it will take place during EOD part of a COB on the next
working day. This will be for what is normally called a split month end. For example if the
end of the month is Friday 31st and the first working day of the next month is Monday
the 3rd, then any accounts set for capitalisation on the first or second of the month will
be capitalised in the start of day processing of the COB starting on Friday 31st. If the
account is not set for start of day capitalisation then the accounts due for capitalisation
on the first or second will be capitalised during the EOD processing of the COB starting
on Monday 3rd.

It is possible to set different frequencies for interest capitalisation for Credit , Credit2,
Debit and Debit2 interest. For example, for accounts of Private individual residing in UK
and USA classified as group 1 we can set the capitalisation frequency as last date of
every month for debit interest and to pay interest for credit interest at the end of every
quarter.
On the other hand we can set up for group of current accounts of Corporates to debit
interest every quarter on the last date while for credit balances in the same accounts,
interest is not payable.
SETTLE.ACCT.CLOSE Field is used to indicate whether settlement account is required
while closing accounts falling under this group.


This workshop solution is meant for hands on setting a Group Capitalisation conditions


Rules have to be set up group wise and currency wise to take effect from the
indicated dates for each of the groups created in ACCT.GEN.CONDITION. Then Id
can be 1USD25JAN2008, where 1 is the group Id set up for USD with the effective
date.
General charges and applicable taxes for the group are indicated in CHARGE.KEY
and TAX.KEY Fields. CHARGE.KEY Field is mandatory. Even if there are no charges
to be recovered a null charge key is to be indicated.
TAX.KEY Field hold ids of Tax records (defined in TAX table) or

TAX.TYPE.CONDITION records with a "*" symbol prefixed, which specifies the
calculation and processing of taxes say one or more, applicable to debit interest.
If linked to tax record , then tax rate is applicable on all accounts in the
associated group of accounts. In the latter case, Tax can be collected based on
customer related conditions. CONDITION.PRIORITY needs to be defined for TAX
and grouping rules defined in TAX.GEN.CONDITION. For each grouping condition,
the actual tax rates available in TAX table will be linked to a TAX.TYPE.CONDITION
by defining it in TAX.CODE Field. Hence, when TAX.KEY in GROUP.DEBIT.INT is
defined with an identifier of TAX.TYPE.CONDITION, then the system will derive
the applicable tax rates based on the customer grouping. No tax is applied if
interest is not calculated. The tax record, if attached must be in existence with an
effective date not later than effective date of GROUP.DEBIT.INT.

INTEREST.DAY.BASIS gets its default value from respective CURRENCY table . If it is to

be different, then it is possible to indicate the same. If debit interest need not be
calculated, then NONE to be indicated.
Debit interest can be calculated on daily, average or highest balance during the interest
period. The required balance types used for interest calculations to be defined in
DR.BALANCE.TYPE is chosen as AVERAGE for Average balance taken during the interest
period or DAILY for Daily balance taken or HIGHEST for the highest balance during the
interest period.
It is possible to set different rates for range of balances by multi valuing interest related
fields. The calculation method can be effected using LEVEL or BAND type interest
calculation defined through DR.CALCUL.TYPE Field.
For example: Let us take the interest rate to be indicated as 5% for balances up to USD
5,000 and 6% thereafter. If the account has got a debit balance of USD 6,000, then
under level calculation, 6% interest on entire balance is applied.
But on the other hand, under band calculation, 5% on first 5,000 and 6% on the
remaining 1,000 is applied.

When more than one rate of interest is mentioned namely for a level/band calculation
type, then it is possible to define amount up to which the first rate is applied using
DR.LIMIT.AMT. If no limit is specified for the first level and if second level rates are input
, the first rate is applicable up to the overdraft limit specified for each Account in
ACCOUNT.DEBIT.LIMIT table. When more than 2 levels of rates are defined, then it is a
mandatory input.
It is possible to apply fixed or floating rates and different choices are possible for
different balances. It could be fixed for the first slab and floating for the second slab or
floating for the first slab and fixed for the second slab.
Fixed interest rate can be input through DR.INT.RATE Field.
To indicate floating rate, it is linked to BASIC.INTEREST, through DR.BASIC.RATE Field.
Over the floating rate it is possible to apply margin by adding or subtracting or
multiplying using DR.MARGIN.OPER and indicating the margin in DR.MARGIN.RATE
Field.
For example: Current rate 6.75%. If margin rate of 10 is to be multiplied to this rate,
effective rate is 7.425%, being 110% of 6.75
If floating rate is opted, it is possible to indicate a floor rate of interest in DR.MIN.RATE
Field. If this is indicated as 4, then the final rate to be applied on the account after
taking into account the floating rate and its spread, will be at least 4%.

If a minimum amount of interest is to be collected from an account, then it is specified

in DR.MIN.VALUE. Interest will be accrued on the account normally. If it is less than the
minimum amount indicated here at the time of capitalisation, then it can be optionally
waived or not. If DR.MIN.WAIVE is set to “YES”, then debit interest amounts below the
minimum value will be waived and not debited to the account and if it set to “NO”, then
value in DR.MIN.VALUE will be collected.
From R15, a new field is added in ACI/ADI and GCI/GDI tables to specify the Waiver
currency and Amount of their choice for each Account/Group. If waiver currency is not
specified then the Account currency is to be automatically defaulted in this field.
Based on the stipulated Currency, system need to convert the accrued interest from
Account Currency to the specified Waiver currency at applicable Exchange rate (Middle
rates) for determining whether it is to be waived or otherwise.
In addition to this bank also requires that these historical exchange rates need to be
stored in the System so that whenever the interest gets recalculated subsequently
because of back valued transactions etc., the same exchange rate is applied for
conversion of calculated interest from account currency to Waiver currency.
In the similar manner rules can be set for second interest to be debited from the
respective accounts, over and above the first interest.
All the fields are prefixed with DR2 for this purpose.
For example : A bank may charge additional interest on accounts with average debit

balance under USD 50,000 .

COMPOUND.TYPE Field is used to specify the number of compounding periods per year.
Optional values for the field are DAILY, WEEKn, Mnn or Nnn. If left blank, no
compounding will occur.

Similarly second interest can be defined over and above the first interest table.

Annual Payment Rate (APR) is the equivalent interest rate considering all the added
costs. This is known as TEG in France. It is arrived at based on interest rate, total
added cost, and terms. For an advance, the APR is the interest rate plus charges plus
any other incidentals payable to the Bank. APR would be equal to interest rate if there is
no additional cost s. If this is required to be indicated in the underlying accounts,
APR.REQUIRED Field should be set to yes. If APR is not required, this field is set as NO.
MAX.LEGAL.RATE Field is used to indicate the maximum legal rate applicable to the
group. It acts like a cap.
MAX.DEBIT.CHG.RATE Field identifies the maximum allowed charge as a percentage of
the first debit interest amount. For example, if it is set as 40%., then the total charges
should not exceed 40% of the interest to be collected.
The values that need to be defaulted into these three fields can be stored in
GROUP.CONDITION table. GROUP.CONDITION is used to define Group Level conditions
for calculation and application of interest, charges and APR . Id of GROUP.CONDITION
table chosen should match with the Group Id indicated in GROUP.DEBIT.INT table.


This workshop solution is meant for hands on setting a Group debit interest conditions


GROUP.CREDIT.INT table allows rules for calculation of credit interest for groups of
accounts. It is quite similar to GROUP.DEBIT.INT with a few additional capabilities. The Id
will comprise Group Id, Currency and effective date each separated by a “.”
TAX.KEY Field identifies either a Tax record (defined in TAX table) or
TAX.TYPE.CONDITION record with a "*" symbol prefixed, which specifies the calculation
and processing of tax, applicable to credit interest. Input of TAX.TYPE.CONDITION helps
in deducting different rates of tax for different group of customers within the associated
group of accounts. INTEREST.TAX.MIN Field defines the amount of interest which can be
earned tax free. If the amount of credit interest earned in a capitalisation period is
greater than this amount then tax, if defined, will be deducted. The minimum interest
taken for tax calculation will be for CR interest and CR2 interest individually and not for
the sum of the two.
It is possible to net debit interest against credit interest prior to calculating tax , if both
are capitalised on the same dates. DR interest can be netted against CR interest and
DR2 interest can be netted against CR2 interest.

Bank can define the free interest amount for tax exemption. Options are also available
to net the credit interest against the debit interest for tax purposes. Bank can also cap
the maximum credit interest rate through Cr Max Rate field. Options are available to
apply credit interest on daily, average or minimum account balance.

Similar to the features in GROUP.DEBIT.INT, it is possible to set rules for first and second
credit interest as fixed and/ or floating interest rate. The rates could be on a level or
band basis. Similarly, it is possible to waive or pay a minimum amount of interest.
CR.MAX.RATE Field is used to define the capped rate for credit balance type. If the rate
that is derived after applying any spread, is more than this rate then interest rate will be
capped at this value. Credit Interest can be calculated on daily, average or minimum
balance during the interest period by defining in CR.BALANCE.TYPE Field. If “MINIMUM”
is opted , the minimum balance during a period within a month is used for interest
calculations. It is possible to set negative interest rates on accounts in credit. To achieve
this , NEGATIVE.RATES Field on GROUP.CREDIT.INT must be set to YES. If this field is set
as either “No” or left unpopulated, then when interest rates fall below 0, zero interest
will be accrued to that account. If set to YES, this would enable collecting interest from
accounts even though they have credit balances.
Negative interest rates may occur by CR.BASIC.RATE being specified with a discount ,
such that the net effective rate is negative. This is useful for penalising overdraft
accounts maintaining credit balance. If set to BLOCK.MARGIN, negative effect will not be
allowed because of margin. Negative margin can not make the rate more negative or a
positive rate to negative. For Example, If base rate is -7, margin is -2 then net effect will
be -7.If margin is +2 then the effective rate become -5. If base rate is +5 and margin is -7
then effective rate will be zero not negative.

Minimum balance in account for interest calculation can be specified in

CR.MINIMUM.BAL along with start and end dates maintaining such minimum balance is
specified in CR.MIN.BAL.ST.DTE and CR.MIN.BAL.ED.DTE respectively. If accounts are
opened or closed between these dates, then processing is as defined below.
When CR.ACCR.OPEN.AC is set as Yes, then credit interest is calculated on minimum
balance between the opening date and end date provided balance type is minimum.
When set as NO, then no interest is applied to the account for the month of opening.
Similarly CR.ACCR.CLOSE.AC is used for account closed during the period. When set as
Yes, then end date for minimum balance calculations is taken as the closure date of the
account to enable it to receive interest for the month.
CR.ZERO.INT.BAL Field indicates that credit interest will not be paid for the entire
capitalisation period if the balance in the account falls below the value indicated here.

Input into CR.ZERO.INT.OC Field will determine whether any accounts opened or closed
during the capitalisation period will have interest paid. NO or Null input will result in no
interest being paid. YES input will result in interest being paid dependent upon the value
in CR.ZERO.INT.BAL.
It is possible to specify that credit interest is to be calculated only for offset against debit
interest and not for crediting the Customer's Account by using CR.OFFSET.ONLY Field. If
the field is set as Y, then first credit interest will be offset for first debit interest only.
Input to this field has no effect unless the debit and credit capitalisation dates are the
same.
When CR2.OFFSET.ONLY is set to Y, then only the second Credit Interest specified in the
CR2 Fields may be used to offset the second Debit Interest specified in DR2 Fields .


This workshop solution is meant for hands on setting a Group debit interest conditions


General charges related to accounts are of two types namely interest related charges
and account maintenance or ledger fees related charges.
Interest related charges include DEBIT.INT.ADDON, GOVERNMENT.MARGIN,
HIGHEST.DEBIT and INTEREST.STATEMENT charge. Either DEBIT.INT.ADDON or
HIGHEST.DEBIT may be charged but not both. All these charges are levied each time
debit one interest is applied. Charge rates applicable are those ruling on the date of
debit interest capitalisation.
Ledger fee charges may be applied monthly, quarterly or half yearly as specified in the
CHARGE.CALCULATION Field in Company record, always at the end of a calendar month.
The charges are BALANCE.REQUIREMENT, NUMBER.OF.CREDIT TURNOVER.CREDIT,
NUMBER OF DEBITS, TURNOVER.DEBIT and TRANSACTION.CHARGE which are not
immediate ones depending on the Transaction Codes. Either the NUMBER OF CREDIT or
TURNOVER.CREDIT, NUMBER.OF.DEBIT or TURNOVER.DEBIT can be charged, but not
both.
Charges effective on the date of capitalisation are applicable for the whole of
capitalisation period.


It is possible to specify a supplementary flat percentage charge on debit interest

amount through DEBIT.INT.ADDON table .
HIGHEST.DEBIT table allows specification of a Percentage charge, based upon the
Highest Debit balance recorded on an Account during the application period for Debit
Interest .
Both are applied to Debit 1 interest amount calculated by the System on Capitalisation
date. The applicable DEBIT.INT.ADDON rate is that ruling on the date of Debit 1 interest
application.
DEBIT.INT.ADDON represents the same type of charge as 'HIGHEST.DEBIT' and for this
reason both cannot be specified for application to any one particular account or group.
Highest Debit record in effect on the date of the debit interest capitalisation is
applicable to the whole capitalisation period. HIGHEST.DEBIT could also be collected as
ledger maintenance charges using HIGHEST.DEBIT.CHG in GENERAL.CHARGE table.
However free, minimum and maximum amounts of charge can be specified. First the
free amount is deducted from the calculated charge and then adjusted for specified
minimum/maximum charge amount. Separate interest related charges can be defined
for specific currencies, including local currency. The default charge defined in local
currency if defined will be applied to cover all accounts in currencies not specifically
mentioned for that currency.


This workshop meant is meant for hands on setting a debit interest addon charge
condition


This workshop is meant for hands on setting a Highest debit charge condition

GOVERNMENT.MARGIN is a table used to define supplementary flat percentage charge

calculated on overdraft balances by the system on capitalisation date and collected on
behalf of the Government. The same percentage charge is applicable for all currencies. It
is possible to specify Minimum and Maximum Amounts for specific currencies as well as
default minimum and maximum local currency equivalent amounts which apply to all
other currencies. If there are no overdraft balances during the Capitalisation period, no
Government Margin charge is made. The Government Margin rate ruling on the date of
the debit interest capitalisation is applicable for the whole Capitalisation period.
The purpose of INTEREST.STATEMENT table is to specify a flat fee which is levied at the
time of production of a Debit Interest Statement. Specific charges can be entered by
currency. For all currencies not specifically mentioned, a default charge can be entered
in local currency equivalent.
It is possible to have up to 99 records for all the charges discussed. Id comprises
numeric suffixed with month and year. These records are attached to GENERAL.CHARGE
and linked to GROUP.DEBIT.INT. For each of these charges, profit and loss category and
transaction codes are required to be defined.


This workshop solution is meant for hands on setting a Interest Statement Condition


General charges related to accounts are of two types namely interest related charges
and account maintenance or ledger fees related charges.
Interest related charges include DEBIT.INT.ADDON, GOVERNMENT.MARGIN,
HIGHEST.DEBIT and INTEREST.STATEMENT charge. Either DEBIT.INT.ADDON or
HIGHEST.DEBIT may be charged but not both. All these charges are levied each time
debit one interest is applied. Charge rates applicable are those ruling on the date of
debit interest capitalisation.
Ledger fee charges may be applied monthly, quarterly or half yearly as specified in the
CHARGE.CALCULATION Field in Company record, always at the end of a calendar month.
The charges are BALANCE.REQUIREMENT, NUMBER.OF.CREDIT TURNOVER.CREDIT,
NUMBER OF DEBITS, TURNOVER.DEBIT and TRANSACTION.CHARGE which are not
immediate ones depending on the Transaction Codes. Either the NUMBER OF CREDIT or
TURNOVER.CREDIT, NUMBER.OF.DEBIT or TURNOVER.DEBIT can be charged, but not
both.
Charges effective on the date of capitalisation are applicable for the whole of
capitalisation period.

NUMBER.OF.CREDIT table may be used to specify a fixed charge per entry that passes
over an account during the capitalisation period. Alternately, TURNOVER.CREDIT table
can be used to specify a Percentage charge on the total value of chargeable credit
entries which pass over an Account during the Capitalisation period.
Only one of these two types of charges can be specified for each Account
Entries are chargeable only for those records in TRANSACTION table which are defined Y
in TURNOVER.CHARGE Field.
Only one of these two types of charges can be specified for each Account.
Charge amount , free amount ,minimum and maximum amounts can be specified for
each currency. Default amounts in local currency equivalent may also be defined and is
used for accounts in currencies for which no amounts are specified separately.


This workshop solution is meant for hands on setting charges for Number of Credit


This workshop solution is meant for hands on setting charges for turnover credit

Similar to credit transactions charges may be set for debit transactions.

NUMBER.OF.DEBIT table may be used to specify a fixed charge per entry for debit
transactions which pass over an Account during Capitalisation period.
Alternatively, TURNOVER.DEBIT table is used to specify a percentage charge on the total
value of chargeable debit entries which pass over an Account during the Capitalisation
period.
Entries are chargeable only for those records in TRANSACTION table which are defined Y
in TURNOVER.CHARGE Field.
Only one of these two types of charges can be specified for each Account.
Charge amount , free amount ,minimum and maximum amounts can be specified for
each currency. Default amounts in local currency equivalent may also be defined and is
used for accounts in currencies for which no amounts are specified separately.


This workshop solution is meant for hands on setting charges for Number of debit.


This workshop solution is meant for hands on setting charges for turnover debit

Purpose of BALANCE.REQUIREMENT table is to define a fixed charge to be applied if a

specified Balance is not maintained in an account. The required balance may be defined
as the minimum or average Balance over the capitalisation period. Charges for different
Balances amount may be specified and can also be defined currency wise.
ACCT.STATEMENT. CHARGE indicates charges for supplying full statement, copy of
statement and/or for every sheet of the statement. The number of free statement pages
that may be allowed, minimum and maximum amounts can also be indicated. These
details can be set up for default and currency wise.
For all the account maintenance charges discussed rates on capitalisation date is valid
for the entire period.
It is possible to have up to 99 records for all the charges discussed. Id comprises of
numeric suffixed with month and year. These records are attached to GENERAL.CHARGE
and linked to GROUP.DEBIT.INT. For each of these charges, profit and loss category and
transaction codes are required to be defined.


This workshop solution is meant for hands on setting charges for Balance Requirement

This workshop solution is meant for hands on setting charges for Account Statement

TRANSACTION.CHARGE table allows a charge, determined by the Transaction Code, to

be specified for each entry that passes over an Account during the capitalisation period.
For example charges for cash withdrawal can be set up. The Id comprises of a sequence
number, an effective date and an optional general charge code.
If the general charge code is used the transaction charge will be linked specifically to the
accounts linked to the general charge record, otherwise it becomes generic to all general
charges.
Transaction Charge record which comes to effect on the effective date is applicable for
the whole of the capitalisation period. The Charge Amount can be expressed either on a
unit basis, which represents the cost per entry, or as a Percentage of the total value of
the entries or a FT.COMMISSION.TYPE.
If a valid FT.COMMISSION.TYPE record is attached then the transaction charge is taken
based on the conditions specified in the FT.COMMISSION.TYPE. Category, debit-credit
transaction codes defined in the TRANSACTION CHARGE is taken for processing.
Default free amount in TRANSACTION.CHARGE is also used as a parameter for
calculating charges. If FT.COMMISSION.TYPE record is attached then Percentage, Default
charge amount, Default minimum amount & Default maximum amount fields cannot be
entered. Otherwise these can be defined with or without details currency wise.

TRANSACTION.CHARGE is not attached through GENERAL.CHARGE, it is attached

through TRANSACTION record in CHARGE.KEY Field.
IMMEDIATE.CHARGE Field in TRANSACTION record is set to NO to enable collecting
these charges along with other Account maintenance general charges , as they cannot
be applied immediately.
System maintains an internal file ACCR.ACCT.TRAN.CH with details of currently accrued
transactions based charges for each account. These details are used at the time of
capitalising the charges . Daily transaction charges are calculated online.
These charges could be selectively collected or waived for a group of accounts or an
individual account through option in GENERAL.CHARGE.


This workshop solution is meant for hands on setting Transaction Charge


The charges applied to an account will vary from different categories of account. Charges
are of two types interest related and ledger fee related .
Interest related charges include DEBIT.INT.ADDON or HIGHEST.DEBIT,
GOVERNMENT.MARGIN and INTEREST.STATEMENT Charge.
The ledger fee related charges can be based on BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT or TURNOVER.CREDIT, NUMBER.OF.DEBIT or TURNOVER.DEBIT,
ACCT.STATEMENT.CHARGE and non immediate TRANSACTION.CHARGE depending on
the Transaction Codes. TRANSACTION.CHARGE is not attached through
GENERAL.CHARGE . It is attached through TRANSACTION record in CHARGE.KEY Field.
All charges are linked through GENERAL.CHARGE . Several such charge tariff structures
may be stored in the file GENERAL.CHARGE. Charges effective on the date of
capitalisation are applicable for the whole of capitalisation period.
A particular GENERAL.CHARGE record could be linked to a GROUP.DEBIT.INT record or to
a single account through ACCOUNT.DEBIT.INT. This brings out the whole picture of
charge structure for accounts.

The GENERAL.CHARGE record applicable to a particular Account is specified in the

relevant GROUP.DEBIT.INTEREST OR ACCOUNT.DEBIT. INTEREST Record. Id can be up to
four digit number and effective date of charges.
Applicable interest related and account maintenance charges are linked though fields in
GENERAL.CHARGE similar to the names of the different charges tables.
Additionally HIGHEST.DEBIT could be collected like account maintenance charges using
HIGHEST.DEBIT.CHG Field.
Interest related charges other than GOVERNMENT.MARGIN can be waived if required , if
they maintain a stipulated minimum or average balance.
Depending on value in INT.CHRG.BAL.TYPE Field the minimum or average balance for
the interest Capitalisation period is used for application of charges. If there is an entry in
INT.CHARGE.CCY Field for the Currency of the Account, then balance as per
INT.CHRG.BAL.TYPE is compared with the balance in the corresponding INT.CHARGE.BAL.
Otherwise, the balance is converted to local currency and compared with the Default
Balance in INT.CHARGE.DEF.BAL Field.

In case of Foreign currency accounts, Account maintenance charges other than

TRANSACTION. CHARGE can be collected or waived by using the option of Yes or No in
CHARGE.OF.FCY.ACCT Field.
CALCUL.STEP.PERIOD Field specifies whether charges in BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT, NUMBER.OF.DEBIT, TURNOVER.CREDIT, TURNOVER.DEBIT,
HIGHEST.DEBIT.CHG and ACCT.STATEMENT.CHARGE should be calculated once to cover
the full charge period, as specified in the Company record, or in monthly steps.
If ‘ monthly' is specified, free, minimum and maximum amounts apply to charges
calculated for each month. Otherwise Free, Minimum and Maximum amounts are only
applied to total charges for the period.
COMB.DEBIT.CREDIT Field specifies whether charges for debit and credit entries
specified in NUMBER.OF.CREDIT or TURNOVER.CREDIT and NUMBER.OF.DEBIT or
TURNOVER.DEBIT should be calculated separately or combined. If 'NO' is specified, debit
and credit charges are calculated separately. Otherwise a combined charge is calculated
using charge details specified in NUMBER.OF.CREDIT or TURNOVER.CREDIT.

It is possible to selectively apply the charges set through TRANSACTION.CHARGE set and
linked through TRANSACTION table. TRANS.CODE.CHARGE Field specifies whether
charges per entry should be calculated using the charge records applicable to each
Transaction code. The field can be used optionally to waive charges on transactions.
If it is proposed to collect charges on transactions, it is possible to combine charges of
respective transactions into one and apply rules. The record Id of
TRANSACTION.CHARGE to be combined is specified .
Then the charges are accumulated into one charge amount and free, minimum and
maximum amounts in the TRANSACTION.CHARGE record specified in
COMB.TRNS.CHRG.CDE Field. Otherwise the charges for each Transaction code is
processed separately using Free, Minimum and Maximum amounts in the individual
Transaction Charge records.
.

WAIVE.CHARGE.NEG.BAL Field specifies whether all charges specified in

BALANCE.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT, TURNOVER.CREDIT,
TURNOVER.DEBIT and STATEMENT.CHARGE Fields should be waived if the Account has a
negative Balance at any time during the calculation period.
If this field contains Y, all charges specified in the fields listed above are waived if the
Balance is negative at any time during the calculation period even if it is only negative
for one day.
If CALCUL. STEP.PERIOD specifies that charges are calculated in monthly steps (M), the
Balances are checked for each month separately and charges waived for that month in
which the Balance is negative.
If CALCUL.STEP. PERIOD specifies that charges are calculated in one step for the whole
period (P) as specified in the Company record, all charges are waived if the Balance is
negative at any time during the whole period.

It is possible to combine all charges except TRANSACTION.CHARGE and apply as single

debit. Depending on CHARGE CODE LEVEL, individual or combined charge amounts are
calculated. CHARGE.CODE.LEVEL Field is set to COM for combining charges and IND for
individual transactions of charges.
LOW.AMT.CHARGE Field specifies the smallest amount of charges specified in
BAL.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT, TURNOVER.CREDIT,
TURNOVER.DEBIT and STATEMENT.CHARGE, which will be booked, for Accounts in the
Currency specified in the corresponding OFFSET.CURRENCY. If calculated charges are
less than this amount, they will be waived.
In the absence of a defined currency, individual or combined charge amounts are
converted to local currency equivalent. If the result is less than the amount specified in
DEF.LOW.AMT.CHARGE, the charge is waived.
Currency wise charges below stipulated amounts or individual charges can be waived.

When Account maintenance charges are combined, it is possible to set rules for waiving
or offsetting. This is achieved depending on the value in the OFFSET.BAL.TYPE Field. The
options available are MINIMUM and AVERAGE. If accounts maintain the balance
indicated charges can be waived.The Average or Minimum balance for the application
period is calculated and converted to local currency equivalent. If the result is not less
than the DEFAULT.MIN.AV.BAL all charges specified in BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT, NUMBER.OF.DEBIT, TURNOVER.CREDIT, TURNOVER.DEBIT and
STATEMENT.CHARGE are waived.
It is also possible to calculate a notional credit interest amount and can be offset against
the calculated charges. DEFAULT.BAL.NO.OFFSET Field specifies the balance (in local
currency equivalent) required before offset interest is calculated for Accounts in
Currencies with no such details.
Details for waiving charges and calculating offsets for Accounts, in specific Currencies
may be specified in the multi value group of associated OFFSET.CURRENCY, MIN.AV.BAL,
DAY.BASIS, BAL.NO.CREDIT and LOW.AMT.CHARGE Fields.
PERCT.FOR.OFFSET Field is used to indicate the rate. DEFAULT. DAY.BASIS or DAY.BASIS
are used to indicate the interest day basis to be used in the calculation.


This workshop solution is meant for hands on setting a General Charge


This workshop solution is meant for amending the Group Debit Interest condition
created earlier and adding a new General Charge created in the previous workshop

We have so far seen parameter tables for setting up rules regarding calculation
and capitalisation of interest and charges. CONDITION.PRIORITY permits us to
decide the order of priority to choose criteria for creating groups for differential
treatment.
Based on the priority criteria chosen in CONDITION.PRIORITY, different actual
groups are created in ACCT.GEN.CONDITION with inclusion of one default group.
Then debit interest rates are indicated through GROUP.DEBIT.INT for groups of
accounts and ACCOUNT.DEBIT.INT for specific accounts. In the similar manner
credit interest rate is specified through GROUP.CREDIT.INT and
ACCOUNT.CREDIT.INT. The capitalisation rules are set up through
GROUP.CAPITALISATION for groups and ACCT.CAPITALISTION for accounts for
both debit and credit interest.
Various type of interest related and ledger fee related charges are set up and
linked to GENERAL.CHARGE. These charges are attached to GROUP. DEBIT.
INTEREST or ACCOUNT.DEBIT.INTEREST for collection from the underlying
accounts.

T24 Account Introduction
Ans a. Conditions based on which groups are going to be

defined are indicated.
b. These conditions are prioritised
Ans: Groups of accounts for differential treatment are created here.
Ans: a. For the groups formed in ACCT.GEN.CONDITION,

capitalisation rules for interest and interest related charges are set here.
b. Id of GROUP.CAPITALISATION is same as ACCT.GEN.CONDITION
97
Ans: 1. Interest, Charges and Statements
Ans: 2. Frequency of capitalisation 2.Separate frequencies for

debit and credit interest capitalisation.
Ans: 3. Level 6%; Band 5.5%.
Ans : 4. Interest related charges
98
Ans: 1. In GROUP.DEBIT.INT, using id of Group Number suffixed with currency code and
effective date, group wise interest conditions are set and the conditions are effective
from the effective date of id.
Ans: 2. Charges are linked to GENERAL.CHARGE. This in turn is linked to group of

Acccounts/individual accounts in GDI/ADI
through Charge key field.
Ans: 3. ACCT.GEN.CONDITION is not used for this. ADI/ACI with account number
effective date as id is used for setting
special conditions at account level.
99
From R13, Transaction Recycler (RC) module introduced captures transaction which
cannot and should not be completed and retry them until they are completed or
abandoned.
Parameter tables can be used to define:
Choice of applications or products from which accounting entries which need to be
captured and stored for recycling
Retry conditions for recycling rules like retry frequency, attempts and more.
Priority for transaction based on application, product and contract (by age and amount)
when we have more than one transaction outstanding against a settlement account
The transaction recycler service routines are triggered by linking it to the conditions for
processing. Details of transactions to recycled are stored in a live table with details of
attempts and conditions and these files can be moved to history.
For transaction recycling in IC, RC.TYPE is to be defined. The recycling condition and type
to be used are given. During each retry the recycler service draws the amount available
in the settlement account for settling the transaction amount in full or partial based on
the configuration.
Transaction cycler would retry the failed transactions of a given settlement account
during Close of Business through the job RC.CYCLER.SERVICE, both during START.OF.DAY
and END.OF.DAY stages. Every failed transaction would be retried both during EOD and
SOD stages and would count to one attempt.
If a transaction is handed over to RC but is settled outside of RC framework, then the
transaction is not considered for further processing by RC and is marked with a specific

status.

On collection of a simple charge, the PL will be credited for the charge. If the customer
account results in an excessive overdraft, with Transaction recycling on, the transaction
is booked to customer account, but the credit entry is placed in a suspense account
(indicated in parameter table discussed in the course later)

With suspense accounting on for the charge collection from the customer, if the
accounts might result in overdue, the charge is placed in CRF suspense instead of PL.
With Recycler setting on, debiting customer account is replaced by debiting suspense
account and crediting PL is replaced by crediting CRF suspense account.

RC.CAPTURE – Defines the accounting entries which need to be captured and stored for
recycling. This table enables Recycling for the module.
RC.TYPE - Defines core and local routines called by the transaction cycler service to
perform transaction specific processing.
RC.CONDITION contains details of the recycling rules, with each record containing details
of a particular set of retry conditions
RC.PRIORITY – Master/Lead company wise records - prioritisation rules are for
sequencing the pending transactions for a given Settlement Account by system id
RC.PRODUCT.PRIORITY EB.SYSTEM.ID wise records - prioritisation within each of the T24
Product Code defined in RC.PRIORITY. Contains the rules regarding which types of
transaction take priority where there is more than one outstanding transaction against a
settlement account. It ranks by product within an EB.SYSTEM.ID
RC.CONTRACT.PRIORITY - to specify the prioritization characterized by the individual
arrangements on which the transactions are pending
RC.DETAIL - holds the information about the transaction that was either captured by the
Recycler or was handed-off to the Recycler by an Application
RC.DETAIL.HIST - After settlement RC.DETAILS.HIST would get updated if
WRITE.TO.HISTORY is set as Yes in RC.CONDITION
For further details on parameterization please refer to the userguide on Transaction
Recycler.

RC.CAPTURE is used to configure conditions/rules based on which a transaction

could be captured for recycling by the central Accounting engine.
The record ID is EB.PRODUCT.ID and has to be enabled for any product ID which needs
Recycler.
This table contains the default RC condition with RC type for handoff from other
applications.
The record id is a valid EB.PRODUCT.ID and optionally could be followed by a lead
company code to define the recycling condition specific to that company.
The Default RC condition and Default RC Type are mandatory fields of the table.
RC.CAPTURE which can be populated with any preferred type and condition record.
Product Category start and end defines particular product types to be captured by the
recycler.
The transaction code specified in the table will be checked against the transaction code
in the accounting entry by the capture routine. If no value is entered here then all
entries for the system id will be captured. Also, the suspense category for storing the
entries can be indicated for this type of transaction
Record ID for Interest and Charges recycling should be respective system ID say IC.

RC.TYPE is the released as part of core and defines the core and local routines called by the
transaction recycler service to perform a transaction specific processing. Provides a link with the
RC.CONDITION table which defines the processing conditions for this type of transaction.
Selection of records for transaction recycling are grouped by settlement account. The records
from RC.DETAIL are selected and grouped.
As a pre-process the settlement account is verified to get the outstanding due amount for each
transaction
The selected transactions are prioritised after verification of details say availability of funds in
settlement account against the due amount of each transaction and order of prioritisation.
The process of retrying each transaction is carried out. When a transaction is failed, the last retry
status is marked as failed.
As a part of
Post process each transaction is selected and status of the processed transaction is updated in
system maintained table RC.DETAIL.
Prioritise: Defines the message specific core routine to be called by the cycler to perform
transaction grouping and sorting - Yes/No
Loc Prioritise: Defines whether a message specific local routine to be called by the cycler to
perform transaction grouping and sorting Yes/No
Pre-Process: Define whether a message specific core routine need to be called to pre-process a
message - Yes/No
Loc Pre Process Define whether a message specific local routine need to be called to pre-process
a message - Yes/No
Post Process:Defines the message specific core routine to be called by the cycler to perform
processing after the transaction has completed Yes/No
Loc Post Process: defines whether a message specific local routine is to called by the cycler to
perform processing after the transaction has completed. Yes/No

The Retry conditions are defined in the table RC.CONDITION. RC.CONDITION contains details of
the recycling rules, with each record containing details of a particular set of retry conditions
Retry Frequency:frequency to retry from the settlement account for an outstanding bill.
Retry Attempts: number of retry attempts to try before giving up, it would be number of days if
frequency is daily. No input if retry period is set
Retry Period: Specifies period for transaction recycler- to terminate the retry processing based
on the date the transaction was added to the recycler. No input if retry attempts is set.
Eg: M0131 end of this month,
M0231 end of next month,
M0215 on the 15th of the next month.
Retention Period: Number of days that the RC.DETAIL record would remain after maturity
before being deleted or moved to history
Write to History: ‘YES’ indicates that the RC.DETAIL record will be written to RC.DETAIL.HIST
after the post maturity period
“NO” or NULL indicates that the detail record will be deleted at the end of the retention period.
Note, The transaction is might or might not be successful after certain retries. If write to history
is no or null, no track of retries are updated/available for further reference.
Txn Type: specify a FT.TXN.TYPE.CONDITION ID to be used by recycler while generating FT

entries to settle a transaction
Retry Option - Only for IC application
PARTIAL – On every retry date, system attempts to settle transactions partially with the funds
available in the settlement account, if sufficient fund is not available to settle it fully.
END.PARTIAL – During final retry date, system attempts to settle the transaction partially with
the funds available in the settlement account, if sufficient fund is not available to settle it fully.

Prioritisation rules for sequencing the pending transactions for a given Settlement Account where we
have multiple transactions pending are defined using:
RC.PRIORITY - Highest level prioritisation parameter. Priority is setup at the company level by system ID
RC.PRODUCT.PRIORITY – The next level of prioritisation within each system ID defined in RC.PRIORITY. The
product wise priority is defined here and is linked to the contract wise priority records.
RC.CONTRACT.PRIORITY – The lowest level of prioritisation to specify the prioritisation characterised by
the individual records on which the transactions are pending. Contains the rules regarding which types of
transaction take priority when there is more than one outstanding transactions against a settlement
account and if multiple transactions (of the same type) with the same due date should be combined and
settled.
RC.PRIORITY :
Contains master company or Lead Company specific records
Highest level prioritisation parameter that allows setup of priority of transactions at company level
This table is used in conjunction with RC.PRODUCT.PRIORITY and RC.CONTRACT.PRIORITY to create the
rules regarding which types of transaction take priority where there is more than one outstanding
transaction against a settlement account. The RC.PRIORITY table is used to rank transactions by system id.
PREV.SETTLE field indicates that if set to Yes, in a retry of ‘n’ bills of an arrangement for settlement, all
bills must be settled. Even if one of them fails, for some reason then none of the bills should be
considered for settlement. Please note that the bills mentioned here can be of different dates.
This means, if an arrangement has three bills (of same or different type) outstanding each of same or
different value dates, system ensures that even if one of the settlement fails, then none of the bills are
considered for settlement.
Product group specific PREV.SETTLE option can be mentioned. This overrides the DEF.PREV.SETTLE option
(the default previous settle option) for the company.

RC.PRODUCT.PRIORITY –This table is used in conjunction with RC.PRIORITY and RC.CONTRACT.PRIORITY to create the
rules regarding which types of transaction take priority where there is more than one outstanding transaction against
a settlement account. The application RC.PRODUCT.PRIORITY is used to rank by product within a module (system id).
The fields PROD.CAT.START, PROD.CAT.END and CONTRACT.PRTY are available for non AA Products only.
RC.CONTRACT.PRIORITY – The lowest level of prioritisation to specify the prioritisation characterised by the individual
transactions are pending. Contains the rules regarding which types of transaction take priority when there is more
than one outstanding transactions) against a settlement account.
DUE.TYPE - This field is a mandatory field and has predefined type of priority conditions. Options are: GROUP.BY ,
SORT.BY.DATE, SORT.BY AMOUNT,
SETTLEMENT.CONDITION, COMBINE.BY
DUE.RULE - This field is a mandatory field and predefined list of preferences for each of the values defined in
DUE.TYPE.
GROUP.BY: DATE; SORT.BY.DATE: OLDEST, NEWEST; SORT.BY.AMOUNT: LARGEST, SMALLEST;
SETTLEMENT.CONDITION:PREVIOUS.MUST.SETTLE; COMBINE.BY: DATE
Combine by with Date is used to Combine multiple transactions (of the same type) with the same due date and settle
them. If the total amount cannot be settled, then none of the dues are settled.
Please note that COMBINED.BY would look for settling ‘n’ transactions which are falling due or having the same value
date but the PREV.SETTLE option of RC.PRIORITY looks at all bills for settlement irrespective of the value dates.
Hence they should not be used together.

RC.DETAIL - Live table stores details of each transaction to be recycled – Record contains
the below items with delimiter as *:
Settlement Account - for multiple settlement accounts this will be the first one
Start Date – When the record was created
Contract.id – The original contract @ID – could be settlement account for non contract
related transactions or arrangement id for arrangements
Contract-detail – bill @id for arrangements, or sequence number for contracts or
eb.system.id for IC
For recycle conditions original values are copied from the retry parameter record to
retain the original settings and work out period end date when the record is created.
Details like retry frequency, attempts, RC.TYPE, retry start and end date, retry amount,
product details, last retry details, entry details, combined details, fatal errors if any,
recovered amount and date, status, remaining amount are stored in RC.DETAIL
RC.DETAIL.HIST is updated only if enabled in RC.CONDITION as write to history as YES.

Note, The transaction is might or might not be successful after certain retries. If write to
history is no or null, no track of retries are updated/available for further reference

From R14, RC has a online retry service, other than regular COB job. A trigger to cycler
service will pick up pending transactions against a settlement whenever certain events
like Credit to the account, Removal of posting restriction or Unblocking of locked funds
from the account happens.
RC.PENDING.TXNS - List file to maintain all the pending transactions (RC.DETAIL ids)
against a settlement account. This file is updated whenever new RC.DETAIL is captured.
Record id : Settlement account number; RC.DETAIL.ID: Valid RC.DETAIL record; The status
of RC.DETAIL should be either 'NEW' or 'CURRENT‘. If the status of the given RC.DETAIL
matches any one of the given statuses "COMPLETED,REJECTED,TERMINATED“. Then that
RC.DETAIL is removed from the list
If all the RC.DETAIL for an account is removed then the entire record against an account
is deleted
RC.RETRY.TRIGGER - Trigger file used by recycler service to process pending transactions
of an account during online
TRIGGER.REF - TerminalNo:”*”:CurrentDate:”*”:CurrentTime
TRIGGER.TYPE - Specifies what has triggered the online retry like – posting of credit
entry, removing posting restrictions, unblocking of funds on the settlement account are
the cases which could trigger a online retry. Holds a valid OVERRIDE record id that is
passed to recycler service and updated in RC.DETAIL record.

RC.CHANGE can be used to cancel or terminate a pending recycler transaction is

required. The account for which status has to be changed has to opened with record id
as settlement account number. Select the desired RC.DETAIL record id. Status of record
can be updated as TERMINATE. Other options are for future usage and not available in
R14.
RC.DETAIL would have the status update with AMEND.BY, AMEND.DATE.TIME,
AMEND.REASON

From R14, It is possible to capture blocked funds on an account into recycler and
subsequently retry with core cycler framework using cycler priority settings
For certain transactions which are captured by recycler for retry, have facility to block
funds for the transaction amount in the settlement account and map it against the
recycler transaction
RC.RETRY - decides if a blocked funds transaction should be captured by RC framework
and retried on pre-defined frequency or not. Note, this fields is n.a. for locked events
triggered from RC.DETAIL records
YES - This block on account would be handed over to RC framework and retried on pre-
defined frequency. No – No retry in RC framework. Null and NO are the same.
BLOCK.PRIORITY - Recycler while processing more than one blocked funds against a
settlement account, would check this filed against the RC.PRIORITY setting and decide
the priority of processing
Entry is valid system ID followed by priortity AC<nnn>, RC<nnn> - valid only if RC.RETRY
is yes
Recollect that, It is also possible to partially settle a captured transaction within cycler
framework
NOTE: P&L reversal and rebooking for any transaction, which is captured into recycler,
would be handled as part of local development and core does not processing to this

RC.CAPTURE:
DEF.BLOCK.FUNDS maintained at the product level to decide if AC.LOCKED.EVENTS
record has to be created, when cycler captures a debit transaction for retry at a later
date
AC.LOCKED.EVENTS would be created for the retry amount with from date as the
transaction date
BLOCK.FUNDS - decide if a failed transaction, which is captured by RC has to create a
AC.LOCKED.EVENTS record if the transaction’s EB.SYSTEM.ID matches with what is
defined in RC.CAPTURE
RC.TYPE:
LOC.CAPTURE.CHK.RTN – If yes, during RC capture processing, system would check if a
routine with name like RC.CAPTURE.CHK.<RC.TYPE.ID>.LOC exists in the system. If exists,
then, call that routine to decide if the transaction is eligible for capture or not. If this
returns CAPTURE.FLAG=FALSE, then, this would override core’s capture flag and the
transaction should not be captured. If no, local capture routine will be called.
PRTY.SORT – If YES, core RC priority routine would check if a routine with name like
RC.PRTY.SORT<rcTypeID> is available and call that with a list of RC.DETAIL IDs and
records, which are already sorted by core recycler. When set to NO or null, application
level prioritisation would not be possible
LOC.PRTY.SORT - decide if a local routine can change the prioritisation order of a list of
pending transactions against a settlement account
RC.CONDITION –

START.DT.OPTION - to specify a relative date or a specific day of a month. Used to offset

the START.DATE of the retry process with base date as capture date.
DATE.CONVENTION- decide if a rc date (start, end or next retry date) falls on a holiday,
what should the system do, either move the date to next or previous working date. Valid
values are FORWARD or BACKWARD. Default value is FORWARD


T24 Account Group Parameters R16 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T24 Account Group Parameters R16 PDF

Uploaded by

Copyright:

Available Formats

T24 Account Group Parameters R16.

T24 Accounts R16.1 1

T24 Accounts R16.1 2

T24 Accounts R16.1 3

T24 Accounts R16.1 4

T24 Accounts R16.1 5

T24 Accounts R16.1 6

T24 Accounts R16.1 7

Statement related tables are AC.STMT.PARAMETER, CONDITION.PRIORITY and

T24 Accounts R16.1 8

T24 Accounts R16.1 9

It is possible to set preferential service conditions for maintenance and servicing of

T24 Accounts R16.1 10

It is possible to control the statement entries appearing in the customer statement.

T24 Accounts R16.1 11

T24 Accounts R16.1 12

T24 Accounts R16.1 13

T24 Accounts R16.1 14

CONDITION.PRIORITY table with Id as ACCOUNT is used to specify data elements

CONDITION.PRIORITY table is used to define criteria like nationality, industry ,

T24 Accounts R16.1 15

T24 Accounts R16.1 16

T24 Accounts R16.1 17

T24 Accounts R16.1 18

T24 Accounts R16.1 19

T24 Accounts R16.1 20

Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is dependent on the

T24 Accounts R16.1 21

T24 Accounts R16.1 22

This workshop solution is meant to have hands on setting a new Category

T24 Accounts R16.1 23

T24 Accounts R16.1 24

T24 Accounts R16.1 25

T24 Accounts R16.1 26

T24 Accounts R16.1 27

T24 Accounts R16.1 28

T24 Accounts R16.1 29

T24 Accounts R16.1 30

T24 Accounts R16.1 31

Purpose of GROUP.CAPITALISATION table is to specify the next capitalisation date and

T24 Accounts R16.1 32

T24 Accounts R16.1 33

T24 Accounts R16.1 34

T24 Accounts R16.1 35

T24 Accounts R16.1 36

TAX.KEY Field hold ids of Tax records (defined in TAX table) or

T24 Accounts R16.1 37

INTEREST.DAY.BASIS gets its default value from respective CURRENCY table . If it is to

T24 Accounts R16.1 38

T24 Accounts R16.1 39

If a minimum amount of interest is to be collected from an account, then it is specified

T24 Accounts R16.1 40

balance under USD 50,000 .

T24 Accounts R16.1 40

T24 Accounts R16.1 41

T24 Accounts R16.1 42

T24 Accounts R16.1 43

T24 Accounts R16.1 44

T24 Accounts R16.1 45

T24 Accounts R16.1 46

T24 Accounts R16.1 47

T24 Accounts R16.1 48

Minimum balance in account for interest calculation can be specified in