Product Requirements Document

Introduction

The Mukhyamantri Karma Tatpara Abhiyan Yojana (MUKTA Yojana) is a government scheme aimed at helping the urban poor, consequently boosting the employment rate within the state. The purpose of this document is to provide comprehensive specifications for MUKTASoft version v1.1.

MUKTASoft aims to improve the overall scheme efficiency of MUKTA by identifying & providing equal job opportunities to the urban poor, constructing environment-friendly projects, developing local communities and slums & plan better for upcoming years.

Purpose

The purpose of this document is to give a detailed description of the requirements for the MUKTASoft v1.1. It will illustrate the purpose and complete declaration for the development of the system. It will also explain system constraints, interface and interactions with other external applications. This document is primarily intended to define the scope of version v1.1 and propose to the stakeholders for its approval and as a reference for developing the next version of the system for the development team.

Definitions, Acronyms & Abbreviations

JE	Junior Engineer
ME	Municipal Engineer
EO	Executive Officer
MC	Municipal Corporation
DDO	Drawing and Disbursing Officer
SOR	Schedule of Rates
WO	Work Order
PO	Purchase Order
WL	Finalized Worklist

Information Source

1. MUKTA FRS

2. JIT Technical documents for integration and discussions with JIT teams

2. Visits to Dhenkanal and Jatni ULBs [Prototype, Product Showcases and UAT]

In Scope

1. JIT Integration

2. Time Extension

3. MUKTA Dashboard

Out of Scope

1. Aadhaar Integration to validate wage seeker’s Aadhaar numbers.

2. Project closure has been moved to MUKTASoft V2.0

Functional Details

JIT Integration

To achieve the goal of smart payments for MUKTA beneficiaries, MUKTASoft will be integrated with JIT-FS. It will enable the ULBs to transfer the money to the beneficiary account through DBT in a smooth and seamless manner by minimizing manual intervention.

Flow Diagram

Fund Allocation Register

To execute the MUKTA-related works, the fund is provided by the state government through the state treasury. The fund is allocated to 4 different heads of account aiming the expenditure booked for different purposes and communities. The information on fund allocation for a ULB is then made available by the JIT system to an integrated system for tracking and validation purposes. MUKTASoft fetches these details and then maintains them for validation and reporting purposes.

Search Criteria

#	Field	Description
1	Financial Year	Financial year, by default current financial year is selected.
2	Head of Account	HOAs from the configuration.
3	Transaction Type	Allotment types are, 1) Initial Allotment 2) Additional Allotment 3) Withdrawal 4) Expense 5) Expense Reversed

Search Result

#	Field	Description
1	HOA	Head of accounts of MUKTA
2	Transaction Number	Transaction number of the transactions fetched from JIT or created in MUKTASoft.
3	Transaction Date	Date of transaction received from JIT-FS in a response of API call or the MUKTASoft PI creation date. Date to be taken care when calling the API again.
4	Transaction Type	A transaction type would be anything from the options given below. Initial Allotment Additional Allotment Withdrawal Expense Expense (Reversed) First 3 are received from the JIT-FS system through API calls while the last one is from MUKTASoft when a PI is pushed. A reverse entry of the Expense is made in the case PI is canceled or failed to create.
5	Transaction Amount	It is a transaction/bill amount.
6	Sanctioned Balance	It is the balance remaining from the sanctioned amount and calculated as given below. Sanctioned Balance = Total Sanctioned Amount - Sum of all the allotments.
7	Fund Available	It is the fund available for the expenditure and calculated as given below. Fund Available = Sum of all the allotments - (Sum of all the expenditure + Sum of all the withdrawal)

Mockups

Create Payment Instruction

The payment instruction is created and then pushed to the JIT system to enable the JIT to process the payment against a bill. For each bill, a payment instruction is generated internally on approval of the bill.

Attributes

#	Parameter	Is Mandatory?	Description
1	Payment Instruction ID	Yes	Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
2	Payment Instruction Date	Yes	Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
3	DDO Code	Yes	The code of DDO from the configuration.
4	Grantee Code	Yes	Grantee code from the configuration.
5	Scheme Code	Yes	MUKTA scheme code
6	HOA	Yes	Head of account from which payment to be made.
7	SSU ID	Yes	Special spending unit id from the configuration.
8	Master Allotment ID	Yes	Virtual allotment parent ID/sanction ID from which payment to be made.
9	Bill Net Amount	Yes	PI net amount of the payment instruction created in MUKTASoft and then pushed to JIT.
10	Bill Gross Amount	Yes	PI gross amount of the payment instruction created in MUKTASoft and then pushed to JIT.
11	Number of Beneficiaries	Yes	The count of beneficiaries in the payment instruction.
12	Purpose	Yes	Purpose is the reference text. E.g. Muster Roll ID etc. for which the payment instruction is created.
	Beneficiary Details	Array	In a single request multiple beneficiaries can be added.
13	Beneficiary Payment ID	Yes	The beneficiary's Payment ID, unique for each beneficiary for its payment. Payment of the beneficiary is tracked by this throughout the payment processing. It is generated with the PI generation.
14	Beneficiary Name	Yes	Beneficiary name maintained in MUKTASoft.
15	Beneficiary Account Number	Yes	Beneficiary’s bank account number maintained in MUKTASoft.
16	IFSC	Yes	IFSC of bank branch from beneficiary’s accounts details.
17	Beneficiary Mobile Number	Yes	Beneficiary's mobile number maintained in MUKTASoft.
18	Beneficiary Address	Yes	Beneficiary’s address maintained in MUKTASoft.
19	Account Type	Yes	Account type of beneficiary’s account maintained in MUKTASoft
20	Payment Amount	Yes	Amount payable to beneficiary.
21	PAN	No	PAN of beneficiary
22	AADHAR	No	Aadhaar of beneficiary
23	Purpose	Yes	Purpose is the reference text. E.g. Muster Roll ID etc. for which the bill is created.

Mockups

Not applicable.

Search Payment Instruction

Search payment instruction serves the purpose of searching a payment instruction to view the details along with status and provide a by default list of all the payment instructions which are pending action from a ULB user.

Search Criteria

Attributes

#	Parameters	Description
1	Ward	Drop-down, with the ward name as values.
2	Payment Instruction Type	Payment instruction types. Viz. Original/ Revised.
3	Project Name	Name of project
4	Bill Number	Bill number
5	Status	Status of payment instructions. This parameter is not applicable for “Payment Instruction Pending for Correction”
6	Created from date	Payment instruction created date. This parameter is not applicable for “Payment Instruction Pending for Correction”
7	Created to date	Payment instruction created date. This parameter is not applicable for “Payment Instruction Pending for Correction”

Mockups

Search Result

Attributes

#	Parameter	Description
1	Payment Instruction ID	Original/ Revised Payment Instruction ID. It is a hyperlink which opens the payment instruction to view the complete details.
2	Payment Instruction Date	Original/ Revised Payment Instruction Date.
3	No. of beneficiaries	Total number of beneficiaries for which payment is getting processed.
4	No. of successful Payments	Total number of successful payments.
5	No. of failed Payments	Total number of failed payments
6	Total Amount	Total amount of payment instruction which is to be paid.
7	Status	Status of payment instruction

Mockups

View Payment Instruction

The view payment instruction feature is provided mainly for 2 purposes.

1. To view the details and track the status of payment instructions.

2. To take action against a payment instruction which is failed or rejected by the JIT system.

Attributes

#	Parameter	Description
1	Bill Number	Hyperlink to view the bill details.
2	Payment Instruction Type	Payment instruction type, Original or Revised.
3	Parent Payment Instruction ID	Parent payment instruction id, i.e. original PI ID. It is a hyperlink to view the Original Payment Instruction Details.
4	Payment Instruction ID	Payment Instruction ID.
5	Payment Instruction Date	Payment Instruction Date.
6	Head of Account	Head of account from which amount to be paid
7	Master Allotment ID	Master allotment ID from which amount to be paid
8	Status	Status of payment instruction. A tool-tip is displayed to display the error message for declined and rejected PIs.
9	Payment Advice Details
10	Payment Advice ID	Payment advice ID generated for the original/ revised PI.
11	Payment Advice Date	Payment advice generation date.
12	Token Number	Token no. generated for the payment instruction
13	Token Date	Token no. generated for the payment instruction
14	Online Bill Number	Online bill number for the online bill generated for the payment advice.
	Error/ Info Section	A information display band to display the error message/ info messages
	Beneficiary Details	Tabular form
15	Beneficiary ID	It is an individual wage seeker/ organization ID for CBOs and vendors, and displayed as a hyperlink to view details.
16	Payment ID	Unique beneficiary ID for the payment through JIT. It remains the same though the process until the payment becomes successful.
17	Beneficiary Name	Name of the beneficiary.
18	Account Number	Account number of beneficiary, only the last 4 digits are displayed. Remaining initial digits of A/C are masked.
19	IFSC	IFSC code of the bank/ branch of beneficiary accounts.
20	Payment Status	The payment status, as per the definition. A tooltip is shown to display the error message for failed payments.
21	Payment Amount	The payment amount of the beneficiary.
	Info	In case there are failed payments, information is displayed. “Please make sure all the necessary corrections are made before generating the revised payment instruction for JIT” .

Mockups

Update Payment Details

Payment details of beneficiaries are updated with an API call which provides the details of beneficiaries for which amount is debited from the MUKTA account of provided ULB. The update in the status can be seen on the payment instruction details page.

Update Failure Details

Payments which fail to credit into the beneficiary bank accounts are updated with an API call which provides the details of all the beneficiary payments which are returned. The update in the status can be seen on the payment instruction details page.

Create Revised Payment Instruction

For all the failed payments a revised payment instruction is created. The option to create a revised payment instruction is provided on the payment instruction page for failed payments.

Time Extension

A work order is created for an approved estimate to award the work to CBO. CBO starts the work to complete it within a given period. In case CBO comes to know that they are not in a position to complete the work within the given period due to various reasons, they need to inform the same to an officer in charge of the project and apply for a time extension which is then subject to approval/cancelling of work order based on the analysis done by the ULB.

Process Flow

Create Time Extension

The request for a time extension can be directly raised by CBO using the mobile application or by the officer in charge of the project on behalf of CBO using a web application. Once the request is raised it goes for verification and approval.

CBO

CBO logins into application visits to My Works to get the option to raise the time extension request and then fill the form with the below details and submit it for verification and approval.

Attributes

1. Extension Period (in days) - It is mandatory to fill.

2. Reason for Extension - It is mandatory to fill.

Mockups

Employee

The MUKTA Implementation Expert can create this request on behalf of CBO and then send it for verification and approval. Once the request is created it is visible in the CBO application under My Service Requests.

Attributes

1. Extension Period (in days) - It is mandatory to fill.

2. Reason for Extension - It is mandatory to fill.

Mockups

Time Extension Workflow

The time extension work is of 3 levels beginning with the creator, forwarded for verification and ending with approval. The table below explains the levels of workflow and the transition between them.

Attributes

#	Action	Role	From State	To State	Status
1	Submit	Work Order Creator		Pending for verification	Submitted
2	Verify and Forward	Work Order Verifier	Pending for verification	Pending for approval	Verified
3	Send Back	Work Order Verifier	Pending for verification	Pending for correction	Sent Back
4	Send Back	Work Order Approver	Pending for approval	Pending for verification	Sent Back
5	Send Back To CBO	<any roles having access of action>	<Current Status>	Pending for correction	Sent Back
6	Edit/ Re-submit	Work Order Creator	Pending for correction	Pending for verification	Re-submitted
7	Approve	Work Order Approver	Pending for approval	Approved	Approved
8	Reject	<any roles having access>	<Current Status>	Rejected	Rejected

Mockups

Standard UI which is for creation, verification, and approval to be used here.

Search Time Extension

Search work order screens are used to search for revised work orders (time extension).

View Time extension

The time extension request can be searched using the search work order screen and view the details.

MUKTA Dashboard

Issues

Projects Delayed

1. Count of Projects where WO start date is in the selected date range and WO end date + X days are less than today's date. Let X be configurable.

2. For example: The selected time period is Jan 1 to Jan 15. WO start date is Jan 7th, the end date is Jan 31, and X is 7. From 8 Feb onwards if project closure is not done, this project is considered delayed.

3. On hover show “Contract created in the selected time period but not closed till date”.

Pending Bills

1. Count of Bills that are created (Automatically or manually) in the selected date range but current status (as of today) is not Paid/Payment done (Whichever is the final stage of the Bill).

2. Considers all types of bills.

3. Show the Amount as well of these bills as designed in the mockup.

4. On hover show “ Bills created in the selected time period but payment is not done as of today”.

Work Orders Not Issued

1. Number of Projects that are created in the selected time period and Work Orders are not yet created. (PS: Both are created dates only through text that says issued.)

2. On hover show the text “ Projects created but Work Orders not created”.

Muster Rolls Not Created

1. Count of weeks across all work orders that are in progress (Accepted by SHG) but Muster Roll is not created.

2. If the Contract start date is Jan 1st (Mon) and the user has not created muster rolls until Jan 31, the number of Muster Rolls not created is 4 for this project. If the user submits any 2 of them on Feb 1st, then the remaining 2 should be shown.

3. On hover show “Work weeks completed but muster rolls not submitted to ULBs”.

SLA Breached

1. The number of estimates that are created in the selected time period but have breached their SLA is respective workflow statuses.

2. Ex. Estimate created on Jan 15 (timeline selected is Jan 12-18), SLA is 5 days for one particular state. From Jan 21 onwards till date, this will be counted as an SLA breach.

3. All these will be accumulated to form an SLA breach of Estimates.

4. If the estimate is moved to the next workflow state, this count will go down until the breach happens again.

5. In the same way, SLA breaches are calculated for other services too.

ULB-wise Leaderboard

ULB-wise issues are displayed in tabular form.

Status Wise Break-up

Projects

1. Created - All projects that are created in the selected time period.

2. In progress - Number of Projects that are created in the selected time period but Work Order (Contract) is not closed yet (which means the project is officially not closed).

3. Closed - Projects that are created in the selected time period and Work Order has closed in the past already.

Estimate

1. Created - All estimates that are created in the selected time period.

2. Yet to Approve - The number of Estimates that are created in the selected time period but the estimate is not finally approved (Did not reach the final status).

3. Approved - The number of Estimates that are created in the selected time period and approved in the past.

Contracts

1. Created - All Contracts that are created in the selected time period

2. Yet to Approve - The number of contracts that are created in the selected time period but the contract is not finally approved (Did not reach final status).

3. Yet to Accept - The number of contracts that are created in the selected time period but not accepted by CBO as of date.

4. In Progress - The number of contracts that are created in the selected time period and Accepted by CBO in the past but not closed yet, irrespective of the contract closure date.

5. Closed - The number of contracts that are created in the selected time period and closed in the past.

Muster Rolls

1. Submitted - All MRs that are created and Submitted (combined action) in the selected time period.

2. Yet to Approve - The number of MRs that are created in the selected time period but Approval is pending (Did not reach final status).

3. Approved - The number of Estimates that are created in the selected time period and approved in the past.

Money Transferred

Amount paid by bill type aggregated by months.

Payment and Labour Attendance

1. The number of approved person days considered in Muster rolls that are created for Wage seeker Bills amounting to above KPI.

2. On Hover Show: Month and actual person days.

By Project Type

1. Projects that are created in the selected time period by project type.

2. Show the total project count within the PIE.

3. Switching to Amount should show the same split by Amount instead of Count.

By Bill Type

1. Amount Billed (created) by Bill Type in the selected time frame. May not be approved or may be rejected also in that timeframe.

2. Show the total amount in the PIE.

3. Switching to numbers should give the number of bills the above KPI refers to while calculating the amount.

Payment By Gender

1. Table showing payments that are made to wage seekers distinguished by gender for the selected time period.

2. Average days of employment.

3. Average payment distinguished by gender for the selected time period where the status of beneficiary reflects paid.

Mockups