T24 - Financial Reporting - R9

1T3TRE - Financial Reporting - R9.1

T3TRE - Financial Reporting - R9.1 2

The objective of this course is to equip participants learn about different tools and techniques used for designing and generating reports. In this process participants are introduced to a Model Bank Report. Later on we will see Reporting Tools like Header, Column and Line important for creation of tables. We will also see some important functionalities with regard to Report Specifications. Finally, we will see the process of Generation of various Reports and the linkage of Reports with other tables alongwith printing of Reports.



In Financial Accounting course, you have learnt how various types of accounting entries are generated and how they are consolidated into CAL and CPL records. You will, in this course, learn about the different tools and techniques used for generating reports using the data available in CAL and CPL records.


In T24, a report is built like a traditional house.To build a house, first we build a strong foundation, upon which we build the Columns, then the Roof and finally the Walls. Of course, we build the house depending upon the requirements and specifications.Extending this analogy, for a T24 financial report, the foundation or the primary source of information is the CRF (Central Reporting File), which as you know comprises the two consolidation tables CAL and CPL (CONSOLIDATE.ASST.LIAB and CONSOLIDATE.PRFT.LOSS). A T24 financial report is like any other report, a two dimensional array of columns and rows. In T24, we refer to the rows as lines. Similar to building a house, to design a T24 financial report, you have to first design its Columns and Lines. The Columns are the type of information to be reported across a report column. In T24, once you design a column, you can use it across any report. It could represent an opening balance, a closing balance, total credit transactions, total, etc.Finally, the Lines decide which information is reported in a row. For example, in the first row, you may decide to report deposits and in the second row the loans.


You will now see some of the financial reports generated in T24 to learn their important design components. Various types of reports can be produced from T24 Central Reporting File (CRF) balances. The screenshot shows the specimen of a report produced.This report shows the Closing Balances under different groupings like Cash, Due from Banks, etc. Above the Line 0030 CASH, you can see individual CAL keys listed with balances. Such a report which reports CAL keys and information from them, are known as CRF reports.If you further analyse the report, you can see that it has three Columns and multiple Lines. The first column holds sequence Nos. and the second column is the description of Lines. You can see that they do not hold any financial information, and thus we will refer to them as “Descriptive Columns”. While the third one, which reports financial amounts will be referred to as a “Financial Column”. If you look at the first and second Lines, there is no amount under the financial column, and we will refer to such Lines as “Heading” Lines. You can see that in the Line 0030 Cash Balance, there is an amount, and we will refer to it as a “Detail” Line. Finally, you can see that in the TOTAL CASH Line, though there is a financial amount, no keys are listed above that. Why? Because, it is not reported from CAL keys, but a calculated total is printed here. We will refer to such Lines as “Total” Lines. To recap, CRF reports contain amounts only from CRF i.e. CAL and CPL tables. A report comprises of some descriptive and some financial columns. Similarly some Lines are just Headings, some report financial amounts and some just report totals.


If you compare this report, with the previous one, you can see that this report gives the details of individual cash account balances under the row Cash Balance. For instance, details like Customer, Account Number, Interest rate, Interest Day basis, Value date etc. which are fetched from T24 Balance files/Applications like Accounts and Contracts. Such a report, which gives the balances of individual accounts and contracts under a consolidation key, is referred to as a CRB report. CRB reports are also based on the CRF base i.e. CAL and CPL tables, and in addition they report the balances of underlying contracts and accounts.



We have two broad types of reports which can be designed in T24.The first one is a report with closing balances. This report will give information of closing balances of accounts, contracts and profit and loss headings. Note that such a report pertaining to Assets and Liabilities report is shown here with one columns, showing the day’s closing figures.The second type of a report is one showing movements. This report will give information on opening balance, debit and credit movements and closing balance for a day. In short, it will display intra-day movements. Example of such report is a Profit and Loss report with opening balance, debit movements, credit movements and closing balance for a day. The CAL and CPL records are designed to hold intra day movements. The CAL records hold the closing balance not as one figure, but as a maturity date-wise schedule. For example, a T24 Bank has given two loans on 3rd of January, 2008, the first one maturing on 10th June and second one on 15th June, same year. All consolidation conditions are same for the two loans. On 3rd of January, when these two loans are consolidated under the same console key, the closing balances of the two balances will be shown under different maturity dates.


Now, what are the tools required for Reporting?The first step is to create desired columns that would be used in any report. Different types of columns are built using RE.STAT.COLUMN.TYPE application. The standard abbreviation for this is COLUMN.The next step is to design a particular report. A suitable heading for a report and choosing the columns that are required in the report is done through RE.STAT.REPORT.HEAD application. The standard abbreviation for this is HEAD.Then designing each row or line of the report can be done through RE.STAT.REP.LINE application. The standard abbreviation for this is LINE.


The Header of a report is designed using the application RE.STAT.REPORT.HEAD. In this case, the report name MBGL is specified as the Id in RE.STAT.REPORT.HEAD. The HEADING given will be printed on each page as the title of the report. Observe the screenshots to get the links.As we discussed earlier, you can see that the first 2 columns are descriptive columns, which do not report any financial amounts. In a T24 report, there could be a maximum of 3 descriptive columns. This report has not opted for the 3rd

descriptive column. The descriptive column headings and their size are indicated by multi valuing fields LINE.NARR.SIZE and NARR.HD. The first descriptive column will have 6 characters and the second 35 characters. The underlining that is required under narrations has also been duly defined. Look at the set of fields from LINE.NARR.SIZE.1 to NARR.HD.2.2.1.Please remember that what is to be printed under each descriptive column will be designed using the LINE application and not in the HEAD.You can see that COLUMN.TYPE: CLOSBAL is inserted in the Report, which will print the amounts in the first financial column.You can also observe that this report is designed to show the figures in full and not in thousands or millions.

Here, we will design the financial columns. In this instance, the financial column chosen is named CLOSBAL in the application RE.STAT.COLUMN.TYPE. It is advisable to follow standard naming method, so that the users can easily choose the requisite column without going deeper to find out how it has been defined.The GROUP Field makes a high-level distinction whether the report is a “Closing” type or a “Movement” type. We have discussed earlier the difference between reports which contain only closing balances, and those which contain intra-day movements. This Column has been designed to show only Closing Balances. See the field GROUP in the COLUMN record.The fields TYPE.1 to TYPE.4 define as to what type of data will be reported in a Column. The TYPE.1 Field decides whether the report can allow Assets and Liabilities as well as Profit and Loss items under it. Further this Column has been designed to report the Net of debit and credit balances, local as well as local currency equivalent of foreign currency. (See the fields TYPE.2 and TYPE.3.1 of the COLUMN record).Further, the Column heading and underlining have also been defined here. See set of fields LINE.1.FULL to LINE.2.MILL. They convey how the heading should appear in a report displaying the full amount and in reports displaying the amounts only as thousands and millions. Finally, the Column has been attached to the HEAD record in COLUMN.TYPE Field.

The Id of the LINE record is MBGL.Line number (of four digits). The Line Number in the Id represents the order of printing the rows or lines of a Report. You can also understand that the first component of the Id is the Id of the HEAD record, thus a LINE record is always dependent on a Report, unlike COLUMN records which are independent of the Reports. Line 20 has been defined as Heading line and the contents of the report’s two description columns are defined. The links shown should help you understand better. A Heading Line will not report any values under financial columns.Lines 30 and 40 have been defined as Detail lines, which means in addition to the content of the Descriptive columns, they will have the parameters to select CAL and CPL keys to report their amounts in the various financial columns of the Report. You can see that the two lines are accumulated with accumulator of 1. That means their financial column amounts will be summed up, accumulated and reported.You can see that the Line No.100 is a Total Line and the accumulated amount “1” are printed. Thus, a Total Line will just print the accumulated totals. 6 You can also see that in the Total Line, it is accumulated further as “2”. This means, this will be a sub-total which will be accumulated and printed in a further total line.


This diagram maps out the flow for creating financial reports. You can see, the financial data resulting from transactions, have been consolidated by the system according to the consolidation criterion defined in CONSOLIDATE.COND. The T24 concept does not have General Ledger accounts, but the selection criterion of CONSOLIDATE.COND enable us also to create reports, respectively lines. The consolidated records are stored in CAL and CPL tables.You have learnt, before creating Lines, we need to create the Columns and then the Header. More about all this will be dealt in the coming units.



Different types of financial columns to accommodate different needs can be designed in the application RE.STAT.COLUMN.TYPE.Columns once designed, can be used in any number of reports. i.e. Columns are independent of Reports.Columns are broadly defined as Movement group and Closing group columns. While a Closing group column can report only Closing Balances, a Movement group Column can report intra-day movements. In any report, while more than one financial column could be used, all the columns used should belong to either a movement group or a closing group. i.e. You cannot include Columns of different groups in one Report.


The TYPE fields are used to define the various attributes of a Column. There are four type fields TYPE.1 to TYPE.4. In a Movement Group Column, only TYPE.2 is allowed and it is mandatory. A Movement group column (see TYPE.2 Field) can be defined to display one of the following: (i) Opening Balance – reports the opening balance (ii) Debits – provides the debit movements (iii) Credits – provides the credit movements (iv) Net – provides the net of credit and debit movements(v) Shutting (Closing) – gives the closing balance. Thus, you can see that even though a Report may be containing only Movement Type Columns, it is possible to report the Closing balances, and thus the restriction to mix Movement and Closing type Columns in a Report, is not really a design constraint.(vi) Equivalent – gives the local equivalent of closing balance. You might be wondering about other Movement group columns, in which currency they would report their amounts? You cannot parameterise the Currency of reporting for a Movement group Column. We have a functionality known as Splitting a Report into different Sections Currency-wise, which we will discuss later. A Movement group Column (Other than Equivalent Type) will always report as per the Currency of a Section. In this case, an Equivalent type Column will be useful to report the LCY equivalent of closing balances.


If a CPL key has BALANCE: -15000, DEBIT.MOVEMENT: -14000, CREDIT.MOVEMENT: 11000, BALANCE.YTD: -10000, then Opening Type column will report: -25000 (BALANCE+BALANCE.YTD), Shutting type column will report: -28000 (Opening+Debit+Credit Movements).


The other type of column is the ‘Closing’ type. This column displays only the closing balances of a CAL/CPL key. The Closing balances can be split across various Columns, by defining Columns with different attributes. In case of Closing Type Columns, the TYPE.1 to TYPE.3 Fields are mandatory, while TYPE.4 Field is optional. The TYPE.1 Field represents the type of amount to be reported in the Column. It has the following options:1. Asset/Liability – Closing balance of only CAL items 2. BOTH – Closing balance of both CAL and CPL items3. PLYTD – PLYTD balance of CPL items (closing balance till previous month end)4. PLCM – Current month balance of only CPL items5. Profit/Loss – Closing balance (PLYTD+PLCM) of only CPL items, reporting current closing balance.The screenshot shows Closing balances of only Profit and Loss as on a particular date.


In case of a Closing Group Column, TYPE.2 Field is useful to specify the sign of the Balances to be reported. It has options to report only Debit figures, Credit figures, or to net Debit and Credit figures. For example, in a Report, the columns COL1, COL2 and COL3 are specified as Closing type columns with TYPE.2 Field specified respectively as DEBIT, CREDIT and NET. Then the amount of Asset types FXFWDSELL:50000, FXFWDSELLBL: -50000 would be reported under COL1: -50000, COL2: 50000 and COL3:0.


TYPE 3 Field(Currency Options)All – All currency transactions in Local equivalent. Local – Local currency transactions only.Foreign – Local currency equivalent of Foreign currency transactions only.Currency – Foreign currency amounts for Asset & Liab only.Profit.Currency – Foreign currency amounts for P&L only.*CCY – Local currency equivalent of a specific currency.


TYPE 3 Field (Currency Options)All – All currency transactions in Local equivalent. Local – Local currency transactions only.Foreign – Local currency equivalent of Foreign currency transactions only.Currency – Foreign currency amounts for Asset & Liab only.Profit.Currency – Foreign currency amounts for P&L only.*CCY – Local currency equivalent of a specific currency.


Values can be ranged for use in a Column. The values that could be ranged are any parameter on the CONSOLIDATE.COND and Asset Type. Separate set of ‘Include’ and ‘Exclude’ values could be defined on this table. For example Euro transactions and non-Euro transactions are to be reported on two different columns. The Euro currencies can be ranged up (specify all Euro currencies in the include range) and the other column-range could be defined to either exclude the Euro currencies or include other than Euro currencies.


For a Closing Group Column, the input in TYPE.4 Field is optional. This feature can be used to split the balances across different Columns, based on criteria not possible through TYPE.1, TYPE.2 or TYPE.3. Here you can attach an Id of a RE.STAT.COLUMN.RANGE record, which in turn has a range of values specified, based on any consolidation parameter specified in CONSOLIDATE.COND. Values can be chosen for inclusion or exclusion in RE.STAT.COLUMN.RANGE.For example, imagine three different records in RE.STAT.COLUMN.RANGE as shown in the screenshots. The user has specified the inclusion criteria in two records and the exclusion criteria in the third record based on the consolidation parameter RESIDENCE.The Ids when attached to TYPE.4 field in 3 different COLUMN records, will refer to the ranges in the relevant records for classifying the CAL/CPL records and to report the closing balances.


For closing group column 4 different types are available. Constructing a closing type of column throws in much more options. TYPE 1 Field can be used to indicate whether this column should permit only Assets and Liability figure or Profit and Loss figure of both under the same column or only Profit and Loss of current month or Profit and Loss from year beginning to month beginning.TYPE 2 Field permits limited options. While this column by nature will pick out only the closing figures, should it allow only Debit figures or Credit figures or both (Net) are the choices available.TYPE 3 Field is used to indicate currency splits in columns. All currencies to appear in the same column or only local currency equivalent or foreign currency or for profit and loss reports the currency of profit or as per currency code.TYPE 4 Field is used to link a pre-defined range of values for this column.Here, 3 types are mandatory and the fourth one (range) is optional.


The Id is the column name, the name is free but should be self-explanatory.Type 1, 3 and 4 are not available for movement group.


For any financial Column, the column heading to appear on the top of the column can be specified in the fields LINE.1.FULL.1 to LINE.2.MILL.1.In fact, you can specify different Column Headings, depending on how the amounts will be reported, say in full, thousands or millions. How the amounts will be reported itself is controlled by a field in HEAD.









Any report has some common design attributes.Using RE.STAT.REPORT.HEAD (Abbreviation: HEAD), you can define the attributes that apply at a Report level like title, financial columns, the Units for reporting, etc. To begin with, you have to define a Title and a description of the report.Then, you have to define the Columns for the Report. Up to 3 columns can be used for general description. These are user definable and not linked to the columns defined in RE.STAT.COLUMN.TYPE. After the descriptive columns, financial columns should be defined. These columns should have been pre defined in RE.STAT.COLUMN.TYPE. In addition, you can specify in the HEAD record, your own columns for totals and other calculations like variance in percentage between opening balance and closing balance.


The Header gives an outline or shape for a report.We can opt for section wise split for currencies. ALL option produces one section containing local currency and equivalent of foreign currencies. Useful for General ledger type of reports.CURRENCY option produces one section per currency including local currency. Useful for foreign currency control ledgers.LOCAL option produces one section containing local currency only. Useful for local currency control ledgers. BY.FOREIGN option produces one section per currency without local currency. TOTAL.FOREIGN option produces one section containing the equivalent of foreign currencies only.Further, we can also control whether profit and loss information should be shown in the currency we earned or only as local currency equivalent.


You have seen earlier that a Column is independent of any Report; however, Lines or row definitions depend on Reports. It is possible to obtain different reports having the same line contents, but having different columns.This means, if we choose the closing group columns for the first report and the movement group columns for the second report, and if we retain the Line design to be same for both the reports, we will get reports with different layout but Line content being same. For instance, we can have a report GLSTD with closing group columns and another report GLSTD.MVMT with movement group columns. It would suffice if Lines were defined only for GLSTD report. GLSTD.MVMT report would pick the same line information, but present it in the columns defined for GLSTD.MVMT.Id for the main report can be up to 10 Alphanumeric characters. Id for the second report can then have up to 10 additional characters, separated from the first part by a ‘.’ You have to first create and authorise the HEAD record for the first Report, say GLSTD. Then you can create another HEAD record for the second report, say with ID:GLSTD.MVMT. In this case, you will be defining the Lines only for the first report GLSTD.


A brief note about the report contents can be defined in the field DESCRIPTION, while the Title of the report can be defined in the field HEADING.The LINE.NARR.SIZE field defines the Size (width) of a Descriptive Column. It can be multi-valued maximum three times to define three Descriptive Columns of a Report.There could be a maximum of two Lines of Heading for a Descriptive Column, which you can specify in the fields GB.NARR.HD.1 and GB.NARR.HD.2. In this example, we have only created two descriptive columns, and you can see how the report title and descriptive column headings appear in the Report.


In a multi-currency system, Banks would like to split their financial reports currency-wise. It is possible to opt for section wise split of currencies through the field SPLIT in RE.STAT.REPORT.HEAD.ALL option produces one section containing local currency and equivalent of foreign currencies. This is useful for General ledger type of reports.CURRENCY option produces one section per currency including local currency. This is useful for foreign currency control ledgers.LOCAL option produces only one section containing local currency only. Useful for local currency control ledgers. BY.FOREIGN option produces one section per currency without local currency. TOTAL.FOREIGN option produces one section containing the equivalent of foreign currencies only.


It is very important to define properly the content of this field according to the nature of the report that the user wants to produce. The following examples will clarify the use of this field: For production of a General Ledger report, the user will probably define 'ALL' in this field. For production of a General Ledger report containing the local currency equivalent amount of foreign currencies, you will have to define “TOTAL.FOREIGN” in this field.


For production of report on AL positions of various currencies, the user may define ‘CURRENCY‘ or ‘BY FOREIGN’ in this field. Like this, for production of FCCL report, the user may define ‘BY.FOREIGN' in this field together with columns of a TYPE 3 equal to 'CURRENCY'. For production of LCCL report, the user will probably define 'LOCAL' in this field. Let us also understand the linkages this field might have with TYPE.2 and TYPE.3 Fields of a COLUMN.For example, if there are 10 Lines (rows) for a Report, if you choose CURRENCY option, in a Bank which has Assets and Liabilities in five currencies, the report will have five sections, one for each Currency. Each section will report the 10 Lines, with amounts in respective currencies.If your report is a Movement type report, then the amounts will be reported in respective currencies of the split Sections. In this case, you may also use a Column with TYPE.2=EQUIVALENT, to report the closing balances in local currency equivalents.In case your report is a Closing type report, then you may define two columns one with TYPE.3=CURRENCY to report the balances in the Currency of the Split, and the other with TYPE.3=ALL to report the balances in local currency equivalent.

All profit and loss transactions, although 'booked' in local currency, contain the original source currency and amount. When they are consolidated in CPL records, both the original source currency amount and local currency amounts are stored. It is therefore possible to show the source currency as well as local currency instead of showing local currency alone in any report.The PROFIT field of HEAD can be used to tell how to split the P&L items in a report. It takes either a value of LOCAL or CURRENCY. LOCAL value selection will imply accumulation in local currency.CURRENCY value selection will split a report P&L items currency-wise it was earned or incurred.Be careful to properly define the combination of SPLIT and PROFIT values. Note that, SPLIT field should not be ALL when CURRENCY option is used for PROFIT.


There are various options available in AMOUNT.UNITS Field to print the amounts in the reports.ALL represents Full amounts including decimal places UNITS represents Full amounts but excluding decimal places HUNDREDS shown as decimal places of thousands THOUSANDS shown in Thousands but excluding decimal places PART.MILLIONS shown as decimal places of millions MILLIONS shown in Millions but excluding decimal placesDefault value is ALL.Earlier, when we discussed about Columns, we have discussed how you can define different headings for a financial column, depending on how the amounts are represented in a Report.As per the choice here, the column heading can be different as defined in RE.STAT.COLUMN.TYPE for different amounts. RE.AMT.ABBREV contains the narrative to be printed on top of the reports to describe these amounts – In full, In thousands etc.


Now, assume there may not be values for a Line in a report, that is, the amount is nil across various columns of a Line. The bank may want to suppress such lines appearing in a report. This is done by setting the ZERO.SUPP.DET Field to YES.Like this, it is also possible to suppress all the “total” lines having zero values using the ZERO.SUPP.TOT Field. If you want to selectively suppress only certain groups of zero lines, and not all, that is also possible.SUPP.GROUP Field specifies the groups of lines that are to be suppressed in the report, in case the line contains only zeros.To use this functionality, you have to specify Suppression Group value at the Line definition level. For example, you can define a Suppression value of 1 in the Line 100 of a Report, and if you attach this Suppression Group value in the Head, this line will not be printed, when it has no values. You can set Suppression Group values from 1 to 9. If you wish to suppress Lines with non-zero values, then use the Suppression group values NP1 to NP9 in both the LINE and HEAD definitions.


The financial Columns which have been defined in the table RE.STAT.COLUMN.TYPE can be attached to the field COLUMN.TYPE or alternately, value in this field can be given as a 'TOTAL' column, or as a 'CALC' column. Any number of pre-defined columns in RE.STAT.COLUMN.TYPE can be used, provided they all belong to either Movement group or Closing group. Financial columns cannot be duplicated within a same report.The “TOTAL” and “CALC” Columns are both dynamically calculated when the Report is generated, from the values of other Columns. While a “TOTAL” column can only add or subtract amounts of other Columns, a “CALC” column can report even Multiplication and Division of other column values. For both types of Columns, you have to specify the type of operation in TOTAL.PARAM, the names of operated Columns in TOTAL.COLUMN, operated Constants in TOT.CONSTANT, and the Column Heading in GB.HEAD.1 and GB.HEAD.2.In case of a “CALC” column, in addition, you have to specify the INTEGER.SIZE and DECIMAL.SIZE to set the size of the calculated column. Further, you can set the ABS.VALUE to Y to report negative figures as positive ones, in case of a calculated column.In the screen-shot here, you can see how a calculated Column has been defined in a Report to print the variance percentage of the daily balance.



In the screen-shot here, you can see how a calculated Column has been defined in a Report to print the variance percentage of the daily balance.


In continuation to the previous page, here, you can see how the Total and Calculated columns are printed, with the Headings as defined in the RE.STAT.REPORT.HEAD.When you are defining multiple CALC columns in a Report, then you can define the intermediate calculations in the multi-value fields MNE.NAME, MNE.PARAM, MNE.COLUMN and MNE.CONSTANT. Once defined, they should be used at least once in a report. The MNE.NAME Field value could be entered in TOTAL.COLUMN Field instead of entering a standard Financial column name.


In a Movement Type report, it is possible to report details from underlying Accounting entries. The field values to be printed from the accounting entries, the print position, etc. can be defined in the application RE.STAT.ENT.FORMAT, whose record Id has to be attached in ENTRY.FORMAT.ID Field of HEAD.You will learn more about RE.STAT.ENT.FORMAT in the next page.


RE.STAT.ENT.FORMAT contains details about the presentation and format of 'entries' to be included in a report.In addition to the type of Amount to be printed, for each type of entry (STMT.ENTRY, CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY), the user can specify which details of the entry (transaction reference, etc.) need to be printed on the report. AMOUNT Field specifies which amount need to be printed from underlying entries and could have the following values:LCY.CREDIT means Local currency and local currency equivalent Credit amount.LCY.DEBIT means Local currency and local currency equivalent Debit amount.LOCAL means local currency and local currency equivalent of both Credit and Debit amounts.CCY.CREDIT means Foreign currency credit amount.CCY.DEBIT means Foreign currency debit amount.CURRENCY means Foreign currency amount (includes both credits and debits).The screenshot conveys, the user has specified Local currency and local currency equivalent debit amount has to be reported in Column 73. Further, the Field 26 of STMT.ENTRY must be printed in the Print Column 1 with a width of 13 characters.


Based on the values set in RE.STAT.ENT.FORMAT, this is how the details from accounting entries will appear on the report.Heading is taken from the description given in HDR.1 Field and details are fetched from particulars available from the accounting entries.

Reports can be produced indicating residual maturity, as CAL keys hold balances maturity date-wise.The last working day of the month and the last calendar day of the month could be different due to holidays - say 28th of the month is the last working day because 29th

and 30th are holidays. The time bands could be calculated based on either the last working day or the last day of the month. If MAT.TO.MONTH.END Field is set to Yes, the last working day is stretched to the last day of the month and monthly bands give month end dates. If set to No, time bands are calculated from last working day.


Similar to MAT.TO.MONTH.END Field, MAT.INCLUSIVE Field indicates whether deals maturing on the last day of a time band should be reported within that band or in the next. For example, a Loan contract is maturing on 31st December, 2008. A report is taken on 28th to show deals maturing before next 3 days.Since the contract matures on the last day of the band, if this field is set to yes then the loan is shown in the report within the time band. If set to No, it will be included in the second time period.


Values for an amount can be negative. How can such an amount be reported?The format for showing negative amounts is available in NEG.AMT.FORMAT FieldThe negative amount -123.12 will be expressed as follows for the following options:E, as <123.12>, with the amount in bracketsM 123.12- with a trailing negative signB as 123.12db with db suffixedN as 123.12 converted into a positive figureNull as -123.12 in the default format


It is possible to store the Line balances of a report, for future reference as well as for enquiry purposes. MAINTAIN.BALANCES Field specifies whether line balances are to be recorded for this report. The option 'DETAIL' - denotes that details of individual movements behind the line will be kept. In this case, the Ids of Accounting entries related to that Line movement will be stored. 'SUMMARY' - denotes that only the summary of line level movements and balances will be kept. Accordingly, line balances and Ids of accounting entries are recorded in the RE.STAT.LINE.BAL & RE.STAT.LINE.MVMT tables. NONE indicates that no balances will be recorded. The number of months for which the data of last financial year in the RE.STAT.LINE.BAL & RE.STAT.LINE.MVMT tables are to be maintained can be mentioned in the field DETAIL.MONTHS.








RE.STAT.REP.LINE is the application used to design a Financial Report’s Lines or rows, by setting how the amounts of CAL/CPL keys will be reported in different lines. It selects the Consolidation keys, within them the Asset Types, etc., and their amount will be reported in a row. Within a consolidation key, there could be several amount fields. The Column definition splits these amounts across different Columns in the Report. T24 has provision for creating a maximum of 9999 lines in each report.Note the Id in the screenshot. The line Id is formed by two elements separated by a dot. This is HEAD Id. Line Number, for example, GLSHORT.0100 to represent Line No. 0100 of the Report with Id: GLSHORT. The Line No. tells T24 the relative position of a Line in a Report.It is recommended to create a short Id for the HEAD records and number the lines

starting from 10 with a gap of 10, so that there is space to insert new lines in future. Lines created for one report cannot be used in other reports. However, as you have learnt earlier, if a Report is constructed based on another report, for example, GLSHORT and GLSHORT.MVMT, then both will share the Lines defined for GLSHORT. A line can be referred by mnemonic as well. This is taken care by MNEMONIC Field. The value here should be unique and 3 – 10 upper case alphanumeric characters.



Types of line can be Heading, Detail or Total. In the report details given in the slide, 0020 Cash gives line type Heading. Like that line number 0030 is a detail line and line number 0090 is Total line. Line Description can be in maximum of 3 columns. Upto 9 accumulators can be used in a report. Accumulator is one identifying similar balances to be consolidated. Here line balance 30 and 31 can have same accumulator for instance 1. Once balances 30 and 31 are totalled and ready for printing in report , the accumulator gets released and is available for another consolidation of individual line balances.Maturity split handles the residual maturity which is maturity date minus today. Contracts maturing on various time slabs could be printed on different lines based on residual maturity. Netting Of Assets is a facility to report Asset and Liability in different lines according to sign. Instead of defining the details in two different lines, it is possible to define details in one line and indicate where the opposite sign should automatically go through ASSET.SIGN and ASSET.OPP.LINE Fields.

Profit Period is facility to report in different lines the result of a Profit & Loss data according to the period say CM(Current Month only )in one line,

YTD (upto previous Month) in one line and ALL ( Closing balance as of date (CM + YTD)) in third line without split.

Types of line can be Heading, Detail or Total. In the report you are seeing here, the Line with No. 0020 is a Heading Line, which just reports a Heading without any financial amounts. Similarly, line number 0030 is a detail line and line number 0090 is a Total line. As you have learnt earlier under Head, a Line Description can be given in a maximum of three columns. The field TYPE will classify a Line as a Heading, Detail or Total Line.If chosen as Heading, it is used to define headings like ASSETS and sub-headings like LOANS & ADVANCES, etc.Detail line is to return financial values from CAL key and CPL keys. It is mandatory that CAL/CPL keys have to be picked for detail lines. Total Line is used to define ‘Totals’ and ‘Sub-Totals’ for the detail lines.


Up to nine accumulators can be simultaneously used in a report. An Accumulator is a counter used to accumulate total balances for reporting later.Here the Lines 30 and 31 can have same accumulator for instance 1. Once the balances of Lines 30 and 31 are totalled and reported, the accumulator will be released and can be reused for accumulation of other line balances.You now know that, Total line refers to total / sub-total of the detail line(s). It is possible to accumulate balances of lines, be it Detail line or Total line, through TOTAL.ACCUM Field, which can be given a numerical value from 1 to 9. The accumulated totals can be printed on a Total line through TOTAL.PRINT Field, which can be given value from 1 to 9. If TOTAL.PRINT Field is specified as 1, then the total of all the previous lines with TOTAL.ACCUM Field defined as 1 will be totalled and printed here.Once the total of an accumulator is printed, , its value will be set to 0 and it will be ready to be used as an accumulator for accumulating balances of a different group of detail lines.Accumulators of 1 to 9 can be simultaneously used in a report to print totals of Lines at multiple levels.


Sub-total lines can be further accumulated using TOTAL.ACCUM field in those Total lines and printed as Grand Total using TOTAL.PRINT Field in another Total line.The TOTAL.ACCUM Field is a multi value field. This enables line in one accumulator to be totalled to different accumulator covering a group of lines.



Have a look at all the line records created. Find out the DETAIL records having TOTAL.ACCUM field as value 1. The total of such details will be printed at the line No.0100 as Total Liquidities. This is done through the field TOTAL.PRINT of 1 in line No.0100.The total of Line No.0100 will be treated as sub-total, as TOTAL.ACCUM Field of this line is specified as 2. Along with all the lines with TOTAL.ACCUM Field of 2, this will be carried forward to another Sub-total / Grand Total.Sub-total lines can be further accumulated using TOTAL.ACCUM Field in those Total lines and printed as Grand Total using TOTAL.PRINT Field in another Total line.

We will now see some Line layout options.Spaces can be included before and after a line. SPACE.BEFORE Field is to indicate number of blank lines to leave before a Line. SPACE.AFTER Field is to indicate number of blank lines to leave after a Line. The value NEW in this field will indicate that the line is to be printed in a new page. Lines, which do not return any financial data, can be excluded to reduce the size of the report (These lines will be shown when a value is returned in them). SUPPRESSION is a field, which suppresses line details with zero values or Numeric values. This can be set with a value Y, 1 to 9 or NP1 to NP9. Y is to suppress lines with zero values. No is not to suppress. The numeric value from 1 to 9 is to suppress Lines with zero values, while NP1 to NP9 is to suppress Lines with non-zero values. For the SUPPRESSION Field functionality to work, it is necessary that the SUPPRESSION Field group values are also specified in the SUPPRESSION Field of the HEAD record related to the Lines. In case SUPPRESSION Field holds value of Y for a Heading Line, the Heading Line will not be printed if no detail or total Line is printed, before the next Heading Line.


Normally, balances of a Consolidation Key will appear only once in a report. A Bank may require the details of a Line again to be repeated in another section of the report. To enable this, ASSET.EXT.DUP field is used. To mark that a Line details will be duplicated in another Line, this field has to be set with a value of Y. Further, in a Trial Balance type of report, it is necessary to report all Balances from all CAL record. The definition of Lines of a Report may not cover all the CAL record balances. In such a case, we can define default Lines to report Balances of CAL records, not reported anywhere else in the Report. In this case, the ASSET.EX.DUP Field will have the following values:DEF – Used for Both default contingent and non-contingent balances together.DAL – Used for only default non-contingent balances.DOF – Used for only default contingent balances.



We know that a CAL record holds maturity values as per scheduled dates in case of CAL records for Contract applications with a Term. This feature can be used to report time-based contracts according to their residual maturity.In a DETAIL line, the maturity splitting could be shown under different lines. Maturity splitting is possible only in reports using Closing group columns and Lines reporting CAL balances.You can see how the set of fields MAT.DATE.TO and MAT.LINE.NO are entered.Periods which need to be entered in chronological order, can be defined in Days, Months and Years and they will be calculated from the system date. Last period should always be left as REST.For the first period, MAT.LINE.NO is left blank, which means the balances for the first period will be reported under the current Line. Balances under other time slabs will be reported in their respective line numbers.


Here, you will see how the other Lines in a maturity split are defined. The line MBGL.0510 needs to be created first as shown. As it is a dependent line, all the mapping fields should be left as null.Then the line MBGL.0410 will be created. Here, the mapping details i.e. which CAL keys will be selected for this Line will be reported.In both the Lines, the ASSET.EXT.DUP Field will be set to MAT, to denote that the Lines represent Maturity split.


A detailed line may have a credit or debit amount as its value. The requirement could be to report if the Balance is Debit in one Line, and if it is Credit in another Line. It is not possible to define this i.e. the type of Balance in the mapping definition, which you will learn later. For example, if the Current Account net balances are in debit, print in one Line, and if it is in credit, print in a different Line. This can be achieved by using the fields ASSET.SIGN and ASSET.OPP.LINE. Here, you can see that in Line 200, ASSET.SIGN is defined as DEBIT and the ASSET.OPP.LINE has been defined as 600. In this case, the mapping for selecting the CAL keys will be defined only in Line 200. If the balance returned is in Debit, it will be reported in Line 200, else it will be reported in Line 600.


There is a similar facility to report in different lines the Profit/Loss Balances according to the sign.Fields PROFIT.TYPE together with PROFIT.SIGN and PROFIT.OPP.LINE are used for this purpose.Here, in Line 200, PROFIT.TYPE Field is set as LINE, PROFIT.SIGN as DEBIT and PROFIT.OPP.LINE as 300. This means if the Profit & Loss balances to be reported is with debit sign, it will appear in Line 200, else it will be reported in Line 300. In this case, the mapping to select the CPL keys will be defined in Line 200, and Line 300 will not have any mapping definition.


It is possible to set the PROFIT.TYPE Field as RECORD, in this case the field PROFIT.EXT.DUP Field needs to be set as REC. This field is similar to the ASSET.EXT.DUP, we have discussed earlier. Here, you can see that in Line 200, PROFIT.TYPE Field is set as RECORD, PROFIT.SIGN as CREDIT and PROFIT.OPP.LINE as 300. In this case, the individual CPL records whose balances will be reported will be taken into consideration and not the net balance to be reported in the Line. Those CPL records with a credit balance will be summed and reported in Line 200, and those CPL records with a debit balance will be summed and reported in Line 300.The mapping for selecting the CPL keys will be defined only in Line 200.For example, in Line 200, CPL records for Commission are selected and there are two records, one for LD Commission + 150, another for MM Commission is –100 and the net result of this line is +50. In this case, 150 will be reported in Line 200 and -100 will be reported in Line 300.In the same case, if PROFIT.TYPE Field is opted as LINE, then the net amount +50, which is a credit amount, will be reported in Line 200.


It is possible to report in different lines the result of a Profit and Loss line according to the sign of the total line or the various consolidated records which are included in the definition of the line. For example, in the slide shown above details of line 7810 are taken for line 3810 for netting of P & L. In the same way it is also possible to report in different lines the result of an Asset and liability definition also.


The Profit and Loss data can be also reported according to the period using the field PROFIT.PERIOD. You have learnt in the Financial Accounting course, that in a CPL record, 2 balances are held one is the YTD (Year to Date) balance, which is the balance till the previous month end and another is the CM (Current Month) balance, which is the balance for the current month.When the mapping to select CPL keys is done, the PROFIT.PERIOD Field can be set to CM or YTD, meaning the Current Month or Year to Date (until previous month-end) Balance will be report in the Line. In this case, a Line No. Can be specified in PP.OPP.LINE Field to report the other Balance. For example, in Line 200, if you define PROFIT.PERIOD Field as CM and PP.OPP.LINE as 300, then the Current Month P&L Balance will be printed in Line 200, and YTD (Balance until previous month-end) will be printed in Line 300.A value of ALL in PROFIT.PERIOD Field will indicate that the current closing balance (CM+YTD) will be printed in the Line. In this case, the PP.OPP.LINE cannot be defined.

T24 Bank can decide whether local currency equivalents of Forex contracts could be reported either as the latest value after revaluation or as originally contracted.FX.REP.RATE Field, if set to HISTORIC, will show the values as per historic rates available in the contracts.Remember, this option is used only for Closing group reports and ignored for Movement group reports.For this FOREX contracts hold the original historic rates which should be accessed by Line application for reporting values as per original rates.CAL key balances show normally the currency equivalent at the EOD after revaluation for the day.



We have earlier discussed under Report Heading, that it is possible to maintain the Line Balances and their underlying entries for all Lines of a Report.If you do not wish to maintain such balances for all Lines, it is possible to specify such functionality at a Line level.For this, the field LINE.BALANCE can be set as NULL or SUMMARY or DETAIL. NULL option will not retain Line information.SUMMARY and DETAIL will respectively maintain the Line Balances and individual entries for the Line.


In a Detail Line, T24 will report amounts from selected CAL and CPL records. For Asset Liability consolidation, you know that there are four fixed consolidation parameters, and then up to 12 user defined choices made in CONSOLIDATE.COND. All these form the basis for reporting. Users can use these 16 parameters plus the Asset Type while defining the rules to select CAL records, for reporting in a Line.Financial information from CAL records that has to appear in a line is defined through associated multi-value fields commencing with ASSET.APPLIC.ID. You can see here that the Application Id, Currency Market, Position Type and Currency, which are the fixed parameters, are first listed and then the names of consolidation parameters as set in the CONSOLIDATE.COND ASSET&LIAB record are listed. Finally, the Asset Type, which is used in CAL records to hold the Balances, is listed.


Users can specify values for each of these fields, to select appropriate CAL records and within them the Asset Types. Null values in a field means any value is allowed.If required, Users can multi-value and define multiple sets of values, which will be taken as “OR” conditions, for selection. The field ASSET.APPLIC.ID is mandatory in any multi-value set.

It is possible that a CAL or CPL record key can fit into multiple Lines in a Report.T24 will always use the best fit. While doing so, a CAL key will fit into a Line, which has the maximum number of parameter values fitting. However, even then it is possible that a CAL key will fit into multiple Lines. Then T24 will use the following priority order for fitting the CAL key to a Report Line.User defined consolidation variables 1 to 12 in ascending orderAsset TypeAsset CurrencyAsset Pos TypeAsset Ccy Mkt Asset Applic IdIn case of a CPL key, the order of priority for fitting would be User defined consolidation variables 1 to 12 in ascending orderProfit CurrencyProfit Applic Id



Though the mapping done to fit CAL or CPL key values to a Line could be multi-valued to define OR conditions, it is not convenient when you wish to fit a Line to a range of values. For example, if you require a Line to report balances of all Accounts with Categories in the range 1001 to 1100, you have to multi-value the mapping set 100 times to specify the Category value from 1001 to 1100. The table RE.STAT.RANGE can be used to overcome this problem, by defining a range of values for any CAL or CPL key parameter, which are used in a Line definition.Ranges can be defined based on Application Id and a Consolidation field relevant to that Application. For example, here you can see that a Range has been defined for Account Application and the Consolidation field CATEGORY in the range 3101 to 3107. It is also possible to set ranges for Customer level consolidation fields without specifying an Application Id. In addition, ranges can be also defined for ASSET.TYPE or ASSET.CURRENCY or PROFIT.CURRENCY.Start Range and End Range are specified in the fields START.RANGE and END.RANGE. To define multiple discrete values, multi-value START.RANGE Field and give the values, without giving any value in END.RANGE Field.


You can view here a range given for Nostro accounts, based on Consolidation field CATEGORY. It has been specified that this range can be used only for ACCOUNT application.Similarly, in the next screenshot, a range for SECTOR is specified. This range can be used for any application, since SECTOR depends on Customer and not on other T24 applications.In the example with ASSET.TYPE, discrete values are specified by multi-valuing START.RANGE. In the last example, PLCATEGORY for consolidation of PL items defined in CONSOLIDATE.COND has been used. Though no application has been mentioned, this can be used only in CPL keys selection.How can you attach a Range to a Line? You can attach it by pre-fixing *, for example *NOSTRO can be specified as a CATEGORY value in a Line to select any CAL key satisfying the range of Category values. Remember, it is not possible to modify a Range when it is linked to any Line.


In CONSOLIDATE.COND, the user defined variables are Variable1: Product, Variable2: Department and Variable3:Sector.The range PUBLIC is defined on the consolidation field SECTOR in the Range: 1000 to 2000Line No. Product Department Sector0150: 11200 Null *PUBLIC0160: 11200 Null 1000The CAL keys will be fitted to the Lines shown against them:AC.1.TR.USD.11200..1000…. to Line: 0160AC.1.TR.USD.11200..1100…. to Line: 0150.


A CAL record holds balances according to the differing nature of the Assets / Liabilities called Asset types.These Asset types are hard coded and they could be contingent or non-contingent. Contingents are always Off Balance sheet items. Examples of Contingent Asset Types are forward Principal, forex spot, etc. P & L Asset types like accrued interest, accrued commission, etc. are not hard coded, but use the corresponding PL Category.In a Line, you can select which Asset Type balance of a CAL key, you would like to report.This gives the flexibility in reporting different Asset types under a key in different lines or consolidating different asset types into one line.For example, loan principal together with accrued interest thereon could be shown under a single line or in two separate lines.


These are examples of asset types for Contingent balance, Non-contingent balances and Accruals. In case of Accounts, the P&L categories for interest expense and income are hard coded, and there could be two separate interest rates defined for an Account, which are separately accounted.


In FRA, only contingent balances are transacted. Hence, Asset types will be only Contingent.


List of asset types for FOREX module is given. Like FRA, there is no non-contingent contract balances. Charges are not accrued here.


List of assets types possible in LD CAL keys is given. Accruals take the asset types by Category codes defined for PL credit or debits in LD module.


List of assets types possible for a MG contract is given. Similar to LD, accruals take the asset types from Category codes, which are defined in the Parameter table.


List of assets types possible for a MM contract is given, and they are similar to that of a LD contract, except that no commitment asset type is possible in MM.


List of assets types possible in Securities Module is given. Accruals take the asset types from Category codes defined in SEC.ACCOUNT.MASTER.


It is possible to create a line as “CATCH ALL” in order to obtain in one line all undefined items. Useful for reports like Balance sheet.The options DAL and DOF to report default non-contingent and contingent items separately have been introduced in R6 release.A CRF record will normally appear once only on any report. Where it is requested that the details are to appear on two or more lines, (say showing a contingent item above as well as below the line in a balance sheet), the 'Y' is to be entered in this field to indicate that duplication is allowed.

A CRF record will normally appear only once on any report. Where it is requested that the details are to appear on two or more lines, (say showing a contingent item above as well as below the line in a balance sheet), the 'Y' is to be entered in this field to indicate that duplication is allowed.



For Profit & Loss we have one consolidation parameter (CP or PL) generated by the system, then up to 12 variable choices made in CONSOLIDATE.COND and then the PROFIT.CURRENCY and PROFIT.EXT.DUP.


It is possible to create a line (usually 9999) as “CATCH ALL” in order to obtain in one line all undefined items. Useful for reports like Profit & Loss.The options DAL and DOF to report default non-contingent and contingent items separately have been introduced in R6 release.A CRF record will normally appear only once on any report. Where it is requested that the details are to appear on two or more lines, (say showing a contingent item above as well as below the line in a balance sheet), the 'Y' is to be entered in this field to indicate that duplication is allowed.


RE.STAT.NAME file is used to create records containing data for specific lines which can be used across several reports. For example Cash on hand, Cash with Central Bank etc. To use this in a report, RE.STAT.REP.LINE record has a field to access this data as line detail. CONSOL.NAME is the field where data created in RE.STAT.NAME get attached.This will enable modification of a line easier at one place i.e. When modifications for a line are to be effected, instead of doing the same in all reports where such lines occur, it would be enough to modify RE.STAT.NAME for line concerned, to effect changes in all reports.By now, you know that a Line is dependent on a Report, and for each Report, you have to define separate Lines.However, it is possible that similar Lines are used across multiple Reports. For example, you may report Cash Balances across multiple Reports.Instead of completely defining a Cash Balance Line in multiple reports, it is possible to define it in a central place, and then use the definition in Line definition of any Report. RE.STAT.NAME application is used to create records containing the mapping definition for specific lines, which can be used across several reports. The structure is similar to a LINE.


Id of a record in this table can be 20 alphanumeric characters. The Id of a RE.STAT.NAME record can be attached to the field CONSOL.NAME in RE.STAT.REP.LINE. When a RE.STAT.NAME record is linked to RE.STAT.REP.LINE, the details in RE.STAT.NAME are automatically populated in the LINE.When modifications for a Line mapping are to be effected, instead of doing the same in all reports where such Lines occur, it would be enough to modify RE.STAT.NAME record, which will effect the change in all reports.When RE.STAT.NAME record is linked to RE.STAT.REP.LINE, the details in RE.STAT.NAME are automatically populated.Care must be taken when modifying the RE.STAT.NAME record. A check must be done to ensure that the modification has been reported in RE.STAT.REP.LINE.If the record is not updated, then type again the CONSOL.NAME and it will be updated.


RE.STAT.REP.LINE contains details about the different lines and line contents for each report. Covers details on totaling, spacing between lines as well as which type of CRB records are to be printed on the line.















RE.STAT.REQUEST application allows you to print a CRF type report on demand. If attached to a COB job, then requisite reports can be automatically printed as part of COB processing.You can view here the flow for generating CRF Financial Reports. You will learn more about RE.STAT.REQUEST in the next page.


As already discussed, RE.STAT.REQUEST is used for production of CRF reports, which report only the Balances from CAL and CPL key.It specifies the reports that are to be produced, language of the reports and the output format. The output could be a report, which can be printed or copied to hard disk as per the format specified in RE.STAT.OUTPUT. The level of the report required can also be specified. This means the report can be specified to be a ‘SUMMARY’, ‘DETAIL’ or ‘BOTH’ types of reports.SUMMARY Report prints only the report lines with balances, and do not print consolidation keys under each Line.DETAIL Report prints both report lines as well as the individual consolidation record keys that make up each line, together with their balances.The option BOTH produces separate Summary and Detail reports.


You must know that the RE.STAT.REQUEST record with Id DAILY must never be deleted, because it is used as a data record in the COB Batch EB.STAT.PRINT for printing CRF reports.However, the record can be modified by the T24 Bank as per their requirements i.e. to either add or remove reports.Other RE.STAT.REQUEST records can be created to generate adhoc CRF reports on-line.


The Batch record EB.STAT.PRINT is used to generate CRF reports during COB at desired frequency. The reports to be generated are to be specified in the RE.STAT.REQUEST record with Id: DAILY.RE.PRINT.DEAL.RPT is another file to generate CRB reports which are produced with details from CAL,CPL and select details of accounts and contracts.

We will now see the process of printing reports during COB.RE.PRINT.DEAL.RPT is the batch record used to generate CRB files during COB. CRB type reports in addition to printing the Line Balances, will print for each Line its related Account or Contract Ids and their Balances. Of course, you have to first set the Report in the HEAD table. The following are the steps to be followed to set up the printing of CRB type reports during COB. The reports thus generated will have a pre-fix of CRB before the Report Id.Set records in the applications RE.EXTRACT.PARAMS and RE.RETURN.EXTRACT for the report to update a flat file. Id will be equal to Report ID.ENQUIRY application should contain a record with Id : CRB.REPORT. The layout of the CRB report is specified through this record.


In ENQUIRY.REPORT table, a record with Id: CRB.REPORT.XXX should be created, for the Report with Id: XXX.After setting the above applications, we need to set the batch RE.PRINT.DEAL.RPT to generate the CRB report.In the Batch record, the Id of the CRB report should be specified in the DATA field of the job RE.OUTPUT.EXTRACT.Further, the DATA Field of the job EB.PRINT should be set with the value “ENQ CRB.REPORT.XXX”, where XXX is the Report Id.


Reports already generated are held in the HOLD.CONTROL, for the period specified in Field REPORT.RETENTION in SPF table.This setting at SPF table can be bypassed by setting report specific retention period in the table REPORT.CONTROL for individual reports.For printing adhoc CRF reports, when you verify a RE.STAT.REQUEST record, desired CRF reports will be generated and stored in HOLD.CONTROL. However, RE.CALC.REP.LINES should be run in classic mode before using RE.STAT.REQUEST application. Otherwise the report generated online will show zero balances. Using the Enquiry REPORT.LIST, the desired reports can be viewed and / or printed.


The steps for printing online CRB type reports are listed.



By using Function Verify in HOLD.CONTROL, and using Enquiry REPORT.LIST, the desired reports can be viewed and / or printed.


The mismatches in T24 must be taken seriously if they happen. They must be corrected immediately. We have already discussed that CRD (Difference) reports are investigation reports that provide details of mismatches between consolidation record level balances and underlying Contract and Account level balances for a particular line or lines on a report. With the introduction of online update of work files for CAL consolidation by most of the applications, the mismatch will be eliminated for those applications.RE.STAT.BAL.REC application needs to be run in verify mode for a specific line number or a range of lines of a Report, in order to get the Balances as per CAL records, and the Balances of underlying Accounts and Contracts, as updated in their Balance Look-up tables. This report would have a pre-fix of CRD and stored in HOLD.CONTROL. CRD type reports can be also generated on-line by verifying RE.STAT.MISMATCH application record. In this case, it will report those lines where there is a mismatch between the CAL balances and underlying Account and Contract balances.


Here, you can view a CRD report generated by verifying RE.STAT.BAL.REC.


Here, you can view another CRD report generated by verifying RE.STAT.MISMATCH.


RE.CONSOL.REQUEST is used to produce combined CRF reports for a group of Companies. The reports are known as CRC reports, and the Report Id will be pre-fixed with CRC.This functionality is available for both Multi-Company and Multi-Book environments.Combined reports can be produced online by verifying the RE.CONSOL.REQUEST application record or by attaching such records in the Batch: EB.CONSOL.PRINT.RE.CONSOL.REQUEST uses the parameters specified in COMPANY.CONSOL to define a group of Companies for combined reporting purposes.When consolidated reports are produced, the local currency amounts and local currency equivalent amounts will be converted into a common reporting currency, whose exchange rates for conversion need to be defined.

Let us now look into the fields of RE.CONSOL.REQUEST.Field REPORT.NAME will be the Id of the report, which has been defined in RE.STAT.REPORT.HEAD.CONTENTS Field specifies the level of the report to be printed. Value DETAIL means report produced will be at CRF record level. Both the lines and corresponding CAL/CPL keys with their balances will reported.Value SUMMARY means report produced will be at report line level. This means that only the report lines and balances will be printed. When BOTH is chosen, then 2 Reports, one DETAIL and other SUMMARY reports will be produced. CONSOL.NO Field is linked to the COMPANY.CONSOL record, in which further parameters for consolidation are defined.REPORT.CCY Field will indicate the currency in which the report is to be printed. If the field is NULL, default currency specified in COMPANY.CONSOL will be used.


RATES.MKR Field indicates how the local currencies of the Companies need to be converted into the Reporting currency. This is relevant when the Local Currencies are different or when different Currency tables have been set up for the Lead Companies. Value DEFAULT in this field will take currency file as specified in the relevant COMPANY.CONSOL record. Value COMPANY means Currency file of concerned Company will be used. If there is more than one Currency file for a local currency, values specified in the fields LCL.CCY and CCY.COMPANY of the related COMPANY.CONSOL record will be used.If Value SPECIAL is mentioned, rates defined in the RE.RPT.CCY.RATE table will be used.Field SPCL.RATE.ID will have Id of the RE.RPT.CCY.RATE record, whose exchange rates will be used, when RATES.MKR Field has a value of SPECIAL.


RE.RPT.CCY.RATE table can be used to indicate special rates for reports consolidation.We have already seen that RE.CONSOL.REQUEST makes use of rates defined in this table when RATES.MAKER Field in RE.CONSOL.REQUEST has a value of SPECIAL.Id of the table RE.RPT.CCY.RATE is CCY.NNN (Currency code followed by 3-digit sequence number). Thus, different rates can be defined for a Currency, which can be used while consolidating different financial reports. When a new record is input, the rates between each Local Currency and the Reporting Currency will be automatically defaulted, which could be modified.


Important fields along with the examples are furnished as:LOCAL.CCY – Local currency for which the following rates will apply; BASE.CCY – Either the Local currency or the Reporting currency in the ID;QUOTE.CODE – Null or a value of 0 to 5 to specify the units of the BASE.CCY whose rates are quoted. Null or 0: 1 unit, 1: 10 units, 2: 100 units, etc.EXCH.RATE – Rate of the Non Base currency (i.e. the Local currency or the Reporting Currency) against the fixed units of the Base Currency.Example: LOCAL.CCY: USD, BASE.CCY: USD, QUOTE.CODE: 0, EXCH.RATE: 1.095, Reporting Currency in the Id: EUR implies, 1 USD=1.095 EUR.



Further parameters for CRC reports are defined in COMPANY.CONSOL where Id is three-digit member. This Id will be attached to a RE.CONSOL.REQUEST record. COM.CONSOL.TO Field identifies the Company Code for the combined report. The purpose of this field is to print the Company details such as Company Name, etc. in the Header of a Report. An operative Company code can be specified, provided it is again included in the COM.CONSOL.FROM Field. A non-operative Company Code (with CONSOLIDATION.MARK=C in COMPANY record) could be also specified. The purpose of such a Company will be only to give the static details for a consolidation report.


COM.CONSOL.FROM Field is a multi-value field to specify the IDs of operative Companies, whose data needs to be combined for reporting purposes.DEFAULT.RPT.CCY Field is the Default reporting currency for the combined report, which will be used if reporting currency is not specified in RE.CONSOL.REQUEST.DEFAULT.CCY.COM Field is the Default Company whose currency rates will be used for defaulting rates at run time, when the option DEFAULT is used in RATES.MKR Field of RE.CONSOL.REQUEST during run-time.LCL.CCY and CCY.COMPANY Fields are defaulted for each Company with a unique local currency.If the currency files are different in Companies with same Local currency, it is possible to select which Company’s Currency files need to be used for determining the exchange rates for consolidated report.These rates will be used when the option COMPANY is used in RATES.MKR Field of RE.CONSOL.REQUEST during run time.


T24 prints two transaction journal reports: Please remember that these are not standard financial reports designed using the tools we have discussed so far. They are hard coded reports.TXN.JOURNAL.PRINT report shows for any processing date, a transaction journal by application, transaction reference, transaction description, amount, currency and local equivalent. To activate the generation of this report it is necessary to add them to the BATCH record EB.PRINT. The first one TXN.JOURNAL.PRINT Report is generated for all entries excluding contingent entries.


The second report is the same kind report on daily transactions for all contingent accounting entries.


The number of days up to which reports will be retained in HOLD.CONTROL can be set in REPORT.RETENTION Field of SPF. Default value is 5 days. There is a similar field in REPORT.CONTROL, where the parameter can be set up for individual Reports.In addition to retain historical reports, it is possible to retain historical balances and movement details of report lines, by setting MAINTAIN.BALANCE Field in RE.STAT.REPORT.HEAD or LINE.BALANCE Field in RE.STAT.REP.LINES. The option, if chosen at HEAD level will apply to all Lines of the Report. Alternatively, the option can be chosen for required Lines in the LINE application.Information could be held for a maximum of 99 months and the tables can be set to maintain ‘summary’ balances or ‘detail’ balances. RE.STAT.LINE.BAL records are maintained for the Line Balances, if Summary is opted. RE.STAT.LINE.MVMT records are additionally created to maintain an index of the underlying accounting entry Ids, if the Detail option has been chosen.


RE.STAT.LINE.BAL is created if the balances are required to be maintained in the Line or the Head. This table would contain the following values for every business day:Opening BalanceCredit Movement for the DayCredit Movement for the Current MonthCredit Movement for the Current YearDebit Movement for the DayDebit Movement for the Current MonthDebit Movement for the Current Year &Closing Balance for both Deal currency and Local currency.One entry (Id) is written for each day for each Line number and sorted Currency wise. Hence, the Id of this file would consist of Line reference + CCY + Date. For a Closing type report only the opening and closing balances are recorded and movement (credit and debit) details are maintained only for Movement reports. (Column Type should be Movement).


RE.STAT. LINE.MVMT will be updated to maintain an index to the underlying movements (Ids of accounting entries) if the “Detail” option has been chosen for the LINE.BALANCE of associated Lines or in the HEAD record. Such records will be maintained only for MOVEMENT type reports and not for closing type reports which report only closing balances. For each report line, currency and date the entry keys raised by the system are

stored with an identifier. ‘A’ for (Account) - STMT.ENTRY‘P’ for (PL) - CATEG.ENTRY‘R’ for (Spl. Entry) - RE.CONSOL.SPEC.ENTRYInstead of storing Ids of individual Accounting entries, in case of STMT.ENTRY, the Ids of RE.CONSOL.STMT.ENT.KEY, in case of CATEG.ENTRY, the Ids of RE.CONSOL.PROFIT, and in case of SPEC entries, the Ids of RE.CONSOL.SPEC.ENT.KEY are recorded. These records in turn hold respectively the Ids of STMT.ENTRY, CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY.


In the above screen shots, you can observe the way the Record Ids related to the movements are stored in respect of RE.CONSOL.SPEC.ENTRY and CATEG.ENTRY.


The enquiry LINE.BAL.SUM displays the movements of the Reporting Line required.


The enquiry LINE.BAL.SUM.LCL displays the movements of the Summary Reporting Lines of a Report.


RE.STAT.LINE.CONT table holds for each Line in a report, the CAL keys and associated Asset Types, whose details will be printed in the Line. This table is used to drill down from a Line to its associated CAL keys.


When T24 generates a report, it will not try to fit the CAL keys to Report Lines each time. That will require a lot of processing time.Instead, whenever a Report is created or modified, an index relating all CAL keys to various report lines, is maintained in the table RE.CONSOL.ASSET.LINE. In fact, this index is built as part of COB processing. That is why when you create a new report of modifying an existing report, you cannot generate online the concerned reports, and you can do it only after COB processing.As you can notice the record Id is the CAL consolidation variable 1 or a Range. The details hold the values of other consolidation variables, the Asset Types and associated Report and Line Nos.


Similar to RE.CONSOL.ASSET.LINE, for the CPL records such an index is maintained by T24 in the table RE.CONSOL.PROFIT.LINE. The structure is similar to that of RE.CONSOL.ASSET.LINE.


Here you can see how you can drill down from a Line to its constituent CAL keys.


This shows how the Lines and their related CAL key and Balances are printed in a Report.


Here you can see a CRD report with Line/CAL key balances and Balances of underlying Accounts and Contracts.


You can view here a CRB report with account / contract balances. You can see how the CAL keys determined by RE.CONSOL.CONTRACT are used to return the Accounts and Contracts, which form part of a Line.


RE.STAT.LINE.CHANGE application is useful to move lines around within a specific report. If the changes are required on existing reports, RE.RECALC.REP.LINES should be run in Classic Mode. However, the reports generated will be based on the previous COB figures, but including the line modifications.RE.RETURN.EXTRACT application is used to extract details of CRF reports to a disk file. The parameters for extraction of the Report should be specified in the application RE.EXTRACT.PARAMS with Id equal to the Report Id.





We have so far seen in this module different Reports and methods available for generating these reports.We have also seen tools available for the generation of reports – Header, Column and Line. We learnt how to generate reports and print reports. Besides the above, we also looked at the files required to store the information of line balances for posterity alongwith the importance of Utility Files.


Date post:	14-Jul-2016
Category:	Documents
Upload:	donakomeah
View:	1,267 times
Download:	270 times

T24 - Financial Reporting - R9

Documents