QuestionFrom which applications can account balance figures like Monthly account balances, daily account balances be fetched? AnswerI. You can get this information from ACCT.ACTIVITY file which is a live file. It updates online, shows the day wise daily credit and debit and closing balance. II. You can use Enquiry STMT.ENT.BOOK or VAL.STMT.ENT.BOOK based on your system. If it is a value-dated system then use VAL.STMT.ENT.BOOK, and if Trade dated then you can use STMT.ENT.BOOK enquiry. These enquiries will give you balance of accounts for different date criteria.QuestionIs there any parameter which can restrict the account to go into debit balance? AnswerNo, there is no parameter to restrict the account getting into debit balance, however if any transaction tries to make balances of account to debit then an override Unauthorised overdraft will be generated by the system. If you wish to stop such kind of transaction you can make use of Dispo officer setup / Overrides to restrict users to authorise transactions with such override. Please refer to the How to link for the setup. QuestionGENERAL.CHARGE based on account balance AnswerQuery:Levy a flat amount month end charge(GENERAL CHARGE) on all active accounts based on account balance. Answer:Kindly be note that according to T24 functionality it is not possible to levy general charges for the active accounts only, leaving the dormant/inactive accounts. Any type of general charges will also affect the dormant/inactive accounts. Also if charges are setup for an account in the GENERAL.CHARGE record then system will collect full charge amount from the account irrespective of whether the account has the available balance or not. Hence it is not possible to debit charges based on account balance. QuestionWhat is the difference among OPEN.ACTUAL.BAL, OPEN.CLEARED.BAL, ONLINE.ACTUAL.BAL, ONLINE.CLEARED.BAL and WORKING.BALANCE in account application? AnswerONLINE.ACTUAL.BAL: This field contains the current Actual Balance of the Account. This is exactly the same as the actual balance at the start of day (Open Actual Balance) plus the value of all the fully authorised entries since the start of day. In a value dated accounting system, this balance is updated by future value dated entries only during start of day processing of the value date, unlike the trade dated systems where this field would be updated immediately on generation of the entry. In both systems, forward entries or F entries would update this balance only during batch processing of the respective value dates. ONLINE.CLEARED.BAL: This field contains the current Cleared Balance of the Account. This is the same as the cleared balance at the start of day (Open Cleared Balance) plus the Value of all fully authorised entries since the start of day, except any credit or reversal debit entries with future Exposure Dates. Of all the future dated entries in a trade dated system, only debit entries update this balance on the BOOKING.DATE itself. The future dated credit entries hit this balance only during start of day processing on the EXPOSURE.DATE. In a value dated accounting system, both debit and credit future value dated entries update this balance during start of day processing on the EXPOSURE.DATE. For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day on the appropriate date (EXPOSURE.DATE) by the program AC.FWD.EXPOSURE.

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

OPEN.ACTUAL.BAL: This field contains the Actual (unclear) Balance or Ledger Balance of the Account as on start of day. In a trade dated accounting system, the future dated entries will update this balance during batch processing on the booking date of the entries. In a value dated accounting system, future dated entries will update this balance during batch processing on the value date. OPEN.CLEARED.BAL: This field contains the Cleared Balance of the Account as on start of day. This includes the value of all entries over the Account except any credit entries or reversal debit with Exposure Dates in the future. In a trade dated system, future dated debit entries will update this balance during COB processing on the BOOKING.DATE. Future dated credit entries hit this balance only during start of day processing of the EXPOSURE.DATE. In a value dated accounting system, both debit and credit future dated entries update this balance during start of day processing of the EXPOSURE.DATE. For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of day on the appropriate date by the program FWD.EXPOSURE.QuestionACCOUNT.STATEMENT enquiry showing wrong balance while viewing for specific ACCOUNT. AnswerFor getting the ACCOUNT balances for any specific period kindly use the enquiry STMT.ENT.BOOK and where as ACCOUNT.STATEMENT enquiry is designed to use HANDOFF id as selection to view the STATEMENT for the HANDOFF generated in AC.STMT.HANDOFF.QuestionHow to rebuild Available balance ladder in the Account record AnswerAvailable balance ladder can be rebuilt using the application AF.REBUILD.REQUEST and the job REBUILD.AVAIL.FUNDS. We can rebuild ladder just for one account, or a group of accounts or for all accounts based on the setup done in AF.REBUILD.REQUEST template. We need to create a record in AF.REBUILD.REQUEST application with ID as NEXT.WORKING.DATE (T24 date), and during the SOD stage of the subsequent COB, REBUILD.AVAIL.FUNDS jobQuestionWhat is the difference between the RE.ACCT.OPEN.BAL, OPEN.ACTUAL.BALANCE and the OPEN.CLEARED.BALANCE fields in the account table? AnswerThe RE.ACCT.OPEN.BAL is an application, used to maintain the Opening Balance of the customer and internal accounts. The OPEN.ACTUAL.BALANCE and the OPEN.CLEARED.BALANCE are the fields in the account table. The OPEN.ACTUAL.BALANCE contains the Actual (unclear) Balance or 'Ledger Balance' of the Account as at the start of the day and the field OPEN.CLEARED.BALANCE contains the Cleared Balance of the account as at the start of the day. This includes the value of all entries over theccount except any credit entries or reversal debit with Exposure Dates in the future.QuestionIs it possible in R7 that the balance of account xxxxx differs from the account OPEN.ACTUAL.BAL? AnswerFrom R7, contract balances for report will be arrived from EB.CONTRACT.BALANCES file. Check this file for the particular accountQuestionCan a T24 system have different dates as TODAY in DATES record, across the Lead Companies and run COB using TSA.SERVICE record COB? AnswerThe answer is NO.As per the standard functionality of T24, only with GP (Global Processing) product installed, the T24 system can have different dates in the DATES records across companies. This will enable to group companies of same region together and run COB separately for them.During COB, the job EB.CYCLE.DATES will create a record named COB in the F.LOCKING record. It will update the TODAY date based on the company for which it is run. When the job EB.CYCLE.DATES runs for other companies after when it runs for the company BNK, it will update the F.LOCKING record COB with the date of the other company. The date in this record is used to populate the common variable C$BATCH.START.DATE, which is used across several jobs of the COB like IC.COB, etc. Since there will be a mismatch between the date assigned to C$BATCH.START.DATE and the date available in the DATES record for that company, there are chances that the COB jobs fail to process any records.Any of these procedures should be followed to solve the above scenario,1) Synchronise the DATES for all companies and run COB.Or2) If GP product installed, group companies together and create a separate TSA.SERVICE record for each and every group or company and run COB separately for them.QuestionOpening balance on Enquiry ACCT.ENTRY.STMT always displays value 0, even though there is balance on the account on a specific date. AnswerThe enquiry ACCT.ENTRY.STMT is actually designed to be executed only upon verifying the ACCT.ENTRY.STMT template. The selection criteria like START.DATE and END.DATE, which is mandatory to produce an ACCOUNT.STATEMENT for a particular period and to determine its Opening balance are present in ACCT.ENTRY.STMT template and not in the enquiry. Hence when we verify ACCT.ENTRY.STMT, the routine ACCT.ENTRY.STMT.RUN will get triggered, which in turn executes the enquiry ACCT.ENTRY.STMT and displays the relevant output. Since, you have not verified this enquiry, the opening balance is displayed as 0QuestionIncorrect opening balance and entries in un-sorter order when enquiring for master account. AnswerKindly use the field SORT.REQ to YES in the enquiry STMT.ENT.BOOK or as an alternate option to BOOKING.DATE, use the criteria PROCESSING.DATEQuestionHow does the Account balance get updated when NS is installed and FT is input during COB? AnswerNon Stop Processing(NS) and Close Of Business(COB) complement each other. Close Of Business disallows input and processing of records in all applications other than the one supported by Non-Stop service.The applications that are available in NS service will be available without any restrictions and will be using the next working date for processing. This ensures concurrent transactions are not picked up for processing by COB that is running parallell.Case 1: Working balance of Account with reference 123456 is 500 Euro before the COB. We start the COB. During the COB a User is inputting an FT transaction debiting the account with reference 123456 with 300 Euro. How the system will be checking the balance at that stage (assuming that at that moment no txns have come from the COB for that account its at the early stages)?The system will consider the next working date for processing the FT transaction inputted during COB to debit the account with reference 123456 with 300 Euro. For the current date the system will process the account with reference 123456 with 500 Euro. i.e., the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL fields are updated with 500 Euro and the WORKING.BALANCE fields with (500-300) = 200 EuroCase 2: What will happen if after the FT transaction is authorized and during the later stages of the COB a charge will be posted on the account (with amount Euro 400). What will happen to the balances in this case?The posted charge on account with amount 400 Euro will be processed with the next working date. At this stage, after the authorization of FT the fields ONLINE.ACTUAL.BAL, ONLINE.CLEARED.BAL and WORKING.BALANCE are updated with (500-300-400) = -200 Euro and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL fields with 500 Euro.QuestionWe have WORKING.BALANCE problem for a particular account whose INAU transaction has been deleted from backend AnswerAs per the standard T24 Design, deletion of a transaction in INAU status, from backend, is not recommended. Doing so will result in Account balance problem leaving the problematic ENTRY.HOLD intact. The normal procedure is to delete the INAU transaction from Globus prompt, even if the number of such transactions is large.QuestionHow the Account balance would be updated when NS is installed and FT is input during COB? AnswerNon Stop Processing and Close Of Business complement each other. Close Of Business not allow input and processing of records in all applications other than one supported by Non-Stop service.The applications that are available in NS service will be available without any restrictions and will be using the next working date for processing, thus ensuring the concurrent transactions are not picked up for processing by the Close Of Business which is running in parallel.QuestionHow can I set up a flat monthly account maintenance charge in T24 (the charge is a flat amount charged independently of the balance of the account)? AnswerCalculation of flat charges for an account independent of account balance can be achieved through IC.CHARGE application setup.QuestionIn some cases account balances fields are displayed in Account application. In the same time according to R12 User Guides we find this type of information in EB.CONTRACT.BALANCE. AnswerAs per the T24 functionality in R12, the balance fields in the account are removed and they will be updated in the EB.CONTRACT.BALANCES record. There is a field BALANCE.MOVED in the EB.CONTRACT.BALANCES application, which will be set to 'YES' if the balances are moved from Account to EB.CONTRACT.BALANCES record during upgrade.In case the balance in the account record is not moved, then the balance will be moved only once it has movement/transactions.QuestionSuppress -Available Balance Override ? AnswerThe overdraft on available balance will be triggered if you have the AVAILABLE BALANCE ladder for the account ,So to supress the override we should set the CASH FLOW DAYS to NULL and CREDIT.CHECK to WORKING in the ACCOUNT.PARAMETER file. Due to this setting the AVAILABLE BALANCE ladder wont be built for the accounts so there wont be any AVAILABLE BALANCE override and only unauthorized overdraft based on working balance will be raised.QuestionWhen OPEN.ACTUAL.BAL of an account is updated? AnswerOpen actual balance Contains the Actual (uncleared) Balance or 'Ledger Balance' of the Account as at the start of the day. This balance is equal to the BK.BALANCE FOR PREVIOUS DAY IN ACCT.ACTIVITY (INCLUDE FUTURE DATED CREDIT) = ECB.OPEN.BALANCE( EB.CONTRACT.BALANCES file ) . and this balance will be updated by the JOB EOD.ACCT.ACTIVITY in the BATCH AC.SYS.END.OF.DAY in the stage S010 based on the file ACCT.ENT.TODAY. Hope this clarifies you betterQuestionCredit interest as not calculated for minimum balance type setup. AnswerAs per the query, interest was not calculated when the GCI is defined with MINIMUM balance. Kindly consider the below sample example with the explanation.For the problematic account "0000000438332" group level interest has been defined in the GROUP.CREDIT.INT record "20 MWK 18 SEP 2010". CAPITAL CITY GROUP.CREDIT.INT SEE GROUP.CY.DATE..... 20 MWK 18 SEP 2010 Special Saver Accts Malawi Kwacha ------------------------------------------------------------------------------ 1 INTEREST.DAY.BASIS E 366/365 2 TAX.KEY........... *WHT 3 CR.BALANCE.TYPE... MINIMUM 4 CR.CALCUL.TYPE.... LEVEL5 CR.MINIMUM.BAL.... 1,000.00 7. 1 CR.BASIC.RATE.. 41 Base Rate 1% 0.5% 25 INTEREST.TAX.MIN..10,000.00 ------------------------------------------------------------------------------ In the above record we could see the CR.BALANCE.TYPE is set as "MINIMUM" and "CR.MINIMUM.BAL" is set as "1,000.00". As per the above interest setup system will calculate interest for the minimum amount that is maintained in the whole interest period and the minimum amount should be greater than 1000 for the whole interest period as well. In our case the interest period for the year 2011 is from 01-Jan-2011 to 31-Dec-2011. Since the balance was less than 1000 for the days from 01-Apr-2011(from 1st Apr to 3rd Apr "-34,877.27") to 04-Apr-2011(-54,877.27) system has not calculated the interest and this is the standard T24 functionality for minimum balance type interest calculation. NBM HO Account Activity SEE MWK Spl Saver ACCT.NO.YEAR.MONTH 438332 - 2011-04 SHABA MANNIX W N ------------------------------------------------------------------------------ 1. 1 DAY.NO......... 01 3. 1 TURNOVER.DEBIT. -45,000.00 4.1 BALANCE........ -34,877.27 1. 2 DAY.NO......... 04 3. 2 TURNOVER.DEBIT. -20,000.00 4. 2 BALANCE........ -54,877.27 -------------------------------QuestionACCOUNT.CLOSURE AND LIQUDATION ACCOUNT AnswerUpon Account Closure online, the interest amount is capitalised to the Liquidation Account. As it is an Account Closure event, The FT generated should contain the outstanding balance, Interest and Fees to be settled.pacs reference :PACS00094603Explanation :We would like to explain the functionality , When an account with liquidation account set is closed online with closure charges, charges would be booked to the main account. Only interest and other charges(general) will be booked to the liquidation account. This applies for normal closure as well.QuestionWhy is the core enquiry MB.RG.BALANCE.LIST not generating any output in our system? AnswerThe enquiry MB.RG.BALANCE.LIST gets the data form the record RG.BALANCE.LIST present in HOLD. The value BALANCE.LIST from the field DATA under the job PRINT.ACCOUNT.REPORTS was removed from higher releases. If we need to update BALANCE.LIST then adding the value in the field DATA will solve the problem.QuestionAccount SWEEPING AnswerMaintenance SweepSweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is less than the amount defined in MIN.AMT of AC.ACCOUNT.LINKSurplus SweepSweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is greater than the amount defined in MAX.AMT of AC.ACCOUNT.LINKTwo-Way SweepThere are two cases,Case 1 - If RETURN.AT.SOD is YesSweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the balance in TO.ACCOUNT is either greater than MAX.AMT or less than MIN.AMT defined in AC.ACCOUNT.LINK at End Of Day.Sweep of balances back from FROM.ACCOUNT to TO.ACCOUNT at Start Of DayCase 2 - If RETURN.AT.SOD is NoSweep of balances from TO.ACCOUNT to FROM.ACCOUNT if the amount is either greater than MAX.AMT or less than MIN.AMT defined in AC.ACCOUNT.LINK at End Of Day alone.If you need to move only debit balances from ACCOUNT1 to ACCOUNT2, you can make use of Maintenance SweepIf you need to move balances from ACCOUNT1 to ACCOUNT2 irrespective of debit or credit, you can make use of Two-Way Sweep with AC.SWEEP.TYPE>RETURN.AT.SOD as No.QuestionHow to make the system consider only the WORKING.BALANCE for CREDIT CHECK? AnswerTo make the system consider only the WORKING.BALANCE for CREDIT.CHECK do the following settings CREDIT.CHECK to '', AVAIL.BAL.UPD to none and VDATE.BAL.CHK to ''QuestionSome amounts in T24 balance is different from the amounts calculated with STMT.ENTRY and CATEG.ENTRY AnswerThe T24 account balance will be the sum of STMT.ENTRY alone for a particular account. Hence, we are not supposed to sum the CATEG.ENTRY. Also for the Accrual categories (51007, 52210, 54401, 61090, 63205), CATEG.ENTRY should alone be checked and compared with balance shown in CATEG.ENT.BOOKQuestionQuestion on overdraft override for the Nostro account AnswerThe system will raise the override message "yyyymmdd customer account OVERDRAFT ON AVAILABLE BALANCE currency xxxxxxxx.xx" only for the customer accounts.The processing of override is skipped if it is Internal or Nostro account irrespective of the Account/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER setup.QuestionWhy does enquiry output show different amount in the LIAB enquiry compared to the sum of balance in the accounts for customers? AnswerGenerally, the LIAB enquiry adds the balance of the accounts which have credit balance in it for a customer and displays it in the ENQ LIAB output. When the credit balance is displayed in the ENQUIRY LIAB, the corresponding drilldowns will display different amount as summation of balance will consider both credit and debit balances. If the ENQ LIAB output needs to display the sum of account balance irrespective of credit or debit. The ALLOW.NETTING field should be set to Y in LIMIT record and ACCOUNT records respectively. QuestionFew fields & and its purpose in ACCOUNT.PARAMETER AnswerLOCKED.WITH.LIMIT:=================A New field LOCKED.WITH.LIMIT introduced in ACCOUNT.PARAMETER,ACCT.GROUP.CONDITION and ACCOUNT to check Limit on an account in the Locked amount checkingNew functionality in the system will also allow the option to include the Limit in the Locked amount checking. The locked amount check is done on the current balance and then on the future cashflows if there are any. If Locked amount checking with Limit is allowed, then the Limit or Balance available refers to Working.Balance or T24 Available Balance after taking the locked amount and Limit into consideration.This functionality may be set at ACCOUNT.PARAMETER, ACCT,GROUP.CONDITION or on an individual ACCOUNT record using the field LOCKED.WITH.LIMIT. The default setup is to ignore limit for locked amount processing. Priority is given to the set up at the lowest level.If this setting is set as YES, Limit will be included for Locked amount checking. If a transaction is put through in Locked account, the system will arrive at working balance by substracting locked amount from available limit.Default setting is NO where Limit is not included for checkingUSE.SESSION.NO==============This field is used to include session number in the ID for the CONSOL.UPDATE.WORK file , this file is the base file to update the CAL , By updating session number we can avoid the problem of partial updation and locking problem.BYPASS.TXN.JOURNAL=================For a Heavy volume client and if the TJ report is not used , By switch off this field will not update the TXN.JOURNAL work file , this is the base file to generate the TRANS.JOURNAL report.This is to avoid the hit in reporting job performance.BYPASS.JOURNAL.SUMFor a heavy volume client and if the EB.JOURNAL.SUMMARY is not used by the client, By switch off will not update the file EB.JOURNAL.SUMMARY.WORK. This is to avoid the hit in reporting job performance.QuestionDoes it exist any parameter in order to control on how many days in advance is computed the available balance for the above override message (for example can we shorten this period to 1 day in advance) ? AnswerIssue desc: On 17 aug 2011 we tried to debit one customer account with FT, we obtained the following override message :22/08/11 47527 OVERDRAFT ON AVAILABLE BALANCE RON -86996279.32"Explanation provided: The number of days for which the available ladder should be built can be set in CASH.FLOW.DAYS field of ACCOUNT.PARAMETER. If you want the system to check only one day forward then you can set CASH.FLOW.DAYS to 1.The override OVERDRAFT ON AVAILABLE BALANCE, will be based on the available balance ladder of the account, the updates to available balance ladder can be controled using the fields CREDIT.CHECK and AVAIABLE.BAL.UPD in ACCOUNT/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER. When CREDIT.CHECK is set to "AVAILWORK" in ACCOUNT/ACCT.GROUP.CONDITION/ACCOUNT.PARAMETER, system will check working balance of the accounts for any transaction posted to the account.When CREDIT.CHECK is set to "AVAILABLE", then UNAUTH debit movements will be updated in available balance ladder. By default system will update unauth debit movements to available balance ladder.AVAILABLE.BAL.UPD field allows the values BOTH, NONE, CREDITS or DEBITS, this specifies which type of movement should be udpated to avaialble balance ladder, whether credit movement or debit movement or both credit or debit or no update.Also we would like to let you know that when you change the no of days in CASH.FLOW.DAYS, say from 10 to 1, then the available balance ladder of the accounts should be rebuilt based on the new value. To do this kindly set the job REBUILD.AVAIL.FUNDS to 'D' daily anQuestionPREV.OPEN.BAL in the R07 release is not matching with the EB.GET.ACCT.BALANCE output in the upgraded R10 environment. AnswerIn R7 release for back dated transaction, BK.BALANCE ladder will get updated only from the booking date (today's date). But in higher release (from R10 onwards), this design has been modified. Even the BK.BALANCE ladder will get update from the back value date itself. Hence routine EB.GET.ACCT.BALANCE is returning the amount, including the total of all entries posted today with VALUE.DATE back dated beyond PREV.DATE.From R10 release onwards, to get the correct booking(trade) balance we have introduced new ladder in ACCT.ACTIVITY record - BOOKING.DAY ladder. (Fields BOOKING.DAY, BK.TRADE.DATE, BK.TRADE.TOVR.CR and BK.TRADE.TOVR.DB are part of this ladder). But this ladder will get updated only if we set the field ADJ.TRADE.DATE.BAL in the ACCOUNT.PARAMETER record to 'Y'.So to solve this problem, while you upgrade, kindly set the field ADJ.TRADE.DATE.BAL to 'Y' in the ACCOUNT.PARAMETER record. This will update the new ladder in the ACCT.ACTIVITY andQuestionCan STMT.ENT.BOOK enquiry be used to check account balances? AnswerNo, if you are in a value dated system, you should not use STMT.ENT.BOOK enquiry to check account balances, this is only for trade dated system. Use VAL.STMT.ENT.BOOK enquiry instead.QuestionACCOUNT.PARAMETER AND CREDIT.CHECK :WORKING AnswerAvailable balance override will be thrown based on the available balances in the ACCOUNT. If the CREDIT.CHECK is working and then the CASH FLOW DAYS is null , System will not update the ladder balances and it will not throw the overrideQuestionPurpose of CASH.FLOW.DAYS in ACCOUNT.PARAMETER AnswerACCOUNT>AVAILABLE LADDER will be updated based on the setting in ACCOUNT.PARAMETER>CASH.FLOW.DAYS. Setting ACCOUNT.PARAMETER>CASH.FLOW.DAYS to (null) will not update available ladder of the customer accounts (for NOSTRO accounts, CASH.FLOW.DAYS will be considered as 10 days even if the field is blank) and hence the override OVERDRAFT ON AVAILABLE BALANCE override will not be raised. QuestionAccount opening and closing by month required, we need to know is there any existing report. AnswerIn order to achieve the requirement, kindly change the frequency of the Account to M01 (Monthly once) in the ACCOUNT.STATEMENT record, so that the AC.STMT.HANDOFF record will be generated with FROM.DATE and TO.DATE once in a month based on the frequency set.During that frequency end date's COB, system will generate Account statement report with Opening balance and Closing balance by month.QuestionAllow netting not working when limit record attached to the account has zero as overdraft limit AnswerAs per the functionality, Limit record should have limit amount. If limit record does not contain any balance then its not considered as valid limit record. Since overdraft limit amount is "0", system not netting the account balances belongs to the customer.System throws the override message even though customer has funds in other accounts. In order to net the account balances limit record shoulQuestionWill there be any impact when changing the category of an account from normal savings to staff savings? AnswerThe result of changing the category will be a change in account group (consol key). But this change will not happen online and will happen only during COB. There will be no impact because the account will be removed from the old link file and added to the new consol key and the CAL balance changes accordingly.QuestionAccount not overdrawn as seen in STMT.ENT.BOOK but interest debited for the customer AnswerIn order to get the balance and entry listing with reference to interest calculation, we request you to use the field PROCESSING.DATE instead of BOOKING.DATE in the enquiry STMT.ENT.BOOK. This will list entries as per the processing date/value date since the interest calculated based on value date.QuestionIn an account closure, the system reports override: CALCULATED INTEREST MAY BE INACCURATE-ENTRIES POSTED TODAY. If we accept it, how do we know the interest is correct? AnswerThe override "CALCULATED INTEREST MAY BE INACCURATE - ENTRIES POSTED TODAY" is actually for informative purpose only and this won't affect your ACCOUNT closing whatsoever.While committing the ACCOUNT.CLOSURE record, the system will consider balances up to the previous day and post interest accordingly. It will also check if there are any entries for this account in the ACCT.ENT.TODAY file. If so, then the override 'CALCULATED INTEREST MAY BE INACCURATE - ENTRIES POSTED TODAY' will appear for your information. Its because, the account balance will be updated during EOD and based on the ONLINE.ACTUAL.BAL interest amount is calculated and updated in the field TOTAL.CR.INTEREST/DEBIT in the ACCOUNT.CLOSURE record.But anyway the entries for the account in the ACCT.ENT.TODAY file will get processed during today's EOD, hence the amount for these entries will reflect the account balances only during EOD. Capitalization of the interest for this closing account will happen during EOD based on the calculated account balances.QuestionWe would like to know the format of internal account ids in multi-company and multi-book environment AnswerMulti-Company internal accounts ================================ Format is CCY-CATEG-NNNN CCY - is the currency code CATEG - is the 5 digit category code NNNN - is 4 digit sequence number between 0001 to 9999 Here the sequence number part can be any number between 0001 to 9999 and it is not dependent to the Company sub-division code. Consider an account USD100010001, this account can be created in BNK and in FCB but both are different accounts and will be located physically under different files FXXX.ACCOUNT Interco accounts - For the case of balance inter-company internal accounts, the sequence number (NNNN) identifies the other company involved in the transaction. Eg, USD128002000 in BNK refer to the Interco account residing in BNK and that will be used if transactions happen between BNK and 2000 (FCB) Multi-Book internal accounts ============================= Format is CCY-CATEG-NNNN-xxxx CCY - is the currency code CATEG - is the 5 digit category code NNNN - is 4 digit sequence number between 0001 to 9999 xxxx - is the branch sub-division code Here xxxx is the branch sub-division code and this will be unique for each branch. Consider an account USD1000100011005, this account belongs to the branch 1005 (RAJ) and the same account cannot be used in any other branch. Interco accounts - In a multi-book system, for Interco accounts, the NNNN and xxxx part are under to identify the branches involved in the transaction. Consider the account, USD-12800-1005-0001, here NNNN = 1005 is the other branch code (RAJ) involved in the transaction and xxxx = 0001 identifies the branch to which this account belongs.QuestionWhen i try to reverse the ACCOUNT.CREDIT.INT/ADI/GCI/GDI the system throws the error "REVERSAL NOT ALLOWED FOR THIS RECORD ID". AnswerKindly note that according to the T24 functionality the system will not allow the reversal of the last ACCOUNT.DEBIT.INT record. For example , if there are four ACCOUNT.DEBIT.INT records as follows,10693-20090302 10693-20090402 10693-20090502 10693-20090602 Then the system will allow the reversal of the records 10693-20090602, 10693-20090502, 10693-20090402 but will not allow the reversal of last record 10693-20090302. In case if you like the system not to follow this ACCOUNT.DEBIT.INT (100000017797-20100801) record but to follow the GROUP.DEBIT.INT record then in the field INTEREST.DAY.BASIS of the ACCOUNT.DEBIT.INT specify the value as G (GENERAL). Account Debit Interest SEE ACCOUNT.NO.DATE... 10693 - 03 APR 2009 Michael Dell ------------------------------------------------------------------------------ 1 CHARGE.KEY........ 33 NO CHARGES 2 INTEREST.DAY.BASIS G GENERAL ===> By setting this value the system will follow the GROUP.DEBIT.INT and not this ACCOUNT.DEBIT.INT 4 DR.BALANCE.TYPE... DAILY 5 DR.CALCUL.TYPE.... LEVEL 7. 1 DR.INT.RATE.... 15.00 22 APR.REQUIRED...... NO 36 CURR.NO........... 1 ------------------------------------Questionis it possible to achieving the report with the Lines descriptions and details such as actual account numbers instead of the consol key on the report AnswerIt is not possible to print the account numbers in the reports instead of consol keys. As per the T24 functionality, the CRF report will displays only the consol keys & it does not shows the Account balance in the CRF report. This is also applicable for PC report. Hence it is not possible to have the account details in CRF report.Also, please be noted that for PC database we can generate only CRF & CRC report. we cannot generate CRB report. QuestionWe want to develop a local enquiry, which will fetch the entries for a particular account and for a particular date. Can we make use any core routines to achieve this functionality? AnswerTo fetch the statement entries for a particular account for the particular time period, the following core routine EB.ACCT.ENTRY.LIST can be used instead of the routine E.STMT.ENQ.BY.CONCAT. The core routine EB.ACCT.ENTRY.LIST returns the OPENING BALANCE of the account for the given start date and the statement entries for the mentioned period( START.DATE to END.DATE).QuestionIf every transaction on FBNK.STMT.ENTRY should found in STMT.ACCT.CR or STMT.ACCT.DR ? AnswerSTMT.ACCT.CR/DR , this file holds the details of interest capitalisation detailsEvery transaction STMT.ENTRY will be updated in the STMT.PRINTED file , By selecting this file we can fetch the STMT.ENTRY.In core an routine is used to fetch the entries from STMT.PRINTED SUBROUTINE EB.ACCT.ENTRY.LIST(ACCOUNT.NUMBER,FROM.DATE,END.DATE,YID.LIST,OPENING.BAL,ER)** Passed Parameters.** ACCOUNT.NUMBER :- Account for which balance & entries is to be returned.* FROM.DATE :- Start date for opening balance and entries.* END.DATE :- The last date to be considered.** Outgoing :* ==========** YID.LIST :- List of statement entry ids.* OPENING.BAL :- Opening balance on the startt date.* ER :- Any errors foundQuestionACCT.ENT.TODAY not raised AnswerSetting the field ENT.TODAY.UPDATE to "YES" in ACCOUNT.PARAMETER will make the system to update the ACCT.ENT.TODAY file. This will contain the account wise entries inputted on TODAY's date. In COB, system will update OPEN.ACTUAL.BALANCE and OPEN.CLEARED.BALANCE , based on the entries in ACCT.ENT.TODAY file. QuestionExplain the functionality of position accounting with an example? AnswerThe functionality of position accounting with an example. Consider two position accounts is updated for the transaction involving buying of 100USD by selling 200GBP. Note: Here GBP is considered as local currency. Position accounts hold value as shown: POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -200 GBPUSD140160201000 -200 100 Now the exchange rate for USD is changed. On running COB, revaluation for USD is processed. Say, due to revaluation Position account will have a balance of GBP 250 which reflects correctly the new price of the USD position of 100 USD at the new price. POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -250 GBPUSD140160201000 -200 100 For achieving this, system will revalue the local equivalent of the USDGBP account and post revalued amount to the GBPUSD account. The corresponding opposite leg will be posted in P&L. This will happen for all the NC position accounts. For forward FX, since the contract contributes to the off balance GL, separate category is used for position account (19022). In this case, the USDGBP CAL will be revalued. But the GBPUSD posting will not happen as the posting to P&L will be carried on with FX revaluation of unrealized profit which will be carried out based on forward position. This is the functionality of position accounts for forward FX. QuestionExplain the functionality of position accounting with an example? AnswerThe functionality of position accounting with an example. Consider two position accounts is updated for the transaction involving buying of 100USD by selling 200GBP. Note: Here GBP is considered as local currency. Position accounts hold value as shown: POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -200 GBPUSD140160201000 -200 100 Now the exchange rate for USD is changed. On running COB, revaluation for USD is processed. Say, due to revaluation Position account will have a balance of GBP 250 which reflects correctly the new price of the USD position of 100 USD at the new price. POSITION ACCOUNT AMT1 AMT USDGBP140160201000 100 -250 GBPUSD140160201000 -200 100 For achieving this, system will revalue the local equivalent of the USDGBP account and post revalued amount to the GBPUSD account. The corresponding opposite leg will be posted in P&L. This will happen for all the NC position accounts. For forward FX, since the contract contributes to the off balance GL, separate category is used for position account (19022). In this case, the USDGBP CAL will be revalued. But the GBPUSD posting will not happen as the posting to P&L will be carried on with FX revaluation of unrealized profit which will be carried out based on forward position. This is the functionality of position accounts for forward FX. QuestionCan the accounts category be amended? What are the implications? AnswerYes, accounts category can be changed. Following are the implications of changing the category: I) Condition group of Account will change based on new category. II) Change in CONDITION.GROUP will affect the Cr & Dr interest rate. III) Consol key of account may change based on new category. IV) Balance in old CAL will be moved to new CAL.QuestionWhen will the commitment available amount increase? AnswerWhen LD loan under LD revolving commitment contract goes to PD in amount type PR during batch or online, the commitment available amount is not increased.The commitment available is increased only when LD loan is paid by debiting account or PD PR has been paid in PD module.Whenever PRIN.INCREASE is done in LD LOAN contract, the balance in the account is checked and depending upon the availability of funds, appropriate override message is generated. Under no circumstances, PD record is created or updated for PRIN.INCREASE operation.The principal decrease in LD contract does not generate or update PD contract. Instead, irrespective of the liquidation mode, if balance is available in the liquidation account STMT.ENTRY is generated. If not, suitable override message is given by the system.This functionality is available only from the release R09QuestionWhat are SGN entries and why they are raised AnswerQuery: 1) Why are the Special Entry records made? At which situation could we expect more of these entries?Response: 1. If the Closing balance of particular account changes from CREDIT to DEBIT or from DEBIT to CREDIT, when compared to the previous days closing balance, then system will raise SGN entries during the subsequent COB.Query: Is it possible to configure T24 not to make these SGN entries.Response: 2. These entries are raised in order to update the correct asset type based on current balance. These entries are essential for T24 as per its current architecture and for the proper updation of the files EB.CONTRACT.BALANCES and CAL.QuestionRE.CONSOL.SPEC.ENTRY with transaction code SGN meaning AnswerFor example : Account having the balance of DEBIT asset typeDay 1:DEBIT asset type in CALDay 2:By depositing cash makes the balances as CREDITDuring DAY2 COB , System reverse the DEBIT asset in CAL andupdate the CREDIT balance under CREDIT asset type in CAL. For this changes SGN entries will be raised , there will not be any corresponding STMT.ENTRY.QuestionThe effects of changing this field in ACCT.GROUP.CONDITION from AVAILABLE to WORKING AnswerSetting the CREDIT.CHECK to blank or WORKING in ACCT.GROUP.CONDITION, the Available funds will be updated with all transactions, except unauthorised credits and Overdraft check uses only working balance for this group of accounts.Future cash flow check uses the Available balance ladder as from the value/exposure date of the transaction.QuestionPL CLOSE OUT process work flow prior and after R08 AnswerThe year end process has been changed from r08 release. Kindly find the below process in lower release and the higher release.Below R08:1. The system will close the CPL by posting the reversal entry(CATEG.ENTRY) for each group of CPL key balances.2. Consolidated PL closing balances of that respective year will be directly updated to the balance of the PL category 69999.3. Then the system will post the CATEG.ENTRY to move the consolidated closing amount (one for CREDIT and the other for DEBIT) from PL category 69999 to the PL CLOSE category account by raising the STMT.ENTRY.From R08:The system will close the CPL by posting the reversal entry(CATEG.ENTRY) for each group of CPL key balances and the balance will moved to the PL CLOSE category account by posting a STMT.ENTRY.Example :Hope the below example will be more clear.Consider,CPL balance pertaining to group 1 = 1000 USDCPL balance pertaining to group 2 = 500 USDThen, in the lower releases,a) The system will post a CATEG.ENTRY for -1000 USD to the group 1 category.b) The CATEG.ENTRY will be posted for -500 USD to the group 2 category.b) 1500 USD will be directly updated to the category 69999 without any entry.c) Then the CATEG.ENTRY will be posted for the amount -1500 to the 6999 category and a STMT.ENTRY will be posted for 1500 USD to the PL CLOSE category account.In higher release,a) 1000 USD pertaining to the group 1 category will be moved to the PL CLOSE category by post a CATEG.ENTRY for -1000 USD to the group 1 category and a STMT.ENTRY for 1000 USD to the PL CLOSE category.b) Similarly 500 USD pertaining to the group 2 category will be moved to the PL CLOSE category by post a CATEG.ENTRY for -500 USD to the group 2 category and a STMT.ENTRY for 500 USD to the PL CLOSE categQuestionAccrued interest and capitalized interest for LD.LOANS.AND.DEPOSITS AnswerTo get the Interest amount Already Capitalized: FIELD NO 38. = INT.RECEIVED (LMM.SCHEDULES.PAST ) This field gives the interest amount that has been collected from the customer. To get the Daily Outstanding Balance for LD: FIELD NO 11 = OUTS.ACCRUED.INT (LMM.ACCOUNT.BALANCES) : This field holds the balance of accrued interest, that is yet to receive from the customer. Often called 'interest earned not collected' and current interest receivable'. QuestionWhat is the need for EB.FINANCIAL.SYSTEM? AnswerThe purpose of EB.FINANCIAL.SYSTEM, is to handle the creation of unbalanced accounting entry. Based on the setup done in this table, system will either throw error the accounting entries created by transaction is not balanced (or) will create an automatic balancing entry for internal account category defined.You can balance the COB entries and/or online entries based on the flag set in the below fields. 3. 1 AUTO.BL.SYS.ONL Y 4. 1 AUTO.BL.SYS.COB YA category must be reserved for only posting such self-balancing entry. And a local currency internal account must exist for this category. If you choose to balance accounting entry automatically, then this internal account will be used to post the balancing entry. 6. 1 BALANCING.CAT.. 14012The balancing entry created will have the below transaction code. 7. 2 BLNCING.TXN.CDE 11If you do not want to create self-balancing entry, set the fields AUTO.BL.SYS.ONL & AUTO.BL.SYS.COB to NO. In this case, system will create fatal error for transactions producing unbalance accounting entry.If you set the fields to Y, in event of unbalanced transactions (assume FT transaction has produce only credit entry), system will create a self-balancing entry. A message like "Self Balancing Entry Raised Contract" will be registered in EB.EOD.ERROR for creating self-balancing entry.QuestionPenal Charges on Recurring deposits AnswerPenal charges on a recurring deposit are processed during COB by the batch job AZ.FIND.LATE.PAYMENT. Defaulted repayment schedules are identified by comparing the scheduled balance for the date with the actual working balance of the account. Also, the defaulted schedule amounts are populated in the fields LAST.PAY.DATE and AMOUNT.DUE in the AZ.SCHEDULES record. Penal charges in AZ are calculated based on the setup in the corresponding AZ.PRODUCT.PARAMETER. The following fields are referred to in AZ.PRODUCT.PARAMETER while processing penal charges. LIAB.TO.PENALTY - Based on the value given under this field, the number of delayed instalments liable to penalty will be arrived and corresponding charges defined under LATE.PMT.FEE will be charged. Numbers specified in this field refers to number of instalments. For example, if 2 is defined here, the account will be liable for late fee after 2 instalments are missed. LATE.PYMT.FEE - Defines the charges to be levied on the Savings Plan/ Recurring Deposit type of accounts for having paid the instalments late. Based on the value given under LIAB.TO.PENALTY, the delayed instalQuestionWhat are the possible values of CRF TYPE field in STMT.ENTRY and their scenarios/explanations. AnswerFor account related asset types are Offbalance Sheet Accounts indicated by CONTINGENT.INT fieldOFFSUSP - Suspensed(INT.NO.BOOKING set) OFFDB - < zero OFFCR - > zeroOn Balance Sheet SUSPENS - SuspensedDEBIT - > zeroCREDIT - < zeroQuestionHow does the concept of Balanced Accounting Entries work? AnswerT24 follows double entry book keeping principles with a single base currency. Applications should therefore provide financial movements that net to zero in local currency. There is currently no validation that the application supplies balanced entries.If unbalanced accounting entries are generated it can result in an out of balance financial system that requires a manual data correction procedures. QuestionWhat are the entries involved during EB.COMPANY.CHANGE? AnswerWhenever we move contracts/account from one company to another using EB.COMPANY.CHANGE, system will raise RE.CONSOL.SPEC.ENTRY with TRANSACTION.CODE eq 'APP' for the new company and old company. Along with these entries system will raise STMT.ENTRY against the interco category (interco-entries)to keep the GL of each company in balance.QuestionWhen one loan goes into overdue, then the other loans of the same customer need to be classified as past due ? AnswerAs per the existing T24 functionality the Past due will be created when LIQUIDATION.MODE in underlying contract is set as Semi-automatic or Manual. If the LIQUIDATION.MODE is set as Semi-automatic and the corresponding Liquidation Account doesnt have enough balance to repay the contract then the system will create the PD for the remaining amount for the underlying contract.If the LIQUIDATION.MODE is set as Manual then it will not consider the Liquidation Account, the system will directly create the PD for the schedule amount for the underlying contract. It is not possible to create the PD records for all the LD contract of the customer when a PD record is created for one LD contract of that same customer. So it is not possible with the existing designQuestionIn Treasury menu model bank, core have enquiry nostro (ENQ NOSTRO.SUMMARY and ENQ NOSTRO.POSITION). Can you explain us, what function for this enquiry and can you guide how to trace from where system take the balances? AnswerENQ NOSTRO.SUMMARYThe ENQ NOSTRO.SUMMARY will display the consolidated balance Nostro accounts on Currency wise for the next five working days from current date by picking details from the available ladder of the Account (fields 149 - 156). ENQ NOSTRO.POSITIONThe ENQ NOSTRO.POSITION is the next level enquiry to be invoked when descending the enquiry levels of the ENQ NOSTRO.SUMMARY, displaying the next five working days Nostro balances of the respective banks Currency wise from the available ladder of the Account.This can also be launched separately without drilling down from the ENQ NOSTRO.SUMMARY for the specified currency in the selection criteria.QuestionHow does the system act for unexecuted standing order with type FI? AnswerIf a Standing Order fails due to insufficient funds (System will check STO amount with the Account balances), the associated funds transfer record generated is placed on hold status pending manual intervention.Standing Orders can be set for automatic resubmission if failure is due to insufficient funds. Two methods exist to retry process. These methods can be combined to create a continuous retry process that runs all day every day until funds become available or until the limit of 10 days is reached. The maximum limit at the moment is only 10 days.Method 1: Daily resubmission is enabled in FT.APPL.DEFAULT by entering a value for the number of days in the field NO.RESUBMSSN.DAYS. This field will allow the maximum 10 days of resubmission. For up to 10 days maximum within the COB batch processing daily system will check the availability of funds. When the retry limit is reached without sufficient funds, the funds transfer record is created in hold, and T24 can generate a delivery advice message to this effect. The message to be used is specified in FT.APPL.DEFAULT application SO.MESSAGE.TYPE field value.Method 2: We can enable online resubmission of STO by specifying RETRY.START.TIME and RETRY.END.TIME in a 24-hour clock notation, within the FT.APPL.DEFAULT record. To start the online process the EB.SO.RETRY.CHECK record in EB.PHANTOM needs to be verified. This record contains the field parameter SLEEP.SECS to allow the user to indicate a time interval in seconds between retry attempts. For example, to retry failed Standing Orders every hour enter an interval of 3600 (60 seconds x 60 minutes). If any moment in the account balances of the STO then this phantom will check the STO balance with the account balance and if sufficient funds are available to process STO system will execute the STO.When the retry limit is reached without sufficient funds, the funds transfer record is created in hold as before, and T24 can generate a delivery advice message to this effect. The message to be used is specified in FT.APPL.DEFAULT application SO.MESSAGE.TYPE field value.QuestionWhat is the purpose of Dummy entries created in STMT.ENTRY file, how and why are they generated? AnswerWhen you are running a stmt.entry related enquiry (eg. STMT.ENT.BOOK or STMT.ENT.VALUE), stmt.entry will be generated with id as DUMMY in below scenarios.i. When enquiry launched for the account that doesn't exist in the system.ii. When enquiry launched for an existing account and the selected date doesn't hold any entries. The enquiry is designed in such a way to display the balance at period. start and period. end to '0'. In order to achieve this, a DUMMY STMT.ENTRY id is generated. If you want to remove the DUMMY stmt.entry records from the STMT.ENTRY file, you can do the below from your jbase prompt.Replace 'XXX' with the company mnemonic.Jsh>SELECT FXXX.STMT.ENTRY WITH @ID LIKE DUMMYXX records selected.>DELETE FXXX.STMT.ENTRYXX records deleted.QuestionPlease explain the difference between the CRB and CRD report? AnswerCRB reports are based upon the flat CRF report but contain details of the individual contracts and accounts that make up each line. The CRB report will have the line balances, as well as the contract balances. It has the Asset & Liabilities and Profit & Loss related information and CONTRACT level details.CRD reports are the investigation reports that provide details of mismatches between CAL key level balances and underlying Contract / Account level balances for a particular line or lines on a report. The CRD report is classified into two types RE.STAT.MISMATCH and RE.STAT.BAL.RECRE.STAT.MISMATCH - Reports the consol key which is having difference between ECB and CAL balances.RE.STAT.BAL.REC - Reports the consol key and contract balances related to all the lines. It also reports the balance mismatchQuestionWe are unable to modify the existing record MONTHLY from STMT.GEN.CONDITION. System throws the error CONDITION EXIST ERROR MESSAGE. How to rectify this? AnswerThe error will be shown because of the following two reasons:a) The value(CATEGORY) entered the field VALUE has been already used in the other STMT.GEN.CONDITION recordsb) If there is only one value(CATEGORY) in the record and if you try to delete that category and authorize the same will result in the same error.Instead of deleting the value from the record where there is only one value, kindly reverse the particular record (MONTHLY). After reversing the record, kindly delete the value from the concat file FXXX.STMT.GEN.COND.PRTYEg., >JED FXXX.STMT.GEN.COND.PRTY 19900001 }]MONTHLYAfter this press ESC and type FD. This will delete the particular recordQuestionWhat is the need for running REGEN? AnswerFor generation of CONSOLIDATE.ASST.LIAB (CAL) and CONSOLIDATE.PRFT.LOSS (CPL) keys, we will be using the application CONSOLIDATE.COND. Whenever there are any changes made in the CONSOLIDATE.COND record, then there will be changes in the CAL and CPL keys. Also there will be an impact in the system, the same contract or account balance will be present under 2 consol keys.In order to resolve the problem we need to run the REGEN, to move the balances from the old keys to new key. When we make any changes in CONSOLIDATE.COND record which are ASSET&LIAB or PROFIT&LOSS and if there is no CAL and CPL key present in the system, then there is no need of running the REGEN, since changes are done in an empty database.But when we make any changes in CONSOLIDATE.COND record which are ASSET&LIAB or PROFIT&LOSS and if there are CAL and CPL keys present in the system, then we need to run REGEN in order to change the format of the CAL and CPL keys.QuestionWhat is the use of field CAP.INT plus REPAY.CAP set to YES for an LD contract? Please explain with an example. AnswerCAP.INT is a capitalisation flag in LD.SCHEDULE.DEFINE record to identify interest capitalisation so that for every I schedule, the user can set a flag to indicate whether that particular I schedule should be capitalised or not. If CAP.INT set to YES for particular I-Schedule then it is added to the corresponding Principal Schedule. If set to NULL then interest will be debited from the Customer account. Consider below example: ---------------------------- CAP.INT in LD.SCHEDULE.DEFINE for each I schedule TRANSACTION DATE AMOUNT BALANCE CAP.INT Loan Drawdown 30/6/04 500,000.00 500,000.00 Interest Capitalised 1/8/04 2,191,78 502,191.78 CAP.INT set to YES. So interest is capitalised with Principal Payment 1/8/04 (2,500.00) 499,691.78 Interest 1/9/04 2,121.98 499,691.78 CAP.INT is NULL So interest is not capitalised. Payment 1/9/04 (2,500.00) 497191.78 The field REPAY.CAP has no impact on CAP.INT field. If field REPAY.CAP is set to YES then CAPITALISATION field cannot be set to YES. If CAP.INT field set to YES then CAPITALISATION field cannot be set to YES. QuestionWhat are the entries involved during EB.COMPANY.CHANGE? AnswerWhenever we move contracts/account from one company to another using EB.COMPANY.CHANGE, system will raise RE.CONSOL.SPEC.ENTRY with TRANSACTION.CODE eq 'APP' for the new company and old company. Along with these entries system will raise STMT.ENTRY against the interco category (interco-entries)to keep the GL of each company in balance.How to create user-defined OVERRIDE and use it with OVERRIDE.CLASS.DETAILS

How to create user-defined OVERRIDE and use it with OVERRIDE.CLASS.DETAILS?PurposeThisdocument describesthe creation of user-defined OVERRIDE and its setup using OVERRIDE.CLASS.DETAILS.This setup is used where a user's accessto input some kind of transaction and not to authorize transactions which have some specific overrides.The OVERRIDE.CLASS.DETAILS setup is used to give permission to users to authorize the transactions based on value entered in corresponding field.ProcedureApplicable and Involvement T24 Release applicableFrom G13 Onwards

No of steps involved12

Applications/Files involved EB.API, PGM.FILE, VERSION, OVERRIDE, OVERRIDE.CLASS.DETAILS and USER

The following steps are used tocreate user-defined OVERRIDE and set OVERRIDE.CLASS.DETAILS for a specific field.The user defined OVERRIDE is triggered in INPUT.ROUTINE by comparing the corresponding field value of the current application with field value of the relevant application.Step 1: Compile and catalog the INPUT ROUTINE - TEST.AUTH (Sample routine) * Local input routine to raise OVERRIDE message based on the DEBIT.AMOUNT * Field in the FT record. SUBROUTINE TEST.AUTH $INSERT I_COMMON $INSERT I_EQUATE $INSERT I_F.FUNDS.TRANSFER $INSERT I_F.ACCOUNT GOSUB INITIALISATION GOSUB PROCESSINITIALISATION: FN.FT="F.FUNDS.TRANSFER" F.FT="" FN.AC="F.ACCOUNT" F.AC="" RETURNPROCESS: CALL OPF(FN.FT,F.FT) CRT "FT ID":ID.NEW ACCID=R.NEW(FT.DEBIT.ACCT.NO)*assign the DEBIT.ACCT.NO to variable ACCID CALL OPF(FN.AC,F.AC) CALL F.READ(FN.AC,ACCID,R.AC,F.AC,Y.ERR)*Read the corresponding DEBIT.ACCT.NO record to R.AC DEBAMT=R.NEW(FT.DEBIT.AMOUNT) *assign the DEBIT.AMOUNT to variable DEBAMT AMTINACC=R.AC *assign the DEBIT.ACCTs WORKING.BALANCE to variable AMTINACC*Here we are checking whether the transaction amount is greater than the *account balance and TEXT is the common variable which is used to build the *values to the OVERRIDE which is to be generated.IF DEBAMT > AMTINACC THEN TEXT="ACCT.NEW.OVERRIDE"*Passing the values to the OVERRIDE message TEXT = R.AC:VM:ABS(DEBAMT): VM :ACCID TEXT = R.AC TEXT = ABS(DEBAMT) TEXT = ACCID TEXT = R.AC CURR.NO=1 CALL STORE.OVERRIDE(CURR.NO)END RETURN

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

Step 3: Create a record in PGM.FILE for input routine TEST.AUTHStep 4: Create a VERSION record for FUNDS.TRANSFER application and attach the INPUT routineStep 5: Create a new OVERRIDE.CLASS.DETAILS record NEWOVERStep 6: Create a new OVERRIDE record ACCT.NEW.OVERRIDE and attach OVERRIDE.CLASS.DETAILS to Detail.1 field:Step 7: Create USER - USER1(ANAND11) USER1 has rights to approve the ACCT.NEW.OVERRIDE override. OVERRIDE.CLASS field of this USER record has value EMP1. Hence USER1 can approve this override when the transaction amount falls between 1 and 50000 Step 8: Create USER - USER2(ANAND12) USER2 has rights to approve the ACCT.NEW.OVERRIDE override. OVERRIDE.CLASS field of this USER record has value EMP1 and EMP2. Hence USER2 can approve this override when the overdraft amount falls between 1 to 100000.

Step 9: CREATE USER - USER3(INPUTTER)USER3 has rights to approve the ACCT.NEW.OVERRIDE override .OVERRIDE.CLASS field of this User record has value EMP1,EMP2 and EMP3. Hence USER3 can approve this override when the transaction amount falls between 1 and 500000.Step 10:USER1(ANAND11) inputs a FT (for with DEBIT.AMOUNT for 75,000) and on validating the transaction, the local override ACCT.NEW.OVERRIDE is generated and when the record is tried to authorized using USER1(ANAND11), the record is moved to INAO status.

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