RFP for Integrated Financial Management ... - Mptreasury.org

RFP for Integrated Financial Management 

Information System 

Attachment B 

Functiionall Requiirement Speciifiicatiions 

Department of Finance 

Government of Madhya Pradesh 

Department of Finance, GoMP 1

Attachment B 

Functional Requirement Specifications 

Table of Contents 

1. Financial Management Information System............................................................... 5 

1.1 Plan and Budget...................................................................................................................5 

1.1.1 Project Management...................................................................................................5 

1.1.2 District Plan Preparation..........................................................................................11 

1.1.3 State Plan Preparation ..............................................................................................14 

1.1.4 Receipt Budget...........................................................................................................16 

1.1.5 Plan Budget Preparation ..........................................................................................17 

1.1.6 Plan Budget Preparation Revised Estimates.........................................................18 

1.1.7 Non Plan Budget Preparation.................................................................................20 

1.1.8 Non Plan Budget Preparation Revised Estimates................................................23 

1.1.9 Budget Management.................................................................................................25 

1.1.10 Budget Consolidation...............................................................................................30 

1.1.11 Payment of Advance from Contingency Fund.....................................................32 

1.1.12 Recoupment of Advance given from Contingency Fund...................................33 

1.1.13 Public Fund Account................................................................................................34 

1.1.14 Off –Budget Entries and Payments .......................................................................35 

1.2 Accounting & Bookkeeping.............................................................................................37 

1.2.1 Processing of Journal Vouchers and General Ledger Posting ...........................37 

1.2.2 Asset Account Management....................................................................................43 

1.2.3 Creation of Purchase Order ....................................................................................47 

1.2.4 Manage Receipts of Goods and Services...............................................................51 

1.2.5 Project/Contract Creation.......................................................................................53 

1.2.6 Project/Contract Management ...............................................................................57 

1.2.7 Contractor Bill Clearing ...........................................................................................59 

1.2.8 Advance Payment to Contractors...........................................................................63 

1.2.9 Works Contingency Expenses ................................................................................66 

1.3 Debt & Investment Management ...................................................................................68 

1.3.1 Raising Market Borrowings .....................................................................................70 

1.3.2 Repayment of Market Borrowing...........................................................................71 

1.3.3 Obtaining Loans from Financial Institutions .......................................................73 

1.3.4 Loan Repayment to Financial Institutions ............................................................76 

1.3.5 Loans from NABARD and their Repayment.......................................................78 

1.3.6 Obtaining Central Government Loans/Grants ...................................................81 

1.3.7 Central Government – Loan Repayments ............................................................82 

1.3.8 Loans for Externally Aided Projects ......................................................................85 

1.3.9 Obtaining Loans / advances from GoMP and its repayments by Corporations 

90 

1.3.10 Recording of Guarantees .........................................................................................92 

1.3.11 Updation of Guarantees...........................................................................................94 

1.3.12 Government Investments........................................................................................96 

1.4 State Receipts Management System................................................................................97 

1.4.1 State Receipts System ...............................................................................................97 

1.5 Treasury Disbursement System.....................................................................................102 


Attachment B 


1.5.1 Treasury Disbursement System.............................................................................102 

1.5.2 Financial Sanctions .................................................................................................106 

1.6 Deposits............................................................................................................................108 

1.6.1 Sanction and Account Creation for Deposits.....................................................108 

1.6.2 Fund Transfer to PD/ED Account.....................................................................110 

1.6.3 Revenue Deposits ...................................................................................................112 

1.6.4 Civil Court Deposits...............................................................................................113 

1.6.5 Local Fund Deposits ..............................................................................................116 

1.6.6 Lapsed Deposits......................................................................................................117 

1.6.7 Refund of Lapsed Deposits...................................................................................119 

1.6.8 Refund of Excess Revenue Receipts & Recoveries ...........................................121 

1.6.9 K-Deposit.................................................................................................................122 

1.7 Internal & Statutory Audit .............................................................................................124 

1.8 Strong Room Operations...............................................................................................126 

1.8.1 Government Stationary Procurement..................................................................126 

1.8.2 Material Storage under Strong Room...................................................................130 

1.8.3 Stamps Selling from Treasury ...............................................................................134 

1.8.4 Return of stored valuables from Treasury...........................................................136 

2. Human Resource Management Information System .............................................. 137 

2.1 Manpower Planning........................................................................................................137 

2.2 Recruitment......................................................................................................................138 

2.3 Confirmation....................................................................................................................139 

2.4 Leave Management .........................................................................................................140 

2.4.1 Leave Management (Earned and Availed)...........................................................140 

2.4.2 Leave Management (Earned and Availed)-Half Pay Leave ..............................142 

2.4.3 Leave Management (Availed Leaves) - Commuted (Medical Ground) ..........143 

2.4.4 Leave Management (Availed Leaves) - Commuted (On other Ground)........144 

2.4.5 Leave Management (Availed Leaves & Adjustment from leave to be earned in 

future) - Leave not due...........................................................................................................146 

2.5 Performance Management System (PMS) ...................................................................147 

2.6 Training and Learning Management.............................................................................149 

2.6.1 Training - Planning .................................................................................................149 

2.6.2 Training - Implementation.....................................................................................150 

2.6.3 Training – Learning Management.........................................................................151 

2.7 Promotion.........................................................................................................................152 

2.7.1 Promotion ................................................................................................................152 

2.7.2 Time Bound Pay Scale Enhancement (Kramonati)...........................................154 

2.8 Payroll Processing............................................................................................................156 

2.9 Other Employee Entitlement........................................................................................164 

2.9.1 Other Employee Entitlement (Loans and Advances) .......................................164 

2.9.2 Other Employee Entitlement [Claims (TA & Medical Re-imbursement)].....165 

2.10 Transfer Posting, Joining and Deputation...................................................................166 

2.10.1 Transfer Posting, Joining and Deputation ..........................................................166 

2.10.2 Deputation ...............................................................................................................168 

2.11 Employee Grievance Redressal.....................................................................................169 

2.12 Departmental Enquiry....................................................................................................171 


Attachment B 


2.13 Employee Exit .................................................................................................................173 

2.13.1 Employee Exit - Superannuation..........................................................................173 

2.13.2 Employee Exit: Other Exits (Death, Termination, VRS and Resignation, 

Compulsory retirement and Absorption/ Samvillyan)......................................................174 

2.14 Court Cases ......................................................................................................................175 

2.15 Pension Management Information System .................................................................177 

3. Citizen’s Grievance Redressal ................................................................................ 182 

4. General System requirements ................................................................................. 184 

5. Web Portal .............................................................................................................. 190 


Attachment B 


1. Financial Management Information System 

The following section captures detailed Functional Requirements of the financial processes 

as envisaged by the Integrated Human Resource & Government Financial Management 

System. 

1.1 Plan and Budget 

1.1.1 Project Management 

Table 1: Functional Requirement Specification – Project Management 

Business Requirement – Project Management 

Sr. No. 

Requirement Description 

1. System should make the project planning module available to HOOs and HODs 

on an ongoing basis 

2. System should provide the option of creating new projects 

3. System should generate a Project ID for every new project created and system 

should be able to generate a unique project number after the competent 

authority has accorded administrative approval and/or technical sanction for it 

4. Should create project profile for new projects and DPRs which should include: 

• Location 

• Name of project 

• Type of Project 

• Goal & Objectives (Outcome) of the Project 

• Current Situation 

• Gap Analysis 

• Strategy Options 

• Work Plan 

• Mode of funding (with alternative funding options) 

• Funding Agency 

• Major milestones 

• Activity Sets for each strategy 

• Criteria and Justification for selection of the final strategy 

• Outputs of each activity 

• Cost of each Activity 

• Total Cost of the Project 

5. Should have the details of work in progress projects which includes: 

• Name of the Project 

• Outcome of the project 

• Activity Detail 


Attachment B 


• Output of each activity 

• Milestones completed 

• Cost Incurred 

6. System should allow creation of a new activity and generate an activity ID 

7. System should allow breaking the strategy options into activity sets and provide 

the following details 

• Activity Name 

• Activity Description 

• Duration 

8. System should allow estimation of resources corresponding to each activity of 

the activity set 

9. System should be able to calculate the cost specific to each activity with the help 

of cost tables 

10. System should allow consolidation of cost specific to each activity set 

11. System should calculate the cost of the entire project 

12. Should create online cost-table 

13. Should allow Finance/Works Department to enter latest costs in the cost tables 

& SORs 

14. Should allow prioritization of strategy options based on least cost of the project 

15. Should identify projects with priority and outcome for each year, for each 

department 

16. Should maintain vendors database and standard rates in the form of a cost tables 

17. Should create and link projects, sub projects, activities and tasks 

18. Should create an Ad hoc project, where a work break down structure is not 

required 

19. Should be able to enter milestones , milestone dates and Key Performance 

Indicators in the system 

20. Should be able to enter monitoring Schedule 

21. Should assign project owner, project manager, accountable person and key 

stakeholders 

22. Should support for template based DPR/Draft project plan 

23. System should allow customizing the DPR format in the system which includes 

the outlines/formats/directives as given in the Government order 

Project Approvals/Execution 

24. System should have formats available for Administrative/Technical Sanctions 

for the projects 


Attachment B 


25. Should capture approvals (Administrative and/or Technical Sanctions) 

26. System should allow the stakeholders to apply for Administrative sanctions by 

Competent Authority for any project which is due for implementation 

27. System should allow stakeholders to seek technical sanction from a competent 

authority for the details & cost estimate of the project 

28. System should generate a Administrative and Technical sanction number for 

sanction issued for a project 

29. System should allow AS/TS for projects included in a plan i.e. approved by State 

Planning Commission 

30. System should allow AS/TS for projects which have to be initiated on an ad hoc 

basis and have not been approved in a plan 

31. System should allow issuing revised AS/TS in cases the expenditure goes 

beyond the approved estimates 

32. Should allow relevant stakeholders to monitor the projects and update physical 

and financial progress 

33. Should track completion of each module/activity, leading to the overall 

commissioning of project 

34. Should track changes made to the project plan & budgets 

35. Should allow HODs/HOOs to review the approved project plan submitted by 

the department from Project Plan module 

36. Should allow HODs/HOOs to review the activities line items of each approved 

Project /Programme provided under the Planned Budget of the current 

Financial Year 

37. Should allow project estimate to be maintained so that revised estimates can be 

computed in combination with the actual to date expenditure 

38. Should provide a view of projects/plans to HODs/HOOs on the basis of the 

priority of the project 

39. Should be able to provide the following details of the Work In Progress project 

• Project ID 

• Activity ID 

• Activity List 

• Current Status of activity 

• Milestones achieved 

• Pending activities 

• Budgeted Estimate 


40. Should allow HODs/HOOs to enter the following data corresponding to 

pending activities 

• Activities to be completed in the current Financial Year 

• Probable End Date 

41. Should be able to input the following details of approved projects but not 

started 


Attachment B 


• Probable Start Date 


• Cost associated with each activity 

42. Should allow HODs/HOOs to refer to the cost tables for probable cost of each 

activity for work-in-progress and uninitiated projects 

43. Should allow administrative department to access/modify the projects available 

in the project management module 

44. Should make the revised estimate forms available online 

45. Should keep a track of the revisions done to the project plan 

Project Scheduling 

46. Should allow activity scheduling using PERT/CPM 

47. Should support for attachments such as drawings, specs, instructions etc., in 

formats such as PDF, CAD, Visio, text/flat files, PPT, XLS, DOC, RTF, TIF, 

GIF, JPEG etc., 

Project Monitoring 

48. Should monitor each activity/task in the project 

49. Should allow HODs/HOOs to review the approved project plan submitted by 

the department 

50. Should allow HODs/HOOs to review the activities line items of each approved 

Project /Programme provided under the Planned Budget of the current 

Financial Year 

51. Should allow project estimate to be maintained so that revised estimates can be 

computed in combination with the actual to date expenditure 

52. Should provide a view of projects/plans to HODs/HOOs on the basis of the 

priority of the project 

53. Should be able to assist in project monitoring by providing the following details 

of the Work In Progress project 




• Current Status of activity 

• Pending activities 

• Milestones 

• Budgeted Estimate 


54. Should allow HODs/HOOs to enter the following data corresponding to 

pending activities 



Attachment B 


• Probable End Date 

55. Should be able to input the following details of approved projects but not 

started 

• Probable Start Date 


• Cost associated with each activity 

56. Should allow HODs/HOOs to refer to the cost tables for probable cost of each 

activity for work-in-progress and uninitiated projects 



59. Should monitor variations from schedules and send alerts 

60. Should generate alerts for delay in starting/completion major 

activities/milestones 

61. Should monitor estimates versus actual : money amounts, services, labor, time 

span, vehicles used etc., 

62. Should monitor all projects consolidated, individual projects and individual tasks 

63. Should store baseline and revised plans 

64. Should display project total, accumulated costs in terms of actual, revenue, 

capitalization costs, future commitments etc., 

65. Should maintain project percentage completed status -based on work to date. 

66. System should link the project plan module with the office accounting system 

for creation of asset in asset register 

General Requirements 

67. Should capture the data pertaining to all aspects of projects 

68. Should track resource across projects 

69. Should enable what-if modeling scenarios 

70. Should record the costs for each major project or a set of activities under 

investigation 

71. Should do analysis of resources used on a project compared to the estimates for 

different categories, i.e., money, time, materials, overheads etc. 

72. Should maintain the records for the duration of the project; 

73. Should generate management reports. 

74. Should reflect inflation in project costs, highlight and correct errors, if detected 

in project management with proper notifications and authorization controls 


Attachment B 


75. Should maintain complete data on any project must be kept throughout the life 

of a project and must be able to be printed out and/or reviewed on screen at any 

time. 

76. Should capture documentation related to execution of various projects (existing 

& old) for retrospective analysis in future. 

77. Should enable online project management process by enabling team members to 

easily manage, track, and report on their project activities through familiar tools, 

like the Web. 

78. Should incorporate security measures, to limit changes by project owners to only 

their respective projects and simulations 

79. Should track changes, with reasons 

80. Should establish security measures to ensure that the personnel are allowed to 

review/edit projects they are involved with. 

81. Should be able to re-open closed projects 

82. Should notify all appropriate personnel, that a project is closed 

83. Should provide security measures, to ensure that the project closure is done by 

authorized personnel only 

84. Should print project reports at summary level and detailed level 


Attachment B 


1.1.2 District Plan Preparation 

Table 2: Functional Requirement Specification - District Plan Preparation 

Business Requirement – District Plan Preparation 

Sr. No. 


1. Should allow HOOs to prepare district plan after identifying projects based on 

priority and outcome from planning module 

2. Should allow HOOs to view the consolidated yearly resources requirements for 

new projects 

3. Should allow HOOs to view the consolidated yearly resources requirements for 

ongoing projects 

4. Should allow HOOs to consolidate the yearly resources requirements for new 

and existing projects 

5. Should compile the draft plan for new and ongoing projects having following 

details 

• Locations 

• Project Name 

• Outcomes 

• Duration 

• Cost Estimates 

• Justification 

• Combined Priority 

• Implementation details of on-going projects 

6. Should enable HOOs to submit the draft plan to the District Planning 

Committee 

7. Should send the listed details of the district project plan to District Planning 

Committee 

• Locations 

• Project List 

• Outcomes 



• Combined Priority including MTEF requirements 


8. Should provide an option to DPC to drill down to the complete details of each 

project 


• New or Rolling Project 

• Cost associated with new Project 

• Cost associated with ongoing projects 

• Priority of Project 


Attachment B 


• Probable start date 

• Outcome of Project 


• Cost Breakdown of activities 

• Brief Description 

• Duration of project 

• Start Date 

• End Date 


9. System should generate alerts in the form of notifications sent to DPCs as a 

confirmation of submission of project charter (proposed plan) 

10. System should provide a consolidated view of the draft district plan submitted 

by all the HOOs 

11. Should allow DPC to review the draft district plan and provide 

approval/rejection/modification 

12. Should allow HOOs to make changes in the project if revisions have been asked 

to be made by DPC 

13. System should allow DPC to enter the remarks of discussions with the Tribal 

and Welfare Department (TWD) in the system against the district plan prepared 

14. System should allow DPC to enter the percentage of district plan to be reserved 

for the tribal welfare (TSP) 

15. Should notify State Planning Commission of the submission of Proposed 

District Plan by DPC 

16. Should allow State Planning Commission to view the important details of the 

submitted plan 


• Impact/Outcome of Project 

• Cost associated with the project 

17. Should enable State Planning Commission to pull the complete details of the 

project if required 

18. Should give an option to State Planning Commission to approve/reject 

components/Items of the proposed District plan. 

19. Should allow field for providing relevant comments 

20. Should send a notification to the respective HODs and Administrative 

Department Head about the approval of the district component of the 

departmental plan 

21. System should allow the head of Administrative department to view the district 

component approved by the DPC and State Planning Commission 

22. Should provide an option to Head of Administrative Department, HODs and 

HOOs to search and sort a project/activity on the listed criteria 

• District Name (ID) 



Attachment B 



• Desired output 

• Lowest cost 


Attachment B 


1.1.3 State Plan Preparation 

Table 3: Functional Requirement Specification - Sate Plan Preparation 

Business Requirement – State Plan Preparation 

Sr. No. 


1. Should allow HODs to prepare draft state plan after identifying projects based 

on priority and outcome from project management module 

2. Should port and copy required fields’ information from project management 

module onto the format of state plan proposal 

3. Should allow HODs to view the consolidated yearly requirements for new 

projects including district plan 

4. Should allow HODs to view the consolidated yearly requirements for ongoing 


5. Should allow HODs to consolidate the yearly requirements for new and existing 


6. Should compile the draft state plan having following details 

• Locations 


• Duration 

• Outcomes 



• Combined Priority including MTEF requirements 


7. System should provide the option to HODs for consolidating the yearly budget 

requirements for state focus projects and district plan 

8. System should allow HODs to submit the department project plan to State 

Planning Commission 

9. Should provide notification to State Planning Commission for submission of 

Draft plan by HODs 

10. System will provide the notification in the form of an email in the customized 

mail box for each login 

11. Should provide a consolidated view to State Planning Commission for plan of 

each department 

12. Should allow State Planning Commission to view the important details of the 

submitted plan 


• Priority 

• Impact/Outcome of Projects 

• Cost associated with the project 

• Projects under implementation 


Attachment B 


13. Should allow HOD to prepare PPT for presentation of state plan and access 

detail (DPR) of any project during discussions 

14. Should allow State Planning Commission to provide 

approval/modifications/rejection for item/components with appropriate 

remarks of the consolidated department plan 

15. System should allow State Planning Commission to enter the remarks of 

discussions with the Tribal and Welfare Department (TWD) in the system 

against the plan prepared for state focus projects 

16. System should allow State Planning Commission to enter the percentage of plan 

for state focus projects to be reserved for the tribal welfare (TSP) 

17. Should allow State Planning Commission to modify the priority of the project as 

specified by HODs/HOOs 

18. Should provide HODs the option of modifying the project plans in case of any 

revisions are asked by State Planning Commission 

19. Should allow Head of Administrative Department to view and review the 

consolidated departmental plan in the system 

20. Should allow State Planning Commission the option of drilling down and 

analyzing the cost associated with each activity 

21. Should allow State Planning Commission the option to consolidate State Plan 

(using defined parameters/criteria) for submission to Planning Commission 

22. Should allow State Planning Commission the option to access any level of 

available details during discussions with Planning Commission 

23. Should allow State Planning Commission to update the state and department 

ceiling in the system as provided by Planning Commission 

24. Should send a notification to the HODs, Finance Department and Head of 

Administrative Department for the ceiling entered in the system 

25. Should allow the Finance Department to override the ceiling provided by State 

Planning Commission and provide a new ceiling for the departments in the 

system depending on the resources available 

26. Should allow HODs to re-allocate the ceiling into the system to HOOs 

27. Should send notifications to HOOs for the ceiling entered in the system 

28. System should make the project plan editable to introduce any changes that are 

required to ensure compliance with the state/district plan ceiling 


Attachment B 


1.1.4 Receipt Budget 

Table 4: Functional Requirement Specification – Receipt Budget 

Business Requirement – Receipt Budget 

Sr. No. 


1. System should have formats for preparing the receipt budget 

2. System should allow HOO/HODs to access the receipt budget formats and 

prepare receipt budget estimates 

3. System should allow integration of the budget formats with receipt system and 

debt management system 

4. System should allow extracting the following data from the receipt system 

• Tax revenue 

• Non-Tax revenue 

• Fees & Grants 

• Etc. 

5. System should allow integration of the receipt budget formats with debt 

management module for the following data 

• Loans and Advances 

• Interest Payment 

• Write off bad debts 

• Etc. 

6. System should allow forecasts/estimates on the basis of trend analysis using 

receipt database 

7. System should allow submission of the budget estimates for receipts by 

HOO/HODs to Head of Administrative Department 

8. System should allow Head of Administrative Departments to view and 

consolidate the receipt budget 

9. System should allow Head of Department to submit the estimates to Finance 

Department 

10. System should allow Department of Finance to view and consolidate the 

estimates 

11. System should allow Department of Finance to forecasts/estimates in other 

receipt heads and consolidate the receipt budget for the entire state 

12. System should project actual collections month by month against each item of 

forecasted/estimated/projected receipt for each HOO/HOD/Administrative 

Department 


Attachment B 


1.1.5 Plan Budget Preparation 

Table 5: Functional Requirement Specification – Plan Budget Preparation 

Business Requirement – Plan Budget Preparation 

Sr. No. 


1. Should provide a functionality in the Project plan module to prepare the budget 

for the approved department projects and schemes on the basis of cost estimates 

2. Should allow HOOs/HODs to capture the cost estimates and other details in 

the Plan budget form which include 

• Location 

• Object Head 


• Cost of Project 

• Implementation details of rollout projects 

3. Should allow HODs to prepare the department plan budget based on the 

requirements of the new and rollover projects created in the project plan module 

4. Should allow HODs to consolidate the budget prepared by HOOs with the state 

plan budget 

5. Should allow the HODs to submit the plan budget estimates to the Head of 

Administrative Department 

6. Should allow Head of Administrative Department to view the consolidated 

budget estimates for the department 

7. Should allow HODs/Head of Administrative Department to compare plan 

budget with MTEF requirements 

8. Should allow Head of Administrative Department to submit the approved 

consolidated budget to the Finance Department 

9. Should provide an option to allocate a part of the plan budget to priority sector 

(Tribal & SC) 


Attachment B 


1.1.6 Plan Budget Preparation Revised Estimates 

Table 6: Functional Requirement Specification – Plan Budget Preparation Revised Estimates 

Business Requirement –Plan Budget Preparation Revised Estimates 

Sr. No. 


1. System should allow HOOs/HODs to review the project management module 

to check the status of the approved new and rollover (long/short term) projects 

under implementation 

2. System should give a list of all the projects (new and rollover) that have been 

included for the current financial year plan 

3. Should allow HOOs/HODs to consider activities line items of each approved 

Project /Programme Provided under the Planned Budget of the FY 

4. System should allow HOOs/HODs to review financial and physical progress 

(activities & milestones) of the projects 

5. System should consider the extent to which the activities/ of a plan/programme 

under implementation have been completed so far and are planned/ likely to be 

completed in remaining months of the FY 

6. System should give the detail of expenditure incurred till date and the milestones 

achieved corresponding to the expenditure 

7. System should allow to finalize the likely start date for the activities remaining 

for the balance months of current financial year 

8. System should allow compilation of cost for each activity head wise which are 

expected to be incurred in the remaining months of current financial year 

9. System should allow apportioning budget from one project, with likely savings, 

to another, with likely excesses, within the same head of account to 

HOO/HOD 

10. System should allow re-appropriation of budget from one project, with likely 

savings, to another, with likely excesses, within the same major head of account 

to HOD within delegation of powers 

11. System should allow formulation of proposals for re-appropriation of budget 

from one project, with likely savings, to another, with likely excesses, outside the 

powers of HOO/DOD, for submission to Administrative Department 

12. System should allow preparation of proposal for additional grant or surrender of 

budget as the case may be for/from individual project/head of account 

13. While considering re-appropriation of saving or additional grants to another 

project, MTEF level for the year (including backlog if any) for the heads of 

accounts affected 

14. System should allow accessing the revised budget estimate form in the system 

15. System should pull the budgeted estimate in the form for the current financial 

year 

16. System should populate the re-appropriation, re-allocations, surrenders, revised 

requirements for the remaining months etc. done as on the date for preparation 


Attachment B 


of revised estimates 

17. System should cumulate the re-appropriation, re-allocations, surrenders etc. with 

the budgeted estimates to arrive at the revised budget estimates 

18. System should allow HOOs to submit the budget to their HODs 

19. System should allow HODs to compile the revised estimates for district and 

state focus plans 

20. System should allow HODs to submit the revised estimates for the department 

to Head of Administrative Department 

21. System should allow Head Of Administrative Department to submit the revised 

estimates of the department to DoF 


Attachment B 


1.1.7 Non Plan Budget Preparation 

Table 7: Functional Requirement Specifications – Non Plan Budget Preparation 

Business Requirement – Non Plan Budget Preparation 

Sr. No. 


1. Should allow initiation of the budget preparation activity on a specific date 

2. Should also allow changes to be made in the date for availability of the budget 

program by Finance Department only 

3. Should allow the stakeholders access to the system for accessing the non-plan 

budget program 

4. Should allow authorized stakeholders to modify the fields in a budget program 

5. Should send notification to all the relevant stakeholders for initiation of budget 

activity in the system 

6. System provides the ability to lock out budget changes after specified date which 

can be reversed by BCO/DoF 

7. System should provide the facility to allow multi-level appropriation structure inline 

with State’s budgeting requirements 

8. System should provide the aggregation of budget data such that each level is a 

summary of the level beneath it 

9. System provides the following information on budget forms 

• Five year historical budget and actual expenditure data 

• Monthly and Year-to-date Actual 

• Current Year Budget 

10. Should provide the option to enter the details in the budget program form as 

major heads, minor heads etc. 

11. Should be able to pull data from HR module for HR related expenses and Office 

accounting module to get the expense for non-HR activities. 

Data fields to be pulled from HR & Pension Database: 

• Salary Increments/Deductions 

• Training & Development Costs 

• Cost associated with People Retiring 

• Cost associated with recruitment 

• Allowances etc. 

Data fields to be pulled from office accounting database: 

• Actual expenditure 

• Deduction/Receipts etc. 

12. System should capture the expenditure data from the IFMIS/AGMP’s database 

13. System should compute last 8 Months Expenditure of last FY for each 

expenditure head 


Attachment B 


14. Should allow addition of first 4 months expenditure of current financial year in 

the expenditure head to last 8 months 

15. Should have incorporated budget formula including the contingency factor 

which will give the budget estimate based on last 8 months of last financial year 

and first 4 months of current financial year 

16. System should allow DDO/HOOs to undertake trend analysis of expenditure 

and revenue to compare the budget estimates with the trends identified to make 

the budget estimates more realistic 

17. System provides for application of percentage increases or decrease to a 

budgeted category 

18. Should enable enhancement of amount against MTEF designated heads to meet 

the minimum funding requirements 

19. System should allow a field to provide expenditure remarks at the time of budget 

preparation 

20. System should allow maximum of 1000 words to be entered in the field for 

providing the remarks 

21. System should allow Finance Department to modify the budget preparation 

format for specifying the structure for calculation of HR expenses 

22. Should pull salary requirement projection and other HR expenses for next year 

from the HR database 

23. Should provide option to fill the details of the expenditure which are not pulled 

from HR, Office Accounting database 

24. Should allow users to add the budget requirement for new items 

25. Should consolidate HR , non-HR and new item expenditure 

26. Should provide the functionality of submitting the budget 

27. Should generate a notification and send it to relevant stakeholders for taking the 

necessary action 

28. Should send BCOs a notification for the budget submitted by DDO/HOOs. A 

notification should be generated for every DDO/HOO and sent to BCO 

29. Should be able to consolidate the budget submitted for all DDO/HOOs under a 

BCO 

30. Should allow BCOs to Approve/Reject/Modify the budget prepared by 

DDO/HOOs 

31. Should provide a drop down menu to select a DDO/HOO and view details of 

the proposed budget for a specific DDO/HOO 

32. Should generate a Budget ID for budget program submitted by every office 

33. System should allow drill-down capabilities from budgeted summary categories 

to line item detail justification 

34. System should not allow overwriting any budget request in case of any edits 

made. 

35. System should generate an audit log for all modifications made after final 

submission of budget at different levels 


Attachment B 


submission of budget at different levels 

36. System should allow BCOs to make relevant changes to the proposed budget as 

suggested by Finance Department 

37. System should allow Finance Department to have a consolidated view of the 

budget proposed by BCOs 

38. System should allow version control in case of any edits done to the budget 

request 

39. System should allow Finance Department to view the budget submitted by 

BCOs 


Attachment B 


1.1.8 Non Plan Budget Preparation Revised Estimates 

Table 8: Functional Requirement Specification - Non Plan Budget Preparation Revised Estimates 

Business Requirement –Non Plan Budget Preparation Revised Estimates 

Sr. No. 


1. System should make the e-form available for entering the revised budget 

estimates 

2. Should allow copying details from existing budget into the revised budget 

estimate form 

3. Should populate the projected expenditure level (articulated by MTEF) in the 

revised estimates form to compare the level of expenditure achieved 

4. Should be able to capture HR Expenditure for last 4 months of current Financial 

Year for each expense head 

5. Should allow comparison of the projected expenses for next 8 months with the 

budget allocated 

6. Should have budget formula incorporated for revised budget calculation details 

related to statistical information/account, budget rules incorporated 

7. Should be able to pull the data for HR related expenditure for next 8 months 

from the HR database 

8. Should allow addition for any new services and filling up of required Performa 

for each new item of services 

9. Should allow justifications to be provided for including any new services 

10. Should allow compilation of the revised budget for HR and non-HR expenses 

head wise by incorporating re-appropriations and additional grants and 

subtracting surrenders 

11. System should allow accessing the revised budget estimate form in the system 

12. System should pull the budgeted estimate in the form for the current financial 

year 

13. System should populate the re-appropriation, re-allocations, surrenders, revised 

requirements for the remaining months etc. as on the date of preparation of 

revised estimates 

14. System should cumulate the re-appropriation, re-allocations, surrenders etc. with 

the budgeted estimates to arrive at the revised budget estimates 

15. Should allow BCOs to review the revised non plan budget estimates submitted 

by DDO/HOOs 

16. Should allow BCOs to submit the revised estimates to the Head of 

Administrative Department 

17. Should allow Head of Administrative Department to view and approve revised 

estimates received from HODs 


Attachment B 


18. Should allow Head of Administrative Department to consolidate revised 

estimates received from HODs and submit departmental revised estimates to the 

Finance Department 

19. System should allow the Finance Department to review the revised non plan 

budgets estimates received from each Head of Administrative Department 

20. System should allow the Finance Department to review and revise the revised 

non plan budgets estimates of each HOD in joint consultation 

21. Should enable enhancement of amount against MTEF designated heads to meet 

the minimum funding requirements by additional grants/re-appropriations 

22. System should allow the Finance Department to consolidate revised non plan 

budget proposals with budget estimates 


Attachment B 


1.1.9 Budget Management 

Table 9: Functional Requirement Specification – Budget Management 

Business Requirement – Budget Management 

Sr. No. 


1. Should allow creation of expenditure programme for non-plan budget, based on 

rules of expenditure for: 

• Recurring expenditure items proportionate over the year @ of 1/12 

• Recurring expenditure items not proportionate over the year e.g. 

maintenance 

Non recurring expenditure item to be planned over the year e.g. office furniture 

& equipment 

2. Should allow DDO/HOO to review progress of expenditure vis-à-vis 

expenditure programme 

3. Should enable DDO/HOO/HOO & BCO/HOD to undertake expenditure 

monitoring/ reviews using system tools and utilities. 

4. Comparison of expenditure with project implementation schedule in plan budget 

(mile stone/end of activity stage) periodically(at least quarterly for first three 

quarters and monthly in last quarter, by 15th of last month of FY) 

5. Comparison of expenditure with expenditure program using trend analysis for 

recurring non plan expenditure periodically (at least quarterly for first three 

quarters and monthly in last quarter, by 15th of last month of FY) 

6. Comparison of expenditure with expenditure program using for non-recurring 

non plan expenditure periodically (at least quarterly for first three quarters and 

monthly in last quarter, by 15th of last month of FY) 

7. As a result of expenditure reviews should identify likely savings/excesses 

8. Should allow users to choose from following options 

• No Requirement 

• Additional Requirement 

• Budget Savings 

9. System should perform following action on selecting No requirement option 

• Update the system for no additional budget requirement 

10. System should perform following action on selecting Budget Savings option 

• Make available the proposal for Re-appropriation/Surrender 

11. Should allow DDO/HOOs & BCO to fill the surrender proposal and submit 

the proposal to Finance Department 

12. Should provide the following fields in budget surrender form 

• Planned/Non-Planned Budget 

• Grant 

• Account Head (Major/Minor) 

• Amount to Surrender 


Attachment B 


13. System should perform following action on selecting Additional Requirement 

option 

• Send a notification to BCO/HODs for additional budget requirement 

• Notification should have the details of Grant, Account Head and 

additional requirement 

14. System should retain and allow access to narrative justification for budget 

Adjustments(re-appropriation) by DDO/HOOs/HODs 

15. Should allow relevant stakeholders to transfer budget within various account 

heads within a major head 

16. Should allow BCO/HODs to view the budget surrendered by various 

DDO/HOOs of the department 

17. System allows users to perform on-line appropriation budget adjustments with 

appropriate security authority within the Financial powers 

18. System allows users to inquire as to the status of budget adjustment on-line. 

19. Should allow BCOs/HODs to re-appropriate if additional budget exists within a 

major head within own powers 

20. Should allow BCOs/HODs to send request to Administrative 

Department/Finance Department for 

• Re-appropriation beyond own power 

• Additional Requirement/Grant 

21. Should provide Administrative Department/Finance Department a consolidated 

view of 

• Surrenders by BCOs/HODs of various departments (Head Wise) 

• Surrenders by a Department (Head Wise) 

22. Should allow Admin/Finance Department to re-appropriate within own powers 

if additional budget exits in the following conditions 

Between various Major Heads of a Grant 

23. Should allow Finance Department to enter general across the board (economy) 

cuts for a specific expense head e.g. Travel 

24. System should deduct the budgeted amount for all the DDO/HOOs for specific 

across the board (economy) cuts 

25. Should allow DDOs to reallocate budget to other DDOs within its powers and 

by BCOs to other BCOs within its powers 

26. Should allow Finance Department to send a notification to HODs/BCOs in 

case of unavailability of budget for re-appropriation 

27. Should send HODs/BCOs alerts for unavailability of budget for reappropriation 

28. Should allow HODs/BCOs to prepare a supplementary grant proposal and 

submit it to Finance Department in case there is no excess budget available for 

re-appropriation 

29. Should have the required listed fields in the supplementary grant proposal 

• Account Head 

• Additional Budget requirement 


Attachment B 



• Surrenders in heads having savings 

30. System should allow preparation of supplementary budget on the basis of 

supplementary proposals received from the Head of Administrative 

Departments. 

31. Should copy details from existing budget into the revised estimate budget form 

32. Should allow DDO/HOOs/BCOs and HOOs/HODs to compare budgeted 

estimate and revised estimates 

33. Should copy details from re-appropriation/additional grants/surrendered budget 

to modify original budget estimates as revised estimates 

34. Ability to view own actual budget by each DDO/HOO spending to date and 

also project the expected expenditures for the rest of the period. 

35. Should allow BCOs to enter budget for DDO/HOOs to spread over different 

periods 

36. Should provide Finance Department to upload the approved budget by 

legislative assembly in the system 

37. System processes and maintains all budget iterations, from DDO/HOOs to 

Budget uploaded in the system by Finance Department 

38. System should provide the listed fields for uploading the budget 

• Department Code 

• BCO Code 

• Budget allocated 

39. Should send alerts to Head of Administrative Department for the budget 

uploaded by Finance Department BCO wise 

40. Should allow Head of Administrative Department to release the budget in the 

system to its BCOs 

41. Should allow BCOs to re-allocate budget to DDO/HOOs 

42. Should allow BCOs to allocate budget partially to its DDO/HOOs 

43. System should allow Finance Department to lock any budget head for any 

period of time in case of issues with resource availability 

44. System should allow specifying a lower limit of expenditure to be done under a 

particular budget head 

45. System should send alerts to the Finance Department in case of low or no 

expenditure being done by a department for any particular head 

46. System should allow the relevant stakeholders to capture the budget approved 

by legislature to be withdrawn from the consolidated fund with regards to Vote 

of accounts 

47. System should allow the approved budget to be reflected against the budgeted 

estimates when the budget is passed in the legislative assembly 

48. System should update the system with the balance amount to be withdrawn 

from the consolidated fund. The balance should be calculated by subtracting the 


Attachment B 


budgeted estimates and the expenditure incurred from the consolidated fund in 

case of vote of accounts. 

49. System should allow Finance Department to prepare appropriation bill in the 

system after the budget is passed by the legislative assembly 

50. System should capture the following details in the appropriation bill 

• Schedule showing the specific services 

• Purposes and the limits up to which expenditure can be incurred as per 

budget passed by the Legislature 

• Expenditure charged on the Fund in two separate columns 

51. System should allow Finance Department to capture the assent accorded by the 

Governor and change the status of “Appropriation Bill” to “Appropriation 

Act”. 

52. System should not allow any changes to be done to the Appropriation bill after 

the consent from the Governor has been received 

53. System should have formats to compile/prepare budget books in various 

volumes to be presented to legislative assembly 

54. Should have formats ready to compile/prepare a budget speech to be presented 

to the assembly for various sectors 

55. Should allow Finance Department to compile/prepare Finance Secretary Memo 

which includes 

• Budget at a glance 

• Financial Statement from last 5years 

• Graphs 

• Provisions for Plan Schemes for Revised Estimate 

• Provision for Plan Schemes in the Revised Estimates under different 

Revenue and Capital Heads 

• Provisions for Plan Schemes for Budget Estimate 

• Provision for Plan Schemes in the Budget Estimates under different 

Revenue and Capital Heads 

• Object wise Expenditure 

56. System should allow flagging all the budget heads in which re-appropriation has 

been done 

57. System should allow extracting the details of re-appropriations done across 

various budget heads by various DDOs/HODs/Administrative Department 

Head/DoF 

58. System should provide formats for preparing the outcome budget for various 

departments 

59. System should provide formats for preparing the gender budget for various 

departments 

60. System should have an option which captures the off-budget grants received 

from the center 

61. System should allow Finance Department to capture the off-budget grant for 

each department parallel to the Budget estimates. The system should capture the 


Attachment B 


following fields for capturing the off-budget grants 

• Department 

• Programme/Scheme 

• Budget Estimates for the financial year 

• Revised Estimates for the financial year 

62. System should allow generation of a report for any kind of re-appropriations, 

surrenders and additional grant requirements for a particular budget head at state 

level at the time of budget preparation 

63. System should allow a demand for grant to be compiled/generated for each 

department 

64. System should generate the unique demand number for each demand 

65. System should provide specific formats for preparing the demand for grants 

which includes 


• Plan Component 

• Non Plan component 

• Budget Estimates 

• Revised Estimates 

• Revenue/Capital Section 


Attachment B 


1.1.10 Budget Consolidation 

Table 10: Functional Requirement Specification – Budget Consolidation 

Business Requirement – Budget Consolidation 

Sr. No. 


1. Should allow BCOs to compile the budget estimates for plan and non-plan 

component head wise for all DDO/HOOs 

2. Should allow BCOs to compile the revised budget estimates for plan and nonplan 

component head wise for all DDO/HOOs 

3. Should allow BCOs to compile the budget requirements and revised budget 

requirements for all the DDO/HOOs for plan and non-plan activities 

4. Should allow consolidation of budget estimates for plan and non-plan Budget 

for a department head wise 

5. Should allow consolidation of revised budget estimates for plan and non-plan 

budget for a department head wise 

6. Should allow Department of Finance to view the surrenders, re-appropriations, 

reallocation for various account heads parallel to the budget estimates as 

prepared by various departments 

7. Should allow Finance Department to consolidate budget proposals received 

from BCOs, incorporate DoF level estimates (e.g. pension, interest payments, 

loans/market borrowing repayments) and review consolidated budget for plan 

and non-plan (Budget Estimates and Revise Budget estimates) for the state 

8. System should allow maintaining the confidentiality of the budget estimates after 

it has been finalized by cabinet approval and is due to be presented in the 

assembly 

9. System should allow only relevant stakeholders to access the budget after it has 

been approved by cabinet and still to be approved by legislative assembly 

10. Should allow Finance Department to make the consolidated state budget 

available online after final approval with links to required details/justifications 

11. Should allow the Ministers/MLAs/Legislative Assembly to access the 

consolidated budget online 

12. Should allow Ministers/MLAs/Legislative assembly to drill down to the details 

of the budget till BCO level 

13. Should allow Ministers/MLAs/Legislative Assembly to view and drill down to 

the details of the budget till DDO/HOO level 

14. Should allow Ministers/MLAs/Legislative assembly to view the justification for 

budget requirement 

15. Should display MTEF requirements (amount) against proposals in each related 

head 

16. Should link for the justification formats with the budget requirement for new 

items 

17. Should display links to plan outputs which are basis of outcome budgets 


Attachment B 


18. Should display links to provision details which are basis of gender budgets 


Attachment B 


1.1.11 Payment of Advance from Contingency Fund 

Table 11: Functional Requirement Specification – Contingency Account 

Business Requirement – Contingency Account 

Sr. No. 


1. System should allow HOD/Admin. Dept./DoF to access Budget Management 

Module to identify savings or otherwise, in various budget heads, for meeting 

additional budget requirements 

2. System should have formats for application to be submitted for seeking advance 

from contingency fund 

3. System should necessarily have following text fields in the application: 

• Circumstances in which provision was not included in the budget 

• Reason why delay is not possible 

• Amount required to be advanced from the contingency fund 

• Grant or appropriation in which budget provision has to be made from 

dropdown menu 

4. System should allow Head of Administrative Department to access the 

application in the system for applying online for advance from contingency fund 

5. System should allow Head of Administrative Department to submit the 

application to Department of Finance online 

6. System should generate alerts for DoF on receipt of the application 

7. System should allow DoF to review the application and provide its approval or 

rejection in the system 

8. System should generate a standard sanction order on providing the approval for 

transfer of funds 

9. System should have following details in the sanction order: 

• Amount 

• Grant or Re-appropriation for expenditure provision 

• Description of sub-heads and appropriation units 

10. System should generate a notification on issuing the order and send it to the 

respective Head of Administrative Department and AGMP 

11. System should generate a unique ID for each sanction order 

12. System should allow DoF to make the funds-transfer entry from Contingency 

fund to the corresponding budget head 

13. System should flag the budget head in which provision for budget has been 

provided through contingency fund 

14. System should give alerts or notifications to Department of Finance on a 

monthly basis for all the account heads where advance paid from contingency 

fund has to be recouped 


Attachment B 


1.1.12 Recoupment of Advance given from Contingency Fund 

Table 12: Functional Requirement Specification – Recoupment of Advance from Contingency 

Account 

Business Requirement – Recoupment of Advance from Contingency Account 

Sr. No. 


1. System should populate list of all outstanding CF advances 

2. System should generate alert when supplementary grant proposal uploaded for 

recoupment of outstanding CF advances 

3. System should allow DoF to issue an order through the system for recouping 

amount of advance to contingency fund 

4. System should prompt DoF to check the following before issuing the order 

• Appropriation Act has been passed 

• Sanction ID generated at the time of advance payment is linked 

5. System should allow DoF to transfer funds from the related budget head to 

contingency fund 

6. System should send a notification to AGMP for order issued for recouping 

funds against contingency advance account 

7. System should provide all above functionalities under the Budget Management 

Module 


Attachment B 


1.1.13 Public Fund Account 

Table 13: Functional Requirement Specification – Public Fund Account 

Business Requirement – Public Fund Account 

Sr. No. 


1. System should have formats available for preparation of Public Fund Account to 

be presented at the time of budget preparation 

2. System should allow DoF to prepare a public fund account statement which 

includes all the receipts which are a liability to the state 

3. System should allow linkage of formats to human resource database for 

collations of receipts in the Public Fund Account through deductions of GPF, 

DPF, NPS, GIS etc. from the employee payroll 

4. System should allow linkage of formats to human resource database for 

expenditure in Public Fund Account on a/c of payments of GPF, NPS, DPF, 

DIS etc. to employees 

5. System should allow linkage with deposit module to have an input for the 

estimations of receipts and expenditure in the Public Fund Account on a/c of 

various types of deposits and the payments done against those deposits 

6. System should provide the utility for trend analysis of expenditure from Public 

Fund Account 

7. System should allow preparation of revised and budgeted estimates for the 

public fund account 


Attachment B 


1.1.14 Off –Budget Entries and Payments 

Table 14: Functional Requirement Specifications – Off Budget Entries & Payments 

Business Requirement – Off Budget Entries & Payments 

Sr. No. 

Requirement Description – Off Budget Entries 

1. Should allow the DDOs to enter the details of the payments received under the 

OFF BUDGET category over the IFMIS application. The DDO should be allowed 

to enter the following details: 

• DDO Code 

• Departments / Agency from which Off Budget Amount has been received 

• Scheme Name 

• Scheme id 

• Amount Received from Agency 1 

• Amount Received from Agency 2 

• …………………………………. 

• Amount Received from Agency n 

• Bank’s Name & Branch in which amount has been received 

• Bank’s Account in which amount has been received 

• Budget Head / Line (Which would be a alphanumeric code just like the 16 

digit code providing details of Major Head Minor Head Project Details 

Scheme Details and other payment details that would be used to identify the 

kind of payment) 

2. Should generate alerts for DoF over the updation once the DDO has entered the 

above details 

3. Should allow the DoF official to re validate the entered details with the actual 

amount received in the Particular Bank Accounts 

4. Should allow the DoF official to make the payments of the state’s contribution 

directly in designated account after verifying that the contribution from central / 

external agency has already been received 

Sr. No. Requirement Description – Off Budget Payments 

1. Should allow the DDO to check whether the amount details uploaded by him/her 

have been updated over the IFMIS application 

2. Once the DDO has checked that the amount received under the Off Budget Head 

has been updated over the IFMIS application then only s/he should be allowed to 

raise claim over the IFMIS application 

3. Should allow the DDO of the local bodies receiving the Off Budget Payments to 

raise claims over the IFMIS application 

4. Should be allowed to make payments using the Treasury Disbursement System as 

mentioned in the TDS module of FRS 

5. Should update the Off Budget balances once the disbursement has been made and 

should also update the IFMIS application for balance amount in the account head 


Attachment B 


6. Should generate alerts for DoF each time any transaction is made from this account 

head 


Attachment B 


1.2 Accounting & Bookkeeping 

1.2.1 Processing of Journal Vouchers and General Ledger Posting 

Table 15: Business Requirement: Processing of Journal Vouchers and General Ledger Posting 

Business Requirement – Processing of Journal Vouchers and General Ledger Posting 

Sr. No. 

General Ledger 


1. Should create and maintain unlimited number of ledgers/registers in general 

Ledger (GL) with an option to include or exclude any of the ledgers for one or 

multiple consolidations. 

2. Should maintain multiple accounting structures. (Cash, modified cash, modified 

accrual, accrual) 

3. Should define accounting periods with at least fiscal periods, per year with 

cumulative figures 

4. Should define User definable start and end dates for the period 

5. The system shall provide functionality to automatically reconcile bank activity 

entered in the system with bank transactions received from the State's bank 

Accounts (e-scrolls). 

6. The system shall provide functionality to accommodate multiple banks and bank 

accounts in the automated bank reconciliation process 

7. Should set up security by various user groups to restrict access for those account 

ranges. 

8. Should define Account level security by user e.g.: The system should restrict user 

entering or reviewing balances for certain accounts. 

9. Should maintain minimum ten years on-line history 

10. The system shall provide functionality to provide a manual and automatic 

reconciliation process of bank activity that can be used at the user's discretion 

11. The system shall provide functionality for users to make correction during the 

reconciliation process 

12. The system shall provide functionality to automatically receive and store electronic 

deposit information in various formats as well as generate information to identify 

and approve the deposits 

13. The system shall provide functionality to automatically adjust cash held in an 

agency’s fund ledger and the associated revenue for each returned cheques or 

unsuccessful transaction (payment) 

14. The system shall provide functionality to automatically update the general ledger 

with contract transaction and documents 

15. The system shall provide functionality to define accounting rules such that both 

full accrual and modified accrual postings are captured, as well as cash basis for 


Attachment B 


the following items including, but not limited to: 

• Fixed and Current assets 

• Liabilities 

• Loans receivables and payable 

• Investments 

• Deposits 

• Advances to Contractors 

• AR and payable 

• Disbursement and Receipts (taxation) 

• Non tax revenue receipts 

16. The system shall provide functionality to support an unlimited number of 

subsidiary ledgers including both statistical and financial ledgers 

17. The system shall provide functionality to support a centralized ledger for each 

fund 

18. The system shall provide functionality to prevent the posting of a transaction 

unless all components of that transaction pass data and funding 

edits/validations 

19. The system shall provide functionality to simultaneously support the following 

basis of accounting for appropriate fund types, but not limited to: 

• Cash basis 

• Accrual basis 

• Modified accrual basis 

20. The system shall provide functionality to support multi-fund accounting with the 

capacity to segregate funds by type and by regulatory requirements 

21. The system shall provide functionality to automatically create due to/due from 

entries to balance transaction entries by fund based on pre-defined rules 

22. The system shall provide functionality to configure a journal voucher format 

23. The system shall provide functionality for the user to set-up standard journal 

voucher templates that can be recycled to enable the creation of like kind 

vouchers 

24. The system shall provide functionality to generate a unique journal Id for each 

journal voucher transaction and transaction line entered 

25. The system shall provide functionality to define multiple types of journal vouchers 

to handle multiple transaction types including, but not limited to: 

• Manual 

• Recurring 

• Interfaced 

26. The system shall provide functionality to reverse manual, recurring, and interfaced 

journal vouchers 

27. The system shall provide functionality to create unique journal voucher types to 

be identified to each journal voucher created within the system. Unique 


Attachment B 


journal voucher types will be used as a means to easily identify the purpose of the 

entry, the originating source, and its contents 

28. The system shall provide functionality to store valid journal types in a repository 

29. The system shall provide functionality to support both automatic and manual 

identification of document numbers 

30. The system shall provide functionality for a user to edit the accounting 

distribution from the default distribution for interfaced journal vouchers 

31. The system shall provide functionality to post transactions from integrated 

functional areas to the general ledger interactively (near-real time) 

32. The system shall Provide functionality for users to enter audit adjustments 

33. The system shall provide functionality for users to enter adjustments that 

automatically generate subsequent general ledger postings, such as a reversal in 

a future period 

34. The system shall provide functionality to generate recurring entries on a schedule 

(e.g., monthly, quarterly, annually) so users may edit or approve entries prior to 

posting 

35. The system shall provide functionality to process standard/recurring journal 

entries or fixed and variable amounts that are posted at scheduled intervals 

36. The system shall provide functionality for users to modify a recurring journal 

voucher at the header and line levels 

37. The system shall provide functionality to reverse journal vouchers with user 

control over the period in which the reversal occurs 

38. The system shall provide functionality to establish accruals (e.g., payroll) on a 

monthly basis 

39. The system shall provide functionality to automatically reverse accrual transactions 

in either the period immediately following the fiscal month to which the 

transactions are posted or the current period 

40. The system shall provide functionality for users to add comments to pending 

transactions or documents 

41. The system shall provide functionality to automate reconciliation controls 

between general ledger and sub-ledger balances 

42. The system shall provide functionality to identify goods or services received in the 

prior year that were paid for in the current year 

43. The system shall provide functionality for the user to create and use separate 

concentration funds to document cash receipts, cash holdings, and cash 

disbursements within a single checking/banking account 

44. The system shall provide functionality for the user to retrieve data for reversing or 

making adjustments, based on search criteria (e.g., batch number, batch 

and group identifier, receipt, debit memo identifier) 

45. The system shall provide functionality to assign approval routes to journal 

voucher transactions 


Attachment B 


46. The system shall provide the functionality for appropriation and re-appropriation 

of funds between various budget heads at various levels (BCO, HOO, HOD, 

DDO) 

47. The system shall provide functionality to create approval routes for inter-fund or 

inter-agency 

48. The system shall provide functionality to automatically balance inter-fund and 

inter-agency transactions 

49. The system shall provide the functionality to post transactions in the past or 

future period as long as the period is open 

50. The system shall provide the functionality to permit prior year adjustments to be 

entered in the current fiscal year and reported as a prior year adjustment for 

financial reporting and entered as a current year adjustment for budgetary 

purposes 

51. The system shall provide functionality for users to access to current period 

information during the previous period's close (e.g., no restrictions on January 

while December is being closed) 

52. The system shall provide functionality to run multiple periods and fiscal years 

concurrently, which will allow users to enter transactions, based on effective 

dates, in any periods that have not been closed 

53. The system shall provide functionality to automate fiscal year end close process 

54. The system shall provide functionality to soft close a fiscal year end to prevent 

state agencies from posting in the prior fiscal year after a designated date 

55. The system shall provide functionality to maintain open and close periods for 

other modules (e.g. AR, AP, Disbursement, Receipts, Project, Debt management) 

independent from the general ledger 

56. The system shall provide functionality to allow multiple preliminary year-end 

closings to occur while maintaining the ability to post data to current and prior 

periods 

57. The system shall provide functionality to perform an automated year-end rollover 

of appropriate financial information into the new fiscal year 

58. The system shall provide functionality to prevent interferences with the 

processing of current year transactions during the year-end closing process 

59. The system shall provide functionality to report revenue and expenditure activity 

on a cash basis (budgetary compliance and reporting) and accrual basis 

within the same fund and shall provide reconciling transaction reports as needed, 

including the transactions that may end up in different fiscal years based on the 

method of reporting 

60. The system shall provide functionality for users to trace summarized transactions 

in the general ledger back to detail source documents in other system modules or 

subsystems. If the information must be retrieved from these modules or 

subsystems, it should be transparent to users 

61. The system shall provide functionality for users to define standard general ledger 

inquiries with parameter options 


Attachment B 


62. The system shall provide functionality for users to perform on-line drill-downs 

from the general ledger summary balance to the original source document(s) 

63. The system shall provide functionality to generate bank reports as and when 

required along with the monthly, quarterly and annual bank statement 

64. The System shall provide the functionality to prevent creation of duplicate 

transactions with system controls 

65. Should provide functionality for users to identify specific transactions that are 

exempt from appropriation budget and/or cash edits/validation 

66. Should provide functionality to permit cross-validation rules across all element of 

the data classification structure 

67. Should provide functionality for users to edit transactions to ensure that each 

entry to a fund is complete based on specified fields 

68. Should provide functionality to ensure that journal entries are in balance prior to 

posting 

69. Should provide functionality for users to define an d maintain standard rules that 

control general ledger account posting for all accounting events across integrated 

functional areas (e.g., AP and Purchasing) 

70. Should provide functionality to develop routines, reports, and inquiries that 

compare subsidiary ledger balances (e.g., any integrated functional area) with the 

respective general ledger balance for integrity controls 

71. Should provide functionality to prevent the creation of duplicate transactions with 

system controls 

72. Should have centralized account maintenance capability in order to ensure that 

any addition or change in the account code in the master chart of account will be 

available automatically in all 

Period Closing 

73. Should maintain more than one open period at a time 

74. Should generate period closing reports that ensures consistency check with the 

sub ledgers 

75. Should have separate period closing capability by sub ledger 

76. Should selectively close or open periods for posting (with adequate security ) 

Year End Closing 

77. Should close and open the year automatically 

78. Should keep adjusting period for audit adjustments and other financial 

transactions after the year closing 

79. Should generate closing exception reports 

80. Should ensure at year end close all entries are in balance and all periods have been 

closed 


Attachment B 


81. Should carry forward prior year end Balance Sheet account balances to new fiscal 

year as beginning balances during year-end close. 

Inquiry & Reporting 

Inquiry 

82. Should perform on-line transaction inquiries for Individual Chart of Accounts, 

Summarized at various levels of parents, range of periods, Actual or budget or 

both with variance, Period to date, year to date and project to date 

83. Should perform budget (Initial, revised)vs. actual with variance inquiry with the 

option to change budget ID 

84. Should perform budget vs. actual inquiry on summary account & detailed account 

balances 

85. Should inquire account balances for net change and period balances 

86. Should perform cross module drill down 

87. Should capture the following information(Transaction date , Invoice number or 

cheques number as applicable, Source document reference, Invoice detail 

description, Original transaction currency INR, Original transaction amount¸ 

Functional transaction amount equivalent, etc.) from the general ledger related to 

transactions posted from accounts payable module 

Reporting 

88. Should generate trial balance summarized by account segment and in detail 

89. Should print journal vouchers from the system before and after posting with the 

status shown separately 

90. Should produce general ledger reports for users elected accounts and periods 

91. Should generate the following financial reports in user defined format Balance 

sheet, Income and Expenditure Account, Cash flow statement, Budget status 

report ( budget vs. actual by selected accounts/groups of accounts) 

92. Should generate Balance Sheet and Income and Expenditure by Units, analyzed by 

account heads 

93. Should include no decimal digits for Indian currency on all Financial reports 

94. Should have all Online transactions registers 

95. Should generate required consolidated monthly treasury accounts for AGMP 

96. Should generated required consolidated monthly state accounts out of treasury 

transactions 

97. Should allow AGMP utility for compiling statutory state accounts for defined 

period 


Attachment B 


1.2.2 Asset Account Management 

Table 16: Business Requirement - Asset Accounts Management 

Business Requirement – Asset Account Management 

Sr. No. 


1. The system shall provide functionality to maintain inventory in the assets 

module. Additional data fields would include, but are not limited to the 

following: 

• Asset Name 

• Asset version 

• Manufacturer (i.e. licensor) 

• Order number 

• Order date 

• Quantity 

• Supplier 

• License term 

• License type 

• Product category/class (e.g., PC, mainframe, or server) 

2. For the new assets created the system should have the functionality to record 

information including, but not limited to 

• Date of Completion 

• Last date of performance guarantee 

• Details of amount withheld, deposit, bank guarantee etc 

3. The system shall provide functionality to track in process asset which are under 

creation/development/manufacturing, through works/manufacturing 

accounting module 

4. The system shall provide functionality for users to directly enter asset 

information when the asset is acquired outside of integrated system modules like 

disbursement, works accounting (Contractor procures on behalf of the State, 

gift, donation) 

5. The system shall provide functionality to assign unique identification number to 

all assets 

6. The system shall provide functionality to integrate the disbursement, works 

accounting and Asset Management modules to identify expenditure transactions 

or input against an asset 

7. The system shall provide functionality to be integrated with existing purchase 

modules for various line departments. 

8. The system shall provide functionality to be integrated with new procurement 

systems (e-procurement) (department level and state level) as and when 

dept/state decides to implement them 

9. The system shall provide functionality for a free-form narrative description field 

(text box) for entry of an asset item 


Attachment B 



Sr. No. 

(text box) for entry of an asset item 


10. The system shall provide functionality to track different types (class/category) of 

assets including, but not limited to: 

• Equipment 

• Buildings 

• Infrastructure 

• Land 

11. The system should provide functionality to track the budget head or project 

under which the asset is acquired or created 

12. The system shall provide functionality for users to copy asset record entries for 

identical items and then assign separate asset tag/inventory control 

/identification numbers (e.g., purchase of 20 identical personal computers) 

13. The system shall provide functionality to maintain detailed real estate 

information required to identify and account for State lands including, but not 

limited to: 

• Legal description 

• District 

• Acquisition information 

• Number of acres 

• Value per acre 

• Fair market value 

• Geographic Information, Location (latitude and longitude) 

14. The system shall provide functionality to record all capitalizable costs associated 

with the construction or purchase/acquisition of an asset and when 

applicable, link the asset to the project, sub-project or grant/head that resulted 

in acquisition of the asset 

15. The system shall provide functionality for users to record and maintain 

information on construction work in progress and provide a mechanism to 

transfer accumulated work in progress costs to an asset record if needed or 

generate report on cost of work in progress 

16. The system shall provide functionality for users to create, edit, or delete 

parent/child relationships between assets 

17. The system shall provide functionality for users to change an asset's useful life, 

salvage value, and depreciation method when necessary 

18. The system shall provide functionality to track (e.g., identify, record, inquire, 

report) regular/preventative maintenance performed on selected assets 

19. The system shall provide functionality for user inquiries by any element of the 

asset master record (e.g., asset number, asset description, location) 

20. The system shall provide functionality to maintain information on building 

assets including but not limited to the following: 


Attachment B 



Sr. No. 


• Location (region, district) 

• Building age or date constructed 

• Number of stories - Construction type 

• Department using the asset 

• Square footage (land /built-up) 

• Valuation 

• Insurance information if any (company, policy, coverage amount, etc.) 

• Geographic location (Latitude and Longitude) 

• History (fire, construction, major maintenance activity) 

21. The system shall provide functionality to accommodate multiple depreciation 

schedules that could be applied to an asset 

22. The system shall provide functionality for users to maintain detailed asset 

information required to identify and properly account for all assets including, but 

not limited to: 

• Asset ID 

• Description 

• Condition 

• Acquisition date 

• In service date 

• Asset category 

• Asset class 


• Office 

• Model number 

• Serial number 

• Location 

• Procurement method 

• Expenditure Head of Account up to Object code 

• Cost 

• Disposal date 

• Disposal reference 

• Disposal costs 

• Amount collected (to be required if the method of disposition is sale) 

• Profit/Loss on disposal of assets and its recording in account records. 

23. The system shall provide functionality for users to modify or remove the link 

between a child and the parent asset. (e.g. large equipments are typically 

accompanied which are recorded as separated asset by there is parent child 

relationship that exists) 


Attachment B 



Sr. No. 



(GL) to capitalize any asset acquired through the disbursement module 


to capitalize any completed project that is added to fixed assets 

26. The system shall provide functionality to post accounting entries to the general 

ledger when additions, deletions, and changes to the asset values occurs 

27. The system shall provide functionality for users to drill down from asset 

summary reports to any source document stored in the system 

28. The system shall provide functionality to track the usage of a child asset 

independently of the parent asset to which it is linked so that if the child moved 

from one parent asset to another parent asset, all data is maintained and 

transferred physical counts that 

29. The system shall provide functionality for an equipment type to pre-populate 

useful life for an asset 

30. The system shall provide functionality for each department to define the useful 

life of each equipment type (e.g., Dept. A has a useful live of 5 years for asset 

type copiers and Dept. B has a useful life of 7 years for copiers 

31. The system shall provide functionality to amortize the cost of equipments to the 

assets it was used in creating on predefined formula. 

32. The system shall provide functionality to create an asset record for a leased asset 

(State as lessee) 

33. The system shall provide functionality to maintain repair and preventative 

maintenance history data for each equipment unit, including online access to 

both summary information 

34. The system shall provide functionality to generate reports detailing the cost of 

new assets acquired to replace an asset lost, missing, stolen, or destroyed 

35. The system shall provide functionality to record capital assets that were 

originally captured as construction in progress in another module (e.g., Works 

Accounting) 

36. The system shall provide functionality to create reports to be used for are 

organized and sorted by physical asset location and by sub-location codes 

specified by the agency 

37. The system shall provide functionality to track and report by each asset record if 

the equipment custodian (assigned responsible employee) is authorized to 

take his or her assigned assets offsite from the State facility and identify the 

person who authorized the State employee the privileges or right to take his or 

her assets offsite 

38. The system shall provide functionality to create asset master records with no 

corresponding cost for manual transactions (e.g., donated, gifts) 


Attachment B 


1.2.3 Creation of Purchase Order 

Table 17: Business Requirement Specification - Create Purchase Order 

Business Requirement – Creation of Purchase Order 

Sr. No. 


1. The system shall provide functionality to select the vendors name alphabetically 

by name, by vendor number for entry into purchase order when required for 

single/limited tender cases 

2. The system shall provide functionality to port commodity ID from 

Asset/Inventory database 

3. The system shall provide functionality to provide the ability to users to perform 

the following functions on a purchase order, including but not limited to 

• Inquire 

• Add 

• Change 

• Cancel 

• Delete 

4. The system shall provide functionality to provide the following information on 

the purchase order, including but not limited 

• Vendor name 

• Vendor Number 

• Buyer name 

• Buyer number 

• Ship to address 

• Order from address 

• Commodity code 


• Unit of measurement 

• Unit price 

• Quantity 

• Total amount 

• Account code (major, minor, object head etc) 

• Project code (if any) 

• Contract number 

• Method of purchase 

• Payment terms 

• Item master reference or description 

• Discount percent (if any offered) 

5. The system shall provide functionality to save incomplete purchase orders 


Attachment B 



Sr. No. 


6. The system shall provide functionality to access and select stock items from item 

master for purchase order 

7. The system shall provide functionality to create rate contract for the inventoried 

supplies needed throughout the year 

8. The system shall provide functionality to automatically create the purchase order 

for the inventoried supplies when the supplies reach a specified order level for 

items under rate contract However PO can only be issued if condition of budget 

& sanction is met 

9. The system shall provide functionality to enter zero rupees purchase order 

10. The system shall provide functionality to assign a buyer number or id either for 

entire requisition or by specific line items 

11. The system shall provide functionality to automatically validate some of the 

purchase order fields at the time of creation including, but not limited to 


• Project id 

• Account code 

12. The system shall provide functionality to identify multiple delivery dates and 

ship to locations on a line item basis for purchase orders 

13. The system shall provide functionality to associate multiple account codes to 

single line item on a purchase order 

14. The system shall provide functionality to enable a percentage based distribution 

of cost for a line item across multiple account codes in purchase order 

15. The system shall provide functionality to automatically populate the ship to 

address with capabilities to over ride as and when required 

16. The system shall provide functionality to automatically assign unique purchase 

order number 

17. The system shall provide functionality to enable no les then 2 places of decimal 

for price per units of measure 

18. The system shall provide functionality to perform an automated check for 

budget availability 

19. The system shall provide functionality to allow the user to modify the purchase 

order after it has initially been saved 

20. The system shall provide functionality to backdate the purchase orders 

21. The system shall provide functionality to enter % term conditions, net days and 

date and month if the vendor offers prompt payment or any discount 

22. The system shall provide functionality to aggregate multiple manual requisitions 

to a single purchase order 

23. The system shall provide functionality to enable the addition of comments on 

purchase order 


Attachment B 



Sr. No. 


24. The system shall provide functionality to create change orders to existing 

purchase orders 

25. The system shall provide functionality to create recurring purchase orders in case 

of rate contract 

26. The system shall provide functionality to require the tax id numbers of vendor 

before awarding purchase order or contract 

27. The system shall provide functionality to create multiple purchase order for one 

manual requisition 

28. The system shall provide functionality to set quality and price tolerance by line 

item on the purchase order 

29. The system shall provide functionality to copy existing purchase order 

information to a new or modified purchase order 

30. The system shall provide functionality to identify the line items in the purchase 

order which will generate an asset record 

31. The system shall provide functionality to provide a mechanism to send purchase 

order / contract via multiple formats based on vendor profile (email, XML, hard 

copy etc) 

32. The system shall provide functionality to use purchase order for goods and 

services ordered from an internal department (e.g. purchase of furniture and 

other fixtures from other state government agencies) 

33. The system shall provide functionality to match Supply Challans, receipts and 

Invoices (quantities, price and receipt date) against purchase order line items and 

report discrepancies 

34. The system shall provide functionality to run enquiries on line item information 

on purchase orders on any combination of following fields 

• Ship to address 

• Order from address 



• Account code (major, minor, object head etc) 

• Project code (if any) 

35. The system shall provide functionality to enable orders with staggered delivery 

schedules on a line item basis 

36. The system shall provide functionality to update purchase order with 

acknowledgements received electronically from the vendor 

37. The system shall provide functionality to administrator to create, modify and 

customize templates for purchase orders 

38. The system shall provide functionality for users to enquire for purchase orders 

39. The system shall provide functionality to provide fright and payment terms 

fields as a part of the purchase order/contractor 


Attachment B 



Sr. No. 


40. The system shall provide functionality to provide detailed purchasing history by 

vendor via enquiry 

41. The system shall provide functionality to perform various slicing and dicing of 

information and generate custom reports from purchase order data 

42. The system shall provide functionality to provide inquiries of outstanding 

purchase orders by office and department 


Attachment B 


1.2.4 Manage Receipts of Goods and Services 

Table 18: Business Requirement Specification - Manage Receipts of Goods and Services 

Business Requirement –Manage Receipts of Goods and Services 

Sr. No. 


1. The system shall provide functionality to receive multiple transactions from 

multiple vendor locations on a purchase order 

2. The system shall provide functionality to save the date and time stamp for the 

receipt of goods purchase functions 

3. The system shall provide functionality to allow various types of transactions 

relating to the receipt of goods/services including, but not limited to: 

• Completes - Back Order 

• Rescheduled 

• Balance Cancelled 

• Partial receipts 

• Material disposition 

• Return goods for credit 

• Return goods for damage 

• Return goods for over-shipments 

• Trade-ins (a line item rather than deducting from the actual cost) 

4. The system shall provide functionality to record receipt of no cost items 

5. The system shall provide functionality to create unique receiving number at the 

time of entry of receipt of goods and services 

6. The system shall provide functionality to enable receipt of goods and services 

without a purchase order 

7. The system shall provide functionality to track (e.g., identify, save, inquire, 

report) the reason for the rejection of goods by receiver (individual) 

8. The system shall provide functionality to purchasing and the inventory system to 

share a common receiving function and item commodity file (inventory system 

not a part of first phase) 

9. The system shall provide functionality to automatically update inventory onhand 

and on-order when items are received into inventory off a purchase 

Order 

10. The system shall provide functionality for the receipt of goods and not payment 

of goods, to update inventory 

11. The system shall provide functionality to process three ways match transaction 

(purchase order, receipt of goods and payment bill or voucher) 

12. The system shall provide functionality to transfer items between agencies and 

departments using inter agency/department transfers 

13. The system shall provide functionality to authorize designated receivers for a 

department 


Attachment B 


Business Requirement –Manage Receipts of Goods and Services 

Sr. No. 


14. The system shall provide functionality to automatically notify users via email of 

purchase orders that are past its delivery dates and have not been fully received 

15. The system shall provide functionality to automatically update purchase order 

status and balances based on receipt of goods 

16. The system shall provide functionality to reverse a receiving transaction against a 

purchase order 

17. The system shall provide functionality to create reminder notices to vendors for 

shipments due based on defined thresholds 

18. The system shall provide functionality to have receiving create Accounts Payable 

(AP) liability in General Ledger 

19. The system shall provide functionality to process two way matches (purchase 

order and voucher) for payment 

20. The system shall provide functionality to establish receiving tolerances by 

commodity classification code 

21. The system shall provide functionality to automatically create required vouchers 

upon the receipt of goods against a purchase order 

22. The system shall provide functionality for users to correct data entered in the 

receiving system 

23. The system shall provide functionality to receive against multiple ship to 

addresses in a purchase order 

24. The system shall provide all required forms and formats (in Hindi and English) 

for books of accounts and make them available online 

25. The system shall provide functionality to create all other entries in relevant 

books of accounts (asset/inventory/service registers, Journal. and Ledgers) 

through auto escalation 

26. System shall provide for compilation of store & stock accounts and viewing it 

both in double entry accrual based, as well as, in single entry cash based 

accounting system 


Attachment B 


1.2.5 Project/Contract Creation 

Table 19: Functional Requirement Specification – Project creation and Updation 

Business Requirement – Project /Contract Creation 

Sr. No. 


1. System should make the project planning module available to HOOs and HODs 

on an ongoing basis 

2. The system should provide the functionality to enable creation of a new contract 

for implementation 

3. The system should provide the functionality to provide a contract creation utility 

by capturing AS/TS/Tender Approval Order for the project 

4. The system should provide the functionality to provide interface with related e- 

procurement system to capture details of the finalised tender (current or future) 

5. The system should provide the functionality to provide utility to define/capture 

terms and conditions of the contract as per agreement between the department 

and the contractor 

6. The system should provide the functionality to enable creation of the Unique 

Scheme ID for implementation of the project through execution of the contract 

in Project management module 

7. The system should provide the functionality to enable creation of more than one 

contract for the same Unique Scheme ID 

8. The system should provide the functionality to enable creation of a contract for 

the more than one Unique Scheme ID 

9. The system should provide the functionality to provide utility to redefine the 

contract as per need after revised AS/TS received in the system 

10. The system should provide the functionality to provide all required forms and 

formats (in Hindi and English) made available online 

11. The system should provide the functionality to defining overall % limit for work 

charge contingencies with maximum % limit of each broad item of contingency 

expenditure 

12. The system should provide the functionality to allocating/distributing scheme 

budget over the FY as per needs of construction programme (month wise) 

13. The system should provide the functionality to allow reallocating/redistributing 

scheme budget over the FY as per needs of the revised construction programme 

(month wise) 

14. The system should provide the functionality to enable uploading of detailed 

construction programme against the contract defined 

15. The system should provide the functionality to define contract and construction 

programme reach (sub-engineer or section) wise 

16. The system should provide the functionality to customize online MB reach-wise 

17. The system should provide the functionality to define reach slice/quantities and 

milestones of the contract in section’s online MB enabling capture of 


Attachment B 


measurements and milestone in the MB 

18. Scheme budget will have to be distributed (month-wise) over the financial year 

to be able to draw moneys with regard to contractor’s bills and related work 

contingency expenditure 

19. The system should provide the functionality to raise alerts if slice/quantities 

exceeds predefined limits 

20. The system should provide the functionality to enable consolidation of 

measurement SDO/EE (Division)-wise as also inter division consolidation of 

Item-wise quantities and milepost information. 

21. The system should provide the functionality to enable computation of quantities 

for approval of contractor’s bill/invoice of quantities 

22. The system should provide the functionality to enable creation of contract bill as 

per verified/measured quantities less what is paid earlier (Process: Contractor 

Bill Clearing) 

23. The system should provide the functionality to enable adjustments of deductions 

on account of advances, security, penalty, taxes, etc from created bill (Process: 

Contractor Bill Clearing) 

24. The system should provide the functionality to enable uploading of contractor’s 

bill in IFMIS Disbursement system (Process: Contractor Bill Clearing) 

25. The system should provide the functionality to enable Updation of 

project/scheme expenditure/output accounts after each disbursement 

26. The system should provide the functionality to enable audit logs for all 

changes/modifications and copied in the contract/project management 

utility/system 

27. The system should provide the functionality to enable closure of contract when 

completed/abandoned/ terminated 

28. The system should provide the functionality to enable consolidation of all 

information/data of all the contracts of a particular project/scheme in project 

management module 

29. The system should provide the functionality to create and link contracts, sub 

contracts, activities and tasks 

30. The system should provide the functionality to create an Ad hoc contracts, 

where a work break down structure is not required 

31. The system should provide the functionality to be able to enter milestones , 

milestone dates and Key Performance Indicators in the system for specific the 

contracts 

32. The system should provide the functionality to assign contracts owner, contracts 

manager, accountable person and key stakeholders, System updating authority, 

reviewing authority 

33. The system should provide the functionality to support for template based 

DPR/Draft contracts plan 

34. The system should provide the functionality to capture the data pertaining to all 

aspects of contracts 


Attachment B 


35. The system should provide the functionality to track resource across contracts 

36. The system should provide the functionality to enable what-if modeling 

scenarios 

37. The system should provide the functionality to record the costs for each major 

contracts or a set of activities under investigation 

38. The system should provide the functionality to do analysis of resources used on 

a contracts compared to the estimates for different categories, i.e., money, time, 

materials, overheads etc. 

39. The system should provide the functionality to maintain the records for the 

duration of the contracts; 

40. The system should provide the functionality to generate management reports for 

each contract. 

41. The system should provide the functionality to reflect inflation in contract costs, 

highlight and correct errors, if detected in contract management with proper 

notifications and authorization controls 

42. The system should provide the functionality to maintain complete data on any 

contracts must be kept throughout the life of a contract and must be able to be 

printed out and/or reviewed on screen at any time. 

43. The system should provide the functionality to capture documentation related to 

execution of various contracts (existing & old) for retrospective analysis on a 

future date. 

44. The system should provide the functionality to enable online contract 

management process by enabling team members to easily manage, track, and 

report on their contract activities through familiar tools, like the Web. 

45. The system should provide the functionality to incorporate security measures, to 

limit changes by contracts owners to only their respective contracts and 

simulations 

46. The system should provide the functionality to track changes, with reasons 

47. The system should provide the functionality to establish security measures to 

ensure that the personnel are allowed to review/edit contracts they are involved 

with. 

48. The system should provide the functionality to be able to re-open closed 

contracts 

49. The system should provide the functionality to notify all appropriate personnel, 

that a contract is closed 

50. The system should provide the functionality to provide security measures, to 

ensure that the project closure is done by authorized personnel only 

51. The system should provide the functionality to print contracts reports at 

summary level and detailed level 

52. The system should provide the functionality that at the time of inclusion of 

contract in budget, there should be a limit beyond which no provision can be 

made 


Attachment B 


53. The system should provide the functionality to keep the provision indicated in 

the budget should be the limit for that work, which can be drawn in that 

financial year with a facility for amendment 

54. The system should provide the functionality to incorporate different of models 

payment including but not limited to, 

• PPP (BOT) with 100% private funding 

• PPP with viability gap funding 

• Annuity based model with variable concession periods 

55. The system should provide the functionality to provide availability of 

• List of registered contractors/firms 

• List of Blacklisted firms 

• List of partners of such blacklisted firms 

56. The System should have the functionality to provide information of the 

contracts and its performance, present status etc undertaken by any contractor 

to whom contract is being awarded in last 5 years or more 


Attachment B 


1.2.6 Project/Contract Management 

Table 20 : Business Requirement Specification - Project/Contract Management 

Business Requirement – Project Management 

Sr. No. 


1. Should allow the application to interact and obtain inputs from project creation 

module 

2. Should allow the system updating authority (sub engineer in the case of Works 

Department) to access the project management module of the application 

3. Should allow the system updating authority to view the terms and conditions, the ser 

milestones and other project related information over the system 

4. Should allow the system updating authority to update the project with the following 

information: 

o Project Name (Drop Down) 

o Project Id (self generated) 

o Project duration ( to be selected by authority) 

• Activity Detail 

• Output of each activity 

o Milestones set (self generated from) 

o Milestones Pending (self Generated by the system) 

o Milestones achieved (to be filled in by authority) 

o Activities set under the milestone 

o Activities achieved 

o Activities pending 

o Cost Incurred 

o Material Used (for works) 

o Remarks by the sub engineer 

5. Should generate an alert for the next higher authority / approving authority (SDO in 

case of works dept.) to as soon as the EE / Project Upload authority updates the 

project management module 

6. Should allow the approving authority to view the updated project update module 

7. Should allow the approving authority to view the details of updates made by the 

project updates made by system updating authority 

8. Should allow the approving authority to approve / reject / raise objections / make 

minor changes at his own end to the updation 

9. Should generate alerts for the system updating authority to view the rejections/ 

observations made by the approving authority 

10. Should mark the project updated once the approving authority has approved the 

updates made by the system updating authority 

11. Should monitor each activity/task in the project 


Attachment B 




14. Should allow the relevant authorities to make revisions to the project 

15. Should allow the authorities to seek online sanctions for project plan revision 

16. Should monitor variations from schedules and send alerts to the concerned 

authorities 

17. Should monitor estimates versus actual : money amounts, services, labor, time span, 

vehicles used etc., 

18. Should monitor all projects consolidated, individual projects and individual tasks 

19. Should store baseline and revised plans 

20. Should display project total, accumulated costs in terms of actual, revenue, 

capitalization costs, future commitments etc., 

21. Should maintain project percentage completed status -based on work to date. 

22. System should link the project plan module with the office accounting system for 

creation of asset in asset register 

23. Should reflect inflation in project costs, highlight and correct errors, if detected in 

project management with proper notifications and authorization controls 

24. Should maintain complete data on any project must be kept throughout the life of a 

project and must be able to be printed out and/or reviewed on screen at any time. 

25. Should capture documentation related to execution of various projects (existing & 

old) for retrospective analysis in future. 

26. Should enable online project management process by enabling team members to 

easily manage, track, and report on their project activities through familiar tools, like 

the Web. 

27. Should incorporate security measures, to limit changes by project owners to only 

their respective projects and simulations 

28. Should track changes, with reasons 

29. Should establish security measures to ensure that the personnel are allowed to 

review/edit projects they are involved with. 

30. Should be able to re-open closed projects 

31. Should notify all appropriate personnel, that a project is closed 

32. Should provide security measures, to ensure that the project closure is done by 

authorized personnel only 

33. Should print project reports at summary level and detailed level 


Attachment B 


1.2.7 Contractor Bill Clearing 

Table 21: Business Requirement Specifications- Contractor Bill Clearing 

Business Requirement – Contractor Bill Clearing 

Sr. No. 


1. Should provide required electronic formats of invoices (e.g. Abstract of 

quantities executed as per running bill format given in CPWA Code) online 

along with a generic invoice format which can be customized by the project 

authority for the project use. 

2. Allow authorized contractors to access online invoice forms and submit invoice 

online. 

3. For every invoice submitted and entered into the system, system should create a 

unique Invoice/bill id. Any further communication and tracking should be based 

on that. 

4. Should allow the contractors to track the status of their application. The points 

at which the status can be tracked would be: 

• Invoice processed at sub engineer level 

• Submitted to SDO for clearing 

• Invoice processed at SDO level, bill created 

• Submitted to EE for clearing 

• Invoice accepted / rejected at EE level 

• Queued in Ways & Means Management 

• Bill cleared 

The application could be tracked through the IFMIS website, IVRS , SMS 

5. System should generate notifications for the contractor (through SMS / email / 

voice message etc.) at each of the following stages: 

• Invoice processed at sub engineer level (measurements verified) in MB 

• MB submitted to SDO for clearing 

• Invoice accepted / rejected at SDO level. Bill created 


• Invoice accepted / rejected at EE level. Bill passed & uploaded for 

payment. 

• Queued in Ways & Means Management 

• Bill cleared and amount credited to the contractor’s account 

6. Should allow all the registered users i.e. sub engineer, sub divisional officer, DA, 

executive engineer and others to access the system based on their level of 

authentication 

7. The system should require a two level (EE & DA) authentication for processing 

and clearing of any invoice/bill 


Attachment B 


and clearing of any invoice/bill 

8. Should provide a search option to contractors to check the status of their 

application. The search should provide the results based on following search 

criteria 

• Contractor ID 

• Contractor Name 

• Invoice Date/ID 

9. Should not allow the EE office to enter same invoice numbers/ID for two 

different invoices 

10. On receiving the invoice should allow the office to enter the project ID. As soon 

as the project ID is entered into the system the system should populate the 

project plan, terms of reference, original contract and online measurement book. 

11. Should allow the sub engineer / SDO to enter the following bill details over the 

bill submission page. (The fields marked as self filled should generate 

automatically) 

• Invoice No. (to be filled by sub engineer) 

• Bill no. (token leaf bills) 

• Head details (to be filled by sub engineer) 

• Contractor’s name (self filled) 

• Contractor’s ID (self filled) 

• TAN & CIN Number of the company (self filled) 

• Contractor’s bank account number (self filled) 

• Bank branch name, location and code (self filled) 

• Address of the company (self filled) 

• Contact details of the contractor (self filled) 

• Milestone Achieved or not (to be filled by sub engineer) – Yes or No 

• Claimed amount (to be filled by office) – Rs… 

• Passed amount (to be filled by DA/EE) – Rs… 

• Penalties to levy on contractor - if any (to be filled by relevant authorities 

(SA/SDO/DA/EE) – Rs… 

• Deductions (to be filled by DA/Auditor) – Rs… 

• Sub Engineer’s/SDO/EE Remarks (to be filled by sub 

engineer/SDO/EE) 

• Digital signature of the EE 

12. Should allow the EE to upload the bills only if they are appended by his digital 

signature 

13. Should generate alerts for the sub divisional officer once the sub engineer has 

submitted the MB to SDO’s 

14. Should change the status of application from invoice submitted to MB 

forwarded to SDO 


Attachment B 


15. Should generate an alert for the SDO if the sub engineer does not upload MB 

within specified (SLA) days of invoice submission, as per the auto escalation 

matrix 

16. Should allow the office to enter the invoice number, as soon as the office enters 

the invoice number the invoice details should be populated the system 

17. Should allow the office to enter the project ID into the application, as soon as 

the office enters the project ID the project plan, online measurement book, 

corresponding terms of reference, original contract document and budget 

availability statement should open up automatically 

18. Should allow the SDO to accept / reject / edit the MB at his own end. 

19. Should allow the SDO to seek clarification or mark for action to sub engineer 

20. Should allow the SDO to enter the reasons for the rejection of the MB or the 

part there of 

21. Should allow the SDO to edit the MB at his own end for certain minor changes 

22. Should allow the SDO to approve quantities (partially) as per his/her own 

verification 

23. In case of an approval (including partial approval) should allow the EE/PIU 

staff to raise a bill in the IFMIS. 

24. Should generate an alert for EE if the SDO does not act upon the received MB 

within specified Days (as per SLA) of receiving the MB as per the auto escalation 

matrix 

25. Should generate an alert for the EE as soon as the SDO updates the 

measurements/ at his own end for submission of bills 

26. Should show DA/EE the invoice number, remarks made by the Sub-engineer/ 

SDO as soon as he views the bill request 

27. Should allow the DA/EE to enter the invoice number over the system, as soon 

as the DA/EE enters the invoice number the invoice details should be 

populated over his end 

28. Should allow the DA/EE to view the project ID in the bi, as soon as the SDO 

creates/uploads the bill. The project ID the project plan, online measurement 

book, corresponding terms of reference, original contract document and budget 

availability statement should open up automatically 

29. Should allow the DAEE to accept / reject / edit the bill at his end 

30. Should allow the EE to seek clarification or mark for action to sub engineer 

through SDO 

31. Should allow the Treasury Disbursement System to transfer the bill amount to 

the contractor’s bank account directly though direct debit facility (ECS, etc.). 

The alerts can be sent through the following options: 

• Email 

• SMS 

• Updation over the application ID 


Attachment B 


32. Should generate alerts for the relevant users that the payment of given ……… 

amount has been made in the account of contractor on such and such date 

33. Should generate auto alerts for Superintendent Engineer and Chief engineer if 

the Executive Engineer does not process the bill without an appropriate reason 

within predefined time days 

34. Should system generate notifications (through SMS / email / voice message etc.) 

at each of the following stages: 

• Measurements taken/verified at sub engineer level 

• Submitted to SDO for clearing 

• Bill created at SDO level 


• Bill accepted / rejected at EE level 

• Submitted to treasury disbursement system 

• Bill cleared by Ways & Means system and contractor’s account credited. 


Attachment B 


1.2.8 Advance Payment to Contractors 

Table 22: Functional Requirement Specifications – Advance Payment 

Business Requirement – Advance Payment to Contractors 

Sr. No. 


1. Should allow the EE/PIU staff to enter all the invoices for advance received at the 

front desk from the contractor/supplier/service provider for advance payments. 

The bill clerk will make the following entries while accepting the invoices for 

advance payment: 

• Claim ID (System Generated) 

• Claim date 

• Contractor’s name 

• Contractor’s ID 

• Invoice number 

• Contractor’s bank account details (already registered in the system) 

• Particulars of security received (e.g. bank guarantee, etc) 

2. Should provide the facility to EE/PIU to accept or reject the advance payment 

claim made by the contractor 

3. Should generate a rejection ID in case the contractor/supplier/service provider 

request has been rejected. The EE’s staff will enter the following details over the 

system: 

• Claim id (System generated) 

• Rejection ID (System Generated) 

• Rejection Date (System Generated) 

• Rejection Code ((System Generated) 

• Reason for rejection (standard reasons from dropdown menu or to be filled 

in) 

4. Should allow the bill clerk to accept the request and upload it over the system, the 

bill clerk will update the following entries in the pre defined form: 

• Claim id (System Generated) 

• New / Resubmitted 

• Invoice Date 

• Invoice Type (Drop Down Menu) 

• Head Details (To be system generated based on the bill type – From drop 

down menu) 

• Budget Flag 

• Sanction details 

• Gross Amount 

• Net Amount 

• Payee Department 


Attachment B 


• Balance Budget available in the HOA 

5. Should generate an alert for the Executive Engineer/PIU as soon as the bill clerk 

raises a bill for advance payments 

6. Should allow the EE/PIU to view the bill raised by the bill clerk over his system 

7. Should provide the facility to EE/PIU to review the Measurement Book if required, 

Bank Guarantee details contract uploaded over the system 

8. Should provide the EE/PIU the following options: 

• Accept 

• Reject 

• Object and resend to bill clerk 

• For processing the raised bill 

9. Should allow the EE/PIU to enter the following format in case of a rejection: 

Claim id (System generated) 


• Rejection Date (System Generated) 

• Rejection Code ((System Generated) 

• Reason for rejection (description to be filled in by bill clerk) 

10. Should allow the EE to fill in the following details in case of an objection 


• Objection ID (System Generated) 

• Objection Date (System Generated) 

• Objection # 1: (Standard objection filled from dropdown menu other to be 

recorded)………………………….. 

• Objection # 2: (Description to be filled)………………………….. 

• Objection # n: (Description to be filled)………………………….. 

11. Should generate an alert for the designated staff in case EE/PIU has raised any 

objections over the raised bill 

12. Should allow the designated staff to respond to the raised objections in a serial wise 

manner: 


• Objection ID (System Generated) 

• Objection Date (System Generated) 

• Objection # 1: (Filled by EE/PIU)………………………….. 

• Actions taken over the Objection # 1 (Filled by Bill Clerk)……………… 

• Objection # n: (Filled by EE/PIU)………………………….. 

• Actions taken over the Objection # n (Filled by Bill Clerk)……………… 

13. Should generate an alert for the Executive Engineer/PIU as soon as the bill clerk 

uploads the report over the actions taken at his end 

14. Should allow the Executive engineer/PIU to accept the request for payment 


Attachment B 


15. Should allow the EE to view the bank guarantee details while clearing the advance 

payments to the contractor/supplier/service provider 

16. Should present EE record of all the past payments made to the contractor/ 

supplier/service provider 

17. Should allow the EE to register all the requests for advance payment 

18. Both in the case or approval / rejection, EE’s approval / rejection should be made 

visible to all the relevant stakeholders over the application 

19. In case of an approval should allow the EE/PIU staff to raise a bill in the IFMIS. 

20. Should allow the EE/PIU to make payment directly to the contractor’s bank 

account 

21. Should generate an alert on amount transfer from EE to contractor’s account 

22. Should maintain a database of all the advance payments 

23. Should account for recovery/adjustment of advance payment while making the next 

payments to the contractor 

24. Should provide details of the advances that have been paid till date to the 

contractor/supplier/service provider before any new payments 


Attachment B 


1.2.9 Works Contingency Expenses 

Table 23: Functional Requirement Specifications – Works Contingency Establishment Expenses 

Business Requirement – Works Contingency Establishment Expenses 

Sr. No. 


1. The system should provide the functionality to defining overall limit (%) and limits 

(%) of various individual items in work contingency in the system 

2. The system should provide the functionality to define maximum % of work 

contingency in different stages of project implementation 

3. The system should provide the functionality to allocate work charge establishment 

expenditure over different ongoing projects within limits defined 

4. The system should provide the functionality to allocate work contingency 

expenditure over different ongoing projects within limits defined 

5. The system should provide the functionality to restrict allocation of work 

contingency amount at various stages of project implementation as per pre-defined 

limits for the particular stage. 

6. The system should provide the functionality to enter & book work contingency in 

related works accounts registers and ledgers as per received vouchers 

(invoices/bills/hand receipts) 

7. The system should provide the functionality to raise the bill for works contingency 

establishment expenses 

8. The system should provide the functionality to book/allocate work contingency 

expenditure against only an active project 

9. The system should provide the functionality to only raise a bill against a specific 

work contingency head or account 

10. The system should provide the functionality to do a pre audit of the received 

vouchers (invoices/bills/hand receipts) for the availability of budget against a 

particular work contingency head 

11. The system should provide the functionality to populate the salary details from 

work-charge contingency employee database 

12. The system should provide the functionality to the bill clerk to add comments or 

remarks against every expenditure line entry 

13. The system should provide the functionality to move the vouchers 

(invoices/bills/hand receipts) entry to Divisional accountants work flow once the 

entered in related records and submitted by Bill clerk 

14. The system should provide the functionality to bill clerk to move vouchers 

(invoices/bills/hand receipts) in office records in office file to DA/EE for 

verification of entry. 

15. The system should provide the functionality to bill clerk to modify or delete the 

vouchers (invoices/bills/hand receipts) entry in the system before the divisional 

accountant approves or reject it 

16. The system should provide the functionality to Divisional accountant to either 

approve or reject the vouchers (invoices/bills/hand receipts) entry 


Attachment B 


approve or reject the vouchers (invoices/bills/hand receipts) entry 

17. The system should provide the functionality to DA to add comments or remarks 

(dropdown menu or text box) in case the voucher is rejected or returned. This field 

should be mandatory on non acceptance of entry/voucher 

18. The system should provide the functionality to bill clerk to make modification in the 

rejected entry/voucher and resubmit or raise a fresh new entry/voucher and delete 

the existing entry/voucher. 

19. The system should provide the functionality to transfer the entry/voucher from 

DA’s workflow to Executive Engineer’ workflow once it is approved. 

20. The system should provide the functionality for EE to approve or reject the 

entry/voucher. 

21. The system should provide the functionality to EE to add comments (dropdown 

menu or text box) in case the entry/voucher is rejected. This should be a mandatory 

field 

22. The system should provide the functionality to transfer the entry/voucher to 

treasury disbursement system for creating bill for disbursement 

23. The system should provide for the purpose of bill creation for disbursement the 

budget against each item of work expenditure (work-charge establishment & workcharge 

contingency) be made available by aggregating scheme budgets under all 

scheme IDs and within overall limit (%) and limits (%) of various individual items as 

per defined in work contingency in the system 

24. The system should provide for check for financial powers/sanction as in other cases 

of disbursement 

25. The system should provide for treatment of work contingency expenditure within 

the framework of normal office contingency rules and regulations 


Attachment B 


1.3 Debt & Investment Management 

Table 24: Functional Requirement Specifications – Overall Debt Management System 

Business Requirement – Overall Debt Management System 

Sr. No. 


1. DMS should have the facility for reporting on: 

• Debt sustainability analysis. 

• Status of aid allotment. 

• Strategic framework for borrowing. 

• Reserves and exchange risk management. 

• Statistical compilations such as overall effect on balance of payments etc 

2. The DMS should provide the relevant report writer facilities. It should also 

provide facilities for retrieving user-specified information from the database 

Whenever required. 

3. The DMS should have the capability to interface with the accounts payables system 

and reconcile/post the information of payments pertaining to debt servicing and 

repayment of loans 

4. The DMS should be able to transfer information of due but not paid amount of 

interest/loan installments of various loans and market borrowings to the accounts 

payable system and update current liability account also 

5. The DMS should be able to record the actual billing information either from paperbased 

documents or from electronic files sent by the lender. The DMS should have 

the facility of calculating billing information and comparing it with the actual billing 

information received from the lender. It should also have the capability of 

generating forecasted payment schedules automatically or entering these manually. It 

should have the facility of interfacing with the Accounts payable module to submit 

the RFPs electronically and to transfer information about the forecasted payment 

schedules 

6. The DMS should have the capability of setting up special accounts for loans. It 

should be able to interface with the Accounting system and retrieve information 

about the movement of funds in these special accounts which should be subaccounts 

within the Treasury Single Account 

7. The DMS should be able to interact with the ACCOUNTING SYSTEM to transfer 

details about the disbursement schedule of monetary aid received from the donors 

8. The DMS should interact with the fixed asset module of the ACCOUNTING 

SYSTEM to reconcile the acquisition/ creation of assets out of aid money, as 

reported by the beneficiary budget entity, with the aid recorded in the DMS 

9. The DMS should have the facility of automatically generating the requisite invoices 

for payment of loan tranches for loans given by government. The system should also 

be able to interact with the ACCOUNTING SYSTEM to transfer the RFPs 

electronically. 


Attachment B 


10. The DMS should interface with the ACCOUNTING SYSTEM to receive 

information about the actual disbursement of loans and should be able to register 

the payments into the loan accounts of the agency who has taken the loan 

11. DMS should have the capability of generating the invoices in accordance with the 

repayment dates in the loan agreement. The system should interface with the 

ACCOUNTING SYSTEM to register the corresponding receivables 

12. The DMS should be able to transfer information to the accounts receivable system 

regarding the disbursement schedules of loans 

13. The DMS should provide a facility for entering the repayment advice received 

through the bank 

14. It should also have the capability of posting these repayment details in the individual 

loan ledgers 

15. The DMS should be able to interface with the ACCOUNTING SYSTEM to 

retrieve the information on receipts pertaining to repayment of debt and should 

print reconciliation reports 


Attachment B 


1.3.1 Raising Market Borrowings 

Table 25: Functional Requirement Specifications – Raising Market Borrowings 

Business Requirement – Raising Market Borrowings 

Sr. No. 


1. Should be able to generate a resource chart with the help of the system * 

2. Should have a separate debt management section with the following login options: 

• Market Borrowing 

• Loans from Financial Institutions 

• Central Government Loans and Grants 

3. Should allow the user to choose the option of market borrowing 

4. Should provide two options under this section: 

• Capturing of Market Borrowings details (raising & repayment) 

• Should allow the user to choose any of the above options 

5. On choosing the option, should generate a unique Borrowing ID for each new 

borrowing 

6. Should show the borrowing ID whenever any transaction related to a particular 

borrowing is carried out 

7. Should capture the following details related to each new loan (bearing a unique 

borrowing id): 

• Amount Borrowed 

• Source of Borrowing 

• Date of Borrowing 

• Details of Borrowing (coupon rate, discount offered, rate of interest, face 

value etc.) 

• Terms of Reference of borrowing 

• Duration of borrowing 

• Repayment Schedule 

8. Should have a feature of importing the details recorded in the CS DRMS application 

to IFMIS and vice versa 

9. Should update the states receipt and liability account as soon as a new borrowing is 

taken by the state 

10. Should enable updation of relevant accounts on market borrowings by the AG’s 

11. Should enable DoF to use DSS for most economic market borrowing decisions 


Attachment B 


1.3.2 Repayment of Market Borrowing 

Table 26: Functional Requirement Specifications – Repayment of Market Borrowings 

Business Requirement – Repayment of Market Borrowings 

Sr. No. 


1. (In case RBI sends FLAT FILE to Finance Department regarding the repayment) 

2. Should be able to convert the Flat File received from RBI into a usable format in 

IFMIS 

3. Should update the IFMIS automatically based on the information received from the 

RBI 

4. Should update the State Disbursements Account based on the updation done in the 

IFMIS – Market Borrowings Module 

5. Should update the State Liabilities Account based on the updation done in the 

IFMIS – Borrowings Module 

6. (In case RBI does not sends FLAT FILE to Finance Department and sends the 

details of repayment manually or through *.PDF or any non usable formats) 

7. Should allow the user to click the option of Repayment of Market Borrowings 

8. Should open the Repayment of Borrowings section for the concerned user after 

checking his credentials as per the login component. 

9. Should allow the concerned user to update the following details over the Repayment 

of Borrowing Section: 

• Borrowing ID (against which the repayment was done) 

• Amount repaid 

• Distribution of Repayment (Principle & Interest) 

• Date of Repayment 

• Total Amount Repaid 

• Remaining Amount 

• Amount of next repayment 

10. Should update the related module as soon as the repayment is made 

11. Should update the State Disbursement Account & State Liabilities Account on the 

repayment 

12. Should allow DoF to assess resources requirements for repayment of each market 

borrowing over give period of time 

13. Should link loan and market repayments with the budget module 

14. Should keep track of any wrong payments made by the state government 

15. Should capture the details of the market borrowings that have not been claimed after 

the maturity period also. The system should generate alerts over such borrowings to 

the buyer and if they are still not claimed should transfer them as revenue to the 


Attachment B 


state. 


Attachment B 


1.3.3 Obtaining Loans from Financial Institutions 

Table 27: Functional Requirement Specifications – Obtaining Loans from Financial Institutions 

Business Requirement – Obtaining Loans from Financial Institutions 

Sr. No. 


1. System should have separate loans module in the IFMIS 

2. Should allow the Finance Department Representative to access the loan module as 

per the login component 

3. Should allow the user to select the type of loan, from the following options: 

• Loans / Grants from centre 


4. Should present the Finance Department following options, when he logs in to the 

Loans Module: 

• Fresh Loans 

• Updation / Editing of Loan Details 

• Repayment of Loans 

5. Should allow the Finance Department Representative any of the above option 


Fresh Loans 

1. Should open the Fresh Loans Page whenever the Finance Department 

Representative elects the Fresh Loans option 

2. Should throw up an option to the user whether he wants to register a new loan take 

by the state government or he wants to quit the fresh loans system 

3. Should allow the user to select any of the above options 

4. Should take the user to the main page in case the DoF selects quit the fresh loans 

section 

5. Should generate a Unique Loan ID if the user selects a Fresh Loans option 

6. Should present the DoF Representative the following blank fields, which he should 

be allowed to fill and upload: 

• Loan ID(self generated) 

• Name of Financial Institution from which the loan has been taken 

• Principle Amount 

• Interest Rate (as on date of loan receiving) 

• Loan Duration 

• Loan Installment Period (Monthly, Quarterly, Half Yearly, Yearly) 

• Other Terms & Conditions 


Attachment B 


• Account Details of Financial Agency for loan repayment 

7. Should allow the DoF representative to upload the above information over the 

Loans module of IFMIS 

8. Should generate a message on both successful / unsuccessful uploading of guarantee 

details 

9. Should allow the DoF’s representative to capture the following details pertaining to 

the received loan amount: 

• Mode of Loan Transfer 

o Cheque 

o Online transfer to state’s receipt account 

• For cheque entries DoF’s representative will make the following entries: 

o Loan ID 

o Cheque Number 

o Name of Financial Institution 

o Branch 

o Cheque Number 

o Cheque Amount 

o Loan Amount 

o Received Amount 

o Balance amount 

o Cheque issuance date 

o Cheque credit details (Amount credited, Receipt Head, e-Challan No 

& date) 

10. For online transfer to the state’s receipt account the system would capture the 

following details on its own from receipt module: 

• Loan ID 

• Transaction ID 

• Name of Financial Institution 

• Branch 

• Account number from which amount is received 

• Receipt amount 

• Requested amount 

• Balance amount s 

• Credit details (Amount credited, Receipt Head, e-Challan No & date) 

11. Should update the State Liabilities Account as soon as a new loan amount is received 

in government account 

12. Should allow the Finance Department Representative – Loan Management Officer 

to edit the incorrect loan entries in the IFMIS 

13. Should allow him to the changes only in the following Sections: 



• Interest Rate 



Attachment B 


• Loan Installment Period 



14. Should create an audit log for above & send web mail to all concerned (DoF, 

Financial Institution) 

15. Should show the DoF representative a success message on successful updation of 

the details 


Attachment B 


1.3.4 Loan Repayment to Financial Institutions 

Table 28: Functional Requirement Specifications – Loan Repayment to Financial Institutions 

Business Requirement – Loan Repayment to Financial Institutions 

Sr. No. 


1. Should generate alerts (through mail / SMS) …… days in advance on the fixed date 

of loan repayment installment and payment of interest for the DoF – Representative 

– Loan Officer 

2. Should allow the DoF Representative to create and upload the payment of interest 

and loan repayment requisition (e-sanctions) over the IFMIS. The Loan Repayment 

Requisition would contain the following details: 

• Loan ID 





• Loan Installment Period (Monthly, Quarterly, Half Yearly, Yearly) 

• Loan installment Amount (Principle & Interest) 

• Installment Period 

• Account details of Financial Institution 

• Amount of payment of interest and/or loan repayment 

• Date on which due to be paid by credit to FI bank account 

• Budget Heads of Account 

• Available Budget Amounts 

3. Should generate an alert for the DDO of Finance Department / Chief Accounts 

Officer (CAO) over the uploading of loan repayment requisition 

4. Should allow the DoF’s DDO / CAO to view the requisition (e-Sanction) uploaded 

by the Loan Officer 

5. Should allow the DDO / CAO to create the bill for loan installment over the 

IFMIS. Should allow the DDO / CAO to enter the following details: 

• Head details (through drop down menu): 

• Loan ID (to be selected by DDO from loan database) : 

• Principle Installment Amount (Auto Generated through requisition) or 

• Interest Installment Amount (Auto Generated through requisition) 

• Account Details of the Financial Institution (Auto Generated) 

6. Should allow the DDO / CAO to have an access to DoF’s budget before the bill 

preparation and submission over the IFMIS 

7. Should allow the DDO / CAO to transfer the interest/loan installment amount 

directly into Financial Institution’s account through the State Disbursement System 

8. Should update the States Disbursement Account 


Attachment B 


9. Should update the loan account automatically 

10. Should update the State Liabilities Account 




Attachment B 


1.3.5 Loans from NABARD and their Repayment 

Table 29: Functional Requirement Specifications – Loans from NABARD and their Repayment 

Business Requirement – Obtaining Loans from NABARD 

Sr. No. 


1. Should keep track of all previous loans taken from NABARD 

2. Should allow the application to interact with the planned budget and project 

management modules of the system 

3. Should be able to input details of the various projects from the project management 

module 

4. Should allow the DoF to make sufficient budgetary allocation to particular head as 

per the Budget Management module 

5. Should allow the DDO to view the amount under the particular heads of accounts 

under the NABARD head 

6. Should allow the DDO to withdraw money from the particular HOA as the 

Disbursement module 

7. Should allow the DDO of the concerned department to enter the details of 

expenditure claim over the system 

8. Should generate an alert for Department of Finance and NABARD over the 

submission of claim details by the DDO 

9. Should aloe the DoF / NABARD officials to view the expenditure details online 

10. Should allow the NABARD officials to make online payments for mobilization 

advance as well as for the expenditure claim OR should allow the Department of 

Finance to enter the received amount details over the state receipt system (If 

NABARD does not agrees on online transfer of funds) 

11. Should provide an interface between the loans received from NABARD and State 

Receipt System 

12. Should allow NABARD to issue the promissory note online (If NABARD agrees) 

13. Should allow the DoF to issue the guarantee over the receipt of promissory note 

online (If NABARD agrees) 

14. Should allow the DoF to enter the loan conditions as fixed by NABARD over the 

system 

15. Should open the Fresh Loans Page whenever the Finance Department 

Representative elects the Fresh Loans option 

16. Should take the user to the main page in case the DoF selects quit the fresh loans 

section 

17. Should generate a Unique Loan ID if the user selects a Fresh Loans option 

18. Should present the DoF Representative the following blank fields, which he should 



Attachment B 



• Loan number as provided by NABARD 

• Loan ID(self generated) 

• Project name 

• Scheme name 

• Project id 

• Scheme id 



• Loan Duration (generally 5 years) 

• Loan Installment frequency (Monthly, Quarterly, Half Yearly, Yearly) 

• Loan repayment start date 

• Moratorium period (generally 2 years) 

• % of Loan amount under the moratorium period 

• Moratorium period start date 


• Account Details of NABARD for loan repayment 

19. Should allow the DoF representative to upload the above information over the 

Loans module of IFMIS 

20. Should update the State Liabilities Account as soon as a new loan amount is received 

in government account 

21. Should allow the Finance Department Representative – Loan Management Officer 

to edit the incorrect loan entries in the IFMIS 

22. Should allow him to the changes only in the following Sections: 





• Loan Installment Period 



23. Should create an audit log for above & send web mail to all concerned (DoF, 

Financial Institution) 

24. Should show the DoF representative a success message on successful updation of 

the details 

Loan Repayment to NABARD 

1. Should generate alerts for the loan officer – DoF for repayment of loans starting one 

month in advance to the actual repayment date 

2. Should 

3. Should allow the DoF Representative to create and upload the payment of interest 

and loan repayment requisition (e-sanctions) over the IFMIS. The Loan Repayment 


Attachment B 


Requisition would contain the following details: 

• Loan ID 




• Loan Installment frequency (Monthly, Quarterly, Half Yearly, Yearly) 


• Installment Period 

• Account details of Financial Institution 

• Amount of payment of interest and/or loan repayment 

• Repayment under normal condition / moratorium period 

• Date on which due to be paid by credit to FI bank account 

• Budget Heads of Account 

• Available Budget Amounts 

4. Should generate an alert for the DDO of Finance Department / Chief Accounts 

Officer (CAO) over the uploading of loan repayment requisition 

5. Should allow the DoF’s DDO / CAO to view the requisition (e-Sanction) uploaded 

by the Loan Officer 

6. Should allow the DDO / CAO to create the bill for loan installment over the 

IFMIS. Should allow the DDO / CAO to enter the following details: 

• Head details (through drop down menu): 

• Loan ID (to be selected by DDO from loan database) : 

• Principle Installment Amount (Auto Generated through requisition) or 

• Interest Installment Amount (Auto Generated through requisition) 

• Account Details of the Financial Institution (Auto Generated) 

7. Should allow the DDO / CAO to have an access to DoF’s budget before the bill 

preparation and submission over the IFMIS 

8. Should allow the DDO / CAO to transfer the interest/loan installment amount 

directly into Financial Institution’s account through the State Disbursement System 

9. Should update the States Disbursement Account 

10. Should update the loan account automatically 


12. Should link the loan repayments with the budget module, so that enough provisions 

can be made in the budget for loan repayments 

13. Should keep track of any wrong repayments made to GoI 



Attachment B 


1.3.6 Obtaining Central Government Loans/Grants 

Table 30: Functional Requirement Specifications – Obtaining Central Government Loans / Grants 

Business Requirement – Central Government Loans / Grants 

Sr. No. 


1. System should have separate loans module in the IFMIS 

2. Should allow the user to access the loan module as per the login component 

3. Should allow the user to select the type of loan, from the following options: 

• Loans / Grants from centre 


4. Should present the user to choose from the following options, when he logs in to 

the Loans Module: 

• Fresh Loans 

• Updation / Editing of Loan Details 

• Repayment of Loans 


6. Should allow the DoF – Representative to enter the details of sanction order over 

the system in a pre defined format 

7. Should generate alerts for the relevant parties over the uploading of sanction order 

both by the DOF as well as AGMP 

8. Should allow the AGMP to enter the loan details over the system on receipt of 

credit advice from RBI 

9. Should allow the AGMP to import the flat file (if any) sent by the RBI – CAS into 

the system 

10. Should allow the AGMP to enter the details of the clearance memo over the system 

11. Should generate alerts for DoF on the submission of clearance memo by AGMP 

12. Should automatically update the State’s Receipt Account 




Attachment B 


1.3.7 Central Government – Loan Repayments 

Table 31: Functional Requirement Specifications - Central Government Loan Repayments 

Business Requirement – Central Government Loan Repayments 

Sr. No. 


1. Should provide projections of resources requirements for payment of interests and 

repayment of loans over a defined period (for input to MTFF and estimating budget 

requirements, i.e. BE/RE) 

2. Should generate alerts for the AGMP / DoF for interests payments and/or loan 

repayment 

3. Should generate a loan repayment schedule on its own based on the defined terms & 

conditions of loan in the system 

4. Should allow the AGMP to create and upload the loan repayment requisition over 

the IFMIS. The Loan Requisition page would contain the following details: 

• Loan ID 

• Name of Central Ministry from which the loan has been taken 




• Loan/Interests Installment Period (Monthly, Quarterly, Half Yearly, Yearly) 


• Details of budget heads for disbursement 

5. Should generate an alert for the Loan Management Officer of the Finance 

Department over the uploading of loan repayment requisition 

6. Should allow the DoF’s to view the requisition uploaded by the AGMP 

7. Should allow the Loan Management Officer of the Finance Department to provide 

online approval for loan repayment to AGMP 

8. Should allow the AGMP to have an access to DoF’s budget before the advice is sent 

to CAS Nagpur 

9. Should allow the AGMP to view DoF’s approval 

10. Should allow the AGMP to generate a loan repayment advice through the system. A 

soft copy of the advice should be stored in the system itself. 

11. Should forward soft copy of the loan repayment advise for DoF also 

12. Should allow the AGMP to update the system as soon as it gets information from 

CAS – RBI of the actual money transfer. 

13. Should generate alerts for the DoF whenever AGMP updates the system with actual 

disbursement details from RBI/AGMP. 

14. Should automatically update the State’s Disbursement Account 


Attachment B 


15. Should update the DMS and the State Liabilities Account 




Attachment B 


* Resource Chart Preparation 

Table 32: Functional Requirement Specification: Resource Chart Preparation 

Business Requirement – Resource Chart Preparation 

Sr. No. 


1. Should allow the State Government to assess its own resource projections from 

Revenue Forecast Models inbuilt in the system 

2. Should provide access to information over projected central government taxes 

devolution 

3. Should provide information over repayment of various kinds of loans and 

interests thereon by the State Government 

4. Should be able to access information on committed expenditures for non 

planned budget module 

5. Should be able to assess plan budget requests and resource gaps 

6. Should be able to analyze options available for bridging the resource gaps 

7. Should be able to compare the resources projections with the MTFF projections 

8. Should be able to develop the most economic mix for bridging the resource gap 

(through loans and market borrowings) 

9. Should be able to compile and generate the resource chart on its own 


Attachment B 


1.3.8 Loans for Externally Aided Projects 

Table 33: Functional Requirement Specifications – Loans / grants for Externally Aided Projects 

Business Requirement – Loans / Grants for Externally Aided Projects 

Obtaining Loans / Grants 

Sr. No. 


1. Should allow to select between three options: 

• 70 / 30 loan 

• Back to back loan 

• Grant 

2. Should provide the following options once an option for any of the loans is selected: 

• Fresh loan / grant entry 

• Editing of current entries 

• Amount of advance/reimbursements received 

• Loan repayments 

• Viewing the current information 

3. Should be able to capture the details of the sanction letter issued by GoI and RBI in 

the following way: 

• Sanction order number 

• Date 

• Loan number ( as provided by GoI) 

• Loan Account Number 

• Loan id as generated by the system 

• Scheme / project name 

• External Agency’s name : 

• Type of funding (70 / 30, back to back or grant) 

• Amount released/reimbursed 

• If 70 / 30 chosen then: 

o Loan id 

o Loan amount (in INR) 

o Loan amount (in foreign currency) 

o Grant Demand no. and other head details 

o Interest rate 

o Repayment period (generally 20 years) 

o Repayment conditions 

o Repayment period start date 

o Repayment frequency (monthly mostly) 

o Number of yearly payments (10 currently) 

o Repayment installment (from dd/ mm / yyyy ……. To dd/ mm / 

yyyy ………..) – exclusive of moratorium period payments 

o Moratorium conditions (duration of moratorium period, start/end of 


Attachment B 


moratorium period etc.) 

o Repayment installment (from dd/ mm / yyyy ……. To dd/ mm / 

yyyy ………..) – inclusive of moratorium period payments 

o Penal interest rate 

o Heads of accounts from which repayment of loan amount would be 

made 

o Other terms and conditions for the loan 

• In case of back to back loans 

o Loan Number ( as provided by GoI) 

o Loan id 

o Scheme / project name 


o Loan equivalent in Indian currency 

o Interest rate for first 6 months 


o Repayment period 

o Repayment conditions in words 


o Repayment frequency 

o Number of yearly payments 

o Other terms and conditions for the loan laid by the funding agency 

o Heads of account under which the loan amount would be captured 

o Charges levied by the external agency 

Processing (upfront) fees 

Commitment charges 

Other charges levied by the funding agency 

• In case of grants 

o Grant number ( as provided by GoI) 

o Grant id 


o Grant amount (in foreign currency) 

o Grant equivalent in Indian currency 

o External agency’s contribution (in %) 

o State government’s contribution (in %) 

o Other terms and conditions for the loan laid by the funding agency 

4. Should maintain a scanned / soft copy of the sanction order in the system 

5. Should allow one term settlement of loans 

6. Should generate a unique loan / grant id as soon as a new loan or grant is registered 

over the system 

7. Should always link the unique loan / grant id with the loan or grant number received 

from Funding Agency/GoI / RBI 

8. Should allow the competent authority to edit the repayment conditions / criteria at 

any point of time e.g. in case of back to back loans should be allowed to change the 


Attachment B 


interest rates on a periodic (generally six monthly) basis 

9. Should display the various foreign exchange currency rates over the system on the 

given day 

Reimbursement Claims 

1. Should provide various types of reimbursement claim form with due dates 

2. Should provide linkages between budget/expenditure HOA and disbursement 

categories 

3. Should port expenditure incurred under various HOA to related disbursement 

category 

4. Should allow spending (implementing) units to select required claim form and 

compile unit-wise Reimbursement Claims for given period including ‘nil’ claims 

5. Should provide claims to be compiled disbursement category-wise 

6. Should allow spending unit to view and edit compiled Reimbursement Claims to 

adjust for non reimbursable advances (expenditure) or shifting amounts from within 

various disbursement categories if wrongly compiled 

7. Should provide list of vouchers to be attached 

8. Should provide hyperlink of an expenditure item to its scanned copy of voucher 

9. Should allow spending unit to upload reimbursement claim to its PMU 

10. Should allow PMU to view and edit reimbursement claim received from spending 

11. Should generate alerts for spending units who have not uploaded (submitted) 

reimbursement claims by due date including ‘nil’ claims 

12. Should allow PMU to consolidate all reimbursement claims received from various 

spending units 

13. Should provide interface with the system of CAAA for uploading claims 

14. Should allow PMU to upload consolidated reimbursement claims to CAAA in their 

system 

15. Should capture information coming from CAAA about claims 

clearances/acceptance position 

16. Should generate reports of all uploaded (submitted) reimbursement claims, claims 

cleared, claims returned under objections, claims rejected and pending claims, etc 

17. Should integrate with DMS for updation of amounts of loans (SCA) received as 

either advance or reimbursement claims collating CAAA information with RBI 

credits information. 

Loan Repayments 

1. Should generate alerts (through mail / SMS) …… days in advance on the fixed date 

of loan repayment installment and payment of interest for the DoF – Representative 

– Loan Officer 


Attachment B 


2. Should be able to enter the loan repayment details received from GoI/AGMP/ RBI 

over the system 

3. In case of back to back loans, should generate alerts every 5th month that the 

interest/conversion rates have to be revised and should generate continuous alerts 

every day till the loan rates have been revised 

4. Should allow the DoF representative to enter the loan repayment details over the 

system 

5. Should allow the DoF representative to enter the following details for loan 

repayments: 

• Letter number informing about the repayments (if receiving info via letter) 

• Date of receiving the information 

• Date of actual repayment 

• Loan number (as provided by GoI/Funding Agency ) 

• Loan Account Number 

• Loan id as generated by the system 

• Scheme / project name 

• External Agency’s name : 

• Type of loan (70 / 30, back to back or grant) 

• If 70 / 30 chosen then: 

o Loan id 

o Loan amount (in INR) 


o Grant Demand no. and other head details 

o Interest rate 

o Repayment period (generally 20 years) 


o Repayment installment made with distribution of loan and interest 

payment (from dd / mm / yyyy……. to dd / mm / yyyy………..) 

exclusive of moratorium period payments 

o Repayment installment made with distribution of loan and interest 

payment (from dd / mm / yyyy……. to dd / mm / yyyy………..) 

inclusive of moratorium period payments 

o Total loan repayment made (both normal repayments + moratorium 

repayments) 

o Penal interest paid (if any) 

o Loan amount left to be paid 

o Interest amount left t be paid 

o Heads of accounts from which repayment of loan and interest 

amount has been made 

• In case of back to back loans 

o Loan Number ( as provided by GoI) 

o Loan id 




Attachment B 


o Loan equivalent in (Indian currency-INR) 

o Repayment made in foreign currency (with distribution of loan and 

interest amount) 

o Repayment made in Indian currency (with distribution of loan and 

interest amount) 

o Difference due to the fluctuating foreign currency rate (+ / - ) {If 

positive then it would be treated as a revenue and the receipt account 

of the state government would be credited and in case of losses 

owing to increase of increase in the rate of foreign currency it would 

treated as a disbursement from disbursements account} 

o Interest rate (for the six monthly period) 

o Penalties if any 

o Bank processing charges 

o Repayment period 

o Repayment frequency 

o Number of yearly payments 

o Heads of accounts from which the loan and interest repayment has 

been made 

6. Should update the States Disbursement Accounts both for repayment of loan and 

interest repayments along with the losses owing to foreign currency fluctuations 

7. Should update the Receipts account if revenues are made owing to foreign currency 

rate fluctuations and INR value has grown vis-à-vis the foreign currency 

8. Should update the loan account automatically once the repayments of loan and 

interest amounts have been made 

9. Should update the State Liabilities Account as after each repayment the liability of 

the state will reduce 

10. Should update the DMS as after each repayment the debt liability of the state will 

reduce 

11. Should link the loan repayments with the budget module, so that enough provisions 

can be made in the budget for loan repayments 

12. Should keep track of any wrong repayments made to GoI 


Attachment B 


1.3.9 Obtaining Loans / advances from GoMP and its repayments by 

Corporations 

Table 34: Functional Requirement Specifications – Loans / Advances and its repayments by 

Corporations 

Business Requirement – Loans/Advances and its repayment by Corporations 

Sr. No. 


1. Should allow the Corporation’s Head to view the available proposal / request 

formats over the system 

2. Should allow the Corporation’s Head to make entries in the required formats 

3. Should allow the Corporation’s Head to make changes in the selected format 

4. Should allow the Corporation’s Head to submit the proposal / request for loan 

advance through the system 

5. Should generate alerts for the Corporation’s head over the successful submission of 

request 

6. Should generate alerts for the Admin Unit Head (HOD) over receiving 

corporation’s request 

7. Should allow the Admin Unit Head (HOD) to accept / object / modify at his own 

end in the submitted proposals 

8. Should allow the Admin Unit Head (HOD) to submit the proposal to DoF online 

9. Should generate alerts for Admin Unit Head over the successful submission of the 

proposal 

10. Should generate alerts for DoF officials on receipt of request / proposal online 

11. Should allow the DoF officials to accept / object / modify at their own end in the 

submitted proposals, in all the cases should generate alerts for admin unit and 

corporation heads 

12. Should allow the DoF to fix the loan terms and conditions in the system by making 

the following entries: 

• Loan id 

• Date 

• Sanction no. 

• Corporation’s name 

• Department’s name 

• Loan / advance requested (should be allowed to select one option) 

• Loan account details 

• For Advances 

o Advance Requested 

o Advance sanctioned 

o Return period 


Attachment B 


o Rate of Interest (if applicable) 

o Terms and conditions ( to be entered manually) 

o Head details under which advance would be provided 

o Penalty terms and conditions 

• For Loans 

o Loan requested 

o Loan sanctioned 

o Rate of interest (for particular duration) 

o Loan Duration 

o Moratorium period ( if any GoMP wants to provide) and its terms 

and conditions 

o Loan repayment frequency (monthly, quarterly, half yearly, yearly) & 

Number of Installments 


13. Should allow the DoF to transfer the amount to particular heads of accounts 

through budgetary provisions 

14. Should update the state’s account receivable 

Loan Repayment by Corporations 

1. Should generate alerts for the corporation, admin unit and DoF before one month 

of the actual repayment date 

2. Should continuously generate alerts till repayment has been made 

3. Should display a separate loan / advance repayment section to the corporation’s – 

DDO 

4. Should allow the Corporation DDO to make the repayment electronically through 

the state receipt system 

5. Should update the state account receivable as soon as the payment has been made by 

the corporations 

6. Should generate alerts on repayment of loan / advance 

7. Should automatically update the receipts head of the state government on receipt of 

the repayment amount 

8. In case of non repayment of advances / loans by corporations should generate alerts 

for Admin Unit Head and DoF Officials 

9. Should show the corporation as defaulter history whenever any financial transaction 

related to the corporation is carried out by DoF e.g. budget preparation, additional 

loan / advance providing etc. 


Attachment B 


1.3.10 Recording of Guarantees 

Table 35: Functional Requirement Specifications - Recording of Guarantees 

Business Requirement – Recording of Guarantees 

Sr. No. 


1. Should allow the Admin Unit Representative of the Department whose 

Autonomous agency wants the Government to act as guarantor to login into the 

system as per the login component 

2. Should show the Admin Unit Representative the access guarantees module over his 

screen whenever he logs in to the system. The system should have a guarantees 

module in the application. 

3. Should show the user two options when he enters the guarantee module : 

• Recording of Loan and Guarantees 

• Updation of Guarantees 

4. Should allow the user to choose any of the options 

Recording of New Guarantees 

1. Should allow the Admin Unit user to capture the guarantee details 

2. Should allow the Admin Unit User to enter the following information related to 

guarantees: 

• Guarantee request ID (Self Generated) 

• Name of Autonomous Institution 

• Department’s Name 

• Proposal Details (PDF / Word Format) 

• Bank/FI details which has agreed to provide loan 

• Terms and Conditions of Loan 

• Loan Amount 



3. Should allow the Admin Unit user to upload the above details over the application 

before generating ID 

4. Should generate a message on both successful / unsuccessful uploading of guarantee 

details 

5. Should generate alerts (through IFMIS / e mail) for the Finance Department 

representative in charge of guarantees module 

6. Should allow the Finance Department Representative to review the guarantee details 

at his end 

7. Should allow the Finance Department Representative to edit the guarantee details 

for clerical errors only 


Attachment B 


8. Should allow the Finance Department Representative to provide his approval / 

rejection over the system itself 

9. Should allow the Finance Department Representative to add Observations / 

Remarks along with approval / rejection 

10. Should generate alerts related to DoF’s approval / rejection for the Admin Unit 

Representative who requested the Government to act as guarantor on behalf of the 

autonomous agency 

11. Should allow the Admin Unit Representative of the Department to view the Finance 

Department’s Approval / Rejection and its observations made 

12. Should allow the Admin Unit Representative to capture and upload the decision of 

the Cabinet over the system. This would be captured in the following way: 

• Guarantee request id 

• Guarantee details 

• Decision of DoF (Request Accepted / Request Rejected) 

• Decision of Cabinet (Request Accepted / Request Rejected) 


Attachment B 


1.3.11 Updation of Guarantees 

Table 36: Functional Requirement Specification - Updation of Guarantees 

Business Requirement – Updation of Guarantees 

Sr. No. 


1. Should generate auto- alerts for all concerned if stipulated schedule of interest 

payment and/or repayment of loan hired is not adhered by the autonomous 

agency. 

2. Should allow the Admin Unit Representative of the Department for whose 

Autonomous agency Government has acted as guarantor, to login into the system 

as per the login component 

3. Should show the Admin Unit Representative the guarantees module over his 

screen whenever he logs in to the system. The system should have a guarantees 

module in the application. 

4. Should show the user two options when he enters the guarantee module : 

• Recording of Loan and Guarantees 

• Updation of Guarantees 

5. Should allow the user to choose any of the options 

Updation of Guarantees 

1. Should allow the Admin Unit Representative to choose the second option – 

Updation of Guarantees 

2. Should allow the concerned Admin Unit Representative to enter the following 

repayment details in the application: 

• Guarantee request ID 

• Loan repayment amount (Principle + Interest) 

• Remaining duration 

• Outstanding amount 

• Fines & Penalties (if any) 

o Revision details in terms of loan 

o Revised interest rate 

o Revised duration 

o Revision of total outstanding 

• Time & amount of next installment 

3. Should allow the Admin Unit user to upload the above details over the application 

4. Should generate a message on both successful / unsuccessful uploading of 

guarantee details 

5. Should generate alerts for the Finance Department over the successful updation 

of guarantees related interest payment and/or loan repayment details by the 

Admin Unit Representative 


Attachment B 


6. System should update the contingent liability of the state as soon as a repayment is 

made to the financial institution 

7. System should provide utility DSS/data mining for evaluating creditworthiness of 

any agency with required past history/data available in the system 


Attachment B 


1.3.12 Government Investments 

Table 37: Functional Requirement Specifications – Government Investments 

Business Requirement – Government Investments 

Sr. No. 


1. Should allow the RBI / DoF officials to enter the details of the investments made by 

RBI in the system 

2. Should generate alerts for DoF as soon as RBI updates the details system, if it agrees 

to enter investment details in the system then 

3. Should capture the details of investments made in the case of treasury bills 

4. Should capture the following Treasury bill details in the system: 

• Face Value 

• Discount rate 

• Maturity period (14 days, 91 days, 182 days and 364 days) of treasury bills 

5. On achieving the maturity period should allow the RBI to enter the details of the 

realizations into the system and the state debt & investment system should capture 

the transactions details directly from RBI level 

6. In case RBI does not agrees to enter the details at its ends should allow the DoF 

Representative to enter the details of return on investments in the system 

7. Should affect automatic entries in the state accounts of disbursements and receipts 

on accounts of TB transactions 


Attachment B 


1.4 State Receipts Management System 

1.4.1 State Receipts System 

Table 38: Functional Requirement Specifications – State Receipts System 

Business Requirement – State Receipts System 

Sr. No. 


1. The main page of the Treasury Receipt system website should host the information 

related to Treasury Receipt system. The following information should be hosted at 

the Treasury Receipt system website: 

• Payments that can be made via Treasury Receipt system 

• Eligibility Criteria 

• Process manual for various kinds of payments 

• Fees structure 

• Grievance filing procedure 

• Authorities to contact 

• Forms and documents required 

2. The system should host a login functionality on the main page of the Treasury 

Receipt system website 

3. Should allow the user to choose the login category: 

• Individual Users 

• Organizations/Companies 

• Government Officials 

• Banks 

• Common Service Centers 

• Department Appointed Agents 

4. The system should allow only registered users to enter the application 

5. The system should provide the new individual users the facility to register 

themselves with the Treasury Receipts module of the IFMIS application. The users 

can be: 

• Service agents (CSC/Agent) 

• Individual citizens 

• Private firms and agencies 

• Government / non-government institutions 

6. Should ask the new users to provide the following details: 

• Kind of registration [individual, agent, institutional (government/non 

government)] 

For individual User Registration 


Attachment B 


• Full name of the user 

• Pan Number (optional) 

• Profession 

• Address 

• Contact number 

• Email 

For Institutional (non-government) Registration 

• Name of Firm 

• TIN/CIN no. 

• Location of firm 

• Contact person address including email & phone/mobile 

• Type of firm (to be selected from dropdown menu) 

7. The system should allow the system administrator/departmental authorized person 

to create user profile for the following 

• Banks 

• Agents 

• CSC’ 

For all these users a unique users identification number should be generated 

For Bank Branch Registration 

• Name of the Bank 

• Name of the Branch 

• Person responsible for receipts 

• Branch Address 

• Contact number of Manager and nodal officer 

• Official Email id (Manager & Nodal Officer) 

For agent Registration 

• Name of the agent 

• Registration number with the department 

• Name of the department with which agent is registered 

• Address 

• Contact number 

• Email 

8. Should throw an error message in case an incorrect user id or a password or both are 

entered into the system 

9. The system should display through dropdown menu a list of all the receipt heads in 

which paying in would be acceptable via the Treasury receipts system for different 

types of logins/user 

10. Should allow the user to select the kind of service he wants to utilize. The 

application should host an interface between the Treasury Receipt system website 

and the departments for which some database related information is required. E.g. 

the Road Tax department should host the vehicle information database and this 


Attachment B 


should be made available to the Treasury Receipt system user during the road tax 

submission. The database would return requested details on supplying particular 

information. E.g. when the user provides the registration number of a vehicle for 

which the road tax has to be paid the database would return the vehicle details, 

owner details, tax details and other details which would act as an input for the 

Treasury Receipt system payments e-Form. 

11. Should generate an e-Form (some of its fields would be self filled based on the 

selections made by the user via the department’s database) on the selection of a 

particular service/head for which he wants to make the payment. The e Form 

should contain the following information: 

• Receipt Head details – fees head , tax head (to be selected from dropdown 

menu) (auto displayed for departmental agents on login) 

• Name of service (self filled by the application) 

• Name of Department (self filled by the application) 

• Department code (self filled by the application) 

• Registration id (self filled by the application) 

• User details (self filled by the application) 

• Fresh payment / Arrear (option based) 

• Duration for which the payment has to be made (the user will have to select 

the dates from the calendar provided in the application) 

• Payment details (tax amount, service charge, penalty / late fees, total 

amount) 

• Mode of payment (to be selected by the user) 

12. Should allow the user to select the mode of payment in the e-Form. Should provide 

the following options to the user for making the Treasury Receipt system payments: 

• Credit cards (via payment gateway) 

• Debit cards (via payment gateway) 

• Direct Debit Facility (ECS)/Net Banking 

• Pre paid cards 

13. Should generate a unique transaction ID for each Treasury Receipt system 

transaction 

14. The System should generate a Unique Application Number and should be able to 

identify the applicant based on this Number 

15. Should be able to generate an e – Challan for the payee with the following details: 

• Transaction ID * 

• Department Code / Name * 

• Head of Account[Major- Minor]* 

• District/Tax Circle* 

• Assessment Year 

• Purpose/Subhead* 

• Depositor/ Dealer/company Name* 

• TAN/CIN 

• Depositor E - Mail Id 


Attachment B 


• Depositor’s mobile no. 

• Depositor’s address 

Fields marked * are mandatory 

16. System should provide utility to view/print and send the self generated e-challan 

copy to the payee via email also 

17. Every Institutional Login should have its own mail box which should be used 

official communication apart from the e-mail id 

18. Should provide an interface to accept the e –scroll generated by various banks on a 

daily basis by the system/designated bank (currently there is only one agency bank 

for the Treasury Receipt system operations). The system should be able to convert 

the e-scroll data format to Treasury Receipt system database structure. 

19. Should be able to reconcile all the payments for a particular head against the e scroll 

received from the banks 

20. Should be able to update the centralized IFMIS application once the data has been 

reconciled 

21. Should allow the Circle Tax Officers of a particular department to login to the 

application and check the periodic status of transactions and generate Consolidated 

Treasury Receipt (CTR) for defined period. 

22. Should be able to reconcile the transactions that have not featured in the current 

day’s e-scroll in the next working day’s reconciliation process through a plus-minus 

memo system 

23. Should consider the transactions that have not featured in the previous day’s e-scroll 

on priority basis for the current day’s reconciliation process through a plus-minus 

memo system 

24. Should generate alerts for the transactions that have not featured in any of the e 

scrolls [over defined period tentatively( next 5 day’s)scrolls] 

Treasury Disbursement System: In the integrated financial management system based on 

accrual based accounting, by transfer entries also need to be factored in for preparation of state 

accounts. This means that the by transfer entries under various heads will be treated as receipts 

under respective heads. This should be done through GL 

25. The system should include the by transfer entries from treasury disbursement system 

for creating consolidated state account 

26. Out of Treasury Transactions: A set of transactions would be carried out of the of 

treasury system. These transactions will continue as earlier is but they should be 

captured in the integrated system. Out of treasury transactions correspond to all the 

transactions which are routed through RBI/AGMP. These transactions can be of 

the following nature 

• Inter AG transactions 

• Transactions with RBI (grants, central share and loans as also market 

borrowings) 

• Transactions with central ministry or GoI for devolution of central taxes 

27. An interface for the treasury disbursement should be provided with AGMP for the 

recording of out of treasury transactions 


Attachment B 


28. Different logins should be created for AGMP for recording of transactions related 

to 

• Inter AG transactions 

• Loans & Market borrowings details 

• Details of transactions with GoI (related central ministries) 

29. The system should a web based GUI for AGMP 

30. The interface should be the same as for other stakeholders with format specific to 

AGMP with needed access rights 


Attachment B 


1.5 Treasury Disbursement System 

1.5.1 Treasury Disbursement System 

Table 39: Functional Requirement Specifications – Treasury Disbursement System 

Business Requirement – Treasury Disbursement System 

Sr. No. 


1. The treasury disbursement system should be linked with the office accounting 

system 

2. The treasury disbursement system should be interfaced with the HRMIS and 

Pension module 

3. Should incorporate with the budget management the system 

4. Should incorporate ways and means management system for bill clearing 

5. The System should generate a Unique Bill Number and should be able to identify 

the bill based on this Number 

Claim Raising 

1. Should allow the bill clerk to access claims section 

2. Should allow the bill clerk to register all the received claims through a new claim 

option. 

3. Should generate a claim id as soon as a new bill is admitted by the bill clerk in the 

Office Accounting System. Should allow the bill clerk to enter the following fields: 


• Claim date 

• Applicant’s name 

• Employee Number (If applicant is an employee) 

• Reference Number (If any) 

• Applicant’s bank account details 

4. Should allow the bill clerk to either accept or reject the claim after manual checking 

in the Office Accounting System. The bill clerk will check that proper sanctions and 

authority letters are attached 

5. Should allow the bill clerk to run a system check over the submitted bill, the system 

checks would be done for: 

• Budget Availability 

• Sanction availability 

• Follows book of financial powers 

6. In case the bill clerk finds a defect in the bill manually, he should be allowed to reject 

the bill by clicking on the reject option. On choosing the reject option he should be 

provided the following fields in the Office Accounting System: 



Attachment B 



• Rejection Date 

• DDO Code 

• Rejection Code 

• Reason for rejection (description) 

7. Should allow the bill clerk to print a rejection slip for the claimant 

8. Should also allow the bill clerk to accept the bills, the following fields would be filled 

by the bill clerk in case of acceptance: 


• DDO Code 

• DDO Designation 

• New / Resubmitted 

• Bill Date 

• Bill Type (Drop Down Menu) 

• Head Details (To be system generated based on the bill type) 

• Budget Flag (Budgeted/Non Budgeted) 

• Gross Amount 

• Net Amount 

• Payee Department 

• Balance Budget for the DDO, HOA and, Demand Number 

• Comments made by bill clerk 

9. Should allow the bills clerk to generate a requisition for the DDO for bill clearing 

10. Should generate alerts for the DDO on the submission of bill by the bill clerk 

DDO’s Account Creation & Management 

1. Should capture DDOs accounts information from SFMS Data 

2. Should allow new DDO’s account to be created after sanction by GOMP/AG 

3. Should allow creation of temporary DDO accounts for disbursement purpose for a 

given period also 

4. Should create secured log in system for each authorized DDO 

5. Should allow DDOs to customize their accounting (DE/SE - Office/Works/ 

Forest) system 

6. Should provide monitoring mechanism and tools to BCO and other higher 

authorities to monitor DDO’s functioning/accounts 

7. Should provide the facility of login audit trail, the audit trail will help to track the 

details of each transaction vis-à-vis the entered login 

Claim Raising 

1. Should generate alerts for the DDO on the submission of bill by the bill clerk 

2. Should generate an alert for the DDO if the bill clerk does not submits the bill as 


Attachment B 


per the fixed SLA 

3. The system should follow an auto escalation matrix 

Drawing and Disbursement Function 

1. Should allow the DDO to import the accepted bills from OAS to TDS 

2. Should process the net payments through the Ways and Management module. The 

ways and means management would clear the payment as per the defined rules. 

3. Should allow the system to electronically transfer the amount to claimant’s bank 

account 

4. Should link the State’s Disbursement System with the Agency Bank’s system 

through a payment gateway 

5. Should build an electronic reconciliation system that would capture the e scroll 

coming in from the banks and match it with the disbursements cleared 

6. Should acknowledge disbursement to DDO after receipt of e scroll from agency 

bank 

7. The banks will send a consolidated e scroll the system should be capable enough to 

process the scroll and generate DDO wise e scrolls 

8. Allow to Affect Required Entries (gross, by transfer payment and net) in General 

Ledger after release of Payments by Agency Bank 

Ways and Means Management and Cash Flow System 

1. Should allow the Department of Finance to prioritize claim types from time to time 

2. DoF to prioritize the claims on the basis of: 

• Claim Type (Salary, Wages, Pension, Purchases, Works, etc) 

• Claim amount (above one/two/five/ten cores or any other amount criteria) 

3. Should allow the clearing of bill payments through ECS and other e- payments 

options. The clearing would be based on: 

• To be Paid without specific clearance (Salary, wages, pension, below defined 

amount) 

• To be in Queued in for Specific Clearance based on amount (Above 

one/two /five/ ten/…..cores ) and bill type 

4. Should also allow the DoF to set Clearance Priority from amongst queued in bills & 

clear for e-Payment by Wait list/Type/Amount/Individual Claim 

5. Should allow Bill Clearance Priority to be Built-in along with manual Clearance from 

Queued in Bills in the Cash-Flow Mgt. System 

6. Allows all cleared claims to be e-Paid to stipulated accounts & generate Payment 

details 

7. Should have an in built Decision Support System supporting and providing 

following: 

• Information on expected amount of Committed Claims (Salary, Wages,, 

• Pension) through trend analysis of past experience 

• Information on likely revenue realization through trend analysis (past 

months/same month over past years) 

• Based on the above should be able to provide projected cash / resource 

requirements, this will also enable to redefine Clearance Priority 

• Should enable analysis of Cash- Flow Management Actions for feedback to 


Attachment B 


Decision Support System 

8. Should affect RBD accounts for all cash transactions 

Out of Treasury Disbursements 

1. Should integrate the State Disbursement System with the following systems through 

General Ledger (GL): 

• Debt Management System all the repayment modules of 

o Repayment of market borrowings & interests 

o Repayment of loans taken from Financial Institutions & interests 

o Repayment of central government loans & interests 

• Accountant General Madhya Pradesh System for capturing the details of the 

following: 

o Inter AG transactions / inter-circle adjustments 

o Other transactions that involve state disbursements 

2. Should provide a consolidated out of treasury disbursement figure in GL for the 

system 

Account Consolidation 

1. Should consolidate disbursement figures for both the treasury and out of treasury 

disbursements in GL 

2. Should compile a consolidated state’s disbursement account in GL and sent it 

electronically to AGMP 

3. Should be able to provide a consolidated statement in GL showcasing the state 

disbursement and state receipt system for DoF/AGMP 


Attachment B 


1.5.2 Financial Sanctions 

Table 40: Functional Requirement Specifications – Electronic Financial Sanctions 

Business Requirement – Electronic Financial Sanctions 

Sr. No. 


1. Should allow creating book of delegation of financial powers over the system. The 

book of financial powers would contain rules/information regarding the designation 

of approving authority the limit up to which he can sanction. 

2. Should allow to create sanctioning authorities and define levels as per the book of 

financial powers 

3. Should allow the relevant users to view their financial powers 

4. Should also allow the relevant stakeholders to view the sanctioning powers of 

various other stakeholders 

5. Should generate a unique ID each time a sanction request is generated and this ID 

would remain the same for all the sanction related items 

6. Should allow the HOO to clear the bills if it is in their financial powers through the 

treasury disbursement module and enface his approval along with the bill. The 

sanctioning authority should enface the following details while providing the 

financial sanctions: 

• Requested amount for sanction 

• Head or account of expenditure or budget from the drop down menu 

• Amount sanctioned in figures and amount 

• Subject of Sanction (Type from dropdown) 

• Type reference if any 

• Text of Sanctions (Text Box) 

• Sanction Order No 

• Sanction approval date 

• Sanctions ID 

7. Should generate a unique sanction ID each time a sanction is generated and this id 

would remain the same for all the sanction related items 

8. Should allow the relevant stakeholders to forward the proposal for sanction to 

higher authorities if the claim limit is not under own financial powers. Should 

provide a drop down facility in whose name the current stakeholder is forwarding 

the request. 

9. Should intimate the related lower level stakeholders forwarding proposal for 

sanction if the higher level stakeholders have approved the proposal for sanction 

10. Should allow the DoF to make changes in the Book of Financial Powers from time 

to time 

11. Should generate alerts for higher authorities as soon as a lower authority has 

uploaded a proposal for sanction for financial sanction 


Attachment B 


12. Should only allow relevant stake holders to use the sanction for disbursement 

13. Should allow relevant stake holders to use the sanctioned amount in parts for 

disbursement as per the budget availability or other related factors 

14. Should attach link to sanction with created bill 

15. Should enable HR Related Sanctions to Enface Name/s & Unique ID of 

Employee/s from Dropdown menu or proposal for sanction 

16. Should enable Sanctions to Enface Name/s & Unique ID of others from proposal 

for sanction ( as in case of grant in aid to institutions 

17. Should enable view or compilation of report of unused/used/partially used/lapsed 

sanctions 


Attachment B 


1.6 Deposits 

1.6.1 Sanction and Account Creation for Deposits 

Table 41: Functional Requirement Specification – Sanction and Account creation for Deposits 

Business Requirement – Sanction and Account Creation for Deposits 

Sr. No. 


1. Should provide relevant rules in the system 

2. Should provide related approval workflow 

3. System should allow Operator/HOOs/HODs to raise a request for creation of 

a deposit account 

4. System should display a form for creation of the request for deposit account 

5. System should provide a drop down to the stakeholder for selecting the type of 

deposit account i.e. Personal, Education, Court, Revenue etc. 

6. System should allow HOOs//HODs to capture the following details for raising 

a request 

• HOO code 


• Purpose 

• PD/ED operator Code 

• PD/ED Source 

o Consolidated Fund Account 

o Others 

• Operator Name 

• Scheme ID 

• Scheme Description 

7. System should allow submission of the request for deposit account creation 

8. System should send a notification to the Admin Dept. on submission of the 

request by the HOO 

9. System should allow head of Admin Dept. to submit the request to the 

Department of Finance after appropriate scrutiny 

10. System should allow the Department of Finance to mark its approval on the 

request submitted 

11. System should notify the Admin Dept after receiving the approval/rejection 

from Finance Department 

12. System should allow the Admin Dept. to forward the approval received from 

DoF to AG 

13. System should provide an interface to the AG to provide the concurrence for 

account creation request and updating its systems 


Attachment B 


14. System should notify Admin Dept /HOOs/ Operator after the approval is 

received from AG 


Attachment B 


1.6.2 Fund Transfer to PD/ED Account 

Table 42: Functional Requirement Specification – Fund transfer to PD/ED account 

Business Requirement – Fund transfer to PD/ED account 

Sr. No. 


Fund Transfer to PD/ED accounts 

1. Should allow the PD / ED operator to view scheme wise balances for various 

schemes running under the PD / ED operator 

2. Should allow capturing the opening balance of multiple operators against 

multiple schemes in the system. 

3. Should allow PD/ED operators to raise a request in the system for fund transfer 

to PD/ED account 

4. Should allow the PD / ED operator to enter the following details over the 

system with respect to the request: 

• Request Date (System generated) 

• Operator Code (Self Generated) 

• Scheme Code (Drop Down by ED / PD operator) 

• Opening Balance (to be entered by ED / PD Operator) 

• Amount requested 

• Purpose of request 

5. Should allow the DDOs to transfer funds from the scheme/grant to the 

PD/ED account by Transfer Credit (BT) 

Fund Transfer to agency accounts 

1. Should generate a scheme wise details of opening balance for various schemes 

under the various Public and Education Deposits (PD/ED) 

2. Should allow the PD / ED operator to enter the details of the grant/advances 

needs to be transferred to agency accounts 

3. Should allow the PD / ED operator to check the scheme wise balance of the 

PD / ED accounts 

4. Should allow the PD / ED operator to create a request in the system for the 

sanction to be accorded to the concerned agency 

5. Should allow PD/ED operators to enter the expenditure details in the system 

for the expenditure incurred by the concerned agency 

6. Should allow PD/ED operators to submit the request through the system 

7. Should send a notification to the DDOs when the sanction is accorded by the 

competent authority 

8. Should allow DDOs to process the payments through the Treasury 

Disbursement system by transfer credit to the PD/ED operators’ account 

9. Should capture the following details related to the PD / ED accounts payments: 

• Date 

• Operator Details 

o Operator Code 


Attachment B 


o Operator name 

• Payment Details 

o Mode of Pay (by transfer credit) 

o Amount 

o Transaction id 

o Payee Name 

• Scheme Code 

• Scheme Description 

10. Should generate and capture the advice of payment for all the Education and 

Personal deposits 

11. A unique Advice ID will be generated by the system after successful credit of 

account 

12. Should capture the following field related to the advice of payments: 

• Advice Date 

• Advice Number 

• Operator Code 

• Scheme Code 

• Payment transaction id 

• Payment Date 

• Payee Name 

• Amount 

13. Should deduct the scheme wise balances as soon as any payments are made from 

the scheme balance 

14. Should provide related rules in the system 


Attachment B 


1.6.3 Revenue Deposits 

Table 43: Functional Requirement Specification – Revenue Deposits 

Business Requirement – Revenue Deposits 

Sr. No. 



2. System should allow the treasury to create a new account for a each revenue 

deposit received/credited through the cyber treasury 

3. Should allow DDOs to capture details for payments done by payees through the 

cyber treasury module 

4. Should allow DDOs to realize the moneys submitted through of the demand 

drafts by the payees. 

5. Should allow the HOO/DDOs to enter the selected bidder details against the 

payment details 

6. Should allow refund on the sanction of competent authority when 

bidding/procurement process is complete 

7. Should provide link to original deposit for verification of refund bill and 

discharge of original deposit amount after refund 

8. Should allow refund of the bid amount for bidders not selected through the 

refund module 

9. Should allow release of payments and credit back to the depositor account when 

bidding/procurement process is complete 


Attachment B 


1.6.4 Civil Court Deposits 

Table 44: Functional Requirement Specification – Court Deposits 

Business Requirement – Court Deposits 

Sr. No. 



2. Should allow the court DDO to select the option of the kind of deposit: 

• Civil Court Deposit 

• Criminal Court Deposit 

3. Should not allow the courts to receive / disburse amounts more than defined 

limit through cash mode. 

4. Should allow the court DDO to enter the following details pertaining to court 

deposits transactions: 

• Date (system generated) 

• Court Name (system generated) 

• DDO Code (system generated) 

• DDO Designation (system generated) 

• Type of Court Deposit (from drop down menu) 

o Civil Court Deposit 

o Criminal Court Deposit 

• Head of Accounts (from drop down menu) 

• Transaction Date (system generated) 

• Total cash inflow (receipts) (ported from courts records) 

• Total cash outflow (disbursements) (ported from courts records) 

• Balance Amount (Calculated Field) (ported from courts records) 

• Total receipts received through cyber treasury module (ported from 

courts records) 

• Total disbursements made through the state disbursement system 

(ported from courts records) 

• Total balance at the end of day (ported from courts records) 

5. Should provide the court DDO calculator functionality in the system to enter 

the various individual received and disbursed cash amounts. Also the system 

should generate a consolidated daily collections, disbursements and balance 

figure for cash transactions 

6. Should calculate the total cash balance based on OB, the total cash inflow and 

total cash outflow 

7. Should generate a daily transaction wise details for collections/disbursements 

made through cyber treasury and state disbursement modules respectively 

8. Should display the following information in case of receipts collected through 

cyber treasury module of state receipts system: 



Attachment B 


• Amount 

9. Should allow the DDO to enter the transaction id for cyber treasury and state 

disbursement transactions into the system 

10. Should import the total inflow received through receipts received from cyber 

treasury module for court deposits 

11. Should import the total outflows disbursed through the treasury disbursement 

module of court deposits 

12. Should provide a daily court deposits balance based on the total receipts and 

total disbursements. The total receipts would constitute of total cash receipts in 

the day and the total deposits received through cyber treasury module. Whereas, 

the total disbursements would be formed from the total cash disbursements 

through the court and total refunds made through treasury disbursement system. 

13. Should display the following details related to receipts received through cyber 

treasury module of state receipt systems for court deposits to the court DDO: 

• Transaction id 

• Transaction date 

• DDO Code 

• HOA details 

• Type of Deposit 

o Civil Court 

o Criminal Court 

• Purpose of deposit 

o Penalty 

o Fine 

o Deposit 

o Others 

• Reference of order/judgment 

• Link Bank’s name 

• Branch details 

• Bank’s code 

• Amount details 

• Name of Depositor 

14. Should allow the court DDO to make the disbursements for refunds of court 

deposits through the treasury disbursement system’s refund of deposit. The 

system should allow the Court DDO to make the required entries in the online 

bill of refund of deposit: 

• Type of Deposit (dropdown menu) 

o Civil Court 

o Criminal Court 

• Refund type (dropdown menu) 

• Particulars of refund order 

• Refund amount 


Attachment B 


• HOA details (system generated) 


Attachment B 


1.6.5 Local Fund Deposits 

Business Requirement – Local Fund Deposit 

Sr. No. 


1. Should generate a new deposit account id for each new Local Fund Deposit 

Account created 

2. Should allow only particular kind of bodies to open Local Fund Deposit 

Account, currently the bodies that are allowed to open Local Fund Deposit 

Account are: 

• Janapada Fund 

• Municipal Funds 

• Dispensary Funds 

• Museum Funds 

• Cotton 

• Grain Market Funds 

• Town Funds 

3. Should capture the following details regarded to account opening: 

• Name of the body 

• Unique id assigned to the issued body 

• Account number for the local fund deposit 

• Amount submitted by body initially while account opening 

• Interest rate as defined by DoF 

4. Should allow the DoF officials to define an interest rate that needs to be paid on 

the local fund deposit in the system itself 

5. Should make all deposits in the State Public Account as a deposit and not in the 

Consolidated Account as a revenue 

6. Should link the State Receipt System to the Local Fund Deposit Account so that 

the amount deposited in the Local Fund Deposit can be accepted via the State 

Receipt System 

7. Should link the Local Fund Deposit Account with the State Disbursement 

System so that the Bodies can raise their disbursement bills over the IFMIS itself 

8. Should credit interest amount in the particular body’s account automatically as 

per conditions defined by DoF in the system 

9. Should allow the Body to make disbursements from the Local Fund Deposit 

Account using the State Disbursement System 

10. Should link the State Disbursement & Receipt System with State Deposits 

System and in turn with the Local Fund Deposit Account 


Attachment B 


1.6.6 Lapsed Deposits 

Table 45: Functional Requirement Specification – Lapsed Deposits 

Business Requirement – Lapsed Deposits 

Sr. No. 



2. Should monitor deposit accounts at the end of every financial year for certain 

deposits namely K- /Revenue deposit /etc not claimed within a certain period of 

time (generally on March 31 of an year after 3 years of deposit) 

3. Should transfer the amount for certain deposits namely K-deposit/ Revenue 

after defined validity period to lapsed to concerned government revenue receipt 

head 

4. Should maintain the following fields in case of lapsed deposits: 

• Deposit Type (Revenue/K/etc) 

• Lapse ID (System Generated) 

• Source 

o Consolidated Fund Account 

o Others 

• Source (Centre / State) 

• Scheme name 

• Scheme id 

• Lapsed Date 

• Lapsed Transaction Number (System Generated) 

• Lapsed Amount 

• Remarks 

• By whom originally tendered 

• HOO/DDO 

• Total Lapsed amount 

5. Should generate ID and alerts for the concerned HOO/DDO by the system 

over the lapsed deposits 

6. Should generate regular alerts from 1 st March onwards for the lapse of sanctions 

for deposits from Consolidated Fund Account 

7. Should lapse the account if a revalidation or revised sanction is not received by 

31 st March of the Financial Year for deposits from consolidated fund account 

8. Should generate a HOO/DDO wise list of lapsed deposits and credits to state 

receipt head 

9. Should allow concerned HOO/DDO to raise bill for payment of lapsed deposit 

from concerned revenue head 

10. Should generate a statement providing details of the lapsed deposit and the E- 

statement should be forwarded to all the interested parties i.e. the DoF, AG – 


Attachment B 


MP 

11. In case of money that had come from Centre and had been kept as a deposit in 

the state public account for those deposits in case of deposits lapsing the system 

generate alerts for the resubmission of deposit account for DoF. 

12. Should allow DoF the lapsed deposit has to be resubmitted to GoI then DoF 

should be allowed to make disbursement from the State Public Account through 

the State Disbursement System 


Attachment B 


1.6.7 Refund of Lapsed Deposits 

Table 46: Functional Requirement Specification – Refund of Lapsed Deposits 

Business Requirement – Refund of Lapsed Deposits 

Sr. No. 



2. System should allow claimants to raise requests online in the system 

3. System should allow claimants to fill a form which will have the deposit ID from 

which the amount was lapsed, the claimant should fill the following fields: 

• Deposit id 

• Deposit type 

• BCO Code 

• DDO code (if any) 


• Deposit period (Start Date …… to End Date……) 

• Account number 

• Reason for not claiming the amount in due time 

4. System should allow the claimants to submit the request for refund 

5. Should link the refund of lapsed deposit module with budget module to include 

a provision for refunding the lapsed deposit amount that had come from the 

centre 

6. System should notify (generate alert for) the competent authority regarding the 

submission of the request 

7. System should allow competent authority to drill down into the details of the 

lapsed deposit 

8. System should provide an option to the competent authority to provide the 

approval/rejection on the request 

9. Should allow the Competent Authority to provide sanction for the refund of 

lapsed deposit through the system 

10. Should capture the sanction details over the system, the following details needs 

to be captured for the provided sanctions: 

• Lapsed deposit details, amount id number and date of transfer credit to 

revenue head 


• Sanction Number 

• Sanction Date 

• Sanction Authority 

11. System should trigger a notification to AG/Competent Authority for seeking 

confirmation on the refund request 


Attachment B 


12. System should allow AG/Competent Authority to provide approval/rejection 

on the refund request 

13. System should send a notification to HOO/DDO regarding approval/rejection 

of the request 

14. System should allow HOO/DDO to upload the bill to the disbursement module 

for the payment of sanctioned amount to the claimants account 


Attachment B 


1.6.8 Refund of Excess Revenue Receipts & Recoveries 

Table 47: Functional Requirement Specification – Refund of Excess Revenue Receipts and recoveries 

Business Requirement – Refund of Excess Revenue Receipts and recoveries 

Sr. No. 



2. Should provide option to select the refund type from the following options: 

• Revenue Refund 

• Refund of excess recovery/deposit of Commercial/other Taxes 

• Refund of excess recoveries 

3. Should allow the Competent Authority to verify original receipt/credit 

4. Should allow the Competent Authority to provide online sanction for the refund 

of deposit 

5. Should capture the sanction details over the system, the following details needs 

to be captured for the provided sanctions: 




• HOA 

• Original credit/receipt 

6. Should capture the following details for refund bill: 




• HOA for expenditure (deduct receipt head) 

7. Should capture the following details for Commercial/other Tax Refunds: 




• Tax Refund Payment Order Number 

• Issue date of Payment Order 

• Name of Depositor 

• Amount to be Refunded 

8. Should provide an interface with the Office Accounting System for bill raising 

9. Should provide an interface with Treasury Disbursement System for bill clearing 


Attachment B 


1.6.9 K-Deposit 

Table 48: Functional Requirement Specification – K-Deposit 

Business Requirement – K-Deposit 

Sr. No. 


1. System should allow HOO/HODs to access the financial sanction system work 

flow to raise a request for sanction/transfer of funds to K-Deposit and 

withdrawal of funds from K-Deposit 

2. System should allow HOO/HODs to choose from the option of depositing 

funds or withdrawal from K-Deposit 

3. System should allow HOO/HODs to enter the following details in the form 

• Budget Head for transfer to K-Deposit 

• Deposit ID for withdrawal from K-Deposit 

• Amount 

4. System should allow HOO/HODs to submit the request online 

5. System should generate alerts when any proposal/sanction is received at 

different levels 

6. System should allow Head of administrative department to review the request 

and provide comments/seek clarification 

7. System should allow Head of Administrative Department to provide an 

approval/rejection on the request 

8. System should allow Head of Administrative Department to submit the request 

to Department of Finance 

9. System should allow Department of Finance to access financial sanction module 

to issue a sanction for depositing or withdrawal of funds to/from K-Deposit 

10. System should allow issuing separate sanctions for a deposit and withdrawal 

request 

11. System should allow linking withdrawal sanction ID to the deposit sanction ID 

12. System should send a notification to AGMP/Head of Administrative 

Department when the sanction is issued 

13. System should send the sanction ID, amount and budget head for the sanction 

or Deposit ID for withdrawal 

14. System should allow Head of Administrative Department to communicate the 

sanction details to HOO/HODs 

15. System should allow DDOs to raise a bill in the system against the sanction ID 

for deposit or withdrawal 

16. System should allow transfer of funds through treasury disbursement system to 

K-Deposit or from K-Deposit 

17. System should transfer the K-Deposit amount to revenue deposit head by a 

transfer entry if the K-Deposit amount is not claimed for refund from 3 years of 

deposit date 


Attachment B 


18. System should lapse the K-Deposit amount if it is not claimed for refund for 

another 3 years from revenue deposit account 

19. System should allow withdrawal from K-Deposit in parts. 

20. System should nullify the sanction for withdrawal from K-Deposit if the amount 

is not withdrawn with 3 months of issuing sanction 


Attachment B 


1.7 Internal & Statutory Audit 

Table 49: Functional Requirement Specification – Auditing including Internal Audit 

Business Requirement – Auditing 

Sr. No. 


1. Should provide Electronic Audit Management System (a system that 

electronically processes most audit work, including selection of auditees, 

establishment and coordination of audit plans, management of audit data and 

processing of audit results, etc). 

2. Should provide/customize the e-Audit Portal System. (an integrated system that 

provides an integrated environment where, with a single sign on, one can have 

access not only to the information customized to one’s own needs but to 

different systems within the e-Audit System, including the Electronic Audit 

Management System, Data Collection and Analysis System, Audit Knowledge 

Management System and Electronic Approval System) 

3. Should provide Government Audit Integration System (system that connects the 

audit supporting programs of internal audit organizations (CTA/Depts.) through 

the network, thereby realizing coordination of audit plans, sharing of audit 

information and electronic interchange of audit documents) 

4. Should provide the Field Audit Management System (a system that supports the 

formation of networks among team members in the sites of field work and 

provides generalized audit software to enable users at field work to re-analyze, 

for their specific purposes, the data which has been processed by the data 

collection and analysis system of the main system) 

5. Should provide required Computer Assisted Audit Techniques System (CAATS), 

a standard financial accounting software, modified as required, for audit systems 

having the capability to analyze data and can be used to recalculate certain items 

e.g. depreciation charge for the non-current assets, interest on the bank 

overdraft, etc. 

6. Should provide Embedded Audit Facilities which allows test to be made at the 

time the data is being processed for a real time auditing. 

7. Should allow the auditing results to be printed out immediately or copied to 

secondary storage and later evaluated by the auditor 

8. Should store information as it is processed for subsequent audit review. 

9. Should check the integrity of files which have been processed 

10. Should stop and record items which are of special audit interests as previously 

designed by the auditor 

11. Should provide for tagging transactions with an indication e.g. a different color 

when they enter into the system. Should provide the auditor with print out of 

the details of the steps in processing tagged transactions. 

12. Should allow use of valid data is used to check that the system/software 

processes the data accurately. 


Attachment B 


13. Should allow use of invalid data is used to check the system/software, gives 

either a warning or rejects the data 

14. Should be designed at the output stage so as to handle the audit test data without 

unwanted side effects 

15. Should allow as part of a normal run and auditors to apply to “dummy” test held 

on master files and avoiding eventuality of test data being subject to special 

procedures which are not applied to normal transactions. 

16. Provide utility to carry out regular testing of the system (to test application 

control) without using a special test run and indeed without being present during 

processing. 

17. Should provide utility for development of e-audit work programme 

18. Should accept electronic records from the bookkeeping and financial accounting 

system of IHR &GFMIS 

19. Should allow selection of any statistically valid sample of transactions on which 

to conduct audit test 

20. Should Integrate CAATS into the IFMIS 

21. Should provide full documentation and recording of all systems and 

applications; procedures for normal approval and acceptance of all new and 

changed applications 

22. Should provide an audit trail consistent with Generally Accepted Accounting 

Principles (GAAP) including those for automatically generated material 

transactions e.g. direct debits; complex calculations without demonstrating how 

it has been done e.g. interest charged to customers for overdue debts; EDI 

with other organizations e.g. AGMP/Banks; 

23. Should provide for the audit trial to consist of computer print outs, documents 

stored in machine readable form, etc 

24. Should provide for the portion of the audit trial such as the date and the time of 

the last change in a record and the person making the change stored as part of 

the on-line records 

25. Should be able to allow data to be retained so it can be used in other areas of the 

audit including error identification and segregation of transactions within 

accounts, once its verified using computer a technique, 

26. Should allow design and performance of substantive and compliance tests 

27. Should allow customized reports to be generated by the system and a standard 

audit trail is maintained. 

28. Should allow analyzing data and generating specific reports using a standard 

program (data analysis is focused and allows for any future adjustment to be 

made with minimal effort). 

29. Should allow preliminary data to be analyzed early in the audit process and so 

that a more efficient audit plan can be devised earlier in audit programme. 

30. Should enable facility for search, compare, compute, analyze, etc through e-audit 

and/or DSS utility 


Attachment B 


1.8 Strong Room Operations 

1.8.1 Government Stationary Procurement 

Table 50: Functional Requirement Specifications - Government Stationary Procurement 

Business Requirement – Government Stationary Procurement 

Sr. No. 

Requirement Description – Stamps 

1. Should show Office in Charge at the officer in charge of Sub treasury / Treasury 

Officer at District Treasury of the current stamps inventory 

2. Should generate auto alerts for the officer in charge whenever the inventory reaches 

a threshold level 

3. Should allow the officer in charge of Sub treasury / Treasury Officer at District 

Treasury to raise an indent for stamps procurement at the system. The Officer in 

charge would raise the request in the following format: 

• Name of treasury (auto generated): 

• Treasury code(auto generated): 

• Stamps Type 

• Current stock status of the item : 

• Indent Source 

o Govt. Press 

o Others 

• Indent ID (System Generated) 

• Indent Date 

• Stamp Details 

o Stamp Category 

o Stamp Denomination 

o No of Sheets 

o No of Label 

• Total Quantity (In Label) 

• Total Value Of Stamp 

• Remarks 

4. Should receive an acknowledgement as soon as he submits his application over the 

system, the acknowledgement should contain the following fields: 

• Transaction id (auto generated): 



• Date (auto generated) 

• Current stationary stock status: 

• Number of stamps requested: 

• Remarks: 


Attachment B 


5. Should import the indent information to invoice recording page 

6. Should allow the STO / DTO to select the invoice recording page on receiving the 

delivery of materials 


Treasury to capture the invoice details whenever he receives the delivery of 

stationary. The format for capturing the delivery details would be as follows: 

• Invoice Number 

• Invoice Date 

• Indent Reference 

o Indent Source (Govt. Press/ District Treasury/ Sub –Treasury) 

o Treasury Code (If Indent Source is District Treasury) 

o Sub – Treasury Code (If Indent Source is Sub – Treasury) 

o Indent ID 

o Indent Date 

• Mode of Transport (Train/By Post/Road/Others) 

• Bilty Reference (If Mode of Transit is Train) 

o Bilty Number 

• Number of Parcels 

• Type of stamps 

• Number of particular stationary received: 

• Series of stationary received (From S. No. …….. To S. No. ….) 

• Current Stock Status (should be auto calculated as soon as the DTO enters 

the number of stamps received): 

• Value of stamps (only for stamps): 

• Remarks / Certificate (To be filled in by STO that ….. number of stamps 

was received in proper condition and ……. Number of stamps were 

received in damaged state) 

8. Should allow the DTO to fix the inventory levels at the district and sub treasuries 

(……% of overall stock capacity – this would be based on the past 3 years trends of 

consumption, Lead supply time for arranging stationary) 

9. Should allow the District Treasury Officer to view the requests raised by the Officer 

in Charge at the sub treasury under his jurisdiction 

10. Should allow DTO to consolidate his treasury’s stationary requests with the stamps 

requests of sub treasuries falling under his jurisdiction 

11. Should allow DTO to update consolidated stamps request for the entire district that 

would consist of stamp requests for all the sub treasuries, district treasury and city 

treasury over the application 

12. Should generate a deposit id as soon as the DTO submits the stamps request over 

the application 

13. Should generate alerts for the treasury / sub treasuries as soon as the DTO updates 

his system that the stamps have been received at his end 


Attachment B 


14. Should allow the DTO to re allocate the stamps to sub treasuries and other 

treasuries, the following fields should be available to the DTO during the stamps 

allocation: 


• Name & Code of treasury / sub treasury to which the stamps have been 

allocated (should be a drop down option): 

• Number of stationary requested by the treasury (auto generated) 

• Number of stationary allocated to particular treasury / sub treasury: 

Sr. No. 

Requirement Description – Cheque Book & Token Book 

1. Should show Office in Charge at the Sub treasury / Treasury Officer at District 

Treasury status of the current Cheque Book / Token Book inventory 




Treasury to raise an indent for issuance of Cheque Book / Token book at the 

system. The Officer in charge would raise the request in the following format: 



• Current stock status: 

• Indent Source 

o Govt. Authority 

o Others 

• Indent ID (System Generated) 

• Indent Date 

• Memo Number 

• Memo Date 

• Option of Choice (Cheque/Token) 

• Cheque 

o Types of Cheques 

o Token 

• Quantity 

• Remarks 

4. Should generate alert on successful creation and submission of indent information 



• Indent id (auto generated): 




• Current stock status: 

• Stock requested: 


Attachment B 


• Remarks: 

6. Should import the indent information to invoice submission page 

7. Should allow the STO / DTO to select the invoice submission page on receiving the 

delivery of materials 


Attachment B 


1.8.2 Material Storage under Strong Room 

Table 51: Functional Requirement Specifications - Material Storage under Strong Room 

Business Requirement – Material Storage under Strong Room 

Sr. No. 


1. Should provide Treasury Officer an option to select what he wants to store, the TO 

/ STO can submit the following material under the strong room operations: 

• Valuables sealed packets deposited under various orders / authority as per 

SR 47 of MPTC Vol.-I 

• Other important documents by the order of District Collector/competent 

authority as per SR 47 of MPTC Vol.-I 

• Sealed packets of duplicate keys of different offices 

• Stamps of different Denominations pertaining to court fees, registration fee, 

Excise duty, judicial and Non-Judicial stamps, and special Adhesive stamps, 

water mark paper 

• Cheque Books pertaining to different departments like Treasury cheque 

book, PWD cheque book, Forest cheque book, P.D. cheque book 

• Other documents like Bill Transit Register, Money Receipt Book 

• Cash chest of different offices 

2. Should allow TO to select any of the above option 

Valuables Sealed Packets, Other Important Documents or Sealed packets of Duplicate Keys & 

Sealed Cash Chest 

1. Should provide an option to select for registering any new identity that has come for 

storing under the strong room. As soon as the TO would select this option should 

generate a Storage ID for the particular item. 

2. Should be allowed to capture the invoice details of material deposited under the 

strong room operations, the format for capturing the details would be as follows: 

• Storage id (self generated) 

• Treasury name (self generated) 

• Treasury code (self generated) 

• Date of receiving material (system generated) 

• Depositing Agency 

• Court Case Number (Applicable for court case only) 

• Court Case Date (Applicable for court case only) 

• Sanction Number (if applicable) 

• Sanction Date (if applicable) 

• Deposit ID (System generated) 

• Concerned Official – Designation and Code 

• Deposited From Date 

• Deposited To Date 


Attachment B 


• Letter Number (if manually letter comes from dept.) 

• Letter Date (if manually letter comes from dept.) 

• Detail of valuable (would choose from drop down - Valuables Sealed 

Packets, Other Important Documents Sealed packets of Duplicate Keys) 

• If other (Please Specify) 

• Quantity of valuable received 

• Certificate – Remarks (to be filled by TO that the material was received 

properly sealed) 

3. Should be allowed to generate an acknowledgement receipt with the above details 

4. Should be allowed to store details of each stored material line-wise over the system 

Receipt of stamps request stamps issuance of stamps by District Treasury Officer to 

Sub Treasuries and Other Treasuries 

For Sub Treasuries 

1. Should show Office in Charge at the treasury of the current stamps inventory 



3. Should allow the officer in charge of sub treasury to raise an indent for stamps 

procurement at the system. The Officer in charge would raise the request in the 

following format: 




• Current stamps stock status: 


• Remarks: 







• Current stamps stock status: 


• Remarks 

5. Should receive alerts as soon as the DTO updates his system after receiving stamps 

6. Should allow the Officer in Charge at sub treasuries to capture the delivery details 

whenever he receives the delivery of stamps. The format for capturing the delivery 

details would be as follows: 

• Date (of updation): 


Attachment B 


• Type of Stamps (drop down box): 

• Number of stamps received: 



• Value of stamps: 

• Invoice number: 

• Indent number of delivery: 

• Received from (Name of the press) 

• Date of receiving: 

For Issuing District Treasury 

1. Should allow the DTO to fix the inventory levels at the district and sub treasuries 

(……% of overall stock capacity – this would be based on the past 3 years trends of 

stamps sales, Lead supply time for arranging stamps) 

2. Should allow the District Treasury Officer to view the requests raised by the Officer 

in Charge at the sub treasury under his jurisdiction 

3. Should allow DTO to consolidate his treasury’s stamp requests with the stamp 

requests of sub treasuries falling under his jurisdiction 

4. Should allow DTO to update consolidated stamps request for the entire district that 

would consist of stamp requests for all the sub treasuries, district treasury and city 

treasury over the application 

5. Should generate a deposit id as soon as the DTO submits the stamps request over 

the application 

6. Should allow the DTO to capture the delivery details whenever he receives the 

delivery of stamps. The format for capturing the delivery details would be as follows: 

• Date (of updation): 

• Type of Stamps (drop down box) 

• Denomination of stamps (in Rs.) 

• Number of stamps received: 

• Series of stamps received (From S. No. …….. To S. No.) 



• Total Value of stamps: 

• Invoice number: 

• Indent number of delivery: 

• Received from (Name of the press): 

• Date of receiving: 

• Remarks 

7. Should generate alerts for the treasury / sub treasuries as soon as the DTO updates 

his system that the stamps have been received at his end 

8. Should allow the DTO to re allocate the stamps to sub treasuries and other 

treasuries, the following fields should be available to the DTO during the stamps 

allocation: 


Attachment B 



• Name & Code of treasury / sub treasury to which the stamps have been 

allocated (should be a drop down option): 

• Number of stamps requested by the treasury (auto generated) 

• Number of stamps allocated to particular treasury / sub treasury: 


Attachment B 


1.8.3 Stamps Selling from Treasury 

Table 52: Functional Requirement Specifications - Stamps Selling 

Business Requirement – Stamps Selling 

Sr. No. 


1. The system should maintain record of all the registered stamp vendors 

2. The system should capture details of all the stamp procurement. The system should 

capture the following items through the cyber treasury application: 

• Name of vendor / Individual : 

• Registration id (in case of vendors): 

• Type of stamps requested: 

• Denomination of stamps requested: 


• Amount submitted (Total amount ……… Commission Amount………….): 

• Head details: 

• Date of amount submission: 

• Current date: 

3. Should be able to search the transactions database. The search should provide the 

results based on following search criteria: 

• Vendor id 

• Transaction date 

• Vendor name 

4. Should maintain ledger accounts for the registered agents. The ledger accounts 

would help the TOs to make staggered allotment of stamps to the vendors. E.g. if 

the treasury is not able to make full allotment of stamps at one go then TO can mark 

it in the application only this much number of stamps have been allocated and this 

much number of stamps are yet to be allocated 

5. Should allow TOs to make the following entries during stamp allocation: 

• User of cyber treasury application - Bank / Individual (self filled using the 

information obtained by cyber treasury): 

• Name of vendor (self filled using the information obtained by cyber 

treasury): 

• Registration id (self filled using the information obtained by cyber treasury): 

• Type of stamps requested (self filled using the information obtained by cyber 

treasury): 

• Number of stamps requested (self filled using the information obtained by 

cyber treasury): 

• Amount received (self filled using the information obtained by cyber 

treasury): 

• Head Details (self filled using the information obtained by cyber treasury): 


Attachment B 


• Date of amount submission (self filled using the information obtained by 

cyber treasury): 

• Number of stamps allotted to the vendor (to be enter by treasury officer) 

• Number of stamps pending to be allotted (to be enter by treasury officer) 

• Stock before the start of delivery (self generated) 

• Stock situation after the delivery of material (self generated) 

6. Should generate a sales receipt for the vendor to whom the stamps have been 

allotted, a copy of the sales receipt should also be captured in the system. The details 

of the sales receipt would be as follows: 

• Name of vendor 

• Registration id 

• Type of stamps requested 

• Number of stamps requested 

• Amount received 

• Head Details 

• Number of stamps allotted to the vendor 

• Number of stamps pending to be allotted 


Attachment B 


1.8.4 Return of stored valuables from Treasury 

Table 53: Functional Requirement Specifications - Return of Stored Valuables from Treasury 

Business Requirement – Return of Stored valuables from Treasury 

Sr. No. 


1. The system should maintain record of all the stored items with the treasury 

2. Should be able search the items in the database. The search should provide the 

results based on following search criteria: 

• Department’s name 

• Department id 

• Acknowledgement receipt number 

3. Should show the following details on locating the particular record: 

• Transaction id 

• Department name 

• Department id 

• Details of item stored 

• Quantity of item stored 

• Date of storage 

4. Once the TO locates a particular record he should be provided with an option of 

release / issuance of stored item. As soon as the TO would press the release item 

button he should be allowed to make the following entries in addition to the above 

entries: 

• Transaction id (generated automatically) 

• Department name (generated automatically) 

• Department id (generated automatically) 

• Details of item stored (generated automatically) 

• Quantity of item stored (generated automatically) 

• Date of storage (generated automatically) 

• Number of items released (to be filled by TO) 

• Date of release (to be filled by TO) 

• Time of release (to be filled by TO) 

• Current stock status (to be filled by TO) 


Attachment B 


2. Human Resource Management Information System 

The following sections capture the functional requirements of the human resource and 

pension processes as envisaged by the Integrated Human Resource and Government 

Financial Management Information System. 

2.1 Manpower Planning 

Table 54: Functional Requirement Specification –Manpower Planning 

Business Requirement – Manpower Planning & Cadre Management 

Sr. No. 


1. System should allow authorized user (CCA level as per roster) to perform 

analytics on sanctioned posts in a cadre and establishment unit (old/new/to-be) 

2. System should allow generation of lists of permanent/temporary posts at any 

time. CCA level ex cadre / cadre 

3. System should have proposal formats (for Conversion of part of temporary 

establishment to permanent establishment, continuing remaining temporary 

establishment, on creation of new establishment on surrender of old 

establishment post, surrender existing establishment posts 

(temporary/permanent) cadre review) available in the system so that proposal 

can be created 

4. System should have formats of orders available in the system for Conversion of 

part of temporary establishment to permanent establishment, continuing 

remaining temporary establishment, on creation of new establishment on 

surrender of old establishment post, surrender existing establishment posts 

(temporary/permanent) and cadre reviews (CCA level) 

5. System should allow user to define qualification/ requirements for post 

identified for recruitment for each cadre or post 

6. System should be able to project future requirement of employees and salary 

outflows over time 

7. System should allow authorized users to update the list of establishment 

positions which were converted and created 

8. System should allow authorized users to update the list of sanctioned posts in a 

cadre setup 

9. System should allow authorized users to update and publish the cadre gradation 

list 

10. System should also have e-mail facility for communication to take place 

11. Authorized users should be able to view the final list of temporary and 

permanent posts in a cadre/setup 


Attachment B 


2.2 Recruitment 

Table 55: Functional Requirement Specification - Recruitment 

Business Requirement: Recruitment 

Sr. No. 


1. System should generate vacancy list sorted by cadre, ex- cadre & dying post and 

appropriate recruitment mode 

2. System should allow online communication via e-mail between CCA, 

administrative department and other recruitment agencies 

3. System should allow downloading of data from Internet, if a website for the said 

purpose of recruitment exists 

4. System should allow mapping of eligibility requirements against positions / 

grades / locations, and at the same time maintenance of a vacancy database 

5. System should be able to provide for formats for placing advertisements for 

recruitment at CCA level 

6. System should generate the required eligibility requirements against requisitioned 

/ required position to be filled in 

7. System should be capable of short-listing from list of electronic applications 

received, on the basis of essential criteria and highlight extent of fulfillment of 

desirable criteria for the shortlisted candidates 

8. System should have standard formats(of orders and communication letters to 

agencies and appointment of selected candidates) available in the system as 

provided by GoMP 

9. System should provide facility for uploading of documents of new recruits 

10. System should allow for checking the availability of a potential candidate for a 

position from the employees on rolls 

11. System should be able to maintain the details of individuals who have applied 

directly or through other media 

12. System should allow creation of service records for new recruits 

13. System should generate reports on percentage vacancies filled up 

14. System should create records for police verification, medical reports / date of 

birth / finger print / nominations / forms / details and other records necessary 

for service records 

15. System should provide format for capturing learning after the process of 

recruitment completed 


Attachment B 


2.3 Confirmation 

Table 56: Functional Requirement Specification – Confirmation 

Business Requirement: Confirmation 

Sr. No. 


1. System should allow reviewing of availability of vacant permanent post for 

confirmation in the cadre by generating required list as per system defined 

parameters or as and when required 

2. System should generate list of employees (meeting confirmation criteria) to be 

confirmed on quarterly basis / periodic intervals 

3. System should allow tracking of probation period for each new employee and 

provide system alerts on probation completion due dates 

4. System should allow entry/ update of reporting/probation location assigned to 

employee and its lien 

5. System should retrieve data on training undertaken and other details (successful 

completion certified/tested) as needed for confirmation 

6. System should track passing of required exams (departmental/professional) 

7. System should record & generate alert on successful completion of confirmatory 

training 

8. System trigger process for confirmation based on defined rules 

9. System should generate list of data not found in the related database 

10. System should generate list of employee fit for confirmation based on system 

defined confirmation rules/orders and available data 

11. System should generate list of employees confirmed on the basis of vacant 

permanent posts available and should also declare remaining fit candidates to be 

declared quasi permanent 

12. System should allow authorized user to increase the duration of probation if 

employee not confirmed due to given reason (non completion of training or 

passing of exam) and allow related authority to define its impact on seniority. 

13. System should have standard formats of order given by GoMP available in the 

system for issuance of confirmatory/QP orders 

14. System should record/ update confirmation date and location of employee in 

data base 

15. System should generate gradation list from updated employee data 

16. Once an employee is confirmed his present post, salary structure should get 

updated in the system as required 


Attachment B 


2.4 Leave Management 

2.4.1 Leave Management (Earned and Availed) 

Table 57: Business Requirement - Leave Management (Availed and Earned) 

Business Requirement – Leave Management (Availed and Earned) 

Sr. No. 


1. System should support on-line Leave application processing by providing 

required workflow 

2. Multiple Leave types and related rules should be defined in the system 

3. System should allow users to view leaves eligibility and leaves availed 

4. System should allow users to apply for leave under different applicable and 

eligible categories/rules 

5. System should define hierarchical workflows for recommendation and approval 

of leaves 

6. System should be able to record the recommendation/approval/ rejection of 

applied leaves and update the employee leave account accordingly 

7. System should be able to generate alert for giving reasons if leave is refused. 

8. System should be allow selection of general reasons of refusal of leave from a 

dropdown menu and provide a text box for inserting other specific reasons 

9. System should support a Business Calendar and Leave Application dates should 

be validated against this calendar 

10. System should support a Forward Leave Plan by employee, department, 

company etc. 

11. System should support Forward Leave Plan to generate a Leave Program for a 

employee in case s/he is planning for further studies, vacation etc. 

12. System should calculate and print an advice on joining date, remaining leave and 

other user defined data to user specified entities like number of leaves used, 

leaves remaining 

13. On approval of the leave, system should calculate payment entitlement and raise 

the necessary payment/recovery requisition if needed 

14. System should have all leave formats available in the system 

15. System should support leave amendments and adjustments 

16. System should support backdating of leave by the authorized user 

17. System should support conversion of one type of availed/sanctioned leave into 

another 

18. System should retain all leave history (approved, rejected, adjusted) till the user 

requests purge based on user defined criteria 


Attachment B 


19. If an employee joins earlier/later then approved date then system should be able 

to apply user defined rules for early, late returns and initiate 

adjustments/deductions electronically in the Payroll Module after revised 

sanction 

20. System should have provision that a salary is stopped if a person is absent for 

more than 1 month without proper sanction or as per rules and policies 

21. System should support regularization of unsanctioned absence period by grant 

of different types of leave and LWP/Leave Not Due 


Attachment B 


2.4.2 Leave Management (Earned and Availed)-Half Pay Leave 

Table 58: Business Requirement - Leave Management (Earned and Availed) – Half Pay Leave 

Business Requirement – Leave Management (Availed and Earned) – Half Pay Leave/ 

Medical Leave 

Sr. No. 







eligible rules/categories 

5. System should allow definition of hierarchical workflows for approval of leaves 

6. System should be able to record the approval/ rejection of applied leaves and 

update the employee leave account accordingly 






10. System should allow employee to upload scanned medical leave certificate 

11. On approval of the leave system should calculate payment entitlement and raise 

the necessary payment/recovery requisition if needed 





more than 1 month or as per rules and policies 


Attachment B 


2.4.3 Leave Management (Availed Leaves) - Commuted (Medical Ground) 

Table 59: Business Requirement - Leave Management (Availed Leaves) - Commuted (Medical 

Ground) 

Business Requirement – Leave Management(Availed Leaves)- Commuted (Medical 

Ground) 

Sr. No. 







eligible categories 

5. System should allow definition of hierarchical workflows for approval of leaves 

6. System should be able to record the approval/ rejection of applied leaves and 

update the employee leave account accordingly 






10. System should allow employee to upload scanned medical leave certificate and 

fitness certificates 

11. On approval of the leave system should calculate payment 

entitlement/recoveries and raise the necessary payment/recovery requisition if 

needed 







Attachment B 


2.4.4 Leave Management (Availed Leaves) - Commuted (On other Ground) 

Table 60: Business Requirement - Leave Management (Availed Leaves) - Commuted (On Other 

Ground) 

Business Requirement – Leave Management(Availed Leaves)- Commuted (On other 

Ground) 

Sr. No. 




2. Multiple Leave types and related issues should be defined in the system 



eligible categories/rules 

5. System should allow definition of hierarchical workflows for recommendation 

and approval of leaves 

6. System should be able to record the recommendation/approval/ rejection of 

applied leaves and update the employee leave account accordingly 







other user defined data to user specified entities 


the necessary payment requisition if needed 

12. System should generate a warning for any document expiry during the planned 

leave period 

13. System should have all leave formats available in the system 



16. System should support conversion of one type of availed/sanctioned leave into 

another 





adjustments/deductions electronically in the Payroll Module 


Attachment B 




20. System should support regularization of unsanctioned absence period by grant 

of different types of leave and LWP/Leave Not Due 


Attachment B 


2.4.5 Leave Management (Availed Leaves & Adjustment from leave to be 

earned in future) - Leave not due 

Table 61: Business Requirement - Leave Management (Availed Leaves & Adjustment form Leave to 

be earned in future) – Leave not due 

Business Requirement – Leave Management(Availed Leaves & Adjustment from leave 

earned in future)- Leaves not due 

Sr. No. 


1. Multiple Leave types should be defined in the system by providing required 

workflow 



eligible categories 




other user defined data to user specified entities 


the necessary payment requisition if needed and deduct amount from payroll if 

needed 

7. System should generate a warning for any document expiry during the planned 

leave period 







adjustments/deductions electronically in the Payroll Module 

12. System should inform employee of leaves to be deducted from their account in 

future 




Attachment B 


2.5 Performance Management System (PMS) 

Table 62: Business Requirement - Performance Management System 

Business Requirement –Performance Appraisal 

Sr. No. 


5. System should provide facility for online processing for Appraisals 

6. System should allow concerned authority to upload Goals / KRAs for the year 

for a department/district/unit 

7. System should allow concerned employees to upload their KPAs, goals and 

objectives for the appraisal period 

8. System should allow concerned employees to create action plan for achievement 

of goals and objectives set by them or for them by superiors 

9. System should allow concerned employees to fill in the implementation progress 

information in action plan implementation schedule, recording ease/difficulty in 

completing each planned activity 

10. System should allow concerned employees to undertake periodic reviews (at 

major mileposts) and final evaluation of implementations with their supervisory 

officers 

11. System should allow concerned employees and their supervisory officers to 

upload reports on results of periodic reviews and evaluations jointly 

12. System should allow training and development assessment information to be 

also uploaded in the TNA database 

13. System should allow e-mail communication 

14. System should generate on-line Confirmation of joining date of new 

employees/absorption forms for purpose of appraisal by Head of Department 

15. System should be able to log various stages of employee appraisal and evaluation 

process to generate Performance Evaluation forms on-line and forward them 

through workflow 

16. System should have inbuilt forms for Appraise & Appraiser to fill up 

17. System should allow Appraise & Appraiser and/or CCA/Reviewer to view the 

form on-line at the same time 

18. System should generate alerts to point out if self assessment/review is over due 

19. System should support to hold evaluation and results/reports of multiple 

reviews in the system to be used for self-assessment and appraisals 

20. System should provide facility for online processing for Appraisals 

21. System should allow reports to be sent to assessing officer by employees and 

reviewer for reviewing by CCA 

22. System should allow employee to see final comments of appraisers accept CR 

grading 


Attachment B 


23. System should allow employee to make representation against adverse comments 

reported if any 

24. System should store finalised appraisal reports with restricted access 

25. System should also store CR grades in a separate file to be accessed by the 

system for confirmation and promotion processing, etc. 


Attachment B 


2.6 Training and Learning Management 

2.6.1 Training - Planning 

Table 63: Business Requirement Specification – Training Planning 

Business Requirement – Training – Planning 

Sr. No. 


1. System should support online uploading of draft and final Training policy 

2. System should support online uploading of comments/suggestions on draft 

training policies 

3. System should have all the training related details for all employees (trainings 

done and trainings needs expressed as core and professional competencies) 

4. Training and Development needs identified through Performance Appraisal 

System should be captured in the system as priority needs for related employees 

5. System should facilitate training need analysis by allowing employees to fill-up 

online questionnaires 

6. System should facilitate training need analysis by allowing employees to access 

competency testing system 

7. System should have formats available in the system for proposal creation, 

training plan, budget preparation and allocation of training budget to field units 

8. System should allow definition of hierarchical workflows for approvals (plan & 

budget) 

9. System should also have previous year’s budget estimates 

10. System should allow authorize users to select training providers form training 

database, 

11. System should allow authorize users to use web mail for communication to 

training providers, employees, etc 

12. System should allow training programme schedule to be uploaded in the system 

with likes to details like training provider, programme design, location, etc 

13. System should allow employees to select optional (professional & development) 

training programmes and uploading request to participate 

14. System should have approval workflow (HOO/CCA) for requests uploaded by 

employees for optional programme 

15. System should allow DTO to compile employees’ requests for optional training 

programmes and use system defined criteria to prepare shortlist of selected 

employees. 


Attachment B 


2.6.2 Training - Implementation 

Table 64: Business Requirement Specification - Training - Implementation 

Business Requirement – Training - Implementation 

Sr. No. 


1. System should have provision for training details to be captured 

2. System should allow communication to take place between DTC and selected 

training candidates 

3. System should have standard formats available of orders available in the system 

4. System should allow online payment transfer to training providers through 

DDO of HOD 

5. System should have provision for online feedback / validation on Trainings by 

the employees while creating their training completion reports 

6. System should have provision for online creation/uploading of action plan for 

consolidation/ transfer of learning by employee on completion of training 

7. System should have provision for online updation of action plan when activities 

gets completed 

8. System should have provision for tracking of implementation of action plan by 

HOO/CCA 

9. System should have provision for creation of instruments for online evaluation 

of training by employees/supervisors whose access and response recorded in the 

system 

10. System should have provision for online tracking of responses uploaded by 

related (trainees/supervisors) and generate reminders/escalation to superiors if 

not done by due date 

11. System should have provision for online compilation of responses to evaluation 

instruments by DTO/CCA 

12. System should have provision for uploading of evaluation reports in the related 

training records 

13. System should allow online updation of employee records 


Attachment B 


2.6.3 Training – Learning Management 

Table 65: Business Requirement Specification - Training Learning Management 

Business Requirement Training – Learning Management 

Sr. No. 


1. System should allow employees to upload in workflow self development needs 

as identified during analysis of own work/assignments in consultation with 

supervisory officers. 

2. System should allow employees’ supervisory officers (immediate and HOO) to 

mark their agreement in the workflow and upload to DTO/CCA 

3. System should allow employees’ to upload requests for job rotation, special 

assignments and secondments in the workflow 

4. System should allow employees’ supervisory officers (immediate and HOO) to 

mark their recommendations on employees requests in the workflow and upload 

to DTO/CCA 

5. System should allow CCA and HOD to approve or rejects (assigning reason) 

employee’s requests for job rotation, special assignments and secondments 

6. System should allow web-mail communication 

7. System should have standard formats available for all related orders 

8. System should allow online uploading/consolidation of training learning data 

once the employee is back from training 

9. System should allow alerts generation if employees returning from competency 

trainings, secondments for experiential learning do not upload required reports 

in prescribed time limit 

10. System should allow employees to upload implementation information regarding 

action plans 

11. System should allow online updation of employee records 


Attachment B 


2.7 Promotion 

2.7.1 Promotion 

Table 66: Business Requirement Specification - Promotion 

Business Requirement –Promotion 

Sr. No. 


1. System should be able to define cadre specific and general promotion rules in 

the system 

2. System should store all the rules pertaining to promotion 

3. System should allow employees to view the rules for promotion 

4. System should be able to identify vacant posts for promotion 

5. System should be able to generate timely triggers indicating the due date for 

promotion, process to start 

6. System should check mandatory conditions, such as completion of required 

service period and/or completion of required service period at the lower post 

from which to be promoted, before promotions 

7. System have integration with "Cadre Management" for accessing gradation lists 

8. System should update employee's grade & pay scale details resulting due to 

promotion decisions 

9. System should have access to all the CR Grades & Performance Appraisal of 

employee till date 

10. System should have access to other reports of employee to be considered by 

DPC, e.g. DE/No event (Police or Lokayukt enquiry etc.) 

11. System should be able to generate final gradation list to be submitted to DPC 

12. System should be able to generate lists of employees in zone of consideration as 

per cadre/general promotion rules 

13. System should record details of promotion declined earlier by employees in zone 

of consideration 

14. System should be able to generate list of employees in zone of consideration as 

per specific cadre/related general promotion rules 

15. System should be able to depict CR grades of each employee in zone of 

consideration for the period as defined by the specific cadre/related general 

promotion rules 

16. System should be able to generate online fit list of employees as decided by DPC 

17. System should be able to block (keep promotions under sealed cover) employees 

from promotion against whom DE/other events are pending till a final decision 

in the matter is taken and recorded in the system 


Attachment B 


18. System should have standard formats of promotion orders available in the 

system 

19. System should generate on-line promotion orders 

20. Policy for Salary revision, Increments consequent upon Promotions should be 

maintained in the system on-line and trigger them for pay fixation process in 

related module 

21. System should have the facility to send a communication to the employee in case 

he is promoted 

22. Concerned authority should have the provision to update employee database and 

gradation list in the system if not auto triggered 


Attachment B 


2.7.2 Time Bound Pay Scale Enhancement (Kramonati) 

Table 67: Business Requirement Specification - Time Bound Pay Scale Enhancement (Kramonati) 

Business Requirement –Promotion 

Sr. No. 


1. System should be able to define cadre specific and/or general rules in the system 

for Time Bound Pay Scale Enhancement (Kramonati) 

2. System should be able to generate timely triggers indicating the due date for 

Time Bound Pay Scale Enhancement (Kramonati) in all cases 

3. System should check mandatory conditions, such as completion of required 

service period (completion of required service period) at the post on which Time 

Bound Pay Scale Enhancement (Kramonati) to be given 

4. System have integration with "Cadre Management" for accessing gradation lists 

5. System should update employee's grade & pay scale/ pay band / grade pay 

details resulting due to the decisions 

6. System should access CR Grades & Performance Appraisal of employee for 

required period 

7. System should have access to other reports of employee to be considered by 

KC, e.g. DE/No event (Police or Lokayukt enquiry etc), etc 

8. System should be able to generate final gradation list to be submitted to DPC 

9. System should be able to generate lists of employees in zone of consideration as 

per cadre/general Time Bound Pay Scale Enhancement (Kramonati) rules 

10. System should record details of promotion declined earlier by employees in zone 

of consideration 

11. System should be able to depict CR grades of each employee in zone of 

consideration for the period as defined by the specific cadre/related general 

Time Bound Pay Scale Enhancement (Kramonati) rules 

12. System should be able to generate online fit list of employees as decided by KC 

13. System should be able to defer grant of Time Bound Pay Scale Enhancement 

(Kramonati) to employees from against whom DE/other events are pending till 

a final decision in the matter is taken and recorded in the system 

14. System should have standard formats of Time Bound Pay Scale Enhancement 

(Kramonati) orders available in the system 

15. System should generate on-line orders 

16. Policy for Salary revision, Increments consequent upon Time Bound Pay Scale 

Enhancement (Kramonati) should be maintained in the system on-line and 

trigger them for pay fixation process in related module 

17. System should have the facility to send a communication to the employee in case 

he is promoted 


Attachment B 


18. Concerned authority should have the provision to update employee database and 

gradation list in the system if not auto triggered 

19. System should be able to define rules for Time Bound Pay Scale Enhancement 

(Kramonati), scan perquisites & auto generate orders on due dates for employees 

if auto process enabled 


Attachment B 


2.8 Payroll Processing 

Table 68: Functional Requirement Specifications - Payroll Processing 

Business Requirement: Payroll Processing 

S. No Requirement Description 

1. The system shall record, as a minimum, the following data: 

• Job classifications and descriptions 

• Employee status codes and descriptions 

• Salary & allowance codes, descriptions and Tax indicators 

• Deduction codes and descriptions 

• Beneficiaries for deductions (Account code, individuals etc.) 

• Location (Disbursement Centre) codes and descriptions 

• Treasury Office/District code and names 

• Leave codes and descriptions 

• Payroll Calendar 

• Pay scale number, Pay scales, Pay scale description 

2. The system should provide facilities to add, modify, reclassify or abolish job 

positions in accordance with the approved manpower ceiling. In particular, 

the following data should be recorded in the system as a minimum: 

• Position Number 

• Designation 

• Position Category 

• State Institution 

• Division/Department 

• Job Classification 

• Occupant’s employee identification number 

• Position creation date (date created in the position list) 

• Position status {permanent/temporary/occupied | vacant 

|unfunded} 

• Occupancy History 

• Start Date 

• End Date 

3. The system allow receipt of attendance / leave records from: 

• All locations (HOO) 

• All departments 

4. The system should make New Pension Scheme (NPS) deductions from 

employee salary as per grade. 

5. The system should allow park payroll run for those employees whose 

attendance, leave or other related records are missing, or cannot be 

processed. 


Attachment B 


6. The system should check the leave sanction records for each employee. 

7. The system calculate basic pay, pay band, grade pay for each employee based 

on: 

• Standard salary rate for the employee 

• Attendance, leave, , etc based on data received 

8. The system should accommodate adjustment for the previous period's 

attendance. 

9. The system should allow automatic calculation of Payroll based on the above 

inputs. 

10. The monthly salary be calculated from: 

• Base salary 

• Overtime (calculated at hourly rates) 

• Allowances (regular monthly) 

• Allowances (one-off additions) 

• Duty allowances 

• Allowances based on a % to basic salary 

• Allowance based on a particular shift such as Night shift allowance 

• Deductions for absence (calculated at hourly rates) 

• Standard deductions (regular monthly) 

• One-off deductions 

• Deductions uploaded from other systems such as TDS, Staff 

Advance, Co operative recoveries etc. 

11. The System should be able to itemize by employee for reporting purposes. 

12. System should itemize all the above on the pay slip. 

13. The system should keep track of vacation days so that vacation pay 

entitlement can be paid as & when required. 

14. The system should track any restriction on the number of allowances which 

can be paid to employees. 

15. The system should track any restriction on the number of Deductions which 

can be made in the pay roll system. 

16. The system should allow repatriation accruals to be calculated based on 

contract period and probability of extension. 

17. The system should allow deductible EMI be entered for the period for 

which it is to be deducted based on sanction orders 

18. The system should stop EMI deduction automatically after end of the 

period. 

19. System should allow arrears of salary be paid for the adjustment of salary for 

the previous period by giving range of months/ Period. 

20. The system should automatically calculate all the dependent components in 

the Payroll, as per GoMP regulation 


Attachment B 


21. The system should automatically check for deduction dues status before a 

person leaves for vacation. 

22. The system should maintain grades and associated deductions for all 

employees. 

23. The system should automatically update payroll calculation rules whenever 

an employee's grade changes. 

24. The system should handle more than one type of payroll - e.g. regular 

employees paid monthly and temporary/contract staff paid irregularly work 

changed / contingency employee. 

25. Some of the reports which should be available: 

• Employee status 

• Payroll rejection 

• Bank deposit details 

• Employee pay history 

• New employees list 

• Departed employees list 

• Salary increases (confidential) 

• Warnings list (confidential) 

• Vacation pay accruals by department 

• Indemnity accruals by department 

• Wages cost by department and category 

• Wages including on costs by department and category of staff 

• Deductions / Deposits list giving employee wise amount deducted 

• Cash advances list employee 

• Accident penalty list employee 

• Other deduction 

• Salary Register 

• Salary slips in soft copy uploaded to employee webpage 

26. The system should calculate Leave / Vacation Settlement for an employee 

based on: 

• Leave Records 

• Eligibilities 

• Leaves Earned 

• Date of Vacation start 

27. The system should automatically block payroll processing for an employee 

based on his vacation date. 


Attachment B 


28. The system should maintain vacation / leave resumption details of each 

employee. 

• Leave eligibility 

• Applied duration of Leave 

• Actual duration of Leave 

• Excess days (Actual - Applied) 

• Less days (Applied - Actual) 

29. System should automatically release payroll block once the employee's 

vacation / leave resumption notification is received. 

30. System should perform deductions based on Excess / fewer days based on 

vacation / leave duration. 

31. System should perform deductions based on Excess / Less days paid based 

on Vacation / Leave start date 

32. The system should maintain records of employees who encash their 

Vacation 

33. The system should allow instruction to be given to Finance on whether to 

make the deduction payments in Cash or Advance. 

34. The system should capture cash advances paid to employees. 

35. The system / module should enable payment to be made on specific dates, 

for example, salary paid on last day in each month. 

36. The system should make available security controls to limit access to 

specified personnel. 

37. System should allow viewing of data as per employee on line by those 

permitted access. 

38. The system should have an interface with Disbursement and accounts 

module to transfer the payroll related information. 

39. The system should be flexible enough to provide and restrict access to tasks 

within Payroll between users of HR and Finance according to the 

requirement. 

40. The system should up load data / interact with other modules as required. 

41. The system should be able to associate one salary grade code to other salary 

grade 

42. The system should support exceptions to CCA in case of any salary increases 

and promotions 

43. The system should be able to define compensation elements like HRA, 

compensatory Allowance, Transport Allowance etc. 

44. The system should be able to define eligibility of compensation elements to 

jobs, positions, grades etc. 


Attachment B 


45. The system should be able to assign compensation elements to employees 

automatically 

46. 

The system should be able to define security for view and entry of 

compensation data. 

47. The system should send a message to the employee in case his / her salary is 

not getting calculated due to reasons like rejoining application not filled after 

returning from leave or any other reason 

48. 

The system should be able to calculate and generate salary bill 

49. The system should compute manually & automatically the values of earnings 

and deductions by using standard formulas 

50. The system should support detailed payroll calculations using conditional 

logic and references to any module 

51. The system should maintain/ configure pay elements like LT, leave and 

Medical etc. 

52. The system should allow restriction of administrative functions to a few 

selected payroll users 

53. The system should allow the display of only selected menu options/ forms 

based on the role of the user 

54. 

The system should upload payroll history data 

55. The system should maintain slab wise details for all statutory elements like 

Income Tax, etc. as well as user defined elements 

56. The system should indicate taxable earnings, deduction priority, carryover, 

partial recovery etc. 

57. The system should view pay related details via reports and queries 

58. The system should calculate following kinds of pay elements Basic/ Leave 

Encashment/ Joining Bonus ,Special Pay/ Allowance, Dearness Allowance, 

House Rent Allowance, City Compensatory Allowance, Tuitions Fees, 

Children’s Education Allowance, Washing Allowance, Conveyance 

Allowance, Transport Allowance, Others (User Defined) 

59. The system should allow deductions that might be either GoI rules, State 

Rules or Local organization rules like General Provident Fund, Festival/ 

Grain Advance, Natural Calamity Advance, Cycle/ Scooter Advance, 

Income Tax/ Surcharge, Employee Welfare fund, Others (User Defined) 

60. The system should record Loans & Advance payments details like Interest 

Free Advances, Short Term Advances, Long Term Advances (Interest 

Bearing Advances), etc. 

61. The system should allow the cap of deductions at user defined fixed values 

or as a percentage of some pay elements 


Attachment B 


62. The system should allow calculation of one time payment of allowance and 

deductions by amount, days , percentage etc. 

63. The system should allow input of start and end date for recurring payment / 

deductions 

64. The system should support any ad hoc basis payment recalculation during 

the payroll run while preserving the run’s other results. 

65. The system should monitor regular payroll cycle from data entry to fully 

reconciled results 

66. 

The system should view complete history of payroll results 

67. The system should mark erroneous calculations for retry while keeping 

reconciled calculations intact 

68. The system should automatically detect the changes made in the past that 

would impact payroll and run retro pay for those employees 

69. The system should calculate Payroll online 

70. The system should calculate an individual’s payment online 

71. The system should view pay slip online 

72. The system should update balances immediately upon calculation 

73. The system should maintain complete taxation rules defined as part of the 

pay structures configuration 

74. The system should configure various tax rules (e.g. Income tax, Professional 

taxes, etc ) on basis, method of calculation, Default percentage rates, General 

accounts to which tax effects may be posted, Applicable State etc. 

75. The system should generate reports / certificates (user defined format with 

reference number) 

76. The system should project tax liability of an employee for the period within a 

tax calendar and providing tax planners to the employee 

77. The system should support separate tax tables for bonus pay calculations 

78. The system should handle exemptions and rebates as per the Income Tax 

Rules 

79. The system should calculate HRA Rebate 

80. The system should handle LTC and Medical exemptions as per the Income 

Tax Rules 

81. The system should generate automatically employer/employee returns in pdf 

or any other format 

82. The system should process out-of-sequence checks (pay slip) e.g. in the cases 

of transfers in middle of month 

83. 

The system should display the status of the Payroll calculations 


Attachment B 


84. The system should run Payroll multiple times before finalization to ensure 

accurate pay computation 

85. The system should maintain start and stop dates for deductions on the 

Employee Master file 

86. The system should define element categories and associated taxation 

87. The system should make deduction amounts negative 

88. The system should include reverse deduction in next pay cheque if 

incorrectly withheld 

89. The system should determine deduction amounts by amount and percent of 

earnings 

90. 

The system should prioritize deductions by using the deduction code 

91. The system should apply or stop various deductions based on employee 

status changes (e.g., Leave Of Absence, term) 

92. The system should record Statutory Information & generate Reports 

93. The system should approve employee tax declaration 

94. The system should generate Pay slip in Bilingual (English, Hindi) along with 

pay elements 

95. The system should provide details of Earnings, deductions, Perquisites, 

Employer Charges, Income Tax Summary, Leave Details etc. 

96. The system should generate employee fund transfer Report 

97. The system should automatically update Payroll database for changes in 

employee record without interfering with payroll processing (e.g. 

Promotions in the middle of month, etc) 

98. The system should automatically update payroll database when pay rate 

changes due to any reason for e.g. promotion, pay commission, etc. 

99. The system should make Back dated calculations 

100. The system should reflect payroll adjustments in correct pay period 

101. The system should have a full and Final settlement process in place 

102. The system should generate arrear calculation for a defined period when 

salary enhancements (salary & allowances) are revised from retrospective 

effect 

103. The system should generate slandered deductions calculations on arrear 

amount calculated (IT, deductions based on % of salary component, e.g 

house rent (license fee) 

104. System should generate month-wise Due & Drown statement for arrears 

calculated citing reference of drawn amount (Treasury Voucher No & date) 

105. The system should generate electronic schedules of all deductions 

106. The system should port arrear claim data into DDO Accounting System on 

Arrear Pay Bill 

107. The system should record disbursal details on the bill (employee/ claimant 

Bank particulars and account number) 


Attachment B 


108. The system should update original payment entries after disbursal 

109. The system should update employee database after disbursal 


Attachment B 


2.9 Other Employee Entitlement 

2.9.1 Other Employee Entitlement (Loans and Advances) 

Table 69: Functional Requirement Specification - Other Employee Entitlement (Loans and Advances) 

Business Requirement: Other Employee Entitlement (Loans & Advances) 


1. The system should calculate entitlement based on defined rules. 

2. The system should enable analytics on entitlement payouts by cadre / 

department / position. 

3. The system should generate alerts on default when applications are uploaded. 

4. The System should have the facility to define multiple types of loans and 

Advances application formats: 

• Bicycle 

• Scooter 

• Car 

• House Building 

• Tour 

• Computer 

• Festival 

• Grain 

• From Provident Fund 

• Pay on Transfer 

5. The System should allow users to define loan eligibility criteria / repayment 

& also the recovery process. 

6. The System should allow integration with payroll module for the choice of 

mode of payment 

7. The System should be able to capture repayment conditions (no. of 

installments, rate of installment) 

8. The System would definition of hierarchical workflows for uploading 

application form for approval of loans/advances 

9. The System should have integration with employee service records for check 

of eligibility of loan and loan amount 

10. The system should have the provision for employee to submit information of 

Loans / Advances from other than Government Agencies. 

11. 

The System should be able to allow creation/filling of loan applications 

based on the checks such as available allocation of funds, Basic Pay of 

individual, duration of service, number of times advance is availed 


Attachment B 


2.9.2 Other Employee Entitlement [Claims (TA & Medical Reimbursement)] 

Table 70: Functional Requirement Specification - Other Employee Entitlement [Claims (TA & 

Medical Re-imbursement)] 

Business Requirement: Other Employee Entitlement [Claims ( TA & Medical reimbursement)] 


1. The system should calculate entitlement based on defined rules. 

2. The system should enable analytics on entitlement payouts by cadre / 

department / position. 

3. The system should generate schedules of adjustments/repayments and 

calculate deviations. 

4. The system should generate alerts on default. 

5. System should allow user to define supporting documents required (if 

necessary) for each type of claim 

6. System should allow user to define the employee grade wise eligibility of the 

claim limits 

7. System should allow user to define the approving authority for every type of 

claimant. Approving authority will authorize the purpose of expense 

8. System should allow user to submit claim for a single expense as well as 

multiple expenses 

9. System should allow submitted claim to be submitted to the DDO 

10. System should allow the appropriate authority to approve the claim 

11. System should be able to capture the eligibility requirement for availing LTA 

12. System should be able to calculate employee wise eligibility for LTA 

13. System should allow user to define the eligibility of medical claims 

14. System should have integration with payroll module for processing of 

reimbursements 

15. System should be able to track utilization of LTA and medical claims by 

employees 

16. System should allow hierarchical approval to application for non-core 

benefits 


Attachment B 


2.10 Transfer Posting, Joining and Deputation 

2.10.1 Transfer Posting, Joining and Deputation 

Table 71: Functional Requirement Specification - Transfer Posting and Joining 

Business Requirement: Transfer Posting and Joining time 


1. Should define Transfer Policy Parameters in the System 

2. Issuance of Transfer Order Activity for relieving of any employee on Study 

Tour and other reason at CCA, LPC also issuing online by CCA 

3. Should define cadre-wise HRD parameters/requirements (for job rotation) in 

the system 

4. Should define general policy of postings notified by government/ 

departments, e.g. Husband/Wife to be located at the same HQ town; 

relocated to identified place (..) years before superannuation; not more than 

(..)years in difficult locations (e.g. tribal area) 

5. Should define pre-qualification (academic/professional/experience) 

requirements for specific posts (usually needed for deputation postings, etc) 

6. The system should identify vacant posts for transfer and should included 

deputation and other requirements necessitating transfers. 

7. The system should allow generating of Transfer Proposals/Orders for 

transfer of employees from one location to another. 

8. The system should generate list of employees in each cadre coming under 

zone of consideration as per policy parameters 

9. The system should provide the "current location" of an employee at all times. 

10. The system should take requests for transfer uploaded in system from 

employees 

11. The system should match the position requirement with the employee profile 

12. The system should capture transfer requirements on the bases of 

administrative action (suspension/DE/complaint/etc) 

13. The system should match transfer requirement with the transfer location 

wish-list of the employees. 

14. The system should generate a short-list of transfers and postings based on 

redefined parameters by CCA/DTB 

15. The system should allow CCA/DTB to add/drop names from short-list and 

regenerate fresh lists with required alternatives 

16. The system should allow CCA/DTB to finalize transfer list 


Attachment B 


17. The system should publish final transfer list on department’s website 

18. The system should generate the "Transfer details" for employee when he is 

transferred from one location to another 

19. The system should be able to generate the Transfer order 

20. The system should be able to send the approved Transfer Order 

automatically to authorized personnel according to internal defined hierarchy. 

21. The system should generate a warning incase the employee has not joined the 

location within the specified period of time. 

22. 

The system takes a note of the further action to be taken after CCA/HOO 

discussion with the employee in case he/she has not joined the new location 

within a stipulated period of time? 

23. The system should support maintenance of data in case the employee has 

asked postponing of date. 

24. The system should update the employee master on relocation or transfer of 

an employee from one place to another or one department to another. 

25. The system should allow updation & maintenance of transfer details in the 

employee record with the transfer details. 

26. The system should maintain transfers that are to be issued in the future, e.g. 

on deputation/self relocation request 

27. If there is a change in the salary & perks of an employee due to transfer, the 

system should be able to maintain a record of such a change: 

• Standard salary rate for the employee 

• Employee data received 

28. The system should update employee data and gradation list. 


Attachment B 


2.10.2 Deputation 

Table 72: Functional Requirement Specification- Deputation 

Business Requirement: Deputation 


1. The system should generate circulars for deputation vacancies. 

2. The system should receive nominations for deputation vacancies. 

3. The system should shortlist nominations for deputation based on: 

• Educational Qualifications 

• Experience 

• Scale of Pay 

• Hierarchical Grouping of Post 

4. The system should prepare post-wise seniority list of employees applying / 

due for deputation. 

5. The system should allow recording of deputation details such as: 

• Start date and end date of deputation period 

• Post Deputed to 

• Office Deputed to 

• Section Deputed to 

• Deputation Pay Scale 

• Deputation Allowance 

• Terms and conditions of deputation 

6. The system should generate final list of people to be deputed department 

wise based on decision of acceptance of borrowing organization and DTB 

7. The system should issue letters: 

• Relieving Letter 

• Joining Letter 

8. The system should be capable to auto update employee database. 

9. The system should update gradation list automatically on employee joining 

deputation post. 


Attachment B 


2.11 Employee Grievance Redressal 

Table 73: Functional Requirement Specification - Employee Grievance Redressal 

Business Requirement: Employee Grievance 


1. The system should generate bilingual grievance form. 

2. The system should allocate unique number (ID) for grievance tracking. and 

maintain case history with essential data like: 

• Employee ID 

• Brief description about the grievance 

• Date of grievance filed 

• Status 

• Last decision 

3. The system should allow information/event tracking 

4. The system should generate periodic reports for the grievances redressal 

5. The system should keep record of grievance redressal status in related 

database. 

6. System should support online transfer of documents among offices of 

departments 

7. System should support online approvals as per the responsibility matrix 

defined in the system 

8. The system should allow users to define the categories of grievances. 

9. The system should generate statement of pending cases on a 

monthly/periodic basis which describes the status of the cases. 

10. The system should allow user to file appeal against the decision in a case. 

11. The system should track the number of appeals made by the employees in 

case of CCA 

12. The system should support searching of case by employee number, employee 

name, grievance ID number etc. 

13. The system should have the ability to generate required Formats and Letters 

14. The system should have the ability to generate list of open/pending/closed 

cases at any point of time. 

15. The system should have the provision to key in the date of explanation called 

for and the reply with reference (date). 

16. The system should have the provision for recording grievance proceedings 

automatically and affect compensation/ progression as per decision on the 

grievances 

17. The system should capture/track if employee has filed appeal against the 

decision of CCA in any case 

18. The system should have the ability to generate forwarding letter for 

investigation of cases 


Attachment B 


19. The system should have the ability to key in investigation officer’s name and 

it’s SR No., Posting etc confidential. 

20. The system should have the ability to capture investigation report (by date). 

21. The system should be able to generate List of Pending 

Investigation/grievances/appeal cases Report. 

22. The system should have the facility to close the case and upload 

report/decision in the system. 


Attachment B 


2.12 Departmental Enquiry 

Table 74: Functional Requirement Specification - Departmental Enquiry 

Business Requirement: Department Enquiry 


1. The system should generate ID when a DE is proposed in the system. The 

unique ID for each case maintain case history with essential data like: 

• Employee ID 

• Category of charge (Major/Minor) 

• Show-cause issued 

• Employee reply received 

• Charge sheet issued 

• Employee reply received 

• Brief description about the charge 

• Date and number of charge sheet 

• Status 

• Last decision 

2. MP Civil Service: Conduct rule and CCA rules shown in master for all user 

3. The system should maintain all online records of departmental enquiry. 

4. The system should allow users to define the categories of misconducts and 

rules under which DE could be initiated. 

5. The system should have standard forms and letters in the workflow for 

important communications 

6. The system should allow authorized users to upload show-cause notice & 

charge-sheet against an employee 

7. The system should allow employee against whom DE is instituted to upload 

replies, representations to CCA 

8. The system should generate alerts if SLAs defined for each activity in the 

process are not followed 

9. The system should generate statement of pending cases on a monthly basis 

which describes the status of the cases. 

10. The system should allow user to file appeal against the decision of a case. 

11. The system should track the number of appeals made by the employee. 

12. The system should support searching of case by employee number (ID), 

employee name, case number (ID) etc. 

13. The system should have the ability to feed the data of warnings/ 

displeasures/ censures communicated to the employee or exoneration in the 

DE cases. 

14. The system should have the ability to generate list of opened/pending/closed 

cases. 


Attachment B 


15. The system should have the ability to feed ‘Suspension cases/Police, 

Lokayukt, EOW Cases/Sanction for prosecution cases (with details of date of 

suspension, etc) 

16. The system should have the ability to generate letters/Orders pertaining to 

Suspensions/ Revocation of suspensions. 

17. The system should have the ability to record details of date of 

Suspensions/date of revocation of suspension/ misconduct / cause of 

suspension/treatment of period of suspension with communication to related 

module (Payroll Processing, Employee Database). 

18. The system should have the ability to communicate details of compulsory 

retirement, termination or dismissal as a result of disciplinary proceedings to 

employee exit module 

19. The system should have the provision to key in the date of explanation called 

for and the reply date. 

20. The system should have the provision for recording DE proceedings should 

automatically effect compensation/ progression as per decision of DE 

21. The system should have the ability to key in investigation officer’s name and 

SR No., Posting etc in case of pending Police, Lokayukt, and EOW 

investigation. 

22. The system should have the ability to capture investigation report date. 

23. The system should be able to generate List of Pending Investigation Report. 

24. The system should have the facility to close the case. 

25. The system should have the ability to generate FIR if DE results in need for 

prosecution under CRPC. 


Attachment B 


2.13 Employee Exit 

2.13.1 Employee Exit - Superannuation 

Table 75: Functional Requirement Specifications - Employee Exit: Superannuation 

Business Requirement: Employee Exit – Superannuation 


1. The system should generate employee wise terminal benefit calculation sheet 

for each type of benefit. 

2. 

The system should prepare the final settlement advise to Accounts from HR. 

3. The system should maintain a record of the amount payable / receivable 

from exiting employee. 

4. The system should generate the relieving letter for an employee. 

5. The system should generate the Salary certificate (LPC) for an employee / 

ex-employee. 

6. The system should maintain an ex-employee account. 

In case amount is receivable from an employee, the system should maintain 

an account of the amount due and reflect any changes therein. 

7. The system should generate letters for communication on the amount due 

from the employee (e.g. three electronically generated reminders in last two 

months). 

8. In case an employee has been given an additional charge, the system should 

be able to maintain the record for the same with relation to skill set & the 

portfolio assigned to the employee. 

9. 

The system generates retirement orders. 

10. The system should stop GPF deductions 4 months prior to retirement date 

of employee. 

11. On the exit of an employee, the system should generate a letter for informing 

the Bank of the same. 


Attachment B 


2.13.2 Employee Exit: Other Exits (Death, Termination, VRS and 

Resignation, Compulsory retirement and Absorption/ Samvillyan) 

Table 76: Functional Requirement Specification - Employee Exit: Other Exits (Death, Termination, 

VRS and Resignation, Compulsory retirement and Absorption/ Samvillyan) 

Business Requirement: Employee Exit : Other Exits (Death, Termination, VRS and 

Resignation, Compulsory retirement and Absorption/ Samvillyan) 


1. In case employ exit, the system should generate the Clearance Certificate for 

the employee & electronically route it through workflow. System updates the 

employee records accordingly with the employees date of leaving 

2. The system should required exit orders for employees’ exit 

3. The system should generate employee wise terminal benefit calculation sheet 

for each type of benefit 

4. The system should prepare the final settlement advise to Accounts from HR 

5. The system maintain a record of the amount payable / receivable from 

exiting employee 

6. The system should generate the Salary certificate for an employee / exemployee 

7. The system should maintain an ex-employees account 

8. In case amount is receivable from an employee, the system should maintain 

an account of the amount due and reflect any changes therein 

9. On the exit of an employee, the system should generate a letter for informing 

the Bank of the same 


Attachment B 


2.14 Court Cases 

Table 77: Functional Requirement Specification - Court Cases 

Business Requirement - Court Cases 


1. The system should submit the verdict and action plan concerned authority 

2. The system should keep record of legal issues. 

3. The system should Allocate unique case tracking number. 

The system should generate reports at regular intervals which are submitted 

4. for review on line to concerned officers 

5. The system should provide for generation of orders of PO’s appointment 

The system should manage particulars of all the relevant constituents and 

6. parties involved in a case. 

The system should efficiently manage the process, path and milestones as the 

7. case progresses to final outcome 

The system should generate alerts for all concerned at important stages of 

8. case progress (reply/evidence/hearing/verdict) 

The system should allow multiple channel access to those managing the case 

9. and provide information to those named as party in the case 

The system should manage all types of documentation or their references 

10. associated with the case 

The system should facilitate/manage all types of correspondence associated 

11. with the case 

The system should manage all interaction associated with the case including 

12. the Legal Case History 

The system should closely integrate with all the other modules of the 

application like Human Resource, IFMIS and Pension for implementation of 

13. the case/action plan on verdict. 

The system should facilitate interdepartmental case handling, knowledge 

sharing and promote accountability 

14. 

15. 

16. 

17. 

18. 

The system should provide a centralized repository of all cases related 

information, which is available to users based on their role in the 

organization. 

The system should facilitate search through structure and unstructured 

content in the repository 

The system should allow users to share sensitive information and allow users 

to access only those information based on their role/SLA that they need to 

perform their tasks 

The system should allow user to use the custom attributes to capture 

information across all cases or cases of a specific type as well as be used as 

criteria when searching for cases 


Attachment B 


19. 

20. 

21. 

The system should allow categorization of cases (Active/ Inactive) for future 

references in centralized repository 

The system should publish frequent areas of disputes and possible resolutions 

in KM 

Appropriate approval/implementation workflows should be built into the 

system 


Attachment B 


2.15 Pension Management Information System 

Table 78: Functional Requirement Specification- Pension Module 

Business Requirement – Pension Module 

S. No Description 

Regular Pension Payment Release 

The system should be able to generate pension payment schedules as per 

1. class/category/chargeability. 

The system should be able to calculate entitlements, recoveries and net 

2. payable and generate pension bills. 

The system should allow users to define the Rules for separation – 

3. • Class/Category/Chargeability 

The system should capture Nomination Information like Nominee Details, 

4. Percentage, Relationship, Guardian Information for minors etc 

System would be able to forecast exact pension liability of GoMP based on 

5. current status/trend analysis for relief enhancement for any given period. 

System would be able to calculate the pension payment share (e.g. between 

6. MP and Chhattisgarh) 

The system should automatically calculate all the dependent components in 

7. the Pension, as per GoMP regulation 

The system should make available security controls to limit access to 

8. specified personnel. 

System should allow viewing of data as per employee / pensioner on line by 

9. those permitted access. 

The system should have an interface with Disbursement and accounts 

10. module to transfer the pension related information. 

The system should be flexible enough to provide and restrict access to tasks 

11. between users of Pension, HR and Finance according to the requirement. 

12. The system should up load data / interact with other modules as required. 

The system should allow the display of only selected menu options/ forms 

13. based on the role of the user 

14. The system should upload pension history data 

15. The system should view pay related details via reports and queries 

The system should monitor regular pension cycle from data entry to fully 

16. reconciled results 

17. The system should view complete history of pension payroll results 

Workflow and logic will be built into the system i.e. system will be 

programmed to handle activities like: 

18. • Reducing the family pension automatically after the stipulated time 


Attachment B 




19. 

20. 

21. 

22. 

23. 

24. 

25. 

26. 

27. 

• Timely stoppage of the deductions of commuted portion 

automatically 

Web based facility will be built into the system so that banks can upload 

scans of life certificates / finger prints / death certificate / change request 

(for e.g. pension to family pension) / transfer submitted to them by 

pensioners. Link will be built into the system so that pension department will 

be able to view whether a pensioner has submitted Life certificate. 

System should be able to generate alerts and exception reports where excess 

funds have been released to the Central Record Keeping Agency. 

Report to be generated for any new addition / deletions in the pensioners 

and also reason why the number may have changed. E.g. in month 1, the 

system reports 100 pensioners. In Month 1, the system reports that 12 

pensioners have dropped out (expired) and 6 new pensioners have come in. 

In such cases, the system should allow business intelligence features i.e. 

“drill-down” reporting so that DPPFI can view summary details of these 

changes to pensioner database as well as pull up details of individual 

pensioners. 

Repository of Pension rules and subsequent amendments in the rules will be 

handled by the system through KMS (Knowledge Management System). All 

circulars related to pension will be available online and can be accessed 

anytime 

Authority map / alerts checks / exception reports / logins / escalation 

matrix etc. which will be built into the system 

In case of Anticipatory pension, if PPO is generated system will block 

Anticipatory pension payment and vice versa. Where anticipatory pension 

has been granted because of an event like a court case on pay scale issues for 

that employee, system should allow retrospective calculation of pension 

payment schedule and any adjustments for excess payments once the court 

takes a decision on the applicable pay scale 

The system will handle record keeping through Document Management 

System 

The system should mark erroneous calculations for retry while keeping 

reconciled calculations intact 

The system should automatically detect the changes made in the past that 

would impact pension and run retro pay for those pensioners 

28. The system should calculate an individual’s payment online 

29. The system should update balances immediately upon calculation 

The system should maintain complete taxation rules defined as part of the 

30. pension structures configuration 


Attachment B 




31. 

32. 

33. 

The system should generate reports / certificates (user defined format with 

reference number) 

The system should handle exemptions and rebates as per the Income Tax 

Rules 

The system should generate automatically pensioner returns in pdf or any 

other format 

34. The system should display the status of the Pension calculations 

The system should run Pension Calculations multiple times before 

35. finalization to ensure accurate pay computation 

36. The system should make deduction amounts negative 

The system should determine deduction amounts by amount and percent of 

37. earnings 

38. The system should record Statutory Information & generate Reports 

39. 

The system should automatically update Pension database for changes in 

pensioner record without interfering with pension processing (e.g. pensioner 

status change in the middle of month, etc) 

40. The system should make Back dated calculations 

41. The system should maintain individual pensioner’s ledger 

Pension Grievance 

42. The system should generate grievance form. 

43. The system should allocate unique number for grievance tracking. 

44. The system should generate periodic reports for the grievances addressed. 

45. The system should keep record of grievance redressal status. 

46. System should support online transfer of documents among departments 

System should support online approvals as per the matrix defined in the 

47. system 

48. The system should keep record of pensioner grievance filed. 

49. The system should allow users to define the categories of misconducts. 

System should generate unique ID for each case and maintain case history 

with essential data like: 

• Pensioner ID 

• Brief description about the grievance 

• Date of grievance filed 

• Status 

50. • Last decision 

The system should generate statement of pending cases on a monthly basis 

51. which describes the status of the cases. 


Attachment B 




52. The system should allow user to file appeal against the decision of a case. 

The system should have online availability of grievance redressal case along 

53. with status, responsibility matrix, SLAs 

Escalation Matrix will be defined in the system to outline procedures to deal 

54. with various categories of complaints depending on their priority. 

At the point of data entry, system should allow the operator to select the 

55. category and priority of the complaint from drop-down menus. 

The system will also have a manual override facility for senior officials at 

DPPFI. Through this, senior authority can assign a high or low priority to a 

56. grievance, regardless of the priority assigned to it initially. 

A log file will be maintained in the system of the documents collected. Status 

of whether the requested documents have been received will also be 

57. updated. 

Pensioner will be able to log in with his pensioner ID and check the status of 

his/her complaint and what documents remain to be collected for further 

58. processing 

The system will allow an option of “Further Correspondence” for a 

particular complaint/grievance ID. Any letters/memos drafted by the 

dealing official in that case has to be uploaded against that ID. Whether 

59. uploaded or not, system will maintain audit trails at all organizational levels 

System can also give a list of complaints pending for sometime and the 

director will have manual override facility of the severity to change the action 

60. plan 

System alert will be generated in case a complaint has not been resolved 

61. beyond a defined response time 

62. Role based Grievance handling will be built into the system 

63. The system should have required online workflow for grievance redressal 

64. The system should track the number of appeals made by the pensioner 

Pension Revision 

65. The system should identify pensioners/cases for revisions of pension 

The system should enable revisions to take place automatically including 

66. pension revision and relief enhancement (through masters modifications) 

The system should inform pensioners on revisions and related 

67. arrears/recoveries through E mail / sms / post 

There shall be a link with repository of rules, so that all the latest as well as 

68. old circulars are available at one point. 

The system shall identify “NO Change” cases and record this in the history 

69. sheet of the case. 

Alerts should be generated to the respective authoriries in DPPFI in case a 

70. pensioner requests to change to family pension, etc. 

71. The system should allow pensioner to be informed about the status of 

revision through a web based facility. 


Attachment B 




revision through a web based facility. 

72. The system should update pensioner data 

Pension Database Management 

The system should interact with HR Module to receive list and records of 

73. new pensioners and pension revisions 

The system should update pensioner details based records received from 

74. HRMIS 

75. The system should upload all the scanned relevant documents of pensioners 

The system should permit user / retiree to upload/modify his data like 

• Address 

• Bank account number 

• Email id 

• Phone Number 

76. • Nominee Details 

The system should generate emails/sms on uploading/modification of data 

77. to related 

78. The system should have a common pensioner database 

The system should allow concurrent user access to the database and 

79. maintain data integrity 

The system should at the same time, allow different users to have access to 

80. different data fields all mapping into the common pensioner database 

The system should generate & record unique Identification number for the 

81. pensioner 

82. The system should allow pensioner's to view their own records 

83. The system should allow pensioner's to edit their own relevant records 

The system should allow evaluation and prioritization of the database on 

84. user defined criteria 

The system should maintain history of each pensioner (grievances etc.) and 

85. display / generate reports of the same 

The system should allow users to define their own data fields / custom 

86. reports 

The system should check Departmental Dues/outstanding loans/ 

87. Government assets (if any) assigned to employee 

The system should calculate the pension payout schedules/bills as per the 

class/category/ chargeability and any other parameter of separation of one 

88. (type) of claim from other 

89. The system should maintain pensioners ledgers 


Attachment B 


3. Citizen’s Grievance Redressal 

Table 79: Functional Requirement Specifications – Citizen Grievance Redressal 

Business Requirement – Citizen Grievance Redressal 

Sr. No. 


1. Should allow a fresh user to register over the application as: 

• Individual complainant 

• Kiosk operators (CSC) 

• Call Centre Official (to be set up by SI) 

• Front desk operator (at DoF Level) 

2. Should be able to provide information to the citizens about details related to 

grievance filing process 

3. Should register the grievance in either of two categories i.e. 

• Fresh Grievance 

• Grievance Escalation 

4. The application should be connected to the ration card or any other database 

that is identified through a unique ID. The application should be registered 

only after the applicant’s credentials have been cross checked with the 

available database. 

5. Should be able to generate a unique registration number during registering an 

applicant with the application. Should be able to identify the applicant 

uniquely based on this registration number. 

6. Should allow the complainant to attach files in picture / document / .pdf / 

video / audio and other formats along with the grievance complaint 

7. Should be able to issue an acknowledgement receipt once the applicant is 

registered with the system. The acknowledgement receipt should have the 

following details: 

• Grievance registration number 

• Fresh grievance / grievance escalation 

• Grievant name 

• Detail of grievance 

• Amount paid 

• Expected date for obtaining solution 

• Other registered details (e,g. mobile number, email etc.) 

8. Should be able to mark the application to the Receiving Official for grievance 

redressal 

9. Should allow the Appellate Official to reject any frivolous grievances using the 

rejection component. 

10. Should be able to help the Appellate Official to assign Field Official to take 

action on the filed grievance 

11. Should allow the Field Official to upload field report over the system 


Attachment B 


12. Should maintain records of all the grievances filed through the grievance 

redressal system for a particular period of time 

13. Should allow the Appellate Official to review the Field Report online in a pre 

defined format 

14. Should allow the Applet Official to upload the Action Taken Report over 

application in a pre defined format 

15. Should be able to store soft copy of Action Taken Report (ATR) in database and 

generate trigger for Front Office Executive / Applicant that the certificate 

has been prepared and he can take a printout of the same. The trigger should 

be generated to all the registered mediums such as Mobile (through sms), 

email, status updation over the application 

16. Should be able to auto generate grievance to higher authorities in case specified 

SLAs are not met by the officials as per the auto escalation mechanism 

17. Should generate monitoring reports on specified time intervals and send it to 

relevant authorities 

18. Should allow stakeholders to track the application status at different pre defined 

stages. 

19. Should provide access to authorities to monitor Application Status / 

Performance / SLAs for a particular period by logging onto the system 

20. Should provide user the facility to return back to the previous page / edit any 

information before submission of final information 

21. Should allow the user to view the grievance redressal through any of the 

registered mediums i.e. Mobile, Email, Online 

22. Should request the user to provide the grievance registration number / 

applicant’s name / any other unique id for obtaining solution 

23. Should provide user a print preview before taking a printout 

24. Should allow user to take a print out of the soft copy of the Action Taken 

Report as per the delivery component 

25. Should provide a site map at the opening page of the application 

26. Should be able to send SMS to applicant in case of missing of final SLAs and 

status tracking. 

27. Should provide link to State Vigilance/Audit System to escalate citizens’ 

complaints, and enquiry report thereof, related with financial 

irregularities/corruption/fraud/misappropriation in public 

services/departments 


Attachment B 


4. General System requirements 

Several Enterprise-wide Usability and Workflow aspects of the IFMIS will be central to the 

realization of business process improvements identified by the functional requirements 

analysis (FRS). This section summarizes these system-wide requirements, which advance the 

goals described below. 

Sr. No. Technical Area Requirement Description 

1. Enterprise-wide 

Usability 


Usability 

The system shall provide functionality to enable all 

incomplete transactions or records to be saved, at any stage, 

for completion at a later time. The system should auto save 

all the transactions after each stage. 

The system should provide secured login to the system 

through the following ways: 

• Biometric thumb impression devise 

• Secured user name and login 


Usability 


Usability 

The system should generate alerts for password renewal on 

every 15 days. The password should allow alphabets, 

numbers, and special symbols. 

The system shall provide functionality for users to attach to 

any transaction, multiple electronic files (documents and 

images), without restriction to size, including, but not 

limited to: 

• Scanned receipts 

• Supporting documentation 

• Scanned image (e.g., drawings, bulletins) 

• Amendment to a contract 

The system shall provide functionality to accommodate a 

common graphical user interface including, but not limited 

to: 

• Pull-down menus 

• Spell checking 

• Ability to find, replace, and go-to within a 

transaction 

• Keyboard equivalent for all menu options 

• Use of mouse for all commands 

• Scrollable list boxes 

• Radio Buttons for selecting option from multiple 

options 

• Cursor selection of items in scrollable list boxes 

• Multiple windows that may be open at the same time 

• Windows that can be minimized and maximized 


Attachment B 



• Built-in charting on all standard inquiries 

• Dropdown menu list of open windows 

• Ability to print windows or entire screens in a "user 

friendly" print format 

• Print preview of each transaction 


Usability 


Usability 


Usability 


Usability 

The system shall provide an online help facility with 

capabilities including, but not limited to: 

• Window level help 

• Field level help 

• Error message help 

• Context sensitive help 

• Windows hypertext help i.e. an internet based search 

• Indexed help 

• Definable coaches, wizards, or tutors 

The system shall provide functionality for users to establish 

a descriptive profile for the State's organizational hierarchy 

containing information including, but not limited to: 

• Organizational addresses 

• Contact information 

• User-defined fields for supplemental information 

The system shall provide functionality to integrate (exchange 

data) with MS-Office software including, but not limited to: 

• Excel 

• Word 

• Access 

• MS – Outlook 

• MS – Project 

The system shall provide functionality for users to view 

attachments in multiple formats of common software 

programs including, but not limited to: 

• Excel files 

• Word files 

• PowerPoint files 

• Visio files- PDF files 

• Notepad files 

• Jpeg files 

• HTML files 

• Lotus 1-2-3 files 

• Tiff Files 


Attachment B 




Usability 


Usability 


Usability 


Usability 


Usability 


Usability 

• BMP files 

The system shall provide functionality for users to both 

upload data and export data from integrated / interfaced 

project management software 

The system shall provide functionality for users to 

customize aspects of their screen layout including, but not 

limited to: 

• Establish custom menus 

• Establish custom "go-to" buttons 

• Color choices 

• Font formatting 

• Fields displayed 

• User specific default values 

• Customizable toolbars 

The system shall provide functionality to clearly display the 

mandatory / optional data entry fields 

The system shall provide functionality for users to view 

multiple screens simultaneously while maintaining data and 

session integrity 

The system shall provide functionality to terminate a session 

after a pre-determined period of inactivity 

The system shall provide functionality to accommodate 

multiple delivery options for all system generated documents 

(e.g., vouchers, invoices, purchase orders, contracts) 

including, but not limited to: 

• Letter (printed for mailing) 

• Email 

• Web posting 

• Electronic Data Interchange (EDI) 

• Fax 

• Extensible Markup Language (XML) 

• Email attachment (spreadsheet or word processing 

document) 

• SMS 

• IVRS based messaging 


Usability 

The system shall provide functionality to fully integrate with 

email software such as Microsoft Outlook Lotus Notes, and 

GroupWise capability 

16. Enterprise-wide The system shall provide functionality to support the 


Attachment B 



Usability creation and use of electronic & digital signatures 


Usability 

The system shall provide functionality to apply multiple 

electronic signatures & digital to a document or transaction 


Usability 

The system shall provide functionality to validate and 

revalidate electronic & Digital signatures. Should support 

PKI (Public Key & Private Key) enabled transactions in case 

of digital signatures. 


Usability 

The system shall provide functionality to maintain a record 

of electronic & digital signature validation in combination 

with the associated electronic document or transaction 


Usability 

The system shall provide functionality for users to create 

transactions for a fixed or percentage allocation amount 

among multiple account codes 


Usability 

The system shall provide functionality for users to pull 

forward account distributions and other information from 

referenced documents (i.e. accounting codes from purchase 

order are pulled forward to any voucher that references the 

original purchase order) 


Usability 

The system shall provide functionality for users to edit saved 

and posted transactions/documents 


Usability 


standard validation on all input fields including, but not 

limited to:- Data type validation- Range validation- Format 

validation 


Usability 

The system shall provide functionality for users to copy 

previously saved transactions to a new transaction 


Usability 

The system shall provide functionality for users to perform 

mass updates to create, change, or delete selected fields 

across multiple records 


Usability 

The system shall provide functionality for users to establish 

and use quick codes (i.e. a short code pulls forward an 

associated accounting distribution) to add account number 

information to transactions 


Usability 

The system shall provide non-mandatory user-defined fields 

for the purposes of entering miscellaneous data into a 

transaction 


Usability 

The system shall provide functionality for either a systemassigned 

unique number or a user-defined unique number 

for each transaction or document created in the system 

including, but not limited to the following: journal entries, 

including cost allocations, Vouchers, Invoices, Purchase 

orders, Grants, Requisitions, Assets, system, and tag 

generation, Projects 

29. Enterprise-wide The system shall provide programs with reports to enable 


Attachment B 



Usability 


Usability 


Usability 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 

users to purge system data in any of the modules 

The system shall provide functionality for users to print the 

entire contents of any screen in a printable format 

The system shall provide functionality to comply with the 

accessibility requirements regarding accessibility of State 

web based applications specified in GoMP IT Policy or 

other GOs instructions in this regards, if any 

The system shall provide functionality to launch the system 

from within a workflow message or notification email. 

The system shall provide functionality to implement end to 

end business process workflows that extend to external 

systems 

The system shall provide functionality to route electronic 

documents through a workflow and allow or disallow 

document editing at each workflow stage. 

The system shall provide functionality to define lead and lag 

times between activities 

System should generate messages for both successful and 

unsuccessful transactions. As soon as a transaction is 

complete an email through the defined workflow system 

should be generated for the concerned stakeholders. 

The system shall provide functionality to define 

dependencies between activities in a workflow 

The system shall provide functionality to maintain an audit 

trail of the transaction review and approval that occurred 

during an automated workflow. 

The system shall provide functionality to perform 

transactions and other workflow functions via a portal 

interface. 

The system shall provide functionality to perform workflow 

functions via a PDA or any mobile interface. 

The system shall provide functionality for configurable 

rules-based automated notifications including, but not 

limited to: 

• System alerts (e.g., pop-up windows) 

• Automatically generated emails with variable 

narrative or appropriate web links 


rules-based automatic notifications on events including, but 


• Pending approvals on a system transaction 

• Aging of open invoice status 

• New budget version availability or release 


Attachment B 




Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 


Workflow 

• Status of prompt contracting calendar 

• Collection of overdue debts 

• Key milestone dates in RFP/contract process 

The system shall provide functionality for business partners 

to access the system from a remote location using webbased 

self-service functionality and search for information 

including, but not limited to: 

• Order status 

• Payment status 

• Grant information 

• Transaction history 

The system shall provide functionality to support the 

establishment of workflow by transaction type including, but 


• Requisitions 

• Purchase orders 

• Contracts 

• Contract change orders and amendments 

• Lease renewals 

• Vouchers 

• Budget adjustments based on cross appropriation 

level of detail 

• Inter-agency transactions 

The system shall provide a reporting and/or inquiry tool 

that can report on the status of the transaction moving 

through workflow 

The system shall provide functionality for users to define 

time thresholds or parameters for each activity in a 

workflow 

The system shall provide functionality to enable users to 

define the sequence of activities that constitute a workflow 

transaction 

The system shall provide functionality to enable users to 

define concurrent activities within a workflow transaction 

The system shall provide functionality to support both 

sequential and concurrent approval processing in each 

module, based on predefined user configuration 

The system shall provide functionality for users to delegate 

approval authority for a defined time-period (e.g., vacations) 


Attachment B 



5. Web Portal 


Business Requirement – Web Portal 

Sr. No. Requirement Description – Web Portal 

1. 

Attachment B 

Should allow the 

Functional 

administrator 

Requirement 

to define 

Specifications 

the user ids and passwords for various set 

of Department users, he should be also able to assign various roles / tasks / 

privileges with these id’s and passwords. 

2. Should allow the Administrator to delete any accounts 

3. Should host the following contents on the main page: 

• Information about the Department of Finance 

• Department Chart 

• Organization Locator 

• Citizen Charter 

• Codes / Rules 

• Circulars / Notifications 

• FAQ 

• List of services served by the portal to citizens (indicative list will be) 

o Payment of bills and taxes 

o Grievance Redressal 

o RTI 

o Audit Reports & feedback thereof 

o Feedback on public projects/programmes/services 

outputs/outcomes/impacts 

o Specific opinion poll – response to 

o DoF offices and locations 

o Tenders 

o Links to other related websites 

o Stakeholder type through a drop down box (DDO, BCO, HoD, 

Admin Unit Head, PRI, ULB, Banks, AGMP, DoF, DTA, DoP, 

Works Department, Employee, Pensioner, Citizen etc.) 

• Login section for different stakeholders/services 

• State Budget and supplementary budgets 

• State’s Plan 

• Search Option (Internal & External) 

• Link to Training Manuals (both in Hindi / English) 

• Link to Online Tests 

• Help 

• Conversion to Hindi / English tab 

• Site Map 

• Contact Us 

• Downloads 

• Disclaimer 

4. Should allow the non department users to register themselves on the portal. In the 

case of Employees and Pensioners the user ids need to be mapped with employee 

and pensioner id. 

5. Should allow the various users to select their user type. Once the user has clicked on 

the user type he should be forwarded to the particular login page where he would be 

requested to submit his login in credentials. 

6. For first time non department users the system should provide the functionality to 

register themselves on the portal. Whereas for the registered users (both department 

and non department) on successful login should forward the users to the individual 

Department page of Finance, type depending GoMP upon the category to which the stakeholder belongs to. 191 

7. For the department users there should be a dual factor authentication provision for 

logging in to the application. Once the department user (DDO, BCO, HOO, DoF 

Officials) selects their category they would be transferred to their individual login

Attachment B

RFP for Integrated Financial Management ... - Mptreasury.org

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?