Aa Tutorial

1.
ARRANGEMENT ARCHITECTURE
Product Setup & Technical Guide

Arrangement Architecture Product Setup & Technical Guide
Amendment History
Version Date Author / Changed By Status

0.1 25th May 2015 Dinesh BR Initial Draft
0.1 25th May 2015 Iyyappan R Initial Draft
0.2 23rd July 2015 Dinesh BR Updated sections – 2.2,
2.2, 3.1, 7.2
Included sections – 5,
5, 8.1
0.2 23rd July 2015 Krishnaveni Reviewed
Version: V 0.2, 23 rd July 2015

Table of Contents
1. Introduction
2. Components of AA
2.1 Flow of AA
2.2 Product Line
2.3 Product Group
2.4 Product
2.5 Product Class
2.6 Product Conditions
3. Defining conditions
3.1 Activity API
3.2 Activity Presentation
3.3 Charge
3.4 Activity Charges
3.5 Activity Mapping
4. Activity setup flow of AA
5. Adding Local Reference Field
6. New Arrangement
Arrangement Architecture
6.1 Create New Arrangement Architecture
6.2 Find AA loan / authorize the AA Loan
7. Commonly used Insert file and

and common
common variables in AA
AA
7.1 Insert files
7.2 Common variables
7.3 Property classes
8. AA at Subroutine level
8.1 Core APIs
8.2 Reading the property class

8.3 RAISE conditions
8.5 Select command in the AA record
9. Updating Fields in AA
9.1 Authorizing the record
9.2 Updating existing record
9.3 Updated Restructure date & End date
10. T24 Browser Level debug in TAFJ for AA routine
10.1 Browser listener
10.2 Variables tab

1. Introduction
This document helps the user to understand about the functionality of Arrangement
Architecture (AA) and flow of product setup and technical aspects in AA.
2. Components of AA
In AA, we have 5 major components are below,
Product Line
Product Group
Product
Property class
Product conditions
2.1 Flow of AA
From 5 major components, 3 are available under “Products” link and remaining 2 under
“Product Conditions ”.


In the above components, Product Line and Product Group will be created only by Temenos.
In other components, we will be able to
t o define conditions.
2.2 Product Line
Product Line is a high level definition of the business component which was created by
Temenos. We can’t able to create or modify anything in this Product Line.
It is where we select the purpose of what we are going to do. If we wish to get a loan, then we
will go with “Lending”
“Lending” product line. If we wish to deposit, then we select “Deposits” product
line.
2.3 Product Group
Product group provides basic shape to the product. This is where we will select which loan we
are going to take. For example:
example: if we wish to take
t ake personal loan, we will select “Personal
Loan” product group.
2.4 Product
This is where the user links the desired properties to appropriate conditions.
For the product group we selected, we will have different products to use. In this product, we
will define the conditions about how the product should behave.

2.5 Property Class
Class is where will have set of activities to behave. These can be given by Temenos and
cannot be amended.
Some major used classes are ACTIVITY.API and ACTIVITY.PRESENTATION.

ACTIVITY.PRESENTATION.
2.6 Product Conditions
Product Condition is where we will define the

t he behavior.


3. Defining conditions
In the product condition, we will define conditions for classes. For the respective class,
cla ss, there will be
some set of conditions to define the class.
For example: We are considering ACTIVITY.API,

ACTIVITY.API, we have to create or modify to define conditions.
Some of the frequently used classes are given below:
3.1 ACTIVITY.API
This is the place where we play around with routines.
In this ACTIVITY.API only, we have to attach routines.
Here, user can define ACTIVITY, PROPERTY.CLASS and ACTION.
In order to define our local routines we have to provide valid Activity Class / Activity ID along
with the Property class/ Property along with Action.
From the above screenshot, our routine will get triggered whenever the user updates the values in
the Interest tab/section for a new a Lending contract.
We can define routines under following sections.
 Record routine
Triggered when record opens
 Pre validation routine
Triggered before core validation of the record
 Validation routine
Triggered during validation

 Pre routine
Triggered before the defined action takes place
 Post routine
Triggered after the defined action takes place
Above given screenshot clearly shows, in which stage which routine will get triggered.
The below screenshot shows the attachment of Record, Validation and Post routine i n the
product JAB.LENDING.
JAB.LENDING.
Validation routine:
From the above screenshot our routine will get triggered whenever the user adjust the bill
“RESTRUCTURE-ADJUST-ALL-BALANCE-
then validate the record for a “RESTRUCTURE
Action– “ADJUST -BILL”.
MAINTAINTENANCE” activity and Action– “ADJUST
Pre Routine:

From the above screenshot our routine will get triggered whenever the user opens the
record and updates in the Charge tab/section for a new a Lending contract.
Post Routine:
Post routine is triggered both UNAUTH and AUTH status for a Lending New
Arrangement.
Local routine to perform the required action is attached as Post routine in

JAB.LENDING product.
The below screenshot shows the post routine triggered with “UNAUTH”
“UNAUTH” status,

The below screenshot shows the post routine triggered with “AUTH” status,
Note:
Pre and Post routines are called during all stages of template – like
like Input, Delete,
Authorization, and Reversal. Hence the developer should always branch the control using
OFS$OPERATION.
For ex: From the above screenshot, we have given as OFS$OPERATION EQ

“PROCESS”.
“PROCESS”. If condition gets satisfied, then system will process the defined code. Else, it
will return. This is how we are taking control on code for pre and post routines.
3.2 ACTIVITY.PRESENTATION
It is used for defining various versions in

i n a single screen which will be used for different
Property classes/Properties/Activities during an entry.
Here, we will attach VERSIONS.

No routines should be defined

defined in the versions defined
defined in ACTIVITY.PRESE
ACTIVITY.PRESENTATION
NTATION.. The
versions should only define screen layout.
Adding local field to the application is covered in Section 5.
3.3 CHARGE
This property is used to define charges. This property class ca n be added to PAYMENT
SCHEDULE
SCHEDULE property class for defining scheduled charges. To define charges related t o an
activity this class can be used in ACTIVITY CHARGE
CHARGE property class.
Charge routine field is used to define calculation as required by user. Usually, we will attach
routine in this field to calculate charge.

3.4 ACTIVITY.CHARGES
It defines the charge that needs to be applied when activity is triggered.
For example: If we increase/decrease Term amount (LENDING-INCREASE-

(LENDING-INCREASE-
TERM.AMOUNT/LENDING-DECREASE-TERM.AMOUNT) in an arrangement,
corresponding charge property will be called which was defined in Property conditions.
3.5 ACTIVITY.MAPPING
In this property class, we will define about which transaction code to be hit during respective
activities.

4. Activity setup flow of AA
While setting up the product, we have to consider Property classes and Property conditions
in Product Group and Product respectively.
For example: Please see the below screenshots showing flow of attaching API to product.
Lending -> Personal Loan (View) -> Activity API -> API

In the above screenshot, Property class is ACTIVITY.API

ACTIVITY.API and the id given for this
t his property class is
API. This should be given in the Property Condition.

Property class is the id of Product classes. Here, we will define the properties which will be
used in Product designer.
From the above screenshot, AA.LENDING.API is the property condition defined in product.
Also, it is the id of Activity.API class.

In this API, we have attached

att ached routines as Pre & Post.
The above given setup is for one property class. Likewise, we have to setup for other activities
based on the requirement.
5. Adding Local Reference Field
AA Properties shares the same field layout across 4 different f iles:

 Designer (Example: AA.PRD.DES.CUSTO
AA.PRD.DES.CUSTOMER) MER)
 Proofing (Example: AA.PRD.PRF.CUSTOME
AA.PRD.PRF.CUSTOMER) R)
 Catalog (Example: AA.PRD.CAT.CUSTO
AA.PRD.CAT.CUSTOMER) MER)
 Arrangement (Example: AA.ARR.CUSTOMER)
AA.ARR.CUSTOMER)
To avoid duplicity and maintain data integrity, AA allows definition of Local reference fields to
just one file (the PRD.DES
PRD.DES files) and replicates the same
same across other levels automatically.
automatically.
We have given below the screenshots of local field and it was attached to the
AA.PRD.DES.ACCOUN
AA.PRD.DES.ACCOUNT T table.
Local table:

Local Ref table:
The above local field is attached to the version AA.ARR.ACCOUNT,JAB.AA

AA.ARR.ACCOUNT,JAB.AA which
which was
attached to the ACTIVITY.PRESENTATION>PERSONAL.LOAN

The above setup will lead to display the LRF in the Account property tab. The screenshot is
given below:
Till now, we have seen the technical functionality of AA. Now, we are going to learn about the
business flow in AA.
AA.
6. New Arrangement Architecture
While creating a new Arrangement Architecture, it displays multiple Product groups and Product.
Every Product Groups contains different Products.
Please find below the product groups and products in the product catalog which is defined in the
products and product conditions.
conditions.

6.1 Create New Arrangement Architecture
To create New Arrangement Architecture via T24 browser, follow the below steps
Click on User Menu -> Product Catalog

Pop up window will be opened, Choose Product Group as Personal Loan & Product as Other Loan

Enter your Customer id and Currency details in the

t he above screen and validate the record, it will open
up the arrangement screen to define values.

Account Tab:
Mandatory input fields are - Term Amount and Penalty interest (Fixed rate)

Commitment tab:
Input the term amount of the loan,
Principal Interest tab:

Penalty Interest tab:

Schedule for the respective Arrangement architecture:
Here defined the Payment type, Method, Property & Frequency.
Account Closure:
In account closure Activity and action fields are defaulted based on the Product & Product condition s
Setup.

After committing the record,
6.2 Find AA Loan / Authorize the AA Loan
Once Commit the AA record and find the loan/ authorize the record.
Click user Menu - > Find Loan

Select Unauthorized AAA tab,
Input the Arrangement id - AA13274QWHBW

7. Commonly used Insert file and common variables in AA

These insert files and common variable are used to
t o find the AA record details.
7.1 Insert Files
$INSERT I_F.AA.INTEREST
$INSERT I_F.AA.TERM.AMOUNT
$INSERT I_F.AA.ACTIVITY.HISTORY
$INSERT I_F.AA.ARRANGEMENT.ACTIVITY
$INSERT I_AA.LOCAL.COMMON
$INSERT I_AA.APP.COMMON
$INSERT I_F.AA.PRODUCT
$INSERT I_AA.ACTION.CONTEXT
$INSERT I_F.AA.TERM.AMOUNT
$INSERT I_F.AA.LIMIT

7.2 Common Variables
Find below the common variables of I_F.AA.LOCAL.COMMON,
Find below the common variables of I_F.AA.APP.COMMON

c_aalocArrProductId - The above contract shows product id is “OTHER LOAN/INDIVIDUAL ”
c_aalocArrCurrency - Currency “JOD”

c_aalocActivityId – Activity
– Activity ID “AAACT13274MBB57Y56”
c_aalocLinkedAccount – Linked acc no – “1000010703”
– “1000010703”
c_aalocArrId - Arrangement ID “AA13274QWHBW”
c_aalocActivityStatus – Like
– Like “UNAUTH” , “REVERSE” ,”DELETE”, “AUTH”
c_aalocPropertyId – Like
– Like “PRININTEREST”
c_aalocPropClassId – Like
– Like “TERM.AMOUNT”

Likewise, above mentioned AA Insert files are having many common variables.
7.3 Property Classes
For reading the AA record is different from the normal read command (CALL F.READ()),
F.READ()),
Initially we need to get the Arrangement ID.
Mostly used property classes are,
 CLOSURE
 CUSTOMER
 INTEREST
 LIMIT
 TERM.AMOUNT
 OFFICERS
 PERIODIC.CHARGES
 SETTLEMENT
 BALANCE.MAINTENANCE
 CHARGE.OVERRIDE
 CHARGE
8 AA at routine level
Initially get the Arrangement Id to process the Property class find below details of the routine,
8.1 Core APIs

The following APIs may be utilized when certain information’s are required in a local routine:
 AA.GET.ARRANGEMENT.CONDITION
o This routine can be used by any application to retrieve the pro perty
conditions that apply to an arrangement for a particular effective date
(default value is TODAY).
o The specific property or property cl ass required must be supplied
o The records and ids for the property conditions that apply are returned
o No. of arguments passed – 7
Parameter type Name Description

IN (Mandatory) idArrangementComp The Id of the arrangement for which
property condition is requested.
IN (Optional) idPropertyClass Property class for which property
details are sought. If the class
contains multiple properties in this
arrangement, system returns the
records for all properties
IN (Optional) idProperty Specific property for which details
are sought. If class is not supplied,
property must be stated.
IN (Optional) effectiveDate The date for which property details
are sought. If the property record
does not have a record on that date,
the past record nearest to that date

is returned. If a date is not supplied,

TODAY would be assumed.
OUT returnIds List of property Ids for this class
separated by FMs
OUT returnConditions List of property records – lowered to
be in sync with Ids
OUT returnError Errors if any during the processing
 AA.GEN.ARRANGEMENT.ACTIVITY.FIELDS
o This method maps the arrangement properties, its field name and its value
to new arrangement activity record
o Values can be supplied to arrangement property conditions from
AA.ARRANGEMENT.ACTIVITY record while triggering an activity
Parameter Type Name Description

IN(Mandatory) Property list List of property names of the
arrangement whose values are
supplied. Properties are separated by
value markers
IN(Mandatory) Field name list List of field names for each of the
properties whose values are supplied.
For a property the field names are
separated by sub value markers
IN(Mandatory) Field value list Actual values for the list of fields for
each of the arrangement properties.
For a property the field values are
separated by sub value markers
OUT ARR ACT Fields record The formatted arrangement activity
record
 AA.GEN.NEW.ARRANGEMENT.ACTIVITY
o This method appends the new arrangement activity as the secondary
activity to the parent activity

IN(Mandatory) Arrangement Id The arrangement id reference
IN(Mandatory) Secondary activity New secondary activity name to be
triggered.
IN(Mandatory) Effective date Effective date of the activity
IN(Mandatory) Txn Details The arrangement product that is
effective on the date passed for this
arrangement
IN(Mandatory) Parent activity id The list of properties that are eligible
for this product(separated by VMs)
IN(Mandatory) Arrangement activity New arrangement activity record
rec
OUT Return error Error message if any

 AA.GET.ECB.BALANCE.AMOUNT
o This method returns the total balance amount for a given balance type on a
given date for an account arrangement

IN(Mandatory) Account Id The account number of the
arrangement
IN(Mandatory) Balance type The balance type for which the
balance is sought.
IN(Mandatory) Request date Date for which balance is sought
OUT Balance amount The balance amount as in
EB.CONTRACT.BALANCES as on the
requested date. If the balance type is
virtual then sum of all the virtual
balance is returned
OUT Return error Error if any
8.2 Reading the property class
Initially get the arrangement using common variable – “c_allocArrI

– “c_allocArrId”
d” and read the
AA.ACTIVITY.HISTO
AA.ACTIVITY.HISTORY RY table to get the Arrangement Activity id.
Used common variables are – “c_allocAr

– “c_allocArrId”,
rId”, “c_allocActivityEffDate”
“c_allocActivityEffDate”
The below routine used the Core API – AA.GET.ARRANGEMENT.CONDITIONS

AA.GET.ARRANGEMENT.CONDITIONS to read
and write the AA record.
Total Arguments - 7
Passed Arguments are – Arrangement
Arrangement ID, Prop class, Property, R.Conditions and Err
message.
8.3 RAISE Conditions
RAISE(R.CONDITION) is used to get the values for the defined property class
“TERM.AMOUNT”.
The below routine to get the Amount, tenor, and maturity date of the Term amount
property class values.

Using this we can get the records for the tables or any property class
Below Common variables are used to check the conditions,
8.5 Select Command in the AA record
The below example is used to select the AA Bill record by using the
t he Core API – AA.GET.BILL.ID
AA.GET.BILL.ID
Total Passed
Passed Arguments
Arguments - 8
9 Updating fields in AA
9.1 Authorizing the record
For updating fields, use below logic, instead of using F.WRITE api,

R.AA.ACC.RECORD<AA.AC.LOCAL.REF,Y.RESTRUCT.DATE.POS,Y.CNT+1> = TODAY
R.AA.ACC.RECORD<AA.AC.LOCAL.REF,Y.END.DATE.POS,Y.CNT+1> = Y.DATE
The below condition is used to check

c heck the status of the record ,
REQD.PROCESS
REQD.PROCESS = c_arrActivityStatus["-",1,1]
REQD.PROCESS EQ 'UNAUTH' then
Below API “AA.ACTION.LIST.MANAGER” is used to “APPEND” the fields like OFS

process.
CALL AA.ACTION.LIST.MANAGER("APPEND", "", "", "")
Note:
Use AA.ACTION.LIST.MANA
AA.ACTION.LIST.MANAGER
GER api only for updating the fields in AA and for other
applications, use F.WRITE.
F.WRITE.
9.2 Updating existing record
The below logics are used to updating the existing records,
REQD.PROCESS
REQD.PROCESS = c_arrActivityStatus["-",1,1]
REQD.PROCESS EQ 'AUTH' then
CALL AA.ACTION.LIST.MANAGER("INSERT", "", "", "")
Below API “AA.ACTION.LIST.MANAGER” is used to “ INSERT” the fields like OFS

process.

9.3 Updated Restructure date & End date below
10 T24 Browser Level debug in TAFJ for

f or AA routine
10.1 Browser Listener
Initially start the browser. Listener in the Eclipse then input the contract in the T24
Browser.
If the routine is attached, then during the respective activity, routine is triggered which is
attached (like POST, PRE and Validation routine) in the products setup.
10.2 Variables Tab
Below the AA Routine triggered for the respective AA activity.

Already mentioned the AA common variable in the section- 7.2
AA Variables and Values:

In the variables tab, find

fi nd the values of the AA common variables,
For Ex:
c_aalocActivityStatus - DELETE
c_aalocCurrAction - DR.MOVEMENT.
DR.MOVEMENT.
c_aalocArrCurrency - JOD
c_aalocPropertyId - PRININTEREST
PRININTEREST
c_aalocArrProductId - JAB.LENDING
JAB.LENDING
While processing batch in COB/ONLINE,

COB/ONLINE, Activity Status is
i s like UNAUTH or DELETE.
Below screenshot shows the common variable values of Arrangement ID, Product ID, Property ID,
Currency and Status of AA contract.


Aa Tutorial

Uploaded by

Aa Tutorial

Uploaded by

1.

Product Setup & Technical Guide

Version Date Author / Changed By Status

Version: V 0.2, 23 rd July 2015

2.2 Product Line

2.3 Product Group

2.5 Product Class

2.6 Product Conditions

3.1 Activity API

3.2 Activity Presentation

3.4 Activity Charges

3.5 Activity Mapping

4. Activity setup flow of AA

5. Adding Local Reference Field

6.1 Create New Arrangement Architecture

6.2 Find AA loan / authorize the AA Loan

7. Commonly used Insert file and

7.1 Insert files

7.2 Common variables

7.3 Property classes

8.1 Core APIs

8.2 Reading the property class

Version: V 0.2, 23 rd July 2015

8.3 RAISE conditions

8.4 Common variables

8.5 Select command in the AA record

9.1 Authorizing the record

9.2 Updating existing record

9.3 Updated Restructure date & End date

10. T24 Browser Level debug in TAFJ for AA routine

10.1 Browser listener

10.2 Variables tab

Version: V 0.2, 23 rd July 2015

In AA, we have 5 major components are below,

Version: V 0.2, 23 rd July 2015

Version: V 0.2, 23 rd July 2015

2.2 Product Line

2.3 Product Group

Version: V 0.2, 23 rd July 2015

2.5 Property Class

Some major used classes are ACTIVITY.API and ACTIVITY.PRESENTATION.

2.6 Product Conditions

Product Condition is where we will define the

Version: V 0.2, 23 rd July 2015

Version: V 0.2, 23 rd July 2015

For example: We are considering ACTIVITY.API,

Some of the frequently used classes are given below:

This is the place where we play around with routines.

In this ACTIVITY.API only, we have to attach routines.

Here, user can define ACTIVITY, PROPERTY.CLASS and ACTION.

We can define routines under following sections.

Version: V 0.2, 23 rd July 2015

Version: V 0.2, 23 rd July 2015

Local routine to perform the required action is attached as Post routine in

Version: V 0.2, 23 rd July 2015

For ex: From the above screenshot, we have given as OFS$OPERATION EQ

It is used for defining various versions in

Here, we will attach VERSIONS.

Version: V 0.2, 23 rd July 2015

No routines should be defined

Version: V 0.2, 23 rd July 2015

It defines the charge that needs to be applied when activity is triggered.

For example: If we increase/decrease Term amount (LENDING-INCREASE-

Version: V 0.2, 23 rd July 2015

4. Activity setup flow of AA

Version: V 0.2, 23 rd July 2015

In the above screenshot, Property class is ACTIVITY.API

Version: V 0.2, 23 rd July 2015

Version: V 0.2, 23 rd July 2015

In this API, we have attached

5. Adding Local Reference Field

AA Properties shares the same field layout across 4 different f iles:

Version: V 0.2, 23 rd July 2015

Local Ref table:

The above local field is attached to the version AA.ARR.ACCOUNT,JAB.AA

Version: V 0.2, 23 rd July 2015