View
221
Download
0
Category
Preview:
Citation preview
cument History
Overview Procurement Policy Manual for RajCOMP Info Services Limited
Document Title
RajCOMP Info Services Limited- Manual on Policies and Procedures for
Procurement
Document Status
Final
Abstract This document provides a broad framework and guidelines for RajCOMP
Info Services Limited Staff in carrying out various procurement activities.
Document Publication History
Date Author Version Remark
17th February 2011 Dr. S.S. Vaishnava V3 Final Version
Distribution
Version Name Location
Final MD RajComp Info Services
Limited
RajComp Info Services Limited office,
Jaipur
Secretary (IT) RajComp Info Services Limited office,
Jaipur
RajCOMP Info Services Limited (RISL)
Request For Proposal (RFP) for “Design, Development and Implementation of Store Management System (SMS) for Rajasthan Police, Government of Rajasthan along with Operation & Maintenance Services”
2015
“Design, Development and Implementation of Store Management System (SMS)”
Page 2 of 198
Table of Contents
Contents ABBREVIATIONS & DEFINITIONS .................................................................................................................. 7
1. INVITATION FOR BID (IFB) & NOTICE INVITING BID (NIB) ................................................................. 10
2. ROJECT PROFILE & BACKGROUND INFORMATION .......................................................................... 13
2.1 Project Profile 13
2.2 About the Rajasthan police 18
3. PRE-QUALIFICATION/ ELIGIBILITY CRITERIA ..................................................................................... 21
4. SCOPE OF WORK, DELIVERABLES & TIMELINES................................................................................ 23
4.1 Preparation of FRS and SRS 23
4.1.1 Undertake Requirement Gathering, Preparation of Project Documents, Functional
Requirement Study (FRS) Document 23
4.1.2 Preparation of Software Requirement Specification 25
4.2 Development of Application software 25
4.3 Integration with Other Applications 26
4.4 Testing of the Developed Application 26
4.5 User Acceptance Testing 26
4.6 Security Audit / Safe to Host Certification of developed application 26
4.7 Data Digitization and Migration 27
4.8 Deployment and Configuration of Application 27
4.9 Training and Capacity Building 27
4.10 Application Go-Live 28
4.11 Operation & Maintenance of the Application 28
4.12 Infrastructure Deployment (Supply, Installation and Commissioning of the Hardware
Infrastructure) 30
4.14 Major Roles & Responsibilities (Stakeholder-wise) 30
4.15 Project Milestones, Deliverables and Time Schedule 34
5. INSTRUCTION TO BIDDERS (ITB) ........................................................................................................... 36
5.1 Sale of Bidding/ Tender Documents 36
5.2 Pre-bid Meeting/ Clarifications 36
5.3 Changes in the Bidding Document 36
5.4 Period of Validity of Bids 37
5.5 Format and Signing of Bids 37
5.6 Cost & Language of Bidding 38
5.7 Alternative/ Multiple Bids 39
5.8 Bid Security 39
“Design, Development and Implementation of Store Management System (SMS)”
Page 3 of 198
5.9 Deadline for the submission of Bids 40
5.10 Withdrawal, Substitution, and Modification of Bids 41
5.11 Opening of Bids 41
5.12 Selection Method: 41
5.13 Clarification of Bids 42
5.14 Evaluation & Tabulation of Technical Bids 42
5.15 Evaluation & Tabulation of Financial Bids 43
5.16 Correction of Arithmetic Errors in Financial Bids 44
5.17 Comparison of rates of firms outside and those in Rajasthan 44
5.18 Price/ purchase preference in evaluation 45
5.19 Negotiations 45
5.20 Exclusion of Bids/ Disqualification 45
5.21 Lack of competition 46
5.22 Acceptance of the successful Bid and award of contract 47
5.23 Information and publication of award 48
5.24 Procuring entity’s right to accept or reject any or all Bids 48
5.25 Right to vary quantity 48
5.26 Performance Security 48
5.27 Execution of agreement 49
5.28 Confidentiality 50
5.29 Cancellation of procurement process 50
5.30 Code of Integrity for Bidders 51
5.31 Interference with Procurement Process 52
5.32 Appeals 52
5.33 Stay of procurement proceedings 54
5.34 Vexatious Appeals & Complaints 54
5.35 Offenses by Firms/ Companies 54
5.36 Debarment from Bidding 55
5.37 Monitoring of Contract 56
6. GENERALTERMS AND CONDITIONS OF TENDER & CONTRACT ...................................................... 57
Definitions 57
6.1 Contract Documents 58
6.2 Interpretation 58
6.3 Language 58
6.4 Joint Venture, Consortium or Association 59
6.5 Eligible Goods and Related Services 59
6.6 Notices 59
6.7 Governing Law 59
“Design, Development and Implementation of Store Management System (SMS)”
Page 4 of 198
6.8 Scope of Supply 60
6.9 Delivery & Installation 60
6.10 Supplier’s/ Selected Bidder’s Responsibilities 60
6.11 Purchaser’s Responsibilities 61
6.12 Contract Price 61
6.13 Recoveries from Supplier/ Selected Bidder 61
6.14 Taxes & Duties 61
6.15 Copyright 62
6.16 Confidential Information 62
6.17 Sub-contracting 63
6.18 Specifications and Standards 63
6.19 Packing and Documents 64
6.20 Insurance 64
6.21 Transportation 64
6.22 Inspection 65
6.23 Samples 65
6.24 Drawl of Samples 66
6.25 Testing charges 66
6.26 Rejection 66
6.27 Extension in Delivery Period and Liquidated Damages (LD) 66
6.28 Authenticity of Equipment 68
6.29 Warranty 69
6.30 Patent Indemnity 69
6.31 Limitation of Liability 70
6.32 Force Majeure 71
6.33 Change Orders and Contract Amendments 71
6.34 Termination 72
a) Termination for Default 72
b) Termination for Insolvency 72
c) Termination for Convenience 73
6.35 Exit Management 73
6.36 Settlement of Disputes 77
7. SPECIAL TERMS AND CONDITIONS OF TENDER & CONTRACT ....................................................... 79
7.1 Payment Terms and Schedule 79
7.2 Service Level Standards/ Requirements/ Agreement 80
7.3 Change Requests/ Management 82
ANNEXURE-1: BILL OF MATERIAL (BOM) ....................................................................................................... 84
ANNEXURE-2: TECHNICAL STANDARDS & SPECIFICATIONS ................................................................... 85
“Design, Development and Implementation of Store Management System (SMS)”
Page 5 of 198
ANNEXURE-3: PRE-BID QUERIES FORMAT .................................................................................................. 89
ANNEXURE-4: BIDDER’S AUTHORIZATION CERTIFICATE ......................................................................... 90
ANNEXURE-5: SELF-DECLARATION ............................................................................................................... 91
ANNEXURE-6: CERTIFICATE OF CONFORMITY/ NO DEVIATION .............................................................. 93
ANNEXURE-7: DECLARATION BY BIDDER .................................................................................................... 94
ANNEXURE-8: MANUFACTURER’S AUTHORIZATION FORM (MAF) ............................................................ 95
ANNEXURE-9: UNDERTAKING ON AUTHENTICITY OF COMPUTER EQUIPMENTS .................................. 96
ANNEXURE-10: FINANCIAL BID COVER LETTER & FORMAT ..................................................................... 97
COVER LETTER .................................................................................................................................................. 97
ANNEXURE-11: BANK GUARANTEE FORMAT............................................................................................. 101
ANNEXURE-12: DRAFT AGREEMENT FORMAT .......................................................................................... 106
ANNEXURE-13: FORMAT FOR SUBMISSION OF PROJECT REFERENCES FOR PRE-
QUALIFICATION EXPERIENCE ...................................................................................................................... 109
ANNEXURE-14: MEMORANDUM OF APPEAL UNDER THE RTPP ACT, 2012 .......................................... 110
ANNEXURE-15: EXPECTED QUALIFICATION OF MANPOWER RESOURCES .......................................................... 111
ANNEXURE-16: LIST OF STORES AND OFFICES, RAJASTHAN POLICE ................................................................ 112
ANNEXURE-17: FUNCTIONAL REQUIREMENT SPECIFICATIONS (FRS) ............................................................... 115
1.1 DEMAND MANAGEMENT MODULE ............................................................................................................... 116
1.2 MASTER DATA MANAGEMENT MODULE ...................................................................................................... 123
1.3 MATERIAL SUPPLY AND STOCK ENTRY MODULE ........................................................................................ 131
1.4 STOCK ALLOTMENT AND ISSUE MODULE ........................................................................................................ 139
1.5 PERSONNEL AND BRANCH ALLOTMENT MODULE ............................................................................................ 145
1.6 STOCK TRANSFER MODULE........................................................................................................................ 149
1.7 EMPLOYEE TRANSFER MODULE ................................................................................................................. 154
1.8 FIXED ASSETS MODULE ............................................................................................................................. 158
1.9 WORKFLOW MANAGEMENT MODULE .......................................................................................................... 162
1.10 DASHBOARD AND REPORTING MODULE ...................................................................................................... 173
1.11 OTHER REQUIREMENTS.............................................................................................................................. 176
1.11.1 Integration Requirements 176
1.11.2 Management of documents 178
1.11.3 Additional Requirements 184
ANNEXURE 18: TECHNICAL SPECIFICATION (HARDWARE) .................................................................... 195
“Design, Development and Implementation of Store Management System (SMS)”
Page 6 of 198
Request For Proposal (RFP) for “Design, Development and Implementation of Store Management System (SMS) for Rajasthan Police, Government of Rajasthan along with
Operation & Maintenance Services”
[Reference No. <Ref. No.> dated <date>]1
Mode of Bid Submission Online though eProcurement/ eTendering system at http://eproc.rajasthan.gov.in
Procuring Authority Managing Director, RISL, First Floor, C-Block, Yojana Bhawan, Tilak Marg, C-Scheme, Jaipur-302005 (Rajasthan)
Date & Time of Pre-bid meeting 15 June 2015, 03:00 PM Last Date & Time of Submission of Bid 25 June 2015, 03:00 PM Date & Time of Opening of Technical Bid 25 June 2015, 04:00 PM
Bidding Document Fee: Rs. 1000 (Rupees One Thousand only)
Name of the Bidding Company/ Firm:
Contact Person (Authorised Bid Signatory):
Correspondence Address:
Mobile No. Telephone & Fax Nos.:
Website & E-Mail:
RajCOMP Info Services Limited (RISL) First Floor, Yojana Bhawan, C-Block, Tilak Marg, C-Scheme, Jaipur-302005 (Raj.)
Phone: 0141- 5103902 Fax: 0141-2228701
Web: http://risl.rajasthan.gov.in, Email: chhatrapal.risl@rajasthan.gov.in
“Design, Development and Implementation of Store Management System (SMS)”
Page 7 of 198
ABBREVIATIONS & DEFINITIONS
Act The Rajasthan Transparency in Public Procurement Act, 2012 (Act No. 21 of 2012) and Rules thereto
Authorised Signatory
The bidder’s representative/ officer vested (explicitly, implicitly, or through conduct) with the powers to commit the authorizing organization to a binding agreement. Also called signing officer/ authority having the Power of Attorney (PoA) from the competent authority of the respective Bidding firm.
BG Bank Guarantee
Bid/ eBid A formal offer made in pursuance of an invitation by a procuring entity and includes any tender, proposal or quotation in electronic format
Bid Security A security provided to the procuring entity by a bidder for securing the fulfilment of any obligation in terms of the provisions of the bidding documents.
Bidder Any person/ firm/ agency/ company/ contractor/ supplier/ vendor participating in the procurement/ bidding process with the procurement entity
Bidding Document Documents issued by the procuring entity, including any amendments thereto, that set out the terms and conditions of the given procurement and includes the invitation to bid
BoM Bill of Material
CMC Contract Monitoring Committee
Competent Authority An authority or officer to whom the relevant administrative or financial powers have been delegated for taking decision in a matter relating to procurement. MD, RISL in this bidding document.
Contract/ Procurement Contract
A contract entered into between the procuring entity and a successful bidder concerning the subject matter of procurement
Contract/ Project Period
The Contract/ Project Period shall commence from the date of issue of Work order till completion of One Year of Operations & Maintenance Services after Go Live of the project.
COTS Commercial Off The Shelf Software
C/S Central Store
Day A calendar day as per GoR/ GoI.
DeitY, GoI Department of Electronics and Information Technology, Government of India
DoIT&C Department of Information Technology and Communications, Government of Rajasthan.
“Design, Development and Implementation of Store Management System (SMS)”
Page 8 of 198
ETDC Electronic Testing & Development Center
FOR/ FOB Free on Board or Freight on Board
FUS Field Unit Store
GoI/ GoR Govt. of India/ Govt. of Rajasthan
Goods
All articles, material, commodities, electricity, livestock, furniture, fixtures, raw material, spares, instruments, software, machinery, equipment, industrial plant, vehicles, aircraft, ships, railway rolling stock and any other category of goods, whether in solid, liquid or gaseous form, purchased or otherwise acquired for the use of a procuring entity as well as services or works incidental to the supply of the goods if the value of services or works or both does not exceed that of the goods themselves
ICT Information and Communication Technology.
IFB Invitation for Bids (A document published by the procuring entity inviting Bids relating to the subject matter of procurement and any amendment thereto and includes notice inviting Bid and request for proposal)
INR Indian Rupee
ISI Indian Standards Institution
ISO International Organisation for Standardisation
IT Information Technology
ITB Instruction to Bidders
LD Liquidated Damages
LoI Letter of Intent
NCB National Competitive Bidding, a bidding process in which qualified bidders only from within India are allowed to participate
NIB Notice Inviting Bid
Notification A notification published in the Official Gazette
OEM Original Equipment Manufacturer
PAN Permanent Account Number
PBG Performance Bank Guarantee
PC Procurement/ Purchase Committee
PQ Pre-Qualification
Procurement Process
The process of procurement extending from the issue of invitation to Bid till the award of the procurement contract or cancellation of the procurement process, as the case may be
Procurement/ Public The acquisition by purchase, lease, license or otherwise of works, goods
“Design, Development and Implementation of Store Management System (SMS)”
Page 9 of 198
Procurement or services, including award of Public Private Partnership projects, by a procuring entity whether directly or through an agency with which a contract for procurement services is entered into, but does not include any acquisition without consideration, and “procure” or “procured” shall be construed accordingly
Project Site Wherever applicable, means the designated place or places.
PSD/ SD Performance Security Deposit/ Security Deposit
Purchaser/ Tendering Authority/ Procuring Entity
Person or entity that is a recipient of a good or service provided by a seller (bidder) under a purchase order or contract of sale. Also called buyer. RISL in this RFP document.
RAC Rajasthan Armed Constabulary
RajSWAN/ RSWAN Rajasthan State Wide Area Network
RISL RajCOMP Info Services Limited
RPD Rajasthan Police department
RSDC Rajasthan State Data Centre, New IT Building, Yojna Bhawan, Jaipur
RVAT Rajasthan Value Added Tax
Services
Any subject matter of procurement other than goods or works and includes physical, maintenance, professional, intellectual, consultancy and advisory services or any service classified or declared as such by a procuring entity and does not include appointment of any person made by any procuring entity
SI System Integrator
SLA
Service Level Agreement is a negotiated agreement between two parties wherein one is the customer and the other is the service provider. It is a a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.
SSDG State Services Delivery Gateway
State Government Government of Rajasthan (GoR)
State Public Procurement Portal http://sppp.raj.nic.in
Subject Matter of Procurement Any item of procurement whether in the form of goods, services or works
TIN Tax Identification Number
TPA Third Party Auditors
VAT/ CenVAT Value Added Tax/ Central VAT
WO/ PO Work Order/ Purchase Order
“Design, Development and Implementation of Store Management System (SMS)”
Page 10 of 198
1. INVITATION FOR BID (IFB) & NOTICE INVITING BID (NIB)
“Design, Development and Implementation of Store Management System (SMS)”
Page 13 of 198
2. ROJECT PROFILE & BACKGROUND INFORMATION
2.1 Project Profile
1) Thematic Focus/Project Objectives a) Rajasthan Police has a mandate to maintain overall public order, protect citizens
and property from the hazards of public accidents and commission of unlawful
acts.
b) In pursuance of the above mandate, Rajasthan Police needs various items/goods
for the effective discharge of these duties. The purchase, distribution, allotment of
these items/goods is done by various stores of the police.
c) Traditionally, various tasks associated with these stores have been done manually.
This includes demand gathering, identifying existing stock and inventory, preparing
demand proposals, entering details of purchased items in various registers and
capturing details of item allotment in registers and vouchers.
d) The existing process is fraught with issues like duplication of work, redundant
processes, time delays and wastages due to manual collection of information from
various stores through letters, errors and mistakes due to manual information
storage and retrieval.
e) The problem is amplified because of the maintenance of store at various levels by
each district, unit and wing of the police.
f) As the number of store items/goods are increasing day by day and amount of
information stored and retrieved is also increasing, the above mentioned problems
are getting amplified leading to loss of productivity and effectiveness.
g) In order to cut time wastages, reduce errors and to ensure prompt availability of
information for decision making, Rajasthan Police has decided for the automation
of the existing processes for management of various stores.
h) The department has adopted a multi-pronged approach for successful
implementation of Store Management System (SMS)
Software Application to store and retrieve information
IT infrastructure creation
Digitization of existing data
IT and Change Management Training
i) The main objectives of the department are:
To provide IT enabled platform to capture the information and data related
to various store processes. Department also envisages to ensure that
insightful and relevant information can be obtained from the proposed
system with ease and simplicity.
“Design, Development and Implementation of Store Management System (SMS)”
Page 14 of 198
To provide a platform to store in-charge and other store employees, which
shall reduce their manual effort, enabling them to record and capture
processes and data quickly and without errors. This will save their time and
further motivate them to perform their duties more diligently thus ensuring
greater productivity.
To capture complete workflow and processes followed by various stores for
processing the store management activities. Department also envisages
those processes which are redundant and which can either be removed or
re-engineered by the advanced IT solution.
j) The strategic objective of the Rajasthan Police is to make store processes more
efficient and in-turn ensure smooth functioning of other police wings and units
which depend on stores for their various demands.
2) Need and Benefits a) Rajasthan Police is essential for any state to maintain law & order, ensure safety of
citizens and property from unlawful activities and anti-social individuals. For
effective discharge of their duty, police personnel require various items.
b) To ensure that all required items are purchased and distributed effectively,
Rajasthan Police had created various stores. These stores were responsible to
purchase and distribute items related to uniform, arms & ammunition, motor
vehicles, stationery, printed material and other miscellaneous items. Further to
ensure that items are available promptly stores were maintained at various levels
like central store at police headquarter, field unit stores at police lines, battalions
and wings and also sub-field unit stores at lower levels like police stations,
companies etc.
c) The proposed Store Management System (SMS) is envisaged to be developed to
perform various store operations across all categories of stores at all levels. The
benefits which will accrue from this system are:
Eliminate Data Duplication: Earlier, with manual method of recording data,
information and transaction, same information was maintained across
various registers and multiple vouchers containing same information were
created. Store in-charge at various levels used to record same information
whenever the item/good was collected and distributed. This lead to
duplication of work and hence wastage of time. By envisaged system, a
single entry of information related to each item/good will be done and
“Design, Development and Implementation of Store Management System (SMS)”
Page 15 of 198
same information will be replicated whenever that information is needed at
any stage of work flow. This will cut down the duplication of work.
Elimination of redundant processes: With manual stores, several
processes like creation of issue vouchers and confirmation of these
vouchers by lower level stores by sending confirmed copies back to
higher level stores were done. Also, information used to be captured at
multiple places. This led to redundant activities being performed leading
to wastage of time and effort. With the new system, redundant
processes will be eliminated.
Paper less system: In the existing manual processes, lot of papers were
used in recording of information in registers and vouchers. With the new
system, all information will be recorded and exchanged electronically
leading to reduction in usage of power and hence saving of trees.
Advanced analytics and reporting system: With manual systems, it was
hard to extract information across multitudes of register and it was even
more difficult to perform meaningful analysis of extracted data. This led to
availability of insights for decision making. The envisaged system will
help to extract huge amount of information in no time and use of
advanced analytics tool will help to develop insightful reports and
information.
3) Brief Technical Solution Requirements
The selected bidder shall be responsible to provide a state of an art solution for the
technical requirements and scope of work mentioned in this bidding document.
The application software development work shall be in compliance to the best
practices, applicable industry standards and respective guidelines issued by
Department of information technology (DIT), Government of India (GoI) and
Department of Information Technology & Communication (DoIT&C), Government of
Rajasthan.
Bidder would involve only competent and qualified personnel for the fulfilment of
deliverables mentioned in this bidding document.
For detailed functional and technical requirements, selected bidder may refer to the
subsequent sections of this bidding document.
“Design, Development and Implementation of Store Management System (SMS)”
Page 16 of 198
4) Brief Scope of Work a) The scope involves study, design, development, testing and implementation of
Store Management System (SMS) application software for Rajasthan Police,
Government of Rajasthan.
b) Supply and installation of required IT infrastructure at Police Head Quarters (PHQ)
and other Rajasthan Police offices as mentioned in this bidding document.
c) Data entry, digitization and migration of legacy data into the database of proposed
solution. Legacy data is mainly available in physical registers and vouchers. Some
information may also be available in spreadsheet and word documents.
d) Training of various employees of Rajasthan Police on basic computer skills and
proposed Store Management System application.
e) After successful Go Live of the project, provide One (1) year of Operations &
Maintenance (O&M) services as per the Service Level Standards defined in the
RFP. If required, the O&M services may be extended on mutually agreed terms &
conditions.
f) Rajasthan Police expects the successful bidder to provide quality & timely
services. All the activities performed during different phases of the project shall be
closely monitored by RISL/DOIT&C/ Rajasthan Police /GoR.
g) For detailed Scope of Work (SOW), selected bidder may refer to the subsequent
sections of this bidding document.
5) Implementing and Participating Agencies (Stakeholders)
Rajasthan Police
Various police unit/wing stores
RajCOMP Info Service Limited (RISL)
Department of Information technology & Communication (DoIT&C), Government of
Rajasthan
6) Target Group (Beneficiaries)
Store In-charge
Central Store
Planning, Maintenance & Welfare Branch
“Design, Development and Implementation of Store Management System (SMS)”
Page 17 of 198
Store In-charge Most of the store operations and tasks is managed by store in-charge of respective store.
Store in-charges are responsible to maintain stock balance, identify items/goods nearing
or passed their expiry dates, send and collect holding & requirements data, maintain
various registers and allotment of items to personnel and branches. The direct
beneficiaries of the proposed Store Management System will be store in-charges. Brief list
of benefits which are expected from the SMS are:
(i) Ease of recording information in various registers: Store in-charge will not be
required to duplicate and record same information across various registers.
(ii) Elimination of redundant work: Store in-charge will not be required to track
vouchers and close their confirmation, once SMS is implemented, as voucher
status will be directly updated from the system. Also many other redundant store
operations will be reengineered and hence will reduce effort needed of store men.
(iii) Instant access of information: Store in-charge will not be required to track ledger
balances and stock inventory levels as this data will be updated automatically by
the system and hence instant stock balances will be available.
Central Store (i) Automatic demand collection: Central store will not be required to manually collect
annual requirements from 70 odd units of Rajasthan Police. Demand initiation and
collection will be automatically done using the SMS. This will cut down the time
required to collect information from individual stores.
(ii) Faster and flexible proposal preparation: Central store will not have to track each
items inventory balance and its future requirements to prepare purchase
proposals. This operation will be performed automatically by the proposed SMS
application. Moreover the system will allow flexibility in proposal preparation
according to different needs and criteria of police.
(iii) Real-time availability of stock location and stock balance: The proposed SMS
application will automatically keep track of stock items and stock balance across all
70 field unit stores. This will provide real time status of stock to central store.
Planning, Maintenance & Welfare Branch (i) Single Source of Information: The proposed system will provide the PM&W branch
single source of information. Senior officers will not have to consult various
registers and filed to extract necessary information. Information across all levels
and categories of store will be available at the click of a button and hence will free
up precious time of senior officers for more productive work.
“Design, Development and Implementation of Store Management System (SMS)”
Page 18 of 198
(ii) Advanced analysis and decision making support: The proposed system will have
advance analytic capabilities and tools which will allow senior officers to perform
advanced analysis of data across multiple dimensions and criteria. This will provide
deeper insights and help in fact based decision making.
7) Expected accomplishments from the project (Project Outcome)
The expected outcomes to be achieved from this project:
Centralized availability of information
Advanced analysis and decision making capability
Dashboard and customized reporting capability
Online initiation of tasks and real time monitoring
Online approvals and sanctions
Automatic update of stock balance and stock locations
Instant information to individuals and braches through SMS/Email
2.2 About the Rajasthan police
Rajasthan was formed by the merger of the erstwhile princely states. The security and the police
forces of the former princely states varied in composition, functions and administrative procedures.
Following the merger, the police forces of the princely states united as of January, 1951.
. Rajasthan Police is responsible for maintenance of public order and protection of persons and
property from the hazards of public accidents and the commission of unlawful acts
Rajasthan Police today is an 80,000 strong force which has steadily grown over the years in
organisation, equipment, operational techniques, attitude and outlook. The Rajasthan Police is
headed by the Director General of Police (DGP). Rajasthan is divided into 2 police
commissionerate, 7 police range each headed by an Inspector General of Police (IGP). The state
is further divided into 40districts (including 3 rural districts, 2 city districts in Jaipur City and 2
railway police districts), 171 circles, 709 police stations and 788 out-posts
Organizational Wings of Rajasthan Police
S.No. Branch Activities
1 Crime Inter-state and inter-district crime
Collection, coalition and dissemination of crime intelligence Matters related to atrocities on weaker sections and women
Coordination with other agencies such as CBI, NCB etc. Matters related to violation of human rights
2 District-Circle-Police Station
Handling citizen complaints
Maintenance of public order
Preliminary investiagtion for complaints
“Design, Development and Implementation of Store Management System (SMS)”
Page 19 of 198
Registration of First Information Reports (FIR)
3 Establishment Postings & Transfers
Promotions & Department
Annual performance appriasals Medals, Merits, Certificates and Rewards Recruitments
Service Matters
Reorganization of police set-up, jurisdictions of field units, creation of police stations and out-posts and revision of strength
4 Planning & Welfare
Provisioning of stores
Matters related to welfare Matters related to police canteens and canteen funds
Matters related to police funds Matters related to police annual group insurance scheme
Matters related to mmodernization
5 Police Telecommunications
All matters related with police telecommuniccations
Publication of police magazines
Technical up-gradation of police including evaluation of needs & requirements and identification of equipments
Preperation and implementation of computerization schemes
6 Rajasthan Armed Constabulary
In 1952, the Government of Rajasthan decided to raise a special force that could not only be deployed along the border but also assist the civil police in combating the dacoity menace. The first headquarters and training centre was established at Bharatpur in 1952 and five battalions received training there. These men, some ex-soldiers drawn from the State forces and some from places outside Rajasthan , were a part of the first 5 battalions of the Rajasthan Armed Constabulary. Each battalion consisted of 6 companies and one company remained at the battalion headquarters. These battalions were then dispatched to the border areas of Sriganganagar, Raisinghnagar, Barmer, and Jaisalmer. One unit was stationed at Ghat Gate, Jaipur to check dacoity.
7 State Special Branch
Internal intelligence
Border Intelligence Counter espionage
Security of VIP and vital installations
Security Training School Matters related to foreigner registration
“Design, Development and Implementation of Store Management System (SMS)”
Page 20 of 198
Crimes related with official secrets act
8 Vigilance Branch
The Vigilance Branch deals with complaints against police officers/personnel regarding non-registration of F.I.R., use of third-degree methods, corruption in police, misconduct which will include drinking on duty and misbehaviour with citizens. On receipt of such complaints inquiries are conducted, relevant records are scrutinized and appropriate departmental action is initiated against the delinquents. The Branch also monitors departmental enquiries, suspension cases, prosecution sanctions, appeals and vigilance clearance for police officers.
Organizational Structure
“Design, Development and Implementation of Store Management System (SMS)”
Page 21 of 198
3. PRE-QUALIFICATION/ ELIGIBILITY CRITERIA
1) A bidder participating in the procurement process shall possess the following minimum pre-
qualification/ eligibility criteria.
S. No.
Basic Requirement
Specific Requirements Documents Required
1 Legal Entity The bidder should be a company registered under Indian Companies Act, 1956
OR A partnership firm registered under Indian Partnership Act, 1932.
- Copy of valid Registration Certificates - Copy of Certificates of incorporation
2 Financial: Turnover from IT/ ITeS
Annual Turnover of the bidder from IT/ ITeS during each of the last three financial years, i.e., from 2011-12 to 2013-14 (as per the last published audited balance sheets), should be at least Rs. 5,00,00,000 (Rupees Five Crores only).
CA Certificate with CA’s Registration Number/ Seal
3 Financial: Net Worth
The net worth of the bidder, as on 31/03/2014 or 31/03/2015, should be Positive.
CA Certificate with CA’s Registration Number/ Seal
4 Technical Capability
The bidder must have successfully completed At least one project of software application
development in e-governance domain executed in India of value not less than Rs. 50,00,000 (Rupees Fifty Lakh Only) during any of the last three financial years i.e. between 2011-12 and 2013-14.
At-least one project in e-governance domain executed in India during last three financial years i.e. between 2011-12 and 2013-14 which includes software application development and hardware supply & installation t. The aggregate value of the project should not be less than Rs. 1,00,00,000 (Rupees One Crore Only)
Annexure-13 per project reference
And Work Completion Certificates from the client;
OR Work Order + Self Certificate of Completion (Certified by the Statutory Auditor);
OR Work Order + Phase Completion Certificate from the client
5 Tax registration and clearance
The bidder should have a registered number of i. VAT/ CST where his business is located ii. Service Tax iii. Income Tax / Pan number. The bidder should have cleared his tax dues up to 31/03/2014 to the Government.
Copies of relevant certificates of registration Tax clearance certificate from the Commercial Taxes Officer of the Circle concerned OR CA Certificate
6 Certifications The bidder must possess, at the time of bidding, a valid CMMi Level 3 Certification.
Copy of a valid certificate
“Design, Development and Implementation of Store Management System (SMS)”
Page 22 of 198
S. No.
Basic Requirement
Specific Requirements Documents Required
7 Mandatory Undertaking
Bidder should: - a) not be insolvent, in receivership, bankrupt or
being wound up, not have its affairs administered by a court or a judicial officer, not have its business activities suspended and must not be the subject of legal proceedings for any of the foregoing reasons;
b) not have, and their directors and officers not have, been convicted of any criminal offence related to their professional conduct or the making of false statements or misrepresentations as to their qualifications to enter into a procurement contract within a period of three years preceding the commencement of the procurement process, or not have been otherwise disqualified pursuant to debarment proceedings;
c) not have a conflict of interest in the procurement in question as specified in the bidding document.
d) comply with the code of integrity as specified in the bidding document.
A Self Certified letter as per Annexure-5: Self-Declaration
8 OEM Authorization
The bidder should have been authorized by respective OEM for distribution/channel partner/retailer of the equipment covered under this RFP. The bidder must attach Manufacturer’s Authorization Certificate and back-to-back support for all the active items to be covered through this tender except for the items which are declared End of Support from respective OEM.
As per Annexure-8
2) In addition to the provisions regarding the qualifications of the bidders as set out in (1) above: -
a. the procuring entity shall disqualify a bidder as per the provisions under “Clause:
Exclusion/ Disqualification of bids in Chapter-5: ITB”; and
b. the procuring entity may require a bidder, who was pre-qualified, to demonstrate its
qualifications again in accordance with the same criteria used to pre-qualify such bidder.
The procuring entity shall disqualify any bidder that fails to demonstrate its qualifications
again, if requested to do so. The procuring entity shall promptly notify each bidder
requested to demonstrate its qualifications again as to whether or not the bidder has done
so to the satisfaction of the procuring entity.
“Design, Development and Implementation of Store Management System (SMS)”
Page 23 of 198
4. SCOPE OF WORK, DELIVERABLES & TIMELINES
For the automation of the existing store management processes at Rajasthan Police Department,
RISL intends to engage with the qualified and competent System Integrator (SI)/Selected bidder
for Design, Development and Implementation of Store Management System (SRS) along with
providing Operation & Maintenance Services for a period of One (1) years from the date of Go
Live of the SMS application. The Selected bidder shall also be responsible for Supply &
Installation of necessary IT Infrastructure (as per Annexure 1: Bill of Material) at various project
locations as mentioned in Annexure 16.
The broad scope of work for the system integrator/successful bidder during the period of contract/
engagement would include (but not limited to): -
Preparation of FRS and SRS
Development of Application software
Integration with Application and Gateways
Testing of the developed application
User Acceptance Testing (UAT)
Assist RISL in Security Audit/safe to Host Certification
Data Digitization and Migration
Supply, installation and commissioning of the requisite IT Infrastructure
Training and Capacity Building
Application Go-Live
Operation & Maintenance of Application
4.1 Preparation of FRS and SRS
4.1.1 Undertake Requirement Gathering, Preparation of Project Documents, Functional Requirement Study (FRS) Document
Carry out study of the existing business processes to thoroughly understand the functional and
operational mechanism and collect requirement from the concerned officer(s) and undertake the
following activities: -
Conducting a detailed assessment of the functional, technical and operational
requirements as per the details mentioned in this bidding document: -
o by interacting with concerned departmental officials
o by reviewing the existing systems, applications (if any), and the departmental
website
Understand/ assess input data and outputs/ reporting requirements
Collect existing forms, registers and report formats
Prepare different use cases scenario
“Design, Development and Implementation of Store Management System (SMS)”
Page 24 of 198
Detailed study of requirements of application components and solutions
Assess existing applications and third party systems from the perspective of integration
with other applications
Prepare FRS detailing both Functional and Non-Functional requirements
Obtaining Sign-off of FRS from the designated authority
The core application modules/ features proposed to be developed and rolled out under the SMS
application are as under:
Demand Management Module
Material Supply and Stock Entry Module
Stock Allotment and Distribution Module
Personnel and Branch Allotment Module
Stock Transfer Module
Employee Transfer Module
Fixed Assets Module
Reporting and Dashboard Module
Workflow Management Module
Master Data Management Module
Other Modules
“Design, Development and Implementation of Store Management System (SMS)”
Page 25 of 198
4.1.2 Preparation of Software Requirement Specification
Prepare SRS and SDD document based on the captured business, functional and
technological requirements and undertake the following activities:
Independent assessment of the requirements of the concerned department / user group
and prepare SRS document
Prepare and maintain various design documents based on principles of modular
approach to develop secure and scalable application software including:
i. Enterprise / Application and Security Architecture Document
ii. Data Flow Diagrams (DFD)
iii. High Level Design (HLD) and Low Level Design Documents(LLD)
4.2 Development of Application software
The Selected bidder shall be responsible for Design, Development, Testing and
Deployment of Store Management System Application based on the approved FRS and
SRS document. The selected bidder shall adhere with the indicative FRS at Annexure-17
and the Technical Specification & Standards at Annexure-2 of this RFP document.
To maintain business continuity the selected bidder shall make use of existing database
cluster (Postgre, SQL Server v9.x, MS SQL, Oracle and MySQL) available at RSDC.
“Design, Development and Implementation of Store Management System (SMS)”
Page 26 of 198
4.3 Integration with Other Applications
Integration of SMS application with other systems is not in the scope of work of this RFP, however,
the selected bidder shall design and develop the SMS application basis open architecture
standards which shall facilitate seamless integration with other applications like payment
gateways, SMS gateway and other third party applications as and when required.
4.4 Testing of the Developed Application
Testing of developed application majorly covering performance, security, load testing and
undertake the following activities: -
Prepare & submit Test Strategy, Test Plan and Test Cases to RISL
Obtaining sign-off on testing approach and plan.
Conducting testing like performance, load, security, quality testing of various components/
modules of the software developed, as per the industry / DEITY standards. The selected
bidder shall be required to share the testing documents and standards with the security
audit team and any other person/organization authorized by the RISL/Rajasthan Police.
4.5 User Acceptance Testing
Prepare detailed UAT plans, schedules, procedures and formats
Submission of detailed FAT/ UAT plans/ schedules/ procedures/ formats.
Obtaining sign-off on testing approach and plan from the designated authority.
Perform Software Testing: Conducting testing of various components/ modules of the
software developed, as per the industry/DEITY standards.
Rectifying the Software issues/ bugs reported during the testing up-to the satisfaction of
RISL/ Rajasthan Police.
During UAT, the developed application shall be deployed in the RSDC Staging Server.
4.6 Security Audit / Safe to Host Certification of developed application
Provide assistance to RISL team in undertaking Security Audit / Safe to Host Certification of the
developed application by third party external agency selected by DoIT&C/RISL and undertake the
following activities:
Ensure developed application is free from Vulnerability / bugs / defects etc. mandatory for
clearing Security Audit / Safe to Host Certification as per the direction of RISL.
Share all the relevant documents like FRS / SRS / Test Cases as required for safe to host
certification.
Incorporate desired changes in the developed application software as suggested
after/during safe to host certification.
Based on the audit reports submitted by the third party external agency, the selected
bidder shall make the required changes to the application at no extra cost.
“Design, Development and Implementation of Store Management System (SMS)”
Page 27 of 198
RISL shall bear the cost of obtaining Security Audit/Save to Host Certification
4.7 Data Digitization and Migration
Selected bidder shall provide manpower for the data digitization and migration. This
includes but not limited to creation of master database, entry of transactional data,
scanning of supporting documents etc.
Selected bidder will develop a migration strategy for migration of digitized data of existing
registers/vouchers/letters etc. to proposed system.
Selected bidder should ensure proper validations, data authenticity, tracking and reporting.
The selected bidder is required to quote Man Month Rate for undertaking Data Digitization
& Migration as part of the financial bid.
The man month effort required for the Data Digitization and Migration activity shall be
mutually decided with the selected bidder during the project study phase, and the same
shall be the basis for the payment to the selected bidder as per the quoted man month rate
Selected bidder is required to obtain Data Digitization & Migration acceptance report from
RISL/Rajasthan Police.
4.8 Deployment and Configuration of Application
Post Safe-To-Host certification, selected bidder will deploy and configure the SMS application at
RSDC.
4.9 Training and Capacity Building
Impart user training at various users’ levels as per the directions of RISL/Department on Train the
Trainer (ToT) basis i.e. to the core team of the Rajasthan Police Department.
Broad activities would include:
Prepare and submit Training Plan and Schedule
Prepare and provide Training Materials, User / Admin Manuals covering all major
instructions for all types of users / roles
Conduct hands-on training on developed application software to the identified set of users
to make them well conversant with the built in functionalities, features and processes.
Training could have multiple sessions as per the need and requirement of the project/
application. Hence, selected bidder shall conduct Training Needs Analysis of all the
concerned staff and drawing up a systematic training plan. The training duration should
be sufficiently long for effecting meaningful assimilation of training content by an average
user. There should be sufficient number of trainers (at least 2) in every training session
for conducting the training program.
“Design, Development and Implementation of Store Management System (SMS)”
Page 28 of 198
The content of the training and schedule shall be mutually decided by Department/ RISL
and the selected bidder later at an appropriate time period. All the training sessions will
be held at Jaipur location.
The requisite training infrastructure like the training room, computers, and projector with
screen shall be provided by RISL/ Rajasthan Police
RISL / Department sahll ensure that employees are available for training as per finalized
training schedule.
In case, after feedback, more than 30% of the respondents suggest that the training
provided to them was unsatisfactory or less than satisfactory then the selected bidder
should re-conduct the same training at no extra cost.
Mentioned below are the indicative no’s of officials to be provided with the training.
S.No. Description of Training
No. of employees to be trained (approx.)
Batch Size No. of batches
No. of session (min 6 hrs) per batch
Total no. of session
1 Hands-on application training
700 20-25 28-35 1 28-35
2 Refresher Training
200 20-25 8-10 1 8-10
4.10 Application Go-Live
Only after the successful completion of section 4.8 and 4.9, the application would be
deemed to have been commissioned.
After the successful commissioning, the system would be declared as Go-Live and enter into
O&M phase and the selected bidder shall also obtain application Go Live certificate by RISL/
Department.
4.11 Operation & Maintenance of the Application
The selected bidder shall provide Operation & Maintenance (O&M) services for Store
Management System (SMS) Application, for a period of One (1) from the date of Go – Iive of the
SMS application Selected bidder shall manage complete operations and maintenance of the
developed application and ensure that the developed application is bug/ error free, running
smoothly and simultaneously incorporate necessary changes in the application functionality as
approved by RISL. Broad activities would include: -
The selected bidder shall provide the following minimum dedicated manpower onsite at
Rajasthan Police, Jaipur for day-to-day operations and maintenance of the overall project
for one year after Go-Live. The selected bidder, if required, with prior permission from
“Design, Development and Implementation of Store Management System (SMS)”
Page 29 of 198
RISL, may also deploy additional manpower for smooth functioning of the project at
RISL/Rajasthan Police office and at no extra cost.
o One Local Support Executive/ Engineer
Minimum qualification for the local support executive/engineer is available at Annexure-
15. Besides, the deployed resource should have enough troubleshooting and
development/coding skills to work upon minor deviations and errors in the application.
The selected bidder, with the help of aforementioned deployed manpower, shall be
responsible for: -
o Overall administration, operations, monitoring, maintenance, MIS generation etc.
of the Application software and to ensure the desired uptime. This would also
include bug fixing, minor changes to the application software, reply to the queries/
feedback/ suggestions/ complaints from all the stakeholders.
o The selected bidder shall maintain version control and archives of source code.
Also, it would be the responsibility of the selected bidder to retain the deployed manpower
for the entire Contract/ Project duration or in the event of a resource leaving the
employment with selected bidder, the same shall be immediately replaced with another
resource of equivalent qualifications and experience. All such events should be notified
prior to RISL.
Selected bidder will provide the deployed manpower with dedicated laptop/desktop.
Rajasthan Police will provide the deployed manpower seating space, necessary furniture,
internet connection, landline phone (if needed) etc.
During and after the end of the project period, the selected bidder shall refrain from
canvassing Rajasthan Police / RISL/ GoR and any of its associates with any claim for
employment of the selected bidder’s personnel deployed under the project.
As Hindi is Official Language of the Government of Rajasthan, the selected bidder has to
appoint personnel having proficiency with Hindi language.
The staff provided by the selected bidder will perform their duties in accordance with the
instructions given by the designated officers of RISL/ Rajasthan Police from time to time.
RISL/ Rajasthan Police will examine the qualification, experience etc. of the personnel
provided before they are deployed. The selected bidder has to take approval from RISL/
Rajasthan Police for the proposed staff before their deployment. RISL/ Rajasthan Police
reserve the right to reject the personnel, if the same is not acceptable, before or after
commencement of the awarded work/ project.
At no time, the provided manpower should be on leave or absent from the duty without
prior permission from the designated nodal officer of Rajasthan Police/RISL. In case of
long term absence due to sickness, leave etc. the selected bidder shall ensure
“Design, Development and Implementation of Store Management System (SMS)”
Page 30 of 198
replacements and manning of all manpower posts without any additional liabilities to
RISL/ Rajasthan Police. Substitute resource will have to be provided by the selected
bidder against the staff proceeding on leave/ or remaining absent and should be of equal
or higher qualifications/ experience.
The proposed services shall be normally manned from 9:30 AM to 6:30 PM but may vary
as per the requirement throughout the project period or as decided by RISL/ Rajasthan
Police.
4.12 Infrastructure Deployment (Supply, Installation and Commissioning of the Hardware Infrastructure)
Selected bidder shall be responsible for the Supply, installation and commissioning of the
IT Infrastructure as per Annexure1: Bill of Material at various designated project locations
as mentioned in Annexure-16.
Selected bidder shall also be required to submit Technical Specification Compliance as
mentioned in Annexure 18: Technical Specification & Standards
The hardware and software supplied under the project should be branded, interoperable,
Unicode 5.1 or higher compliant and IPv6 ready from the day one.
Providing comprehensive onsite OEM warranty for all the supplied products at all the
designated project locations for a period of Three (3) Years from the date of Installation of
the products.
b) Installation, Integration, Testing and Commissioning
The installation, integration, testing and commissioning of PCs and allied equipment,
software, updates, patches etc. at all the project locations.
Obtaining installation, completion and commissioning certificate (Sign-Off) for all project
locations from and duly verified by the respective nodal officer of RISL/Rajasthan Police.
Provide OEM documentation with every unit of the equipment supplied. The language of
the documentation should be in English. The technical documentation should include
illustrated catalogues/ reference manuals/ technical manuals and operation manuals.
4.14 Major Roles & Responsibilities (Stakeholder-wise)
a) Responsibilities of RISL/ Rajasthan Police The role of RISL/ Rajasthan Police in the successful implementation of the Store Management
System includes discharging of the following responsibilities:
To ensure active participation from the Rajasthan Police users
To coordinate with other government agencies.
“Design, Development and Implementation of Store Management System (SMS)”
Page 31 of 198
Review and approve the solution design, implementation approach, and other reports as
submitted by the selected bidder.
To provide necessary support during requirement gathering, sharing of sample reports and
other IT infrastructure requirements
To conduct review meetings at defined regular intervals to monitor the overall progress of
the project.
Provide feedback on changes to be in the solution to improve usability of the application
software.
Report problems/ bugs in solution to the selected bidder for immediate action/ rectification.
Provide the Data Center/ requisite infrastructure required for hosting the developed
application software.
Prioritize the change requests as per project objectives.
Evaluate and approve the effort estimates (for change requests) provided by the selected
bidder for development and deployment of application software.
Co-ordination with the RSDC Operator and other stakeholders of the project.
To ensure timely project milestones sign offs.
Facilitate Acceptance Testing, security audit and performance audit
To approve and oversee the proposed training plan
Set up and administration of escalation mechanism
Review and approve the Payments to the selected bidder as per SLA.
Any other help/ assistance/ co-ordination required for the successful implementation and
operations of the work/ project.
Provide manpower deployed by the selected bidder necessary resources such seating
space, furniture, internet connection, landline phone (if needed) and any other incidental
requirement as mutually decided by the selected bidder and RISL/Rajasthan Police.
Identification of employees who need training and ensure that identified employees receive
training as per agreed schedule.
Provide necessary infrastructure and support for training.
b) Responsibilities of Selected bidder The following are the roles and responsibilities of the selected bidder to be selected for design,
development, testing, implementation and operations & maintenance of the Store Management
System at Rajasthan Police.
To design, develop, test and implement a secure, scalable solution for the Rajasthan
Police
“Design, Development and Implementation of Store Management System (SMS)”
Page 32 of 198
Adopting open, interoperable standards by following international and national industry and
government standards
To prepare and submit the System Requirement Specification (SRS) Report after study of
department processes and functions.
To prepare security level design document with compliance to state/central government IT
policy
To conduct testing not limited to Unit testing, System testing, Integration testing, Load
testing, performance testing
To provide training and workshops to the departmental users at various levels on all the
modules
To provide full documentation of the design, installation and implementation of the software
along with user Training Manuals and other training related documentation
To identify and describe the data entry points in consultation with department to eliminate/
minimize the duplication of data entry
Data digitization and migration as per and mutually defined and agreed terms with
department.
To interface with Project Coordinator, Project Consultant, Data Centre host, Bandwidth
Service Provider etc.
Change Management Plan: Plan for changes to be made to include drawing up a task list,
decide on responsibilities, coordinate with all the affected parties, establish and maintain
communication between parties to identify and mitigate risks, manage the schedule,
execute the change, ensure and manage the change tests and documentation.
Perform User Acceptance Testing
To ensure successful integration of the system with other available applications
To get the security audit done from third party, agency registered with CERT-IN, if desired
To facilitate performance audit by third party, agency registered with state/central
government and selected by department, if needed
Operations & Maintenance of the solution to include: -
(i) Deployment of reporting and monitoring system capable of generating reports for SLA
monitoring.
(ii) System administration, including but not limited to management of users, processes,
preventive maintenance and management of updates & patches to ensure that the
system is properly updated
(iii) Event log analysis generated in all the sub systems including but not limited to
servers, operating systems, databases, applications, security devices, messaging, etc.
ensuring that the logs are backed up and truncated at regular intervals.
“Design, Development and Implementation of Store Management System (SMS)”
Page 33 of 198
(iv) MIS Reports: The shall submit the reports on a regular basis in mutually decided
format and intervals.
(v) To prepare user feedback process and forms for getting feedback on service level
parameters in consultation with Rajasthan Police and conduct user feedback survey at
intervals to be defined by Department.
Helpdesk Support as required
The selected bidder will work in close coordination with the Rajasthan Police and other
stakeholders for this project.
The selected bidder would be required to coordinate with the RISL and Rajasthan Police
for the detail system study and interact with the different user level, wing and cells of the
Rajasthan Police before preparation of final SRS and design documents.
The selected bidder will carry out the activities as indicated in this section of RFP and
submit all the mentioned deliverables within the stipulated time-frame.
The selected bidder will ensure that the time lines will be adhered to. If there are any
perceived slippages on the timelines, the selected bidder would deploy additional
manpower, free of any additional charges.
The selected bidder will ensure compliance with the project SLAs.
The selected bidder will make the best effort to ensure that the quality of deliverables
meets the expectations.
The Selected bidder would get the relevant sections of deliverables, particularly the
deliverables of the Application development / Customization phase, duly verified/ validated
from the concerned Departmental officer / official.
The deliverables will be accepted only if they confirm to the specifications as laid down in
this RFP. Deliverables of the selected bidder will be considered to have been formally
accepted only after the Department communicates so in writing. Any queries regarding the
deliverables will have to be answered by the selected bidder within 5 working days.
The selected bidder will share all intermediate documents, drafts, reports, surveys and any
other item related to this assignment. No work products, methodology or any other
methods used by the selected bidder should be deemed as proprietary and non-shareable.
The selected bidder would submit hardcopies and softcopies of all the deliverables to
Department as per timelines specified in the RFP.
Bidder would be required to coordinate with the State Nodal Agency for RSDC.
Bidder would be required to coordinate with the State NIC and treasury for Central / State
computerization initiatives.
bidder would provide the manpower deployed at Rajasthan Police offices with
laptop/desktop needed as per his/her routine work.
“Design, Development and Implementation of Store Management System (SMS)”
Page 34 of 198
4.15 Project Milestones, Deliverables and Time Schedule
The milestones, deliverables and time schedule for the implementation of Store Management
System (SMS) project would be as follows:
The time specified completion of activities as mentioned in the table below shall be deemed to
be the essence of the contract and the selected bidder shall arrange supplies and provide the
required services within the specified period.
It should be noted that any delay in the project timelines shall attract Liquidated Damages to
the selected bidder as per the details mentioned in subsequent sections of this RFP
document.
T is the event of issuance of Work Order to the selected bidder.
S.No. Milestones Project Deliverables Timelines
1 Undertaking activities as mentioned in Scope of Work section 4.1
FRS & SRS Document Approval of FRS & SRS by RISL
T + 45 days
2
Undertaking activities as mentioned in Scope of Work section 4.2, 4.4, 4.6, 4.7 and 4.8
Configuration & Deployment document with source code in two sets of DVDs along with source code and/or license of third party API/any other software used.
Test cases and Test report. Data Digitization & Migration
Acceptance Report.
T + 105 days
3
Undertaking activities as mentioned in Scope of Work section 4.5, 4.6, 4.8, 4.12
UAT Sign Off Certificate From RISL/Department
Hardware supply and commissioning report
T + 130 days
4 Undertaking activities as mentioned in Scope of Work section 4.9 and 4.10
User Manual, Training documentation, Hand-outs
Training Completion Certificate Certificate for Go-Live by RISL
T + 145 days
5 Undertaking activities as mentioned in Scope of Work section 4.11
Quarterly SLA Attainment Reports
For a period of 1 year from the date of Go Live of the Application
Note:
Deliverables/ Reports, if any, mentioned elsewhere in this RFP document would also be
accounted for while ascertaining the successful completion of the respective Phase of the
project and selected bidder would submit the same as per the requirement of RISL/
Rajasthan Police.
“Design, Development and Implementation of Store Management System (SMS)”
Page 35 of 198
Remark: The above mentioned delivery schedule shall be applicable subject to fulfilment of
obligations by RISL/department for respective milestone, wherever applicable. In case of
delay in action taken by RISL, same number of days would be added in the delivery period.
Any delay in the approval of the deliverable(s) submitted by the selected bidder to RISL/
Rajasthan Police shall not account for the delay selected bidder’s part. The supply of
requisite Hardware at all the designated project locations shall commence only after the
successful UAT of the Application as the hardware would be of no use, if the application is
not accepted by RISL/ Rajasthan Police.
“Design, Development and Implementation of Store Management System (SMS)”
Page 36 of 198
5. INSTRUCTION TO BIDDERS (ITB)
5.1 Sale of Bidding/ Tender Documents a) The sale of bidding documents shall be commenced from the date of publication of Notice
Inviting Bids (NIB) and shall be stopped one day prior to the date of opening of Bid. The
complete bidding document shall also be placed on the State Public Procurement Portal
and e-Procurement portal. The prospective bidders shall be permitted to download the
bidding document from the websites and pay its price while submitting the Bid to the
procuring entity.
b) The bidding documents shall be made available to any prospective bidder who pays the
price for it in cash or by bank demand draft, banker's cheque.
c) Bidding documents purchased by Principal of any concern may be used by its authorised
sole selling agents/ marketing agents/ distributors/ sub-distributors and authorised dealers
or vice versa.
5.2 Pre-bid Meeting/ Clarifications a) Any prospective bidder may, in writing, seek clarifications from the procuring entity in
respect of the bidding documents.
b) A pre-bid conference is also scheduled by the procuring entity as per the details mentioned
in the NIB and to clarify doubts of potential bidders in respect of the procurement and the
records of such conference shall be intimated to all bidders and where applicable, shall be
published on the respective websites.
c) The period within which the bidders may seek clarifications under (a) above and the period
within which the procuring entity shall respond to such requests for clarifications shall be as
under: -
a. Last date of submitting clarifications requests by the bidder: as per NIB
b. Response to clarifications by procuring entity: as per NIB
d) The minutes and response, if any, shall be provided promptly to all bidders to which the
procuring entity provided the bidding documents, so as to enable those bidders to take
minutes into account in preparing their bids, and shall be published on the respective
websites.
5.3 Changes in the Bidding Document a) At any time, prior to the deadline for submission of Bids, the procuring entity may for any
reason, whether on its own initiative or as a result of a request for clarification by a bidder,
modify the bidding documents by issuing an addendum in accordance with the provisions
below.
b) In case, any modification is made to the bidding document or any clarification is issued
which materially affects the terms contained in the bidding document, the procuring entity
“Design, Development and Implementation of Store Management System (SMS)”
Page 37 of 198
shall publish such modification or clarification in the same manner as the publication of the
initial bidding document.
c) In case, a clarification or modification is issued to the bidding document, the procuring
entity may, prior to the last date for submission of Bids, extend such time limit in order to
allow the bidders sufficient time to take into account the clarification or modification, as the
case may be, while submitting their Bids.
d) Any bidder, who has submitted his Bid in response to the original invitation, shall have the
opportunity to modify or re-submit it, as the case may be, within the period of time originally
allotted or such extended time as may be allowed for submission of Bids, when changes
are made to the bidding document by the procuring entity:
Provided that the Bid last submitted or the Bid as modified by the bidder shall be
considered for evaluation.
5.4 Period of Validity of Bids a) Bids submitted by the bidders shall remain valid during the period specified in the NIB/
bidding document. A Bid valid for a shorter period shall be rejected by the procuring entity
as non-responsive Bid.
b) Prior to the expiry of the period of validity of Bids, the procuring entity, in exceptional
circumstances, may request the bidders to extend the bid validity period for an
additional specified period of time. A bidder may refuse the request and such refusal shall
be treated as withdrawal of Bid and in such circumstances bid security shall not be
forfeited.
c) Bidders that agree to an extension of the period of validity of their Bids shall extend or get
extended the period of validity of bid securities submitted by them or submit new bid
securities to cover the extended period of validity of their bids. A bidder whose bid security
is not extended, or that has not submitted a new bid security, is considered to have refused
the request to extend the period of validity of its Bid.
5.5 Format and Signing of Bids a) Bidders must submit their bids online at e-Procurement portal i.e.
http://eproc.rajasthan.gov.in.
b) All the documents uploaded should be digitally signed with the DSC of authorized
signatory.
c) A Single stage- Two part/ cover system shall be followed for the Bid: -
a. Technical Bid, including fee details, eligibility & technical documents
b. Financial Bid
d) The technical bid shall consist of the following documents: -
“Design, Development and Implementation of Store Management System (SMS)”
Page 38 of 198
S. No.
Documents Type Document Format
Fee Details 1. Bidding document Fee (Tender Fee) Proof of submission (PDF) 2. RISL Processing Fee (e-Procurement) Instrument/ Proof of submission
(PDF) 3. Bid Security Instrument/ Proof of submission
(PDF) Eligibility Documents
4. Bidder’s Authorisation Certificate As per Annexure-4 5. All the documents mentioned in the
“Eligibility Criteria”, in support of the eligibility
As per the format mentioned against the respective eligibility criteria clause (PDF)
Technical Documents 6. Certificate of Conformity/ No Deviation As per Annexure-6 7. Declaration by Bidders As per Annexure-7 8. Manufacturer’s Authorisation Form (MAF) As per Annexure-8 (Indicative
Format) 9. Undertaking on Authenticity of Comp.
Equip. As per Annexure-9
10. Technical Specifications Compliance As per Annexure - 18
b) Financial bid shall include the following documents: -
S. No.
Documents Type Document Format
1. Financial Bid – Cover Letter On bidder’s letter head duly signed by authorized signatory as per Annexure- 10
2. Financial Bid - Format As per BoQ (.XLS) format available on e-Procurement portal
c) The bidder should ensure that all the required documents, as mentioned in this bidding
document, are submitted along with the Bid and in the prescribed format only. Non-
submission of the required documents or submission of the documents in a different
format/ contents may lead to the rejections of the Bid submitted by the bidder.
5.6 Cost & Language of Bidding a) The Bidder shall bear all costs associated with the preparation and submission of its Bid,
and the procuring entity shall not be responsible or liable for those costs, regardless of the
conduct or outcome of the bidding process.
b) The Bid, as well as all correspondence and documents relating to the Bid exchanged by
the bidder and the procuring entity, shall be written only in English Language. Supporting
documents and printed literature that are part of the Bid may be in another language
provided they are accompanied by an accurate translation of the relevant passages in
English/ Hindi language, in which case, for purposes of interpretation of the Bid, such
translation shall govern.
“Design, Development and Implementation of Store Management System (SMS)”
Page 39 of 198
5.7 Alternative/ Multiple Bids
Alternative/ Multiple Bids shall not be considered at all. Also, the bidder shall not quote for
multiple brands/ make/ models but only one in the technical Bid.
5.8 Bid Security
Every bidder, if not exempted, participating in the procurement process will be required to
furnish the bid security as specified in the NIB.
a) In lieu of bid security, a bid securing declaration shall be taken from Departments of the
State Government, Undertakings, Corporations, Autonomous bodies, Registered Societies
and Cooperative Societies which are owned or controlled or managed by the State
Government and Government Undertakings of the Central Government.
b) Bid security instrument of bid security or a bid securing declaration shall necessarily
accompany the technical bid.
c) Bid security of a bidder lying with the procuring entity in respect of other bids awaiting
decision shall not be adjusted towards bid security for the fresh bids. The bid security
originally deposited may, however, be taken into consideration in case bids are re-invited.
d) The bid security may be given in the form of a banker’s cheque or demand draft, in
specified format, of a scheduled bank. The bid security must remain valid thirty days
beyond the original or extended validity period of the bid.
e) The issuer of the bid security and the confirmer, if any, of the bid security, as well as the
form and terms of the bid security, must be acceptable to the procuring entity.
f) Prior to presenting a submission, a bidder may request the procuring entity to confirm the
acceptability of proposed issuer of a bid security or of a proposed confirmer, if required.
The procuring entity shall respond promptly to such a request.
g) The bank guarantee presented as bid security shall be got confirmed from the concerned
issuing bank. However, the confirmation of the acceptability of a proposed issuer or of any
proposed confirmer does not preclude the procuring entity from rejecting the bid security
on the ground that the issuer or the confirmer, as the case may be, has become insolvent
or has otherwise ceased to be creditworthy.
h) The bid security of unsuccessful bidders shall be refunded soon after final acceptance of
successful bid and signing of Agreement and submitting performance security.
i) The Bid security taken from a bidder shall be forfeited, including the interest, if any, in the
following cases, namely: -
a. when the bidder withdraws or modifies its bid after opening of bids;
b. when the bidder does not execute the agreement, if any, after placement of supply/
work order within the specified period;
“Design, Development and Implementation of Store Management System (SMS)”
Page 40 of 198
c. when the bidder fails to commence the supply of the goods or service or execute work
as per supply/ work order within the time specified;
d. when the bidder does not deposit the performance security within specified period after
the supply/ work order is placed; and
e. if the bidder breaches any provision of code of integrity, prescribed for bidders,
specified in the bidding document.
j) Notice will be given to the bidder with reasonable time before bid security deposited is
forfeited.
k) No interest shall be payable on the bid security.
l) In case of the successful bidder, the amount of bid security may be adjusted in arriving at
the amount of the Performance Security, or refunded if the selected bidder furnishes the
full amount of performance security.
m) The procuring entity shall promptly return the bid security after the earliest of the following
events, namely:-
a. the expiry of validity of bid security;
b. the execution of agreement for procurement and performance security is furnished by
the selected bidder;
c. the cancellation of the procurement process; or
d. the withdrawal of bid prior to the deadline for presenting bids, unless the bidding
documents stipulate that no such withdrawal is permitted.
5.9 Deadline for the submission of Bids a) Bids shall be received online at e-Procurement portal and up to the time and date specified
in the NIB.
b) Normally, the date of submission and opening of Bids would not be extended. In
exceptional circumstances or when the bidding document are required to be substantially
modified as a result of discussions in pre-bid meeting/ conference or otherwise and the
time with the prospective bidders for preparation of Bids appears insufficient, the date may
be extended by the procuring entity. In such case the publicity of extended time and date
shall be given in the manner, as was given at the time of issuing the original NIB and shall
also be placed on the State Public Procurement Portal, if applicable. It would be ensured
that after issue of corrigendum, reasonable time is available to the bidders for preparation
and submission of their Bids. The procuring entity shall also publish such modifications in
the bidding document in the same manner as the publication of initial bidding document. If,
in the office of the Bids receiving and opening authority, the last date of submission or
opening of Bids is a non-working day, the Bids shall be received or opened on the next
working day.
“Design, Development and Implementation of Store Management System (SMS)”
Page 41 of 198
5.10 Withdrawal, Substitution, and Modification of Bids a) If permitted on e-Procurement portal, a bidder may withdraw its Bid or re-submit its Bid
(technical and/ or financial cover) as per the instructions/ procedure mentioned at e-
Procurement website under the section "Bidder's Manual Kit".
b) Bids withdrawn shall not be opened and processes further.
5.11 Opening of Bids a) The Bids shall be opened by the bid opening & evaluation committee on the date and time
mentioned in the NIB in the presence of the bidders or their authorised representatives
who choose to be present.
b) The committee may co-opt experienced persons in the committee to conduct the process
of Bid opening.
c) The committee shall prepare a list of the bidders or their representatives attending the
opening of Bids and obtain their signatures on the same. The list shall also contain the
representative’s name and telephone number and corresponding bidders’ names and
addresses. The authority letters, if any, brought by the representatives shall be attached to
the list. The list shall be signed by all the members of Bid opening committee with date and
time of opening of the Bids.
d) All the documents comprising of technical Bid/ cover shall be opened & downloaded from
the e-Procurement website (only for the bidders who have submitted the prescribed fee(s)
to RISL).
e) The committee shall conduct a preliminary scrutiny of the opened technical Bids to assess
the prima-facie responsiveness and ensure that the: -
a. bid is accompanied by bidding document fee, bid security or bid securing declaration,
and processing fee (if applicable);
b. bid is valid for the period, specified in the bidding document;
c. bid is unconditional and the bidder has agreed to give the required performance
security; and
d. other conditions, as specified in the bidding document are fulfilled.
e. any other information which the committee may consider appropriate.
f) No Bid shall be rejected at the time of Bid opening except the Bids not accompanied with
the proof of payment or instrument of the required price of bidding document, processing
fee and bid security.
g) The Financial Bid cover shall be kept unopened and shall be opened later on the date and
time intimated to the bidders who qualify in the evaluation of technical Bids.
5.12 Selection Method:
The selection method is Least Cost Based Selection (LCBS or L1).
“Design, Development and Implementation of Store Management System (SMS)”
Page 42 of 198
5.13 Clarification of Bids a) To assist in the examination, evaluation, comparison and qualification of the Bids, the bid
evaluation committee may, at its discretion, ask any bidder for a clarification regarding its
Bid. The committee's request for clarification and the response of the bidder shall be
through the e-Procurement portal.
b) Any clarification submitted by a bidder with regard to its Bid that is not in response to a
request by the committee shall not be considered.
c) No change in the prices or substance of the Bid shall be sought, offered, or permitted,
except to confirm the correction of arithmetic errors discovered by the committee in the
evaluation of the financial Bids.
d) No substantive change to qualification information or to a submission, including changes
aimed at making an unqualified bidder, qualified or an unresponsive submission,
responsive shall be sought, offered or permitted.
5.14 Evaluation & Tabulation of Technical Bids a) Determination of Responsiveness
a. The bid evaluation committee shall determine the responsiveness of a Bid on the basis
of bidding document and the provisions of pre-qualification/ eligibility criteria of the
bidding document.
b. A responsive Bid is one that meets the requirements of the bidding document without
any material deviation, reservation, or omission where: -
i. “deviation” is a departure from the requirements specified in the bidding document;
ii. “reservation” is the setting of limiting conditions or withholding from complete
acceptance of the requirements specified in the bidding document; and
iii. “Omission” is the failure to submit part or all of the information or documentation
required in the bidding document.
c. A material deviation, reservation, or omission is one that,
i. if accepted, shall:-
1. affect in any substantial way the scope, quality, or performance of the subject
matter of procurement specified in the bidding documents; or
2. limits in any substantial way, inconsistent with the bidding documents, the
procuring entity’s rights or the bidder’s obligations under the proposed contract;
or
ii. if rectified, shall unfairly affect the competitive position of other bidders presenting
responsive Bids.
“Design, Development and Implementation of Store Management System (SMS)”
Page 43 of 198
d. The bid evaluation committee shall examine the technical aspects of the Bid in
particular, to confirm that all requirements of bidding document have been met without
any material deviation, reservation or omission.
e. The procuring entity shall regard a Bid as responsive if it conforms to all requirements
set out in the bidding document, or it contains minor deviations that do not materially
alter or depart from the characteristics, terms, conditions and other requirements set
out in the bidding document, or if it contains errors or oversights that can be corrected
without touching on the substance of the Bid.
b) Non-material Non-conformities in Bids a. The bid evaluation committee may waive any non-conformities in the Bid that do not
constitute a material deviation, reservation or omission, the Bid shall be deemed to be
substantially responsive.
b. The bid evaluation committee may request the bidder to submit the necessary
information or document like audited statement of accounts/ CA Certificate,
Registration Certificate, VAT/ CST clearance certificate, ISO/ CMMi Certificates, etc.
within a reasonable period of time. Failure of the bidder to comply with the request
may result in the rejection of its Bid.
c. The bid evaluation committee may rectify non-material nonconformities or omissions on
the basis of the information or documentation received from the bidder under (b)
above.
c) Tabulation of Technical Bids a. If Technical Bids have been invited, they shall be tabulated by the bid evaluation
committee in the form of a comparative statement to evaluate the qualification of the
bidders against the criteria for qualification set out in the bidding document.
b. The members of bid evaluation committee shall give their recommendations below the
table as to which of the bidders have been found to be qualified in evaluation of
Technical Bids and sign it.
d) The number of firms qualified in technical evaluation, if less than three and it is considered
necessary by the procuring entity to continue with the procurement process, reasons shall
be recorded in writing and included in the record of the procurement proceedings.
e) The bidders who qualified in the technical evaluation shall be informed in writing about the
date, time and place of opening of their financial Bids.
5.15 Evaluation & Tabulation of Financial Bids
Subject to the provisions of “Acceptance of Successful Bid and Award of Contract” below, the
procuring entity shall take following actions for evaluation of financial Bids:-
“Design, Development and Implementation of Store Management System (SMS)”
Page 44 of 198
a) Financial Bids of the bidders who qualified in technical evaluation shall be opened online at
the notified time, date and place by the bid evaluation committee in the presence of the
bidders or their representatives who choose to be present;
b) the process of opening of the financial Bids shall be similar to that of technical Bids.
c) the names of the bidders, the rates given by them and conditions put, if any, shall be read
out and recorded;
d) conditional Bids are liable to be rejected;
e) the evaluation shall include all costs and all taxes and duties applicable to the bidder as
per law of the Central/ State Government/ Local Authorities, and the evaluation criteria
specified in the bidding documents shall only be applied;
f) the offers shall be evaluated and marked L1, L2, L3 etc. L1 being the lowest offer and then
others in ascending order in case price is the only criteria, or evaluated and marked H1,
H2, H3 etc. in descending order.
g) the bid evaluation committee shall prepare a comparative statement in tabular form in
accordance with rules along with its report on evaluation of financial Bids and recommend
the lowest offer for acceptance to the procuring entity, if price is the only criterion, or most
advantageous Bid in other case;
h) The members of bids evaluation committee shall give their recommendations below the
table regarding lowest Bid or most advantageous Bid and sign it.
i) it shall be ensured that the offer recommended for sanction is justifiable looking to the
prevailing market rates of the goods, works or service required to be procured.
5.16 Correction of Arithmetic Errors in Financial Bids
The bid evaluation committee shall correct arithmetical errors in substantially responsive Bids,
on the following basis, namely: -
a) if there is a discrepancy between the unit price and the total price that is obtained by
multiplying the unit price and quantity, the unit price shall prevail and the total price shall
be corrected, unless in the opinion of the bid evaluation committee 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 shall be corrected;
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 clause (a) and (b) above.
5.17 Comparison of rates of firms outside and those in Rajasthan
“Design, Development and Implementation of Store Management System (SMS)”
Page 45 of 198
While tabulating the financial Bids of those firms which are not entitled to price preference, the
element of Rajasthan Value Added Tax (RVAT) shall be excluded from the rates quoted by the
firms of Rajasthan and the element of Central Sales Tax (CST) shall be included in the rates of
firms from outside Rajasthan for financial bid evaluation purpose.
5.18 Price/ purchase preference in evaluation
Price and/ or purchase preference notified by the State Government (GoR) and as mentioned
in the bidding document shall be considered in the evaluation of Bids and award of contract.
5.19 Negotiations a) Except in case of procurement by method of single source procurement or procurement by
competitive negotiations, to the extent possible, no negotiations shall be conducted after
the pre-bid stage. All clarifications needed to be sought shall be sought in the pre-bid stage
itself.
b) Negotiations may, however, be undertaken only with the lowest or most advantageous
bidder when the rates are considered to be much higher than the prevailing market rates.
c) The bid evaluation committee shall have full powers to undertake negotiations. Detailed
reasons and results of negotiations shall be recorded in the proceedings.
d) The lowest or most advantageous bidder shall be informed in writing either through
messenger or by registered letter and e-mail (if available). A minimum time of seven days
shall be given for calling negotiations. In case of urgency the bid evaluation committee,
after recording reasons, may reduce the time, provided the lowest or most advantageous
bidder has received the intimation and consented to regarding holding of negotiations.
e) Negotiations shall not make the original offer made by the bidder inoperative. The bid
evaluation committee shall have option to consider the original offer in case the bidder
decides to increase rates originally quoted or imposes any new terms or conditions.
f) In case of non-satisfactory achievement of rates from lowest or most advantageous bidder,
the bid evaluation committee may choose to make a written counter offer to the lowest or
most advantageous bidder and if this is not accepted by him, the committee may decide to
reject and re-invite Bids or to make the same counter-offer first to the second lowest or
most advantageous bidder, then to the third lowest or most advantageous bidder and so on
in the order of their initial standing and work/ supply order be awarded to the bidder who
accepts the counter-offer. This procedure would be used in exceptional cases only.
g) In case the rates even after the negotiations are considered very high, fresh Bids shall be
invited.
5.20 Exclusion of Bids/ Disqualification a) A procuring entity shall exclude/ disqualify a Bid, if: -
“Design, Development and Implementation of Store Management System (SMS)”
Page 46 of 198
a. the information submitted, concerning the qualifications of the bidder, was false or
constituted a misrepresentation; or
b. the information submitted, concerning the qualifications of the bidder, was materially
inaccurate or incomplete; and
c. the bidder is not qualified as per pre-qualification/ eligibility criteria mentioned in the
bidding document;
d. the Bid materially departs from the requirements specified in the bidding document or it
contains false information;
e. the bidder, submitting the Bid, his agent or any one acting on his behalf, gave or
agreed to give, to any officer or employee of the procuring entity or other governmental
authority a gratification in any form, or any other thing of value, so as to unduly
influence the procurement process;
f. a bidder, in the opinion of the procuring entity, has a conflict of interest materially
affecting fair competition.
b) A Bid shall be excluded/ disqualified as soon as the cause for its exclusion/ disqualification
is discovered.
c) Every decision of a procuring entity to exclude a Bid shall be for reasons to be recorded in
writing and shall be: -
a. communicated to the concerned bidder in writing;
b. published on the State Public Procurement Portal, if applicable.
5.21 Lack of competition a) A situation may arise where, if after evaluation of Bids, the bid evaluation committee may
end-up with one responsive Bid only. In such situation, the bid evaluation committee would
check as to whether while floating the NIB all necessary requirements to encourage
competition like standard bid conditions, industry friendly specifications, wide publicity,
sufficient time for formulation of Bids, etc were fulfilled. If not, the NIB would be re-floated
after rectifying deficiencies. The bid process shall be considered valid even if there is one
responsive Bid, provided that: -
a. the Bid is technically qualified;
b. the price quoted by the bidder is assessed to be reasonable;
c. the Bid is unconditional and complete in all respects;
d. there are no obvious indicators of cartelization amongst bidders; and
e. the bidder is qualified as per the provisions of pre-qualification/ eligibility criteria in the
bidding document
b) The bid evaluation committee shall prepare a justification note for approval by the next
higher authority of the procuring entity, with the concurrence of the accounts member.
“Design, Development and Implementation of Store Management System (SMS)”
Page 47 of 198
c) In case of dissent by any member of bid evaluation committee, the next higher authority in
delegation of financial powers shall decide as to whether to sanction the single Bid or re-
invite Bids after recording reasons.
d) If a decision to re-invite the Bids is taken, market assessment shall be carried out for
estimation of market depth, eligibility criteria and cost estimate.
5.22 Acceptance of the successful Bid and award of contract a) The procuring entity after considering the recommendations of the bid evaluation
committee and the conditions of Bid, if any, financial implications, trials, sample testing and
test reports, etc., shall accept or reject the successful Bid. If any member of the bid
evaluation committee, has disagreed or given its note of dissent, the matter shall be
referred to the next higher authority, as per delegation of financial powers, for decision.
b) Decision on Bids shall be taken within original validity period of Bids and time period
allowed to procuring entity for taking decision. If the decision is not taken within the original
validity period or time limit allowed for taking decision, the matter shall be referred to the
next higher authority in delegation of financial powers for decision.
c) Before award of the contract, the procuring entity shall ensure that the price of successful
Bid is reasonable and consistent with the required quality.
d) A Bid shall be treated as successful only after the competent authority has approved the
procurement in terms of that Bid.
e) The procuring entity shall award the contract to the bidder whose offer has been
determined to be the lowest or most advantageous in accordance with the evaluation
criteria set out in the bidding document and if the bidder has been determined to be
qualified to perform the contract satisfactorily on the basis of qualification criteria fixed for
the bidders in the bidding document for the subject matter of procurement.
f) Prior to the expiration of the period of bid validity, the procuring entity shall inform the
successful bidder, in writing, that its Bid has been accepted.
g) As soon as a Bid is accepted by the competent authority, its written intimation shall be sent
to the concerned bidder by registered post or email and asked to execute an agreement in
the format given in the bidding documents on a non-judicial stamp of requisite value and
deposit the amount of performance security or a performance security declaration, if
applicable, within a period specified in the bidding documents or where the period is not
specified in the bidding documents then within fifteen days from the date on which the
letter of acceptance or letter of intent is dispatched to the bidder.
h) If the issuance of formal letter of acceptance is likely to take time, in the meanwhile a Letter
of Intent (LOI) may be sent to the bidder. The acceptance of an offer is complete as soon
as the letter of acceptance or letter of intent is posted and/ or sent by email (if available) to
“Design, Development and Implementation of Store Management System (SMS)”
Page 48 of 198
the address of the bidder given in the bidding document. Until a formal contract is
executed, the letter of acceptance or LOI shall constitute a binding contract.
i) The bid security of the bidders who’s Bids could not be accepted shall be refunded soon
after the contract with the successful bidder is signed and its performance security is
obtained.
5.23 Information and publication of award
Information of award of contract shall be communicated to all participating bidders and
published on the respective website(s) as specified in NIB.
5.24 Procuring entity’s right to accept or reject any or all Bids
The Procuring entity reserves the right to accept or reject any Bid, and to annul (cancel) the
bidding process and reject all Bids at any time prior to award of contract, without thereby
incurring any liability to the bidders.
5.25 Right to vary quantity a) If the procuring entity does not procure any subject matter of procurement or procures less
than the quantity specified in the bidding documents due to change in circumstances,
the bidder shall not be entitled for any claim or compensation.
b) Repeat orders for extra items or additional quantities may be placed on the rates and
conditions given in the contract. Delivery or completion period may also be proportionately
increased. The limits of repeat order shall be as under: -
a. 50% of the quantity of the individual items and 50% of the value of original contract in
case of works; and
b. 50% of the value of goods or services of the original contract.
5.26 Performance Security a) Prior to execution of agreement, Performance security shall be solicited from all successful
bidders except the departments of the State Government and undertakings, corporations,
autonomous bodies, registered societies, co-operative societies which are owned or
controlled or managed by the State Government and undertakings of the Central
Government. However, a performance security declaration shall be taken from them. The
State Government may relax the provision of performance security in particular
procurement or any class of procurement.
b) The amount of performance security shall be 5% of the amount of supply order in case of
procurement of goods and services. In case of Small Scale Industries (SSI) of Rajasthan, it
shall be 1% of the amount of quantity ordered for supply of goods and in case of sick
industries, other than SSI, whose cases are pending before the Board of Industrial and
Financial Reconstruction (BIFR), it shall be 2% of the amount of supply order.
c) Performance security shall be furnished in any one of the following forms: -
“Design, Development and Implementation of Store Management System (SMS)”
Page 49 of 198
a. Demand Draft or Banker's Cheque of a scheduled bank;
b. National Savings Certificates and any other script/ instrument under
National Savings Schemes for promotion of small savings issued by a Post Office
in Rajasthan, if the same can be pledged under the relevant rules. They shall be
accepted at their surrender value at the time of bid and formally transferred in the
name of procuring entity with the approval of Head Post Master;
c. Fixed Deposit Receipt (FDR) of a scheduled bank. It shall be in the name of
procuring entity on account of bidder and discharged by the bidder in advance. The
procuring entity shall ensure before accepting the FDR that the bidder furnishes an
undertaking from the bank to make payment/ premature payment of the FDR on
demand to the procuring entity without requirement of consent of the bidder
concerned. In the event of forfeiture of the performance security, the Fixed Deposit
shall be forfeited along with interest earned on such Fixed Deposit.
d) Performance security furnished in the form specified in clause [b.] to [e.] of (c) above shall
remain valid for a period of 60 days beyond the date of completion of all contractual
obligations of the bidder, including warranty obligations and maintenance and defect
liability period.
e) Forfeiture of Security Deposit: Security amount in full or part may be forfeited, including
interest, if any, in the following cases:-
a. When any terms and condition of the contract is breached.
b. When the selected bidder fails to make complete supply satisfactorily.
c. if the selected bidder breaches any provision of code of integrity, prescribed for
bidders, specified in the bidding document.
f) Notice will be given to the selected bidder with reasonable time before PSD deposited is
forfeited.
g) No interest shall be payable on the PSD.
5.27 Execution of agreement a) A procurement contract shall come into force from the date on which the letter of
acceptance/ letter of intent or PO is despatched to the selected bidder.
b) The successful bidder shall sign the procurement contract within 15 days from the date on
which the letter of acceptance or letter of intent is despatched to the successful bidder.
c) If the bidder, who’s Bid has been accepted, fails to sign a written procurement contract or
fails to furnish the required performance security within specified period, the procuring
entity shall take action against the successful bidder as per the provisions of the bidding
document and Act. The procuring entity may, in such case, cancel the procurement
process or if it deems fit, offer for acceptance the rates of lowest or most advantageous
“Design, Development and Implementation of Store Management System (SMS)”
Page 50 of 198
bidder to the next lowest or most advantageous bidder, in accordance with the criteria and
procedures set out in the bidding document.
d) The bidder will be required to execute the agreement on a non-judicial stamp of specified
value at its cost and to be purchase from anywhere in Rajasthan only.
5.28 Confidentiality a) Notwithstanding anything contained in this bidding document but subject to the provisions
of any other law for the time being in force providing for disclosure of information, a
procuring entity shall not disclose any information if such disclosure, in its opinion, is likely
to: -
a. impede enforcement of any law;
b. affect the security or strategic interests of India;
c. affect the intellectual property rights or legitimate commercial interests of bidders;
d. affect the legitimate commercial interests of the procuring entity in situations that may
include when the procurement relates to a project in which the procuring entity is to
make a competitive bid, or the intellectual property rights of the procuring entity.
b) The procuring entity shall treat all communications with bidders related to the procurement
process in such manner as to avoid their disclosure to competing bidders or to any other
person not authorised to have access to such information.
c) The procuring entity may impose on bidders and sub-contractors, if there are any for
fulfilling the terms of the procurement contract, conditions aimed at protecting information,
the disclosure of which violates (a) above.
d) In addition to the restrictions specified above, the procuring entity, while procuring a
subject matter of such nature which requires the procuring entity to maintain confidentiality,
may impose condition for protecting confidentiality of such information.
5.29 Cancellation of procurement process a) If any procurement process has been cancelled, it shall not be reopened but it shall not
prevent the procuring entity from initiating a new procurement process for the same subject
matter of procurement, if required.
b) A procuring entity may, for reasons to be recorded in writing, cancel the process of
procurement initiated by it -
a. at any time prior to the acceptance of the successful Bid; or
b. after the successful Bid is accepted in accordance with (d) and (e) below.
c) The procuring entity shall not open any bids or proposals after taking a decision to cancel
the procurement and shall return such unopened bids or proposals.
“Design, Development and Implementation of Store Management System (SMS)”
Page 51 of 198
d) The decision of the procuring entity to cancel the procurement and reasons for such
decision shall be immediately communicated to all bidders that participated in the
procurement process.
e) If the bidder who’s Bid has been accepted as successful fails to sign any written
procurement contract as required, or fails to provide any required security for the
performance of the contract, the procuring entity may cancel the procurement process.
f) If a bidder is convicted of any offence under the Act, the procuring entity may: -
a. cancel the relevant procurement process if the Bid of the convicted bidder has been
declared as successful but no procurement contract has been entered into;
b. rescind (cancel) the relevant contract or forfeit the payment of all or a part of the
contract value if the procurement contract has been entered into between the procuring
entity and the convicted bidder.
5.30 Code of Integrity for Bidders a) No person participating in a procurement process shall act in contravention of the code of
integrity prescribed by the State Government.
b) The code of integrity include provisions for: -
a. Prohibiting
i. any offer, solicitation or acceptance of any bribe, reward or gift or any material
benefit, either directly or indirectly, in exchange for an unfair advantage in the
procurement process or to otherwise influence the procurement process;
ii. any omission, including a misrepresentation that misleads or attempts to mislead
so as to obtain a financial or other benefit or avoid an obligation;
iii. any collusion, bid rigging or anti-competitive behaviour to impair the transparency,
fairness and progress of the procurement process;
iv. improper use of information shared between the procuring entity and the bidders
with an intent to gain unfair advantage in the procurement process or for personal
gain;
v. any financial or business transactions between the bidder and any officer or
employee of the procuring entity;
vi. any coercion including impairing or harming or threatening to do the same, directly
or indirectly, to any party or to its property to influence the procurement process;
vii. any obstruction of any investigation or audit of a procurement process;
b. disclosure of conflict of interest;
c. disclosure by the bidder of any previous transgressions with any entity in India or any
other country during the last three years or of any debarment by any other procuring
entity.
“Design, Development and Implementation of Store Management System (SMS)”
Page 52 of 198
c) Without prejudice to the provisions below, in case of any breach of the code of integrity by
a bidder or prospective bidder, as the case may be, the procuring entity may take
appropriate measures including: -
a. exclusion of the bidder from the procurement process;
b. calling-off of pre-contract negotiations and forfeiture or encashment of bid security;
c. forfeiture or encashment of any other security or bond relating to the procurement;
d. recovery of payments made by the procuring entity along with interest thereon at bank
rate;
e. cancellation of the relevant contract and recovery of compensation for loss incurred by
the procuring entity;
f. debarment of the bidder from participation in future procurements of the procuring
entity for a period not exceeding three years.
5.31 Interference with Procurement Process A bidder, who: -
a) withdraws from the procurement process after opening of financial bids;
b) withdraws from the procurement process after being declared the successful bidder;
c) fails to enter into procurement contract after being declared the successful bidder;
d) fails to provide performance security or any other document or security required in terms
of the bidding documents after being declared the successful bidder, without valid
grounds,
shall, in addition to the recourse available in the bidding document or the
contract, be punished with fine which may extend to fifty lakh rupees or ten per cent of
the assessed value of procurement, whichever is less.
5.32 Appeals a) Subject to “Appeal not to lie in certain cases” below, if any bidder or prospective bidder is
aggrieved that any decision, action or omission of the procuring entity is in
contravention to the provisions of the Act or the rules or guidelines issued thereunder, he
may file an appeal to such officer of the procuring entity, as may be designated by it for the
purpose, within a period of 10 days from the date of such decision or action, omission, as
the case may be, clearly giving the specific ground or grounds on which he feels
aggrieved:
a. Provided that after the declaration of a bidder as successful in terms of “Award of
Contract”, the appeal may be filed only by a bidder who has participated in
procurement proceedings:
“Design, Development and Implementation of Store Management System (SMS)”
Page 53 of 198
b. Provided further that in case a procuring entity evaluates the technical Bid before the
opening of the financial Bid, an appeal related to the matter of financial Bid may be filed
only by a bidder whose technical Bid is found to be acceptable.
b) The officer to whom an appeal is filed under (a) above shall deal with the appeal as
expeditiously as possible and shall endeavour to dispose it of within 30 days from the date
of filing of the appeal.
c) If the officer designated under (a) above fails to dispose of the appeal filed under that sub-
section within the period specified in (c) above, or if the bidder or prospective bidder or the
procuring entity is aggrieved by the order passed, the bidder or prospective bidder or the
procuring entity, as the case may be, may file a second appeal to an officer or authority
designated by the State Government in this behalf within 15 days from the expiry of the
period specified in (c) above or of the date of receipt of the order passed under (b) above,
as the case may be.
d) The officer or authority to which an appeal is filed under (c) above shall deal with the
appeal as expeditiously as possible and shall endeavour to dispose it of within 30 days
from the date of filing of the appeal:
e) The officer or authority to which an appeal may be filed under (a) or (d) above shall be :
First Appellate Authority: Principal Secretary, IT&C, GoR
Second Appellate Authority: Principal Secretary, Finance Department, GoR
f) Form of Appeal:
a. Every appeal under (a) and (c) above shall be as per Annexure-14 along with as
many copies as there are respondents in the appeal.
b. Every appeal shall be accompanied by an order appealed against, if any, affidavit
verifying the facts stated in the appeal and proof of payment of fee.
c. Every appeal may be presented to First Appellate Authority or Second Appellate
Authority, as the case may be, in person or through registered post or authorised
representative.
g) Fee for Appeal: Fee for filing appeal:
a. Fee for first appeal shall be rupees two thousand five hundred and for second
appeal shall be rupees ten thousand, which shall be non-refundable.
b. The fee shall be paid in the form of bank demand draft or banker’s cheque of a
Scheduled Bank payable in the name of Appellate Authority concerned.
h) Procedure for disposal of appeal:
a. The First Appellate Authority or Second Appellate Authority, as the case may be,
upon filing of appeal, shall issue notice accompanied by copy of appeal, affidavit
and documents, if any, to the respondents and fix date of hearing.
“Design, Development and Implementation of Store Management System (SMS)”
Page 54 of 198
b. On the date fixed for hearing, the First Appellate Authority or Second Appellate
Authority, as the case may be, shall,-
i. hear all the parties to appeal present before him; and
ii. peruse or inspect documents, relevant records or copies thereof relating to
the matter.
c. After hearing the parties, perusal or inspection of documents and relevant records
or copies thereof relating to the matter, the Appellate Authority concerned shall
pass an order in writing and provide the copy of order to the parties to appeal free
of cost.
d. The order passed under (c) shall also be placed on the State Public Procurement
Portal.
i) No information which would impair the protection of essential security interests of India, or
impede the enforcement of law or fair competition, or prejudice the legitimate commercial
interests of the bidder or the procuring entity, shall be disclosed in a proceeding under an
appeal.
5.33 Stay of procurement proceedings
While hearing of an appeal, the officer or authority hearing the appeal may, on an application
made in this behalf and after affording a reasonable opportunity of hearing to the parties
concerned, stay the procurement proceedings pending disposal of the appeal, if he, or it, is
satisfied that failure to do so is likely to lead to miscarriage of justice.
5.34 Vexatious Appeals & Complaints Whoever intentionally files any vexatious, frivolous or malicious appeal or complaint under
the “The Rajasthan Transparency Public Procurement Act 2012”, with the intention of
delaying or defeating any procurement or causing loss to any procuring entity or any other
bidder, shall be punished with fine which may extend to twenty lakh rupees or five per cent of
the value of procurement, whichever is less.
5.35 Offenses by Firms/ Companies a) Where an offence under “The Rajasthan Transparency Public Procurement Act 2012”
has been committed by a company, every person who at the time the offence was
committed was in charge of and was responsible to the company for the conduct of the
business of the company, as well as the company, shall be deemed to be guilty of having
committed the offence and shall be liable to be proceeded against and punished
accordingly:
Provided that nothing contained in this sub-section shall render any such person liable
for any punishment if he proves that the offence was committed without his knowledge or
that he had exercised all due diligence to prevent the commission of such offence.
“Design, Development and Implementation of Store Management System (SMS)”
Page 55 of 198
b) Notwithstanding anything contained in (a) above, where an offence under this Act has
been committed by a company and it is proved that the offence has been committed with
the consent or connivance of or is attributable to any neglect on the part of any director,
manager, secretary or other officer of the company, such director, manager, secretary or
other officer shall also be deemed to be guilty of having committed such offence and
shall be liable to be proceeded against and punished accordingly.
c) For the purpose of this section-
a. "company" means a body corporate and includes a limited liability partnership,
firm, registered society or co- operative society, trust or other association of
individuals; and
b. "director" in relation to a limited liability partnership or firm, means a partner in the
firm.
d) Abetment of certain offenses: Whoever abets an offence punishable under this Act,
whether or not that offence is committed in consequence of that abetment, shall be
punished with the punishment provided for the offence.
5.36 Debarment from Bidding a) A bidder shall be debarred by the State Government if he has been convicted of an
offence
a. under the Prevention of Corruption Act, 1988 (Central Act No. 49 of 1988); or
b. under the Indian Penal Code, 1860 (Central Act No. 45 of 1860) or any other law
for the time being in force, for causing any loss of life or property or causing a
threat to public health as part of execution of a public procurement contract.
b) A bidder debarred under (a) above shall not be eligible to participate in a procurement
process of any procuring entity for a period not exceeding three years commencing from
the date on which he was debarred.
c) If a procuring entity finds that a bidder has breached the code of integrity prescribed in
terms of “Code of Integrity for bidders” above, it may debar the bidder for a period not
exceeding three years.
d) Where the entire bid security or the entire performance security or any substitute thereof,
as the case may be, of a bidder has been forfeited by a procuring entity in respect of any
procurement process or procurement contract, the bidder may be debarred from
participating in any procurement process undertaken by the procuring entity for a period
not exceeding three years.
e) The State Government or a procuring entity, as the case may be, shall not debar a bidder
under this section unless such bidder has been given a reasonable opportunity of being
heard.
“Design, Development and Implementation of Store Management System (SMS)”
Page 56 of 198
5.37 Monitoring of Contract a) An officer or a committee of officers named Contract Monitoring Committee (CMC) may
be nominated by procuring entity to monitor the progress of the contract during its
delivery period.
b) During the delivery period the CMC shall keep a watch on the progress of the contract
and shall ensure that quantity of goods and service delivery is in proportion to the total
delivery period given, if it is a severable contract, in which the delivery of the goods and
service is to be obtained continuously or is batched. If the entire quantity of goods and
service is to be delivered in the form of completed work or entire contract like fabrication
work, the process of completion of work may be watched and inspections of the selected
bidder’s premises where the work is being completed may be inspected.
c) If delay in delivery of goods and service is observed a performance notice would be
given to the selected bidder to speed up the delivery.
d) Any change in the constitution of the firm, etc. shall be notified forth with by the
contractor in writing to the procuring entity and such change shall not relieve any former
member of the firm, etc., from any liability under the contract.
e) No new partner/ partners shall be accepted in the firm by the selected bidder in respect
of the contract unless he/ they agree to abide by all its terms, conditions and deposits
with the procuring entity through a written agreement to this effect. The selected bidder’s
receipt for acknowledgement or that of any partners subsequently accepted as above
shall bind all of them and will be sufficient discharge for any of the purpose of the
contract.
f) The selected bidder shall not assign or sub-let his contract or any substantial part thereof
to any other agency without the permission of procuring entity.
“Design, Development and Implementation of Store Management System (SMS)”
Page 57 of 198
6. GENERALTERMS AND CONDITIONS OF TENDER & CONTRACT
Bidders should read these conditions carefully and comply strictly while sending their bids.
Definitions
For the purpose of clarity, the following words and expressions shall have the meanings hereby
assigned to them: -
a) “Contract” means the Agreement entered into between the Purchaser and the successful/
selected bidder, together with the Contract Documents referred to therein, including all
attachments, appendices, and all documents incorporated by reference therein.
b) “Contract Documents” means the documents listed in the Agreement, including any
amendments thereto.
c) “Contract Price” means the price payable to the successful/ selected bidder as specified in the
Agreement, subject to such additions and adjustments thereto or deductions there from, as
may be made pursuant to the Contract.
d) “Day” means a calendar day.
e) “Delivery” means the transfer of the Goods from the successful/ selected bidder to the
Purchaser in accordance with the terms and conditions set forth in the Contract.
f) “Completion” means the fulfilment of the related services by the successful/ selected bidder in
accordance with the terms and conditions set forth in the Contract.
g) “Goods” means all of the commodities, raw material, machinery and equipment, and/or other
materials that the successful/ selected bidder is required to supply to the Purchaser under the
Contract.
h) “Purchaser” means the entity purchasing the Goods and related services, as specified in the
bidding document.
i) “Related Services” means the services incidental to the supply of the goods, such as
insurance, installation, training and initial maintenance and other similar obligations of the
successful/ selected bidder under the Contract.
j) “Subcontractor” means any natural person, private or government entity, or a combination of
the above, including its legal successors or permitted assigns, to whom any part of the Goods
to be supplied or execution of any part of the related services is subcontracted by the
successful/ selected bidder.
k) “Supplier/ Successful or Selected bidder” means the person, private or government entity, or a
combination of the above, whose Bid to perform the Contract has been accepted by the
Purchaser and is named as such in the Agreement, and includes the legal successors or
permitted assigns of the successful/ selected bidder.
l) “The Site,” where applicable, means the designated project place(s) named in the bidding
document.
“Design, Development and Implementation of Store Management System (SMS)”
Page 58 of 198
Note: The bidder shall be deemed to have carefully examined the conditions, specifications, size,
make and drawings, etc., of the goods to be supplied and related services to be rendered. If the
bidder has any doubts as to the meaning of any portion of these conditions or of the specification,
drawing, etc., he shall, before submitting the Bid and signing the contract refer the same to the
procuring entity and get clarifications.
6.1 Contract Documents
Subject to the order of precedence set forth in the Agreement, all documents forming the
Contract (and all parts thereof) are intended to be correlative, complementary, and mutually
explanatory.
6.2 Interpretation
a) If the context so requires it, singular means plural and vice versa.
b) Entire Agreement: The Contract constitutes the entire agreement between the Purchaser
and the Supplier/ Selected bidder and supersedes all communications, negotiations and
agreements (whether written or oral) of parties with respect thereto made prior to the date
of Contract.
c) Amendment: No amendment or other variation of the Contract shall be valid unless it is in
writing, is dated, expressly refers to the Contract, and is signed by a duly authorized
representative of each party thereto.
d) Non-waiver: Subject to the condition (f) below, no relaxation, forbearance, delay, or
indulgence by either party in enforcing any of the terms and conditions of the Contract or
the granting of time by either party to the other shall prejudice, affect, or restrict the rights
of that party under the Contract, neither shall any waiver by either party of any breach of
Contract operate as waiver of any subsequent or continuing breach of Contract.
e) Any waiver of a party’s rights, powers, or remedies under the Contract must be in writing,
dated, and signed by an authorized representative of the party granting such waiver, and
must specify the right and the extent to which it is being waived.
f) Severability: If any provision or condition of the Contract is prohibited or rendered invalid or
unenforceable, such prohibition, invalidity or unenforceability shall not affect the validity or
enforceability of any other provisions and conditions of the Contract.
6.3 Language
a) The Contract as well as all correspondence and documents relating to the Contract
exchanged by the successful/ selected bidder and the Purchaser, shall be written in
English language only. Supporting documents and printed literature that are part of the
Contract may be in another language provided they are accompanied by an accurate
translation of the relevant passages in the language specified in the special conditions of
“Design, Development and Implementation of Store Management System (SMS)”
Page 59 of 198
the contract, in which case, for purposes of interpretation of the Contract, this translation
shall govern.
b) The successful/ selected bidder shall bear all costs of translation to the governing
language and all risks of the accuracy of such translation.
6.4 Joint Venture, Consortium or Association
Joint Ventures, Consortiums or associations are not allowed.
6.5 Eligible Goods and Related Services
a) For purposes of this Clause, the term “goods” includes commodities, raw material,
machinery, equipment, and industrial plants; and “related services” includes services such
as insurance, transportation, supply, installation, integration, testing, commissioning,
training, and initial maintenance.
b) All articles/ goods being bid, other than those marked in the Bill of Material (BoM) should
be the ones which are produced in volume and are used by a large number of users in
India/ abroad. All products quoted by the successful/ selected bidder must be associated
with specific make and model number, item code and names and with printed literature
describing configuration and functionality. Any deviation from the printed specifications
should be clearly mentioned in the offer document by the bidder/ supplier. Also, the bidder
is to quote/ propose only one make/ model against the respective item.
c) The OEM/ Vendor of the quoted product must have its own registered spares depot in
India having adequate inventory of the equipment being quoted for providing the necessary
spares as per the requirements of the bidding document.
d) The OEM/ Vendor of the quoted product should also have its direct representation in India
in terms of registered office for at least past 3 years. The presence through any
Distribution/ System Integration partner agreement will not be accepted.
e) Bidder must quote products in accordance with above clause “Eligible goods and related
services”.
6.6 Notices
a) Any notice given by one party to the other pursuant to the Contract shall be in writing to the
address specified in the contract. The term “in writing” means communicated in written
form with proof of dispatch and receipt.
b) A Notice shall be effective when delivered or on the Notice’s effective date, whichever is
later.
6.7 Governing Law
The Contract shall be governed by and interpreted in accordance with the laws of the
Rajasthan State/ the Country (India), unless otherwise specified in the contract.
“Design, Development and Implementation of Store Management System (SMS)”
Page 60 of 198
6.8 Scope of Supply
a) Subject to the provisions in the bidding document and contract, the goods and related
services to be supplied shall be as specified in the bidding document.
b) Unless otherwise stipulated in the Contract, the scope of supply shall include all such items
not specifically mentioned in the Contract but that can be reasonably inferred from the
Contract as being required for attaining delivery and completion of the goods and related
services as if such items were expressly mentioned in the Contract.
c) The bidder shall not quote and supply and hardware/ software that is likely to be declared
as End of Sale in next 6 months and End of Service/ Support for a period of 3 Years from
the last date of bid submission. OEMs are required to mention this in the MAF for all the
quoted hardware/ software. If any of the hardware/ software is found to be declared as End
of Sale/ Service/ Support, then the selected bidder shall replace all such hardware/
software with the latest ones having equivalent or higher specifications without any
financial obligation to the purchaser.
6.9 Delivery & Installation
a) Subject to the conditions of the contract, the delivery of the goods and completion of the
related services shall be in accordance with the delivery and completion schedule specified
in the bidding document. The details of supply/ shipping and other documents to be
furnished by the successful/ selected bidder are specified in the bidding document and/ or
contract.
b) The contract for the supply can be repudiated at any time by the purchase officer, if the
supplies are not made to his satisfaction after giving an opportunity to the successful
bidder of being heard and recording the reasons for repudiation.
c) The Supplier/ Selected bidder shall arrange to supply, install and commission the ordered
materials/ system as per specifications within the specified delivery/ completion period at
various departments and/ or their offices/ locations mentioned in the PO/ WO.
d) Shifting the place of Installation: The user will be free to shift the place of installation within
the same city /town/ district/ division. The successful/ selected bidder shall provide all
assistance, except transportation, in shifting of the equipment. However, if the city/town is
changed, additional charges of assistance in shifting and providing maintenance services
for remaining period would be decided mutually.
6.10 Supplier’s/ Selected Bidder’s Responsibilities
The Supplier/ Selected bidder shall supply all the goods and related services included in the
scope of supply in accordance with the provisions of bidding document and/ or contract.
“Design, Development and Implementation of Store Management System (SMS)”
Page 61 of 198
6.11 Purchaser’s Responsibilities
a) Whenever the supply of goods and related services requires that the Supplier/ Selected
bidder obtain permits, approvals, and import and other licenses from local public
authorities, the Purchaser shall, if so required by the Supplier/ Selected bidder, make its
best effort to assist the Supplier/ Selected bidder in complying with such requirements in a
timely and expeditious manner.
b) The Purchaser shall pay all costs involved in the performance of its responsibilities, in
accordance with the general and special conditions of the contract.
6.12 Contract Price
a) The Contract Price shall be paid as specified in the contract subject to any additions and
adjustments thereto, or deductions there from, as may be made pursuant to the Contract.
b) Prices charged by the Supplier/ Selected bidder for the Goods delivered and the Related
Services performed under the Contract shall not vary from the prices quoted by the
Supplier/ Selected bidder in its bid, with the exception of any price adjustments authorized
in the special conditions of the contract.
6.13 Recoveries from Supplier/ Selected Bidder
a) Recovery of liquidated damages, short supply, breakage, rejected articles shall be made
ordinarily from bills.
b) The Purchase Officer shall withhold amount to the extent of short supply, broken/ damaged
or for rejected articles unless these are replaced satisfactorily. In case of failure to withhold
the amount, it shall be recovered from his dues and performance security deposit available
with RISL.
c) The balance, if any, shall be demanded from the Supplier/ Selected bidder and when
recovery is not possible, the Purchase Officer shall take recourse to law in force.
6.14 Taxes & Duties
a) The TDS, Raj-VAT, Service Tax etc., if applicable, shall be deducted at source/ paid by
RISL as per prevailing rates.
b) For goods supplied from outside India, the successful/ selected bidder shall be entirely
responsible for all taxes, stamp duties, license fees, and other such levies imposed outside
the country.
c) For goods supplied from within India, the successful/ selected bidder shall be entirely
responsible for all taxes, duties, license fees, etc., incurred until delivery of the contracted
Goods to the Purchaser.
d) If any tax exemptions, reductions, allowances or privileges may be available to the
successful/ selected bidder in India, the Purchaser shall use its best efforts to enable the
“Design, Development and Implementation of Store Management System (SMS)”
Page 62 of 198
successful/ selected bidder to benefit from any such tax savings to the maximum allowable
extent.
6.15 Copyright
The copyright in all drawings, design documents, source code and other materials containing
data and information furnished to the Purchaser by the Supplier/ Selected bidder herein shall
remain vested in the Supplier/ Selected bidder, or, if they are furnished to the Purchaser
directly or through the Supplier/ Selected bidder by any third party, including suppliers of
materials, the copyright in such materials shall remain vested in such third party.
6.16 Confidential Information
a) The Purchaser and the Supplier/ Selected bidder shall keep confidential and shall not,
without the written consent of the other party hereto, divulge to any third party any
drawings, documents, data, or other information furnished directly or indirectly by the other
party hereto in connection with the Contract, whether such information has been furnished
prior to, during or following completion or termination of the Contract.
b) The Supplier/ Selected bidder may furnish to its Subcontractor, if permitted, such
documents, data, and other information it receives from the Purchaser to the extent
required for the Subcontractor to perform its work under the Contract, in which event the
Supplier/ Selected bidder shall obtain from such Subcontractor an undertaking of
confidentiality similar to that imposed on the Supplier/ Selected bidder.
c) The Purchaser shall not use such documents, data, and other information received from
the Supplier/ Selected bidder for any purposes unrelated to the Contract. Similarly, the
Supplier/ Selected bidder shall not use such documents, data, and other information
received from the Purchaser for any purpose other than the design, procurement, or other
work and services required for the performance of the Contract.
d) The obligation of a party under sub-clauses above, however, shall not apply to information
that: -
i. the Purchaser or Supplier/ Selected bidder need to share with Rajasthan Police or
RISL or other institutions participating in the Contract;
ii. now or hereafter enters the public domain through no fault of that party;
iii. can be proven to have been possessed by that party at the time of disclosure and
which was not previously obtained, directly or indirectly, from the other party; or
iv. otherwise lawfully becomes available to that party from a third party that has no
obligation of confidentiality.
e) The above provisions shall not in any way modify any undertaking of confidentiality given
by either of the parties hereto prior to the date of the Contract in respect of the supply or
any part thereof.
“Design, Development and Implementation of Store Management System (SMS)”
Page 63 of 198
f) The provisions of this clause shall survive completion or termination, for whatever reason,
of the Contract.
6.17 Sub-contracting
a) The selected bidder shall not assign or sub-let his contract or any substantial part thereof
to any other agency without the permission of Purchaser/ Tendering Authority.
b) If permitted, the selected bidder shall notify the Purchaser, in writing, of all subcontracts
awarded under the Contract, if not already specified in the Bid. Subcontracting shall in no
event relieve the Supplier/ Selected bidder from any of its obligations, duties,
responsibilities, or liability under the Contract.
c) Subcontractors, if permitted, shall comply with the provisions of bidding document and/ or
contract.
6.18 Specifications and Standards
a) All articles supplied shall strictly conform to the specifications, trademark laid down in the
bidding document and wherever articles have been required according to ISI/ ISO/ other
applicable specifications/ certifications/ standards, those articles should conform strictly to
those specifications/ certifications/ standards. The supply shall be of best quality and
description. The decision of the competent authority/ purchase committee whether the
articles supplied conforms to the specifications shall be final and binding on the supplier/
selected bidder.
b) Technical Specifications and Drawings
i. The Supplier/ Selected bidder shall ensure that the goods and related services comply
with the technical specifications and other provisions of the Contract.
ii. The Supplier/ Selected bidder shall be entitled to disclaim responsibility for any design,
data, drawing, specification or other document, or any modification thereof provided or
designed by or on behalf of the Purchaser, by giving a notice of such disclaimer to the
Purchaser.
iii. The goods and related services supplied under this Contract shall conform to the
standards mentioned in bidding document and, when no applicable standard is
mentioned, the standard shall be equivalent or superior to the official standards whose
application is appropriate to the country of origin of the Goods.
c) Wherever references are made in the Contract to codes and standards in accordance with
which it shall be executed, the edition or the revised version of such codes and standards
shall be those specified in the bidding document. During Contract execution, any changes
in any such codes and standards shall be applied only after approval by the Purchaser and
shall be treated in accordance with the general conditions of the contract.
“Design, Development and Implementation of Store Management System (SMS)”
Page 64 of 198
d) The supplier/ selected bidder must certify that all the goods are new, unused, and of the
agreed make and models, and that they incorporate all recent improvements in design and
materials, unless provided otherwise in the Contract.
e) The supplier/ selected bidder should further warrant that the Goods shall be free from
defects arising from any act or omission of the supplier/ selected bidder or arising from
design, materials, and workmanship, under normal use in the conditions prevailing in the
place of final destination.
6.19 Packing and Documents
a) The Supplier/ Selected bidder shall provide such packing of the Goods as is required to
prevent their damage or deterioration during transit to their final destination, as indicated in
the Contract. During transit, the packing shall be sufficient to withstand, without limitation,
rough handling and exposure to extreme temperatures, salt and precipitation, and open
storage. Packing case size and weights shall take into consideration, where appropriate,
the remoteness of the final destination of the Goods and the absence of heavy handling
facilities at all points in transit.
b) The packing, marking, and documentation within and outside the packages shall comply
strictly with such special requirements as shall be expressly provided for in the Contract,
including additional requirements, if any, specified in the contract, and in any other
instructions ordered by the Purchaser.
6.20 Insurance
a) The Goods supplied under the Contract shall be fully insured against loss by theft,
destruction or damage incidental to manufacture or acquisition, transportation, storage,
fire, flood, under exposure to weather and delivery at the designated project locations, in
accordance with the applicable terms. The insurance charges will be borne by the supplier
and Purchaser will not be required to pay such charges if incurred.
b) The goods will be delivered at the FOR destination in perfect condition.
6.21 Transportation
a) The supplier/ selected bidder shall be responsible for transport by sea, rail and road or air
and delivery of the material in the good condition to the consignee at destination. In the
event of any loss, damage, breakage or leakage or any shortage the bidder shall be liable
to make good such loss and shortage found at the checking/ inspection of the material by
the consignee. No extra cost on such account shall be admissible.
b) All goods must be sent freight paid through Railways or goods transport. If goods are sent
freight to pay, the freight together with departmental charge @5% of the freight will be
recovered from the supplier’s/ selected bidder’s bill.
“Design, Development and Implementation of Store Management System (SMS)”
Page 65 of 198
6.22 Inspection
a) The Purchase Officer or his duly authorized representative shall at all reasonable time
have access to the supplier’s/ selected bidder’s premises and shall have the power at all
reasonable time to inspect and examine the materials and workmanship of the goods/
equipment/ machineries during manufacturing process or afterwards as may be decided.
b) The supplier/ selected bidder shall furnish complete address of the premises of his factory,
office, go-down and workshop where inspection can be made together with name and
address of the person who is to be contacted for the purpose.
c) After successful inspection, it will be supplier’s/ selected bidder’s responsibility to dispatch
and install the equipment at respective locations without any financial liability to the
Purchaser. However, supplies when received at respective locations shall be subject to
inspection to ensure whether they conform to the specification.
6.23 Samples
a) When notified by the Purchaser to the supplier/ bidder/ selected bidder, Bids for articles/
goods marked in the BoM shall be accompanied by four sets of samples of the articles
quoted properly packed. Such samples if submitted personally will be received in the office.
A receipt will be given for each sample by the officer receiving the samples. Samples if
sent by train, etc., should be despatched freight paid and the R/R or G.R. should be sent
under a separate registered cover. Samples for catering/ food items should be given in a
plastic box or in polythene bags at the cost of the selected bidder.
b) Each sample shall be marked suitably either by written on the sample or on a slip of
durable paper securely fastened to the sample, the name of the selected bidder and serial
number of the item, of which it is a sample in the schedule.
c) Approved samples would be retained free of cost upto the period of six months after the
expiry of the contract. RISL shall not be responsible for any damage, wear and tear or loss
during testing, examination, etc., during the period these samples are retained.
The Samples shall be collected by the supplier/ bidder/ selected bidder on the expiry of
stipulated period. RISL shall in no way make arrangements to return the samples. The
samples uncollected within 9 months after expiry of contract shall be forfeited by RISL and
no claim for their cost, etc., shall be entertained.
d) Samples not approved shall be collected by the unsuccessful bidder. RISL will not be
responsible for any damage, wear and tear, or loss during testing, examination, etc., during
the period these samples are retained. The uncollected samples shall be forfeited and no
claim for their cost, etc., shall be entertained.
e) Supplies when received may be subject to inspection to ensure whether they conform to
the specifications or with the approved samples. Where necessary or prescribed or
“Design, Development and Implementation of Store Management System (SMS)”
Page 66 of 198
practical, tests shall be carried out in Government laboratories, reputed testing house like
STQC (ETDC) and the like and the supplies will be accepted only when the articles
conform to the standard of prescribed specifications as a result of such tests.
f) The supplier/ selected bidder shall at its own expense and at no cost to the Purchaser
carry out all such tests and/ or inspections of the Goods and Related Services as are
specified in the bidding document.
6.24 Drawl of Samples
In case of tests, wherever feasible, samples shall be drawn in four sets in the presence of
supplier/ bidder/ selected bidder or his authorised representative and properly sealed in their
presence. Once such set shall be given to them, one or two will be sent to the laboratories
and/ or testing house and the third or fourth will be retained in the office for reference and
record.
6.25 Testing charges
Testing charges shall be borne by the Government. In case, test results showing that supplies
are not upto the prescribed standards or specifications, the testing charges shall be payable by
the selected bidder.
6.26 Rejection
a) Articles not approved during inspection or testing shall be rejected and will have to be
replaced by the selected bidder at his own cost within the time fixed by the Purchase
Officer.
b) If, however, due to exigencies of Rajasthan Police, such replacement either in whole or in
part, is not considered feasible, the Purchase Officer after giving an opportunity to the
selected bidder of being heard shall for reasons to be recorded, deduct a suitable amount
from the approved rates. The deduction so made shall be final.
c) The rejected articles shall be removed by the supplier/ bidder/ selected bidder within 15
days of intimation of rejection, after which Purchase Officer shall not be responsible for any
loss, shortage or damage and shall have the right to dispose of such articles as he thinks
fit, at the selected bidder’s risk and on his account.
6.27 Extension in Delivery Period and Liquidated Damages (LD)
a) Except as provided under clause “Force Majeure”, if the supplier/ selected bidder fails to
deliver any or all of the Goods or perform the Related Services within the period specified
in the Contract, the Purchaser may without prejudice to all its other remedies under the
Contract, deduct from the Contract Price, as liquidated damages, a sum equivalent to the
percentage specified in (d) below for each week or part thereof of delay until actual delivery
or performance, up to a maximum deduction of the percentage specified in the bidding
“Design, Development and Implementation of Store Management System (SMS)”
Page 67 of 198
document and/ or contract. Once the maximum is reached, the Purchaser may terminate
the Contract pursuant to clause “Termination”.
b) The time specified for delivery in the bidding document shall be deemed to be the essence
of the contract and the supplier/ selected bidder shall arrange goods supply and related
services within the specified period.
c) Delivery and installation/ completion period may be extended with or without liquidated
damages, if the delay in the supply of goods or service is on account of hindrances beyond
the control of the supplier/ selected bidder.
i. The supplier/ selected bidder shall request in writing to the Purchaser giving reasons
for extending the delivery period of service, if he finds himself unable to complete the
supply of goods or service within the stipulated delivery period or is unable to maintain
prorate progress in the supply of goods or service delivery. This request shall be
submitted as soon as a hindrance in delivery of goods and service occurs or within 15
days from such occurrence but before expiry of stipulated period of completion of
delivery of goods and service after which such request shall not be entertained.
ii. The Purchaser shall examine the justification of causes of hindrance in the delivery of
goods and service and the period of delay occurred due to that and recommend the
competent authority on the period of extension which should be granted with or without
liquidated damages.
iii. Normally, extension in delivery period of goods and service in following circumstances
may be considered without liquidated damages:
a. When delay has occurred due to delay in supply of drawings, designs, plans etc. if
the Rajasthan Police or RISL was required to supply them to the supplier of goods
or service provider as per terms of the contract.
b. When delay has occurred in supply of materials etc. if these were required to be
supplied to the supplier or service provider by the RISL as per terms of the contract.
iv. If the competent authority agrees to extend the delivery period/ schedule, an
amendment to the contract with suitable denial clauses and with or without liquidated
damages, as the case may be, shall be issued. The amendment letter shall mention
that no extra price or additional cost for any reason, what so ever beyond the
contracted cost shall be paid for the delayed supply of goods and service.
v. It shall be at the discretion of the concerned authority to accept or not to accept the
supply of goods and/ or services rendered by the contractor after the expiry of the
stipulated delivery period, if no formal extension in delivery period has been applied
and granted. The competent authority shall have right to cancel the contract with
respect to undelivered goods and/ or service.
“Design, Development and Implementation of Store Management System (SMS)”
Page 68 of 198
vi. If Rajasthan Police or RISL is in need of the good and/ or service rendered after expiry
of the stipulated delivery period, it may accept the services and issue a letter of
extension in delivery period with usual liquidated damages and denial clauses to
regularize the transaction.
d) In case of extension in the delivery and/ or installation/ completion/ commissioning period
is granted with full liquidated damages, the recovery shall be made on the basis of
following percentages of value of goods and/ or service which the supplier/ selected bidder
has failed to supply/ install/ complete : -
No. Condition LD %*
a. Delay up to one fourth period of the prescribed period of delivery, successful installation and completion of work 2.5 %
b. Delay exceeding one fourth but not exceeding half of the prescribed period of delivery, successful installation and completion of work
5.0 %
c. Delay exceeding half but not exceeding three fourth of the prescribed period of delivery, successful installation and completion of work 7.5 %
d. Delay exceeding three fourth of the prescribed period of delivery, successful installation and completion of work
10.0 %
i. Fraction of a day in reckoning period of delay in supplies, successful installation and
completion of work shall be eliminated, if it is less than half a day.
ii. The maximum amount of liquidated damages shall be 10% of the contract value.
iii. *The percentage refers to the payment due for the associated works/ goods/ service.
6.28 Authenticity of Equipment
a) The selected bidder shall certify (as per Annexure-9) that the supplied goods are brand
new, genuine/ authentic, not refurbished, conform to the description and quality as
specified in this bidding document and are free from defects in material, workmanship and
service.
b) If during the contract period, the said goods be discovered counterfeit/ unauthentic or not
to conform to the description and quality aforesaid or have determined (and the decision of
the Purchase Officer in that behalf will be final and conclusive), notwithstanding the fact
that the purchaser may have inspected and/ or approved the said goods, the purchaser will
be entitled to reject the said goods or such portion thereof as may be discovered not to
conform to the said description and quality, on such rejection the goods will be at the
selected bidder’s risk and all the provisions relating to rejection of goods etc., shall apply.
The selected bidder shall, if so called upon to do, replace the goods etc., or such portion
thereof as is rejected by Purchase Officer, otherwise the selected bidder shall pay such
damage as may arise by the reason of the breach of the condition herein contained.
“Design, Development and Implementation of Store Management System (SMS)”
Page 69 of 198
Nothing herein contained shall prejudice any other right of the Purchase Officer in that
behalf under this contract or otherwise.
c) Goods accepted by the purchaser in terms of the contract shall in no way dilute
purchaser’s right to reject the same later, if found deficient in terms of the this clause of the
contract.
6.29 Warranty
a) The selected bidder must supply all items with comprehensive on-site OEM warranty valid
for three years after the goods, or any portion thereof as the case may be, have been
delivered to, installed and accepted at the final destination(s) indicated in the bidding
document. However, if delay of installation is more than a month’s time due to the reasons
ascribed to the selected bidder, the warranty shall start from the date of last successful
installation of the items covered under the PO.
b) At the time of goods delivery, the selected bidder shall submit a certificate/ undertaking
from all the respective OEMs mentioning the fact that the goods supplied are covered
under comprehensive warranty & support for the prescribed period.
c) The purchaser shall give a written notice to the selected bidder stating the nature of any
defect together with all available evidence thereof, promptly following the discovery thereof.
The purchaser shall afford all reasonable opportunity for the selected bidder to inspect
such defects. Upon receipt of such notice, the selected bidder shall expeditiously cause to
repair the defective goods or parts thereof or replace the defective goods or parts thereof
with brand new genuine/ authentic ones having similar or higher specifications from the
respective OEM, at no cost to the Purchaser. Any goods repaired or replaced by the
selected bidder shall be delivered at the respective location without any additional costs to
the purchaser.
d) If having been notified, the selected bidder fails to remedy the defect within the period
specified, the purchaser may proceed to take within a reasonable period such remedial
action as may be necessary, in addition to other recourses available in terms and
conditions of the contract and bidding document.
e) During the warranty period, the selected bidder shall also be responsible to ensure
adequate and timely availability of spare parts needed for repairing the supplied goods.
f) The warranty on supplied software media, if any, should be at least 90 days.
6.30 Patent Indemnity
a) The supplier/ selected bidder shall, subject to the Purchaser’s compliance with sub-clause
(b) below, indemnify and hold harmless the Purchaser and its employees and officers from
and against any and all suits, actions or administrative proceedings, claims, demands,
losses, damages, costs, and expenses of any nature, including attorney’s fees and
“Design, Development and Implementation of Store Management System (SMS)”
Page 70 of 198
expenses, which the Purchaser may suffer as a result of any infringement or alleged
infringement of any patent, utility model, registered design, trademark, copyright, or other
intellectual property right registered or otherwise existing at the date of the Contract by
reason of: -
i. the installation of the Goods by the supplier/ selected bidder or the use of the Goods in
the country where the Site is located; and
ii. the sale in any country of the products produced by the Goods.
Such indemnity shall not cover any use of the Goods or any part thereof other than for the
purpose indicated by or to be reasonably inferred from the Contract, neither any
infringement resulting from the use of the Goods or any part thereof, or any products
produced thereby in association or combination with any other equipment, plant, or
materials not supplied by the supplier/ selected bidder, pursuant to the Contract.
b) If any proceedings are brought or any claim is made against the Purchaser arising out of
the matters referred to above, the Purchaser shall promptly give the supplier/ selected
bidder a notice thereof, and the supplier/ selected bidder may at its own expense and in
the Purchaser’s name conduct such proceedings or claim and any negotiations for the
settlement of any such proceedings or claim.
c) If the supplier/ selected bidder fails to notify the Purchaser within thirty (30) days after
receipt of such notice that it intends to conduct any such proceedings or claim, then the
Purchaser shall be free to conduct the same on its own behalf.
d) The Purchaser shall, at the supplier’s/ selected bidder’s request, afford all available
assistance to the supplier/ selected bidder in conducting such proceedings or claim, and
shall be reimbursed by the supplier/ selected bidder for all reasonable expenses incurred in
so doing.
e) The Purchaser shall indemnify and hold harmless the supplier/ selected bidder and its
employees, officers, and Subcontractors (if any) from and against any and all suits, actions
or administrative proceedings, claims, demands, losses, damages, costs, and expenses of
any nature, including attorney’s fees and expenses, which the supplier/ selected bidder
may suffer as a result of any infringement or alleged infringement of any patent, utility
model, registered design, trademark, copyright, or other intellectual property right
registered or otherwise existing at the date of the Contract arising out of or in connection
with any design, data, drawing, specification, or other documents or materials provided or
designed by or on behalf of the Purchaser.
6.31 Limitation of Liability
Except in cases of gross negligence or wilful misconduct: -
“Design, Development and Implementation of Store Management System (SMS)”
Page 71 of 198
a) neither party shall be liable to the other party for any indirect or consequential loss or
damage, loss of use, loss of production, or loss of profits or interest costs, provided that
this exclusion shall not apply to any obligation of the supplier/ selected bidder to pay
liquidated damages to the Purchaser; and
b) the aggregate liability of the supplier/ selected bidder to the Purchaser, whether under the
Contract, in tort, or otherwise, shall not exceed the amount specified in the Contract,
provided that this limitation shall not apply to the cost of repairing or replacing defective
equipment, or to any obligation of the supplier/ selected bidder to indemnify the Purchaser
with respect to patent infringement.
6.32 Force Majeure
a) The supplier/ selected bidder shall not be liable for forfeiture of its PSD, LD, or termination
for default if and to the extent that it’s delay in performance or other failure to perform its
obligations under the Contract is the result of an event of Force Majeure.
b) For purposes of this Clause, “Force Majeure” means an event or situation beyond the
control of the supplier/ selected bidder that is not foreseeable, is unavoidable, and its origin
is not due to negligence or lack of care on the part of the supplier/ selected bidder. Such
events may include, but not be limited to, acts of the Purchaser in its sovereign capacity,
wars or revolutions, fires, floods, epidemics, quarantine restrictions, and freight
embargoes.
c) If a Force Majeure situation arises, the supplier/ selected bidder shall promptly notify the
RISL in writing of such conditions and cause thereof within 15 days of occurrence of such
event. Unless otherwise directed by RISL, the supplier/ selected bidder shall continue to
perform its obligations under the contract as far as reasonably practical.
d) If the performance in whole or part or any obligation under the contract is prevented or
delayed by any reason of Force Majeure for a period exceeding 60 days, either party at its
option may terminate the contract without any financial repercussion on either side.
e) In case a Force Majeure situation occurs with the Rajasthan Police or RISL, the Rajasthan
Police or RISL may take the case with the supplier/ selected bidder on similar lines.
6.33 Change Orders and Contract Amendments
a) The Purchaser may at any time order the supplier/ selected bidder through Notice in
accordance with clause “Notices” above, to make changes within the general scope of the
Contract in any one or more of the following: -
i. drawings, designs, or specifications, where Goods to be furnished under the Contract
are to be specifically manufactured for the Purchaser;
ii. the method of shipment or packing;
iii. the place of delivery; and
“Design, Development and Implementation of Store Management System (SMS)”
Page 72 of 198
iv. the related services to be provided by the supplier/ selected bidder.
b) If any such change causes an increase or decrease in the cost of, or the time required for,
the supplier’s/ selected bidder’s performance of any provisions under the Contract, an
equitable adjustment shall be made in the Contract Price or in the Delivery and Completion
Schedule, or both, and the Contract shall accordingly should be amended. Any claims by
the supplier/ selected bidder for adjustment under this clause must be asserted within thirty
(30) days from the date of the supplier’s/ selected bidder’s receipt of the Purchaser’s
change order.
c) Prices to be charged by the supplier/ selected bidder for any related services that might be
needed but which were not included in the Contract shall be agreed upon in advance by
the parties and shall not exceed the prevailing rates charged to other parties by the
supplier/ selected bidder for similar services.
6.34 Termination
a) Termination for Default i. The tender sanctioning authority of RISL may, without prejudice to any other remedy
for breach of contract, by a written notice of default of at least 30 days sent to the
supplier/ selected bidder, terminate the contract in whole or in part: -
a. If the supplier/ selected bidder fails to deliver any or all quantities of the service
within the time period specified in the contract, or any extension thereof granted by
RISL; or
b. If the supplier/ selected bidder fails to perform any other obligation under the
contract within the specified period of delivery of service or any extension granted
thereof; or
c. If the supplier/ selected bidder, in the judgement of the Purchaser, is found to be
engaged in corrupt, fraudulent, collusive, or coercive practices in competing for or
in executing the contract.
d. If the supplier/ selected bidder commits breach of any condition of the contract.
ii. If RISL terminates the contract in whole or in part, amount of PSD may be forfeited.
iii. Before cancelling a contract and taking further action, advice of senior most finance
person available in the office and of legal adviser or legal assistant posted in the office,
if there is one, may be obtained.
b) Termination for Insolvency
RISL may at any time terminate the Contract by giving a written notice of at least 30 days
to the supplier/ selected bidder, if the supplier/ selected bidder becomes bankrupt or
otherwise insolvent. In such event, termination will be without compensation to the
“Design, Development and Implementation of Store Management System (SMS)”
Page 73 of 198
supplier/ selected bidder, provided that such termination will not prejudice or affect any
right of action or remedy that has accrued or will accrue thereafter to RISL.
c) Termination for Convenience i. RISL, by a written notice of at least 30 days sent to the supplier/ selected bidder, may
terminate the Contract, in whole or in part, at any time for its convenience. The Notice
of termination shall specify that termination is for the Purchaser’s convenience, the
extent to which performance of the supplier/ selected bidder under the Contract is
terminated, and the date upon which such termination becomes effective.
ii. Depending on merits of the case the supplier/ selected bidder may be appropriately
compensated on mutually agreed terms for the loss incurred by the contract if any due
to such termination.
iii. The Goods that are complete and ready for shipment within twenty-eight (28) days
after the supplier’s/ selected bidder’s receipt of the Notice of termination shall be
accepted by the Purchaser at the Contract terms and prices. For the remaining Goods,
the Purchaser may elect:
a. To have any portion completed and delivered at the Contract terms and prices;
and/or
b. To cancel the remainder and pay to the supplier/ selected bidder an agreed amount
for partially completed Goods and Related Services and for materials and parts
previously procured by the supplier/ selected bidder.
6.35 Exit Management
a) Preamble
i. The word ‘parties’ include the procuring entity and the selected bidder.
ii. This Schedule sets out the provisions, which will apply on expiry or termination of the
Project Implementation and Operations and Management of SLA.
iii. In the case of termination of the Project Implementation and/ or Operation and
Management SLA due to illegality, the Parties shall agree at that time whether, and if
so during what period, the provisions of this Schedule shall apply.
iv. The Parties shall ensure that their respective associated entities carry out their
respective obligations set out in this Exit Management Schedule.
b) Transfer of Assets
i. The selected bidder may continue work on the assets for the duration of the exit
management period which may be a six months period from the date of expiry or
termination of the agreement, if required by RISL to do so. During this period, the
selected bidder will transfer all the assets in good working condition and as per the
specifications of the bidding document including the ones being upgraded to the
“Design, Development and Implementation of Store Management System (SMS)”
Page 74 of 198
department/ designated agency. The security deposit/ performance security
submitted by selected bidder will only be returned after the successful transfer of the
entire project including its infrastructure.
ii. The selected bidder, if not already done, will transfer all the Software Licenses under
the name of the Rajasthan Police as desired by the procuring entity during the exit
management period.
iii. RISL during the project implementation phase and the operation and management
phase shall be entitled to serve notice in writing to the selected bidder at any time
during the exit management period requiring the selected bidder to provide DoIT&C
or its nominated agencies with a complete and up-to-date list of the assets within 30
days of such notice.
iv. Upon service of a notice, as mentioned above, the following provisions shall apply: -
a. In the event, if the assets which to be transferred to RISL mortgaged to any
financial institutions by the selected bidder, the selected bidder shall ensure that
all such liens and liabilities have been cleared beyond any doubt, prior to such
transfer. All documents regarding the discharge of such lien and liabilities shall be
furnished to RISL or its nominated agencies.
b. All title of the assets to be transferred to RISL or its nominated agencies pursuant
to clause(s) above shall be transferred on the last day of the exit management
period. All expenses occurred during transfer of assets shall be borne by the
selected bidder.
c. That on the expiry of this clause, the selected bidder and any individual assigned
for the performance of the services under this clause shall handover or cause to
be handed over all confidential information and all other related material in its
possession, including the entire established infrastructure supplied by selected
bidder to RISL.
d. That the products and technology delivered to RISL during the contract term or
on expiry of the contract duration should not be sold or re-used or copied or
transferred by selected bidder to other locations apart from the locations
mentioned in the this bidding document without prior written notice and approval
of RISL. Supplied hardware, software & documents etc., used by selected bidder
for RISL shall be the legal properties of RISL.
c) Cooperation and Provision of Information during the exit management period
i. The selected bidder will allow RISL or its nominated agencies access to the
information reasonably required to define the current mode of operation associated
“Design, Development and Implementation of Store Management System (SMS)”
Page 75 of 198
with the provision of the services to enable RISL or its nominated agencies to assess
the existing services being delivered.
ii. The selected bidder shall provide access to copies of all information held or
controlled by them which they have prepared or maintained in accordance with the
Project Implementation, the Operation and Management SLA and SOWs relating to
any material aspect of the services provided by the selected bidder. RISL or its
nominated agencies shall be entitled to copy all such information comprising of
details pertaining to the services rendered and other performance data. The selected
bidder shall permit RISL or its nominated agencies and/ or any replacement operator
to have reasonable access to its employees and facilities as reasonably required by
RISL or its nominated agencies to understand the methods of delivery of the services
employed by the selected bidder and to assist appropriate knowledge transfer.
d) Confidential Information, Security and Data
The selected bidder will promptly on the commencement of the exit management period
supply to RISL or its nominated agencies the following:
i. Documentation relating to Intellectual Property Rights;
ii. Project related data and confidential information;
iii. All current and updated data as is reasonably required for purposes of RISL or its
nominated agencies transitioning the services to its replacement selected bidder in a
readily available format nominated by RISL or its nominated agencies; and
iv. All other information (including but not limited to documents, records and
agreements) relating to the services reasonably necessary to enable RISL or its
nominated agencies, or its replacement operator to carry out due diligence in order to
transition the provision of the services to RISL or its nominated agencies, or its
replacement operator (as the case may be).
v. Before the expiry of the exit management period, the selected bidder shall deliver to
RISL or its nominated agencies all new or up-dated materials from the categories set
out above and shall not retain any copies thereof, except that the selected bidder
shall be permitted to retain one copy of such materials for archival purposes only.
e) Transfer of certain agreements
i. On request by Procuring entity or its nominated agencies, the selected bidder shall
effect such assignments, transfers, innovations, licenses and sub-licenses as
Procuring entity or its nominated agencies may require in favour of procuring entity or
its nominated agencies, or its replacement operator in relation to any equipment
lease, maintenance or service provision agreement between selected bidder and
third party leasers, operators, or operator, and which are related to the services and
“Design, Development and Implementation of Store Management System (SMS)”
Page 76 of 198
reasonably necessary for carrying out of the replacement services by RISL or its
nominated agencies, or its replacement operator.
ii. Right of Access to Premises: At any time during the exit management period and for
such period of time following termination or expiry of the SLA, where assets are
located at the selected bidder’s premises, the selected bidder will be obliged to give
reasonable rights of access to (or, in the case of assets located on a third party's
premises, procure reasonable rights of access to RISL or its nominated agencies,
and/ or any replacement operator in order to inventory the assets.
f) General Obligations of the selected bidder
i. The selected bidder shall provide all such information as may reasonably be
necessary to effect as seamless during handover as practicable in the circumstances
to RISL or its nominated agencies or its replacement operator and which the operator
has in its possession or control at any time during the exit management period.
ii. The selected bidder shall commit adequate resources to comply with its obligations
under this Exit Management Clause.
g) Exit Management Plan
i. The selected bidder shall provide RISL or its nominated agencies with a
recommended exit management plan ("Exit Management Plan") which shall deal with
at least the following aspects of exit management in relation to the SLA as a whole
and in relation to the Project Implementation, the Operation and Management SLA
and SOWs.
ii. A detailed program of the transfer process that could be used in conjunction with a
replacement operator including details of the means to be used to ensure continuing
provision of the services throughout the transfer process or until the cessation of the
services and of the management structure to be used during the transfer; and
iii. Plans for the communication with such of the selected bidder's, staff, suppliers,
customers and any related third party as are necessary to avoid any material
detrimental impact on RISL operations as a result of undertaking the transfer; and
iv. If applicable, proposed arrangements and Plans for provision of contingent support in
terms of business continuance and hand holding during the transition period, to RISL
or its nominated agencies, and Replacement Operator for a reasonable period, so
that the services provided continue and do not come to a halt.
v. The selected bidder shall re-draft the Exit Management Plan annually after signing of
contract to ensure that it is kept relevant and up to date.
vi. Each Exit Management Plan shall be presented by the selected bidder to and
approved by RISL or its nominated agencies.
“Design, Development and Implementation of Store Management System (SMS)”
Page 77 of 198
vii. In the event of termination or expiry of SLA, Project Implementation, Operation and
Management SLA or SOWs each party shall comply with the Exit Management Plan.
viii. During the exit management period, the selected bidder shall use its best efforts to
deliver the services.
ix. Payments during the Exit Management period shall be made in accordance with the
Terms of Payment Clause.
x. It would be the responsibility of the selected bidder to support new operator during
the transition period.
6.36 Settlement of Disputes
a) General: If any dispute arises between the supplier/ selected bidder and RISL during the
execution of a contract that should be amicably settled by mutual discussions. However, if
the dispute is not settled by mutual discussions, a written representation will be obtained
from the supplier/ selected bidder on the points of dispute. The representation so received
shall be examined by the concerned Procurement Committee which sanctioned the tender.
The Procurement Committee may take legal advice of a counsel and then examine the
representation. The supplier/ selected bidder will also be given an opportunity of being
heard. The Committee will take a decision on the representation and convey it in writing to
the supplier/ selected bidder.
b) Standing Committee for Settlement of Disputes: If a question, difference or objection arises
in connection with or out of the contract/ agreement or the meaning of operation of any
part, thereof or the rights, duties or liabilities of either party have not been settled by mutual
discussions or the decision of tender sanctioning Procurement Committee, it shall be
referred to the empowered standing committee for decision, if the amount of the claim is
more than Rs. 50,000/-. The empowered standing committee shall consist of following
members: - (RISL)
Chairman of BoD of RISL : Chairman
Secretary, DoIT&C or his nominee,
not below the rank of Deputy Secretary : Member
Managing Director, RISL : Member
Director (Technical)/ Executive Director, RISL : Member
Director (Finance), RISL : Member
A Legal Expert to be nominated by the Chairman : Member
c) Procedure for reference to the Standing Committee: The supplier/ selected bidder shall
present his representation to the Managing Director, RISL along with a fee equal to two
percent of the amount of dispute, not exceeding Rupees One Lakh, within one month from
the date of communication of decision of the tender sanctioning Procurement Committee.
“Design, Development and Implementation of Store Management System (SMS)”
Page 78 of 198
The officer-in-charge of the project who was responsible for taking delivery of the goods
and/ or service from the supplier/ selected bidder shall prepare a reply of representation
and shall represent the RISL’s stand before the standing committee. From the side of the
supplier/ selected bidder, the claim case may be presented by himself or through a lawyer.
After hearing both the parties, the standing committee shall announce its decision which
shall be final and binding both on the supplier/ selected bidder and RISL. The standing
committee, if it so decides, may refer the matter to the Board of Directors of RISL for
further decision.
d) Legal Jurisdiction: All legal proceedings arising out of any dispute between both the parties
regarding a contract shall be settled by a competent court having jurisdiction over the
place, where agreement has been executed and by no other court, after decision of the
standing committee for settlement of disputes.
“Design, Development and Implementation of Store Management System (SMS)”
Page 79 of 198
7. SPECIAL TERMS AND CONDITIONS OF TENDER & CONTRACT
7.1 Payment Terms and Schedule
a) Payment schedule - Payments to the bidder, after successful completion of the target
milestones (including specified project deliverables), would be made as under: -
S.No. Milestones Project Deliverables Payment
1 Undertaking activities as mentioned in Scope of Work section 4.1
FRS & SRS Document Approval of FRS & SRS by RISL
20 % of Agreement
value
2
Undertaking activities as
mentioned in Scope of
Work section 4.2, 4.4,
4.6, 4.7 and 4.8
Configuration & Deployment document with source code in two sets of DVDs along with source code and/or license of third party API/any other software used.
Test cases and Test report. Data Digitization & Migration
Acceptance Report.
40 % of Agreement
value
3
Undertaking activities as
mentioned in Scope of
Work section 4.5, 4.6,
4.8, 4.12
UAT Sign Off Certificate From RISL/Department
Hardware supply and
commissioning report
25 % of Agreement
value
4
Undertaking activities as
mentioned in Scope of
Work section 4.9 and
4.10
User Manual, Training documentation, Hand-outs
Training Completion Certificate Certificate for Go-Live by RISL
Equally Quarterly
instalments for a
period of One Year
i.e. 3.75 % of
Agreement value
per quarter
b) The supplier’s/ selected bidder’s request for payment shall be made to the purchaser in
writing, accompanied by invoices describing, as appropriate, the goods delivered and related
services performed, and by the required documents submitted pursuant to general conditions
of the contract and upon fulfilment of all the obligations stipulated in the Contract.
c) Due payments shall be made promptly by the purchaser, generally within sixty (60) days after
submission of an invoice or request for payment by the supplier/ selected bidder.
d) The currency or currencies in which payments shall be made to the supplier/ selected bidder
under this Contract shall be Indian National Rupees (INR) only.
e) All remittance charges will be borne by the supplier/ selected bidder.
f) In case of disputed items, the disputed amount shall be withheld and will be paid only after
settlement of the dispute.
“Design, Development and Implementation of Store Management System (SMS)”
Page 80 of 198
g) Payment in case of those goods which need testing shall be made only when such tests have
been carried out, test results received conforming to the prescribed specification.
h) Any penalties/ liquidated damages, as applicable, for delay and non-performance, as
mentioned in this bidding document, will be deducted from the payments for the respective
milestones.
i) Taxes, as applicable, will be deducted/ paid as per the prevalent rules and regulations.
7.2 Service Level Standards/ Requirements/ Agreement
a) Purpose & Duration of SLA: The SLA purpose is to enforce a contract between the bidder and
purchaser. The SLA would come into effect from the date of commissioning and until the
successful completion of the Operations & Maintenance period of 1 year.
b) Escalation Procedure: RISL/Rajasthan Police will inform the selected bidder about any
incident, deviation, non-performance etc. through an e-mail/letter/phone etc. The SLA timeline
for the incident will start whenever a communication is made as described above.
RISL/Rajasthan Police and selected bidder would maintain a SLA register/log in which
information about each error, deviation and non-performance will be noted such as nature of
error, timing, elapsed time, response provided by selected bidder, timing of response,
feedback etc. and any other relevant information.
c) Dependencies: the dependencies on the performance of services beyond the control of either
party and where default is due to reasons beyond the control of the selected bidder or due to
the reasons attributable to RISL or third parties, the selected bidder would not be penalized.
d) Monitoring & Evaluation: RISL/Rajasthan Police and the selected bidder shall maintain a log of all
reported incidents along with basic details such as nature of incident, time of occurrence, place etc.
RISL/Rajasthan Police will review the performance on SLAs according to the response provided by the
selected bidder.
e) Penalty for Non-performance in required Service Levels/ Standards
If the selected bidder fails to deliver the required services due to reasons attributable to him like
non-functioning of the hardware/ system, non-accessibility of the application, non-availability of the
technical personnel/ manpower, etc. the cumulative penalty, as applicable, would be imposed as
mentioned bellow while processing the payment for respective milestone.
i. Penalty for Downtime of IT Infrastructure deployed at various project locations:
The below mentioned table describes item wise schedule of expected time allowed to
selected bidder to maintain items in up and running condition. The penalty shall be
imposed in case selected bidder fails to resolve complaint in expected time
“Design, Development and Implementation of Store Management System (SMS)”
Page 81 of 198
Items Time Penalty Time Penalty Time Penalty
Desktop Less than 2 Days No Penalty 2–4
Days Rs. 500/day 4–6 Days Rs. 1000/day
MFP Less than 2 Days No Penalty 2–4
Days Rs. 500/day 4–6 Days Rs. 1000/day
UPS Less than 2 Days No Penalty 2–4
Days Rs. 500/day 4–6 Days Rs. 1000/day
Biometric device
Less than 2 Days No Penalty 2–4
Days Rs. 500/day 4–6 Days Rs. 1000/day
*Non rectification of incident for more than 7 days for 2 or more consecutive months may be
considered as a breach of contract
ii. Penalty for downtime of software application
The penalty defined below is applicable foe web based application software not
functional/accessible. If the website/application is up and running at RSDC then penalty defined
below will not be applicable.
Delay (in days) Penalty
Less than 2 Days No penalty
2 – 4 Days Rs. 1000/day
4 – 7 Days Rs. 2000/day
Note: Non-availability of software application for 7 days for 2 or more consecutive months may
be treated as a breach of contract
iii. Penalty for Absence
In the case of absence of resources from the project site (beyond Government Holidays and allowed leaves of 18 days per calendar year effective from the date of deployment), penalty of INR 1000 per day shall be applicable for each additional leave taken.
iv. Penalty for non-timely performing software support services
Delay (in days) Penalty Up-to 2 day No penalty
3-5 days Rs. 5000/day
5-10 days Rs. 1000/day
Note: Non-timely update and software support for 10 or more days for 2 or more consecutive months may be treated as a breach of contract
“Design, Development and Implementation of Store Management System (SMS)”
Page 82 of 198
Note:
Any delay/non-performance, not attributable to the selected bidder, shall not be taken into
the account while computing adherence to service levels but the selected bidder shall
submit sufficient records/ documents that the delay/ non-performance is not on his part.
The resources shall be allowed to avail 18 leaves per year from the date of deployment of
the resource on prorate basis accrued every quarter. Deployed resource shall ensure prior
approval of leave from the concerned Office-In-Charge.
The maximum total penalty in any quarter shall not be more than 15% of the total amount
due for the quarter. Imposition of penalties amounting to 15% of the quarterly contract
value for a continuous period of 2 quarters shall be treated as non-performance and
beyond which the tendering authority may initiate action as per RFP terms and condition
for breach of SLA if not satisfied with the response given by the selected bidder for reasons
thereof. The tendering authority may also forfeit the PSD and also debar the Selected
bidder from bidding (for all types and form of bids) for at least three years in RISL and
DoIT&C.
7.3 Change Requests/ Management
a) An institutional mechanism will be set up for taking decisions regarding requests for
changes. The Purchase Committee will set up a Change Control Committee with members
from the procurement agency and the selected bidder. If it is unable to reach an
agreement, the decision of the Purchase Committee will be final.
b) RISL may at any time, by a written order given to the selected bidder , make changes
within the general scope of the Agreement in any one or more of the following: -
Designs, specifications, requirements which software or service to be provided under
the Agreement are to be specifically developed and rendered for RISL.
The method of deployment, shipping or packing.
Schedule for Installation Acceptance.
The place of delivery and/or the services to be provided by the selected bidder.
c) The change request/ management procedure will follow the following steps: -
Identification and documentation of the need for the change - The information related to
initiator, initiation date and details of change required and priority of the change will be
documented by RISL.
Analysis and evaluation of the Change Request - Impact of the change in terms of the
estimated effort, changed schedule, cost and the items impacted will be analysed and
documented by the selected bidder.
“Design, Development and Implementation of Store Management System (SMS)”
Page 83 of 198
Approval or disapproval of the change request – RISL will approve or disapprove the
change requested including the additional payments for software development, quoted
man-month rate shall be used for cost estimation, efforts of all technical resources-
project manager, analyst, software developer, testing engineer, database architecture
etc shall be taken into account for total man-month estimation to carry out the software
development resulting from the change request. For all technical resources irrespective
of their experience and specialisation, the quoted man-month rate shall be used.
Efforts of support staff shall not be taken into consideration for this purpose.
Implementation of the change – The change will be implemented in accordance to the
agreed cost, effort, and schedule by the selected bidder.
Verification of the change - The change will be verified by RISL on implementation of
the change request.
d) All changes outside the scope of supplies agreed to herein which may have likely financial
implications in terms of the overall cost/ time of the project shall be undertaken by selected
bidder only after securing the express consent of RISL. In the event that the consent of
RISL is not received then the change will not be carried out.
e) While approving any change request, if required, RISL may ask the selected bidder to
deploy the required resources on-site.
f) If any such change outside the scope of supplies agreed to herein causes an increase or
decrease in cost of, or the time required for, firm’s performance of any provisions under the
Agreement, equitable adjustments shall be made in the Agreement Price or Delivery
Schedule, or both, and the Agreement shall accordingly be amended. Any claims by firm
for adjustment under this must be asserted within 30 (thirty) days from the date of selected
bidder receiving the RISL change order which shall not be unreasonably withheld or
delayed.
“Design, Development and Implementation of Store Management System (SMS)”
Page 84 of 198
ANNEXURE-1: BILL OF MATERIAL (BoM)
S. No. Equipment Qty MAF Required (Yes/ No)
1. Desktop System i3 with 2 GB RAM (with 800 VA UPS) 87 Yes
2. 800 VA UPS 87 Yes
3. Laser Network Multifunction Printer 80 Yes
4. Biometric Devices 100 Yes
“Design, Development and Implementation of Store Management System (SMS)”
Page 85 of 198
ANNEXURE-2: TECHNICAL STANDARDS & SPECIFICATIONS
STANDARDS
1. Application Design & Development a) Compliance with industry standards: Solution shall be compliant with industry
standards wherever applicable. This will apply to all the aspects of solution including but
not limited to design, development, security, installation, and testing.
b) Platform Flexibility: Open Standards and Interoperability (Usage of standard APIs)
shall be considered Web-centric, multi-tier architecture shall be used.
c) Compliance to SOA and EAI: Application shall be based on Service Oriented
Architecture (SOA) and EAI. All modules of the application shall expose key functionality
through Software APIs in form of SOAP & WS-* or JSON & REST etc. so that they can
be consumed by other applications.
d) User Interface: The application’s UI should be based on HTML5 standard only and
should be compatible with all devices like Desktop, Smartphone and tablet etc. The
application interface should be responsive.
e) Error Handling: Ensure applications execute proper error handling so that errors will
not provide detailed system information, deny service, impair security mechanisms, or
crash the system.
f) Rich User experience: The solution should have capability where any services like
Payment Gateway, the mobile devices for queries/ reporting and providing day-to-day
approvals by competent authorities as per authorized workflow for different kind of
requests; and external entities like bank, departments and others can invoke this
framework by passing the required parameters and specifying the desired output.
2. Technology Standards a) Browser Compatibility: The FMDSS Application should support common web and
mobile browsers like Google Chrome, Internet Explorer, Firefox, Safari and Opera Mini
etc.
b) Bi-Lingual Support: Application shall support at least Unicode 5.1/ 6.0 standard based
Bi-lingual versions for user interface. It is expected to be in the Hindi and English (India)
languages.
c) Anywhere Access: Application shall be deployed on state government data centre to
enable anytime, anywhere access and to address auto-sync/save, efficiency, peak load
“Design, Development and Implementation of Store Management System (SMS)”
Page 86 of 198
handling issues. The application should also function on the low bandwidth (64 Kbps/
GPRS).
d) Scalability, Reliability and Flexibility: The technology must be scalable with
Department’s emerging requirements and must continue to be reliable as the
information handling needs of the government increases. The architecture must be
scalable and flexible for modular expansion.
e) Interoperability: The system should be interoperable and should comply with open
standards for easy integration. The entire system/ subsystem should be interoperable,
in order to support information flow and integration. Operating systems and storage
technologies from several suppliers must interact well with each other.
f) Single Sign On (SSO): Government of Rajasthan, as part of its e-Governance action
plan, is in the process of implementing central Single Sign-On (SSO) infrastructure in
Rajasthan State Data Center (RSDC), Jaipur.
Rajasthan SSO is being implemented using Microsoft platform and includes the
following:
o Identity Provider: MS-Active Directory Services (ADS) on MS-Windows Server
2012 R2 Standard Edition.
o SSO Application: MS .Net Framework 4.x based web application that provides a
secure SSO Application Interface including interface and secure web services for
Identity and Application management lifecycle.
The entire identity management lifecycle is managed through a custom .Net web
based secure GUI application and web services and a set of readymade libraries.
Similarly, the application registration and role mapping activities are also managed by
a custom .Net web based secure GUI application.
Process Flow: Only upon successfully authentication (MS-ADS), the end-user would
land on the SSO Application wherein he would see a list of all the SSO-enabled
applications. Once the authenticated user clicks on any application under the SSO
Application, his role/ access to that application is validated with MS-ADS in a secured
manner and depending upon his role, access is denied/ granted to that application
with the set of privileges mapped to the assigned role by that application. The user,
after having finished his/ her work with the application, can go-back to SSO
Application to select another application or directly Logout from the existing
application.
The SSO application would also enable an authenticated user to review/ update his
profile (self-service) using the SSO application. The audit trail of all the actions
“Design, Development and Implementation of Store Management System (SMS)”
Page 87 of 198
performed by an authenticated user on Rajasthan SSO would be maintained in a
separate database.
g) Presentation Layer: The presentation layer i.e. User Interface would be used for the
receiving and delivery information for to and from the end-user of the application. It
should be responsive.
h) Workflow System: Workflow would be used with the automation of procedures where
documents, information or tasks are passed among participants according to a defined
set of rules to achieve, or contribute to an overall business goal. A workflow system
would manage and monitor the state of activities in a workflow, such as the processing
and approval of various application forms, and determines which new activity to
transition to according to defined processes.
3. Security Standards a) Application Access: Ensure applications processing data properly for authenticated
users (through central authentication systems), specifically: SSO Login. Establish
authorizations for applications by affiliation, membership, or employment, rather than by
individual. If individual authorizations are used, these should expire and require renewal
on a periodic (at least annually) basis.
b) Review: Conduct code-level security reviews with professionally trained peers for all
new or significantly modified applications; particularly, those that affect the collection,
use, and/or display of confidential data. Conduct annual security tests of Internet
applications.
c) Security: application shall support both HTTP and HTTPS (SSL certificate shall be
provided by Purchaser).
4. Quality Management Standards
a) All project deliverables will be subject to a review and approval process and will be
signed off by the purchaser.
b) Peer reviews will be held for business design and technical design documents, and
code-walkthroughs for non-generated code.
c) Defining a test strategy has been scheduled in the Business Design phase. This
strategy will include the development of test scenarios, test cases and a detailed test
plan.
d) An acceptance test task is included in the work plan to enable the business area to test
the final product in a production-like environment prior to implementation. The initial
requirements for this acceptance test will be documented during the business design.
e) All system and application deliverables will be signed off prior to migration to production.
“Design, Development and Implementation of Store Management System (SMS)”
Page 89 of 198
ANNEXURE-3: PRE-BID QUERIES FORMAT
Name of the Company/Firm: Bidding Document Fee Receipt No. ___________ Dated___________ for Rs. _____________/- Name of Person(s) Representing the Company/ Firm: Name of Person Designation Email-ID(s) Tel. Nos. & Fax Nos.
Company/Firm Contacts: Contact Person(s) Address for
Correspondence Email-ID(s) Tel. Nos. & Fax Nos.
Query / Clarification Sought: S.No. RFP
Page No. RFP Rule No.
Rule Details Query/ Suggestion/ Clarification
Note: - Queries must be strictly submitted only in the prescribed format (.XLS/ .XLSX/ .ODF).
Queries not submitted in the prescribed format will not be considered/ responded at all by the
procuring entity. Also, kindly attach the coloured scanned copy of the receipt towards the
submission of the bidding/ tender document fee.
“Design, Development and Implementation of Store Management System (SMS)”
Page 90 of 198
ANNEXURE-4: BIDDER’S AUTHORIZATION CERTIFICATE
To, {Procuring entity}, ______________________________, ______________________________, I/ We {Name/ Designation} hereby declare/ certify that {Name/ Designation} is hereby authorized to sign relevant documents on behalf of the company/ firm in dealing with NIB reference No. ______________________ dated _________. He/ She is also authorized to attend meetings & submit technical & commercial information/ clarifications as may be required by you in the course of processing the Bid. For the purpose of validation, his/ her verified signatures are as under. Thanking you, Name of the Bidder: - Verified Signature: Authorised Signatory: - Seal of the Organization: - Date: Place:
“Design, Development and Implementation of Store Management System (SMS)”
Page 91 of 198
ANNEXURE-5: SELF-DECLARATION
To, {Procuring entity}, ______________________________, In response to the NIB Ref. No. _____________________________ dated ___________ for {Project Title}, as an Owner/ Partner/ Director/ Auth. Sign. of ____________________________________, I/ We hereby declare that presently our Company/ firm _________________, at the time of bidding,: -
a) possess the necessary professional, technical, financial and managerial resources and competence required by the Bidding Document issued by the Procuring Entity;
b) have fulfilled my/ our obligation to pay such of the taxes payable to the Union and the State Government or any local authority as specified in the Bidding Document;
c) is having unblemished record and is not declared ineligible for corrupt & fraudulent practices either indefinitely or for a particular period of time by any State/ Central government/ PSU/ UT.
d) does not have any previous transgressions with any entity in India or any other country during the last three years
e) does not have any debarment by any other procuring entity f) is not insolvent in receivership, bankrupt or being wound up, not have its affairs
administered by a court or a judicial officer, not have its business activities suspended and is not the subject of legal proceedings for any of the foregoing reasons;
g) does not have, and our directors and officers not have been convicted of any criminal offence related to their professional conduct or the making of false statements or misrepresentations as to their qualifications to enter into a procurement contract within a period of three years preceding the commencement of the procurement process, or not have been otherwise disqualified pursuant to debarment proceedings;
h) does not have a conflict of interest as mentioned in the bidding document which materially affects the fair competition.
i) will comply with the code of integrity as specified in the bidding document. j) I/we undertake, for timely establishment of a local office in Jaipur (if the award is made to
us) and within 2 months from the date of issue of LOI k) We have an existing office at Jaipur at the following address. In case the bidder does not
has an existing office at Jaipur, then bidder undertakes to open an office in Jaipur within one month of issue of LOI. ……………………………………………………………………………………………………..
If this declaration is found to be incorrect then without prejudice to any other action that may be taken as per the provisions of the applicable Act and Rules thereto prescribed by GoR, my/ our security may be forfeited in full and our bid, to the extent accepted, may be cancelled. Thanking you,
“Design, Development and Implementation of Store Management System (SMS)”
Page 92 of 198
Name of the Bidder: - Authorised Signatory: - Seal of the Organization: - Date: Place:
“Design, Development and Implementation of Store Management System (SMS)”
Page 93 of 198
ANNEXURE-6: CERTIFICATE OF CONFORMITY/ NO DEVIATION
To, {Procuring Entity}, ______________________________, CERTIFICATE This is to certify that, the specifications of Hardware & Software which I/ We have mentioned in the Technical bid, and which I/ We shall supply if I/ We am/ are awarded with the work, are in conformity with the minimum specifications of the bidding document and that there are no deviations of any kind from the requirement specifications. Also, I/ we have thoroughly read the bidding document and by signing this certificate, we hereby submit our token of unconditional acceptance to all the terms & conditions of the bidding document without any deviations. I/ We also certify that the price I/ we have quoted is inclusive of all the cost factors involved in the end-to-end implementation and execution of the project, to meet the desired Standards set out in the bidding Document. Thanking you, Name of the Bidder: - Authorised Signatory: - Seal of the Organization: - Date: Place:
“Design, Development and Implementation of Store Management System (SMS)”
Page 94 of 198
ANNEXURE-7: DECLARATION BY BIDDER
I/ We declare that I am/we are bonafide/ Manufacturers/ Whole Sellers/ Sole distributor/ Authorised dealer/ dealers/ sole selling/ Marketing agent in the goods/ stores/ equipment for which I/ We have quoted. If this declaration is found to be incorrect then without prejudice to any other action that may be taken, my/ our security may be forfeited in full and the bid, if any, to the extent accepted may be cancelled. Name of the Bidder: - Authorised Signatory: - Seal of the Organization: - Date: Place:
“Design, Development and Implementation of Store Management System (SMS)”
Page 95 of 198
ANNEXURE-8: MANUFACTURER’S AUTHORIZATION FORM (MAF)
(Indicative Format)
To, {Procuring Entity}, ______________________________, Subject: Issue of the Manufacturer’s Authorisation Form (MAF) Reference: NIB/ RFP Ref. No. _____________________ dated ________ Sir, We {name and address of the OEM} who are established and reputed original equipment manufacturers (OEMs) having factories at {addresses of manufacturing location} do hereby authorize {M/s __________________________} who is our {Distributor/ Channel Partner/ Retailer/ Others <please specify>} to bid, negotiate and conclude the contract with you against the aforementioned reference for the following Hardware/ Software manufactured by us: -
{OEM will mention the details of all the proposed product(s) with their make/ model.}
We undertake to provide OEM Warranty for the offered Hardware/ Software, as mentioned above, for 3 Years. We hereby confirm that the offered Hardware/ Software is not likely to be declared as End-of-Sale within next 6 months from the date of bid submission. We hereby confirm that the offered Hardware/ Software is not likely to be declared as End-of-Service/ Support within next 3 years from the date of bid submission.] Yours faithfully, For and on behalf of M/s (Name of the manufacturer) (Authorized Signatory) Name, Designation & Contact No.: Address: ___________________________________ Seal:
“Design, Development and Implementation of Store Management System (SMS)”
Page 96 of 198
ANNEXURE-9: UNDERTAKING ON AUTHENTICITY OF COMPUTER EQUIPMENTS
{to be filled by the bidder (On Rs. 100/- Non-judicial stamp paper)}
To, {Procuring Entity}, ______________________________, Reference: NIB No. :___________________________________ Dated:__________ This has reference to the items being supplied/ quoted to you vide bid ref. no. ___________ dated ___________. We hereby undertake that all the components/ parts/ assembly/ software used in the equipment shall be genuine, original and new components /parts/ assembly/ software from respective OEMs of the products and that no refurbished/ duplicate/ second hand components/ parts/ assembly/ software are being used or shall be used. In respect of licensed operating system, we undertake that the same shall be supplied along with the authorized license certificate with our name/logo. Also, that it shall be sourced from the authorized source for use in India. In case, we are found not complying with above at the time of delivery or during installation, for the equipment already billed, we agree to take back the equipment already supplied at our cost and return any amount paid to us by you in this regard and that you will have the right to forfeit our Bid Security/ SD/ PSD for this bid or debar/ black list us or take suitable action against us. Authorized Signatory Name: Designation: Note: The signing Authority should be no lower than Company Secretary of the bidder.
“Design, Development and Implementation of Store Management System (SMS)”
Page 97 of 198
ANNEXURE-10: FINANCIAL BID COVER LETTER & FORMAT
COVER LETTER
To, {Procuring Entity}, ______________________________, Reference: NIB No. :___________________________________ Dated:__________ Dear Sir, We, the undersigned bidder, Having read & examined in detail, the Bidding Document, the receipt of which is hereby duly acknowledged, I/ we, the undersigned, offer to supply/ work as mentioned in the Scope of the work, Bill of Material, Technical specifications, Service Level Standards & in conformity with the said bidding document for the same. I / We undertake that the prices are in conformity with the specifications prescribed. The quote/ price are inclusive of all cost likely to be incurred for executing this work. The prices are inclusive of all type of govt. taxes/duties. I / We undertake, if our bid is accepted, to deliver the goods in accordance with the delivery schedule specified in the schedule of Requirements. I/ We hereby declare that in case the contract is awarded to us, we shall submit the contract performance guarantee as prescribed in the bidding document. I / We agree to abide by this bid for a period of _____ days after the last date fixed for bid submission and it shall remain binding upon us and may be accepted at any time before the expiry of that period. Until a formal contract is prepared and executed, this bid, together with your written acceptance thereof and your notification of award shall constitute a binding Contract between us. I/ We hereby declare that our bid is made in good faith, without collusion or fraud and the information contained in the bid is true and correct to the best of our knowledge and belief.
“Design, Development and Implementation of Store Management System (SMS)”
Page 98 of 198
We understand that you are not bound to accept the lowest or any bid you may receive. We agree to all the terms & conditions as mentioned in the bidding document and submit that we have not submitted any deviations in this regard. Date: Authorized Signatory Name: Designation:
“Design, Development and Implementation of Store Management System (SMS)”
Page 99 of 198
Financial Bid Format Consolidated Commercial Bid
S. No. Item no. and Description Cost in INR inclusive of all Incidental Charges and Taxes
1. Total Cost of A1
2. Total Cost of A2
3. Total Cost of A3
Total Cost (in figures) – Rs.
Total Cost (in words) – Rs.
A1) Hardware Equipment’s
S. No.
Item No. and Description Unit Qty
Base Unit Cost in INR (incl. all
Incident Charges and Taxes but excl. VAT/CST)
VAT/CST on Base
Unit Cost (In INR)
Total Cost in INR (incl. all
Incident Charges and
Taxes)
1 2 3 4 5 = 2 * (3 + 4)
1 Desktop Computer (incl. OS + AntiVirus + Open Office +800 VA UPS)
Nos. 87
2 Laser Network Multi-function Printer
Nos. 80
3 Biometric Devices Nos. 100
Total A1 (in figures) – Rs.
Total A1 (in words) – Rupees
“Design, Development and Implementation of Store Management System (SMS)”
Page 100 of 198
A2) Design, Development and Implementation of Store Management System along with One Year Operation & Maintenance Support Services
S. No.
Item No. and Description
Unit of Measure
ment
Base Unit Cost in INR (incl. all
Incident Charges and Taxes but
excl. Service Tax )
Service Tax
(In INR)
Total Cost in INR (incl. all
Incident Charges and
Taxes)
1 2 3 4 = (2 + 3)
1
Design, Development and Implementation of Store Management System along with One Year Operation & Maintenance Support Services
Lump Sum
Total A2 (in figures) – Rs.
Total A2 (in words) – Rupees
A3) Miscellaneous Cost
S. No.
Item No. and Description
Unit of Measurement
Indicative Qty* (Man
Month and Session)
Base Unit Cost in INR (incl. all
Incident Charges and
Taxes but excl. Service Tax )
Service Tax
(In INR)
Total Cost in INR
(incl. all Incident Charges
and Taxes)
1 2 3 4 = (2 + 3)
1 Data Digitization Man-month
30
2 Training. Per Session 40
3 Man-month rate for undertaking change request
Man Month
15
Total A3 (in figures) – Rs.
Total A3 (in words) – Rupees
Note*: the above mentioned quantities are indicative only for the purpose of financial bid evaluation, however, the payment to the selected bidder shall be made on actuals
“Design, Development and Implementation of Store Management System (SMS)”
Page 101 of 198
ANNEXURE-11: BANK GUARANTEE FORMAT
BANK GUARANTEE FORMAT – BID SECURITY (To be stamped in accordance with Stamp Act and to be issued by a Nationalised/ Scheduled bank having its branch at Jaipur and payable at par at Jaipur, Rajasthan)
To, The Managing Director, RajCOMP Info Services Limited (RISL), First Floor, Yojana Bhawan, C-Block, Tilak Marg, C-Scheme, Jaipur-302005 (Raj). Sir, 1. In accordance with your Notice Inviting Bid for “Design, Development, Installation and
Maintenance of Store Management System of Rajasthan Police, GoR and O&M for 1 year” vide NIB reference no. <please specify> M/s. …………………………….. (Name & full address of the firm) (Hereinafter called the “Bidder”) hereby submits the Bank Guarantee to participate in the said procurement/ bidding process as mentioned in the bidding document. It is a condition in the bidding documents that the bidder has to deposit Bid Security amounting to Rs. ____________(Rupees ____________Only ) in respect to the NIB Ref. No. _______________ dated _________ issued by RISL, First Floor, Yojana Bhawan, C-Block, Tilak Marg, C-Scheme, Jaipur, Rajasthan (hereinafter referred to as “RISL”) by a Bank Guarantee from a Nationalised Bank/ Scheduled Commercial Bank having its branch at Jaipur irrevocable and operative till the bid validity date (i.e. 90 days from the date of submission of bid). It may be extended if required in concurrence with the bid validity. And whereas the bidder desires to furnish a Bank Guarantee for a sum of Rs. ____________(Rupees ______________ Only) to the RISL as earnest money deposit.
2. Now, therefore, we the ……………………………….…… (Bank), a body corporate constituted under the Banking Companies (Acquisition and Transfer of Undertaking) Act. 1969 (delete, if not applicable) and branch Office at…………………... (Hereinafter referred to as the Guarantor) do hereby undertake and agree to pay forthwith on demand in writing by the RISL of the said guaranteed amount without any demur, reservation or recourse.
3. We, the aforesaid bank, further agree that the RISL shall be the sole judge of and as to whether the bidder has committed any breach or breaches of any of the terms costs, charges and expenses caused to or suffered by or that may be caused to or suffered by the RISL on account thereof to the extent of the Earnest Money required to be deposited by the bidder in respect of the said bidding document and the decision of the RISL that the bidder has committed such breach or breaches and as to the amount or amounts of loss, damage, costs, charges and expenses caused to or suffered by or that may be caused to or suffered by the RISL shall be final and binding on us.
4. We, the said Bank further agree that the Guarantee herein contained shall remain in full force and effect until it is released by the RISL and it is further declared that it shall not be necessary for the RISL to proceed against the bidder before proceeding against the Bank and
“Design, Development and Implementation of Store Management System (SMS)”
Page 102 of 198
the Guarantee herein contained shall be invoked against the Bank, notwithstanding any security which the RISL may have obtained or shall be obtained from the bidder at any time when proceedings are taken against the Bank for whatever amount that may be outstanding or unrealized under the Guarantee.
5. Any notice by way of demand or otherwise hereunder may be sent by special courier, telex, fax, registered post or other electronic media to our address, as aforesaid and if sent by post, it shall be deemed to have been given to us after the expiry of 48 hours when the same has been posted.
6. If it is necessary to extend this guarantee on account of any reason whatsoever, we undertake to extend the period of this guarantee on the request of our constituent under intimation to you.
7. The right of the RISL to recover the said amount of <Rs. ______________ (Rupees <in words>)> from us in manner aforesaid will not be precluded/ affected, even if, disputes have been raised by the said M/s. ……….………………(bidder) and/ or dispute or disputes are pending before any court, authority, officer, tribunal, arbitrator(s) etc..
8. Notwithstanding anything stated above, our liability under this guarantee shall be restricted to <Rs. ______________ (Rupees <in words>)> and our guarantee shall remain in force till bid validity period i.e. <please specify> days from the last date of bid submission and unless a demand or claim under the guarantee is made on us in writing within three months after the Bid validity date, all your rights under the guarantee shall be forfeited and we shall be relieved and discharged from all liability thereunder.
9. This guarantee shall be governed by and construed in accordance with the Indian Laws and we hereby submit to the exclusive jurisdiction of courts of Justice in India for the purpose of any suit or action or other proceedings arising out of this guarantee or the subject matter hereof brought by you may not be enforced in or by such count.
10. We hereby confirm that we have the power/s to issue this Guarantee in your favor under the Memorandum and Articles of Association/ Constitution of our bank and the undersigned is/are the recipient of authority by express delegation of power/s and has/have full power/s to execute this guarantee under the Power of Attorney issued by the bank in your favour.
Date ………………… (Signature) ………………………………………. Place ………………… (Printed Name) …………………………………. (Designation) …………………………………… (Bank’s common seal) …………………………. In presence of: WTTNESS (with full name, designation, address & official seal, if any) (1) ………………………………………
“Design, Development and Implementation of Store Management System (SMS)”
Page 103 of 198
……………………………………… (2) ……………………………………… ……………………………………… Bank Details Name & address of Bank: Name of contact person of Bank: Contact telephone number: GUIDELINES FOR SUBMISSION OF BANK GUARANTEE The Bank Guarantee shall fulfil the following conditions in the absence of which they cannot be considered valid: - 1. Bank Guarantee shall be executed on non- judicial stamp paper of applicable value
purchased in the name of the bank. 2. Two persons should sign as witnesses mentioning their full name, designation, address and
office seal (if any). 3. The Executor (Bank Authorities) may mention the power of attorney No. and date of execution
in his/ her favour authorizing him/ her to sign the document. The Power of Attorney to be witnessed by two persons mentioning their full name and address.
4. The Bank Guarantee should be executed by a Nationalised Bank/ Scheduled Commercial Bank only.
5. Non – Judicial stamp paper shall be used within 6 months from the date of Purchase of the same. Bank Guarantee executed on the non-judicial stamp paper after 6 (six) months of the purchase of such stamp paper shall be treated as non-valid.
6. The contents of Bank Guarantee shall be strictly as per format prescribed by RISL 7. Each page of Bank Guarantee shall bear signature and seal of the Bank and B.G. number. 8. All corrections, deletions etc. in the Bank Guarantee should be authenticated by signature of
Bank Officials signing the Bank Guarantee. 9. Bank should separately send through registered post/courier a certified copy of Bank
Guarantee, mentioning Bid reference, Bid title and bidder name, directly to the Purchaser at the following address:
“Design, Development and Implementation of Store Management System (SMS)”
Page 104 of 198
BANK GUARANTEE FORMAT – PERFORMANCE SECURITY (PBG) (To be stamped in accordance with Stamp Act and on a Stamp Paper purchased from Rajasthan State only and to be issued by a Nationalised/ Scheduled bank having its branch at Jaipur and payable at par at Jaipur, Rajasthan) To, The Managing Director, RajCOMP Info Services Limited (RISL), First Floor, Yojana Bhawan, C-Block, Tilak Marg, C-Scheme, Jaipur-302005 (Raj). 1. In consideration of the RajCOMP Info Services Limited (hereinafter called "RISL") having
agreed to exempt M/s ..........................(hereinafter called "the said Contractor(s)" from the demand, under the terms and conditions of an Agreement No..................................dated .....................made between the RISL through …………………… and .......................(Contractor) for the work .................(hereinafter called "the said Agreement") of Security Deposit for the due fulfilment by the said Contractor (s) of the terms and conditions contained in the said Agreement, on production of a Bank Guarantee for Rs...................(rupees ........................................only), we ...................(indicate the name of the Bank), (hereinafter referred to as "the Bank") at the request of ..................Contractor(s) do hereby undertake to pay to the RISL an amount not exceeding Rs...................(Rupees..................................only) on demand.
2. We................. (Indicate the name of Bank), do hereby undertake to pay Rs.................... (Rupees............................only), the amounts due and payable under this guarantee without any demur or delay, merely on a demand from the RISL. Any such demand made on the bank by the RISL shall be conclusive as regards the amount due and payable by the Bank under this guarantee. The Bank Guarantee shall be completely at the disposal of the RISL and We....................... (Indicate the name of Bank), bound ourselves with all directions given by RISL regarding this Bank Guarantee. However, our liability under this guarantee shall be restricted to an amount not exceeding Rs...................... (Rupees....................only).
3. We.......................(indicate the name of Bank), undertake to pay to the RISL any money so demanded notwithstanding any dispute or disputes raised by the contractor(s) in any suit or proceeding pending before any Court or Tribunal or Arbitrator etc. relating thereto, our liability under these presents being absolute, unequivocal and unconditional.
4. We.....................(indicate the name of Bank) further agree that the performance guarantee herein contained shall remain in full force and effective up to <DATE> and that it shall continue to be enforceable for above specified period till all the dues of RISL under or by virtue of the said Agreement have been fully paid and its claims satisfied or discharged or till the RISL certifies that the terms and conditions of the said Agreement have been fully and properly carried out by the said Contractor(s) and accordingly discharges this guarantee.
5. We ...........................(indicate the name of Bank) further agree with the RISL that the RISL shall have the fullest liberty without our consent and without affecting in any manner our obligations hereunder to vary any of the terms and conditions of the said Agreement or to extend time of performance by the said Contractor(s) from time to time or to postpone for any time or from time to time any of the powers exercisable by the RISL against the said Contractor(s) and to forbear or enforce any of the terms and conditions relating to the said Agreement and we shall not be relieved from our liability by reason of any such variation, or extension being granted to the said Contractor(s) or for any forbearance, act or omission on
“Design, Development and Implementation of Store Management System (SMS)”
Page 105 of 198
the part of the RISL or any indulgence by the RISL to the said Contractor(s) or by any such matter or thing whatsoever which would but for this provision, have effect of so relieving us.
6. The liability of us ............................. (indicate the name of Bank), under this guarantee will not be discharged due to the change in the constitution of the Bank or the contractor(s).
7. We .............................. (indicate the name of Bank), lastly undertake not to revoke this guarantee except with the previous consent of the RISL in writing.
8. This performance Guarantee shall remain valid and in full effect, until it is decided to be discharged by the RISL. Notwithstanding anything mentioned above, our liability against this guarantee is restricted to Rs........................... (Rupees..............................only).
9. It shall not be necessary for the RISL to proceed against the contractor before proceeding against the Bank and the guarantee herein contained shall be enforceable against the Bank notwithstanding any security which the RISL may have obtained or obtain from the contractor.
10. We .............................. (indicate the name of Bank) verify that we have a branch at Jaipur. We undertake that this Bank Guarantee shall be payable at any of its branch at Jaipur. If the last day of expiry of Bank Guarantee happens to be a holiday of the Bank, the Bank Guarantee shall expire on the close of the next working day.
11. We hereby confirm that we have the power(s) to issue this guarantee in your favor under the memorandum and articles of Association/constitution of our bank and the undersigned is/are the recipient of authority by express delegation of power(s) and has/have full power(s) to execute this guarantee for the power of attorney issued by the bank.
Dated..........................day of....................For and on behalf of the <Bank> (indicate the Bank)
Signature
(Name & Designation)
Bank's Seal
The above performance Guarantee is accepted by the RISL
For and on behalf of the RISL
Signature
(Name & Designation)
“Design, Development and Implementation of Store Management System (SMS)”
Page 106 of 198
ANNEXURE-12: DRAFT AGREEMENT FORMAT
This Contract is made and entered into on this ______day of ________, 2015 by and between RajCOMP Info Services Limited (RISL), having its head office at First Floor, Yojana Bhawan, Tilak Marg, C-Scheme, Jaipur-302005, Rajasthan (herein after referred to as Purchaser/ RISL) which term or expression, unless excluded by or repugnant to the subject or context, shall include his successors in office and assignees on ONE PART And M/s__________________, a company registered under the Indian Companies Act, 1956 with its registered office at _____________________ (herein after referred as the “Successful bidder/ Supplier”) which term or expression, unless excluded by or repugnant to the subject or context, shall include his successors in office and assignees on the OTHER PART. Whereas, Purchaser is desirous of appointing an agency for <project title> as per the Scope of Work and Terms and Conditions as set forth in the RFP document dated _________ of <NIB No _________________>. And whereas M/s______________ represents that it has the necessary experience for carrying out the overall work as referred to herein and has submitted a bid and subsequent clarifications for providing the required services against said NIB and RFP document issued in this regard, in accordance with the terms and conditions set forth herein and any other reasonable requirements of the Purchaser from time to time. And whereas Purchaser has accepted the bid of supplier and has placed the Work Order vide Letter No. __________________ dated _______, on which supplier has given their acceptance vide their Letter No._____________ dated ____________. And whereas The supplier has deposited a sum of Rs. ________________/- (Rupees _________________) in the form of __________________ ref no. _________________ dated ______________ of ____________ Bank and valid up to _____________ as security deposit for the due performance of the contract. Now it is hereby agreed to by and between both the parties as under: - 1. The NIB Ref. No. ____________________________ dated ___________ and RFP document
dated _________ issued by RISL along with its enclosures/ annexures, wherever applicable, are deemed to be taken as part of this contract and are binding on both the parties executing this contract.
“Design, Development and Implementation of Store Management System (SMS)”
Page 107 of 198
2. In consideration of the payment to be made by RISL to supplier at the rates set forth in the work order no. ____________________ dated _________ will duly supply the said articles set forth in “Annexure-I: Bill of Material” thereof and provide related services in the manner set forth in the RFP, along with its enclosures/ annexures and Technical Bid along with subsequent clarifications submitted by supplier.
3. The RISL do hereby agree that if supplier shall duly supply the said articles and provide related services in the manner aforesaid observe and keep the said terms and conditions of the RFP and Contract, the RISL will pay or cause to be paid to supplier, at the time and the manner set forth in the said conditions of the RFP, the amount payable for each and every project milestone & deliverable. The mode of Payment will be as specified in the RFP document.
4. The timelines for the prescribed Scope of Work, requirement of services and deployment of technical resources shall be effected from the date of work order i.e. ____________ and completed by supplier within the period as specified in the RFP document.
5. In case of extension in the delivery and/ or installation period/ completion period with liquidated damages, the recovery shall be made on the basis of following percentages of value of stores/ works which supplier has failed to supply/ install/ complete: -
a) Delay up to one fourth period of the prescribed delivery period, successful installation & completion of work
2.5%
b) Delay exceeding one fourth but not exceeding half of the prescribed delivery period, successful installation & completion of work.
5.0%
c) Delay exceeding half but not exceeding three fourth of the prescribed delivery period, successful installation & completion of work.
7.5%
d) Delay exceeding three fourth of the prescribed delivery period, successful installation & completion of work.
10.0%
Note: i. Fraction of a day in reckoning period of delay in supplies/ maintenance services shall be
eliminated if it is less than half a day. ii. The maximum amount of agreed liquidated damages shall be 10%. iii. If supplier requires an extension of time in completion of contractual supply on account of
occurrence of any hindrances, he shall apply in writing to the authority which had placed the work order, for the same immediately on occurrence of the hindrance but not after the stipulated date of completion of supply.
iv. Delivery period may be extended with or without liquidated damages if the delay in the supply of goods in on account of hindrances beyond the control of supplier.
6. All disputes arising out of this agreement and all questions relating to the interpretation of this agreement shall be decided as per the procedure mentioned in the RFP document.
In witness whereof the parties have caused this contract to be executed by their Authorized
Signatories on this _____day of _______________, 2015.
Signed By: Signed By:
“Design, Development and Implementation of Store Management System (SMS)”
Page 108 of 198
( ) Designation:, Company:
Managing Director/Director (T), RISL
In the presence of:
In the presence of:
( ) Designation: Company:
( ) Designation: RISL
( ) Designation: Company:
( ) Designation: RISL
“Design, Development and Implementation of Store Management System (SMS)”
Page 109 of 198
ANNEXURE-13: FORMAT FOR SUBMISSION OF PROJECT REFERENCES FOR PRE-QUALIFICATION EXPERIENCE
Project Name: Value of Contract/Work Order (In INR):
Country:
Location within country:
Project Duration:
Name of Customer: Total No. of staff-months of the assignment:
Contact person with address, phone,
fax and e-mail:
Approx. value of the services provided by your
company under the contract (in INR):
Start date (month/year):
Completion date (month/year):
Name of associated bidders, if any:
Narrative description of Project:
List of Services provided by your firm/company
Please attach a copy of the work order/ completion certificate/ purchase order/ letter from the customer for each project
reference
“Design, Development and Implementation of Store Management System (SMS)”
Page 110 of 198
ANNEXURE-14: MEMORANDUM OF APPEAL UNDER THE RTPP ACT, 2012
Appeal No ………of …………… Before the ………………………… (First/ Second Appellate Authority) 1. Particulars of appellant:
a. Name of the appellant: <please specify> b. Official address, if any: <please specify> c. Residential address: <please specify>
2. Name and address of the respondent(s):
a. <please specify> b. <please specify> c. <please specify>
3. Number and date of the order appealed against and name and designation of the officer/
authority who passed the order (enclose copy), or a statement of a decision, action or omission of the procuring entity in contravention to the provisions of the Act by which the appellant is aggrieved: <please specify>
4. If the Appellant proposes to be represented by a representative, the name and postal address
of the representative: <please specify> 5. Number of affidavits and documents enclosed with the appeal: <please specify>
6. Grounds of appeal (supported by an affidavit): <please specify>
7. Prayer: <please specify> Place ……………………………………. Date ……………………………………
Appellant's Signature
“Design, Development and Implementation of Store Management System (SMS)”
Page 111 of 198
ANNEXURE-15: Expected Qualification of Manpower resources S.No. Role Desirable Qualification and Experience 1 Local Support Engineer/Executive B.Tech (CS/IT) / MCA
Fluency in English/Hindi 2+ years of post-qualification and relevant
work experience as support executive/engineer
Troubleshooting and development /coding skills to work upon minor errors, deviations etc. in application and hardware.
Note:
Selected bidder should provide the deployed resource a laptop/desktop as needed for his/her routine work.
Rajasthan Police will provide the deployed resource seating space, necessary furniture, internet connection, landline phone (if needed) etc.
“Design, Development and Implementation of Store Management System (SMS)”
Page 112 of 198
ANNEXURE-16: List of Stores and Offices, Rajasthan Police
S.No. Name of District/Unit/Wing 1 Commissionerate Jaipur 2 Jaipur Rural 3 Jhunjhunu 4 Sikar 5 Dausa 6 Alwar 7 Ajmer 8 Bhilwara 9 Nagaur 10 Tonk 11 CommissionerateJodhpur 12 Jodhpur Rural 13 Sirohi 14 Jalore 15 Barmer 16 Jaisalmer 17 Pali 18 Bharatpur 19 Karoli 20 Sawai Madhopur 21 Dholpur 22 Bikaner 23 Ganganagar 24 Hanumangarh 25 Churu 26 Udaipur 27 Banswara 28 Dungarpur 29 Chittorgarh 30 Rajsamand 31 Pratapgarh
“Design, Development and Implementation of Store Management System (SMS)”
Page 113 of 198
32 Kota City 33 Kota Rural 34 Bundi 35 Jhalawar 36 Baran 37 GRP Ajmer 38 GRP Jodhpur 39 I Bn. RAC,Jodhpur 40 II Bn. RAC, Kota 41 III Bn. RAC, Bikaner 42 IV Bn. RAC, Chainpura 43 V Bn. RAC, Jaipur 44 VI Bn. RAC, Dholpur 45 VII Bn. RAC,Bharatpur 46 VIII Bn. RAC,Delhi 47 IX Bn. RAC,Tonk 48 X Bn. RAC,Bikaner 49 XI Bn. RAC,Delhi 50 XII Bn. RAC,Delhi 51 XIII Bn. RAC,Jail,Jaipur 52 SDRF,Jaipur 53 Hadi Rani,Ajmer 54 CID (Crime Branch),Jaipur 55 CID (Inteligency Branch),Jaipur 56 MBC Kherwara 57 RPTC Jodhpur 58 PTS Jodhpur 59 PTS Kishangarh 60 PTS Kherwara 61 PTS Jhalawar 62 PTS Alwar 63 PTS Bikaner 64 PTS Bharatpur 65 CommPTS,JDR. 66 RPA Jaipur 67 PMDS Bikaner
“Design, Development and Implementation of Store Management System (SMS)”
Page 114 of 198
68 Wireless,Jaipur 69 ATS/SOG,Jaipur 70 SCRB, Jaipur 71 Central Stores,PHQ,Jaipur
*Complete detail and addresses of the supply locations will be given at time of issuing P.O. Rajasthan Police shall ensure that exact locations with contact details are shared with RISL and selected bidder.
“Design, Development and Implementation of Store Management System (SMS)”
Page 115 of 198
ANNEXURE-17: Functional Requirement Specifications (FRS)
The functional requirement specifications stated below are the minimum features that the solution
suggested for Store Management System (SMS) of Rajasthan Police should have. This indicative
functional requirement has been provided here to be used by the selected bidder for the effort
estimation. The selected bidder shall develop the final detailed Functional Requirement
Specifications (FRS) and System Requirement Specifications (SRS) documents after a detailed
design phase where all the processes, procedures and existing templates should be studied in
detail by the selected bidder. Selected bidder should independently design the solutions as may
be required to support the business operations. The selected bidder shall be required to
coordinate with the department for the detailed system study and interact with the different users
of the department for preparation of final FRS, SRS and related design documents.
Core Application Modules
Based on the requirements of services envisaged for the Central Store of Rajasthan Police for
automation under current scope of project, mentioned below are the core and non-core functional
modules that are envisaged for Store Management System (SMS). Following is a list of modules
to be developed:
A. Demand Management Module
B. Master Data Management Module
C. Material Supply and Stock Entry Module
D. Stock Allotment and Issue Module
E. Personnel and Branch Allotment Module
F. Stock Transfer Module
G. Employee Transfer Module
H. Fixed Assets Module
I. Workflow Management Module
J. Dashboard and Reporting Module
Other functional and non-functional requirements
Based on the requirements of services envisaged for SMS development under current scope of
project, following are the other functional and non-functional requirements that are envisaged:
a. Management of Documents
b. Additional Requirements
“Design, Development and Implementation of Store Management System (SMS)”
Page 116 of 198
a. System Wide Functionalities
b. System Management Requirements
c. Operational Requirements
d. Human Engineering Requirements
e. Audit Logs
f. Security Requirements
1.1 Demand Management Module
Demand management module is the most important module for the envisaged system, as the
entire purchase and distribution cycle of Central Store starts with demand collection and
aggregation. The module will be used by the various stores to initiate the annual exercise of
collection of requirements and holdings of store items from various districts, units and wings of the
Police.
“Design, Development and Implementation of Store Management System (SMS)”
Page 117 of 198
Demand management module will essentially create a facility through which central store will
initiate the demand collection in desired template and format. The demand initiation process will
be multi step process. The proposed system should take care of demand initiation at all store
levels i.e. at central store, field unit stores and sub-field unit stores. Designated officer at each
level will initiate this process through their login credentials.
Proposed system will be used to collect demand for store items under various budgetary heads.
Once the demand is aggregated at a particular level, additional demands gathered through from
internal sections, branches etc. will be included to prepare final demand proposal.
Requirement ID
Requirement Description
System Login
REQ_DMM_1 The systems shall be accessible to the following users:
SP C/S or officer designated by SP C/S
Store-man/Store in-charge of all central stores
SP (district/unit/wing) or officer designated by him/her
Store man of all FUS
Store man of all SFUS
Any other officer/employee designated by above jobs as per relevant
orders from time to time.
REQ_DMM_2 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities through
online access and limited capabilities through offline access.
REQ_DMM_3 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police.
REQ_DMM_3 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_DMM_4 The system shall maintain non editable audit trail of all activities carried out by
any user in SMS.
REQ_DMM_5 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by a
“Design, Development and Implementation of Store Management System (SMS)”
Page 118 of 198
Requirement ID
Requirement Description
higher level user
Workflow
REQ_DMM_6 The system should allow designated authority to configure the workflow for
various types of demand collection being initiated. Demand initiator should be
able to define workflow for demands collected under various budgetary heads.
REQ_DMM_7 The system should allow the demand initiator to indicate which type of demand
is being initiated.
REQ_DMM_8 The following mentioned fields are indicatively expected to be captured for
collection of demands/requirements and holdings from each store:
District/Unit/Wing name
Station/Company/Zone name
Item name
Miyad (if applicable)
Ledger Balance
Holding
Requirement
Document number of proof document/reference document
Remarks
The selected bidder should consult Rajasthan Police to design final template
for demand collection for varuiys categories of demand
REQ_DMM_9 Demand initiator should be able to create a list of items for which demands is
to be collected. The system should allow demand initiator to pick and choose
items from the item list available in Master Data Management module.
REQ_DMM_10 The systems should allow demand initiator to authorize which category of
stores are to participate in a particular demand collection process
REQ_DMM_11 The system should provide facility demand initiator to authorize particular
district/units/wings etc. from which demand is to be collected.
REQ_DMM_12 The system should allow demand initiator to create maximum and minimum
units for each item for which demand is to be collected.
“Design, Development and Implementation of Store Management System (SMS)”
Page 119 of 198
Requirement ID
Requirement Description
REQ_DMM_13 The system should allow demand initiator to specify deadline by which
demand is to be entered in the system.
REQ_DMM_14 The system should have ability to reduce or extend the timelines allowed for
each demand collection process.
REQ_DMM_15 The system should have the provision for authorized user to extend deadline
for demand collection process. The authorized user should also be able to
temporarily relax deadlines for particular stores
REQ_DMM_16 The system should allow store-man/store in-charge to pick the data from their
local database and fill the demand note.
REQ_DMM_17 The system should allow higher level store to fill the demand details of lower
level stores in cases like when the data is already available to higher level
store, connectivity issues or any other issues are present at lower level stores.
REQ_DMM_18 The system should allow spurious data to be rejected at each level.
REQ_DMM_19 System should allow at each store level to create reminders and alerts for
lower level stores.
REQ_DMM_20 For demands which are to be collected throughout the year system should
automatically add the latest demand to the previous demands entered by the
same district/unit/wing/store.
REQ_DMM_21 Whenever demand is entered in the system, system should run the business
rules set in the system for all items and prompt the user whenever a possible
deviation from business rule is detected.
Demand aggregation
REQ_DMM_22 System should allow store-man at each store level to aggregate holdings and
demands entered in the system by lower level stores.
REQ_DMM_23 System should allow aggregation of demands and holdings item wise, store-
wise, district wise, unit wise, wing wise, zone wise etc.
REQ_DMM_24 The system should allow one store to transfer demands of particular items to
other store. This is done when one store is responsible for demand collection
but purchase of item is done by other store.
“Design, Development and Implementation of Store Management System (SMS)”
Page 120 of 198
Requirement ID
Requirement Description
REQ_DMM_25 The system should allow demand initiator to edit the demand data whenever
there seems to be some error in the data entered.
REQ_DMM_26 The system should allow demand initiator to pick and fill data from sources
such as excel sheets, XML files, csv files or files and sources of such nature
where demands can possibly be collected.
REQ_DMM_27 The system should allow addition of demands from internal branches and
sections to previously aggregated demand.
REQ_DMM_28 The system should allow the user to attach various documents/supporting
documents/evidences. Following should be the indicatively allowed formats for
upload:
Scanned documents
Images
RTFs
PDFs
The system shall support all other formats as specified by Rajasthan Police for
above mentioned types of documents.
REQ_DMM_29 System should provide user the option to either upload a document or mention
reference number of the document.
REQ_DMM_30 System should have the provision to postpone the uploading of a document
required in the process. This should not stop the work from progressing. In
such situation, system should create a pending item list for the documents to
be uploaded.
REQ_DMM_31 The system should have mandatory fields marked out clearly for filling. The
system should not allow submission of the application without completing the
mandatory fields. Mandatory/Non Mandatory fields shall be finalized in
discussion with the Rajasthan Police.
REQ_DMM_32 All types of documents submitted along with the application should be
preserved securely in the system and its quality must be maintained. All
documents should be in read only mode and non-editable mode.
REQ_DMM_33 On submission of the demand and holding sheet, a unique demand number
“Design, Development and Implementation of Store Management System (SMS)”
Page 121 of 198
Requirement ID
Requirement Description
should be generated by the system for future reference. This application
number should be saved in encrypted form in the system.
REQ_DMM_34 System should allow locking the entered data so that further editing of data by
lower level stores is not possible
REQ_DMM_35 System should allow automatic aggregation and submission of data whenever
store manager fails to do so before deadline.
REQ_DMM_36 System should allow demand initiator to temporarily allow lower level stores to
fill the data after the deadline.
REQ_DMM_37 System should allow lower level stores to initiate separate demand and
holding collection process from their subordinate stores for self-purchased
items.
Demand Proposal Preparation
REQ_DMM_38 After the collection and aggregation is done, system should allow authorized
user to prepare demand proposals for approval. User should be able to pick
and choose items for which proposal is to be prepared.
REQ_DMM_39 User should be able to pick demands from a particular district, unit, wing or a
combination of these to prepare proposal.
REQ_DMM_40 User should be able to pick items according to specific business rules such as
all item which are due to according to Miyad or not due etc.
REQ_DMM_41 User should be able to prepare proposal for demands under various budgetary
head.
REQ_DMM_42 System should allow user to prepare proposals in multiple iteration i.e. for a
particular item system should keep track of number of items included in the
past proposal and should prompt user about number of items for which
proposal preparation is pending
REQ_DMM_43 System should allow versioning of proposals and should maintain copy of all
past versions of the same proposal.
REQ_DMM_44 System should allow direct preparation of proposal in cases where collection
of data from lower level stores in not required.
“Design, Development and Implementation of Store Management System (SMS)”
Page 122 of 198
Requirement ID
Requirement Description
MIS
REQ_DMM_45 The system should provide suitable MIS to designated officer at predefined
periodicity/ scheme/circle/division. These MIS should have parameters to
configure option to be delivered through email, or dashboard, or access by the
designated user. Indicative but not comprehensive list of MIS include:
Store wise holding and requirements of items
District/unit/wing/zone/company wise holding and requirements of items
List of districts/units/wings etc. pending to submit data.
List of districts/units/wings etc. who have submitted data.
Stores for which demand is not collected
Stores for which demand has been initiated
Stores for which demand is closed
Items included in the demand initiation note
Demand pending to be included in proposals.
Demand included in proposals
List of past proposals
List of approved proposals
Integration
REQ_DMM_46 System should allow integration with Master data Management Module so that
any changes made in the Master data management module are reflected in
real-time in Demand Management Module
REQ_DMM_47 Demand Management Module will be integrated with Workflow management
module so that only that processes are allowed which have been created in
workflow for that store
REQ_DMM_48 Demand Management Module should be integrated with electronic digital
signature pad so that whenever signatures are to be collected through pads,
signature pads are activated and signatures operation is performed effortlessly
“Design, Development and Implementation of Store Management System (SMS)”
Page 123 of 198
Requirement ID
Requirement Description
REQ_DMM_49 Demand Management Module should be integrated with all other modules in
the system which are logically related according to workflow
REQ_DMM_50 System should have a provision for biometric authentication at all places in the
workflow where signatures where required in manual system. User should
have the provision to authenticate the information and processes using any of
the authentication methods viz. biometric authentication system, electronic
signature pad and also manual signatures on paper.
1.2 Master Data Management Module
Master data management module will be primary module required to operationalize Store
Management System (SMS) and hence will be of prime importance. MDM module will be used to
create the primary database of the units, wings, battalions, employees and all other users of the
items purchased and issued by central store. MDM module will be used to create primary lists of
materials procured and distributes by central store. Details of all the items will be first created in
MDM module. Subsequent to that MDM module will be use to link each item with the relevant
Central Store, Field Unit Store and all other lower level stores.
Any new additions of items to be purchased will be first made in MDM module and its mapping be
done to relevant store. Editing of item-store mapping if needed will be first done in MDM module.
Creation, addition, deletion and modifications of all master data items will be done through MDM
module. MDM module will be used to map the stores to their unit, wing etc. and subsequently to
store in-charges/store man.
Requirement ID
Requirement Description
System Login
REQ_MDM_1 The System shall be accessible to following users:
SP (C/S)
SP (District/Unit/Wing)
DySP (C/S)
“Design, Development and Implementation of Store Management System (SMS)”
Page 124 of 198
Requirement ID
Requirement Description
Store In-charges for all Central Stores
Store In-charges for all FUS stores
Store In-charges for all SFUS stores
IT System Administrator
Any other user authorized for store duty
REQ_MDM_2 MDM module will be accessible to internal Rajasthan Police users as per the
user roles specified by the Rajasthan Police.
Primary users of MDM module will be store in-charges/store man for:
o Creation of store items and materials in the system
o Addition, deletion and modification of various stores.
o Mapping of items to stores.
o Mapping of stores to units, wings, districts etc.
REQ_MDM_3 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities through
online access and limited capabilities through offline access.
REQ_MDM_4 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police.
REQ_MDM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_MDM_6 MDM module will also be accessible to IT administrator to implement system
level changes in MDM module
REQ_MDM_7 MDM module will also be available to SP C/S to override any unauthorized
modifications
REQ_MDM_8 The system shall maintain non editable audit trail of all activities carried out by
any user in SMS.
REQ_MDM_9 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by a
“Design, Development and Implementation of Store Management System (SMS)”
Page 125 of 198
Requirement ID
Requirement Description
higher level user
Store Creation/Modification
REQ_MDM_10 The system should allow creation of various stores in the system. Any store
creation will capture following fields:
Store Name
Store Objective
Level of store i.e. Central Store, Field unit store or Sub-field unit store
Store Owner (PHQ in case of central store, District/Unit/Wing in case of
Field Unit Store, Zone/Line/Company in case of sub-field unit store
Store Category (MT, Uniforms etc.)
Higher level store name
Store In-charge Name
Store in-charge contact details
REQ_MDM_11 System should allow creation of store by only higher level store owner or the
authorized user.
REQ_MDM_12 Central store creation should be allowed without intervention of higher level
store
REQ_MDM_13 System should allow modification of store details. Upon modification of store
details system should send details of modifications to higher level store owner
and SP of the concerned district/unit/wing
REQ_MDM_14 System should create unique ID for each store.
REQ_MDM_15 System should allow store operations be merged or store operations to be split
among several stores
Item creation/modification
REQ_MDM_16 The system should allow creation of store items. Any new items will typically
require following fields:
Item Name
Item Category
Item make
Item model
“Design, Development and Implementation of Store Management System (SMS)”
Page 126 of 198
Requirement ID
Requirement Description
Item expiry (if applicable)
Miyad of item (if applicable)
Size/Height/Weight (if applicable)
Item ID (if applicable)
Above is a tentative list of item details to be captured when item is created.
selected bidder should consult with all store in-charges finalize the list of items
and the details of each item to be captured
REQ_MDM_17 System should allow each item to be linked to a category i.e. whether the item
belongs to category of arms, ammunition, uniform, vehicle etc.
REQ_MDM_18 System upon choosing item category should display appropriate detail to be
captured for that category of item.
REQ_MDM_19 System should allow creation of items by different levels of stores i.e. field unit
stores and sub-field unit stores be also allowed to create items
REQ_MDM_20 Before final item creation, system should prompt user with all similar items
already present in the system so that duplicate or redundant items may not be
created in the system.
REQ_MDM_21 Items created by FUS/SFUS should be visible to only that SFUS and FUS.
REQ_MDM_22 All items created by FUS/SFUS should also be added to master item list
maintained by central store
REQ_MDM_23 Any modification in the item details be allowed to only the store in-charge of
store that created the item.
REQ_MDM_24 System should allow central store authorized user to create, delete or modify
any store items irrespective of whether the item was created by a lower level
store
REQ_MDM_25 System should create a unique item ID for each item
Employee Database Creation
REQ_MDM_26 The system should allow addition of employee names in the system.
REQ_MDM_27 Employee database creation will be undertaken by district, unit or wing in
which the employee is presently working. System should allow all store owners
“Design, Development and Implementation of Store Management System (SMS)”
Page 127 of 198
Requirement ID
Requirement Description
to create employee database.
REQ_MDM_28 An indicative but not exhausted list of details when database of an employee is
created is as follows:
Employee Name
Employee Cadre
Employee Designation
Employee Age/DOB
Employee Unique ID
Employee Contact Details
Selected bidder should consult Rajasthan Police to finalize the details to be
captured.
REQ_MDM_29 The system should NOT allot any system generated unique ID. Rather the
system should uniquely identify each employee by a department provided
unique number. Selected bidder should consult department and create
provision in the system to capture this number.
REQ_MDM_30 Upon creation of employee database, system should sent welcome email and
SMS to employee along with system generated username and password for
employee dashboard
REQ_MDM_31 Any employee database modifications will be allowed only to the store in-
charge of the store with which employee is presently tagged.
REQ_MDM_32 System should email/SMS to employee I any changes in employee database
is done.
REQ_MDM_33 System should allow employees to themselves modify certain basic details
only like contact etc.
District/Unit/Wing Creation/Modification
REQ_MDM_34 The system shall allow creation of district/unit/wing in system. System should
capture following information when creation is done:
District/Unit/Wing/Zone/Company/Line Name
Unit Heads name
Circle/Commissionerate/Zone name (if applicable)
“Design, Development and Implementation of Store Management System (SMS)”
Page 128 of 198
Requirement ID
Requirement Description
Unit Head contact details
District/Unit/Wing owner
selected bidder should consult Rajasthan Police to finalize details to be
capture
REQ_MDM_35 Creation facility will be allowed only to central store authorized user.
REQ_MDM_36 System generated email/SMS should be sent to unit head upon creation or
modification.
REQ_MDM_37 System should assign a unique ID to each district/unit/wing etc.
REQ_MDM_38 System should not allow lower level zone/company etc. to make modification
or delete higher level details
REQ_MDM_39 System should allow higher level entity to make modification in lower level
entity details or even override modifications made by lower level entity
Supplier/Vendor Creation
REQ_MDM_40 System should allow creation of supplier/vendor detail in the system
REQ_MDM_41 An indicative list of details to be captured in supplier/vendor creation process
are:
Supplier Organization Name
Supplier Address Details
Supplier Office Contact Detail
Supplier’s Official Representative Name
Supplier’s Official Representative Contact detail
Items authorized to be sold be seller (System should allow mapping of
item-supplier details)
Period of authorization
REQ_MDM_42 System should allow only authorized central store user to create supplier
details for items purchased by Central Store
REQ_MDM_43 System should allow FUS/SFUS to create supplier/vendor details for items
self-purchased by them
“Design, Development and Implementation of Store Management System (SMS)”
Page 129 of 198
Requirement ID
Requirement Description
REQ_MDM_44 System should not allow lower level stores to modify/delete details created by
higher level stores
REQ_MDM_45 System should allow Central Store authorized user to modify/delete any details
created by lower level details
REQ_MDM_46 On creation of supplier details, system should send welcome SMS/Email to
supplier along with system generated username and password for
supplier/vendor account
REQ_MDM_47 Supplier be allowed only to change certain details like contact details etc.
REQ_MDM_48 Suppliers/vendors created by store of one district/unit/wing should not be
accessible to users of other district/unit/wing
Mappings
REQ_MDM_49 For item-store mappings, should allow store in-charge to pick and choose
items which are purchased/collected/distributed/used by that store
REQ_MDM_50 System should allow one to many linkage for store-item mapping
REQ_MDM_51 System should not allow linking one item to more than one category of store
i.e. one item can only be linked to only one of the uniform, stationery, arms
store etc.
REQ_MDM_52 System should allow modifications in item-store category mapping. This
change can only be done by store which creates the item in list
REQ_MDM_53 System should allow central store authorized user to modify or override any
changes made by lower level stores.
REQ_MDM_54 System should not allow any mapping between two master data items which is
against any business rule/logic.
MIS
REQ_MDM_55 The system should provide suitable MIS to designated officer. These MIS
should have parameters to configure option to be delivered through email, or
dashboard, or access by the designated user. Indicative but not
comprehensive list of MIS include:
“Design, Development and Implementation of Store Management System (SMS)”
Page 130 of 198
Requirement ID
Requirement Description
List of stores
List of items
List of employees
List of district/unit/wings
Store-item mapping list
List of contact details
Employee dashboard report
Summary of employees tagged to District/Unit/Wing
Summary of items tagged to a District/Unit/Wing
Integration
REQ_MDM_56 System should allow integration with Master data Management Module so that
any changes made in the Master data management module are reflected in
real-time in Master Data Management Module
REQ_MDM_57 Master Data Management Module will be integrated with Workflow
management module so that only that processes are allowed which have been
created in workflow for that store
REQ_MDM_58 Master Data Management Module should be integrated with electronic digital
signature pad so that whenever signatures are to be collected through pads,
signature pads are activated and signatures operation is performed effortlessly
REQ_MDM_59 Master Data Management Module should be integrated with all other modules
in the system which are logically related according to workflow
REQ_MDM_60 System should allow integration with Master data Management Module so that
any changes made in the Master data management module are reflected in
real-time in Master Data Management Module
REQ_MDM_61 System should have a provision for biometric authentication at all places in the
workflow where signatures where required in manual system. User should
have the provision to authenticate the information and processes using any of
“Design, Development and Implementation of Store Management System (SMS)”
Page 131 of 198
Requirement ID
Requirement Description
the authentication methods viz. biometric authentication system, electronic
signature pad and also manual signatures on paper.
1.3 Material Supply and Stock Entry Module
This module will be used to perform all store operation that are required to receive the ordered
materials from various suppliers and vendors and then enter the details of these items in various
registers and vouchers. Every level of store will perform this operation to register details of
purchased items in their registers. This operation may be performed against annual purchase,
self-purchase and special purchase under other funds.
Requirement ID Requirement Description
System Login
REQ_MSSM_1 The system should be accessible through centralized web
application/offline module for internal user assigned with following roles and
indicative privileges:
o Central Store
- SP (C/S)
- Uniform Store In-charge
- IT system administrator
- Any other employee assigned to Uniform Store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
“Design, Development and Implementation of Store Management System (SMS)”
Page 132 of 198
Requirement ID Requirement Description
REQ_MSSM_2 The system should allow authorized users to access various functions,
forms, screens, sub modules, information etc. as per the authorizations and
user roles permissible as per guidelines and policies of the Rajasthan
Police
REQ_MSSM_3 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police
REQ_MSSM_4 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities
through online access and limited capabilities through offline access.
REQ_MSSM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_MSSM_6 Module should also be accessible to IT administrator to implement system
level changes.
REQ_MSSM_7 Module should also be available to SP C/S to override any unauthorized
modifications
REQ_MSSM_8 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode
i.e. work performed by lower level user is authorized and
authorized/finalized by a higher level user
Material Supply and Stock Entry by Central Store
REQ_MSSM_9 System should allow authorized user to enter details of various items
supplied by vendors in various registers according to the workflow for that
store.
REQ_MSSM_10 For stores which use Temporary register their workflow, system should
provide facility to enter details in temporary register
An indicative list of details to be captured in temporary register:
Store Name
“Design, Development and Implementation of Store Management System (SMS)”
Page 133 of 198
Requirement ID Requirement Description
Store level
Store Category
Item Name
Item Details (these details to be auto filled from master data
management module as per item ID)
Supplier/Vendor Name
Name of vendors representative
Bill Number
Challan Number
Date of delivery
Number of items delivered
Cost of Items
Signature of receiver/store-man
Signature of vendor representative
Signature of SP/DySP
This is not an exhaustive list. Selected bidder should finalize the template
and details after consultation with Rajasthan Police. System should ensure
maximum pre-filling of data as per logical workflow.
REQ_MSSM_11 System should prompt user to enter the signatures wherever necessary
according to workflow. System should allow the user to pick and choose
three option whenever signatures are required:
System should allow the user to user Digital Signature
System should allow usage of signature pads, and copy the
signatures onto necessary place in the document.
System should allow user to print acknowledgment copy of
document and get the signatures. In case this option is chosen, then
system should prompt user to enter unique ID of employee whose
signature is to be taken. In case person is not from Rajasthan Police,
then system should prompt user to enter basic details of signee such
as Name, Organization, Email and phone number
REQ_MSSM_12 If the user chooses option to sign with signature pad then system should
“Design, Development and Implementation of Store Management System (SMS)”
Page 134 of 198
Requirement ID Requirement Description
activate the signature pad facility and capture and paste the signature at
appropriate place.
REQ_MSSM_13 If the user chooses to sign with Digital Signature then system should allow
user to locate the signature file in the desktop/laptop and perform the
signing activity
REQ_MSSM_14 System should have the provision to allow C/S user to pick and choose
records entered in various registers and vouchers to be sent to
higher/senior officer user account to get signatures and authorization.
System should provide tick boxes against each record to select those
records which need authorization from higher level.
REQ_MSSM_15 System should allow Move option to move the details of item from one
register/voucher to another register/voucher. Whenever an item is moved,
status of item details should change as per workflow for that particular
store.
REQ_MSSM_16 For every movement, system should prompt user to enter reason for
movement along with option to upload the documents or mention details of
documents.
REQ_MSSM_17 System should create various item statuses to identify the present status of
work. An indicative list of items is:
Arrived but not inspected
Sent for testing
Inspection Pending
Inspected and approved
Inspected and rejected
Issued
Issued and Confirmed
Received
Allotted
Returned etc.
“Design, Development and Implementation of Store Management System (SMS)”
Page 135 of 198
Requirement ID Requirement Description
The Selected bidder should work with Rajasthan Police to develop final
list of all item statuses which will be needed according to workflow
REQ_MSSM_18 System should ensure that status changes are allowed only according to
the defined workflow for that store.
REQ_MSSM_19 Systems should prompt user whenever the status of an item is being
changed. System should ask user to choose reason for status change and
also provide facility to upload necessary document.
REQ_MSSM_20 System should allow the user to mention the reference number of
necessary documents instead of uploading the. System should also allow
user to upload the documents later too.
REQ_MSSM_21 System should allow generation of received vouchers for the items entered
in Temporary registers. System should prompt user to mention reference of
inspection note or upload the inspection note.
REQ_MSSM_22 For all rejected items, system should allow user to change the status to
“Inspected and Rejected”. System should prompt user to mention reference
number of inspection note or upload the inspection note.
REQ_MSSM_23 An indicative list of details to be captured in received voucher:
Store Name
Store Level
Store Category
Item Name
Item Details (these details to be auto filled from master data
management module as per item ID)
Supplier/Vendor Name
Name of vendors representative
Bill Number
Challan Number
Number of items delivered
Cost of Items
“Design, Development and Implementation of Store Management System (SMS)”
Page 136 of 198
Requirement ID Requirement Description
Signature of receiver/store-man
Signature of vendor representative
Signature of SP/DySP
This is not an exhaustive list. Selected bidder should finalize the template
and details after consultation with Rajasthan Police. System should ensure
maximum pre-filling of data as per logical workflow.
REQ_MSSM_24 System should generate a unique number for each voucher and
reference/transaction ID for each transactions made in several registers
REQ_MSSM_25 System should be able to pre-fill the received voucher with data from the
item details entered in temporary register.
REQ_MSSM_26 System should allow multiple options of signing to a user:
Bulk item signature: In case details of many item are entered in
registers or vouchers
Single Item Signature: In case user chooses to get signatures
individually
REQ_MSSM_27 As soon as the received voucher is generated for an item, system should
change the status to “Item Received”
REQ_MSSM_28 For all received items, system should replicate the item details in stock
register. System should allow user to modify/delete the replicated details.
REQ_MSSM_29 System should allow user to choose stock register, as per workflow of that
particular store finalized in “Workflow Management Module”
REQ_MSSM_30 For each stock register entry, following details are to be captured:
Store Name
Date
Item Name
Item details (these details to be auto filled from master data
management module as per item ID)
“Design, Development and Implementation of Store Management System (SMS)”
Page 137 of 198
Requirement ID Requirement Description
Number of items
Cost/Item
Total cost of items
Signature of store man
Signature of receiver
Signature of SP/DySP (authorized officer)
Remarks
This is not an exhaustive list. Selected bidder should finalize the template
and details after consultation with Rajasthan Police. System should be able
to pre-fill as many details possible as per logical workflow.
REQ_MSSM_31 For every item detail entered, system should generate a unique transaction
ID for that record.
REQ_MSSM_32 For each item , moved to stock register system should change status to
“Stock Register Details Entered”
REQ_MSSM_33 System should adjust inventory balance and ledger balance whenever the
item details are entered in Stock Register
REQ_MSSM_34 System should ensure that items are moved to specific registers according
to category of item.
MIS Reports
REQ_MSSM_35 System should allow report based on different status of items in various
registers
REQ_MSSM_36 System should generate list of items pending for inspection, items for which
inspection is initiated, items for which inspection is complete.
REQ_MSSM_37 System should generate list of all items for which received vouchers have
been generated
REQ_MSSM_38 System should generate list of all transactions pending for authorization by
“Design, Development and Implementation of Store Management System (SMS)”
Page 138 of 198
Requirement ID Requirement Description
checker i.e. Higher level user
REQ_MSSM_39 System should allow reports based on specific dates and reports based on
specific periods.
REQ_MSSM_40 System should generate reports for items which are pending inspections,
REQ_MSSM_41 System should allow prints of each voucher generated from the system in
the format decided by Rajasthan Police for that store
REQ_MSSM_42 System should allow generation of reports for each store level and each
store category
REQ_MSSM_43 System should provide viewing of various reports in formats like HTML,
PDF, Excel etc.
REQ_MSSM_44 System should allow downloading of reports in specific formats chosen by
the user
Integration Requirements
REQ_MSSM_45 System should allow integration with Master data Management Module so
that any changes made in the Master data management module are
reflected in real-time in Material Supply and Stock Entry Module
REQ_MSSM_46 Material Supply and Stock Entry Module will be integrated with Workflow
management module so that only that processes are allowed which have
been created in workflow for that store
REQ_MSSM_47 Material Supply and Stock Entry Module should be integrated with
electronic digital signature pad so that whenever signatures are to be
collected through pads, signature pads are activated and signatures
operation is performed effortlessly
REQ_MSSM_48 Material Supply and Stock Entry Module should be integrated with all other
modules in the system which are logically related according to workflow
“Design, Development and Implementation of Store Management System (SMS)”
Page 139 of 198
Requirement ID Requirement Description
REQ_MSSM_49 System should have a provision for biometric authentication at all places in
the workflow where signatures where required in manual system. User
should have the provision to authenticate the information and processes
using any of the authentication methods viz. biometric authentication
system, electronic signature pad and also manual signatures on paper.
1.4 Stock Allotment and Issue Module
Requirement ID Requirement Description
System Login
REQ_SAIM_1 The system should be accessible through centralized web
application/offline module for internal user assigned with following roles and
indicative privileges:
o Central Store
- SP (Central Store)
- Store In-charge
- IT system administrator
- Any other employee assigned to perform store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
REQ_SAIM_2 The system should allow authorized users to access various functions,
“Design, Development and Implementation of Store Management System (SMS)”
Page 140 of 198
Requirement ID Requirement Description
forms, screens, sub modules, information etc. as per the authorizations and
user roles permissible as per guidelines and policies of the Rajasthan
Police
REQ_SAIM_3 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police
REQ_SAIM_4 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities
through online access and limited capabilities through offline access.
REQ_SAIM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_SAIM_6 This module will also be accessible to IT administrator to implement system
level changes in MDM module
REQ_SAIM_7 This module will also be available to SP C/S to override any unauthorized
modifications
REQ_SAIM_8 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police-SMS.
REQ_SAIM_9 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode
i.e. work performed by lower level user is authorized and
authorized/finalized by a higher level user
REQ_SAIM_10
Stock Allotment to Stores & Item Distribution to Stores
REQ_SAIM_11 System should allow Central Store user to generate allotment list and
allotment orders. System should allow C/S to Create a Consolidated
Allotment Order for FUS and SFUS from “Approved Demand/Proposal”
prepared from Demand Management Module.
REQ_SAIM_12 System should allow FUS user to generate Consolidated and Individual
“Design, Development and Implementation of Store Management System (SMS)”
Page 141 of 198
Requirement ID Requirement Description
allotment orders to various SFUS under its purview
REQ_SAIM_13 System should allow C/S, FUS and SFUS users to generate allotment
orders for various internal branches and sections
REQ_SAIM_14 System should keep track that no store allots any lower level store or
branches items more than their approved demand and also ensure that no
item is allotted more than approved item number.
REQ_SAIM_15 System should allow generation of individual allotment order for each
district/unit/wing.
REQ_SAIM_16 System should “Approved demand” list whenever an individual allotment
order is generated. System should reduce the number of items allotted from
approved demand.
REQ_SAIM_17 System should ensure that allotment order generation process is carried out
in a maker-checker function i.e. an allotment order generated by store-
man/store in-charge is authorized/finalized by a higher level user.
REQ_SAIM_18 An individual allotment order would typically consider following fields:
Store Name
Item Details
Number of allotted items
Signature of SP/ DySP (C/S)
REQ_SAIM_19 When authorized representative from a lower level store arrives at a higher
level store arrives to collect items as per allotment order, system should
allow generating issue voucher only as per approved workflow for that
store.
REQ_SAIM_20 For each issue voucher, an indicative list of details to be captured is as
follows:
• Store Name
“Design, Development and Implementation of Store Management System (SMS)”
Page 142 of 198
Requirement ID Requirement Description
• Date
• Issuer Name/ Store-man name
• Receivers Name
• Receivers Employee ID
• District/Unit/Wing name to which item is issued
• Item Name
• Item details (these details to be auto filled from master data
management module as per item ID)
• Number of items
• Cost/Item
• Total cost of items
• Stock Register Unique item ID
• Data of entry in stock register
• Signature of issuer
• Signature of receiver
• Signature of SP/DySP (authorized officer)
• Remarks
This is not an exhaustive list. Selected bidder should finalize the template
and details after consultation with Rajasthan Police
REQ_SAIM_21 As soon as the item is issued and issue voucher is generated, system
should automatically modify the item status in various registers according to
workflow.
REQ_SAIM_22 System should replicate the item details entered in vouchers to the issued
and stock register for that store as per workflow of that store.
REQ_SAIM_23 For all issued objects, details of issue voucher must be replicated in
appropriate issue register of various levels of stores by the system.
“Design, Development and Implementation of Store Management System (SMS)”
Page 143 of 198
Requirement ID Requirement Description
REQ_SAIM_24 The system should then automatically generate issue register entry for that
item.
The fields captured in issue register are:
Item Name
Item details
Number of items issued
Date of issue
District/Unit/Wing to which item was issued
Signature of store-man
Signature of SP/DySP (authorized officer)
Remarks
REQ_SAIM_25 System should automatically replicate details if items from issue register in
stock register as per flow.
REQ_SAIM_26 When the item details have been entered in Stock Register, system should
automatically reduce the ledger balance for that item in stock register.
REQ_SAIM_27 System should update the status of item details in higher level store
registers when lower level stores confirm that items have been received.
REQ_SAIM_28 System should automatically replicate entries in various registers according
to the workflow of that lower level store when status of an item is changed
REQ_SAIM_29 System should have provision to automatically adjust the ledger balances in
respective stock registers according to workflow.
REQ_SAIM_30 System should have the ability to inform higher level stores of any changes
made by lower levels in vouchers and registers
REQ_SAIM_31 System should automatically update the issue vouchers and stock registers
of higher level stores when the lower level stores make an entry in their
stock and received registers.
“Design, Development and Implementation of Store Management System (SMS)”
Page 144 of 198
Requirement ID Requirement Description
REQ_SAIM_32 System should have provision to generate issue vouchers of various kinds
according to category of items such as permanent and consumable items.
MIS Reports
REQ_SAIM_33 System has the provision to generate summary of various vouchers issued
and received by each store
REQ_SAIM_34 System should have the ability to generate various allotment reports
district/unit/wing wise, date wise, item wise etc.
REQ_SAIM_35 System should have the ability to generate the stock registers according to
district/unit/wing, for a specified period, according to items, according to
different category of stores etc.
REQ_SAIM_36 System should have the ability to filter various registers according to status
of items mentioned in them and generate reports.
REQ_SAIM_37 System should have the ability to generate reports of items for which issue
vouchers have been generated but confirmation at lower level stores are
not done
REQ_SAIM_38 System should have the provision to generate various ledger balance
reports according to criteria such as store category, item category,
district/unit wing wise, permanent items, consumable items etc.
REQ_SAIM_39 System should have the ability to provide a allotment record of an item.
Integration Requirement
REQ_SAIM_40 System should allow integration with Master data Management Module so
that any changes made in the Master data management module are
reflected in real-time in Stock Allotment and Issue Module
REQ_SAIM_41 Stock Allotment and Issue Module will be integrated with Workflow
management module so that only that processes are allowed which have
“Design, Development and Implementation of Store Management System (SMS)”
Page 145 of 198
Requirement ID Requirement Description
been created in workflow for that store
REQ_SAIM_42 Stock Allotment and Issue Module should be integrated with
electronic/digital signature pad so that whenever signatures are to be
collected through pads, signature pads are activated and signatures
operation is performed effortlessly
REQ_SAIM_43 Stock Allotment and Issue Module should be integrated with all other
modules in the system which are logically related according to workflow
REQ_SAIM_44 System should have a provision for biometric authentication at all places in
the workflow where signatures where required in manual system. User
should have the provision to authenticate the information and processes
using any of the authentication methods viz. biometric authentication
system, electronic signature pad and also manual signatures on paper.
1.5 Personnel and Branch Allotment Module
Requirement ID Requirement Description
System Login
REQ_PBAM_1 The system should be accessible through centralized web
application/offline module for internal user assigned with following roles and
indicative privileges:
o Central Store
- SP (C/S)
- Uniform Store In-charge
- IT system administrator
- Any other employee assigned to Uniform Store duty
o Field Unit Stores
“Design, Development and Implementation of Store Management System (SMS)”
Page 146 of 198
Requirement ID Requirement Description
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
REQ_PBAM_2 The system should allow authorized users to access various functions,
forms, screens, sub modules, information etc. as per the authorizations and
user roles permissible as per guidelines and policies of the Rajasthan
Police
REQ_PBAM_3 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police
REQ_PBAM_4 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities
through online access and limited capabilities through offline access.
REQ_PBAM_5 The system should allow authorized users to access various functions,
forms, screens, sub modules, information etc. as per the authorizations and
user roles permissible as per guidelines and policies of the Rajasthan
Police.
REQ_PBAM_6 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_PBAM_7 This module will also be accessible to IT administrator to implement system
level changes.
REQ_PBAM_8 Module will also be available to SP C/S to override any unauthorized
modifications
REQ_PBAM_9 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode
i.e. work performed by lower level user is authorized and
authorized/finalized by a higher level user
“Design, Development and Implementation of Store Management System (SMS)”
Page 147 of 198
Requirement ID Requirement Description
Personnel & Branch Allotment
REQ_PBAM_10 System should have provision to issue items to both individual and
branches/section. System should generate appropriate issue vouchers.
REQ_PBAM_11 System should provide facility to allot items to individuals and branches
across all level of stores i.e. all three levels of stores Central Store, FUS
and SFUS must be able to use this facility
REQ_PBAM_12 System should allow initiation of allotment by change in the status of item in
stock registers.
REQ_PBAM_13 System should ensure that personnel items are not allotted to branches and
vice-versa.
REQ_PBAM_14 System should have the provision to allow representatives of officers to
collect individual items. In this situation information SMS/Email should be
sent to recipient officer.
REQ_PBAM_15 System should generate appropriate issue vouchers according to the
category of recipient and category of items.
REQ_PBAM_16 System should have the provision to reflect the changes made in stores
stock registers to reflect in personnel allotment register and branch
allotment register
REQ_PBAM_17
REQ_PBAM_18 System should have the ability to prompt user when more items than items
mentioned in Miyad or allotment orders are tried to be allotted.
REQ_PBAM_19 System should have the provision to create exception when items are to be
allotted more than Miyad or allotment orders. System should only finalize
these changes when they have been authorized by higher level officer.
REQ_PBAM_20 System should have the provision to replicate information in issued
“Design, Development and Implementation of Store Management System (SMS)”
Page 148 of 198
Requirement ID Requirement Description
registers to personnel/branch allotment registers. An indicative list of items
is mentioned below:
Personnel/Branch Name
Item name
Item Detail
Number of Items
Date of allotment
Signature of Personnel/Branch In-charge
REQ_PBAM_21 System should have the provision to calculate necessary fees, employee
contribution or past dues before an item is allotted to an individual
REQ_PBAM_22 System should have the provision to update the employee account or
branch/section account when items are allotted
REQ_PBAM_23 System should have the ability to automatically update the stock register of
concerned store upon allotment of item and reduce the ledger balance.
REQ_PBAM_24 System should provide the facility to reverse or modify erroneous
transaction or entries.
REQ_PBAM_25 System should send information SMS/Email to the employee or head of the
concerned branch to which items have been issued.
MIS Reports
REQ_PBAM_26 System should have the ability to generate reports of personnel and branch
allotment register according to different stores, districts, units, wings etc.
REQ_PBAM_27 System should have the ability to generate list of items allotted on a
particular day, week, month or year
REQ_PBAM_28 Systems should have the ability to drill down personnel and branch
allotment registers and view specific details in this register in various
formats like HTML, PDF, Excel, CSV etc.
“Design, Development and Implementation of Store Management System (SMS)”
Page 149 of 198
Requirement ID Requirement Description
REQ_PBAM_29 System should have the ability to generate customized report needed by
various stores in day to day operation.
Integration Requirements
REQ_PBAM_30 System should allow integration with Master data Management Module so
that any changes made in the Master data management module are
reflected in real-time in Personnel and Branch Allotment Module
REQ_PBAM_31 Personnel and Branch Allotment Module will be integrated with Workflow
management module so that only that processes are allowed which have
been created in workflow for that store
REQ_PBAM_32 Personnel and Branch Allotment Module should be integrated with
electronic/digital signature pad so that whenever signatures are to be
collected through pads, signature pads are activated and signatures
operation is performed effortlessly
REQ_PBAM_33 Personnel and Branch Allotment Module should be integrated with all other
modules in the system which are logically related according to workflow
REQ_PBAM_34 System should have a provision for biometric authentication at all places in
the workflow where signatures where required in manual system. User
should have the provision to authenticate the information and processes
using any of the authentication methods viz. biometric authentication
system, electronic signature pad and also manual signatures on paper.
1.6 Stock Transfer Module
Requirement ID
Requirement Description
System Login
“Design, Development and Implementation of Store Management System (SMS)”
Page 150 of 198
Requirement ID
Requirement Description
REQ_STM_1 The system should be accessible through centralized web application/offline
module for internal user assigned with following roles and indicative privileges:
o Central Store
- SP (Central Store)
- Store In-charge
- IT system administrator
- Any other employee assigned to perform store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
REQ_STM_2 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police
REQ_STM_3 The system shall maintain non editable audit trail of all activities carried out by
any user in Rajasthan Police
REQ_STM_4 System should have the provision of offline access along with access with
centralized web application. The system should allow all capabilities through
online access and limited capabilities through offline access.
REQ_STM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_STM_6 This module will also be accessible to IT administrator to implement system
“Design, Development and Implementation of Store Management System (SMS)”
Page 151 of 198
Requirement ID
Requirement Description
level changes.
REQ_STM_7 This module will also be available to SP C/S to override any unauthorized
modifications
REQ_STM_8 The system shall maintain non editable audit trail of all activities carried out by
any user in Rajasthan Police-SMS.
REQ_STM_9 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by a
higher level user
Stock Transfer Initiation
REQ_STM_10 System should have the provision to initiate stock transfer only through
authorized user access.
REQ_STM_11 System should have the provision to record contact details of officers
authorized to initiate stock transfer, and system should send SMS/Email to
concerned officer whenever stock transfer module is used so as to avoid
unauthorized transfer
REQ_STM_12 System should prompt the user to enter reference number of stock transfer
order or upload the stock transfer order upon which system should allow
further access to this module
REQ_STM_13 System should send a message to receiving and issuing store whenever stock
transfer is initiated.
REQ_STM_14 System should allow store-man of issuing store to transfer the stock either
from its own store or one of its subordinate store.
REQ_STM_15 System should have the provision to generate issue vouchers and update the
concerned stock register of the store from where stock is transferred.
REQ_STM_16 An indicative list of details captured in stock transfer voucher is as follows:
Issuing Store Name
Receiving Store Name
Issuing District/Unit/Wing Name
Receiving District/Unit/Wing
“Design, Development and Implementation of Store Management System (SMS)”
Page 152 of 198
Requirement ID
Requirement Description
Stock Transfer Initiation Officer
Stock Transfer order number
Item Name
Item Details
Number of Items
Receiving Store Representative Name
Signature of receiver
Signature of Store Man
Signature of Issuing SP
Selected bidder should consult with Rajasthan Police and finalize template
of voucher.
REQ_STM_17 System should create a pending prompt at receiving store when the issuing
store has issued issue voucher
REQ_STM_18 System should have the ability to replicate detail of issued items across issue
register and stock register of issuing store
REQ_STM_19 System should automatically update the received register and stock register of
receiving store when the store-man of receiving store updates the pending
issue voucher status.
REQ_STM_20 System should automatically update the ledger and inventory balance of both
issuing and receiving stores
REQ_STM_21 System should update the location of items in stock registers of Central Store
and all higher level stores.
REQ_STM_22 System should allow the higher level store to reverse or stop the stock transfer
process.
REQ_STM_23 System should ensure that all the business rules/logic is followed in stock
transfer process. If any deviation is observed, system should prompt the user
to take the permission of higher level authorized officer to move further.
REQ_STM_24 System should be able to update the personnel or branch allotment registers
in case stock was first collected
MIS Reports
“Design, Development and Implementation of Store Management System (SMS)”
Page 153 of 198
Requirement ID
Requirement Description
REQ_STM_25 System should have the ability to generate the reports of all items issued by a
store on a particular day and also in a specific period.
REQ_STM_26 System should have the ability to generate list of all item issued by a store on
a specific day and also during a specific period
REQ_STM_27 System should have the ability to generate store category wise list of items
issued or received by the store
REQ_STM_28 System should be able to generate reports of all successful and failed stock
transfer processes.
REQ_STM_29 System should be able to generate list of all items issued/received to/from a
particular district/unit/wing FUS or a SFUS.
REQ_STM_30 System should have the ability to generate list of stock transfer processes
initiated by a specific officer/authority
Integration Requirements
REQ_STM_31 System should allow integration with Master data Management Module so that
any changes made in the Master data management module are reflected in
real-time in Stock Transfer Module
REQ_STM_32 Stock Transfer Module will be integrated with Workflow management module
so that only those processes are allowed which have been created in workflow
for that store
REQ_STM_33 Stock Transfer Module should be integrated with electronic/digital signature
pad so that whenever signatures are to be collected through pads, signature
pads are activated and signatures operation is performed effortlessly
REQ_STM_34 Stock Transfer Module should be integrated with all other modules in the
system which are logically related according to workflow
“Design, Development and Implementation of Store Management System (SMS)”
Page 154 of 198
Requirement ID
Requirement Description
REQ_STM_35 System should have a provision for biometric authentication at all places in the
workflow where signatures where required in manual system. User should
have the provision to authenticate the information and processes using any of
the authentication methods viz. biometric authentication system, electronic
signature pad and also manual signatures on paper.
1.7 Employee Transfer Module
This module will be used to record stock movement related to employee transfer from one
district/unit to another district/unit. Stock movements captured in this module will update the stock
registers and related ledger balances of the reliving and accepting district/unit stores. The stock
position in the employee dashboard will also be updated using this module.
Requirement ID Requirement Description
System Login
REQ_ETM_1 The system should be accessible through centralized web application/offline
module for internal user assigned with following roles and indicative
privileges:
o Central Store
- SP (Central Store)
- Store In-charge
- IT system administrator
- Any other employee assigned to perform store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
“Design, Development and Implementation of Store Management System (SMS)”
Page 155 of 198
Requirement ID Requirement Description
- Sub-unit Head
- Store Man
REQ_ETM_2 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police
REQ_ETM_3 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police
REQ_ETM_4 System should have the provision of offline access along with access
through centralized web application. The system should allow all capabilities
through online access and limited capabilities through offline access.
REQ_ETM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_ETM_6 This module will also be accessible to IT administrator to implement system
level changes.
REQ_ETM_7 This module will also be available to SP C/S to override any unauthorized
modifications
REQ_ETM_8 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by
a higher level user
Employee Transfer
REQ_ETM_9 The system should have the capability to initiate stock transfer movement
related to employee transfer only through authorized user.
REQ_ETM_10 The system should allow store man of the store with which employee is
currently tagged to determine store related dues to be paid by the employee.
REQ_ETM_11 System should provide provision to determine what items are issued to the
employee, which of these items are to be returned to the store and which
items employee is permitted to carry with him/her.
“Design, Development and Implementation of Store Management System (SMS)”
Page 156 of 198
Requirement ID Requirement Description
REQ_ETM_12 The system should allow store man of the related store to generate
transfer/kit voucher when the dues have been paid. System should prompt
store man if the dues have not been paid and should not allow further
processing.
REQ_ETM_13 System should have the provision to update stock register of store when
employee has returned returnable items.
REQ_ETM_14 An indicative list of details captured in Transfer/Kit voucher is as follows:
Store Name
Employee Unit/Wing Name
Employee Designation
Item list
Item Details
Number of Items
Accepting District/Unit/Wing Name
Accepting Store Name
Signature of Store Man
Signature of Employee
Signature of SP (District/Unit/Wing)
Selected bidder should consult Rajasthan Police and finalize the template of
voucher.
REQ_ETM_15 System should have the provision to automatically update personnel
allotment register when items have been returned.
REQ_ETM_16 System has the ability to mention only those items on transfer/kit voucher
which an employee can carry with him/her.
REQ_ETM_17 Upon generation of transfer/kit voucher from relieving store, system should
automatically update stock register of accepting store with pending
confirmation of transfer voucher items.
REQ_ETM_18 System should have the ability to update inventory balances of all higher
level stores related to the concerned store according to workflow.
REQ_ETM_19 System should send information SMS/Email to the concerned employee
upon creation of transfer voucher.
“Design, Development and Implementation of Store Management System (SMS)”
Page 157 of 198
Requirement ID Requirement Description
REQ_ETM_20 System has the provision to update the employee dashboard with stock
movements captured in vouchers and registers of the store
REQ_ETM_21 Upon acceptance of the transfer voucher at the accepting store, system
should automatically update stock register and stock balances of the
accepting store.
REQ_ETM_22 All necessary information of employee transfer movement should be
available with Central Store
REQ_ETM_23 System should have the provision to stop/reverse employee transfer
movement by the Central Store or higher level store.
MIS Reports
REQ_ETM_24 The system should be able to generate reports of all employee movements
on a particular date or a particular period
REQ_ETM_25 The system should be able to generate report of all employees transferred
from one particular district/unit to another district/unit.
REQ_ETM_26 The system should have the provision to generate list of all items returned by
transferred employees on a given date or a given period.
REQ_ETM_27 The system should be able to generate report of dues received from all
transferred employees
REQ_ETM_28 System should allow higher level stores to see report of all employee
movements at lower level stores
REQ_ETM_29 System should allow list of pending tasks related to employee transfer
movements
Integration Requirements
REQ_ETM_30 System should allow integration with Master data Management Module so
that any changes made in the Master data management module are reflected
in real-time in Employee Transfer Module
REQ_ETM_31 Employee Transfer Module will be integrated with Workflow management
module so that only those processes are allowed which have been created in
workflow for that store
“Design, Development and Implementation of Store Management System (SMS)”
Page 158 of 198
Requirement ID Requirement Description
REQ_ETM_32 Employee Transfer Module should be integrated with electronic/digital
signature pad so that whenever signatures are to be collected through pads,
signature pads are activated and signatures operation is performed
effortlessly
REQ_ETM_33 Employee Transfer Module should be integrated with all other modules in the
system which are logically related according to workflow
REQ_ETM_34 System should have a provision for biometric authentication at all places in
the workflow where signatures where required in manual system. User
should have the provision to authenticate the information and processes
using any of the authentication methods viz. biometric authentication system,
electronic signature pad and also manual signatures on paper.
1.8 Fixed Assets Module
This module will be used to record the details of all fixed assets available with Rajasthan Police.
Various kinds of buildings, offices, residential complexes, land parcels etc. available with
Rajasthan Police are classified as fixed assets. This module will be used to capture information
like category of asset, geographical location, administrative ownership, usability etc. This activity
will not be recurring in nature. Once the assets information is entered in the system, only
subsequent changes to that asset and addition of new assets will be recorded in the system.
Requirement ID Requirement Description
System Login
REQ_FAM_1 The system should be accessible through centralized web application/offline
module for internal user assigned with following roles and indicative
privileges:
o Central Store
- SP (Central Store)
- Store In-charge
“Design, Development and Implementation of Store Management System (SMS)”
Page 159 of 198
Requirement ID Requirement Description
- IT system administrator
- Any other employee assigned to perform store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
REQ_FAM_2 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police
REQ_FAM_3 The system shall maintain non editable audit trail of all activities carried out
by any user in Rajasthan Police
REQ_FAM_4 System should have the provision of offline access along with access
through centralized web application. The system should allow all capabilities
through online access and limited capabilities through offline access.
REQ_FAM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
ensure that the data is not submitted by non-humans.
REQ_FAM_6 This module will also be accessible to IT administrator to implement system
level changes.
REQ_FAM_7 This module will also be available to SP C/S to override any unauthorized
modifications
REQ_FAM_8 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by
a higher level user
Fixed Asset Information
“Design, Development and Implementation of Store Management System (SMS)”
Page 160 of 198
Requirement ID Requirement Description
REQ_FAM_9 The system should have the provision to identify various categories of fixed
assets and allow different parameters to be captured for each category of
asset
REQ_FAM_10 The system should have the provision to enter, modify and delete details of
any fixed asset only by the authorized system user for that category of asset.
REQ_FAM_11 System should allow uploading of reference documents for each asset.
REQ_FAM_12 System should allow deferred uploading of necessary document. System
should allow triggers and reminders to be set when this option is chosen
REQ_FAM_13 System should also allow mentioning of reference of necessary documents
instead of uploading of documents.
REQ_FAM_14 System should allow different templates of information to be captured for
each category of asset. An indicative list of fields in a general template is as
follows;
District
CO Office
Police Station
Outpost
Occupied Land
Vacant Land
Constructed Area
Land Disputes
Detail of disputes
Residential Accommodation
Facilities
Religious Places
Under Construction
Unusable Building
Remarks
Selected bidder should consult Rajasthan Police and finalize template for
each category of asset.
REQ_FAM_15 System should have the field level validation and should prompt user
“Design, Development and Implementation of Store Management System (SMS)”
Page 161 of 198
Requirement ID Requirement Description
whenever any deviation is noted.
REQ_FAM_16 System should have the provision to record GIS/GPS detail of each asset
and should create a google map pointer whenever such details are added.
REQ_FAM_17 System should allow authorized higher level user to modify/delete the
information entered by the lower level user.
REQ_FAM_18 System should allow different file formats for attachment such as PDF,
JPEG, TIF, DOC, XLSX etc.
REQ_FAM_19 System should inform the higher level user whenever any
modification/deletion of information is done by lower level user.
REQ_FAM_20 System should allow the authorized higher level user to override/reverse
changes/additions made by lower level users.
REQ_FAM_21 System should allow modification of information template for each category
on the fly by the authorized user.
REQ_FAM_22 System should create a unique ID for each asset.
MIS Reports
REQ_FAM_23 The system should be able to generate category wise reports of assets.
REQ_FAM_24 System should allow generation of reports
range/circle/district/unit/wing/police station/outpost wise.
REQ_FAM_25 System should allow generation of reports according to status of various
assets i.e. reports of assets which are under construction, construction
complete etc.
REQ_FAM_26 System should allow generation of reports on a particular date or during a
specific period.
REQ_FAM_27 System should allow reports to be created according to user created
business rules and triggers.
REQ_FAM_28 System should allowing viewing and downloading of reports in various
formats like PDF, XLSX, DOC, HTML etc.
REQ_FAM_29 System should allow reports to be linked to dashboard of various employees.
“Design, Development and Implementation of Store Management System (SMS)”
Page 162 of 198
Requirement ID Requirement Description
Integration Requirements
REQ_FAM_30 System should allow integration with Master data Management Module so
that any changes made in the Master data management module are reflected
in real-time in Fixed Assets Module
REQ_FAM_31 Fixed Assets Module will be integrated with Workflow management module
so that only those processes are allowed which have been created in
workflow for that store
REQ_FAM_32 Fixed Assets Module should be integrated with electronic/digital signature
pad so that whenever signatures are to be collected through pads, signature
pads are activated and signatures operation is performed effortlessly
REQ_FAM_33 Fixed Assets Module should be integrated with all other modules in the
system which are logically related according to workflow
REQ_FAM_34 System should have a provision for biometric authentication at all places in
the workflow where signatures where required in manual system. User
should have the provision to authenticate the information and processes
using any of the authentication methods viz. biometric authentication system,
electronic signature pad and also manual signatures on paper.
1.9 Workflow Management Module
The proposed solution shall be capable of an automated electronic processing of data and
documents that allows for the integration of Business Rules. It must adhere to the thin client open
standards and must not require any proprietary software to be installed on client machines. It
shall be able to deal with exceptions when these occur by changing business rules or even the
entire processes in real time to respond to business conditions. It shall enable the efficient and
accurate tracking of the entire cycle of each major business process and provide means of
generating reports for management as well as for statistical purposes. It shall seamless manage
documents related to the workflow and be capable of retrieving and attaching documents and
archiving the processed documents with metadata in the specified folder structure.
“Design, Development and Implementation of Store Management System (SMS)”
Page 163 of 198
Requirement ID Requirement Description
System Access and Login
REQ_WFM_1 The system should be accessible through centralized web application/offline
module for internal user assigned with following roles and indicative
privileges:
o Central Store
- SP (Central Store)
- Store In-charge
- IT system administrator
- Any other employee assigned to perform store duty
o Field Unit Stores
- SP (District/Unit/Wing)
- Store Man
o Sun-field unit stores
- Sub-unit Head
- Store Man
REQ_WFM_2 The system should allow authorized users to access various functions, forms,
screens, sub modules, information etc. as per the authorizations and user
roles permissible as per guidelines and policies of the Rajasthan Police
REQ_WFM_3 The system shall maintain non editable audit trail of all activities carried out by
any user in Rajasthan Police
REQ_WFM_4 System should have the provision of offline access along with access through
centralized web application. The system should allow all capabilities through
online access and limited capabilities through offline access.
REQ_WFM_5 The system shall apply spam control measures like ‘captcha’ images during
registration to avoid spurious details being automatically submitted and to
“Design, Development and Implementation of Store Management System (SMS)”
Page 164 of 198
ensure that the data is not submitted by non-humans.
REQ_WFM_6 This module will also be accessible to IT administrator to implement system
level changes.
REQ_WFM_7 This module will also be available to SP C/S to override any unauthorized
modifications
REQ_WFM_8 System should have the provision to identify and categorize
activities/processes which need to be performed in maker-checker mode i.e.
work performed by lower level user is authorized and authorized/finalized by a
higher level user
Task Routing
REQ_WFM_9 The system shall have a workflow engine to support different types of
document routing mechanism including:
REQ_WFM_10 Sequential routing –Tasks are to be performed one after the other in a
sequence
REQ_WFM_11 Parallel routing – Tasks can be performed in parallel by splitting the tasks
among multiple users and then merging as single composite work item. The
system shall support conditional merging of multiple parallel activities i.e.
Response from mandatory parallel work stages before it can be forwarded to
next stage
REQ_WFM_12 Rule based routing - One or another task is to be performed, depending on
predefined rules
REQ_WFM_13 Ad-hoc routing: Changing the routing sequence by authorized personnel
Process Designing
I. Graphical Route Designer
REQ_WFM_14 The workflow management system shall support Inbuilt Graphical route
designer for modelling complex business processes using drag and drop
facilities.
REQ_WFM_15 The system shall allow process designers to define multiple automatic system
defined stages, where no human intervention is required.
REQ_WFM_16 The interface shall be easy to use so that process owners can change the
business process as and when required without any programming knowledge.
“Design, Development and Implementation of Store Management System (SMS)”
Page 165 of 198
REQ_WFM_17 The system shall enable process designers to design multiple sub-processes.
This includes mapping of the existing process instance to the newly created
process instance as per mapping defined in the route.
REQ_WFM_18 The workflow management system development environment shall provide
easy navigation to choose sub-processes as required to be invoked from
within a process.
REQ_WFM_19 Facility to copy and paste work stages along with all its properties.
REQ_WFM_20 Facility to define documents viewed and to be attached at individual stages.
REQ_WFM_21 The process designer shall support multiple introduction stages for
introducing different document types from different acquisition sources
REQ_WFM_22 Facility to define multiple archive stages for archive selected documents and
indexes at any stage of workflow process.
REQ_WFM_23 The system shall provide facility to define hold stages so that a particular
instance or the workflow can be kept on hold for specified interval on the
basis of pre-defined condition. The system shall also provide facility to define
conditions for resuming the instance from hold stage.
REQ_WFM_24 The system shall allow process designers to design properties for each work
stage like default document view, form view or Exception view etc.
REQ_WFM_25 The system shall allow users to define entry-level settings like increase of
priority or sending an email trigger on the basis of pre-defined conditions or
setting up particular variable or property etc.
REQ_WFM_26 The workflow management system shall support the definition of roles and
allow many-to-many relationships between users and roles to be defined.
REQ_WFM_27 The workflow management system shall be capable of automatically
deploying an entire business process application (including forms and
adapters) to the servers from the development environment
II. Inbuilt Form Designer
REQ_WFM_ 28 The system shall provide inbuilt facility to design custom forms that can be
attached at one or more stages of workflow.
REQ_WFM_29 The form designer interface shall support facility to define text boxes, Combo
boxes, radio buttons, Drop down etc.
“Design, Development and Implementation of Store Management System (SMS)”
Page 166 of 198
REQ_WFM_30 The system shall provide facility to define variables in the process or in
external database tables, which can be linked to fields defined in the form for
efficient data entry.
REQ_WFM_31 The system shall provide facility to define zones at forms and images, so that
relevant part of the image is highlighted for image assisted data entry.
REQ_WFM_32 The system shall support field level calculations at form level
REQ_WFM_33 Facility to use scripts for defining field level validations
III. Automatic Escalations
REQ_WFM_ 34 The system shall provide facility to define multi-level escalation procedures
REQ_WFM_35 The system shall provide facility to define deadlines to individual work stages
and escalation to respective or group of individuals, if the instance is not
processed in specified time frame.
REQ_WFM_36 The system shall provide facility to define multi-level escalations on the basis
of deadlines i.e. Level 1 escalation after specified time and Level 2 escalation
after specified time.
REQ_WFM_37 Facility to raise custom triggers like Email, SMS etc. for escalations.
REQ_WFM_38 The system shall support inbuilt calendar for defining Holidays and Working
hours and the escalations and reminders shall be raised on the basis of this
i.e. if the escalation time is set for 2 days and there is Sunday in between
then it shall not be included
IV. Inbuilt Exceptions
REQ_WFM_39 The system shall provide facility to define exceptions at individual stages,
which shall dynamically change the route on execution.
REQ_WFM_40 The system shall have facility to give rights to raise and clear exceptions at
different stages of the process with user comments.
REQ_WFM_41 Facility to raise triggers on the basis of exceptions.
REQ_WFM_42 Facility to raise automatic exceptions on the basis of pre-defined conditions.
REQ_WFM_43 The system shall track all the exceptions raised in the course of process and
shall maintain history of that with user name, date, time and comments.
REQ_WFM_44 The system shall clearly differentiate process instances with and without
“Design, Development and Implementation of Store Management System (SMS)”
Page 167 of 198
exception
V Task Management
REQ_WFM_45 The system shall provide facility to define tasks for individual or group of
users with deadlines.
REQ_WFM_46 The system shall provide facility to define check lists for individual stage with
option to make particular checklist items as mandatory.
REQ_WFM_47 Facility to raise triggers on the basis of checklist.
REQ_WFM_48 The workflow management system shall have email notification to user when
the user is not logged on to the workflow management system. Upon
receiving the email, the user shall be able to click on the attachment in the
email to automatically launch the Workflow management system and present
the user with the task to act on.
REQ_WFM_49 Automatic reminders to concerned users for delegated tasks.
REQ_WFM_50 The system shall allow definition of audit stages to audit work of new users.
The users shall be able to define percentage of work to be audited on the
basis of which, random instances shall be picked up and sent to auditing
supervisor.
REQ_WFM_51 The workflow management system shall provide user-definable job filters and
sorters for the outstanding tasks for viewing and work prioritization.
REQ_WFM_52 The workflow management system shall allow the users to route/re-route the
jobs to one or more other users by job and by users (e.g. on long leave,
resignation).
REQ_WFM_53 The workflow management system shall allow automatic temporary re-routing
of jobs to one or more other users (e.g. temporary covering of duties).
VI. Inbuilt Triggers
REQ_WFM_ 54 The system shall provide facility to define custom triggers like Emails, Word
template or launching executable etc. on predefined conditions
REQ_WFM_55 The system shall provide facility to define custom templates for the triggers
with static and dynamic data.
REQ_WFM_56 The system shall provide facility to generate event based triggers for
automatically sending mails/ fax, generating responses, invoking data form for
“Design, Development and Implementation of Store Management System (SMS)”
Page 168 of 198
data entry, communicating from external systems.
REQ_WFM_57 The workflow management system shall have email notification to user when
the user is not logged on to the workflow management system. Upon
receiving the email, the user shall be able to click on the URL in the email to
automatically launch the Workflow management system and present the user
with the task to act on.
VII. Multiple Initiation Methodologies
REQ_WFM_58 The Workflow management system shall support multiple initiation
methodologies for different user groups or document types.
REQ_WFM_59 The Workflow management system shall support automatic initiation of
incoming faxes as separate instance with the fax document as an attachment.
REQ_WFM_60 The system shall support automatic initiation on the basis of incoming emails
with email as an attachment.
REQ_WFM_61 The system shall support facility to host online forms in PDF or JSP format,
which can be filled online by the users and on submission a process instance
is initiated.
VIII Custom Human to Human interfaces
REQ_WFM_62 The system shall support rapid application development component that
enables development of User friendly and customizable user interfaces for
each stage of the workflow on the fly.
REQ_WFM_63 The system shall provide facilities so that process implementer needs only to
define the work step parameters like the to do list, exceptions, comments,
associated Forms and related document images for each step based on,
which the user interface is automatically generated. Each parameter that
requires user input, including interfaces of integrated applications and images
that the user needs to refer to shall be made available in different frames
through a single desktop.
REQ_WFM_64 The desktop shall support inbuilt imaging capabilities and shall support
complete and automatic integration of every step of the workflow with the
underlying DMS for the purpose of document retrieving and processing.
There shall be no need for integrating individual steps of a workflow to DMS
separately.
“Design, Development and Implementation of Store Management System (SMS)”
Page 169 of 198
Architecture and Technology
REQ_WFM_ 65 The workflow management system shall be based on an N-tier, open,
scalable architecture.
REQ_WFM_66 The workflow management system shall support thin client architecture.
REQ_WFM_67 The workflow management system shall support Web based interfaces.
REQ_WFM_68 The workflow management system shall support XML messaging and SOA
Architecture.
REQ_WFM_69 The workflow management system shall have the ability to integrate through
messaging.
REQ_WFM_70 The workflow management system shall have the ability to integrate through
APIs.
REQ_WFM_71 The workflow management system architecture must be scalable and can
support increasing number of users and concurrent transactions.
REQ_WFM_72 The workflow management system shall run in a clustered environment.
REQ_WFM_73 The workflow management system shall be scalable through both horizontal
clustering (multiple channels) and vertical clustering (multiple instances per
machine).
REQ_WFM_74 The Workflow management system must be Unicode compliant and shall also
support customizing the interface in local language.
REQ_WFM_75 The system should have the capability to interface with industry standard web
services through simple interfaces.
Process Management
REQ_WFM_ 76 The workflow management system shall be able to support complete
administration through a web browser interface.
REQ_WFM_77 The workflow management system shall allow administrators to manage
users, groups, roles and other document management operations.
REQ_WFM_78 The workflow management system shall allow administrators to suspend,
resume and control various processes from the same interface
REQ_WFM_79 The workflow management system shall have audit trail to maintain history of
all transactions performed on the system.
“Design, Development and Implementation of Store Management System (SMS)”
Page 170 of 198
REQ_WFM_80 The system shall give flexibility to administrator to do selective logging i.e.
suspend and resume audit trail generation for specific system and user
activities.
REQ_WFM_81 The workflow system shall give a facility to define turnaround time for the
complete process and also for the individual work stages for efficient
monitoring
REQ_WFM_82 The workflow system shall give a facility to set audit percentage for multiple
users at different stages, so that the specified percentage of work randomly
goes for work audit.
REQ_WFM_83 The workflow system shall give a facility to review the audit done by different
auditors.
REQ_WFM_84 The workflow system shall display all the queues corresponding to particular
process and add and remove multiple users to particular queue.
REQ_WFM_85 The workflow system shall allow administrator to set properties of particular
queue i.e. FIFO, Dynamic etc.
REQ_WFM_86 The system shall support load balancing of work items in case of dynamic
queues i.e. if more than one user is associated with particular queue, work
items shall be assigned on the basis of current load.
REQ_WFM_87 The workflow system shall support the concept of Shared and Personal
Queues, so that work items can either be permanently assigned to user’s
Personal queue or can be routed to shred pool of users.
REQ_WFM_88 The workflow management system shall allow administrator to add new
queues and associate multiple work steps with them.
REQ_WFM_89 The workflow system shall give a facility to set diversions for particular users
so that all the incoming work items are routed to assigned person or group of
users.
Application Access Control
REQ_WFM_90 The workflow management system shall provide comprehensive access
control mechanism.
REQ_WFM_91 All users of the workflow management system shall be able to access to their
own work queues and other work queues with access granted by the
workflow administrator. They shall not be able to delete assigned tasks from
“Design, Development and Implementation of Store Management System (SMS)”
Page 171 of 198
the work queues.
REQ_WFM_92 Process owners or workflow administrator shall be able to intervene the flow
of work items and reassign to specific user and shall also support ad-hoc
routing to specific stage in case of delays or bottleneck.
REQ_WFM_93 The application shall log all the actions done by individual users with user
name, date and time and the administrator shall be able to generate detailed
audit logs and history of the process instance.
REQ_WFM_94 The application shall support field level access so that authorized users can
only edit them.
REQ_WFM_95 The workflow management system shall allow process owners to track the
following status:
Task Status
REQ_WFM_95 Types of actions required (i.e. for approval, for acknowledgment, for further
dissemination, for reply, etc)
REQ_WFM_96 For a task in progress or a completed task on Name of Officer, Start Date,
End Date, Duration
Process Monitoring and Reporting
REQ_WFM_ 97 The workflow management system shall be able to keep track of the work
item status, the date/time the jobs are started and ended, the creation and
archival date of the documents.
REQ_WFM_98 The workflow management system shall provide graphical and tabular tools to
view progress of each individual process
REQ_WFM_99 The workflow management system shall support the generation of
performance comparison reports.
REQ_WFM_100 The workflow management system shall support users drill down from a
higher level view of business processes to lower level details.
REQ_WFM_101 The workflow management system shall support statistical reports like Total
turnaround time and delay report for complete process or specific work stages
REQ_WFM_102 The workflow management system shall support definition of new customized
reports based on exposed data points.
REQ_WFM_103 The workflow management system shall also provide dashboard interface for
“Design, Development and Implementation of Store Management System (SMS)”
Page 172 of 198
online reporting of various processes. The interface shall give a flexibility to
toggle between graphical and tabular view and tile different windows in the
same interface
User Management and Security
REQ_WFM_ 104 The workflow management system shall support integration with domain level
authentication and single sign on.
REQ_WFM_105 The workflow management system shall support integration with database-
based authentication.
REQ_WFM_106 The workflow management system shall be capable of giving access rights to
users/groups on work stages, documents, forms and also to the data fields.
REQ_WFM_107 The workflow management system shall support extensive password
validations i.e. locking of user account after specified number of unsuccessful
login attempts, password history, password expiry, passwords must be
alphanumeric and of minimum character length etc.
REQ_WFM_108 The workflow management system shall support SSL, HTTPS and session
timeouts.
Integration and Web Services
REQ_WFM_109 The workflow management system shall provide support to invocation of
external programs to perform activities of a process like launching core
application screen for data entry.
REQ_WFM_110 The workflow management system shall support integration based on
messaging.
REQ_WFM_111 The workflow management system shall support integration based on
standards such as XML
REQ_WFM_112 The workflow management system shall support message-based
collaboration based on protocols such as HTTP, FTP and SMTP.
REQ_WFM_113 The workflow management system shall support actions to be taken on
business processes based on messaging.
REQ_WFM_114 The workflow management system shall allow documents used in processes
to come from inbuilt proposed document management system.
REQ_WFM_115 The workflow management system shall support integration with Email
“Design, Development and Implementation of Store Management System (SMS)”
Page 173 of 198
Servers.
REQ_WFM_116 The workflow management system shall support email-steps to be fully
integrated into business processes, not just for notification but also to initiate
or complete a work step.
REQ_WFM_117 The workflow management system shall provide fully functional APIs for
Process, Rules and Integration engines.
REQ_WFM_118 The workflow management system shall support web services.
REQ_WFM_119 The workflow management system shall enable the work items to access the
web methods of a remotely deployed web service
REQ_WFM_120 The system shall allow the data to be mapped from the workflow to Web
method parameters and vice versa.
REQ_WFM_121 The system shall allow support of both synchronous as well as asynchronous
mode to invoke Web methods
REQ_WFM_122 The workflow management system shall allow a step of a business process or
integration process to be performed by Web services.
REQ_WFM_123 The workflow management system shall allow for an integration flow or a
business process to be made available as Web services
1.10 Dashboard and Reporting Module
Requirement ID
Requirement Description
REQ_GEN_1 Each user of SMS should have a customized dashboard view on logging into
the system with key sections as
Activities pending
“Design, Development and Implementation of Store Management System (SMS)”
Page 174 of 198
Requirement ID
Requirement Description
Activities assigned
Key MIS
SMS
Notifications
Link to allowable modules/activities for particular User
REQ_GEN_2 System should provide individual dashboard for all employees
REQ_GEN_3 System should provide individual dashboard for all branches/sections who are
issued items
REQ_GEN_4 Dashboard should provide customization facility to dashboard owners i.e.
users should be able to add or delete information/data fields according to their
roles and privileges.
REQ_GEN_5 System should prompt user if a data/information is tried to be included in the
dashboard for which user does not enjoys access. System should provide user
the facility to send electronic request to authorized higher officer to allow the
desired data/information on his/her dashboard.
REQ_GEN_6 Dashboard should all users to generate reports of data accessible to them
according to their roles and privileges
REQ_GEN_7 System should allow higher level users to view dashboards of lower
level/subordinate users according to workflow, business rules and roles and
privileges granted to various levels of users.
REQ_GEN_8 System should allow collapsible windows in the dashboard so that users
should be able pick and expand relevant and desirable to view.
REQ_GEN_9 System should have provision to generate various charts/graphs from data
available to a user from his/her dashboard.
REQ_GEN_10 System should allow users to remove data which may not be needed by the
user.
REQ_GEN_11 System should allow user to add more data and information on his/her
dashboard. System should ensure that if the intended data/info
“Design, Development and Implementation of Store Management System (SMS)”
Page 175 of 198
Requirement ID
Requirement Description
REQ_GEN_12 System should allow users to set triggers/rules upon activation of which
system automatically populates the user’s dashboard with intended
data/information.
Reporting
REQ_GEN_13 System should allow customized development of reports on the fly to various
users according to user’s roles and privileges.
REQ_GEN_14 System should ensure that no business rule/logic or orders are violated in
creation of reports. For possible breaches should disallow further processing
and prompt user to take permission from authorized officer.
REQ_GEN_15 System should allow generation of reports for various data points on a specific
day or for a specific duration or period
REQ_GEN_16 System should allow generation of report according to store level and store
category
REQ_GEN_17 System should allow generation of reports for only particular data appoints or
records found in a set of records or information
REQ_GEN_18 System should allow automated generation of reports for triggers set by the
users
REQ_GEN_19 System should allow to set periodicity of certain reports and should
automatically generate reports at pre-defined times/intervals
REQ_GEN_20 System should allow sending of reports via email, fax etc. to other authorized
users
REQ_GEN_21 System should allow conversion of various reports from one format to another
for exp. Should allow user to convert reports from csv to excel, excel to pdf
etc.
REQ_GEN_22 System should allow users to set passwords for access to reports.
REQ_GEN_23 System should allow users to drill-down the data generated in a report
REQ_GEN_24 System should allow users to set validity periods for the reports beyond which
reports may not be accessible.
REQ_GEN_25 System should allow generation of reports related to carious tasks and
“Design, Development and Implementation of Store Management System (SMS)”
Page 176 of 198
Requirement ID
Requirement Description
performance of those tasks by assigned user
REQ_GEN_26 System should be able to store all reports generated by a user. User should be
able to set up a period beyond which reports are deleted from the system.
REQ_GEN_27 System should be able to generate reports according to various parameters
such as district/unit/wing wise reports, item wise reports, year/month/weak/day
wise reports, task wise reports, demand head wise reports etc.
REQ_GEN_28 System should able to include pictures/images etc. which may be needed in a
report
1.11 Other Requirements
1.11.1 Integration Requirements
The Store Management System (SMS), in future would be required to integrate with certain
application and mechanisms. Selected bidder should ensure that system so designed and
developed that future integration with other applications is done seamlessly without involving re-
designing or re-development.
Application Status Integration Requirements Data exchange methodology
Integration with
UID initiative
Envisaged System should have provision for future
integration with UIDAI system in terms of
Using Aadhaar and
demographic/biometric
authentication for service
delivery
Complying to various
standards and compliance
requirements of various
components in line with
guidelines issued by
UIDAI
Flat files/ Web
services for
Data
exchange
“Design, Development and Implementation of Store Management System (SMS)”
Page 177 of 198
Integration with
SSDG
Envisaged In order to achieve future integration of
information across state departments,
State Service Delivery Gateway
(‘SSDG’) has been conceptualized.
SSDG acts as standards-
based messaging
switches and provides
seamless interoperability
and exchange of data
across the departments.
The applications
developed at state level
can interact with the
gateway through
connector.
The web user shall first be
routed to state service
delivery gateway from
department portal and
after data and identity
scrutiny shall be routed to
Department back office.
The bidder will ensure
middleware solution as a
back up to the SSDG.
Flat files/ Web
services for
Data
exchange
Selected bidder may be required to integrate/provide connectors/APIs to integrate SMS modules
with above mentioned applications in the future. System design should be such that the
envisaged integration is required to be done, no re-designing and re-development is required.
“Design, Development and Implementation of Store Management System (SMS)”
Page 178 of 198
1.11.2 Management of documents
Central Repository for managing documents would form integral part of the solution. Key points
where documents shall be managed through solution include
Managing various documents of Rajasthan Police including operating rules, orders,
guidelines, procedures, registers, policies etc.
Documents submitted by various users/stores as per requirements of workflow for above
detailed core modules
This module helps in catering to all requirements of Rajasthan Police related to management of
documents. It provides clear metadata for categorization of any document entering the system. It
must also support a string based search.
Requirement ID Requirement Description
REQ_GEN_29 The system shall allow storing and retrieval of digital documents comprising
of
a) Scanned documents
b) Images
c) Video clips
d) Audio clips
REQ_GEN_30 Automatic categorization of documents as different documents like vouchers,
receipts, challans/bills, proof documents, inspection report etc.
REQ_GEN_31 Easy to use GUI for setting the scanning properties like indexing parameters,
document and folder nomenclature, zones for data extraction etc.
REQ_GEN_32 Facility to upload scanned batches from different field offices with Auto
folder/Subfolder creation document filing & indexing on user defined fields.
REQ_GEN_33 System ability to provide Compression of scanned image files in TIF Format.
REQ_GEN_34 The System shall support Image Editing operations such as page insertion,
deletion merge/split pages, etc.
REQ_GEN_35 The system shall provide facility for merging/splitting documents based on
bar-code/page count, etc. to assemble documents from scanned batches
REQ_GEN_36 Support all the special image enhancement functionality offered by the
scanner through the driver interface.
REQ_GEN_37 The system shall support categorization of documents in folders-subfolders
“Design, Development and Implementation of Store Management System (SMS)”
Page 179 of 198
Requirement ID Requirement Description
just like windows interface. There should not be any limit on the number of
folder and levels of sub folder
REQ_GEN_38 The system shall provide facility to link cross-related documents.
REQ_GEN_39 The system shall provide search facility to in the same interface, so that
users are able to search the documents to be linked.
REQ_GEN_40 The system shall support versioning of documents with facility to write
version comments
REQ_GEN_41 The system shall allow Locking of documents for editing and importing it back
into the system through check-in/Check-out features
REQ_GEN_42 The system shall support Applet for viewing Image documents- No third party
viewers should be there for viewing of scanned images. Please specify if
third party applets are used and the licensing terms together with cost
implication
REQ_GEN_43 Image view applet should support progressive display technology.
REQ_GEN_44 Even for multi-page document, the download and view should be page by
page.
REQ_GEN_45 The system shall facilitate Document View without the native application in
pdf or html view for office applications like Word, excel, PPT etc.
REQ_GEN_46 The system shall facilitate zoom-in/zoom-out, zoom percentage and Zoom
lens to zoom in on a part of image and other image operations like Invert,
rotate etc.
REQ_GEN_47 Document view shall have the provision to draw a line, insert arrows etc. over
image document.
REQ_GEN_48 Document view shall have the provision to highlight or hide certain text by
drawing line rectangle and solid rectangle.
REQ_GEN_49 Document view shall have the provision to insert text over image document
REQ_GEN_50 The system shall support for viewing documents in native application
REQ_GEN_51 The system shall provide facility of putting text, graphic and image
annotations on document pages
“Design, Development and Implementation of Store Management System (SMS)”
Page 180 of 198
Requirement ID Requirement Description
General
REQ_GEN_52 The system shall provide an easy to use email like interface for routing &
working on workflow items
REQ_GEN_53 The system shall provide an inbox like feature to receive workflow item
REQ_GEN_54 The system shall provide an Sent Item like feature to view forwarded
workflow item
REQ_GEN_55 The system shall have a tree like structure for frequently use features.
Indexing
REQ_GEN_56 The System shall provide facility to index folders and documents on user-
defined indexes.
REQ_GEN_57 The system shall provide facility to set particular fields as mandatory or
unique
Search and Retrieval
REQ_GEN_58 The system shall provide extensive search facility to retrieve documents or
Folders/Files
REQ_GEN_59 The system shall support saving of search queries and search results
REQ_GEN_60 The system shall have quick retrieval ( should be able to handle Terabytes
of data quickly in less than 10 seconds(indicative))
REQ_GEN_61 The system shall support search for documents or folders on document or
folder on profile information such as name, created, modified or accessed
times, keywords, owner etc.
REQ_GEN_62 The system shall support combined search on Profile, Indexed and Full Text
Search
REQ_GEN_63 The system shall support search for documents/Folders using user-defined
indexes and document classes.
REQ_GEN_64 The system shall support Full Text Search on image and electronic
documents
REQ_GEN_65 The system shall support highlighting of searched string with a facility to
browse between pages for a multiple page document and moving between
“Design, Development and Implementation of Store Management System (SMS)”
Page 181 of 198
Requirement ID Requirement Description
hit pages
REQ_GEN_66 The system shall support advanced search using Boolean and logical
operators like and, or, greater than etc. for example searching application
form on the basis of customer type and city
REQ_GEN_67 The system shall support facility to export results in excel format
REQ_GEN_68 The system should provide support for configuring and saving search
criteria’s
REQ_GEN_69 Check-In and Checkout support for collaborative working on documents
Security
REQ_GEN_70 The system shall support access permissions on Folders, documents and
object level
REQ_GEN_71 The system shall support multiple levels of access rights (Delete/ Edit/ View/
Print/ Copy or Download).
REQ_GEN_72 The system shall support for application based rights
REQ_GEN_73 The system shall support system privileges like Create/Delete Users, Define
indexes etc.
REQ_GEN_74 The system shall support secure login id and passwords for each user and
passwords shall be stored in encrypted format in database
REQ_GEN_75 The system shall have a facility to define password policy with extensive
password validations like passwords must be of minimum 8 characters, shall
be alphanumeric, locking of user-id after three un-successful attempts,
password expiry, password history so that passwords are not same as
previous passwords etc.
REQ_GEN_76 The system shall support Disaster recovery by replicating the data at remote
locations
REQ_GEN_77 The system shall support provide support for HTTPs/SSL for secured data
transfer and session timeouts.
REQ_GEN_78 The system shall provide LDAP support for integrating with directory services
and shall support single sign on
“Design, Development and Implementation of Store Management System (SMS)”
Page 182 of 198
Requirement ID Requirement Description
REQ_GEN_79 The system shall support Extensive Audit-trails at document, Folder and for
highest levels for each action done by particular user with user name, date
and time
REQ_GEN_80 The system shall support integration with database-based authentication.
Administration
REQ_GEN_81 The system shall support web-based administration module for the complete
management of system.
Document Delivery and Distribution
REQ_GEN_82 The system shall allow users to download documents through HTTP
depending upon the access rights
REQ_GEN_83 The system shall support for Print/Mail/Fax of documents
Reports and Audit Trails Features
REQ_GEN_84 The system shall support extensive Reports and audit trails and shall also
provide data points and facility to design new reports
REQ_GEN_85 The application shall log all the actions done by individual users with user
name, date and time and the administrator shall be able to generate detailed
audit logs and history of the process instance.
Reminders and Alarms
REQ_GEN_86 The system should have the capability to set automatic reminders and alarms
to concerned users.
Monitoring and Tracking
REQ_GEN_87 The system shall be able to keep track of the status, the date/time the jobs
are started and ended, the creation and archival date of the documents.
REQ_GEN_88 The system should have inbuilt monitoring and diagnostic tool for monitoring
of logs, versions and important services
Custom Human to Human interfaces
REQ_GEN_89 The system shall support Rapid Application Development component that
enables development of User friendly and customizable user Interface.
REQ_GEN_90 The desktop shall support inbuilt Imaging capabilities and shall support
“Design, Development and Implementation of Store Management System (SMS)”
Page 183 of 198
Requirement ID Requirement Description
complete and automatic integration of every step of the approval workflow
with the underlying DMS for the purpose of document retrieving and
processing. There shall be no need for integrating individual steps of a
workflow to DMS separately.
REQ_GEN_91 The system shall be Unicode compliant for supporting different languages
and shall also provide localization kits for localizing the User Interface in
particular language
REQ_GEN_92 The system shall have a support for Hindi language GUI
Integration and Web Services
REQ_GEN_93 Should be based on open standards and have API support for data import &
export
REQ_GEN_94 The system shall provide support to invocation of external programs to
perform activities of a process like launching core application screen for data
entry.
REQ_GEN_95 The system shall support integration based on messaging
REQ_GEN_96 The system shall support integration based on standards such as XML
REQ_GEN_97 The system shall support message-based collaboration based on protocols
such as HTTP, FTP and SMTP.
REQ_GEN_98 The system shall support integration with Email Servers.
REQ_GEN_99 The system shall support email-steps to be fully integrated, not just for
notification but also to initiate or complete a work step.
REQ_GEN_100 The system shall provide fully functional APIs for Integration.
REQ_GEN_101 The system shall provide presentation level API to customize user task
interfaces.
REQ_GEN_102 The system shall support Web services.
REQ_GEN_103 The system shall enable the work items to access the Web methods of a
remotely deployed web service
REQ_GEN_104 The system shall allow support of both synchronous as well as asynchronous
mode to invoke Web methods
“Design, Development and Implementation of Store Management System (SMS)”
Page 184 of 198
Requirement ID Requirement Description
REQ_GEN_105 The system shall support Web based interfaces.
REQ_GEN_106 The system may have its own front-end or launch any application.
REQ_GEN_107 The system should have the capability to interface with industry standard
web services through simple interfaces.
1.11.3 Additional Requirements
S No. Business Requirement Description
System Wide Functionalities
REQ_GEN_108 Consistent, globally unique naming and addressing scheme for data made
centrally and automatically
REQ_GEN_109 Centralized application and components
REQ_GEN_110 Application shall be paperless and web-based. Functions and other relevant
information shall be accessible to authorized persons on request.
REQ_GEN_111 Application shall be modular in design and shall be designed using modular and
reusable programming techniques for ease of maintenance.
REQ_GEN_112 For any hardware and software purchased in order to facilitate Application,
quality assurance requirements must be adhered to.
REQ_GEN_113 Application shall have the capability to ensure that management of data is
defined independently of the processes that create or use that data.
REQ_GEN_114 Application shall have the capability to format output to support HTML, XML,
text and any other format required for data exchange/integration with various
entities involved in the process.
REQ_GEN_115 The architecture shall be expandable. This requires that the application
architecture should include interfaces that will permit easy insertion of
additional capabilities as required (e.g., replacing an Relational Database
Management System (RDBMS) with an RDBMS with object oriented
extensions, adding new report formats, statistical algorithms etc.)
REQ_GEN_116 The architecture shall be operationally robust. This requires that the system
architecture should: - include standard error handling modules permitting the
system to degrade "gracefully" in the presence of failures, be functionally
“Design, Development and Implementation of Store Management System (SMS)”
Page 185 of 198
redundant when appropriate, ensure that functional allocation to architectural
elements does not introduce unacceptable delay or introduction of human error,
support end-to-end system performance analysis
REQ_GEN_117 Application shall be designed to permit the easy insertion of new modules and
new enhancements.
REQ_GEN_118 Internal application changes shall be transparent, any changes that will not be
transparent must be coordinated before implementation
REQ_GEN_119 Application shall have the capability to complete all requests (e.g., store,
retrieve, update, etc.) without any data loss
REQ_GEN_120 Application shall have a system of record for legal purposes and shall maintain
an audit file in chronological sequence of each transaction and all corresponding
corrections made during the transaction by clients or their facilitators
REQ_GEN_121 Application shall be made possible to distribute the elements between different
premises.(only if required)
REQ_GEN_122 Distributed elements shall operate as a single integrated and cohesive
information system
REQ_GEN_123 System shall have the capability to organize and store all data for aggregation
and analysis
REQ_GEN_124 System shall be able to add new storage devices, if required, to serve archiving
needs.
REQ_GEN_125 Application shall accommodate usage growth with minimal disruptions.
REQ_GEN_126 Application shall be designed to accommodate growth in data rates and
volumes for communications and networks
REQ_GEN_127 Application shall have the capability to define and modify Client’s access
privileges.
REQ_GEN_128 Application shall have the capability to remotely maintain and upgrade the
system
REQ_GEN_129 Application shall use open systems, standard-based architecture to meet
functional requirements and to inter-operate with existing information systems.
REQ_GEN_130 Application may be built from a combination of both unique and Commercial Off-
The-Shelf (COTS) service capabilities if required
“Design, Development and Implementation of Store Management System (SMS)”
Page 186 of 198
REQ_GEN_131 Application shall facilitate the development of applications; application platform’s
enabling services shall consist of well-defined Applications Program Interface
(API).
REQ_GEN_132 A standards-based operating system shall be selected, which will provide
formally defined APIs for application program access
System Management Requirements
REQ_GEN_133 System shall incorporate management capability, which shall include:
Configuration Management, Testing & Validation, Fault Detection, Fault
Isolation, Fault Recovery, Data collection, Data Analysis
REQ_GEN_134 System shall provide end-to-end performance monitoring and control.
REQ_GEN_135 System shall maintain knowledge of current operational status of all elements.
REQ_GEN_136 Necessary configuration control procedures shall be instituted to ensure a
complete understanding of system and configuration
REQ_GEN_137 System shall provide the capability to manage system operations,
administration, archiving, and security functions
REQ_GEN_138 System shall establish and maintain accounting information on communications
used.
REQ_GEN_139 System shall support end-to-end system fault isolation of all provided services,
including the capability to identify a failing node, element, and/or service, to the
level necessary to correct the fault.
REQ_GEN_140 System shall provide capability to manage fault isolation functions
REQ_GEN_141 System shall provide data quality determination and analysis, error correction,
recovery processing, and related quality control procedures and processes.
REQ_GEN_142 System shall provide for support of coordinated management of elements
distributed between different premises.
REQ_GEN_143 Application shall implement applications and infrastructure components to
permit management to monitor and measure the effectiveness.
REQ_GEN_144 Application shall permit inclusion of new or modified requirements during the life
of application with appropriate established change control procedures.
Operational Requirements
“Design, Development and Implementation of Store Management System (SMS)”
Page 187 of 198
REQ_GEN_145 Application shall support 24 hours per day, 7 days per week on a continuous
basis
REQ_GEN_146 User training shall be provided to authorized personnel to permit full use of
application
REQ_GEN_147 Application shall perform its operations in accordance with applicable policies
and procedures.
REQ_GEN_148 Data inputs to the application shall be validated prior to being processed
REQ_GEN_149 Input data shall be validated for out of range values.
REQ_GEN_150 Input data shall be validated for missing or incomplete data.
REQ_GEN_151 Input data shall be validated for unauthorized or inconsistent control data.
REQ_GEN_152 Input data shall be validated for values or volumes that are exceptional to the
norm.
REQ_GEN_153 Invalid input data shall be rejected and security incident shall be initiated.
REQ_GEN_154 Integrity checks functionality on any data generated by the system shall be
provided.
REQ_GEN_155 Reasonableness check functionality on the volume and values of data output
shall be provided.
REQ_GEN_156 Functionality necessary for scheduling of Application to certain days, dates or
time of day, shall be provided.
REQ_GEN_157 Functionality necessary for 'roll back' or recovery routines if applicable fails to
operate as planned shall be provided
Human Engineering Requirements
REQ_GEN_158 System shall provide a menu driven screen interface permitting a properly
trained user to navigate easily through the different functions of the system.
REQ_GEN_159 System shall provide users with access to information management services at
their premises.
REQ_GEN_160 The user interface shall be tailored to functions, which are authorized for the
user.
Back Up Requirements
“Design, Development and Implementation of Store Management System (SMS)”
Page 188 of 198
REQ_GEN_161 Back-up copies of data shall be taken at a mutually agreed upon frequency to
be consistent with the ability to recover cost effectively from any loss or
corruption.
Logs
The following operations shall be logged by means of automatic (machine
generated) logs:
REQ_GEN_162 Logs shall include process start and finish times.
REQ_GEN_163 Logs shall include Application faults, errors and recovery processes.
REQ_GEN_164 Logs shall include the use of any privileged passwords.
REQ_GEN_165 Logs shall include the use of any privileged utilities.
REQ_GEN_166 Logs shall include automatically generated data necessary to assess the
application performance.
REQ_GEN_167 The frequency of logs generation shall be mutually agreed upon, in order to be
consistent with the ability to trace appropriate actions of the application.
REQ_GEN_168 Logs shall include all log-ons and log-outs as well as all attempts (whether
successful or not) to log-on
REQ_GEN_169 Logs shall have appropriate mutually agreed upon retention period.
REQ_GEN_170 The log generating software shall prohibit amendment of log details and
disabling of the recording of events.
REQ_GEN_171 The log generating software shall include review of log-on patterns to determine
potentially abnormal system use.
REQ_GEN_172 Files of logged events shall be protected from amendment or deletion.
REQ_GEN_173 Logging process shall always be enabled except when explicitly disabled by a
supervisor role. Controls shall be in place to prevent the logging process from
being disabled.
Security Requirements
REQ_GEN_174 Application shall prevent unauthorized users from accessing the system.
REQ_GEN_175 Application shall make data available to the authorized users in an expedient
and secure environment
REQ_GEN_176 Application shall provide access monitoring to compile and report security
“Design, Development and Implementation of Store Management System (SMS)”
Page 189 of 198
violations and attempted security violations
REQ_GEN_177 Application shall have the thorough capability to a log record of an unauthorized
attempt.
REQ_GEN_178 Application shall provide physical and remote access control to Application
systems.
REQ_GEN_179 Application shall evaluate the following security measures such as encryption
and firewalls, which shall provide a model for the Application design.
REQ_GEN_180 Application shall implement controls to ensure the privacy of information,
individuals, and corporations are not compromised.
REQ_GEN_181 Application shall use audit controls, electronic signatures, data encryption and
other methods to assure the authenticity of transaction and other relevant data.
REQ_GEN_182 Application database management security services shall include access control
(e.g., Discretionary Access Control (DAC), Mandatory Access Control (MAC),
content-dependent and context dependent access control), individual user
identification and authentication (I&A), data confidentiality, data integrity (e.g.,
entity integrity, referential integrity, and label integrity), security audit, object
reuse, availability of service and data, and other security services.
REQ_GEN_183 Application shall implement controls to ensure the authenticity of data is
preserved.
REQ_GEN_184 Application shall comply with the Application Security Plan and security
guidelines of each of the stakeholder involved.
REQ_GEN_185 Application shall adhere to guidelines for physical, personnel, computer,
communications, and internal data security.
REQ_GEN_186 Application shall be foreseen of user registration system allowing: distinguishing
different user roles; authorization of users;
REQ_GEN_187 Application shall be foreseen with an access control policy functionality allowing
access of users in different roles to different functionalities of Application. At
least the following roles shall be introduced for Application: Supervisor,
Operator, System support, User
REQ_GEN_188 Only registered users shall be allowed to log-in to the application.
REQ_GEN_189 Registered users shall be allowed to log-on only to those Application functions
“Design, Development and Implementation of Store Management System (SMS)”
Page 190 of 198
which they are authorized to access and use.
REQ_GEN_190 Registration of users in their respective roles shall be valid only for a limited
period of time, where after their authorization shall be re-confirmed and
prolonged.
REQ_GEN_191 Additional access controls shall be considered for log-on to Application (such as
physical tokens)
REQ_GEN_192 The logon processes shall display only the minimum amount of information to
assist users.
REQ_GEN_193 The logon processes shall prohibit the display of help screens.
REQ_GEN_194 The logon processes shall minimize the opportunities for unauthorized
connections to Application.
REQ_GEN_195 The logon processes shall prohibit the display of the Application system or the
application details until the process has been successfully completed.
REQ_GEN_196 The logon process shall deny access if either the username or password is
invalid without identifying the specific erroneous element.
REQ_GEN_197 The logon process shall allow only a fixed number of logon attempts before
disabling the terminal.
REQ_GEN_198 If access is denied following repeated unsuccessful logon attempts, this shall be
treated by the application as a security incident and handled accordingly.
REQ_GEN_199 The logoff procedure shall clear any screen displays prior to terminating the
application.
REQ_GEN_200 Application shall disallow simultaneous logon by the same user.
REQ_GEN_201 The password management system shall require the enforcement of a minimum
password length.
REQ_GEN_202 The password management system shall require the use of quality (i.e. difficult
to guess) passwords.
REQ_GEN_203 The password management system shall require the enforcement of a
password change after a TBD period.
REQ_GEN_204 The password management system shall include non-display of the password
when being entered
“Design, Development and Implementation of Store Management System (SMS)”
Page 191 of 198
REQ_GEN_205 The password management system shall require the storage of passwords in
encrypted form.
REQ_GEN_206 For all security incidents alarm functionality shall be implemented, which
immediately informs the supervisor role of these incidents.
REQ_GEN_207 Application shall treat the following events as security incidents: unsuccessful
log-on, intrusion detection, malfunctioning of encryption facility
Legal and Regulatory Requirements
REQ_GEN_208 Application shall provide flexibility to easily modify the system to handle
changes in trade laws, regulations, and license & permit requirements.
REQ_GEN_209 Application shall have the capability to search and analyse payment
transactions for enforcement purposes
Interface Requirements
REQ_GEN_210 Seam less integration / interfacing with existing/proposed applications
Testing Requirements
REQ_GEN_211 Standard procedures shall be established to test compliance and conformance
of equipment, to be used to facilitate IPF to IPF Standards and to certify
interoperability and portability of information systems coupled to applications.
REQ_GEN_212 All corrections to address discrepancies shall be validated through formal
regression test before insertion into the operational systems
REQ_GEN_213 Application shall support the revalidation of performance capabilities whenever
an element(s) upgrade/enhancement is made to IPF, which may cause a
change in performance.
REQ_GEN_214 All new application functionality shall be validated through a formal extensive
testing before insertion into the operational systems.
REQ_GEN_215 Application shall support operations and testing concurrently.
REQ_GEN_216 Application shall provide tools and metrics to support testing, system
performance monitoring, fault isolation, verification and validation of the end-to-
end system
Common Technical Requirements
REQ_GEN_217 The system shall have ability to customize user menus and screens based on
“Design, Development and Implementation of Store Management System (SMS)”
Page 192 of 198
user access authority.
REQ_GEN_218 The system shall be able to archive transactional database records to prevent
long term speed concerns. The solution must also feature functionality for
efficient retrieval of archived data.
REQ_GEN_219 The solution shall be capable of generating event notifications and interfacing
with E-mail system and must support e-mail triggers as part of the solution’s
workflow.
REQ_GEN_220 The system shall provide a report-writing tool, which can be used to generate
customized reports at any level.
Audit Trail
The system shall be able to automatically record an audit trail of events under
the control of the system, storing information about:
REQ_GEN_221 Action which is being carried out
REQ_GEN_222 The object(s) to which the action is being applied
REQ_GEN_223 The user carrying out the action
REQ_GEN_224 The date and time of the event
REQ_GEN_225 The system shall track and record information about events in the audit trail
without manual intervention, once the audit trail facility has been activated
REQ_GEN_226 The system shall ensure that audit trail data cannot be modified, or any part of
the data be deleted by any user, including an Administrator.
REQ_GEN_227 The system allow the extent of audit trail tracking and recording to be user-
configurable, so that an Administrator can select the events for which
information is automatically recorded
REQ_GEN_228 The system shall ensure that the selection for audit trail tracking, and all later
changes to it, are also recorded in the audit trail
REQ_GEN_229 The system shall ensure that audit trail data is available for inspection on
request, so that a specific event can be identified and all related data made
accessible, and that this can be achieved by authorized external personnel e.g.
auditors, who have little or no familiarity with the system
User Interface
“Design, Development and Implementation of Store Management System (SMS)”
Page 193 of 198
REQ_GEN_230 System shall perform data validation checks on the input such as data formats,
completeness of the form in terms of mandatory fields, checking for file type and
size of files uploaded, etc. In case of any validation failure, the system shall
display an appropriate error message.
Enquiries and Grievance Redressal Services
REQ_GEN_231 System shall be able to provide a list of "Frequently Asked Questions" to the
user
REQ_GEN_232 Allowing employers to log enquiries and grievances through an online web
application / Allow help desk personnel to take grievances
REQ_GEN_233 System shall be able to capture enquiries and grievances through an electronic
form.
REQ_GEN_234 System shall be able to associate an enquiry or a grievance with a past request
similar request
REQ_GEN_235 System shall generate a unique case number for the grievance which can be
used for tracking purposes on successful submission of the form through the
web portal
REQ_GEN_236 Should be based on open standards and have API support for data import and
export
REQ_GEN_237 The system shall provide support to invocation of external programs to perform
activities of a process like launching core application screen for data entry
REQ_GEN_238 The system shall support integration based on messaging and shall support
distributed systems interface
REQ_GEN_239 The system shall provide the option of invoking its integration components
(adapters) either synchronously and asynchronously
REQ_GEN_240 The system shall allow users to define adapters for the system
REQ_GEN_241 The system shall support integration based on standards such as XML/those
laid down by Stakeholders
REQ_GEN_242 The system shall support message based collaboration based on protocols such
as HTTP, FTP and SMTP
REQ_GEN_243 The system shall provide fully functional APIs for integration
REQ_GEN_244 The system shall provide presentation level API to customize user task
“Design, Development and Implementation of Store Management System (SMS)”
Page 194 of 198
interfaces
REQ_GEN_245 The system shall support web services
REQ_GEN_246 The system shall enable the work items to access the web methods of a
remotely deployed web service
REQ_GEN_247 The system shall allow support of both synchronous and asynchronous modes
to invoke web methods
REQ_GEN_248 The system shall support web based interfaces
REQ_GEN_249 The system shall have the ability to integrate through messaging
REQ_GEN_250 The system may have its own front end or launch any application
REQ_GEN_251 The system should have the capability to interface with industry standard web
services through simple interfaces
“Design, Development and Implementation of Store Management System (SMS)”
Page 195 of 198
ANNEXURE 18: TECHNICAL SPECIFICATION (HARDWARE) Note: All the specifications below are minimum specifications and higher specifications shall be
used wherever necessary/ required. Deviation on higher side shall only be considered and no
extra weightage shall be awarded for such deviations.
Item No. 1 – Desktop
Particular/features
Description of Requirement Specification proposed by the
bidder
Compliance (Yes/No)
Processor Intel Core i3-4130 (3.40 GHz) or higher Chipset Intel Q85 or higher on original Intel/ OEM
motherboard
Memory 4GB @1600 MHz DDR3 RAM (Expandable up to minimum 16GB)
HDD 500 GB 7200 RPM Serial ATA HDD or higher with SMART (Self-Monitoring, Analysis and Reporting Technology) functionality
Monitor 47 cm (18.5 inch) TFT Digital Colour Monitor
Bays 3 Nos. or above Keyboard Standard OEM Keyboard (mechanical) Mouse OEM Two button Optical Scroll Mouse with
mouse pad
Optical Device DVD RW (Min. 16x) or higher Cabinet Mini Tower / Micro Tower / SFF Ports Min. 6 USB Ports (with at least 2 in
front), 1 Serial audio port for microphone and headphone in front
Network Features
On board 10/100/1000 Ethernet network port
Multimedia Integrated Audio and Graphic Controller Power Management
ACPI (Advanced Configuration and Power Management Interface)
Operating System
Genuine MS-Windows 8 Professional 64 Bit with Recovery and Drivers on CD/DVD and on HDD
Anti-Virus Trend-micro/Symantec/ Quickheal/MacAfee/Kaspersky/Bit defender/K7/Sophos Internet Security (Latest Version) with 3 Year subscription
Office Suite Open Office Dust Cover Quality Dust Cover for Monitor, CPU and
Keyboard
Warranty 3 years on-site comprehensive warranty
“Design, Development and Implementation of Store Management System (SMS)”
Page 196 of 198
Item No. 2 - 800 VA UPS
Particular/features Description of Requirement Specification Proposed by the bidder
Compliance (Yes/No)
Capacity 800 VA
No. of Sockets Min. 3 sockets for connecting devices
Battery Make ISO 9001 and ISO 14001 certified
Input Voltage 160 V – 260 V, 50 Hz +/‐ 3 Hz
Output 220 V +-5%, 50 Hz +/‐ 3 Hz
Battery Type Sealed Maintenance Free
Battery 2 X(12V, 7AH) or higher
Battery Backup 12 V x 2 no. x 9 AH at least 216 VAH (i.e. housing of the batteries should be within UPS)
Cables With necessary cable and plug
Warranty 3 years on-site comprehensive warranty
“Design, Development and Implementation of Store Management System (SMS)”
Page 197 of 198
Item No. 3 – Multi Function Printer
Particular/feature Description of Requirement Specification Proposed by the bidder
Compliance (Yes/No)
Print Speed 25 ppm (A4) or higher Functions Print, copy, scan, fax Duty Cycle (monthly) 15000 pages or higher
Print Resolution 1200*1200 dpi or higher Print technology Laser Duplex Automatic Scan type/technology Flatbed, ADF/Contact image sensor
Scan speed 15 ppm Scan resolution 1200*1200 dpi Copy resolution 600*600 dpi Fax resolution 300*300 dpi Fax features All standard features Network Enabled Yes, 10/100 Mbps Connectivity Hi-Speed USB 2.0 Processor speed 600 MHz or higher Memory 256 MB or higher Media Size supported A4, A5
Energy Star yes
Drivers Windows 7/8 Operating System drivers to be included
Cables/ Accessories All the required cables, accessories
Warranty 3 years onsite warranty
“Design, Development and Implementation of Store Management System (SMS)”
Page 198 of 198
Item No. 4 – Biometric Device
Particular/features Description of Requirement Specification proposed by the bidder
Compliance (Yes/No)
Cable Length Min 1800 mm
Certification FCC class A or equivalent
Sensor Optical
Image Resolution Min. 500 DPI
Image Size 480X320 pixel
Image Grayscale 8 bit, 256 level
Effective Capture Area
>25mmX25mm
Light Source Red LED
Lifetime (typical) Min 50,000 hours
Operating Voltage 5 V from USB port
Supporting Operating System
Windows 7 / Vista / XP / 2000, 2003/ Android
Interface USB 2.0
Weight Max 0.35 Kg
Operating Temperature
0-50 degree Celsius
Humidity 10-90% condensing
Software API Compliant with UIDAI Device Capture API Specification
Communication Speed (Max)
12 Mbps
Verification Time Less than 1 sec
Auto On function Yes
Hardened Contact Area
Yes
Warranty 3 year on-site warranty
Note: All the supplied Hardware / Software should be Interoperable, IPv6 ready and in
compliance with the policies/ guidelines issued by DeITY, GoI in this regard. Also, the bidder is
to quote/ propose only one make/ model against the respective item.
All the equipment is to be supplied, hosted and installed at locations mentioned in Annexure-16.
The selected bidder shall have to mount the equipment with required accessories/ cables/
screws etc.
Recommended