Document-Management PDF

TEMENOS T24
Document Management
User Guide
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Document Management
Table of Contents
Introduction.............................................................................................................................................. 3
Application Overview ........................................................................................................................... 3
Setting up the System.......................................................................................................................... 4
Application Design ............................................................................................................................... 6
Topics ............................................................................................................................................... 6
Design overview ............................................................................................................................... 6
Overview of Input and Processing ..................................................................................................... 18
Structure of DM Applications.......................................................................................................... 18
Walk-through of setting parameter and data files .......................................................................... 39
Walk-through of Document Tracking by T24.................................................................................. 41
TEMENOS T24 User Guide Page 2 of 55

Document Management
Introduction
Application Overview
The Document Management (DM) module provides the functionality to manage the Documents
obtained from Customers for availing various facilities with a Bank. With this Module installed, it would
be possible to specify details about Classification and Types of Documents, conditions for required
Documents when a Customer relation is established and for the various facilities offered to Customers.
The module would track the Status of required Documents and it would produce appropriate overrides
or errors when the required documents are with an invalid status.

Document Management
Setting up the System
1. Documents obtained from Customers could be categorised into Customer level and Application
level Documents.
2. A Customer level Document is one, which would be required to establish a Customer Relation
with the Bank.
3. For example, Passport Copy would be a Customer level Document.
4. An Application level Document is one, which would be required from a Customer only for
transactions pertaining to a particular Application. Again, an Application level Document could
be categorized into Contract Specific and Non-Contract Specific.
5. A Contract Specific Document is one, which should be separately obtained from a Customer for
each transaction in an Application.
6. For example, a Promissory Note would be a Contract-Specific Application level Document for
LD Loans.
7. A Non-Contract Specific Document is one, which would be obtained once from a Customer
irrespective of any number of transactions in an Application.
8. For example, a Loan Conditions Agreement would be a Non-Contract specific Application level
Document for LD Loans, if it would be applicable all the LD loans granted to a Customer.
9. A Mandatory Document is one, which is specified by User as such, and which could trigger
processing of overrides or error conditions by T24.
10. A Required Document is one, which is determined by T24 based on the defined parameters, as
essential for inputting a record in an application.
11. Track means the processing done by T24 depending on the status of Required Mandatory
Documents, for a record input in an application.
12. Document data files refer to the files CUST.DOCUMENT and TRANS.DOCUMENT, which
stores the details of documents tracked for a Customer.
13. A Tracked Document refers to any Document, which exists in the document data files
CUST.DOCUMENT or TRANS.DOCUMENT.
14. Each Tracked Document in the document data files is associated with only one Customer and it
would be referred to as a Document Tracked for the Customer.
15. If details of a Document for a Customer are not stored in the Document data files, it would be
referred to as a Document not already tracked for a Customer.
16. A Customer Type is any field in a T24 application whose value would refer to the ID of record in
CUSTOMER file (i.e. a Customer of the Bank).
For example, in the application SEC.TRADE the fields CUSTOMER.NO, BROKER.NO are Customer
Types. Documents would be tracked only for pre-defined Customer Types.
1. A Related Application is an application whose mandatory required documents would be also

tracked, when a record is input in another application.

Document Management
For example, when a SEC.TRADE is input, documents required for related records in the application
SEC.ACC.MASTER may be tracked. In this case, SEC.ACC.MASTER would be referred to as a
Related Application of SEC.TRADE.
2. Status of a Document is a description of the position of a tracked document, specified either by

User or T24 in document data files.
3. An Equivalent Document is any document, which would be specified in the parameter files, as
equivalent to another document for the purposes of document tracking.
4. An Expired Document is one with its Expiry Date less than the Processing Date.
A Next Document is one, which would be obtained in replacement of a document before or after its
expiry.

Document Management
Application Design
Topics
The following topics will explain the concept of DM in more detail.
Design overview
The DM Module is designed around parameter files and data files. The conditions for document
tracking are defined in the parameter files and details of documents are stored in the data files.
The parameter files are:
DM.APPLICATION.INFO
DOCUMENT.CLASS
DOCUMENT.TYPE
DOCUMENT.STATUS
DOC.GEN.CONDITION
DOCUMENT.REQUIRED
While DOCUMENT.CLASS, DOCUMENT.TYPE, and DOCUMENT.STATUS records need to be

specified at installation level, other parameter file records need to be specified for each Company
where DM is installed.
The data files are:
CUST.DOCUMENT
TRANS.DOCUMENT
While CUST.DOCUMENT stores Customer specific documents not tied to particular transactions,
TRANS.DOCUMENT stores transaction specific documents.
Invoking Document Tracking

Documents would be tracked when a record is accessed in an application (with file classification CUS
or FIN) with the following T24 functions: INPUT, COPY or HISTORY RESTORE.
When file update functions OFS, EBS.AUTO.FUNCTION are used, documents would be tracked only
when the target applications are accessed with the above referred functions of INPUT, COPY or
HISTORY RESTORE.

Document Management
Once the DM Module is installed in a Company, its processing could be invoked from any T24
application of users choice.
For each application for which DM processing should be invoked, users could specify in
DM.APPLICATION.INFO, for which Customer Types (File names in the application which accept only
Customer IDs) documents need to be tracked. For example, when an FT record is input, documents
might be tracked only for DEBIT.CUSTOMER or for CREDIT.CUSTOMER or for both.
Figure 1 - Specification of Customer Types for FT Application
If a Customer Type for which documents need to be tracked is a multi-valued field, then documents
would be tracked for each Customer ID specified as a value of the field. For example in case of a
SEC.TRADE input, documents would be tracked for each Customer of the trade, if CUSTOMER.NO,
which is a multi-valued field, were specified as a Customer Type.
Document Status
To track documents, T24 uses Status codes associated with them. Users could specify the Status
codes in the application DOCUMENT.STATUS. A Status could be defined only as a Valid or Invalid
Status. T24 uses three pre-defined Status codes of 1 (Received), 2 (Not Received) and 3
(Expired), while creating document records or updating status of expired documents. The
DOCUMENT.STATUS records for these codes are supplied during product installation.
Figure 2 User defined status of 5

Document Management
Document Groups
The Required Documents for a record input could depend on the following factors: Application in
which the record is input, Customer Type for which documents need to be tracked and finally the value
of the data input in various fields.
For this purpose, Users could specify for each application plus Customer Type combination conditions
for document grouping. The conditions for Document groups are specified in the application
DOC.GEN.CONDITION.
For example, for an FT application, the Document groups for the Customer Types DEBIT.CUSTOMER
and CREDIT.CUSTOMER might depend on different conditions.
Figure 3 Specify a Document Group for a Debit Customer
Figure 4 Specify a Document Group for a Credit Customer
There is also a facility to define conditions for Document groups at Application level, which would be
applicable to any Customer Type in the Application, without its own Document Groups.
In the above example, for the Funds Transfer application, the document group conditions could be
specified at FT application level, which would apply to Customer Types DEBIT.CUSTOMER and
CREDIT.CUSTOMER, if they do not have their own document group conditions.

Document Management
Figure 5 - Document Group conditions at Application level for FT
Document Tracking Requirements

Users could specify for each Document Group in an application, the requirements (rules) for
Document Tracking in DOCUMENT.REQUIRED. These requirements would specify the Document
Types to be tracked for the group, whether Customer level documents are to be tracked (for
applications other than CUSTOMER), and whether documents for a Related Application record also
need to be tracked.
Figure 6 Document requirements for Document Group FT*202
While defining documents for a group, Users could specify whether a Document is Mandatory or not
(Field: MANDATORY). T24 would track only Mandatory documents and would not do any processing
with non-Mandatory documents.
While defining documents for a group, Users could specify whether a Mandatory Required Document
with an Invalid STATUS would immediately stop a record input, by setting the field STOP.TXN to YES.
They could also specify a period of time (filed STOP.TXN.DAYS) applied from the STATUS.DATE of a
Mandatory Required Document, up to which an application record which depends on the document,
could be input; T24 would not allow such a record input after the specified time.

Document Management
Confirmation Messages
A Confirmation Message is a new type of Override Message displayed by T24 in a question format;
Users could respond for the message as either YES or CANCEL (in the T24 Browser) and YES or NO
(in Reflection); the responses would be respectively interpreted as a positive and negative response.
Depending on the user response, further processing would be done by T24. A response of CANCEL
or NO would not cancel the transaction as in the case of other Override Messages.
Such Confirmation Messages would be displayed by T24 in the following cases:
o A CUSTOMER record is input and a Mandatory Required Document is not already tracked or
tracked with a STATUS of 2 (Not Received).
o A record is input in any application other than CUSTOMER and a Mandatory Required
Contract-Specific Document is not already tracked or tracked with a STATUS of 2 (Not
Received).
Screen-shot of a Confirmation Message is given below. These messages would display the
Description of a tracked Document type (BIRTH CERTIFICATE), the document group for which it is a
required one (CUS*102) as well as the ID of the Customer (300018) for whom it is tracked.
Figure 7 - Confirmation Message by T24
When a user responds to a Confirmation Message with yes, T24 would create or update a document
data record with a STATUS of 1 (Received). If the User response is CANCEL or NO, T24 would
create or update a document data record with a STATUS of 2 (Not Received). If the User wants to
input any other User defined STATUS (for example, a status code of 5 for Fax Copy Received), User
could later modify the STATUS in document data records.
When a Confirmation Messages is responded to by the User, appropriate Override Messages would
be stored in the application record. In the screenshot, for the Document IDCARD, user has responded
with YES and for the Document DOB, User has responded with CANCEL or NO.

Document Management
Figure 8 Stored Override Messages for Confirmation Messages
Override Messages
For other Mandatory Required Documents not already tracked or already tracked with an Invalid
STATUS, T24 would display and store appropriate normal Override Messages.
In the screen-shot below the Document DOB (with Description BIRTH CERTIFICATE) for Customer
30018 had been already tracked (stored in CUST.DOCUMENT) with a User defined Invalid STATUS,
and while tracking the document again when the CUSTOMER is modified, T24 displays a normal
Override Message.
Figure 9 - Override Message for a Document with invalid status
Document Tracking for CUSTOMER Input

Any tracked document would be associated by T24 with only one Customer (ID of a record in the
CUSTOMER file).
When a CUSTOMER record is input, T24 would determine the required mandatory documents. If any
such document was not already tracked or already tracked with a STATUS of 2 (Not Received), T24
would display a Confirmation Message as to whether the Document has been received. Depending on
the User response, T24 would appropriately create or update a data record for the tracked document
in the file CUST.DOCUMENT.

Document Management
The table below shows the document tracking process when a CUSTOMER record is input.
Document Tracking for Customer Input
Mandatory Type of Status of Message by Update by
Required Document Document T24 and
T24
Documents response by
for User
CUSTOMER Any Document Not already Confirmation Create record in
tracked Message and CUST.
User response: DOCUMENT
YES
with STATUS=1
(Received)
Confirmation Create record in
Message and CUST.
User response: DOCUMENT.
CANCEL or with STATUS=2
NO
(Not Received)
Not Already Error Message No action
Tracked in Live
File.
But CUST.
DOCUMENT in
INAU status
created by an
unauthorized
input from a
different
Application.
Already Tracked Confirmation Update STATUS
in CUST. Message and to 1 (Received)
DOCUMENT with User response:
STATUS=2 YES
(Not Received) Confirmation No action
Message and
(Document
User response: would remain in
same STATUS
CANCEL or
of 2)
NO
Already Tracked Override No action
in Message
CUST.DOCUME
NT with any
Invalid STATUS
other than 2

Document Management
Document tracking for input in Applications other than CUSTOMER

When a record is input in any application other than CUSTOMER, T24 would determine the required
mandatory documents.
o If Customer level documents are required to be tracked (Field CHECK.CUST.LEVEL is YES in

DOCUMENT.REQUIRED), T24 would display Override Messages for all Mandatory Customer
level documents with an Invalid STATUS or not already tracked. If the document is not already
tracked, T24 would create the document in CUST.DOCUMENT with STATUS=2. If the document
is not already tracked, but in unauthorized status due to input from a different application then
T24 would display an Error message.
o If Mandatory documents for Related Applications are required to be tracked, (Field
RELATED.APPLN in DOCUMENT.REQUIRED is not null), T24 would display Override
Messages for all such documents with an Invalid STATUS or not already tracked.
o T24 would display a Confirmation Message whether the Document has been received for
Contract Specific Mandatory documents for the current application, if they are not already
tracked or tracked with a STATUS of 2 (Not Received). Depending on the User response, T24
would appropriately create or update the data record for the tracked document in
TRANS.DOCUMENT.
o T24 would display Override Messages for Contract specific Mandatory documents for the
current application, already tracked with any Invalid STATUS other than 2
o T24 would display Override Messages for Non-Contract specific Mandatory documents for the
current application, with any Invalid STATUS.
The table below shows the document tracking process when a record is input in an application other
than CUSTOMER.
Document tracking for input in an application other than CUSTOMER
Mandatory Type of Status of Message by Update by

Required Document T24 and
Document T24
Documents response by
for User
Current Contract Not already tracked Confirmation Create record in
Application Specific Message and TRANS.DOCUMENT
with STATUS=1
LD (E.g. User
(Received)
Promissory response:
Note) YES
Confirmation Create record in
Message and TRANS.
User DOCUMENT with
response: STATUS=2
CANCEL or
NO (Not Received)

Document Management
Already tracked in Confirmation Update STATUS to 1

TRANS. Message and (Received)
DOCUMENT with User
STATUS=2 (Not response:
Received) YES
Confirmation No action
Message and
(Document would
User remain in same
response: STATUS of 2)
CANCEL or
NO
Already Tracked in Override No action
TRANS. Message
DOCUMENT with
any Invalid STATUS
other than 2
Non-Contract Not Already Override Create record in
Specific Tracked Message CUST.DOCUMENT
with STATUS=2
(E.g. General
Loan Already Tracked in Override No action
Agreement) CUST. Message
DOCUMENT with
any invalid STATUS
including 2
Tracked in Live File. OR Override
Message
But CUST.
based on the
DOCUMENT in field
INAU status created CUST.DOC.O
by an unauthorized VERRIDE in
input from a DM.APPLICA
different TION.INFO
Application.
Customer Any Not already tracked Override Create record in
level Document Message CUST.DOCUMENT.
(CUSTOMER with STATUS=2
application)
Already Tracked in Override No action
CUST. Message
DOCUMENT with
any invalid STATUS
including 2

Document Management

Tracked in Live File. OR Override
Message
But CUST.
based on the
DOCUMENT in field
INAU status created CUST.DOC.O
by an unauthorized VERRIDE in
input from a DM.APPLICA
different TION.INFO
Application.
Related Contract Not already tracked Override Create record in
Application Specific Message TRANS.DOCUMENT
with STATUS=2
(E.g. (E.g. Account
ACCOUNT) Opening Already tracked in Override No action
form) TRANS. Message
DOCUMENT with
any invalid STATUS
including 2
Non-Contract Not already tracked Override Create record in CUST.
Specific Message
DOCUMENT.
(E.g.
with STATUS=2
Electronic
Banking Already tracked in Override No action
Agreement) CUST. Message
DOCUMENT with
any invalid STATUS
including 2
Document Records created by T24

T24 would initially update document data records in an unauthorized state; it would update the live
records only when the underlying transaction is authorised by the User.
When any T24 initiated update to a document data record is outstanding in an unauthorized state,
Users would not be allowed to modify that document data record; this would ensure data integrity of
system-initiated updates.
When the User creates a new document data record and puts it in an unauthorized state, T24 would
not allow the User to commit any application input for which that document is mandatory; this would
ensure data integrity of user initiated updates.
Reversal and History Restore

When any application record is reversed using the REVERSE function, then all the Contract Specific
documents tracked for that application record would be automatically reversed by T24.

Document Management
When a reversed application record is restored using the HISTORY RESTORE function, T24 would
restore required Contract-specific documents from History, after confirming with the User whether to
restore them.
Maintenance of Document records

T24 would calculate and default the expiry date (Field: END.DATE) only for Documents with a Valid
STATUS, whenever any field on which the expiry date calculation depends such as STATUS.DATE,
SIGNATURE.DATE or STATUS is input, in the document data records.
If appropriate, T24 would default an expiry date in the Document data records created by it, during
document tracking.
In the screenshot below, a validity period of 30 Days is specified for the Valid STATUS 5 in the
application DOCUMENT.STATUS, which would be applicable from the STATUS.DATE. T24 has
defaulted an END.DATE of 09 AUG 2001.
Figure 10 - END.DATE defaulted by T24
Users would have an option to update a T24 defaulted expiry date with an appropriate lesser date.
On the End-of-day operations, T24 would update the STATUS of all documents expiring before the
next working day to a T24 defined status of 3 (Expired).
Maintenance of New Document details

A new document obtained in replacement of an expired document could be differentiated in document
data records by a document sequence number, (Field: DOC.SEQUENCE) which should be maintained
by User; T24 would update this field only in those cases, where it initiates update of current document
details with that of the next one.

Document Management
Users have the option to specify details about a next document, while the current document is still
effective. For example, Users could specify the date on which a new document has been sent for
signature to replace the current one, etc.
Figure 11 Details of Next Document updated by User
Users always have the option to directly update the details of the current document with that of the
next one; or Users could make a valid new document received from a Customer to replace the current
one, effective from a future date (Field: NEXT.EFF.DATE in CUST.DOCUMENT and
TRANS.DOCUMENT). On the effective date, T24 would update the details of the current document
with that of the next valid document.
If the next document is with an Invalid STATUS (for example: it is not yet received or received with an
invalid status), T24 would automatically update the details of the current document with that of the
next one, on the expiry (Field: END.DATE) of the current document. For this processing to happen, the
next document should not have expired (either Field: NEXT.END.DATE is null or it is not less than the
working day next to expiry date of current document).

Document Management
Overview of Input and Processing

Structure of DM Applications
GLOBUS Applications
CUSTOMER
CUST.DOCUMENT
DOCUMENT.STATUS DM.APPLICATION.INFO
(Non Contract Specific
(Status definition that (Application level
Documents tracked for a
defines validity) parameters)
Customer)
TRANS.DOCUMENT
DOCUMENT.TYPE DOC.GEN.CONDITION
(Contract Specific
(Document Definition) (Document Groups)
Documents tracked for a
Customer)
DOCUMENT.REQUIRED
(Document Requirements
DOCUMENT.CLASS
for Application and
(Document Classification)
Customer Groups)
Figure 12 - DM Applications Relationship Diagram
Multi-Company
The parameter files:
DOCUMENT.CLASS
DOCUMENT.TYPE
DOCUMENT.STATUS
which describe the Class, Type of Documents and Status Codes are Installation (INT) type files which
could be shared by all Companies.

Document Management
Other parameter files:
DM.APPLICATION.INFO
DOC.GEN.CONDITION
DOCUMENT.REQUIRED
which define the requirements for document tracking, are Financial (FIN) type, Company specific files;
they could be used to define Company specific rules for document tracking.
The data file CUST.DOCUMENT which, stores the details of Non-Contract specific documents tracked
for a Customer is a Customer (CUS) type file; this file would be shared by all Companies which share
the same CUSTOMER file.
The data file TRANS.DOCUMENT which stores the details of Contract-specific documents tracked for
a Customer (for any application) is a Financial (FIN) type, Company specific file. The documents
tracked for an application are stored in the appropriate Companys TRANS.DOCUMENT file,
depending on the type of application.
DM.APPLICATION.INFO
This file contains the details of T24 applications for which DM Module processing should be invoked; it
also specifies the Customer Types in the applications, for which documents should be tracked.
Records of this application could not be reversed.
DM.APPLICATION.INFO Field Description
Field Description
ID Any valid T24 application for which documents need to be tracked.
APPLN.MNEMONIC Specifies Mnemonic for the application, for Document Tracking
purposes.
XX.CUST.FIELD.NAME Specifies the Customer Types (names of customer fields) in the
Application, for whom Documents need to be tracked. Documents
would be tracked only for the customer(s) whose IDs equal the
values of the fields defined here. Input is allowed only for
Applications with File Classification either CUS or FIN.
CUST.DOC.OVERRIDE Specifies whether an error message is to be displayed or an
override message is to be displayed while tracking non-contract
specific documents, which have already been tracked by a
transaction different from that of the application.

Document Management
Specifying Customer Types for Tracking
The field CUST.FILED.NAME specifies the Customer Types for whom documents need to be tracked.
Hence a value of the field specified here should refer to a CUSTOMER record ID. If the value of the
field specified here, does not refer to a CUSTOMER record ID, then no document tracking would be
done for the Customer Type.
Track an Applications documents only from other Applications
If required documents need not be tracked when a record is directly input in an application, but such
documents need to be tracked when a record is input in another application, then no value should be
specified for the field CUST.FILED.NAME. For example, documents might not be required to be
tracked when Security details are input in the file SECURITY.MASTER. However, required documents
for a Security might need to be tracked for a Customer or Broker when a SEC.TRADE is input.
DOCUMENT.CLASS
A Document Class is the classification/grouping of document types at the highest level (e.g. Account
Opening Forms). No processing rules are applicable at this level.
DOCUMENT.CLASS Field Description
Field Description
ID Name of the Document Class.
XX.LL.DESCRIPTION Description of the Document Class.
DOCUMENT.TYPE
A Document Type defines the common characteristics that apply to a particular type of document; a
document obtained from a Customer would be an instance of a Document Type (e.g. Signature Card).
DOCUMENT.TYPE Field Description
Field Description
ID Name of the Document Type.
XX.LL.DESCRIPTION Description of the Document Type.
CLASS The Document Class to which this Document Type is linked to.

Document Management
Field Description
VERSION Version of the Document Type, for information purposes.
BEGIN.DATE Date from when the Document Type needs to be tracked.
END.DATE Date up to which the Document Type needs to be tracked.
REVIEW.FREQ Frequency at which the Document Type needs to be reviewed by
the Bank for its format, etc, and the Next Date of Review.
SIGNATURE.REQD Specifies whether a Signature would be required for Documents of
this Type.
XX.EQUIV.DOC Document Types, which are considered equivalent to this Document
Type for processing purposes.
NEW.ALL.CUST Field to indicate whether a Document of this type is required for all
customers or for only new customers created on or after the
BEGIN.DATE.
NOTICE.DAYS Period before expiration of the Documents of this type, when
customers need to be advised (for information purposes only).
CONTRACT.SPECIFIC Specifies whether a Document of this type needs to be obtained
separately for each Contract (Transaction) from the Customer.
VALID.PERIOD Specifies the period up to which a Document of this type is valid
from the date specified as VALID.BASE.DATE.
VALID.BASE.DATE Specifies the date (at document level), to which the above defined
VALID.PERIOD would be applied to calculate a documents Expiry
Date.
XX.VALID.COMPANY Specifies the Companies(s) in which this Document Type needs to
be tracked.
Stop Tracking a Document Type
Tracking of a Document Type could be temporarily suspended by updating the field BEGIN.DATE to a
future date.
Tracking of a Document Type could be permanently stopped by specifying the field END.DATE.
Equivalent Document Types
The field EQUIV.DOC could be used to define Document Types, which could be treated as alternatives
to a given Document Type, for document tracking purposes. For a Customer application Document
Group, PASSPORT is Mandatory. For PASSPORT, the equivalent documents specified are
DRILICENCE and IDCARD. If one of PASSPORT, DRILICENCE or IDCARD has been tracked with a
Valid Status, then T24 would not display any Override Message; otherwise it would treat it as an
invalid condition and process accordingly.
When none of the main document or its equivalent documents has been already tracked, then if a
Confirmation Message is to be displayed by T24, it would display the message for the main document

Document Management
first. If the User responds with CANCEL/NO, then it would display the message for the first equivalent
document, and then it would continue to display messages for each equivalent document until User
responds with YES. T24 would then create a record only for the Document for which the user has
responded with YES, with a Status of 1 (Received) in the document data files. If the User does not
respond as YES to any one of the main document or its equivalent documents, then T24 would create
a record only for the main document with a status of 2 (Not Received) in the document data files.
Equivalent documents could be defined only for non-contract specific documents.
Company dependent Tracking
The field VALID.COMPANY could be used to restrict the Companies in which a Document Type needs
to be tracked. T24 would apply this condition at the time of tracking. Document REGFXFORM is
specified as applicable only to Companies BN1 and BN2. If the document is a Mandatory one for a
record input in an application, it would be tracked, only if the record is input from Companies BN1 and
BN2.
Customer level documents to be tracked only for new Customers
The field NEW.ALL.CUST is used to restrict tracking a Mandatory Customer level Document type only
for new customers created on or after its effective date. For example, TAXCLRCERT is a Mandatory
Customer level document type with an effective date of 15.2.2002 for a certain group of Customers.
When an existing Customer is modified and the above referred document type is determined by T24
as a Mandatory one for the Customer, if the document has not been already tracked for the Customer,
then T24 would not consider it as an invalid condition. If the document has been already tracked for
the Customer, then T24 would subject it to the normal document tracking processing validations.
DOC.GEN.CONDITION
This file defines the conditions for Document Groups for any T24 application defined in the file
DM.APPLICATION.INFO.
The conditions might be specified for each Customer Type in an Application or at Application level that
could apply to any Customer Type without its own record for Document grouping.
For a record input in an application, document group(s) for the Application plus Customer Type
combination would be determined from this file; Documents required for all such group(s) would be
tracked for the Customer Type. If no matched Group could be found, then documents would not be
tracked for the Customer Type.
To stop documents tracking for a Customer Type in an application, records of this application could be
reversed.
When documents are tracked for multiple customers in an application, and a value of the field to be
tested for determining document groups is associated with the Customers for whom documents are
tracked, it would be possible to specify this through the field ASC.CUS.FLD.

Document Management
For example, if documents are tracked for each Customer in a SEC.TRADE and if the Customer
Residence of each Customer is to be compared to determine the document groups, then: In
DOC.GEN.CONDITION for SEC.TRADE, specify the DECISN.FIELD as CUSTOMER.RESIDENCE
which would be a multi-valued field returning one value for each Customer in the transaction, and then
set the field ASC.CUS.FLD to CUSTOMER.NO. When Documents are tracked for each Customer
(CUSTOMER.NO), then the value of CUSTOMER.RESIDENCE corresponding to that Customer would
be used for comparison purposes.
It is also possible to attach a local sub-routine in the DECISN.FIELD to test other conditions.
The local subroutine must be defined on the PGM.FILE as a V type program and while specifying it as
a value of DECISN.FIELD in DOC.GEN.CONDITION; any valid field name of the application specified
in the ID of the record could be specified as its parameter.
Figure 13 - DOC.GEN.CONDITION with local sub-routine attached
The local subroutine is called from the T24 subroutine DM.GRP.CONDITION to determine the relevant
group(s) the contract falls (if any).
The local subroutine must be defined to accept the following arguments:
APPLN: Name of the application
ID.APPLN: ID of the application record for which documents are tracked
R.APPLN: The application record itself
FIELD.VALUE: Value of the field specified as parameter in the routine attached to

DOC.GEN.CONDITION. If the parameter specified is multi-valued field and a
value is also specified for ASC.CUS.FLD, then this value would be the value
of the parameter field corresponding to the value of ASC.CUS.FLD.
COMPARISON: Value of DECISION in DOC.GEN.CONDITION
DATA.FROM: Value of DECISN.FROM in DOC.GEN.CONDITION

Document Management
DATA.TO: Value of DECISN.TO in DOC.GEN.CONDITION
CONDITION.OK: Value returned should be null or 0 for False or any other value for True.
DOC.GEN.CONDITION Field Description
Field Description
ID Format of the ID will be "Application Mnemonic*Customer Field
Name", where the first part will be the Mnemonic defined for an
application and second part will be a customer field name defined for
that application in DM.APPLICATION.INFO. Second part of the ID is
optional.
SCAN.ALL.GROUP Specifies whether T24 should stop with the first matched group or
whether it should scan all Group(s) to determine all matching
Document Group(s).
XX<DOC.GROUP Specifies a name for the Document Group.
XX-XX<DECISN.FIELD Could be either a local subroutine name or a field defined in the
STANDARD.SELECTION record for the application (identified by the
first part of the key field).
XX-XX-DECISION The comparison operator for the condition to be evaluated.
XX-XX-DECISION.FROM The constant, which the value derived from the DECISN.FIELD is
compared to.
XX-XX-DECISION.TO The upper value used for field value comparisons based on ranges
where the DECISION field is defined as NR (Not in Range) or RG
( in Range).
XX-XX>ASC.CUS.FLD Name of the Customer Field in the application associated with the
Decision filed (DECISN.FIELD) in the set.
Determination of Document Groups
Users could specify by setting the field SCAN.ALL.GROUP to NO whether T24 should stop with the
first matched group or whether it should scan all defined groups to determine other matched groups.
Example: SCAN.ALL.GROUP = YES. A record input satisfies the conditions specified for Groups 101,
102 and 103. Then T24 would track the Mandatory Required Documents for all the Groups 101, 102
and 103. If the value is NO, then T24 would track documents specified for the Group 101, which is the
first matched one.
DOCUMENT.REQUIRED
This application specifies for each Document Group (defined in the file DOC.GEN.CONDITION), the
requirements for documents tracking.

Document Management
Records of this application could be reversed.
If no record exists for a Document Group in this application, then no documents would be determined
as required for that group.
DOCUMENT.REQUIRED Field Description
Field Description
ID Format of the ID will be "Application Mnemonic*Document Group",
where the first part should be the Mnemonic defined for an
application in DM.APPLICATION.INFO and second part should be a
Document Group (field DOC.GROUP in DOC.GEN.CONDITION) for
the application defined in the first part.
CHECK.CUST.LEVEL Specifies whether for this group, customer level documents
(documents required for CUSTOMER input), should be also tracked
in addition to other application level documents.
XX<DOCUMENT.TYPE Specifies Document Type(s) which needs to be tracked for the
Group.
XX-MANDATORY Specifies whether the Document Type is Mandatory or Optional.
XX-STOP.TXN Specifies whether a transaction needs to be stopped, if a required
Mandatory document is invalid. Stopping the transaction would be
subject to the value of the field STOP.TXN.DAYS.
XX-STOP.TXN.DAYS Specifies the Number of days (calculated from a document's Status
Date in the file CUST.DOCUMENT or TRANS.DOCUMENT), after
which a required Mandatory document with an invalid status, would
stop a transaction input.
XX>TXN.PROCESSING Specifies whether the document type needs to be tracked for
transactions input from a related application or not.
XX<RELATED.APPLN Specifies the related application(s) (other than CUSTOMER) whose
required mandatory documents also need to be tracked.
XX-APPLN.ID.LINK Specifies the name of a field in the application specified in the first
part of the ID (application in which a transaction is input), which links
to the related application.
XX>APPLN.CUS.FLD Specifies the name of a customer field in the Related Application.
Documents for the related application would be tracked for the
Customer whose ID is equal to the value of this field in the related
application's appropriate record.

Document Management
Check Customer Level Documents for records input in other Applications
Setting the value of the field CHECK.CUST.LEVEL to YES could specify this. For example, Documents
are tracked for Customer ID 1000 when a record is input in LD application. If this field is specified as
YES, then T24 would determine and track the Mandatory Required Documents (Customer level
documents) for the Customer ID 1000 in CUSTOMER application.
Then it would track the application level documents (for the LD application) for Customer ID 1000
specified in the multi-value field DOCUMENT.TYPE.
Track Application level documents of a Related Application
For tracking documents of a related application, T24 would determine the ID of the record in the
related application ACCOUNT, using the value of the field APPLN.ID.LINK in the current application.
Then it would determine the Customer for whom documents need to be tracked in the ACCOUNT
record. For this purpose, it would use the value of the field in the ACCOUNT record, which is referred
by the APPLN.CUS.FLD. T24 would then determine and track the application level documents for
ACCOUNT for the identified Customer ID. Since the Related Application could have more than one
Customer Type, it is essential to specify for which Customer Type in the Related Application,
documents need to be tracked.
Stop Transactions
Whether a Mandatory document with an Invalid STATUS should stop a transaction could be specified
by setting the field STOP.TXN to YES. If a Confirmation Message is displayed for such documents,
and the User responds with CANCEL or NO, T24 would display an Error Message and control would
return to the application record being input. If only an Override Message is displayed for such a
document (for example, a Non-Contract specific document with an Invalid STATUS), after displaying
the Override Message, T24 would display an Error Message and control would return to the
application record being input.
If the field STOP.TXN.DAYS is set to a specified number of days, then the above referred stopping of a
transaction would occur only when the application record is input after the specified number of days
calculated from the STATUS.DATE of the document.
Restrict Tracking of a Required Document only for input from Main application
It is possible to restrict a required document type (Field: DOCUMENT.TYPE in

DOCUMENT.REQUIRED) for tracking only when input is made from the main application; in such a
case, the document would not be tracked from any other Related Application. This could be specified
by defining a value of NO (do not track for input from another application) in the field
TXN.PROCESSING.

Document Management
Example:
Electronic Statement Agreement (ELESTMT) is a required Document Type for ACCOUNT Document
Group 101 (In DOCUMENT.REQUIRED record with ID AC*101, ELESTMT is specified as a value of
the field DOCUMENT.TYPE). For this document, the field TXN.PROCESSING is set to NO. The
document type ELECSTMT would be tracked whenever an Account is input which belongs to the
Account Document Group 101.
In DOCUMENT.REQUIRED, for a LD loans Document Group, ACCOUNT is defined as a related

application in the field: RELATED.APPLN; When a loan is input in the LD Application, the related
Account belongs to Account Document Group 101. When the documents for the Account are tracked
after LD input, since TXN.PROCESSING is set to NO for the document ELECSTMT in Account
Document Group 101, it would not be tracked.
DOCUMENT.STATUS
This file stores the details of Status codes used in the document data files CUST.DOCUMENT and
TRANS.DOCUMENT.
Records with IDs 1 (Received), 2 (Not Received) and 3 (Expired) are supplied during installation
and these Status ID values are used by T24 in processing. While Status 1 is a valid one (VALID=YES),
both Status 2 and 3 are invalid (VALID=NO).
However, for workflow reasons, an option is available to the Users to modify the Status 1 to an invalid
one (VALID=NO).
When the DOCUMENT.STATUS ID 1 is specified as an invalid one and when a Document is created
by T24 with a Status of 1 (the document is tracked for the first time for the Customer/Transaction and
user responds with YES to a T24 Confirmation Message), the stipulation of stopping a transaction
when a mandatory document is invalid (STOP.TXN=YES in DOCUMENT.REQUIRED) would not be
applicable.
For example, VALID is set to NO in DOCUMENT.STATUS for the ID 1.
The document IDCARD is mandatory for a transaction input and set with STOP.TXN=YES in
DOCUMENT.REQUIRED. When IDCARD is tracked for the first time and the User responds with YES
to the T24 Confirmation Message, the input would not be stopped and T24 would create the
Document with the invalid Status 1. However, when the document IDCARD is again subsequently
tracked and if the document IDCARD is still with Status 1 (an invalid status) in CUST.DOCUMENT or
TRANS.DOCUMENT, the input would be stopped.
Users could define their own Status codes in this application, which could be either Valid or Invalid
(Field: VALID set to YES or NO).

Document Management
DOCUMENT.STATUS Field Description
Field Description
ID ID can be any positive integer subject to a maximum of 10 characters.
XX.LL.DESCRIPTION Description of the status.
VALID Specifies whether this status, if attached to a Document tracked for a
customer would make it valid or invalid.
VALID.PERIOD For a valid status (Value of the Field VALID is YES), this field specifies
the period up to which a Document of this status is valid. The validity
period could be calculated either from STATUS.DATE (in the file
CUST.DOCUMENT or TRANS.DOCUMENT) or from its calendar year
beginning, for a document of this status.
CUST.DOCUMENT
This file stores details of non-contract specific documents tracked for customers. Such documents
could be Customer level documents tracked for CUSTOMER record input or Non-Contract specific
documents tracked for record input in any application other than CUSTOMER.
For example, an IDCARD is a Customer level document tracked for CUSTOMER record input, while a
LOANAGREEM is an Application level document tracked for an LD record input. Both are Non-
contract specific and would be stored in the file CUST.DOCUMENT.
It would be possible to specify the details of the Next Document, while the current one is still effective.
Records in this application could be created or updated by both the User and T24 as explained in this
document.
CUST.DOCUMENT Field Description
Field Description
ID Format of the ID must be "Customer ID.* Document Type ID", where
the first part refers to the ID of the Customer for whom the document is
tracked, and second part refers to the ID of the Document Type.
REFERENCE.NO Specifies the reference for the document, if any.
BEGIN.DATE Specifies the Date from which the Document is tracked in T24.
STATUS Specifies the Status of the Document.
STATUS.DATE Specifies the Date from which the Status applies to the Document.
XX.LL.STAT.DETAILS Specifies the remarks if any, on the current status of the document.

Document Management
Field Description
SIG.DATE Specifies the Date on which Signature has been obtained on the
Document.
END.DATE Specifies the expiry date of the document.
DOC.SEQUENCE Specifies the Sequence Number of a Document, to distinguish
documents obtained on expiry of an earlier one.
LAST.UPD.DATE Specifies the date the record was last updated.
LAST.UPD.APPLN When the document record is updated by T24, this field specifies the
application from which T24 is updating it.
APPLN.TXN.REF When the document record is updated by T24, this field specifies the
transaction reference number of the application, from which T24 is
updating it.
UPDATE.BY Used for T24 processing.
NEXT.STATUS Specifies Status of the Next Document.

XX.LL.NEXT.DETAILS Specifies the remarks if any, on the status of the Next Document.
NEXT.EFF.DATE Specifies the Date on which a Valid Next Document would become
effective, for tracking purposes.
NEXT.STATUS.DATE Specifies the Date from which the specified status (NEXT.STATUS)
applies to the Next Document.
NEXT.SIG.DATE Specifies the Date on which Signature has been obtained on the Next
Document.
NEXT.END.DATE Specifies the expiry date of the Next Document.
Processing of Expiry Date
If the STATUS of a document is Invalid, T24 would not default any Expiry Date; then User could
optionally input any date not less than Bank Date as its Expiry Date. However, when a Document is
initially created by T24 based on User response of YES to the T24 confirmation message Have you
received ., then the Expiry Date of the Document would be updated by T24, irrespective of whether
the STATUS 1 of the created Document is defined as valid or invalid.
If a document is with a Valid STATUS, T24 would default the Expiry Date (Field END.DATE) of a
document (in CUST.DOCUMENT or TRANS.DOCUMENT), whenever the fields STATUS OR
STATUS.DATE or SIG.DATE is updated by the User.
The Expiry Date defaulted by T24 would be the least of:
1. Expiry Date calculated as per the validity period (Field: VALID.PEIOD) specified for the
STATUS in DOCUMENT.STATUS and
2. Expiry Date calculated as per the validity period (Field: VALID.PEIOD) specified for the
document type in DOCUMENT.TYPE.

Document Management
The User would be allowed to update the T24 defaulted date only to an appropriate lesser date.
Whenever T24 creates or updates a document data record with STATUS 1 (Received), it would
default an Expiry Date, if there is a validity period defined for the document type in DOCUMENT.TYPE.
If T24 does not default an Expiry Date, then User could specify any date not less than the Bank Date
as Expiry Date.
On the End-of-day operations, T24 would update the STATUS of all documents expiring before the
next working day, to a T24 defined status of 3 (Expired).
Expiry Date Calculation - Example

Document Management
Processing of Next Document
The following processing for Next Document applies equally to documents either in
CUST.DOCUMENT or TRANS.DOCUMENT.
It may be required to send reminders to a Customer or forward the next document for signature, etc,
before the expiry-date of a current document. It is possible for a User to specify the Status and other
details associated with a Next Document, while the current one is still effective, in the fields from
NEXT.STATUS to NEXT.END.DATE.
The Bank might obtain the Next Document signed from the Customer before the expiry of the current
one. When the Next Document is received, Bank would like to make it effective immediately or from a
future date. It is always possible for the User to directly update the details of the current document
(Fields from REFERENCE.NO to SIG.DATE) with that of the next Document, if the next one is to be
made effective immediately. Whenever the User directly updates the details of the current one with
that of the next document, care should be taken by the User to increment the field DOC.SEQUENCE by
1 to indicate that the current document has been replaced with a new one.
However, the User would have an option to make a Valid Next Document effective from a future date,
by specifying a value for the field NEXT.EFF.DATE. T24 would automatically update the details of the
current document with that of Next one on the Effective Date specified by the User.
If the Next Document is with an Invalid STATUS (field NEXT.STATUS), Users would not be allowed to
make it effective from a specified future date.
After expiry of the current document, if the Next Document is with an Invalid STATUS and not yet
expired, T24 would automatically update the details of the current document with that of Next one.

Document Management
Processing of Next Document - Example
A Promissory Note (ID: PROMNOTE) received from Customer ID 1000 is due to expire on 20.03.2002.
The Bank forwards a new Promissory Note to customer on 10.02.2002 for signature. User might input
a status of 6 (Next Document sent for Signature Invalid Status defined by User) for the Next
Document (Field: NEXT.STATUS) and update its details.
Input of Next Document Details
Field Description
ID 1000*PROMNOTE
REFERENCE.NO PN12856
BEGIN.DATE 25.03.1999 (Date first tracked in T24)
STATUS 1 (Received)
STATUS.DATE 25.03.1999 (Date of Receipt by Bank)
XX.LL.STAT.DETAILS
END.DATE 20.03.2002 (3 years from Signature Date)
SIG.DATE 21.03.1999
DOC.SEQUENCE 2 (This is the second document of the same ID tracked for the
Customer)
NEXT.STATUS 6 (New Document sent for signature A user defined Invalid

Status)
XX.LL.NEXT.DETAILS Chaser to be sent on 20.02.2002
NEXT.EFF.DATE
NEXT.STATUS.DATE 10.02.2002 (Date New Document sent for signature)
NEXT.SIG.DATE
NEXT.END.DATE
Case 1: There is no response from the Customer and the next document continues with an Invalid
Status.
Step 1: On End-of-Day of 20.03.2002 (Expiry of Current Document):
Status of current document would be updated by T24 to 3 (Expired).

Document Management
T24 Update: On expiry of Current Document with valid status
Field Description
ID 1000*PROMNOTE
BEGIN.DATE 25.03.1999
STATUS 3 (Expired) (updated by T24)
STATUS.DATE 20.03.2002 (Updated by T24 to Bank Date)
XX.LL.STAT.DETAILS
SIG.DATE 21.03.1999
END.DATE 20.03.2002
DOC.SEQUENCE 2
NEXT.STATUS 6
XX.LL.NEXT.DETAILS Chaser to be sent on 20.02.2002
NEXT.EFF.DATE
NEXT.STATUS.DATE 10.02.2002
NEXT.SIG.DATE
NEXT.END.DATE
Step 2: On End-of-Day of 20.03.2002 (After expiry of Current Document):

Since the status of the next document (Field: NEXT.STATUS) is Invalid and the next document has not
yet expired, T24 would update the current document details with that of the next one.

Document Management
T24 Update: After expiry of current document with valid status
Field Description
ID 1000*PROMNOTE
STATUS 6 (Updated by T24 from NEXT.STATUS)
STATUS.DATE 10.02.2002 (Updated by T24 from NEXT.STATUS.DATE)
XX.LL.STAT.DETAILS Chaser to be sent on 20.02.2002 (Updated by T24 from
NEXT.DETAILS)
SIG.DATE
END.DATE
DOC.SEQUENCE 3 (Previous sequence incremented by 1).
NEXT.STATUS Cleared by T24

XX.LL.NEXT.DETAILS Cleared by T24
NEXT.EFF.DATE Cleared by T24
NEXT.STATUS.DATE Cleared by T24
NEXT.SIG.DATE Cleared by T24
NEXT.END.DATE Cleared by T24
Case 2: Customer has signed a new Promissory Note on 15.02.2002, which was received by the
Bank on 16.02.2002. If the Bank desires to make the new document immediately effective, they could
directly update the details of the current document with that of next one, and clear the details of the
next one, on 16.02.2002.

Document Management
User update: Current document details with that of next document
Field Description
ID 1000*PROMNOTE
REFERENCE.NO PN14989 (New Reference No.) (Updated by User)
BEGIN.DATE 25.03.1999 (No change field)
STATUS 1 (Received) (updated by User)
STATUS.DATE 16.02.2002 (Date received from Customer) (updated by User)
XX.LL.STAT.DETAILS
SIG.DATE 15.02.2002 (updated by User)
END.DATE 14.02.2005 (Calculated by T24 and accepted by User)
DOC.SEQUENCE 3 (Previous sequence incremented by 1 by User).
NEXT.STATUS Cleared by User

XX.LL.NEXT.DETAILS Cleared by User
NEXT.EFF.DATE Cleared by User
NEXT.STATUS.DATE Cleared by User
NEXT.SIG.DATE Cleared by User
NEXT.END.DATE Cleared by User
Case 3: Customer has signed a new Promissory Note on 15.02.2002, and was received by the Bank
on 16.02.2002. Bank desires to make it effective only from 21.03.2002 (after expiry of the current
document), and use the current document till its expiry.

Document Management
Step 1: On receipt of the new Promissory Note on 16.02.2002, User could update the details of the
Next Document, with the following details, to make it effective from 21.03.2002.
User update: Next Document details
Field Description
ID 1000*PROMNOTE
STATUS 1
STATUS.DATE 25.03.1999
XX.LL.STAT.DETAILS
END.DATE 20.03.2002
SIG.DATE 21.03.1999
DOC.SEQUENCE 2
NEXT.STATUS 1 (valid status for next document updated by User)

XX.LL.NEXT.DETAILS
NEXT.EFF.DATE 21.03.2002 (Make effective the Next Document from this Date)
(updated by User)
NEXT.STATUS.DATE 16.02.2002 (Date of receipt by Bank) (updated by User)
NEXT.SIG.DATE 15.02.2002 (Date of signature on next document) (updated by User)
NEXT.END.DATE 14.02.2005 (Calculated by T24 and accepted by User)

Document Management
Step 2:
On Start-of-Day of 21.03.2002, the Effective Date of the Next Document (field NEXT.EFF.DATE), T24
would update the details of the Current Document with that of the valid Next Document.
T24 update: On Effective Date of Next Document
Field Description
ID 1000*PROMNOTE
STATUS 1 (Updated by T24 from NEXT.STATUS)
STATUS.DATE 16.02.2002 (Updated by T24 from NEXT.STATUS.DATE)
XX.LL.STAT.DETAILS (Updated by T24 from NEXT.DETAILS)
END.DATE 14.02.2005 (Updated by T24 from NEXT.END.DATE)
SIG.DATE 15.02.2002 (Updated by T24 from NEXT.SIG.DATE)
DOC.SEQUENCE 3 (Incremented by 1 by T24)
NEXT.STATUS Cleared by T24

XX.LL.NEXT.DETAILS Cleared by T24
NEXT.EFF.DATE Cleared by T24
NEXT.STATUS.DATE Cleared by T24
NEXT.SIG.DATE Cleared by T24
NEXT.END.DATE Cleared by T24
TRANS.DOCUMENT
This file stores details of Contract specific documents tracked for customers, in all applications other
than CUSTOMER.
When a transaction is reversed in an application, its related documents in this file would be reversed
by T24.

Document Management
TRANS.DOCUMENT Field Description
Field Description
ID Format of the ID must be "Customer ID.* Application Mnemonic *
Transaction ID * Document Type ID", where the first part refers to the
ID of the Customer for whom the document is tracked, second and
third part refer to the Application and Record ID for which the
Document is tracked, and the last part refer to the ID of the Document
Type.
REFERENCE.NO Specifies the reference for the document, if any.
BEGIN.DATE Specifies the Date from which the Document is tracked in T24.
STATUS Specifies the Status of the Document.
STATUS.DATE Specifies the Date from which the Status applies to the Document.
XX.LL.STAT.DETAILS Specifies the remarks if any, on the current status of the document.
SIG.DATE Specifies the Date on which Signature has been obtained on the
Document.
END.DATE Specifies the expiry date of the document.
DOC.SEQUENCE Specifies the Sequence Number of a Document, to distinguish
documents obtained on expiry of an earlier one.
LAST.UPD.DATE Specifies the date the record was last updated.
LAST.UPD.APPLN When the document record is updated by T24, this field specifies the
application from which T24 is updating it.
APPLN.TXN.REF When the document record is updated by T24, this field specifies the
transaction reference number of the application, from which T24 is
updating it.
UPDATE.BY Used for T24 processing.
NEXT.STATUS Specifies Status of the Next Document.

XX.LL.NEXT.DETAILS Specifies the remarks if any, on the status of the Next Document.
NEXT.EFF.DATE Specifies the Date on which a Valid Next Document would become
effective, for tracking purposes.
NEXT.STATUS.DATE Specifies the Date from which the specified status (NEXT.STATUS)
applies to the Next Document.
NEXT.SIG.DATE Specifies the Date on which Signature has been obtained on the Next
Document.
NEXT.END.DATE Specifies the expiry date of the Next Document.

Document Management
DM.DOCUMENTS.TRACKED
This file stores T24 generated records with details of documents tracked for an authorized application
record.
DM.DOCUMENTS.TRACKED Field Description
Field Description
ID Format of the ID is "YYYYMMDD * Application Mnemonic *
Transaction ID", where the first part refers to the date the application
record input, second and third part refer to the Application and Record
ID for which the Documents are tracked.
xx-DOCUMENT Specifies the IDs of both CUST.DOCUMENT and
TRANS.DOCUMENT records tracked for the application record input.
Figure 14 DM.DOCUMENTS.TRACKED Example
Walk-through of setting parameter and data files

1. Determine for which T24 applications, document tracking needs to be invoked. For each such
application, determine the Customer Types for whom documents need to be tracked. Input
these details in the application DM.APPLICATION.INFO.
2. Determine whether any additional Status such as Advice Sent, Signature not obtained, etc.
need to be used in addition to the system installed Status records.
If so, determine for each Status:
Whether such Status could be valid or invalid.
If valid, determine what would be the period of validity, if any, for such status.
Whether the validity period could be applicable from the STATUS.DATE or from its
calendar year beginning, for documents with this status?

Document Management
Input the appropriate details in the application DOCUMENT.STATUS.
3. Determine the Document Class and Types, which need to be tracked by T24.
In particular, determine for each Document Type:
From and up to when it needs to be tracked?
What would be the frequency for reviewing the format, etc. of it?
Whether a signature is mandatory for documents of that type?
Whether there could be any equivalent documents?
Whether it would be applicable only to new customers?
What would be the validity period that would be applicable to a document of that type?
Whether the validity period could be applicable to a document of that type either from
its STATUS.DATE or SIGNATURE.DATE?
Whether the validity period could be applicable from the date specified above or from
its calendar year beginning?
Whether it is required only in specified Companies?
Input the appropriate details in the applications DOCUMENT.CLASS and DOCUMENT.TYPE.
4. If there are multiple Customer Types in an application, determine whether the conditions for
Document Grouping would differ for them or they would share the common conditions. In the
first case document groups need to be defined for each Application plus Customer Type
combination and in the later case document groups need to be defined only at each
application level.
5. For each such combination, determine distinct document groups with unique document
requirements, and the conditions under which this grouping could be done. Input the details of
the Document Groups in the application DOC.GEN.CONDITION.

Document Management
6. For each Document Group defined above, determine the requirements for Document Tracking.
In particular, for each Document Group:
Determine the Document Types, which need to be tracked.
For each Document Type, determine:
! Whether it is Mandatory or not?
! Whether its Invalid STATUS would immediately stop a transaction input?
! Whether its Invalid STATUS would stop a transaction input only after a specified
number of days from its STATUS.DATE?
! Whether Customer level documents also need to be tracked?
! Determine the Related Applications whose documents also need to be tracked.
For each Related Application, determine:
! Which field in the current application would hold the value of a Record ID in the
Related Application?
! For which Customer Type in the Related Application, documents need to be
tracked?
Input the records with relevant details in the application DOCUMENT.REQUIRED.
7. If there exists non-Contract specific documents, which were already tracked for a Customer,
input their details in the application CUST.DOCUMENT. The date of their original receipt, etc.
should be input as STATUS.DATE. Also input their current STATUS, etc. Ensure that the Expiry
Date (Field END.DATE), if any defaulted by T24 is correct; if not modify the record to hold the
correct Expiry Date.
8. Do a similar exercise for Contract specific documents and input their details in the Application
TRANS.DOCUMENT.
Walk-through of Document Tracking by T24

The following demonstration illustrates T24 screenshots for setting up parameter files for invoking
document tracking for an LD Loan input, with a requirement to track Customer level Documents and
documents for the DRAWDOWN.ACCOUNT in related application ACCOUNT, in addition to documents
for LD input itself. It also illustrates the T24 Overrides and Confirmation Messages displayed, while the
documents are tracked.
Step 1: User input of Parameter files

Document Management
User inputs record for CUSTOMER Application in DM.APPLICATION.INFO.
Figure 15 - Input for CUSTOMER Application in DM.APPLICATION.INFO
User inputs record for LD Application in DM.APPLICATION.INFO and specifies Customer Types for
whom documents need to be tracked in LD.
Figure 16 - Input for LD Application in DM.APPLICATION.INFO
User inputs record for Related Application ACCOUNT in DM.APPLICATION.INFO and specifies
Customer Types for whom documents need to be tracked in ACCOUNT.
Figure 17 - Input for ACCOUNT Application in DM.APPLICATION.INFO

Document Management
User inputs record for IDENTIFER class of documents in DOCUMENT.CLASS.
Figure 18 - Input for ID: IDENTIFIER in DOCUMENT.CLASS
User inputs record for document type IDCARD in DOCUMENT.TYPE.
Figure 19 - Input for ID: IDCARD in DOCUMENT.TYPE
User inputs Document Group conditions record for CUSTOMER application in DOC.GEN.CONDITION.
Group 102 defined for Customers with SECTOR=4100 (Private Individuals).

Group 101 defined as a default group for other Customers.

Document Management
Figure 20 - Input for CUSTOMER Application in DOC.GEN.CONDITION
1.7. User inputs Document Group conditions record for LD Application in DOC.GEN.CONDITION.
The record applies at Application level, for any Customer Type in LD, without its own document
group conditions.
Conditions for Document Group 202 is defined for LD Loan Contracts with CATEGORY=21050
Figure 21 - Input for LD Application in DOC.GEN.CONDITION

Document Management
1.8. User inputs Document Group conditions record for Related Application ACCOUNT in
DOC.GEN.CONDITION.
The record applies at Application level for a Customer Type without its own record.
Group 301 defined as a default group, which would apply to any Account.
Figure 22 - Input for ACCOUNT Application in DOC.GEN.CONDITION
1.9. User inputs Document requirements record for CUSTOMER Document Group 102 in
DOCUMENT.REQUIRED.
Two Mandatory Documents IDCARD and DOB are required.

Both the documents will be tracked from Related applications also (Field TXN.PROCESSING is
YES)
Figure 23 - Input for CUSTOMER Group 102 (Private Individuals) in

DOCUMENT.REQUIRED

Document Management
1.10. User input document requirements record for ACCOUNT Document Group 301 in
DOCUMENT.REQUIRED.
One Mandatory Document ACOPENFORM (Contract-Specific in DOCUMENT.TYPE) is required.

Specified that Customer level documents need to be tracked for this group (Field
CHECK.CUST.LEVEL is YES).
Figure 24 - Input for default ACCOUNT Group 301 in DOCUMENT.REQUIRED
1.11. User input document requirement record for LD Document Group 202 in
DOCUMENT.REQUIRED.
One Mandatory Document PROMNOTE (Contract-Specific in DOCUMENT.TYPE) is required.

The document would stop a transaction if tracked with an Invalid STATUS (Field STOP.TXN is
YES).
Another Mandatory Document LOANAGRMT (Non-Contract Specific in DOCUMENT.TYPE) is
required.
Specified that Customer level documents need to be tracked for this group (Field
CHECK.CUST.LEVEL is YES).
Documents for an Account with ID equal in value to DRAWDOWN.ACCOUNT in the Related
Application ACCOUNT should be tracked.

Document Management
Figure 25 - Input for LD Group 202 (Loans) in DOCUMENT REQUIRED
Step 2: Track Documents for an LD Loan input
2.1. User inputs CUSTOMER record with SECTOR=4100.
Mandatory Required Documents: IDCARD (Not already tracked) and DOB (Not already tracked).
Response by T24:
Since document IDCARD is not already tracked, it displays a Confirmation Message. User has
already received the document and he responds with YES.
Since document DOB is not already tracked, it displays a Confirmation Message. User has not
received the document and he responds with CANCEL or NO.

Document Management
Figure 26 - T24 Confirmation Message for document IDCARD after CUSTOMER Input

Document Management
Figure 27 - T24 Confirmation Message for document DOB after CUSTOMER Input
2.2. T24 has created the following Documents in the file CUST.DOCUMENT, based on the User
response.
Record for the Document IDCARD with STATUS=1 (Received).
Record for the Document DOB with STATUS=2 (Not Received).
Figure 28 - CUST.DOCUMENT created by T24 for the document DOB
2.3. User inputs a new ACCOUNT for the Customer ID 300018 already created..
Mandatory Required Documents:

Document Management
Customer level: IDCARD (with a Valid STATUS of 1) and DOB (with an Invalid STATUS of 2).
For own Application: Contract Specific document ACOPENFORM (Not already tracked).
Response by T24:
Since document IDCARD is with a Valid STATUS of 1, it does not display any Override Message.
Since document DOB is with an Invalid STATUS of 2, it displays an Override Message.
Since Contract-specific document ACOPENFORM was not already tracked, it displays a
Confirmation Message. User responds with YES, since he has received the document.
Figure 29 - Override for Invalid Customer level document DOB after ACCOUNT Input

Document Management
Figure 30 - Confirmation Message for Contract Specific Doc. ACOPENFORM after

ACCOUNT Input
2.4. T24 has created a record for the document ACOPENFORM with STATUS=1 (Received) in the file
TRANS.DOCUMENT, based on the User response.
Figure 31 - Document record for ACOPENFORM created in TRANS.DOCUMENT by

T24
2.5. User inputs a new LD Loan Account (CATGORY=21050) for the Customer ID 300018 already
created, with DRAWDOWN.ACCOUNT=40436.

Document Management
Customer level: IDCARD (with a Valid STATUS OF 1) and DOB (with an Invalid STATUS of 2).
For Own Application: Non-Contract Specific document LOANAGRMT (Not already tracked).
For Own Application: Contract Specific document PROMNOTE (with STOP.TXN flag set to YES
and Not already tracked).
For Related Application ACCOUNT: Contract Specific document ACOPENFORM for the
ACCOUNT with ID 40436 (equal to value of DRAWDOWN.ACCOUNT) and for Customer ID 300018
(equal to value of field CUSTOMER in the ACCOUNT record) (with a Valid STATUS of 1).
Response by T24:
Since documents IDCARD and ACOPENFORM are with Valid STATUS, it does not display any
Override Message.
Since document PROMNOTE was not already tracked and it is Contract specific document for the
current application, it displays a Confirmation Message. User responds with NO, since the
document has not been received.
Since the field STOP.TXN flag is set to YES for the document in DOCUMENT.REQUIRED, it
displays an Error Message and control returns to the application record.
Figure 32 - Confirmation Message for Contract-specific document PROMNOTE after

LD Input

Document Management
Figure 33 - Error Message for Invalid Doc. PROMNOTE (Stop.Txn Flag set to YES)
after LD Input
2.6. User again commits the above record and now responds with YES for the Contract-specific
Document PROMNOTE Confirmation Message.
Customer level: IDCARD (with a Valid STATUS OF 1) and DOB (with an Invalid STATUS of 2).
For Own Application: Non-Contract Specific document LOANAGRMT (Not already tracked).
For Own Application: Contract Specific document PROMNOTE (with STOP.TXN flag set to YES
and Not already tracked).
For Related Application ACCOUNT: Contract Specific document ACOPENFORM for the
ACCOUNT with ID 40436 (equal to value of DRAWDOWN.ACCOUNT) and for Customer ID 300018
(equal to value of field CUSTOMER in the ACCOUNT record) (with a Valid STATUS of 1).
Response by T24:
Since documents IDCARD and ACOPENFORM are with Valid STATUS, it does not display any
Override Message.
Since document DOB is with an Invalid STATUS of 2, it displays an Override Message.
Since document LOANAGRMT was not already tracked, it displays an Override Message. It does
not display a Confirmation Message, since it is not Contract-Specific.
Since document PROMNOTE was not already tracked and it is a Contract-specific document for
the current application, it displays a Confirmation Message. User now responds with YES, since
he has received the document.

Document Management
Figure 34 - Override Message for invalid Customer level document DOB After LD Input
Figure 35 - Override Message for Invalid Non-Contract specific doc. (for LD

application) after LD Input

Document Management
Figure 36 - Confirmation Message for Contract-specific doc. PROMNOTE after LD

Input
2.7. T24 would store in the application record, the details of User response (Received or Not
Received) for the Confirmation Messages displayed by it.
Figure 37 Document Tracking Override Messages stored in the LD record

Document-Management PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Document-Management PDF

Transféré par

Droits d'auteur :

Formats disponibles

TEMENOS T24

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 55

TEMENOS T24 User Guide Page 3 of 55

Setting up the System

1. A Related Application is an application whose mandatory required documents would be also

TEMENOS T24 User Guide Page 4 of 55

2. Status of a Document is a description of the position of a tracked document, specified either by

TEMENOS T24 User Guide Page 5 of 55

The parameter files are:

While DOCUMENT.CLASS, DOCUMENT.TYPE, and DOCUMENT.STATUS records need to be

The data files are:

Invoking Document Tracking

TEMENOS T24 User Guide Page 6 of 55

Figure 1 - Specification of Customer Types for FT Application

Figure 2 User defined status of 5

TEMENOS T24 User Guide Page 7 of 55

Figure 3 Specify a Document Group for a Debit Customer

Figure 4 Specify a Document Group for a Credit Customer

TEMENOS T24 User Guide Page 8 of 55

Figure 5 - Document Group conditions at Application level for FT

Document Tracking Requirements

Figure 6 Document requirements for Document Group FT*202

TEMENOS T24 User Guide Page 9 of 55

Such Confirmation Messages would be displayed by T24 in the following cases:

Figure 7 - Confirmation Message by T24

TEMENOS T24 User Guide Page 10 of 55

Figure 8 Stored Override Messages for Confirmation Messages

Figure 9 - Override Message for a Document with invalid status

Document Tracking for CUSTOMER Input

TEMENOS T24 User Guide Page 11 of 55

TEMENOS T24 User Guide Page 12 of 55

Document tracking for input in Applications other than CUSTOMER

o If Customer level documents are required to be tracked (Field CHECK.CUST.LEVEL is YES in

Document tracking for input in an application other than CUSTOMER

Mandatory Type of Status of Message by Update by

TEMENOS T24 User Guide Page 13 of 55

Already tracked in Confirmation Update STATUS to 1

TEMENOS T24 User Guide Page 14 of 55

Not Already Error Message No action

Document Records created by T24

Reversal and History Restore

TEMENOS T24 User Guide Page 15 of 55

Maintenance of Document records

Figure 10 - END.DATE defaulted by T24

Maintenance of New Document details

TEMENOS T24 User Guide Page 16 of 55

Figure 11 Details of Next Document updated by User

TEMENOS T24 User Guide Page 17 of 55

Overview of Input and Processing

Figure 12 - DM Applications Relationship Diagram

TEMENOS T24 User Guide Page 18 of 55

Other parameter files:

Records of this application could not be reversed.

DM.APPLICATION.INFO Field Description

TEMENOS T24 User Guide Page 19 of 55

Specifying Customer Types for Tracking

Track an Applications documents only from other Applications

Records of this application could not be reversed.

DOCUMENT.CLASS Field Description

Records of this application could not be reversed.

DOCUMENT.TYPE Field Description