Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The time extension feature allows users to search for time extension requests and view their details.
The same Search Work Order feature is used to search for revised work orders.
Clicking to view the details of a revised work order will open the "View Revised Work Order Page," showing the following information:
1
Revised work order number
Display Only
NA
Revised work order number
2
Work order number
Display Only
NA
Work order no.
3
Project ID
Display Only
NA
Project ID of the project.
4
Project sanctioned date
Display Only
NA
Date of the proposal from the project.
5
Project name
Display Only
NA
Project name
6
Project description
Display Only
NA
Project description
7
Work Order Details
Tab
8
Name of CBO
Display Only
NA
The name of the CBO
9
CBO ID
Display Only
NA
The CBO ID
10
Role of CBO
Display Only
NA
The role of the CBO IA/ IP.
11
Name of the officer in-charge
Display Only
NA
Name of the officer in-charge as provided in original WO.
12
Designation of officer in-charge
Display Only
NA
Designation of the officer in-charge as provided in original WO.
13
Project completion period
Display Only
NA
Number of days work to be completed as provided in original WO.
14
Work Start Date
Display Only
NA
Work start date as provided in original WO.
15
Work End Date
Display Only
NA
Revised work end date as provided in original WO.
16
Work order amount
Display Only
NA
Total estimated cost as provided in original WO.
17
Extension requested
Display Only
NA
Time requested to extend in days.
18
Revised End Date
Display Only
NA
The revised End Date as per the time requested as extension.
19
Reason for Extension
Display Only
NA
Reason for time extension provided entered by CBO.
20
Terms and Conditions
Tab
As provided in original WO.
21
Workflow Timelines
Section
As per the the workflow of revised work order.
Not applicable.
In Workflow Time Extension - Workflow actions based on roles logged in user has.
For Workflow Completed Time Extension - No Actions
Revised work details are displayed as per the details provided in the story.
The workflow to process the time extension request
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 the organization come to know that they are not in a position to complete the work within the given time frame due to various reasons, they need to inform the same to 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.
Request for time extension can be directly raised by CBO using the mobile application and by the officer-in-charge of the project on behalf of CBO using a web application. Once a request is raised it goes for verification and approval.
The work order inbox is used to complete the revised work order workflow.
Workflow is the same as the workflow of the original work order with the same workflow levels (except/ decline are excluded) and actions.
1
WORK ORDER CREATOR/ CBO Admin
Create
Search
View
Edit/ Re-submit
Submit
Junior Engineer/ Assistant Engineer/ CBO User
2
WORK ORDER VERIFIER
Search
View
Verify and Forward
Send Back
Municipal Engineer
3
WORK ORDER APPROVER
Search
View
Approve
Send Back
Send Back To CBO
Reject
Executive Officer
1
Submit
Work Order Creator/ CBO Admin
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
Work Order
Edit/Re-submit
Pending for correction
1
Edit/ Re-submit
Pending for re-assignment
1
Verify and Forward
Pending for verification
2
Approve
Pending for approval
1
The revised work order is forwarded to the approver.
A revised work order is sent back to the previous user in the workflow.
The revised work order is sent back to CBO for correction.
The revised work order is edited and re-submitted. It goes to the verifier for verification.
The revised work order is approved.
The time extension comes into effect and the CBO user is allowed to track the attendance of wage seekers for an extended period.
The revised work order is rejected.
Send Back To CBO
CBO
Time extension request {timeextensionrequestid} is sent back to you for correction. Login to MUKTASoft for details. MUKTA - Govt. of Odisha.
Reject
CBO
Time extension request {timeextensionrequestid} for the project {projectid}
is rejected. Login to MUKTASoft for detail. MUKTA - Govt. of Odisha.
Approve
CBO
Time extension request {timeextensionrequestid}
for project
{projectid}
is approved. Login to MUKTASoft for detail. MUKTA - Govt. of Odisha.
Reject
Officer In-charge
Time extension request {timeextensionrequestid}
for the project
{projectid} is rejected. Login to MUKTASoft for detail. MUKTA - Govt. of Odisha.
Approve
Officer In-charge
Time extension request {timeextensionrequestid} for project {projectid} has been approved. Login to MUKTASoft for detail. MUKTA - Govt. of Odisha.
UI design is going to be the same as the work order workflow. Only the workflow states will be displayed as per the table given above.
The workflow pop-up windows for every action are going to be the same as for the work order workflow.
The same work order inbox is used.
The workflow pop-up windows are used as per the standard.
Actions are configured based on role-action mapping.
Workflow states are defined as provided and the state transition is done accordingly.
SMS notifications are sent.
A closure request is created and send for approval, there should be an option to view all the request which are raised so far and a option to edit if a closure request is sent to creator for the same.
Closure Requests/ Time Extension Request
CBO
Role: CBO ADMIN
To be view the closure requests Closure Requests feature is provided.
Closure Requests lists all the closure requests which are created for the works assigned to logged-in CBO user and are segregated by In Progress and Approved closure requests.
Each closure request card will have below attributes displayed
Closure Request No.
Work Order No.
Work Description
Location - Locality + Ward
Work Start Date
Work End Date
Work Amount
Status [Submitted, Sent Back, Verified, Approved]
View Details/ Edit - Action button to see the muster roll details./ Edit action is enabled when service request is send back for correction.
On View Details, the details of closure request is displayed with the attributes as given below.
Project Details
Closure Request No.
Project ID
Project Sanction Date
Project Type
Project Name
Project Description
Location
On View Details, the details of time extension request is displayed with the attributes as given below.
Request ID
Work Order No.
Project ID
Work Description
Completion Days
Work Start Date
Work End Date
Extension required in days
Extended End Date
Extension Reason
Status
Not applicable
Not applicable
View Details - To view the closure request details.
Edit - In case closure request is sent back for correction.
Not applicable.
My service request to list all the request raised for project assigned to him.
Details in the card view is displayed as provided.
Details for detailed view is displayed as provided.
CBO can edit the closure request when it is sent back to CBO.
Fund Allocation Register
Reports → Fund Allocation Register
Employee
Role: Fund Allocation View
Virtual Allotment Details (VA) is the API to fetch the fund allocation details.
MUKTA as a scheme has multiple HOAs for which fund is sanctioned and allocated.
Fund Allocation Register has to be developed to see and download the details.
For Request/ Response parameters, please refer the integration approach document.
This data is stored and maintained at MUKTASoft for every financial year and used for reporting and reference purposes.
APIs to be triggered daily at 10 PM.
Search Parameters
#
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
Note: Financial Year is mandatory to select, by default current financial year is selected and records are searched.
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 JIT-FS system through API call 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 transaction 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 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)
While fetching the details, from date should be taken care properly.
The records/transactions are sorted in chronological order.
The master data which needs to be configured.
Special Spending Unit
SSU ID
SSU Name
Grantee Code
DDO Code
Tenant ID
Head of Accounts
Code
Name
221705789358641045908 (MUKTA - SC Component)
221705800358641045908 (MUKTA - General Component)
221705796358641045908 (MUKTA - ST Component)
Not applicable.
Not applicable.
Search - Fetch and display the records based on the search parameters.
Clear - Clear the search parameters.
Download - Option to download the report into PDF format is provided as per the attached format.
Not applicable
Data fetched is stored for reporting and reference purpose.
Report is developed with the option to download the it into PDF.
The integration with JIT start with the payment instruction. Hence the entity we create at MUKTASoft to push into JIT as Payment Instruction will also be called Payment Instruction.
Payment Instruction
Auto Generation
Employee
Role: System
Payment instruction (PI) is the API to push the PI details into JIT.
For failed transactions, revised PI is generated and then pushed into JIT.
For each bill one PI is prepared and pushed into JIT.
PI is prepared and pushed with approval of Bill (Wage Bill, Purchase Bill, Supervision Bill).
To generate a PI, selection of HOA logic is given under configuration section.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for each PI and revised PI.
Once a PI is generated can be searched and viewed using search and view PI feature.
System performs a check to decide on the HOA, It picks a HOA first out of three HOAs and check for the fund available for all the sanction orders one by one and when found sufficient fund is available, create PI.
HOAs are scanned in the sequence given below. Sequence of HOA to be selected should be configurable.
SC Head
ST Head
General Head
#
Parameter
Is Mandatory?
Description
2
jitBillNo
Yes
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
3
jitBillDate
Yes
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
4
jitBillDdoCode
Yes
The code of DDO from the configuration.
5
granteeAgCode
Yes
Grantee code from the configuration.
6
schemeCode
Yes
MUKTA scheme code
7
hoa
Yes
Head of account from which payment to be made.
8
ssuIaId
Yes
Special spending unit id from the configuration.
9
mstAllotmentDistId
Yes
Virtual allotment parent ID/sanction ID from which payment to be made.
10
billNetAmount
Yes
PI net amount of the payment instruction created in MUKTASoft and then pushed to JIT.
11
billGrossAmount
Yes
PI gross amount of the payment instruction created in MUKTASoft and then pushed to JIT.
12
billNumberOfBenf
Yes
The count of beneficiaries in the payment instruction.
13
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.
14
benefId
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.
15
benefName
Yes
Beneficiary name maintained in MUKTASoft.
16
benfAcctNo
Yes
Beneficiary’s bank account number maintained in MUKTASoft.
17
ifscCode
Yes
IFSC of bank branch from beneficiary’s accounts details.
18
benfMobileNo
Yes
Beneficiary's mobile number maintained in MUKTASoft.
19
benfAddress
Yes
Beneficiary’s address maintained in MUKTASoft.
20
accountType
Yes
Account type of beneficiary’s account maintained in MUKTASoft
21
paymentAmount
Yes
Amount payable to beneficiary.
22
panNo
No
PAN of beneficiary
23
adhaarNumber
No
Aadhaar of beneficiary
24
purpose
Yes
Purpose is the reference text. E.g. Muster Roll ID etc. for which the bill is created.
#
Parameter
Description
1
jitBillNo
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
2
jitBillDate
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
3
ssuIaId
Special spending unit ID. A master value maintained in JIT-FS.
4
successCode
0 - for successfully accepting the PI.
7
sucessDescrp
Jit Bill is received successfully ,Payment Instruction will be generated after Bill is submitted by SSU in JIT-FS
PI is created and saved at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of PI API: No response is received.]
PI status at MUKTASoft changes to Pending.
Beneficiary payment status update to “Payment Pending”.
Option to re-push the PI is provided, and the same time system will try to push all such PI once in a day at 9PM every day.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of PI API: <JIT error message>]
PI status at MUKTASoft updated/changes to Declined.
Beneficiary payment status updated to “Payment Pending”.
Option to re-push the PI is provided, necessary correction is made to encounter the error and PI is re-pushed.
Success response is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of PI API: Response is received and updated successfully]
PI status at the MUKTASoft changes to Initiated.
Beneficiary payment status changes to “Payment Initiated”.
An expense transaction is recorded under Fund Allocation Register.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Pending
Payment Pending
Resubmit
PI
2
Response with Error
Pending
Declined
Payment Pending
Resubmit
PI
3
Response Without Error
Pending/ Decline
Initiated
Payment Initiated
No Action
Make sure DDO Code and SSUID are passed into requests as per the configuration. In case configuration is missing. [Message: DDO and SSUID configuration is missing.]
Make sure Net or Gross amount of Payment Instruction is not more than the total allotted amount for SSU a HOA and Sanctioned ID. [Message: Insufficient fund.]
Make sure the payment instruction ID is unique and no PI has already been pushed with same PI ID. [Message: Duplicate payment instruction ID.]
Make sure number of beneficiaries mentioned in the header should not mismatch with the actual details. [Message: Number of beneficiaries provided in header doesn’t match with the details.]
Make sure amount mentioned in the net amount should not mismatch with the total of all the beneficiaries amount. [Message: The total net amount provided in hear doesn’t match with total of all the beneficiaries.]
Make sure Gorss amount is either equal to or more than Net Amount and none of them can be zero. [Message: Gross amount can not be less than the net amount.]
Make sure at least one beneficiary is included in PI. [Message: Beneficiary detail is missing.]
Make sure total net amount is equal to sum of all the beneficiaries’ payment amount. [Message: The total net amount provided in header doesn’t match with total of all the beneficiaries.]
Make sure PI doesn’t have duplicate beneficiary. i.e. same a/c and ifsc cannot be repeated. [Message: There are 2 or more than 2 beneficiaries account number and IFSC are same.]
Beneficiaries original account no /IFSC/Bifid is not matching with correction file – Make sure parameter values passed are correct. [Message: The beneficiary <paymentid> was not present in the original payment instruction.]
Status are configured as master data.
PI Status
Pending
Declined
Initiated
Rejected
Approved
In Process
Completed
Payment Status - Beneficiary’s payment status.
Payment Pending
Payment Initiated
Payment In Process
Payment Successful
Payment Failed
Not applicable.
Not applicable.
Resubmit (*On View Payment Instruction)*
PI is re-constructed, availability of fund is checked and push and the response is updated back.
Scheduler: Same time a scheduler running every day at 10PM will try to push such PIs which are created with status Pending.
Not applicable
PI ID is generated following the format given below.
PI-<ULBCODE>/FY/<6 digit running sequence number>. E.g. PI-DK/2022-23/000023.
The Six digit running sequence no. should be running for ULB wise.
It has to be reset to 1 with start of every financial year. i.e. on 01/04 00:00AM
Payment transaction ID is generated for each beneficiary, which is unique for the every transaction. There is not specific format.
View Payment Instruction.
Make sure the the availability of fund is checked before pushing the payment instruction into JIT.
PI is generated for each and every bill and pushed to JIT with the approval of bill.
All the validations are taken care.
PI ID is generated as per the format defined.
If the PI is declined, the same PI can be modified and re-pushed.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
Search project by ULB/ employee users.
Employee Role: Project Admin, Project_Viewer
Search Project action has to be configurable and allow mapping with a role on demand.
Search Project is provided to allow the users to search Work and view its details/ create estimates.
#
Field Name
Data Type
Description
1
Ward
Drop-down
List of ward boundaries for logged-in user ULB with search by entering name.
2
Project Type
Drop-down
Values of work type from MDMS configuration.
3
Project Name
Textbox
Project Name
4
Project ID
Textbox
Work identification no. generated for a work in works proposal
6
From Date
Date Picker
Proposal creation date, entered by user while creating works proposal.
7
To Date
Date Picker
Proposal creation date, entered by user while creating works proposal.
At least one parameter is required to perform the search.
Consider From Date and To Date as a Date Range single parameter.
An exact search is performed for the values entered/selected other than Project Name.
For Project Name, fuzzy search is applicable.
In case multiple parameter values are supplied AND are applied for searching record.
The search result is shown as given below.
Pagination is displayed to handle the big result set. 10 records are displayed per page.
The option to download the result set in Excel/ PDF is provided.
#
Field
Data Type
Comments
1
Project ID
Display Only
A hyperlink to open the project details in view mode.
2
Project Name
Display Only
Name of project having project description displayed as tool-tip on mouseover.
4
Location
Display Only
Locality name along with ward name.
5
Estimated Cost
Display Only
The project cost from the project details
All the actions are displayed based on role action mapping and the user role assignment.
Search - It will perform the search based on the values supplied for search parameters and the logic defined.
Clear Search - It will clear the values filled for searched parameters.
Project ID - It will take the user to the View Project Details Page.
Not applicable.
1
Search Parameters/ Search Logic should be as stated in the story above.
2
Search result is shown as described in the story.
3
Pagination is provided to handle more results and 10 records per page is displayed.
A time extension request is created and sent for approval. There should be an option to view all the requests that have been raised so far and the option to edit if a request is sent to CBO for correction.
Time Extension Request
CBO
Role: CBO ADMIN
To view the requests, the My Requests feature is provided.
My Requests lists all the requests (Closure/ Time Extension) created for the works assigned to logged-in CBO users, and segregated by In Progress and Approved requests.
An approved request can not be edited.
In Progress closure, the request can be edited only when the request is sent back for correction.
The edit time extension request form allows users to change the extra days required for completion of the project and then submit again.
Field level validations.
Not applicable.
Edit and Submit.
Not applicable.
The same as create time extension request.
After changing the extension period, on submit request is again placed to the verifier.
Creating a time extension request by employee
A work order is created for an approved estimate in order to award the work to CBO. CBO starts the work to complete it within a given time period.
In case the organization comes to know that they are not in a position to complete the work within the given time frame due to various reasons, they need to inform the same to 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.
Request for time extension can be directly raised by CBO using the mobile application and by the officer-in-charge of the project on behalf of CBO using a web application. Once a request is raised it goes for verification and approval.
Home > Work Orders > Inbox > Search Work Order > View Work Order > Request Time Extension (From Action Menu)
Work order to be revised to extend the completion period.
The request to revise the work order for the extension of time can be created by the CBO/officer-in-charge.
1
Work order number
Display Only
NA
Work order no.
2
Project ID
Display Only
NA
Project ID of the project.
3
Project sanction date
Display Only
NA
Date of the proposal from the project.
4
Project name
Display Only
NA
Project name
5
Project description
Display Only
NA
Project description
8
Work Order Details
Tab
9
Name of CBO
Display Only
NA
The name of the CBO as per original WO.
10
CBO ID
Display Only
NA
The CBO ID as per original WO.
11
Role of CBO
Display Only
NA
The role of the CBO IA/IP as per original WO.
12
Name of the officer in-charge
Display Only
NA
Name of officer in-charge as per original WO.
13
Designation of officer in-charge
Display Only
NA
Designation of officer in-charge as per original WO.
14
Project completion period
Display Only
NA
Number of days work to be completed as per original WO.
15
Work Start Date
Display Only
NA
Work start date as per original WO.
16
Work End Date
Display Only
NA
Work end date as per original WO.
17
Work order amount
Display Only
NA
Total estimated cost as per original WO.
18
Extension requested
Numeric
Y
Time requested to extend in days.
19
Reason for Extension
Text-area
Y
The reason of time extension to be captured here, it should not be more than 250 characters.
20
Terms and Conditions
Display Only/ Tab
NA
Terms and conditions as per original WO.
On Request Time Extension
In case the first muster roll is pending to submit for approval.
Time extension request can not be created. Please ensure that no muster roll is pending for submission.
2. In case the first muster roll itself is not created.
Time extension request can not be created. Please ensure that the first muster roll is submitted for approval.
3. In case a project closure request is already created.
Time extension request can not be created. A closure request has already been created for the selected project.
Not applicable.
On submit, create and forward workflow pop-up window is displayed.
On Create and Forward,
The success page is displayed.
The time Extension request number is generated as per the specified format. TE/2022-23/000021.
The time extension request is forwarded to the verifier in the workflow.
Modification of work order is allowed to extend the time.
A time extension request number is generated to identify the request.
The link between original and revised work orders is maintained.
Payment Instruction
Status Update for Payment Failed Status
Employee
Role: System
Failed Details (FD) is the API to fetch the failed payment details from JIT.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every FD call.
The API call to be scheduled once in a day at 10 PM for Completed payment instructions.
#
Parameter
Description
2
billno
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
3
billDate
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
4
adviceId
Payment advice ID, generated at JIT-FS
5
onlineBillRefNo
Online bill reference no. generated at JIT and received with PAG response.
6
tokenNo
Token number, generated at JIT-FS
7
tokenDate
Token number, generated at JIT-FS
#
Parameter
Description
2
billNumber
Bill number of the bill created in MUKTASoft and then pushed to JIT-FS as payment instruction.
3
billDate
Bill date of the bill created in MUKTASoft and then pushed to JIT-FS as payment instruction.
4
voucherNo
Voucher generated at JIT-FS for maintaining the accounting.
5
voucherDate
Voucher date.
6
billRefNo
Online bill reference number generated at JIT and received with PAG response.
7
tokenNumber
Token number generated at JIT-FS
8
tokenDate
Token generation date
benfDtls
10
benfAcctNo
Beneficiary’s account number.
11
benfBankIfscCode
Beneficiary’s bank / branch IFSC.
12
utrNo
Unique transaction number used by banks to reconcile the transaction.
13
utrDate
UTR date.
14
endToEndId
End to end id generated to identify a particular beneficiary for a transaction while it is pushed to CPC for payment clearance.
15
orgBillRefNumber
Original online bill reference number, In first failure case billRefNo and orgBillRefNumber are same.
16
challanNumber
Challan number of the challan created to put the amount into suspense account
17
challanDate
Challan generation date
18
failedReason
Reason for failure
19
benfId
Beneficiary unique ID, unique to transaction.
Error message displayed on View Payment Instruction Page. [Message: On call of FD API: No response is received.]
PI status at MUKTASoft remain unchanged to Completed.
Beneficiaries payment status remain unchanged to Payment Successful.
No action is enabled.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of FD API: <JIT error message>]
PI status at MUKTASoft remain unchanged to Completed.
Beneficiaries payment status remain unchanged to Payment Successful.
No action is enabled.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of FD API: Response is received and updated successfully]
PI status at the MUKTASoft remain unchanged to Completed.
The beneficiaries for which details is received in response, the payment status changes to Payment Failed.
SMS notification is sent to all the beneficiaries.
Option to generate revised PI is enabled. It triggered the COR API call.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Completed
Completed
Payment Successful
No Action
2
Response With Error
Completed
Completed
Payment Successful
No Action
3
Response Without Error
Completed
Completed
Payment Failed
Generate Revised PI
COR
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
To beneficiary for which failure details is received:
Payment of Rs. {amount} for MUKTA, transaction <UTRNO> is failed. Contact MUKTA Cell at ULB for more detail. MUKTA - Govt. of Odisha.
View Payment Instruction
API is called and status is fetched and updated for beneficiaries.
SMS notification is sent to beneficiary for failed transaction.
Status is reflected in View Payment Instruction Page.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
Payment Instruction
Status Update for Payment Status
Employee
Role: System
Payment Details (PD) is the API to fetch the payment details from JIT.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every PD call.
The API call to be scheduled once in a day at 10 PM for In Process payment instruction.
#
Parameter
Description
1
finYear
Financial year received in the APIs response of PAG.
2
ExtAppName
The name of the application from which the call is being made.
3
billRefNo
Online bill reference number received in the APIs response of PAG.
4
tokenNumber
Token number received in the APIs response of PAG.
6
tokenDate
Token date received in the APIs response of PAG.
#
Parameter
Description
1
billNumber
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
2
billDate
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
3
voucherNumber
Voucher number of the voucher created in JIT to maintain the accounting.
4
voucherDate
The voucher creation date of the voucher created in JIT-FS for payment.
5
billRefNo
Online bill reference number generated in JIT and received in PAG response.
6
paymentStatus
Payment status Message Received from RBI at the time of Debit Scroll.
7
tokenNumber
Token number generated in JIT and received in PAG response.
8
tokenDate
Token date of the token generated in JIT and received in PAG response.
Debit Scroll Details
9
benfAcctNo
Beneficiary’s account number.
10
benfBankIfscCode
Beneficiary’s bank / branch IFSC.
11
utrNo
Unique transaction number used by banks to reconcile the transaction.
12
utrDate
The date of transaction which is used by bank.
13
endToEndId
End to end id generated to identify a particular beneficiary for a transaction while it is pushed to CPC for payment clearance.
14
benfId
Beneficiary unique ID, unique to transaction.
Error message displayed on View Payment Instruction Page. [Message: On call of PD API: No response is received.]
PI status at MUKTASoft remain unchanged to In Process.
All beneficiaries payment status remain unchanged to Payment In Process.
Option to refresh the status is provided. It triggers call of PD.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of PD API: <JIT error message>]
PI status at MUKTASoft remain unchanged to In Process.
All beneficiaries payment status remain unchanged to Payment In Process.
Option to refresh the status is provided. It triggers call of PD.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of PD API: Response is received and updated successfully]
PI status at the MUKTASoft changes to Completed.
The beneficiaries payment status is changed to “Payment Successful”.
No action is enabled.
SMS notification is sent to all the beneficiaries.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
In Process
In Process
Payment In Process
Refresh
PD
2
Response With Error
In Process
In Process
Payment In Process
Refresh
PD
3
Response Without Error
In Process
Completed
Payment Successful
No Action
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
To all the beneficiaries:
Payment of Rs. {amount} for MUKTA, transaction <UTRNO> is made to your registered bank account. Contact your bank if not credited within 72 hours. MUKTA - Govt. of Odisha.
View Payment Instruction
API is called and status is fetched and updated for both PI and Beneficiary.
SMS notification is sent to all the beneficiaries.
Status is reflected in View Payment Instruction Page.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
Payment Instruction
Status Update for Successful Payment Details of Revised PIs
Employee
Role: System
Success Payment Details (FTPS) is the API to fetch the payment details of revised PI from JIT.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every FTPS call.
The API call to be scheduled once in a day at 10 PM for In Process payment instruction.
#
Parameter
Description
1
jitCorBillNo
PI ID of revised PI generated in MUKTASoft to re-push failed transactions into JIT
2
jitCorBillDate
PI date of revised PI generated in MUKTASoft to re-push failed transactions into JIT
3
jitCorBillDeptCode
Application code.
4
jitOrgBillRefNo
Original online bill reference no. in JIT while payment failed first time.
5
jitOrgBillNo
Original Payment Instruction ID in MUKTASoft while payment failed first time.
6
jitOrgBillDate
Original Payment Instruction Date in MUKTASoft while payment failed first time.
#
Parameter
Description
1
jitCorBillNo
Revised PI ID generated in MUKTASoft and push failed transactions into JIT
2
jitCorBillDate
Revised PI date generated in MUKTASoft and push failed transactions into JIT
3
jitOrgBillRefNo
Original, the first online bill reference number generated in JIT.
4
voucherNumber
The voucher number of voucher generated in JIT to maintain the accounting.
5
voucherDate
The voucher creation date for the voucher created in JIT for payment.
6
billRefNo
Online bill reference number for revised PI/ Current PI.
7
paymentStatus
Payment status, message received from RBI at the time of Debit Scroll.
8
tokenNumber
Token number generated in JIT.
9
tokenDate
Token date generated in JIT.
Beneficiary Details
10
benfAcctNo
Beneficiary’s account number.
11
benfBankIfscCode
Beneficiary’s bank / branch IFSC.
12
utrNo
Unique transaction reference number used by banks to reconcile the transaction.
13
utrDate
UTR date.
14
endToEndId
It is generated to identify a beneficiary for a transaction while it is pushed to CPC for payment clearance.
15
benfId
Beneficiary unique ID, unique to transaction.
Error message displayed on View Payment Instruction Page. [Message: On call of FTPS API: No response is received.]
PI status at MUKTASoft remain unchanged to In Process.
All beneficiaries payment status remain unchanged to Payment In Process.
Option to refresh the status is provided. It triggers call of FTPS.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of FTPS API: <JIT error message>]
PI status at MUKTASoft remain unchanged to In Process
All beneficiaries payment status remain unchanged to Payment In Process
Option to refresh the status is provided. It triggers call of FTPS.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of FTPS API: Response is received and updated successfully]
PI status at the MUKTASoft changes to Completed.
The beneficiaries payment status is changed to Payment Successful.
No action is enabled.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
In Process
In Process
Payment In Process
Refresh
FTPS
2
Response With Error
In Process
In Process
Payment In Process
Refresh
FTPS
3
Response Without Error
In Process
Completed
Payment Successful
No Action
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
To all the beneficiaries:
Payment of Rs. {amount} for MUKTA, transaction <UTRNO> is made to your registered bank account. Contact your bank if not credited within 72 hours. MUKTA - Govt. of Odisha.
View Payment Instruction
API is called and status is fetched and updated for both PI and Beneficiary.
SMS notification is sent to all the beneficiaries.
Status is reflected in View Payment Instruction Page.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
Payment Instruction
Status Update API Call
Employee
Role: System
Payment instruction status (PIS) is the API to fetch the PI status from JIT.
Once a PI is accepted at JIT, it is then approved with a digital sign by SSU in JIT.
The approved ones only has the Payment Instruction ID and Date available in response.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every PIS call.
The API call to be scheduled once in a day at 10:00PM every day for the Payment Instructions Initiated, and the Payment Instructions Declined having error “Duplicate Payment Information Id”.
#
Parameter
Is Mandatory?
Description
1
jitBillNo
Yes
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
2
jitBillDate
Yes
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
3
ssuIaId
Yes
Special spending unit ID. A master value maintained in JIT-FS.
#
Parameter
Description
1
pmtInstId
The unique id of payment instruction that’s been generated at JIT.
2
payInstDate
The date of payment instruction created.
3
jitBillNumber
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
4
jitBillDate
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
5
ssuIaId
Special spending unit ID. A master value maintained in JIT-FS.
6
billNetAmount
Net bill amount sent in the PI
7
billGrossAmount
Gross bill amount sent in the PI
8
schemeCode
Scheme code under which PI is created
9
totalNumberOfBeneficiary
Total beneficiary count
Error message displayed on View Payment Instruction Page. [Message: On call of PIS API: No response is received.]
PI status at MUKTASoft remain unchanged to Initiated.
All beneficiaries payment status remain unchanged to Payment Initiated.
Option is given to user to refresh the status. On refresh API call is triggered.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of PIS API: <JIT error message>]
PI status at MUKTASoft remain unchanged to Initiated.
All beneficiaries payment status remain unchanged to Payment Initiated.
Option is given to user to refresh the status. On refresh API call is triggered.
If the PI is rejected by SSU user, the same is received in error message.
Error message displayed on View Payment Instruction Page. [Message: On call of PIS API: <JIT error message>]
PI status at MUKTASoft changes to Rejected.
All beneficiaries payment status changes to NA.
A reverse expense transaction is recorded under Fund Allocation Register.
Option to generate new PI is provided from View Payment Instruction Page.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of PIS API: Response is received and updated successfully]
PI status at the MUKTASoft changes to Approved.
All beneficiaries payment status remain unchanged to Payment Initiated.
Option to refresh the status is provided. It triggers call of PAG.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Initiated
Initiated
Payment Initiated
Refresh
PIS
2
Response with Error Others
Initiated
Initiated
Payment Initiated
Refresh
PIS
3
Response with Error Rejected
Initiated
Rejected
Payment Initiated
Generate New PI
PI
4
Response Without Error
Initiated
Approved
Payment Initiated
Refresh
PAG
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable
View Payment Advice
There is scheduler running to fetch the PI status and updated at MUKTASoft.
Status is updated based on response received.
Both the statuses are reflected in View Payment Instruction.
Option to Generate Revised PI is given to user through View Payment Instruction Page.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying based on schedule until a response is received. The latest response is recorded in the log.
Payment Instruction
Search Payment Instruction to Generate Revised PI
Employee
Role: Accountant
Home Page > Payment Instructions > Search Payment Instruction
Search Payment Instruction to be provided to list all the PIs which have the failed transaction and the revised PI to be generated for them.
Two types of searched to provided with 2 different tabs.
Pending for Action
Open Search
Below are the search parameters to search such payment instructions.
#
Parameters
Description
1
Ward
Drop-down, with the ward name as values.
2
Project Type
Project Types
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”
“Pending for Action” tab is displayed by default with the search result of PIs which are pending for action. It means.
The payment instructions which have the status Completed, Declined, and Pending.
Additional condition for Completed PI, It should have at least one beneficiary payment status as Payment Failed .
Open Search, it will allow users to search any payment instruction and view the details.
In this case, at least one parameter is must to search.
For name, fuzzy search is enabled.
Created from and To are considered as one parameters as date range.
#
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
Not applicable
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable
Search enables users to see the pending correction PI by default.
Search for any PI is also provided to search and view the details.
Payment Instruction
Status Update for Payment Failed Status from revised PI
Employee
Role: System
Failed transaction failed payment (FTFPS) is the API to fetch the failed payment details from JIT.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every FTFPS call.
The API call to be scheduled once in a day at 10 PM for Completed payment instructions.
#
Parameter
Description
1
jitCorBillNo
Revised PI ID generated in MUKTASoft and pushed for failed transactions into JIT
2
jitCorBillDate
Revised PI date generated in MUKTASoft and pushed for failed transactions into JIT
3
billRefNo
Online bill reference number for revised/current PI
4
tokenNumber
Token number generated in JIT.
5
tokenDate
Token date generated in JIT.
#
Parameter
Description
1
jitCorBillNo
Revised PI ID generated in MUKTASoft and pushed for failed transactions into JIT
2
jitCorBillDate
Revised PI date generated in MUKTASoft and pushed for failed transactions into JIT
3
billRefNo
Online bill reference number for the current revised PI.
4
tokenNumber
Token number generated in JIT.
5
tokenDate
Token date generated in JIT.
Beneficiary Details
7
benfAcctNo
Beneficiary’s account number.
8
benfBankIfscCode
Beneficiary’s bank / branch IFSC.
9
utrNo
Unique transaction reference number used by banks to reconcile the transaction.
10
utrDate
UTR date.
11
endToEndId
It is generated to identify a beneficiary for a transaction while it is pushed to CPC for payment clearance.
12
orgBillRefNumber
Original online bill reference no.
13
challanNumber
Challan number
14
challanDate
Challan date
15
failedReason
Account related errors, Like account that doesn't exist.
16
benfId
Beneficiary unique ID, unique to transaction.
Error message displayed on View Payment Instruction Page. [Message: On call of FTFPS API: No response is received.]
PI status at MUKTASoft remain unchanged to Completed.
Beneficiaries payment status remain unchanged to Payment Successful.
No action is enabled.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of FTFPS API: <JIT error message>]
PI status at MUKTASoft remain unchanged to Completed.
Beneficiaries payment status remain unchanged to Payment Successful.
No action is enabled.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of FTFPS API: Response is received and updated successfully]
PI status at the MUKTASoft remain unchanged to Completed.
The beneficiaries for which details is received in response, the payment status changes to Payment Failed.
Option to generate revised PI is enabled. It triggered the COR API call.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Completed
Completed
Payment Successful
No Action
2
Response With Error
Completed
Completed
Payment Successful
No Action
3
Response Without Error
Completed
Completed
Payment Failed
Generate Revised PI
COR
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
To beneficiary for which failure details is received:
Payment of Rs. {amount} for MUKTA, transaction <UTRNO> is failed. Contact MUKTA Cell at ULB for more detail. MUKTA - Govt. of Odisha.
View Payment Instruction
API is called and payment status is fetched and updated for the beneficiaries.
SMS notification is sent to beneficiary for failed transaction.
Status is reflected in View Payment Instruction Page.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
Payment Instruction
View Payment Instruction
Employee
Role: Accountant
View Payment Instruction to be provided to view the detail and track the status of Original/ Revised Payment Instructions.
Below is the details which is displayed for a payment instruction.
#
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 individual ID of wage seeker/ organization ID for CBOs and vendors, and displayed as hyperlink to view details.
16
Payment ID
Unique beneficiary ID for the payment through JIT. It remain same though the process until the payment becomes successful.
17
Beneficiary Name
Name of the beneficiary.
18
Account Number
Account number of beneficiary, only 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 beneficiary.
Info
In case of there are failed payments, an information is displayed. “Please make sure all the necessary corrections are made before generating the revised payment instruction for JIT” .
Not applicable.
Not applicable.
Not applicable.
Not applicable.
For Pending and Declined Payment Instruction.
Re-submit - Payment instruction is re-push again.
A success toast message is displayed on successful submission and the status of PI changes to Initiated. [*The payment instruction is submitted successfully.*]
In case, the PI is decline again, the toast message is displayed with the error message and the status of PI remain Declined. [*Submission failed, <error message>*]
2. For Completed Payment Instruction which has at least one failed payment.
Generate Revised PI - A revised PI is generated and push to JIT after clearing all the errors.
A success toast message is displayed on successful submission with the PI ID displayed in message. [*Revised payment instruction <PIID> generated and submitted successfully.*]
In case revised PI is declined, a failure toast message is displayed with the PI ID generated for revised PI. [*Revised payment instruction <PIID> generated successfully, but failed to submit.*]
Not applicable
Payment instruction details is displayed as described in the story.
Actions are enabled based on the status of current payment instruction.
Payment instruction id is generated according to format defined in case revise PI is generated.
Appropriate messages are displayed with each action.
Edit Work Order action is to be mapped with Work Order Creator.
It is configurable and can to mapped with other roles too on demand.
The work order which is in the workflow can only be edited.
Rejected, Approved, and Accepted work orders can not be edited.
Edit work orders allows the user to edit the below-given work order detail.
1
Work order number
Display Only
NA
Work order no.
2
Project ID
Display Only
NA
Project ID of the project.
3
Date of proposal
Display Only
NA
Date of the proposal from the project.
4
Project name
Display Only
NA
Project name
5
Project description
Display Only
NA
Project description
6
Project Details
Tab
Displayed as per view project details.
7
Estimate Details
Tab
Displayed as per view estimate details.
8
Work Order Details
Tab
9
Name of CBO
Drop-down
Y
The name of the CBO from the organization master maintained at the ULB level. The name is searchable in the drop-down.
10
CBO ID
Display
Y
The CBO ID from the organization registry.
11
Role of CBO
Drop-down
(Auto- selected)
Y
The role of the CBO is decided based on the estimated amount. It is configurable in the system.
IP (Implementation Partner) - If the estimated cost of the works is more than Rs.15 Lakhs
IA (Implementation Agency) - If the estimated cost of the works is up to Rs.15 Lakhs
12
Name of the officer in-charge
Drop-down
Y
The drop-down values are population based on the role assigned. The name is searchable in the drop-down. Name + Designation
13
Designation of officer in-charge
Display
Y
Displayed from the EIS/User’s record saved in the system.
14
Project completion period
Numeric
Y
Number of days work to be completed.
15
Work order amount
Read Only
Y
Total estimated cost of the selected work.
Relevant Documents
Sections
16
BOQ
File Attachment
Y
Allows single file, not greater than 5 MB. Files can be of type doc, xls, pdf, jpg.
17
Labour Analysis
File Attachment
Y
Allows single file, not greater than 5 MB. Files can be of type doc, xls, pdf, jpg.
18
Material Analysis
File Attachment
Y
Allows single file, not greater than 5 MB. Files can be of type doc, xls, pdf, jpg.
19
Terms and conditions
File Attachment
Y
Allows single file, not greater than 5 MB. Files can be of type doc, xls, pdf, jpg.
20
Others
Textbox
N
To capture the file name
21
File Attachment
N
To attach the file file the name entered above in the textbox.
Once the work order is edited, it is re-submitted for approval using the Submit action button.
Not applicable.
Based on the logged-in user role, a workflow pop-up window is displayed on submit.
Work Order Creator
Submit pop-up window
Work Order Verifier
Verify and Forward pop-up window
Approver
Approval pop-up window
On respective workflow action, changes get saved and the work order is forwarded to the next user in the workflow.
On Cancel, the pop-up window gets closed and the action gets cancelled.
Accordingly, the messages are shown.
<To be updated>
1
Role-based access based on configuration.
2
The work order which is in the workflow can only be edited.
3
The work order is opened in editable mode.
4
The details given in the table can be edited by the user.
5
On Submit, the work order is again forwarded to the next user for approval.
Request for time extension on projects.
CBO: My Works → Request Time Extension
CBO
Role: CBO ADMIN
My Works lists all the work orders which are assigned to logged-in CBO and are segregated by In Progress and Completed works.
Work orders for which at least one muster roll is created and approved are allowed to create the time extension request.
Also for that project closure request should not be created.
In the action menu, the Request Time Extension option is displayed only if the above 2 conditions are met.
Each work order card will have the below attributes displayed:
Work order number
Project description
Role of CBO
Officer-in-charge
Issue Date
Due Date
Work order amount
Status
View Details - Link to view the complete details of the work order.
Request Time Extension - Action button. [This action is shown only when at least one muster roll is submitted and approved]
On creating a time extension request,
A window to capture the requested extension for the completion period in days is displayed.
CBO enters the below details and submits the request.
Extension Period (in days) - Mandatory
Reason for Extension - Mandatory
On Request Time Extension - In case the first muster roll is pending to submit for approval.
Not even a single muster roll has been approved for the project. Please ensure that the first muster roll is submitted for approval.
Not applicable.
On submit,
A time extension request is created and sent for verification/ approval.
The request ID is generated as per the specified format. ID: TE/2022-23/000021.
Not applicable.
On successful submission, the success page is displayed.
On failure, a common failure page is displayed.
The request ID is generated as per the specified format.
Payment Instruction
Re-push revised PI for failed transactions
Employee
Role: Accountant
Home Page → Billing → Search Bills → Open Bill → Generate Revised PI
Failed Transaction Correction (COR) is the API to push revised PI to JIT.
A new PI is generated at MUKTASoft to push it as revised PI.
MUKTA accountant login in MUKTASoft open the bill screen and initiate revised PI.
For Request/ Response parameters, please refer the integration approach document.
The response data is stored and maintained at MUKTASoft for every COR call.
API is called with an action is triggered by user from View Payment Instruction Page.
#
Parameter
Description
2
jitCorBillNo
Revised PI ID of the PI generated at MUKTASoft to re-push failed transactions into JIT
3
jitCorBillDate
Revised PI date of the PI generated in MUKTASoft to re-push failed transactions into JIT
4
jitCorBillDeptCode
Application code, e.g. MUKTA.
5
jitOrgBillRefNo
Original viz. first (parent) bill reference no. of online bill which was received in the PAG response.
6
jitOrgBillNo
Original viz. first (parent) MUKTASoft PI ID.
7
jitOrgBillDate
Original viz. first (parent) MUKTASoft PI date.
Beneficiaries Details
8
benefId
Beneficiary ID, Beneficiary id of the failed transaction.
9
jitCurBillRefNo
Latest failed transaction bill reference number viz. The PI for which failure is reported (Original/ Revised)
10
orgAccountNo
Original Account Number, The one which was pushed in first PI.
11
orgIfsc
Original IFSC, , The one which was pushed in first PI.
12
correctedAccountNo
Corrected account number, recent corrected account number corrected for this revised PI.
13
correctedIfsc
Corrected IFSC, recent corrected IFSC corrected for this revised PI.
14
curAccountNo
Current account number which was pushed in just previous PI for which failure is reported.
15
curIfsc
Current IFSC which was pushed in just previous PI for which failure is reported.
#
Parameter
Description
2
jitCorBillNo
Revised PI ID, created in MUKTASoft and then pushed to JIT
3
jitCorBillDate
Revised PI date, created in MUKTASoft and then pushed to JIT
4
successCode
0 - Success
5
sucessDescrp
JIT Correction Bill is received successfully ,Forwarded to Treasury officer to generate Return adjust Bill
PI is created and saved at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of COR API: No response is received.]
PI status at MUKTASoft updated to Pending.
Beneficiary payment status changes to “Payment Pending”.
Option to re-push the PI is provided, and the same time system will try to push all such PI once in a day at 9PM every day.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of COR API: <JIT error message>]
PI status at MUKTASoft is updated to Declined.
Beneficiary’s payment status will change to “Payment Pending”.
Option to re-push the PI after clear the error is provided from View Payment Instruction Page.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of COR API: Response is received and updated successfully]
PI status at the MUKTASoft changes to In Process.
Beneficiary’s payment status will change to Payment In Process.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Pending
Payment Pending
Resubmit
COR
2
Response With Error
Pending
Declined
Payment Pending
Resubmit
COR
3
Response Without Error
Pending/ Decline
In Process
Payment In Process
No Action
Note: PIS and PAG calls are skipped for revised PI.
Make sure the payment instruction ID is unique and no PI has already been pushed with same PI ID. [Message: Duplicate payment instruction ID.]
Make sure PI doesn’t have duplicate beneficiary. i.e. same a/c and ifsc cannot be repeated. [Message: There are 2 or more than 2 beneficiaries having same account number and IFSC.]
Beneficiaries original account no /IFSC/Bifid is not matching with correction file – Make sure parameter values passed are correct. [Message: The beneficiary <paymentid> was not present in the original payment instruction.]
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable
The format used for Original Payment instruction is followed.
View Payment Instruction
Revised PI is generated and pushed to JIT.
All the validations are taken care which are applicable to Original PI.
PI ID is generated as per the format defined or original PI.
If the PI is declined, the same one can be modified and re-pushed.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
MUKTA Dashboard comes with around 21 KPIs visulization covering the action items, tracking the status of attendance, expendutire and payments.
Count of Projects where WO start date is in the selected date range and WO end date + X days is less than todays date. Let X be configurable.
For ex. Selected time period is Jan 1 to Jan 15. WO start date is Jan 7th, end date is Jan 31, X is 7. From 8Feb 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”
Count of Bills that are created (Automatically or manually) in the selected date range and but current status(as of today) is not Paid/Payment done (Whichever is final state of Bill)
Considers all types of Bills
Show Amount as well of these bills as designed in mockup
On Hover show “ Bills created in the selected time period but payment is not done as of today”
Number of Projects that are created in the selected time period and Work Orders are not yet created. (PS: Both are create dates only though text says issued.)
On Hover show text “ Projects created but Work Orders not created”
Count of weeks across all work orders that are in progress (Accepted by SHG) but Muster Roll is not created.
If Contract start date is Jan1st (Mon) and user hasn't created muster rolls until Jan 31, Number of Muster rolls not created are 4 for this project. If User Submits any 2 of them on Feb 1st, then remaining 2 should be shown.
On hover show “Work weeks completed but muster rolls not submitted to ULBs”
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 on-wards till date this will be counted as SLA breach.
Parallel there could be other estimates in other workflow statuses too which have their respective SLA breaches.
All these will be accumulated to form SLA breach of Estimates.
If estimate is moved to next workflow state, this count will go down until the breach happens again.
All SLA breaches below KPIs follow same Logic.
Includes only until contract issuance. Contract Acceptance by SHG breach is not counted as SLA breach for this metric.
Muster roll approval breaches SLA.
Only for Purchase Bills in V1.
Leadboard: Information in tabular form.
Serial Number
Numbers.
Show Max 5 in default table view.
If there are less than 5 rows (Pilot use-case) show only that number of rows. Don't show empty rows
ULB
List of ULBs.
Project delayed
The same KPI definition from Action Items.
Pending bills
The same KPI definition from Action Items.
WO not issued
The same KPI definition from Action Items.
Muster rolls not created
The same KPI definition from Action Items.
Only three statuses will be shown for projects.
Created - All projects that are created in 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 project is officially not closed)
Closed - Projects that are created in the selected time period and Work Order is closed in the past already
No Hover Text
Only three statuses will be shown for Estimates.
Created - All estimates that are created in selected time period
Yet to Approve - Number of Estimates that are created in the selected time period but estimate is not finally approved (Didn't reach final status)
Approved - Number of Estimates that are created in the selected time period and approved in the past
No Hover Text
Five statuses will be shown for Contracts.
Created - All Contracts that are created in selected time period
Yet to Approve - Number of contracts that are created in the selected time period but contract is not finally approved (Didn't reach final status)
Yet to Accept - Number of contracts that are created in the selected time period but not Accepted by CBO as of Date
In Progress - Number of contracts that are created in the selected time period and Accepted by CBO in the past but not closed yet, irrespective of contract closure date.
Closed - Number of contracts that are created in the selected time period and closed in the past
No Hover Text
Only three statuses will be shown for Muster Rolls.
Submitted - All MRs that are created and Submitted (Combined action) in selected time period
Yet to Approve - Number of MRs that are created in the selected time period but Approval is pending (Didn't reach final status)
Approved - Number of Estimates that are created in the selected time period and approved in the past
No Hover Text
Work order is created for an approved estimate in order to award the work to CBO and then send it for the approval process. The approval process contains various workflow levels and states associated with those levels.
Work order preparation for a work by the Work Order Creator and then its verification and approval by other users (actors) in the workflow.
1
WORK ORDER CREATOR
Create
Search
View
Edit/ Re-submit
Submit
Reject
Junior Engineer/ Assistant Engineer
2
WORK ORDER VERIFIER
Search
View
Verify and Forward
Send Back
Executive Officer
3
WORK ORDER APPROVER
Search
View
Approve
Send Back
Send Back To Originator
Reject
Municipal Engineer
4
CBO ADMIN
Accept
Decline
Community based organization contact person (President/ Secretary)
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 Originator
<any roles having access>
<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
9
Accept
CBO Admin
Approved
Accepted
Accepted
10
Decline
CBO Admin
Approved
Pending for re-assignment
Declined
11
Edit/ Re-submit
Work Order Creator
Pending for re-assignment
Pending for verification
Re-submitted
Work Order
Edit/ Re-submit
Pending for correction
1
Edit/ Re-submit
Pending for re-assignment
1
Verify and Forward
Pending for verification
2
Approve
Pending for approval
1
Accept
Approved
7
UI design is going to be the same as the estimate workflow. Only the workflow states will be displayed as per the table given above.
1
Actions are configured based on role-action mapping.
2
Workflow states are defined as provided and the state transition is done accordingly.
Projects that are created in the selected time period by project type
Show total project count within the PIE.
Switching to Amount should show same split by Amount instead of Count
Default Action on Hover
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 time-frame.
Show total Amount in the PIE
Switching to number should give number of bills the above KPI refers to while calculating amount.
Default line chart component
Behavior same with respect to filters
Amount Paid by Bill Type Aggregated by Months.
IF JIT integration is done by the time you are reading this, KPI should be the actual Amount transferred (Response from JIT) by Bill Type aggregated by Months.
IF JIT Is not done by now, Bill Final State (Payment done)by Bill Type aggregated by Months.
On Hover show: All 3 KPIs in that vertical column with actual Amounts
Payments are the same as represented in the bar chart and filtered only by wage bill.
On Hover show: Month and Actual Amount
The number of Approved Person Days considered in Muster rolls created for Wage seeker Bills amounting to above KPI.
On Hover Show: Month and Actual Person Days
Table showing payments made to Wage Seekers by gender in the selected time period. Considers wage bills where final approval status and beneficiary status reflect payment done.
Average days of employment - Average Approved Days by gender from muster rolls created in a selected time frame.
Average Payment - Average Payment made by gender in the selected time period where the status of beneficiary turned to paid.
This is an Umbrella story for MUKTA Dashboard. Gives high level description details along with standard components.
V1 Dashboard has 25 KPIs - 8 Simple numbers and 17 in Charts Design
Should filter the dashboard data by selected District.
Multi select should be enabled.
Should filter the dashboard data by selected District.
Multi select should be enabled.
Should be drilled down from District that is selected.
Cr, Lac, Unit as per DIGIT standard
Share
Email, Whatsapp as per DIGIT standard
JPEG as per DIGIT Standard
Define a single role called “MUKTA Dashboard Viewer” whoever has that access should have Dashboard link on left navigation menu and home page card links.
Use same dashboard Icon as per DIGIT standard.
Clicking on link will land user directly on dashboard Home with no filters applied.
All filters, Denominations, Share and Download options to work as standard and expected.
All Cards will by default have menu individually(three dots). This will download image or share that card in that visualization to JPEG (Default DIGIT behavior)
Schedule of rates
The scheduled items for which the works department publishes the rates are known as schedule of rates. There are mainly 4 types of items for which schedules of rates are published.
Material - These are the material items which are required to accomplish a work.
Labour - The skilled and unskilled laborers which are required to accomplish the work.
Machinery - These are the equipment which are required to accomplish the work.
Works - The composition of material, labours, machinery together to form a building block for a work.
Detailed Estimation of Project
After getting administrative approval on a pre-estimation of project cost a detailed estimate is prepared. It helps to capture the measurement of works in details estimate the cost accurately in terms of predicting the cost, material, labour, and machinery required to complete the work. It is also used for tendering and contracting the work.
View Detailed Estimate
Search Estimate → View Estimate.
No change.
There is no change in existing search estimate.
Changes are for the attributes added newly.
Estimate Number
Estimate Type
Project ID
Project Sanction Date
Project Name
Project Description
Project Details [*The project details is shown as view project detail in a separate TAB*]
Estimation Details
SORs - Below information is displayed in the grid.
Type
Code
Description
UOM
Rate
Quantity
Amount
Measurements
Type
Description
Numbers
Length
Breath
Height/ Depth
Quantity
Total
Not applicable.
Not applicable.
For In Workflow Estimates, actions in Action Menu, workflow actions based on the role of logged-in user.
Save as Draft
Verify and Forward,
Technical Sanction
Approve
Send Back
Send Back To Originator
Edit Estimate
Reject
Not applicable.
Same as create estimate in real only mode.
Estimate details is displayed as described in the story.
Actions are enabled as per the estimate workflow state and role logged-in user has.
Measurement Book
The measurement book is a most important record. It is the basis of all accounts of quantities of work done, purchase made and it must contain such a complete record of facts as to be conclusive evidence in court of law.
It is the basis of all accounts of quantities whether of works done by Contractors or by laborers employed departmentally, or materials received. It is so written the transactions are readily traceable.
A mobile application to be developed for employees to facilitate on-the-ground measurement capture and seamless integration with the system.
Key functionalities of the system include login, searching work orders, managing Measurement Books (MB) with features such as creating and saving as a draft, submitting for verification, editing MB, and verifying and approving MB. Users can also view existing Measurement Books.
MUKTASoft seamlessly integrates with AADHAAR to ensure the unique identification of MUKTA beneficiaries/wage seekers by authenticating the AADHAAR number provided during the registration process.
Inbox for Employees
Employees
Inbox page for employees to be developed duly taking care of the MUKTA branding aspect.
The inbox of employees is divided into 4 sections.
Menu Title
Product Name
Menu Links
Create Work Order - It will take the user to the search estimate page.
Search Work Order - It will take the user to search work order.
Search Parameters
Work order number
Project ID
Project type
Filters
Assigned to me - It displays the work orders in the inbox which are assigned to the logged-in user.
Assigned to all - Selected by default, It displays the work orders in the inbox which are pending for action of role(s) logged-in users have.
Ward - Multi-select
Locality - Multi-select
Workflow state - state of the workflow of the work order.
Result Display Area
Work order number
Project name
CBO name
Assignee
Workflow state
Work Order Amount
SLA days remaining
It should be a DIGIT standard Inbox that allows to configure based on a request from the implementation.
Not applicable.
Not applicable.
Menu links and Search, Filter apply and Numbers h.yperlinks.
Not applicable.
1
It should be a service-wise inbox for all the employee users.
2
Following the DIGIT standard inbox design.
Hence for Work Order Creator, the On Submit pop-up window is opened to capture the below-given details.
Assignee name- Drop-down - Non Mandatory - The next user in the workflow i.e. work order verifier hence the employees having the role Work_Order_Verifier are displayed in drop-down with the Name and Designation. E.g. Suresh K working as Junior Assistant Executive Engineer and having the role of work order verifier will be displayed ‘Suresh K - Assistant Executive Engineer’.
Comments - Text area - Non-Mandatory - In case any comments to be added.
Forward - Action Button
Cancel - Action Button
On Forward,
The pop-up window is closed, a toast success message is displayed and the view work order page is refreshed.
The action menu is loaded according to the role-action mapping of the currently logged-in user.
The work order is forwarded to the next user in the workflow and shown in its inbox.
The workflow state changes accordingly and timelines show the current state of the estimate.
Work order is removed from the currently logged-in user’s inbox.
Submit/ Forward
Work Order Creator
Pending for verification
Submitted
Re-submit/ Forward
Work Order Creator
Pending for correction
Pending for verification
Re-submitted
On cancel, a pop-up window is closed, toast cancel message is displayed on the view work order page.
Toast Success Message:
The work order is forwarded successfully.
Failure Message:
Forward of work order failed.
Toast Cancel Message:
Action is cancelled.
Not applicable.
Not applicable.
1
On submission, the application is forwarded to the next user in the flow.
2
The pop-up window gets closed and the application page is refreshed. A toast success message is displayed.
3
On cancel pop-up window is closed. A toast cancel message is displayed.
4
Workflow states change and based on the role the existing user has view work order page refreshes.
Verify and forward the work order to the next workflow user.
Employees
The Verify and Forward action is provided with a pop-up window to capture the below-given details.
Assignee name- Drop-down - Non Mandatory - The next user in the workflow i.e. Approver, hence the employees having the role Work_Order_Approver are displayed in drop-down with the name and the designation. E.g. Mahesh K working as EO and having the role of Work_Order_Approver will be displayed as ‘Mahesh K - Executive Officer’.
Comments - Text area - Non-Mandatory - In case any comments to be added.
Attach Supporting Document - Non-Mandatory - Any document to be uploaded as a supporting document.
Verify and Forward - Action Button
Cancel - Action Button
The pop-up window is closed, toast cancel message is displayed on the view work order page
On Verify and Forward,
A pop-up window is closed, the toast success message is displayed and the view work order page is refreshed.
The action menu is loaded according to the role-action mapping of the currently logged-in user.
The work order is forwarded to the next user in the workflow and shown in its inbox.
The workflow state changes accordingly and timelines show the current state of the work order.
Work order is removed from the currently logged-in user’s inbox.
Work Order Verifier
Pending for verification
Pending for approval
Verified
Toast Success Message:
The work order has been forwarded successfully.
Failure Message:
Verification of work order failed.
Toast Cancel Message:
Action has been cancelled.
Not applicable.
1
Verify and forward pushes the work order to the next user in the flow.
2
The pop-up window is closed and the view work order page is refreshed. A toast success message is displayed.
3
Workflow states change, and based on the existing role the user can view the work order page on refresh.
4
On cancel pop-up window is closed. A toast cancel message is displayed.
For approval of work order.
Employees
For the approval of the work order, action Approve is provided and the below given detail is captured in a pop-window on approval.
Comments - Text area - Non-mandatory
Attach Supporting Document - Document upload - Non-mandatory
Approve - Action Button
Cancel - Action Button
On Approve,
The work order is approved.
Approve pop-up window is closed, a toast success message is displayed and the view work order page is refreshed.
Workflow timelines are displayed accordingly.
Workflow state changes as given below.
Work Order Approver
Pending for approval
Approved
Approved
On cancel, the toast cancel message is displayed.
Toast Success Message:
Work order has been administratively approved successfully.
Failure Message:
Approval of work order is failed.
Toast Cancel Message:
Action has been cancelled.
SMS to the Work Order Creator
Work Order <work order no.> for the project <projectname> of the location <location> has been approved and sent to <CBOName> for acceptance. For more detail please login to MUKTASoft to view the estimate details.
SMS to the CBO
Dear <contactpersonname>, <organisationname> has been chosen as the <IA/IP> for the project <project name>. Please accept the work order <WO_NUMBER> before <duedate> to avoid auto cancellation. To login please click on <Organization Login URL>.
1
On approve, work order workflow state changes accordingly.
2
On approve, notification is sent to work order creator.
Reject the work order.
Employees
To reject the work order, action is provided to capture the below-given detail and reject the work order.
Comments - Text area - Mandatory
Attach Supporting Document - Document upload
Reject - Action Button
Cancel - Action Button
On Reject,
The pop-up window is closed, toast reject message is displayed.
The work order page is refreshed. No actions are enabled for the rejected work order.
The work order creator is informed about the rejection of the work order through SMS notification.
Workflow state changes as given below.
<the role having access of reject action>
<Current State>
Rejected
Rejected
3. On cancel, a toast cancel message is displayed on the view work order page.
Toast Success Message:
Work order has been rejected successfully.
Failure Message:
Rejection of work order is failed.
Toast Cancel Message:
Action has been cancelled.
SMS to the creator’s mobile
Work order <work order no.> for the project <project name> of the location <location> has been rejected by <username+designation>. For more detail please login to MUKTASoft to view the work order details.
1
On reject, the work order is rejected and the workflow state/status changes accordingly.
2
No further actions can be performed on a rejected work order.
3
Notification is sent to the work order creator.
Search a work order by various ULB Employees/ users.
Employee
Role: Work Order Creator, Work Order Verifier, Work Order Approver.
Search Work Order- It has to be configurable and is mapped with a role on demand.
Search Work Order is provided to allow the users to search for a work order and view its details.
1
Ward
Drop-down
Auto-complete, matching search. The values populated from ward boundary master data.
2
Project type
Drop-down
Project type masters value
3
Project name
Textbox
Project name
4
Work order number
Textbox
Work Order number, unique identification no.
5
Status
Drop-down
Workflow state of a work order.
6
Created From Date
Date Picker
Work Order creation date.
7
Created To Date
Date Picker
Work Order creation date.
At least one parameter is required to perform the search.
The date range From Date/ To Date is considered one parameter.
An exact search is performed for the values entered/selected except the project name.
For project name fuzzy search to be enabled.
In case multiple parameter values are supplied AND are applied for searching record.
The search result is shown as given below.
1
Work order number
Display Only
A hyperlink to open the work order in view mode.
2
Project name
Display Only
Project name with project description displayed as tool-tip on mouseover
3
Name of CBO
Display Only
Name of the organization to whom Work Order is awarded.
4
Role of CBO
Display Only
Role of CBO, IA/IP
5
Location
Display Only
Locality name along with ward name. (Locality + Ward)
6
Status
Display Only
Workflow status of the work order.
7
Work order amount
Display Only
Total WO amount.
At least one parameter is required to perform the search.
Search - To search the result upon supplying the values of the parameters.
Clear Search - To clear the search parameters supplied.
Not applicable.
1
At least one parameter is required to perform the search.
2
Search results are displayed on matching records found else no record found message is displayed.
3
Pagination is applied if more than 10 records are found.
Generate a pdf copy of the work order.
Employees
The Work Order PDF has 6 main sections.
Header - Municipality Info and Work Order No. and Amount.
Work order is addressed to either JE/AE or CBO.
The subject section
The content of the work order body
The work order issue detail
Footer - Terms and Conditions
Conditions
In case the CBO role is defined as the Implementation Agency
The work order is addressed to CBO only.
<Officer Incharge/ CBO> ---> <CBO Name>
<Implementation Agency/ Implementation Partner> ---> <Implementation Agency>
In case the CBO role is defined as Implementation Partner
The work order is addressed to JE and CBO both, JE’s name comes first.
<Officer Incharge/ CBO> ---> <Officer In-charge Name>
<Implementation Agency/ Implementation Partner> ---> <Implementation Partner>
Other variables -
SLA Days - maximum days are given to CBO to accept the work order.
Due Date - Work order approval date + SLA Days
1
Design should be as per Figma.
2
Conditions are fulfilled.
Send the work order back to the previous user in the workflow.
Employees
Send Back action is provided with the below details to be captured.
Comments - Text area - Non-mandatory - It is provided to add any remarks/instructions to be passed on to the previous user in the workflow.
Attach Supporting Document - Document upload - Non-mandatory - In case any documents are to be attached.
Send Back - Action Button
Cancel - Action Button
On Send Back,
The pop-up window is closed, and a toast success message is displayed.
The view work order page is refreshed and the action menu is loaded according to the role of the logged-in user.
The work order is sent back to the previous user’s inbox.
Workflow states change as per the flow.
On cancel, the toast cancel message is displayed on top of the view work order page.
Toast Success Message:
Work order has been sent back successfully.
Failure Message:
Sending back of work order is failed.
Toast Cancel Message:
Action has been cancelled.
Not applicable.
Send the work order back to the originator’s inbox for any correction required.
Employees
It is provided to send the work order back to the originator’s inbox for any correction required. Below given detail is captured.
Comments - Text area - Non-mandatory - It is provided to add any remarks/ instructions to be passed to the originator of the work order.
Attach Supporting Document - Document upload - Non-mandatory - In case any documents are to be attached while sending the work order back to the originator.
Send Back - Action Button
Cancel - Action Button
On Send Back -
The pop-up window is closed and a toast success message is displayed.
The view work order page is refreshed and the actions menu is loaded according to the role the logged-in user has.
The work order is placed into the work order creator’s inbox.
The ‘Edit Work Order’ option is provided to Work Order Creator to edit the work order and attached the new documents files and Re-submit it.
Workflow state changes as given below.
On cancel, the pop-up window is closed, toast cancel message is displayed on the view work order page.
Toast Success Message:
Work order has been sent back to the creator successfully.
Failure Message:
Sending back of work order is failed.
Toast Cancel Message:
Action has been cancelled.
Not applicable.
Once an estimate is prepared and approved, the next step is to award the work to a contractor, to decide the various methods used like Tendering, Quotation and Nomination. Once a contractor is decided a work order is created in the favor of the contractor.
In MUKTA, it is a nomination method to decide a CBO (community-based organization) and then the work order is created in the name of that organization.
Create Work Order
Search Estimate → View Estimate → Create Work Order.
Employee
Role: Work Order Creator
CBO to whom the work is awarded is decided offline and then the work order is created in the name of CBO.
Create Work Order form is developed as per the UI design provided and the attributes listed below.
To create the work order estimate is searched and opened to view the details. From the action menu Create Work Order is selected.
Field-level validations as mentioned in the attribute tables.
Organization-type community-based organizations from the organization master maintained at the ULB level are only allowed.
Only Active and Valid To >= Work Order Created Date, organization are listed under drop-down or allowed to search. The organization with the status “Inactive” and “Debarred” are not listed irrespective of valid to date.
The minimum value for the work completion period should not be less than 1 day.
The Role of CBO drop-down is selected automatically by the system based on the configuration provided.
IF the total estimated amount <=15 lakhs THEN the Role of CBO = IA AND the role can be changed by the user.
IF the total estimated amount is >15 lakhs THEN the Role of CBO = IP AND the role can not be changed by the user.
The amount limit deciding the role of CBO should be configurable. At present it is 15 lakh.
The stories for configuring the workflow are given separately.
On Submit
Submit workflow opens a pop-up window with the Forward option.
The work order record is saved into the system and the workflow state changes to Pending for verification.
The Work Order No. is generated in a specified format, if it is a direct submission.
Format for Work Order No. is WO/FY/<6digitrunningno.>. Example: WO/2022-23/000051
6 DIGIT running sequence number is reset to 1 with the start of the new FY.
The work order is available to download in PDF as per the given format. There will be a separate ticket for PDF download.
On cancel, the action is cancelled.
On successful forward the Success Page is displayed else the Failure Page is displayed.
Not applicable.
View Detailed MB
Search MB → View MB
No change.
Measurement book is searched and opened to view the details.
Below are the attributes which are displayed.
MB Reference Number
MB Number
Work Order Number
Project ID
Project Sanction Date
Project Location
Project Name
Project Description
View Measurement History
Measurement History
Sr. No
MB Reference Number
MB Date
MB Period
MB Amount
Status
Not applicable.
Not applicable.
For In Workflow MB, actions in Action Menu, workflow actions based on the role of logged-in user.
Save as Draft
Verify and Forward
Approve
Send Back
Send Back To Originator
Edit MB
Reject
Not applicable.
MB details is displayed as described in the story.
Actions are enabled as per the estimate workflow state and role logged-in user has.
Employees
Role: MB_Creator, MB_Verifier, MB_Approver
Inbox page for employees to be developed duly taking care of MUKTA branding aspect.
The inbox of employee is divided into 4 sections.
Menu Title
Product Name - MUKTA
Menu Links
Create MB- This link will take the user to Search Work Order screen to search the work order and create the MB.
Search MB- This link will take the user to Search Measurement Book screen to search MB and view the details.
Search Parameters
MB Reference Number
Project ID
Project type
Filters
Assigned to me - This filter will allow the users to filters the MB which are assigned to logged in user only and display the result accordingly.
Assigned to all - Selected by default, and allow the users to search view all the MBs which are pending to take action for a role which logged in user has.
Ward - Multi-select, to filter the MB which are created for selected projects belong to selected ward(s).
Locality - Multi-select, to filter the MB which are created for selected projects belong to selected locality(ies).
Workflow state - To apply the filter to displayed the MB which are in the selected workflow state.
Result Display Area
MB Reference Number
Project name
Assignee
Workflow state
MB Amount
SLA days remaining
It should be DIGIT standard Inbox allow to configure based on request from the implementation.
Not applicable
Not applicable
Menu Links and Search, Filter Apply and Numbers Hyperlinks.
Not applicable.
It should be a service wise inbox for all the employee users.
Following the DIGIT standard inbox design.
Work Orders Card View
Employee Mobile Application
ULB Employees
This page list all the work orders of the status “Accepted”.
Limited work order information is displayed on the card as given below.
Work Order Number
Project Description
CBO Name
CBO Role
Officer In-charge Name
Project Start Date
Project End Date
Work Value
Status
Filter - It allows the user to filter the listed work orders by the values provided.
Work Order Number
Project Name
Project ID
Project Type
Ward
None
None
None
All the work orders with status accepted are listed.
Option to sort and filter the work order is provided.
Option to view the complete Work Order details is provided.
Option to initiate new MB creation is provided.
Home Page
Employee Mobile Application
ULB Employees
Upon successful login Home Page is displayed.
The menu displayed as given below.
Work Orders
Measurement Books
Work Orders - Take the users to card views of the list of all accepted work orders.
Measurement Book - Take the users to card view of the MBs which are in workflow.
None
None
None
User is able to enter username, password and select city.
On successful login, user is allowed to login.
Measurement Book Inbox/ Card View
Employee Mobile Application
ULB Employees
This page list all the measurement books which are under workflow.
Limited MB details is displayed on the card as given below.
MB Number
Project Description
Assignee
Workflow State
MB Amount
SLA days remaining
Filter - It allows the user to filter the listed MBs by the values provided.
MB Number
Project ID
Project Name
Ward
Workflow State
None
None
None
All the MBs which are in workflow are listed.
Option to sort and filter the MB is provided.
Option to view the complete MB details is provided.
Option to initiate new MB creation is provided.
Edit Detailed Measurement Book
Home > Measurement Book> MB Inbox > Edit MB
ULB: MB Creator
A measurement book can be edited during the workflow only.
Edit of measurement book should be configurable and can be enabled for any of workflow users.
As of now it is enabled for estimate creator only.
The attributes defining detailed measurement are given in below table.
Save - It is to save the details captured for detailed MB and keeping MB with editor.
Generate Utilization- Generate the utilization statement out of saved detailed MB details.
Submit - It is to allow the user to forward the MB for verification/ next action.
View Utilization Statements - It will take the user to view utilization statement HTML page.
View MB History - To display all the MBs created so far as per the detail provided in the table above.
Changes gets save successfully.
No change in workflow state.
Toast success message is displayed.
Page gets refreshed and opened in editable mode.
Changes saved successfully.
Changes gets saved.
Utilization statements are revised.
MB is forwarded to next user in the workflow.
Toast message is displayed with success message based on the workflow state transition.
Changes gets saved.
The utilization is generated and success toast message is displayed.
Utilization statements are generated successfully.
Utilization statements generation failed.
Not applicable.
Not applicable.
Not applicable
MB can be edited during the workflow only.
Once approved it can not be edited.
Actions and messages are to be taken care.
View Measurement Book
Employee Mobile Application
ULB Employees
This page is to view MB details.
The details are as given below.
Measurement Book Primary Details Details
MB Number
Work Order Number
Muster Roll ID
Project Description
Measurement Period
MB History (Cards) - In case of first MB, this information is not displayed.
MB Number
Period
Date
MB Amount
Status
Actions - It will open up with the workflow actions according to role user is having.
Save as Draft - It will save the MB and assigned to creator.
Edit - It will open the MB in editable mode.
Submit - It will open the submit and forward workflow pop-up window.
Verify and Forward - It will open the verify and forward workflow pop-up window.
Send Back - It will open the send back workflow pop-up window.
Send Back To Originator - It will open the send back to originator workflow pop-up window.
Approve - It will open the approve workflow pop-up window.
Reject - It will open the reject workflow pop-up window.
View Utilization Statement - It will open the utilization statement in a pop-up window.
None
None
None
Details to be displayed as per figma.
Create Measurement Book
Employee Mobile Application
ULB Employees
This page is to create a new MB for a project or edit an existing MB in workflow.
A MB would be either first MB, intermediate MB or a last MB for a project.
First MB will not have any used quantity and MB history associated with it while the subsequent MBs will have used quantity as well as a associated MB history. Complete MB details of previous MB can be seen using view MB details.
The details is displayed as below while creating a MB.
Measurement Book Primary Details Details
MB Number
Work Order Number
Muster Roll ID
Project Description
Measurement Period
MB History (Cards) - In case of first MB, this information is not displayed.
MB Number
Period
Date
MB Amount
Status
Actions - It will open up with the workflow actions according to role user is having.
Edit
Submit
Verify and Forward
Send Back
Send Back To Originator
Approve
Reject
All the validations applied while creating/ editing a MB in Web application.
All the validation applied during workflow available in web.
None
All the notification during workflow as per web application.
Create MB Page is developed as per figma.
All the validations existing to web application are applicable here.
All web workflow actions are applicable and displayed as per the role user has.
Search Schedule of Rates
Home > Schedule of Rates > Search SOR
State: STATE_MUKTA_ADMIN
ULBs: MUKTA_ENG_ADMIN
Search SOR to be provided to list all the SORs.
There are various search parameters to search such a SOR.
At least one parameter is required to perform the search.
Consider From Date and To Date as a Date Range single parameter.
Exact search is performed for the values entered/selected.
In case multiple parameters values are supplied AND is applied for searching record.
By default active SORs are searched and currently effective rates are displayed.
Search - To perform the search based on the parameters entered.
Clear - To clear the values entered for search.
SOR Code - Hyperlink to view the SOR detail on mouse click. View SOR display the searched rate with SOR details on View Page.
Search result is displayed.
Option to download search result in excel is provided.
Pagination is provided to displayed 10 record at a time.
Not applicable.
Not applicable.
Not applicable.
Search is provided with the search parameters mentioned and the result is displayed as mentioned.
On click of SOR code, searched rate is displayed with SOR details on View SOR Page.
Pagination and option to download the searched result into Excel is provided.
Payment Instruction
Status Update for Payment Advice
Employee
Role: System
Payment Advice Status (PAG) is the API to fetch the payment advice status from JIT.
Once a PI is accepted at JIT, it is then approved with a digital sign by SSU in JIT.
For approved PI then payment advice is generated.
For Request/ Response parameters, please refer the .
The response data is stored and maintained at MUKTASoft for every PAG call.
The API call to be scheduled once in a day at 10:15 PM every day for the Approved payment instructions.
Error message displayed on View Payment Instruction Page. [Message: On call of PAG API: No response is received.]
PI status at MUKTASoft remain unchanged to Approved.
All beneficiaries payment status remain unchanged to Payment Initiated.
Option to refresh the status is provided. It triggers call of PAG.
Error message is stored at MUKTASoft.
Error message displayed on View Payment Instruction Page. [Message: On call of PAG API: <JIT error message>]
PI status at MUKTASoft remain unchanged to Approved.
All beneficiaries payment status remain unchanged to Payment Initiated.
Option to refresh the status is provided. It triggers call of PAG.
Success message is received and same is stored at MUKTASoft.
Info message displayed on View Payment Instruction Page. [Message: On call of PAG API: Response is received and updated successfully]
PI status at the MUKTASoft changes to In Process.
All beneficiaries payment status remain unchanged to Payment In Process.
Option to refresh the status is provided. It triggers call of PD.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
Not applicable
View Payment Instruction
Status is fetched and update in MUKTASoft for both PI and Beneficiary.
The response is captured in MUKTASoft for debugging and error reporting.
Technical glitched in the integration are defined as error and captured.
System keep trying until a response is received. The latest response is recorded in the log.
View Schedule of Rates
Home > Search SOR > SOR Code (Hyperlink) > View SOR
State: STATE_MUKTA_ADMIN
ULBs: MUKTA_ENG_ADMIN
View SOR is provided to view the details of created active/inactive SOR.
Search a SOR using the search SOR and then open to view the details.
The details displayed as given below.
Modify SOR - It is applicable to all type of SOR and enable the user to change of SOR description and status.
Add/ Modify Rate - It is applicable to all type of SOR other than Works and enable the user to add new rate or modify existing rate.
Add/ Modify Analysis - It is applicable to Works type of SOR only and enable the user to add rate analysis or modify existing rate analysis.
View Rate Analysis - It is applicable to Works type of SOR only and enable the user to view the currently linked rate analysis.
Not applicable.
Not applicable.
Not applicable.
SOR details is displayed as per the attribute provided in the story.
Rate is displayed as per the search result.
View history displayed the history of rates.
Estimate preparation for a work, by the Estimate Creator and then its verification and approval by other users (actors) in the workflow. Hence no change in existing approach.
There is no change from existing actors.
There is minor change in the workflow.
The option to save the estimate as draft to be provided at first before submitting it to verifier and the same is reflected in the below table.
No change. In the UI, the workflow will start displaying from Submitted state.
Roles are created as given provided.
Actions are configured based on role - action mapping.
Workflow states are defined as provided and the state transition done accordingly by updating the status appropriately.
Add/ Modify SOR Rate
Home > Search SOR > SOR Code (Hyperlink) > View SOR > Add/Modify Rate (action)
ULB: MUKTA_ENG_ADMIN
Add Rate is provided to enable the users add new rate or modify an existing rate.
Add/ Modify rate is allowed to only non works SORs only.
On add new rate, modify page is opened with the existing details and rates.
The attributes which are allowed to modify are as given below table.
In case new rate is added.
A new rate is created with new effective date.
The previous rate is closed with the previous day date.
View SOR Page is displayed with newly added rate.
A success toast message is displayed for new rate creation.
Success Message - New Rate Added
Rate has been added successfully effective from <effective date>.
Success Message - Existing Rate Modified
The rate effective from <effective date> has been modified successfully.
Alert! On Modify
Do you want to update existing rate effective from <effective date>? Please confirm to complete the action.
On Modify (In no change in rate details)
Modification to existing SOR rate is failed as there were no changes done.
Adding new rate to the SOR is failed.
Modification to existing SOR rate is failed.
Effective date should not be a date before current rate effective date.
Effective from time is always start of the day i.e. 00:00. The time in between in the day is not allowed.
Effective to date, the time is always 11:59:59.
Not applicable.
Not applicable.
Modification of existing rate is allowed.
Adding new rate with a new effective date is allowed.
On modification, alert message is displayed.
On successful add/modify rate, success toast message is displayed.
Create Detailed Estimate
Home > Estimates > Estimate Inbox > Create Estimate
ULB: Estimate Creator (Same as existing)
A detailed estimate creation screen to be provided.
The attributes defining detailed estimate are given in below table.
Note: Attachment section to be changed to remove detailed estimate as attachment.
Save as Draft - It is to save the details captured for detailed estimate and keeping it with creator.
Generate Analysis - Generate the analysis statement out of saved detailed estimate details.
Submit - It is the same as per existing estimate, allow the user to forward the estimate for verification.
View Analysis Statements - It will take the user to view analysis statement HTML page.
Estimate is created with the details provided.
If it is first time, estimate no. is generated as per the format provided.
Success toast message is displayed and page is loaded again in editable mode with the details saved.
Estimate gets assigned to the creator and made available in his/her inbox with the WF state Drafted.
On open from inbox, its get opened in editable mode same as edit estimate.
This action is enabled for saved estimate only.
The estimate details are saved.
Analysis statements are revised.
Estimate is forwarded to verifier.
Success page is displayed with success message.
First time, this action is enabled for saved estimate only.
The analysis is generated and Success toast message is displayed.
View Analysis Statements link is enabled.
Analysis statements are generated successfully.
Analysis statements generation failed.
Only active SORs and active and effective rates are displayed on search SOR.
All the intermediate figures are rounded up-to 2 decimal places.
Prerequisite
SOR Rate Master
Not applicable
The given additional features are incorporated.
The workflow is changed to have the option to save the details as draft.
The drafted estimate is assigned to the creator of estimate and can be searched using search estimate.
Estimate is made available to the inbox of estimate creator as well.
There is no change in the role-action and edit process.
Edit screen will get changed based on changes to have detailed estimate.
Not applicable.
On Save, Changes in the detail estimate are saved and no workflow changes done, fresh analysis is generated.
On submit, based on logged-in user role, workflow pop-up window is displayed.
Same as created detailed estimate screen with additional estimate number displayed on top.
Role based access based on configuration.
The estimates which are in workflow can only be edited.
Estimate is opened in editable mode.
The details given in table can be edited by user.
Create SOR
Home > Schedule of Rate > Search SOR Page > Action (Create SOR)
State: STATE_MUKTA_ADMIN
Create SOR feature is provided to enable the users create a SOR with its rate.
There are 4 types of SOR defined. Material, Labour, Machinery, and Works.
The rates of first 3 type of SORs are directly added by user on creation of SOR.
The rate for the SOR of type Works is calculated using rate analysis and added to SOR.
The attributes defining SOR are given in below table.
Submit - On Submit
Save the details into system and SOR is created with the status active.
Generate a unique code as per given format.
Success page is displayed with the success message and below actions.
a) Create SOR
b) Add Rate Analysis
c) Go To Search SOR
c) Go To Home Page
On Submit and Create Another SOR
Save the details into system and SOR is created with the status active.
Toast success message is displayed.
Create SOR Page is opened to create another SOR.
Success Message
SOR has been created successfully. SOR Code: <>
Duplicate record of same type, sub type, and variant is not allowed.
Effective from time is always start of the day i.e. 00:00.
Effective from date while creating SOR can be any date.
Duplicate Message
This SOR already exists. SOR Code:<code>.
These are the masters which are configured into MDMS to enable SOR creation.
SOR Type
SOR Sub Type
SOR Variant
Unit of Measurement
Heads/ Charges
(Separate tickets are created for each of them to configure into MDMS)
SOR Code format.
Not applicable
SOR can be created without having rate associated with it.
It covers all 4 types of SORs. Works SOR are created without rate.
Effective from time is always 00:00:00.
SOR code is generated as per the format provided.
Modify Schedule of Rate
Home > Search SOR > SOR Code (Hyperlink) > View SOR > Modify SOR (action)
State: STATE_MUKTA_ADMIN
Modify SOR is provided to enable the users to make the correction in the existing SOR.
The attributes which are allowed to modify are as given below table.
Submit - On Submit.
SOR detailed gets updated successfully.
View SOR Page is displayed with updated details.
Success toast message is displayed.
In case SOR is getting inactivated.
The status of SOR is get updated inactive in case no other active SOR is referencing it.
Otherwise a validation message is displayed and system doesn’t update the status to inactive.
SOR details has been updated successfully.
Validation message a reference SOR is getting inactivated.
This SOR can not be inactivated as there are active SORs exists referencing it.
Not applicable.
Not applicable.
On successful update, View SOR Page is displayed.
Toast success message is displayed.
System doesn’t allow to change the status to inactive in reference SORs exists.
Search Measurement Book
Employee
Role: MB Creator, MB Verifier, MB Approver
Search Measurement Book to be provided to search a MB and view the details.
Search is provided based on various parameters.
At least one parameter’s value is required to perform the search.
Date range From Date/ To Date is considered one parameter.
Exact search is performed for the values entered/selected other than Project Name.
For Project Name, fuzzy search to be provided.
In case multiple parameters values are supplied AND is applied for searching record.
Search result is shown as given below.
Pagination is displayed to handle the big result set. 10 record per page are displayed.
Option to download the result set in Excel/ PDF is provided.
At least one parameter’s value is required to perform the search.
Search - It will perform the search and display the result. In case, no result found appropriate message is displayed.
Clear Search - It will clear the search parameters.
MB Reference Nbmer - Hyperlink will take the user to MB detail page.
Not applicable.
At least one parameter is required to perform the search.
Search result displayed on matching records found else no record found message is displayed.
Pagination is applied if more than 10 records are found.
Create Detailed Measurement Book
Home > Measurement Book> MB Inbox > Create MB
ULB: MB Creator
A detailed measurement book creation screen to be provided.
From view work order page, action Create MB is provided.
The attributes defining detailed measurement are given in below table.
Save as Draft - It is to save the details captured for detailed MB and keeping it with creator.
Generate Utilization- Generate the utilization statement out of saved detailed MB details.
Submit - It is to allow the user to forward the MB for verification.
View Utilization Statements - It will take the user to view utilization statement HTML page.
View MB History - To display all the MBs created so far as per the detail provided in the table above.
MB is created with the details provided.
If it is first time, MB number and MB reference number are generated as per the format provided.
Success toast message is displayed and page is loaded again in editable mode with the details saved.
MB gets assigned to the creator and made available in his/her inbox with the state Drafted.
On open from inbox, its get opened in editable mode same as edit estimate.
This action is enabled for saved (Drafted) MB only.
The MB details are saved.
Utilization statements are revised.
MB is forwarded to verifier.
Success page is displayed with success message.
First time, this action is enabled for saved (Drafted) MB only.
The utilization is generated and success toast message is displayed.
View Analysis Statements link is enabled.
Utilization statements are generated successfully.
Utilization statements generation failed.
MB period shall follow the muster roll period for each project.
Only active SORs and active and effective rates are displayed on search SOR.
All the intermediate calculated figures are rounded up-to 2 decimal places.
All the measurements can be entered into up-to 4 decimal places.
MB Number
MB/FY: yyyy-yy/SEQUENCE (6 Digits)
MB/2023-24/000091.
MB Reference Number
MB/FY: yyyy-yy/SEQUENCE (6 Digits)/ XX
Here XX 2 digit running sequence no.
MB/2023-24/000091/01
Not applicable
First MB
Second Onward
MB form is designed as per the wire-frame provided.
Each MB entry goes for approval.
Measurements entered are allowed to be captured up to 4 decimal places.
The amount calculated is rounded up to 2 decimal places.
Attachment section to attach the site photos.
Measurement Book Workflow
Home > Inbox
On Approve To Creator
MB Entry {refno} for the project {projectid} is approved. Login to MUKTASoft to view estimate details. MUKTA - Govt. of Odisha.
On Reject To Creator
MB Entry {refno} for the project {projectid} is rejected. Login to MUKTASoft to view estimate details. MUKTA - Govt. of Odisha.
The same UIs which are being used for other flows.
Roles are created as given provided.
Actions are configured based on role - action mapping.
Workflow states are defined as provided and the state transition done as provided.
SMS notifications are sent accordingly.
#
Field Name
Data Type
Description
1
SOR Type
Drop-down
SOR types, the values from SOR Type Master.
2
SOR Sub Type
Drop-down
SOR sub types, the values from SOR Sub Type Master.
3
SOR Variant
Drop-down
SOR variant, the values from the SOR Variant Master.
4
SOR Code
Text
The system generated unique code of the SOR.
5
Status
Drop-down
Active/ Inactive.
6
Effective From
Date
The rate effective from date, can be a future date too.
7
Effective To
Date
The rate effective from date, can be a future date too.
#
Field Name
Description
1
SOR Code
It is system generated unique code to identify the SOR uniquely.
2
SOR Description
It is the description of SOR upto 64 characters only and end with a (…) with an option to display the complete text in tool-tip on mouse-click.
3
SOR Type
SOR types, the values from SOR Type Master.
4
SOR Sub Type
SOR sub types, the values from SOR Sub Type Master.
5
Status
The status of SOR, Active/ Inactive.
6
Rate
The current effective rate of the SOR.
#
Parameter
Description
1
pmtInstId
Payment instruction ID of the payment instruction generated at JIT
2
pmtInstDate
Payment instruction date of the payment instruction generated at JIT
3
billNo
Payment Instruction ID of the payment instruction created in MUKTASoft and then pushed to JIT.
4
billDate
Payment Instruction date of the payment instruction created in MUKTASoft and then pushed to JIT.
5
ssuIaId
Special spending unit ID. A master value maintained in JIT-FS.
#
Parameter
Description
2
billNo
Bill number of the bill created in MUKTASoft and then pushed to JIT-FS as payment instruction.
3
ssuIaId
Special spending unit ID. A master value maintained in JIT-FS.
4
finYear
The financial year for which bill was created.
5
adviceId
Unique Id generated after successfully submission of Advice for payment in JIT.
6
adviceDate
Advice date of payment advice generated in JIT.
7
onlineBillRefNo
Auto generated online bill Reference number in JIT.
8
tokenNumber
Token number generated automatically after auto submitted bill to treasury
9
tokenDate
Token date of the token generated automatically.
Beneficiary List
10
benfName
Beneficiary name
11
benfAccountNo
Beneficiary account number
12
benfBankIfscCode
Beneficiary’s IFSC which was pushed through PI.
13
amount
Amount to be paid to the beneficiary.
14
benfId
Beneficiary unique ID which was generated for PI.
#
Response
PI Status (From)
PI Status (To)
Payment Status
User Action
API Call
1
No Response
Approved
Approved
Payment Initiated
Refresh
PAG
2
Response With Error
Approved
Approved
Payment Initiated
Refresh
PAG
3
Response Without Error
Approved
In Process
Payment In Process
Refresh
PD
#
Field Name
Description
1
SOR Code
It is system generated unique code to identify the SOR uniquely.
2
SOR Type
SOR types, the values from SOR Type Master.
3
SOR Sub Type
SOR sub types, the values from SOR Sub Type Master.
4
SOR Variant
SOR variant, the values from the SOR Variant Master.
5
Unit of Measurement
The unit of measurement.
6
Rate Defined for Quantity
The quantity of SOR for which rate is provided.
7
SOR Description
It is the description of SOR to describe the SOR.
8
Status
The status of SOR Active/ Inactive. Active means active for usage.
Rate Details
SOR rate, based on the search performed.
9
Effective From
The date from which the rate is effective.
Heads
A grid to select the head which ever applicable is provided.
10
Basic Rate
Basic rate of the SOR, provided by the state PWD.
11
Conveyance
Conveyance cost defined for the unit of quantity given in SOR.
12
Royalty
Royalty defined for the unit of quantity given in SOR.
13
Labour Cess
The amount of labour cess, it is applicable to SOR of type Works only.
14
Rate
The final rate of SOR.
Rate History
History of rates which were effective in the past.
1
Serial No.
Serial number of the record.
2
Effective From
The rate effective from date.
3
Rate/ Unit
The net effective rate.
4
View Details
Button to view the break-up of rate.
5
Actions
Modify SOR - Applicable to all type of SOR. (State Users Only)
Add/ Modify Rate - Applicable to other than Works (State/ ULB Users)
Add/ Modify Rate Analysis - Applicable to Works type of SOR. (State Users Only)
View Rate Analysis - Applicable to Works type of SOR. (State/ ULB Users)
Work Order Verifier
Pending for verification
Pending for correction
Sent Back
Work Order Approver
Pending for approval
Pending for verification
Sent Back
1
On send back, the pop-up window is closed and a toast success message is displayed. The view work order page is refreshed.
2
The work order is sent back to the previous user in the workflow and the workflow timeline gets updated.
3
Workflow state changes based on the role as mentioned in the story above.
4
On cancel, the pop-up window is closed and a toast cancel message is displayed.
#
Role (Actors)
Actions
User Persona
1
ESTIMATE_CREATOR
Create
Submit
Search
View
Edit/ Re-submit
Junior Engineer/ Assistant Engineer/ MUKTA Implementation Expert
2
ESTIMATE_VERIFIER
Search
View
Verify and Forward
Send Back
Executive Engineer
3
TECHNICAL_SANCTIONER
Search
View
Technical Sanction
Send Back
Send Back To Originator
Reject
Municipal Engineer
4
ESTIMATE_ APPROVER
Search
View
Approve
Send Back
Send Back To Originator
Reject
Executive Officer/ Municipal Commissioner
5
ESTIMATE_VIEWER
Search
View
MUKTA Program Coordinator
#
Action
Role
From State
To State
Status
1
Save as Draft
Estimate Creator
Saved as draft
Drafted
2
Submit
Estimate Creator
Saved as draft
Pending for verification
Submitted
3
Verify and Forward
Estimate Verifier
Pending for verification
Pending for technical sanction
Verified
4
Technical Sanction
Technical Sanctioner
Pending for technical sanction
Pending for approval
Technically Sanctioned
5
Send Back
Estimate Verifier
Pending for verification
Pending for correction
Sent Back
6
Send Back
Technical Sanctioner
Pending for technical sanction
Pending for verification
Sent Back
7
Send Back
Estimate Approver
Pending for approval
Pending for technical sanction
Sent Back
8
Send Back To Originator
<roles having access>
<Current Status>
Pending for correction
Sent Back
9
Edit/ Re-submit
Estimate Creator
Pending for correction
Pending for verification
Re-submitted
10
Approve
Estimate Approver
Pending for approval
Approved
Approved
11
Reject
<any roles having access>
<Current Status>
Rejected
Rejected
<roles having access to send back to originator>
<Current Status>
Pending for correction
Sent Back
1
The work order is moved to Work Order Creator’s inbox.
2
Work Order Creator- Edit Work Order action is enabled to edit the work order.
3
Workflow state changes as mentioned in the ticket.
#
Field
Data Type
Required
Description
1
Project ID
Display Only
NA
Project ID of the project.
2
Date of proposal
Display Only
NA
Date of the proposal from the project.
3
Project name
Display Only
NA
Project name
4
Project description
Display Only
NA
Project description
5
Work Order Details
Tab
6
Name of CBO
Drop-down
Y
Organization type community based organization from the organization master maintained at the ULB level are only allowed.
Only Active organizations and the organization valid to date is above work order created date are listed under drop-down or allowed to search.
The name is searchable in the drop-down and search is start with min 3 characters has to be entered.
Search is performed for the CBOs registered within the ULB.
7
CBO ID
Display
Y
The CBO ID from the organization registry.
8
Role of CBO
Drop-down
(Auto- selected)
Y
The role of the CBO is decided based on the estimated amount. It is configurable in the system.
IP (Implementation Partner) - If the estimated cost of the works is more than Rs.15 Lakhs
IA (Implementation Agency) - If the estimated cost of the works is up to Rs.15 Lakhs
9
Name of the officer in-charge
Drop-down
Y
The drop-down values are population based on the role assigned.
The name is searchable in the drop-down with min 3 characters entered. Name + Designation;
Search is performed within the employees having the role OFFICER_IN_CHARGE.
10
Designation of officer in-charge
Display
Y
Displayed from the EIS/User’s record saved in the system.
11
Project completion period (in days)
Numeric
Y
Number of days work to be completed.
Min Value: 1 day.
12
Work order amount
Read Only
Y
Total estimated Amount - Overhead Amount (Sum of all which are not a work value)
13
Labour and Material Analysis
14
Labour Analysis
View Document
Y
The labour analysis file attached to estimate to be displayed here.
15
Material Analysis
View Document
Y
The material analysis file attached to estimate to be displayed here.
16
Relevant Documents
Sections
17
BOQs
File Attachment
Y
Allows single file, not greater than 5 MB. Files can be of type doc,docx, xls,xlsx pdf, jpg.
18
Terms and conditions
File Attachment
N
Allows single file, not greater than 5 MB. Files can be of type doc,docx, xls,xlsx pdf, jpg.
19
Others
Textbox
N
To capture the file name
20
File Attachment
N
To attach the file file the name entered above in the textbox.Allows single file, not greater than 5 MB. Files can be of type doc,docx, xls,xlsx pdf, jpg.
21
Terms and Conditions
Tab
22
Description
Alphanumeric
N
Grid of textbox to enter the terms and conditions as bulleted list.
1
The role of CBO is decided based on the logic provided.
2
On Forward, the work order is forwarded to the next user.
3
The work order number is generated as per the specified format.
4
On successful forward Success Page is displayed else Failure Page is displayed.
#
Field Name
Data Type
Is Mandatory?
Description
1
SOR Code
Display
Yes
The SOR code.
2
SOR Type
Display
Yes
Material, Labour, Machinery, Works.
3
SOR Sub Type
Display
Yes
Applicable for SOR type Works only.
4
SOR Variant
Display
Yes
Applicable for SOR type Works only.
5
Unit of Measurement
Display
Yes
Unit of measurement for the item.
6
Rate Defined for Quantity
Display
Yes
Quantity of items for which basic rate is defined.
7
Description
Display
Yes
Name of item as per the standard definition of OPWD
8
Status
Display
Yes
The status of SOR, Active/ Inactive.
Rate Details
9
Effective From
Date
Yes
The date from which rate is become effective.
Heads
Grid
Yes
Rate of other than works SORs can only be added.
10
Basic Rate
Numeric
Yes
The basic rate of the item defined by the OPWD.
11
Conveyance
Numeric
No
The conveyance charges applicable.
12
Royalty
Numeric
No
The royalty amount on the items.
13
Rate
Display
Yes
A calculated value.
14
Submit
Button
Yes
It saves the changes into system.
#
Field Name
Data Type
Is Mandatory?
Description
1
Estimate Type
Display
Yes
Estimate type, Original.
2
Project ID
Display
Yes
Project ID
3
Project Sanction Date
Display
Yes
Project sanction date
4
Project Name
Display
Yes
Project name
5
Project Description
Display
Yes
Project description
Search SOR
It provides the option to search a SOR and add to estimate.
SORs
1
Code
Display
Yes
SOR code, unique identifier for each SOR.
2
SOR Description
Display
Yes
SOR description from the SOR master for the selected SOR.
3
Unit
Display
Yes
Unit of measurement
4
Rate
Display
Yes
The rate defined and effective currently.
5
Quantity
Display
Yes
Calculated value out of measurements.
6
Amount
Display
Yes
Calculated value and equal to Qty*Amount.
Measurements
A table to capture the measurement details and calculate the quantity using it.
1.1
Sr. No.
Display
Auto
Measurement serial number.
1.2
Type
Drop-down
Yes
Plus/ Minus measurements.
1.3
Name
Alphanumeric
(32 Chars)
Yes
The name of the measurement.
1.4
Number (Nos)
Numeric
(6,4)
Yes
No. of items.
1.5
Length (L)
Numeric
(6,4)
Yes
Length measured. Allowed up-to 4 places of decimal.
1.6
Breadth (B)
Numeric
(6,4)
Yes
Width measured. Allowed up-to 4 places of decimal.
1.7
Height/ Depth
Numeric
(6,4)
Yes
Depth measured. Allowed up-to 4 places of decimal.
1.8
Quantity
Display
Yes
Qty = N* L*B*D; rounded up-to 4 places of decimal.
1.9
Total
Display
Yes
Grid total for the quantities of measurements. rounded up-to 4 places of decimal.
Non SORs
2
SOR Description
Alphanumeric
(2048 Chars)
Yes
SOR description from the SOR master for the selected SOR.
3
Unit
Drop-down
Yes
Unit of measurement
4
Rate
Numeric
(6,2)
Yes
The rate defined and effective currently.
5
Quantity
Display
Yes
Calculated value out of measurements.
6
Amount
Display
Yes
Calculated value and equal to Qty*Amount.
Measurements
The table is same as described under SOR.
Other Charges
It is going to be same as provided in the existing estimate screen as overhead.
7
View Analysis Statements
Link
Yes
It will take the user to analysis page. It gets enabled once the analysis is generated.
Actions
1
Save as Draft
Button
Yes
Save the estimate as a draft.
2
Generate Analysis
Button
Yes
Generates the analysis and populates the figures.
3
Submit
Button
Yes
Submit the estimate for verification.
Role
Workflow Window
Estimate Creator
Submit pop-up window, estimate gets forwarded to verifier with changes saved and fresh analysis generated.
Estimate Verifier
Verify and Forward pop-up window, estimate gets forwarded to technical sanctioner with changes saved and fresh analysis generated.
Technical Sanctioner
Technical Sanction pop-up window, estimate gets forwarded to approver with changes saved and fresh analysis generated.
Approver
Approval pop-up window, estimate gets approved with changes saved and fresh analysis generated.
Sr. No.
Field Name
Data Type
Is Mandatory?
Description
1
SOR Type
Drop-down
Yes
Material, Labour, Machinery, Works.
2
SOR Sub Type
Drop-down
Yes*
Applicable for SOR type Works only.
3
SOR Variant
Drop-down
Yes*
Applicable for SOR type Works only.
4
Unit of Measurement
Drop-down
Yes
Unit of measurement for the item.
5
Rate defined for quantity
Numeric (6,0)
Yes
Quantity of items for which basic rate is defined.
6
Description
Alphanumeric (2048 Chars)
Yes
Name of item as per the standard definition of OPWD
Rate Details
Section
Optional
It is not applicable to Works SOR.
7
Effective From
Date
Yes
The date given rate will become effective, it can be a past and future date. Time is always 00.00
Heads
Grid
Optional
A grid to select the head whichever is applicable.
8
Basic Rate
Numeric (6,2)
Yes
The basic rate of the item defined by the OPWD
9
Conveyance
Numeric (6,2)
No
The conveyance charges applicable based on the distance item is carried.
10
Royalty
Numeric (6,2)
No
The royalty amount on the items as per the state mining department.
11
Labour Cess
Numeric (6,2)
No
It is applicable for works items only and calculated on Basic + Conveyance + Royalty.
12
Rate/ Unit
Display
Yes
A calculated value.
13
Submit and Create Another SOR
Button
Yes
It will allow the user to submit the details and open a new create SOR form.
14
Submit
Button
Yes
It saves the SOR details into system and create SOR record.
Sr. No.
SOR Type
Format
1
Material
LD-<5 digit running sequence>. E.g. LD-00001
2
Labour
LD-<5 digit running sequence>. E.g. LD-00001
3
Machinery
LD-<5 digit running sequence>. E.g. LD-00001
4
Works
<SUBTYPECODE>-<5 digit running sequence>. E.g. EW-00001
#
Field Name
Data Type
Is Mandatory?
Description
1
SOR Code
Display
Yes
The SOR code.
2
SOR Type
Display
Yes
Material, Labour, Machinery, Works.
3
SOR Sub Type
Display
Yes
Applicable for SOR type Works only.
4
SOR Variant
Display
Yes
Applicable for SOR type Works only.
5
Is it a basic variant?
Display
Yes
Applicable for SOR type Works only.
6
Unit of Measurement
Display
Yes
Unit of measurement for the item.
7
Rate Defined for Quantity
Display
Yes
Quantity of items for which basic rate is defined.
8
SOR Description
Alphanumeric
Yes
Name of item as per the standard definition of OPWD
9
Status
Drop-down
Yes
The status of SOR, Active/ Inactive.
Sr. No.
Field Name
Data Type
Description
1
Ward
Drop-down
Name of the ward from the configured boundary data.
2
Project Name
Text
Project name
3
MB Number
Text
MB number
4
MB Reference Number
Text
MB reference number
5
Status
Drop-down
Workflow statuses, Drafted, Submitted, Verified, Approved.
6
Created From
Date
MB created date
7
Created To
Date
MB created date
Sr. No.
Field Name
Description
1
MB Reference Number
MB reference number, a hyperlink to open the MB.
2
MB Number
MB number
3
Project Name
Project name, with the option to see the project description as tool-tip.
4
CBO Name
Name of CBO to whom work order is awarded.
5
Status
Status of MB.
6
MB Amount
MB amount.
#
Field Name
Data Type
Is Mandatory?
Description
1
Work order number
Display
NA
Work order number
2
Project ID
Display
NA
Project ID
3
Project sanction date
Display
NA
Project sanction date
4
Project Location
Display
NA
Project location
5
Project Name
Display
NA
Project name
6
Project Description
Display
NA
Project description
7
View MB History
Link
NA
In case second onward MB entries, to show the measurement history in the format given below.
MB History - It is displayed for second onward MB entries.
1
Sr. No
Display
NA
Serial number
2
MB Reference Number
Display
NA
Measurement reference number
3
MB Date
Display
NA
Measurement date
4
MB Period
Display
NA
Measurement period
5
MB Amount
Display
NA
Measurement amount
6
Status
Display
NA
Status of the measurement.
MB Period - It has to follow muster roll muster roll period.
1
From Date
Date
Yes
The date from which measurement is taken. In case not the first MB, auto filled with previous MB’s To Date +1.
2
To Date
Date
Yes
The date till which measurement is recorded.
SORs
1
Type
Display
Yes
SOR Sub type as provided in estimate
2
Code
Display
Yes
SOR Code as provided in estimate
3
SOR Description
Display
Yes
SOR description as provided in estimate
4
Unit
Display
Yes
Unit of measurement as provided in estimate
5
Rate
Display
Yes
Rate per unit as provided in estimate.
6
Quantity
Display
Yes
Quantity calculated from measurement captured.
7
Amount
Display
Yes
Calculated from Rate*Quantity. Rounded up to 2 decimal places.
Measurements
1.1
Sr. No.
Display
Auto
Serial number of measurement
1.2
Type
Display
Auto
Plus/ Minus from estimate.
1.3
Name
Display
Auto
The name of the measurement from the estimate.
1.4
Number (Nos)
Numeric
(6,4)
Yes
No. of items if the unit of measurement is number.
1.5
Length (L)
Numeric
(6,4)
Yes
Length measured for completed work.
1.6
Breadth (B)
Numeric
(6,4)
Yes
Width measured for completed work.
1.7
Height/ Depth (D)
Numeric
(6,4)
Yes
Depth measured for completed work.
1.8
Quantity
Display
Yes
Qty = N*L*B*D; rounded up-to 4 decimal places.
1.9
Total
Display
Yes
Grid total for the quantities of measurements, rounded up-to 4 decimal places.
Non SORs - The above is repeated for Non SORs also except Type and Code.
View Utilization Statements - A link to view the utilization statements in HTML view.
Worksite Photos
Tab
7
Worksite Photo
Upload File
Yes
5 photos JPG and PNG images are supported.
Actions
1
Save as Draft
Menu
Yes
Action to save the measurement record as draft.
2
Generate Utilization
Menu
Yes
Action to generate measurement statements out of measurements recorded.
3
Submit
Menu
Yes
Action to submit the measurement book for verification
Sr. No.
Role (Actors)
Actions
User Persona
1
MB_CREATOR
Create
Submit
Search
View
Edit/ Re-submit
Junior Engineer/ Assistant Engineer/ MUKTA Implementation Expert
2
MB_VERIFIER
Search
View
Verify and Forward
Send Back
Executive Engineer
3
MB_ APPROVER
Search
View
Approve
Send Back
Send Back To Originator
Reject
Municipal Engineer
4
MB_VIEWER
Search
View
MUKTA Coordinator/ MUKTA Accountant
#
Action
Role
From State
To State
Status
1
Save as Draft
MB Creator
Drafted
Drafted
2
Submit
MB Creator
Drafted
Pending for verification
Submitted
3
Verify and Forward
MB Verifier
Pending for verification
Pending for approval
Verified
4
Send Back
MB Verifier
Pending for verification
Pending for correction
Sent Back
5
Send Back
MB Approver
Pending for approval
Pending for verification
Sent Back
6
Send Back To Originator
<roles having access>
<Current Status>
Pending for correction
Sent Back
7
Edit/ Re-submit
MB Creator
Pending for correction
Pending for verification
Re-submitted
8
Approve
MB Approver
Pending for approval
Approved
Approved
9
Reject
<any roles having access>
<Current Status>
Rejected
Rejected
Workflow State/ Event
Current State
SLA (In Days)
Edit/ Re-submit
Pending for correction
1
Verify and Forward
Pending for verification
2
Approve
Pending for approval
1
They payment to the beneficiaries are done through JIT system. In a case when a payment is failed due to wrong bank account number or IFSC, or due to any other reasons the same is submitted again to JIT as a revised PI.
As per the recent conversations, it has been communicated to us that the revised PI works in tried within 90 days or before 30th April of next financial year from the date transaction got failed. Hence change in the system to made to address this use case.
This is for the failed transactions which could not be cleared before 90 days from the failure date or 30th April of next FY, whichever is earlier.
From the view PI page option to create a new PI to be enabled for such transactions.
A new original PI is created with request JSON PI is required and submit to JIT.
New PI is created and send for payment for those failed transactions which could not be cleared before 90 days from the failure date or 30th April of next FY, whichever is earlier.
An estimate can be revised due to following reasons.
Due to revision in rates.
Due to deviations (less/excess) in SOR/ Non-SOR quantities.
And for both the revision, logic to calculate estimated to be implemented as given below.
For an estimate system should know the used and unused quantities of all the SORs/Non-SORs.
Used quantity to be fetched from approved MBs. In workflow MBs will not be considered to determine the used quantity.
Current effective rates to be applied to calculate the revised estimate amount and it will be calculated SOR/ Non-SOR wise as given below.
Amount = (Unused Quantity + Additional Quantity (if added any))* current effective rate.
For newly added SOR/ Non-SOR, current effective rates are applied.
The revised estimate amount is calculated using current effective rates on unused quantities of SORs.
Estimate templates assist civil engineers in categorizing frequently used Schedule of Rates (SORs) for specific project types or construction works, streamlining the estimate preparation process and reducing time.
Skills are the schedule of rates of type labour, as of now these are maintained as separate master’s data into MDMS while these should be part of SOR.
This will help to maintain these in one place and make effective in both the places Estimate and Muster Roll.
Skills to be created as SOR.
In estimate and muster roll, data to be fetched from SOR.
Separate Skills master data to be discarded.
It has to be ensure all the features are intact and working properly after making this changes.
Separate skills master data is discarded.
Skills data is fetched from SOR in all the places.
All the affected feature to be tested properly to ensure things are working fine.
It addresses specific technical issues and aligns with on-ground processes, incorporating necessary improvements.
Rate analysis in Public Works Departments (PWD) involves the examination and calculation of rates for various construction activities or works. It is a systematic process carried out to determine the cost of executing a particular work item per unit quantity. Rate analysis typically involves breaking down the cost components associated with a construction activity, including materials, labor, machinery, contractor's profit, overhead costs, and miscellaneous expenses.
Wage seeker’s registration process to be changed to validate the individual’s AADHAAR through AADHAAR integration.
There is change in wage registration mobile screens to accommodate the AADHAAR validation and make it more user friendly.
Entire registration process is divided into 4 steppers as it was there in earlier and the screens provided as given below.
Individual’s Identification Details
Individual’s Personal Details
Individual’s Skills Details
Individual’s Photo
Location Details
Financial Details
Summary
On validate, API is called and AADHAAR is validated.
On valid AADHAAR, a inline success message is displayed and “Next” button is enabled to move to next page.
On invalid AADHAAR, a inline invalid message is displayed and “Next” button is kept disabled.
On failure, a inline invalid message is displayed and “Next” button is kept disabled.
On selection of any other identity document, other than AADHAAR, “Validate” action is not displayed and user is allowed to move to next scree if case all the required detail is entered.
Takes the user to next page, when all the required details of current page entered.
Save the record in system.
All existing validation
Validation button is displayed only when identity document selected as AADHAAR.
None
Change in Individual Details Page to accommodate AADHAAR validation.
AADHAAR validation is implementation only when identity document selected AADHAAR.
Purchase Bill
System should allow to make purchase bill in name of CBO as purchase reimbursement.
Employee: Bill Creator (JE/ AE/ IE)
As of now a purchase bill can only be prepared in the name of vendor organization.
System should allow to prepare a purchase bill in the name of CBO for the reimbursement of material purchase payments.
With this system will allow to create prepare a purchase bill either in the name of Vendor of CBO.
To achieve this some change in the existing purchase bill are suggested.
Organization type a new field is added, which is by default selected “CBO”.
Option to search organization will remain as it is.
There is minor change in invoice detail section, please refer wire-frame for the same.
There is minor change in bill details section, please refer wire-frame for the same.
Rest all remain same.
Actions and workflow remain same.
System allows to prepare a bill either in the name of vendor or CBO.
There are minor UI changes to accommodate this.
Workflow is not changed.
Wage seeker’s modification to be changed to validate the individual’s AADHAAR through AADHAAR integration.
There is change in modification screens to accommodate the AADHAAR validation.
User is given an option to select the identity document and enter the document number.
In case, identity document selected is AADHAAR validate button is displayed.
In case of other document selected, validation button is not displayed.
On validate, API is called and AADHAAR is validated.
On valid AADHAAR, a inline success message is displayed and “Next” button is enabled to move to next page.
On invalid AADHAAR, a inline invalid message is displayed and “Next” button is kept disabled.
On failure, a inline invalid message is displayed and “Next” button is kept disabled.
On selection of any other identity document, other than AADHAAR, “Validate” action is not displayed and user is allowed to move to next scree if case all the required detail is entered.
Save the record in system.
All existing validation
Validation button is displayed only when identity document selected as AADHAAR.
None
Change in Individual Details Page to accommodate AADHAAR validation.
AADHAAR validation is implementation only when identity document selected AADHAAR.
Create Estimate Template
Home > Estimate Template > Search Template > Action (Create Template)
State: STATE_MUKTA_ADMIN
Create estimate template feature is provided to enable the user to create a template.
The attributes defining template are given in below table.
Sr. No.
Field
Data Type
Is Mandatory?
Description
1
Project Type
Drop-down
Yes
Project type, the master data from MDMS.
2
Template Name
Text
Yes
Name given to template.
3
Template Description
Text
Yes
The description, describing the template in detail.
4
Search SOR
Search
Yes
To search an SOR and add to the template.
5
SORs
Section
5.1
Sr. No.
Display
Yes
Serial number.
5.1
Sub Type
Display
Yes
SOR sub type
5.2
SOR Code
Display
Yes
SOR code
5.3
Description
Display
Yes
SOR description
5.4
Unit
Display
Yes
Unit of measurement
6
Non SORs
Section
6.1
Sr. No.
Display
Yes
Serial number.
6.2
Description
Text
Yes
Non SOR description
6.3
Unit
Drop-down
Yes
Unit of measurement
Submit - On Submit
In case a template with same set of SORs are already present an alert is displayed.
Save the details into system with status Active.
Generate a unique code using the format TMP-<4 DIGIT RUNNING SEQUENCE>. e.g. TMP-0001
Success page is displayed with the success message and below actions.
Create Template
Go To Search Template
Go To Home Page
It looks like a duplicate template. A template with same set of SORs already exists. Do you want to continue?
Another template of same set of SORs alert is displayed.
Not applicable
Not applicable
Template code is generated as per the format given.
Alert on duplicate template.
View Template
Home > Search Template> Template Code (Hyperlink) > View Template
State: STATE_MUKTA_ADMIN
ULB: MUKTA_ENG_ADMIN
View Template is provided to view the details of created active/inactive estimate template.
To view the template details, template is searched using the search facility and then opened to view the details.
The details displayed as given below.
Attributes
Sr. No.
Field
Description
1
Code
A unique code generated for template.
2
Project Type
Project type
3
Name
Name given to template.
4
Description
The description, describing the template in detail.
5
Is Active
Status of template, Active/ Inactive.
6
SORs
6.1
Sr. No.
Serial number.
6.2
Sub Type
SOR sub type
6.3
SOR Code
SOR code
6.4
Description
SOR description
6.5
Unit
Unit of measurement
7
Non SORs
7.1
Sr. No.
Serial number.
7.2
Description
Non SOR description
7.3
Unit
Unit of measurement
Modify - It takes the user to modify template page.
Not applicable.
Not applicable.
Not applicable.
View is as per the the table and wire-frame.
Action to modify template is provided.
Writing the rate calculation logic and a scheduler to revise the rates for pending revise rate SORs on demand.
Search SOR is used to search and schedule the revision of rates.
It runs on demand and triggered by the user from pending rate revision screen.
User complete the rate revision of all required material, labour, and machinery SORs using edit SOR rate before calling for this JOB.
User search the works SORs which are to be revised.
User initiate the action by clicking on “Revise Rate” and select for the Effective Date for rates.
Revision rate JOB gets scheduled and runs in the back-end and only those SORs picked which has a different existing rate from calculated rate.
Revise rate scheduler runs in the back-ground, system generates the new rates and then link with the SOR with new effective date.
All the errors encountered during revision are captured and reported.
In case there is a rate already exists for same given effective date and existing rate is different from new generated rate, existing rate is inactivated and new rate is made effective from given effective date.
In case a rate exists from past effective date, existing rate is closed and new rate is added and made effective from given effective date.
In case no rate, new rate is generated and added from given effective date.
Users can see the progress and status of JOB from view rate revision JOBs screen.
Revise Rate
On revise rate, all the components of rates are calculated and added/update to SOR.
All the validations applicable for add/edit SOR rates.
All the errors encountered are captured and reported.
For rates effective date should not be a date before current rate effective date.
Effective from time is always start of the day i.e. 00:00.
Effective to date, the time is always 11:59:59.
The components/ heads defined to calculate the SOR rates are as given below.
Basic Rate
Conveyance
Royalty on Minerals
Environment Management Fund (EMF)
District Mineral Fund (DMF)
Additional Charges
Labour Cess
Basic Rate
Rate Analysis Basic Rate is calculated for the quantity define for analysis.
SOR Basic Rate = (Basic Rate*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Conveyance
Conveyance is calculated for the quantity define for analysis.
SOR Conveyance = (Conveyance*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Royalty on Minerals
Royalty is calculated for the quantity define for analysis.
SOR Royalty = (Royalty*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
EMF
EMF is calculated for the quantity define for analysis.
SOR EMF= (EMF*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
DMF
DMF is calculated for the quantity define for analysis.
SOR DMF= (DMF*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Additional Charges
Additional charges is calculated for the quantity define for analysis.
SOR Additional charges= (Additional charges*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Labour Cess
SOR Labour Cess = 1% of (SOR Basic Rate + SOR Conveyance + SOR Royalty + SOR EMF + SOR DMF + SOR Additional charges);
SOR Rate = Basic Rate + Conveyance + Royalty + EMF + DMF + Additional Charges + Labour Cess;
Not applicable
View Scheduled JOBs
Scheduler runs when triggered by user.
It reports the issues found during execution.
View scheduled job screen is provided to view all the jobs.
View Rate Analysis
Home > Search SOR > View SOR > View Analysis (Action)
State: MUKTA_STATE_ADMIN
ULB: MUKTA_ENG_ADMIN
To view the rate analysis associated with a SOR, SOR is searched open to view.
From view SOR page, select the action “View Analysis”.
View rate analysis display the details of rate analysis with an action to revise the rate.
The attributes are display as given below in the table.
Sr. No.
Field Name
Description
1
SOR Code
It is system generated unique code to identify the SOR.
2
SOR Type
SOR Type, the values from the SOR Type Master.
3
SOR Sub Type
SOR sub types, the values from SOR Sub Type Master.
4
SOR Variant
SOR variant, the values from the SOR Variant Master.
5
Unit
Unit of measurement.
6
Rate Defined for Quantity
The quantity for which SOR rate is defined.
7
SOR Description
SOR description.
8
Status
Active/Inactive
Constituents
9
Effective From
Display the date when it was last modified.
10
Analysis Defined for Quantity
The quantity for which rate analysis is defined.
11
Material
11.1
Code
Unique code defined for the material item.
11.2
Name
Name of the material item.
11.3
Unit
Unit of measurement on which item is measured.
11.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
11.5
Quantity
Quantity of the item defined for the given SOR.
11.6
Amount
The total amount for item arrive from Quantity * Rate.
11.7
Total
Grid Total of all the items added under material.
12
Labour
12.1
Code
Unique code defined for the labour item.
12.2
Name
Name of the labour item.
12.3
Unit
Unit of measurement on which item is measured. Mostly Nos.
12.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
12.5
Quantity
Quantity of the item defined for the given SOR.
12.6
Amount
The total amount for item arrive from Quantity * Rate.
12.7
Total
Grid Total of all the items added under labour.
13
Machinery
13.1
Code
Unique code defined for the machinery item.
13.2
Name
Name of the machinery item.
13.3
Unit
Unit of measurement on which item is measured.
13.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
13.5
Quantity
Quantity of the item defined for the given SOR.
13.6
Amount
The total amount for item arrive from Quantity * Rate.
13.7
Total
Grid Total of all the items added under machinery.
14
Conveyance
14.1
Code
Unique code defined for the material item.
14.2
Name
Name of the material item.
14.3
Unit
Unit of measurement on which item is measured.
14.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
14.5
Quantity
Quantity of the item defined for the given SOR.
14.6
Amount
The total amount for item arrive from Quantity * Rate.
14.7
Total
Grid Total of all the items added under material.
15
Royalty on Minerals
15.1
Code
Unique code defined for the material item.
15.2
Name
Name of the material item.
15.3
Unit
Unit of measurement on which item is measured.
15.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
15.5
Quantity
Quantity of the item defined for the given SOR.
15.6
Amount
The total amount for item arrive from Quantity * Rate.
15.7
Total
Grid Total of all the items added under material.
16
DMF
16.1
Code
Unique code defined for the material item.
16.2
Name
Name of the material item.
16.3
Unit
Unit of measurement on which item is measured.
16.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
16.5
Quantity
Quantity of the item defined for the given SOR.
16.6
Amount
The total amount for item arrive from Quantity * Rate.
16.7
Total
Grid Total of all the items added under material.
17
EMF
17.1
Code
Unique code defined for the material item.
17.2
Name
Name of the material item.
17.3
Unit
Unit of measurement on which item is measured.
17.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
17.5
Quantity
Quantity of the item defined for the given SOR.
17.6
Amount
The total amount for item arrive from Quantity * Rate.
17.7
Total
Grid Total of all the items added under material.
18
Additional Charges
18.1
Code
Unique code defined for the material item.
18.2
Name
Name of the material item.
18.3
Unit
Unit of measurement on which item is measured.
18.4
Basic Rate
Rate of item defined for a unit, always latest available rate is fetched.
18.5
Quantity
Quantity of the item defined for the given SOR.
18.6
Amount
The total amount for item arrive from Quantity * Rate.
18.7
Total
Grid Total of all the items added under material.
19
Extra Charges
19.1
Description
Extra charge description
19.2
Applicable On
The type of SOR it is applicable, e.g. Material, Labour, and Machinery.
19.3
Calculation Type
Fixed/ Percentage.
19.4
Figure
The figure for fixed or percentage calculation type.
19.5
Amount
The calculated value, Basic Rate * Figure, or user entered fixed value.
20
Grand Total
Total of all Material + Labour + Machinery + Convenance + Royalty + DMF + EMF + Additional Charge
21
Labour Cess
Labour cess = 1% of Grand Total.
22
Rate/ Qty UOM
This is the calculated rate for rate analysis quantity defined.
23
Rate/ UOM
This is the calculated rate for SOR per unit quantity.
24
Rate/ UOM
This is existing rate for SOR per unit quantity.
25
View History
A link to take the user to view rate analysis history page.
26
Take Actions
Add Analysis - Enables users to add a new analysis from new effective date. Edit Analysis - Enable the user to edit analysis with the same effective date. Revise Rate - Enable the user to revise the rate, in case there is difference between existing SOR basic rate and rate according to rate analysis.
View History - It takes the user to view history of rate analysis.
Edit Analysis - It takes the user to the add/modify rate analysis page.
Revise Rate - Enable the user to revise the rate, in case there is difference between existing SOR basic rate and rate according to rate analysis.
Not applicable.
The components/ heads defined to calculate the SOR rates are as given below.
Basic Rate
Conveyance
Royalty on Minerals
Environment Management Fund (EMF)
District Mineral Fund (DMF)
Additional Charges
Labour Cess
Calculation Logic
Basic Rate
Rate Analysis Basic Rate is calculated for the quantity define for analysis.
SOR Basic Rate = (Basic Rate*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Conveyance
Conveyance is calculated for the quantity define for analysis.
SOR Conveyance = (Conveyance*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Royalty on Minerals
Royalty is calculated for the quantity define for analysis.
SOR Royalty = (Royalty*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
EMF
EMF is calculated for the quantity define for analysis.
SOR EMF= (EMF*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
DMF
DMF is calculated for the quantity define for analysis.
SOR DMF= (DMF*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Additional Charges
Additional charges is calculated for the quantity define for analysis.
SOR Additional charges= (Additional charges*Quantity defined for SOR)/ (Quantity defined for Rate Analysis).
Labour Cess
SOR Labour Cess = 1% of (SOR Basic Rate + SOR Conveyance + SOR Royalty + SOR EMF + SOR DMF + SOR Additional charges);
SOR Rate = Basic Rate + Conveyance + Royalty + EMF + DMF + Additional Charges + Labour Cess;
Not applicable
View Rate Analysis display the currently effective rate analysis.
It allows the user to view history of rate analysis.
Revising rate of single SOR is allowed.
Search Estimate Template
Home > Estimate Template > Search Template
State: STATE_MUKTA_ADMIN
ULB: MUKTA_ENG_ADMIN
Search Template is provided to list all the template.
There are various search parameters to search a template.
Sr. No.
Field Name
Data Type
Description
1
Project Code
Drop-down
Project types
2
Template Name
Text
It is name of template
3
Template Code
Drop-down
It is system generated unique code to identify the template
4
Status
Drop-down
Active/ Inactive.
At least one parameter is required to perform the search.
Exact search is performed for the values entered/selected.
In case multiple parameters values are supplied AND is applied for searching record.
Pagination to be enabled.
Search result is displayed as given below.
Sr. No.
Field Name
Description
1
Code
It is system generated unique code to identify the template
2
Name
Template name.
3
Description
Template description.
4
Status
Active/ Inactive.
Search - To perform the search based on the parameters entered.
Clear - To clear the values entered for search.
Template Code - Hyperlink to view the template detail on mouse click.
Not applicable.
Not applicable.
Not applicable.
Search is provided with the parameters provided.
Result is shown as provided in the table and wire-frame.
Pagination is provided.
Modify Estimate Template
Home > Search Template> Template Code (Hyperlink) > View Template> Modify (action)
State: STATE_MUKTA_ADMIN
Modify template is provided to enable the users to make the correction in the existing template details.
The attributes which are allowed to modify are as given below table.
Sr. No.
Field
Data Type
Is Mandatory ?
Description
1
Code
Display
Yes
A unique code generated for template.
2
Project Type
Drop-down
Yes
Project types values from master data.
3
Name
Text
Yes
Name given to template.
4
Description
Text
Yes
The description, describing the template in detail.
5
Status
Drop-down
Yes
Status of the template Active/ Inactive
5
Search SOR
Search
Yes
To search an SOR and add to the template.
6
SORs
6.1
Sr. No.
Display
Yes
Serial number.
6.2
Sub Type
Display
Yes
SOR Sub Type
6.3
SOR Code
Display
Yes
SOR Code
6.4
Description
Display
Yes
SOR description
6.5
Unit
Display
Yes
Unit of measurement
7
Non SORs
7.1
Sr. No.
Display
Yes
Serial number.
7.2
Description
Text
Yes
Non SOR description
7.3
Unit
Drop-down
Yes
Unit of measurement
Submit - On Submit,
Changes are saved and success toast message is displayed.
The existing estimates which has already used the template remains unaffected.
Changes to template are saved successfully.
Not applicable.
Not applicable.
Not applicable.
Estimate template is modified.
Estimates created remains unchanged.
Add/ Edit Rate Analysis
Home > Search SOR > View SOR > Add Rate Analysis (action)
Home > Search SOR > View SOR > Edit Rate Analysis (action)
State: MUKTA_STATE_ADMIN
Add/Edit rate analysis feature is provided to add or modify the Rate Analysis.
To add the rate analysis, “Add Analysis” action is provided from SOR view page for those SOR which doesn’t have a rate analysis linked.
To edit the rate analysis, “Edit Analysis” action is provided from SOR view page for those SOR which has a rate analysis linked.
To add a SOR item into rate analysis, it should be active.
For rate analysis, only Item Code, Description, UOM, and Quantity is stored. Rates then calculated on fly.
The attributes defining rate analysis are given in below table.
Sr. No.
Field Name
Is Mandatory?
Description
1
SOR Code
Display
System generated unique code to identify a SOR.
2
SOR Type
Display
SOR Type as defined and updated.
3
SOR Sub Type
Display
SOR sub types as defined and updated.
4
SOR Variant
Display
SOR variant as defined and updated.
6
SOR Unit of Measurement
Display
Unit of measurement of SOR.
7
Rate Defined for Quantity
Display
The quantity for which SOR rate is defined.
8
SOR Description
Display
SOR description.
9
Status
Display
Active/ Inactive.
Constituents
Section
10
Effective From
Date
A effective from date, any date while adding rate analysis first time. Second time onward new analysis can be added from a future date only.
11
Analysis Defined for Quantity
Numeric
The quantity for which rate analysis is defined.
12
Material
Grid
SOR of type Material.
12.1
Code
Display
Unique code defined for the material item.
12.2
Name
Search
Name of the material item.
12.3
Unit
Display
Unit of measurement on which item is measured.
12.4
Quantity
Numeric
Quantity of the item defined for the given SOR.
13
Labour
Grid
SOR of type labour
13.1
Code
Display
Unique code defined for the labour item.
13.2
Name
Search
Name of the labour item.
13.3
Unit
Display
Unit of measurement on which item is measured. Mostly Nos.
13.4
Quantity
Numeric
Quantity of the item defined for the given SOR.
14
Machinery
Grid
SOR of type machinery
14.1
Code
Display
Unique code defined for the machinery item.
14.2
Name
Search
Name of the machinery item.
14.3
Unit
Display
Unit of measurement on which item is measured.
14.4
Quantity
Numeric
Quantity of the item defined for the given SOR.
16
Extra Charges
Grid
16.1
Description
Text
Extra charge description. E.g. Scaffolding Charges.
16.2
Applicable On
Drop-down
SOR type values, Material, Labour, Machinery.
16.3
Calculation Type
Drop-down
Fixed/ Percentage.
16.4
Figure
Numeric
The figure calculated for fixed or percentage calculation type.
16.5
Amount
Display
The calculated value, Basic Rate * Figure, or user entered fixed value.
Submit - On Submit
In case a new rate analysis is added.
A new rate analysis record is created and linked with SOR with the given effective date.
Existing rate analysis is closed with the previous day of new effective date.
View Rate Analysis Page is displayed with newly created rate analysis.
A success toast message is displayed.
In case existing rate analysis is edited.
Alert message is displayed to confirm if user wants to really modify existing rate analysis.
In case no changes made in the existing rate analysis, system displays an info message without saving it.
Upon confirmation, a new rate analysis record is created and made effective from same effective date.
Existing rate analysis record is made inactive.
View Rate Analysis Page is displayed with newly updated rate analysis.
A success toast message is displayed.
In case action is failed due to any reason, failure message is displayed.
Success Message - New Rate Analysis Added.
Rate analysis has been created for <SORCode> and made effective from <effective date>.
Success Message - Existing Rate Analysis Edited.
The rate analysis effective from <effective date> for <SORCode> has been modified successfully.
Alert! Existing rate analysis is edited.
Do you want to update existing rate analysis for <SORCode> effective from <effective date>? Please confirm to complete the action.
The rate analysis has not been modified as there were no changes done.
Adding new rate analysis is failed.
Modification to existing rate analysis is failed.
Out of 3 types of SOR items, adding at least one is mandatory.
All the quantities can be entered up to 4 decimal places.
All the amount calculated is rounded up to 2 decimal places.
Effective date should not be a date before current rate analysis effective date.
Effective from time is always start of the day i.e. 00:00. The time in between in the day is not allowed.
Effective to date, the time is always 11:59:59.
None.
Not applicable
Rate analysis is allowed to be added to an active SOR only.
All the validations are taken care.
On Add/ Edit Rate Analysis, rate for respective SOR is created and made effective.
Data Privacy: Changes in muster roll (AADHAAR to be removed)
Employee
Change in View/ Edit Muster Roll is required to implement data privacy.
The following details are to be removed from muster roll View and Edit Pages and PDF.
Account Number
IFSC
AADHAAR
Wage seeker ID should be a hyperlink to view the beneficiary details.
PII and sensitive information are displayed masked/unmasked based on the role of the logged-in user.
Rest remains the same as the existing muster roll.
Sensitive account information like IFSC and AADHAAR is to be removed from the muster roll view, edit, and PDF.
Wage seeker ID to be available as a hyperlink.
Wage seekers' details are displayed as masked/unmasked based on the role of the logged-in user.
Detailed estimate to be enhanced to search a template and add to the estimate.
Search Template option is provided where template can be searched by name.
Once a template is searched is added into estimate and hence all the SORs and Non-SORs from template get added to estimate automatically.
User can delete the SORs/ Non-SORs out of added ones.
User can add new SORs/ Non-SORs by searching SORs.
User should able to remove all SORs/Non-SORs added from template and add a new template.
User should be able to search and add a template.
User should be able to remove all SORs/Non-SORs added from a template.
User should be able to add/remove SORs/Non-SORs out of added template.
All the existing validations should be working as it is.
Data Privacy: Bank account details will be removed from the wage bill.
The wage bill is generated automatically by the system on approval of the muster roll.
As of now in the view wage bill details page, bank account details are displayed.
Bank account details are to be removed from the View Wage Bill page.
Muster Roll ID should be a hyperlink, on clicking it, opens into the View Muster Roll page.
The wage seeker ID should be a hyperlink, clicking it, opens the view wage seeker’s details.
Based on the role user can view the wage seeker’s details masked/unmasked.
Sensitive information account - IFSC to be removed from the view bill.
Muster roll ID and Wage seeker ID will be available as hyperlinks.
Wage seekers' details are displayed masked/unmasked based on the role of the logged-in user.
Privacy policy notice to be displayed on login to user for acceptance
Data Privacy: Privacy notice in login
The user is asked to accept the privacy policy when logging in.
A complete privacy policy is displayed for the user to read out.
Without acceptance, the user is not allowed to log in.
Click on the below file link to find the policy document -
The privacy policy is displayed on login.
The user is forced to accept the privacy policy when logging in.
Utilization Statements
Utilization statements are generated for measurement of work completed and captured in a MB. Utilization statements can be viewed and download from MB view screen.
ULB: MB creator, verifier, approver and viewer.
The utilization statements are generated out of saved MB details.
First, these are generated SORs wise.
Second, get consolidated to have Material Wise, Labour Wise, and Machinery Wise View.
The attributes and format is same for all three.
The option to download into PDF is provided.
The attributes defining detailed estimate are given in below table.
Not applicable.
Not applicable.
Not applicable.
Not applicable
HTML View:
PDF View:
Utilization is generated of material, labour and machinery required.
The format and template is same for all three.
Option to download these into PDF to be provided.
Analysis Statements
Analysis statements are generated for an estimate. These can be navigated from estimate view screen using view analysis statement.
ULB: Estimate creator, verifier, technical sanctioner, approver and viewer.
The analysis statements are generated out of saved estimate details.
First, these analysis statements are generated SORs wise.
Second, they consolidated to have Material, Labour , and Machinery Wise.
The attributes and format is same for all three statements
Option to download into these statements into PDF is provided.
The attributes defining detailed estimate are given in below table.
Not applicable.
Not applicable.
Not applicable.
Not applicable
HTML View:
PDF View:
Analysis is generated of Material, Labour and Machinery required.
The format and template is same.
Option to download these into PDF to be provided.
Analysis statements are generated out of an estimates and shared with CBO along with WO.
CBOs
The analysis statements are generated out of saved estimate details.
These are generated SORs wise and then consolidated to have Material Wise, Labour Wise, and Machinery Wise View.
The attributes and format is same for all three.
The option to download into PDF is provided from Work Order Details View page.
Labour Analysis
Material Analysis
Machinery Analysis
The attributes defining detailed estimate are given in below table.
Not applicable.
Not applicable.
Not applicable.
Not applicable
Analysis is generated of material, labour and machinery required.
The format and template is same for all three.
Option to download these into PDF to be provided.
Sr. No.
Field Name
Description
1
Code
SOR code of type material, labour, or machinery.
1.2
Description
SOR description of type material, labour, or machinery.
1.3
Unit
The unit of measurement
1.4
Rate
Rate per unit
1.5
Quantity
Total quantity required for the given SOR item.
1.6
Amount
Amount calculated rate*quantity.
1.7
Total
Total of all the material required for a given SOR item.
2
Grand Total
Total of all the material required.
Material Wise Consolidation
1
Code
SOR code of type material, labour, or machinery.
2
Description
OR description of type material, labour, or machinery.
3
Unit
The unit of measurement
4
Rate
Rate per unit
5
Quantity
Total quantity required.
6
Amount
Amount calculated rate*quantity.
7
Total
Total of all the material required.
Sr. No.
Field Name
Description
1
SOR Description
SOR item from the estimate.
1.1
Code
The item code from the lead charges
1.2
Name
The item name from the lead charges
1.3
Unit
The unit of measurement
1.4
Rate
Rate per unit
1.5
Quantity
Total quantity required for the given SOR item.
1.6
Amount
Amount calculated rate*quantity.
1.7
Total
Total of all the material required for a given SOR item.
2
Grand Total
Total of all the material required.
Material Wise Consolidation
1
Code
The item code from the lead charges
2
Name
The item name from the lead charges
3
Unit
The unit of measurement
4
Rate
Rate per unit
5
Quantity
Total quantity required.
6
Amount
Amount calculated rate*quantity.
7
Total
Total of all the material required.
Sr. No.
Field Name
Description
1
Code
The item code from the lead charges
2
Description
The item name from the lead charges
3
Unit
The unit of measurement
4
Rate
Rate per unit
5
Quantity
Total quantity required.
6
Amount
Amount calculated rate*quantity.
7
Total
Total of all the material required.
Data Privacy: View Muster Rolls changes
PII and sensitive information are to be removed from additional details of each service as per the analysis done.
Changes are to be made to restrict storing additional details with PII and sensitive data.
Not applicable.
PII and sensitive information are to be removed from additional details of each service.
Restrict them from getting stored again.
Data Privacy: Engage Wage Seeker changes
CBO
Mobile number to be removed from display of engaged wage seekers.
The details are displayed as given below.
Name
Father/ husband’s name
Address
The details given above are displayed only in cases where the role permission is “View_WS_Unmasked”.
For the other roles, the details given above are displayed masked.
The masking format is given below.
Name - displayed unmasked.
Father/ husband name: The first letter of each part of the name, followed by asterisks. (A** B******)
Address
Door No. - The first letter is shown, and the rest is masked.
Street name - The first letter is shown, and the rest is masked.
Locality - The first letter is shown, and the rest is masked.
Ward - The first letter is shown, and the rest is masked.
City - The first letter is shown, and the rest is masked.
Mobile number is removed from engaged wage seekers display.
PII and sensitive information displayed masked for roles with permissions other than View_WS_Unmasked.
For the user(s) having role permissions for View_WS_Unmasked PII and sensitive details are displayed unmasked.
View/ Edit Organization’s Details - PII data to be masked.
Employee
Change in View/ Edit Organization is required to implement data privacy.
PII and sensitive information to be masked for all other roles other than “View_ORG_Unmasked”.
The format of masking is as given below.
Door No. - The first letter is shown, and the rest is masked. e.g. 101A/2 → 1*****.
Street Name - The first letter is shown, and the rest is masked. e.g. Gandhi Marg → G********g.
Locality - The first letter is shown, and the rest is masked. e.g. Manohar Nagar → M***********r.
Mobile Number - The first 8 digits are masked, rest are displayed. e.g. 8888888888 → **********88.
Email ID - The first, last and domain are displayed, rest all are masked. e.g. nschauhan@gmail.com → n*******n@gmail.com
Account number - Only last 4 digits are displayed, rest all are masked with asterisk. e.g. 321004567621 → ********7621.
IFSC - The first 4 and last 2 digits are displayed, rest are masked. e.g. ICIC0000047 → ICIC*****47.
Branch Address -
Street number and specific street details are masked.
The district name is partially masked.
The city, state, and postal code remain visible.
PAN - The first 3 and Last 2 digit are displayed. rest are masked. BNQNS7208B → BNQ******8B.
GSTIN - The first 3 and Last 2 digit are displayed. rest are masked.
The details shown masked for the role other than View_ORG_Unmasked.
For the user having role “View_ORG_Unmasked” information displayed is unmasked.
View
Edit
Organization contact person PII and sensitive data are to be masked while displayed based on role.
A user having the role permission for “View_ORG_Unmasked” can see the details unmasked.
A user having a role permission other than “View_ORG_Unmasked” and view the details masked without an option to unmask it.
View/ Edit Wage Seeker's Details - PII data to be masked.
Employee
Change in View/ Edit Wage Seeker is required to implement data privacy.
PII and sensitive information are to be masked for all roles other than “View_WS_Unmasked”.
The format of masking is given below.
Name - displayed unmasked.
Identity number - Completely masked (Undisclosed) and for the role View_WS_Unmasked - (********1234)
Father/ husband name - The first letter of each part of the name, followed by asterisks. (A** B******)
Relationship - Completely masked (Undisclosed)
Address
Door No. - The first letter is shown, and the rest is masked. e.g. 101A/2 → 1*****.
Street Name - The first letter is shown, and the rest is masked. e.g. Gandhi Marg → G*********.
Locality - The first letter is shown, and the rest is masked. e.g. Manohar Nagar → M************.
Ward - The first letter is shown, and the rest is masked.
City - The first letter is shown, and the rest is masked.
Date of birth - Only the year is visible - **/**/1990
Gender - Complete masked. (Undisclosed)
Mobile Number - The first 8 digits are masked, rest are displayed. e.g. 8888888888 → **********88.
Social category - Complete masked. (Undisclosed)
Email ID - The first and last letters and domain are displayed, rest are masked. e.g. nschauhan@gmail.com → n*******n@gmail.com
Photo - Completely masked - Undisclosed
Account number - The last 4 digits are displayed, the rest are masked with an asterisk. e.g. 321004567621 → ********7621.
IFSC - The first 4 and last 2 digits are displayed, rest are masked. e.g. ICIC0000047 → ICIC*****47.
PAN - The first 3 and Last 2 digits are displayed. rest are masked. e.g. BNQNS7208B → BNQ******8B.
The details shown masked for the role other than View_WS_Unmasked.
For the user having role “View_WS_Unmasked” information displayed is unmasked.
Wage seekers' PII and sensitive data are to be masked while displayed based on role.
A user having the role permission for “View_WS_Unmasked” can see the details unmasked except the AADHAAR/ Identity number.
A user having role permission other than “View_WS_Unmasked” can view the details masked without an option to unmask it.
View Payment Instruction - Account Number and IFSC to be masked.
Employee
Change in View Payment Instruction is required to implement data privacy.
PII and sensitive information are masked so the users do not have a role to view it.
The format of masking is given below.
Account number - Only the last 4 digits are displayed, the rest are masked with asterisk. e.g. 321004567621 to ********7621.
IFSC - The first 4 letters and last 2 digits are displayed. e.g. ICIC0000047 to ICIC*****47.
The details shown are masked for the role other than View_WS_Unmasked, View_ORG_Unmasked, and View_DED_Unmasked.
For the user having roles View_WS_Unmasked, View_ORG_Unmasked, and View_DED_Unmasked information displayed is unmasked.
Beneficiaries' PII and sensitive data are to be masked while displayed based on role.
A user having roles View_WS_Unmasked, View_ORG_Unmasked, and View_DED_Unmasked can see the details unmasked.
A user having roles other than View_WS_Unmasked, View_ORG_Unmasked, and View_DED_Unmasked views the details masked.
Data Privacy: Track attendance changes
While updating attendance, wage seeker’s details are displayed as masked/unmasked based on the role the user has.
The father/husband's name is masked as per the role the logged-in user has.
Wage seeker details are displayed as masked/unmasked based on the role the user has.
Data Privacy: View Muster Rolls changes
While updating attendance, wage seeker details are displayed masked/unmasked based on the user's role.
The father/husband's name is masked based on the role the logged-in user has.
Wage seeker details are displayed as masked/unmasked based on the role the user has.
Data Privacy: View muster rolls changes to search for wage seekers interested in engaging with a project.
While updating attendance, wage seeker details are displayed masked/unmasked based on the user's role.
The father/husband's name is masked based on the role the logged-in user has.
Wage seeker details are displayed as masked/unmasked based on the role the user has.
