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
Out of Scope
Aadhaar Integration to validate wage seeker’s Aadhaar numbers.
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
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
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
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
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
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.
To view the details and track the status of payment instructions.
To take action against a payment instruction which is failed or rejected by the JIT system.
Attributes
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
Extension Period (in days) - It is mandatory to fill.
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
Extension Period (in days) - It is mandatory to fill.
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
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
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.
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.
On hover show “Contract created in the selected time period but not closed till date”.
Pending Bills
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).
Considers all types of bills.
Show the Amount as well of these bills as designed in the mockup.
On hover show “ Bills created in the selected time period but payment is not done as of today”.
Work Orders Not Issued
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.)
On hover show the text “ Projects created but Work Orders not created”.
Muster Rolls Not Created
Count of weeks across all work orders that are in progress (Accepted by SHG) but Muster Roll is not created.
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.
On hover show “Work weeks completed but muster rolls not submitted to ULBs”.
SLA Breached
The number of estimates that are created in the selected time period but have breached their SLA is respective workflow statuses.
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.
All these will be accumulated to form an SLA breach of Estimates.
If the estimate is moved to the next workflow state, this count will go down until the breach happens again.
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
Created - All projects that are created in the selected time period.
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).
Closed - Projects that are created in the selected time period and Work Order has closed in the past already.
Estimate
Created - All estimates that are created in the selected time period.
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).
Approved - The number of Estimates that are created in the selected time period and approved in the past.
Contracts
Created - All Contracts that are created in the selected time period
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).
Yet to Accept - The number of contracts that are created in the selected time period but not accepted by CBO as of date.
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.
Closed - The number of contracts that are created in the selected time period and closed in the past.
Muster Rolls
Submitted - All MRs that are created and Submitted (combined action) in the selected time period.
Yet to Approve - The number of MRs that are created in the selected time period but Approval is pending (Did not reach final status).
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
The number of approved person days considered in Muster rolls that are created for Wage seeker Bills amounting to above KPI.
On Hover Show: Month and actual person days.
By Project Type
Projects that are created in the selected time period by project type.
Show the total project count within the PIE.
Switching to Amount should show the same split by Amount instead of Count.
By Bill Type
Amount Billed (created) by Bill Type in the selected time frame. May not be approved or may be rejected also in that timeframe.
Show the total amount in the PIE.
Switching to numbers should give the number of bills the above KPI refers to while calculating the amount.
Payment By Gender
Table showing payments that are made to wage seekers distinguished by gender for the selected time period.
Average days of employment.
Average payment distinguished by gender for the selected time period where the status of beneficiary reflects paid.
Mockups
Last updated
