AAAdvanced Customisation Part 1

AA Advanced Customisation - Part 1
Temenos University - June 2012 1




Before we proceed and discuss the use of the ACTIVTY.API Property

Class, let’s review briefly a few core concepts that will be used during this
Advanced Customisation course. The key points we have to remember
about before we get started are
Property Classes
Properties
Activity Classes
Activities
Local Reference fields & Customised Screen Layouts
Customisation through ACTIVITY.PRESENTATION Property
Class

• Property Classes are AA reusable components defined by attributes and

actions. A set of Property Classes defines an AA Product Line (i.e. a broad
category of products set up by Temenos)
• Property Classes can have different values, called Properties. Properties are
named instances of Property Classes with all their Attributes and Actions.
While Property Classes are defined by Temenos only, Properties can be
defined by the client. Each Property shares the same Attributes and Actions
of the Property Class with which it is associated (but the VALUES of them
change). Product Groups are defined by Properties
• A Product Condition is a user-defined set of rules set for a Property Class of
a Product Line (defines default values for Attributes), which are attached to
Properties at the corresponding Product level.
• Property Classes can be enriched with locally developed fields

Activities, defined in the application AA.ACTIVITY, describe which action can

be carried out on a specific Property (e.g. LENDING-DISBOURSE-
COMMITMENT define the possibility to DISBOURSE an amount, within the
LENDING product range using the COMMITMENT Property).
Properties have Property Classes, which define the characteristics of the Property.
In a similar way, Activities have Activity Classes, which primarily define the
Actions that form a Process.
Lets take the property class TERM.AMOUNT. The actions which can be
performed on this property class can be found in the actions tab of the property
class record. When the user performs an activity, a set of actions are performed
on a particular property. This information will be stored in the
AA.ACTIVITY.CLASS table. So, for example, when the user perform a
disbursement on an arrangement, the activity class LENDING-DISBURSE-
TERM.AMOUNT will be accessed, through corresponding activity LENDING-
DISBURSE-COMMITMENT (where COMMITMENT is the instance of
TERM.AMOUNT property class used in the product).
All activity classes perform some action on a property class. That is why the ID
of an activity class is Product Line-Action-Property Class name.

The tables used for building the re-usable components & customising AA screens
are:
• AA.PROPERTY.CLASS -> Designed by TEMENOS
• AA.PROPERTY -> Named copy of Property class
• AA.PRD.DES.<PROPERTY.CLASS> -> Used to o design product
conditions by assigning values to attributes of Property class
AA.PROPERTY and AA.PRD.DES.<PROPERTY.CLASS> are set up during

implementation and these components could be used across several Products.
As we have seen in the AA Basic Customisation course,

AA.PRD.DES.<PROPERTY.CLASS> is the application name used as @ID of the
LOCAL.REF.TABLE record which will allow to link local new reference fields
to AA components, instead of a standard T24 application name. What do we
remember about local reference fields?

Local Reference Fields are application fields developed locally in order to

meet the requirements of a specific Temenos’ client
They are created in T24 by setting up a new record in LOCAL.TABLE
In AA, local fields can be attached to an AA Component by setting up a
new record in LOCAL.REF.TABLE with @ID as
AA.PRD.DES.<PROPERTY.CLASS>
Through a mechanism called Automatic Replication, whenever we add a
local field to a AA.PRD.DES.<PROPERTY.CLASS> application, also the
corresponding applications used for Proofing, Publishing,
Creating/Simulating an Arrangement will be updated by the system

Customised Screen Layouts are referred as Versions in T24

These views can be created for any application in T24 and can be
used in association with any function which is compatible with the
application they are based on
Customised Screens are created using the VERSION application
Versions are used to customise the number of authorisers, layout,
field properties and field content of an application screen
Customised screen views for AA arrangements can be created by
setting up new VERSION records for applications of the type:
AA.ARR.<PROPERTY.CLASS> (for real arrangements)
AA.SIM.<PROPERTY.CLASS> (for simulations)
In AA, Versions can be associated to Properties, Property classes or
Activities

As we have seen previously during the AA Basic Customisation course, different

Customised Screen Layous can be triggered based on three different levels:
• Property Class
• Property
• Activity
In this picture, the different levels are from the least specific (Property Class) to
the most specific (Activity). If a conflict arises, the most specific level will take
precedence over the least specific one. This means that when different versions
are associated to two connected levels, the version associated to the most specific
level will take precedence over the other - e.g. if version 1 is associated to the
LENDING-DISBURSE-COMMITMENT Activity and version 2 is associated to
the COMMITMENT Property, when the LENDING-DISBURSE-
COMMITMENT activity takes place, version 1 will be displayed to end-user
instead of version 2.
We will review how to set up this through the ACTIVITY.PRESENTATION

property class.

ACTIVITY.PRESENTATION is a Property Class which allows us to attach

specific versions to another Property Class, a Property or an Activity.
If a conflict between versions arises, the version connected to the
most specific level will take precedence (i.e. versions connected to
Activities take precedence over Property-specific ones and
Property-specific versions take precedence over views associated to
a Property Class)
Steps involved in associating a Version to an AA Screen are:

Create a VERSION record
Define a new Product Condition within the
ACTIVITY.PRESENTATION property class in which you associate
the VERSION to the chosen level
Attach the newly created Product Condition to the appropriate
Product
Proof & Publish

Now that we have reviewed some important concept about Basic Customisation
in AA, we can focus on a new concept: the ACTIVITY.API Property class.
Let’s take as an example a scenario in which a bank asks us to add some extra
validation to our AA Screen. For instance, our client wants us to set up a
POSTING.RESTRICTION local reference field on the COMMITMENT Property
screen of the Personal Loan product when a LENDING-DECREASE-
COMMITMENT Activity is carried out. Than, when a user fill in this field, the
client wants system field POSTING.RESTICTION on the ACCOUNT Property
screen to be automatically updated.
This kind of automatic update would normally require an authorisation routine or

the use of OFS in Globus mode. Nevertheless, it is currently not possible to attach
routines directly to versions of AA.ARR.<PROPERTY.CLASS> applications:
the ACTIVITY.API Property class is used to attach user-defined routines to these
kind of versions, instead.
The steps involved to attach a routine to a version of an

AA.ARR.<PROPERTY.CLASS> application are
Write a routine, compile it and catalog it
Create an entry in EB.API for such routine
Create a new Product Condition for the Property Class
ACTIVITY.API and attach the routine either to an Activity or to an

Activity Class


There are different types of routines which can be associated with AA screen
versions in ACTIVITY.API Property Class, set up through the
AA.PRD.DES.ACTIVITY.API application. These are currently:
- Pre-routines are routines triggered before a certain action, specified in the

PC.ACTION field AA.PRD.DES.ACTIVITY.API. Let’s try to understand what
this means with an example. Let’s say that we want to associate a Pre-routine
with the LENDING-INCREASE-COMMITMENT. The pre-routine will look
after changing the Payoff Condition only if the COMMITMENT (Property) is
subject to the INCREASE action – this means that your routine will actually
automatically generate a new activity of type LENDING-UPDATE-PAYOFF.
Now, if you set up your routine as pre-routine, this will imply that, from a
technical point of view, the Child activity will be performed first (a new record
will created at the database level) and the Parent activity will performed once
the Child is completed. If we want, instead, the Parent activity to be completed
before the Child we need to define our routine as a post-routine.
- Post-routines work in a similar way to pre-routines – However, the routine
attached to this field will get trigger after the action specified in PC.ACTION
executes
- Record routines are subroutines to be executed for a combination of
ACTIVITY.CLASS / ACTIVITY and PROPERTY.CLASS / PROPERTY and
ACTION fields. More than one record routine can be defined for an
ACTIVITY,PROPERTY.CLASS,ACTION field combination. The Record
Routine will be triggered when a given property is read before the action

processing
- Pre-validation routines will get trigger before core level validation. It is used to input or
modify the required fields or else mandatory fields. But “NOINPUT” and “NON-
NEGOTIABLE” fields would not have no effect on this. E.g. If the value for the
mandatory field AMOUNT has to be populated, then the user should use this field. If
the user wish to populate the value for the field and attach it to the field
PRE.VALIDATE.RTN
- Validation routines are attached to the VALIDATE.RTN field and will get trigger after
core level validation. For example, a local reference field can be introduced with some
value assigned to it. If the user wish to include a local reference field, then he can
achieve it through this field.

Here you can see the ACTIVITY.API routines’ flow – as previously explained,
Record routines are invoked as soon as the AA arrangement they operate on is
opened in an ‘input’ mode and before it is Validated/Committed. Pre-validate
routines are a new kind of AA routines introduced from R12; they are invoked
before core validation, while Validate routines are invoked afterwards. Pre-
routines are executed before the action specified in PC.ACTION field is
processed (e.g. INCREASE or DECREASE commitment, CREATE a new
arrangement etc) while, finally, post-routines will be called after the PC.ACTION
has taken place.
Very important technical note – Validate and Pre-validate routines only work in
R12 after the installation of the R12_AA_Framework_5 update. This update
should be installed before you write and test these types of routines.



As you know, we can access the Database Designer Composite Screen by

clicking on Admin Menu>Implementation Utilities>Customization>Database
Designer. We click then on the option “New Field” in order to create a new field

Once the “User Defined Field” Screen has come up, we input the Id of our new
field and we click on the edit button.
1. We assign a description and a short name to the new local reference field
through the GB Description AND GB Field Name fields.
2. Width Max is a mandatory field through which you state the local field’s
maximum length; on the other hand, you can decide whether the
AA.COMMITMENT.MEMO has a minimum length through Width Min –
when Width Min is left empty, like in this example, it means that the new
local reference field is not mandatory
3. In this case, we would like the current field to link to the
POSTING.RESTRICT table, so that it will display a dropdown list pointing
to the records contained in the aforementioned table. By populating
LINKED.TABLE, the field ENRICHMENT also becomes mandatory. As you
remember, ENRICHMENT contains the number of the field in the
POSTING.RESTRICT table whose content will be used as an enrichment for
POST.REST.TA
4. If you link a local field to a T24 existing table, like in this example, there’s no
need to specify a TYPE for the local reference field
Once we are finished, we can validate & commit. After committing, the new local
reference field will be automatically live as we are using a self-authorising

version.

We have now to attach the newly created POST.REST.TA field to the

TERM.AMOUNT property class. In order to do so, we will click on the “Add
Field to a Table” option which will open the customised screen “Linked fields”, a
version of the LOCAL.REF.TABLE.
Now, the standard Id for the LOCAL.REF.TABLE application is a valid

Application name. As we learnt previously, when we want to add a new field to a
property class, we should update the application used to define product conditions
for such property class, i.e. AA.PRD.DES.<PROPERTY.CLASS>. So, in this
case we have to attach the new field to AA.PRD.DES.TERM.AMOUNT.
In order to do so we should:
1. Set AA.PRD.DES.TERM.AMOUNT as a key for our new record

2. Specify the Id of our newly created reference field (i.e. POST.REST.TA) in
Field No
Once we are finished, we can validate & commit the record. Please note that the
record will be immediately set to live status, as we are using a self-authorising
version.

Even if we have created a new local reference field and we have linked it to the
TERM.AMOUNT property class, we are not able to view it within an AA screen
quite yet. The end-result we aim for, is to display such new field within the
‘Commitment’ screen of an PERSONAL.LOAN record whenever we perform a
LENDING-DECREASE-COMMITMENT activity. In other words, we would like
the new field to be presented to end-users only when they are trying to decrease
the amount of a Personal Loan arrangement.
The fastest way to achieve this, is to find out which version of
AA.ARR.TERM.AMOUNT is associated with the LENDING-DECREASE-
COMMITMENT activity for the PERSONAL.LOAN product and include our
new POST.REST.TA local reference field to such version. But how can we do
this?
From the AA Basic Customisation course, you should remember that you can
associate versions with Property Classes, Properties and Activities through the
ACTIVITY.API Property Class. In previous workshops, we had created new
product conditions for ACTIVITY.API and then we had associated these
customised conditions to products, using the PRESENTATION Property.
In this case, however, we would like to modify an existing condition rather than
creating new ones so we should proceed backwards – first we will check which
Conditions are already associated with the PERSONAL.LOAN product and then
we will change them so that the AA.ARR.TERM.AMOUNT version used for
LENDING-DECREASE-COMMITMENT activity also includes our new field.
Let us check the list of Conditions associated with the PERSONAL.LOAN

product. We can get the full list of available products in R12 Model Bank, through Admin
Menu > Product Builder > Products. The PERSONAL.LOAN product belongs to the
LENDING Product Line and to the PERSONAL.LOANS Product Group. By clicking on
the ‘View’ context workflow link, we are able to check the features of the
PERSONAL.LOAN product.

Just by casting a quick look to the PERSONAL.LOAN record, we can view from
the ‘Product Designer’ tab that this product is depending on a Parent Product
called PERSONAL.LOAN.PARENT. What are the implications in terms of
Property Conditions?
As we have learnt during the AA Basic Customisation course, a child product will
inherit the parent product’s conditions. However, if there’s a conflict between the
parent’s Property Conditions and the child’s ones, the most specific conditions
will take precedence over the most generic – in other words, the Property
Conditions set at the child level will always take precedence but if no condition is
set at the child level, the parent conditions will be used.
In our case, we should check if the PERSONAL.LOAN conditions include
description of the version to be used for the ‘Commitment’ screen while
performing a LENDING-DECREASE-COMMITMENT activity. If these
description is missing in the child’s Property Conditions, we should look at the
parent’s Property Conditions.

We can check which Property Conditions are associated to the current Product by
clicking on the ‘’Property Conditions’ tab. In this case, the Property we are
interested in is PRESENTATION as this is the property in charge of defining
which versions are presented to end-users when a certain Property, Property Class
or Activity is presented. For the PERSONAL.LOAN product, the Property
Condition associated to the PRESENTATION Property is also called
‘PERSONAL.LOAN’. As we still don’t know whether the PERSONAL.LOAN
condition includes a specific AA.ARR.TERM.AMOUNT version for the
LENDING-DECREASE-COMMITMENT activity, it would be a good idea to
also check the condition associated to the PRESENTATION Property also for the
PERSONAL.LOAN.PARENT product, which is the parent of
PERSONAL.LOAN.

Again, we can check the Conditions associated to the

PERSONAL.LOAN.PARENT product through Admin Menu > Product Builder >
Products. Obviously, also the PERSONAL.LOAN.PARENT product belongs to
the LENDING Product Line and to the PERSONAL.LOANS Product Group. By
clicking on the ‘View’ context workflow link, we are able to check the features of
this product, labeled ‘Parent Conditions’.

Under the ‘’Property Conditions’ tab of the PERSONAL.LOAN.PARENT

product, we find a long list of Conditions. Scrolling down to the
PRESENTATION Property, we can see the name of the Condition associated with
it, i.e. LENDING. Now that we know that for the PERSONAL.LOAN product
both a specific Presentation Condition (i.e. PERSONAL.LOAN) and a Parent
Presentation Condition (i.e. LENDING) exist, we should check both for an
AA.ARR.TERM.AMOUNT version linked to the LENDING-DECREASE-
COMMITMENT activity. If such version exists for both the parent and the child
products, then the child’s version will take precedence. Else, the child will inherit
the parent condition’s settings. How can we check the content of these two
Property Conditions and hence the versions included in them? The easiest way to
do so is to look at the AA.PRODUCT.DESIGNER-PRODUCT.CONDITIONS
composite screen available under the Model Bank Admin Menu.

We can view the content of a product condition through Admin Menu > Product
Builder > Product Conditions. In this example, the Property Class through which
we can define how customised screens for AA arrangements are presented to end-
users is ACTIVITY.PRESENTATION. As we have learnt from the AA Basic
Customisation course, each Product Condition associated to
ACTIVITY.PRESENTATION is listing which versions are associated with
Properties, Property Classes or Activities belonging to one or more Products.
In our case, we have to check the content of both the PERSONAL.LOAN and of
the LENDING Product Conditions, to know which version of
AA.ARR.TERM.AMOUNT is linked to LENDING-DECREASE-
COMMITMENT activity, if any. We will start with the PERSONAL.LOAN
condition record as this belongs specifically to the PERSONAL.LOAN Product
(which means that an activity specific version set here would take precedence
over any parent product’s settings).
Important note – if no activity specific version exists in any of the two conditions,
then a Property specific version will be used (in this case, the property would be
‘Commitment’). And if no Property specific version is available, then the
Property Class specific version will be taken in consideration (in this case.
‘TERM.AMOUNT’).

If we want to have a look to the versions associated with the PERSONAL.LOAN

condition, we have to look at the ‘Default Values’ tab under the
PERSONAL.LOAN Condition record. As we can see from this picture, there is
no version specifically associated to the LENDING-DECREASE-
COMMITMENT activity within this record and also specific settings have been
defined nor for the ‘Commitment’ Property and neither for the ‘Term Amount’
Property Class – actually, the only Activity which has versions specifically set for
it is LENDING-NEW-ARRANGEMENT and the only Property Class which
shows a version linked to it is ‘Settlement’.
This means that we have to rely on versions within the Product Condition
associated with the PERSONAL.LOAN.PARENT product, i.e. the LENDING
Product Condition.

Again, through Admin Menu > Product Builder > Product Conditions, we access
to the list of conditions associated with the ACTIVITY.PRESENTATION
Property Class and we choose LENDING.

The ‘Default Values’ tab under the LENDING condition record, presents a
number of activities for which both Activity versions and a Simulation versions
are defined. In our case, we want to identify which AA.ARR.TERM.AMOUNT
version is used to display the ‘Commitment’ screen (i.e. the screen associated
with the ‘Commitment’ Property) while executing the LENDING-DECREASE-
COMMITMENT activity.
We can easily spot such version, which is
AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT.
Please note that if no Activity specific screen had been available, we could have
either created one or used the version associated with the TERM.AMOUNT
Property (as there is no version linked to the ‘Commitment’ property in the
LENDING condition either).
Now that we have identified the customised ‘Commitment’ screen used for
decreasing commitments in Personal Loans arrangements, we must update such
version so that it includes our POST.REST.TA local reference field.

We have identified the version used to display a customised ‘Commitment’ screen

while decreasing the commitment of a Personal Loan arrangement – it’s
AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT. We have now to add our
local reference field called POST.REST.TA to this version.
In order to do so, we can use the SCREEN.DESIGNER composite screen

available under Admin Menu > Implementation Utilities > Customization >
Screen Designer. Once the Screen Designer composite screen pops up, we select
the option ‘New Version’ and then type in the id of the version we want to amend
in the ‘Version Designer’ screen and click on the ‘Edit’ button. This self-
authorising view of the VERSION application can be used to both input new
records and to update them.

Once the AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT version record is

opened in an ‘Edit’ mode, we can add a new field in the first ‘Field Definitions’
tab just by expanding the ‘Field Name’ multi-value field and writing the Standard
Selection name of our local reference field in it. As usual, by expanding ‘Field
name’ we also expand a set of linked multivalues:
Col – is used to define the column position of the current filed
Text Max – defines the number of characters allocated to the field label
Text – contains the field label
Attribute – defines special attributes for the field
On the second ‘Field Definitions’ tab, we can find further details such as
Exp – allows users to block the expansion of a multi-value field, if set to ‘NO’
Enr – defines how many characters will be assigned to the field enrichment text
Dysplay Type – defines whether the field has some special display type (e.g.
Combobox, No column header etc)
Tooltip – defines the field’s tooltip

Let us sum up what we have done so far –
1) We have created a local reference field called POST.REST.TA which contains

information regarding posting restrictions
2) We have linked POST.REST.TA to the Term Amount property class, and
hence to the AA.ARR.TERM.AMOUNT application
3) We have made sure that local field is included in the version
AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT , which is the
customised screen displaying the ‘Commitment’ property and presented to the
end-user while they are decreasing the commitment of a Personal Loan
arrangement. In order to find out about this, we had to check the Conditions
associated to the PRESENTATION Property in the PERSONAL.LOAN
product and in its parent, the PERSONAL.LOAN.PARENT product. Once
identified the two conditions, we checked the versions associated to them
through the PRESENTATION.API property class

Our objective now is to write a routine which is invoked only when the
LENDING-DECREASE-COMMITMENT is performed, extracts the content of
the POST.REST.TA local reference field on the TERM.AMOUNT Property Class
and updates the system field POSTING.RESTRICTION on the ACCOUNT
Property Class. We will later learn how it is possible to attach such routine to the
POST.REST.TA field on the
AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT version.
We need to figure out what the algorithm behind this kind of routine could be. We
should –
1) Get details of the arrangement generated by the end user

2) Map the content of the posting restrict system field against the
POST.REST.TA local reference field
3) Generate a new activity to update posting restriction

We will call our subroutine AA.UPDATE.ACCT.POST. First the required

insert files need to be added. As we know already from Jbase Basic API
programming courses, I_COMMON and I_EQUATE files holds the
common variables and equates for the variables. Let us look into the other
insert files available.
I_AA.LOCAL.COMMON is an insert file for named common variables that

can be used in the local routines developed for AA. Few samples for the
named variables available in this file are, c_aalocArrangementRec that
holds the main arrangement record. c_aalocArrProductId that holds the
product id used by the arrangement etc.
I_F.AA.ACCOUNT has the field names equated to field positions for the
ACCOUNT property class. I_F.AA.TERM.AMOUNT has the filed names
equated to field position for TERM.AMOUNT property class.
The INITIALISE section is used to initialise local variables used in the API.
MAIN.PROCESS section does the main process of the API

In this part of code, you are retrieving the details from

STANDARD.SELECTION for AA.ARR.ACCOUNT application using the
GET.STANDARD.SELECTION.DETS routine. The field name of posting
restriction field is retrieved using FIELD.NUMBERS.TO.NAMES routine.
The FIELD.NUMBERS.TO.NAMES accepts five parameters
FIELD.NUMBERS.TO.NAMES(IN.FIELD.NUMBER,R.STANDARD.SELEC
TION,FIELD.NAME,DATA.TYPE,ERR.MSG)
Incoming Parameters:
IN.FIELD.NUMBER – specifies the field number to be converted; please
note that in this case we are not using the field number directly but using
the common variable AA.AC.POSTING.RESTRICT, instead. This is
possible because we mentioned the insert file I_F.AA.ACCOUNT
within our routine. I_F.AA.ACCOUNT maps all field
numbers against common variables defining the field
name.
R.STANDARD.SELECTION - specifies the standard selection record
content
Outgoing Parameters:
FIELD.NO – used to hold the returned standard selection field name

(different from the common variable within I_F.AA.ACCOUNT), blank if not found
DATA.TYPE - data type is set to “D” by default; in case of error, any other data
type passed back
ERR.MSG - variable to store error messages

GET.ARR.DETAILS is used to get details of the arrangement

UPDATE.ARR.FIELDS is used to map the posting restrict field
UPDATE.POST.RESTRICT is used to generate a new activity to update
posting restriction

If you see the code, the common variables are used to retrieve the
arrangement information. These variables are defined in
I_AA.LOCAL.COMMON
c_aalocArrId holds the arrangement id

c_aalocArrangementRec holds the whole arrangement record
c_aalocArrActivityId holds the arrangement activity id
c_aalocActivityId holds the activity id. In this case the activity id is
LENDING-DECREASE-COMMITMENT
c_aalocActivityEffDate holds the effective date for the activity
c_aalocProductRecord holds the publishes product record for the
arrangement
AA.GET.PROPERTY.NAME routine will retrieve the property name. It

takes two inputs, the product record and the property class for which you
wish to retrieve the property name
SUBROUTINE AA.GET.PROPERTY.NAME(PRODUCT.RECORD,
PROPERTY.CLASS, PROPERTY)
PRODUCT.RECORD – holds the product definition

PROPERTY.CLASS – holds the property class for which properties are sought
PROPERTY - Returns a list of properties (separated by FMs) for the given
property class

UPDATE.ARR.FIELDS.REC paragraph is used to update the property

fields in AA.ARRANGEMENT.ACTIVITY. In order to create a new
arrangement record you need to supply values that need to change in
AA.ARR.ACCOUNT like
AA.ARR.ACCOUNT Field to be updated -> POST.RESTRICT, extracted
previously on slide 36 and placed in the variable
POST.RESTRICT.FLD.NAME
Local Reference Field Name -> POST.REST.TA
Multi value and sub value position -> 1:1
Value -> that has been retrieved from the local reference field and stored
in a variable called POSTING.RESTRICT.VALUE
After getting all the required values to generate an arrangement activity,

instead of manually forming an OFS message, you can call
AA.GEN.ARRANGEMENT.ACTIVITY.FIELDS routine with the property
name, field name and field values.
AA.GEN.ARRANGEMENT.ACTIVITY.FIELDS(ARR.PROPERTY.LIST,
ARR.FIELD.NAME.LIST, ARR.FIELD.VALUE.LIST,
ARR.ACT.FIELDS.REC)
Input parameters:

ARR.PROPERTY.LIST List of arrangement properties

ARR.FIELD.NAME.LIST List of field names of the given arrangement property
ARR.FIELD.VALUE.LIST Values for the field names of the given arrangement
property
ARR.ACT.FIELDS.REC Mapped arrangement activity record

This paragraph UPDATE.POST.RESTRICT is used to create the

AA.ARRANGEMENT.ACTIVITY record for the activity LENDING-
UPDATE-ACCOUNT. The routine
AA.GEN.NEW.ARRANGEMENT.ACTIVITY would create new
arrangement activity record and append the same as secondary activity by
calling the routine AA.SECONDARY.ACTIVITY.MANAGER
AA.GEN.NEW.ARRANGEMENT.ACTIVITY(ARRANGEMENT.ID,
NEW.ACTIVITY, EFFECTIVE.DATE, ARR.TXN.DETAILS,
ARR.ACTIVITY.ID, ARR.ACT.FIELDS.REC, RETURN.ERROR)
ArrangementId – holds the id of the arrangement

NewActivity – holds the secondary activity to be triggered
EffectiveDate - holds the effective date of the activity
ArrTxnDetails - holds transaction information of the arrangement
ArrActivityId – holds the parent arrangement activity id
ArrActFieldsRec – holds the new arrangement activity record

ReturnError is the error variable

Please note that, from R12 TAFC release onwards, if you are trying to compile a
program which has got insert files ( e.g.: I_COMMON, I_EQUATE, etc, etc., )
then the syntax should be
BASIC -I../T24_BP <YOURDIRNAME> <YOUR-PROGRAM-NAME>

[BASIC -I../T24_BP TRG.BP AA.UPDATE.ACCT.POST ]
We are assuming you have, like in this case, all your inserts in T24_BP (which, as
you know, is a directory under bnk.run).

Write, compile, catalogue the routine and then make an entry for the
routine in EB.API application.
@ID – should be the same as the routine @ID
Description – should contain a meaningful description of what this routine
does
Protection level – This is the protection level that is to be followed. The
accepted values are FULL, PARTIAL and NONE
Source Type – Basic or Java are the possible options
It is now time to create a new Condition for the ACTIVIY.API Property

Class which includes the routine we have just created. This will allow us to
attach such Condition to the API Property of the PERSONAL.LOAN
product in order to make sure that our routine is invoked when it is
appropriate.

We can create a new Product Condition by accessing the

AA.PRODUCT.DESIGNER-PRODUCT.CONDITIONS composite screen
through Admin Menu > Product Builder > Product Conditions. Then we select
the ‘New Conditions’ context-based workflow icon beside ACTIVITY.API on the
Property Classes enquiry output.
The ‘Product Condition – Activity API’ screen will appear on the bottom left-
hand side frame of the composite screen. Let us type in the id of our new
Condition (i.e. API.TEST) and then click on the ‘Edit’ icon.

We should now complete the new API.TEST Condition record as follows.

@ID – The @id of the record will contain the name we assigned to it followed by
the current bank’s date (appended by the system)
Activity Id – As in this case we would like the Pre/Post routine to be invoked
when the Commitment is decreased on an arrangement, we can specify in this
field the name of the activity which will act as a trigger (i.e. LENDING-
DECREASE-COMMITMENT). The Activity Id and Activity Class are mutually
exclusive, and hence in this case Activity Class is empty.
Property – Defines the Property ID under which the Pre/post routines will be
Executed. The Property.Class and Property are mutually exclusive fields (and
hence, in this case, the Property Class field is empty). This field can be expanded
to give pre/post routines under various combinations of Activity.Class/Activity,
Property.Class / Property and Action fields
Action - Defines the ACTION under which the Pre/post routines will be
Executed. The ACTION is a mandatory field for a combination of
ACTIVITY.CLASS / ACTIVITY and PROPERTY.CLASS / PROPERTY fields in
a multi value set. This field can be expanded along with a given
PROPERTY.CLASS / PROPERTY.
All other fields will be used to store the @id of routines to be invoked. In this
case, we want to define AA.UPDATE.ACCT.POST as a Post routine, as it will be
invoked after the required ACTION is performed. Please note that more than one
post routine can be defined for an ACTIVITY,PROPERTY.CLASS,ACTION field
combination

Let us now add the new Condition to the PERSONAL.LOAN product. We can
get the full list of available products in R12 Model Bank, through Admin Menu >
Product Builder > Products. As we have seen previously, the PERSONAL.LOAN
product belongs to the LENDING Product Line and to the PERSONAL.LOANS
Product Group. By clicking on the ‘Amend’ context workflow link, we are able
to update the features of the PERSONAL.LOAN product.

In order to attach the new condition to the PERSONAL.LOAN product, we must

open the ‘Property Conditions’ tab and expand the ‘Property’ field, adding one
new value. This new ‘Property’ value should be set to API, while the associated
multi-value of the ‘Conditions’ field should contain the name of our condition,
i.e. API.TEST. Arrangement link should be set to TRACKING.

Let us proof and publish the product in the usual way.

Now, the product is ready and we should be able to test if the POST.REST.TA
local reference field within the ‘Commitment’ screen while decreasing a Personal
Loan arrangement. Also, once the Commitment decrease is authorised, we will
check if the ‘Account’ screen is updated by our routine as expected.

We can create a new Personal Loan arrangement using the

T24.PRODUCT.CATALOG composite screen, through User Menu > Product
Catalog. Then we should select the ‘Lending’ Product Group, the ‘Personal Loan’
Product and then click on the ‘New Arrangement’ context-based workflow icon.

Specify Customer Number, Currency, Amount, Term or Maturity Date and

Account for Repayments etc, then validate & commit. Accept any override. Note
down the new Arrangement Id & log on as a different user to authorise the record.

As you know, in order to authorise any Loan product, we can use the
AA.FIND.ARRANGEMENT.AL composite screen which you find under User
Menu > Retail Operations > Find Loan. Once the composite screen pops up, we
will select the second tab from the left (‘Unauthorised’) and then search by
Arrangement Id.
Once the enquiry output is presented to you, click on the ‘Overview’ context-
workflow icon on the right hand-side of the screen.

Once the ‘Lending Overview – Unauthorised’ composite screen pops up, get the
new record approved. Let us now decrease the commitment of this authorised
Personal Loan arrangement to check if our POST.REST.TA local reference field
is displayed within the ‘Commitment’ screen for the LENDING-DECREASE-
COMMITMENT activity and also to make sure that the
AA.UPDATE.ACCT.POST routine works properly – this should extract the
content of POST.REST.TA and updates the system field ‘POSTING.RESTRICT’
on the ‘Account’ Screen.

As you know, in order to perform a new activity on the authorised personal loan
arrangement, we can use again the AA.FIND.ARRANGEMENT.AL composite
screen available under User Menu > Retail Operations > Find Loan. Once the
composite screen pops up, we will select the first tab from the left (‘Authorised’)
and then search by Arrangement Id.

Once the ‘Arrangement Overview (Lending)’ composite screen has opened, click
on the ‘New Activity’ hyperlink on the top right-hand side of the screen. An
enquiry output listing New User Activities will pop up and you should now select
the ‘Decrease Commitment’ option, under ‘Term Amount’ property class. In order
to do so, click on the ‘Do activity today’ context-workflow icon.

As soon as the the AA.ARRANGEMENT.ACTIVITY screen opens (here we are

using a version called AA.ARRANGEMENT.ACTIVITY,AA.DRILL), we can
see that the ‘Commitment’ screen includes field labeled ‘Posting Restriction for
Term Amount’ and that this field points to the POSTING.RESTRICT table. This
is of course the POST.REST.TA local reference field we had created at the
beginning of this demo.
Our first test on the local reference field has been successful – so now we should
proceed with the second one and check if our post routine is also invoked
correctly. In order to do so, we should complete the required details making sure
that we populate the ‘Posting Restrict for Term Amount’ field (e.g. with option 4),
then commit the record and accept any override.
Once the activity is completed, we should log on as a different user and authorise
it as follows.

Again, we can retrieve the unauthorised activity and approve it through User
will select the first tab from the left (‘Authorised’) and then search by
Arrangement Id.

When the ‘Arrangement Overview (Lending)’ composite screen appears, look at

the Pending Activities list on the ‘Additional Details’ frame located on the bottom
right-hand side of the screen. The unauthorised ‘Decrease Commitment’ activity
will be listed there – select the ‘Approve’ option and authorise the record as soon
as it pops up.
Let us now note down the Id of the current LENDING-DECREASE-
COMMITMENT activity and check the effect of this authorisation on the
arrangement through the AA.ARRANGEMENT.ACTIVITY application.

Let’s now look at the activity we have just authorised through

AA.ARRANGEMENT.ACTIVITY and try to understand whether it has
generated the desired effects. On the activity record, together with the usual
activity information (Arrangement Id, Activity name, Arrangement details etc.),
we can immediately spot two fields which are very important for our second test
–
Child Activity – containing the Id of a child Activity which was generated

automatically when the current activity was authorisied
Master Activity – a system maintained field which is used to indicate the Master
arrangement activity which initiated this transaction. In this case, Master Activity
is the same
as the AA.ARRANGEMENT.ACTIVITY @ID, which implies that the current
activity was input manually and not automatically generated. This is also shown
by the Initiation type field, which is set to USER (meaning that this activity was
manually input by a user)
Let us now jot down the Child Activity Id and check the ‘Commitment’ and
‘Account’ screens on this activity record to see if the update between them has
been carried out successfully between TERM.AMOUNT and ACCOUNT
Property Classes. While executing the LENDING-DECREASE-COMMITMENT
activity, we had populated the local field POST.REST.TA on the ‘Commitment’

screen with value ‘4’. If the routine has worked properly, now the content of the system
field POSTING.RESTRICT on the ‘Account’ screen should be the same.

As expected the value of local field POST.REST.TA on the ‘Commitment’ screen

is ‘4’ as we manually set it while performing LENDING-DECREASE-
COMMITMENT. This was done thanks to the
AA.ARR.TERM.AMOUNT,AA.CHANGE.COMMITMENT version which we
had aptly modified to contain the POST.REST.TA local field.

And on the same record, also the POSTING.RESTRICT system field has been
automatically updated to value ‘4’. This happened because the current
LENDING-DECREASE-COMMITMENT activity, after authorisation, generated
a child activity which updated the ACCOUNT Property as well, thanks to the post
routine we attached to the parent activity. Let us use the Child Activity Id we had
jotted down to check the corresponding record in
AA.ARRANGEMENT.ACTIVITY.

As we can seem the child activity triggered by our post routine is a

LENDING-UPDATE-ACCOUNT as expected.
The linked activity is AAACT12026CHLXLR3T, this is the LENDING-
DECREASE-COMMITMENT activity that generated the LENDING-
UPDATE-ACCOUNT activity.
The Initiation type is SECONDARY. As we know, this field denotes the type
of initiation for the current activity that is whether the activity was triggered by
the user or by external transaction or it could be scheduled or secondary activity.
SECONDARY implies that this activity was automatically generated on
authorisation of another activity (we have previously seen that, in our case, the
master activity has Initiation Type set to USER – other possible values are
SCHEDULED, TRANSACTION and NOLOG)
The activity class is LENDING-UPDATE-ACCOUNT, the property on which
the action should take place is ACCOUNT.
The field that has to be updated is POSTING-RESTRICT at multi value
and sub value position 1:1.
The value that has to used for updating is ‘4’. If you remember, this is the
value that we specified in the POST.REST.TA local reference field
These details show us that also our second and last test is successful –
the post routine has been invoked appropriately, it has extracted the
content of our local reference field and has generated this child LENDING-
UPDATE-ACCOUNT activity to updated the content of the

POSTING.RESTRICT field with such extracted value.

• Let us create a new version of AA.ARR.TERM.AMOUNT which includes

AA.COMMITMENT.MEMO and POST.REST.TA local fields and link this
version to the LENDING-DECREASE-COMMITMENT Activity within
the VEHICLE.LOAN product – if you remember, the local field
AA.COMMITMENT.MEMO was created during Demo 1 of the AA Basic
Customisation Course. Both this and the POST.REST.TA fields will be
included within the new version as we will see. Secondly we will have to
attach the version to the Condition for the PRESENTATION Property in the
VEHICLE.LOAN record.
• Then, we will write a validation routine which updates the local field
AA.COMMITMENT.MEMO with a comment whenever the local field
POST.REST.TA is populated. This will be triggered during validation of an
Vehicle Loan arrangement, while decreasing the arrangement’s commitment
• Finally we will associate this routine to a new Product Condition of the
ACTIVITY.API Property Class and then we will attach such Product
Condition to the Vehicle Loan Product. Remember that you need to proof &
publish the product before you can test your new customised screen layout
and validate routine.
Please note that, as explained in slide 16, the R12_AA_Framework_5 update is

required for this demo to be completed.

1) To create our new version, we will access the Screen Designer Composite
screen, as usual, through Admin Menu> Implementation Utilities >
Customization > Screen Designer and then we should click on the New
Version option.
2) As soon as the New Version screen comes up, we should type in the Id of our
new VERSION record (i.e. AA.ARR.TERM.AMOUNT,VAL.RTN) and then
click on the Edit button.
3) On the main screen, we will jot down a brief description of the Customised
Screen Layout you are creating in GB Description and set the Language field
appropriately. As we have seen, in this version the NO.OF.AUTH field is
defaulted to 1 and cannot be changed.

4) We should now focus on the first Field Definitions tab in order to define the
fields and their basic structure for the AA.ARR.TERM.AMOUNT,VAL.RTN
version record
5) Each of the requested fields should have an entry in FIELD.NAME
6) COL contains instead information about the indentation from the left margin
(i.e. column position).
7) Text Max defines the amount of characters occupied by each field’s label
8) Text field contains the customised label which will be assigned to a specific
field in this version
We can now validate & commit the record. Version Designer is a self-authorising
version and hence our record will become immediately live.

We have created a new customised layout for the TERM AMOUNT Property
Class and our objective is to display this version to end-users whenever they
perform a LENDING-DECREASE-COMMITMENT activity on a Vehicle Loan.
We know that the versions displayed for each Activity, Property or Property Class
are defined through the PRESENTATION.API Property Class (linked to the
PRESENTATION Property) and that there are different ways to attach a specific
version to an activity – you can create a brand new Condition for
PRESENTATION.API from scratch and then attach it to a product, you can
update the VERSION in an already created Condition for a product (as we did in
Demo 1 of this presentation) or you can update an already existing
PRESENTATION Condition, including your version. In the past, we have seen
examples for the first and the second scenario, while now we are going to try and
update and existing Condition.
What we should do is check which condition is associated with the
PRESENTATION property in VEHICLE.LOAN (if any) and then update such
condition so that our version is linked to the LENDING-DECREASE-
COMMITMENT Activity. Note that, if the PRESENTATION condition is
missing we can either create a new one or update the corresponding condition at
the Parent Product level if VEHICLE.LOAN is a Child Product.
We can get the full list of available products in R12 Model Bank, through Admin
Menu > Product Builder > Products. The VEHICLE.LOAN product belongs to
the LENDING Product Line and to the PERSONAL.LOANS Product Group. By
clicking on the ‘View’ context workflow link, we are able to check the features of

our product.

We can check which Property Conditions are associated to the current Product by
clicking on the ‘’Property Conditions’ tab. In this case, the Property we are
interested in is PRESENTATION as this is the property in charge of defining
which versions are presented to end-users when a certain Property, Property Class
or Activity is presented. For the VEHICLE.LOAN product, the Property
Condition associated to the PRESENTATION Property is also called
‘VEHICLE.LOAN’.
We will now update the VEHICLEL.LOAN condition so that it includes our
AA.ARR.TERM.AMOUNT version for the LENDING-DECREASE-
COMMITMENT activity.

Again, through Admin Menu > Product Builder > Product Conditions, we access
to the list of conditions associated with the ACTIVITY.PRESENTATION
Property Class, we choose VEHICLE.LOAN and click on the ‘Update’ context-
based workflow icon, just beside this record.

The ‘Default Values’ tab under the VEHICLE.LOAN condition record, presents
all activities/properties/property classes for which both Activity versions and a
Simulation versions are defined. Those which are not listed here will be defaulted
from the parent product of VEHICLE.LOAN, i.e. PERSONAL.LOAN.PARENT.
In our case, we want to make sure that a specific AA.ARR.TERM.AMOUNT
version is used while executing the LENDING-DECREASE-COMMITMENT
activity.
As we can see, no Activity Version has been defined for the LENDING-
DECREASE-ARRANGEMENT: only the LENDING-NEW-ARRANGEMENT
activity and the SETTLEMENT Property Class have their own versions defined
while the other activities/properties/property classes will inherit their versions
from PERSONAL.LOAN.PARENT.

We do not want to interfere with the Parent Product settings, in this case, so we
will simply multi-value the Activity field and add the LENDING-DECREASE-
ARRANGEMENT value. Then, using the Activity and Property associated fields
we will connect the AA.ARR.TERM.AMOUNT,VER.RTN version to the
COMMITMENT Property for the aforementioned Activity.
Now that our version is associated to the VEHICLE.LOAN Condition, we need to
write a validate routine for inter-field update and attach it to the
VEHICLE.LOAN product through ACTIVITY.API

This Pre-routine is fairly easy as it does not imply the creation of a new
activity but simply the update of the AA.COMMITMENT.MEMO local
reference field if the POST.REST.TA local reference field contains any
value. Within the first part of our routine we will list, as usual, the insert
files we wish to use.
Then we need to identify the content of POST.REST.TA – in order to do
so, we will use a different method from the one previously seen, which
relied on the GET.LOC.REF API (see slides 35-50, Demo 1 of this same
presentation).
In this routine we will take for granted that we already know the position of
POST.REST.TA based on the standard selection record for
AA.PRD.DES.TERM.AMOUNT and AA.ARR.TERM.AMOUNT (we must
remember that that the latter gets automatically updated based on changes made
on the first, together with all the tables linked to the TERM.AMOUNT Property
Class). Checking out Standard Selection, we notice that POST.REST.TA appears
to be stored in the first position <1,1> of the LOCAL.REF field of the
TERM.AMOUNT-related tables, while MEMO.FIELD.POS is located on the
second position <1,2>.
So, in order to extract the values of POST.REST.TA, we use the common
variable AA.AMT.LOCAL.REF (stored under the insert file
I_F.AA.TERM.AMOUNT) assigning to it the correct position – the content
of POST.REST.TA will be located consequently under
AA.AMT.LOCAL.REF <1,1>. Please note that this parameter is supposed

to be inputted manually by the user and, therefore, we will extract it from the
common variable R.NEW – a dimensioned array which, as we know, contains data
from the currently opened record.
Once we have identified the position of POST.REST.TA, we will initialise the
variable MEMO.TEXT that contains the message to be displayed within the
AA.COMMITMENT.MEMO if the condition defined in the IF-THEN-ELSE structure
is true – in this case if the content of POST.REST.TA (initialised to the local
variable POSTING.RESTRICT.VALUE) is not null, then we will position the
content of MEMO.TEXT in AA.AMT.LOCAL.REF<1,2>, which means where the
AA.COMMITMENT.MEMO local reference field is positioned. Else
AA.COMMITMENT.MEMO will be left empty.
The REBUILD.SCREEN API will rebuild the arrangement page in case the
validate routine is invoked in CUI.
We can now compile and catalog our routine


We can create a new Product Condition by accessing the

AA.PRODUCT.DESIGNER-PRODUCT.CONDITIONS composite screen
through Admin Menu > Product Builder > Product Conditions. Then we select
the ‘New Conditions’ context-based workflow icon beside ACTIVITY.API on the
Property Classes enquiry output.
The ‘Product Condition – Activity API’ screen will appear on the bottom left-
hand side frame of the composite screen. Let us type in the id of our new
Condition (i.e. API.VEHICLE.LOAN) and then click on the ‘Edit’ icon.

We should now complete the new API.VEHICLE.LOAN Condition record as

follows.
@ID – The @id of the record will contain the name we assigned to it followed by
the current bank’s date (appended by the system)
GB Description – a meaningful description of what this Activity API condition is
used for
Activity Id – As in this case we would like the Validated routine to be invoked
when the Commitment is decreased on an arrangement, we can specify in this
field the name of the activity which will act as a trigger (i.e. LENDING-
DECREASE-COMMITMENT). The Activity Id and Activity Class are mutually
exclusive, and hence in this case Activity Class is empty.
Property – Defines the Property ID under which the Pre/post routines will be
Executed. The Property.Class and Property are mutually exclusive fields (and
hence, in this case, the Property Class field is empty). This field can be expanded
to give pre/post routines under various combinations of Activity.Class/Activity,
Property.Class / Property and Action fields
Action - Defines the ACTION under which the Pre/post routines will be
Executed. The ACTION is a mandatory field for a combination of
ACTIVITY.CLASS / ACTIVITY and PROPERTY.CLASS / PROPERTY fields in
a multi value set. This field can be expanded along with a given
PROPERTY.CLASS / PROPERTY.
All other fields will be used to store the @id of routines to be invoked. In this

case, we want to define AA.UPDATE.MEMO.VALIDATION as a Validation routine, as it

will be invoked on validation of a record inputted during the required ACTION (i.e.
LENDING-DECREASE-COMMITMENT).
Note that also the field ‘Default Negotiable’ is mandatory and should be populated under
the ‘Negotiation Rules’ tab

Let us now add the new Condition to the VEHICLE.LOAN product. We can get
the full list of available products in R12 Model Bank, through Admin Menu >
Product Builder > Products. As we have seen previously, the VEHICLE.LOAN
product belongs to the LENDING Product Line and to the PERSONAL.LOANS
Product Group. By clicking on the ‘Amend’ context workflow link, we are able
to update the features of the VEHICLE.LOAN product.

In order to attach the new condition to the VEHICLE.LOAN product, we must

open the ‘Property Conditions’ tab and expand the ‘Property’ field, adding one
new value. This new ‘Property’ value should be set to API, while the associated
multi-value of the ‘Conditions’ field should contain the name of our condition,
i.e. API. VEHICLE.LOAN Arrangement link should be set to TRACKING.

Let us proof and publish the product in the usual way.

Now, the product is ready and we should be able to test if our Pre-routine is
triggered on validation, while performing a LENDING-DECREASE-
COMMITMENT activity on a Vehicle Loan arrangement. In order to see this, let
us create & authorise a new Vehicle Loan.

We can create a new Vehicle Loan arrangement using the

T24.PRODUCT.CATALOG composite screen, through User Menu > Product
Catalog. Then we should select the ‘Lending’ Product Group, the ‘Vehicle Loan’
Product and then click on the ‘New Arrangement’ context-based workflow icon.

Specify Customer Number, Currency, Amount, Term or Maturity Date and

Account Reference etc, then validate & commit. Accept any override. Note down
the new Arrangement Id & log on as a different user to authorise the record as
seen in Demo 1.

As you know, in order to authorise any Loan product, we can use the
AA.FIND.ARRANGEMENT.AL composite screen which you find under User
will select the second tab from the left (‘Unauthorised’) and then search by
Arrangement Id.

Once the ‘Lending Overview – Unauthorised’ composite screen pops up, get the
new record approved. Let us now decrease the commitment of this authorised
Vehicle Loan arrangement to check if the AA.ARR.TERM.AMOUNT,VAL.RTN
version is presented and if our pre routine works properly – this should check the
content of POST.REST.TA and updates the local field
AA.COMMITMENT.MEMO on the ‘Commitment’ screen.

As you know, in order to perform a new activity on the authorised personal loan
arrangement, we can use again the AA.FIND.ARRANGEMENT.AL composite
screen available under User Menu > Retail Operations > Find Loan. Once the
composite screen pops up, we will select the first tab from the left (‘Authorised’)
and then search by Arrangement Id.

Once the ‘Arrangement Overview (Lending)’ composite screen has opened, click
on the ‘New Activity’ hyperlink on the top right-hand side of the screen. An
enquiry output listing New User Activities will pop up and you should now select
the ‘Decrease Commitment’ option, under ‘Term Amount’ property class. In order
to do so, click on the ‘Do activity today’ context-workflow icon.

As soon as the the AA.ARRANGEMENT.ACTIVITY screen opens (here we are

using a version called AA.ARRANGEMENT.ACTIVITY,AA.DRILL), we can
see that the ‘Commitment’ screen presents the
AA.ARR.TERM.AMOUNT,VAL.RTN customised screen view we had created,
which includes POST.REST.TA and AA.COMMITMENT.MEMO local reference
fields.
Let us now select an entry in the ‘Posting Restriction for Term Amount’ field and
click on the ‘Validate’ button to invoke our AA.UPDATE.MEMO.VALIDATION
Pre-routine.

After clicking on the ‘Validate’, AA.UPDATE.MEMO.VALIDATION Pre-

routine is invoked correctly – it checks as expected the content of
POST.REST.TA and updates the ‘Arrangement Memo’ field with the warning
message defined within our code.




AAAdvanced Customisation Part 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AAAdvanced Customisation Part 1

Uploaded by

Copyright:

Available Formats

AA Advanced Customisation - Part 1

Temenos University - June 2012 1

Temenos University - June 2012 2

Temenos University - June 2012 3

Temenos University - June 2012 4

Before we proceed and discuss the use of the ACTIVTY.API Property

Temenos University - June 2012 5

• Property Classes are AA reusable components defined by attributes and

Temenos University - June 2012 6

Activities, defined in the application AA.ACTIVITY, describe which action can

Temenos University - June 2012 7

AA.PROPERTY and AA.PRD.DES.<PROPERTY.CLASS> are set up during

As we have seen in the AA Basic Customisation course,

Temenos University - June 2012 8

Local Reference Fields are application fields developed locally in order to

Temenos University - June 2012 9

Customised Screen Layouts are referred as Versions in T24

Temenos University - June 2012 10

As we have seen previously during the AA Basic Customisation course, different

We will review how to set up this through the ACTIVITY.PRESENTATION

Temenos University - June 2012 11

ACTIVITY.PRESENTATION is a Property Class which allows us to attach

Steps involved in associating a Version to an AA Screen are:

Temenos University - June 2012 12

This kind of automatic update would normally require an authorisation routine or

The steps involved to attach a routine to a version of an

Temenos University - June 2012 13

Temenos University - June 2012 13

Temenos University - June 2012 14

- Pre-routines are routines triggered before a certain action, specified in the

Temenos University - June 2012 15

Temenos University - June 2012 15

Temenos University - June 2012 16

Temenos University - June 2012 17

Temenos University - June 2012 18

As you know, we can access the Database Designer Composite Screen by

Temenos University - June 2012 19

Temenos University - June 2012 20

Temenos University - June 2012 20

We have now to attach the newly created POST.REST.TA field to the

Now, the standard Id for the LOCAL.REF.TABLE application is a valid

1. Set AA.PRD.DES.TERM.AMOUNT as a key for our new record

Temenos University - June 2012 21

Temenos University - June 2012 22

Temenos University - June 2012 22

Temenos University - June 2012 23

Temenos University - June 2012 24

Again, we can check the Conditions associated to the

Temenos University - June 2012 25

Under the ‘’Property Conditions’ tab of the PERSONAL.LOAN.PARENT

Temenos University - June 2012 26

Temenos University - June 2012 27

If we want to have a look to the versions associated with the PERSONAL.LOAN

Temenos University - June 2012 28

Temenos University - June 2012 29

Temenos University - June 2012 30

We have identified the version used to display a customised ‘Commitment’ screen

In order to do so, we can use the SCREEN.DESIGNER composite screen

Temenos University - June 2012 31

Once the AA.ARR.TERM.AMOUNT,AA.CHANGE.AMOUNT version record is

Temenos University - June 2012 32

Let us sum up what we have done so far –

1) We have created a local reference field called POST.REST.TA which contains