Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Work in Progress Will be formatted and removed
Contract Creator should be able to edit rejected contracts and resubmit them .
Rejected Contracts will show up in contract creators inbox.
Clicking on it will take to contract view screen. Users Click on “Actions” to make changes to contract.
Contract Details, ID, Contract Type and Project Details wont be editable.
Financial Details, Agreement Details are editable.
Creator Can make these changes and proceed to forward to checker.
Clicking on Rejected Contract ID from inbox will open Contract view page.
Clicking Actions-> Modify Contract will make page editable
From here on the flow is same as that of Create Contract. Once this Contract is submitted it is again moved to the respective Checker's inbox for approval. Contract can be rejected any number of times due to any specific reason which can be mentioned in the comments and the same comments are reflected in the View Contract screen.
Upon Successful update relevant acknowledgement screen displayed.
A contract that is approved and sent to next stage wont be editable.
Create Contract will have link to create contract from view approved estimate sub Estimate table screen.
Clicking on this will open create contract screen.
Add the following MDMS config to fetch the values of different dropdown filed of create estimate
Once the above details are filled, user needs to forward contract to concerned department and official for checking. Forwarding is considered as part of contract creation.Fill in the details and click “Forward and Approve”.
Once Create Contract API call is successful, an acknowledgement screen is shown.
Some of the dropdown data is fetched from mdms and hrms search API
Executing Department
MDMS
{
tenant,
"common-masters",
[ { "name": "Department" } ]
}
Designation
MDMS
{
tenant,
"common-masters",
[ { "name": "Designation" } ]
}
Designation of officer in charge
hrms
/egov-hrms/employees/_search
Name of officer in charge
hrms
/egov-hrms/employees/_search
Localization keys are added under the ‘rainmaker-works’ locale module. In future if any new labels are implemented in works module that should also be pushed in the locale DB under rainmaker-works locale module. Below is the example of few locale labels for hindi and English.
When creating a Contracts module, the module needs to be enabled in citymodule.json.
Add the Following details in citymodule.json
Overview
An estimate proposal is the simplest form of estimate that is created to start detailing the scope and financial aspects of a project.
An estimate proposal contains
Administrative details (Department, Work type, Work Category etc)
Financial Details (Fund, Function, Budget heads COA etc)
Work Details (Name of the work, estimated amount)
Processing details (Approving department, Approver designation)
Describes a group of individuals and their attendance details.
User should be able to create → Forward (or) check → Forward/Reject a contract.
Contracts will be created by contract_creator, Checked by contract_checker and approver by contract_approver. This will be linear workflow and rejected contracts at any point in lifecycle will come into inbox of creator.
Contracts counters on Home Screen will increase/decrease as the inbox items for checkers and approvers increase/decrease respectively.
Actions menu on view page of Work orders should have actions to be taken by respective Actors
For Work Orders (Non-Departmental)
WO is created by JE, Approved by ME. Checkers in between depends on Implementation and can vary from ULB to ULB
Approved WO goes into Work Order inbox of respective organisation.
Organisation can either accept or reject.
Rejected Work Orders will come back into inbox of creator and cycle repeats
For Work Orders (Departmental)
WO is created by JE, Approved by ME. Checkers in between depends on Implementation and can vary from ULB to ULB
Approved WO goes into Work Order inbox of respective organisation.
Organisation can either accept or reject.
Rejected Work Orders will come back into inbox of creator and cycle repeats
For Purchase Orders
PO is created by JE, Approved by ME. Checkers in between depends on Implementation and can vary from ULB to ULB. An Infra expert can be assigned to check PO.
Approved PO goes as SMS to registered Vendor
Vendor can click on the PO link & download approved PO’s PDF.
Once the Estimate are created they will move to the respective checker and approver's inbox as pending items.
From Contract Proposal Inbox, User can come into Contract View Screen where Details of Contract present while creating the contract and Workflow history will be displayed.
User can take necessary actions by clicking on Actions Menu.
An Action bar on the View Contract Screen shows the list of actions
Forward Contract
Reject Contract
Modify Contract
Approve Contract
When any action is clicked respective popup is rendered according to the selected action. We have created three popups for approve, forward and reject. They are shown below
When these popups are submitted, Update Contract API is called containing the relevant updates in the workflow object contained in the request body. The contract service internally calls the workflow service and updates the status of the application.
Upon successful update, a response screen is displayed as follows
Create an Estimate Proposal
When creating a works module, the module needs to be enabled in citymodule.json.
Add the Following details in citymodule.json
Estimate Creator will have link to create estimate from estimate inbox screen.
Clicking on this will open create estimate screen.
Add the following MDMS config to fetch the values of different dropdown filed of create estimate
Once the above details are filled, user needs to forward estimate to concerned department and official for checking. Forwarding is considered as part of estimate creation.Fill in the details and click “Forward Estimate”.
Each Work detail will be referred to as Sub-Estimate & sub Estimate will back track to all details of Estimate as-is. At least 1 Sub-Estimate has to be created to create an Estimate. Sum of All Amounts of Sub-Estimates is the Estimate Amount.
Once Create Estimate API call is successful, an acknowledgement screen is shown.
API Call Roll action-mapping
/estimate-service/estimate/v1/_create
9
EST_CREATOR
Some of the dropdown data is fetched from mdms and hrms search API
Executing Department
mdms
{
tenant,
"common-masters",
[ { "name": "Department" } ]
}
Ward, Location
mdms
{
"pb.amritsar",
"egov-location",
[ { "name": "TenantBoundary" }]
}
Beneficiary, Nature of Work, Type of Work
mdms
{
"pb,
"works",
[ { "name": "BeneficiaryType" },
{ "name": "EntrustmentMode" },
{ "name": "NatureOfWork" },
{ "name": "TypeOfWork" }, ]
}
Fund, Function, Budget Head,Scheme, subSchem
mdms
{
"pb",
"finance",
[ { "name": "BudgetHead" },
{ "name": "Functions" },
{ "name": "Fund" },
{ "name": "Scheme"} ]
}
Designation of officer in charge
hrms
/egov-hrms/employees/_search
Name of officer in charge
hrms
/egov-hrms/employees/_search
Localization keys are added under the ‘rainmaker-works’ locale module. In future if any new labels are implemented in works module that should also be pushed in the locale DB under rainmaker-works locale module. Below is the example of few locale labels for hindi and English.
Creator (EST_CREATOR)
Create/Edit(Rejected) Estimate and Forawrded
Checket1 (EST_CHECKER)
Checked Estimate and Forwarded
Checker2 (EST_TECH_SANC)
Checked Estimate and Forwarded
Admin Approver (EST_ADMIN_SANC)
Approved Estimate
User should be able to create → Forward (or) check → Forward/Reject an estimate.
Once the Estimate are created they will move to the respective checker and approver's inbox as pending items.
From Estimate Proposal Inbox, User can come into Estimate View Screen where Details of Estimate present while creating the estimate and Workflow history will be displayed.
User can take necessary actions by clicking on Actions Menu.
Sample ProcessInstance Worflow Object as given below:
An Action bar on the View Estimate Screen shows the list of actions
Forward Estimate
Reject Estimate
Modify Estimate
Approve Estimate
When any action is clicked respective popup is rendered according to the selected action. We have created three popups for approve, forward and reject. They are shown below
When these popups are submitted, Update Estimate API is called containing the relevant updates in the workflow object contained in request body. Estimate service internally calls the workflow service and updates the status of application.
Users must have the respective roles for taking actions on the Estimate, Otherwise the Action Bar will not be visible. And users can only take actions on the applications assigned to them.
Upon successful update a response screen is displayed as follows
EST_CHECKER
CHECK (Check and Forward) / REJECT
EST_TECH_SANC
TECHNICALSANCTION (Check and Forward) / REJECT
EST_ADMIN_SANC
ADMINSANCTION (Approve) / REJECT
Modify Estimate and Re-Submit Estimate
An Estimate proposal that is rejected by any user in the workflow will reach creators inbox.
Creator has to make necessary changes and resubmit the Proposal
A Rejected Proposal will have status as Rejected in Creators Inbox.
Clicking on Estimate ID from inbox will open estimates view page.
Clicking Actions-> Modify Estimate will make page editable
Except Date of Proposal everything will be editable. Estimate Proposal ID which is generated initially shown in modify screen.
From here on the flow is same as that of Create Estimate. Once this Estimate is submitted it is again moved to the respective Checker's inbox for approval. Estimate can be rejected any number of times due to any specific reason which can be mentioned in the comments and the same comments are reflected in the View Estimate screen.
Upon Successful update relevant acknowledgement screen displayed.
An Estimate that is approved and sent to next stage wont be editable.
Inbox screen for Attendance Management Module
Overview:
Lists all the musters submitted by SHG
To search/filter the muster list based on various criteria
To navigate to Muster details/View Attendance page
The employee home screen will have a link to navigate to the Attendance Inbox screen
The inbox screen consists of a list of muster rolls created/submitted by SHG in tabular format. This table supports pagination and the number of records displayed per page can be editable
A minimum of 1 search criterion is required based on which the list will be populated with search results. Search parameters are as below:
Name of the work
Implementing Agency/Partner
This list can be filtered based on below parameters:
Date range
Muster roll status
A ‘No results found’ message is displayed if no records are found for the given search/filter criteria.
Both search and filter criteria can be cleared using the ‘Clear Search’ and ‘refresh’ buttons respectively. Muster Roll ID is a clickable link that navigates the user to the View Attendance screen (Muster Details).
Inbox screen technical implementation can be found in the file below.
Hooks used
To fetch inbox details, ‘useCustomAPIHook’ is used which takes all the API details like URL, query params and body from config (defined in MDMS).
To fetch inbox config, ‘useCustomMDMS’ hook is used which takes the module name, master details and config.
APIs used
Endpoint:
Sample curl for Inbox API:
Inbox screen config is fetched from MDMS using 'useCustomMDMS' hook.
Localisation keys are added under the ‘rainmaker-attendencemgmt’ locale module. In future, if any new labels are implemented in the attendance module they should be pushed to the locale DB under rainmaker-attendencemgmt locale module. Below is an example of a few locale labels for Hindi and English.
The content on this screen is rendered based on configuration passed via MDMS. Its implementation can be found in the below file.
Screen to update muster roll status based on different roles
Objective: To view and modify the attendance days and perform various actions like verify, reject and approve based on roles.
Users can navigate to this screen by clicking on the muster roll id on the inbox page.
Initially, the muster has 'Submitted' status. Junior Engineer can view, Edit, Verify and Reject the Attendance.
Verify: Clicking on the ‘Verify’ action button verifies the existing muster and the user is redirected to the success page
Edit: Clicking on the ‘Edit’ action button displays the extra details in the table. The working days can be edited. Based on that ‘Modified Amount’ is updated dynamically.
As soon as the user updates anything ‘Action’ button changes to the ‘Save’ button. On click of Save, muster is verified with updated details and the user is redirected to the success page.
Reject: Clicking on the ‘Reject’ action displays a popup where the user can provide any comments and reject the muster.
On 'Confirm Reject', muster will be rejected and the user will be redirected to the success page.
The municipal Engineer can view, Approve, and Reject the attendance which is verified by Junior Engineer
Approve: Clicking on the ‘Approve action displays a popup where the user can provide any comments and approve the muster.
On 'Approve Attendance', the muster will be approved and the user will be redirected to the success page.
The municipal Engineer can also reject the attendance verified by Jr Engineer by clicking on the 'Reject' action.
Modify attendance technical implementation where all actions are handled can be found in the below file.
Hooks used
To update muster (modify, verify, reject, approve, resubmit), ‘useUpdateAttendance’ is used which updated muster roll details.
APIs used
Endpoint:
Sample curl for Update muster API:
Wage seeker skills data is fetched from MDMS using 'getMultipleTypesWithFilter' service.
Localisation keys are added under the ‘rainmaker-attendencemgmt’ locale module. In future, if any new labels are implemented in the attendance module they should also be pushed in the locale DB under rainmaker-attendencemgmt locale module. Below is an example of a few locale labels for Hindi and English.
The content on this screen is rendered based on the configuration passed on ApplicationDetails template component. Its implementation can be found in the below file.
Screen to view muster roll details for selected muster roll.
Objective:
To view weekly muster roll details/attendance for selected muster roll
To view the workflow history of the muster roll
Users can navigate to this screen by clicking on the muster roll id on the inbox page
The view screen consists of register details on top, Enrolled user details in tabular format, Workflow history and Actions that can be performed on selected muster. Initially, muster has ‘Submitted’ status.
View Attendance screen technical implementation can be found in the below file.
Hooks used
To fetch muster roll details, ‘useViewAttendance’ is used which takes tenant id and muster roll number.
To fetch workflow details, ‘useWorkflowDetails is used which takes tenant id, muster roll number, and business service (muster-roll-approval) as module code and config.
APIs used
Endpoint:
Sample curl for Search muster API:
Wage seeker skills data is fetched from MDMS using 'getMultipleTypesWithFilter' service.
Localisation keys are added under the ‘rainmaker-attendencemgmt’ locale module. In future, if any new labels are implemented in the attendance module they should also be pushed in the locale DB under rainmaker-attendencemgmt locale module. Below is an example of a few locale labels for Hindi and English.
The content on this screen is rendered based on the configuration passed on ApplicationDetails template component. Its implementation can be found in the below file.
/inbox/v2/_search
JUNIOR_ENGINEER
View inbox for Muster Rolls
/inbox/v2/_search
MUNICIPAL_ENGINEER
View inbox for Muster Rolls
/muster-roll/v1/_update
JUNIOR_ENGINEER
Reject
Send for Approval
Modify/Verify Muster Roll
/muster-roll/v1/_update
MUNICIPAL_ENGINEER
Approve
Reject
/muster-roll/v1/_search
JUNIOR_ENGINEER
View Individual Muster Roll
/muster-roll/v1/_search
MUNICIPAL_ENGINEER
View Individual Muster Roll