RFP for Integrated Financial Management Information System · 1.4 State Receipts Management System ... 2.12 Departmental Enquiry ... Functional Requirement Specification

Department of Finance, GoMP 1

RRRFFFPPP fffooorrr IIInnnttteeegggrrraaattteeeddd FFFiiinnnaaannnccciiiaaalll MMMaaannnaaagggeeemmmeeennnttt IIInnnfffooorrrmmmaaatttiiiooonnn SSSyyysssttteeemmm

AAAttttttaaaccchhhmmmeeennnttt BBB

FFFuuunnnccctttiiiooonnnaaalll RRReeeqqquuuiiirrreeemmmeeennnttt SSSpppeeeccciiifffiiicccaaatttiiiooonnnsss

DDDeeepppaaarrrtttmmmeeennnttt ooofff FFFiiinnnaaannnccceee GGGooovvveeerrrnnnmmmeeennnttt ooofff MMMaaadddhhhyyyaaa PPPrrraaadddeeessshhh

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



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



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



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



• 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



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

• Cost Incurred 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



• 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

• Project ID

• Activity ID

• Activity List

• Current Status of activity

• Pending activities

• Milestones

• Budgeted Estimate

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

pending activities




• 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 57. Should make the revised estimate forms available online


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



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



1.1.2 District Plan Preparation

Table 2: Functional Requirement Specification - District Plan Preparation

Business Requirement – District Plan Preparation


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

• Cost Estimates

• Justification

• Combined Priority including MTEF requirements

• Implementation details of on-going projects 8. Should provide an option to DPC to drill down to the complete details of each

project

• Project List

• New or Rolling Project

• Cost associated with new Project

• Cost associated with ongoing projects

• Priority of Project



• Probable start date

• Outcome of Project

• Activity List

• Cost Breakdown of activities

• Brief Description

• Duration of project

• Start Date

• End Date

• Implementation details of on-going projects 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

• Project List

• 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)

• Project ID



• Activity ID

• Desired output

• Lowest cost



1.1.3 State Plan Preparation

Table 3: Functional Requirement Specification - Sate Plan Preparation

Business Requirement – State Plan Preparation


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 projects including district plan

5. Should allow HODs to consolidate the yearly requirements for new and existing projects including district plan

6. Should compile the draft state plan having following details

• Locations

• Project Name

• Duration

• Outcomes

• Cost Estimates

• Justification

• Combined Priority including MTEF requirements

• Implementation details of on-going projects 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

• Project List

• Priority

• Impact/Outcome of Projects

• Cost associated with the project

• Projects under implementation



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



1.1.4 Receipt Budget Table 4: Functional Requirement Specification – Receipt Budget

Business Requirement – Receipt Budget


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



1.1.5 Plan Budget Preparation

Table 5: Functional Requirement Specification – Plan Budget Preparation

Business Requirement – Plan Budget Preparation


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

• Project Name

• 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)



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


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



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



1.1.7 Non Plan Budget Preparation

Table 7: Functional Requirement Specifications – Non Plan Budget Preparation

Business Requirement – Non Plan Budget Preparation


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 in-line 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



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



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



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


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



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



1.1.9 Budget Management

Table 9: Functional Requirement Specification – Budget Management

Business Requirement – Budget Management


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



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 re-appropriation

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



• Justification

• 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



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



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

• Account Head

• Plan Component

• Non Plan component

• Budget Estimates

• Revised Estimates

• Revenue/Capital Section



1.1.10 Budget Consolidation

Table 10: Functional Requirement Specification – Budget Consolidation

Business Requirement – Budget Consolidation


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 non-plan 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



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



1.1.11 Payment of Advance from Contingency Fund

Table 11: Functional Requirement Specification – Contingency Account

Business Requirement – Contingency Account


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



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


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



1.1.13 Public Fund Account

Table 13: Functional Requirement Specification – Public Fund Account

Business Requirement – Public Fund Account


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



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



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



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


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



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



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



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



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



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



1.2.2 Asset Account Management

Table 16: Business Requirement - Asset Accounts Management

Business Requirement – Asset Account Management


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





(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:





• 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

• Department

• 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)





24. The system shall provide functionality to automatically update the general ledger (GL) to capitalize any asset acquired through the disbursement module

25. The system shall provide functionality to automatically update the general ledger 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)



1.2.3 Creation of Purchase Order

Table 17: Business Requirement Specification - Create Purchase Order

Business Requirement – Creation of Purchase Order


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

• Description

• 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





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

• Commodity code

• 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





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

• Commodity code

• Description

• 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





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



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


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 on-hand 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



Business Requirement –Manage Receipts of Goods and Services


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



1.2.5 Project/Contract Creation

Table 19: Functional Requirement Specification – Project creation and Updation

Business Requirement – Project /Contract Creation


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



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



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



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



1.2.6 Project/Contract Management

Table 20 : Business Requirement Specification - Project/Contract Management

Business Requirement – Project Management


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



12. Should make the revised estimate forms available online


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



1.2.7 Contractor Bill Clearing

Table 21: Business Requirement Specifications- Contractor Bill Clearing

Business Requirement – Contractor Bill Clearing


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



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



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



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.



1.2.8 Advance Payment to Contractors

Table 22: Functional Requirement Specifications – Advance Payment

Business Requirement – Advance Payment to Contractors


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



• 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



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



1.2.9 Works Contingency Expenses

Table 23: Functional Requirement Specifications – Works Contingency Establishment Expenses

Business Requirement – Works Contingency Establishment Expenses


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



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 & work-charge 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



1.3 Debt & Investment Management Table 24: Functional Requirement Specifications – Overall Debt Management System

Business Requirement – Overall Debt Management System


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 paper-based 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 sub-accounts 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.



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



1.3.1 Raising Market Borrowings

Table 25: Functional Requirement Specifications – Raising Market Borrowings

Business Requirement – Raising Market Borrowings


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



1.3.2 Repayment of Market Borrowing Table 26: Functional Requirement Specifications – Repayment of Market Borrowings

Business Requirement – Repayment of Market Borrowings


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



state.



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


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

• Loans from Financial Institutions 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

6. Should be able to generate a resource chart with the help of the system *

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



• 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

• Loan Duration



• Loan Installment Period


• Account Details of Financial Agency for loan repayment 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



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


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 Duration

• 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



9. Should update the loan account automatically

10. Should update the State Liabilities Account





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


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 be allowed to fill and upload:



be allowed to fill and upload:

• 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:



• Interest Rate

• Loan Duration

• Loan Installment Period


• Account Details of Financial Agency for loan repayment 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



Requisition would contain the following details:

• Loan ID



• Loan Duration

• 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




1.3.6 Obtaining Central Government Loans/Grants

Table 30: Functional Requirement Specifications – Obtaining Central Government Loans / Grants

Business Requirement – Central Government Loans / Grants


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

• Loans from Financial Institutions 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 5. Should be able to generate a resource chart with the help of the system *

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





1.3.7 Central Government – Loan Repayments

Table 31: Functional Requirement Specifications - Central Government Loan Repayments

Business Requirement – Central Government Loan Repayments


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 Duration

• 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



15. Should update the DMS and the State Liabilities Account





* Resource Chart Preparation Table 32: Functional Requirement Specification: Resource Chart Preparation

Business Requirement – Resource Chart Preparation


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



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


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



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 amount (in foreign currency) o Loan equivalent in Indian currency o Interest rate for first 6 months o Penal interest rate o Repayment period o Repayment conditions in words o Repayment period start date 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 Scheme / project name 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



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



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 Loan amount (in foreign currency) o Grant Demand no. and other head details o Interest rate o Repayment period (generally 20 years) o Repayment period start date 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 o Scheme / project name o Loan amount (in foreign currency)



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



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


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



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 o Penal interest rate

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.



1.3.10 Recording of Guarantees

Table 35: Functional Requirement Specifications - Recording of Guarantees

Business Requirement – Recording of Guarantees


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

• Loan Duration

• Interest Rate 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



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)



1.3.11 Updation of Guarantees Table 36: Functional Requirement Specification - Updation of Guarantees

Business Requirement – Updation of Guarantees


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



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



1.3.12 Government Investments

Table 37: Functional Requirement Specifications – Government Investments

Business Requirement – Government Investments


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



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


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



• 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



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



• 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



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



1.5 Treasury Disbursement System

1.5.1 Treasury Disbursement System

Table 39: Functional Requirement Specifications – Treasury Disbursement System

Business Requirement – Treasury Disbursement System


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:





• 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



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



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



1.5.2 Financial Sanctions Table 40: Functional Requirement Specifications – Electronic Financial Sanctions

Business Requirement – Electronic Financial Sanctions


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



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



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


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

• Department

• 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



14. System should notify Admin Dept /HOOs/ Operator after the approval is received from AG



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


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



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



1.6.3 Revenue Deposits

Table 43: Functional Requirement Specification – Revenue Deposits

Business Requirement – Revenue Deposits


1. Should provide related rules in the system

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



1.6.4 Civil Court Deposits

Table 44: Functional Requirement Specification – Court Deposits

Business Requirement – Court Deposits



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:

• Account Head



• 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



• HOA details (system generated)



1.6.5 Local Fund Deposits

Business Requirement – Local Fund Deposit


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



1.6.6 Lapsed Deposits

Table 45: Functional Requirement Specification – Lapsed Deposits

Business Requirement – Lapsed Deposits



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 1st 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

31st 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 –



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



1.6.7 Refund of Lapsed Deposits

Table 46: Functional Requirement Specification – Refund of Lapsed Deposits

Business Requirement – Refund of Lapsed Deposits



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)

• HOA details

• 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

• HOA details

• Sanction Number

• Sanction Date

• Sanction Authority 11. System should trigger a notification to AG/Competent Authority for seeking

confirmation on the refund request



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



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



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:

• Sanction Number

• Sanction Date

• Sanction Authority

• HOA

• Original credit/receipt

6. Should capture the following details for refund bill:

• Sanction Number

• Sanction Date


• HOA for expenditure (deduct receipt head)

7. Should capture the following details for Commercial/other Tax Refunds:

• Sanction Number

• Sanction Date


• 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



1.6.9 K-Deposit

Table 48: Functional Requirement Specification – K-Deposit

Business Requirement – K-Deposit


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



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



1.7 Internal & Statutory Audit Table 49: Functional Requirement Specification – Auditing including Internal Audit

Business Requirement – Auditing


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.



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



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:



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

7. Should allow the officer in charge of Sub treasury / Treasury Officer at District 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



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


3. Should allow the officer in charge of Sub treasury / Treasury Officer at District 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

5. Should receive an acknowledgement as soon as he submits his application over the system, the acknowledgement should contain the following fields:

• Indent id (auto generated):




• Current stock status:

• Stock requested:



• 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



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


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



• 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: 4. Should receive an acknowledgement as soon as he submits his application over the

system, the acknowledgement should contain the following fields:





• 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):



• 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:




• 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:



1.8.3 Stamps Selling from Treasury

Table 52: Functional Requirement Specifications - Stamps Selling

Business Requirement – Stamps Selling


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):



• 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



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


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)



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


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



2.2 Recruitment Table 55: Functional Requirement Specification - Recruitment

Business Requirement: Recruitment


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



2.3 Confirmation Table 56: Functional Requirement Specification – Confirmation

Business Requirement: Confirmation


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



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)


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



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



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





4. System should allow users to apply for leave under different applicable and 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

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 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



14. System should have provision that a salary is stopped if a person is absent for more than 1 month or as per rules and policies



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)





4. System should allow users to apply for leave under different applicable and 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






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)



2. Multiple Leave types and related issues should be defined in the system


4. System should allow users to apply for leave under different applicable and 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




10. System should calculate and print an advice on joining date, remaining leave and other user defined data to user specified entities

11. On approval of the leave system should calculate payment entitlement and raise 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


18. 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




20. System should support regularization of unsanctioned absence period by grant of different types of leave and LWP/Leave Not Due



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


1. Multiple Leave types should be defined in the system by providing required workflow


3. System should allow users to apply for leave under different applicable and eligible categories


5. System should calculate and print an advice on joining date, remaining leave and other user defined data to user specified entities

6. On approval of the leave system should calculate payment entitlement and raise 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




11. 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

12. System should inform employee of leaves to be deducted from their account in future




2.5 Performance Management System (PMS) Table 62: Business Requirement - Performance Management System

Business Requirement –Performance Appraisal


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



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.



2.6 Training and Learning Management

2.6.1 Training - Planning

Table 63: Business Requirement Specification – Training Planning

Business Requirement – Training – Planning


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.



2.6.2 Training - Implementation

Table 64: Business Requirement Specification - Training - Implementation

Business Requirement – Training - Implementation


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



2.6.3 Training – Learning Management

Table 65: Business Requirement Specification - Training Learning Management

Business Requirement Training – Learning Management


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



2.7 Promotion

2.7.1 Promotion Table 66: Business Requirement Specification - Promotion

Business Requirement –Promotion


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



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



2.7.2 Time Bound Pay Scale Enhancement (Kramonati) Table 67: Business Requirement Specification - Time Bound Pay Scale Enhancement (Kramonati)

Business Requirement –Promotion


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



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



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.



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



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.



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.



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



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



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)



108. The system should update original payment entries after disbursal

109. The system should update employee database after disbursal



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



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

Table 70: Functional Requirement Specification - Other Employee Entitlement [Claims (TA & Medical Re-imbursement)]

Business Requirement: Other Employee Entitlement [Claims ( TA & Medical re-

imbursement)]


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



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



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.



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.



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



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.



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.



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.



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.



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 / ex-

employee 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



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.

4. The system should generate reports at regular intervals which are submitted for review on line to concerned officers

5. The system should provide for generation of orders of PO’s appointment

6.

The system should manage particulars of all the relevant constituents and parties involved in a case.

7. The system should efficiently manage the process, path and milestones as the case progresses to final outcome

8. The system should generate alerts for all concerned at important stages of case progress (reply/evidence/hearing/verdict)

9.

The system should allow multiple channel access to those managing the case and provide information to those named as party in the case

10. The system should manage all types of documentation or their references associated with the case

11. The system should facilitate/manage all types of correspondence associated with the case

12. The system should manage all interaction associated with the case including the Legal Case History

13.

The system should closely integrate with all the other modules of the application like Human Resource, IFMIS and Pension for implementation of the case/action plan on verdict.

14.

The system should facilitate interdepartmental case handling, knowledge sharing and promote accountability

15.

The system should provide a centralized repository of all cases related information, which is available to users based on their role in the organization.

16.

The system should facilitate search through structure and unstructured content in the repository

17.

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

18.

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



19. The system should allow categorization of cases (Active/ Inactive) for future references in centralized repository

20. The system should publish frequent areas of disputes and possible resolutions in KM

21. Appropriate approval/implementation workflows should be built into the system



2.15 Pension Management Information System Table 78: Functional Requirement Specification- Pension Module

Business Requirement – Pension Module S. No Description

Regular Pension Payment Release

1. The system should be able to generate pension payment schedules as per class/category/chargeability.

2. The system should be able to calculate entitlements, recoveries and net payable and generate pension bills.

3.

The system should allow users to define the Rules for separation –

• Class/Category/Chargeability

4. The system should capture Nomination Information like Nominee Details, Percentage, Relationship, Guardian Information for minors etc

5. System would be able to forecast exact pension liability of GoMP based on current status/trend analysis for relief enhancement for any given period.

6. System would be able to calculate the pension payment share (e.g. between MP and Chhattisgarh)

7.

The system should automatically calculate all the dependent components in the Pension, as per GoMP regulation

8.

The system should make available security controls to limit access to specified personnel.

9.

System should allow viewing of data as per employee / pensioner on line by those permitted access.

10.

The system should have an interface with Disbursement and accounts module to transfer the pension related information.

11.

The system should be flexible enough to provide and restrict access to tasks between users of Pension, HR and Finance according to the requirement.

12. The system should up load data / interact with other modules as required.

13.

The system should allow the display of only selected menu options/ forms 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

16.

The system should monitor regular pension cycle from data entry to fully reconciled results

17. The system should view complete history of pension payroll results

18.

Workflow and logic will be built into the system i.e. system will be programmed to handle activities like:

• Reducing the family pension automatically after the stipulated time




• Timely stoppage of the deductions of commuted portion automatically

19.

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.

20.

System should be able to generate alerts and exception reports where excess funds have been released to the Central Record Keeping Agency.

21.

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.

22.

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

23.

Authority map / alerts checks / exception reports / logins / escalation matrix etc. which will be built into the system

24.

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

25.

The system will handle record keeping through Document Management System

26.

The system should mark erroneous calculations for retry while keeping reconciled calculations intact

27.

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

30.

The system should maintain complete taxation rules defined as part of the pension structures configuration




31.

The system should generate reports / certificates (user defined format with reference number)

32. The system should handle exemptions and rebates as per the Income Tax Rules

33.

The system should generate automatically pensioner returns in pdf or any other format

34. The system should display the status of the Pension calculations

35.

The system should run Pension Calculations multiple times before finalization to ensure accurate pay computation

36. The system should make deduction amounts negative

37. The system should determine deduction amounts by amount and percent of 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

47. System should support online approvals as per the matrix defined in the system

48. The system should keep record of pensioner grievance filed.

49. The system should allow users to define the categories of misconducts.

50.

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

• Last decision

51. The system should generate statement of pending cases on a monthly basis which describes the status of the cases.




52. The system should allow user to file appeal against the decision of a case.

53. The system should have online availability of grievance redressal case along with status, responsibility matrix, SLAs

54. Escalation Matrix will be defined in the system to outline procedures to deal with various categories of complaints depending on their priority.

55. At the point of data entry, system should allow the operator to select the category and priority of the complaint from drop-down menus.

56.

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 grievance, regardless of the priority assigned to it initially.

57.

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 updated.

58.

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 processing

59.

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 uploaded or not, system will maintain audit trails at all organizational levels

60.

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 plan

61. System alert will be generated in case a complaint has not been resolved 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

66. The system should enable revisions to take place automatically including pension revision and relief enhancement (through masters modifications)

67. The system should inform pensioners on revisions and related arrears/recoveries through E mail / sms / post

68. There shall be a link with repository of rules, so that all the latest as well as old circulars are available at one point.

69. The system shall identify “NO Change” cases and record this in the history sheet of the case.

70. Alerts should be generated to the respective authoriries in DPPFI in case a 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.




revision through a web based facility.

72. The system should update pensioner data

Pension Database Management

73. The system should interact with HR Module to receive list and records of new pensioners and pension revisions

74. The system should update pensioner details based records received from HRMIS

75. The system should upload all the scanned relevant documents of pensioners

76.

The system should permit user / retiree to upload/modify his data like

• Address

• Bank account number

• Email id

• Phone Number

• Nominee Details

77. The system should generate emails/sms on uploading/modification of data to related

78. The system should have a common pensioner database

79. The system should allow concurrent user access to the database and maintain data integrity

80. The system should at the same time, allow different users to have access to different data fields all mapping into the common pensioner database

81. The system should generate & record unique Identification number for the 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

84. The system should allow evaluation and prioritization of the database on user defined criteria

85. The system should maintain history of each pensioner (grievances etc.) and display / generate reports of the same

86. The system should allow users to define their own data fields / custom reports

87. The system should check Departmental Dues/outstanding loans/ Government assets (if any) assigned to employee

88.

The system should calculate the pension payout schedules/bills as per the class/category/ chargeability and any other parameter of separation of one (type) of claim from other

89. The system should maintain pensioners ledgers



3. Citizen’s Grievance Redressal

Table 79: Functional Requirement Specifications – Citizen Grievance Redressal

Business Requirement – Citizen Grievance Redressal


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



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



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

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 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 4. Enterprise-wide

Usability 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



Sr. No. Technical Area Requirement Description

• 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


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 6. Enterprise-wide

Usability 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 7. Enterprise-wide

Usability 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 8. Enterprise-wide

Usability 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




• BMP files 9. Enterprise-wide

Usability 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 11. Enterprise-wide

Usability 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


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




Usability creation and use of electronic & digital signatures 17. Enterprise-wide

Usability The system shall provide functionality to apply multiple electronic signatures & digital to a document or transaction


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.


The system shall provide functionality to maintain a record of electronic & digital signature validation in combination with the associated electronic document or transaction


The system shall provide functionality for users to create transactions for a fixed or percentage allocation amount among multiple account codes


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)


The system shall provide functionality for users to edit saved and posted transactions/documents


The system shall provide functionality to accommodate standard validation on all input fields including, but not limited to:- Data type validation- Range validation- Format validation


The system shall provide functionality for users to copy previously saved transactions to a new transaction


The system shall provide functionality for users to perform mass updates to create, change, or delete selected fields across multiple records


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


The system shall provide non-mandatory user-defined fields for the purposes of entering miscellaneous data into a transaction


The system shall provide functionality for either a system-assigned 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




Usability users to purge system data in any of the modules 30. Enterprise-wide

Usability 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

32. Enterprise-wide Workflow

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


The system shall provide functionality to accommodate rules-based automatic notifications on events including, but not limited to:

• Pending approvals on a system transaction

• Aging of open invoice status

• New budget version availability or release




• Status of prompt contracting calendar

• Collection of overdue debts

• Key milestone dates in RFP/contract process 43. Enterprise-wide

Workflow The system shall provide functionality for business partners to access the system from a remote location using web-based self-service functionality and search for information including, but not limited to:

• Order status

• Payment status

• Grant information

• Transaction history 44. Enterprise-wide

Workflow The system shall provide functionality to support the establishment of workflow by transaction type including, but not limited to:

• Requisitions

• Purchase orders

• Contracts

• Contract change orders and amendments

• Lease renewals

• Vouchers

• Budget adjustments based on cross appropriation level of detail

• Inter-agency transactions 45. Enterprise-wide

Workflow 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)




5. Web Portal



Business Requirement – Web Portal

Sr. No. Requirement Description – Web Portal

1. Should allow the administrator to define 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 page type depending upon the category to which the stakeholder belongs to.

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

