Core Si RFP Volume II

Request for Proposal (RFP) for Selection of Core
System Integrator (CSI)

Volume II: Instructions to Bidders

DEPARTMENT OF POSTS
MINISTRY OF COMMUNICATIONS & IT
GOVERNMENT OF INDIA
21
st
April 2011

RFP for Core System Integrator Volume II

Reference No: 12-7/2010-PMU dated 21/4/2011 2 of 382
Table of Contents
Table of Contents .................................................................................................................................... 2
Table of Tables ........................................................................................................................................ 5
1. Disclaimer ........................................................................................................................................ 6
2. Introduction .................................................................................................................................... 7
2.1 Tender Notice ......................................................................................................................... 7
2.2 Bid Process Schedule .............................................................................................................. 9
2.2.1 Activities of the bidding process ..................................................................................... 9
2.2.2 Schedule for the bidding process .................................................................................... 9
2.3 Acronyms Used ..................................................................................................................... 10
3. General Instructions to Bidders .................................................................................................... 11
3.1 Methodology for Selection ................................................................................................... 11
3.2 Eligible Products and Services ............................................................................................... 11
3.3 Documents Establishing Products' Eligibility and Conformity to Bidding Documents ......... 12
3.4 OEM and Sub-contractors ..................................................................................................... 12
3.5 DoPs Right to Terminate the Process................................................................................... 13
3.6 Conflict of Interest ................................................................................................................ 13
3.7 One Bid per Bidder ................................................................................................................ 13
3.8 Field Visit by Bidders ............................................................................................................. 13
3.9 Source Code and Intellectual Property Rights ...................................................................... 13
3.10 Clarification of Bidding Documents ...................................................................................... 14
3.11 Pre Bid Conference ............................................................................................................... 15
3.12 Supplementary Information to RFP ...................................................................................... 15
3.13 Amendment of RFP ............................................................................................................... 15
3.14 Earnest Money Deposit ......................................................................................................... 16
3.15 Modification of Bids .............................................................................................................. 16
3.16 Period of Validity of Bids ....................................................................................................... 16
3.17 Deadline for Submission of Bids ........................................................................................... 17
3.18 Late Bids, Delayed Bids and Post Bid Offers ......................................................................... 17
3.19 Contacting Department of Posts ........................................................................................... 17
3.20 Lack of Information to Bidder ............................................................................................... 17
3.21 Acknowledgement of Understanding of Terms .................................................................... 17
3.22 Non-Conforming Bids ............................................................................................................ 17
3.23 Confidentiality ....................................................................................................................... 18
3.24 Right to Content of the Bids/Proposals ................................................................................ 18
3.25 Clarifications ......................................................................................................................... 18
3.26 Authenticity of the Information and Right for Verification .................................................. 19
3.27 Fraudulent and Corrupt Practice .......................................................................................... 19

3.28 Disqualification ..................................................................................................................... 19
3.28.1 Violation of the procurement process .......................................................................... 20
3.28.2 Non compliance to the conditions of the bidding process ........................................... 20
3.28.3 Non responsive content of the proposal ...................................................................... 20
3.28.4 Inability to respond in accordance with the bidding guidelines ................................... 21
3.28.5 Consequences of disqualification ................................................................................. 21
3.29 Right to Accept Any Bid and to Reject Any or All Bids .......................................................... 21
3.30 Right to Vary Quantity at Time of Award .............................................................................. 22
3.31 Additional Conditions ............................................................................................................ 22
3.31.1 Entire Request for Proposal .......................................................................................... 22
3.31.2 Entire proposal by the bidder ....................................................................................... 22
3.31.3 Mode of Communication .............................................................................................. 23
3.31.4 Right to Share and Evaluate .......................................................................................... 23
4. Preparation and Submission of Bids ............................................................................................. 24
4.1 Language of Bid ..................................................................................................................... 24
4.2 Cost of Preparation and Submission of bid ........................................................................... 24
4.3 Bid Currency .......................................................................................................................... 24
4.4 Signature ............................................................................................................................... 24
4.5 Submission and Receipt of Bids ............................................................................................ 24
4.6 Technical Bid ......................................................................................................................... 26
4.6.1 General Instructions ...................................................................................................... 26
4.6.2 Suggestions on draft contract ....................................................................................... 26
4.6.3 Documents constituting the Technical Bid ................................................................... 26
4.7 Financial Bid .......................................................................................................................... 28
4.7.1 General Instructions ...................................................................................................... 28
4.7.2 Bid Price ........................................................................................................................ 29
4.7.3 Correction of Errors....................................................................................................... 29
4.7.4 Fall Clause ..................................................................................................................... 30
4.7.5 Documents constituting the Financial Bid .................................................................... 30
5. Opening and Evaluation of bids .................................................................................................... 31
5.1 Verification of EMD ............................................................................................................... 31
5.2 Evaluation of Technical Bids ................................................................................................. 31
5.2.1 Overall Technical Evaluation parameters ..................................................................... 31
5.3 Evaluation of Financial Bids .................................................................................................. 47
5.3.1 Net Present Value ......................................................................................................... 47
5.3.2 QCBS method of selection of bidder shall be adopted by Department of Posts .......... 48
5.4 Other Evaluation Conditions ................................................................................................. 48
6. Award of Contract ......................................................................................................................... 49

6.1 Negotiations .......................................................................................................................... 49
6.2 Award of Contract ................................................................................................................. 49
6.3 Notification of Award ............................................................................................................ 49
6.4 Signing of Contract ................................................................................................................ 49
6.5 Failure to Agree with the Terms and Conditions of the RFP ................................................. 49
6.6 Performance Bank Guarantee .............................................................................................. 50
7. Annexure ....................................................................................................................................... 50
7.1 Profiles to be evaluated for the Assignment ........................................................................ 50
7.2 Technical Bid Formats ........................................................................................................... 56
7.2.1 TECH 1: Covering Letter ................................................................................................ 56
7.2.2 TECH 2: Details of Relevant Experience of the Bidder .................................................. 58
7.2.3 TECH 3: Compliance Statement Format for Technical Requirements .......................... 63
7.2.4 TECH 4: Compliance Statement Format for Functional Requirements ...................... 124
7.2.5 TECH 5: Product and Solution Integration .................................................................. 343
7.2.6 TECH 6: Technical Solution, Approach & Methodology .............................................. 343
7.2.7 TECH 7: Schedule of Requirements for Hardware Infrastructure and Software ........ 343
7.2.8 TECH 8: Team Composition and Task Assignments .................................................... 346
7.2.9 TECH 9: CV of Proposed Resources ............................................................................. 347
7.2.10 TECH 10: Staffing Schedule ......................................................................................... 348
7.2.11 TECH 11: Work Schedule ............................................................................................. 349
7.2.12 TECH 12: Suggestions on Draft Terms of Contract...................................................... 350
7.2.13 TECH 13: Declaration on Absence of Conflict of Interest ........................................... 351
7.2.14 TECH 14: Schedule of Subcontractors ......................................................................... 352
7.2.15 TECH 15: Authorization Letter from OEM ................................................................... 353
7.2.16 TECH 16: Power of Attorney for signing of Application ............................................. 355
7.2.17 TECH 17: Non-Malicious Code Certificate ................................................................... 357
7.2.18 TECH 18: Patent Rights Confirmation ......................................................................... 358
7.2.19 TECH 19: Undertaking on Sizing .................................................................................. 359
7.2.20 TECH 20: Declaration that the Bidder has not been blacklisted ................................. 360
7.3 Financial Bid Formats .......................................................................................................... 361
7.3.1 FIN 1: Covering Letter ................................................................................................. 361
7.3.2 FIN 2: Schedule of Requirements ................................................................................ 362
7.3.3 FIN 3: Undertaking on Fall Clause ............................................................................... 376
7.3.4 FIN 4: Undertaking on Pricing of Technical Bid Items ................................................. 377
7.4 Request for Clarifications Format ....................................................................................... 378
7.5 Bank Guarantee Format for Earnest Money Deposit ......................................................... 379
7.6 Performance Bank Guarantee Format ................................................................................ 381


Table of Tables
TABLE 1: BID PROCESS SCHEDULE .................................................................................................................. 9
TABLE 2: LIST OF ACRONYMS ....................................................................................................................... 10
TABLE 3: SUMMARY OF NUMBER OF TECHNOLOGY REQUIREMENTS .................................................................. 32
TABLE 4: FUNCTIONAL REQUIREMENTS SCORING MECHANISM FOR COTS BASED MODULES .................................. 34
TABLE 5: FUNCTIONAL REQUIREMENTS SCORING MECHANISM FOR CUSTOM DEVELOPED MODULES ....................... 34
TABLE 6: SUMMARY SCORING SHEET ............................................................................................................ 34
TABLE 7: TECHNICAL EVALUATION CRITERIA................................................................................................... 38
TABLE 8: SCORING FOR APPROACH & METHODOLOGY .................................................................................... 45
TABLE 9: SCORING FOR TEAM STRENGTH & QUALIFICATION ............................................................................. 45
TABLE 10: SCORING FOR OVERALL INTEGRATION PLAN .................................................................................... 46
TABLE 11: OVERALL SCORING METHODOLOGY ............................................................................................... 46
TABLE 12: PROFILES TO BE EVALUATED ......................................................................................................... 50
TABLE 13: FIN2.1 CONSOLIDATED PRICE SUMMARY INCLUSIVE OF TAXES ........................................................ 362


1. Disclaimer

The sole objective of this Request for Proposal (RFP) is to solicit Techno-Commercial offers from
Bidders who have been short listed based on their responses to the Expression of Interest (EOI) for
Core System Integrator (CSI) for IT Modernisation Project issued by DoP on October 29
th
, 2010.

This document includes statements, which reflect various assumptions and assessments arrived at by
the DoP in relation to the India Post 2012 Project. Such assumptions, assessments and statements do
not purport to contain all the information that each bidder may require. The assumptions,
assessments, statements and information contained in this RFP may not be complete, accurate,
adequate or correct. Each interested bidder should therefore, conduct its own investigations and
analysis and should check the accuracy, adequacy, correctness, reliability and completeness of the
assumptions, assessments, statements and information contained in this RFP and obtain
independent advice from appropriate sources.

Information provided in this RFP to the interested bidder(s) is on a wide range of matters, some of
which may depend upon interpretation of law. The information given is not intended to be an
exhaustive account of statutory requirements and should not be regarded as a complete or
authoritative statement of law. The DoP accepts no responsibility for the accuracy or otherwise for
any interpretation or opinion on law expressed herein.

The DoP, its employees and advisors make no representation or warranty and shall have no liability
to any person, including any interested bidder, under any law, statute, rules or regulations or tort,
principles of restitution or unjust enrichment or otherwise for any loss, damages, cost or expense
which may arise from or be incurred or suffered on account of anything contained in this RFP or
otherwise, including the accuracy, adequacy, correctness, completeness or reliability of the RFP and
any assessment, assumption, statement or information contained therein or deemed to form part of
this RFP or arising in any way with pre-qualification of the bidder for participation in the bidding
process.

The DoP also accepts no liability of any nature whether resulting from negligence or otherwise
howsoever caused arising from reliance of any bidder upon the statements contained in this RFP.

The DoP may, in its absolute discretion but without being under any obligation to do so, update,
amend or supplement the information, assessment or assumptions contained in this RFP.

The issue of this RFP does not imply that DoP is bound to appoint the selected bidder or
concessionaire, as the case may be, for the India Post 2012 Project and DoP reserves the right to
reject all or any of the bids without assigning any reasons whatsoever.

The bidder shall bear all its costs associated with or relating to the preparation and submission of its
bid including but not limited to preparation, copying, postage, delivery fees, expenses associated
with any demonstrations or presentations which may be required by DoP or any other costs incurred
in connection with or relating to its bid. All such costs and expenses will remain with the bidder and
DoP shall not be liable in any manner whatsoever for the same or for any other costs or other
expenses incurred by a bidder in preparation or submission of the bids, regardless of the conduct or
outcome of the bidding process.


2. Introduction
2.1 Tender Notice
1. Department of Posts (DoP) invites Techno-Commercial proposals only from the Bidders who
have been short listed based on their response to the Expression of Interest (EOI) for Core
System Integrator (CSI) for IT Modernisation Project issued by DoP on October 29th, 2010.
Further details on the scope of work and services expected from the bidder are provided in
Volume I of the RFP. Your company is now invited to submit your proposal as per the attached
RFP document.
2. A company will be selected under Quality-and Cost-Based Selection (QCBS) procedures
described in this RFP
3. The RFP includes the following documents:
a. Volume I: Functional, Technical and Operational Requirements
Volume I of this RFP contains details regarding solution and other requirements that the DoP
deems necessary to share with the potential Bidders. The information set out in this volume
includes Project Overview, Scope of Work, To-Be Process flows, Functional requirements,
Technical Requirements of the solution, desired Service Levels and Roll-out Plan for various
components of the proposed solution.
b. Volume II: Instruction to Bidders
Volume II of this RFP details out all that may be needed by the potential Bidders to
understand the bidding process. This includes the technical and financial forms required to
respond to this RFP as well as to understand the technical evaluation methodology as part of
this bidding process.
c. Volume III: Contractual and Legal Specifications
Volume III of this RFP explains the contractual terms that the DoP wishes to specify at this
stage and includes a draft of Master Services Agreement.
This Volume is Volume II
4. The purchased RFP document is not transferable
5. The bidders shall furnish an EMD of ` 14 crores (Rupees Fourteen crores only) in the form of a
Bank Guarantee issued by a Nationalized/Private Bank in favour of Department of Posts
payable at New Delhi as per the format provided in Section 7.5: Bank Guarantee Format for
Earnest Money Deposit. EMD in any other form shall not be entertained.
6. Bids (Technical and Financial), including EMD must be received by DoP at the address specified
below not later than the date and time mentioned in Section 2.2.2: Schedule for the bidding
process.
7. DoP will first verify the EMD, in the presence of bidders authorised representatives who choose
to attend, at the date and time mentioned in Section 2.2.2: Schedule for the bidding process.
8. The Contact Person for submission of queries/clarifications is:
Shri. Atul Srivastav

ADG (PMU), Room 422A
Dak Bhawan, Sansad Marg,
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122
Email: [email protected]

9. The Address and Addressee at which the bid is to be submitted is:
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122


2.2 Bid Process Schedule
2.2.1 Activities of the bidding process
The bidding process for this Request for Proposal will include the following steps:
1. Issue of RFP documents with all the formats, requirements, specifications, terms and conditions
etc.
2. Receipt of the queries and Requests for Clarifications (RFC) on the RFP document and
specifications from the bidders.
3. Pre-bid conference to clarify the queries from the short-listed bidders.
4. Circulation of the answers to queries and the clarifications, if any, on the RFP documents and the
specifications, to all the short-listed bidders.
5. Submission of the Technical and Financial proposals, including EMD, by the bidders.
6. Verification of the EMD by DoP.
7. Opening and evaluation of the Technical proposals of the qualified bidders.
8. Announcement of Technical evaluation result
9. Opening of the Financial bids submitted by the bidders qualified at the technical evaluation
stage
10. Finalisation of contract with bidder having highest score after technical and commercial
evaluation followed by award of contract
2.2.2 Schedule for the bidding process
The tentative schedule for the bidding process is given in the table below:
Table 1: Bid Process Schedule
# Information Details
1.
Release of Request For Proposal (RFP)
document to only shortlisted bidders
4 PM on 21
st
April, 2011
2.
Last Date for Submission of written queries
(Queries from only those shortlisted bidders
who have submitted signed NDA will be
admitted)
5 PM on 5
th
May, 2011
3.
Last date of obtaining RFP Document 3 PM on 11
th
May, 2011
4.
Pre Bid Conference 10 AM on 12
th
May, 2011
5.
Release of responses to written queries 20
th
May, 2011
6.
Last Date for Submission of bids 3 PM on 9
th
June 2011

# Information Details
7.
Place, Date and Time of opening the
Technical bids
New Delhi 110001
4pm on 9
th
June 2011

2.3 Acronyms Used
Table 2: List of Acronyms
Acronym Explanation
CD Compact Disc
COTS Commercial Off The Shelf
CSI Core System Integrator
CV Curriculum Vitae
EMD Earnest Money Deposit
ERP Enterprise Resource Planning
ICT Information & Communication Technology
IPR Intellectual Property Rights
LoI Letter of Intent
MoU Memorandum of Understanding
MSA Master Services Agreement
NPV Net Present Value
OEM Original Equipment Manufacturer
PMS Project Management Services
PSU Public Sector Unit
QCBS Quality and Cost Based Selection
RFP Request for Proposal
SDP Service Delivery Platform
VAT Value Added Tax


3. General Instructions to Bidders
3.1 Methodology for Selection
The bidding process for the Selection of Core System Integrator (CSI) consists of three stages of
bidding and bid evaluation
1. Stage 1: Verification of EMD
a. The EMD submitted by the bidders shall be verified as per the compliance to the EMD
format specified in Section 7.5. Only those bids, submitted with EMD in the appropriate
format specified will be considered valid and be taken to the Stage 2.
2. Stage 2: Technical Evaluation: The technical evaluation has been divided into two sub stages.
(i) Stage A: Only such bids that meet the following conditions shall be short listed for Stage
B:
a) Valid CMM SEI certification on the date of submission of the bid
b) Should not be blacklisted by central government institution or public sector units in
India
c) Bid accompanied with copies of valid service tax registration certificate, PAN card
and VAT/Sales Tax registration certificate
d) Meet all technology requirements as listed in TECH 3 (Section 7.2.3).
(ii) Stage B:
a) Technical Bid Evaluation: The Technical responses submitted by the bidders shall be
evaluated as per the Technical evaluation criteria specified in Section 5.2:
Evaluation of Technical Bids.
b) Technical Solution Presentation: The committee may invite each bidder to make a
presentation to DoP at a date, time and location determined by the DoP. The
purpose of such presentations would be to allow the bidders to present their
proposed solutions to the committee and the key points in their proposals.
c) Only such bids that have minimum qualifying marks of 75% in the Technical
response in Stage B shall be short listed for Stage 3.
3. Stage 3: Financial bid opening and selection of vendor based on QCBS approach: A company
will be selected under Quality-and Cost-Based Selection (QCBS) procedures described in the RFP.
3.2 Eligible Products and Services
1. For the purpose of these Bidding Documents, Core System Integrator Systems also called
simply the CSI Systems means any or all the products to be installed together with related
services to be provided by the selected Bidder under this Bid.
2. All products and services to be delivered under this bid shall be governed by ITC (HS)
Classification of Export and Import items issued by Ministry of Commerce, Government of India
as amended from time to time and as per the Exim policy of Government of India including
restrictions on eligible source countries, if any, at the time of supply.

3. All the imported products and services (if any) to be supplied under this bid must be eligible for
export to India under the existing regulations of the country(s) of origin for the proposed
project. Bidder shall be responsible for obtaining all the necessary export permits for the
respective products and services supplied.
3.3 Documents Establishing Products' Eligibility and Conformity to Bidding
Documents
1. Bidders shall furnish, as part of its bid, documents establishing the eligibility and conformity to
the bidding documents of all products and services, which the bidder proposes to supply.
2. The documentary evidence of the eligibility of the products and services shall consist of a
statement in the bid certifying that the proposed systems have their origin in eligible countries.
3. The documentary evidence of the bidder's qualifications and ability to perform if its bid is
accepted shall establish to the DoPs satisfaction:
a. that, in the case of a bidder offering to supply products under this bid that it did not
produce, the bidder has been duly authorised by the subcontracted producer to supply the
products in India and to act on behalf of the producer, corroborated by a completed
Manufacturers Authorisation Form as provided in the bidding documents; and
b. that, the bidder and any subcontractors have the financial, technical, and management
capabilities to support the Systems, and have a successful performance history.
4. For purpose of the commentary to be furnished pursuant to Section 3.3, Para III (a), the bidder
shall note that any references to brand names or model numbers, if any, designated by DoP in its
Technical Specifications, are intended to be descriptive only and not restrictive. The bidder may
substitute alternative brand/model names in its bid, provided that it demonstrates to DoPs
satisfaction that the substitutes ensure equivalence to those referred in the Technical
Specifications and approvals as specified.
3.4 OEM and Sub-contractors
The bidder may partner with other companies, who may be OEMs or sub-contractors, for the
purpose of bidding for this project. The following must be noted:
1. The bidder shall be the single point of contact between such partners and DoP and shall be
solely responsible for the discharge and administration of all the obligations for this project.
2. The bidder will have sole responsibility under the contract and will be the sole point of contact
for DoP.
3. The bidder shall clearly define the role of each partner in its Bid response with respect to
planning, design, supply of hardware and software, work execution, operation and maintenance
and clearly indicate their scope of work/responsibilities and professional relationship between
the partners, if any. This information is to be given as per format TECH 14 provided in the
annexure.

3.5 DoPs Right to Terminate the Process
1. DoP makes no commitments, explicit or implicit, that this process will result in a business
transaction with anyone
2. This RFP does not constitute an offer by DoP. The bidders participation in this process may
result in DoP selecting the bidder to engage in further discussions and negotiations towards
execution of a contract. The commencement of such negotiations does not, however, signify
a commitment by DoP to execute a contract or to continue negotiations
3.6 Conflict of Interest
1. Bidder shall furnish an affirmative statement as to the existence of, absence of, or potential for
conflict of interest on the part of the bidder due to prior, current, or proposed contracts,
engagements, or affiliations with DoP. Additionally, such disclosure shall address any and all
potential elements (time frame for service delivery, resource, financial or other) that would
adversely impact the ability of the bidder to complete the requirements as given in the RFP
2. The successful bidder shall not participate in any tender arising out of the work carried out
through this RFP
3.7 One Bid per Bidder
1. No bidder shall submit more than one bid against this RFP. An applicant applying individually
shall not be entitled to submit another application individually.
2. If a bidder submits more than one bid, all such bids shall be disqualified.
3.8 Field Visit by Bidders
1. If required as part of the bidding process, DoP will invite all registered bidders (as mentioned in
the Tender notice) to conduct field visits and obtain for itself on its own responsibility, all
information that may be necessary for preparing the bid document
2. To avoid disruption of the day to day operations of DoP during the field visit, DoP will schedule
the visits based on the requests by the potential bidders
3. Registered bidders need to notify DoP explicitly on the number of personnel (up to a maximum
of 3) designated for the field visit on their behalf. Only these personnel will be entertained for
field visit
4. The costs of visiting the site(s) shall be at bidder's own expense
3.9 Source Code and Intellectual Property Rights
1. The Intellectual Property Rights of the Application Software (except COTS) developed for DoP
shall be vested in DoP who shall have absolute right to use, license or sell the system without
any payment to or permission from the bidder.


2. The Intellectual Property Rights of any customisation or development done on the COTS
application package shall also be vested in DoP who shall have absolute right to use, license or
sell the system without any payment to or permission from the bidder.
3. The bidder shall relinquish to DoP the source code along with adequate detailed documents
(from the testing phase onwards) and the rights to the systems, programs and software
developed at DoPs expense, and all ownership right to the application software packages
procured for DoP. The source code with version control system should be submitted in DVD(s) to
DoP for application software or to be put in a joint ESCROW account.
Bidders should submit a declaration to this affect.
3.10 Clarification of Bidding Documents
1. A bidder requiring any clarification on the RFP document may notify DoP in writing by e-mail
followed by confirmatory letter (as per the format given inSection 7.4: Request for Clarifications
Format). Bidders shall send the queries in an excel format only. No requests for clarification
will be accepted by telephone. DoP shall respond in writing to any request for clarification of the
RFP document which it receives till the date mentioned in Section 2.2.2: Schedule for the
bidding process. Any questions submitted after that shall not be considered by DoP. In no event
will DoP be responsible for ensuring that bidders inquiries have been received by DoP.
2. DoP shall conduct a Pre bid conference for all bidders to clarify any queries that the bidder might
have regarding the RFP as per the date and time mentioned in Section 2.2.2: Schedule for the
bidding process.
3. Each bidder should not depute more than 2 people for the Pre bid conference and the
concerned people should carry their company identification card on the conference day.
Thereafter, written copies of DoPs response shall be sent to all primary contacts of the
registered bidders and will also be published on the DoP web site. The Pre bid conference shall
be held at the venue mentioned in Section 2.2.2: Schedule for the bidding process.
4. If a bidder discovers any significant ambiguity, error, conflict, discrepancy, omission, or other
deficiency in this RFP, the bidder should immediately notify DoP of such error and request
modification or clarification of the RFP document, which modification/clarification shall be at the
sole discretion of DoP.
5. DoP will not be responsible for any queries which any of the bidders claim to have sent and
which did not reach the designated email ids of DoP.
6. Only those queries sent by the primary contact person (as mentioned in the Tender notice) of
the short-listed bidder will be entertained. Queries sent by anybody else from the bidder
organisation or its associates will not be entertained.
7. Any queries/clarifications related to the RFP should be sent to the following Postal/ email
addresses:

New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

RFP for Selection of Core System Integrator should mandatorily be included in the subject line.
3.11 Pre Bid Conference
1. Pre bid conference: A Pre bid conference will be held as per schedule indicated in Section
2.2.2: Schedule for the bidding process. The date, time and venue of the conference will be
intimated to all short-listed bidders through e-mail.
2. Representatives of the short-listed bidders organisation may attend the pre-bid conference at
their own cost.
3. The short-listed bidders shall be communicated details related to the Bid Process though the
Primary contact person as submitted in the response to the EOI for the Selection of Core System
Integrator ONLY. In a scenario of change of this primary contact information, the bidder has to
communicate this change to DoP to avoid any non-receipt of bid process communication.
4. The purpose of the conference is to provide bidders with information regarding the RFP and the
proposed solution requirements, and to provide each bidder with an opportunity to seek
clarifications regarding any aspect of the RFP.
3.12 Supplementary Information to RFP
If DoP deems it appropriate to revise any part of this RFP or to issue additional data to clarify an
interpretation of the provisions of this RFP, it may issue supplements to this RFP. Such supplemental
information will be communicated to the primary contacts (as mentioned in the Tender notice) of all
the short-listed bidders by e-mail. Any such supplement shall be deemed to be incorporated by this
reference into this RFP.
3.13 Amendment of RFP
1. At any time prior to the last date of submission of bids, DoP may, for any reason, whether at its
own initiative or in response to a clarification requested by a prospective bidder, modify the RFP
document by an amendment.
2. The primary contacts of all the short-listed bidders will be notified of the amendment in writing
or by fax or by email or by publishing in the website of DoP and such amendment will be binding
on them.
3. In order to provide the prospective bidders reasonable time in which to take the amendment
into account in preparing the bids, DoP may, at its discretion, extend the last date of submission
of bids.

3.14 Earnest Money Deposit
1. The bidders shall furnish an EMD of ` 14 crores (Indian Rupees Fourteen crores only) as part of
their bid.
2. The EMD shall be in form of a Bank Guarantee issued by a Nationalized / Private Bank authorized
to do business with Government as per the format provided in Section 7.5: Bank Guarantee
Format for Earnest Money Deposit. EMD in any other form shall not be entertained.
3. Any bid not accompanied with the EMD shall be rejected by DoP as non-responsive.
4. The EMD shall be valid for a period of 45 days beyond the final validity period of the bid.
5. EMD of all unsuccessful bidders shall be returned within 30 days of conclusion of the bid
process.
6. EMD of the successful bidder shall be returned after receipt of Performance Security from it as
called for in the contract.
7. The EMD may be forfeited by DoP in the following cases:
a. If the bidder withdraws or amends its bid or impairs or derogates from the RFP in any
respect within the period of validity of the bids
b. In case the successful bidder fails to sign the Contract or fails to furnish the performance
security
3.15 Modification of Bids
1. The bidder may modify its bid after the bid submission, provided that written notice of the
modification is received by DoP prior to the deadline prescribed for submission of bids.
2. The bidders modification notice should be prepared, sealed, marked in a manner similar to the
original bid.
3. In a scenario of modification of the bid, the entire bid (including EMD, Technical and Financial
bids) need to be resubmitted again to DoP prior to the deadline prescribed for submission of
bids. In such case, the bid submitted earlier by the bidder shall not be considered by DoP for the
purpose of evaluation.
4. Modification of a bid after the deadline for submission of bids and before the expiration of
period of bid validity may result in the forfeiture of the Earnest Money Deposit.
3.16 Period of Validity of Bids
1. Bids shall remain valid for 180 days after the date of bid opening prescribed by DoP. DoP shall
reject a bid valid for a shorter period, as non-responsive.
2. In exceptional circumstances, DoP may solicit the bidders consent to an extension of the period
of validity. The request and the response thereto shall be made in writing (or by fax). The validity

of the EMD provided shall also be suitably extended. A bidder may refuse the request without
forfeiting its EMD. A bidder extending the validity will not be permitted to modify its bid.
3.17 Deadline for Submission of Bids
1. Bids (EMD, Technical bid and Financial bid) must be received by DoP at the address specified in
Section 2.1: Tender Notice not later than the date and time mentioned in Section 2.2.2:
Schedule for the bidding process. In the event of the specified date for the submission of bids
being declared a holiday for DoP, the bids will be received up to the appointed time on the next
working day.
2. In case DoP extends the deadline for submission of bids due to any reason, all rights and
obligations of DoP and bidders previously subject to the deadline will thereafter be subject to
the deadline as extended.
3.18 Late Bids, Delayed Bids and Post Bid Offers
Late bids (i.e. bids received after the specified time of opening), delayed bids (i.e. bids received
before the time of opening but after the due date and time of receipt of bids) and post bid offers
shall not be considered by DoP.
3.19 Contacting Department of Posts
1. No bidder shall contact DoP or its employees on any matter relating to its bid, from the time of
the bid opening to the time the Contract is awarded. If the bidder wishes to bring additional
information to the notice of DoP, it should do so in writing.
2. Any effort by a bidder to influence DoP in its decisions on bid evaluation, bid comparison or
contract award may result in rejection of the bidders bid.
3.20 Lack of Information to Bidder
The bidder shall be deemed to have carefully examined all RFP documents to its entire satisfaction.
Any lack of information shall not in any way relieve the bidder of its responsibility to fulfil its
obligation under the bid.
3.21 Acknowledgement of Understanding of Terms
1. By submitting a proposal, each bidder shall be deemed to acknowledge that it has carefully
read all sections of this RFP, including all forms, schedules and annexure hereto, and has fully
informed itself as to all existing conditions and limitations.
2. By submitting a proposal in response to this RFP, the bidder shall also be deemed to
acknowledge that the company is in agreement with the terms and conditions of the RFP and
the procedures for bidding and evaluation.
3.22 Non-Conforming Bids
A proposal may be construed as a non-conforming proposal and ineligible for consideration:

1. If it does not comply with the requirements and scope of this RFP.
2. If a proposal appears to be packaged presentations of promotional materials that do not
follow the format requested in this RFP or do not appear to address the particular requirements
of the proposed solution.
3.23 Confidentiality
1. Information relating to the examination, clarification, evaluation, and recommendation for the
short-listed bidders shall not be disclosed to any person who is not officially concerned with the
process or is not a retained professional advisor advising DoP in relation to or matters arising out
of, or concerning the bidding process in the entire procurement procedure.
2. DoP will treat all information, submitted as part of the proposal or bidding documents, in
confidence and will require all those who have access to such material to treat the same in
confidence. The bidder may not divulge any such information unless it is directed to do so by any
statutory entity that has the power under law to require its disclosure or is to enforce or assert
any right or privilege of the statutory entity and/ or the Authority or as may be required by law
or in connection with any legal process.
3.24 Right to Content of the Bids/Proposals
1. All the responses, proposals, accompanying documentation, correspondence by the bidders etc.,
once opened and the reports resulting out of the activities of the bidding process will become
the property of DoP and will not be returned to the bidders. The bid documents which are not
opened for any reasons as elaborated in other sections of this RFP will be returned to the
bidders.
2. DoP is not restricted in its rights to use or disclose any or all of the information contained in the
proposal, and can do so without compensation to the bidder. DoP shall not be bound by any
language in the proposal indicating the confidentiality of the proposal by the bidder or any other
restriction on its use or disclosure.
3. The information provided by the bidders in response to the RFP, including any clarifications
provided by the bidder against the queries from DoP during the bidding process, is deemed to be
valid till the end of the contract period, in case the contract is awarded to the bidder.
3.25 Clarifications
1. DoP may seek clarifications from the bidders on the content of their proposal during the
proposal evaluation process.
2. All correspondence for the clarifications will be sent to the authorised representative of the
bidders (as mentioned in the Tender notice).
3. The bidders are expected to provide the clarifications within the time frame to be specified by
DoP in their communication.

4. If the bidders fail to provide any clarifications against such requests within the timeframe
specified, DoP will make appropriate assumptions on those points and proceed with the
evaluation.
3.26 Authenticity of the Information and Right for Verification
1. In case it is found during the evaluation of the bids or at any time before signing of the contract
or after its execution and during the period of project execution resulting out of the contract
thereof, that the bidder has/had made material misrepresentation or has given any materially
incorrect or false information, the bidder shall be disqualified forthwith, if not yet awarded the
contract either by issue of the letter of intent or entering into a contract.
2. And If the bidder has already been issued the Letter of Intent (LoI) or has entered into a contract
to execute the project as the case may be, the same shall, notwithstanding anything to the
contrary contained therein or in this RFP, be liable to be terminated, by a communication in
writing by DoP to the bidder, without DoP being liable in any manner whatsoever to the bidder
without prejudice to any other right or remedy which DoP may have under this RFP, the bidding
documents, the Contract to execute the project or under applicable law.
3. DoP reserves the right to verify all statements, information and documents submitted by the
Applicant in response to the RFP. Any such verification or lack of such verification by DoP shall
not relieve the bidder of its obligations or liabilities hereunder nor will it affect any rights of DoP
thereafter.
3.27 Fraudulent and Corrupt Practice
1. DoP will reject a proposal for award if it determines that the bidder recommended for award has
engaged in corrupt, fraudulent or coercive practices in competing for, or in executing, the
project(s).
2. Fraudulent practice means a misrepresentation of facts in order to influence a procurement
process or the execution of the project and includes collusive practice among bidders (prior to or
after bid submission) designed to establish bid prices at artificial non-competitive levels and to
deprive DoP of the benefits of free and open competition.
3. Corrupt Practice means the offering, giving, receiving or soliciting of anything of value,
pressurising to influence the action of a public official in the process of project execution
4. Coercive Practice means harming or threatening to harm, directly or indirectly, persons or
their property to influence their participation in a procurement process, or affect the execution
of a contract.
3.28 Disqualification
DoP may at its sole discretion and at any time during the evaluation of bid, disqualify any bidder, in
the following cases but not limited to:

3.28.1 Violation of the procurement process
1. Financial proposal (in soft copy or hard copy) is enclosed in the same envelope as Technical
proposal.
2. The price information, the pricing policy or pricing mechanisms or any document indicative of
the commercial aspects of the proposal are either fully or partially enclosed or are part of the
Technical Proposal.
3. Bidders may specifically note that while processing the bid documents, if it comes to DoPs
knowledge expressly or implied, that some bidders may have compounded in any manner
whatsoever or otherwise joined to form a cartel resulting in delay / holding up the processing of
bid then the bidders so involved are liable to be disqualified for this contract as well as for a
further period of two years from participation in any of the bids floated by DoP. It is also clarified
that if need arises DoP would go in for appointment of outside party(s) to undertake the work
under the captioned bid.
4. In case any one party submits multiple bids or if common interests are found in two or more
bidders, the bidders are likely to be disqualified, unless additional bids/bidders are withdrawn
upon notice immediately.
3.28.2 Non compliance to the conditions of the bidding process
1. The bid documents are not signed as per guidelines of the RFP
2. The required EMD has not been provided or the conditions of the EMD have been modified
3. The bid validity period is shorter than the required period
4. The bid is not submitted in accordance with this document
5. During validity of the bid, or its extended period, if any, the bidder increases its quoted prices
6. The bidder qualifies the bid with his own conditions
7. Bid is received in incomplete form
8. Bid is received after due date and time
9. Bid is not accompanied by all requisite documents
3.28.3 Non responsive content of the proposal
1. Information submitted in Technical offer is found to be misrepresented, incorrect or false,
accidentally, unwittingly or otherwise, at any time during the processing of the contract (no
matter at what stage) or during the tenure of the contract including the extension period, if any.
2. The deliverables as given in the Technical solution should be in consonance with the Financial
proposal. Any deviations in the final deliverables between Technical and Financial proposals shall
make the bid as being unresponsive and may lead to disqualification of the bid.

3.28.4 Inability to respond in accordance with the bidding guidelines
1. The successful bidder, invited to sign the contract qualifies the letter of acceptance of the
contract with its conditions.
2. The bidder is expected to submit a statement agreeing to deposit the source code (including all
necessary documentation), for the solution proposed under the project, in an escrow account
and Intellectual Property Rights (IPR) for all the software products supplied/ developed/
customised as part of the project (including client application developed for rural ICT). DoP shall
own and have the right in perpetuity to use all newly created IPR which have been developed
solely during the execution of the project including but not limited to source code, object code,
compilers, library files, executables, records, reports, designs, application configurations, data
and written material, products, specifications, reports, drawings and other documents which
have been newly created and developed by the SI solely during the project. The above
statement has to be submitted along with the Technical proposal. Non-receipt of such a
statement shall make the Bid as being unresponsive and shall lead to disqualification of the Bid.
3. Bidder fails to deposit the Performance Bank Guarantee or fails to enter into a contract within
15 days of the date of notice of award of contract or within such extended period, as may be
specified by DoP.
3.28.5 Consequences of disqualification
1. If the proposal or the bid of any bidder is disqualified at any stage for any reason, the bid of the
particular bidder will not be processed further and the same will be communicated to the bidder
through email/fax.
2. No further correspondence by the bidder with DoP on the bids of the particular bidder will be
entertained by DoP.
3. If the documents submitted as a part of the proposal or the bids are already opened they will
not be returned to the bidder.
4. If any of the documents or the bid covers of the bidder, who has been disqualified, are not
opened at the time of disqualification, they will be returned to the address written on the bid
covers.
5. The EMD submitted by the bidder as a part of their bid will be returned to the authorised person
of the bidder organisation 15 days after submission of a written request for the return of EMD
duly signed by the authorised person
3.29 Right to Accept Any Bid and to Reject Any or All Bids
1. DoP reserves the right to accept or reject any or all bids without assigning any reasons. Any bid
not containing sufficient information, in view of DoP, to permit a thorough analysis, may be
rejected.
2. DoP reserves the right to verify the validity of bid information, and to reject any bid where the
contents appear to be incorrect, inaccurate or inappropriate in its assessment.

3. DoP shall have the right to determine in its own best judgment, the bidders who will qualify for
the short list, if any, and thereafter, the final selected firm that shall undertake the work.
4. Further, DoP shall have the right to cancel the RFP process at any time prior to award of the
contract, without thereby incurring any liability to the affected bidder(s).
3.30 Right to Vary Quantity at Time of Award
1. DoP reserves the right to increase, decrease or not purchase/ procure all together the
requirements of products, licences, services and locations originally specified in the specification
without any change in Bid rate or other terms and conditions. However the variation in
products, licence and services shall not be more than 15% of the contract value. The variation in
the number of locations shall not be lower than or greater than 25% of the total locations
specified in the Volume I of the RFP.
2. DoP reserves the right to place order for supply of the additional equipment during
implementation of the project and/or within twelve months from date of Acceptance of the
Systems on the same price list.
3. Go Live is the date when the roll out in the pilot branches in completed and sign off obtained
from DoP
3.31 Additional Conditions
3.31.1 Entire Request for Proposal
The following constitute the entire Request for Proposal by DoP:
1. The three volumes of the RFP supplied by DoP
2. The additional conditions if any, supplied by DoP on or before the last date for the submission of
the responses by the bidder
3. The clarifications provided by DoP during the pre-bid phase or before the last date for the
submission of the responses by the bidder
4. Minutes of the meeting of pre-bid meeting circulated to the bidders by DoP
5. Any official communication through email/fax/post by DoP sent to all the bidders during the
bidding period or before the last date for submission of the response by the bidder
3.31.2 Entire proposal by the bidder
1. The response by the bidder submitted in the form of CDs and printed materials
2. The presentation material submitted by the bidder during the Technical Presentation and
Demonstration of solutions
3. The written clarifications provided by the bidder as a part of the proposal against any
queries/requests by DoP

4. Minutes of the meeting of the Pre-bid meeting
3.31.3 Mode of Communication
1. No oral communication by either party will be recognised as the official commitment or
communication. The preferable modes of communication by either party will be email/ fax/
post. Any oral communication should follow a formal procedure of communication in writing.
2. Any communication sent through fax or by post by either party should be duly signed by the
respective authorised persons and addressed to the authorised person of the other party.
3. Any communication sent through email by either party should be through the email id of the
respective authorised persons.
3.31.4 Right to Share and Evaluate
1. DoP has the right to share the response of the proposal submitted by the bidders in the form of
CDs and printed materials with technical experts, designated agencies, consultants etc for the
purpose of evaluation
2. The Technical and Financial Proposals submitted by the bidders as response to this RFP will be
evaluated by a Committee of Officers appointed by DoP or representative(s) or expert(s)
designated by DoP


4. Preparation and Submission of Bids
4.1 Language of Bid
The bid prepared by the bidder, as well as all correspondence and documents relating to the bid
exchanged by the bidder and DoP shall be written in English language.
4.2 Cost of Preparation and Submission of bid
The bidder shall bear all costs associated with the preparation and submission of the bid, and DoP
will in no case be responsible or liable for those costs, regardless of the conduct or outcome of the
bidding process.
4.3 Bid Currency
All prices should be quoted only in Indian Rupee (`). Bids submitted in any other currency shall be
summarily rejected.
4.4 Signature
1. The covering letters must be signed with the bidders name and by a representative of the
bidder, who is authorised to commit the bidder to contractual obligations. All obligations
committed by such signatories are liable to be fulfilled by the bidders who would be selected to
carry out the project as per the terms of this RFP.
2. All the commitments, obligations and responses (all the pages) against this RFP must be signed
by the representative of the bidders and are enforceable through contracts which may be signed
at the end of the bidding process.
4.5 Submission and Receipt of Bids
1. DoP will not accept delivery of proposal in any manner other than that specified in this volume.
Proposal delivered in any other manner shall be treated as defective, invalid and rejected.
2. The original proposal (Technical and Financial proposals) shall contain no interlineations or
overwriting, except as necessary to correct errors made by the bidders themselves. The person
who signed the proposal must initial such corrections. Submission letters for the Technical and
Financial Proposals should respectively be as per the format of Form TECH 1: Covering Letter
and Form FIN 1: Covering Letter given in Section 7.2.1 and Section 7.3.1 respectively.
3. An authorised representative of the bidder shall initial all pages of the original Technical and
Financial proposals. The authorisation shall be in the form of a written Power of Attorney
accompanying the proposal (refer TECH 16 in the Annexure) or in any other form demonstrating
that the representative has been dully authorised to sign. The signed Technical and Financial
proposals shall be marked ORIGINAL.
4. The bidder must submit the following:
a. EMD in the format specified in Section 7.5

b. Original, 2 hard copies and 1 soft copy (on a non-rewritable CD) of the Technical proposal
(i) In the soft copy, Form TECH 3: Compliance Statement Format for Technical
Requirements and Form TECH 4: Compliance Statement Format for Functional
Requirements should be submitted in the excel format as provided to the bidder
c. Only the original of the Financial proposal
5. The EMD shall be placed in a sealed envelope clearly marked EMD
6. Copies of the Technical Proposal shall be marked COPY
7. All required copies of the Technical Proposal are to be made from the original. If there are
discrepancies between the original and the copies of the Technical Proposal, the original
governs. If there are discrepancies between the hard copies and the soft copy of the Technical
Proposal, the hard copy governs.
8. The original and all copies of the Technical Proposal shall be placed in a sealed envelope clearly
marked TECHNICAL PROPOSAL
9. The original Financial Proposal shall be placed in a sealed envelope clearly marked FINANCIAL
PROPOSAL
10. The three envelopes containing the (a) EMD (b) Technical Proposals and (c) Financial Proposals
respectively shall be placed into an outer envelope and sealed. This outer envelope shall bear
the submission address, reference number be clearly marked NOT TO BE OPENED BEFORE
*Insert the time and date of the opening+.
11. All the envelopes should have the names and address of the bidders clearly written over them.
DoP will return the envelopes to these addresses, if the envelopes are not opened for any
reason and are liable to be returned to the bidders in unopened form.
12. The outer and inner envelopes mentioned above shall indicate the name and address at which
the bid is to be submitted. Failure to mention the address on the outside of the envelope could
cause a bid to be misdirected or to be received at the required destination after the deadline.
13. DoP shall not be responsible for misplacement, losing or premature opening if the outer
envelope is not sealed and/or marked as stipulated. This circumstance may be case for proposal
rejection. If the Financial proposal is not submitted in a separate sealed envelope duly marked as
indicated above, this will constitute grounds for declaring the proposal non-responsive.
14. The proposals must be sent to the address indicated in Section 2.1: Tender Notice and
received by DoP no later than the time and the date indicated in Section 2.2.2: Schedule for the
bidding process, or any extension to this date. Any proposal received by DoP after the deadline
for submission shall be rejected and returned unopened.


4.6 Technical Bid
4.6.1 General Instructions
1. The Technical proposal should contain a detailed description of how the bidder will provide the
required solution outlined in this RFP. It should articulate in detail, as to how the bidders
Technical Solution meets the requirements specified in Volume I of the RFP.
2. The bidder is expected to respond to the requirements completely and with enough details and
focus on demonstrating bidders suitability to meet the functional and non functional
requirements of the solution outlined in this RFP.
3. The bidder is expected to respond using the specified formats for the response, wherever
applicable. Failure to use the specified formats may result in disqualification of the proposal.
4. The Technical Proposals must be direct, concise, and complete. Any information that is not
directly relevant to this RFP should not be included in the proposal. DoP shall evaluate bidders
proposal based upon its clarity and the directness of its response to the requirements of the
project as outlined in this RFP.
5. The Technical bid must not contain any pricing information, the pricing policy or pricing
mechanisms or any document indicative of the commercial aspects of the proposal or any other
commercial information not required for technical evaluation, either fully or partially.
4.6.2 Suggestions on draft contract
1. A draft contract including the standard terms and all the other terms specific to the
implementation of the solution as part of the RFP scope is included as part of Volume III of this
RFP. It is expected that the bidder will be able to execute this contract without any
modifications, in case they are selected for doing so.
2. However, the bidder is requested to indicate as per the format given in Form TECH 12:
Suggestions on Draft Terms of Contract, the changes the bidder desires to have and the reason
for that. This is only a solicitation of suggestions for change.
3. It is neither guaranteed that these requests for changes will be accepted in the final contract nor
this process should be construed as any commitment from DoP to consider those suggestions.
4. The bidder should not suggest any change that has financial or commercial implications during
the execution of the contract and is against the basic spirit of procuring the products and
services for implementation of the overall solution as part of the scope.
4.6.3 Documents constituting the Technical Bid
The Technical bid shall comprise the following as detailed in Section 7.3: Technical bid formats:
1. TECH 1: Covering Letter
2. TECH 2: Details of relevant experience of bidder

3. TECH 3: Compliance Statement Format for Technical Requirements
4. TECH 4: Compliance Statement Format for Functional Requirements
5. TECH 5: Product & Solution Integration

6. TECH 6: Technical Solution, Approach & Methodology
a. This form should explain in detail the technical solution offered by the bidder including the
technical approach, design of the solution offered, etc.
7. TECH 7: Schedule of Requirements for Hardware Infrastructure and Software
8. TECH 8: Team Composition and Task Assignments
a. This form should contain the list of the proposed Professional staff team to be engaged in
this assignment by area of expertise, the position that would be assigned to each staff team
member, and their tasks
9. TECH 9: CV of Proposed Resources
a. This form should detail out the CVs of the Professional staff signed by the staff themselves or
by the authorised representative of the Professional Staff
10. TECH 10: Staffing Schedule
a. This form should detail out the estimates of the staff input needed to carry out the
assignment. The staff-months input should be indicated separately in the format.
11. TECH 11: Work Schedule
a. This form will show in the form of a bar chart, the timing proposed for each activity and
milestones
12. TECH 12: Suggestions on Draft Terms of Contract
a. Suggestions, if any, on the Draft Terms of Contract as defined in Volume III of the RFP should
be mentioned in this form. DoP reserves its right to treat the suggestions in any manner that
DoP deems suitable for the bidding process
13. TECH 13: Declaration on absence of conflict of interest
14. TECH 14: Schedule of Sub Contractors
a. This form should list the Sub contractors employed, if any, along with the specific
responsibility proposed to be sub contracted to them. It should also contain description of the
projects similar to the responsibility to be executed by the sub contractor.
15. TECH 15: Authorisation Letter from the OEM
a. Refer Section 3.4.
16. TECH 16: Power of Attorney for signing of application
a. Refer Section 3.4.
17. TECH 17: Non-Malicious Code Certificate
18. TECH 18: Patent Rights Confirmation

19. TECH 19: Undertaking on Sizing
20. TECH 20: Declaration that the Bidder has not been blacklisted
21. Valid tax registration documents (Service Tax, VAT etc.)
22. Valid CMM SEI certification for the locations which are proposed for the delivery of this project
23. Self Declaration by Authorised Signatory certifying that the proposed products have their origin
in eligible countries
24. Self Declaration by Authorised Signatory agreeing to relinquish source code (including all
necessary documentation) and Intellectual Property Rights (IPR) of the Application Software
developed for DoP
4.7 Financial Bid
4.7.1 General Instructions
1. Bidders shall furnish the required information on their Financial bid in the enclosed formats only.
Any deviations in format may make the bid liable for rejection.
2. The bidder is expected to price for all the items and components of the solution required to
meet the specifications of DoP as mentioned in RFP Volume I.
3. If any of the items or components listed in the Technical bids is not covered in the Financial bid,
it is assumed that the price for the same is subsumed or included in the price of other
components or is part of the overall Financial proposal.
4. Prices shall be quoted entirely in Indian Rupees. (% values are not allowed). No clauses for price
fluctuations due to fluctuation of the Indian currency against any of foreign currency will be
accepted during the period of the contract.
5. It is mandatory to provide break-up of all Taxes, Duties and Levies wherever applicable and/or
payable.
6. The bidder shall give the total composite price inclusive of all levies and taxes, i.e. customs duty,
sales tax/VAT, service tax and excise, packing, forwarding, freight and insurance and support to
DoP up to the installation site but excluding Octroi / Entry tax, which will be paid extra as per
actuals, wherever applicable. Any increase in rates of taxes will be to the account of the bidder.
The basic unit price and all other components of the price need to be individually indicated.
Prices of incidental services should also be quoted.
7. DoP reserves the right to ask the bidder to submit proof of payment against any of the taxes,
duties, levies indicated.
8. The bidder needs to account for all Out of Pocket expenses due to Boarding, Lodging and other
related items.

9. It will be the responsibility of the bidder to obtain import license / custom clearance, wherever
required, on behalf of DoP. DoP shall provide assistance and undertaking wherever required as
per the law of land.
10. Bidders should provide all prices, quantities as per the prescribed format. Bidder should not
leave any field blank. In case the field is not applicable, 0 (Zero) must be indicated in all such
fields.
11. DoP has the option to pick and choose the solution components and change the scale of the
solution at the time of buying the solution components from the successful bidder.
12. The bidder shall indicate the unit prices and the total bid prices of the various components of the
Core System integration solution as per the formats given in Section 7.3: Financial Bid Formats.
13. The prices quoted by the bidder and accepted by DoP shall hold good till the completion of the
contract, and no additional claims will be admissible on account of any price variation or
fluctuation in the market rates, except where mutually agreed.
14. Discount, if any, offered by the bidders shall not be considered unless specifically indicated in
the price schedule. Conditional discounts shall not be considered for evaluation of bids.
15. The solutions proposed as part of the bid shall be evaluated and decided on the basis of all
inclusive price offered by the bidders.
4.7.2 Bid Price
1. In case any of the proposed solution or its components are quoted as a combo option/ price
then the same needs to be indicated.
2. The price for any software licenses required for the purpose of the proposed solution should be
for enterprise wide licenses.
3. The price should be quoted for the latest version of the application software for the proposed
solution.
4. Price bid shall be made in separate tables for each solution offered.
5. The bidder is expected to price all the items and services proposed in the Technical bid. DoP may
seek clarifications from the bidder on the Technical proposal. Any of the clarification by the
bidder on the technical proposal should not have any commercial implications. The Financial
proposal submitted by the bidder is inclusive of all the items in the technical proposal and is
assumed to incorporate all the clarification provided by the bidder on the technical proposal
during the evaluation of the technical offer. The bidder is requested to undertake this
declaration as per the format given in Form FIN 4: Undertaking on Pricing of Technical Bid
Items
4.7.3 Correction of Errors
1. Bidders are advised to exercise adequate care in quoting the prices. No excuse for corrections in
the quoted price shall be entertained after the proposals are opened. All corrections, if any,

should be initialled by the person signing the proposal form before submission, failing which the
figures for such items may not be considered
2. Arithmetic errors in proposals shall be corrected as follows:
a. If, in the price structure, there is discrepancy between the unit price and the total price
(which is obtained by multiplying the unit price by the quantity), the unit price shall prevail
and the total price corrected accordingly, unless in the opinion of DoP, there is an obvious
misplacement of the decimal point in the unit price, in which case the total price as quoted
shall govern and the unit price corrected accordingly
b. If there is an error in a total corresponding to the addition or subtraction of subtotals, the
subtotals shall prevail and the total shall be corrected; and
c. If there is a discrepancy between words and figures, the amount in words shall prevail,
unless the amount expressed in words is related to an arithmetic error, in which case the
amount in figures shall prevail subject to (a) and (b) above
4.7.4 Fall Clause
1. If the solution or any parts of that in any of its forms being offered by the bidder has been
supplied / contracted with any Ministry/Department of the Government of India or any Public
Section Organisation in the last 12 months, the bidder is required to give a written undertaking
that the company has not supplied/is not supplying the similar systems or subsystems (to the
extent of line items mentioned in the price bid forms FIN 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8) at a
price lower than that offered in the present bid to any other Ministry/Department of the
Government of India or Public Sector organisation and if the similar system has been supplied at
a lower price, then the details regarding the price, time of supply and quantities be included as
part of the financial offer.
2. In case of non disclosure, if it is found at any stage that the similar system or sub-system was
supplied by the bidder to any other Ministry/Department of the Government of India at a lower
price, then that very price, will be applicable to the present case and, with due allowance for
elapsed time, the difference in the price would be refunded to DoP, if the contract has already
been concluded
3. The bidder is requested to use Form FIN 3: Undertaking on Fall Clause for the undertaking on
Fall Clause.
4. The Fall Clause is applicable to all the separately priced items individually, including the prices
for the third party solutions / components
4.7.5 Documents constituting the Financial Bid
The Financial bid shall comprise the following as detailed in Section 7.4: Financial bid formats:
1. FIN 1: Covering Letter
2. FIN 2: Schedule of Requirements
3. FIN 3: Undertaking on Fall Clause
4. FIN 4: Undertaking on Pricing of Technical Bid Items


5. Opening and Evaluation of bids
5.1 Verification of EMD
1. DoP will first open only the envelope containing the EMD, in the presence of bidders
authorised representatives who choose to attend, at the date and time mentioned in Section
2.2.2: Schedule for the bidding process. The authorised representatives, who intend to attend
the bid opening, are to bring with them letters of authority from the corresponding bidders.
The bidders authorised representatives who are present during bid opening shall sign an
attendance sheet evidencing their attendance. In the event of the specified date of bid opening
being declared a holiday for DoP, the bids shall be opened at the appointed time on the next
working day.
2. DoP shall verify that the EMD has been provided by the bidder in the format specified in Section
7.5. The bids not accompanied by the EMD will be summarily rejected without any further
evaluation.
5.2 Evaluation of Technical Bids
1. The Technical bids of only those bidders, who have submitted the EMD as per the specified
requirement, shall be opened.
2. The Technical bids would be evaluated by an Evaluation Committee on the basis of the Technical
evaluation criteria and sub criteria listed below.
3. While evaluating the Technical proposals, the Evaluation Committee shall have no access to the
Financial proposals until the technical evaluation is complete and the competent authority
accepts the recommendation.
4. When deemed necessary, the Evaluation Committee may seek clarifications on any aspect of the
Technical Bid from the bidder. However, that would not entitle the bidder to change or cause
any change in the substance of the bid submitted or price quoted.
5. Proposals will be reviewed to assess compliance with the requirements set out in this RFP.
Proposals that do not fully comply with the minimum requirements will be rejected without
further consideration.
6. All compliant Technical bids shall be given a Technical Bid Evaluation score (T). Only those bids
that have T>450 and have minimum qualification under each head as described in section
5.2.1.8, shall be short listed for the Financial bid opening.
5.2.1 Overall Technical Evaluation parameters
Implementation for the Core System Integrator involves various components as mentioned in
Volume I of this RFP. Hence the proposal submitted by the bidder shall be evaluated on technical
grounds covering various components of the projects as follows:
Stage A:
a) Valid CMM SEI certification on the date of submission of the bid

b) Should not be blacklisted by central government institution or public sector units in India
c) Bid accompanied with copies of valid service tax registration certificate, PAN card and VAT/Sales
Tax registration certificate
d) Meet all technology requirements as listed in TECH 3 (Section 7.2.3).

Only those bidders who are qualified in Stage A will be considered for Stage B Evaluation.
Stage B:
1. Solution Proposed
a. Functional requirements
b. Product and Solution Integration
2. Relevant experience
3. Technology Solution presentation
4. Team strength and qualification
5. Approach and Methodology
STAGE A
5.2.1.1 Methodology for Technology Requirements
The technology requirements cover the hardware, technical solution requirements (including
database), security components that are to be supplied as a part of the solution.
1. Bidder should clearly specify the detailed configuration and specifications of the hardware
required at various levels of performance and supply a detailed unpriced Bill of Materials (BoM)
in the technical proposal with the part numbers for the hardware based on the technical
requirements.
2. The bidder should clearly specify the detailed solution architecture.
3. The hardware should be scalable to support the numbers as specified in Volume 1 of this RFP.
4. The application software that is being provided as a part of the solution offering is expected to
comply with the requirements as specified in TECH 3 (Section 7.2.3)
5. The technology requirements mentioned in TECH 3 of this RFP are all mandatory requirements.
The bidder is required to classify the requirements as under:
Compliant Feature - Available as a part of the standard solution offering
Non Compliant Feature Not available as a part of the standard solution offering.
Technology requirements are all mandatory requirements and are minimum in nature. Non
compliance with any of the requirements will make the prospective Bidder disqualified for the
next stage (i.e. Stage B).
Table 3: Summary of Number of Technology Requirements
Type of technology requirements Number of requirements
Technical solution (i.e. general technical solution requirements,
integration standards, other standards, technical solution
requirements)
292
Hardware requirements (i.e. servers, storage, SAN switches, FC-IP
126

Routers, Tape library, Disaster recovery)
Security specifications (i.e. overall solution requirements, security
architecture, application security requirements, database security
requirements, anti-phishing solution, risk-based authentication
solution)
220
Refer to TECH 3 (Section 7.2.3) for detailed Technical Solution Requirement specification,
Hardware specification and Security Specification and response sheet.
Only the bidder scoring 100% in the technology requirements shall be evaluated further compliance
with functional requirements, previous experience, team strength & qualification and approach &
methodology.
STAGE B
5.2.1.2 Scoring methodology for Functional Requirements
Functional requirements (refer TECH 4) for Mail Operations, Logistics Post, Philately, Finance &
Accounts, Human Resources, Customer Interaction Management and Call Centre have been
segregated into two categories as described below. The bidder has to provide all modules and
functional requirements specification as a part of the contract.
Based on the business requirement, each functional requirement under Mail Operations, Logistics
Post, Philately, Finance & Accounts, Human Resources, Customer Interaction Management and Call
Centre has been identified to be one of the following.
Essential Features (EF): Essential features are those functionalities which are to be met in their
entirety in the concerned solution
Desired Features (DF): They are those functionalities which are required by the concerned
function but not necessarily as priority
The bidder should provide a response to each of the functionalities listed in the functional
requirement specification in terms of whether the solution proposed by the bidder is compliant with
the functional requirement or not, if not then how the bidder plans to comply with the requirement
and in case of a Commercial off the shelf solution being proposed by the bidder whether the
functionality would be a standard feature or a customized feature.
The response of the bidder to the functional requirement and how the proposed solution meets
the same shall be evaluated.
The bidder will have to provide all the functional requirements which have been stipulated as
Essential Features before the start of Pilot of the project. Desired Features have to be provided
before the completion of Pilot of the project.
No response against a functional requirement shall be treated as non compliant functionality. If a
response has been filled in against a functional requirement under more than one head i.e.
Compliant, Compliant, but with a work around, Non Compliant, it shall be treated as non
compliant functionality.

In case of Standard features the bidder necessarily has to provide details of the Menu
/Parameterization /System option of the said feature in the application software in a separate
column.
Table 4: Functional Requirements Scoring Mechanism for COTS based modules
Available with the
functionality
Evaluation Score
Available
Available as standard functionality for Mail Operations,
Logistics Post, Philately, Finance & Accounts, Human
Resources, Customer Interaction Management and Call
Centre.
1.00
Evaluated as not being compliant or no explanation provided 0
Available with
customisation
Functionality can be met by customisation of product 0.75
Not Available Functionality Not Available 0
Table 5: Functional Requirements Scoring Mechanism for Custom developed modules
Compliance with
the functionality
Evaluation Score
Compliant
If COTS is proposed, available as standard functionality or in
case of a Custom developed solution, a detailed and valid
explanation is provided as to how the requirements would be
met
1.00
If COTS is proposed, functionality can be met by customisation
of product or in case of Custom developed solution if the
explanation provided seems valid but not sufficient
0.75
Non Compliant
Not complied through COTS or in case of Custom developed
solution, no valid explanation is provided.
0
The bidder will have to score at least 80% in the functional requirements specified for Mail
Operations, Logistics Post, Philately, Finance & Accounts, Human Resources, Customer Interaction
Management and Call Centre.
The summary scoring sheet for functional requirements is mentioned in the table below.
Table 6: Summary Scoring Sheet
# Particulars Total FRS
Maximum
Score
Passing
Score @
80%
Vendor
Score
1 Mail Operations
Mail Booking Engine 260 243 194

India Post Visibility
System
195 182 146

Delivery and Postman 118 117 94


Management System
Transportation
Management System
50 39 31

Mailer & Logistics
Appointment
Scheduling System
77 72 58

Sort Program System 18 15 12

Labour Scheduling
System
18 19 15

2 Logistics Post
Warehouse
Management System
80 69 55

Transportation
Management System
58 48 38

3 Philately
Philatelic Deposit
Account
21 21 17

Stock and supply of
Stamps
24 24 19

4
Finance &
Accounts
General Ledger 164 174 139

Requisition &
Procurement
55 56 45

Inventory Mgt. 37 39 31

Account Receivable 35 38 30

Account Payable 67 71 57

Asset Accounting 52 55 44

Payroll 55 58 46

Budgeting 20 20 16

Cash Management 17 17 14

Costing 17 17 14

Other Systems 57 60 48

Internal Audit 9 9 7

5
Human
Resources
Human Resources
Management System
97 96 77

Leave Management 63 62 50

Recruitment
Management
69 69 55

Performance
Management
27 27 22

Establishment Review 44 44 35

Training Administrator 59 59 47

Employee Portal 6 6 5


6
Customer
Interaction
Management
Point of Sale 55 55 44

Web Portal 128 128 102

Mobile Solution 10 10 8

7 Call Centre Call Centre 55 55 44

8
Common
Infrastructure
Solution
Email solution 58 58 46

Directory Services 20 20 16

Enterprise Monitoring
System (EMS)
79 79 63

Service Desk 97 97 78

Total 2371 2328 1862
Refer to TECH 4 (Section 7.2.4) for detailed functional requirement specification and response
sheet.
5.2.1.3 Scoring methodology for Product and Solution Integration
# Description Maximum Score
1.
Product Characteristics: If more than one product is proposed, all of them will be evaluated
against the following parameters and the product with the lowest score will be considered for
evaluation.
1.a
Supportability:
Instances of it being implemented in India (localization)
Support Availability in India
Skills availability in India to support the proposed solutions
Partners in India
20
1.b
Scalability: The solution should be scalable in capturing the anticipated
growth, both in terms of users as well as transactions
The proposed products should have been implemented anywhere
globally with over 10,000 transactional users in a single instance
20
1.c
Feature of the proposed product - such as tools for deployment,
integration, maintenance, implementation tools, etc.
10
2. Solution Integration
2.a
COTS solution components multi product suite / single product suite
including database and native vs. external integration architecture
25
2.b
Integration Architecture within various CSI solution components including
COTS and Custom developed components
10
2.c
Overall Integration Architecture of CSI solution components with other
solution components and Enterprise Service Bus Architecture
15
Total 100

The bidders may also be requested to make Technology solution presentation. This presentation
may include the following:
Structured Walkthrough of solutions
Elaborate on how far the proposed solution conforms to the architecture contained in the RFP
Demonstrate the softwares ability to meet the functional and technical requirements for
business operations as detailed in the RFP Volume 1
Highlight, at a macro level, the extent of customisation that may be necessary if the package is
chosen


5.2.1.4 Scoring Methodology for Relevant Experience
The bidder shall be rated on its previous experience as per the criteria mentioned below in the table
Table 7: Technical Evaluation Criteria
S. No Evaluation Criteria Weightage in Technical Score
Supporting documents to be
furnished
1
Relevant implementation experience of the Bidder
in Postal industry
24
a
The bidder should have experience of
implementing large scale IT projects, including
application development and deployment in the
Postal industry within the last 5 years. ONLY the
project with value of over `10 crores and
implementing at least 1 module from the following
as part of its scope will be considered:
Point of Sale (in Postal)
Track and Trace
Delivery Management (for Postal)
Note:
Bidders are advised to showcase maximum of 3
projects for this criteria (first 3 projects listed
will only be considered for evaluation)
Projects where more than 20% of the services
component was/has been subcontracted will
not be considered for scoring (Self-Declaration
to be given by the bidder)
Projects done in-house cannot be cited as
Scoring for each project will be done as follows,
based on status of the project as Completed
(supported by a Completion certificate from the
Client) or In Progress (supported by Work Order,
Contract, Client Letter):

Project
with 1
module
Project
with 2
modules
Project
with 3
modules
Completed 6.00 7.00 8.00
In progress 5.00 6.00 7.00
For In-progress projects, the project start date
should be at least six months prior to the date of
submission of the response.

The following documents for each
credentials showcased as part of the
response:
Copy of Contract
Work Order
Completion Certificate
Letter from the client with details
of the project

furnished
credentials
2
in end-to-end ERP Implementation of similar
scope
26
b.
a. The bidder should have experience of large
scale end-to-end ERP implementation in India
for the following modules within the last 5
years with minimum of 500 functional named
users, excluding self-service users:
Human Resources Management System
Finance & Accounts
Payroll
b. The bidder should have experience of large
scale end-to-end ERP implementation for the
following modules within the last 5 years with
minimum of 500 functional named users,
excluding self-service users:
Inventory Management
Procurement
Transportation and Logistics
Note:
Bidders must showcase experience credentials
for the same ERP package that is proposed for
the India Post 2012 project
projects for each criteria (first 3 projects listed
Scoring for each project will be done as follows
based on status of the project as Completed
(supported by a Completion certificate from the
Client) or In Progress (supported by Work Order,
Contract, Client Letter):
a. ERP implementation with HRMS, F&A and
Payroll modules (12 marks)
Completed 4.00
In progress 3.00
b. ERP implementation with Inventory
Management, Procurement and
Transportation and Logistics modules (12
marks)
Completed 4.00
In progress 3.00
* Additional 2 marks will be allocated if at least
one of the projects has been completed in a
Government agency/PSU in India.
response
Copy of Contract
Work Order
of the project

furnished
for each criteria will only be considered for
evaluation)
credentials

3
in System Integration projects of similar scale
25
c.
The bidder should have significant experience of
implementing System Integration projects including
supply, installation, commissioning of hardware
and software within the last 5 years in at least 6
states / UTs in India.
Note:
Project executed in India with the project value
of ` 50 crores, with minimum of ` 20 crores of
services component, will only be considered
under this criteria
Based on the number of States/UTs that a project
has been implemented and current status of the
project, marks will be allotted for each project as
follows:

No. of States/UTs
<6 6-8 9-12 13-20 >20
Completed - 5.5 6.0 6.5 7.0
In Progress - 5.0 5.5 6.0 6.5

one of the projects has been completed in a
North-East state
response
Copy of Contract
Work Order
of the project

furnished
credentials
4
Relevant experience of implementing Customer
Interaction channels
15
d.
a) The bidder should have experience of setting
up and managing multi-lingual call centre
operations with minimum capacity of 100 seats
within the last 5 years
b) The Bidder should have experience of
implementing Portals with at least 1000
concurrent users
Note:
for each of the criteria will only be considered
for evaluation)
credentials
a) Call Centre Experience (10 Marks)
3 Projects: 8 Marks
2 Projects: 5 Marks
1 Project: 3 Marks
one of the projects has been executed for an
Indian client covering multiple regional
languages.

b) Portal Experience (5 Marks)
3 Projects: 5 Marks
2 Projects: 4 Marks
1 Project: 3.5 Marks

response
Copy of Contract
Work Order
of the project
5
Experience in implementing infrastructure
solutions
10
e. The bidders should have experience of 3 projects = 10 The following documents for each

furnished
implementing at least two of the following
Infrastructure solutions within the last 5 years in a
single project:
EMS,
Directory,
Email solutions,
Service Desk,
ITIL
Valid projects for this criteria will cover:
For EMS Bidder should have implemented at
least 2 modules out of Network Monitoring,
Server monitoring, Application monitoring,
Event Correlation in a single project
For Directory and Email solutions
Implementation must be across 50 or more
locations or serve minimum of 10000 users
ITIL Bidder should have implemented project
service desk supporting minimum 1000 users
Note:
2 projects= 8
1 project = 6
response
Copy of Contract
Work Order
of the project

furnished
credentials


5.2.1.5 Scoring criteria for Approach & Methodology
The Approach and Methodology adopted for the implementation should cover at least the
following aspects apart from the technical and functional solutions:
Project Execution
Deployment Methodology
Support methodology, including Service Desk
Data Migration
Training Approach
Bidder must be able to showcase how their previous experience in Postal Industry, ERP
Implementation, System Integration projects, Customer Interaction channels, Infrastructure
solutions, etc. will be leveraged through their Approach & Methodology proposed for the project
Project Execution
The bidder would be evaluated on the following parameters:
Understanding of solution proposed in terms of business requirements, architecture and
implementation
Design of the solution proposed in terms of architecture, application design & performance,
integration, deployment and maintenance
Development approach and methodology in terms of application development strategy,
development environment architecture, tools, etc
Deployment approach and methodology
Deployment Methodology
The bidders implementation plan, proposed timelines and deployment methodology to meet these
plan and timelines will form a critical part of the final evaluation and selection of the bidder.
Bidder must ensure that the implementation plan and timelines are adequately described at a
detailed level in terms of plan, approach, tools and technique.
Support methodology, including Service Desk
The bidders proposal must have include sections describing the proposed methodology for
providing support to the entire DoP workforce and integrating with other vendors like FSI, RSI, NI,
DC, etc. CSI is expected to provide a service desk support to all employees of DoP hence it will form a
critical aspect of the overall proposal. Bidder should include team structure and evolution of the
support team during the rollouts and post completion of all rollouts, during the support phase.
Data Migration Methodology
The quality of the bidders Data Migration strategy and processes will form an integral part of the
final evaluation and selection of the bidder.
Bidder must ensure that the data migration strategy and techniques used are adequately described
at a detailed level in terms of plan, approach, tools and techniques for migration, data integrity,
verification post migration, etc. The areas to be addressed should cover but not necessarily be

limited to the Data Migration training techniques, details of various steps to be carried out for
successful data migration by the SI and experience of the implementers.
Training Approach
The quality of the bidders training approach plan and the details shall form an integral part of the
final evaluation and selection of the bidder. The bidder should include details in terms of training
approach and strategy, content and courseware, manpower to train and impart training, training
infrastructure and facility, delivering the training, including the innovative methods and techniques
for imparting the training first time and for the continuous refresher training. It should also include
details about support, monitor and measuring training effectiveness.
Table 8: Scoring for Approach & Methodology
# Approach & Methodology 75
a.
Overall understanding of the project including the objectives,
requirements, challenges envisaged in implementation etc.
10
b.
Overall approach and methodology to be adopted for the project.
The bidder should be comprehensive in their response and should cover
all elements of the project requirement including the proposed tools,
technologies and products.

b.1 Project Execution 9
b.2 Deployment methodology 9
b.3 Support methodology, including Service Desk 9
b.4 Data Migration methodology 9
b.5 Training Approach 9
c.
Project Execution plan, Milestones and Timelines
The Project execution plan must be in the form of a Gantt chart, identify
major milestones, map the main resources to be deployed for key
activities etc.
20
5.2.1.6 Scoring criteria for Team Strength & Qualification
Bidders responses to each point under Team Strength & qualification, including the team profile
provided by the bidder, would be evaluated.
Table 9: Scoring for Team Strength & Qualification
#
Team proposed for the project and qualifications, experience and
competency of key professional staff
150
a. Overall Program Manager (1 resource) 20

b.
Project Managers/ Functional Leads (1 each for Mail Operations, Finance
& Accounts, Human Resources, Infrastructure, BI and Data Warehouse,
CIM and Call Centre, PoS Applications)
35
c. Postal Experts ( 3 profiles ) 21
d. ERP Implementation Expert Finance (2 Profiles) 10
e. ERP Implementation Expert HR (2 Profiles) 10
f. Government Accounting Expert (2 Profile) 10
g. Enterprise Architect (profile must have TOGAF certificate) 15
h. Architects (2 each for Application, Infrastructure, Integration) 24
i. India Payroll Expert 5
Bidder must be able to showcase how their previous experience in Postal Industry, ERP
Implementation, System Integration projects will be leveraged through their Resources
proposed
The above profiles are considered for evaluation, which needs to be mandatorily proposed.
However bidder is expected to ensure all the required roles are included as per the bidders
implementation plan to meet the requirements of the RFP and suitable resources are proposed.
5.2.1.7 Scoring criteria for Overall Integration Plan
Table 10: Scoring for Overall Integration Plan
# Overall Integration plan 75
a.
Comprehensiveness of Integration Plan covering
Schedule of Integration tasks
Geographical scale requirements
All components and sub-systems
Roles & responsibilities, including bidders sub-contractors (if any)
Documentation and resolution of integration problems
Migration from existing applications and support during the transition

6
7
7
7
5
8
b.
Approach to work with multiple DoP vendors (e.g. RSI, FSI, NI, DCF etc)
Solutions development and deployment
Common infrastructure solutions
Help Desk
Call Centre

10
10
7.5
7.5
5.2.1.8 Overall Scoring
Table 11: Overall Scoring Methodology

# Evaluation Criteria
Total Marks
allocated
Minimum
Qualification Score
1 Relevant Experience (RE) 100 65
2 Team Resources proposed (TR) 150 105
3 Approach and Methodology (AM) 75 52.5
4 Overall Integration Plan (IP) 75 52.5
5 Solution Proposed (SP) 200

5.a Compliance to Functional Requirements 100 80
5.b Solution Integration 100 70
Only those bids, which score more than the minimum qualifying for each of the above listed items,
shall be short-listed for the opening of Financial Bid.
The final Technical Score shall be calculated as following:
Technical Bid Evaluation Score: T = RE + TR + AM + IP + SP

5.3 Evaluation of Financial Bids
DoP shall publicly open the Financial proposals of only those bidders who are technically qualified, in
the presence of bidders authorised representatives who choose to attend, at the date and time
mentioned in Section 2.2.2: Schedule for the bidding process, or otherwise communicated by
DoP. The authorised representatives, who intend to attend the bid opening, are to bring with them
letters of authority from the respective bidders. The name of the bidders, their technical scores and
their financial proposal shall be read aloud. The bidders authorised representatives who are present
during bid opening shall sign an attendance sheet evidencing their attendance. In the event of the
specified date of bid opening being declared a holiday for DoP, the bids shall be opened at the
appointed time on the next working day.
5.3.1 Net Present Value
1. The Financial bids will be evaluated based on the Total Price as arrived from the Price Summary
table using Net Present Value Method (NPV).
2. The NPV method shall be applied on the following price components ONLY to arrive at the Total
Price to be considered for evaluation:
a. Operations & Maintenance Price (Form FIN 6)
The Net Present Value (NPV) for the price elements shall be calculated as per the following
formula:
P
n
/(1+ r)
n

Where:

a. P
n
= Price for a particular nth year, i.e. n is 1 for 1st year, 2 for 2nd year 5 for 5th
year
b. r is Cost of Capital = 9%
5.3.2 QCBS method of selection of bidder shall be adopted by Department of Posts
1. In QCBS, the solution with the lowest evaluated Financial Proposal (F
m
) across all categories will
be given the maximum financial score (S
f
) of 100 points. The formula for determining the
financial scores is the following: S
f
= 100 x F
m
/F, in which S
f
is the financial score, F
m
is the lowest
price and F is the price of the proposal under consideration.
2. The formula for determining the technical score is as follows: S
t
= T/6, in which T is the technical
bid evaluation score of the proposal (solution) under consideration.
3. Proposals (solutions) will be ranked according to their combined technical (S
t
) and financial (S
f
)
scores using the weights (W
t
= the weight given to the Technical Proposal; W
f
= the weight given
to the Financial Proposal; W
t
+ W
f
= 1) indicated below (Section 5.5, Point 4). The combined
score (S) will be calculated as follows: S = S
t
x W
t
+ S
f
x W
f
.
4. The weights given to the Technical and Financial Proposals are:
a. W
t
= 50%
b. W
f
= 50%
5.4 Other Evaluation Conditions
1. During the time of the evaluation of the Technical or/and Financial bids, DoP may seek
clarifications from the bidders on specific items in the bids submitted by them. All such
clarifications will be sent to the contact persons indicated in the proposal either by email or
postal mail.
2. The bidder has the option to respond or not respond to these queries. If the bidder fails to
respond within the stipulated time period, DoP has the right to make assumptions on the
Technical or/and Financial bids submitted by the bidder and if such assumptions lead to
disqualification of the Technical or/and Financial bids, DoP is not accountable for these
omissions.
3. The responses by the bidders to the queries raised by DoP will be treated as part of the
proposal.
4. If any of the responses by the bidders to the queries sent by DoP has commercial implications,
these commercial aspects will not be accommodated in the evaluation process. The bidder is to
sign a declaration to this effect as per Form FIN 4: Undertaking on pricing of Technical bid
Items.
5. The final scores will be rounded to the second decimal.
6. In the event two or more bids are tied on the basis of their combined technical and financial
score, the bid securing the highest technical score among the tied bids will be adjudged the
successful bid.

6. Award of Contract
6.1 Negotiations
1. The Evaluation Committee of DoP reserves the right to negotiate the price with the successful
bidder.
2. Negotiations will conclude with a review of the draft Contract. To complete negotiations, DoP
and the successful bidder will initial the agreed Contract.
6.2 Award of Contract
1. After completing negotiations DoP shall issue a Letter of Intent to the selected bidder, and
promptly notify all bidders who have submitted proposals about the decision taken.
2. The selected bidder will sign the contract after fulfilling all the formalities/pre-conditions
mentioned in the standard form of contract in Volume III, within 15 days of issuance of the letter
of intent.
6.3 Notification of Award
1. Prior to expiration of the period of bid validity, DoP will notify the successful bidder in writing or
by fax or email, to be confirmed in writing by letter, that its bid has been accepted.
2. The acceptance of bid will constitute a legally binding Contract. This will be followed by a
detailed purchase/work order.
3. Upon the successful bidder's furnishing of Performance Security, DoP shall promptly notify all
unsuccessful bidders and shall discharge their Earnest Money Deposit.
6.4 Signing of Contract
1. At the same time as DoP notifies the successful bidder that its proposal has been accepted, it
shall enter into a separate contract, incorporating all agreements (to be discussed and agreed
upon separately) between DoP and the successful bidder. The Model agreement (Draft MSA) is
provided in RFP Volume III.
2. DoP shall have the right to annul the award in case there is a delay of more than 30 days in
signing of contract, for reasons attributable to the successful bidder.
6.5 Failure to Agree with the Terms and Conditions of the RFP
Failure of the successful bidder to agree with the Terms and Conditions of the RFP shall constitute
sufficient grounds for the annulment of the award, in which event DoP may award the contract to
the next best value bidder or call for new proposals.

6.6 Performance Bank Guarantee
1. The successful bidder shall furnish a performance security in Indian Rupees (`), for an amount of
10% of the Contract value issued by a Nationalized / Private Bank authorized to do business with
Government at the time of singing of the contract with the DoP.
2. The performance security shall be in the form of a Bank guarantee as per the format given in
Section 7.6: Performance Bank Guarantee Format issued by a Nationalized / Private Bank
authorised to do business with Government having at least one branch office in New Delhi,
India. The performance security shall be valid for a period of 60 days beyond the date of
completion of all contractual obligations of the supplier, including warranty obligations.
3. The performance security shall be forfeited by bidder and credited to DoP in the event of a
breach of contract by the successful bidder, in terms of the relevant contract. DoP shall notify
the successful bidder in writing of its invocation of its right to receive such compensation
indicating the contractual obligation(s) for which the bidder is in default and the bidder will have
to pay it within 15 days of the notice date.
4. The performance security shall be refunded to the successful bidder after it duly performs and
completes the contract in all respects within 60 days of completion of all such obligations under
the contract.
5. In the event of delay in completion of warranty period obligations beyond the specified time
period, the successful bidder shall arrange to extend the performance security from time to time
to the satisfaction of DoP.
6. The successful bidder shall furnish amendment to the Performance Security, if required,
immediately
7. Annexure
7.1 Profiles to be evaluated for the Assignment
Table 12: Profiles to be evaluated
# Key Position
No of
profiles
required
Education
Qualification
Professional Experience
1 Program
Manager
ONE B.E / B.Tech /
M.Tech and
MBA
Minimum 15 years of project management
experience of large scale IT implementation
projects
At least 5+ years of experience in
implementing end-to-end Core System
Integration Project
Should have experience of managing 3 end-
to-end large scale IT implementation project

including 1 end-to-end Core System
Integration Project
Should have experience of one end to end
implementation project in HR, F&A and
Inventory Management modules
PMI/ Prince2/ equivalent certified Project
Manager
2 Project
Managers/
Functional
Leads Mail
Operations

ONE B.E / B.Tech /
M.Tech and
MBA in
Operations
preferred
Minimum 12 years of experience and should
have experience of managing large scale IT
implementation projects that involve Mail
solutions
implementing COTS solutions for Mail
Operations
Should have experience of implementing at
least 2 end to end COTS solutions as a
functional lead for Mail Operations
3 Project
Managers/
Functional
Leads
Finance &
Accounts

ONE B.E / B.Tech /
M.Tech and
MBA in Finance
/ Chartered
Accountant
implementation projects that involve Finance
& Accounting solutions
implementing Finance & Accounts COTS
solutions
least 3 end to end Finance & Accounts COTS
solutions as a functional lead
Should have sound understanding of Indian
accounting standards and policies (Indian
GAAP)
4 Project
Managers/
Functional
Leads
Human
Resources

ONE B.E / B.Tech /
M.Tech and
MBA in HR
implementation projects that involve Human
Resource Management solutions
implementing Human Resource Management
Solution (COTS)
least 3 end to end Human Resource
Management COTS solutions as a functional
lead
5 Project ONE

Managers/
Functional
Leads
Infrastructure

6 Project
Managers/
Functional
Leads
Business
Intelligence
and Data
Warehouse

ONE B.E / B.Tech /
M.Tech
Minimum 12 years of experience in Business
Intelligence with at least 3 years in core
project management
Should have 5+ years experience in
implementing Business Intelligence/ Data
Warehousing solutions including modelling
data structure, batch reporting, database
management and security management
Should have excellent knowledge and
experience with metadata, SQL, OLAP,
information architecture and technology
infrastructure
7 Project
Managers/
Functional
Leads Call
Centre

ONE B.E / B.Tech /
M.Tech
have experience in call Centre setup and
information systems and their associated
business applications
Should have at least 5+ years of experience
in setup and running of call Centres including
modelling, call Centre technology,
networking, floor plan design, security
systems, process management and
management information systems
Project
Managers/
Functional
Leads
Website
(Added this
one as Call
Centre and
Website setup
require
completely
different skill
set)
ONE B.E / B.Tech /
M.Tech in IT
have experience in managing website
development, related infrastructure
management, assessing technical
performance, security and content
management
in build, test. Launch and maintenance of
web applications, forms, graphics and
knowledge of programming languages such
as JAVA, HTML and ASP.NET
Should have at least 3+ years experience in
ecommerce setup and administration and
third party services management
8 Project ONE B.E / B.Tech / Minimum 12 years of experience in large

Managers/
Functional
Leads PoS
Applications

M.Tech or MBA scale IT implementations and should have
experience of implementing POS applications
Should have at least 5+ years experience in
planning, testing and rollout of COTS
solutions for POS applications
Should have sound understanding of POS
systems, standalone Kiosks and back office
systems
9 Postal/Logistic
s Expert
THREE M.Tech or MBA
in Operations
implementation projects that involve postal
or logistics solution implementation
Must have experience of at least one project
in implementing postal or logistics solution
10 ERP
Implementati
on Expert -
Finance
TWO M.Tech or MBA
in Finance
implementation projects that involve Finance
& Accounting solutions
implementing Finance & Accounts COTS
solutions
Should have sound understanding of Indian
accounting standards and policies (Indian
GAAP)
11 ERP
Implementati
on Expert - HR
TWO MBA in HR Minimum 10 years of experience and should
implementation projects that involve Human
Resource Management solutions
implementing Human Resource Management
Solution (COTS)
12 Government
Accounting
Expert
TWO
Should have minimum of 12 years of
experience in Finance and Accounting for
large scale enterprises and Public Sector in
particular
in managing changes in accounting policies,
transitioning to accrual based accounting,
activity based costing, consolidation of
financial statements and accounting for
controlled entities
13 Enterprise ONE
B.E/B.Tech Minimum 15 years of Architecture

Architect experience of large scale IT implementation
projects
More than 6 years of experience of
Enterprise Architecture in large
organizations/Projects
Should have Enterprise Architecture
experience in minimum 3 large size IT
Implementation projects
Should have Enterprise Architecture
experience in minimum 2 projects where ERP
package was implemented
Should have a TOGAF certification
Should have experience of defining technical
governance in at least 2 projects
Previous postal experience will be preferred
14 Technology
Architects
(Applications)
TWO
B.E/B.Tech Should have 10+ years of experience in
system architecture, software engineering &/
or product development experience
Should have at least 6 years of experience in
end-to-end application development lifecycle
Should have Application Architecture
Should have Application Architecture
15 Technology
Architects
(Infrastructure
)
TWO
B.E/B.Tech Should have 10+ years of experience in
infrastructure architecture
end-to-end infrastructure implementation
and management
Should have Infrastructure Architecture
Should have Infrastructure Architecture
16 Technology
Architects
(Integration)
TWO
B.E/B.Tech Should have 10 years of integration
experience in large scale IT Projects

end-to-end application integration
Should have Integration Architecture
Should have experience of integration with
ERP packages in minimum 2 projects
Should have implemented ESB in at least 2
projects
Should have experience in defining &
implementing Service Governance in at least
2 project
17 India Payroll
Expert
ONE B.E / B.Tech /
M.Tech and
MBA
Should have minimum of 12 years of
experience in large scale IT implementations
Should be a subject matter expert in payroll
and well versed in India payroll regulations,
policies and best practices across industries
such as Public Sector and Financial Services
and should define the requirements for
building payroll application
Should have experience of implementing
Payroll applications in at least 2 projects in
India. At least one of the implementations
should be for a PSU or Government


7.2 Technical Bid Formats
7.2.1 TECH 1: Covering Letter

(To be submitted on the Letterhead of the bidder)
(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Subject: Submission of RFP for Selection of Core System Integrator for India Post
IT modernisation project

Dear Sir,

Having examined the RFP, we, the undersigned, offer to provide the professional services as
required and outlined in the RFP for Selection of Core System Integrator for the India Post 2012
Project.

The following persons will be the authorized representative of our company/organisation for all
future correspondence between the DoP and our organisation till the completion of the
procurement process for the Core System Integrator of the India Post 2012 project.

Primary Contact Secondary Contact
Name:
Title:
Company Name:
Address:
Phone:
Mobile:
Fax:
E-mail:
We fully understand that in event of any change in our contact details, it is our responsibility to
inform the DoP about the new details. We fully understand that the DoP shall not be responsible for
non-receipt or non-delivery of any communication and/or any missing communication from the DoP
to us in the event of reasonable prior notice of any change in the authorized person(s) of the
company is not provided to the DoP.


We attach hereto our response as required by the RFP, which constitutes our proposal.

We confirm that the information contained in this response or any part thereof, including its
exhibits, and other documents and instruments delivered or to be delivered to DoP is true, accurate,
verifiable and complete. This response includes all information necessary to ensure that the
statements therein do not in whole or in part mislead the department in its short-listing process.

We fully understand and agree to comply that on verification, if any of the information provided
here is found to be misleading the RFP process, we are liable to be dismissed from the selection
process or termination of the contract during the project, if selected to do so.

We agree for unconditional acceptance of all the terms and conditions set out in the RFP document
and also agree to abide by this tender response for a period of 180 days from the date fixed for bid
opening.

We hereby declare that in case the contract is awarded to us, we shall submit the Performance Bank
Guarantee for an amount of 10% of the Contract value issued by a Nationalised / Private Bank as per
the format provided in the RFP document.

We agree that you are not bound to accept any tender response you may receive. We also agree
that you reserve the right in absolute sense to reject all or any of the products/ services specified in
the tender response.

It is hereby confirmed that I/We are entitled to act on behalf of our company/ corporation/ firm/
organisation and empowered to sign this document as well as such other documents, which may be
required in this connection.

Dated this ___ day of ___ 2011

Yours sincerely,

on behalf of *bidders Name+
Authorised Signature [In full and initials]:
Name and Title of Signatory:
Name of Firm:
Address:
Seal/Stamp of bidder:

7.2.2 TECH 2: Details of Relevant Experience of the Bidder
7.2.2.1 Experience of implementing large scale IT projects including application development
and deployment in the Postal industry within the last 5 years

# Item Details
General Information
I. Customer Name, Location, Country
II.
Name of the Contact Person and contact
details for the project

Project Details
III. Name of the project
IV. Start Date/End Date
V. Current Status (work in progress, completed)
VI. Contract tenure
Size of the project
VII. Order Value of the project (in ` lakhs)
VIII.
Total Price of the services provided (by the
bidder)

IX. Title and Scope of the Project
Narrative description of Project:
Description of actual services provided by your company within this project

Notes:
I. Please use one form per project
II. Please submit copy of Work Order/ Client Letter/ Job Completion Certificate as proof in support
of above declaration
III. Bidders may be required to facilitate interaction with the client and/or site visits, if required
7.2.2.2 Experience of end-to-end ERP implementation with minimum of 500 functional named
users within the last 5 years

# Item Details
General Information
I. Customer Name
II.

III.
Type of Industry where project was
implemented ((e.g. Government, Banking &


# Item Details
Financial Services, Hospitality, Technology,
Manufacturing, Retail etc.)
Project Details
IV. Name of the ERP project
V.
Location Details where project was
implemented

VI. Start Date/End Date
VII. Current Status (work in progress, completed)
VIII. Contract tenure
IX. ERP Package Used
X. ERP modules implemented
Size of the project
XI. Order Value of the project (in ` lakhs)
XII.
bidder)

XIII. No. of ERP functional users
Description of actual services provided:

Notes:
7.2.2.3 System Integration Services in India within the last 5 years
# Item Details
General Information
I. Customer Name
II.

Project Details
VI. Contract tenure
Size of the project

# Item Details
VIII.
bidder)

IX.
Scale of Project (give details of locations
covered under the project, including the
names of states / UTs covered)


Notes:
7.2.2.4 Customer Interaction Channels
7.2.2.4.1 Experience of setting up and managing Call Centre operations with minimum capacity of
100 seats within the last 5 years
# Item Details
General Information
I. Customer Name
II.

Project Details
VI. Contract tenure
Size of the project
VIII.
bidder)


# Item Details

Notes:
7.2.2.4.2 Experience of implementing portals with at least 1000 concurrent users for an Indian
Client
# Item Details
General Information
I. Customer Name
II.

Project Details
VI. Contract tenure
Size of the project
VIII.
bidder)

Description of actual services provided by your staff within the assignment:

Notes:
7.2.2.5 Experience of implementing Infrastructure solutions including EMS, Directory services, e-
Mail solutions, Service Desk, ITIL etc.
# Item Details

# Item Details
General Information
I. Customer Name
II.

Project Details
VI. Contract tenure
Size of the project
VIII.
bidder)


Notes:


7.2.3 TECH 3: Compliance Statement Format for Technical Requirements

# Description
Vendor Response
Compliant
Non-
compliant
Remarks

Technical Requirements
1.
The solution architecture and system must use open standards based, flexible and extensible
integration interfaces between the various components of the solution.

2.
The solution architecture of the system should be multi-tiered and it should have a minimum of
the following tiers: presentation layer, business logic layer and data layers with well defined
interfaces.

3. The solution offered should be Service Oriented Architecture (SOA) compliant.
4.
The solution architecture should be modular, highly granular, loosely coupled and flexible which
should be able to plug-and-play different components based on the business requirements.

5. The solution architecture should have no single point of failure within and across tiers.
6.
The solution should include load balancing and other performance tuning mechanism for web,
application, and Database tiers.

7. The solution must support an RDBMS based solution.
8. The solution should allow the system to be built for 64 bit operating system.
9. The solution should support application load balancing and Database clustering.
10. The solution should have capability to integrate with 3
rd
party/ legacy applications.

11. The solution should have the ability to maintain log of transactions at all the tiers.
12.
The solution should have the ability to export data output directly in excel, PDF, text, XML, HTML,
etc.

13. The solution should be able to import data from various formats (such as Text, Excel, CSV, XML).
14. The solution should support GUI and/or web-based User Interface.
15. The solution should support remote operation of system administration.
16.
The solution should have the ability to restrict data update/deletion/creation only through
application layer.

17. The solution should support real time transaction processing and master data update.
18. The solution should support data import & export to variety of Databases.
19. The solution should be supported on client with any Operating System like windows, Linux.
20. The solution should support TCP/IP, HTTPS, HTTP.
21. The solution should support version control.
22.
The solution should support the leading back-up vendor products to manage automated Database
back-ups and restore.

23. The solution must be able to integrate Database with leading archival technologies.
24.
The solution should provide online documentation, on-line help, field-level help, screen-level help
etc.

25.
The proposed solution should be able to seamlessly integrate with other business systems such as
ECMS, Banking, Insurance etc.

26.
The solution must be able to seamlessly upgrade services, components and modules without


affecting services.
27.
The solution must support low bandwidth and "near-no" bandwidth conditions for the
transactions.

28.
The solution should be highly scalable to support current and future requirements as per the
volumetric data provided in RFP.

29.
The system should support variance up to 20% in peak volumes as they are subjected to variances
such as festivals, seasons, economic state of the country and customers, regulatory changes, etc.
There should be no impact on the system performance during these scenarios.

30.
The solution should be designed in such a way that the availability to the users is not impacted in
any way while carrying out any planned operations such as daily, monthly or annual closings,
system maintenance, backups, data warehousing, data mining, report generation, MIS generation
or while running batch processes.

31. The system should support all the standards mentioned in the Section 6 of Volume I of this RFP
32.
The solution should include the details of various environments required for design, build and
testing. The minimum environments that should be provided are development, testing,
preproduction and production.

33.
CSI must be able to share schema and other logical models/artefacts with other service providers
such as FSI, RSI etc. for any enterprise data requirements.

34.
The solution should be able to integrate with multiple external payment gateways and SMS
gateways.

35. The solution should ensure that Data integrity should not be lost in any scenario.
36.
Solution should have the ability to:
Provide performance statistics for the CPU/ Memory, Database, Application servers


Predict possible system bottlenecks

37.
Solution should have tools to assist administration of:
Configuration Management

Performance Tuning

System Diagnostics

Capacity Planning

38. Ability to send alerts to system administrator in case of defaults/ failure/ bottlenecks

Point of Sale Technical Requirements
39. PoS applications should support Hindi and English
40.
PoS should have capability to provide local inventory status & synchronise with the central
inventory. Information/data available on POS should be encrypted and secure.

41. PoS should have capability to work as a standalone system or in offline mode.
42.
POS should have capability to integrate with 3
rd
party business applications (i.e. Retail) and with
the inventory on central server as per DoP requirements.

43.
PoS should support all the features of Banking, Insurance and Mail Operations as specified in
functional requirements.

44.
PoS should be able to integrate with components of the ERP such as General Ledger, Finance &
Accounts, etc.

45. POS should have the capability to connect with weigh machine and bar code scanner.

Basic Telephony
46. Solution should support TDM/IP/SIP/Video end-points

47. Solution should be able to connect to trunks of different protocols i.e. ISDN/IP/SIP
48. Features such as Call transfer, conference, call forwarding etc should be provided
49. Restriction of features/services based on user (agent) profile should be feasible
50. Call billing system to track and report outbound calls

Resiliency & Monitoring (common for entire Call Centre Infrastructure)
51.
Basic Telephony System, ACD, IVR, CTI & CRM solutions should be resilient with seamless
handover to standby server

52.
System should be able to provide notification in case of any failure of hardware, application, trunk
failure etc on SMS, email, visual notifications

Scalability & Life of product (common for entire Call Centre Infrastructure)
53. All components of the Call Centre system (Telephony, CRM, ACD, IVR, CTI, etc) should be scalable
54.
Version upgrades or dot releases of various components of the Call Centre system (Telephony,
Application, ACD, IVR, CTI, etc) should be covered in the initial supply.

55. Upgrade of IVR ports in blocks or individual numbers should be feasible
56. Upgrade in quantity of ACD/CTI license should be feasible

Call Centre Technical Requirements Interactive Voice Response
57. System should receive all inbound calls on the toll-free telephone number set up by the DoP.
58.
System should identify customer through Calling Line Identification (CLI) and support intelligent
call routing.

59.
System should include speech recognition engine in order to support and interpret multiple
languages.


60. System should support multiple languages for Text-to-speech capability.
61. System should support all the languages specified in the RFP.
62.
System should be easily configurable that enables the users to change the IVR tree without any
hard-coding.

63. System should support messages scheduling.
64.
System should be able to capture usage details of each customer as the customer traverses
through a call.

65.
System should have an interface through which the customer usage details can be shared with
other solutions.

66.
System should integrate with the rest of the proposed solution to provide seamless Call Centre
performance.

67. IVR System should be able to integrate with DoP's existing database servers for call routing.
68.
IVR solution should include capability to provide reports - to generate utilization reports, call
volume on entry points etc

69. IVR should support connectivity with telephony system (same or different) at multiple locations
70. IVR system should be able to connect to trunks of different protocols i.e. ISDN/IP/SIP

Call Centre Technical Requirements Automatic Call Distribution (ACD)
71. System should handle high call volumes efficiently.
72. System should support multiple groups for all call types.
73.
System should provide the capability of combining data with the IVR menu system that can
intelligently rout calls requesting further assistance to a smart ACD.


74.
System should provide highly configurable system for adding/removing users, assigning users to
different queues and defining skill sets.

75. System should support intelligent call based routing.
76. System should allow calls to be transferred within and outside the Call Centre.
77.
System should support the relaying of marketing messages to voice callers while waiting in queues
or when on hold.

78.
System should be capable of providing Call Centre reports on agent performance, group answered
calls.

79. System should allow customization of reports as per requirement.
80.
ACD features such as - call barge-in local and remote, work codes & other standard features
should be available.

Call Centre Technical Requirements Computer Telephone Integration (CTI)
81. System should be able to integrate with setup of a Call Centre solution
82.
Must be able to interface with the key business applications banking, insurance, mail operations
and RICT along with other third party applications to send/receive data

83. System should have the ability to generate and service requests
84. The CTI must be capable of activating the fast dialling feature of the ACD
85.
Call events should be handled from the system such as hold, retrieve hold, conference, transfer,
etc.

86. CTI should be integrated with core Call Centre system and must be able to update the IVR
87. Should be able to integrate with setup of a Call Centre solution


Call Centre Technical Requirements Call Centre Application
88. Call Centre application should support ticket with all related data logging and tracking.
89.
It should enable Managers/Supervisors to monitor the overall performance of the Call Centre
agents and interact when needed.

90.
It should interface with other applications to retrieve information that would be required by the
Call Centre agent to perform various tasks.

91.
It should integrate with the CTI and should be able to pull IVR usage details of the customer
including all options selected by the customer and all details entered by customer from the time
the customer reaches an agent.

92. It should allow the agent to log on to the system and track each ticket.
93. Information of the escalated tickets should be made available as and when required

DoP Website Technical Requirements
94.
The solution should support web based access to all business/enterprise applications through
India Post website.

95.
The website should implement consistent look-and-feel and shall be the single platform for
disseminating information

96. The system should not allow concurrent sessions for the same user
97.
The solution should support two modes of access Anonymous and Secure. While general
contents should be freely accessible, some restricted contents should be made accessible to
registered users only.

98.
The system should automatically log out a customer in case of session breakdowns (e.g.,
communication failure, high inactivity period - these should be parameterized)


99.
The website should implement security features, such as password complexity, automatic
blocking (temporary/permanent) of user logins after given number of unsuccessful login attempts
(should be parameterized), controlled access to content stored on the portal and logging of
security incidents.

100.
The website should also conform to the Guidelines for Indian Government Websites which is
available at http://web.guidelines.gov.in and http://egovstandards.gov.in/.

101.
Some of the secure web contents will be accessible through HTTPS protocol on Secure Socket
Layer (SSL) using web browser.

102.
The Usage Analytics services shall provide the interface that manages and creates reports on
website usage. These analytics reports shall provide usage data such as web hits, number of visits,
duration, usage pattern, web errors etc.

Should provide support for comprehensive audit trail features such as:
103. Daily activities log are merged into the history log files
104. Date, time and user-stamped transaction checklist are on-line generated for different transactions
105.
All transaction screens should display system information including Function ID and Name,
Processing Date, Current Time, Current User, etc.

106. Daily activity reports are provided to highlight all the transactions being processed during the day
107. Unsuccessful attempts to log-in to the system should be recorded
108. All attempts to access/change system data should be system driven
109.
The website should support all leading browsers such as Microsoft Internet Explorer, Firefox,
Chrome etc.

110.
The website should be able to interface with enterprise applications (Banking, Postal Insurance,


Mail Operations etc.) seamlessly through interfaces provided by applications.
111. The web application should be able to support HTML, DHTML, etc. (Markup language)
112.
The solution should support client side scripting/ programming languages like Java scripts, VB
scripts, Java Applets, ActiveX, etc.

113.
During transaction input, fields are automatically validated to ensure the validity and consistency
of data

114.
The website should provide search engine with advanced full-text search capabilities

115.
The search engine should be able to search for requests within the site.

Packaged Applications (PA) Technical Requirements
116. The solution offered should be uni-code compliant.
117.
The solution should have the ability to support multi currency operations.

118.
The solution should have the ability to connect database through ODBC, OLEDB, JDBC and through
native drivers.

119. The solution shall have context sensitive help capability.
120.
The solution should ensure that data is entered/captured only once to minimize data redundancy.

121.
The solution should have the ability to set up business rules and notify exceptions/ alert/
reminders to users.

122. The solution should include rule based data cleansing/ enhancement tool.
123.
The solution should support role-based access control and segregation of duty.


124.
The solution should allow for fresh login to the application during online data backup.

125.
The solution should provide integrated management for all the components.

126.
The solution should be capable of retaining the data structure and format even after
release/upgrades.

127.
The solution should be capable of maintaining data on continuous basis without affecting system
performance.

128.
The solution should have the ability to configure the meta data for field creation, report
generation etc.

129.
The solution should provide concise overview of parameters like configuration changes,
infrastructure usage, performance, required maintenance activities, potential security issues,
status of business flows and diagnostic test results.

130.
The solution should be able to integrate email systems supporting SMTP for notifications &
workflow.

131.
The solution should be capable of generating user friendly reports across all modules, which shall
be meaningful, consolidated and concise, could work as an effective tool for top executives for
decision making.

132.
The solution should have scalability in terms of:
Number of users

Number of workflows supported

Number of organizational entities

ESB BPM Technical Requirements
133. Solution should be implemented using SOA and must support the ESB design pattern.

134.
ESB should support SOA standards such as XML, XSLT, BPEL, web services standards and
messaging standards.

135.
ESB should support all industry standards interfaces for interoperability between different
systems i.e. Banking, Insurance, Mail etc.

136.
ESB should support the use of WSDL 1.1 to describe service interfaces, with XML schema being
used as the way of representing the format of data used in XML-based message exchanges.

137.
ESB should support the following integration security standards:
Authentication

Authorization

Encryption

Secure Conversation

Non-repudiation

XML Firewalls

Security standards support

WS-Security 1.0

WS-Trust 1.2

WS-Secure Conversations 1.2

WS-Basic Security Profile

138. The solution should support routing to all internal & external systems.
139.
The solution should define a canonical structure wherever possible and support transformation
to/from all available structures.

140.
The solution should have comprehensive auditing capabilities to support any internal or external


audits.
141. The solution should provide configurable logging feature for supporting error handling.
142.
The solution should provide transaction integrity for all transactions including the long running
and distributed transactions.

143. The solution should include feature of service registry for managing all services.
144. The solution should support synchronous & asynchronous service/message integration.
145. The solution should support graphical modelling environment for process flow.
146. The solution should support long running processes.
147. Business process modelling should support process choreography & process orchestration.
148.
Business process management tool should use Business Process Execution language (BPEL)
standard and provide the facility for the following:

Graphical user interfaces for all configuration, installation and operations activities

Interfaces for the configuration of the users and roles that are business-user friendly

Wizard-like assistants and command line actions for power users

Process designer must provide a UDDI and WSDL service browser

Process designer must support Human workflow/ Human tasks

Process designer should provide inbuilt wizards to model connectivity to packaged apps, JMS,
JCA, AQ, File systems and other legacy systems

Process designer should have some built-in integration services like JMS, FTP, Email services

Process designer should provide wizards to generate common process flow

Process designer must provide support for non-XML to XML translation


The transformation designer must provide auto mapping and debugging support

Process designer must provide out-of-box, inbuilt reports for historical process/activity
analysis

149.
BPM should have the following facilities for data exchange:
Ability for reading data from multiple data sources to compose a message response

Ability to read messages in XML, DTD and XSD formats

Ability for encoding standards: Unicode, EBCDIC, ASCII, DBCS and code pages

Ability to route messages based on that messages content and rules associated with the
message type

Support for persistence of instances or sessions

150.
The solution should be able to support connectivity using protocols like JMS, HTTP/HTTPS, Secure
FTP, FTP, SMTP, LDAP, SOAP etc.

151.
The Business Process layer should provide the following security functions:
Facility for Role-based user access and logging

Facility for industry standard authentication repositories (LDAP)

Configurable time-out threshold for user sessions

Support data encryption for the transmission of login passwords

152.
The business process management interaction layer should support following transaction
management capability:

It should provide several number of transactional interaction patterns

Support for logging the state of a transaction when it changes

Support for both synchronous and asynchronous transactions


153.
High performance and reliability for the information exchange between multiple systems:
Provide for high availability features

Facility for automatic (configurable) crash recovery including configurable fail over and
redundancy

Facility to prioritize requests. The system to allow the developer to configure prioritization of
requests where it makes sense, in the workflow engine, and automatically takes care of
processing in the process layer.

154.
The business process management and integration platform must provide the following support
for Business Activity Monitoring:

Facility to provide real time information of operation

Facility to provide capability to business users to get the ability to build interactive, real-time
dashboards and proactive alerts to monitor their business services and processes.

Facility to support graphical view of operation

Facility to provide capability to business user to monitor their SLA and KPI.

155.
Facility to provide the following security features for deploying Service-Oriented Architectures
across department level applications:

Web Services Security: Ability for policy-driven security and management capabilities to
existing or new Web services.

Policy management: Ability for migration of policy development from development to testing,
and then on to production. Also Allows versioning of policies.

Support: Ability to virtualize an underlying Web Service, so that clients do not learn the
address details of the Service.

Mail Operations Technical Requirements - General Requirements

156. The solution must provide a framework to integrate with multiple mail booking vendors
157. The solution must integrate with barcode scanner and printer
158.
The solution should support an online booking (e-payment system) for SMBs with mail room
facility

159. The solution should support data exchange with RFID enabled systems and applications
160. The system shall have accounts for facilitating bill collection for Business Partners
161. The solution should have capability to interfaces with India Post business partners
162.
MBE shall integrate with Franking Machine users (including franking software and hardware)

163.
MBE shall integrate with the remotely managed franking system server at the vendor location
(RMFS server).

Mail Operations Technical Requirements - IPVS
164. The IPVS system must integrate with the DPMS system
165. The IPVS system must support the 2-9-2 item bar code standard
166. IPVS system must support the Unique Bar Code Format for Individual Articles
167. IPVS system must support the UPU-standard 29-character receptacle bar code
168. IPVS system must support the UPU-standard EDI message formats
169. IPVS system must support the PREDES message formats
170. IPVS system must support the PRECON message formats
171. IPVS system must support the CARDIT message formats
172. IPVS system must support the RESDES message formats

173. IPVS system must support the RESCON messages formats
174. IPVS system must support the RESDIT message formats
175. IPVS system must support the CUSITM message formats
176. IPVS system must support the CUSRSP message formats
177. IPVS system must support the Electronic Verification Notes (eVN) message standards
178. IPVS system must support the CP87 parcel bill formats
179. IPVS system must support the CP78 verification note formats
180. IPVS system must support the CN24 Reporting formats
181.
IPVS system must be able to integrate with and provide interfaces for WMS.

182. IPVS system must be able to integrate with and provide interfaces for TMS.
183.
IPVS system must be able to integrate with and provide interfaces for Railway Carrier Services
(RCS).

184.
IPVS system must be able to integrate with and provide interfaces for Air Carrier Services (ACS).

185.
IPVS system must be able to integrate with and provide interfaces for DPMS.

186.
IPVS system must be able to integrate with Delivery Scanning System and Scanner hardware and
software.

187.
IPVS system must be able to integrate with SMS gateway for sending messages and alert
notifications.

Mail Operations Technical Requirements - DPMS
188. DPMS application should be multi-lingual

189. DPMS should interface with IPVS solution
190. DPMS should provide scanning capability
191.
DPMS should provide the capability of taking an image of the signature on a signed delivery
confirmation form

192.
DPMS solution should provide the capability for the recipient to sign on-screen for e-Proof-of-
Delivery

193.
DPMS device should transmit data collected when cradled back at the office or when wirelessly
connected

194. DPMS system should provide support for electronically generated CN24 standard
195. DPMS system should provide support for electronically generated CN15 standard
196. DPMS should integrate with the Mail Booking Engine for printing ePost articles
197. DPMS should support printing of Unique Article Bar Code and Human Readable ID
198. DPMS should support printing Online or Phone Booked Article Bar Code Labels
199.
DPMS should be able to generate a Bar Code containing the original unique ID on the printed MO
request.

200.
DPMS should generate a unique bar code as per the format specified compatible with DPMS (13
character code 2 character for money order product code MO, 9 digits for unique number
generated and last 2 character would be IN)

Data Warehouse Technical Requirements - Architecture
201. The solution should support BLOB and CLOB objects.
202. The solution should provide user-id and password security, roles and groups.

203.
The ETL server should be 'cluster aware' and support load balancing, fail-over and other cluster
facilities.

204. ETL process should be able to run on a 'grid' of computers or servers.
205. ETL processes should be able to run on different machines or processors.
206.
Data pipelining: Different steps of an ETL process should be able to run on different machines or
processors.

207.
It should allow partitioning to determine on which machine or processor the data has to be
processed e.g. product codes.

208. It should provide adequate scalability to handle clients data volumes.
209.
ETL Tools should be able to exchange data with Metadata Management Tools

210. The ETL tool should be CWM-compliant; it should support the common Warehouse Meta Model.
211. It should allow for features/options to provide for version control.

Data Warehouse Technical Requirements - ETL Functionality
212.
It should allow to read a data source once and load the results into two or more tables (Splitting
data streams/multiple targets)

213.
It should allow for Conditional splitting. This is same as the condition listed above, but in a
conditional way, for example, if revenue is higher then 1000 put the results in table 1 else in table
2.

214.
It should have union capability and allow putting rows of different tables with the same structure
into one table or dataset.

215. It should have data aggregation and data duplication (making multiple data sets) capabilities.

216.
It should allow unloading a table(s) in a temporary store area to lookup/search values.

217.
It should support slowly changing dimensions (hm = manually; wizard = wizard; auto = out-of-the-
box).

218. It should have a mature scheduler that supports dependencies.
219.
It should be able to detect errors within the job, and change the route within the process flow
when a specific error arises.

220.
It should allow for a readability to understand the data attribute movement within the ETL
logic/flow.

Data Warehouse Technical Requirements - Ease of Use
221.
The ETL tool should provide a user friendly GUI for creation of transformation jobs and ETL
sequences

Data Warehouse Technical Requirements - Reusability
222. Components should be reusable and should be able to handle parameters.
223.
It should be able to divide processes into named small pieces of building blocks (modular
programming).

224.
It should have to define variables within in the transformation data flows. The variable should be
able to use either built-in Functions to support simple logical, string and arithmetic operations.

225.
The tool should have features to insert comments in the transformation flow.

Data Warehouse Technical Requirements - Real-time
226.
It should be capable of deployment with both real-time and batch data integration needs.

227. It should be able to publish an ETL process and/or target attribute as a web service


Data Warehouse Technical Requirements - Connectivity
228. It should read/write from industry leading RDBMS using native drivers such as ODBC, JDBC etc.
229. It should read/write Flat File data sources.
230. It should read Flat Files through FTP.
231. It should read XML sources.
232. It should have Bulk Loader support.
233. It should support joined tables as source.
234.
There should be functions available to control the quality of the data (e.g. a matching
transformation or an address cleanser)

235.
It should have the ability to create transformation to remove duplicates.

236.
It should have options for data profiling, uniqueness of values, maximum, minimum, distribution
of values etc.

Data Warehouse Technical Requirements - Metadata Management
237. It should integrate with the Data Modelling tools (list tools).
238. It should provide a central metadata repository for E&T information.
239. Metadata should be in an open relational database.
240. Metadata Repository should support multiple platforms/databases (list details).
241. It should provide interface to the Metadata repository (view and modify).
242. It should have a complete set of metadata (technical, business and deployment).
243. It should provide built-in reports on metadata.

244. It should provide easy to use metadata interface for browsing.
245. . It should comply with the standards Common Warehouse Model ('CWM')
246. It should be allowed to customized/extended the Metadata repository.

MIS & Reporting Technical Requirements - Technical Architecture
247. The solution should provide for a browser based interface.
248. It should be scalable to support 1000 concurrent users.
249. It should allow for source connectivity with leading RDBMS (Oracle, DB2, Microsoft, Teradata etc.)

MIS & Reporting Technical Requirements - Reporting Features
250. The system should support ad-hoc reports.
251.
The system should have calculation capabilities (ability to define complex calculations, user
specific calculations, runtime calculations, etc.)

252. The solution should have the ability to develop custom reports.
253. The solution should be able to create custom objects/ formulas for repeated use in reporting tool.
254. The solution should provide standard report templates.
255. The solution should be able to prioritize reports while execution.
256. The solution should have the ability of reporting both at unit level and DoP level.
257. The solution should provide MIS dashboards for the senior management.
258.
The solution should have the ability to format (page size, row, columns, fonts, colours, tables etc.).

259.
The solution should have the capability for capture/share commentary.


260.
The solution should have column filters/sorts.

261.
The solution should allow for data manipulation (slice & dice data on the fly, pivoting, sorting,
Ranking, rearranging columns, etc.).

262.
The solution should have data mining capability (options/pattern analysis - ability to search data
for patterns that may not be intuitive using one of many techniques).

263.
The solution should have drill-down capabilities (ability to drill down to various levels of a
hierarchy).

264.
The solution should have the capability of raising exception alarms (e.g. email notification).

265.
The solution should provide for exception reporting (ability to set certain thresholds).

266.
The solution should have exporting capabilities (ability to copy resulting data to other applications
such as Excel, Notes, CSV.).

267.
The solution should have graphing capabilities such as graphing options, interactive graphs, ease
of use, dynamic update.

268. The solution should provide user friendly GUI to allow easy generation of reports.
269.
The solution should provide report outputs in RTF, PDF, Excel, CSV formats.

270.
The solution should have integration capabilities e.g. ability to integrate in existing environments
portal.

271.
The solution should allow the user to set preferences.

272. The solution should be able to print (What you see is what you get).
273. The solution should support proxy users or delegation.

274.
The solution should be able to distribute reports (Push, Pull).

275.
The solution should have the ability to save data for later use or to a local PC/laptop or for other
users to view. It should support offline viewing.

276. The solution should have point and click query generation capability.
277. The solution should be able to sort/filter without re-querying.
278.
The solution should have the ability to schedule reports.

279. The solution should have the ability for report bursting.
280. The solution should allow for drag-and-drop formatting
281.
The solution should have web capabilities and same report functions should be available in the
web as in the GUI.

282. It should be able to publish all the reports on DoP portal
283. It should have the capability to provide refresh-only capability to a user group.
284.
It should have the capability for row level security.

285. It should have wizards to help with functionality.
286.
It should allow for user management (ability to maintain user groups, ease of user administration
etc.)

287. It should be able provide monitoring for systems, performance, availability and data growth etc.
288.
The solution should have the ability to archive reports and use in Enterprise Content Management
System.

289. The solution should provide for conditional formatting, based on thresholds or data ranges for any

cell in the report.
290.
The solution should provide access to data and report, based on pre defined user responsibilities.

291. The solution should have the ability to schedule reports to run at periodic intervals.
292. The solution should be able to send reports electronically to other users.
Hardware Requirement
Servers
General requirements of servers
293.
Application and data base servers should be based on RISC/EPIC/X86(Intel/AMD) architecture with
industry standard 64-bit Operating System.

294.
All other servers should also be same OS platform OR any other commercially available and
supported OS platform as per software requirements. The form factor for all other servers must
be Blade only, as per the specifications under Minimum specifications for other servers (web,
management etc.) given below.

295. Servers offered should be of latest generation and highest clock speed at the time of supply.
296.
The bidder should design the overall solution such that the variety and number of server models
in Data Centre is minimized in order to improve the management of the overall solution.
Virtualization and consolidation technologies would be given preference.

297.
The bidder should provide requisite licenses for all the system software required for the database
servers including, but not limited to, Operating System, Compilers, Multi-Pathing software, File
Systems, Volume Managers, OS hardening and verification tool, pre-built failover agents for
database and application software, and Clustering Software etc. for unlimited number of
instances.


298.
The bidder should propose a set of minimum 2 consoles (Servers or high-end workstations with
17" TFT screens with minimum resolution of 1024x768 and KBD/Mouse etc) within the Data
Centre for monitoring and managing the servers. Every server should not be provisioned with
monitor, keyboard and mouse individually. It is envisaged that the servers would be monitored
remotely using the Remote Control facility (NOC).

Minimum Specifications for Database and Application Servers: Following specifications are
applicable to database and application servers of core applications such as Mail Operations, HRMS
and Finance and Accounts.

299.
Application and database servers should be RISC/EPIC/ X86 (Intel/AMD) processor based servers
with processor clock speed of 1.6 GHz or above. Servers offered should be supplied with 64-bit
Operating System. Application OEM or CSI should provide minimum 2 client references which are
running proposed application(s) at locations with minimum 1000 locations or minimum 10000
concurrent users on same platform.

300.
CSI must ensure no single point of failure for production environment and necessary components
must be added to the solution accordingly.

301.
All applications shall fail over on to High availability Server in separate partitions. In case of failure
of any Server, it should be possible to dynamically move CPU and Memory resources from other
partitions to the High Availability Partition without re-booting the system or partition.

302.
Capacity of High Availability Server shall be calculated in a such a way that in case of failure of any
single application, it shall be possible to dynamically allocate same amount of CPU and Memory
resources (as in production) to the HA partition.

303.
The database and application tier for all modules have to be configured on servers which support
partitioning/virtualization technology. The OS disk for each environment must be mirrored.
Required consolidation/virtualization licenses should be proposed for full quoted configuration for
unlimited number of instances.


304.
The proposed server should have ability to use spare processors which would dynamically kick in
when the active processors fail.

305.
Should support a shared architecture wherein CPU and Memory can be shared between the
different partitions, be it virtual partitions or logical partitions.

306.
It is envisaged that both the physical servers should have similar number of partitions and every
partition on one server should be clustered with respective partition on the other server.

307.
The proposed partitioning mechanism should have flexibility of assigning resources like CPU, and
Memory to a unit level granularity to each individual partition. The server should have the
configured capability to assign dedicated resources to partitions.

308.
Each partition should be populated with minimum 8 number of Gigabit full-duplex Ethernet ports
OR 2 x 10Gigabit ports for LAN connectivity. Each 10G port must be capable of carving out at least
4 logical NICs with configurable speeds from one physical port. The server should have the
capability to balance the load across multiple port interfaces in active-active mode and seamless
failover without any data corruption or Application/Database crashing.

309.
The servers should have the capability to balance the load across multiple HBA interfaces in
active-active mode and seamless failover without any data corruption or Application/Database
crashing. Also they should have the capability to support storage arrays of all leading storage
vendors including, but not limited to EMC, Hitachi, HP, IBM, Network Appliance, SUN, etc.

310. Non-production components must be provisioned outside the production servers
311. The servers in cluster must be sized to give 100% load support in case of a failover
312. The average CPU utilization of the environment must not go beyond 65%
313.
Solution should be sized so that it should have headroom of 100% CPU/Memory upgrade in
future. The database server should be vertically scalable while application servers should scale
horizontally


314. The application layer must be spanned over at least two different servers for load balancing

Minimum specification for other servers (web, management etc.)
Following are the specifications of blade servers for other servers:

315.
These should be 64 bit RISC/EPIC/X-86 (Intel/AMD) CPU with clock speed of 1.6 GHz or above with
industry standard 64 bit Operating System.

316.
Each Server must be populated with minimum 2 multi-cores with highest speed and FSB available
in the server family.

317.
Total number of CPUs and RAM size in all servers to be defined by the bidder as per application
sizing and to meet the performance SLAs.

318.
The blade server should have dual redundant 146GB internal disks in mirror mode or option of
boot from SAN.

319.
Virtualization Software License, allowing for hosting multiple Virtual Machines (VMs) on the
server. The virtualization software should allow for migration of VMs from one physical server to
another physical server.

320.
The blade server should be supplied with minimum 4 nos. of GbE or 2 nos. of 10GbE Ethernet
ports.

321. The blade server should be configured with minimum two 4 Gbps FC adapters or SAS ports.
322.
Each blade chassis should be sized so that it should have headroom of minimum 2 server blades in
future.

323. CD ROM Drive per chassis.
324. Management Module.
Blade Chassis Specification

325. Description
Should provide common resources essential for the Blade Servers
like Power, System Management, Cabling, Ethernet Management
and expansion, external Fibre Channel Storage switching and
connectivity & Redundant I/O Path for all fabrics

326. Midplane Should support passive or active midplane architecture
327. Blade Bays
Blade Chassis to accommodate minimum of 8 Full Height Hot Plug-
gable Blade Servers

328. Ethernet Switch Modules
Redundant Gigabit Ethernet/10GigE Pass-through modules for each
blade server

329. I/O Path for all Fabrics
Chassis should have dual I/O connections from every blade server
to help provide maximum uptime

330.
Fibre Channel Switch
Module
Should have redundant 8 GB fibre channel ports for each blade
server and Redundant hot-swap 8GB Fibre Channel SAN Switch
Modules with no single point of failure

331. Management Modules
Hot swappable management module to communicate with the
system management processor on the Blade Servers from remote
locations

332.
Total No. of Switch/Bridge
Module Slots
8 or above hot-swappable modules
333. Blower Modules Should have redundant and hot swappable blower or fan modules
334. Power Modules
Dual Power Supply to cater power for the blade servers
(redundant). No single point of failure for Power Delivery. No single
fault should take down the entire power bus. Should have N+N
power topologies for higher uptime

335.
Redundancy in Power
Chassis should have redundant fans and the power supplies and
should be able to provide reconfiguration of fans and power


Modules supplies without manual intervention
336. Form Factor up to 10U - 19" Rack mountable with 28" depth
337. CD/Diskette/USB
CD-ROM/DVD-ROM Drive which can be sheared among all the blade
servers. The chassis should have minimum Two USB 2.0 ports.

338. Failure Support
Pre-Failure or Post-Failure support for Blades, bridge/switch
modules, I/O modules, management modules, power modules,
blower/fan modules, media tray.

339. Diagnostics
Should support diagnostic features for Blade server, processor,
memory, power supplies, blowers, switch module, management
module

340. System Management
Should provide support for remote console management, power
on/off blades, should monitor power status, operating system,
temperature, disks, blowers/fans, power Modules, system
diagnostic programs provided through the Management Software

341. System Panel
LED/LCD panel to provide power-on, location, over temperature,
information and system error conditions

342.
Support for heterogeneous
Servers
The chassis should be able to support a mix of Blade Servers
RISC/EPIC/X-86(Intel/AMD)architecture processors

Storage
Minimum specification for Storage Array
343.
The storage array should be supplied with 250 TB usable capacity in a single array and expandable
to 1024 TB in future by addition of only racks, disks and disk enclosures.

344.
The storage should be a Monolithic Storage System(s) and shall support no single point of failure
features, such as Non- disruptive component replacement and hot-replacement of Interfaces, Disk


controllers, Disk drives, Cache memory cards, Micro-code, Power supplies, Battery systems, Fan
subsystems, FC controller and ports, etc. There shall be no significant performance degradation
due to any single failure in the enterprise storage.
345.
Storage-array should be top of the line product with all in-built redundancies to provide No Data
Transaction Loss because of any subsystem/component failure. Furthermore the storage system
should be tried and tested model in production environment for minimum of six months at the
time of submission of RFP.

346.
Storage-array should support zero data loss after committing the write operation to the
application.

347.
The Storage Array should be configured with minimum 256 GB of Cache GB. Additional Cache, if
required based on the proposed solution should be supplied and configured accordingly

348.
Storage system should be configured with at least 32 Backend FC or SAS Disk ports (towards disks)
and at least 32 front end FC/SAS ports (towards FC switch) scalable to 64. Each front-end port in
the storage array should have dedicated processor or cores for delivering high throughput and I/O
performance.

349.
The Storage Array configuration should be sized to deliver minimum 50000 SPC- 1 IOPS at an
average response time of 2ms or less. CSI should also specify the SPC-1 IOPS per disk that can be
achieved with the Storage Array. The Storage Array bandwidth should be at least 3GBps rated as
per SPC-2 benchmark. Performance numbers if not available or published need to be certified by
manufacturer's parent company lab along with detailed lab test report. Storage should be
minimum sized for asked performance workload or as per proposed solution requirement
(whichever is higher)

350. The storage array should support flash/solid state disks.
351.
The array should support automated storage tiering and movement of data within different tiers
of storage namely SSD, FC/SAS and SATA disks without requiring user intervention, depending on


the frequency or pattern of the accessed data.
352.
Storage should be able to work in a heterogeneous environment which may include multi-vendor
storages such as Sun, IBM, HP, EMC, Hitachi etc.

353.
Storage system should be configured with LUN masking software and license for all LUNs created
on the storage system.

354.
The storage array should support native front end connectivity options such as Fibre Channel,
FICON. The array should also support Gig-E for remote replication.

355. The storage should have separate dedicated data signal path and control signal path.
356.
The storage array should be supplied with Thin Provisioning / Virtual Provisioning. Requisite
software licenses should be provided with the storage system for the entire proposed capacity.

357.
The Supplied array should support features like Cloning and Array based remote replication. The
array should be supplied with license of the mentioned software for the entire capacity
configured.

358.
Storage System should support at least RAID 5/6 and RAID 1/0.Mix and match of disks types &
RAID levels shall be supported.

359.
The enterprise storage arrays should be configured with latest disks with data storage in RAID
levels mentioned below:
Minimum 10% of usable capacity shall be on Solid State Disks in RAID 5
Minimum 50% on FC/SAS disks in RAID 1/O
Minimum 40% on SATA disks in RAID 6
The usable capacity is defined as the Net storage capacity available for the application stack, after
deducting the penalties imposed by storage infrastructure requirements, disk and array
formatting, RAID penalties, host OS and file system formatting including overheads for directory
structure and inodes etc or any other penalties which eat away usable disk space. The disks should


be enterprise class disks built for 24 x 7 operations.
360.
Storage Array should support both Spanning and Striping of volume across minimum of 32
channels in active- active configuration.

361.
The storage should support authentication security control, by user and role in order to avoid
unauthorized service actions.

362.
The storage array should support latest versions of operating systems like Linux (RHEL and SUSE),
Windows, Unix (AIX / HPUX / Solaris etc.).The storage system should offer exhaustive support for
all industry leading cluster systems.

363.
The data in cache shall not be lost in case of power failure even in extended power outages. In the
event of power failure, data for total cache supported by the storage array should be safely
written to the disks and system shall perform a graceful shutdown.

364.
The storage system should have proactive maintenance like self monitoring, self-diagnosing and
wherever possible, self-repairing features.

365. The array should support capability to replicate data to a remote site using storage controllers
366.
Suitable rack enclosures from the array manufacturer need to be included for the complete
storage solution.

367.
The storage system should be configured with GUI-based storage management software tools for
management. A single command console should be used for the entire storage system for all
functionalities like SAN & Storage configuration and management, performance monitoring and
reporting analyze performance data, generate customized reports. The software applied should
be capable of monitoring 3rd party storage arrays in a heterogeneous environment as well.

368.
The CSI should quote all the applicable set of management licenses for the offered SAN and
Storage for the entire capacity configured.

Minimum Specification of SAN Switches

369.
SAN switch should be of director class with 128 ports populated and active. Should have non-
blocking architecture and scalable to 256 ports in a single domain with 8Gbps full duplex with no
over subscription with local switching. Two nos. of Fibber channel switch should be provided in
high availability mode.

370.
Should support 4 GB FC ports and also support 1Gig and 10 Gig Ethernet ports for remote
replication in future.

371.
Switch should support multiprotocol architecture such as FC, FICON, FCIP and emerging protocol
such as Converged Enhanced Ethernet (CEE) and Fibre Channel over Ethernet (FCoE).

372.
SAN Switch should have equal performance from any port to any port on the director for
consistent performance.

373. All the ports should operate at 8Gbps and auto-negotiate to 4Gbps/2Gbps / 1Gbps FC speeds.
374.
All the components should be hot swappable field replaceable units allowing non disruptive
maintenance

375.
There should not be any single point of failure in the switch. The SAN switch should provide
Enterprise-class availability features such as Dual-redundant control processors, redundant hot-
swappable power and cooling subsystems. Power supply and fan assembly should have different
FRU.

376. The switch shall support different port types such as U_Port, FL_Port, F_Port, E_Port, and EX_Port.
377. Non disruptive Microcode/ firmware Upgrades and hot code activation.
378.
It should be possible to isolate the high bandwidth data flows traffic to specific ISLs/trunks by
simply using Zoning.

379.
Switch should support Virtual Fabrics feature that enables partitioning of a physical SAN into
logical fabrics and isolation by application, business group, customer, or traffic type.


380.
Cascading of two SAN switches should be possible from any port in any module across the
Director

381.
Switch should provide advanced zoning capabilities and allow health and performance monitoring
capabilities. Support for web-based management and should also support CLI.

382. Should have proactive fault detection and alerting capability to avoid any hot-spots in the fabric.
383. The switch should be rack mountable.
384.
Provide Adaptive Networking services such as Quality of Service (QoS) to help optimize application
performance in consolidated, virtual environments. It should be possible to define high, medium
and low priority QOS zones to expedite high-priority traffic.

385.
It should be possible to configure any port in the switch for Fibre Channel Integrated Routing
mode for selective device sharing while maintaining remote fabric isolation or higher levels of
scalability and fault isolation.

386.
It should be possible to configure the switches with alerts based on threshold values for
temperature, fan status, Power supply status, port status.

387.
Switch should support diagnostics features such as port mirroring (SPANport), Syslog, Online
system health, Port-level statistics etc.

388.
Introduction of application blades/storage service cards should not impact the port throughput or
total available ports in the remaining slots of the switch chassis.

389. Throughput of the each switch should be 1024 Gbps or more
390. Should provide 15M LC-LC cables for all the ports.
Minimum Requirements of FC IP routers
391.
At least two routers should be provided at each location. The design should support failover using
redundant configurations, ensuring that in case one of the routers is down, the traffic can flow


through the other router. Actual requirement would be as per the bandwidth requirement of
WAN link to storage infrastructure. In case additional routers are required based on the
requirement of bandwidth sizing for asynchronous storage based remote replication over IP; the
same should have to be proposed additionally.
392.
The proposed FCIP router could be standalone or as part of proposed SAN Switch as a separate
module within the SAN Switch

Tape Library
393. The tape library shall be used for storing backup and the aged data as per the policy of DOP
394.
The Tape Library Unit shall be configured with fibre based Tape Drives, and shall be quoted with
the requisite number of drives and slots as per the dimensioning parameters given in this
document.

395.
It should be possible to take the tapes out of the library without losing their contents so that
monthly/quarterly backup copies may be preserved outside the tape library.

396.
The Tape Library Unit should be configured with fibre based Tape drives, having the following
specifications and features.

397. The Tape drives should have capacity of at least 1600GB / 3200GB (uncompressed /compressed)
398.
The Tape Library should be quoted with the requisite no. of slots as per the dimensioning
parameters given in this document for each data centre.

399.
Each of these Tape Libraries must be supplied with minimum 12 drivers and should be scalable
upto minimum 40 drives and at least 3000 slots. Scalability of the number of drives and slots can
be delivered through multiple tape libraries.

400.
The Tape library should be capable to allow addition of slots, add or remove tape drives and
updates of the librarys microcode without scheduled downtime. There should be dual path for
each drive in the library in failover and load balance mode. In case of a path failure, data should


be able to transfer through alternate path.
401.
The tape library should be configured with at least one robot per tape library to address all the
slots in a redundant configuration

Tape Library Specifications
402. Data cartridge capacity 1600 GB / 3200 GB (uncompressed /compressed)
403. Library connectivity 4 Gbps or higher fibre channel
404. Number of drives At least 12 drives
405. I/O slots At least 16 I/O slots
406. Tape Cartridge slots At least 280
407. Virtualization Support for at least 12 logical drives
408. Management Remote, Web browser-based management
409. High Availability Dual Power Supply, Data path failover and load balancing

Disaster Recovery Requirements
The following are minimum requirements and bidder shall propose the solution which is required
to meet the following RTO and RPO requirement as per SLA mentioned in Volume I:

410.
The bidder shall commence supply of DR hardware and software only after successful go-live of
pilot phase or as agreed with DoP.

411.
The hardware and software supply at DR should be equivalent to primary
Data Centre however vendors shall highlight the areas (especially in software license) if duplicate
component is not required at DR. The entire environment at disaster recovery should be
maintained as a full working copy of primary data centre.

412. CSI should supply necessary replication software and disaster recovery management software for

replication between DC and DR
413.
Proposed storage system should be capable of doing data replication between similar storage
systems in synchronous or asynchronous mode. Storage system should be capable of supporting
3-Stage DR if required in future.

414.
Replication software should support data consistency at the respective DR in all eventualities like
link failures, controller failures etc. The method for data consistency should be clearly explained in
the bid.

415.
The hosts connecting to the storage arrays with 2 or more HBAs shall be configured with specific
software for HBA load balancing, multi-pathing and auto failover.

416.
This software should allow multiple path I/O capabilities from the Host and also have the ability to
automatically detect and recover failed paths.

417. It should provide dynamic load balancing and automatic path failover capabilities.
418.
The HBA load balancing and redundancy software should be supplied for the maximum number of
hosts supported in the Storage Array and should also be configured to support the maximum
LUNS supported in the Storage array as a one time configuration.

Security Requirements
Overall Solution requirement:
419.
CSI must ensure that the proposed Security architecture is based on industry best practices and
adheres to the security standards such as ISO 27001, Information security standards framework
and guidelines standards under eGovernance standards (http://egovstandards.gov.in),
Information Security guidelines as published by Data Security Council of India (DSCI) and shall
comply with IT (Amendment) Act 2008.

420.
To achieve the security goals for solution, DoP aims to deploy a multi-layered detailed security
system covering the overall solution needs. Following security solutions are not part of this RFP,


however, CSI is required to propose complete security architecture required for their solution
after considering the following solution:
Two layers of Firewall in HA
Network IPS
Fraud Management System for Banking
CSI must ensure that the security solution provided must integrate with the overall security
architecture and solutions of DoP.
421.
To maintain confidentiality, integrity and appropriate access to information, CSI must ensure and
incorporate all necessary security and control features for the following:
Databases
Networks (web security etc.)
Operating System
Any other solutions as proposed by the CSI

422.
It will be the responsibility of the CSI to work closely with the other System Integrators such as FSI,
Network Integrator, Data Centre etc. to ensure that the solution provided gets integrated with the
overall DoP technology architecture including information security architecture and with the
solutions mentioned under each section.

423.
CSI must ensure complete information security of the solution provided, and must ensure that any
other solution required besides those mentioned under Security Requirements (Section 4.3 of
Volume I of this RFP) must be considered as part of the SIs solution

424.
Monitoring & Audit: Compliance with security best practices may be monitored by periodic
Information Security audits / assessments performed by or on behalf of the DoP. The periodicity
of these audits / assessments will be decided at the discretion of the DoP. These audits /
assessments may include, but are not limited to, a review of: access and authorization procedures,
physical security controls, backup and recovery procedures, and program change controls. To the
extent that the DoP deems it necessary to carry out a program of inspection and audit /


assessment to safeguard against threats and hazards to the confidentiality, integrity, and
availability of data, the CSI shall provide the DoPs representatives access to its facilities,
installations, technical resources, operations, documentation, records, databases and personnel.
The CSI must provide DoP access to various monitoring and performance measurement systems
(both manual and automated). DoP has the right to get the monitoring and performance
measurement systems (both manual and automated) audited / assessed without prior approval /
notice to the CSI.
425.
Security Architecture Guidelines
As part of the overall India Post 2012 initiative, DoP aims to deploy a multi-layered security system
to protect critical digital assets of the organization.
To address security at web and delivery channels like Advance Financial Systems (AFS), CSI needs
to follow the below-mentioned architecture guidelines:

426.
The solution should be based on well known/popular Open Standards with no single point of
failure to facilitate seamless integration with surrounding systems, applications and delivery
channels etc.

427.
Data pertaining to enrolment process, transaction process as well as the data that is stored at
various points needs to be appropriately secured as per minimum standard 128 Bit AES/3DES
encryption.

428.
The proposed solution architecture should be compliant with security regulations / standards /
guidelines issued by Government of India

Application Security requirements of the proposed application for banking and insurance
The CSI must adhere to the following application security requirement while proposing the
solution.

Access/authentication
429. The proposed solution must have capabilities to define user profiles (Capabilities/ Rights).

430.
The proposed solution needs to facilitate creation of the user IDs at a central level / distributed
level as desired by the DoP.

431.
The proposed solution must have capabilities to attach the user ID to each and every action done
by the user in the system.

432.
The proposed solution must have capabilities to check for duplicate record based on criteria such
as user name (first + last name) etc.

433.
The proposed solution shall be compatible with external two-factor authentication systems, which
DoP may decide to deploy later.

434.
The proposed solution should support creation of temporary user ID's and access rights based on
number of days, months restrictions or time based restrictions (minutes, hours).

Password Requirement
435. The proposed solution should set a default password upon creation of the user ID.
436.
The proposed solution should allow the DoP to define password policies. The minimum password
policies to be defined are:
Minimum/ Maximum password length
Alpha numeric combination of password
Compulsory use of special characters
Minimum password age
Password expiry period
Repeat passwords etc.

437.
The proposed solution should be able to automatically check the passwords with the password
policy, which can be customized by the DoP.

438.
The proposed solution should enforce changing of the default password set by the system (at the
time of creation of user ID) when the user first logs on to the system. The proposed solution


should enforce all password policies as defined at the time of first change and thereafter.
439.
The proposed solution should store User ID's and passwords in an encrypted format with
passwords encrypted using minimum MD5 hash algorithm.

440.
The proposed solution needs to define overrides for certain set of transaction errors / warnings
and link transactions to specific user IDs. All such overrides should be recorded for Audit trail.

User Group Creation
441. The proposed solution should be able to form user groups and link rights to such defined groups.
442.
The proposed solutions should be able to restrict user access to:
Menus
Sub- menus
Screens
Fields
Reports
Combination of the above

443.
The proposed solution should perform all restrictions & accesses at the Central level only. Solution
must have a mechanism to enforce such restrictions & access when the proposed systems are
accessed in off-line mode.

444.
The proposed solution should have all restrictions to be placed within the application with the
help of menu driven options.

445.
The proposed solution needs to define levels of authorisation, based on user profile/access level
granted. For any sensitive data access / transaction or the privilege use access, the solution
should ensure minimum two levels of authorization.

446.
Data in Transit
The proposed solution should be capable of encrypting the password / other sensitive data during


data transmission.
447.
Audit logging:
The proposed solution should be able to generate audit trails of all transactions. The minimum
fields that should be captured in the audit trail are:
Date & time stamp
Transaction ID linked to every transaction / activity. Transaction ID has to be unique and
should not be duplicated. Further the transaction ID should be generated whether the
transaction is successful, unsuccessful / rejected.
User ID
Authorised By
Overridden By

448.
The proposed solution should allow users to define error messages (parameterisable) for a
particular transaction.

Access restriction to critical accounts
449.
The proposed solutions must have capabilities to restrict access to critical accounts / information
to a particular user ID / or a group of user IDs.

450.
The proposed solutions should not allow any changes to be made to the details of the transaction
after authorization.

451.
The proposed solutions should not permit the same individual to modify and authorize the same
transaction.

452. The proposed solution should only allow authorized personnel to change global parameters.
453.
The proposed solution should define Maximum Inactive Time (parameterisable) after which a user
should be automatically logged out of the system.

454.
The proposed solution should have the capability to suspend or cancel an inactive user ID after a


defined time frame.
455. The proposed solution should have the capability to reactivate suspended user Ids.
456.
The proposed solution must have the provision to assign a user ID with highest access level for
querying with no financial transaction authority.

457.
The proposed solution should support tracking of all system administration activities within
appropriate system log.

458.
The proposed solution should report active users in the system on different parameters such as
location wise, group wise etc.

459.
The proposed solution should have Log report of users logging in & out of the system throughout
a period of time.

460.
The proposed solution needs to support validation of user ID and password with customized
dictionary for rejections.

461.
The proposed solution needs to support defining separate menu options with view / query
options for auditors, non-operational staff.

462.
The proposed solution needs to support geographic region wise, branch wise, and account type
wise, transaction type wise facility for fixation of counter/single window limits.

463.
The proposed solution should support monitoring from a remote place (Data Centre/SOC) on the
activities performed by users in various locations.

464.
The proposed solution should parameterise different business hours, working hours, weekly offs,
holidays etc. for different locations.

465.
The proposed solution should track the changes made in parameter files along with detailed audit
trail.

466.
Reports: The proposed solution should generate reports for login access, staff with multiple level


accesses; functionality based access; use Ids disabled, suspended, cancelled users.
End Point Security Solution
467.
In order to prevent DoPs network against the threat of viruses, worms, SPAMS, DoP plans to
implement a comprehensive Anti-Virus software solution which shall provide continuous
protection against these threats across all infrastructure layers of network including desktops,
gateways i.e. emails and internet /Web. It will be the responsibility of the CSI to maintain the
overall solution and report the endpoint upgrade/update status and any failures. CSI must work
with different solution providers across multiple circles for deployment of the agents on the
respective end-points.

468.
The proposed solution should be able to block devices based on Windows Class ID and should
include USB, Infrared, Bluetooth, Serial, Parallel, fire wire, SCSI and PCMCIA. Solution should also
be able to block and give read/write/execute permission for mentioned devices.

469.
Proposed solution should be able to deploy flexible and different security policies depending upon
the AND/OR relationship of following network triggers e.g. IP address (range or mask) , - DNS
Server , DHCP Server , WINS Server , Gateway Address , TMP Token Exists (hardware token) ,
DNS Name Resolves to IP, Policy Manager Connected, Network Connection (wireless, VPN,
Ethernet, dialup).

470.
Proposed Anti Spyware solution should be able to bypass Windows File System and should have
Direct Access to NTFS Volume to provide raw Disk Scan for superior Root Kit protection.

471.
Antivirus and Antispyware policy can have options by default to choose High Security and High
performance to have a right balance while deployment in the production network.

472.
The Host-based, self-enforcement - It should use a desktop firewall (built into the agent) to
permit or deny managed endpoints access to the network. This method should offer the fastest
and easiest implementation as it requires: No infrastructure changes and no additional
deployment efforts.


473.
System Lock Down - it should be able to Lock down the system by fingerprinting every
executable file on the system. It can then monitor all running applications and terminate any
application for which the agent does not have a matching fingerprint ensuring application based
control.

474.
If the host is non-compliant with security policies, Agent can automatically initiate a restoration
action, which can include running command line, downloading and executing/inserting a file,
running scripts, remediating by setting required registries keys, rechecking the host for
compliance, and ultimately granting access for the compliant host to the network.

475.
Solution should have a readymade template able to check & enforce if Microsoft
service/WSUS/SMS is installed, running, install waiting packages, checked for new packages in
defined duration.

Anti Virus and Anti SPAM solution for email messaging should include
476.
Proposed Antivirus, Anti SPAM solution should be for the SMTP gateway and as well as for the
messaging servers (Messaging servers as proposed by the bidder). This protection should include
content filtering.

477. The proposed solution should be able to filter for viruses and SPAMs for SMTP traffic.
478.
The proposed solution should have signature technology that eliminates randomization and
HTML-based filter evasion techniques.

479. The proposed solution should provide anti-Spam capabilities against multiple languages.
Antivirus and URL filtering Web Gateway solutions should include
480.
The solution must protect DoPs against latest web threats, including malicious URLs, spyware,
botnets, viruses, and other types of malware, and provide controls for web and application use.

481.
The solution should have flexible deployment options including port SPAN / in line / in line with
proxy etc.


482.
The solution must provide multi-layer Inspection including network packets, URLs/IPs, files, active
content, applications, behaviour, all ports and protocols (both inbound and outbound).

483.
The solution must provide multi Layer Malware protection including Malware web domains
(http), Malware IP domains (anything over IP), Content Filter Malware categories (Malware,
Phishing, etc.), Malware Content Scanning, Malware Scan , Detection of Compromised endpoints ,
Infected Client Detection - Network Fingerprinting, Botnet Detection - Behavioural Modelling.

484.
Application Control The solution must Inspects all internet bound traffic for popular web
applications - Signature Based, and should not be reliant only on ports.

485.
Protocol Support - Should provide fast protection at the gateway across multiple protocols for
inbound and outbound web traffic.

486. Performance - The solution should offer zero latency (less than 2ms).
487.
Botnet Defense The solution should have in-built intelligence & co-relation capability to inspect
for, detect, and block active and dormant botnet activities with in the network endpoints.

488.
Application Control - The solution should have advanced application control capabilities with
ability to monitor and control usage by end-users spanning multiple applications.

489.
Internet Application Blocking - The administrator should have feature to prevent peer-to-peer
sharing, streaming media, games, and other Internet applications from accessing the Internet.

Security Information & Event Management System (SIEM) Requirement:
490.
Security Management in DoPs network is very critical as various security devices and servers will
generate thousands of security logs which need to be analysed and correlated. Hence, there
should be a mechanism to monitor, correlate and notify Security incidents in the DoP network to
remediate them immediately. Along with this, the solution should provide a mechanism for
comparison with best practices such as ISO 270001.

491.
The solution should have the capability of collecting the log in real time and storing it in raw


format with no further modifications done on the logs.
Log Analysis & Storage:
492.
The SIEM solution must integrate with all the server operating systems, network and security
devices and allow one single global view of all the collector devices and sites across DOP
infrastructure.

493.
The log generated should be stored in a centralized storage. The period up-to which the data must
be available should be customizable. There must be archival facility through which the old log data
can be pushed to an external device like SAN, NAS, DAS.

494.
Log Monitoring: The solution must facilitate monitoring and review of the log data and should
have automated analysis facility. Log monitoring feature should have facility to generate reports.
Facility must be there for management of the log server(s) and clients. The software must have
user management facility with privileges restricting access to limited resources. Alert facility must
generate automatic alert notification based on specific events.

495.
The solution must aggregate, normalize, correlate and analyze event log data from the multiple
devices within DoPs infrastructure. It must collect all the data sent from the device, compress and
encrypt log data on the centralized storage.

496.
The system should have the correlation capability. The system should be updated with new
correlation rules based on new identified attack patterns and threats.

497.
Log management infrastructure should perform several functions that assist in storage, analysis
and disposal of log data. These functions should function in such a way that the original logs
should not be altered. The log management infrastructure should have the following
functionalities:

General
498.
Log Parsing The solution must ensure that any Log parsing activities should not alter the raw log


in any format.
499.
The solution must provide a mechanism wherein Logs may be normalized and reformatted for
reporting and correlation.

500. Event aggregation should preferably happen at the time of co-relation.
Storage
501.
The logs should be encrypted when stored and solution must provide a mechanism for integrity
checks.

502.
The proposed solution must provide Log archival facility which allows retaining of logs for
extended period.

503. The solution must provide support for defining different retention periods for different devices.
504. The SIEM solution should be capable of integrating with a GRC solution.
The solution should support SAN, NAS and DAS for external storage.
505.
The solution must provide target device notification if target device is down or no longer
sending/receiving events.

506.
The proposed solution should have the capability to provide detailed analysis of security incidents
occurred and recorded by the solution.

507. The bidder must provide appropriate storage based on complete requirement of monitoring.
508.
The solution must provide correlation support correlation support but not limited to - Rule Based,
Behaviour Based, Vulnerability based, User defined, Baseline based.

Reporting
509.
The system should have out-of-the-box reports for supported devices and compliance standards
for the supported devices. The reports should include standard security analysis reports and


graphs. Any newer reports published by the vendor should be made available for use at no extra
license, it is expected that newer reports published are provided on a monthly basis for use within
DOP.
510. The reports should be available in minimum PDF and CSV format.
511.
The system should have the capability to Schedule Reports using emails on daily, weekly and
monthly basis.

512. Scheduled reports should be available for viewing if desired in future.
513.
The solution should provide a process for creating ad-hoc log queries. This process should use
standard syntax such as wildcards and regular expressions and It should provide mechanism to
allow saving queries.

514.
Any reports that are available out-of-the-box or any customization performed on existing reports
should not require any separate licensing.

Identity and Access Management System
Scope of the solution will cover the following Scope
515.
Comprehensive and Integrated Identity and Access
Management Solution for Identity Management, Web
Access Management, Web SSO, Enterprise Single Sign-
On
Identity and Access Management for all
Internal users, Web SSO and Web Access
Management for external as well as
Internal users

516.
Comprehensive Identity Management, Provisioning,
and Password Management Solution
For all Internal users

517.
Comprehensive Web Access Management and Web
Application Single Sign-On Solution
For all Internal as well as external users

518.
Comprehensive Single Sign-On solution to access Web,
For all Internal users

enterprise and legacy applications
519.
Comprehensive LDAP v3 directory with X.500
distribution and replication services to deliver a
backbone of servers that have the capacity to scale to
hundreds of millions of entries, to store all identity
information and associated resources.
User store for all Internal as well as
external users

520. Functional Requirements for the Identity and Access Management Solution
521.
The Identity and Access Management solution should consist of Identity Management,
Provisioning, Password Management, Web Access Management, Web SSO, and Single Sign-On for
thick client applications and Server Access Control must provide out-of-the-box integration among
the various sub components.

522.
The bidder must provide reference able case studies for Web Access Management Solution for
millions of user deployments (minimum one case study to be submitted).

523.
The solution must provide out-of-the-box Universal Single Sign-On across Web and Client Server
applications.

524.
The proposed Identity and Access Management solution must also integrate with applications for
Mail operations, Logistics post, e-Commerce, Postal banking operations, postal life insurance,
Human Resources and notification systems like e-Mail, Helpdesk system etc.

525.
The proposed Server Access Control solution should be able to protect critical server
infrastructure and minimize security risks by regulating access to confidential data and mission
critical services. The solution should provide policy-based control of who can access specific
systems, what they can do within them, and when they are allowed access. Specifically, it should
proactively secure access to data and applications located on Linux, UNIX and Windows system
servers throughout the infrastructure.

Technical Specifications for the Proposed Identity & Access Management System

526. The proposed solution should allow bulk loading of user data.
527. The proposed solution should support for 'Separation of Duty'.
528. The solution should support RBAC model.
529. The proposed Identity and Access Management System must provide the following features:
530.
The proposed solution must provide centralized administration of user-ids and password
management.

531. The proposed solution must provide support for user store on a central LDAP or an RDBMS.
532.
The proposed solution must provide a central directory of users, their real-world business
information, their accounts, and their access rights across the enterprise without requiring
changes to end-systems.

533.
The proposed solution must allow accounts on end-systems to be discovered, and linked to users
within the administration utility, which can be subsequently used as the single point of
administration.

534.
Cross Platform / Application - Must provide easy and cost-efficient administration of users and
resources across enterprise security systems and directories.

535.
Scalable - Must be scalable, open, extensible, and built around standards-based LDAP/X.500
technology.

536. Audit - Must provide a consolidated audit trail of administrative operations.
Other Requirements
537.
The proposed solution must have APIs to enable additional user management operations on UNIX,
Linux and over and above the default operating system account set-up.

538.
The proposed solution must have LDAP interface to enable queries/updates by authorized third-


party customer tools.
539.
The proposed solution must support enforcement of a centrally-defined security policy, e.g. for
access rights, user names, password lengths.

Role-based Administration
540.
The proposed solution must provide access rights based on job function to support
implementation of role-based administration.

541.
The proposed solution must have a web-interface for simplified user administration that can be
used by HR, business managers to introduce and delete users, and assign them to job functions.

542.
The proposed solution should be able to integrate with HR application, CRM application so as to
enable creation of user ids based on data fed to CRM and HR applications.

543.
The proposed solution must allow users to access critical data through a single, secure login, while
reducing security/password administration.

544.
The proposed solution should have an embedded work flow which would help in automating
routine tedious tasks like approval processes.

545.
The proposed solution must provide advanced Web support, to allow for smooth access and
personalization of the user interface for each user. Once a user has been authenticated to the sign
on system, access to all authorized Web applications and resources must be handled by this
system.

546.
The proposed solution must provide access to only those applications/resources that the
user/customer has authority to.

547.
The proposed solution should provide capabilities to perform recertification of identities across
the Enterprise.

548.
The proposed solution should provide capabilities to perform Identity Auditing for entitlement


violations and validations.
549. The proposed solution must have Out-of-Box integration with Web Services.
550.
The proposed solution should provide capabilities to have Corporate Directory as well as
Provisioning Directory.

551.
The proposed solution must provide capabilities to ensure if a user is authenticated at a low level
of security (e.g., password), then they should be forced to re-authenticate when they attempt to
access a more sensitive resource (e.g., one protected by a token card).

552.
Priority of these authentication methods should be Administrator specified. It should not be hard-
wired into the product and Administrator should be able to control the priority of each
authentication method.

553.
The proposed solution must provide feature to ensure that the User should be permanently (until
re-enabled) disabled from using the system.

554.
The proposed solution should supply significant password management services such as
expiration, min/max lengths, forgotten password support, lock-out, customizable composition
rules, editable password dictionary, etc.

555. The proposed solution should support both session and idle timeouts on a per-resource basis.
556.
Administrator should be able to specify rules for generating and rolling over encryption keys (e.g.,
periodically, or upon command).

557.
Authentication management system should be capable of supporting automated fallback to
alternative authentication systems.

558. The proposed solution should support directory chaining.
559. The proposed solution should provide protection from cross-site scripting.
560. The proposed solution should support time or location-based policies.

561.
Administrator should be able to create a policy for any user, any group (including dynamic
groups), any role, or even any ad-hoc set of users who share certain attributes.

562.
Administrator should be able to create a policy that includes a group of users, with the exception
of certain individuals.

563.
Administrator should be able to integrate dynamic/external data (at run-time) in the enforcement
of my policies via a Web service.

564.
Administrator should be able to create policies that perform comparative tests on each users
directory profile information.

565.
The proposed solution should support controlled impersonation of users allowing certain users
to temporarily use the entitlements of other users without sharing of passwords.

566. The proposed solution should support fine-grained control of access to file, page, or objects.
567.
The proposed solution should redirect the user to different web pages based on the type of failed
authentication or authorization that occurs.

568. The proposed solution should support full replication of all components.
569. The proposed solution should support automatic failover and failover between clusters.
570. The proposed solution should do dynamic load balancing across all servers.
The proposed solution should also load balance across directories.
571. The proposed solution should have extensive caching capabilities.
572.
The proposed solution should provide 2nd-level caching, so that recently used policies are
separated out into a separate cache. And these caches should be tunable for each environment;
also the caches should be either flushed or refreshed on administrator command.

573. The proposed solution should enable or disable logging without restarting the server.

574.
The proposed solution should enable all agents to be managed from a single administrative
interface. If so the shared secret keys should be automatically rolled-over on some predefined
schedule.

575.
The proposed solution should support policy information be stored directly in LDAP, so that a
single directory can be used to store both user and policy information.

576. Administrator should have full flexibility about where to store both user and policy information.
577. The proposed solution should allow integrating with home grown unique authentication methods.
578.
There should be an API to allow easy integration of business logic into the policy enforcement
decisions. e.g., policies based on the content of dynamic user data.

579.
The proposed solution should use the policy enforcement capabilities of the product to manage
security for custom developed application and it should enforce policies based on any generic
resource, not just Web-based.

580. There should be an API that supports access to the password attributes in the directory.
581. The proposed solution must provide API that should support workflow capabilities.
582.
There should be an API for custom agents and also an API to allow custom directories to be used
for user storage.

583.
The proposed solution must manage access to applications maintaining unique credentials for
each application per user, eliminating the risks associated with password synchronization
(Applications within the organization may have password strengths defined based on their
sensitivity. Hence each application should continue to have a password as per the password
strength post the implementation of Single Sign-On too).

584.
The proposed solution must log users into any resource requiring a sign-on including banking
application, email, databases applications, web-enabled applications (DoP may have a mix of
Client Server, Legacy and Web applications. The solution must provide capabilities to manage all


environments from access management perspective).
585. The proposed solution must integrate with the Web SSO out-of-the-box.
586.
The proposed solution must control the number of sessions a user may have open simultaneously
on one or more workstations.

587.
The proposed solution must ensure all user credentials are encrypted in storage and in transit
between all components of the system (since the system deals with sensitive information like the
user credentials, it is needed that the information is encrypted in storage as well as in transit
between all the components of the system).

588.
The proposed solution must provide capabilities to re-authenticate users before running sensitive
applications (Organizations can identify applications that are sensitive from a security or other
perspective, and require the user to re-authenticate before running such applications).

589.
The proposed solution must include an embedded high performance X.500 directory / RDBMS to
provide unparalleled scalability supporting millions of users.

590.
The proposed solution must support Offline mode functionality to allow users to login to
applications even when the SSO server is not On-line. Offline mode must only be available for
those applications identified for use in the offline mode by the security administrator.

591.
The solution must provide a centralized policy /role driven control over authorization to access
applications.

592.
The logon scripts, policies and the logs stored on the server must be proactively protected by an
access control module.

593.
The proposed solution must support server farms to distribute load among multiple servers
providing scalability.

594.
The proposed solution must provide Personalized Application List to users (Users must be
presented an exact view of the applications they have permissions to use).


595.
The users application list must be automatically refreshed eliminating the need to re-authenticate
when application availability changes.

596.
Must have an option to extract user information like last successful login, last password change,
which application, how many users are using etc.

597.
Host-based Server Access Control System (HSACS)
The HSACS is a centralized system that controls access to the servers, file systems and databases
in the Data Centre. The solution must cover all systems which are proposed by bidder under the
scope of work mentioned in the RFP and additional systems as procured under FSI RFP. The
specifications of the SACS are as follows:

HSACS solution must cover all critical servers at Data Centre/DR as well as other critical servers
598.
The HSACS shall control access to all server system (Unix, Linux and Windows) resources including
applications, data files, devices, processes/daemons, and audit files.

599.
The HSACS shall intercept security-sensitive events in real-time, and evaluate its validity before
passing control to the OS.

600.
The HSACS shall make no changes to the operating system kernel or binaries. Software must allow
for quick uninstall, if necessary.

601.
The HSACS shall allow controlling actions and access to resources of all users including privileged
accounts such as root / administrator.

602.
The HSACS shall provide the ability to designate specific roles like Administrators, Auditors, and
Password Managers etc with appropriate rights. It must also provide the ability to designate
specific users as Subordinate or Group Administrators, to manage users and file permissions for
their group.

603.
The HSACS shall provide complete file protection by intercepting every file access request and
deciding if the user is authorized to access the file.


604.
The HSACS shall enable administrators to designate critical files that when changed or modified,
shall generate a suitable alarm and write an audit record.

605.
The HSACS must support creation of rules for access permissions to various file systems on per
user and group profile basis.

606.
Users shall be allowed to access the system resources as per the day and time pre-described in
the system.

607.
The HSACS shall support management and policy distribution across multiple platforms (Linux,
UNIX and Windows) from a central management console. It must support the deployment of the
same policies across multiple servers ensuring consistency of security policies.

608.
The HSACS shall support audit trail of all access activities. It shall track user logins, logouts access
to resources and track user names from initial authentication to create secure and useful audit
trails with full integrity. It shall provide a monitoring mode to record activity of specific users.

609.
The HSACS shall provide simple to use graphical interface to enable complete management of all
user, group, resource, audit and policy settings, either centrally for an enterprise or de-centralized
to departments or business units.

HSACS User management
610.
The HSACS shall provide the facility to set accounts to expire on specific dates, deactivate
accounts on a configurable date or after a configurable amount of inactive time, lock out accounts
after multiple failed logins through a daemon, restrict accounts logins during configurable times
and days, deny access to accounts based on company holidays.

611.
The HSACS must ensure that users permissions must always be governed by the original login ID.
Taking over the root account should not grant the user any additional privileges.

612.
The HSACS shall enable the administrators to share subsets of root authority among different
administrators based on their functional roles.


613.
The HSACS shall make it possible to automate the creation of complex security policies with point
and click options including control over logins, password quality, user and group access, system
files, attack prevention, network and environments.

614.
The HSACS shall enable fast addition, change, deletion and modifications to users and groups
across platforms, including synchronization with native operating system settings.

615.
The HSACS shall allow controlling actions and access to resources of all users including privileged
accounts such as root / administrator. Must track the "real user" even in case of surrogates.

616.
The solution should provide a feature to eliminate passwords from scripts. Via PUPM, it should be
possible to replace hard-coded passwords in scripts with privileged account passwords that are
generated by PUPM only when needed. The solution should provide a unified web-based console
which consolidates all aspects of privileged user management under a single console host
access control and privileged user management across physical and virtual systems, devices and
applications.

617.
The solution must provide support for IPv6 and FIPS140-2 and must provide Services and Registry
Values Protection.

618.
Two Factor Authentication tokens
Two factor authentication tokens will be used to provide two layer of authentication for system
administration and critical user accounts. It will be bidders responsibilities to work with different
solution providers to deploy the solution and provide support for integration.

619. The solution must provide time-synchronous authentication technology.
620.
The solution must support a PASSCODE (combination of a 4 8 digit numeric/alphanumeric PIN
and a pseudorandom token no.) using AES or 3Des algorithm.

621. The hardware token should be tamper proof and not have any changeable parts.
622.
The solution must have authentication support based on the current Universal Coordinated Time


(UCT) and a supported time buffer.
623.
The solution must provide offset correction that is automatically synchronized to Authentication
Server.

624.
The solution must support for a multi-tier architecture comprising end user authenticator, target
application / device Agent and an Authentication Server

625.
The solution must provide encrypted communication between the components including the
primary and failover servers with the encryption key to change every few minutes.

626. The solution must provide multi platform support for the authentication server.
627.
The solution must provide support to define access based on time of day, day of week or by group
or user-defined access.

628.
The solution must have provision available to write a custom query (SQL Statement) and generate
the reports based on queries in .CSV, .HTML formats.

629. Authentication server should have inbuilt RADIUS Server.
630. Authentication server should support cross realm authentication between primary servers.
631. Agent APIs to be available in both C and Java and must be delivered along with the license.
632.
Support for web-based provisioning and workflow product that enables users to rapidly deploy
hardware and software tokens.

633.
The solution must have support for software to enable a system or Help Desk administrator to use
a web browser to view and modify user, token and extension record data in the Authentication
server database.

634.
The solution must provide web-based workflow and support multiple approvers and distributors
and should support delegated administration.

635. The solution must support USB Token and OTP LCD display on the same device.

636.
The solution must provide support for storage of digital certificates, software tokens and
biometric templates, passwords on the USB Token with OTP LCD display.

637. The Authenticators should be in forms of hardware (e.g., Keyfob) but not in the form of CDs.
638.
The hardware token should have an LCD window capable of displaying minimum of six digit
number.

7.2.4 TECH 4: Compliance Statement Format for Functional Requirements
7.2.4.1 Mail Operations
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Mail Booking Engine
Point of Sale Counter Terminal Landing Page
1. MB1.1
The Point of Sale Counter Terminal shall allow the user to enter the Mail Booking Engine
portal from the main landing screen
E 1
Mail Booking Engine Terminal Peripherals
2. 2 MB1.2
The Counter Terminal shall have peripherals connected that enable required functionality
(assumes included screen, keyboard and mouse)

3. MB1.2.1
The Counter Terminal shall have a connected weigh scale that automatically passes item
weight to the terminal


4. MB1.2.1.1 The connected scale must also have a human readable digital display E 1
5. MB1.2.1.2
If the scale is not able to automatically transfer data to the terminal, the user shall be able
to manually enter the displayed weight into the terminal. System shall also allow the
counter clerk to input volumetric data.
E 1
6. MB1.2.2 The Counter Terminal shall have a connected bar code scanner
7. MB1.2.2.1 The bar code scanner shall provide an audible notification on successful scan E 1
8. MB1.2.2.2 The bar code scanner shall provide a visual notification on successful scan E 1
9. MB1.2.2.3
If the bar code scanner is not able to transfer data to the Terminal, the user shall be able to
manually enter bar code characters
E 1
10. MB1.2.3 The Counter Terminal shall have a connected printer
11. MB1.2.3.1 The connected printer shall print receipts for customers E 1
12. MB1.2.3.2
The connected printer shall print adhesive labels with paid postage amount or bar codes to
be affixed to accountable articles
E 1
13. MB1.2.4
The Counter Terminal shall be compatible to handle a credit/debit/ATM card reader in the
future

14. MB1.2.4.1
If the credit/debit/ATM card reader is not present or is not working, the user shall have the
ability to manually enter credit/debit card numbers
E 1
15. MB1.2.4.2
If the customer uses a debit/ATM card, the system shall have the capability to accept the
customers PIN code for identification validation on a PIN code keypad
E 1
16. MB1.2.5
The Counter Terminal software solution shall be designed to be touch-screen compatible
(i.e. finger sized selection buttons, on-screen keyboard icon, etc.) so that future monitor
purchases can utilize the touch-screen interface
D 2

Booking an Individual Accountable Mail Article
17. MB1.3 MBE shall validate data related to the article being booked
18. MB1.3.1 MBE shall prompt the user to enter the destination PIN code
19. MB1.3.1.1 MBE shall validate PIN codes as being valid E 1
20. MB1.3.1.2
The system shall prompt users to select the destination city/state based on the PIN code
master available in the system
E 1
21. MB1.3.1.3
The system shall create an address memory so that frequently entered destinations can
be presented as remembered options to the user as the destination city/state characters
are entered (similar to Google browsing intelligence)
E 1
22. MB1.3.1.4
When the system displays remembered destination options to the user, the user shall be
able to select one of the options such that the remaining destination information is auto-
populated by the system
E 1
23. MB1.3.1.5
When the user selects the city/state, the system shall auto-populate the associated PIN
code
E 1
24. MB1.3.2 MBE shall display on the screen the weight of the article that was placed on the scale E 1
25. MB1.3.2.1 If the scale is not connected, the user shall enter the weight of the article into MBE E 1
26. MB1.3.3
MBE shall display the possible product types based on the destination entered (i.e. Speed
Post, Registered, International, etc.)
E 1
27. MB1.3.3.1
If the destination entered is not serviced by one of the standard product types, then that
product type shall not be displayed (i.e. Speed Post to certain rural areas)
E 1
28. MB1.3.4
When the possible product-types are displayed, the system shall display beside each
product-type the system-calculated postage required
E 1

29. MB1.3.4.1
MBE shall use configurable data to automatically calculate required postage based on the
following attributes of the article:
Product (i.e. Speed Post, Registered, International, etc.)
Origin
Destination
Weight of article
Price of the article (in case of periodicals/books)
Volumetric size of article (input manually)
E 1
30. MB1.3.5
When the possible product types are displayed, the system shall display beside each
product type the automatically system-determined expected delivery date range for each
product
E 1
31. MB1.3.6
After the user selects the product desired by the customer, the system shall allow the user
to select multiple, configurable special services (meaning more services can be added to the
list of options) requested by the customer (i.e. SMS notifications, signature confirmation,
etc.)

32. MB1.3.6.1
The system shall display special services relevant to the product selected alongside the
additional cost for each service
E 1
33. MB1.3.6.2
If the customer selects SMS notification for sender at time of delivery, the system shall
prompt the user to enter the senders mobile phone number
E 1
34. MB1.3.6.3
If the customer selects SMS notification for recipient on day of expected delivery, the
system shall prompt the user to enter the recipients mobile phone number
E 1
35. MB1.3.6.4
If the customer selects e-mail notification for sender at time of delivery, the system shall
prompt the user to enter the senders e-mail address
E 1
36. MB1.3.6.5
If the customer selects e-mail notification for recipient on day of expected delivery, the
system shall prompt the user to enter the recipients e-mail address
E 1

37. MB1.3.6.6
The system shall validate that all e-mail addresses match expected e-mail format (include
@ and . somewhere after the @)
E 1
38. MB1.3.6.7
If the customer selects Return Service if the article is for some reason undeliverable, the
system shall prompt the user to enter the senders full address
E 1
39. MB1.3.7
After the user has selected any additional services, the system shall present the final
amount of postage due that includes the up-charges for the selected special services

40. MB1.3.7.1
If the customer has selected Speed Post, the system shall display the expected end to end
routing and associated transit times
E 1
41. MB1.3.7.2
For Speed Post bookings, the system shall identify the routing on the printed Speed Post
label
E 1
42. MB1.3.8
The system shall prompt the user to scan the 2-9-2 bar code sticker that will be used to
track the article

43. MB1.3.8.1
The user shall have the ability to enter the bar code number in the event that the scanner is
not working or there is none connected
E 1
44. MB1.3.8.2
Once Speed Net has been completely decommissioned and all scanners have been
upgraded to read the future article bar code, the system shall auto-generate/print unique
bar codes, making this scanning requirement unnecessary in the future
D 2
45. MB1.3.9
Upon completion of payment transaction (see Accepting Payment requirements section),
all data captured during the article booking shall be transmitted to the central server
E 2
Individual Stamp Sales
46. MB1.4 MBE shall provide Stamps sales functionality
47. MB1.4.1
The system shall provide a beginning of day function to record the amount of postage and
petty cash taken to the stamp counter
E 1

48. MB1.4.2
The system shall provide an end of day function to record the amount of postage and petty
cash returned to the Mail Booking Engine terminal
E 1
49. MB1.4.3
The system shall reconcile the beginning of day stamp counts and cash amounts with the
end of day stamp counts and cash amounts and raise any discrepancies to the user
E 1
50. MB1.4.4
The system shall send stamp transaction details to the Inventory Management System for
tracking of post office stamp inventory
E 1
Retail Post Sales
51. MB1.5 MBE shall provide the ability to sell Retail Post items to customers
52. MB1.5.1
MBE shall offer the following services:
Sale of goods
a. Sale of stationery
b. Sale of packing material
c. Greeting cards of other organizations
d. Sale of gold coins
e. Sale and distribution of souvenirs
f. Sale and distribution of books
g. Sale and distribution of prasadams
h. RBI coins service
i. Sale of Revenue/judicial/Non-judicial
j. Sale of Rakhi/Speed Post/other envelopes
Sale of application forms
k. Sale of UPSC/SSC/RRB application forms
l. Sale of University application forms
Miscellaneous Services
m. Sale of travel related services
n. Railway reservation service (PRS)
E 3

o. Sale of event tickets
p. Address verification services
q. Drop-Box services
r. Forex services
s. Subscription services
t. Telecom services
u. Income Tax services
v. Distribution of loans
w. Internet caf services
x. Other agency services
53. MB1.5.1.1 MBE shall provide the flexibility for HQ admin users to add new Retail Post service offerings E 1
54. MB1.5.2 MBE shall provide the ability to sell philatelic items to customers E 1
55. MB1.5.3 The system shall allow the user to add multiple items to the customers order E 1
56. MB1.5.3.1
As additional items are added to the customers order, the system shall auto-update the
amount owed by the customer
E 1
57. MB1.5.4
Upon completion of payment transaction (see Accepting Payment requirements section),
all data captured during the Retail Post order shall be transmitted to the central server
E 1
58. MB1.5.5
If the customer has purchased a Retail Post item stocked by DoP, MBE shall send order
request to WMS for order fulfilment to be processed
D 1
59. MB1.5.6
If the customer has purchased a Retail Post item NOT stocked by DoP, MBE shall send the
external customer the order request for order fulfilment
D 2
60. MB1.5.7
The system shall send transaction details to the Inventory Management System for tracking
of post office philatelic and Retail Post inventory
E 2
61. MB1.5.8
When the system books a VPP or Payment on Delivery article, the system shall have an
outbound interface with Accounts Receivable module for the amount outstanding against
E 2

the identification number of the article
62. MB1.5.9
If the system is operating in offline mode, the booking shall still occur, but the user shall
notify the customer that the article may not be immediately available (may be on backorder
since the system cant connect to check) and capture customer SMS/e-mail to notify user
when the item will be available
E 2
63. MB1.5.10 The system shall enable ePayment
64. MB1.5.10.1 The system shall have accounts for facilitating bill collection for Business Partners E 1
65. MB1.5.10.2 The system shall collect bill payment from retail customers for the partner corporate E 1
66. MB1.5.10.3
The system record the customer id number (unique identifier for the business partner) into
the system
E 1
67. MB1.5.10.4
The system shall have an outbound interface with the customer IT system to pass on the
information pertaining to the payments by its customers
E 1
68. MB1.5.10.5
The system shall have proper accounting for the money collected on behalf of its business
partner
E 1
Online Booking and Pickup Requests
69. MB1.6 MBE shall provide the user an online pickup request capability
70. MB1.6.1 MBE shall require the user to enter the address where the article shall be picked up E 1
71. MB1.6.2 MBE shall require the destination address where the article shall be delivered E 1
72. MB1.6.3
MBE shall allow the user to select the product type (i.e. Speed Post, Registered,
International, etc.)
E 1
73. MB1.6.4
For International articles, the system shall require the user to enter required customs
declaration information online
E 1

74. MB1.6.5
For International articles, the system shall require the user to print the Customs Declaration
form to be securely affixed with tape to the article
E 1
75. MB1.6.6
MBE shall allow the user to select special services (i.e. delivery confirmation, signature
confirmation, etc.) that they would like to include for the article
E 1
76. MB1.6.7
MBE shall require the user to enter the physical attributes of the article: weight and
dimensions. (Meant only for small & medium business with mail room facility)
E 1
77. MB1.6.8
MBE shall calculate required postage based on the data entered by the customer. (Meant
only for small & medium business with mail room facility)
E 1
78. MB1.6.9
MBE shall create a label to be printed and affixed by the customer on the article. (Meant
only for small & medium business with mail room facility)

79. MB1.6.9.1
The label shall include the following required sender/delivery information:
Sender Name
Sender Address
Recipient Name
Recipient Address
Special Services Included
E 1
80. MB1.6.9.2
The label shall include paid postage information. (Meant only for small & medium business
with mail room facility)
E 1
81. MB1.6.9.3
The label shall include the unique article bar code. (Meant only for small & medium
business with mail room facility)
E 1
82. MB1.6.9.4
The label shall be formatted such that it fits on a standard adhesive label size that the
customer can easily purchase to be fed through a laser printer. (Meant only for small &
medium business with mail room facility)
E 1
83. MB1.6.10
MBE shall provide users various payment methods as described in the Payment Options
E 1

requirements. (Meant only for small & medium business with mail room facility)
84. MB1.6.11
MBE shall generate a receipt for the customer. (Meant only for small & medium business
with mail room facility)
E 1
85. MB1.6.12
MBE shall interface with the Delivery & Postman Management System to send customer
pickup requests to the post office where that address is serviced
E 1
86. MB1.6.13
For city areas, the system shall be compatible with functionality to locate the closest
postman using GPS in postmans device along with the expected beats of the postmen.

87. MB1.6.13.1
If a postman along that beat has not yet passed the destination entered, the system shall
send an SMS notification to the postman with the closest device for pickup on remaining
beat.
D 1
88. MB1.6.13.2
In addition to the device SMS, the system shall also send an outbound interface to DPMS
for the expected delivery and postage due
D 1
89. MB1.6.13.3
If the postman along that beat has already passed the destination entered or there are no
GPS enabled devices in that area, the system shall send an outbound interface including all
of the collected information to DPMS to schedule the pickup for the following day
E 1
90. MB1.6.13.4
If the customer chooses to not print the label information, the data sent via SMS or
interface to DPMS shall include the following required sender/delivery information:
Sender Name
Sender Address
Recipient Name
Recipient Address
E 1
91. MB1.6.13.5 The label data shall include required postage information for the postman to collect E 1
92. MB1.6.13.6 MBE shall book the article through the handheld being carried with the Postmen D 1

93. MB1.6.13.7
System shall reconcile the amount collected by the Postmen with the Accounts Receivable
module
D 1
94. MB1.6.13.8
For places where the Postman does not carry the handheld, he will come back to the office
and upload the information in the system in the office through MBE
E 1
95. MB1.6.13.9 The label data shall include the unique article bar code E 1
Booking of Bulk Customers
96. MB1.7 MBE shall provide functionality to induct bulk mail customer drop-offs
97. MB1.7.1
MBE shall allow the user to upload the customers electronic manifest in a pre-defined file
format through a web account. Alternatively, it shall also allow the user to upload the
electronic manifest from customers physical storage device (CD/DVD)

98. MB1.7.1.1
The data to be uploaded from the electronic manifest shall be the following:
Customer ID (assigned at first use of booking or appointment system)
Article ID
Weight of the Article
Recipient Name
Recipient Address
Destination City/State and PIN
Special Service Code for the article
E 1
99. MB1.7.1.2 The system shall display the summary information for the shipment E 1
100. MB1.7.1.3
After uploading the electronic manifest, the system shall calculate the postage due for the
entire transaction based on the information in the manifest
E 1
101.
MB1.7.1.3.
1
The system shall send a debit transaction to the Accounts Receivable module for the
customer ID to be invoiced for the amount calculated based on the manifest
E 1

102. MB1.7.1.4
Upon completion of the users scanning (either through handheld scanner or through high-
speed scanner), the system shall allow an update of the counts of articles actually in the
shipment
E 1
103.
MB1.7.1.4.
1
The system shall re-calculate the postage for any discrepancies in counts between the
customers manifest and the actual counts
E 1
104.
MB1.7.1.4.
2
The system shall send a debit transaction to the Accounts Receivable module with the
customer ID, the additional amount to be invoiced, and the count of the discrepancy
E 1
105. MB1.7.2 MBE shall provide the user a bulk customer booking screen
106. MB1.7.2.1 MBE shall prompt the user to first weigh a sample article E 1
107. MB1.7.2.2
If the shipment is small enough to be weighed on the scale, MBE shall allow the user to
capture the total weight of the shipment
E 1
108. MB1.7.2.3
If the shipment cannot fit on the scale, MBE shall allow the user to enter the number of
articles included in the shipment that will be validated through individual bar code scans
E 1
109. MB1.7.2.4
MBE shall prompt the user to select any special services requested by the customer for the
entire shipment
E 1
110. MB1.7.2.5
If the shipment has been bar coded by the customer, the system shall capture the article
bar codes for each PIN code

111.
MB1.7.2.5.
1
For PIN code-wise bundles, the user shall enter the PIN code of the bundle and then scan
each article bar code related to that PIN code without having to re-enter the PIN code each
time
E 1
112.
MB1.7.2.5.
2
The user shall enter a new PIN code when changing PIN codes for a bundle of articles for
another destination then scan the relevant article bar codes
E 1
113.
MB1.7.2.5. For city-wise bundles, the user shall enter the first three digits of PIN code of the bundle
E 1

3 and system shall populate the next three digits as 000 and then scan each article bar code
related to that PIN code without having to re-enter the PIN code each time
114.
MB1.7.2.5.
4
The user shall enter a new PIN code when changing PIN codes for a bundle of articles for
another destination then scan the relevant article bar codes
E 1
115. MB1.7.2.6
If the shipment has not been bar coded by the customer, the system shall include an extra
charge for counter bar coding

116.
MB1.7.2.6.
1
The user shall enter the PIN code only of the bundle and then enter the beginning and end
bar code to be applied to that bundle
E 1
117.
MB1.7.2.6.
2
The user shall enter a new PIN code when changing PIN codes for a bundle of articles with
the same destination then enter the beginning and end bar code to be applied to the
relevant article bar codes
E 1
118. MB1.7.2.7
MBE shall calculate the total charge for the shipment based on the number of items,
weight, destination and special services selected using the bulk postage table
E 1
119. MB1.7.3
The customer can pay for the shipment using one of the methods described in the Payment
Options requirements section
E 1
120. MB1.7.4
If the customer does not want to pay through one of the individual Payment Options
described in requirement MB1.9, MBE shall use the customers credit or debit account for
payment
E 1
121. MB1.7.4.1
MBE shall allow for new customer creation if the customer does not already have a DoP
credit or debit account. This information must be maintained locally and centrally (for
distribution to other local servers).

122.
MB1.7.4.1.
1
The system shall capture company name, contact information, company funds approver,
and all other fields per the standard DoP customer application form
E 1
123.
MB1.7.4.1. If the customer is government or semi-government, their account may be opened as a
E 1

2 Book-Now-Pay-Later customer for payments related to Speed Post and other premium
products
124.
MB1.7.4.1.
3
If the customer provides deposit (as specified by DoP) through one of the Payment
Options, they shall be setup as a BNPL customer
E 1
125.
MB1.7.4.1.
4
If the customer is not a BNPL customer, they shall provide advance payment through one of
the Payment Options so that their shipment amount can be deducted from their credit
available
E 1
126.
MB1.7.4.1.
5
If the customer has an advance payment account, the system shall create a debit from the
customers account for the total amount due
E 1
127.
MB1.7.4.1.
6
Customer advance payments, debits, and BNPL transactions shall be sent to the Accounts
Receivable module for customer account
E 1
128.
MB1.7.4.1.
7
If the customer does not have enough funds in their debit account, the system shall prompt
the user to add more funds
E 1
129.
MB1.7.4.1.
8
If the customer has a BNPL account, the AR module receives an amount due transaction
from the Mail Booking Engine to increase the amount owed by the customer
E 1
130.
MB1.7.4.1.
9
If the customers account exceeds a configurable threshold of amount due, the user shall
instruct the customer that the booking cannot be accepted without payment of the overage
E 1
131.
MB1.7.4.1.
10
If the customers account is in default because a payment was missed, the system shall
prompt the user to send electronic instruction to the customer that the booking cannot be
accepted without payment of the amount due
E 1
132. MB1.7.5
Upon completion of the payment transaction, the system shall transmit bulk booking
events for each article
E 1
133. MB1.7.6
If the customer was a new customer, the system shall send a new customer record to the
Customer Database and receive back a unique customer ID that can be provided to the
E 1

customer for future use
Franking Machine Functionality
134. MB1.8 MBE shall provide functionality to interact with Franking Machine users
135. MB1.8.1
MBE shall accept license fee from the Franking machine user for unique franking machine
(digifrank compliant as prescribed by DoP).

136. MB1.8.1.1 MBE shall issue the receipt for the license fee deposited E 1
137. MB1.8.1.2
MBE shall prompt franking machine user to enter Annexure-A fields that are not already
captured through their license number
E 1
138. MB1.8.2 MBE shall intimate Licensing Authority about license requests E 1
139. MB1.8.2.1 MBE shall enable the Licensing Authority to verify application forms
140. MB1.8.3
MBE shall accept list of clients along with their consent letters who are being serviced by a
franking machine user
E 1
141. MB1.8.4 MBE shall update application form status E 1
142. MB1.8.5
MBE shall grant unique license to the franking machine user after Licensing Authority and
field staff physical verification
E 1
143. MB1.8.5.1
MBE shall generate four digitally authenticated Copies of Certificate of License along with
customer relationship numbers to be sent to:
- Franking machine user
- Designated post office/mail office/field post office
- Remotely Managed Franking System centre
- Mail Booking/Retail Post server
E 1
144. MB1.8.6 The system shall allow Corporate customers to uniquely log into the India Post MBE

145. MB1.8.6.1 MBE shall recognize the customer based on customer relationship number E 1
146. MB1.8.6.2
MBE shall list out all licenses for franking machines possessed by the customer 1 license
for each franking machine

147.
MB1.8.6.2.
1
MBE shall show balances against each license E 1
148.
MB1.8.6.2.
2
MBE shall show license usage pattern E 1
149. MB1.8.6.3 MBE shall enable selection of individual license for recharge E 1
150. MB1.8.6.4 MBE shall accept any of the standard Payment Options E 1
151.
MB1.8.6.4.
1
MBE shall credit unique license E 1
152.
MB1.8.6.4.
2
MBE shall record details of licenses recharged E 1
153. MB1.8.6.5
MBE shall pass the details of licenses recharged to the remotely managed franking system
server at the vendor location (RMFS server)
E 1
154. MB1.8.7
MBE shall allow authorised user to update the status of any franking machine license as
cancelled or expired
E 1
155. MB1.8.8
MBE shall provide options for cancellation of Franking Machine licenses as per DoP SOP
Based on Licensee request
Based on DoP request
E 1
156. MB1.8.9 MBE shall not allow recharge of the cancelled/expired licenses E 1
157. MB1.8.10 MBE shall provide options for renewal of FM licenses as per DoP SOP E 1

158. MB1.8.11
MBE shall process requests for miscellaneous services of Franking Machine as per DoP SOP
Address change of FM With/without change of licensing authority
Change in license identifier etc.
E 1
159. MB1.8.12 MBE shall enable selection/update of rebate & refunds provided by post E 1
160. MB1.8.13
MBE shall provide online forms required for Franking Machine operations (e.g. Application
for renewal of license)
E 1
Payment Options
161. MB1.9 MBE shall provide numerous payment options
162. MB1.9.1 MBE shall accept cash payments E 1
163. MB1.9.2 MBE shall calculate required change to be returned to the customer E 1
164. MB1.9.3 MBE shall be compatible to accept credit card payments E 1
165. MB1.9.4 MBE shall be compatible to accept debit card payments E 1
166. MB1.9.5 MBE shall accept ATM card payments E 1
167. MB1.9.5.1 MBE shall allow the customer to enter their ATM card PIN code
168. MB1.9.6 MBE shall have the ability to debit the customers DoP savings account for any transaction E 1
169. MB1.9.7
MBE shall have the ability to debit the corporate customer account for the services
performed for the customer
E 1
170. MB1.9.8
MBE shall have the ability to debit the customers savings account held at other banks for
any transaction
E 1
171. MB1.9.9 For corporate/bulk mailer customers ONLY, MBE shall accept cheque payments E 1
172. MB1.9.9.1
If the customers cheque does not clear, the customers account shall be marked with
E 1

prescribed amount for returned cheque charge
Capturing Employee Work Hours
173. MB1.10 MBE shall record employee work hour details
174. MB1.10.1 MBE shall automatically capture work hours of users of the terminals
175. MB1.10.1.1
For users of the Terminal, MBE shall provide a start shift function where the user first
records the beginning of their work shift
E 1
176. MB1.10.1.2
For users of the Terminal, MBE shall provide an end shift function where the user records
the end of their work shift
E 1
177. MB1.10.2
For employees in an office who do not use the terminal, the Mail Booking Engine shall
provide a means by which the supervisors can manually record employee work hour details
in the system
E 1
Transferring Data from a Disconnected Office
178. MB1.11
MBE shall provide the ability to dump and load data stored on a local server that cannot
connect to the central server

179. MB1.11.1
MBE shall allow a user to perform a daily data dump onto CD or flash drive that can be
taken to a neighbouring connected office
E 1
180. MB1.11.2
MBE shall allow a user to load data from a CD or flash drive containing a data dump from a
neighbouring disconnected office
E 1
181. MB1.11.3
MBE shall automatically transfer the re-loaded data to the central server once the data
dump has been loaded onto the connected office server
E 1
182. MB1.11.4 The data being transferred must be encrypted on the transferring medium E 1
Mail Accounting Functions

183. MB1.12
MBE shall include an accounting engine for recording transactions done for sale of
products/services

184. MB1.12.1 MBE shall record the sales volumes and pricing data for profitability analytics E 1
185. MB1.12.1.1
Each product/service transaction needs to be booked (associated) to a predefined Head of
account (HoA) for proper revenue recognition
E 1
186. MB1.12.1.2 These HoAs will be defined by the PAF division as per GoI guidelines for the same E 1
187. MB1.12.1.3
At each End of Day, the mail app will centrally push consolidated GL data product (HoA)
wise from each PO to the GL for consolidation and compilation of accounts for DoP as a
whole
E 1
Product/Pricing List Functions
188. MB1.13 The system shall include a product & pricing list
189. MB1.13.1 The product/pricing list shall be centrally maintained
190. MB1.13.1.1 The product/pricing list shall be available to the mail booking engine E 1
191. MB1.13.1.2
The product & pricing list shall be available to other booking channels such as Rural ICT &
web booking
E 1
192. MB1.13.1.3
The product & pricing list shall be maintained with state-to-state variances, both on
product prices and on taxes/tariffs
E 1
193. MB1.13.1.4
Pricing list for Logistics services being offered to the customers shall be maintained in the
system for various routes and options (LCL, LTL, FTL etc.)
E 1
194. MB1.13.2
Each product must be assigned to a predefined Head of Account (HoA) for proper revenue
recognition
E 1
195. MB1.13.3
When new products are added, the system shall not make the new product available to
E 1

booking systems until a Head of Account has been assigned to the new product
196. MB1.13.4
When a new product is added, the changed product/pricing information shall be
synchronized to the local servers not the entire product/pricing list
E 1
Booking an Individual International Mail Article
197. MB1.14 MBE shall ensure that the product and documentation meets international specifications
198. MB1.14.1 The system shall validate the article meets sizing restrictions
199. MB1.14.1.1 The system shall accept weight of the parcels in kilogrammes E 1
200. MB1.14.1.2 The system shall accept a maximum individual weight of 20 kilogrammes E 1
201. MB1.14.1.3
The system shall provide option of admitting parcels between the weights of 20 and 50
kilogrammes
E 1
202. MB1.14.1.4 The system shall limit parcel to two meters for any one dimension E 1
203. MB1.14.2 The system shall capture address details for addressee and sender E 1
204. MB1.14.3
The system shall verify the details of the article along with the list of restricted articles in
the destination country
E 1
205. MB1.14.3.1 The system shall check with the prohibitions of individual destination country E 1
206. MB1.14.4
The system shall have a checklist which includes:
CP71/CP72 Dispatch note
CN22/CN23 Customs declaration
export licence / import licence
certificate of origin
certificate of health
E 1
207. MB1.14.5
The system shall capture at the time of posting of a parcel, the treatment to be given in
E 1

case of non-delivery
Return to sender
Redirection for delivery to the addressee
Abandonment
208. MB1.14.6 The system at the office of origin shall be equipped to print the CP73 label E 1
209. MB1.14.7
The system shall capture numerous required data elements/forms and transfer such data to
UPU-specified systems
E 1
210. MB1.14.7.1
The system shall allow electronic entry into form
CP71 Dispatch note
CN23 Customs declaration
E 1
211. MB1.14.7.2
The system shall record method of forwarding and to be clearly indicated on the dispatch
note relating to the parcel
E 1
212. MB1.14.7.3 Dispatch note is to be printed in a self-adhesive document pack pasted firmly to the parcel E 1
213. MB1.14.7.4
The system shall print for parcels on which a COD charge is applicable the dispatch note
which will bear very prominently the heading "reimbursement" along with the amount
E 1
214. MB1.14.8 The system shall capture international accounting information E 1
215. MB1.14.8.1
The system shall capture charges, customs duty, and other fees paid out on behalf of the
other on the CN12 form
CN 12 Details of accounts prepared by creditor admin
CP 75 summarized account
CN51 Airmail detailed account
E 1
Booking ePost at the Counter
216. MB1.15
The system shall allow a user to book an ePost article that will be printed and delivered by
the destination post office


217. MB1.15.1 The system shall allow a written note to be recorded into the system E 1
218. MB1.15.2
The system shall accept a note that is to be scanned at the parent office with a document
scanner
E 1
219. MB1.15.3
The system shall prompt the user to record the following data for the article to be sent via
ePost:
Senders name
Recipients name
Recipients full address
E 1
Booking Individual Article over the Phone
220. MB1.16 The system shall provide an accountable article pickup function through the DoP Call Centre
221. MB1.16.1 The Call Centre screen shall capture sender name and address E 1
222. MB1.16.2
The Call Centre screen shall capture the destination address where the article shall be
delivered
E 1
223. MB1.16.3
The Call Centre screen shall allow the user to select the product type requested by the
customer (i.e. Speed Post, Registered, Money Order International Articles must be
booked online or at post office)
E 1
224. MB1.16.4
The Call Centre screen shall allow the user to select special services (i.e. delivery
confirmation, signature confirmation, etc.) that they would like to include for the article
E 1
225. MB1.16.5
For city areas, the system shall be compatible with functionality to locate the closest
postman using GPS in postmans device along with the expected beats of the postmen.
D 1
226. MB1.16.5.1
If a postman along that beat has not yet passed the destination entered, the system shall
send an SMS notification to the postman with the closest device for pickup on remaining
beat.
D 1

227. MB1.16.5.2
In addition to the device SMS, the system shall also send an outbound interface to DPMS
for the expected delivery
E 1
228. MB1.16.5.3
If the postman along that beat has already passed the destination entered or there are no
GPS enabled devices in that area, the system shall send an outbound interface including all
of the collected information to DPMS to schedule the pickup for the following day
E 1
229. MB1.16.5.4
The data sent via SMS or interface to DPMS shall include the following required
sender/delivery information:
Sender Name
Sender Address
Recipient Name
Recipient Address
Special Services Included alongwith the mail class of an article
E 1
Booking a Money Order
230. MB1.17
The Mail Booking/Retail Post System shall allow booking of Money Order for payment to a
beneficiary at another location in the country

231. MB1.17.1
The shall provide two options for Money Orders:
1. Money Order delivery at the doorstep
2. Customer to approach any connected/service providing Post Office
E 1
232. MB1.17.2
System shall allow capture of the following details for Doorstep Delivery Transaction:
Sender Name
Sender address
Sender Mobile Phone Number
Amount
Beneficiary Name
Beneficiary Address
E 1

Beneficiary Mobile Phone Number
Beneficiary Identification details, if any
Delivery Post office details
Small Text message, if any
233. MB1.17.3
On selection of transaction where customer would approach the PO, the system shall allow
capture of the following details:
Sender Name
Sender address
Sender Mobile Phone Number
Amount
Beneficiary Name
Beneficiary Address
Beneficiary Mobile Phone Number
Beneficiary Identification details, if any
Delivery Post office details (Greyed out since this MO is payable across the network)
Small Text message, if any
E 1
234. MB1.17.4
System shall allow selection of sender by means of providing the customer ID or Account
number which would enable debit to the Senders Account (Only for PBS Branch Account
Holders)
E 1
235. MB1.17.5
System shall enable capture of the Senders Mobile number if the same does not get
populated by selection of the Customer ID or Account number
E 1
236. MB1.17.6
System to allow parameterization of a maximum & minimum limit for any type of
transaction
E 1
237. MB1.17.7 System to calculate Commission pertaining to the MO at the prescribed rate E 1
238. MB1.17.8
System shall allow recovery of this commission by debit to the Savings Bank account in case
E 1

sender is Account holder (Only in case of a PBS branch)
239. MB1.17.9 System shall allow capture of Multiple Beneficiaries and their details in the system E 1
240. MB1.17.10
System shall generate a Unique reference number (13 character code 2 character for
money order product code MO, 9 digits for unique number generated and last 2 character
would be IN) for each type of transaction booked. The same should be sent to the Sender &
Beneficiary via SMS with the details of the Paying Branch in case of Type 1 transaction
E 1
241.
MB1.17.10.
1
The unique number shall be sent to the Sender & Beneficiary via SMS with the details of the
Paying Branch in case of Type 1 transaction as well as a printed receipt presented to the
sender
E 1
242. MB1.17.11 System should allow for maker checker concept for authorization of the MO transaction E 1
243. MB1.17.12
System should interface with the SMS engine to send a Text Message to sender and
beneficiary for the Booking of Money Order event
E 1
Money Order Accounting
244. MB1.18
System should enable interface with PBS to debit the sender if he/she is an account holder
(Only in case of a PBS branch)

245. MB1.18.1
System shall verify the account balances before transfer of funds in case it is a request by
debit to account (Only in case of a PBS branch)
E 1
246. MB1.18.2
System shall have an accounting interface with GL to enable inter-branch accounting
entries for payment of the MO and knock off the Cash position entries and the Inter-branch
entries after liquidation
E 1
247. MB1.18.3
System should be able to match off the accounting entries and reconcile the same based on
liquidation by the Delivery Branch
E 1
248. MB1.19
MBE shall have the functionality to sell and discharge the Indian Postal Orders as per the
E 2

DoP Standard Operation Procedure
Integration Requirements
249. IPVS
MBE shall have an outbound interface to the IPVS sending all of the data captured in MBE
so that IPVS can consolidate the article tracking events, volume, and employee work hour
data with the same data captured throughout the remainder of the mail network
E 2
250. DPMS
MBE shall have an outbound interface to DPMS to send articles booked online or over the
phone that require labels to be printed by the postman and taken on their beat for postage
collection
E 2
251. MLASS
MBE shall have an inbound interface to receive requests for appointment costing that
includes shipment details and additional services requested by the customer for their
shipment. MBE shall then respond with the total cost of the shipment and services.
E 2
252. ERP AR
MBE shall have an outbound interface to AR to debit the account with the charges for the
services performed for the customer, to credit account for deposits made for future
services, and to intimate account receivable amount for Book-Now-Pay-Later (BNPL)
service. It shall also use this interface to confirm that the customers account is in good
standing and can accept the new shipment. Finally, the system shall send VPP or Cash-on-
Delivery article ID and amount due to later be reconciled after successful delivery.
E 2
253. WMS
MBE shall have an outbound interface to the WMS to send Retail Post order requests for
order fulfilment
E 2
254. ERP GL
MBE shall have an outbound interface to the GL Solution to send all of the revenue-
generating transaction data (i.e. stamp sales, philatelic sales, Retail Post, etc.).
E 2
255. ERP IMS
MBE shall have an outbound interface to the IMS to send stamp, philatelic, and Retail Post
transaction details so that the IMS can track and auto-replenish inventory within the Post
Offices
E 2

256. PBS
MBE shall have an outbound interface to the PBS in order to debit the account with the
charges for the services performed for the customer.
E 2
257. HRMS
For the purpose of workload analysis of an establishment (operative and administrative
units), Establishment Review Module of HRMS shall need the number and value of
operations/ transactions happening at each establishment. The customized interface
designed for this purpose shall draw data for four calendar months, from the data
warehouse in the form of MIS reports. MBE shall ensure that this detail is stored in the data
warehouse on a monthly basis.
E 2
258.
External
Customer
MBE shall have outbound interfaces with external customer systems to send non-DoP Retail
Post order requests for order fulfilment.
D 2
259.
RMFS
Licensing
Authority
MBE shall have an outbound interface to send Franking Machine license information E 2
260.
RMFS
Server
MBE shall have an outbound interface to the RMFS server to send Franking Machine
recharge information
E 2
India Post Visibility System
261. MB2.1 IPVS shall allow collection office users to capture outbound bag/volume information.
262. MB2.1.1
IPVS shall allow collection office users to nest individual accountable articles into unique
bar coded bags by scanning the bag bar code then the individual articles.

263. MB2.1.1.1
IPVS shall allow users to scan the standard 2-9-2 item bar code when creating accountable
article bags.
E 1
264. MB2.1.1.2
IPVS shall allow the user to Close the bar coded bag by again scanning the bag bar code
after scanning individual articles into the bag.
E 1
265.
MB2.1.1.2. Closed bags shall be sequentially marked in the system such that every time a new bag is


1 created for a destination office, the sequence number for that destination office increases
by 1 to later ensure that no bags are lost between origin and destination.
266. MB2.1.1.3
IPVS shall treat scans of individual articles into bags as en route events for the individual
article scanned.
E 1
267. MB2.1.1.4
IPVS shall store bag manifest data in the central server and transmit such data to the
relevant downstream offices.
E 1
268. MB2.1.2
When RFID system has been enabled, IPVS shall have the functionalities listed under
MB2.1.1 activated through RFID capability
D 2
269. MB2.1.3 IPVS shall allow users to capture details about bags of ordinary mails.
270. MB2.1.3.1 IPVS shall allow the user to enter the destination of the bag they are about to create. E 1
271. MB2.1.3.2
After placing all of the ordinary mail for that destination into the bag and placing the bag on
the scale, IPVS shall capture the weight of the bag.
E 1
272. MB2.1.3.3
IPVS shall then prompt the user to scan the 2-9-2 permanent bag bar code on the bag when
despatching a new bag.
E 1
Capturing Data on Inbound Mail Items/Volume
273. MB2.2 IPVS shall capture data related to inbound bags.
274. MB2.2.1 IPVS shall scan the incoming ordinary mail bags on receipt. E 1
275. MB2.2.2 IPVS shall scan the incoming accountable mail bags on receipt.
276. MB2.2.2.1
IPVS shall accept scans of bags with associated nested articles as en route events for the
individual articles associated with the scanned bag.
E 1
277. MB2.2.2.2
IPVS shall use a configurable (by site) QA frequency value that indicates when the user must
scan each article in an accountable bag individually upon receipt (i.e. every 5
th
bag, every
10
th
bag, every bag, etc.).
E 1

278. MB2.2.2.3 IPVS shall accept scans from bar code scanners for individual accountable articles. E 1
279. MB2.2.2.4
IPVS shall interface with high-speed scanners or sorters in high volume facilities to receive
scans for individual accountable articles.
E 1
280. MB2.2.2.5
If individual article scanning is required by the QA frequency, when the user first scans the
bag, the bag manifest will be displayed on the screen allowing the user to see the articles
expected to be scanned out of the bag.
E 1
281. MB2.2.2.6
As the individual articles are scanned out of the bag, the screen shall refresh indicating the
items that have been received by a checkmark or some other received indicator.
E 1
282. MB2.2.3 IPVS shall accept scans from bar code scanners for bag scans. E 1
283. MB2.2.4 When RFID is enabled, IPVS shall accept read events from RFID readers for bag scans. D 2
Creating Outbound Bags of Accountable Mail
284. MB2.3
IPVS shall allow users to capture data about outbound accountable mail bags being created
at the facility.

285. MB2.3.1 IPVS shall prompt the user to enter the bag destination. E 1
286. MB2.3.2
IPVS shall tie origin, destination, and date created information to the unique bag bar code
generated/printed by the system
E 2
287. MB2.3.3
IPVS shall allow users to nest individual articles into unique bar coded bags by scanning the
new bag bar code and then the individual articles.

288. MB2.3.3.1 IPVS shall allow users to scan the standard 2-9-2 article bar code. E 1
289. MB2.3.3.2 IPVS shall allow users to scan the new item bar code E 1
290. MB2.3.3.3
When the new bar code is scanned when nesting the articles into the bag, if the PIN code
does not match the destination PIN codes of the intelligent bag tag, IPVS shall throw an
audible and visual alert to the user informing them the destination of the bag does not
E 1

match the destination of the item.
291. MB2.3.4
IPVS shall allow user to Close the bar coded bag by again scanning the bag bar code after
scanning individual articles into the bag.
E 1
292. MB2.3.5
IPVS shall allow user to associate bag bar code with bag RFID tag by scanning the bag bar
code then the RFID tag bar code.
D 2
293. MB2.3.5
IPVS shall accept the scans of the individual articles into bags as en route events for the
individual article scanned.
E 1
294. MB2.3.6 IPVS shall record the type of bag
295. MB2.3.6.1 IPVS shall pop up a list of types of receptacles on the screen at the scan of a bag tag E 1
296. MB2.3.6.2 IPVS shall not allow the user to proceed before the type of bag is chosen E 1
297. MB2.3.6.3 IPVS shall link the type of bag with the bag barcode E 1
298. MB2.3.6.4 IPVS shall maintain record of all nested bags in case of a T bag E 1
Creating Outbound Bags of Ordinary Mail
299. MB2.4
IPVS shall allow users to capture data about outbound ordinary mail bags being created at
the facility.

300. MB2.4.1 IPVS shall prompt the user to enter the bag destination. E 1
301. MB2.4.2
After placing the bag on the weigh scale, the user shall be prompted to scan the unique EB
2-9-2 bar code on the bag to capture the associated weight for the origin/destination
combination.
E 1
302. MB2.4.3 IPVS shall record the type of bag
303. MB2.4.3.1 IPVS shall pop up a list of types of receptacles on the screen at the scan of a bag tag E 1
304. MB2.4.3.2 IPVS shall not allow the user to proceed before the type of bag is chosen E 1

305. MB2.4.3.3 IPVS shall link the type of bag with the bag barcode E 1
306. MB2.4.3.4 IPVS shall maintain record of all nested bags in case of a T bag E 1
Transmission Scanning
307. MB2.5 IPVS shall use in-transmission scans for en route events for unique articles.
308. MB2.5.1
After placing the bag on the weigh scale, the user shall scan the bag bar code to capture the
associated weight.
E 1
309. MB2.5.2
If the terminal does not have a connected weigh scale, the user shall be able to enter the
weight and then scan the bag bar code to have the associated weight automatically
captured.
E 1
310. MB2.5.3
IPVS shall accept scans of bags with associated nested articles as en route events for the
individual articles associated with the scanned bag.

311. MB2.5.3.1 IPVS shall accept scans from bar code scanners for bag scans. E 1
312. MB2.5.3.2 IPVS shall accept events from RFID readers for bag scans. D 1
313. MB2.5.4
IPVS shall accept scans of individual articles into transmission containers as en route events
for the individual article scanned.
E 1
314. MB2.5.5
IPVS shall accept tracking events from the WMS for articles/shipments moving out of DoP
warehouses.
E 2
315. MB2.5.6
IPVS shall accept tracking events from the TMS for articles/shipments tracked within the
TMS.
E 2
316. MB2.5.7 IPVS shall interface with Rail Carrier systems to collect bag ETAs for associated bags. D 2
317. MB2.5.8 IPVS shall interface with Air Carrier systems to collect bag ETAs for associated bags. D 2
Delivery Scanning from DPMS

318. MB2.6
IPVS shall interface with Delivery & Postman Management System to receive delivery-
related events.

319. MB2.6.1
IPVS shall interface with delivery scanning solutions for attempted delivery events for
unique articles.
E 1
320. MB2.6.2
IPVS shall send receiver estimated delivery time SMS (if requested in the Mail Booking
Engine) when received at delivery office event received for the article.
E 2
321. MB2.6.3 IPVS shall interface with delivery scans for actual delivery events for unique articles. E 1
322. MB2.6.4
IPVS shall send sender actual delivery confirmation SMS (if requested in the Mail Booking
Engine) when delivery event received for the article.
E 2
323. MB2.6.5
IPVS shall interface with DPMS to accept digital signature images for association to unique
articles as delivery confirmation events.
E 2
324. MB2.6.6
IPVS shall interface with DPMS to receive Return to Sender notifications requiring a new
reverse record in IPVS for domestic as well as international mail
E 2
Capturing Employee Work Hour Information
325. MB2.7 IPVS shall capture employee work hour information.
326. MB2.7.1
IPVS shall interface with the Mail Booking Engine to upload retail counter employee work
hour details.
E 2
327. MB2.7.2 IPVS shall record mail processing employee work hour details.
328. MB2.7.2.1
In facilities where employee badge swipe or biometric machines are available, IPVS shall
use badge swipes or biometric readings to record employee work hour details.
D 1
329. MB2.7.2.2
In facilities where employee badge swipe or biometric machines are not available, IPVS
shall provide a means by which the supervisors or users can manually record employee
work hour details in the system.
E 1

330. MB2.7.3 IPVS shall record transmission office employee work hour details.
331. MB2.7.3.1
In transit mail offices where employee badge swipe or biometric machines are available,
IPVS shall use badge swipes or biometric to record employee work hour details.
D 1
332. MB2.7.3.2
In transit mail offices where employee badge swipe or biometric machines are not
available, IPVS shall provide a means by which the supervisors or users can manually record
employee work hour details in the system.
E 1
333. MB2.7.4
IPVS shall interface with the Delivery and Postman Management solution to upload
postman work hour details.
E 1
Customer Article Visibility
334. MB2.8 IPVS shall present article visibility events to customers.
335. MB2.8.1 IPVS shall provide a means by which DoP resources can research all visibility events. E 2
336. MB2.8.2
IPVS shall have configurable flags for each product type that indicates which events are
visible to customers through IPVS.

337. MB2.8.2.1
IPVS shall provide customers the ability to research tracking events recorded throughout
the network.
E 1
338.
MB2.8.2.1.
1
IPVS shall provide tracking event data to customers in on-line research format. E 1
339.
MB2.8.2.1.
2
IPVS shall provide tracking event data to DoP Call Centre for customer call-in research
capability.
E 1
Overall Network Volume Visibility
340. MB2.9 IPVS shall capture volume information throughout postal operations.
341. MB2.9.1
IPVS shall interface with Mail Booking Engine to capture volume originating at each post


office.
342. MB2.9.1.1 IPVS shall capture post office volume information by product type. E 1
343. MB2.9.1.2 IPVS shall capture post office volume information by origin/ destination combination E 1
344. MB2.9.2 IPVS shall capture volume information at all mail processing facilities.
345. MB2.9.2.1
IPVS shall capture volume information for accountable product types by summarizing scan
events.
E 1
346. MB2.9.2.2
IPVS shall capture volume information for non-accountable product types by accepting
weight measurements from connected scales.
E 1
347. MB2.9.2.3
For facilities with scales not connected to an IPVS workstation, IPVS shall capture volume
information for non-accountable product types by allowing users to enter the weight
displayed by the scale into the IPVS workstation for the unique bag bar code.
E 1
348. MB2.9.2.4 IPVS shall capture mail processing volume information by product type. E 1
349. MB2.9.2.5 IPVS shall capture mail processing volume information by origin/ destination combination. E 1
350. MB2.9.3 IPVS shall capture volume information in transit mail offices.
351. MB2.9.3.1
IPVS shall capture transmission volume information through bag scan events at offices that
have handheld scanners.
E 1
352. MB2.9.3.2
IPVS shall capture transmission volume information through weigh scales connected to the
IPVS terminal.
E 1
353. MB2.9.3.3
For sites with no handheld scanner or connected weigh scale, the IPVS terminal shall allow
users to enter counts of bags being transmitted.
E 1
354. MB2.9.3.4 IPVS shall capture transmission volume information by product type. E 1
355. MB2.9.3.5 IPVS shall capture transmission volume information by origin/ destination combination. E 1

356. MB2.9.4
IPVS shall interface with the Delivery and Postman Management System to capture
destination post office volume information.

357. MB2.9.4.1 IPVS shall capture delivery volume information by product type. E 1
358. MB2.9.4.2 IPVS shall capture delivery volume information by postman beat. E 1
Processing International Mail Articles
359. MB2.10 IPVS shall allow for additional processing for international mail articles.
360. MB2.10.1
IPVS shall generate UPU-standard receptacle labels for mail bags destined for a Foreign
Postal Administration (FPA).
(http://www.upu.int/standards/en/s8_and_s9_user_guide_on_postal_despatches-
postal_receptacles_en.pdf)

361. MB2.10.1.1
IPVS shall scan outbound items out into bags using the same process as domestic item
scanning.
E 1
362. MB2.10.1.2
The international receptacle label shall contain the UPU-standard 29-character receptacle
bar code.
E 1
363. MB2.10.1.3
The international receptacle label shall contain the assigned transportation information for
the bags routing from origin to destination.
E 1
364. MB2.10.1.4
The international receptacle label shall contain the F-bag identifier if the bag is the final bag
for the days dispatch.
E 1
365. MB2.10.1.5 IPVS shall generate UPU required forms & paperwork for each bag. E 1
366. MB2.10.2
IPVS shall generate UPU-standard EDI messages for outbound volume.
(http://www.upu.int/)

367. MB2.10.2.1 IPVS shall generate required PREDES messages for dispatches. E 1

368. MB2.10.2.2 IPVS shall generate required PRECON messages for consignments. E 1
369. MB2.10.2.3 IPVS shall generate required CARDIT messages for consignments. E 1
370. MB2.10.2.4 IPVS shall calculate terminal dues for dispatched volume. E 1
371. MB2.10.3
IPVS shall receive UPU-standard EDI messages for inbound mail volume.
(http://www.upu.int/)

372. MB2.10.3.1
IPVS shall translate data from FPAs PREDES messages to generate internal IPVS data for
reconciliation when volume arrives.
E 1
373. MB2.10.4 IPVS shall allow data entry of inbound receptacles.
374. MB2.10.4.1 IPVS shall scan receptacle labels from FPAs. E 1
375. MB2.10.4.2
IPVS shall scan inbound items out of bags using the same process as domestic item
scanning.
E 1
376. MB2.10.5 IPVS shall generate UPU-standard EDI messages for received inbound volume.
377. MB2.10.5.1 IPVS shall generate required RESDES messages for received dispatches. E 1
378. MB2.10.5.2 IPVS shall generate required RESCON messages for received consignments. E 1
379. MB2.10.5.3 IPVS shall generate required RESDIT messages for dispatches received. E 1
380. MB2.10.5.4 IPVS shall generate terminal dues for received volume. E 1
381. MB2.10.6
IPVS shall auto-generate electronic Verification Notes (VN) for FPAs when discrepancies are
identified between FPA PREDES versus received receptacles.

382. MB2.10.6.1
IPVS shall provide users capabilities to further research auto-generated VNs through
querying IPVS data.
E 1
383. MB2.10.7
IPVS shall provide users the ability to create manual VNs for additional discrepancies not
automatically identified within IPVS (i.e. terminal dues mismatch, incorrect rates,
E 1

incorrect weights, etc.)
384. MB2.10.8
The system shall capture the details of the parcels at the dispatching office of exchange on
a CP87 bill
E 1
385. MB2.10.9
The system shall send entries for bulk in the CP87 parcel bill to the destination
administration
E 1
386. MB2.10.10 The system shall inform origin administration in case of seizure of wrongly admitted parcel E 1
387. MB2.10.11
The system shall prepare a CP78 verification note for parcels retained due to damage or
theft
CP78 verification note
CN24 Report
E 1
388. MB2.10.12
The system shall interface with international systems to send the electronic proof of
delivery (image file with signature) received from DPMS
E 1
Creating and Opening Transit Bags
389. MB2.11
IPVS shall allow the user to create and open transit bags to and from other mail offices/post
offices with other bags nested inside.

390. MB2.11.1 IPVS shall allow the user to create transit bags with other bags nested inside.
391. MB2.11.1.1
The user shall build all the inside bags using the normal procedure before building a transit
bag.
E 1
392. MB2.11.1.2
Once the user selects the option to create the outer transit bag, the system shall prompt
the user to scan all inner bags.
E 1
393. MB2.11.1.3
After all inner bags have been scanned, the user shall scan the outer bag to complete the
transit bag creation.
E 1
394. MB2.11.1.4 The system shall validate that the destinations of all of the inner bags match. E 1

395. MB2.11.1.5
Throughout the rest of the network, any time an outer transit bag is scanned, all articles
associated with one of the nested inner bags shall receive an en route scan event.
E 1
396. MB2.11.2 IPVS shall allow the user to open transit bags with other bags nested inside.
397. MB2.11.2.1 IPVS shall allow users to scan the nested bags out of the transit bag. E 1
398. MB2.11.2.2 IPVS shall allow users to scan the individual articles out of the nested bags. E 1
Creating Bulk Delivery Bags
399. MB2.12
IPVS shall provide delivery office users the ability to create bags for delivery of bulk articles
to a single customer.

400. MB2.12.1
The user shall select the customer name of the bulk delivery and scan the articles for that
customer.
E 1
401. MB2.12.1.1
If the customer name does not already exist for the office, the user shall enter the name to
be stored for later use.
E 1
402. MB2.12.2 The user shall then scan all articles going into the customers bulk delivery bag. E 1
403. MB2.12.3
Once all articles have been scanned, the user shall scan the unique EB 2-9-2 bar code on the
bag.
E 1
End-of-Day Reports Created in IPVS
404. MB2.13 IPVS shall provide several end-of-day reports.
405. MB2.13.1 IPVS shall provide a detailed articles received report. E 1
406. MB2.13.2 IPVS shall provide a detailed articles dispatched report. E 1
407. MB2.13.3
IPVS shall provide a detailed discrepancy report between articles received and articles
dispatched.
E 1

408. MB2.13.4
IPVS shall provide a detailed discrepancy report between articles expected and articles
actually received.
E 1
409. MB2.13.5 IPVS shall provide a detailed volume received report. E 1
410. MB2.13.6 IPVS shall provide a detailed volume dispatched report. E 1
411. MB2.13.7
IPVS shall provide a detailed discrepancy report between volume received and volume
dispatched.
E 1
412. MB2.13.8
IPVS shall provide a detailed discrepancy report between volume expected and volume
actually received.
E 1
413. MB2.13.9 IPVS shall provide a per person IPVS usage/productivity report. E 1
Transferring Contents of One Bag into Another Bag
414. MB2.14
IPVS shall provide functionality to systemically transfer all data related articles associated
with one bag into another bag.

415. MB2.14.1
The user shall first scan the transferring bag then scan the bag into which the articles are
being transferred to complete this action.
E 1
416. MB2.14.2
If the bag into which the articles are being transferred already has associated
articles/destination, IPVS shall validate that the destination of the transferring bag matches
that of the destination bag.
E 1
Air Carrier Payment Calculation
417. MB2.15 IPVS shall centrally calculate payment amounts for mail transported by air carriers.
418. MB2.15.1
IPVS shall maintain contract requirements for agreements with air carriers transporting DoP
mail volumes.

419. MB2.15.1.1 IPVS shall maintain data containing price per kg/bag of mail assigned to each air carrier. E 1

420. MB2.15.1.2
The rates must be maintained at a level flexible enough to allow the following:
Different carriers can have different rates
Different lanes (origin/destination) can have different rates
E 1
421. MB2.15.2
IPVS shall calculate payment due to each carrier once per day for the prior day and any
prior days that had late arriving data that has not been paid.

422. MB2.15.2.1
Payment shall be calculated using the rate per kg/bag and multiplying by the associated
rates.
E 1
423. MB2.15.2.2 Every bag that has been paid shall be marked in the system as paid. E 1
424. MB2.15.2.3
In the case that a local scanner has not transmitted its data in time for the next-day
calculation, the system shall be able to look back at unpaid records and include their
payment in the payment calculated on the day it was received.
E 1
425. MB2.15.3
IPVS shall have the ability to turn on an interface of calculated payment by air carrier to the
Accounts Payable solution.

426. MB2.15.3.1
Payment details shall include kg/bags moved from each origin that were paid in this
payment.
E 1
427. MB2.15.3.2 The system shall also send the rates used for the payments. E 1
Confirming Article Counts Associated with MLASS Appointments
428. MB2.16
IPVS shall provide the capability to scan inbound bulk articles against an appointment ID
entered by the IPVS user that was created out by MLASS.

429. MB2.16.1 IPVS shall capture the total count of articles associated with the MLASS appointment. D 2
430. MB2.16.2
IPVS shall have an outbound interface to MLASS to send article counts related to the MLASS
appointment IDs.
D 2
Alerting/Escalation Capability

431. MB2.17 IPVS shall provide alerting/escalation capabilities for exception articles or bags.
432. MB2.17.1
IPVS shall display alerts on a management console/dashboard for articles that receive a
scan in a facility that is not along the articles expected path based on reference data
showing routings for each origin/destination combination (missorted articles).
E 2
433. MB2.17.2
IPVS shall display alerts on a management console/dashboard for articles that have not
received a scan after a configurable amount of time after their expected arrival at the next
destination, but articles that were associated with the same bag have received scans (lost
articles).
E 1
434. MB2.17.2.1
If IPVS later receives a scan event for a lost article, the alert shall still be maintained in the
system to later identify temporarily lost articles, but the lost article should no longer be
displayed on the management console/dashboard.
E 1
435. MB2.17.3
IPVS shall display alerts on a management console/dashboard for entire bags that receive a
scan in a facility that is not along the bags expected path based on reference data showing
routings for each origin/destination combination (misrouted bags).
E 2
436. MB2.17.4
IPVS shall display alerts on a management console/dashboard for entire bags that have not
received a scan after a configurable amount of time after their expected arrival at the next
destination (lost bags).
E 2
437. MB2.17.4.1
If IPVS later receives a scan event for a lost bag, the alert shall still be maintained in the
system to later identify temporarily lost bags, but the lost bag should no longer be
displayed on the management console/dashboard.
E 1
438. MB2.17.5
IPVS shall provide a configurable escalation mechanism where certain configurable alert
thresholds can trigger escalation of alerts to specific e-mail addresses or SMS mobile
numbers.
E 1
439. MB2.17.5.1
Escalation thresholds shall include the following:
Late bags (ability to group and filter by origin locations)
E 1

Misrouted bags (ability to group and filter by origin locations)
Lost bags (ability to group and filter by origin locations)
Configurable number of lost articles (ability to group and filter by origin locations)
Configurable number of misrouted articles (ability to group and filter by origin locations)
Recording of Articles Damaged in Processing
440. MB2.18 IPVS shall allow the user to record a scan event for a damaged article. E 2
Monitoring of Railways Transit Section
441. MB2.19 IPVS shall have the facility to provide report on the usage of Railways Transit section
442. MB2.19.1
IPVS shall have the feature to record the running status of transit section at the origin of
that section
D 1
443. MB2.19.2
IPVS shall have the feature to record the arrival status of transit section at the destination
of that section
D 1
444. MB2.19.3
IPVS shall have the facility to generate a status report of various transit sections (cancelled
or otherwise) for a specified period. This shall be used for verification of the bills sent by the
Railways
D 1
445. MBE
IPVS shall have an inbound interface from the MBE that loads Booked events for
accountable articles into IPVS so that expected downstream events can be tracked against
the article as the article physically moves through the network and receives downstream
tracking scans/events
E 2
446. DPMS
IPVS shall have an outbound interface to the DPMS that will share electronic manifests of
the bags heading to the Delivery Post Offices. IPVS shall have an inbound interface from
the DPMS that loads postman beat volumes and Attempted Delivery/Delivery events
from the postman scans/entries.
E 2

447. WMS
IPVS shall have an inbound interface for tracking events for articles moving out of
warehouse.
E 2
448. TMS IPVS shall have an inbound interface for tracking events captured within TMS E 2
449. MLASS
IPVS shall have an outbound interface to MLASS to send article counts related to an MLASS
appointment ID
E 2
450. LSS
IPVS shall have an outbound interface to send LSS actual employee work hours captured
within IPVS for comparison against the planned hours in LSS
E 2
451. HRMS
warehouse in the form of MIS reports. IPVS shall ensure that this detail is stored in the data
warehouse on a monthly basis
E 2
452. EDI
IPVS shall have an outbound and inbound interface for EDI messages exchanged between
DoP and Foreign Postal Administrations, Airlines, Customs etc.
E 2
453.
ECM
(PBS/PLI SI)
IPVS shall have an outbound interface with ECM to send international documents
generated/received
E 2
454. IM
IPVS shall have an outbound interface with Inventory Management to pass on the
information pertaining to the bags throughout the supply chain
E 2
455. Air Carriers
IPVS shall have an inbound interface with external agencies such as Air carriers to receive
the bag related information for tracking purpose. IPVS shall receive bag scan information
when the consignments are loaded onto the flight and unloaded from the flights.
D 2
Delivery & Postman Management System
Delivery & Postman Management Capabilities

456. MB4.1 DPMS shall provide delivery and postman management capabilities
Presenting Expected Work Load
457. MB4.2 DPMS shall create an expected work load status report for each day or shift.
458. MB4.2.1
DPMS report shall populate the list of expected accountable articles booked for the area
under a particular delivery office
E 1
459. MB4.2.1.1
For each expected accountable article, the system shall display the expected time of arrival
at the delivery office.
E 1
460. MB4.2.2 DPMS shall display the volume of incoming ordinary mail bags. E 2
461. MB4.2.3
DPMS shall provide scheduled pick-ups (customer requested specific time) to be assigned
to the postmen.
D 2
462. MB4.2.4
DPMS shall provide expected route pick-ups (customer just requested pickup on beat) for
each postman.
D 2
Capturing Data on Inbound Mail Items/Volume
463. MB4.3.1
DPMS shall scan the incoming ordinary mail bags on receipt (when RFID is enabled,
scanning/reading shall be done through RFID)
E 1
464. MB4.3.2 DPMS shall scan the incoming accountable mail bags on receipt E 1
465. MB4.3.3
DPMS shall use a configurable (by site) QA frequency value that indicates when the user
must scan each article in the accountable bag individually upon receipt (i.e. every 5
th
bag,
every 10
th
bag, every bag, etc.).
E 1
466. MB4.3.4
System shall have the functionality to scan the incoming bags through RFID system, when
RFID is deployed at facilities
D 2
Beat Level Sorting Data Capture/Holds/Beat Slips

467. MB4.4 DPMS shall capture details about articles per beat through article scanning and user entry.
468. MB4.4.1
After beat level sorting is complete, DPMS shall allow the user to scan accountable articles
that are to be held in the office based on customer requests.
E 1
469. MB4.4.2
After Hold articles are recorded, DPMS shall allow the user to scan each accountable
article for creation of the postmans beat slip.

470. MB4.4.2.1
If the postman is removing any held articles from Hold status to include them on that
days beat, DPMS shall simply allow the user to scan the held articles while scanning the
rest of the articles for the beat slip.
E 1
471. MB4.4.2.2
DPMS shall create a beat slip for each postman that sequentially (alphabetically then
numerically) lists each accountable article for the beat including the following per article:
Printed bar code of the article
Human readable number of the bar code
Space for postman to record time of delivery/attempted delivery
Space for recipients printed name
Space for recipients signature (N/A if signature not required for that article
E 1
472. MB4.4.3
After all beat slips have been created, DPMS shall provide functionality where the
supervisor can view the discrepancies between the expected manifests and the actual
accountable articles received across all office postmen.
E 2
473. MB4.4.4 DPMS shall capture the number of Business Reply Mail pieces per mailer. E 1
474. MB4.4.5
DPMS shall capture the number of Speed Post Value Payable pieces per postman after beat
sorting.
E 1
475. MB4.4.5.1
When the user enters the number of Speed Post Value Payable pieces per postman, the
system shall also capture the total value of the pieces.
E 1
476. MB4.4.6 DPMS shall capture the total number of ordinary mails per postman after beat sorting. E 1

477. MB4.4.7
DPMS shall calculate the total number of accountable articles based on the beat slip
creation scanning.
E 2
478. MB4.4.8
For bulk delivery bags, the user shall scan the bag before taking the bag out for delivery to
indicate all the contents in the bag are being delivered.
E 1
On-Beat Delivery Scanning, Data Entry, and Window Delivery
479. MB4.5
DPMS shall allow delivery scanning on the beat or at the post office window through the
use of a handheld scanning device.

480. MB4.5.1
The device shall allow the user to scan individual accountable articles when they are
delivered.
E 1
481. MB4.5.1.1 The device shall record the time the scan is performed as the time of delivery (I scan event). E 1
482. MB4.5.1.2
If proof of delivery is required, the device shall prompt the user to enter the first initials and
full last name of the recipient. It should provide the addressee name; however, it should
also have an option of overriding the same as the recipient may be different.
E 1
483. MB4.5.1.3
If proof of delivery is required, the device shall provide the capability of taking an image of
the signature on a signed delivery confirmation form for e-Proof-of-Delivery.
E 1
484.
MB4.5.1.3.
1
The device shall similarly provide the capability for the recipient to sign on-screen for e-
Proof-of-Delivery.
E 1
485. MB4.5.2
If the article cannot be delivered, the device shall allow the user to scan individual
accountable articles as attempted delivery.
E 1
486. MB4.5.2.1
The device shall record the time the scan is performed as the time of attempted delivery (H
scan event).
E 1
487. MB4.5.3
All data recorded on the beat shall be stored on the device until the data has been synced
to the server in the office.
E 1

488. MB4.5.4
The device shall transmit data collected on beat once it is cradled back at the office or
wirelessly connected.
E 2
489. MB4.5.5
For articles requiring payment collection when delivered, the DPMS shall capture
information relating to the payment.

490. MB4.5.5.1 The system shall capture the article ID that is being paid. E 1
491. MB4.5.5.2 The system shall capture the amount of cash collected. E 1
492. MB4.5.5.3
The system shall have an outbound interface to Accounts Receivable confirming that the
article has been paid to clear the amount outstanding.
E 1
Post-Beat Delivery Scanning and Data Entry
493. MB4.6
DPMS shall allow delivery scanning after the postman has returned from the beat through
the use of a handheld scanning device and their completed beat slip if the postman did not
have a device on their beat.

494. MB4.6.1
The device shall allow the user to scan individual accountable articles from their beat slip to
record their delivery (I scan event).
E 1
495. MB4.6.1.1
The device shall prompt the user to enter the time the article was delivered according to
the beat slip.
E 1
496. MB4.6.1.2
If proof of delivery is required, the device shall prompt the user to enter the first initials and
full last name of the recipient. It should provide the addressee name; however, it should
also have an option of overriding the same as the recipient may be different.
E 1
497. MB4.6.1.3
If proof of delivery is required, the device shall prompt the user to take an image of the
signature with the device from the signed beat slip for e-Proof-of-Delivery.
E 1
498. MB4.6.2
If the article could not be delivered on the beat, the device shall allow the user to scan
individual accountable articles as attempted delivery.
E 1

499. MB4.6.2.1
The device shall record the time the scan is performed as the time of attempted delivery (H
scan event).
E 1
500. MB4.6.3
All data recorded shall be stored on the device until the data has been synced to the server
in the office.
E 1
501. MB4.6.4 The device shall transmit data collected it is cradled or wirelessly connected. E 2
502. MB4.6.5
For articles requiring payment collection when delivered, the DPMS shall capture
information relating to the payment.

503. MB4.6.5.1 The system shall capture the article ID that is being paid. E 1
504. MB4.6.5.2 The system shall capture the amount of cash collected. E 1
505. MB4.6.5.3
The system shall have an outbound interface to Accounts Receivable confirming that the
article has been paid to clear the amount outstanding.
E 1
506. MB4.6.6
The system shall display articles that have been in the office longer than a configurable
number of days.
E 1
507. MB4.6.6.1
If the original sender requested Return Service for the article, the system shall allow the
user to scan the article and create a new record in the tracking database with the same bar
code for the returning article.
E 1
End-of-Day Reports
508. MB4.7 DPMS shall provide several end-of-day reports.
509. MB4.7.1
DPMS shall summarize the scan compliance of the articles due for delivery that day
(expected Delivery scans vs. Delivery and Attempted Delivery actuals).
E 2
510. MB4.7.2 DPMS shall display all items currently on hold in the office. E 1
511. MB4.7.2.1 DPMS shall display how long the held items have been on hold. E 1

512. MB4.7.3
DPMS shall display undeliverable articles in the office (those with an Attempted Delivery
but no successful Delivery event).

513. MB4.7.3.1
DPMS shall display articles that have been in the office longer than a configurable number
of days.
E 1
514. MB4.7.3.2
DPMS shall display articles that are in the office with more than a configurable number of
Attempted Delivery events.
E 1
Capturing Employee Work Hours
515. MB4.8 DPMS shall capture employee work hours.
516. MB4.8.1 DPMS shall provide the user the ability to record their shift begin time. E 1
517. MB4.8.2 DPMS shall provide the postmen the ability to record when they leave to go on their beat. E 1
518. MB4.8.3 DPMS shall provide the postmen the ability to record when they return from their beat. E 1
519. MB4.8.4 DPMS shall provide the user the ability to record their shift end time. E 1
520. MB4.8.5
DPMS shall provide the supervisors the ability to make updates to employee shift
begin/end times.
E 1
Data Transmission to IPVS
521. MB4.9 DPMS shall interface with IPVS.
522. MB4.9.1 DPMS shall interface with IPVS to send article tracking information captured in DPMS. E 1
523. MB4.9.2 DPMS shall interface with IPVS to send inbound mail volumes captured in DPMS. E 1
524. MB4.9.3 DPMS shall interface with IPVS to send employee work hour details captured in DPMS. E 1
525. MB4.9.4
DPMS shall interface with IPVS to receive inbound bag manifests captured in IPVS for
validation through DPMS.
E 1

526. MB4.9.5 DPMS shall interface with IPVS to send electronic proof of delivery for international mail E 1
International-Specific Notifications
527. MB4.10 DPMS shall allow electronic capture of international-specific notifications.
528. MB4.10.1
The system shall provide for an electronic form CN24 in case the article is damaged or
rifled.
E 1
529. MB4.10.2
The system shall enable an office to give the reason for non delivery on an electronically
generated CN15 form.
E 1
Printing ePost Articles
530. MB4.11
DPMS shall allow a user to print ePost items to be delivered by their office or their
associated smaller offices.

531. MB4.11.1
DPMS shall receive an inbound interface from the Mail Booking Engine for ePost articles
that are to be printed for the receiving customer.
E 1
532. MB4.11.2 DPMS shall print the recipients name and address on the ePost article. E 1
533. MB4.11.3 DPMS shall print the senders name on the ePost article. E 1
Printing Online or Phone Booked Article Labels before the Beat
534. MB4.12
DPMS shall have an inbound interface from the Mail Booking Engine to receive details of
articles that were booked online or over the phone prior to the postman going on the beat
that require an article label.

535. MB4.12.1
DPMS shall display the expected pickup articles requiring a printed label to the in-office
clerk sorter performing the original beat-level sorting.
D 2
536. MB4.12.1
DPMS shall allow the user to print all expected pickup labels so that the labels can be sorted
to the individual postman beats.
D 2

537. MB4.12.2
The labels shall include the following information:
Sender Name
Sender Address
Recipient Name
Recipient Address
Postage Due
Unique Article Bar Code and Human Readable ID
D 1
538. MB4.12.3
Printing the bar code label shall trigger the transfer of data back to DPMS and the creation
of the booking event in the system that shall be sent to IPVS.
D 1
539. MB4.12.3.1
DPMS shall include booking events for pickup articles in the outbound interface to IPVS
with delivery events.
D 1
540. MB4.12.4
Upon return to the office, the system shall provide a mechanism for the postman to
reconcile the cash collected for the pickup articles.
E 1
Printing Online or Phone Booked Article Bar Code Labels on the Beat
541. MB4.13
DPMS shall have an inbound interface from the Mail Booking Engine to receive details of
articles that were booked online or over the phone prior while the postman is on the beat
for pickup at a location on the postmans remaining beat.

542. MB4.13.1
The device shall display the SMS received from the Mail Booking Engine with the pickup
location information.
D 1
543. MB4.13.1.1
The device shall add the pickup location and details to the device database so the user can
easily reference the required pickups.
D 1
544. MB4.13.2
When the postman selects the pickup record after arriving at the pickup location, the
system shall display the amount of postage due for the article.
D 1

545. MB4.13.3
When the postman has confirmed receipt of cash payment, the system shall print the bar
code label to be affixed to the already addressed package.
D 1
546. MB4.13.4
Printing the bar code label shall trigger the transfer of data back to DPMS and the creation
of the booking event in the system that shall be sent to IPVS.
D 1
547. MB4.13.4.1
DPMS shall include booking events for pickup articles in the outbound interface to IPVS
with delivery events.
D 1
548. MB4.13.5
Upon return to the office, the system shall provide a mechanism for the postman to
reconcile the cash collected for the pickup articles.
E 1
Delivering Money Orders
549. MB4.14 The system shall enable the office to dispense Money Orders.
550. MB4.14.1
The Type 2 MO transaction (money available for pickup at any connected Post Office)
should be accessible across the country for payout.
E 1
551. MB4.14.2
The MO transactions to be delivered to a doorstep shall appear in the delivery branch
queue of MO payments to be made on that day.
E 1
552. MB4.14.2.1 System should be able to print the individual MO request with all the details. E 1
553. MB4.14.2.2
System should be able to generate a Bar Code containing the original unique ID on the
printed MO request.
E 1
554. MB4.14.2.3
The system shall be able to generate a unique bar code as per the format specified
compatible with DPMS (13 character code 2 character for money order product code MO,
9 digits for unique number generated and last 2 character would be IN)
E 1
555. MB4.14.3 The system shall reconcile paid Money Orders through a Delivery scan of the MO bar code. E 1
556. MB4.14.4
System shall allow the destination branch to Return the MO transaction from its queue to
the sender in case the beneficiary does not exist/relocated to unknown address.
E 1

557. MB4.14.4.1 The system shall generate an SMS informing the sender of the return. D 1
558. MB4.14.5
System shall allow the destination Branch to Redirect the MO transaction to another
delivery branch which is closer to the Beneficiary destination.
E 1
559. MB4.14.5.1
The system shall generate an SMS informing the sender and beneficiary of the redirection
to a different office/address.
D 1
560. MB4.14.6
If the Money Order has not been collected within 5 months, the system shall send an SMS
informing the sender and beneficiary that the Money Order has still not been collected.
D 1
561. MB4.14.7
The system shall send another SMS to the sender and beneficiary 2 weeks before the 6
month expiration period if the Money Order has still not been collected.
D 1
562. MB4.14.8
The system shall send a final SMS to the sender and beneficiary once the 6 month
expiration period has ended for the sender to come back to the originating office and
collect the funds.
D 1
Recording a Redirected Article
563. MB4.15
The system shall allow postmen to record a scan event when the article needs to be
redirected to a new address because the recipient has moved.
E 1
564. MB4.15.1
The system shall require the postman to enter the new address so that the system can
maintain where the article was redirected for customer complaint management.
E 1
Dues Collection
565. MB4.16 DPMS shall enable collection of dues from recipients
566. MB4.16.1 DPMS shall enable creation of daily list of dues to be collected (due postage, customs duty) E 1
567. MB4.16.2 DPMS shall facilitate data entry confirming collection of due postage at the end of day E 1
568. MB4.16.3
For international mail, DPMS shall indicate the customs duty to be collected from the
E 1

recipient
569. MB4.16.4
DPMS shall have an outbound interface to Accounts confirming the dues collected under
various heads
E 1
570. MBE
DPMS shall have an inbound interface from the MBE to receive the retail customer pickup
requests to be incorporated with Postmen beats (data including customers pick up
address, type of service, postage due). It shall also have an inbound interface from the MBE
to receive individual customer article pickup requests that require the postman to print a
label before their beat or while on their beat.
E 2
571. IPVS
DPMS shall have an inbound interface from IPVS to receive inbound mail volumes, inbound
bag manifests, and inbound accountable article information. DPMS shall have an outbound
interface to IPVS to send article tracking events (including captured signature if required)
and employee work hour information.
E 2
572. AR
DPMS shall have an outbound interface with AR module to update the Business Reply Mail
customer accounts for the services provided to enable billing and to record money
collected for all successfully delivered payment due articles. This module will also capture
the type of Business Reply Mail opted for by the customer based on which the charges shall
be applied.
E 2
573. GL
DPMS shall have an outbound interface to the GL Solution to send all of the cash-collection
transactions for articles requiring payment on delivery.
E 2
574. HRMS
warehouse in the form of MIS reports. DPMS shall ensure that this detail is stored in the
E 2

data warehouse on a monthly basis.
Transportation Management System
Managing Fleet of Vehicles
575. MB6.1 TMS shall manage the fleet of all vehicles owned by DoP.
576. MB6.1.1 TMS shall maintain a list of all vehicles owned by DoP. E 1
577. MB6.1.1.1 TMS shall register all the vehicles into the system. E 1
578. MB6.1.1.2
TMS shall maintain vehicle details (registration numbers, make, year) along with the facility
it belongs to.
E 1
579. MB6.1.2 TMS shall establish the overall fleet capacity of DoP.
580. MB6.1.2.1 TMS shall maintain a repository of available fleet capacity of DoP owned vehicles for MMS. E 1
581. MB6.1.2.2
TMS shall maintain a repository of available fleet capacity of hired/contracted vehicles for
MMS.
E 1
582. MB6.1.3 TMS shall review the transportation capacity requirements of DoP.
583. MB6.1.3.1
TMS shall assess the short-term transportation requirements (for the immediate execution)
based on the scheduling requests received.
E 1
584. MB6.1.3.2
TMS shall highlight any gaps in available capacity and the short-term transportation
requirements based on the scheduling requests received.
E 1
585. MB6.1.3.3 TMS shall assess the long-term transportation requirements based on the business plans. E 1
586. MB6.1.3.4
TMS shall highlight any gaps in available capacity and the long-term transportation
requirements based on the business plans.
E 1
587. MB6.1.4 TMS shall plan/manage the maintenance of the fleet.

588. MB6.1.4.1 TMS shall plan/manage the maintenance of DoP owned fleet.
589.
MB6.1.4.1.
1
TMS shall prepare a detailed maintenance plan for DoP owned fleet. E 1
590.
MB6.1.4.1.
2
TMS shall schedule this maintenance into the overall transportation schedule. E 1
591.
MB6.1.4.1.
3
TMS shall track the adherence to this maintenance plan by preparing a planned versus
actual report.
E 1
592. MB6.1.4.2 TMS shall review the maintenance of the hired/contracted vehicles.
593.
MB6.1.4.2.
1
TMS shall maintain a maintenance plan agreed with the contractor. D 1
594.
MB6.1.4.2.
2
TMS shall track the status of the maintenance plan for its implementation. D 1
595.
MB6.1.4.2.
3
TMS shall highlight non-adherence to the relevant authorities. D 1
Vehicle Tracking
596. MB6.2
TMS shall have the capability to later provide a telematics/GPS/RFID based solution for
track & trace purpose

597. MB6.2.1
For DoPs own vehicles, TMS shall provide telematics solution to capture the various
operating parameters
D 1
598. MB6.2.2
For the entire fleet (owned and hired) TMS shall have the functionality of providing
GPS/RFID based track & trace solution

599. MB6.2.2.1 TMS shall uniquely identify each vehicle through an RFID or GPS device D 1

600. MB6.2.2.2
For hired vehicles, TMS shall be able to provide a unique identifier to the vehicle by loading
a bag with RFID/GPS inside the vehicle
D 1
601. MB6.2.2.3 TMS shall provide the vehicle-wise report on deviation from the approved route D 1
Scheduling Vehicles
602. MB6.3 TMS shall schedule vehicles (pickup and delivery) as per the scheduling requirements.
603. MB6.3.1 TMS shall receive scheduling requirements. E 1
604. MB6.3.2 TMS shall review the vehicle availability. E 1
605. MB6.3.3 TMS shall incorporate the maintenance plan into the vehicle scheduling. E 1
606. MB6.3.4 TMS shall allocate vehicles to various routes as per the optimized schedule. E 1
607. MB6.3.5 TMS shall perform online contingency management. E 1
Managing Payments
608. MB6.4 TMS shall facilitate contractor payments
609. MB6.4.1
TMS shall have inbound interface with the AP for receiving the invoice details raised by
vehicle contractors for the services performed by them for DoP
E 1
610. MB6.4.2
TMS shall have the ability to process and validate these invoices based on the actual
services performed and agreed rates.
E 1
611. MB6.4.3
TMS shall have an outbound interface with AP for passing on the confirmation on the
invoice for the payment processing
E 1
Route Management
612. MB6.6 TMS shall manage the routes of the vehicle to be followed.
613. MB6.6.1
TMS shall obtain the volume of mail/consignment flow between various facilities (collected
E 1

through IPVS).
614. MB6.6.2 TMS shall determine the route parameters (pick up, locations, volumes). E 1
615. MB6.6.3
TMS shall identify network and route options and select the most optimal route by
performing cost evaluation.
E 1
616. MB6.6.4 TMS shall generate pick-up and delivery plan. E 1
617. MB6.6.5 TMS shall re-route vehicle to manage contingencies. E 1
Interface with other systems
618. MB6.7 TMS shall interface with other systems
619. MB6.7.1 TMS shall have interface with IPVS
620. MB6.7.1.1 TMS shall have outbound interface with IPVS to provide visibility on goods being carried E 1
621. MB6.7.1.2
TMS shall have inbound interface with IPVS for the volume of mails/consignments being
handled between various network nodes (facilities)
E 1
622. MB6.7.2
TMS shall have inbound interface with MLASS to receive requests for the pick-up from
customer premises
D 1
623. IPVS
TMS shall have an outbound interface with IPVS to send transmission events on the volume
of mails/consignments being handled between various facilities
E 2
624. MLASS
TMS shall have an inbound interface with MLASS to determine transportation availability
and to receive requests from the customer for pick-up
E 2
Mailer & Logistics Appointment Scheduling
Scheduling Appointment through Multiple Channels

625. MB3.1 MLASS shall provide multiple channels for customers to schedule appointments
626. MB3.1.1 MLASS shall allow web-based appointment scheduling for pickup or drop E 1
627. MB3.1.2 MLASS shall allow phone-based appointment scheduling for pickup or drop E 1
628. MB3.1.3
MLASS shall allow customer to make an appointment in person at the post office / Logistics
Post centre
E 1
629. MB3.1.4 MLASS shall capture sender details
630. MB3.1.4.1 MLASS shall capture mobile phone contact details E 1
631. MB3.1.4.2 MLASS shall capture email address E 1
632. MB3.1.4.3 MLASS shall capture postal address E 1
633. MB3.1.5 MLASS shall validate services
634. MB3.1.5.1
MLASS shall have an outbound interface with IPVS to pass on services selected during the
appointment scheduling
E 1
635. MB3.1.6 MLASS shall capture consignment information
636. MB3.1.6.1 MLASS shall capture number and weight of the consignment E 1
637. MB3.1.6.2 MLASS shall capture the approximate volume (size) of the consignment E 1
638. MB3.1.7 MLASS shall display tentative time and date in case of a pickup request
639. MB3.1.7.1 MLASS shall determine the nearest Post office or LPC that will service the request E 1
640. MB3.1.7.2
MLASS shall have outbound interface with TMS for providing the pick-up related
information for the TMS to schedule the pickup
E 1
641. MB3.1.7.3
MLASS shall have inbound interface with TMS for receiving tentative time and date for the
pickup
E 1

642. MB3.1.7.4
MLASS shall provide the multiple options of tentative pickup times and prompt the
customer to select one
E 1
Address Memory
643. MB3.2.1
MLASS shall create a senders address memory so that frequently entered addresses can
be presented as remembered options to the user as the address characters are entered.
D 1
644. MB3.2.2
MLASS shall store previously entered shipper addresses belonging to a corporate customer
account
D 1
645. MB3.2.3 MLASS shall allow the corporate customer to select the appropriate address D 1
646. MB3.2.4
MLASS shall display remembered address options to the user who shall be able to select
one of the options such that the remaining address information is auto-populated by the
system.
D 1
Booking Confirmation
647. MB3.3
MLASS shall complete the appointment request transaction by confirming receipt of
payment or intent of payment at dropoff/pickup.

648. MB3.3.1 MLASS shall log an appointment in the database upon confirmation of payment E 1
649. MB3.3.2
MLASS shall send an electronic (mail/SMS) confirmation (if requested) of successful
appointment transaction
D 1
650. MB3.3.3
If the appointment was made in person, the MLASS shall provide the customer with a
printed receipt
E 1
651. MB3.3.4
MLASS shall provide blank electronic copies of all necessary documentation ((i.e. - customs
declaration etc. - Input taken from the services selected for the articles, could be speed
post / international, COD etc) for usage by the sender
E 1
Appointment Reminder

652. MB3.4 MLASS shall proactively send out the SMS/email appointment reminders if requested
653. MB3.4.1
MLASS shall send reminder at various time buckets e.g. 8hrs prior to appointment to the
shipper / sender
D 1
654. MB3.4.2 MLASS shall also send details about the transaction in the reminder D 1
Appointment Cancellation
655. MB3.5 MLASS shall process cancellation requests.
656. MB3.5.1 MLASS shall have an option to put in a cancellation request. E 1
657. MB3.5.2 MLASS shall receive the transaction details provided by the sender for cancellation. E 1
658. MB3.5.3 MLASS shall track cancelled appointments.
659. MB3.5.3.1 The system shall allow appointment cancellations 48 hours prior with no system penalty. E 1
660. MB3.5.3.2
For cancellations within 48 hours, the system shall mark the appointment as cancelled
with penalty.
E 1
661. MB3.5.3.3 For no-shows, the system shall mark the appointment as no show. E 1
662. MB3.5.3.4
If the customer has a configurable number of cancelled with penalty and no show
appointments, they shall only be given less desirable appointment times.
E 1
663. MB3.5.4 MLASS shall have an outbound interface with TMS for updating the schedule E 1
Appointment Rescheduling
664. MB3.6 MLASS shall accept rescheduling requests and changes to transaction
665. MB3.6.1
MLASS shall re-execute the appointment scheduling process to when an appointment
rescheduling request is submitted by the customer
E 1
Payment Processing

666. MB3.7
MLASS shall collect payments (through redirection to the payment gateway) from the
customer if the customer chooses to pay ahead of time for the incoming shipment.

667. MB3.7.1
MLASS shall maintain data related to the customer account and their current balance so
that the Accounts modules do not have to be read from for every transaction.
E 1
668. MB3.7.2 MLASS shall collect advance payments for collection charges. E 1
669. MB3.7.2.1 MLASS shall collect advance payments for drop charges.
670. MB3.7.3 MLASS shall provide numerous payment options. E 2
671. MB3.7.4 If appointment is being made at the counter, MLASS shall accept cash payments. E 1
672. MB3.7.4.1 MLASS shall calculate required change to be returned to the customer. D 1
673. MB3.7.5 If appointment is being made at the counter, MLASS shall accept cheque payments. E 1
674. MB3.7.6 The online version of MLASS shall accept credit card payments. E 1
675. MB3.7.7 The online version of MLASS shall accept debit card payments. E 1
676. MB3.7.7.1 The online version of MLASS shall allow the customer to enter their debit card PIN code.
677. MB3.7.8 At the counter or in the online version, MLASS shall accept ATM card payments. E 1
678. MB3.7.8.1 The system shall allow the customer to enter their ATM card PIN code.
679. MB3.7.9
MLASS shall have the ability to debit the corporate customer account for the services
performed for the customer.
E 1
680. MB3.7.9.1
MLASS shall send a debit transaction with the customer ID, debit amount, and transaction
details to the AR module for debit from their account.
E 1
681. MB3.7.10 MLASS shall have the ability to accept pre-payment for the shipments. E 1
682. MB3.7.10.1
MLASS shall send a credit transaction with the customer ID and credit amount to the
E 1

Accounts Payable module for credit to their account.
683. MB3.7.11
If the interface from IPVS for the appointment ID shows that MORE pieces than were in the
electronic manifest were actually inducted, the system shall send another debit transaction
to the Accounts Receivable module for the discrepancy amount.
E 2
684. MB3.7.12
If the interface from IPVS for the appointment ID shows that FEWER pieces than were in the
electronic manifest were actually inducted, the system shall allow a customer to either
request a refund or leave the funds in their account for a future shipment.
E 1
685. MB3.7.12.1
If the customer requests a refund through the online MLASS module, the system shall send
a request for refund for the amount specified by the user to the Accounts Payable module
that will issue the refund to the user.
E 1
686. MB3.7.12.2
If the customer requests a refund through the post office counter MLASS module and the
refund is less than a configurable limit, the user shall provide the customer the cash due
and the system shall send a debit transaction to the Accounts module to reflect the refund
against the customer IDs balance.
E 1
687. MB3.7.12.3
If the customer requests a refund through the post office counter MLASS module and the
refund is more than a configurable limit, the system shall send a request for a refund for
the amount specified by the user to the Accounts Payable module that will issue the refund
to the user.
E 1
688. MB3.7.12.4
If the customers account exceeds a configurable threshold of amount due, the user shall
instruct the customer that the booking cannot be accepted without payment of the amount
due
E 1
689. MB3.7.12.5
If the customers account is in default because a payment was missed, the user shall
instruct the customer that the booking cannot be accepted without payment of the amount
due.
E 1
Customer Management

690. MB3.8
MLASS shall allow for new customer creation if the customer does not already have an DoP
credit or debit account. This information must be maintained locally and centrally (for
distribution to other local servers).
E 1
691. MB3.8.1
The system shall capture company name, contact information, company funds approver,
and all other fields per the standard DoP customer application form.
E 1
692. MB3.8.2
If the customer is government or semi-government, their account may be opened as a
Book-Now-Pay-Later customer.
E 1
693. MB3.8.3
If the customer provides a deposit of predetermined amount through one of the payment
options, they shall be setup as a BNPL customer.
E 1
694. MB3.8.4
The system shall send a new customer record to the Customer Database and receive back a
unique customer ID that can be provided to the customer for future use.
E 1
695. MBE
MLASS shall have an outbound interface to MBE to send booking requests and then receive
an inbound interface to receive transaction payment confirmation.
E 2
696. IPVS
MLASS will interact with the IPVS to log the type of services requested for the articles,
provide the checklist and documentation in electronic format when bulk mailers are
sending international parcels, accountable articles etc. and show the status of the shipment
transaction (pick-up/drop/store).
E 2
697. WMS
MLASS will pass on information on weight, volume, dimensions and number of articles to
the WMS and will check space availability. Once appointment is confirmed, the storage
space is blocked in the WMS for a particular confirmation id, customer id and time duration
D 2
698. TMS
MLASS will interact with TMS to find out the tentative vehicle availability for a particular
date, time, facility id, location name, customer address, service type (pick-up/drop/store)
and route id
D 2

699. GL
MLASS will interface with Accounts Receivable to receive customer credit details (i.e.
credit owed, credit limit, etc.) and to send customer charges, BNPL details, and summaries
of revenue by category (mail shipments, logistics shipments, etc.).
E 2
700.
Customer
Database
MLASS will interface with the customer database of existing customers to determine if
customer already exists. If the customer does not exist, CRM will create a new customer
account and provide the new unique number.
E 2
701. HRMS
warehouse in the form of MIS reports. MLASS shall ensure that this detail is stored in the
data warehouse on a monthly basis
E 2
Sort Program System
Maintaining List of Sort Programs
702. MB7.1 SPS shall maintain mail processing sort programs in a centralized data store.
703. MB7.1.1
SPS shall store automated equipment sort programs with the following attributes:
Facility ID
Sort program name
Work operation
E 1
704. MB7.1.2
SPS shall store at least the following bin details for each bin in a sort program:
Bin name
Bin contents (associated PIN codes)
Bin destination facility ID
E 1
Sort Program Creation/Edit/Delete/Upload/Modification

705. MB7.2 SPS shall provide a sort program upload capability.
706. MB7.2.1
SPS shall allow the user to upload a Microsoft Excel sort program that matches a certain
pre-determined format.
E 1
707. MB7.2.2
SPS shall allow the user to upload a text file sort program that matches a certain pre-
determined format.
E 1
708. MB7.2.3
SPS shall provide a capability to let the user manually enter/create a sort program within
the system.
E 1
709. MB7.2.4
Upon completion/upload of a sort program, SPS shall validate that, at a minimum, all PIN
codes are assigned to one and only one bin.
E 1
710. MB7.2.5 SPS shall allow users to delete sort programs when they are no longer in use. E 1
711. MB7.2.6 SPS shall allow users to modify existing sort programs as per new requirements E 1
Viewing Sort Programs at Higher Level Office
712. MB7.3 SPS shall allow a reporting office user to view all reporting office sort programs.
713. MB7.3.1
Upon a facility sort program upload/edit, SPS shall notify the responsible office (district or
circle) that a change has been made.
E 1
714. MB7.3.2 SPS shall require responsible office approval for sort program uploads/edits. E 1
National Sort Program Templates
715. MB7.4 SPS shall maintain nationwide sort program templates created by HQ users.
716. MB7.4.1
Nationwide sort program templates shall be stored within the system for individual
facilities to have a starting point to create their site-specific sort programs.
E 1
717. MB7.4.2 HQ users shall be able to create sort program templates for use by specific facilities. E 1

718. MB7.4.3
SPS shall notify stored site users on their e-mail addresses when a new nationwide
template has been created.
E 1
719. MB7.4.4
SPS shall allow new templates to be created using any facilitys existing sort program as a
template (copy/paste/edit functionality).
E 1
Labour Scheduling System
Storing Employee Work Schedule Details
720. MB8.1
LSS will store employee work schedule details in order to enable matching work load
requirement and employee availability.

721. MB8.1.1
LSS will interface with the HR system to obtain employee details (including employee ID,
assigned facility, level) for all employees assigned to a mail operations facility (i.e. post
office, mail processing centre, transit mail office, etc.).
E 1
722. MB8.1.2
LSS will allow users to enter the following information for employees: On-the-Job Skills &
Competencies, Discontinue Date, Work Assignment, Scheduled Work Hours, Scheduled
Leaves, Scheduled Days Off
E 1
723. MB8.1.3 LSS will obtain the job description of different roles from the HR system. E 1
Interface to Receive Actual Employee Work Details
724. MB8.2 LSS will interface with IPVS to obtain actual employee work details.
725. MB8.2.1 LSS will interface with IPVS to obtain actual employee work hours. E 1
726. MB8.2.2
LSS will assume the employee is on leave if the interface with IPVS returns no actual work
hours on a given day.
E 1
Workforce Operational Reporting
727. MB8.3 LSS will provide complete visibility into the scheduling of the entire workforce

728. MB8.1 LSS will provide users with scheduling details at various levels E 1
729. MB8.1.1 LSS will provide the scheduling details of every employee E 1
730. MB8.1.2 LSS will provide the scheduling details of all offices E 1
731. MB8.1.3 LSS will provide the scheduling details of all departments E 1
732. MB8.1.4 LSS will provide the scheduling details of all functions E 1
733. MB8.1.5 LSS will provide the scheduling details of all levels E 1
734. MB8.2 LSS will provide operational report data on actual vs. expected work load at different offices E 2
735. MB8.3 LSS will provide operational report data on the productivity of the employees E 2
736. HR
LSS will interface with HR system to obtain data related to employee work details, role
description and recruitment.
E 2
737. IPVS
LSS will have an inbound interface from IPVS to receive actual employee work hours. This
interface will also provide workload and productivity for employees and different entities.
E 2
7.2.4.2 Logistics Post
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Warehouse Management System

Warehouse Storage
1. 2 MB5.1 WMS shall enable storage of all the items in the Warehouse.
2. MB5.1.1 WMS shall uniquely identify all the storage locations available.
3. MB5.1.1.1
WMS shall have a central repository of all storage locations available across the various
facilities in the entire supply chain.
E 1
4. MB5.1.1.2 WMS shall further break-down the facilities into easily identifiable storage locations. E 1
5. MB5.1.1.3 WMS shall provide the storage locations unique ids. E 1
6. MB5.1.2 WMS shall read the barcodes provided by the business partners on items. E 1
7. MB5.1.3 WMS shall slot all items based on various categories pre-defined in the system.
8. MB5.1.3.1 WMS shall maintain a list of categories (voluminous, heavy, size etc.). E 1
9. MB5.1.3.2 WMS shall categorize each item into one of these categories. E 1
10. MB5.1.4 WMS shall allocate unique storage locations to each item to be stored.
11. MB5.1.4.1
WMS shall allocate storage location to items based on velocity, size and material
classification.
E 1
12. MB5.1.4.2 WMS shall allocate storage location to items based on storage space availability. E 1
Order Receipt
13. MB5.2 WMS shall receive replenishment orders.
14. MB5.2.1 WMS shall receive orders from business partners
15. MB5.2.1.1 WMS shall have inbound interface with external business partners system. D 1
16. MB5.2.1.2 WMS shall have defined link with the business partners software. D 1

17. MB5.2.1.3
WMS shall receive & combine orders from same customer originating at different
locations.
D 1
18. MB5.2.1.4 WMS shall capture the order details (quantity, destination, date for replenishment) D 1
19. MB5.2.1.5
WMS shall have an inbound interface with MLASS to receive information about the volume
of material expected to come into the system for a defined period.
D 1
20. MB5.2.2 WMS shall receive orders from India Post Mail Booking Engine
21. MB5.2.2.1
WMS shall receive intimation when a customer buys an articles/collection of articles on the
DoP portal
E 1
22. MB5.2.2.2
WMS shall receive the order details such as date of delivery, item ID, quantity, destination
address
E 1
23. MB5.2.3 WMS shall replenish the Retail Post stock maintained at the various DoP facilities
24. MB5.2.3.1
WMS shall maintain a stock of Retail Post inventory at each of the facilities and update it
with any sale transaction
E 1
25. MB5.2.3.2
WMS shall prompt re-order based on the pre-defined minimum stock levels for different
facilities
E 1
26. MB5.2.4
WMS shall allocate the locations/facilities for servicing the order and provide the relevant
information to the identified facilities/locations
E 2
Item Retrieval
27. MB5.3
WMS shall enable retrieving the items stored in the Warehouse based on the order
received.

28. MB5.3.1 WMS shall prepare the picking list based on the order received.
29. MB5.3.1.1
WMS shall identify the most optimal locations for picking the items to service an order
E 1

based on parameters such as reduced material handling, FIFO and location.
30. MB5.3.1.2 WMS shall print the picking list for the warehouse personnel to review while picking. E 1
31. MB5.3.1.3 WMS users shall use handheld scanners to scan pick-list items as they are picked. E 1
32. MB5.3.2 WMS shall prepare the packing list based on the order received.
33. MB5.3.2.1 WMS shall decide the packing sequence based on a pre-defined logic. E 1
34. MB5.3.2.2 WMS shall determine the packing requirements from the system. E 1
35. MB5.3.2.3 WMS shall print a packing list. E 1
36. MB5.3.2.4
WMS shall optimize the packing operation by optimizing the packing combination for the
items on an order.
E 1
37. MB5.3.2.5 WMS users shall use handheld scanners to scan packing list items as they are packed. E 1
Document Storage
38. MB5.4 WMS shall store documents electronically.
39. MB5.4.1
WMS shall allow users to scan documents into the WMS using the attached document
scanner.
E 1
40. MB5.4.2
WMS shall have the capability to uniquely identify the documents and link them to a
particular consignment.
E 1
41. MB5.4.3
WMS shall have the capability to electronically transfer the document to the various
entities (e.g. LPC, Insurance agencies etc.).
E 1
Order dispatch
42. MB5.5 WMS shall process the dispatch of the order.
43. MB5.5.1 WMS shall prepare/print the labels to be pasted on the consignment. E 1

44. MB5.5.2
WMS shall generate the necessary documentation that needs to be carried for various
forms of transportation.
E 1
45. Mb5.5.3 WMS shall have an outbound interface with TMS to arrange for vehicle for order dispatch. E 1
Manage Cross-docking
46. MB5.6 WMS shall allow cross-docking of shipments. D 1
47. MB5.6.1
WMS shall match the inbound shipments with the outbound shipments and explore
potential cross-docking.
D 1
Invoicing
48. MB5.7 WMS shall raise invoice on customers based on services performed. E 1
49. MB5.7.1
WMS shall interface with the Customer Account solution for accessing the unified
customer account in order to raise invoice on corporate customers.
E 1
Resource Optimization
50. MB5.8 WMS shall optimize the utilization of warehousing space and facilities.
51. MB5.8.1 WMS shall provide visibility into all DoP facilities capacity/ utilization. D 1
52. MB5.8.2
WMS shall have an optimizing engine that shall optimally utilize the various facilities while
storing/picking.
D 1
Distribution
53. MB5.9 WMS shall have a distribution capability.
54. MB5.9.1 WMS shall plan for goods distribution based on the order received/business agreement. E 1
55. MB5.9.2
WMS shall accordingly prepare the pick-list for the items to be picked up to service the
order.
E 1

56. MB5.9.3 WMS shall prepare the packing list for items to be packed. E 1
57. MB5.9.4 WMS shall generate the label to be put on the items for shipping. E 1
58. MB5.9.5
WMS shall have an outbound interface with TMS to provide shipping information for these
items.
E 1
59. MB5.10 WMS shall maintain an inventory of the items
60. MB5.10.1 WMS shall maintain an inventory status of items in the Logistics Post supply chain
61.
MB5.10.1.
1
WMS shall maintain the inventory status of items stored in the warehouse and LPCs E 1
62.
MB5.10.1.
2
WMS shall maintain the inventory status of items under transit at various stages of supply
chain
E 1
63.
MB5.10.1.
3
WMS shall generate an inventory aging report highlighting the obsolete items E 1
64. MB5.10.2 WMS shall maintain inventory status of retail post items
65.
MB5.10.2.
1
WMS shall keep a track of the inventory of retail items sold through the POs as also
through the web portal of the DoP on an ongoing basis
E 1
66.
MB5.10.2.
2
WMS shall generate MIS reports to show PO-wise daily inventory position for each item E 1
67.
MB5.10.2.
3
WMS shall update the inventory level upon the acknowledgement of receipt of items by
the central stores /Warehouse from 3rd party vendors/partners in the system
E 1
68.
MB5.10.2.
4
WMS shall record the quantity and serial number of items received E 1

69.
MB5.10.2.
5
WMS shall record and account for discrepancies arising out of physical verification of
inventories
E 1
70.
MB5.10.2.
6
WMS shall be able to track ,identify and alert user about obsolete inventory E 1
71.
MB5.10.2.
7
WMS shall send automatic trigger to the designated relationship manager for re-order to
3rd party/business partner when inventory approaches re-order level
E 1
72.
MB5.10.2.
8
WMS shall enable user to manually edit the re-order level which triggers the automatic
procurement request
E 1
73. MBE
WMS shall have an inbound interface with MBE to receive Retail Post order requests for
WMS to coordinate order fulfilment.
E 2
74. IPVS
WMS shall have an outbound interface with IPVS to provide the visibility on the
consignment received at the warehouse. Also when the booking is done through the
handheld, the booking shall reflect the status of consignment in the IPVS.
E 2
75. MLASS
WMS shall have an inbound interface with MLASS to receive information about the volume
of material expected to come into the system for a defined period.
D 2
76. TMS
WMS shall have an outbound interface with TMS to pass on the information regarding all
dispatches being scheduled. TMS shall use this information to schedule the vehicles
accordingly.
E 2
77. IMS
The WMS System shall have an outbound interface to the IMS to send on-hand inventory
details.
E 2
78.
Customer
Account
WMS shall have an outbound interface with Customer Account to update the customer
account for the services provided to enable billing for customers
E 2

79. ECM
WMS shall have an outbound interface with ECM to send all the digitized documents to the
central repository
E 2
Transportation Management System
Managing Fleet of Vehicles
80. MB9.1 TMS shall manage the fleet of all vehicles owned by DoP.
81. MB9.1.1 TMS shall maintain a list of all vehicles owned by DoP. E 1
82. MB9.1.1.1 TMS shall register all the vehicles into the system. E 1
83. MB9.1.1.2
TMS shall maintain vehicle details (registration numbers, make, year) along with the facility
it belongs to.
E 1
84. MB9.1.2 TMS shall establish the overall fleet capacity of DoP.
85. MB9.1.2.1
TMS shall maintain a repository of available fleet capacity of DoP owned vehicles for
Logistics Post Vehicles.
E 1
86. MB9.1.2.2
TMS shall maintain a repository of available fleet capacity of hired/contracted vehicles for
Logistics Post Vehicles.
E 1
87. MB9.1.2.3
TMS shall include the vehicles available in the market (not under DoP contract, but
available for hire at pre-approved rates and a defined SLA) at a short notice for its available
capacity calculation
E 1
88. MB9.1.3 TMS shall review the transportation capacity requirements of DoP.
89. MB9.1.3.1
TMS shall assess the short-term transportation requirements (for the immediate
execution) based on the scheduling requests received.
E 1
90. MB9.1.3.2
TMS shall highlight any gaps in available capacity and the short-term transportation
requirements based on the scheduling requests received.
E 1

91. MB9.1.3.3 TMS shall assess the long-term transportation requirements based on the business plans. E 1
92. MB9.1.3.4
TMS shall highlight any gaps in available capacity and the long-term transportation
requirements based on the business plans.
E 1
93. MB9.1.4 TMS shall plan/manage the maintenance of the fleet.
94. MB9.1.4.1 TMS shall plan/manage the maintenance of DoP owned fleet.
95.
MB9.1.4.1
.1
TMS shall prepare a detailed maintenance plan for DoP owned fleet. E 1
96.
MB9.1.4.1
.2
TMS shall schedule this maintenance into the overall transportation schedule. E 1
97.
MB9.1.4.1
.3
TMS shall track the adherence to this maintenance plan by preparing a planned versus
actual report.
E 1
98. MB9.1.4.2 TMS shall review the maintenance of the hired/contracted vehicles.
99.
MB9.1.4.2
.1
TMS shall maintain a maintenance plan agreed with the contractor. D 1
100.
MB9.1.4.2
.2
TMS shall track the status of the maintenance plan for its implementation. D 1
101.
MB9.1.4.2
.3
TMS shall highlight non-adherence to the relevant authorities. D 1
Vehicle Tracking
102. MB9.2
TMS shall have the capability to later provide a telematics/GPS/RFID based solution for
track & trace purpose

103. MB9.2.1
For DoPs own vehicles, TMS shall provide telematics solution to capture the various
D 1

operating parameters
104. MB9.2.2
For the entire fleet (owned and hired) TMS shall have the functionality of providing
GPS/RFID based track & trace solution

105. MB9.2.2.1 TMS shall uniquely identify each vehicle through an RFID or GPS device D 1
106. MB9.2.2.2
For hired vehicles, TMS shall be able to provide a unique identifier to the vehicle by loading
a bag with RFID/GPS inside the vehicle
D 1
107. MB9.2.2.3 TMS shall provide the vehicle-wise report on deviation from the approved route D 1
Scheduling Vehicles
108. MB9.3 TMS shall schedule vehicles (pickup and delivery) as per the scheduling requirements.
109. MB9.3.1 TMS shall receive scheduling requirements. E 1
110. MB9.3.2 TMS shall review the vehicle availability. E 1
111. MB9.3.3 TMS shall perform load-planning for combining LTL wherever possible. E 1
112. MB9.3.4 TMS shall incorporate the maintenance plan into the vehicle scheduling. E 1
113. MB9.3.5 TMS shall allocate vehicles to various routes as per the optimized schedule. E 1
114. MB9.3.6 TMS shall perform online transport scheduling. E 1
115. MB9.3.7 TMS shall perform online contingency management. E 1
Managing Rates
116. MB9.4
TMS shall maintain a comprehensive rate list of contracted rates agreed with the
contractors for different routes and options (LTL, FTL).
E 2
Managing Payments
117. MB9.5 TMS shall facilitate contractor payments

118. MB9.5.1
TMS shall have inbound interface with the AP for receiving the invoice details raised by
vehicle contractors for the services performed by them for DoP
E 1
119. MB9.5.2
TMS shall have the ability to process and validate these invoices based on the actual
services performed and agreed rates.
E 1
120. MB9.5.3
TMS shall have an outbound interface with AP for passing on the confirmation on the
invoice for the payment processing
E 1
Route Management
121. MB9.6 TMS shall manage the routes of the vehicle to be followed.
122. MB9.6.1 TMS shall determine the route parameters (pick up, locations, volumes). E 1
123. MB9.6.2
TMS shall identify network and route options and select the most optimal route by
performing cost evaluation.
E 1
124. MB9.6.3 TMS shall generate pick-up and delivery plan. E 1
125. MB9.6.4 TMS shall re-route vehicle to manage contingencies. E 1
126. Interface with other systems
127. MB9.7 TMS shall interface with other systems
128. MB9.7.1 TMS shall have interface with IPVS
129. MB9.7.1.1 TMS shall have outbound interface with IPVS to provide visibility on goods being carried E 1
130. MB9.7.1.2
TMS shall have inbound interface with IPVS for the volume of mails/consignments being
handled between various network nodes (facilities)
E 1
131. MB9.7.2
TMS shall have inbound interface with MLASS to receive requests for the pick-up from
customer premises
D 1

132. MB9.7.3
TMS shall have inbound interface with WMS to receive scheduling request for order
fulfilment
D 1
133. Integration Requirements
134. WMS
TMS shall have an inbound interface with the WMS to receive scheduling request for order
fulfilment
E 2
135. IPVS
TMS shall have an outbound interface with IPVS to send transmission events on the
volume of mails/consignments being handled between various facilities
E 2
136. MLASS
E 2
137. MLASS
E 2

7.2.4.3 Philately
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Philatelic Deposit Account Management
Philatelic Deposit Account Opening
1. PH1.1 System shall enable PDA opening E 1
2. PH1.1.1 System shall allow Post Office PA to open a PDA across the counter E 1

3. PH1.1.2 System shall allow the user to open a PDA through web portal E 1
4. PH1.1.3 System shall allow the user to open a PDA through Call Centre E 1
5. PH1.1.4 System shall capture the details of the account E 1
Payment Options
6. PH1.2 System shall allow multiple payment options for PDA E 1
7. PH1.2.1
System shall allow web payment through debit card/credit card/bank transfer/ POSB
transfer
E 1
8. PH1.2.2 System shall allow cash payment across the counter E 1
Philatelic Account Management
9. PH1.3 System shall allow online account management for the PDA D 1
10. PH1.3.1 System shall allow online change of address D 1
11. PH1.3.2 System shall allow online change of contact details D 1
12. PH1.3.3 System shall allow online query for account balance D 1
13. PH1.3.4 System shall provide complete transaction history for the account D 1
Order Management
14. PH1.4 System shall allow online order generation E 1
15. PH1.4.1 System shall provide a link to the Philately page listing all the current releases E 1
16. PH1.4.2
System shall allow the user to place an order for the current release including the
quantities
E 1
17. PH1.4.3
System shall allow the user to place future order for the future release including the
quantities
E 1

18. PH1.4.4 System shall send electronic alerts to the email provided as contact for all transactions E 1
Account closure
19. PH1.5 System shall allow the user to close the account E 1
20. PH1.5.1 System shall allow the user to close the account through the Call Centre E 1
21. PH1.5.2 System shall allow the user to close the account online E 1
Stock & Supply of Stamps
Stamp Printing
22. PH2.1 System shall manage the stamp printing process E 1
23. PH2.1.1
System shall maintain detailed list of all categories of stamps, denomination-wise along
with the date of release
E 1
24. PH2.1.2
System shall generate advice for printing of Philatelic stamps to be sent to RSD Nashik and
RSD Hyderabad
E 1
25. PH2.1.3
System shall consolidate the indents raised for definitive stamps by the CSD along with the
denomination
E 1
26. PH2.1.4
System shall generate advice for printing of definitive stamps to be sent to RSD Nashik and
RSD Hyderabad
E 1
Stamp Receipt at the Office
27. PH2.2 System shall receive the stamps at the destination office E 1
28. PH2.2.1 System shall send electronic alert to the receiving office E 1
29. PH2.2.2
System shall verify the physical receipt versus the invoiced quantity and raise any
mismatch
E 1

30. PH2.2.3 System shall generate variance report to be sent to RSD Nashik and RSD Hyderabad E 1
31. PH2.2.4 System shall allow the goods receipt online E 1
Stamp Inventory
32. PH2.3
System shall maintain the inventory of stamps for each office (Post Offices, Philatelic
Bureaux, CSD)
E 1
33. PH2.3.1 System shall maintain denomination-wise inventory of stamps E 1
34. PH2.3.2
System shall update the stock quantity every day at the close of day accounting for any
stock received and the sale of stamps
E 1
35. PH2.3.3 System shall generate Remittance Advice (RA) in the case of inter bureau supply E 1
Sale of Philatelic Stamp
36. PH2.4 System shall manage the sale of stamps E 1
37. PH2.4.1
System shall ensure that stamps are not supplied to any bureau/ counter above the
authorized limit
E 1
38. PH2.4.2 System shall ensure that philatelic stamps are not sold before their release date E 1
39. PH2.4.3
System shall generates stamp distribution list for supply to PDA Account Holders/ Nehru
Stamp Clubs / Dealers as per the choice of the account holder
E 1
40. PH2.4.4
System shall limits the supply to the account holders as per the balance available in their
accounts
E 1
Disposal of Philatelic Stamp
41. PH2.5 System shall manage the sale/disposal of old philatelic stamps D 1
42. PH2.5.1
System shall update stock of the office as per Write off sanctions issued by Superintendent
D 1

with appropriate remarks and generates alert to physically destroy the stamps
43. PH2.5.2
Transfers the unsold stamps after one year (configurable) from the date of release to the
General Stamps balance at that office, updating stamps registers and sends alert
D 1
Interface with Other systems
44. IM
System shall have interface with Inventory Management module to use the inventory
management functionalities
E 1
45.
Requisitio
n &
Procurem
ent
System shall have interface with Requisition & Procurement module to generate indents,
creation of purchase order and good receipt
E 1

7.2.4.4 Finance & Accounts
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

General Ledger
Consolidation of transactions
1. FA.GL.1
System shall automatically consolidate summary of transactions from different
applications
E 1
2. FA.GL.1.1 System shall collate revenue/ expenditure received as a summary from PBS at end of day E 1

3.
FA.GL.1.1.
1
System shall get summary input of all PBS accounting transactions by transaction ID and
office of origination of transaction
E 1
4.
FA.GL.1.1.
1.1
System shall consolidate summary of transactions already classified under HoA E 1
5. FA.GL.1.2 System shall consolidate revenue/ expenditure from PLI Ledger E 1
6.
FA.GL.1.2.
1
System shall get summary input of all PLI accounting transactions by transaction ID and
office of origination of transaction
E 1
7.
FA.GL.1.2.
1.1
8. FA.GL.1.3 System shall consolidate revenue/ expenditure from Mail Booking engine E 1
9.
FA.GL.1.3.
1
System shall get summary input of all Mail Operations Transactions from the booking
engine by transaction ID and office of origination of transaction
E 1
10.
FA.GL.1.3.
1.1
11.
FA.GL.1.3.
2
System shall get summary input of all accounting transactions in MLASS (Mail & Logistics
Appointment & Scheduling Solution) by transaction ID and office of origination of
transaction
E 1
12.
FA.GL.1.3.
2.1
13. FA.GL.1.4 All transactions shall be posted to GL in batch mode at End of day E 1
14.
FA.GL.1.4.
1
System shall allow offline transaction files from non connected Post Offices to be
integrated in GL as a batch process
E 1
15.
FA.GL.1.4. System shall collate revenue/ expenditure received as a summary from Sanchay Post at
E 1

2 end of day
16.
FA.GL.1.4.
3
System shall get summary input of all Sanchay Post accounting transactions E 1
17.
FA.GL.1.4.
4
System shall consolidate summary of Sanchay Post transactions already classified under
HoA
E 1
Online Accounting
18. FA.GL.2
System shall support online accounting entries from Fixed Asset Accounting, Inventory
management, Accounts Receivable, Accounts Payable and Procurement Functions
E 1
19. FA.GL.2.1
System shall allow for posting of expenses identified as 'recurring' (Payroll, etc) on a pre-
defined logic and shall get posted automatically once the program has been executed on a
specified date
E 1
20. FA.GL.2.2 System shall fetch details of salaries paid to departmental employees from Payroll Function E 1
21. FA.GL.2.3 System shall fetch details of other bills/loans drawn by employees from Payroll Function E 1
22. FA.GL.2.4
System shall fetch details of Govt. contribution towards NPS for all employees (Nil Bill)
from Payroll Function
E 1
23. FA.GL.2.5
In case of employees not on Payroll, the systems shall support manual input of drawal of
bills and Govt. contribution for the employees
E 1
24. FA.GL.2.6
System shall record expenditures incurred by Administrative offices (Circle Office/ Regional
Office/ Div. Office), CSD, PSD, MMS, RMS, Civil & Electrical Division
E 1
25. FA.GL.2.7 System shall interface with Accounts Payable function E 1
26.
FA.GL.2.7.
1
System shall pass accounting entries in GL for payable amount E 1
27.
FA.GL.2.7.
System shall pass entry in GL when payables have been squared off E 1

2
28. FA.GL.2.8 System shall interface with Accounts Receivable function E 1
29.
FA.GL.2.8.
1
System shall pass accounting entries in GL for receivable amount E 1
30.
FA.GL.2.8.
2
System shall pass entry in GL when receivables have been squared off E 1
31. FA.GL.2
System shall support online accounting entries from Fixed Asset Accounting, Inventory
management, Accounts Receivable, Accounts Payable and Procurement Functions
E 1
32. FA.GL.2.1
System shall allow for posting of expenses identified as 'recurring' (Payroll, etc) on a pre-
defined logic and shall get posted automatically once the program has been executed on a
specified date
E 1
33. FA.GL.2.2 System shall fetch details of salaries paid to departmental employees from Payroll Function E 1
34. FA.GL.2.3 System shall fetch details of other bills/loans drawn by employees from Payroll Function E 1
35. FA.GL.2.4
System shall fetch details of Govt. contribution towards NPS for all employees (Nil Bill)
from Payroll Function
E 1
36. FA.GL.2.5
In case of employees not on Payroll, the systems shall support manual input of drawal of
bills and Govt. contribution for the employees
E 1
37. FA.GL.2.6
System shall record expenditures incurred by Administrative offices (Circle Office/ Regional
Office/ Div. Office), CSD, PSD, MMS, RMS, Civil & Electrical Division
E 1
38. FA.GL.2.7 System shall interface with Accounts Payable function E 1
39.
FA.GL.2.7.
1
System shall pass accounting entries in GL for payable amount E 1
40.
FA.GL.2.7.
System shall pass entry in GL when payables have been squared off E 1

2
41. FA.GL.2.8 System shall interface with Accounts Receivable function E 1
42.
FA.GL.2.8.
1
System shall pass accounting entries in GL for receivable amount E 1
43.
FA.GL.2.8.
2
System shall pass entry in GL when receivables have been squared off E 1
Common Charts of Account
44. FA.GL.3 System shall use common Chart of Accounts E 1
45. FA.GL.3.1
System shall have defined Chart of Accounts for Accrual Accounting as prescribed by ICAI
ARF which shall drive the Chart of Accounts used in PBS, PLI and Mail ledgers
E 1
46. FA.GL.3.2
System shall have cost codes built-in to map expenses to the correct cost centre (Circle
Office, Regional Office, etc)
E 1
47. FA.GL.3.3
System shall be able to generate financial reports in Cash Based Accounting format from
the Accrual Accounting system
E 1
48.
FA.GL.3.3.
1
System shall generate Circle Abstract with classification into HoA in the format as is
currently submitted
E 1
49.
FA.GL.3.3.
2
System shall generate General Abstract with classification into HoA in the format as is
currently submitted
E 1
50.
FA.GL.3.3.
3
System shall have the ability to handle other reporting under Accounting standards E 1
51.
FA.GL.3.3.
4
System shall be able to create a central data pool with maximum level of granularity so
that reports can be generated in accordance with the regulatory or management
requirement:
E 1

52.
FA.GL.3.3.
4.1
Internal & External Financial Reporting E 1
53.
FA.GL.3.3.
4.2
Performance Reporting E 1
54.
FA.GL.3.3.
4.3
Operational Reporting E 1
55.
FA.GL.3.3.
4.4
Reconciliation Reporting - On-line, real-time update or batch (user defined) E 1
56. FA.GL.3.4
System shall support creation/modification/ deletion of Heads of Accounts as per
directives of Ministry of Finance
E 1
Accounts Consolidation
57. FA.GL.4 Accounts Consolidation E 1
58. FA.GL.4.1
System should enable the Accounts Processing Centre to retrieve consolidated
quarterly/annual accounts (no input should be required from the operating offices as all
the accounting data is updated real time in the database)
E 1
59. FA.GL.4.2 Should be able to consolidate general ledgers using different accounting periods E 1
60. FA.GL.4.3 Should be able to define period start and end dates in the consolidation module E 1
61. FA.GL.4.4
Should be able to make consolidation for the subsequent periods even if the consolidation
of first period is still open
E 1
62. FA.GL.4.5
All codes entered should be able to be validated on-line, and the code description
displayed for visual checking
E 1
63. FA.GL.4.6
Should be able to reproduce the chart of accounts from any of the general ledgers in the
consolidation module as a basis for consolidation
E 1

64. FA.GL.4.7
Should display list of all valid codes and their descriptions at points when codes are
required to be entered
E 1
65. FA.GL.4.8 Should be able to generate the required reports, including: E 1
66.
FA.GL.4.8.
1
trial balance E 1
67.
FA.GL.4.8.
2
segmental revenue accounts E 1
68.
FA.GL.4.8.
3
profit and loss account E 1
69.
FA.GL.4.8.
4
balance sheet E 1
70.
FA.GL.4.8.
5
IBNR E 1
71.
FA.GL.4.8.
6
Cash Flow E 1
72.
FA.GL.4.8.
7
Calculation of ratios E 1
73.
FA.GL.4.8.
8
net movement by account showing opening balance at start of the month, all
transactions and closing balance
E 1
74.
FA.GL.4.8.
9
net movement by account showing opening balance at start of the range of continuous
vouchers , net transactions during the range and closing balance at the end of the range
E 1
75. FA.GL.4.9
Should be able to convert various office balances of foreign offices in various currencies
into rupees and generate consolidated balance sheet of all such offices
E 1

76.
FA.GL.4.1
0
Should support prep of a/c where transfer of office takes place during the financial year
from one controlling office to another
E 1
77.
FA.GL.4.1
1
Should have provision for calculation of solvency ratio E 1
78.
FA.GL.4.1
2
Should have provision to track actual transaction dates for various transactions (prior
period items)
E 1
79.
FA.GL.4.1
3
Should be capable of supporting migration of legacy accounting data E 1
80.
FA.GL.4.1
4
It is likely that most reports will be produced by means of an end-user report writer. Such a
report writer should be able to access all data items in the database to enable a wide range
of custom reports to be written (subject to approval)
E 1
81.
FA.GL.4.1
5
System shall be able to create and maintain accounts and account information on-line E 1
82.
FA.GL.4.1
6
System shall be able to create memo accounts for collecting non-financial statistical
information
E 1
83.
FA.GL.4.1
7
System shall be able to segregate expense accounts by division, department and work,
cost or profit centre
E 1
84.
FA.GL.4.1
8
System shall be able to transfer or consolidate accounts and automatically combine all
details
E 1
85.
FA.GL.4.1
9
System shall be able to record settlements and adjustments through journal entries E 1
86.
FA.GL.4.2
0
System shall be able to carry out reversal of journal entries E 1

87.
FA.GL.4.2
1
System shall be able to post journal entries in batch E 1
88.
FA.GL.4.2
2
System shall be able to sort information from a header record in each transaction E 1
89.
FA.GL.4.2
3
System shall be able to consolidate financial data along the following parameters: E 1
90.
FA.GL.4.2
3.1
Within a Division/circle/region E 1
91.
FA.GL.4.2
3.2
Post office level E 1
92.
FA.GL.4.2
3.3
Cost, profit or work centres or administrative office wise E 1
93.
FA.GL.4.2
4
System shall be able to repeat details from the previous journal (e.g. date, description)
while at the same time preventing duplication of journal entry
E 1
94.
FA.GL.4.2
5
System shall be able to enter description for each detail line of a journal E 1
95.
FA.GL.4.2
6
System shall be able to create multiple batches of journal entry at one time, with
predefined authority levels for the same
E 1
96.
FA.GL.4.2
7
System shall be able to automatically accept and post journal entries from Account
Payable, Accounts Receivable, etc.
E 1
97.
FA.GL.4.2
8
System shall have unique number for each journal entry E 1
98.
FA.GL.4.2
System shall be able to look-up by account number and description during entry E 1

9
99.
FA.GL.4.3
0
System shall be able to create automatic recurring entries that allocate one account
balance among several others based on ratios
E 1
100.
FA.GL.4.3
1
System shall be able to terminate a recurring journal entry based on the automatic
accumulation of all payments equalling total commitment
E 1
101.
FA.GL.4.3
2
System shall be able to set starting and ending period/year for recurring entries E 1
102.
FA.GL.4.3
3
System shall be able to enter and maintain statistical information either along with or
independently of journal entries
E 1
103.
FA.GL.4.3
4
System shall prevent duplicate posting to the same account E 1
104.
FA.GL.4.3
5
System shall be able to check before a period close that all the vouchers have been
authorized and posted and System shall give a warning if some unauthorized /unposted
voucher remains in the system
E 1
105.
FA.GL.4.3
6
System shall ensure at year-end close that all entries are in balance and that all periods
have been closed
E 1
106.
FA.GL.4.3
7
System shall identify and process accruals with automatic reversal in the next accounting
period
E 1
107.
FA.GL.4.3
8
System shall automatically roll-up detail accounts to summary accounts E 1
108.
FA.GL.4.3
9
System shall be able to calculate and maintain current, prior, and previous year
comparative information
E 1
109.
FA.GL.4.4
System shall provide capability to revise invalid journals, subject to predefined authority E 1

0
110.
FA.GL.4.4
1
System shall be able to define a number of suspense codes E 1
111.
FA.GL.4.4
2
System shall be able to post errors to different suspense codes according to the source E 1
112.
FA.GL.4.4
3
System shall be able to correct transactions posted to suspense real time E 1
113.
FA.GL.4.4
4
System shall have a GL report writer E 1
114.
FA.GL.4.4
5
System shall be able to generate unlimited number of financial reports for balance sheet,
income statement, supporting schedule, cash flow and other specific account analysis
E 1
115.
FA.GL.4.4
6
System shall be able to specify the contents of each column with no restriction i.e. current
month, current budget, year to date, budget to date, last year to date
E 1
116.
FA.GL.4.4
7
System shall support online posting of all financial transactions in GL and updating of all
reports
E 1
117.
FA.GL.4.4
8
System shall support drilldown from GL entries to individual transactions E 1
118.
FA.GL.4.4
9
System shall support mapping of transactions to respective operating office based on user
id / office code to facilitate generation of various reports office wise
E 1
119.
FA.GL.4.5
0
System shall allow all offices to drill down to transaction level in respect of
offices/intermediaries under their administrative control
E 1
120.
FA.GL.4.5
1
System shall provide for what if analysis with option to post / not post to GL E 1

121.
FA.GL.4.5
2
System shall allow user to indicate closure of an accounting period for a given office and
prevent further accounting in the closed period
E 1
122.
FA.GL.4.5
3
System shall enforce uniformity in transaction date and accounting date in respect of all
accounting transactions except those done through Journal Vouchers, in which case the
accounting can be backdated.
E 1
123.
FA.GL.4.5
4
System shall have ability to track backdated adjustments E 1
124.
FA.GL.4.5
5
System shall have facility for Multi currency transaction, indexation, exchange gain / loss,
accounting treatment to Exchange Gains/Loss as per companys stated Significant
Accounting Policy in the Annual Report
E 1
125.
FA.GL.4.5
6
System shall be able to override standard currency exchange rate with each input
transaction
E 1
126.
FA.GL.4.5
7
When the standard exchange rate is overridden, output report generated System shall
show:
E 1
127.
FA.GL.4.5
7.1
the standard exchange rate E 1
128.
FA.GL.4.5
7.2
the override exchange rate E 1
129.
FA.GL.4.5
7.3
the person entering the override transaction E 1
130.
FA.GL.4.5
8
All postings and account balances System shall be maintained in both local currency and
user-defined foreign currencies
E 1
131.
FA.GL.4.5
9
System shall be able to calculate foreign exchange gains/losses E 1

132.
FA.GL.4.6
0
System shall maintain a history of exchange rates. The history shall capture the effective
date of a change to an exchange rate, the date it was changed and by whom and details of
what the rate was changed from/to
E 1
133.
FA.GL.4.6
1
System shall provide multi-currency support with ability for authorized user to create a
new currency and exchange rate in addition to those already available
E 1
134.
FA.GL.4.6
2
System shall permit modification / cancellation of receipts / payment vouchers only by
designated users
E 1
135. FA.GL.5
System shall allow for post adjustment entries in closed period with proper audit trail and
authorization
E 1
Closing of Accounts
136. FA.GL.6
System shall have the ability of periodic and year end closing of accounts be done as per
user defined closing calendar
E 1
137. FA.GL.6.1
System shall carry forward the closing balance of the financial year as opening balance to
the next financial year automatically
E 1
138. FA.GL.7
System shall have the ability to automatically generate General Ledger Accounts required
to support transactions according to modifiable business rules. Facility to generate the
General Ledger Accounts for the DoP as a whole. If the DoP wishes to generate accounts
for Particular region or branches only or for a particular territory/state/LoB, then the
ability for such a request must be available.
E 1
139. FA.GL.7.1
System shall have ability to transfer charge-back and profit to any account and/or
cost/profit centre from any activity.
E 1
140. FA.GL.7.2
System shall have the ability to create parent-child (nested) relationships between
accounts.
E 1
Reporting

141. FA.GL.8 System shall be able to group by : E 1
142. FA.GL.8.1 Legal Entity E 1
143. FA.GL.8.2 Controlling Area / LOB E 1
144. FA.GL.8.3 Profit Centre Hierarchy E 1
145. FA.GL.8.4 Cost Centre Hierarchy E 1
146. FA.GL.8.5 Operating Concern E 1
147. FA.GL.8.6 Product wise E 1
148. FA.GL.8.7 Maintenance of Cash GL E 1
149. FA.GL.8.8 Maintenance of Sundry/Suspense GL E 1
150. FA.GL.8.9 Maintenance of Contra Heads E 1
151. FA.GL.9
System shall have the ability to facilitate book closure at periodical intervals (monthly,
quarterly, half-yearly/yearly or at any user definable time-frame).
E 1
152. FA.GL.10
System shall post all transactions received from other systems directly to a GL suspense ,
pending review and adjustment before actual posting :
E 1
153.
FA.GL.10.
1
Backvalued entries shall be allowed E 1
154.
FA.GL.10.
2
Time period for back valuation shall be 2 / 3 years which is to be available as user
definable option
E 1
155.
FA.GL.10.
3
Average balances shall be automatically recalculated E 1
156.
FA.GL.10. Flag accounts which are inactive through user determined criteria E 1

5
157.
FA.GL.10.
6
Suppress printing accounts with zero balance on reports and financial statements
(Flexible)
E 1
158.
FA.GL.10.
7
Access account numbers and descriptions during data entry E 1
159.
FA.GL.10.
8
Allow multiple accounting periods to be open at one time E 1
Interface with Other Systems
160.
PBS
system
GL shall have an inbound interface with CBS solution for getting daily summary of
transactions posted in CBS
E 2
161. PLI system
GL shall have an inbound interface with PLI solution for getting daily summary of
transactions posted in PLI
E 2
162. MLASS
GL shall have an inbound interface with MLASS/ Mail Accounting engine solution for
getting daily summary of mail transactions
E 2
163. AR/AP
GL shall have an inbound interface with AR/ AP Functions to pass details of receivables and
payables of DoP. The details shall be updated in AR/AP as and when the receivables and
payables are cleared.
E 2
164. Payroll
GL shall have an inbound interface with Payroll Function to update all the details of pay
bills and other bills drawn by employees of India Post
E 2
Requisition & Procurement
Requisition
165. FA.RP.1
System shall allow users at the operational unit (HO/SO) to raise procurements requests
for operational items .System shall treat these users as light users
E 1

166. FA.RP.1.1
System shall enable HO and SO to send requests for procurement directly to divisional
office or PSD/CSD as case may be
E 1
167.
FA.RP.1.1.
1
System shall allow for requests from HO& SO to be automatically collated into the
Procurement Function
E 1
168. FA.RP.1.2 System shall interface with Inventory Management Function E 1
169.
FA.RP.1.2.
1
System shall allow designated users at PAO/CSD/PSD and circle office to view inventory of
all HO/ SO
E 1
170.
FA.RP.1.2.
1.1
System shall enable user to fix reorder levels and reorder quantities for different items of
inventory
E 1
171.
FA.RP.1.2.
2
System shall auto monitor the inventory levels across all operative offices and send auto
procurement request to CSD/ PSD when inventory approaches the pre defined re-order
level
E 1
172.
FA.RP.1.2.
2.2
System shall send request for pre set quantities E 1
173.
FA.RP.1.2.
2.3
System shall only reorder quantities as defined but allow the user to manually change the
quantities to be ordered only after proper authorisation
E 1
174.
FA.RP.1.2.
3
System shall keep a timestamp record of the procurement request and overriding
exception approvals if any
E 1
175.
FA.RP.1.2.
4
System shall generate a MIS report of all procurement requests made, fulfilled open and
expired along with any deviation approvals
E 1
176. FA.RP.1.3
System shall interface with PBS inventory Function to monitor inventory of security items
such as Cheque Book and Cash Certificate/ Stamps and initiate a procurement request to
PSD and CSD respectively when inventory approaches the pre defined re-order level
E 1

Request for procurement
177. FA.RP.2 System shall allow for raising request of procurement from external vendors E 1
178. FA.RP.2.1 System shall allow for CSD/ PSD to raise procurement requests to external vendor E 1
179.
FA.RP.2.1.
1
System shall interface with Inventory Management Function E 1
180.
FA.RP.2.1.
1.1
System shall allow for requests from HO/SO to be automatically collated into the
Procurement Function
E 1
181.
FA.RP.2.1.
1.2
System shall also allow for manual entry of requests from HO/ SO E 1
182. FA.RP.2.2
System shall allow requisition approvals to be automatically routed through defined
Workflow
E 1
183.
FA.RP.2.2.
1
System shall allow for request to be approved by Sanctioning Authority (to be decided
according to delegation of financial powers) for financial concurrence
E 1
184.
FA.RP.2.2.
2
System shall allow for sanctioned request to be routed to Purchasing Director for placing
order with DGS&D
E 1
185. FA.RP.2.3 System shall allow for raising a request of procurement through DGS&D E 1
186. FA.RP.2.4
System shall allow for raising a request of procurement through vendors selected by
tendering process
E 1
187. FA.RP.2.5
System shall indicate the status of the procurement request (Open, Processing, In transit,
Closed)
E 1
188. FA.RP.2.6 System shall interface with Budget Function E 1
189.
FA.RP.2.6. The Sanctioning Authority shall be able to view the available budget for the concerned
E 1

1 procurement request
190.
FA.RP.2.6.
2
System shall make available to the Purchase Officer, the budget available for the
concerned item
E 1
191.
FA.RP.2.6.
3
System shall update available budget after sanction is approved E 1
Issuance of Purchase Order
192. FA.RP.3
System shall be able to issue Purchase Orders after approval by Sanctioning Authority (to
be decided according to delegation of financial powers) for financial concurrence
E 1
193. FA.RP.3.1 System shall be enabled to issue Purchase Orders to DGS&D E 1
194. FA.RP.3.2
System shall be enabled to issue Purchase Orders to vendors selected through tendering
process
E 1
195. FA.RP.3.3
System shall be enabled to issue Purchase Orders to 3rd party/ printer for replenishment
of CSD/ PSD
E 1
196. FA.RP.3.4
System shall map Purchase Orders raised to the requisition raised by PAO/ concerned
Admin Office
E 1
197. FA.RP.3.5
System shall allow for delivery of Purchase Orders to DGS&D through email stored as
contact information
E 1
198.
FA.RP.3.5.
1
System shall allow for change of contact number or email of vendor E 1
199. FA.RP.3.6
System shall allow for delivery of Purchase Orders to vendors via email stored as contact
information
E 1
200.
FA.RP.3.6.
1
System shall allow for change of contact number or email of vendor E 1

201. FA.RP.3.7
System shall allow for Purchase Orders to be classified by type of purchases/ value of
purchases
E 1
202. FA.RP.3.8
System shall compute Income Tax (TDS) and Service Tax for each transaction wherever
applicable at current rates for each Purchase Order issued
E 1
Goods Receipt
203. FA.RP.4 System shall provide the ability for acknowledgement of receipt of goods/ services online E 1
204. FA.RP.4.1
System shall enable indenting office to specify consignee entitled to receive goods from
third party/CSD/PSD
E 1
205. FA.RP.4.2
System shall enable the indenting office/designated consignee to acknowledge receipt of
goods through defined workflow and send intimation to Purchase officer.
E 1
206.
FA.RP.4.2.
1
System shall record the time stamp of such acknowledgement E 1
207.
FA.RP.4.2.
2
Upon receipt of goods, an intimation/alert shall also be sent to the indenting office. E 1
208.
FA.RP.4.2.
3
System shall manage invoice-to-order matching - 2/3/4 way E 1
209. FA.RP.4.3
System shall recognize the value of goods received as 'Liability' in GL and also update the
Account Payable Function
E 1
210.
FA.RP.4.3.
1
System shall send an intimation to the PAO alerting about the receipt of goods and
creation of liability
E 1
211. FA.RP.4.4
System shall enable the Purchase officer to close procurement request after intimation
from consignee through defined workflow
E 1
212. FA.RP.4.5
System shall update Inventory Management Function with details of goods received upon
E 1

closure of the request
Vendor Account
213. FA.RP.5 System shall allow for creation of new vendor record E 1
214. FA.RP.5.1 System shall allow user to enter details of new vendor E 1
215.
FA.RP.5.1.
1
System shall capture mandatory fields such as PAN No., TIN no., TAN No., Bank A/c details,
etc
E 1
216.
FA.RP.5.1.
2
System shall prevent creation of duplicate vendor records E 1
217. FA.RP.5.2
System shall be able to classify vendor based on type of goods/ services procured from
them
E 1
218. FA.RP.5.3 System shall be able to provide list of vendors with no or limited activity D 1
219.
FA.RP.5.3.
1
System shall be able to alert Purchasing Director of vendors with limited activity for further
action
D 1
Inventory Status
220. FA.IM.1
System shall track inventory level of cheque books, pre printed CC, stamps , materials at
various locations
E 1
221. FA.IM.1.1 System shall track inventory at Post Offices on an ongoing basis E 1
222.
FA.IM.1.1.
1
System shall update inventory level at Post Offices after receipt of physical goods from
CSD/ PSD
E 1
223.
FA.IM.1.1.
1.1
System shall update the inventory level after indenting office acknowledges receipt of
goods in the system and close the procurement request
E 1

224.
FA.IM.1.1.
1.2
System shall record the quantity of items received E 1
225.
FA.IM.1.1.
1.3
System shall record the serial numbers of the of items received E 1
226.
FA.IM.1.1.
2
System shall update inventory levels of Post Offices on an ongoing basis E 1
227.
FA.IM.1.1.
2.1
System shall interface with the PoS/ Mail application to update the inventory of stamps,
envelopes and other postal items and update inventory levels accordingly
E 1
228.
FA.IM.1.1.
2.2
System shall interface with the PBS solution to monitor issuance of security items such as
cheque books, debit cards and update inventory levels accordingly
E 1
229.
FA.IM.1.2.
2.3
System shall interface with the PBS solution to monitor issuance of items such as pre
printed cash certificates based transactions and update the inventory level accordingly
E 1
230. FA.IM.1.2 System shall be able to track inventory at CSD/ PSD on an ongoing basis E 1
231.
FA.IM.1.2.
1
System shall update inventory level at CSD/ PSD upon receipt of inventory from printing
press/ 3rd party
E 1
232.
FA.IM.1.2.
1.1
System shall update the inventory level upon acknowledgement of receipt of goods by
indenting office in the system and close the procurement request
E 1
233.
FA.IM.1.2.
2
System shall update inventory level at CSD/ PSD to account for the physical dispatch of
material to HO/ SO/ BO after it is acknowledged by the indenting office
E 1
234. FA.IM.1.3 System shall generate reports to show daily inventory position for each item E 1
235.
FA.IM.1.3.
1
System shall generate MIS reports for inventory position at Post Office level E 1
236.
FA.IM.1.3.
System shall generate MIS report for open inventory transfer requests between offices E 1

1.1
237.
FA.IM.1.3.
2
System shall generate MIS reports for inventory position at CSD/ PSD level E 1
238. FA.IM.1.4 System shall be able to track ,identify and alert user against obsolete inventory E 1
239. FA.IM.1.5
System shall record and account for discrepancies arising out of physical verification of
inventories
E 1
Interface with Procurement
240. FA.IM.2 System shall interface with Procurement Function E 1
241. FA.IM.2.1
System shall send automatic trigger to Procurement Function for re-order to CSD/ PSD
when inventory approaches re-order level
E 1
242.
FA.IM.2.1.
1
System shall allow user to manually edit the re-order level which initiates the automatic
procurement request
E 1
243. FA.IM.2.2
System shall send automatic trigger to Procurement Function for sanction of procurement
at CSD/ PSD when inventory approaches re-order level
E 1
Interface with GL
244. FA.IM.3 System shall interface with General Ledger Function E 1
245. FA.IM.3.1 System shall reflect inventory at CSD/ PSD under Current Assets HoA of GL E 1
Inventory Management for Retail Post items
246. FA.IM.4 Retail Inventory items under WMS E 1
247. FA.IM.4.1
System shall keep a track of the inventory of retail items sold through the POs as also
through the web portal of the DoP on an on going basis
E 1
248. FA.IM.4.2 System shall generate reports to show daily inventory position for each item E 1

249. FA.IM.4.3
System shall update the inventory level upon acknowledgement of receipt of items by the
central stores from 3rd party vendors/partners in the system
E 1
250. FA.IM.4.4 System shall record the quantity and serial number of items received E 1
251. FA.IM.4.5
System shall generate MIS reports to show daily inventory position (quantity and value) for
each item
E 1
252. FA.IM.4.6 System shall be able to track ,identify and alert user about obsolete inventory E 1
253. FA.IM.4.7
System shall record and account for discrepancies arising out of physical verification of
inventories
E 1
254. FA.IM.4.8
System shall send automatic trigger to Relationship Manager for re-order to 3rd
party/partner when inventory approaches re-order level
E 1
255. FA.IM.4.9
System shall enable user to manually edit the re-order level which triggers the automatic
procurement request
E 1
Accounts Receivable
Customer Tracking
256. FA.AR.1 System shall have ability to track customers E 1
257. FA.AR.1.1
System shall be able to create new customer accounts in Order Management or Account
receivables
E 1
258. FA.AR.1.2
System shall have a Sub Ledger for different customers/ agencies for Book Now Pay Later
products
E 1
259. FA.AR.1.3
System shall interface with mail application /POS and update the extent of order fulfilled
based on information received
E 1
Claims Management

260. FA.AR.2 System shall raise claims on respective agencies E 1
261. FA.AR.2.1 System shall raise monthly Invoice on EPF and CMPF for pension amount and commission E 1
262. FA.AR.2.2 System shall raise monthly Invoice on Railways for pension amount and commission E 1
263. FA.AR.2.3 System shall raise monthly Invoice on Telecom Department for commission E 1
264. FA.AR.2.4
System shall raise monthly Invoice on any other agency for pension amount and
commission as applicable
E 1
265. FA.AR.2.5 System shall raise invoices on bulk mail customers as per the pre defined milestones E 1
266. FA.AR.2.6
System shall raise periodic Invoice on International Postal Organizations for services
rendered to deliver articles (EMS, Parcel, Mails) within country
E 1
267. FA.AR.2.7 System shall square off receivables on clearance of payment by the concerned agency E 1
268.
FA.AR.2.7.
1
System shall allow user to nullify receivables from Railways on receipt of RBI clearance
memo
E 1
269.
FA.AR.2.7.
2
System shall allow set off of receivables and payables at client level E 1
270.
FA.AR.2.7.
3
System shall allow treatment of negative payables as receivables E 1
Interface with GL
271. FA.AR.3 System shall interface with the GL Function E 1
272. FA.AR.3.1
System shall update receivables GL with Pension and commission amount for pension
disbursed to other agencies (EPF, CMPF, Railways, Telecom)
E 1
273. FA.AR.3.2 System shall update receivables GL with Book Now Pay Later orders fulfilled E 1

274. FA.AR.3.3
System shall update receivables GL with net amount due from International Postal
organizations
E 1
Receivable Management
275. FA.AR.4 System shall calculate receivables due to India Post E 1
276. FA.AR.4.1 System shall maintain Sub Ledger for different customers/ agencies E 1
277. FA.AR.4.2 System shall calculate interest earned on receivables on account of late payment E 1
278. FA.AR.4.3 System shall calculate receivable basis interest calculated and advance payment received E 1
279. FA.AR.4.4 System shall send notification to agency on amount receivable by DoP E 1
280.
FA.AR.4.4.
1
System shall specify interest accrued on amount E 1
281.
FA.AR.4.4.
2
In case online notification cannot be sent, system shall generate a physical copy of the
notification
E 1
282. FA.AR.4.5
Should support adjustment of premium on proposals against amount in the clients
suspense account or against subsidy already received from the government
E 1
283. FA.AR.4.6 Should support Payment Before Cover option as per Indian regulations E 1
284. FA.AR.4.7
Should be able to maintain an Accounts Receivable master record with details (Code,
Name, Address, Phone no., Email id, Payment Terms, Bank Account details, Payment
history, etc.):
E 1
285. FA.AR.4.8
Should be able to keep track of premium receipt from client in case of payment through
Bank Guarantee and generate alert when payment is not done before due date
E 1
286. FA.AR.4.9 Should be able to deduct commission recoverable from the payable commission E 1
287.
FA.AR.4.1 Should allow for creation of receivables at policy level, client level, and agent/broker and
E 1

0 co-insurer levels
288.
FA.AR.4.1
1
Should allow set off of receivables and payables at client level E 1
289.
FA.AR.4.1
2
Should allow treatment of negative payables as receivables (negative payables can come
into effect when recovery of agency commission due to refund/cheque dishonour exceeds
the commission payable on business procured for a given agent for a given period)
E 1
290. FA.AR.5
System shall interface with the Pension Auditing Software of Department of Telecom, EPF,
CPMF, Railways
E 1
Accounts Payable
Invoice receipt
291. FA.AP.1 System shall acknowledge receipt of invoices raised on DoP E 1
292. FA.AP.1.1
System shall allow for three way checking of invoices against Purchase Order and
acknowledgment of receipt (challan)
E 1
293. FA.AP.1.2
System shall support invoice entry along with payment schedules for direct invoices as well
as PO based invoices
E 1
294.
FA.AP.1.2.
1
System shall also allow for manual entry of invoice details E 1
295. FA.AP.1.3 System shall have the ability to block invoice payments to vendors along with reason codes E 1
296. FA.AP.1.4
System shall provide for authorization of release of payment against invoice raised to DoP
through defined workflow
E 1
297.
FA.AP.1.4.
1
System shall raise alert for approval of invoice to Sanctioning Authority basis delegated
financial powers
E 1

298.
FA.AP.1.4.
2
System shall record the approvals given by various Sanctioning Authorities for audit
purposes
E 1
299. FA.AP.1.5 System shall maintain Sub Ledgers for various vendors/ agencies E 1
300.
FA.AP.1.5.
1
System shall receive information on volumes transferred by air carrier and price rates from
IPVS
E 1
301.
FA.AP.1.5.
2
System shall calculate amount due to air carriers from price and volume information
received from IPVS
E 1
302.
FA.AP.1.5.
3
System shall maintain records of Railway Haulage charges due to Railways E 1
303.
FA.AP.1.5.
4
System shall pass accounting entries from vendor Sub Ledger into GL for any payments
made to other vendors/agencies
E 1
304.
FA.AP.1.5.
5
System shall track different kinds of advance payment made to vendors in the vendor Sub
Ledger
E 1
305.
FA.AP.1.5.
6
System shall maintain details of payment transactions for different vendors in Sub Ledgers E 1
306. FA.AP.1.6 System shall generate list of outstanding invoices and age of invoice E 1
307. FA.AP.1.7 System shall reflect invoice wise outstanding for a particular vendor or group of vendors E 1
308. FA.AP.1.8 System shall allow set off of receivables and payables at client level E 1
Payment
309. FA.AP.2 System shall allow for payments to be made to vendors through different modes E 1
310. FA.AP.2.1 System shall support flexibility for selecting invoices for payment E 1
311.
FA.AP.2.1.
System shall support selection of invoices that are yet to be paid E 1

1
312.
FA.AP.2.1.
2
System shall support selection of invoices that are approaching due date for payment E 1
313. FA.AP.2.2 System shall have the ability of advance to be given to vendors on the basis of PO E 1
314. FA.AP.2.3 System shall allow for partial payment of invoices E 1
315.
FA.AP.2.3.
1
System shall allow user to indicate whether particular payment will close an invoice E 1
316. FA.AP.2.4
System shall have the ability to release payments on account to a vendor and link it to
vendor specific invoice(s) received
E 1
317. FA.AP.2.5
System shall have the ability to facilitate centralized payment for multiple invoices raised
by a vendor
E 1
Error proofing
318. FA.AP.3 System shall provide for error checking E 1
319. FA.AP.3.1 System shall not allow for over payment to vendor E 1
320. FA.AP.3.2 System shall check for and stop duplicate invoices from being processed E 1
321.
FA.AP.3.2.
1
System shall alert the user against the possibility of duplicate payment E 1
Interface with Procurement
322. FA.AP.4 System shall interface with Procurement Function E 1
323. FA.AP.4.1
System shall create a payables record in AP upon receipt of goods by the indenting
office/designated consignee
E 1
324. FA.AP.4.2 System shall provide for online query of Purchase Orders from procurement Function E 1

325. FA.AP.4.3 System shall map invoice to the PO against which it was raised (if applicable) E 1
Interface with PBS
326. FA.AP.5 System shall interface with the PBS Function E 1
327. FA.AP.5.1 System shall make available to PBS, the payment details to be released to the vendor E 1
328.
FA.AP.5.1.
1
System shall interface with PBS notifying it of payments due as per scheduled payout dates E 1
329. FA.AP.5.2 System shall allow for user to hold payment to a specific vendor E 1
330. FA.AP.5.3 System shall be able to maintain master accounts payable data E 1
331.
FA.AP.5.3.
1
Address and contact details E 1
332.
FA.AP.5.3.
2
Bank details E 1
333.
FA.AP.5.3.
3
Payment terms E 1
334.
FA.AP.5.3.
4
Employee remarks E 1
335. FA.AP.5.4 System shall generate reports on Ageing analysis for payments due E 1
336. FA.AP.5.5 System shall maintain and generate reports on Outstandings with reasons and action plan E 1
337. FA.AP.5.6
System shall be able to calculate interest on overdue balances as it may be specified by
the user
E 1
338. FA.AP.5.7 System shall be able to capture data for printing cheque automatically from the system E 1

339. FA.AP.5.8 System shall be able to print cheque drawn on multiple bank accounts E 1
340. FA.AP.5.9 System shall be able to recover in the event of a failure in the cheque printing process E 1
341.
FA.AP.5.1
0
System shall be able to prevent the same cheque from being printed in both the original
and the recovery process run
E 1
342.
FA.AP.5.1
1
System shall reconcile voided, cancelled or returned cheque E 1
343.
FA.AP.5.1
2
System shall generate alerts for cheques pending for more than 7 days E 1
344.
FA.AP.5.1
3
System shall be capable of tracking rejections, retransmissions, returns E 1
345.
FA.AP.5.1
4
System shall be capable of integrating with SWIFT, NEFT, RTGS messages E 1
346.
FA.AP.5.1
5
System shall be able to handle employee expense reimbursement description, dates and
time periods, and cross reference to related sales outcome by:
E 1
347.
FA.AP.5.1
6
System shall distinguish between types of prepaid advances and adjustment of same while
passing the bill
E 1
348.
FA.AP.5.1
7
System shall be able to select bank accounts for disbursements, including reviewing
multiple bank accounts to determine the proper account to issue checks from
E 1
349.
FA.AP.5.1
8
System shall be able to process manual cheques E 1
350.
FA.AP.5.1
9
System shall be able to issue post dated cheques E 1
351.
FA.AP.5.2 In case of posted payment being voided, GL posting System shall be automatically
E 1

0 reversed
352.
FA.AP.5.2
1
System shall generate alerts / reminders based on the Payment terms with the Party E 1
353.
FA.AP.5.2
2
System shall be able to record reasons against payments E 1
354.
FA.AP.5.2
3
System shall provide facility to issue one cheque for multiple claims/transactions and
facility to issue the cheque in name of third party; System shall allow multiple payees for a
single transaction
E 1
355.
FA.AP.5.2
4
System shall have provision to set payment priorities (for cases when limited funds are
available)
E 1
356.
FA.AP.5.2
5
System shall enable electronic funds transfer to partners, vendors towards any payments E 1
357.
FA.AP.5.2
6
System shall support integration with the Core applications to alert the Accounts
Processing Centre for various payments due and enable electronic payments
E 1
Asset Accounting
Asset Database
358. FA.AC.1
System shall maintain a database of all assets at DoP exceeding ` 5000 in value at the time
of purchase
E 1
359. FA.AC.1.1 System shall maintain database of Assets purchased by DoP E 1
360.
FA.AC.1.1.
1
System shall fetch detail of assets purchased from Procurement Function E 1
361.
FA.AC.1.1. System shall update list and value of assets owned by DoP upon acknowledgement of the
E 1

1.1 receipt of assets by the indenting office
362.
FA.AC.1.1.
1.2
System shall note the date of purchase of asset E 1
363.
FA.AC.1.1.
2
System shall record the location of asset E 1
364.
FA.AC.1.1.
3
System shall record the description of asset E 1
365.
FA.AC.1.1.
4
System shall record the 'Salvage value' of the asset E 1
366.
FA.AC.1.1.
5
System shall record the 'Useful Life' of the asset E 1
367. FA.AC.1.2 System shall maintain database of Assets leased by DoP D 1
368. FA.AC.1.3
System shall support automatic posting when an asset is either retired, scrapped,
transferred, etc
E 1
Depreciation
369. FA.AC.2 System shall calculate value of depreciation of asset E 1
370. FA.AC.2.1 System shall notify Purchase officer when asset is nearing the end of its useful life D 1
371. FA.AC.2.2
System shall generate reports on a half yearly/ annual basis on list of assets owned by DoP
at Circle level
D 1
372.
FA.AC.2.2.
1
System shall be able to calculate the book value of asset in report E 1
373. FA.AC.2.3
System shall generate reports on a half yearly/ annual basis on list of assets owned by DoP
at pan India level
D 1

374.
FA.AC.2.3.
1
System shall calculate the book value of asset in report E 1
Interface with Budgeting E 1
375. FA.AC.3 System shall interface with Budget Function E 1
376. FA.AC.3.1
System shall make available to the Budget Function asset information for preparing Budget
estimates
D 1
377. FA.AC.3.2 System shall accommodate a user- definable asset number E 1
378. FA.AC.3.3 System shall be able to accommodate unlimited number of assets E 1
379. FA.AC.3.4
System shall be able to maintain details of written-off assets, whilst excluding these from
general reporting and all current asset valuation calculations
E 1
380. FA.AC.3.5 System shall generate sequential number per asset E 1
381. FA.AC.3.6
System shall be able to enter Project / Department cost centre codes in the fixed assets
system at the time of approval of Capex
E 1
382. FA.AC.3.7 System shall be able to maintain comprehensive fixed assets register, including: E 1
383.
FA.AC.3.7.
1
value of asset E 1
384.
FA.AC.3.7.
2
date of purchase E 1
385.
FA.AC.3.7.
3
asset reference code E 1
386.
FA.AC.3.7.
4
description E 1

387.
FA.AC.3.7.
5
short name E 1
388.
FA.AC.3.7.
6
memorandum notes (optional, and up to 1,000 characters) E 1
389.
FA.AC.3.7.
7
depreciation type E 1
390.
FA.AC.3.7.
8
depreciation formula E 1
391.
FA.AC.3.7.
9
accumulated depreciation E 1
Asset Verification
392. FA.AC.4 System shall facilitate inventory verification periodically E 1
393. FA.AC.4.1 System shall be able to categorize assets to facilitate a variety of depreciation rates E 1
394. FA.AC.4.2 System shall be able to change the method of depreciation E 1
395. FA.AC.4.3
System shall be able to maintain the status of an asset and related details stored when the
asset is sold or discarded along with a flag to highlight 'sold /discarded'
E 1
396. FA.AC.4.4
System shall automatically generate the necessary transactions to support asset write-
on's/write-off's
E 1
397. FA.AC.4.5 System shall automatically generate the entry for loss/Profit of sale of assets E 1
398. FA.AC.4.6 System shall automatically generate the necessary transactions to support asset transfers E 1
399. FA.AC.4.7 System shall facilitate tracking of maintenance (AMC) D 1
400. FA.AC.4.8
System shall automatically update the location of an Asset as soon as a Transfer Note is
E 1

approved for transfer of the asset
401. FA.AC.4.9
System shall automatically post write-on, write-off and transfer transactions to the
General Ledger
E 1
402.
FA.AC.4.1
0
System shall automatically post depreciation allocations as per user defined criteria E 1
403.
FA.AC.4.1
1
System shall request user verification for all transactions/processes performed E 1
404.
FA.AC.4.1
2
System shall be able to post adjustment transactions online to the General Ledger E 1
405.
FA.AC.4.1
3
System shall generate annual insurance re-valuation and replacement cost reports D 1
406.
FA.AC.4.1
4
System shall be able to generate Asset Valuation Report, by category E 1
407.
FA.AC.4.1
5
System shall be able to generate Asset Write-On, Transfer and write-off Report, for a given
period
E 1
408.
FA.AC.4.1
6
System shall be able generate Asset Write-On, Transfer and write-off Report, by Cost
Centre / Project
E 1
409.
FA.AC.4.1
7
System shall be able to track insurance status of assets, with alerts when renewal is due D 1
Payroll
Employee Database
410. FA.PY.1 System shall maintain database of Employees at DoP E 1

411. FA.PY.1.1 System shall maintain database of Employees on rolls of DoP E 1
412.
FA.PY.1.1.
1
System shall update list of Employees when an employee joins or exits E 1
413.
FA.PY.1.1.
2
System shall record the location where the employee is posted E 1
414.
FA.PY.1.1.
3
System shall record details about self, dependents , bank account, date of birth ,
permanent address etc
E 1

FA.PY.1.1.
4
System shall record the cadre and designation of employee E 1
415. FA.PY.1.2
System shall maintain database of all salary components of the employee like Basic salary,
HRA entitlement, TA,DA,LTC ,overtime, etc
E 1
416.
FA.PY.1.2.
1
System shall interface with the IPVS to fetch details of overtime working by mail operations
employees for payroll calculations
E 1
417. FA.PY.1.3
System shall interface with Establishment Review Master to get employee information for
calculating payroll
E 1
418.
FA.PY.1.3.
1
System shall fetch the leave details of each employee from the leave management system
in .xls or csv format which will be uploaded into the payroll processing module
E 1
419.
FA.PY.1.3.
2
System shall fetch the penalty and other details of each employee D 1
420. FA.PY.1.4
System shall notify the Salary processing team of an employees impending
retirement/superannuation based on date of birth record in the system
E 1
421. FA.PY.1.5
System shall support automatic update of salary components based on change in
employees location , status i.e. retired or transferred to a different location etc
E 1

Payroll calculation
422. FA.PY.2 System shall calculate payroll of employees in Circle E 1
423. FA.PY.2.1
System shall allow defined users to access payroll data and run payroll for respective
Circles only
E 1
424. FA.PY.2.2
System shall run separate payrolls for different cadres depending on eligibilities and rules
applicable for each category
E 1
425. FA.PY.2.3
System shall have the facility for reimbursements of Leave Travel Concession (LTC),
medical reimbursement, other reimbursements that the employee is eligible to
E 1
426.
FA.PY.2.3.
1
System shall check the payment against the overall entitlement E 1
427.
FA.PY.2.3.
2
System shall dynamically reduce the balance payable based on each part payment made E 1
428.
FA.PY.2.3.
3
System shall allow for employees to view the balance receivable at any time D 1
429. FA.PY.2.4 System shall maintain details of Loans & Advances of each employee on the payroll E 1
430. FA.PY.2.5
System shall compute all statutory deductions from salary such as Income Tax, GPF
contributions, HBA, Insurance premium etc(details to be finalized ) and deduct the same
from the Payout figure
E 1
431.
FA.PY.2.5.
1
System shall define various pay elements like earnings and deductions using a rule based
framework
E 1
432.
FA.PY.2.5.
1.1
System shall define the rules of earnings and deductions as per the guidelines of the
Government of India/State Governments
E 1
433.
FA.PY.2.5. System shall allow for the rules to be changed in case of directive by Government of
E 1

1.2 India/State Governments
434. FA.PY.2.6
System shall have the capability to handle tax computation of employees as per Income
Tax Act
E 1
435.
FA.PY.2.6.
1
System shall maintain the tax slabs, rates and surcharges and compute the tax
automatically
E 1
436. FA.PY.2.7 Disbursement of payroll shall be done only through bank credit E 1
437.
FA.PY.2.7.
1
System shall enable payroll disbursement into employee bank accounts through any of the
following three modes by generating a payroll detail file for uploading into PBS /Sanchay
post/ECS of other banks
D 1
438.
FA.PY.2.7.
1.1
System shall enable credit of the payroll amount directly into POSB accounts for the
identified 4000 PBS enabled branches
D 1
439.
FA.PY.2.7.
1.2
System shall enable credit of the payroll amount into employees ECS supported bank
accounts with other Public sector banks
D 1
440.
FA.PY.2.7.
1.3
System shall enable an MIS report for payroll of those employees who do have any PBS
enabled POSB/other bank ECS account and continue to have an account with a Sanchay
Post supported Post office
D 1
441. FA.PY.2.8
System shall generate exception report at every salary processing cycle to highlight any
discrepancies :Missing account nos., wrong account nos., closed /transferred SB accounts
etc.
E 1
442. FA.PY.2.9 System shall post the salary details to GL classified under appropriate HoA E 1
443. FA.PY.2.10 System shall be able to run multiple payrolls in a single instance E 1
444. FA.PY.2.11
System shall be able to maintain a single central payroll repository and be able to run and
access payroll from any location in a centralized or decentralized manner
E 1

445. FA.PY.2.12
System shall be able to handle the entire tax computation as per Income Tax Act without
any need for repeated manual calculations. The tax slabs, rates and surcharges System
shall be maintained by the system and the tax System shall be computed automatically
E 1
446. FA.PY.2.13
System shall be able handle the payment of reimbursements. This payment System shall
be set to be checked against the overall limit which will be dynamically reduced based on
each part payment. The balance against this eligible limit can be viewed for the employee
at
E 1
447. FA.PY.2.14 System shall support superannuation computation E 1
448. FA.PY.2.15 System shall be capable of calculating arrears when the scheme is revised E 1
449. FA.PY.2.16
System shall be able to define various formulae and be able to link them to other
calculation formulae / elements such that when there is a rule change only the component
which has undergone a change will be effected (e.g. tax slabs)
E 1
450. FA.PY.2.17 System shall take care of final settlement process to arrive at net to be recovered or due E 1
451. FA.PY.2.18
Simulation option System shall be available that can test run payroll for a chosen payroll
period
D 1
452. FA.PY.2.19
System shall be able to support the retrospective computation of changes to the various
data heads and makes the appropriate computation and payments in the current period.
These include changes in organization data, Employee data
E 1
453. FA.PY.2.20
A retrospective computation of the salary System shall be initiated automatically for those
employees whenever there is a relevant change. The appropriate re-computation of the
statutory aspects to be carried out. Tax shall also be automatically calculated.
D 1
454. FA.PY.2.21 System shall be able to prepare and submit quarterly and annual tax returns D 1
455. FA.PY.2.22 System shall support generation of Form 16 and other statutory documents E 1

456. FA.PY.2.23 System shall support integration with HRMS to take care of leave, attendance, etc. E 1
457. FA.PY.2.24 System shall be able to facilitate the back dating of allowances E 1
458. FA.PY.2.25 System shall be able to support various pay methods e.g. Autopay, EFT, Cash, Cheque etc. E 1
Maintenance of GPF Accounts
459. FA.PY.3 System shall maintain GPF accounts of DoP employees E 1
460. FA.PY.3.1 System shall post monthly credits to the GPF account E 1
461. FA.PY.3.2 System shall post debits to the GPF account when approved E 1
462. FA.PY.3.3 System shall calculate annual interest on GPF amount and post the same to the account E 1
463. FA.PY.3.4 System shall post the annual GPF amount on the employee portal E 1
464. FA.PY.3.5 System shall provide for printing the annual GPF slip E 1
Budgeting
465. FA.BD.1
The system should provide functionality for formulating various types of budget like:
Cash budget
Expense budget
Capital budgeting
Performance based budget
Zero based budgeting
E 1
466. FA.BD.2
The system should ensure completeness of data for preparation of budget (especially
when data has to be sourced from other source systems)
E 1
467. FA.BD.3 The system should interface with the procurement module E 1
468. FA.BD.4
The system should allow purchase orders to be raised for only those items which have
been included in the specified budget (fixed asset budget, administrative expenditure
E 1

budget, sales & marketing expenditure budget, etc)
469. FA.BD.5
The budget module shall have an inbuilt workflow defined for approval of all
procurements in line with Government of India regulations and actual transactions shall
take place only after the concurrence of Finance department has been received
E 1
470. FA.BD.6
The system should allow payment to be made only for budgeted expenses and
procurements
E 1
471. FA.BD.7 The system should provide functionality to define tolerance limit for the budget D 1
472. FA.BD.8
The system have functionality to configure approved Schedule of Authority for budget
approval and for passing of expenditure and payment which have not been budgeted or
are in excess of the budgeted amount
E 1
473. FA.BD.9 Any amendment to a budget should be approved as per the Schedule of Authority E 1
474. FA.BD.10 The system should interface with the accounting GL E 1
475. FA.BD.11 The system should interface with the fixed asset module D 1
476. FA.BD.12
The system should provide MIS report to highlight the following:
Approved budget
Budget utilized
Budget available
E 1
477. FA.BD.13
The system should generate variation reports (Variance Analysis report) at pre defined
intervals to monitor the budget
E 1
478. FA.BD.14
The system should mail/ circulate MIS reports and variance reports to the concerned
persons
D 1
479. FA.BD.15
The system should have access control privileges in order to protect confidential
information
E 1

480. FA.BD.16 System shall record the disbursals made against approved budgets E 1
481. FA.BD.17
System shall have checks in place to disallow any single purchase in excess of predefined
limits of the DoP ( currently ` 15000)
E 1
482. FA.BD.18
System shall account all procurements done by DoP and disbursed through the F&A
solution
E 1
483. FA.BD.19
System shall record and account for any disbursements under ` 15000 made directly
through F&A only after online approvals of designated users
E 1
484. FA.BD.20
System shall enable MIS reports of Sanctioned budgets, utilization and disbursement for
Internal audit and control purposes
E 1
Cash Management
485. FA.CM.1.1 The system should monitor payment and receipt flow E 1
486. FA.CM.1.2 The system should have functionality for defining a payment program E 1
487. FA.CM.1.3
The system should have functionality to upload the electronic bank statement in the cash
management system. (The system should support all the formats in which the bank
statements are normally provided in the banking industry in India)
E 1
488. FA.CM.1.4 The system should have a functionality to manually enter bank account statement (if any) E 1
489. FA.CM.1.5 The system should be able to do liquidity forecasting D 1
490. FA.CM.1.6 The system should integrate with the treasury application/ module (if any) E 1
491. FA.CM.1.7 The system should have functionality to create and edit payment advices (if any) D 1
492. FA.CM.1.8 The system should print account statements E 1
493. FA.CM.1.9
The system should be linked with the customer's/ vendor's account (if any) and update the
E 1

customer's/ vendor's account on receipt of cash from the customer or a payment being
made to the vendor
494.
FA.CM.1.1
0
The system should support online updation of account as well as batch updation of
accounts
E 1
495.
FA.CM.1.1
1
The system should have functionality to configure critical limits (based on solvency
assessment) in the account
E 1
496.
FA.CM.1.1
2
The system should have functionality to send alerts to the concerned people when a
critical limit is breached
E 1
497.
FA.CM.1.1
3
The system should have functionality to calculate and provide financial ratios like working
capital, etc
D 1
498.
FA.CM.1.1
4
The system should provide functionality of automatic transfer of cash above a certain limit
into pre defined investments
D 1
499.
FA.CM.1.1
5
The system should have Account Reconciliation facility E 1
500.
FA.CM.1.1
6
The system should have access control privileges in order to protect confidential
information
E 1
501.
FA.CM.1.1
7
The system should generate Cash Flow Statement for the defined period D 1
Costing
502. FA.CT.1.1 The system provide the functionality to define cost unit and cost Centre E 1
503. FA.CT.1.2
The costing system should facilitate decision making, cost control and meet reporting
requirement
E 1
504. FA.CT.1.3 The system should facilitate cost assignment and cost tracking for all the cost units and
E 1

cost centres
505. FA.CT.1.4 The system should provide standard costing functionalities E 1
506. FA.CT.1.5 The system generate variance reports to track standard vs. actual E 1
507. FA.CT.1.6
The system should provide/ support the following types of costing:
-- Job costing
-- Absorption costing
-- Activity Based Costing
-- Marginal costing
-- Target costing
E 1
508. FA.CT.1.7 The system should categorize the cost elements into fixed, variable and semi variable E 1
509. FA.CT.1.8
The system should provide the functionality to calculate the cost of production or cost of
rendering the service based on direct material cost/ direct cost related to provision of
service, conversion cost (if any) and non production cost/ costs not related to rendering of
service
E 1
510. FA.CT.1.9 Conversion cost should be computed based on the cost Centre E 1
511. FA.CT.1.10
The system should provide the functionality to have a common cost pool for unassignable
costs
E 1
512. FA.CT.1.11 The system should facilitate inventory valuation E 1
513. FA.CT.1.12
The system should allow bifurcation on 'personnel/ employee cost' into in house
employees and contracted employees
E 1
514. FA.CT.1.13
The system should interface with the material management module and have a common
item master
E 1
515. FA.CT.1.14 The system should interface with the financial accounting module E 1

516. FA.CT.1.15
The system should maintain standard as well defined costing templates for the various
products defined by Department of Post
E 1
517. FA.CT.1.16 The system should facilitate Product pricing E 1
518. FA.CT.1.17 The system should facilitate period based cost allocation E 1
Other Systems
Authorization of Pension Payments
519. FA.OS.1 System shall allow for sanctions for Authorization of Pension payments to DoP employees E 1
520. FA.OS.1.1
System shall make available to employees, the forms to be filled in for authorization of
Pension payout, through ESS
E 1
521. FA.OS.1.2
System shall allow for sanctioning of Pension payment to employee by respective
Sanctioning authority through MSS
E 1
522.
FA.OS.1.2.
1
System shall provide ability of the AO/AAO at the PAO to view and cross check E 1
523.
FA.OS.1.2.
2
System shall provide ability for the Directorate to view details E 1
524.
FA.OS.1.2.
3
System shall provide the sanctioning authority to raise an Enfacement Ticket online E 1
525.
FA.OS.1.2.
4
System shall allow for corresponding HO to view ticket online E 1
526.
FA.OS.1.2.
5
System shall allow for HO to reply to the clarification online E 1
527.
FA.OS.1.2.
System shall allow for the Sanctioning authority to close the ticket on approval E 1

6
528. FA.OS.1.3 System shall allow for Pensioner to apply for change request through ESS E 1
529.
FA.OS.1.3.
1
System shall accept application for Gratuity and Commutation E 1
530.
FA.OS.1.3.
2
System shall accept application for Fund management in a PBS bank E 1
531.
FA.OS.1.3.
3
System shall accept application for changing location of Pension payout E 1
532.
FA.OS.1.3.
4
System shall allow for sanctioning of request through MSS E 1
533. FA.OS.1.4 System shall communicate the changes made to the respective employee through ESS E 1
Self Service
534. FA.OS.2 System shall allow self service options with respect to New Pension Scheme E 1
535. FA.OS.2.1 System shall allow employees to fill up online forms for applying for NPS E 1
536.
FA.OS.2.1.
1
System shall record the following information of employees: Name, Designation, Scale of
pay, DoB, Nominee name, % of share
E 1
537. FA.OS.2.2
System shall allow for employee to view and generate online statement of deductions
under NPS
E 1
538.
FA.OS.2.2.
1
System shall maintain the Accounts and supply Annual Statement to employees E 1
539. FA.OS.2.3
In case of death of employee, system shall allow for sanctioning one-time payment of
accumulated amount to nominee
E 1

Authorization of New Pension
540. FA.OS.3 System shall allow for Authorization of New Pension E 1
541. FA.OS.3.1 System shall submit electronically form to Circle PAO real time E 1
542. FA.OS.3.2 System shall sent an alert to Circle PAO to assign PRAN E 1
543. FA.OS.3.3
System shall generate an electronically compatible information feed to NSDL for getting
PRAN at the circle office (NPS)
E 1
544. FA.OS.3.4 System shall send the PRAN electronically on line to DDO and the Official E 1
Pension Payment
545. FA.OS.4 Pension Payment E 1
546. FA.OS.4.1 System shall handle Pension payments to DoP employees E 1
547. FA.OS.4.2 System shall sub- classify components of pension E 1
548. FA.OS.4.3 There shall be no limits on the number of sub- classification within a pension account E 1
549. FA.OS.4.4 System shall define any specific rules for functioning of different pension accounts. E 1
550. FA.OS.4.5 System shall generation of the pension list branch wise. E 1
551. FA.OS.4.6
System shall update the pensioners list on an incremental bases in the event of new
inclusion / deletions in the event of death etc.
E 1
552. FA.OS.4.7
System shall generate an advice branch wise and pension account wise for any such
new inclusion / deletions.
E 1
553. FA.OS.4.8
System shall accept the details of the individual pension account holders (pensioners) like
PPO, Basic pay, Allowances, submission of life certificate, date of birth, date of
commutation, date of starting pension etc.
E 1

554. FA.OS.4.9
System shall capture the signatures of the pension holders and retrieve the same at any
point of time using hot keys (user definable)
E 1
555.
FA.OS.4.1
0
System shall calculate and post pension payments payable to different pension accounts
taking into account:
E 1
556.
FA.OS.4.1
0.1
- Salary structures E 1
557.
FA.OS.4.1
0.2
- DA / Interim relief rates E 1
558.
FA.OS.4.1
0.3
- Others E 1
559.
FA.OS.4.1
1
System shall at least capture key details of the individual pension account holders
(pensioners) like PPO, Basic pay, Allowances, submission of life certificate, date of birth,
date of commutation, date of starting pension etc.
E 1
560.
FA.OS.4.1
2
System shall automatically calculate and post pension arrears on account of revision of
salary structures or DA rates etc.
E 1
561.
FA.OS.4.1
3
System shall integrate with the clearing Function for cheques deposited in the parent
pension accounts
E 1
562.
FA.OS.4.1
4
System shall handle pension payments to the pensioners at the branches as defined for the
particular type of account e.g. pensioners only cash payments as per limits defined, State
Government Pension payment only through Bankers Cheque etc.
E 1
563.
FA.OS.4.1
5
System shall capture at least the minimum details at the time of payment i.e. account
number, particular of the transaction, amount, name of pensioner, time and date of
payment, mode of payment etc.
E 1
564.
FA.OS.4.1 System shall generate and track a particular transaction with the help of a unique
E 1

6 reference number.
565.
FA.OS.4.1
7
System shall generate a summary of pension payments made as of a particular date /
range of dates at the branch / head office level as parameterized.
E 1
566.
FA.OS.4.1
8
System shall generate an ASCII file for pension payments made by the branch as per
defined flat file structures.
E 1
567.
FA.OS.4.1
9
System shall upload ASCII file generated by branches not under core banking for all
pension payments made by them at the node / link branches.
E 1
568.
FA.OS.4.2
0
System shall generate a report branch wise for all un-reconciled entries at the parent
branch
E 1
569.
FA.OS.4.2
1
System shall automatically generate a report of all un reconciled entries more than x
number of days (parameterizable) at the parent branch
E 1
570.
FA.OS.4.2
2
System shall generate a consolidated summary for all types of pension payments (State
Government, central government etc.) under a particular pension account and sub
accounts (under central government - defense, railways, civil pension etc.) as of a pa
E 1
571.
FA.OS.4.2
3
System shall calculate and directly post pension payments in accounts linked to the core
banking solution from a centralized location
E 1
572. FA.OS.5
The CSI will need to deploy a fraud prevention solution to monitor movement of cash and
other remittances between various post offices
E 1

Interface with Bank Reconciliation software Public Account Current Software (PACS): For bank
reconciliation, DoP has implemented a separate bespoke solution called 'PACS' which will compare
the CBS bank book data from India post with CBS data received from the focal point branch of the
dealing bank at the circle office/DAP level

573. FA.OS.6.1 The F&A system shall have an outbound interface with the PACS solution E 1

574. FA.OS.6.2
The system shall send the daily bank book transactions for each clearing house post office
to PACS solution at every day end for reconciling with the CBS data received from the focal
point branch of the Bank
E 1
575. FA.OS.6.3 The Bank Reconciliation shall be done within the PACS solution E 1
Internal Audit & Inspection
576. FA.IA.1
User (Auditor) creation with access limited to viewing of EIS, Customer Transaction data
etc.
E 1
577. FA.IA.2 Ad-hoc report writing facility for the auditors D 1
578. FA.IA.3 Making ad-hoc queries satisfying the audit needs E 1
579. FA.IA.4
Interface enabling the data to be downloaded to the audit software for analysis of data for
audit purpose
E 1
580. FA.IA.5
Concurrent audit whereby transactions/activities deviating from business rules are
diverted on real-time basis to concurrent auditors.
E 1
581. FA.IA.6 Internal Audit Report Template for writing of Reports D 1
582. FA.IA.7 Monitoring & Scheduling of Internal Audits, Statutory Audits etc. D 1
583. FA.IA.8
System shall inform the Internal Audit modules users about any new
product/service/facility to customers/employees (such as loans) introduced by DoP by way
of a monthly MIS report
E 1
584. FA.IA.9
System shall be able to generate an MIS report highlighting any new product /
service/facility to customers/employees introduced in the specific Post Office(s) chosen
for audit between the last audit date and current audit date
E 1

7.2.4.5 Human Resources
#

C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Human Resources Management System
HRMS Administration & Set-up
1. HR A.1
HR master data is a part of the core HR Data that includes all the master data,
configuration and rules that enable Personnel and HRD transactions in the application.
E 1
2. HR A.2 Circle master manages Circle related information such as name, description etc. E 1
3. HR A.3 Region master manages region related information such as name, description etc. E 1
4. HR A.4 Division master manages Division related information such as name, description etc. E 1
5. HR A.5
Sub-Division master manages Sub-Division related information such as name, description
etc.
E 1
6. HR A.6
Location (City) master manage all the location details of offices (operative and
administrative) such as location name, address, phone number etc, office demographics,
planning information (sanctioned and working strength) against each post.
E 1
7. HR A.7
Office master manages Office related information such as name, description, unique office
number etc.
E 1
8. HR A.8
Holiday master helps in managing Holiday details such as Holiday date, holiday description,
holiday reason etc. Holiday lists can thus be maintained for different circles and regions if
E 1

the holidays differ
9. HR A.9
Competent Authority (workflow rules) master helps in assigning the appointing authority,
leave sanctioning authority and immediate supervisor so as to manage the HR processes
workflow
E 1
10. HR A.10
Document template manages different document templates that are used in different HR
Modules across the software.
E 1
11. HR A.11
Access control master manages the authorization for various processes based on the
cadre, location, process etc.
E 1
12. HR A.12
Organization Management Master manages the organization hierarchy- immediate
supervisor and reportees for every employee. This will help drive workflow for employee
and manager self service
E 1
13. HR A.13
Training Configuration Master manages the list of all the training Centres with the details
of number of classrooms, computers, hostel capacity etc
E 1
14. HR A.14
Establishment Review Master maintains a database of all establishments with the details
such as Unique Post Office No, Type and Classification, Functional status (Permanent/
Temporary), Planning info (sanctioned staff, working staff, order number), Locality Status,
Year of last establishment review, applicable rules for kind of work hour reports,
Periodicity of Establishment Review, Master for time norms (for departmental) and point
system (for GDS Offices)
E 1
Personnel Information System
15. HR B.1
Online Service Book is the record of service details throughout the employee lifecycle in
the organization
E 1
16. HR B.1.1 System shall maintain online service book for all departmental employees E 1
17. HR B.1.2 Online Service Book shall have different sections same as the existing service book E 1

18. HR B.1.3
Part A of the service book maintains the personal data about the employees that is entered
at the time of joining. System shall maintain the following personal data:
Employee Identification Number
Employee Name
Fathers Name
Spouse
Permanent Address
Address for Communication
Permanent Home Town
Nationality
Sex
Marital Status
Educational Qualifications (at the time of entry)
Educational Qualifications (subsequently acquired)
Professional and Technical Qualification
Exact Height
Personal Mark of Identification
Caste
Date of birth
Employee photo, Signature and Left Thumb Impression
Family Information
Details of the dependents including relationship, their month & year of birth, studying in
school/college, monthly income/pension amount
E 1
19. HR B.1.4
System shall allow an employee to view the scanned Employee Joining Forms such as
Family Pension Scheme Form, Form I for Nomination for Death-cum-Retirement Gratuity,
Nomination for Benefits under CGEIS Form -8, Declaration of Details of Family through the
service book
E 1

20. HR B.1.5
Part-II of the service book -Certificate and Attestation, shall maintain scanned copy of the
seven certificates for the verification carried out at the time of joining. System shall allow
uploading the scanned documents such as Medical Examination, Character and
Antecedent, Allegiance to Constitution, Oath of Secrecy , Marital Status, Declaration of
Home Town, Verification of entries in part 1.
E 1
21. HR B.1.6
Part III A of Service Book shall maintain the previous qualifying service and foreign service.
In case the employee has another service book for previous employment, data shall be
entered from that service book
E 1
22. HR B.1.7
Part III B of a Service Book shall maintain the Foreign Service Details -From To, Post held
and name of foreign employer, Leave and Pension Contribution payable by, Amount of
Leave and pension actually contributed actually Recovered
E 1
23. HR B.1.8
Part IV of the Service Book maintains the History and Verification of Service. Any entry in
the service book is triggered by a change in the Post, Office, Station, Scale of Pay and
Nature of Appointment triggered by events such as appointment, promotion, reversion,
deputation, transfer (including foreign service), increment, leave and suspension
E 1
24. HR B.1.9
System shall maintain the following details for History and Verification of Service -Period
(From-To), Post, Scale and Office (with station), Pay (Substantive and Officiating),
Triggering Event, Digital Signature of attesting officer and verifying authority with date,
Remarks
E 1
25. HR B.1.10
Remarks column is used to note any information which may not directly impact the entry
in the service book but is worth mentioning to explain the service record
E 1
26. HR B.1.11 System shall throw an error message if there is any explained gap in the service record E 1
27. HR B.1.12
Part V of the service book maintains the Leave Account of the Employee for the following
types of leave
Earned Leave
E 1

Half Pay Leave
Commuted Leave
Leave not Due
28. HR B.1.13
System shall maintain the following details in the leave account- Particulars of Service
completed and leave, completed months of service, leave credited in the beginning of half
year, no of days of leave availed in the past, leave to be deducted, Total leave at credit in
days, Leave taken (from-to), number of days
E 1
29. HR B.1.14
System shall credit/debit the leave based on the eligibility in terms of years of service. This
will interlink with the Leave Management Module of HRMS
E 1
30. HR B.1.15
Any update in the online service book shall be approved by an authorized official/attesting
officer
E 1
31. HR B.1.16
System shall allow the authorized user to administer changes to the documents or
personal details only if the employee requesting a change has produced the relevant
supporting documents
E 1
32. HR B.1.17
System shall display a user friendly view to the employee with details under relevant tabs
and links
E 1
33. HR B.1.18
System shall allow the authorized authority to take a print-out of the service book in a
specified period (say six months) that can be shared with the employee when He/she
raises a request
E 1
HR B.2 Employee Joining Process and Creation of Employee Record
34. HR B.2.1
Once a vacancy is closed on the recruitment module (when selection offer is made to the
candidate), system shall create a dummy employee record which shall derive data from the
recruitment module saving time for data re-entry
E 1
35. HR B.2.2
System creates the employee record and assigns a unique identification number to the
E 1

employee.
36. HR B.2.3
Unique ID and password is communicated to the respective employee at the time of
joining
E 1
37. HR B.2.4
When an employee joins, He/she sends the online charge report to his/her supervisor,
payroll and HR Administration Team
E 1
38. HR B.2.5
Employee Record is activated after the charge report is received. Joining documents such
as joining form, attestation, verification form and certificate for qualifying examination
shall be uploaded on the Document management system
E 1
HR B.3 Allotment of Unique Employee ID
39. HR B.3.1 Every employee in India Post shall be assigned a seven digit unique employee number D 1
40. HR B.3.2
The series of numbers to be used for assigning employee ID should clearly distinguish the
departmental employees from the extra-departmental (GDS) employees
D 1
41. HR B.3.3
For existing employees, the unique employee ID has to be assigned based on the year of
joining
D 1
42. HR B.3.4
For new employees, the number has to be assigned based on the year of joining after the
selection offers are send to the employees
D 1
43. HR B.3.5
Employee ID can have the year of joining appended at the end so that the year of joining
and seniority can be easily established from the employee number
D 1
44. HR B.3.6
Employee ID has to be retained for 30 years after the employee exits the organization. If an
employee, is suspended or is on deputation, the employee ID has to be retained for a
period as defined by Government of India
E 1
45. HR B.3.7
The provisioning of unique number to employees shall be controlled in a centralized
manner to ensure uniqueness and business logic
E 1

46. HR B.3.8
All the service and personnel records shall be associated with the unique identification
number
E 1
47. HR B.3.9
Unique Employee ID shall be maintained in an Active Directory that can be used for access
control for IPVS, POS, Core Banking Solution, Core PLI Solution, and Document
Management System.
E 1
HR B.4 Changes in PIS as a result of Probation and Confirmations
48. HR B.4.1
System shall maintain the confirmation rules and shall generate list of employees (meeting
confirmation criteria). System trigger process for confirmation based on defined rules
E 1
49. HR B.4.2
System shall allow tracking of probation period for each new employee and provide system
alerts on probation completion due dates
E 1
50. HR B.4.3
System shall allow an authorized official to make changes to the reporting authority,
location and employment status of the employee
E 1
51. HR B.4.4
System shall retrieve data on training undertaken by the employee and other details
(successful completion certified/tested) as needed for confirmation
E 1
52. HR B.4.5 System shall track passing of required exams (departmental/professional) for confirmation E 1
53. HR B.4.6
System shall record & generate alert on successful completion of confirmatory
Training
E 1
54. HR B.4.7
System shall generate list of employees confirmed on the basis of vacant permanent posts
available and should also declare remaining fit candidates to be confirmed
E 1
55. HR B.4.8
System shall allow authorized user to increase the duration of probation if employee not
confirmed due to given reason (non completion of training or passing of exam) and allow
related authority to define its impact on seniority.
E 1
56. HR B.4.9
System shall maintain standard formats of order given by India Post available in the system
E 1

for issuance of Confirmatory/Extension orders
57. HR B.4.10 System shall record/ update confirmation date and location of employee in data base E 1
58. HR B.4.11
Once an employee is confirmed his present post, system shall allow making changes to the
salary structure, seniority list, leave configuration, organization management, workflow
management etc.
E 1
HR B.5 Changes in PIS as a result of Promotion Process
59. HR B.5.1
System receives the list of candidates who have been selected for promotion for a cadre
based on seniority or departmental examination
E 1
60. HR B.5.2
System also receives the details such as new location, designation, date of relieving and
date of joining the new location, new and old immediate supervisor
E 1
61. HR B.5.3
System shall generate standardized promotion/posting letter using the template, for all
employees who have been promoted. Employee receives an alert to confirm and send
charge report on joining the new post/location
E 1
62. HR B.5.4
System shall allow employee to send online charge report to immediate supervisor of both
relieved and relieving official for approval and payroll department
E 1
63. HR B.5.5
Authorized Officials shall be allowed to update the PIS with the new details. Other
configurations such as leave configuration, organization management, workflow
management configuration, salary etc shall also be changed based on approval
E 1
64. HR B.5.6 System also tracks the status of charge reports and generate alerts accordingly E 1
HR B.6 Changes in PIS as a result of Transfer process
65. HR B.6.1
System shall allow the appointing authority to draw the list of candidates who are eligible
for tenure transfer after 4 years of service (in a post office or post) under Rule 37
E 1
66. HR B.6.2
System shall send a alert to the respective employee to send three locations of preference
E 1

for transfer or apply for extension with reasons to the appointing authority
67. HR B.6.3
System shall do the initial matching of the candidates preferences with the available
options of transfer locations. Transfer decision shall be guided by the Recruitment Rules
and roster points retaining the sanctioned strength as per defined rules.
E 1
68. HR B.6.4
System shall generate standardized transfer orders after approval from competent
authority
E 1
69. HR B.6.5
Candidates join the new location and send charge report to the appointing authority,
payroll and personnel department
E 1
70. HR B.6.6
System can track the completion of charge report after joining the new location and
generate alerts for the candidate
E 1
71. HR B.6.7
System shall allow for exceptions such as special transfer under Rule 38 or Request for
extension in the same office
E 1
72. HR B.6.8
In case of transfer under rule 38, an employee can apply for special transfer after 5 years
for direct recruitment and 3 years after promotion
E 1
HR B.7 Employee Separation Process/Exit Management
73. HR B.7.1
Personnel division starts the exit management process 6 months before the date of
retirement. System shall give the list of employees who are due for superannuation and
voluntary retirement
E 1
74. HR B.7.2
Personnel division shall generate alert for authorized official in accounts (payroll)
department to send the leave encashment certificate consisting of balance earned leaves
for the employee
E 1
75. HR B.7.3
Personnel division shall generate an approval request for the authorized official in
accounts department to calculate and generate certificates such as Group Insurance Letter,
Gratuity, GPF, and Loans & Advances.
E 1

76. HR B.7.4
Personnel division shall generate an approval request for the authorized official in
Administration department to generate for laptops, access card, and No-Dues from Library.
E 1
77. HR B.7.5
Accounts shall process the retirement benefits and issue a provisional PPO only after
receiving the no dues certificates (online/hard copy) from various departments
E 1
78. HR B.7.6 System shall track the completion of permanent PPO for the retiring employee E 1
79. HR B.7.7 On retirement, system shall convert the employee record to inactive record E 1
80. HR B.7.8
System shall retain the employee number and employee record for a period as defined by
Government of India
E 1
HR B.8 Organization Management
81. HR B.8.1
The system shall provide for effortless maintenance of the Organization structure using
tree structure and make changes in the structure with respect to Employee Post, Jobs and
the same shall get reflected in the Employee data. This shall be applicable to making
changes in Reporting relationships
E 1
82. HR B.9
System shall maintain employee and organizational data important for the workflow
management
Employment Status (Confirmed, Probationary, temporary, contract etc)
Recruitment rule applicable (Departmental Exam, Promotion, Direct Recruitment)
Designation
Cadre
Date of joining the Organization
Date of joining the cadre
Immediate Supervisor
Appointing Authority
Reportees
Job History and Promotion Details (Transfer and Promotions)
E 1

Emergency Contact Information
History of trainings attended like name of the course, name of the PTC/Institution, month
& year of training, duration of the course in days/weeks
Awards received by the employee including the name of the award, year of award, in
which discipline/filed and date of receipt of award
History of disciplinary actions against the employee including date of charge, nature of
charge, amount of financial loss to India Post, date of punishment and nature of
punishment
Work done outside India Post on deputation, details
Employee medical details
Blood group
83. HR B.10
System shall maintain the salary change details such as Pay details, PF Number, PAN
Number, Bank account information, date of pay change, annual increment, details of any
advances, GPF processed by the payroll department etc.
E 1
84. HR B.11 System shall maintain the information about the vigilance cases and the status of a case E 1
85. HR B.11.1
Any changes in the PIS that makes any changes to the above fields (except confidential
information such as Vigilance clearance and Disciplinary Actions)
E 1
86. HR B.11.2
System shall maintain the vigilance information about the employees. System shall allow
authorized officials to track and change status of vigilance information of an employee
maintaining confidentiality. Following information can be recorded in the Personnel
Information System:
Recordable warning issued
Period of suspension
Treatment of suspension period e.g. as duty, restricted to whatever given etc
Charge Sheet issued under Rule 16 of CCS (CCA) rules 1965 (Minor Punishments)
Charge Sheet issued under Rule 14 of CCS(CCA) rules 1965 (Major Punishments)
E 1

Minor penalty imposed
Major penalty imposed
Period of Penalty
Worked as Inquire Officer/presenting Officer/Defence Assistant in finalization of any
disciplinary proceedings
Prosecution (any criminal prosecution in the court of law)
Period of time when worked as in charge of single/double handed post office (in vase of
postal assistant)
Whether indemnity bond/bank guaranty obtained before posting as treasurer (in case of
postal assistants)
Whether police verification done and PVR is available on record at the time of entry into
the service)
87. HR B.11.3
System shall maintain access control for viewing parts of service details. For example, an
employee will not be able to view Vigilance related information.
E 1
88. HR B.12
System shall also allow authorized officials to maintain a log/calendar to track the court
cases regarding matters related to personnel
E 1
89. HR B.13
System shall support uploading/recording relevant details such as appreciation, award, and
certification of an employee.
E 1
HR B.14 Acknowledging the Seniority/Gradation List
90. HR B.14.1
System shall maintain cadre wise gradation list and seniority list for departmental and GDS
employees respectively for a pre-defined period based on the seniority (date of joining the
present cadre) as defined in Government of India rules
E 1
91. HR B.14.2
The cadre-wise gradation list shall be viewed and acknowledged by the respective
departmental employee and GDS employees on Employee Portal and on paper respectively
E 1
92. HR B.14.3
System shall display the cadre wise gradation list relevant to the departmental employees
E 1

on his/her Employee Portal for his/her acknowledgement
93. HR B.14.4
System shall track the completion status of online acknowledgement by employees on
portal
E 1
94. HR B.14.5
System shall send the seniority list for a GDS cadre to an authorized IPO/ASP to get
signatures on the paper based seniority list
E 1
95. HR B.14.6
System shall allow for an employee to send a representation if his/her position on the
gradation list is incorrect
E 1
96. HR B.14.7
System shall draw the seniority/gradation list every year for a specified period and shall
maintain the previous year list as defined by Government of India.
E 1
Leave Management
97. L 1.2.1
Leave Configuration- Manage Leave Types facilitates the configuration of Leave types in
an organization. There can be more than one Leave type for the selected configuration
period.

98. L 1.2.1.1
The system shall have the provision to maintain all types of leave like Casual Leave,
Paternity Leave, Maternity Leave, Medical Leave, Commuted Leave, Extra-ordinary leave,
Sabbatical leave, Half pay Leave and Leave not Due
E 1
99. L 1.2.1.2
The system shall have the ability to maintain leave eligibilities for each type of leave
depending on the rules specified by India Post
E 1
100. L 1.2.1.3
The system shall maintain rules for availing leave, en-cashing leaving, accrual of leaves,
lapsing of leaves, ceilings for accumulation of leaves and rules for combination of leave
types
E 1
101. L 1.2.1.4
System shall maintain rules for leave encashment, leave clubbing and leave truncation
rules
E 1
102. L 1.2.1.5
The system shall support transfer of people from one leave structure to another leave
structure
E 1

103. L 1.2.1.6
The system shall support comprehensive leave approval rules
Barred combination of leave
Leave only for working days
Leave for calendar days
Leave pre-fixing and suffixing with other leaves
Leave pre-fixing and suffixing with weekly-off and paid holidays
Minimum and maximum no of days at a stretch
Maximum no of incidents for any leave
Leave Encashment
Leave Clubbing
Leave truncation (carry forward to next year) rules
Negative Leave Balance Rule
E 1
104. L 1.2.1.7 System shall define hierarchical workflows for recommendation and approval of leaves E 1
105. L 1.2.1.8
System shall support a Business Calendar and Leave Application dates should be validated
against this calendar
E 1
106. L 1.2.1.9 System shall support on-line Leave application processing by providing required workflow E 1
107. L 1.2.1.10 System shall allow users to view leaves eligibility and leaves availed E 1
108. L 1.2.1.11
System shall be able to record the recommendation/ approval/ rejection of applied leaves
and update the employee leave account accordingly
E 1
109. L 1.2.2
Leave Balance Adjustment helps in adjustment of Leave balance by adding or deducting
the number of Leaves for individual employees or a selection of employees.

110. L 1.2.2.1
System shall allow an authorized official to make leave adjustment (credit/debit) for one or
group of employees
E 1
111. L 1.2.2.2
Leave Credit configuration facilitates crediting days of leave for an individual or selection of
employees between Confirmed, Contract, Probation and trainees.
E 1

112. L 1.2.2.3
The system shall have the provision for accounting for leave including automatic credit of
leave and manual credit / debit / modification / cancellation/adjustment etc
E 1
113. L 1.2.2.4
System shall allow for leave accruals on a monthly / quarterly / half-yearly / yearly and at
the beginning of a month or end of the month.
E 1
114. L 1.2.2.5
System shall inform an employee of leaves already deducted or to be deducted from
his/her account in future
D 1
L 1.2.3 Leave Request is used by an employee to request for leave.
115. L 1.2.3.1 An employee shall apply for leave through Employee Portal. E 1
116. L 1.2.3.2
In case Employee Portal is not available/accessible (for Group D and GDS), an alternate
source shall be arranged to bring the approved leave form nearest to the system.
Authorized Officials shall account for approved leave on the system
E 1
117. L 1.2.3.3
An employee can view details of leave types based on eligibility for him/her, along with
current leave balance
E 1
118. L 1.2.3.4
On submission, system shall forward the form for approval based on the workflow
configuration.
E 1
119. L 1.2.3.5
System shall support rules that can be set for multiple levels of approval and for eligibility
based approval.
E 1
120. L 1.2.3.6
Leave Calendar can be viewed by the employee for preceding and succeeding year to view
the leaves availed and planned training programs
D 1
121. L 1.2.3.7
System shall display an error message if there is a date conflict. An employee can not apply
for leave for the date for which the a leave application is already pending or approved
E 1
122. L 1.2.3.8
For medical leave, system shall allow uploading the scanned medical certificate and fitness
certificate from a doctor
E 1

123. L 1.2.3.8 System shall generate a warning for any document expiry during the planned leave period E 1
L 1.2.4
Leave Request Approval supports the leave sanctioning authority to approve the Leave
requests raised by employees and that directed to him or her for approval.

124. L 1.2.4.1
For casual or restricted holiday leave, leave sanctioning authority is the immediate
supervisor. In all other cases, leave sanctioning authority is the next higher authority.
E 1
125. L 1.2.4.2
The Leave Sanctioning Authority can view the leave request routed to him/her on his/her
Managers Portal and can accept/reject the leave request
E 1
126. L 1.2.4.3
System shall allow the Leave Sanctioning Authority to approve the leave request with
his/her comments along with a handover arrangement under office arrangement or
substitute arrangement, if the applicant works in a post office
E 1
127. L 1.2.4.4
System shall maintain the list of leave reserves for making substitute arrangement in place
of a candidate going on leave
E 1
128. L 1.2.4.5
System shall generate an alert for the substitute who has been arranged for that period
and his/her immediate supervisor in the post office so as to relieve him/her
E 1
129. L 1.2.4.6
System shall allow the Leave sanctioning authority to view the leave balance of the
applicant
E 1
130. L 1.2.4.7
In exceptional cases, the system shall allow the leave sanctioning authority to give special
grant when leave not due or negative leave balance
E 1
131. L 1.2.4.8 System shall be able to generate alert for giving reasons if leave application is rejected E 1
132. L 1.2.4.9
System shall be allow selection of general reasons of rejection from a dropdown menu and
provide a text box for inserting other specific reasons
E 1
133. L 1.2.4.10
System shall generate an alert on leave approval that can be viewed by the applicant on
his/her Employee Portal
E 1

134. L 1.2.4.11
System credits the leave account of the employee when He/she sends the charge report to
relinquish the charge from the date of leave. A copy of the online charge report is received
by immediate supervisor, authorized official in payroll department and personnel division
E 1
135. L 1.2.4.12
The substitute assumes charge and sends the online charge report to his/her immediate
supervisor, authorized official in payroll and personnel division. Employee going on leave
shall also send a charge report to relinquish charge.
E 1
136. L 1.2.4.13
System can track the completion of online charge report and generate alert for the
employee accordingly.
E 1
137. L 1.2.4.14
On approval of the leave, system shall calculate payment entitlement and raise
the necessary payment/recovery requisition if needed
E 1
138. L 1.2.4.15
System shall support conversion of one type of availed/sanctioned leave into
another based on the defined rule
E 1
139. L 1.2.4.16
If an employee joins earlier/later then approved date then system shall be able
to apply user defined rules for early, late returns and initiate adjustments/deductions
electronically in the Payroll Module after revised sanction
E 1
140. L 1.2.4.17
System shall have provision that a salary is stopped if a person is absent for
more than 1 month without proper sanction or as per rules and policies
E 1
141. L 1.2.4.18
System shall support regularization of unsanctioned absence period by grant
of different types of leave such as Leave with Pay and Leave Not Due
E 1
142. L 1.2.5 Leave Cancellation allows an employee to cancel an approved leave request
143. L 1.2.5.1
Employee can log on to Employee Portal and cancel a approved leave request with the
reason
E 1
144. L 1.2.5.2 System allows cancellation of only approved leave E 1

145. L 1.2.5.3 On submission, the request is forwarded to the leave approver E 1
146. L 1.2.6
Leave Cancellation Approval allows the leave sanctioning authority to cancel a leave
request

147. L 1.2.6.1
System shall display all cancellation requests on Leave Sanctioning Authoritys Managers
Portal.
E 1
148. L 1.2.6.2 System also allows for part cancellation of leave period. E 1
149. L 1.2.6.3
Leave Sanctioning Authority can view the Leave Cancellation request with reason. He/she
can also view the earlier approved leave request and comments.
E 1
150. L 1.2.6.4 Applicant gets an intimation on his/her Employee Portal on approval or rejection E 1
151. L 1.2.7
Leave Regularization allows an employee to regularize leave for past days without raising
a prior leave request.

152. L 1.2.7.1
System shall allow the employee to apply for leave regularization request on Employee
Portal. Employee inputs the leave type and number of days for regularization
E 1
153. L 1.2.7.2 System shall display only the past dates for leave regularization request E 1
154. L 1.2.7.3
System shall display and error message if there is a date conflict. System does not allow
applying for leave in the period for which leave has already been applied/approved
E 1
155. L 1.2.7.4 On submission, the request is forwarded to the leave approver. E 1
156. L 1.2.7.5
System shall allow a leave regularization for extended leave period provided it meets all
the leave rules and is approved by the leave approving authority
E 1
157. L 1.2.8
Leave Regularization approval allows the leave sanctioning authority to approve a leave
regularization request

158. L 1.2.8.1 System shall display all leave regularization request on approvers Portal. E 1

159. L 1.2.8.2
System allows the leave approver to accept/reject the leave regularization request with
comments
E 1
160. L 1.2.9
Leave Encashment allows the employees to en-cash Earned Leaves, at the time of
retirement

161. L 1.2.9.1
System shall maintain the Earned leave balance based on the eligibility rules (such as credit
based on completed years of service) for every employee
E 1
162. L 1.2.9.2
Employee can apply for the leave encashment on Employee Portal when the eligibility for
the leave encashment is met
E 1
163. L 1.2.9.3
System shall have the ability to send reminder to an employee when 300 earned leaves are
accumulated in his/her account
E 1
164. L 1.2.9.4
The application for leave encashment will be routed to the authorized official in payroll
department for checking eligibility and further processing.
E 1
165. L 1.2.9.5 System shall be linked to payroll and employee leave account in online service book E 1
Recruit Management
R 1.3.1 Recruitment Management Module Set-Up
166. R 1.3.1.1
Post Master maintains the details of all the post, designation, functional unit, cadre, grade,
probation and confirmation rule etc.
E 1
167. R 1.3.1.2
Vacancy Master maintains the post, number of vacancy against each post, designation,
grade, recruitment rule, category (General / SC / ST / OBC / Sports / PH), region
(directorate, circle, region, division or sub-division) job description and status
(Vacant/Occupied)
E 1
168. R 1.3.1.3
Recruitment Rules master manages the sanctioned staff under each cadre and the
recruitment rule applicable to the cadre
E 1

169. R 1.3.1.4
System shall maintain an annual recruitment calendar for departmental examination,
direct examination and seniority based promotion and track the completion status of each
recruitment
E 1
R 1.3.2 Post Management
170. R 1.3.2.1
System shall support to maintain a database of function or job profiles in the organization
with details such as profile name, business unit or function, cadre, description,
responsibilities and effective date (on which the profile was created) along with the order
number.
E 1
171. R 1.3.2.2
System shall support associating a post to the job profile. Every post shall have a unique
identification number.
E 1
172. R 1.3.2.3
System shall support adding post details such as post number, designation, function
profile, effective date, reason for creating the post, cadre, grade, pay scale, maximum
sanctioned number/head count, age, educational qualification, reporting authority,
number of reportees, experience/seniority required.
E 1
173. R 1.3.2.4
System shall allow taking approval from competent appointing authority (through
Managers Portal ) for any new post created
E 1
174. R 1.3.2.5
System shall allow making changes to the number of posts and other requirements of the
post.
E 1
R 1.3.3 Vacancy Management
175. R 1.3.3.1
System shall support maintaining a master list of approved vacancies for each post and
other details about the vacancies
E 1
176. R 1.3.3.2
System shall allow creation of vacancy under each post with recruitment rules (direct
examination, seniority based promotion, departmental examination), eligibility details in
terms of category and geography (circle, region, division).
E 1

177. R 1.3.3.3
System shall comply with the recruitment rules and eligibility defined in the recruitment
master while creating the vacancies
E 1
178. R 1.3.3.4
System shall allow taking approval from competent appointing authority through
Managers Portal for vacancies created under each post for each location.
E 1
179. R 1.3.3.5
System shall maintain the status of the vacancy
Vacant-in case no eligible candidate found for a published vacancy or vacancy number
not approved by the approver
Published- If vacancy communicated to the Recruitment Agency
Candidate Selected-if selected candidate approved
Closed-if the selected candidate has joined or rejected offer
E 1
180. R 1.3.3.6
System shall allow making changes to the number of vacancies and other requirements of
the vacancy such as category, educational qualifications etc according to the changes in
Government of India rules.
E 1
R 1.3.4 Calculation of Vacancies
181. R 1.3.4.1
System shall allow the calculation of vacancies (sanctioned staff minus actual staff) for
each cadre and for different modes of recruitment (such as promotion, departmental
examination and direct recruitment ) and category
E 1
182. R 1.3.4.2
System shall generate vacancy list sorted by cadre, ex - cadre & dying post and appropriate
recruitment mode
E 1
183. R 1.3.4.3
System shall draw information regarding vacancy that is due for creation because of
superannuation in a specified period
E 1
184. R 1.3.4.4
System shall allow online communication via e -mail or browser between administrative
department and other recruitment agencies
E 1
185. R 1.3.4.5
Vacancies that needs to be filled by seniority based promotion is communicated to the
E 1

respective appointing authority
186. R 1.3.4.6
System shall allow mapping of eligibility requirements against posts / grades / locations,
and at the same time maintenance of a vacancy database
E 1
187. R 1.3.4.7
System shall be able to provide for formats for placing advertisements for recruitment on
external and internal portals for departmental and direct recruitment
E 1
188. R 1.3.4.8
System shall be capable of short -listing from list of electronic applications received, on the
basis of essential criteria and highlight extent of fulfilment of desirable criteria for the
short-listed candidates
E 1
189. R 1.3.4.9 System shall provide facility for uploading of documents of new recruits E 1
190. R 1.3.4.10 System shall allow creation of employee records and service book for new recruits E 1
R 1.3.5 Seniority Based Promotions
191. R 1.3.5.1 System shall be able to define cadre specific and general promotion rules E 1
192. R 1.3.5.2 System shall store all the rules pertaining to promotion for every cadre E 1
193. R 1.3.5.3 System shall allow employees to view the rules for promotion E 1
194. R 1.3.5.4 System shall be able to identify vacant posts for promotion E 1
195. R 1.3.5.5
System shall be able to generate timely triggers indicating the due date for promotion
process to start based on model calendar
E 1
196. R 1.3.5.6
System shall check mandatory conditions such as completion of required service period
and/or completion of required service period at the lower post from which to be
promoted, before promotions
E 1
197. R 1.3.5.7
System shall be able to generate list of employees in zone of consideration as per specific
cadre/related general promotion rules
E 1

198. R 1.3.5.8 System shall be able to generate final gradation list to be submitted to DPC E 1
199. R 1.3.5.9
System shall record details of promotion declined in the past by employees in zone of
consideration
E 1
200. R 1.3.5.10
Appointing Authority shall view and download online APAR for last five years from the
online PMS
E 1
201. R 1.3.5.11
For internal DPC, the appointing authority shall have access to vigilance related
information from the PIS
E 1
202. R 1.3.5.12
For external DPC, appointing authority shall request for a vigilance clearance certificate
from respective vigilance department
E 1
203. R 1.3.5.13 System shall be able to generate online fit list of employees as decided by DPC E 1
204. R 1.3.5.14
System shall be able to block (keep promotions under sealed cover) employees from
promotion against whom DE/other events are pending till a final decision in the matter is
taken and recorded in the system
E 1
205. R 1.3.5.15
System shall update employee's grade & pay scale details resulting due to promotion
decisions
E 1
206. R 1.3.5.16
System shall have the facility to send a communication to the employee in case he/she is
promoted
E 1
207. R 1.3.5.17 System shall have standard formats of promotion orders available in the system E 1
208. R 1.3.5.18 System shall maintain the status of accepted and rejected offer letters by the candidates E 1
209. R 1.3.5.19
System shall draw the list of GDS staff who are eligible for seniority based promotion or
departmental examination based on the pre-defined rule
E 1
210. R 1.3.5.20
On selection of a GDS staff as departmental employee (Group D, Postman or Postal
Assistant), his/her record shall be updated in the PIS
E 1

R 1.3.6. Departmental or Direct Recruitment through a Recruitment Agency
211. R 1.3.6.1
Recruitment Management Module shall also allow for integration with the recruitment
agency through a interface such as a portal
E 1
212. R 1.3.6.2
System shall allow the Personnel division to post the number of vacancies under each
cadre with details about the location, eligibility and category, that need to be filled through
a direct and departmental examination on the recruitment portal for recruitment agency
E 1
213. R 1.3.6.3
Recruitment Agency shall be responsible for the following recruitment activities as defined
in the scope of work of outsourcing proposal:
Issue of Notification
Design the Application Kit
Receiving filled Application Form from candidates
Location wise list of applications received
Application Screening and List of Eligible and Ineligible candidates for Examination
Setting Question Paper and Answer Key
Exam Preparation Exercise
Sending Admit Cards to the Eligible Candidates
Conducting Examination
Evaluation of Answer Sheets
Preparation of Merit List of selected candidates
Helpdesk for handling the queries of the candidates regarding eligibility, admit card
Maintaining the recruitment portal content
E 1
214. R 1.3.6.4
System shall allow India Post to receive data from recruitment agency at different point in
time such as eligible candidates for examination, merit list of selected candidates based on
the location (circle, region, or division etc) or category
E 1
R 1.3.7 Post Selection Activities

215. R 1.3.7.1
System receives the merit list and forwards the same to the appointing authority for
approval
E 1
216. R 1.3.7.2
On approval, system allows for generating standardized selection letter for selected
candidates. For new joinees, the training details are also given which needs integration
with the training administration module
E 1
217. R 1.3.7.3
On approval, system creates Unique Employee ID and dummy employee record on the PIS
that shall draw details from the application form that was earlier filled by the employee
E 1
218. R 1.3.7.4 India Post initiates the process of verification of certificates and medical examination. D 1
219. R 1.3.7.5
The system shall keep provision to record the acknowledgement of offer letters, medical
reports, verified and authenticated testimonials, caste certificate and other relevant
certificates as per the user defined check list
E 1
220. R 1.3.7.6 System shall maintain the status of accepted and rejected offers by the candidates E 1
221. R 1.3.7.7
System shall also notify the list of new joinees and promotees to the respective training
institutes
E 1
222. R 1.3.7.8 The system shall support selection of candidates on compassionate grounds E 1
R 1.3.8 Time Bound Pay Scale Enhancement
223. R 1.3.8.1
System shall be able to define cadre specific and/or general rules in the system for Time
Bound Pay Scale Enhancement
E 1
224. R 1.3.8.2
System shall be able to generate timely triggers indicating the due date for Time Bound Pay
Scale Enhancement in all cases
E 1
225. R 1.3.8.3
System shall check mandatory conditions , such as completion of required service period
(completion of required service period) at the post on which Time Bound Pay Scale
Enhancement to be given
E 1

226. R 1.3.8.4 System shall access the gradation list for getting the list of candidates E 1
227. R 1.3.8.5
System shall update employee's grade & pay scale / pay band / grade pay details resulting
due to the decisions
E 1
228. R 1.3.8.6 System shall access APAR report of employee for the required period E 1
229. R 1.3.8.7 System shall have access to vigilance clearance information of an employee E 1
230. R 1.3.8.8 System shall be able to generate final gradation list to be submitted to DPC E 1
231. R 1.3.8.9
System shall be able to generate lists of employees in zone of consideration as per
cadre/general Time Bound Pay Scale Enhancement rules
E 1
232. R 1.3.8.10
System shall be able to defer grant of Time Bound Pay Scale Enhancement to employees
from against whom a final decision in matters related to vigilance or other inquiry, has
been taken and recorded in the system
E 1
233. R 1.3.8.11
Policy for Salary revision, Increments consequent upon Time Bound Pay Scale
Enhancement should be maintained in the system on -line and trigger them for pay fixation
process in related module
E 1
234. R 1.3.8.12
Authorized authority should have the provision to update employee data base, service
book and gradation list in the system
E 1
Performance Management
PM 1.4.1 Performance Management Module Set-Up
235. P M 1.4.1.1 System shall support performance management tools, tracking & reporting E 1
236.
PM
1.4.1.2
System shall be capable to create Performance Management Document for employees
depending on the cadre / grade in the organisation
E 1
237.
PM System shall have the ability to define performance scale for each parameter for each
E 1

1.4.1.3 cadre / grade so as to ensure that the same measures of performance are communicated
to the appraiser as well as the appraisee.
238.
PM
1.4.1.4
System shall define and maintain the workflow based authorizations for the reporting
manager, reviewing authority and accepting authority
E 1
239.
PM
1.4.1.5
System shall have inbuilt forms for Appraise & Appraiser to fill up E 1
240.
PM
1.4.1.6
System shall be able to log various stages of employee appraisal and evaluation process to
generate Performance Evaluation forms on -line and forward them through workflow
E 1
241.
PM
1.4.1.7
System shall generate alerts to point out if self assessment/review is over due E 1
PM 1.4.2 Objective Setting
242.
PM
1.4.2.1
Employee shall log-in to the Online Performance Management Module (PMS) through
Employee Portal
E 1
243.
PM
1.4.2.2
System shall allow the documentation of objectives under various accountabilities as
discussed with immediate supervisor (for Group A and B)
E 1
244.
PM
1.4.2.3
System shall allow for a reporting authority to set generic objectives for all operative staff
under his/her facilitation (Group C)
E 1
245.
PM
1.4.2.4
PMS shall allow for the Supervisor to log-in and view /edit objectives for his/her reportees E 1
246.
PM
1.4.2.5
System shall track the status of completion and send reminders/alerts accordingly E 1
247.
PM
1.4.2.6
System shall allow for editing the objectives whenever there is a change in the organization
management as a result of a transfer or promotion
E 1

248.
PM
1.4.2.7
System shall allow an employee to set two different set of objectives in a performance
year, only in case of a transfer or promotion
E 1
PM 1.4.3 Self Input and Annual Appraisal (Writing APAR)
249.
PM
1.4.3.1
PMS allows for an employee to log-in and submit the self-input (resume) for that year E 1
250.
PM
1.4.3.2
PMS shall allow for the Supervisor to view the self-input and fill the APAR form. E 1
251.
PM
1.4.3.3
Supervisor can access the PIS to check if any vigilance case is pending against the employee E 1
252.
PM
1.4.3.4
Supervisor can also check the number of trainings completed by the employee in the year E 1
253.
PM
1.4.3.5
For Group A and B, the reporting authority shall fill the APAR and forward the same to the
reviewing authority and then to accepting authority based on workflow
E 1
254.
PM
1.4.3.6
Reviewing and Accepting Authority can edit an APAR E 1
255.
PM
1.4.3.7
System shall support the ability of forwarding the APAR to an external authority such as
Ministry of Communication, who is accepting authority for posts HAG and above.
D 1
256.
PM
1.4.3.8
System shall share a copy of APAR with the employee only the final authority has accepted
the APAR
E 1
257.
PM
1.4.3.9
System shall be able to track the status of completion and send reminders/alerts
accordingly
E 1
258.
PM
1.4.3.10
System shall allow employee t o make representation against adverse comments reported
if any
E 1

259.
PM
1.4.3.11
System shall store finalized appraisal reports with restricted access E 1
260.
PM
1.4.3.12
System shall also store grades in a separate file to be accessed by the system for
confirmation and promotion processing, etc.
E 1
261.
PM
1.4.3.13
Trainings recommended in the APAR shall integrate with the Training Administration
Module
E 1
Establishment Review
E 1.5.1 Set-up the Establishment Review Database
262. E 1.5.1.1
Establishment Review Database is a master database containing information about each
establishment (post offices and administrative offices) such as:
Unique Number
Post Office Type and Classification
Functional status (Permanent/ Temporary)
Planning info (sanctioned staff, order number), establishment info (actual staff),
Associated Accounts Office
Post Master and Phone Number
Locality Status (State, District, Urban / Rural, Normal / hilly, Status of locality, Population,
Area served , No of villages)
Year of last establishment review and related changes etc.
Applicable rules for kind of Reports (Supervisory, Operative, Delivery Post Man, Group D
and GDS)
Periodicity of Establishment Review
Master for time norms (for departmental post offices ) and point system (Branch Offices)
Abolished posts, order number and date (for Head Post offices and Sub Post Offices)
E 1
263. E 1.5.1.2
Authorized officials from the HR Administration Team in each division, region and circle will
E 1

manage the workflow for Establishment Review process
264. E 1.5.1.3
Establishment Review shall be a customized interface that shall have the ability to draw
data from the data warehouse for applications such as PBS, PLI, IPVS, POS, Finance and
Accounts
E 1
265. E 1.5.1.4
Interface shall maintain the formats required for the workload analysis such as EST 2, EST
79, EST 5, Workload Analysis for GDS Post
E 1
266. E 1.5.1.5
System shall maintain proposal formats (for Conversion of part of temporary establishment
to permanent establishment, continuing remaining temporary establishment, on creation
of new establishment on surrender of old establishment post, surrender existing
establishment posts (temporary/permanent) cadre review) available in the system so that
proposal can be created.
E 1
267. E 1.5.1.6
System shall maintain a master of the time norms and point factors for various kinds of
post offices and posts
E 1
268. E 1.5.1.7
System shall also maintain the expenditure of running a GDS Post office with details of
number of GDS post and allowances paid
E 1
269. E 1.5.1.8
System shall allow the HR Representative to assign a IPO/ASP for verification of statistics
and collection of data that could not be drawn from data warehouse
E 1
270. E 1.5.1.9
System shall maintain the conditions and rules for the kind of reports (operative,
supervisory, Group D, GDS, Postman) that must be generated for each establishment
depending on the classification and working staff
E 1
271. E 1.5.1.10
System shall maintain the templates for EST 2, EST 79, EST 5, summary of work hours
reports for Supervisory, Operative, Delivery Post Man, Group D and GDS based on type of
post office
E 1
272. E 1.5.1.11
System shall allow authorized user to perform analytics on sanctioned posts in a cadre and
E 1

establishment unit (old/new/to-be)
273. E 1.5.1.12 System shall allow generation of lists of permanent/temporary posts at any time E 1
E 1.5.2 Workload Analysis of Departmental Post Offices
274. E 1.5.2.1
System allows the authorized HR official in the HR Administration Team at each division to
identify the post offices due for periodic review based on the pre-defined periodicity
through the Establishment Review Module
E 1
275. E 1.5.2.2
On request, the authorized official will request the MIS team to send data from the data
warehouse that he/she can view in the interface. The kind of data will be the number of
transactions for different products and the value of transactions (in some cases)
E 1
276. E 1.5.2.3
System shall have the ability to draw the statistical information for four calendar months,
regarding the number of transactions of each type happening in a post office
E 1
277. E 1.5.2.4
Authorized users shall send a copy of MIS report to the IPO with filled statistical data and
blank fields so that he/she can collect the data from the respective post office
E 1
278. E 1.5.2.5 Authorized official shall enter the data manually in the interface, data that was send by IPO E 1
279. E 1.5.2.6
Authorized official shall apply pre-defined time norms from time factor master file to
generate work hour summary reports for operative, supervisory, sorting postman, GDS and
Group D as applicable to the post office
E 1
280. E 1.5.2.7
System shall draw information regarding the current staff hours from the Establishment
Review Master
E 1
281. E 1.5.2.8
System shall bring together the summary of all kinds of work hours summary reports and
the staff hours in EST 79 format
E 1
282. E 1.5.2.9
System shall retain one copy of the summary of work hours (EST 79) and forward another
copy to the authorized official in region office along with the proposal for further
E 1

consideration
283. E 1.5.2.10
Any changes in the Establishment Information as a result of workload analysis shall be
updated in the Establishment Review Master
E 1
E 1.5.3 Workload Analysis of GDS Posts
284. E 1.5.3.1
System allows the HR representative for Establishment Review at each division to identify
the GDS post in branch post offices due for periodic review based on the pre-defined
periodicity
E 1
285. E 1.5.3.2
System allows the HR representative for Establishment Review to raise a request for MIS
report (in prescribed format) with filled in statistical data for the defined period
E 1
286. E 1.5.3.3
System supports the ability to draw data stored in data warehouse by different software
such as IPVS, POS, Core Banking Solution, and PLI Solution. The kind of data will be the
number of transactions for different products or the value of transactions.
E 1
287. E 1.5.3.4
E 1
288. E 1.5.3.5
For data that cannot be drawn from the data warehouse directly, IPO/ASP shall be
collecting that data. System allows an authorized official to input that data in the MIS
report
E 1
289. E 1.5.3.6
System shall apply pre-defined point system from master file to generate work hour
summary for various GDS post as applicable to the post office
E 1
290. E 1.5.2.8
System shall draw information regarding the current staff hours from the Establishment
Review Master
E 1
291. E 1.5.2.9
System shall retain one copy of the summary of work hours and forward another copy to
the authorized official in region office along with the proposal for further consideration
E 1

292. E 1.5.2.10
Any changes in the Establishment Information as a result of workload analysis shall be
E 1
E 1.5.4 Financial Assessment of Branch Offices
293. E 1.5.4.1
System allows the HR representative for Establishment Review at each division to identify
the post offices due for financial assessment based on the pre-defined periodicity
E 1
294. E 1.5.4.2
System allows the HR representative for Establishment Review to raise a request for MIS
report (in EST 5 format) with value returns (income and expenditure) for the branch office
E 1
295. E 1.5.4.3
System supports the ability to draw data stored in data warehouse by different software
such as IPVS, POS, Core Banking Solution, PLI Solution and Rural ICT. The kind of data will
be the number of transactions for different products or the value of transactions.
E 1
296. E 1.5.4.4
E 1
297. E 1.5.4.5
System shall also information about cost (static and dynamic) of running a establishment
such as allowances paid to the GDS employees, number of GDS post, rent of building as in
the prescribed format
E 1
298. E 1.5.4.6
For data that cannot be drawn from the data warehouse directly, IPO/ASP shall be
collecting that data. System allows an authorized official to input that data in the MIS
report
E 1
299. E 1.5.4.7
System shall calculate the income and expenditure and check the eligibility against the pre-
defined permissible limit of loss
E 1
300. E 1.5.4.8
System shall retain one copy of the summary of work hours (EST 5) and forward another
copy to the authorized official in region office along with the proposal for further
consideration
E 1
301. E 1.5.4.9
Any changes in the Establishment Information as a result of financial assessment shall be
E 1

E 1.5.5 Update the Establishment Review Database
302. E 1.5.5.1
Any change in the Establishment information as a result of workload analysis or financial
assessment leads to decisions such as:
Up gradation or down gradation of post office
Closure or merger of post offices
Change in the GDS allowances
Redeployment of post
Abolition of Post
Retention of a temporary post office
E 1
303. E 1.5.5.2
System shall allow updating the Establishment Review Database with the order number
issued by circle, region or division and date of the order.
E 1
304. E 1.5.5.3
System shall also allow updating PIS in line with the changes in Establishment Review
Master as this forms the basis of many HR processes such as Periodic Review (Workload
Analysis), Vacancy Calculation, Payroll, Transfer Process etc
E 1
305. E 1.5.5.4
Scope of the Establishment Review Process depends on the scope of the business
operations performed in the post offices. Therefore, any changes in the operations and
activities in the post office shall be taken into account to revise the line items or time
factors for workload analysis. System shall have the capability to incorporate such changes
in future. Items of work or description of work is likely to undergo changes after
implementing of the IT Modernization. Items of work could be added, eliminated or
modified. This will have to be factored in while configuring the Establishment Review
Module.
E 1
Training Administration Module
T 1.6.1 Training Set-up

306. T 1.6.1.1
System shall support the training administration for the entire training infrastructure (1
PSCI, 6 PTCs, 81 WCTCs and 70 Divisional Training Centres and 6 Zonal Training Centres)
E 1
307. T 1.6.1.2 System shall support online uploading of draft and final Training policy E 1
308. T 1.6.1.3
System shall support alignment of training institutes with Training Calendar and training
courses as each training centre is mandated to provide a pre-define kind of training
E 1
309. T 1.6.1.4
System shall maintain the target audience for a training centre as each training centre is
mandated to cater to a training needs of pre-defined circle/region/division based on
geography
E 1
310. T 1.6.1.5
System shall maintain the master list for faculty, classroom, number of computers, hostel
accommodation and batch size
E 1
311. T 1.6.1.6
System shall authorize the Training centre-In charge of each training centre for Training
Administration activities such as course administration, class scheduling, Manage
Registration, training feedback etc.
E 1
312. T 1.6.1.7
System shall authorize appointing/relieving authority and immediate supervisor to approve
or cancel a nomination through workflow management
E 1
313. T 1.6.1.8
Training and Development needs identified through Performance Management Module
shall be captured in the system as priority needs for related employees
E 1
314. T 1.6.1.9
System shall facilitate training need analysis by allowing employees to fill up online
questionnaires or competency testing system
E 1
315. T 1.6.1.10
System shall have formats available in the system for proposal creation, training plan,
budget preparation and allocation of training budget to field units
E 1
T 1.6.2 Load Training Calendar
316. T 1.6.2.1
Based on the training set-up, authorized official shall prepare and load the annual training
E 1

calendar
317. T 1.6.2.2
System shall allow training institutes to follow standardized training calendar as loaded
centrally by HRD and schedule some training programs based on the needs of a specific
circle/region and division
E 1
318. T 1.6.2.3
Every employee can view his/her personalized training calendar for at least next six
months on Employee Portal
E 1
319. T 1.6.2.4
System shall track the status of completion of mandatory training and generate alert for
probationary, new promotees and new joinees
E 1
T 1.6.3 Course Administration
320. T 1.6.3.1
System shall authorize a training centre in-charge to administer a course by adding course
details such as Target participants, Duration, Maximum and Minimum Batch Size, Faculty,
Program Objectives and Program Content, Select Course Evaluation Template
E 1
321. T 1.6.3.2
System shall send the course details to the respective appointing authorities, respective
HRD team, Faculty and Target Audience
E 1
322. T 1.6.3.3
System shall track due date for the course and generate alert for training administrator
and HR.
E 1
T 1.6.4 Class Scheduling
323. T 1.6.4.1
System shall allow self-registration(for Group A and B) and Nomination by Training
Administrator
E 1
324. T 1.6.4.2
For induction training for new joinees and promotees, the training administrator shall
receive a list of new joinees or promotees from the Recruitment module
E 1
325. T 1.6.4.3
System support maintenance of training profile for each employee including
recommended training, completed courses, certifications in PIS/Service Book.
E 1

326. T 1.6.4.4
System shall allow the Training Administrator to search and select candidates who have
not completed a particular training course
E 1
327. T 1.6.4.5
System shall allow to nominate candidates based on the pre-defined seat allocation for
each circle, region and division
E 1
328. T 1.6.4.6 System shall allow the training administrator to nominate more people than the batch size E 1
329. T 1.6.4.7
System shall forward the training nomination to respective workflow based approver/
(relieving authority)
E 1
330. T 1.6.4.8 System shall authorize the approver to accept/reject the nominations. E 1
331. T 1.6.4.9
System shall maintain the list of leave reserves for making substitute arrangement in place
of a candidate going for training
E 1
332. T 1.6.4.10
For any rejected nomination, the approver shall provide a alternative for him/her, for
which He/she can view the list of people under her/his circle, region, division who have not
completed that course
E 1
333. T 1.6.4.11
System shall allow for maintaining a confirmed list and waitlist for the training program
based on the session capacity.
E 1
334. T 1.6.4.12
Employee gets alert on change in registration status such as Registered, Wait-Listed or
Confirmed
E 1
335. T 1.6.4.13
For accepted nominations, the supervisors of the registered candidate is informed so as to
relieve him/her for training
E 1
T 1.6.5 Manage Registration
336. T 1.6.5.1 System shall send reminders to the enrolled candidates and supervisors E 1
337. T 1.6.5.2 System shall draw the report of candidates registered for a particular course E 1

338. T 1.6.5.3
Employee shall send a confirmation (with travel details) or request for a cancellation, 15
days before the training program
E 1
339. T 1.6.5.4
System shall request the candidate to register for the next course when cancelling the
current registration. Employee can view personalized training calendar and schedule of the
next training course
E 1
340. T 1.6.5.5
In case of a cancellation of a registered candidate, system shall automatically push the
wait-listed candidates up the list
E 1
341. T 1.6.5.6
In case of a cancellation of training program when session capacity not met, system shall
send a system initiated email to the respective candidates
E 1
342. T 1.6.5.7 System shall allow an authorized training in-charge to re-schedule a course E 1
343. T 1.6.5.8
System shall maintain the list of cancelled/re-scheduled course and inform the respective
candidates. These candidates shall be given preference while administering the course in
future
D 1
344. T 1.6.5.9
System also facilitates mapping training courses to employees based on training
recommended in the APAR. During the Performance Appraisal Process, it is possible for the
Appraiser to recommend specific or generic training that they feel the appraised employee
should undergo.
E 1
T 1.6.6 Training Delivery
345. T 1.6.6.1
System shall support sending pre-reads or instructions to the registered candidates.
System shall support the training material in Hindi and English language.
D 1
346. T 1.6.6.2 System shall support marking attendance of the candidates E 1
347. T 1.6.6.3 System shall allow online payment transfer to training providers / vendors D 1
T 1.6.7 Administer Training Feedback

348. T 1.6.7.1
System shall allow selection of evaluation template from various available templates.
System shall support the templates in Hindi and English language.
E 1
349. T 1.6.7.2
System shall have provision for creation of instruments for online evaluation of training by
employees/supervisors whose access and response recorded in the system
E 1
350. T 1.6.7.3
System shall have provision for online tracking of responses uploaded by related
(trainees/supervisors) and generate reminders/escalation to superiors if not done by due
date
E 1
351. T 1.6.7.4 System shall have provision for online compilation of responses to evaluation Instruments E 1
352. T 1.6.7.5 System compiles the consolidated training feedback report and sends to the HRD Division E 1
T 1.6.8 Administer Participant Evaluation
353. T 1.6.8.1
System allows for a participant evaluation test/assessment with options for scoring and
correct answers. System shall support the test in Hindi and English language.
E 1
354. T 1.6.8.2
System shall draw a report with consolidated results (in percentile) to be shared with
candidates
E 1
355. T 1.6.8.3
System shall allow for the scores/ certification to be captured in the PIS. System shall
register an employee for re-training if they fall in the group (Needs Improvement)
E 1
356. T 1.6.8.4
System shall be able to grade the performance of the candidates in 3-4 groups to identify
the best performers and the candidates who need improvement
E 1
357. T 1.6.8.5
System shall consider the candidates marked as Needs Improvement for next training
program in a WCTC/Divisional Training Centre
E 1
T 1.6.9 Post Training Activities
358. T 1.6.9.1
System allows for updating training record (attendance and evaluation) for an employee
after completion of the training
E 1

359. T 1.6.9.2
System shall provide for taking online feedback from supervisor one month after the
training completion. System shall aggregate the result to be used by HRD Division
E 1
360. T 1.6.9.3 System allows for reporting the cost of the training under various heads E 1
361. T 1.6.9.4
System shall provide summary analysis of training evaluations, participant evaluation,
attendance, and cost after completion of training.
E 1
362. T 1.6.9.5
System shall support the update of training database for GDS, by an authorized official
(such as the IPO/ASP)
E 1
363. T 1.6.9.6
System updated the PIS and Online Service Book with the training details and the scores
received in the training
E 1
364. T 1.6.9.7
System shall support the training administration for e-learning programs in future as India
Post is planning to go for e-learning in future.
D 1
Employee Portal
365. EP 1.7.1
Employees shall have access to the following:
Individual log-in ID and password to every employee
Ability to view personal and service records such as online service book, gradation list
etc.
Ability to view and edit personal data
Ability to initiate Employee Portal transactions such as:
o Leave Management
o Performance Management
Training Administration
Ability to view the status of a request
India Post News and Updates (common content and location specific)
E 1
366. EP 1.7.2 Managers shall have access to the following: E 1

Besides the above Employee Portal features, managers shall be able to view the view and
accept/reject the Employee Portal transactions directed to them by his/her staff
Ability to view the relevant information about the employee when approving a request
such as leave balance summary etc.
Ability to view MIS reports , based on authorization
367. EP 1.7.3
Employee Portal also maintains links for Employee Search, Post Offices Search, Expert
Directory, My Service Book, My Training Page etc.
E 1
368. EP 1.7.4
Employee Portal shall also provide functionalities such as raising a query for HR, applying
for LTC, Medical Claims, and Cash Advance. Through workflow management, this shall be
routed to the manager for approval and to the Payroll for processing
E 1
369. EP 1.7.5 System shall support the Employee Portal content in Hindi and English language. E 1
370. EP 1.7.6
HR Administration Team shall be responsible for the following:
Ensure proper workflow management
Track the status of pending approvals
Manage the content on the portal
E 1

7.2.4.6 Customer Interaction Management
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Point of Sale
Overall

1. POS1.1 The solution shall provide PoS support E 1
2. POS1.2
The system shall provide access to only DoP employees (administrators, users, etc) using
unique employee user id and password
E 1
Information Management
3. POS2.1
The system shall provide information to the citizens about DoP (such as history,
management, mission, organization, citizen charter, etc.)
E 1
4. POS2.2
The system shall provide information about various products and services offered by the
DoP
E 1
5. POS2.2.1
The system shall integrate with the Mail Operations system to provide information about
various mail products and services
E 1
6. POS2.2.2
The system shall integrate with the PBS to provide information about various banking
products and services
E 1
7. POS2.2.3
The system shall integrate with the PLI system to provide information about various
Insurance products and services
E 1
8. POS2.2.4
The system shall integrate with Mail Operations system to provide information about
various retail products and services
E 1
9. POS2.3
The POSS shall support rich media content (such as flash video, audio, or video (mpeg,
mov, asf, etc.); rich content such as a robust user interface)
D 1
10. POS2.4 The system shall enable Product Data Management D 1
11. POS2.4.1 The system shall provide/leverage new or existing cross-sell rules D 1
12. POS2.4.2 The system shall provide/leverage new or existing up-sell rules D 1
13. POS2.4.3 The system shall provide product bundling D 1

14. POS2.5 The system shall support Unicode (multiple languages) E 1
Transaction Management
15. POS3.1 The system shall enable Order Capture E 1
16. POS3.1.1
The system shall enable users to browse, search and compare different products and
services
E 1
17. POS3.1.2 The system shall enable users to place the order for different services E 1
18.
POS3.1.2.
1
The system shall integrate with Mail Booking Engine for all transactions related to mail
articles
E 1
19.
POS3.1.2.
2
The system shall integrate with PBS for all banking related transactions E 1
20.
POS3.1.2.
3
The system shall integrate with PLI system for all insurance related transactions E 1
21.
POS3.1.2.
4
The system shall integrate with Mail Booking Engine to record the Retail Post sale
transaction
E 1
22.
POS3.1.2.
4.1
The system shall enable users to place order for DoP products (such as Stamps, Postcards,
Envelopes, Stationary, and Philately etc.)
E 1
23.
POS3.1.2.
4.2
The system shall enable users to place order for DoP featured products (India, abroad and
warehouse)
E 1
24.
POS3.1.2.
4.3
The system shall provide reservations for the out-of stock products D 1
25. POS3.2 The system shall allow Order Management E 1
26. POS3.2.1 The system shall provide home pick up, delivery and return of articles and orders D 1

27. POS3.2.2 The system shall integrate with IPVS to enable users to create track and trace alerts E 1
28. POS3.2.3 The system shall provide customer order history based on the customer id E 1
29. POS3.2.4
The system shall be able to automatically capture the weight of the article using the
weighing machine connected to the PoS counter machine
E 1
30.
POS3.2.4.
1
The system shall allow the user to manually enter the weight of the article in case the
weighing scale is not connected to the PoS counter machine
E 1
31. POS3.2.5
The system shall be able to read the barcode scanned by the office scanner connected to
the PoS counter machine
E 1
32. POS3.2.6
The PoS shall be able to print out the article labels, barcodes, customer receipt etc using
the printer connected to the POSS counter machine
E 1
33. POS3.3 The system shall allow order payment management E 1
34. POS3.3.1
The system shall integrate with different systems (Mail Booking engine, PLI and CBS) and
produce a single consolidated bill for all the transactions done by the customer
E 1
35. POS3.3.2
The system shall be able to process cash payments from the customer against the bill
outstanding
E 1
36. POS3.3.3
The system shall be able to process payments using credit card / debit card / cash card
from the customer against the bill outstanding
E 1
37.
POS3.3.3.
1
The system shall integrate with the payment gateway using the magnetic card swipe
machine connected to the PoS counter machine
E 1
38. POS3.3.4
The system shall be able to process payments using direct debit from the Postal Savings
Bank of the customer against the bill outstanding
E 1
39. POS3.3.5
The system shall be able to process payments using Bill Me Later Payment method (e.g.
cash on delivery, VPP) for the customers against the bill outstanding
E 1

40. POS3.3.6
The system shall be able to process payments using cheques from the
bulk/corporate/BNPL customers against the bill outstanding
E 1
41.
POS3.3.6.
1
The POSS shall not accept and process cheques provided by the individual customers
against any amount outstanding
E 1
Account Management
42. POS4.1 The system shall provide access to only DoP employees (i.e. administrators and users) E 1
43. POS4.2 The system shall allow only administrators to create/add new user to the PoS counter E 1
44. POS4.2.1
The system shall allow administrators to define the user rights and the transactions which
shall be allowed to be performed at the PoS counter
E 1
45. POS4.2.2
The system shall integrate with the Active Directory to add the user profile as created by
the administrator
E 1
46. POS4.3
The system shall allow users and administrators to access the terminal using the unique
username/user id and password
E 1
47. POS4.3.1
The system shall integrate with the Active Directory to verify the username/user id and the
password
E 1
48. POS4.3.2
The system shall integrate with the local database to verify the username/user id and the
password in case of loss of connectivity with the Active Directory
E 1
49. POS4.3.3
The system shall enable multiple users and administrators use the same PoS counter using
his/her username and password
E 1
50. POS4.4
The system shall provide users with the flexibility to customize screen views (e.g. shortcuts
for the product/service in most demand)
D 1
51. POS4.5
The system shall enable users to create dashboards providing summary of all the recent
transactions related to mails, banking, insurance and retail post
E 1

52. POS4.6
The system shall provide the periodic (end of day/end of week/end of month) summary of
cash position at the counter against all the users using that PoS counter
E 1
53. POS4.7
The system shall interface with the "Sanchay Post" (in offices where Sanchay Post is used
for Banking related transactions) to receive the details of all the credit and debit
transactions done at the terminal by different users and reconcile the end of day cash
balance
E 1
54. POS4.8
The system shall interface with the "Treasurers F&A Module" and generate MIS reports
for all the credit and debit transactions done at the various Post office terminals by
different users and arrive at the end of day cash balance
E 1
55. POS4.9
The system shall provide the periodic (end of day/end of week/end of month) summary of
login time, logout time, number of transactions and value of transactions by each PoS
counter and each PoS user
E 1
Web Portal
Overall Scope
56. WEB1.1
The portal shall provide web browser support, cross browser compatibility, and channel
support like mobile platforms (all Mobile OS)
E 1
57. WEB1.2 The portal shall provide access to various types of users E 1
58. WEB1.2.1 The portal shall provide access to customers E 1
59.
WEB1.2.1.
1
The portal shall provide access to individual customers E 1
60.
WEB1.2.1.
2
The portal shall provide access to corporate customers E 1
61. WEB1.2.2 The portal shall provide access to merchandisers of retail products and services D 1

62. WEB1.2.3 The portal shall provide access to advertisers D 1
63. WEB1.2.4 The portal shall provide access to agents E 1
Information Management
64. WEB2.1
The portal shall provide information about DoP (such as history, management, mission,
organization, citizen charter, etc.)
E 1
65. WEB2.2 The portal shall provide information about various products and services E 1
66. WEB2.2.1
The portal shall integrate with the Mail Operations system to provide information about
E 1
67. WEB2.2.2
The portal shall integrate with the PBS to provide information about various banking
E 1
68. WEB2.2.3
The portal shall integrate with the PLI system to provide information about various
Insurance products and services
E 1
69. WEB2.2.4 The portal shall provide information about various Retail products and services E 1
70. WEB2.3 The portal shall manage the content and catalogue E 1
71. WEB2.3.1 The portal shall enable content acquisition and creation E 1
72. WEB2.3.2 The portal shall provide an online catalogue E 1
73. WEB2.3.3 The portal shall enable content maintenance E 1
74. WEB2.3.4
The portal shall support rich media content (such as flash video, audio, or video (mpeg,
mov, asf, etc.); rich content such as a robust user interface) to enable podcasting and web
casting
E 1
75. WEB2.3.5 The portal shall provide versioning and configuration management E 1

76. WEB2.3.6 The portal shall provide dynamic caching E 1
77. WEB2.4 The portal shall manage the product data E 1
78. WEB2.4.1 The portal shall provide product attribute management E 1
79. WEB2.4.2 The portal shall provide/leverage new or existing cross-sell rules D 1
80. WEB2.4.3 The portal shall provide/leverage new or existing up-sell rules D 1
81. WEB2.4.4
The portal shall provide product cross reference and replacement (e.g. offer a replacement
product in the event that the product under view is sold out)
D 1
82. WEB2.4.5 The portal shall provide product bundling D 1
83. WEB2.4.6 The portal shall enable users to customize/configure products D 1
84. WEB2.5 The portal shall provide advertisements of the merchandisers E 1
85. WEB2.6 The portal shall provide Value Added Services (VAS) E 1
86. WEB2.6.1 The portal shall enable users to locate nearest post office/letter box E 1
87. WEB2.6.2 The portal shall enable users to look up PIN code district wise E 1
88. WEB2.6.3 The portal shall enable users to subscribe for e-Newsletter, Direct Mailers, etc. E 1
89. WEB2.6.4 The portal shall provide the service of "Ask an expert service" D 1
90. WEB2.6.5 The portal shall provide Directory Services (e.g. Yellow Pages) E 1
91. WEB2.6.6 The portal shall provide Font Download E 1
92. WEB2.6.7 The portal shall provide Print Postage (refer MB1.6.8-MB1.6.9) D 1
93. WEB2.7 The portal shall provide multiple language translation support E 1
Transaction Management

94. WEB3.1 The portal shall manage the order capture E 1
95. WEB3.1.1
The portal shall enable users to browse, search and compare different products and
services
E 1
96. WEB3.1.2 The portal shall enable users to place the order for different services E 1
97.
WEB3.1.2.
1
The portal shall integrate with Mail Booking Engine system for all transactions related to
individual mail articles
E 1
98.
WEB3.1.2.
2
The portal shall integrate with MLASS for all transactions related to bulk mail articles E 1
99.
WEB3.1.2.
3
The portal shall integrate with PBS for all banking related transactions E 1
100.
WEB3.1.2.
4
The portal shall integrate with PLI system for all insurance related transactions E 1
101.
WEB3.1.2.
5
The portal shall enable users to shop Retail Post products E 1
102.
WEB3.1.2.
5.1
The portal shall integrate with Mail Booking Engine to record the Retail Post sale
transaction
E 1
103.
WEB3.1.2.
5.2
The portal shall enable users to place order for the DoP products (such as Stamps,
Postcards, Envelopes, Stationary, Philately, etc.)
E 1
104.
WEB3.1.2.
5.3
The portal shall enable users to place order for featured products (India, abroad and
warehouse)
E 1
105.
WEB3.1.2.
5.4
The portal shall enable users to place order from the merchandiser websites (India and
abroad)
D 1
106.
WEB3.1.2. The portal shall provide the list of merchandiser websites (including foreign posts for
D 1

5.4.1 stamps)
107.
WEB3.1.2.
5.4.2
The portal shall enable users to navigate to (and place order on) merchandiser website D 1
108.
WEB3.1.2.
5.4.3
The portal shall capture the details of the order placed on the merchandiser website D 1
109.
WEB3.1.2.
5.5
The portal shall provide global shopping cart E 1
110.
WEB3.1.2.
5.6
The portal shall enable users to specify the delivery details (such as address, time,
packaging requirements, etc.)
E 1
111.
WEB3.1.2.
5.7
The portal shall integrate with IPVS to enable users to create track and trace alerts E 1
112. WEB3.2 The portal shall provide order management capability E 1
113. WEB3.2.1 The portal shall provide home pick up, delivery and return of articles and orders D 1
114. WEB3.2.2 The portal shall provide Track & Trace of articles and orders E 1
115. WEB3.2.3 The portal shall provide order maintenance E 1
116. WEB3.2.4 The portal shall provide order cancellation E 1
117. WEB3.2.5 The portal shall provide Back-order and wait list D 1
118. WEB3.2.6 The portal shall provide order history E 1
119. WEB3.3 The portal shall provide order payment management capability E 1
120. WEB3.3.1 The portal shall perform the payment calculation E 1
121.
WEB3.3.1.
1
The portal shall calculate the cost of all the products purchased E 1

122.
WEB3.3.1.
2
The portal shall calculate the tax/duty to be levied E 1
123.
WEB3.3.1.
3
The portal shall calculate shipping and handling charges E 1
124. WEB3.3.2 The portal shall provide payment refund processing E 1
125. WEB3.3.3
The portal shall provide Fraud Management i.e. the capability to recognize fraud occurring
on the site through pattern analysis
E 1
126. WEB3.3.4
The portal shall integrate with the payment gateway to facilitate all 3
rd
party online
payments
E 1
127.
WEB3.3.4.
1
The portal shall enable users to make a direct debit from his/her bank account E 1
128.
WEB3.3.4.
1.1
The portal shall provide users a list of banks to choose from E 1
129.
WEB3.3.4.
1.2
The portal shall integrate with the portal of the chosen bank and navigate the users to
his/her bank account
E 1
130.
WEB3.3.4.
2
The portal shall enable users to make payment using his/her debit card E 1
131.
WEB3.3.4.
2.1
The portal shall provide users a list of debit cards to choose from E 1
132.
WEB3.3.4.
2.2
The portal shall integrate with the portal of the chosen debit card company/bank and
navigate the user to the website
E 1
133.
WEB3.3.4.
3
The portal shall enable users to make payment using his/her credit card E 1

134.
WEB3.3.4.
3.1
The portal shall provide users a list of credit cards to choose from E 1
135.
WEB3.3.4.
3.2
The portal shall integrate with the portal of the chosen credit card company/bank and
E 1
136.
WEB3.3.4.
4
The portal shall enable users to make payment using his/her cash card E 1
137.
WEB3.3.4.
4.1
The portal shall provide users a list of cash cards to choose from E 1
138.
WEB3.3.4.
4.2
The portal shall integrate with the portal of the chosen cash card company/bank and
E 1
139.
WEB3.3.4.
5
The portal shall enable users to make payment using 3
rd
party (e.g. Pay Pal) payment
method
E 1
140.
WEB3.3.4.
5.1
The portal shall provide users a list of 3
rd
party payment options to choose from E 1
141.
WEB3.3.4.
5.2
The portal shall integrate with the portal of the chosen 3
rd
party and navigate the user to
the website
E 1
142.
WEB3.3.4.
6
The portal shall provide Bill Me Later Payment method (e.g. cash on delivery, VPP) E 1
Marketing
143. WEB4.1
The portal shall support brand management to manage customer experience and brand
through products, content, and advertising
E 1
144. WEB4.2
The portal shall support campaign management to create and schedule
campaigns/promotions centred around specific products
D 1

145. WEB4.3
The portal shall support online marketing to integrate with sister sites to foster cross
selling amongst a suite of applications
D 1
146. WEB4.4
The portal shall support email marketing to conduct email campaigns to promote simple
purchasing such as 1-click ordering
D 1
147. WEB4.5
The portal shall support targeted marketing to target specific customer segments to
promote products that the segment is deemed to desire
D 1
148. WEB4.6
The portal shall support comparison shopping to enable users to compare specific products
to determine the best possible choice
E 1
149. WEB4.7
The portal shall support search engine optimization to enhance search results on search
engines such as Google primarily by adding appropriate keywords throughout the
application
D 1
150. WEB4.8
The portal shall support portal integration and placement to produce the content in a
portal user interface through external portals such as yahoo or MSN
D 1
151. WEB4.9
The portal shall support loyalty programs to promote programs such as discounts for
returning customers, customer buyback (e.g. buy 3 get 1 free).
D 1
152. WEB4.10 The portal shall support integration with 3
rd
party advertising agents (e.g. adsends) D 1
Account Management
153. WEB5.1 The portal shall provide account and profile management to all its users E 1
154. WEB5.1.1 The portal shall provide account and profile management to customers E 1
155.
WEB5.1.1.
1
The portal shall provide account and profile management to individual customer E 1
156.
WEB5.1.1.
2
The portal shall provide account and profile management to corporate customers E 1

157. WEB5.1.2
The portal shall provide account and profile management to merchandisers of retail
D 1
158. WEB5.1.3 The portal shall provide account and profile management to advertisers D 1
159. WEB5.2 The portal shall have the capability to manage the account and profile E 1
160. WEB5.2.1 The portal shall enable users to register their profiles online E 1
161.
WEB5.2.1.
1
The portal shall enable users to specify delivery/pick-up address E 1
162.
WEB5.2.1.
2
The portal shall enable users to update delivery/pick-up address (permanent and
temporary)
E 1
163. WEB5.2.2 The portal shall provide a calendar E 1
164. WEB5.2.3 The portal shall provide account & profile viewing and maintenance E 1
165.
WEB5.2.3.
1
The portal shall enable users to create viewing dashboards providing summary of all the
recent transactions related to mails, banking, insurance and retail post
E 1
166.
WEB5.2.3.
2
The portal shall enable users to view transaction history E 1
167.
WEB5.2.3.
2
The portal shall enable users to view bank account balance, payment amount outstanding,
payment due date, etc.
E 1
168. WEB5.2.4 The portal shall enable users to link various accounts E 1
169. WEB5.2.5 The portal shall enable users to create and manage alerts E 1
170.
WEB5.2.5.
1
The portal shall enable users to create and manage alerts for new products, services,
discount, schemes, etc.
E 1
171.
WEB5.2.5. The portal shall enable users to define frequency of the account statements (email/post,
E 1

2 monthly/quarterly)
Customer support
172. WEB6.1 The portal shall interface with the customer Call Centre for order support E 1
173. WEB6.2 The portal shall provide customer support E 1
174. WEB6.2.1 The portal shall support Customer Feedback/Surveys E 1
175. WEB6.2.2 The portal shall support Customer Complaints E 1
176. WEB6.2.3 The portal shall support Customer Requests E 1
177. WEB6.2.4
The portal shall integrate with the Customer Call Centre solution to generate the complaint
registration number to be provided to the customer
E 1
178. WEB6.3 The portal shall enable users to access the list of Frequently Asked Questions (FAQs) E 1
Site navigation
179. WEB7.1 The portal shall provide Interactive Site Navigation (e.g. flash based virtual post) E 1
180. WEB7.2 The portal shall provide Guided Navigation E 1
181. WEB7.3 The portal shall provide Site Search E 1
182. WEB7.4 The portal shall provide Site HELP E 1
183. WEB7.5 The portal shall provide Site Map E 1
Mobile Solution
CIM1 Solutions shall provide responses to enquiry through SMS
184. CIM1.1 Solution shall receive customer enquires through SMS at a number E 1
185. CIM1.2
Solution shall enable response to enquiries pertaining to the status of a consignment in the
E 1

DoP supply chain
186. CIM1.3
Solution shall interface with IPVS to check the status of consignment for the article details
given in the customer SMS
E 1
187. CIM1.4
Solution shall send an SMS alert to the customer providing information about the status of
the consignment
E 1
CIM2 Solution shall register customer complaints and track the status of complaint
188. CIM2.1 Solution shall receive customer complaints through SMS E 1
189. CIM2.2
Solution shall register the customer complaint and send an SMS alert to the customer
intimating the customer complaint number
E 1
190. CIM2.3
Solution shall track the status of customer complaint and send SMS to the customer
informing about the status of the complaint
E 1
CIM3
Solution shall generate SMS alert at various pre-defined stages in the supply chain of the
DoP

191. CIM3.1 Solution shall have the ability to generate SMS alert for attempted delivery E 1
192. CIM3.2 Solution shall have the ability to generate SMS alert for estimated time of delivery E 1
193. CIM3.3
Solution shall have the ability to send the SMS alert to contact number provided while
booking the consignment
E 1

7.2.4.7 Call Centre
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

CI.CS.1 Scope of the Solution
1. CI.CS.1.1 The solution shall support various customer interaction channels E 1
2. CI.CS.1.1.1 The solution shall provide Call Centre Integration support E 1
3. CI.CS.1.1.2 The solution shall provide Interactive Voice Response (IVR) support E 1
4. CI.CS.1.1.3
The solution shall enable customers to connect to the customer support centre from
anywhere in India (24 x 7 x 365 or as indicated) using India Post toll free telephone number
E 1
CI.CS.2 The solution shall provide relevant information
5. CI.CS.2.1
The solution shall provide general information about India Post (such as history,
management, mission, organization, citizen charter, etc)
E 1
6. CI.CS.2.1.1 The solution shall enable users to locate post office/box nearest to the customer E 1
7. CI.CS.2.1.2 The solution shall enable users to look up PIN code E 1
8. CI.CS.2.1.2
The solution shall enable users to better leverage and access information on the portal,
and information regarding the various services available through the multiple channels
E 1
CI.CS.2.2
The solution shall provide information about various Mail, Banking, and Insurance
products and services.

9. CI.CS.2.2.1
The solution shall integrate with the Mail Operations system to provide information about
E 1
10. CI.CS.2.2.2 The solution shall integrate with the PBS to provide information about various banking E 1

11. CI.CS.2.2.3
The solution shall integrate with the Postal Life Insurance (PLI) system to provide
information about various Insurance products and services
E 1
12. CI.CS.2.2.4
The solution shall integrate with Mail Operations system to provide information about
various retail products and services
E 1
CI.CS.3 The solution shall initiate and execute various types of transactions
13. CI.CS.3.1
The solution shall integrate with Mail Booking Engine system for all orders and requests
related to individual mail articles
E 1
14. CI.CS.3.2
The solution shall integrate with Mail Booking Engine system for all orders and requests
related to retail post service
E 1
15. CI.CS.3.3
The solution shall integrate with Mail & Logistics Appointment Scheduling system (MLASS)
for all orders and requests related to bulk mail articles
E 1
16. CI.CS.3.4 The solution shall integrate with PBS for all orders and requests related to banking E 1
17. CI.CS.3.5
The solution shall integrate with Postal Life Insurance (PLI) system for all orders and
requests related to insurance
E 1
18. CI.CS.3.6
The solution shall integrate with Agency Management system for all orders and requests
related to insurance
E 1
19. CI.CS.3.7
The solution shall integrate with the India Post Visibility System (IPVS) to track and trace all
the articles and products
E 1
20. CI.CS.4 The solution shall manage the customer complaints E 1
21. CI.CS.4.1 The solution shall enable the user to register the customer complaint and/or feedback E 1
22. CI.CS.4.2 The solution shall generate the customer complaint registration number E 1
23. CI.CS.4.3
The solution shall integrate with identified departments to send the mails for customer
complaint resolution
E 1
24. CI.CS.4.4 The solution shall track the status of the customer complaint E 1

25. CI.CS.4.5
The Call Centre shall integrate with the portal to receive the customer complaints and
provide information related to the status of the customer complaint.
E 1
CI.CS.5 The solution shall manage the accounts
26. CI.CS.5.1
The solution shall provide access to only India Post employees (i.e. administrators and
users) for accessing accounts
E 1
27. CI.CS.5.2
The solution shall allow only administrators to create/add new user and delete old users to
provide access to the Call Centre terminal
E 1
28. CI.CS.5.2.1
The solution shall allow administrators to define the user rights and the transactions which
shall be allowed to be performed at the CSC terminal
E 1
29. CI.CS.5.2.2
The solution shall integrate with the Active Directory to add the user profile as created by
the administrator
E 1
30. CI.CS.5.2.3
The solution shall provide access and authority to make changes to system configurations
only India Post employees (administrators, specified users, etc) using employee unique
user id and password
E 1
31. CI.CS.5.3
The solution shall allow users and administrators to access the terminal using the unique
username/user id and password
E 1
32. CI.CS.5.3.1
The solution shall integrate with the Active Directory to verify the username/user id and
the password
E 1
33. CI.CS.5.3.2
The solution shall integrate with the local database to verify the username/user id and the
password in case of loss of connectivity with the Active Directory
E 1
34. CI.CS.5.3.3
The solution shall enable multiple users and administrators use the same CSC terminal
using his/her username and password
E 1
Interactive Voice Response (IVR)
IVR 2 Call Centre & IVR Requirements
35. IVR 2.1 The IVR solution shall be available via the call centre number 24X7X365 E 1
36. IVR 2.2
The solution shall provide dual-tone multi-frequency (DTMF) signalling menu service for
users to retrieve information from the service.
E 1

37. IVR 2.3
The IVR services shall be rendered across the various states. The service shall be accessible
in the local language of the state as well as
English and Hindi.
E 1
38. IVR 2.4
The menu structure shall provide callers with touch tone shortcuts, that can be used in
sequence, which will allow the knowledgeable users to access information more quickly,
without having to drill down through the menu structure with every call.
E 1
39. IVR 2.5
The system shall have an on-line help service with:
Instructions for proper use of the service by caller
Menus
Content (information) available to the caller
E 1
40. IVR 2.6
The service shall respond to user errors with an offer to the users to restate or re-enter
their selection.
E 1
41. IVR 2.7
The service shall allow users the capability of replaying the message they have just heard,
restarting their session by returning to the main menu, or by accessing the help menu at
any point during the call.
E 1
42. IVR 2.8
The system shall have capability of presenting a broadcast message at the start of every
call, if it is required at any point during the stage of regular operations. This message shall
be separate and apart form any static message regarding service availability.
D 1
43. IVR 2.9
The information shall be provided to the callers after their identification based on the
required query. The system must have an authentication mechanism through PIN.
E 1
44. IVR 2.10 The solution shall be able to support multi-lingual requirements E 1
45. IVR 2.11
The information that a user may seek are:
Status of application based on transaction id.
Information on India Post services
E 1
46. IVR 2.12
Once the caller initial request has been satisfied, the caller will be prompted whether or
not they wish to request additional information.
E 1
Reporting Requirements

47. REP1.1 Calls per week, month or other period. E 1
48. REP1.2 Numeric and graphical representation of call volume E 1
49. REP1.3 Call per phone line or port E 1
50. REP1.4 Average length of calls E 1
51. REP1.5
Calls for each interaction tracked by type ( calls for information on specific service, calls for
specific enquiries)
E 1
52. REP1.6
Number of dropped calls after answering, including:
Calls that ended while on hold, indicating that the caller hung up
Call that ended due to entry errors using the automated system indicating difficulty in
using the system
E 1
53. REP1.7
The solution shall provide the periodic (end of day/end of week/end of month) summary of
login time, logout time, number of calls and action taken by each CSC terminal and each
CSC user
E 1

7.2.4.8 Common Infrastructure Solution
#
C
a
t
e
g
o
r
y

s
e
r
i
a
l

n
u
m
b
e
r
.

Description
E
s
s
e
n
t
i
a
l

/

D
e
s
i
r
e
d

M
a
x
i
m
u
m

s
c
o
r
e

C
o
m
p
l
i
a
n
t

(
Y
/
N
)

S
t
a
n
d
a
r
d

f
e
a
t
u
r
e

o
r

c
u
s
t
o
m
i
z
e
d

f
e
a
t
u
r
e

o
f

O
f
f

t
h
e

s
h
e
l
f

s
o
l
u
t
i
o
n

V
e
n
d
o
r

R
e
m
a
r
k
s

Enterprise Monitoring System (EMS)

Enterprise Management System: To provide comprehensive end-to-end availability and
performance management across key parts of the infrastructure and applications. It should


allow identifying trends in performance in order to avert possible service problems.
1. CI3.1
The solution shall integrate server, application and database performance information and
alarms in a single console and provide a unified reporting interface for complete
environment. The current performance state of the entire Data Centre environment shall
be visible in an integrated console.
E 1
2. CI3.2
The solution must scale to a large infrastructure while supporting a single web interface for
access to reports.
E 1

Virtualization Management System: The proposed solution must extend management
capabilities from the physical server environment to the virtual server environment. The
proposed solution must have capabilities to:

3. CI3.3 Monitor complex heterogeneous physical & virtual environment. E 1
4. CI3.4 Detect, diagnose & remediate root-cause & performance issues. E 1
5. CI3.5 Visibility into virtual machine (VM) location, configuration & response times. D 1
6. CI3.6 Discovery to inventory, baseline & identify virtual sprawl E 1
7. CI3.7 Tracking & Validating Configuration Changes of both host and guest virtual Machines. E 1
8. CI3.8 Virtual Machine Usage reporting & checking compliance to pass audits E 1
9. CI3.9 Managing resource pools across heterogeneous virtual environment. E 1
10. CI3.10
Standardize configuration, timely provisioning and appropriate retirement of Virtual
Machines
D 1
11. CI3.11
The solution should help in overcoming complexities associated with virtualization by
providing visibility into the virtualized Infrastructure, automating Data Centre processes,
pin point root cause & performance issues inside complex heterogeneous virtual
environments.
E 1

12. CI3.12
The solution must support an architecture that can be extended to support multiple
heterogeneous virtualization platforms, hypervisors and technologies
E 1
13. CI3.13
The system must be able to discover parent host server and map virtual machine
relationship to their parent host and build up graphical web based topology map
automatically for virtual machines & physical host
E 1
14. CI3.14
The system should understand parent-child relationship between parent virtual host &
guest VMs and deduce root-cause by automatically suppressing alarms from guest VMs in
case parent host goes down.
E 1
15. CI3.15
The solution must detect virtual server and virtual machine configuration changes and
automatically update topology.
E 1
16. CI3.16
Proposed solution should be able to track dynamic movement of virtual machines (for e.g.
vMotion) in virtual environment.
E 1
17. CI3.17
The system must support enhanced fault isolation to suppress alarms on logical VMs when
physical servers fail.
E 1
18. CI3.18
The solution must have the ability to collect data from the virtual systems without only
relying on SNMP.
D 1
19. CI3.19
The solution should provide comprehensive end-to-end performance reporting for virtual
environments.
E 1
20. CI3.20
The solution must support centralized management of virtual and physical environments
and provide a single central point of control for heterogeneous environments.
E 1
21. CI3.21
The system must provide dynamic optimization of virtual resources enabling IT
administrators proactively respond to changing business demands by using business policy
and performance data to allocate and reallocate systems resources in real-time.
D 1
22. CI3.22
The system must provide real-time and historical performance of physical and virtual
D 1

environments
Server Management System
23. CI3.23
The system shall provide the unified performance state view in a single console. The
current performance state of the entire server infrastructure shall be visible in an
integrated console.
E 1
24. CI3.24
The system must provide lightweight server agents to ensure availability and performance
for target server nodes and deliver scalable, real-time management of critical systems. It
should also be able to automate monitoring, data collection and analysis of performance
from single point.
E 1
25. CI3.25
Agent(s) on the managed node (server) should be used to monitor both the system metrics
and processes as well as monitor any application(s) running on that server.
D 1
26. CI3.26
The system should be able to monitor various operating system parameters such as
processors, memory, files, processes, file systems, etc. where applicable, using agents on
the servers to be monitored
E 1
27. CI3.27
It should be possible to configure the operating system monitoring agents to monitor
based on user-defined thresholds for minimum warning and critical states and escalate
events to event console of enterprise management system.
E 1
28. CI3.28
The proposed agents should support operating system monitoring for various platforms
including Windows, UNIX and Linux versions.
E 1
29. CI3.29
It should also be able to monitor various operating system parameters depending on the
operating system being monitored, yet offer a common interface for viewing the agents
and setting thresholds.
D 1
30. CI3.30
It should also provide the ability to set thresholds and send notifications when an event
occurs, enabling system administrators and DBAs to quickly trace and resolve
E 1

performance-related bottlenecks.

The proposed server monitoring agent must support monitoring the following
parameters but not limited to:

31. CI3.31
Processors: Each processor in the system should be monitored for CPU utilization. It should
compare Current utilization against user specified warning and critical thresholds.
E 1
32. CI3.32
File Systems: Each file system should be monitored for the amount of file system space
used, which should be compared to user-defined warning and critical thresholds.
E 1
33. CI3.33
Log Files: Logs should be monitored to detect faults in the operating system, the
communication subsystem, and in applications. System agents should also analyze log files
residing on the host for specified string patterns.
E 1
34. CI3.34
System Processes: System agents should provide real-time collection of data from all
system processes. Using this it should help identify whether or not an important process
has stopped unexpectedly. It should provide an ability to automatically restart Critical
processes.
E 1
35. CI3.35
Application Processes: The agent should be capable of monitoring critical application
processes for any application hosted on the server
E 1
36. CI3.36
Application log files: The agent should be capable of parsing the application log files to
identify error conditions and automatically take actions based on pre-defined policies
E 1
37. CI3.37
Application related metrics: The agent should be capable of collecting system resource
utilization by application or specific application process.
E 1
38. CI3.38
Memory: System agents should monitor memory utilization and available swap space and
should raise an alarm in event of threshold violation.
E 1
39. CI3.39
The system must send alerts for an array of server conditions, including inadequate free
space, runaway processes, high CPU utilization and inadequate swap space and should also
D 1

have capability to take automatic corrective actions
40. CI3.40
The solution must be able to gather information about resources over a period of time and
provide historical performance and usage information through graphical reports showing
overall performance trends. It should also include a platform-independent, browser-based
console to monitor performance from remote locations.
E 1
Database Management System
41. CI3.41
The solution should support monitoring of standard RDBMS such as Oracle, DB2 and MS-
SQL.
E 1
42. CI3.42
The solution should have out of box monitoring capabilities of various parameters of
standard RDBMS. The solution must include hundreds of predefined scans for monitoring
various database and operating system resources.
E 1
43. CI3.43 The solution should have capability of automatic corrective actions for standard RBMS D 1
44. CI3.44
The solution must have a console to enable users to monitor, analyze and take corrective
action from a centralized point. It should also seamlessly integrate with integrated service
management portal for single view
E 1
45. CI3.45
The solution must support real-time reporting and historical archive store for performance
information. DBAs should be able to drill down through layers of data to discover the cause
of a condition occurring with the databases, or operating system. These historical reports
must also be usable to perform trend analysis and capacity planning.
E 1
Management System for Web based Portals and Applications:
46. CI3.46
The solution must determine if the root cause of performance issues is inside the
monitored application, in connected back-end systems or at the network layer from a
single console view
E 1
47. CI3.47
The solution must proactively monitor real user transactions; detect failed transactions;
E 1

gather evidence necessary for triage and diagnosis of problems that affect user
experiences and prevent completion of critical business processes
48. CI3.48
The solution must provide deeper end-to-end transaction visibility by monitoring at a
transactional level.
E 1
49. CI3.49
The solution should measure the end users' experiences based on transactions with or
without the need to install agents on user desktops.
E 1
50. CI3.50
The solution should be deployable as a passive listener on the network thus inducing zero
overhead on the network and application layer.
D 1
51. CI3.51
The system must be able to provide root-cause probability graphs for performance
problems showing the most probable root-cause area within application infrastructure.
E 1
52. CI3.52
The solution must provide a single unified view that shows entire end-to-end real user
transaction and breaks down times spent within the application components, SQL
statements, backend systems and external 3rd party systems for quick trouble shooting.
E 1
53. CI3.53
The solution must be able to provide graphs and charts for performance problems
highlighting most probable root-cause areas within monitored application infrastructure.
D 1
54. CI3.54
The system must be able to provide the ability to create user groups based on application
criteria or location and link user ids to user names and user groups.
E 1
55. CI3.55
The system must provide the capability to mask critical / confidential data from the
monitored transactions.
D 1
56. CI3.56
The system must be able to track the HTTP or HTTPS sessions used by a particular user, so
one can see how many sessions there are, and, when a session is experiencing
performance or availability problems, assess the impact and address any issues for a
particular user.
E 1
57. CI3.57 The solution must support all common Java & .NET framework versions. D 1

58. CI3.58
The solution must provide a real-time application topology map to triage and quickly
pinpoint the component causing a performance bottleneck in the end-to-end transaction
flow.
E 1
59. CI3.59
The solution must gather available performance indicator metrics from all within real-time
production environments and real user transactions 24x7 with minimal overhead on
monitored applications without sampling.
E 1
60. CI3.60
The solution must be able to detect production Memory Leaks from mishandled Java
Collections and Sets and isolate exact component creating leaking Collection or Set (or
.NET Memory Leaks within the CLR).
E 1
61. CI3.61
The system must be able to detect user impacting defects and anomalies and reports them
in real-time:
Slow Response Time
Fast Response Time
Low throughput
Partial Response
Missing component within transaction
E 1
62. CI3.62 The solution must allow monitoring granularity for all transactions. D 1
63. CI3.63
The solution must provide real-time monitoring of resource utilization like JVM memory
usage, Servlets, EJB pools, DB connection pools and Threads.
D 1
64. CI3.64
The solution must be able to identify socket and file Input / Output activity from the
application.
E 1
65. CI3.65
As a means of detecting poorly performing SQL, the solution must be able to proactively
record all SQL calls, and report on the slow performing ones. The SQL measurements must
be made from within the monitored application not using an external database agent.
D 1

66. CI3.66
The solution must monitor performance of all stored procedures being executed from
within the Java/.NET application.
E 1
67. CI3.67
The system must be able to provide the ability to detect and alert when users experience
HTTP error codes such as 404 errors or errors coming from the web application.
E 1
68. CI3.68
The solution should have provision for automatic discovery of business critical transactions
by setting up bounding conditions to describe transactions.
E 1
69. CI3.69
The solution must provide ability to monitor performance of applications up to the method
level of execution (Java/.Net method) 24x7 in production environments with negligible
impact on monitored application.
E 1
70. CI3.70
The solution must be able to report on any application errors occurred while executing
application functionalities and pinpoint exact place of error within transaction call stack.
E 1
71. CI3.71
The solution must provide levels of thresholds which can be set on alerts and provide for
actions so that alerts can automatically trigger other processes when thresholds are
breached. The proposed solution must not necessitate any changes to application source
code.
E 1
72. CI3.72
The solution must proactively identify any thread usage problems within applications and
identify stalled (stuck) threads.
E 1
Integration with Service Management Portal
73. CI3.73
The Service Management System must integrate with the NMS (in addition to proposed
EMS) to collect network related information (alarms, assets, events etc.) into the central
system.
E 1
Integration with Service Desk
74. CI3.74
The Service Level Management System should provide the capability to calculate and
report on network specific SLAs.
E 1

75. CI3.75
The proposed system must completely and seamlessly integrate with the helpdesk
ticketing system. A single integrated helpdesk system with a unified Configuration
management database (CMDB) needs to be created. The helpdesk system must be able to
integrate with the proposed system / DB / application management tools via event
management engine so as to automatically generate trouble tickets in case of any critical
alerts.
E 1
76. CI3.76
The system should provide Asset Management tool which should provide multiple
integration methodologies to assimilate the data supplied from various management
sources. It should integrate with Helpdesk system so as to provide asset information while
opening the Ticket.
E 1
77. CI3.77
The NMS system proposed by NI must also be integrated with helpdesk system directly or
via event management layer to create automatic trouble tickets for any critical network
failures affecting the service delivery infrastructure.
E 1
78. CI3.78 The Service Level Management must be integrated with the helpdesk. E 1
79. CI3.79
The proposed management and helpdesk solution must work together to create an
integrated CMDB for better configuration management & change management process.
The proposed end-to-end solution must have a single central management dashboard for
viewing the critical business-centric KPIs in graph & chart formats
E 1
Service Desk
Service Management Portal
80. CI4.1
The solution must provide insight across the IT infrastructure based on a complete
integrated view of each IT service. The solution must provide the ability to model and
monitor business and IT services and represents the health of various business critical
services based on the supporting infrastructure.
E 1

81. CI4.2
The system must provide integration with proposed monitoring systems for physical and
virtual servers, databases and applications as well as with service management systems
like CMDB and helpdesk solution.
E 1
82. CI4.3
The solution must have out-of-the- box integration with network / system managers &
CMDBs and support integration with new data sources, including event normalization and
enrichment
E 1
83. CI4.4
The system must collect information from other proposed tools to give a better
understanding about how infrastructure and applications comprise specific IT services, and
how infrastructure is impacting the transactions associated with relevant applications
thereby impacting service quality.
E 1
84. CI4.5
The solution should support role-based service dashboards and service consoles for
management, staff, operations and stakeholders along with historical reports.
E 1
85. CI4.6
The system must provide a simple and easy-to-use methodology to build logical service
models to relate all IT components of a service (systems, databases, applications and
transaction). The solution must also enable the definition and creation of end-to-end, real-
time business service models quickly and efficiently without programming knowledge.
E 1
86. CI4.7
The solution must have the ability to understand how the infrastructure impacts critical
services, and quickly identify root cause for any services outage or performance
degradation.
E 1
87. CI4.8
The solution must provide service visualization capabilities including service management
dashboard and topology based views for displaying service relationships.
E 1

The solution must provide role-based user access to provide proper service information
to the correct people in ensuring the data is analyzed properly. The solution must be
configured to provide the following :

88. CI4.10
Dashboard views for business and IT owners to understand how the services are
E 1

performing as a whole.
89. CI4.11
Service topologies for high level IT staff to understand how different service and
infrastructure components relate to each other.
E 1
90. CI4.12
Capabilities for reporting on services levels, service availability, performance and health
are required
E 1
91. CI4.13
The solution must provide real-time proactive visibility into how well critical business
services are delivered to end-users based on integrated analysis of user experience,
application transactions and the underlying infrastructure.
E 1
92. CI4.14
This solution must display the quality, risk, SLA compliance and other important
parameters of critical business services, enabling quick resolution of problems impacting
service quality.
E 1
93. CI4.15
The solution must integrate and analyze data from other management tools proposed
including application performance management tools for metrics on real-time and
simulated user experience & business transaction behaviour and infrastructure
management tools.
E 1
94. CI4.16
The solution must provide a layer of intelligence to be able to integrate, normalize and
reconcile information from heterogeneous tools through a common integration platform
based on a real-time integrated service management model and operational management
database (CMDB).
E 1
95. CI4.17
The solution must create a single central instance of the discovered IT environment for
accurate business service modelling and impact analysis as well as provide a common view
of all critical business service status information to the stakeholders across the
organization and in a format suitable for their roles.
D 1

Service Level Management System: The solution must include a comprehensive and
integrated service delivery management to carry out SLA Management, Reporting &


Monitoring. The proposed system must enable building of reusable elements for defining
standard service offerings and for use in building SLAs in the system. The framework must
provide industry standard definitions for:
96. CI4.18 Services - what organization offers (IT systems, Apps, Business Processes) E 1
97. CI4.19 Service Metrics - define the way the service is measured, based on ITIL v3 standards E 1
98. CI4.20
E.g. Availability-% Time Available, Performance-Latency, Performance-% Packet Delivery,
Incident Mgt-Avg. Response Time, etc
E 1
99. CI4.21 Specific service level metrics Ability to define specific key performance indicators D 1
100. CI4.22
The Service Level Management system should have out-of-the-box integration with other
processes like Request Management, Incident Management, Problem Management and
Change Management.
E 1
101. CI4.23
The system is expected to provide the ability to define a catalogue of specific key
performance indicators or service level metrics, defining exactly what each metric means -
both the definition and attributes within the systems framework as well as the business
logic to calculate.
E 1
102. CI4.24
The system must support and contain best practice libraries of industry standard
services/metrics aligned with ITIL v3 standards and allow using these as a starting point.
E 1
103. CI4.25
The system must support groupings of predefined KPIs for a service or group of services as
templates.
D 1
104. CI4.26
The system must provide the ability to configure and manage a list of templates
preconfigured with best practice Service Level Objectives.
E 1
105. CI4.27
The system must facilitate a new contract/SLA to be quickly deployed based upon
one/several of these templates and the attributes for the specific metrics changed as
necessary (for example, target, time threshold, Incident severity level) without requiring
E 1

any specific programming skills.
106. CI4.28
The SLA management system must provide the ability to group Services in many ways for
reporting purposes.
E 1
107. CI4.29
Solution shall provide an easy-to-use GUI to create a library of weekly and yearly calendars:
Business hours, Peak hours, maintenance windows, holidays, etc.
E 1
108. CI4.30 The system must support service life-cycle with status, version and audit trail control. E 1
109. CI4.31
The system must enable defining a set of mandatory items as part of any contract creation
process automatically in order to enforce validation and drive standardization.
D 1
110. CI4.32
The solution should provide capability to define a catalogue of reusable
calculation/business logic engines on how to calculate the various Service Level metrics
that can be used. Business logic has to be reusable (define once, use multiple times) and
changing the business logic / calculations should allow the changes to propagate to any
Service Level Obligation (SLO) / Service Level Agreement (SLA) that uses it.
E 1
111. CI4.33
Solution should be able to provide a common repository for all agreements across
organization, whether they are SLAs, internal SLAs/ Operational Level Agreements (OLAs),
or vendor underpinning contracts.
E 1
112. CI4.34
Solution shall manage the SLA state in the life cycle (e.g. draft, current, etc.) and be able to
support start / end dates (i.e. the SLA start date and end dates) as well as periodical
revisions to the SLA (i.e. new targets, new metrics). Furthermore the system shall track all
changes made and allow users to go back to a previous version of a SLA.
E 1
113. CI4.35
Authorized users shall be able to customize each element of an SLA, setting different
targets, thresholds/escalation scheme, time period coverage, penalties, etc
E 1
114. CI4.36
Solution shall offer easy interfaces to handle the calculating of dependent service level
indicators. End to End Transaction data and operational availability measurements must
be used to calculate the End-to-End Service Delivery indicator. Solution should be able to
E 1

link metrics dependent or related to one another
115. CI4.37
Solution shall be able to manage different kinds of process oriented Service Level
Objectives.
E 1
116. CI4.38
Solution shall be able to manage specific quality analysis metrics such as, Latency, Packet
Drop Ratio, etc.
D 1
117. CI4.39
The system must enable manage and report on Metrics including, but not limited to:
By Service/ Product/ Process
Areas of measurement (e.g. Availability, Performance, Incident Management)
Geographic Location
D 1
118. CI4.40
Solution shall be able to support the easy creation & management of multiple SLAs and be
able to view and report on them from individual SLA perspective, as well as performance
rolled up for the overall organization.
E 1
119. CI4.41
Solution should support specifying different measurement targets for different time
periods (for example, higher availability is required during peak hours)
E 1
120. CI4.42
Solution should provide the capability to link addresses from within the Contract or Service
catalogue a link to external or internal sources (documents, files, web pages etc.).
E 1
121. CI4.43
Solution should be able to support scheduled and un-scheduled maintenance windows for
an SLA and consider those when reporting performance and calculating service
credit/debit
E 1
122. CI4.44 Solution should provide the Ability to Create Multiple levels of Threshold settings D 1
123. CI4.45
Solution shall provide the ability to easily create & deliver warning notifications and alerts,
built around multiple levels of thresholds and the SLA target for each SLO/SLI, i.e. upon
occurrence of a SLA / SLO threshold exception, an action shall be triggered (notification,
highlight etc.)
E 1

124. CI4.46
The solution should have the ability of system to automatically generate results of
penalties / bonuses on specified basis.
D 1
125. CI4.47
From the SLA & agreed upon metrics stored in the SLA Management module, an
authorized user should be able to generate a printable version of the SLA in a standard
format, like MS Word. Contents of the printable version should be configurable. Support
for several export templates should be available.
E 1
126. CI4.48
Solution should provide the ability to add exceptions (like excluded time periods) to
contracts both before committing SLA and while effective. For example, after SLA is in
effect an Exceptional downtime occurs and it is agreed upon/negotiated with the bidder.
An exception to the specified tracking period must be allowed to be added (preferably
through a simple GUI) that will cause the system to exclude a particular set of data/events
that occurred during that time period. The system must automatically take this into
account when doing the service level reporting, without a user is having to manually re-do
metric formulas/calculations.
E 1
127. CI4.49
The proposed solution must also provide an audit trail to be maintained in the system on
who has added & when that exception was added.
E 1
Solution shall provide the means to perform searches for:
128. CI4.50
SLA contracts according to all SLA parameters: e.g. Supplier, customer, service, revenues,
geography;
E 1
129. CI4.51
SLA failures (or conformances) according to all SLA parameters: e.g. Supplier, customer,
service, revenues, geography
E 1
130. CI4.52
Authorized users should able to create ad-hoc reports without the need for specialized
knowledge. The system shall also provide the ability for users to create personal reports
that only they have access to, as well as reports that are shared (accessible by multiple
users).
E 1

131. CI4.53
The solution should be able to automatically produce scheduled pre-defined SLA
performance reports and distribute them, when required through email. The solution
should also be capable of exporting reports and/or the underlying data, to the following
formats such as, MS Excel, PDF, HTML, CSV
E 1
132. CI4.54
The system shall provide the ability to point and click on any graphically represented
service level value in a chart and drill down to the next level of information making up that
result.
E 1
133. CI4.55
A performance dashboard integrated with the SLA Management module shall be available
within the SLM tool, by utilizing icons and colour coding for quick identification for
warnings, severity levels.
E 1
134. CI4.56
The system must enable an end-to-end graphical overview based on the contract definition
for immediate understanding of Contract and Service relations (relationship of
Underpinning Contracts, OLA and SLAs). The graphical overview must also provide and
display Contracts, Services, Obligations and technical items with the appropriate
relationships and dependencies in order to quickly understand complex contracts and
service relations within the service delivery chain.
E 1
135. CI4.57
The dashboard should support a view showing all the Services, their status as related to all
the SLA commitments and what contract parties are being impacted by below-level
performance.
E 1
136. CI4.58
An Incident or Trouble-ticket, related to a specific Configuration Item, which is created
manually or automatically by integration of the monitoring systems with the helpdesk,
should be automatically associated with the related Service Level Agreement.
D 1
137. CI4.59
The Service desk, which includes the SLA management system and CMDB, should be
capable of integration with third party monitoring tools.
E 1
138. CI4.60
Collection of data must be close to real time for metrics such as availability & response
E 1

time and collected in batch mode for operational data such as from Help Desk.
139. CI4.61
Solution shall be able to manage the following types of SLAs: Helpdesk, Data, Applications,
Web services, Voice, Wireless, LAN, WAN, Security, Storage, Systems/servers
E 1
Helpdesk and Ticketing System (including CMDB and Asset Management)
140. CI4.62 The system must be ITIL-v3 based and provide support for various defined ITIL processes E 1
141. CI4.63
The solution must provide flexibility of logging, viewing, updating and closing incident
manually via web interface.
E 1
142. CI4.64 The web interface console would also offer access to knowledge database. E 1
143. CI4.65
The solution must provide classification to differentiate the incident via multiple
levels/tiers of categorization, priority levels, severity levels and impact levels.
E 1
144. CI4.66
The solution must be able to provide flexibility of incident assignment based on the best
practices as defined in ITILv3.
D 1
145. CI4.67
Each escalation policy must allow easy definition on multiple escalation levels and
notification to different personnel.
E 1
146. CI4.68
The escalation policy would allow flexibility of associating with different criteria like
device/asset/system, category of incident, priority level, organization and contact.
E 1
147. CI4.69
The solution must provide web-based knowledge database to store useful history incident
resolution.
E 1
148. CI4.70
The knowledge management system must be compliant with KCS (Knowledge Centred
Support) which define best practices for knowledge management.
D 1
149. CI4.71
The knowledge management system must have a natural language search engine that is
capable of automatically relating the appropriate knowledge article with the Incident /
Problem description.
D 1

150. CI4.72
The solution must contain built-in knowledge tools system that can provide grouping
access on different security knowledge articles for different group of users.
E 1
151. CI4.73
The solution must provide seamless integration to log incident/problem automatically
through integration with other proposed tools such as EMS event management, server
management, database management, network management system
E 1
152. CI4.74 The solution must be able to log and escalate user interactions and requests. E 1
153. CI4.75
The solution must provide status of registered calls to end-users over email and through
web.
E 1
154. CI4.76
The solution must have an updateable knowledge base for technical analysis and further
help end-users to search solutions for previously solved issues.
E 1
155. CI4.77
The knowledge management system should be capable of automatically rating the
knowledge articles based on usage and also automatically deleting knowledge articles that
have not been used for a specified period of time based on policy.
D 1
156. CI4.78
The solution must have the ability to track work history of calls to facilitate
troubleshooting.
E 1
157. CI4.79
The solution must support tracking of SLA (service level agreements) for call requests
within the help desk through service types.
E 1
158. CI4.80
The solution must support request management, problem management, configuration
management and change requests management.
E 1
159. CI4.81
The solution must be capable of assigning call requests to technical staff manually as well
as automatically based on predefined rules, and should support notification and escalation
over email, web etc.
E 1
160. CI4.82
The solution must have an integrated CMDB for better configuration management &
change management process. The solution must have a top management dashboard for
E 1

viewing the helpdesk KPI in graph & chart formats.
161. CI4.83
The solution must support remote management for end-user & allow analysts to do the
desktop sharing for any system located anywhere, just connected to internet.
E 1
162. CI4.84
The Change Management system should have out-of-the-box integration with Incident
Management, Problem Management and Service Level Management.
E 1
163. CI4.85
It should be possible to define sequential as well as parallel tasks in the Change
Management workflows.
D 1
164. CI4.86 The system should provide a graphical view of the different workflows. D 1
165. CI4.87
The proposed asset management solution should provide the features specified below:
a. Asset tracking Vendor details
b. Maintenance and repair information
c. Purchasing and contracts information (purchases, leases, warranties and so on)
System location, and user or owner contact information.
E 1
166. CI4.88
The asset management for IT solution should include mature work management processes
and support for proactive work activities. It should provide built-in report designers and
viewers, as well as role-based dashboards, that can help to view information that can be
acted on in ways that are meaningful to IT and business staff.
E 1
167. CI4.89
The asset management solution must support automated asset life-cycle management. It
must provide management of assets from requisitioning, through delivery, installation and
configuration, servicing and maintenance over the life of the asset, to finally
decommissioning and returning or disposing of the asset.
E 1
168. CI4.90
Asset management solution should combine maintenance, procurement and contract
management for IT assets into one easy-to-use Web interface.
D 1
169. CI4.91
Asset management solution should provide means to automatically track and efficiently
E 1

manage the complete life cycle of assets. This asset lifecycle functionality should permit
the tracking and management of IT assets through initial request, approval, procurement,
contract, receipt, deployment, asset installs, moves, adds, changes (IMACs), and
retirement.
170. CI4.92
Asset management solution should control procurement and maintenance agreement
costs. It should provide thorough and accurate asset tracking that helps in making key
business decisions effectively, redeploy assets where needed and avoid over-provisioning.
E 1
171. CI4.93
Asset management solution should follow standards-based approach and should provide
the capability to integrate with key financial and HR systems, as well as automated asset
discovery applications.
E 1
172. CI4.94
Proposed solution should facilitate IT operations staff to use asset management to
proactively plan IT needs. The software should help plan, review and report on work,
resources and costs associated with implementing IT infrastructure changes. Plus, it should
notify support staff about changes and schedule rollouts.
E 1
173. CI4.95
Asset management solution should provide capability to manage IT spare parts inventory
which is an important part of maintaining any asset. The Inventory module should tracks
materials needed for maintenance. It should keep track of items in stock, indicates when
stock falls below user-defined reorder points, creates purchase requisitions and purchase
orders to restock needed items, and reports items received.
E 1
174. CI4.96
Asset management solution should provide capabilities to manage preventive
maintenance (PM) work that needs to be done on regular schedule in order to keep assets
running efficiently. The applications in the Preventive Maintenance module should help to
plan and budget for regular maintenance work by planning the labor, material, service, and
tool needs of your regularly scheduled maintenance and inspection work orders.
E 1
175. CI4.97
Asset management solution should provide software license management so as to track
your software license entitlements and compare those entitlements to deployed
E 1

inventory.
176. CI4.98
Asset management solution should provide the facility of reconciliation to match deployed
hardware and software data to procurement and asset or materials management data. It
should also facilitate in establishing the basis for reconciliation.
E 1
Email Solution
Mail & Messaging solution should have the following features
177. CI1.1 Should provide support for LDAP V3 Directory access E 1
178. CI1.2 The mail messaging software must have integration with proposed Directory solution E 1
179. CI1.3 Should provide support for digital signatures. D 1
180. CI1.4
Should provide support for simple, flexible administration using a Web browser or any
other management console.
E 1
181. CI1.5 Should support tools for message tracking and monitoring management. E 1
182. CI1.6 Should support for clustering and automatic fail over and load balancing services. E 1
183. CI1.7 Should provide support for POP, IMAP4, SMTP and Web based Access. E 1
184. CI1.8 It should support SSL encryption with 128/ 168 bit keys. E 1
185. CI1.9 Should provide for Simplified Server Monitoring. D 1
186. CI1.10
Should provide easy creation of new database usage, activity, replication, and ACL
monitors.
E 1
187. CI1.11 X.509 V3 support - that provides a standard for all digital certificates. E 1
188. CI1.12 Periodic or per-message notification when the quota is exceeded. E 1
189. CI1.13 Support for automation of administration tasks through GUI or scripting D 1

190. CI1.14
Should be capable of implementing Private Blacklist, Private White lists and DNS White
lists.
E 1
191. CI1.15 Should support S-MIME browser access of email. E 1
192. CI1.16 Should be capable of providing policy based administration controls. E 1
193. CI1.17 Should provide for horizontal and vertical scalability. D 1
194. CI1.18 Should provide reporting features to monitor Statistics and Events on the servers. E 1
195. CI1.19 Should be complied to enforce government compliance & regulation requirements. E 1
196. CI1.20 Should be able to provide archiving & message indexing/ journaling capabilities. E 1
197. CI1.21
Should be able to provide customizable message classification depending on type of
messages.
E 1
198. CI1.22
Should be able to provide end to end encryption with a minimum of 128 bit key
encryption.
E 1
199. CI1.23
Should have capability to enforce email retention settings on users so emails can be
retained/archived/deleted as per state policies.
E 1
200. CI1.24 Should support feature for Sent messages to be recalled by the sender. E 1
201. CI1.25
Should support TLS encryption between different messaging server roles to help ensure
that all the messaging data transferred between messaging servers is encrypted.
E 1
202. CI1.26
Should support browser based email access with features including schedulable separate
out-of-office messages for internal and external users, S/MIME support, Really Simple
Syndication (RSS) subscriptions, and Managed E-Mail Folder access etc.
E 1
203. CI1.27
Should have capability to provide visual guidance on the best dates and times for meeting,
based on the schedules of invitees and resources.
E 1

204. CI1.28
Should support Multi-Mailbox Search Administrators should be able to perform fast, full-
text search across all mailboxes if required for legal or other purposes.
E 1
205. CI1.29 Unified Messaging Support: E 1
206. CI1.29.1 Messaging System should support following Unified Communication capabilities. E 1
207. CI1.29.2 IVR Capabilities to access email, voice mails, calendar and contacts by ordinary phone. D 1
208. CI1.29.3 Emails, Voice Mails and Fax redirected to Inbox. E 1
209. CI1.29.4 Speech Enabled Auto-attendant. D 1
210. CI1.29.5 Should support integration with IP or non-IP PBXs. D 1
211. CI1.29.6 Notification when a caller leaves a voice message D 1
212. CI1.29.7 Secure Real-time transport protocol should be supported E 1
213. CI1.29.9 Quality of service (QoS) should be supported by using differentiated service E 1
214. CI1.30 Should provide core anti-spam capability out-of-box E 1
215. CI1.31
Should support integrated Mobile Messaging without any third party plug-ins of software
with following features:
E 1
216. CI1.31.1
Should provide with Up-to-date notifications synchronization with Pocket PC , Nokia &
Symbian & based smart phones (Push Based Mobile Messaging) with no third party
middleware services
E 1
217. CI1.31.2
Should provide integrated Support for HTML Messages - Rich HTML mail for mobile devices
is supported. Replying to an e-mail should preserve the HTML formatting for all other
users in the thread
E 1
218. CI1.31.3 Should support enforcement of security policies on Mobile devices. E 1
219. CI1.31.4 Should support remote wipe out of Mobile Devices by central administrator E 1

220. CI1.31.5 Should Support remote wipe on Mobile Devices. D 1
221. CI1.32
The solution should provide in built journaling, which can be enabled internally or
externally or user based. Journal messages could be archived with-in server or taken off to
another system
E 1
222. CI1.33
Should provide MRM (Message Record Lifecycle Management) for email retention and
expiration using organization policy.
E 1
Instant Messaging (IM) solution should have the following features but not limited to:
223. CI1.34
The ability for authorized users to send and receive instant messages (IM) to other
authorized users.
E 1
224. CI1.35
Should support the industry-standard protocols Session Initiation Protocol (SIP) and SIP for
Instant Messaging and Presence Leveraging Extensions (SIMPLE)
E 1
225. CI1.36
Messages can be sent to a single individual user or to a group of users. Groups of users can
be created dynamically by adding users to an existing IM session, or can be defined in
advance as a list or group. Use of existing group definitions, such as in directory service
E 1
226. CI1.37 Should support integration with centralized directory services E 1
227. CI1.38
Ability for logging and archiving of the communications in all IM sessions for records
management or regulatory compliance. Logging of IM sessions for only specific pre-
identified users.
E 1
228. CI1.39
Ability for visual and audible alerts to the intended recipient upon arrival of an IM
message. Mode(s) of alerts under user control.
D 1
229. CI1.40
Should provide Instant Messaging & Presence capabilities through a browser based
interface
E 1
230. CI1.41 Support for instant messaging and presence capability from mobile device E 1
231. CI1.42
Solution should have capability to protect against unsolicited instant messages (SPIM
filters)
D 1
232. CI1.43 Should support seamless access to remote users without the need for Virtual Private E 1

Networking (VPN)
233. CI1.44 Should support the Users to send and receive files from within IM conversations D 1
234. CI1.45 Should support the Users to use a Tablet PC. D 1
Directory Services
235. CI2.1 Centralized authentication and authorization mechanisms for users E 1
236. CI2.2
Directory Services solution for all DoP Departmental/Post/Mail offices and other third
part resources for user authentication and access rights
E 1
237. CI2.3 Should support high-availability E 1
238. CI2.4 Should be LDAP v3 Compliant E 1
239. CI2.5 Support for open standards e.g. XML E 1
240. CI2.6 Should be able to replicate data between servers and support cascading replication E 1
241. CI2.7 Support for Group policies and software restriction policies E 1
242. CI2.8
Support settings to configure various desktop or user related settings via centralized
control like Browser setting, desktop restrictions, program restrictions, admin controls,
software deployment etc.
E 1
243. CI2.9 Feasibility for all manual functions to be automated using group policies. D 1
244. CI2.10
Support for integrated authentication mechanism across operating system, messaging
services.
E 1
245. CI2.11 Out of the box integration with the mail and messaging solution D 1
246. CI2.12
Enhanced authentication mechanism which supports authentication across multiple
Operating systems like Windows and Unix/Linux.
E 1
247. CI2.13
Ability to integrate with other Standards based Directory system for synchronizing user
accounts and passwords.
E 1

248. CI2.14 Support for Access Control Lists (ACLs). E 1
249. CI2.15
Should have capability of implementing restrictions over accessing the directory data at
different levels
E 1
250. CI2.16
Should support multi factor authentication; Support for user authentication through user
ID/password, X.509v3 public-key certificates, or Anonymous authentication
E 1
251. CI2.17
Support security features for smart cards, public key infrastructure (PKI), and x.509
certificates
E 1
252. CI2.18
Should have simple and flexible administration using GUI or web browser to perform
administration tasks
E 1
253. CI2.19 Provision of APIs to programmatically manage each component of Directory Service. D 1
254. CI2.20 Support for modifiable and extensible schema both manually and programmatically E 1

7.2.5 TECH 5: Product and Solution Integration
Refer section 5.2.1.3 for the information to be provided with relevant documentary evidence along
with relevant references.
7.2.6 TECH 6: Technical Solution, Approach & Methodology
Refer section 5.2.1.2 for the information to be provided.
7.2.7 TECH 7: Schedule of Requirements for Hardware Infrastructure and Software
7.2.7.1 Hardware Infrastructure
# Component
Usage of
Proposed
Hardware
Hardware
vendor
name,
Model and
OS
No. of units Remarks
1 Servers

1.1 Core Application Server

1.1.1 DC (Wave 1) To be filled To be filled To be filled To be filled
1.1.2 DC (Wave 2&3) To be filled To be filled To be filled To be filled
1.1.3 DRC (Wave 1) To be filled To be filled To be filled To be filled
1.1.4 DRC (Wave 2&3) To be filled To be filled To be filled To be filled
1.2 Database Server
1.3 Development & Testing Server
1.4
Miscellaneous Servers (Web,
Management, email, Security
etc.)
To be filled To be filled To be filled To be filled
2 Storage

2.1 Storage Array To be filled To be filled To be filled To be filled
2.2 SAN Switches To be filled To be filled To be filled To be filled
2.3 FC IP Routers To be filled To be filled To be filled To be filled
2.4 Miscellaneous To be filled To be filled To be filled To be filled
3 Tape Library To be filled To be filled To be filled To be filled

Notes:
I. Bidders shall specify all required servers that are proposed in order to meet the requirements as
stated in the RFP
7.2.7.2 Software
# Component
Usage of
Proposed
Software
Software
vendor
name and
version
No. of units Remarks
1
Common Infrastructure
Solution

1.1 EMS To be filled To be filled To be filled To be filled
1.2 ESB To be filled To be filled To be filled To be filled
1.3 Email To be filled To be filled To be filled To be filled
1.3 Directory To be filled To be filled To be filled To be filled
1.5 Service Desk To be filled To be filled To be filled To be filled
2 Mail Operations

2.1 Mail Booking Engine To be filled To be filled To be filled To be filled
2.2 India Post Visibility System To be filled To be filled To be filled To be filled
2.3
Delivery & Postman
Management System
2.4
Mailer & Logistics
Appointment Scheduling
System
2.5 Labour Scheduling System To be filled To be filled To be filled To be filled
2.6 Sort Program System To be filled To be filled To be filled To be filled
2.7 Client application for RICT To be filled To be filled To be filled To be filled
3 Logistics Post

3.1
Warehouse Management
System
3.2
Transportation Management
System
4 Finance & Accounts
4.1
Finance & Accounts
application
4.2
Procurement & Inventory
application
4.3 RICT Client application To be filled To be filled To be filled To be filled
5 Human Resources
5.1
Human Resources
applications
5.2 ESS user application To be filled To be filled To be filled To be filled
5.3 MSS user application To be filled To be filled To be filled To be filled
6
Customer Interaction
Management

6.1 Point of Sale To be filled To be filled To be filled To be filled
6.2 Web-Portal To be filled To be filled To be filled To be filled
6.3 Mobile channel To be filled To be filled To be filled To be filled
7
Customer Information
Management
8
Database software for DC
server application
9
Database software for DRC
server application
10 Miscellaneous applications To be filled To be filled To be filled To be filled

Notes:
I. Bidders shall specify any additional software that are required in order to meet the requirements
as stated in the RFP
II. Bidder shall consider only Enterprise wide License prices for all software that it is providing


7.2.8 TECH 8: Team Composition and Task Assignments
#
Name of the
Resource
Position
Assigned
Area of
Expertise
Duration
Task
Assigned
Own
Employee /
Subcontractor
I. To be filled To be filled To be filled To be filled To be filled To be filled
II. To be filled To be filled To be filled To be filled To be filled To be filled
III. To be filled To be filled To be filled To be filled To be filled To be filled
IV. To be filled To be filled To be filled To be filled To be filled To be filled
V. To be filled To be filled To be filled To be filled To be filled To be filled


7.2.9 TECH 9: CV of Proposed Resources
I. CVs of Profiles indicated in Section 7.1: Profiles to be evaluated for the Assignment

# Item Details
1.
Name of Staff
[Only one candidate shall be nominated for each
position]

2. Current Job Title
3. Name of Company
4. Position Assigned in Project
5. Education Details
i. Name of Institution From To Degree Obtained
ii.
iii.
iv.
6. Certifications and Trainings attended
7. Total No. of years of experience
8.
Details of Experience
Name of Organisation From To Designation/ Responsibilities
i.
ii.
iii.
iv.
9.
Detailed Tasks Assigned on the Project
[List all tasks to be performed under this
assignment]

10.
Relevant Work Undertaken that Best Illustrates the experience as required for the Role
(provide maximum of 5 citations of 10 lines each)
i.
Name of Assignment or Project
Year
Location
Employer
Main project features
Positions held
Value of Project
[Approximate value or range value]

Activities performed
ii.
Name of Assignment or Project
Year
Location
Employer
Main project features

# Item Details
Positions held
Value of Project
[Approximate value or range value]

Activities performed
7.2.10 TECH 10: Staffing Schedule
Staffing schedule for the proposed resources need to be provided

7.2.11 TECH 11: Work Schedule

# Activity
1

Months
2

1 2 3 4 5 6 7 8 9 10 11 12 n
1
2
3
4
5

N

Notes:
I. Indicate all main activities of the assignment. For phased assignments indicate activities, delivery of reports, and benchmarks separately for each phase.
II. Duration of activities shall be indicated in the form of a bar chart.

7.2.12 TECH 12: Suggestions on Draft Terms of Contract

# Reference (Clause No. & Pg. No) Deviation in the Proposal Brief Reasons

* We accept that modifications/ changes suggested in this annexure may or may not be considered
in the final contract nor is this process construed as any commitment from Department of Posts to
consider the suggestions. The financial and technical bid submitted by us is not dependent upon the
acceptance of the changes suggested.

Notes:
I. Bidder shall list all clauses of the Draft Terms of Contract to which compliance is either partial or
conditional or non-complaint with details and reasons thereof

II. Department of Posts reserves the right to reject the bid in the event of partial compliance or
conditional compliance or non-compliance to any of the terms stipulated in the Draft Terms of
Contract of the RFP


7.2.13 TECH 13: Declaration on Absence of Conflict of Interest

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Subject: Undertaking on Conflict of Interest regarding Selection of Core System Integrator

Dear Sir,

I/We do hereby undertake that there is absence of, actual or potential conflict of interest on the part
of the bidder or any prospective subcontractor due to prior, current, or proposed contracts,
engagements, or affiliations with Department of Posts.

I/We also confirm that there are no potential elements (time frame for service delivery, resource,
financial or other) that would adversely impact the ability of the bidder to complete the
requirements as given in the RFP.

We undertake and agree to indemnify and hold Department of Posts harmless against all claims,
losses, damages, costs, expenses, proceeding fees of legal advisors (on a reimbursement basis) and
fees of other professionals incurred (in the case of legal fees and fees of professionals, reasonably)
by Department of Posts and/or its representatives, if any such conflict arises later.

Dated this ___ day of ___201_

Yours sincerely,

Name of Firm:
Address:


7.2.14 TECH 14: Schedule of Subcontractors

Please list the Sub-contractors proposed to be used for the project. The Bidder must not sub-
contract more than 20% of the services component of this project

Sl. No.
Name and
Address of Sub-
Contractor
Specific Responsibility
proposed to be sub-
contracted
Statement of similar works
executed by the Sub-Contractor in
the past
To be filled To be filled To be filled


7.2.15 TECH 15: Authorization Letter from OEM
(To be submitted on the Letterhead of the OEM)
(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Dear Sir,

We _____ who are established and reputable manufacturers/ developers of __________________
having factories/ offices at ________________________________ do hereby authorize M/s
____________[Name and address of vendor] to submit a Bid and sign the contract with you for the
goods/ solution manufactured/ developed by us against the above RFP.

We undertake to provide the following:

1. Support for turnkey implementation of the project covering all the asset and application
components, their planning, design, engineering customization and their integration with other
components in the project and project completion within the time schedules specified in the
tender document.
2. Support for the term of the contract the products / solutions being supplied to Department of
Post. If the same is de-supported by us for any reason whatsoever, we undertake to replace it
with an equivalent or better substitute that is acceptable to Department of Posts, without any
additional cost to Department of Posts and without impacting the performance of the solution in
any manner.
3. Support for operation, maintenance and upgrades, as defined in Section 5 in Volume I of the
RFP, including supply and/or installation all new releases, versions, any type of update, upgrade
patch and/or bug fixes for the software or firmware from time to time to Department of Posts.
4. For any future requirements to add any new business capability to the proposed product/
solution, offer our best terms for negotiations.
5. Enter into an end user license agreement with Department of Post

organization and empowered to sign this document as well as such other documents, which may be


Yours sincerely,

on behalf of *OEMs Name+
Authorized Signature [In full and initials]:
Name of Firm:
Address:
Seal/Stamp of System Integrator:


7.2.16 TECH 16: Power of Attorney for signing of Application
(Refer Section 3.4 )

Know all men by these presents, We.. (name of the firm and address of
the registered office) do hereby irrevocably constitute, nominate, appoint and authorise Mr/ Ms
(name), son/daughter/wife of and presently residing at
., who is presently employed with us (the System Integrator) and holding the position of
. , as our true and lawful attorney (hereinafter referred to as the Attorney) to do
in our name and on our behalf, all such acts, deeds and things as are necessary or required in
connection with or incidental to submission of our application for pre-qualification and submission
of our bid for the ***** Project proposed or being developed by the ***** (the Authority)
including but not limited to signing and submission of all applications, bids and other documents and
writings, participate in Pre-Applications and other conferences and providing information/ responses
to the Authority, representing us in all matters before the Authority, signing and execution of all
contracts including the Concession Agreement and undertakings consequent to acceptance of our
bid, and generally dealing with the Authority in all matters in connection with or relating to or arising
out of our bid for the said Project and/ or upon award thereof to us and/or till the entering into of
the Concession Agreement with the Authority.

AND we hereby agree to ratify and confirm and do hereby ratify and confirm all acts, deeds and
things done or caused to be done by our said Attorney pursuant to and in exercise of the powers
conferred by this Power of Attorney and that all acts, deeds and things done by our said Attorney in
exercise of the powers hereby conferred shall and shall always be deemed to have been done by us.

IN WITNESS WHEREOF WE, ., THE ABOVE NAMED PRINCIPAL HAVE EXECUTED THIS
POWER OF ATTORNEY ON THIS DAY OF . 2..

For

..

(Signature, name, designation and address)

Witnesses:

1.

(Notarised)
2.


Accepted

(Signature)

(Name, Title and Address of the Attorney)

Notes:

1. The mode of execution of the Power of Attorney should be in accordance with the procedure, if
any, laid down by the applicable law and the charter documents of the executant(s) and when it
is so required, the same should be under common seal affixed in accordance with the required
procedure.
2. Wherever required, the Applicant should submit for verification the extract of the charter
documents and documents such as a board or shareholders resolution/ power of attorney in
favour of the person executing this Power of Attorney for the delegation of power hereunder on
behalf of the Applicant.
3. For a Power of Attorney executed and issued overseas, the document will also have to be
legalised by the Indian Embassy and notarised in the jurisdiction where the Power of Attorney is
being issued. However, the Power of Attorney provided by Applicants from countries that have
signed the Hague Legislation Convention 1961 are not required to be legalised by the Indian
Embassy if it carries a conforming Appostille certificate.


7.2.17 TECH 17: Non-Malicious Code Certificate

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122
Email: [email protected].

Subject: Non-Malicious Code Certificate

Dear Sir,

I. We hereby certify that the hardware and the software being offered as part of the contract does
not contain any kind of malicious code that would activate procedures to:
a. Inhibit the desired and the designed function of the equipment.
b. Cause physical damage to the user or his equipment during the operational exploitation of
the equipment.
c. Tap information regarding network, network users and information stored on the network
that is classified and / or relating to National Security, thereby contravening Official Secrets
Act 1923.

II. There are no Trojans, Viruses, Worms, Spywares or any malicious software on the system and in
the software developed.

III. Without prejudice to any other rights and remedies available to Department of Posts, we are
liable in case of physical damage, loss of information and those relating to copyright and
Intellectual Property rights (IPRs), caused due to activation of any such malicious code in
embedded / shipped software.


Yours sincerely,

Name of Firm:
Address:


7.2.18 TECH 18: Patent Rights Confirmation

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122
Email: [email protected].

Subject: Patent rights confirmation

Dear Sir,

I. We do hereby undertake that none of the deliverables being provided by us is infringing on any
patent or intellectual and industrial property rights as per the applicable laws of relevant
jurisdictions having requisite competence.

II. We also confirm that there shall be no infringement of any patent or intellectual and industrial
property rights as per the applicable laws of relevant jurisdictions having requisite competence,
in respect of the equipments, systems or any part thereof to be supplied by us. We shall
indemnify Department of Posts against all cost/claims/legal claims/liabilities arising from third
party claim in this regard at any time on account of the infringement or unauthorised use of
patent or intellectual and industrial property rights of any such parties, whether such claims
arise in respect of manufacture or use. Without prejudice to the aforesaid indemnity, the SI shall
be responsible for the completion of the supplies including spares and uninterrupted use of the
equipment and/or system or any part thereof to Department of Posts and persons authorised by
Department of Posts, irrespective of the fact of claims of infringement of any or all the rights
mentioned above.

III. If at a later date it is found that it does infringe on patent rights, we absolve Department of Posts
of any legal action.


Yours sincerely,

Name of Firm:
Address:


7.2.19 TECH 19: Undertaking on Sizing

(To be submitted on the Letterhead of the Bidder)
(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Sub: Undertaking on Sizing regarding Selection of Core System Integrator

Dear Sir,

I. We have acted as System Integrators of server hardware for Server, Router, Firewall and Load
Balancers components < Insert other components name> being sized and provided, pursuant to
the Request for Proposal (RFP) document for Selection of Core System Integrator for India Post
Modernisation project

II. We have sized the hardware, software and other equipment based on the information provided
by Department of Posts in its RFP document and in accordance with the tender and Service Level
requirements and assure Department of Posts that the sizing consider all requirements
mentioned in the RFP document.

III. However, if the sizing of any of the proposed solutions is found to be inadequate in meeting the
tender and the Service Level requirements given by Department of Posts, then we will upgrade
the proposed solution without any additional cost to Department of Posts


Yours sincerely,

on behalf of *Bidders Name]
Name of Firm:
Address:
Seal/Stamp of Bidder:


7.2.20 TECH 20: Declaration that the Bidder has not been blacklisted

(To be submitted on the Letterhead of the Bidder)
(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Dear Sir,

We confirm that our company is not blacklisted in any manner whatsoever by central Government
institution or Public Sector Units (PSUs) in India.

organization and empowered to sign this document as well as such other documents, which may be


Yours sincerely,

on behalf of [Bidders Name+
Authorized Signature [In full and initials]:
Name of Firm:
Address:
Seal/Stamp of Bidder:

Important Note:
1. The above criteria related to blacklisting will be valid till the final award of contract.
2. Bidders will be obliged to inform Department of Posts in writing about any changes in status
(if any) with respect to above blacklisting criteria, and till the conclusion of final award of
contract.


7.3 Financial Bid Formats
7.3.1 FIN 1: Covering Letter

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Subject: Submission of RFP for Selection of Core System Integrator
Dear Sir,

We, the undersigned, offer to provide Core System Integration services for India Post IT
Modernisation project in accordance with your Request for Proposal dated _____ and our Technical
Proposal.

Our attached Financial Proposal is for the sum of [Insert amount(s) in words and figures
1
]. The
amount of the local taxes, as identified/estimated is shown in the summary separately.

Our Financial Proposal shall be binding upon us subject to the modifications resulting from Contract
negotiations, up to expiration of the validity period of the Proposal, i.e. for 180 days after the date of
bid opening prescribed by Department of Posts.

We hereby certify that we have taken steps to ensure that no person acting for us or on our behalf
will engage in bribery.

We undertake that, in competing for (and, if the award is made to us, in executing) the above
contract, we will strictly observe the laws against fraud and corruption in force in India namely
Prevention of Corruption Act, 1988.

We understand you are not bound to accept any Proposal you receive.


Yours sincerely,

Name of Firm:
Address:

1
Amounts must coincide with the ones indicated under Total Price of Financial proposal in Form FIN-2
7.3.2 FIN 2: Schedule of Requirements
Bidder to specify make and model against each hardware item mentioned as part of the Summary of price. Similarly the version number of the software to
be specified against each software item mentioned as part of the Summary of Price
7.3.2.1 FIN 2: Schedule of Requirements
Table 13: FIN2.1 Consolidated Price Summary Inclusive of Taxes
# Component Total Price (`)
A Hardware price (including 3 year warranty maintenance) as per FIN 2.2 Fill up here
B Software License price (including 3 year warranty maintenance including COTS solution) as per FIN 2.3 Fill up here
C Software development, customization, implementation and roll out price as per FIN 2.4 Fill up here
D Training price as per FIN 2.5 Fill up here
E Call Centre price as per FIN 2.6 Fill up here
F Service Desk price NPV as per FIN 2.7 Fill up here
G Operations and Maintenance NPV price as per FIN 2.8 Fill up here
H Total (A+B+C+D+E+F+G) Fill up here
7.3.2.2 FIN 2.2: Hardware Price
# Component OEM
Make /
Model
P
r
i
c
e

p
e
r

U
n
i
t

/

L
o
c
a
t
i
o
n

/

B
a
t
c
h
/

R
e
s
o
u
r
c
e

(
a
s

a
p
p
l
i
c
a
b
l
e
)

N
o
.

o
f

U
n
i
t
s
/
l
o
c
a
t
i
o
n
s
/
B
a
t
c
h
e
s

/

R
e
s
o
u
r
c
e
s

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
o
t
a
l

P
r
i
c
e

(
e
x
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

N
a
m
e

o
f

t
h
e

T
a
x

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
a
x

R
a
t
e

(
t
o

b
e

m
e
n
t
i
o
n
e
d
)

A
m
o
u
n
t

o
f

T
a
x

(
`
)

T
o
t
a
l

P
r
i
c
e

i
n

`

(
i
n
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

1 Servers

1.1 Core Application Server

1.1.1 DC (Wave 1) To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.2 DC (Wave 2&3) To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.3 DRC (Wave 1) To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.4 DRC (Wave 2&3) To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
a. Sub-total of Core Application Server

To be filled
1.2 Database Server
b. Sub-total of Database Server To be filled
1.3 Development & Testing Server
c. Sub-total of Development & Testing Server To be filled
1.4
Miscellaneous
Servers (Web,
Management,
email, Security
etc.)
To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
d. Total of Servers To be filled
2 Storage To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
2.1 Storage Array To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
2.2 SAN Switches To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
2.3 FC IP Routers To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
2.4 Miscellaneous To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
e. Sub-total of Storage To be filled
3 Tape Library To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
f.
Sub-total of Tape To be filled
Library
A Total Hardware Price To be filled
Bidder to specify make and model against each hardware item mentioned as part of the Hardware Price.
Bidder to add more columns for more than one taxes, as applicable.
7.3.2.3 FIN 2.3: Software License Price (Enterprise-wide, including warranty maintenance in case of COTS based modules)
# Module OEM
Version
details
P
r
i
c
e

p
e
r

U
n
i
t

/

L
o
c
a
t
i
o
n

/

B
a
t
c
h
/

R
e
s
o
u
r
c
e

(
a
s

a
p
p
l
i
c
a
b
l
e
)

N
o
.

o
f

U
n
i
t
s
/
l
o
c
a
t
i
o
n
s
/
B
a
t
c
h
e
s

/

R
e
s
o
u
r
c
e
s

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
o
t
a
l

P
r
i
c
e

(
e
x
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

N
a
m
e

o
f

t
h
e

T
a
x

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
a
x

R
a
t
e

(
t
o

b
e

m
e
n
t
i
o
n
e
d
)

A
m
o
u
n
t

o
f

T
a
x

(
`
)

T
o
t
a
l

P
r
i
c
e

i
n

`

(
i
n
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

1 Common Infrastructure Solution

1.1 EMS To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.2 ESB To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.3 Email To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.4 Directory To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.5 Service Desk To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled

Sub-total of Common Infrastructure Solution

To be filled
2 Mail Operations

2.1
Mail Booking
Engine
2.2
India Post
Visibility System
2.3
Delivery &
Postman
Management
System
2.4
Mailer & Logistics
Appointment
Scheduling
System
2.5
Labour Scheduling
System
2.6
Sort Program
System
2.7
Client application
for RICT
Sub-total of Mail Operations To be filled
3 Logistics Post

3.1
Warehouse
Management
System
3.2
Transportation
Management
System

Sub-total of Logistics Post

To be filled
4 Finance & Accounts

4.1
Finance &
Accounts
application
4.2
Procurement &
Inventory
application
4.3
RICT Client
application

Sub-total of Finance & Accounts

To be filled
5 Human Resources

5.1
Human Resources
applications
5.2
ESS user
application
5.3
MSS user
application

Sub-total of Human Resources

To be filled
6 Customer Interaction Management

6.1 Point of Sale To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
6.2 Web-Portal To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled
6.3 Mobile channel To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled To be filled

Sub-total of Customer Interaction
Management

To be filled
7
Customer
Information
Management
8
Database
software for DC
server application
9
Database
software for DRC
server application
10
Miscellaneous
applications
B Total of Software licence price

To be filled
7.3.2.4 FIN 2.4: Software & Infrastructure Price
# Component
P
r
i
c
e

p
e
r

U
n
i
t

/

L
o
c
a
t
i
o
n

/

B
a
t
c
h
/

R
e
s
o
u
r
c
e

(
a
s

a
p
p
l
i
c
a
b
l
e
)

N
o
.

o
f

U
n
i
t
s
/
l
o
c
a
t
i
o
n
s
/
B
a
t
c
h
e
s

/

R
e
s
o
u
r
c
e
s

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
o
t
a
l

P
r
i
c
e

(
e
x
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

N
a
m
e

o
f

t
h
e

T
a
x

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
a
x

R
a
t
e

(
t
o

b
e

m
e
n
t
i
o
n
e
d
)

A
m
o
u
n
t

o
f

T
a
x

(
`
)

T
o
t
a
l

P
r
i
c
e

i
n

`

(
i
n
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

1 Software Services

1.1 Customization Price (wherever applicable) To be filled To be filled To be filled To be filled To be filled
1.1.1 Mail Operation To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.2 Logistics Post To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.3 F&A To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.4 HR To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.5 Web Portal To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.6 SMS Gateway To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.1.7
Misc. application as
required
To be filled To be filled To be filled To be filled To be filled To be filled To be filled
a. Sub-total of customization price

To be filled
1.2 Data Migration

b. Sub-total for Data Migration

To be filled
1.3 Implementation Price at Central Location

1.3.5
Misc. application as
required
c. Sub-total of Implementation at Central Location

To be filled
1.4 Roll-out

1.4.1 Wave 2 - Pilot Locations To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.4.2
Wave 2 - Phase 1
Locations
1.4.3
Wave 2 - Phase 2
Locations
1.4.4 Wave 3 - Pilot Locations To be filled To be filled To be filled To be filled To be filled To be filled To be filled
1.4.5
Wave 3 Final Roll-out
Locations
d. Sub-total for Roll out

To be filled
e. Sub-total for Implementation Services (c + d)

To be filled
f.
Sub-total of customization, data migration,
implementation and roll out price

To be filled
2
Infrastructure
Implementation services
C Total of Software and Infrastructure Services

To be filled
7.3.2.5 FIN 2.5: Training Price
# Component
P
r
i
c
e

p
e
r

B
a
t
c
h
/

R
e
s
o
u
r
c
e

(
a
s

a
p
p
l
i
c
a
b
l
e
)

N
o
.

o
f

B
a
t
c
h

/

R
e
s
o
u
r
c
e
s

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
o
t
a
l

P
r
i
c
e

(
e
x
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

N
a
m
e

o
f

t
h
e

T
a
x

(
a
s

a
p
p
l
i
c
a
b
l
e
)

T
a
x

R
a
t
e

(
t
o

b
e

m
e
n
t
i
o
n
e
d
)

A
m
o
u
n
t

o
f

T
a
x

(
`
)

T
o
t
a
l

P
r
i
c
e

i
n

`

(
i
n
c
l
u
s
i
v
e

o
f

t
a
x
e
s
)

Wave 1

1 User Champion To be filled To be filled To be filled To be filled To be filled To be filled To be filled
2 RICT User Champion To be filled To be filled To be filled To be filled To be filled To be filled To be filled
3 End User Training To be filled To be filled To be filled To be filled To be filled To be filled To be filled
4 Technical Training To be filled To be filled To be filled To be filled To be filled To be filled To be filled
5 Administrator Training To be filled To be filled To be filled To be filled To be filled To be filled To be filled
6
Executive Awareness
Training
7 Audit Training To be filled To be filled To be filled To be filled To be filled To be filled To be filled
8 Any Other (as required) To be filled To be filled To be filled To be filled To be filled To be filled To be filled

Wave 2

14
Executive Awareness
Training

Wave 3

22
Executive Awareness
Training
Total To be filled
7.3.2.6 FIN 2.6: Call Centre Price
Component Pricing Metric
No. of calls upto 15,000,000 (slab
1)
Slab 2 Slab n
Unit Rate (`)
upto 2 decimal
places
Unit Rate (`)
(words) upto 2
decimal places
Unit Rate (`)
upto 2 decimal
places
Unit Rate (`)
(words) upto 2
decimal places
Unit Rate (`)
upto 2 decimal
places
Unit Rate (`)
(words) upto 2
decimal places
Charges for handling
inbound calls by agents
Per call To be filled To be filled To be filled To be filled To be filled To be filled
Bidder to indicate the prices for incremental slabs as the call volumes grow. Minimum number of inbound calls expected is 15,000,000. Please refer the
volumetric data provided in section 8.2 of Volume I of this RFP. Financial evaluation will be done for 35,000,000 calls.
7.3.2.7 FIN 2.7: Service Desk Price
# Component
Year 1 (as applicable)
Year 2 (as
applicable)
Year 3 (as
applicable)
Year 4 (as
applicable)
Year 5 (as
applicable)
Year 6 (as
applicable)
Year 7 (as
applicable)
Persons to be Man-month Total Price (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C)
deployed (A)
Rate (`) (B) (`) (C)
1
Mail Operation
Applications
2 Logistics Post Application To be filled To be filled To be filled
3 F&A Applications To be filled To be filled To be filled
4 HR Applications To be filled To be filled To be filled
5 Web-Portal To be filled To be filled To be filled
6 eMail Application To be filled To be filled To be filled
7 EMS Application To be filled To be filled To be filled
8
Miscellaneous Application
(please specify)
9 Central Hardware To be filled To be filled To be filled
10 Any other (as required) To be filled To be filled To be filled

Total of Service Desk Price

To be filled

NPV Price of Service Desk To be filled

7.3.2.8 FIN 2.8: Operations & Maintenance Price
# Component
Year 1 (as applicable)
Year 2 (as
applicable)
Year 3 (as
applicable)
Year 4 (as
applicable)
Year 5 (as
applicable)
Year 6 (as
applicable)
Year 7 (as
applicable)
Persons to be Man-month Total Price (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C) (A) (B) (C)
deployed (A)
Rate (`) (B) (`) (C)
1
Mail Operation
Applications
2 Logistics Post Application To be filled To be filled To be filled
3 F&A Applications To be filled To be filled To be filled
4 HR Applications To be filled To be filled To be filled
5 Web-Portal To be filled To be filled To be filled
6 eMail Application To be filled To be filled To be filled
7 EMS Application To be filled To be filled To be filled
8
Miscellaneous Application
(please specify)
9 Central Hardware To be filled To be filled To be filled
10 Any other (as required) To be filled To be filled To be filled

Total of O&M Price

To be filled

NPV Price of O&M To be filled

Bidders to estimate the O&M cost according to the roll-out plan
7.3.3 FIN 3: Undertaking on Fall Clause

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Subject: Fall clause on the pricing of the solution

Dear Sir,

We, the undersigned, offer to provide Core System Integration services for India Post Modernisation
project in accordance with your Request for Proposal dated _____ and our Technical Proposal.

We undertake that in the last 12 months we have not supplied/are not supplying the similar
systems or subsystems at a price lower than that offered in the present Bid in respect of any other
Ministry/Department of the Government of India or a Public Sector Unit / Organization and if it is
found at any stage that the similar system or sub-system was supplied by us to any other
Ministry/Department of the Government of India at a lower price, then that very price, with due
allowance for elapsed time, will be applicable to the present case and the difference in the cost
would be refunded by us to Department of Posts, if payments have already been made to us for the
solution

Yours sincerely,

Name of Firm:
Address:

7.3.4 FIN 4: Undertaking on Pricing of Technical Bid Items

(Place)
(Date)

To
New Delhi 110001
Telephone: 011 2303 6763; Fax: 011- 2309 6122

Subject: Pricing of Technical bid Items
Dear Sir,

We do hereby undertake that Financial proposal submitted by us is inclusive of all the items in
the technical proposal and is inclusive of all the clarification provided/ may be provided by us on
the technical proposal during the evaluation of the technical offer. We understand and agree
that our Financial proposal is firm and final and any clarifications sought by you and provided by
us would not have any impact on the commercial proposal submitted by us.


Yours sincerely,

Name of Firm:
Address:

7.4 Request for Clarifications Format

BIDDERS REQUEST FOR CLARIFICATION RFP for Selection of Core System Integrator
Name of Organisation
submitting the request:
Name and position of person
submitting request:
Contact details of person
submitting the request:
Address:
Telephone:
Fax:
Email:
#
Bidding Document Reference(s)
(section number/ page)
Content of bid Document
requiring Clarification
Points of clarification
required

7.5 Bank Guarantee Format for Earnest Money Deposit

Whereas (hereinafter called the tenderer)
has submitted their offer dated. for the supply of
.. (hereinafter called the tender) against the
purchasers tender enquiry No. ..

KNOW ALL MEN by these presents that WE . of
.. having our registered office at
. are bound unto . (hereinafter called the
Purchaser) in the sum of for which payment
will and truly to be made to the said Purchaser, the Bank binds itself, its successors and assigns by
these presents. Sealed with the
Common Seal of the said Bank this day of .20

THE CONDITIONS OF THIS OBLIGATION ARE:
1. If the tenderer withdraws or amends, impairs or derogates from the tender in any respect
within the period of validity of this tender.
2. If the tenderer having been notified of the acceptance of his tender by the Purchaser during
the period of its validity:-
a. If the tenderer fails to furnish the Performance Security for the due performance of
the contract.
b. Fails or refuses to accept/execute the contract.

WE undertake to pay the Purchaser up to the above amount upon receipt of its first written demand,
without the Purchaser having to substantiate its demand, provided that in its demand the Purchaser
will note that the amount claimed by it is due to it owing to the occurrence of one or both the two
conditions, specifying the occurred condition or conditions.

This BANK GUARANTEE shall be interpreted in accordance with the laws of India.

The Guarantor Bank represents that this BANK GUARANTEE has been established in such form and
with such content that is fully enforceable in accordance with its terms as against the Guarantor
Bank in the manner provided herein.

This BANK GUARANTEE shall not be affected in any manner by reason of merger, amalgamation,
restructuring or any other change in the constitution of the Guarantor Bank.

The Bank further undertakes not to revoke this Guarantee during its currency except with the
previous express consent of Department of Posts, in writing.

The Bank declares that it has power to issue this Guarantee and discharge the obligations
contemplated herein, the undersigned is duly authorised and has full power to execute this
Guarantee for and on behalf of the Bank.

This guarantee will remain in force up to and including 45 days after the period of tender validity and
any demand in respect thereof should reach the Bank not later than the above date.

.
(Signature of the authorised officer of the Bank)

.
.
Name and designation of the officer

.
Seal, name and address of the Bank and address of the Branch

7.6 Performance Bank Guarantee Format

To
The President of India

WHEREAS . (Name and Address of the supplier)
(hereinafter called the supplier) has undertaken, in pursuance of contract no.
dated . to provide Core System Integration services for India Post Modernisation project
(herein after called the contract). AND WHEREAS it has been stipulated by you in the said contract
that the supplier shall furnish you with a bank guarantee by a scheduled commercial recognised by
you for the sum specified therein as security for compliance with its obligations in accordance with
the contract;

AND WHEREAS we have agreed to give the supplier such a bank guarantee;

NOW THEREFORE we hereby affirm that we are guarantors and responsible to you, on behalf of the
supplier, up to a total of . (amount of the guarantee
in words and figures), and we undertake to pay you, upon your first written demand declaring the
supplier to be in default under the contract and without cavil or argument, any sum or sums within
the limits of (amount of guarantee) as aforesaid, without your needing to prove or to show grounds
or reasons for your demand or the sum specified therein.

We hereby waive the necessity of your demanding the said debt from the supplier before presenting
us with the demand.

We further agree that no change or addition to or other modification of the terms of the contract to
be performed thereunder or of any of the contract documents which may be made between you
and the supplier shall in any way release us from any liability under this guarantee and we hereby
waive notice of any such change, addition or modification.

This BANK GUARANTEE shall be interpreted in accordance with the laws of India.

The Guarantor Bank represents that this BANK GUARANTEE has been established in such form and
with such content that is fully enforceable in accordance with its terms as against the Guarantor
Bank in the manner provided herein.

This BANK GUARANTEE shall not be affected in any manner by reason of merger, amalgamation,
restructuring or any other change in the constitution of the Guarantor Bank.

The Bank further undertakes not to revoke this Guarantee during its currency except with the
previous express consent of Department of Posts, in writing.

The Bank declares that it has power to issue this Guarantee and discharge the obligations
contemplated herein, the undersigned is duly authorised and has full power to execute this
Guarantee for and on behalf of the Bank.

This guarantee shall be valid until the .. day of , 201

(Signature of the authorised officer of the Bank)
.

Name and designation of the officer
.
.

Seal, name and address of the Bank and address of the Branch

Core Si RFP Volume II

Uploaded by

Copyright:

Available Formats

Core Si RFP Volume II

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Core Si RFP Volume II

Uploaded by

Copyright:

Available Formats

Request for Proposal (RFP) for Selection of Core

System Integrator (CSI)

You might also like