T3TAAC Arrangement Architecture Core R15 v3.1

T24 Arrangement Architecture - Core -
T3AAC - R15 1
The AA module provides a flexible framework that allows a number of products
to be created. It has the ability to allow user to construct banking products by
combining different business components through AA Product Builder. To create
a product, we will be using various product components such as Property
classes, properties and product conditions. Temenos has defined broad Product
Lines. We can create a product group under a product line. From a product
group, products can be designed as stand-alone products or as inheritance
products in a product family. The link between a product and an arrangement
will also be covered, checking out various activities in an arrangement.
AA also provides for simulating activities for “what-if” speculation for new and
existing product instances without creating or affecting live records.

T3AAC - R15 2

T3AAC - R15 3

T3AAC - R15 4
Almost all banking solutions including traditional T24, contain product silos.
The related functionality and product features exist within the respective silos.
In this instance, reusability is limited, creation of a new product / innovation /
modification in an existing product is difficult.
Innovation is about the Financial Institution’s ability to innovate new products
to offer their customers and thus maintain their competitive edge in the market.
We, as their partners, should have the ability to support such innovation with
product features and flexibility.
5
Till Arrangement architecture came into T24, each T24 module - AC, MG, LD,
MM, AZ etc. had a purpose built silo. Functionality and product features exist
within these silos. Each module has different product definitions and
parameters.
Under Account module , we have different types of accounts, such as Current
Accounts, Savings Accounts, Overdraft Accounts and various parameter tables.
Similarly under LD module, we have deposits and lending functionality, with its
own parameter tables. Each of the T24 Product modules have their own
parameter tables, transaction tables and processing logic.
Even to service a single product, multiple modules have to be implemented.
Local Developments for simple things like Availability of a product was
inevitable. Customisation involved additional local developments as per the
client’s requirements.
6
The AA module provides a flexible framework that allows a number of new T24
modules to be created. The application provides a business component based
architecture for the management of products. Using AA, we will be moving to a
modular Product architecture, whereby clients can create their own Products by
using the Components provided by Temenos, and these components can be
reused across many Products.

T3AAC - R15 7
In AA there is a three tiered Product Organisation comprising of Product Lines
defined by Temenos. Product Groups and Products are defined by clients.
Lending, Internet Services, Accounts, Deposits, Product Bundle are some of the
Product Lines in AA.
Every product is an assembly of many components. For example, for the
LENDING products, we have components like Term Amount, Payment Rules,
Limit, Periodic Rules, Accounting, Interest, etc. For Account products, we have
components like Account, Eligibility, Accounting, Charge, Interest etc. These
components are serviced in AA.
8
Product design and servicing are enterprise level functions. Functionality is
encapsulated in a set of common product components. Each component has its
own attributes and actions defined by Temenos.

T3AAC - R15 9
Product Lines are released by Temenos. Each product line is constructed by
combining the various, available, reusable components. Product lines e.g.
Lending, Deposits, Accounts, Product bundle, Relationship Pricing…….

T3AAC - R15 10
T3AAC - R15 11
BMW produces cars and they do not stop with one product, they also produce
motor bikes. These two items, whilst sharing a common purpose to transport
people, are clearly different Product Lines. We call these broad categories as
Product Lines.
Within their car product line, BMW has built a number of models which are
clearly segregated into groups such as the 3 series, 5 series, 7 series, etc. We will
refer them as Products Groups. These product Groups go on to form the highest
level in a complex product line hierarchy.
Within each product group, there are further subdivisions based on various
factors. For instance, the first subdivision is based on the body style of the car
such as a saloon, coupe or touring. This classification creates Product
Derivatives.

T3AAC - R15 12
Product Building structure clearly defines the Product families. The components
like engines, transmission, etc. can be used across different models. The
components have a high degree of reuse and this helps in assembling cars to fit
into the choice, needs, budgets, etc. of customers. This further helps customers
to get the product modified later with their choice. For example, a customer
would have selected a car with standard alloy wheels and later get the wheels
changed with spokes ones or radial ones. Financial institutions would like to
have the same flexibility and ease of designing and selling Products.

T3AAC - R15 13
Application of car model vis-à-vis the financial products is illustrated here.
Car Models could be organised first by Series such as 3-series, then by Model
Range such as 3-series Saloon, Coupe, etc and then by cars.
Similarly, AA Product Line “Lending” is organised first. Under it, there are
different Product Groups such as Mortgages, Home Loans, Personal Loans, etc.
have been created. Finally, each Product Group has multiple derived Products.
For example, the Mortgages Product Group has Products like 3 year fixed
mortgage, 5 year fixed mortgage, Floating Mortgages, etc.

T3AAC - R15 14
T3AAC - R15 15
T24 distinguishes its business applications as Account based and Contract based.
This comes from the underlying business of Banks which do allow balances in
accounts to switch from positive to negative sign on one hand. But on the other
hand a loan remaining always a loan and a deposit for a fixed period always a
deposit till its maturity. Balances in these contracts never switch their
accounting sign.
Account based products normally have some kind of account underlying such
as savings account or current account. Accounts of the Banks are either Nostro
Accounts or Vostro accounts. Based on the limit available for accounts, accounts
are classified as Overdrafts.
Contract type products include term loans, term deposits and long term
mortgages. There is regular payment of interest and redemption of principal in
these type of loans. Repayment may be linear / annuity / other method.
Arrangement architecture has revolutionized this concept.
Lending arrangements and Deposits arrangements have a term / maturity date.
However, Lending arrangements, Deposit arrangements and Accounts
arrangements are opened under T24 Accounts and balances in these can be both
positive or negative.

T3AAC - R15 16
Create an arrangement under Current Account Group and select the Current
Account product.
Commit the Arrangement and get it authorised.

T3AAC - R15
Use the menu path displayed and create a current account arrangement.

T3AAC - R15
Input customer ID and currency of arrangement and validate the record. We may
notice that on creation of the new Arrangement we had AAACT…. Which is the
activity ID of creation of this arrangement. We would discuss about Activity in
detail during this course.
On validating the record the AA version would come up and the arrangement id
is generated.
We can see the components of the arrangement in this version.

We would read how to default values to these components, whether they can be
amended and if so, on what limitation in the duration of this course.
You may note that under the Account tab highlighted the Account number
associated with this arrangement is can be seen.
Now, commit the record.

T3AAC - R15
In order to authorise the record, open the record in unauth status.

T3AAC - R15
The arrangement is now authorised.

T3AAC - R15
Now view the arrangement and identify the components of the arrangement
account.

T3AAC - R15
T3AAC - R15 23
To recap Attributes are common features of a Component across different
Products. For example, the Component Engine has Attributes Fuel Type, Power
Output, Torque, etc. across different Products.
Similarly it has Actions or Functions like Start, Stop, etc. across different
Products.
Thus a Component has common Attributes and Actions across different

Products.
In AA we refer to these Components which have Attributes and Actions as a

Property Class. In the next Page, we will compare a Component of a Car and a
Property Class of a Banking Product to understand this concept better.

T3AAC - R15 24
The Components for vehicles vis-à-vis Banking products are compared.
In our example, the Wheel Component of vehicles are compared with the
Interest Component of Banking Products. Similar to other Components of
Vehicles viz. Transmission, Engine, Body, etc. we can think about the
Components Payment schedule, Charges, Term Amount (Period plus Principal)
of Banking Products.
In AA, the Attributes and Actions of Components are defined for every Property
Class.

T3AAC - R15 25
In some Products, there will be a requirement to have more than one Component
of the same type. These multiple instances of a Component will have the same
attributes but they could have different values.
For example, in case of a Car, the component Wheel has two instances Front
Wheel and Rear Wheel. Both of them viewed as the Component Wheel will
have same Attributes like Radius, Type, etc. but the values of these Attributes
might be different in case of Front and Rear Wheels. Similarly in case of a
Banking product, for example, in a Lending Product, there could be a
requirement to have two types of Interest viz. Principal Interest and Penalty
Interest.
In this case both belong to the Property Class Interest. But they could have
different values for the Attributes like Rate, Type, etc. These named types or
instances of a Property Class are termed as a Property in AA.
In AA, while Client can create new Properties based on Property Classes,
Property Classes themselves can be created only by Temenos.

T3AAC - R15 26
In a Product, we can have any number of Properties derived from a Property
Class, but the attributes of all such Properties are same as that of the Property
Class. They have the same Attributes and do the same actions. However, their
Attributes can have different values as explained earlier. It is the Properties
rather than the Property Classes, which are used to define the Products. Some
properties are hidden to prevent users from modifying / viewing the attributes at
arrangement level. For such a Property, the Property Type field is set as
‘Product.Only’.

T3AAC - R15 27
In AA, Product Lines which are combinations of Property Classes have been
defined by Temenos.
Some of the Product Lines unique to Banking Industry would be:
● Loans
● Deposits
● Accounts

T3AAC - R15 28
In AA under each Product Line, multiple Product Groups can be created by
Clients. While the Product Line has been defined by Temenos which is a
combination of Property Classes, Clients can create their own Product Groups
under a Product Line.
A Product Group is a sub-set of the Property Classes of its Product Line. Of

course, all the mandatory Property Classes need to be retained in a Product
Group and optional Property Classes may be included or omitted. Further, at a
Product Group level, we actually need to specify the Properties (atleast one)
for each Property Class.

T3AAC - R15 29
For example, a Product Line has 3 Property Classes: Account which is a
mandatory one, Interest and Charges which are optional. In the Product Group
formed under the Product Line, the Property Classes Interest and Account are
used, while the Charges can be omitted.
Further, under the Interest Property Class, we have two Properties - Principal
Interest and Penalty Interest. Under the Account Property Class we have only
one Property, Account.

T3AAC - R15 30
In AA under each Product Group, multiple Products can be created by Clients. It
is finally the Products which a Bank can offer to its Customers. And it is THAT
specific product, for that customer, which is the contract called an
Arrangement.

T3AAC - R15 31
A Product Condition is a set of rules set for a Property Class. It defines the
default values for its Attributes. It is also used to define certain other conditions
like Negotiation Rules, etc. which we will discuss later. Example: For Interest
Property Class, we can define a Product Condition with the Interest Type
Attribute set to Fixed, Rate set to 5, and set other rules.

T3AAC - R15 32
Product Conditions are linked to Property at Product level. As economic and
processing conditions may change over time, clients can optionally set an
effective date for such conditions.

T3AAC - R15 33
Answers:
1. a
2. b
3. a

T3AAC - R15 34
4. a
5. b
6. a

T3AAC - R15 35
T3AAC - R15 36
To summarise the features of Product hierarchy:
It is possible for a Product to have only one Parent Product, while a Parent
Product may have multiple Child Products.
A Parent Product and child products down the line must be of the same Product
Group.
A Product can be set to either “saleable” or it could be only for inheritance.
What this means? When a Product is saleable, it means it is complete with
Product Conditions for all its Properties.
When it is only for inheritance, it means the Product is not complete i.e. All
the Properties of the Product are not defined with Product Conditions. In
this case, its only use will be to be a Parent such that Products at a lower level
will inherit its Properties.
It is possible to set a Parent Product also as saleable. This just means that in
addition to being saleable, its Properties can be inherited by its Child Products.
The benefits of Product Inheritance are :
 Clear organization of Product hierarchy
 Each saleable Product can be much simpler
 Differences between Products are immediately apparent
 Variations of Products can be easily done

T3AAC - R15 37
Earlier you have seen how a Car Product can be designed using inheritance and
Product hierarchy. Now you will be seeing the concept of Product hierarchy
with a financial example.
In this example, we have the Lending Product Line. The Product Line which has
been defined by Temenos has certain mandatory and certain optional Property
Classes.
The Product Group Mortgage under the Lending Product Line, has been defined
by User with Property Classes from that of Lending Product Line.
In addition, User has defined Properties for the Property Classes defined in the
Product Group and specified whether the Properties are mandatory or optional.
User can attach multiple Properties for a Property Class. For example, in this
case two Properties Principal Interest and Penalty Interest have been attached to
the Interest Property Class.
You will be seeing in the next page how a Product can be defined under this
Product Group. System will ensure that each mandatory Property Class of the
Product Line will have at least one Property defined in the Product level.

T3AAC - R15 38
Clients can create Product Conditions for every Property Class and then attach
them to the Properties at a Product Level.
In the above example there are three Product Conditions for Term Amount
Property class. You can learn in detail about the Property Classes used here in
the AA-Lending course. The Property Commitment has been attached to the
Property Class Term Amount at the Product Group level.
One of the Product Conditions (25 yr Mortgage) of Term Amount Property Class
is attached to the Property Commitment at Product Level.

T3AAC - R15 39
In the above example, we have 5 Product Conditions for the Payment Schedule
Property Class. In the Product Group, the Property Repayment Schedule has
been linked to the Payment Schedule Property Class. At the Product Level, the
Product Condition (Constant Monthly) is attached to the Property Repayment
Schedule.

T3AAC - R15 40
Here the Payment Rules have two Properties Repayment and Principal Decrease
linked to it in the Product Group. One of the 4 available Product Conditions of
Payment Rules Property Class is attached to each of its associated Properties at
Product Level.

T3AAC - R15 41
The only Product Condition created for Accounting Property Class is attached to
its associated Property at Product Level.

T3AAC - R15 42
A product is created when Product Conditions associated with respective
Property classes are linked to relevant Properties at Product level.

T3AAC - R15 43
In the example, we have three levels of Products. For Capped Interest Mort
Product, parent is Flexible Mortgage. In turn, for Flexible Mortgage Product,
parent is Mortgage. Thus a 3 level product hierarchy has been formed. Top most
is defined with Product Conditions for some Properties and is set for inheritance
only. It is the same case for middle level Products which are also incomplete
even after inheriting Properties from parent. Middle level products are also set
for inheritance only. Finally, lower level Products are for sale. It is visible that
some Properties are re-defined with different Product Conditions at different
levels. Every level will inherit conditions from its higher level only for
Properties not defined in itself. This means if Product Conditions are defined for
a Property both at lower level and higher level, condition at lower level
prevails over the one at higher level.
For example, Interest Property is defined with different conditions at all three
levels. Lowest level Product will retain what is defined in it and will not inherit
interest condition from parent. Capped Interest Mort Product will inherit
conditions from higher levels for all Properties other than the ones defined in
itself. This means that child Product will be available for sale with Product
Conditions defined at child level plus other conditions inherited from its parent.
Advantage of this is that it is simple to create new Products at lowest level,
which have slight variations to existing Products without going through
whole process of creating a new Product with Product Conditions for all

T3AAC - R15 44
Properties.

T3AAC - R15 44
Now that you have an understanding of how a Product is designed, we will see
what an Arrangement is. An arrangement is an instance of a Product associated
with a Customer. In simple words, for a financial Product, when a Product is
sold to a Customer, it becomes an Arrangement with the Customer.
Creating an Arrangement involves “negotiating” with the Customer for changes

to the standard product specification.
Technically an Arrangement is created with a copy of the Product Conditions,

some of which can then be modified, and some cannot.
You will learn about what is negotiation in the next page.
With the car analogy, the engine cannot be modified, the wheels can optionally
be modified, and the colour must be chosen. This means that while the engine
cannot be negotiated, the wheels and colour can be negotiated.

T3AAC - R15 45
Earlier, we have seen the linkage among Product Line, Property Class, Property
Class Attributes, Product Group, Property, Product and Product condition.
An arrangement is Customer specific offering of a Product. An Arrangement is

in fact a set of conditions called Arrangement Conditions which are inherited
from the Product Conditions of respective Product. For example, when a
Mortgage Product with LIBOR floating rate and 0.5% standard margin can be
offered to a Customer with standard margin reduced to 0.25%. In this case, the
Product Condition for the Interest Property has been modified at the
Arrangement level and it becomes an Arrangement condition. This
modification is possible only if the Negotiation Rules set at the Interest Property
Condition allows this.

T3AAC - R15 46
1. a
2. b
3. c

T3AAC - R15 47
T3AAC - R15 48
Product Builder of AA can be used to construct AA Products and publish it into
a single product Catalog.
AA Product Builder leads into Product Lines, which are predefined by Temenos.
Product lines currently available are Accounts (for retail accounts like Savings
and Current accounts), Deposits (for retail term deposits), Internet Services (for
ARC IB service configuration), Lending (for retail term lending products),
others (for any other T24 products and other Bank products for comparison
purposes), Relationship Pricing (for Preferential Pricing), Product Bundle,
Mobile Services, Proxy Services and Agent . Product Lines can be created only
by Temenos and they cannot be created by the User.
These “building blocks” can be used to go to the next level of Product Groups,
which are pre-defined for select T24 applications. They are user definable for
other products.
The final stage is defining the Products which are completely user definable.
These individual Products are made available for sale to Customers by including
them in Catalog.

T3AAC - R15 49
Banks desire to have a single mechanism to define characteristics of a Product
from start to end, instead of setting different parameters for different aspects.
Likewise, they also want to have a single Catalog to display all products to
effectively sell them. Temenos solution of ARC – Acquire , Retain and Cross
sell – enables this. User can easily define all their products as well as
competitors' in a single Catalog through Arrangement Architecture (AA).
AA has its own set of products, like AA Loans and AA Deposits which could
be built by using AA Product Builder. This acts as a single mechanism to define
all characteristics of each AA product. This concept has been extended to cover
select parameter tables of select retail applications of T24. Accounts, All in one
accounts, Mortgages and Loans and Deposits modules can be covered.
Transaction type tables of these applications can be built and maintained by AA
Product builder. If they are built using AA Product builder , then later
maintenance is possible only though this builder. Before including them into a
common Catalog, it is also possible to link a version of T24 for them so that
from Catalog it is easy to access them.

T3AAC - R15 50
In product builder, the first step is to have broad product lines. These are pre
defined by Temenos. Product Lines namely Lending, Deposits, Accounts,
Bundle, Relationship pricing, Agent are dealt under Retail. The other product
lines are Internet Services, Mobile Services, Proxy Services and Others.
From product line, we move to product groups which are built through
AA.PRODUCT.GROUP. These can be built by Clients.
The property classes also have been pre defined for each of the Product Lines.
Thus, they get the basic attributes of the product line.
Property classes are pre defined by Temenos. The classes are like Interest,
General Charge etc. However every property class may have one or more
distinct properties. These are user definable. Under interest, user can define a
fixed interest or floating interest with or without margin as different properties
and pick what is needed for a particular product.

T3AAC - R15 51
AA.PRODUCT.DESIGNER application is used to define products. It is advised
to use the pre set versions to go from product line to product group and then on
to products.
Under a Lending product line, for a product group called PERSONAL.LOANS,
we can define any number of products. For one such product called
PERSONAL.LOAN, we can define all its properties like currencies allowed,
maximum Term, interest rate etc.
After defining the product, it is to be added to Catalog. This is a two step
process. When the product is getting defined, T24 does not check whether all
properties have been defined. However, when the product is subject to proof,
it validates its conditions, accounting rules and calculation sources. If all these
choices could be mapped, then proofing is successful. After that, it has to be
published to add to Catalog.

T3AAC - R15 52
T3AAC - R15 53
The primary tool for designing and publishing products is the Products
Configuration Screen which enables a user to
1) Browse Temenos defined Product Lines and amend descriptions if needed
2) View, amend and create Product Groups and
3) Products and
4) Proof and
5) Publish products
This comprises several parameter tables like AA.PRODUCT.LINE,
AA.PRODUCT.GROUP, AA.PRODUCT, AA.PROPERTY,
AA.PROPERTY.CLASS etc that are used to define Arrangement Architecture
products. The pre packaged tools help create and maintain products through
thoughtfully created composite screens, enquiries and versions.

T3AAC - R15 54
All product lines are pre configured. Few product lines can be used to configure
classic T24 modules - ACCOUNTS Product Line for configuring AC module,
LENDING Product Line to configure loan products in LD, MG and AZ module.
Full use of LENDING is made available to those who have installed AL (AA
Lending).
INTERNET.SERVICES Product Line is meant for configuring ARC Internet
banking services configuration. OTHER Product Line can be used to publish
other T24 products as well as other banks’ products for comparison.
While only Temenos can add new product lines in AA.PRODUCT.LINE, it is
possible for Clients to change description of these product lines as they desire.
This could be achieved by amending the existing description.

T3AAC - R15 55
View icon can be used to view existing records.
Edit icon in Product Lines can be used to change description of records in
AA.PRODUCT.LINE.
While T24 parameter tables cannot be automatically generated or maintained for
any product under OTHER product line, it is possible to link these products to a
T24 version and also include these in Product Catalog.

T3AAC - R15 56
By using the icon for Drilling down to instances, Clients can choose a Product
line and can drill down to view existing product groups and from there to view
the existing Products for the desired group. If the user does not want to amend
an existing product, they can choose to create a new product.
By using the icon for New instances, users can create records at the next level.
While at Product Line, if this icon is clicked, then it is possible to create new
record in Product group in application AA.PRODUCT.GROUP. While at
Product group, if this icon is clicked, then it is possible to create new record in
AA.PRODUCT.GROUP.
While product lines are pre defined by Temenos, it is possible to define new
product groups in AA Loan under LENDING product line. For AC, AZ, LD and
MG modules, records in AA.PRODUCT.GROUP are already pre defined.
Product groups for any other products can be defined under OTHER product
line.
While creating new product groups, Group type can be set as INTERNAL or
EXTERNAL. INTERNAL means that the group being defined is the Bank's
own product and is available for sale to its customers. At times, it may be
necessary for a Bank to do comparison between its own product and one by its
competitor to show how its product is superior when compared to products of
other Banks.. Hence, products of others can be defined as EXTERNAL,
which are not available for sale here.

T3AAC - R15 57
T3AAC - R15 58
You have learnt earlier that a Property Class is a fundamental building block of
AA and that a Product Line is a combination of Property Classes. Property
Classes are released by Temenos and you can only amend their Description.
The components are reusable and can be used across several Products.

T3AAC - R15 59
Property Classes are building blocks, released by Temenos and you can only
amend their Description.
Financial institution uses these functionality of “building blocks” to construct
individual products which are available for sale to its customers. (Navigate:
admin/product builder/properties => select a CLASS )
CCY – Product conditions for the same product will vary by currency (e.g.
interest and principal conditions). The product property condition definition
(AA.PRD.DES.xxxxx) will contain currency in the key. If CCY is not defined
then property will NOT be based on currency.
OPT.CCY - Indicates that properties may or may not have Currency component
in them. But it needs to have a default non currency condition and when a
explicit currency condition is not stated, it picks the default condition for
processing. Currently only CHARGE property supports OPT.CCY option.
DATED – Product conditions can vary by date and relevant dated property
definition should be used when performing processing. The product property
condition will contain an effective date in the record key. If DATED is not
specified the record will not contain a date.
MULTIPLE – Allows more than one property of that class to be defined for a
single product. If MULTIPLE is not specified only one property of this class can
be linked to an AA product.

T3AAC - R15 60
MERGE – Allows Child condition not to override parent condition blindly. This option
indicates that the property class has special merging properties when doing proofing and
publishing. The child condition does not override the parent condition blindly as other
classes do.

T3AAC - R15 60
Product Commission property class enables configuration of financial product
line / product Group / Products those are eligible for Rewards calculation.
Can define if rewards are paid immediately or is scheduled.
This property class is applicable for Agents and Rewards product line .
Agent Commission Property Class links the Rewards arrangement/Agent

Arrangement to the Financial arrangement.
Provides the ability to override the predefined Rewards/Commission that is
defaulted from Product commission.

T3AAC - R16 61
FORWARD.DATED – Allow users to define conditions applicable on a later
date at the Arrangement level. When an action is initiated on an arrangement
involving this activity, system will show the condition which is currently
applicable and also future condition if any. Future condition can be added,
amended or deleted by the user, but conditions which are currently applicable
cannot be deleted. Currently enabled for ACTIVITY.CHARGES,
ACTIVITY.RESTRICTION, CHARGE, INTEREST and PAYMENT.SCHEDULE.
ARRANGEMENT - This option behaves much like TRACKING.ONLY type,
except that the property conditions will be allowed to be amended at the
arrangement level subject to negotiation rules. So, when a property class is
defined with this type, then, any activity done at arrangement for the property of
this class will always see the product and default them in the arrangement
condition. This option indicates that the property of this class has some special
arrangement level processing, hence, the field values at the arrangement level
will not be merged with any of the previously amended arrangement values.
Currently, only BALANCE.MAINTENANCE is defined with this type.
TRIGGER – Properties related to this property class will not appear in
Arrangement Activity screen. When certain activities related to these property
classes are triggered and validated in the Arrangement activity, property
associated with this property class appears in the arrangement. E.g. Charge
Override – This Property appears in an arrangement after an Activity charge is

T3AAC - R15 62
triggered and validated.

T3AAC - R15 62
VARIATION: From R14 Variation is a Type which can have an additional
component in the Product condition.
Variations enables variations in a single product meaning a single product for
preferential pricing strategies.This mechanism makes use of different conditions
(i.e. it has multiple variations) based on characteristics such as channel and or
customer. The variety of a product a customer receives is dependent on both
eligibility and a priority order (where the client is eligible for multiple
variations).
Prior to creating products with variations, the “named” variations are to be
defined. These will be used in both the product designer (to specify a
priority) and within the IDs of the product conditions.
A virtual table AA.PRODUCT.VARIATION holds the list of available product
variations. Variations are defined in the virtual table
AA.PRODUCT.VARIATION.
For example, Interest product condition FIXED.RATE-USD-20120101 can have

the key “FIXED.RATE-USD-INTERNET-20120101” to hold specific interest
conditions for products subscribed through “Internet”. The 3rd component in the
key “INTERNET” should be a valid entry in the EB.LOOKUP file. Variation
enables products to be offered to Customers through various channels.

T3AAC - R15 63
TRACKING – Certain types of property (e.g. interest conditions) may be
defined at the product level and the arrangements of that product simply 'track'
the product definition and do not require any definition at the arrangement level.
If TRACKING is specified then a property of this class can be defined as
TRACKING, CUSTOM.TRACKING or NON-TRACKING in the product
definition.
NON.TRACKING - Indicates that the properties belonging to this class should
only have fixed link behavior. In other words, these properties may not have
CUSTOM.TRACKING or TRACKING link to the arrangement.
TRACKING.ONLY - Indicates that the properties of this class can ONLY have
tracking behavior. Also, the properties of this class should be stated as
PRODUCT.ONLY in AA.PROPERTY.
BALANCE.PREFIX : A property class can hold related financial balances This
field holds the allowed prefixes for use in the balance type and should reflect the
possible stages in the lifecycle. Values should be 3 alphanumeric.
CUR - The current or live value of the property balance; ACC - The current
accrued balance for the property; DUE - The due balance for property; AGE -
An aged balance where the prefix will be determined by the overdue status. A
value of AGE here denotes that the balance can move through multiple
stages based on the OVERDUE property definitions.

T3AAC - R15 64
AA.PROPERTY.CLASS.ACTION is the application which holds information on
actions which can be performed with a PROPERTY CLASS
The user will be able to get information on whether the action will generate an
accounting entry and also which Product Line will be affected.
(Navigate: Admin/Product Builder/ Additional Settings/Actions => Select
Interest > Accrue Action )

T3AAC - R15 65
Please view the record existing under Property Classes – Customer and Term
Amount.
View details tab as also the balance pre-fix as applicable to each product line.
Discuss the basic attributes.

T3AAC - R15 66
Customer Property class has attributes Dated and Non-Tracking. This indicates
that the product condition will have date as part of its record Id and being
marked as Non Tracking, this property cannot be tracked. Please note that there
are no balance prefix defined for this property.
Term Amount property class has attributes CCY, Dated and Non-Tracking. The
product condition of this property has currency as part of its record Id. When the
product is to be made available in say, 4 different currencies, product
conditions have to be created in all of these 4 currencies. This also indicates
that the product condition will have date as part of its record Id and being
marked as Non Tracking, this property cannot be tracked.
Balance prefix is CUR & TOT for Lending product Line and TOT for Deposits
product line. This indicates that this property needs to have balance types
defined before using them in our Product Group and Product. Term amount
property class does not apply to Accounts Product Line, while Customer is
mandatory for all financial product lines.

T3AAC - R15 67
Now that we have learnt about a Product Group, we will go into a Product. We
sill start with Properties.
In AA we can create named types (instances) of a Property Class which are
known as PROPERTIES.
AA.PROPERTY is the T24 application that is used to create properties.
As you have seen earlier, you can attach multiple properties to a Property Class
in a Product Group, provided it is allowed in the Property Class.
PROPERTY.TYPE: It can have a null value or one of the values: Product Only,
Suspend, Suspend Overdues, Variation, Residual accrual, Credit, Forward dated,
Accrual by Bills, Commission, Rebate unamortised.

T3AAC - R15 68
PRODUCT.ONLY: The Property details will be hidden at an Arrangement
level, and user cannot view or amend them. For example, Properties under
ACCOUNTING Property Class will have this value. It is to prevent the User
from viewing or modifying Accounting rules at an Arrangement level. It is
enough if the Property is attached to the Product.
SUSPEND: Currently, it is applicable only to Properties under Property Classes:

INTEREST and CHARGE. This means that Property would be allowed to be
suspended. For example, accrual of Interest can be suspended.
SUSPEND.OVERDUE: Existing and past Overdues in the Property will be also
suspended when the Property is suspended. This goes along with the value
SUSPEND i.e. SUSPEND also be one of the values of PROPERTY.TYPE.
Variation: Although Temenos define the AA.PROPERTY.CLASS records type

as variation another step to configure is to flag the AA.PROPERTY record also
to be a variation. A property of Property Class that is variation specific can have
a property can be variation specific while another property of same property
class need not have any variations. Remember if variation condition defined for
a property, at Proofing and Publishing stage if a Property isn’t flagged as a
variation, an error will be shown

T3AAC - R15 69
Residual Accrual - When interest accrued is greater than the amount made due
for interest for that period, excess amount is moved to RES<INTEREST>
balance of this property
Credit – This Property is payable to customer, Applicable for charge property,
e.g. bonus
Forward dated - The property needs to be set as FORWARD.DATED in type
field of AA.PROPERTY file so that the forward dated conditions appear
alongside the current condition as multiple tabs, for negotiation at a later date
Accrual by Bills – The system accrues the penalty interest which is stored in
AA.INTEREST.ACCRUALS .It allocates the accrued penalty interest
proportionally to each bill based on the calculation balance. If interest property
is set as “ACCRUE.BY.BILLS”, then routine AA.ACCRUE.BILL S will be
called after normal accrual process is completed to update bill details, with
accrual corresponding to that bill.

T3AAC - R15 70
From R15, we have two new property types
Rebate Unamortised –
There can be any number of charge properties associated with a loan product.
Amongst them only few might have a requirement to rebate back the
proportional amount. Rebate unamortized property type identifies the properties
for which rebate functionality is required. Properties which are marked with this
property type would only be rebated back.
Normal charges without property type as Rebate Unamortised can be set to
amortize. When an arrangement with such a charge definition is paid off, it
should recognise the unamortised amount immediately, without depending on
the configuration in payment schedule.
Periodic. Charges cannot be of the type Rebate unamortized.
Property type “COMMISSION” is introduced to identify charges those are used

as commissions. The bills that are generated for these charges indicate that they
are commissions.
Null indicates that it is a normal property, there are no special features

T3AAC - R15 71
Create new property for Customer Property Class

T3AAC - R15 72
Input property names as desired in record Id for Customer. Give GB description
and full description as applicable.
See that the respective property class is automatically defaulted. Commit the
record.

T3AAC - R15 73
T3AAC - R15 74
We now know how to create a Property. But it is the Product Condition which is
practically used in a Product to default values in an Arrangement and to control
their modification. We will go into details of the Product Conditions now.

T3AAC - R15 75
What is the underlying application that is used to store all the information about
Product conditions?
Do you still remember?

Product Conditions belong to a Property Class and you can create different
Product Conditions for a Property Class
For each Product Condition you can create different dated records
For each Property class a separate application is created with the name
AA.PRD.DES.<Property class name>.
You will see an example for this in the next page.

T3AAC - R15 76
Product condition can be currency-specific. You may notice that
TERM.AMOUNT Product Condition, Currency USD is part of Id.
If Property classes has TYPE set to CCY then Product condition can be currency
specific. For such Classes, Products that support multiple currencies will require
Product conditions for each currency. Product Conditions that are not currency
specific just have one condition, and currency will not be part of ID. For
example we have a Product Condition called FIXED.INTEREST-USD. If you
support a GBP as well, you need a Product Condition called FIXED.INTEREST-
GBP. When assigning conditions to a Property the user simply assigns the
condition FIXED.INTEREST . When a new arrangement is created appropriate
conditions for currency of arrangement will be used.
TYPE = CCY - Specifies whether Properties created for a Property Class can
have Product Conditions based on currency or not. If TYPE field contains a
value CCY, then Product Conditions for property will vary by currency. Product
condition definition will contain currency in key. If CCY is not defined,
property will NOT be based on currency.
TYPE = DATED - Specifies whether Properties created for a Property Class
can have date Product Conditions or not. If this field contains a value DATED
then Product conditions can vary by date and relevant dated property definition
will be used when processing. Product Condition will contain an effective
date in record key. If DATED is not specified record will not contain a date.

T3AAC - R15 77
The currency forms a part of the ID of Product Conditions that are currency
specific.
Assumption: TRG Product contains the a property that is of TERM.AMOUNT
type. The TRG Product supports USD and GBP.
Question: How many Product conditions needs to be created for the property
which is an instance of TERM.AMOUNT Property class?
Answer: We will have to create two Product conditions. One for USD and
another for GBP.

T3AAC - R15 78
Each Product Condition record in T24 has an Effective Date. The effective
date represents the date on which that particular set of values takes effect for a
Product and for any Arrangements which “track” Changes to Product Conditions
are typically controlled by effective dating. Note that any Product Condition
can be set for Tracking at a Product level.
This allows you to set up any changes to Product Conditions in advance, and
when Product using the conditions has been re-published, they will
automatically switch over to the new condition on the effective date.
When you do not specify a date in the Id of a Product Condition, date part of
the Id defaults to the today’s system date.

T3AAC - R15 79
After you create a record for a Product Condition with a new effective date, it is
essential to proof and publish all the Products to which the Condition has
been attached. Then the new condition values will be used in Arrangements
created on or after the effective date. You will learn more about proofing and
publishing later in this course.

T3AAC - R15 80
To create variations of a product, first create Product Conditions for each
property that is specified as having a variation.
INTEREST Property class is currency specific and dated. When the variation
product condition is for the variation Branch, the product condition is:
FIXEDRATE-USD-BRANCH-20100806
ACTIVITY.CHARGES Property class is dated and when the product condition

is created for the Branch variation, the product condition is:
VEHICLE.LOAN-BRANCH-20100101
If the AA.PROPERTY.CLASS type is defined as “Variation” then the ID

structure of the product condition would have one additional component, which
could accept any value defined in the virtual table.
When a key is defined in AA.PRD.DES.XXX of a property class which supports

variation, a validation would be done to check whether it is a valid variation
defined in AA.PRODUCT.VARIATION virtual table and error message is
displayed if the same is not found

T3AAC - R15 81
T3AAC - R15 82
To summarise, the currency and effective date of a Condition are part of ID of a
product condition. The currency defaults to the local currency and the
effective date defaults to System date. So to create a USD condition with a
future effective date, enter the ID as the name of the condition, then a hyphen,
then the currency, then a hyphen, then the date.
Example, FIXED.RATE-USD-20080315.
IF type of a property class is CCY, then its product conditions should be
currency specific. CCY will be part of Id.
IF type of a property class is DATED, then its product conditions should be Date
specific. Date will be part of Id. The date represents effective date of the
product condition.
IF type of a property class is OPT.CCY, then its product conditions may be
currency specific. CCY may or may not be part of Id. IF no currency is
specified, then two - - will be defaulted after Product condition identifier.
Currently CHARGE Property class is OPT.CCY type.

T3AAC - R15 83
You can see here a model Product Condition set for the TERM.AMOUNT
Property Class.
Default Values
You can see there are different fields like Amount, Term, etc. which are the
attributes of the TERM.AMOUNT Property Class. Here, we have defined a
value of “25Y” for Term and “No” for Revolving. When this Product Condition
is attached to a Property (of the TERM.AMOUNT class) in a Product, these
values will be defaulted in an Arrangement created for the Product.
Negotiation Rules
We will learn about this tab in the later part of this course.

T3AAC - R15 84
Negotiation Rules are used to specify which attributes may be amended at the
Arrangement level, and which must remain the same across all Arrangements.
For each attribute that is modifiable, the negotiation rule defines the rules by
which they may be modified.
For example, a product may be specified as having a base term of 5 years. At the
arrangement level, the bank may wish that the user have the ability to negotiate
from 3 to 10 years, A user would define a negotiation rule on the
TERM.AMOUNT property condition for the TERM attribute with a
“MINPERIOD” of 3Y and a “MAXPERIOD” of 10Y.
Another typical example would be the amount of a loan. Most loan products do
not have a default value but rather have a minimum and maximum amount. This
is accomplished by the definition of two negotiation rules on the Term Amount
property for the AMOUNT attribute.

T3AAC - R15 85
This is an example of negotiation rule for a product condition. We will see more
of this, in detail, in the coming slides.

T3AAC - R15 86
Now, we will go into the fields of Negotiation Rules tab and find out what they
stand for.
Field: DEFAULT.NEGOTIABLE, It is a Mandatory field.
It has 2 Options: Yes and No.
It defines whether all attributes (fields) of the Property Class can be negotiable
or not - at a top level.
This top level rule can be over ruled for specific attributes by setting the fields
below. In this instance, UPDATE.COMMT.LIMIT and REVOLVING Fields set
as Non-negotiable will override the Default Negotiable setting of Yes at top
level.

T3AAC - R15 87
Let us learn about the multi-valued NR.ATTRIBUTE field.
This specifies the attribute of the Property Class, for which a negotiation rule is
to be defined in the associated fields NR.NEGOTIABLE through to
NR.MESSAGE.
These attributes will become the fields in the Arrangement.
Must be a valid attribute of the Property Class. In this example, where the
Product Condition is set for the TERM.AMOUNT Property Class, it should be a
valid attribute name of the TERM.AMOUNT Property Class.

T3AAC - R15 88
We will now look into the Field NR.OPTIONS. It is a sub-valued field i.e. it can
have more than one value for each Attribute.
NR.OPTIONS has a list of options with values:

Negotiable
Non-Negotiable
Override
Fix value
Mandatory
Resetting
NonResetting
We will explain about these values in the next page.

T3AAC - R15 89
The value NEGOTIABLE indicates that the associated Attribute (i.e. field) can
be negotiated (amended) at the arrangement level.
The value NON-NEGOTIABLE indicates that the associated Attribute cannot be
amended at the arrangement level.
Both NEGOTIABLE and NON-NEGOTIABLE cannot be defined together.
The value OVERRIDE specifies if a default override message should be
generated whenever the default value is modified at the arrangement level.
This feature will be useful for the Authoriser to know which of the defaulted
values have been modified at the Arrangement level.
If OVERRIDE is not specified, no override will be generated.

T3AAC - R15 90
Some of the Attributes have been set as Mandatory at the Property Class and this
setting cannot be changed.
However, you can set an optional attribute as Mandatory, by specifying the
value MANDATORY. The value MANDATORY specifies if the Attribute is
mandatory for this product condition. Can only be specified where the Attribute
is not defined as mandatory in the property class.
This means a value has to be mandatorily input for this attribute at the
Arrangement level.
The value FIX-VALUE specifies if the Attribute value is to be fixed at the

arrangement level. If FIX-VALUE is not specified, the Attribute value will
vary with the changes to the underlying product condition.

T3AAC - R15 91
We will look into NR.TYPE here:
This specifies the rule for comparing the value input in an Arrangement against
set values here.
For example, MINIMUM against Amount attribute means the value input in the
Arrangement should have this minimum value.
This is sub-valued within an Attribute, and thus it is possible to define more than
one negotiation rule for an Attribute.
MAXIMUM indicates the Amount attribute can go up to this maximum value.
The NR.TYPE input must be a valid record ID from EB.COMPARISON.TYPE
table.

T3AAC - R15 92
NR.VALUE
This field specifies the value that links to the rule in field NR.TYPE.
This is the value(s) to compare against the value input in the Arrangement.
NR.MESSAGE
Specifies whether to raise an error or override message when the rule is broken
at the Arrangement level.

T3AAC - R15 93
We will now look into the Field DEFAULT.ATTR.OPTION. It is an optional
field.
Allowed Values are RESETTING and NON-RESETTING.
RESETTING denotes that during any Renewal Activities (for eg :
CHANGE.PRODUCT, RESET) the arrangement conditions will be reset from
the Product you are changing to.
NON-RESETTING denotes that during any Renewal Activities arrangement
conditions will be maintained from the Arrangement level.
The top level default attribute option can be modified at attribute level
using the drop down in NR.OPTIONS

T3AAC - R15 94
Let us see a Negotiation Rule set in a Product Condition to TERM.AMOUNT
Property Class, which has attributes for Term, Amount, etc.
You can see that default values for Amount is set to null value, Term to 25Y,
Revolving to NO and UPDATE.LIMIT to None. Here, by default all attributes
of Term Amount Property Class are negotiable i.e. they can be modified in an
Arrangement. Restrictions to this general rule is defined under a set of
associated fields starting with ATTRIBUTE. Since Amount does not have a
default value, it will be null in an Arrangement. Amount is a mandatory
Attribute and User will input the value and commit. When the amount is less
than 200000, it will be an error condition. When the amount exceeds 750000, it
will raise an override message. Though by default all attributes are negotiable,
there is an exception to this rule.
Both the attributes UPDATE.COMMIT.LIMIT (set with a default value of
NONE) and REVOLVING (set with a default value of NO) are not negotiable
i.e. their defaulted values cannot be modified in an Arrangement.
Please note that we have not set any rule for the Attribute TERM. What will
happen to that? By default any attribute is negotiable.
Thus TERM is negotiable. It will be defaulted with the set value of 25Y in an
Arrangement. Since no rule has been set for this attribute, User can modify it to
any value in an Arrangement.

T3AAC - R15 95
Let us see a Negotiation Rule set in a Product Condition to TERM.AMOUNT
Property Class, which has attributes for Term, Amount, etc.
You can see that default values for Amount is set to null value, Term to 25Y,
Revolving to NO and UPDATE.LIMIT to None. Here, by default all attributes
of Term Amount Property Class are negotiable i.e. they can be modified in an
Arrangement. Restrictions to this general rule is defined under a set of
associated fields starting with ATTRIBUTE. Since Amount does not have a
default value, it will be null in an Arrangement. Amount is a mandatory
Attribute and User will input the value and commit. When the amount is less
than 200000, it will be an error condition. When the amount exceeds 750000, it
will raise an override message. Though by default all attributes are negotiable,
there is an exception to this rule.
Both the attributes UPDATE.COMMIT.LIMIT (set with a default value of
NONE) and REVOLVING (set with a default value of NO) are not negotiable
i.e. their defaulted values cannot be modified in an Arrangement.
Please note that we have not set any rule for the Attribute TERM. What will
happen to that? By default any attribute is negotiable.
Thus TERM is negotiable. It will be defaulted with the set value of 25Y in an
Arrangement. Since no rule has been set for this attribute, User can modify it
to any value in an Arrangement.

T3AAC - R15 96
Create a new Product condition for Term Amount property class.
Set the following rules:
Term to default as 3Y, but Negotiable between 1 and 5 years
To produce overrides if negotiated otherwise
All attributes, by default are Negotiable

T3AAC - R15 97
A new Term amount product condition with ID as TERMAMOUNT is created.
Please note the default date and currency in the record ID. Term is input as 3
years, the attribute is left negotiable with a minimum period of 1Y and a
maximum period of 5Y, override is marked for negotiation beyond these.
Default negotiable is marked as Yes.

T3AAC - R15 98
1. b
2. c
3. b

T3AAC - R15 99
Controlling Attribute values of an Arrangement over a period of time is done by
Periodic Rules, which in turn depends on Periodic Attributes.
Periodic Attribute Class
Predefined periodic attribute classes are released by TEMENOS to define
Actions and Attributes for certain Property Classes
Clients are also allowed to create periodic attribute class from R13.
A Periodic Attribute can act on the Attributes of a specified Property Class. Periodic
Attributes can be defined by Clients by combining a time element with a Periodic
Attribute Class.
User can attach the Periodic Attributes to a Product Condition. While attaching a
Periodic Attribute to a Product Condition, User has to specify a comparison value for
evaluation and can optionally specify a Break Result and Break Charges.
Whenever the Attributes of the Property Class are updated in an Arrangement, the
Periodic Attributes will be evaluated. The Break Result is used to tell the system how it
should behave when the Periodic Attribute fails and how much has to be charged for
such failure.
E.g. A periodic rule is attached to the interest condition based on rate increase tolerance
over a period.
• Periodic Attribute
Named type / instance of a Periodic Attribute Class
Helps in controlling Attribute values of an Arrangement over a period of time
A Periodic Attribute is defined by Client from an existing Temenos or User defined
Periodic Attribute Class

T3AAC - R15 100
T3AAC - R15 101
We can see the Periodic Attribute Class defined for every Property Class
For each Periodic Attribute Class we have some predefined Periodic Attribute.

T3AAC - R15 102
Let us use the Term amount product condition created in the earlier workshop.
We have to update the Periodic attribute AMOUNT.INCREASE.1Y indicating
amount increasing every year should not exceed the value of 10000.
If this condition is broken, override should be generated

T3AAC - R15 103
Let us use the Term amount product condition created in the earlier workshop.
We have to update the Periodic attribute AMOUNT.INCREASE.1Y indicating
amount increasing every year should not exceed the value of 10000.
If this condition is broken, override should be generated
Charge levied on breaking the rule is optional.

T3AAC - R15 104
T3AAC - R15 105
Classes are released by Temenos and you can only amend their Description.
The screen here shows the Product Hierarchy in AA and what they are about at
each level.

T3AAC - R15 106
Classes and Product Lines are released by Temenos and you can only amend
their Description.

T3AAC - R15 107
The Product Line provides a high level definition of the business components
(Property Classes) that may be required to construct a product belonging to that
line. For example the LENDING Product Line will enable users to design and
service term loan products such as Loans (personal, small business, etc.)
Mortgages Lines of Credit
The Product Lines are defined by Temenos and cannot be created by the User. A
Product Line is described by the Property Classes which constitute it. The
financial institution may then use these “building blocks” of functionality to
construct the individual products which are available for sale to its customers.
LINE.ATTRIBUTE: This optional field is used to specify whether the product
line deals with amounts/currencies and whether it supports reverse replay
mechanism. Possible values are CCY, REPLAY,NULL
For example LENDING product lines deals with amounts/currencies where as
product line like INTERNET.SERVICES do not involve amounts/currencies. If
this field contains a value CCY, it means that the products of this line deal with
amounts.
If any back dated activity is triggered, all the activities performed from the
given back date till today are reversed, the current activity is applied and
all the reversed activities are replayed taking into effect the conditions
altered by the backdated activity. This is called reverse replay. Product line

T3AAC - R15 108
with LINE.ATTRIBUTE as REPLAY, supports reverse and replay mechanism.

T3AAC - R15 108
Single:
Remember in order to give a preferential treatment for each of the Relationship
Pricing Plans a customer can have only one arrangement (Among Gold, Silver
and Bronze, based on the eligibility condition, relationship pricing arrangement
can be formed for only one either Gold or Silver or Bronze).
The line attribute single indicates that there can be only one unique arrangement
for each customer for products belonging to this line. A customer may take as
many LENDING products that he may require – but there can be only one
RELATIONSHIP.PRICING arrangement for a customer.
Validations are added whilst taking NEW arrangement to throw error when
multiple arrangements are taken under a single product.
Property Classes that constitute the line are to be marked as Mandatory or not
For a mandatory Property Class, there should be at least one Property present in
its Product Groups and Products
If any Property is to be included at a Product level, its Property class should
have been defined at Product line level – either as Mandatory or Optional

T3AAC - R15 109
View the record existing under LENDING, ACCOUNT and DEPOSITS
Product line.
View details in Tab sections - Product lines and Property Classes.

T3AAC - R15 110
Under Product Lines tab, all three Product Lines, namely Lending, Accounts and
Deposits contain description plus CCY and REPLAY under the Line attribute.

T3AAC - R15 111
Under the Property Classes tab of Lending Product Line, these are the valid
Property classes.
Please note that whether the Property class is mandatory or not is also indicated
here.

T3AAC - R15 112
Under the Property Classes tab of Accounts Product Line, these are the valid
Property classes.
Please note that whether the Property class is mandatory or not is also indicated
here.

T3AAC - R15 113
We will look into how you can design an AA Product beginning with Product
Group. Please recollect that the Product Group is in the second level of Product
organisation. Clients can create their own Product Group under existing Product
Lines. Each Product Group has a number of Properties associated with it and
specified as Mandatory or not. Each Product Group must have one
Mandatory Property for each of the mandatory Property Classes of its
Product Line. All Products belong to a Product Group.
GROUP.TYPE Field : Valid options are INTERNAL and EXTERNAL
INTERNAL – means the group being defined is own Bank's product. Only
products specified as INTERNAL are available for sale to customers.
EXTERNAL - There may be a necessity for Banks to do comparison between its
own product(INTERNAL) and one by its competitor. Those groups may be
defined as EXTERNAL. These products may then be used for comparative
analysis to show the superiority of Bank's product. Products of this type are not
available for sale to own customers.
REBUILD.ACTIVITIES field is used to rebuild AA.ACTIVITY records from
AA.ACTIVITY.CLASS. AA.ACTIVITY is an instance of
AA.ACTIVITY.CLASS, records would be created on AA.ACTIVITY for all
instances(properties)of class(property class) at authorisation stage. This can be
used to rebuild activities when a new property is introduced into a group.

T3AAC - R15 114
We will discuss about AA Activities later in the course.

T3AAC - R15 114
Create a new Product Group with the Property classes
and properties as given above.
Hint: Do not leave any line without a property. Go
sequentially down and remove(with ‘-’ ) any
unwanted classes for this group

T3AAC - R15 115
A new Product Group is created under Lending Product Line with appropriate
inputs in Property class, Property and Mandatory fields as given in the
workshop.

T3AAC - R15 116
Id: Id can be input with a name and an effective date separated by a hyphen. If
no date is input, T24 will automatically default the system date. If a record with
a future effective date is created for an existing Product, T24 will automatically
default all field values from the existing record. Effective dating a Product is
useful to offer a Product initially for some time with certain Properties and
then modify its structure from a future date.
DESCRIPTION and FULL.DESCRIPTION: Description about the Product.
PRODUCT.GROUP: The group to which the Product belongs to.
PARENT.PRODUCT: (Optional Field) Product to which current Product is a
Child Product. If it is set,, then Product need not be complete with all Mandatory
Properties. It will inherit Properties not defined at its level, from Parent Product.
INHERITANCE.ONLY: Value YES signifies that this Product cannot be
offered directly for an Arrangement with a Customer. Its purpose is that other
Products can inherit from this Product by linking this Product as their Parent.
Inheritance Only products do not undergo full proofing validations nor are they
available for sale on their own. They are only abstract definition of a product
which should be derived down the hierarchy to define the product in its entirety.

T3AAC - R15 117
T24 product builder follows a structured way of defining products. Each product
should have all the mandatory properties and any of the optional properties of its
product group defined along with a product condition for each of the property.
You can define more than one product condition for a property. In such cases,
you should specify when the subsequent condition would be effective from
arrangement date and the same can be specified in EFFECTIVE Field.

T3AAC - R15 118
You can define the subsequent links between a product and its arrangements.
ARR.LINK.TYPE Field is used to determine whether subsequent changes of
conditions in product should have its effect on the existing arrangements. The
three options are TRACKING, NON-TRACKING and TRACKING.ONLY

T3AAC - R15 119
NON.TRACKING
Arrangement attributes are unaffected by product-level changes. At the
Arrangement level, Attributes can be negotiated, subject to Negotiation Rules in
corresponding Product Condition.
TRACKING
When TRACKING is set in the ARR.LINK for a Product Condition, then
changes to the Attribute values at the Product Condition level will be reflected
in an Arrangement throughout its life.
In this case, the Product Condition must have default values for all its
mandatory Attributes and user can not input value for any Attribute. Any
negotiation rules set in the Product Condition will be just ignored. To set this
functionality, in the PROPERTY.CLASS, the TYPE field should have
TRACKING as a value.
CUSTOM.TRACKING
This is similar to Tracking with some differences. If negotiation rules are set for
some Attributes at the Product Condition level, User can input their values at
Arrangement level. When an attribute is negotiated at the arrangement level
or if it is set to Fix-Value in Product Condition, it will not track changes to
Product Condition. All other Attributes will track changes to Product
Conditions.

T3AAC - R15 120
There is a relation between the TYPE field of a Property Class and how the
ARR.LINK Field can be set for its Product Condition in a Product:
If TYPE is set to TRACKING
ARR.LINK can be set to TRACKING or CUSTOM.TRACKING or

NON.TRACKING. It indicates that the given property can be set to tracking.
If TYPE is set to NON.TRACKING
ARR.LINK can only be set to NON.TRACKING
If TYPE is set to TRACKING.ONLY
ARR.LINK can be set only to TRACKING

T3AAC - R15 121
You can define the subsequent links between a product and its arrangements.
ARR.LINK.TYPE Field is used to determine whether subsequent changes of
conditions in product should have its effect on the existing arrangements. The
three options are TRACKING, NON-TRACKING and TRACKING.ONLY

T3AAC - R15 122
AA allows the flexibility to attach multiple conditions for the same property. The
subsequent conditions are effective after a time period, which is also defined at the
product level.
Effective : In addition to dated changes of Property, the Product designer also allows a
Product to be defined with “timed” changes of its conditions. These timed changes may
be defined as “condition changes” (i.e. a standard product property is linked to one
defined product condition and after a period of time switches to a different defined
product condition. It can be a valid period indicator with W- Week, M-Month, Y- Year
and D-Days
Effective. Base : Defines the effective period of next(new) condition in field
EFFECTIVE. The options are Start, Arrangement and Anniversary . The anniversary
option is introduced from R15.
START: In case disbursement has happens at a different date than new arrangement
creation date then all existing START type conditions will be deleted and new
conditions created based on disbursement date of the arrangement.
ANNIVERSARY : Bank define interest rate change conditions (Forward conditions)
based on ANNIVERSARY date which can be changed at any time during the life of the
contract. When an Anniversary date is changed, the existing anniversary conditions are
deleted and the new anniversary conditions are created based on the base date as new
anniversary date.
ANNIVERSARY option is applicable for interest and payment schedule properties
ARRANGEMENT : If user doesn’t select any one of above options then system will
treat those are ARRANGEMENT type conditions. Forward condition effective date is
calculated by considering START.DATE of the arrangement. It will not be changed any
of the time.
Note: Forward dated product conditions for forward dated properties are still
applicable.

T3AAC - R15 123
When creating the new arrangement user can define the future dated rate change for an interest
property from the arrangement Level. It will be done by using + button. When user press the
+ button system will open one relative calendar. It has the relative option START,
ANNIVERSARY and ARRANGEMENT.
Base date changes for ANNIVERSARY condition

1. New arrangement: - During creation of new arrangement if the user has created any
anniversary condition then the new arrangement effective date is considered as the base date.
2. Disbursement & Auto Disbursement: - In account property, BASE.DATE.TYPE field is set as
START option and then if the disbursement is executed on a different date other than new
arrangement creation date, then the ANNIVERSARY date is changed to disbursement date. In
this case if user creates any forward dated ANNIVERSARY conditions they are deleted and the
new conditions are created by considering base date as the disbursement date.
A new activity LENDING-CHANGE.CONDITION-ARRANGEMENT introduced.
3. Update Account: - Anniversary date can be changed by triggering update account activity. In
this case, existing anniversary conditions are deleted and the new conditions are created by
taking base date as the new anniversary date
4. Change Product: - Whenever the change product activity is triggered either by user or a
scheduled activity, the Anniversary date is changed to effective date of change product
activity date. In this case, existing anniversary conditions are deleted and the new conditions
created by taking base date as new anniversary date.
5. Rollover arrangement: - Anniversary date is changed to the effective date of roll over activity.
In this case, existing anniversary conditions are deleted and the new conditions created by taking
base date as new anniversary date.
6. Reset arrangement: - Anniversary date is changed to effective date of reset arrangement
activity. In this case, existing anniversary conditions are deleted and the new conditions create
by taking base date as new anniversary date.

T3AAC - R15 124
T3AAC - R15 125
CURRENCY field indicates the currency(ies) that are possible within this
product. The input must be a valid record from the CURRENCY table.
This is a multi value field.
CALC.PROPERTY: [in Product Design] Some properties require calculations

for them. For example, a Current Interest property may have to accrue
interest at a specific rate on a specified amount. The base amount on which
such calculations should happen is stated here. The field is associated with
SOURCE.TYPE, SOURCE.BALANCE and SOURCE.PROPERTY fields.
Validation rules:
The property stated here would be validated in the proofing stage to verify if
they actually belong to this product.

T3AAC - R15 126
For a product that should have variations, we must specify which variations are
required and whether there is a default if a customer does not qualify for any
variation.
In the PROPERTY.VARIATION field of the product designer, the user could

select which variation it should support. Also, if a customer is eligible for more
than one variation, then the variation to be used would be determined based on
the priority defined in the variation tab.
If a product is defined with 2 variations - Gold and Silver then (eligibility

conditions given for both GOLD and SILVER), if a customer is eligible for
more than one variation, priority defined will determine which variation will be
used.
Please note that , eligibility conditions can also be configured for a “default”
product if required.

T3AAC - R15 127
Property Variation
Definition is allowed only for the Properties of a Property Class for which variations are
defined. If the product supports multiple variations, then product conditions needs to be
created for each variation. In the PROPERTY.VARIATION field of the product
designer, the user could select which variation it should support. Additionally, if a
customer is eligible for more than one variation, then the variation to be used would be
determined based on the priority defined in the variation tab.
When variation is attached to a property at product designer but variation type is
not defined at property, a error message is displayed “Property not allowed for
variation”.
Variations and Priority

If a product has more than one variation, the user can specify the variations and their
priority order to be taken through this field. The available values are from the virtual
table AA.PRODUCT.VARIATION as previously defined. The order in which the user
specifies the variations is from top to bottom. In other words, when determining the
variation to use, the system would start from the first multi-value field and stop when
the customer is eligible.
Default Available
If the customer is not eligible for a variation, then this field would determine if there is a
“non-variation” (Default) product. If this is “checked” then the default configuration
could not have ELIGIBILITY, as all the customers would be eligible.

T3AAC - R15 128
1. c
2. c
3. b

T3AAC - R15 129
Create a Product under the Product Group created in the earlier workshop. At
least one product condition is to be attached to each property. Set the calculation
source tab as indicated.

T3AAC - R15 130
The product is created under the product Group defined earlier.
The properties opted for in the product group are defaulted while creating the
product. Suitable product conditions are filled in, arrangement link is set for
tracking / non-tracking. Under calculation source tab, CURACCOUNT is set as
the balance property for calculating Principal Interest on daily debits. Please
note that under the availability tab, currency is defaulted as USD.

T3AAC - R15 131
The product conditions are assigned for each property.
The calculation source is indicated for the interest property.

T3AAC - R15 132
Create another Product under the Product Group created in the earlier workshop.
This product is to be defined as a Parent product by marking
INHERITANCE.ONLY. At least one product condition is to be attached to each
property. Set the calculation source tab as indicated. (HINT: rest of properties
will be inherited from Product Group)

T3AAC - R15 133
We are creating a parent product. The properties opted for in the product group
are defaulted while creating the product. Out of 9 properties, only 6 are chosen
for the parent product, rest will be defined in the child product. Suitable product
conditions are filled in, arrangement link is set for tracking / non-tracking.

T3AAC - R15 134
Create a Product under the Product Group created in the earlier workshop. This
is a child product of the parent created in the earlier workshop. At least one
product condition is to be attached to each property. Set the calculation source
tab as indicated.

T3AAC - R15 135
We are creating a Child product. This product is the child of parent product
created earlier and is under the same product group. The properties opted for in
the product group are defaulted while creating the product. Out of 9 properties,
only 4 are chosen for the child product, rest were earlier chosen in the parent
product. Suitable product conditions are filled in, arrangement link is set for
tracking / non-tracking. Under calculation source tab, CURACCOUNT is set as
the balance property for calculating Principal Interest on daily debits.

T3AAC - R15 136
A Product in AA goes through three processes – Product designing, proofing and
publishing.
Designing is the Process of creating Products and attaching Product Conditions

to their Properties. It is done using the T24 Product Browser.
When a Product is designed, it has to undergo Proofing process. Proofing

validates that the Product has been configured correctly without errors, and is
ready for release. Proofing is the process that checks whether the Product is
in sync with its hierarchy such as Parent and or the associated Product
Group.
Once a Product is proofed, it has to be published. Publishing is the process by

which a Product is put into Product Catalog. Once a Product is published into
Product Catalog, it is available for sale. When a parent Product is proofed and
published, these functions are performed down the line to all the child
Products under it. In this case it is not necessary to individually proof and
publish the child Products.

T3AAC - R15 137
New Arrangements can be created only for a Product published into Product Catalog.

T3AAC - R15 137
We have seen how Product Designer allows you to create Products with their
Properties and Conditions. The next stage is Proofing. At the proofing stage,
we need to set the available date of the product. Proofing validates that the
Product has been configured correctly. Proofing includes checking whether all
mandatory Properties have been given conditions, that there are no conflicts
between those conditions, and any other errors that would prevent the Product
from being published. Any errors generated have to be fixed and the product
has to be proofed again. Then the Product is published, and it enters the Product
Catalog. Now the product is available for sale and can be used to create
Arrangements.
The proofing and publishing process can be done either “Online” or by running
a “Service” in the AA.PRODUCT.MANAGER application. If ONLINE is
chosen, system would proof the product immediately. If SERVICE is chosen, the
main product (from which the publishing is triggered) is written on to a LIST
file AA.PUBLISH.SERVICE.LIST for indicating whether it is a
PROOF/PUBLISH initiation. A Service would be introduced –
AA.PUBLISH.SERVICE (from TSA.SERVICE, ) – which would process this
list file. The service would publish products hierarchy-wise. This ensures that a
child would not accidentally get published before the parent has been
processed.

T3AAC - R15 138
T3AAC - R15 138
When you publish a Product, you have to define 2 dates related to it. One is the
Available Date, which is the date from which the Product is available for sale.
Only from this date, Arrangements for the product can be created.
Another one is the Expiry Date, from which the Product will cease to exist and
no Arrangements can be input for the Product. However, existing Arrangements
for the Product will continue.
PRODUCT.ERROR Field displays the errors caused when Proofing fails.
SUGGESTION Field displays suggestions for rectifications of errors.

T3AAC - R15 139
Proof the Parent Product used in the previous workshop with available date as
today, then publish the same.
HINT: Access the Product and use ‘Manage’ button

T3AAC - R15 140
The parent product is proofed with available date as today’s date and Online
opted. On proofing being successful, status monitor shows the status as
completed successfully. Then publishing is done, again, on publishing being
successful, status monitor shows the status as completed successfully

T3AAC - R15 141
Answer:
1. c
2. b
3. b

T3AAC - R15 142
T3AAC - R15 143
Before we move further into Activities, we will recollect that an Arrangement is
an agreement between the bank and the customer whereby the bank agrees to
provide services associated with a Product.
If it is a Financial Arrangement, it also has a currency and account for
lending/deposit/account products.
All arrangements have an agreement date. Arrangements can be created after
product available date.
Finally, arrangements has Arrangement Conditions. This is the set of Properties
defined for the Product with their conditions.
Creating an Arrangement involves “negotiating” changes to the standard product
specification. All the attributes that were specified as negotiable can be
amended.
Technically an arrangement is created with a copy of the product conditions,
which then hold the values for the specific arrangement. So the arrangement is
not simply held in a single record, it is spread across multiple records. This is
why it is easier to use the enquiries and composite screens provided rather than
try and look at files directly.

T3AAC - R15 144
Create an arrangement for Mortgage product and set the following:
Create an Arrangement for Mortgage Product
Indicate a commitment amount of 100,000
Input a settlement account under Pay In and pay out settlement tab and
ensure Active is set to YES
Ensure that payment schedule has disbursement property % as 100%

Against DISBURSEMENT type bill
Commit the Arrangement, accept overrides and get it authorised

T3AAC - R15 145
The arrangement is created using New arrangement Activity. The commitment
amount is input as required. The schedule is verified for full disbursement.
Commitment amount is input along with Term. Settlement conditions are set as
Active Yes and indicating settlement account

T3AAC - R15 146
T3AAC - R15 147
From R14, T24 Document Management can capture and upload (store) the
documents and images at arrangement level for loans, deposits and accounts
products in the Arrangement overview
Enquiry – AA.TXN.DOC is used for Viewing, Reversing, Editing and
uploading the Transaction documents. Also possible to upload/ reverse uploaded
documents/ images as and when required using the Correspondence Tab
For instance the loan agreement obtained by the bank is available at
arrangement level, in the arrangement overview screen via Correspondence tab
(earlier named as “Messages”).
DM.APPLICATION.INFO and DOC.GEN.CONDITION holds a record AAA.
For the DM.APPLICATION.INFO with record ID ‘AAA’
DOC.GEN.CONDITION specifies the activities for which document
management has to be set up.

T3AAC - R15 148
Create an Arrangement for your Customer for the above Product
You can find your customer defaulted as the primary customer. Add
another to the same arrangement
Set the term as 1Y, the amount as 75,000
Settlement account to be given suitably in Pay In and Pay Out
Settlement Tab
Commit the Arrangement and get it authorised
Now search for your deposit arrangement using the secondary customer you
have added in the arrangement

T3AAC - R15 149
An arrangement is created under Long Term Deposit product, picked from the
catalog.
Another owner is added to the primary customer.
Term is input as 1Y
Commitment amount is input as 75,000.
Settlement account under settlement tab is input.
Arrangement is committed.
Then, the arrangement is authorised.

T3AAC - R15 150
Now search for your deposit arrangement using the secondary customer
you have added in the arrangement.
You can find the deposit that we just created where this customer is a
secondary customer.

T3AAC - R15 151
From R14,
Customer Relationship can define the percentage split of income/tax amongst
the primary and joint customer. Tax splits are calculated between the various
joint holders based on the tax types linked to them. Tax Type to have Apply Split
as yes and Tax parameter to be available.
AA enables the tax calculation based on the customer relation for a customer
having a portfolio reference. T24 splits the tax calculated on an income for a
primary customer amongst the primary and joint customers in a pre-defined
percentage as indicated in the Customer Relationship.
ST.CUST.RELATIONSHIP.DATES - list of dates for a customer
relationship record. ID being customer relationship ID without the date
ST.TAX.REPORT.DETAILS - Tax report file to store customer-wise tax

details against a single transaction
From R16,
AA.CUSTOMER.ROLE is released where tax splits are possible between

customers.

T3AAC - R16 152
It can be enabled at New arrangement activity and also using AA.CUSTOMER.ROLE.
More information is covered in Advanced courses.

T3AAC - R15 152
AA.ARRANGEMENT.ACTIVITY Application is used to trigger activities for
arrangement.
Where does the arrangement actually gets stored?

We know that the Product Conditions are based on Property Classes. Product
Conditions belonging to a particular Property Class are stored in a separate
application that corresponds to the respective Property Class.
Are the Arrangement conditions/values also grouped based on Property class?

Yes!
An arrangement gets stored in AA.ARRANGEMENT, whereas the arrangement

conditions relating to the various Property Classes are stored in applications that
begin with AA.ARR.<Property Class Name>.

T3AAC - R15 153
In this screen, you can see where the Product Conditions and the corresponding
Arrangement Conditions (values at Arrangement level) are stored.
The basic elements like Customer, Product, etc. are stored in
AA.ARRANGEMENT.
On publishing a product, the respective product condition for each property is
stored in AA.PRD.CAT.<PROPERTY.CLASS>
The Arrangement values for the Property related to Customer Property
Class are stored in AA.ARR.CUSTOMER.
The ID of a record in AA.ARR.<PROPERTY.CLASS> is Arrangement Id-

Property-Date . serial number
On the same day if we have multiple changes in the same record, they are stored
as serial numbers of the same record (changes using Activities which will be
discussed later).
Though the Application storing Arrangement values is based on Property

Class, the records are maintained by Property ID. This is because at an
Arrangement level there could be multiple Properties for a Property Class. For
example, PRINCIPALINT and PENALTYINT Properties for the INTEREST

T3AAC - R15 154
Property Class.

T3AAC - R15 154
Adding a local reference to a property means it has to be replicated across all of
these files. To avoid duplicating the same set of fields across 4 files and also to
maintain data integrity, AA allows definition of Local reference fields to just
one file (the PRD.DES file) and replicates the same across other levels
automatically.
Designer (Example : AA.PRD.DES.CUSTOMER)
Proofing(Example: AA.PRD.PRF.CUSTOMER).
Catalog (Example: AA.PRD.CAT.CUSTOMER)
Arrangement (Example: AA.ARR.CUSTOMER)
The local reference field is defined in the application LOCAL.TABLE, then
added to the local ref table of the desired property class’s designer table. When
the local ref table is authorised for the designer, standard selection records of the
property’s proof, catalog and arrangement files are rebuilt along with the
designer record

T3AAC - R15 155
Under Property Classes, we had earlier learnt that the Balance prefix is
hardcoded for each property class. These balance prefix-es denotes the life cycle
of an Arrangement by which financial balance would move from one stage to
the other. For instance CUR+BALANCE, ACC+PRINICIPALINT
When the property is suspended the accruals are posted to the balance types
suffixed with a “SP” instead of PL.
T24 has no validations on AC.BALANCE.TYPE record id. Do you know why?

T3AAC - R16 156
AC.BALANCE.TYPE records are either contingent, non-contingent. Balance
types can also be classified as internal reporting type.
Apart from this we have the virtual balances which are sum of
AC.BALANCE.TYPES. These are used for calculation of penalty interest and
not reported.
There are charge off related AC.BALANCE.TYPE generated automatically by

T24 AA framework, if charge off component is configured in the lending
product.
The AC.BALANCE.TYPES would look like CURBALANCECO,
CURBALANCECUST.
This is an advanced concept and will be dealt in deal during AA Lending
courseware.
Note: The type of accounting entry (Spec or Stmt entry) is also mentioned in
AC.BALANCE.TYPE record.

T3AAC - R16 157
Virtual balances allow banks to define calculated balances (e.g. sum of three
actual balances) for simpler use in product definitions and enquiries.
Now we know why there are no validations in AC.BALANCE.TYPE record ID.

T3AAC - R16 158
CALC.PROPERTY Field is used to specify properties require calculations. (e.g.
PRINCIPALINT and PENALTYINT are properties require calculation of
interest).
Calculation is based on a BALANCE indicated in SOURCE.BALANCE Field.
This should be a valid AC.BALANCE.TYPE Id.
SOURCE.TYPE Field indicates whether calculation is based on Maximum,
Average or Daily balance. The data for this field should be a valid record in
AA.SOURCE.CALC.TYPE.
For example, a Current Interest property may have to accrue interest at a
specific rate on a specified amount. The base amount on which such calculations
should happen is stated here.
In this example PRINCIPALINT will use CURACCOUNT Balance type for
calculation, while PENALTYINT will use TOTALPENALTY Balance type.
Here the TOTALPENALTY type balance is a virtual balance and may include,
due principal, overdue principal, overdue charges, etc.

T3AAC - R16 159
T3AAC - R15 160
T3AAC - R15 161
Activities are operations that can be applied to Arrangements
Example : Disburse, Apply Payment, Accrue Interest
Arrangements can only be updated via Activity (both online and COB)
In fact, creating a new Arrangement is also an activity
Activities are grouped into Activity Classes
Defined by Temenos
Activity Class defines behaviour

T3AAC - R15 162
Anything you do that affects an Arrangement is done using an Activity.
Activities are business functions which can be invoked directly by a user or
through close of business processing or via another application like Funds
Transfer or Teller.
Activities include creating an Arrangement as we have seen, disburse loan,

accrue interest, make a repayment, etc. The only things that are not Activities
are enquiries of one kind or another, where you are just looking at details and
not changing anything to do with an Arrangement.

T3AAC - R15 163
Now we have an idea of what Activities are, let us see how they work in AA.
In AA, Activities are associated with Properties. A crucial point to note is that,
few activities like ‘Create New’ , ‘View arrangement’, ‘Takeover activity’ acts
on the arrangement (not the property). This is the only exception to the rule.
In this Arrangement, we have the Property COMMITMENT of the

TERM.AMOUNT Property Class which define the Term and Amount. Similarly
REPAYMENT Property is associated with the PAYMENT.RULES Property
Class, which defines how a payment of a Loan is to be applied to various dues.
Finally PRININT property is associated with INTEREST Property Class which
defines the rate, margin, etc. for Interest.
Here, disbursing a loan is naturally associated with the Commitment Property

which will affect the Amount of the loan; an accrual is naturally associated with
the Principal Interest Property, and apply payment is related to Repayment
Property and so on.

T3AAC - R15 164
Activities are defined within a Product Line. Although Properties can be
shared between Product Lines, Activities are not. Activities represent real
behaviour of the system, and this may be intentionally different across Product
Lines.
Properties can have multiple activities associated with them. The Activities
associated with the Commitment Property (of TERM.AMOUNT Class) include
disburse funds, increase committed amount, change term, etc.
We define another term, the “Process”, which represents what is actually being
done by the activity.

T3AAC - R15 165
This example explains how activity is associated to a Product Line, a Process
and a Property
Here the process DISBURSE related to LENDING Product Line acts on the
Property: COMMITMENT and the Activity is LENDING-DISBURSE-
COMMITMENT i.e. The amount of the loan is disbursed.

T3AAC - R15 166
Similar to the Properties are named types of Property Classes, we have
Activities belong to Activity Classes.
While Activity Class is related to a Property Class, an Activity is related to a
Property.
For example, take Activity Class LENDING-DISBURSE-TERM.AMOUNT.
The ID is a combination of Product Line–Process-Property Class.
The related Activity will have an ID with a combination of Product Line-
Process-Property, where the Property is linked to the Property Class. In this
case, where COMMITMENT is a Property linked to the Property Class:
TERM.AMOUNT, the corresponding Activity ID will be LENDING-
DISBURSE-COMMITMENT.
Normally Activities are generated automatically when you modify a Product
Group and request the Activities to be rebuilt. Here you can see the Activity
LENDING-DISBURSE-COMMITMENT under the Activity Class LENDING-
DISBURSE-TERM.AMOUNT. Here COMMITMENT is a Property belonging
to the Property Class: TERM.AMOUNT and attached to a Product Group under
the LENDING Product Line.
System generates AA. ACTIVITY records for each of the property when
used for the first time in a Product Group when the product group is set
with REBUILD.ACTIVITIES Field to YES.

T3AAC - R15 167
Normally Activities are generated automatically when you create or modify a
Product Group and request the Activities to be rebuilt. This does not create user-
friendly descriptions for the activities. It is recommended to modify the
activity descriptions once all the Properties have been generated.
For each ACTIVITY.CLASS of TERM.AMOUNT Property Class, a
corresponding ACTIVITY record for its property, say COMMITMENT can be
created.
An Activity is automatically created when a Property is added to a Product
Group with Rebuild Activity set to yes.This process creates all the standard
Activities for each Property. Meaning,
1. Picks up all the Properties for the Product Group
2. For each of the Properties, gets the appropriate Property Class name
3. For each of the Property Classes, gets the appropriate Activity Class name
4. Based on the Activity class, builds the Activities.

T3AAC - R15 168
Now, take a look at the Activity Class LENDING-ACCRUE-INTEREST. This
is where all the logic is built. Look at the Action tab. When this Activity is
performed, this Action tab tells us what are the various actions that will happen
in the background. Normally, in the traditional approach, when you wish to
accrue interest, you would have written code for - a. Actually accruing the
interest; b. Checking to see if any restrictions to interest has been made in any of
the parameter tables; c. Calculate charges if any and d. Send delivery message if
required. The most crucial thing to remember is, you would have done this for
all applications that need to calculate interest.
In AA, when LENDING-ACCRUE-INTEREST activity is performed, the
following will happen – a. An action ACCRUE will be performed on the
INTEREST property class; b. An action EVALUATE will be performed on the
ACTIVITY.RESTRICTION Property Class; c. An action CALCULATE will be
performed on the ACTIVITY.CHARGES Property Class and d. An action
SEND.MESSAGE will be performed on the ACTIVITY.MESSAGING Property
Class. Now, what do these actions mean. These actions denote that, internally,
T24 will invoke ‘action routines’ to actually perform the job. For instance for
action ACCRUE on the INTEREST Property Class, a routine named
‘AA.INTEREST.ACCRUE’. The naming convention is AA.<Property class
name>.<Action>. These action routines are available and can be reused.

T3AAC - R15 169
To understand usage of activity type concept better, let us look at Activity Class
definition LENDING-DECREASE-TERM.AMOUNT.
When you view the list of Activities that you can perform on an Arrangement,
all Activities belonging to a particular Property Class (TERM.AMOUNT in
this case) will be displayed provided, ‘User’ is set in TYPE Field in Activity
Class. In this case, please note that “Decrease Activity for Commitment” is
displayed against Term Amount in the Arrangement. This is the Description of
the Activity: LENDING-DECREASE-COMMITMENT. Please note that in this
Arrangement, the Property COMMITMENT is linked to the TERM.AMOUNT
Property Class and hence the corresponding Activity is allowed for User
execution.

T3AAC - R15 170
We can see that in LENDING-AGE-OVERDUE activity class we have the
activity types mentioned like if it is scheduled, secondary and sod process.
We have some actions in property class that have user input as NO – This
indicates that these actions in the property class will automatically triggered by
the system and doesn’t need user intervention.
The Can Prop Class, Can Action and Can user input indicates the actions that
would be reversed when the activity is reversed and if user intervention is
required for the same.

T3AAC - R16 171
It is possible to create linked activity to AA.ACTIVITY which will perform
exactly the same activity as the original one.
We would need linked activities when we have to differentiate between the same
activity triggered by various OFS, channels or transaction codes – Eg: Deposit
through branch, Foreign currency deposit through branch etc.

T3AAC - R16 172
Hint : TERM.AMOUNT in filter, with LENDING

T3AAC - R15 173
We can see that on triggering the Activity LENDING-ACCRUE-INTEREST,
system accrue interest and no user intervention is required. There are no other
related activities.
We see that in LENDING-INCREASE-TERM.AMOUNT we have increased the

commitment amount. This is a user input activity.
While we increase the commitment amount we may also update the payment
schedule. This is a secondary activity but will be triggered only on user input
Without any user intervention, system itself will trigger some activity to
evaluate if there any activity restrictions to increase commitment amount,
calculates any activity charges as result of increased commitment amount and
sends messages for increased commitment amount.

T3AAC - R15 174
There are five ways to do an arrangement activity.
They can be run directly from the Arrangement Overview for changing terms
and conditions like the loan term, interest changes, basically changing any of the
product conditions for the loan.
They can be run indirectly via a transaction. These are typically the financial
activities, disbursements, payments, etc which affect balances.
They can be run as part of COB (Close of Business). This includes interest
accruals, bill processing, etc.
They can be run from another system using an OFS message
They can be run as a “secondary activity”, triggered from another activity

T3AAC - R15 175
Activity Log maintains a record of all activities performed in an arrangement.
The record is in a chronological order. User can drill down to view the details
of the activity. Activity log is used as a basic information tool for reversal of
activities.
The Activity Log shows all Activities relating to the Arrangement. The most
recent Activity is shown at the top on the grounds that it is likely to be the most
relevant. In this example we see the New Arrangement, issue bill, made due and
Decrease commitment amount activity.
Activity log hold the status of the Activity whether authorised, unauthorised,
reversed or reversed unauthorised.

T3AAC - R15 176
When you run a transaction against an Arrangement, T24 behaves in a different
way from if you had run the same kind of transaction against an ordinary T24
account. The system automatically invokes the appropriate Activity for that
transaction.
This works through a mapping between the T24 transactions and the AA
Activities. Depending on the transaction code you enter, it will know which AA
activity you intend to run. You will learn how to configure these in the AA
business course.

T3AAC - R15 177
Reversal and replay is enabled for products when LINE.ATTRIBUTE Field in
its AA.PRODUCT.LINE is set to REPLAY.
Financial Position and related calculations are based on value date. Reverses all
related activities from today to back valued date. Current back valued entry is
triggered. Replays activities from back date to today. Accounting entries are
passed for both reversal and replay. Full History of the arrangement
conditions should be available for reversal and replay activities. The correction
processing takes place in real-time and is initiated by the submission of a back-
dated arrangement activity.
Reversal happens unconditionally for all User, Transaction and Scheduled

activities
Replay would perform the User, Transaction activities on the dates on which
they were triggered
Replay of scheduled activities replay is decided at runtime based on the
backdated activity triggered at this instance

T3AAC - R15 178
Reversal and replay is enabled for products when LINE.ATTRIBUTE Field in
its AA.PRODUCT.LINE is set to REPLAY.
Financial Position and related calculations are based on value date. Reverses all
related activities backwards from today to back valued date. Current back
valued entry is triggered. Full History of the arrangement conditions should be
available for reversal and replay activities.
ACTIVITY.TYPE determines how the activity should behave during reverse

and replay.
Reversal of activity not possible when AA.ACTIVITY.CLASS type is

NOREVERSE. Activity cannot be manually reversed by user.
Replay of activity not possible when AA.ACTIVITY.CLASS type is
NOREPLAY. Activity will not be reversed / replayed by any activity. Activity
will not trigger reversal / replay of other activities when AA.ACTIVITY.CLASS
type is NORR.

T3AAC - R15 179
Use AA.ACTIVITY.HISTORY, with filter on arrangement ID, to see history of
activities

T3AAC - R15 180
A Personal loan with biweekly payments is chosen. We can see that there are
few bills outstanding as per the schedules.

T3AAC - R15 181
We see the some User initiated activity and system triggered secondary activity
in the AA.ACTIVITY.HISTORY
These activities are having status as “AUTH”

T3AAC - R15 182
T3AAC - R15 183
On clicking the new activity tab we have list of activity listed,
Here chose to perform an activity, ensure the effective date is start date and
validate the deal.
We can see two tabs appear both Schedule and settlement instruction– Can you
explain why both the tabs are appearing based on what we learnt about activities
already?
Yes Settlement instruction update is a secondary user triggered activities based
on the schedule activity.
Update the schedule tab as required.

Now commit the record.

T3AAC - R15 184
Open the Activity history record and view the reversal status.
Do you know why some activities are reversed and why some are not reversed.

T3AAC - R15 185
Now open the record and authorise the same.

T3AAC - R15 186
View the Activity history record to view the reversal authorised and new activity
come up.

T3AAC - R15 187
T3AAC - R15 188
A personal loan arrangement is chosen with biweekly schedules. There are few
bills outstanding.

T3AAC - R15 189
The activity history is seen here for the arrangement.

T3AAC - R15 190
The schedule is updated effective from the start date of the arrangement and the
activity is committed.

T3AAC - R15 191
We can see that some activities are in reversal states and the in unauth status.
There are certain activities that are unaffected as well.

T3AAC - R15 192
Delete the activity in un-auth status.

T3AAC - R15 193
We can see the result as unauth activity being deleted and the reversal also
deleted.

T3AAC - R15 194
The record/arrangement returns back to original schedule.

T3AAC - R15 195
T3AAC - R15 196
HINT: View Interest accruals: Use AA.INTEREST.ACCRUALS – filter ID
contains <arrangement id>, and PROPERTY.NAME contains PRINCIPALINT

T3AAC - R15 197
We can see the Arrangement has an accrued interest for 6% under Prinicipalint
component
We can see the activity history. Interest accruals for principal interest in
AA.INTEREST.ACCRUALS

T3AAC - R15 198
We see the interest change activity is back dated and interest rate is changed,

T3AAC - R15 199
Now the activity has to be authorised.
We can see the projected accrual change in the financial summary.

T3AAC - R15 200
The accruals are updated in the AA.INTEREST.ACCRUALS.
We can see the activity for change in principalint is authorised and effect is seen
in the AA.INTEREST.ACCRUALS.
Can you recollect and explain why the Accruals are not seen in Activity history
and they are not reversed and replayed.
Also can you see the effective accrual amount is changed in interest is correct
even without reversal and replay.

T3AAC - R15 201
Whenever an Arrangement is created under the Lending, Accounts and Deposits
Product Line, an Account is created for each Arrangement. The Arrangement
thus created, along with its Account and Balances belong to the Company under
which it was created. It is possible for the USER to change the Company to
which the ARRANGEMENT belongs to through the application
EB.COMPANY.CHANGE.
Both these companies should share the same financial files in the database for
the change to happen.The actual process of company change happens during
COB.

T3AAC - R15 202
The User, in order to use the alerts features, has to make the ALERTS
property class part of the PRODUCT.GROUP and add the relevant property
to the PRODUCT.
The product condition created for this property class will contain the event
(Activity) for which the Alert has to be triggered. All other parameters for
triggering the Alert will be set up as part of the Alert processing system.
Once the product condition has been created and added to the product, user has
to trigger the activity for which this alert has been setup (which is
LENDING-DISBURSE-COMMITMENT). The disbursement activity will
in turn trigger the LENDING-SUBSCRIBE-MYALERTS activity which will
create the alerts for the event. Once this activity has been authorised, a
record will be created in AA.ARR.ALERTS application.

T3AAC - R15 203
Activity Presentations class is used for defining various versions to be used for
different Property Classes / Properties / Activities during an arrangement
entry. It helps in displaying various versions / screen while inputting an
arrangement through browser for different Properties of the product.
SUPPRESS.SEE.MODE - If the user wants to view only the property and its
fields relevant to activity being performed and suppress all other
properties that open up in SEE mode (non-editable), user has to set this field
to "YES". Default option for this field is NULL. If the field is set to NULL,
all properties along with field values would be shown during input of an
activity.

T3AAC - R15 204
T3AAC - R15 205
AA provides a Simulation tool which can help in decision making for the
customer.
• Creates simulated loans for prospective and existing customers.
• Performs what-if speculation for new loans.
• Calculates loan duration, when amount and installments are given. Similarly,
amount or installment can be calculated when other two variables are given.
• Simulates multiple disbursements within the loan schedule.
• Possible to convert simulated loan into a live loan.
• Shows the result of a future dated activity on an existing arrangement.
When an activity is simulated, system actually performs all actions but stores
these details in a separate simulated file.
You have learnt earlier that data of an arrangement are stored in respective
Property Class records AA.ARR.<PROPERTY.CLASS>. Similarly data of
simulated arrangements are stored in AA.SIM.<PROPERTY.CLASS>.

T3AAC - R15 206
AA Simulation can be run for future dated activities. We can also simulate a set
of activities for a specific period, where a start date and end date is given.
More than one activity can be simulated simultaneously.
Simulation performs activities without creating or updating live records and
produces output for these activities. This helps customer to take decision to opt
for arrangements. Simulated activities can be retained for user-defined days and
if the customer opts for the same, it can be executed into a live record.
Simulation also performs activities on existing arrangements for situations like
what if, pay off or renewal on a specified date.
In AA Lending, users can compare simulated arrangements or simulated
arrangement activities. Also, the users can print the comparison overview
screen if desired. A minimum of two simulations are required to compare the
values and a maximum of three simulations can be compared. Duplicates are not
allowed.
We will discuss further on this in AA Lending course.

T3AAC - R15 207
Simulation within AA would require sub-systems. They are Simulation data
capture and Simulation Runner.
Simulation data capture captures data for activity being simulated subject to
negotiation condition of the product.
The data captured in simulation capture are stored in
AA.SIM.<PROPERTY.CLASS>.
Simulation runner is used to define the period of simulation and list of activities
to be simulated. This runs the data captured through the Simulation data capture.
Before simulating an activity, Simulation service has to be started.

T3AAC - R15 208
AA.ARRANGEMENT.ACTIVITY application is used to trigger activities for
live arrangement. AA.SIMULATION.CAPTURE application is used to trigger
simulation.
AA.SIMULATION.CAPTURE application has same set of Fields as that of
AA.ARRANGEMENT.ACTIVITY.
All defaulted and negotiated conditions captured through
AA.SIMULATION.CAPTURE application are stored in individual SIM files for
each property like AA.SIM.INTEREST, AA.SIM.CUSTOMER, and
AA.SIM.TERM.AMOUNT etc.
AA.SIMULATION.CAPTURE application can be used to capture, simulate or
directly execute the required activity.
When Field AUTO.RUN is set to EXECUTE, data captured are executed
into live file.

T3AAC - R15 209
AA.SIMULATION.RUNNER is mandatory for simulating the captured
information. When the AUTO.RUN Field is set to SIMULATE,
AA.SIMULATION.RUNNER record is created automatically during
committing of AA.SIMULATION.CAPTURE. If this field is set to NULL,
AA.SIMULATION.RUNNER will not be created automatically. In this case,
User should create AA.SIMULATION.RUNNER.
SIM.CURRENCY Field is defaulted with Currency of Simulation Arrangement.
SIM.RUN.DATE, SIM.END.DATE Fields are defaulted with system date and
user can change the end date to define a simulation period. If the
SIM.END.DATE Field is left Null, system will run the simulation only for the
run date.

T3AAC - R15 210
The user can opt to have a simulated arrangement converted into a LIVE
arrangement based on the customer’s final decision.
This can be achieved by setting the field EXECUTE.SIMULATION in
AA.SIMULATION.RUNNER to ‘YES’.
User can set to simulate associated or related activity along with a simulated
activity. For example, what-if speculation for creating and disbursing an
arrangement; repayment and make due activities etc.
Associated activity is defined in RELATED.ACTIVITY Field of
AA.ACTIVITY.

T3AAC - R15 211
After the basic information for simulation has been captured, next step is to
actually run the simulation. AA.SIMULATION.RUNNER application is used to
run the simulation from a given start date to end date.
The service AA.SIMULATION.SERVICE simulates the activity given in
AA.SIMULATION.CAPTURE. The service can be set in AUTO mode and the
respective agents started. If the service AA.SIMULATION.SERVICE is in
STOP status, message for simulation will not be picked up. Hence no
simulation will take place.
Simulation monitor refreshes every 10 seconds to check the status.
STATUS Field denotes the status of the simulation runner. It is a non-input
field.
COMPLETED - SUCCESSFULLY -> This denotes that runner has been
completed successfully.
COMPLETED - ERROR -> This denotes that runner is completed but has got
errors while executing.
Processing -> This denotes that runner is getting executed.

T3AAC - R15 212
The pre-requisites for starting a simulation is detailed here.
For R15 TAFJ area from Temenos Shell prompt type
tRun START.TSM –DEBUG
&
tRun tSA **

T3AAC - R15 213
T3AAC - R15 214
Simulate an arrangement for your customer effective today
Commit the record. View your simulated arrangement.

T3AAC - R15 215
T3AAC - R15 217
The simulation runner starts and shows the status monitor. Once the status is
shown as Completed – successfully, the simulated arrangement overview is
accessed and viewed.
Please note that to view the simulated arrangement overview, either menu
navigation as mentioned in workshop contents can be done or the icon next to
Status completed successfully can be clicked.
The simulated Arrangement can be executed and bought to live status using the
execute icon indicated.

T3AAC - R15
Upon drilling down into the view button the simulation runner is seen.
When executed successfully, we can find the record under the live file list.

T3AAC - R15 219
T3AAC - R15 220
In the arrangement overview with the Simulations Tab, we can find the list
of simulations.
Out of these, the desired records are chosen for comparison

T3AAC - R15 221
Here, Simulations for comparison are chosen in AA simulation compare.
On committing the record a pop up enquiry will get displayed with the Drill
down option. The simulation comparison result appears with print option
on the top.

T3AAC - R15 222
1. c
2. b
3. b

T3AAC - R15 223
T3AAC - R16 224
Marketing Catalog is from the sales and marketing sense, something a customer
would browse to look for the product that matches their requirements.
Marketing focused product catalogue that can be exposed to all customer
channels and provide an easy and intuitive mechanism by which bank staff and
customers alike are able to quickly search for and locate the products they
require.
Each Product defined in the Product Catalogue (AA.PRODUCT) will have a
corresponding Marketing Catalogue record which describes the key attributes
and values for that product.
This Marketing Catalogue will give the opportunity to the user/customer to
compare different product based on criteria/fields defined by the Marketing
Administrator of the bank.
A new application AA.MARKETING.CATALOGUE.DESIGNER will be
created to define the searchable parameters for each Product Group.
Each record on this table will represent a Product.Group and the contents of the
record will describe the searchable attributes and how they are to derived
from the existing Product Catalogue data or whether they can be manually
entered.

T3AAC - R16 225
FIELD.NAME
Name of the field ie Max.Loan.Amount or Early.Redemption.Penalty
FIELD.DESCRIPTION
Description of the field that will appear as a column header
SOURCE.TYPE
Used to allow us to add multiple fields automatically in the case of interest and
charge properties – ie rate, desc, etc. (See below fields of new table
AA.STANDARD.FIELD.TYPE)
SOURCE.PROPERTY
Contains the AA property name from which the source data is to be retrieved
SOURCE.FIELD
Field on the defined property from which the data is retrieved
(not allowed for source type interest or charge)
SRC.FLD.RULE.TYPE
Enable the user to decide if he wants to display the field value picked up in
SOURCE.FIELD or if it needs to take it from a linked table (Periodic Rule,
Negotiation Rule or Activity Restriction)
SRC.FLD.RULE (‘Attributes’ column heading in version)

T3AAC - R16 226
Define the rule from the previous RULE.TYPE you want to display (MINPERIOD,
MAXMOUNT, etc…)

T3AAC - R15 226
SOURCE.DATA.TYPE
Indicates the data value type i.e. date, amount, rate etc. Could link to an IN2
routine
SOURCE.VALUE
Enable to display a single value (text or number) that the user want to display
for all products
SOURCE.API
Enable to connect to another system and get data that is not inside T24
SOURCE.NULL.VALUE
Value to be applied if the property specified does not exist for a given product
ACTION
This will allow the user to PUBLISH the marketing catalogue.

T3AAC - R16 227
This Standard Field Type application used to define a standard set of fields to
extract some standard information like interest and charge.
Below standard set of fields would be defined for INTEREST in
AA.STANDARD.FIELD.TYPE which will make-up interest information, like
a. Whether interest rate is defined or not
b. Type of interest, Fixed or Periodic or Floating
c. Resolved interest rate (for key) or fixed interest rate
d. Preferential rate for the customer
e. Reset date for periodic or floating type interest
Similarly below standard set of fields would be defined for CHARGE in
AA.STANDARD.FIELD.TYPE which will make-up the charge information,
like,
a. Whether charge is defined or not
b. Type of charge, Calculated or Fixed
c. Charge rate in case of calculated
d. Charge amount
e. Preferential pricing amount for the customer
These special data is only applicable for INTEREST and CHARGE properties.

T3AAC - R16 228
T3AAC - R15 229
Use Admin menu > Product Builder > Marketing Designer - Under
product line Lending Go to Small Business Loans –
Click on edit icon
After giving a meaningful name and description for the catalog being built, We
define the criteria as minimum and maximum amount from COMMITMENT
property with negotiation attributes as minimum and maximum. Similarly for
the Term with minimum and maximum attribute from same property
Interest is to be pulled out from the AA.STANDARD.FIELD.TYPE by
indicating in SOURCE.TYPE
The Catalog is to be published.

T3AAC - R16 230
The marketing catalog is now commited. We can find the system data type for
field names populated by the system

T3AAC - R16 231
We find the conditions of the catalog built being displayed here.

T3AAC - R16 232
In user menu, Retail operations, the catalogue created now is opened and the
results are displayed.

T3AAC - R16 233
To view the preferential information of Interest, we are using the customer
100100 and we see the preferential rates offered for this customer.

T3AAC - R16 234
T3AAC - R15 235
The AA module provides a flexible framework that allows a number of new T24
modules to be created. The application provides a business component based
architecture for the management of products.
The application provides the ability to allow the user to construct banking
products by combining different business components. PRODUCT.LINES
which provide functionality for different banking areas are licensed by Temenos;
each product line utilises a number of property classes (business components)
that are fully configurable.
Main features of the product builder are:
• Ability to build families of products.
• Ability to inherit properties from the product family structure.
• Ability to determine the properties that a product is comprised of.
• Control of default values to be applied for product arrangements.
• Dated conditions for products.
• Full control of scope of negotiation between product and arrangement
conditions.
• Control of negotiation of attributes over time.
• Design/Proof/Publish lifecycle for product management.

T3AAC - R15 236
T3AAC - R15 237
T24’s core accounting application provides the ability for an Account to hold
and process multiple Balances.
The Balances in AA are user defined subject to some rules, and they represent
the financial components of an Arrangement.
A Balance is specified by associating a Property with a Balance pre-fix. Of
course, the Property should be a financial Property like ACCOUNT, INTEREST,
CHARGE, etc. which allow Balances. You will learn in detail about how to do
this later.
For example, a balance pre-fix of ‘Acc’ (for Accrued) can be associated with an
interest property such as ‘PENALTYINTEREST’which will result in an
‘ACCPENALTYINTEREST’ balance.
Different balances can be created for different Properties such as Committed
Principal, Due Principal, due Penalty Interest, etc.
Different Over Due balances can be created by its age like Overdue 5 days
Principal Interest, Non Accrual Annual Fee, etc.
T24 Arrangement Architecture -Loans -

T3TAAL - R15 238
In this example, AA.INTEREST.ACCRUALS shows the total accrued penalty
interest as USD 86.75. The total penalty accrued amount gets apportioned to
each bill based on ACCRUAL.BY.BILLS in Penalty Interest Property.

T3TAAL - R15 239
In this example, the Property option has been set to only SUSPEND.
You can see that interest accrual before NAB status are booked to P&L
and when it reaches NAB on the 60th day, only future accruals are posted
to SP balance while existing accruals are retained in P&L.

T3TAAL - R15 240
In this example, the Property option has been set to SUSPEND.OVERDUES.
You can see that the interest accrual before NAB status are booked to P&L and
when it reaches NAB on the 60th day, the total accruals are reversed from P&L
and placed to NABLOANINTSP and ACCLOANINTSP respectively and posts
further accruals to Suspended balances.

T3TAAL - R15 241
T3AAC - R15 242
T3AAC - R15 243

T3TAAC Arrangement Architecture Core R15 v3.1

Uploaded by

Document Information

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

T3TAAC Arrangement Architecture Core R15 v3.1

Uploaded by

Copyright:

Available Formats

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

We can see the components of the arrangement in this version.

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

Thus a Component has common Attributes and Actions across different

In AA we refer to these Components which have Attributes and Actions as a

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

A Product Group is a sub-set of the Property Classes of its Product Line. Of

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

Creating an Arrangement involves “negotiating” with the Customer for changes

Technically an Arrangement is created with a copy of the Product Conditions,

You will learn about what is negotiation in the next page.

T24 Arrangement Architecture - Core -

An arrangement is Customer specific offering of a Product. An Arrangement is

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

Agent Commission Property Class links the Rewards arrangement/Agent

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -