Documente Academic
Documente Profesional
Documente Cultură
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
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.
Page 3 of 55
Document Management
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.
Page 4 of 55
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. 3. 4.
Status of a Document is a description of the position of a tracked document, specified either by User or T24 in document data files. 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. 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.
Page 5 of 55
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.
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.
CUST.DOCUMENT TRANS.DOCUMENT
While CUST.DOCUMENT stores Customer specific documents not tied to particular transactions, TRANS.DOCUMENT stores transaction specific documents.
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.
Page 6 of 55
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.
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.
Page 7 of 55
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.
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.
Page 8 of 55
Document Management
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.
Page 9 of 55
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.
o o
A CUSTOMER record is input and a Mandatory Required Document is not already tracked or tracked with a STATUS of 2 (Not Received). 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.
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.
Page 10 of 55
Document Management
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.
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.
Page 11 of 55
Document Management
The table below shows the document tracking process when a CUSTOMER record is input. Document Tracking for Customer Input Mandatory Required Documents for CUSTOMER Type of Document Status of Document Message by T24 and response by User Confirmation Message and User response: YES Update by T24
Any Document
Create record in CUST. DOCUMENT with STATUS=1 (Received) Create record in CUST. DOCUMENT. with STATUS=2 (Not Received) No action
Confirmation Message and User response: CANCEL or NO Not Already Tracked in Live File. But CUST. DOCUMENT in INAU status created by an unauthorized input from a different Application. Already Tracked in CUST. DOCUMENT with STATUS=2 (Not Received) Confirmation Message and User response: YES Confirmation Message and User response: CANCEL or NO Already Tracked in CUST.DOCUME NT with any Invalid STATUS other than 2 Override Message Error Message
Page 12 of 55
Document Management
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. 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. 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. T24 would display Override Messages for Contract specific Mandatory documents for the current application, already tracked with any Invalid STATUS other than 2 T24 would display Override Messages for Non-Contract specific Mandatory documents for the current application, with any Invalid STATUS.
o o
The table below shows the document tracking process when a record is input in an application other than CUSTOMER.
Page 13 of 55
Document Management
Confirmation Message and User response: YES Confirmation Message and User response: CANCEL or NO
Already Tracked in TRANS. DOCUMENT with any Invalid STATUS other than 2 Non-Contract Specific (E.g. General Loan Agreement) Not Already Tracked Already Tracked in CUST. DOCUMENT with any invalid STATUS including 2 Not Already Tracked in Live File. But CUST. DOCUMENT in INAU status created by an unauthorized input from a different Application. Customer level (CUSTOMER application) Any Document Not already tracked
Override Message
No action
Error Message OR Override Message based on the field CUST.DOC.O VERRIDE in DM.APPLICA TION.INFO Override Message
No action
Override Message
No action
Page 14 of 55
Document Management
Not Already Tracked in Live File. But CUST. DOCUMENT in INAU status created by an unauthorized input from a different Application. Related Application (E.g. ACCOUNT) Contract Specific (E.g. Account Opening form) Not already tracked
Error Message OR Override Message based on the field CUST.DOC.O VERRIDE in DM.APPLICA TION.INFO Override Message Override Message
No action
Override Message
Override Message
No action
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.
Page 15 of 55
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.
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.
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).
Page 16 of 55
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.
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).
Page 17 of 55
Document Management
Multi-Company
The parameter files:
which describe the Class, Type of Documents and Status Codes are Installation (INT) type files which could be shared by all Companies.
Page 18 of 55
Document Management
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.
CUST.DOC.OVERRIDE
Page 19 of 55
Document Management
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.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).
Page 20 of 55
Document Management
Description Version of the Document Type, for information purposes. Date from when the Document Type needs to be tracked. Date up to which the Document Type needs to be tracked. Frequency at which the Document Type needs to be reviewed by the Bank for its format, etc, and the Next Date of Review. Specifies whether a Signature would be required for Documents of this Type. Document Types, which are considered equivalent to this Document Type for processing purposes. 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. Period before expiration of the Documents of this type, when customers need to be advised (for information purposes only). Specifies whether a Document of this type needs to be obtained separately for each Contract (Transaction) from the Customer. Specifies the period up to which a Document of this type is valid from the date specified as 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. Specifies the Companies(s) in which this Document Type needs to be tracked.
XX.VALID.COMPANY
Tracking of a Document Type could be permanently stopped by specifying the field END.DATE.
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
Page 21 of 55
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.
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.
Page 22 of 55
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.
COMPARISON: DATA.FROM:
Page 23 of 55
Document Management
DATA.TO: CONDITION.OK:
Value of DECISN.TO in DOC.GEN.CONDITION Value returned should be null or 0 for False or any other value for True.
SCAN.ALL.GROUP
XX<DOC.GROUP XX-XX<DECISN.FIELD
XX-XX>ASC.CUS.FLD
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.
Page 24 of 55
Document Management
If no record exists for a Document Group in this application, then no documents would be determined as required for that group.
CHECK.CUST.LEVEL
XX-STOP.TXN.DAYS
XX>APPLN.CUS.FLD
Page 25 of 55
Document Management
Then it would track the application level documents (for the LD application) for Customer ID 1000 specified in the multi-value field DOCUMENT.TYPE.
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.
Page 26 of 55
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.
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).
Page 27 of 55
Document Management
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 Noncontract 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.
Page 28 of 55
Document Management
Description Specifies the Date on which Signature has been obtained on the Document. Specifies the expiry date of the document. Specifies the Sequence Number of a Document, to distinguish documents obtained on expiry of an earlier one. Specifies the date the record was last updated. When the document record is updated by T24, this field specifies the application from which T24 is updating it. When the document record is updated by T24, this field specifies the transaction reference number of the application, from which T24 is updating it. Used for T24 processing.
UPDATE.BY
Specifies Status of the Next Document. Specifies the remarks if any, on the status of the Next Document. Specifies the Date on which a Valid Next Document would become effective, for tracking purposes. Specifies the Date from which the specified status (NEXT.STATUS) applies to the Next Document. Specifies the Date on which Signature has been obtained on the Next Document. Specifies the expiry date of the Next Document.
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.
1. 2.
Expiry Date calculated as per the validity period (Field: VALID.PEIOD) specified for the STATUS in DOCUMENT.STATUS and Expiry Date calculated as per the validity period (Field: VALID.PEIOD) specified for the document type in DOCUMENT.TYPE.
Page 29 of 55
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).
Page 30 of 55
Document Management
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.
Page 31 of 55
Document Management
6 (New Document sent for signature A user defined Invalid Status) Chaser to be sent on 20.02.2002
Case 1: There is no response from the Customer and the next document continues with an Invalid Status.
Page 32 of 55
Document Management
10.02.2002
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.
Page 33 of 55
Document Management
Cleared by T24 Cleared by T24 Cleared by T24 Cleared by T24 Cleared by T24 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.
Page 34 of 55
Document Management
Cleared by User Cleared by User Cleared by User Cleared by User Cleared by User 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.
Page 35 of 55
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.
20.03.2002 21.03.1999 2
21.03.2002 (Make effective the Next Document from this Date) (updated by User) 16.02.2002 (Date of receipt by Bank) (updated by User) 15.02.2002 (Date of signature on next document) (updated by User) 14.02.2005 (Calculated by T24 and accepted by User)
Page 36 of 55
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.
Cleared by T24 Cleared by T24 Cleared by T24 Cleared by T24 Cleared by T24 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.
Page 37 of 55
Document Management
REFERENCE.NO BEGIN.DATE STATUS STATUS.DATE XX.LL.STAT.DETAILS SIG.DATE END.DATE DOC.SEQUENCE LAST.UPD.DATE LAST.UPD.APPLN APPLN.TXN.REF
UPDATE.BY
Specifies Status of the Next Document. Specifies the remarks if any, on the status of the Next Document. Specifies the Date on which a Valid Next Document would become effective, for tracking purposes. Specifies the Date from which the specified status (NEXT.STATUS) applies to the Next Document. Specifies the Date on which Signature has been obtained on the Next Document. Specifies the expiry date of the Next Document.
Page 38 of 55
Document Management
DM.DOCUMENTS.TRACKED
This file stores T24 generated records with details of documents tracked for an authorized application record.
xx-DOCUMENT
2.
Page 39 of 55
Document Management
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?
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.
Page 40 of 55
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?
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.
Page 41 of 55
Document Management
User inputs record for LD Application in DM.APPLICATION.INFO and specifies Customer Types for whom documents need to be tracked in LD.
User inputs record for Related Application ACCOUNT in DM.APPLICATION.INFO and specifies Customer Types for whom documents need to be tracked in ACCOUNT.
Page 42 of 55
Document Management
!" Group 102 defined for Customers with SECTOR=4100 (Private Individuals). !" Group 101 defined as a default group for other Customers.
Page 43 of 55
Document Management
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
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.
Two Mandatory Documents IDCARD and DOB are required. Both the documents will be tracked from Related applications also (Field TXN.PROCESSING is YES)
Page 45 of 55
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).
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.
Page 46 of 55
Document Management
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.
Page 47 of 55
Document Management
Figure 26 - T24 Confirmation Message for document IDCARD after CUSTOMER Input
Page 48 of 55
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).
Page 49 of 55
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
Page 50 of 55
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.
Page 51 of 55
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.
Page 52 of 55
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 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.
Page 53 of 55
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
Page 54 of 55
Document Management
Page 55 of 55