T24 Development: Technical Specification

Technical Specification
T24 Development SAR number: SAR Reference
T24 Development
Technical Specification For Internal Use Only
SAR Reference: 56323
SAR Description: Due Processing
Client Name: Internal
Client Reference: Client Ref
Amendment History:
Revision Date Amended Name Description

1.0 05-06-2010 R.Gayathri Original version
No part of this document may be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without the express written permission of Temenos.
Information in this document is subject to change without notice.
Trademarks
UNIX® is a registered trademark of UNIX System Laboratories Inc.
T24® and jBASE® are registered trademarks of TEMENOS Holdings NV.
Oracle ® is a registered trademark of Oracle Corporation.
All other trademarks are the property of their respective owners.
Copyright  2007 Temenos. All rights reserved.
Table of Contents
1. Introduction------------------------------------------------------------------------------------------5
1.1 Existing System Overview............................................................................................5
1.2 New Requirements Overview.......................................................................................6
1.3 Workflow......................................................................................................................6
1.4 Considerations...............................................................................................................7
1.5 Example Output............................................................................................................7
2. Table Layouts-----------------------------------------------------------------------------------------8
2.1 New Tables...................................................................................................................8
2.2 Modified Tables............................................................................................................9
2.3 Conversion....................................................................................................................9
3. Server Program and Data Modifications-------------------------------------------------------10
3.1 AA.BUILD.PERIODIC.CHARGE.DATES............Error! Bookmark not defined.
3.2 AA.CHARGE.ACT.MAKE.DUE.............................Error! Bookmark not defined.
3.3 AA.BUILD.PROCESS.DETAILS...........................Error! Bookmark not defined.
3.4 AA.CHARGE.ISSUE.BILL.....................................Error! Bookmark not defined.
3.5 AA.UPDATE.PAYMENT.SCHEDULE.DATE......Error! Bookmark not defined.
3.6 AA.CHECK.BASE.BALANCE...............................Error! Bookmark not defined.
3.7 AA.GET.ACTIVITY.LIST........................................Error! Bookmark not defined.
3.8 AA.GET.PAYMENT.SCHEDULE.DATE..............Error! Bookmark not defined.
3.9 AA.PAYMENT.RULES.CREATE.DUE................Error! Bookmark not defined.
3.10 AA.PAYMENT.SCHEDULE.ISSUE.BILL............Error! Bookmark not defined.
3.11 AA.PAYMENT.SCHEDULE.MANAGER.............Error! Bookmark not defined.
3.12 AA.SETTLEMENT.SETTLE....................................................................................10
3.13 AA.GET.PAYMENT.TYPE.DUE.AMOUNT...........................................................14
3.14 AA.GET.SETTLEMENT.LINKED.ACCT.BAL......................................................17
3.15 AA.GET.SETT.ACCT.RULE.TYPE.BALANCE....................................................20
3.16 AA.PARSE.DUES.AGAINST.SETT.ACCOUNTS...............................................22
4. Client Program and Data Modifications-------------------------------------------------------25
4.1 XSL.............................................................................................................................25
4.1.1 Program Name 1.............................................................................................25
4.2 Static HTML...............................................................................................................25
4.3 JavaScript....................................................................................................................25
4.4 Skins............................................................................................................................25
4.5 Java..............................................................................................................................25
4.6 XML Templates..........................................................................................................25
4.7 Configuration files......................................................................................................26
4.8 Images.........................................................................................................................26
5. Processing Modifications--------------------------------------------------------------------------27
5.1 Delivery.......................................................................................................................27
5.2 Batch Processing.........................................................................................................27
5.2.1 New Batch Job...............................................................................................27
5.2.2 New Batch Processes.....................................................................................27
5.3 EURO Considerations ................................................................................................27
5.4 Miscellaneous .............................................................................................................27
6. Documentation---------------------------------------------------------------------------------------28
6.1 User Guide & Release Notes......................................................................................28
6.2 Help Text....................................................................................................................28
7. Testing Considerations-----------------------------------------------------------------------------29
7.1 Online..........................................................................................................................29
7.2 Close of Business........................................................................................................29
1. Introduction
1.1 Existing System Overview
This SAR is a part of MTR3b – Requirements, which aims at complete movement of all
retail products from the legacy T24 modules into AA.
Specifically, this enhancement will cover SETTLEMENT DUE PROCESSING. This
covers the option to specifying accounts for the liquidation of PRINCIPLE/ INTERET/
CHARGE.
Currently in ACCOUNT module, user has an option to specify either a single settlement
account for all interest or can specify settlement accounts by interest type.
Following are the fields used by ACCOUNT module, for liquidation account
specification,
Field Description
Identifies the Customer Account to which ALL
INTEREST.LIQU.ACCT
interest is to be capitalized (booked).
Specifies the type of interest to be liquidated.
XX< INT.LIQU.TYPE
DR, CR, DR1, DR2, CR1, CR2
Specifies the interest liquidation account for the
XX- INT.LIQU.ACCT
type specified.
The currency of the liquidation account (can be different
XX> INT.LIQ.CCY
from the main account)
Identifies the customer account to which all charges will be
XX< CHARGE.ACCOUNT
capitalised
The currency of the charge account (can be different from
XX- CHARGE.CCY
the main account)
XX> CHARGE.MKT The currency market of the charge account.
Currently in AA module, the Settlement Property Class allows a user to specify a Direct
Debit mandate per Payment Type in order to receive funds from another account.
There is no provision for specifying either an internal account to receive funds from or a
method of specifying any account to pay funds to (i.e. liquidate).
When the current Settlement Property Class was designed, the only requirement was to
provide the same functionality which existed in the MG module.
As such it was designed only with the ability to link one or more Payment Types to Direct
Debit mandates.
1.2 New Requirements Overview
The SETTLEMENT property class DUE processing will be enhanced to do the following
,
1. Receiving funds from an account in T24.
2. Specifying settlement instruction based upon Payment Type.
3. On Loan Repayment the process sequence will be
o Make Due
o Try to apply repayment according to Settlement Instructions
o Repay and make remaining (if any) as ‘Due’
4. Regarding funding of AA Deposit
o Funding of deposits needs to be supported once a Deposit arrangement is

authorised.
o The sequence of funding will be
o Update Expected balance
o Try to fund from the source account according to settlement instruction
o Pay and leave remaining in “Expected” as applicable
5. Similar settlement instructions like disbursement of loan and maturity processing will
be handled by another sar PAY OUT processing .
6. The process of settlement of DUES should follow the account debit rule as specified
below,
o Partial: Take the 1000 and go to the next account. If not, make remaining as due.
o Full: Overdraw the source account and pay outstanding in Full.
o None: If required amount is not available, then full outstanding is left as ‘Due’.
1.3 Workflow
The scope of this SAR is to bring settlement instruction processing into AA.
Workflow for due processing,
o New action routine will be written in the MAKE.DUE activity class.
o This action routine will call a new activity class PRODUCT.LINE-SETTLE-
ARRANGEMENT.
o This new activity class will have a single action routine

AA.SETTLEMENT.SETTLE inside it.
o AA.SETTLEMENT.SETTLE will find all the dues of the arrangement and will
allocate funds from the account defined for settlement after validating the account
debit rule.
o Once the fund allocation is over, this routine it self will raise the debit entry for
the customer side and credit will be on suspense account.
o This action routine will also update the AA.ACTIVITY.BALANCES which will
be used for reversal processing.
o Once entries are raised, this routine will trigger an APPLY PAYMENT secondary
activity with activity as defined in the field
SETTLEMENT>PAY.IN.SETT.ACTIVITY.
o Thus apply payment activity will take care of settlement against the arrangement
due balances.
1.4 Considerations
Limitations of this Sar.

o Currency based settlement instruction will be developed separately.
o Linking arrangement account for settlement will be developed separately.
o Pay processing settlement will be developed using separate SAR.
o Retry settlement processing is not in the scope of this SAR.
o Settlement of dues according to the balance type is not in the scope of this SAR.
o Unallocated credits amount consideration inside the settlement will be developed
separately.
1.5 Example Output

2. Table Layouts
2.1 New Tables
Table Name

Description
Product
Classification
Field Name Type Description

SAR Reference 8 50858069.doc

2.2 Modified Tables
Table Name

Description
Product
Classification
Field Name Type Description

2.3 Conversion


3. Server Program and Data Modifications
3.1 AA.SETTLEMENT.SETTLE
1. This routine will be an action routine for the new activity LENDING-SETTLE-SETTLEMENT.
2. This action routine will do the following,
3. The process section will call separate paragraph to process INPUT, REVERSAL, DELETE, and AUTHORISE.
4. Inside the PROCESS.INPUT.ACTION,
o Assign the value of VAL to REQD.PROCESS variable and route out to separate paragraph for PAY.IN and
PAY.OUT processing.
o Process PROCESS.SETTLE.PAY.OUT paragraph
o Process PROCESS.SETTLE.PAY.IN paragraph.
5. Inside the PROCESS.DELETE.ACTION ,
o If this is INPUT-DELETE then,
 Process PROCESS.ACTIVITY.BALANCES with PROCESS.TYPE as REVERSE .
 Process UPDATE.ACTIVITY.BALANCES paragraph.
o Process PROCESS.ACCOUNTING.UPDATES with REQD.PROCESS = DEL.
6. Inside the PROCESS.AUTHORISE.ACTION,
o Process PROCESS.ACCOUNTING.UPDATES with REQD.PROCESS = AUT
7. Inside the PROCESS.REVERSE.ACTION,

o Process PROCESS.ACTIVITY.BALANCES paragraph with PROCESS.TYPE as GET
o Load the PROPERTY into USED.ACCT and PROPERTY.AMT into USED.ACCT.AMT. Make this array to get
separated by FM.
o Process BUILD.ACCOUNTING.ENTRY with REVERSAL.MODE = 1
8. Inside the PROCESS.SETTLE.PAY.OUT paragraph,
o Just have a RETURN statement . Further enhancement will be done during PAY processing.
9. Inside the PROCESS.SETTLE.PAY.IN paragraph, build two arrays,
o Let one array say ACCT.LIST contains the account numbers
o The other say ACCT.AMT.LIST carries the working balance
o Process DETERMINE.DUE.AMT paragraph.
o Process PARSE.ACCT.BAL.AGAINST.DUE paragraph.
o Process the paragraph PROCESS.ACTIVITY.BALANCE, with PROCESS.TYPE = UPDATE just to update the
details in the ACTIVITY.BALANCES file.
o Process the paragraph UPDATE.ACTIVITY.BALANCE to actually write the newly build balances for this account
into the file AA.ACTIVITY.BALANCES.
o Process the paragraph BUILD.ACCOUNTING.ENTRIES to hit the customer side account.
o Process the paragraph RAISE.SEC.ACTIVITY to process the apply payment.
10. Inside the DETERMINE.DUE.AMT ,
o Loop through multi valued PAYMENT.TYPE
o Call the routine AA.GET.PAYMENT.TYPE.DUE.AMOUNT to get the sum of due balances for the PAYMENT.TYPES defined at that
multi value level.
o Let TOT.DUE.AMOUNT variable carries the total of due amount for the PAYMENT.TYPE passed to the routine
AA.GET.PAYMENT.TYPE.DUE.AMOUNT.
11. Inside the PARSE.ACCT.BAL.AGAINST.DUE

o Call the routine AA.PARSE.DUES.AGAINST.SETT.ACCOUNTS. This routine will return
o USED.ACCT - contains the cumulative of accounts used in this entire process of settlement.
o USED.ACCT.BAL – contains the cumulative of account balances used in this entire process of settlement.
o ALLOCATED.ACCT.LIST – Contains the account utilised in this settlement process.
o ALLOCATED.ACCT.AMT.LIST – Contains the account balance utilised in this settlement process.
o TOT.ALLOCATED.AMT – Total amount allocated in this settlement process.
o If some settlement had happened (TOT.ALLOCATED.AMT > 0 ) then,
o Assign USED.ACCT to ACCT.LIST and USED.ACCT.BAL to ACCT.AMT.LIST. Thus multiple occurrences of
accounts across the multivalve set of PAYMENT.TYPE will be handled using these variables.
Now, we have to call following process in sequence,
12. Inside the PROCESS.ACTIVITY.BALANCE paragraph,
o Call AA.PROCESS.ACTIVITY.BALANCES with the following as it arguments.
o ARRANGMENT.ID = arrangement id
o PROCESS.TYPE = GET/UPDATE/REVERSE
o ACTIVITY.BALANCES = “”
o ACTIVITY.REFERENCE = activity reference id
o PROPERTY = USED.ACCT( separated by VM)
o BALANCE.TYPE = “”
o BALANCE.TYPE.AMT = USED.ACCT.BAL (separated by VM)
13. Inside the UPDATE.ACTIVITY.BALANCS paragraph,
o Call AA.UPDATE.ACTIVITY.BALANCES.

o This will update the AA.ACTIVITY.BALANCES record with ACCOUNTS in PROPERTY field and AMT.SETTLED
in the PROPERTY.AMT field.
14. Inside the paragraph BUILD.ACCOUNTING.ENTRIES,
o We have to build accounting entries to hit the customer side by calling AA.ACCOUNT.MANAGER.
o Get the account event type, by calling the routine AA.GET.ACCOUNTING.EVENT.TYPE. The event type for this
event is SETTLEMENT-SETTLE-DUE. ( make this call as a separate paragraph)
o For each account in USED.ACCT, build the EVENT.REC as given below
o EVENT.REC<E_EVENT.TYPE> = EVENT.TYPE
o EVENT.REC<E_AMOUNT> = ABS(THIS.USED.ACCT.BAL)
o EVENT.REC<E_SIGN> = "DEBIT"
o EVENT.REC<E_CONTRACT.ID> = THIS.USED.ACCT
o EVENT.REC<E_VALUE.DATE> = EFFECTIVE.DATE
o EVENT.REC<E_REVERSAL.IND> = (REVERSAL.MODE = "YES")
o Instead of hard coding the transaction code inside this routine to debit the accounting entry , we can have a new
EVENT.TYPE – SETTLEMENT-SETTLE-DUE which tells the TXN.CODE.
o The opposite suspense entry will also get the details from the new EVENT.TYPE. (AC.SOFT.ACCOUNTING will
default the TXN.CODEs to be used. )
o We will have a new type AC*TXN in AC.ALLOCATION.RULE > MVMT.TARGET / OPP.TARGET. This new type
will pass the account number to soft accounting.
o Inside the loop it assigns this EVENT.REC TO MULTI.EVENT.REC after lowering the array.
o Once all the accounts in USED.ACCT have been processed,
o Process the paragraph PROCESS.ACCOUNTING.UPDATES
15. Inside the PROCESS.ACCOUNTING.UPDATES paragraph,

o If REQUIRED.PROCESS = VAL then call AA.ACCOUNTING.MANAGER with the MULTI.EVENT.REC.

o If it’s not VAL processing call AA.ACCOUNTING.MANAGER without passing MULTI.EVENT.REC. Just pass the
REQUIRED.PROCESS alone.
o Even on VAL processing check whether MULTI.EVENT.REC is present before calling the
AA.ACCOUNTING.MANAGER record.
16. Inside the RAISE.SEC.ACTIVITY paragraph,
o Call the AA.PROCESS.SECONDARY.ACTIVITY.
o The secondary activity record to be build will be as specified below,
o AAA.REC<AA.ARR.ACT.ARRANGEMENT> = Arrangement id
o AAA.REC<AA.ARR.ACT.ACTIVITY> = Activity specified in the settlement activity field for this multi value set
o AAA.REC<AA.ARR.ACT.EFFECTIVE.DATE> = EFFECTIVE.DATE
o AAA.REC<AA.ARR.ACT.LINKED.ACTIVITY> = AA$MASTER.ACTIVITY<1,1>
o AAA.REC<AA.ARR.ACT.ORIG.TXN.AMT> = TOT.ALLOCATED.AMT
o AAA.REC<AA.ARR.ACT.TXN.AMOUNT.LCY> = TOT.ALLOCATED.AMT
o AAA.REC<AA.ARR.ACT.CURRENCY> = ARR.CURRENCY
o AAA.REC<AA.ARR.ACT.TXN.AMOUNT> = TOT.ALLOCATED.AMT
o With this the process for INPUT action ends
3.2 AA.GET.PAYMENT.TYPE.DUE.AMOUNT
This routine will return the balances for the PAYMENT.TYPE passed. This routine will get the due type as an argument , so that
PAY.IN and PAY.OUT balances can be captured using the same routine
Arguments for this routine

1. ARRANGEMENT.ID – Inward – carries arrangement id
2. BALANCE.TYPE – Inward – carries DUE/PAY
3. BALANCE.DATE – Inward – carries date for which the bills need to be extracted
4. BALANCE.CCY – Inward – future use
5. PAYMENT.TYPE – Inward – carries the payment type separated by FM
6. PROPERTY.LIST – Inward - carries the property type separated by FM
7. PROPERTY.CLASS.LIST – Inward - carries the property class type separated by FM
8. BILL.IDS – Inward – carries the BILLS reference separated by FM
9. TOT.BALANCE.AMT.LIST – Outward – carries the balances in a list for the passed currency by FM. This
will carry either PAYMENT.TYPE/ PROPERTY.LIST/ PROPERTY.CLASS.LIST balances.
10. TOT.BALANCE.AMT.LCY.LIST - Outward – carries the balances in a list for the passed currency by FM. This
will carry either PAYMENT.TYPE/ PROPERTY.LIST/ PROPERTY.CLASS.LIST balances in local currency.
11. SUM.BALANCE.AMT – Outward – Carries the sum of balance amount in balance currency.
12. SUM.BALANCE.AMT.LCY – Outward – Carries the sum of balance amount in local currency
13. RET.ERROR – Outward – Error on processing.
The logic of this routine is as follows,

As of now , this routine will calculate local DUE balances only.
 Initialise paragraph should initialise the variable which are used to calculate the balances and sum of the balances.
Apart from this , a variable process flag need to be set. The condition to set the process flag will be if
PAYMENT.TYPE or PROPERTY.CLASS.LIST or PROPERTY.LIST.
 In the initialise paragraph set the variables with following condition
Process type = PAYMENT/PROPERTY.CLASS/PROPERTY depending on the LIST passed and assign the
corresponding list to PROCESS.LIST variable.

 Inside the process paragraph ,
CASE PROCESS.FLAG is set and the BALANCE.TYPE is PAY
As of now no code need to be written for PAY processing , just write a paragraph separately with single return
statement.
CASE PROCESS.FLAG is set and the BALANCE.TYPE is DUE
GOSUB GET.DUE.BALANCE.AMT
 Inside the paragraph GET.DUE.BALANCE.AMT,
CASE process.type = PAYMENT
Go sub GET.PAYMENT.TYPE.DUE.BALANCES
CASE 1 (process.type = PROPERTY.CLASS\ PROPERTY )
No code need to be written as of now.
 Inside the paragraph GET.PAYMENT.TYPE.DUE.BALANCES,
This paragraph will check is any BILL.IDS passed otherwise this will call GET.BILL to get all the bills. Then this will
call GET.BILL.DUE.AMOUNT to get the due amounts for the bills.
 Paragraph GET.BILL
This should call the routine AA.GET.BILL with ARRANGEMENT.ID and PAYMENT.METHOD. The bill reference
passed must be used for getting the bill details on further paragraph.
It’s better to declare all variables used in call to AA.GET.BILL.
 Paragraph GET.BILL.DUE.AMOUNT
This routine will process the bill reference returned by AA.GET.BILL in a loop,
Call GET.BILL.DETAILS to get the bill details
Call GET.THIS.DUE.AMT to get the dues on this bill for the payment type/s passed
 Paragraph GET.BILL.DETAILS

This paragraph will call AA.GET.BILL.DETAILS to get the bill details for the bill reference passed by the
AA.GET.BILL.
 Paragraph GET.THIS.DUE.AMT,
For each PAYMENT.TYPE,
Call AA.GET.BILL.PROPERTY.AMOUNT with PROCESS.TYPE and PAYMENT.TYPE and get the balance
amount and assign it to PROCESS.AMT.LIST and sum up the balances for this property.
Code should cater to the scenario of two bills for the same PAYMENT.TYPE , such that the initialisation of
PROCESS.AMT.LIST and PROCESS.AMT.LIST.LCY are outside this looping paragraph GET.THIS.DUE.AMT.
Thus the DUE balances for the passed PAYMENT.TYPE have been calculated and will be returned from this
routine.
3.3 AA.GET.SETTLEMENT.LINKED.ACCT.BAL
This routine will check the account balances for an account passed. The logic of this routine is similar to the routine
PD.GET.AVAILABLE.AMOUNT.
Arguments to this routine
1. ACCOUNT.NO - Inward – A/c number
2. BALANCE.DATE – Inward – Date for which the balance need to be calculated.
3. BALANCE.CCY – Inward – Currency in which the balance to be calculated.
4. WORKING.BALANCE - Outward – Carries the Working balance – Any amount locked in that a/c
5. OD.BAL.AMT – Outward – Carries Working balance + Available limit amount – any amount locked in the passed a/c.
The logic of this routine is as follows
 Inside the initialisation paragraph, do opf for the account file.
 Inside the Process Paragraph, Read the account that is passed.

If the ACCOUNT passed is an arrangement account then,
Just call a paragraph, GET.ARRANGEMENT.ACCOUNT.BALANCE. As of now, this paragraph will contain just a
return statement and will be enhanced in future.
If the ACCOUNT passed is a normal customer account then,
Process the paragraph GET.ACCOUNT.BALANCE.
 Inside the GET.ACCOUNT.BALANCE, the logic is to build the working balance and limit amt available for that account.
This paragraph will call the following paragraphs
o GET.AVAILABLE.BALANCE,
o ADJUST.LOCKING.AMT and
o GET.LIMIT.AVAILABLE.AMT.
 Inside the GET.AVAILABLE.BALANCE paragraph,
If the account has specified another account for AUTO PAYMENT, then we need to read this account once again.
WORKING.BALANCE will be taken from the account record’s WORKING.BALANCE field.
 Inside the ADJUST.LOCKING.AMT paragraph, any amount that got locked for the passed period will be subtracted from
the computed WORKING.BALANCE. This will be calculated as follows,
LOCKED.BAL = R.ACCOUNT<AC.LOCKED.AMOUNT>
LOCKED.DATE = R.ACCOUNT<AC.FROM.DATE>
DATE.CNT = DCOUNT(LOCKED.DATE,VM)
FOR I = 1 TO DATE.CNT
CUR.DATE = LOCKED.DATE<1,I>
IF CUR.DATE AND CUR.DATE LE TODAY THEN
LOCKED.AMOUNT = LOCKED.BAL<1,I>
END

NEXT I
After calculating the locked amount , if there is any LOCKED.BALANCE which is greater than zero then the
WORKING.BALANCE will be reduced by the LOCKED.AMOUNT.
Once the WORKING.BALANCE has been calculated, have a call to a paragraph
GET.CURRENCY.BASED.BAL. This paragraph will deal with cross currencies in future.
 Inside the GET.LIMIT.AVAILABLE.AMT paragraph,
Call the routine GET.ACCOUNT.LIMIT.AMOUNT. The arguments to this routine are as follows,
LIAB.NO – Account holders liability number taken from CUSTOMER>CUSTOMER.LIABILITY field.
CUSTOMER.NO- Customer number of the account holder
ACCOUNT.LIMIT.REF- Limit reference for this account taken from ACCOUNT>LIMIT.REF
CCY- Currency of the passed account taken from ACCOUNT>CURRENCY
AL.AMT- Online limit allocated amount- returned by the routine
AV.AMT – Available Limit amount – returned by the routine
Now to calculate the OD.BAL.AMT we have available limit amount in AV.AMT.
If AV.AMT is less than zero make it as zero.
If WORKING.BALANCE is less than zero then, calculate the OD.BAL.AMT as
OD.BAL.AMT = AV.AMT – LOCKED.AMOUNT
If WORKING.BALANCE exist then,
OD.BAL.AMT = AV.AMT + WORKING.BALANCE
3.4 AA.GET.SETT.ACCT.RULE.TYPE.BALANCE
This routine will return the amount that can be taken from the account balances for processing the settlement .

Arguments to this routine are
1. ACCOUNT.NO – Inward account number to be processed . Used for future use.
2. PAYMENT.TYPES – Inward – Payment types whose DUE.BALANCE is passed .Used for future use.
3. DUE.BALANCE – Inward – Due.balance against which the funds need to be allocated.
4. ACCT.BALANCE – Inward – Fund available in account
5. ACCT.OD.LIMIT.BALANCE – Inward – Overdraft amount limitation
6. ACCOUNTING.RULE.TYPE – Inward – Type of settlement to be done - Partial/ full/none.
7. ALLOCATED.AMT – Outward – Amount of fund allocated for settlement
8. RET.ERROR – Outward – Error if any.
The logic of this routine is as follows,

o Inside the initialise paragraph, initialise the variable ALLOCATED.AMT to zero.
o Check the accounting rule type, whether to settle in partial /full/ none.
o Call the paragraph related to the passed ACCOUNTING.RULE.TYPE
o Case ACCOUNTING.RULE.TYPE is NONE
 Go sub PROCESS.NONE.SETTLEMENT
o Case ACCOUNTING.RULE.TYPE is PARTIAL
 Go sub PROCESS.PARTIAL.SETTLEMENT
o Case ACCOUNTING.RULE.TYPE is FULL
 Go sub PROCESS.FULL.SETTLEMENT
o Inside the paragraph PROCESS.NONE.SETTLEMENT,
If enough funds are not available in the account , make the due to remain as such.

If ACCT.BALANCE < DUE.BALANCE then
ALLOCATED.AMT = 0
Else
ALLOCATED.AMT = DUE.BALANCE
o Inside the paragraph PROCESS.PARTIAL.SETTLEMENT,
If enough funds are not available in the account, take the available fund.
If ACCT.BALANCE < DUE.BALANCE then
ALLOCATED.AMT = ACCT.BALANCE
Else
o Inside the paragraph PROCESS.FULL.SETTLEMENT,
If enough funds are not available in the account, then overdraw the account.
If ACCT.OD.LIMIT.BALANCE < DUE.BALANCE THEN
ALLOCATED.AMT = ACCT.OD.LIMIT.BALANCE
End Else
3.5 AA.PARSE.DUES.AGAINST.SETT.ACCOUNTS
This routine will get the due amount, settlement accounts defined against the due amount and account debit rule.
This routine will return the accounts and the funds allocated against each account, and the total amount of due that can
be settled. Simply this will be the sum of the funds allocated from each account.
Arguments for this routine,
1. TOT.BILL.DUE – Inward – Total of Due amount against which settlement to happen.

2. SETTLE.ACCOUNT – Inward – Settlement accounts available for fund allocation.
3. SETTLE.RULE – Inward – Account debit rule.
4. USED.ACCT – Inward/Outward - Settlement accounts which have been utilised already in this stream of
settlement.
5. USED.ACCT.BAL – Inward/Outward – Already utilised accounts allocated amount.
6. ALLOCATED.ACCT – Outward – Accounts whose funds are to be utilised in settlement process
7. ALLOCATED.AMT - Outward – Fund allocated against each account
8. TOT.ALLOCATED.AMT – Outward – Total of funds allocated for each account
9. RET.ERROR –Outward – Error on processing.
The logic for this routine is as follows
o Inside the initialise paragraph, initialise the ALLOCATED.ACCT, ALLOCATED.AMT and TOT.ALLOCATED.AMT and
FULLY.SETTLED to zero.
o Inside the process paragraph, for each of the account passed process the paragraph GET.ACCT.SETTLE.AMT and
UPDATE.ACCT.SETTLE.AMT.
o Inside the paragraph GET.ACCT.SETTLE.AMT,
o Initialise the variables as stated below,
o Initialise ACCT.BAL =0
o ACCT.OD.BAL = 0 and
o ALLOCATED.AMT = 0
o Call AA.GET.SETTLEMENT.LINKED.ACCT.BAL to get the account balance of the account passed. Let ACCT.BAL
hold the working balance of the account and ACCT.OD.BAL hold the available limit balance of the account.
o Now, check whether the account processed (ACCT.TO.PROCESS ) is there is USED.ACCT.
o If ACCT.TO.PROCESS is located in USED.ACCT get the already used balance from USED.ACCT.BAL.

o Decrease the ACCT.BAL and ACCT.OD.BAL by USED.ACCT.BAL.
o To determine the settlement amount we have to allocate the available fund in the account after validating the
ACCOUNT DEBIT RULE defined at that multi value level.
o Call the routine AA.GET.SETT.ACCT.RULE.TYPE.BALANCE to decide the balance to be taken from this a/c.
o This routine will return the fund allocated from this account for this settlement event. Capture it in a variable say
ALLOCATED.AMT.
o Inside the UPDATE.ACCT.SETTLE.AMT, update the ALLOCATED.AMT array and the USED.ACCT.BAL array
accordingly.
IF ALLOCATED.AMT > 0 THEN
TOT.BILL.DUE - = ALLOCATED.AMT
TOT.ALLOCATED.AMT += ALLOCATED.AMT
ALLOCATED.ACCT <-1> = ACCT.TO.PROCESS
ALLOCATED.AMT<-1> = ALLOCATED.AMT
LOCATE ACCT.TO.PROCESS IN USED.ACCT SETTING ACCT.POS THEN
USED.ACCT.BAL<ACCT.POS> -= ALLOCATED.AMT
END ELSE
USED.ACCT<-1> = ACCT.TO.PROCESS
USED.ACCT.BAL<-1> = ALLOCATED.AMT
END
o Thus, on return the USED.ACCT and USED.ACCT.BAL will have the cumulative of account balances utilised.
3.6 AA.SETTLEMENT.CHECK.SETTLE
This will be an action routine in the MAKEDUE activity class.

This routine will just trigger a secondary activity PRODUCT.LINE-SETTLE-ARRANGEMENT.

3.7 AC.ALLOCATION.RULE.VALIDATE
Inside the paragraph TARGET.CHECK, for the CASE TARGET.TYPE[1,2] = ‘AC’, the account check should be
changed conditionally as stated below,
IF TARGET.DETAIL <> 'TXN' THEN
GOSUB ACCOUNT.CHECK
END
3.8 AC.SOFT.ACCOUNTING
Inside the paragraph GET.ACCOUNT.NO , for the case MVMT.IND = “AC”, following code change is needed.
CASE MVMT.IND = "AC"
ACCT.NO = MVMT.BALANCE.TYPE["*",2,1] ;* Specific account number
IF ACCT.NO = "TXN" THEN
ACCT.NO = EVENT.DETAIL<E_CONTRACT.ID>
END
3.9 DATA MODIFICATION
o Attach the action routine AA.SETTLMENT.CHECK.SETTLE, in the following ACTIVITY.CLASS records. This
Action routine should be attached next to CHECK.SETTLE activity.
PRODUCT.LINE -MAKEDUE-PAYMENT.SCHEDULE
PRODUCT.LINE-MAKEDUE-PERIODIC.CHARGES
PRODUCT.LINE-MAKEDUE-CHARGE
o New AC.ALLOCATION.RULE needs to be set up for LENDING-SETTLEMENT property class.

o AA.PRD.DES.ACCOUNTING record needs to be changed and the SETTLEMENT property class accounting
rule should be mapped to AC.ALLOCATION.RULE>LENDING-SETTLEMENT.
o New AA.ACTIVITY.CLASS needs to be created for LENDING-SETTLE-ARRANGEMENT.
o The action routine for this will be AA.SETTLEMENT.SETTLE.
o AA.ACTIVITY.CLASS.ACTION should have a new record. The id of the record will be SETTLEMENT-SETTLE.
This ACTION will have ACCOUNTING set to YES.
o AC.EVENT record to be released newly wit id as SETTLEMENT-SETTLE-DUE
o When this EVENT entries are declared in AC.ALLOCATION.RULE, we can use a new MVMT.TARGET which
is AC*TXN.

4. Client Program and Data Modifications
4.1 XSL
4.1.1 Program Name 1
4.2 Static HTML

4.3 JavaScript

4.4 Skins

4.5 Java

4.6 XML Templates


4.7 Configuration files

4.8 Images


5. Processing Modifications
5.1 Delivery

5.2 Batch Processing
5.2.1 New Batch Job

5.2.2 New Batch Processes

5.3 EURO Considerations 1

5.4 Miscellaneous 2

1
e.g. Changes/considerations to ensure EURO compliance
2
e.g. Accounting rules, Position Management update, Limit update etc.

6. Documentation
6.1 User Guide & Release Notes

6.2 Help Text


7. Testing Considerations
7.1 Online

7.2 Close of Business


T24 Development: Technical Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T24 Development: Technical Specification

Uploaded by

Copyright:

Available Formats

Technical Specification

T24 Development SAR number: SAR Reference

SAR Reference: 56323

SAR Description: Due Processing

Client Name: Internal

Client Reference: Client Ref

Revision Date Amended Name Description

1.0 05-06-2010 R.Gayathri Original version

Information in this document is subject to change without notice.

Copyright  2007 Temenos. All rights reserved.

1.1 Existing System Overview

1.2 New Requirements Overview

3. On Loan Repayment the process sequence will be

o Try to apply repayment according to Settlement Instructions

o Repay and make remaining (if any) as ‘Due’

4. Regarding funding of AA Deposit

o Funding of deposits needs to be supported once a Deposit arrangement is

o The sequence of funding will be

o Update Expected balance

o Try to fund from the source account according to settlement instruction

o Pay and leave remaining in “Expected” as applicable

o Full: Overdraw the source account and pay outstanding in Full.

o This new activity class will have a single action routine

Limitations of this Sar.

1.5 Example Output

2.1 New Tables

Table Name

SAR Reference 8 50858069.doc

2.2 Modified Tables

Table Name

SAR Reference 9 50858069.doc

3. Server Program and Data Modifications

SAR Reference 10 50858069.doc

SAR Reference 11 50858069.doc

SAR Reference 12 50858069.doc

SAR Reference 13 50858069.doc

o If REQUIRED.PROCESS = VAL then call AA.ACCOUNTING.MANAGER with the MULTI.EVENT.REC.

SAR Reference 14 50858069.doc

The logic of this routine is as follows,

SAR Reference 15 50858069.doc

SAR Reference 16 50858069.doc

SAR Reference 17 50858069.doc

SAR Reference 18 50858069.doc

SAR Reference 19 50858069.doc

The logic of this routine is as follows,

SAR Reference 20 50858069.doc

SAR Reference 21 50858069.doc

SAR Reference 22 50858069.doc

This will be an action routine in the MAKEDUE activity class.

SAR Reference 23 50858069.doc

3.9 DATA MODIFICATION

SAR Reference 24 50858069.doc

SAR Reference 25 50858069.doc

4. Client Program and Data Modifications

4.1.1 Program Name 1

4.2 Static HTML

4.6 XML Templates

SAR Reference 26 50858069.doc

4.7 Configuration files

SAR Reference 27 50858069.doc

5.2 Batch Processing

5.2.1 New Batch Job

5.2.2 New Batch Processes