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...
Category
Services
GIT TAGS
Docker artifact ID
Remarks
FSM
FSM
fsm:v1.4.0-4ca02ac299-75
FSM calculator
fsm-calculator:v1.2.0-01dd6c9b3a-14
Vehicle
vehicle:v1.3.0-5682061fd3-18
Vendor
vendor-db:v1.3.0-ece6fa00d1-35
PQM
pqm-service:v1.0.0-7c253cb947-169
PQM Anomaly
pqm-anomaly-finder-db:v1.0.0-4eb854b58b-52
PQM Scheduler
pqm-scheduler:vNA-7201d5466b-13
Digit-UI FSM
DIGIT UI
sanitation-ui:v1.5.0-99fe703c60-449
DIGIT dependency builds
The FSM release is bundled with the DIGIT 2.8 release. Hence, the release builds for DIGIT 2.8 release can be accessed .
Configs
MDMS
Localisation
Devops
Introduced three new services: PQM Service, PQM Anomaly Service, and PQM Scheduler Service.
Create, update, and search for process quality monitoring tests.
Record test results gradually for a test and submit from evaluation when all the test results available
Evaluation of test values against benchmarks configured in MDMS, for producing a test result (FAIL/PASS) status.
Test results undergo anomaly analysis for comprehensive insights.
Plant performance related charts.
Actively monitors anomalies in process quality.
Added notification for relevant user groups promptly for proactive anomaly management.
Automation of test scheduling based on environment configuration and MDMS test standard configurations.
Triggers schedule APIs from PQM-Scheduler to generate tests at defined frequency.
Efficiently runs tests at specified intervals, ensuring a configurable approach.
A new worker registry concept has been introduced. Creating a worker, updating details, searching and tagging a worker for different operations on sanitation programmes. Sanitation workers' creation, updation, and search operations are performed using the individual registry.
Added functionality for creating, updating, and searching for sanitation workers.
Deprecated the drivers tab and added the driver concept from the FSM registry.
Introduced the sanitation workers tab to the FSM registry.
Added functionality for assigning. a sanitation worker to a vendor.
Migration of existing drivers to sanitation workers.
Deprecation of delinking of a driver with vendors introduced in v1.3.
Tag sanitation workers (drivers and helpers) to an FSM application for capturing the workers' activities.
The inbox for FSM has been upgraded from V1 to V2.
No core services have been modified. Workflow details, flow diagram, and API details are given in confluence.
Service
API's
Description
New/Update
PQM Service
/pqm-service/v1/_create
Adhoc create test
New
/pqm-service/v1/_update
Update test with results, save test with partial results as drafts
New
/pqm-service/v1/_search
Search for PQM tests
New
/pqm-service/v1/_scheduler
Schedule test based on the test standards in MDMS
New
/pqm-service/v1/_plainsearch
API for redexing the data
New
pqm-service/plant/user/v1/_create
Add plant and user mapping
New
pqm-service/plant/user/v1/_update
Update plant and user mapping
New
pqm-service/plant/user/v1/_search
Search for plant user mapping
New
PQM Anomaly FInder Service
/pqm-anomaly-finder/v1/_search
Search for anomalies
New
/pqm-anomaly-finder/v1/_plainsearch
Reindex the anomaly data
New
FSM
/fsm/v1/_update
Added list of workers object for tagging workers to the FSM application
Updated
Vendor
/vendor/v1/_update
Added list of workers object to assign sanitation worker to vendor
Updated
Enabling Samaaj (society), Sarkar (government), & Bazaar (industry/market) partners with a digital platform that would help ensure zero deaths, disease, and environmental contamination resulting from poor sanitation - a reality for every citizen across the Global South.
Water-Sanitation aims to ensure zero untreated waste by catalysing open digital ecosystems.
Category
Services
GIT TAGS
Docker Artifact ID
Remarks
Citizen
citizen:v1.8.0-b078fa041d-97
Employee
employee:v1.8.0-2ac8314b2f-116
DSS dashboard
dss-dashboard:v1.8.0-0d70d60e63-53
Encryption
egov-enc-service:v1.1.3-44558a0-3
xState chatbot
xstate-chatbot:v1.1.1-44558a0-2
Searcher
egov-searcher:v1.1.5-72f8a8f87b-16
Payment gateway
egov-pg-service:v1.2.3-ffbb7a6-4
Filestore
egov-filestore-db:v1.3.0-72d8393-4
Zuul - API gateway
zuul:v1.3.1-76bf31f-5
Mail notification
egov-notification-mail:v1.2.0-9fde481-3
SMS notification
egov-notification-sms:v1.1.3-48a03ad7bb-10
Localisation
egov-notification-sms:v1.2.0-9fde481-3
Persist
egov-persister:v1.1.5-3371bc2-5
ID gen
egov-idgen:v1.2.3-44558a0-3
User
egov-user:v1.2.8-9fde481-19
User chatbot
egov-user-chatbot:v1.3.0-6cfa52c1f9-1
MDMS
egov-mdms-service:v1.3.2-44558a0-3
URL shortening
egov-url-shortening:v1.1.2-1715164454-3
Indexer
egov-indexer:v1.1.7-44558a0-3
Report
report:v1.3.4-96b24b0d72-16
Workflow
egov-workflow-v2:v1.3.0-fbea797-11
PDF generator
pdf-service:v1.1.6-96b24b0d72-22
Chatbot
chatbot:v1.1.6-72f8a8f87b-8
Deprecated
Access control
egov-accesscontrol:v1.1.3-72f8a8f87b-24
Location
egov-location:v1.1.5-fbea797-5
OTP
egov-otp:v1.2.3-9fde481-3
User OTP
user-otp:v1.2.0-9fde481-8
NLP engine
nlp-engine:v1.0.0-fbea6fba-21
No changes in the current release.
Egov document-Uploader
egov-document-uploader:v1.1.1-6cfa52c1f9-4
National dshboard ingest
national-dashboard-ingest:v1.0.1-44558a0-3
New service
National dashboard Kafka pipeline
national-dashboard-kafka-pipeline:v1.0.1-44558a0-3
New service
Apportion
egov-apportion-service:v1.1.5-72f8a8f87b-5
Collection
collection-services:v1.1.6-c856353983-29
Billing
billing-service:v1.3.4-72f8a8f87b-39
HRMS
egov-hrms-db:v1.2.6-116d8db-9
Dashboard analytics
dashboard-analytics:v1.1.7-1ffb5fa2fd-49
Dashboard ingest
dashboard-ingest:v1.1.4-72f8a8f87b-10
EGF instrument
egf-instrument:v1.1.4-72f8a8f87b-4
EGF master
egf-master:v1.1.3-72f8a8f87b-15
Finance collection Voucher consumer
finance-collections-voucher-consumer:v1.1.6-96b24b0d72-18
Individual
User event
egov-user-event:v1.2.0-c1e1e8ce24-21
Inbox
inbox:v1.3.1-733167672c-14
Custom consumer
egov-custom-consumer:v1.1.1-72f8a8f87b-3
egov-pdf:v1.1.2-344ffc814a-37
eDCR
egov-edcr:v2.1.1-1815083c26-25
Finance
egov-finance:v3.0.2-0d0a8db8ff-28
Frontend (old UI)
Core Services
Business Services
Municipal Services
Utilities Services
eDCR
Finance
Introducing New Services for Enhanced Process Quality Management
Process Quality Management (PQM) Service.
Process Quality Management (PQM) Anomaly Finder Service.
PQM Scheduler (CronJob Scheduler).
Enhancements
Sanitation Worker Welfare feature
Driver-Individual migrate feature
FSM inbox V2
Process Quality Management (PQM) Service
Create, update, and search for process quality monitoring tests.
Evaluate test values against benchmarks, producing a result (FAIL/PASS) status.
Test results undergo anomaly analysis for comprehensive insights.
Plant performance related charts.
Process Quality Management (PQM) Anomaly Finder Service
Actively monitors anomalies in process quality.
Notifies relevant user groups promptly for proactive anomaly management.
PQM Scheduler (CronJob Scheduler)
Automates test scheduling based on environment configuration.
Triggers schedule APIs from PQM-Service to generate tests.
Efficiently runs tests at specified intervals, ensuring a configurable solution.
Sanitation worker welfare feature
A new worker registry concept has been created.
The creation of a worker, updation of details, searching and tagging a worker for different operations on sanitation programmes.
Driver-individual migration feature
The driver-individual migration scripts is responsible for fetching all existing drivers in the system and subsequently generating creates corresponding individuals in the system.
FSM Inbox V2
The inbox for FSM has been upgraded from V1 to V2.
New Docs
The waste we flush down the toilet does not always go into a sewer. Approximately 70% of the households in India have toilets connected to septic tanks or soak pits, technically known as on-site containment systems. They accumulate and store faecal matter over a long period. In sewers, the faecal matter travels daily with a lot of water through long concrete pipes. But in the case of on-site systems, it stays stored for about 3-5 years. Once the storage is full, the waste is emptied and transported to the treatment plant through vacuum trucks. The end-to-end value chain of safe storage, collection, transport, treatment, and end-use or disposal of faecal matter is called Faecal Sludge and Septage Management or FSSM. ‘Faecal Sludge’ and ’Septage’ are used to describe faecal matter in a specific physical and chemical state after prolonged storage.
FSSM has emerged as a cost-efficient population scale alternative to the networked sewer, which has been the traditional method of wastewater management.
Cost-effective: FSSM is 10 times cheaper than sewer systems.
Coverage: Less than one-third of urban toilet users are connected to sewer systems. The rest are more or less dependent on FSSM systems. Targeting FSSM will help us impact the maximum number of citizens.
Scale: In India's Swachh Bharat mission, 11 crore toilets were constructed across the country. Most are connected to on-site systems, which again increases the need for FSSM.
Our current understanding of the problems in septage management is based on our interactions with stakeholders and thorough published reports, and whitepapers. We are aware that FSSM systems have interdependent parts, and each stage of the FSSM value chain impacts how effectively the next stage functions. For instance, if the septic tanks do not have proper access, they will add to the cost of emptying, adding time and cost burden on desludging operators (DSOs). Similarly, it becomes unviable for the DSOs to dump the waste at the treatment plant if it is far from the city which is often the case.
While the linear sanitation value chain provides an understanding of the flow of faecal sludge, it does not capture all stakeholders in the process that control and influence the current effectiveness of sanitation systems.
We will use a systems mapping approach to outline the different factors and interactions within the sanitation value chain. We will explore systemic challenges at each part of the value chain that result in poor sanitation outcomes.
City managers, central/state governments
While sanitation is a priority of the central and state governments, city administrators have been strapped due to deficiencies in standards, building codes, municipal processes, and contracting and monitoring capabilities. These make it difficult to ensure the adequacy, usability, and safety of the toilets provisioned by public funds.
Masons
Masons are fundamental in proper construction of toilets and containment units. But a majority of masons currently lack the necessary training on construction standards. They are rarely employed using formal contracts, contributinb to the lack of traceability and accountability during the construction of toilets.
Citizens
Lack of awareness of the impact of improper construction of toilets and containment tanks, or constraints of affordability and space, leads citizens to influence masons to build containment units that do not follow technical standards. It is difficult to identify trained masons and services are procured through social networks and word of mouth.
Desludging operators
Lack of proper access to the containment systems adds time-cost to service.
Treatment plants are located far from the city, making safe dumping unviable.
While the payment from citizens is a clear incentive for emptying the tanks or pits, there are no incentives to ensure the safe transport of the faecal sludge to the treatment plant.
Operations remain inefficient without timely and useful information for service delivery. Working conditions are risky, but provisions for personal protection equipment and emergency healthcare services are rare.
Citizens
It is difficult to identify and book desludging services and service delivery is not reliable.
Low-income households are denied service since they are not able to afford the full cost.
City managers, central/state governments
Challenging to regulate the market for safe dumping without compromising service delivery.
Lack of clear and actionable information in terms of safe or unsafe dumping of faecal sludge.
Lack of pricing policies, infrastructure standards, licensing processes, and contracting and monitoring capacity limit the ability of decision-makers to take action.
City managers, centre/state governments
Difficult to regulate the market across various stages of construction and operations.
Operational data of the treatment plant and process is often recorded offline and used for post-facto auditing. There is a pervasive lack of actionable information.
Lack of rational pricing policies, comprehensive service benchmarks and infrastructure standards, contracting and monitoring tools hamper corrective action.
Plant operators
The supply of desludging load varies in an unreliable and unpredictable manner, and over time, leads to system failure.
Treatment plant management and maintenance is difficult and costly, and the payments are often not linked to performance.
The performance is not directly causally linked to the environmental impact.
Operations are not monitored to facilitate preventive action within the plant, and lack any binding linkages with standard operating procedures and service level agreements.
Civil society and academia
In the absence of data, researchers struggle to create new knowledge around the failures, risks, and opportunities, as well as give recommendations for improvement.
Since policy and standards are not mapped to operational data, it is difficult for the ecosystem to translate knowledge to action, impact and access.
Government
Inability to trace the impact and proper usage of grants and subsidies for sanitation.
Limited state capacity in terms of budget, skilled human resources, tools, and technology. Coordination across multiple functions, such as standard-setting, policy-making, contracting, audit, monitoring, is needed to keep sanitation systems functional.
Limited penetration of technology, innovation, and competition in the sanitation sector, makes it difficult for the government to enforce accountability across internal processes and market interactions.
At the core of all systemic challenges, there are problems that hinder a systemic change, limit stakeholders from implementing changes, or even cause the system to collapse. The identified problems are explained below:
Current standards do not cover all aspects of sanitation and service delivery - such as standards of treated human waste, treatment plant technologies, and benchmarks, among others.
The ecosystem has created many standards, which are not formally notified or enforced.
Where standards exist, awareness and compliance are dismal for the following reasons:
Many actors in the value chain do not have the necessary knowledge, skills, or standard operating procedures.
Complexities in service delivery result in incomplete or improper service.
Poor requirement specifications in the Request for Proposals (RFPs) documents.
Model contracts exist but are not followed.
Delays in corrective action since contracts are not tightly coupled with monitoring.
Systemic data either does not exist or remains disjointed to understand how much waste exists, where, when, with whom, and why.
Feacal sludge tends to drop out of the value chain, untreated.The unavailability of the information - who dropped it, when, how, or where it ended up polluting the environment - hampers the process of taking corrective and preventive measures
Data around faceal sludge (how much, where, when, who is responsible) is too little.
Required data is not created, available, or shared across relevant ecosystem actors. As a result, the performance of sanitation systems remains opaque and unobservable.
Current systems are not structured to maximise the value from faceal sludge and related services.
The policy framework may not recognise treated human excreta as compost. Unclear and fragmented demand for treated waste contributes to lax operations upstream.
The release provides the functionality of tagging the gram panchayat (GP) and villages via urban local bodies (ULBs). The ULB will be servicing desludging requests for households in the respective GP.
The functionality included are:
Adding GPs while creating an application.
Make the amount per trip field editable for GPs.
Updated
DIGIT Sanitation started with and in future, we will pick up Solid Waste Management (SWM). Beyond that, we believe that the platform can be leveraged for other waste streams but the nature of our intervention will be evolve.
Click to access the backend service document.
Adding GPs while creating an application
The user can add a GP and the villages under that GP while creating an application. The GPs are tagged to the ULBs closest to them. The ULBs will be servicing the desludging requests from the GPs and the villages falling under that GP.
Make the amount per trip field editable
Once the application is created with a selection of GPs, the amount per trip field will become editable for the user.
pqm-persister
PQM
Added persister config for the pqm service.
pqm-anomaly-persister
PQM-Anomaly
Added persister file for the pqm-anomaly service.
pqm-indexer
PQM
Added indexer file for the pqm service.
pqm-anomaly-indexer
PQM-anomaly
Added indexer file for the pqm-anomaly service.
pqm-inbox-indexer
PQM
Added inbox indexer file for the pqm service.
Vendor-persister
Vendor
Updated vendor-persister file for sanitation worker feature.
FSM-persister
FSM
Updated fsm-persister file for sanitation worker feature.
TQM Chart API changes
PQM
Added chart API configs for TQM plant operator landing page.
PQM Download PDF
PQM
Pdf download configuration for test results summary
PQM
Save test on creation
save-test-application
Update test
update-test-application
Update test workflow
update-workflow-test-application
Save test topic for inbox
save-test-event-application
Update test topic for inbox
update-test-event-application
Anomaly topic for when a test fails
create-pqm-anomaly-finder
Anomaly topic for when a test result has not been submitted
testResultNotSubmitted-anomaly-topic
Creation of plant-user mapping
save-plant-user-mapping
Updation of plant-user mapping
update-plant-user-mapping
PQM Anomaly Finder
Anomaly topic for when a test fails
save-pqm-test-anomaly-details
Anomaly topic for when test result not submitted
testResultNotSubmitted-anomaly-topic
Save anomaly topic
create-pqm-anomaly-finder
Event (In-App) Notification
persist-user-events-async
FSM
Save new FSM application
save-fsm-application
Update FSM application
update-fsm-application
Update FSM application workflow
update-fsm-workflow-application
Update vehicle trip details
update-vehicle-trip-Details
Save plant user mapping
save-plant-map-application
Update plant user mapping
update-plant-map-application
Receipts get pushed to this topic
egov.collection.payment-create
SMS notification topic
egov.core.notification.sms
Event (In-app) notification topic
persist-user-events-async
Vendor
Save vendor topic
save-vendor-application
Update vendor topic
update-vendor-application
Save driver topic
save-driver-application
Update driver topic
update-driver-application
Update vendor-driver and vendor-vehicle relationship
save-vendordrivervehicle-application
TQM UI Tech Documentation
TQM is an independent UI module which only depends on the core UI libraries.
Here are the articles in this section:
1
Development is completed for all the features that are part of the release.
Yes
@ Pritish.Rath
Code was frozen by 10-01-2024.
2
Test cases are documented by the QA team, and reviewed by the product owners, and test results are updated in the test cases sheet.
Yes
All test cases are reviewed by the Product Owner and results have been updated in the sheet. QA sign-off is given accordingly.
3
The incremental demo of the features showcased during the sprint showcase and feedback is incorporated. If possible, list out the JIRA tickets for feedback.
Yes
Demo given on 20-12-2023 for PQM, and 02-01-2024 for Sanitation Worker.
4
UI/UX audit review by UX architect is completed along with feedback incorporation for any changes in UI/UX.
Yes
@ AndrewJones
UI/UX audit is done and review comments are incorporated.
5
Incremental demos to the product owners are completed as part of the sprint and feedbacks are incorporated.
Yes
Demo given on 20-12-2023 for PQM, and 02-01-2024 for Sanitation Worker.
6
QA sign-off is completed by the QA team and communicated to the product owners. All the tickets' QA sign-off status is updated in JIRA.
Yes
All test cases are reviewed by the Product Owner and QA sign-off is given accordingly.
7
UI, API technical documents are updated for the release along with the configuration documents.
Yes
8
UAT promotion and regression testing from the QA team is completed. QA team has shared the UAT regression test cases with the product owners.
Yes
All test cases are reviewed by the Product Owner.
9
API automation scripts are updated for new APIs or changes to any existing APIs for the release. API automation regression is completed on UAT, the automation test results are analysed, and necessary actions are taken to fix the failure cases. Publish the list of failure use cases with a reason for failure and the resolution taken to fix these failures for the release.
Yes
Automation script is reviewed by the Tech Lead.
10
The API backward compatibility testing is completed.
Yes
Tested on 05-JAN-2024.
11
The communication is shared with the product owners for the completion of UAT promotion and regression by the QA team. The product owners have to give a product sign-off within one week of this communication.
Yes
UAT sign-off was completed. Sign-off dates 10th JAN 2024 for PQM and Sanitation Worker Welfare.
12
The UAT product sign-off communication is received from the product owners along with the release notes and user guides (if applicable).
Yes
UAT sign-off was completed. Sign-off dates 10th April 2023 for PQM and Sanitation Worker Welfare.
13
The GIT tags and releases are created for the code changes for the release.
Yes
Added a new git tag V1.4
14
Verify whether the release notes are updated.
Yes
15
Verify whether all UAT builds are updated along with the GIT tag details.
Yes
All the budils are added with release tag V1.4
16
Verify whether all MDMS, configs, InfraOps configs are updated.
Yes
17
Yes
18
Verify whether all test cases are up to date and updated along with necessary permissions to view the test cases sheet. The test cases sheet is verified by the Test Lead.
Yes
19
Verify whether the UAT credentials sheet is updated with the details of new users and roles, if any.
Yes
20
Verify whether all the localisation data was added in UAT, including Hindi, and updated in the release kits.
Yes
All localisations added as part of the release.
21
Verify whether the product release notes and user guides are updated and published.
Yes
22
The demo of the released features is done by the product team as part of the sprint/release showcase.
Yes
23
Technical and product workshops/demos are conducted by the engineering and product teams to the implementation team (Implementation handover).
Yes
Technical and product handover to impel conducted on 24-11-2023, and 04-01-2024. Signoff on handover is given on 11-01-2024
24
Architect sign-off and technical quality report.
Yes
Signed off on 02-Jan-2024.
25
Success metrics and product roadmap.
Yes
26
Adoption metrics.
Yes
27
Programme roll-out plan.
Yes
28
Implementation checklist.
Yes
29
Implementation roll-out plan.
Yes
30
Gate 2
31
The internal release communication along with all the release artefacts are shared by the engineering/product teams.
32
Plan for upgrading the staging/demo instance with the release product - within 2-4 weeks based on the period where no demos are planned from staging for the previous version of the released product.
33
The release communication to partners is shared by the GTM team and the webinar is arranged by the GTM team after the release communication - within 2-4 weeks of the release.
The following MDMS changes were done as part of the FSM v1.4 release:
For MDMS-V2 changes, refer to the below table for the sequence in which MDMS schema and data needs to be added for the PQM service:
data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json
data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json:
This page contains the changes related to Process Quality Management-related services (PQM) and Sanitation Worker Welfare along with the MDMS, DevOps and configuration setups required to accommodate these features.
The PQM service is required to create, update, search and evaluate tests against benchmarks. Follow the steps given below:
Configure the build.
Make the role action-mapping changes in the MDMS.
Master Data for PQM
Click on the Job-builder once the above steps are complete.
Restart the following services: egov-accesscontrol, egov-mdms-service, egov-persister
Configure the build.
Make the role action-mapping changes in the MDMS.
Click on the Job-builder once the above steps are complete.
Restart the following services: egov-accesscontrol, egov-mdms-service.
Configure the build.
Deploy the latest build of individual service refer link#
Code PRs for referenceL
Enabling TQM module in DIGIT-UI
To access the TQM module in DIGIT-UI, enable it from MDMS and add TQM specific roles for the user to access TQM UI.
Add the following configuration in citymodule.json under this path in MDMS. The reference file is given below.
Add TQM to these files in DIGIT-UI codebase. Add it in enabledModules Array.
Note: The name "TQM" should match the name "Tqm" added in mdms(citymodule). However, uppercase or lowercase does not matter.
frontend\micro-ui\web\micro-ui-internals\example\src\index.js
frontend\micro-ui\web\src\App.js
Files for reference:
Sample object:
PQM_TP_OPERATOR -> This role is for Plant Operator user
PQM_ADMIN -> This role is for ULB Admin user
Note: One user cannot have both these roles because flows and UI is different for these users. These roles are added in the mdms. The reference file is given below
Enhancements were made to the core module version to support some of the features in TQM UI such as help section and notification card in ULB admin's home page
The recommended core version for TQM UI is the following:
and
ULB User: , , PQM Service: , ,
Plant User: , ,
,
Verify whether all docs will be published to by the Technical Writer as part of the release.
Product showcase done on 10-01-2024 by
@Pritish.Rath
Make sure TQM and FSM is enabled in this master ->
data/pg/common-masters/howItWorks.json ->
data/pg/FSM/SanitationWorkerSkills.json ->
data/pg/FSM/SanitationWorkerEmploymentType.json ->
data/pg/FSM/SanitationWorkerEmployer.json ->
data/pg/FSM/SanitationWorkerFunctionalRoles.json ->
Add the .
Add the new persister file: .
Add the
Add the .
Add the .
Add the .
Add the .
Add mdms changes, refer to this .
Add config changes, refer to this .
Add the Helm chart, refer to this .
Deploy the latest build of vendor and FSM, refer to this .
Sanitation worker depends on the individual service. Refer to this .
Migrate all the drivers to individual using
Make sure UI MDMS changes are added from .
Refer to the technical documentation for TQM UI to run UI
Refer to the technical documentation for sanitation worker UI
PQM inbox
MDMS for inbox
Added MDMS configuration for inbox-v2 integration.
Role Action
MDMS
Added role-action mapping for all APIs of the PQM service.
PQM.BenchmarkRule
id, code, name
code
PQM.QualityTestLab
code
code
PQM.Material
code, name
code
PQM.Parameter
code, name
code
PQM.PlantConfig
code, pendingTestsToDisplayWithinDays, pendingTestsToDisplayWithinDaysInbox, pendingTestsToDisplayWithinDaysForULB, iotAnomalyDetectionDays, manualTestPendingEscalationDays
code
PQM.PlantType
code, name
code
PQM.ProcessType
code, name
code
PQM.Unit
code, name
code
PQM.WasteType
code, name
code
PQM.SourceType
code, name
code
PQM.Stage
code, name, output
code
PQM.Process
code, type, name, stages, wasteType
code
PQM.Plant
code, plantType, active
code
PQM.QualityCriteria
code, name, plantType, wasteType, address, processes
code
PQM.TestStandard
code, plant, process, stage, material, qualityCriteria, frequency, sourceType
code
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
manualTestPendingEscalationDays
The number of days after which a scheduled test that is still pending requires escalation.
pendingTestsToDisplayWithinDays
The number of days within which pending tests, assessments, or evaluations should be displayed or considered.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
input
Materials provided as input to a stage.
output
Materials provided as output to a stage.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
type
Defines the type of process.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
stages
A list of stages that come under a particular process.
wasteType
The classification of waste materials based on their characteristics or origin.
code
Alphanumeric or numeric representation assigned to uniquely identify the record.
name
Textual or human-readable identity given to a record.
description
Details or explanation for a record.
plantType
The classification of plants based on their processing.
wasteType
The classification of waste materials based on their characteristics or origin
address
Location details for a particular plant.
processes
A list of processes that happen under a particular plant.
plantConfig
Configuration details for a particular plant.
ULBs
Comma separted ULB list who have operational access to. e.g. pg.cityb, pg.cityb
PlusCode
Address of the plant. e.g. JQ2R+7G Khapar Kheri, Punjab
Latitude
Latitude of the plant location
Longitude
Logitude value of the plant location
PlantLocation
Location of the plant. e.g. Bhalasore
PlantOperationalTimings
Plant Operational Timings. E.g. 10.00am-08.00pm
PlantOperationalCapcityKLD
Capacity of the plant for operating at max. E.g.50
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
parameter
Anything that is measurable as an input/output for a particular stage.
unit
The unit for measuring this particular parameter.
benchmarkRule
The rules according to which a test value should be tested (For example, greater than, less than, equals to).
benchmarkValues
Specific numbers on which the benchmark rule is applied for a test value.
allowedDeviation
The acceptable difference from the benchmark values.
code
Alphanumeric or numeric representation assigned to uniquely identify the field.
plant
Plant code for which this test standard is registered.
process
Process code for which this test standard is registered.
stage
Stage code for which this test standard is registered.
material
Material code for which this test standard is registered.
qualityCriteria
The quality criteria which is applicable for the unique combination of plant, process, stage, and material.
frequency
The frequency at which this test standard should be scheduled.
sourceType
The origin of this particular test standard.
Attribute
Type
Mandatory
Comments
Validation Required?
Treatment Process ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a process flow
N, this value should be system generated
Process Name
Text
Y
This is the commonly used identifier for the process flow
Max characters - 256
Status
Array
Y
Status of the process flow
Active/Inactive, Single Select
Treatment Process Type
Array
Y
The dropdown will be auto populated basis the list of waste maintained in the MDMS
Single Select
Treatment Process Subtype
Array
Y
The dropdown will be auto populated basis the list of waste maintained in the MDMS
Single Select
Attribute
Type
Mandatory
Comments
Validation Required?
Plant ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a plan.
Auto-generated
Plant Name
Text
Y
This is the commonly used identifier for the plant
Maximum charatcters - 128
Plant Type
Array
Y
Single select only, faecal sludge, solid waste, co-treatment
Tenant Id
Text
Y
Status
Array
Y
Status of the plant
Active/inactive, single select
Geolocation
Latitude-Longitude
Y
Capture the exact latitude-longitude
Attribute
Type
Mandatory
Comments
Validation Required?
Stage ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a Job ID
Auto-generated
Stage Name
Text
Y
This is the commonly-used identifier for the Job
Maximum characters - 128
Minimum xharacters - NA
Status
Boolean
Y
Status of the stage
Active/inactive, single select
Input Quality Measurement Required
Boolean
Y
This selection will allow the user to set up if the input quality for the particular input type needs to be monitored. A user should be able to enable and disable input quality measurement requirement independently for each type
Yes/no, single select
Output Type
Array
Y
The dropdown will be auto-populated basis the list of output types
Multi-select
Output Quality Measurement Required
Boolean
Y
This selection will allow the user to set up if the output quality for the particular job needs to be monitored. A user should be able to enable and disable the output quality measurement requirement independently for each type
Yes/no, single select
Attribute
Type
Mandatory
Validation
Quality Parameter
Array
Y
Selecting from the predefined of the above-mentioned quality parameters and standards.
single select
Quality Parameter Unit of Measurement
Array
Y
Selection of the unit of measurement (mg/L, Absolute value etc). Single select
Benchmark Rule
Array
Y
Options include X>=,<=R, =<Y and >=Z, single select
Benchmark Value
Numeric
Y
Entered by user, numeric only
Testing Frequency - Manual (Days)
Numeric
Y
Selecting a custom frequency range for laboratory testing based on consent to operate, numeric only
Monitoring Frequency - Quality Sensor (Days)
Numeric
N
Selecting a custom frequency
Note: Should be optional if the ULB/state choses not to have sensor-based monitoring. Numeric only
Attribute
Type
Required?
Comments
Configuration Date
Datetime
Y
Device Type
Text
Y
Selection from the device master data
[“GPS Sensor”, “pH Sensor”, “Accelerometer”, “Light Sensor”]
Plant
Text
Y
Treatment Process
Text
Y
Stage
Text
Y
Output Type
Text
Y
Parameters
Array
Y
The parameters are monitored by the device
Monitoring Frequency
Numeric
Y
Custom frequency for the device
Calibration Date
Datetime
Y
Input from the user about any change in the calibration/maintenance of the device
Calibration Accuracy
Array
Y
Range to indicate the permissible deviation in the accuracy
IsConnected?
Boolean
Y
To indicate the connectivity of the device
Connectivity History
?
Y
Date-wise device audit log to know the connectivity status
Verification History
?
Date-wise device verification log to know the days when device input was verified with laboratory results
Attribute
Type
Mandataroy
Validation
Test ID
Alphanumeric
View only
Auto-generated on the creation of schedule
Plant Name
Text
View only
Auto-populated on the creation of schedule
Treatment Process
Text
View only
Auto-populated on the creation of schedule
Treatment Process Type
Text
View only
Auto-populated on the creation of schedule
Stage
Text
View only
Auto-populated on the creation of schedule
Output Type
Text
View only
Auto-populated on the creation of schedule
Test Type
Array
Lab/IoT, auto-selected to Lab
Parameter 1…n
Text
View only
Auto-populated on the creation of schedule
Testing Date
Date
View only
Date calculated through the predefined laboratory testing schedule
SLA
Numeric
View only
Difference between the current date and testing date: The compliance to a testing schedule can be checked through this field. However, the actions based on failed/successful compliance falls under vendor management, which is not in scope currently and will be taken up separately under vendor management
Status
Text
View only
Status to be auto set to ‘Scheduled’
Attribute
Type
Required?
Comments
Test ID
Numeric
Y
Auto-generated by system
Plant Name
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Treatment Process
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Treatment Process Type
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Stage
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Output Type
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Test Type
Array
Lab/IoT, auto-selected to lab for on demand
Lab Submitted to
Text
Y
This will not be required in case test type = IoT
Quality Parameter 1
Numeric
Y
Validation to be applied at impel
Quality Parameter 2
Numeric
Y
Validation to be applied at impel
Quality Parameter 3
Numeric
Y
Validation to be applied at impel
Quality Parameter n
Numeric
Y
Validation to be applied at impel
Collection Time
Date
Y
This is the date-time during which the user updates status to pending Results. for IoT, this is the time sensor records reading
Attachment
Document
Y
For a given collection location, photo or PDF proof of laboratory result mentioning the information of above-mentioned parameters
Attribute
Type
Required?
Comments
Alert DateTime
Datetime
Y
Auto-captured based on date-time
Alert Type
Text
Y
Auto-captured
Lab test results not as per the benchmark
Plant Name
Text
Y
Process Name
Text
Y
Process Type
Text
Y
Parameter 1…n
Text
Y
UoM
Text
Y
Benchmark
Number
Y
Results
Number
Y
Test Type
Text
Y
Auto-selected to lab/IoT, or both
Attribute
Type
Required?
Comments
Alert DateTime
Datetime
Y
Auto captured based on date-time
Alert Type
Text
Y
Auto captured
No reading received from the device
Plant Name
Text
Y
Process Name
Text
Y
Process Type
Text
Y
Device ID
Numeric
Y
The Driver-Individual Migration Scripts is responsible for fetching all existing drivers in the system and subsequently generating creates corresponding individuals in the system.
The data migration has been implemented in Vendor Service with latest stable build -
File Path -
File Path -
Please use FSM_ADMIN credentials for accessing this API.
PQM Business Service Request
Instructions for Production execution:
Replace the tenant id for production environment
Replace the request info object with production user info details
For PQM new Business service PQM has been created
Create businessService (workflow configuration) using the /businessservice/_create
. Following is the product configuration for PQM
Online solution to desludging operations management
Our mission is to build a digital tool that enables urban local body employees to deliver desludging services (emptying septic tanks) to citizens. The linear nature of feacal sludge value chains presents a clear framework for comprehending the optimal flow of sludge, but these value chains consist of diverse stakeholders and business models. The absence of coordination among value chain stakeholders and the lack of transparency to enforce standardised practices at each stage of the value chain lead to subpar sanitation outcomes. Furthermore, conflicts between stakeholders and the feasibility challenges of existing and emerging business models diminish the efficiency of the waste value chain.
The Faecal Sludge Management (FSM) application has been able to provide data and visibility to track service requests and understand the service delivery value chain, paving the way for process enhancements in FSM.
The product will provide the following benefits:
Reduce time taken for service delivery.
Establish a chain of custody of waste from the point of collection to disposal.
Digital record keeping of service deliveries.
Support data interoperability with other sanitation systems in the state.
Improve sustainability by providing visibility and control to the government.
Citizen
The citizen is able to have multi-channel access to safe and trackable service delivery. This leads to accountable and transparent services, and seamless grievance redressal.
They can receive push notifications with reminders for when their septic tank is due for desludging or with information on how to accurately segregate solid waste — to create behavioural nudges that contribute to healthier habitats.
Overall improvements in waste management and reduction in illegal dumping will mean that everyone lives in a cleaner and healthier neighbourhood, leading to public health gains (for example, a reduction in water-borne diseases).
Sanitation worker
The sanitation workers are skilled in safe sanitation practices, standards and tools.
Monitored service delivery will lead to optimisation of performance and create safe working conditions with transparency, ensuring compliance in safety practices.
Enumeration of sanitation workers will enable delivery of targeted benefits and welfare schemes for workers and their families (for example, health checkups, insurance, social security, scholarships for children, etc.).
ULB Employee
The ULB employee is able to create a single back-end registry for all incoming service requests. They are able to collect and maintain relevant citizen information to deliver efficient services.
The ULB employee is able to do remote tracking of value chain stakeholder — waste-transporters can be tracked in real-time to ensure that there is no illegal dumping of collected waste. They are able to ensure that quality of waste treatment meets the standards by validating automated records without being at the waste treatment plant.
Waste management vendors/Desludging Operators
Waste management vendors are able to assign tools and services that best suit the citizen who has raised the request by referring to the relevant information that would affect service delivery, such as property information. The ability to do this would make the process time and cost-effective.
Increasing the viability of waste management services will enable more private players to enter the fray, limit illegal dumping and eradicate opportunities for illegal manual scavenging.
Faecal Sludge/Co-treatment plant/Centre operator
The plant operator will be able to validate that there is no discrepancy in volume between the waste collected at the households and disposed off at the plant, ensuring that no waste drops off the value chain without treatment.
Adhere to the schedule for treatment quality, and record treatment quality results.
Adhere to the schedule for maintenance, and ensure that the plant is up and running efficiently.
Treatment plants can be plugged into waste-to-value markets, making it easier for buyers of processed and tested waste to discover and buy from them, thereby contributing to the financial sustainability of treatment plants.
Administrators
Govern the entire waste value chain via dashboards.
View the capacity available for transport and treatment at the state and ULB levels, and its utilisation via dashboards.
View compliance of SLAs and citizen satisfaction levels for services.
The current version provides the following features:
Define pricing for desludging services based on the property type, sub-type and volume, and categories where services are free/subsidised.
Interface for citizens to request for desludging services and track service delivery.
Interface for urban local bodies (ULBs) to record service requests received via multiple channels, and track service delivery.
Interface for Faecal Sludge Treatment Plant (FSTP) operators to record the entry of vehicles against service requests.
Interface for FSTP operators to record the entry of vehicles without service requests.
Collect feedback from citizens on the completion of service delivery.
Define and monitor against SLAs.
Assignment of requests to transportation vendors.
Interface for transport vendors to manage requests and track the status of requests.
Assignment of vehicles and drivers to service requests.
Calculate service fees based on the defined pricing and the number of trips.
Define the minimum amount payable at the ULB level while requesting for services.
Collect part payments in advance and the rest as balance.
Interface for citizens to make payments via a payment gateway.
Interface for ULBs to collect and record payments.
Generate receipts.
Send notifications via SMS.
Send in-app notifications.
Dashboards at the state and ULB levels.
- View KPIs (Total requests, trends in requests, SLAs, and capacity utilisation of FSTPs, and vendor performance).
- Filters (Time, ULB)
Reports
The following masters are also maintained as part of the product:
Vehicle master
Driver master
Vendor master
Treatment plant master
Every plant operator created will be linked to one or more plants under an urban local body (ULB).
When a plant operator logs in to the system, the top bar is populated with a dropdown which shows a list of plants this user (plant operator) is linked to.
By default, the option "All Plants" is selected.
When a user selects a plant, lets say, plant A, all the data of plant A will be shown in the app, whether it's inbox, view past results page, home page, etc.
Whenever a change in a plant is detected through the dropdown, the app is redirected to the landing screen.
A plant operator is a sanitation worker; while creating a sanitation worker, you can link the sanitation worker to one or multiple plants.
Data such as a list of the current user's plants and active plant is stored in session storage, and is available to use within the app.
Whenever a plant operator logs in, he/she can make a call to this API endpoint "/pqm-service/plant/user/v1/_search" to get a list of the plants that the user is linked to .
Sample payload:
Send the user's individual id/uuid in the request object.
Curl for the above API call:
You will get a list of plants in the response which is used to populate the dropdown.
By default, the "All Plants" option is selected which is the default behaviour.
When a user selects a particular plant, it becomes active and one can filter the data (all tests shown in the app) by that plant's code in the UI.
UI for the top bar:
Every page in the plant operator's screen has a help button on the top right.
Clicking on it takes the user to the help screen which shows a list of videos. Each video has a title and a description.
Clicking on a video runs it in a media player.
Flows in the app can be stored in a video and it can be shown in this screen.
This page is fully configurable through MDMS.
Refer to the following MDMS file to configure the list of videos:
Multiple languages can be configured. Currently, English and Hindi are the two options available.
Sample configuration object:
The above configuration object is used to render the screen. It has a video level header and description along with URLs for Hindi and English videos. The page level header is also present.
The module name can be configured. For example, here we have added the module name as TQM.
From the TQM card in the home screen, there is a link to the Inbox.
The inbox will show a list of tests that are in workflow.
Filters and search options are available such as Treatment process, Stage, Output, Status, Test Id and Plant name.
Clicking on a test will take the user to the test details screen.
Note: Unlike the plant operator inbox, this inbox is only for visibility purposes. A ULB admin cannot take any action in the tests that are in the inbox.
The test detail screen will show all the details about the test and status of the test.
When tests are in the submitted status, it's status will show as PASS or FAIL depending on the values of the benchmark.
If tests are in the workflow, it's status will show as pending.
Use inbox-v2 API.
URL for inbox "/inbox/v2/_search".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_search" and "/inbox/v2/_search" endpoint for a ULB admin user role, that is:
Use pqm-service.
URL for search "/pqm-service/v1/_search".
Sample request object:
From the TQM card in the home screen, there is a link to "View Past Tests".
The view past tests screen will show the tests whose workflow is completed, that is, they are in the submitted status.
The screen shows a list of cards, each card corresponding to a test, and shows test details similar to inbox.
Filters and sort options are available.
User can filter by Treatment process, Output Type, Test Type and the date range.
Sort is similar to inbox.
Use the pqm-service.
URL for search "/pqm-service/v1/_search".
Sample request object:
Role-action mapping is done for the search endpoint for a plant operator user role, that is:
This screen is similar to the View Past Test Results screen for a plant operator.
Refer the following page View Past Test Results/Test's Summary Screen
UI for reference:
From the TQM card in the home screen, there is a link to the inbox.
Tests are created through the cronjob scheduler at the backend.
These tests created have a two-step workflow: Scheduled (initial state) -> Select Lab -> Pending Results -> Submitted (final state).
By default, tests which are in the workflow, will show up in the inbox of a plant operator. The inbox shows a list of cards corresponding to each test.
Each card contains data relevant to the test such as Test ID, Treatment Process, Stage, Output, Status, etc.
There is a dynamic action button in each card. According to the current workflow status, it will show either update status (scheduled state) or update results.
Clicking on the update status opens an update test screen which shows data about the test and a dropdown which has a list of labs configured in MDMS. A user can select one of the labs and update the test.
Clicking on update results opens an update test screen, which also shows the same test details, but the bottom card shows a list of benchmarks to be tested in that test. A user can enter these benchmarks and update the test. There is an option to upload a document as well, and at least one benchmark is mandatory to enter.
A success/failure toast is shown once the test is updated.
Filter and sort options are available in the inbox.
A user can filter by -> Treatment Process, Output Type, Date Range, Workflow Status.
A user can sort by date (latest first/latest last).
Use the pqm-service.
URL for inbox "/pqm-service/v1/_update".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_update" endpoint for a plant operator user role, that is:
Use the inbox-v2 API.
URL for inbox "/inbox/v2/_search".
Sample request object:
Role action mapping is done for the "/inbox/v2/_search" endpoint for a plant operator user role, that is:
The above diagram illustrates the integration between each actor. A brief description of each role is provided below:
Role
Description
Action
System Administrator
The user can define boundaries, create roles and users, define properties,, upload lisy of localities and slums, as well as create localisation.
Define boundaries.
Create roles and map to actions.
Create users: Map to the role and boundary (boundary mapping to be confirmed).
Define property types and sub-types.
Define pricing.
Upload the list of localities and pin codes.
Upload the list of slums.
Define the minimum advance pricing to be collected.
Create localisation.
Citizen
A citizen can request for a desludging operation online. The user can check the status of the application online, make the payment for the service online, and post desludging, they can rate the quality of the service online.
Request for desludging services.
View the acknowledgement receipt.
View the payment receipts.
Track the status of desludging requests.
View the history of past desludging services.
Make online payments.
ULB Employee (Can be assigned roles as creator, collector, editor, report viewer, dashboard viewer or admin)
A ULB official will act as a regulatory and management authority for the entire desludging process. He/she can receive the request from a citizen online or can create a request on behalf of the citizen online. When the request is received, the user can assign a desludging operator for a request. The official can also update the status of the request on behalf of the DSO after the service is completed at the site, and view the relevant reports.
Add, update, and disable vendors.
Add, update, and disable drivers.
Add, update, and disable vehicles.
Map vendors and drivers.
Map vehicles and drivers.
Create desludging service requests on behalf of citizens.
Accept, reject, or update desludging service requests
Assign vendors to desludging services.
Collect service fees.
View dashboards and reports for a specific ULB.
Transportation Vendors
This user can receive the requests assigned by a ULB official, and update the status of the transaction after the service is completed.
Accept/reject desludging requests.
Assign vehicles to requests.
Update the number of trips.
Map the completion of requests.
Treatment Plant Operator
This user can view the current demand, that is, the list of planned desludging requests available in the system. He/she can update the vehicle log which enters the FSTP/STP every day.
Record incoming vehicles against requests.
Record incoming vehicles without associated service requests.
State Administrator
The user can view dashbaords and reports. The user can also filter dasboards and reports for a specific urban local body and by time.
View dashboards and reports for states.
Filter dashboards and reports by time, and for a specific ULB.
ULB admins have an option to create a test. This is an adhoc test which does not have any workflow involved. By default, it will be in the submitted state when created.
From the home screen, click on the Add Test Result link.
The user is redirected to Create Test screen. This page has two form cards. One is for entering Plant Name, Treatment Process, Stage and output type. The other card has a list of benchmarks according to the selection of the above form.
Note: After filling the first form, only the list of benchmarks will show up.
If any quality criteria is not found for the selection of parameters, an error is shown and user has to select another criteria.
After filling the forms, click on submit to create a test.
After a successful creation, the system automatically redirects to the view test details screen of the newly-created test.
Use pqm-service.
URL for inbox "/pqm-service/v1/_create".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_create" and "/pqm-service/v1/search" endpoint for a ULB admin user role, that is:
Water-Sanitation is an open-source web and mobile-enabled platform designed to digitise operations in the waste management value chain, from collection to treatment. It provides the ability to drive coordination across multiple independent and disconnected stakeholders, ensuring a continued chain of custody of waste throughout.
According to a United Nations (UN) report, only 54% of the world population has access to safe sanitation. We believe that at the heart of the problems in sanitation are ineffective systems that fail to deliver. Hence, systems must be progressively reformed. To move habitats towards zero untreated waste, we will leverage the capabilities built by the Digital Infrastructure for Governance, Impact & Transformation (DIGIT), and ensure the traceability of waste by enabling the ecosystem with the following features:
Chain of custody: We will ensure a seamless and traceable chain of custody for waste. This will enable stakeholders to track waste from its source to its final destination, ensuring accountability and transparency in the waste management process.
Actionable data: Our system will provide actionable data on waste management operations, which will enable stakeholders to make informed decisions. This data will be used to optimise waste collection and treatment processes, identify areas for improvement, and drive evidence-based decision-making.
Code for innovation: We will foster innovation by providing a digital platform that encourages collaboration among stakeholders. Our system will facilitate the sharing of ideas, best practices, and innovative solutions for sanitation challenges, driving continuous improvement in the waste management ecosystem.
Current digital efforts across geographies do not take a “whole of system view” and do not solve the cost of coordination and duplication issues. Such siloed, solution-centric approaches and tools create a new set of problems and inefficiencies for countries:
Higher costs and time: This is incurred on creating or procuring and maintaining these systems, including the onboarding cost of the same actors in each programme.
Data exists in multiple systems: They are not interoperable, leading to duplication, inconsistencies, poor adoption by on-ground workers, and sub-optimal decision-making.
Limited reusability and innovation: Data and capabilities are intertwined and ‘locked,’ making it extremely hard for the wider ecosystem to innovate and build upon.
Sub-scale: The tools are not able to scale for the national population and across waste streams.
Water-Sanitation solutions are built on the principles of societal platforms, envisioning a space where sanitation is supported by shared resources, curated knowledge, and evolving solutions that address the needs of the community. We recognise that the challenges of sanitation are systemic and require the collective efforts of all stakeholders to be effectively addressed. Drawing from the insights gained from our urban mission, we embrace the triple helix model, which emphasises partnerships among different stakeholders, including civil society (samaaj), government (sarkaar), and industry/market (bazaar), to generate innovation through synergistic collaboration. Leveraging our experience in building large-scale public digital infrastructure, we are well-positioned to create the foundation for this ecosystem and drive progress in solving the most pressing sanitation issues. We believe that by fostering cooperation and collaboration among all stakeholders, we can create sustainable solutions that meet the needs of communities and contribute to the transformation of the sanitation landscape.
While sanitation requirements and solutions may vary among local governments, there are commonalities in the value chain of sanitation waste streams, such as faecal sludge management, solid waste management, plastic waste management, etc. These value chains typically involve steps such as generation, containment, collection, transport, treatment, and disposal/reuse. These similarities provide an opportunity to abstract and digitise various components of the service value chain, with the potential to encode standards and enable data-driven visibility into sanitation services.
The Water-Sanitation solution is specifically designed to allow for the contextualisation and reuse of components across different waste streams and geographies. By incorporating standards into the platform and leveraging data registries and reusable building blocks in the technology stack, applications can be developed more efficiently and quickly at the solution layer, resulting in lower costs and faster implementation. This approach enables flexibility and scalability in addressing diverse sanitation needs, while also promoting interoperability and consistency in the digital solutions deployed. By leveraging the Water-Sanitation solutions, stakeholders can build innovative applications tailored to local contexts, while adhering to standardised components and data structures, leading to more effective and sustainable sanitation services.
Following is a glimpse of how this would work:
The above image illustrates the core infrastructure services, and the enabling services that are built/configured for a Faecal Sludge Management (FSM) solution with the following functionality:
Allowing citizens to request septic tank desludging services
Scheduling desludging services for a certain set of property types/localities, etc.
Automated or manual assignment of vendors to perform requests
Tracking sludge from collection to disposal at a treatment plant using the Internet of Things (IoT)
Notifications to stakeholders at each point in the workflow
Dashboards and reports
Now, consider that instead of FSM, a solution needs to be built for Solid Waste Management:
The same set of infrastructure and enabling services could be used to configure the following functionalities:
Scheduling the collection of waste based on different categories
Automated or manual assignment of vendors to perform requests
Tracking adherence to the schedule
Tracking waste movement from pickup to disposal at a treatment facility
Notifications to stakeholders at each point in the workflow
Dashboards and reports
Further, only an additional service for segregation monitoring would have to be built.
To illustrate this further, imagine building a solution for sanitation worker welfare:
The same set of services can be used here as well, with the addition of a few components. The Water-Sanitation platform is built leveraging the DIGIT Core Services, which are customised into the following key building blocks:
Service Request Management
Define pricing
Record service requests
Assign and manage service requests
Provide subsidies
Calculate service fees
Track status
Collect feedback
Transport Management
Schedule pickup
Assign vehicles and drivers
Track status
Billing and Payments
Generate demand
Generate receipts
Online payment gateway
Notifications
SMS
In app
Service Delivery Monitoring
Dashboards
Reports
The Desludging Operators or DSOs are responsible for initiating and completing action on citizen requests for desludging services. The requests are routed to the respective DSOs by the urban local body (ULB) officials. The DSOs update the application status once the services are delivered and the payments are collected.
DSOs can do the following:
Assign vehicles for desludging services
Decline service requests
Complete service requests
DSOs operators are provided with credentials to log in to the system.
On this page, the following actions can be performed:
Enter username and password
Select city for login
Reset password by clicking on the “Forgot Password” link
On clicking continue, DSOs are redirected to the FSM homepage.
On this page, the following actions can be performed in the FSM card:
Click on Inbox to view assigned requests
Search for historical requests serviced
Change language
Edit profile details by clicking on the user icon on top right hand corner
Logout by clicking on the user icon on the top right hand corner
Requests assigned to the DSO can be viewed by clicking on the Inbox link in the FSM homepage.
Requests pending for acceptance will be viewable in the status: Pending for DSO Approval.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”
Clear search by clicking on “Clear Search’”
View and update applications by clicking on an application number
Filter applications by locacilty using the ‘Locality’ dropdown
Filter applications by ‘Status’
Search for past applications by using “Search Application”
Sort applications by Application date.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details
Click on the “Take Action” button
The take action button has the following options:
Assign Vehicle
Decline Request
A request can be approved by assigning a vehicle. Clicking on “Assign Vehicle’’ will display the following pop-up:
The following actions can be performed:
Update Vehicle Registration No.
Close pop-up by clicking on the Close button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
Confirm decline request by clicking on the “Assign Vehicle” button
A snack bar will confirm assignment of vehicle and the application timeline will be updated to DSO in Progress.
Once DSO is in progress, the number of trips can be updated.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”
Clear search by clicking on “Clear Search”
View and update applications by clicking on an application number
Filter applications by ‘Locacilty’ using the locality dropdown
Filter applications by ‘Status’
Search for past applications by using “Search Application”
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details
Click on the ‘Take Action’ button
The take action button has the following options:
Complete Request
Update/Schedule Trips
On clicking on Update/Schedule trips, the following pop up is displayed:
The following actions can be performed:
Increase the number of trips by clicking on the + button
Decrease the number of trips by clicking on the - button
Close pop-up by clicking on the Close button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
Confirm update/schedule trips by clicking on the “Update/schedule” button
A snack bar will confirm that the number of trips have been updated
Once the service request has been completed and all pending payments have been collected, the same has to be confirmed in the system. This can be done by selecting the “Complete Request” button in the “Take Action” button. On clicking on Complete Request, the following pop up is displayed:
The following actions can be performed:
Confirm/Update service date
Confirm/Update Volume of waste collected
Confirm/Update pit details
Upload pit photo
Close pop-up by clicking on the Close button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
Confirm details by clicking on the ‘Completed’’ button
A snack bar will confirm that request has been completed and the status will be updated to “Waiting for Disposal”.
DSOs can choose to decline unserviceable service requests. Applications can be rejected by a DSO in the “Pending for DSO Approval” stage.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”
Clear search by clicking on “Clear Search”
View and update applications by clicking on an application number
Filter applications by ‘Locacilty’ using the locality dropdown
Filter applications by ‘Status’
Search for past applications by using “Search Application”
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details
Click on the “Take Action” button
The take action button has the following options:
Assign Vehicle
Decline Request
Clicking on “Decline Request’’ will display the following pop-up:
The following actions can be performed:
Reason for declining
Enter comments
Close pop-up by clicking on the Close button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
Confirm decline Request by clicking on the “Decline Request” button
A snack bar will confirm decline and the application timeline will be updated to DSO Rejected.
The DIGIT-Faecal Sludge Management (FSM) allows citizens to raise service requests for desludging and pay the fees for the service delivery online. For governing bodies and vendors, it makes service delivery easier and captures information end-to-end, ensuring waste pick up and its disposal at the correct treatment plant. Real-time tracking of service delivery, along with the availability of rich transactional data allow decision makers to ensure a better citizen service experience and promote a cleaner/healthier environment.
Apply for desludging services
Make payment for services
Register desludging operators
Update vehicle logs
Manage vendors, vehicles and drivers
Refer to the table below to understand the different user roles and the scope of action linked to each role. The manual provides a detailed description of how to use the system for each role.
This section guides you through the details of using the FSM module for each role. Click on the relevant role below to learn more about how to use the FSM system.
Citizen
Apply for desludging services
Make payment for services
Individuals and society groups/communities
Desludging Operators (DSO)
Take action on assigned service requests
Private or government entities
Septage Treatment Plant Operator (SeTPO)
Update vehicle log
Private or government entities
Employees
Apply for desludging services on behalf of citizens
Receive payment from citizens over the counter
Send back applications
Reject applications
Assign DSOs to service requests and update the status of the service requests
ULB employees
Sanitation Worker UI Documentation
As part of FSM v1.4, sanitation worker related features/screens have been added to the FSM UI. These screens are accessible with current FSM related roles such as FSM_Admin, Creator, Editor, Collector, etc.
The following screens are available for the sanitation worker UI:
Sanitation Worker Details
From the FSM Registry Screen Admin can search for Sanitation worker and go to it's details page.
From the Sanitation Worker details page , admin can click on "Edit" action
Admin will be redirected to the edit sanitation worker page
This page contains the same form as Create Sanitation Worker . The only difference is all the fields are auto populated based on the worker that we are updating
Admin can update all the details except Sanitation Worker Id and Name
Clicking on Submit will show a response screen saying Sanitation Worker details updated successfully
We are hitting Individual Update endpoint "/individual/v1/_update" to update the details of a Sanitation worker
Refer the curl below:
If during update, vendor details are changed then along with individual update we are calling vendor update "/vendor/v1/_update"
Refer the curl below
Role action mapping is done for the above 2 endpoints for "FSM_ADMIN" role
This section includes the following:
Check left padding for all forms
Improvement
1
Done
Y
Border colour of the view test screen
Improvement
0.5
Done
Y
Result summary bold in view test screen
Improvement
0.1
Done
Y
Back button and help label spacing in the help screen
Improvement
0.1
Done
Y
Powered by DIGIT in sidebar at the bottom
Improvement
0.1
Done
Y
Truck icon change
Improvement
0.5
Done
Y
Role details: Remove colon, and values should not be bold
Improvement
0.1
Done
Y
Pending tasks text color change
Improvement
0.1
Done
Y
Left and right spacing of the notification cards to be equal
Improvement
0.1
Done
Y
The font size for notification subheads to be checked
Improvement
0.1
Done
Y
Empty state for notifications should be according to Figma
Improvement
0.5
Done
Y
Once notifications are cleared for the user, it should not appear when the page is refreshed
Improvement
Backend changes required. Will be done in patch.
View past test results to be left aligned to the icon
Improvement
0.1
Done
Y
On refreshing the page, the input filtered view should remain intact
Improvement
Done
Y
All cards and table to have 4px radius
Improvement
0.5
Done
Y
Spacing between the quality testing icon and text
Improvement
0.1
Done
Y
Improvement
0.1
Done
Y
In some test results, the timeline connecting line is missing
Improvement
1
Done
Y
Notifications cards to be responsive
Improvement
1
Done
Y
Submit CTA does not work
Improvement
1
Done
Y
No toast validations on submitting
Improvement
0.5
Done
Y
The placement of the logout popup should be higher
Improvement
0.5
Done
Y
Test date localisation missing
Improvement
0.1
Done
Y
Background image to be changed
Improvement
0.5
In plants dropdown, the hover states should extend to the edges
Improvement
0.5
Done
Y
Inbox rows are not actionable
Improvement
1
Done
Y
Alerts - heading alignment
Improvement
0.5
Done
Y
Inner padding of
cards
Improvement
0.5
Done
Y
Share dropdown should close on clicking outside
Improvement
0.5
Done
Y
Size and alignment of buttons to be fixed
Improvement
1
Done
Y
Localisation missing for CTAs
Improvement
0.5
Done
Y
Once filters are applied, the filters should be retained while re-opening filters as well
Enhancement
Need enhancement in core components. Will be done in patch.
TODO
Need enhancement in core components.
Sort filters should be retained
Enhancement
Need enhancement in core components. Will be done in patch.
TODO
Need enhancement in core components.
On sorting the date column, the filters should also change
Enhancement
Need enhancement in core components. Will be done in patch.
TODO
Need enhancement in core components.
Filter card on the side should be sort
Enhancement
Need enhancement in core components. Will be done in patch.
TODO
Need enhancement in core components.
The user interface (UI) design is broken up into the following sections:
Login
Raise a Desludging Request
View Applications
Accept Applications
Payments
Assign Desludging Operator
Assign Vehicle
Complete Request
Rate Services
Manage Vendor, Driver and Vehicle Details
Find the mock-ups below:
When the user opens the application, it first asks them to select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.
Users are redirected to this screen once they select the preferred language in the previous screen. The city field is a list with radio buttons based on the tenants that are configured in the instance, and the selected radio button is highlighted in orange. The selection of the city will determine the urban local body (ULB) where the application request is raised.
Once the user selects a location and clicks on continue, the user is redirected to the following screen:
The mobile number entered in the application is for all communication purposes. All SMS communication will be sent to the user on the entered number. A user can also access the history of all past and active transactions using this number. The next button will only be deactivated and will be highlighted once the user has entered a valid number. An error message will be displayed if the number is not 10 digits, or alphabets/special characters are entered.
On clicking ‘Next’, an OTP will be sent to the user, and the user will be redirected to the following screen:
The screen will prompt the user to enter the OTP sent to the registered mobile number. A counter will be displayed on the screen with a countdown on the number of seconds pending post which the OTP has be re-quested. After 30 seconds, a resend button will be visible to the user. The next button will only be deactivated and will be highlighted once the user has entered an OTP. On clicking ‘Next’, the user will be redirected to the FSM landing page. On entering the incorrect OTP, the user will see an error message that says “Invalid OTP”.
When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.
The user will be provided with a unique system-generated ID and password manually for login.
For an incorrect password, it should show the message “incorrect password” below the password field. If an existing user does not remember his/her password, they must click on “Forgot Password”. This will open a pop-up asking the user to contact the administrator. The ‘OK’ button will collapse the pop-up.
The city field is a dropdown based on the tenets created in the instance. Once all fields are filled, the user can click on ‘Continue’. If any field is not filled, the user will be prompted to fill all fields.
A landing page is available to a citizen on login.
The citizen can apply for desludging requests by clicking on “Apply for Emptying Septic Tank/Pit”. This will redirect the user to the service request page.
The user is prompted to enter the “No. of Trips” and the “Vehicle Capacity”. If the user knows the details, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
Once the user clicks on ‘Next’, the user is redirected to “Choose Property Type”. A workflow on the top will show the user in which step of the request form he/she is. The radio button for the selected property type will be highlighted with orange. The next button will only be deactivated and will be highlighted once the user has selected a property type.
Based on the property type selected, an information box is displayed to the user informing them about the approximate cost of desludging. On clicking next, the user is prompted to “Choose Property Sub-Type”:
The radio button for the selected property type will be highlighted in orange. The next button will only be deactivated and will be highlighted once the user has selected a property type.
The user is prompted to select the pincode for the property location using the map or search a location using the search bar. The user can also drag the point on the map to the selected location. If the user knows the pin location, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”. If the pin location is not selected, the user is redirected to enter the pincode.
The user can enter a 7-digit pincode. If any alphabets/special characters are entered, the user will be prompted with an invalid pincode error. If the user knows the pincode, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
After this, the user will be redirected to the property address page and he/she will have to select a city and a mohalla. Both of these are dropdowns. The city dropdown is populated based on the tenants created in the system. The list of localities/mohallas will be from the MDMS. The next button will be deactivated and will be highlighted once the user has filled in the details. Once a property address is provided, the user is asked to select whether the property is a slum.
The radio button for the selected option will be highlighted in orange. The next button will only be deactivated and will be highlighted once the user has selected an option. If yes is selected, the user will be redirected to enter the slum name.
The slum name can be selected from a dropdown. The next button will only be deactivated and will be highlighted once the user has selected a slum name. On clicking ‘Next’, the user is redirected to the property address screen.
After this, the user will be redirected to the property address page where he/she will have to enter the “Street Name” and “Door/House No”. The ‘Next’ button will be deactivated and will be highlighted once the user has filled in the details. Once a property address is provided, the user is asked to provide a landmark.
The landmark can be entered by typing in the text box. If the user knows the landmark, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
The user will be prompted to “Choose Pit type”. The radio button for the selected option will be highlighted in orange. If the user knows the pit type, he/she can enter the details and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
The user will be prompted to “Upload Pit Photos” by clicking on the camera icon. Once the button is clicked on, the user can choose the camera or select a photo from the gallery. If the user has the photo, he/she can upload the photo and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
The user will be asked to select gender. The radio button for the selected option will be highlighted in orange. If the user wants to declare their gender, the user can select from Male/Female/Transgender/Others, and click on ‘Next’. If not, the user also has the option to “Skip and Continue”.
The user is redirected to the “Payment Details” page. If an advance has been configured in the backend by the ULB, the advance amount is displayed on the screen. The user can enter the advance amount. If an amount below the advance amount is entered, then an error is displayed. To confirm, the user can click on ‘Next’. The user is then prompted to “Check the Answers”.
A change option is displayed beside each answer. In case the user wants to edit any details, the user can click on the change button and the user will be redirected to that part of the workflow. If not, the user can click on ‘Submit’.
The user is displayed a confirmation message for application submission along with an application number. A download button can be used to download the application receipt as displayed below. The user can also go back home by clicking on the “Go back to home page” button.
A landing page is available to the ULB employee on login.
The employee can apply for desludging requests on behalf of the citizen by clicking on “New Desludging Request”. This will redirect the user to a form.
The user is prompted to enter the mandatory and non mandatory fields. The “Amount per Trip”, “Total Amount” and “Advance Collection” fields are empty, and will be autopopulated once the “Property Type, “Property Sub-type”, “No. of Trips” and “Vehicle Capacity” are filled.
The following validations will be present in the page:
Mobile number to be 10 digits and cannot be alphanumeric or contain special characters.
Advance amount edited cannot be greater than total amount or lesser than minimum amount.
The submit button is greyed out and will only show as active when all mandatory fields are filled.
Once the user submits the form, the user is redirected to a confirmation page. The confirmation page will display a unique application number. A download option to download the application receipts displayed below is also available. The user can go back to the landing page using the “Go Back to Home” button.
A citizen can view his/her applications by redirecting to “My Applications” from their landing page.
The “My Applications” page lists down all the ongoing applications and will display the Application No., Service Category and Application Status. A view button will be made available along with each application. Once the user clicks on ‘View’, they are redirected to the following page:
The user can view all details of the application on the screen. There is an option to download the application receipt and payment receipts using the Download button.
The application timeline below the application shows the history of the application along with details of the date when the workflow step was completed. If the application is in the “Pending for Payment”, the same will be displayed and a corresponding link will be displayed in the “Application Timeline”.
Similarly, if the application is in the “Pending Citizen Feedback” stage, the same will be displayed and a corresponding link will be displayed in the “Application Timeline”.
To view the applications, an employee can navigate to the inbox from the Landing page. The inbox shows a list of all active applications along with their SLAs.
The user can search for an active application using “Application No.” and “Mobile No.” and click on search. This will return the application with the corresponding “Application Number” or the list of applications with the corresponding mobile number. The user can further filter applications based on the criteria on the left hand side, that is, Locality or Status.
To view Past Applications, the user can navigate to Search Applications. Here, users can search for both Active and past applications with the following fields: Application Number, Mobile Number, Status and Locality. On clicking on an application number, the user is redirected to the Application details page.
The user can view all details of the application on the screen. The application timeline below the application shows the history of the application along with details of the date when the workflow step was completed.
The ULB employee can accept and update application details when a citizen has raised a request or rejected it.
This can be done by clicking on the “Update Application” button. Details such as locality, number of trips and capacity will be displayed. Clicking on “Update application” will update the status of the application as “Pending for Payment”.
Clicking on “Reject Application’ will reject the application and the user will be prompted to select a reason for rejection and click on submit. Once the application is updated, it will move to pending for payment status if advance payment is applicable.
If the application is on the “Payment Pending” stage, the user will have the option to make a payment from the “View Applications” page.
The user can make a payment by clicking on the “Make Payment” button. The user is redirected to the bill details page which displays the total, advance, and due amount.
Here, the amount due is prefilled and displayed to the user. If the user is aligned, they can proceed by clicking on “Proceed to Pay”.
All payment methods available and configured will be available here as radio buttons. The selected radio button will be filled in orange to display the selection. The user also receives an intimation that they will be redirected to a third-party site. On completion of the payment, the user is redirected to a payment confirmation page. A ‘Print’ receipt option is available to download the payment receipt.
Desludging applications pending payment is accessible in the inbox of the user assigned the collector role. The status of the application is reflected in the status column.
By clicking on the application number, the user can view application details.
The user will be able to view details of the application along with details of the Amount Per Trip, Total Amount, and amount to be collected. The application details will also display the status as “Pending for Payment”. The user can proceed to collect payment by clicking on the “Collect Payment” button and the user will be redirected to the “Collect Payment” page.
The user will see information about the amount to be collected and further will be required to fill the following information:
Payer Name
Payer Phone number
Additionally, the user will be prompted to select the payment mode using radio buttons. The selected radio button will be highlighted in orange. If the user is getting a physical receipt, then the receipt number can be recorded under the Gen/G8 receipt details.
On clicking the submit button, the user is redirected to the payment confirmation screen. The user can download the payment receipt using the ‘Print’ receipt button or go back to the landing page using the “Take Action” button.
Once the payment (if any) is collected, the ULB employee can assign a desludging operator. Applications where DSO needs to be assigned will be shown as “Pending for DSO Assignment” in the inbox.
By clicking on the application number, the user can view application details.
The user can start the process of assigning a DSO by clicking on the “Assign DSO” button. This will display the following pop-up to the user:
The user can select the DSO via a dropdown. The list of DSOs is populated by matching the vehicle capacity requested to the DSOs with vehicles with the required capacity. An expected date of completion is to be selected. Once all fields are filled, the user can assign the selected DSO. An error message will be displayed if a field is left blank. The user can also go back to the application details page by clicking on the ‘Close’ button.
Once the user clicks on ‘Assign’, the status in the workflow timeline will reflect “Pending for DSO Approval”. For any reason, if the DSO is unavailable to service the request, the request can be reassigned to another DSO. This can be done by clicking on the “Take Action” button and clicking on reassign DSO.
The same fields need to be filled as that for “Assign DSO”. However, the user is required to select a reason for rejection from a list preconfigured in the backend. An error message will be displayed if a field is left blank. On re-assigning a DSO, the user is displayed a snack bar with confirmation.
The user can also go back to the application details page by clicking on the ‘Close’ button.
A vehicle can be assigned by both the ULB and the DSO (or basis roles configured) when the application is in the “Pending for DSO Approval” stage. By clicking on the application number, the user can view application details.
The user can start the process of assigning a vehicle by clicking on the “Assign Vehicle” button. This will display the following pop-up to the user.
The user can select the “Vehicle no.” via a dropdown. The list of vehicles is populated by matching the vehicle capacity requested with the required capacity. The vehicle capacity and number of trips are displayed on the pop-up. An error message will be displayed if the vehicle registration number field is left blank. The user can also go back to the application details page by clicking on the ‘Close’ button.
Once the user clicks on ‘Assign”, the status in the Workflow timeline will reflect the “DSO InProgress” stage.
At any point during service, the DSO or ULB can update the number of trips. This can be done by clicking on the “Take Action” button and selecting the “Update/Schedule Trips” option.
The user can increase or decrease the number of trips by clicking on the plus or minus sign. The number of trips will increase or decrease and be displayed based on the user's action. The user can confirm the updated number of trips by clicking on the Update/Schedule button. The user can also go back to the application details page by clicking on the ‘Close’ button.
A snack bar will confirm the updated number of trips.
Once the service request has been completed and all pending payments have been collected, the same has to be confirmed in the system. This can be done by selecting the “Complete Request” button in the “Take Action” button. On clicking on “Complete Request”, the following pop-up is displayed:
The user is required to fill in the following details:
Date of Service (selected from a calendar)
Volume of Waste collected
Additionally, the user can add optional details such as Pit Type and Pit Dimensions and upload a photo of the Pit. An error message will be displayed if all mandatory fields are not filled.
The user can confirm the completion by clicking on the ‘Completed’ button. The user can also go back to the application details page by clicking on the ‘Close’ button.
if the application is on the Payment Pending stage, the user will have the option to make a payment from the “View Applications” page.
On clicking on ‘View’, the user is redirected to the application details page. The workflow timeline will reflect that the application is pending citizen feedback and a clickable “Rate Us” option is displayed to the user.
Once the user clicks on rate us, the user will be redirected to the following page:
The user can provide feedback by selecting one out of 5 stars and selecting safety gears used via a multi-select box. If either of these fields is not filled, the user is displayed an error when clicking on the submit button. Additional comments may be added by the user.
On clicking the submit button, the user will be redirected to a confirmation page. The user can use the ‘Download’ button to download any payment or acknowledgement receipts from the users.
The FSM Registry allows for the following actions from the frontend for a particular urban local body (ULB):
Add new driver, vehicle, vendor
Edit driver, vehicle, vendor details
Enable and disable drivers, vehicles and vendors
Tag driver and vehicle to vendors.
The user can access the ULB registry by clicking on the FSM Registry link in the landing page.
The landing page of the FSM registry is defaulted to show the list of vendors in the system. A particular vendor can be searched for by entering the Vendor name in the search bar. Search can be cleared by clicking on the “Clear Search” button.
The user can view the number of associated total and active vehicles and drivers against a vendor. The user can view the details of the tagged vehicles and drivers by clicking on the number. The user can enable/disable the vendor using the toggle.
A new vendor, vehicle or driver can be added by clicking on the plus button on the top right of the page.
On clicking the plus button, the user will be prompted to select whether he/she/it/they/them want to add a Vendor, Driver or Vehicle. To add a new Vendor, the user can click on Vendor and the user will be redirected to the “Add Vendor” page.
A new vendor can be added by entering details such as Vendor Name, personal details, including Gender, Date of Birth, Email and Phone number and Address details such as Door No, Pincode and landmark. Each vendor is created with a unique mobile number and hence, an error message will be displayed if the mobile number has been used to create other vendors. An error message will be displayed if all mandatory fields are not filled.
The user can confirm the completion by clicking on the ‘Submit’ button. The user can also go back to the FSM Registry landing page by using the breadcrumbs.
Once the user submits an application, a snack bar will confirm the successful addition of a vendor and details of the added vendor will be displayed in the vendor list.
Vendor details can be viewed by clicking on the vendor name. This will display details such as name, number and address. Details of vehicles and drivers tagged to the vendor will be visible on the screen. The user can go back to the FSM Registry landing page by using the breadcrumbs.
Vendor details can be edited by clicking on the “Take Action" button and selecting edit. Add or edit information and click on “Submit Application”. The changes will reflect on the vendor details page.
A vendor can be deleted by clicking on the “Take Action” button and selecting delete.
A pop-up will be displayed for confirmation. The user can confirm delete by clicking on ‘Delete’ or go back to the vendor details by clicking on ‘Cancel’.
On clicking delete, the user will be redirected to the FSM registry landing page and a snack bar will be displayed confirming that the vendor has been deleted.
Multiple vehicles can be tagged to a vendor. It is necessary that a vehicle exists in the system before it can be tagged. A vehicle can be tagged to a vendor by clicking on the “Add Vehicle” button in the vendor details page.
A pop-up will be displayed with a dropdown to select a vehicle. Only vehicles that are not tagged to any vendor are to be displayed. The user can select the vehicle number and click on submit or go back to the vendor details page by clicking on close.
The added vehicle details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vehicle details.
Multiple drivers can be tagged to a vendor. It is necessary that a driver exists in the system before it can be tagged. A driver can be tagged to a vendor by clicking on the “Add Driver” button in the vendor details page.
A pop-up will be displayed with a dropdown to select a driver. Only drivers that are not tagged to any vendor will be displayed. The user can select the driver name and click on submit or go back to the vendor details page by clicking on close.
The added driver details will be displayed. The driver can be untagged from the vendor by clicking on the delete button against the driver details.
To view the list of Vehicles, the user can navigate to the Vehicle tab from the FSM Registry landing page.
The user can view the creation date, tagged vendor and status for a vehicle in this page. A particular vehicle can be searched for by entering the vehicle number in the search bar. Search can be cleared by clicking on “Clear Search”. Vehicles can be sorted by creation date, by clicking on the arrow beside the column heading. The user can enable/disable the vehicle using the toggle.
To add a new vehicle, the user can click on vehicle near the plus button and the user will be redirected to the “Add Vehicle” page.
A new vehicle can be added by entering details such as Vehicle Registration number, Model, Type, Capacity, details of pollution certificate, insurance and road tax. Each vehicle is created with a unique registration number and hence, an error message will be displayed if the registration number has been used to create other vehicles. An error message will be displayed if all mandatory fields are not filled.
The user can confirm the completion by clicking on the ‘Submit’ Button. The user can also go back to the FSM Registry landing page by using the breadcrumbs. Once the user submits an application, a snack bar will confirm the successful addition of a vehicle.
Details of the added vehicle will be displayed in the vehicle list.
Vehicle details can be viewed by clicking on the vehicle name. This will display details such as the registration number, vehicle type, make, model, capacity etc. The vendor that the vehicle is tagged to and whether it is active is also displayed in the details.
Vehicle details can be edited by clicking on the “Take Action” button and selecting edit. Add or edit information and click on submit application. The changes will reflect in the vehicle details page.
A vehicle can be deleted by clicking on the “Take Action” button and selecting delete.
A pop-up will be displayed for confirmation. The user can click on delete to confirm to cancel to go back to vehicle details. The vehicle will be deleted.
Apart from tagging a vehicle to a vendor from the vendor details page, tagging can also be done from the vehicle details page by clicking on the add vendor button. The tagging can be edited by clicking on the edit icon beside Vendor name, in case a vendor is already added.
A pop-up will be displayed with a dropdown to select a vendor. The user can select the vendor and click on submit or go back to the vehicle details page by clicking on ‘Cancel’.
The added vendor details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vendor name. The edit (pencil) button allows you to change the vendor tagging.
To view the list of drivers, the user can navigate to the drivers tab.
The user can view the creation date, tagged vendor, and status for a driver in this page. A particular driver can be searched for by entering the driver name in the search bar. Search can be cleared by clicking on “Clear Search”.
Drivers can be sorted by creation date, by clicking on the arrow beside the column heading. The user can enable/disable the vehicle using the toggle. The user can change the tagging of the Vendor by using the drop down in the “Vendor Name” column.
To add a new driver, the user can click on Driver from the plus button and the user will be redirected to the “Add Driver” page.
A new driver can be added by entering details such as Driver Name, and License number. Each vehicle is created with a unique license number and hence, an error message will be displayed if the license number has been used to create other vehicles. An error message will be displayed if all mandatory fields are not filled.
The user can confirm the completion by clicking on the ‘Submit’ button. The user can also go back to the FSM Registry landing page by using the breadcrumbs. Once the user submits an application, a snack bar will confirm the successful addition of a driver. Details of the added driver will be displayed in the driver list.
Driver details can be viewed by clicking on the driver name. This will display details such as the Name, phone number and license number. The vendor that the driver is tagged to is also displayed in the details.
Driver details can be edited by clicking on the “Take Action” button and selecting edit. The user can add or edit information and click on submit application. The changes will reflect in the driver details page.
A driver can be deleted by clicking on the “Take Action” button and selecting delete.
A pop-up will be displayed for confirmation. The user can click on delete to confirm or view driver details by clicking on cancel. The vehicle will be deleted.
Method 1: Apart from tagging a driver to a vendor from the vendor details page, tagging can also be done from the driver details page by clicking on the add new vendor button.
A pop-up will be displayed with a dropdown to select a vendor. The user can select the vendor and click on submit or go back to the driver details page by clicking on ‘Cancel’.
The added vendor details will be displayed. The vehicle can be untagged from the vendor by clicking on the delete button against the vendor name. The edit (pencil) button allows you to change the vendor tagging.
The FSM Registry allows for the following actions from the frontend for a particular urban local body (ULB):
Add a new sanitation worker, vehicle, vendor.
Edit sanitation worker, vehicle, vendor details.
Enable and disable sanitation workers, vehicles and vendors.
Tag a sanitation worker and vehicle to vendors.
Login as a ULB admin and navigate to the FSM registry by clicking on it.
The following actions can be performed:
View a list of all vendors in the system along with the details of tagged vehicles and sanitation workers.
Search for a vendor using the search box.
Clear search by using the "Clear Search" button.
Enable/disable a vendor by using the toggle.
Sort vendors by creation date.
View total vehicles tagged to the vendor by clicking on the value to “Total Vehicles”.
View active vehicles tagged to the vendor by clicking on the value to “Total Vehicles”.
View total sanitation workers tagged to the vendor by clicking on the value to “Total sanitation workers”.
View active sanitation workers tagged to the vendor by clicking on the value to “Total sanitation workers”.
Add a new vendor, sanitation worker or vehicle by clicking on the ‘Add’ button.
Vendor details can be viewed by clicking on the vendor name in the FSM Registry homepage.
The following actions can be performed:
View vendor details along with tagged vehicles and sanitation workers.
Tag a new vehicle to the vendor by clicking on the “Add Vehicle” button.
Remove a tagged vehicle by clicking on ‘Delete’ on the top right of the vehicle card.
Edit vehicle details by clicking on the ‘Edit’ symbol on the top right of the vehicle card.
Tag a new sanitation worker to the Vendor by clicking on the “Add Sanitation Worker” button.
Remove a tagged sanitation worker by clicking on the ‘Delete’ symbol on the top right of vehicle card.
Edit sanitation worker details by clicking on the ‘Edit’ symbol on the top right of the vehicle card.
The details of a vendor can be edited or a vendor deleted by clicking on the “Take Action” button.
Clicking on the ‘Edit’ button as part of the “Take Action” button will redirect the user to the “Edit Vendor” details page.
The following actions can be performed:
Edit vendor details.
Submit application.
The user will be redirected to the list of vendors, and a snack bar will confirm edit.
A vendor can be deleted by clicking on the “Take Action” button and selecting delete. A pop-up will appear on the screen.
The following actions can be performed:
Confirm delete.
Close pop-up by clicking on the 'Close' button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
The user will be redirected to the list of vendors, and a snack bar will confirm delete.
Multiple vehicles can be tagged to a vendor. It is necessary that a vehicle exists in the system before it can be tagged. A vehicle can be tagged to a vendor by clicking on the “Add Vehicle” button in the vendor details page.
The following actions can be performed:
View vendor details along with tagged vehicles and sanitation workers.
Tag a new vehicle to the vendor by clicking on the “Add Vehicle” button.
Remove a tagged vehicle by clicking on the ‘Delete’ symbol on the top right of vehicle card.
Edit vehicle details by clicking on the ‘Edit’ symbol on the top right of the vehicle card.
Tag a new sanitation worker to the vendor by clicking on the “Add sanitation worker” button.
Remove a tagged sanitation worker by clicking on the ‘Delete’ symbol on the top right of vehicle card.
Edit sanitation worker details by clicking on the ‘Edit’ symbol on the top right of the vehicle card.
The details of a vendor can be edited or a vendor deleted by clicking on the “Take Action” button.
Clicking on “Add Vehicle” will display a pop-up.
Only vehicles that are not tagged to any vendor will be displayed.
The following actions can be performed:
Select vehicle from the dropdown.
Click on 'Submit' to confirm.
Close pop-up by clicking on the Close button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
The user will be able to see the tagged vehicle in the vehicle details section. The vehicle can be untagged from the vendor by clicking on the delete button against the vehicle details.
Multiple sanitation workers can be tagged to a vendor. It is necessary that a sanitation worker exists in the system before he/she can be tagged. A sanitation worker can be tagged to a vendor by clicking on the “Add sanitation worker” button in the vendor details page.
A pop-up will be displayed with a dropdown to select a sanitation worker. Only sanitation workers that are not tagged to any vendor will be displayed.
The following actions can be performed:
Select sanitation worker from the dropdown.
Click on 'Submit' to confirm.
Close pop-up by clicking on the 'Close' button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up
The added sanitation worker details will be displayed. The sanitation worker can be untagged from the vendor by clicking on the delete button against the sanitation worker details.
A new vendor can be added by clicking on the ‘Add’ button on the FSM Registry landing page.
The following actions can be performed:
Add a new vendor by clicking on vendor.
Add a new vehicle by clicking on vehicle.
Add a new sanitation worker by clicking on sanitation worker.
On clicking on vendor, the user will be redirected to the add vendor page.
The following actions can be performed:
Enter vendor name.
Select vendor owner details such as Gender, Date of Birth, Email and Phone number. Each vendor is created with a unique mobile number and hence, an error message will be displayed if the mobile number has been used to create other vendors.
Enter address details.
Submit the application.
Once the user submits an application, a snack bar will confirm the successful addition of a vendor.
Details of the added vendor will be displayed in the vendor list.
The vehicle list can be viewed by clicking on the vehicle tab in the DSM registry.
A list of all vehicles in the system are visible along with the details of the vendor they are tagged to.
User Actions
The following actions can be performed:
View list of all vehicles in the system along with the details of tagged vendor.
Search for a vehicle using the search box.
Clear search by using the “Clear Search” button.
Enable/disable a vehicle by using the toggle.
Sort vehicles by creation date.
Add a new vendor, sanitation worker or vehicle by clicking on the ‘Add’ button.
Vehicle details can be viewed by clicking on the vehicle name.
The following actions can be performed:
View details of the vehicle.
Edit vendor tagging by clicking on the edit icon besides the vendor name.
Remove vendor tagging by clicking on the 'Delete' icon besides the vendor name.
Click on the “Take Action” button to edit or delete a vehicle.
On clicking on the “Take Action” button, the following will be displayed.
The following actions can be performed:
Click on edit to edit the vehicle.
Click on delete to delete the vehicle.
Click anywhere else on the screen to go back to vehicle details.
On clicking on the edit button, the user will be redirected to the “Edit Vehicle” page.
The following actions can be performed:
Edit vehicle details.
Submit edited details.
The user will be redirected to the vehicle details page and the edits will be reflected.
A vehicle can be deleted by clicking on the “Take Action” button and selecting delete.
The following actions can be performed:
Click on edit to edit the vehicle.
Click on delete to delete the vehicle.
Click anywhere else on the screen to go back to vehicle details.
On clicking the delete button, a pop-up will be displayed for confirmation.
The following actions can be performed:
Close pop-up by clicking on the 'Close' button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-u
Confirm deletion by clicking on the delete button.
On clicking on ‘Delete', the user will be directed to a list of vehicles and a snack bar will be displayed as confirmation.
Apart from tagging a vehicle to a vendor from the vendor details page, tagging can also be done from the vehicle details page by clicking on the add vendor button.
The following actions can be performed:
View details of the vehicle.
Tagging vehicle to a Vendor by clicking on the ‘+’ icon besides “Add New Vendor”.
A pop-up will be displayed with a dropdown to select a vendor.
The following actions can be performed:
Selection of a vendor from the dropdown.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Close pop-up by clicking on 'Cancel'.
Confirm vendor selection by clicking on 'Submit'.
On clicking submit, the added vendor details will be displayed in the vehicle details page and a snack bar will be displayed for confirmation.
Add a new vehicle by clicking on the Add button on the FSM Registry landing page and select vehicle.
The following actions can be performed:
Add a new vendor by clicking on vendor.
Add a new vehicle by clicking on vehicle.
Add a new sanitation worker by clicking on sanitation worker.
On clicking on ‘Vehicle’, the user will be redirected to the add vehicle page.
The following actions can be performed:
Enter the vehicle registration number. Each vehicle is created with a unique registration number and hence, an error message will be displayed if the registration number has been used to create other vehicles.
Select vehicle details such as model, type, capacity, details of pollution certificate, insurance and road tax.
Submit the application.
Once the user submits an application, a snack bar will confirm the successful addition of a vendor.
Details of the added vehicle will be displayed in the vehicle list.
Login as a ULB admin and navigate to the FSM Registry by clicking on it. Click on the sanitation worker tab. A list of all sanitation workers in the system is visible along with the details of the vendor they are tagged to.
The following actions can be performed:
View the list of all sanitation workers in the system along with the details of tagged vendor.
Search for a sanitation worker using the search box.
Clear search by using the “Clear Search” button.
Enable/disable a sanitation worker by using the toggle.
Sort sanitation workers by creation date.
Add a new vendor, sanitation worker or vehicle by clicking on the ‘Add’ button.
Sanitation worker details can be viewed by clicking on the sanitation worker’s ID.
The following actions can be performed:
View details of the sanitation worker.
Edit vendor tagging by clicking on the edit icon besides the vendor name.
Remove vendor tagging by clicking on the 'Delete' icon beside the vendor name.
Click on the “Take Action” button to edit or delete a sanitation worker.
sanitation worker details can be edited by clicking on the “Take Action" button and selecting edit.
The following actions can be performed:
Click on 'Edit' to edit the sanitation worker.
Click on 'Delete' to delete the sanitation worker.
Click anywhere else on the screen to go back to sanitation worker details.
On clicking the Edit button, the user will be redirected to the “Edit Sanitation Worker” page.
The following actions can be performed:
Submit edited details like professional, role details.
The user will be redirected to the sanitation worker details page and the edits will be reflected.
A sanitation worker can be deleted by clicking on the “Take Action” button and selecting 'Delete'.
The following actions can be performed:
Click on 'Edit' to edit the sanitation worker.
Click on 'Delete' to delete the sanitation worker.
Click anywhere else on the screen to go back to sanitation worker details.
On clicking the 'Delete' button, a pop-up will be displayed for confirmation.
The following actions can be performed:
Close pop-up by clicking on the 'Close' button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Confirm deletion by clicking on the 'Delete' button.
On clicking on ‘Delete’, the user will be directed to a list of vehicles and a snack bar will be displayed as confirmation.
Method 1: Apart from tagging a sanitation worker to a vendor from the vendor details page, tagging can also be done from the sanitation worker details page by clicking on the add new vendor button.
The following actions can be performed:
View details of the vehicle.
Tag sanitation worker to a vendor by clicking on the + icon besides the “Add New Vendor”.
A pop-up will be displayed with a dropdown to select a vendor.
The following actions can be performed:
Selection of a vendor from the dropdown.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Close pop-up by clicking on 'Cancel'.
Confirm vendor selection by clicking on 'Submit'.
On clicking on submit, the added vendor details will be displayed in the sanitation worker details page and a snack bar is displayed for confirmation.
Method 2: A sanitation worker can also be tagged to a vendor from the sanitation worker list page. Select a vendor from the dropdown. The sanitation worker will be tagged to the selected vendor.
Add a new sanitation worker by clicking on the 'Add' button on the FSM Registry landing page and select the sanitation worker.
The following actions can be performed:
Add a new vendor by clicking on vendor.
Add a new vehicle by clicking on vehicle.
Add a new sanitation worker by clicking on sanitation worker.
On clicking on sanitation worker, the user will be redirected to the add sanitation worker page.
The following actions can be performed:
Enter sanitation worker personal details such as Gender, Mobile number, DOB.
Enter the professional details like skills of the sanitation worker.
Click on "Add Role" to define the role for the sanitation worker if the worker is a driver or a helper or a plant operator.
Submit the application.
Once the user submits an application, a snack bar will confirm the successful addition of a vendor. Details of the added sanitation worker will be displayed in the sanitation worker list.
Urban local body (ULB) officials or employees receive the service requests, and are responsible for managing and routing these requests to specific DSOs.
Employees can:
Create desludging application on behalf of citizens.
Collect payments.
Update application/generate demand.
Assign DSO to an application.
Assign sanitation worker to an application.
Re-assign DSO to an application.
Complete or decline request.
Multiple request assignment to a single vehicle.
Manage vendor, driver, and vehicle details.
After landing on the employee URL, the user is prompted to select the language with which they would like to access the system.
On this page, the following actions can be performed:
Selection of language
After the user clicks on ‘Continue’, the page navigates to the ‘Login’ page.
ULB employees are provided with credentials to login to the system. There are role-based access for various steps in the workflow, that is, different individuals can be assigned to create an application, modify applications or manage vendor, driver and vehicle details.
On this page, the following actions can be performed:
Enter username and password.
Select city for login.
Reset password by clicking on the “Forgot Password” link.
On clicking continue, employees are redirected to the FSM home page.
The FSM home page has 3 options:
To create a new application on behalf of the citizen.
View existing pending applications.
Search for historical applications.
On this page, the following actions can be performed:
Navigate to the inbox to view pending actions.
Create a new desludging application.
Search for old applications.
Change language.
Edit profile details by clicking on the user icon on top right hand corner.
Logout by clicking on the user icon on top right hand corner.
Click on "New Desludging Application" to create a new application.
On this page, the following actions can be performed:
Enter application details (Application Channel, Applicant Name, Applicant Mobile Number and Gender).
Enter property details (Property Type and Property Subtype).
Enter location details (Pincode, City, Locality, Whether Slum and slum name, Street Name, Door/House No., Landmark).
Enter pit/septic tank details (Pit Type, Dimensions).
Enter trip details (No. of trips required and vehicle capacity).
On filling the above details, the "Amount per Trip" and "Total Amount" are calculated automatically.
The following actions can be performed:
The advance amount may be edited (above minimum advance amount and below total advance amount).
Click on "Submit Application" to submit the application, and it redirects to a confirmation page.
The following actions can be performed:
Download application acknowledgement receipt.
Go back to the homepage.
An SMS will be triggered to the citizen with an acknowledgement and payment link, if payment is due.
An application created by a citizen through the online channel has to be updated by an employee before confirmation. This application will show with the status “Application Created”.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”.
Clear search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Locality’ using the Locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details.
On clicking on the update application, application details will be viewed. Details such as locality, number of trips and capacity will be displayed.
Clicking on “Update application” will update the status of the application as “Pending for Payment”.
Desludging applications pending for payment are accessible in the inbox of the user assigned the collector role. The status of the application is reflected in the status column.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”.
Clear Search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Lolacilty’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details, including applicant, property and trip details
View application timeline.
Proceed to collect by clicking on the “Collect Payment” button.
A user is redirected to the following screen on clicking on "Collect Payment".
The following actions can be performed:
View collection amount, including total amount and amount per trip.
Enter/update payee details.
Select payment mode.
Gen/G8 receipt details by entering receipt no. and issue date.
Upon clicking on collect, a user is redirected to a confirmation page.
User Actions
The following actions can be performed:
Print payment receipt.
Go back to home by clicking on the “Take Action” button.
The following is the view of the payment receipt.
Open desludging applications are accessible by navigating to the inbox via the FSM homepage. Applications where DSO needs to be assigned will be shown as "Pending for DSO Assignment".
The following actions can be performed:
Search for an active application using “Application No." and “Mobile No.”.
Clear Search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Locality’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application detail.
Assign DSO.
On clicking the "Assign DSO" button, a pop-up will occur.
The following actions can be performed:
Select DSO name via dropdown.
Select expected date of completion.
Close pop-up by clicking on the 'Close' button.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Clicking on 'Assign' will redirect the user to the application details page and display a snack bar as confirmation. The status of the application will be updated to “Pending for DSO Approval”.
Employees can reassign to other DSOs in case the request has been rejected or declined by the DSO for some reason. Search for applications "Pending for DSO Approval" status.
The following actions can be performed:
Search for an active application using “Application No." and “Mobile No.”.
Clear search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Localilty’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details.
Click on “Take Action” button.
The take action button has the following options:
Assign vehicle (on behalf of DSO).
Decline request (on behalf of DSO).
Re-assign DSO.
Clicking on “Re-assign DSO” will display the following pop-up.
The following actions can be performed:
Select “Reason for Re-assign”.
Select “DSO Name”.
Update “Expected date of completion”.
Close pop-up by clicking on the 'Close' button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop up.
Confirm re-assignment by clicking on the ‘Reassign’ button.
Clicking on 'Assign' will redirect the user to the application details page and display a snack bar as confirmation. The status of the application will remain as “Pending for DSO Approval".
Employees can be assigned the role of the DSO, and can decline a request on behalf of the DSO. Applications can be rejected by an employee when in “Pending for DSO Approval” stage.
User Actions
The following actions can be performed:
Search for an active application using “Application No." and “Mobile No.”.
Clear search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Localilty’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details.
Click on the “Take Action” button.
The take action button has the following options:
Assign vehicle (on behalf of DSO).
Decline request (on behalf of DSO).
Re-assign DSO.
Clicking on “Decline Request’” will display the following pop-up.
User Actions
The following actions can be performed:
Reason for declining.
Enter comments.
Close pop-up by clicking on the 'Close' button on the pop-up.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Confirm decline request by clicking on the “Decline Request” button.
A snack bar will confirm decline and the application timeline will be updated to "DSO Rejected".
Employees can be assigned the role of the DSO, and can assign a vehicle and a sanitation worker on behalf of the DSO. A vehicle and a sanitation worker can be assigned when the application is in the “Pending for DSO Approval" stage.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”
Clear search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Locality’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details.
Click on the “Take Action” button.
The take action button has the following options:
Assign vehicle (on behalf of DSO).
Assign sanitation worker (on behalf of DSO).
Decline request (on behalf of DSO).
Re-assign DSO.
Clicking on “Assign Vehicle and Sanitation Worker’’ will display the following pop-up.
The following actions can be performed:
Update vehicle registration number.
Update the driver and the sanitation worker.
Choosing a driver is mandatory.
Close pop-up by clicking on the 'Close' button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop up.
Confirm decline request by clicking on the 'Assign' button
A snack bar will confirm assignment of vehicle and driver, and the application timeline will be updated to "DSO in Progress".
Once DSO is in progress, the number of trips can be updated. This can be done by both the ULB and the DSO.
The following actions can be performed:
Search for an active application using “Application No.” and “Mobile No.”.
Clear search by clicking on “Clear Search”.
View and update applications by clicking on an application number.
Filter applications by ‘Locality’ using the locality dropdown.
Filter applications by ‘Status’.
Search for past applications by using “Search Application”.
On clicking on an application number, application details are displayed.
The following actions can be performed:
View application details.
Click on the “Take Action” button.
The take action button has the following options:
Complete request.
Update/schedule trips.
Re-assign DSO.
On clicking on Update/Schedule trips, the following pop up is displayed:
The following actions can be performed:
Increase the number of trips by clicking on the + button.
Decrease number of trips by clicking on the - button.
Close pop-up by clicking on the Close button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop up.
Confirm update/schedule trips by clicking on the “Update/schedule” button.
A snack bar will confirm the updated number of trips.
Once the service request has been completed and all pending payment has been collected, the same has to be confirmed in the system. This can be done by selecting the “Complete Request” button in the “Take Action” button. On clicking on "Complete Request", the following pop-up is displayed:
The following actions can be performed:
Confirm/update service date.
Confirm/update the volume of waste collected.
Confirm/update pit details.
Upload pit photo
Close pop-up by clicking on the 'Close' button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop up
Confirm details by clicking on the ‘Completed' button.
A snack bar will confirm that request has been completed and the status will be updated to “Waiting for Disposal”.
The Septage Treatment Plant Operator (SeTPO) receives multiple vehicles servicing various desludging requests in the urban local body (ULB) and adjacent gram panchayats (GPs) through the day, each day. Some of these trips made by some vehicles may be associated with the applications raised and serviced through the platform. Additionally, incoming vehicles may come in independently, without corresponding applications.
SeTPO can:
Update the status of applications and trips in “Waiting for Disposal” stage at the FSTP/STP as disposed
Log vehicle(s) requests that are not in the system
FSTP operators are provided credentials to login to the system.
On this page, the following actions can be performed:
Enter username and password
Select the city for login
Reset password by clicking on the “Forgot Password” link
On clicking continue, FSTP operators are redirected to the FSM homepage.
Click on Inbox to view incoming vehicles for disposal against applications and perform actions
Record incoming vehicle that has not come in via an application
View reports
Change language
Edit profile details by clicking on the user icon on the top right hand corner
Logout by clicking on the user icon on top right hand corner
On this page, the following actions can be performed:
To view incoming vehicles for disposal against applications, the user can navigate to the inbox. The inbox displays a list of trips along with the vehicle number that is pending to be disposed off at a specific plant.
The following actions can be performed:
Search for an active trip using the “Application No.”, Vehicle no. and DSO name.
Clear search by clicking on “Clear Search”
View and update trip details by clicking on a trip ID or vehicle log
Sort applications and trips by the application date
On clicking on an application number or vehicle log ID, the user is redirected to the update trip page.
View trip details such as Vehicle no., DSO Name, and Locality.
Update vehicle in time and out time.
Update septage dumped (in litres)
Add additional details and attachments.
Submit form or decline vehicle by clicking on the “Take Action” button
The following actions can be performed:
The take action button has the following options:
Decline Vehicle
Submit
On clicking the Submit button, the application is updated successfully and a snack bar will appear for confirmation. The application will also be removed from the Inbox.
There are multiple reasons why a vehicle may be declined at the treatment plant, such as due to the quality of waste or if the plant is under maintenance. In such cases, the treatment plant operator may decline the incoming vehicle. This can be done from the application details page where the “Take Action” button has the option for Decline. On clicking on this, the following pop-up will appear.
The following actions can be performed:
Select the reason for declining
Close pop-up by clicking on the Close button on the pop up.
Close pop-up by clicking on the cross icon on the top right of the pop up.
Confirm decline by clicking on Decline Vehicle.
On clicking on Decline Vehicle, there will be a snack bar confirming the action and the user will be redirected to the home screen.
Incoming vehicles that have not come in via an application can be recorded by the user using the add ‘New’ button on the FSM home screen. On clicking on the New button, the user will be redirected to the following screen:
The following actions can be performed:
Enter Vehicle Number
Click on Next
Once vehicle number is entered, the ‘Next’ button will be highlighted and the user will be redirected to the Vehicle Log screen.
The following actions can be performed:
Update DSO Name and Locality
Update Vehicle In time and Out time.
Update volume of waste.
Update Additional Details and Attachments.
Submit the form by clicking on Submit.
A snack bar will confirm submission and the user will be redirected to the FSM homepage.
Logging in with the plant operator role will take the user to the landing page.
The landing page has a list of cards which includes the TQM card.
The landing page shows a pending tasks card at the bottom of the page.
The pending tasks card lists tests pending to be updated by this user.
The tasks which are overdue will show up first in the pending tasks card.
There is an option to view all the pending tasks which takes the user to TQM inbox page.
Clicking on the Treatment Quality Monitoring (TQM) card will take the user to the TQM home page.
The TQM home page shows a TQM card with the links to Inbox, View Past Tests.
It also shows 2 cards below which are -> Your performance, Alerts card.
The "Your Performance" card shows relevant metrics such as test compliance and the percentage of tests that passed which shows the efficiency of the plant(s) linked to the logged in user.
The 'Alerts' card shows a count of the different types of alerts that were raised by the system. This data comes from the anomaly finder.
In FSM 1.3 EDITOR users could take workflow actions and assign drivers to FSM Applications now we have changed that assignment. Now EDITOR users can assign a driver and multiple helpers to an FSM Application. And both driver and helper are Sanitation workers now.
EDITOR User role code:
Login with EDITOR user and go to FSM Inbox
From Inbox choose any application whose status is pending for DSO assignment
Go to the application details page from inbox
From the Action bar options click on "Assign Vehicle and Sanitation Workers"
A Popup window will open which looks like the following
We have two new options here, Assign Driver and Assign Sanitation Worker
Assign Driver is single select and mandatory
Assign Sanitation worker is multi-select and we can assign multiple Sanitation workers. Assigning worker is non mandatory though
Both these dropdowns are searchable i.e., EDITOR can search by name and Sanitation worker ID
These dropdowns are populated based on the vendor that is tagged to the current FSM Application.
User can click on Assign to take this action. A toast message is displayed showing the update is successful.
After this action, added Sanitation workers are displayed on the Application Details screen under DSO Details Section
To fetch FSM application details we are hitting this endpoint "/fsm/v1/_search"
Refer the below curl:
To update FSM application we are hitting this endpoint "/fsm/v1/_update"
Refer to the below curl:
To get a particular vendor data tagged to the current application we are hitting this endpoint "/vendor/v1/_search"
Refer to the below curl
Role action mapping for the above three endpoints is done for this role
Desludging operators (DSO) can be registered via a user interface (UI) available to the urban local body (ULB) admin. Once created, multiple vehicles and drivers can be mapped to a DSO. DSOs can also be enabled/disabled in the system.
Desludging operators will have the following details:
Drivers can be registered via a UI available to the ULB admin. Once created, a driver can be mapped to a DSO. Drivers can also be enabled/disabled in the system.
Driver operators will have the following details:
Vehicles can be registered via a UI available to the ULB admin. Once created, a vehicle can be mapped to a DSO. Vehicles can also be enabled/disabled in the system.
Vehicles operators will have the following details:
The citizen or the ULB official can apply for a desludging request.
Application Channel
Citizens can apply online using the web application.
Citizens can walk into a ULB and submit a request to the counter operator, who then creates an application on behalf of the citizen online.
Citizens can call the ULB and request for a desludging operation, which can then be transformed into an online application by the ULB official.
Application Submission
Desludging applications can be created by a citizen.
Desludging application requests can be created by a ULB official on behalf of a citizen.
- If the application is created by a ULB official, then capture the channel in which the request was received. It will be an additional field in the UI to capture the channel.
Service Request Fee
Service request fee is calculated as a multiplier of the amount per trip defined in the billing slab table (based on property type, sub-type, whether it is a slum, vehicle capacity) and the number of trips.
For certain combinations with the above parameters, the pricing can be set at zero. In such cases, demand will not be generated.
ULBs can configure a minimum advance payment to be collected before starting a request. This can either be a fixed value (starting from 0) or a percentage (ranging from 0-100). Citizens will be able to make a payment above the minimum advance amount, and below the total trip amount as an advance payment.
Payment: Online/Cash Counter
Citizens can make both the advance and balance payments online.
Citizens can make both the advance and balance payments at the ULB counter.
Payment receipts will be generated and sent across via SMS. They can be downloaded at the citizen and ULB interfaces.
When a service request is received by a ULB official, he/she can do the following:
- Search and assign a DSO to the application request.
- Cancel the application with remarks.
- Update the application request with the number of trips required to empty the septic tank or Pit and the vehicle details.
- Change the DSO from an application request if the assigned DSO is not available.
- Update the status of the request as completed, post desludging.
- View past records of requests and service delivery.
Cancellation of application
A citizen or a ULB official can cancel the application online.
Citizens can cancel it only if the DSO is not assigned to the service request.
Application cannot be cancelled if the payment is made already.
ULB officials can cancel it only if the service is not completed by the DSO.
SMS and Email Updates
SMS and email updates are sent on every necessary process of the entire process flow.
A DSO should get notified about the request that is assigned to him/her. On receiving the request, the following actions can be taken:
- View the request.
- Assign requests to a vehicle.
- Update the number of trips.
- Flag a request ready for disposal.
- Close the request post desludging.
One DSO cannot see the details of the other DSO or the request assigned to the other DSOs.
Citizens can provide feedback on the desludging request:
There will be an option to rate the service provided with comments.
There will be an option for citizens to update whether safety equipment is used by the sanitary workers during the operation.
Plant operators can do the following:
View the list of desludging operations for a day. Since an application may have multiple trips, the plant operator will view multiple line items against an application in the inbox.
Update the Vehicle entry log against an application request with the details like:
- Date and time of entry.
- Volume of sludge dumped at the plant.
If a vehicle without a corresponding request arrives at the FSTP, the FSTP can record the vehicle entry.
The DSO can also decline an incoming vehicle.
Citizens can provide feedback on the desludging request:
Rate the service provided (1-5 stars).
Multi-select to update whether safety equipment is used by the sanitary workers during the operation.
List of PDFs
Acknowledgement Recepit: Confirming receipt of desludging receipts.
Payment receipts: Multiple payment receipts based on the payments made.
Search criteria
Search result
Search criteria
Search result
Search criteria
Search result
Filter criteria
Selection criteria
Other functionalities:
Share via:
a. Image: Downloads image
b. Whatsapp: Image shared via Whatsapp
Download:
a. Image format
Advance Balance Workflow
Pay Later Workflow
Zero Price Workflow
Admins can fill the "Add Sanitation Worker" form to create sanitation workers in the system.
Admins can fill details such as Mobile Number, Name, Date of Birth, Photograph, Address, Skills, etc.
The mobile number has to be unique, otherwise a validation error will be shown and the user will not be able to submit the form.
There is a role details section at the bottom which is non-mandatory.
Using this role details section, an admin can specify the functional roles that this worker has, such as driver, helper, etc.
By default, all workers will have a generic SANITATION_WORKER role.
Currently, driver and helper functional roles are present in the system. Both are created as citizens.
Sanitation workers can have multiple functional roles, that is, they can be a driver as well as a helper.
Sanitation workers can also be tagged to vendors on this page based on whether the employer type is a ULB or a private vendor. This implies that the vendor select dropdown is populated based on the employer type.
After submitting the necessary details, an admin can click on submit and a response page is shown.
We will hit the "/individual/v1/_create" endpoint to create sanitation workers
The curl is given below:
If a vendor is selected while creating a sanitation worker, we are calling this endpoint "/vendor/v1/_update" to tag this worker to a vendor after the individual create has responded with success.
The curl is given below:
Role-action mapping is done for the above two API endpoints for the following role:
Fetching data from the MDMS
The config can be found at CompleteApplication.js
File Path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/CompleteApplication.js
UploadPitPhoto.js molecule is available within the molecules folder in react-components.
File Path: frontend/micro-ui/web/micro-ui-internals/packages/react-components/src/molecules/UploadPitPhoto.js
Saving Image fileId in FSM service
The link for the MDMS changes made is given below.
RoleStatusMappping.json
Schedule Action is added for post-pay applications where DSOs can schedule the trip by entering the number of trips.
Code snippet for schedule window:
ScheduleDso.js is the file responsible for the schedule window pop up.
File path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/ScheduleDso.js
Faecal Sludge Management (FSM) is a system that enables citizens to raise a request for septic tank cleaning with their urban local bodies (ULBs) directly or for reaching out to a ULB counter. Citizens can track the application, make a payment for the charges and rate the service.
billing-service
mdms-service
workflow-v2
boundary-service
user-service
idgen-service
user-events
collection-service
notification-service
vendor
vehicle
fsm-calculator
egov-url-shortener
collection-service
pdf-service
This page shows all the details about a Sanitation worker
Sample Page Screenshot is given below for reference
Admin users will get an action bar at the bottom of the page which has two actions
Delete -> This calls the update Individual API and disables this user ( Soft delete)
A corresponding toast message is shown
We are hitting this endpoint "/individual/v1/_search" to fetch Sanitation Worker Details
Refer the curl below:
When individual is deleted we are making use of individual update "/individual/v1/_update"
Refer to the curl below
When we delete a Sanitation worker who is tagged to a vendor we are updating the worker - vendor tagging to inactive.
Refer to the curl below:
Role Action mapping is done for the above three endpoints for FSM_ADMIN role
There are two new updates introduced in FSM v1.2.1 while creating a new application - Stepper Information and Vehicle Capacity Selection in the Service Request Screen.
We are introducing stepper information in FSM while creating an application from the citizen side so that they have visibility on how many steps they need to go over to submit details regarding their tank.
TLTimelineInFSM.js file is the common component and used for rendering the stepper information. The path of the file is:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/TLTimelineInFSM.js
The code snippets for defining the steps present in FSM application under case “APPLY”:
The code snippets to render the stepper information in each screen using the timeline component:
Citizens can now select vehicle capacity along with the number of trips required while creating an application. If nothing is selected, we will proceed by taking the minimum vehicle capacity available with the number of trips.
Code path: frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pageComponents/SelectTripNo.js
The code snippet for rendering the Vehicle Capacity field in Service Request screen:
The code snippet for fetching the vehicles available under all DSO:
The code snippet for setting the default vehicle capacity to minimum:
In FSTP, we are trying to decouple the vehicle dispose from the FSM application. Whether vehicle is attached to any FSM application or not, we allow the vehicle to dispose in the FSTP plant.
After logging as a FSTP user, we have now the home button option:
Code changes path are:
DIGIT-Dev/frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/FsmCard.js
After moving into “home” option, an FSTP user can choose from the following options:
FSTP can choose Add Vehicle Log option if he/she wants to check whether a vehicle is linked to any application and dispose.
FSTP can choose Inbox if he/she wants to check all the applications that are is ready to dispose.
The path for code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpOperations.js
The code snippet for populating the options:
The code snippet for rendering the icon:
ULBHomeCard.js is the common component used to populate options in the screen.
The paths:
frontend/micro-ui/web/micro-ui-internals/packages/react-components/src/atoms/ULBHomeCard.js
FSTP can add vehicle log using vehicle number (in proper format with spaces, e.g. AB 00 CD 1234). An improper format will throw an error.
The path for the code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpAddVehicle.js
The code snippet for populating the add vehicle log field and its validation:
The code snippet for rendering the screen:
After entering the vehicle number in the add vehicle log screen, we are fetching the FSM application, which is linked to that specific vehicle number. The data is rendered as shown below:
The path for the code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpServiceRequest.js
The code snippets for fetching the FSM application linked to vehicle number:
Fetching the vehicle Id using vehicle number
Fetching the vehicle log using vehicle Id
Extracting out the FSM application number from vehicle log:
Fetching the FSM application details using FSM application number
The code snippets to render the data:
Mobile view
Desktop view
After selecting the application, FSTPO can dispose the vehicle log in the vehicle log screen.
Additional details and attachment fields are introduced in new updates in FSM v1.2.1 .
The screen for the existing vehicle log:
The screen for new vehicle log if no application is found for vehicle is shown below. FSTPO can dispose the new vehicle log by providing all the details below.
The path for the code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/FstpOperatorDetails.js
The code snippet for additional details and attachments field:
For new vehicle log:
The code snippets to render input field for new vehicle log:
Width of the column to be increased and the proportion of row height should match Figma
From the screen, an admin can create the sanitation worker page using the add option.
The functional roles have been mapped to the system roles using .
Employer has two options: ULB and private vendor. This specifies the current employer of this worker. This can be changed in .
Vendors can be a ULB or a private vendor. This is specified in .
From the Admins can Search for a Sanitation Worker and go to it's details page by clicking on Sanitation Worker Id
Edit -> This takes the user to
After taking delete action page is automatically redirected to the
Field Name
Type
Mandatory
Editable (Y/N)
Unique within a ULB (Y/N)
Vendor name
Free text
Y
N
N
Gender
Array
Y
N
N
DOB
Date
N
Y
N
Email address
Free text (Email format)
N
Y
N
Mobile number
Number
Y
N
Y
Door number
Free text
N
Y
N
Plot number
Free text
N
Y
N
Building name
Free text
N
Y
N
Street
Free text
N
Y
N
Pincode
Free text
N
Y
N
City
Array
Y
N
N
Locality/mohalla
Array
Y
N
N
Landmark
Free text
N
Y
N
Additional Details
Free text
N
Y
N
Status
Binary
Y
Y
N
Field name
Type
Mandatory
Editable (Y/N)
Unique within a ULB (Y/N)
Driver name
Free text
Y
N
N
Driver license number
Free text (Validation on the license format)
Y
Y
N
Gender
Array
N
Y
N
DOB
Date
N
Y
N
Email address
Free text (Email format)
N
Y
N
Driver phone number
Number
Y
N
N
Field name
Type
Mandatory
Editable (Y/N)
Unique within a ULB (Y/N)
Registration number
Free Text
Y
N
Y
Vehicle model
Array
Y
Y
N
Vehicle type
Array
Y
Y
N
Tank capacity
Array
Y
Y
N
Pollution certificate valid till
Date
N
Y
N
Insurance valid till
Date
N
Y
N
Road tax paid till
Date
N
Y
N
Fitness certificate valid till
Date
N
Y
N
Vehicle owner name
Free text
Y
N
N
Vehicle owner phone number
Number
Y
N
N
Field name
Type
Mandatory
Editable
Comments
Applicant name
Text
Y
N
Mobile number
Numeric
Y
N
Gender
Dropdown
Y
N
City
Dropdown
Y
N
As per the boundary data defined.
Locality
Dropdown
Y
N
As per the boundary data defined.
Whether property is in a slum
Binary
Y
N
Slum name
Dropdown
Y
N
Only if the above selection is yes. List of slums per ULB to be uploaded in the system.
Street name
Text
N
N
Door house number
Text
N
N
Landmark
Text
N
N
Geo location
Lat-Long
N
N
As per DIGIT standards.
Onsite sanitation type
Dropdown
N
Y
Select one from the list.
PIT size
L*B*D in feet (This UOM might change from state to state)
N
Y
Numeric
Property type
Dropdown
Y
N
Use the same ontology as defined in DIGIT Property Tax.
Property sub-type
Dropdown
Y
N
Use the same ontology as defined in DIGIT Property Tax.
Number of trips required
Numeric
Y
Y
Editable by ULB and DSO.
Vehicle capacity
Dropdown
Y
N
Populated as per the vehicle capacities available in the particular ULB.
Application channel
Dropdown
Y
Required only if the creator is a ULB official.
Total amount
Numeric, display only
Y
N
Calculated based on the billing slabs.
Minimum amount payable
Numeric, display only
Y
N
Displayed as per the configuration in the backend.
Advance amount
Numeric
Y
Y
Field name
Type
Required
Comments
Volume of waste collected
Numeric
Y
Field name
Type
Required
Comments
Vehicle in-time
Time
Y
Vehicle out-time
Time
Y
Volume of sludge dumped
Numeric
Y
Additional details
Text
N
Attachments
Document/Image
N
Field name
Type
Required
Comments
Vehicle number
Alphanumeric
Y
Only unregistered vehicles in the system.
DSO name
Text
Y
Locality
Text
Y
Vehicle in-time
Time
Y
Vehicle out-time
Time
Y
Volume of sludge dumped
Numeric
Y
Additional details
Text
N
Attachments
Document/Image
N
Attribute
Type
Required?
Comments
Vehicle
UUID
Y
Trip Number
Numeric
Y
Volume
Numeric
Y
Desludging request
UUID
Y
Reason for declining
String
Y
[ “Septage Source”, “Outside operational hours”, “Under Maintenance”]
Field name
Type
Required
ULB name
Default
Internally pass the ULB name (Y)
From date
Date
Y
To date
Date
Y
DSO name
Search
N - Auto-populate on typing a few letters.
Application number
Application date
Current Status
DSO Name
Amount (Rs)
Date of completion
Field name
Type
Required
ULB name
Dropdown
Internally pass this info.
Mohalla
Dropdown
N
DSO
Search
N - Auto-populate on typing few characters.
From date
Date
Y
To date
Date
Y
Application number/Date
Mohalla
DSO Name
Status
SLA compliance
Volume of waste collected
Field name
Type
Comments
ULB name
Dropdown
If the logged-in user is a ULB employee, then pass this information internally.
If the logged-in user is an STP/FSTP operator, then ask the user to select the ULB name as one STP can be attached to multiple ULBs.
STP/FSTP name
Dropdown
Internally pass this information: We have mapping between ULB and STP/FSTP.
DSO name
Search
N - Auto-populate on typing a few letters.
Vehicle number
Dropdown
Populate only if the DSO name is selected.
From date
Date
Y
To date
Date
Y
Application number
DSO name /Vehicle number
Vehicle entry date
Vehicle in time
Vehicle out time
Volume of sludge dumped (L)
Field name
Type
Comments
DDR (District name)
Dropdown
If the logged-in user is a ULB employee, then pass this information internally.
If the logged-in user is an admin, show for all the districts.
ULB name
Dropdown
If the logged-in user is a ULB employee, then pass this information internally.
If the logged-in user is an admin, show for all the ULBs.
Date range (From and to dates)
Date
Mandatory, auto-select for entire time period.
Field Name
Type
Comments
Denomination
Array
Choose the denominate between Cr, Lac and Unit.
Chart name
Chart type
X Axis
Y Axis
Logic
Comments
Tooltip (if any)
Drilldown available (Y/N)
Overview: Total requests
KPI
NA
NA
Sum of total the requests cumulated over a period of time.
Absolute number and percentage increase or decrease from previous year for the same time period.
NA
N
Overview: Total sludge treated (in KL)
KPI
NA
NA
Sum of the total sludge deposited from registered and unregistered vehicles at the FSTP.
Absolute number and percentage increase or decrease from the previous year for the same time period.
NA
N
Overview: Total collection
KPI
NA
NA
Sum of the total revenue collected against service delivery.
Absolute number and percentage increase or decrease from the previous year for the same time period.
NA
N
Overview: SLA compliance
KPI
NA
NA
Average SLA compliance (percentage of requests completed within SLA).
Percentage number and percentage increase or decrease from the previous year for the same time period.
NA
N
Overview: Citizen average rating
KPI
NA
NA
Average citizen rating (Total citizen rating/total number of applications with feedback).
Absolute number and percentage increase or decrease from the previous year for the same time period.
NA
N
Total cumulative collection
Area chart
Month
Total collection
Cumulative collection over a period of time.
- Month name - Value
N
Revenue by property type
Pie chart
NA
NA
Distribution of requests by property type.
The percentage of requests by each property type to be displayed on the chart.
Display percentage and absolute value.
N
Top 3 performing ULBs (SLA achievement)
Percentage completion on line chart
NA
NA
Average SLA per ULB.
Top 3 to be displayed. View more options available to view the entire list of ULBs.
N
Bottom 3 performing ULBs (SLA achievement)
Percentage completion on line chart
NA
NA
Average SLA per ULB
Bottom 3 to be displayed. View more options available to view the entire list of ULBs.
M
FSTP - Capacity utilisation
Line chart
Percentage capacity utilisation
Time (Month)
Total waste disposed of or total capacity.
Total waste treated to be displayed below the chart heading.
- Month - Capacity utilisation (%). - Capacity utilisation (%) as compared to last year for the same month.
Monthly waste collected versus monthly waste disposed off
Column chart
Waste collected and waste dumped
Time (Month)
- Sum of waste collected.
- Sum of waste disposed of.
- Month
- Waste collected (absolute number and % increase decrease as compared to last year for the same month).
- Waste disposed (absolute number and % increase or decrease as compared to last year for the same month).
Total request by region
Table
NA
NA
Fields:
- Serial number.
- District
- # of open requests.
- # of closed requests.
- # of total requests.
- Completion rate (Percentage completion).
- SLA achieved: Percentage.
- Total collection.
- Selection to display the number of rows in a table.
- Option to move to the next and the previous pages, and display the current page number.
- Search by district name.
- Show filters applied, if any.
Drilldown on district name to ULBs mapped in the district.
Vehicle log report
Table
NA
NA
Fields:
- Serial number.
- ULB.
- Volume of waste collected.
- Volume of waste dumped.
- Capacity utilisation (percentage). - Show comparison to last year.
- Selection to display the number of rows in a table.
- Option to move to the next and the previous pages, and display the current page number.
- Search by district name.
- Show filters applied, if any.
Application type
Status
Roles
Action
Next state
Desludging
Citizen
FSM_CREATOR_EMP
Create application
Application created
Desludging
Application created
Citizen
FSM_CREATOR_EMP
Submit application
Pending for payment
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reject application
Application created
Desludging
Pending for payment
Citizen
Pay for the number of trips (may be 0 to full)
Pending for DSO assignment
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Assign DSO
Pending for DSO approval
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Return application
Application created
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reassign DSO
Pending for DSO approval
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Assign Vehicle
DSO in progress
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Reject
Pending for DSO assignment
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
Update the number of trips or schedule trips
DSO in progress
Desludging
DSO in progress
Citizen
Pay (full amount)
DSO in progress
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
Dispose
DSO in progress
Desludging
DSO in progress
DSO
FSM_EDITOR_EMP
Complete request (after collecting the total amount)
Pending citizen feedback
Desludging
Pending citizen feedback
Citizen
Citizen provides feedback
Request completed
Application Type
Status
Action
Roles
Next State
VehicleTrip
Schedules trip
FSM_DSO
SCHEDULED
VehicleTrip
SCHEDULED
Ready for disposal
FSM_DSO"
"FSM_EDITOR_EMP
Waiting for disposal
VehicleTrip
Waiting for disposal
Dispose
FSM_EMP_FSTPO
DISPOSED
Application type
Status
Roles
Action
Next state
Desludging
Citizen
FSM_CREATOR_EMP
Create application
Application created
Desludging
Application created
Citizen
FSM_CREATOR_EMP
Submit application
Pending for DSO assignment
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reject application
Application created
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Assign DSO
Pending for DSO approval
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Return application
Application created
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reassign DSO
Pending for DSO approval
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Assign Vehicle
DSO in progress
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Reject
Pending for DSO assignment
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
Update the number of trips or schedule trips
DSO in progress
Desludging
DSO in progress
Citizen
Pay (Full Amount)
DSO in progress
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
Dispose
DSO in progress
Desludging
DSO in progress
DSO
FSM_EDITOR_EMP
Complete Request (after collecting the total amount)
Pending citizen Feedback
Desludging
Pending citizen feedback
Citizen
Citizen provides feedback
Request completed
Application Type
Status
Action
Roles
Next state
VehicleTrip
Schedules trip
FSM_DSO
SCHEDULED
VehicleTrip
SCHEDULED
Ready for disposal
FSM_DSO"
"FSM_EDITOR_EMP
Waiting for disposal
VehicleTrip
Waiting for disposal
Dispose
FSM_EMP_FSTPO
DISPOSED
Application type
Status
Roles
Action
Next State
Desludging
-
Citizen
FSM_CREATOR_EMP
Create application
Application created
Desludging
Application created
Citizen
FSM_CREATOR_EMP
Submit application
Pending for payment
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reject application
Application created
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Assign DSO
Pending for DSO approval
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Return application
Application created
Desludging
Pending for DSO assignment
FSM_EDITOR_EMP
Reassign DSO
Pending for DSO approval
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Assign vehicle
DSO in progress
Desludging
Pending for DSO approval
DSO
FSM_EDITOR_EMP
Reject
Pending for DSO Assignment
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
update No of trips / schedule trip
DSO in Progress
Desludging
DSO in progress
FSM_EDITOR_EMP
Reassign DSO
Pending for DSO approval
Desludging
DSO in progress
FSM_EDITOR_EMP DSO
Dispose
DSO in progress
Desludging
DSO in progress
DSO
FSM_EDITOR_EMP
Complete request (after collecting the total amount)
Pending citizen feedback
Desludging
Pending citizen feedback
Citizen
Citizen provides Feedback
Request completed
Application type
Status
Action
Roles
Next state
VehicleTrip
Schedules trip
FSM_DSO
SCHEDULED
VehicleTrip
SCHEDULED
Ready for disposal
FSM_DSO"
"FSM_EDITOR_EMP
Waiting for disposal
VehicleTrip
Waiting for disposal
Dispose
FSM_EMP_FSTPO
DISPOSED
The following are the known issues for DIGIT FSM v1.4:
Category
Details
Known Issues
Requests pending for action with sanitation workers will remain open if the Sanitation Worker is deactivated while the request is pending to be completed.
Functional Limitations
Automatic mapping between functional and system roles is not defined
A sanitation worker is currently created at the instance level. In case a sanitation worker is operating within a specific boundary, functionality to limit operations is not provided.
Editing Tagged Sanitation workers: Sanitation workers once tagged to a request cannot be edited.
Part search for Sanitation worker ID is not available
Here are the articles in this section:
FSM home breadcrumb title all should align
Improvement
2
Done
Y
Y
All text alignment should be left for FSM registry table
Improvement
2
Done
Disable button alignment, Figure our dropdown
Antriksh will share design
The date of vehicle creation camel case needs to be fixed
Improvement
0.5
Done
Y
Alignment of breadcrumbs and title should be out of the card and left
Improvement
3
Done
Y
Vehicle details title and second card should be aligned
Improvement
2
Done
Y
Remove the break line in the FSM details page
Improvement
2
Follow Design same as New Desludging Application
Done
Y
Spacing between section header, field above and field below
(+91) in every mobile input field need to be added if it is not major changes
Improvement
16
91 Should be every where there is mobile number field
Done
Some are in old format and some are in new format
Look at entire application and check where gaps are
The rupee symbol needs to be removed from the left side and symbols should be left aligned
Improvement
2
Done
Rupee is still coming on the left hand side in application form
Also look at the entire application and check where gaps are
Add vendor card need to be alligned for vehicle
Improvement
3
Done
Add vendor pop-up close circle need to follow the Figma design, pop-up does not align for text properly
Improvement
2
Done
Update trips, add driver, add vendor, add driver modal cancel icon need to be corrected
Improvement
2
Done
Remove top padding in vendor/vehicle/driver details screen
Improvement
2
Done
Vendor/driver/vehicle details screen title-breadcrumb-card should be aligned properly
Improvement
4
Done
Vendor/driver/vehicle edit screen title-breadcrumb-card should be aligned properly
Improvement
Done
Vendor/driver/vehicle edit screen title should be outside card
Improvement
Done
Vehicle number search box in the vehicle tab should check the correct format
Improvement
2
Done
HOME SCREEN REMOVE
Improvement
2
Done
Pincode validation
Improvement
16
Done
Roles permission for FSM inbox links are not proper
Improvement
3
Done
In collector screen, error for incorrect phone number is showing as Payment_Invalid_Mobile
Localisation
0.15
Done
Sorting FSM inbox should follow common inbox for vendor/driver/vehicle tab -backend
Improvement
12
Done
Sorting FSM inbox should follow common inbox for vendor/driver/vehicle tab- UI
Improvement
12
Done
The vendor name dropdown UI sould be according to the Figma link and align left
Improvement
18
Done
Show only go back to home if has only go back to home else show take action + If only one action is present in take action, then show only the action name
Improvement
12
Done
Redirection from SMS for payment, Showing as ES_PAYMENT_DETAILS_TOTAL AMOUNT and ES_PAYMENT_DETAILS_ADV_AMOUNT
Localisation
Done
Wherever input text does not match validation, error message needs to show in real-time
Improvement
40
Blocker
Todo
Change is redirected to a page in form and then the entire form restarts. Expected action: Change button should go to required page and then Next button should go back to the same page
Improvement
Common Issue in Every Module. Antriksh, Jagan and team is looking into it
Different terminologies found for Payment Method. In the Generate Receipt page (Payment mode -> Cash, Cheque, Credit/Debit Card) where as In Complete Request Page (Payment Received -> Paid In Cash, Paid at Counter, Net Banking).
Improvement
Need Clarity on what method should be populated?
Receipt capacity instead of type
Improvement
Dependency on Backend PDF Service
Todo
Vehicly type and payment sections should be separate
Improvement
Dependency on Backend PDF Service
Todo
Receipt needs to be redesigned
Dependency of Core Team. Since Receipt is a core services
FSM registry table should be common component
Improvement
16
Already common component is using
Todo
Either we can keep the option for the advanced amount and full amount in collect page for citizen, or remove the option <Tahera will get back on this
Improvement
Addressed in Frontendedback section of advance pay
Todo
Will be covering in Advance Pay Section
Pay Now and Pay Later looks a little confusing. Check the localisation with other modules
Improvement
Addressed in Frontendedback section of advance pay
Todo
Will be covering in Advance Pay Section
After clicking pay now, it is showing advance amount which looks a little confusing. Need to check with PO
Improvement
Addressed in Frontendedback section of advance pay
Todo
Will be covering in Advance Pay Section
Login error message "This MobileNumber Already Register as UserName in System. Pls try Another UserName"/ Reword to "This Mobile Number Already Register in the System. Please try Another UserName"
Improvement
1
Core team work
Todo
Test the entire product
Todo
Scroll up to the field
Improvement
12
Todo
Next button should be disabled when data is not filled; next button usage is currently inconsistent
Improvement
View application screen for citizen should have data in the same format as the acknowledgement receipt
Improvement
new UI has to be developed on figma first
FSM Calculator is a system that enables the FSM aAdmin to create billing slabs for the FSM application(s) with different combinations of propertytype, slum, and tank capacity, among others. It generates the demand after calculating the charges for the given application using the billing slabs already configured.
billing-service
mdms-service
workflow-v2
User-service
fsm
Vehicle Registry is a system that enables urban local body (ULB) employees to create and search vendors, that is, Desludging Operators (DSO) and driver entities with appropriate vehicle entities for the FSM application.
egov-mdms-service
egov-user-service
boundary-service
Egov-idgen
egov-workflow-v2
vehicle
DIGIT FSM V1.4 has been enhanced to provide the base for features to ensure Sanitation Worker Welfare. To know more about DIGIT FSM v1.4 , please follow the GitBook Link.
Deprecating Driver Registry
Introduction of Sanitation Worker Registry
Tagging Sanitation Workers to Service requests.
Updated Feature
Description
Maintaining a list of unique sanitation workers in DIGIT Sanitation through a sanitation worker registry
Viewing list
Adding a sanitation worker
Updating details
Disabling sanitation worker
Tagging sanitation workers to vendors
Recording participation of sanitation workers in service delivery by tagging sanitation workers to requests:
Tagging multiple sanitation workers to a request
Editing tagged sanitation workers
SMS to sanitation Worker in case of request assignment
Upgrade to inbox from V1 to V2
To improve performance of the inbox, migrated to version v2 of inbox
Click here for Known Issue List.
Goal
Category
Objective
How will it be measured via the product?
How will we know this is successful?
Zero deaths, diseases, and environmental contamination resulting from poor sanitation
Primary
To ensure every sanitation worker has a valid identity so as to enable distribution of benefits.
Number of sanitation workers registered in the system.
Increase in the number of sanitation Workers enrolled in the system over time.
Logging in with ULB admin role takes the user to the home page of DIGIT-UI.
If a ULB admin user is logged in, he/she will have access to TQM, and a TQM card will be visible on this screen.
Links such as Inbox, View Past Tests, and create test are available on this card.
A notification card is available on the bottom, which is specific to TQM. All the TQM-related notifications configured will show up here. Currently, it shows notifications for tests whose results are not updated on time (crossed scheduled date).
Use the egov-user-event service.
Sample request object:
The API returns a list of notifications relevant to the logged in user.
Sample curl for notifications:
The role-action mapping for /egov-user-event/v1/events/_search is added for this user that is, the ULB admin whose role code is PQM_ADMIN.
Introducing worker and FSM application mapping
Backward compatibility for existing applications
As part of the worker welfare v1.0, a new worker registry concept is being introduced. The creation of a worker, updation of details, searching and tagging a worker for different operations on sanitation programmes will be covered. We will leverage the Individual Registry for storing and querying details about a worker.
The individual service is an enhanced version of the user service that houses data about individuals. The individual service is being re-used from DIGIT Health.
Click here to access the Individual Service.
Change from driver concept to worker.
Deprecation of the driver table.
Backward compatibility for existing drivers (converting a driver user into an individual and mapping/backfilling to vendors).
Introducing worker vendor mapping.
Creation of workers directly using Individual registry APIs.
Vendor_Registration_Contract.yaml
Vehicle Registry is a system that enables urban local body (ULB) employees to create and search vehicle entities and schedule vehicle trips for FSM applications, and track the vehicle trip.
egov-mdms-service
egov-workflow-v2
user-service
egov-idgen
vendor
To enable FSM module in any new environment, we would need to perform certain steps. Considering an AWS account is already setup, following are the steps to be followed:
Deploy all required core-services builds to support this municipal-services(FSM and its dependent services). The core-services include: egov-accesscontrol, egov-common-masters, egov-data-uploader, egov-document-uploader, egov-enc-service, egov-filestore, egov-idgen,egov-indexer, egov-localization, egov-location, egov-mdms-service, egov-notification-mail, egov-notification-sms, egov-otp, egov-persister, egov-pg-service, egov-searcher, egov-url-shortening, egov-user, egov-workflow-v2, pdf-service, report, user-otp, zuul
Deploy all required business-services builds to support this municipal-service(FSM and its dependent services). The business-services include: billing-service, collection-services, dashboard-analytics, dashboard-ingest, egf-instrument, egf-master, egov-apportion-service, egov-hrms.
Deploy this municipal-service “fsm” as well as dependent municipal-services: fsm-calculator, vendor, vehicle, inbox, egov-user-event.
Sanitation workers provide an invaluable service that many of us notice only when confronted with locked, blocked, or filthy toilets; overflowing septic tanks; or beaches contaminated with sewage. These workers are vital to the proper functioning of the sanitation systems that underpin daily life, and we need many more of them to achieve the ambitious agenda of Sustainable Development Goal (SDG) 6. Yet sanitation workers are often invisible and too often subject to conditions that expose them to the worst consequences of poor sanitation: debilitating infections, injuries, social stigma, and even death in their daily work. Workers’ rights need to be recognised; workers need freedom and support to organise as a labor force; and their working conditions need to be improved and progressively formalised to safeguard health and labor rights to ensure decent working conditions, as called for by SDG 8.
Sanitation workers range from permanent public or private employees with health benefits, pensions, and clear legal protections to some of the most marginalised, poor, and abused members of society who take on low-grade, labor-intensive, and dangerous work. For those employed informally, their work is financially precarious, with poor pay and few benefits. Sanitation workers often suffer weak legal protection, missing or weak standard operating procedures, and weak enforcement and oversight of laws and policies protecting their rights and health.
Who is a Sanitation Worker?
The term sanitation workers refers to all people — employed or otherwise — responsible for cleaning, maintaining, operating, or emptying a sanitation technology at any step of the sanitation chain. This includes toilet cleaners and caretakers in domestic, public, and institutional settings; those who empty pits and septic tanks once full and other faecal sludge handlers; those who clean sewers and manholes; and those who work at sewage and faecal waste treatment and disposal sites (Dalberg Advisors 2017; WHO 2018).
Key challenges associated with sanitation workers are as follows:
Multiple occupational and environmental hazards.
Weak legal protection of an invisible workforce.
Financial insecurity.
Social stigma and discrimination.
There have been considerable initiatives taken in India towards sanitation worker welfare. Some of these include:
Institutionalisation of safety practices through the implementation of ERSU.
Loan financing via the National Safai Karamcharis Finance & Development Corporation (NSKFDC) for entrepreneurship and alternate skill development.
Training and skill development programmes towards safe sanitation.
For the implementation and execution of the above initiatives, the first step is to recognise sanitation workers as individuals entitled to safety, benefits and rights with specific skill-sets and capabilities. In certain states (Odisha, Tamil Nadu, and Maharashtra, to name a few), a database of sanitation workers is created through the generation of unique IDs. These aim to provide a formal identity to sanitation workers and further serve as a base for welfare programmes including medical coverage and student fee reimbursement. Training provided to these individuals, ensures that only trained professionals participate in the sanitation value chain. The second step is to monitor the participation of sanitation workers in service delivery to ensure safe sanitation by ensuring defined safety protocols are followed, and ensuring participation of trained sanitation workers in service delivery.
Keeping this in mind, Sanitation Worker Welfare will be introduced as an extension to DIGIT Sanitation.
V1: Introduction of sanitation worker database and recording participation of sanitation workers in service delivery.
V2: Implementation of the ERSU process on DIGIT.
Sanitation Worker Welfare will be rolled out across 2 versions:
The following is the scope of V1 for Sanitation Worker Welfare:
Maintaining a list of unique sanitation workers in DIGIT Sanitation through a sanitation worker registry:
Viewing list
Adding a sanitation worker
Updating details
Disabling sanitation worker
Tagging sanitation workers to vendors
Recording participation of sanitation workers in service delivery by tagging sanitation workers to requests:
Tagging multiple sanitation workers to a request
Editing tagged sanitation workers
SMS to sanitation Worker in case of request assignment
Report
With the implementation of the sanitation worker database, we aim to create a unique, verifiable database of sanitation workers, each with a unique ID.
Specifications:
Changes required:
The following functionality will be available to the user via the frontend to manage sanitation worker database:
View list of sanitation workers
Adding a sanitation worker
Updating details
Disabling sanitation worker
Tagging sanitation workers to vendors
Assign sanitation workers to a request:
Along with assigning a vehicle, the DSO will assign sanitation workers to a request. The sanitation workers will be assigned either by entering the unique SW ID or the phone number of the sanitation worker. If the unique SW ID/phone no. exists in the database, details of the sanitation worker, that is, name, phone number, SW ID, and photograph to be displayed on the screen for the DSO to confirm. In case the Garima ID/phone number does not exist, an error message will be displayed.
A DSO may assign one to many sanitation workers to a request. However, entering a minimum of one sanitation worker to a request is mandatory.
Specifications:
Updating Application | DSO in Progress
1.1 Tagging Sanitation Worker to Request
Notification to Sanitation Worker
An SMS notification will be triggered to the sanitation worker when a request is assigned to them with the citizen name and phone number.
Add a new sanitation worker by clicking on the ‘Add’ button on the FSM registry landing page and select Sanitation Worker User Actions. The following actions can be performed:
Add a new vendor by clicking on vendor.
Add a new vehicle by clicking on vehicle.
Add a new sanitation worker by clicking on sanitation worker.
On clicking on “Sanitation Worker”, the user will be redirected to the add the sanitation worker page.
User Actions
The following actions can be performed:
Enter the sanitation workers details. The fields are mentioned in the functional specifications table.
Go back by using the breadcrumbs.
Once the user submits an application, a snack bar will confirm the successful addition of a sanitation worker.
Details of the added sanitation worker will be displayed in the sanitation worker list on the top.
Login as an ULB admin and navigate to the FSM Registry by clicking on it. Click on the sanitation worker tab.A list of all sanitation workers in the system are visible along with the details of the vendor they are tagged to.
User Actions
The following actions can be performed:
View list of all sanitation workers in the system along with the details of tagged vendors.
Search for a sanitation worker using the search box. Results should be displayed in case of part match.
Clear search by using the “Clear Search” button
Enable/disable a sanitation worker by using the toggle.
Sort sanitation workers by creation date.
Add a new vendor, sanitation worker or vehicle by clicking on the ‘Add’ button.
Sanitation worker details can be viewed by clicking on the sanitation worker’s name. All details of the sanitation worker captured while creating a sanitation worker will be displayed here.
User Actions
The following actions can be performed:
View details of the sanitation worker.
Edit vendor tagging by clicking on the edit icon besides the vendor name.
Remove vendor tagging by clicking on the delete icon beside the vendor name.
Click on the “Take Action” button to edit or delete a vehicle.
Sanitation worker details can be edited by clicking on the “Take Action" button and selecting edit.
User Actions The following actions can be performed:
Click on edit to edit the sanitation worker.
Click on delete to delete the sanitation worker.
Click anywhere else on the screen to go back to the sanitation worker details.
On clicking the Edit button, the user will be redirected to the “Edit Sanitation Worker” page.
User Actions
The following actions can be performed:
Edit sanitation worker details.
Click on ‘Submit’.
The user will be redirected to the sanitation worker details page and the edits will be reflected.
The user will be redirected to the sanitation worker details page and the edits will be reflected. can be deleted by clicking on the “Take Action” button. The user will be redirected to the sanitation worker details page, and the edits will be reflected in the details page and selecting delete.
User Actions
The following actions can be performed:
Click on Edit to edit the sanitation worker.
Click on Delete to delete the sanitation worker.
Click anywhere else on the screen to go back to the sanitation worker details.
On clicking the ‘Delete’ button, a pop-up will be displayed for confirmation.
The following actions can be performed:
Close the pop-up by clicking on the ‘Close’ button on the pop-up.
Close the pop-up by clicking on the cross icon on the top right of the pop-up.
Confirm deletion by clicking on the ‘Delete’ button.
On clicking on ‘Delete’, the user will be directed to a list of SW and a snack bar will be displayed as confirmation.
Method 1:
Apart from tagging a sanitation worker to a vendor from the sanitation worker details page, tagging can also be done from the sanitation worker details page by clicking on the add new vendor button.
User Actions
The following actions can be performed:
View details of the sanitation worker.
Tag SW to a vendor by clicking on the + icon besides the “Add New Vendor”.
A pop-up will be displayed with a dropdown to select a vendor.
User Actions
The following actions can be performed:
Selection of a vendor from the dropdown.
Close pop-up by clicking on the cross icon on the top right of the pop-up.
Close pop-up by clicking on ‘Cancel’.
Confirm vendor selection by clicking on ‘Submit’.
On clicking on submit, the added vendor details will be displayed in the sanitation worker details page and a snack bar is displayed for confirmation.
Method 2:
A sanitation worker can also be tagged to a vendor from the sanitation worker list page. Select a vendor from the dropdown. The sanitation worker will be tagged to the selected vendor.
The DSO assigns a sanitation worker by clicking on the “Take Action” button and clicking an option of adding a vehicle and sanitation workers.
A pop-up is displayed. The user can perform the following actions:
Select a vehicle number from dropdown. This is mandatory.
Assign a driver by typing the name or the sanitation worker ID in the search field. A list of matching results will be displayed and the user can select one. On selection, the name and sanitation worker will be displayed in the field. The driver can be edited by editing the field and retyping the name of the sanitation. This is mandatory
Assign helpers by typing the name or sanitation worker ID. A list of matching results will be displayed and the user can select multiple. The selected sanitation workers will be displayed below the field and the user can remove them by clicking on the cross beside their name. This is non mandatory.
The user can confirm the assignment by clicking on confirm.
The user can close the pop-up by clicking on the cross icon on the top right hand side of the pop up or clicking on the cancel button. No entered details will be saved in this case.
The assign button will only be activated once the vehicle and driver is selected.
Part search to be enabled for both fields.
Sanitation worker details are displayed in the application in the DSO details section:
Driver: Name and sanitation worker ID.
Sanitation 1: Name and sanitation worker ID.
If there are more than 1 sanitation worker assigned, multiple rows for sanitation workers will be visible. Driver and sanitation worker fields will not be displayed unless they are assigned.
Login for sanitation workers to accept/decline requests.
Login access via sanitation worker registry: Sanitation worker registries will contain information on drivers and treatment plant operators, who participate in the DIGIT sanitation workflow. Ideally, login for the product for the role should be via the registry. However, this will not be implemented.
Verification of whether the job roles tagged to the sanitation worker are the actual roles they are performing on field.
Verification of whether the correct sanitation worker is tagged to the request.
Verification of training status of sanitation workers will be maintained by the partner agency and we are dependent on them to compute the percentage.
Multiple sanitation workers service a request. Only a subset of them are assigned in the system.
Sanitation worker safety is of national importance. The national mandate for the same is issued under “Emergency Response Sanitation Unit (ERSU)”. The Urban Management Centre (UMC) is leading the implementation of ERSU across Odisha. As part of ERSU, UMC along with the state of Odisha has also rolled out a programme for “Sanitation worker benefits” called 'Garima' whose main objective is to identify, monitor and support sanitation workers and their families.
eGov is collaborating with UMC on “Sanitation worker safety” for Odisha, which includes building platform and product capabilities for Garima. The objective of of the collaboration between eGov and UMC through an integration with Garima is to create a record of service delivery to:
Provide enumeration and benefits to sanitation workers
Identify the percentage of services with evidence of safe practices
eGov, through its DIGIT FSM platform implemented in Odisha can serve as a data capturing layer for the above and provide access of this information to UMC. The following will be the scope of work across the partnership:
For enabling any municipal-service on a fresh environment and for the first time, we need to have basic idea of what DIGIT does and what all generic services are required for setting it up .
DIGIT is an open-source, customizable platform that lends itself to extensibility. New modules can be built on top of the platform to suit new use-cases or existing modules can be modified or replaced. To enable this, in addition to deploying DIGIT, a CD/CI pipeline should be set up. CD/CI pipelines enable the end user to automate & simplify the build/deploy process.
DIGIT platform comprises of couple of core-services that serves as the backbone for the platform. There are several core-services like:
Each microservice has a distinct function, which is explained in the provided documentation links. Once you understand the platform and its terminology, you'll be well-prepared to activate any particular municipal service.
FSM Service Faecal sludge management (FSM) is a system that enables citizen to raise a request for septic tank cleaning with there ULB’s directly or indirectly reaching out to ULB counter. Citizen can track the application, make a payment for the charges and rate the service. Actions & Role Action Mapping : Add Role-Action mapping for the API’s in MDMS. Following are the required entries. They should be mapped to both CITIZEN and appropriate employee roles.
MDMS Actions & Role Action Mapping for FSM
FSM Calculator Service
FSM Calculator is a system that enables FSM Admin to create billing slab for the FSM application(s) with different combination of propertyType , slum , tank capacity and etc..
MDMS Actions & Role Action Mapping for FSM Calculator:
Vendor Service
Vendor Registry is a system that enables ULBEmployees to create and search Vendor i.e Desluding Operator (DSO) and driver entities with appropriate vehicle Entities for FSM Application. This document contains the details about how to setup the Vendor and describe the functionalities provided.
MDMS Actions & Role Action Mapping for Vendor
Vehicle Service
Vehicle Registry is a system that enables ULB Employees to create and search Vehicle Entities and schedule Vehicle Trip for FSM Application and track the VehicleTrip.
MDMS Actions & Role Action Mapping for Vendor
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Update the with the following requirements:
Indexer config: We will need following indexer files for setting up any module
Persister config Persister files required:
Searcher config
Pdf config Data config: Format config:
Reports Also mention the path of the above report file .
Dashboard configs => =>
Add all configs required
Add all Actions/endpoints required for fsm as mentioned in this . Add all actions with respect to core and business-services as well, like those of - egov-user, egov-mdms-service, apportion-service, collection-service, billing-service, egov-location, egov-common-masters, egov-idgen, egf-master, egov-user-event, otp services, access, egov-workflow-v2, data-uploader, egov-hrms, filestore-service, pdf-service, egov-pdf, report, localization-service, egov-persister, egov-indexer, egov-searcher, eg-pg-service, dasboard-analytics, dashboard-ingest, digit-ui, fsm, fsm-calculator, vendor, vehicle.
Add Role-Action mapping in file
Add required Roles for the respective FSM module in
Add , , , , , , , , , , , folders with their respective files.
Also add ULB/city specific data in their respective folders, for instance, create a folder and add the respective data files like Slum.json, UrcConfig.json, ZeroPricing.json required.
Note: The data sepecific to any ULB needs to be collected from the ULB officials and need to be present in mdms level. Refer the ULB specific data documentation and updation/upsertion
Add all the helm charts with respect to the business-services, core-services and municipal-services. Refer .
Add DevOps level changes in the evironment file. Refer . Add all the paths for files in the configs in the environment file. For instance, add the the path of indexer, persister and searcher files, etc. Make sure to add required properties at each service level as defined in the above mentioned environment file.
Upsert the required localizations. Refer for detailed steps.
Upsert the workflows as mentioned in the .
Upsert the SMS templates as localizations in your environment as well as update them in the SMS portal being used by the state. For detailed infomation,
Sanitation workers can be managed via the implemented as part of V1.3. The FSM Registry allows for ULB admins to manage the list of vendors, vehicles and drivers.
The Sanitation Worker Welfare module v1.0 will be rolled out to Orissa as part of Sujog v1.4. Click to know more.
Refer for further reference of DIGIT and its deployment.
..and
:
:
Goal
Category
Objective
How will it be measured via the product?
How will we know this is successful?
Zero deaths, diseases, and environmental contamination resulting from poor sanitation.
Primary
To ensure every sanitation worker has a valid identity so as to enable distribution of benefits.
Number of sanitation workers registered in the system.
Increase in the number of sanitation Workers enrolled in the system over time.
Zero deaths, diseases, and environmental contamination resulting from poor sanitation.
Secondary
To ensure only trained sanitation workers service requests.
The percentage of requests serviced by trained sanitation.
Increase in the percentage of requests serviced by trained sanitation.
Type
Mandatory
Editable (Y/N)
Unique within a tenant (Y/N)
Unique within an instance (Y/N)
Validation
Sanitation worker name
Free text
Y
N
N
N
N
Sanitation worker ID
Autogenerated
Y
N
Y
Y
N
Skills
Array, Multiselect
Y
Y
N
N
N (examples of these are Driving, Lab Operations, Plant Maintenance etc)
Tenant ID
Array, Multiselect
Y
Y
N
N
N (one sanitation worker may be performing roles in multiple tenants)
Roles
Array/Multiselect
Y
Y
N
N
N (examples of this is driver, helper, treatment plant operator, lab operator)
Gender
Array
N
Y
N
N
N
DOB
Date
N
Y
N
N
Must be minimum (Today - 18 years)
Email address
Free text (Email format)
N
Y
N
N
Follow email format
Phone number
Number
Y
N
N
N
Must have 10 digits
Status
Boolean
Y
Y
N
N
N
Employment type
Array (Fixed/Contractual)
Y
Y
N
N
N
Employer
Array (ULB/Vendor)
Y
Y
N
N
N
Vendor name
Array (Populated based on vendors in the ULB)
Y
Y
N
N
N
Photograph
File
N
Y
N
N
File size
Backend table
As Is
With sanitation worker registry
Action
Driver Table
Driver details are currently stored in the driver table in FSM.
Driver details will be fetched from the sanitation worker table.
Deactivate driver table.
Sanitation Worker Table
NA
Sanitation worker details will be stored in the sanitation worker table.
Create sanitation worker table.
Driver Vehicle Table
Currently, drivers and vehicles are mapped in the driver vehicle table in FSM.
There will be no driver vehicle mapping. Each transaction will be assigned to sanitation workers/drivers from the frontend.
Deactivate driver vehicle mapping table.
Sanitation Worker and Vendor Mapping
NA
Sanitation workers will be mapped to a vendor.
Create a sanitation worker vendor mapping table.
Entities
Actions
Create
Read
Search
Update
Delete
Deactivate
Sanitation Worker
X
Attribute
Type
Mandatory (Y/N)
Comments
SW ID (8 Digits)/Phone number
BIGINT
Y
Post assigning vehicles, the “Take Action” button will show an option to assign sanitation workers.
Search by entering Garima ID and phone number of the sanitation worker.
View of details fetched via API:
Name
Garima ID
Phone no.
Photograph
Confirm sanitation workers.
It is mandatory to add atleast 1 sanitation worker to a request.
Edit of sanitation worker/workers possible by deleting a sanitation worker.
displayName
Roles
Create FSM Application
CITIZEN, FSM_CREATOR_EMP, FSM_SWACHH_SATHI
Search FSM Application
CITIZEN,FSM_DSO,FSM_CREATOR_EMP,FSM_SWACHH_SATHI,FSM_EDITOR_EMP,FSM_ADMIN,FSM_DSO,FSM_DRIVER,FSM_COLLECTOR,FSM_VIEW_EMP,FSM_EMP_FSTPO
Update FSM Application
CITIZEN,FSM_EDITOR_EMP,FSM_ADMIN,FSM_DSO,FSM_DRIVER
FSM Application Charge Payment Search
FSM_ADMIN,FSM_DSO,FSM_DRIVER,FSM_COLLECTOR,FSM_EDITOR_EMP,CITIZEN,FSM_VIEW_EMP
FSM Application Audit Search
CITIZEN, FSM_CREATOR_EMP, FSM_EDITOR_EMP, FSM_VIEW_EMP, FSM_ADMIN, FSM_DSO, FSM_DRIVER, FSM_EMP_FSTPO, FSM_COLLECTOR
Create FSTP FSTPOperator Mapping
FSM_ADMIN
Update FSTP FSTPOperator Mapping
FSM_ADMIN,FSM_EMP_FSTPO
Search FSTP FSTPOperator Mapping
CITIZEN
Inbox Search ofr uI
FSM_EMP_FSTPO,FSM_COLLECTOR,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_CREATOR_EMP,FSM_ADMIN,FSM_DSO
Link
/fsm/v1/_create
/fsm/v1/_update
/fsm/v1/_search
/fsm/v1/_audit
/fsm/v1/_plainsearch
/fsm/plantmap/v1/_create
/fsm/plantmap/v1/_update
/fsm/plantmap/v1/_search
/inbox/v1/_search
/fsm/v1/_schedular
displayName
Roles
FSM BillingSlab Create
SUPERUSER,FSM_ADMIN
FSM BillingSlab Update
FSM_CREATOR_EMP,FSM_EDITOR_EMP,FSM_ADMIN,FSM_DSO,SUPERUSER
FSM BillingSlab Search
FSM_CREATOR_EMP,FSM_EDITOR_EMP,FSM_DSO,CITIZEN,SUPERUSER
Link
fsm-calulator/v1/_calculate
fsm-calculator/v1/_estimate
fsm-calculator/v1/billingSlab/_create
fsm-calculator/v1/billingSlab/_update
fsm-calculator/v1/billingSlab/_search
fsm-calculator/v1/_cancellationfee
fsm-calculator/v1/_advancebalancecalculate
Actions
Roles
Create Vendor/DSO
SUPERUSER,FSM_ADMIN
Search Vendor/DSO
FSM_ADMIN,FSM_DSO,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_EMP_FSTPO,CITIZEN,FSM_COLLECTOR,FSM_CREATOR_EMP,FSM_REPORT_VIEWER,FSM_DASHBOARD_VIEWERFSM_DRIVER,FSM_CREATOR_EMP,SUPERUSER
Update Vendor/DSO
FSM_EMP_FSTPO,FSM_ADMIN,SUPERUSER
Vendor Driver Create
FSM_ADMIN,FSM_CREATOR_EMP,FSM_DSO,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_EMP_FSTPO
Vendor Driver Update
FSM_ADMIN,FSM_CREATOR_EMP,FSM_DSO,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_EMP_FSTPO
Vendor Driver Search
FSM_ADMIN,FSM_CREATOR_EMP,FSM_DSO,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_EMP_FSTPO
Link
/vendor/v1/_create
/vendor/v1/_search
/vendor/v1/_plainsearch
/vendor/v1/_update
/vendor/driver/v1/_create
/vendor/driver/v1/_update
/vendor/driver/v1/_search
displayName
Roles
Create Vehicle Application
FSM_ADMIN
Search Vehicle Application
FSM_ADMIN,FSM_DSO,FSM_EDITOR_EMP,FSM_VIEW_EMP,FSM_EMP_FSTPO,FSM_CREATOR_EMP
Vehicle Trip Search
FSM_EMP_FSTPO,FSM_EDITOR_EMP,FSM_CREATOR_EMP,FSM_ADMIN
Vehicle Trip Update
FSM_EMP_FSTPO
Update Vehicle Application
FSM_ADMIN
Vehicle Trip Create
FSM_EMP_FSTPO
Link
vehicle/v1/_create
vehicle/v1/_search
/vehicle/v1/_plainsearch
/vehicle/trip/v1/_create
vehicle/trip/v1/_update
vehicle/trip/v1/_search
/vehicle/trip/v1/_plainsearch
vehicle/v1/_update
List of actions required to go live in the new State for the FSM module:
Data loading steps: Tenant, boundary, workflow etc
Import this curl :
Login from FSTP credientials and copy the uuid of FSTP user.
Take FSTP plantCode from MDMS PlantInfo.json file for specific ulb.
The status should be always ACTIVE.
Login from FSM_ADMINDEV credentials(for sujog-dev) which is having FSM Admin role for all the ulb’s.
Copy the auth token and user-info. Paste the auth token in the req. Body “authToken” field.
Hit the url.
Ways to load Vendor details :
From Api
By FSM Registry
Loading from API :
Steps:
Import this collection - https://www.getpostman.com/collections/59691b6d0a7346a7f29b
Change the request url specific to environment.
For Create DSO(URL) : https://sujog-dev.odisha.gov.in/vendor/v1/_create
For Search DSO(URL) : https://sujog-dev.odisha.gov.in/vendor/v1/_search?tenantId=od.anandapur
For Update DSO(URL) : https://sujog-dev.odisha.gov.in/vendor/v1/_update?tenantId=od.anandapur
Login from FSM_ADMINDEV credentials(for sujog-dev) which is having FSM Admin role for all the ulb’s.
Copy the auth token. Paste the auth token in the req. Body “authToken” field.
Request Info (eg. anandapur ulb) for Create DSO :-
Note:
Before pushing the vendor,first add Vehicle in MDMS. Take Vehicle Make, Model and Capacity from VehicleMakeModel in MDMS.
No special characters allowed in Vendor name.
Vehicle Registration number should be unique for every vehicle.
Scenerios for Vendor and Vehicle users: - One Vendor can be linked with two or more vehicles. - One Vehicle is linked with One Vendor. - Two Vendors can’t have same mobile number because vendor is a user and user is stored uniquely in database. - Vendor owner, Vehicle owner and Driver owner can be same or different for One Vehicle.
Hit the url it’ll push the data of vendor.
From FSM Registry :
Add details of Cesspool Operator,Vehicle and Driver from FSM Registry and link Vehicle with Cesspool operator and Driver with Cesspool Operator.
Import the curl :
Login to Super_user and copy the auth token
Change the req. Url to env you want to push also the auth token
Add the localisation message in the request body.
Hit the url.
Reference Localisation Doc :
All localisations of FSM : https://docs.google.com/spreadsheets/d/1RWqP-h_s0lJZnQ9RvFOIePdy7Hxle-RN/edit?usp=sharing&ouid=109809705320882389789&rtpof=true&sd=true
https://docs.google.com/document/d/1z-V8U8BvT1Ict1gRyf4b4aOCjr_snJ-Psk6A_5oKzWs/edit?usp=sharing
https://drive.google.com/drive/folders/1bIv4txLjOSt2L4DsNWkShSgmZFzo73yU?usp=drive_link
Important points :
Related modules for FSM : rainmaker-fsm
,rainmaker-common
,rainmaker-dss
Push the localisation for all the modules separately
After pushing the localisation,make a file to store all the localisations according to modules.
Selected tab white bg
Improvement
1
Done
Y
Add button width increase
Improvement
0.5
Done
Y
Dropdown width vendor
Improvement
0.1
Done
Y
Left padding of form
Improvement
0.1
Done
Y
Mobile and other validation spacing
Improvement
0.1
Done
Y
Role details input width should be same(License No)
Improvement
0.5
Done
Y
Delete Icon should be there
Improvement
0.1
Done
Y
Skills Localisation
Improvement
0.1
Done
Y
Dropdown height(upto 6-7 elements without scrolling)
Improvement
0.1
Done
Y
Add Vendor Icon should be before text
Improvement
0.1
Done
Y
Toast message should be up
Improvement
0.5
Done
Y
Delete popup spacing reduce
Improvement
Done
Role details tab compare with figma
Improvement
0.1
Done
Y
photograph compare with figma
Improvement
Done
Y
Icon in add role
Improvement
0.5
Done
Y
space b/w checkboxes
Improvement
0.1
Done
Y
Plus Icon in Details Page should be in circle
Improvement
0.1
Done
Y
FSM Card Icon missing Home Page
Improvement
1
Done
Y
Spacing between sections view worker
Improvement
1
Done
Y
Multiselect chips
Improvement
1
Done
Y
No Driver message check position(toast should touch the footer)
Improvement
0.5
Done
Y
Role details card spacing b/w labels and values
Improvement
0.5
Done
Y
All toasts should be at the bottom(close to either footer or action bar)
Improvement
0.1
Done
Y
DSS has two sides to it: One being the process in which the data is pooled to ElasticSearch, and the other being the way it is fetched, aggregated, computed, transformed and sent across. As this revolves around a variety of data sets, there is a need for making this configurable so that, if a new scenario is introduced, then it is a configuration away from getting the newly-introduced scenario involved in this flow of process.
This document explains the steps on how to define the configurations for the analytics side of DSS for FSM.
Analytics: Micro-service that is responsible for building, fetching, aggregating, and computing the data on ElasticSearch to a consumable data response, which will be later used for visualisations and graphical representations.
Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration
Chart API Configuration
Each visualisation has its own properties, and comes from different data sources (sometimes it is a combination of different data sources).
In order to configure each visualisation and their properties, we have a chart API configuration document. In this, the visualisation code, which happens to be the key, will have its properties configured as a part of configuration, and are easily changeable.
Here is the sample ChartApiConfiguration.json data for FSM.
Click here to check the complete configuration
Master Dashboard Configuration is the main configuration which defines as which are the Dashboards which are to be painted on screen.
It includes all the Visualizations, their groups, the charts which comes within them and even their dimensions as what should be their height and width.
Click here for the complete configuration.
The master dashboard configuration, which was explained earlier, holds the list of dashboards that are available.
Given the instance where role action mapping is not maintained in the application service, this configuration will act as Role - Dashboard Mapping Configuration. In this, each role is mapped against the dashboard which they are authorised to see. This was used earlier when the role action mapping of eGov was not integrated. Later, when the role action mapping started controlling the dashboards to be seen on the client side, this configuration was only used to enable the dashboards for viewing.
Click here to check the configuration
common-masters/uiCommonConstants.json
Click here to check the complete configuration.
roleaction.json
Click here to check the complete configuration.
Action test.json:
Click here to check the complete configuration.
FSM-DSS Consists of multiple graphs which represent the data of FSM. Each graph has its own configuration which will describe the chart and its type.
DSS Consists of following charts in FSM:
Overview
Total Cumulative Collection
Top ULB By Performance
Bottom ULB by Performance
FSM Collection by Usage Type
FSTP - Capacity Utilization
Monthly Septage Collected
Top DSO By Performance
Bottom DSO By Performance
Desludging Request Report
Vehicle Log Report
Overview graph contains multiple data information as below in the selected time period.
Total requests: Which represents the number of FSM applications.
Total sludge treated: This represents the total sludge dumped at the yard in KL.
Average FSM cost: This represents the average collection amount for the FSM applications.
Total collection: This represents the total collection amount for the FSM applications.
SLA compliance: This represents the total SLA achieved in percentage.
Average citizen rating: This represents the citizen average rating value.
This graph contains the collection amount information in the monthly base as a cumulative line graph. This will change as per the denomination amount filter selection.
This graph represents the ULBs based on the SLA achieved in bar chart representation with the percentage of SLA achieved in ascending order. This chart also contains the drill-down to give the complete information regarding each ULB.
Drill chart: If there is a drill-down on the visualisation, then the code of the drill-down visualisation is added here. This will be used by client service to manage drill-downs.
This chart consists of a drill-down, so, we gave the drill-down chart key as a reference in this chart (as shown in the picture above).
Here is the drill down chart config params.
Table chart sample: This chart comes with 2 kinds: Table and xtable.
The table type allows aggregated fields added as available in the query keys. Hence, to extract the values based on the key, aggegationPaths needs to add along with their data type as in pathDataTypeMapping.
When you click on "Show More," you will navigate to a tabular chart of the bottom ULB by performance.
This graph shows the collection amount based on the usage/property type, and this amount will change as per the denomination filter change. This also shows the percentage of the top four properties; the remaining properties will go under the 'Others' category.
This graph is in the line chart representation, and shows the data in cumulative format. It contains the information about the waste collecting plant capacity utilisation in percentage as well as the total waste dumped at plant in KL at the top of the graph.
This graph shows the data in horizontal bar representation, and the bars contain data monthly wide as well as non-cumulative data. This graph contains the monthly information of septage collected and dumped at the plant in KL.
This graph represents the DSOs based on the number of DSO requests and on SLA achievement in bar chart representation in ascending order. This chart also contains the drill-down to give the complete information regarding each DSO.
When you click on "Show More", you can see the details of the available DSOs under the selected ULB.
This graph represents the DSOs based on the number of DSO requests and on SLA achievement in bar chart representation in descending order. This chart also contains the drill-down to give the complete information regarding each DSO.
This is the bottom DSO drill-down chart which represents the table chart type.
When you click on "Show More", you can see the details of the available DSOs under the selected ULB.
This tabular chart representation graph shows multiple FSM information, such as the number of open application requests, closed requests, total requests, completion rate in percentage, SLA achieved in percentage, and total collection amount. This table shows the data at the district-level and also has the drill-down chart from each district to ULB, as well from ULB to the ward-level data for the same.
The xtable type allows you to add multiple computed fields with the aggregated fields dynamically added.
To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in exist in query key, newField as name to appear for computation must be defined.
chartSpecificProperty: This is specific to FSM-DSS, and it is used to achieve the xtable column order along with the computed fields. This property is not used in any other module till now.
When you click on any district name, you will see the drill-down charts, which will represent that specific district data.
When you click on the ULB, you will navigate towards under that specific ULB and each ward will show the data specific to that ward.
This table shows the data of vehicle trips, and it includes the number of trips, total septage collected, total septage dumped, and capacity utilisation in percentage. This graph also contains the drills-downs from district to ULB and from ULB to the vehicle level, which shows the vehicle number.
When you click on any district name, you will see the drill-down charts, which will represent the data specific to that district.
When you click on any boundary/ULB, you will navigate to the specific vehicle details which will be as shown below.
isRoundOff: This property is introduced to round-off the decimal values. For example, if the value is 25.43 by using isRoundOff property in configuration, you will get it 25. If value is 22.56, the round-off value will be 23. This can be used for insights configuration as well as overview graph.
Key (Example: fsmTotalrequest): This is the visualisation code. This key will be referred to in further visualisation configurations. This is the key which will be used by the client application to indicate which visualisation is needed for display.
chartName: The name of the chart which has to be used as a label on the dashboard. The name of the chart will be a detailed name. In this configuration, the name of the chart will be the code of localisation which will be used by the client side.
queries: Some visualisations are derived from a specific data source, while some others are derived from different data sources and are combined together to get a meaningful representation. The queries of aggregation, which are to be used to fetch out the right data in the right aggregated format, are configured here.
queries.module: The module/domain level on which the query should be applied on. Faecal Sludge Management is FSM.
queries.indexName: The name of the index on which the query has to be executed is configured here.
queries.aggrQuery: The aggregation query in itself is added here. Based on the module and the index name specified, this query is attached to the filter part of the complete search request and then executed against that index.
queries.requestQueryMap: Client request will carry certain fields which are to be filtered. The parameters specified in the client request are different from the parameters in each of these indexed documents. To map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.
queries.dateRefField : Each of these modules have separate indexes, and all of them have their own date fields. When a date filter is applied against these visualisations, each of them has to apply it against their own date reference fields. To maintain what is the date field in which index, we have this configured in this configuration parameter.
chartType : As there are different types of visualisations, this field defines what is the type of chart/visualisation that this data should be used to represent.
Chart types available are:
Metric - This represents the aggregated amount/value for records filter by the aggregate as query
Pie - This represents the aggregated data on grouping. This can be used to represent any line graph, bar graph, pie chart, or donuts.
Line - This graph/chart is data representation on date histograms or date groupings.
Perform - This chart represents groping data performance wise.
Table - Represents a form of plots and value with headers as grouped on and list of its key, values pairs.
xtable - Represents an advanced feature of table; it has addition capabilities for dynamic adding header values.
valueType: In any case of data, the values which are sent to plot, might be a percentage, an amount, or a count. To represent them and differentiate the numbers from amount and percentage, this field is used to indicate the type of value that this visualisation will send.
Action: Some visualisations are not just aggregation on data source. There might be cases where we have to do a post-aggregation computation. For example, in the case of top 3 performing ULBs, the target and total collection is obtained, and then the percentage is calculated. In such cases, the action that has to be performed on that data is defined in this parameter.
documentType: The type of document on which the query has to be executed is defined here.
drillChart: If there is a drill-down on the visualisation, then the code of the drill-down visualization is added here. This will be used by client service to manage drill-downs.
aggregationPaths: All the queries will have aggregation names in it. To fetch the value out of each aggregation response, the name of the aggregation in the query will be needed. These aggregation paths will have the names of aggregation in it.
insights: It is to show the data with the comparison of last year with arrow symbols. It will show the data as percentage is increased or decreased.
_comment: To display information on the “i” symbol of each visualisation, the visualisation information is maintained in this field.
Postman collection for fsm-dss: https://www.getpostman.com/collections/119ee90dd54c04617c3a
After adding all the data for ulb in MDMS,next step is to create user for Employee and FSTP.
From HRMS, Create Employee user and FSTP user of new tenant and add roles to it.
EMPLOYEE USER Example
FSTP USER Example
Set the password of EmployeeId by checking the logs of sms service.
The data templates contains Annexures which will be provided by the Program Team.
Annexure -1 : ULB and FSTP data.
Annexure -2 : Cesspool Vehicles
Annexure -3 : Slum Within ULB
Annexure -4 : Zero Pricing Property
Annexure -5 : GP Tagging and Pricing
Annexure -1 : ULB and FSTP data This Annexure contains the names and contact details provided for -
FSM Executive(Sl. No. A6) : CREATOR, COLLECTOR, EDITOR, DASHBOARD VIEWER, FSSM REGISTRY
FSM TRP(Sl. No. B7) : SUBMIT/DECLINE TRIPS, ADD VEHICLE LOG
Sl. No. A1 - A4 : ULB Details added in tenant/tenants.json file in mdms
Sl. No. B1 - B6 : FSTP Details added in FSM/FSTPPlantInfo.json file in mdms
Sl. No.
DETAILS
EXAMPLE
DESCRIPTION
A1
Name of ULB
(E.g.: Berhampur Municipal Corporation or Balasore Municipality or Banki NAC)->
Anandapur Municipality
A2
Helpline Phone numbers for Septic tank cleaning
(Write Landline with Code. Eg.: 0674-234563, 14420)->
14420
(Write 10 digit Mobile No. Eg.: 9876786543)->
8249735088
A3
ULB's full postal Address
->
Anandapur Municipality
A4
ULB's Latitude and Longitude
(E.g.: 20.2961° N, 85.8245° E)->
21.19076,86.130399
A5
ULB Commissioner / Executive Officer (EO) Details
Name of Commissioner / EO
->
Asok Kumar Rout
WhatsApp Phone No. of Commissioner / EO
->
9999999921
Official Email Id of Commissioner / EO
->
A6
ULB - FSSM Executive Details
(The designated role should be nominated by the EO/Commissioner)
(This person is responsible for taking desludging service requests from citizens, collecting payments, assigning cesspool vehicles which are registered at ULB (both ULB and Private) and taking further action on the requests. The designated role should be nominated by the EO/Commisioner and will be responsible to update the desludging requests on SUJOG-FSSM platform received via various channels. This role should have accessibility to the designated phone number/14420/ULB counter/single window, IT infrastructure (computer, internet, printer) etc.)
Name of FSSM Executive
->
Sk Sahabaz Alam Quadri
WhatsApp Phone No. of FSSM Executive
->
9999999922
Official Email Id of FSSM Executive
->
B1
FSTP's full postal Address
->
Salapda near MCC 2 ward no -12 Anandapur Municipality
B2
FSTP's Latitude and Longitude
(E.g.: 20.2961° N, 85.8245° E)->
21.19076,86.130399
B3
FSTP Installed Capacity in Kilo-Liters
(Eg.: 45 KLD)->
10 KLD
B4
Plant Operation Timing Duration
(Eg.: 09:00 AM - 08:00 PM)->
9.00 AM - 5.00 PM
B5
Name of SHG / ALF / CLF operating the Plant
->
MAA TARINI WSHG
B6
Is the FSTP serving the nearby Gram Panchayats?
(Write "Yes" OR "No". If "Yes", then how many Gram Panchayats) (Eg.: Yes-15 GPs OR No)->
Yes-81GPs
B7
FSTP - TRP Details
(Lab Technician)
Name of FSTP TRP
->
Rashmita Ojha
WhatsApp Phone No. of FSTP TRP
->
9999999923
Official Email ID of the FSTP TRP
->
NA
Annexure -2 : Cesspool Vehicles
Name of the ULB: (Write in right side box)
Anandapur Municipality
Details
Description
Vehicle-1
C. Cesspool Vehicle Details of ULB
Cesspool Vehicle Registration No.
->
OD09J7874
Vehicle Ownership
ULB or Private
ULB
Vehicle Owner's Name
If owner is ULB, mention the ULB name (E.g.: Banki NAC). If owner is Private Party, mention the name of Private Party's Company name (E.g.: Ram Infra Pvt. Ltd.) or Person name (E.g.: Ramesh Sahu).->
Anandapur Municipality
Mode of Operation
ULB Owned & ULB Operated or ULB Owned & Privately Operated or Privately Owned and Privately Operated ->
ULB owned & ULB opereted
Whether Cesspool Vehicle is registered with ULB?
YES or NO ->
YES
Cesspool Contractor's Name
->
NIPS
Cesspool Contractor's Phone No.
->
9988998898
Cesspool Driver's Name
->
DIPU MUKHI
Cesspool Driver's Phone No.
->
9988675561
Cesspool Driver's License No.
->
OR0920040025878
Cesspool Vehicle Insurance No.
->
3379/331735/000/00
Pollution Certificate No.
->
Yes
Vehicle Make
Eg.: Swaraj, Eicher, Mahindra etc. ->
Mahindra
Vehicle Model
Eg.: Truck, Tractor, Pick Up etc. ->
Truck
GPS Tracker is present in vehicle?
YES or NO ->
No
Cesspool Tank Capacity (in Litres)
->
1000
Per trip Pricing for Residential properties
->
1000
Per trip Pricing for Commercial properties
->
1000
Per trip Pricing for Institutional properties
->
1000
Per trip Pricing for Slum areas
->
1000
The Contractor Details are the DSO/Vendor/Cesspool Operator details can be added from vendor api or FSM Registery to add dso in the portal.The driver and vehicle is assigned to the dso.
Vehicle Make,Model and Vehicle Tank capacity is added in MDMS under VehicleMakeModel.json file within Vehicle folder in mdms-repo.
According to Tank Capacity,Property Type,Sub-property Type and Slums,the pricing is defined in billing-slab.
Annexure -3 : Slum Within ULB The ULB can configure zero pricing for slums at a ULB level - all applications raised from slums would be required to pay zero application fees When creating an application, the default Slum Name is set to 'NONE'. If the user resides in a slum area, they have the option to select a specific Slum Name as follows:
Open the Septic tank emptying request.
In the 'Slum Name' field, you will find 'NONE' as the default value.
If you live in a slum area, click on the 'Slum Name' field to open a dropdown menu.
From the dropdown menu, select your specific slum area from the available options.
By selecting the appropriate slum name, you can accurately specify your residential location within the application.
Name of the ULB: (Write in right side box)
Anandapur Municipality
D. Slum List of ULB
Sl No.
Name of the Slum in the ULB
1
Birbal Kolha Sahi
2
Dehury Sahi
3
Panda Sahi
4
Bauti Sahi
5
Dahanibania Sahi
6
Bandirigadia Harijan Sahi
7
Mukhi Sahi
8
Majhi Harijan Sahi
9
Hadi Sahi
10
Gouda Sahi
11
Kolha Sahi
12
Badaharijan Sahi
13
lndira Colony
14
Saunti Sahi
15
Janara Harijan Sahi
16
Nala Sahi
17
Harijan Sahi near Gotha
18
Adibasi Sahi(Poda khaman)
19
Dehury Sahi (Podakhaman)
20
Mukhi Sahi (Podakhaman)
21
Deury Sahi, Sailong
22
Sarat Kumar Sahoo
The slum details are added in specific ulb folder(anandapur/FSM/Slum.json).
Annexure -4 : Zero Pricing Property In Zero Pricing Property,ULB can opt for zero-price application based on some criteria(like slum, property, sub-property, capacity etc.) which is configurable in MDMS & billing_slab table .In case of zero-pricing, no demand will be generated and collection step will get skipped.
Eg. For Institutional.Temple,the price will be 0.
Name of the ULB (Write in right side box)
Anandapur Municipality
E. Zero Pricing Properties of ULB
Sl No.
Property Type
Property Sub Type (Mention here the name of the properties under each category as mentioned in the left-hand side column.) E.g.: CT, PT, Collector's Office etc.
1
Institutional
CT,PT, Temple, Govt. High School, Govt. Hospital, Govt. School
2
Commercial
3
Slum
Annexure -5 : GP Tagging and Pricing When creating a new application, users can choose between local municipalities or urban supported villages. Based on their choice, they can select either a locality/mohalla or a Gram Panchayat (GP) area from the respective dropdown list. If a ULB employee selects GP, they can manually input a trip amount based on offline calculations, instead of using the auto-calculated amount available for urban areas. ULB employees and DSO Operation personnel should also be able to edit the number of trips, and the final amount must be a multiple of the initial amount entered in the application based on the number of trips.
Sl No.
Name of the Gram Panchayat tagged to ULB
1
BAILO
2
BAUNSAGARH
3
BELABAHALI
4
BUDHIKUDA
5
DHAKOTHA
6
GAYALAMUNDA
7
HARIDAPAL
8
JALASUAN
9
KANTIPAL
10
KATHAKATA
11
KODAPADA
12
KOLIMATI
13
MANOHARPUR
14
MOCHINDA
15
PANASADIHA
The data related to Gram Panchayat are added in mdms under specific ulb folder(Example. anandapur/egov-location/boundary-data.json to show in the ui.
To add new ulb/tenant for FSM,following steps should be followed:
Add data in MDMS
After this,restart the mdms service and check the status in ui.The tenant will be added in ui.
Create Employee and FSTP login credientials.
Plant Mapping of tenant
Push the localisation of all the slums and Gram Panchayat in tenant.
Push the billing-slab of new tenant
Push the vendor-vehicle data of new tenant
Citizens represent individuals or communities who are the system end-users. The FSM module provides citizens with the scope to apply for desludging services and make the payment for the applied services.
Citizens can do the following:
Language selection
Login
Apply for desludging services
Check application status and vehicle status
Download application acknowledgement
Choose to pay an amount above the minimum advance required and pay the remaining balance post service
Rate the services provided by the urban local bodies (ULBs)
Overview
When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange colour.
On this page, the following actions can be performed:
A user can switch the language.
A user can click on 'Continue' to navigate to the login screen.
Overview
Users are redirected to this screen once they select the preferred language in the previous screen. Users can choose to either register as a new user or login as an existing user.
Register a new user
User Actions
On this page, the following actions can be performed:
A person can register as a new user by entering the mobile number, name and the city.
A person can login as an existing user by clicking on the login button.
A user can choose to continue with Whatsapp to raise a service request.
After the user clicks on "Continue", the page navigates to the "Enter OTP" page.
User actions
On this page, the following actions can be performed:
Enter the OTP received on the given mobile number to login.
The system will prompt for the selection from a list of available cities. Select the city to complete login.
Login as an Existing User
Overview
This is the page one is redirected to when the user clicks on ‘Login’ to login as an existing user.
User Actions
On this page, the following actions can be performed:
Enter mobile number to login as an existing user.
Navigate to register as a new user.
A user can choose to continue with Whatsapp to raise a service request.
After the user clicks on ‘Continue’, the page navigates to the “Enter OTP” page.
User Actions
On this page, the following actions can be performed:
Enter the OTP received on the given mobile number to login.
Once the OTP is entered, users are prompted to choose a location. Using this screen, they can select the location for which they would like to request for services.
User Actions
On this page, the following actions can be performed:
A user can switch the location.
A user can click on 'Continue' to navigate to the login screen.
Overview
After they login, users are redirected to this screen where multiple actions can be performed related to Faecal Sludge Management services.
User Actions
On this page, the following actions can be performed:
Desludging services can be requested by clicking on “Apply for Emptying of Septic Tank/Pit” option on the homepage.
User is redirected to the Service Request Page.
On this page, the following actions can be performed:
Enter “No of Trips” required
Enter “Vehicle Capacity” required.
Skip and Continue if the above information is not available.
On clicking on “Next”, the user is redirected to the Choose Property Type page.
On this page, the following actions can be performed:
Selection of Property Type
Basis Property Type selected, information regarding tentative cost of desludging service is provided.
On clicking on “Next”, the user is redirected to the Choose Property Subtype page.
On this page, the following actions can be performed:
Selection of Property Subtype
On clicking on “Next”, the user is redirected to the Pin Property Location page.
On this page, the following actions can be performed:
Enable the Location finder to allow GPS to track the current location, or, move the pin to the location manually.
Search for location using the search bar.
Skip and Continue if the above information is not available.
If pin location is not selected, the user is redirected to enter Pincode.
On this page, the following actions can be performed:
Entering Pincode.
Skip and Continue if the above information is not available.
On clicking on “Next”, the user is redirected to the Provide Property Address page.
On this page, the following actions can be performed:
Selection of City
Selection of Locality/Mohalla
On clicking on “Next”, the user is redirected to mention whether the property is located in a Slum.
On this page, the following actions can be performed:
Selection of whether property is located in Slum
On clicking on “Next”, the user is redirected to the Provide Name of Slum page. If no is selected, then this page is skipped.
On this page, the following actions can be performed:
Selection of Slum name from dropdown
On clicking on “Next”, the user is redirected to the Provide property address page.
On this page, the following actions can be performed:
Enter Street Name
Enter Door No.
Skip and Continue if above information is not available
On clicking on “Next”, the user is redirected to the Provide Landmark page.
On this page, the following actions can be performed:
Enter Landmark
Skip and Continue if above information is not available.
On clicking on “Next”, the user is redirected to the Pit/Septic Tank Details page.
On this page, the following actions can be performed:
Enter Length of Septic Tank
Enter Breadth of Septic Tank
Enter Depth of Septic Tank
Skip and Continue if the above information is not available.
On clicking on “Next”, the user is redirected to the Upload Pit photo page.
On this page, the following actions can be performed:
Upload Pit Photo
Skip and Continue if the above information is not available.
On clicking on “Next”, the user is redirected to the Select Gender page.
On this page, the following actions can be performed:
Select Gender
Skip and Continue if the above information is not available.
On clicking on “Next”, the user is redirected to the Payment Details page. The page displays Total amount and Minimum amount payable. The advance amount payable field displays the minimum amount payable.
On this page, the following actions can be performed:
Enter advance amount greater than minimum amount payable and lower than total amount
Skip and Continue if the above information is not available
On clicking on “Next”, the user is redirected to the Summary page. The page displays a summary of all the details filled by the user.
On this page, the following actions can be performed:
Click on Change to change any filled details
Click on Submit once the review is complete and the details are satisfactory
On clicking on “Submit”, the user is redirected to the Application Submitted page.
On this page, the following actions can be performed:
Download application receipt by clicking on download button
Go back to the home page.
The system triggers a notification along with the Application No. and details to the registered mobile number. Any subsequent updates and actions on the application also trigger a notification to the applicant.
The system triggers a notification along with the Application No. and details to the registered mobile number. Any subsequent updates and actions on the application also trigger a notification to the applicant.
From the home page, users can access past application history by clicking on the “My Applications” page.
On this page, the following actions can be performed:
Click on ‘My applications’ to view a list of past applications.
On this page, the following actions can be performed:
View details of Applications
Clicking on View redirects the user to Application Details
View details of applications
View current Status of application
On this page, the following actions can be performed:
If the application is on the Payment Pending stage, the user will have the option to make a payment from the View Applications page.
On this page, the following actions can be performed:
Download Acknowledge receipt of application
Make a payment by clicking on the Make Payment button.
The user is redirected to the bill details page which displays the total, advance and due amount.
On this page, the following actions can be performed:
Confirm details and Proceed to pay.
The user is redirected to Select Payment preference.
The system intimates the user that clicking on Pay will redirect them to a third party payment gateway.
On this page, the following actions can be performed:
Select Payment Method.
Click on pay to proceed.
The system displays a payment acknowledgement message along with the Payment Receipt No.
On this page, the following actions can be performed:
Print Payment receipt
If the application is on the Payment Pending stage, the user will have the option to make a payment from the View Applications page.
On this page, the following actions can be performed:
Provide the rating for service by clicking on Rate us.
The user will be redirected to the Provide Feedback page.
On this page, the following actions can be performed:
Selection of overall rating between 1-5 stars
Confirmation on Safety gears used by the operator
Providing additional inputs, if any, using the comments box.
Clicking on submit redirects the user to the confirmation page.
On this page, the following actions can be performed:
Download final payment receipt
Go back to the home page.
Sample of SMS present in FSM product :
The above SMS needs to be registered with specific TEMPLATE ID(Eg.'1407169140018862465') for each Localization key from the state Government/Client on their respective SMS portals.
Append the TEMPLATE ID at the end of message. Example.
Push the sms templates in Localisation. SMS related to OTP:
For adding the rate slabs(pricing) of vehicles,consider different combination of propertyType , slum and tank capacity.
RESIDENTIAL and RESIDENTIAL.SUB-PROPERTY_TYPE
INSTITUTIONAL and INSTITUTIONAL.SUB-PROPERTY_TYPE
COMMERCIAL and COMMERCIAL.SUB-PROPERTY_TYPE
Consider billing slab property types and Sub-property types for both slum and non-slum areas.Take slum='YES' for slum areas and take slum='NO' for non-slum areas.
Sample Data for pricing : - The pricing is provided according to Vehicle capacity,property-types and slum areas.
Within the tenant,For two Vehicles having the same capacity,the pricing should be same. Example : In Vehicle-1 and Vehicle-3,for capacity 1000,pricing for Residential properties with Slum='NO' = 1000 Commercial properties with Slum='NO' = 1000 Institutional properties with Slum='NO' = 1000 Residential properties with Slum='YES' = 800 Commercial properties with Slum='YES' = 800 Institutional properties with Slum='YES' = 800
Loading Rate Slabs Steps:
Change the request url specific to environment.
Login from FSM_ADMINDEV credentials(for sujog-dev) which is having FSM Admin role for all the ulb’s.
Copy the auth token. Paste the auth token in the req. Body “authToken” field.
Open the runner tab (ctrl+shift+R) and import the file which is shared in the step 5. (For example: billing-athagarh.json for pushing athagarh billing slab).
Drag the api which is provided in Step 1 collection.
Hit the postman collection.
IMPORTANT POINTS:
1.The format of billing slab data is:
Eg.
2.The capacity always starts from 0.
3.Example. If the given capacity is 1000 and 3000 then the range should be:
"capacityFrom": 0,
"capacityTo": 1000,
"capacityFrom": 1001,
"capacityTo": 3000,
4.Consider billing-slab for both slum and non-slum areas.
5.The status is always ACTIVE.
How to update billing slab data:
The format of updating billing slab data is:
2.If the need is to update the price for all the slums from 800 to 500,for this Take the response from search api for slum “YES”,make a json file with updated price and push it using runner with the syntax mentioned in point 1.
Zero Pricing property in billing-slab :
For some combination of property types and sub-property types,the zero pricing property is given.For that,the price will be considered as 0(zero) for all the capacities and slum areas.
The urban-rural convergence is an initiative that aims to ensure access to sanitation services to all gram panchayats (GPs) via urban local bodies (ULBs) located closest to them.
A ULB employee creates applications to cater to the sanitation needs of local communities in urban areas. In the same way, they should also cater to the same sanitation needs of rural bodies near that urban region.
They need a provision in a system while creating a new application to either choose local municipalities or urban-supported villages.
Based on their choice they would be able to select either a locality/mohalla or a GP area from the respective master data drop-down list.
The caveat here is that if a ULB employee chooses GP, then the trip amount field should be editable where he/she can fill in any logical amount based on the offline calculation instead of the auto-calculated amount already there in an application in the case of urban bodies.
ULB employees or DSO operators should also be able to edit the number of trips. The final amount should be multiple of the initial amount entered into an application with the number of trips.
Update the MDMS data: boundary-data.json
- Add a new children hierarchy for GP under city which will be parallel to locality. A sample MDMS is attached below:
By default, the 'Urban' option will be pre-selected in the radio button in the above wireframe and the drop-down will have the locality/mohalla master data. If an employee selects “ULB supported village”, then the locality/mohalla drop-down will be replaced by GPs and village drop-down data on the fly.
The system will use the below URL to fetch the localities or GPs and their corresponding villages.
- In the case of localities, one needs to pass boundaryType as “Locality”.
- In the case of GP/villages, one needs to pass the boundaryType as “GP”.
Introduction of a new string column (boundary_type) in the FSM_APPLICATION table to capture (locality or GP) to determine if the application created is for rural or not so that in the near future it will be helpful for the analytics and statistics in dashboards.
- The default value for this column will be locality to support backward compatibility
Adding a vehicle log would also have the option to select urban (default option) or rural. If rural gets selected the text name of an element would be replaced from 'locality' to “Gram Panchayat” for a text field.
Introduction of a new column of string type (boundary_type) in the vehicle_trip table to capture if the vehicle log is created for the GP or not.
- The default value for this column will be Locality to support backward compatibility.
boundary-data.json
UrcConfig.json
To enable URC feature in the UI:
To analyse the impact, we deployed a different module (property tax) which points to the same boundary-data mdms.
Expectation:
For FSM Module: Non-URC flow: The locality drop-down should show all the localities as it is (there should be no impact). URC flow: The gram panchayat and village drop-down should show as per the new GP and village added to the MDMS.
For Property Tax Module: The locality drop-down should show all the localities as it is (there should be no impact).
Property Tax Screen:
The locality dropdown in property tax displays the values from the existing location hierarchy itself (there is no impact).
SUJOG FSM (NON-URC)
In FSM, for non-URC, the locality drop-down shows the values from the existing hierarchy itself (there is no impact)..
SUJOG FSM (URC)
GP drop-down In the case of FSM (URC), the gram panchayat and village drop-downs are showing values from the new hierarchy we have configured in the existing MDMS.
Village Dropdown
Pricing
Pricing per trip will be entered by “ULB employees” for each request.
ULB employees will have a free text entry field to enter the price for a request.
In FSTP, there are two scenarios -
Selects a gram panchayat from drop-down but the village is not in the list. In this case, select 'other' in the village and a free text field appears.
Select 'other' in the GP list. In this case, 2 free text fields appear - one for GP and one for village.
If the locality or GP is located outside the city, then select “Outside ULB Limits” and provide the locality/gram panchayat name in the text field.
In the dashboard, add the following chart:
Add pie chart: Applications by source
Pie chart value: Ratio of applications from GP: Ratio of requests from urban areas.
Add toggle for applications and sludge.
Pie chart value: Ratio of sludge disposed from GP: Ratio of sludge from urban areas.
Tooltip: Show total applications and total sludge (See design). Tooltip value to be responsive to toggle between unit, lakh, and crore.
The chart should filter based on the period, district, ULB (dashboard filters).
Add bar chart: Number of applications per month from the GP.
Bar chat value: The total number of applications from the GP.
Add toggle for applications and sludge disposed.
Tooltip: Show the total applications and total sludge (See design). Tooltip value to be responsive to toggle between unit, lakh, and crore.
The chart should filter based on the period, district, ULB (dashboard filters).
The following features/components will be available in the TQM module:
The aim is to provide the users of the system information and control at each level - from defining how operations will be run, to updating status against pending operational tasks, and viewing operational data to draw insights to refine operations.
Analytics contains multiple configurations. We need to add the changes related to FSM in this dashboard-analytics. Here is the location: configs/egov-dss-dashboards/dashboard-analytics at qa · egovernments/configs Below is a list of configurations that need to be changed to run FSM successfully.
Line - This graph/chart is data representation on date histograms or date groupings.
This graph represents the ULB’s based on the SLA achieved in bar chart representation with the percentage of SLA achieved in descending order. This chart also contains the drill-down to give the complete information regarding each ULB.
Reference from Annexure
Data
Location
Description
Annexure -1 Sl. No. A1 - A4
Tenant Details
To show the tenant at login screen
To enable ulb to create application,add tenant in FSM module
Annexure -1 Sl. No. B1 - B6
FSTP Data
To add FSTP information
Annexure-2 Vehicle Make,Vehicle Model,Cesspool Tank Capacity
New Vehicles
Add Vehicles in application.Before pushing the vehicle data,new vehicle should be added in mdms.
Annexure -3
Slum Details
To add slum data,create a folder of a respective tenant and inside it add slum.json file in FSM folder
URC Feature
To enable URC(GramPanchayat) feature for ulb
Annexure -4
Zero pricing feature
To enable zero pricing feature
Annexure -5
Locality and Gram Panchayat Details
Under specific ulb folder,add locality and gp details under egov-location folder.
Required combination of property types and Sub-property types added in :
Import this collection -
For search billing-slab(url) -
For create billing-slab(url) -
For update billing-slab(url) -
Download these files - and update the file by changing the different combination of propertyType , slum and tank capacity with respect to tenant/ulb.
6.If the price of all the slums is given as 0,then mark zeroPricingStatus as true otherwise mark it as false in .
Eg.
boundaryType=Locality&tenantId=pb.amritsar
boundaryType=GP&tenantId=pb.amritsar
We are keeping the locality hierarchy under the city as it is [No change there]. And the ‘location api’ with boundaryType as 'locality' will be used the same way it's being called currently to get the localities. Below are the API details: boundaryType=Locality&tenantId=pb.amritsar Response:
To get a list of gram panchayats and corresponding villages, pass the boundaryType as 'GP'. Below are the API details: boundaryType=GP&tenantId=pb.amritsar
The chart should have export, share, and download options.
The chart should have export, share, and download options.
Action
Localization key
localization message
SMS
1
Employee creates an application
FSM_SMS_ASSIGN_DSO_APPLY
Dear citizen, your application for cleaning septic tank/pit is created with application reference no {2}. You will be notified when an operator is assigned to a request. Request is expected to be completed within {SLA_HOURS}hrs. Thank You. EGOVS.
Dear citizen, your application for cleaning septic tank/pit is created with application reference no FSM-AND-2023-07-27-003405. You will be notified when an operator is assigned to a request. Request is expected to be completed within 48hrs. Thank You. EGOVS.
2
Citizen creates an application
FSM_SMS_ASSIGN_DSO_APPLY
Dear citizen, your application for cleaning septic tank/pit is created with application reference no {2}. You will be notified when an operator is assigned to a request. Request is expected to be completed within {SLA_HOURS}hrs. Thank You. Govt. of Odisha.
Dear citizen, your application for cleaning septic tank/pit is created with application reference no FSM-AND-2023-07-27-003406. You will be notified when an operator is assigned to a request. Request is expected to be completed within 48hrs. Thank You. Govt. of Odisha.
3
At the time of assign vehicle
FSM_POST_PAY_SMS_DSO_INPROGRESS_DSO_ACCEPT
Dear citizen, Vehicle {VEHICLE_REG_NO} will be reaching your location to clean the septic tank/pit on {POSSIBLE_SERVICE_DATE} with reference to your application number {2}. You can contact the operator in +91 {DSO_MOBILE_NUMBER} Thank You. Govt. of Odisha
Dear citizen, Vehicle OD09J7874 will be reaching your location to clean the septic tank/pit on 27-07-2023 with reference to your application number FSM-AND-2023-07-27-003406. You can contact the operator in +91 9988998898 Thank You. Govt. of Odisha
4
Updating no of trips
FSM_SMS_DSO_INPROGRESS_UPDATE
Dear citizen, your application for cleaning septic tank /pit with application number {2} is updated and the operator has entered the number of trips: {NO_OF_TRIPS}. Please click this link {PAY_LINK} to pay the amount of Rs {AMOUNT_TO_BE_PAID} towards cleaning of your septic tank/pit. Thank You. EGOVS
Dear citizen, your application for cleaning septic tank /pit with application number FSM-AND-2023-07-27-003406 is updated and the operator has entered the number of trips: 2. Please click this link https://sujog-dev.odisha.gov.in/egov-url-shortening/Q56N2npkX6OKAJ4l to pay the amount of Rs 2000.0 towards cleaning of your septic tank/pit. Thank You. EGOVS
5
Collect payment
FSM_SMS_DSO_INPROGRESS_PAY
Dear citizen, amount of Rs.{AMOUNT_TO_BE_PAID}/- is received towards the payment of cleaning septic tank /pit for reference no. {RECEIPT_NO}. Please click this link {RECEIPT_LINK} to download the receipt. Thank You. Govt. of Odisha
Dear citizen, amount of Rs.2000.0/- is received towards the payment of cleaning septic tank /pit for reference no. 07/2023-24/009469. Please click this link https://sujog-dev.odisha.gov.in/egov-url-shortening/eRX3JK18bW0BAalM to download the receipt. Thank You. Govt. of Odisha
6
Complete Request
FSM_SMS_CITIZEN_FEEDBACK_PENDING_COMPLETED
Dear citizen, your request for cleaning septic tank/pit is completed. Please take some time to rate us using the link {FSM_APPL_LINK}. Thank You. Govt. of Odisha
Dear citizen, your request for cleaning septic tank/pit is completed. Please take some time to rate us using the link https://sujog-dev.odisha.gov.in/egov-url-shortening/5oyNDr9LJRmnMY6P. Thank You. Govt. of Odisha
7
Cancel Request by ULB
FSM_SMS_CANCELED_CANCEL
Dear citizen, your request for cleaning the septic tank/pit is cancelled with the reason {FSM_CANCEL_REASON}. Please use this link {NEW_FSM_LINK} to create a new request if needed. Thank You. Govt. of Odisha
Dear citizen, your request for cleaning the septic tank/pit is cancelled with the reason CITIZEN_DENIED_REQUEST. Please use this link https://sujog-dev.odisha.gov.in/egov-url-shortening/d0mgXKeAE8XKLxvb to create a new request if needed. Thank You. Govt. of Odisha
8
Decline Request after assinging dso
FSM_SMS_DSO_REJECTED_DSO_REJECT
Dear citizen, your request for cleaning the septic tank/pit is rejected with the reason {FSM_DSO_REJECT_REASON}. Please use this link {NEW_FSM_LINK} to create a new request if needed. Thank You. Govt. of Odisha
Dear citizen, your request for cleaning the septic tank/pit is rejected with the reason Vehicle is under repair. Please use this link https://sujog-dev.odisha.gov.in/egov-url-shortening/LM7ROBzx9dOnAXd0 to create a new request if needed. Thank You. Govt. of Odisha
9
Submit Vehicle Trip
FSM_SMS_DSO_INPROGRESS_UPDATE
Dear citizen, your application for cleaning septic tank /pit with application number {2} is updated and the operator has entered the number of trips: {NO_OF_TRIPS}. Please click this link {PAY_LINK} to pay the amount of Rs {AMOUNT_TO_BE_PAID} towards cleaning of your septic tank/pit. Thank You. EGOVS
Dear citizen, your application for cleaning septic tank /pit with application number FSM-AND-2023-07-27-003408 is updated and the operator has entered the number of trips: 1. Please click this link https://sujog-dev.odisha.gov.in/egov-url-shortening/az21kn2R95Gnpwb4 to pay the amount of Rs 1000.0 towards cleaning of your septic tank/pit. Thank You. EGOVS
10
After updating trips first time and generating payment
FSM_ADVANCE_APP_CREATE
Dear citizen, Your application reference number for cleaning septic tank/pit is {2}. You have opted to pay an advance amount of Rs.{AMOUNT_TO_BE_PAID}/-. Please click this link {PAY_LINK} to make the payment. You will be notified when an operator is assigned. Thank you for contacting us. EGOVS
Dear citizen, Your application reference number for cleaning septic tank/pit is 107-FSM-2023-02-15-006749. You have opted to pay an advance amount of Rs.100/-. Please click this link https://qa.digit.org/egov-url-shortening/p8Lvp0 to make the payment. You will be notified when an operator is assigned. Thank you for contacting us. EGOVS
Name of the ULB: (Write in right side box)
Anandapur Municipality
Details
Description
Vehicle-1
Vehicle-2
Vehicle-3
Cesspool Tank Capacity (in Litres)
->
1000
3000
1000
Per trip Pricing for Residential properties
->
1000
2000
1000
Per trip Pricing for Commercial properties
->
1000
2000
1000
Per trip Pricing for Institutional properties
->
1000
2000
1000
Per trip Pricing for Slum areas
->
800
1500
800
Name of the ULB (Write in right side box)
Anandapur Municipality
E. Zero Pricing Properties of ULB
Sl No.
Property Type
Property Sub Type
1
Institutional
CT,PT, Temple, Govt. High School, Govt. Hospital, Govt. School
Table Name
Column Name
Comments
eg_fsm_application
boundarytype
To capture (locality or GP) to determine if the application created is for rural or not based on the radio button selection.
eg_fsm_address
additionaldetails.gramPanchayat
To store the selected GP while creating an application.
eg_fsm_address
additionaldetails.village
To store the selected village while creating an application.
eg_vehicle_trip
boundarytype
To capture (locality or GP) if the vehicle log is created for GP or not.
Feature
Service Name
PR
Added new component for URC
data/pg/FSM/CommonFieldsConfig.JSON
Create UrcConfig.json to enable URC feature
data/pg/angul/FSM/UrcConfig.json
Enabling overRide for tripAmount
data/pg/FSM/Config.json
Added GP data for specific ulb
data/pg/ulb-name/egov-location/boundary-data.json
Feature
Service Name
Changes
URC
FSM
https://github.com/egovernments/DIGIT-Dev/pull/5296 https://github.com/egovernments/DIGIT-Dev/pull/5297 https://github.com/egovernments/DIGIT-Dev/pull/5308 https://github.com/egovernments/DIGIT-Dev/pull/5309 https://github.com/egovernments/DIGIT-Dev/pull/5312 https://github.com/egovernments/DIGIT-Dev/pull/5315 https://github.com/egovernments/DIGIT-Dev/pull/5317 https://github.com/egovernments/DIGIT-Dev/pull/5318 https://github.com/egovernments/DIGIT-Dev/pull/5319 https://github.com/egovernments/DIGIT-Dev/pull/5376 https://github.com/egovernments/DIGIT-Dev/pull/5378 https://github.com/egovernments/DIGIT-Dev/pull/5399 https://github.com/egovernments/DIGIT-Dev/pull/5406
Feature
Location
PR
Add pie chart: Applications by Source
Add Bar chart: No. of applications per month from Gram Panchayat
configs/egov-dss-dashboards/dashboard-analytics/ChartApiConfig.json,
configs/egov-dss-dashboards/dashboard-analytics/MasterDashboardConfig.json
Features/Components
Description
Functionality
Schedule of Tests
This component will be used by treatment plant operators and urban local body (ULB) employees to see the schedule of tests.
View the schedule of lab tests and track the compliance. Track the compliance of IoT test results and cases of failures.
Recording Test Results
This component will be used by treatment plant operators and ULB employees to upload results manually and track IoT readings.
Create digital records of quality test results alerts in the following cases:
IoT device not working.
Lab results do not match IoT results.
Anomaly Detection
This component will be used by treatment plant operators and ULB employees to interpret test results.
Identify in real-time/near real-time when the results of a particular test are not as per the benchmarks.
Alerts in the following case:
Results not upto the benchmark.
Dashboards
This module will give stakeholders insights and information regarding the operations of the treatment plant. Users can use this to drill down and identify plants and processes where compliance to testing and/or test results are not upto benchmarks.
Dashboards will also help users see trends over time to see patterns and identify long-term problem areas.
Dashboard to analyse trends in the treatment quality and compliance with the treatment schedule. Drill down will be made available from state to the ULB and at a plant level.
Dashboard to analyse patterns in issues. A drill down will be made available from state to ULB and at a plant level.
Provision of urban local bodies (ULBs)/DSO to assign one or more sanitation workers to each request:
Sanitation workers will be made available via integration with the Garima database through API in the workflow.
Since the Garima ID may not be well known to the ULB/DSO, a search functionality is to be made available by entering a phone number.
Preview details of the selected sanitation worker for confirmation.
Capture sanitation worker details if a sanitation worker is not available in the Garima database.
Provide aggregated data around how many requests are served by date via unique Garima IDs by API to UMC.
No linking will be done between the Garima worker and the vendor in Sujog FSM.
Provide enumeration and benefits to sanitation workers.
Identify the percentage of services with evidence of safe practices.
Feature
Service Name
PR
Added new component for URC
data/pg/FSM/CommonFieldsConfig.JSON
Create UrcConfig.json to enable URC feature
data/pg/angul/FSM/UrcConfig.json
Enabling overRide for tripAmount
data/pg/FSM/Config.json
Added GP data for specific ulb
data/pg/ulb-name/egov-location/boundary-data.json
Create UrcConfig.json and add GP data for all the ULBs for which the URC feature needs to be enabled.
Created two adaptors for Garima:
1. Create API
- The adapter calls the UMC API to create records and generate the unique garima ID.
2. Search API
- Get a response from the UMC API based on the search criteria.
Changes made in the FSM Update API
When we update the FSM application, we create a record of Garima in the DIGIT system simultaneously which uses the individual service to create an individual record in the DIGIT database.
Accordingly, one needs to set up the individual service for Garima.
https://github.com/egovernments/DIGIT-DevOps/commit/0af62303dd48d944c988a2b1fb2e772c5df61b3d
Feature
Service Name
Changes
Garima
FSM
FSM
egovio/fsm:FSM1.3Impl-sujog-Odisha-handover-pqm-4f16b9e968-176
egovio/fsm-db:FSM1.3Impl-sujog-Odisha-handover-pqm-4f16b9e968-176
Individual
egovio/individual-db:sujog-individual-d13a5d35fb-199
egovio/individual:sujog-individual-d13a5d35fb-199
Digit-ui
egovio/digit-ui:FSM-Sujog-40157ab-325
FSM
/fsm/v1/_update
/fsm/v1/_searchGarimaWorker
/fsm/v1/_createGarimaWorker
Individual
/individual/v1/_create
/individual/v1/_search
UMC
api/egov/sanitation-worker/search
/api/v1/egov/sanitation-worker/capture
Create a Garima folder in web\micro-ui-internals\packages\modules\fsm\src\pages\employee
Add the following code.
https://github.com/egovernments/digit-ui/blob/900f784b813f0e733ee0b9eae162759345248d42/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/GarimaDetails/index.js#L1C1-L200C30
Add the required Garima custom components and register them.
https://github.com/egovernments/digit-ui/blob/900f784b813f0e733ee0b9eae162759345248d42/web/micro-ui-internals/packages/modules/fsm/src/pageComponents/GarimaPersonalDetails.js#L1C1-L199C38
Register the above custom page components:
Add the redirection URL for the "Add vehicle" action option:
https://github.com/egovernments/digit-ui/commit/900f784b813f0e733ee0b9eae162759345248d42
Add the necessary Garima hooks call:
The following localisations need to be added:
The urban-rural convergence is an initiative that aims to ensure access of sanitation services to all Gram Panchayats(GPs) via Urban Local Bodies (ULBs) located closest to them.
As a ULB employee, They are creating applications to cater the sanitation needs of local communities in Urban areas. The same way they should also cater the same sanitation needs to rural bodies which are nearby to that urban region.
They need a provision into a system while creating a new application to either choose local municipalities or urban supported villages.
Based on their choice they would be able to select either locality/mohalla or Gram Panchayat(GP) area from the respective master data drop down list.
The caveat here is if an ULB employee chooses GP then the trip amount field should be an editable field where he/she can fill any logical amount based on their own offline calculation instead of auto calculated amount that is already there in an application in case of Urban bodies.
ULB employees or DSO Operation should also be able to edit the no. of trips and the final amount should be multiple of the initial amount entered into an application with no. of trips.
Need to update mdms data: boundary-data.json
Need to add a new children hierarchy for GP under City which will be parallel to Locality. A sample MDMS is attached below in this document.
By Default “Urban” option will be pre-selected in the radio button in the above wireframe and the drop-down will have the locality/mohalla master data. In case if employee selects “ULB supported village” then the locality/mohalla dropdown will be replaced by GPs and Village drop-down data on the fly.
System will use the below URL to fetch the localities or GPs and their corresponding villages.
In the case of localities, need to pass boundaryType as “Locality”.
https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=Locality&tenantId=pb.amritsar
In the case of GP/villages, need to pass the boundaryType as “GP”.
https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=GP&tenantId=pb.amritsar
Introduction of a new string column (boundary_type) in the FSM_APPLICATION table to capture (Locality or GP) to determine if the application created is for RURAL or not so that in the near future it will be helpful for the analytics and statistics in Dashboards.
Default value for this column will be Locality to support backward compatibility
Add Vehicle log would also have the option to select Urban (Default option) or Rural. If Rural gets selected the text name of an element would be replaced from “Locality” to “Gram Panchayat” for a text field.
Introduction of a new column of string type (boundary_type) in vehicle_trip table to capture if the vehicle log is created for GP or not.
Default value for this column will be Locality to support backward compatibility.
Sample MDMS
boundary-data.json
UrcConfig.json
To enable URC feature in UI
We are keeping the Locality hierarchy under the City as it is [No change there]. And the ‘location api’ with boundaryType as “Locality” will be used the same way it's being called currently to get the localities. Below are the api details: https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=Locality&tenantId=pb.amritsar Response:
To get a List of Gram Panchayats and corresponding villages, we will pass boundaryType as “GP”. Below are the api details: https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=GP&tenantId=pb.amritsar
Table Name
Column Name
Comments
eg_fsm_application
boundarytype
to capture (Locality or GP) in order to determine if the application created is for RURAL or not based on the radio button selection
eg_fsm_address
additionaldetails.gramPanchayat
To store the selected GP while creating an application.
eg_fsm_address
additionaldetails.village
To store the selected village while creating an application.
eg_vehicle_trip
boundarytype
to capture (Locality or GP) if the vehicle log is created for GP or not.
To analyze the impact, we deployed a different module(property tax) which is also pointing to same boundary-data mdms.
Expectation:
For FSM Module: Non-URC flow : Locality dropdown should show all the localities as it is. [There should be no impact] URC flow : GramPanchayat and Village dropdown should show as per new GP and village added to the MDMS.
For Property Tax Module: Locality dropdown should show all the localities as it is. [There should be no impact]
Property Tax Screen
The locality dropdown in Property tax is displaying the values from existing location hierarchy itself. NO IMPACT.
SUJOG FSM (NON-URC)
In FSM, for non-URC the locality dropdown is showing values from the existing hierarchy itself. [NO IMPACT]
SUJOG FSM (URC)
GP Dropdown In case of FSM(URC), the grampanchayat and village dropdown are showing values from the new hierarchy we have configured in the existing mdms.
Village Dropdown
Pricing
Pricing per trip will be entered by “ULB employees” for each request
ULB employee will have a free text entry field to enter price for a request.
In FSTP,there are two scenerios -
Selects a Gram panchayat from drop down but village is not in the list. In this case, Selects other in village and a free text field appears.
Selects 'other' in GP list. In this case, 2 free text fields appear - one for GP and one for Village.
If the locality or GP is located outside the city,then select “Outside ULB Limits” and provide Locality / Grama Panchayat name in text field.
In the dashboard, add the following chart:
Add pie chart: Applications by Source
Pie Chart Value: Ratio of Applications from GP: Ratio of requests from Urban Areas
Add toggle for Applications and Sludge
Pie Chart Value: Ratio of Sludge Disposed from GP: Ratio of Sludge from Urban Areas
Tooltip: Show Total Applications and Total Sludge (See design). Tooltip value to be responsive to toggle between Unit, Lac and Crore
Chart should filter basis time period, district, ulb (dashboard filters)
Add Bar chart: No. of applications per month from Gram Panchayat
Bar Chat Value: Total Number of applications from Gram Panchayat
Add toggle for Applications and Sludge Disposed
Tooltip: Show Total Applications and Total Sludge (See design). Tooltip value to be responsive to toggle between Unit, Lac and Crore
Chart should filter basis time period, district, ulb (dashboard filters)
REFERENCE DOCS :
https://drive.google.com/drive/folders/1kXiz2-95M1raWNujmGAshI2okYvwMtUg?usp=drive_link
Urban local body (ULB) officials/employees are responsible for ensuring that regular treatment quality tests are performed at plants. In certain cases, the ULB officials/employees or third-party agencies such as the Pollution Control Board may perform independent tests. In case of non-compliance with treatment quality standards, the ULB officials/employees are to ensure that corrective actions are promptly taken.
Based on the role and responsibilities of the ULB official/employee, the following functionalities are available:
View Test Schedule: Based on the frequency of testing that is configured on the backend, the system generates a testing schedule. ULB officials/employees can view the upcoming tests for all plants tagged to the ULB.
View Past Test Results: A digital record of all the past test results uploaded on the platform can be accessed. Sort and filter functionalities make it easy to view all the test results.
Record Test Result: In case adhoc tests are conducted, employees have a provision to record the test results. Adhoc test results will also be available to view in the past test results section.
Employee login credentials (login ID and password) can be created for employees via the HRMS. Using this, the employees can sign in.
The user can perform the following actions:
Login by entering a username and password, and selecting the city.
Use the "Forgot Password" link to reset password.
After Logging in, the user will land on the home screen which contains a card with links to actions that can be performed by the user.
The "Treatment Quality" card contains the following:
Count of the total pending tests.
Inbox to view the upcoming tests.
View past test results.
Add test result.
Notifications: The notification panel displays the following:
Tests that are overdue for >7 days.
Failed tests where test results are not as per the parameter.
The user can view the details of the test by clicking on the “View Details” button. The user can dismiss the notification by clicking on the cross button.
The inbox link will redirect the user to the list of upcoming tests for plants tagged to the ULB.
View the list of upcoming tests: The list of upcoming tests will be sorted by the pending date, where the test with the highest SLA is displayed first. The user can sort the list by clicking on the table headers.
Filter tests: Filters are displayed on the left-hand panel of the screen. The following filters are available:
Treatment process: This will be multi-select showing values for the treatment processes configured for the ULB.
Stages: This will be a dropdown showing values for stages configured for the plant.
Status: This will be a multi-select showing the value for the status in the treatment quality workflow.
Selected filters can be removed by clicking on the refresh button on the top right hand corner of the filter pane or the clear button. Sort: Tests can be sorted by the pending date by clicking on the date column.
Search:
Tests can be searched using the following:
Test ID
Plant name
Users can fill either test ID or plant or both and click on the search button.
Users can clear search by clicking on the "Clear Search’"
The user can redirect to the home screen by using the breadcrumbs or the back button of the browser.
A test details page can be accessed by clicking on the "Test ID" hyperlink in the inbox.
This will show details about the upcoming test.
The past test results can be viewed from the TQM landing page and clicking on "View Past Results".
On clicking on "View Past Results", the user is redirected to the list of past tests.
The user can perform the following tasks:
View the list of past tests: The results will be sorted on the test date.
View test details: The user can view test details by clicking on the “Test ID” link in each row.
Search tests: The user can search based on the following:
Test ID:
Plant Name.
Treatment process
Test type
Date range
To clear search and view all past tests, the user can click on 'Clear'.
Sort: Tests can be sorted by the pending date by clicking on the date column.
Download test results in Excel and PDF formats using the download button.
On clicking on any "Test ID" hyperlink, the user will be redirected to the test details page. The test details page will display the summary of the submitted test along with the timelines/workflow.
A user can record test results by clicking on the “Add Test Result” link on the treatment quality card.
Clicking on the “Add Test Result” button will redirect the user to the “Add Test Result” page.
The user has to enter the below fields:
Plant Name
Treatment Process
Treatment Stage
Output Type
Quality Parameters: Based on the selections for the above, the parameters to be tested are populated in the form. At Least one parameter needs to be filled in for the submit button to be enabled. If no parameter is filled and the user clicks on the submit button, an error message is displayed saying “At Least one parameter needs to be filled to Add Test Result”.
Attachments, if any.
Once the user clicks on the ‘Submit’ button, the test results page is displayed.
Based on the benchmarks for an acceptable range of parameters defined, the user will be able to view whether the test overall and each parameter has passed or failed.
The treatment plant operator is responsible for ensuring that the treatment quality for the plant is as per benchmarks. For this, treatment quality tests need to be performed regularly and any deviations in quality need to be corrected immediately.
The treatment plant operator has the following functionalities:
View the list of upcoming tests: Based on the frequency of testing that is configured on the backend, a testing schedule is generated for the plant. The plant operator can receive timely reminders and can view overdue and upcoming tests.
View test details: Details of upcoming tests can be accessed to verify outputs, parameters, and test due dates.
Update the test status and results: Test status and results against a scheduled test can be updated.
View past test results: A digital record of all past test results uploaded on the platform can be accessed. Sort and filter functionalities make it easy to view all the test results.
Treatment plant operator credentials (login ID and password) can be created for employees via the HRMS. Using this, the treatment plant operator can sign in.
On this page, the following actions can be performed:
Enter username and password.
Select the city for login.
Reset password by clicking on the “Forgot Password” link.
Home Page
The user will land on the home page post-login. The user can perform the following actions:
User Actions
Access treatment quality module (Update test status and results).
Switch between the plants.
Users can view the List of pending tasks: This will show the list of tests pending within the next [X] days. A button for “View All Pending Tasks” will be displayed which will redirect the user to “All Pending Tasks”.
Other actions such as an inbox to view the incoming vehicles for disposal and record incoming vehicles will be available here, based on the functionality assigned.
On clicking on the treatment quality card, the user is redirected to the TQM home page. The user can perform the following actions:
User Actions:
View and take action on upcoming tests using the inbox. The inbox will show a count of upcoming tests beside it.
Past test results: Past test results submitted for the plant can be viewed here.
View performance: This widget shows the performance of the plant in regards to treatment quality and will display the following KPIs:
Test compliance: Compliance percentage of plant with regards to the treatment quality
Percentage of test results passed - The total test results passed/the total test results submitted (for the past 30 days).
Count of alerts raised in the past 30 days.
Distribution of alerts based on the alert category.
Go back to the Landing page using the ‘Back’ button.
Access Help
A help button is available for the user to get a guided view of the page. This is available on every page.
View List of Upcoming Tests
On clicking on the inbox link the user is redirected to the list of upcoming tests. This will show only a list of tests to be completed and updated by the Treatment Plant operator.
How is the schedule generated?
A scheduler runs for every ‘X’ days and new tests are generated within the treatment plant operator’s login.
Workflow for Treatment Quality Tests
There are 2 statuses:
Update Status
Update Results
Update Status : When the tests are scheduled and pending for status update, the status of the test is 'Scheduled'.
Update Results : Once the status of the tests are updated , the status of the tests will change to “Pending Result”, that is, waiting for the results to be updated.
User Actions
The total count of upcoming tests is displayed beside the inbox.
View the list of upcoming tests. The following fields will be displayed:
Test ID.
Treatment process
Stage
Output type
Pending date
Status
SLA
Filter tests: On clicking on the filter icon, a pop-up will be displayed. The following filters are available:
Treatment process: The dropdown shows the values for treatment processes configured for the plant. The selected treatment process is displayed here on selection. If not, the field is left blank.
Output type: The dropdown shows values for output types configured for the plant. The selected output type is displayed here on selection. If not, the field is left blank.
Status: The dropdown shows values for the status in the treatment quality workflow. The selected status is displayed here on selection. If not, the field is left blank.
Date range: Selection of date range (calendar view): The selected date range is displayed here on selection. If not, the field is left blank.
On selecting values for the filters above, the user can click on search to filter the inbox.
To clear filters, the user can click on 'Clear'.
To close the pop-up, a user can click on the cross in the top right hand corner of the screen.
Sort: On clicking on sort, a pop-up will be displayed:
Tests can be sorted by the pending date:
Date (Latest First)
Date (Latest Last)
On selecting values for the sort above, the user can click on sort to sort the inbox.
To clear sort, a user can click on clear all.
To close the pop-up, a user can click on the cross in the top right hand corner of the screen.
View Test Details
The test details can be viewed by the user in two ways:
Via the pending tasks.
Via the inbox.
View Test Details Via Pending Tasks
The list of pending tasks can be accessed via the landing page for TQM. This will show the list of tests pending within the next 7 days.
This will show tests in both workflow stages:
Submit Sample
Update Results
Based on the workflow stage, the action for the user will be displayed.
On clicking the “Submit Sample/Update Results” button, the user will be redirected to the test details page.
View Test Details Via Inbox
For test results in the scheduled stage, the "Update status" button will be displayed.
For tests in the pending results stage, the "Update results" button will be displayed.
Update Test Details
On clicking on the "Update Status", the user will be redirected to the test details page.
The test details page will consist of 2 cards.
The first card will display the following fields:
Test ID
Treatment Process
Stage
Output Type
Pending Date
Status
Parameters to be tested along with their unit of measurement
SLA (This will be displayed in red/green based on the SLA. If today>pending date, this is red, If today<pending date, then it is green).
The second card will be based on the test status:
For status tests ‘Scheduled’, the user will be asked to ‘Select a lab’
For status tests “Pending Results”, the user will be asked to "Add test results".
The user can :
Update parameter readings (mandatory fields): Only numerical values can be entered.
Attach documents (non-mandatory).
Submit test results by clicking on the ‘Submit’ button. The button will be deactivated unless all values have been updated. On clicking the submit button, a pop-up will be displayed to the user to confirm submission.
The user can confirm submission by clicking on the ‘Submit’ button.
The user can go back to the test details page by clicking on the “Go back” button.
On submission, the system displays the lab results submitted successfully along with the test ID
The user can see the summary of the test results and whether it has passed/failed based on a comparison between the values entered by the user and the benchmarks.
In case all values are as per the benchmarks, the test results will be displayed as ‘Pass’. All values will be shown in green, and the user receives feedback that all results are as per the benchmarks.
Verifying against benchmarks and Pass/Fail. The status of the test depends on benchmarks that are pre-defined.
In case one or more values are not as per the benchmarks, the test results will be displayed as ‘Fail’. All values as per the benchmarks will be shown in green. Values not as per the benchmarks will be shown in red. The user is provided with information that the test results are not as per the benchmark.
The user can go back to the home page by clicking on the ‘Back’ button.
View Past Test Results
Past test results can be viewed via the TQM landing page and by clicking on "View Past Results’"
On clicking on the past tests, the user is redirected to the list of the past tests.
User Actions :
View the list of past tests . Details of tge past tests can accessed by clicking on the "View Results".
Filter and sort test.
From the FSM card in the home screen, there is a link to the "FSM Registry". FSM admins have access to manage the FSM Registry.
The FSM Registry is multi-tabbed search screen.
Using the FSM Registry, FSM admins can manage vehicles, vendors, and sanitation workers in the system.
There are three tabs available, that is, Vendor, Vehicle, Sanitation Worker.
Vendor and vehicle were already there in FSM 1.3. The Sanitation Worker tab have now been added.
This tab shows a list of sanitation workers in the system.
Admins can search for sanitation workers with the sanitation worker ID, name, and mobile number.
Clicking on a particular ID takes the user to the sanitation worker details page.
Admins can disable/enable sanitation workers.
There is a vendor dropdown available to each sanitation worker which shows a list of vendors that they can be tagged to. An admin can tag a sanitation worker to a vendor using that dropdown.
Vendors are listed based on agency type. Currently, there are two types of agency: ULB and private vendor.
If a sanitation worker is employed by the ULB, then the dropdown will show vendors whose agency type is ULB, and likewise for private vendors.
The employer selection of a sanitation worker can be done while creating a sanitation worker.
We are using the individual registry to create, update, and disable sanitation workers.
If an admin disables a sanitation worker already tagged to a vendor, then that vendor tagging is also disabled. This implies that the if an admin enables that user, we need to tag the vendor again.
There is an 'Add' option at the top right of this screen using which admins can create vehicle, vendor, and sanitation worker.
Note: There is a SANITATION_WORKER role in the system. All sanitation workers created through the system will have this role.
We will hit hit the individual search API to get a list of sanitation workers using the SANITATION_WORKER system role.
The curl is given below:
We will hit the "vendor/v1/_search" endpoint to get a list of vendors.
The curl is given below:
We will hit the "/vendor/v1/_update" to update tagging of sanitation workers to vendors.
The curl is given below:
We will utilise the individual update API for disabling/enabling sanitation workers.
The curl is given below:
Role-action mapping is done for the above mentioned API endpoints for FSM admin users with the following role code:
There are three main updates in FSM v1.2.1 for employee UI:
Application timeline
Photo viewed by employee/DSO
Payment mode while completing request
An employee can see the application status in application timeline with provider details.
The path for the code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/index.js
The code snippet to render application timeline:
The code snippet for extracting the provider info for each status:
An employee/DSO can view the photo uploaded by the employee/DSO in complete request action.
The path for the code:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/index.js
The code snippets to render the field:
ViewImages.js are the common component used to fetch and render the Image file id. The path is shown below:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/components/ViewImages.js
An employee has to select the payment mode while completing the request.
File path:
frontend/micro-ui/web/micro-ui-internals/packages/modules/fsm/src/pages/employee/ApplicationDetails/config/CompleteApplication.js
The code snippet to render the field.
MDMS file fetch for payment mode:
Workbench Setup
For the loading of data, the following will be required:
State-level user for workbench (to allow for loading of state data).
Urban local body (ULB)-level users for workbench (to allow for loading of ULB-specific data). One user for the workbench with access to all ULBs can also be created and the user can navigate across the ULB to upload data for each ULB
ULB employees are provided with credentials to log in to the system. Role-based access for various steps in the workflow, that is, different individuals can be assigned to create an application, modify applications, or manage vendor, driver, and vehicle details.
User actions
On this page, the following actions can be performed:
Enter username and password.
Select a city for login.
Reset your password by clicking on the “Forgot Password” link.
On clicking continue, employees are redirected to the Workbench home page
For the proper working of the platform, the following benchmark rules should be configured. If any other benchmark rules are configured, the system will not function:
Inbox
Click on “Add Master Data” to add a new benchmark rule
Inbox
Click on “Add Master Data” to create new a Quality Test Lab
Inbox
Click on “Add Master Data” to create new a material
Inbox
Click on “Add Master Data” to create a new parameter
Inbox
Click on “Add Master Data” to create a plant configuration
Inbox
Click on “Add Master Date” to create a plant type
Inbox
Click on “Add Master Data” to create a new process type
Inbox
Click on “Add Master Data” to create a new unit
Inbox
Click on “Add Master Data” to create new Waste Type
Inbox
Click on “Add Master Data” to create a new source type
Inbox
Click on “Add Master Data” to add a new stage
Inbox
Click on “Add Master Data” to create a new process
Once the plant is created, the plant user mapping has to be done through the backend. If there is already an FSM instance created and running, then the V1 of codes for plant and ULB has to be taken for V2 and the backend team will have to create the plants using the same codes.
Inbox
Click on “Add Master Data” to add a new plant
Inbox
Click on “Add Master Data” to add a new quality criteria
Inbox
Click on “Add Master Data” to add a new test standard
The user will land on the home page post login. The following actions can be performed by the user:
The plant name is visible on the top right hand corner of the screen.
A help button is available for the user to get a guided view of the page. This is available on every page.
Cards are viewable for the following modules:
a. Vehicle log module (record incoming vehicles)
b. Treatment quality module
c. View dashboard
Clicking on each of these cards will take the user to the Homepage for the specific module.
List of pending tasks: This will show the list of tests pending within the next [X] days. The next action item in the task workflow will be displayed beside a pending task for a user to take prompt action. A button for “View All Pending Tasks” will be displayed which will redirect the user to “All Pending Tasks”.
On clicking on the treatment quality card, the user is redirected to the TQM home page. The following actions can be performed by the user:
View and take action on upcoming tests using the inbox. The inbox will show a count of upcoming tests beside it.
View past test results: Past results from both lab and IoT devices will be displayed here.
View IoT readings: The user can access the record of IoT readings here.
Sensor Monitoring: The user can access a list of IoT devices along with their status here.
View dashboard: The user will be directed to the treatment quality dashboard.
View performance: This widget will show the performance of the plant in regards to treatment quality and will display the following KPIs:
a. Test compliance: Compliance percentage of plant with regards to the treatment quality and its comparison to state level compliance percentage.
b. Last treatment quality result - Pass/fail and date of the test.
c. Count of alerts raised in the past 30 days.
d. Distribution of alerts based on the alert category.
Go back to the Landing page using the back button.
A help button is available for the user to get a guided view of the page. This is available on every page.
View List of Upcoming Tests
On clicking on inbox, the user is redirected to the list of upcoming tests. This will show only a list of lab tests. The user can perform the following tasks:
Total count of upcoming tests are displayed beside the inbox in brackets.
View list of upcoming tests. The following will be the fields displayed:
Total count of upcoming tests are displayed beside the inbox in brackets.
View list of upcoming tests. The following will be the fields displayed:
a. Test ID.
b. Treatment process (in case there is only 1 treatment process for the plant, this field will not be displayed).
c. Stage: This will display the process stage where the sample is to be collected from.
d. Output type: Biosolids/effluents.
e. Pending date: This is the test date as per schedule.
f. Status: status of the test.
g. SLA: Show difference between test due date and today.
An action item available based on the next status in the workflow will be displayed:
a. For test results in the scheduled stage, update status will be displayed.
b. For tests in the pending results stage, update results will be displayed.
Filter tests: On clicking on filter, a pop-up will be displayed:
a. The following filters are available:
Treatment process: (In case there is only 1 treatment process for the plant, this field will not be displayed). This will be a dropdown showing the values for treatment processes configured for the plant. The selected treatment process is displayed here on selection. If not, the field is left blank.
Output type: This will be a dropdown showing values for output types configured for the plant. The selected output type is displayed here on selection. If not, the field is left blank.
Status: This will be a dropdown showing values for the status in the treatment quality workflow. The selected status is displayed here on selection. If not, the field is left blank.
Date range: Selection of date range (calendar view): Selected date range is displayed here on selection. If not, the field is left blank.
b. On selecting values for the filters above, a user can click on filter to filter the inbox.
c. To clear filters, a user can click on clear all.
d. To close the pop-up, a user can click on the cross on the top right hand corner of the screen.
Sort: On clicking on sort, a pop-up will be displayed:
a. Tests can be sorted by the pending date:
Date (Latest first)
Date (Latest Last)
b. On selecting values for sort above, the user can click on sort to sort the inbox.
c. To clear sort, a user can click on clear all.
d. To close the pop-up, a user can click on the cross on the top right hand corner of the screen.
Go back to the landing page using the back button.
A help button is available for the user to get a guided view of the page. This is available on every page.
View Test Details
Test Details can be viewed by the user in 2 ways:
Via the pending tasks.
Via inbox.
View Test Details Via Pending Tasks
The list of pending tasks can be accessed via the landing page for TQM. This will show the list of tests pending within the next [X] days.
The next action item in the task workflow will be displayed as a button beside a pending task for a user to take prompt action. On clicking on the button, the user will be redirected to the test details page.
View Test Details Via Inbox
A list of tests can be accessed on the inbox. An action item is available based on the next status in the workflow will be displayed:
For test results in the scheduled stage, the update status will be displayed.
For tests in the pending results stage, the update results will be displayed.
On clicking on the action item, the user will be redirected to the test details page.
The test details page will consist of 2 cards:
The first card will display the following fields:
Test ID
Treatment Process
Stage
Output Type
Pending Date
Status
Parameters to be tested along with their unit of measurement
SLA (This will be displayed in Red/green basis SLA. If today>Pending date, this is red, If today<pending date, then green).
The second card will be based on the test status:
For tests in status ‘Scheduled’, the user will be asked to select a lab.
For tests in status “Pending Results”, the user will be asked to add test results
The user can go back using the back button - The redirection will be based on the page the user has accessed the test details page from. A help button is available for the user to get a guided view of the page. This is available on every page.
Update Tests
Tests can be updated by the user from the test details page. The test details page will display the next action item for the user based on the workflow test. For tests with the wWorkflow status ‘Scheduled’, the user will be prompted to confirm if sample has been submitted to the lab for testing.
The user can perform the following actions:
Select a lab from a dropdown list configured in the MDMS.
Update status of the test. The button will be deactivated if Lab is not selected, and will only be activated once selection is made. Once the user clicks on update status, he/she is redirected back to the page from which test details were accessed and a snack bar confirms the status update and the action Item button shows updated next step.
In case an update of status fails, the user will remain on the same page and a failure message will be displayed to the user.
For tests with the workflow status “Pending Status”, the user will be prompted to fill test results.
The user can perform the following actions:
Update parameter readings (mandatory fields) The following validations will be applied:
a. Only numerical values will be viewable here. In case of non numerical values, the following error message is displayed “Only numeric values allowed. Please input in the required format”.
Attach documents (non-mandatory): The following validations will be applied:
a. Only files in the following formats will be supported: .png, .jpg. .pdf. In case a file of unsupported format is selected, the following error will be displayed “The file type is not supported. Please upload in the following formats: .pdf, .png, .jpg”.
b. File size of maximum X mb allowed. In case file size is larger than permitted value, the following error will be displayed “The file size is too large. Please upload a file below x mbs”.
Submit test results by clicking on the ‘Submit’ button. The button will be deactivated if all is not selected, and will only be activated once selection is made. On clicking the submit button, a pop-up will be displayed to the user to confirm submission.
The following actions will be made available to the user:
Confirm submission by clicking on the ‘Submit’ button.
Go back to the test details page by clicking on the “Go back” button.
On clicking the submit button and failure to submit test results, the user will remain on the same page and a failure message will be displayed.
On clicking the submit button and successful submission of the test results, the user will be redirected to the summary page and a snack bar will confirm the submission.
At this stage, the user will be displayed the summary of test results and whether it has passed/failed based on a comparison between the values entered by the user and the benchmarks. In case all values are as per the benchmarks, the test results will be displayed as ‘Pass’. All values will be shown in green and the user receives feedback that all results are as per benchmarks. The user can go back to the home page by clicking on the ‘Back’ button.
In case one or more values are not as per the benchmarks, the test results will be displayed as ‘Fail’. All values as per benchmarks will be shown in green. Values not as per the benchmarks are shown in red. The user is provided with information that the test results are not as per benchmark. The user can go back to the Home page by clicking on the ‘Back’ button.
View Past Test Results
Past test results (both IoT and Lab) can be viewed via the TQM landing page and by clicking on past tests.
On clicking on past tests, the user is redirected to the list of past tests.
The user can perform the following tasks:
View the list of past tests. The following will be the fields displayed:
a. Test ID.
b. Treatment process (in case there is only 1 treatment process for the plant, this field will not be displayed).
c. Stage: This will display the process stage where the sample is to be collected from.
d. Output type: Biosolids/effluents
e. Pending date: This is the test date as per schedule.
f. Test result: Pass/fail.
2. View test details: The user can view test details by clicking on “View Results” button on each card.
Filter tests: On clicking on Filter, a pop-up will be displayed. The following filters are available:
i. Treatment process: (in case there is only 1 treatment process for the plant, this field will not be displayed). This will be a dropdown showing values for Treatment Processes configured for the plant. The selected treatment process is displayed here on selection. If not, the field is left blank.
ii. Output type: This will be a dropdown showing values for the output types configured for the plant. The selected output type is displayed here on selection. If not, the field is left blank.
iii. Test type: This will be a dropdown showing values for the test type (IoT/Lab). The selected test type is displayed here on selection. If not, the field is left blank.
iv. Date range: The selection of date range (calendar view) - The selected date range is displayed here on selection. If not, the field is left blank.
On selecting values for filters above, the user can click on filter to filter the inbox. To clear filters, the user can click on clear all. To close the pop-up, a user can click on the cross on the top right hand corner of the screen. On selection of the filter, the selected filter is displayed on the screen. On clicking the cross button near the displayed filter, the filter is removed.
Sort: On clicking on sort, a pop-up will be displayed:
a. Tests can be sorted by the pending date:
Date (Latest first)
Date (Latest last)
b. On selecting values for sort above, the user can click on sort to sort the inbox.
c. To clear sort, the user can click on clear all.
d. To close the pop-up, the user can click on the cross on the top right hand corner of the screen.
In case filters/sort/search is applied and the user navigates to the test details page, on going back, the values of the filters/sort/search should remain the same.
The user can download the list of tests, filtered by selection in Excel and PDF format.
Go back to the Landing page using the back button.
A help button is available for the user to get a guided view of the page. This is available on every page.
On clicking the “View Results” button, the user will be redirected to the test summary page.
The page will have 2 cards:
The first card will display the following fields:
Test ID.
Treatment Process.
Stage.
Output Type.
Test Type.
Lab Name/Device ID: This will show Lab Name/Device ID based on the Test type.
Test submitted on.
Test Results: Pass/Fail.
The second card will display the following fields:
Parameters, their unit of measurement and the values of the parameters recorded. The values will be read/green basis whether they are as per benchmarks or not.
The user can go back to the list of tests by clicking on the ‘Back’ button, both on the top and bottom of the page.
View IoT Readings
IoT readings can be viewed via the TQM landing page and clicking on view IoT readings.
On clicking on View IoT readings, the user is redirected to the view tests page filter on test type: IoT.
The functionality of the page remains the same as the “View Past Tests” page.
Sensor Monitoring
Sensor monitoring can be accessed by clicking on the sensor monitoring link on the TQM landing page.
On clicking on sensor monitoring, the list of IoT devices are displayed.
The following details are displayed on the page:
Total number of IoT devices is displayed beside the page heading in brackets.
A card is available for each device. The following details will be displayed:
- Device ID.
- Treatment Process.
- Stage.
- Output Type.
- Last Calibrated Date.
- Device Status.
- Verification Status.
- Last Verification Date.
- Parameters that the device monitors.
The user can perform the following actions:
Filter devices: On clicking on filter, a pop-up will be displayed.
a. The following filters are available:
i. Treatment process: (in case there is only 1 treatment process for the plant, this field will not be displayed). This will be a dropdown showing values for the treatment processes configured for the plant. The selected treatment process is displayed here on selection. If not, the field is left blank.
ii. Output type: This will be a dropdown showing values for the output types configured for the plant. The selected output type is displayed here on selection. If not, the field is left blank.
iii. Device status: This will be a radio button showing active/inactive
iv. Parameters: This will be a multi-select displaying all parameters configured on the backend.
b. On selecting values for filters above, the user can click on filter to filter the inbox.
c. To clear filters, the user can click on clear all.
d. To close the pop up, the user can click on the cross on the top right hand corner of the screen.
e. On selection of the filter, the selected filter is displayed on the screen. On clicking the cross button near the displayed filter, the filter is removed.
Search: On clicking on search, a pop-up will be displayed.
a. The user can search a device by device ID. Part search to be enabled.
View Dashboard
Dashboards can be accessed by clicking on the “View Dashboards” link on the TQM landing page.
Navigation:
On landing on the dashboard, the user can navigate across the treatment process types to view the dashboard specific to the treatment process type.
Filter:
Date range: Users should be able to filter based on the date range basis which dashboard is to be filtered.
Other functionalities:
Share:
Users should be able to share a filtered dashboard over WhatsApp in an image format.
Users should be able to share filtered charts/tables over WhatsApp in an image format.
Download:
Users should be able to download the filtered dashboard in PDF and image formats.
Users should be able to download filtered charts/tables in PDF and image formats.
Metrics:
Total incoming sludge: The sum of the total sludge that is disposed of at the plant for the selected time period.
Number of trips: A count of the total incoming vehicles at the treatment plant for the selected time period.
Overall quality: The number of tests where all parameters are as per the benchmarks as compared to the total number of test results recorded.
Compliance percentage: The percentage of tests where results have been recorded.
Total alerts: A count of the total alerts raised of the following types: Test results not as per the benchmark, no reading from the IoT device, and lab results and IoT results not matching.
Treatment Quality Overview:
KPIs:
Total tests - A count of the total tests for the filtered date range.
A count of tests that have passed treatment quality.
A count of tests that have failed the treatment quality.
Table:
Heading - Name of the plant.
Table displaying the following fields:
a. Stage, output type, value of parameters, and compliance percentage.
b. Button to view the trends for a particular stage.
Toggle to toggle between IoT readings and lab results.
Trends of parameter readings:
This chart will be available once the user clicks on the view trend button in the table button.
The table shows the trend for one parameter over time, and provides a view of the benchmark for comparison. A toggle is available to navigate between the parameters. Detailed metric details for the Treatment Quality Monitoring dashboard are viewable below:
A card for Treatment Quality Monitoring will be made available on the landing page of the employee.
The treatment quality contain the following:
a. An overview of the total pending tests and how many are nearing SLA.
b. View upcoming tests using the inbox. The inbox will show a count of upcoming tests beside in brackets.
c. View past test results: Past results from both lab and IoT devices will be displayed here.
d. View IoT readings: The user can access the record of IoT readings here.
e. Sensor monitoring: The user can access a list of IoT devices along with their status here.
f. View dashboard: The user will be directed to the treatment quality dashboard.
Clicking on each of these links will take the user to the specific page.
Notifications: This will show the list of alerts regarding TQM. Currently, this will display the tests that have crossed SLA for greater than 7 days. The user can view the details of the test by clicking on the “View Details” button. The user can dismiss the notification by clicking on the cross button.
Rest of the functionality will remain the same as the current ULB employee landing page.
View List of Upcoming Tests
On clicking on Inbox, the user is redirected to the list of upcoming tests. This will show only a list of lab tests. The user can perform the following tasks:
The total count of upcoming tests are displayed beside the inbox in brackets.
View a list of upcoming tests. The list of upcoming tests will be sorted by the pending date, where the test with the highest SLA is displayed first. The following fields will be displayed:
a. Test ID
b. Plant Name
c. Treatment Process
d. Pending Date: This is the test date as per schedule
e. Status: Status of the test
f. SLA: Show difference between test due date and today. This will be displayed in red if test due date<today and in green if today>test due date.
The user can view test details by clicking on the test ID.
Filter tests: Filters are displayed on the left hand panel of the screen. The following filters are available:
i. Treatment process: This will be multi-select showing values for the treatment processes configured for the ULB. The selected treatment process will be displayed as a tick on the multi-select box. If not, it is left blank.
ii. Stages: This will be a dropdown showing values for stages configured for the plant. The selected stage is displayed here on selection. If not, the field is left blank.
iii. Status: This will be a multi-select showing values for the status in the treatment quality workflow.
On selecting values for filters above, the user can click on filter to filter the inbox. To clear filters, the user can click on the refresh icon on the top right of the filter panel.
Sort: Tests can be sorted by the pending date by clicking on the date column.
Search:
a. Tests can be searched using the following:
i. Test ID.
ii. Plant Name.
b. Part search to be enabled for both.
c. Users can fill either test ID or plant or both and click on the search button.
d. Users can clear search by clicking on the clear search link.
In case filters/sort/search is applied and the user navigates to the test details page, on going back, the values of the filters/sort/search should remain the same.
Redirecting to other links in the TQM module: Users can redirect to other pages in the TQM module via the links provided on the top left of the page. The following links will be displayed:
a. View Past Results
b. View IoT Results
c. Sensor Monitoring
d. View Dashboard
View Test Details
A test details page can be accessed by clicking on the test ID in the inbox. The test details page will consist of the following fields:
The following information will be displayed. In case the information on any field is not available such as the lab name/value against parameters based on the status of the test, the value against the fields will be displayed as “To be Updated”
- Test ID
- Plant Name
- Treatment Process
- Stage
- Output Type
- Test Type
- Test Scheduled on
- Status
- Lab Name
- Sample submitted on
- Test results submitted on
- SLA (This will be displayed in red/green based on the SLA. If today>pending date, this is red, If today<pending date, then green for open tests. For closed tests, SLA will be displayed).
- Table containing the following details:
i. S.No
ii. Parameter
iii. UoM
iv. Benchmark
v. Value Recorded - The value will be displayed in red/green based on comparison to the benchmark
vi. Overall Test results - Pass/Fail
- Attached documents, if any. The user should be able to view the document by clicking on the document icon. No icon will be present if documents are not attached.
- Test Timeline
The user can go back using the breadcrumbs of the page.
The user can download the test report by clicking on the 'Download' button.
View Past Test Results
Past test results (both IoT and Lab) can be viewed via the TQM landing page and clicking on past tests.
On clicking on past test results, the user is redirected to the list of past tests.
The user can perform the following tasks:
View the list of past tests. The results will be sorted on the test date. The following will be the fields displayed:
a. Test ID
b. Plant
c. Treatment Process (in case the there is only 1 treatment process for the plant, this field will not be displayed).
d. Test Type
e. Test Date: This is the date the test results are updated
f. Test Result: Pass/Fail
View test details: The user can view test details by clicking on the “Test ID” link in each row.
Search tests: The user can search based on the following:
i Test ID: Input text field, part search should be enabled.
ii. Plant: Dropdown of list of plants in the ULB.
iii. Treatment process: Dropdown of list oftTreatment Process in the ULB.
iv. Test type: This will be a dropdown showing values for the test type (IoT/Lab). The selected test type is displayed here on selection. If not, the field is left blank.
v. Date range: Selection of date range (calendar view): The selected date range is displayed here on selection. If not, the field is left blank.
On selecting values for search above, the user can click on search to filter the inbox. To clear search and view all past tests, the user can click on “Clear Search”.
Sort: Tests can be sorted by the pending date by clicking on the date column.
In case filters/sort/search is applied and the user navigates to the test details page, on going back, the values of the filters/sort/search should remain the same.
Download test results in Excel and PDF formats using the download button.
The user can go back using the breadcrumbs on the top of the page. In case the user has navigated to the test details page from the past test results list, on clicking back, the user should be redirected to the test details page.
On clicking on any test ID button, the user will be redirected to the test details page (same as redirection from the inbox).
View IoT Readings
IoT readings can be viewed via the TQM landing page and clicking on “View IoT Reading”.
On clicking on IoT readings, the user is redirected to the list of past tests, with the search on test type selected as IoT and the results filtered for IoT readings only. All other functionality will remain the same.
Sensor Monitoring
The list of devices can be viewed via the TQM landing page and by clicking on ‘Sensor Monitoring’’.
On clicking on sensor monitoring, the user is redirected to the list of devices.
The user can perform the following:
View total devices: The total number of IoT devices is displayed beside the page heading in brackets.
A row is available for each device. The following details will be displayed:
- Device ID
- Plant
- Treatment Process
- Stage
- Output Type
- Device Status
- Parameters: One or multiple parameters that the device is monitoring.
The user can perform the following actions:
a. Search Devices: On clicking on the filter, a pop up will be displayed. The following filters are available:
Device ID: Part search should be available here.
Plant: Dropdown based on plants configured in the MDMS.
Treatment process: Dropdown-based on the treatment process type.
Stage: Dropdown-based stage of selected treatment process.
Output type: This will be a drop down showing values for Output types configured for the plant.
Device status: Dropdown contains active/Inactive as options.
b. On selecting values for filters above, the user can click on Search to filter the inbox.
c. To clear search, the user can click on clear all.
Record Test Result
Since actors such as PCB might conduct adhoc tests, a provision will be provided to the user to record test results without a schedule. A user can record test results by clicking on the “Add Test Result” link on the card.
Clicking on the “Add Test Result” button will redirect the user to the “Add Test Result” page.
The following fields need to be entered by the user:
Plant Name: This is a dropdown based on the list of plants available in the system. For a state level user, this should display all plants in the state. For a ULB, it should also display the names tagged to the ULB.
Treatment Process: This is a dropdown based on the list of treatment processes in the plant selected.
Treatment Stage: This is a dropdown based on the list of stages in the treatment process selected.
Output Type: This is a dropdown based on the output types available in the stage
Values against parameters. Atlease 1 parameter needs to be filled for the submit button to be enabled. If no parameter is filled and the user clicks on the submit button, an error message is displayed as a snack bar.
Attachments, if any.
Once the user clicks on the Submit button, the test results page is displayed.
This is the same as the “View Test Results” page with the following changes:
TesttType will be displayed as Lab.
Status, lab name and SLA field are not displayed.
Workflow will not be displayed.
The user can go back to the “Add Test Results” page via the breadcrumbs.
The TQM Dashboard will be made available to both the ULB employee and the state employee, and can be accessed by clicking on the dashboard link on the landing page.
On clicking on the dashboard, the user is directed to the dashboard view.
The access to data in the dashboard will be based on the following roles:
ULB admin will be able to view the dashboard for all plants in the ULB.
A state admin will be able to view the dashboard for all plants in the ULB.
Navigation:
On landing on the dashboard, the user can navigate across the treatment process types to view the dashboard specific to the treatment process type.
Filters:
Date range: Users should be able to filter based on the date range.
ULB: Users should be able to filter based on the ULB. For a ULB employee, the ULB is auto-selected to the ULB the plant and employee is tagged to. For a state user, all ULBs are available.
Plant: Users should be able to filter based on the plant. For ULB employees, plants tagged to the ULB to which the employee belongs should be available in the dropdown. For state users, all plants are available.
Other functionalities:
Share:
- Users should be able to share a filtered dashboard over WhatsApp in an image format.
- Users should be able to share filtered charts/tables over WhatsApp in an image format.
Download:
- Users should be able to download the filtered dashboard in PDF and image formats.
- Users should be able to download the filtered charts/tables in PDF and image formats.
Metrics
Overall KPIs:
The dashboard will display the following KPIs:
Total incoming sludge: The sum of the total sludge that is disposed of at the plant for the selected time period.
Number of trips: A count of total incoming vehicles at the treatment plant for the selected time period.
Overall quality: The number of tests where all parameters are as per benchmarks as compared to the total number of test results recorded.
Compliance percentage: The percentage of tests where results have been recorded
Total alerts: A Count of total alerts raised of the following types: Test results not as per benchmark, the number reading from IoT device, and lab results and IoT results not matching.
Treatment quality overview:
KPIs:
Total plants - A count of the unique plants for the particular treatment process.
Count of plants who have passed the treatment quality as per the last recorded test.
Count of plants who have failed the treatment quality as per the last recorded test.
Treatment quality is said to have passed if all parameters for final output(s) of a treatment process are as per benchmarks. Treatment quality is said to have failed if 1 or more parameters for final output(s) of a treatment process is not as per benchmarks.
Map:
A map view of the location of each plant will be displayed as part of the dashboard. Plants here will be colour coded, based on whether it has passed/failed the treatment quality. (Red = failed, Green = passed).
Table:
A table will be available to plant-wise details of test results (pass/fail), and the compliance percentage. This will be as per the last test result. The user will also be able to see a change in compliance percentage compared to the last month. A drilldown will be made available for a plant via this table. For TRP users and ULBs, where only 1 plant is tagged for the process type, the drilled table is automatically visible.
On drilldown, the following is viewable to the user:
Heading - Name of plant.
Table displaying the following fields:
a. Stage, output type, value of parameters, and compliance percentage.
b. Button to view the trends for a particular stage.
Toggle to toggle between IoT readings and lab results.The selected test type will appear highlighted.
If there are multiple process flows, then the user can switch between process flows by using the buttons. The selected process flow will appear highlighted.
Trends of parameter readings:
This chart will be available once the user clicks on the view trend button in the table button.
The table shows the trend for one parameter over time and provides a view of the benchmark for comparison. A toggle is available to navigate between parameters.
Chart should have export, share and download options.
Chart should have export, share and download options.
The user can select the lab from the dropdown and click on the "Update Status".
S.No
Section Heading
Chart Heading
Subheading
Definitions (This will appear on the dashboard whenever a user hovers on the metric, wherever applicable).
Chart Type
X-Axis
Y-Axis
Value
Columns
How to calculate
Boundary
Drilldown/Toggle
Comparison KPIs, if any
Show comparison in
Specific to State/ULB/ TRP/all
Tooltip on Hover on Data Point
Input Fields
1
Input
Total incoming sludge
NA
The total incoming sludge from registered and unregistered vehicles.
KPI
NA
NA
Total incoming sludge.
NA
Total incoming sludge = (Volume of waste disposed of for registered vehicles) + (Volume of waste disposed of for unregistered vehicles).
State, Plant ULB
NA
NA
NA
NA
2
Input
Number of incoming trips
NA
The number of trips disposed of at the treatment plant.
KPI
NA
NA
The count of trips to the treatment plant from registered and unregistered vehicles.
NA
Number of trips disposed = Count (Distinct trip ID).
State, Plant ULB
NA
NA
NA
NA
3
Treatment Quality
Overall quality
NA
The percentage of tests where all parameters are as per the benchmarks.
KPI
NA
NA
The percentage of test results meeting the benchmarks.
NA
Overall quality = (Number of tests where all parameters meet benchmarks/ The total number of tests) * 100.
State, Plant ULB
NA
NA
NA
NA
4
Treatment Quality
Compliance
NA
The percentage of tests where results have been recorded.
KPI
NA
NA
The percentage of tests with the status as submitted out of the total tests.
Compliance percentage = (Count of test ID in status 'Submitted'/Count (distinct trip ID) * 100.
State, Plant ULB
NA
NA
NA
NA
5
Alerts
Total alerts
NA
The total alerts raised by the system in the following categories: 1) Test results not as per the benchmark, 2) No reading from the IoT device, 3) Lab results and IoT results not matching.
KPI
NA
NA
Total alerts.
Count (Distinct alert ID).
State, Plant ULB
NA
NA
NA
NA
6
Treatment Quality Plants
Total plants
NA
NA
NA
NA
NA
Count of plants
Count (Distinct plant ID).
State, Plant ULB
NA
NA
NA
NA
7
Treatment Quality Plants
Treatment quality passed
NA
Treatment quality is considered passed if all parameters of both biosolids and effluents are as per the benchmarks for the output of the treatment process in the last test recorded.
NA
NA
NA
The count of plants with treatment quality passed.
Treatment quality for the output type =If(COUNT IF (All parameters meet benchmarks, FALSE) = 0, "Treatment Quality for Output type passed", "Treatment Quality for Output type failed"). Treatment quality for plant passed = =IF(COUNT IF (Treatment quality for output type, FALSE) = 0, " Treatment Quality Passed", "Treatment Quality Failed").
State, Plant ULB
NA
NA
NA
NA
8
Treatment Quality Plants
Treatment quality failed
NA
Treatment quality is considered failed when one or more parameters of biosolids or effluents are not as per the benchmarks for the output of the treatment process in the last test recorded.
NA
NA
NA
The count of plants with treatment quality failed.
Count (Distinct plant ID) - Treatment quality passed.
State, Plant ULB
NA
NA
NA
NA
9
Treatment Quality Plants
NA
NA
NA
Map
NA
NA
Point = Geolocation of plant. Plant icon colour is green if the treatment quality is passed, and red if the treatment quality failed.
Same as 7 and 8
State, Plant ULB
NA
NA
NA
NA
Name of the plant
10
Treatment Quality Plants
NA
NA
NA
Table
NA
NA
NA
Plant Name, Test Result, Compliance %
Test result same as S.No 7 and S.No 8
State, Plant ULB
NA
NA
NA
NA
11
Treatment Quality Plants
NA
NA
NA
Table
NA
NA
NA
Stage, Output Type, Parameters 1...n, Compliance %
Mentioned above
State, Plant ULB
NA
Compliance percentage.
The percentage from the last month.
NA
12
Trend in [Parameter Name] Readings
NA
NA
NA
Multi-line chart
Test dates
Parameter Value
- Value of device reading. - Value of lab results.
NA
NA
Plant
NA
NA
NA
NA
Date Lab result - X Device reading - Y
DIGIT Sanitation is enhanced with a new Product -Treatment Quality Monitoring(TQM). The Treatment Quality Monitoring aims to improve the Treatment Quality of plants by ensuring that timely tests are conducted and any deviations are addressed quickly. To know more about Treatment Quality Monitoring(TQM) , please follow the
Click for Known Issue List.