RFP DOCUMENT

Index

Sl. No Title Page No.

1 List of Abbreviations 2

2 Appendix-I Terms of Reference 3

3 Section 1 - Scope of Work 6

4 Section 2 – Functional Requirement Specification (FRS) for ERP Reconfiguration 23

5 Section 3 – System - Solution Architecture for Reconfigured ERP 49

6 Section 4 – Testing Requirement for Reconfigured ERP 62

7 Section 5 – Service Level Agreement (SLA) 65

8 Section 6 – Timeline 69
 List of Abbreviations

Abbreviation Expansion
API Application Programming Interface
COTS Commercial Off-The-Shelf
BOQ Bill of Quantities
DPR Detailed Project Report
EDMS Electronic Document Management System
GC General Consultant
GCC General Conditions of Contract
HRMS Human Resource Management System
IT Information Technology
MRTS Mass Rapid Transit System
O&M Operations and Maintenance
SCC Special Conditions of Contract
SLA Service Level Agreement
SPV Special Purpose Vehicle
TOR Terms of Reference
AP Accounts Payable
AR Accounts Receivable
GL General Ledger
FA Fixed Assets
CM Cash Management
Configuration, Extension, Modification, Localization, and
CEMLI
Integration Framework

SPOC Single Point Of Contact

3
 APPENDIX- I
TERMS OF REFERENCE (TOR)

Vol-2
4
 Index
Section 1 - Scope of Work

Section 2 – Functional Requirement Specification (FRS) for ERP Reconfiguration

Section 3 – System - Solution Architecture for reconfigured ERP

Section 4 – Testing Requirement for Reconfigured ERP

Section 5 – Service Level Agreement (SLA)

Section 6 – Timeline

Vol-2
5
 Section – 1

Scope of Work

Vol-2 Section 1: Scope of Work

6
 1. Introduction

ORGANIZATION is presently using Oracle E-Business Suite as the COTS ERP for
Purchasing and Finance/Account (AP, AR, GL, FA, CM) functions. HRMS is currently
managed by a custom developed module, which is integrated with Oracle E-Business Suite
for Accounting and financial functions. However, there is a need to reconfigure the existing
ERP (Oracle E- Business Suite), which would meet the requirements of company in a better
way. In order to achieve this, Oracle E-Business Suite should be reconfigured and Finance,
Projects, Inventory, Purchasing and custom modules should be incorporated fully so that it
can be used at multiple project locations and upcoming projects of Organization.

Bidder has to reconfigure the existing ERP such that ORGANIZATION shall be the company
with single GST, PAN and TAN having different projects/Business Units along with provision
for adding more business units in future. In addition to reconfiguration, existing ERP
needs to be aligned with latest development with respect to Ind AS, Companies Act and
other statutory laws and taxes from time to time.

Bidder will be responsible for creating custom reports for each location as well as
consolidated reports for the company.

Each location will be considered a different cost center. ORGANIZATION user should
be able to generate Location wise balance sheet and single balance sheet for the company.

Complete transition of E-Business Suite and migration of data from the existing system to the
newly reconfigured system will be the responsibility of Vendor and it is to be performed in a
timely manner. Employees of ORGANIZATION also, need to be trained to perform their
respective functionalities in the new system.

Also, the bidder will need to undertake Annual Maintenance and Support (AMS) for the entire
ERP system including the newly reconfigured ERP for 5 years after go-live and stabilization
of reconfigured systems.

2. Detailed Scope of Work

2.1 Job: For reconfiguration of ERP (Oracle E-Business Suite), integration with existing
custom HRMS and Annual Maintenance and Support of reconfigured ERP Application for
Organization Ltd. for 05 years.
2.1.1 At present ORGANIZATION has the following Oracle Licenses (Perpetual):

S. No. Details Qty.

1 Oracle Learning Management - Trainee Perpetual 500

2 Oracle Payroll - Employee Perpetual 500

3 Oracle Internet Application Server Enterprise Edition - 04

Processor Perpetual

Vol-2 Section 1: Scope of Work

7
 4 Oracle Financials - Application User Perpetual 15

5 Oracle Internet Application Server Enterprise Edition - 25

Named User Plus Perpetual

6 Oracle Database Enterprise Edition - Processor Perpetual 04

7 Oracle Real Application Clusters - Processor Perpetual: 04

8 Oracle Human Resources - Employee Perpetual 500

9 Oracle Self-Service Human Resources - Employee Perpetual 500

10 Oracle Project Costing - Application User Perpetual 05

11 Oracle Database Enterprise Edition - Named User Plus 25

Perpetual

12 Oracle User Productivity Kit Professional - UPK Developer 02

Perpetual

13 Oracle Purchasing - Application User Perpetual 10

14 Oracle Discrete Manufacturing - Application User Perpetual 10

15 Oracle User Productivity Kit Professional - Application User 50

Perpetual

2.2 At Present Oracle database [Link].0 and oracle EBS 12.2.5 is being used and hardware
installed presently at ORGANIZATION premises consist of:

Hardware Make Qty.

Server Dell R730 2
Storage Dell Powervault 1
SAN Switch Brocade 8GB FC 2
Tape Drive Powervault 1
Oracle Linux Basic Limited - 2
Oracle VM Premier Limited - 2
Backup Software NetVault 1

Servers placed at ORGANIZATION Premises have Octa Core, Intel (R) Xeon (R) CPU
E5-2630 v3 processor with 2.4GHz clock speed. Oracle VM Server Release 3.4.2 is
installed on both servers.

Current Database Size for Production is as follows:

Reserved: 129.58 GB
Used: 74.73 GB
Free: 54.85 GB

Vol-2 Section 1: Scope of Work

8
 Annual Maintenance and Support will be vendor’s responsibility, SPOC in any case for
ORGANIZATION will be the Vendor and it will be Vendor’s responsibility to get
required support from the OEM. Vendor has to provide Annual Maintenance of existing
hardware placed at ORGANIZATION premises for 05 years.

2.3 GL, Purchasing/Procurement, Receivables, Asset Management (Fixed Assets), Inventory

Management, Cash Management, Project Management, Contract Module and Revenue
automation module are currently implemented, where Revenue automation and Contract
module are custom modules.

Following two modules are Custom Modules implemented in ORGANIZATION EBS:

2.3.1 Revenue Automation:
Revenue Automation Module is used to maintain the earning (by selling tokens, Go
Smart Card etc.) data at stations, reconciliation and accounting of the same. It is
integrated with finance GL/AR Modules.
It has two parts:
1. Revenue automation: Used at station by entry operators for maintaining
earning data.
2. Revenue automation Finance: Used by ORGANIZATION finance team for
reconciliation and accounting.
Processes being followed in Revenue Automation Module are as follows:
-OPERATOR ENTRY
-WTE URC (Write Token Error Unreadable Card)
-WTC TOKEN/CARD
-PAYBACK
-PRINTPAGE
-VALIDATE AND COMPUTE TOTAL

Processes being followed in Revenue Automation Finance are as follows:

-FINANCE SEARCH
-FINANCE REVIEW
-DAILY BANKING AFC STATION REPORT
-GENERATE SUMMERY/MIS (Management Information Summary) REPORT
-WTE TOKEN REPORT
-REVIEW
-REVENUE ACCOUNTING
-WTE TOKEN APPROVAL
-REVENUE CHARGEBACK ENTRY
-SEARCH CHARGEBACK ENTRY
-CREATE CHARGEBACK ENTRY
-PRINT CHARGEBACK ENTRY
-POS TERMINAL ID ENTRY

2.3.2 Contract Module:

This customized solution enables business to capture Contract details and has
ability to auto-generate invoices as per the agreed frequency integrated with AR
module. Broadly Contract Creation Process workflow is as depicted below: -

Vol-2 Section 1: Scope of Work

9
 Draft Invoice
Contract Service Invoice
Approval Invoice Creation
Creation Delivery Approval

Custom Pages created in this module are as follows:

a. Contract Search Page

b. Contract Create Page
c. Service Delivery Page
d. Service Delivery Line Page
e. Service Delivery Report Page
f. Create Contract Invoice Page
g. Price Escalation Page
h. Contract Approval Page

2.3.3 At present approx. 62 custom reports are there in EBS as per

ORGANIZATION need, Details are as follows:

Sr. No. Program/Report Name Module

1 AP Invoice GST Details Report AP
2 Bank Advice Register Report AP
3 Bank Payment Register Report AP
4 Bank Payment Voucher AP
5 Employee as vendor create/update Program AP
6 GSTTDS7 Excel Report AP
7 Purchase Bills Register Report AP
8 Unapproved AP Invoice Hold Apply AP
9 Unapproved AP Invoice Hold Release AP
10 VENDOR TDS Report (Excel) AP
11 Vendor Invoice Entry- Voucher AP
12 AP_Invoice_Reimbursement_Interface AP
13 Supplier Payment Advice Bank Transfer File (EFT) Report AP
14 Outstanding Reimbursement Invoices Report AP
15 Cumulative Bank Register Report AP
16 Voucher Printing – Reimbursement Invoices AP
17 Monthly Contractual Report AP
18 Payable AP Invoice Print Report AP
19 Journal Day Book Report AP
20 Blanket Release Print Report (XML) AP
21 Milestone Payment Details Report AP
22 AR Invoice GST Details Report AR
23 AR Transaction Details Report AR
24 Bank Receipts Register Report AR
25 Customer Ledger Report AR
26 Employee – Customer Creation AR
27 Misc Receipt Creation Program AR
28 Misc receipt creation for Training Cost AR
29 Sales Invoice Register Report AR
30 Tender Security Report AR

Vol-2 Section 1: Scope of Work

10
 31 AR_Receipt_Details_Report AR
32 Customer Ledger transaction report AR
33 Annual Salary Increment Custom Program FA
34 Journal Entry Reserve Ledger Report FA
35 GL Interface Program GL
36 GL Transactions GL
37 Journal Voucher GL
38 Journals Register Report GL
39 FIN MIS Report GL
40 MIS Trial Balance Report GL
41 Approved PO Proposal Pending for RFQ Creation PO
42 Goods Receipt Note (GRN) Report PO
43 POGRN GST Details Report PO
44 Pending Indents for Purchase Proposal Creation Report PO
45 Purchase/Work Order Print Report(XML) PO
46 SRN Print Report (XML) PO
47 Standard Purchase Order Print Report (XML) PO
48 Standard Purchase Order W/O Tax Print Report (XML) PO
49 AMC W/O Tax Print Report (XML) PO
50 Work Order Print Report (XML) PO
51 RFQ Print Report (XML) PO
52 RFQ Comparison Report (Based on Lowest Offer) PO
53 RFQ Comparison Report (Based on Total Value Offer) PO
54 Blanket Purchase Order Print Report (XML) PO
55 Work order W/o tax print report (XML) PO
56 Open PO Report PO
57 Bank Confirmation Report Project
58 Bank Guarantee Report Remainder1 Project
59 Bank Guarantee Report Remainder2 Project
60 Reminder Executive Report Project
61 Revenue Chargeback Print Voucher REVENUE
62 Bank Reconciliation Report AP

Bidder will be responsible for creating custom reports in addition to existing reports as well
as changes in existing reports as per ORGANIZATION requirements. Format for some of the
custom reports are attached at Appendix-VII for reference, actual reports will be provided
during reconfiguration, if required.

Payable Super User module has following Custom processes and reports:

1. Invoice Bulk Approval

2. Payment Advice Printing
3. Bulk Validation and approval
4. Invoice (Standard + Custom LC invoice Creation)

2.3.4 Approx. 243 form personalization are there as per ORGANIZATION need,
details of form personalization are as follows:

Vol-2 Section 1: Scope of Work

11
 Form Form
ID Name User Form Name Personalization Rule Name
54250 APXINWKB Invoice Workbench Form in one Session
If Document category is -STD-LC-INV then
54250 APXINWKB Invoice Workbench populate standard as type in Customer id field
If Document category is -STD-LC-INV then
54250 APXINWKB Invoice Workbench populate standard as type in Type field
If Document Catergory is null displaying warning
54250 APXINWKB Invoice Workbench message
If Document Category is -LC-CM then populate
54250 APXINWKB Invoice Workbench Credit Memo as type in customer id field
If Document Category is -LC-CM then populate
54250 APXINWKB Invoice Workbench Credit Memo as type in type field
If Document Category is -LC-DM then populate
54250 APXINWKB Invoice Workbench Debit Memo as type in customer id field
If Document Category is -LC-DM then populate
54250 APXINWKB Invoice Workbench Debit Memo as type in type field
54250 APXINWKB Invoice Workbench Query allowed
54250 APXINWKB Invoice Workbench Define India Taxes Details Menu
54250 APXINWKB Invoice Workbench Define India Taxes Details Menu
54250 APXINWKB Invoice Workbench Define India Taxes Details Menu
54250 APXINWKB Invoice Workbench Prepayment amout per:cent test
54250 APXINWKB Invoice Workbench Define India Taxes Details Menu
54250 APXINWKB Invoice Workbench Invoke Taxes Details UI
54250 APXINWKB Invoice Workbench Invoke Taxes Details UI
54250 APXINWKB Invoice Workbench Mandatory Document category in header level
54250 APXINWKB Invoice Workbench Invoke Taxes Details UI
54250 APXINWKB Invoice Workbench Invoke Taxes Details UI
54250 APXINWKB Invoice Workbench Special Localization Menu
54250 APXINWKB Invoice Workbench Stop transaction if document category name is null
54250 APXINWKB Invoice Workbench Special Localization Menu
54250 APXINWKB Invoice Workbench Special Localization Menu
54250 APXINWKB Invoice Workbench Special Localization Menu
54250 APXINWKB Invoice Workbench invoince number variable
54250 APXINWKB Invoice Workbench Error Message for invalid invoice type
54250 APXINWKB Invoice Workbench Error Message for invalid invoice type
54250 APXINWKB Invoice Workbench Error Message for invalid invoice type
Assign Invoice Number to Global variable for DFF
54250 APXINWKB Invoice Workbench updation in inovoice
54250 APXINWKB Invoice Workbench Error Message for invalid invoice type
54250 APXINWKB Invoice Workbench Error Message for Dist Line not Saved
54250 APXINWKB Invoice Workbench Error Message for Dist Line not Saved
54250 APXINWKB Invoice Workbench Error Message for Dist Line not Saved
54250 APXINWKB Invoice Workbench Error Message for Dist Line not Saved
Update DFF(ATTRIBUTE12 and 13) with Contract
54250 APXINWKB Invoice Workbench Number and prepayment title in Related Invoices
Error Message for Third Party Registration and tax
54250 APXINWKB Invoice Workbench calendar missing
Error Message for Third Party Registration and tax
54250 APXINWKB Invoice Workbench calendar missing

Vol-2 Section 1: Scope of Work

12
 Error Message for Third Party Registration and tax
54250 APXINWKB Invoice Workbench calendar missing
Error Message for Third Party Registration and tax
54250 APXINWKB Invoice Workbench calendar missing
54250 APXINWKB Invoice Workbench JAI Localization
54250 APXINWKB Invoice Workbench JAI Localization
54250 APXINWKB Invoice Workbench Hide creater values
54250 APXINWKB Invoice Workbench JAI Localization
54250 APXINWKB Invoice Workbench JAI Localization
54250 APXINWKB Invoice Workbench Hide Validator values
54250 APXINWKB Invoice Workbench Displaying message when invoice is already validated
Stop transaction when user selecting account as 28000
54250 APXINWKB Invoice Workbench in Distributions
54250 APXINWKB Invoice Workbench GHG: Create Menu Items
GHG: Transaction View Zoom - Not allowed without
54250 APXINWKB Invoice Workbench invoice
GHG: Transactions View Zoom - Not allowed for Credit
54250 APXINWKB Invoice Workbench Memos
GHG: Open Environmental Transactions Form (View
54250 APXINWKB Invoice Workbench Window)
Stop transaction when user is seleAZW2cting accounts
54250 APXINWKB Invoice Workbench in 18040,18030,18020 other than prepayment
54250 APXINWKB Invoice Workbench GHG: Call Cancel Invoice Transactions
54250 APXINWKB Invoice Workbench GHG: Open Transactions Form
Stop Transaction when user select account code 28025
54250 APXINWKB Invoice Workbench & 28030 other than DM as invoice type
54301 APXIWALL Invoice Overview GHG: Set Form Defaults
GHG: Can Not Zoom From NULL Invoice - Create
54301 APXIWALL Invoice Overview Emissions
GHG: Can Not Zoom From NULL Invoice - View
54301 APXIWALL Invoice Overview Environmental Transactions
54301 APXIWALL Invoice Overview GHG: Create Environmental Transactions
54301 APXIWALL Invoice Overview GHG: View Environmental Transactions
54251 APXPAWKB Payment Workbench assign global variable
54251 APXPAWKB Payment Workbench Display Navigation to Milestone D2K form
54251 APXPAWKB Payment Workbench vendor number global variable
54251 APXPAWKB Payment Workbench Initialize zoom menu and global variables D2k Form
54251 APXPAWKB Payment Workbench Call Milestone Details D2K form
54251 APXPAWKB Payment Workbench assing total inthis
assinging inthis bill amount into payment invoice
54251 APXPAWKB Payment Workbench amount
validating invoice amount in both custom and seeded
54251 APXPAWKB Payment Workbench form
Auto populating payment document name using
54251 APXPAWKB Payment Workbench function
54392 ARXRWMAI Receipts Enable India Tax Detail Menu
disable search and apply and Apply buttons for
54392 ARXRWMAI Receipts Receivables responsibility
54392 ARXRWMAI Receipts Invoke Advance Receipt Tax UI
disable Search and Apply and Apply buttons for
54392 ARXRWMAI Receipts Receivables responsibility

Vol-2 Section 1: Scope of Work

13
 54392 ARXRWMAI Receipts No action for transaction number
54392 ARXRWMAI Receipts Show Popup Message with Different India Tax
54391 ARXTWMAI Transactions Enable India Tax Details Tools Menu
54391 ARXTWMAI Transactions Enable India Tax Details Tools Menu
54391 ARXTWMAI Transactions Enable India Tax Details Tools Menu
54391 ARXTWMAI Transactions Invoke O2C Common UI
54391 ARXTWMAI Transactions Invoke O2C Common UI
54391 ARXTWMAI Transactions Invoke O2C Common UI
54391 ARXTWMAI Transactions Invoke Advance Receipt Tax UI
54391 ARXTWMAI Transactions Invoke Advance Receipt Tax UI
54391 ARXTWMAI Transactions Invoke Advance Receipt Tax UI
54391 ARXTWMAI Transactions Disable Incomplete Button (TGW_HEADER)
54391 ARXTWMAI Transactions Disable Incomplete Button (TGW_HEADER)
54391 ARXTWMAI Transactions Disable Incomplete Button (TGW_HEADER)
Define Application
10004 FNDSCAUS User Restirct User - 0
59224 GHGORGS GHG : Organizations GHGORGS_ACCOUNT_RANGES_RO
59226 GHGSOURC GHG : Sources GHGVAR_RO
59226 GHGSOURC GHG : Sources GHGSOURC_COMBINATION_RO
59226 GHGSOURC GHG : Sources GHGSOURC_EMISSION_RO
59226 GHGSOURC GHG : Sources GHGSOURC_EMISSION_ENERGY_RO
59226 GHGSOURC GHG : Sources GHGSOURC_FACTOR_EXT_RO
59226 GHGSOURC GHG : Sources GHGVARI_RO
GHG : Transaction
59230 GHGTXNBT Batches GHGTXNBT_APP_RO
GHG : Transaction
59230 GHGTXNBT Batches GHG: Check GLOBAL.TRANSACTION_SET_ID
GHG : Transaction
59230 GHGTXNBT Batches GHG: Run Query
GHG : Transaction
59230 GHGTXNBT Batches GHGGLOVAR_RO
59232 GHGTXNS GHG : Transactions GHGTXNS_RO
Global variable to get item number for Open move
55445 INVTOTRX Transact Move Orders Orders
55445 INVTOTRX Transact Move Orders Adding Open Move Order label in tools menu
55445 INVTOTRX Transact Move Orders Calling Open Move Order Quantity form
Inventory Global Variable of Item for Open Indent and Qty details
52468 INVTTMTX Transactions Form
Inventory Calling Open Indents and Quantity Custom form form
52468 INVTTMTX Transactions DFF
Inventory
52468 INVTTMTX Transactions Adding Open Indents label in tools menu
Inventory
52468 INVTTMTX Transactions Calling Open Indents Quantity form
Inventory
52468 INVTTMTX Transactions GHG: Set Record Commit Counter
Inventory
52468 INVTTMTX Transactions GHG: Check For GHG Item
Inventory
52468 INVTTMTX Transactions GHG: Generate Transaction Issue
52890 INVTVTXN View Transactions GHG: Create Menu

Vol-2 Section 1: Scope of Work

14
 52890 INVTVTXN View Transactions GHG: Call Menu
52890 INVTVTXN View Transactions India: Enable India Tax Details Menu
52890 INVTVTXN View Transactions India: Invoke Receiving Tax Common
Define First Party
59399 JAINFPTY Registration Enable India Tax Details Tools Menu
Define First Party
59399 JAINFPTY Registration Invoke Configurations UI
59269 JAINNSTL Settlement Process Enable Repository Review Menu
59269 JAINNSTL Settlement Process Invoke Tax Repository Review - Header Level
59269 JAINNSTL Settlement Process Invoke Tax Repository Review - Line Level
India Tax Details -
59264 JAINTXOC Order to Cash Enable Receipt Match menu
India Tax Details -
59264 JAINTXOC Order to Cash Invoke Receit Match Function
India Tax Details -
59264 JAINTXOC Order to Cash Invoke SO Status Check
India Tax Details -
59264 JAINTXOC Order to Cash Add Taxes to Sales Order
India Tax Details -
59264 JAINTXOC Order to Cash Invoke Add Taxes to Sales Order
India Tax Details -
59265 JAINTXPP Procure to Pay Show Massege When We Select Recovery Category
India Tax Details -
59265 JAINTXPP Procure to Pay Define Claim Process Menu
India Tax Details -
59265 JAINTXPP Procure to Pay Invoke Claim Process UI
56053 OEXOEORD Sales Orders Enable Tax Details Tools Menu
56053 OEXOEORD Sales Orders Enable India Tax Details Tools Menu
56053 OEXOEORD Sales Orders Invoke O2C Common UI
56053 OEXOEORD Sales Orders Invoke O2C Common UI
58665 OEXOEPMT Payments Enable India Tax Detail Menu
58665 OEXOEPMT Payments Invoke Advance Receipt Tax UI
58402 OEXOETEL Quick Sales Orders Enable India Tax Details Tools Menu
58402 OEXOETEL Quick Sales Orders Invoke O2C Common UI
54461 PAXINRVW Invoices Enable India Tax Details Tools Menu
54461 PAXINRVW Invoices Invoke O2C Tax Common UI
53838 PAYWSGEV Define Rate Remove Value Column
54000 PERWSDJT Define Job Remove Approval Authority Segment
54000 PERWSDJT Define Job Remove Additional Employment Rights Button
54000 PERWSDJT Define Job Remove Bench Mark Job Button
54000 PERWSDJT Define Job Remove Bench Mark Job Name Segment
54000 PERWSDJT Define Job Remove Further Information Segment
54000 PERWSDJT Define Job Remove Requirement Button
54000 PERWSDJT Define Job Remove Evaluation Button
54000 PERWSDJT Define Job Remove Work Preference Button
54000 PERWSDJT Define Job Remove Map Surveys Button
F4 Define
54003 PERWSDOR Organization Remove Date To Field
F4 Define
54003 PERWSDOR Organization Rename From Date to Effective Date

Vol-2 Section 1: Scope of Work

15
 Enter Absence Remove the Following Fileds : Authorized by &
54012 PERWSEAD Information Number/Replaced by & Number
Enter Absence
54012 PERWSEAD Information Authorized by & Number/Replaced by & Number
Combined Person & Remove National Identifier Search Option from Find
54356 PERWSHRG Assignment Form Person Window
Combined Person &
54356 PERWSHRG Assignment Form Remove APPLICANT Tab hole
Combined Person &
54356 PERWSHRG Assignment Form Remove FURTHER Name Tab
Combined Person &
54356 PERWSHRG Assignment Form Remove OTHERS Tab
Combined Person &
54356 PERWSHRG Assignment Form In the Office Details Tab , Remove Mailstop Field
Combined Person & Remove following from Further Personal Info-
54356 PERWSHRG Assignment Form Residential Staus/Other Document if No Pan
Combined Person &
54356 PERWSHRG Assignment Form Remove MISCELLANEOUS Tab from Assignment Screen
Combined Person & Remove PROJECT INFORMATION Tab from Assignment
54356 PERWSHRG Assignment Form Screen
Combined Person & Remove BARGAINING UNIT Tab from Assignment
54356 PERWSHRG Assignment Form Screen
Combined Person &
54356 PERWSHRG Assignment Form Rename Salary Basis to Basic Pay
Combined Person &
54356 PERWSHRG Assignment Form Rename Assignment Number to Employee Number
Combined Person & Remove Following Fields: Assignment
54356 PERWSHRG Assignment Form Category/Collective Agreement/Employee Category.
Combined Person &
54356 PERWSHRG Assignment Form Rename Supervisor Name to Reporting Officer
Combined Person & Probation Period should be defaulted to 2 years from
54356 PERWSHRG Assignment Form Date of Hire
Combined Person &
54356 PERWSHRG Assignment Form Reporting Officer update
Combined Person &
54356 PERWSHRG Assignment Form Probation update
Combined Person &
54356 PERWSHRG Assignment Form Probation message
Combined Person &
54356 PERWSHRG Assignment Form Rename Job as Designation
Combined Person &
54356 PERWSHRG Assignment Form Validate Record
Combined Person &
54356 PERWSHRG Assignment Form Target Object
Combined Person &
54356 PERWSHRG Assignment Form Rename Org as Department
Combined Person &
54356 PERWSHRG Assignment Form Rename Grade as Pay Scale
Combined Person &
54356 PERWSHRG Assignment Form Probation period
Combined Person &
54356 PERWSHRG Assignment Form probation commit
54018 PERWSLOC F4 Define Location Remove Other Details Tab

Vol-2 Section 1: Scope of Work

16
 54018 PERWSLOC F4 Define Location Remove Extra Information Tab
54018 PERWSLOC F4 Define Location Remove Shipping Details Tab
Remove EXTRA INFORMATION Button from Previous
57963 PERWSPED Previous Employment Employment Page
54720 PERWSQUA Qualifications Remove LICENCE Tab form Qualification Page
54720 PERWSQUA Qualifications Remove TUTION Tab form Qualification Page
54720 PERWSQUA Qualifications Remove TRAINING Tab form Qualification Page
Remove PROFESSIONAL MEMBERSHIP Tab form
54720 PERWSQUA Qualifications Qualification Page
Remove QUALIFICATIONS FRAMEWORK DETAILS Tab
54720 PERWSQUA Qualifications form Qualification Page
Enter Purchase
54366 POXPOEPO Orders GUI Enable India Tax Details Tools Menu
Enter Purchase
54366 POXPOEPO Orders GUI Invoke P2P Common UI
Enter Purchase
54366 POXPOEPO Orders GUI Defaulting PO Approval
Enter Purchase
54366 POXPOEPO Orders GUI Enable PO Date Editing
Enter Purchase
54366 POXPOEPO Orders GUI Assign edited value
Enter Purchase
54366 POXPOEPO Orders GUI Validating creation Date
54367 POXPOERL Enter Release GUI Enable India Tax Details Tools Menu
54367 POXPOERL Enter Release GUI Invoke P2P Common UI
Purchase Order
54368 POXPOVPO Summary GUI Enable India Tax Details Tools Menu
Purchase Order
54368 POXPOVPO Summary GUI Invoke P2P Common UI
Enter Requisitions
54369 POXRQERQ GUI Enable India Tax Details Tools Menu
Enter Requisitions
54369 POXRQERQ GUI Invoke P2P Common UI
Requisition Summary
54379 POXRQVRQ GUI Enable India Tax Details Tools Menu
Requisition Summary
54379 POXRQVRQ GUI Invoke P2P Common UI
Enter RFQ's and
54371 POXSCERQ Quotes GUI Enable India Tax Details Tools Menu
Enter RFQ's and
54371 POXSCERQ Quotes GUI Enable India Tax Details Tools Menu
Enter RFQ's and
54371 POXSCERQ Quotes GUI Invoke P2P Common UI
Enter RFQ's and
54371 POXSCERQ Quotes GUI Invoke P2P Common UI
52899 RCVRCERC Enter Receipts GUI Validating Creation Date
52899 RCVRCERC Enter Receipts GUI Enable India Tax Details Tools Menu
52899 RCVRCERC Enter Receipts GUI Assigning the Receipt Date
52899 RCVRCERC Enter Receipts GUI Invoke India Tax Details UI(INTERFACE)
52899 RCVRCERC Enter Receipts GUI Message for Unsupported Match Option (Interface)
52899 RCVRCERC Enter Receipts GUI Invoke India Tax Details UI(Base)
52899 RCVRCERC Enter Receipts GUI Message for Unsupported Match Option (Base)

Vol-2 Section 1: Scope of Work

17
 52899 RCVRCERC Enter Receipts GUI Populate Jai Determination Factor Interface
52899 RCVRCERC Enter Receipts GUI Invoke India Tax Details UI(INTERFACE-Express)
52899 RCVRCERC Enter Receipts GUI Populate Jai Determination Factor Interface (Express)
Match Unordered
52900 RCVRCMUR Receipts Enable India Tax Details Tools Menu
Match Unordered
52900 RCVRCMUR Receipts Invoke India Tax Details UI(Base)
Match Unordered
52900 RCVRCMUR Receipts Message for Unsupported Match Option (Base)
Match Unordered
52900 RCVRCMUR Receipts Update det factor for unordered receipt
View Receiving
52901 RCVRCVRC Transactions GUI Enable India Tax Details Tools Menu
View Receiving
52901 RCVRCVRC Transactions GUI Message for Unsupported Match Option (Base)
View Receiving
52901 RCVRCVRC Transactions GUI Invoke India Tax Details UI(Base)
View Receiving
52901 RCVRCVRC Transactions GUI Enable India Tax Accounting Tools Menu
View Receiving
52901 RCVRCVRC Transactions GUI Invoke India Tax Accounting
54376 RCVTXECO Enter Corrections GUI Enable India Tax Details Tools Menu
54376 RCVTXECO Enter Corrections GUI Message for Unsupported Match Option(INTERFACE)
54376 RCVTXECO Enter Corrections GUI Invoke India Tax Details UI(INTERFACE)
54376 RCVTXECO Enter Corrections GUI Message for Unsupported Match Option(Base)
54376 RCVTXECO Enter Corrections GUI Invoke India Tax Details UI(Base)
54376 RCVTXECO Enter Corrections GUI Populate Jai Determination Factor Interface
54377 RCVTXERE Enter Returns GUI Enable India Tax Details Tools Menu
54377 RCVTXERE Enter Returns GUI Initialize line id
54377 RCVTXERE Enter Returns GUI Message for Unsupported Match Option (Interface)
54377 RCVTXERE Enter Returns GUI Invoke India Tax Details UI(INTERFACE)
54377 RCVTXERE Enter Returns GUI Message for Unsupported Match Option (Base)
54377 RCVTXERE Enter Returns GUI Invoke India Tax Details UI(Base)
54377 RCVTXERE Enter Returns GUI Populate Jai Determination Factor Interface
Enter Receiving
52904 RCVTXERT Transactions GUI Enable India Tax Details Tools Menu
Enter Receiving
52904 RCVTXERT Transactions GUI Invoke India Tax Details form (INTERFACE)
Enter Receiving
52904 RCVTXERT Transactions GUI Message for Unsupported Match Option (INTERFACE)
Enter Receiving
52904 RCVTXERT Transactions GUI Invoke India Tax Details form (Base)
Enter Receiving
52904 RCVTXERT Transactions GUI Message for Unsupported Match Option (Base)
Enter Receiving
52904 RCVTXERT Transactions GUI Populate Jai Determination Factor Interface
Shipping Transactions
56124 WSHFSTRX Form Enable India Tax Details Tools Menu
Shipping Transactions
56124 WSHFSTRX Form Stop Invoking O2C Common UI when Delivery is Null
Shipping Transactions
56124 WSHFSTRX Form Invoke O2C Common UI

Vol-2 Section 1: Scope of Work

18
 The scope of work shall broadly include, but not limited to, the following:
2.4 Analysis & Design
• Study, Requirement understanding and Analysis of existing ERP system of
ORGANIZATION (Functional, Technical, CEMLI & integrations)
• Detailed discussions with concerned stakeholders to understand the overall objectives
of the assignment.
• Vendor to access and provide a List of CEMLI components
• Identify the impacted CEMLI components due to Re-implementation
• Report the changes needed to make any customization works in R12 Environment.
• Analyze all integrations in existing system for updates or code changes, unit test and
support.
• Any DB Link Interfaces to be analyzed for updates or code changes, unit tested and
supported
• Analyze interface for any updates on configuration or code changes
• Finalization of Project Objectives/Requirements.
• Helps estimate the complexity of a re-implementation and facilitates efficient planning
and execution
• Detailed discussions with concerned stakeholders to understand the overall objectives
of the assignment.
• Detailed High level and Low level application designs.
• Migration of Legacy data from existing system to reconfigured ERP.
• Client Sign-off for Requirement Analysis
• Preparation of Content Structure/ Information Architecture for the application
• Approval of prototype (reconfigured ERP) by vendor
• Coordination and collection of required content from the concerned stakeholder
• Approval on the content gathered by the client department

2.5 Development & Testing

Development and testing by the bidder will include but not limited to:
• Reconfiguration, testing and implementation of ERP on test/development instance
server. Reconfiguration, testing, hosting will be done on existing server placed at
ORGANIZATION premises.
• Content Population (If Required)
• Integration with Existing Custom HRMS Module. Integration should be in such a way
that data of one system can be access from another and both applications have synced
data. EBS should be able to access HRMS data and generate reports from it as well as
HRMS should be able to EBS data for necessary usage.
• Integration with Maximo or Custom Asset Management module (Under
implementation at present) s
• Contract module for receivables and payables.
• system should be able to generate printable vouchers at all level of entry.
• Generation of statutory reports and discharge of statutory liabilities.
• Generation of Ledger of all G/Ls receivables/payables along with opening and closing
balance for any period.
• Generation of reports as per user need: department wise, project wise, location wise,
and at account level (eg. Station recovery and maintenance account) etc.
• Reconfiguration, Integration and Unit Testing, Integration Testing, System Testing and
Functional Testing.

Vol-2 Section 1: Scope of Work

19
 • Re-implementation will be with Standard ECC dashboards for Financials, SCM that
would be made available wherever possible along with few functional configurations
(roles, etc.).
• Perform customizations re-implementation and retrofitting
• Testing for the configuration and retro-fitted custom object and modules.
• Once the CEMLI code packs are re-implemented, standard flows are tested and
demonstrated by functional team in front of key users in workshops.
ORGANIZATION may in turn test CEMLI as well as Standard flows to verify that
CEMLI are intact post re- implementation.
• Familiarization sessions will be conducted to introduce and train key users on R12
new features (Train the trainer approach). The new features available in the R12 will
be discussed during these workshops in line with current business.
• Testing of reconfigured application based upon:
o Compliance to applicable guidelines
o Assess the user objective achievement etc.
• UAT Sign-off by user department
• Assist ORGANIZATION super users during User Acceptance Testing.
• Both Project Managers from Vendor and ORGANIZATION would discuss &
finalize the Production cut-over strategy
• Modification based upon user feedback
• Integration of the reconfigured ERP with existing Custom HRMS.

*During development vendor has to reconfigure the system on latest version of softwares,
applications, database etc.
*During Development phase required development team shall be stationed at
ORGANIZATION head office for smooth communication b/w development team and
ORGANIZATION Team. Bidder’s employees may have to travel to any other location of
ORGANIZATION.

2.6 Annual Maintenance and Support

The System Integrator shall provide stabilization support post implementation, as part of the
project. During the stabilization period the system Integrator would help ORGANIZATION
user to correct any troubleshooting while doing transactions or generating reports. The
system Integrator will update the user manuals and configuration manuals if required.
Any required configuration and/or customization required during this phase would be done
by System Integrator without any additional cost.
During the period of implementation and stabilization, System Integrator shall remain
responsible to arrange replacement and for setting right at his own cost any
software/application installed by him which is of defective manufacture or design or become
unworkable due to any cause whatsoever. The decision of ORGANIZATION
representative in this regards to direct the System Integrator to attend any damage or defect
in work shall be final and binding on System Integrator.

Annual maintenance wherever referred in this document includes “comprehensive onsite

support” with total responsibility for troubleshooting and rectifying the defective
components.
It will include (but not limited to) hardware maintenance and support, EBS application
maintenance and support, Oracle Licenses’ support and Database Maintenance and support.
Vendor will be responsible to provide support from OEM in any case, ORGANIZATION’s
contact will be with vendor’s team only.

Vol-2 Section 1: Scope of Work

20
 These services should be rendered within stipulated timelines duly adhering to the service
levels. The scope also includes but is not limited to provision of new release, patches, versions
of softwares including middleware, firmware, hardware, Database, testing tools and bug
correction.

After 03 months of implementation period and 03 months of stabilization period,

ORGANIZATION will enter into Annual Maintenance Contract for a total of 05 years.
Bidder agency will be responsible for AMC at each Business location of ORGANIZATION.

Annual maintenance and support services would include at least:

• Annual Maintenance of reconfigured ERP application (after integrating existing
custom HR module with it and stabilization) for a period of five years.
• Onsite and Offsite Managed support
• Reactive and preventive maintenance
• Configuration changes support
• Development changes support
• Preparation of User Manuals and other documents for the implemented ERP.
• Training to all users for better understanding and usage of application.
• Support in handover of applications to user department
• Regular updates to the system with respect to changes in taxation, legislations,
reporting requirements.
• Support Report changes and configuration changes.
• Support to all bolt-on / customizations in the ERP.
• Provide software license management related support to employer.
• Server / System Administration support.
• Data backup and recovery support.
• Database administration support.
• Data space management.
• One trained manpower having at least 03 years’ Oracle EBS functional support
experience and of commerce background (at least [Link]./ CA/ CA(Inter)/ CMA/
CMA(Inter)) who had been a part of development/reconfiguration team, equipped
with his/her own tools and computer/laptop stationed at ORGANIZATION head
office for complete onsite support and coordination with technical team for all
working days of ORGANIZATION during working hours.
• Onsite support for handholding the users, database recovery and data synchronization
after crash, performance tuning upgrades etc.
• Ensuring ERP solution OEM services for system performance, performance tuning,
upgrades etc.

2.7 Application Hosting

The hosting shall be done on sever placed at ORGANIZATION premises. The vendor has to
provide hardware maintenance service for the existing hardware for entire contract period.
The other features are:
• Be highly reliable with at least 99.5% service up time.
• Ensure that security patches are regularly installed in their software and provide
proactive defense against malware and other cyber attacks
• Pro-actively monitor and maintain services to maximum server performance and up
time.
• Safeguard data privacy, confidentiality and security.
• Promptly inform ORGANIZATION about any changes to the T&C and/or their plan.

Vol-2 Section 1: Scope of Work

21
 • ORGANIZATION data needs to be backed up at regular frequency as decided by
ORGANIZATION to a designated server at ORGANIZATION data center.

2.8 License Arrangement

• ORGANIZATION has perpetual and ATS paid licenses mentioned under section 2.1.1
• ORGANIZATION has 15 Nos. Oracle Financials – Application User Perpetual
licenses and approx. 30 application users in finance are proposed to use the finance
related modules. Bidder is to ensure either of the following:
a. Use a Bolt-on/Customization/SSO or any other legal technological innovative
methodology to ensure that all finance users can use the system without increasing
the number of licenses. There should be proper audit logs available identifying user
committing a transaction. There should no loss or difference in
privilege/functionality vis-à-vis usage at present.
b. Bidder shall make provision for procuring additional licenses and its ATS in their
bid. ORGANIZATION shall not pay any additional amount for the same to bidder
or the OEM (onetime or recurring). The system should support 30 finance user
during the period of the contract.
c. Bidder may, in consultation with ORGANIZATION, exchange less used licenses
listed under section 2.1 for more useful licenses in such a manner that
ORGANIZATION does not incur any additional cost and rather reduce its ATS
expenditure.

2.9 Other Deliverables

• High Level Design/ Architecture Document
• Performance Test Reports
• Security Test Reports
• Deployment Script
• API for accessing data stored in database
• User Manual/SOP
• Technical Manual
• Data Backup/ Archival Process
• Requirement Traceability Matrix
• Source Code
• Infrastructure design document
• At the end of 05 Years, the agency needs to provide ORGANIZATION data in a
format / media acceptable to ORGANIZATION.

Note: Final payment would be processed after confirmation of handover of all

deliverables.

Vol-2 Section 1: Scope of Work

22
 Section 2

Functional Requirement Specifications (FRS)

For ERP Application

Vol-2 Section 2: Functional Requirement Specifications

23
 Functional Requirement Specifications

Broadly the ERP Application will have (but not limited to) the below mentioned
functionalities and users at each business locations should be able to ((but not limited to))
perform all the functions mentioned below:

1.1 Financial Management

Response from
Sl. No. Description Bidder (Yes/No) Comments

General Ledger

It should be possible to group journal

1 entries by type or date

It should be possible to enter a journal

2 without entering batch information

User should be able to enter a category

while entering a journal, to describe the
3 purpose of the journal

The General Ledger module should be

integrated with payables, receivables, fixed
assets, purchasing, projects, cash
4 management etc.

It should be possible to import budget,

actual and encumbrance data from external
5 systems into the general ledger

There should be support for multiple

6 currencies in the general ledger

There should be a facility for budgeting in

the general ledger (through cost centers or
7 department wise)

It should be possible to import budget

amounts from external sources (like excel
8 sheets etc.)

Required number of secondary ledgers

9 should be assignable to a primary ledger

It should be possible to enter additional

descriptive information about journal lines
10 while entering journal

Vol-2 Section 2: Functional Requirement Specifications

24
 Response from
Sl No. Description Bidder (Yes/No) Comments

It should be possible to specify how to

round off the amount of tax while entering a
11 journal

The system should support entering of

12 statistical journals

It should be possible to enter a combined

13 statistical and monetary journal

It should be possible to create a new journal

batch by copying and modifying an existing
14 journal batch

It should be possible to change the period of

15 an un-posted batch

It should be possible to change the journal

16 entry currency in an un-posted journal

It should be possible to check, reserve or un-

reserve funds for individual journal entries
17 or a journal batch

There should be a facility to prevent the

Reviewing and Correcting Balances of a
journal or journal batch if proper approvals
18 are not taken

There should be a facility to prevent the

posting of a journal or journal batch if
19 proper approvals are not taken

It should be possible to create journal

entries in a spreadsheet and later upload to
20 the general ledger

It should be possible to enter journal entries

21 for a prior period

It should be possible to enter journal entries

22 for a future period

There should be a possibility to review

23 transactions under budgetary control

It should be possible to review details of

24 transactions under budgetary control

Vol-2 Section 2: Functional Requirement Specifications

25
 Response from
Sl No. Description Bidder(Yes/No) Comments

There should be a possibility to print a

report containing details of all the
25 transactions under budgetary control

It should be possible to submit journals and

journal batches for approval to the
26 appropriate approvers

It should be possible to specify whether the

person preparing the journal should be able
27 to approve it or not

The system should be able to notify the

preparer of a journal if the approver gives
28 no response for a certain number of days

It should be possible to allocate amounts

from any cost pool (revenues, expenses etc.)
29 to various accounts

It should be possible to allocate amounts

that reflect changes to a cost pool or update
30 previous allocations

It should be possible to distribute amounts

from one allocation pool to a subsidiary
31 allocation pool

It should be possible to use current,

historical, or estimated rates to allocate
costs such as employee benefits,
commissions, bad debt, warranty costs,
32 overhead etc.

It should be possible to use statistics such as

headcount, units of power sold, square
33 footage etc. to allocate allocation amounts

It should be possible to define journal

formulas for transactions which are
repeated every accounting period, such as
accruals, depreciation charges, allocations
34 etc.

It should be possible to create recurring

35 journal batches

Vol-2 Section 2: Functional Requirement Specifications

26
 Response from
Sl No. Description Bidder(Yes/No) Comments

There should be an option to automatically

copy entries from an existing recurring
36 journal batch

It should be possible to define certain

security rules to restrict access to recurring
37 journals

It should be possible to create recurring

journals and recurring journal batches in a
38 foreign currency

There should be an option to be able to use a

recurring journal for only specified periods
39 of time

There should be a facility to enter a

balancing amount line automatically when
40 creating a recurring journal

It should be possible to enter formulas to

41 calculate recurring journal amounts

It should be possible to enter unlimited

42 number of steps in a formula

It should be possible to use balances in

other accounts in the recurring journal
43 formula

It should be possible to create journal

entries which affect the same account each
44 period, but have different posting amounts

It should be possible to schedule a recurring

45 journal batch

There should be a provision to enter a batch

of journals which allocate financial amounts
across a group of cost centers, departments
46 etc.

It should be possible to copy an existing

batch of journals which allocate financial
amounts across a group of cost centers,
47 departments etc.

It should be possible to define certain

security rules to restrict access to recurring
48
journals which allocate financial amounts

Vol-2 Section 2: Functional Requirement Specifications

27
 Response from
Sl No. Description Bidder(Yes/No) Comments

across a group of cost centers, departments

etc.

It should be possible to import journals

from external programs like payroll,
49 accounts receivable, accounts payable etc.

There should be a possibility to correct or

modify data rejected during the journal
50 import process

It should be possible to correct or modify

51 accounts in journal import data

It should be possible to delete journal

52 import data as and when required

It should be possible to cancel the posting of

53 a journal batch

It should be possible to post a journal or a

54 journal batch to a suspense account

It should be possible to review the batch

55 posting status

There should be a possibility to correct

56 batch posting errors

It should be possible to automatically post

journal batches which meet a specific
57 criteria

It should be possible to schedule automatic

posting of a journal batch which meet a
58 specific criteria

It should be possible to post journal entries

to reverse accruals, estimates, errors, or
59 temporary adjustments and reclassifications

It should be possible to post journal entry

batches to reverse accruals, estimates,
errors, or temporary adjustments and
60 reclassifications

It should be possible to automatically

generate journal entries to reverse accruals,
estimates, errors, or temporary adjustments
61 and reclassifications

Vol-2 Section 2: Functional Requirement Specifications

28
 Response from
Sl No. Description Bidder(Yes/No) Comments

There should be an option to reverse journal

entries both by switching debit/credit and
62 by changing the sign

It should be possible to reconcile

transactions in General Ledger accounts
63 which should balance to zero

It should be possible to reconcile

64 transactions in multiple currencies

It should be possible to apply budgetary

control to purchasing, requisitions,
65 purchase orders and payables

There should be a provision for accounting

66 for encumbrances or pre-expenditures

It should be possible to enter encumbrance

67 batches

The system should be able to automatically

68 relieve encumbrances

It should be possible to manually relieve

69 encumbrances

It should be possible to review the funds

available and compare encumbrances and
70 expenditures with budgets

It should be possible to perform year-end

encumbrance processing, to identify
outstanding purchase order and requisition
encumbrances, cancel some or all of these
71 encumbrances etc.

There should be an option to view account

balances for multiple ledgers in a single
72 view by querying on ledger sets

It should be possible to drill down to see the

journal entries which comprise the account
73 balances

It should be possible to drill down to Sub-

ledger Accounting and then to sub ledger
transactions which comprise the journals
74 which comprise the account balances

Vol-2 Section 2: Functional Requirement Specifications

29
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to view journal and

sub-ledger transaction information as
balanced accounting entries or in the form
75 of T-accounts

It should be possible to perform an account

inquiry on ledger sets to view actual or
encumbrance account balances across
multiple ledgers that are assigned to a
76 ledger set

It should be possible to perform a journal

77 entry inquiry

It should be possible to perform online

78 inquiries on master and detail budgets

It should be possible to build custom

reports according to requirements with
complete control over the rows, columns,
79 contents and calculations

It should be possible to define reports

80 across ledgers in a ledger set

The system should be able to generate

financial reports such as income statements
and balance sheets, based upon data in the
general ledger across a ledger in a set of a
81 ledger

It should be possible to define reports with

reusable report objects, so that it is possible
to create new reports from the components
82 of already defined reports

It should be possible to print multiple

83 reports simultaneously

It should be possible to print the same

report for multiple ledgers, companies, cost
84 centers, departments etc.

It should be possible to schedule reports to

85 run automatically

The system should have the capability to

produce adhoc reports as and when
86 required

Vol-2 Section 2: Functional Requirement Specifications

30
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to print reports to tab-

delimited files for importing to other
87 spreadsheet programs

It should be possible to move balances by

period from one account to another or
merge balances by period from multiple
88 accounts into a single account

The system should ensure that all the

necessary postings from various other
modules (Like accounts payable, treasury
etc.) are posted to the ledger before starting
89 the closing run.

90 It should be possible to create calendars

It should be possible to reverse journal

91 entries with proper permissions.

92 It should be able to import journal entries.

Payables

The payables system should be fully

integrated to the general ledger and the
93 cashbook.

It should be possible to check and stop

creation of duplicate supplier master
94 accounts

There should be possibility to set up "one

time supplier" or ad hoc supplier account
for processing transactions for rarely used
suppliers so as to obviate the need to set up
95 individual master file records.

It should be possible to merge two or more

96 suppliers or service providers

Purge functionality should be available for

97 suppliers created in the system

System should be able to record details for

each supplier including payment method,
98 terms etc.

Automatic creation of supplier records from

99 external sources should be possible

Vol-2 Section 2: Functional Requirement Specifications

31
 Response from
Sl No. Description Bidder(Yes/No) Comments

There should be possibility to store legacy

100 supplier code and use it as a search criteria

Automatic numbering for suppliers should

101 be available

System should be able to associate bank

account information with suppliers to
102 enable automatic electronic payment

It should be possible to enter factoring

arrangements for suppliers and send
103 payments directly to the factoring agents

Prepayment accounts for each supplier

104 should be enterable in the system

Ability to make future dated payments and

have future dated payments account for
105 each supplier should be present

It should be possible to hold unmatched or

non-validated invoices for particular
106 suppliers

There should be possibility to specify

invoice tolerances and limits for each
107 supplier

It should be possible to have multiple sites

in different zones/circles for each supplier,
and designate sites as pay sites in each
108 zone/circle

Ability to create interest invoices for

109 overdue payments should be present

Possible to make separate payments for

110 different invoices from same supplier

There should be ability in the system to

111 import invoices/bills from external sources

Automatic invoice tax calculation and

112 processing should be possible

Support for automated tax calculation and

accounting of partially recoverable and non-
recoverable tax and other regional and local
113 taxes should be present

Vol-2 Section 2: Functional Requirement Specifications

32
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to create withholding

tax invoices manually as well as
114 automatically

System should be able to pay relevant

115 zonal/regional tax authority

Ability to project withholding tax should be

116 present

System should be able to handle pay on

117 receipt (ERS) or advance shipment notice

It should be possible to distribute invoice

118 amount among different accounts

There should be facility to manually allocate

invoice amount to different accounts at the
119 time of invoice creation

Ability to enter price corrections into

120 already existing invoices should be present

It should be possible to add new invoices to

121 existing batches

Invoices or bills received in foreign

122 currencies should be supported

User defined or automatic exchange rates

between currencies should be supported
123 while entering invoices

When a credit/debit memo is matched to an

invoice, the same distributions should be
124 applied to the memo as to the invoice

Possible to automatically create a debit

memo when goods are returned to a
125 supplier

Ability to enter invoices or debit/credit

memos for which both positive and negative
matching can be done against purchase
126 orders and other invoices should be present

It should be possible to both automatically

and manually create tax distributions for
127 invoices

Vol-2 Section 2: Functional Requirement Specifications

33
 Response from
Sl No. Description Bidder(Yes/No) Comments

System should be able to record VAT for

128 reporting purposes

Automatic accounting for recoverable,

partially recoverable and non-recoverable
129 tax should be supported

It should be possible to record freight

charges manually, by allocating freight to
invoice distributions, or through automatic
130 freight distributions

Ability to put holds on invoices, scheduled

131 payments or suppliers should be present

System should be able to schedule payments

automatically based on payment terms and
132 terms date of the invoice

It should be possible to make advance

133 payments in foreign currency

System should support automatic tax

134 calculation when applying prepayments

It should be possible to apply and release

135 holds on advance payments

System should be able to match credit and

136 debit memos to purchase orders

System should be able to generate ageing

137 analysis for outstanding invoices

System should be able to make payments as

138 per schedule payout dates automatically

Reflect invoice wise outstanding for a

particular supplier and for group of
139 suppliers

System should be able to make part

payment against an invoice and balance
140 payment on a subsequent date

It should be possible to make payment on

account to supplier and later link it to
141 invoice(s)

Vol-2 Section 2: Functional Requirement Specifications

34
 Response from
Sl No. Description Bidder(Yes/No) Comments

Deductions from invoices possible to be

recorded under various accounts like cash
142 discount, rebates etc.

2 way, 3 way and 4 way checking of invoices

143 should be available

System should be able to block invoices and

suppliers for payments along with reason
144 codes

It should be possible to record and account

for discrepancies arising out of physical
145 verification of inventory

It should be possible to run payment lists

146 for specific supplier types

It should be possible to run payment lists

147 for specific banks

System should be able to produce a

remittance advice for all payments made
148 (irrespective of method of payment).

System should provide an invoice register

facility by which invoices can be logged
149 prior to entry in the ledgers.

Giving advances to suppliers on basis of

150 purchase orders should be possible

Accounting for encumbrances should be

151 possible in the system

Ability to drill down from balances to sub

152 ledger transactions should be present

It should be possible to record zero amount

153 payments

It should be possible to record payments

154 made outside of Payables

Automatic numbering of payment

155 documents should be available

It should be possible to create payment for

an address different from supplier site
156 address

Vol-2 Section 2: Functional Requirement Specifications

35
 Response from
Sl No. Description Bidder(Yes/No) Comments

System should be able to prepare the

payment document (check) and save it for
157 printing later

It should be possible to account for

expenses where funds are actually not
158 disbursed

Ability to make payments in batches as per

159 user entered selection criteria

It should be possible to set limits on

160 payment amounts in batches

System should be able to create multiple

161 payment batches in different currencies

Scheduling automatic submission of

162 payment batches should be possible

Ability to send notifications to selected

people when payment batches are
163 completed should be available

It should be possible to modify payments

164 within a payment batch

System should be able to show the status of

165 each payment document

It should be possible to record partial

payment batches and restart/cancel the
printing of the rest of the payment
166 documents

Running multiple payment batches from the

167 same bank account should be possible

System should be able to create payments in

168 foreign currencies

System should be able to automatically

calculate maturity date for future dated
169 payments

It should be possible to create future dated

170 payment batches

System should be able to void/stop a future

171 dated payment

Vol-2 Section 2: Functional Requirement Specifications

36
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to control payable

172 periods

Ability to adjust balance of two or more

payables/creditors Account

Receivables

Accounts receivables should be fully

integrated to the general ledger and the
173 cashbook.

System should have the capability to check

for and stop creation of duplicate customer
174 accounts

It should be possible to perform advanced

searches for customers using user defined
175 criteria

System should be capable of handling user

defined rules for searching/duplicate
176 identification for customers

System should require searching for

customer/party before entering new
177 customer/party

There should be capability to perform fuzzy

178 searches for customers on different criteria

There should be possibility to add a

customer as either an organizational
179 consumer or individual consumer

It should be possible to create multiple

180 accounts for the same customer (e.g. if one
customer is using power at various locations
or is buying power for different purposes)

System should be able to store the details of

entities with which there is currently no
181 business (potential customers)

It should be possible to record relationships

182 between different customers

Vol-2 Section 2: Functional Requirement Specifications

37
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to associate a tax

183 profile with a customer

System should be capable of recording

different addresses/sites and
184 uses/purposes for customer accounts

Automatic Numbering of customers should

185 be available

It should be possible to enter information

about customers from third party sources
186 (e.g. credit rating)

It should be possible to have active and

187 inactive accounts for the same customer

Changing/updating customer account site

188 information should be possible

It should be possible to add/update a

189 customer profile

190 It should be possible to control AR Periods

It should be possible to define auto

191 accounting setup

192 It should be able to create manual invoice

It should be able to create invoice with

193 standard memo lines

194 It should be able to copy invoices

195 It should be able to set accounting rule

196 It should be able to create manual receipt

Cash Management

It should be possible to load bank

statements from an external source into the
197 system for intra day/ any specific period.

It should be possible to retrieve bank

198 statements already entered into the system

Vol-2 Section 2: Functional Requirement Specifications

38
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to load intra-day bank

199 statements into the system

The system should be capable of receiving

200 XML Bank Statements

It should be possible to import and reconcile

a bank statement in a single request for
201 intra day/ any specific period.

It should be possible to import and reconcile

an intra-day bank statement in a single
202 request

The system should have the capability to

203 validate bank statements

It should be possible to review bank

204 statement interface errors

It should be possible to correct bank

205 statement interface errors

It should be possible to enter bank

206 statements manually

207
It should be possible to update bank
statements already entered into the system

It should be possible to reconcile bank

208 statements automatically

There should be a provision to specify

209 reconciliation tolerances in the system

It should be possible to review

reconciliation and validation errors and
210 manual review and correction of errors

It should be possible to manually reconcile a

211 previously entered bank statement

It should be possible to create a new bank

212 statement line from reconciled transactions

It should be possible to review reconciled

213 transactions for a bank statement

It should be possible to review reconciled

214 transactions for a specific line

Vol-2 Section 2: Functional Requirement Specifications

39
 Response from
Sl No. Description Bidder(Yes/No) Comments

It should be possible to un-reconcile

215 transactions for statement lines

It should be possible to un-reconcile

216 transactions for a statement

It should be possible to create payments and

217 receipts from within the system`

There should be a feature to project the cash

needs and evaluate the company’s liquidity
218 position

The system should have a tool to view the

daily cash position by currency or bank
219 account

The system should be able to handle cash

220 pools and cash pooling

There should be a facility to create both

notional and physical cash pools in the
221 system

It should be possible to maintain balances

222 by accounts

There should be a possibility to maintain

223 balances for multiple accounts

Reporting

The system should have in-built Financial

intelligence to recognize various account
224 types (i.e. asset, liability, revenue, expense).

Ability to extend reporting capabilities

across and within all aspects of accounting
225 structure

Ability to self-monitor account alerts and

exceptions – Proactively monitor account
226 balances, sudden variances.

Ability to define multiple hierarchies that

227 are updated real-time

Vol-2 Section 2: Functional Requirement Specifications

40
 Response from
Sl No. Description Bidder(Yes/No) Comments

Ability to define corporate reporting and

analysis across multiple GLs without
disruption to current financial management
228 processes

To have Self-service and mobile reporting

229 options

Access to and proactive monitoring of

230 account balances directly from Excel

Stream account balances for near-instant

231 financial analysis and decision support

Ability to roll-up, drilldown, slice-and-dice,

232 and pivot data for fast and intuitive analysis

Ability to Intuitive audits of general ledger

233 balances with journal details

Self-service access to reports any time & this

234 module can be license or subscription base

1.2 Purchasing and Inventory Management

Response from
Sl No. Description Bidder(Yes/No) Comments

Material Master List

Ability to define different kind of items

like spare parts, consumables, service
items and other items required for
1 operation

Ability to define user defined functional

attributes for an item and search items
2 by functional attributes

Ability to capture the status of materials

3 (e.g. active, obsolete, discontinued, etc.)

Vol-2 Section 2: Functional Requirement Specifications

41
 Response from
Sl No. Description Bidder(Yes/No) Comments

Ability to maintain multiple units of

4 measure

Ability to support material hierarchy

(like a family product group and
5 classification)

Ability to track material by batch/lot or

6 serial number (as from the Supplier)

Ability to document different material

handling requirement (e.g. hazardous
7 material, expiry date, etc.)

Ability to capture internal lead time

(internal process and movement, e.g.
from requisition to stock/arrival at a
8 project, including QA)

Ability to provide a central catalogue

9 (accessible locally)

Ability to easy search a facility based on

several criteria (e.g. materials group,
functional, alphabetical, type of
materials, aliases, multilingual, Supplier
10 part number)

Ability to maintain single / multi-level

11 class hierarchies

Ability to have a workflow based

approval process for adding new item
or updating the attributes of the
12 existing item

Ability to store multiple Supplier names

13 for the same material / group

Capability to create, maintain and

synchronize single data repository for
the master data for the items across the
14 plants/ substations

Ready-list of attributes for the items in

15 the master data repository

Capability to conduct search on

16 parameters of the items

Vol-2 Section 2: Functional Requirement Specifications

42
 Response from
Sl No. Description Bidder(Yes/No) Comments

Capability to manage workflow driven

17 change for the master data of the items

Capability to enable data quality control

and role-based security for maintaining
18 the master data of the items

Capability to manage item relationships

19 for spare parts

Generation of reports related to Stores

as on any date along with name, qty,
20 value and total amount of stock.

21 Option to define stock valuation method

Capability to maintain stock register of

materials lying at different locations
separately as well as consolidated
22 report

Purchase Requisitions

Ability to initiate an electronic purchase

requisition and online approvals should
be done as per the defined approval
20 limits

Ability to reprocess an unapproved

21 purchase requisition

Ability to capture purchase requisitions

from multiple locations to create one
22 purchase order

Ability to support an electronic multi-

23 level requisition approval process

Ability to restrict purchases from the

24 approved/qualified suppliers only

Ability to accommodate on-line and

25 batch updating of requisitions

26 Ability to create requisition templates

27 Ability to check requisition summary

Vol-2 Section 2: Functional Requirement Specifications

43
 Response from
Sl No. Description Bidder(Yes/No) Comments

Purchase Orders & Purchase

Agreements

Ability for multiple purchasers to

28 approve a single Purchase Order

Ability to accommodate various types of

orders (e.g. blanket contract- contract
29 agreement, etc.)

Able to capture the delivery instruction

details which include details of the
quantity of material, time targets to be
delivered and the place of delivery and
30 all details

Able to enter multiple delivery dates for

items in a purchase order e.g. each line
item may have a different delivery date
31 or multiple line item delivery dates

Ability to do repeated purchasing (from

the previous Supplier) and copy
32 previous contract terms and conditions

Ability to change the approval process

33 in the system if the local policy changes

Ability to do unit of measure

conversions in purchase
34 orders/contracts

Ability to communicate purchase order

to supplier by email or using a supplier
35 portal

Ability to accept partial shipment

36 within a timeframe periods

Ability to attach text descriptions and

37 drawings to purchase orders

Ability to create automatically

numbered purchase order from a
38 purchase contract

Vol-2 Section 2: Functional Requirement Specifications

44
 Response from
Sl No. Description Bidder(Yes/No) Comments

Ability to show discount/rebates in the

39 contract

Ability to return material and keep the

Purchase Order (contract) open until
40 the returned material is replaced

Ability to purchase a material without

41 an item number (non stock item)

Ability to define and maintain purchase

of services (which does not require a
42 'receiving' process)

Ability to receive the services delivered

by supplier as a progress acceptance
(e.g. percentage) as well as "package" of
43 services

Ability to create single contract for

many different types of products
44 (services, materials or combined)

Ability to support centralized

45 purchasing.

Ability to check that a Supplier is not on

46 the blacklist

Ability to track a purchase order

(contract) based on purchase order
(contract) number and title of the
47 contract, type of materials

Ability to generate purchase orders

automatically (from history) as well as
48 manually

Ability to support the creation of

49 contracts for purchase agreements

Able to split purchase order between

vendors based on user defined
50 parameters

Ability to handle multiple currencies for

51 purchasing

Vol-2 Section 2: Functional Requirement Specifications

45
 Response from
Sl No. Description Bidder(Yes/No) Comments

Ability to send the material directly

from the vendor to the site in case of
52 emergency

The system should be able to keep track

of the local purchases details along with
the audit trails and this must be
53 accessible to the higher authorities

Ability to ensure that the vendor

payment happens only after the goods
are received at the stores in good
54 condition

Ability to maintain a centrally

negotiated blanket contract and allow
individual units to initiate the delivery
55 time, quantity and unit price

Ability to record amendment to the

56 contract

Ability to display the PO with all the

parameters including tax details at the
57 time of approval

Report to show the unused balance PO

58 at any date to cancel them

Receiving Process

The system should record goods

received against the purchase order and
highlight any variation in quantity
57 received.

Goods received note to be entered into

the system against the purchase order
58 number.

Able to create one purchase order

receipt from various consignment
59 receipt

Vol-2 Section 2: Functional Requirement Specifications

46
 Response from
Sl No. Description Bidder(Yes/No) Comments

The system should be able to show

what was actually ordered in the
60 specified purchase order

Ability to edit actual number received

from that displayed with proper
61 authorization

Goods received details to be

automatically transferred to the
Accounts Payable system for payment
after approval from the concerned
authorities. Payment should happen
only once the stores acknowledges the
62 receipt of goods in good condition

Able to store quality inspection details

for an item in the system and
subsequent recording of the results of
63 the inspection to be recorded

Ability to track materials damaged

during handling/transit and this
shortfall should be adjusted in the
64 inventory

Ability to generate and maintain Daily

65 material received details

Able to reject a consignment receipt yet

still enter the details into the system to
enable tracking and vendor
66 performance to be captured

The system should maintain and track

67 the details of the rejected material.

Ability to create Approval groups and

68 assign approval groups

69 Ability to Control purchasing periods

70 Ability to create buyers

Fixed Assets Module

Vol-2 Section 2: Functional Requirement Specifications

47
 Response from
Sl No. Description Bidder(Yes/No) Comments

Ability to create fixed assets with

componentization of assests in the
system through purchase from vendor
1 and capitalization of expense/CWIP

Ability to sale/ dispose off any asset or

part of asset and to set of the receivable
2 of the same.

Ability to calculate the taxes on

sales/dispose off and calculation of
profit and loss and subsequent
3 credit/debit in profit /loss Account.

Ability to change depreciation on

4 sale/dispose off of any asset.

Ability to change depreciation for who;e

5 or any part of any year as required.

Ability to change additional

depreciation automatically/manually
and creation of fixed assets register
6 with serial number of assets.

Ability to calculate depreciation for the

purpose of income tax after all
7 adjustments

Ability to configure assets tracking

numbers along with serial number of
8 the assets.

Generation of reports as required under

9 schedule II of Companies Act.

Process to define life of assets and

10 modification in the same.

Other required modifications in FA

11 Module.

Integration with Maximo/Custom Asset

12 Management Modules

Vol-2 Section 2: Functional Requirement Specifications

48
 Section 3

System – Solution Architecture for

reconfigured ERP

Vol-2 Section 2: System-Solution Architecture

49
 About this document
This document focuses on how the system solution architecture should look like. The contents of
the document are logically structured so as to make enhancements to this document as and when
there is opportunity, based on additional learning, to mature it to the higher level. The document
provides the expected technical architecture of the system.

While designing, building and operating the system, Bidder needs to comply with the guidelines
contained in this document.

Key Assumptions

Following key assumptions needs to be taken care while building the Architecture for
the system:
a) The system should look for transformational opportunities

Instead of imitating paper process in electronic form, applications should look to fully
embrace latest technological advancements to transform the processes completely and
offer wider choice and no/low touch point for all stakeholders to interact directly. It is
critical that project design are aligned to larger trends and designed for the future rather
than past.

b) Technology rapidly evolves and requires continuous adoption

Technology evolves way too fast and Government projects with its long procurement cycles
do not align naturally to adapt to this trend. Also, making changes to existing
implementations require contract changes, new RFP (Request for Proposal), etc. Hence it is
very essential that entire system is built by design to integrate not just within itself with
components coupled loosely to allow changes in sub-system level without affecting other
parts, architected to work completely within a heterogeneous compute, storage, and multi-
vendor environment. The system will also integrate and have bidirectional transfer of
information from various supplier systems. For this an open standards based approach
needs to be adopted so that manual intervention is kept to the minimum possible.

c) Ability to select best product at best rate in as and when required

Applications should be designed to get best cost and performance advantages of natural
technology curve (constant increase of speed and decrease of cost) and still aligned to open
procurement practices of the Government. For this to happen, architecture should be open,
use commodity hardware, have no vendor lock- in, and designed for horizontal scale. This
allows buying of commodity compute, storage, etc. only when needed at best price.

d) Multi-channel service delivery

With High penetration of mobility and very large percentage of internet usage using mobile
devices, it is imperative that the applications provide multiple channels of service delivery

Vol-2 Section 3: System-Solution Architecture

50
 to constituents. An important consideration is that the access devices and their screen
capabilities (including browser variations) are numerous and constantly evolving. Hence, it
is imperative to design the system such that an ecosystem that can adapt and continues to
evolve.

e) Data Security:

Security and privacy of data within the system will be foundational keeping in view the
sensitivity of data and critical nature of the infrastructure proposed to be built.

Vol-2 Section 3: System-Solution Architecture

51
 Chapter 1- Design Considerations of the System
1. Design Consideration for the system

Following are the design considerations that have been considered while conceptualizing
the solution.

1.1 Integrated Approach

Reconfigured ERP system will provide linkage to all stakeholders. It will be a common
medium of information sharing with standardized interfaces.

1.2 Distributed Access

One of the design considerations is to provide multiple channels/interfaces to respective

users to interact with the system from various types of access mechanisms.

1.3 Security & Privacy

Security and privacy of data should be fundamental in design of the system without
sacrificing utility and convenience. When creating a platform of this scale, it is imperative
that handling of privacy and security of data are not afterthoughts, but designed into the
strategy of the system from day one.

1.4 Configurability

All configurations including shall be captured in a central place within the system. Managing
these in a central repository ensures only once source of truth is used and reduces issues of
inconsistent application behavior. Decoupling of the business parameters from the rest of
the solution architecture and making them configurable allows for a great deal of flexibility.

1.5 Compliance

The compliance sub-sections in this document need to be submitted as part of

the Bidder/Agency’s technical proposal:

Description Complies (Yes/No)

Chapter-1 Adherence to Design

Considerations of the System

Vol-2 Section 3: System-Solution Architecture

52
 Chapter 2 - System Architecture Principles

2. ORGANIZATION system shall be built on the following core principles:

2.1 Openness

The system will need to interface with existing HRMS module / other integrations for bi-
directional information flow. Openness comes from use of open standards and using APIs
where available and interfaces for all components.

2.2 No Vendor lock-in and Replace ability

Use of commodity hardware

Commodity technology refers to hardware technologies that is completely commoditized

and are available from a variety of providers. Applications that are built on such
technologies are built on commodity computing architecture. This is one of the key
architecture decisions.

Applications that are architected to use commodity hardware fully benefit from using best
technologies at a cost effective rates and allow applications to not be tied to a proprietary
and vendor specific technology. Such applications also benefit best when technology evolves
at a rapid pace.

The System will be completely built using an open commodity hardware and scalable.
Such open scale-out architecture allows ORGANIZATION to procure latest servers from
any vendor / cloud service provider at the best price whenever required. Similarly, storage
layer also will not depend on any specialized hardware and takes advantage of heterogeneous
storage arrays having from multiple vendor.

2.3 Security and Privacy

The system will ensure privacy and data integrity and must disseminate data to authenticated
and authorized users only (both internal and external users). Security and privacy of data
within the system is foundational and is clearly reflected in ORGANIZATION’s strategy,
design and its processes throughout the system.

It is very important that all data is provided significant protection. It has to be ensured that
the data is handled with the utmost care within its own and Bidder/Agency domains and
follows some of the major principles of data privacy/protection recognized. Internally data
must be protected from all threats and must be kept confidential.

Activities such as anti-spoofing (no one should be able to masquerade for inappropriate
access), anti-sniffing (no one should be able get data and interpret it), anti-tampering (no one
should be able to put/change data which was not meant to be put/changed) should be taken
care for data in transit, as well as data at rest, from internal and external threats.

Vol-2 Section 3: System-Solution Architecture

53
 2.4 Scalability

a. Loose coupling through open API and messaging

It is critical that all 3rd party interfaces be fully interoperable without any affinity to
platforms, programming languages, network technologies.

b. Data partitioning and parallel processing

Considering the fact that the system will need to intract with custom HRMS portal and
handle HRMS data, data partitioning (or sharding) is integral to ensure as data and
volume grow, system can continue to scale without having bottlenecks at data access
level. Choice of appropriate data sources such as RDBMS, Object Oriented Databases,
distributed file systems; etc. (as required) must be made to ensure there is absolutely
no “single point of bottleneck” in the entire system including at the database and
system level to scale linearly using commodity hardware.

c. Horizontal scale for compute, Network and storage

The system architecture must be such that all components including compute, network
and storage must scale horizontally to ensure that additional resources (compute,
storage, network etc.) can be added as and when needed to achieve required scale. This
also ensures that capital investments can be made only when required. Given the
significance of the system, it is important that the scalability of the system be
measurable and demonstrable, before GO- Live.

2.5 Reliability

The system must have appropriate measures to ensure processing reliability for the
data received or accessed through the solution. It will be necessary that the following issues
be taken care properly:

a. Zero loss of data ( data already saved / date at rest should also not be lost)

b. Unauthorized access and alteration to Data in the system shall be prevented

c. Prevent processing of duplicate incoming files / data
2.6 Availability

The solution design and deployment architecture will ensure that the application offers
system High Availability.
2.7 Data Driven Decision Making

All the decisions making in the system shall be driven out of data and not on the basis
of assumptions.

2.8 Reconstruction of truth

Vol-2 Section 3: System-Solution Architecture

54
 System should NOT allow database/system administrators to make any changes to data.
It should ensure that the data and file (data at rest) that is kept in the systems has tamper
resistance capacity and source of truth (original data of invoices and final returns) could
be used to reconstruct derived data such as ledgers and system generated returns.
System should be able to detect any data tampering through matching of hash value and
should be able to reconstruct the truth.

2.9 Compliance
The compliance sub-sections in this document need to be submitted as part of
the Bidder/Agency’s technical proposal:

Description Complies (Yes/No)

Chapter-2 Conformance to Architecture

Principles of System

Signature of the bidder

Vol-2 Section 3: System-Solution Architecture

55
 Chapter 3 – High Level Architecture
Architecture Overview

3.1 The system shall be enabled based on prioritization of modules based on business
requirement. The system tightly integrates with all other components of the overall
technology landscape with bi-directional interfaces as required.

3.2 System accessibility through Ecosystem

The system shall be accessible across all kinds of devices including desktops, laptops,
Windows, Android, and IOS tablets and mobile phones.

3.3 Persistence and Data Stores

Operational Store (Partitioned Database): This would contain the operational data of
transactions in the ERP system. The data should be horizontally scalable. It is essential that
entire system is architected to work in parallel with appropriate data and system
partitioning. Data partitioning (or sharing) is integral to ensure as data and volume grow,
system can continue to scale without having bottlenecks at data access level. Architecture
also must support mechanisms for read only transactions to be against a replica instance
while insert/update transactions on primary instance.

3.4 MIS and Reporting:

The reporting component is critical to the success of the project as it will enable effective
decision making for all stakeholders.

Over a period of time, data will be accumulated to provide a wealth of information insight for
useful analysis both for compliance as well as to weed out interesting patterns and
exceptions.

Visualization and reporting:

i. The reporting tool should output data in various formats.

ii. There shall be separate reporting for each location/Business Unit and option should
be available to generate consolidated reports of all locations.

ii. The Reports generated by the system should be made accessible through API or an

Vol-2 Section 3: System-Solution Architecture

56
 interface to be viewed by the authorized users. The interface for the authorized users
should be simple with user friendly features such as drop down list, drag.

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

iv. The solution should be able to distribute reports and have the ability to save data for
later use or to a local PC/laptop/tablet or for other users to view. It should support
offline viewing and be able to send reports electronically to other users.

3.5 Anomaly Detection: The system should display alerts / information, based on certain
pre-defined criteria, if there is any deviation from the standard trend.

3.6 Data Warehouse (DW) is the repository that contains all data in its granular details. It is
important to note that data storage for reporting and analytics should be separated from the
core transaction data (data that is part of the live production systems). The advantage of the
highly de-normalized analytics data being completely separated is to ensure scalability and
make least impact to production systems.

3.7 Email service

Provision for automated messages to registered email ids be available in the system when
required. This may be through integration to email service used by organization.

3.38 Compliance
The compliance sub-sections in this document need to be submitted as part of
the Bidder/Agency’s technical proposal:

Description Complies (Yes/No)

Chapter-3 Conformance to High Level

Architecture

Vol-2 Section 3: System-Solution Architecture

57
 Chapter 4 - Security
Security is one of the utmost important aspects envisaged in the entire solution design of the
system. All key dimensions both from proactive and reactive security measures including
authentication, authorization, access control, logging and monitoring should be an integral
part of the system architecture.

4.1 Authentication and Authorization

1. The system should comply w i t h all requirements of s e c u r i t y , reliability a n d

non- repudiation.

a. Once the users enter their login credentials, the user credentials from the user
authentication server database must be verified and then only the access should be
granted.
b. Solution should have the functionality to provide authentication based on the role.

4.2 User and Identity Management

i. The solution should be capable of uniquely identifying all users of the system and their
activities.
ii. The solution should have the capability of providing user access rights to system and
data which will be in line with the defined functional requirements.
iii. The identified solution should be capable of supporting both on premise and
cloud implementation, or a hybrid of the two.
iv. The user account management component of the solution should address requesting,
establishing, issuing, suspending, modifying, and closing user accounts and related
privileges, with a proper approval process.

4.3 Application Security

i. The s y s tem must comply with the security guidelines as applicable

ii. Data output from an application should be validated to ensure that the processing
of stored information is correct and appropriate to the circumstances

iii. Should implement secure error handling practices in the application

4.4 Data Integrity

Data in transit (from external systems or between internal systems) or data at rest must be
protected from tampering. The risk is from both external users and internal users
(such as Database Administrators) who are close to the data at all times.

Vol-2 Section 3: System-Solution Architecture

58
 4.5 Data Confidentiality

To ensure data is secured to access only by required teams and applications, the following
principles are to be adhered:

1. All the databases must be accessed by individual user accounts and user accounts
cannot be shared by multiple persons or as a team based accounts.

2. All the databases/systems must be integrated with the Identity Access Management
system for centralized control. This will also enable disabling of user accounts when a
person leaves the organization.

3. Sensitive data stored in the main RDBMS tables must be encrypted so that
Database administrators do not have direct access to this information for misuse

4.6 Compliance

The compliance sub-sections in this document need to be submitted as part of

the Bidder/Agency’s technical proposal:

Description Complies (Yes/No)

Chapter-3 Conformance to Security

Vol-2 Section 3: System-Solution Architecture

59
 Chapter 5 – Quality Assurance
A thorough quality check is an integral part of any system deployment. The reconfigured
ERP shall be tested at all levels with well-defined test and use cases. Bidder/Agency
is expected to lay down a robust Quality Assurance program for testing of the
application for functionality, performance and security before putting in production
environment. The program must include an overall plan for testing and acceptance
of system, in which specific methods and steps should be clearly indicated and approved
by ORGANIZATION. Bidder/Agency is required to incorporate all suggestions /
feedback provided after the elaborate testing within a pre-defined, mutually agreed
timeline. Bidder/Agency must undertake the following:

a. Define the various levels or types of testing that will be performed for system.
b. Describe any technique that will be used for testing the system.
c. Indicate / demonstrate to ORGANIZATION that applications installed in the system
have been tested.

5.1 Testing

Bidder/Agency is expected to perform complete testing including Load testing,

performance testing, and integration testing.

5.2 Performance and Load Testing

Bidder/Agency is expected to implement performance and load testing with following

features:

i. Bidder/Agency should perform the load testing of the applications for multiple
workload profiles, multiple scenarios, and user loads to handle the envisaged
users of the system.

iii. Different activities before load testing i.e. identification of work load profiles,
scenarios, information capturing report formats, creation of testing scripts,
infrastructure detailing and workload profile should be prepared before the start of
actual load testing exercise.

iv. Should monitor resource utilization including memory leakage, CPU overload and
network overload. Should have the ability to split end-to-end response time for
Network & Server(s) and provide drill-down capability to identify and isolate
bottlenecks.

v. System should be seamlessly integrated with the existing HRMS Module.

Vol-2 Section 3: System-Solution Architecture

60
 5.3 Compliance
The compliance sub-sections in this document need to be submitted as part of
the Bidder/Agency’s technical proposal:

Description Complies (Yes/No)

Chapter-3 Conformance to Quality

Assurance.

Signature of the bidder

Vol-2 Section 3: System-Solution Architecture

61
 Section 4

Testing Requirements for

reconfigured ERP

Vol-2 Section 4: Testing Requirements

 Testing and Acceptance Criteria

i. Bidder shall demonstrate the following mentioned acceptance criteria prior to acceptance of the
solution as well as during project operations phase, in respect of scalability and performance etc. The
Bidder may propose further detailed Acceptance criteria which the ORGANIZATION will review.
Once ORGANIZATION provides its approval, the Acceptance criteria can be finalized. In case
required, parameters might be revised by ORGANIZATION in mutual agreement with bidder and
the revised parameters shall be considered for acceptance criteria. Bidder/Agency could set up a
testing environment in its own facility that is separate from the development, staging and
production environment. A comprehensive system should be set up that would have the
capability to log and track the testing results, upload and maintain the test cases and log and track
issues/bugs identified.

b. The following table depicts the details for the various kinds of testing envisaged for the project:

Type of Testing Responsibility Scope of Work

System Testing Bidder/Agency 1. Bidder/Agency to perform System testing

where the reconfiguration work is being executed

2. Should be performed through manual as well as

automated methods.

Integration Testing Bidder/Agency 1. Bidder/Agency to perform Integration testing

in its own setup.

2. Integration testing to be performed through

manual as well as automated methods

Performance and • Bidder/Agency 1. Bidder/Agency to do performance and load

load Testing • ORGANIZATION/Th testing
ird Party Auditor (to
monitor the 2. Various performance parameters such as
Performance Testing) response time, throughput etc. should be taken
into account.

3. Test cases and results to be shared with

ORGANIZATION
Security Testing • Bidder/Agency 1. The solution should demonstrate compliance
(including • ORGANIZATION/Th with industry standard security requirements.
penetration and ird Party Auditor (to
vulnerability monitor the 3. Security testing to be carried out in the exact
testing) Performance Testing) same environment/architecture that would be set
up for production.

Vol-2 Section 5: Testing Requirements

63
 User Acceptance ORGANIZATION ORGANIZATION HR users to perform User
Testing of System Acceptance Testing

2. Bidder/Agency to prepare UAT test cases

Vol-2 Section 5: Testing Requirements

64
 3. UAT to be carried out in the exact
environment/architecture that would be set up
for production

4. Bidder/Agency should fix bugs and issues

raised during UAT and get approval on the fixes
from ORGANIZATION/third party Auditor
before production development

5. Changes in the application as an outcome of

UAT shall not be considered as change request.
Bidder/Agency has to rectify the observations.

Note:

a. Bidder needs to provide the details of the testing strategy and approach including details of
intended tools/environment to be used by Bidder for testing in its technical proposal.
ORGANIZATION does not intend to own the tools and all costs in this regard shall be borne by
the Bidder.

b. The Bidder shall work in a manner to satisfy all the testing requirements and adhere to the testing
strategy outlined. The Bidder must ensure deployment of necessary resources and tools during the
testing phases. The Bidder shall perform the testing of the solution based on the approved test plan,
document the results and shall fix the bugs found during the testing. It is the responsibility of the
Bidder to ensure that the solution delivered meets all the requirements specified in the RFP. The
Bidder shall take remedial action based on outcome of the tests.

c. The Bidder/Agency shall arrange for environments and tools for testing and for training as
envisaged. Post Go-Live; the production environment should not be used for testing and training
purpose. If any production data is used for testing, it should be masked and it should be protected.
Detailed process in this regard including security requirement should be provided by the
Bidder/Agency in its technical proposal. The process will be finalized with the selected bidder.

d. The cost of rectification of non-compliances shall be borne by the Bidder.

Vol-2 Section 5: Testing Requirements

65
 Section 5

Service Level Agreement (SLA)

Vol-2 Section 5: Service Level Agreement

66
 Service Level Agreements (SLA)

The SLA’s specify the levels of service to be provided by the Bidder/Agency to ORGANIZATION.
This level is also called the baseline. Any degradation in the performance of the solution and services
is subject to levying liquidated damages. The liquidated damages mentioned in this RFP are genuine
pre-estimate of damages likely to flow from the breach of timelines and service levels. The liquidated
damages mentioned in this RFP are not the sole and exclusive remedies available with
ORGANIZATION for any breach and Bidder/Agency shall not be relieved from any obligations by
virtue of payment of such liquidated damages

Definitions

Non-Working Days: All Sundays and Public Holidays.

*All Working and Non-working days (365 days in a calendar year).

24*7 means three shifts of 8 hours every day. This is applicable for all seven days of the week without
any non-working days. “Scheduled Maintenance Time” shall mean the time that the System is not in
service due to a scheduled activity as defined in this SLA. The scheduled maintenance time would not
be during 16X7 (7:00 am to 11:00 pm) timeframe. Further, scheduled maintenance time is planned
downtime taken after permission of ORGANIZATION.

“Scheduled operation time” means the scheduled operating hours of the System for the month. All
scheduled maintenance time on the system would be deducted from the total operation time for the
month to give the scheduled operation time.

“System or Application downtime” means accumulated time during which the System is totally
inoperable within the Scheduled Operation Time but outside the scheduled maintenance time and
measured from the time a call is logged with the Bidder/Agency of the failure or the failure is known
to the Bidder/Agency from the availability measurement tools to the time when the System is returned
to proper operation.

“Availability” means the time for which the services and facilities are available for conducting
operations on the system including application and associated infrastructure. Availability is defined
as: {(Scheduled Operation Time – System Downtime)/(Scheduled Operation Time)} * 100% measured
on monthly rest basis.

“Incident” refers to any event/abnormalities in the functioning of the any of IT Equipment/Services

that may lead to disruption in normal operations of the Data Centre, System or Application services.

Interpretation & General Instructions

During O&M phase, the SLA parameters shall be monitored on a quarterly basis as per the individual
SLA parameter requirements. In case the service levels cannot be achieved at service levels defined in
the tables below, it shall result in a breach of contract and shall invoke liquidated damages.

Vol-2 Section 5: Service Level Agreement

67
SLAs would be reported quarterly. A Service Level breach will occur if the Bidder/Agency fails to meet
Minimum Service Levels on a quarterly basis for a particular Service Level. Root cause analysis (RCA)
to be prepared for all cases of breach in SLA’s and shared with ORGANIZATION.

Overall Availability and Performance Measurements will be on a quarterly basis for the purpose of
Service Level reporting. Month wise “Availability and Performance Report” will be provided by the
Bidder/Agency every quarter in the ORGANIZATION suggested format and a review shall be
conducted based on this report. Availability and Performance Report provided to the
ORGANIZATION shall contain the summary of all incidents reported and associated performance
measurement for that period.

Maximum Liquidated damages are capped at 10% of Total Project Value. If the liquidated damages
during Development and Implementation phase exceed 10% of the Total project value, then
ORGANIZATION reserves the right to terminate the contract.

In case there are successive breaches of SLA’s for two quarters, ORGANIZATION can issue show
cause notice to the Bidder/Agency to explain the non-performance. Also meeting may be called
wherein Bidder/Agency needs to explain the action taken to prevent such recurrences in future. This is
without prejudice to other rights of ORGANIZATION.

Sr. SLA Parameter Description Target

No.

1. Team mobilization and Deployment of identified key personnel

commencement of work including in ORGANIZATION, mobilization of
deployment of key personnel on team and commencement of work as per <7 working
site the project schedule days

2. Delay in any of the project Measured as the difference between the <7 days
milestones planned date for the milestone and the
actual date of its completion

3. Delay in overall Go-Live date Measured as the difference between the <7 Days
planned date for the Go-Live and the
actual date of Go-Live

4. Training and capacity building Feedback to be taken from all attendees >75% of
training
audience to
give a
satisfactory
or above
rating (per
training)

Vol-2 Section 5: Service Level Agreement

68
Operations and Maintenance phase:

Availability
The table below captures the key parameter which will form part of the key Performance indicators
which the Bidder/ Agency needs to capture in its Monthly report to ORGANIZATION.
ORGANIZATION can highlight the indicators, which in ORGANIZATION’s opinion, are at a level
higher than expected. Bidder / Agency will have to take suitable action to ensure that the risks are
mitigated.

Sr. Key Performance Target Description

No. Indicator performance

1. Average uptime of the >= 99% Measured as the average uptime of server at
application DC/DR on a monthly basis. Uptime of the
equipment will be measured on 24 X 7 basis

Penalty

1. In case the bidder / agency is not able to meet the target and execute the job within the project
timelines mentioned for the milestones, a penalty of 2% of the entire contract amount shall
be imposed per week of delay.

2. During AMC Phase if any issues is not resolve within timeline decided by bidder/agency and
ORGANIZATIONL mutually, a penalty of 2% of the quarterly AMC amount shall be imposed
per week of delay.

Vol-2 Section 5: Service Level Agreement

69
 Section 6

Timeline

Vol-2 Section 6: Timeline 70

 Timelines and schedule of Reconfiguration

6.1 Project Timeline

The project delivery timelines are to be adhered to by the Bidder/Agency keeping in mind that the
project has been cast in an aggressive schedule and needs a sense of urgency and resource allocation
to ensure that the project is delivered in time within budgets. Technology will play an important role
in the execution of the overall ORGANIZATION project and thus it is critical that the Bidder/Agency
work on tight schedules with the best resources possible to deploy. Some of the key milestones are
given below. The time below is indicative; the Bidder/Agency may improve upon them to deliver the
project earlier if possible.

Time Allowed (From the date of

Sl. No. Milestone
award of contract) in weeks.

1 ERP User Requirement gathering T+1

2 Reconfiguration of ERP T+7
3 Integration with existing HRMS Module T+9
User Acceptance & Testing (UAT) and
4 T+11
reported issues resolution.
5 Go-Live T+12

T – Project start date i.e. the date of receipt of Letter of Acceptance of Award from Bidder Or Seven
(07) days after issuance of Letter of award to Bidder by ORGANIZATION whichever is earlier.

Vol-2 Section 6: Timeline

70