Erprfp JPDCL

Request for Proposal for Selection of System Integrator
(ERPSI) to Design, Develop, Implement and Maintain

Enterprise Resource Planning (ERP) Solution on Cloud
Issued By:
Jammu Power Distribution Corporation Limited (JPDCL)
Issue Date: 19/09/2023

e-NIT Number: 07 of 2023-24
Request for Proposal for Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain
JPDCL
Proprietary Notice
This document contains confidential information of JPDCL which is provided for the sole purpose of
permitting the recipient to evaluate the proposal submitted herewith. In consideration of receipt of
this document, the recipient agrees to maintain such information in confidence and to not reproduce
or otherwise disclose this information to any person outside the group directly responsible for
evaluation of its contents, except that there is no obligation to maintain the confidentiality of any
information which was known to the recipient prior to receipt of such information from JPDCL or
becomes publicly known through no fault of recipient, from JPDCL or is received without obligation of
confidentiality from a third party owing no obligation of confidentiality to JPDCL.
Page 2 of 390
JPDCL
Disclaimer
Jammu Power Distribution Corporation Limited (JPDCL) intend to implement a Cloud based Enterprise
Resource Planning Solution. This document has been prepared on the basis of available information
in JPDCL and other publicly available documents which JPDCL believes to be reliable. The sole objective
of this document (the Request for Proposal or the RFP) is to solicit Commercial and Technical Bids
from interested parties for taking part in the Tendering process leading to Selection of Master System
Integrator for Implementation & Maintenance of Cloud based Enterprise Resource Planning Solution.
While this document has been prepared in good faith, no representation or warranty, express or
implied, is or shall be made, and no responsibility or liability shall be accepted by JPDCL or any of their
employees, consultants, advisors or agents as to or in relation to the accuracy or completeness of this
document and any liability thereof is hereby expressly disclaimed. Interested Parties may carry out
their own study/analysis/investigation as required before submitting their Commercial and Technical
Bids.
This document does not constitute an offer or invitation, or solicitation of an offer, nor does this
document or anything contained herein, shall form a basis of any agreement or commitment
whatsoever.
Some of the activities listed to be carried out by JPDCL subsequent to the receipt of the responses are
indicative only. JPDCL has the right to continue with these activities, modify the sequence of activities,
add new activities or remove some of the activities, as dictated by the best interests of JPDCL.
Page 3 of 390
JPDCL
Summary
PART I – BIDDING PROCEDURES AND REQUIREMENTS
Section 1: Request for Proposals (RFP) Notice
This Section includes Request for Proposals.
Section 2: Eligibility and Qualification Requirements
This Section contains information regarding specific eligibility and qualification

requirements applicable for prospective bidders to be considered for further evaluation of their
proposal.
Section 3: Instructions to Bidders and Bid Data Sheet
This Section consists of two parts: ―Instructions to Bidders and ―Bid Data Sheet contains
information specific to selection and corresponds to the clauses in ―Instructions to Bidders that call
for selection-specific information. This Section provides information to help prospective bidders
prepare their proposals. Information is also provided on submission, opening and evaluation of
proposals, selection of successful bidder and award of contract.
Section 4: Bidding Forms – Technical Proposal
This Section includes the forms for Technical Proposal that are to be completed by the prospective
bidders and submitted in accordance with the requirements of Section 3.
Section 5: Bidding Forms - Financial Proposal
This Section includes the financial forms that are to be completed by the prospective bidders,
including the bidder’s costing and pricing, which are to be submitted in accordance with the
requirements of Section 3.
Section 6: Project Requirements
This Section describes Scope of Work, System Requirement, Specifications, Quality Requirements,
Service Level Agreement (SLA), Standards, Activities and Tasks, Plans, Deliverables, Documentation,
and other requirements/ details related to and/or connected with the Project.
PART II – CONTRACT FORM AND CONDITIONS OF CONTRACT
Section 7: Contract Form and Conditions of Contract
This Section includes standard contract form. It includes General Conditions of Contract (GCC) and
Special Conditions of Contract (SCC). The SCC include clauses specific to this contract to supplement
the General Conditions.
PART III – CONTRACT RELATED FORMS
Section 8: Contract Related Forms
This Section includes the form used to notify Award of the Contract to the successful bidder and the
form for Performance Security to be furnished by the bidder.
Page 4 of 390
JPDCL
Glossary of Terms
Abbreviation Description
BG Bank Guarantee
BoM Bill of Material
BoQ Bill of Quantity
CCN Change Control Note
CNS Change Note on Scope of Work
COTS Commercial off-the-Shelf
CSP Cloud Service Provider
CV Curriculum Vitae
DC Data Centre
DMZ Demilitarized Zone
DoB Date of Birth
DoJ Date of Joining
DR Disaster Recovery Centre
ESS Employee Self Service
EMD Earnest Money Deposit
EQI Equated Quarterly Installment
FI Financial Institution
FRS Functional Requirements Specification
GCC General Conditions of the Contract
Govt. of
Government of India
India
HoD Head of Department
HR&A Human Resource and Administration
IT Information Technology
JPDCL Jammu Power Distribution Corporation Limited
LoI Letter of Intent
LoA Letter of Award
MSA Master Services Agreement
NOC No Objection Certificate
OEM Original Equipment Manufacturer
PBG Performance Bank Guarantee
RFP Request for Proposal
RPO Recovery Point Objective
RTM Requirement Traceability Matrix
RTO Recovery Time Objective
SDD Solution Design Document
SRS Software Requirements Specification
Page 5 of 390
JPDCL
Contents
Proprietary Notice................................................................................................................................... 2
Disclaimer................................................................................................................................................ 3
Summary ................................................................................................................................................. 4
Glossary of Terms.................................................................................................................................... 5
Introduction ............................................................................................................................................ 8
PART I .................................................................................................................................................... 11
Section 1. Request for Proposal Notice ........................................................................................................ 12
Section 2. Eligibility and Qualification Requirements .................................................................................. 15
Section 3. Instructions to Bidders and Bid Data Sheet ................................................................................. 43
Section 4. Bidding Forms- Technical Proposal .............................................................................................. 71
Section 5. Bidding Forms - Financial Proposal ............................................................................................ 111
Section 6. ERP System Requirements and Service Level Agreement ......................................................... 125
1. Current State of the System ................................................................................................................. 125
2. Overview of the envisaged ERP System ............................................................................................... 131
3. Capacity Estimates ............................................................................................................................... 136
4. Overview of the ERPSI Scope of Work .................................................................................................. 139
5. Design, configuration / customization / enhancement of the envisaged Enterprise Resource Planning
(ERP) System .................................................................................................................................................. 147
6. Acceptance Testing .............................................................................................................................. 159
7. Data Migration ..................................................................................................................................... 167
8. Training and Capacity Building ............................................................................................................. 174
9. Set-up and operationalization of IT Helpdesk for the envisaged ERP System ...................................... 180
10. Implementation of cybersecurity considerations for design, configuration / customization /
enhancement of the envisaged Enterprise Resource Planning (ERP) System ................................................ 184
11. Operations and Maintenance for 4 years ............................................................................................. 196
12. Support pertaining to cybersecurity considerations during Operations and Maintenance ................. 203
13. Project Documentation ........................................................................................................................ 208
14. Monitoring Performance and Service Levels ........................................................................................ 208
15. Usage Reporting Management ............................................................................................................ 209
16. Payment Terms, Deliverables and Timelines ....................................................................................... 210
17. Service Level Agreement ...................................................................................................................... 218
18. Governance Structure .......................................................................................................................... 234
19. Manpower requirements ..................................................................................................................... 243
Annexure – III : Functional Requirement Specification .................................................................................. 245
PART II ................................................................................................................................................. 363
Section 7. Conditions of Contract ............................................................................................................... 364
Page 6 of 390
JPDCL
PART III ................................................................................................................................................ 386

Section 8. Contract Related Form .............................................................................................................. 387
Page 7 of 390
JPDCL
Introduction
Background of the Project
A well-functioning electricity infrastructure is essential for the success of a modern economy. 24x7
availability of reliable, quality and affordable power is key to economic development of the country.
Power Sector has witnessed tremendous growth over the past five years in generation, transmission
and universal access to electricity. India is surplus in power generation today. The continued progress
in inter-state and intra-state transmission network has removed transmission bottlenecks and created
sufficient transmission capacity to transmit electricity generated from one region to another.
In the Distribution Sector, Government of India has been assisting the States / Distribution Companies
(DISCOMs) through various schemes since 2014, namely Deen Dayal Upadhyaya Gram Jyoti Yojana
(DDUGJY); Pradhan Mantri Sahaj Bijli Har Ghar Yojana (SAUBHAGYA); and Integrated Power
Development Scheme (IPDS). The Distribution system has been strengthened under DDUGJY and IPDS
in rural and urban areas respectively.
Steps have also been taken for automation and use of Information Technology (IT) in Distribution
Sector under IPDS and R-APDRP which includes the establishment of Data Centres, GIS mapping of
consumers, Asset Mapping, Online energy auditing & accounting, Consumer care centres, AMI meters
on feeders & Distribution Transformers, provision of Smart Metering to reduce losses etc. in urban
areas.
It is with this objective that the Government of India’s commitment for providing 24x7 uninterrupted,
quality, reliable and affordable power supply, that the Revamped Reforms Based and Results Linked
Distribution Sector Scheme (RDSS) has been formulated by Ministry of Power to improve the
operational efficiencies and financial sustainability for strengthening of supply infrastructure and
achieving basic minimum benchmarks in reforms.
Another important step is Cyber security of critical infrastructure in power sector organizations has
become a matter of fundamental priority with respect to national defence strategy. As per the
directives of Ministry of Power, Information Sharing and Analysis Centre-Power (ISAC-Power) a central
coordinating agency under Central Electricity Authority (CEA) to share and analyse various cyber
security incidents in the Power Sector was conceived. The ISAC-Power is the common platform for the
four sectoral CERTs under Ministry of Power. The ISAC-Power focuses to be the Central Information
Resource pooling and sharing platform. The spread of Internet and its indispensability brings with it
the risk of loss, damage and misuse of valuable information which can be of disastrous consequences
to individuals, businesses and Governments. Increased interconnection and integration render the
grids vulnerable to cyber threats, putting stored data and computers at great risk. With sufficient cyber
security measures, policies and framework in place, a utility power system can be made more efficient,
reliable and secure, as failure to address these problems will hinder the modernization of the existing
power system. Cyber security and data privacy are some of the key challenges for Power utilities, as
establishment of digital electricity infrastructure entails the challenge of communication security and
data management. Digital network and systems are highly prone to malicious attacks from hackers
which can lead to mis-utilization of consumers’ data, making cyber security the key issue to be
addressed.
Page 8 of 390
Request for Proposal for Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain Enterprise Resource Planning (ERP) Solution on Cloud JPDCL
Organisation Structure of JPDCL
Page 9 of 390
JPDCL
About the Project

JPDCL intends to implement a SaaS-based Enterprise Resource Planning (ERP) solution for an
integrated data collection, analysis and sharing platform to address the key business challenges and
share the data across various functional areas which can make its business processes efficient, more
robust, and reliable to meet the present and future challenges.
The objective of the “Enterprise Resource Planning System Integrator (ERPSI)” shall be to implement
an integrated Enterprise Resource Planning (ERP) System, integrating the business processes across
the geographical areas of JPDCL which include Circles, Towns, Sub-Divisions and other Administrative
Offices, etc.
Implementation of ERP shall be Software as a Service (SaaS)-based ERP product on private cloud
edition (including cloud infrastructure, support, and technical services) for a period of four (04) years.
Post the end of the subscription, the same can be extended for another tenure as per mutual
agreement between both the parties. The ERPSI should carefully analyze the project requirements
related to SaaS-based solution to be delivered, IT Infrastructure required at various JPDCL offices, and
the SLA criteria while deriving the right SaaS-based solution.
Among the various functional modules to be implemented are:
SR. NO. FUNCTIONAL MODULE LEGEND

1 Finance and Accounts F&A
2 Human Resource Management, Payroll and ESS HRM
3 Inventory and Stock (Material Management) MM
4 Purchasing / Contract Management PROC
5 Project Management PS
6 Asset Lifecycle Management ALM
7 Supply Operations / Online Feeder Management SUPOPS
8 Energy Management EM
9 Operations Support OPSUP
10 Consumer Service Management and Grievance Redressal CSMGR
11 Governance, Risk and Compliance GRC
12 Document Management System DMS
Page 10 of 390
JPDCL
PART I
BIDDING PROCEDURES AND REQUIREMENTS
Page 11 of 390
JPDCL
Section 1. Request for Proposal Notice
PROCUREMENT NOTICE
Contract Title: “Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain
Enterprise Resource Planning (ERP) Solution on Cloud ‘‘
Request for Proposal (RFP)/ Tender Number: 07 of 2023-2024
Issued on: 19/09/2023
1. Jammu Power Distribution Corporation Limited (JPDCL) (hereinafter also referred to as Utility ‘)
invites online Proposals for ― Selection of System Integrator (ERPSI) to Design, Develop,
Implement and Maintain Enterprise Resource Planning (ERP) Solution on Cloud. Bidders are
advised to note the clauses on Eligibility and Qualification Requirements in Section-2 and
Evaluation Criteria of the RFP Document for evaluation of Proposals.
2. Bidding for selection of System Integrator will be conducted through Domestic competitive
bidding on turnkey basis.
3. The RFP Document is available online www.jktenders.gov.in from [19/09/23] to 19/10/2023] on
payment of cost of document (Tender Fee) as indicated in the TABLE below. The prospective
Bidders would be responsible for downloading the RFP Document and ensuring that any addenda/
corrigendum/ amendment/ clarification thereto available on the website is also downloaded and
incorporated.
4. The bidding shall be conducted under Single Stage Two-Envelope Quality and Cost based Selection
(QCBS) method Bidding process with e-Procurement as specified in Section 3.
5. Under the Single Stage Two-Envelope Bidding process, the Bidder shall not quote, disclose, or
submit its price in the Eligibility Criteria and Technical Proposal (First Envelope) or in any other
manner, whatsoever, except as part of the Financial Proposal (Second Envelope). In case of any
non-compliance in this regard, the Proposal shall be out-rightly / summarily rejected.
6. An incomplete and/or ambiguous and/or conditional Proposal and/or Proposal submitted late is
liable to be ignored/ summarily rejected.
7. Proposal must be submitted online through the e-Tendering process specified in Section 3. Any
Proposal or modifications to Proposal received outside the e-Procurement system will not be
considered, unless otherwise specified in Section 3. Utility shall not be held liable for any delays
due to e-Procurement/ e-Tendering system failure beyond its control. Even though the system will
attempt to notify the bidders of any bid updates, Utility shall not be liable for any information not
received by the bidder. It is the bidders ‘responsibility to verify the website for the latest
information related to this RFP.
8. The Bidder should provide detailed information on any litigation or arbitration arising out of its
completed contracts or contract under execution during the last five years with Jammu Power
Distribution Corporation Limited (JPDCL). A history of awards involving litigations against the
Bidder, or any part or JV may result in rejection of bid. The Bidder should furnish the self-
declaration stating the above and upload the same along with the other documents in the relevant
field in the e-procurement portal, failing which the offer is liable to be rejected.
Page 12 of 390
JPDCL
9. If the information furnished by the Bidder found to be false at any stage of tendering / execution,
then the Jammu Power Distribution Corporation Limited (JPDCL), at its discretion may act against
such Bidder. If false information is found at the Tendering stage Jammu Power Distribution
Corporation Limited (JPDCL) may forfeit the EMD paid, disqualify the offer of such Bidder, blacklist
the Firm etc. If false information is found at execution stage, then Jammu Power Distribution
Corporation Limited (JPDCL) may cancel the works awarded, forfeit the Bank Guarantee furnished
against the performance of the contract, blacklist the Firm, besides initiating action for recovery
of excess money paid by Jammu Power Distribution Corporation Limited (JPDCL), if any after
getting the works executed from other contractors, levy liquidated damages etc.
10. Important dates, amounts and other details pertaining to this RFP Notice including submission and
opening of proposal, cost of documents/ Tender Fee, address for communication, etc., are given
in the TABLE below.
11. If Utility office happens to be closed on the specified date of opening of the Proposals, the
Proposals/ bids will be opened on the next working day at the same time and venue/online joining
link or as may be notified by Utility.
12. Other details can be seen in the RFP document.
Important Dates, Amounts and Other Details
Tender/RFP Reference No. and Date 07 of 2023-2024 19/09/2023

Place of availability of Tender Documents (RFPs) www.jktenders.gov.in
Place of submission of Bids www.jktenders.gov.in
Tender Document (RFP) Request for Proposal Document
Tender Type (Open/Limited/EOI/Auction/Single) Open
Is Multi Currency Allowed No (Only Indian Rupees)
One time Procurement Yes
Bid Validity days (180/120/90/60/30) 180 days
Location (Work / Services / Items / As per RFP) As per RFP
Rupees Twenty five thousand only (INR 25,000/
Non-refundable) in the shape of Demand Draft in
Cost of Tender Document favor of "Executive Engineer, IT & C Div-JPDCL,
Gladni Gid Station Complex, Narwal, Jammu-
180006 (J&K)”
Rupees Forty-Four Lacs only (INR 44,00,000/-)
To be furnished by the lead bidder by submitting
in the shape of CRD/FDR, BG or Demand Draft
from any Scheduled Commercial Bank/
Earnest Money Deposit (EMD)
Nationalized Bank drawn in favor of “Chief
Accounts Officer, O/o the Managing Director,
Jammu Power Distribution Corporation Limited
(JPDCL)”, payable at Jammu and valid for a period
Page 13 of 390
JPDCL
of minimum 180 days. Account details for the

purpose of EMD and Performance Guarantee:
Bank Name: J&K bank, Branch Rail Head Jammu
Beneficiary Name: Managing Director, Jammu
Power Distribution Corporation Limited (JPDCL)
IFSC Code: JAKA0ERAILH
Account No: 0022040510000001
E-mail Address to send Pre-bid Queries xenitjpdcl@gmail.com
Two stage bidding in Two Cover
1. Cover – I
Nature of Bid Process • Eligibility Criteria and Technical Bid
2. Cover – II
• Commercial Bid
Method of Selection Quality Cost based Selection (70:30)
Download Date 20/09/2023 at 10:00 am
Clarification start date 21/09/2023 at 10:00 am
Last Date for Submission of clarifications by
18/10/2023 at 04:00 pm
bidders
Date of Pre-Bid Meeting 30/09/2023 2:00 pm
Executive Engineer, IT&C Division, Jammu Power
Distribution Corporation Limited (JPDCL), Gladni
Place for Pre-bid Meeting
Grid Station Complex, Narwal, Jammu-180006
(J&K) through VC
Last date and time for Submission of Bids 19/10/2023 3:00 pm
Last date and time for Submission of Tender fee 18/10/2023 4:30 pm
(hard copy), Integrity Pact, Power of Attorney
Online Opening of Technical Bids 20/10/2023 2:00 pm
Shall be separately communicated to the
Opening of Commercial Bids
technically responsive bidders
Executive Engineer-IT & C Division, Gladni Grid
Address for Communication Station Complex, Narwal, Jammu-180006 (J&K)
Email: xenitjpdcl@gmail.com
Page 14 of 390
JPDCL
Section 2. Eligibility and Qualification Requirements

1. The Bid can be submitted by a Sole Bidder as an individual entity or a Consortium of
firms/companies (specific requirements for Consortium are given under Clause 5 below) who are
eligible to participate in tenders for public procurement in India in accordance with Applicable
Laws including any amendments or modifications to the same from time to time.
2. If at any stage of the bidding, any order/ ruling is found to have been passed in the last 1 (one)
year preceding the Bid submission deadline by a competent Court of Law or any appropriate
Commission or any Arbitral Tribunal against the Sole Bidder/ Lead Bidder/ any Consortium
Members or its Affiliates for breach of any Contract awarded by any Government
agency/department, then Bids from such Bidders shall be liable to be rejected. All Bidders shall
confirm in accordance to Form 7 given in Section 4 that no such order(s)/ ruling(s) have been
passed by a competent Court of Law or an appropriate Commission against it or its Affiliates. In
case of any such order/ ruling, it is the duty of the Bidder to inform Utility for the same during the
Bid submission.
3. Technically qualified Bidders shall continue to maintain compliance with the Eligibility and
Qualification Requirements specified herein. Failure to comply with the aforesaid requirements
shall make the Bid from such Bidders liable for rejection at any stage of the bidding process.
4. To be eligible to bid, the Bidders must ensure compliance to the following, failing which they shall
not be eligible:
Restrictions under Rule 144 (xi) of GFR 2017: Restrictions on procurement from a bidder of a
country which shares a land border with India
a) Any bidder from a country which shares a land border with India will be eligible to bid only if
the bidder is registered with the Competent Authority.
b) "Bidder" (Seller / Service Provider) means any person or firm or company including any
member of a consortium or joint venture (that is an association of several persons, or firms or
companies), every artificial juridical person not falling in any of the descriptions of bidders
stated hereinbefore, including any agency branch or office controlled by such person,
participating in a procurement process.
c) "Bidder from a country which shares a land border with India" for the purpose of this Order/
Rule means: -
a. An entity incorporated, established, or registered in such a country; or
b. A subsidiary of an entity incorporated, established, or registered in such country; or
c. An entity substantially controlled through entities incorporated, established
registered in such a country; or
d. An entity whose beneficial owner is situated in such a country; or
e. An Indian (or other) agent of such an entity; or
f. A natural person who is a citizen of such a country; or
g. A consortium or joint venture where any member of the consortium or venture falls
under any of the above
d) The bidders are required to ensure compliance to the directions issued by Ministry of Power,
Government of India vide OM No: A-1/2021-FSC-Part (5) dated November 16, 2021 pertaining
to Public Procurement (Preference to Make in India) to provide for purchase preference
(Linked with local content) in respect of Power Sector and other OM‘s/directions/circulars
issued by appropriate Ministries‘ in this regard and subsequent amendments thereof.
Page 15 of 390
JPDCL
e) The beneficial owner for the purpose of (III) above will be as under:
1. In case of a company or Limited Liability Partnership, the beneficial owner, or the natural
person(s), who, whether acting alone or together, or through one or more juridical person, has a
controlling ownership interest or who exercise control through other means. Explanation
1.1. An entity incorporated, established, or registered in such a country; or "Controlling
ownership interest" means ownership of or entitlement to more than twenty-five percent of
shares or capital or profits of the company;
1.2. "Control" shall include the right to appoint majority of the directors to control the
management or policy decisions including by virtue of the shareholding or management
rights or shareholders agreements or voting agreements;
2. In case of a partnership firm, the beneficial owner is the natural person(s), who, whether acting
alone or together, or through one or more juridical person, has ownership of entitlement
to more than fifteen percent of capital or profits of the partnership;
3. In case of an unincorporated association or body of individuals, the beneficial owner is the natural
person(s), who, whether acting alone or together, through one or more juridical person, has
ownership of or entitlement to more than fifteen percent of the property or capital or profits of
such association or body of individuals;
4. Where no natural person is identified under (1) or (2) or (3) above, beneficial owner is the relevant
natural person who holds the position of serving managing official;
5. In case of a trust, the identification of beneficial owner(s) shall include the identification of
the author of the trust, the trustee, the beneficiaries with fifteen percent or more interest in the
trust and any other natural person exercise ultimate effective control over the trust through a
chain of control or ownership;
f) An Agent is a person employed to do any act for another, or to represent another in dealings
with third person.
g) The successful bidder shall not be allowed to sub-contract works to any contractor from a
country which shares a land border with India unless such contractor registered with the
Competent Authority.
5. Eligibility Requirements for Consortium
5.1. Members of the Consortium shall enter into a binding Consortium Agreement, in the form
specified at Form 8 (Consortium Agreement) given in Section 4 of RFP Document, for the purpose
of submitting Bid. The Consortium Agreement, to be submitted along with the Bid, shall, inter
alia:
a) convey the intent to comply with the terms and conditions of the ERP System
Integrator (ERPSI) Contract in the event selected to undertake the Project; and
b) Clearly outline the proposed roles and responsibilities, if any, of each member.
5.2. Every Consortium Member shall provide consent to the Lead System Integrator (ERPSI- Lead) and
make itself aware of all the proceedings of the bidding process and Project implementation
through legally enforceable Consortium Agreement, power of attorneys, legal undertakings, etc.
(if applicable) entered amongst all members of that Bidding Consortium including but not
limited to those as prescribed in Form 8, Form 9 and Form 11 given in Section 4. In the absence
of duly executed formats, the Bid shall not be considered for evaluation and shall be rejected.
Page 16 of 390
JPDCL
5.3. The ERPSI-Lead shall be liable for the execution of the entire obligation in the ERP System
Integrator (ERPSI) Contract in accordance with the terms and conditions thereof. Only the Lead
Consortium Member, who must be a System Integrator (ERPSI), shall have the authority to
conduct all businesses for and on behalf of the Consortium
6. The Bidder, individual entity in case participating in the bidding as Sole Bidder, or as a Consortium
Member or as ERPSI-Lead in case participating in the bidding as Bidding Consortium, and its Sub-
Contractor(s) should not be blacklisted by any Govt. Organization or regulatory agencies or Govt.
Undertaking as on date of submission of the bid. Bidder should submit a self- undertaking signed
by its authorized signatories for the same as per the format prescribed in Form 18 given in Section
4
7. The ERPSI-Lead/ Sole Bidder shall submit the Bid after submitting the Tender Fees and Bid
Security as per the various terms, schedules and formats prescribed in this RFP. Further, The
ERPSI-Lead shall be the point of contact for the Consortium during the Bid process before award
of the Project to the ERPSI for the ERP implementation, and Utility shall communicate directly to
the contact person appointed through the Power of Attorney as per Form 10 given in Section 4
8. The Technically Evaluated Entity may be the Sole Bidder or the ERPSI-Lead/2nd Member of a
Consortium, as the case may be. The Consortium may consist of 2 members at the maximum
(i.e., the ERPSI-Lead and the ERPSI-2nd). The ERP OEM, CSP and DDA are all sub-contracted.
9. No further sub-contracting other than as mentioned in Pre-qualification and Technical
evaluation criteria will be allowed during any stage of the project implementation without prior
consent of JPDCL.
10. The consortium bid submitted without valid consortium agreement shall be treated as non-
responsive
11. The contract agreement shall be signed with all members of the Consortium. Members of the
Consortium shall be jointly and severally liable to JPDCL for the execution of the project in
accordance with the terms of the bid document and a statement of this effect shall be included
in the Consortium Agreement
12. Qualification Requirements

12.1. The technical and financial requirements of qualification for the System Integrator (ERPSI) are
as follows:
The prospective Bidder (referred as ERPSI-Lead) and the 2nd consortium member (in case of a
consortium; referred as ERPSI-2nd) shall have to enclose all documentary evidence in support
of pre-qualification as per formats given in the RFP document
Page 17 of 390
JPDCL
S.
Criteria Documentary Evidence*
No.
a. The Sole Bidder and Consortium
member (lead + 1 member), should be
registered under Companies Act,
1956/ 2013 or as amended (from time
to time) or an LLP registered under LLP
Act 2008/ Partnership firm under
Partnership Act 1932 i. Copy of Certification of Incorporation/
b. The Sole Bidder or the Lead Bidder in Registration Certificate
1.
case of a Consortium should have ii. PAN Card
completed at least 08 years of iii. GST Registration
Operations in India as on bid
submission date.
c. The Consortium member in case of a
Consortium should have completed at
least 06 years of Operations in India as
on bid submission date
Average Annual Turnover from IT/ ICT
(System Implementation) services during
i. Audited financial statements for the last
the last best three financial years out of
three FYs.
last five financial years. (FY 2017-18, FY
2018-19, FY 2019-20, 2020-21, 2021-22) AND
ii. Certificate from the Statutory Auditor/
i) In case of sole bidder
2. Chartered Accountant on turnover
The Sole Bidder should have an average
details for the last three FYs. The
annual turnover of INR 50 Crores
certificate must have UDIN issued by
ICAI. The certificate must have UDIN
ii) In case of a Consortium
issued by ICAI. Format is provided in
a) Lead Bidder - min. INR 40 crore
Form 15
b) Consortium Member - min. INR 10
crore
Page 18 of 390
JPDCL
S.
No.
The Sole Bidder or the Lead Bidder should
have an average annual turnover of INR 15
Crores from ERP solution (on Cloud/ on-
Premises) implementation* during the
i. Audited financial statements for the last
last best three financial years out of last
three FYs.
five financial years (FY 2017-18, FY 2018-
19, FY 2019-20, 2020-21, 2021-22) AND
ii. Certificate from the Statutory Auditor/
*Implementation Services includes
3. Chartered Accountant on turnover
Design, Develop, Supply, Installation,
details for the last three FYs. The
Operations and Maintenance of ERP
certificate must have UDIN issued by
solution (on Cloud/ On-premise)
ICAI. The certificate must have UDIN
(excluding IT Infrastructure, networking
issued by ICAI. Format is provided in
equipment, storage backup equipment,
Form 15
servers, auxiliary infrastructure such as
desktops, printers, UPS, scanners)
Certificate from the Statutory Auditor/

Positive Net-worth
Chartered Accountant on positive net-worth
for the last three (3) financial years. The
4. The Sole Bidder and Consortium member
certificate must have UDIN issued by ICAI. The
should have a positive net-worth in all the
certificate must have UDIN issued by ICAI.
last 3 FYs (FY 2019-20, 2020-21, 2021-22)
Format is provided in Format is provided in
Form 15
Page 19 of 390
JPDCL
S.
No.
Project Citation/ Case Studies as per format in
Form 12 followed by documentary evidences
as below:
Project Experience Work order/ Purchase Order/ Contract
Agreement
The bidder should have successfully
implemented 2 (two) ERP Projects of OR
the offered ERP OEM Product Contract clearly highlighting the Scope of
(Cloud/On-Premise) in India in last 10 Work, Bill of Material and value of the
year. Out of two (2) eligible ERP projects Contract/order
one must have been implemented in
OR
Central/State PSU or Govt.
Organization. Self-certificate from bidder mentioning the
(In case of a consortium, this Scope of Work, Bill of Material and value of the
requirement needs to be met by either Work order/Purchase Order/ Contract
of the Member) Agreement, signed by authorised signatory of
bidder for this bid along with the certificate
Further, in both projects mentioned issued by the Statutory Auditor / Chartered
above- Accountant certifying value of the project
• The offered ERP OEM Product shall
Note: Bidder shall mention disclaimer under
have cumulatively 500 transactional
each Self-certificate that Bidder cannot submit
user-base in two eligible ERP projects
Work order/ Purchase Order/ Contract
• At least 3 modules out of following Agreement due to NDA signed with respective
5. functions / modules of the offered client
ERP OEM Product must have been AND
implemented–
o Finance and Accounting Submission of following certificate/
o Purchasing/Contract document:
Management
o Inventory Management For Completed projects: Bidders must
o Governance, Risk and provide the Necessary Purchase Order/ LOI/
Compliance (GRC) Contract Agreement. Further, the bidder
o Human Resource Management, must provide the successful completion
Payroll and ESS letter from the client. The successful
o Business Intelligence Reporting completion shall include at least one year
FMS subsequent to Go-Live.
Out of the two (2) implemented projects,
at least one (1) should be successfully For ongoing Projects: Bidders must provide
completed (Go-live achieved followed by the Necessary Purchase Order/ LOI/ Contract
completion of at least one year FMS) and Agreement. Further, the bidder must provide
second (2nd) project must have achieved a letter from the client explicitly mentioning
Go-live status. that the project has successfully achieved Go-
Live status.
(*Completion Certificate for completed projects

shall be issued after the Go-Live and at least one
year FMS period is over)
Page 20 of 390
JPDCL
S.
No.
Project Citation/ Case Studies as per format in
Form 12 followed by documentary evidences
as below:
i. Work order/ Purchase Order/ Contract

Agreement
OR
ii. Self-certificate from bidder mentioning the
Scope of Services and value of the Work
order/ Purchase Order/ Contract
The Bidder(s) should have implemented
Agreement, signed by authorized signatory
at least One (1) Turnkey IT System
of bidder for this bid along with the
Integration (TSI) project having
certificate issued by the Statutory Auditor/
installation, configuration,
Chartered Accountant certifying value of
customization, implementation, Roll
the project
Out as well as providing FMS services /
Note: Bidder shall mention disclaimer
System Operation services and
under each Self-certificate that Bidder
preferably supply of Hardware/cloud
cannot submit Work order/ Purchase
services/Software/ licenses during the
Order/ Contract Agreement due to NDA
6. last Ten (10) financial years,
signed with respective client
AND
• One project each costing not less than To show the Project as “Complete”/ “Phase
the amount equal to INR. 20 Cr. Completed” minimum one (1) of the
OR following certificate/ documents shall be
• two projects each costing not less enclosed:
than the amount equal to INR. 13 Cr.
OR i. Completion Certificate/ Phase Completion
• three projects each costing not less Report/ Letter issued & signed by the
than the amount equal to INR. 10 Cr. competent authority of the client entity on
the entity’s letterhead/ email
communication
OR
ii. Copies of payments received against the
Work order/ Purchase Order/ Contract
Agreement signed by the Statutory
Auditor/ Chartered Accountant of bidder
or any other document certifying the
completion/ phase completion of the
project
Page 21 of 390
JPDCL
S.
No.
The Sole Bidder or any of Consortium
members, should jointly possess any three
(3) of the below certifications, which are
valid at the time of bidding:
The sole bidder or the consortium member:
i. ISO 9001:2008/ ISO 9001:2015 for
Quality Management System i. Copies of valid certificates
ii. ISO 20000:2011 for Service AND

IT
Management For CMMi level 5
Copies of valid certificates
iii. ISO 27001:2013 for Information OR
7.
Security Management System In case bidder is in the process of re-
iv. CMMi Level 5 Capability Maturity certification of CMMi level 5 or above, then
Model Integration the copy of expired certificate and present
assessment certificate from duly authorised
Note: The Sole Bidder or Lead Bidder CMMi auditor to be enclosed.
should have at least CMM/CMMI level 5
valid certification. The member of the
consortium should possess minimum one
(1) of the above valid certifications.
The Sole Bidder and Consortium member

and its Partner/ Directors should not have
been blacklisted/ debarred by any Central
Government/ State Government/ PSU or
any other Government Institution/ The Sole Bidder and Consortium member shall
Authority in India/ Multi-lateral funding furnish an undertaking signed by CEO/ Country
agency. Also, have not been under any Head/ Authorized signatory of the company to
8. legal action for indulging in corrupt be provided on Non – judicial stamp paper of
practice, fraudulent practice, coercive INR 100/- or such equivalent amount and
practice, undesirable practice, breach of document duly attested by notary public as
contract or restrictive practice with any per format in Form 18
Indian Central Government/ State
Government in last three (3) years as on
bid submission date and the same must
have been revoked prior to bid submission
Page 22 of 390
JPDCL
S.
No.
a. Specific Power of Attorney in favour of
Authorized Signatory signing the bid
and Board Resolution in favour of
person granting the Power of
Attorney for the Sole Bidder or the
Lead Bidder in case of Consortium (on
Non – judicial stamp paper of INR i. Power of Attorney for the Sole Bidder or
100/- or such equivalent amount and the Lead Bidder in case of Consortium to
document duly notarized) who shall sign the Contract Agreement as per
sign the Contract Agreement format in Form 10
9. b. Specific Power of Attorney in favour of ii. Specific Power of Attorney from each
Authorized Signatory signing the bid consortium member to the Lead Bidder
and Board Resolution in favour of authorizing to sign the Contract
person granting the Power of Agreement on behalf of them as per
Attorney for the Lead Bidder from format in Form 9
member of the Consortium (on Non –
judicial stamp paper of INR 100/- or
such equivalent amount and
document duly notarized) authorizing
to sign the Contract Agreement on
behalf of them
a. The Sole Bidder or the Lead Bidder i. Office address in each city along with
shall have a project office in Jammu Shop Establishment Certificate
city or shall furnish an undertaking to
OR
establish an office in each city within
10.
thirty (30) days of signing the ii. Undertaking from authorized signatory
Contract. The office shall be to open office in each city within thirty
maintained during the entire duration (30) days) days from Contract signing
of the contract date.
Bidder should be authorized system
integrator/implementation partner of the
offered ERP OEM Product for sale,
11. support, and services of the offered ERP Letter from OEM of offered ERP OEM Product
OEM Product. In case of Consortium,
either ERPSI-Lead/ERPSI-2nd may met the
requirement.
The technical and financial requirements of qualification for the ERP OEM are as follows:
S.
No.
The ERP OEM should be incorporated in India i. Certificate of incorporation /

1. under the Companies Act 1956 for at least 10 Partnership deed
years. ii. GST Registration
Page 23 of 390
JPDCL
S.
No.
The offered ERP OEM product should have Work order/ Purchase Order/ Contract
2. been implemented on a Cloud based IT Agreement / Client Certificate
Infrastructure for at least One customer.
Minimum Average Annual Turnover (MAAT) Copy of Annual Audited Financial
last best three financial years out of last five Statements certified by Chartered
financial years (FY 2017-18, FY 2018-19, FY Accountant
3.
2019-20, 2020-21, 2021-22) of the ERP OEM
should not be less than INR Five Hundred (500)
Crore. ERP OEM must have positive net worth.
Self-certificate by the ERP OEM with the
The OEM of the ERP OEM Product should have
list of five (5) implementation Partners /
at least Five (5) Implementation Partners /
4. System Integrators with details of the
System Integrators who must have experience
projects
in implementation of the proposed ERP OEM
product in enterprises.
The ERP OEM product should have been • Purchase Order/ LOI/ Contract
successfully implemented at least 3 (three) ERP Agreement / client certificate along
Projects of the offered ERP OEM Product in with a cover letter from the ERP OEM.
India in last 10 years with at least 500 ERP • Successful completion letter from the
licenses in each project as on bid submission client.
5. date.
(*Completion Certificate is issued after
Out of the 3 (three) projects at least 1 (one)
theGo-Live and FMS period is over)
project must have been implemented in Power
Sector (Generation, Transmission or
Distribution)
Self-Certifications by the
ERP OEM product must be specific and latest
authorized signatory of the OEM.
version for India with statutory requirements
incorporated and should have a localization
support in terms of Excise, Income Tax, GST,
auditing etc. specific to Indian requirements. It
should also support data entry in
Hindi/regional languages a second language
also.
6.
ERP OEM Product should be a cloud based
modular architecture which should provide
1. Clean Core (KPI) Dashboard
2. Process optimization and automation
3. Unique access to the sustainability-focused
innovations.
4. New AI capabilities, inclusive of Generative
AI based functionality.
Page 24 of 390
JPDCL
S.
No.
Details of Support Services with address
ERP OEM should have Service Level Agreement
of support centres in India along with Self
(SLA) based support for offered products &
Certification by the ERP OEM
related issues with first level support point in
India.
The support should be available on 24x7x365
7. basis with Technical Assistance Centers
(TAC)/Support Centre based in India.
The support center should offer post-sales

support including Tele support for the offered
products.
The technical and financial requirements of qualification for the CSP Vendor are as follows:
S.
No.
The Cloud Service Provider (CSP) should be
incorporated and registered in India under
the Indian Companies Act 1956 and should i. Certificate of incorporation /
1. Partnership deed
have been in operation in India from
minimum of last Five (5) financial years ii. GST Registration
ending 31st March 2022.
The Cloud Service Provider (CSP) must be i. Valid STQC Audit Compliant
empanelled with the Ministry of Electronics & certificate.
2.
Information and Technology, Government of ii. Proof of valid Empanelment by
India (MEITY). MEITY (reference on MEITY website
or Empanelment Certificate).
3. The proposed Cloud Service Provider (CSP)‘s Self-certificate singed by authorized
Data Centres /DRC Centres shall be in India signatory and duly attested by the Bidder.
4. Proposed Cloud Service Provider (CSP) should Copy of valid relevant certification
be SOC – 2 Type II compliant.
Page 25 of 390
JPDCL
S.
No.
The CSPs hosting services facility/location
shall be certified to the following standards:
a) ISO 27001/ ISO 27034-1 – Data
Centre and the cloud services should
be certified for the latest version of
the standards.
5. b) ISO/IEC 27017:2015 – Code of Copy of valid relevant certification
practice for information security
controls based on ISO/IEC 27002 for
cloud services and Information
technology.
c) Uptime Institute Tier Certification or
similar certification for Tier III
compliant
13. Technical Evaluation Criteria

• The prospective Bidder (referred as ERPSI-Lead) and the 2nd consortium member (in case of
a consortium; referred as ERPSI-2nd) shall have to enclose all documentary evidence in
support of technical evaluation criteria. JPDCL reserves right to summarily reject any bid
which does not contain all the mandatory supporting document or may ask bidder to
resubmit documents, the decision of JPDCL shall be final and binding in this regard
• Only those bidders who qualify Eligibility Criteria requirements shall be qualified for technical
bid evaluation
• The JPDCL reserves the right to reject a Product/ Solution/ Service if it is of an opinion that the
offered product/ service does not match the technical/ functional requirements/objectives
specified in the RFP
• Any bid found to be non-compliant to the mandatory Functional Requirements, RFP terms and
conditions and the Scope of Work shall be rejected and shall not be considered for further
evaluation. Bids that are technically compliant would only be taken up for commercial
evaluation
• Only those bids which have a minimum technical score of 75% of total marks will be
considered qualified. However, JPDCL reserves the right to lower the minimum required marks
to 70% if none of bidder achieves 75% of the total technical.
Page 26 of 390
Max.
S. No. Criteria Category Evaluation Criterion Supporting Documents required*
Marks
A Bidder’s profile (Max Marks: 30)
A1 Average Annual Turnover from IT/ ICT Average annual turnover from IT/ ICT services over 10 Certificate from the Statutory
(System Implementation) services of the last best three financial years out of last five Auditor/ Chartered Accountant on
the Sole Bidder or in case of a financial years (FY 2017-18, FY 2018-19, FY 2019- turnover details from the over the
Consortium, combined turnover of 20, 2020-21, 2021-22). Marks shall be allotted as last three (3) best financial years.
lead bidder and partner/ consortium given below:
member
• More than INR 90 Crores = 10 marks
• More than INR 70 Crores – up to INR 90 Crores
= 8 marks
• >= INR 50 Crores – up to 70 Crores = 6 marks
A2 Average Annual Turnover from ERP Average annual turnover from ERP solution (on 5 Certificate from the Statutory
solution (on Cloud/ on-Premises) Cloud/ on-Premises) implementation over the last Auditor/ Chartered Accountant on
implementation of the Sole Bidder or best three financial years out of last five financial turnover details from the over the
Lead Bidder years (FY 2017-18, FY 2018-19, FY 2019-20, 2020- last three (3) financial years (FY
21, 2021-22). Marks shall be allotted as given 2019-20, 2020-21, 2021-22)
below:
• More than INR 40 Crores = 5 marks
• More than INR 20 Crores – up to INR 40 Crores
= 3 marks
• >= INR 15 Crores – up to 20 Crores = 2 marks
Page 27 of 390
Max.
Marks
A3 The Bidder(s) should have • One project each costing not less than the 10
implemented at least One (1) amount equal to INR. 20 Cr.
Turnkey IT System Integration (TSI) o 1 Project= 8 Marks
project having installation, o 2 Projects- 10 Marks
configuration, customization,
implementation, Roll Out as well as • Two projects each costing not less than the
providing FMS services / System amount equal to INR. 13 Cr.
Operation services and preferably o 2 Project= 8 Marks
supply of Hardware/cloud o 4 Projects- 10 Marks
services/Software/ licenses during • Three projects each costing not less than the
the last Ten (10) financial years, amount equal to INR. 10 Cr.
o 3 Project= 8 Marks
o 6 Projects- 10 Marks
A3 Certifications of the Sole Bidder and The Sole Bidder or Consortium Member should 5 Copies of valid certificates
Consortium Member jointly possess below certifications which are valid
at the time of bidding:
i. ISO 9001:2008/ ISO 9001:2015 for
Quality Management System
ii. ISO 20000:2011 for IT Service
Management
iii. ISO 27001:2013 for Information
Security Management System
Page 28 of 390
Max.
Marks
iv. CMMi Level 5 Capability Maturity
Model Integration
Marks shall be allotted as given below:
i. No. of certifications (4) – 5 marks
ii. No. of certifications (3) - 3 marks
iii. No. of certifications (2) – 2 marks
B Project Experience (Max Marks: 25)
B1.a The bidder should have successfully The Sole Bidder or Consortium Member should 10 Work order/ Purchase Order/
implemented at least two ERP have experience, in India of ERP solution (on Contract Agreement
Projects of the offered ERP OEM Cloud/ on-Premises) implementation**(should
product in India in last 10 (ten) years OR
have been declared "Go-live" by the Client) during
with at least 250 ERP licenses in each the last five years as on bid submission. Contract clearly highlighting the
project. Scope of Work, Bill of Material and
• No. of project (5) - 10 marks value of the Contract/order
Further, projects mentioned above- • No. of project (4) - 8 marks OR
• At least 3 modules out of
• No. of project (2) – 6 marks Self-certificate from bidder
following functions / modules of
the offered ERP OEM Product mentioning the Scope of Work, Bill
must have been implemented– of Material and value of the Work
o Finance and Accounting order/Purchase Order/ Contract
o Purchasing/Contract Agreement, signed by authorised
Management signatory of bidder for this bid along
o Inventory Management with the certificate issued by the
Page 29 of 390
Max.
Marks
o Governance, Risk and Statutory Auditor / Chartered
Compliance (GRC) Accountant certifying value of the
o Human Resource project
Management, Payroll and
Note: Bidder shall mention
ESS
disclaimer under each Self-
o Business Intelligence
certificate that Bidder cannot submit
Reporting
Work order/ Purchase Order/
Contract Agreement due to NDA
AND
Submission of following certificate/
document:
For Projects declared Go-Live
Go-Live certificate issued & signed
by the competent authority of the
client entity on the entity’s
letterhead.
B1.b Implementation of ERP Projects in 5 Work order/ Purchase Order/

Power Sector 1 ERP project in Power sector – 4 Marks. Contract Agreement
2 ERP project in Power sector – 5 Marks OR
Self-certificate from bidder
mentioning the Scope of Services
Page 30 of 390
Max.
Marks
and value of the Work order/
B2 Bidder’s Cloud Experience The Sole Bidder or Consortium Member should 10
Purchase Order/ Contract
have experience of Cloud based solution hosting IT
Agreement, signed by authorized
/ ERP implementation projects.
signatory of bidder for this bid along
• No. of project (3) - 10 marks with the certificate issued by the
• No. of project (2) – 8.5 marks Statutory Auditor/ Chartered
Accountant certifying value of the
• No. of project (1) – 7.5 marks project
Note: Bidder shall mention
disclaimer under each Self-
certificate that Bidder cannot submit
Work order/ Purchase Order/
Contract Agreement due to NDA
AND
To show the Project as “Complete”/
“Phase Completed” minimum one
(1) of the following certificate/
documents shall be enclosed:
Completion Certificate/ Phase

Completion Report/ Letter issued &
signed by the competent authority
of the client entity on the entity’s
letterhead/ email communication
Page 31 of 390
Max.
Marks
OR
Copies of payments received against
the Work order/ Purchase Order/
Contract Agreement signed by the
Statutory Auditor/ Chartered
Accountant of bidder or any other
document certifying the
completion/ phase completion of
the project
ERP OEM Experience (Max Marks: 20)
B4.a ERP OEM Experience The ERP OEM product should have been 10
successfully implemented at least 3 (three) ERP
Projects of the offered ERP OEM Product in India
in last 07 years with at least 500 ERP licenses in
each project as on bid submission date.
Out of the 3 (three) projects at least 1 (one) project
must have been implemented in Power Sector
(Generation, Transmission or Distribution)
• No. of project (5) - 10 marks
• No. of project (4) – 8 marks

B4.b ERP OEM Experience in Power Sector • No. of project (2) - 5 marks 5
Page 32 of 390
Max.
Marks
B5 Software as a Service (SaaS) with The offered COTS ERP SaaS certified service 5
multiple CSP availability available in India with numbers of MeitY
empanelled CSPs.
• 1 CSP – 1 Marks
• 2 CSP - 3 Marks
• 3 CSP or above – 5 Marks
C Approach & Methodology with proposed solution (Max Marks: 10)
C1 Approach & methodology • Understanding of scope, high-level 10 Presentation by bidder

architecture and proposed ERP solution to
meet the functionalities as given in RFP – 03
marks
• Risks for the project and propose suitable
mitigation plan for each of these risks – 02
marks
• Experience and approach of implementing ERP
solution on cloud – 02 marks
• Manpower Schedule and Work Plan – 03
marks
D Quality and Competence of Resources (Max Marks: 15)
D1 Project Manager (Onsite) a. Experience (2 Marks) 5
Page 33 of 390
Max.
Marks
● Min. 12 years of Experience in IT Detailed CV as per the format
Consulting projects and implementation specified in Section 4
of ERP / customized application
development or similar domain for at least
5 years
Should have at least one project experience in the
Power Generation Sector.(If period of experience
not defined, no marks will be given)
Marks will be allocated as below:
• Experience 12 – 15 years : 1 Marks
• Experience more than 15 years: 2
Marks
I(f period of experience not defined, no marks will
be given)
b. Interaction (1 Marks)
● It is compulsory that the proposed resources
must be available for interaction with the
Committee.
● Marks will be awarded based on interaction.
If any resource is not available for
interaction, then ‘ZERO’ marks will be
awarded
D2 Functional Lead for each of the below 6x1=6
a. Project Experience
ERP module having experience in
Page 34 of 390
Max.
Marks
respective domain (one for each ● At least 2 project experience in functional
Module i.e. 06 Resources x 1 Mark) implementation of the module for which the
Functional Consultant has been proposed.
1. Finance and Accounting
2. Purchasing/Contract
Management • 2 Projects : 0.5 Marks
3. Inventory Management • More than 2 Projects : 1 Marks
4. Governance, Risk and (If experience not defined, no marks will be given)
Compliance (GRC)
5. Human Resource
Management, Payroll and ESS
6. Business Intelligence Reporting
D3 Solution Architect a. Project Experience (1 Marks) 2

● Minimum 08 years’ Experience as Solution
Architect
• Experience 08 – 12 years : 0.5 Marks
• Experience more than 12 years : 1
Marks
(If period of experience not defined, no marks will
be given)
Page 35 of 390
Max.
Marks
Committee.
awarded
D4 Technical Consultant a. Experience (1 Marks) 2
● Minimum of 8 years of Data Centre
experience including 2 years of Cloud
Administration experience
● Should have at least 2 project experience
on the SaaS-based ERP proposed
• 2 Projects : 0.5 Marks
• More than 2 Projects : 1 Marks
(If period of experience not defined, no marks will
be given)
Committee.
Page 36 of 390
Max.
Marks
awarded
*Note: During Bid evaluation, if required JPDCL may seek additional document(s) / clarification(s) from bidder. Bidder shall be required to provide written
clarification on the queries within the stipulated timeframe failing which, JPDCL shall have right do disregard the clarification and proceed with the evaluation
as per the RFP terms and conditions
The Technical Evaluation would be done for only those bidders, who comply with the eligibility criteria mentioned in Section 2 – Eligibility and Qualification
Requirements. The Evaluation Committee may invite only such qualified bidders to make a presentation as part of the technical evaluation.
Only those bids which have a minimum technical score of 75% of total marks and minimum 50% in each section of the Technical Evaluation as given in Table
below shall be considered qualified. However, JPDCL reserves the right to lower the minimum required marks if none of Bidder achieves 75% of the total
technical. The bid complied as per criteria mentioned above shall be evaluated as per the framework detailed below:
Minimum Qualifying
S. No. Evaluation Criteria Max. Marks
Marks (for each section)
1. Bidder’s Profile 30 15
2. Project Experience 25 12.5
3. ERP OEM Experience 20 10

4. Proposed solution, approach, methodology 10 5
5. Quality and Competence of Resources 15 7.5
The technical marks of a bidder shall be assigned to Bidder and it shall be awarded based on the Technical Evaluation Criteria as specified above. JPDCL’s
decision in this regard shall be final & binding and no further discussion shall be held with Bidders.
Page 37 of 390
Note: JPDCL reserves the right to share the technical score of the qualified bidder with respective bidder only. After sharing of the technical score, Bidder shall
be required to maintain strict confidentiality and the integrity of the technical scores shared with them by JPDCL.
Page 38 of 390
JPDCL
14. Bid Opening and Evaluation Methodology
14.1. Stage – 1
14.1.1. Verification of Pre-Qualification Criteria
Envelope 1 containing the Pre-Qualification Criteria (PQC) Compliance Format & supporting
documentary evidence will be opened. The bids qualifying the PQC will then be taken forward to next
step. Those bids which do not meet the PQC will be summarily rejected and technical bids will not be
evaluated.
The bidder has to provide the details of PQR supporting documents for evaluation in the format as per
the Pre-Qualification Compliance Format as per Form 14 in Section 4.
14.1.2. Technical Bid Evaluation
Envelope 1 containing the Technical Criteria Compliance Format & the supporting documents will be
opened next. Technical Bid Evaluation will be done for the bidders who qualify in the Pre-
qualification Criteria (Stage 1). The bidder must provide the details of TQR supporting documents for
evaluation in the format as per the Technical Qualification Compliance Format as per Form 14 in
Section 4.
The technical score of a bidder ‘Tb’ shall be assigned to bidder and it shall be awarded based on the
Technical Evaluation Criteria as specified in the RFP. Department’s decision in this regard shall be final
& binding and no further discussion shall be held with any bidder.
Tb : Absolute Technical Score
Tmax : Maximum Technical Score
Tn : Normalized Technical score of bidder under Consideration
Normalized Technical score (Tn) = Tb/ Tmax * 100
14.2. Stage – 2 Financial Evaluation

1. All the technically qualified bidders shall be notified to participate in Commercial Bid opening
process
2. Bidders quoting unrealistic cost of items shall be summarily rejected by JPDCL. Any bid found
to have unsatisfactory response in the eligibility criteria as mentioned shall be rejected and
shall not be considered for further evaluation.
3. The financial Bids for the technically qualified bidders shall then be opened on the notified
date and time and reviewed to determine whether the Financial Bids are substantially
responsive. Bids that are not substantially responsive are liable to be disqualified at
Purchaser’s discretion.
4. The Commercial Bids for the Technically Qualified bidders who have scored minimum of 75
marks and minimum 50% in each section of the Technical Evaluation shall then be opened on
the notified date.
5. Arithmetical errors will be rectified on the following basis:
Page 39 of 390
JPDCL
“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. If there is a discrepancy between words and figures, the amount in words will
prevail”
6. The bid price shall include all taxes and levies and shall be in Indian rupee and mentioned
separately
7. The Commercial Bids shall be opened, in the presence of Bidders’ representatives who choose
to attend the Commercial Bid opening on date and time to be communicated to all the
technically qualified Bidders. Bidder’s representatives who are present shall sign a register
evidencing their attendance. The name of bidder & bid prices shall be announced at the
meeting.
14.3. Scoring of Commercial Criteria
The Commercial score of a bidder ‘Fb’ shall be assigned to ERPSI. ‘Fb’ shall be the total Commercial
quote made by bidder (excluding the Optional Services quotes sought in the Commercial bid, if
any)
Fn : Normalized Commercial score for bidder under consideration
Fb : Commercial quote for bidder under consideration
Fmin : Commercial quote of the lowest evaluated Commercial Bid
Normalized Commercial Score (Fn) = 100 x Fmin/ Fb
14.4. Scoring of Commercial Criteria

1. Quality and Cost based Selection (QCBS) method shall be adopted for the evaluation of
Bids
2. Under QCBS, the Technical Proposals will be allotted weightage of 70% while the
Commercial Proposals will be allotted weightages of 30%.
3. Bids shall be ranked according to their combined technical (Tb) and Commercial (Fn)
scores using the weights (T = 0.70 the weight given to the Technical Bids; P = 0.30 the
weight given to the Commercial Bids; T + P = 1). The final evaluation shall be based on
Final Score which shall be calculated as shown below:
4. Final Score (S) = Tn x T + Fn x P
Bidder achieving the highest combined technical and commercial score shall be invited for awarding
the contract. In case of a tie where two or more bidders achieve the same highest combined technical
and commercial score, bidder with the lower commercial bid shall be invited first for awarding the
contract
Page 40 of 390
JPDCL
14.5. Rejection Criteria
Besides other conditions and terms highlighted in the RFP, bids may be rejected under following
circumstances:
a. Eligibility Rejection Criteria
i. Bids submitted without or improper EMD
ii. Eligibility Criteria containing commercial details
iii. Bids received through Telex/ Telegraphic/ Fax/ E-Mail/ post etc. except, wherever
required, shall not be considered for evaluation
iv. Bids which do not confirm unconditional validity of the bid as prescribed in the RFP
v. If the information provided by the bidder is found to be incorrect/misleading at any stage/
time during the Tendering Process
vi. Any effort on the part of a Bidder to influence the Purchaser’s bid evaluation, bid
comparison or Contract award decisions
vii. Bids without power of authorization and any other document consisting of adequate proof
of the ability of the signatory to bind the bidder
b. Technical Rejection Criteria
i. Technical Bid containing commercial details
ii. Revelation of Prices in any form or by any reason before opening the Commercial Bid
iii. Failure to furnish all information required by the RFP or submission of a bid not
substantially responsive to the RFP in every respect
iv. Bidder not quoting for the complete Scope of Work as indicated in the RFP, addendum (if
any) and any subsequent information given to the bidder
v. Bidders not complying with the functionality, specifications and other Terms and
Conditions as stated in the RFP
vi. The bidder not conforming unconditional acceptance of full responsibility of providing
Goods and Services in accordance with the Scope of Work and General Conditions of
Contract
vii. If the Bid does not conform to the timelines indicated in the Bid
viii. Bidder not scoring minimum marks as mentioned in the RFP
c. Commercial Rejection Criteria
i. Incomplete Commercial Bid
ii. Commercial Bids that do not conform to the RFP’s Commercial Bid format
iii. Total price quoted by the bidder does not include all statutory taxes and levies applicable
iv. If there is an arithmetic discrepancy in the commercial bid calculations, the Purchaser shall
rectify the same. If The bidder does not accept the correction of the errors, bid may be
rejected.
v. If bidder quotes NIL charges/consideration, the bid shall be treated as unresponsive and
shall not be considered
Page 41 of 390
JPDCL
Section 3. Instructions to Bidders and Bid Data Sheet

Table of Contents
Section 3. Instructions to Bidders and Bid Data Sheet ................................................................................. 43
A. General Provisions .............................................................................................................................. 43
B. Preparation of Proposals .................................................................................................................... 48
C. Submission, Opening and Evaluation.................................................................................................. 55
D. Award of Contract ............................................................................................................................... 60
E. Bid Data Sheet .................................................................................................................................... 62
Annexure – I Format for request for Clarification / Pre-bid queries ........................................................... 66
Annexure – II Document Checklist and List of Forms.................................................................................. 67
Page 42 of 390
JPDCL
Section 3. Instructions to Bidders and Bid Data Sheet

A. General Provisions
1. Definitions 1.1. Definitions
a) “ERP System Integrator (ERPSI) Contract” or “ERPSI
Contract” or “Contract” shall mean the Contract to be
entered into between the Selected Bidder in the event
the Selected Bidder is an individual entity, Lead Bidder in
the event the Selected Bidder is a Consortium 1 and
the Utility, for undertaking the Project;
b) “Bid” shall mean the bid submitted by a Bidder(s) in response
to this RFP and shall include the Technical Bid and the
Financial Bid;
c) “Bidder(s)” shall mean individual entity or Consortium
of entities bidding in response to this RFP. The Bidder can
either be a company incorporated under the applicable
laws of their relevant jurisdiction;
d) “Bidding Consortium” shall mean the Consortium of
entities bidding for Project after executing Consortium
Agreement as per the terms and conditions of this RFP;
e) “Bid Data Sheet (BDS)” means an integral part of the
Instructions to Bidders (ITB) Section 3, that is used to reflect
issues, details, and conditions specific to the procurement,
to supplement and/or modify the provisions of ITB.
f) “Conflict of Interest” shall have the meaning as ascribed
thereto in ITB 3;
g) “ERPSI 2nd” shall mean the Member of the
Bidding Consortium other than the ERPSI-Lead;
h) “Contractor” shall mean the same as ―ERPSI;
i) “Contract Price” shall have the meaning as ascribed thereto
in Section 7;
j) “Financial Bid” shall have the meaning as ascribed thereto in
ITB 17;
k) "Financially Evaluated Entity" shall mean the company
which has been evaluated for the satisfaction of the
financial requirement set forth in Clause 8 of Section 2;
l) Financial Proposal” shall mean the same as Financial Bid;
m) “Financial Year” or “FY” shall mean the period starting
from 1st April of a calendar year to 31st March of
the consecutive calendar year;
n) “ITB” (this Section 3 of the RFP) means the Instructions
to Bidders that, along with other Sections, provides the
Bidders with all information needed to prepare their
Proposals.
Page 43 of 390
JPDCL
o) “ERPSI-Lead” or “Lead Bidder” shall mean the Member of

the Bidding Consortium, designated as such by the
other members of the Consortium, having authority to
represent all the members before the Utility;
p) Month shall mean calendar months
unless otherwise specified.
q) “Operational Go-live” or “Operational” shall
have the meaning as ascribed thereto in Section 6 of the RFP
Document;
r) “Project” shall mean the Utility‘s ERP Project defined in
Section 6 of the RFP Document
s) “Project Completion” or “Completion” shall signify the end
of the Implementation and FMS phase of the Project
t) “Proposal” shall mean the same as Bid and shall include
the Technical Proposal and the Financial Proposal;
u) “Request for Proposal” or “RFP” means this Tender of which
the number, name and details have been mentioned in Bid
Data Sheet, including all its Volumes/ Sections/ Forms/
Annexures/ Appendices etc., for Selection of System
Integrator (ERPSI) (including all clarification/ addendum/
amendment/ corrigendum/ etc. issued from time to time);
v) RFP Document shall have the same meaning as ascribed
thereto in ITB 2.1 and ITB 2.1.1
w) “Service(s)” or “Related Service(s)” shall mean any
Service(s) performed or to be performed as a part of the
Project by the ERPSI;
x) “Sub-Contractor” shall mean any person, natural or
legal, including manufacturers, to whom execution of any
part of the ERPSI Contract, including preparation of any
design or supply of the ERP OEM Product, is sub-
contracted directly or indirectly by the Contractor, and
includes its legal successors or permitted assigns;
y) “Technical Bid” shall have the meaning as ascribed thereto in
ITB 16;
z) “Technical Proposal” shall mean the same as Technical Bid;
aa) "Technically Evaluated Entity" shall mean the company
which has been evaluated for the satisfaction of the
technical requirement set forth in the RFP
bb) “Tender” shall mean the same as RFP;
cc) “Tender Fee” shall mean the fees submitted with the RFP;
dd) “Utility” means the entity, named, and as briefly described
in Bid Data Sheet, that has issued the Request for Bids
for Appointment of Selection of System Integrator for
Supply,
Page 44 of 390
JPDCL
Installation, Commissioning, Implementation and Support

for Enterprise Resource Planning (ERP) System at JPDCL, to
enter into a Contract for the implementation of the ERP
system in the Project area as per the RFP Document.
1.2. Capitalised terms used herein but not defined specifically shall
have the meaning as ascribed to them in Section 6 and Section
7, and elsewhere in RFP Document.
1.3. Headings and Marginal Notes: Headings and marginal notes to
the terms and conditions of the Contract are not deemed to
form part thereof nor are to be taken into consideration in the
interpretation or construction thereof or of the Contract.
2. Introduction 2.1. This Request for Proposal (RFP) is issued by the Utility for
selecting the Selection of System Integrator (ERPSI) to Design,
Develop, Implement and Maintain Enterprise Resource
Planning (ERP) Solution on Cloud. This RFP Document
(a) About this Request provides the overall structure of the document (as
for Proposal outlined in the beginning of the document in the section
titled ―Summary, Abbreviations & Table of Content),
requirements and general terms and conditions applicable to
each Bidder.
2.1.1.The RFP Document (also referred to as the bidding document)
consist of Parts I, II, and III, which include all the sections
indicated below, and should be read in conjunction with any
Addenda/ Corrigenda/ Amendments/ Clarifications etc. issued
thereto from time to time in accordance with this Section 3.
PART I Bidding Procedures and Requirements
• Section 1 - Request for Proposal Notice
• Section 2 - Eligibility Requirements
• Section 3 - Instructions to Bidders and Bid Data
Sheet
• Section 4 - Bidding Forms - Technical Proposal
• Section 5 - Bidding Forms - Financial Proposal
• Section 6 - ERP Requirements and Service Level
Agreement
PART II Contract Form and Conditions of Contract
• Section 7 – Contract Form and Conditions of Contract
(b) Bidding Process and
Electronic- PART III Contract Related Forms
Procurement System • Section 8 – Contract Related Forms
2.2. Bidding against the Request for Proposal shall be under Two
Envelope Two Stage Bidding Process. The bidding process will
be conducted online with Electronic – Procurement System
(e- Procurement/ e- Tendering/ e- Bidding System) as
specified in BDS.
2.2.1.The Bidders who wish to participate in online Tenders will have

to procure/ should have legally valid digital signature as per
Page 45 of 390
JPDCL
Information Technology Act, 2000 using which they can sign

their electronic Bids.
2.2.2.All Bids should be digitally signed. For details regarding digital

signature certificate and related training, the Bidder should
contact at the address mentioned in BDS.
2.3. The Bidders are invited to submit their Proposal comprising

a Technical Proposal and a Financial Proposal, for award of
Contract named in the BDS. The Proposal will be the basis for
evaluation and holding discussions, if required, and ultimately
(c) Study of Utility‘s
Existing Systems signing the Contract with the Selected Bidder.
2.4. A standard brief regarding detail of existing systems relevant to
the ERP Project has been provided in Section 6. However,
notwithstanding the same, all Bidders are advised to visit and
examine the site and existing facilities, and obtain for itself, on
its own responsibility and cost, all information that may be
necessary for preparing the Bid. The cost of visiting the site
shall be at the Bidder‘s own expense.
2.5. The Bidder and any of its personnel or agents shall be
granted permission, through the assistance of the Utility, by
the Utility to enter upon its premises and lands for the purpose
of such inspection, but only upon the express condition that
the Bidder, its personnel and agents will release and
indemnify the Utility and its personnel and agents from and
against all liability in respect thereof and will be responsible
for death or personal injury, loss of/or damage to property
and any other loss, damage, costs and expenses incurred as a
result of the inspection.
2.6. The Bidder‘s designated representative(s) is/are invited to
attend a pre-bid meeting at Bidder‘s expense, which shall take
(d) Pre-Bid Meeting
place online or at the time and venue/online joining link
specified in the BDS
2.7. The purpose of the meeting will be to clarify any issues
regarding this RFP in general and the scope of work in particular.
2.8. The Bidder may submit any question or query to Utility in
writing, to reach Utility not later than one week before the
meeting as per the format given in BDS. It may not be
practicable at the meeting to answer questions received late,
but questions and responses will be transmitted as indicated
hereafter.
2.9. Minutes of the meeting, including the text of the questions
raised and the responses given, together with any responses
prepared after the meeting, will be transmitted through the e-
Procurement System mentioned in ITB 2.2 without delay to all
prospective Bidders who have downloaded the RFP.
Page 46 of 390
JPDCL
2.10. Non-attendance at the pre-bid meeting (online/at the

Utility specified venue) will not be a cause for disqualification of
a Bidder
3. Conflict of Interest 3.1. A Bidder shall not have a conflict of interest that affects
the Bidding process (the ―Conflict of Interest”). In the event a
Bidder is found to have a Conflict of Interest, the Utility may
choose to reject the Bid, terminate the ERPSI Contract (in the
event it has been awarded) as per termination clause in the
ERPSI Contract. Any Bidder found to have a Conflict of
Interest shall be disqualified.
3.2. A Bidder shall be deemed to have a Conflict of Interest affecting
the bidding process, if:
(a) a constituent of such Bidder is also a constituent of another

Bidder; or
(b) such Bidder or its Member thereof receives or has received
any direct or indirect subsidy, grant, concessional loan
or subordinated debt from any other Bidder or its
Member, has provided any such subsidy,
grant, concessional loan or subordinated
debt to any other Bidder or its Member; or
(c) such Bidder has the same legal representative for purposes
of this Bid as any other Bidder; or
(d) such Bidder, has a relationship with another Bidder,
directly or through common third party/ parties, that puts
either or both of them in a position to have access to each
other‘s information about, or to influence the Bid of either
or each other; or
(e) such Bidder has participated as a consultant to the
Authority in the preparation of any documents, design,
or technical specifications of the Project.
Explanation: In case a Bidder is a Consortium, then the term Bidder

as used in this Clause shall include each Member of such Consortium.
4. Bidders to Inform Itself 4.1. The Bidder shall make independent enquiry and satisfy itself
Fully with respect to all the required information, inputs, conditions
(including site conditions) and circumstances and factors that
may have any effect on its Bid. Once the Bidder has submitted
the Bid, the Bidder shall be deemed to have examined the laws
and regulations in force and fixed its price taking into account
all such relevant conditions and also the risks, contingencies
and other circumstances which may influence or affect the
Services performed within the scope of work, as provided in
this RFP. Accordingly, the Bidder acknowledges that, on being
selected, it shall not be relieved from any of its obligations
under the RFP Documents nor shall be entitled to any extension
of time for commencement of Services or financial
compensation for any reasons whatsoever attributable to ERPSI
Page 47 of 390
JPDCL
4.2. The Bidders should particularly acquaint themselves with the

technical requirements of Utility‘s all the existing business
processes, systems, operations, assets, equipment,
statutory codes, and standards.
4.3. The Bidder shall familiarize itself with the procedures and time
frames required to obtain all consents, clearances and permits
required for implementation of the Project
5. Fraud and Corruption 5.1. Utility requires compliance with the Anti-Corruption
Guidelines/ Laws in force of the relevant Government/ its
instrumentalities/ Utility.
6. Eligibility and 6.1. The eligibility and qualification requirements for submission of
Qualification Proposals against the RFP are given in Section 2. Proposals, if
Requirements any, from Bidders not complying with the same shall be rejected
outright and shall not be considered for evaluation.
B. Preparation of Proposals
7. General 7.1. In preparing the Proposal, the Bidder is expected to examine the
Considerations and RFP Document in detail. Material deficiencies in providing the
Instructions information or documentation requested in the RFP Document
may result in rejection of the Proposal.
7.2. All Bidders shall comply with the dates and amounts indicated
in this RFP.
7.3. The Bidders shall comply with and agree to all the provisions of
this RFP for various bidding considerations including but not
limited to eligibility, costs, payments, information regarding
Utility‘s systems, bid formats, Bid submission and other
considerations
7.4. The Bidders shall be evaluated based on the requirements,
criteria, norms, and procedures laid out or included by
reference, in the RFP Document
7.5. The Bidders shall be required to undertake the scope of work for
the Project indicated in Section 6 of the RFP Document.
7.6. The Bidders must conform to the requirements and provide a list
of equipment (including any special equipment) necessary
to meet the technical specifications, functional &
performance requirements as specified in the Section 6 of RFP
Document as per the format provided in Form 14 in Section 4.
The equipment supplied shall confirm to all the
requirements under all applicable laws including any order
issued by the central government including Order No
No.9/16/2016-Trans-Part (2) dated 18 November 2020 and
Order No. 11/05/2018-Coord. dated 17 September 2020 issued
by Ministry of Power and Order No. F/No.6/18/2019-PPD by
Ministry of Finance, Department of Expenditure, Public
Procurement Division dated 23 July 2020 including any
amendments or modifications to the same from time to time.
7.7. Bidder shall submit Clause by Clause‘ compliance to the RFP
document including the ERPSI Contract and the technical
Page 48 of 390
JPDCL
specifications and functional requirements (with amendments,

if any) as per the format prescribed in Form 14 given in Section
4.
7.8. Bidder‘s Proposal shall include sufficient information and
supporting documentation in order to determine
compliance without further necessity for inquiries.
7.9. The Bidder‘s Proposal shall clearly identify all features described
in the specifications along with any supporting reference
material in accordance with ITB 15.2 as per the format
prescribed in Form 3 given in Section 4.
7.10. An analysis of the technical specifications, functional
and performance requirements of the ERP system as
provided in Section 6 may lead the Bidders to conclude that
additional items of hardware, software and/or
services (for example communication repeater, router
etc.) are required that are not specifically mentioned in this
specification. The Bidders shall be responsible for installing such
items (at no additional cost to the Utility) such that a reliable
and fully functional ERP system is
implemented that meets or exceed the capacity and
performance requirements. Such materials shall be deemed
to be within the scope of the ERPSI Contract. To the extent
possible, the Bidder shall identify and include all such
additional items in their proposal.
7.11. The Bidders are advised to visit sites (at their own expense),
prior to the submission of the proposal, and make surveys and
assessments as deemed necessary for proposal submission.
7.12. Failure by Utility to request information from a Bidder that
has not been properly provided shall not be construed as
waiver on the part of Utility of the obligation of the Bidder to
furnish the said data / information unless the waiver is in
writing.
7.13. Bid submitted by the Bidders before the Bid Submission
Deadline, shall become the property of the Utility, and shall not
be returned to the Bidders.
7.14. The cost of all stamp duties payable for executing the RFP,
Bid Documents or Project shall be borne by the Bidders.
7.15. No interest shall be paid to the Bidder on any amount
submitted to Utility, whether to be returned or not.
8. Cost of Bidding / 8.1. The Bidder shall bear all costs associated with the preparation
Preparation of and submission of its Proposal, including post-bid discussions,
Proposal technical and other presentations etc., and Utility shall not be
responsible or liable for those costs, regardless of the conduct
or outcome of the selection process. Utility is not bound to
accept any proposal and reserves the right to annul the
selection process at any time prior to Contract award, without
thereby incurring any liability to the Bidder.
9. Language 9.1. Bid/Proposal prepared by the Bidders and all correspondence
and documents relating to the Bid exchanged by the Bidder
and Utility and its associates shall be written in the English
language.
Page 49 of 390
JPDCL
9.2. In case the correspondence or documents are in different

language, the Bidder must submit certified translations along
with the original document. These translations can be certified
by a Certified Translator or the same can be submitted with an
undertaking on a non-judicial stamp paper for translation
10. Documents Comprising 10.1. The Proposal shall comprise the documents and forms
the Proposal and List mentioned in this Section in general and listed in Section 4 and
of Forms Section 5 in particular. A Document Checklist for the same as
well as the list of forms referred to in this RFP Document is
provided in RFP.
11. Only One Proposal 11.1. A Bidder shall submit only one Bid in the same bidding
process, either individually as a Sole Bidder or as a Member of
a Bidding Consortium (including the ERPSI-Lead). It is further
clarified that any of the Parent/ Affiliate/Ultimate Parent of
the Bidder/ Member in a Bidding Consortium shall not
separately participate directly or indirectly in the same bidding
process.
12. Proposal / Bid 12.1. The Bid/ Proposal submitted by the Bidder(s) shall be valid
for a period of specified in BDS reckoned from the Bid
Submission Deadline as may be extended from time to time.
12.1.1. All such offers, and terms and conditions set forth
in this RFP shall be valid for the ERPSI till the successful
completion of the Project.
12.1.2. In exceptional circumstance, Utility may solicit the
Bidder‘s consent to an extension of the Bid validity
period. The request and responses thereto shall be
made in writing or by email. If a Bidder accepts to
extend the validity, the Bid Security shall also be
suitably extended. A Bidder may refuse the request
without
forfeiting its Bid Security. A Bidder granting the
request will not be required or permitted to modify its
Bid.
12.2. The Bidder shall furnish as part of its Technical Bid, a Bid
security in original form, and in the amount specified in the
BDS.
12.3. Pursuant to ITB 12.2, the Bid Security shall be a demand
guarantee, and in any of the following forms, at the Bidder‘s
option:
(a) an unconditional bank guarantee issued by any of the
banks mentioned in BDS;
(b) Bid Security in other forms, if specified in the BDS. In the
case of a bank guarantee, the Bank Guarantee for Bid
Security shall be provided by the Lead Consortium
Member/ Sole Bidder in the format prescribed in Form
6 included in Section 4, Bidding Forms - Technical
Proposal. The bid security shall be valid for 180 Days
beyond the end of validity period of the Bid specified in
ITB 12.1. This shall also apply if the period of the Bid
validity is extended.
Page 50 of 390
JPDCL
12.4. Any Bid not accompanied by a substantially responsive Bid

Security a specified, shall be rejected by the Utility as non-
responsive.
12.5. If the Bid Security from any Bidder is forfeited or lapsed
either partly or wholly during the Bid process, then such
Bidders and Consortium are liable for rejection.
12.6. Bid Security of unsuccessful Bidders shall be returned as
promptly as possible upon the successful bidder‘s signing the
contract and furnishing the Performance Security pursuant to
ITB 29.
12.7. The Bid Security of the Selected Bidder shall be returned
as promptly as possible once the ERPSI has signed the Contract
with the Utility and furnished the required Performance
Security.
12.8. The Bid Security may be forfeited if
1. the Bidder withdraws/ modifies/ substitutes its Bid during
the period of Bid validity as specified in ITB 12.1 or any
extension thereto provided by the Bidder;
2. bid is rejected for existence of conflict of interest, or more
than one bid being submitted by a Bidder;
3. bid submitted by a Consortium is not accompanied
by Consortium Agreement in the form provided in this RFP.
4. The Selected Bidder:
o fails to sign the ERPSI Contract; or
o fails to furnish a Performance Security in accordance
with RFP; or is found to have submitted false
particulars/ fake documents; or
o refuses to execute the work at its agreed scope/quoted
rates, after Utility issues the Letter of Award;
o is involved in incidents of manipulation of rates either
by cartelization or otherwise.
13. Extension of Proposal 13.1. Utility will make its best effort to complete the bidding
Validity process and award the contract prior to the date of expiry
of the Bid/ Proposal validity. However, should the need
arise, Utility may request, in writing, all Bidders who
submitted Bids/Proposals prior to the Bid Submission Deadline
to extend the Proposals‘ validity.
13.2. If the Bidder agrees to extend the validity of its Proposal, it
shall be done without any change in the original Proposal.
13.3. The Bidder has the right to refuse to extend the validity of
its Proposal in which case such Proposal will not be further
evaluated.
14. . Clarification and 14.1. Bidders may seek clarifications on this RFP in writing, through
Amendment of RFP a letter, fax, or email to reach Utility no later than the period
specified in BDS
14.2. Utility may issue clarification only, at its sole discretion, which
is considered reasonable by it.
14.3. Any such clarifications issued shall be sent to all the Bidders
to whom the RFP has been issued. Any such clarification shall
also be hosted on the website of the Utility and transmitted
through the e-Procurement System mentioned in ITB 2.1.
Page 51 of 390
JPDCL
14.4. Utility is not under any obligation to entertain/ respond

to suggestions made or to incorporate modifications sought for.
14.5. For the avoidance of any doubt, it is hereby clarified that
the Utility is not obliged to extend the Bid Submission
Deadline on account of clarifications sought by the bidder
14.6. During the bidding process, Utility, for any reason may modify
the RFP, including the timelines, by issuance of addendum /
modification / errata and / or a revised document.
14.7. Revisions or amendments in the bidding guidelines may cause
Utility to modify amend or supplement the RFP to be in
conformance with any applicable Law. Such document shall be
notified in writing through the e-
Procurement System mentioned in ITB 2.1, or letter or
fax or e-mail to all the entities who have downloaded the
RFP, and the same shall be binding on them.
14.8. Utility shall not be responsible for any delay in receipt of the
addendum/ modification/ errata and/ or revised document and
receipt of the same by the Bidders shall be presumed by Utility
upon taking all reasonable steps to notify the Bidders. Late
receipt of any addendum/ modification/ errata and/ or revised
document will not relieve the Bidder from being bound by that
modification or the Bid Submission Deadline. All such
amendments/modifications shall be issued at least 7(seven)
working days prior to the Bid Submission Deadline.
14.9. In order to provide reasonable time to the Bidders to take the
modification into account in preparing their Bid, or for any
other reasons, Utility may, at its discretion, extend the
deadline/ timeline for Bid submission
15. Preparation of Bid/ 15.1. The Bidder shall prepare its Bid and furnish required
Proposal and Bid information and documents as per the guidelines, formats,
Formats forms, schedules, fees, and other specification in this Section, as
well as the RFP Document in general.
15.2. Strict adherence to the formats/ forms, wherever
specified, is required. Wherever information has been sought
in specified formats, the Bidder shall refrain from referring to
brochures or pamphlets. Non-adherence to formats and/ or
submission of incomplete information may be a ground for
declaring the Bid as non-responsive. Each format must be
duly signed and stamped by the authorized signatory of the
Bidder.
16. Technical Bid/ 16.1. The Technical Bid/Proposal shall be prepared using the
Proposal Format and Forms provided in Section 4 of the RFP and shall comprise
Content the information, details and documents listed in subsequent
clauses herein The Technical Bid/ Proposal shall not include
any financial information. A Technical Proposal
containing material financial information shall be
declared non- responsive.
16.2. The Technical Bid shall contain the list of all participating
Consortium Members and Sub-contractor(s) (if applicable)
participating in the Bid as per the format prescribed in Form 1
given in Section 4. Furthermore, the Technical Bid shall
contain a covering letter by the Lead Consortium Member/
Page 52 of 390
JPDCL
Sole Bidder duly designated and signed by all Members of that

Bidding Consortium as per the format prescribed in Form 8
given in Section 4.
16.3. The Technical Bid shall contain a legally enforceable
Consortium Agreement (in case Bidder is a Consortium)
entered amongst all Members of that Bidding Consortium,
designating one of the Members to be the Lead Consortium
Member as per the format prescribed in Form 8 given in
Section 4. In the absence of a duly executed Consortium
Agreement, the Bid shall not be considered for evaluation and
will be rejected.
16.4. The Technical Bid shall contain Power of Attorney from each
Consortium Member in favour of the Lead Consortium
Member as per the format prescribed in Form 9 given in
Section 4. All submissions and representations by the Lead
Member shall be deemed to be on-behalf of the entire
consortium and shall be binding all the members of the
Consortium.
16.5. The Lead Consortium Member/ Sole Bidder shall designate
one person to represent the Bidding Consortium/ Bidder in its
dealings with Utility. The person designated by the Lead
Consortium Member/ Sole Bidder (registered Company) shall
be authorized through a Power of Attorney as per Form 10
given in Section 4 to perform all tasks including, but not
limited to, providing information, responding to inquiries,
signing of Bid on behalf of the Consortium, etc. and attach the
same in the Technical Bid.
16.6. The Technical Bid shall contain signed Letter of Consent as
per Form 11 given in Section 4 from each Consortium Member
that the Bid has been reviewed and each element of the Bid is
agreed to by them including but not limited to any commitment
in the Project.
16.7. The Technical Bid shall contain the Tender Fees and the Bid
Security as per the format prescribed in Form 6 given in
Section 4.
16.8. The Technical Bid shall contain all documents required to
prove/substantiate the Eligibility and Qualification
Requirements of the Bidders or the Bidding Consortium
specified in ITB 6.1 and Section 2 (as per the format
prescribed in Form 2 given in Section 4):
a) Company profile document with evidence of fields of
competence for each Consortium Member;
b) Attested copy of Certificate Registration/
Incorporation issued by the Registrar of Companies
for each Consortium Member/ Bidder
c) Certificate of Commencement of Business issued by the
Registrar of Companies for Lead Consortium Member/
Sole Bidder clearly indicating the number of years of
operation.
16.9. The Bidder shall submit a preliminary Project implementation
plan along with the Bid which shall include at least the
Page 53 of 390
JPDCL
following activities (as per the format prescribed in Form 3

given in Section 4).
16.10. In case of Award of the ERPSI Contract, the detailed Project
implementation plan, submitted as part of the Technical Bid,
shall be revised, and submitted by the ERPSI, in consultation
with the Utility, to ensure smooth takeover of existing Utility
systems and any ongoing Services under the scope of the ERP
Project.
16.11. The Technical Bid of the Bidder shall contain the indicative
List of Material and Services in the format prescribed in Form 13
as given in Section 4 without any mention of costs/ prices.
16.12. The List of Material and Services shall be accompanied by the
detailed specifications of the supply in the Technical Bid
demonstrating responsiveness of the quoted Solution. The
Bidder shall also indicate the country of origin of each
equipment in Form 14 as given in Section 4. For supply of
equipment / material from the country of origin other than
India, the bidder shall submit performance certificate in
support of satisfactory operation in India or a country other
than the country of origin having climatic and operational
conditions including ambient temperature similar to that of
India for more than number of years, indicated in BDS in
accordance with Order No. 11/05/2018-Coord. dated 17
September 2020 issued by the Ministry of Power including any
amendments or modifications to the same from time to time.
16.13. The Technical Bid of the Bidder shall contain the names and
details of the suitably qualified Bidder‘s representative and Key
Personnel to perform the ERPSI Contract as per the format
provided in Form 4 given in Section 4. The data on their
experience should be supplied using the Form 5 given in
Section 4 for each candidate proposed.
16.14. Any removal/ change/ replacement of Key Personnel
(as provided in Form 4 and 5 given in Section 4) shall be notified
to Utility within 7(seven) working days along with the
Curriculum Vitae (CV) of the personnel replacing the previous
personnel. The personnel replacing the previous key personnel
shall have equivalent or better educational qualification and
relevant professional experience
Note: Submission of the Technical Proposal in a materially wrong

format may lead to the Proposal being deemed non-responsive to
the RFP requirements.
17. Financial Bid/ Proposal 17.1. The Financial Proposal shall be prepared using the Forms
Format and Content provided in Section 5 of the RFP and shall comprise the
information, details and documents listed in subsequent clauses
herein.
17.2. The Financial Bid shall only be submitted electronically as per
the format prescribed in Section 5. No hard copy of the
Financial Bid shall be submitted. The Financial Bid shall include
the cost of different licenses that are required for installation,
cloud data centre facilities, data collection / digitisation /
migration to new platform, operational Go-Live, and
Page 54 of 390
JPDCL
maintenance of the Project and the person-day rate for

executing new requirement for software components. Price
quoted should clearly mention the basic cost/ unit price
including any other taxes/ duties/ levies, Goods and Service Tax
(GST). The Financial Bid will be evaluated basis the total cost
of the Project as quoted by the Bidder(s) for the Contract Period
in Form 1 given in Section 5.
17.3. Unit prices (exclusive of all taxes/ duties/ levies/ cess etc.) (as
provided in Section 5) quoted by the Bidder shall be firm and
final and shall remain constant throughout the Contract Period
and shall not be subject to any modifications.
17.4. Any items or prices omitted by the Bidder, if incurred at a
later stage by the Bidder, within the scope of work as provided
in the ERPSI Contract, shall be borne by the Bidder with no
financial liability on Utility.
17.5. Any scope of work required for expansions during the
Contract Period shall be supplied by the
ERPSI keeping the specifications and unit price
same as per the List of Material and Services (as provided in
Form 13 given in Section 4) and Financial Bid (as provided in
Section 5), respectively.
17.6. All prices in the Financial Bid shall be quoted in Indian
Rupees. The Bidder shall bear the risk related to foreign
exchange variations during the Contract Period. The variation in
the statutory taxes will be in accordance with the ERPSI
Contract.
17.7. Alternative (alternate technology/
architecture/ design/ functionality or proposals with
multiple options) Bids shall be rejected.
C. Submission, Opening and Evaluation

18. Submission of Bids/ 18.1. Both Technical Bid and Financial Bid shall be digitally signed
Proposals and Bid and submitted electronically using the e-Procurement system
Submission Deadline indicated in ITB 2.2 on or before the Bid Submission
Deadline following the instructions therein. All the documents
shall be scanned and uploaded however, where the data is
required to be entered manually, the same shall be entered
accordingly by the Bidder.
(a) Submission of Bids/
18.2. Requisite Tender Fee and Bid Security in the specified form/
Proposals
instrument shall be submitted in original so as reach after
(b) Bid Submission the Bid Submission Deadline and before bid opening date as
Deadline mentioned in the RFP, failing which the Bid shall be deemed
non-responsive.
18.3. In addition to the electronic submission and submission of
Tender Fee and Bid Security in the specified form/ instrument
in original as per ITB 18.2, if so, specified in BDS, the Bidder
shall also provide certain document in
original/ hard copy/(ies) of the original/ revised (if any) in a
sealed envelope after the Bid Submission Deadline and before
bid opening date as mentioned in the RFP
18.4. The hard copies to be submitted in original and/ or attested
as may be specified in BDS.
Page 55 of 390
JPDCL
18.5. The hard copy of the document as per ITB 18.2 and ITB 18.4
above shall be sent in a sealed envelope to Utility via
Registered Post with Acknowledgement Due (RPAD), speed
post or courier in the manner specified in ITB 17.4.3, which
should reach Utility after the Bid Submission Deadline and
before the bid opening date as mentioned in the RFP
18.6. The sealed envelope shall be clearly marked on the top with
details mentioned in BDS. The sealed envelope shall be
addressed to the Utility as specified in BDS. The sealed
envelope shall also clearly mention the name of the Lead
Consortium Member/ Sole Bidder submitting the Bid.
18.7. The sealed envelope shall not contain the Financial Bid. The
Financial Bid shall only be submitted electronically.
18.8. In case of discrepancy between the electronically submitted
documents and the physically submitted documents in the
sealed envelope, the electronically submitted documents and
the information contained therein shall prevail and be treated
as the final submission.
18.9. Insufficiency of the electronically submitted Bid shall not be
compensated by any information, documentation or material
provided additionally in the physically submitted documents
in the sealed envelope
18.10. All Bids shall be electronically submitted as may be
specified in this Section, by Utility no later than the Bid
Submission Deadline indicated in BDS as may be extended
from time to time by the Utility.
18.11. Bidders may prepare, edit, substitute, or withdraw their offers
any number of times online before the Bid Submission
Deadline as may be permitted by the e-Procurement system.
After the Bid Submission Deadline, the Bidder shall not, or
attempt to, change, or withdraw the
Bid under any circumstances. No written or online
request in this regard shall be entertained.
18.12. Any Bid received by Utility, either
electronically or physically, after the Deadline prescribed
by Utility will not be uploaded and accordingly be rejected.
In case of hard copy submissions, late Bids shall be returned
unopened to the Bidder.
18.13. Utility may, at its discretion, extend this Bid Submission
Deadline by amending the RFP at any time prior to opening of
the Bids, in which case all rights and obligations of Utility
and the Bidders shall thereafter be subject to the deadline as
extended.
18.14. Any Proposal or its modification received by Utility after the
deadline through any means or medium, whatsoever, shall be
declared late and rejected, and promptly returned unopened.
19. Confidentiality 19.1. Information relating to the examination, evaluation,
comparison, and recommendation of ERPSI Contract award,
shall not be disclosed to Bidders or any other persons not
officially concerned with such process.
19.2. Any attempt by a Bidder to influence Utility in the
examination, evaluation, comparison, and post qualification
of the Bids or ERPSI Contract award decisions may result in the
rejection of its Bid.
Page 56 of 390
JPDCL
19.3. If any Bidder, from the time of opening the Technical Bids to
the time of ERPSI Contract award, wishes to contact Utility on
any matter related to the bidding process, it should do so in
writing.
20. Opening of Technical 20.1. The Technical Bids shall be opened online or at the date and
Bids/ Proposals time, and the address indicated BDS. In case hard copy
submission of Technical Bid or certain document is requested
by the Utility as per ITB 18 the physically submitted
Technical Bids/ documents in the sealed envelope shall be
opened simultaneously to check inter alia
requisite submissions and for the Tender Fees and the Bid
Security.
20.2. The Bids shall be deemed to be under consideration
immediately after they are opened and confirmation or
receipt of the Tender Fee and Bid Security, and until an
official intimation of award or rejection is made by Utility to
the Bidders.
20.3. Utility shall then separately evaluate the Bids with respect to
the Eligibility and Qualification Requirements, sufficiency of
the submission, conformation/ compliance/ responsiveness to
all the mandatory requirements, terms, conditions, and
specifications of the RFP Document without any deviation,
reservation, or omission, and other parameters outlined in
this RFP.
20.4. The Financial Proposal shall remain unopened in the e-
Procurement/ e-Tendering system securely, until they are
opened in accordance with ITB 23.
20.5. At the opening of the Technical Proposals the following shall
be published on E-proc portal: (i) the name of the Bidder; (ii)
any modifications to the Proposal submitted through the e-
Procurement/ e-Tendering system prior to
proposal submission deadline; and (iii) any other information
deemed appropriate.
21. Bid/ Proposals 21.1. The bidding process is designed to select the ERPSI through a
Evaluation Overview series of assessment of: (i) conformation/ compliance to all
and Verification/ the mandatory requirements under applicable laws and this
tender, terms, conditions, and specifications of the RFP
Clarifications
Document without any material deviation, reservation, or
omission; and (ii) the financial amounts quoted by the
Bidder. The Bid submitted by the Bidder shall consist of a
Technical Bid and a Financial Bid.
First Stage-Fulfilment of Eligibility and Qualification

Requirements and determination of substantial
responsiveness to the RFP Documents: The Technical Bids
shall be opened by Utility and be checked to determine (i)
whether the Bidders comply with the
Eligibility Requirements, have offered eligible ERP system
requirements and modules in their Bids, as specified in ITB
6.1 and Section 2; (ii)whether the Bidders meet the
Qualification Requirement specified in ITB 6.2 and Section 2;
Page 57 of 390
JPDCL
(iii) whether the Bids are substantially responsive to the

RFP document including the requirements specified in
Section 7 basis ‗Clause by Clause‘ compliance to the RFP
Document including the technical specifications and
functional requirements (with amendments, if any) as per the
format prescribed in Form 14 given in Section 4
Second Stage-Opening of Financial Bid: Financial Bids of all

technically qualified Bidders would be opened, basis
which the award of ERPSI Contract shall be determined.
Third Stage-Award of Project: The ―Successful Bidder as

defined in ITB 26 shall be awarded the ERPSI Contract.
21.2. The Bidder is not permitted to alter or modify its Bid/
Proposal in any way after the Bid Submission Deadline.
21.3. Utility‘s determination of the responsiveness of a Bid/
Proposal is to be based on the contents of the Proposal itself
including any response to clarifications sought by Utility
which does not alter the substance of the Proposal or the
price.
21.4. A substantially responsive Bid/ Proposal is
one that conforms to all the mandatory
requirements, terms, conditions, and specifications of the
RFP Document without any material deviation, reservation, or
omission, as defined in
ITB 25.
21.5. The Contract, if awarded, shall be executed in accordance
with RFP document and any other conditions.
21.6. Notwithstanding anything stated in the RFP Document,
Utility reserves the right to verify the authenticity of the
documents submitted for meeting the eligibility, qualification
and/or other specified requirements and may request for
clarifications any additional information/ documents from the
Bidder. However, the Bidder shall not be permitted to alter
the substance of the Proposal or the price under any
circumstances whatsoever
21.7. Utility reserves the right at its sole discretion to contact the
Bidder‘s bank, lenders, financing institutions and any other
persons as necessary to verify the Bidder‘s
information/documents for the purpose of
eligibility, qualification and/ or other specified requirements.
21.8. Utility may verify the Bidder‘s technical and financial data by
checking with the Bidder‘s clients/ lenders/ bankers/ financing
institutions/ any other person as necessary.
21.9. To assist in the examination, evaluation, comparison and
post-qualification of the Bids, Utility may, at its discretion,
ask any Bidder for a clarification of its Bid. Any clarification
submitted by a Bidder that is not in response to a request by
Utility shall not be considered. Utility
request for clarification and the response shall be in writing.
No change in the prices shall be sought, offered, or permitted
by Utility in the evaluation of the Financial Bids
Page 58 of 390
JPDCL
22. Evaluation of 22.1. All Bids will first be evaluated for Clause by Clause‘
Technical Bids/ compliance to the RFP document and the ERPSI Contract
Proposals including the technical specifications and
functional requirements (with amendments, if any) as
per the format prescribed in Form 14 given in Section 4.
The Bidders fulfilling the Eligibility and Qualification
Requirement and having submitted substantially responsive
Bids conforming to and meeting all the mandatory
requirements, terms, conditions, and specifications of the
RFP Document without any material deviation, reservation, or
omission, as defined in
ITB 25, shall qualify for the opening of Financial Bid.
22.2. In the event the Technical Bid is substantially responsive,
Utility may waive any deviation, reservation, or omission in the
Bid as defined in ITB 25.1
22.3. Provided that a Technical Bid is substantially responsive,
Utility may request that the Bidder submit the necessary
information or documentation, within a reasonable period of
time, to rectify nonmaterial, nonconformities or omissions in
the Technical Bid related to documentation requirements.
Such omission shall not be related to any aspect of the price
Bid. Failure of the Bidder to comply with the request may
result in the rejection of its Bid.
23. Opening of Financial 23.1. At the completion of the technical evaluation, Utility shall
Proposals intimate the technically qualified Bidders for opening of
Financial Bids, along with the date, time of opening of
Financial Bids either online or at a venue/online joining link
intimated by the Utility.
23.2. The Financial Bids shall be opened
through the e- Procurement system referred to in ITB 2.2,
in the presence of authorized representatives of all technically
qualified Bidders who chose to attend the online bid opening
on the specified date and time.
24. Evaluation of Financial 24.1. Provided that the Technical Bid is substantially responsive,
Bids/ Proposals Utility will correct arithmetical errors during evaluation of
Financial Proposals on the following basis:
i. 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 Utility 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;
ii. 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;
iii. if there is a discrepancy between words and figures,
the amount in words shall prevail. However, where the
amount expressed in words is related to an arithmetic
error, the amount in figures shall prevail subject to (i) and
(ii) above. Except as provided in (i) to (iii) herein above,
Page 59 of 390
JPDCL
Utility shall reject the Financial Bid if the same contains

any other computational or arithmetic discrepancy or
error.
25. Deviations, 25.1. During the evaluation of Bids/ Proposals, the following
Reservations and definitions apply:
Omissions
(a) Deviation is a departure from the requirements specified
in the RFP document;
(b) Reservation is the setting of limiting
conditions or withholding from complete acceptance
of the requirements specified in the RFP document; and
(c) Omission is the failure to submit part, or all of the
information or documentation required in the RFP
document.
25.2. A substantially responsive Bid is one that meets the

requirements of the bidding document without material
deviation, reservation, or omission. A material deviation,
reservation, or omission is one that:
(a) if accepted, would:
(i) affect in any substantial way the scope, quality, or

performance of the Goods and Related Services
specified in the Contract; or
(ii) limit in any substantial way, inconsistent with the
bidding document, the Utility‘s rights, or the Bidder‘s
obligations under the Contract; or
(b) if rectified, would unfairly affect the competitive position of

other Bidders presenting substantially responsive Bids.
26. Successful / Selected 26.1. The price as per the Financial Proposal/ Bid of all technically
Bidder qualified Bidders, determined upon evaluation of Financial
Proposals/ Bids, shall be the basis for determination of the
Successful Bidder/ Selected Bidder.
26.2. The technically qualified Bidder with the lowest Financial
Bid shall be considered as the Successful Bidder/ Selected
Bidder and shall be considered for award of the ERPSI
Contract.
26.3. If the Successful Bidder/ Selected Bidder does not accept the
correction of errors as per ITB 24.1, its Bid shall be
disqualified, and its Bid Security shall be forfeited.
D. Award of Contract
27. Award Criteria 27.1. Subject to ITB 26.3, the Utility shall award the Contract to the
Successful Bidder/ Selected Bidder.
27.2. Utility shall present the Letter of Award (as per the format
prescribed in Form 2 given in Section 8) to the Successful Bidder
and invite the Performance Security in order to sign the ERPSI
Contract to implement the Project
27.3. The Successful Bidder shall provide an undertaking that the
key staff identified for the Project (as submitted in its
Technical Bid) shall be available for the respective proposed
Page 60 of 390
JPDCL
work requirement, anytime during the duration of the Project,

till its successful completion
27.4. If for any reason the Bid of the Successful Bidder is rejected or
Letter of Award issued to the Successful Bidder is cancelled,
Utility is empowered to take decisions for any of the following:
(a) Consider the next lowest evaluated Bid from eligible and
qualified Bidder whose bid is determined
substantially responsive; or
(b) Annul the Bid process; or
(c) Take any such measure as may be deemed fit in the sole
discretion of Utility, as applicable.
28. Utility’s Right to Vary 28.1. Utility reserves the right to increase or decrease the number
Quantities at the time of items as per BoQ under the ERPSI Contract subject to the
of Award limit of - 20% (twenty percent) up to +20% (thirty percent) of the
existing number of items as per BoQ (as provided in Section 5),
covered under the ERPSI Contract, without any change in the
unit prices or other terms and conditions of the ERPSI
Contract and the Bid
29. Letter of Award 29.1. Prior to the expiry of the period of Bid validity, Utility shall
notify the successful Bidder, in writing, by issuing the Letter of
Award, that its Bid has been accepted.
29.2 Until the ERPSI Contract is prepared and executed, the
notification of award shall constitute a binding contract
30. Signing of Contract 30.1. Within 15 Days of receipt of the Letter of Award, the
and Contract successful Bidder shall sign the ERPSI Contract.
Performance Security
30.2. Within 21 (twenty-one) Days of the receipt of Letter of Award
from Utility, the Successful Bidder shall
furnish the Performance Security, for an amount
equivalent to three percent (3%) (or as per CVC guidelines
applicable at the time) of the Contract Price (final price after the
negotiation (if any)), using for that purpose the format of
Performance Security given in Form 1 in Section 8. Immediately
upon furnishing of Performance Security, ERPSI may request
the Utility to execute the ERPSI Contract.
30.3. Validity: Valid for the entire Project term. The BG shall be
released after 4 years and 2 months from the Effective Date of
Go-Live of the Enterprise Resource Planning Solution or
execution of all pending Work Orders, whichever is later.
30.4. Instrument: One single deposit in the form of Bank Guarantee.
30.5. In the event of termination, Purchaser may Invoke the

Performance Bank Guarantee, recover such other direct costs
and other amounts towards direct damages from the bidder that
may have resulted from such default and pursue such other
rights and/or remedies that may be available to the Purchaser
under law.
Page 61 of 390
JPDCL
30.6. Failure of the Successful Bidder to submit the above-

mentioned Performance Security or sign the ERPSI Contract
shall constitute sufficient grounds for the annulment of the
award and forfeiture of the Bid Security. In that event Utility
may award the ERPSI Contract to the next lowest Bidder
E. Bid Data Sheet
Bid Data Sheet
ITB Reference A. General Provisions
1.1 (v) Name of the RFP: Selection of System Integrator (ERPSI) to Design, Develop,
Implement and Maintain Enterprise Resource Planning (ERP) Solution on
Cloud
Tender/RFP Reference No. and Date: 07 of 2023-2024 19/09/2023
1.1 (ee)
About JPDCL
Post unbundling of Power Development Department, JPDCL is mandated with
Development and Management of Electric Power Supply at Sub-Transmission
and Distribution level in Jammu region of UT of J&K. JPDCL performs following
functions:
• Development of Electric Power Supply infrastructure at Sub-
Transmission and Distribution Level
• Distribution of Electric Power Supply to the people of Jammu region
• Maintenance of Electric Power Supply at Sub-Transmission and
Distribution Level
Electricity plays an important role in socio-economic development of the
region, by ensuring adequate and good quality electric power supply JPDCL
plays an important role in wholistic development of Jammu Region. JPDCL is
committed to serve the electric energy needs of the region in general and
people in particular.
2.2
Bidding against RFP shall be conducted through/ with Electronic –
Procurement (e- Procurement/ e- Tendering) System. Utility shall use the
following Electronic-Procurement system to manage this Request for
Proposal (RFP) process:
www.jktenders.gov.in
The electronic-procurement system shall be used to manage the following

part of the RFP process like issuing RFP, corrigendum/ addendums,
submissions of Proposals, opening of Proposals etc.
To aid and facilitate the Bidders on e-Procurement/ e-Tendering process a

detailed manual on the same titled Bidder Help Manual for e-Bidding has
been provided annexed to the Bid Data Sheet as Annexure <No.>. The same
may be utilized by the Bidders.
2.2.2 Executive Engineer-IT & C Division, Gladni Grid Station Complex, Narwal,
Jammu-180006 (J&K)
Page 62 of 390
JPDCL
Email: xenitjpdcl@gmail.com
2.3 Design, Develop, Implement and Maintain Enterprise Resource Planning

(ERP) Solution on Cloud
2.4
Kindly refer to the Section 6 Point No. 2 Current State of the System
2.6
A Pre-Bid Meeting will be held as per the details below.
Executive Engineer, IT&C Division, Jammu Power Distribution Corporation
Limited (JPDCL), Gladni Grid Station Complex, Narwal, Jammu-180006 (J&K)
through VC
Kindy refer Section 1 Request for Proposal table of important dates
2.8 Kindy refer to the Section 3 : Annexure – I Format for Request for
Clarification / Pre-bid queries for Format for Sending Query to Utility
ITB Reference B. Preparation of Proposals
10.1 Kindy refer to the Section 3 Annexure – II Document Checklist and List of
Forms
12.1 The Bid shall remain valid until i.e. up to and including 180 days reckoned
from the Bid Submission Deadline, as may be extended by the Utility.
12.2 Currency and the amount of Bid Security to be furnished by the Bidder is:
• Rupees Forty-Four Lacs only (INR 44,00,000/-)

• The Bid Security to be furnished in Indian Rupees (INR) only
12.3(a) Banks by whom Bank Guarantee is required to be issued:
Bid Security has to be made in the form of Bank Guarantee from any
Scheduled Commercial Bank / Nationalized Bank drawn in favour of “The
Managing Director, Jammu Power Distribution Corporation Limited (JPDCL)”,
payable at Jammu equivalent
12.3(b) Bid Security may be furnished in other forms mentioned below:
To be furnished by the lead bidder by submitting in the shape of CRD/FDR,

BG or Demand Draft from any Scheduled Commercial Bank/ Nationalized
Bank drawn in favor of “The Managing Director, Jammu Power Distribution
Corporation Limited (JPDCL)”, payable at Jammu and valid for a period of
minimum 180 days.
Account details for the purpose of EMD and Performance Guarantee:
Bank Name: J&K bank, Branch Rail Head Jammu
Beneficiary Name: Managing Director, Jammu Power Distribution
Corporation Limited (JPDCL)
IFSC Code: JAKA0ERAILH
Account No: 0022040510000001
Page 63 of 390
JPDCL
14.1 • Queries must be submitted in the format mentioned in Annexure – I

Format for request for Clarification / Pre-bid queries
• JPDCL shall not respond to any queries not adhering as per the format
mentioned in Annexure – I Format for request for Clarification / Pre-bid
queries
• All queries on the RFP should be received on or before as prescribed in
the Section 1 Request for Proposal table of important dates
16.12 Not Applicable
ITB Reference C. Submission, Opening and Evaluation
18.3 The following documents shall be submitted in original:
Bidder shall submit original ‘Cost of Tender Document in the form of

Demand Draft’, ‘EMD in the form of Refundable & Irrevocable Bank
Guarantee’, ‘Form19: Conflict of Interest’, ‘Form 9 and Form 10: Power of
Attorney executed in favour of the Authorized Signatory’ and ‘Form 20: Pre-
contract Integrity Pact’ after the last date of online submission of bids and
before opening of Bids.
The bidder shall mark its name and tender reference number on the back of
the Demand Draft before sealing the same. The address of JPDCL, name and
address of the bidder and the Tender Reference Number shall be marked on
the envelope. The envelope shall also be marked with a sentence “NOT TO
BE OPENED BEFORE the Date and Time of Bid Opening”. If the envelope is
not marked as specified above, JPDCL shall not assume any responsibility for
its misplacement, pre-mature opening etc.
18.4 Not Applicable
18.6 Details to be marked on the sealed envelope:

• RFP No.
• RFP Name
• Bid Submission Deadline
• Time and Date of Bid Opening,
• Name and address of the Lead Consortium Member/ Sole Bidder
submitting the Bid
• The envelope shall also be marked with a sentence “NOT TO BE
OPENED BEFORE the Date and Time of Bid Opening”.
Sealed Envelope(s) to be addressed to:

Executive Engineer-IT & C Division, Gladni Grid Station Complex, Narwal,
Jammu-180006 (J&K)
18.10 Kindy refer Section 1 Request for Proposal Notice for important dates
related to bid submission and opening
20.1 Kindy refer Section 1 Request for Proposal Notice for important dates
related to bid submission and opening
Page 64 of 390
JPDCL
Page 65 of 390
JPDCL
Annexure – I Format for request for Clarification / Pre-bid queries

Bidders requiring specific points of clarification may submit queries through email
xenitjpdcl@gmail.com in MS excel ( strictly as per below format ) documents only using the following
format:
Bidder’s Request for clarification / pre-bid queries
Name of Organization submitting Name & position of person Full address of the
request submitting request Organization including
phone, fax and email
points of contact
Tel:
Fax:
Email:
Content of RFP Justification

S. RFP requiring for Changes
RFP Clause RFP Page Clarification
Section Clarification requested
No number No. Required
number
( if any)
*queries should be sent in MS excel ( strictly as per above format ) document only.
Note:
• The name of the organization and the date shall appear in each page of such as
document/email in the header or footer portion.
• Bidders who have purchased the Tender/RFP document shall only be allowed to attend Pre-
Bid Meeting. Attending Pre-Bid Meeting is optional.
• Pre-bid queries of ERPSIs who have not purchased the Tender/RFP document shall not be
entertained
Page 66 of 390
JPDCL
Annexure – II Document Checklist and List of Forms

This Checklist shall be filled in and submitted by the bidder along with the Eligibility Criteria and
Technical Bid. Except Financial Bid as per format provided given in Section 5 (to be completed and
submitted by the Bidder in the Financial Bid) all other documents/ forms duly filled and complete in
all respect are to be submitted by the Bidder in the Technical Bid
Proposal Reference
S. RFP Section
Document (to be filled by the
No. Reference
Bidder)
1. Tender Fee 1,3
2. EMD Fee as per Format 6 given in the Section 4 / 1,4
Proof of EMD payment
3. List of Consortium Members and Subcontractor(s) 4
(as applicable) as per the format prescribed in Form
1 given in Section 4
4. Bidder Information as per the format prescribed in
4
Form 2 given in Section 4
5. Project Implementation Plan as per format provided
4
in Form 3 given in Section 4
6. Curriculum Vitae of key personnel as per format
4
provided in Form 4 and Form 5 given in Section 4
7. Bid Security in the form of Demand Draft or Bank
Guarantee as per format prescribed in Form 6 given 4
in Section 4
8. Covering Letter for Submission of Bid by Sole Bidder
/ Lead Consortium Member as per format prescribed 4
9. Consortium Agreement Format entered amongst
both Members of the Bidding Consortium as per 4
format prescribed in Form 8 given in Section 4
10. Power of Attorney by ERPSI – 2nd in favour of ERPSI-
Lead as per format prescribed in Form 9 given in 4
Section 4
11. Power of Attorney by ERPSI-Lead/ Sole Bidder
authorizing an Individual Designated Representative
4
for the Consortium/ Bidder as per the format
prescribed in Form 10 given in Section 4
12. Letter of Consent by each Consortium Member
reviewing each element of the Bid as per format 4
prescribed in Form 11 given in Section 4
13. For ERPSI-Lead in case of Consortium Bidding / Sole
Bidder Experience:
i. References along with requisite contract/
Purchase Order (PO)/ Work Order (WO). The
references should indicate client name,
2,4
scope of work, Project start date (as per the
format prescribed in Form 12 given in
Section 4);
ii. Documentary evidence of Project
completion such as client completion
Page 67 of 390
JPDCL
Proposal Reference
S. RFP Section
No. Reference
Bidder)
certificate, proof of payment received and
client certificate of delivery of material,
proof of asset capitalized in books of
accounts (as applicable)/ and similar proofs
along with contact details of the client.
14. For System Integration Experience:
I. References along with requisite contract/
Purchase Order (PO)/ Work Order (WO). The
references should indicate client name, scope
of work, Project start date (as per the format
prescribed in Form 12 given in Section 4);
II. Documentary evidence of completion of the
Project or completion of Go-Live status (i.e.,
2,4
Go-live certificate, UAT testing certificate
etc.) or other documentary evidence
indicating completion (e.g., proof of payment
received and client certificate for supply of
material or similar proofs) along with contact
details of the client;
III. Client certificate and other documentation
for implementation performance/ operation
15. List of Material and Services as per format provided
4
16. Table of Compliance as per format provided in Form
4
14 given in Section 4
17. Turnover and Net worth Certificate as per format
provided in Form 15 given in Section 4 along with
Audited Annual financial statements, Balance Sheet 2,4
and P&L Account of all Consortium Members/ Sole
Bidder for the respective Financial Years
18. Discloser of court cases as per format provided in
4
Form 16 given in Section 4
19. Undertaking on Change Request (Company Letter
Head) as per format provided in Form 17 given in 4
Section 4
20. Undertaking of for non-blacklisting as per format
2,4
provided in Form 18 given in Section 4
21. Conflict of Interest (Company Letter head) as per
4
format provided in Form 19 given in Section 4
22. Pre-contract Integrity Pact (To be executed on a non-
judicial as per format provided in Form 20 given in 4
Section 4
23. Performance Security as per the format prescribed
8
24. Copy of this RFP with sign and official seal on every
1 to 8
page
25. Financial Bid as per format provided in Form 1 given
5
in Section 5
Page 68 of 390
JPDCL
Proposal Reference
S. RFP Section
No. Reference
Bidder)
26. Any other document -
Page 69 of 390
JPDCL
Section 4. Bidding Forms- Technical Proposal

Table of Contents
Section 4. Bidding Forms- Technical Proposal .............................................................................................. 71
Form 1: List of Consortium Members/ Sub-Contractor(s) ........................................................................... 71
Form 2: Bidder Information ......................................................................................................................... 72
Form 3: Project Implementation Plan .......................................................................................................... 73
Form 4: Bidder’s Representative and Key Personnel ................................................................................... 74
Form 5: Resume and Declaration................................................................................................................. 75
Form 6: Format of Bank Guarantee for Bid Security .................................................................................... 77
Form 7: Format of Covering Letter by ERPSI-Lead/ Sole Bidder for Submission of Bid ............................... 79
Form 8: Format of Consortium Agreement to be entered amongst all Members of a Bidding Consortium
..................................................................................................................................................................... 82
Form 9: Format of Power of Attorney by ERPSI-2nd in favor of ERPSI-Lead ............................................... 86
Form 10: Format of Power of Attorney by ERPSI-Lead / Sole Bidder authorizing an Individual Designated
Representative ............................................................................................................................................. 89
Form 11: Format of Letter of Consent by Sole Bidder/ ERPSI-Lead reviewing each element of the Bid ..... 91
Form 12: Record of Similar Work Done ....................................................................................................... 93
Form 13: List of Material and Services ......................................................................................................... 94
Form 14: Table of Compliance ................................................................................................................... 101
Form 15: Turnover and Net worth Certificate ........................................................................................... 102
Form 16: Format for court cases................................................................................................................ 103
Form 17: Undertaking on Change Request (Company Letter Head) ......................................................... 104
Form 18: Undertaking of for non-blacklisting ............................................................................................ 105
Form 19: Conflict of Interest (Company Letter head) ................................................................................ 106
Form 20: Pre-contract Integrity Pact (To be executed on a non-judicial stamp paper of INR 100/-) ........ 107
Page 70 of 390
JPDCL
Section 4. Bidding Forms- Technical Proposal

Form 1: List of Consortium Members/ Sub-Contractor(s)
Major Project Item Proposed Consortium Member / sub- Nationality
Contractor
System Integrator (Lead)
System Integrator (2nd)

ERP OEM Subcontractor
(Not a consortium member)
Cloud Service Provider (CSP) /
Managed Service Provider (if any)
Subcontractor (Not a
consortium member)
Data Digitization Agency (if any)
Subcontractor
[Other] (if any)
Page 71 of 390
JPDCL
Form 2: Bidder Information

Sole Bidder/ all Consortium Members must provide all documents required to prove/ substantiate
its Eligibility as required in Eligibility Criteria Clause for each Consortium Member
S. No Information Requirement Details
1. Company Name and Details
2. Address of its place of business in India
3. List of board of directors or regulating/controlling body
4. Attested copy of Certificate of Registration/

Incorporation issued by the Registrar of Companies
5. Certificate of Commencement of Business issued by the

Registrar of Companies
6. Copy of the Goods and Services Tax (GST) Registration

Certificate
7. Provident Fund (PF) Certificate indicating PF Code
8. Copy of Permanent Account Number (PAN) Card
9. CA certified audited annual financial statements and

positive financial Net worth for the last three years
Page 72 of 390
JPDCL
Form 3: Project Implementation Plan

The Bidder shall submit a preliminary Project implementation plan along with the Bid which shall
include at least the following activities:
1. Site Survey;
2. Understanding of Utility and its requirement with respect to Project implementation;
3. Overall system architecture (incl. Cloud Services if applicable), configuration, and
customization;
4. Approach towards data privacy and cyber security;
5. Details of proposed roll out and testing methodology along with data migration plan;
6. Approach paper documenting the interfaces for integration with existing and future
applications based on the information provided by utility;
7. Project team structure;
8. Work Plan
9. Staffing Schedule
10. Quality Assurance Program;
11. Training Schedule,
12. Change Management Plan
13. Documentation
14. Go-Live Plan
15. Exit Management and Knowledge Transfer Plan
Page 73 of 390
JPDCL
Form 4: Bidder’s Representative and Key Personnel

Relevant
Overall
Name of Experience In Compliance
S. No. Role Qualification Experience
Resource respective role (Yes / No)
(Years)
(Years)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Page 74 of 390
JPDCL
Form 5: Resume and Declaration
1. Proposed Position
2. Name of Firm
3. Name of Expert
4. Citizenship
5. Education
Membership in Professional
6. Associations (Professional
Certifications)
7. Countries of Work Experience
Language Skills Language Read Write Speak
(mark Excellent/ Good/ Average) English
Hindi
<Add language>
8. Employment Records
From: To:
Employer:
Position Held:
From: To:
Employer:
Position Held:
From: To:
Employer:
Position Held:
From: To:
Employer:
Position Held:
9. Work Undertaken That Best Illustrates Capability to handle the tasks assigned
Project Name
Year
Location
Client
Main project Features
Position Held
Activities Performed:
Page 75 of 390
JPDCL
Expert’s contact information

e-mail:
Phone:
Certification:
I, the undersigned, certify that to the best of my knowledge and belief that
• This CV correctly describes my qualifications and my experience
• I was not part of the team who wrote the Scope of Work for this RFP
• I understand that any wilful mis-statement described herein may lead to my disqualification
or dismissal, if engaged
• I confirm that I am available as certified in the following table and throughout the expected
time schedule for this position as provided in the Bid:
Commitment Details
Commitment to duration of contract: [insert period (start and end dates) for which this
Representative or Key Personnel is available to work on
this contract]
Time commitment: [insert period (start and end dates) for which this
Representative or Key Personnel is available to work on
this
contract]
Name of Expert: Signature Date:
Countersignature of authorized representative of the Bidder:
Signature
Date:
Page 76 of 390
JPDCL
Form 6: Format of Bank Guarantee for Bid Security
[To be on non-judicial stamp paper of Rupees One Hundred Only (INR 100/-) or appropriate value as
per Stamp Act relevant to place of execution, duly signed on each page.]
Reference No. ……………. Bank Guarantee No. ……………. Dated:
To,
The Managing Director
SERC Building, B.R. Ambedkar Chowk, Rail Head Complex, Jammu – 180006
Dear Sir/ Madam,
WHEREAS……………………… [Insert name of the Sole Bidder/ERPSI-Lead] with address …………….

[Insert address of Sole Bidder /ERPSI-Lead] having its registered
office at ……………. [Insert address of the Sole Bidder /ERPSI-Lead] (Hereinafter, the ―Bidder )
wishes to participate in Tender No. [Tender Details] (the ―RFP ) issued by JPDCL (hereinafter, the
―Utility) for Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain
Enterprise Resource Planning (ERP) Solution on Cloud.
And WHEREAS a Bank Guarantee for [Amount] valid [Date] is required to be submitted by the
Bidder along with the RFP.
In consideration of the [details of the Bidder] agreeing to undertake the obligations under the [insert
details of the bid document], we, …………….[Insert name of the Bank and address of the Branch
giving the Bank Guarantee] having our registered office at …………….[Insert address of the
registered office of the Bank] (Guarantor Bank) hereby give this Bank Guarantee No.
…………….[Insert Bank Guarantee number] dated …………….[Insert the date of the Bank
Guarantee], and hereby agree unequivocally, irrevocably and unconditionally to pay immediately
on demand in writing from the Utility any officer authorized by it in this behalf any amount not
exceeding [Amount] to the said Utility on behalf of the Bidder.
We, [Insert name of issuing bank] do hereby undertake to pay the amounts due and payable under
this bank guarantee without any demur, protest, dispute or any inquiry. Any such demand made
on the Guarantor Bank, shall be conclusive as regards the amount due and payable by the Guarantor
Bank under this bank guarantee. Our liability under this present being absolute and unequivocal.
The Guarantor Bank hereby expressly agrees that it shall not require any proof of the terms of
the [bid documents] or the occurrence of any event specified thereunder and shall make the
payment to the Utility immediately on the written demand from the Utility, made in any format,
raised at the above- mentioned address of the Guarantor Bank.
Page 77 of 390
JPDCL
We ……………. [Insert name of the Bank] also agree that withdrawal of the Bid or part thereof by the
Bidder within its validity or non-submission of Performance Security by the Bidder within the
stipulated time of the Letter of Award to the Bidder or any violation to the relevant terms stipulated
in the RFP would constitute a default on the part of the Bidder and that this Bank Guarantee is liable
to be invoked and encashed within its validity by the Utility in case of any occurrence of a
default on the part of the Bidder and that the amount is liable to be forfeited by the Utility.
This Guarantee shall be valid and binding on this Bank up to and inclusive of ……………. [Insert the date
of validity of the Bank] and shall not be terminable by notice or by Guarantor by reason of
merger, amalgamation, restructuring, liquidation, winding up, dissolution or change in the
constitution of the Bank or the firm of the Bidder Or by any reason whatsoever and our liability
hereunder shall not be impaired or discharged by any extension of time or variations or
alternations made, given, conceded with or without our knowledge or consent by or between the
Bidder and the Utility.
NOTWITHSTANDING anything contained hereinbefore, our liability under this guarantee is

restricted to [Amount]. Our Guarantee shall remain in force till [Date]. Unless demands or claims
under this Bank Guarantee are made to us in writing on or before [Date], all rights of the Beneficiary
under this Bank Guarantee shall be forfeited, and we shall be released and discharged from
all liabilities there under.
[Insert the address of the Bank with complete [Insert signature of the Bank’s Authorized
postal branch code, telephone and fax Signatory]
numbers, and official round seal of the Bank]
Attested
……………………………. [Signature]
(Notary Public)
Place: …………………………. Date: …………………………….
INSTRUCTIONS FOR SUBMITTING BANK GUARANTEE

1. Bank Guarantee to be executed on non-judicial stamp paper of appropriate value as per Stamp
Act relevant to place of execution.
2. The Bank Guarantee by Bidder shall be given from any Scheduled Commercial Bank.
3. The full address along with the Telex/Fax No. and e-mail address of the issuing bank to be
mentioned.
Page 78 of 390
JPDCL
Form 7: Format of Covering Letter by ERPSI-Lead/ Sole Bidder for Submission of

Bid
To,
Sub: Bid for Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain
Ref: [Tender Details]
Dear Sir/ Madam,
We, the undersigned ……………. [Insert name of the ERPSI-Lead/ Sole Bidder] having read,
examined, and understood in detail the RFP for Selection of System Integrator for
Supply, Installation, Commissioning, Implementation and Support for Enterprise Resource Planning
(ERP) System hereby submit our Bid comprising of Technical and Financial Bids.
1. We give our unconditional acceptance to the RFP including but not limited to all its instructions,
terms and conditions, and formats attached thereto, issued by Utility, as amended. In token
of our acceptance to the RFP, the same have been initiated by us and enclosed to the Bid. We
shall ensure that our Consortium shall execute such requirements as per the provisions of
the RFP and provisions of such RFP shall be binding on us.
2. Fulfilment of Eligibility
We undertake that we fulfil the Eligibility Criteria stipulated in the RFP and fulfil all the eligibility
requirements as the Lead Consortium Member/ Sole Bidder as outlined in the RFP.
3. Bid Security
We have enclosed a Bid Security of [Amount] in the form of a Bank Guarantee No. …………….
[Insert Bank Guarantee Number] (OR Demand Draft) dated ……………. [Insert date of the Bank
Guarantee] as per Form 6 given in Section 4 from ……………. [Insert name of Bank providing Bid Bond]
and valid up to [Date].
4. No Deviation
We have submitted our Financial Bid strictly as per terms and formats of the RFP, without any
deviations, conditions and without mentioning any assumptions or notes for the Financial Bid in the
said format.
5. Acceptance
Page 79 of 390
JPDCL
We hereby unconditionally and irrevocably agree and accept that the decision made by
Utility in respect of any matter regarding or arising out of the RFP shall be binding on us. We
hereby expressly waive any and all claims in respect of Bid process.
We confirm that there are no litigations or disputes against us, which materially affect our
ability to fulfil our obligations with regard to fulfilling our obligations as per the RFP.
6. Familiarity with Relevant Indian Laws and Regulations

We confirm that we have studied the provisions of the relevant Indian laws and regulations
as required to enable us to submit this Bid and execute the RFP Documents, in the event of our
selection as Selected Bidder. We further undertake and agree that all such factors as mentioned in
the ERPSI Contract have been fully examined and considered while submitting the Bid.
7. Contact Person
Details of the contact person representing our Bidding Consortium/ Sole Bidder (registered Company)
supported by the Power of Attorney prescribed in Section 4 of the RFP are furnished as under:
Name: ………………………………………………….
Designation: ………………………………………………….
Company: ………………………………………………….
Address: ………………………………………………….
Mobile: ………………………………………………….
Phone: ………………………………………………….
Fax: ………………………………………………….
Email: ………………………………………………….
• We are submitting herewith the Technical Bid containing duly signed formats, both in
electronic and physical forms, (duly attested) as desired by you in the RFP for your
consideration.
• We are also submitting herewith the Financial Bid in electronic form only, as per the terms
and conditions in the RFP.
8. It is confirmed that our Bid is consistent with all the requirements of submission as stated in the
RFP and subsequent communications from Utility.
9. The information submitted in our Bid is complete, strictly as per the requirements stipulated in
the RFP and is correct to the best of our knowledge and understanding. We would be
solely responsible for any errors or omissions in our Bid.
10. We confirm that all the terms and conditions of our Bid are valid for acceptance for a period of 1
(one) year from the Bid Submission Deadline.
11. We confirm that we have not taken any material deviation so as to be deemed non-responsive
with respect to the provisions stipulated in the RFP.
12. We confirm that no order/ ruling/ judgment has been passed by any Competent Court
or Appropriate Commission against us or any of our Consortium Members or in the preceding
1 (one) year from the Bid Submission Deadline for breach of any contract and that the Bid
Security submitted by the us or any of our Consortium Members has not been forfeited, either
Page 80 of 390
JPDCL
partly or wholly, in any bid process in the preceding 1 (one) year from the Bid Submission
Deadline.
13. We confirm that we are not currently blacklisted by any Govt. Organization or Regulatory
Agencies or Govt. undertaking.
14. We are registered/ exempt from registering in accordance with applicable laws
[Evidence of valid registration by the Competent Authority shall be attached if applicable]
Yours sincerely,
Authorized Signature [In full and initials]: _________________
Name and Title of Signatory: ___________________
Name of Firm: ________________
Address: _______________________
Page 81 of 390
JPDCL
Form 8: Format of Consortium Agreement to be entered amongst all Members of a

Bidding Consortium
[To be on non-judicial stamp paper of appropriate value as per Stamp Act relevant to place of
execution, duly signed on each page.]
FORM OF CONSORTIUM AGREEMENT BETWEEN
M/s…........................................, M/s. .........................................., M/s. ..........................................,
AND M/s. .......................................... for bidding for Tender No. [Tender Details] (the ―RFP ) dated
[Date] as per its Clause 4.3.2
1. This Consortium Agreement (hereinafter referred to as Agreement) executed on this .......... [date]
day of .......... [month], .......... [year] between
2. M/s. .........................................., a company incorporated under the laws of .................... and having
its Registered Office at .........................................., (hereinafter called "Party 1,” or ”Lead
Consortium Member” which expression shall include its successors, executors and permitted
assigns);
3. M/s. .........................................., a company incorporated under the laws of .................... and having
its Registered Office at .........................................., (hereinafter called "Party 2, which expression
shall include its successors, executors and permitted assigns);
[The Bidding Consortium should list the name, address of its registered office and other details of all
the Consortium Members above.]
WHEREAS the Parties abovenamed are entering into this Consortium Agreement for the purpose of
submitting the Bid in response to the RFP and in the event of selection as Selected Bidder to comply
with the requirements as specified in the RFP and ensure execution of the System Integrator Contract
as may be required to be entered into with Utility.
Party 1, Party 2 are hereinafter collectively referred to as the “Parties” and individually as a “Party”.
WHEREAS the RFP stipulates that the Bidders applying as a Bidding Consortium shall submit a legally
enforceable Consortium Agreement in a format specified in the RFP, whereby each Consortium
Member undertakes to be liable for its Roles and Responsibilities, provide necessary guarantees and
pay required fees as required as per the provisions of the RFP, as specified herein.
WHEREAS any capitalized term in this Agreement shall have the meaning ascribed to such term in the
RFP document.
NOW THEREFORE, THIS AGREEMENT WITNESSTH AS UNDER:
In consideration of the above premises and agreement all the Parties in this Consortium do hereby
mutually agree as follows:
1. In consideration of the selection of the Consortium as the Bidding Consortium by Utility, we the
Members of the Consortium and Parties to the Consortium Agreement do hereby unequivocally
agree that M/s........................................................... [Insert name of the Lead Member], shall act
as the Lead Member as defined in the RFP for self and agent for and on behalf of
M/s. .........................................., M/s. .........................................., M/s. ..........................................,
Page 82 of 390
JPDCL
and M/s. .......................................... [the names of all the other Members of the Consortium to
be filled in here].
2. The Lead Consortium Member is hereby authorized by the Members of Consortium and Parties
to the Consortium Agreement to bind the Consortium and receive instructions for and on behalf
of all Members. Role of the Parties: The Parties hereby undertake to perform the roles and
responsibilities as described below:
a) Party of the First Part shall be the Partner in Charge of the Consortium and shall have the
Specific Power of Attorney from all Parties for conducting all business for and on behalf
of the Consortium during the selection process for the Project and until the Effective Date
under the Contract;
b) Party of the Second Part (Partner 1) shall be [role];
3. Both Consortium Members undertake to be jointly and severally liable for the performance of its
part of the Roles and Responsibilities without in any way limiting the scope of collective liability
envisaged in this Agreement in order to meet the requirements and obligations of the RFP. The
ERPSI-Lead shall be liable and responsible for ensuring the individual and collective commitment
of each of the Members of the Consortium in discharging all their respective Roles and
Responsibilities.
4. In case of any breach of any of the commitment as specified under this Agreement by any of the
Consortium Members, the Lead Consortium Member of the Consortium shall be liable to meet
the obligations as defined under the RFP.
5. Except as specified in the Agreement, it is agreed that sharing of responsibilities as aforesaid and
obligations thereto shall not in any way be a limitation of responsibility of the Lead Member under
these presents.
6. The Members expressly agree to adhere to all the terms and conditions of the RFP and confirm
that we don‘t have any Conflict of Interest (as defined in the RFP).
7. This Consortium Agreement shall be construed and interpreted in accordance with the Laws of
India and Courts at [Place] shall have the exclusive jurisdiction in all matters relating thereto and
arising there under.
8. It is hereby agreed that the Lead Consortium Member shall furnish the Bid Security, as stipulated
in the RFP, on behalf of the Bidding Consortium.
9. It is hereby agreed that in case of selection of Bidding Consortium as the System Integrator, the
Parties to this Consortium Agreement do hereby agree that they shall furnish the Performance
Security and other commitments to Utility as stipulated in the RFP and System Integrator
Contract. The Lead Member shall be responsible for ensuring the submission of the Performance
Security and other commitments on behalf of all the Consortium Members.
10. It is further expressly agreed that the Consortium Agreement shall be irrevocable and, for the
System Integrator, shall remain valid over the term of the Project, unless expressly agreed to the
contrary by Utility.
11. The Lead Consortium Member is authorized and shall be fully responsible for the accuracy and
veracity of the representations and information submitted by the Consortium Members
respectively from time to time in response to the RFP for the purposes of the Bid. The
Page 83 of 390
JPDCL
representation by the Lead Member shall be deemed to be on behalf of and binding on all
members of the Consortium.
12. It is expressly understood and agreed between the Members of the Consortium and Parties that
the responsibilities and obligations of each of the Members shall be as delineated as annexed
hereto as Annexure-A forming integral part of this Agreement. It is further agreed by the
Members that the above sharing of responsibilities and obligations shall not in any way be a
limitation of responsibilities and liabilities of the Members, with regards to all matters relating to
the execution of the Bid and implementation of the Project envisaged in the RFP Documents.
13. It is clearly agreed that the Lead Consortium Member shall ensure performance indicated in the
RFP. In the event one or more Consortium Members fail to perform its/ their respective
obligations, the same shall be deemed to be a default by all the Consortium Members.
14. It is hereby expressly agreed between the Parties to this Consortium Agreement that neither
Party shall assign or delegate or subcontract its rights, duties, or obligations under this
Agreement to any person or entity except with prior written consent of Utility.
15. This Consortium Agreement:
a) has been duly executed and delivered on behalf of each Party hereto and constitutes the
legal,
valid, binding, and enforceable obligation of each such Party;
b) sets forth the entire understanding of the Parties hereto with respect to the subject matter
hereof; and
c) may not be amended or modified except in writing signed by each of the Parties and with
prior written consent of Utility.
Common Seal of .................................. has For M/s. .......................................... (Party 1)

been affixed in my/ our presence pursuant [Signature of Authorized Representative]
to Board Resolution dated ..................... ................................................................
[Name of the Authorized Representative]
[Designation of the Authorized Representative]
Witness 1
[Signature of Witness 1]
................................................................
Name:
Page 84 of 390
JPDCL
Designation
Witness 2
[Signature of Witness 2]
..............................................................
..
Name:
Designation:
..
Common Seal of .................................. has For M/s. .......................................... (Party N)
been affixed in my/ our presence pursuant to [Signature of Authorized Representative]
Board Resolution dated ..................... ................................................................
[Name of the Authorized Representative]
[Designation of the Authorized Representative]
Witness 1 Witness 2
[Signature of Witness 1] [Signature of Witness 1]

................................................................ ................................................................
Name: Name:
Designatio Designation:
n:
Page 85 of 390
JPDCL
Form 9: Format of Power of Attorney by ERPSI-2nd in favour of ERPSI-Lead

[To be provided by each Consortium Member (other than the Lead Consortium Member) in favor of
the Lead Consortium Member]
WHEREAS JPDCL has issued for Tender No. [Tender Details] (the ―RFP) dated [Date] for inviting Bids
in respect of Selection of Selection of System Integrator (ERPSI) to Design, Develop, Implement and
Maintain Enterprise Resource Planning (ERP) Solution on Cloud (the ―Project on the terms contained
in the RFP;
WHEREAS M/s.……………., M/s. ………………., M/s. and M/s. ………………. [Insert names of all Members of
Consortium] the Members of the Consortium are desirous of submitting a Bid in response to the RFP,
and if selected, undertaking the responsibility of implementing the Project as per the terms of the
RFP;
WHEREAS all the Members of the Consortium have agreed under the Consortium Agreement dated
…………. (the ―Consortium Agreement), entered into between all the Members and submitted along
with the Bid to appoint ………... [Insert the name and address of the Lead Consortium Member] as Lead
Consortium Member to represent all the Members of the Consortium for all matters regarding the
RFP and the Bid;
AND WHEREAS pursuant to the terms of the RFP and the Consortium Agreement, we, the Members
of the Consortium hereby designate M/s …………... [Insert name of the Lead Member] as the Lead
Consortium Member to represent us in all matters regarding the Bid and the RFP, in the manner stated
below: -
Know all men by these presents, we …………………………………………. [Insert name and
address of the registered office of the Member 1], ………………………………………………….
[Insert name and address of the registered office of the
Member 2] …...,.……………………………………. [Insert name and address of the registered office of
the Member n] do hereby constitute, appoint, nominate and authorize ……………………………… [Insert
name and registered office address of the Lead Consortium Member], which is one of the Members
of the Consortium, to act as the Lead Member and our true and lawful attorney, to do in our name
and on our behalf, all such acts, deeds and things necessary in connection with or incidental to
submission of Consortium‘s Bid in response to the RFP issued by Utility including signing and
submission of the Bid and all documents related to the Bid as specified in the RFP, including but not
limited to undertakings, letters, certificates, acceptances, clarifications, guarantees or any other
document, which Utility may require us to submit. The aforesaid attorney is further authorized
for making representations to Utility named in the RFP, and providing information / responses
to Utility, representing us and the Consortium in all matters before Utility named in the RFP, and
generally dealing with Utility named in the RFP in all matters in connection with our Bid, till completion
of the bidding process as well as implementation of the Project, if applicable, in accordance with the
RFP.
Page 86 of 390
JPDCL
We, as Members of the Consortium, hereby agree to ratify all acts, deeds and things done by our said
attorney pursuant to this Power of Attorney and that all acts, deeds, and things done by our aforesaid
attorney shall be binding on us and shall always be deemed to have been done by us.
All the terms used herein but not defined shall have the meaning ascribed to such terms under the
RFP.
We, as Members of the Consortium, hereby agree to ratify all acts, deeds and things done by our said
attorney pursuant to this Power of Attorney and that all acts, deeds, and things done by our aforesaid
attorney shall be binding on us and shall always be deemed to have been done by us.
RFP.
Signed by the within named ………………………………. [Insert the name of the executant Consortium
Member] through the hand of Mr./ Ms./ Dr. ………………………………………. duly authorized by the Board
to issue such Power of Attorney dated this …………………. day of ………….…
Accepted
………………………………
(Signature of Attorney)
[Insert Name, designation, and address of the Attorney]
Attested
…………………………………..
(Signature of the executant)
(Name, designation, and address of the executant) …………………………………….
Signature and stamp of Notary of the place of execution
Common seal of ……………… has been affixed in my/our presence pursuant to Board of Director’s
Resolution dated……
1. WITNESS1. ………………………………………………. (Signature)

Name ………………………………………….
Designation...........…………………………...
2. WITNESS2...........…………………………..................... (Signature)
Page 87 of 390
JPDCL
Name ………………………………………….
Designation...........…………………………. __
Notes
(a) The mode of execution of the power of attorney should be in accordance with the procedure,
if any, laid down by the applicable law and the charter documents of the executant(s).
(b) In the event, power of attorney has been executed outside India, the same needs to be duly
notarized by a notary public of the jurisdiction where it is executed. Such POAs must be duly
apostilled and (if required) suitable confirmation of the concerned consulate must also be
obtained.
(c) Also, wherever required, the executant(s) should submit for verification the extract of the
charter documents and documents such as a Board resolution / power of attorney, in favor of
the person executing this power of attorney for delegation of power hereunder on behalf of
the executant(s).
Page 88 of 390
JPDCL
Form 10: Format of Power of Attorney by ERPSI-Lead / Sole Bidder authorizing an

Individual Designated Representative
execution.]
Know all men by these presents, we …………………………………………….[Insert name and address of the
registered office of the Lead Consortium Member of the Bidding Consortium/ Sole Bidder] do
hereby constitute, appoint, nominate and authorize Mr./Ms.
………………………………………………… [Insert name and residential address], who is presently employed
with us and holding the position of ………………………………. as our true and lawful attorney, to do in our
name and on our behalf, all such acts, deeds and things necessary in connection with or incidental to
submission of our Bid in response to Tender No. [Tender Details] for Selection of System Integrator
(ERPSI) to Design, Develop, Implement and Maintain Enterprise Resource Planning (ERP) Solution on
Cloud (the Project) issued by JPDCL, including signing and submission of the Bid and all other
documents related to the Bid, including but not limited to undertakings, letters, certificates,
acceptances, clarifications, guarantees or any other document which Utility may require us to
submit. The aforesaid attorney is further authorized for making representations to Utility, and
providing information / responses to Utility, representing us in all matters before Utility, and generally
dealing with Utility in all matters in connection with our Bid till the completion of the bidding process
as per the terms of the RFP.
We hereby agree to ratify all acts, deeds and things done by our said attorney pursuant to this Power
of Attorney and that all acts, deeds, and things done by our aforesaid attorney shall be binding on us
and shall always be deemed to have been done by us.
RFP.
Signed by the within named ........................................... [Insert the name of the executant
company] through the hand of Mr./ Mrs. ………………………………………. duly authorized by the
Board to issue such Power of Attorney dated this ………………………. day of ………
Accepted
……………………………… (Signature of Attorney)
[Insert Name, designation, and address of the Attorney]
Attested
…………………………………..
(Signature of the executant)
(Name, designation, and address of the executant)
…………………………………….
Page 89 of 390
JPDCL
Signature and stamp of Notary of the place of execution

Common seal of ……………… has been affixed in my/our presence pursuant to Board of Director’s
Resolution dated……
1. WITNESS 1. ………………………………………………. (Signature)
Name ………………………………….
Designation...........………………….
2. WITNESS 2. ………………………………………………. (Signature)
Name ………………………………….
Designation...........…………………. _
_________________________________________________________________________
Notes:
a. The mode of execution of the power of attorney should be in accordance with the procedure, if
any, laid down by the applicable law and the charter documents of the executant(s).
b. In the event, power of attorney has been executed outside India, the same needs to be duly
notarized by a notary public of the jurisdiction where it is executed. Such POAs must be duly
apostilled and (if required) suitable confirmation of the concerned consulate must also be
obtained.
c. Also, wherever required, the executant(s) should submit for verification the extract of the charter
documents and documents such as a Board resolution / power of attorney, in favor of the person
executing this power of attorney for delegation of power hereunder on behalf of the executant(s).
Page 90 of 390
JPDCL
Form 11: Format of Letter of Consent by Sole Bidder/ ERPSI-Lead reviewing each
element of the Bid
[On the letter head of Sole Bidder/ each Member of the Consortium including Lead Member]
[Reference No.]
From:
[Address of the Lead Consortium Member/ Sole Bidder] [Telephone No., Fax No., Email]
[Date]
To,
SERC Building, B.R. Ambedkar Chowk,
Rail Head Complex,
Jammu – 180006
Sub: Bid for Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain
Enterprise Resource Planning (ERP) Solution on Cloud.
Ref: [Tender Details]
Dear Sir/ Madam,

We, ……................… [Insert name of the undersigned Sole Bidder/ Consortium Member] Sole
Bidder/ Member of Consortium and Lead by ……................… [Insert name of the Lead Consortium
Member] have read, examined, and understood the RFP and RFP Documents for Selection of System
Integrator for Supply, Installation, Commissioning, Implementation and Support for Enterprise
Resource Planning (ERP) System.
We hereby confirm our concurrence with the RFP including in particular the Bid / and Consortium
Agreement submitted by ……................… [Insert name of the Sole Bidder/ Lead Consortium
Member], in response to the RFP. We confirm that the Bid has been reviewed and each element of
the Bid is agreed to including but not limited to the commitment and obligations of our Company.
The details of contact person are furnished as under: Name :
Designation :
Name of the Company :
Address :
Phone Nos. :
Fax Nos. :
Page 91 of 390
JPDCL
E-mail address :
Dated the ……. day of ……. of 20……
Thanking you,
Yours faithfully,
………………………………..
[Signature, Name, Designation of Authorized Signatory of Consortium Member and Company's Seal]
Business Address:
[Name and address of principal officer]
Page 92 of 390
JPDCL
Form 12: Record of Similar Work Done

Name of the Project: Location:
Client Name: Client Address:
Type of Client: (PSU / Power Utility/ Indian Power Utility/ Private/ Others):
Project Duration (In Months): Project Value: (In INR Crores):
Status: (Complete / Ongoing)
Start Date: Completion Date:
Number of Users*: Modules covered*:
Name of the ERP OEM Product implemented*:
Complete Documentary Evidence Attached Documentary Evidence (Start Page No. To End
(Yes/No): Page No.):
Page 93 of 390
JPDCL
Form 13: Bill of Material and Services

Schedule: A
Summary of Costs
S.No. Description Unit Quantity
(1) (2) (3) (4)
1. Yearly Subscription of ERP SaaS Lumpsum 1
Application Licenses and Others (OEM) -
Till Go-Live as per TABLE: A of attached
BOQ Price Break Down
Application Licenses and Others (OEM) -
After Go-Live as per TABLE: B of attached
3. ERP Application Implementation and Lumpsum 1
O&M Services as per Table: C of attached
4. Data Migration as per Table: D of Lumpsum 1
attached BOQ Price Break Down
5. Incidental Charges as per TABLE: E of Lumpsum 1
Table: A (Till Go-Live)

A Yearly Subscription of ERP SaaS Application Licenses and Others (OEM)
S.No. ERP No. of Users Name of Unit of Proposed No.
Software considered till Product & Licenses of Units of
Go-Live OEM Licenses
License
required for
Application till Go-Live
(1) (2) (3) (4) (5) (6)
SaaS-based ERP Application Users To be filled by the bidder
Licenses
1 All Access Licenses 20 Nos.
2 Module Access 162
Licenses
2a Distribution 125 Nos.
operations
(Inventory and
Stock, Asset
Management and
Project
Management,
Operations Support
Page 94 of 390
JPDCL
A Yearly Subscription of ERP SaaS Application Licenses and Others (OEM)

S.No. ERP No. of Users Name of Unit of Proposed No.
Software considered till Product & Licenses of Units of
Go-Live OEM Licenses
License
required for
Application till Go-Live
and Consumer
Service
Management and
Grievance
Redressal)
2b Finance & 15 Nos.
Accounting
2c Human Resource 10 Nos.
Management
2d Purchasing / 10 Nos.
Contract
Management
2e Legal 2
3 Management Self- 100 Nos.
Service
4 Employee Self- 2500 Nos.
Service & Payroll
5 Development User 2 Nos.
6 Asset Life Cycle - Lumpsum
Management
Licences for other components of the envisaged ERP System
1 Helpdesk Lumpsum
Management Tool
(SaaS Based)
2 Enterprise Content Lumpsum
Management (SaaS
Based)
3 System Monitoring Lumpsum
tools (SaaS Based),
if any
4 Other Lumpsum
Tools/Software
(SaaS Based)
Note:
1. These number of users proposed in (Table: A) & (Table: B) are as per the current usage of
JPDCL. However, ERPSI should propose an optimal “User Licenses” (ERP SaaS Application)
Page 95 of 390
JPDCL
satisfying the JPDCL requirements without compromising the flexibility of usage across
different business functions for Till-Go-Live Period (Table A) and Post-Go-Live Period (Table B)
2. The Licenses will be used across JPDCL including all its JVs, subsidiaries and other external
stakeholders as defined in the RFP in India and abroad under one license agreement to be
signed between JPDCL and OEMs.
3. During the contract period, JPDCL will have the liberty to order additional ERP System Licenses
& Other Software Licenses at unit rates of items offered in the commercial bid. The unit of
license and its rate mentioned in price bid for tender items will remain unchanged for entire
contract period.
4. OEM will provide the license policy comprising of
a. License buckets/blocks/bundle/bunch/units etc. along with License type, rates and
others details
b. Maximum number of allowable users as per the license policy
c. Calculation made for arriving at the numbers of licenses offered
5. JPDCL shall be authorized to use the maximum number of allowable users (as per license
policy) without formal communication with OEM
6. JPDCL shall be authorized to reallocate the license usage as per their internal utilization
requirements within a User license type
7. ERP System Licenses including Application, Database, Supporting Solution, Tools etc. shall be
property of JPDCL, and shall be utilized by JPDCL as per its business requirements.
8. ERP OEM will sign End User License Agreement (EULA) with JPDCL before procurement of
licenses.
Table: B (Post Go-Live)

B Yearly Subscription of ERP SaaS Application Licenses and Others (OEM)
ERP Proposed No.

Software No. of Users Name of of Units of
Unit of
S.No. considered Product & Licenses
License Licenses
post Go-Live OEM required for
Application post Go-Live
(1) (2) (3) (4) (5) (6)
Annual Technical Support (ATS) for To be filled by the bidder
SaaS-based ERP Application Users
Licenses supplied till Go-live
1 All Access Licenses 20 Nos.
2 Module Access 162
Licenses
2a Distribution 125 Nos.
operations (Inventory
and Stock, Asset
Management and
Project Management,
Operations Support
and Consumer Service
Management and
Grievance Redressal)
Page 96 of 390
JPDCL
ERP Proposed No.

Unit of
License Licenses
2b Finance & Accounting 15 Nos.
2c Human Resource 10 Nos.
Management
2d Purchasing / Contract 10 Nos.
Management
2e Legal 2
3 Management Self- 100 Nos.
Service
4 Employee Self- 2500 Nos.
Service & Payroll
5 Development User 2 Nos.
6 Asset Life Cycle - Lumpsum
Management
1 Helpdesk Lumpsum
Management Tool
(SaaS Based)
Management (SaaS
Based)
tools (SaaS Based), if
any
4 Other Lumpsum
Tools/Software
(SaaS Based)
Rates for ERP SaaS Application Licenses for the purpose of roll-out
ERP No. of Users Name of
Unit of
S.No. Software considered Product &
Licenses
License Application per Block OEM
Supply of ERP SaaS Application Licenses of additional ERP SaaS

Application Licenses (in Blocks of numbers specified below)
1 All Access Licenses 5 Block
2 Module Access 100 Block
Licenses
Page 97 of 390
JPDCL
ERP Proposed No.

Unit of
License Licenses
3 Management Self- 10 Block
Service
4 Employee Self- 500 Block
Service & Payroll
Annual Technical Support (ATS) for Supply of ERP SaaS Application
Licenses of additional ERP SaaS Application Licenses (in Blocks of
numbers specified below)
1 All Access Licenses 5 Block
2 Module Access 100 Block
Licenses
3 Management Self- 10 Block
Service
4 Employee Self- 500 Block
Service & Payroll
Note:
1. Year2#: The definition of Year 2 will be considered as the first year of operations of the
envisaged ERP system after Go-Live i.e. Go-Live of ERP solution at all the locations and
declaration of Go-Live, duly approved by JPDCL. The start of stabilization period will be treated
as start of the Year 2.
2. Other applicable conditions are mentioned in (TABLE: A)
Table : C ERP Application Implementation and O&M Services

ERP Application Implementation and O&M Services
S.No. Item Unit Quantity
(1) (2) (3) (4)
Implementation – (Till Go-Live)
1. Implementation, Integration, Lumpsum 1
Customization, Realization, Testing and
GO-Live as per SoW
2. Operations and Maintenance for 48 Months (Including Helpdesk) – (Post Go-Live)
2.1 Operations and Maintenance for Year 2 Lumpsum (Per 12
Month)
Month)
Page 98 of 390
JPDCL

Month)
Month)
Rates for Engagement of specific resources for the purpose of change request
3. Functional Consultant: Man-Months -
3.1 Functional Consultant for Finance & Man-Months 1
Accounts
3.2 Functional Consultant for Payroll & HR Man-Months 1
Management
3.3 Functional Consultant for Procurement Man-Months 1
Store and Material management
3.4 Functional Consultant for Asset Life Cycle Man-Months 1
management
3.5 Functional Consultant for Utilities Man-Months 1
(Distribution Operations)
3.6 Functional Consultant for Utilities Billing Man-Months 1
3.7 Functional Consultant for Citizen services Man-Months 1
4. Solution Architect Man-Months 1
5. Technical SME Consultants Man-Months 1
6. Developer Man-Months 1
7. Tester Man-Months 1
8. Helpdesk Operator Man-Months 1
Table : D Data Migration
Data Migration
(1) (2) (3) (4)
Data Migration
1 (Data Checking, Data Identification and Lumpsum 1
preparation, Data Extraction, Data
Assessment, Data Mapping and cleansing,
developing data conversion scripts, Data
Loading, Testing and Verification, Data
Reconciliation etc.)
Note: Estimated volume of Data migration Refer 'Capacity Estimates' section of the RFP
Page 99 of 390
JPDCL
Table : E Incidental Charges

Incidental Charges
(1) (2) (3) (4)
1 Incidental Charges (Including Travelling / Lumpsum 1
Boarding / Lodging etc.) during the
contract period
Page 100 of 390

JPDCL
Form 14: Table of Compliance

The Bidder shall submit ‘Clause by Clause‘ compliance to the RFP document including the technical
specifications and functional requirements as per the format prescribed in Form 14
The Bidder shall annotate the Table of Contents of each section to provide a high-level summary of
compliance status. In all cases, the following symbols, and no others shall be used:
• C - Bid complies with all requirements in the adjacent paragraph.

• A - Bid is not compliant with the requirements in the adjacent paragraph, but a
functional alternative is proposed.
• X - Bid takes exception to the requirements of the adjacent paragraph and no functional
alternative is proposed.
Only one symbol shall be assigned to paragraph and shall indicate the worst-case level of compliance
for that paragraph. This annotation may be handwritten.
The Bidder shall also underline, on the compliance copy, all requirements to which exceptions have
been taken (X) or to which alternatives have been proposed (A).
Each alternative shall be clearly and explicitly described. Such descriptions shall use the same
paragraph numbering as the bid document sections addressed by the alternatives. All alternative
descriptions shall be in one contiguous section of the bidder‘s proposal, preferably in the same
volume, and titled "Alternatives." A separate section titled "Exceptions" shall also be provided
containing any discussion or explanation chooses to provide concerning exceptions taken.
Alternatives which do not substantially comply with the intent of the Bid documents will be
considered exceptions.
Any clause which is not included in this compliance table shall be treated as ―fully complied or C.
The Utility will assess the merits of each alternative and exception and will be the sole judge as to
their acceptance.
Additionally, the bidder has to provide the details of PQR and TQR supporting documents in the
following format
Proposal
PQR/TQR Clause RFP Criteria Supporting Compliance
reference and
/ RFP Reference Description Document (Yes/No)
Page No.
Page 101 of 390

JPDCL
Form 15: Turnover and Net worth Certificate

Average Annual
Annual Turnover (INR Turnover from IT/ ICT
S. No. Financial Year from IT/ ICT (System ( System
Implementation) Crores) Implementation) (INR
Crores)
1. Financial Year 2019-20
Note: The audited Financial Statements for the corresponding years have to be enclosed.
Average Annual
Annual Turnover (INR Turnover from ERP
S. No. Financial Year from ERP solution solution
implementation (Crores) implementation (on
on Cloud/ on-Premise) Cloud/ on-Premise)
(Crores)
S. No. Financial Year Net Worth (INR Crores)
Note: The audited Financial Statements for the corresponding years have to be enclosed.
Name of the auditor issuing the certificate

Name of the auditor’s Firm:
Seal of auditor’s Firm:
Date:
(Signature, name and designation of the authorized signatory for the Auditor’s Firm)
Page 102 of 390

JPDCL
Form 16: Format for court cases
Pending Litigation
Value of Pending
Value of Pending Claim
Year Matter in Dispute Claim as a percentage
in INR (if any)
of Net Worth (if any)
The information of pending litigation mentioned above is true and correct to our best knowledge and
belief.
Yours sincerely,
Name of Firm: ________________
Address: _______________________
Location: _____________________________________ Date: _________________
Page 103 of 390

JPDCL
Form 17: Undertaking on Change Request (Company Letter Head)

To,
Subject: Undertaking on Change Request

We, the undersigned, offer to Selection of System Integrator (ERPSI) to Design, Develop, Implement
and Maintain Enterprise Resource Planning (ERP) Solution on Cloud in response to the Request for
Proposal dated <insert RFP date> and RFP No <insert RFP no.> for “Selection of System Integrator
(ERPSI) to Design, Develop, Implement and Maintain Enterprise Resource Planning (ERP) Solution on
Cloud”. We hereby confirm that the assumptions mentioned in our Approach & Methodology
document submitted as part of the bid proposal will not become the basis for Change Request.
Authorized Signature: _________________

Location: _____________________________________ Date: _________________
Page 104 of 390

JPDCL
Form 18: Undertaking of for non-blacklisting

(To be executed on Non – judicial stamp paper of INR 100/-or such equivalent amount and
document duly attested by notary public)
(Insert Bidder Name) have not been blacklisted/ debarred by any Central Government/ State
Government/ PSU or any other Government Institution/ Authority in India/ Multi-lateral funding
agency. Also, have not been under any legal action for indulging in corrupt practice, fraudulent
practice, coercive practice, undesirable practice, breach of contract or restrictive practice with any
Indian Central Government/ State Government in last three (3) years as on bid submission date.
In case, bidder was blacklisted and subsequently blacklisting has been revoked in last 3 years as on
bid submission date, please provide the details regarding the period for which the company / firm
was blacklisted and the reason/s for the same
Blacklisting/
S. Date of Reason for Date of
Debarring Remarks
No. Blacklisting/Debarment Blacklisting/Debarment Revocation
Organization
1.
2.
Note: All the supporting documents related to backlisting/ debarment and revocation are required to
be appended to this letter.
Authorized Signature: _________________

Location: _____________________________________ Date: _________________
*In case of a consortium, the consortium member shall submit above undertaking separately
Page 105 of 390

JPDCL
Form 19: Conflict of Interest (Company Letter head)

To,
SERC Building, B.R. Ambedkar Chowk,
Rail Head Complex,
Jammu – 180006
Sub: Undertaking on Conflict of Interest regarding Selection of System Integrator ( ERPSI) to Design,
Develop, Implement and Maintain Enterprise Resource Planning (ERP) Solution on Cloud
Dear Sir,
I/We do hereby undertake that there is absence of, actual or potential conflict of interest on the part
of ERPSI or any prospective subcontractor due to prior, current, or proposed contracts, engagements,
or affiliations with JPDCL.
I/We also confirm that there are no potential elements (time-frame for service delivery, resource,
financial or other) that would adversely impact our ability to complete the requirements as given in
the RFP.
We undertake and agree to indemnify and hold JPDCL harmless against all claims, losses, damages,
costs, expenses, proceeding fees of legal advisors (on a reimbursement basis) and fees of other
professionals incurred (in the case of legal fees and fees of professionals, reasonably) by JPDCL and/or
its, if any such conflict arises later.
Yours sincerely,
Name of Firm: ________________
Address: _______________________
Location: _____________________________________ Date: _________________
Page 106 of 390

JPDCL
Form 20: Pre-contract Integrity Pact (To be executed on a non-judicial stamp paper
of INR 100/-)
INTEGRITY PACT
This pre-Bid Pre-Contract agreement (hereinafter called the “Integrity Pact”) is made on _______ day of the
month of __________ 2023, by and between:
1. Jammu Power Distribution Corporation Limited (hereinafter called “JPDCL”, which expression shall
mean and include, unless the context otherwise requires, its successors in office and assigns) of the
First Part; and
2. __________ (hereinafter called the “BIDDER” which expression shall mean and include, unless the
context otherwise requires, its successors and permitted assigns) of the Second Part.
JPDCL and ERPSI, where the context permits, shall be referred to collectively as “Parties” and individually as
“Party”.
WHEREAS,
A. JPDCL proposes to appoint a Master System Integrator for Implementation & Maintenance of Cloud
based Enterprise Resource Planning Solution as detailed in the RFP No. __________ issued on
__________ by JPDCL (“RFP”), and ERPSI is willing to submit / has submitted a Bid for selection as
Master System Integrator; and
B. ERPSI is a company / partnership/ limited liability partnership, constituted in accordance with the
relevant law in the matter and JPDCL is a public sector undertaking licenced under Section 8 of the
Companies Act, 2013; and
C. To avoid all forms of corruption by following a system that is fair, transparent and free from any
influence/prejudiced dealings prior to, during and subsequent to the currency of the Contract to be
entered into with a view to enabling JPDCL to obtain the desired Services at a competitive price in
conformity with the defined specifications by avoiding the high cost and the distortionary impact of
corruption on public procurement, and enabling ERPSI to abstain from bribing or indulging in any
corrupt practice in order to secure the contract by providing assurance to them that their competitors
will also abstain from bribing and other corrupt practices and JPDCL will commit to prevent corruption,
in any form, by its officials by following transparent procedures.
The Parties hereto hereby agree to enter into this Integrity Pact and agree as follows:
1. Commitments of JPDCL
1.1 JPDCL undertakes that no official of the JPDCL, connected directly or indirectly with the Contract, will
demand, take a promise for or accept, directly or through intermediaries, any bribe, consideration, gift,
reward, favour or any material or immaterial benefit or any other advantage from ERPSI, either for
themselves or for any person, organisation or third party related to the contract in exchange for an
advantage in the bidding process, bid evaluation, contracting or implementation process related to the
Contract.
1.2 JPDCL will, during the pre-Contract stage, treat all bidders alike, and will provide to all bidders the same
information and will not provide any such information to any particular bidder which could afford an
advantage to that particular bidder in comparison to other bidders.
1.3 All the officials of JPDCL will report to the appropriate Government office any attempted or completed
breaches of the above commitments as well as any substantial suspicion of such a breach.
2. In case any such preceding misconduct on the part of such official(s) is reported by ERPSI to JPDCL with
full and verifiable facts and the same is prima facie found to be correct by JPDCL, necessary disciplinary
proceedings, or any other action as deemed fit, including criminal proceedings may be initiated by
Page 107 of 390

JPDCL
JPDCL and such a person shall be debarred from further dealings related to the contract process. In
such a case while an enquiry is being conducted by JPDCL the proceedings under the Contract would
not be stalled.
3. Commitments of ERPSI
ERPSI commits itself to take all measures necessary to prevent corrupt practices, unfair means and
illegal activities during any stage of its bid or during any pre-Contract or post-Contract stage in order to
secure the contract or in furtherance to secure it and in particular commit itself to the following: -
3.1 ERPSI will not offer, directly or through intermediaries, any bribe, gift, consideration, reward, favour,
any material or immaterial benefit or other advantage, commission, fees, brokerage or inducement to
any official of JPDCL, connected directly or indirectly with the bidding process, or to any person,
organisation or third party related to the Contract in exchange for any advantage in the bidding,
evaluation, contracting and implementation of the Contract.
3.2 ERPSI further undertakes that it has not given, offered or promised to give, directly or indirectly any
bribe, gift, consideration, reward, favour, any material or immaterial benefit or other advantage,
commission, fees, brokerage or inducement to any official of JPDCL or otherwise in procuring the
Contract or forbearing to do or having done any act in relation to the obtaining or execution of the
Contract or any other contract with the Government for showing or forbearing to show favour or
disfavour to any person in relation to the Contract or any other contract with the Government.
3.3 ERPSI shall disclose the name and address of agents and representatives, and its foreign principals or
associates.
3.4 ERPSI shall disclose the payments to be made by them to agents/brokers or any other intermediary, in
connection with this bid/Contract.
3.5 ERPSI further confirms and declares to JPDCL that ERPSI has not engaged any individual or firm or
company whether Indian or foreign to intercede, facilitate or in any way to recommend to JPDCL or any
of its functionaries, whether officially or unofficially to the award of the Contract to ERPSI, nor has any
amount been paid, promised or intended to be paid to any such individual, firm or company in respect
of any such intercession, facilitation or recommendation.
3.6 ERPSI, either while presenting the bid or during pre-Contract negotiations or before signing the
Contract, shall disclose any payments he has made, is committed to or intends to make to officials of
JPDCL or their family members, agents, brokers or any other intermediaries in connection with the
Contract and the details of services agreed upon for such payments.
3.7 ERPSI will not collude with other parties interested in the Contract to impair the transparency, fairness
and progress of the bidding process, bid evaluation, contracting and implementation of the Contract.
3.8 ERPSI will not accept any advantage in exchange for any corrupt practice, unfair means and illegal
activities.
3.9 ERPSI shall not use improperly, for purposes of competition or personal gain, or pass on to others, any
information provided by JPDCL as part of the business relationship, regarding plans, technical proposals
and business details, including information contained in any electronic data carrier. ERPSI also
undertakes to exercise due and adequate care lest any such information is divulged.
3.10 ERPSI commits to refrain from giving any complaint directly or through any other manner without
supporting it with full and verifiable facts.
3.11 ERPSI shall not instigate or cause to instigate any third person to commit any of the actions mentioned
above.
3.12 If ERPSI or any employee of ERPSI or any person acting on behalf of ERPSI, either directly or indirectly,
is a relative of any of the officers of JPDCL, or alternatively, if any relative of an officer of JPDCL has
financial interest/stake in ERPSI’s firm, the same shall be disclosed by ERPSI at the time of filing of
tender.
The term 'relative' for this purpose would be as defined in Section 2(77) of the Companies Act 2013.
3.13 ERPSI shall not lend to or borrow any money from or enter into any monetary dealings or transactions,
directly or indirectly, with any employee of JPDCL.
4. Previous Transgression
4.1 ERPSI declares that no previous transgression occurred in the last 3 (three) years immediately before
signing of this Integrity Pact, with any other company in any country in respect of any corrupt practices
Page 108 of 390

JPDCL
envisaged hereunder or with any Public Sector Enterprise in India or any Government Department in
India that could justify ERPSI's exclusion from the bidding process.
4.2 ERPSI agrees that if it makes incorrect statement on this subject, BIDDER can be disqualified from the
bidding process or the Contract, if already awarded, can be terminated for such reason.
5. Earnest Money Deposit
5.1 While submitting its bid, ERPSI shall deposit an amount of Rs. 36,00,000 (Rupees Thirty-Six Lakhs) as
Earnest Money Deposit, with JPDCL in the shape of CRD/FDR, BG or Demand Draft from any Scheduled
Commercial Bank/ Nationalized Bank, promising payment of the guaranteed sum to JPDCL on demand
within three working days without any demur whatsoever and without seeking any reasons
whatsoever. The demand for payment by JPDCL shall be treated as conclusive proof of payment.
5.2 The Earnest Money Deposit shall be valid up to a minimum period of 1 (one) year.
5.3 In case of ERPSI is declared the successful bidder, a clause would also be incorporated in the provision
pertaining to Performance Bank Guarantee in the Contract that the provisions of Clause 6 (Sanctions
for Violation) shall be applicable for forfeiture of Performance Bank Guarantee in case of a decision by
JPDCL to forfeit the same without assigning any reason for imposing sanction for violation of this
Integrity Pact.
5.4 No interest shall be payable by JPDCL to ERPSI on Earnest Money Deposit for the period of its currency.
6. Sanctions for Violations
6.1 Any breach of the aforesaid provisions by ERPSI or anyone employed by it or acting on its behalf
(whether with or without the knowledge of ERPSI) shall entitle JPDCL to take all or any one of the
following actions, wherever required: -
(i) To immediately call off the pre-Contract negotiations without assigning any reason or giving any
compensation to ERPSI. However, the proceedings with the other bidder(s) would continue.
(ii) The Earnest Money Deposit (in pre-Contract stage) or Performance Bank Guarantee (after the Contract
is signed) shall stand forfeited either fully or partially, as decided by JPDCL, and JPDCL shall not be
required to assign any reason, therefore.
(iii) To immediately cancel the Contract, if already signed, without giving any compensation to ERPSI.
(iv) To recover all sums already paid by JPDCL with interest thereon at 2% (two percent) higher than the
prevailing Prime Lending Rate of State Bank of India. If any outstanding payment is due to ERPSI from
JPDCL in connection with any other contract for any other stores, such outstanding payment could also
be utilised to recover the aforesaid sum and interest.
(v) To encash the Earnest Money Deposit / performance bank guarantee in order to recover the payments,
already made by JPDCL, along with interest.
(vi) To cancel all or any other contracts with ERPSI. ERPSI shall be liable to pay compensation for any loss
or damage to JPDCL resulting from such cancellation/rescission and JPDCL shall be entitled to deduct
the amount so payable from the money(s) due to ERPSI.
(vii) To debar ERPSI from participating in future bidding processes of the Government of India for a
minimum period of 5 (five) years, which may be further extended at the discretion of JPDCL.
(viii) To recover all sums paid in violation of this Integrity Pact by BIDDER(s) to any middleman or agent or
broker with a view to securing the Contract.
(ix) In cases where irrevocable letters of credit have been received in respect of any contract signed by
JPDCL with ERPSI, the same shall not be opened.
(x) Forfeiture of performance bank guarantee in case of a decision by JPDCL to forfeit the same without
assigning any reason for imposing sanction for violation of this Integrity Pact.
6.2 JPDCL will be entitled to take all or any of the actions mentioned at Clauses 6.1(i) to (x) of this Integrity
Pact also on the commission by ERPSI or any one employed by it or acting on its behalf (whether with
or without the knowledge of ERPSI), of an offence as defined in Chapter IX of the Indian Penal Code,
1860 or Prevention of Corruption Act, 1988 or any other statute enacted for prevention of corruption.
6.3 The decision of JPDCL to the effect that a breach of the provisions of this Pact has been committed by
JPDCL shall be final and conclusive on JPDCL. However, JPDCL can approach the Independent Monitor(s)
appointed for the purposes of this Pact.
7. Fall Clause
Page 109 of 390

JPDCL
ERPSI undertakes that it has not provided/is not supplying similar Services at a price lower than that
offered in the present bid in respect of any other Ministry/Department of the Government of India or
PSU and if it is found at any stage that similar Services were supplied by ERPSI to any other
Ministry/Department of the Government of India or a PSU at a lower price, then that very price, with
due allowance for elapsed time, will be applicable to the present case and the difference in the cost
would be refunded by ERPSI to JPDCL, if the contract has already been concluded.
9. Facilitation of Investigation
In case of any allegation of violation of any provisions of this Integrity Pact or payment of commission,
JPDCL or its agencies shall be entitled to examine all the documents including the books of accounts of
ERPSI and ERPSI shall provide necessary information and documents in English and shall extend all
possible help for the purpose of such examination.
10. Law and Place of Jurisdiction
This Integrity Pact is subject to Indian Law. The place of performance and jurisdiction is the seat of
JPDCL.
11. Other Legal Actions
The actions stipulated in this Integrity Pact are without prejudice to any other legal action that may
follow in accordance with the provisions of the extant law in force relating to any civil or criminal
proceedings.
12. Validity
12.1 The validity of this Integrity Pact shall be from date of its signing and extend up to 5 (five) years or the
complete execution of the Contract to the satisfaction of both JPDCL and ERPSI, including warranty
period, whichever is later. In case BIDDER is unsuccessful this Integrity Pact shall expire after 6 (six)
months from the date of the signing of the Contract.
12.2 Should 1 (one) or several provisions of this Integrity Pact turn out to be invalid, the remainder of this
Integrity Pact shall remain valid. In this case, the Parties will strive to come to an agreement to their
original intentions.
JPDCL BIDDER
__________ [Signature] __________ [Signature]
__________ [Name] __________ [Name]
__________ [Designation] __________ [Designation]
Witness Witness
1. 1.
2. 2.
Page 110 of 390

JPDCL
Section 5. Bidding Forms - Financial Proposal

Form 1: Format of Submission of Financial Bid
To,

SERC Building,
B.R. Ambedkar Chowk,
Rail Head Complex,
Jammu – 180006
Sub: Selection of Request for Proposal for Selection of System Integrator (ERPSI) to Design, Develop,
Implement and Maintain Enterprise Resource Planning (ERP) Solution on Cloud
RFP No: 07 of 2023-2024 Dated: 19/09/2023
Dear Sir,
We, the undersigned Bidder, having read and examined in detail all the Tender documents in respect
of “Request for Proposal for Selection of System Integrator (ERPSI) to Design, Develop, Implement
and Maintain Enterprise Resource Planning (ERP) Solution on Cloud” do hereby propose to provide
services as specified in the RFP No. < > dated < >
I. PRICE AND VALIDITY

a. All the prices mentioned in our Bid are in accordance with the terms & conditions as specified
in the RFP. The validity of bid is 180 days from the date of opening of the RFP.
b. We are an Indian Firm and do hereby confirm that our Tender prices include all taxes. However,
all the taxes are quoted separately under relevant Sections.
c. We have studied the clause relating to Indian Income Tax and hereby declare that if any income
tax, surcharge on Income Tax, Professional and any other Corporate Tax in altercated under the
law, we shall pay the same.
II. UNIT RATES

We have indicated in the relevant schedules enclosed, the unit rates for the purpose of on
account of payment as well as for price adjustment in case of any increase to / decrease from the
Scope of Work under the Contract.
III. DEVIATIONS
We declare that all the services shall be performed strictly in accordance with the RFP irrespective
of whatever has been stated to the contrary anywhere else in our bid.
Further we agree that additional conditions, if any, found in our bid documents, shall not be given
effect to.
IV. EARNEST MONEY DEPOSIT (EMD)
Page 111 of 390

JPDCL
We have enclosed an EMD in the form of Refundable & Irrevocable Bank Guarantee for a sum of
INR 44,00,000/- (Rupees Fourty-Four Lacs only). This EMD is liable to be forfeited in accordance
with the provisions in the RFP
V. TENDER PRICING
We further confirm that the prices stated in our bid are in accordance with your Instruction to
Bidders included in Tender documents.
VI. QUALIFYING DATA
We confirm having submitted the information as required by you in your Instruction to Bidders.
In case you require any other further information / documentary proof in this regard before
evaluation of our Tender, we agree to furnish the same in time to your satisfaction.
VII. BID PRICE
We declare that our Bid Price is for the entire scope of the work as specified in the RFP. These
prices are indicated in (Error! Reference source not found. in Section 5) attached with our Tender a
s part of the Tender.
VIII. PERFORMANCE BANK GUARANTEE BOND
We hereby declare that in case the Contract is awarded to us, we shall submit the Performance
Bank Guarantee bond in the format prescribed in Section 4 of the RFP
We hereby declare that our Tender is made in good faith, without collusion or fraud and the
information contained in the Tender is true and correct to the best of our knowledge and belief.
We understand that our Tender is binding on us and that you are not bound to accept a Tender
you receive.
We confirm that no technical deviations are attached here with this commercial offer.
Yours sincerely,
Name of Firm: ________________
Address: _______________________
Location: _____________________________________ Date: _________________
Page 112 of 390

Form 2: Format for Financial Breakup of Cost Components

Schedule: B
Summary of Costs
S.No. Description Unit Quantity Total Cost GST % GST Amount Total Cost
(excl GST) Including GST
(1) (2) (3) (4) (5) (6) (7)=(5)*(6) (8)=(5)+(7)
Application Licenses and Others
(OEM) - Till Go-Live as per TABLE:
A1 of attached BOQ Price Break
Down
Application Licenses and Others
(OEM) - After Go-Live as per
TABLE: B1 of attached BOQ Price
Break Down
3. ERP Application Implementation Lumpsum 1
and O&M Services as per Table: C
4. Data Migration as per Table: D of Lumpsum 1
5. Incidental Charges as per Table: E Lumpsum 1
of attached BOQ Price Break
Down
Page 113 of 390

Table : A1 (Till Go-Live)

A Yearly Subscription of Supply of ERP SaaS Application Licenses and Others (OEM)
Unit
ERP Proposed No.
of Units of Rate
Software Unit of Total Cost Total Cost
S.No. Licenses (In Rs.) GST % GST Amount
License Licenses (excl GST) Including GST
required for till (Excl
Application Go-Live
GST)
(1) (2) (3) (4) (5) (6)= (4)*(5) (7) (8)=(6)*(7) (9)=(6)+(8)
1 All Access Licenses Nos.
2 Module Access
Licenses
2a Distribution Nos.
and Stock, Asset
Management and
Project Management,
Operations Support
Management and
2b Finance & Accounting Nos.
2c Human Resource Nos.
Management
2d Purchase / Contract Nos.
Management
2e Legal Nos.
Page 114 of 390

A Yearly Subscription of Supply of ERP SaaS Application Licenses and Others (OEM)
Unit
ERP Proposed No.
of Units of Rate
S.No. Licenses (In Rs.) GST % GST Amount
required for till (Excl
Application Go-Live
GST)
3 Management Self- Nos.
Service
4 Employee Self- Nos.
Service & Payroll
5 Development User Nos.
7 Asset Life Cycle Lumpsum
Management
1 Helpdesk Lumpsum
Management Tool
(SaaS Based)
Management (SaaS
Based)
any
4 Other Lumpsum
Tools/Software (SaaS
Based)
Page 115 of 390

Note:
1. These number of users proposed in (Table: A) & (Table: B) are as per the current usage of JPDCL. However, ERPSI should propose an optimal “User
Licenses” (ERP SaaS Application) satisfying the JPDCL requirements without compromising the flexibility of usage across different business functions
for Till-Go-Live Period (Table A) and Post-Go-Live Period (Table B)
2. The Licenses will be used across JPDCL including all its JVs, subsidiaries and other external stakeholders as defined in the RFP in India and abroad
under one license agreement to be signed between JPDCL and OEMs.
3. During the contract period, JPDCL will have the liberty to order additional ERP System Licenses & Other Software Licenses at unit rates of items offered
in the commercial bid. The unit of license and its rate mentioned in price bid for tender items will remain unchanged for entire contract period.
4. OEM will provide the license policy comprising of
a. License buckets/blocks/bundle/bunch/units etc. along with License type, rates and others details
b. Maximum number of allowable users as per the license policy
c. Calculation made for arriving at the numbers of licenses offered
5. JPDCL shall be authorized to use the maximum number of allowable users (as per license policy) without formal communication with OEM
6. JPDCL shall be authorized to reallocate the license usage as per their internal utilization requirements within a User license type
7. ERP System Licenses including Application, Database, Supporting Solution, Tools etc. shall be property of JPDCL, and shall be utilized by JPDCL as per
its business requirements.
8. ERP OEM will sign End User License Agreement (EULA) with JPDCL before procurement of licenses.
Page 116 of 390

Table : B1 (Post Go-Live) – Annual Technical Support (ATS) for ERP SaaS Application Licenses and Others (OEM) supplied till Go-live
B1 Annual Technical Support (ATS) for ERP SaaS Application Licenses and Others (OEM) supplied till Go-live
ERP Proposed No.
of Units of Unit Rate (In
S.No. Licenses Rs.) (Excl GST % GST Amount
required for GST)
Application Post Go-Live
(1) (2) (3) (4) (5) (6)= (4)*(5) (7) (8)=(6)*(7) (9)=(6)+(8)
1 All Access Licenses Nos.
2 Module Access
Licenses
2a Distribution Nos.
and Stock, Asset
Management and
Project Management,
Operations Support
Management and
2b Finance & Accounting Nos.
2c Human Resource Nos.
Management
2d Purchase/ Contract Nos.
Management
2e Legal Nos.
Page 117 of 390

B1 Annual Technical Support (ATS) for ERP SaaS Application Licenses and Others (OEM) supplied till Go-live
ERP Proposed No.

of Units of Unit Rate (In
S.No. Licenses Rs.) (Excl GST % GST Amount
required for GST)
Application Post Go-Live
3 Management Self- Nos.
Service
4 Employee Self- Nos.
Service & Payroll
5 Development User Nos.
7 Asset Life Cycle Lumpsum
Management
1 Helpdesk Lumpsum
Management Tool
(SaaS Based)
Management (SaaS
Based)
any
4 Other Lumpsum
Tools/Software (SaaS
Based)
Page 118 of 390

Note:
1. Year2#: The definition of Year 2 will be considered as the first year of operations of the envisaged ERP system after Go-Live i.e. Go-Live of ERP solution
at all the locations and declaration of Go-Live, duly approved by JPDCL. The start of stabilization period will be treated as start of the Year 2.
2. Other applicable conditions are mentioned in (TABLE: A)
Table: B2 (Post Go-Live) – Supply and Annual Technical Support (ATS) for ERP SaaS Application Licenses and Others (OEM) for roll-out
B2 Rates for ERP SaaS Application Licenses for the purpose of roll-out
ERP Unit Rate
Software No. of Units of (per block) Total Cost
Unit of Total Cost
S.No. Licenses per GST % GST Amount Including GST
License Licenses (In Rs.) (Excl (excl GST)
Block (per block)
Application GST)
(1) (2) (3) (4) (5) (6)= (4)*(5) (7) (8)=(6)*(7) (9)=(6)+(8)
Supply of ERP SaaS Application Licenses of additional ERP SaaS Application Licenses (in Blocks of numbers specified below)
1 All Access Licenses Block 5
2 Module Access Block 100
Licenses
3 Management Self- Block 10
Service
4 Employee Self- Block 500
Service & Payroll
Annual Technical Support (ATS) for Supply of ERP SaaS Application Licenses of additional ERP SaaS Application Licenses (in Blocks of numbers
specified below)
1 All Access Licenses Block 5
2 Module Access Block 100
Licenses
Page 119 of 390

B2 Rates for ERP SaaS Application Licenses for the purpose of roll-out
ERP Unit Rate
Software No. of Units of (per block) Total Cost
Unit of Total Cost
S.No. Licenses per GST % GST Amount Including GST
License Licenses (In Rs.) (Excl (excl GST)
Block (per block)
Application GST)
3 Management Self- Block 10
Service
4 Employee Self- Block 500
Service & Payroll
Note:
1. Price per block (with each block inclusive of the number of licenses indicated in the above table) shall be required to be quoted in Table B2.
2. Other terms and conditions are as per specified under Section 6, Sub-section 4 and Table B1 of this Form.
Table : C ERP Application Implementation and O&M Services

Total
Unit Rate Total Cost Amount
S.No. Item Unit Quantity GST % GST Amount
(Excl GST) (Excl GST) Including
GST
(1) (2) (3) (4) (5) (6)=(4)*(5) (7) (8)=(6)*(7) (9)=(6)+(8)
Implementation – (Till Go-Live)
9. Implementation, Integration, Lumpsum 1
Customization, Realization,
Testing and GO-Live as per
SoW
Page 120 of 390


Total
GST
10. Operations and Maintenance for 48 Months (Including Helpdesk) –
(Post Go-Live)
2.1 Operations and Maintenance Lumpsum (Per 12
for Year 2 Month)
for Year 3 Month)
for Year 4 Month)
for Year 5 Month)
Rates for Engagement of specific resources for the purpose of change request
11. Functional Consultant: Man-Months 1
3.1 Functional Consultant for Man-Months 1
Finance & Accounts
Payroll & HR Management
Procurement Store and
Material management
Asset Life Cycle management
Page 121 of 390


Total
GST
Utilities (Distribution
Operations)
Utilities Billing
Citizen services
12. Solution Architect Man-Months 1
13. Technical SME Consultants Man-Months 1
14. Sr. Developer Man-Months 1
15. Developer Man-Months 1
16. Tester Man-Months 1
17. Helpdesk Operator Man-Months 1
Page 122 of 390

Table : D Data Migration

Data Migration
S.No. Item Unit Quantity Total Cost (excl GST % GST Amount Total Cost
GST) Including GST
(1) (2) (3) (4) (5) (6) (7)=(5)*(6) (8)=(5)+(7)
Data Migration
1 (Data Checking, Data Lumpsum 1
Identification and preparation,
Data Extraction, Data
Assessment, Data Mapping and
cleansing, developing data
conversion scripts, Data Loading,
Testing and Verification, Data
Reconciliation etc.)
Note: Estimated volume of Data migration Refer 'Capacity Estimates'
section of the RFP
Table : E Incidental Charges

Incidental Charges
S.No. Item Unit Quantity Total Cost (excl GST % GST Amount Total Cost
GST) Including GST
(1) (2) (3) (4) (5) (6) (7)=(5)*(6) (8)=(5)+(7)
1 Incidental Charges (Including Lumpsum 1
Travelling / Boarding / Lodging
etc.) during the contract period
Page 123 of 390

Note:
i. The total Cost would be considered for commercial evaluation of the bids, JPDCL reserves the right at the time of award of Contract to increase or
decrease the quantity of goods and/ or services from what was originally specified while floating the RFP without any change in unit price or any other
terms and conditions
ii. Itemized rates shall be valid for one year and basis on these rates JPDCL may increase scope/ BoM as change order upto 25% of total cost of the Project.
Additional, scope/ BoM shall be coterminous with the original project.
iii. The price quoted by ERPSI is including freight, forwarding, transit, insurance and installation charges, GST and/or other applicable levies, taxes, as per
the commercial format shall be considered
iv. Nothing in the Contract shall relieve the ERPSI from its responsibility to pay any tax that may be levied in India on profits made or otherwise by it in
respect of the Contract
v. The ERPSI shall comply with the proper byelaws and legal orders of the local body or public authority under the jurisdiction of which the work is
executed and pay all fees and charges for which he may be liable. Nothing extra shall be payable on this account.
vi. All the item names and description for each line item shall be used as mentioned in the Bill of Material of scope of work
vii. Unit price is required to be mentioned for each line item/ component mandatorily
viii. Any increase or decrease in the rates of the applicable taxes or any new levy on account of changes to the account of the Authority (JPDCL)
Page 124 of 390

JPDCL
Section 6. ERP System Requirements and Service Level Agreement

1. Current State of the System
1.1 Current System Software and Services
System Software and Services refer to applications and services provided by applications / modules /
subroutines signed to run the user application programs and hardware on which the user application
programs are deployed. System Software and Services act as the interface between the hardware and
user applications.
Key System Software and Services that are envisaged to be implemented as part of proposed
Enterprises Resource Architecture are detailed in the following sections. All components specified
below shall be in line with requirements specified for Enterprise Architecture and shall be easily
integrated with other systems of the State while adhering to design specifications of all compliance
rules.
1.1.1. PFMS Portal

The Public Financial Management System (PFMS) is a web-based online software application
developed and implemented by the Controller General of Accounts (CGA), Department of
Expenditure, Ministry of Finance, and Government of India. PFMS started during 2009 with the
objective of tracking funds released under all Plan schemes of Government of India, and real time
reporting of expenditure at all levels of Programme implementation.
All the expenses related to central schemes are paid via PFMS portal.
Functionality of the PFMS Portal expected to be integrated with the envisaged ERP System shall
involve the following; but not be limited to
• Invoice submission/upload related to CG schemes

• Payment initiation via creation of Payment batches
• Approval mechanism
• Payments to treasury post approval
1.1.2. JK Paysys
JK Paysys is a URL based NIC portal where all the types of bills are uploaded (Salary & Non-Salary).
In this portal DDO has two types of role, Maker (Bill Preparer) and Checker (Bill Approver). Their
Username is same, but passwords are Different. Once Checker approves Bill, Bill is sent electronically
to Treasury. Both Checker/Maker can see status of his bill in Dashboard. JK Paysys is integrated with
BEAMS.
Functionality of this Portal expected to be integrated with the envisaged ERP System shall involve the
following; but not be limited to:
• Vendor should be able to upload the Invoice/RA Bills

• Approval mechanism
• Payment initiation
• Integration with BEAMS Portal
Page 125 of 390

JPDCL
1.1.3. BEAMS Portal

It’s an online computerized web-based application for preparation and authorization.
BEAMS (Budget Estimation Allocation and Monitoring System) are unique and unprecedented
initiatives. The integration of BEAMS and PaySys enabled the availability of real-time data of works to
the citizens through the EMPOWERMENT portal which they can access without any username and
password.
BEAMS enables the Interface between function DDO and Payment system, and Reporting and
expenditure reconciliation system with AG/Accounting authority.
• Generation of real-time data of JK Paysys and Budget details from BEAMS
• Integration with JK Paysys Portal
• Integration with Treasury/PAO system
1.1.4. CCB (Customer care & Billing)
It manages customer information and processes associated with the customer lifecycle including:
• Sales and marketing, and

• program management.
This is the consumer billing software of JPDCL. It will get the data from HES & MDM system and it will
generate the electricity bill and remit to consumer and it will have the data of customer receipt also.
• Dashboard related to consumer units & receipt amount.

1.1.5. HES/MDM
Head End System (HES) is used for collecting initial data from meters. The system is presently provided
by Techno Electric and Anvil cables.
Meter Data Management (MDM) system provided by Abjayon System in JPDCL. Smart Metering
comprises of Smart Meters, Data Concentrator Units (DCUs)/gateways/routers/access points, Head
End System (HES), Meter Data Management System
MDMS communicating over bi-directional Wide Area Network (WAN), Neighbourhood Area Network
(NAN)/Field Area Network (FAN) and Home Area Network (HAN). Multiple smart meters can connect
to a DCU/gateway/router/access point which in turn send aggregated data to the HES. This DCU (Data
Concentrator Unit holds three Antenna, down Antenna connect with Smart meter and top antenna
Range from (1500 mtrs to 2000 mtrs) at last communicate with HES. This HES contains GPRS Sim cards
for Communication.
The smart meter can also directly communicate with the HES using appropriate WAN technologies
(for example smart meters can directly send data to the HES on servers in the control room). The
Meter Data
Page 126 of 390

JPDCL
Management System (MDMS) collects data from the HES and processes it before sharing with billing
system and other IT applications Home Area Network (HAN).
The key features that make a meter ‘smart’ are the addition of a communication module capable of
two-way Machine to Machine (M2M) communications and a remote connect/disconnect switch. A
smart meter is an electronic device that records consumption of electric energy in intervals of an hour
or less and communicates that information at least daily back to the utility for monitoring and billing.
Smart meters enable two-way communication between the meter and the computers in the utility
control center. Smart Meters usually have real-time or near real-time sensors, power outage
notification, and power quality monitoring features.
Using an MDM platform,
• Enhanced security.
• To protect the business data.
• Improved productivity.
• Application control.
• Optimized data collection.
• Risk management.
• Cost saving.
• Leading MDM vendors.
• Integration of MDMS with middleware.
• Integration of MDMS with other systems such as billing, collection, customer care,
connection/disconnection, MS etc.
1.1.6. BUSY Software
It’s a business accounting software covers complete financial accounting, multi-location inventory,
multi-currency, multi-tax capabilities, multi-branch management, order processing, payroll, MIS,
Invoicing, etc., which helps in making informed decisions to scale the business.
There are multiple users IDs are created as per the roles. Every department is punching the data in the
software and CA appointed by the corporation is managing the overall status of the software.
This software is expected to be sunset and functionality pertaining to this software is expected to be
configured/ customized/enhanced in the envisaged ERP System. Detailed functional requirement
specifications pertaining to the processes of this software (and expected to be mapped in the modules
of the envisaged ERP system) is provided in the RFP.
1.1.7. DT Management Online Portal

Damage Transformer management Online Portal is used to complete care about the Damage /New
transformer.
This online portal is Accessible by the three Roles Junior Engineer/Senior Engineer/ Workshop. In
Junior Engineer logging get the Dashboard where he will create the Damage transformer initiate under
Page 127 of 390

JPDCL
the section DTR Status where select feeder details, sub-station name, Distribution transformer and
generate the docket/unique ID as challan. This Challan is only visible to workshop Dashboard if they
approve it then come to ED Workshop. In Workshop, Joint Inspection has been initiate to estimate
transformer for items, finance needed and finally Job card Creation has done with (Inspection Id) the
process is available under the log book. Certificates generate amount of work done to MD Office.
In Request tag, two option are available 1. Initiated Requests, 2. Approve. The Approval Process under
the supervision of Executive officer only. They are the only one when damage initiated and once
transformer back then he is responsible to create new UID and Latch with feeder.
In Damage Status, we can check the count of Damages in the current financial year.
In stock section tag, check the Repair, Damaged, Buffer stock of the transformer. In this section we
can also change the ownership of the transformer e.g. Centre Store give transformer to Receiving
Station.
At last, once the Repaired transformer successfully delivered then certificate has been generated.
Based on this certificate, payment process is initiated by the DDO to Managing Director.
This portal is expected to be sunset and functionality pertaining to this portal is expected to be
configured/ customized/enhanced in the envisaged ERP System. Detailed functional requirement
specifications pertaining to the processes of this portal (and expected to be mapped in the modules
of the envisaged ERP system) is provided in the RFP.
1.1.8. JK HRMS (Human Resource Management System)

It has every user’s updated data within it. It monitors and coordinates their working as well with a
view to deal with different nature of issues, different sections have been set up, viz. Services Section,
Vigilance Section, Cabinet Section, Coordination Section, Administration Section, Legal Section,
Establishment Section, Monitoring section, Planning and Statistics section, Accounts section, Official
languages section, IT initiatives section.
In an endeavour to move towards e-Governance, General Administration Department (GAD) has
always focused on providing services in electronic mode and has ensured transparency, efficiency,
accountability, probity, accessibility and affordability in the system. To cite examples, GAD has added
many feathers in its cap with remarkable achievements like JK-HRMS (Human Resource Management
System).
• Integration of employee data, Admin data.
1.1.9. JK CPIS
The scope of the project is to capture employee profiles as well as office profiles in the CPIS database
of all the departments, spread over in the entire state of Jammu & Kashmir.
It also envisages to keep UpToDate information of employees, when they are promoted, transferred,
or retired etc. It also aims to assign a unique Employee Identification Number to all the employees for
future references. Further this CPIS database can be used for electronic service book and GPF.
Page 128 of 390

JPDCL
As per direction of Finance Department, J&K it is responsibility of DDO to modify or add new employee
data in CPIS system. Since CPIS is integrated with Treasury/PAO System. So DDO keep updated
employee personal and salary details.
E-mail from the official email Id of the DDO should be sent to E-mail Id: cpis-jk@nic.in for the following:
• Update the correct bank branch code of DDO/Employee
• Delete Employee Id, if there exist two or more Employee Id’s
• If double entry of Aadhar/PAN number visible for any Employee.
• Update DDO designation.
• Any other
• Integration wrt update or addition or any other data wrt employee data.
• Integration wrt changes wrt promotion/transferred/retirement.
• Integration with Treasury/PAO system.
1.1.10. EPM - Employee Performance Monitoring Portal
This portal has been designed and deployed to capture the monthly work performance of the employees and
officers of the Government of Jammu & Kashmir and the appraisal thereof by their respective Reporting /
Controlling Officers. The aim is to provide a mechanism for self-appraisal to the government employee on one
hand and, on the other hand, to provide a readily available means to the higher authorities for monitoring and
better human resources management.
For using the system, an Employee shall register as a new user using their CPIS ID and create a password based
upon the OTP they receive on their registered Mobile Number though SANDES App. A user should download
the SANDES Mobile App. User will submit his working and achievements during the month and submit for the
approver.
Functionality of this Portal expected to be integrated with the envisaged ERP System shall involve the following;
but not be limited to:
• Integration wrt data entry of monthly employees self-appraisal performance.
1.1.11. PAR (Property Annual Return)

As per Sec 9 (2) of J&K Public Men and Public servants declaration of Asset and other provision Act, 1983 lays
down that it shall be incumbent on the part of every public servant to submit annual returns of the assets held
by him and his family members in the month of January every year and shall indicate the reason for increase, if
any, in the assets and source thereof.
With a view to make the process of filing of property returns employee friendly, the Govt of J&K has launched
online portal for filing the annual property return by each & every J&K Govt employee as mandate under the
J&K Public Servants Declaration of Assets Act & Rules made thereof every year ending 31st Dec, by or before 31st
Jan of the next calendar year.
• Integration of data entry & updation wrt property data.
Page 129 of 390

JPDCL
• Approval mechanism.
1.1.12. Annual Performance Report (Sparrow)

The electronic Annual Performance Appraisal Report (SPARROW) is an online system based on the
comprehensive performance appraisal dossier that is maintained for each member of Service by the State
Government/ Central Government. The aim of the system is to facilitates the electronic filling of PAR by officers
in a way that is not only user friendly but also allows to fill from anywhere anytime as per their convenience.
PAR filling process starts at the beginning of the financial year. The PAR Manager creates the workflow of the
individual officer. The custodian generates the PAR of the respective Organization officers and sends the blank
PAR forms to the individual officer. The officer fills the PAR for further submission to his/ her Reporting officer.
The PAR moves from Reporting officer to Reviewing officer and to Accepting officer mandatorily marking CR
Section a slip.
The SPARROW application is compatible in all the three browsers i.e. Internet explorer, Mozilla Firefox and
Chrome.
• Integration wrt data entry of annually employees self-appraisal performance.
1.1.13. Feeder Online Portal

It’s an online portal where anyone can get the information about
A. AT&C Loss
• AT &C Loss report at various level (Corporation level/Division wise/Sub-division wise/Feeder
wise/Feeder Manager wise) for specific date range.
• AT&C Losses Improvement progress of JPDCL
• Year month wise Revenue Billed Trajectory
• Year month wise Revenue Collected Trajectory
B. e Meter Reading Sheet at Corporation/Division/Sub-Division level.
This portal is expected to be sunset and functionality pertaining to this portal is expected to be configured/
customized/enhanced in the envisaged ERP System. Detailed functional requirement specifications pertaining
to the processes of this portal (and expected to be mapped in the modules of the envisaged ERP system) is
provided in the RFP.
1.1.14. GEMS Portal

Government e-Marketplace portal is a portal setup for procurement of most types of goods by the government
offices. JPDCL is using this portal as a mandate part by government for procurement.
1.2 Ongoing IT Projects of JPDCL

1.2.1. Smart Metering
At present installation and integration of 57500 smart meters with existing Oracle Utilities CCB
product is being carried out at various locations of Jammu. This project includes following modules.
Page 130 of 390

JPDCL
Modules Solution
Meter Data Management Oracle Utilities Product
Head-End System Landis & Gyr HES
1.2.2. SCADA and DMS

In this project, 54 Nos. 33/11 KV Receiving Station are being integrated with SCADA Data Centre at
B.R. Ambedkar Chowk, Jammu. Once integrated, these receiving stations will be monitored and
managed from SCADA DC. The associated 11 KV network of these 54 Receiving Stations shall be
managed by Distribution Management System (DMS) integrated with SCADA with the aid of
sectionizers, FPI etc.
1.3 Existing IT Infrastructure
The existing IT infrastructure JPDCL comprises of 55 servers along with associated network at Data
Centre and 47 servers along with associated network at Disaster Recovery Centre. The existing DC/DRC
is connected to 11 field offices out of 48 field offices of JPDCL via VPN based MPLS connectivity and
serves 3.5 lac consumers out of 10.60 lac consumers of JPDCL. The DC/DRC equipment such as servers,
storage etc have attained end of life and need urgent replacement for uninterrupted functioning of
DC/DRC. Moreover, the existing IT infrastructure does not have the capacity as well as processing
power to accommodate 7.1 lac consumers of JPDCL which are being serviced with outdated
distributed Windows Based SQL servers. There are total of 44 standalone Windows Based SQL servers
that have attained end of life and do not have processing power even to service the existing
2. Overview of the envisaged ERP System

2.1 Envisaged Solution
Typical System Architecture of the envisaged ERP System is presented below.
Page 131 of 390

JPDCL
The System Architecture for the envisaged ERP System shall comprise of the following Layers at
minimum; but not be limited to:
• Users.
• Communication Channels Layer.
• Security Layer.
• Application Layer.
• Data Layer.
• Common Services Layer.
Page 132 of 390

JPDCL
2.1.1. Users of the System Architecture for the envisaged ERP System
Typical Users expected to the utilize the functionality / services of the envisaged ERP System shall
include; but not be limited to:
• JPDCL ERP Users:
o Senior Management.
o Functional Core Team.
o JPDCL End-Users.
o Management Report Users.
• ERP End-Users from other (external) stakeholders.
• Consumers.
• Vendors.
• Helpdesk Personnel.
• System Administrators.
• Governance Team Members.
• Auditors.
Functionality / services of the envisaged ERP System expected to be utilized by various Users have
been elaborated in the RFP.
2.1.2. Communication Channels Layer

Communications Channels Layer is expected to comprise the following at minimum; but not be limited
to:
• Web Portal
• Mobile App
• Email
• SMS
• WhatsApp
• JPDCL Daak
• JPDCL Field Offices (from CFC perspective)
• India Post Offices (from CFC perspective)
• J&K Bank Khidmat Centers (from CFC perspective)
Methodology for accessing functionality / services of the envisaged ERP System expected to be utilized
by various Users have been elaborated in the RFP.
2.1.3. Security Layer

The envisaged ERP System is expected to be consider the Zero Trust Principles while designing the
System. As part of their ‘ICT Infrastructure Architecture and Design’ and ‘Software Architecture and
Design’ deliverables, ERPSI shall be expected to provide a roadmap for scaling Zero Trust controls /
tenets throughout the Project duration.
Page 133 of 390

JPDCL
In addition, the components of the Security Layer shall be expected to meet all security-related
compliances specified in the RFP.
Security Layer is expected to comprise the following at minimum; but not be limited to:
• Authentication.
• Authorization.
• Security Solutions.
• Security Controls.
• Recovery Solution (for Disaster Recovery Centre: DRC).
• Enterprise Back-up Solution.
• Cloud Traffic Monitoring Tool.
• CMDB Tool.
2.1.4. Application Layer
Application Layer is envisaged to comprise of two basic components:
• Modules from the SaaS-based ERP Application.
• Existing Applications of JPDCL through integration with the SaaS-based ERP Application.
Details of modules and Existing Applications of JPDCL that are expected to be integrated with the
envisaged ERP System have been elaborated in the RFP.
2.1.5. Data Layer

Data Layer is expected to comprise sum total of all data residing within the envisaged ERP System.
Major components in which the data comprised in the envisaged ERP System shall include the
• ERP System Data:

o Master Data
o Transaction Data
o Document Data
o Metadata
• Legacy Data
• Data being Backed-up
• Archived Data
• Audit Logs
2.1.6. Common Service Layer.
Common Services Layer is expected to comprise the following at minimum; but not be limited to:
• Identity Access Management system component
• Policy Management and Enforcement Services system component
• Enterprise Content Management system component
Page 134 of 390

JPDCL
• Workflow Management Engine system component

• SaaS-based tools for monitoring and management of the envisaged ERP system assets
• SaaS-based IT Helpdesk Management Software (for ERP Users)
• SaaS-based SLA Monitoring Tool
• SMS Gateway
• Email Gateway
• Payment Gateway
• Aadhar Authentication API
• DigiLocker API
• eSign API
• DSC verification system component
Page 135 of 390

JPDCL
3. Capacity Estimates
3.1 Estimation count of ERP User Licences
Estimated total count of ERP User License for the envisaged ERP System is presented below.
ESTIMATED NOTES PERTAINING TO THE LICENSE
# LICENSE TYPE
LICENSE COUNT TYPE / ESTIMATED LICENSE COUNT
1 All Access Licenses 31 Users covered under this User License
Types shall have access to all modules
of the ERP SaaS-based Application.
2 Module Access Licenses 863 Users covered under this User License
Types shall have access to specific
modules of the ERP SaaS-based
Application as indicated.
2a Distribution Operations 668
(comprising Inventory and
Stock, Purchasing / Contract
Management, Project
Management, Supply
Operations and Online Feeder
Management, Energy
Management, Operations
Support and Consumer Service
Management and Grievance
Redressal)
2b Finance & Accounting 97
2c Human Resource Management 96
2d Legal 2
3 Management Self-Service 271 Users covered under this User License
Types shall have access to MSS in
addition to the specific modules of
the ERP SaaS-based Application as
indicated under Point No. 2.
4 Employee Self-Service & 5123 ESS and Payroll shall applicable for all
Payroll 5154 head-count of JPDCL. However,
Users covered under All Access
Licenses have NOT been considered
here (on account of their “all access”).
5 Development User 2
7 Asset Life Cycle Management - All assets covered under the
envisaged ERP System shall be
addressed by this License.
Page 136 of 390

JPDCL
Note:
1. Procurement of licenses shall be undertaken by JPDCL in multiple lots.
First lot shall be procured for enabling the Go-live as per the following numbers:
ESTIMATED LICENSE
# LICENSE TYPE
COUNT
1 All Access Licenses 20
2 Module Access Licenses 162
2.a Distribution operation (Inventory, Asset Management 125
and Project Management)
2.b Finance & Accounting 15
2.c Human Resource Management 10
2.d Purchasing / Contract Management 10
2.e Legal 2
3 Management Self-Service 100
4 Employee Self-Service & Payroll 2500
5 Development User 2
7 Asset Life Cycle Management -
Rest of the licenses shall be procured as pr the roll-out plan that shall be mutually discussed
by JPDCL and the ERPSI in lots as per the following numbers:
ESTIMATED LICENSE
# LICENSE TYPE
COUNT
1 All Access Licenses 5
2 Module Access Licenses 100
3 Management Self-Service 10
4 Employee Self-Service & Payroll 500
2. Since Asset Lifecycle Management License/(s) shall be required to cover all assets covered
under the envisaged ERP System, the License/(s) shall be procured at Go-live only.
Page 137 of 390

JPDCL
3.2 Estimation of the size of data for data migration
Estimates of data required to be migrated from existing applications is presented below

ESTIMATED DATA
S.No NAME OF APPLICATION NOTES
SIZE
DT Management Software 210 MB Data for FY 2022-23 and FY 2023-24
1 (as of the date of floating of the RFP)
Online Feeder Management 20 GB This system was launched during the
2 System (Urja Pravaah) current Financial Year.
BUSY Software 20 GB Data for FY2020-21 and FY 2021-22
pertains to closed transactions.
3 Data for FY 2022-23 is still under
closing.
Data for FY 2023-24 is open.
Size estimate of Document Data that is required to be migrated is presented below.
S .No TYPE OF TRANSACTION RELATED TO DOCUMENT DATA ESTIMATED DATA SIZE

1 Document Data pertaining to Open Transactions 210 GB
2 Document Data pertaining to Closed Transactions 105 GB
3 Total Document Data 315 GB
It shall be noted that the above tables present an estimate of data to be migrated. However, the actual data
that is required to be migrated may vary.
Page 138 of 390

JPDCL
4. Overview of the ERPSI Scope of Work

Activities under the Scope of Work for the Enterprise Resource Planning System Integrator (ERPSI) for
the design, configuration / customization, and maintenance of the Enterprise Resource Planning (ERP)
System shall comprise the following activities at the broad level:
I. Project Kick-off.
II. Set-up of Cloud-based ERP System.
III. Design, configuration / customization / enhancement of the envisaged Enterprise Resource
Planning (ERP) System.
IV. Acceptance Testing.
V. Data Migration.
VI. Training and Capacity Building.
VII. Set-up and operationalization of IT Helpdesk for the envisaged ERP System.
VIII. Implementation of cybersecurity considerations for design, configuration / customization /
enhancement of the envisaged Enterprise Resource Planning (ERP) System.
IX. Operations and Maintenance for 4 years.
X. Support pertaining to cybersecurity considerations during Operations and Maintenance.
XI. Project Documentation.
The System Integrator shall offer COTS ERP solution on Software as a service (SaaS) model. The
proposed SaaS solution from OEM shall be provided as a dedicated private cloud hosted on MeitY
empaneled cloud service provider (CSP). The CSP should be certified by COTS ERP OEM and should
have a reseller relationship with the OEM. The SaaS solution shall have the flexibility of being hosted
on multiple CSPs and SI/OEM shall provide the flexibility to change CSP at any point of time during
contract with no additional cost to the customer. The SaaS service should be offered with minimum
99.7% contractual SLA at the application level in production environment which should be supported
by minimum 99.95% uptime SLA on Cloud from the MeitY empaneled CSP.
Scope of SaaS OEM
• Subscription based model - OEM’s end-to-end subscription model shall include ERP software,
infrastructure, managed services, security & governance, updates, patches, and requisite
compliances with government regulations applicable in India and abroad.
• COTS OEM Reference Architecture - Should be deployed on OEM’s Reference Architecture out of
the box. These reference architectures should be mapped and evolved based on the product and
hyper scale operational best practices.
• Proximity to OEM Product Development - The access to the product development teams of
OEM’s should enable the support teams to resolve the system issues faster and keep the
systems up to date with product related recommendations.
• Full Stack SLA’s - SaaS OEM shall provide industry-leading SLA’s up to the application layer not
less than 99.9% availability committed contractual SLA on production environment directly from
the COTS ERP OEM
Page 139 of 390

JPDCL
4.1 Project Kick-off

Activities that shall be required to be undertaken by the ERPSI pertaining to Project Kick-off shall
include the following, but not be limited to:
• Deploy the Project Team onsite including, but not limited to:
o Project Manager
o Solution Architect
o IT Infrastructure Lead
o Functional Experts.
• Coordinate with JPDCL SPOC for organizing a Project Kick-off Meeting.
• Preparation and submission of the following documentation at minimum; but not limited to:
o Project Charter including the following sections, but not limited to:
▪ Executive summary: High-level summary including Project’s Background
information, Purpose of the Project at a high-level, issues / problems the
Project that are envisaged to be corrected, etc. at minimum.
▪ Purpose of the Project: Detailed description of the Project Need, Project
objectives, Success Criteria envisioned, Goal Statements, etc. at minimum.
▪ Project Description: Defining contours of the Scope of Work, Entry and Exit
Criteria at the Project-level, Scope Exclusions, etc. at minimum.
▪ Statement of Project Requirements: For providing guidance to the
stakeholders involved pertaining to the contours within which the Project
Execution shall take place.
▪ Assumptions.
▪ Constraints.
▪ Project Risks: High-level definitions.
▪ List of Project Deliverables.
▪ Summary of Project Milestones.
▪ Project Approval Requirements.
▪ ERPSI Project Team: High-level view.
▪ Governance Structure of the ERPSI Project Team: With individuals identified
for each position.
o Project Plan:
▪ High-level.
▪ Module-wise for ERP implementation.
▪ Track-wise for Infrastructure set-up.
Assumptions and dependencies are expected to be covered in detail.
o Resource Deployment Plan – including details of deployment of onsite and offsite
resources.
o Communication Plan.
Page 140 of 390

JPDCL
o Risk Management Plan.

o Issue Management Procedure.
o Escalation Management Procedure:
▪ Escalation Management Mechanism pertaining to the deliveries of ERPSI.
▪ Escalation Matrix for the ERPSI.
o Quality Management Procedure.
o Change Control Procedure.
Setting up of the following processes / mechanisms for the following at minimum; but not limited
to - for being accessible to all stakeholders:
• Project Monitoring.
• Schedule for Weekly Reviews, Project Implementation Committee, Steering Committee
Meetings.
• Issue Register and procedures for handling Issues.
• Risk Register and procedures for handling Risks.
• Identified communication channels.
• Requirement Traceability Matrix (RTM).
• Project Documentation Repository.
• Handling Escalations.
• Handling Change Requests.
4.2 Set-up of Cloud-based ERP System

Activities that shall be required to be undertaken by the ERPSI for Set-up of Cloud- ERP System shall
include the following, but not be limited to:
• Infrastructure Requirement Study, Sizing and ICT Infrastructure Architecture and Design.
• Deployment of Cloud instances and other ICT Infrastructure components.
4.3 Infrastructure Requirement Study, Sizing and ICT Infrastructure

Architecture and Design
• ERPSI shall perform a detailed assessment of the underlying ICT Infrastructure requirements,
the number of locations, users, transaction volumes, concurrency, etc.
• ERPSI shall factor for three types of environments at minimum; but not limited to:
o Development.
o Staging.
o Production.
• ERPSI is expected to utilize the India Enterprise Architecture (IndEA) prescribed by the
Ministry of Electronics & Information Technology (MeitY), Government of India (GoI) for
Page 141 of 390

JPDCL
drafting the ICT Infrastructure Architecture. ERPSI may refer to other industry followed
frameworks for strengthening the ICT Infrastructure Architecture.
• The envisaged ERP System is expected to be consider the Zero Trust Principles while designing
the System. As part of their ‘ICT Infrastructure Architecture and Design’ deliverable, ERPSI
shall be expected to provide a roadmap for scaling Zero Trust controls / tenets throughout the
Project duration.
• Based on the assessment and requirements collected and identified during ‘Software
Requirement Study’, ‘To-be Process documentation, Gap Analysis and Business Process Re-
engineering’, and ‘Software Architecture and Design’, ERPSI shall work out and sizing for
Cloud-based instances.
• Sizing shall consider the following at minimum; but not be limited to:
o Envisaged transaction volume of:
▪ JPDCL Officials / Staff.
▪ External stakeholders (Power Development Department (PDD) / Jammu and
Kashmir State Power Transmission Company Limited (JKPTCL), etc.)
▪ Consumers.
▪ Integrated Systems.
o Year-on-year (Y-o-Y) increase in transaction volumes.
o User concurrency.
o Locations from where the envisaged ERP System shall be accessed.
o Types of devices that shall be accessing the envisaged ERP System.
o Types of connectivity that shall be utilized by devices to access the envisaged ERP
System.
o Typical data and document size, and frequency of generation / storage.
ERPSI shall be required to submit detailed volumetric analysis and workings of assessment and
sizing exercise undertaken – for all environments – JPDCL for consideration of completion of
respective deliverable / milestone.
• ERPSI shall prepare List and specifications of Cloud instances and the supporting / ancillary
services that shall be required to be procured from the Cloud Service Provider (CSP).
• While designing and architecting the Cloud-based ERP System, ERPSI is expected to consider
redundancy with paramount importance. ERPSI to ensure the 99.90% availability of the ERP
System.
• ERPSI to provision DR drill for a minimum of once in a year. The Cloud based Disaster
Recovery Centre (DRC) shall be made available for a minimum of 15 days on switch over
mode at 1:1 redundancy.
• ERPSI shall ensure that ERP system along with its supporting application software / third-
party services / tools shall be on the same Cloud for better integration and serviceability.
• Data backup shall be another important factor to be considered by the ERPSI while outlining
the ERP System. Further, ERPSI shall be required to provide an additional data backup to
JPDCL at / near JPDCL Head Office, Dr. B. R. Ambedkar Chowk, Jammu in; both, online (on
real time basis) and off-line modes, JPDCL is having the storage which can be looked for the
extension (Minimum Storage requirement is 20 TB).
Page 142 of 390

JPDCL
• ERPSI shall take special care to ensure all environments are secured appropriately. ERPSI
shall ensure that prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc.
• ERPSI shall also collect details the end-user ICT infrastructure and connectivity of JPDCL’s
Users for analysing the sufficiency of their specifications for operating the envisaged ERP
System.
• SaaS-based ERP Application and Design shall cover the following, but not limited to:
o Integration of:
▪ Helpdesk infrastructure.
▪ Non-IT components deployed at various offices of JPDCL.
▪ Components for PKI-enablement.
▪ Mobile devices of JPDCL Officials / Staff.
o Compliance to various JPDCL’s IT and Information Security (IS) Policies to
Architecture and Design of the underlying ICT Infrastructure of the envisaged ERP
System.
• Documentation expected to be prepared and submitted as part of ‘System Architecture and
Design’ shall include the following, but not be limited to:
o Infrastructure Requirement Study.
o Detailed volumetric analysis and workings of assessment and sizing exercise
undertaken (for all environments).
o Detailed analysis and workings undertaken for proving that the SaaS-based ERP
Application can address the requirements stipulated in the RFP and prescribed by
JPDCL stakeholders, and achieve the SLAs stipulated in the RFP.
o Populated Risk Register – first version.
• This ERPSI shall provide, supply, installation and configuration of all ordered equipment(s)
required at specified locations for the whole contract period along with the integration with
links provided from Primary and Secondary MPLS service provider & links provided by
department on SD WAN system.
• ERPSI shall draw out and specify detailed specifications for the SD-WAN Network for that
needs to be used for the ERP system for satisfactorily operations. ERPSI should prepare the
specifications of SD-WAN Network Services and submit the same to JPDCL for review. ERPSI
shall ensure that the recommended network shall be able to accommodate scaling up
requirements in future.
• The ownership of the data generated upon usage of the system, at any point of time during
the contract or expiry or termination of the contract, shall rest absolutely with JPDCL.
4.4 Procurement of Cloud based ERP

• ERPSI shall ensure that Cloud instances are procured from MeitY (Ministry of Electronics &
Information Technology)-empaneled Cloud Service Provider (CSP).
• Cloud Service Providers with the following capabilities at minimum; but not be limited to, shall
be selected by the ERPSI for this Project:
Page 143 of 390

JPDCL
o It is the responsibility of the ERPSI to define the security services that need to be
implemented for their workloads depending on the nature of the applications / data
hosted on the cloud.
o ERPSI need to ensure that the CSPs facilities/services are compliant to various security
standards as per the applicability (as mentioned below) and should be verified by third
party auditors.
▪ ISO/IEC 27001 or ISO/IEC 27002:2022 - Data Centre and the cloud services
should be certified for the latest version of the standards towards information
security management system along with information security, cybersecurity,
and privacy protection.
▪ ISO/IEC 27017:2015-Code of practice for information security controls based
on ISO/IEC 27002 for cloud services and Information technology
▪ ISO 27018 - Code of practice for protection of personally identifiable
information (PII) in public clouds.
▪ ISO 20000-1 – Information Technology service management system
requirements
▪ TIA 942 A/B &/or Uptime Tier III or higher – Telecommunication infrastructure
standard for Data Centre. (Self-certification by the CSP is allowed).
▪ Payment Card Industry (PCI) DSS - compliant technology infrastructure for
storing, processing, and transmitting credit card information in the cloud.
o CSP should suitably address all the potential risks and issues in cloud implementation
including data security and privacy, increased complexity in integration with existing
environments, vendor lock-in, application portability between different platforms,
exit management / Transition-Out Services etc.
o All Services including data should be hosted in India.
o Exit Management / Transition-Out Services -The responsibilities of the CSP during the
Exit Management Period need to be agreed upon with the Utility and they should
assist the Utility in migrating the data etc.
o The responsibilities of CSP/MSP include migration of the data, content, and any other
assets to the new environment or on alternate cloud service provider‘s offerings and
ensuring successful deployment and running of the Utility‘s Solution on the new
infrastructure
o SLA of 99.814% availability is offered by the CSP.
o Encryption of data both in rest and transit is allowed to be enabled.
o Conducting of Vulnerability Assessment and Penetration Testing shall be allowed to
be as per schedule communicated in advance.
o Audit trails / logs for the ICT Infrastructure shall be made available by the CSPs to
JPDCL and ERPSI in the event of a cybersecurity incident / breach.
• Required number of Cloud instances with requisite specifications shall be procured by the
ERPSI for the complete duration of the project – i.e. Implementation Track, and Operations
and Maintenance Track for 4 years.
• ERPSI shall remain the single point of contact for all activities pertaining to cloud services.
Page 144 of 390

JPDCL
• Proof of purchase of subscriptions of Cloud Instances, Internet Bandwidth, other components

/ services in the name of JPDCL (wherever possible) (wherever required) shall be required to
be submitted by the ERPSI to JPDCL for consideration of completion of respective deliverable
/ milestone.
4.5 Deployment of Cloud based ERP

• ERPSI shall be required to set-up the Cloud instances for the following environments, at
minimum; but not be limited to, as per the sizing arrived by them during the ‘Infrastructure
Requirement Study, Sizing and ICT Infrastructure Architecture and Design’ phase:
o Development.
o Staging.
o Production.
• ERPSI shall ensure that all software / Cloud / hardware components required to meet the
requirements of this Project are implemented as part of the envisaged ERP System. ERPSI
shall also ensure that requisite tools for monitoring the health and performance of the SaaS-
based ERP Application. No additional costs shall be paid by JPDCL towards any components
that have been missed out during the Bid Submission unless there is a legitimate Change
Request arising from change of scope related to ICT infrastructure / functionality impacting
sizing of the envisaged ERP System or technical feature requirement or SLA requirement.
• ERPSI shall ensure all-inclusive security of all software / Cloud / hardware components
across all environments and technologies employed.
• Documentation expected to be prepared and submitted as part of ‘Deployment of Cloud
instances and other ICT Infrastructure components’ shall include the following, but not be
limited to:
o Deployment Architecture Diagrams:
▪ Overall Deployment Architecture Diagram indicating all components.
▪ Detailed Deployment Architecture Diagrams for each sub-system
▪ Deployment Architecture Diagrams for Cloud Instances providing details of
ERP and supporting third-party services / tools running on them.
o Inventory Report:
▪ SaaS-based ERP Application (supporting application software / third-party
services / tools).
▪ SaaS-based ERP Application Health and Performance Monitoring Tools.
o Installation and Commissioning Report.
o Integration documents for:
▪ Helpdesk infrastructure.
▪ Non-IT components deployed at various offices of JPDCL.
▪ Components for PKI-enablement.
▪ Enablement of access of system by Mobile devices of JPDCL Officials / Staff.
o Up-to-date Configuration Management Database (CMDB).
o Copy of Configuration files (for safe-keeping in Escrow Account).
Page 145 of 390

JPDCL
o Copy of documentation from OEMs pertaining to Product details, Data Sheets,

Installation Guides, Integration Guides, etc.
o Updated Risk Register and Issue Register.
Page 146 of 390

JPDCL
5. Design, configuration / customization / enhancement of the envisaged

Enterprise Resource Planning (ERP) System
Activities that shall be required to be undertaken by the ERPSI for design, configuration /
customization, and maintenance of the envisaged ERP System shall include the following, but not be
limited to:
• Conducting sensitization workshops.
• Software Requirement Study.
• To-be Process documentation, Gap Analysis and Business Process Re-engineering.
• Software Architecture and Design.
• Procurement of licenses.
• Configuration / Customization / Enhancement (new development) of SaaS-based ERP
Application.
ERPSI is expected to this phase in accordance with the principles of Secure Software Development
Life Cycle (Secure SDLC)-based methodology.
5.1 Conducting sensitization workshops

Activities that shall be required to be undertaken by the ERPSI pertaining to conducting sensitization
workshops shall include the following, but not be limited to:
• Conduct senior management workshops for setting the overall context with respect to the
Project and the expectations from the leadership and Project Sponsors of JPDCL.
• Conduct walk-thorough of SaaS-based ERP Application proposed by ERPSI to demonstrate the
Solution and impact of the ERP implementation on day-to-day working of JPDCL Officials /
Staff.
• Identify Functional groups and SPOCs for the same from JPDCL. Conduct specific discussions
with Functional Groups for setting expectations on the upcoming activities with them.
• Distribute reference material and templates to the members of the Functional Groups.
• ERPSI shall organize additional meetings with the Functional Groups as part of this phase to
ensure that all questions of the members of the Functional Groups are answered before they
start their activities.
Key stakeholders who are expected to participate in the sensitization workshops shall include the
following at minimum; but not be limited to:
• Leadership: JPDCL leadership who shall be sponsoring and guiding the Project strategically.
• Process Owners: Officials who shall be in-charge of the end-to-end process under their
jurisdiction. The processes under an Official may or may not comprise a complete ERP module
and / or may have functionality across ERP modules.
• Data Owners: Officials who shall be in-charge of all data within a process under their
jurisdiction. The data under an Official may or may not comprise a complete database table.
Page 147 of 390

JPDCL
Typical areas that are expected to be covered by the ERPSI under these sensitization workshops from
the perspective of creating awareness amongst the stakeholders are as follows:
• What the new optimized system would look like?
• How much does the processes and system change? How do we prepare for these?
• What new policies and procedures are needed to support this new scenario?
• How do we build a citizen centricity to the various services?
• How to shift from a function-oriented work performance to a service oriented performance?
• How to shift from output-based assessments to well-defined outcome-based assessments?
Typical modules expected to covered under sensitization workshop shall include, but not be limited
to the following.
Module Coverage
Change • To explain the need for change.
Management for • To highlight the areas of concern and needs improvement dimensions.
Leadership
• To establish, understand and sensitize the impact of change and
ensure smooth adoption.
• To elaborate on how to manage the various facets of change.
• To identify challenges and providing change solvent strategies.
• To share experiences - Successes Stories and Challenges.
• To train the leaders to nurture organizational culture that would be
receptive and positive towards change.
• To train leaders how collaborative leadership through dialogue,
discussion and critique would bring in a smooth transition.
• To train leaders to embrace the resistance and trust the process.
Business Process Re- • To explain about BPR, and its importance for the Project.
engineering • To undertake training for new processes and their requirements.
• To train the Officials in facilitating efficient usage of the whole system.
• To train the Officials to enable them to contribute through new
processes.
Page 148 of 390

JPDCL
5.2 Software Requirement Study

Activities that shall be required to be undertaken by the ERPSI during Software Requirement Study
shall include the following, but not be limited to:
• ERPSI shall perform the detailed assessment of the functional, non-functional and technical
requirements pertaining to the envisaged ERP System and document the same.
• ERPSI shall identify the processes and functionality that are envisaged for being available
through the Mobile App.
• In addition, the ERPSI has to carry out sufficient assessment of existing applications for
ensuring proper integration with the envisaged ERP System. Details related to integration
planned by JPDCL shall be captured in the ‘Software Requirement Study’ documentation.
• ERPSI shall also undertake study of prevailing acts, rules, guidelines, manuals, sectoral
CERTs, etc. followed by JPDCL for driving their operations. ERPSI shall capture all relevant
pointers such that compliance to the prevailing acts, rules, guidelines, manuals, sectoral
CERTs, etc. is ensured as part of the design, implementation and operations of the envisaged
ERP System.
• ERPSI shall consider all supporting modules / functionality / features that shall impact the
eventual configuration of the envisaged ERP System during the Software Requirement Study
phase – supporting modules / functionality / features shall include, but not be limited to:
o Identity and Access Management.
o Enterprise Content Management (including Document Management System).
o Enterprise Workflow Management.
o Knowledge Management - including Online help, CBT-based training, etc.
o Helpdesk Operations (for ERP Users).
o Management Information System (MIS), Reporting, Dashboards and Analytics.
o Creation of Master Data – including implementation for standard taxonomies.
o Migration of Transaction Data.
o Portals – JPDCL, Consumer, CFC, etc.
o Enablement of PKI components for integration for Digital Signature Certificates.
• In addition, Key Performance Indicators (KPIs) shall be defined jointly by ERPSI and JPDCL for
the SaaS-based ERP Application for allowing measurement of outcomes of the Project.
• The ‘Software Requirement Study’ documentation shall include the following, but not limited
to:
o List and detailed description processes and sub-processes of JPDCL that are envisaged
to be covered in the SaaS-based ERP Application and the Mobile App.
o List and description of the existing IT Applications used by JPDCL (from integration
perspective).
o List of integrations envisaged by JPDCL.
o List of supporting application software / third-party services / tools requirements.
o List of non-technical and technical requirements gathered during discussions.
Page 149 of 390

JPDCL
o List of prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. that being
followed by JPDCL for driving their operations. Important clauses that are anticipated
to have an impact on the implementation of the envisaged ERP system shall be
identified.
o Organization Structures at various levels – JPDCL, Departmental, Sub-departmental,
functional, etc. (including no. of employees / staff).
o User Access Control and Authorization Matrixes (function / process / sub-process-
wise).
o Escalation Matrixes (function / process / sub-process-wise).
o Number and outline / format of MIS and other Reports of JPDCL that are expected to
be implemented, and overall requirements pertaining to MIS, Reporting, Dashboards
and Analytics.
o Volume of transaction data expected to be migrated.
o Formats of documents, average size of documents across categories and total volume
of documents required to be migrated.
o Expectations pertaining to the User Experience of ERP Users from the envisaged ERP
System - User Interface and collaboration requirements.
o Outline of the Mobile App and various Portals – features and functionality other than
processes and sub-processes.
o KPIs for assessment of outcomes of the Project.
o Key observations pertaining to requirements / improvement areas / gaps of the
envisaged ERP System (based on requirements specified by JPDCL Nodal Officers /
Officials):
▪ Functionality.
▪ User Experience.
▪ Features with respect to the SaaS-based ERP Application and Mobile App.
▪ ICT Infrastructure requirements.
▪ Technology aspects.
▪ Operations And Delivery.
▪ Handholding And Capacity Building Initiatives.
This section shall comprise the analysis of the ERPSI in respect of the Software Requirement
Study conducted.
o List and compilation of evidence / artefacts collected during discussions.
• ERPSI shall prepare the ‘Software Requirement Study’ document and submit the same to
JPDCL for obtaining a formal sign-off.
• JPDCL shall provide a sign-off on the ‘Software Requirement Study’ document for the same to
be considered as a deliverable.
Page 150 of 390

JPDCL
5.3 To-be Process documentation, Gap Analysis and Business Process Re-
engineering
• ERPSI shall prepare the first draft To-be processes based on the:
o Inputs collected by them during the Software Requirement Study phase.
o Analysis conducted by themselves at the end of the Software Requirement Study
phase.
o Framework of the ERP Product.
o Best practices prescribed in the industry for undertaking a similar ERP
implementation.
• ERPSI shall demonstrate the best practices available in the ERP Product, and showcase how
these best practices affect and can be implemented in the existing business processes. ERPSI
shall utilize their first draft of To-be processes and any demo systems of the ERP Product
available with them.
• ERPSI shall undertake Business Process Re-engineering (BPR) wherever required (after
preparation of the first draft of To-be processes and undertaking ERP Product capability
workshops with JPDCL Nodal Officers / Officials / Users).
• ERPSI shall collate all information from the sessions held and BPR undertaken and conduct
gap analysis.
• ERPSI shall organize workshops to reconcile the gaps between the existing practices and the
identified To-be processes (their prescribed benchmarks). Based on the discussions held
during these sessions, the To-be processes shall be finalized.
• Functional elements of the envisaged ERP System that are required to be decided upon and
finalized in this phase shall include the following, but not be limited to:
o Functional modules, processes and sub-processes.
o Functionality identified for Mobile App.
o Function-wise User Roles and Organization Structure to be mapped.
o Supporting modules to be implemented / services / third-party services to be
integrated.
o Integrations to be undertaken.
o User Access and Permission Control Matrixes (function / process / sub-process-wise).
o Number and outline / format of MIS, other Reports of JPDCL, Dashboards and
Analytics that are expected to be implemented.
• Other non-functional and technical elements of the envisaged ERP System that are required
to be decided upon and finalized in this phase shall include the following, but not be limited
to:
o User Access Control and Authorization Matrixes (function / process / sub-process-
wise).
o Implementation of Multi-Factor Authentication (MFA).
Page 151 of 390

JPDCL
o User Experience-related elements – including outlines for user interfaces for ERP
System, Mobile App and Portals (JPDCL, Consumer, CFC).
o Enablement of functionality of allowing Users to utilize DSCs.
o Language and localization.
o Access mechanisms – desktops / laptops / mobile devices / CFCs, etc.
• While undertaking BPR and / or finalizing To-be processes, special care shall be taken by the
ERPSI to ensure compliance to statutory and regulatory requirements prescribed under
various prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. applicable to JPDCL and
consideration of cybersecurity aspects.
• Documentation expected to be prepared and submitted as part of ‘To-be process
documentation, Gap Analysis and Business Process Re-engineering’ shall include the
following, but not be limited to:
o First draft of To-be processes.
o List and elaboration of the best practices prescribed in the industry for undertaking a
similar ERP implementation – used for preparation of the first draft of To-be
processes.
o BPR undertaken.
o Gap Analysis undertaken.
o Discussion pointers / Minutes of Meetings for the various workshops / discussion
sessions held by the ERPSI during this phase.
o Finalized functional, non-functional and technical elements of the To-be processes
including, but not limited to those specified earlier in this sub-section.
o Compliance sheets of the finalized elements with:
▪ Functional Requirement Specification (FRS), Non-functional Requirement
Specifications and Technical Requirement Specifications specified in the RFP.
▪ Prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. referred –
mapping to clauses / sub-clauses / sections / articles of the documents is
required.
o Populated Requirement Traceability Matrix – first version.
o Detailed analyses and workings undertaken during the course of ‘To-be process
documentation, Gap Analysis and Business Process Re-engineering’ phase.
5.4 Software Architecture and Design

• Based on the To-be processes, Gap Analysis and BPR undertaken, the ERPSI is expected to
draft the Software Architecture and Design of the envisaged ERP System including its
underlying ICT Infrastructure.
• ERPSI is expected to utilize the India Enterprise Architecture (IndEA) prescribed by the Ministry
of Electronics & Information Technology (MeitY), Government of India (GoI) for drafting the
Software Architecture. ERPSI may refer to other industry followed frameworks for
strengthening the Software Architecture.
Page 152 of 390

JPDCL
• The envisaged ERP System is expected to be consider the Zero Trust Principles while designing
the System. As part of their ‘Software Architecture and Design’ deliverable, ERPSI shall be
expected to provide a roadmap for scaling Zero Trust controls / tenets throughout the Project
duration.
• ERPSI shall ensure that all requirements specified in the RFP and those captured during
‘Software Requirement Study’, and ‘To-be Process documentation, Gap Analysis and Business
Process Re-engineering’ shall be addressed in the Software Architecture and Design.
• ERPSI is expected to embody security and governance elements in the Software Architecture
and Design across multiple layers of technology stack such as isolation, Application / Database
/ Operating System, hardening, Secure Integration and Front Ends, Encryption, Patching,
Monitoring, and Data Privacy etc.
• ERPSI shall be required to prove that the outlined Software Architecture and Design is able to
meet all requirements stipulated in the RFP and prescribed by JPDCL stakeholders, and
achieve the SLAs stipulated in the RFP.
• Software Architecture and Design shall cover the following, but not limited to:
o Software Architecture and Design Principles followed.
o List of Zero Trust controls / tenets proposed for consideration with rationale of
selecting them.
o SaaS-based ERP Application details – elaborating the planned services, modules,
components (including but not limited to application software, third-party services,
tools), integrations, etc.
o Resultant Software Application portfolio – including system software, other
applications of JPDCL envisaged to be integrated, third-party applications / services,
tools, PKI-services, etc.
o Resultant Technology landscape (including standards to be followed).
o Data Architecture for the envisaged ERP System – including database design /
structures, entity relationship diagrams, secure storage and authenticated retrieval of
data, types of queries allowed for various users / system calls, etc.
o Integration enablement – API / Web Services, and their design.
o Software Security components / features – identified for enablement for Information
Security.
o Access channels / User Interfaces (Hardware / Software / Human) – including user
interfaces, mode of data entry, user outputs, etc.
o Software configuration / development methodology to be followed.
o Various diagrammatic representations and views (logical, process, deployment,
implementation) that are important for future reference.
o List of security and governance elements incorporated in the Software Architecture
and Design.
o List of compliances – to sections / clauses / tenets of applicable industry standards,
and prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc.
o List of risks identified pertaining to the SaaS-based ERP Application and its integration
with application software, third-party services, tools, etc. comprised in the envisaged
ERP System, and Software Architecture and Design.
Page 153 of 390

JPDCL
• In addition, ERPSI shall be required to submit the following in relation to the ‘Software
Architecture and Design’ – for capturing the design of the SaaS-based ERP Application in detail:
o Software Requirement Specification.
o High-level Design (HLD).
o Low-level Design (LLD).
• Documentation expected to be prepared and submitted as part of ‘Software Architecture and
Design’ shall include the following, but not be limited to:
o Software Architecture and Design.
o Software Requirement Specification (SRS).
o High-level Design (HLD).
o Low-level Design (LLD).
o ERP Product documentation that elaborates on the internal architecture of the SaaS-
based ERP Application.
o Detailed analysis and workings undertaken for proving that the designed Software
Architecture and Design is able to address the requirements stipulated in the RFP and
prescribed by JPDCL stakeholders, and achieve the SLAs stipulated in the RFP.
o Populated Risk Register – first version.
5.5 Procurement of licenses

• ERPSI shall be required to procure licenses for all the proposed products, system software,
databases, tools and any other software required for realizing the envisaged ERP System as
per the requirements specified in the RFP and those captured during ‘Software Requirement
Study’, and ‘To-be Process documentation, Gap Analysis and Business Process Re-
engineering’, and those identified during ‘System Architecture and Design’.
• All the licenses shall be perpetual and procured in the name of “Jammu Power Distribution
Corporation Limited (JPDCL)”.
• All product licenses procured by the ERPSI for implementing the envisaged ERP System shall
be the property of JPDCL from the day of purchase.
• ERPSI shall also provision of the Annual Support for all such products / software procured.
JPDCL shall not pay for any functional or technical updates / upgrades or patches that are
released by any OEM whose products have been deployed as part of the envisaged ERP
System.
• Proof of purchase of licenses in the name of JPDCL and purchase of ATS shall be required to
be submitted by the ERPSI to JPDCL for consideration of completion of respective deliverable
/ milestone.
• No additional costs shall be borne by JPDCL in relation to procurement of licenses, unless there
is a legitimate Change Request arising from change of functional scope or SLA requirement.
Page 154 of 390

JPDCL
5.6 Configuration / Customization / Enhancement (new development) of

SaaS-based ERP Application
• ERPSI shall undertake configuration / customization / enhancement (new development) of
SaaS-based ERP Application based on the functional, system requirement specifications and
designs finalized for JPDCL’s envisaged ERP System during the previous phases.
• ERPSI shall endeavour to utilize inherent functionality and features available within the ERP
Product for undertaking the configuration of the envisaged ERP System. Wherever there is a
possibility of adopting standard workflows, work-arounds shall be planned, discussed with the
concerned JPDCL stakeholder, updated in the documentation of the ‘To-be processes
documentation, Gap Analysis and Business Process Re-engineering’ and ‘Software
Architecture and Design’, and implemented.
• ERPSI shall endeavour to minimize customizations and enhancements. Total percentage of
functionalities stipulated in the FRS presented in this RFP for which customization /
enhancements are undertaken shall not exceed twenty (20) percent.
• Any customizations / enhancements that are a result of legal, regulatory or statutory
compliance requirements shall not be considered in the twenty (20) percent cap specified in
the above sub-point. However, it shall be noted that the ERPSI shall be required to implement
all functionality and features to ensure compliance to legal, regulatory or statutory
requirements as per prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. that are in
force upto the date of Go-live of the envisaged ERP System. No Change Requests shall be
awarded to the ERPSI for undertaking activities pertaining to ensuring such compliances.
• ERPSI shall ensure that required and sufficient audit trails have been configured for all
transactions (for e.g. add, update and delete) using transaction log reports, so that errors in
data, intentional or otherwise, can be traced and reversed.
• ERPSI shall ensure that Zero Trust controls / tenets identified during the ‘Software
Architecture and Design’ phase for implementation shall be configured.
• From the implementation perspective, ERPSI is expected to follow Secure Software
Development Life Cycle (Secure SDLC) methodology framework for undertaking configuration
/ customization / enhancement (new development) of SaaS-based ERP Application.
• ERPSI shall also ensure implementation of all requisite controls so that databases and their
constituent data are not tampered or modified by system operators without compromising
the performance / speed of the system.
• ERPSI shall ensure that sufficient granularity is built in the SaaS-based ERP Application
modules, sub modules and individual functionalities so that these functionalities can be
enabled or disabled through the application administrator as per the requirements.
• ERPSI shall be required to undertake integrations as per the scope specified in the RFP and
requirements assessed during the ‘To-be processes documentation, Gap Analysis and
Business Process Re-engineering’ and ‘Software Architecture and Design’ phases.
Page 155 of 390

JPDCL
5.7 Resource Management

• ERPSI shall be responsible for adequately sizing of the necessary compute, memory, and
storage required, building the redundancy into the architecture (including storage) and load
balancing to meet the service levels.
• For auto-scaling of any major expected increase in the workloads, the ERPSI shall carry out the
capacity planning in advance to identify & provision, where necessary, the additional capacity
to meet the user growth and / or the peak load requirements to support the scalability and
performance requirements of the solution.
• The scaling up / scaling down (beyond the auto-scaling limits or whenever the auto-scaling
limits must be changed) must be carried out with prior approval by the JPDCL. The Service
Provider shall provide the necessary details including the sizing calculations, assumptions,
current workloads & utilizations, expected growth / demand and any other details justifying
the request to scale up or scale down.
5.8 Network Management

• JPDCL will provide the Network connectivity and on board the network service provide to
connect all required locations to access the ERP Application.
• ERPSI must closely liaison with bandwidth Service Provider(s) for the period of contract.
• ERPSI must be expected to liaise with the network service provider to ensure the links are
commissioned within the timelines specified and agreed by JPDCL.
• ERPSI must escalate any delays in the link commissioning to JPDCL on proactive basis.
• ERPSI must inform the JPDCL of the link readiness and commissioning.
• ERPSI must monitor and manage the SDWAN based PoP links to meet the SLA.
• ERPSI must liaise with the network service provider in case of any link / line failure and ensure
the same is restored within the agreed timelines.
• The ERPSI along with the JPDCL will have to put in place in mechanisms to capture actual
downtime as per the agreed Service Levels between the JPDCL and the Network Service
Provider and compute the delay and penalty thereof.
• ERPSI is responsible for monitoring and administering the proposed network equipments
within all the new IPDS locations.
• ERPSI must monitor the performance of the network and coordinate with the NBSP for
resolution of issues.
5.9 Database Backup

• Data backup shall be another important factor to be considered by the ERPSI while outlining
the ERP System. Further, ERPSI shall be required to provide an additional data backup to JPDCL
at / near JPDCL Head Office, Dr. B. R. Ambedkar Chowk, Jammu in; both, online (on real time
basis) and off-line modes, JPDCL is having the storage which can be looked for the extension
(Minimum Storage requirement is 20 TB).
• ERPSI shall formulate Backup & Archival policy and procedure in line to the requirements and
necessary approval of JPDCL.
Page 156 of 390

JPDCL
• The ERPSI shall perform backup as per the requirement of the JPDCL. This will include
managing the regular backup and restore operations and assuring security of the media
through appropriate access control. In addition, the ERPSI shall also manage scheduled data
replication at DR.
• However, as a minimum requirement the ERPSI shall perform weekly backups for the files.
• For the databases, perform minimum twice weekly full database backup, with three times
daily backup of database log files.
• System Integrator shall perform and store data and file backups consisting of an initial full
back up with daily incremental backups for files.
• Retain the backups for entire project period on system and thereafter on tapes which can be
restored when required.
• System Integrator shall not delete any data at the end of the agreement without the express
approval of JPDCL.
• Monitoring and enhancement of the performance of scheduled backups, schedule regular
testing of backups and ensure adherence to related retention policies. Retention policies shall
be decided after placing formal LOA to the selected ERPSI.
• Ensure prompt execution of on-demand backups of volumes, files and database applications
whenever required by the JPDCL or in case of upgrades and configuration changes to the
system.
• Real-time monitoring, log maintenance and reporting of backup status on a regular basis. The
ERPSI should ensure prompt problem resolution in case of failures in the backup processes.
• The ERPSI should also ensure that a 24 x 7 support for file, database and volume restoration
requests is available at the Cloud based Data Centers.
• Specific Snapshot – At request of JPDCL, the ERPSI shall create a full snapshot for the platform,
content, and related data, to be retrieved at the request of JPDCL.
5.10 Privacy and Security Safeguards.

• If the data is classified as very sensitive, the ERPSI to ensure that the data is encrypted as part
of a standard security process for highly sensitive content or choose the right cryptographic
algorithms evaluating security, performance, and compliance requirements and may choose
from multiple key management options.
• The ERPSI should notify the JPDCL promptly in the event of security incidents or intrusions, or
requests from foreign government agencies for access to the data, to enable the JPDCL to
manage these events proactively.
• The CSP shall not delete any data at the end of the agreement (for minimum of 90 days beyond
the expiry of the agreement) without the express approval of JPDCL.
• At the end of the agreement, the ERPSI with prior permission, shall ensure and inform the
JPDCL that all the storage blocks or multiple copies of data if any are unallocated or zeroed
out by the ERPSI, cannot be recovered. If due to some regulatory reasons if it is required to
securely decommission data, the JPDCL can implement data encryption at rest using the
managed keys, which are not stored in the cloud. Then JPDCL may delete the key used to
protect the decommissioned data, making it irrecoverable.
Page 157 of 390

JPDCL
• The ERPSI shall report forthwith in writing of information security breaches to the JPDCL by
unauthorized persons (including unauthorized persons who are employees of any Party) to
gain.
Page 158 of 390

JPDCL
6. Acceptance Testing
The primary goal of Acceptance Testing shall be to ensure that the envisaged ERP System meets
Requirements, Standards, and Specifications as set out in the RFP and as needed to achieve the
desired Output, Outcomes and Service Levels. Acceptance Testing shall involve:
• Solution Testing.
• Integration Testing.
• Performance Testing.
• Review of Data Migration.
• Security Testing and Audit.
• Pre-Go-live Audit.
6.1 General Requirements of Acceptance Testing

• Clear and quantifiable metrics shall be utilized by the ERPSI and JPDCL to ensure that the
Acceptance Testing for the envisaged ERP System is undertaken successfully.
• ERPSI shall setup the requisite Staging (Testing) environment for undertaken all required tests
under Acceptance Testing as per requirements specified in the RFP.
6.2 Issue Register and handling of issues during Acceptance Testing

• The Issue Register set-up by the ERPSI during the ‘Project Kick-off’ phase is expected to be
utilized by the ERPSI for logging defects / issues and tracking their closure during the
Acceptance Testing Phase.
• ERPSI shall be responsible for populating the Issue Register with the defects / issues identified
during various Acceptance Tests. ERPSI shall provide Reports for the various Acceptance Tests
to JPDCL as evidence of defects / issues logged in the Issue Register.
• In addition to the various Reports generated during Acceptance Testing, JPDCL and / or its
nominated agencies shall utilize the Issue Register to track closure of defects / issues logged
in it.
• ERPSI shall be expected to resolve all the defects / issues identified during by Acceptance
Testing of JPDCL’s envisaged ERP System.
• ERPSI shall be expected to rectify and re-test the closure of defects / issues to ensure
achievement of SLAs / satisfaction of JPDCL (whichever is applicable).
• Upon rectification of a defect / issue, ERPSI shall be expected to update the Requirement
Traceability Matrix (wherever applicable).
• Additionally, ERPSI shall be expected to set-up necessary supplementary tools for logging of
defects and / or carrying out testing, if required.
Page 159 of 390

JPDCL
6.3 Testing Approach for Acceptance Testing

ERPSI shall be required to conduct the following steps; but not limited to, as part of their approach to
conducting Acceptance Testing across test cycles at all stages of Solution Testing:
• Identification of test scenarios; comprehensively.

• Ascertaining of Testing Methodology and preparation of Testing Plan.
• Preparation of test scripts in accordance with the test scenarios identified.
• Identification of test data along with expected out come in specific test script pertaining to a
test scenario.
• Review and finalization test scenarios, test scripts and test sequence.
• Identification of tools for undertaking the planned tests.
• Setting-up the test scenarios and test data in the Staging (Testing) environment.
• Conducting the test.
• Recording test results.
• Comparing the same with expected result.
It shall be noted that ERPSI shall provide Testing Plans for each type of Acceptance Test prescribed in
the RFP.
It shall be noted that by the ERPSI that JPDCL shall expect the ERPSI to utilize the results of Acceptance
Tests conducted by them to make necessary changes to the SaaS-based ERP Application and Cloud
Infrastructure configurations to optimize performance – which shall in-turn impact the achievement
of SLA by the ERPSI during Operations and Maintenance.
Hence, the ERPSI is expected to ensure that the Testing Plans are comprehensive and encompass
various scenarios to the largest extent possible.
Page 160 of 390

JPDCL
6.4 Solution Testing

6.4.1. Outline of Framework for Solution Testing
• Solution Testing shall essentially comprise the following, but not be limited to:
o Unit Testing (UT): Function / process / sub-process-wise testing of developed / configured
solution for each Module of the SaaS-based ERP Application.
o User Acceptance Testing (UAT): Complete testing of the SaaS-based ERP Application based
on User Roles and Responsibilities.
o Load and Stress Testing: To test the envisaged ERP System based on simulated growth
users and transaction volume to ensure that the System achieves SLA parameters
stipulated in the RFP.
o Stabilization Test: To test if the solution meets SLA parameters and complete functioning
as per requirements stipulated in the RFP.
• ERPSI shall be expected to conduct all tests as required to be undertaken in an industry-
standard Software Testing Life Cycle (STLC).
6.4.2. Additional expectations from the ERPSI pertaining to User Acceptance Testing
(UAT)
In addition to the general requirements of Acceptance Testing, Issue Register and handling of issues
during Acceptance Testing, Testing Approach for Acceptance Testing, and stipulations of outline
of framework for Solution Testing, ERPSI shall be expected to perform following, but not limited
to, in respect of User Acceptance Testing (UAT):
• ERPSI shall facilitate JPDCL and / or its nominated agencies to conduct User Acceptance
Testing (UAT).
• JPDCL shall nominate a team to carry out User Acceptance Testing of the envisaged ERP
System configured, customized and enhanced by ERPSI.
• ERPSI shall provide training to the Testing team prior to the commencement of the UAT (User
Acceptance Testing) of system.
Page 161 of 390

JPDCL
6.5 Integration Testing

• Primary objective of Integration Testing shall be to ensure that the SaaS-based ERP Application
and other subsystems; including but not limited to, existing applications, supporting
application software, third-party services, tools, etc. are able to share data in industry
acceptable protocols and formats.
• The envisaged ERP System is expected to be based on an open architecture and be able to
integrate the SaaS-based ERP Application and other subsystems; including but not limited to,
existing applications, supporting application software, third-party services, tools, etc. at all
levels utilizing:
o Enterprise Application Integration (EAI).
o Data Integration (DI).
o Electronic Document Interchange (EDI).
The envisaged ERP System is expected to support various industry-standard interoperability
and integration methods including, but not limited to:
o Web-services.
o Application Programming Interface (API).
o Messaging Queuing.
o XML based file transfer.
o Flat file transfer.
It is expected that the ERPSI review the integrations of the envisaged ERP System for the afore-
specified requirements.
• ERPSI shall conduct Integration Testing for testing appropriateness of integrations of the SaaS-
based ERP Application with its subsystems; including but not limited to, existing applications,
supporting application software, third-party services, tools, etc. from the functional
perspective, at the following levels:
o Process.
o Data.
o Document exchange: No loss of integrity of document is to be ascertained at
minimum.
ERPSI shall ensure that each integration produces the envisaged results to obtain an assurance
of proper integrations from the functional perspective.
• In addition, it is expected that ERPSI shall be expected to review the integrations of the
envisaged ERP System to ascertain that all external systems; including but not limited to,
existing applications, supporting application software, third-party services, tools, etc. shall be
integrated with the envisaged ERP System based on a consistent, real-time or batch processing
data exchange methodology operating in an automatic manner without any manual
intervention unless specifically required.
Page 162 of 390

JPDCL
6.6 Performance Testing

ERPSI shall perform Performance Testing of the deployed System (comprising the SaaS-based ERP
Application and other subsystems; including but not limited to, existing applications, supporting
application software, third-party services, tools, etc.) against key parameters defined in SLA described
in this RFP.
Typical parameters that shall be considered for Performance Testing include, but not be limited to:
• Request response time.

• Work-flow processing time.
• Concurrent sessions supported by the System.
ERPSI is also expected to conduct a Performance Review including verification of scalability provisions
made in the envisaged ERP System for catering to the requirements of volume growth in future.
6.7 Review of Data Migration

• ERPSI shall arrange for a review exercise through a Third-party Data Migration Audit Agency.
ERPSI shall be required to contract the services of the Third-party Data Migration Audit Agency
with a Clause that the Review Report of the exercise shall be shared with both; JPDCL
Coordinator and ERPSI.
• ERPSI shall seek approval from JPDCL prior to appointment of the Third-party Data Migration
Audit Agency and commencement of review work by the Third-party Data Migration Audit
Agency.
• Coverage of the review of Data Migration shall include, but not be limited to strategies,
validation, assessment, comprehensive and completeness of data (both at pre- and post-data
migration stages).
• ERPSI shall be required to discuss the corrective actions / recommendations made by the
Third-party Data Migration Audit Agency in their Review Report with JPDCL Coordinator and
other concerned stakeholders and seek their approval prior to commencement of action on
corrective actions / recommendations made by the Third-party Data Migration Audit Agency
in the Review Report.
• ERPSI will ensure closure of all corrective actions / recommendations made by the Third-party
Data Migration Audit Agency in their Review Report to the satisfaction of JPDCL stakeholders
and Third-party Data Migration Audit Agency.
• It is expected that the Third-party Data Migration Audit Agency undertakes a reassessment
after closure of corrective actions / recommendations by the ERPSI and provides a Final
Report to JPDCL Coordinator and ERPSI confirming successful closure of all agreed corrective
actions / recommendations.
Page 163 of 390

JPDCL
6.8 Security Testing and Audit

• ERPSI shall arrange for a testing and audit exercise through a Third-party Audit Agency for
undertaking Security Audit of the envisaged ERP System. ERPSI shall be required to contract
the services of the Third-party Audit Agency with a Clause that the Security Testing Audit
Report of the exercise shall be shared with both; JPDCL Coordinator and ERPSI.
• ERPSI shall seek approval from JPDCL prior to appointment of the Third-party Audit Agency
for Security Testing and Audit and commencement of review work by the Third-party Audit
Agency.
• Scope coverage of activities expected to be undertaken by the Third-party Audit Agency as
part of the Security Testing and Audit shall include the following, but not be limited to:
o Vulnerability Assessment (VA).
o Penetration Testing (PT).
o Compliance Audit.
o Secure Code Review.
o Secure Configuration Review.
o IT General Controls Review.
o Review of implementation of all patches / updates from the product OEMs of SaaS-
based ERP Application, integration middleware, supporting system software, tools,
any other layer of software, etc. from the standpoint of mitigating known
cybersecurity and Zero-Day Attack (if a new release / new product is being deployed
as part of the supporting applications / tools, etc.) vulnerabilities ( ERPSI shall be
required to cover all known vulnerabilities upto the date of commencement of Pre-Go-
live Audit).
• It shall be noted that ERPSI shall be required to set-up a ‘Pre-production’ instance of the
envisaged ERP System in the Staging (Testing) environment for undertaking all the afore-
specified activities. The ‘Pre-production’ instance of the envisaged ERP System shall be
required to be an exact replica of the instance of the envisaged ERP System that is expected
to be deployed in the Production environment.
• ERPSI shall be responsible for obtaining all the requisite permissions from the Cloud Service
Provider (CSP) for undertaking all the afore-specified activities.
• In addition, the Third-party Audit Agency shall be expected to perform the following Security
Reviews for the complete envisaged ERP System as part of Security Testing and Audit at
minimum, but not limited to:
o Assessment of authentication mechanism provided in the application / components /
modules.
o Assessment of data encryption mechanisms implemented for the solution.
o Assessment of data access privileges, retention periods and archival mechanisms.
o Assessment of Business Continuity measures.
o Assessment of Information Security related measures.
• The Third-party Agency for Pre-Go-live Audit shall submit a detailed Security Testing and Audit
Report to JPDCL and ERPSI comprising observations, corrective actions / recommendations,
risk analysis and assessment of impact on the overall functioning and performance of the
envisaged ERP System.
Page 164 of 390

JPDCL
• ERPSI shall be required to discuss the corrective actions / recommendations made by the
Third-party Audit Agency in their Security Testing and Audit Report with JPDCL Coordinator
and other concerned stakeholders and seek their approval prior to commencement of action
on corrective actions / recommendations made by the Third-party Audit Agency in the
Security Testing and Audit Report.
• ERPSI will ensure closure of all corrective actions / recommendations made by the Third-party
Audit Agency in their Security Testing and Audit Report to the satisfaction of JPDCL
stakeholders and Third-party Audit Agency.
• It is expected that the Third-party Audit Agency undertakes a reassessment after closure of
corrective actions / recommendations by the ERPSI and provides a Final Report to JPDCL
Coordinator and ERPSI confirming successful closure of all agreed corrective actions /
recommendations.
6.9 Pre-Go-live Audit

ERPSI shall arrange for an audit exercise through a Third-party Audit Agency for undertaking Pre-Go-
live Audit of the envisaged ERP System. ERPSI shall be required to contract the services of the Third-
party Audit Agency with a Clause that the Pre-Go-Live Audit Report of the exercise shall be shared
with both; JPDCL Coordinator and ERPSI.
ERPSI shall seek approval from JPDCL prior to appointment of the Third-party Audit Agency for Pre-
Go-live Audit and commencement of review work by the Third-party Audit Agency.
Scope coverage of activities expected to be undertaken by the Third-party Audit Agency as part of the
Pre-Go-live Audit shall include the following, but not be limited to:
• Review of ‘Software Requirement Study’, ‘To-be Process documentation, Gap Analysis and
Business Process Re-engineering’, and ‘Software Architecture and Design’, ‘ICT Infrastructure
Architecture and Design’ documents and other functional and technical documents along with
any other related documents.
• Preparation of module-wise detailed observations covering and including; but not limited to,
process coverage, usage of the envisaged ERP System functionalities, risks in customized
processes (if any).
• Providing recommendations on industry best practices for JPDCL as appropriate e.g.,
organization structure, codification etc.
• Review of compliance of the To-be processes with prevailing acts, rules, guidelines, manuals,
sectoral CERTs, etc.
• Audit to ensure installation of proper versions and licenses for the envisaged ERP System
including; but not limited to SaaS-based ERP Application’s licensing, integration middleware,
supporting system software, tools, any other layer of software etc.
• Verification of standard ERP functionalities including module, sub-module which have been
used to meet JPDCL’s requirements.
• Verification and review of approach and methodology followed for undertaking the
customization as per standards recommended by SaaS-based ERP Application OEM.
• Identify risks for JPDCL in such customization undertaken.
Page 165 of 390

JPDCL
• Review of all enhancements (new development / custom developed components / objects /

process etc.) with risk assessment, if any.
• Verification and confirmation before Go-live; the technical preparedness of the envisaged ERP
System for Go-live.
• Review technical and operational procedures, system performance, user support documents
and structure as per the scope and OEM standards.
• Verification of the implemented envisaged ERP System for compliance with the standard
practices.
• Review of procedures, comprehensiveness of response registry items, sufficiency of training
of deployed helpdesk personnel, quality of response of the Centralized IT Helpdesk.
• Review of all project deliverables and other associated project documentation from the
perspective of appropriateness and sufficiency to guide ‘Operations and Maintenance’ or
response during a cyber-security event.
• Confirm that the envisaged ERP System is performing as per SLAs stipulated in the RFP.
• Confirmation of validity STQC Audit Report of the Cloud Service Providers for Data Centre and
Disaster Recovery Centre. The valid STQC Report shall be submitted as part of the Pre-Go-live
Audit Report to JPDCL.
The Third-party Agency for Pre-Go-live Audit shall submit a detailed Pre-Go-live Audit Report to JPDCL
and ERPSI comprising observations, corrective actions / recommendations, risk analysis and
assessment of impact on the overall functioning and performance of the envisaged ERP System, and
JPDCL operations.
ERPSI shall be required to discuss the corrective actions / recommendations made by the Third-party
Audit Agency in their Pre-Go-live Audit Report with JPDCL Coordinator and other concerned
stakeholders and seek their approval prior to commencement of action on corrective actions /
recommendations made by the Third-party Audit Agency in the Pre-Go-live Audit Report.
ERPSI will ensure closure of all corrective actions / recommendations made by the Third-party Audit
Agency in their Pre-Go-live Audit Report to the satisfaction of JPDCL stakeholders and Third-party
Audit Agency.
It is expected that the Third-party Audit Agency undertakes a reassessment after closure of corrective
actions / recommendations by the ERPSI and provides a Final Report to JPDCL Coordinator and ERPSI
confirming successful closure of all agreed corrective actions / recommendations.
Duration allowed to the Third-party Audit Agency for undertaking the Pre-Go-live Audit shall be
maximum 25 days including all audit activities and post audit compliance checks and validation.
Page 166 of 390

JPDCL
7. Data Migration
7.1 Data categories and sources
Following data is proposed to be migrated to the envisaged ERP System:
• Master data.
• Transaction data (Open transactions of the ‘Finance & Accounting System’ and ‘Distribution
Transformer Management System’ and open cases / transactions of JPDCL on account of their
operations).
• Data in reference to transactions of the envisaged ERP System (Reports, Notings,
Correspondences, supporting documents, etc. pertaining to open transactions, or that which
is required to be maintained under legal, statutory or regulatory requirements only).
Master data for being utilized by the envisaged ERP System shall be created from the following sources
of data:
• Master data available in existing applications (that are required to be integrated, ‘Finance &
Accounting System’ and ‘Distribution Transformer Management System’) specified in the RFP.
• From relevant documentation utilized by the Departments / Business Units of JPDCL for
conducting their operations (including, but not limited to prevailing acts, rules, guidelines,
manuals, sectoral CERTs, etc.).
• Master data collected from the Data Owners (and Process Owners; wherever applicable)
through templates provided by the ERPSI.
Transaction data for being utilized by the envisaged ERP System shall be created from the following
sources of data:
• Open transactions from the ‘Finance & Accounting System’ and ‘Distribution Transformer
Management System’.
• Open cases / transaction of JPDCL on account of their operations – i.e. data of those open
cases / transactions that are currently being undertaken manually but will be covered under
the scope of the envisaged ERP System.
Data for reference that shall be uploaded to the envisaged ERP System shall be made available to the
ERPSI by relevant Data Owners and Process Owners in the formats (digital file format) specified by the
ERPSI.
It shall be noted that the ERPSI shall not be responsible for digitization of any data / files of
Departments / Business Units of JPDCL. Departments / Business Units of JPDCL shall be required to
digitize all data under this category of data themselves.
Page 167 of 390

JPDCL
7.2 Overall Data Migration Strategy and Approach

ERPSI shall be required to migrate all data specified in the RFP to the database of the envisaged ERP
System.
As part of data migration, ERPSI shall perform the following activities at minimum; but not be limited
to:
• ERPSI shall prepare Data Migration Plan and submit to JPDCL Coordinator for approval. While
preparing the Data Migration Plan, ERPSI shall ensure minimum business impact at the time
of Data Migration.
• ERPSI shall prepare the requisite set-up for Data Migration (including staging environment
and other associated set-up). ERPSI shall be required to provide this set-up as part of their
deliverables under the Scope of Work specified in this RFP.
• Upon receipt of approval from JPDCL Coordinator, ERPSI shall migrate the data to the
production environment of the envisaged ERP System.
• ERPSI shall ensure the accuracy and completeness of the migrated data. It shall be noted that
JPDCL reserves the right to verify the accuracy and completeness of the migrated data on its
own / through its nominated agencies.
Page 168 of 390

JPDCL
7.3 Data Migration Methodology

7.3.1. Data Migration Methodology for data from existing applications
It is expected that data from existing applications (that are required to be integrated, ‘Finance &
Accounting System’ and ‘Distribution Transformer Management System’) shall be migrated to the
envisaged ERP System. Data that is expected to be migrated shall include the following, but not be
limited to:
• Master Data.
• Transaction Data (pertaining to open transactions of the specified existing applications).
As part of the data migration activity to be conducted for data from existing applications, ERPSI shall
be required to undertake the following activities, at minimum; but not be limited to:
• ERPSI shall set-up the required environments / systems comprising the Databases of existing
applications, Intermediary Database and Database of the SaaS-based ERP Application as
depicted in the diagram below.
Diagram: Indicative set-up for conducting Data Migration from existing applications
• ERPSI shall secure the Intermediary Database (expected to be set-up within the staging
environment) for information security, and data protection and privacy. Sufficient measures
shall be required to be undertaken by the ERPSI for ensuring the same.
• ERPSI shall set-up the Intermediary Database with the same data structure, table design and
masters as in Database of the SaaS-based ERP Application. Raw data shall be migrated from
the Databases of existing applications to the Intermediary Database after preforming Pre-load
Validations on the data using data migration rules / logics / validations / scripts.
This shall ensure that only refined form of the data over several years of operations of the
existing applications is made available in Database of the SaaS-based ERP Application – i.e.
Page 169 of 390

JPDCL
data from the Databases of existing applications is processed through levels of checks and
balances to ensure only refined data is pushed through in Database of the SaaS-based ERP
Application.
This shall also ensure the availability of data extracted from existing applications (which is
expected to be refined and stored) as per the design of the Database of the SaaS-based ERP
Application.
• It shall be noted that initially the data constituted in the Intermediary Database and the
Database of the SaaS-based ERP Application shall not be exactly identical – i.e. data from the
day of Go-Live and period before that shall be different.
This is to ensure that the data which is being migrated to the Intermediary Database may not
become completely refined and correct after the Pre-Load Validation process and may require
additional checks (that shall be performed during Data Load Validations) to make the data
pure, and hence not corrupt the Database of the SaaS-based ERP Application (the production
database of the envisaged ERP System).
• All the data from existing applications prior to Go-Live date shall be available in the
Intermediary Database. The data shall be pushed to the Database of the SaaS-based ERP
Application only after performing Data Load Validations.
Initially, it is expected that the Database of the SaaS-based ERP Application shall hold only that
data which is processed on or after the actual Go-Live date, the Intermediary Database (which
shall have the refined data from the Databases of existing applications) shall only be used as
and when required, and that no new data is being pushed into the Intermediary Database by
the envisaged ERP System.
Eventually, as and when data is cleansed and validated through Data Load Validations, it is
expected that data from the Intermediary Database shall be migrated to the Database of the
SaaS-based ERP Application and the envisaged ERP System shall utilize the migrated data from
the Database of the SaaS-based ERP Application.
• Since Intermediary Database is expected to have the same Database Structure, Table Design
and Masters, it is envisaged that the Database of the SaaS-based ERP Application shall have
no compatibility issues while interacting with the Intermediary Database for executing
transactions.
• ERPSI shall undertake Pre-load Validation activities of data – i.e. data refining activity and
migration from the Databases of existing applications to the Intermediary Database – in
phased manner, for better results and ensuring proper validation by the JPDCL Data Owners
(and Process Owners; wherever applicable).
It is expected that the entire volume of data is broken down to lots of few years (for example:
lots of 1 year, 2 years, etc.) for being refined and migrated to the Intermediary Database. Once,
a lot is completely validated and accepted by the Data Owner (and Process Owner; wherever
applicable), the next lot of data shall be taken up of undertaking the same exercise. It is
expected that this process shall be repeated till all data is refined and migrated from the
Databases of existing applications to the Intermediary Database.
Once all the data is checked for completeness and accuracy, and duly verified by the respective
Data Owners (and Process Owners; wherever applicable) and JPDCL Coordinator, Data Load
Validation of data for migration of data from the Intermediary Database to the Database of
the SaaS-based ERP Application shall be undertaken by ERPSI. ERPSI shall conduct Data Load
Validation module / data-set-wise.
Page 170 of 390

JPDCL
Until then, the SaaS-based ERP Application shall interact with the Intermediary Database for
reference and the Database of SaaS-based ERP Application for population of transaction data
generated from transactions undertaken in the envisaged ERP System.
• It is further envisaged that over a period of time, the data in the Intermediary Database shall
no longer be required for the overall operations / processing of the envisaged ERP System.
Upon completion of the Data Migration activities in totality, ERPSI shall archive and
decommission the Intermediary Database in accordance with Data Archival Policy, and other
Information Security and Data Protection and Privacy requirements stipulated by JPDCL.
Approval of JPDCL Coordinator shall be required to undertake the archival and
decommissioning activity pertaining to the Intermediary Database.
7.3.2. Data Migration Methodology for data other than data from existing applications
and data for reference
It is expected that the data other than data from existing applications and data for reference shall be
migrated to the envisaged ERP System. Data that is expected to be migrated shall include the
following, but not be limited to:
• Master Data.
• Transaction Data (pertaining to open cases / transaction of JPDCL on account of their
operations).
As part of the data migration activity to be conducted for other than data from existing applications
and data for reference, ERPSI shall be required to undertake the following activities, at minimum; but
not be limited to:
• ERPSI shall provide templates to the Data Owners (and Process Owners; wherever applicable)
for collecting data.
• ERPSI shall conduct hand-holding sessions / workshops for Data Owners (and Process Owners;
if any) for:
o Explaining the process of filling the templates.
o Guiding the Data Owners (and Process Owners; wherever applicable) on:
▪ Undertaking data classification.
▪ Standardizing nomenclature of data.
o Clarifying doubts that the Data Owners (and Process Owners; wherever applicable)
may have pertaining to the exercise.
• Data Owners (and Process Owners; wherever applicable) shall extract relevant data from their
respective Systems and provide the same to the ERPSI in the format specified in the templates
provided by the ERPSI.
• ERPSI shall endeavour to obtain complete data-set for a module / major process. Once the
complete data-set is received, ERPSI undertake Data Load Validation of the data-set.
Page 171 of 390

JPDCL
• ERPSI may schedule one-on-one discussions with the Data Owners (and Process Owners;
wherever applicable) or organize additional hand-holding sessions / workshops until
completeness and accuracy of data is achieved from the Data Load Validation activities.
• After the expected level of integrity of data is achieved, ERPSI shall be seek approval from the
JPDCL Coordinator for migration of the data to the envisaged ERP System.
• Upon successful migration of the data, ERPSI shall be required to archive the data collected
from the Data Owners (and Process Owners; wherever applicable), intermediate-processed
data, and Post-Load Reports in accordance the procedure prescribed by JPDCL and in
compliance to the Data Archival Policy, and other Information Security and Data Protection
and Privacy requirements stipulated by JPDCL.
7.3.3. Data Migration Methodology for data for reference

It is expected that the data for reference shall be migrated to the envisaged ERP System.
Data for reference shall primarily comprise Document Data including the following, but not be limited
to Reports, Notings, Correspondences, supporting documents, etc. pertaining to open transactions,
or that which is required to be maintained under legal, statutory or regulatory requirements.
Data that is expected to be migrated shall include the following, but not be limited to:
• Document files.
• Metadata.
As part of the data migration activity to be conducted for data for reference, ERPSI shall be required
to undertake the following activities, at minimum; but not be limited to:
• ERPSI shall provide templates to the Data Owners (and Process Owners; wherever applicable)
for collecting details of documents required to be migrated and the documents’ associated
metadata.
• ERPSI shall conduct hand-holding sessions / workshops for Data Owners (and Process Owners;
if any) for:
o Explaining the process of filling the templates.
o Digital formats in which the documents files (envisaged for migration) are required.
o Guiding the Data Owners (and Process Owners; wherever applicable) on:
▪ Undertaking document classification.
▪ Standardizing nomenclature of metadata.
o Clarifying doubts that the Data Owners (and Process Owners; wherever applicable)
may have pertaining to the exercise.
• Data Owners (and Process Owners; wherever applicable) shall prepare the document files in
accordance with the prescriptions of the ERPSI and the documents’ associated metadata in
the format specified in the templates provided by the ERPSI.
Page 172 of 390

JPDCL
• ERPSI shall endeavour to obtain complete document-set for a module / major process. Once
the complete document-set is received, ERPSI undertake Transformation process for the
document-set.
• ERPSI may schedule one-on-one discussions with the Data Owners (and Process Owners;
wherever applicable) or organize additional hand-holding sessions / workshops until the
required level of confidence is achieved from the Transformation activities.
• ERPSI may create additional indexes / catalogues / document resources, etc. to ensure that
the documents are available across the required modules / processes in the envisaged ERP
System.
• After the expected level of confidence is achieved, ERPSI shall be seek approval from the JPDCL
Coordinator for migration of the documents to the envisaged ERP System. ERPSI shall be
required to prove the confidence in the documents and data transformed through the audit
trails generated and maintained during the Transformation process.
• Upon successful migration of the documents, ERPSI shall be required to archive the
documents and data collected from the Data Owners (and Process Owners; wherever
applicable), intermediate-processed documents and data, and audit trails of the
Transformation process in accordance the procedure prescribed by JPDCL and in compliance
to the Data Archival Policy, and other Information Security and Data Protection and Privacy
requirements stipulated by JPDCL.
Page 173 of 390

JPDCL
8. Training and Capacity Building

Training and Capacity Building are critical components for the success of this Project. The objective of
Training and Capacity Building initiatives shall be to empower all Users and other stakeholders to
optimally use and ensure smooth functioning of the envisaged ERP System.
Conducting trainings and building capacities at various levels is critical to the successful
implementation of the recommended initiatives. Also, the training programs shall be required to cover
at minimum general / basic computer awareness programs in addition to ERP / Technology-specific
programs in order to ensure adoption of the system at all levels.
8.1 Participants of Training and Capacity Building Initiatives

8.1.1 User Categories envisaged to be become participants of
Training and Capacity Building Initiatives
Based on the nature of their responsibilities and their requirements participants can be classified into
the following categories for training purposes:
• Functional Core Team:

Description: Functional Core User Team shall be responsible for management & overall
functioning of the application, managing the master application etc.
Training and Capacity building expected for the Functional Core User shall involve the
following areas at minimum; but not be limited to:
o Application functionality.
o Basic System Administration (from process ownership and management perspective).
o Master Management (from data ownership and management perspective).
• JPDCL End-Users:
Description: JDPCL End-Users Team shall be responsible for undertaking day-to-day
functioning (JPDCL operations) by utilizing the envisaged ERP System.
Training and Capacity building expected for the JPDCL End-Users shall involve the following
areas at minimum; but not be limited to:
o System functionalities (process perspective).
o Various reporting and analytical functional available.
o Various other features made available by the envisaged ERP System for improving
operational efficiency of JPDCL End-Users.
• Other stakeholder End-Users:
Description: Other stakeholders (in addition to JDPCL Officials / Staff) are expected to utilize
the envisaged ERP System. End-Users Teams of such other stakeholders shall be responsible
for participating in few functions of the day-to-day operations of JPDCL by utilizing the
Page 174 of 390

JPDCL
Training and Capacity building expected for the JPDCL End-Users shall involve the following
areas at minimum; but not be limited to:
o System functionalities (process perspective – relevant to the stakeholder).
o Various reporting and analytical functional available (relevant to the stakeholder).
• Management Report Users:
Description: Management Report Users shall be responsible for only extracting required
reports from the envisaged ERP System.
Training and Capacity building expected for the Management Report Users shall involve
extraction of various reporting and analytical functional available.
• Senior Management Users:

Description: Senior Management Users shall be involved in governance and controlling of
operations, and overall quality management of all JPDCL processes implemented in the
Training and Capacity building expected for the Management Report Users shall involve:
o System functionalities (board-level process perspective).
o Various reporting and analytical functional available.
o Governance, Risk and Controlling (GRC)-functionality.
o Quality Management.
8.1.2 Number of participants for Training and Capacity

Building Initiatives
Number of participants for Training and Capacity Building (atleast 5-Times) Initiatives shall be in
accordance with the count of users assessed across User Categories specified in this RFP.
Page 175 of 390

JPDCL
8.2 Training and Capacity Building Plan

ERPSI shall be required to submit a Tentative Training and Capacity Building Plan including detailed
schedule, batch size, focus areas of training, delivery method, and training curriculum at minimum;
but not be limited to, at the onset of the Project. The Plan details shall be discussed by ERPSI with
JPDCL Project Coordinator for assessing the sufficiency of the Plan in meeting the objective of
endeavour. Authority of making final decision shall reside with JPDCL Project Coordinator at all times
and ERPSI shall be expected to include the decisions of the JPDCL Project Coordinator in the Final
Training and Capacity Building Plan.
ERPSI shall submit the ‘Final Training and Capacity Building Plan’ to JPDCL for obtaining a formal sign-
off. JPDCL shall provide a sign-off on the same for being considered as a deliverable.
8.2.1 Focus Areas for Training

Training and Capacity Building Plan must focus on the imparting training in the following areas:
• Functional Training for all End-Users (JPDCL and other stakeholders) of the envisaged ERP
System for enabling them to utilize the system as envisioned by JPDCL senior management.
End-Users shall be expected to be trained on module functionalities – specific to the processes
which they will be engaging in for day-to-day operations.
• Functional Training and Basic System Administration Training for Process Owners (from JPDCL
only) for enabling them to govern the processes under their jurisdiction from the perspective
of being subject matter expert on the processes being mapped in ERP module, handling basic
level issues pertaining to common services such as payment gateway, etc., user login
approvals, etc.
• Master Data Management Training for Data Owners (from JPDCL only) for enabling them to
govern master data under their ownership.
• Management Report User Training for enabling the identified end-users for extracting reports
efficiently and using assigned analytics functions.
ERPSI shall include / develop the following as part of the Training and Capacity Building Plan:
• Design a User Interface (UI) under Knowledge Management System Module of the envisaged
ERP System for enhanced user experience during training (utilizing latest concepts of
designing UIs):
o Step-by-step instructions for selecting options for each field in a dedicated part of the
screen.
o Expandable bubbles at data field labels that will expand by placing cursor on them –
they will provide information of the field and what data is to be filled in.
o Availability of relevant acts, rules, guidelines, manuals, sectoral CERTs, etc. on screen
for ready reference.
• Training Calendars: Re-training available at regular intervals for JPDCL End-Users.
• Refresher trainings for Core Team: New trends in industry with respect to domain, technology
and ERP.
Page 176 of 390

JPDCL
• Trainings for End-Users of other stakeholders: Only one round of training shall be conducted
by the ERPSI for End-Users of other stakeholders. After the initial training, End-Users of other
stakeholders shall be expected to utilize the ‘Training & Online Help’ made available to them
through the User Workspace (through Portal and Mobil App).
8.2.2 Training Delivery Methods

Training for all the groups mentioned above shall be the responsibility of the ERPSI and the same shall
be undertaken using one or more of the following approaches:
• Classroom.
• Web-based training / e-learning (self-paced).
• Virtual Instructor-led.
ERPSI shall be required to provide a section for ‘Training & Online Help’ on each User’s Workspace
(made available to Users through Portal and Mobile App). Function of this section shall be covered
under Knowledge Management System Module of the envisaged ERP System.
Training material shall be made available to learners based on their roles defined in the envisaged ERP
System.
8.2.3 Indicative Training Schedule and Curriculum

ERPSI shall finalize and manage the detailed Training Schedule in consultation with JPDCL Project
Coordinator in alignment with the overall implementation roadmap of the Project and coordinate the
same with all stakeholders involved. Training Schedule shall be prepared and finalized process-wise /
ERP module-wise and shall be optimized to reduce business impact and effective utilization of Training
infrastructure and capacities. ERPSI shall also be required to manage and maintain requirements,
nominations etc. for the Trainings.
The Training Curriculum under the Training can Capacity Building Plan shall be organized in suitable
Training Modules and these shall be used to develop the required Training Materials. The Training
Curriculum shall outline the module structure and outline, pre-requisite / initial reading / preparation
required, typical duration for completing the training and intended audience for effective and efficient
training of all identified trainees.
Training Modules indicated in the Training Schedule and Curriculum shall be delivered in such a
manner that trainees across user categories are trained by the time the SaaS-based ERP Application
“goes-live”. Continuous reporting (MIS) and assessment shall be required to be an integral function of
training. ERPSI shall also identify the languages used by trainees across user categories of the SaaS-
based ERP Application and ensure multi-language training to the trainees as per requirement.
An indicative Training Curriculum and Duration for each Module has been specified below.
Page 177 of 390

JPDCL
TOPICS DURATION
# TRAINING
(indicative only) (indicative only)
1 Senior Management • Application usage. 2 days
• MIS report analysis.
• Query / Search generation.
• Quality Management related processes.
• GRC related processes.
2 Functional Core Team • Application usage. 5 days
• Data Management related processes and
features.
• Issue resolution related processes.
3 JPDCL End-Users • Application usage. 2 days
4 Other stakeholder • Application usage. 0.5 days
End-Users • MIS report analysis (relevant reports
only).
5 Management Report Extraction of various reporting and analytical 0.5 days
Users functional available.
8.2.4 Tracking of Learning and Certification

The Knowledge Management System Module of the envisaged ERP System shall provide functionality
to track learning of trainees. For trainees completing training modules successfully, the Knowledge
Management System Module shall be able to provide certificates to such trainees and be able to track
history for learning for all Users.
The Knowledge Management System Module of the envisaged ERP System shall also be able to track
re-training of trainees and provide a complete learning history of all trainees; except End-Users of
other stakeholder.
Page 178 of 390

JPDCL
8.2.5 Development of Training Material

The ERPSI shall hold the responsibility for creation of Training Material and their circulation to the
relevant trainees during the Trainings. Following shall be the coverage of Training Materials to be
prepared by the ERPSI:
• Preparation of training material / functionality guides / user manuals for all Users (listed under
this section) of processes of the SaaS-based ERP Application.
• Preparation of user manuals for Consumers (accessing the envisaged ERP System for raisin
Service Requests).
ERPSI shall provide the Training Material thus prepared to JPDCL in electronic medium and hard-copy
booklet format.
ERPSI shall provide detailed training material by elaborating the approach to performing tasks of each
process; step-by-step, in soft and hard copies to all users for reference.
ERPSI shall ensure that the Training Content meets all the objectives of the Training and Capacity
Building Plan. The Training Material shall be developed in Hindi, English and other languages as
identified earlier. ERPSI shall also develop the Training Material for delivery through Computer Based
Training, Instructor Led Training, Online User Material / Help Manuals and Job Aids.
8.2.6 Training Effectiveness Evaluation

ERPSI shall evaluate the effectiveness of all end Trainings using electronic or manual surveys. ERPSI
shall be responsible for analyzing the feedback and arrange for conducting refresher training,
wherever needed.
JPDCL shall periodically monitor the training effectiveness through the performance metrics and
Service levels and the ERPSI shall comply with the same.
Page 179 of 390

JPDCL
9. Set-up and operationalization of IT Helpdesk for the envisaged ERP

System
9.1 Purpose of the IT Helpdesk for the envisaged ERP System
ERPSI shall be expected to setup an IT Helpdesk for the envisaged ERP System for the following
purposes:
• Resolving functional and technical queries and issues pertaining to the envisaged ERP System.
• Resolving queries / issues pertaining to monitoring and management of assets deployed by
ERPSI in relation to the envisaged ERP System under this Project.
• Recording, providing first-level response, and tracking progress of response actions
recommended for management of incidents pertaining to the envisaged ERP System.
9.2 Scope coverage of the IT Helpdesk for the envisaged ERP System
The scope coverage of the IT Helpdesk for the envisaged ERP System shall include the envisaged ERP
System including its integration with existing applications, supporting application software, third-party
services, tools, etc., and its underlying Cloud-based Infrastructure and ICT Infrastructure components
deployed by the ERPSI as part of the Project.
However, the scope coverage of the IT Helpdesk for the envisaged ERP System pertaining to the
integrated existing applications, supporting application software, third-party services, tools, etc. shall
be restricted to raising the ticket on the respective vendors and tracking for closure.
In addition, scope coverage of the IT Helpdesk for the envisaged ERP System pertaining to
cybersecurity incidents shall be restricted to escalating the ticket on the concerned JPDCL Cyber Crisis
Management Plan (CCMP) stakeholder.
9.3 Components of the IT Helpdesk for the envisaged ERP System

The IT Helpdesk for the envisaged ERP System is expected to act a Single Point of Contact (SPOC) for
all stakeholders of JPDCL and the Project. The IT Helpdesk for the envisaged ERP System shall automate
the process of logging, tracking, consolidating, managing and escalating issues and incidents through
proper channels.
The IT Helpdesk for the envisaged ERP System shall be required to be accessible through the following
at minimum; but not be limited to:
• Telephone (Toll-free number) followed by IVRS.

• Web Portal of the envisaged ERP System.
• Mobile App of the envisaged ERP System.
• Email.
• WhatsApp.
• Collaboration Tool implemented by JPDCL; if any.
Page 180 of 390

JPDCL
As part of the IT Helpdesk for the envisaged ERP System, ERPSI shall be expected to set-up:
• 5-seater Helpdesk (Space, power supply, internet and telephone connectivity, furniture, other
non-ICT infrastructure, etc. shall be provided by JPDCL).
• Helpdesk Management Software including a Ticket Management Tool, Call Management Tool,
etc.
• Toll-free number with five (05) lines.
• Integration of the Helpdesk Management Software with IVRS, Email, WhatsApp and
Collaboration Tool of JPDCL (if any).
• Soft-phones for Helpdesk Operators.
• ICT Infrastructure for setting-up the IT Helpdesk for the envisaged ERP System including; but
not limited to:
o Head-set and any other communication devices for Helpdesk Operators.
o Telephone sets for Helpdesk Operators (five (05) nos. - for redundancy).
o Desktop systems for Helpdesk Operators.
o Power back-up for at least 4 hours.
9.4 Operation of the IT Helpdesk for the envisaged ERP System

• IT Helpdesk for the envisaged ERP System shall provide services from 8AM to 8PM except on
public holidays declared by JPDCL and Union Territory of Jammu and Kashmir.
• IT Helpdesk for the envisaged ERP System shall:
o Track each incident / call to resolution
o Escalate the calls, to the appropriate levels; wherever required.
o Coordinate with respective stakeholders for closure of calls.
o Analyse the incident / call statistics and provide monthly reports including but not
limited to - type of incidents / calls logged, Incidents / calls resolved, Incidents / calls
open, etc.
• Operations of the IT Helpdesk for the envisaged ERP System shall be organized in at least three
(03) levels:
o L1: Helpdesk Operators:
▪ Acknowledge the query / issue / incident.
▪ Undertake first-level analysis.
▪ Provide first-level resolution.
▪ Escalate the query / issue / incident that require further analysis.
▪ Track closure of the queries / issues / incidents raised to the IT Helpdesk for
o L2: ERPSI’s Operations and Maintenance Team:
▪ Analyse the query / issue / incident in detail.
Page 181 of 390

JPDCL
▪ Provide resolution in case of query / issue.

▪ Escalate the resolution of query / issue in case additional guidance pertaining
to policies / processes / procedures of JPDCL are required to answer the
query.
▪ Escalate an identified incident to concerned JPDCL Cyber Crisis Management
Plan (CCMP) stakeholder.
o L3: JPDCL Process Owners and concerned JPDCL Cyber Crisis Management Plan
(CCMP) stakeholder:
▪ JPDCL Process Owners shall be expected to provide guidance to ERPSI’s
Operations and Maintenance Team additional guidance pertaining to policies
/ processes / procedures of JPDCL are required to answer the query.
▪ Queries / issues solely related to JPDCL’s procedures / policies shall be
answered by JPDCL Process Owners only.
▪ JPDCL Cyber Crisis Management Plan (CCMP) stakeholder shall be expected
to provide response action plan to JPDCL User reporting the incident,
undertaking other necessary actions for response to the incident and
reporting the incident.
Details of the actions taken by JPDCL Process Owners pertaining to queries / issues and
concerned JPDCL Cyber Crisis Management Plan (CCMP) stakeholder pertaining to
incidents shall be recorded in the IT Helpdesk for the envisaged ERP System, and shall
be tracked by the L1 Helpdesk Operators for closure.
• Operations of the IT Helpdesk for the envisaged ERP System shall be driven by Standard
Operating Procedures and a well-curated repository of responses.
ERPSI shall be required to capture details pertaining to preparation of the repository of
responses during the ‘Software Requirement Study’, ‘Infrastructure Requirement Study’, ‘To-
be Process documentation, Gap Analysis and Business Process Re-engineering’, ‘Software
Architecture and Design’ and ‘ICT Infrastructure Architecture and Design’ phases, and prepare
and operationalize the repository of responses as part of the IT Helpdesk for the envisaged
ERP System.
ERPSI shall be required to periodically (at least quarterly) review the repository of responses
and update the repository of responses to incorporate the learnings during the previous
period.
• IT Helpdesk for the envisaged ERP System shall provide services across the identified
communication channels at minimum in English and Hindi.
• In addition, ERPSI shall be expected to periodically (at least quarterly) solicit user satisfaction
levels about the envisaged ERP System by conducting surveys through the IT Helpdesk for the
Page 182 of 390

JPDCL
9.5 Helpdesk Operators

ERPSI shall deploy five (05) trained Helpdesk Operators at the IT Helpdesk for the envisaged ERP
System.
ERPSI shall be required to identify a Supervisor amongst the Team who will operate in the general shift
and deploy two (02) Helpdesk Operators in two (02) shifts to address the operations of the IT Helpdesk
for the envisaged ERP System.
Helpdesk Operators shall be dedicatedly deployed on this project for full time basis on-site. Payment
to ERPSI shall be made based on actual number of Helpdesk Operators deployed.
Helpdesk Operators shall be required to perform various activities including; but not limited to, the
following:
• Understand the query / issue / incident in the reported request. Query / issue / incident could
be related to the following at minimum; but not limited to:
o Functionality of the envisaged ERP System.
o Technical aspects of the envisaged ERP System – such as login and password issues,
accessing a particular module, navigation assistance, report generation assistance, etc
o Connectivity to the envisaged ERP System.
• Provide information / clarification / resolution / action item on the spot in case of an
informational query or providing necessary troubleshooting assistance in case of a logged
issue.
• Forward the query / issue / incident to concerned JPDCL personnel in case:
o Query / issue pertains to JPDCL’s procedures / policies (Answers to such queries should
also be recorded in the knowledge base for future reference).
o Security incident is reported.
• In case of queries / issues for which a resolution is not possible instantly, Helpdesk Operators
shall submit the request into the system for escalation and further action by the ERPSI’s
Operations and Maintenance Team.
It shall be noted that JPDCL shall periodically (at least quarterly) review the call volume and quality.
Based on number of calls, JPDCL may increase or decrease the number of helpdesk seats.
Page 183 of 390

JPDCL
10. Implementation of cybersecurity considerations for design,

configuration / customization / enhancement of the envisaged Enterprise
Resource Planning (ERP) System
10.1 Secure Software Development Life Cycle (Secure SDCL)
ERPSI shall be expected to undertake design, configuration / customization / enhancement of the
envisaged ERP System utilizing the tents of Secure Software Development Life Cycle (Secure SDLC).
ERPSI shall perform the following activities at minimum; but not be limited to, at various stages of the
Software Development Life Cycle (SDLC).
S.No PHASE ACTIVITIES

1. Conducting sensitization • ERPSI shall be expected to explain the importance
workshops of following the Secure SDLC for undertaking design,
configuration / customization / enhancement of the
envisaged ERP System to all concerned JPDCL
stakeholders prior to commencement of ‘Software
Requirement Study’ and ‘Infrastructure
Requirement Study’ activities.
• ERPSI shall be expected to focus on facilitating the
concerned JPDCL stakeholders in thinking
Cybersecurity while providing inputs / conducting
discussions during the subsequent phases of the
SDLC.
• In addition, ERPSI shall be expected to provide a
training to the concerned JPDCL stakeholders for
enabling them to provide the requisite security-
inclusive inputs / comments / decisions during the
subsequent phases of the SDLC.
2. • Software Requirement Study • ERPSI shall be expected to prepare a list of all

security features pertaining to the envisaged ERP
• Infrastructure Requirement
System for which inputs are required to be collected
Study
from the concerned JPDCL stakeholders.
• Based on the list of security features, ERPSI shall be
expected to draft specific questions for User
Categories comprising the concerned JPDCL
stakeholders.
• ERPSI shall be required to conduct discussions with
the concerned JPDCL stakeholders and collect
inputs specifically for each of the questions
identified.
3. To-be Process documentation, ERPSI shall be required to conduct activities of this

Gap Analysis and Business phase based on:
Process Re-engineering
• Inputs collected specifically for each of the
questions identified pertaining to security features
from the concerned JPDCL stakeholders.
Page 184 of 390

JPDCL

• ERPSI’s assessments / analyses pertaining to system
security during ‘Software Requirement Study’ and
‘Infrastructure Requirement Study’.
• Zero Trust controls / tenets as prescribed by OEMs
of various products being utilized and those
specified in the RFP.
• Data protection and privacy requirements under the
requirements stipulated under various applicable
prevailing acts, rules, guidelines, manuals, sectoral
CERTs, etc.
4. • Software Architecture and • ERPSI shall conduct Threat Modelling analysis and
Design identify all requisite security controls that shall be
included in the ‘Software Architecture and Design’
• ICT Infrastructure
and ‘ICT Infrastructure Architecture and Design’.
Architecture and Design
• ERPSI shall undertake design the Software
• Sizing of ICT Infrastructure
Architecture and ICT Infrastructure Architecture of
the envisaged ERP System based on the identified
security controls and Zero Trust controls / tenets.
• ERPSI shall ensure that all additional components
(products / cloud instances / hardware
components) / ICT infrastructure (compute /
storage / network) capacity for addressing the
identified security controls and Zero Trust controls /
tenets, data protection and privacy requirements,
and security controls identified are factored in the
sizing exercise.
• ERPSI shall be required to identify all risks
associated with the ‘Software Architecture and
Design’ and ‘ICT Infrastructure Architecture and
Design’, and populate (and update; as and when
required) the same in the Risk Register.
5. • Procurement of licenses ERPSI shall take into cognizance the Third Party Risks
• Procurement of Cloud associated with OEMs of the products that are boing
instances and other ICT utilized in the implementation and operationalization of
Infrastructure components the envisaged ERP System. ERPSI shall be required to:
• Ensure selection of such products for undertaking
implementation of the envisaged ERP System such
that the inherent risk associated with the OEM is
minimized.
• Prepare a list of all risks associated with the OEM
and populate (and update; as and when required)
the same in the Risk Register.
Page 185 of 390

JPDCL

6. Configuration / Customization / ERPSI shall undertake configuration / customization /
Enhancement (new development) enhancement of the envisaged ERP System in
of SaaS-based ERP Application accordance with the inputs collected and requirements
identified in the earlies stages.
7. Deployment of Cloud instances ERPSI shall undertake deployment, configuration and

and other ICT Infrastructure hardening of cloud instances in accordance with the
components requirements identified in the earlies stages.
8. Acceptance Testing ERPSI shall be required to all Acceptance Tests

stipulated under Acceptance Testing in this RFP.
9. Data Migration ERPSI shall be expected to secure the environments and

other ICT Infrastructure / systems deployed for
performing Data Migration activities.
ERPSI shall ensure data protection and privacy in
respect of all data handled during the process of Data
Migration.
10. Training and Capacity Building ERPSI shall be expected to train the concerned
stakeholders of JPDCL in subjects concerning to security
in context of operating the envisaged ERP System.
ERPSI shall create awareness pertaining to phenomena
such as phishing, malware, etc. and build capacities
pertaining to identification of malware, ransomware,
etc. from the perspective of facing an incident while
operating the envisaged ERP System.
Page 186 of 390

JPDCL
10.2 Zero Trust Architecture

The envisaged ERP System is expected to be consider the Zero Trust Principles while designing the
System. As part of their ‘ICT Infrastructure Architecture and Design’ and ‘Software Architecture and
Design’ deliverables, ERPSI shall be expected to provide a roadmap for scaling Zero Trust Controls
throughout the Project duration.
Zero Trust controls / tenets pertaining to the following elements of System may be considered by the
ERPSI:
• Identity:
o Directory Services.
o Multi-factor Authentication (MFA).
o User Behaviour.
o User Authentication.
o User Authorization.
o Privileged Access Management (PAM).
• Devices:
o Device Authentication.
o Device Authorization.
o Device Compliance.
o Configuration Management.
• Cloud instances and Network connectivity:
o Macro-segmentation.
o Micro-segmentation.
o Encryption-in-transit.
o Infrastructure virtualization.
o Dynamic Routing.
• Constituent Applications and their Workloads:
o Secure Software Development Life Cycle.
o Virtualization.
o Containerization.
o Encryption-in-process.
• Data:
o Digital Rights Management.
o Data Loss Protection.
o Encryption-at-rest.
o Tagging.
o Governance.
Page 187 of 390

JPDCL
• Orchestration / Automation:
o Threat Response (support / facilitation in case of requirement under IT and IS policies
of JPDCL).
o Policy Enforcement.
o SOAR (support / facilitation in case of requirement under IT and IS policies of JPDCL).
o Configuration Management.
o Process Management.
• Analytics / Visibility (support / facilitation in case of requirement under IT and IS policies of
JPDCL):
o Security Information and Event Management (SIEM).
o Threat Detection.
o Event Monitoring.
o User Activity Monitoring (UAM).
o Policy Decision.
In addition, ERPSI shall be required to follow the prescriptions of the SaaS-based ERP Application OEM
pertaining to designing and implementing Zero Trust controls / tenants as identified for the envisaged
ERP System.
ERPSI shall be required to uphold the following at minimum; but not be limited to, while designing
and implementing the identified Zero Trust controls / tenets for the envisaged ERP System:
• All data sources and computing services are considered resources.
• All communication is secured regardless of network location.
• Access to individual resource is granted on a per-session basis.
• Access to resources is determined by dynamic policy.
• Enterprise monitors and measures the integrity and security posture of all owned and
associated assets.
• All resource authentication and authorization are dynamic and strictly enforced before access
is allowed.
• Enterprise collects as much information as possible about the current state of assets, cloud
infrastructure, and communications and uses it to improve its security posture.
During the Implementation Track, ERPSI shall be required to utilize all inherent tools / capabilities
provided by the SaaS-based ERP Application OEM, and OEMs of platforms of existing applications (for
integration) / supporting application software / third-party services / tools, etc. comprising the
envisaged ERP System to implement the identified Zero Trust controls / tenets. In case additional tools
/ software are of required by ERPSI for implementing the identified Zero Trust controls / tenets for
the envisaged ERP System, ERPSI shall provide the same as part of their deliverables. No additional
costs shall be paid by JPDCL towards any additional tools / software (that are required for achieving
the expected identified Zero Trust controls / tenets for envisaged ERP System) that have been missed
out during the Bid Submission unless there is a legitimate Change Request arising from change of
Page 188 of 390

JPDCL
scope related to ICT infrastructure / functionality impacting sizing of the envisaged ERP System or
technical feature requirement or SLA requirement.
Page 189 of 390

JPDCL
10.3 Business Continuity Planning

ERPSI shall be expected to get themselves on-boarded to the Business Continuity Plan (BCP) of JPDCL.
As part of their responsibilities on this Project, ERPSI shall be required to undertake the following at
minimum; but not limited to:
• Plan and implement the Disaster Recovery Centre in accordance with the specifications
specified in the RFP and requirements pertaining to achieving SLAs.
• Conduct Disaster Recovery (DR) Drills at regular intervals in accordance with concerned IT and
IS policies of JPDCL.
• Work with JPDCL to:
o Identify major processes of JPDCL implemented in the envisaged ERP System –
processes that are expected to have a major impact on the business and operations
of JPDCL on account of unavailability in case of an event / incident.
o Identify various events / incidents that may impact the identified business critical
processes.
o Conduct risk assessment and determine the measure for mitigating the risks
associated the identified business critical processes in respect of the events / incidents
listed.
o Work with JPDCL to implement measures (pertaining to the envisaged ERP System and
its underlying ICT infrastructure only) ensure that the identified business critical
processes stay in operation.
• Participate in activities of Disaster Recovery pertaining to the envisaged ERP System in case of
occurrence of an event / incident.
• Ensure compliance to Business Continuity Planning related tenets of the following at
minimum; but not limited to, are addressed during design, configuration, customization and
enhancement of the envisaged ERP System:
o IT and IS policies of JPDCL.
o Prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. applicable to JPDCL’s
business and operations.
Page 190 of 390

JPDCL
10.4 Data protection and privacy

ERPSI shall be required to consider data protection and privacy requirements pertaining to the data
of JPDCL that shall be processed through the envisaged ERP System.
As part of their responsibilities on this Project, ERPSI shall be required to undertake the following at
minimum; but not limited to:
• Obtain data classification from JPDCL and ensure implementation of the same in regards of
the data of the envisaged ERP System.
• Ensure confidentiality, integrity, availability, lawfulness, transparency, accuracy and
compliance to duration of data retention for all data that shall constitute the envisaged ERP
System.
• Ensure data minimization and localization during implementation.
• Ensure that the design, configuration, customization and enhancement of the envisaged ERP
System is undertaken in accordance with:
o The principles of privacy are design.
o IT and IS policies of JPDCL.
o Prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc. applicable to JPDCL’s
business and operations.
• Ensure that all requirements pertaining to Consent Management are captured during the
‘Software Requirement Study’, considered in the ‘To-be processes’ and ‘Software Architecture
and Design’ and implemented as part of the envisaged ERP System.
• Ensure requisite measures are undertaken (including deployment of additional tools; if
required) for achieving Data Leakage Prevention from the envisaged ERP System.
Page 191 of 390

JPDCL
10.5 Compliance and Audit requirements

As part of the scope of activities, ERPSI shall be required to ensure that adequate measures are
undertaken during design, configuration, customization and enhancement of the envisaged ERP
System pertaining to deploying an envisaged ERP System that is compliant to various standards,
policies, legal / statutory / regulatory / other requirements prescribed by authorities, etc. In addition,
undertake / participate in audits.
ERPSI shall be required to address the following Compliance and Audit requirements pertaining to
the envisaged ERP System at minimum; but not be limited to:
• Compliance to ISO Standards (pertaining to the envisaged ERP System only) including; but not
limited to:
o ISO 27001: Information Security Management System.
o ISO 20000: IT Service Management.
o ISO 22301: Business Continuity.
o ISO 27032: Cybersecurity Management.
• Compliance to IT and Information Security (IS) Policies of JPDCL (pertaining to the envisaged
ERP System only) including; but not limited to:
o Access Control Policy.
o Asset Management Policy.
o Back-up and Recovery Policy.
o IT System Operations Security Policy.
o Network and Communications Security Policy.
o System Acquisition, Development and Maintenance Policy.
o IT Risk Management Policy.
o Information Security Incident Management Policy.
o Business Continuity Management Policy.
o Information and Information-related Devices’ Disposal Policy.
o Physical and Environmental Security Policy.
o Supplier Relationship Incident Management Policy.
o Email Policy.
o IT Asset Management and Inventory Policy.
o Service Management Policy.
o Cybersecurity Policy.
o IT Audit Policy.
o Change Management Policy.
o Data Management Policy.
o Incident Monitoring, Reporting and Response Policy.
o Remote Access Policy.
Page 192 of 390

JPDCL
o Password Policy.
o Policy on Use of IT Resources.
o Mobile Device Management Policy.
o Policy on adoption of Open-Source Software.
o Open Data Policy.
o Polices and Stand Operating Procedures (SOPs) pertaining to Data Centers and Cloud
installations of JPDCL.
• Compliance to sectoral CERTs / guidelines issued by the Central Electricity Authority of India.
• Compliance to tenets of various prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc.
prescribed by the Ministry of Electronics and Information Technology (MeitY), Government of
India (GoI), and other agencies of GoI:
o Information Technology (The Cert-IN and Manner of Performing Functions and
Duties), Rules, 2013) and various other Cert-IN guidelines (inc. that issued on
28.04.2022 which required incident reporting with 6 hours).
o DSCI Security Framework (DSF).
o IT Act, 2000 and all its Amendment Rules.
o E-Waste (Management and Handling) Rules, 2010.
o Policy for preference to domestically manufactured goods in procurement due to
security considerations, 2012.
o National Data Sharing and Accessibility Policy, 2012.
o National Cyber Security Policy, 2013.
o National Policy on Universal Electronic Accessibility, 2013.
o Website Quality Manual.
o Guidelines for Adoption of Electronic Payments and Receipts (EPR), 2016.
o Aadhaar Authentication for Good Governance (Social Welfare, Innovation,
Knowledge) Rules, 2020.
o Cyber Security Audit Baseline Requirements, 2020 (Draft).
o Personal Data Protection Act, 2023.
• Adherence to various standards, guidelines, prescriptions by the Ministry of Electronics and
Information Technology (MeitY), Government of India (GoI), and other agencies of GoI
stipulated at https://egovstandards.gov.in/
• Compliance to various prevailing acts, rules, guidelines, manuals, sectoral CERTs, etc.
applicable to JPDCL’s business and operations (pertaining to the envisaged ERP System only)
including; but not limited to:
o General Financial Rules, 2017.
o Manual for Procurement of Works (Department of Expenditure, Ministry of Finance,
Government of India).
o Manual for Procurement of Goods (Department of Expenditure, Ministry of Finance,
Government of India).
Page 193 of 390

JPDCL
o Manual for Procurement of Consultancy and Other Services (Department of

Expenditure, Ministry of Finance, Government of India).
o Delegation of Financial Powers to Administrative Departments.
o Jammu and Kashmir Treasury Code.
o Income Tax Act, 1961.
o All applicable Goods and Service Tax (GST) Acts.
o Jammu and Kashmir Civil Service Regulations, 1956.
o Jammu and Kashmir Civil Service (Leave) Rules, 1979.
o General Provident Fund (Central Services) Rules, 1960.
o General Provident Fund Manual.
o Jammu and Kashmir State Life Insurance Scheme.
o Jammu and Kashmir Civil Services (Classification, Control and Appeal) Rules, 1956.
o Jammu and Kashmir Government Employees (Conduct) Rules, 1971.
o Jammu and Kashmir Civil Services (Medical Attendance and Allowance) Rules,1990.
o Jammu and Kashmir Civil Services (Leave Travel Concession) Rules, 2019.
• Adherence to various other industry-accepted standard, guidelines, etc. including; but not
limited to:
o ITIL (Information Technology Infrastructure Library).
o COBIT Framework.
o NIST 800 series.
o NIST Cybersecurity Framework (CSF).
o CIS Controls – SANS Top 20.
o OWASP Top 10.
o COSO Enterprise Risk Management Framework.
In addition, ERPSI shall be required to undertake / participate by means of extending required support
to JPDCL in undertaking audits listed in the RFP at minimum.
Page 194 of 390

JPDCL
10.6 Patching of known vulnerabilities

ERPSI shall be expected to implement all patches / updates / bug fixes made available by the OEMs
of SaaS-based ERP Application, integration middleware, supporting system software, tools, any other
layer of software, etc. from the standpoint of mitigating known cybersecurity and Zero-Day Attack (if
a new release / new product is being deployed as part of the supporting applications / tools, etc.)
vulnerabilities. This activity shall be required to be undertaken by the ERPSI to irrespective of the
actions undertaken by them in consequence to the outcome of the ‘Security Testing and Audit’
activities - unless conflict arises, or specific decision has been provided by the JPDCL Project
Coordinator on this matter.
ERPSI shall be required to cover all known vulnerabilities upto the date of commencement of Pre-Go-
live Audit. However, in case a patches / updates / bug fixes, it shall be deployed prior to Go-Live and
‘Security Testing and Audit’ of the same shall be taken separately and details of the same shall be
recorded under the Vulnerability Management Program. This shall ensure that the envisaged ERP
System is free of known vulnerabilities as of date of Go-Live.
10.7 On-boarding to Cybersecurity initiatives of JPDCL

ERPSI shall be required to on-board themselves during the Pre-Go-Live preparation phase to various
Cybersecurity initiatives of JPDCL including; but not limited to:
• Cyber Crisis Management Plan (CCMP).

• Risk Assessment and Management Program.
• Vulnerability Management Program.
• Threat Monitoring Program.
ERPSI’s roles and responsibilities in respect of these initiatives shall be restricted to facilitating JPDCL
from the perspective of Operations and Maintenance (O&M) of the envisaged ERP System.
Page 195 of 390

JPDCL
11. Operations and Maintenance for 4 years

ERPSI shall be required to undertake the following activities for a period of four (04) years pertaining
to the envisaged ERP System at minimum; but not limited to:
• Operations & Maintenance of Application Software constituting the envisaged ERP System.
• Operations & Maintenance of ICT Infrastructure deployed for the envisaged ERP System.
• Assistance / participation in internal audits / certification audits of JPDCL.
• Transition / Exit Management.
11.1 Operations & Maintenance of Application Software constituting the

envisaged ERP System
Operations and Maintenance of Application Software constituting the envisaged ERP System shall
include, but not limited to:
• Production monitoring.
• Troubleshooting.
• Addressing the functionality, availability and performance issues.
• Keeping the envisaged ERP System up-to-date from the perspective of applying patches /
updated / upgrades – functional and technical.
• Ensuring cybersecurity of the envisaged ERP System.
• Implementing the system change requests.
ERPSI shall keep the Application Software constituting the envisaged ERP System in good working
condition, meeting the requirements defined by JPDCL, perform changes and upgrades to applications
as required / requested (through change requests) by JNPT.
Broad scope coverage for Operations & Maintenance of Application Software constituting the
envisaged ERP System shall include the following; but not be limited to:
• Compliance to SLA.
• Maintenance of Application Software constituting the envisaged ERP System.
• Implementing functional and technical upgrades / updates from OEMs of Application
Software products comprised in the envisaged ERP System.
• Problem Identification and Resolution.
• Software Change and Version Control.
• Maintain Configuration Information and System Documentation.
• Delivery of and improvement in Helpdesk Services.
• Deployment of qualified Manpower for Application Support.
Page 196 of 390

JPDCL
11.1.1 Compliance to SLA

ERPSI shall ensure compliance to uptime and performance requirements of the envisaged ERP System
as indicated in the SLA in the RFP. Any upgrades / major changes to the Application Software
constituting the envisaged ERP System shall be planned accordingly by ERPSI for ensuring adherence
to the SLA requirements.
11.1.2 Maintenance of Application Software constituting the

envisaged ERP System
ERPSI shall address all the errors / gaps in the functionality / technical features offered by the
envisaged ERP System (vis-à-vis that which was captured and signed-off in ‘Software Requirement
Study’, ‘Infrastructure Requirement Study’, ‘To-be Process documentation, Gap Analysis and Business
Process Re-engineering’, ‘Software Architecture and Design’ and ‘ICT Infrastructure Architecture and
Design’ for the envisaged ERP System) at no additional cost during the Operations and Maintenance
Track.
For changes to the envisaged ERP System; beyond the agreed requirements which were captured and
signed off, a separate Change Control Note (CCN) shall be prepared and executed by the ERPSI after
the due approvals obtained from JPDCL.
It shall be noted that any change / upgrade to the Application Software constituting the envisaged ERP
System performed during the Operations and Maintenance Track shall be subjected to the
comprehensive and rigorous Acceptance Testing by the ERPSI and / or JPDCL (as the case my require)
to ensure that the changes implemented in the envisaged ERP System meet the desired and specified
requirements of JPDCL, and do not impact any other function or security configurations of the
11.1.3 Implementing functional and technical upgrades /

updates from OEMs of Application Software products
comprised in the envisaged ERP System
ERPSI is expected to purchase maintain Annual Technical Support (ATS) for all products comprised in
the envisaged ERP System for the entire duration of four (04) years of the Operations and
Maintenance Track. ATS is expected to allow ERPSI / JPDCL to avail the following at minimum; but not
limited to, without any additional payments to the OEMs of products:
• Bug fixes / patches / updates.
• Functional and technical upgrades.
• Security patches.
Whenever a Security patch is released by an OEM of a product comprised in the envisaged ERP System,
ERPSI shall immediately inform and discuss implementation of the same with the JPDCL Coordinator.
For all other categories of functional and technical upgrades / updates, ERPSI shall periodically (at
least quarterly) discuss the implementation of the of functional and technical upgrades / updates with
Page 197 of 390

JPDCL
the JPDCL Coordinator. Implementation of these of functional and technical upgrades / updates shall
follow the Change Control Process set-up by JPDCL.
For changes to the envisaged ERP System under this category, a separate Change Control Note (CCN)
shall be prepared and executed by the ERPSI after the due approvals obtained from JPDCL.
It shall be noted that any change on account of implementation of functional and technical upgrades
/ updates from OEMs of Application Software products to the Application Software constituting the
envisaged ERP System performed during the Operations and Maintenance Track shall be subjected to
the comprehensive and rigorous Acceptance Testing by the ERPSI and / or JPDCL (as the case my
require) to ensure that the changes implemented in the envisaged ERP System meet the desired and
specified requirements of JPDCL, and do not impact any other function or overall security of the
11.1.4 Problem Identification and Resolution

ERPSI shall be responsible for identification and resolution of problems in respect of the Application
Software constituting the envisaged ERP System including; but not limited to:
• System malfunctions.
• Performance problems.
• Data corruption.
It shall be noted that the scope coverage pertaining to problem identification and resolution which is
expected to be addressed by the ERPSI shall be restricted to the SaaS-based ERP Application and
supporting application software, third-party services, tools, etc. implemented by them during this
Project.
Scope coverage expected to be addressed by the ERPSI in regards of problem identification and
resolution pertaining to the integrated existing applications, supporting application software, third-
party services, tools, etc. (that have only been integrated by the ERPSI to the envisaged ERP System)
shall be restricted to raising the ticket on the respective vendors and tracking for closure through the
IT Helpdesk.
11.1.5 Software Change and Version Control

All planned changes to Application Software constituting the envisaged ERP System shall be
coordinated within established Change Control processes to ensure that:
• Proper approvals have been received for required changes / modifications.

• Schedules have been adjusted to minimize impact on the implementation and Operations and
Maintenance Tracks of the Project.
ERPSI shall define the Software Change Management and Version Control process and obtain
approval for the same from JPDCL.
Page 198 of 390

JPDCL
For any changes to the of Application Software constituting the envisaged ERP System, ERPSI shall be
expected to prepare detailed documentation including proposed changes, impact to the envisaged
ERP System in terms of functional outcomes / additional features added to the envisaged ERP System,
changes to the risks identified, etc.
ERPSI shall be expected to obtain approval from JPDCL for all the proposed changes before
implementation of the same into production environment and such documentation shall be subject
to review at the end of each quarter of Operations and Maintenance Track.
11.1.6 Maintain Configuration Information and System

Documentation
ERPSI shall be expected to maintain Configuration Information for the Application Software
constituting the envisaged ERP System and any associated System Documentation throughout the
tenure of the Project. The same shall be submitted for safe custody / back-up to JPDCL.
ERPSI shall also be required to maintain and update all documentation pertaining to the envisaged
ERP System to ensure that:
• Source code along with required tools / procedure are documented.

• System specifications are documented.
• Application documentation is updated to reflect on-going maintenance and enhancements
including; but not limited to, ‘To-be Process documentation, Gap Analysis and Business
Process Re-engineering’, ‘Software Architecture and Design’ and ‘ICT Infrastructure
Architecture and Design’, in accordance with the defined standards and compliance
requirements.
• User manuals and training manuals are updated to reflect on-going changes / enhancements.
• Standard practices are adopted and followed in respect of version control and management.
ERPSI is expected to ensure that any tools required for managing Configuration Information and
System Documentation pertaining to the envisaged ERP System shall be provided as part of the
envisaged Solution.
11.1.7 Delivery of and improvement in Helpdesk Services

ERPSI shall setup an IT Helpdesk for the envisaged ERP System to facilitate JPDCL Users in resolving
their software issues, technical difficulties and asset management.
In addition to the scope of work elaborated in respect of the IT Helpdesk for the envisaged ERP System,
ERPSI shall ensure:
• Periodic training of the Helpdesk Operators for improvement in performance.
• Updation of the Response Repository to facilitate Helpdesk Operators.
• Undertake periodic feedbacks from Users pertaining to the performance of the IT Helpdesk
for the envisaged ERP System.
Page 199 of 390

JPDCL
Focus of the ERPSI shall be to improve the performance of the IT Helpdesk for the envisaged ERP
System through the tenure of the Operations and Maintenance Track.
11.1.8 Deployment of qualified Manpower for Application

Support
ERPSI shall be expected to place a Team of well-qualified professionals to provide support to JPDCL in
its day-to-day operation of the envisaged ERP System and helping / facilitating / hand-holding the
JPDCL Users in managing the application.
ERPSI shall be expected to make its own assessment of the workforce required for being deployed on-
site / offsite on the Project for providing day-to-day Application Support in accordance with the SLAs
defined in the RFP.
Page 200 of 390

JPDCL
11.2 Assistance / participation in internal audits / certification audits of

JPDCL
JPDCL may themselves undertake / hire services of a Third-Party Auditor to undertake periodic internal
audits for obtaining assurance in respect of security, performance and proper functioning of the
envisaged ERP System. Such audits shall include; but not be limited to:
• Inventory Audit.
• Security Audit.
• Performance Audit.
• SLA Audit.
• Helpdesk Audit.
Further, JPDCL may also undergo certification audits including; but not limited to, ISO 27001, ISO
20000, ISO 22301, etc.
ERPSI shall participate in the internal audit and certification audit activities of JPDCL. Scope of the
ERPSI shall be restricted to:
• Providing “Audit” logins to the envisaged ERP System to nominated Auditors upon receipt of
directions from JPDCL Coordinator for the specified duration.
• Extracting specific evidences from the system.
• Providing documentation maintained by the ERPSI in respect of this Project.
11.3 Support for Transition / Exit Management

At the end of the Operations and Maintenance Track / in the event of termination of Contract, ERPSI
shall be expected to provide necessary handholding and transition / exit management support to
JPDCL and / or any other agency that shall be selected for maintaining the envisaged ERP System for
a minimum period of three (03) months.
The handholding and transition / exit management support shall include; but be limited to:
• Conducting detailed walkthrough and demonstrations of the:
o Functionality and features implemented in the envisaged ERP System
o Existing applications, supporting application software, third-party services, tools, etc.

comprising the envisaged ERP System integrated with the envisaged ERP System.
o Underlying Cloud-based ICT IT Infrastructure and other ICT Infrastructure

components.
• Handing over of the Cloud instances for Data Centre and Disaster Recovery Centre.
• Handing over of admin credentials to various Application Software and ICT Infrastructure
components deployed under the Project for operationalizing the envisaged ERP System.
Page 201 of 390

JPDCL
• Handing over of data back-ups and archives.
• Handing over all documentation created and maintained for this Project.
• Addressing the queries / clarifications of JPDCL and / or agency selected by JPDCL for
maintaining the envisaged ERP System with respect to:
o Working / performance levels of the envisaged ERP System including its underlying
ICT Infrastructure.
o Overall monitoring and management of the components of the envisaged ERP

System deployed including its underlying ICT Infrastructure.
• Conducting training sessions; if any are required by JPDCL and / or agency selected by JPDCL
for maintaining the envisaged ERP System.
Page 202 of 390

JPDCL
12. Support pertaining to cybersecurity considerations during Operations

and Maintenance
12.1 Deployment of functional and technical upgrades / updates pertaining
to security of the envisaged ERP System
Keep a track of the bug fixes / updates / upgrades / patches for functional (for example: additional
methods of user authentication, etc.) and technical features concerning the security aspects of the
products and the underlying infrastructure of the envisaged ERP System comprising the envisaged ERP
System through OEM websites and / or advisories from industry-standard sources.
Such bug fixes / updates / upgrades / patches for functional and technical features shall be required
to be deployed immediately by the ERPSI. In addition, ERPSI shall be required to test these bug fixes
/ updates / upgrades / patches for functional and technical features for proper functioning, security
and performance.
ERPSI shall be expected to endeavour to keep the envisaged ERP System secure from cyber-attacks
with all up-to-date security measure made available through bug fixes / updates / upgrades / patches
for functional and technical features of the products comprising the envisaged ERP System and
advisories pertaining to the underlying infrastructure of the envisaged ERP System.
Scope coverage, expectations from ERPSI regarding their performance and method for handling
deployment of activities pertaining to deployment of functional and technical upgrades / updates
pertaining to security of the envisaged ERP System shall be as defined in the RFP.
12.2 Participation in execution of ‘Cyber Crisis Management Plan (CCMP)’

JPDCL envisions to set-up a Cyber Crisis Management Plan (CCMP) for ensuring cybersecurity of their
organization’s ICT assets. ERPSI shall be expected to participate in execution of the Cyber Crisis
Management Plan (CCMP) from the perspective of the envisaged ERP System.
Scope coverage of the ERPSI shall be restricted to components of the envisaged ERP System deployed
by the ERPSI under this Project including; but not limited to:
• SaaS-based ERP Application.

• Existing applications, supporting application software, third-party services, tools, etc.
comprising the envisaged ERP System.
• Cloud instances of Data Centre, Disaster Recovery Centre.
• Back-up systems.
• Network connectivity.
• System software.
• Any other ICT Infrastructure components.
With respect to participating in execution of Cyber Crisis Management Plan (CCMP), ERPSI shall be
expected to:
• Record security incidents at the Helpdesk.
Page 203 of 390

JPDCL
• Analyze the incidents and ascertain the security incident.

• In case of ascertaining of a security incident, escalate an identified incident to concerned
JPDCL Cyber Crisis Management Plan (CCMP) stakeholder.
• Participate in conducting Root Cause Analysis of the security incident in respect of the
components of the envisaged ERP System deployed by the ERPSI.
• Undertake necessary actions in response to the security incident (only in respect of the
components of the envisaged ERP System deployed by the ERPSI).
• Track closure of the security incidents raised to the IT Helpdesk for the envisaged ERP System.
• Update, maintain in Enterprise Content Management System and back-up systems, and make
available all versions of Project Documentation to the concerned JPDCL stakeholders of the
Project.
12.3 Participation in execution of ‘Risk Assessment and Management

Program’
JPDCL envisions to establish a Risk Assessment and Management Program for ensuring effective and
efficient management of organizational risks of JPDCL. ERPSI shall be expected to participate in
execution of the Risk Assessment and Management Program from the perspective of the envisaged
ERP System.
• Cloud instances of Data Centre, Disaster Recovery Centre.
• Network connectivity.
With respect to participating in execution of Risk Assessment and Management Program, ERPSI shall
be expected to:
• Identify risks to the envisaged ERP System.
• Identify risks to business and operations of JPDCL on account of unavailability / malfunctioning
• Record and maintain the risks in the Risk Register.
• Participate in periodic review of risks.
• Undertake actions decided during the periodic review of risks (pertaining to only those
components of the envisaged ERP System deployed by the ERPSI).
Page 204 of 390

JPDCL
• Update the Risk Register and make the up-to-date copy of the same available to all concerned
stakeholders of the Project / envisaged ERP System.
12.4 Participation in execution of ‘Vulnerability Management Program’

JPDCL envisions to set-up a Vulnerability Management Program for ensuring that:
• All known vulnerabilities of the organization’s ICT assets have been meticulously identified.
• The organization’s ICT assets are up-to-date from the perspective of security measure
undertaken for mitigating a cyber-attack.
ERPSI shall be expected to participate in execution of the Vulnerability Management Program from
the perspective of the envisaged ERP System.
With respect to participating in execution of Vulnerability Management Program, ERPSI shall be
expected to:
• Maintain the Development environment for deployment of bug fixes / updates / upgrades /
patches pertaining to security of the envisaged ERP System / identified vulnerability.
• Maintain the Staging environment for testing the deployed bug fixes / updates / upgrades /
patches (pertaining to security of the envisaged ERP System / identified vulnerability).
• Keep a track of the bug fixes / updates / upgrades / patches concerning the security of /
vulnerabilities identified in the products and the underlying infrastructure of the envisaged
ERP System comprising the envisaged ERP System through OEM websites and / or advisories
from industry-standard sources.
• Undertake all preparations for allowing JPDCL / their nominated Third-Party Auditor for
undertaking Vulnerability Assessment (VA) and Penetration Testing (PT) periodically.
• JPDCL may undertake Red Teaming exercises. ERPSI shall be expected to participate in the
exercise as the Blue Team.
• Resolve all recommendations (outcomes of the VAPT / Red Teaming exercise).
• Maintain a record of all vulnerabilities identified, source of their identification and actions
undertaken for ensuring their patching / closure / resolution.
Page 205 of 390

JPDCL
12.5 Participation in execution of ‘Threat Monitoring Program’

JPDCL envisions to establish a Threat Monitoring Program for ensuring continuous monitoring of their
organization’s ICT assets for cyber-threats and getting an early warning on a cyber-attack. To ensure
the same, JPDCL may establish a full-fledged Security Operations Centre (SOC) themselves / hire
services from a Service Provider.
ERPSI shall be expected to participate in execution of the Threat Monitoring Program from the
perspective of the envisaged ERP System.

With respect to participating in execution of Threat Monitoring Program, ERPSI shall be expected to:
• Make audit logs available to the SOC Team for being collected and analysed – ensure proper
integration of log collector.
• Undertake required actions:
o In the event of a security incident.
o For resolution of recommendations identified during periodic analysis of the logs.
12.6 Participation in internal / third-party / certification audit activities of

JPDCL
JPDCL may themselves undertake / hire services of a Third-Party Auditor to undertake periodic internal
audits for obtaining assurance in respect of security, maintenance of compliance, performance and
proper functioning of the envisaged ERP System. Such audits shall include; but not be limited to:
• Process and Application Audit.
• Compliance Audit.
• Security Audit.
• SLA Audit.
• Inventory Audit.
• Performance Audit.
• Helpdesk Audit.
Page 206 of 390

JPDCL
Further, JPDCL may also undergo certification audits including; but not limited to, ISO 27001, ISO
20000, ISO 22301, etc.
ERPSI shall participate in the internal audit and certification audit activities of JPDCL. Scope of the
ERPSI shall be restricted to:
• Providing “Audit” logins to the envisaged ERP System to nominated Auditors upon receipt of
directions from JPDCL Coordinator for the specified duration.
• Extracting specific evidence from the system.
• Providing documentation maintained by the ERPSI in respect of this Project.
Page 207 of 390

JPDCL
13. Project Documentation

In addition to drafting, updating and maintaining the required deliverables indicated in the RFP, ERPSI
shall be expected to collate and curate a Project Documentation Repository in the Enterprise Content
Management System of the envisaged ERP System.
Access to the Project Documentation Repository shall be configured according to the roles of JPDCL
stakeholders to whom the Project Documentation shall be made available. ERPSI shall be expected
to obtain the role matrix for Project Documentation Repository from JPDCL Coordinator for
undertaking the access configuration.
It is further expected that the following shall be periodically reviewed (at least half-yearly) by JPDCL
in accordance with the compliance requirements of JPDCL:
• Access to the Project Documentation Repository.
• Document classification.
• Mapping of document classification to user role.
ERPSI shall be required to update access configuration to the Project Documentation Repository in
accordance with the review comments / observations / recommendations.
14. Monitoring Performance and Service Levels

• Provide and implement tools and processes for monitoring the availability of assigned
applications, measuring the service levels, performance and utilization responding to system
outages with troubleshooting activities designed to identify and mitigate operational issues.
• The tool shall provide the exact utilization of servers and shall be able to generate per day,
per month and per quarter utilization reports based on which the payments will be made to
the ERPSI.
• Reviewing the service level reports, monitoring the service levels and identifying any
deviations from the agreed service levels.
• Monitoring of service level including availability, uptime, performance, application specific
parameters for e.g., triggering elasticity, request rates, number of users connected to a
service.
• Detecting and reporting service level agreement infringements.
• Monitoring of performance, resource utilization and other events such as failure of service,
degraded service within the cloud service provider‘s boundary.
Page 208 of 390

JPDCL
15. Usage Reporting Management

• Track system usage and usage reports.
• Monitoring, managing, and administering the monetary terms of SLAs and other billing related
aspects.
• Provide the relevant reports including real time as well as past data / information / reports for
JPDCL to validate the billing and SLA related penalties.
• ERPSI must ensure the 100% availability and provide a UAT (User Acceptance Test) for the
failover / failback scenarios after the deployment.
Page 209 of 390

JPDCL
16. Payment Terms, Deliverables and Timelines

16.1 Implementation Timelines
Implementation Timelines and Deliverables associated with each Phase of the Project are stipulated
below
S.
Phase Timeline Deliverables
No.
1. Issuance of Letter of A -
Award (LoA)
2. Signing of Contract T = A + 15 -
with ERPSI days
3. Kick-off meeting T + 15 days • Project Charter.
and Mobilization of • Final Project Plan.
onsite team • Resource Deployment Plan.
• Communication Plan.
• Risk Management Plan.
• Issue Management Procedure.
• Escalation Management Procedure.
• Quality Management Procedure.
• Change Control Procedure.
• Setting up of the following processes / mechanisms
for various project management activities.
• Escrow account set-up.
4. • Conducting T+3 • Conducting sensitization workshops.
sensitization months • Software Requirement Study.
workshops • First draft of To-be processes.
• Software • List and elaboration of the best practices prescribed
Requirement in the industry for undertaking a similar ERP
Study implementation.
• To-be Process • BPR undertaken.
documentation, • Gap Analysis undertaken.
Gap Analysis • Discussion pointers / Minutes of Meetings for the
and Business various workshops / discussion sessions held by the
Process Re- ERPSI during this phase.
engineering • Finalized functional, non-functional and technical
• Software elements of the To-be processes including, but not
Architecture limited to those specified earlier in this sub-section.
and Design • Compliance sheets of the finalized elements with:
o Functional Requirement Specification (FRS),
Non-functional Requirement Specifications
and Technical Requirement Specifications
specified in the RFP.
o Prevailing acts, rules, guidelines, manuals,
sectoral CERTs, etc. referred – mapping to
clauses / sub-clauses / sections / articles of
the documents is required.
Page 210 of 390

JPDCL
S.
No.
• Populated Requirement Traceability Matrix – first
version.
• Detailed analyses and workings undertaken during
the course of ‘To-be process documentation, Gap
Analysis and Business Process Re-engineering’
phase.
• Software Architecture and Design.
• Software Requirement Specification (SRS).
• High-level Design (HLD).
• Low-level Design (LLD).
• ERP Product documentation that elaborates on the
internal architecture of the ERP SaaS-based
Application.
• Detailed analysis and workings undertaken for
proving that the designed Software Architecture and
Design is able to address the requirements
stipulated in the RFP and prescribed by JPDCL
stakeholders, and achieve the SLAs stipulated in the
RFP.
• Populated Risk Register – first version.
5. • Procurement of T+7 • Proof of purchase of licenses in the name of JPDCL.
licenses months • Configured / customized / enhanced ERP SaaS-based
• Configuration / Application, integrated with all listed existing
Customization / systems / services, and all audit logs configured.
Enhancement • Configuration, customization, enhancement and
(new integration documents pertaining to “Configured /
development) customized / enhanced ERP SaaS-based Application,
of ERP SaaS- integrated with all listed existing systems / services,
based and all audit logs configured”.
Application • Source Code – including all configurations /
• Integration customizations / enhancements, other executable
files, etc.
• Technical documentation to explain Source Code.
• Database Design and Schema documents.
• Software Installation Guide and Checklist.
• Updated Compliance sheets (from To-be Process
documentation, Gap Analysis and Business Process
Re-engineering Sub-phase)
• Updated Software Architecture and Design.
• Updated Software Requirement Specification (SRS).
• Updated High-level Design (HLD).
• Updated Low-level Design (LLD).
• Cut-over Communication Strategy.
• Updated Requirement Traceability Matrix.
• Updated Risk Register and Issue Register.
6. Training T+7 • Training and Capacity Building Plan.
months
Page 211 of 390

JPDCL
S.
No.
• Training material / functionality guides / user
manuals for ERP Users.
• User Manuals for Consumers.
• Content for ‘Online Help and Training’.
• Uploading of all requisite documents and details
(pertaining to UI) to Knowledge Management
System Module.
• Uploading of content to ‘Online Help and Training’.
• Conduct all required trainings as per the ‘Training
and Capacity Building Plan’.
• ERP User feedback (collected post-training).
• Training Calendar for refresher trainings.
7. Data Migration T + 7.5 • Data Migration Plan.
months • Data Migration Templates.
• Sign-of on completion of Data Migration activity
from identified Data Owners (and Process Owners;
wherever applicable).
8. Acceptance Testing T+8 • Acceptance Testing Plan.
months • Solution Testing Reports:
o Unit Testing (UT) Report.
o User Acceptance Testing (UAT) Report.
o Load and Stress Testing Report.
o Stabilization Test Report.
• Integration Testing Report.
• Performance Testing Report.
• Report for Review of Data Migration.
• Security Testing and Audit Reports:
o Vulnerability Assessment and Penetration
Testing (VAPT) Report.
o Compliance Audit Report.
o Secure Configuration Review Report.
o IT General Controls Review Report.
o Report for Review of implementation of all
patches / updates from the product OEMs
(of ERP SaaS-based Application, integration
middleware, supporting system software,
tools, any other layer of software, etc.)
o Pre-Go-live Audit Report.
• Updated Requirement Traceability Matrix.
9. Set-up and T + 8.5 • Sign-off on operationalized and integrated IT
operationalization months Helpdesk infrastructure (from Competent Authority
of IT Helpdesk for within JPDCL).
Page 212 of 390

JPDCL
S.
No.
the envisaged ERP • Sign-off on completion of Helpdesk Operator
System training activities (from Competent Authority within
JPDCL).
10. Go-Live* of all ERP G=T+9 • Conduct “Demonstration and Acceptance of the
Solution (G) months envisaged ERP System” Workshop.
• Go-Live Certificate (from Competent Authority
within JPDCL).
• Mobilization of required staff for O&M.
• Exit Management Plan – first version.
11. Operations & G + 4 years • Proof of purchase of ATS for ERP SaaS-based
Maintenance Applications and other software / tools (provided by
the ERPSI as under this Project – Upon completion of
purchase).
• SLA Adherence Report (Monthly basis).
• Asset Information Register (Inventory) Review
Report (Quarterly basis).
• Error / Gap / Problem Identification and Resolution
Report (Errors / gaps identified during the course of
operations or based on calls logged at the Helpdesk
– monthly basis).
• Security Patch Deployment Status Report (Weekly).
• Bug fix / Patch / Update Deployment Status Report
(Fortnightly basis).
• Functional and Technical Upgrade Deployment
Status Report (Quarterly basis).
• Helpdesk Call and Ticket Analysis (Monthly basis).
• Helpdesk Response Repository Review Report
(Quarterly basis).
• ERP End-User Feedback Report (Quarterly basis).
• IT Helpdesk Call Volume and Quality Review Report
(Quarterly basis).
• Preventive Maintenance Report (Half-yearly basis).
• Change Request Status Report (Monthly basis).
• Root Cause Analysis Report (as and when required).
• Updated Exit Management Plan (Yearly basis).
• Updated Requirement Traceability Matrix (To be
kept updated all the time).
• Updated Risk Register and Issue Register (To be kept
updated all the time).
It shall be noted that JPDCL may direct the ERPSI to submit “additional deliverables” during the
course of the Project. ERPSI shall be required to submit the same for being considered towards
completion of the Phase.
Page 213 of 390

JPDCL
* “Go-live” definition: “Go-Live” means the date on which the envisaged ERP System is completely
operational as per the requirements provided in this RFP, subsequent changes agreed and signed-off
with the ERPSI, successful completion of all the acceptance tests to the satisfaction of JPDCL,
conducting of “Demonstration and Acceptance of the envisaged ERP System” Workshop, and issuance
of Go-Live Certificate (from Competent Authority within JPDCL). Date of issuance of Go-Live Certificate
(date of receipt of the Certificate by ERPSI from JPDCL via email / registered post) shall be deemed as
the “Date of Go-live”.
Page 214 of 390

JPDCL
16.2 Payment Terms

The payments shall be strictly made based on acceptance and quality of deliverables, performance
and timelines of services delivered by the ERPSI. The ERPSI should produce the required deliverables
as listed in the RFP indicating “Ready-for-use” status (i.e., delivery, configuration, commissioning, and
successful operation of system) for respective deliverable / services for ERP system, duly signed as
accepted by JPDCL.
16.2.1 ERP System Implementation Phase Cost

Mobilization Advance
S. ACTIVITY PAYMENT TERMS PAYMENT MILESTONES
No
Mobilization 5% of the ERP System • Submission of BG of 105% of
advance Implementation Cost equivalent value (ERP System
quoted for ERP Project Implementation Phase cost)
against a BG of 105% of • Signing of Contract agreement
equivalent value (ERP • After successful completion of
System Implementation Project Initiation Phase (as defined
1 Phase cost) in Section 6 Sub-Section 10)
• Approval by JPDCL as project
mobilization advance
• Deployment of resources on-site at
JPDCL (as defined in Section 6 Sub-
Section 10.4)
Note: In case the ERPSI accepts the mobilization advance, 5% will be deducted from software and
implementation payment components to make the total value to be 100%.
16.2.2 ERP System Software (License Component)

(ERP System Implementation Phase Cost – Part A)
No
Supply of Licenses • Supply requisite software to JPDCL.
85% of cost of software
• Acceptance accorded of receipt by
JPDCL, in form of email or letter.
1
(Staggered delivery based number of license
requirements proposed by ERPSI and
acceptance of JPDCL)
Acceptance Testing 15% of cost of software On successful Acceptance Testing
Completion completion (NO failed cases /
2 open observations shall be
allowed) and sign off by JPDCL.
Page 215 of 390

JPDCL
16.2.3 ERP System Implementation Services

(ERP System Implementation Phase Cost)
No
• Conducting sensitization 20% of the cost of Approval of all deliverables
workshops implementation phase by JPDCL as defined in
• Software Requirement Section 6 Sub-Section 10.
Study
• To-be Process
1
documentation, Gap
Analysis and Business
• Software Architecture
and Design
• Configuration / 30% of the cost of Approval of all deliverables
Customization / implementation phase by JPDCL as defined in
Enhancement (new Section 6 Sub-Section 10.
2 development) of ERP
SaaS-based Application
• Integration
• Acceptance Testing
Training 20% of the cost of Approval of all deliverables
3 implementation phase by JPDCL as defined in
Section 6 Sub-Section 10.
Data Migration 20% of the cost of Approval of all deliverables
4 implementation phase by JPDCL as defined in
Section 6 Sub-Section 10.
Go-live Balance 10% of the total cost After 3 months of
of implementation phase Submission of “Go-Live
5 Certificate” as defined in the
Sub-Section 12.6 of Section
6.
16.2.4 ERP System Operation & Maintenance Phase Cost

(After Successful Go-Live of ERP System)
S. No ACTIVITY PAYMENT TERMS PAYMENT MILESTONES

Operation & Quarterly payments at • Receipt of invoices from the
Maintenance the end of each quarter ERPSI
activities • After submission of deliverables
/ reports by ERPSI as per the
1 frequency specified in the RFP
acceptance by JPDCL.
(It shall be noted that deliverables
shall be reviewed and accepted as
per the frequency stipulated in the
Page 216 of 390

JPDCL
S. No ACTIVITY PAYMENT TERMS PAYMENT MILESTONES

RFP. However, payments shall be
processed on quarterly basis).
Note: The payment shall be made in the following manner:
• The ERPSI shall submit all the Key deliverables and services to JPDCL as per the contract
agreement.
• The completion of work and services shall be verified by JPDCL designated technical
committees.
• Payment shall be made after due verification and acceptance of completed work and services
and issue of completion certificate from the JPDCL.
16.3 In the event that the ERPSI has duly followed the procedure and JPDCL fails to make any
payment within the 45 days of production of invoice along with all supporting documents
up to satisfaction of JPDCL, the work will not be stopped, and the payment will be made
in due time upon mutual acceptance.
16.4 The Utility named in the Bidding Documents intends to use the capital subsidy {60%
(90% in case of special category states) of cost of the project} under Revamped Reforms-
based and Results linked, Distribution Sector Scheme (RDSS), 40% (10% in case of special
category states) to be arranged by the State Government/Employer through loans from
REC/PFC/or other FIs/own resources. However, the payment as per the contract payment
terms will be released timely by the Employer, without any linkage to disbursement of
the funds under RDSS scheme.
Page 217 of 390

17. Service Level Agreement

Service Level Agreement (SLA) shall be monitored as mentioned in the following table. It is expected that the envisaged ERP system shall meet the minimum
threshold of service defined against each level. Any degradation below this minimum threshold will attract penalties as per bands of service level met. The
idea is that it triggers a proper review of any defect / failure / performance that had been agreed upon for the Project, and to find resolutions in keeping with
the highest standards of service excellence.
17.1 SLAs for the Implementation

Following table stipulates the Service Levels required to be maintained by the ERPI during the Implementation Phase of the envisaged ERP System.
S. MEASUREMENT SERVICE LEVEL

KEY PERFORMANCE INDICATOR PENALTY
No METHODOLOGY TARGET
Completion of activities pertaining Submission of all stipulated 100% within timeline 0.5% per week or part thereof maximum up to 10%
to ‘Kick-off Meeting and documents. stipulated of the payment pertaining to ‘Implementation,
Mobilization of onsite team’ • Submission of CVs of 100% within timeline Integration, Customization, Realization, Testing and
each onsite team stipulated GO-Live as per SoW’.
member being In case of delay beyond 1 month, JPDCL may
deployed. terminate the contract and forfeit the PBG.
• Deployment of the
1 onsite team.
Confirmation to JPDCL 100% within timeline
Coordinator pertaining to set-up stipulated
of various project management-
related processes / mechanisms.
Submission of documentation of 100% within timeline
Escrow Account to JPDCL for stipulated
signing.
Completion of activities pertaining Proof of completion of activities 100% within timeline 0.5% per week or part thereof maximum up to 10%
2
to: stipulated as deliverables in the stipulated of the payment pertaining to ‘Implementation,
Page 218 of 390


• Conducting sensitization RFP (Attendance Sheets, Integration, Customization, Realization, Testing and
workshops discussion notes, etc.). GO-Live as per SoW’.
• Software Requirement Submission of all stipulated 100% within timeline In case of delay beyond 1 month, JPDCL may
Study documents. stipulated terminate the contract and forfeit the PBG.
• To-be Process
documentation, Gap
Analysis and Business
• Software Architecture
and Design
Completion of activities pertaining Proof of purchase of licenses in 100% within timeline 0.5% per week or part thereof maximum up to 10%
to: the name of JPDCL. stipulated of the payment pertaining to ‘Implementation,
• Procurement of licenses Proof of completion of activities 100% within timeline Integration, Customization, Realization, Testing and
• Configuration / stipulated as deliverables in the stipulated GO-Live as per SoW’.
3 Customization / RFP. In case of delay beyond 1 month, JPDCL may
Enhancement (new Submission of all stipulated 100% within timeline terminate the contract and forfeit the PBG.
development) of ERP documents. stipulated
SaaS-based Application
• Integration
to ‘Training’ stipulated as deliverables in the stipulated of the payment pertaining to ‘Implementation,
RFP. Integration, Customization, Realization, Testing and
4
Submission of all stipulated 100% within timeline GO-Live as per SoW’.
documents. stipulated In case of delay beyond 1 month, JPDCL may
terminate the contract and forfeit the PBG.
Page 219 of 390


to ‘Data Migration’ documents. stipulated of the payment pertaining to ‘Implementation,
Integration, Customization, Realization, Testing and
5
GO-Live as per SoW’.
In case of delay beyond 1 month, JPDCL may
to ‘Acceptance Testing’ documents. stipulated of the payment pertaining to ‘Implementation,
Integration, Customization, Realization, Testing and
6
GO-Live as per SoW’.
to ‘Set-up and operationalization documents. stipulated of the payment pertaining to ‘Implementation,
of IT Helpdesk for the envisaged Integration, Customization, Realization, Testing and
7
ERP System’ GO-Live as per SoW’.
to ‘Go-Live of the envisaged ERP stipulated as deliverables in the stipulated of the payment pertaining to ‘Implementation,
Solution’ RFP. Integration, Customization, Realization, Testing and
8
Submission of all stipulated 100% within timeline GO-Live as per SoW’.
documents. stipulated In case of delay beyond 1 month, JPDCL may
Page 220 of 390

JPDCL
17.2 Service Level Agreements Monitoring

JPDCL shall carry out the quarterly monitoring and performance review of ERPSI against the monthly
formulated reports for SLA. A designated third party or personal from JPDCL shall review the
performance of ERPSI against the SLA.
• The SLA reports shall be formulated based on the automated system generated reports.
• ERPSI shall submit the monthly SLA report to designated Nodal Officer as per agreed frequency
and timeline.
• For requirement of SLA audit, JPDCL may perform a visit either by internal department or by an
external contractor at respective DC / DR locations.
• The review / audit report will form a basis of any action relating to imposing penalty on or breach
of contract of the ERPSI.
17.3 Service Level Agreements and Targets

The service levels agreements shall be agreed by the ERPSI as a key performance indicator for this
engagement. These key indicators shall be used while monitoring and measuring performance of
ERPSI. The service level indicators have been categorized under:
• Availability management.
• Problem Resolution and Notification Times.
• Performance Parameters.
• Services related SLA.
All management tools required to monitor the performance of the service shall be provided by the
ERPSI at no extra cost. ERPSI would be required to provide access to the management tools to JPDCL
for monitoring purposes and would also provide the MIS reports for overall project and SLA monitoring
as a part of the contract. ERPSI shall provide all the necessary diagnostic / monitoring tools and
technology as requested and required by JDPCL to monitor the envisaged ERP System. These tools
shall monitor the product, process, and elements of the envisaged ERP System to generate the reports
and logs which can be utilized by JPDCL for further improvement and enhancements of the overall
envisaged ERP System. The description of the indicative Service Level Agreement (SLA) has been
presented below. A complete Service Level Agreement shall be made with the successful bidder at the
time of signing the contract.
Page 221 of 390

JPDCL
17.3.1. Availability Management

• Availability of envisaged ERP System: High Availability is a key requirement of JPDCL as the
envisaged ERP System is expected to enable JPDCL Officials to deliver the key activities related to
various activities. The expected availability of the envisaged ERP System shall be at minimum 99%.
The Project must also be able to rebound or recover from any planned or unplanned system
downtime, ensuring a minimal impact on the operations. ERPSI shall provide a single point of
contact on a 24*7 basis.
• Availability shall be measured on quarterly basis. Planned downtime shall not be classified as
unavailability. Planned downtime where both main as well redundant systems are not available
for providing service will be limited to maximum of 48 Hours in a quarter. ERPSI shall endeavour
to take such downtimes only during weekends or holidays preferably after End of Day (EoD).
However, duration of the maximum allowable planned downtime time will be reviewed on yearly
basis.
• The failure of the envisage ERP System on account of non-availability of infrastructure provided
by JPDCL shall not be considered while calculating SLA for that quarter.
• In case of any breach in the SLA a penalty amounting to maximum of 10% of the Quarterly O&M
charges shall be levied on the ERPSI.
Page 222 of 390

The following table outlines the availability service levels.
SERVICE PARAMETER SERVICE LEVEL VALIDATION PENALTY
ERP SaaS-based Availability of ERP SaaS- >=99.95% uptime Availability & >= 0.05% but <1% of 5% of the Quarterly
Application based Application as Downtime Reports SLA Payment
mentioned in the Scope measured using
of Work Management Tool. >= 1% but <3% of SLA 20% of the Quarterly
Payment
Measured 24*7 Basis
and Validated by >= 3% but <5% of SLA 50% of the Quarterly
Monthly SLA Payment
Performance Report
>=5% of SLA No Payment
Applications pertaining Availability of >= 99.5% uptime Availability & Less than 1% of SLA 2% of the Quarterly
to Common Services Applications pertaining Downtime Reports Payment
to Common Services measured using
(Supporting and System Software Management Tool. >=1% but <3% of SLA 10% of the Quarterly
Applications) Services which are Payment
Measured 24*7 Basis
(Helpdesk required to support the
ERP SaaS-based and Validated by >=3% but <5% of SLA 30% of the Quarterly
management System Monthly SLA Payment
Tool, etc. as specified in Application as
mentioned in Scope of Performance Report.
the RFP) >=5% but <10% of SLA 50% of the Quarterly
Work Payment
Integration Services Availability of Web >99.5% uptime Availability & Less than 1% of SLA 2% of the Quarterly
uptime Services / Middleware Downtime Reports Payment
Page 223 of 390

for integrating ERP measured using >=1% but <3% of SLA 10% of the Quarterly
SaaS-based Application Management Tool. Payment
with pertaining to
Common Services Measured 24*7 Basis >=3% but <5% of SLA 30% of the Quarterly
and Validated by Payment
Monthly SLA
Performance Report. >=5% but <10% of SLA 50% of the Quarterly
Payment
Project Management Submission of monthly 100% Minutes of meeting and 1% of the Quarterly O&M charges for each
project status reports approval of status default beyond SLA
and conducting project report by engineer in
status meeting charge.
Backup / restore ERPSI shall take backup 99% Report If the negligence is found in monthly audit, the
management as per the backup ERPSI would be penalized a sum of INR 5,000.00
schedule defined by for each default.
JPDCL
JPDCL shall periodically 100% Report INR 5,000.00 for every restore test failure.
ask (once a quarter on a
random day) ERPSI to
restore the backup data
Release Management Resolution of tickets 99% Reports generated 1 % of the Quarterly O&M charges for each
logged in Ticket from Ticket default beyond SLA
Management Tool Management Tool
Page 224 of 390

Incident Management Resolution of ticket >=99% Reports generated 0.5% of the Quarterly Payment
logged in Ticket from Ticket
Management Tool Management Tool
Ticketing Management Resolution of tickets 99% Reports generated 0.5% of the Quarterly Payment
logged from Ticket
Management Tool
Change Management Resolution of Change 99% Monthly Reports 2% of the Quarterly Payment if agreed date for
Management-related requested change is not adhered
tickets
Problem Management ERPSI shall analyse all 100% timely Root cause Report. 5% penalty of the Quarterly Payment of that
the incidents and submission covering all location/site, if the ERPSI does not submit a
provide a root cause incidents logged in that Incident Report stating problem report for that month.
report every month if month problems faced by the
there are more than 5 users. 5% penalty of the Quarterly Payment of that
incidents of the same location/site if the ERPSI does not perform the
Report detailing corrective action for more than one calendar
type. ERPSI shall take corrective and month.
the needed corrective preventive actions
action to prevent
further issues due to
the same cause.
Cyber Security Should be part of 98% Reports 1% of the Quarterly O&M charges for each
Management monthly status report default beyond SLA
Page 225 of 390

Implementation of Implementation of 100% Reports 0.2% of the Quarterly Payment for every non-
Audit audit compliance
Recommendations recommendations
given by JPDCL or its
auditor which have
been agreed by ERPSI to
be implemented.
Resource Management Resource Absent from -- Attendance verification If the resource is absent from designated location
the designated location from biometric system for more than 3 days continuously without any
prior approval from JPDCL.
Payment shall be deducted based on the pro-rata

basis. (Total O&M cost per day divided by nos. of
persons deployed) Further deduction of INR
5.000.00 per day per resource shall also be
applicable on account of loss of JPDCL services.
If the resource is absent from designated location

for more than 7 days continuously, ERPSI shall
have to provide suitable replacement as per
specified certification / experiences criteria
defined in the RFP.
SLA Monitoring Report Availability of SLA 7 working days from Monthly Report 5% of Quarterly Payment
reports covering all the end of the month
parameters required
Page 226 of 390

for SLA monitoring

within the defined time
ERP SaaS-based ERPSI to furnish details 100 % Monthly Report 1 % of the Quarterly O&M charges for each
Application / other of active users default beyond SLA
license monthly
configuration report
Remarks: Although SLA penalties shall be calculated as per above table, however total penalty to be deducted is to be capped at 10 % of the billable amount
for O&M charges
Page 227 of 390

JPDCL
17.3.2. Problem Notification and Resolution Times

Following service levels shall be applicable to the ERPSI for Operations and Maintenance Track. It shall
be noted that the SLA period is including problem identification, resolution from ERPSI or OEM and
shall bear full responsibility with ERPSI:
TYPE OF EXPECTED ACTION /

METRIC MEASURE THRESHOLD
SERVICE REMARKS
As per Delivery Initial Critical 1 Hour Initial review for

Problem Response Category, Priority and
Report (PR) High 2 Hour whether the PR has
Medium 4 Hour sufficient information
to understand the
problem Assignment
to respective
individual for analysis
Respond to initiator
informing of
assignment for
further analysis
As per Delivery Complete Critical 4 Hour Detailed analysis of

Problem Analysis / Problem Report and
Report (PR) Resolution High 6 Hour provide, root cause,
Medium 8 Hour potential risk /
impact, effort
estimate for
resolution and closing
of the problem
17.3.3. Threshold Definitions

• Critical:
Show-stopper application breakdown / crash.
Has serious implications on running the production server and has impacted all business critical
process.
• High:
Serious degradation in the application performance.
Has impacted majority of the business processes but able to continue the operations with the system
limitations. It may have serious implications on the data integrity.
It has affected or may affect, more than 5 users for the same problem.
• Medium:
Moderate degradation in the application performance.
No implications on the data integrity. No impact on the normal operations / day-to-day working.
It has affected or may affect, around less than 5 but 1 or more users for the same problem.
Page 228 of 390

JPDCL
17.3.4. Penalties in case of failure to meet Service Levels

Following penalty shall be applicable to the ERPSI in case of failure to meet provisions of Service Level
Agreement (SLA) as provided in table above:
• In case of problem categorized as “Critical”: JPDCL shall recover from the ERPSI, a sum
equivalent to 0.1% of the quarterly O&M prices for every thirty (30) minutes of delay or part
thereof over and above the given threshold limit for each of such incidents.
• In case of problem categorized as “High”: JPDCL shall recover from the ERPSI, a sum equivalent
to 0.1% of the quarterly O&M prices for every sixty (60) minutes of delay or part thereof over
and above the given threshold limit for each of such incidents.
• In case of problem categorized as “Medium”: JPDCL shall recover from the ERPSI, a sum
equivalent to 0.1% of the quarterly O&M prices for every hundred and twenty (120) minutes
of delay or part thereof over and above the given threshold limit for each of such incidents.
• The same incident shall not have happened more than 2 times in a quarter for Critical category
and 3 times in a quarter for High and Medium categories, a penalty of 5% of quarterly O&M
prices for that quarter will be levied.
• If the same incident happened more than 3 times in a quarter for Critical category and 4 times
in a quarter for High and Medium categories, the performance bank guarantee may be
forfeited, and contract may be terminated.
17.3.5. Performance Parameters

The indicative performance parameters of hardware as well as system software are listed in the below
table.
# PARAMETERS LIMIT
1 User response time (screen navigation) 3 seconds or less
2 Report response time 5 seconds or less for at least

1000 rows fetch
The above performance parameters shall be fulfilled as per below criteria:
• The performance shall be monitored every fortnight for above parameters.

• Performance shall be monitored both in peak as well as in off-peak hours. Peak hours are 10
AM to 5 PM on every working day and off-peak hours are from 5 PM to 10 AM. Time slot
within peak and off-peak hours shall be decided on mutual basis.
• The tools / software licenses used to measure above performance parameters shall be in
scope of the ERPSI.
• If the performance parameters are not fulfilled during fortnightly test, a penalty equivalent to
1% of quarterly operations and maintenance bill shall be levied.
• If performance parameters are not met more than 2 times in a quarter, ERPSI have to take
suitable measures to achieve the above stated performance benchmark. The cost of the same
shall be borne by ERPSI.
Page 229 of 390

JPDCL
17.3.6. Services related to SLA

• Reporting Procedures: ERPSI‘s representative shall prepare and distribute SLA performance
reports in an agreed upon format by the 7th working day of subsequent month of the reporting
period. The reports shall include “actual versus target” SLA performance, a variance analysis
and discussion of appropriate issues or significant events. Performance reports shall be
distributed to the Nodal Official from JPDCL, if required.
• Monitoring and Auditing: JPDCL shall review the performance of the ERPSI against the SLA
parameters each month, or at any periodicity defined in the contract document. The review /
audit report shall form basis of any action relating to imposing penalty or breach of contract.
Any such review / audit can be scheduled or unscheduled. The results shall be shared with the
ERPSI as soon as possible. JPDCL reserves the right to appoint a third-party auditor to validate
the SLA.
17.3.7. Calculation for Availability Service Levels
Uptime Calculation for the Month
• % Monthly Availability = {[(Actual Uptime + Scheduled Downtime) / Total No. of Hours in a
Month] x 100}
• "Actual Uptime" means, of the Total Hours, the aggregate number of hours in any month
during which services of the envisaged ERP System are available for use.
• "Scheduled Downtime" means the aggregate number of hours in any month during which
each services of the envisaged ERP System, are down during total Hours, due to preventive
maintenance, scheduled maintenance, other problems, or any other situation which is not
attributable to ERPSI’s failure to exercise due care in performing ERPSI‘s responsibilities.
• ERPSI shall be required to schedule “Planned maintenance time‟ with prior approval of JPDCL.
This shall be planned except the Business hours of <<DISCOM>>. In exceptional circumstances,
JPDCL may allow the ERPSI to plan scheduled downtime in the working hours where actual
production downtime will be minimal i.e., less than 30 Minutes.
• The downtime for scheduled maintenance shall be needed to be mutually agreed between
JPDCL and the ERPSI. To reduce this time, various maintenance activities can be clubbed
together with proper planning.
• "Total Hours" means the total hours over the measurement period i.e., one month (24 *
number of days in the month).
Downtime Calculation
The recording of downtime shall commence at the time of registering the call with the ERPSI for any
downtime situation for the envisaged ERP System. Downtime shall end when the problem is
rectified, and the services of the envisaged ERP System are available to the user. Down time will
not be considered for following:
• Pre-scheduled preventive maintenance and health checks (Scheduled Downtime).
• Bug in any application which causes the non-availability of the service.
Typical Operations & Maintenance Services (O&M) availability and duration of their
requirement are tabulated below for reference. The criticality of the required services is
categorized under the five categories / priorities i.e., Critical, Urgent, High, Medium, and Low.
Page 230 of 390

JPDCL
Each of the Support Category is associated with respective response and resolution time. The
criticality definitions are as follows:
SUPPORT MAXIMUN
CRITERIA RESOLUTION
CATEGORY RESPONSE TIME
Critical The system is unable to be used for 15 minutes 60 minutes

normal business activities. There is
certainty of financial loss to JPDCL.
High There is a problem with a part of the 1 hour 4 hours

system, which impacts on JPDCL decision
making. No viable workaround is
available. There is a likelihood of financial
loss.
Medium The efficiency of users is being impacted 2 hours 8 hours

but has a viable workaround.
Low A fault, which has no impact on 8 hours 24 hours

processing of normal business activities.
17.4 SLA Change Control

It is acknowledged that SLA may change as JPDCL‘s business needs evolve over the course of the
contract period. As such, this document also defines the following management procedures:
• A process for negotiating changes to the SLA.
• An issue management process for documenting and resolving particularly difficult issues.
• JPDCL and ERPSI management escalation process to be used in the event that an issue is
not being resolved in a timely manner.
Any changes to the levels of service provided during the term of this agreement shall be requested,
documented, and negotiated in good faith by both parties. Either party can request a change. Changes
will be documented as an addendum to SLA and consequently the contract.
SLA Change Process
• Both the parties may amend this SLA by mutual agreement in accordance.
• Changes can be proposed by either party.
• Normally the forum for negotiating SLA changes shall be JPDCL‘s monthly review
meetings.
Page 231 of 390

JPDCL
Version Control
All negotiated SLA changes shall require changing the version control number. As appropriate, minor
changes may be accumulated for periodic release (e.g., every quarter) or for release when a critical
threshold of change has occurred.
17.5 Issue Management

This process provides an appropriate management structure for the orderly consideration and
resolution of business and operational issues in the event that quick consensus is not reached between
JPDCL and ERPSI. It is expected that this pre-defined process shall only be used on an exception basis
if issues are not resolved at lower management levels.
17.5.1. Issue Management Process

• Either JPDCL or ERPSI may raise an issue by documenting the business or technical
problem, which presents a reasonably objective summary of both points of view and
identifies specific points of disagreement with possible solutions.
• JPDCL shall determine which committee or executive level that shall logically be involved
in resolution.
• A meeting or conference call may be conducted to resolve the issue in a timely manner.
The documented issues shall be distributed to the participants at least 24 hours prior to
the discussion if the issue is not an emergency requiring immediate attention.
• Management of JPDCL and ERPSI shall develop a temporary, if needed, and the permanent
solution for the problem at hand. ERPSI shall then communicate the resolution to all
interested parties.
• In the event a significant business issue is still unresolved, the arbitration procedures
described in the Contract shall be used.
17.5.2. Issue Escalation Process
• The purpose of this escalation process is to provide a quick and orderly method of
notifying both parties that an issue is not being successfully resolved at the lowest possible
management level. Implementing these procedures ensures that JPDCL and ERPSI
management are communicating at the appropriate levels. Escalation should take place
on an exception basis and only if successful issue resolution cannot be achieved in a
reasonable time frame.
• All issues shall be raised to the project management team, which is completely
responsible for the day to day aspects of the implementation. The project management
team shall classify the issues based on their severity level and resolve them within
appropriate timelines.
• If project management team is unable to resolve an issue, the issue shall be escalated to
the top management with options / risks detailed for decision. Top management shall
make decisions based on the options / risks presented by the IT team.
• In case one or both the parties are unsatisfied with the decision of the top management
of JPDCL, the dispute shall be resolved as specified as per JPDCL jurisdiction (legal court of
J&K).
Page 232 of 390

JPDCL
17.6 Termination of Contract and Penalties

17.6.1. Risk and Cost Factor
In the event of termination of contract on the basis of non-performance by the ERPSI as per SLA, ERPSI
shall be solely responsible for risk and cost factor thereon.
17.6.2. Breach of SLA

In case the ERPSI does not meet the service levels mentioned in this RFP for three (3) continuous time-
periods as specified in the relevant clause, JPDCL shall treat it as a case of breach of Service Level
Agreement. The following steps will be taken in such a case:
• JPDCL issues a show cause notice to the ERPSI.

• ERPSI shall be required to reply to the notice within three working days.
• if JPDCL authorities are not satisfied with the reply, the performance bank guarantee may be
forfeited, and contract may be terminated by JPDCL as per the contract.
17.6.3. Exclusions
The ERPSI shall be exempted from any delays or slippages on SLA parameters arising out of following
reasons: -
• Delay in execution due to delay (in approval, review etc.) from JPDCL‘s side. Any such delays
will be notified in written to the IT Team.
• Force Majeure.
Page 233 of 390

JPDCL
18. Governance Structure

18.1 Organization Structure
Organization structure that envisaged to be set up for the purpose of successful implementation and operation
of the Project is as follows:
Diagram: Organization Structure for implementation and operation of the envisaged ERP System
Proposed organization structure shall comprise of following constituent units:
• Project Leadership.
• GRC (Governance, Risk and Compliance) Cell.
• Project Delivery Team.
• Project Management Office.
• Audit Function.
18.1.1 Project Leadership

Project Leadership shall provide overall guidance for project strategy, implementation, operations and
maintenance, take policy and financial level decisions and be the final approving body for any decision to
be taken with respect to the envisaged ERP System.
18.1.2 GRC (Governance, Risk and Compliance) Cell

Governance Cell shall be constituted for the purpose of ensuring delivery of services by envisaged ERP System
in line with objectives set-out for it and addressing all operational subjects and issues arising during
Implementation as well as Operations and Maintenance of the envisaged ERP system.
Governance Cell shall comprise of units that shall provide guidance to the Project Teams (JPDCL and MIS) on
specific points arising during the course of the Project including day-to-day operations and managing operational
process during incidents from the perspective of governance. Committees that shall be constituted under the
Governance at minimum are:
• Business Continuity and Operational Resilience

• Risk Management
Page 234 of 390

JPDCL
• Identity and Access Management (IAM) and User Management

• Threat Monitoring and Security Operations
• Data Management and Privacy
• Compliance Monitoring
• System Architecture Control
• Vulnerability Management
18.1.2.1 Business Continuity and Operational Resilience

Business Continuity and Operational Resilience Committee shall be responsible for:
• Identify and analyze types of business and operational disruptions.

• Identify critical business services of JPDCL and processes comprising those services.
• Map business continuity and operational resilience requirements (identified and analyzed) across the
organization.
• Set up of appropriate impact tolerances for critical-important business services and ensuring
configuration of alerts for the same.
• Communicate business continuity and operational resilience plans effectively.
• Continuously monitor business continuity and operational resiliency controls.
• Update of business continuity and operational resiliency controls in case of changes to operations on
account of technology upgrade, process addition, business process re-engineering, etc.
• Conduct Disaster Recovery Centre Drills.
• Ensure data back-up is undertaken as per prescribed Standard Operating procedure (SOP).
• In case of an incident, ensure:
o Data back-ups are made available to ERPSI for restoration.
o Data is restored to allow proper functioning of the system.
• Undertake any activities required for an effective Knowledge Transfer at the end of Operations and
Maintenance Track of ERPSI’s Project duration.
Business Continuity and Operational Resilience Committee shall comprise of JPDCL Coordinator, JPDCL Business
Continuity and Operational Resilience Nodal Officer, Chief Engineer (Distribution) - JPDCL, ERPSI Project
Manager, ERPSI ICT Infrastructure Specialist, Project Management Office representatives and other JPDCL
nominated Advisors / Subject Matter Experts at minimum.
From the perspective of the envisaged ERP System, Business Continuity and Operational Resilience Committee
shall become operational at Go-live and shall continue its activities throughout the duration of the Project; i.e.
upto the end of the Operations and Maintenance Track of the Project.
18.1.2.2 Risk Management

Risk Management Committee shall be responsible for:
• Identify risks including operational risks, third party risks and supply chain risks.
• Analyze, evaluate and prepare risk treatment plan.
• Set-up risk controls under the risk treatment plan, including monitoring mechanisms for the same.
Page 235 of 390

JPDCL
• Monitor risk controls.

• Periodically review and update (if necessary) the risks, their profiling, treatment plan and associated
controls.
Risk Management Committee shall comprise of JPDCL Coordinator, Chief Engineer (Distribution) - JPDCL, Chief
Engineer (Projects) - JPDCL, Chief Engineer (Procurement and Planning) – JPDCL, ERPSI Project Manager, ERPSI
ICT Infrastructure Specialist, ERPSI Solution Architect, Project Management Office representatives and other
JPDCL nominated Advisors / Subject Matter Experts at minimum.
From the perspective of the envisaged ERP System, Risk Management Committee shall become operational from
the Project Kick-off and shall continue its activities throughout the duration of the Project; i.e. upto the end of
the Operations and Maintenance Track of the Project.
18.1.2.3 Identity and Access Management (IAM) and User Management

Identity and Access Management (IAM) and User Management Committee shall be responsible for:
• Identification of User Roles and responsibilities associated with each User Role.
• Preparation and monitoring of User Role - Authorization Matrix.
• Identification and enablement of various access mechanisms for different User Roles identified.
• Regular monitoring of User Creation activities undertaken by the IT Helpdesk for envisaged ERP System.
• Periodic review of Users and deactivation inactive Users.
• Analysis of User access and authorization upon receipt of notification of anomalous behaviour / breach.
Identity and Access Management (IAM) and User Management Committee shall comprise of JPDCL Coordinator,
Chief Engineer (Distribution) - JPDCL, Chief Engineer (Projects) - JPDCL, Chief Engineer (Procurement and
Planning) - JPDCL, ERPSI Project Manager, ERPSI ICT Infrastructure Specialist, ERPSI Solution Architect, Project
Management Office representatives and other JPDCL nominated Advisors / Subject Matter Experts at minimum.
From the perspective of the envisaged ERP System, Identity and Access Management (IAM) and User
Management Committee shall become operational from the Project Kick-off and shall continue its activities
throughout the duration of the Project; i.e. upto the end of the Operations and Maintenance Track of the Project.
18.1.2.4 Threat Monitoring and Security Operations

JPDCL envisions to establish a Threat Monitoring Program for ensuring continuous monitoring of their
organization’s ICT assets for cyber-threats and getting an early warning on a cyber-attack. To ensure the same,
JPDCL may establish a full-fledged Security Operations Centre (SOC) themselves / hire services from a Service
Provider.
Threat Monitoring and Security Operations Committee shall be in-charge of the Threat Monitoring Program and
Security Operations Centre (SOC) and shall be responsible for:
• Continuously collecting and analyzing logs of various components of the envisaged ERP System.
• Raising alerts in case an event of security violation is ascertained.
• Periodically analyze event data collected and share findings with the Vulnerability Management
Committee (for using the strengthening their Program).
Threat Monitoring and Security Operations Committee shall comprise of JPDCL Coordinator, SOC Head - JPDCL,
ERPSI Project Manager, ERPSI ICT Infrastructure Specialist, ERPSI Solution Architect, Project Management Office
representatives and other JPDCL nominated Advisors / Subject Matter Experts at minimum.
Page 236 of 390

JPDCL
From the perspective of the envisaged ERP System, Threat Monitoring and Security Operations Committee shall
become operational at Go-live and shall continue its activities throughout the duration of the Project; i.e. upto
the end of the Operations and Maintenance Track of the Project.
18.1.2.5 Data Management and Privacy

Data Management and Privacy Committee shall be responsible for:
• Identify data-sets (including; but not limited to Master Data, Transaction Data, Metadata, etc)
pertaining to the envisaged ERP System and their specific monitoring and management requirements
• Review Data Migration Plan submitted by the ERPSI and ensure preparation of ERPSI and JPDCL
stakeholders for undertaking the same.
• Review User Role - Authorization Matrix from the perspective of data management, data protection
and privacy and document access and authorization.
• Ensure security of the data residing in Development and Staging environments.
• Ensure all information security, and data protection and privacy compliances are addressed during
Acceptance Testing of the envisaged ERP System.
• Facilitate Third-Party Data Migration Audit.
• Continuously monitor the integrity of data of the envisaged ERP System and analyze data-sets upon
identification of anomalies in system data.
Data Management and Privacy Committee shall comprise of JPDCL Coordinator, Nodal Officers of modules of
the envisaged ERP System, Data Owners of data-sets pertaining to the envisaged System, ERPSI Project
Manager, ERPSI Solution Architect, Project Management Office representatives and other JPDCL nominated
Advisors / Subject Matter Experts at minimum.
From the perspective of the envisaged ERP System, Data Management and Privacy Committee shall become
operational from the Project Kick-off and shall continue its activities throughout the duration of the Project; i.e.
upto the end of the Operations and Maintenance Track of the Project.
18.1.2.6 Compliance Monitoring

The envisaged ERP System is expected to maintain compliances to various prevailing acts, rules, guidelines,
manuals, sectoral CERTs, etc. from sectoral / statutory / regulatory authorities as well as industry-accepted
standards. The envisaged ERP Systems is also expected facilitate all Users of the envisaged EPR System to
conduct business and operations of JPDCL in accordance with various prevailing acts, rules, guidelines, manuals,
sectoral CERTs, etc. from sectoral / statutory / regulatory authorities as well as industry-accepted standards.
Compliance Monitoring Committee shall be in-charge of ensuring achievement and maintenance of compliances
of and by the envisaged ERP System.
Compliance Monitoring Committee shall be responsible for:
• IT and Information Security (IS) Polices of JPDCL are in line with various applicable prevailing acts, rules,
guidelines, manuals, sectoral CERTs, industry standards etc.
• Ensuring that tenets of various applicable prevailing acts, rules, guidelines, manuals, sectoral CERTs,
industry standards etc. and IT and IS Policies of JPDCL are addressed in the:
o Functionality finalized for the envisaged ERP System.
o Technical configurations of the envisaged ERP System, its integrations and its underlying ICT
infrastructure.
Page 237 of 390

JPDCL
• Analyzing every change request from the perspective of IT and IS Policies, and Compliance.
• Reviewing and updating of compliance requirements (and hence, IT and IS Policies of JPDCL) periodically
/ changes in various applicable prevailing acts, rules, guidelines, manuals, sectoral CERTs, industry
standards etc. being followed.
Compliance Monitoring Committee shall comprise of JPDCL Coordinator, Nodal Officers of modules of the
envisaged ERP System, Process Owners of data-sets pertaining to the envisaged System, Data Owners of data-
sets pertaining to the envisaged System, ERPSI Project Manager, ERPSI Solution Architect, Functional Experts
of ERPSI, Project Management Office representatives and other JPDCL nominated Advisors / Subject Matter
Experts at minimum.
From the perspective of the envisaged ERP System, Compliance Monitoring Committee shall become operational
from the Project Kick-off and shall continue its activities throughout the duration of the Project; i.e. upto the
end of the Operations and Maintenance Track of the Project.
18.1.2.7 System Architecture Control

Architecture of the envisaged ERP System is expected to be designed based on India Enterprise Architecture
framework including Security Architecture based on the identified security controls and Zero Trust controls /
tenets.
In addition, considering that IT, IS and Operational Technologies (OT) are expected to undergo change with time;
during the Operations and Maintenance Track of the project, it is expected that the envisaged ERP System and
hence, its System Architecture shall also undergo change.
System Architecture Control Committee shall be in-charge of ensuring a robust and compliant System
Architecture for the envisaged ERP System during the Implementation Track and monitoring and controlling
changes (on account of technology / technical upgrades, addition / modification of functionality / process, IS and
/ or cybersecurity related changes, etc.) that are made to the System Architecture of the envisaged ERP System
during the Operations and Maintenance Track.
Committee shall comprise of JPDCL Coordinator, Nodal Officers of modules of the envisaged ERP System, Process
Owners of data-sets pertaining to the envisaged System, Data Owners of data-sets pertaining to the envisaged
System, ERPSI Project Manager, ERPSI ICT Infrastructure Specialist, ERPSI Solution Architect, Functional Experts
of ERPSI, Project Management Office representatives and other JPDCL nominated Advisors / Subject Matter
Experts at minimum.
From the perspective of the envisaged ERP System, Compliance Monitoring Committee shall become operational
from the Project Kick-off and shall continue its activities throughout the duration of the Project; i.e. upto the
end of the Operations and Maintenance Track of the Project.
18.1.2.8 Vulnerability Management

JPDCL envisions to set-up a Vulnerability Management Program for ensuring that:
• All known vulnerabilities of the organization’s ICT assets have been meticulously identified.
• The organization’s ICT assets are up-to-date from the perspective of security measure undertaken for
mitigating a cyber-attack.
Vulnerability Management Committee shall be in-charge of the Vulnerability Management Program and shall be
responsible for:
• Facilitate conducting of periodic Vulnerability Assessment (VA) and Penetration Testing (PT) exercises,
other Security Tests, etc.
Page 238 of 390

JPDCL
• Monitoring and ensuring implementation of recommendations from the periodic Vulnerability

Assessment (VA) and Penetration Testing (PT) exercises, other Security Tests, etc. for obtaining required
assurance of security of the envisaged ERP System.
• Monitoring OEM websites / portals industry-accepted sources, etc. for latest updates on vulnerabilities
identified in products comprised in the envisaged ERP System.
• Undertaking patching activities and ensuring all latest bug fixes / patches / updates are applied to the
respective products comprised in the envisaged ERP System.
• Undertaking rigorous testing of bug fixes / patches / updates being considered for deployment.
Vulnerability Management Committee shall comprise of JPDCL Coordinator, VM Program Head - JPDCL, ERPSI
Project Manager, ERPSI ICT Infrastructure Specialist, ERPSI Solution Architect, Project Management Office
representatives and other JPDCL nominated Advisors / Subject Matter Experts at minimum.
From the perspective of the envisaged ERP System, Vulnerability Management Committee shall become
operational at Go-live and shall continue its activities throughout the duration of the Project; i.e. upto the end
of the Operations and Maintenance Track of the Project.
18.1.3 Project Delivery Team

Project Delivery Team shall execute and implement the Project within proposed time frame, report on the
progress of the project periodically and meticulously perform activities during the Operations and Maintenance
Track.
18.1.4 Project Management Office

Project Management Office shall be responsible for providing oversight and advisory on all aspects related to
the Implementation, and Operations and Maintenance of the Project to all required stakeholders.
18.1.5 Audit Function

Audit Function shall be responsible for conducting all identified audits, review activities, etc. pertaining to the
In addition, the Audit Function shall also undertake activities to undergo various Certification Audits; as and
when decided by JPDCL, pertaining to the envisaged ERP System.
Page 239 of 390

JPDCL
18.2 Key stakeholders and their responsibilities

The roles and responsibilities for key stakeholder are elaborated in the following sections.
18.2.1 JPDCL Project Sponsor

JPDCL Project Sponsor shall be responsible for providing the overall direction and leadership for the Project.
Responsibilities of the JPDCL Project Sponsor shall be to:
• Resolve conflicts over policy and objectives.

• Nominate Nodal Officers, Process Owners, Data Owners and other Project Team Members.
• Facilitate interaction with external stakeholders such as Jammu and Kashmir Power Transmission
Corporation Limited (JKPTCL), etc.
• Review Project Status Review Reports and take appropriate actions.
• Resolve any major issues of significant project-related and operational risk, cost and impact on the
Project.
• Ensure adherence to the terms and conditions of the Contract and NDA signed between JPDCL and
ERPSI.
18.2.2 JPDCL Coordinator

JPDCL Coordinator shall be the key stakeholder of JPDCL and shall be responsible for the smooth execution of
the Project. Responsibilities of the JPDCL Coordinator shall be to:
• Facilitate interaction with various Teams; including JPDCL, ERPSI, Project Management Office, other
stakeholders, working on this Project.
• Facilitate interaction with various stakeholders such as Jammu and Kashmir Power Transmission
Corporation Limited (JKPTCL), etc. on the need communicated by ERPSI.
• Enable communication with JPDCL’s Nodal Officers, Process Owners, Data Owners and other Project
Team Members for inputs and requirements as required by ERPSI Delivery Team during various
activities.
• Facilitate obtaining of required permissions for ERPSI to enable them to complete various activities of
the Project.
• Review and monitor progress, vis-à-vis what should be accomplished and how long it should take; and
how long it has taken.
• Report status of the Project to JPDCL Project Sponsor.
• Review the Project Status Review Report and facilitate issue to JPDCL Project Sponsor, Nodal Officers,
Process Owners, Data Owners, other Project Team Members and other relevant stakeholders.
• Host the periodic Project Review meetings.
• Review project deliverables from ERPSI and facilitate sharing of the same with JPDCL Project Sponsor
and relevant stakeholders in order to provide feedback to ERPSI Project Manager.
• Co-ordinate formal reviews of the deliverables by the concerned stakeholders and ensure feedback is
addressed.
• Discuss Issues Register and Risk Register with ERPSI Project Manager and communicate decisions to
JPDCL Project Team on resolved issues / methods of handling risks.
• Facilitate acceptance of the deliverable within JPDCL and with other identified stakeholders.
Page 240 of 390

JPDCL
• Review change request or new project requirements and facilitate escalation to JPDCL Project Sponsor.
• Ensure adherence to the terms and conditions of the Contract and NDA signed between JPDCL and
ERPSI.
• Facilitate approval of invoices and release of payment to ERPSI.
18.2.3 JPDCL Project Team

JPDCL Project Team shall comprise of Nodal Officers, Process Owners, Data Owners, other Project Team
Members and representatives of external stakeholders. The JPDCL Project Team shall report to the Project
Coordinator.
The JPDCL Project Team shall be responsible for executing daily activities, and tasks under each module. They
shall be assigned across various stages depending on their competencies vis-à-vis the module / project
requirement.
18.2.4 ERPSI Project Director

Responsibilities of the ERPSI Project Director shall be:
• Selection of Delivery Team Members to work on the Project.

• Meet the JPDCL Project Sponsor periodically to discuss project development and discuss concerns, if
any.
• Overall Project Planning and steering the Project in the right direction.
• Ensure review of the final deliverables for quality is completed.
• Ensure compliance with the agreed Quality Assurance measures and standards.
• Ensure compliance to the terms and conditions of the Contract and NDA signed between JPDCL and
ERPSI.
• Resolution of conflicts over policy and objectives.
18.2.5 ERPSI Project Manager

ERPSI Project Manager shall be the key stakeholder of the ERPSI and shall be responsible for the project
execution and delivery. Responsibilities of the ERPSI Project Manager shall be to:
• Get involved in various project activities based on his / her subject matter skills and experience.
• Act as the key nodal point between JPDCL and ERPSI.
• Oversee execution of all project activities, resolve issues and report on un-resolved issues to ERPSI
Project Director.
• Shall be accountable for operational tasks and fieldwork related to the Project.
• Shall conduct quality checks on service and all deliverables at individual and peer group and ensure
defects free deliverables for further reviews.
• Facilitate deliverable review by JPDCL.
• Discuss Issues Register and Risk Register with JPDCL Coordinator and communicate decisions to ERPSI
Delivery Team on resolved issues / methods of handling risks.
Page 241 of 390

JPDCL
• Report status of the Project to the ERPSI Project Director, JPDCL Project Sponsor, JPDCL Coordinator
and other stakeholders periodically.
• Plan and manage project related budget, and keep a track of time and expense on the Project.
• Ensure compliance to the terms and conditions of the Contract and NDA signed between JPDCL and
ERPSI.
18.2.6 Functional Experts of ERPSI

ERPSI shall introduce Functional Experts for various ERP modules during the Project Kick-Off. These Functional
Experts shall contribute to the Project as follows:
• Interact with various Nodal Officer, Process Owners, Data Owners, other Project Team Members and
representatives of external stakeholders to evaluate stakeholder’s expectations.
• Work with the concerned Nodal Officer, Process Owners, Data Owners, other Project Team Members
and representatives of external stakeholders nominated by JPDCL for identification of areas of concern,
strategy formulation and knowledge transfers.
• Guide the ERPSI Delivery Team Members in formulating the Project Deliverables.
• Provide access to subject related information / data to the JPDCL Project Team Members and ERPSI
Delivery Team Members.
• Facilitate interaction with any external expert; if the need arises.
• Review the deliverables and ensuring the stakeholder expectations are adequately addressed.
• Conduct quality checks on the deliverables and ensuring compliance with the agreed quality
benchmarks.
18.2.7 Quality Management Team of ERPSI

Quality Management Team of ERPSI shall be responsible for:
• Coordinating and undertaking testing (indicated under Acceptance Testing at minimum; but not limited
to) effort including scripted and functional testing and managing the setup and assignment of the tests
using Testing Management tools.
• Use of good testing practices for their assigned focus area.
• Assist in managing any other quality related issues.
18.2.8 ERPSI Delivery Team

ERPSI Delivery Team shall comprise of ERP Software Configuration Specialists, ERP Technical Specialists, Data
Migration Specialists, Cloud Specialists, etc. and representatives of external stakeholders. The ERPSI Delivery
Team shall report to the ERPSI Project Manager.
The ERPSI Delivery Team shall be responsible for executing daily activities, and tasks under each module. They
shall be assigned across various stages depending on their competencies vis-à-vis the module / project
requirement.
Page 242 of 390

JPDCL
19. Manpower requirements

Implementation, and Operations and Maintenance of the envisaged ERP shall require a variety of
skilled resources to be deployed on suitable positions on the Project.
However, it shall be noted that a few positions have been identified by JPDCL with respect to the
Project. It shall be mandatory for the ERPSI to include these positions are included by the ERPSI in
their Project Organization and Resource Deployment Plan. In addition, it shall be mandatory for the
ERPSI to adhere to the skill, qualifications and experience requirements while considering deployment
of resources for the identified positions.
Skill, qualifications and experience requirements of the identified positions are specified in the
following table. Detailed CV for each resource deployed on the position shall be required to be
submitted to JPDCL Coordinator along with a note on compliance of the profile with the requirements
specified.
# POSITION REQUIREMENT
Project Manager • B.E. / B. Tech / M. Tech (Information Technology /
Electronics / Computer Science / Electronics &
Telecommunications / Electronics & Communication /
similar engineering) / MCA
• MBA / PGDM / MMS - preferred
1 • At least one professional certificate such as ISO 27001 / ITIL
/ PMP / Prince-2
• Min. 12 years of Experience in IT Consulting projects and
implementation of ERP / customized application
development or similar domain for at least 5 years
• Should have excellent oral & written communication skills.
Functional Consultants: • B.E. / B. Tech / M. Tech (Information Technology /
• Finance & Accounts Electronics / Computer Science / Electronics &
• Payroll & HR Telecommunications / Electronics & Communication /
Management similar engineering) / MCA (B.Com + CA may be accepted in
• Procurement Store case of ‘Functional Consultant for Finance & Accounts’ only)
and Material • Minimum 8 years of experience.
2 management • At least 2 project experience in functional implementation
• Asset Life Cycle of the module for which the Functional Consultant has been
management proposed.
• Utilities (Distribution • Adequately skilled on the SaaS-based ERP proposed.
Operations)
• Utilities Billing
• Citizen services
Solution Architect • B.E. / B. Tech / M. Tech (Information Technology /
3 • Minimum 8 years of experience.
• Should have at least 1 project experience in Power
Distribution Sector.
• At least 2 project experience in implementation of the SaaS-
based ERP proposed.
Page 243 of 390

JPDCL
# POSITION REQUIREMENT
Technical Consultant • B.E. / B. Tech / MCA / M. Tech with professional level OEM
certification like MCSE/ RHCE or equivalent
• Minimum of 8 years of Data Centre experience including 2
years of Cloud Administration experience.
• Should have at least 2 project experience on the SaaS-based
ERP proposed.
4 • Should have experience of installation, configuration,
management and monitoring of the SaaS-based ERP
proposed (including; but not limited to ensuring uptime of
the ERP system, system monitoring, administration, back-
up and restoration, etc.)
• Should have experience in Incident Resolution, Request
resolution and reporting.
O&M Support Engineer • B.E. / B. Tech / M. Tech (Information Technology /
5 • Minimum 3 years of experience
• Should have experience of implementation / providing
O&M Support Services in their respective functional
module on at least 1 project.
Page 244 of 390

JPDCL
Annexure – III : Functional Requirement Specification

Note: Following sections present the Functional Requirement Specifications for the various Modules
of the envisaged ERP System. Bidders shall note that these are comprehensive, yet indicative and in
case of being on-boarded as the ERPSI, they shall be required to undertake a detailed ‘Software
Requirement Study’ and ‘To-be Process documentation, Gap Analysis and Business Process Re-
engineering’ exercises to ensure that all functionality that is expected by JPDCL from the envisaged
ERP System is captured and the configuration / customization / enhancement (new development) is
undertaken in accordance with the exercise undertaken by them as part of the Project.
Finance and Accounts
S. No. Functional Requirements

A. General Ledger
Capability to provide the facility to have multiple, independent general ledgers/
1.
schedules
Capability to allow information to be consolidated within and across general ledgers for
2.
(month end) reporting purposes.
Capability for each General Ledger (GL) to support and be fully integrated with sales,
3.
purchase, stock and management accounting ledgers and cashbook
4. Capability of each sub-ledger to relate to a separate control account in the general ledger
5. Capability to open Memorandum Accounts for recording financial information
Capability of automatic posting (Postings to sub-ledgers should result in automatic
6.
postings to the control accounts in the general ledger)
Flexibility to accommodate current and any proposed chart of accounts structure and
7.
corporate/field organization structure
Option to have centralized or decentralized account maintenance of chart of account
8.
value
9. Capability to have parent-child hierarchy in chart of account values.
10. Addition /deletion of any account code should be restricted
11. Capability to provide facility to amend the entities (e.g.: Capture description of accounts)
12. Capability to manage Multiple foreign currency transactions
Capability to display GL account balance in multiple views as follows:
• Statutory
13.
• Responsibility (e.g., strategic business unit, Area Office/departmental reporting)
• Geographical
Capability to hold balances for multiple ledger types such as:
• Actual
• Budgeted
14.
• Forecast
• Taxation
• Tariff
Page 245 of 390

JPDCL

• As per requirement
Capability to allow enquiry by:
• Account codes and names
15.
• Wild search
• Specific range of period, year and month batch entry number
Capability of the system to display:
• Online at least 5 years of history for account balances and posted transactions
16. • Account activity including opening balance, movement for the period, closing
balance and year to date balance
• Breakdown of balances by drilling down to source document
Capability to maintain the following master data records to store control information on
how postings done into the general ledger account:
• Name of the account
• Description
• Type of account (Revenue/Expenses/Equity/Liability/Asset)
• Tax posting
17.
• Reconciliation account in nature (e.g., Debtors' & Creditors’ Control account)
• Level of transaction details to be maintained within the GL Account
• Alternative account number to store Discom existing GL account (easier for user
to search new account code)
• Automatic posting to prevent manual posting to accounts (e.g.: - Accounts
Receivable, Account Payable or any other subledger transactions)
18. Capability to create GL master data in hierarchy
Capability to
• Copy accounts between entities
• Automatically renumber account codes
• Closed accounts - block/ mark for deletion
19.
• Add accounts
• End Date accounts
• Change description of accounts
• Change the type of account.
Provide facility for mass creation of GL accounts that includes:
• Copying entire chart using another chart of accounts as reference
• Copying single account
20. • Copying multiple accounts
• Performing data transfer using program for GL account master data from legacy
system
• Allowing deletion of inactive accounts or accounts with no outstanding balance
Capability to:
21.
• Assign an activity status to accounts (e.g. - active/inactive)
Page 246 of 390

JPDCL

• Retrieve an account master record via account alias
Capability to immediately put across the electronic notification to relevant users after
22.
creation or change of master data
Capability to provide audit trail to log the creation, changes and deletion of each GL
23.
account code.
Capability to control creations, amendments and deletion of GL Master data by user-
24.
defined authorization.
Capability to search account code, account name or responsible area during posting of
25.
documents.
Capability to provide facility of Look up accounts number and descriptions during journal
26.
entry.
Capability to electronically route journal for approval to an authorized user before
27. posting to the general ledger. If rejected, the journal should be automatically routed
back to the originator for correction
28. Alert for action for vouchers pending at different level
29. Capability to assign unique number to journal entry
Capability to post allocation journals with user-definable rules (e.g.: apportionment of
30.
expenditure)
31. Capability to restrict access to certain accounts by user-defined groups.
32. Capability to control journal posting function by user-defined authorization
Capability to provide function to reverse documentation-individual or in mass, after
33.
posting by reference document number
34. Capability to post to a future and prior period by authorized users
Capability to suspend and resume, later, entry of journal that are incomplete or
35.
imbalance
36. Capability to update on-line with real time update
Capability to provide facility to:
• Allow storing (park) incomplete documents without carrying out extensive entry
checks
37. • Specify templates to capture details of recurring transactions (e.g.: - fixed
prepayments and accruals)
• Allow amendment or deletion to recurring transactions prior to posting
• Perform the posting automatically according to user-defined specification
Capability to allow for multiple accounting entries (debits and/ or credits) for each
38.
transaction type
39. Capability to provide running total of debit/credit amount
40. Capability to provide running total of transactions in each batch
Page 247 of 390

JPDCL

Capability to request for authorization of transaction exceeding maximum or transaction
41.
limits by user-defined authority
Capability to ensure that all necessary postings from various other modules are posted
42.
to the ledger before starting the closing run
Capability to automatically generate the provisions for administrative expenses,
43.
materials/ services received but invoice not received
Capability to automatically carry forward balances at the end of the year to the balance
44.
sheet and reset all profit and loss account
Capability to prevent inactive accounts from appearing on reports and financial
45.
statements
46. Capability of auto alert for odd balances (debit/credit)
47. Capability to integrate with payroll
Capability to generate a report of pending, responded and un-responded Inter Unit
48.
Transfers (IUTs)
Capability to automatically create relevant accounting entries at both units on
49.
acceptance of the inter-unit accounting by the recipient unit
Capability to perform month-end (soft closing), quarterly, date range and year-end
50.
closing
Capability to automatically, at period end:
• Post accruals
51.
• Reclassify credit and debit balances for reporting purposes
• Run the Revaluation and pass the entry
Capability to automatically update the closing balance of the previous period and
52. opening balance of the current period with prior period transaction postings for all
ledger balances. (e.g.: - actual, budget)
53. Capability to automatically initiate a new financial year
Capability to automatically net off the expense and revenue accounts closing balances
54.
to retained earnings account and carry the same to the following accounting year
Facility to make adjustment/provision entries to the consolidated Trial Balance without
55.
impacting individual unit's Trial Balance
56. Facility to re-run consolidation multiple times after adjusting the unit's accounts
Capability to:
• Consolidate at multi levels
• Consolidate actual and budget at balance sheet, profit/ loss account, cash flow
57. statement, expenses and revenue account levels
• Automate generation of elimination transactions
• Automatic generation of inter Office/ Department balances/ company
• Prepare consolidated Balance Sheet for statutory compliance & as required
Page 248 of 390

JPDCL

58. Facility to change consolidation logic from time to time based on the rules/policies.
• Capability to produce the following financial reports in multiple levels (e.g.,
whole organization, reporting units such as Area Office, zones, departments,
division, sub- division, circle, HO)) and for a user defined period (for the month,
year to date), but not limited to:
• Cost center wise reporting at division office level
• Allow for generating financial statements at the following levels:
o Across Area office,
o Circle office,
59. o Division office.
• Profit and loss account
• Analysis of Profit and Loss account
• Analysis of operating expenses
• Balance sheet
• Analysis of Balance Sheet
• Trial Balance
• Cash flow and Funds flow statement
• Notes to the financial accounts (account breakdowns)
Provide flexible Report generation with the following minimum features:
• Specify the format and layout of reports
• Summarize and total the information to be reported
• Select records to be included in the report
• Select details from each record to be included
• Perform arithmetic calculation on the information selected or totals
60.
• Capability to add narrative comments to reports
• Capability to show financial data in thousands, millions etc. without creating
rounding problem
• Capability of selection of the parameter on which the report should extract data
• Store the report format for later use
• Produce reports in graphical form for presentation purposes
61. Capability to split schedules into multiple sub schedules
62. Capability to produce user defined statutory Reports based on the requirement provided
Capability to compare actual data to budgeted data and/ or budgeted data to actual data
in:
• Annually,
63. • Half yearly,
• Quarterly,
• Monthly or
• Any specific Period.
64. Capability to export reports to standard PC applications (e.g., Excel spreadsheet,
Page 249 of 390

JPDCL

.pdf, Word, JSON,.txt/.csv format etc.)
Capability to automatically carry forward closing balances of a particular financial year
65.
to opening balance of the current year, with user defined control and authorization.
Capability to create multiple versions of financial statement report and Capability to
66.
customize reports as required by the user
67. Capability to generate comparative statements for various periods as defined by the user
68. Capability to print various reports as required by users and management
Capability to support computation of various financial ratios as defined by users and
69. Capability to compare the same with the previous year and year to date based on the
standard formulas.
Allow for generating financial statements at the following levels:
• At PDD Level
• At Corporation level
70.
• At Wing Level
• Across strategic business units
• Across departments
Capability to comply with all tax related statutory requirements in force in India and
71. applicable to the company and the system should be upgraded with the latest tax laws
on a regular basis before the amendments to tax laws come into force
Capability to generate all statutory reports applicable to the company as per prevailing
72.
laws
Capability to change opening balance after taking required approvals from corporate
73.
level.
Capability to add the additional fields to capture any specific fields which are not
74.
provided by ERP as a standard functionality.
Capability to be Integrated with the other sub-systems and provide the required data
75.
from the ERP.
Capability of freezing the balances once entry is posted and no changes to be allowed in
76.
posted journals.
B. Accounts Receivables
Capability to fully integrate account receivables to the general ledger and the cash book
1. and to allow transactional entries for customer invoices/bills, adjustment journals,
collections and employee related bills.
2. Capability to block the posting or trigger warning if update is made to a finalized account
Capability to restrict access to master record to unauthorized changes from being made
3.
as per the users’ access
Capability to set default interest rate or surcharge or access to change the same at any
4.
point of time.
Page 250 of 390

JPDCL

5. Capability to provide audit trail for source of invoice
Capability to generate periodic billing reports based on different parameters and
6.
consolidated report on total receivables at any point of time.
7. Capability to create receivables invoices into customer account if needed
8. Capability to create debit and credit memos into customer account if needed
9. Capability to reference multiple invoices in single debit/ credit memos
Capability to automatically link receivables and any payment received from customers
posted to the general ledger by
10. • Online Processing
• Batch processing
and no changes to be allowed in accounting at general ledger level.
Capability to provide recording non-sales related receivables (Miscellaneous) like
borrowings, deposits, sale of investment, sale of assets, outstanding receivables
11.
considering payment terms, interbank transfers, rent from quarters/ guest house, selling
of tender forms and Scrap Sales etc.
12. Capability to link the receipt from customer with payment gateway.
Capability to accept various payment methods such as
• JK Paysys PFMS
• CCB
• Treasury
• Cheque, bank draft, cash etc.
13.
• Bank transfer
• Offset with other expense or GL account
• Cash Reconciliation
• Any other payment method required as per the business requirement at any
point of time.
14. Capability to accept recurring payments.
15. Capability to allow receipt in installments.
16. Capability to record unbilled revenue to consumers.
17. Capability to set off single payment against different customer account under one group.
18. Capability to create different consumer IDs for single PAN/ID (if required).
Capability to comply with statutory provisions for different customer of single identity
19.
(PAN)
20. Capability to provide ageing as on date based on the different criteria.
Capability to display incoming payment details and produce incoming payment reports
on demand from the system –
21.
• By customer/vendor amount
• By collection date
Page 251 of 390

JPDCL

• By method of payment
• By location
• By type of payment
• By Invoice Reference (Electricity Bill Number)
• By any other criteria specified/suggested by management.
Capability to get the payment data wrt different component of an electricity bill i.e.. Bill
22.
Amount, Demand charge, Late fees, Interest etc.
Capability to issue the refund to customer/vendor and automatically post the refund to
23.
the customer/vendor account.
Capability to refund to the customer/vendor using various payment methods such as:
• Cash
• Cheque
24.
• Bank Transfer
• Any other Payment method required as per the business requirement at any
point of time.
Capability to override the payment method proposed by the system in exceptional cases
25.
with the proper approval mechanism by management.
Capability to print petty cash or payment voucher, cheque and refund statement from
26.
the system
27. Capability to post refund transaction automatically to general ledger
Capability to manage:
• Post adjustment into the customer account. e.g.: reverse the original payment
28. transaction to reinstate the original debt (Reversal of Receipt)
• Change the invoice reference against which payment is received.
• Import dishonored cheque details in an electronic media supplied by the bank
Capability to capture reasons for dishonor of a cheque and maintain customer's payment
29.
default history.
30. Capability to adjust the receipt against multiple invoices raised.
Capability to modify the invoice reference against a receipt at the later date and posting
31.
the same to general ledger automatically through online processing.
32. Capability to charge penalty to the customer account based on user- defined conditions
33. Capability to re-charge penalty imposed by bank to the customer/vendor account (if any)
34. Capability to reverse payment posting from the general ledger automatically.
Capability to provide the different consumers’ dashboards as mentioned below; but not
limited to:
• Total Billing (Smart-Non Smart meter wise, Division wise etc.)
35.
• Payment from customer against billing amount, Late fees, Interest on Late
Payment etc.
• Dues from Customer along with days
Page 252 of 390

JPDCL

• Consumer Previous Payment History
• No. of connections along with type of connection (Industrial/Non-Industrial) and
Load details.
C. Accounts Payables
Capability to capture the following information, but should not be limited to:
• Vendor account number,
• Vendor type (SME/ Non-SME etc.),
1.
• Vendor name, address, fax, telephone, email, contact person, payment terms,
payment methods, payment charges
• Any other information required from the business requirement.
2. Capability to make payment through PFMS/JK Paysys/electronic cash/ wallet.
Capability to provide ageing of vendors based on the criteria required as per business
3.
requirement.
4. Capability to offset third party payment.
5. Capability to directly link to tax payment site and record accounts thereof.
Flexibility to provide account numbers:
6. • Automatically based on the supplier names
• Manually
Upon creation of a new vendor account, Capability to allow for the incorporation of a
7.
check digit as a security feature to ensure accuracy of data entry
Capability to control the creation and change of vendor master data based on users’
8.
access.
Capability to allow for specified fields in the master data to be made mandatory or
9.
optional entry
Capability to perform a consistency/ outstanding amount check on the account balance
10.
based on user defined specification before account is marked for deletion
11. Capability to restrict access to master record to unauthorized changes from being made
Capability to block from posting or trigger warning if update is made to a finalized
12.
account
Capability to print vendor master data and select by new account, vendor account, status
13.
or by any other parameter as per the business requirement.
Capability to provide a list of the blacklisted vendors so that they are debarred for any
14.
future transactions.
Flexible to record payable:
• Automatically record payable entry from other system such as procurement
15. module
• Manually (direct record by the user)
• From any other third party system through integration.
Page 253 of 390

JPDCL

16. Capability to provide audit trail for source of invoice
Capability to provide invoice register facility by which the invoices could be logged prior
17.
to entry into the ledgers
Capability of the system to provide processing of following payables:
• Against purchase order/ contract only
18.
• Against purchase order/ contract only with a goods receipt note/service receipt
note
Capability to automatically generate debit/ credit memos at the time of return of the item
19. based on PO, GRN, Quality, Inspections and acceptance tests as per Discom purchase
regulation norms
Capability of the system to provide collation of purchase orders in the invoice register by
20. PO order type like material PO, Central PO, Local PO, etc. or collation on PO value,
location of raising PO and master plan wherever applicable.
Capability to capture the following information, but should not be limited to: -
• Vendor code, Internal transaction reference, vendor transaction reference,
transaction date, due date for payment calculated by the system from the
21. payment terms, posting period, transaction value, order value to which the
invoice relates
• General ledger account code, ledger narrative, value, debit credit indicator and
analysis code
22. Capability to provide manual entry for non-material related expenses
Capability to provide facility for entering invoices for prepaid expenses and apportion
23. the amount between prepaid accounts on periodic basis or no of days based on the
business requirement.
24. Capability to provide facility for entering invoices pertaining to prior periods
Capability to produce payable reports on demand within the system (but should not be
limited to):
25. • By invoice date
• By vendor type
• By user defined selection criteria based on the business requirement
Capability to trigger a warning if invoice amount exceeds balance of operating
26.
expenditure budget
Capability to block posting if invoice amount exceeds balance of capital expenditure
27.
budget
28. Capability to create debit and credit memos into vendor account manually
29. Capability to reference multiple invoices in single debit/ credit memos
30. Capability to post retention request into vendor account
Capability to perform:
31.
• Refund retention to the vendor and automatically post the refund to the vendor
Page 254 of 390

JPDCL

account
• Automatically offset retention paid up against the balance outstanding of
vendor account
Capability to refund to the vendor using various payment methods such as:
• Cash
32. • Cheque
• Bank Transfer
• Any other specified method as per the business requirement
33. Capability to provide functions to block for payment
34. Capability to manage direct payment to vendors by 3rd parties
Capability to comply with all TDS related requirements/ GST & other state and central
35.
levies.
Capability to trigger automatic alerts prior to due dates of statutory lenders and posting
36.
related accounting entries requirements like tax payments/ return filings etc.
Capability to create a proposed payment list by determining: -
• Item to be paid - items to be paid are selected and grouped for payments based
on user-defined rules
• Payment amount - based on user needs (e.g.: due date of the items)
37. • To whom the payment is made - by specifying the payee
• Payment Method - based on the payment method (e.g.: cash/cheque/ Third
Party) according to the rules defined by the user
• Payment through - the payment is made - based on the specified bank and a
bank account for the payment
Capability to make payment via methods such as:
• Cash
• Cheque - manual and pre-printed
38. • Direct payment by 3rd Parties like lenders
• Bank transfers/ Electronic Fund Transfer
• Foreign currency
• JkPaysys
Capability to specify a minimum and maximum amount for a single payment to identify
39.
the payment method to be selected by the payment program
Capability to over-write minimum and maximum value range and specify another
40.
payment method during the payment run
41. Capability to generate recurring payment voucher
Capability to capture the recurring payment information: -
• Name of the vendor
42.
• Invoice number
• Recurring number
Page 255 of 390

JPDCL

• Accounting information
• Start and end payment date
• Frequency of payment indicator to identify the frequency of the recurring
payment (e.g.: - weekly, monthly, quarterly, biannually, annually)
Capability to allow recurring payment to be deleted or edited within its period of
43.
payment
Capability to make payment in foreign currency: -
• Specify the bank account to which the payment is made from
44. • Specify whether it is possible to use the payment method to pay in foreign
currency
• Specify currencies per payment
Capability to make payment with invoices automatically using user- definable rules such
as:
45. • By oldest invoice
• By specific invoice
• Any other user defined rules
46. Capability to match single payment with multiple invoices
47. Capability to make partial payments
Capability to change payment methods or banks, payee, block items or cancel payment
48.
blocks 45. Audit Trail: Capability to display changes made and by whom
Capability to allow invoices to be released for payment prior to due date as per user
49.
defined authorization
Capability to display or print exception listing. The exception listing should contain
50. blocked items and all outstanding items which the payment program did not propose for
payment (items that could not be settled despite being due)
Capability to divide the task of editing the payment proposal between various users and
51.
enable several users to edit large payment runs at the same time
Capability to perform payment approval functions to enable certain payments to have
52.
prior approval
Capability to request for authorization of transaction exceeding maximum or transaction
53.
limits by user-defined authorities
Capability to print cheque online and perform the following functions: -
• Define void reasons (used during test print, page overflow and other user
54. defined reasons such as printed incorrectly, unusable)
• Determine the next free cheque number and store the allocation of payment
document number to cheque number
55. Capability to provide facility to print and reprint payment voucher together with cheque
Capability to mark the reprint copy with the word 'DUPLICATE'. The payment voucher
56.
should include vendor invoice number, cheque number, addresses and other user-
Page 256 of 390

JPDCL

defined information
Capability to provide feature to cancel/ void payments and cheques based on the users’
57.
access.
Capability to provide access to payment cancellation information based on user defined
58.
selection criteria and print report on cancelled cheques
59. Capability to provide full audit trails for cancelled cheques and payment vouchers
Capability to split payment to more than one payee (e.g.: payment involving withholding
60.
tax)
Capability to automatically clear items based on user criteria after payment has been
made: -
61. • By account
• By document number
• By user defined criteria
62. Capability to post payments for update to the Vendor Account
Capability to automatically post to general ledger:
• Cash discounts received
• Gains or losses from underpayment or overpayment
63.
• GST and GST TAN
• Bank Charges
• Gains or losses from exchange rate differences
Capability to provide the facility to offset balances (Netting) of vendor accounts in AP with
64.
balance of customer accounts in AR (for vendors who are also customers)
Capability to provide access to projected cash requirement information based on
65. selected items to notify head office of funds required to be transferred to the paying
account
Capability to print TDS certificates and print CEN VAT, Service Tax, GST, Income Tax and
66.
TDS report compliant with regulations, and in file-formats which support e- filing
67. Capability to post transactions such as debit and credit memos into vendor account
Capability to identify the transaction via document number (voucher number) series or
68.
document type
Capability to provide facility for:
69. • Automatic numbering of documents
• Allow for multiple document series
Capability to update to the vendor accounts with the following transactions:
70. • Transfer from one vendor account to another
• Miscellaneous debit/credit memo for adjustment
Capability to automatically update the corresponding account codes in the general
71.
ledger after posting to the individual vendor account in the sub ledger
Page 257 of 390

JPDCL

Capability to provide for automatic integration with cash book, general ledger, bank
72. ledger, penalties/ LD account, purchasing, Material management system, TDS account,
expense accounts
Capability of the system to support multilocation payments. Payments through multiple
73.
sub–Area Offices and Area Offices and zones
Capability to credit all payments first to the bank Clearing Account. Post confirmation
74.
from the bank the same will be updated to the books
Capability of the system to maintain cumulative register of cheques and to generate the
75.
cheque register print immediately after printing the cheque
76. Manage Vendor Account Enquiry
Capability to view the account balances: -
• In summary (opening balance, transaction per posting period and closing
balances)
77.
• By line items (drill down from summary)
• Drill down to document detail (e.g., purchase requisition, purchase order,
invoice, expected delivery date)
Capability to perform various display functions within a vendor account such as search,
78. sort, display additional details (e.g., vendor master information), total, view by currency,
obtain total purchase per posting period etc.
Capability to display cheque payment information on-screen based on cheque number
or payment document number. The information includes:
79. • Details of cheque recipient
• Details of the cheque issuer
• Corresponding payment and invoice documents
Capability to provide online enquiry to vendor information via user defined selection and
80.
sorting criteria (e.g., all vendors that are on hold)
Capability to:
• Select reports
• Edit reports (create/change/display)
• Export reports to different systems
• Download data to spreadsheets (e.g., Excel)
• Generate reports one at a time, multiple reports at a time, ad hoc and regular
reports together
81.
• Generate reports at on-line basis
• Generate reports in background
• Generate reports via batch
• Allow creation of user-defined reports without need for technical skills
• Perform calculations (e.g., totaling, percentage)
• Schedule for specific dates, the generation of these evaluations on a regular
basis
Page 258 of 390

JPDCL

• Restrict report selection based on security of database, organization structure
Capability to produce the following payable reports, but should not be restricted to:
• Invoices selected for payment by period, bank, payment method
• List of approved invoices
• Account Analysis Report
• List of cheques printed by cheque number and date
• List of vendors with vendor master details
• AP Liabilities Listing
• Invoices under retention
• List of inactive vendors
82. • Outstanding Cheques which are overdue
• List of cancelled and void cheques
• Details of unpaid invoices (payment proposal exception listing)
• List of realized and unrealized gains/ losses
• Number of invoices and vendors processed within a payment run
• Vendor aging Report
• TDS compliance Report
• GSTR- 2 Report
• 180 Days Input Reversal & Reclaim Report
• User defined report
Capability to provide user defined CEN VAT, Service Tax, GST, GST TAN, Income Tax, TDS
83.
and other statutory reports
Capability to produce vendor payment history including:
• Payment by vendor
• Payment by period for the current and prior year
84. • Total paid by year
• Total cumulative payments
• Date, amount and cheque number last paid
• User defined Criteria
85. Capability to electronically route the reports to allow users to review reports
86. Capability to provide facility to present report in graphs within the system
87. Capability to have a dashboard to present the actual dues of vendor by ageing.
88. Capability to present a dashboard invoice pending for approval.
89. Capability to preview report before printing
Capability to provide the user access based of SOD conflict and provide a warning if it
90.
breaches.
Capability to restrict to change the vendors details which can impact the payment for
91.
e.g. Payment terms, Due date etc. manually at invoice creation dashboard.
92. Capability to book the expenses in my multiple natural account codes in a single invoice
Page 259 of 390

JPDCL

itself
93. Capability to make the zero-payment adjusting the invoice and debit/credit memo.
94. Capability to restrict the invoice final accounting before invoice approval mechanism.
D. Cash Management / Treasury
1. Capability to monitor payment flows and safeguard liquidity
Manage Cash Book Capability to make payment through JK Paysys/ PFMS/Any other
2.
Portal if needed as per the business requirement.
Capability of the cash book to receive automatic postings from the accounts payable and
3.
accounts receivables together with manual postings of other payments and receipts
Capability to have integration with General Ledger. Posting will update specified general
4.
ledger accounts and general ledger cash book balances
Capability to generate daily incoming report and daily outgoing report and to generate
5.
daily/ weekly/ monthly cash flow report.
6. Capability to provide daily opening & closing balances from the Cash Book.
Manage Inter Unit Accounting for Account payable, Account Receivable, General Ledger
7.
& as required.
Capability of the system to maintain the funds released to the units by the expense
8.
heads and automatically post the ledger entries against inter unit account.
Capability to generate the advice for the unit to pass the journal entry to reverse the
9.
inter-unit account post receipt of funds.
Capability to perform automatic bank reconciliation based on the reconciliation
10.
references.
11. Capability to integrate bank reconciliation system with the payment.
Capability to enter bank statement details: -
• Manually
• By electronic means to match bank transaction information with receipts and
payments in the system to produce an electronic bank reconciliation
• Capability to record bank statement transactions including: -
12. • Bank and other charges
• Interest received or paid
• Electronic fund transfers
• Periodic payments
• Dishonored cheques (incoming/ outgoing)
• By Any other modes
Capability to automatically generate postings into the general ledger for outgoing
13. cheques/ transfers as: Cleared cheque/ bank transfer data delivered by the bank to
generate the clearing entries
14. Capability to automatically generate postings into the general ledger for incoming
Page 260 of 390

JPDCL

cheques/ transfers as: Bank transfers and cheques received/ banked in to generate the
clearing entries
15. Capability to print cheque deposit and bank transfer listing
16. Capability to post incoming cheques individually or in batch
17. Capability to provide function to overview cheque deposit processing status online
Capability to: -
• Record stop payment of cheques
18.
• Enable the matching of multiple receipts in the system with a single receipt
transaction on the bank statement
Capability to allow for short term planning from sources affecting the cash position. This
includes:
• Bank balances
• Maturing deposits and loans
19.
• Notified incoming payments posted to the bank accounts
• Incoming payments (e.g., cheques) with a value date
• Outgoing cheques posted to the bank clearing account
• Post-dated cheques
Capability to: -
• Allow update of bank balance by bank accounts
20. • Group bank accounts in a logical hierarchy by the type of account
• Display bank accounts by group or in more details by bank accounts via drill
down
The system should automatically reverse items outstanding for more than 3 months
21.
upon approval Cheque register (Stale cheques)
22. The system will maintain records of all cheques & cash
23. Capability to Manage Cash Register
24. Cash Management for Payment Accounts
Capability to forecast cash outflow based on:
• Liabilities from account payable and borrowings, payroll due within a user
25.
specified period
• User defined level. For example, at HO (e.g., centralized) for Area Office or zone
Capability to provide function to create, change and delete payment advice from sending
26.
bank (e.g., main) account to the receiving (e.g., Payment) bank accounts
27. Capability to provide function to create bank correspondence and/or print cheque
28. Capability to post payment advice to the respective bank account
29. Capability to post automatically to the respective bank accounts in the general ledger
30. Manage Cash Flow Forecast and Information Systems
31. Flexibility to provide for:
Page 261 of 390

JPDCL

• Electronic bank reconciliation
• Drilldown reporting tool
• Journal/ posting overview (e.g., bank transfers, deposit)
• Comparison between actual cash flows with forecasted cash flows
Capability to produce forecast cash flow statement for at least 12 months with the
following minimum details:
• Opening balance
32. • Cash outflows for: Loans, Capital projects, Revenue expenditure, Interest
payment, Tax, Dividends
• Cash inflow from: Customers, Interest received, Loan drawdown, Net
excess/surplus, Closing Balance
Capability to provide drill down capabilities to view details of outflows and inflows. For
33.
example, payment from capital projects can be further analyzed by projects/ jobs.
Capability to allow medium and long-term planning from sources affecting the liquidity
position. This includes:
• Receivables as expected incoming payments.
• Payables as expected outgoing payments (e.g., materials, project, and capital
34.
expenditure) Planned payments of wages and salaries.
• Investments and borrowings
• Planned dividend payment.
• Planned tax payment
Capability to forecast these cash outflow and inflows based on:
• Trends in fees and charges for providing distribution services based on estimates
35. and collection due dates (Accounts Receivable)
• Expenditure trends based on payment due dates (Accounts Payable)
• Fixed deposit and borrowing terms
Capability to:
• Enter forecast cash flow amount manually (e.g., dividend)
36. • Calculate averages.
• Apportion forecast amounts based on historical data (e.g., Collection and
expenditure patterns) in preparation of cash flow statement.
37. Capability to perform ‘What if’ analysis on cash flow based on user- defined assumptions
38. Manage Loans/ Grants and Deposit Management/ Bank Guarantee/ Letter of Credit
Capability to maintain the following information in the loans and deposit master, but
should not be limited to:
• Total receipt at HO from consumers and the division/ sub-division to which they
39. belong in case of direct payment.
• Lender
• Agreement date (If any)
• Loan Term, Moratorium
Page 262 of 390

JPDCL

• Instalment amount
• Interest rate, reset clause
• Loan type (Borrower ‘s note loans, Policy loan, General loan, etc.)
• Loan Source (Government or Private)
• Security Details
• Other loan details and conditions
Capability to provide function for handling the complete loan process for loan given and
40. loan taken e.g., calculation of repayment schedule, Instalments due, Interest calculation,
payment of instalment and interest, capability calculation and posting into
41. Capability to view the detailed source of loan report (local and foreign loan)
42. Manage Inter-Unit Transfer Details
The system will maintain details of all inter unit transfers of:
• Drawing account transfers from HO account to unit accounts and vice versa.
43.
• Details pertaining to transfers provided by bank like UTR number etc. will also
be maintained
44. Manage Cash Management/Treasury Reporting
45. Total Collections into Bank Vs. Total Confirmations from Bank
Total Transfers to unit HO account by bank account number and transaction Cheques
46.
deposited Vs. Cheques credited into bank
47. Dishonored checks by bank account number and identifying issuer of cheque
48. Total cheques issued Vs. Bank debits by bank account number and bank name
49. Un-reconciled statement at the area offices
50. Total cheques issued Vs. Bank debits by cumulative amount
51. Total Transfers to HO account by bank account number and transaction
52. Cheques deposited Vs Cheques credited into bank
Capability to send to Internal Audit (IA) and others as required for pre- auditing for
53.
bills/documents
54. Capability to update utilization of internal Resources
E. Budgeting / Analysis
Manage Budget Preparation
1. • Provision for interim budget.
• Out of budget/ earmarked funds, receipt & payment to be allowed.
Capability to create the following budgets but not limited to:
• Revenue Expenditure budget
• Operating Expenditure/Depreciation budget
2.
• Capital Expenditure budget
• Forecast Balance Sheet for at least 10 years
• Forecast Profit & Loss for at least 10 years
Page 263 of 390

JPDCL

• Forecast Cash Flow for at least 10 years
• Forecast Financial Ratio
• Forecast Retained Income
3. Capability to prepare budget with Top Down and Bottom-up method
Capability to provide function to compute retained Income (RI) and cash for investment
4.
forecast based on user-defined criteria
Capability to import/export budget details from / to external systems electronically (e.g.,
5.
Spreadsheet -Excel)
6. Capability to provide Windows-based spreadsheets for budget preparation
7. Capability to check and balance the detailed-level budget and the summary level budget
Capability to navigate within the budget hierarchy (e.g., expand/ collapse structure, drill
8.
down for details)
9. Capability to provide a graphical representation of the budget hierarchy
Capability to calculate and compare budget vs. actual in:
10. • Amount variance
• Percentage variance
Capability to provide text facility to document any changes made and reasons of
11.
amendments within each version of budget
12. Capability to retain user-specified versions of the budgets upon subsequent reviews
13. Flexibility to maintain, the original budget version and the revised budget version
Update the original budget by
• Increasing the budget amounts
14. • Reducing the budget amounts
• Transferring budget amounts. e.g., transfer budget from Area Office to other
Area Office
Capability to allow changes to be made for the 5-year forecast revenue and expenditure
15.
items either by manual entry or electronic upload
Capability to meet process/reporting requirements of Budget Policy & Procedures of
16.
Discom
Capability to control the following activities by account, date of change and user IDs:
• Lock subsidiary budgets and master budget so that no changes can be made
17.
once approved
• Unlock such budgets to reflect budget changes
Capability to aggregate the inputs from the different accounting units and prepare a
18.
draft consolidated budget
Capability to segregate the final consolidated approved budget, accounting unit wise
19.
Manage Revenue/ Operating expenditure budget
20. Capability to define revenue / operating expenditure budget hierarchy for responsibility
Page 264 of 390

JPDCL

areas within the organization to facilitate control and monitoring
Capability to classify revenue and expenditure items by means of a hierarchy. For
21.
example, personnel costs may consist of salary, wages, overtime, bonus etc.
Capability to provide edit functions to create, insert, copy, and delete responsible area
22.
or revenue / expenditure item within the hierarchy
Capability to identify revenue and expenditure as controllable and uncontrollable for
23.
budget control purposes
Capability to:
24. • Allow posting into a GL account prior to budget approval with proper approval
• Allow posting into a GL account after approval of budget
Capability to control authorization to create, change, delete, budget, transfer and post
by:
25. • Budget version
• Responsible area/ unit
• Type of revenue/ expense
Capability to provide level of access to create and maintain relevant assigned budgets:
• Units can only amend/ input their own budget
26. • Budgeting Cell can amend/ input all budgets for Area Offices/zones/ Head Office
/ departments; and Budget can only be approved by authorized person as
defined in the system
Capability to copy budget values into a new budget version:
27. • From a reference budget version (e.g., previous year budget or forecast budget)
• By selecting specific revenue/ expenditure accounts
28. Capability to revalue budget by percentage and by fixed amount
29. Capability to provide formula (user defined) for planning/ budgeting at the lowest level
Information required includes:
• Revenue from generation charges
• Expected increase in requisition for higher transmission capacity by existing
customers (e.g., based on trend or customer forecast)
• New customers (supported by agreements)
• Loan information
• Salaries and wages
30. • Historical and projected payroll cost and number of staff for user-defined period
• Repairs and maintenance
• Preventative maintenance schedule
• Depreciation (provision for computation of depreciation as per
o Companies Act
o ERC Regulations
o IT Act
• Existing assets
Page 265 of 390

JPDCL

Capability to generate monthly/ quarterly/ half yearly revenue/ operating expenditure
31.
budget
Capability to provide a text editor function up to the lowest budget level (i.e., revenue/
32.
expenditure accounts) to capture supporting workings that derive the budget amount
Capability to record budgets at all levels of the chart of accounts (all views of account
33.
number up to lowest level of the accounts and all levels of organization)
Capability to allow input budget data at detail level with automatic roll- up to summary
34. level by using aggregation of account (i.e., revenue and expenditure items) at multiple
levels of consolidation
Capability to allow input budget data at higher level within the budget hierarchy and
perform the following:
35.
• Manually allocate amounts to detail level based on user-specified methods
• Allocate via automatic pro-rate apportionment to user-specified detail accounts
Allow for manual override of apportioned amounts automatically pro-rated by the
36.
system
Capability to provide the option to reflect changes to amounts in a new budget version
37.
or without indicating budget as a new version (i.e., overwrite original budget)
Capability to check and highlight missing, incomplete budget items prior to consolidation
38.
(for example, a department missing from a set of departments defined for consolidation)
39. Capability to support both project/ non-project Capital expenditure budget
Capability to define a budget hierarchy for Project/ Sub-project to facilitate control and
40.
monitoring
41. Capability to use multiple currency for capital expenditure budget
Capability to determine the budgeting start year and the number of years in the future
42.
for which budgeting is allowed
Capability to:
• Provide for flexible user-defined budgeting period, e.g., 1 year, 3 years or 5 years
• Provide for fixed budget per user-defined budgeting period
43.
• Provide for sub-period budgets, e.g., monthly, quarterly, semi-annually, or
annually
• Provide Capability to create and maintain a 12-month rolling budget
44. Capability to carry forward budget outstanding from projects to the following fiscal year
Capability to carry forward commitment amount from projects to the following fiscal
45.
year
Capability to support multiple budgets by revenue accounts and expense accounts. For
46. example, to provide for at least two sets of budgets such as Annual (Original) and Revised
Budgets for each accounting entity.
47. Capability of Corporate Budgeting process to be integrated with the budgeting and
Page 266 of 390

JPDCL

planning of the individual units and support functions. Finance department (approximate
10-20 users) in the Discom would be involved in the budget preparation.
Deprecation budget should be based on existing assets and budgeted capital
48.
expenditure
49. Capability to commit budget, after posting purchase requisition in purchasing system
Capability to transfer budget between Strategic Business Unit (SBU)/ projects, according
50.
to the authorization level defined by users
51. Capability to provide annual approval budget report
Capability to integrate with the following modules on-line, but should not be limited to;
• Payroll Accounting: usage budget when post salary, bonus and wages etc.
transactions
• Account Payable: usage budget when post expenses transactions via AP
52. • General Ledger: usage budget when post expenses transactions via GL
• Project Accounting: usage budget when post expenses transactions via Project
• Purchase & Contract Management
• Inventory Management: usage budget when issue to Strategic Business Unit
(SBU)/project
53. Capability to generate document number separately when create/ change budget
54. Capability to perform automatic budget checks during transaction posting.
Capability to define tolerance limits either as a percentage or absolute value, depending
on the amount exceed, automatically perform the following:
• Trigger warning to user
55.
• Trigger warning to user and mail to budget owner
• Disallow posting
• Disallow the entry itself
56. Capability to classify budget control type, such as Cost/ Expenditure budget
Capability to provide the following information in the form of reports/ for online viewing
at multiple levels within the budget hierarchy (should not be restricted to):
• Comparison of actual against budget figures (in terms of quantity and value)
• Budgeted Balance Sheet for 10 years
57. • Budgeted Profit/ Loss account for 10 years
• Budgeted Cash flow for 10 years
• Budgeted Financial ratio for 10 years
• Forecast Retained Income
• Other forecast information
Capability to spread budget over the financial periods based on:
• Even spread
58.
• Seasonal spread
• Fixed spread
Page 267 of 390

JPDCL

• Variable spread
• Manual allocation (i.e., to enter budget figure to specific month)
Capability to generate variance analysis (Actual/ Budget) reports by user- defined
59.
parameters (e.g., time, level of detail, activity, etc.)
Capability to print the report and electronically route the reports to allow users to review
60.
reports
Capability to provide exception reports for responsible areas (e.g., Area Office, zones)
that exceeded budget with details such as:
• Revenue/ expenditure (according to chart of accounts)
61.
• Actual to date
• Budget
• Variance (i.e., amount more than budget)
Capability to automatically check and highlight abnormal data i.e., actual exceed budget
62.
more than 10% or less than 10%
63. Capability to provide over/under budget reports
64. Capability to check fund in real-time basis (for capital budget)
65. Capability to view source of fund for each project in capital expenditure budget report
66. Capability to generate budgeted financial statements for the accounting units
67. Capability to send periodic Management Information System (MIS) as & when required
Capability to prepare reports for various government agencies audit and provision for
68.
editing and preparing other reports as required
Capability to generate Cost Records Plant wise, Unit wise and as per statutory
69.
requirement as required by the Department & as per Companies Act, 2013
70. Capability to perform comparison of actual budget with tariff set by the Regulator
71. Capability of restricting the usage of budget from other than requested purpose
Capability of providing the warning when the budget is near to exhaust as per the limit
72.
prescribed
F. Auditing Process
System should allow User (Auditor) creation with access limited to viewing of the
1.
Customer Transaction data etc.
2. System should have the facility to provide Ad-hoc report writing facility for the auditors
System should have the facility to provide Interface enabling the data to be downloaded
3.
to the audit software for analysis of data for audit purpose
System should have the facility to Concurrent audit whereby transactions/activities
4.
deviating from business rules are diverted on real-time basis to internal auditors
System should have the facility to provide Internal Audit Report Template for writing of
5.
Reports
Page 268 of 390

JPDCL

System should have the facility to provide Monitoring & Scheduling of Internal Audits,
6.
Statutory Audits etc.
System should inform the Internal Audit modules users about any new
7. product/service/facility to customers/employees (such as loans) introduced by Discom
by way of a monthly MIS report
System should be able to generate MIS report highlighting any new product/
8. service/facility to customers/employees introduced in the specific office chosen for audit
between the last audit date and current audit date
9. Capability to generate any statutory report as required for compliance
10. Capability to generate pending audit unit wise or as required by Discom
The system shall have dashboards that depict the various key performance parameters
11.
at various levels
G. Bank Reconciliation
Capability to prepare cashbook on daily / monthly basis with valid accounts codes
1. Capability to reconcile with bank statement automatically in excel/Json/pdf format
provided by banks/ other financial institutions.
2. Capability to generate cash ledger division-wise, sub-division wise, wing wise
3. Capability to generate cash trial division-wise, sub-division wise, wing wise
4. Capability to generate consolidated cash ledger and cash trial
5. Capability to restrict the GL once any transaction is triggered
6. Capability to prepare Bank wise pay in slips reports
7. Capability to prepare List of Dishonored cheques issued
8. Auto generation of adjustment entries (JV) arising out of correction in cash book
Auto generation of adjustment entries (JV) arising out of sweep in- sweep out in cash
9.
book
10. Capability to prepare Schedules with details
Capability to restrict use of wrong account code by sensing the routine account codes
11.
used by each section
Produce Trigger based e-mails on the occurrence / non- occurrence of certain events to
12.
designated persons
Capability to allow manual reconciliation of the items where reference is not readily
13.
available
14. Capability to allow to unreconciled the item if wrongly reconciled with the wrong item
15. Capability to restrict any changes in the reconciled payments/receipts.
16. Capability to update the opening & closing balance of the bank book
H. Employee Expenses
Page 269 of 390

JPDCL

1. Capability to capture variable data of recovery/income from various sources for Payroll
2. Capability to adjust the bills against the advances
3. Capability to capture variable data like pay advance like TA advance, medical, etc.
Capability to account all employee income and recoveries and preparation of various
4.
schedules
5. Capability to prepare statutory returns and certificates
6. Capability to maintain the employee-wise sub-ledger for advances & receivables
Capability to prepare bank payment vouchers for payment of salary to employees and
7.
forwarding the same to cash section
Capability to capture salary details according to responsibility canter wise & bill- wise for
8.
costing appropriation, elementwise, account-code wise
Capability to Generate Final Settlement Sheet, Loan Sheet, VR Compensation Sheet for
9.
processing final settlement dues.
Capability to Generate checklist, Voucher related to final settlement dues of retiring
10.
employees
11. Capability to make monthly payment related to various VR schemes
12. Capability to capture Address and Bank details, Retiring TA Bill of retiring employees
13. Capability to capture medical bill, cabin/dietary charges, referred hospital bills
14. Capability to produce TDS certificate for employees
15. Capability to show & print Employees pay-slip at user’s end
16. Support Statutory Compliance with Labor Laws Viz. Wages Act, Factories Act, etc.
Capability to recover PF, CPF, VPF, NPS, EL, GSS, pension contribution: leave contribution
17. and make payment to employee/nominee at the time of superannuation / resignation
/ termination / death
Capability to segregate the employer's contribution towards PF and Pension and
18.
distribute to respective authorities through payment voucher
Capability to generate Pension form and transmit filled in forms electronically to Pension
19.
Authority
Capability to support gratuity payment, PF loans, PF interest, PF status, loan & VPF,
20.
GPF, EL, GSS deductions, Life cover payment in death cases.
21. Capability to capture actual expenses.
22. Capability to auto-calculate Pay commission changes as per Approving Authority.
23. Capability to calculate arrears.
24. Capability to make changes in parameters of salary from past period.
Capability to incorporate existing payroll/ master data of employees in HRMS
25.
portal/CIMS portal.
Page 270 of 390

JPDCL

Capability to timely prepare and submit various statutory returns like TDS, Professional
26.
Tax and receive acknowledgement electronically
Capability to process employee recovery data and payment to authorities like Provident
27.
Fund, Co-operative Bank and societies, LIC, Death Benefit Scheme etc.
28. Capability to generate Employee Pay-slip via HRMS portal
29. Capability to generate Wages analysis
30. Capability to generate TA/LTC/LLTC Advance and Final payment
31. Capability to generate Manpower Statement
32. Capability to generate OT & Absenteeism Report
33. Capability to generate LIC Deduction
34. Capability to generate All Loans & Advances Ledger.
35. Capability to generate Professional Tax statement
36. Capability to prepare VRS payment vouchers
37. Capability to prepare Final settlement voucher
38. Capability to prepare Income Tax salary certificate (Form 16) and Form 12B(A)
Capability to prepare PF contribution by employee and same amount contributed by
39.
employer segregated to PF and Pension
40. Capability to prepare List of the monthly pension contribution
Capability to prepare Ledger of superannuated and separated employees as per the
41.
claim
42. Capability to prepare Schedule for life cover scheme
43. Capability to prepare Monthly various return as per the proforma of the Act
44. Capability to prepare Yearly return on the pension subscription of each pensioner
45. Capability to prepare new joining / separated members of the pensioner as per the Act
Capability to prepare Yearly individual PF & Pension contribution statement with
46.
opening & closing balance
47. Capability to prepare Monthly dues & payments statement as per proforma
48. Capability to prepare monthly dispatched challans
49. Capability to update the data based on service book.
50. Capability to prepare Annual ledger of each pensioner
51. Capability to prepare Daily report of Medical / LTC / LLTC / TA advances
52. Capability to prepare Daily report of all types of bills processed for pay bill & cash
At any point of generation of report of advance (TA / LTC / LLTC) and its correlation with
53.
Accounts (Trial Balance) employee
54. Capability to prepare report on LTC / TA paid to employee quarterly etc. For LTC: Type-
Page 271 of 390

JPDCL

wise (LLTC/LTC and Exe and NonExe), Block wise, separate case on roll case
55. Capability to prepare Refer bill payment report age-wise, party wise
56. Capability to prepare Air party bill payment report - party- wise, Air lines wise
57. Capability to prepare Quarterly I.T. return to I.T. authority
Page 272 of 390

JPDCL
Human Resource Management, Payroll and ESS

A. Organization Management
Ability to define organization hierarchy, organization structure of corporate, Circle, Area
1.
Office, Site Office, Division, Sub-Division etc.
Ability to generate tree structure giving details of all unique role holders and reporting
2. employees (defining reporting and reviewing relationship) - including dual reporting
mechanism for a specific set of employees
Ability to define various categories of employees across class I, II, III & IV (list of existing
3. employees streams wise, cadre wise, wing wise or unit wise on any date or cross section
of time along with a list of officers and staff who will retire in the coming years.
4. Ability to define name of functions, sub-functions and positions
Ability to maintain reporting structure (hierarchy of positions) - including dual reporting
5.
mechanism for a specific set of employees
6. Ability to create new Discom, functions & positions
7. Ability to create new cost center, functions & positions
8. Ability to maintain GPF & other specific fund managed by company.
9. Ability to maintain change in designations due to promotions, transfers
Ability to define multiple organizational structures (positions) and multiple reporting
10.
relationships and integrate with the respective employee data
Ability to restrict making changes in the Operational Management to authorized persons
11.
only
Ability to seek confirmation after every change made in the structure, changes to be
12.
made permanent only on authentication by the controller of the authorized person.
13. Ability to change/restore/rollback changes to a previous (given) date
14. Ability to tightly integrate administrative power definitions to workflows and approvals
15. Ability to provide reports on list of vacant positions
Ability to provide reports on reporting relationships (Functional, administrative) in the
16.
Discom
17. Ability to issue orders advising to take additional charge and charge allowance
Ability to clearly define the hierarchy of Delegation of Power in the organization Human
18.
Resource Policies, Rules and Regulations
Ability to define all clauses under TA regulations, 2009, Medical Attendance rules and
19.
amendment thereof by the management
Ability to define delegation of powers to different authorities in accordance with the
20.
rules.
Ability to define all norms relating to Medical Advance and Medical re-imbursement &
21.
other re-imbursement as per company’s policy in respect of employees and their
Page 273 of 390

JPDCL

dependents
Ability to define all applicable labor laws and ability to monitor compliance/enforcement
22.
of such laws
Ability to process matters relating to employees (including action taken reports against
23.
resolution passed)
Ability to process cases for constitution of committees and reconstitution including
24.
trustee boards
25. Policies for Contractual and Outsourced employees
Ability to define all applicable labor laws for contracts laborers of Discom, clauses that
26.
are related to decision making by HR&A
27. Ability to define the policy for outsourcing of manpower in various Field Units of Discom
28. Ability to define all Rules, Procedures, Regulations for outsourced employees of Discom
B. Employee Master
Ability to store and maintain employee personal data such as employee no., name,
1. addresses, phone numbers, emergency contact information and email addresses, Salary
Bank Account Details, passport details
Ability to integrate with the JKHRMS / JK CPIS portal with the updated employee data
2.
and synchronization of data on regular basis.
Ability to maintain employee's gender, date of birth, blood group, citizenship, marital
3.
status, religion, caste etc.
Ability to maintain an employee ‘s education, certifications, degrees and any
4.
endorsements (Professional Membership)
Ability to maintain previous (multiple) employment details like name of the
5. organization, Discom, position held (designation), start/end dates, reason for leaving,
last salary drawn, references etc.
Ability to maintain names, date of birth and contact details of spouse, children,
6.
dependents, parents, dependents, nominees under different schemes, etc.
Ability to maintain employee's recruitment category like physically handicapped/
7. sportsperson /ex-servicemen / specialist / SC / ST / OBC / compassionate
grounds/Others
8. Ability to update employee's recent photograph and photograph of dependent
9. Ability to maintain employee's medical details after joining
Ability to maintain employee's health problems, medical history and capture the details
10.
(integrate with payroll for reimbursement amount)
Ability to maintain the details of employees in low medical category (like reasons, date
11.
of status change, etc.)
Ability to store caste certification verification & police verification report and detailed
12.
status
Page 274 of 390

JPDCL

Ability to issue NOC for obtaining passport/visa /study abroad or for outside
13.
employment
Ability to maintain the languages known with details of speak, read and write separately.
14.
Clear indication for the mother tongue
Ability to maintain the details of spouse and relatives in the service of the organization
15. including name, employee no., unit where working, designation with provision for
automatic updates of records of the relative as and when it is updated for him by h
16. Ability to maintain details of present designation, salary details, reporting hierarchy
Ability to maintain history of trainings attended (prior to joining & after joining) like
17. name of the course, name of the Institution, month & year of training, duration of the
course in days/weeks etc. (integrate with Training & Development)
Ability to maintain the awards for which nominated / received by the employee
18. including the name of the award, year of award, in which discipline/field and date of
receipt of award and special status/ privilege, if any, to be given to him for the award
Ability to maintain date of joining, probation period, date of confirmation, date of
19.
passing D.A. exams.
Ability to maintain details of promotion from one grade / scale / discipline to another
20.
including any reappointment through internal selections
Ability to maintain full transfer history of the employee including the current & new
21. location, nature of transfer (self-initiated / company initiated), date of joining and date
of relieving at different locations, number of times cancelled
Ability to maintain present place of posting including date of joining of each unit/office,
22.
name of the office, present designation, grade etc.
Ability to maintain history of disciplinary actions taken / initiated against the employee
23. including date of charge, nature of charge, amount of financial loss to organization, date
of punishment and nature of punishment.
Ability to maintain details of suspended employees (reasons of suspension, time
24.
duration of suspension, restricted privileges etc.)
Ability to change employee job status (Active Trainee, Probation, Extended probation,
25. Regular, Contractual, deputation, Suspended, absconding (FIR) & Exit Resigned, VRS,
Terminated/dismissed)
Ability to date and time stamp all changes in the database enabling data availability on
26.
'as on date/time' basis
27. Flexibility of additionally capturing any information relating to employee later
28. Ability to link employee data with the position based standard responsibility (Job) Matrix
Ability to maintain concurrent jobs for employees with additional
29.
responsibilities/special duties in addition to regular responsibilities
30. Ability to link employees with the membership with various Committees (permanent or
Page 275 of 390

JPDCL

temporary) and membership of any professional organization
31. Ability to maintain the record of displeasure issued to the employee
32. Ability to update only authenticated data reflected in the employee master on prompt
33. Ability to maintain employee data with regards to claims, etc.
34. Ability to maintain and view employee leave details
35. Ability to control and monitor the employees leave details
36. Ability to create a process for applying a leave and approval of the same.
Ability to maintain employee data with respect to PF, Gratuity, etc. and the nominations
37.
for the same
Ability to create organizational chart of all positions and reporting relationships based
38.
on the hierarchy.
39. Ability to provide restricted access to different classes of employee master data
Ability to maintain the insurance related details for each employee, like insurance
40.
number, nominee details, amount etc.
Ability to maintain Audit trial of all changes made to employee related sensitive
41.
information
42. Ability to maintain performance appraisal rating of last all years and promotion details
Updates of all information in Employee Master data since recruitment (such as personal
43.
details, addresses, transfers, deputation, change of location
Ability to maintain service files documents in scanned form including Proof of Date of
44.
Birth, domicile, Bonds, if any, executed, disciplinary cases details, photograph etc.
Ability to process Discom House Building Loan (For Class-IV employees) for land
45. purchase, house/flat purchase, construction of residential house, addition/alteration of
constructed house and repair of house through the portal (APR)
46. Ability to provide details of employees applying for higher education
47. Ability to submit and declare of assets by employees
Ability to update the declared assets as and when required and the same should also be
48.
documented
Ability to provide reports of employees based on blood group, length of service, age,
49.
qualification, experience, Discom, salary bands etc.
Ability to provide reports to HR&A Discom on employees personal, educational &
50.
professional details not updated in the system within a stipulated time period
Ability to provide reports on all employee details as per Discom, class/cadre-wise,
51.
location in specified period
Ability to provide reports on employee counts retired, resigned, suspended, terminated,
52.
or left, per Discom, class/cadre-wise, superannuating in a specified period
53. Ability to provide reports on status of details of disciplinary proceedings, time, progress,
Page 276 of 390

JPDCL

status
Ability to provide reports on personnel released from one place and not joined other
54.
office
Ability to provide the list of all employees eligible for transfer based on the
55.
rules/regulation
56. Ability to integrate with any other sub-system and sync the data on a regular basis.
C. Loan Facility
Ability to process Loan under tie-up arrangement with scheduled bank(s)/ any other
1.
financial institutions onboarded by JPDCL/JDPCL/Govt of J&K.
Ability to process charges of interest and other terms and conditions of tie up
2. arrangements with scheduled banks/ any other financial institutions onboarded by
JPDCL/JDPCL/Govt of J&K wrt Loan in respect to loan
Ability to process waiver of loan for the deceased employees with concurrence of the
3.
competent authorities.
Ability to penalize for non-utilization or utilization in any other purpose or delay in
4.
utilization of loan
Ability to generate report on monthly/quarterly /half yearly and yearly statements
5. covering sector wise activities of loan and retrieve relevant data of loanees of recoveries
made and outstanding amount if any linking the same with appropriate financial month
Ability to auto-generate NDC or else for grant of loan, recommendation of sanction for
6. loan, permission for purchase and sale of properties, conveyance and reconveyance of
mortgage deeds
7. Ability to provide reports on all information regarding loan (including recovery stats)
D. Attendance & Leave Management
1. Ability to mark attendance and fill time sheets
2. Ability to apply for leave under the appropriate category and state the reasons for it
3. Ability to Check the status of leave request
4. Ability to approve/cancel/modify leave requests by employees
5. Ability to view accrued leave balances
6. Ability to approve or cancel leaves of subordinates
Ability to intimate the controlling officer when an employee goes on unauthorized leave
7. (unmarked attendance) / returns from unauthorized leave/ extends leave/ reports in
the middle of the sanctioned leave period (along with appropriate reduction in sanction)
8. Ability to provide reports to subordinates and HR&A in ESS on attendance & leave details
Ability to provide multiple reminders to approver if the leaves are not approved within
9.
a stipulated time limit.
10. Ability to update the holiday in timesheet automatically as and when leave applied and
Page 277 of 390

JPDCL

no other data entry to be allowed on that day.
Ability to provide reports to HR&A and HoD on employees presently on leave in the
11.
Discom
Ability to provide the Manager consolidated status of present/absent employees
12.
working under him/her
13. Ability to provide report on attendance details & leave quota/balances
Ability to provide reports on number of employees for whom leave has not been
14.
approved/declined/modified
15. Ability to view vacancy list & status of vacancy (Filled/vacant/abolished)
16. Ability to post CVs of references as per the vacancy list
17. Ability to view Discom -wise manpower strength by HoD
18. Ability to internally apply for a job and view the status of the application
Ability to record requests by employees for passport/visa /study and outside
19.
employment and permission granted/rejected thereof
Ability to submit / update declarations for Income Tax calculation on portal and TDS
20.
calculation should be based on the same.
21. Ability to view compensation and benefit details (Pay Slip)
22. Ability to view the Performance Linked Incentives (PLI) earned during a year
23. Ability to apply for Loans & Advances and Check the status of approval
Ability to display and print pay slip information for each pay period, including gross pay,
24.
taxes, other deductions and net pay, with pay period and year-to-date totals
Ability to view Income tax computations with the new/old remiges both for more
25.
clarification
Ability to handle making online application for sanction of LTC/HTC/other entitlements
26.
through ESS and approval through workflow
27. Ability to view Insurance related details for self
Ability to apply for medical advance, HTC/LTC/Transfer TA/Transfer
28.
grant/advance/reimbursements
29. Ability to enter and approve general claims and expenses through the system
30. Ability to provide report on past salary slips & income tax statements
31. Ability to provide report on month-wise insurance premium payment receipt
E. Training & Development
1. Ability to view the training calendar and nominate oneself and subordinate for the same
Ability to approve/reject the Training requests for specific programs which were not
2. included as training needs. Learning opportunities to be considered for employees who
have ESS rights.
Page 278 of 390

JPDCL

3. Ability to view history of past trainings attended
4. Ability to apply for higher education
Ability to record requests by employees for pursuing higher education and permissions
5.
granted/rejected thereof
6. Ability to provide reports on training calendar of present/past years
7. Ability to provide reports on training programs attended during employment
8. Ability to fill appraisal documents in the system during each stage of appraisal
Ability to view appraisal documents and provide rating and feedback, view status of
9.
appraisal
Ability to handle appraisal documents even in case of dual/multiple reporting officers
10.
(across Discom)
11. Ability to provide reports to HR&A on status of completion of appraisal process
Ability to provide reports to PMS approving authority & PMS coordinating officer on
12. count of performance appraisal documents received during each stage of appraisal by
the PMS approving authority & PMS coordinating officer
Ability to provide reports of employees based on performance appraisal initiated and
13.
completed, appraisal ratings
Provision to define training - short-term, long-term, trainable and non-trainable training
14.
needs and Provision to capture ad-hoc courses offered by various entities
Ability to design selection criteria for various inhouse/ external trainings especially
15.
higher studies
16. Grading training institutions (external) by the training dept. professionals
Ability to provide training feedback by the employee supervisor 6 months post training
17.
for training effectiveness
18. Ability to capture Training Policy and customize process to update/edit the policy
19. Ability to issue orders granting higher studies without pay
Ability to issue permission for acting as examiner/faculty member/guest lecturer in
20.
different technical/management institutes
21. Ability to capture Training needs of employees met/not met during the quarter/year
Ability to formulate and update Annual Training Calendar with list of Training Programs,
22.
Batch size, target group etc.
Ability to provide input to Finance & Accounts Module for payment to
23.
Trainers/Institutes
24. Ability to update list of Trainers/Institutes for various training programs
Ability to record participant's attendance in training programs and employees
25.
nominated but did not attend a training program
Page 279 of 390

JPDCL

26. Ability to notify HoD/employees about the nomination for training program
Ability to define and print training nomination letters to be sent to employees for
27.
invitation
Ability to customize training feedback form, effectiveness form and training nomination
28.
letters
29. Ability to analyze training feedback
30. Ability to book training rooms by Discom for specific training programs
Ability to capture course content of all training programs along with list of Target group,
31.
batch size
Ability to support the process of Induction Training for new recruits by integrating with
32.
the recruitment module
Ability to maintain topic/subject-wise database of internal & external faculty, number
33.
and details of courses conducted by them quarterly, half-yearly, yearly and cumulative
Ability to maintain training budget (for each category of training) - cost of training -
actual expenses. Link the TA/DA/Hotel expenses payment records to find out total cost
34.
of training.
The TA bill passing system should be linked to the Training system
35. Ability to maintain data for internal training exam and certification obtained by staff
36. Ability to maintain data on external certifications obtained by the staff
Ability to have online registration, cancellation, reminder, and confirmation of training
37.
classes
Ability to upload external brochures or training program received from external
38.
institutes
Ability to raise Requisition / Purchase Orders (PO) for clearing professional fees of
39.
Trainers/Institutes/Stationery/Photocopy of training course content/material etc.
Ability to monitor Planned Training against actual training conducted based on user
40.
defined parameters such as number of trainings, budget, participants etc.
41. Ability to maintain training database with full training history of all employees
Ability to raise requests for guest house booking for guests & other field employees
42.
nominated for training
Ability to view status of requests for guest house booking for guests & other field
43.
employees nominated for training
Ability to provide details of vocational training and Govt. of India (apprenticeship) - only
44.
period of training, name and age/CSR training
45. Ability to produce individual and Discom training reports
Ability to provide report with the participant list and total training hours for each
46.
employee during specific period
Page 280 of 390

JPDCL

47. Ability to calculate total Training Cost in a year against the T&D Budget
Ability to provide reports on training programs nominated for but not attended during
48.
employment (reasons for not attending) Employee Exit (Full and Final Settlement)
F. Employee Exit (Full & Final Settlement)
Ability to request for VRS (integrate with Employee Master for status of disciplinary
1.
proceedings and HBL)
2. Facilitate employee to fill exit interview form (for resignation)
Ability to apply for NDC (No Demand Certificate)/clearance from various Discom
3.
departments at the time of Exit
4. Ability to initiate for NDC at the time of transfer
5. Ability to check status of selection for promotion after interview
Ability to record request for transfer through employee self-service and indicate
6. appropriately at the time of transfer exercise. Record of such request wherever acceded
to be maintained
7. Ability to provide promotion letter/increment letter through the system
Ability to view clearance request approved/ rejected by Discom and the reason for the
8.
same
Ability to generate reports on the total number of employees applied for transfers,
9.
number approved/rejected/pending
Ability to view HR Policies & Procedures Handbook including list of infrastructure
10. facilities for level of employees, authority for various approvals, special or additional
powers for authorization
Ability to view administration handbook for guidelines on aspects such as Travel, Local
11.
Conveyance, empaneled car agency, Guest Houses, Conference Rooms etc.
Ability to provide links to the important items hosted in various inhouse websites/
12.
intranet e.g., important circulars/ instructions/ policy documents etc.
13. Ability to define VRS guidelines
14. Ability to request for VRS as per the rules defined for the scheme
Ability to approve for VRS as per the rules defined for the scheme (Integrate with Payroll
15.
& E-Exit)
Ability to generate reports on the total number of employees applied for VRS, number
16.
processed/rejected/pending per year
17. Ability to Provide workflows. Accommodates multiple levels of review and approval
18. Facilitate administrator to create new self-service transactions as and when required.
19. Ability to update work schedule/shift pattern of employees
20. Ability to maintain working hours, weekly offs and national/local holidays
21. Ability to define overtime facility
Page 281 of 390

JPDCL

22. Ability to define and process overtime allowances cases beyond ceiling limit
Ability to define types of leaves: half pay leave, earned leave, casual leave, study leave,
23.
maternity, paternity, childcare - all types
24. Ability to define admissible leave for employees of all class
Ability to track attendance and map it with applied leave (between applied and leave
25.
granted)
Ability to record employee's punch in/punch out date/time details (integrating with
26.
access card machine)
Ability to manually update attendance & leave details of employees in case of
27.
employees to whom access card is not applicable (employees in field offices)
28. Ability to correct attendance & leave details of employees
29. Ability to update half day attendances/leaves in the system
Facilitate E-Exit process for employees at the time of exit. For retirement, send reminder
30.
of the retirement date to the employee one year in advance
31. Ability to fill exit interview form by superior & HR (for resignation)
Ability to process NDC (No Demand Certificate)/clearance from various departments at
32.
the time of Exit
Ability to notify (flag) individuals of any outstanding balances from various departments
33. such as payroll, time office, purchase, establishment procurement- whichever
applicable, when employee exits
Ability to generate and print Leaving Certificate / Experience Certificate once all
34.
approvals are granted
Ability to maintain case details of the employees reinstated/reappointed after being
35.
terminated
Ability to retrieve details of terminated/dismissed employees in case he/she is
36.
reinstated or reappointed
Ability to calculate back pay or other entitlements of reinstated/reappointed employees
37.
(as applicable)
G. Employee Exit Reporting Requirements
Ability to view clearance request approved/rejected by Discom and the reason for the
1.
same
Ability to generate reports on the total number of employees applied for
2.
resignations/VRS, number approved/rejected/pending
Ability to view the complete report on the exit formalities which would be available
3.
whenever it wants to be seen
4. Integrate Time and Leave Management with OM, ESS & Payroll Module
5. Facilitate leave balances to be merged/ transferred/ credited through an accrual process
Page 282 of 390

JPDCL

in the system automatically based on user defined criteria
6. Ability of record keeping and maintenance of historical data Reporting Requirements
7. Ability to provide reports on punch in/punch out date/time data
Ability to provide reports on late coming hours (summing up late hours to automatically
8.
debit from employee leave)
Ability to provide reports on total number of admissible leave and actual leaves taken in
9.
a period by an employee
Ability to produce report to reflect the half day leave, unauthorized absence, repeated
10. late arrival by employee to job location or employee working less than their normal
working hours for Time keeping and disciplinary action
11. Support alert features about scheduled dates like receipt of payments
12. Support for transactions in multiple currencies and cross currencies
Provide customizable ‗workflow ‘for all internal processes & approvals associated with
13.
the payroll system
Provision to define tax rates (including available deductions, exemptions, taxation slab
14.
rates, standard deduction, surcharge etc.)
15. Provision to define ad-hoc taxes
16. Provision to define negative tax rates and amounts
Provision for TDS calculations (if any) & tracking of TDS payable to the State
17.
Government.
Compute TDS based on previous year tax deducted (e.g., 1/12th deducted on a monthly
18.
basis)
There should be a single employee master and it should be integrated with all the
19.
company codes
Approval limits for expense reimbursement should be configured based upon the
20.
hierarchy limits
There should be a field in the master to reflect the company code to the Discom to which
21.
an employee is associated
22. Maintain information of the salary bank account
Ability to allow for the creation of user defined components of Pay like Recurring and
23. Ad hoc Allowances, Recurring and Ad hoc Deductions, User Defined Allowances &
Deductions
Ability to define various insurance schemes with premium and group insurance data
24.
generation.
Ability to allow for the computation of the following elements: Fixed Pay elements
25.
applicable to all employees Like Basic, PF, Special Allowance,
26. Ability to allow the setup of multiple payrolls with different payroll administrators &
Page 283 of 390

JPDCL

combining payroll (clearly def. semi variable, static variable payments)
27. Ability to allow restriction of administrative functions to a few select payroll users
28. Ability to have a data upload facility to upload historical payroll data
Ability to allow the maintenance of slab-wise details for statutory elements like Income
29.
Tax as well as user defined elements
30. Provision to calculate reduction in salary based on attendance policy
31. Ability to generate Form 16
32. Ability to generate TDS challan & return
Ability to allow the following calculation of onetime payment of allowance and / or
deduction, Incentive, arrear, ex-gratia, uniform, lease / conveyance maintenance,
Foundation Day, etc.,
• By Amount: enter amount to be deducted or payable,
33.
• By Days: enter number of Days for system to compute the amount based on
Basic Pay or gross Pay and/or any other component of Pay,
• By Percentage: enter percentage for system to compute the amount based on
basic pay or gross pay and/or any other component of pay
34. Allow for input of start and end date for recurring payment / deduction
Ability to automatically update Payroll database for changes in employee record without
35.
interfering with payroll processing (e.g., Promotions in the middle of month)
36. Ability to allow Back dated calculations
37. Ability to allow a final settlement report for each terminated employee
Ability to allow provision to suspend Payroll runs or control final settlement processing
38.
on a case-to-case basis
39. Ability to have the provision to run separate bonus/ incentive runs
40. Ability to provide the Ability to handle unlimited pay account codes and drawing banks
41. Ability to have a provision to process Arrear and backdated Payment calculations
42. Provision to recover advances in subsequent pay periods with a single transaction
Ability to maintain earnings history information (i.e., a record of all pays of all activity)
43.
for each employee for a user-specified period of time
44. Ability to support multiple banks or savings institutions per employee
Linkage with Punishments i.e., suspension should result in non- payment of subsistence
45.
allowance
46. Ability to calculate HRA Rebate as per the prevailing Income Tax Law/Rules
47. Ability to handle tax exemptions as per the prevailing Income Tax Law/Rules
48. Ability to handle Gratuity Calculations
49. Ability to process casual leaves for the part time sweeper and other part time employees
Page 284 of 390

JPDCL

Ability to handle Provident Fund/VPF rules like Calculate and deduct contributions
50. according to the respective Statutory Acts/ Company policy etc., maintain individual
GPF/VPF accounts and generate individual account slip for every financial year
51. Ability to conduct full and final settlement of employee during Exit
Ability to notify (flag) individuals of any outstanding balances when employee is
52.
terminated
53. Ability to record an employee's selection of benefit, retirement and deduction options
54. Ability to automatically recover salary advances
55. Ability to define multiple payment methods (Bank Transfer/Cheque Payment)
56. Ability to require approval before a specific payment is made to an employee
Ability to forward the overtime schedule to the top management for approval if the
57.
amount of overtime is over a defined percentage of the basic salary
58. Ability to maintain a salary range for each job family or job class/career band
Ability to automatically adjust calculations for mid-pay period salary, advanced salary,
59.
and employment actions
60. Ability to convert the payroll to an excel sheet
Ability to assign work calendar (scheduled workdays, scheduled holidays, etc.) to one or
61.
more employee groups
62. Ability to default standard holiday data, as well as user-defined holiday data
63. Ability to create and maintain work calendars over user-defined years
Ability to provide input to Finance & Accounts Module for salary payment based on
64.
attendance. Statutory and voluntary deductions
65. Ability to calculate arrears in case promotion is made with retrospective effect
66. Ability to update salary details on promotion, Succession Planning
67. Support for allowances, reimbursements, loans etc.
Ability to support encashment of Leave, Tours and travel and on retirement with
68.
consequent tax adjustments
69. Ability to release of festival advance and other advances (user defined) against salary
Ability to Employee-wise recovery position, recovery list and outstanding balances list -
70.
month-wise or as user defined
Ability for payment of medical reimbursement, allowances, recovery and taxation (if
71.
any) thereon
72. Ability to support Recovery of club/ union contributions
Ability for provision of Housing loan or any other loan component to be adjusted against
73.
the employee salary
74. Ability to support payment of educational allowance, transfer allowances and any other
Page 285 of 390

JPDCL

user defined allowances
Ability to support recovery of all other types of loans with reports like recoveries made,
75.
overdue list etc.
76. Ability to support calculation of incremental arrears with consequent tax adjustments
Ability to support payment of salary arrears as per the industry level settlements with
77. tax adjustments. Also support payment of arrears calculated in user defined instalments
or in lump sum Ability to define loans and its various characteristics such as p
78. Ability to attach loan sanctioning rules to every loan type
Ability to allow payroll to deduct the amount due from an employee (in case of
79.
loans/advances etc.)
H. Employee Taxation
Ability to Define tax rules to determine employees tax liability as per changes in
1.
statutory legislation for actual tax liability of employee
Ability to capture employee asset details such as various land holdings, investments in
2.
shares, any bank deposits and various sources of income
Ability to provide investment declaration form in electronic format. The employee will
3. be required to fill and submit the form electronically so as to automatically update salary
record and tax calculation by the system
Ability to ensure support for major statutory reports / certificates of taxes in the user
4.
defined format
I. Employee Deductions
Ability to establish deduction limits for each deduction based on various parameters
1.
like: Employee, Job Classification, Company, Benefit plan, Salary
Ability to make deductions effective: In the current period, in any pay period or periods
2. selected, in any user-defined frequency selected, between user-defined start and stop
dates, until a user defined limit is reached
Ability to have Start and stop dates for deductions should be maintained: On the
3.
Employee Master file, On employee level
Ability to reverse deduction to be included in next paycheck if incorrectly withheld /
4.
Option with user
Ability to determine deduction amounts by: Amount of earnings, Percent of earnings,
5.
Number of hours
Ability to prioritize deductions: Using the deduction code, Using a separate priority
6.
number
Ability to be prompted by system when employee status changes to leave to determine
7.
how deductions will be paid while on leave: take when return lump sum
8. Ability to apply or stop various deductions based on employee status changes
J. Pay Slip Run
Page 286 of 390

JPDCL

1. Ability to provide for online ad-hoc calculation of employees pay slip / salary amount
Ability to perform on-line calculation of pay and benefits for terminated employee based
2.
upon termination date
3. Ability to evaluate different scenarios for change in pay-roll structures
Ability to provide an impact analysis tool for analysis of impact of revision of any / all
4.
components like pay, allowances, deductions etc.
5. Ability to display the status of the payroll calculations
Ability to run Payroll multiple times before finalization to ensure accurate pay
6.
computation
Ability to post the amount of salary paid for each element of pay for an employee, based
7. on the relevant GL account code and employee cost center information to General
Ledger. Financial postings include, Element, Amount, GL Account, Cost Centre
Ability to Post salary payment advice including multiple payment methods such as bank,
8.
cash and Cheque to General Ledger
Ability to generate pay slip with following detail: Taxable and non- taxable components
9. in separate columns, Tax till date, Calculated, Recovered, Projected, Loan balances and
no. of instalments deducted / left, Provident fund opening balance, interest
K. PF & Terminal Benefit Management
Ability to support pooling the monthly contribution of PF into the online PF management
1.
system
Capable to handle terminal benefits (pension, gratuity, GPF, GSS, leave encashment)
2.
including roll of pensioners as per company’s policy.
Capability to handle superannuation and death benefit of employees as per company’s
3.
policy.
4. Allows differentiation of employees (e.g., PF not deductible based on eligibility criteria)
Ability to Support PF settlement process including generation of settlement sheets and
5.
relevant vouchers for accounting
Ability to support calculation of periodic interest and crediting the amount to the
6.
accounts
Ability to perform PF application processing, loan sanctioning, loan disbursement,
7. modification of loan instalments, loan short closure, recovery through payroll, final
settlement during closing/transfer for different type of PF loans (support linkage with
8. Ability to deduct loan instalments (& separately track deductions, loan balance etc.)
Ability to Generate all types of MIS reports as per request of Bank (like PF ledger, PF loan
9.
ledger, Pension rule, PF rule, Gratuity rule (online) etc.)
Ability to maintain nominee details and payment to nominee in case of death of an
10.
employee (Integrate with Employee Master)
Page 287 of 390

JPDCL

11. Ability to provide PF Returns and other statutory forms
12. System should generate all types of reports/registers related to PF management
13. Ability to allow multiple user-defined messages to be printed on Cheques
Ability to prepare statutory dues statement details & bank clearance month wise as per
14.
statutory scheme and remittance activity to the designated bank account
Ability to generate various information as to be required time to time by the statutory
15. authority relating to PF settlement, PF loan, trustee activity information, statutory
pension information and information as pertaining to contractual employees, etc.
Ability to process the statutory pension cases at the time of
16.
retirement/death/resignation/transfer
Ability to generate various information as required by the statutory authority from time
17. to time regarding awarding contract to the contractors with job details, payroll
information, compliance to statutory authority in respect of contractors' employees
L. Investment & Gratuity Management
Ability to perform gratuity calculation, provision & accounting employee- wise as per
1.
user defined rules
2. Ability to perform forfeiture of Gratuity in case of dismissals etc.
3. Ability to generate gratuity payment cheques
Ability to maintain nominee details and payment to nominee in case of death of an
4.
employee
Ability to generate all types of reports/registers related to Gratuity management
5.
Pension Management
Ability to intimate the employees three months before their retirement about their PF
6.
subscription, PF Loan, Gratuity and Pension claim forms etc.
7. Ability to maintain nominee details to facilitate pension processing
Ability to support pension disbursement and support multiple payment modes for
8.
pension
9. Ability to calculate family pension and payment
Ability to support all related accounting procedures including generation of vouchers
10.
and related reports
Ability to perform Income tax calculation and deduction for pension payment as per
11.
relevant department requirements
Ability to handle employees joining and going out on deputation / LIEN along with details
12. like: Leave salary contribution, Pension, PF etc., Economic rehabilitation with
nomination & other details
M. Payroll Reporting Requirements
1. Ability to generate reports on list of employees based on pay scales
Page 288 of 390

JPDCL

Ability to have provision for generating ad-hoc payroll reports & provision for generating
2.
user defined reports
Ability to generate reports on list of employees for whom system notified error in payroll
3.
run
Ability to produce reports on employee cost by employee/Organization unit/Job family,
4.
etc.
5. Ability to automate Transfer process
6. Ability to record Transfer Policy & Procedure
7. Ability to prepare Transfer list based on the user defined criteria
8. Ability to generate transfer orders
9. Ability to record the transfer orders cancelled, approved or deferred
Ability to request transfers by employees (subject to minimum eligibility criteria
10.
specified in transfer policy) and approve/reject transfer requests of employees
11. Ability to process NDC, obtain clearance from other Discom/sections and issue the same
Ability to generate lists of transfer requests/recommendations received to be reviewed
by the Competent Authority for deciding on transfers with/without promotions. The
12.
office may also transfer an employee without any request/recommendation as per the
Tran
Ability to integrate with list of workmen exempted from transfer for being medically
13.
incapacitated, being office bearers of recognized unions and association
14. Ability to integrate with compensation and benefit module
Ability to update new designation, change of cadre/class, salary details etc. in Transfer
15.
Database
Ability to maintain complete history of employee transfers since recruitment and
16.
Integrate with Employee Master, Promotion Module
N. Employee Reporting Requirements
1. Ability to generate reports on count of employees transferred in a specified period
2. Ability to generate reports on total pending, approved/rejected cases of transfer
Ability to generate reports on status of officers/staff whether released or not released
3. or whether joined/not joined (along with dates) as per transfers/promotion orders as
on particular date or cross section of time is available readily from this system
Ability to define rules for promotion eligibility in terms of tenure, seniority, residual
4.
service, performance, achievements, disciplinary actions, low medical category, etc.
Ability to enforce relaxations in eligibility norms to reserved category candidates,
5.
allocating certain percentage of vacancies for these categories
Ability to define grade advancements within a channel (seniority/merit/ranking list time
6.
based)
Page 289 of 390

JPDCL

Ability to carry out the entire promotion process through workflows including online
preparation/printing of Promotion Appraisal Forms/ Booklet recording of
7.
Recommending Authorities Comments/generation of scores/status regarding pending
vigilance cases
Ability to process cases suitable or unsuitable for promotion as well as pending cases if
8.
any based-on performance, in interview and other
9. Ability to generate single page bio-data report for each employee due for promotion
Ability to upload Promotion List and print Promotion Letters of candidates found
10.
suitable for promotion
11. Ability to issue order of promotion
12. Ability to arrive at the surplus and vacant positions
Ability to record request for transfer through employee self-service and indicate
13. appropriately at the time of transfer exercise. Record of such request wherever acceded
to be maintained
Ability to notify to Discom on their email addresses about the employees to be
14.
promoted
15. Ability to record interview ratings of employee short listed for promotion
16. Ability to handle Back Dated promotions with respect to Promotion Policy
17. Ability to approve promotion list by appropriate ordering/approving authority
18. Ability to enforce deferred dates of promotions under CPS due to punishment imposed
Ability to update new designation, change of cadre/class, salary details etc. in Promotion
19.
Database
20. Ability to generate Promotion Orders
21. Ability to record the promotion orders cancelled, approved or deferred
Ability to give input to Payroll Administrator to update salary details on promotion as
22.
per the Promotion Database
Ability to draw a competency matrix in the system and define the competencies /
23.
skills/roles/responsibilities required at each level/position for promotion
Ability to intimate the outcome of various stages of promotion (interview, first shortlist
24.
etc.) to the employees through ESS Module
25. Ability to redefine the promotion process on change of policy
Ability to record transfer option of an employee at the time of promotion and generate
26.
reports for the management for making transfers on promotion
Ability to maintain complete history of employee transfers since recruitment Reporting
27.
Requirements
Ability to generate a list of eligible candidates for promotion of different grades and
28.
streams in consideration of period spent under suspension, extra ordinary leave without
Page 290 of 390

JPDCL

pays etc.
29. Ability to generate list of pending cases with requirement of particulars
Ability to generate reports on status of officers/staff whether released or not released
30. or whether joined/not joined (along with dates) as per transfers/promotion orders as
on date or cross section of time is available readily from this system
Ability to generate seniority list of all officers and staff (with particulars like DoB, DoJ,
31.
Qualifications) on any date/time
Ability to provide reports on total employees promoted during specific period, category
32.
wise, unit wise, designation wise (all details)
Ability to provide reports on employees not selected for promotion or cases deferred or
33.
pending or dropped with reasons
O. Compensation & Benefits
1. Ability to maintain the compensation and benefits policies of the organization
2. Ability to perform Income Tax calculation
3. Ability to calculate compensation and benefit details (Pay Slip) of each employee
4. Ability to issue orders granting Band Pay
5. Ability to issue orders granting annual increments
6. Ability to approve loans and advances of employees (by appropriate authority)
7. Ability to Check Loan Balances
Ability to handle making online application for sanction of LTC/HTC/other entitlements
8.
through ESS and approval through workflow
9. Ability to process application for medical advance, HTC/LTC reimbursements
10. Ability to approve general claims and expenses through the system
Ability to track loan requests made by employees and send reminders, Feedback &
11.
Grievances
Ability to track and record all compensation payment made towards accident-related
12.
cases under Workmen Compensation Act of 1923
Ability to show details on all aspects, place of accident (office), cause, report on how the
13. accident happened, witnesses, name of investigation officer, and other officers involved
in the process at the field, investigation details and determination of co
P. Appraisal-Compensation Reporting Requirements
1. Ability to Integrate with the EPM - Employee Performance Monitoring portal.
2. Ability to provide report on expense requests approved/claimed/rejected/paid
Ability to provide report on month-wise/year-wise accident compensation sanctioned,
3.
and all details related to it
4. Ability to provide report on month-wise insurance premium payment receipt
Page 291 of 390

JPDCL

5. Ability to generate marks on attendance
Ability to capture Performance Appraisal Policy and customize process to update/edit
6.
the policy
7. Ability to define the structure of appraisal process
8. Ability to define the various stakeholders in Performance Appraisal process
9. Ability to define Performance Rating Scale
10. Ability to define the performance appraisal form
Ability to notify/send reminders controlling officer, Performance Appraisal coordinating
11.
officer & Director (HR&A) on process deadlines
12. Ability to initiate target setting by employee
13. Ability to approve target setting by employee's senior officer
14. Ability to initiate midyear appraisal by employees and record any changes in Targets
Ability to review mid-year performance of employees by employee's senior and record
15.
his feedback and performance ratings
Ability to review year-end performance of employees by employee's senior and record
16.
his feedback and performance ratings
Ability to compute annual performance ratings of employees automatically based on
17.
mid-year and year-end performance ratings
Ability to review completion of target setting, mid-year review and year- end review by
18.
Performance Appraisal Coordinating Officer
19. Ability to define self-assessment form
20. Ability to fill Training Needs in the appraisal form by employees
21. Ability to approve Training Needs of employees
Ability to provide input to other Personnel Decisions such as Promotion Module,
22.
Succession Planning Module, T&D Module, Performance Linked Incentive, Job Rotations
Ability to capture Performance Appraisal Guidelines (Employee's guide and Evaluator's
23.
guide)
Design Performance Appraisal database to capture annual performance ratings of
24.
employees of all classes
Ability to record annual performance ratings of employees in Performance Appraisal
25.
Database
26. Ability to maintain appraisal records and ratings of employees for all appraisal years
Ability to route the Appraisal form / Evaluation sheet through the respective levels for
27.
each of the employees
28. Ability to group employees based on categories of performance appraisal ratings
29. Ability to generate memo letters / mails /SMS workflows for the employee in case of
Page 292 of 390

JPDCL

unsatisfactory performance
Ability to scan appraisal documents manually filled by employees (on field etc.)
30.
Reporting Requirements
31. Ability to generate report on employee ratings in the last three years
Ability to provide reports on count/list of total employees completing the target setting,
32.
mid-year and year-end appraisal
Ability to provide reports on count/list of total employees for whom target setting, mid-
33.
year review and year-end review has been completed/pending
Ability to provide reports on count/list of employees based on categories of
34.
performance appraisal ratings
Ability to generate reports for vigilance clearance and detailed status of vigilance
35.
proceedings as well as submission of declaration of assets
36. Ability of generate performance reports and detailed status
Q. Succession Planning
1. Ability to automate the process of Succession Planning
2. Ability to capture SP Policy and process to update/edit the policy
Ability to record and maintain various career options/paths available to employees in
3.
the organization
4. Ability to define Vacancy and Talent Database
Ability to identify key positions (employees who are retiring in a span of next 3 years) to
5.
formulate the vacancy list
Ability to define the eligibility criteria (Age, Performance Appraisal Rating, Attendance
6.
Records, Vigilance Records) for employees to be included in Talent Database
Ability to define the list of employees eligible for the Talent Assessment Process and
7. capture their professional experience details, age, Discom, location, past Appraisal
rating of 10 years
8. Ability to provide list of employees short listed for Talent Evaluation Process
9. Ability to update Interview Assessment Sheet Format including the rating scale
10. Ability to update list of Interviewing Authority for each function
Ability to inform short listed employees and Interviewing authority for Due date, time
11.
and venue for conducting interviews of short-listed employees
12. Ability to update list of questions for interview
Ability to update interview ratings of employees in Talent Assessment Database under
13.
Evaluation Criteria
Ability to update list of top 3 successors for each position in Vacancy and Talent
14.
Database
15. Ability to define Individual Development Plan (IDP) Database
Page 293 of 390

JPDCL

16. Ability to update list of Successors of last years
17. Ability to notify administrator to update successor details after deployment
18. Ability to record history of succession planning process of all years
R. Succession Planning Reporting Requirements
1. Ability to provide reports on list of employees due for retirement in a span of 3 years
2. Ability to provide reports on number and details of Vacancies
3. Ability to provide reports of employees eligible/rejected for Talent Assessment Process
Ability to provide reports of employees short listed/rejected for Talent Evaluation
4.
Process
5. Ability to provide reports of top 3 successors for each position
6. Ability to provide reports on employees undergoing/completed IDP
7. Ability to provide reports on assessment rating of interviewed employees
Ability to provide reports on employees participated/selected/rejected in succession
8.
planning process
S. Manpower Planning
Capability to automate manpower requirement/planning based on competencies, skills,
1.
experience, qualification and other criteria
Capability to make provisions for direct employment/ promotion/ recruitment to
2.
specialist categories/part time or contractual employees
Capability to project cadre-wise/grade-wise manpower requirements for a specified
3. period based on data relating to new upcoming units/resignations/dismissals/future
retirement etc.
Capability to analyze the unit-wise, cadre-wise, grade-wise resources available and
4.
required and do a gap analysis with specific time frame
5. Facility to create new posts or modify existing posts through appropriate approval
Capability to issue alerts before any position falling vacant due to retirement/term of
6.
temporary or contractual employee getting over
Capability to generate a consolidated manpower plan (Discom wise/Section- wise/Unit
7.
wise) for approval through work-flow management system
8. Capability to identify critical posts (by function)
Capability to integrate with the recruitment/promotion module for filling up of
9.
vacancies
Recruitment facility to include the entire process of recruitment in the system including
10.
the budget involved in it. It may also include other new areas
Facility to define positions for internal or external recruitment (define vacancies based
11. on sanctioned strength and existing employee strength for each Discom /unit/section
etc.)
Page 294 of 390

JPDCL

12. Facility to define the requirements for recruitment of deceased dependents
13. Facility to record the details of the applicants of deceased dependents
Facility to furnish the list of applicants of deceased dependents found eligible for being
14.
called for interview/selection
Facility to carry out recruitment for different grade/rank of employees and Part time
15.
employees
Facility to record the time taken to assess the financial condition of the deceased
16.
dependent applicants and accordingly take decisions on the eligibility of the application
17. Support vacancy and post based roster system for recruitment
Facility to define the specifications of the vacancy in terms of qualifications, work
18. experience, location considerations, skills/competencies required, additional
certifications / professional qualifications, etc.
Facility to derive competencies automatically from the job or position competency
19.
requirements into vacancy competency requirements
20. Facility for managing recruitment for special categories requiring relaxation in norms
21. Facility to draw recruitment schedule in accordance with the requirement plan
Facility to indicate that an applicant has applied for the post through another hiring
22.
process within the organization
Facility for generating advertisement for recruitment for internal / external candidates
23.
for publication on HRMS portal, Media and websites
24. Support provision for approval of advertisement from Competent Authority
25. Ability to import resumes from external job sites into the resume database
Facility to receive on-line responses Corrigendum 1 Clarification: Yes, recruiting in
26. special conditions is part of scope of RFP and estimate of annual intake and no. of
candidate cannot be envisaged at this point.
Facility to attach documents / credentials in soft form as a part of the application or at
27.
any other time as decided by the institution
28. Facility to auto generate unique identity number for each new applicant
29. Facility to create workflow for approval of application through various levels
Facility to capture details of the Recruitment Policy and to alert users if there is any
30.
violation of the policy
Facility to route recruitments through various levels of approvals and review. Audit trails
31.
of the entire approval process should be available
Facility to report generation for all the above functionalities with a provision for dynamic
32.
querying
33. Ability to re-induct a person into the organization after a gap in service
T. Staff Selection
Page 295 of 390

JPDCL

1. Facility to design tests to be conducted in written or online modes
Facility for generation of call letters for written test/interview with allocation of Roll
2. numbers (same as unique identity numbers allocated during recruitment phase) and
venue. Should support manual intervention in changing venue/center subsequently.
Facility to create a competency framework (matrix) for various competency types
3. (functional/ behavioral/ leadership) with desired proficiency levels for each
position/grade
Facility to create various competencies and categories into various competency types
4.
viz. Ability, Skill, Knowledge, etc.
Facility to maintain various types of tests and maintain a question/answer database of
5. each type of test (functional, psychometric, analytical etc.) to be administered as part of
the selection process
6. Facility to define the evaluation criteria and generation of results post- evaluation
7. Ability to track interview results / Applicant's progression
Generation of merit list of candidates on user configurable criteria such as category-
8.
wise, center-wise, alphabetically, roll no.-wise, score wise etc.
9. Ability to record payments made to the panel members/invigilators/candidates etc.
10. Capability to maintain details of the candidates resorting to unfair means
11. Provision to record comments of interviewers at various levels of interviews, Hiring
Generation of system driven regret letters and/or offer / appointment letters through
12.
both manual as well as electronic modes (with terms and conditions for appointment)
13. Ability to issue orders of appointment on contract basis
Ability to issue orders of re-engagement (or extension) of retired officers, on contract
14.
basis with re-employment terms
15. Ability to issue order on completion of probation period
Facility to maintain checklist for verification and acknowledgement of various aspects
16.
related to joining viz., medical reports, testimonials, other relevant certificates, etc.
Should allow for maintaining a checklist of details to be mentioned in each employee's
17.
personnel file
U. Staff Confirmation
Facility to change employment status from probation to confirmed/not confirmed after
1.
one year from the date of joining
Facility to integrate with the PAR (Performance Appraisal Report) of the employee on
2.
probation
Facility to attach scanned copy of the vigilance clearance certificate after one year of the
3.
employee's joining
4. Facility to attach service continuity certificate for checking unauthorized attendance of
Page 296 of 390

JPDCL

the employee on probation
Facility to attach scanned copy of the police verification certificate and medical fitness
5.
certificate of the employee hired on probation
V. Reporting Requirements for Staffing
Facility to generate reports on Recruitment cost incurred/employee and cost per
1.
recruitment agency per project
2. Facility to generate report on the time taken by each agency to recruit for a position
Facility to generate reports on Time taken for filling up a vacancy i.e., from paper
3.
advertisement to appointment letter
Facility to generate reports on the time taken for deceased dependent recruitment (i.e.,
4.
from receiving application till appointment)
5. Facility to generate reports on No. of days taken to respond to an applicant
6. Facility to generate reports on year-wise manpower profile of Discom
Facility to generate reports on total manpower strength (Category- wise, designation-
7.
wise in different corporate and field offices of Discom (for each quarter)
8. Facility to generate reports on Education and Age profile employees
9. Facility to generate reports on the details of contractual employees in Discom
Facility to generate reports on the Recruitment, appointment and confirmation details
10.
for each quarter
11. Facility to generate reports on the Superannuation details
12. Facility to generate reports on the Separation details (category wise)
W. Grievance Redressal
1. Facility to store and update Grievance Redressal Policies & Procedures
2. Facility to edit the policies by specified level of authorities
3. Facility to define composition of the GR committees
4. Facility to list various techniques to facilitate communication
5. Facility to store various GR forms for printing
Facility to maintain checklist of the documents that employees need to submit as part
6.
of the procedures
7. Facility to draw schedule for GR meetings
8. Facility to design surveys
9. Facility to alert the users periodically when a deadline is approaching nearer
10. Facility to track/monitor the status of a pending case
Facility to issue ID number for different classes of employees separately Reporting
11.
Requirements for Grievance Redressal
12. Number of court cases filed at labor court & high court, industrial tribunal & other
Page 297 of 390

JPDCL

competent authority
13. Number of grievances disposed per year
Facility to generate reports on the total number of complaints docketed for a specified
14.
period
Facility to generate reports on the total number of grievances handled during a specified
15.
period
Facility to generate reports on the various types of grievances handled during a specified
16.
period
17. Facility to generate reports on the average time taken to resolve a grievance Legal
Facility to maintain database of empaneled lawyers and arbitrators and their fee ‘s
18.
structure
19. Facility to maintain and update all engagement orders, hearing and outcomes
20. Facility to maintain lawyers ‘communications along with gist of the orders
21. Facility to maintain compliance of the orders of different courts
Facility to maintain record of category of court cases at high court such writ, civil
22.
revisions, appeal, contempt of court etc.
23. Facility to maintain details of appeals filed by the company against different orders
Facility to maintain all relevant database for all courts, tribunals, Compensation court,
24.
gratuity tribunal including appellate forums
25. Facility to maintain database regarding arbitration
Facility to maintain database regarding conference with different legal
26.
professionals/bodies/associations
27. Facility to maintain legal opinions given by different legal professionals/legal cell
Facility to maintain database regarding cases for out of court settlement through
28.
empowered committee
Facility to check/monitor status of all pending cases including cases on service matters
29.
related to employees and contract/ outsourced laborers
30. Facility to maintain checklists for defending any case filed against the company
Facility to record bills of the advocates and compare that with their charge rates and
31.
appearance dates
Facility to maintain checklists of the supporting documents that an advocate needs to
32.
submit while raising bills
Facility to alert users if advocate bills are stored into the system without all supporting
33.
documents
Facility to generate reports on total number of awareness programs conducted on legal
34.
issues during a specified period
35. Facility to generate reports on the total amount of pay out on litigation cases during a
Page 298 of 390

JPDCL

specified period
36. Facility to incorporate the outputs of Litigation Management System (LMS)
37. Facility to generate report on review of court cases at the site offices.
Facility to generate reports on the total number of legal cases filed against the company
38. by employees (per year) against disciplinary actions /non- settlement of terminal
dues/other issues
39. Facility to appeal against the punishment/disciplinary action taken against employee
Facility to generate reports on the total number of legal cases filed against the company
40.
by others during a specified period
Facility to generate reports on the total number of employee court cases decided in
41.
favor of the company
Facility to generate reports of pending cases allotted to particular advocates by any
42.
office
Facility to generate reports of pending cases according to involvement of outstanding
43.
dues
44. Facility to generate reports of pending cases according to date/month of filing the cases
Facility to generate reports on amount of revenue allowed by court in favor of company
45.
after disposal of cases
46. Facility to generate reports advocate wise and office wise legal expenditure
47. Facility to generate reports on amount realized through out of court settlement
X. Travel Management
1. Ability to automate the process of Travel Request
2. Ability to define Travel Request (Rail/Air/Road/) Forms
3. Ability to define & select calendar and time schedules for travel planning
4. Ability to define Country/state/city for travel planning
5. Ability to select type of Travel (Local/Domestic/International Travel)
6. Ability to select mode of travel (Rail/Air/Road)
7. Ability to recommend Train Name & Number, Flight Number / Name of Carrier
8. Ability to add number, name, age, Discom, function of travelers
9. Ability to raise Travel Requisition for Local/Domestic/International Travel
10. Ability to select the cost center while raising travel requests
Ability to define approving authority and reviewing authority for
11.
checking/approving/declining travel requests
12. Ability to select approving and reviewing authority for approval of travel requests
Ability to provide any additional comments before submitting the travel request (lowest
13.
fare/berth preference)
Page 299 of 390

JPDCL

14. Ability to approve/decline/modify travel request of employees by approving authority
15. Ability to check status of approval/decline of travel requests
16. Ability to resubmit travel requests if declined
17. Ability to notify Travel Desk of approved travel requests submitted
Ability to raise request for cancellation of travel tickets or booking of Taxis for
18.
Local/Domestic Travel
19. Ability to create request for booking of taxis for Local/domestic Travel
20. Ability to approve/cancel/modify requests for taxi bookings
21. Ability to create, change, display, review and release travel advances
Generation of reminder letters if tours and travels final bill is not submitted by employee
22.
within the prescribed time
23. Ability to provide expenditure reports for separate cost centers
Ability to provide reports on employees for whom travel request has been
24.
approved/declines/modified
Ability to provide reports on all past travel requests with details on travel advance
25.
cleared/per-diem/allowances claimed and actually paid
Ability to raise request for expenses such as medical reimbursement/travel
26.
reimbursement/stationery/local conveyance etc.
Y. Employee Welfare & CSR
Ability to maintain the history of employee welfare and CSR initiatives undertaken over
1.
time, separately
2. Ability to calculate the amount spent on employee welfare and CSR initiatives separately
Ability to provide separate reports on the total number of employee welfare and CSR
3. initiatives undertaken within a specified time with amount spent on each Performance
Linked Incentive (PLI) Scheme
4. Ability to automate the revised PLI scheme for Discom
5. Ability to capture the time to revisions/edit any changes in the PLI scheme
Ability to take input from the corporate and Discom scorecards to update data such as
6.
target setting etc. for computing the PLI for Discom
Ability to calculate the amount disbursable for PLI for all employees in each Discom and
7.
unit of Discom
Ability to calculate and maintain the history of PLIs earned by each employee in a year
8.
(integrate with PMAS and Payroll modules)
9. Ability to make comparisons of year wise PLIs earned by functions/ Discom
Ability to provide reports on the total amount disbursed as PLIs in each year, Discom
10.
level as well as employee wise
Page 300 of 390

JPDCL
Page 301 of 390

JPDCL
Inventory and Stock (Material Management)

A. Material Records Management (Material Master)
Ability to record and maintain item master list with availability of material number/
1. code/ part code as primary identifier for various material types including spares and
consumables
Ability to generate material code automatically for item entry to item master as well as
2.
support manual entry
3. Ability to support alphanumeric material codes & HSN codes
Ability to capture detailed material information including the categories of data to
support core material management transactions like goods receipt, goods issue etc.
• Basic data like Material No, Item Description, UoM, Status, Origin, type,
conversion factors, ownership details etc.
4. • Inventory management data i.e., material history, ABC classification, inventory
location, safety stock, Re-Order Level (ROL) etc.
• Purchasing data i.e., purchase rule, tax/duties rule, ordering batch size etc.
• Cost data i.e., standard price, moving average price, weighted average price etc.
• Criticality
Ability to support item groups or categorization of material into material groups, type
5.
and location etc.
6. Ability to create BOM
7. Ability to integrate BOM with proposed expansion/extension
Ability to support approval workflow and automatically trigger material data
8.
authorization upon material data entry
9. Ability to modify material details and resubmit for approval
10. Ability to track material authorization status pre and post approval
Ability to track changes made to material record with details of changes made, changing
11.
entity and approver of changes
12. Ability to reject material record and update material record status with reasons
Ability to record whether material is moving or non-moving or obsolete and delete a
13.
material record which is non-moving or obsolete.
14. Ability to link material to vendor / supplier details
Availability of search functionality based on material numbers, wild card entries, partial
15.
item description, shelf life, warranty period, specifications, etc.
Ability to display partial or full material master information to users across functional
16. areas and restrict display of all information based on user roles/display authorization
levels
17. Ability to support multiple Units of Measure (UoM) for an item
18. Ability to create catalogues for different material types, spares and miscellaneous items
Page 302 of 390

JPDCL

19. Ability to capture details regarding insurance of the materials
20. Ability to generate detailed item wise report of material information
21. Ability to generate report on revaluation of materials and display valuation history
Ability to generate report on material performance e.g., material history report, material
22.
blacklist report, damage during warranty period
Ability to generate material reports for separate material type, material group, location,
23.
consumption history etc.
B. Manage Inventory
Ability to record multiple physical store locations, capturing individual store physical
1.
description details
Ability to support multiple inventory status for individual items including the following:
• Under testing
• Available for Issue vis-à-vis Order Position
• Scrapped
• Obsolete
2. • In Transfer
• Blocked
• Restricted Use
• Under Repair
• Special Project Stock
• Reserved Stock
Ability to track material movement for each store including:
• Issues
• Inter Store Transfers
• Transfer to Obsolete Stock
3.
• Consignment movements
• Quarantines Stock
• Returns
• Under Repair
Ability to track and monitor stock at various store locations like, Central Stores, Area
4.
Stores, Sub-station Stores, at individual store level and at aggregate level
Ability to plan for inventory based on consumption pattern, present stock, procurement
5.
lead times, projected requirements etc.
Ability to analyze inventory in terms of 'items reached re-order/ safety level' and 'critical'
6. items and generate appropriate alerts when inventory reaches predefined re- order
points
Ability to store shelf-life details for items and display alerts when items reach end of life
7.
(user defined) and remains un-used.
8. Ability to store material movement history in each store and for each item e.g., fast, slow
Page 303 of 390

JPDCL

moving and non-moving.
Ability to Block Materials for posting. Due to delay between material movement and the
9. posting of that movement, there is a short-term discrepancy between actual warehouse
stock and book inventory. To avoid such discrepancy during physical inventory, it is
Ability to classify inventory under bulk material, finished goods, capital items, job work
10.
and disposables
Ability to assign a service level to an inventory item e.g., 100% for critical items and this
11.
will be linked to re-order levels
Ability to schedule stocktaking as per predefined business rules e.g. A Level Items will
12.
be counted once every month and freeze inventory for stocktaking
Ability to support in stock replenishment for all stock items based on parameters like re-
13. order point, safety stock level, consumptions patterns etc. The system should estimate
ordering quantity and delivering schedule which can be converted automatically
Ability to trigger stock replenishment for all stock items on the basis of various
14.
parameters like reorder level, safety stock level, material consumption
Ability to estimate suggested ordering quantity and delivering schedule for individual
15.
items for stock replenishment
Ability to generate purchase requisitions based on re-orders automatically for items
16.
based on predefined system configurations
Ability to support inventory valuation methods like FIFO/ LIFO/ Weighted Average,
17.
Standard Cost, etc.
Ability to revalue inventory, with tracking to revert back / to get original value, if
18.
required. This is to facilitate credit refund to Govt at current rate on original value.
19. Ability to estimate total inventory carrying cost based on inventory valuation method
Ability to generate item wise stock status reports on current inventory status based on
20.
goods receipt, goods issue and stock balances on a daily/weekly basis
Ability to generate consolidated inventory report on receipts, issues, stock adjustments,
21.
scrap inventory, goods returned to suppliers, etc.
Ability to consolidate and generate report on item wise total inventory levels for all
22.
stores
23. Ability to generate stock-out reports
Ability to generate report on inventory analysis e.g., material consumption pattern
24.
across stores
Ability to generate report on availability of inventory during requisitioned and actual
25.
service level for items
26. Ability to generate report on age analysis and shelf-life evaluation
27. Ability to generate report on un-used materials procured for a specific purpose
C. Goods Receipt
Page 304 of 390

JPDCL

Ability to record receipt of inventory items received from vendors/suppliers and
1. generate Stores Receipt Voucher (SRV) including record of place/ location of receipt and
goods details (unit, weight, specifications etc.)
2. Ability to roll back/ update the SRV in case the data is wrongly entered
Ability to record receipt of commercial documents received with goods like excise
3.
invoice duplicate for transport copy along with goods
Ability to record receipt of technical documents like quality certification report received
4.
along with goods.
Availability of control functionality for goods receipt i.e., receiving in excess/shortfall of
5. Purchase Order (PO) quantity, quantity tolerance functionality or PO revision
functionality
Ability to support quality inspection after goods receipt and before delivery of goods to
6. inventory and generate quality inspection report and record the inspection results for
the goods as per Purchase order
Availability of workflow-based inspection notification to quality control on receipt on
7. parts at store and return notification to store on completion of inspection for posting the
item to inventory.
Ability to support three-way matching of Stores Receipt Voucher (SRV) with Purchase
8.
Order (PO), Quality Inspection Report (QC) and Dispatch Instruction Report
9. Ability to club multiple lorry receipts (LRs) / consignments into single SRV
Ability to record partial delivery of items and track different lots of supply from suppliers
10.
for the same PO
11. Ability to automatically trigger evaluation of goods receipt and initiate payment process
Ability to raise bill for payment with workflow-based approval hierarchy for evaluation of
12.
payment
13. Ability to record receipt of goods and track inter store transfers
Ability to receive goods without P.O. or without proper documents and subsequent
14.
adjustment/ regularization
Ability to display updated inventory status after goods receipt for individual items, item
15.
groups and across stores
16. Ability to receive advance shipment notice and attach scanned documents
Ability to record receipt of inventory items purchased at different levels of hierarchy like
17.
Head Office Purchase and Area Office Purchase
Ability to generate intimation notice to purchasing authority in case of return of rejected
18.
goods
Ability to generate report on all SRV created over a period i.e., weekly\monthly for a
19.
storage location
20. Ability to generate inventory status report based on goods received over time, opening
Page 305 of 390

JPDCL

balance, goods issued, closing i.e., daily, weekly and monthly status report.
21. Ability to generate report for all SRV and bill payments against individual PO
Ability to generate exceptions during Goods Receipt including rejected quantity, items
22.
not as per P.O etc.
23. Ability to generate report on bills raised against SRV over a periodic basis in a store
Ability to generate list of items with guarantee clauses, in particular guarantee period
24.
along with Delivery Instruction (DI) date
25. Ability to send alert to the vendor as per delivery schedule
D. Goods Issue
Ability to create material issue request/ store requisition (SR) for material including
spares and miscellaneous items. The requisition record should have a reservation
1.
number, date of reservation, requestor name, stock location, material part number,
quantity, etc.
Ability to generate SR number manually and automatically based on maintenance work
2.
orders, capital works project requirements estimated in system
Availability of control functionality for goods issue i.e., issuing in excess/shortfall of SR
3.
quantity, quantity tolerance functionality or SR revision functionality
4. Ability to modify material issue requests/SR based on approver update
5. Ability to track changes made to SRs and display reservation history
Ability to delete SRs automatically based on cancellations in work orders, capital works
6.
project etc. and record reasons for cancellation
7. Availability of configurable approval workflow for SR approval
8. Ability to display material issue requests awaiting approval
9. Availability of material control functionality to check against SR
10. Ability to display available inventory and approval status for issue of goods
11. Ability to display availability of issuing material in each store before goods issue
12. Ability to issue goods and generate goods issue slip
Ability to support and create pick lists for those items awaiting issue to a capital works
13.
project, plant maintenance job, customer job, transfer request or over the counter issue
14. Ability to configure the information details in the pick lists based on item details
Ability to display updated store inventory status based on goods issued and available
15.
inventory at the store
Ability to consolidate pick lists for items to be supplied to the same destination, user, or
16.
job
Ability to track that the pick list has been picked packed and issued and display the status
17.
of the pick list e.g., being picked, being packed, issued etc.
Page 306 of 390

JPDCL

Ability to capture delivery information within the system e.g., transportation type,
18.
carrier details, dimensions, weight etc.
19. Ability to generate Gate Pass for material movement based on Goods Issue note
20. Ability to capture a single gate pass for multiple SRs to the same requisition
Ability to modify goods issue information details e.g., quantity, material number if
21.
required and track modification history
Availability of dual unit of measure i.e., UoM for storage e.g., units and UoM for issue
22. e.g., kg and a defined relation between them leading to unable to issue exact quantity
as requested in issue slip.
Ability to record issue of goods without reference document or store requisition e.g.,
23.
goods issue for scrap
Ability to generate record on goods issued against approved SRs item wise and generate
24.
exceptions on a periodic basis
Ability to generate report on the goods issued per store over a configurable periodic
25.
basis i.e., weekly/ monthly
Ability to generate report on aggregated goods issued for a particular item over a
26.
periodic basis i.e., weekly/ monthly
Ability to generate stock overview report showing goods received, goods issued and
27.
inventory status for all items in a store
Ability to generate stock consumption statistics based on goods issue for the items over
28.
time
E. Inter Store Transfer
1. Ability to support physical movement of stock between stores i.e., inter-store transfers
Ability to record order for inter-store transfer by pre-configured authorized entity in the
2.
system
Ability to generate material issue request/store indent form/ store transfer note (STN)
3. based on order for inter-store transfer from the material requesting store to the material
issuing store
4. Availability of configurable approval workflow for STN approval for inter-store transfer
5. Ability to modify STN based on approver update
6. Ability to issue goods and generate Goods Issue Note for inter-store transfer
7. Ability to post material transfer and update inventory status of issuing store
Ability to generate Delivery Challan and Gate Pass based on Goods Issue note for inter-
8.
store transfer
Ability to record receipt of goods at receiving store and generate Store Receipt Note
9.
(SRN)
10. Ability to display updated inventory status after goods receipt in receiving store
Page 307 of 390

JPDCL

Availability of material control functionality to check goods issued from issuing store with
11.
goods received in receiving store and post transfer of goods
Ability to capture the Rate Contracts for Inter Store Transfer and rationalize the
12.
transportation linkage to Finance Module
13. Ability to generate report on item wise inter-store transfer consolidated across stores
Ability to generate report on all items received and issued for inter- store transfer for a
14.
storage location on a periodic basis
Ability to generate exceptions and item quantity mismatches arising out of inter-store
15.
transfer
Ability to report on trends of regular item shortages in a store resulting in inter-store
16.
transfers
F. Store Return
Ability to record and support workflow for return of un-used or excess material from
1.
field/substation to stores
2. Ability to record and segregate dismantled material into scrap and healthy category
3. Ability to generate Store Return Note on goods to be returned from field
Ability to record receipt of goods at receiving store, generate Goods Receipt note and
4.
track its SR when goods are returned to store
5. Ability to update the Store Return Note in the store base on prior approvals
6. Ability to display updated inventory status after goods receipt in receiving store
Ability to generate accounting adjustments on a consolidated basis at Area Office level
7.
for all the Store Return Notes generated for that period
Ability to generate report on materials returned to a store over a periodic basis e.g.,
8.
weekly, bi-weekly
Ability to generate summary report of Store Return Notes generated by the system over
9. a periodic basis or location wise scrap/obsolete items (as declared by appropriate
authority) returned to the store from the field operations of the Discom.
G. Material Disposal
1. Ability to compile periodic report of scrap goods returned to the stores
Availability of configurable approval workflow for scrap approval and capture the
2.
recommendation of the scrap disposal committee
3. Ability to display scrap requests awaiting approval
Ability to generate alert to initiate material disposal workflow with the scrap goods
4.
report completion as the trigger
Ability to generate material list for auction/sale by Stores based on material disposal
5.
report
6. Ability to record auction/ sale result for scrap disposal including buyer information and
Page 308 of 390

JPDCL

material disposal details
Availability of workflow to support configurable payment norms for scrap disposal and
7.
generate goods issue based on buyer compliance to payment norms
Ability to generate Goods Disposal note (GDN) after checking against payment
8.
information
Ability to generate accounting adjustments on a consolidated basis at Area Office level
9.
for all the disposals generated for that period
Ability to generate report on scrap items available in a storage location over a periodic
10.
basis e.g., weekly, bi-weekly etc.
Ability to generate exception report for goods disposal process i.e., goods which are not
11.
being disposed on time, auctions not held as planned
12. Ability to generate report on auction results and record auction sale information
Ability to consolidate Goods Disposal note and generate completion report of sale based
13.
on goods disposed and payment terms
14. Ability to block sold goods till actual dispatch.
H. Physical Inventory Verification
Ability to support periodic physical stock verification process and update inventory
15.
status in system based on stock verification
16. Ability to schedule physical stock verification in the system
17. Ability to freeze inventory in the system for physical stock verification
18. Ability to generate item master list for physical stock verification
Ability to generate stock count sheets having detail information like Item No, Item
19. description, Stock Location, Units of Measurement, etc. to capture results of stock
verification
Ability to record the results of stock count in the system and record stock verification
20.
details
Ability to analyze stock count i.e., compare system stored inventory with physical count
21.
and generate exception report
Ability to record recount of the stock items which are at variance in the system prior to
22.
correcting system values
Ability to record possible reason for variance in the system and record root-cause
23.
analysis
Ability to support approval workflow for stock count results and variance, and support
24. authorization hierarchy based on value of discrepancy, type of items etc. for approval of
variances
Ability to update and modify inventory status, material master information based on
25.
physical stock verification
Page 309 of 390

JPDCL

26. Ability to generate stock verification report with quantity and value information
27. Ability to generate report on discrepancy for inventory items counted
28. Ability to generate trend for variance items
29. Ability to generate exception report for those items not counted in a storage location
Page 310 of 390

JPDCL
Purchasing / Contract Management

A. Vendor Records Management
Availability of centralized vendor master records facilitating single vendor description
1.
and code across the organization
Ability to record vendor details including alternate / short name for vendor, contact
2.
person, vendor address, vendors bank account information
3. Ability to classify vendors into MSME, Start-up, Large etc.
Ability to record TDS details, PAN number and Tax details required for ensuring
4. compliance with Indian Tax laws considering both direct& Indirect taxes, Default
currency for invoice/payment
Ability to record vendor specific information relating to an item/vendor relationship. The
details should include vendor name, address, payment terms, price & quantity, free form
5.
comments, delivery information, item no. & description, discounts, vendor
performance, etc.
6. Ability to support multiple addresses against each vendor
7. Ability to support automatic vendor numbering
8. Ability to define different vendor types e.g., domestic vendors, international vendors
Ability to maintain vendor list details e.g., company history, saleable model, shipment,
9.
payment method
10. Ability to maintain vendor lists for OEM vendors and trade vendors
Ability to modify vendor records e.g., bank account information and support
11.
authorization of changes made
Ability to support vendor classification (multiple parameters required to meet reporting,
12. preferential treatment like waiver of EMD etc. payment prioritization and other needs)
e.g., stationary suppliers, electrical suppliers, service suppliers etc.
Ability to classify vendors with regards to: supplier, Contractor, sub- Contractor,
13. transporter, approved/ registered, blacklisted/active/not active, dormant, under trial,
etc.
Ability to support all kinds of sub-contracting activities like goods issue, goods receipt
14.
etc.
15. Ability to display vendors based on vendor grouping/ classification
Ability to block vendors from being used due to a specific reason e.g., vendor bankruptcy,
16.
vendor reliability with effective date, with facilities to re- activate
Ability to record vendor transactions history including purchasing history, payment
17.
history etc.
Ability to record evaluation of vendor credentials to qualify vendors as preferred vendors
18.
for specific items
Page 311 of 390

JPDCL

Ability to generate vendor registration certificate indicating eligible item groups online.
19.
Vendor details will be entered manually by Discom officials.
20. Ability to restrict creation of purchase orders for items only for its preferred vendors
Ability to verify existence of vendor rate contracts at indenting stage and display alerts
21.
for sourcing
Ability to evaluate vendors based on multiple parameters like quality of material,
22. quantity of material and adherence to delivery schedule, prices quoted by the vendor,
vendor response time and other user defined parameters
Availability of vendor rating system based on configurable user defined weightages on
23. multiple parameters (in accordance with Vendor Rating Policy adopted by Discom and
subsequent amendment thereof)
24. Ability to restrict maintenance / access to vendor master record to specific users
25. Ability to allow vendor ‘s request for addition of new items
26. Ability to generate periodic report on vendor alterations to vendor master
Ability to merge / correlate vendor details (e.g., one vendor taking over another vendor).
27.
Enabling tracking change of status from a date
28. Ability to display period-to-date, quarter-to-date, year-to-date vendor balances
29. Ability to block payments to vendors
30. Ability to integrate with finance functions e.g., accounts payable, general ledger
Ability to track vendor/ supplier performance against pre-defined parameters set by
31.
Discom or regulator
Ability to support different business rules and policies for each Vendor class/ category/
32.
type
33. Ability to generate periodic report on vendor alterations to vendor master
34. Ability to generate vendor account statement to be sent to the vendors
Ability to generate report on individual vendor performance and produce vendor
35. delivery report on instances of rejected materials, missed delivery, incorrect location,
incomplete delivery, returns due to damage, over supply etc., average no. of delay, etc.
Ability to generate Vendor analysis reports for spend analysis, performance in terms of
36.
on time in-full delivery, rejections, etc.
Ability to generate reports by outstanding orders, orders shipped but not received,
37.
overdue outstanding orders, orders not fulfilled on time etc.
Ability to generate report on goods returned to vendor that shows the items returned to
38. supplier by Location, Vendor, PO, Category, Product Code, Reasons for return, Value of
Goods return etc.
Ability to generate timeline-based communication history with the vendor regarding
39.
various services like delivery, payment, field service, etc.
Page 312 of 390

JPDCL

Ability to generate vendor ‘s outstanding balance report i.e., balance due to / from
40.
vendors
B. Invoicing
Ability to pay each invoice individually or multiple invoices together for same vendor
1.
and manage outstanding balances accordingly by linking payment to invoices.
Ability to link every payment to invoice(s) and manage outstanding balances for
2.
individual vendors
3. Ability to generate alert for predefined vendors/POs/WOs before payment
Ability to prioritize payments based on pre-defined criteria e.g., due date, vendor
4.
category etc.
Ability to support Third Party payment options (Bank attachment cases, Power of
5.
attorney cases, etc.)
6. Ability to print cheques as per payment instruction
7. Ability to support payment through LCs / BGs
Ability to support predefined approval hierarchy and authorization workflow for
8.
payment to vendors based on amount, vendor category
9. Ability to appropriate / adjust advance payments against multiple contracts/invoices
10. Ability for online vendor registration of new vendors through online interface.
C. Procurement Planning
Ability to support annual procurement planning and budgeting in which Central Stores
1.
and Procurement team shall be involved
Ability to support annual material plan for individual area offices/ procurement/
2.
projects/ O&M
Ability to optimize individual requirements coming from area offices before generating
3.
procurement plan
4. Ability to specify products or services after analyzing the optimized requirements
Ability to select vendors and plan procurement for individual vendors on a periodic
5.
basis.
Ability to receive inputs from key partner suppliers/ vendors regarding products and
6.
service requirements planning
Ability to set up E - procurement facility to automate processing of transactions between
7. Discom and its vendors and to share information with vendors, leading to providing
access to Discom data, as and when Discom decides to use e-procurement
D. Purchase Requisition
1. Ability to display budget available before initiating purchase requisition
Ability to display lead time for purchasing material by material number/ material group
2.
before creating purchase requisition
Page 313 of 390

JPDCL

Ability to create purchase requisition / indent for various types of purchases e.g., stock
3.
materials, non-stock materials, services, assets, contract labor etc.
Ability to support approval hierarchy for authorization and release of purchase
4.
requisitions electronically
Ability to set approvals levels based on norms recommended by Discom like items
5.
classifications, procurement value etc.
Ability to provide purchasing rights of routine items to end users of the items along with
6.
hierarchy-based spending limit.
Ability to record user defined instructions/ requisition details as part of the purchase
7.
requisition.
Ability to assign unique purchase requisition number and restrict creation of duplicate
8.
purchase requisitions through in-built checks etc.
Ability to track the authorization status and generate alerts based on purchase
9.
requisitions awaiting approval
Ability to configure requisitions based on predefined criteria e.g., value, department,
10.
type of purchase etc.
11. Ability to modify purchase requisitions and resubmit for approval
12. Ability to cancel purchase requisition and automatically return committed budget
13. Ability to track and record the status of a requisition e.g., not approved, approved
Availability to search purchase requisitions based on various criteria like Requisition
14.
number, Requester, Item, etc.
Ability to link the purchase requisition to a valid project or cost center / Strategic
15.
Business Unit
Ability to configure the release procedure for purchase requisitions based on type of line
16. item e.g., as part of standard item list, requiring specialized documents and approvals
etc.
17. Ability to track changes made in purchase requisitions and generate audit trail
Ability to generate report of the purchase requisitions created over a period for the
18.
department / Area/ Office
19. Ability to generate report on status of purchase requisitions
Ability to generate report on purchase requisitions based on user defined criteria e.g.,
20.
requisition number, status, date, material number, description, originator etc.
Ability to display report on search results on purchase requisition details based on key
21.
fields like purchase requisition numbers
Ability to generate exception report on purchase requisitions rejected, not approved
22.
cancelled etc.
E. Purchase Order Management
Page 314 of 390

JPDCL

Ability to create purchase order (PO) directly or with reference to a Bid/Tender
1.
document, a contract, purchase requisition, or another purchase order.
Ability to create PO for different types of purchases e.g., stock materials, non-stock
2.
materials, services, assets, contract labor etc.
3. Ability to create PO with multiple delivery addresses and staggered delivery
Ability to have the following as part of the PO:
• Assign purchase order number both automatically and manually
• Requisition originators name and details as applicable
4.
• Item details with document attachment options to enable viewing of item
details
• Text fields for user defined special instructions
Ability to provide for ship-to address, bill-to address, invoice-sent-to address in the
5.
Purchase Order
Ability to specify on order, shipment-from, bill-by/payment to be released, report-to
6.
(agents), etc. vendor address in PO
Ability to capture payment terms in distinct parametric form e.g., full/part/advance,
7.
mode of payment, etc./address to release the payment
8. Ability to capture inspection requirements, acceptance criteria, etc. in PO
Ability to specify packing, shipping, scheduling instruction against item for PO (if desired
9.
unit wise packing may be asked for)
Ability to record standard documents of latest version like Standard Terms and
10.
Conditions of Indigenous/Import procurement, PBG, Bankers List, EMD, BG for Adv., etc.
11. Availability of multiple UOM for items for inventory and for placing order
Ability to support approval hierarchy for PO authorization based upon preconfigured
12.
criteria (also for repeat orders)
Ability to track the authorization status and generate alerts based on PO pending
13.
approval
14. Ability to modify the PO and resubmit for approval
15. Ability to consolidate multiple purchase requisitions into single PO for the same vendor
16. Ability to create multiple PO s from single requisitions for different vendors
17. Ability to split PO between vendors based on user defined parameters
Ability to distribute the costs for individual items in a PO to multiple accounts based on
18.
user defined distribution proportion to be charged to 'valid' accounts or project codes
Ability to display budget available for the purchase and generate alert if no budget is
19.
available or PO value exceeds budget during PO creation
Ability to refer to the type of procurement for an item during PO creation. The type of
20. procurement for the item will be part of the item master data detailing whether the
item:
Page 315 of 390

JPDCL

• Requires a material number.
• Requires an account assignment (i.e., whether you are required to enter an
account assignment category)
• Needs to be kept in stock.
• Requires a goods receipt and/or invoice receipt etc.
21. Ability to get the preferred vendor list for the items selected in the PO
Ability to refer to previously existing contracts with the selected vendors while creating
22.
PO
23. Ability to generate notification on request for vendor acknowledgement for a PO
24. Ability to record PO acknowledgement against the PO from vendors in the system
Ability to capture Purchase Order receipt/ Acceptance and Planned delivery date given
25.
by the vendor in the system.
26. Ability to follow up on the vendor for delivery by sending reminders/ risk & cost notice
Ability to amend Purchase Order with user's approval/ financial concurrence and
27.
approval of Competent Authority and to keep track of all past amendments.
28. Ability to attach documents and specifications to PO
29. Ability to record delivery and shipping information relating to a PO
30. Ability to record vendor performance data for deliveries against a PO upon inspection
Ability to enable three/ four-way matching of PO, Goods Receipt, Quality Inspection
31.
Report and Invoice generated in the system
32. Ability to generate notifications to vendors based on overdue PO
33. Ability to release schedules against a Purchase order for staggered delivery
34. Ability to provide for taxes and duties for various/individual items in the Purchase order
Ability to record specific terms of trade or payment in a PO e.g., Payment Terms and Due
35.
Dates etc.
36. Ability to record vendor discounts in the PO details
Ability to search and display previously created PO by vendor, item code, PO number,
37.
indent number
38. Ability to generate alerts for PO about to become due to the originators
39. Ability to track PO due dates and generate report to originators on overdue POs
40. Ability to create PO based on standard templates for regular purchase items
41. Ability to follow-up on the vendor for order delivery
42. Ability to display transactions history against the PO
43. Ability to automatically calculate Liquidity Damage (LD) based on PO terms
44. Ability to generate report on purchase order history for an item
45. Ability to generate report on change history for a particular PO
Page 316 of 390

JPDCL

Ability to generate reports on PO by user defined criteria e.g., PO numbers, Vendors,
46.
Material numbers, originator, Area Offices
47. Ability to generate report on POs due or overdue for receiving
48. Ability to generate report on PO outstanding for payment
49. Ability to generate report based on PO status
Ability to generate report on user defined exceptions on PO e.g., delivery exceptions,
50.
payment exceptions etc.
F. Turnkey Procurement
Ability to create Letter of Award (LoA) directly or with reference to a Bid/Tender
1.
document, a contract, purchase requisition, or another LoA
Ability to have the following as part of the LoA:
• Assign LoA number both automatically and manually.
2. • Requisition originators name and details as applicable.
• Item details with document attachment options to enable viewing item details.
• Text fields for user defined special instructions
Ability to capture payment terms in distinct parametric form e.g., full/part/advance,
3.
mode of payment, etc./address to release the payment
4. Ability to capture inspection requirements, acceptance criteria, etc. in LoA
Ability to record standard documents of latest version like Standard Terms and
5. Conditions of Indigenous/ Imported procurement, PBG, Bankers List, EMD, BG for
Advance, etc.
Ability to support approval hierarchy for LoA authorization based on preconfigured
6.
criteria
Ability to track the authorization status and generate alerts based on LoA awaiting
7.
approval
Ability to display budget available for the project and generate alert if no budget is
8.
available or LoA value exceeds budget during LoA creation
Ability to refer to previously existing contracts with the selected vendors while creating
9.
LoA
10. Ability to generate notification on request for vendor acknowledgement for a LoA
11. Ability to record LoA acknowledgement against the LoA from vendors in the system
Ability to capture LoA receipt/ Acceptance and scheduled delivery date given by the
12.
vendor in the system.
13. Ability to follow up on the vendor for delivery by sending reminders/ risk & cost notice
Ability to amend LoA with user's approval/ financial concurrence and approval of
14.
Competent Authority and to keep track of all past amendments.
15. Ability to attach documents and specifications to LoA
Page 317 of 390

JPDCL

16. Ability to record vendor performance data for deliveries against a LoA upon inspection
Ability to record specific terms of trade or payment in a LoA e.g., Payment Terms and
17.
Due Dates etc.
Ability to search and display previously created LoA by vendor, LoA number, and other
18.
user defined parameters
19. Ability to display transactions history against the LoA
Ability to make detailed estimates for civil, mechanical, electrical, instrumentation
20.
works, etc.
21. Ability to support multiple types/ modes of tendering
Ability to create a schedule of rates for various service items that would be used for all
22.
cost estimation for service procurement
Ability to generate automatic alerts/ reminders when a contract is about to be expired
23.
or requires renewal
Ability to monitor the LoA execution with respect to time and cost budgeted vs. the time
24.
and cost left
Ability to calculate deviations in scope and time and levy penalties/ liquidated damages
25.
and deduct the same from final payment to Contractor
Ability to support different business rules and policies for each Contractor class/category
26.
and Contractor type
27. Ability to amend/ cancel / offloading of contracts/ LoAs.
28. Ability to track LoA wise performance guarantee, Bank guarantee expiry dates
29. Ability to track LoA history, search work orders by Contractors, nature of job, etc.
30. Ability to record payment terms and actual payments made.
Ability to link payment to the Contractor with the status of the contract execution for
31.
real-time monitoring
Ability to send alerts at defined period/ status for a contract when specified parameter
32.
value is reached
33. Ability to generate report on change history for a particular LoA
Ability to generate reports on LoA by user defined criteria e.g., LoA numbers, Vendors,
34.
originator, etc.
35. Ability to generate report on due or overdue LoAs.
36. Ability to generate report on LoA outstanding payment history.
Ability to generate report on exceptions based on delivery slippages, deviations and cost
37.
overruns.
38. Ability to generate report on LoA current status.
G. Service Procurement
Page 318 of 390

JPDCL

Ability to support procurement of services through recording details of list of service
1.
items, bill of services, estimated rates etc.
Ability to make detailed estimates for civil, mechanical, electrical, instrumentation
2.
works, etc.
3. Ability to revise estimates, if required, during the execution of the order
Ability to support multiple type/modes of tendering for service procurement like RFQ,
4.
direct PO etc.
Ability to create a schedule of rates for various service items that would be used for all
5.
cost estimation for service procurement
6. Ability to create a service requisition/ proposal from an existing requisition
Ability to capture terms and conditions information for each contract proposal or
7.
Execution Order (EO, also referred as "Order" in Discom)
Ability to direct the tender to the appropriate authority for fund allocation/ approval as
8.
per defined hierarchy
9. Ability to generate Execution orders from the tender and the services chosen
10. Ability to create multiple execution orders from one requisition
Ability to compare the current offer with previous offers issued on any other Execution
11.
Order
12. Ability to record execution order receipt confirmation from the vendor
13. Ability to generate unique execution order number
14. Ability to specify staggered job completion pattern
Ability to create a blanket execution order/ rate contracts with or without quantity
15.
commitment and with or without schedule.
Ability to generate automatic alerts/ reminders when a contract is about to be expired
16.
or requires renewal.
Ability to generate a work schedule for various activities along with service item number,
17.
description, completion date, status updates, etc.
Ability to monitor the order execution with respect to time and cost budgeted vs. the
18.
time and cost completed
Ability to track whether payments are made to the workers by the Contractor as per the
19.
statutory requirements
20. Ability to record acceptance/ rejection/ partial acceptance of the service provided
Ability to monitor the order execution with respect to materials issued, payments made
21.
to the Contractor, materials returned by the Contractor
Ability to evaluate the Contractor performance based on pre-defined parameters, record
22.
and provide feedback
23. Ability to calculate deviations in scope and time and levy penalties/ liquidated damages
Page 319 of 390

JPDCL

and deduct the same from final payment to Contractor
Ability to provide a source list of various jobs with job codes and the related list of
24.
vendors attached to it
Ability to capture details like original bid reference, value of work, date of
25. commencement, contract period (completion date), scope of work BOQ, statutory
requirements, GCC conditions, special conditions of contract, etc.
26. Ability to amend proposals and get on-line approvals for amendments
27. Ability to amend/ cancel execution orders/ offloading of contracts
Ability to track execution order wise performance guarantee, Bank Guarantee expiry
28.
dates
Ability to track execution order history, search execution orders by Contractors, nature
29.
of job, etc.
30. Ability to record payment terms and actual payments made
31. Ability to track execution order status in terms of time and cost budgeted
Ability to track execution order wise material and manpower usage versus the budgeted
32.
quantity and highlight any deviations
Ability to link payment to the Contractor with the status of the contract execution for
33.
real-time monitoring
Ability to send alerts at defined period/ status for a contract when specified parameter
34.
value is reached
35. Ability to generate report on status of a service execution order
36. Ability to generate report on service execution orders for Discom
37. Ability to generate report to evaluate vendor performance on user defined criteria
Ability to generate report on exceptions based on delivery slippages, deviations and cost
38.
overruns
Ability to generate reports on service procurement execution order status e.g.,
39.
completed, vendor acknowledged
H. Contract Management
Ability to support contracts both manually or automatically based on Bid/Tender
1.
document results and authorizations
Availability of contract templates for regular items based on previous contracts for
2.
efficient contract creation
Ability to integrate contract creation with other functionality like Bid/Tender document,
3.
Vendor Management and PO management
Ability to define delivery schedule containing precise information on the delivery e.g.,
4.
quantity, dates, schedules as part of the contract
5. Ability to support approval workflow for contract management with authorization
Page 320 of 390

JPDCL

hierarchy for approval and release of contract based on predefined user criteria
6. Ability to generate alerts for contracts requiring approval to authorized users
Ability to request for authorization in the next hierarchy if there is no response on the
7.
approval request by preset time horizon
Ability to record and display the status of the contract i.e., awaiting approval, approved,
8.
or rejected
Ability to reject the contract during authorization, record the reason for rejection and
9.
return to the originator through the workflow
Ability to assign vendors to the contract either manually or based on Bid/Tender
10.
document results
11. Ability to modify the contract and resubmit for approval
Ability to record contract related information like:
• Contract Number
• Contract Type
• Terms and Conditions of the Agreement
12. • Expiry Date
• Contract Value
• Related Information/ Supporting documents
• BG details
• EMD
13. Ability to record EMD against tenders
14. Ability to generate alert for returning EMD for successful / unsuccessful Bidders
15. Ability to track EMD, Tender Fee & Bank Guarantees
16. Ability to record all changes to the contract and track contract history
Ability to search and retrieve contract information including contracts for materials or
17.
services that are no longer active
18. Ability to attach documents e.g., specifications for contracts
19. Ability to generate alerts for contracts nearing expiry to trigger renewal process
20. Ability to check the contract value with procurement budget for the Discom
Ability to request for vendor acknowledgement of the contract after sharing the contract
21.
with the vendor
22. Ability to record vendor acknowledgements to the contract
23. Ability to track the contracts which have not been acknowledged
Ability to track contract performance bank guarantees based on vendor, contract, and
24.
PO
Ability to generate alerts based on expiry of bank guarantees/warranty for items/Defect
25.
Liability period
Page 321 of 390

JPDCL

Ability to generate extension letters by correlating the terms and conditions of the
26.
contract with the progress of work/contract
27. Ability to define Discom and regulator specific rules to manage contracts
28. Ability to generate report on all changes made to a contract
29. Ability to generate report on contract status - approved, awaiting approval, expired etc.
30. Ability to generate report on user number, vendor, originator, authorizer, item etc.
Ability to generate report based on expiry of contracts/warranty for items/Defect
31.
Liability period
32. Ability to generate report on vendor performance on contracted terms
33. Ability to view historical transactions for a contract
Ability to generate report on expected receiving date, payment date - item wise for a
34.
given time horizon e.g., monthly, quarterly, annual basis
Ability to generate consolidated report of contracted values per vendor over a time
35.
horizon
I. Procurement General Reporting Requirements
1. Ability to generate reports confirming to Regulatory, Technical etc. requirements
Ability to provide necessary information to populate predefined Balanced Score Cards
2.
for monitoring of Key Performance Indicators
Ability to meet process/reporting requirements of approved documents like
3.
Procurement Policy and Procedures, etc.
Page 322 of 390

JPDCL
Project Management

A. Project Planning
1. Project Initiation - Communication within organization
2. Project Management Tools for developing project plan
3. Ability to revise project plans
4. Ability to suggest financing plan at the project planning stage itself
Ability to tie-up all documents related to a project (including documents related to
5.
required statutory clearances and compliances) in project control folder
6. Ability to classify type of projects- turnkey/ modular at project planning stage itself
Planning Support - Ability to create planning support repository which will consist of
7. documents related to standard templates of resources, risk & effective mitigation
strategies, learning from other projects, other historical data etc.,
8. Ability to identify regulatory risks & probable mitigation strategies
Ability to maintain a database stating technological options available in the market with
9.
financial cost involved
Ability to create project profile - Name, type, capacity, mode of funding, project cost
10.
center, location, beneficiaries, major milestones, technical details, financial details, etc.,
Ability to assign scores to projects based on benefit measurements and rank them zone
11.
wise and organization wise (Generation/ Distribution Sector)
12. Ability to record project cost estimates, during project setup
A suitable mechanism to index and categorize various proposals for new projects /
13. schemes. This is needed to keep track of the stage at which a new proposal is presently
or to get a view of all the proposed projects or any one of the projects or cumulative
14. Ability to highlight total plan budgets, based on notional plans
Based on above, ability to identify projects for each year, for each office, for distribution
15.
business
Maintain bidder ‘s database and standard rates with reference to their previous
16.
performance
17. Ability to create and link projects, sub projects, activities and tasks
18. Project planning to include schedule for material requirement
19. Ability of create BOQ
20. Ability to integrate BOQ with proposed expansion/extension
21. Ability to create an ad-hoc project, where a work breaks down structure is not required
Change in individual task completion dates, should reflect in overall project milestone
22.
dates
23. Project Planning steps should cover user defined workflow with the ability to modify and
Page 323 of 390

JPDCL

approve the workflow
Ability to define project related checklist / steps and issue alert for deviation/non-
24.
compliance
Ability to assign project owner, project manager, accountable person and key
25.
stakeholders
26. List of new projects initiated and their current position
27. List of new projects waiting for approval at different stages
28. Ability to maintain data of approved vendor
29. Ability to modify the data of approved Vendor
30. Ability to create/Modify/upload Approved GTPs
B. Project Scheduling
Ability for create pre-award schedule (timeline for finalization of specs, NIT, bid
1.
evaluation timelines, contract)
Ability to revise the pre-award schedule including splitting, stretching and crashing of
2.
activities
3. Ability to prepare project implementation schedule based on the benefit score
Support for attachments such as drawings, specs, instructions etc., in formats such as
4. PDF, CAD, Visio, text/flat files, PPT, XLS, DOC, RTF, TIF, GIF, JPEG, GIS output/ reports
etc.,
5. Ability to balance resource usage in a given timeframe, to ensure optimal usage
Import/Export to industry standard project management software applications such as
6.
Primavera/Project Scheduler/MS Projects etc.,
7. Ability to create project wise and Discom wise budgets for various projects/sub modules
Ability to define milestones with categorizations like HOLD point, CHECK point, etc.,
8.
required actions at the milestones, and authority responsible for action
Ability to restrict/allow progress based on completion of required actions at HOLD point,
9.
CHECK point, etc.
10. Ability to link between projects, activities and tasks
11. Ability to schedule payments against key milestones
12. Status of projects waiting for order
13. Ability to generate report on key project milestones and scheduled payments
Ability to generate report on estimated time-based expenditure on each project /
14.
scheme
15. Ability to generate report on critical paths in projects
Ability to generate reports confirming to technical, operational, regulatory, statutory
16.
and other business requirements
Page 324 of 390

JPDCL

17. Ability to create warning Alerts against different time lines of tenders/Execution plans
C. Project Execution
Ability to break projects into activities, sub-activities indicating milestones with
1.
commonly used methods like PERT, CPM
2. Ability to change milestones pre and post facto
3. Ability to track the status of every item in the BOM, resource list
Ability to track/ record "Issue Slip" by the designated authority to allot materials to be
4.
issued by the store for works at desired location
5. Ability to record bidder deliverables inspection and results
6. Ability to issue compliance certificate, post quality assurance
7. Ability to reconcile quality check against quality plans/checklists
8. Ability to maintain online quality assurance during project execution
9. Ability to record and track quality deviations
10. Ability to update physical and financial progress
Ability to track completion of each module/activity, leading to the overall commissioning
11.
of project
Enable management to achieve organization wide compliance and greater efficiencies
12. in project delivery by capturing and deploying best practices and continually improving
processes.
Enable project managers to gain insight into the performance of overall projects /
13. schemes by identifying relevant project trends and problem areas using powerful
analysis tools.
System should enable online project management process by enabling team members
14. to easily manage, track, and report on their project activities through familiar tools, like
the Web.
Ability to incorporate security measures, to limit changes by project owners to only their
15.
respective projects and simulations
16. Ability to track changes, with reasons, time and moderator
Ability to track deliverables against individual bidders, leading to respective contract
17.
closure
18. Ability to generate, record and manage contract closure certificates
19. Ability to record and track Bank Guarantee information
20. Ability to generate alert on Bank Guarantee expiration
21. Ability to generate note on Bank Guarantee extension/encashment/return
Ability to setup a billing plan, that allows the release of payments upon achieving set
22.
milestones
Page 325 of 390

JPDCL

23. Submission control mechanism to set deadlines to receive budget requests
24. Ability to track changes made to the budgets, after budget approvals
Ability to record manpower deployment by contractors along with credential of key
25.
experts/Project Handling Managers
26. Store baseline and revised plans
Report on activity-wise material consumption along with warning on material getting
27.
exhausted
28. Report on quality and quantity deviation
29. Report on status of the contracts
30. Ability to record and track tender fee information
31. Ability to track encashment of tender fee
D. Project Monitoring
1. Ability to monitor each activity/task in the project
2. Ability to monitor variations from schedules and send alerts
3. Ability to generate alerts for slippages at all levels (post and anticipatory)
4. Ability to generate alerts for delay in payments
5. Ability to generate alerts for delay in starting/completion major activities/milestones
6. Ability to generate alert for initiating notification to regulators on certain issues
7. Ability to record delay in activities attributed to externalities (Legal cases etc.)
Ability to raise alerts for requirements for liaison with local authorities to solve out some
8.
external issues
Ability to check adherence to material availability with provision of alert generation in
9.
case of deviation
Ability to monitor project, resource wise, timeline wise, deliverable wise, and funding
10.
agency wise
Ability to monitor estimates versus actual and calculate variance: money amounts,
11.
services, labor, time span, vehicles used, plants used, material etc.,
12. Ability to monitor all projects consolidated, individual projects and individual tasks
13. Ability to carry out resource tracking across projects
Capture all the project management activities for the entire cycle of construction
14. projects i.e., from the point of proposal of a new project to final testing & commissioning
of the project.
Ability to track every document in the project - to trace with who is the current owner
15.
of the file/document, for how long and why
Provide a central tracking system that enables project teams to record, assign, & resolve
16.
issues and capture related risks pertaining to project.
Page 326 of 390

JPDCL

Ability to display project total, accumulated costs in terms of actual, revenue,
17.
capitalization costs, future commitments etc.,
Ability to incorporate feedback from random inspection teams from corporate for major
18.
projects
19. Ability to generate alerts for delay in payments
Ability to record and monitor data on accidents during the project execution project and
20.
resources linked to each bidder
Ability to support NPV (Net Present Value) and SVA (Shareholder Value Added) analysis,
21.
IRR for projects and subprojects
Ability to maintain project percentage completed status (financial as well as physical) -
22.
based on work to date.
Progress reports to funding agencies, management, regulatory bodies and others as per
23.
requirement
24. Slippage reports for all major milestones
25. Drill down facility and Ad-hoc reports, with filter, sort, query, charts etc.,
Ability to display project activities in Gantt charts, pie charts, histograms, tables, etc.
26. illustrating ‗actual ‘to ‗originally planned ‘projects progress in- terms of schedule and
cost
27. Ability to generate scheduling of inspection/completed Activities
E. Project Accounting
Record the costs for each major project or a set of activities under investigation, cost for
1.
each major milestone
Provide an analysis of resources used on a project compared to the estimates for
2. different categories, i.e., money, time, materials, overheads etc. with cost implications
for all
3. Maintain all the cost records for the duration of the project.
4. Ability to reflect inflation in project costs along with the reasons
5. Ability to record information on payment terms, milestones, etc.
6. Ability to store / record invoice cost + Tax invoices from bidders
7. Secure creation of project codes
8. Ability to support alpha-numeric characters for project codes - no limit in length
Support for auto-generation and manual generation of project codes, and preserve
9.
uniqueness in project codes
Ability to review completeness / correctness of invoice and certify completion of
10.
milestone
Ability to approve invoice and send information to Finance Dept. for payments
11.
(hierarchy-based approval)
Page 327 of 390

JPDCL

Ability to integrate with Financial Management system to view real time information on
12.
status of payments against unique project codes and invoice number
Ability to maintain payment records for the duration of the project against unique
13.
project codes
14. Ability to transfer data from Capital Work in Progress to completed capital works
15. Ability to transfer data relating to completed capital works to the Fixed Assets system.
16. Ability to conduct project wise cash flow analysis for a minimum of 5 years
17. Cash flows to be monthly, quarterly, yearly and user defined as well
Ability to incorporate interim cash flow from a partially commissioned project to
18. calculate its final IRR of the total project (required in the case of internally funded
project)
Ability to establish security measures to ensure that the personnel are allowed to
19.
review/edit projects they are involved with ensuring proper authority and access control
20. Ability to notify all appropriate personnel regarding project closure
Ability to integrate with Standard accounting journals for areas such as interest
21.
capitalization and overheads, transportation, etc.
Ability to provide security measures, to ensure that the project closure is done by
22.
authorized personnel only
Ability to generate reports confirming to technical, operational, regulatory, statutory
23.
and other business requirements
Ability to generate reports on current accumulated cost of a project vis-à-vis estimated
24.
cost
Provide up to date cost reports to management - project wise, activity wise as well as
25.
meeting customized requirements
26. Ability to collect all the data required for auditing
27. Ability to generate Alerts against Low/Non availability of funds
28. Ability to record/Store/check e-challan/e-Way Bills
F. Integration with Other Programs
The system will use data captured by the Stores, finance, Payroll and Purchasing systems
1.
and pass the information to the General Ledger
2. Data relating to completed capital works will be transferred to the Fixed Assets system.
3. Integration with Stores control for stock items used
Ability to record Direct purchasing of goods and services (purchase orders; goods
4. received notes etc. for goods and services which do not pass through the stores system)
through the Purchasing system
Ability to integrate with Standard accounting journals for areas such as interest
5.
capitalization and overheads etc. into the General Ledger
Page 328 of 390

JPDCL

6. Final costs transfer to general ledger only on project completion certification.
7. Ability to link with revenue accounting on completion of the project
8. Index project cost codes to relevant general ledger account.
General Ledger accounts to be updated directly from the project accounting system as
9.
an associated function.
Assets created through works under project cost control must be identified on
10.
completion for entry to the asset register.
All data must be identified to its correct financial year and month in that financial year
11. so that any queries over the accuracy of charging resources to the project can be
properly investigated. Consolidated data for each year is not adequate.
View all the reports related to inventory management in respect of construction and
12. O&M materials for financial accounting purposes from System with appropriate
security.
Capitalization of Projects (Capital Work in Progress). From projects to Assets
13.
Management.
Possible to link Purchase Order number of contracts (with contractors) with the project
14.
number
Integration with the Materials Management module to ensure material availability in
15.
site based on current stock and requirement of the project
16. Ability to integrate the data with GEM
17. Ability to show the complete works on website of JPDCL
G. Project Management General Requirements
Capture documentation related to execution of various projects (existing & old) for
1.
retrospective analysis in future.
2. Comprehensive project database to capture the data pertaining to all aspects of projects
3. Resource tracking across projects
Ability to generate technical / financial specifications for projects and to analyze and
4.
evaluate the bids received
Full data on any project must be kept throughout the life of a project and must be able
5.
to be printed out and/or reviewed on screen at any time.
Prevent further transaction processing/transfers against finalized jobs/projects- No post
6.
fact editing
7. Ability to generate Gantt charts, histograms, tables, charts etc.,
Ability to send SMS alerts + email to concerned officials at defined milestones for actions
8.
to be taken (e.g., payments) and deviations from schedules
Ability to provide necessary information to populate predefined Balanced Score Cards
9.
for monitoring of Key Performance Indicators for Planning, Engineering and Project
Page 329 of 390

JPDCL

function
10. Ability to record and show the penalty imposed for Delay/Default
Page 330 of 390

JPDCL
Asset Lifecycle Management

1. Manage Asset Master Data maintenance.
2. Capability to create asset by interlinking SIV and estimate marked for the asset
Centralized definition of assets categories, description, multiple depreciation rates,
3.
predefined residual values etc.
Centralized definitions of content of Asset Register to support Companies (Auditor ‘s
4.
Report) Order, 2013 [CARO] and other statutory requirements
5. Capability to maintain parent-child relationship across assets classes
Capability to maintain the following information in the asset master, but should not be
limited to:
• Asset number
• Group asset number
• General information (e.g., description, make/model, quantity, acquisition date,
owner unit, using unit)
• Posting information (e.g., capitalization date and amount, asset expiry date)
• General ledger account assignment
• Accumulated depreciation
• Depreciation
• Date of Put to use
• Asset Category
• Old depreciation if it is migrating from any other legacy system
• Gain/ loss on disposal
6.
• Revaluation
• Information on the origin of the asset (vendor information e.g., serial number)
• Purchasing information (e.g., vendor number, purchase order number, receiving
number)
• Physical inventory data
• Budgeting data (e.g., budget number)
• Insurance data/ warranty
• Depreciation data - asset useful lives, useful date, residual value, depreciation
method
• Asset location
• Asset class/subclass
• Asset type
• Project/ job number
• Remarks-Examples of information required to be maintained within the Fixed
Capability to perform:
• Master record creation
7.
• Manually
• Automatic posting from Material Management System, Asset & Inventory
Page 331 of 390

JPDCL

System
• Master record changes
• Deactivate master record (this should be automatic upon retirement of asset)
• Delete master record, provided no posting was made to it
• Block asset (to block further cost posting into the asset)
• Change to location/ reporting unit
• Change in assignment of asset, to asset class
• Change in asset useful lives
Capability to carry out mass changes automatically to a large extent for user definable
asset record selection criteria:
• Mass change to depreciation methods
8. • Mass change in depreciation rates
• Mass change in useful lives
• Mass change in asset classification
• Mass change in locations/ reporting units
Provide audit trail for creation, amendments, transfer and deletion for all asset group and
9.
subgroups
10. Capability to maintain FA register locally at Plant/Unit etc.
11. Capability to record fixed assets as either capitalized or work-in-progress

Capability to define fixed assets at different levels such as:
• Group asset (main and components) e.g., Land & Building
• Asset class/subclass (Group asset belongs to an asset class as per user defined
12. norms) e.g., factory land
• Asset type (e.g., tangible and intangible)
• Balance sheet (asset class is assigned to GL account code. This forms the balance
sheet item)
Capability to decide the asset categorization at the time of order placement/contract
13.
finalization
Capability to differentiate between new asset and value adjustment/up gradation to
14.
existing capacity
15. Record fixed assets with date placed in service in the past
16. Record fixed assets with date placed in service in the future
17. Capability to merge multiple fixed assets into one fixed asset
18. Capability to split the single asset into multiple fixed assets
Provision to rectify errors in recording fixed assets in the same period or in previous
19.
periods
20. Capability to record number of units against each fixed asset e.g., chairs - 10 units.
Page 332 of 390

JPDCL

21. Capability to record fixed assets taken on lease, assets on other's property etc
Capability to generate Fixed Assets schedule in accordance with the Statutory
22.
requirements
Capability to generate Fixed Assets schedule in accordance with:
• Companies Act 2013
23.
• Income Tax Act 1961
• Any other Regulatory requirement
24. Capability to update Fixed Asset Register upon capitalization of asset Manage Assignment
Capability to assign an asset to a specific reporting unit or business area (e.g., Area
25. Office/sub-station) for internal reporting purposes e.g. When an asset is assigned to a
specific reporting unit, the system should automatically post the transactions s
26. Manage Addition of Fixed Assets

Capability to automatically or manually allocate a unique asset number upon creation of
27.
the asset master record
Allow for asset additions and capital improvements including:
• Acquisition and capital improvement costs and dates
28. • Maintenance costs and dates
• Original and extended useful life
• Mass additions
Capability to capture expenditure under "Capital Works in Progress (CWIP)" till
29.
completion/commissioning of Asset
30. Capability to transfer from CWIP to respective Asset Account on completion of work
Capability to capitalize asset via Integration with Accounts Payable
• Post the asset acquisition and the corresponding vendor liability in one
transaction
31. • Integration with Purchasing/ Inventory
• Upon receipt of asset (with value), before invoice receipt
• Upon receipt of invoice, asset is received (unevaluated) earlier
• By moving the item from inventory
Capability to capitalize an addition or enhancement to an existing fixed asset in the current
32.
fiscal year
Capability to process a credit memo, which reduces the acquisition and production costs
33.
of an asset
Capability to maintain component-wise break-up of the capitalized value of the asset like
34. original cost, installation cost, allocated amount of indirect expenditure, interest
capitalized etc.
Page 333 of 390

JPDCL

Capability to update the acquisition transactions automatically to the respective account
35.
codes in the General Ledger
36. Manage Transfer of Fixed Assets

Capability to:
• Move an asset, resulting in the need to change asset master data that cannot
be otherwise changed (e.g., the asset class, main asset)
37. • Split up an asset or move part of an asset (transfer between asset groups, sub
asset group)
• Transfer material from the inventory (current assets) to a fixed asset (for
example, for a replacement part)
Capability to capture information such as:
• Date of transfer
38.
• Cost, accumulated depreciation and net book values transferred
• Manage Fixed Asset Disposal/ Retirement
Capability to identify "assets not in use/ awaiting disposal" based on user-defined criteria
(e.g., asset class, location). The listing should contain the following information, but
should not be limited to:
39.
• General master data - location, description, make/ model, acquisition date
• Asset history
• Asset values (book value)
Capability to electronically route proposed disposal listing to specific users for approval
40.
within the system
Capability to perform the following within the Fixed Asset system:
• Perform complete/ partial retirement
41. • Provide simple method of retiring low value assets
• Perform mass retirement
• Capture cost of retirement (e.g., removal cost)
Capability to make provisions against losses on retirement of assets in respect of Assets
42.
waiting for disposal
43. Capability to automatically calculate the gain or loss on disposal/retirement

Capability to capture disposal information such as:
• Date of retirement
• Cost, accumulated depreciation and net book values written off
• Sales proceeds
44. • Sale Invoice Number
• Buyer Details
• Gain/ loss on disposal
• Reasons for retirement
• Cost of Removal
Page 334 of 390

JPDCL

• Mode of retirement e.g., sold, scrapped, donated etc.
Capability to post automatically or manually to the respective account codes in the
General Ledger:
• Gain or loss on disposal.
45.
• Sales proceeds.
• Capitalization cost;
• Accumulated depreciation
Capability to automatically determine the corresponding depreciation charge for the
partial disposal, based on one of the following entries:
46. • Amount of the acquisition costs being retired
• Percentage rate
• Quantity
Capability to manually amend the partial disposal amount calculated by the system and
47.
then recalculate the corresponding depreciation for posting to the General Ledger
48. Capability to post automatically or manually to issue invoice in the Account Receivable
49. Capability to reinstate fixed assets incorrectly retired
50. Manage Depreciation of Fixed Assets

Capability to support different methods of depreciating an asset, such as
• As per Regulatory Requirements
• User-defined rate tables
51. • Sum of digit
• Unit of use
• Useful life
• WDV
52. Capability to change of useful life and effective rate of depreciation at any point of time
Support change in method of deprecation and rates of depreciation for a specific fixed asset
53.
or group of fixed assets during the life of the asset(s)
Capability to maintain multiple depreciation rates vis-à-vis the periods to which they apply
54.
and Capability to calculate depreciation with retrospective effect wherever required
Capability to facilitate adjustment of depreciation of fixed assets prior to and after updates
55.
to general ledger
Capability to automatically post to the corresponding accumulated depreciation and
56.
depreciation expense accounts in the General Ledger
Capability to provide at least daily and monthly basis of calculating depreciation and
57.
depreciation expense accounts in the General Ledger depreciation
Capability to comply calculating depreciation with accounting standard and tax regulation
58.
and regulatory requirements
Page 335 of 390

JPDCL

59. Capability to provide for recalculations of depreciation expense on assets re-valued
60. Manage Insurance of Fixed Assets
61. Record all insurance related details against fixed assets
62. Record multiple insurance policy details against individual fixed assets
System generated alerts/reminders to designated users about insurance premium payable,
63.
new policies to be taken, policies to be discontinued etc.
Capability to automatically update insurance record on passing of the insurance premium
64.
bill with the policy details
Capability to monitor sale/purchase of insurable assets and update insurance records
65.
automatically
66. Capability to update details of claim settled / partly settled / rejected
67. Manage Revaluation of Fixed Assets

Capability to capture the following information:
• Revaluation amount
• Revaluation date
68.
• Revaluation method
• Values reference
• Computation of revaluation surplus/ deficit and diminution
Capability to keep the original asset cost details separated from the revaluated amounts
69.
and a history of revaluation for each asset over time
Capability to automatically post revaluation transaction to update relevant accounts in the
70.
General Ledger (allowance for revaluation (surplus/deficit), allowance for diminution)
71. Manage Physical Verification of Fixed asset

Capability to print asset listing for physical count based on user-definable criteria.
The following information should be generated for each asset; but not limited to:
• By owner unit
• By using unit
• By location
• By asset class / asset category
• By Date
72.
• By Retirement date
• With asset ID
• With asset Class
• With asset description
• With location
• With quantity
• With value
Page 336 of 390

JPDCL

Capability to process the results of the inventory manually or automatically by:
• Making comparison with information in the database
73. • Retiring the asset if asset is confirmed missing.
• Change location if asset has changed location.
• Enter the inventory date in the assets counted and assets identified as missing
Capability to capture the following information for all types of adjustments such as:
• Date of adjustment
74.
• Cost, accumulated depreciation and net book values adjusted
• Adjustment reference document (if any) and authorization
Capability to adjust the acquisition cost and corresponding depreciation manually or
75. automatically for the missing assets to the General Ledger upon update of Fixed Asset
system
Capability to ensure that no duplication of the equipment/asset can occur. In other words,
76.
an item of equipment, once defined, cannot be duplicated within the system.
Capability to define continuous assets/equipment applicable to UH and DH distribution
77.
assets.
The system is to provide facility to allow an item of equipment to be defined as a function
78.
of its length.
Capability to record any environmental issues or regulations required in the operations of
79.
the equipment / asset.
80. Capability to record the physical location of each fixed assets Manage Integration
Capability to provide for automatic integration with General Ledger, Accounts Payable,
Accounts Receivable, Project Management and Budget, including the following:
81.
• Automatic interfacing of accounting entries to the G/L module.
• Drill-back to Account Payable (e.g., Invoice, Purchase Order etc.)
82. Manage FA Reporting and Enquiry

Capability to display asset description at individual asset level, summarized levels (e.g.,
83.
asset class, asset group, by balance sheet) and by asset (e.g., asset number)
Capability to provide drill-down from asset descriptive details to:
• Balances
84.
• Depreciation
• GL account code
Capability to provide asset information via screen and print report, but not limited to:
• By date, year (e.g., by year of capitalization, year of disposal)
• By type of transaction (e.g., acquisitions, transferred, retirement, Written-off,
85.
etc.)
• By asset location - for small assets which are portable
• By owner unit or using unit
Page 337 of 390

JPDCL

• By asset class (main asset group, subgroup, asset number)
• By user-specified rules
Capability to produce reports for various reporting, flexible report writing tools and on-
line enquiry facilities but should not limited to the following:
• Assets by source of funds (e.g., capital contribution, own funds, grant, loan,
consumer contribution, equity)
• Financial reporting (e.g., audit and taxation)
• Management reporting
• Examples of standard reports are listed, but should not be limited to, as follows:
• Assets at gross separately from accumulated depreciation – for period and year-
to- date
• Asset master at summary and detail level
86.
• Asset additions
• Asset retirements
• Asset valuation - gross asset values, accumulated depreciation and NBV
• Assets by source of funds (e.g., capital contribution, own funds)
• Assets by acquisition method (e.g., purchasing, donation)
• Depreciation expense using flexible user selection criteria
• Depreciation forecast
• GL posting summary
• Assets not found at location
• Asset found at location other than that assigned in the asset record
Capability to provide ad hoc listings via screen and/or print listings based on following
user defined specifications but not limited to:
• Select and sort by asset category
• Select and sort by asset class
• Select or exclude fully depreciated assets
87. • Select or exclude retired assets
• Select by GL account codes
• Select by business units
• Select by asset status
• Select by asset location
• Select by asset life within asset book
Capability to provide reports that can analyze asset information:
• By owner unit or using unit (e.g., zones, Area Office)
• By time (e.g., year)
88.
• By company, asset type, department and location.
• By movement (such as addition, transfer or disposal) by account, current month
or year-to-date activity
Provide for complete asset history, for example:
89.
• Depreciation, depletion and amortization current period, year-to-date,
Page 338 of 390

JPDCL

accumulated
• Net book value and residual value for finance, tax and regulatory requirements
• Remaining life
• History transactions with line-item
• Repair and maintenance tracking
• Warranty claims and settlements tracking
• Insurance claims and settlements tracking
• Acquisition and retirement date
• Any other specific information required
Capability to provide the following details or reports for taxation purposes:
• Qualifying cost
• Non-qualify cost
• Year of assessment of acquisition
• disposal/ write off
• Qualifying cost
• Non-qualify cost
• Sales proceeds
• Year of assessment of expiry Adjustments/ transfers
• Qualifying cost
90.
• Year of assessment of adjustment/ transfer Reconciliation of fixed asset
movements
• Opening balance
• Additions
• Disposals
• Transfer in/ out
• Adjustments
• Qualifying costs
• Non-qualifying costs
• Closing balance Auditing Process
Capability to maintain repair and preventative maintenance history data for each
91.
equipment unit, including online access to both summary information
Capability to record capital assets that were originally captured as construction in progress
92.
in another module like Works Accounting
Capability to generate reports detailing the cost of new assets acquired to replace an asset
93.
lost, missing, stolen, or destroyed
Capability to create report with filter criteria as organized, sorted by physical asset location
94.
and by sub-location codes specified by the agency.
Capability to track and report by each asset record if the equipment custodian (assigned
95.
responsible employee) is authorized to take his or her assigned assets offsite from the
Page 339 of 390

JPDCL

office and identify the person who authorized the employee the privileges or right to take
his or her assets offsite.
Page 340 of 390

JPDCL
Supply Operation / Online Feeder Management

1. Capability to calculate the AT& C losses
Capability to get the AT &C Loss report at various level (Corporation level/Division
2. wise/Sub-division wise/Feeder wise/Feeder Manager wise) for specific date range.
3. Capability to monitor the AT&C Losses Improvement progress of JPDCL
4. Ability to get the Year month wise Revenue Billed Trajectory
5. Ability to get the Year month wise Revenue Collected Trajectory
6. Ability to prepare the e Meter Reading Sheet at Corporation/Division/Sub-Division level
7. Capability to monitor the purchase of powers through transmission department
8. Should allow allocation of procured energy.

Ability to generate MIS reports and visually display data on Dashboard in form of graphs,
9. charts, Gantt charts, etc as per requirement.
Ability to provide the SAIDI (System Average Interruption Duration Index) and SAIFI
10. (System Average Interruption Frequency Index) data.
Page 341 of 390

JPDCL
Energy Management

1. Ability to generate daily consumption report for energy services (like electricity, gas etc.)
Ability to book the purchase from transmission division on the basis of consumption
2.
predictions
3. Ability to distribute the energy internally based on the requirement.
Capability to generate the report includes information on key regulatory parameters for
4.
the specified period for Distribution, Transmission and Generation utilities of JPDCL.
5. Capability to get the information about the Average Billing Rate, distribution losses etc.
6. Capability to get the information Power Procurement Cost of DISCOMs
7. Capability to validate that Electricity (Rights of Consumers) Rules 2020 are aligned
8. Capability to capture the Date of Issuance of Tariff Order (Distribution Utilities)
9. Capability to get the variance between Approved and Actual Average Billing Rate
Capability to capture the Open Access Charges like Cross Subsidy Charges, Additional
10.
Surcharges and Wheeling Charges etc.
11. Capability to calculate the Return on Equity for JPDCL.
Capability to manage and take care of resource and inventory and to help in effective
12.
resource planning
Capability to manage variety of rate tariffs and monitoring of the same prior to charging
13.
it to the customers.
Ability to assist in enhancing the asset dependability and reducing the further losses,
14.
increases billing efficiency and thereby increases speed of execution
Ability to integrate with each business functional modules or any other sub system for
15.
smoothens functioning
16. Capability to monitor the meters for building the forecasting trend.
Page 342 of 390

JPDCL
Operations Support

Ability to prepare a Maintenance Budget for Discom with appropriate linkages with
1.
Capital Repair Plan, Preventive Maintenance Plan, Annual Business Plan etc.
Ability to collate budgetary requirements for maintenance from concerned departments
2.
as part of Maintenance Budget exercise
3. Ability to generate format for estimation based on budgetary offers or otherwise
Provision to forecast the cost, including cost of spares, manpower and purchased
4.
services, of Preventive Maintenance activities based on pre-defined checklist
5. Ability to register breakdown call online. Online refers to ERP system.
Ability to send Alert/ Trigger/notification for initiating and closing of request (SMS
6.
facility/ mail) should be sent to all stakeholders by the system.
7. Ability to do Breakdown Calculation based on working hour of the machine
Ability to show Online stock position, online generation of requisition- Ability for Auto
8.
indenting of regular consumable materials
9. Ability to record technical specification of equipment and maintain it on ERP
Ability to search/ trace the material based on specification/ description/ vendor -
10.
Traceability for non-stock items (where material code is not available)
Ability to generate single tender certificate based on various parameters. It is a
11. certificate issued by requester justifying the emergency/proprietary reasons allowing
purchase to go for single tender.
Ability to Vendor to Check the purchase order (PO) Status, Billing Status, Vendor
12. Performance Rating, Upload Test Certificates, Booking Inspection Call / Transporter etc.
should be available online
Maintain vendor specific warranty information and display the same when a problem for
13.
the equipment is notified
Ability to capture PM activities carried out for individual machines under the same
annual maintenance contract (AMC). If more than one equipment is covered in an AMC
14.
(since only one PM plan can be created for each AMC), it is not possible to capture PM
de
15. Ability to deactivate disposed equipment from equipment master
Ability to provide online workflow-based processes for raising notifications, assigning
16. jobs to relevant personnel, preventive maintenance, breakdown maintenance,
calibration of equipment for repair, spares requisitions.
Ability to integrate Maintenance Module processes with other functions like materials
17.
management, production, sales & distribution and finance
Ability to send an alert to the concerned stakeholders if the Preventive Maintenance
18.
(PM) is not completed on time. Alert refers to Email as well as SMS.
19. Ability to compute MTBF (Mean Time Between Failures) and MTTR (Mean Time to repair)
Page 343 of 390

JPDCL

for an equipment
20. Ability to show Depreciated value of machine
Ability to Upload measurement parameters through upload of excel for the logbook
21.
maintenance
22. Ability to view steps and milestones of a maintenance order to be executed
23. Ability to interface with all identified metering points for data collection
24. Ability to capture testing related parameters of equipment ‘s whose tests are carried out
Ability to transfer information from SCADA to collect real time parameters of key
25.
elements across multiple locations Clarification: Please refer
Ability to view precautionary steps / safety instructions to be followed for executing
26.
every work order as per Discom rules and regulatory requirements
27. Ability to upload the list of maintenance plan on system
System should support requirements for following types of maintenance for Power
Plants, Power Stations, DAM, Barrages, Offices, Staff colonies etc.: Electrical,
28.
Mechanical, Civil, Battery Bank Maintenance, Auxiliary Equipment Maintenance,
Powerhouse Store
29. Ability to prepare schedule of calibration for equipment
Ability to identify equipment which need periodic calibrations for ensuring accuracy and
30.
determining and defining the periodicity
Ability to define various parameters monitored can measuring points for that
31.
equipment.
32. Ability to view the list of pending maintenance plans
Ability to raise maintenance execution orders pending list as SMS alerts at defined
33.
intervals to concerned officials to assist proactive work plans
Ability to raise the flags to the concerned officials assigned for the work orders and
34.
Execution orders
Ability to help reviewing Maintenance Schedules execution orders as per geographical
35.
locations
Ability to allocate online, work to concerned department / group of personnel /
36.
individual
37. Ability to view job allocations for individual resources
Ability to reallocate field resources as per job requirement both for internal Employees
38.
of Discom or contract laborers
39. Ability to view the real-time location wise material availability
System should have the provision of a plant/equipment/component register at the
40. Operational level which provides a hierarchical view of equipment, components and sub-
components
Page 344 of 390

JPDCL

Ability to raise requisition to stores for issue of the material required for carrying out
41.
execution order
42. Ability to highlight in the requisition, the location wise material availability
Ability to send a purchase request to procurement / materials department if work needs
43. purchase of material (This should be raised after viewing the availability of the material
online)
44. Ability to upload the receipt of material required for work
Ability to generate a requisition for Permit to Work to isolate equipment for
45.
maintenance and forward the same online for Authorized Person ‘s approval.
46. Ability to receive approvals including Permit to Work online from the Authorized Persons
Ability to view all Permit to Work issued/outstanding on a piece of equipment or a
47.
system itself
48. System should have the ability to link plant/equipment to costs codes for costing
Ability to close all work permits issued on an equipment after completion of the job on
49.
it and inform about the same to all the concerned Officials online
50. Ability to record and archive all executed work permits
51. Ability to update the details of work carried out on a job in the system
Ability to update the details of material consumed in execution, in the Procurement and
52.
Materials Management System
53. Ability to generate PO (Purchase Order) for Labor contracts
54. Ability to enter routine testing results into system
Ability to define and create policies to raise alerts to control room and concerned in case
55.
of fault/issue or condition as defined by the concerned officials
System should have the ability to support short and long form entry of work request
56.
details
Ability to forward bills, PO, etc. to Finance with measurement book and other details for
57.
payment
Ability to maintain calibration report of instruments along with schedule & check for
58.
traceability to national standards
Ability to plan shut down of equipment for calibration and its impact on capacity
59.
planning and production processes
Ability to record calibration results / observations and produce calibration certificates in
60.
required formats
61. Ability to maintain and track history of calibration of all equipment within the plant
Ability to record Improvement required based on the loss analysis for the Overall
62.
Equipment Efficiency (OEE)
63. Ability to carry out Calculation on daily basis for OEE (Over all Equipment Efficiency)
Page 345 of 390

JPDCL

64. Ability to generate daily consumption report for energy services (like electricity, gas etc.)
Ability to maintain List of equipment & schedule for the equipment under statutory
65.
requirement
66. Ability to interact with equipment & Inventory Management System
67. Ability to manage defects throughout their lifecycle
68. Ability to allow an integrated approach for the rectification of faults
Ability to seamlessly integrate the defect management cycle - Fault recording,
69. maintenance planning, procurement of spares and services, closing of maintenance
orders, etc.
70. Ability to prepare a 'Fault-Analysis report' for the major breakdown
System should have the ability to generate hard copy work instructions on approval of a
71. work order including the printing of attachments such as check lists, method sheets,
specifications etc.
72. Ability to receive work orders from Procurement and Materials Management System
Ability to group the work order based on the nature of work like:
• Planned Maintenance
73.
• Breakdown / Emergency Maintenance
• Preventive Maintenance
74. Ability to send online request to higher Official for execution of work order
Ability to generate the list of maintenance execution orders received for the day / week
75.
/ month / user defined period
76. Ability to generate Labor requirement report for various maintenance works
Ability to generate the list of completed maintenance execution orders for the day /
77.
week / month / user defined period
Ability to generate report on the equipment utilization history and statistics of
78.
performance at given period
Ability to view the list of pending maintenance execution orders for the day / week /
79.
month / user defined period
Ability to view the details or reasons for specific pending maintenance jobs as a report
80.
for user defined period
Ability to calculate the cost of resources utilized for carrying out a job and generate it as
81.
a report
82. Ability to generate maintenance schedule report
Ability to generate reports for Planned Maintenance Vs. Achieved Maintenance for all
83.
types of maintenance jobs for user defined periods
Ability to generate cost of maintenance report for each equipment / group of equipment
84.
/ types of equipment or user defined sets
Page 346 of 390

JPDCL

Ability to automatically rearrange Preventive / Predictive Maintenance Schedules as and
85. when the previous activity is accomplished or due to problems like manpower shortage,
other unforeseen circumstances, etc.
Ability to view the list of all equipment which are due for inspection / maintenance based
86.
on chronology
87. Ability to generate a report on common equipment failures based on fault codes
Ability to generate a report with historical data of failures on an equipment over a set
88.
period
89. Ability to generate Preventive / Predictive Maintenance Plan and Overhaul Plan
90. Ability to generate Preventive / Predictive Maintenance Report of Lines (Electrical)
91. Ability to generate Preventive / Predictive Maintenance Report of Sub-Stations
Ability to escalate through a trigger to one ‘s senior Official if a Preventive / Predictive
92.
Maintenance activity is not carried out within the specified time frame
Ability to view the list of Preventive / Predictive Maintenance activities to be carried out
93.
in a specified period as a report
Ability to generate report on the equipment utilization history and statistics details of its
94.
performance
95. Ability to generate a comparative report detailing the list of Preventive / Predictive
Ability to use details of planned Preventive / Predictive Maintenance activities for
96.
resource allocation and scheduling
Ability to generate a report of missed out Preventive / Predictive Maintenance activities
97.
for a specified period
Ability to view as a report the detailed maintenance history of an equipment on which
98.
Preventive / Predictive Maintenance activity was carried out
99. Ability to aid in tracking down the cost incurred in breakdown Maintenance
100. Ability to generate a Progress Report and Status of Breakdown Maintenance
Ability to generate reports on emergency / breakdown reasons for each equipment /
101.
group of equipment / types of equipment for user defined periods
Ability to generate report on the equipment utilization history and statistics details of its
102.
performance
Ability to report common equipment / equipment failures and repair times based on the
103.
failure codes
Ability to generate a report detailing the resources utilized to restore breakdowns in a
104.
period
105. Ability to produce statistical report linking the cause of failures and the effects of failures
Ability to report equipment down time and group of equipment down time over a period
106.
including their fault codes
Page 347 of 390

JPDCL

107. Ability to generate detailed breakdowns reports and costs associated
108. Ability to generate Emergency /Breakdown Maintenance Report for Lines (Electrical)
109. Ability to generate Emergency / Breakdown Maintenance Report for Sub-Stations
Ability to flag triggers on the statutory maintenance activities to be carried out on certain
110.
equipment at specified predetermined period
111. Ability to view the previous statutory reports prepared on specified equipment
112. Ability to use earlier statutory reports as template for preparing new reports
Ability to update necessary details in the system after completion of statutory
113.
maintenance activities
Ability to generate reports as required by statutory authorities for a predetermined
114.
period on an equipment or on an equipment or on a system
Maintenance activities to be carried out and the actual Preventive / Predictive
115.
Maintenance activities carried out over a specified period
116. Ability for maintenance orders to be reviewed and technically closed
All materials, resources and other costs are directly reconcilable back to a maintenance
117.
notification and maintenance order.
The solution will enable the user to update the status of the maintenance order to
118.
indicate it can now be checked for completion prior to business close.
The solution will enable the user to indicate that a maintenance order is "technically
119.
closed".
The Solution will have the ability to capture and amend equipment, labor and material
120.
components to maintenance orders
Upon completion of Maintenance work, the updates should be recorded at equipment
121.
level along with the experiential and numerical feedback.
Upon completion of Fault work, the updates should be recorded at equipment level
122.
along with the experiential and numerical feedback.
123. The solution will allow a user to reschedule work that has not been started.
The solution will, if manual scheduling is permitted, allow the user to alter an
124. assignment. This may be to change dates, remove the individual from the job, assign a
new individual to the work, swap two individuals between assignments. Where the user
The solution will enable the minimum and team requirements to be sent with the
125.
request to the third party
126. Ability to confirm completion of activities against a maintenance order
127. The solution will allow the user to set the status of the Work Task to "ready to start".
The solution will enable the user to update Work task information to reflect the
128.
completion.
129. The solution will enable the user to inquire on work progress at maintenance order and
Page 348 of 390

JPDCL

Work Task level.
The Solution will have the capability to readily provide a list of open maintenance orders
130.
against an individual / work group
The Solution will have the capability to provide a list of open maintenance orders against
131.
a productive unit and its child equipment
It must be possible to identify defects found during an OHL inspection from a user-
132. friendly, equipment types specific list and for this to result in maintenance orders being
created/amended/closed based on specified rules.
133. The solution will provide the ability to update a maintenance order status
Capture activity of all Capex activities including Connections down to equipment class
134.
e.g., Distribution Switchgear, Transformer
OPEX high-volume, low-cost work to be captured by standard job (equipment & voltage)
135.
by activity e.g., Inspection, Civil work, Link boxes
OPEX maintenance activity on 132kV/11kV plant captured by equipment e.g.,
136.
transformer, Isolator, circuit breaker
137. Distribution Maintenance Module activity captured by activity / EGI / equipment
138. Fault activity captured by equipment
139. Ad Hoc work activity captured by equipment for high voltages and EGI for low voltages
140. Need to record in The Solution who i.e., own staff/contractor has carried out task
Need to be able to easily link cost in SAP to The Solution data to calculate unit costs at
141.
appropriate level
Work carried out during or following a storm period needs to be identifiable so that it
142. can be excluded from similar work done at other times so that it is not included in the
routine calculation of performance or returns to regulatory bodies.
The Solution will have the ability to follow different processes based on work type (e.g.,
143.
The Solution will have the ability to prioritize emergency work over other activities)
The Solution will have the Capability to capture Defects at equipment level, either
144.
manually or electronically from the Field
The Solution will have the ability to capture Follow-on work at equipment level, either
145.
manually or electronically from the Field users
The Solution will have the ability to track costs at an individual equipment level including
146. all maintenance order costs (equipment, Labor & materials) to enable whole equipment
lifecycle tracking
147. maintenance orders must be linked to the original maintenance notification
The solution will update, or allow the maintenance order Status to be updated to reflect
148.
the current position.
149. The solution will allow Work Tasks to be assigned individually within a maintenance
Page 349 of 390

JPDCL

order
150. The solution will allow maintenance orders to be comprised of individual work tasks
The solution will present a suggested list of possible Work Tasks for the maintenance
151. order based on the Work Type and pre-defined work templates. The user may select
from the list to create these or create new ones from scratch.
The solution will present suggested details for the selected maintenance order based on
152. the work templates and other information that was captured on the original
maintenance notification
The solution will update the expected end date of a Work Task that has already started,
153. this will be because of progress updates applied either automatically or manually. (This
will cause a reschedule)
The solution will enable templates for maintenance orders and Work tasks to be created
154.
and maintained.
155. The solution will allow a template to be based on another template.
The solution will allow a template to have a status that the user can update. There will
156. be a status representing "live" in which case the template will be offered as one of the
templates to base a work item on.
Requirement to hold civil equipment work and condition history in the solution
157.
equipment still under warranty will be flagged
Processes will support the need to ensure that only current data collection forms / scripts
158.
are in use.
For any unplanned work identified the originator will be identified on the maintenance
159.
order/ request.
Any inspection work completed as part of a fault restoration activity will be recorded in
160.
the solution.
The solution will provide the ability to raise maintenance orders for clean-up work.
161. Contamination history (including what clean-up works have been done) will form part of
the maintenance order. Free text notes can be added to the maintenance order.
Confined Spaces risk rating to be highlighted on maintenance orders raised against the
162.
relevant equipment (sites/buildings/tunnels/shafts) or their children equipment.
163. Ability for maintenance users to raise defects against equipment, subject to policy
Standard jobs will have the ability to hold a Priority, which is set when the job is raised,
164.
and is easily identifiable by Discom
165. The solution will allow multiple users to inspect the same group of equipment.
The solution will provide the ability to create new standard jobs to meet new business
166.
policy
User profile shall determine the level of access to create/modify/delete maintenance
167.
orders / Work requests
Page 350 of 390

JPDCL

The Solution will provide the ability for Control Engineers to have visibility of The Solution
168.
and raise ‗Work Requests ‘/ maintenance orders.
Solution must only allow maintenance orders to be generated if it is associated with a
169.
Site/Location or with an equipment or group of equipment
170. Ability to secure / reserve materials against maintenance orders
Ability to generate a Bill of Materials and associated requisitions / reservations from a
171.
designed maintenance notification
172. Ability to procure unavailable or nonstock materials / services from a maintenance order
Ability to plan all activities across the short, medium and long term (e.g., Resources,
173.
Availability of materials / services etc.)
174. Ability to manage and report on capacity planning
The solution will allow the duration and/or effort required for a Work Task to be updated
175.
(this will cause a reschedule).
Need to be able to identify whether work planned is using internal or external resources,
176.
to identify costs involved.
The maintenance & inspection plan will be made available to commit maintenance
177. orders. maintenance orders should be committed automatically when plan is approved
and committed
The Solution will have the ability to automate parts ordering process (i.e., part lists linked
178. to maintenance orders which are ordered automatically) or manually add parts or
services to a maintenance order which then initiates the appropriate purchasing pr
179. All Faults should be logged against a Site/Location or equipment
180. Solution must support Frequency based; Condition based Maintenance work
181. The solution must generate Inspection plans based on policies and be linked to policy
The solution must enable improved equipment Utilization, Planning & Operations to out-
182. perform agreed Regulatory targets. Viewing of target, forecast, scenario and actuals
must be possible
The solution will allow tracking of equipment, based on type, status, work/condition
183. history and location. (e.g., Grid and Primary Transformers which may be used at other
sites).
The solution will provide full equipment history covering all lifecycle activities. For
184.
example, commissioning, current location, status, date of birth and scrapping
All faults that affect the integrity / performance of an equipment will be recorded against
185.
that equipment in the equipment register.
186. The Reasons for plant change / replacement will be recorded against these equipment
187. Condition history will be retained against the equipment
188. The RCM strategy will be supported by the collection of failure data and equipment
Page 351 of 390

JPDCL

condition data held against the equipment.
Common statuses will be applied to equipment across the Discom for refurbishment /
189.
Strategic Spares etc. This will be supported by common processes.
190. Ability to generate alerts based on the schedule
191. Ability for creation & maintenance of master records for maintenance of equipment
192. Ability to create maintenance plan for equipment calibration
193. Ability to schedule maintenance Plan for equipment calibration
194. Ability to generate Preventive Schedule Overview Report
195. Ability to generate List for activities report for notification
196. Ability to generate equipment downtime analysis report
197. Ability to generate Cause and Effect Analysis Report
198. Ability to generate Material Goods Movement/Consumption Report
Ability to generate report on MTBF (Mean Time Between Failures) and MTTR (Mean
199.
Time to repair) for an equipment
200. Capability to monitor the attendance in accordance to resource deployment
Capability to generate the report includes information on key regulatory parameters for
201.
the specified period for Distribution, Transmission and Generation utilities of JPDCL.
202. Capability to scheduling the workers on periodically basis
203. Capability to assignment of inventory automatically and update the same.
Page 352 of 390

JPDCL
Consumer Service Management and Grievance Redressal

Ability to generate the unique application number in case of application submitted for
1.
new connection (Industrial & other than industrial both).
2. Ability to keep the tracking of unique application number generated
Ability to be integrated with the other sub-system and sync the data of Aadhar-based e-
3.
KYC.
Ability to provide the facility to upload the supporting files in PDF/Excel/Word/text
4.
format.
5. Capability to define the approval hierarchy and file movement based on the same.
Allow the authorized management person to Approve/Reject the application and in case
6.
of rejection, the reason must be provided
Capability to send the notification via email or any other mode to applicant if his
7.
application gets reject along with the rejection reason.
Capability to initiate the payment request automatically based on the unique application
8.
number.
Capable to mark the application status as closed automatically once the application is
9.
rejected
Capability to generate a new Connection ID against the Unique Application Number
10.
once the payment is successful
Capability of the followings in case of new connection post successful payment; but not
limited to:
11. • Initiate a notification to applicant regarding the details of connection including
Connection ID
• Generation of Output certificate automatically with new connection details
12. Capability to Issuance of bill for pre-paid meters
13. Capability to Issuance of No dues Certificate
Capability to calculate the fees and charges based on inputs provided for location and
14.
category of connection in case of shifting of connection.
Capability to calculate the fees and charges based on inputs provided for load and
15.
category of connection in case modification of load.
Capability to calculate the fees and charges based on inputs provided for load and
16.
category of connection in case of change of consumer category.
Capability of the following in case of change of consumer name Upon successful
processing of payment:
• Generation of a new Connection ID against the Unique Application Number.
17.
• Generation of output certificate with new connection details.
• Posting the output certificate with new connection details in the DigiLocker
account; if indicated.
Page 353 of 390

JPDCL

• Trigger a change of 'consumer name' in the system.
• Trigger an update to the Billing System for updation of consumer name
• Initiate notification to Applicant regarding the updates to consumer name.
Capability of the followings in case of modification of load post successful payment; but
not limited to:
• Trigger a change of value of load in the system.
18. • Trigger an update to the Billing System for updation of value of load and
associated billing parameters
• Initiate notification to Applicant regarding updation of value of load and
associated billing parameters.
Capability of the followings in case of shifting of connection post successful payment;
but not limited to:
19. • Trigger a change of 'address' in the ERP system.
• Trigger an update to the Billing System for updation of address
• Initiate notification to Applicant regarding the updates to connection address.
Capability of the followings in case of change of consumer category post successful
payment; but not limited to:
• Trigger a change of 'consumer category' in the ERP system.
20.
• Trigger an update to the Billing System for updation of billing parameters
• Initiate a notification to Applicant regarding the updates to consumer category
and associated billing changes.
Capability of the followings in case of transfer of ownership post successful payment:
• Generation of a new Connection ID against the Unique Application Number.
• Generation of output certificate with new connection details.
• Posting the output certificate with new connection details in the DigiLocker
21.
account; if indicated.
• Trigger a change of 'consumer name' in the system.
• Trigger an update to the Billing System for updation of consumer name
• Initiate notification to Applicant regarding the updates to consumer name
22. Capability to generate the Power Availability Certificate.
Capability to update the resolution of all customers grievance and integrate the same
23.
with the ERP.
24. Capability to track the status of consumer grievances
Capability to initiate the notification of long pending grievances to the concerned
25.
authority
Capability to provide the real time status of grievances to the higher management of
26.
JPDCL via dashboards/MIS report etc
Capability to initiate the notification to the higher authorities in case of any escalations
27.
by consumers
Page 354 of 390

JPDCL

28. Capability to update the status of the grievances
Capability to evaluation performance of the concerned authorities to whom grievances
29.
are raised
Capability to display the following for prepaid connections:
30. • Current balance
• Consumption history (details of consumption against preceding recharges)
Capability to provide the following details about the consumer profile:
• Name, Address, Registered Mobile Number, Registered Email ID
31.
• Connection details – consumer category, load contracted, type of meter, Solar PV
meters
Indicative list of Consumer Services expected to be configured:
• New Electricity Connection (Other than Industrial)
• New Electricity Connection (Industrial)
• Modification of Load
• Shifting of Connection
• Change of Consumer Category
• Change of Consumer Name
• Transfer of Ownership
• Bill payment
• Payment of other charges
• Submission of meter reading for billing
• Self-assessment of electricity bill
• Application for installation, interconnection and metering of distributed
32. renewable energy systems
• Request for duplicate copy of Bill
• Issuance of No dues Certificate
• Signing of Test Report for a grievance submitted (5.9)
• Issuance of bill for pre-paid meters
• Intimation of continued absence from residence
• Permanent disconnection of supply
• Self-assessment of benefits from roof top solar PV system
• Issuance of Certificate of Registration with JPDCL (for application for DG Set
Installation Approval)
• DG Set approval (from PDD)
• Power Availability Certificate NOC (from PDD)
• Electrical Fitness Certificate (from Chief Electrical Inspectorate, Jammu &
Kashmir)
Indicative list of Grievances expected to be configured:
• Shifting of Utilities
33. • Replacement of meter on account of meter reading not commensurate with his
consumption of electricity
• Replacement of meter on account of stoppage of meter
Page 355 of 390

JPDCL

• Replacement of meter on account of damage to the seal of the meter
• Replacement of meter on account of burning of the meter
• Replacement of meter on account of any other damage of the meter
• Dispute Test Report of Meter
• Replacement of stolen meter
• Non-receipt of bill
• Claim of rebate against delayed bill
• Claim of interest on advance payment made in case of intimated continued
absence from residence
• Delay in reconnection of supply after disconnection due to bill defaulting
• No supply beyond a duration specified by JPDCL (announced publicly)
• Number of interruptions in supply beyond the limits as specified by JPDCL
(announced publicly)
• Delay in providing connection
• Delay in processing disconnection
• Delay in processing reconnection
• Delay in processing shifting of connection
• Delay in processing change in consumer category
• Delay in processing change in load
• Delay in processing change in consumer details
• Delay in replacement of defective / stolen+H46 meters
• Complaint regarding voltage related issues (fluctuation, etc.)
• Delay in resolving voltage-related complaint
• Bill related complaints
• Delay in getting PAC (Power Availability Certificate)
• Delay in sanctioning of new connection (Domestic/Industrial)
• Delay in updating of prepaid account on the consumer or mismatch in updating
of prepaid account of the consumer
• Prepaid account not updated with balances
• Discrepancy in net billing
• Delay in construction of private electric infrastructure
• Delay in execution of depository contribution works (setting the electric
infrastructure)
Ability to provide report related to Consumer Service Rating of Discoms along with
34. Integrated Rating of Discoms as per formats specified by Ministry of Power through REC
website.
Page 356 of 390

JPDCL
Governance, Risk and Compliance
S. No. Requirement Specifications

Ability of the system to capture the Details of fines / penalties /punishment/ award/
compounding fees/ settlement amount paid in proceedings (by JPDCL or by directors /
KMPs) with regulators/ law enforcement agencies/ judicial institutions, in the financial year
List down all the fines/penalties, compounding fees and settlement fees along with the
following:
1. • The NGRBC principle they correspond to
• Name of the regulatory/enforcement/judicial institution against each penalty/fine
• Amount Paid (INR) against each penalty/fine
• Case in brief (summary)
• Has an appeal been preferred?
Ability of the system to disclosed in questions above and provide the details of the Appeal/
Revision preferred in cases where monetary or non-monetary action has been appealed,
2.
mention case summary as well as the Name of the regulatory/ enforcement agencies/
judicial institutions
Ability of the system to provide check does the entity have an anti-corruption or anti-bribery
3.
policy and provide a web-link to the policy
Ability of the system to capture the Number of Directors/KMPs/employees/workers against
4. whom disciplinary action was taken by any law enforcement agency for the charges of
bribery/ corruption.
Ability of the system to capture details of complaints regarding conflict of interest.
• Number of complaints received in relation to issues of Conflict of Interest of the
5. Directors
• Number of complaints received in relation to issues of Conflict of Interest of the
KMPs
Ability of the system to capture the details of any corrective action taken or underway on
6. issues related to fines / penalties / action taken by regulators/ law enforcement agencies/
judicial institutions, on cases of corruption and conflicts of interest.
Ability of the system to capture processes of entity in place to avoid/ manage conflict of
7.
interests involving members of the Board along with
Ability of the system to Describe the mechanisms to receive and redress grievances of the
8.
community.
Ability of the system to Describe the mechanisms in place to receive and respond to
9.
consumer complaints and feedback.
Ability of the system create and generate the turnover of products and/ services as a % of
turnover from all products/service that carry information about:
10. • Environmental and social parameters relevant to the product
• Safe and responsible usage
• Recycling and/or safe disposal
11. Ability of the system to generate the unique complaint number of complaints in respect
Page 357 of 390

JPDCL

(Financial Year-wise):
• Data privacy
• Advertising
• Cyber-security
• Delivery of essential services
• Restrictive Trade Practices
• Unfair Trade Practices
• Other
Ability of the system to capture the details of instances of product recalls on account of
safety issues:
12.
• Voluntary Recalls
• Forced Recalls
Ability of the system to register Complaints/Grievances on any of the 09 NGBRC Principles
• Complaints by Investors; Communities; Shareholders; Employees and workers;
13. Customers; Value Chain Partners; Other
• Whether the Grievance Redressal Mechanism in Place
• Number of complaints pending resolution at close the financial year
Ability of the system to capture JPDCL’s framework/ policy on cyber security and risks related
14.
to data privacy along with provide a web-link of the policy
Ability of the system to provide details of followings:
• Any corrective actions taken or underway on issues relating to advertising, and
delivery of essential services;
15.
• Cyber security and data privacy of customers; re-occurrence of instances of product
recalls;
• Penalty / action taken by regulatory authorities on safety of products / services.
Ability of the system to capture the Channels / platforms where information on products
16.
and services of the entity can be accessed.
Ability of the system to capture the steps taken to inform and educate consumers about safe
17.
and responsible usage of products and/or services
Ability of the system to capture Mechanisms in place to inform consumers of any risk of
18.
disruption/discontinuation of essential services
Does JPDCL display product information on the product over and above what is mandated
19.
as per local laws? (Yes/No/Not Applicable) If yes, provide details in brief.
Did JPDCL carry out any survey with regard to consumer satisfaction relating to the major
20. products / services of the entity, significant locations of operation of the entity or the entity
as a whole? (Yes/No)
Ability of the system to provide the following information relating to data breaches:
21. • Number of instances of data breaches along-with impact
• % of data breaches involving personally identifiable information of customers
Page 358 of 390

JPDCL
Document Management System

A. General
The system shall support separate Document/Image server for better management of
22.
documents and store only metadata information in database.
23. The proposed System should be available on Micro Services based architecture.
24. The proposed DMS system should be compliant to ODMA, WebDev, CMIS open standards.
B. Document Capturing / Scanning Solution
Solution should provide an integrated scanning engine with capability for centralized and
1.
decentralized Scanning & Document Capturing.
The scanned documents shall be converted into any of the standard file formats such as
2.
PDF/ JPEG/ RTF/PNG or other standard formats.
All the pages of a single digital file will have to be stitched together to generate an exact
3. replica of the physical file. The stitched document should be represented in a PDF format
or any other standard format.
The proposed solution should provide for automatic correction of parameters like format/
4. compression not proper, skew, wrong orientation, error in automatic cropping, punch
hole marks etc. during scanning.
The quality of scanned images shall be enhanced to the optimum level such as skew, de-
5.
skew to make the image straight.
It shall be possible to carry out cropping and cleaning of images like removal of black noise
6.
around the text, providing equal margins around the text.
The scanning solution should provide support for automatic document quality analysis so
7.
that any bad quality document does not get uploaded to the repository.
C. Document Management System
The System shall support categorization of documents in folders-subfolders just like
1. windows interface. There should not be any limit on the number of folder and levels of sub
folder
2. The System shall support integration with Email Servers for user intimation purpose.
The system shall provide search facility to in the same interface, so that users are able to
3.
search the documents to be linked
4. The system shall support versioning of documents with facility to write version comments.
The system shall allow Locking of documents for editing and importing it back into the
5.
system through check-in/Check-out features
6. Repository should be format agnostic.
Proposed Document Management System should have in-built maker-checker based
7. linear workflow facility for document review, approval / rejection before archival in DMS
repository.
Page 359 of 390

JPDCL

The proposed DMS application should have the capability to integrate with the existing
8.
Unified Billing System (UBS) being implemented currently.
The proposed DMS application should have in-built viewer for viewing digitized
9.
documents inside the application.
10. Support archival & view of PDF format documents.
The in-built viewer should support comprehensive annotation features like highlighting,
marking text, underlining putting sticky notes on documents, and support for text and
11.
image stamps etc. The system shall support automatic stamping of annotations with
username, date and time of putting annotations.
12. The system shall provide facility for securing annotations for selective users.
The System shall provide facility to index folders, files and documents on user-defined
13.
indexes
The system shall provide extensive search facility to retrieve documents or Folders/Files.
14. Solution should have search facility based on system defined, user defined index
parameters as well as Content based / Full Text search.
15. The system should be certified to Record Management standard.
16. The system shall support saving of search queries and search results.
The Document management system should have in-built User Management module that
17.
shall support definition of Users, Groups and Roles relation in the system
The system shall support multiple levels of access rights (Delete/ Edit/ View/ Print/ Copy or
18.
Download).
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,
19.
locking of user-id after three un-successful attempts, password expiry, password history so
that passwords are not same as previous passwords etc.
The system shall provide LDAP support for integrating with directory services and shall
20.
support single sign on
The system shall support web-based administration module for the complete
21.
management of system.
The system shall support Extensive Audit-trails at user, Folder and Cabinet levels and it shall
22. provide facility to generate Audit trails on separate actions, and between specific
date/times
The system should have the capability to set automatic reminders and alarms to
23.
concerned users.
The system should be based on open standards and have API support for data import &
24.
export.
Page 360 of 390

JPDCL
Page 361 of 390

JPDCL
Page 362 of 390

JPDCL
PART II
CONTRACT FORM AND CONDITIONS OF CONTRACT
Draft Contract for
Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain

Between
AND
[ SELECTED BIDDER]
Note: This is draft of contract to be signed with the selected bidder. The terms and conditions of
the contract shall be finalized at the time of signing of the contract
Page 363 of 390

JPDCL
Section 7. Conditions of Contract

A. General Conditions of Contract
1. Definitions and Interpretations
(a) Definitions
1.1. In this Contract, unless the context otherwise requires, the following words, expressions and
abbreviations shall have the following meanings:
(a) “Affected Party” means any of the ERPSI or the Utility whose performance has been affected
by an event of Force Majeure or Force Majeure Event;
(b) “Applicable Laws” shall mean the laws and any other instruments having the force of law in
India as they may be issued and in force from time to time;
(c) “Bid” means the bid submitted by the Bidder(s) in response to the RFP and shall include the
Technical Bid and the Financial Bid;
(d) “Bidder(s)” means individual entity or consortium of entities bidding in response to the RFP;
(e) “Change Order” shall have the meaning as ascribed thereto in Article 14 of this Contract;
(f) “Consortium Member” Any member of the bidding consortium other than the ERPSI-Lead;
(g) “Contract” or “ERPSI Contract” shall mean this Contract entered into between, Selected
Bidder(represented by the ERPSI-Lead acting for and on behalf of the consortium if the
Selected Bidder is a consortium) and the Utility for undertaking the ERP Project and is the
legally binding written agreement signed by the Parties and which includes all the attached
documents listed in its paragraph 1 of the Form of Contract (the General Conditions (GCC),
the Special Conditions (SCC), and the Appendices, Attachments, Annexures etc.).
(h) “Contract Period” or “Term of the Contract” shall have the meaning as ascribed in this Contract;
(i) “Contract Price” shall have the meaning as ascribed thereto in Article 4.1 of this Contract;
(j) “Day” means a calendar day unless indicated otherwise;
(k) “Enterprise Resource Planning” or “ERP” refers to the software used to manage a company‘s
financials, accounts, inventory, projects, reporting and human resources. The functional
blocks of ERP typically include the ERP software, Cloud-based Data Centre (DC) and Disaster
Recovery Centre (DRC), and the Communication Network (SD-WAN);
(l) “Enterprise Resource Planning System Integrator” or “ERPSI”, means the responsible
implementation agency named in SCC appointed by Utility for the Selection of System
Integrator (ERPSI) to Design, Develop, Implement and Maintain Enterprise Resource Planning
(ERP) Solution on Cloud at the Utility and its offices upon execution of the Contract
subsequent to the Letter of Award referred to in SCC;
(m) “Exit Management Period” shall mean the transition period encompassing the time from the
date of termination of the Contract or end of the Contract Period until the date upon which
all transition activities/ services are completed by the ERPSI;
(n) “Force Majeure” or “Force Majeure Event” shall have the meaning as ascribed thereto in Article
8 of this Section;
Page 364 of 390

JPDCL
(o) “GCC” means these General Conditions of Contract.

(p) “Goods” means any good(s) supplied or to be supplied as a part of the Solution by the ERPSI;
(q) “Independent Valuer” shall mean a qualified valuer duly registered under Companies
(Registered Valuers and Valuation) Rules, 2017 for Plant and Machinery and jointly appointed
by the Parties in the event of termination prior to Installation Milestone;
(r) “Lender” means the banks, financial institutions, multilateral funding agencies, non-banking
financial companies registered with the Reserve Bank of India (RBI), insurance companies
registered with the insurance Regulatory & Development Authority (IRDA), pension funds
regulated by the Pension Fund Regulatory & Development Authority (PFRDA), mutual funds
registered with Securities & Exchange Board of India (SEBI), etc., including their successors
and assigns, who have agreed to provide the ERPSI with the debt financing, and any successor
banks or financial institutions to whom their interests may be transferred or assigned;
(s) “Month” means a calendar month unless indicated otherwise;
(t) “Operational/Pilot Go Live” shall have the meaning ascribed thereto in Section 6 of the RFP
(u) “Operational Period” means the period from the Operational Go-Live till the end of the
Contract Period;
(v) “Project or ERP Implementation Project” means the Utility‘s ERP Implementation Project
defined in recital clause in the Contract Form;
(w) “Project Implementation Schedule” shall have the meaning ascribed thereto in Section 6;
(x) “Request for Proposal” or “RFP” means the Tender of which the number, name and details
have been mentioned in SCC, including all its Volumes/ Sections/ Forms/ Annexures/
Appendices etc., for Appointment of ERPSI (including all clarification/ addendum/
amendment/ corrigendum/ etc. issued from time to time);
(y) “Rupees” or “Rs.” Or “INR” or “₹ means Indian Rupees;
(z) “SCC” means the Special Conditions of Contract by which the GCC may be amended or
supplemented.
(aa) “Service(s)” or “Related Service(s)” means any service(s) performed or to be performed as a
part of the Solution by the ERPSI;
(bb) SLA Default Notice means notice to be issued by the Utility in the event ERPSI fails meet any
of the criteria specified in the SLA for cumulatively 3 (three) months in past 6 (six) months so
as to entitling levy of maximum penalty for such criteria;
(cc) “Solution” shall mean the ERP system implemented in its entirety including but not limited to
the designing, financing, supply of hardware, software, transportation, installation,
integration, testing, commissioning, operation, maintenance, training, and other services by
the ERPSI;
(dd) “Termination Payment” shall have the meaning as ascribed thereto in Article 10 of GCC in
Section 7;
(ee) “Utility” shall have the same meaning as ascribed to it in the recital clause of the Form of
Contract.
Page 365 of 390

JPDCL
(b) Interpretation
1.2. In the interpretation of this Contract, unless the context otherwise requires:
1.2.1 Unless otherwise specified a reference to an Article number is a reference to all of its sub-
articles;
1.2.2 Unless otherwise specified a reference to a clause, subclause or section is a reference to a
clause, sub-clause or section of this Contract including any amendments or modifications to
the same from time to time;
1.2.3 A word in the singular includes the plural and a word in the plural includes the singular;
1.2.4 A word importing a gender includes any other gender;
1.2.5 A reference to a person includes a partnership and a body corporate;
1.2.6 A reference to legislation includes legislation repealing, replacing, or amending that
legislation;
1.2.7 Where a word or phrase is given a particular meaning, it includes the appropriate grammatical
forms of that word or phrase which has a corresponding meaning;
1.2.8 In the event of an inconsistency between the terms of the RFP, Bid submitted by the Selected
ERPSI and the subsequent Contract, the terms of the Contract hereof shall prevail;
1.2.9 Whenever a material or article is specified or described by the name of a particular brand,
manufacturer or trademark, the specific item shall be understood as establishing type,
function, and quality desired. Products of other manufacturers may also be considered,
provided sufficient information is furnished so as to enable Utility to determine that the
products are equivalent to those named.
1.2.10 No amendment or other variation of this Contract shall be valid unless it is in writing, is dated,
expressly refers to this Contract, and is signed by a duly authorised representative of both
Utility and the ERPSI thereto.
2. The Contract
(a) Effectiveness and Term
2.1. EFFECTIVENESS AND TERM
2.1.1 This Contract shall come into force and effect on the date of execution of the Contract by the
Parties;
2.1.2 Unless terminated earlier by either Party or extended by the Utility in accordance with the
terms of this Contract, this Contract shall continue in full force and effect until the earlier of
(a) 5 (five) years from the date of execution of the Contract
2.1.3 The Utility, at its own discretion, may extend the operation and maintenance period of the
ERP system at terms mutually agreed upon with the ERPSI.
3. Rights, Title and Interest to ERP System and Equipment

3.1. The ownership, rights and title to the ERP system and other equipment installed by ERPSI for
operation of the ERP system pursuant to this Contract shall vest with Utility during the entire
Term of Contract and post expiry of Contract.
Page 366 of 390

JPDCL
4. Contract Price and Payment

(a) Payment Mechanism
4.1 PAYMENT MECHANISM
4.1.1 The payment shall be made to the ERPSI in Indian Rupees (INR) only
4.1.2 Except in case of Change Order in accordance with Article 13 of this Contract, the sum total of
all payments made to the ERPSI shall not exceed the Contract Price quoted in Article 4.1.1
4.1.3 The actual payment shall be net of any applicable liquidated damages and/or penalty due to
noncompliance of SLAs by the ERPSI.
4.1.4 ERPSI will raise and deliver the invoice and the Deliverables mentioned in this RFP. ERPSI shall
also raise a supplementary invoice for the agreed amount towards software change
requests/new requirements completed in the previous month, in accordance with Article 13.1 of
this Contract. Utility will review the ERPSI invoice raised by the ERPSI and the Deliverables
including the SLA performance report, in accordance with Article 7, within 21 (Twenty-One)
working days from the invoice and SLA performance report delivered by the ERPSI. The disputed
amount, (related to penalty imposed due to non-compliance of SLAs, and liquidated damages),
shall be dealt as terms and conditions of the Contract.
4.1.5 In the event the ERPSI fails to meet a particular performance criterion as mentioned under the
Service Level Agreement (SLA) specified in Section 6 for cumulatively 3 (three) months in past 6
(six) months, resulting in the maximum penalty for the performance criterion, Utility may issue
an SLA Default Notice to the ERPSI directing it to take steps within 90 days to comply with the
performance criterion specified in the SLA.
4.1.6 The JPDCL to release payments within 45 calendar days of the date of the invoice.
(b) Taxes and Duties
4.2 TAXES AND DUTIES
4.2.1 For Goods whether supplied from or outside India, the ERPSI shall be entirely responsible for
all taxes, duties, stamp duties, license fees, and other such levies imposed outside India.
4.2.2 Any statutory increase or decrease in the taxes and duties including GST and Cess as applicable
or in the event of introduction of new tax/cess or cessation of existing tax/cess subsequent to
the ERPSI‘s offer on the goods and services explicitly mentioned in financial bid shall be dealt
with in accordance with provisions of Change in Law.
4.2.3 Notwithstanding anything above or elsewhere in the Contract, in the event that the input tax
credit of the GST charged by the ERPSI is denied by the tax authorities to the Utility for reasons
attributable to the ERPSI, the Utility shall be entitled to recover such amount from the ERPSI by
way of adjustment from any of the subsequent invoices submitted by the ERPSI to the Utility.
5. Performance Security
5.1 The ERPSI has furnished Performance Security in the form of an irrevocable bank guarantee valid
up to a period of 6 (six) months beyond the end of the Contract Period or extended thereafter, for
the amount indicated in the RFP. However, in case of delay in Installation Milestone, the validity
of the initial Performance Security shall be extended by the period of such delay. In the event
Page 367 of 390

JPDCL
delay is solely due to acts and/ or omission of the Utility cost of extending the validity of
Performance Security shall be reimbursed to the ERPSI by the Utility.
5.2 Any payments shall be made to the ERPSI only after receipt of the initial Performance Security by
Utility.
5.3 Upon Termination of the Contract due to Utility Event of default or expiry of the Contract Period,
the separate Performance Security shall be discharged by Utility without any interest and returned
to the ERPSI not later than 14 (fourteen) working days following the date of Termination of the
Contract.
5.4 Upon Termination of the Contract due to ERPSI Event of default, the Performance Security shall
be forfeited by Utility.
5.5 In case of any delay by the ERPSI in performing the activities of the scope of work with respect to
the Project Implementation Schedule, then upon Utility‘s request, the ERPSI shall extend the
validity of the separate Performance Security for the period for which the Contract is extended.
In the event delay is solely due to acts and/ or omission of the Utility cost of extending the validity
of separate Performance Security shall be reimbursed to the ERPSI by the Utility.
6. Liquidated Damages, Penalty, and Incentive
6.1 Subject to Force Majeure, if ERPSI fails to complete the entire works before the scheduled
completion date or the extended date or if Bidder repudiates the Contract before completion of
the Work, the Purchaser may without prejudice to any other right or remedy available to the
Purchaser as under the Contract:
a. Recover from ERPSI, as liquidated damages a sum equivalent to 0.5% of the Contract Value
for each week delay beyond the Scheduled completion date or part thereof, subject to a
maximum of 10% of “Work Order Value”. For the purpose of liquidated damages, the
scheduled completion date shall be taken as “Effective Date of Go-Live”.
AND/OR
b. Terminate the Contract or a portion or part of the work thereof. The Purchaser shall give 30
days’ notice to ERPSI of its intention to terminate the Contract and shall so terminate the
Contract unless during the 30 days’ notice period, ERPSI initiates remedial action acceptable
to the Purchaser.
6.2 The Purchaser may without prejudice to its right to effect recovery by any other method, deduct
the amount of liquidated damages from any money belonging to ERPSI in its hands under this
Contract only (which includes the Purchaser’s right to claim such amount against Bidder’s Bank
Guarantee) or which may become due to ERPSI. Any such recovery or liquidated damages shall
not in any way relieve ERPSI from any of its obligations to complete the work or from any other
obligations and liabilities under the Contract.
6.3 Delay not attributable to ERPSI shall be considered for exclusion for the purpose of computing
liquidated damages
7. SLAs and SLA Audit
7.1 The ERPSI shall be liable to penalties in the event of non-compliance of Service Level Agreements,
as specified in Section 6;
7.2 A designated team/ person from Utility may review the system generated SLA performance report
of ERPSI each month. The review/ audit report will form basis of any action relating to imposing
penalty on or breach of Contract of the ERPSI.
Page 368 of 390

JPDCL
7.3 In case, there is no review/ audit report submitted within 25 (Twenty-Five) working days of every
month, it shall be deemed that all SLAs were met in the previous month.
8. Force Majeure
(a) Force Majeure Event
8.1 A Force Majeure means any event or circumstance or combination of events and circumstances
including those stated below that wholly or partly prevents or unavoidably delays an Affected
Party in the performance of its obligations under this ERPSI Contract, but only if and to the extent
that such events or circumstances are not within the reasonable control, directly or indirectly, of
the Affected Party and could not have been avoided if the Affected Party had taken reasonable
care or complied with prudent utility practices:
a) Natural Force Majeure Events: act of God, including, but not limited to drought, fire, and explosion
(to the extent originating from a source external to the site), earthquake, epidemic, volcanic
eruption, landslide, flood, cyclone, typhoon, tornado, or exceptionally adverse weather
conditions,
b) Non-Natural Force Majeure Events:
i. Direct Non–Natural Force Majeure Events
a. Nationalization or compulsory acquisition by any Governmental instrumentality of any material
assets or rights of the ERPSI; or
b. the unlawful, unreasonable or discriminatory revocation of, or refusal to renew, any Consents,
Clearances and Permits required by the ERPSI to perform their obligations under the Contract or
any unlawful, unreasonable or discriminatory refusal to grant any other Consents, Clearances and
permits required for the development/ operation of the Project, provided that a Competent Court
of Law declares the revocation or refusal to be unlawful, unreasonable and discriminatory and
strikes the same down; or
c. any other unlawful, unreasonable, or discriminatory action on the part of any Governmental
instrumentality which is directed against the Project, provided that a competent Court of law
declares the action to be unlawful, unreasonable, and discriminatory and strikes the same down.
d. any partial or complete shut-down of the internet services in the Project area
e. Shortage of labour, materials, or utilities where caused by circumstances that are themselves Force
Majeure
f. Restrictions imposed by central or state government that prevent or delay project execution
ii) Indirect Non - Natural Force Majeure Events:
1.1 an act of war (whether declared or undeclared), invasion, armed conflict or act of foreign enemy,
blockade, embargo, riot, insurrection, terrorist or military action, civil commotion, or politically
motivated sabotage; 13.5 radioactive contamination or ionizing radiation originating from a source
in India or resulting from any other Indirect Non-Natural Force Majeure Event mentioned above,
excluding circumstances where the source or cause of contamination or radiation is brought or has
been brought into or near the Site by the Affected Party or those employed or engaged by the
Affected Party; or 13.6 industry wide strikes and labour disturbances, having a nationwide impact
in India.
Page 369 of 390

JPDCL
(b) Force Majeure Exclusions

8.2 FORCE MAJEURE EXCLUSIONS
8.2.1 Force Majeure shall not include (i) any event or circumstance which is within the reasonable
control of the Parties and (ii) the following conditions, except to the extent that they are
consequences of an event of Force Majeure:
i. Unavailability, late delivery, or changes in cost of the machinery, equipment, materials, spare parts
etc. for the Project;
ii. Delay in the performance of any Contractors or their agents; Non-performance resulting from
normal wear and tear typically experienced in transmission materials and equipment;
iii. Strikes or labour disturbance at the facilities of the Affected Party;
iv. Insufficiency of finances or funds or the ERPSI Contract becoming onerous to perform; and
v. Non-performance caused by, or connected with, the Affected Party‘s:
a. negligent or intentional acts, errors, or omissions;
b. failure to comply with an Indian Law; or
c. breach of, or default under this ERPSI Contract or any Project documents.
(c) Notification of Force Majeure Event
8.3 NOTIFICATION OF FORCE MAJEURE EVENT
8.3.1 The Affected Party shall give notice to the other Party of any event of Force Majeure as soon as
reasonably practicable, but not later than 7 (seven) days after the date on which such Party knew
or should reasonably have known of the commencement of the event of Force Majeure. If an
event of Force Majeure results in a breakdown of communications rendering it unreasonable to
give notice within the applicable time limit specified herein, then the Party claiming Force
Majeure shall give such notice as soon as reasonably practicable after reinstatement of
communications, but not later than 1(one) day after such reinstatement. Provided that such
notice shall be a pre-condition to the Affected Party‘s entitlement to claim relief under this ERPSI
Contract. Such notice shall include full particulars of the event of Force Majeure, its effects on
the Party claiming relief and the remedial measures proposed. The Affected Party shall give the
other Party regular reports on the progress of those remedial measures and such other
information as the other Party may reasonably request about the Force Majeure.
8.3.2 The Affected Party shall give notice to the other Party of (i) the cessation of the relevant event
of Force Majeure; and (ii) the cessation of the effects of such event of Force Majeure on the
performance of its rights or obligations under this ERPSI Contract, as soon as practicable after
becoming aware of each of these cessations.
(d) Duty to Perform and Duty to Mitigate
8.4 DUTY TO PERFORM AND DUTY TO MITIGATE
8.4.1 To the extent not prevented by a Force Majeure Event, the Affected Party shall continue to
perform its obligations as provided in this ERPSI Contract. The Affected Party shall use its
reasonable efforts to mitigate the effect of any event of Force Majeure as soon as practicable.
(e) Available Relief for a Force Majeure Event
8.5 AVAILABLE RELIEF FOR A FORCE MAJEURE EVENT
8.5.1 Subject to this Article 8
Page 370 of 390

JPDCL
a. no Party shall be in breach of its obligations to the extent that the performance of its obligations
was prevented, hindered, or delayed due to a Force Majeure Event;
b. every Party shall be entitled to claim relief for a Force Majeure Event affecting its performance in
relation to its obligations under this ERPSI Contract;
c. The ERPSI shall be entitled to receive payment at rates to be mutually agreed between the Utility
and the ERPSI for the additions to the scope of work due to an event of force majeure.
9. Intellectual Property
9.1 All Intellectual Property Rights in all material (including but not limited to all Source code, Object
code, records, reports, designs, application configurations, data and written material, products,
specifications, reports, drawings and other documents), which have been newly created and
developed by the ERPSI solely during the performance of Related Services and for the purposes of
inter-alia use or sub-license of such services under this Contract, shall be the property of the ERPSI.
The ERPSI undertakes to disclose all such material, which have been newly created and developed
by the ERPSI solely during the performance of Related Services and for the purposes of inter-alia
use or sub-license of such services under this Contract, to the Utility. The ERPSI hereby grants to
Utility a, non‐ exclusive, non-transferable, irrevocable, royalty‐ free license to use all material
disclosed to the Utility under the Contract. Nothing contained herein shall be construed as
transferring ownership of any Intellectual Property Right from the ERPSI to the Utility.
9.2 The ERPSI shall ensure that while it uses any software, hardware, processes, document or material
in the course of performing the Services, it does not infringe the Intellectual Property Rights of
any person and the ERPSI shall keep the Utility indemnified against all costs, expenses and
liabilities howsoever, arising out any illegal or unauthorized use (piracy) or in connection with any
claim or proceedings relating to any breach or violation of any permission/license terms or
infringement of any Intellectual Property Rights by the ERPSI or its personnel during the course of
performance of the Related Services. In case of any infringement by the ERPSI, the ERPSI shall
have sole control of the defence and all related settlement negotiations
9.3 Subject to Article 9, the ERPSI shall retain exclusive ownership of all methods, concepts, algorithms,
trade secrets, software documentation, other intellectual property or other information belonging
to the ERPSI that existed before the date of execution of the Contract.
10. Termination
(a) ERPSI Event of Default
10.1.1 ERPSI Event of Default means any of the following events arising out of any acts or omission of
ERPSI, its representative, sub-contracts, employees and which have not occurred solely as a result
of any breach of this Contract by the Utility or due to Force Majeure, and where ERPSI has failed
to remedy these events within a period of 30 (Thirty) days of issuance of a notice by Utility
requiring ERPSI to remedy such event.
a. ERPSI has failed to procure and arrange requisite finances for the implementation of the Project;
b. ERPSI abandons the implementation of the Project or repudiates this Contract or otherwise takes
any action, or evidences or conveys an intention not to be bound by the Contract;
c. ERPSI, in the judgment of Utility has engaged in corrupt, fraudulent, collusive, or coercive practices,
in competing for or in executing the Contract; or
Page 371 of 390

JPDCL
d. ERPSI is adjudged bankrupt or insolvent, or if a trustee or receiver is appointed for ERPSI or for the
whole or material part of its assets that has a material bearing on its ability to implement the
Project;
e. ERPSI has been, or is in the process of being liquidated, dissolved, wound-up, amalgamated or
reconstituted in a manner that in the reasonable opinion of Utility would adversely affect ERPSI‘s
ability to implement the Project;
f. A resolution for winding up of ERPSI is passed, or any petition for winding up of ERPSI is admitted by
a court of competent jurisdiction and a provisional liquidator or receiver is appointed and such
order has not been set aside within 90 (Ninety) days of the date thereof or ERPSI is ordered to be
wound up by a court of competent jurisdiction;
g. In the event ERPSI fails to cure the default as indicated in the SLA Default Notice within the time
period specified therein; Failure of ERPSI to furnish Performance Security in accordance with the
provisions of this Contract;
h. Failure or inordinate delay by ERPSI to provide Solution as per Contract;
i. Any representation or warranty made by the ERPSI during the term of the Contract is found to be
false and/or misleading;
j. Failure on account of ERPSI to abide by Applicable Laws and regulations;
k. The shareholding of the ERPSI ceases to be in accordance with the provisions of this Contract;
l. No person having System Integration (ERPSI) experience in terms of the RFP remains a shareholder
of the ERPSI;
m. In the event equipment installed or proposed to be installed by the ERPSI is found to have any
embedded malware/ trojans/ cyber threat;
n. ERPSI fails to comply with the local content requirement as specified in the Bid Submission;
o. ERPSI fails to comply with any of its material obligations under this Contract.
p. In the event the Solution supplied do not meet the minimum specifications as per the Contract, and
the same is not replaced/ modified by the ERPSI to meet the requirements within 14 (fourteen)
working days of being informed by Utility, or as mutually decided between Utility and ERPSI.
(b) Utility Event of Default
10.2.1 Utility Event of Default means any of the following events, unless such event has occurred as a
consequence of the ERPSI Event of Default or a Force Majeure event and where Utility has failed
to remedy these events within a period of 90 (ninety) days of issuance of a notice by ERPSI
requiring Utility to remedy such event:
a. Utility is adjudged bankrupt or insolvent, or if a trustee or receiver is appointed for Utility or for the
whole or material part of its assets that has a material bearing on its ability to perform its
obligations under this Contract;
b. Utility has been, or is in the process of being liquidated, dissolved, wound-up, amalgamated or
reconstituted in a manner that in the reasonable opinion of ERPSI would adversely affect Utility‘s
ability to perform its obligations under this Contract;
c. A resolution for winding up of Utility is passed, or any petition for winding up of Utility is admitted
by a court of competent jurisdiction and a provisional liquidator or receiver is appointed and such
order has not been set aside within [90 (Ninety)] days of the date thereof or Utility is ordered to
be wound up by a court of competent jurisdiction;
Page 372 of 390

JPDCL
d. The breach by Utility of its obligations under this Contract which has an adverse effect on the
performance of ERPSI‘s obligations under this Contract.
(c) Termination for ERPSI Event for Default
10.3 TERMINATION FOR ERPSI EVENT FOR DEFAULT
10.3.1 Without prejudice to any other right or remedy which Utility may have in respect thereof under
this Contract, upon the occurrence of ERPSI Event of Default, Utility shall be entitled to
terminate this Contract in the manner provided in Article 10.3.2.
10.3.2 Utility shall issue a Preliminary Notice to ERPSI providing 90 (Ninety) Days, or such extended
period as the Utility may allow, to cure the underlying Event of Default. If ERPSI fails to cure the
underlying Event of Default within such period allowed, Utility shall be entitled to terminate this
Contract by issuing a termination notice to ERPSI.
(d) Termination for Utility Event of Default
10.4 TERMINATION FOR UTILITY EVENT FOR DEFAULT
10.4.1 Without prejudice to any other right or remedy which ERPSI may have in respect thereof under
this Contract, upon the occurrence of a Utility Event of Default, ERPSI shall be entitled to
terminate this Contract in the manner provided in Article
10.4.2 ERPSI shall issue a Preliminary Notice to Utility providing 90 (Ninety) Days, or such extended
period as the ERPSI may allow, to cure the underlying Event of Default. If Utility fails to cure the
underlying Event of Default within such period allowed, ERPSI shall be entitled to terminate this
Contract by issuing a termination notice to Utility.
(e) Consequences of Termination
10.5 CONSEQUENCES OF TERMINATION
Upon Termination of the Contract, the ERPSI shall:
10.5.1 Notwithstanding anything to the contrary contained in this Contract, any termination of this
Contract pursuant to its term shall be without prejudice to accrued rights of any Party, including
its right to claim and recover damages and other rights and remedies which it may have in law
or contract. All accrued rights and obligations of any of the Parties under this Contract, shall
survive the termination of this Contract to the extent such survival is necessary for giving effect
to such rights and obligations.
10.5.2 Following issue of the Termination Notice by Utility or ERPSI, Utility takes possession and
control of ERPSI‘s control room and call centre, and the exclusivity granted to ERPSI under Article
4 will come to an end.
10.5.3 Upon termination of this Contract by Utility or ERPSI on account of ERPSI‘s Event of Default (in
accordance with Article 10.1.1, or termination of this Contract on account of Utility‘s event of
default (in accordance with Article 10.2.1), ERPSI shall be entitled to a termination payment
subject to proper transfer of the installed ERP System, as agreed upon mutually. Upon
termination of this Contract by Utility or ERPSI on account of ERPSI‘s Event of Default (in
accordance with Article 10.1.1), or termination of this Contract on account of Utility‘s event of
default (in accordance with Article 10.2.1), ERPSI shall be entitled to raise a supplementary
invoice for an amount which is equal to the termination payment. The Supplementary invoice
shall be paid separately by the Utility within 30 (thirty) days from the date of such invoice.
10.5.4 The Termination payment value would be calculated basis the following mechanism:
Page 373 of 390

JPDCL
a. The present value of the receivables for the ERP system installed at Utility offices shall be calculated
by multiplying the outstanding payments towards the ERP system integrated and operationalized
as on the date of termination and discounting the same as on date of termination at the percentage
specified in SCC (Present Value).
b. All amounts due, but not paid by the Utility, including the aggregated amount due to be paid
including amount due to be paid towards supplementary invoice, but not paid or recovered from
the Utility, for the ERP system operations and maintenance as defined in the RFP by the ERPSI, shall
be calculated and factored in to arrive at the net outstanding receivables of the ERPSI (Outstanding
Receivables );
c. All amounts due, but not paid by the ERPSI, including the aggregated applicable liquidated damages
and/(or) penalties due to non-compliance of SLAs by the ERPSI, but not paid or recovered from the
ERPSI, for the ERP system operations and maintenance as defined in the RFP by the ERPSI, shall be
calculated and factored in to arrive at the net outstanding payables by the ERPSI (Outstanding
Payables );
d. Termination Payment Value shall be equal to the sum of Net Present Value and Outstanding
Receivables as per Article 10.5.4.(a) and (b); reduced by Outstanding Payables as per Article
10.5.4.(c) and the sum of insurance proceeds received by the ERPSI for the ERP system, (if any).
10.5.5 Upon Termination of the Contract or expiry of the contract period, the ERPSI shall prepare and
present a detailed Exit Management Plan within 5 (five) working days of termination notice receipt
to the Utility (Exit Management Plan ) in accordance with Article 10.6.
10.5.6 The Utility or its nominated agency will review the Exit Management plan. If approved, ERPSI
shall start working on the same immediately. If the plan is rejected, ERPSI shall prepare alternate
plan within 2 ( two) working days. If the second plan is also rejected, Utility will provide a plan for
ERPSI, and it should be adhered by in totality.
10.5.7 The Exit Management Plan should cover at least the following:
a. Execute all documents that may be necessary to effectively transfer the ownership and title,
including OEM warranties in respect of all equipment;
b. Handover all developed codes, related documentation, and other Configurable Items if any in his
possession;
c. Handover the list of all IT Assets, passwords at all locations to Utility.
10.5.8 The ERPSI and the Authorized personnel from Utility will sign a completion certificate at the
end of successful completion (all points tracked to closure) of the Exit Management Plan.
(f) Exit Management
10.6 Exit Management
10.6.1 Exit Management In case the Contract with the Utility ends or is terminated before the expiry
date of Contracts, the Parties shall agree at that time whether, and if so during what period, the
provisions of this Exit Management Plan shall apply. The Parties shall ensure that their respective
associated entities carry out their respective obligations set out in this Exit Management Plan. The
exit management shall be done in such a manner that operations should continue without any
restriction on access/usage of any kind of functionality. At the end of the Contract period, ERPSI
shall provide necessary handholding and transition support to the Utility or its agency for
maintaining the system post the Contract with the ERPSI. This includes (but not limited to):
Page 374 of 390

JPDCL
13.6.1.1.1 Conducting detailed walkthrough and demonstrations for the ERP Solution;
b. Handing over of ERP Solution, Utility‘s data and all other relevant documentation including updated
detailed bill of quantities for materials and services provided under the Contract;
c. Addressing the queries/clarifications of the designated staff / new agency with respect to the
working / performance levels of the infrastructure;
d. Conducting training sessions;
e. Knowledge Transfer;
f. Any other activity, over and above these, as may be deemed necessary to meet the service levels
and requirements specified in the RFP.
10.6.2 Transfer of Assets / ERP Solutions
a. Utility shall be entitled to serve notice in writing on the ERPSI at any time during the Exit
Management Period requiring the ERPSI and/or its sub-contractor to provide the Utility with a
complete and up to date list of the Assets and System configurations, License details, Customized
Code within 30 (thirty) days of such notice. Utility shall also be entitled to serve notice in writing
on the ERPSI at any time prior to the end of the Exit Management Period requiring the ERPSI to
transfer the overall control to the Utility or its nominated agencies in accordance with Article 10.
b. In case of contract being terminated by Utility, Utility reserves the right to ask ERPSI to continue
running the project operations for a period of 3 months after termination orders are issued. In case
of contract being terminated by ERPSI, Utility reserves the right to ask the ERPSI to continue running
the project operations for a period of 6 (six) months after termination notice is served by ERPSI. In
such case, payments during the Exit Management Period shall be made in accordance with the
Article 4.1 and 10.5 (as the case may be).
c. Upon service of a notice under this Plan, the following provisions shall apply:
i. All title to the assets as per the updated detailed bill of quantities for materials and services provided
under the Contract shall be transferred to Utility, on or before the last day of the Exit Management
Period.
ii. Payment to the outgoing ERPSI shall be made to the tune of last set of completed Services /
deliverables, subject to SLA requirements.
10.6.3 Cooperation and provision of information During the Exit Management Period:
a. ERPSI will facilitate / allow the Utility or its nominated agency access to information reasonably
required to define the then current mode of operation associated with the provision of the services
to enable the Utility to assess the existing services being delivered;
b. Promptly on reasonable request by the Utility, the ERPSI shall provide access to, and copies of all
information held or controlled by them which they have prepared or maintained in accordance
with this Contract relating to any material aspect of the services (whether provided by the ERPSI or
sub-contractors appointed by the ERPSI) to the Utility or its nominated agency. Such information
shall include details pertaining to the list of assets as per updated detailed bill of quantities for
materials and services provided under the Contract, services rendered and other performance
data. ERPSI shall permit the Utility or its nominated agencies to have reasonable access to its
employees and facilities to understand the methods of delivery of the services employed by the
ERPSI and to assist appropriate knowledge transfer; and
Page 375 of 390

JPDCL
c. In the event of Termination prior to Installation Milestone, ERPSI and Utility shall jointly appoint an
Independent Valuer to certify the value of assets, as per the updated detailed bill of quantities for
materials and services provided under the Contract, proposed to be handed over to the Utility upon
termination. The cost of Independent Valuer shall be paid by the ERPSI.
10.6.4 Confidential information, security, and data ERPSI shall promptly on the commencement of the
Exit Management Period supply to the Utility or its nominated agency the following:
a. information relating to the list of assets as per the updated detailed bill of quantities for materials
and services provided under the Contract, current Services rendered and consumer and
performance data relating to the performance of sub-contractors in relation to the Services;
b. documentation relating to the Project‘s Intellectual Property Rights;
c. documentation relating to sub-contractors;
d. all current and updated data as is reasonably required for purposes of Utility or its nominated
agencies transitioning the services in a readily available format;
e. all other information (including but not limited to documents, records, and agreements) relating to
the services reasonably necessary to enable Utility or its nominated agencies, to carry out due
diligence in order to transition the provision of the Services to Utility or its nominated agencies, (as
the case may be).
10.6.5 Transfer of certain agreements On request by the Utility or its nominated agency, the ERPSI
shall affect such assignments, licenses and sub-licenses as Utility may require in favour of the Utility
or its nominated agency reasonably necessary for the carrying out of replacement services. These
agreements may include equipment lease, maintenance, or service provision agreement between
selected ERPSI and third-party lessors, service providers, and any other agreements related to the
Services.
10.6.6 General obligations of the ERPSI during exit management period
a. The ERPSI shall provide all such information as may reasonably be necessary to effect as seamless a
handover as practicable in the circumstances to the Utility or its nominated agency and which the
ERPSI has in its possession or control at any time during the Exit Management Period.
b. For the purposes of this Schedule, anything in the possession or control of the ERPSI or associated
entity, or sub-contractors is deemed to be in the possession or control of the ERPSI.
c. The ERPSI shall commit adequate resources to comply with its obligations under this Exit
Management Schedule.
10.6.7 Exit management process The ERPSI shall prepare an Exit Management Plan for transfer of
operations to the Utility or its nominated agency, in the event of termination or expiry of the
contract with the Utility, without affecting services to stakeholders adversely. ERPSI shall get this
process approved by Utility. The Plan shall include, but not be limited to, the following-
a. A detailed program of the transfer process 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;
b. Plans for the communication with such of the ERPSI‘s subcontractors, staff, suppliers, customers
and any related third party as are necessary to avoid any material detrimental impact on the
Utility‘s project operations and ERP Services to other stakeholders as a result of undertaking the
transfer;
Page 376 of 390

JPDCL
c. Plans for provision of contingent support to Utility or its nominated Agency for a reasonable period
after transfer.
d. The Exit Management Plan including all updates shall be presented by the ERPSI to and approved
by the Utility or its nominated agencies.
e. During the Exit Management Period, the ERPSI shall use its best efforts to deliver the services.
f. Payments during the Exit Management Period shall be made in accordance with the Articles 4.1 and
10.5 (as the case may be) The Exit Management plan shall be furnished in writing to the Utility or
its nominated agencies within 90(ninety) days from date of execution this ERPSI contract The ERPSI
shall re-draft the Exit Management Plan annually thereafter to ensure that it is kept relevant and
up to date. The updated plan shall be furnished in writing to the Utility or its nominated agencies
within 15 days from the end of such period.
11. Liability/ Indemnity
11.1 The ERPSI hereby agrees to indemnify Utility, for all conditions and situations mentioned in this
Article, in a form and manner acceptable to Utility. The ERPSI agrees to indemnify Utility and its
officers, servants, agents (Utility Indemnified Persons ) from and against any costs, loss, damages,
expense, claims including those from third parties or liabilities of any kind howsoever suffered,
arising, or incurred inter alia during and after the Contract Period out of: any negligence or
wrongful act or omission by the ERPSI or its agents or employees or any third Party associated
with ERPSI in connection with or incidental to this Contract; or any infringement of patent,
trademark/copyright or industrial design rights arising from the use of the supplied Solution or
any part thereof.
11.2 The ERPSI shall also indemnify Utility against any privilege, claim or assertion made by third party
with respect to right or interest in, ownership, mortgage or disposal of any asset, property,
movable or immovable as mentioned in any Intellectual Property Rights, licenses and permits.
11.3 Without limiting the generality of the provisions of the Article 11.1 and 11.2, the ERPSI shall fully
indemnify, hold harmless and defend Utility Indemnified Persons from and against any and all
suits, proceedings, actions, claims, demands, liabilities and damages which Utility Indemnified
Persons may hereafter suffer, or pay by reason of any demands, claims, suits or proceedings
arising out of claims of infringement of any domestic or foreign patent rights, copyrights or other
intellectual property, proprietary or confidentiality rights with respect to the Solution,
information, design or process supplied or used by the ERPSI in performing the ERPSI‘s
obligations or in any way incorporated in or related to the Project. If in any such suit, action, claim
or proceedings, a temporary restraint order or preliminary injunction is granted, the ERPSI shall
make every reasonable effort, by giving a satisfactory bond or otherwise, to secure the
suspension of the injunction or restraint order. If, in any such suit, action, claim or proceedings,
the Solution or any part thereof or comprised therein, is held to constitute an infringement and
its use is permanently enjoined, the ERPSI shall promptly make every reasonable effort to secure
for the Utility a license, at no cost to Utility, authorizing continued use of the infringing work. If
the ERPSI is unable to secure such license within a reasonable time, the ERPSI shall, at its own
expense, and without impairing the specifications and standards, either replace the affected
work, or part, or process thereof.
(a) Survival on Termination
11.4 SURVIVAL ON TERMINATION
Page 377 of 390

JPDCL
11.4.1 The provisions of this Article 11 shall survive the Termination of the Contract
(b) Defense of Claim
11.5 DEFENCE OF CLAIMS
11.5.1 If any proceedings are brought or any claim is made against the Utility arising out of the matters
referred to in Article 11, the Utility shall promptly give the ERPSI a notice thereof, and the ERPSI
may at its own expense and in the Utility‘s, name conduct such proceedings or claim and any
negotiations for the settlement of any such proceedings or claims.
11.5.2 If the ERPSI fails to notify the Utility within 28 (twenty eight) days after receipt of such notice
that it intends to conduct any such proceedings or claim, then the Utility shall be free to conduct
the same on its own behalf.
11.5.3 The Utility shall, at the ERPSI‘s request, afford all available assistance to the ERPSI in conducting
such proceedings or claim, and shall be reimbursed by the ERPSI for all reasonable expenses
incurred in so doing.
(c) Limitation of Liability
11.6 LIMITATION OF LIABILITY
11.6.1 Except in cases of gross negligence, fraud, or wilful misconduct: 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 ERPSI to pay liquidated damages to the Utility; and The aggregate liability of the ERPSI to
the Utility, whether under the Contract, in tort, or otherwise, shall not exceed the Contract Price.
Provided that this limitation shall not apply to the cost of repairing or replacing defective
equipment, or to any obligation of the ERPSI to indemnify the Utility with respect to
infringement of any Intellectual Property Rights.
12. Governing Laws and Settlement of Disputes
12.1 The Utility and the ERPSI shall make every effort to resolve amicably any disagreement or dispute
arising between them under or in connection with the Contract, by direct informal negotiation.
12.2 If the Utility and the ERPSI fail to resolve such a dispute (the date of commencement of the
dispute shall be taken from the date when this Article reference is quoted by either Party in a
formal communication clearly mentioning existence of dispute or as mutually agreed) or
difference by mutual consultation within 28 (twenty-eight) days from the commencement of
such consultation, either Party may require that the dispute be referred for resolution to the
formal mechanisms specified in this Article.11.
12.3 All disputes or differences in respect of which the decision, if any, has not become final or binding
as aforesaid shall be settled by arbitration in the manner hereinafter provided. The arbitration
shall be conducted by three arbitrators, one arbitrator each to be nominated by the ERPSI and
the Utility and the third to be appointed as the presiding arbitrator by both the arbitrators in
accordance with the Arbitration and Conciliation Act,1996. If either of the parties fails to appoint
its nominee arbitrator within 60 (sixty) days after receipt of a notice from the other party invoking
the arbitration, the nominee arbitrator appointed by one of the parties invoking the arbitration
clause shall act as the sole arbitrator to conduct the arbitration under the Arbitration and
Conciliation Act 1996, as amended from time to time.
Page 378 of 390

JPDCL
12.4 The arbitration shall be conducted in accordance with the provisions of the Arbitration and
Conciliation Act, 1996 or any statutory modification thereof. The seat of arbitration shall be as
specified in SCC.
12.5 The Contract shall be governed by and interpreted in accordance with laws of India. The Courts,
specified in SCC, shall have exclusive jurisdiction in all matters arising under this Contract.
12.6 Parties to Perform Obligations: Notwithstanding the existence of any Dispute and difference
referred to the Arbitration Tribunal as provided in Article 12.3 and save as the Arbitration
Tribunal may otherwise direct by a final or interim order, the Parties hereto shall continue to
perform their respective obligations (which are not in dispute) under this Contract.
13. Change Order
(b) Change Request/ Change Order for New/Enhancements to Software Applications
13.1 Change Request/Change Order for New/Enhancements to ERP system / Software Applications
Another form of change may arise when the Utility discovers the need to have enhancements
in the delivered software applications and/or entirely new functional requirements in the
applications (New Requirements), subject to Article 13.1.5 of this Contract.
13.1.1 At any point in time the Utility may raise a Change Request to include New Requirements in the
ERP system application. This Change Request shall include the following: Identification and
documentation of the need for the change Functional details of the change Information related
to initiator, initiation date and Priority of the change
13.1.2 The ERPSI will analyze and evaluate the Change Request to come up with the estimate of the
effort involved in terms of man-days required (in respective skill areas) and time schedule as
per agreed priority and document the same. Utility will use the estimated effort of the new
requirements made by the ERPSI and together with the quoted man-month rates arrive at a
cost estimate. For all technical resources, the quoted man-month rate shall be used. Efforts of
support staff shall not be taken into consideration for this purpose.
13.1.3 Based on the agreed cost estimate, the Utility shall raise a Change Order. The ERPSI shall
undertake the development of the New Requirements only after securing express consent of
the Utility. If the consent of Utility is not received, then the change will not be carried out. The
change will be implemented in accordance with the agreed cost, effort, and schedule by the
ERPSI and the change will be verified by the Utility on completion of implementation.
13.1.4 If the Change Order for New Requirements 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 ERPSI receiving the change order.
13.1.5 The following categories of Change Requests shall not be treated as ―New Requirements and
the ERPSI is expected to deliver these Change Requests as per agreed schedule without any
commercial implications. All bug fixes All upgrades of the licensed platforms Changes made to
report templates, New reports, Integration with national level systems like NFMS etc. Minor
changes not requiring more than 10 man-days Aspects already covered under existing scope of
work provided in this Contract
13.1.6 In the case of New Requirements in Software Applications, Utility may at any time, by a written
Change Request seek changes to be implemented within the general scope of the Agreement
Page 379 of 390

JPDCL
provided this does not constitute unrelated work and that it is technically practicable, taking
into account both the state of advancement of the Solution and the technical compatibility of
the change envisaged with the nature of the Solution as specified in the Contract. The Change
Request/New Requirement management procedure will follow the following steps: -
Identification and documentation of the need for the Change Request/New Requirement - The
information related to initiator, initiation date and details of Change Request/New
Requirement and priority of the change/New Requirement will be documented by the Utility.
Analysis and evaluation of the Change Request/New Requirement - Impact of the change/ new
requirement in terms of the estimated effort, changed schedule, cost and the items impacted
will be analyzed and documented by the ERPSI. Approval or disapproval of the Change
Request/New Requirement – the Utility will approve or disapprove the Change Request/New
Requirements. Once approved the Change Request is converted into a Change Order which is
subject to the conditions laid down in Article 13.1.5. Implementation of the change/New
Requirement – The Change Order/New Requirement will be implemented in accordance with
the agreed cost, effort, and schedule by the ERPSI. Verification of the change/New
Requirement - The Change Order/New Requirement will be verified by the Utility on
implementation of the change request.
14. Miscellaneous
(a) Waiver
14.1 WAIVER
14.1.1 Subject to Article 14.1.2, 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.
14.1.2 The waiver by either Party of a breach or default of any of the provisions of this Contract by the
other Party shall not be interpreted as: A waiver of any succeeding breach of the same or other
provision, nor shall any delay or omission on the part of the other Party to exercise; or A way to
avail itself of any right, power, or privilege that it has or may have under this contract to operate
as waiver of any breach or default by the other Party. 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.
(b) Extension of Time
14.2 EXTENSIONS OF TIME
14.2.1 If at any time during performance of the Contract, the ERPSI or its subcontractors should
encounter conditions impeding timely delivery of the Goods or completion of Related Services
pursuant to this Contract, the ERPSI shall promptly notify the Utility in writing of the delay, its
likely duration, and its cause. As soon as practicable after receipt of the ERPSI‘s notice, the Utility
shall evaluate the situation and may at its discretion extend the ERPSI‘s time for performance,
in which case the extension shall be ratified by the Parties by amendment of the Contract.
14.2.2 Except in case of Force Majeure, as provided in Article 9 or where the delay in delivery of the
Goods or completion of Related Services is caused due to any delay or default of the Utility, any
Page 380 of 390

JPDCL
extension granted under Article 14.2.1 shall not absolve the ERPSI from its liability to the pay of
liquidated damages pursuant to Article 6. Time will be the essence of the Contract and no
variation shall be permitted in the delivery time/delivery schedule mentioned in the order
unless agreed by the Utility. The ERPSI is expected to implement the systems for the project
area as per the schedule indicated in the Contract.
(c) Insurance
14.3 INSURANCE
14.3.1 The Goods supplied under the Contract shall be fully insured by the ERPSI against loss or
damage incidental to manufacture or acquisition, transportation, storage, and delivery.
14.3.2 The ERPSI shall furnish to the Utility copies of certificates and policies of the Insurances as soon
as they are affected and renewed by or on behalf of the ERPSI from time to time in terms of
Article 14.
(d) Transportation
14.4 TRANSPORTATION
14.4.1 The ERPSI shall at its own risk and expense transport all the ERPSI‘s equipment to the site by
the mode of transport that the ERPSI judges most suitable under all the circumstances.
14.4.2 Unless otherwise provided in the Contract, the ERPSI shall be entitled to select any safe mode
of transport operated by any person to carry the ERPSI‘s equipment.
14.4.3 The ERPSI shall be responsible for obtaining, if necessary, approvals from the authorities for
transportation of the ERPSI‘s equipment to the Project site. Utility shall use its best endeavours
in a timely and expeditious manner to assist the ERPSI in obtaining such approvals, if requested
by the ERPSI.
15. Confidential Information
15.1 Both ERPSI and the Utility undertake to each other to keep confidential all information (written
as well as oral) concerning the business and affairs of the other, which has been obtained or
received as a result of the discussions leading up to or the entering of the Contract.
15.2 After the entering of the Contract, the Utility and the ERPSI shall keep confidential and shall not,
without the written consent of the other Party hereto, divulge to any third party any 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. Notwithstanding the above, the ERPSI may furnish to
its subcontractors such documents, data, and other information it receives from the Utility to the
extent required for the subcontractors to perform its work under the Contract, in which event
the ERPSI shall obtain from such subcontractors an undertaking of confidentiality similar to that
imposed on the ERPSI under this Article 15.
15.3 The Utility shall not use such documents, data, and other information received from the ERPSI
for any purposes unrelated to the Contract. Similarly, the ERPSI shall not use such documents,
data, and other information received from the Utility for any purpose other than the design,
procurement, or other work and services required for the performance of the Contract.
15.3.1 The obligation of a Party under Articles 14.1 and 14.2 above, however, shall not apply
to information that: Utility or ERPSI need to share with the institutions participating in
the financing of the Contract; (i) information which, at the time of disclosure to the
Page 381 of 390

JPDCL
receiving party was already in the public domain; (ii)information which, after disclosure
to the receiving party becomes publicly available without any breach of this
confidentiality undertaking; (iii)information which was in the possession of he
receiving party prior to its disclosure, as evidenced by the records of the receiving
party; (iv)information that is received by the receiving party from a third party, who to
the knowledge of the receiving party after having conducted reasonable enquiry into
the authority of such third party to possess and divulge the same, is not in breach of
its confidentiality obligations. and (v)information that is required to be disclosed by the
receiving party (and solely to the extent required to be disclosed) pursuant to the
requirements of applicable laws, or order of a judicial, regulatory or administrative
authority or the guidelines of regulatory/administrative authority. .
15.3.2 The above provisions of this Article 15 shall not in any way modify any undertaking of
confidentiality given by either of the Parties hereto prior to the date of execution of
the Contract in respect of the Supply or any part thereof.
15.3.3 Each of the Parties to this Contract, undertakes to the other to take all such steps as
shall from time to time be necessary to ensure compliance with the provisions of the
above Articles by its employees, agents, and sub-contractors.
15.3.4 The provisions of this Article 15 survive completion or termination, for whatever
reason, of the Contract.
16. Subcontracting
16.1 The ERPSI shall be permitted to appoint subcontractor(s) so as to meet its obligations under the
Contract with the Utility, with intimation to the Utility, provided they ensure that any person
engaged by ERPSI are not blacklisted by any Government organization or regulatory agencies or
Government Undertaking as on date of intimation of the Utility (as defined under the Section 2
of this RFP).
16.2 ERPSI shall engage only such sub-contractor(s) who satisfy the eligibility requirement in terms of
applicable laws including the guidelines issued vide Order No. F/No.6/18/2019- PPD by Ministry
of Finance, Department of Expenditure, Public Procurement Division dated 23 July 2020 and as
amended from time to time.
17. Warranty
17.1 The ERPSI warrants that all the Goods that would be used as part of Solution would be new,
unused, and of the most recent or current models, and that they incorporate all recent
improvements in design and materials, unless provided otherwise in the Contract.
17.2 The ERPSI further warrants that the Goods shall be free from defects arising from any act or
omission of the ERPSI or arising from design, materials, and workmanship, under normal use in
the conditions prevailing in the country of final destination.
17.3 The warranty of the ERP system shall remain valid till expiry of the Contract Period.
17.4 The ERPSI shall be responsible for comprehensive maintenance of all the equipment and systems
supplied & installed under this Contract during the Operational Period. There may be some
variation during detailed engineering. ERPSI will have to make their own assessment of the
systems and deploy manpower accordingly. However, it is to be ensured that specified
manpower of requisite qualification is deployed.
Page 382 of 390

JPDCL
17.5 The maintenance of the system supplied & installed by the ERPSI shall be comprehensive. The
ERPSI shall be responsible for providing all the spares as may be required. The spares shall be
maintained by the ERPSI at no extra cost to the Utility.
18. Change in Laws and Regulations
18.1 Unless otherwise specified in the Contract, if after the Bid Submission Deadline indicated in SCC,
any law, regulation, ordinance, order or bylaw having the force of law is enacted, promulgated,
abrogated, or changed in India where the sites is located (which shall be deemed to include any
change in interpretation or application by the competent authorities) that subsequently affects
the project delivery, then such delivery shall be correspondingly amended, to the extent that the
ERPSI has thereby been affected in the performance of any of its obligations under the Contract.
18.2 The Party affected by a change in law shall give notice giving details of the likely impact of the
change in law. The Parties shall negotiate in good faith to place the affected party at the same
economic position as if no change in law had occurred. Provided only such change in law events
which have financial impact beyond a threshold specified in SCC, are to be considered for the
purposes of grant of relief to the affected Party.
18.3 Notification of Change in Law: If the ERPSI is affected by a Change in Law in accordance with
Article 18.1 and wishes to claim relief for such Change in Law under this Article 18, it shall give
notice to the Utility of such Change in Law as soon as reasonably practicable after becoming
aware of the same. Any notice served pursuant to Articles 18 shall provide, amongst other things,
precise details of the Change in Law and its effect on the ERPSI.
19. Severability
19.1 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 or the Contract as a whole and the remaining
provisions of the Contract shall remain in full force and effect.
20. Language
20.1 The official language of the Contract is English. Contract as well as all correspondence and
documents relating to the Contract exchanged by the ERPSI and Utility, shall be written in English.
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
English, in which case, for purposes of interpretation of the Contract, the English translation shall
govern.
20.2 The ERPSI shall bear all costs of translation to English and all risks of the accuracy of such
translation. The ERPSI shall be bound to the English translation and what has been stated therein.
21. Assignment
21.1 The ERPSI shall not assign, in whole or in part, their obligations under this Contract without prior
permission of the Utility.
21.2 However, in case of default by the ERPSI in debt repayments or in the event of default by the
ERPSI, the Utility may, on an application from the Lenders, assign the work under the ERPSI
contract to the nominee of the Lenders subject to the fulfilment of the qualification requirements
and provisions of the Contract.
Page 383 of 390

JPDCL
22. Entire Agreement

22.1 This Contract along with all its annexures, schedule and the provisions of the RFP reflect the entire
understanding of the Parties.
22.2 No variation or modification of the terms of the Contract shall be made except by written
amendment signed by the Parties.
23. Disclaimer
23.1 Utility reserves the right to share, with any consultant of its choosing, any resultant proposals in
order to secure expert opinion.
23.2 Utility reserves the right to accept any proposal deemed to be in the best interest of the Utility.
24. Public Disclosure
24.1 All materials provided to Utility by the ERPSI may be disclosed in accordance with the provisions
of applicable law including but not limited to the Right to Information Act, 2005 (RTI), etc.
24.2 The ERPSI‘s team shall not make or permit to be made a public announcement or media release
about any aspect of this Contract unless Utility first gives the ERPSI its written consent.
25. Adherence to Safety Procedures, Rules, Regulations and Restriction
25.1 ERPSI shall comply with the provision of all laws including labour laws, rules, regulations, and
notifications issued there under from time to time. All safety and labour laws enforced by
statutory agencies and by Utility shall be applicable in the performance of this Contract and
ERPSI‘s team shall abide by these laws.
25.2 Access to the Utility‘s locations shall be strictly restricted. No access to any person except the
designated personnel belonging to the ERPSI who are genuinely required for execution of work
or for carrying out management/maintenance who have been explicitly authorized by Utility shall
be allowed entry to the Utility‘s locations. Even if allowed, access shall be restricted to the
pertaining equipment of Utility only. The ERPSI shall maintain a log of all such activities.
25.3 The ERPSI shall take all measures necessary or proper to protect the personnel, work and facilities
and shall observe all reasonable safety rules and instructions. ERPSI‘s team shall adhere to all
security requirement/regulations of Utility during the execution of the work. Utility‘s employees
and associates also shall comply with safety procedures/policy.
25.4 The ERPSI shall report as soon as possible any evidence, which may indicate or is likely to lead to
an abnormal or dangerous situation and shall take all necessary emergency control steps to avoid
such abnormal situations.
25.5 Utility will be indemnified for all the situations mentioned in this Article in the similar way as
defined in Article 11.
26. Non- Solicitation of Staff
26.1 The Articles of this contract, which by nature are intended to survive termination of this Contract,
shall remain in effect after such termination
27. Survival
27.1 The Articles of this contract, which by nature are intended to survive termination of this Contract,
shall remain in effect after such termination.
28. Notices
28.1 All notices to be given under this Contract shall be in writing and in the English language.
Page 384 of 390

JPDCL
28.2 A Notice shall be effective when delivered or on the notice effective date, whichever is later.
29.3 All notices must be delivered personally, by registered or certified mail or by facsimile
transmission or email.
28.4 All notices shall be effective: If sent by facsimile transmission or email, when sent (on receipt of
confirmation of the correct number or address); If sent by registered post or certified mail, within
5 (five) days of dispatch; If delivered personally, on receipt by intended recipient, provided that
all notices given by facsimile transmission shall be confirmed by registered or certified mail.
28.5 Each party shall forthwith notify the other party of any change in its address to which notices
under this Contract are to be delivered, mailed or facsimiled.
B. Special Conditions of Contract
GCC Article / Amendments of, and Supplements to, Clauses in the General Conditions of
Clause Contract
5.1 5 % of the Contract Price (The Quantum of the Performance Security will be
liveable as per the Existing rules in Vogue at the time of Issuance of LOA.)
10.5.4 (a) 10.5 %
12.4 Jammu and Kashmir
12.5 Jammu and Kashmir
13.1 [ -20%] to [+20%]
18.2 0.2 % of the Contract Price
Page 385 of 390

JPDCL
PART III
CONTRACT RELATED FORMS
Page 386 of 390

JPDCL
Section 8. Contract Related Form
Form No. Document

1 Performance Security as per the format prescribed in Form 1
2 Letter of Award as per the format prescribed in Form 2
Page 387 of 390

JPDCL
Form 1: Format of Performance Security

Reference No. ……………. Bank Guarantee No. ……….…. Dated: …………….
To:
JPDCL
[Address]
Dear Sir/ Madam,
WHEREAS……………. [Insert name of the ERPSI-Lead / Sole Bidder] with address ……………. [Insert
address of the ERPSI-Lead/ Sole Bidder] having its registered office at ……………. [Insert address of
the ERPSI-Lead/ Sole Bidder] (hereinafter, the ―Contractor ), subsequent to participation in Tender
No. [Tender Details] (the ―RFP ) issued by JPDCL (hereinafter, the ―Beneficiary ) for Appointment
of Selection of System Integrator (ERPSI) to Design, Develop, Implement and Maintain Enterprise
Resource Planning (ERP) Solution on Cloud, have been issued the Letter of Award as the Selected
Bidder. The Selected Bidder was required to incorporate the ERPSI. Further the ERPSI was required to
furnish a Performance Security in the form of a Bank Guarantee
And WHEREAS a Bank Guarantee for Rupees ……………. [Insert amount in words equivalent]
(…………….) [Insert amount in figures] valid till……………. [Insert Contract Period] is required to be
submitted by the ERPSI as per the terms and conditions of the RFP.
In consideration of the [details of the Bidder] agreeing to undertake the obligations under the [insert
details of the bid document], we, …………….[Insert name of the Bank and address of the Branch
giving the Bank Guarantee] having our registered office at …………….[Insert address of the
registered office of the Bank] (Guarantor Bank ) hereby give this Bank Guarantee No.
…………….[Insert Bank Guarantee number] dated …………….[Insert the date of the Bank
Guarantee], and hereby agree unequivocally, irrevocably and unconditionally to pay immediately
on demand in writing from the Utility any officer authorized by it in this behalf any amount not
exceeding [Amount] to the said Utility on behalf of the Bidder.
We, [Insert name of issuing bank] do hereby undertake to pay the amounts due and payable under
this bank guarantee without any demur, protest, dispute or any inquiry. Any such demand made
on the Guarantor Bank, shall be conclusive as regards the amount due and payable by the Guarantor
Bank under this bank guarantee. Our liability under this present being absolute and unequivocal.
The Guarantor Bank hereby expressly agrees that it shall not require any proof of the terms of the
[bid documents] or the occurrence of any event specified thereunder and shall make the payment
to the Utility immediately on the written demand from the Utility, made in any format, raised at the
above- mentioned address of the Guarantor Bank.
Page 388 of 390

JPDCL
We ……………. [Insert name of the Bank] also agree that non-performance, delayed performance or
violation of any of the terms and conditions of the contract by ERPSI would constitute a default on the
part of the Bidder and that this Bank Guarantee is liable to be invoked and encashed within its validity
by the Beneficiary in case of any occurrence of a default on the part of the ERPSI or the Selected Bidder
and that the enchased amount is liable to be forfeited by the Beneficiary.
This agreement shall be valid and binding on this Bank up to and inclusive of ……………. [Insert the date
of validity of the Bank] and shall not be terminable by notice or by Guarantor change in the
constitution of the Bank or the firm of the Bidder Or by any reason whatsoever and our liability
hereunder shall not be impaired or discharged by any extension of time or variations or alternations
made, given, conceded with or without our knowledge or consent by or between the Bidder and the
Beneficiary.
NOTWITHSTANDING anything contained hereinbefore, our liability under this guarantee is restricted
to Rupees .......... [Insert amount in words equivalent]. Our Guarantee shall remain in force till
……………. [Insert the contract period]. Unless demands or claims under this Bank Guarantee are made
to us in writing on or before……………. [Insert contract period], all rights of the Beneficiary under this
Bank Guarantee shall be forfeited, and we shall be released and discharged from all liabilities there
under.
[Insert the address of the Bank with complete

postal branch code, telephone, and fax numbers,
and official round seal of the Bank]
[Insert signature of the Bank’s
Authorized Signatory]
Attested: ……………………………. [Signature] (Notary Public)

Place: ………………………….Date: …………………………….
_________________________________________________________________________
INSTRUCTIONS FOR SUBMITTING BANK GUARANTEE
1. Bank Guarantee to be executed on non-judicial stamp paper of appropriate value as per Stamp Act
relevant to place of execution.
2. The Bank Guarantee by Bidder shall be given from the Scheduled Commercial Banks.
Page 389 of 390

JPDCL
Form 2: Format of Letter of Award (Indicative)

Subject: Bid for Appointment of System Integrator for Selection of System Integrator (ERPSI)
to Design, Develop, Implement and Maintain Enterprise Resource Planning (ERP) Solution on Cloud
REF: - 1. Request for Proposal for selection of ERPSI dated [] (―RFP )

2. Your proposal dated :
3. Your clarification :
Dear Sir,
1. This is in reference to your Proposal in relation to the RFP.
2. Pursuant to the evaluations of the Bid, your bid has been found to be most suited.
3. A draft of the ERPSI Contract was provided to you along with the RFP. Please note that there shall
be no change whatsoever in the terms and conditions as set out in the draft Contract.
4. Please note that in the event of failure to comply with any terms and conditions of this Letter of
Award, the entire Bid Security may be forfeited.
5. Any further correspondence in connection with the Project should be addressed to the [insert
details of the appropriate authority with a copy to Chairman/ Managing Director, till further
instructions are issued.
6. The terms and conditions as set out in this Letter of Award shall stand valid until execution of the
ERPSI Contract.
7. Please acknowledge the receipt and return the duplicate copy of this Letter of Award after signing
and stamping it in all the pages to the undersigned as a token of acceptance.
Thanking You
Yours truly
[insert details of the Utility]
Reference No. ……………. Bank Guarantee No. ……….…. Dated: …………….
Page 390 of 390

Erprfp JPDCL

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Erprfp JPDCL

Uploaded by

Copyright:

Available Formats

Request for Proposal for Selection of System Integrator

(ERPSI) to Design, Develop, Implement and Maintain

Jammu Power Distribution Corporation Limited (JPDCL)

Issue Date: 19/09/2023

Section 1: Request for Proposals (RFP) Notice

This Section includes Request for Proposals.

Section 2: Eligibility and Qualification Requirements

This Section contains information regarding specific eligibility and qualification

Section 3: Instructions to Bidders and Bid Data Sheet

Section 4: Bidding Forms – Technical Proposal

Section 5: Bidding Forms - Financial Proposal

Section 6: Project Requirements

PART II – CONTRACT FORM AND CONDITIONS OF CONTRACT

Section 7: Contract Form and Conditions of Contract

PART III – CONTRACT RELATED FORMS

Section 8: Contract Related Forms

PART III ................................................................................................................................................ 386

Organisation Structure of JPDCL

About the Project

Among the various functional modules to be implemented are:

SR. NO. FUNCTIONAL MODULE LEGEND

Section 1. Request for Proposal Notice

Request for Proposal (RFP)/ Tender Number: 07 of 2023-2024

Issued on: 19/09/2023

Important Dates, Amounts and Other Details

Tender/RFP Reference No. and Date 07 of 2023-2024 19/09/2023

of minimum 180 days. Account details for the

Section 2. Eligibility and Qualification Requirements

5. Eligibility Requirements for Consortium

12. Qualification Requirements

Certificate from the Statutory Auditor/

(*Completion Certificate for completed projects

i. Work order/ Purchase Order/ Contract

ii. ISO 20000:2011 for Service AND

The Sole Bidder and Consortium member

The ERP OEM should be incorporated in India i. Certificate of incorporation /

The support center should offer post-sales

13. Technical Evaluation Criteria

A Bidder’s profile (Max Marks: 30)

B Project Experience (Max Marks: 25)

B1.b Implementation of ERP Projects in 5 Work order/ Purchase Order/

Completion Certificate/ Phase

• No. of project (4) – 8 marks

• 3 CSP or above – 5 Marks

C Approach & Methodology with proposed solution (Max Marks: 10)

C1 Approach & methodology • Understanding of scope, high-level 10 Presentation by bidder

D1 Project Manager (Onsite) a. Experience (2 Marks) 5

D3 Solution Architect a. Project Experience (1 Marks) 2

3. ERP OEM Experience 20 10

14. Bid Opening and Evaluation Methodology

14.1.1. Verification of Pre-Qualification Criteria

14.1.2. Technical Bid Evaluation

Tb : Absolute Technical Score

Tmax : Maximum Technical Score

Tn : Normalized Technical score of bidder under Consideration

Normalized Technical score (Tn) = Tb/ Tmax * 100

14.2. Stage – 2 Financial Evaluation

14.3. Scoring of Commercial Criteria

14.4. Scoring of Commercial Criteria

14.5. Rejection Criteria

Section 3. Instructions to Bidders and Bid Data Sheet

Section 3. Instructions to Bidders and Bid Data Sheet

o) “ERPSI-Lead” or “Lead Bidder” shall mean the Member of