1 of 100

v1.4

Introducing Water-Sanitation

About Water-Sanitation

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.

Useful Links

Contact Us

Water-Sanitation

Solution Design

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.

Need for Water-Sanitation

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.

Scope

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

Approach

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.

Overview of Faecal Sludge Management

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.

Why FSM matters - It is the way forward in sanitation

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.

Systems Map

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.

Part 1 - Toilets and containment units

Problems faced by key stakeholders

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.

Part 2 - Emptying and transport

Problems faced by key stakeholders

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.

Part 3 - Treatment

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.

Part 4 - Ecosystem

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.

Critical Problems in FSSM

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:

Absence of well-defined standards for sanitation

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.

Broken chain of custody from waste generation to reuse

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

Lack of verifiable, trusted data at various levels

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.

Inability to convert waste to value

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.

Release Notes

Release Summary

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

New ‌Feature Additions

Feature

Description

Enhancements

Feature

Description

Document Resources & Links

UI Technical Documents

Backend Service Documents

Test Cases

QA Test Cases for PQM:

QA Test Cases for Sanitation Worker Welfare:

Localisation

Impel Release Notes

Release Summary

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.

Release Highlights

The functionality included are:

Adding GPs while creating an application.
Make the amount per trip field editable for GPs.

New Feature Additions

Feature

Description

Document Resources and Link

Click to access the backend service document.

Master Migration Document

Overview

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.

Migration Steps

PQM Service

The PQM service is required to create, update, search and evaluate tests against benchmarks. Follow the steps given below:

Add the .
Add the new persister file: .
Add the
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

PQM Scheduler

Add the .
Add the .
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.

PQM Anomaly Finder Service

Add the .
Add the .
Configure the build.

Sanitation Worker Welfare

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 .
Deploy the latest build of individual service refer link#
Migrate all the drivers to individual using

UI Migration Changes

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
Code PRs for referenceL

Driver-Individual Migration Script

Overview

The Driver-Individual Migration Scripts is responsible for fetching all existing drivers in the system and subsequently generating creates corresponding individuals in the system.

Build

The data migration has been implemented in Vendor Service with latest stable build -

API Spec

MDMS Roleaction Mapping

File Path -

Please use FSM_ADMIN credentials for accessing this API.

Water-Sanitation Product Suite

Waste Management System

TQM UI

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:

How to enable TQM UI
UI: Plant operator
UI: ULB admin

How to Enable TQM UI

Enabling TQM module in DIGIT-UI

Overview

To access the TQM module in DIGIT-UI, enable it from MDMS and add TQM specific roles for the user to access TQM UI.

Enabling Module from MDMS

Add the following configuration in citymodule.json under this path in MDMS. The reference file is given below.

Enabling TQM Module from UI

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:

Roles Required to Access TQM UI

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

Recommended Core UI module version

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:

UI: Plant Operator

Screens/Flows involving Plant Operator user

We have mobile-first screens for plant operators

The screens/flows for a plant operator are given below:

Plant operator home page
TQM landing page
Plant-user mapping
Inbox/update tests
View past test results/test's summary screen
Help section

Landing and Home Page

Logging in with the plant operator role will take the user to the landing page.

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.

Home 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.

Plant-User Mapping

Every plant operator created will be linked to one or more plants under an urban local body (ULB).

Plant-User Mapping Flow

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:

Help Section

Help Flow

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:

{
          "TQM": {
              "moduleCode" : "TQM",
              "videosJson":  [
                  {
                      "headerLabel": "TQM_HELP_Q1",
                      "description": "TQM_HELP_Q1_DESC",
                      "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                      "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  },
                  {
                    "headerLabel": "TQM_HELP_Q2",
                    "description": "TQM_HELP_Q2_DESC",
                    "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                    "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  },
                  {
                    "headerLabel": "TQM_HELP_Q3",
                    "description": "TQM_HELP_Q4_DESC",
                    "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                    "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  },
                  {
                    "headerLabel": "TQM_HELP_Q4",
                    "description": "TQM_HELP_Q4_DESC",
                    "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                    "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  },
                  {
                    "headerLabel": "TQM_HELP_Q5",
                    "description": "TQM_HELP_Q5_DESC",
                    "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                    "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  },
                  {
                    "headerLabel": "TQM_HELP_Q6",
                    "description": "TQM_HELP_Q6_DESC",
                    "en_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4",
                    "hi_IN": "https://media.w3.org/2010/05/sintel/trailer.mp4"
                  }
              ],
              "screenHeader":"TQM_HELP_SECTION"
          }
      }

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.

UI: ULB Admin

Screens/Flows involving ULB Admin user

We have Desktop-first Screens for ULB Admin user

The following screens/flows are available for an urban local body (ULB) admin:

ULB admin home page
Inbox/Test summary screen
View past test results/Test summary screen
Create adhoc test

ULB Admin Home Page

Logging in with ULB admin role takes the user to the home page of DIGIT-UI.

Home Page

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).

API Details for TQM

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.

View Past Test Results

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:

Create Adhoc Test

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.

Create Adhoc Test Flow

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.

API Details for Create:

Use pqm-service.
URL for inbox "/pqm-service/v1/_create".
Sample request object:

Sample curl for inbox:

Role-Action Mapping:

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:

Faecal Sludge Management (FSM)

Online solution to desludging operations management

Overview

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.

Benefits to Value-Chain Stakeholders

Features

The current version provides the following features:

Service Request Management (urban and rural)

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.

Transport Management

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.

Billing and Payments

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.

Notifications

Send notifications via SMS.
Send in-app notifications.

Service Delivery Monitoring

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

Sanitation Actors & Interactions

Actor Interaction Mapping

The above diagram illustrates the integration between each actor. A brief description of each role is provided below:

FSM User Manual

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.

Key Features

Apply for desludging services
Make payment for services
Register desludging operators
Update vehicle logs
Manage vendors, vehicles and drivers

User Roles

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.

User Role

Scope of Action

Role Description

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

Using FSM

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.

Citizens
Employees
DSO
SeTPO

Sanitation Worker UI

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:

FSM Registry -> Sanitation Worker Tab
Create Sanitation Worker
Edit Sanitation Worker
Sanitation Worker Details
Assign Sanitation Workers to FSM Applications (Update to existing screen)

Edit Sanitation Worker

From the Screen Admin can search for Sanitation worker and go to it's .

Updating Sanitation Workers

From the , admin can click on "Edit" action
Admin will be redirected to the edit sanitation worker page
This page contains the same form as . 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

API Details

Individual Update

We are hitting Individual Update endpoint "/individual/v1/_update" to update the details of a Sanitation worker
Refer the curl below:

Vendor Update

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

Role action mapping is done for the above 2 endpoints for "FSM_ADMIN" role

FSM UI Docs

This section includes the following:

FSM Citizen UI

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.

Stepper Information

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.

Technical Implementations Details:

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:

Service Request Screen

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.

Technical Implementation Details:

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:

FSM Employee UI

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

1. Application Timeline:

An employee can see the application status in application timeline with provider details.

Technical Implementation 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:

2. Photo viewed by employee/DSO

An employee/DSO can view the photo uploaded by the employee/DSO in complete request action.

Technical Implementation Details:

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

3. Payment mode while completing request

An employee has to select the payment mode while completing the request.

Technical Implementation Details:

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:

egov-mdms-data/ReceivedPaymentType.json at UAT · egovernments/egov-mdms-data

{
    "tenantId": "pg",
    "moduleName": "FSM",
    "ReceivedPaymentType": [
        {
            "name": "Payed in Cash",
            "code": "PAYED_IN_CASH",
            "active": true
        },
        {
            "name": "Payed in Counter",
            "code": "PAYED_IN_COUNTER",
            "active": true
        },
        {
            "name": "Netbanking",
            "code": "NETBANKING",
            "active": true
        }
    ]
}

FSM Technical Specification

Overview

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.

Service Dependencies:

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

API Specification

Data Model

Web Sequence Diagrams

Vehicle Technical Specification

Overview

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.

Service Dependencies:

egov-mdms-service
egov-workflow-v2
user-service
egov-idgen
vendor

API Specification

Data Model

Web Sequence Diagram

Vendor Technical Specification

Overview

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.

Service Dependencies:

egov-mdms-service
egov-user-service
boundary-service
Egov-idgen
egov-workflow-v2
vehicle

API Specification

Data Model

Web Sequence Diagrams

Calculator Technical Specification

Overview

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.

Service Dependencies:

billing-service
mdms-service
workflow-v2
User-service
fsm

API Specification

Data Model

FSM Release Notes

Release Summary

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 .

Functional Changes

Deprecating Driver Registry
Introduction of Sanitation Worker Registry
Tagging Sanitation Workers to Service requests.

Enhancements

Document Resources & Links

Click for Known Issue List.

Success Criteria

Product Roadmap

Known Issues List

The following are the known issues for DIGIT FSM v1.4:

Training

Videos and training resources

Module Walkthrough Videos

A complete walkthrough of the DIGIT FSM module -

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Sanitation Worker Welfare

Here are the articles in this section:

Vendor Registry
FSM Service

Vendor Registry

Overview

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 .

Click to access the Individual Service.

Architecture Diagram

Vendor Registry

Changes from Version 1.3.1 is 1.4.0

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.

API Specification

ER Diagram

Sequence Diagram

Create Worker

Update Vendor

FSM Service

Changes from Version 1.3.1 is 1.4.0

Introducing worker and FSM application mapping
Backward compatibility for existing applications

API Specification

ER Diagram

Sequence Diagram

Enablement toolkits(Assetization) for FSM

List of actions required to go live in the new State for the FSM module:

: Tenant, boundary, workflow etc

Getting started with DIGIT

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.

Refer for further reference of DIGIT and its deployment.

Core Services:

DIGIT platform comprises of couple of core-services that serves as the backbone for the platform. There are several core-services like:

..and

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.

Loading Localisations

Import the curl :

curl --location --request POST 'https://fsm-2.3.digit.org/localization/messages/v1/_upsert?tenantId=pg' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "apiId": "Rainmaker",
        "ver": ".01",
        "ts": "",
        "action": "_create",
        "did": "1",
        "key": "",
        "msgId": "20170310130900|hi_IN",
        "authToken": "94a4a1dd-5691-4534-88ce-d3440c2e1b85",
        "userInfo": {
            "id": 118,
            "userName": "TLCreator",
            "salutation": null,
            "name": "TLCreator",
            "gender": "MALE",
            "mobileNumber": "6666666666",
            "emailId": null,
            "altContactNumber": null,
            "pan": null,
            "aadhaarNumber": null,
            "permanentAddress": null,
            "permanentCity": null,
            "permanentPinCode": null,
            "correspondenceAddress": "Bang",
            "correspondenceCity": null,
            "correspondencePinCode": null,
            "addresses": [
                {
                    "pinCode": null,
                    "city": null,
                    "address": "Bang",
                    "type": "CORRESPONDENCE",
                    "id": 235,
                    "tenantId": "uk.haldwani",
                    "userId": 118,
                    "addressType": "CORRESPONDENCE",
                    "lastModifiedDate": null,
                    "lastModifiedBy": null
                }
            ],
            "active": true,
            "locale": null,
            "type": "EMPLOYEE",
            "accountLocked": false,
            "accountLockedDate": 1571224291053,
            "fatherOrHusbandName": "Test",
            "signature": null,
            "bloodGroup": null,
            "photo": null,
            "identificationMark": null,
            "createdBy": 4,
            "lastModifiedBy": 1,
            "tenantId": "uk.haldwani",
            "roles": [
                {
                    "code": "PTCEMP",
                    "name": "PT Counter Employee",
                    "tenantId": "uk.haldwani"
                },
                {
                    "code": "TL_CEMP",
                    "name": "TL Counter Employee",
                    "tenantId": "uk.haldwani"
                }
            ],
            "uuid": "573dd472-ebbc-4bbd-b093-897d33f95980",
            "createdDate": "07-10-2019 17:51:18",
            "lastModifiedDate": "13-11-2019 12:19:55",
            "dob": "1/10/2019",
            "pwdExpiryDate": "05-01-2020 17:51:18"
        }
    },
    "tenantId": "pg",
    "messages": [
        {
            "code": "FROM_OTHER_ULB",
            "message": "Other",
            "module": "rainmaker-fsm",
            "locale": "en_IN"
        }
    ]
}'

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.

Plant Mapping of FSTP

Import this curl :
Login from FSTP credientials and copy the uuid of FSTP user.
Take FSTP plantCode from 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.

Creating users for FSM

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.

User Personas

Who can use Faecal Sludge Management solution

Desludging Operator

Urban Local Body

Treatment Operator

All the information is published with the consent of the stakeholders

Features

The following features/components will be available in the TQM module:

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.

Objective

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.

User Manual

Here are the articles in this section:

Employee User Manual

Treatment Plant Operator User Manual

TQM Setup

User Interface Design

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:

Language Selection

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.

Location Selection

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”.

Language Selection

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.

2. Raise a Desludging Request

Citizen Interface

A landing page is available to a citizen on login.

Applying for a Desludging Request

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.

Employee Interface

A landing page is available to the ULB employee on login.

Applying for a Desludging Request

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.

3. View Applications

Citizen Interface

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”.

Employee Interface

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.

4. Accept Applications

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.

5. Payments

Citizen Interface

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.

Employee Interface

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.

6. Assign Desludging Operator

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.

7. Assign Vehicle

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.

8. Complete Request

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.

9. Rate Services

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.

Manage Vendor, Driver and Vehicle Details

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.

View Vendor List

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.

Add a Vendor

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.

View and Edit Vendor Details

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.

Tagging Vehicles and Drivers to a Vendor

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.

View Vehicle List

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.

Add a Vehicle

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.

View and Edit Vehicle Details

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.

Tagging a Vehicle to a Vendor

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.

View Driver List

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.

Add a Driver

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.

View and Edit Driver Details

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.

Tagging a Driver to a Vendor

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’.

Product Requirement Document

Introduction

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:

Success Criteria

Goal

Scope: Sanitation Worker Welfare V1

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

1. Sanitation Worker Registry

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:

Type

Mandatory

Editable (Y/N)

Unique within a tenant (Y/N)

Unique within an instance (Y/N)

Validation

Sanitation worker name

Free text

Sanitation worker ID

Autogenerated

Skills

Array, Multiselect

N (examples of these are Driving, Lab Operations, Plant Maintenance etc)

Tenant ID

Array, Multiselect

N (one sanitation worker may be performing roles in multiple tenants)

Roles

Array/Multiselect

N (examples of this is driver, helper, treatment plant operator, lab operator)

Gender

Array

DOB

Date

Must be minimum (Today - 18 years)

Email address

Free text (Email format)

Follow email format

Phone number

Number

Must have 10 digits

Status

Boolean

Employment type

Array (Fixed/Contractual)

Employer

Array (ULB/Vendor)

Vendor name

Array (Populated based on vendors in the ULB)

Photograph

File

File size

Sanitation workers can be managed via the FSM Registry implemented as part of V1.3. The FSM Registry allows for ULB admins to manage the list of vendors, vehicles and drivers.

Changes required:

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

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

Sanitation workers will be mapped to a vendor.

Create a sanitation worker vendor mapping table.

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

Sanitation Worker: Noun Verb Mapping

Entities

Actions

Create

Read

Update

Delete

Deactivate

Sanitation Worker

2. Recording Participation of Sanitation Workers in Service Delivery

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

Attribute

Type

Mandatory (Y/N)

Comments

SW ID (8 Digits)/Phone number

BIGINT

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:
1. Name
2. Garima ID
3. Phone no.
4. 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.

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.

Design

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.

View Sanitation Worker List

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.

View and Edit Sanitation Worker

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.

Tagging a Sanitation Worker to a Vendor

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.

Recording the Participation of Sanitation Workers in Service Delivery

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.

Out of Scope

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.

Implementation in Orissa

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:

The Sanitation Worker Welfare module v1.0 will be rolled out to Orissa as part of Sujog v1.4. Click here to know more.

User Interface Design

Exemplar

Landing Page: Plant Operator

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”.

Treatment Quality Module (TQM) Home Page

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:

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:

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

Dtill down/Toggle

Comparsion KPIs, if any

Show comparison in

Specific to State/ULB/ TRP/all

Tooltip on Hover on Data Point

Input Fields

Input

Total Incoming Sludge

Total Incoming sludge from registered and unregistered vehicles

KPI

Total Incoming Sludge

Total incoming sludge = (Volume of Waste Disposed for Registered Vehicles) + (Volume of Waste Disposed for Unregistered Vehicles)

State, Plant ULB

Input

# incoming trips

Number of trips disposed at the Treatment plant

KPI

Count of Trips to the Treatment plant from registered and unregistered vehicles

Number of trips disposed = Count(DISTINCT Trip ID)

State, Plant ULB

Treatment Quality

Overall Quality

% of tests where all parameters are as per benchmarks

KPI

% of test results meeting benchmarks

Overall Quality = (Number of tests where all parameters meet benchmarks / Total number of tests) * 100

State, Plant ULB

Treatment Quality

Compliance

% of tests where results have been recorded

KPI

% of tests with Status as submitted out of total tests

Compliance % = (Count of Test ID in status 'Submitted' / Count (Distinct Trip ID) * 100

State, Plant ULB

Alerts

Total Alerts

Total Alerts raised by the system in the following categories: 1) Test Results not as per benchmark 2) No reading from IoT device 3) Lab results and IoT results not matching

KPI

Total Alerts

Count(DISTINCT AlertID)

State, Plant ULB

Treatment Quality Plants

Total Plants

Count of Plants

Count (Distinct PlantID)

State, Plant ULB

Treatment Quality Plants

Treatment Quality Passed

Treatment quality is considered passed if all parameters of both Biosolids and Effluents are as per benchmarks for the output of the Treatment Process in the last test recorded.

Count of Plants with Treatment Quality Passed

Treatment Quality for Output type =IF(COUNTIF(All Parameters Meet Benchmarks, FALSE) = 0, "Treatment Quality for Output type passed ", "Treatment Quality for Output type failed") Treatment Quality for Plant passed = =IF(COUNTIF(Treatment Quality for Output type, FALSE) = 0, " Treatment Quality Passed ", "Treatment Quality Failed")

State, Plant ULB

Treatment Quality Plants

Treatment Quality Failed

Treatment quality is considered failed when 1 or more parameters of Biosolids or Effluents are not as per benchmarks for the output of the Treatment Process in the last test recorded.

Count of Plants with Treatment Quality Failed

Count (Distinct PlantID) - Treatment Quality Passed

State, Plant ULB

Treatment Quality Plants

Map

Point = Geolocation of Plant Plant Icon Colour - Green if Treatment Quality Passed, Red if Treatment Quality Failed

Same as 7 and 8

State, Plant ULB

Name of Plant

Treatment Quality Plants

Table

Plant Name, Test Result, Compliance %

Test Result Same as S.No 7 and S.No 8

State, Plant ULB

Treatment Quality Plants

Table

Stage, Output Type, Parameters 1...n, Compliance %

Mentioned above

State, Plant ULB

Compliance %

% from last month

Trend in [Parameter Name] Readings

Multi-Line Chart

Test Dates

Parameter Value

- Value of Device Reading - Value of Lab results

Plant

Date Lab result - X Device Reading - Y

Landing Page: ULB Employee

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.

View Dashboard

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:

- 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.

FSM-DSS Technical Documentation

Overview

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.

What is analytics?

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.

Analytics Configurations

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.

Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration

Description

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.

  "fsmTotalrequest": {
    "chartName": "DSS_FSM_TOTAL_REQUESTS",
    "queries": [
      {
        "module": "FSM",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Total Application\":{\"value_count\":{\"field\":\"Data.fsm.@timestamp\"}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.fsm.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "number",
    "action": "",
    "drillChart": "none",
    "aggregationPaths": [
      "Total Application"
    ],
    "insight": {
      "chartResponseMap" : "totalApplication",
      "action" : "differenceOfNumbers",
      "upwardIndicator" : "positive",
      "downwardIndicator" : "negative",
      "textMessage" : "$indicator$value% than last $insightInterval",
      "colorCode" : "#228B22",
      "insightInterval" : "year",
      "isRoundOff": true
    },
    "_comment": " FSM Total Applications"
  },
  "totalSludgeTreated": {
    "chartName": "DSS_FSM_TOTAL_SLUDGE_TREATED",
    "queries": [
      {
        "module": "FSM",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Total Sludge Collection\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.vehicleTrip.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "number",
    "action": "",
    "drillChart": "none",
    "aggregationPaths": [
      "Total Sludge Collection"
    ],
    "insight": {
      "chartResponseMap" : "totalSludgeTreated",
      "action" : "differenceOfNumbers",
      "upwardIndicator" : "positive",
      "downwardIndicator" : "negative",
      "textMessage" : "$indicator$value% than last $insightInterval",
      "colorCode" : "#228B22",
      "insightInterval" : "year",
      "isRoundOff": true
    },
    "_comment": " FSM Total Sludge Treated"
  },
  "avgFSMCostRequest": {
    "chartName": "DSS_FSM_AVG_FSM_COST_OR_REQ",
    "queries": [
      {
        "module": "FSM",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.tenantId.keyword\":\"pb.testing\"}}],\"must\":[{\"term\":{\"Data.payments.paymentDetails.businessService.keyword\":\"FSM.TRIP_CHARGES\"}}]}},\"aggs\":{\"Average Collection\":{\"avg\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.fsm.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "amount",
    "action": "",
    "drillChart": "none",
    "isRoundOff": true,
    "aggregationPaths": [
      "Average Collection"
    ],
    "insight": {
      "chartResponseMap" : "averageCollection",
      "action" : "differenceOfNumbers",
      "upwardIndicator" : "positive",
      "downwardIndicator" : "negative",
      "textMessage" : "$indicator$value% than last $insightInterval",
      "colorCode" : "#228B22",
      "insightInterval" : "year",
      "isRoundOff": true
    },
    "_comment": " FSM Average Collection"
  },
  "totalCollectioninLacs": {
    "chartName": "DSS_FSM_TOTAL_COLLECTION",
    "queries": [
      {
        "module": "FSM",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.tenantId.keyword\":\"pb.testing\"}}],\"must\":[{\"term\":{\"Data.payments.paymentDetails.businessService.keyword\":\"FSM.TRIP_CHARGES\"}}]}},\"aggs\":{\"Total Collection\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.fsm.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "amount",
    "action": "",
    "drillChart": "none",
    "documentType": "_doc",
    "aggregationPaths": [
      "Total Collection"
    ],
    "insight": {
      "chartResponseMap" : "totalCollection",
      "action" : "differenceOfNumbers",
      "upwardIndicator" : "positive",
      "downwardIndicator" : "negative",
      "textMessage" : "$indicator$value% than last $insightInterval",
      "colorCode" : "#228B22",
      "insightInterval" : "year",
      "isRoundOff": true
    },
    "_comment": " FSM Total Collection"
  },
  "slaCompliance": {
    "chartName": "DSS_FSM_SLA_COMPLIANCE",
    "queries": [
      {
        "module": "FSM",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.service.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Closed With In Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"count\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}},\"Total Applications\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.fsm.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "percentage",
    "drillChart": "none",
    "documentType": "_doc",
    "action": "percentage",
    "isRoundOff": true,
    "aggregationPaths": [
      "Closed With In Sla",
      "Total Applications"
    ],
    "insight": {
      "chartResponseMap" : "slaCompliance",
      "action" : "differenceOfNumbers",
      "upwardIndicator" : "positive",
      "downwardIndicator" : "negative",
      "textMessage" : "$indicator$value% than last $insightInterval",
      "colorCode" : "#228B22",
      "insightInterval" : "year",
      "isRoundOff": true
    },
    "_comment": " SLA Compliance"
  },
  "citizenAvgRating": {
    "chartName": "DSS_FSM_CITIZEN_AVG_RATING",
    "queries": [
      {
        "module": "FSM",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}],\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\"]}},{\"term\":{\"Data.history.action.keyword\":\"RATE\"}},{\"exists\":{\"field\":\"Data.history\"}},{\"range\":{\"Data.history.rating\":{\"gte\":1}}}]}},\"aggs\":{\"Citizen Average Rating\":{\"avg\":{\"script\":\"int sum = 0;int count =0;if(params['_source']['Data']['history']!=null){ for (item in params['_source']['Data']['history']) {if(item.rating!=null){ sum += item.rating;} }} return sum;\"}}}}}}",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "dateRefField": "Data.fsm.@timestamp"
      }
    ],
    "chartType": "metric",
    "valueType": "number",
    "action": "",
    "drillChart": "none",
    "documentType": "_doc",
    "aggregationPaths": [
      "Citizen Average Rating"
    ],
    "postAggregationTheory": "",
    "insight": {},
    "_comment": " Citizen Average rating"
  },
  "fsmCollectionByUsageType": {
    "chartName": "DSS_FSM_COLLECTION_BY_USAGE_TYPE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Usage Type\":{\"terms\":{\"field\":\"Data.fsm.propertyUsage.keyword\"},\"aggs\":{\"Assessed Properties\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}}}"
      }
    ],
    "chartType": "pie",
    "valueType": "amount",
    "action": "",
    "documentType": "_doc",
    "drillChart": "none",
    "aggregationPaths": [
      "Usage Type"
    ],
    "insight": {
    },
    "_comment": " "
  },
  "fsmTotalCumulativeCollection": {
    "chartName": "DSS_FSM_TOTAL_CUMULATIVE_COLLECTION",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Total Collection\":{\"date_histogram\":{\"field\":\"Data.fsm.@timestamp\",\"interval\":\"intervalvalue\"},\"aggs\":{\"Count\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "amount",
    "action": "",
    "drillChart": "none",
    "documentType": "_doc",
    "aggregationPaths": [
      "Total Collection"
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmTopUlbByPerformance": {
    "chartName": "DSS_FSM_TOP_ULB_BY_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Closed With In Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"count\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}},\"Total Applications\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}}}}"
      }
    ],
    "chartType": "perform",
    "valueType": "percentage",
    "drillChart": "none",
    "documentType": "_doc",
    "drillChart": "ulbTopDrillChart",
    "action": "percentage",
    "plotLabel": "DSS_COMPLETION_RATE",
    "isRoundOff": true,
    "order": "desc",
    "limit": 3,
    "aggregationPaths": [
      "Closed With In Sla",
      "Total Applications"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {
    },
    "_comment": ""
  },
  "ulbTopDrillChart": {
    "chartName": "DSS_FSM_ULB_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"ULB\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\",\"size\":1000,\"order\":{\"_count\":\"desc\"}},\"aggs\":{\"TotalRequests\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}},\"ClosedWithInSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"ClosedOutsideSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"CitizenAverageRating\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\"]}},{\"term\":{\"Data.history.action.keyword\":\"RATE\"}},{\"exists\":{\"field\":\"Data.history\"}},{\"range\":{\"Data.history.rating\":{\"gte\":1}}}]}},\"aggs\":{\"CitizenAvgRating\":{\"avg\":{\"script\":\"int sum = 0;int count =0;if(params['_source']['Data']['history']!=null){ for (item in params['_source']['Data']['history']) {if(item.rating!=null){ sum += item.rating;} }} return sum;\"}}}}}}}}}}"
      }
    ],
   "filterKeys": [
      {"key": "tenantId", "column": "ULB"}
    ],
    "isPostResponseHandler": true,
    "chartType": "table",
    "valueType": "number",
    "action": "",
    "documentType": "_doc",
    "drillChart": "none",
    "plotLabel":"ULB",
    "aggregationPaths": [
      "TotalRequests",
      "ClosedWithInSLA",
      "ClosedOutsideSLA",
      "CitizenAverageRating"
    ],
    "pathDataTypeMapping": [
      {
        "TotalRequests" : "number"
      },
      {
        "ClosedWithInSLA" : "number"
      },
      {
        "ClosedOutsideSLA" : "number"
      },
      {
        "CitizenAverageRating" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmBottomUlbByPerformance": {
    "chartName": "DSS_FSM_BOTTOM_ULB_BY_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Closed With In Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"count\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}},\"Total Applications\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\"},\"aggs\":{\"tenant_count\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}}}}}}"
      }
    ],
    "chartType": "perform",
    "valueType": "percentage",
    "drillChart": "none",
    "documentType": "_doc",
    "drillChart": "ulbBottomDrillChart",
    "action": "percentage",
    "isRoundOff": true,
    "plotLabel": "DSS_COMPLETION_RATE",
    "order": "asc",
    "limit": 3,
    "aggregationPaths": [
      "Closed With In Sla",
      "Total Applications"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {
    },
    "_comment": ""
  },
  "ulbBottomDrillChart": {
    "chartName": "DSS_FSM_ULB_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"ULB\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\",\"size\":1000,\"order\":{\"_count\":\"asc\"}},\"aggs\":{\"TotalRequests\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}},\"ClosedWithInSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"ClosedOutsideSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"CitizenAverageRating\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\"]}},{\"term\":{\"Data.history.action.keyword\":\"RATE\"}},{\"exists\":{\"field\":\"Data.history\"}},{\"range\":{\"Data.history.rating\":{\"gte\":1}}}]}},\"aggs\":{\"CitizenAvgRating\":{\"avg\":{\"script\":\"int sum = 0;int count =0;if(params['_source']['Data']['history']!=null){ for (item in params['_source']['Data']['history']) {if(item.rating!=null){ sum += item.rating;} }} return sum;\"}}}}}}}}}}"
      }
    ],
   "filterKeys": [
      {"key": "tenantId", "column": "ULB"}
    ],
    "isPostResponseHandler": true,
    "chartType": "table",
    "valueType": "number",
    "action": "",
    "documentType": "_doc",
    "drillChart": "none",
    "plotLabel":"ULB",
    "aggregationPaths": [
      "TotalRequests",
      "ClosedWithInSLA",
      "ClosedOutsideSLA",
      "CitizenAverageRating"
    ],
    "pathDataTypeMapping": [
      {
        "TotalRequests" : "number"
      },
      {
        "ClosedWithInSLA" : "number"
      },
      {
        "ClosedOutsideSLA" : "number"
      },
      {
        "CitizenAverageRating" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmCapacityUtilization": {
    "chartName": "DSS_FSTP_CAPACITY_UTILIZATION",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.vehicleTrip.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Capacity Utilization\":{\"date_histogram\":{\"field\":\"Data.vehicleTrip.@timestamp\",\"interval\":\"month\"},\"aggs\":{\"Count\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "amount",
    "action": "",
    "isRoundOff": true,
    "documentType": "_doc",
    "drillChart": "none",
    "aggregationPaths": [
      "Capacity Utilization"
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmMonthlyWasteCal": {
    "chartName": "DSS_FSM_MONTHLY_WASTE_CAL",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.vehicleTrip.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Septage Dumped At Plant\":{\"date_histogram\":{\"field\":\"Data.vehicleTrip.@timestamp\",\"interval\":\"month\"},\"aggs\":{\"Count\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}}}},\"Septage Collected\":{\"date_histogram\":{\"field\":\"Data.vehicleTrip.@timestamp\",\"interval\":\"month\"},\"aggs\":{\"Count\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.tripDetails.volume'].value)/1000.0\"}}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "number",
    "action": "",
    "isRoundOff": true,
    "documentType": "_doc",
    "drillChart": "none",
    "aggregationPaths": [
      "Septage Collected",
      "Septage Dumped At Plant"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmTopDsoByPerformance": {
    "chartName": "DSS_FSM_TOP_DSO_BY_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Raised\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"desc\"}},\"aggs\":{\"Count\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"Closed Within SLA\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"desc\"}},\"aggs\":{\"Count\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}}}},\"Closed Outside SLA\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"desc\"}},\"aggs\":{\"Count\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "number",
    "action": "",
    "drillChart": "dsoTopDrillChart",
    "documentType": "_doc",
    "aggregationPaths": [
      "Raised",
      "Closed Within SLA",
      "Closed Outside SLA"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {
    },
    "_comment": ""
  },
  "dsoTopDrillChart": {
    "chartName": "DSS_FSM_DSO_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"DSOName\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":1000,\"order\":{\"_count\":\"desc\"}},\"aggs\":{\"TotalRequest\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}},\"ClosedWithinSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"ClosedOutsideSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"CitizenAverageRating\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\"]}},{\"term\":{\"Data.history.action.keyword\":\"RATE\"}},{\"exists\":{\"field\":\"Data.history\"}},{\"range\":{\"Data.history.rating\":{\"gte\":1}}}]}},\"aggs\":{\"CitizenAvgRating\":{\"avg\":{\"script\":\"int sum = 0;int count =0;if(params['_source']['Data']['history']!=null){ for (item in params['_source']['Data']['history']) {if(item.rating!=null){ sum += item.rating;} }} return sum;\"}}}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "dsoName", "column": "DSOName"}
    ],
    "isPostResponseHandler": true,
    "chartType": "table",
    "valueType": "number",
    "action": "",
    "documentType": "_doc",
    "drillChart": "none",
    "plotLabel":"DSOName",
    "aggregationPaths": [
      "TotalRequest",
      "ClosedWithinSLA",
      "ClosedOutsideSLA",
      "CitizenAverageRating"
    ],
    "pathDataTypeMapping": [
      {
        "TotalRequest" : "number"
      },
      {
        "ClosedWithinSLA" : "number"
      },
        {
        "ClosedOutsideSLA" : "number"
      },
      {
        "CitizenAverageRating" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmBottomDsoByPerformance": {
    "chartName": "DSS_FSM_BOTTOM_DSO_BY_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Raised\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"asc\"}},\"aggs\":{\"Count\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"Closed Within SLA\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"asc\"}},\"aggs\":{\"Count\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}}}},\"Closed Outside SLA\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":3,\"order\":{\"_count\":\"asc\"}},\"aggs\":{\"Count\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}}}}}}}}"
      }
    ],
    "chartType": "line",
    "valueType": "number",
    "action": "",
    "drillChart": "dsoBottomDrillChart",
    "documentType": "_doc",
    "aggregationPaths": [
      "Raised",
      "Closed Within SLA",
      "Closed Outside SLA"
    ],
    "isCumulative": false,
    "interval": "month",
    "insight": {
    },
    "_comment": ""
  },
  "dsoBottomDrillChart": {
    "chartName": "DSS_FSM_DSO_PERFORMANCE",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"DSOName\":{\"terms\":{\"field\":\"Data.vendor.name.keyword\",\"size\":1000,\"order\":{\"_count\":\"asc\"}},\"aggs\":{\"TotalRequest\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}},\"ClosedWithinSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"ClosedOutsideSLA\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value > params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"valueCount\":{\"value_count\":{\"field\":\"Data.vendor.name.keyword\"}}}},\"CitizenAverageRating\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\"]}},{\"term\":{\"Data.history.action.keyword\":\"RATE\"}},{\"exists\":{\"field\":\"Data.history\"}},{\"range\":{\"Data.history.rating\":{\"gte\":1}}}]}},\"aggs\":{\"CitizenAvgRating\":{\"avg\":{\"script\":\"int sum = 0;int count =0;if(params['_source']['Data']['history']!=null){ for (item in params['_source']['Data']['history']) {if(item.rating!=null){ sum += item.rating;} }} return sum;\"}}}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "dsoName", "column": "DSOName"}
    ],
    "isPostResponseHandler": true,
    "chartType": "table",
    "valueType": "number",
    "action": "",
    "documentType": "_doc",
    "drillChart": "none",
    "plotLabel":"DSOName",
    "aggregationPaths": [
      "TotalRequest",
      "ClosedWithinSLA",
      "ClosedOutsideSLA",
      "CitizenAverageRating"
    ],
    "pathDataTypeMapping": [
      {
        "TotalRequest" : "number"
      },
      {
        "ClosedWithinSLA" : "number"
      },
      {
        "ClosedOutsideSLA" : "number"
      },
      {
        "CitizenAverageRating" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmTotalReqByDistrict": {
    "chartName": "DSS_FSM_TOTAL_REQ_BY_DISTRICT",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtName\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Open_Req\":{\"filter\":{\"bool\":{\"must_not\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"OpenReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"Closed_Req\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"ClosedReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}},\"Closed_With_In_Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"ClosedWithInSla\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalCollection\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}"
      }
    ],
    "isMdmsEnabled": true,
    "filterKeys": [
      {"key": "tenantId", "column": "District"}
    ],
    "chartType": "xtable",
    "valueType": "number",
    "isRoundOff": true,
    "drillChart": "fsmTotalReqByTenant",
    "plotLabel": "District",
    "excludedColumns": ["ClosedWithInSla"],
    "computedFields": [
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedReq", "TotalReq"],
        "newField" : "CompletionRateIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      },
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedWithInSla","TotalReq"],
        "newField" : "SLAAchievedIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      }
    ],
     "chartSpecificProperty": {
     "XtableColumnOrder":[
     "S.N.",
     "District",
     "OpenReq",
     "ClosedReq",
     "TotalReq",
     "CompletionRateIn%",
     "SLAAchievedIn%",
     "TotalCollection"
     ]
     },
    "insight": {
    },
    "_comment": " "
  },
  "fsmTotalReqByTenant": {
    "chartName": "DSS_FSM_TOTAL_REQ_BY_ULB",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtName\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"ULBs\":{\"terms\":{\"field\":\"Data.fsm.tenantId.keyword\",\"size\":1000},\"aggs\":{\"Open_Req\":{\"filter\":{\"bool\":{\"must_not\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"OpenReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"Closed_Req\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"ClosedReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}},\"Closed_With_In_Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"ClosedWithInSla\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalCollection\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "tenantId", "column": "ULB"}
    ],
    "chartType": "xtable",
    "valueType": "number",
    "isRoundOff": true,
    "drillChart": "fsmTotalReqByWard",
    "plotLabel": "ULB",
    "excludedColumns": ["ClosedWithInSla"],
    "computedFields": [
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedReq", "TotalReq"],
        "newField" : "CompletionRateIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      },
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedWithInSla","TotalReq"],
        "newField" : "SLAAchievedIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      }
    ],
    "chartSpecificProperty": {
     "XtableColumnOrder":[
     "S.N.",
     "ULB",
     "OpenReq",
     "ClosedReq",
     "TotalReq",
     "CompletionRateIn%",
     "SLAAchievedIn%",
     "TotalCollection"
     ]
     },
    "insight": {
    },
    "_comment": " "
  },
  "fsmTotalReqByWard": {
    "chartName": "DSS_FSM_TOTAL_REQ_BY_WARD",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.fsm.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "fsm",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"Data.fsm.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Ward\":{\"terms\":{\"field\":\"Data.ward.name.keyword\",\"size\":1000},\"aggs\":{\"Open_Req\":{\"filter\":{\"bool\":{\"must_not\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"OpenReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"Closed_Req\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}}]}},\"aggs\":{\"ClosedReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalReq\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}},\"Closed_With_In_Sla\":{\"filter\":{\"bool\":{\"must\":[{\"terms\":{\"Data.fsm.applicationStatus.keyword\":[\"COMPLETED\",\"CITIZEN_FEEDBACK_PENDING\"]}},{\"script\":{\"script\":{\"source\":\"doc['Data.fsm.auditDetails.lastModifiedTime'].value - doc['Data.fsm.auditDetails.createdTime'].value < params.threshold\",\"lang\":\"painless\",\"params\":{\"threshold\":172800000}}}}]}},\"aggs\":{\"ClosedWithInSla\":{\"value_count\":{\"field\":\"Data.fsm.tenantId.keyword\"}}}},\"TotalCollection\":{\"sum\":{\"field\":\"Data.payments.paymentDetails.bill.billDetails.amountPaid\"}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "wardId", "column": "Ward"},
      {"key": "ulbId", "column": "ULB"}
    ],
    "chartType": "xtable",
    "valueType": "number",
    "isRoundOff": true,
    "drillChart": "none",
    "action": "",
    "documentType": "_doc",
    "plotLabel": "Ward",
    "excludedColumns": ["ClosedWithInSla"],
    "computedFields": [
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedReq", "TotalReq"],
        "newField" : "CompletionRateIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      },
      {
        "postAggregationTheory" : "",
        "actionName": "PercentageComputedField",
        "fields" : ["ClosedWithInSla","TotalReq"],
        "newField" : "SLAAchievedIn%",
        "_comments": "fields are field names picked from its aggregation query to use post aggregation newField value with given new field name  "
      }
    ],
     "chartSpecificProperty": {
     "XtableColumnOrder":[
     "S.N.",
     "Ward",
     "OpenReq",
     "ClosedReq",
     "TotalReq",
     "CompletionRateIn%",
     "SLAAchievedIn%",
     "TotalCollection"
     ]
     },
    "insight": {
    },
    "_comment": " "
  },
  "fsmVehicleLogReportByDDR": {
    "chartName": "DSS_FSM_VECHILE_LOG_REPORT",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.vehicleTrip.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtName\"}",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"NoOfTrips\":{\"value_count\":{\"field\":\"Data.vehicleTrip.@timestamp\"}},\"TotalSeptageCollected\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.tripDetails.volume'].value)/1000.0\"}}},\"TotalSeptageDumped\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}},\"CapacityUtilization\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}}}}}}"
      }
    ],
    "isMdmsEnabled": true,
    "filterKeys": [
      {"key": "tenantId", "column": "District"}
    ],
    "isPostResponseHandler": true,
    "chartType": "xtable",
    "valueType": "number",
    "action": "",
    "isRoundOff": true,
    "documentType": "_doc",
    "drillChart": "fsmVehicleLogReportByTenant",
    "plotLabel":"District",
    "aggregationPaths": [
      "NoOfTrips",
      "TotalSeptageCollected",
      "TotalSeptageDumped",
      "CapacityUtilization"
    ],
    "pathDataTypeMapping": [
      {
        "NoOfTrips" : "number"
      },
      {
        "TotalSeptageCollected" : "number"
      },
      {
        "TotalSeptageDumped" : "number"
      },
      {
        "CapacityUtilization" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmVehicleLogReportByTenant": {
    "chartName": "DSS_FSM_VECHILE_LOG_REPORT",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.vehicleTrip.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtName\"}",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"ULBs \":{\"terms\":{\"field\":\"Data.vehicleTrip.tenantId.keyword\",\"size\":1000},\"aggs\":{\"NoOfTrips\":{\"value_count\":{\"field\":\"Data.vehicleTrip.@timestamp\"}},\"TotalSeptageCollected\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.tripDetails.volume'].value)/1000.0\"}}},\"TotalSeptageDumped\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}},\"CapacityUtilization\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "tenantId", "column": "Boundary"}
    ],
    "isPostResponseHandler": true,
    "chartType": "xtable",
    "valueType": "number",
    "action": "",
    "isRoundOff": true,
    "documentType": "_doc",
    "drillChart": "fsmVehicleLogReportByVehicleNo",
    "plotLabel":"Boundary",
    "aggregationPaths": [
      "NoOfTrips",
      "TotalSeptageCollected",
      "TotalSeptageDumped",
      "CapacityUtilization"
    ],
    "pathDataTypeMapping": [
      {
        "NoOfTrips" : "number"
      },
      {
        "TotalSeptageCollected" : "number"
      },
      {
        "TotalSeptageDumped" : "number"
      },
      {
        "CapacityUtilization" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  },
  "fsmVehicleLogReportByVehicleNo": {
    "chartName": "DSS_FSM_VECHILE_LOG_REPORT",
    "queries": [
      {
        "module": "FSM",
        "dateRefField": "Data.vehicleTrip.@timestamp",
        "requestQueryMap": "{\"wardId\" : \"Data.ward.name.keyword\", \"tenantId\" : \"Data.tenantData.code\" ,  \"district\" : \"Data.tenantData.city.districtCode\"}",
        "indexName": "vehicletrip",
        "aggrQuery": "{\"aggs\":{\"AGGR\":{\"filter\":{\"bool\":{\"must_not\":[{\"term\":{\"data.vehicleTrip.tenantId.keyword\":\"pb.testing\"}}]}},\"aggs\":{\"Vehicle Reg No\":{\"terms\":{\"field\":\"Data.vehicleTrip.vehicle.registrationNumber.keyword\",\"size\":1000},\"aggs\":{\"NoOfTrips\":{\"value_count\":{\"field\":\"Data.vehicleTrip.@timestamp\"}},\"TotalSeptageCollected\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.tripDetails.volume'].value)/1000.0\"}}},\"TotalSeptageDumped\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}},\"CapacityUtilization\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.volumeCarried'].value)/1000.0\"}}},\"TankCapacity\":{\"sum\":{\"script\":{\"source\":\"(doc['Data.vehicleTrip.vehicle.tankCapacity'].value)/1000.0\"}}}}}}}}}"
      }
    ],
    "filterKeys": [
      {"key": "registrationNumber", "column": "Vehicle_No"},
      {"key": "wardId", "column": "Ward"},
      {"key": "ulbId", "column": "ULB"}
    ],
    "isPostResponseHandler": true,
    "chartType": "xtable",
    "valueType": "number",
    "action": "",
    "isRoundOff": true,
    "documentType": "_doc",
    "drillChart": "none",
    "plotLabel":"Vehicle_No",
    "aggregationPaths": [
      "NoOfTrips",
      "TotalSeptageCollected",
      "TotalSeptageDumped",
      "CapacityUtilization",
      "TankCapacity"
    ],
    "pathDataTypeMapping": [
      {
        "NoOfTrips" : "number"
      },
      {
        "TotalSeptageCollected" : "number"
      },
      {
        "TotalSeptageDumped" : "number"
      },
      {
        "CapacityUtilization" : "number"
      },
      {
        "TankCapacity" : "number"
      }
    ],
    "isCumulative": true,
    "interval": "month",
    "insight": {
    },
    "_comment": " "
  }

Click here to check the complete configuration

Master Dashboard 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.

{
      "name": "DSS_FSM_DASHBOARD",
      "id": "fsm",
      "isActive": "",
      "style": "linear",
      "visualizations": [
        {
          "row": 1,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 311,
              "name": "DSS_OVERVIEW",
              "dimensions": {
                "height": 450,
                "width": 4
              },
              "vizType": "metric-collection",
              "label": "DSS_OVERVIEW",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmTotalrequest",
                  "name": "DSS_FSM_TOTAL_REQUESTS",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                },
                {
                  "id": "totalSludgeTreated",
                  "name": "DSS_FSM_TOTAL_SLUDGE_TREATED",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                },
                {
                  "id": "avgFSMCostRequest",
                  "name": "DSS_FSM_AVG_FSM_COST_OR_REQ",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                },
                {
                  "id": "totalCollectioninLacs",
                  "name": "DSS_FSM_TOTAL_COLLECTION",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                },
                {
                  "id": "slaCompliance",
                  "name": "DSS_FSM_SLA_COMPLIANCE",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                },
                {
                  "id": "citizenAvgRating",
                  "name": "DSS_FSM_CITIZEN_AVG_RATING",
                  "code": "",
                  "chartType": "metric",
                  "filter": "",
                  "headers": []
                }
              ]
            },
            {
              "id": 322,
              "name": "DSS_FSM_TOTAL_CUMULATIVE_COLLECTION",
              "dimensions": {
                "height": 450,
                "width": 6
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmTotalCumulativeCollection",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "line",
                  "filter": "",
                  "headers": []
                }
              ]
            }
          ]
        },
        {
          "row": 2,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 321,
              "name": "DSS_FSM_TOP_ULB_BY_PERFORMANCE",
              "dimensions": {
                "height": 250,
                "width": 3
              },
              "vizType": "performing-metric",
              "label": "",
              "noUnit": false,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmTopUlbByPerformance",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "bar",
                  "filter": "",
                  "headers": []
                }
              ]
            },
            {
              "id": 322,
              "name": "DSS_FSM_BOTTOM_ULB_BY_PERFORMANCE",
              "dimensions": {
                "height": 250,
                "width": 3
              },
              "vizType": "performing-metric",
              "label": "",
              "noUnit": false,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmBottomUlbByPerformance",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "bar",
                  "filter": "",
                  "headers": []
                }
              ]
            },
            {
              "id": 323,
              "name": "DSS_FSM_COLLECTION_BY_USAGE_TYPE",
              "dimensions": {
                "height": 250,
                "width": 4
              },
              "vizType": "chart",
              "label": "",
              "noUnit": false,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmCollectionByUsageType",
                  "name": "DSS_FSM_COLLECTION_BY_USAGE_TYPE",
                  "code": "",
                  "chartType": "donut",
                  "filter": "",
                  "headers": []
                }
              ]
            }
          ]
        },
        {
          "row": 3,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 325,
              "name": "DSS_FSTP_CAPACITY_UTILIZATION",
              "dimensions": {
                "height": 450,
                "width": 5
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmCapacityUtilization",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "line",
                  "filter": "",
                  "headers": []
                }
              ]
            },
            {
              "id": 326,
              "name": "DSS_FSM_MONTHLY_WASTE_CAL",
              "dimensions": {
                "height": 450,
                "width": 5
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmMonthlyWasteCal",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "bar",
                  "filter": "",
                  "headers": []
                }
              ]
            }
          ]
        },
        {
          "row": 4,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 327,
              "name": "DSS_FSM_TOP_DSO_BY_PERFORMANCE",
              "dimensions": {
                "height": 450,
                "width": 5
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmTopDsoByPerformance",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "horizontalBar",
                  "filter": "",
                  "headers": []
                }
              ]
            },
            {
              "id": 329,
              "name": "DSS_FSM_BOTTOM_DSO_BY_PERFORMANCE",
              "dimensions": {
                "height": 450,
                "width": 5
              },
              "vizType": "chart",
              "label": "",
              "noUnit": true,
              "isCollapsible": false,
              "charts": [
                {
                  "id": "fsmBottomDsoByPerformance",
                  "name": "Monthly",
                  "code": "",
                  "chartType": "horizontalBar",
                  "filter": "",
                  "headers": []
                }
              ]
            }
          ]
        },
        {
          "row": 5,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 339,
              "name": "DSS_FSM_TOTAL_REQ_BY_DISTRICT",
              "dimensions": {
                "height": 350,
                "width": 10
              },
              "vizType": "chart",
              "label": "",
              "noUnit": false,
              "isCollapsible": true,
              "charts": [
                {
                  "id": "fsmTotalReqByDistrict",
                  "name": "DSS_FSM_TOTAL_REQ_BY_DISTRICT",
                  "code": "",
                  "chartType": "table",
                  "filter": "",
                  "headers": [],
                  "tabName": "Boundary"
                }
              ]
            }
          ]
        },
        {
          "row": 6,
          "name": "DSS_REVENUE",
          "vizArray": [
            {
              "id": 331,
              "name": "DSS_FSM_VECHILE_LOG_REPORT",
              "dimensions": {
                "height": 350,
                "width": 10
              },
              "vizType": "chart",
              "label": "",
              "noUnit": false,
              "isCollapsible": true,
              "charts": [
                {
                  "id": "fsmVehicleLogReportByDDR",
                  "name": "DSS_FSM_VECHILE_LOG_REPORT",
                  "code": "",
                  "chartType": "table",
                  "filter": "",
                  "headers": [],
                  "tabName": "Boundary"
                }
              ]
            }
          ]
        }
      ]
    },

Click here for the complete configuration.

Role Dashboard Mappings 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.

{
  "_comment": "Holds mapping for each role with and its associated dashboards",
  "roles" : [
    {
      "_comment":"This role is super role which can access all the available dashboards: [other/new roles are suppose to be added]",
      "roleId": 6,
      "roleName" : "Admin",
      "isSuper" : "",
      "orgId": "",
      "dashboards": [
        {
          "name": "Facial Sludge Management",
          "id": "fsm"
        }
      ]
    },
    {
      "_comment":"This role is super role which can access all the available dashboards: [other/new roles are suppose to be added]",
      "roleId": 7,
      "roleName" : "Commissioner",
      "isSuper" : "",
      "orgId": "",
      "dashboards": [
        {
          "id": "ulb-fsm"
        }
      ]
    }

  ]
}

Click here to check the configuration

MDMS Configuration to be added

common-masters/uiCommonConstants.json

"fsm":{
                 "routePath":"/dashboard/fsm",
                 "isOrigin":true
              },
              "ulb-fsm":{
                 "routePath":"/dashboard/ulb-fsm",
                 "isOrigin":true
              }

Click here to check the complete configuration.

roleaction.json

 {
      "rolecode": "STADMIN",
      "actionid": {{PlaceHolder1}},
      "actioncode": "",
      "tenantId": "pb"
    }
    
    
    {
      "rolecode": "STADMIN",
      "actionid": {{PlaceHolder2}},
      "actioncode": "",
      "tenantId": "pb"
    },
     {
      "rolecode": "EMPLOYEE",
      "actionid": {{PlaceHolder2}},
      "actioncode": "",
      "tenantId": "pb"
    },  
     {
      "rolecode": "UC_EMP",
      "actionid": {{PlaceHolder2}},
      "actioncode": "",
      "tenantId": "pb"
    },

Click here to check the complete configuration.

Action test.json:

{
      "id": {{PlaceHolder1}},
      "name": "DSS Dashboard Config Facial Sludge Management",
      "url": "/dashboard-analytics/dashboard/getDashboardConfig/fsm",
      "parentModule": "",
      "displayName": "DSS",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "DSS",
      "code": "null",
      "path": ""
    },
  {
      "id": {{PlaceHolder2}},
      "name": "DSS Dashboard Charts",
      "url": "/dashboard-analytics/dashboard/getChartV2",
      "parentModule": "",
      "displayName": "DSS",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "DSS",
      "code": "null",
      "path": ""
    },

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

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.

Total Cumulative Collection

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.

Line - This graph/chart is data representation on date histograms or date groupings.

Top ULB By Performance

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.

Bottom ULB by Performance

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.

When you click on "Show More," you will navigate to a tabular chart of the bottom ULB by performance.

FSM Collection by Usage Type

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.

FSTP - Capacity Utilisation

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.

Monthly Septage Collected

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.

Top DSO By Performance

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.

Bottom DSO By Performance

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.

Desludging Request Report

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.

Vehicle Log Report

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.

Newly-Introduced Property

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.

Common Properties Available

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

MDMS Changes

Overview

The following MDMS changes were done as part of the FSM v1.4 release:

MDMS Changes

Feature

Service name

Changes

Description

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.

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:

MasterName

Schema Link

Required Fields

Unique Fields

PQM.BenchmarkRule

id, code, name

code

PQM.QualityTestLab

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

Make sure TQM and FSM is enabled in this master -> cityModule.json
data/pg/common-masters/howItWorks.json -> HowItWorks
data/pg/FSM/SanitationWorkerSkills.json -> SanitationWorkerSkills
data/pg/FSM/SanitationWorkerEmploymentType.json -> File Link
data/pg/FSM/SanitationWorkerEmployer.json -> File Link
data/pg/FSM/SanitationWorkerFunctionalRoles.json -> File Link

Role-Action Mapping

data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json

{
      "id": 346,
      "name": "schema Create",
      "url": "/mdms-v2/schema/v1/_create",
      "parentModule": "",
      "displayName": "Schema Create",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "",
      "code": "null",
      "path": ""
    },
    {
    "id": 357,
    "name": "Search  PQM Application",
    "url": "/mdms-v2/schema/v1/_search",
    "displayName": "Search MDMS Schema",
    "orderNumber": 0,
    "enabled": false,
    "serviceCode": "PQM",
    "code": "null",
    "path": ""
  }
{
      "id": 347,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.SourceType",
      "parentModule": "",
      "displayName": "Add Data for PQM.SourceType",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "",
      "code": "null",
      "path": ""
    },
     {
      "id": 201,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Labs",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=QualityTestLab",
      "path": "9MDMS.PQM.QualityTestLab",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 202,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.QualityTestLab",
      "displayName": "create PQM.QualityTestLab",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 203,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.QualityTestLab",
      "displayName": "Update PQM.QualityTestLab",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 204,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM BenchmarkRule",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=BenchmarkRule",
      "path": "9MDMS.PQM.BenchmarkRule",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 205,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.BenchmarkRule",
      "displayName": "create PQM.BenchmarkRule",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 206,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.BenchmarkRule",
      "displayName": "Update PQM.BenchmarkRule",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 207,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Material",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Material",
      "path": "9MDMS.PQM.Material",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 208,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Material",
      "displayName": "create PQM.Material",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 209,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Material",
      "displayName": "Update PQM.Material",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 210,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Unit",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Unit",
      "path": "9MDMS.PQM.Unit",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 211,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Unit",
      "displayName": "create PQM.Unit",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 212,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Unit",
      "displayName": "Update PQM.Unit",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 213,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM TestType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=TestType",
      "path": "9MDMS.PQM.TestType",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 214,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.TestType",
      "displayName": "create PQM.TestType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 215,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.TestType",
      "displayName": "Update PQM.TestType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 216,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Plant",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Plant",
      "path": "9MDMS.PQM.Plant",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 217,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Plant",
      "displayName": "create PQM.Plant",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 218,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Plant",
      "displayName": "Update PQM.Plant",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 219,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM PlantType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=PlantType",
      "path": "9MDMS.PQM.PlantType",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 220,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.PlantType",
      "displayName": "create PQM.PlantType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 221,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.PlantType",
      "displayName": "Update PQM.PlantType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 222,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Stage",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Stage",
      "path": "9MDMS.PQM.Stage",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 223,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Stage",
      "displayName": "create PQM.Stage",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 224,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Stage",
      "displayName": "Update PQM.Stage",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 225,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM TestStandard",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=TestStandard",
      "path": "9MDMS.PQM.TestStandard",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 226,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.TestStandard",
      "displayName": "create PQM.TestStandard",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 227,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.TestStandard",
      "displayName": "Update PQM.TestStandard",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 228,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM QualityCriteria",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=QualityCriteria",
      "path": "9MDMS.PQM.QualityCriteria",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 229,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.QualityCriteria",
      "displayName": "create PQM.QualityCriteria",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 230,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.QualityCriteria",
      "displayName": "Update PQM.QualityCriteria",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 231,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Parameter",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Parameter",
      "path": "9MDMS.PQM.Parameter",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 232,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Parameter",
      "displayName": "create PQM.Parameter",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 233,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Parameter",
      "displayName": "Update PQM.Parameter",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 234,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM ProcessType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=ProcessType",
      "path": "9MDMS.PQM.ProcessType",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 235,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.ProcessType",
      "displayName": "create PQM.ProcessType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 236,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.ProcessType",
      "displayName": "Update PQM.ProcessType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 237,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM ProcessSubType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=ProcessSubType",
      "path": "9MDMS.PQM.ProcessSubType",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 238,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.ProcessSubType",
      "displayName": "create PQM.ProcessSubType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 239,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.ProcessSubType",
      "displayName": "Update PQM.ProcessSubType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 240,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM Process",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=Process",
      "path": "9MDMS.PQM.Process",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 241,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.Process",
      "displayName": "create PQM.Process",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 242,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.Process",
      "displayName": "Update PQM.Process",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 243,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM PlantConfig",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=PlantConfig",
      "path": "9MDMS.PQM.PlantConfig",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 244,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.PlantConfig",
      "displayName": "create PQM.PlantConfig",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 245,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.PlantConfig",
      "displayName": "Update PQM.PlantConfig",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 246,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM PlantAddress",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=PlantAddress",
      "path": "9MDMS.PQM.PlantAddress",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 247,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.PlantAddress",
      "displayName": "create PQM.PlantAddress",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 248,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.PlantAddress",
      "displayName": "Update PQM.PlantAddress",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 249,
      "name": "MDMS",
      "url": "url",
      "displayName": "Manage PQM WasteType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "navigationURL": "/workbench-ui/employee/workbench/mdms-search-v2?moduleName=PQM&masterName=WasteType",
      "path": "9MDMS.PQM.WasteType",
      "leftIcon": "dynamic:ContractIcon"
    },
    {
      "id": 250,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.WasteType",
      "displayName": "create PQM.WasteType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 251,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.WasteType",
      "displayName": "Update PQM.WasteType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
   "id": 358,
   "name": "Search  PQM Application",
   "url": "/mdms-v2/v2/_search",
   "displayName": "Search PQM Applications",
   "orderNumber": 0,
   "enabled": false,
   "serviceCode": "PQM",
   "code": "null",
   "path": ""
  },
   {
      "id": 364,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_create/PQM.SourceType",
      "displayName": "create PQM.SourceType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 365,
      "name": "MDMS",
      "url": "/mdms-v2/v2/_update/PQM.SourceType",
      "displayName": "Update PQM.SourceType",
      "orderNumber": 1,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
      {
      "id": 23,
      "name": "Profile Update",
      "url": "/user/profile/_update",
      "displayName": "Profile Update",
      "orderNumber": 1,
      "enabled": false,
      "serviceCode": "ADMIN",
      "code": "null",
      "path": "Administration.Profile Update"
    },
    {
      "id": 26,
      "name": "Update Password",
      "url": "/user/password/_update",
      "displayName": "Update Password",
      "orderNumber": 1,
      "enabled": false,
      "serviceCode": "ADMIN",
      "code": "null",
      "path": "Administration.Update Password"
    },
     {
      "id": 370,
      "name": "Create Workbench UiSchema",
      "url": "/mdms-v2/v2/_create/Workbench.UISchema",
      "displayName": "Create workbench ui-schema",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "MDMS",
      "code": "null",
      "path": ""
    },
    {
      "id": 202,
      "name": "Update Tenant Tenants",
      "url": "/mdms-v2/v2/_update/tenant.tenants",
      "displayName": "Update Tenant Tenants",
      "orderNumber": 0,
      "enabled": true,
      "serviceCode": "PQM",
      "code": "null",
      "path": ""
    }

data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json:

 {
      "rolecode": "MDMS_ADMIN",
      "actionid": 202,
      "actioncode": "",
      "tenantId": "pg"
    },
  {
      "rolecode": "MDMS_ADMIN",
      "actionid": 370,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 26,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_ADMIN",
      "actionid": 26,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_TP_OPERATOR",
      "actionid": 26,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "HRMS_ADMIN",
      "actionid": 26,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "SUPERUSER",
      "actionid": 26,
      "actioncode": "",
      "tenantId": "pg"
    },
     {
      "rolecode": "MDMS_ADMIN",
      "actionid": 23,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_ADMIN",
      "actionid": 23,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_TP_OPERATOR",
      "actionid": 23,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "HRMS_ADMIN",
      "actionid": 23,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "SUPERUSER",
      "actionid": 23,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 364,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 365,
      "actioncode": "",
      "tenantId": "pg"
    },
  {
      "rolecode": "MDMS_ADMIN",
      "actionid": 358,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "SUPERUSER",
      "actionid": 358,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_ADMIN",
      "actionid": 358,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "PQM_TP_OPERATOR",
      "actionid": 358,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 346,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 347,
      "actioncode": "",
      "tenantId": "pg"
    },
{
      "rolecode": "MDMS_ADMIN",
      "actionid": 357,
      "actioncode": "",
      "tenantId": "pg"
    },
     {
      "rolecode": "MDMS_ADMIN",
      "actionid": 201,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 202,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 203,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 204,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 205,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 206,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 207,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 208,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 209,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 210,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 211,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 212,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 213,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 214,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 215,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 216,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 217,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 218,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 219,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 220,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 221,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 222,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 223,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 224,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 225,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 226,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 227,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 228,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 229,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 230,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 231,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 232,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 233,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 234,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 235,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 236,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 237,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 238,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 239,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 240,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 241,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 242,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 243,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 244,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 245,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 246,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 247,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 248,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 249,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 250,
      "actioncode": "",
      "tenantId": "pg"
    },
    {
      "rolecode": "MDMS_ADMIN",
      "actionid": 251,
      "actioncode": "",
      "tenantId": "pg"
    }

PQM.Benchmark

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.QualityTestLab

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.Material

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.Parameter

Field

Definition

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.

PQM.PlantConfig

Field

Definition

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.

PQM.PlantType

Field

Definition

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.

PQM.ProcessType

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.Unit

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.WasteType

Field

Definition

code

Alphanumeric or numeric representation assigned to uniquely identify the field.

name

Textual or human-readable identity given to a record.

PQM.SourceType

Field

Definition

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.

PQM.Stage

Field

Definition

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.

PQM.Process

Field

Definition

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.

PQM.Plant

Field

Definition

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

PQM.QualityCriteria

Field

Definition

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.

PQM.TestStandard

Field

Definition

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.

FSM Functional Specification

Desludging Operator Registration

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:

Field Name

Type

Mandatory

Editable (Y/N)

Unique within a ULB (Y/N)

Vendor name

Free text

Gender

Array

DOB

Date

Email address

Free text (Email format)

Mobile number

Number

Door number

Free text

Plot number

Free text

Building name

Free text

Street

Free text

Pincode

Free text

City

Array

Locality/mohalla

Array

Landmark

Free text

Additional Details

Free text

Status

Binary

Driver Registration

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:

Field name

Type

Mandatory

Editable (Y/N)

Unique within a ULB (Y/N)

Driver name

Free text

Driver license number

Free text (Validation on the license format)

Gender

Array

DOB

Date

Email address

Free text (Email format)

Driver phone number

Number

Vehicle Registration

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:

Field name

Type

Mandatory

Editable (Y/N)

Unique within a ULB (Y/N)

Registration number

Free Text

Vehicle model

Array

Vehicle type

Array

Tank capacity

Array

Pollution certificate valid till

Date

Insurance valid till

Date

Road tax paid till

Date

Fitness certificate valid till

Date

Vehicle owner name

Free text

Vehicle owner phone number

Number

Apply for Desludging Services

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.

Field name

Type

Mandatory

Editable

Comments

Applicant name

Text

Mobile number

Numeric

Gender

Dropdown

City

Dropdown

As per the boundary data defined.

Locality

Dropdown

As per the boundary data defined.

Whether property is in a slum

Binary

Slum name

Dropdown

Only if the above selection is yes. List of slums per ULB to be uploaded in the system.

Street name

Text

Door house number

Text

Landmark

Text

Geo location

Lat-Long

As per DIGIT standards.

Onsite sanitation type

Dropdown

Select one from the list.

PIT size

L*B*D in feet (This UOM might change from state to state)

Numeric

Property type

Dropdown

Use the same ontology as defined in DIGIT Property Tax.

Property sub-type

Dropdown

Use the same ontology as defined in DIGIT Property Tax.

Number of trips required

Numeric

Editable by ULB and DSO.

Vehicle capacity

Dropdown

Populated as per the vehicle capacities available in the particular ULB.

Application channel

Dropdown

Required only if the creator is a ULB official.

Total amount

Numeric, display only

Calculated based on the billing slabs.

Minimum amount payable

Numeric, display only

Displayed as per the configuration in the backend.

Advance amount

Numeric

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.

Update Application Request by ULB Official

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.

Application view by DSO

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.

Field name

Type

Required

Comments

Volume of waste collected

Numeric

Feedback by Citizen

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.

Vehicle Entry by FSTP/STP Plant Operator

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.

Field name

Type

Required

Comments

Vehicle in-time

Time

Vehicle out-time

Time

Volume of sludge dumped

Numeric

Additional details

Text

Attachments

Document/Image

If a vehicle without a corresponding request arrives at the FSTP, the FSTP can record the vehicle entry.

Field name

Type

Required

Comments

Vehicle number

Alphanumeric

Only unregistered vehicles in the system.

DSO name

Text

Locality

Text

Vehicle in-time

Time

Vehicle out-time

Time

Volume of sludge dumped

Numeric

Additional details

Text

Attachments

Document/Image

The DSO can also decline an incoming vehicle.

Attribute

Type

Required?

Comments

Vehicle

UUID

Trip Number

Numeric

Volume

Numeric

Desludging request

UUID

Reason for declining

String

[ “Septage Source”, “Outside operational hours”, “Under Maintenance”]

Feedback by Citizens

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.

Reports

Daily desludging request report

Search criteria

Field name

Type

Required

ULB name

Default

Internally pass the ULB name (Y)

From date

Date

To date

Date

DSO name

N - Auto-populate on typing a few letters.

Search result

Application number

Application date

Current Status

DSO Name

Amount (Rs)

Date of completion

Area-wise daily collection report

Search criteria

Field name

Type

Required

ULB name

Dropdown

Internally pass this info.

Mohalla

Dropdown

DSO

N - Auto-populate on typing few characters.

From date

Date

To date

Date

Search result

Application number/Date

Mohalla

DSO Name

Status

SLA compliance

Volume of waste collected

FSTP/STP plant report with vehicle logs

Search criteria

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

N - Auto-populate on typing a few letters.

Vehicle number

Dropdown

Populate only if the DSO name is selected.

From date

Date

To date

Date

Search result

Application number

DSO name /Vehicle number

Vehicle entry date

Vehicle in time

Vehicle out time

Volume of sludge dumped (L)

Dashboard

Filter criteria

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.

Selection criteria

Field Name

Type

Comments

Denomination

Array

Choose the denominate between Cr, Lac and Unit.

Other functionalities:

Share via:

a. Image: Downloads image

b. Whatsapp: Image shared via Whatsapp

Download:

a. Image format

Chart name

Chart type

X Axis

Y Axis

Logic

Comments

Tooltip (if any)

Drilldown available (Y/N)

Overview: Total requests

KPI

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.

Overview: Total sludge treated (in KL)

KPI

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.

Overview: Total collection

KPI

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.

Overview: SLA compliance

KPI

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.

Overview: Citizen average rating

KPI

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.

Total cumulative collection

Area chart

Month

Total collection

Cumulative collection over a period of time.

- Month name - Value

Revenue by property type

Pie chart

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.

Top 3 performing ULBs (SLA achievement)

Percentage completion on line chart

Average SLA per ULB.

Top 3 to be displayed. View more options available to view the entire list of ULBs.

Bottom 3 performing ULBs (SLA achievement)

Percentage completion on line chart

Average SLA per ULB

Bottom 3 to be displayed. View more options available to view the entire list of ULBs.

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

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

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.

Workflow Desludging Application

Advance Balance Workflow

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

Pay Later Workflow

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

Zero Price Workflow

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

User Stories

User Story 1: Register Testing Standards

Scope:

This user story aims to enable the state and the urban local body (ULB) admin to define the input/output quality testing requirements, including testing parameters, benchmarks, and frequencies for each treatment process and stage in the plant. It also allows them to specify different standards for manual and IoT-based testing for particular input/output types and stages. No UI is required for the same.

Actors:

- State admin

- ULB admin

Details:

- Setup plants, treatment process and stages, and map plants to the treatment process and stages.

- Plants may contain one or more treatment processes, each with a treatment process type and capacity.

- A treatment process will contain multiple stages.

- The state or ULB admin can define input/output testing requirements for each treatment process type and stage.

- They can enable or disable testing for specific input/output types and stages.

- They can define testing parameters, benchmarks, and frequencies at the national/state level.

- They can adjust testing frequencies for plants based on their testing results.

- They can specify different testing standards for manual and IoT-based testing for specific input/output types and stages.

Attributes Table

Treatment process

Attribute

Type

Mandatory

Comments

Validation Required?

Treatment Process ID

Numeric

Auto-generated numeric value which will act as a unique identified for a process flow.

N, this value should be system-generated.

Process Name

Text

This is the commonly-used identifier for the process flow.

Max characters - 256

Status

Array

Status of the process flow.

Active/Inactive, Single Select

Treatment Process Type

Array

The dropdown will be auto-populated basis the list of waste maintained in the MDMS.

Single Select

Treatment Process Sub-type

Array

The dropdown will be auto-populated basis the list of waste maintained in the MDMS.

Single Select

Plants

Attribute

Type

Mandatory

Comments

Validation Required?

Plant ID

Numeric

Auto-generated numeric value which will act as a unique identifier for a plant.

Auto-generated

Plant Name

Text

This is the commonly-used identifier for the plant

Maximum characters - 128

Plant Type

Array

Single Select only, Faecal Sludge, Solid Waste, Co-treatment

Tenant Id

Text

Status

Array

Status of the plant

Active/Inactive, Single Select

Geolocation

Lat,Long

Capture the exact latitude-longitude

Stages:

Attribute

Type

Mandatory

Comments

Validation Required?

Stage ID

Numeric

Auto-generated numeric value which will act as a unique identifier for a job ID.

Auto-generated

Stage Name

Text

This is the commonly-used identifier for the job.

Maximum characters - 128

Minimum Characters - NA

Status

Boolean

Status of the stage.

Active/Inactive, Single Select

Input Quality Measurement Required

Boolean

This selection will allow the user to setup if the input quality for the particular input type needs to be monitored. The user should be able to enable and disable input quality measurement requirement independently for each type.

Yes/No, Single Select

Output Type

Array

The dropdown will be auto-populated basis the list of output types.

Multi-select

Output Quality Measurement Required

Boolean

This selection will allow the user to setup if the output quality for the particular job needs to be monitored. The user should be able to enable and disable output quality measurement requirement independently for each type.

Yes/No, Single Select

Testing Parameters

Attribute

Type

Mandatory

Validation

Quality Parameter

Array

Selecting from the predefined of the above-mentioned quality parameters and standards, Single Select.

Quality Parameter Unit of Measurement

Array

Selection of unit of measurement (mg/L, Absolute value etc.), Single Select.

Benchmark Rule

Array

Options include X>=,<=R, =<Y and >=Z, Single Select.

Benchmark Value

Numeric

Entered by user, numeric only.

Testing Frequency - Manual (Days)

Numeric

Selecting a custom frequency range for laboratory testing based on consent to operate, numeric only.

Monitoring Frequency - Quality Sensor (Days)

Numeric

Selecting a custom frequency

Note: Should be optional if the ULB/State chose NOT to have sensor-based monitoring, numeric only.

Configurations:

This feature can be managed through backend configurations and databases, allowing administrators to make changes easily.

User Actions:

- A state or ULB admin can define the input/output testing requirements for each treatment process and stage.

- They can enable or disable testing for specific input/output types and stages.

- They can define and edit testing parameters, benchmarks, and frequencies at the national/state level.

- They can adjust testing frequencies for plants based on their testing results.

- They can specify different testing standards for manual and IoT-based testing for specific input/output types and stages.

Notifications:

No specific notifications are required for this user story.

User Interface:

N/A

Acceptance Criteria:

1. A state and ULB admin can define input/output testing requirements for each treatment process and stage.

2. They can enable or disable testing for specific input/output types and stages.

3. Testing parameters, benchmarks, and frequencies can be defined and managed at the national/state level.

4. Administrators can adjust testing frequencies for plants based on their testing results.

5. Different testing standards can be specified for manual and IoT-based testing for specific input/output types and stages.

User Story 2: Generate Schedule

Scope

This user story aims to automate the generation of schedules for tests based on the frequency of testing for various parameters. The generated schedule will be used for manual and IoT tests to display upcoming tests, generate alerts, and facilitate escalation in case of non-adherence to the test schedule.

Actors:

DIGIT Sanitation

Details:

As a system, I want to automatically generate schedules for tests based on the frequency of testing for various parameters. This will help in displaying upcoming tests to the plant operator and stakeholders, generate alerts for upcoming tests, and escalate in case of non-adherence to the test schedule.

Workflow:

Attributes Table:

Attribute

Type

Mandatory

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 the lab.

Parameter 1…n

Text

View Only

Auto-populated on the creation of schedule.

Testing Date

Date

View Only

Date calculated through a 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'.

Configurations:

This feature can be managed through backend configurations and databases, allowing administrators to make changes easily.

User Actions:

- The system will automatically generate schedules for tests based on the frequency of testing for various parameters.

- Plant operators and stakeholders can view the upcoming tests on the schedule.

- Alerts will be automatically generated for upcoming tests to notify the relevant parties.

- In case of manual testing, escalations will be triggered if test results are pending beyond the specified days as per the test schedule.

Notifications:

- Alerts will be sent to the the plant operator and stakeholder [X] days prior to the test date.

- Escalations will be triggered for pending test results as per the test schedule.

User Interface:

N/A

Acceptance Criteria:

1. The system should automatically generate schedules for tests based on the frequency of testing for each parameter.

2. Upcoming tests should be displayed to the plant operator and stakeholders.

3. Alerts should be generated for upcoming tests to notify the relevant parties.

4. Escalations should be triggered in case of non-adherence to the test schedule for manual testing.

5. The implementation of this feature should allow for easy configuration and management through backend settings.

User Story 3: Anomaly Detection 1.0

Scope:

This user story aims to implement an anomaly detection system that generates alerts in case of the following anomalies:

1. Lab results not as per the benchmark.

2. IoT device results not as per the benchmark.

3. Lab results and device results do not match.

Actors:

- Test uploader

- IoT system

- DIGIT Sanitation

Details:

As a system, I want to detect anomalies in the test results and generate alerts for the following scenarios:

Attributes Table:

Field

Data Type

Required

Description

Anomaly Type

String

Yes

Specifies the type of anomaly detected.

Benchmark

Float

Yes

Defines the benchmark value for the test results.

Deviation Allowed

Float

Yes

Specifies the allowed deviation from the benchmark for anomaly detection.

Sample Collection Date

DateTime

Yes

The date on which the sample was collected for testing.

IoT Result Date

DateTime

Yes

The date on which the IoT result was recorded.

Alert Generation Date

DateTime

Yes

The date on which the alert was generated.

Lab Test Result

Float

Yes

The result of the manual lab test.

IoT Test Result

Float

Yes

The result recorded via IoT integration.

Alert Message

String

Yes

Specifies the message for the generated alert.

Matching Date

DateTime

Yes

The date on which the closest IoT result is matched with the sample collection date for comparison.

Workflows:

Lab results not as per the benchmark

This is to be generated when the manual test results uploaded by the test uploader are not as per the benchmarks defined (adjusted for deviations, configurable at plant level).

IoT results not as per the benchmark

This is to be generated when the loT test results recorded via the integration are not as per the benchmarks defined for [X] days (adjusted for deviations defined while setting testing parameters).

Generation of alerts: Device results and lab results do not match

In case the data that is recorded by the sensor does not match the data in the lab test result, an auto alert will generated.

Date to be matched on

Sample Collection Date

If the IoT result is not available for the sample collection date, the closest date after for which IoT data available to be considered.

Deviation allowed

Validations:

- Anomaly types, benchmark values, and allowed deviations should be specified for each scenario.

- The matching date for comparing IoT results should be calculated based on the sample collection date and the closest available IoT result date.

- Anomalies should be detected and alerts generated only if the deviation from the benchmark exceeds the allowed deviation.

Configurations:

- The anomaly detection system should be configurable to define benchmark values, allowed deviations, and matching date logic.

User Actions:

- The test uploader uploads manual lab test results.

- The integration system records IoT test results.

- DIGIT Sanitation continuously monitors the test results.

- Alerts are automatically generated if anomalies are detected.

Notifications:

- Alerts will be generated automatically when any of the specified anomalies are detected.

- The alert message will indicate the type of anomaly and the details of the test results.

Acceptance Criteria:

1. The system should be able to detect and generate alerts for the specified anomalies, including lab results not meeting benchmarks, IoT results not meeting the benchmark, and lab and IoT results not matching

2. The allowed deviation for each anomaly type should be configurable.

3. The anomaly detection should be based on the benchmark values set for each type of test result.

4. Alerts should be generated with the appropriate message indicating the type of anomaly detected and the details of the test results.

5. The implementation should allow for easy configuration and management through backend settings.

User Story 4: Anomaly Detection 2.0

Scope:

This user story aims to implement an automated alert generation system for cases where no reading is received from a sensor based on the scheduled frequency.

Actors:

- Integration system

- DIGIT Sanitation

Details:

As a system, I want to automatically generate an alert in case no reading is received from a sensor based on the scheduled frequency.

Workflow:

Attributes Table:

No reading received from device

Attribute

Type

Required?

Comments

Alert DateTime

Datetime

Auto-captured based on the date-time.

Alert Type

Text

Auto-captured

No reading received from the device.

Plant Name

Text

Auto-captured

Process Name

Text

Auto-captured

Process Type

Text

Auto-captured

Device ID

Numeric

Auto-captured

Validations:

- The system should check if a reading was expected from the sensor on the scheduled date.

- An alert should be generated only if no reading is received from the sensor on the scheduled date.

Configurations:

- The alert generation system should be configured to specify the frequency of expected readings from each sensor.

User Actions:

- The integration system monitors the scheduled frequency of readings from the sensors.

- The alert generation system automatically detects cases where no reading is received from a sensor based on the scheduled date.

Notifications:

- An alert will be generated automatically if no reading is received from a sensor based on the scheduled date.

- The alert message will indicate the sensor ID and the scheduled date for the next reading.

Acceptance Criteria:

1. The system should automatically detect cases where no reading is received from a sensor on the scheduled date.

2. Alerts should be generated with the appropriate message indicating the sensor ID and the scheduled date for the next reading.

3. The alert generation should be based on the configured frequency of expected readings from each sensor.

4. The implementation should allow for easy configuration and management through backend settings.

User Story 5: Landing Page: Plant Operator

Scope:

As a plant operator, I want to access the home page after logging in to the system. The landing page should provide an overview of relevant modules, pending tasks, and options to navigate to the specific sections.

Actors:

Plant operator

Details:

Upon successful login, the plant operator will be directed to the home page. The home page will display the following elements:

Plant name: A visible label located on the top right-hand corner of the screen, indicating the name of the plant or facility the operator is associated with.
Help button: A clickable button available on every page to provide a guided view and assistance for users.
Modules cards: The home page will show cards for the following modules:

a) Vehicle Log Module: Allows the user to record incoming vehicles.

b) Treatment Quality Monitoring module: Provides access to information related to treatment quality.

c) View Dashboard: Navigates the user to a comprehensive dashboard.

List of pending tasks: This section will display a list of tests and tasks pending for the plant operator within the next [X] days. Alongside each pending task, the next action item in the workflow will be displayed, enabling the plant operator to take prompt action.
View all pending tasks button: A clickable button that redirects the user to a page displaying all pending tasks.

Attributes:

N/A

Validations:

N/A

Configurations:

N/A

User Actions:

The plant operator can click on the cards representing different modules to navigate to their respective home pages for detailed information and functionalities.
The plant operator can click on the "View All Pending Tasks" button to view all pending tasks in the system.

Notifications:

N/A

User Interface:

Acceptance Criteria:

The plant operator should be able to log in successfully and land on the home page.
The home page should display the plant name, help button, and cards for the different modules.
The list of pending tasks should be visible and filtered based on the defined time frame [X].
Each pending task should display the next action item required.
Clicking on the cards should redirect the user to the respective module's home page.
Clicking on the "View All Pending Tasks" button should redirect the user to a page displaying all pending tasks.

User Story 6: Treatment Quality Monitoring (TQM) Home Page

Scope:

As a plant operator, I want to access the Treatment Quality Monitoring (TQM) home page by clicking on the treatment quality card. The TQM home page should provide access to upcoming tests, past test results, IoT readings, sensor monitoring, treatment quality dashboard, and performance metrics related to treatment quality.

Actors:

Plant operator

Details:

After clicking on the treatment quality card, the plant operator will be redirected to the TQM home page, which will offer the following functionalities:

Inbox: The inbox will display the upcoming tests, and the plant operator can take necessary actions related to these tests. A count of the upcoming tests for quick reference will be displayed in brackets.
View past test results: This section will present the past results from both ab and IoT devices, allowing the plant operator to review historical data.
View IoT readings: The user can access records of IoT readings, enabling them to monitor IoT devices' data.
Sensor monitoring: A list of IoT devices and their status will be available for the plant operator to monitor and ensure smooth operations.
View dashboard: Clicking on this option will direct the plant operator to the treatment quality dashboard, providing comprehensive insights and visualisations.
View performance: This widget will display key performance indicators (KPIs) related to treatment quality, including:

a. Test compliance: The percentage of plant compliance with treatment quality standards, compared to the state-level compliance percentage.

b. Last treatment quality result: Indicates whether the last test result was a pass or fail, along with the date of the test.

c. Count of alerts raised in the past 30 days: Shows the number of alerts generated within the last 30 days.

d. Distribution of alerts based on the alert category: Presents a breakdown of alerts by their respective categories. (Note: For details about the calculation of these metrics, refer to the dashboard user stories).

e. Go back to the landing page: The plant operator can use the back button to return to the landing page.

f. Help button: A clickable button available on every page to provide a guided view and assistance for users.

Attributes Table:

N/A

Validations:

N/A

Configurations:

N/A

User Actions:

The plant operator can view upcoming tests in the inbox and take necessary actions related to them.
The plant operator can review past test results from both Lab and IoT devices.
The plant operator can access records of IoT readings for monitoring purposes.
The plant operator can check the status of IoT devices through sensor monitoring.
The plant operator can navigate to the treatment quality dashboard for comprehensive insights.
The plant operator can view the performance metrics related to the treatment quality.
The plant operator can use the back button to return to the landing page.

Notifications:

N/A

User Interface:

Acceptance Criteria:

The plant operator should be able to access the TQM home page by clicking on the treatment quality card.
The TQM home page should display the inbox with the upcoming tests and their count.
The plant operator should be able to view the past test results from lab and IoT devices.
The plant operator should be able to access the records of IoT readings.
The plant operator should be able to monitor IoT devices and their statuses.
Clicking on "View Dashboard" should redirect the plant operator to the treatment quality dashboard.
The performance metrics should accurately display test compliance, last treatment quality result, count of alerts raised in the past 30 days, and distribution of alerts based on their categories.
The back button should allow the plant operator to return to the landing page.
The help button should be available and functional on the TQM home page.

User Story 7: View List of Upcoming Tests

Scope:

As a plant operator, I want to view a list of the upcoming tests by clicking on the 'Inbox' option. The list should display only lab tests, and I should be able to perform various tasks, such as filtering, sorting, and accessing the test details.

Actors:

Plant operator

Details:

Upon clicking on the 'Inbox', the plant operator will be redirected to the list of upcoming lab tests. The following functionalities will be available:

Total count of the upcoming tests: The total count of the upcoming tests will be displayed beside the inbox, enclosed within brackets.
View list of the upcoming tests: The list will contain the following fields:

- Test ID

- Treatment process (if there is only one treatment process configured for the plant, this field will not be displayed)

- Stage: Indicates the process stage where the sample is to be collected from.

- Output type: Specifies whether the test is for biosolids or effluents.

- Pending date: The scheduled test date.

- Status: The current status of the test.

- SLA: Displays the difference between the test due date and today.

Workflow:

Attributes Table:

Attribute

Type

Mandatory

Validation

Test ID

Alphanumeric

View Only

Auto-generated on the creation of the schedule.

Plant Name

Text

View Only

Auto-populated on the creation of the schedule.

Treatment Process

Text

View Only

Auto-populated on the creation of the schedule.

Treatment Process Type

Text

View Only

Auto-populated on the creation of the schedule.

Stage

Text

View Only

Auto-populated on the creation of the schedule.

Output Type

Text

View Only

Auto-populated on the creation of the schedule.

Test Type

Array

Lab/IoT, auto-selected to the lab.

Parameter 1…n

Text

View Only

Auto-populated on the creation of the schedule.

Testing Date

Date

View Only

Date calculated through predefined laboratory testing schedule.

SLA

Numeric

View Only

Status

Text

View Only

Status to be auto set to 'Scheduled'.

Test Result Status

Roles

Action

Next Status

Scheduled

FSTPO

ULB employee

Submit the sample for testing.

Pending results

Pending Results

FSTPO

ULB employee

Update the results.

Submitted

Configurations:

N/A

User Actions:

The plant operator can view a list of the upcoming tests with the relevant details.
The plant operator can use filters to refine the view based on the treatment process, output type, status, and date range.
The plant operator can use sorting options to arrange the tests based on "Pending Date."
The plant operator can access test details for further actions.

Notifications:

N/A

User Interface:

Acceptance Criteria:

The plant operator should be able to view the list of the upcoming lab tests by clicking on 'Inbox'.
The list should only display the lab tests.
The list of the upcoming tests should contain relevant fields as described in the user story.
The action item displayed should be based on the next status in the treatment quality workflow for each test.
The filters and sorting options should work correctly, and the data should be updated based on the selected criteria.
The user should be able to navigate back to the landing page using the back button.
The help button should be available and functional on the list of upcoming tests page.

User Story 8: View Test Details

Scope:

As a plant operator, I want to view the test details for the upcoming tests either via the pending tasks or the inbox. The test details page will provide comprehensive information about the test and allow me to perform specific actions based on the test's status.

Actors:

Plant operator

Details:

View test details via the pending tasks:

The list of pending tasks can be accessed via the landing page for the Treatment Quality Monitoring (TQM).
The list will display the tests pending within the next [X] days.
The next action item in the task workflow will be displayed as a button beside each pending task for the plant operator to take prompt action.
Clicking on the action item button will redirect the user to the test details page.

View test details via the inbox:

A list of tests can be accessed from the Inbox.
An action item will be displayed based on the next status in the treatment quality workflow for each test:

- For tests in the 'Scheduled' stage, the "Update Status" will be shown.

- For tests in the "Pending Results" stage, the "Update Results" will be displayed.

Clicking on the action item button will redirect the user to the test details page.

Test details page:

It will consist of two cards. First card - Test Information: 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 (Displayed in red/green basis SLA. If today is greater than the pending date, it will be shown in red. If today is less than the Pending Date, it will be shown in green.)

Second card - Test status specific action: The second card will vary based on the test status:

For tests in the 'Scheduled' status, the user will be asked to select the lab.
For tests in the "Pending Results" status, the user will be asked to add test results.

Go back using the back button:

The user can go back using the back button, and the redirection will be based on the page from which the user accessed the test details page (either pending tasks or inbox).

Help button:

A clickable button available on every page to provide a guided view and assistance for users.

Test Attributes:

Attribute

Type

Required?

Comments/Validations

Test ID

Numeric

Auto-generated by the system.

Plant Name

Array

View Only

Auto-populated on the creation of the schedule, dingle 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 the schedule, single select for on-demand test.

Stage

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Output Type

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Test Type

Array

Lab/IoT, auto-selected to the lab for on-demand.

Lab Submitted to

Text

This will not be required in case test type = IoT.

Quality Parameter 1

Numeric

Validation to be applied at impel.

Quality Parameter 2

Numeric

Validation to be applied at impel.

Quality Parameter 3

Numeric

Validation to be applied at impel.

Quality Parameter n

Numeric

Validation to be applied at impel.

Collection Time

Date

This is the date-time on which user updates the status to pending results. For IoT, this is the time sensor records reading.

Attachment

Document

For a given collection location, the photo or PDF proof of the laboratory result mentioning the information of the above-mentioned parameters.

Configurations:

N/A

User Actions:

The plant operator can view test details either via the pending tasks or the Inbox.
The plant operator can perform specific actions based on the test's status, such as updating the status or adding test results.

Notifications:

N/A

User Interface:

Acceptance Criteria:

The plant operator should be able to view the test details via the pending tasks or the inbox.
The test details page should display accurate information, including test ID, treatment process, stage, output type, pending date, status, parameters, unit of measurement, and SLA.
The second card on the test details page should prompt the plant operator to take the appropriate action based on the test's status ("Select Lab" for tests in the 'Scheduled' status and "Add Test Results" for tests in the "Pending Results" status).
The plant operator should be able to navigate back using the back button, and the redirection should be appropriate based on the page from which the test details page was accessed.
The help button should be available and functional on the test details page.

User Story 9: Update Tests

Scope:

As a plant operator, I want to update the test details from the test details page. The test details page will display the next action item based on the workflow status of the test. I should be able to perform different actions depending on whether the test is in the 'Scheduled' status or the "Pending Results" status.

Actors:

- Plant operator

Details:

Updating tests with the workflow status 'Scheduled':

- The test details page will prompt the plant operator to confirm if the sample has been submitted to the lab for testing.

- The user can perform the following actions:

- Select lab: The plant operator can choose a lab from a dropdown list configured in the Master Data Management System (MDMS).

- Update the status of the test: The button to update the test status will be deactivated until the lab is selected. Once the lab is chosen, the button will be activated.

- After clicking on "Update Status," the plant operator will be redirected back to the page from which the test details were accessed. A snack bar will confirm the status update, and the action item button will show the updated next step in the workflow.

- In case the update of the status fails, the plant operator will remain on the same page, and a failure message will be displayed.

Updating tests with the workflow status "Pending Results":

- The test details page will prompt the plant operator to fill in the test results.

- The user can perform the following actions:

- Update parameter readings (mandatory fields): Only numerical values will be allowed. In case non-numerical values are entered, an error message will be displayed, stating "Only numeric values allowed. Please input in the required format."

- Attach documents (non-mandatory): Only files in the formats .png, .jpg, .pdf will be supported. If a file of an unsupported format is selected, an error message will be displayed, stating: "The file type is not supported. Please upload in the following formats: .pdf, .png, .jpg." The file size should be within the permissible limit (X mb), and if the file size is larger, an error message will be displayed, stating: "The file size is too large. Please upload a file below X MB."

- Submit the test results: The button to submit the test results will be deactivated until all mandatory fields are filled. Once all required fields are completed, the button will be activated.

- On clicking the 'Submit' button, a pop-up will be displayed to the user to confirm the submission.

- The following actions will be available to the user in the pop-up:

- Confirm submission: The plant operator can confirm the submission by clicking on the 'Submit' button.

- Go back to the test details page: The plant operator can go back to the test details page by clicking on the "Go back" button.

- In case the submission of test results fails, the plant operator will remain on the same page, and a failure message will be displayed.

After the successful submission of the test results:

- Upon successful submission, the plant operator will be redirected to the summary page, and a snack bar will confirm the submission.

- The summary page will display the test results and whether they have passed or failed based on a comparison between the values entered by the user and the benchmarks.

- If all values are as per the benchmarks, the test results will be displayed as 'Pass'. All values will be shown in green, and the plant operator will receive feedback that all results are as per the benchmarks. The plant operator can go back to the home page by clicking on the back button.

- If one or more values are not as per the benchmarks, the test results will be displayed as 'Fail'. Values that meet the benchmarks will be shown in green, while values not meeting the benchmarks will be shown in red. The plant operator will be informed that the test results are not as per the benchmark. The plant operator can go back to the home page by clicking on the back button.

Workflow:

Functional Specifications for Tests:

Attribute

Type

Required?

Comments/Validations

Test ID

Numeric

Auto-generated by the system.

Plant Name

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Treatment Process

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Treatment Process Type

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Stage

Array

View Only

Auto-populated on the creation of the schedule, dingle select for on-demand test.

Output Type

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Test Type

Array

Lab/IoT, auto-selected to the lab for on-demand.

Lab Submitted to

Text

This will not be required in case test type = IoT.

Quality Parameter 1

Numeric

Validation to be applied at impel.

Quality Parameter 2

Numeric

Validation to be applied at impel.

Quality Parameter 3

Numeric

Validation to be applied at impel.

Quality Parameter n

Numeric

Validation to be applied at impel.

Collection Time

Date

This is the date-time on which user updates the status to pending results. For IoT, this is the time sensor records reading.

Attachment

Document

For a given collection location, the photo or PDF proof of the laboratory result mentioning the information of above-mentioned parameters.

Configurations:

N/A

User Actions:

- The plant operator can update the test details, including lab selection and test status for tests in the 'Scheduled' status.

- The plant operator can fill in the test results for tests in the "Pending Results" status, including numerical values for parameter readings and optional document attachments.

- The plant operator can submit the test results and confirm the submission.

- The plant operator can go back to the test details page or the home page .

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The plant operator should be able to update the test details for tests in both 'Scheduled' and "Pending Results" status.

- The test details page should prompt the plant operator with appropriate actions based on the test's workflow status.

- Validations for numerical values and file formats/sizes should work as described.

- Successful submission of the test results should redirect the plant operator to the summary page and display the results as 'Pass' or 'Fail' based on the benchmarks.

- The plant operator should be able to go back to the test details page or the home page using the appropriate buttons.

- The help button should be available and functional on the test details and summary pages.

User Story 10: View Past Test Results

Scope:

As a plant operator, I want to view past test results (both IoT and lab) by accessing the "Past Tests" section from the Treatment Quality Monitoring (TQM) landing page. I should be able to view a list of past tests, filter and sort them, and access detailed test results for each test.

Actors:

- Plant operator

Details:

View past test results:

- Past test results (both IoT and lab) can be accessed via the TQM landing page by clicking on the "Past Tests" option.

- Clicking on "Past Tests" will redirect the user to the list of past tests.

- The user can perform the following tasks:

1. View the list of past tests:

The list will display the following fields for each test:

- Test ID

- Treatment process (if there is only one treatment process configured for the plant, this field will not be displayed).

- Stage: Indicates the process stage where the sample was collected from.

- Output type: Specifies whether the test is for biosolids or effluents.

- Pending date: The test date as per the schedule.

- Test result: Indicates whether the test result is 'Pass' or 'Fail'.

- View test details: The user can view detailed test results by clicking on the "View Results" button on each card.

2. Filter tests:

Clicking on 'Filter' will open a pop-up with the following filter options:

- Treatment process (if there is only one treatment process configured for the plant, this field will not be displayed): A dropdown with values for treatment processes configured for the plant. The selected treatment process will be displayed upon selection.

- Output type: A dropdown with values for the output types configured for the plant. The selected output type will be displayed upon selection.

- Test type: A dropdown with values for test types (IoT/lab). The selected test type will be displayed upon selection.

- Date range: A calendar view to select a date range. The selected date range will be displayed upon selection.

After selecting the filter values, the user can click on 'Filter' to apply the filters to the list of past tests. To clear filters, the user can click on "Clear All." To close the pop-up, the user can click on the cross on the top right-hand corner of the screen. The selected filter will be displayed on the screen, and clicking the cross button near the displayed filter will remove the filter.

3. Sort:

Clicking on 'Sort' will open a pop-up allowing tests to be sorted by "Pending Date" with the following options:

- Date (latest first).

- Date (latest last).

After selecting the sort criteria, the user can click on 'Sort' to apply the sorting to the list of past tests. To clear the sort, the user can click on "Clear All." To close the pop-up, the user can click on the cross on the top right-hand corner of the screen.

4. Go back to the landing page:

The plant operator can use the back button to return to the landing page.

5. Help button:

A clickable button available on every page to provide a guided view and assistance for users.

The user can download the list of tests, filtered by selection in excel and pdf formats.

Test details:

- The test summary page will consist of two cards.

First card - Test information:

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 submission on

- Test results: Indicates whether the test result is 'Pass' or 'Fail'.

Second card - Parameter details:

The second card will display the following fields:

- Parameters, their unit of measurement, and the recorded values.

- The values will be shown in green or red basis whether they are as per benchmarks or not.

User Actions:

- The plant operator can view past test results by accessing the "Past Tests" section.

- The plant operator can filter and sort the list of past tests based on treatment process, output type, test type, and date range.

- The plant operator can view detailed test results by clicking on the "View Results" button for each test.

- The plant operator can navigate back to the landing page or the list of past tests as needed.

- The help button is available and functional on the test summary page.

Functional Specifications for Tests:

Attribute

Type

Required?

Comments

Test ID

Numeric

Auto-generated by the system.

Plant Name

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Treatment Process

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Treatment Process Type

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Stage

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Output Type

Array

View Only

Auto-populated on the creation of the schedule, single select for on-demand test.

Test Type

Array

Lab/IoT, auto-selected to the lab for on-demand.

Lab Submitted to

Text

This will not be required in case test type = IoT.

Quality Parameter 1

Numeric

Validation to be applied at impel.

Quality Parameter 2

Numeric

Validation to be applied at impel.

Quality Parameter 3

Numeric

Validation to be applied at impel.

Quality Parameter n

Numeric

Validation to be applied at impel.

Collection Time

Date

This is the date-time on which user updates status to pending Results. For IoT, this is the time sensor records reading.

Attachment

Document

For a given collection location, the photo or PDF proof of the laboratory result mentioning the information of above-mentioned parameters.

Validations:

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The plant operator should be able to view past test results by clicking on "Past Tests" from the TQM landing page.

- The list of past tests should display the relevant fields as described in the user story.

- The plant operator should be able to filter and sort the list of past tests based on treatment process, output type, test type, and date range.

- Clicking on the "View Results" button for each test should redirect the plant operator to the test summary page.

- The test summary page should display accurate information, including test ID, treatment process, stage, output type, test type, lab name/device ID, test submission on, test results.

- User can download the list past tests (filtered) by clicking on the download button.

User Story 11: View IoT Results

Scope:

As a plant operator, I want to view IoT readings from the Treatment Quality Monitoring (TQM) landing page by clicking on "View IoT Readings." I should be able to access the view tests page and filter the results to view only IoT readings.

Actors:

- Plant operator

Functionality of the Page:

- The functionality of the view tests page for IoT readings remains the same as the view past tests page.

Attributes Table:

N/A

Validations:

Configurations:

N/A

Details:

View IoT readings:

- IoT readings can be accessed via the TQM landing page by clicking on "View IoT Readings."

- Clicking on "View IoT Readings" will redirect the user to the view tests page, with the filter pre-set to show only IoT readings.

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The plant operator should be able to view IoT readings by clicking on "View IoT Readings" from the TQM landing page.

- The view tests page should display a list of IoT readings with the relevant fields as described in the user story.

- The plant operator should be able to filter and sort the list of IoT readings based on treatment process, output type, and date range.

- Clicking on the "View Results" button for each IoT reading should redirect the plant operator to the test summary page.

- The test summary page for IoT readings should display accurate information, including test ID, treatment process, stage, output type, test type, lab name/device ID, test submission on, test results.

- The plant operator should be able to navigate back to the landing page or the list of IoT readings as needed.

- The help button should be available and functional on the view tests page for IoT readings.

User Story 12: Sensor Monitoring

Scope:

As a plant operator, I want to access sensor monitoring from the Treatment Quality Monitoring (TQM) landing page. I should be able to view a list of IoT devices and their details. Additionally, I should be able to filter the devices based on various criteria and perform a search based on the device ID.

Actors:

- Plant operator

Details:

Sensor monitoring:

- Sensor monitoring can be accessed by clicking on the "Sensor Monitoring" link on the TQM landing page.

- Clicking on "Sensor Monitoring" will display the list of IoT devices.

Details on the Page:

- The page will display the total number of IoT devices beside the page heading in brackets.

- For each device, a card will be available, displaying the following details:

- Device ID.

- Treatment process (if there is only one treatment process configured for the plant, this field will not be displayed).

- Stage: Indicates the process stage where the device is used.

- Output type: Specifies whether the device monitors biosolids or effluents.

- Last calibrated date: The date when the device was last calibrated.

- Device Status: Indicates whether the device is 'Active' or 'Inactive'.

- Verification status: Indicates the verification status of the device.

- Last verification date: The date of the last verification.

- Parameters: The parameters that the device monitors.

User Actions:

- Filter devices:

Clicking on 'Filter' will open a pop-up with the following filter options:

- Output type: A dropdown with values for the output types configured for the plant. The selected output type will be displayed upon selection.

- Device status: A radio button showing options 'Active' and 'Inactive' to filter devices based on their status.

- Parameters: Multi-select displaying all parameters configured on the backend. The plant operator can select multiple parameters to filter devices.

After selecting filter values, the user can click on 'Filter' to apply the filters to the list of IoT devices. To clear filters, the user can click on "Clear All." To close the pop-up, the user can click on the cross on the top right-hand corner of the screen. The selected filter will be displayed on the screen, and clicking the cross button near the displayed filter will remove the filter.

- Search:

Clicking on 'Search' will open a pop-up for the user to search for a device by the device ID. The search should support partial search (part search) to allow the plant operator to find devices quickly based on the device ID.

- Go back to the landing page:

The plant operator can use the back button to return to the landing page.

- Help button:

A clickable button available on every page to provide a guided view and assistance for users.

Device Attributes:

Attribute

Type

Required?

Comments

Configuration Date

Datetime

Device Type

Text

Selection from the device master data.

[“GPS Sensor”, “pH Sensor”, “Accelerometer”, “Light Sensor”]

Plant

Text

Treatment Process

Text

Stage

Text

Output Type

Text

Parameters

Array

The parameters monitored by the device.

Monitoring Frequency

Numeric

Custom frequency for the device.

Calibration Date

Datetime

Input from the user about any change in the calibration or maintenance of the device.

Calibration Accuracy

Array

Range to indicate the permissible deviation in the accuracy.

IsConnected?

Boolean

To indicate the connectivity of the device.

Connectivity History

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 the laboratory results.

Validations:

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The plant operator should be able to access sensor monitoring by clicking on the "Sensor Monitoring" link from the TQM landing page.

- The page should display the list of IoT devices with relevant fields as described in the user story.

- The plant operator should be able to filter devices based on treatment process, output type, device status, and parameters.

- The plant operator should be able to perform a search based on the device ID with partial search support.

- The plant operator should be able to navigate back to the landing page or the list of IoT devices as needed.

- The help button should be available and functional on the sensor monitoring page.

User Story 13: View Dashboard and Overview KPIs

Scope:

As a plant operator, I want to access the dashboards from the Treatment Quality Monitoring (TQM) landing page. I should be able to view different dashboards specific to the treatment process types. Additionally, I should be able to filter the dashboard based on a date range and perform actions like sharing and downloading the dashboard and its charts/tables.

Actors:

- Plant operator

Details:

Dashboards:

- 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 selected treatment process type.

Filters:

- Date range: The user should be able to filter the dashboard based on a date range to view relevant data for the selected time period.

- The user should be able to share the filtered dashboard over WhatsApp in the image format.

- The user should be able to share filtered charts/tables over WhatsApp in the image format.

Download:

- The user should be able to download the filtered dashboard in PDF and image formats.

- The user should be able to download 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 at the plant for the selected time period.

- Number of trips: The 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 compared to the total number of test results recorded.

- Compliance percentage: The percentage of tests where results have been recorded.

- Total alerts: The count of total alerts raised for the following types:

1. Test results not as per the benchmark.

2. No reading from the IoT device.

3. Lab results and IoT results not matching.

Computation of the KPIs can be accessed here.

Attributes Table:

- N/A

Validations:

Configurations:

- N/A

Notifications:

- N/A

User Interface:

Acceptance Criteria:

- The plant operator should be able to access the dashboards by clicking on the "View Dashboards" link from the TQM landing page.

- The user should be able to navigate across the treatment process types and view specific dashboards accordingly.

- The user should be able to filter the dashboard based on a date range to view relevant data for the selected time period.

- The user should be able to share the filtered dashboard and charts/tables over WhatsApp in the image format.

- The user should be able to download the filtered dashboard and charts/tables in PDF and image formats.

- The dashboard should display the specified KPIs for the plant operator to monitor and analyse treatment quality effectively.

User Story 14: Dashboard Card: Treatment Quality Overview

Scope:

As a plant operator, I want to view a dashboard card named "Treatment Quality Overview" on the dashboards page in the Treatment Quality Monitoring (TQM). The card should display the key performance indicators (KPIs) related to treatment quality, a table with relevant fields, and options to filter the data, share the dashboard, and download the data.

Actors:

- Plant operator

Details:

Treatment quality overview dashboard card:

- The "Treatment Quality Overview" card will be available on the dashboards page in TQM.

- KPIs:

- The card will display the following KPIs:

- Total tests: The count of total tests for the filtered date range.

- The count of tests that have passed treatment quality.

- The count of tests that have failed treatment quality.

- Table:

- Heading: Name of the plant

- The table will display the following fields:

- Stage

- Output type

- Value of Parameters

- Compliance percentage

Detailed metric calculations for the Treatment Quality Monitoring dashboard are viewable here.

- Filter:

- The user should be able to filter the data displayed in the card based on a date range. This will allow the plant operator to view data for a specific time period.

- Share:

- The user should be able to share the dashboard card "Treatment Quality Overview" with others over WhatsApp in the image format. This will enable easy sharing of the treatment quality data with relevant stakeholders.

- Download:

- The user should be able to download the data displayed in the "Treatment Quality Overview" card. This should include the KPIs and table data. The download options should include PDF and image formats. This will allow the plant operator to keep a record of the treatment quality data for further analysis and reporting.

- View trends:

- For each stage in the table, a button will be available to "View Trends". Clicking on this button will redirect the user to view trends specific to the selected stage. This will help the plant operator analyse the historical performance of the treatment quality for a particular stage.

- Toggle IoT readings and lab results:

- The user should be able to toggle between viewing the IoT readings and the lab results in the "Treatment Quality Overview" card. This toggle will allow the plant operator to switch between different data sources and gain insights into the treatment quality from different perspectives.

Attributes Table:

- N/A

Validations:

Configurations:

- N/A

Notifications:

- N/A

User Interface Design:

Acceptance Criteria:

- The plant operator should be able to view the "Treatment Quality Overview" card on the dashboards page in TQM.

- The card should display the specified KPIs for the filtered date range.

- The table should show relevant fields, including stage, output type, value of parameters, and compliance percentage.

- The plant operator should be able to filter the data based on a date range to view data for a specific time period.

- The plant operator should be able to share the "Treatment Quality Overview" card with others over WhatsApp in the image format.

- The plant operator should be able to download the data from the "Treatment Quality Overview" card in PDF and image formats.

- The plant operator should be able to view trends for specific stages by clicking on the "View Trends" button in the table.

- The plant operator should be able to toggle between viewing the IoT readings and the lab results in the "Treatment Quality Overview" card.

User Story 15: Dashboard Card: Parameter Trends

Scope:

As a plant operator, I want to view the trends of parameter readings over time for a stagein the treatment quality overview table. The chart should provide a comparison with the benchmark and a toggle to navigate between different parameters.

Actors:

- Plant operator

Details:

Trends of parameter readings:

- The chart will be available once the plant operator clicks on the "View Trend" button in the treatment quality overview table.

- Chart features:

- Parameter trend over time:

- The chart will display the trend of one selected parameter over time.

- The x-axis of the chart will represent time, showing the data points over a specific time period.

- The y-axis will represent the parameter values recorded during that time period.

- Benchmark comparison:

- The chart will include a benchmark line to provide a comparison with the benchmark value for the selected parameter.

- The benchmark line will be displayed on the chart, helping the plant operator visualise how the parameter readings compare to the expected standard.

- Toggle for parameters:

- A toggle will be available to navigate between different parameters for which the trends are available.

- The plant operator can select a different parameter from the toggle to view the trend of that particular parameter.

Attributes Table:

- N/A

Validations:

Configurations:

- N/A

Notifications:

- N/A

User Interface Design:

Acceptance Criteria:

- The plant operator should be able to view the trends of parameter readings after clicking on the "View Trend" button in the treatment quality overview table.

- The chart should accurately display the trend of the selected parameter over time.

- The benchmark line should be visible and appropriately represent the expected standard for the selected parameter.

- The plant operator should be able to toggle between different parameters to view their trends.

User Story 16: Landing Page: ULB Employee

Scope:

As a ULB employee, I want to have a card for Treatment Quality Monitoring (TQM) on the landing page. The card should provide an overview of pending tests and tests nearing SLA, allow me to view upcoming tests using the inbox, access past test results, IoT readings, and sensor monitoring. Additionally, I should be able to view the treatment quality dashboard, and receive alerts related to TQM, which I can view in detail or dismiss.

Actors:

ULB employee

Details:

Landing page: ULB employee

- Treatment Quality Monitoring card:

- The landing page will include a card for Treatment Quality Monitoring.

- Overview:

- The card will provide an overview of the total pending tests and the count of tests nearing SLA.

- View the upcoming tests using the inbox:

- The card will display the count of the upcoming tests beside in brackets.

- The ULB employee can click on the inbox to view the upcoming tests.

- View the past test results:

- The ULB employee can click on a link to view the past results from both lab and IoT devices.

- View IoT readings:

- The ULB employee can click on a link to access the record of IoT readings.

- Sensor monitoring:

- The ULB employee can click on a link to access a list of IoT devices along with their status.

- View dashboard:

- The ULB employee can click on a link to be directed to the treatment quality dashboard.

- Alerts:

- The card will display a list of alerts regarding Treatment Quality Monitoring.

- Specifically, it will display tests that have crossed SLA for greater than 7 days.

- The ULB employee can view the details of each test by clicking on the "View Details" button.

- The ULB employee can dismiss notifications by clicking on the cross button.

- Other functionality:

- The rest of the functionality on the landing page will remain the same as the current ULB employee landing page.

Attributes Table:

- N/A

Validations:

Configurations:

- N/A

Notifications:

- N/A

User Interface Design:

Acceptance Criteria:

- The ULB employee should be able to view the Treatment Quality Monitoring card on the landing page.

- The card should display an overview of the total pending tests and tests nearing SLA.

- The ULB employee should be able to click on the inbox to view the upcoming tests.

- The ULB employee should be able to click on links to view past test results, IoT readings, sensor monitoring, and the treatment quality dashboard.

- The card should display alerts related to TQM and allow the ULB employee to view the details or dismiss them.

- The rest of the functionality on the landing page should remain unaffected.

User Story 17: View Upcoming Tests

Scope:

As a user, I want to view a list of the upcoming lab tests in the Treatment Quality Monitoring (TQM) module by clicking on the inbox. The list should be sorted by the pending date, displaying the test with the highest SLA first. I should be able to see the test ID, plant name, treatment process, pending date, status, and SLA. Additionally, I should be able to filter the tests, search for specific tests by test ID or plant name, and redirect to other pages in the TQM module using the provided links.

Actors:

ULB employee/state employee

Details:

View the list of upcoming tests:

- Inbox navigation:

- The user can click on the inbox to be redirected to the list of upcoming lab tests.

- Total count of upcoming tests:

- The total count of upcoming tests will be displayed beside the inbox in brackets.

- Sorting:

- The list of upcoming tests will be sorted by the pending date, where the test with the highest SLA is displayed first.

- Fields displayed:

- The list of upcoming tests will display the following fields:

- Test ID

- Plant Name

- Treatment Process

- Pending Date: This is the test date as per schedule

- Status: Status of the test

- SLA: The difference between the test due date and today. This will be displayed in red if the test due date is earlier than today, and in green if today is before the test due date.

- View test details:

- The user can view detailed information about a specific test by clicking on the test ID.

- Filters:

- Filters are displayed on the left-hand panel of the screen.

- The following filters are available:

- Treatment process: A multi-select showing values for the treatment processes configured for the urban local body (ULB). The selected treatment processes will be displayed as ticks on the multi-select box. If not selected, it is left blank.

- Stages: A dropdown showing values for the stages configured for the plant. The selected stage is displayed here on selection. If not selected, the field is left blank.

- Status: A multi-select showing values for the status in the treatment quality workflow.

- The user can select values for the filters and click on filter to filter the inbox accordingly.

- To clear the filters, the user can click on the refresh icon on the top right of the filter panel.

- Search:

- The user can search for specific tests using the following:

- Test ID

- Plant name

- Part search is enabled for both fields.

- The user can fill in either the test ID or the plant name or both and click on the search button.

- The user can clear the search by clicking on the clear search link.

- Retaining filters, sort, and search:

- In case filters, sort, or search are applied, and the user navigates to the test details page, on going back, the values of the filters, sort, and search should remain the same.

- Redirecting to other Links:

- 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:

- View past results

- View IoT results

- Sensor monitoring

- View dashboard

Attributes Table:

- N/A

Validations:

Configurations:

- N/A

Notifications:

- N/A

User Interface

Acceptance Criteria:

- The user should be able to view the list of the upcoming lab tests by clicking on the inbox.

- The list of upcoming tests should be sorted correctly by the pending date, showing the test with the highest SLA first.

- The user should be able to see the test ID, plant name, treatment process, pending date, status, and SLA in the list of upcoming tests.

- The user should be able to view detailed information about a specific test by clicking on the test ID.

- The user should be able to filter the tests based on the treatment process, stages, and status.

- The user should be able to search for specific tests by the test ID or the plant name.

- The user should be able to redirect to other pages in the TQM module using the provided links.

User Story 18: View Test Details

Scope:

As a user, I want to access a test details page by clicking on the test ID in the inbox. The test details page should display detailed information about the test, including test ID, plant name, treatment process, stage, output type, test type, test scheduled date, status, lab name, sample submission date, test results submission date, SLA, a table with parameter details, overall test results (pass/fail), attached documents (if any), and the test timeline. Additionally, I should be able to go back using the breadcrumbs of the page and download the test report.

Actors:

ULB employee/State employee

Details:

- Accessing the test details page:

- The user can access the test details page by clicking on the test ID in the inbox.

- Fields displayed:

- The following information will be displayed on the test details page:

- Test ID

- Plant Name

- Treatment Process

- Stage

- Output Type

- Test Type

- Test Scheduled Date

- Status

- Lab Name

- Sample Submission Date

- Test Results Submission Date

- SLA: This will be displayed in red/green based on SLA. If today > pending date, it will be displayed in red. If today < pending date, it will be displayed in green for open tests. For closed tests, SLA will be displayed.

In case the information on any field is not available, such as lab name/value against parameters based on the status of the test, the value against the fields will be displayed as "To be Updated".

- Table with parameter details:

- The page will include a table with the following details:

- S.No

- Parameter

- Unit of Measurement (UoM)

- Benchmark

- Value Recorded: The value will be displayed in red/green based on comparison to the benchmark.

- Overall Test Results: Pass/Fail

- Attached documents:

- The user should be able to view attached documents (if any) by clicking on the document icon. No icon will be present if the documents are not attached.

- Test timeline:

- The test details page will display the test timeline, showing the various stages and dates involved in the test process.

- Go back:

- The user can go back to the previous page using the breadcrumbs of the page.

- Download test report:

- The user can download the test report by clicking on the download button.

Attributes Table:

N/A

Validations:

N/A

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The user should be able to access the test details page by clicking on the test ID in the inbox.

- The test details page should display detailed information about the test, including Test ID, Plant Name, Treatment Process, Stage, Output Type, Test Type, Test Scheduled Date, Status, Lab Name, Sample Submission Date, Test Results Submission Date, and SLA.

- The page should include a table with parameter details, showing S.No, Parameter, UoM, Benchmark, Value Recorded, and Overall Test Results (Pass/Fail).

- The user should be able to view attached documents (if any) by clicking on the document icon.

- The test details page should display the test timeline, showing the various stages and dates involved in the test process.

- The user should be able to go back using the breadcrumbs of the page.

- The user should be able to download the test report by clicking on the download button.

User Story 19: View Past Tests

Scope:

As a user, I want to view past test results (both IoT and lab) via the TQM landing page by clicking on the "Past Tests" link. The Past Test Results page will display a list of past tests with the ability to view test details, search tests based on various criteria, sort the results, and download test results in Excel and PDF formats. Additionally, I should be able to go back using the breadcrumbs on the top of the page and clicking on the Test ID will redirect me to the test details page.

Actors:

ULB employee/State employee

Details:

Past Test Results Page:

- Accessing Past Test Results Page:

- The user can access the Past Test Results page by clicking on the "Past Tests" link on the TQM landing page.

- Fields Displayed:

- The page will display a list of past tests sorted on the test date, with the following fields for each test:

- Test ID

- Plant

- Treatment Process (in case there is only 1 treatment process for the plant, this field will not be displayed)

- Test Type

- Test Date: This is the date the test results are updated

- Test Result: Pass/Fail

- View Test Details:

- The user can view test details by clicking on the "Test ID" link on each row, which will redirect the user to the test details page (same as redirection from Inbox).

- Search Tests:

- The user can search for past tests based on the following criteria:

- Test ID: Input Text field, Part search should be enabled.

- Plant: Dropdown of a list of plants in the ULB.

- Treatment Process: Dropdown of a list of treatment processes in the ULB.

- Test Type: This will be a dropdown showing values for Test Type (IoT/lab). Selected test type 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.

- Sort:

- Tests can be sorted by the Test Date by clicking on the date column.

- Clear Search:

- To clear the search and view all past tests, the user can click on the "Clear Search" button.

- Download Test Results:

- The user can download list of test results in Excel and PDF formats using the download button.

- Go Back:

- The user can go back to the previous page using the breadcrumbs on the top of the page. If the user has navigated to the Test details page from the Past Test results list, clicking back will redirect the user to the Past Test Results page.

Attributes Table:

N/A

Validations:

N/A

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The user should be able to access the Past Test Results page by clicking on the "Past Tests" link on the TQM landing page.

- The Past Test Results page should display a list of past tests sorted on the test date, with relevant fields such as Test ID, Plant, Treatment Process, Test Type, Test Date, and Test Result (Pass/Fail).

- The user should be able to view test details by clicking on the "Test ID" link on each row, redirecting the user to the Test details page (same as redirection from Inbox).

- The user should be able to search for past tests based on Test ID, Plant, Treatment Process, Test Type, and Date range criteria.

- The user should be able to sort past tests by the Test Date.

- The user should be able to clear the search and view all past tests.

- The user should be able to download test results in Excel and PDF formats.

- The user should be able to go back using the breadcrumbs on the top of the page and clicking on the Test ID will redirect the user to the test details page.

User Story 20: View IoT Readings

Scope:

As a user, I want to view IoT readings via the TQM landing page by clicking on the "View IoT Readings" link. On clicking the link, the user should be 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 of the page should remain the same.

Actors:

ULB employee/State employee

- Details:

- Accessing "View IoT Readings" Page:

- The user can access the "View IoT Readings" page by clicking on the "View IoT Readings" link on the TQM Landing Page.

- Redirected Page:

- On clicking "View 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.

- Other Functionality:

- All other functionality available on the page (e.g., viewing past test results, searching tests, sorting, downloading test results) will remain the same.

Attributes Table:

N/A

Validations:

N/A

Configurations:

N/A

Notifications:

N/A

User Interface:

N/A

Acceptance Criteria:

- The user should be able to access the "View IoT Readings" page by clicking on the "View IoT Readings" link on the TQM landing page.

- On clicking the link, the user should be 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 available on the page should remain the same, allowing the user to view past test results, search tests, sort, and download test results as before.

User Story 21: Sensor Monitoring

Scope:

As a user, I want to view the list of devices via the TQM landing page by clicking on the "Sensor Monitoring" link. On clicking the link, the user should be redirected to the list of devices. The page should display the total number of IoT devices, and each device should have specific details such as Device ID, Plant, Treatment Process, Stage, Output Type, Device Status, and the parameters it is monitoring. The user should be able to search and filter devices based on various criteria.

Actors:

ULB employee/State employee

Details:

- Accessing "Sensor Monitoring" Page:

- The user can access the "Sensor Monitoring" page by clicking on the "Sensor Monitoring" link on the TQM Landing Page.

- Redirected Page:

- On clicking "Sensor Monitoring," the user is redirected to the list of devices.

- List of Devices:

- The page will display the total number of IoT devices beside the page heading in brackets.

- Each device will have a row displaying the following details:

- Device ID

- Plant

- Treatment Process

- Stage

- Output Type

- Device Status

- Parameters: One or multiple parameters that the device is monitoring.

- Filters:

- Search Devices:

- On clicking "Filter," a pop-up will be displayed with the following filters:

- Device ID: Allows part search for Device ID.

- Plant: Dropdown with values based on plants configured in the MDMS.

- Treatment Process: Dropdown with values based on the Treatment process type.

- Stage: Dropdown with values based on the Stage of the selected Treatment process.

- Output Type: Dropdown with values based on Output types configured for the plant.

- Device Status: Dropdown with options for Active/Inactive.

- The user can select values for the filters above and click on "Search" to filter the list of devices based on the selected criteria.

- To clear the search and view all devices, the user can click on "Clear All."

Attributes Table:

Attribute

Type

Required?

Comments and Validations

Configuration Date

Datetime

Device Type

Text

Selection from device master data

[“GPS Sensor”, “pH Sensor”, “Accelerometer”, “Light Sensor”]

Plant

Text

Treatment Process

Text

Stage

Text

Output Type

Text

Parameters

Array

The parameters monitored by the device

Monitoring Frequency

Numeric

Custom frequency for the device

Calibration Date

Datetime

Input from the user about any change in the calibration/maintenance of the device

Calibration Accuracy

Array

Range to indicate the permissible deviation in the accuracy

IsConnected?

Boolean

To indicate the connectivity of the device

Connectivity History

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

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The user should be able to access the "Sensor Monitoring" page by clicking on the "Sensor Monitoring" link on the TQM landing page.

- On clicking the link, the user should be redirected to the list of devices, displaying the total number of IoT devices and specific details for each device, such as Device ID, Plant, Treatment Process, Stage, Output Type, Device Status, and the parameters it is monitoring.

- The user should be able to search and filter devices based on various criteria using the available filters.

- The user can perform the search and view the filtered devices based on the selected criteria.

- The user can clear the search and view all devices if needed.

User Story 22: Record Test Results

Scope:

As a user, I want to be able to record test results without a schedule for adhoc tests. A provision will be provided for the user to record test results by clicking on the "Add Test Result" link on the card. Clicking on the link should redirect the user to the "Add Test Result" page where the user can enter the required fields, including Plant Name, Treatment Process, Treatment Stage, Output Type, values against parameters, and any attachments. After submitting the test results, the user should be redirected to the test results page with specific changes to the display compared to the View Test Results page.

Actors:

ULB employee/State employee

Details:

- Accessing "Add Test Result" Page:

- The user can access the "Add Test Result" page by clicking on the "Add Test Result" link on the Card.

- Redirected Page:

- Clicking on "Add Test Result" will redirect the user to the "Add Test Result" page.

- Fields to Enter:

- The user needs to enter the following fields:

- Plant Name: 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: A dropdown based on the list of Treatment Processes in the selected plant.

- Treatment Stage: A dropdown based on the list of Stages in the selected Treatment Process.

- Output Type: A dropdown based on the Output types available in the selected stage.

- Values against parameters: The user should fill in at least 1 parameter 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 attachments are required, the user can add them.

- Submitting Test Results:

- Once the user clicks on the Submit button, the test results page is displayed.

- Changes to "View Test Results" Page:

- The "View Test Results" page with the following changes:

- Test Type will be displayed as "Lab."

- Status, Lab Name, and SLA fields are not displayed.

- Workflow will not be displayed.

Test Attributes:

Attribute

Type

Required?

Comments/Validations

Test ID

Numeric

Autogenerated by system

Plant Name

Array

View Only

Auto populated on creation of schedule, Single select for on demand test

Treatment Process

Array

View Only

Auto populated on creation of schedule, Single select for on demand test

Treatment Process Type

Array

View Only

Auto populated on creation of schedule, Single select for on demand test

Stage

Array

View Only

Auto populated on creation of schedule, Single select for on demand test

Output Type

Array

View Only

Auto populated on creation of schedule, Single select for on demand test

Test Type

Array

Lab/IoT, Autoselected to Lab for on demand

Lab Submitted to

Text

This will not be required in case Test Type = IoT

Quality Parameter 1

Numeric

Validation to be applied at impel

Quality Parameter 2

Numeric

Validation to be applied at impel

Quality Parameter 3

Numeric

Validation to be applied at impel

Quality Parameter n

Numeric

Validation to be applied at impel

Collection Time

Date

This is the date-time on which user updates status to Pending Results. For IoT, this is the time sensor records reading

Attachment

Document

For a given collection location, photo or PDF proof of laboratory result mentioning the information of above-mentioned parameters

Validations:

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The user should be able to access the "Add Test Result" page by clicking on the "Add Test Result" link on the card.

- The "Add Test Result" page should allow the user to enter required fields, including Plant Name, Treatment Process, Treatment Stage, Output Type, values against parameters, and any attachments.

- After submitting the test results, the user should be redirected to the test results page with specific changes to the display compared to the "View Test Results" page.

User Story 23: View Dashboard and Overview KPIs

Scope:

The TQM Dashboard will be available to both ULB employees and state employees. It can be accessed by clicking on the 'Dashboard' link on the landing page. Upon clicking, the user will be directed to the dashboard view. The access to data in the dashboard will be based on the roles, where the ULB admin can view the dashboard for all plants in the ULB, and the state admin can view the dashboard for all plants in the state.

Actors:

- ULB Employee

- State Employee

Details:

- Accessing "Dashboard" View:

- The user can access the Dashboard by clicking on the "Dashboard" link on the landing page.

- Redirected to Dashboard:

- Clicking on "Dashboard" will direct the user to the Dashboard view.

- Navigation:

- On the Dashboard view, the user can navigate across Treatment Process Types to view specific dashboards for each Treatment Process Type.

- Filters:

- Date Range: The user should be able to filter the dashboard based on the selected date range.

- ULB: For ULB Employees, the ULB is automatically selected to the ULB the Plant and Employee is tagged to. For State users, all ULBs should be available in the dropdown.

- 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 should be available.

- Share Functionality:

- User should be able to share the filtered dashboard over WhatsApp in image format.

- User should be able to share filtered charts/tables over WhatsApp in image format.

- Download Functionality:

- User should be able to download the filtered dashboard in PDF and image format.

- User should be able to download filtered charts/tables in PDF and image format.

- Metrics - Overall KPIs:

- The Dashboard will display the following KPIs:

- Total Incoming Sludge: Sum of the total sludge that is disposed of at the plant for the selected time period.

- # of trips: Count of total incoming vehicles at the Treatment Plant for the selected time period.

- Overall Quality: Number of tests where all parameters are as per benchmarks compared to the total number of test results recorded.

- Compliance %: % of tests where results have been recorded.

- Total Alerts: Count of total alerts raised of the following types:

1) Test Results not as per benchmark.

2) No reading from IoT device.

3) Lab results and IoT results not matching.

Detailed Metric calculations for the Treatment Quality Monitoring Dashboard are viewable here.

Attributes Table:

N/A

Validations:

The user should have appropriate access rights to view the dashboard.

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The user should be able to access the dashboard by clicking on the 'Dashboard' link on the landing page.

- The Dashboard view should allow the user to navigate across Treatment Process Types to view specific dashboards for each Treatment Process Type.

- The user should be able to filter the dashboard based on the selected date range, ULB, and plant.

- The user should be able to share the filtered dashboard and charts/tables over WhatsApp in the image format.

- The user should be able to download the filtered dashboard and charts/tables in PDF and image formats.

- The Dashboard should display the overall KPIs, including Total Incoming Sludge, the number of trips, Overall Quality, Compliance percentage, and Total Alerts.

User Story 24: Dashboard Card: Treatment Quality Monitoring

Scope:

The Treatment Quality Overview provides an overview of the Treatment Quality for a particular Treatment Process. It includes KPIs, a map view, and a table of plant-wise details of test results (Pass/Fail) and compliance percentage.

Actors:

ULB Employee/State Employee

Details:

- KPIs:

- Total Plants: The count of unique plants for the particular Treatment Process.

- Count of Plants Passed Treatment Quality: The count of plants that have passed 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.

- Count of Plants Failed Treatment Quality: The count of plants that have failed Treatment Quality as per the last recorded test. Treatment Quality is said to have failed if one or more parameters for final output(s) of a Treatment process are not as per benchmarks.

- Map View:

- The dashboard will display a map view showing the location of each plant. Plants will be colour-coded based on whether they have passed or failed the last output quality test Treatment Quality. (Red = Failed, Green = Passed)

- Table:

- The table will show plant-wise details of Test Results (Pass/Fail) and Compliance Percentage based on the last recorded test. The user will also be able to see the change in compliance percentage compared to the last month.

- Drill down functionality will be available for a plant via this table.

- For Treatment Plant Users (TRP) and ULBs where only one plant is tagged for the process type, the drilled table is automatically visible.

- Drill Down:

- When a user drills down on a specific plant from the table, the following information will be viewable:

- Heading: Name of the Plant

- Table displaying the following fields:

- Stage

- Output Type

- Value of Parameters

- Compliance Percentage

- Button to view Trends for a particular Stage.

- Toggle to Toggle between IoT readings and Lab Results. The selected test type will appear highlighted.

- Switching between Process Flows:

- If there are multiple process flows, the user can switch between them using buttons. The selected process flow will appear highlighted.

Detailed Metric calculations for the Treatment Quality Monitoring Dashboard are viewable here.

- Filters:

- Date Range: The user should be able to filter the dashboard based on the selected date range.

- ULB: For ULB Employees, the ULB is automatically selected to the ULB the Plant and Employee is tagged to. For State users, all ULBs should be available in the dropdown.

- 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 should be available.

- Share Functionality:

- User should be able to share filtered charts/tables over WhatsApp in image format.

- Download Functionality:

- User should be able to download filtered charts/tables in PDF and image format.

Attributes Table:

N/A

Validations:

The user should have appropriate access rights to view the Treatment Quality Overview dashboard.

Configurations:

N/A

Notifications:

N/A

User Interface:

Acceptance Criteria:

- The Treatment Quality Overview dashboard should display the KPIs: Total Plants, Count of Plants Passed Treatment Quality, and Count of Plants Failed Treatment Quality.

- The map view should show the location of each plant, color-coded based on whether they have passed or failed Treatment Quality.

- The table should show plant-wise details of Test Results (Pass/Fail) and Compliance Percentage based on the last recorded test. The user should be able to see the change in compliance percentage compared to the last month.

- The drill down functionality should provide detailed information about a specific plant's Stage, Output Type, Value of Parameters, and Compliance Percentage.

- The user should be able to toggle between IoT readings and Lab Results for a specific plant.

- If there are multiple process flows, the user should be able to switch between them using buttons.

User Story 25: Dashboard Card: Trend of Parameter Reading

Scope:

The user will be able to view a trend chart for a specific parameter over time once they click on the "View Trend" button in the table. The chart will provide a comparison with the benchmark.

Actors:

- ULB Employee/State Employee

- Details:

- When the user clicks on the "View Trend" button in the table, a trend chart will be displayed.

- The chart should not be visible before Trend chart has been clicked on

- The chart will show the trend of the selected parameter over time.

- The chart will also display the benchmark for the selected parameter to provide a comparison.

- A toggle will be available to navigate between different parameters for viewing their trend charts.

Attributes Table:

- N/A

Validations:

- The user should have appropriate access rights to view trend charts.

Configurations:

- N/A

Notifications:

- N/A

User Interface:

Acceptance Criteria:

- The user should be able to view a trend chart for a specific parameter by clicking on the "View Trend" button in the table.

- The chart should show the trend of the selected parameter over time.

- The chart should display the benchmark for the selected parameter to provide a comparison.

- The user should be able to navigate between different parameters using the toggle to view their trend charts.

Test Cases

Test ID

Module

Feature

Description

Steps to be executed

Expected Result

Actual result

QA Test Result

UAT Test Result

PM Test Result

Dashboard

Dashboard_01

Dashboard

Trips mismatch - Vehicle log report

To check for the number of trips in the vehicle log report

1. Login as ULB employee and open dashboard. 2. Navigate to the Desludging Request Report.

Initially, the data is displayed district-wise, so, here it should display the summation number of trips of all boundary.

Initially data is displayed district-wise. However, there is mismatch in the number of trips.

FAILED

Dashboard_02

Dashboard

Desludging Request Report

To verify the data mismatch in the Desludging Request Report

1. Login as a ULB employee and open the dashboard. 2. Navigate to the Desludging Request Report.

Initially, data is displayed district wise so, here it should display summation Open Request of ULB.

Initially data is displayed district wise so, but there is mismatch in open request.

FAILED

Dashboard_03

Dashboard

Desludging Request Report” & Vehicle Log Report

To verify When ULB is selected from drop down, the “Desludging Request Report” & “Vehicle Log Report” is showing District wise data. And there is mismatch in data between district figures and summation of data of ULB

1. Login as ULB Employee and open dashboard. 2. Then navigate to Desludging Request Report. 3. Check for Desludging Request Report” & “Vehicle Log Report”

ashboard shall showcase the requisite data & details with exact usage in the platform. And the district wise data shall be the summation of ULB wise data.

Desludging Request Report” & Vehicle Log Report is showing District wise data. And there is mismatch in data between district figures and summation of data of ULBs

FAILED

Dashboard_04

Dashboard

Check for templates- Date Range

Check for Date Range values

1. Login to Date Range 2. Check for Date Range filter criteria

Date Range should ahve vlues like month, year and dates to select from

Date Range has vlues like month, year and dates to select from

PASSED

Dashboard_05

Dashboard

Check for templates- DDRs

Check for DDRs values

1. Login to Date Range 2. Check for DDRs filter criteria

DDRs should have drop dwon values to select from

DDRs should has drop dwon values to select from

PASSED

Dashboard_06

Dashboard

Check for templates- ULB

Check for ULB values

1. Login to Date Range 2. Check for ULB filter criteria

ULB should have drop dwon values to select from

ULB should has drop dwon values to select from

PASSED

Dashboard_07

Dashboard

Overview chart

Check for overview chart values and shareable over email, download and over whatsapp

1. Login to Date Range 2. Check if IOVerview chart is dispalyed 3. Check if below values are ppopulated Total Request Total Sludge Treated Average FSM Cost Total Collection SLA Compliance Citizen Average Rating

All the below values should be populated correctly Total Request Total Sludge Treated Average FSM Cost Total Collection SLA Compliance Citizen Average Rating and user should be able to share teh image

Below values are populated correctly Total Request Total Sludge Treated Average FSM Cost Total Collection SLA Compliance Citizen Average Rating User is able to share the image and download

PASSED

Dashboard_08

Dashboard

Total Cumulative Collection

Check for Total Cumulative Collection chart is populated as expected and X and Y axis has required values

1. Login to Date Range 2. Check if Total Cumulative Collection chart is displayed with X and Y axis

Total Cumulative Collection should have X axis based on the filter values selected and X axis with the collection volume

Total Cumulative Collection has qX axis based on the filter values selected and X axis with the collection volume

PASSED

Dashboard_09

Dashboard

FSM Collection by Usage Type

Check if FSM Collection by Usage Type displays all the requird property types

1. Login to Date Range 2. Check if FSM Collection by Usage Type chart is dispalyed 3. Check if below values are ppopulated IndependentHouse RecidentialApartment Hotel Toilets Restaurant Institutional Church RowHouses

All the below values should be displayed as expected IndependentHouse RecidentialApartment Hotel Toilets Restaurant Institutional Church RowHouses

All the below values are displayed as expected IndependentHouse RecidentialApartment Hotel Toilets Restaurant Institutional Church RowHouses

PASSED

Dashboard_09

Dashboard

FSM Service Request by Gender

Check if FSM Service Request by Gender is displayed as expected

1. Login to DSS dash board 2. Check for FSM Service Request by Gender if it displays Male , Female and Tansgender values as expected

FSM Service Request by Gender should displayall 3 gender data as expected

FSM Service Request by Gender displays all 3 gender data as expected

PASSED

Driver_01

Driver tab

Error message with duplicate mobile number for driver

To verify if proper error message is displayed when ULB employee create two drivers with same mobile number

1. Login to FSM registry using QAADMIN 2. Go to driver tab and create two new drivers with same mobile nuber

Proper error message should be displayed when ULB employee create two drivers with same mobile number

Proper error message is not displayed displayed when ULB employee create two drivers with same mobile number

FAILED- Fixed and retested (working as expected now)

Vendor_Driver_01

Vendor and Driver tab

To verify when admin creates vendor and driver with same mobile number

1. Login to FSM registry using QAADMIN 2. Go to vendor and driver tab and create two new vendor and driver with same mobile nuber

Vendor name should be displayed for vendor and same for driver

Vendor name is displayed in driver listing when admin creates vendor and driver with same mobile number

FAILED- Fixed and retested (working as expected now)

DSO_01

DSO

DSO - Creating new application

To verify if DSO is able to create new application as citizen

1. Login using citizen ui with DSO mobile number 2. Create a application

DSO should be able to create new application

DSO is unable to create application

FAILED- Fixed and retested (working as expected now)

Citizen_01

DSO

DSO - Citizen flow

To verify Applications Created by Citizen is displayed for DSO user

1. Login as DSO using citizen login 2. create an application 3. Go to my applications 4. Check for applications displayed

Only Dso created applications should be displayed

Applications Created by Citizen is displayed for DSO user

FAILED- Fixed and retested (working as expected now)

Test Cases For Vendor Tab

/ 9

Admin Should be able to see FSM Registry page

Vendo_01

Vendor Tab

FSM Registry - Vendor Tab

To Verify admin can able to select FSM Registry Button

1.Login as Admin 2.Click on Fsm registry

Admin Can able to see FSM Registry page

PASSED

Vendo_02

Vendor Tab

FSM Registry - Vendor Tab

To Verify UI for vendor Tab in FSM Registry page

1.Login as Admin 2.Click on Fsm registry 3.Click on Vendor Button

Admin Should be able to see the Vendor page

Admin Can able to see the Vendor page

PASSED

Vendo_03

Vendor Tab

FSM Registry - Vendor Tab

To Verify for vendor button in FSM Registry page

1.Login as Admin 2.Click on Fsm registry 3.Click on Vendor Button

Admin Should be able to see all the components of vendor button

Admin Can able to see all the components of vendor button

PASSED

Vendo_04

Vendor Tab

FSM Registry - Vendor Tab

To Verify admin can able to enter vendor name in vendor name text field

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter vendor name 5.Click on search

Admin Should be able to see vendor details

Admin Can able to see vendor details

PASSED

Vendo_05

Vendor Tab

FSM Registry - Vendor Tab

To verify admin can able to select Enable / disable toggle button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4Enter vendor name and click on search 5.Click on Enable/disable Toggle

Admin Should be able to see toggle button in orange colour if it is disabled or Should be display in black if it is enabled

Admin Can able to see toggle button in orange colour if it is disabled or Can display in black if it is enabled

PASSED

Vendo_06

Vendor Tab

FSM Registry - Vendor Tab

To verify admin can able to select the vendor name

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter Vendor name 5.Click on search 5.Click on Vendor name

Admin Should be able to view Vendor's details , Vehicle details and Driver details

Admin Can able to view Vendor's details Vehicle details and Driver details

PASSED

Vendo_07

Vendor Tab

FSM Registry - Vendor Tab

To verify admin can able to add vehicle to vendor details

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter Vendor name 5.Click on search 5.Click on Vendor name 6.Click on Add vehicle 7.Select a vehicle 8.Click on submit

Admin Should be able to view vehicle details in vendor's details

Admin Can able to view vehicle details in vendor's details

PASSED

Vendo_08

Vendor Tab

FSM Registry - Vendor Tab

To verify admin can able to add driver to vendor details

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter Vendor name 5.Click on search 5.Click on Vendor name 6.Click on Add driver 7.Select a vehicle 8.Click on submit.

Admin Should be able to view driver details in vendor's details

Admin Can able to view driver details in vendor's details

PASSED

Vendo_09

Vendor Tab

FSM Registry - Vendor Tab

To verify admin able to select Take action button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter Vendor name 5.Click on search 6.Click on Vendor name 7.Click on take action button

Admin Should be able to view Take action button in orange colour

Admin can able to view Take action button in orange colour

PASSED

Vendo_10

Vendor Tab

FSM Registry - Vendor Tab

To verify admin able to select Edit or delete button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vendor Button 4.Enter Vendor name 5.Click on search 6.Click on Vendor name 7.Click on take action button 8.Enter or change the required fields

Admin Should be able to view edit and delete buttons in orange colour

Admin can able to view edit and delete buttons.

PASSED

Vendo_11

Vendor Tab

FSM Registry - Vendor Tab

To verify admin able to click on add icon

1.Login as Admin 2.Click on Fsm registry 3.Click on add icon

Admin Should be view vendor,Vehicle and driver list

Admin can able to view vendor,Vehicle and driver list

PASSED

Vendo_12

Vendor Tab

FSM Registry - Vendor Tab

To verify admin can able to add new vendor

1.Login as Admin 2.Click on Fsm registry 3.Click on Add icon 4.Click on Vendour 5.Enter all the required fields 6.Click on Submit application Button

New Vendor has to create.

New Vendor is created

PASSED

Vendo_13

Vendor Tab

FSM Registry - Vendor Tab

To verify Admin can able to see the vendor name in vendor list

1.Login as Admin 2.Click on Fsm registry 3.Enter vendor name 4.Click on search

Vendor's details should display

Vendor's details is displaying

PASSED

Test Cases For Vehicle Tab

Vehicle_01

Vehicle Tab

FSM Registry - Vehicle Tab

Verify UI for vehicle number Tab in FSM Registry page

1.Login as Admin 2.Click on Fsm registry 3.Click on Vehicle number Button

Admin Should be able to see the Vehicle page

Admin Can able to see the Vehicle page

PASSED

Vehicle_02

Vehicle Tab

FSM Registry - Vehicle Tab

Verify for vehicle number button in FSM Registry page

1.Login as Admin 2.Click on Fsm registry 3.Click on Vehicle number Button

Admin Should be able to see all the components of Vehicle number button

Admin Can bable to see all the components of Vehicle number button

PASSED

Vehicle_03

Vehicle Tab

FSM Registry - Vehicle Tab

Verify admin can able to enter vehicle number in Vehicle number text field

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vehicle number Button 4.Enter Vehicle number 5.Click on search

Admin Should be able to see vehicle details

Admin Can able to see vehicle details

PASSED

Vehicle_04

Vehicle Tab

FSM Registry - Vehicle Tab

To verify admin can able to select Enable / disable toggle button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vehicle number Button 4Enter vendor name and click on search 5.Click on Enable/disable Toggle

Admin Should be able to see toggle button in orange colour if it is disabled or toggle button Should display in black if it is enabled

Admin Can able to see toggle button in orange colour if it is disabled or toggle button Can display in black if it is enabled

PASSED

Vehicle_05

Vehicle Tab

FSM Registry - Vehicle Tab

To verify admin can able to select Vehicle number

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vehiclenumber Button 4.Enter Vehicle number 5.Click on search 5.Click on Vehicle number

Admin Should be able to see Vehicle details.

Admin Can be able to see Vehicle details.

PASSED

Vehicle_06

Vehicle Tab

FSM Registry - Vehicle Tab

To verify admin able to select Take action button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Vehicle number Button 4.Enter Vehicle number 5.Click on search 6.Click on vehicle number 7.Click on take action button

Admin Should be able to see edit and delete buttons in orange colour

Admin Can be able to see edit and delete buttons in orange colour

PASSED

Vehicle_07

Vehicle Tab

FSM Registry - Vehicle Tab

To Verify admin can able to Edit the vehicle details

1.Login as Admin 2.Click on Fsm registry 3.Enter Vehicle number 4.Click on Vehicle number 5.Click on Take action 6.Click on edit 7.Enter the details in required fields 8.Click on submit application Button

Admin Should be able to see updated vehicle details

Admin Can able to see updated vehicle details

PASSED

Vehicle_08

Vehicle Tab

FSM Registry - Vehicle Tab

To Verify admin can able to Delete the vehicle's details

1.Login as Admin 2.Click on Fsm registry 3.Enter vendor name 4.Click on vendor name 5.Click on Take action 6.Click on Delete 7.Click Again On Delete

Vehicle Should be deleted from the list

Vehicle is deleted from the list

PASSED

Vehicle_09

Vehicle Tab

FSM Registry - Vehicle Tab

To verify admin able to click on add icon

1.Login as Admin 2.Click on Fsm registry 3.Click on add icon

Admin Should be able to see vendor,Vehicle and driver list

Admin can able to see vendor,Vehicle and driver list

PASSED

Vehicle_10

Vehicle Tab

FSM Registry - Vehicle Tab

To verify admin can able to add new vehicle

1.Login as Admin 2.Click on Fsm registry 3.Click on Add icon 4.Click on Vehicle 5.Enter all the required fields 6.Click on Submit application Button

New Vehicle has to be created

New Vehicle is created

PASSED

Vehicle_11

Vehicle Tab

FSM Registry - Vehicle Tab

To verify Admin can able to see the vehicle name in vendor list

1.Login as Admin 2.Click on Fsm registry 3.Enter Vehicle number 4.Click on search

Admin Should be able to see Vehicle's details

Admin Can able to see Vehicle's details

PASSED

Test Cases For Driver Tab

Driver_01

Driver Tab

FSM Registry - DriverTab

To check UI of Driver tab

1.Login as Admin 2.Click on Fsm registry 3.Click on Driver Button

Admion Should be able to see the Driver page

Admin Can able to see the Driver page

PASSED

Driver_02

Driver Tab

FSM Registry - DriverTab

To verify Admin can able to enter Driver name in Driver Text field

1.Login as Admin 2.Click on Fsm registry 3.Click on Driver Button 4.Enter driver name in driver text field 5.Click on Search

Admin Should be able to see all the components of Driver page details

Admin Can able to see all the components of Driver page details

PASSED

Driver_03

Driver Tab

FSM Registry - DriverTab

To Verify admin can able to enter Driver name in name Driver text field

1.Login as Admin 2.Click on Fsm registry 3.Click on By Driver Button 4.Enter Driver name 5.Click on search

Admin Should be able to see all the details of the Driver

Admin can able to see all the details of the Driver

PASSED

Driver_04

Driver Tab

FSM Registry - DriverTab

To verify admin can able to select Enable / disable toggle button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Driver Button 4.Enter Driver name 5.Click on search 6.Click on Enable or Disable toggle button

Admin Should be able to see toggle button in orange colour if it is enabled or Should display in black if it is Disabled

Admin can able to see toggle button in orange colour if it is enabled or Should display in black if it is Disabled

PASSED

Driver_05

Driver Tab

FSM Registry - DriverTab

To verify admin able to select Take action button

1.Login as Admin 2.Click on Fsm registry 3.Click on By Driver Button 4.Enter Driver name 5.Click on search 6. Click on Driver name 7.Click on take action button

Admin Should be able to see edit and delete buttons in orange colour

Admin can able to see edit and delete buttons in orange colour

PASSED

Driver_06

Driver Tab

FSM Registry - DriverTab

To verify admin able to click on add icon

1.Login as Admin 2.Click on Fsm registry 3.Click on add icon

Admin Should be able to see vendor,Vehicle and driver list

Admin can able to see vendor,Vehicle and driver list

PASSED

Driver_07

Driver Tab

FSM Registry - DriverTab

To verify admin can able to add new Driver

1.Login as Admin 2.Click on Fsm registry 3.Click on Add icon 4.Click on Driver 5.Enter all the required fields 6.Click on Submit application Button

New Driver has to be created

New Driver is created

PASSED

Driver_08

Driver Tab

FSM Registry - DriverTab

To verify Admin can able to see the Driver name in Driver list

1.Login as Admin 2.Click on Fsm registry 3.Enter Driver name 4.Click on search

Driver details should display

Driver details is displaying

PASSED

Complete request : upload photo - copy

Complete_request_01

Complete request

Uplaod Photo

To verify the localisation has been changed from upload pit photo to upload photo

1.Login as Editor. 2.Select the application which has to be completed. 3.Click on take action. 4.click on complete request.

The localisation Can be changed from upload pit photo to upload photo

The localisation Can been changed from upload pit photo to upload photo

PASSED

FSM Registry Login to Inbox and empty inbox

FSM Registry_01

FSM Registry-Inbox

FSM Registry Login to Inbox and empty inbox

To verify admin can able to view add Add new vendor option

1.Login as Admin. 2.click on Fsm registry button 3.Enter the invalid vendor name. 4.Click on search

Admin should be able to view add new vendor option .

Admin Can able to view add new vendor option .

PASSED

FSM Registry_02

FSM Registry-Inbox

FSM Registry Login to Inbox and empty inbox

To verify admin can able to view add Add new vehicle option

1.Login as Admin. 2.click on Fsm registry button 3.Enter the invalid vehicle name. 4.Click on search

Admin should be able to view add new vehicle option

Admin Can able to view add new vehicle option

PASSED

FSM Registry_03

FSM Registry-Inbox

FSM Registry Login to Inbox and empty inbox

To verify admin can able to view add Add new driver option

1.Login as Admin. 2.click on Fsm registry button 3.Enter the invalid driver name. 4.Click on search.

Admin should be able to view add new vendor option .

Admin Can able to view add new vendor option .

PASSED

ULB Inbox

ULB Employee_01

ULB Employee

ULB Employee Inbox

To verify Filter options like assigned to me and assigned to all Can be removed from UI

1.Login as ULB Employee 2.Click on inbox 3.Check whether Filter options like assigned to me and assigned to all is there.

ULB Employee Can not be able to view assigned to me and assigned to all filter options.

ULB Employee can able to view assigned to me and assigned to all filter options.

PASSED

ULB Employee_02

Creator flow

ULB Employee Inbox

To check that creator can be able to view FSM Page with New De sludging application , inbox and reports options.

1.Login As admin 2.click on New Desludging application button. 3.click the browser back button

Creator Can be able to view FSM Page with New De sludging application , inbox and reports options.

Creator can be able to view FSM Page with New De sludging application , inbox and reports options.

PASSED

Test cases for Vehicle validation

Vehicle number validation_01

Vehicle

Vehicle number validation

The Add new text field Can accept the vehicle number in the AB 00 CD 1234 format

1.Login as FSTPO. 2.Click on Home. 3.Click on Add new. 4.Enter the vehicle number in the AB 00 CD 1234 format.

The Add new text field Can be able to accept the vehicle number in the AB 00 CD 1234 format

The Add new text field is accepting the vehicle number in the AB 00 CD 1234 format

PASSED

Vehicle number validation_02

Vehicle

Vehicle number validation

The Add new text field Can accept the vehicle number in the AB 00 C 1234 format

1.Login as FSTPO. 2.Click on Home. 3.Click on Add new. 4.Enter the vehicle number in the AB 00 C 1234 format.

The Add new text field Can be able to accept the vehicle number in the AB 00 C 1234 format

The Add new text field is accepting the vehicle number in the AB 00 C 1234 format

PASSED

Vehicle number validation_03

Vehicle

Vehicle number validation

The Add new text field Can accept the vehicle number in the AB 00C 1234 format

1.Login as FSTPO. 2.Click on Home. 3.Click on Add new. 4.Enter the vehicle number in the AB 00C 1234 format.

The Add new text field Can be able to accept the vehicle number in the AB 00C 1234 format

The Add new text field is accepting the vehicle number in the AB 00C 1234 format

PASSED

Vehicle number validation_04

Vehicle

Vehicle number validation

The Add new text field Can accept the vehicle number in the AB 00CD 1234 format

1.Login as FSTPO. 2.Click on Home. 3.Click on Add new. 4.Enter the vehicle number in the AB 00CD 1234 format.

The Add new text field Can be able to accept the vehicle number in the AB 00CD 1234 format

The Add new text field is accepting the vehicle number in the AB 00CD 1234 format

PASSED

ULB New application +(modify application)

ULB Employee_01

ULB Employee

ULB New application + modify application

To verify that collector can able to collect the advance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the advance amount.

Collector can able to Collect the advance amount.

PASSED

ULB Employee_02

ULB Employee

ULB New application + modify application

To verify that collector can able to collect the Balance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the balance amount.

Collector can able to Collect the balance amount.

PASSED

ULB Employee_03

ULB Employee

ULB New application + modify application

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

1.Login as collector 2.search with the application number and click on the application number and collect the payment. 3.Download the reciept and view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

ULB collecting advance

, https://digit-discuss.atlassian.net/browse/SM-807

Collector - Advance amount_01

Collector - Advance amount

ULB collecting advance amount

To verify that collector can able to collect the advance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the advance amount.

Collector can able to Collect the advance amount.

PASSED

Collector - Advance amount_02

Collector - Advance amount

ULB collecting advance amount

To verify that collector can able to collect the Balance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the balance amount.

Collector can able to Collect the balance amount.

PASSED

Collector - Advance amount_03

Collector - Advance amount

ULB collecting advance amount

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

Collector - Advance amount_04

Collector - Advance amount

ULB collecting advance amount

To verify that collector can able to collect the remaining amount and the breadcrumbs Can be as follows Home/FSM/ Inbox/ Collect Payment / Generate Receipt

1.Login as Collector. 2.click on inbox and enter the application number and click on the application number, 3.Click on generate reciept and enter all the fields and click on submit application

collector Can be able to collect the remaining amount and the breadcrumbs Can be as follows Home/FSM/ Inbox/ Collect Payment / Generate Receipt

collector can able to collect the remaining amount and the breadcrumbs Can be as follows Home/FSM/ Inbox/ Collect Payment / Generate Receipt

PASSED

Collector - Advance amount_05

Collector - Advance amount

ULB collecting advance amount

To verify that citizen is getting the message in the given format after paying the full amount

Check has to check the message and Can be in the given format Dear citizen, amount of Rs.* is received towards the payment of cleaning septic tank /pit for reference no. *. Please click this link **to download the receipt. Thank You. EGOVS.

citizen Can be able to get the message in the given format.

citizen can able to get the message in the given format.

PASSED

Collector - Advance amount_06

Collector - Advance amount

ULB collecting advance amount

To verify that citizen able to download the reciept from the message link.

Click on the download the reciept link which has sent to citizen and download the report

Citizen Can be able to download the report.

ULB employee update number of trips

ULB Employee - No of trips update_01

ULB Employee - No of trips update

ULB employee update number of trips

cr amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now increase/decrease the trips

Editor Can be able to increase/decrease the trips when citizen has paid some advance amount.

Editor can be able to increase/decrease the trips when citizen has paid some advance amount.

PASSED

ULB Employee - No of trips update_02

ULB Employee - No of trips update

ULB employee update number of trips

To verify that can able to reduce the trips when citizen has paid some advance amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now reduce the trips

Editor Can not be able to reduce the trips when citizen has paid some advance amount.

Editor can't able to reduce the trips when citizen has paid some advance amount.

PASSED

ULB Employee - No of trips update_03

ULB Employee - No of trips update

ULB employee update number of trips

To verify that Editor can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips.

Editor Can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

Editor can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

PASSED

ULB Employee - No of trips update_04

ULB Employee - No of trips update

ULB employee update number of trips

To verify that Editor can able to Complete the request when citizen pay the full amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.complete the request.

Editor Can be able to complete the request when citizen makes the full payment.

Editor can be able to complete the request when citizen makes the full payment.

PASSED

ULB Employee - No of trips update_05

ULB Employee - No of trips update

ULB employee update number of trips

To verify that editor can't able to Complete the request when citizen did not pays the full amount

Login as editor and click on inbox and enter the application number and click on the application number and try to complete the request

editor Can not be able to Complete the request when citizen did not pays the full amount

editor cannot able to Complete the request when citizen did not pays the full amount

PASSED

DSO update number of trips

DSO update number of trips_01

DSO update number of trips

To verify that DSOcan able to increase or decrease the trips when citizen has paid some advance amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now increase/decrease the trips

DSO Can be able to increase/decrease the trips when citizen has paid some advance amount.

DSO can be able to increase/decrease the trips when citizen has paid some advance amount.

PASSED

DSO update number of trips_02

DSO update number of trips

To verify that can able to reduce the trips when citizen has paid some advance amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now reduce the trips

DSOCan not be able to reduce the trips when citizen has paid some advance amount.

DSO can't able to reduce the trips when citizen has paid some advance amount.

PASSED

DSO update number of trips_03

DSO update number of trips

To verify that DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips.

DSO Can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

PASSED

DSO update number of trips_04

DSO update number of trips

To verify that DSO can able to Complete the request when citizen pay the full amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.complete the request.

DSOCan be able to complete the request when citizen makes the full payment.

DSOcan be able to complete the request when citizen makes the full payment.

PASSED

DSO update number of trips_05

DSO update number of trips

To verify that DSo can't able to Complete the request when citizen did not pays the full amount

Login as DSoand click on inbox and enter the application number and click on the application number and try to complete the request

DSoCan not be able to Complete the request when citizen did not pays the full amount

DSocannot able to Complete the request when citizen did not pays the full amount

PASSED

Workflow changes from creator flow side

Workflow changes - Creator side_01

Workflow changes - Creator side

Workflow changes from creator side

To verify that collector can able to collect the advance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the advance amount.

Collector can able to Collect the advance amount.

PASSED

Workflow changes - Creator side_02

Workflow changes - Creator side

Workflow changes from creator side

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

Workflow changes - Creator side_03

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor can able to assign the DSO

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action. 4.click on assign DSO. 5.Assign the DSO.

Editor Can be able to assign the DSO

Editor can able to assign the DSO

PASSED

Workflow changes - Creator side_04

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor/DSO can able to assign the Vehicle.

1.Login as Editor/DSO. 2.2.click on inbox and enter the application number and click on the application number, 3.click on take action. 4.click on assign vehicle 5.Assign the vehicle.

Editor/DSO Can be able to assign the Vehicle

Editor/DSO can able to assign Vehicle

PASSED

Workflow changes - Creator side_05

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor /DSO can able to increase or decrease the trips when citizen has paid some advance amount

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now increase/decrease the trips

Editor /DSO Can be able to increase/decrease the trips when citizen has paid some advance amount.

Editor /DSO can be able to increase/decrease the trips when citizen has paid some advance amount.

PASSED

Workflow changes - Creator side_06

Workflow changes - Creator side

Workflow changes from creator side

To verify that can able to reduce the trips when citizen has paid some advance amount

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now reduce the trips

Editor /DSO Can not be able to reduce the trips when citizen has paid some advance amount.

Editor /DSO can't able to reduce the trips when citizen has paid some advance amount.

PASSED

Workflow changes - Creator side_07

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor /DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips.

Editor /DSO Can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

Editor /DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

PASSED

Workflow changes - Creator side_08

Workflow changes - Creator side

Workflow changes from creator side

To verify that collector can able to Balance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the balance amount.

Collector can be able to Collect the balance amount.

PASSED

Workflow changes - Creator side_09

Workflow changes - Creator side

Workflow changes from creator side

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

Workflow changes - Creator side_10

Workflow changes - Creator side

Workflow changes from creator side

To verify that FSTPO can able to click on Dispose

1.Login as FSTPO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.And Click on dispose.

FSTPO Can be able to click on Dispose.

FSTPO can able to dispose.

PASSED

Workflow changes - Creator side_11

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor/DSO can able to Complete the request when citizen pay the full amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.complete the request.

Editor/DSOCan be able to complete the request when citizen makes the full payment.

Editor/DSOcan be able to complete the request when citizen makes the full payment.

PASSED

Workflow changes - Creator side_12

Workflow changes - Creator side

Workflow changes from creator side

To verify that Editor/DSO Can not able to Complete the request when citizen did not pays the full amount

Login as Editor/DSOand click on inbox and enter the application number and click on the application number and try to complete the request

Editor/DSOCan not be able to Complete the request when citizen did not pays the full amount

Editor/DSOcannot able to Complete the request when citizen did not pays the full amount

PASSED

Workflow changes - Creator side_13

Workflow changes - Creator side

Workflow changes from creator side

To verify that Citizen can able to give Feedback.

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.Fill all the fields. 6.click on submit.

Citizen Can be able to give Feedback.

Citizen can able to give feedback

PASSED

Workflow changes from citizen side

Workflow changes - Citizen side_01

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that citizen is able to view warning message when he enters the amount greater than the advance amount

1.Login as creator 2.click on new desludging appliction 3.Enter all the mandatory fields till Payment Preference 4.Select pre pay in Payment Preference 5.Then enter greater than the advance amount

citizen as to able to view warning message as Amount entered is greater than the advance amount.

citizen can able to view warning message as Amount entered is greater than the advance amount.

PASSED

Workflow changes - Citizen side_02

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that citizen is able to view warning message when he enters the amount lesser than the advance amount

11.Login as creator 2.click on new desludging appliction 3.Enter all the mandatory fields till Payment Preference 4.Select pre pay in Payment Preference 5.Then enter lesser than the advance amount

citizen as to able to view warning message as Amount entered is lesser than the advance amount.

citizen can able to view warning message as Amount entered is greater than the advance amount.

PASSED

Workflow changes - Citizen side_03

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that editor can able to update the trips.

1.Login as editor. 2.search with the citizen created application number and click on application number 3.Click on take action. 4.update the trips.

Editor Can be able to update the trips.

Editor can be able to update the trips.

PASSED

Workflow changes - Citizen side_04

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that collector can able to collect the advance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the advance amount.

Collector can able to Collect the advance amount.

PASSED

Workflow changes - Citizen side_05

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

Workflow changes - Citizen side_06

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor can able to assign the DSO

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action. 4.click on assign DSO. 5.Assign the DSO.

Editor Can be able to assign the DSO

Editor can able to assign the DSO

PASSED

Workflow changes - Citizen side_07

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor/DSO can able to assign the Vehicle.

1.Login as Editor/DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action. 4.click on assign vehicle 5.Assign the vehicle.

Editor/DSO Can be able to assign the Vehicle

Editor/DSO can able to assign Vehicle

PASSED

Workflow changes - Citizen side_08

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor /DSO can able to increase or decrease the trips when citizen has paid some advance amount

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now increase/decrease the trips

Editor /DSO Can be able to increase/decrease the trips when citizen has paid some advance amount.

Editor /DSO can be able to increase/decrease the trips when citizen has paid some advance amount.

PASSED

Workflow changes - Citizen side_09

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that can able to reduce the trips when citizen has paid some advance amount

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips. 5.Now reduce the trips

Editor /DSO Can not be able to reduce the trips when citizen has paid some advance amount.

Editor /DSO can't able to reduce the trips when citizen has paid some advance amount.

PASSED

Workflow changes - Citizen side_10

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor /DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

1.Login as Editor /DSO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.click on update trips.

Editor /DSO Can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

Editor /DSO can be able to view the message as not allowed to reduce the number of trips as amount as already collected when amount has been already paid

PASSED

Workflow changes - Citizen side_11

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that collector can able to Balance amount

1.Login as collector 2.search with the application number and click on the application number and collect the payment.

Collector Can be able to Collect the balance amount.

Collector can be able to Collect the balance amount.

PASSED

Workflow changes - Citizen side_12

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector Can be able to view the advance amount and paid amount and balance amount in payment Reciept.

Collector can able to view the advance amount and paid amount and balance amount in payment Reciept.

PASSED

Workflow changes - Citizen side_13

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that FSTPO can able to click on Dispose

1.Login as FSTPO. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.And Click on dispose.

FSTPO Can be able to click on Dispose.

FSTPO can able to dispose.

PASSED

Workflow changes - Citizen side_14

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor/DSO can able to Complete the request when citizen pay the full amount

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.complete the request.

Editor/DSOCan be able to complete the request when citizen makes the full payment.

Editor/DSOcan be able to complete the request when citizen makes the full payment.

PASSED

Workflow changes - Citizen side_15

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Editor/DSOCan not able to Complete the request when citizen did not pays the full amount

Login as Editor/DSOand click on inbox and enter the application number and click on the application number and try to complete the request

Editor/DSOCan not be able to Complete the request when citizen did not pays the full amount

Editor/DSOcannot able to Complete the request when citizen did not pays the full amount

PASSED

Workflow changes - Citizen side_16

Workflow changes - Citizen side

Workflow changes from Citizen side

To verify that Citizen can able to give Feedback.

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.Fill all the fields. 6.click on submit.

Citizen Can be able to give Feedback.

Citizen can able to give feedback

PASSED

FSM V1.2 : Citizen New application +(modify application)

Citizen side - warning message_01

Citizen side - warning message

To verify that citizen is able to view warning message when he enters the amount greater than the advance amount

1.Login as creator 2.click on new desludging appliction 3.Enter all the mandatory fields till Payment Preference 4.Select pre pay in Payment Preference 5.Then enter greater than the advance amount

citizen as to able to view warning message as Amount entered is greater than the advance amount.

citizen can able to view warning message as Amount entered is greater than the advance amount.

PASSED

Citizen side - warning message_02

Citizen side - warning message

To verify that citizen is able to view warning message when he enters the amount lesser than the advance amount

11.Login as creator 2.click on new desludging appliction 3.Enter all the mandatory fields till Payment Preference 4.Select pre pay in Payment Preference 5.Then enter lesser than the advance amount

citizen as to able to view warning message as Amount entered is lesser than the advance amount.

citizen can able to view warning message as Amount entered is greater than the advance amount.

PASSED

Payment mode from citzen side

Citizen side - Pyment_01

Citizen side - Pyment

To verify citizen can able to make the payment for partial amount.

1.Login as citizen and create a desludging application. 2.Login as editor and update the trips. 3.Login as citizen and make the payment for partial amount by entering all the mandatory fields.

citizen should be able to make the payment for partial amount.

citizen can able to make the payment for partial amount.

PASSED

Citizen side - Pyment_02

Citizen side - Pyment

To verify citizen can able to make the payment for full amount.

1.Login as citizen and create a desludging application. 2.Login as editor and update the trips. 3.Login as citizen and make the payment for full amount by entering all the mandatory fields.

citizen should be able to make the payment for full amount.

citizen can able to make the payment for full amount.

PASSED

Citizen side - Pyment_03

Citizen side - Pyment

To verify citizen can able to make the payment after paying the partial amount

1.Login as citizen and create a desludging application. 2.Login as editor and update the trips. 3.Login as citizen and make the payment for partial amount by entering all the mandatory fields. 4.Login as Editor, assign the DSO. 5.Login as Editor, Assign the vehicle and update the trips. 6.Login as Citizen make the payment for partial amount by entering all the mandatory fields.

citizen should be able to make the payment after paying the partial amount

citizen can be able to make the payment after paying the partial amount

PASSED

Citizen side - Pyment_04

Citizen side - Pyment

To verify citizen can able to make the payment after paying the full amount

1.Login as citizen and create a desludging application. 2.Login as editor and update the trips. 3.Login as citizen and make the payment for full amount by entering all the mandatory fields. 4.Login as Editor, assign the DSO. 5.Login as Editor, Assign the vehicle and update the trips. 6.Login as Citizen make the payment for full amount by entering all the mandatory fields.

citizen should not be able to make the payment after paying the full amount

citizen can not able to make the payment after paying the full amount

PASSED

Updating Citizen Feedback form

Citizen Feedback form_01

Citizen Feedback form

Update Citizen Feedback form

Verify that "Number of Trips" text field has removed From the UI

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.check that Number of Trips text field has removed From the UI

"Number of Trips" text field should be removed From the UI

"Number of Trips" text field is removed From the UI

PASSED

Citizen Feedback form_02

Citizen Feedback form

Update Citizen Feedback form

Verify that "Did desludging happen" textfield has removed From the UI

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.Check that Did desludging happen textfield has removed From the UI

"Did desludging happen" textfield should be removed From the UI

"Did desludging happen" textfield is removed From the UI

PASSED

Citizen Feedback form_03

Citizen Feedback form

Update Citizen Feedback form

Verify that "Provide Feedback " rating scale is a mandatory field

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback.

"Provide Feedback " rating scale should be mandatory field

"Provide Feedback " rating scale is a mandatory field

PASSED

Citizen Feedback form_04

Citizen Feedback form

Update Citizen Feedback form

Verify that "Safety gear used " checkbox is a mandatory field

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.Check that Provide Feedback rating scale is a mandatory field

Verify that "Safety gear used " checkbox should be mandatory field

Verify that "Safety gear used " checkbox should is a mandatory field

PASSED

Citizen Feedback form_05

Citizen Feedback form

Update Citizen Feedback form

Verify that "Comments" textfield is a not a mandatory field

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.Check that Commentstextfield is a not a mandatory field

Verify that "Comments" textfield is a not a mandatory field

PASSED

Citizen Feedback form_06

Citizen Feedback form

Update Citizen Feedback form

Verify that Submit button Should not highlighted when mandatory fields are not filled

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5.check that Submit button Should not highlighted when mandatory fields are not filled

Submit button Should not highlighted when mandatory fields are not filled

Submit button isn't highlighted when mandatory fields are not filled

PASSED

Citizen Feedback form_07

Citizen Feedback form

Update Citizen Feedback form

Verify that when citizen didn't fill the mandatory fields suggestions has to display

1.Login as citizen. 2.click on my application. 3.click on application number. 4.click on Citizen provides Feedback. 5. Check that when citizen didn't fill the mandatory fields suggestions has to display

when citizen didn't fill the mandatory fields suggestions messages should display

when citizen didn't fill the mandatory fields suggestions messages like "please rate your experience between 1-5 stars" and "please select the options from below" is displaying

PASSED

Skip Collection Process for Zero Pricing

Zero pricing_01

Zero pricing

Skip Collection Process for Zero Pricing

Verify that when citizen selects the "Kathagada Parbatia Sahi "slum while creating the De-sludging application the payment details should be ₹ 0

1.Login as citizen. 2.Create an application by selecting "Kathagada Parbatia Sahi" slum option .

Payment details should be ₹ 0 when citizen creates the application by selecting "Kathagada Parbatia Sahi "slum option

when citizen selects the "Kathagada Parbatia Sahi "slum while creating the De-sludging application the payment details is showing as ₹ 0

PASSED

Zero pricing_02

Zero pricing

Skip Collection Process for Zero Pricing

Verify that when creator selects the "Kathagada Parbatia Sahi" slum while creating the De-sludging application the payment details should be ₹ 0

1.Login as creator. 2.Create an application by selecting the "Kathagada Parbatia Sahi" slum option .

Payment details should be ₹ 0 when creator creates the application by selecting "Kathagada Parbatia Sahi "slum option

when creator selects the "Kathagada Parbatia Sahi" slum while creating the De-sludging application the payment details is showing as ₹ 0

PASSED

Zero pricing_03

Zero pricing

Skip Collection Process for Zero Pricing

Verify that when the citizen created the application by selecting the slum option then that applicaton while completing the request ,It should not ask the payment details.

1.Login as Editor. 2.click on inbox and enter the application number and click on the application number, 3.click on take action 4.complete the request.

Verify that when the citizen created the application, by selecting the slum option then that applicaton while completing the request ,It should not ask the payment details.

when the citizen created the application by selecting the slum option then that applicaton while completing the request ,It is not asking the payment details.

PASSED

Zero pricing_04

Zero pricing

Skip Collection Process for Zero Pricing

Configure property type as Residential and sub property type as independent house using API for zero pricing by NOT selecting any slum

Select property type as Residential and sub property type as independent house using API for zero pricing by NOT selecting any slum

Citizen Should not able to create the application

Citizen cannot able to create the application

PASSED

Advance Balance Workflow Enhancement

Advance Balance Workflow _01

Advance Balance Workflow

Verify when minimum pricing by the ULB is zero and citizen chooses to pay 0

1.Login as citizen. 2.Set the minimum pricing given by the ULB

A citizen creates a request where minimum pricing by the ULB is zero and citizen chooses to pay 0. No. of Trips = 1, Amount per Trip is 1000. The workflow is as follows: Create request ----> Accept Request ------> Assign DSO -------> Assign Vehicle ------> Collect Payment ------> Complete Request The collect payment step should display 100% of the total amount as amount due. The payment receipt displays Amount per trip: 1000, Total Amount: 1000, Advance amount paid: 0, Balance amount paid: 1000, Total due: 0

PASSED

Advance Balance Workflow _02

Advance Balance Workflow

Verify when A citizen creates a new request. The minimum pricing by the ULB is 100%.

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. The citizen chooses 1 trip, Amount per trip = 1000. The input box for entering Advance Amount is non editable and displays value equal to 100% of the trip amount.

The citizen chooses 1 trip, Amount per trip = 1000. The input box for entering Advance Amount is non editable and displays value equal to 100% of the trip amount. The acknowledgment receipt displays the following: Amount per trip: 1000 Total Amount: 1000 Advance Amount due: 1000

PASSED

Advance Balance Workflow _03

Advance Balance Workflow

Verify when A citizen creates a new request. The minimum pricing by the ULB is 100%. and When the no. of trips is edited by the ULB to 2, advance amount is updated automatically for 100% of the amount for 2 trips.

The citizen chooses 1 trip, Amount per trip = 1000. The input box for entering Advance Amount is non editable and displays value equal to 100% of the trip amount. When the no. of trips is edited by the ULB to 2, advance amount is updated automatically for 100% of the amount for 2 trips. he acknowledgment receipt displays the following: Amount per trip: 1000 Total Amount: 1000 Advance Amount due: 1000

PASSED

Advance Balance Workflow _04

Advance Balance Workflow

Verify when a citizen creates a new request where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs.

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. citizen creates a new request where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs..

A citizen creates a new request where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs. The collection screen displays 600 Rs. The workflow is as follows: Create Request -----> Accept Request------> Collect Payment -------> Assign Vehicle ----->Collect Payment ----> Complete Request

PASSED

Advance Balance Workflow _05

Advance Balance Workflow

Verify when a citizen created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount”.

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. citizen created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount”.

citizen created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount”.

PASSED

Advance Balance Workflow _06

Advance Balance Workflow

Verify when a ULB creates a request where minimum pricing by the ULB is zero and citizen chooses to pay 0. The workflow is as follows:

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. ULB creates a request where minimum pricing by the ULB is zero and citizen chooses to pay 0. The workflow is as follows:

A ULB creates a request where minimum pricing by the ULB is zero and citizen chooses to pay 0. The workflow is as follows: Create request ----> Accept Request ------> Assign DSO -------> Assign Vehicle ------> Collect Payment ------> Complete Request The collect payment step should display 100% of the total amount as amount due

PASSED

Advance Balance Workflow _07

Advance Balance Workflow

Verify when a ULB creates a new request. The minimum pricing by the ULB is 100%. The citizen chooses 1 trip and The input box for entering Advance Amount is non editable and displays value equal to 100% of the trip amount. When the no. of trips is edited by the ULB to 2, advance amount is updated automatically for 100% of the amount for 2 trips

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. ULB creates a new request. The minimum pricing by the ULB is 100%.

A ULB creates a new request. The minimum pricing by the ULB is 100%. The citizen chooses 1 trip and The input box for entering Advance Amount is non editable and displays value equal to 100% of the trip amount. When the no. of trips is edited by the ULB to 2, advance amount is updated automatically for 100% of the amount for 2 trips.

PASSED

Advance Balance Workflow _08

Advance Balance Workflow

Verify when ULB creates a new request with 1 trip and trip amount as 1000 where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3. ULB creates a new request with 1 trip and trip amount as 1000 where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs

ULB creates a new request with 1 trip and trip amount as 1000 where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs verify acknowledgement, collection screen, payment receipt, Post servicing, collection screen, ayment receipt

PASSED

Advance Balance Workflow _09

Advance Balance Workflow

Verify when ULB creates a new request with 1 trip and trip amount as 1000 where minimum pricing by the ULB is set at 500 Rs. The citizen chooses to pay 600 Rs

PASSED

Advance Balance Workflow _10

Advance Balance Workflow

Verify when ULB created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount

1.Login as citizen. 2.Set the minimum pricing given by the ULB 3.ULB created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount

ULB created a new request. Minimum pricing by the ULB is set at 500 Rs. The citizen enters Rs. 400. An error is shows which states “Amount entered is less than minimum amount

PASSED

Requests unable to be completed when requests are being created using driver/DSO/employee number

Driver/DSO/employee - Request creation_01

Driver/DSO/employee - Request creation

Verify Requests unable to be completed when requests are being created using driver/DSO/employee number

1. Login as DSO 2. Use same phone number as citizen and employee

Check whether Requests unable to be completed when requests are being created using driver/DSO/employee number

Requests unable to be completed when requests are being created using driver/DSO/employee number

PASSED

Test Cases

https://digit-discuss.atlassian.net/browse/SAN-1017 https://digit-discuss.atlassian.net/browse/SAN-1159

Employee_01

Employee

Employee Search details

Verify if UB employee is able to Search without filling details and only selecting date range should display results

1. Login to ULB employee editor and go to inbox 2. Click on search application 3. Give the date range from and to

Should be able to see all applications created in the date range and no other field should be mandatory

PASSED

https://digit-discuss.atlassian.net/browse/SAN-996 https://digit-discuss.atlassian.net/browse/SAN-1163

Editor_01

Editor

Editor Application timeline

Verify Application timeline correct Provider Info- Editor side

1. Login as citizen/creator 2. Create an applciation and fill all details and go until last step using Editor login 3. Validate the application timeline info

Appication time line should show below information Request Completed Pending Citizen Feedback - citizen info Disposed - FSTPO info Disposal in progress - Driver Info Pending for Payment - Accountant Info DSO in Progress - DSO info Pending for DSO Approval - NA Pending for DSO Assignment - NA Application created - Citizen contact info

PASSED

https://digit-discuss.atlassian.net/browse/SAN-978 https://digit-discuss.atlassian.net/browse/SAN-1168

UI_UX_01

UI/UX

Verify UI UX enhancements in citizen and employee login

1. login as citizen/Employee 2. Validate below UI UX enhancements In Employee Login, FSM Icon in Card is missing on left top card In Update Application success screen, Localisation of Select DSO Now, Select DSO need to be changed In Update and Schedule screen from employee side, When Septic tank with soak pit is selected, needs to remove spacing in pit dimension In Collector Login, when collecting payment need to remove spacing in payment mode in radio button

Below UI UX enhancements are validated In Employee Login, FSM Icon in Card is missing on left top card In Update Application success screen, Localisation of Select DSO Now, Select DSO need to be changed In Update and Schedule screen from employee side, When Septic tank with soak pit is selected, needs to remove spacing in pit dimension In Collector Login, when collecting payment need to remove spacing in payment mode in radio button

PASSED

DSO_01

DSO

DSO - Assign vehicle

Verify DSO is able to assign same vehicle for multiple requests - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number. 4) Click on take action and Assign the vehicle. 5) Select another application. 6) Click on take action and Assign same vehicle.

DSO Should be able to assign same vehicle to multiple requests.

PASSED

DSO_02

DSO

DSO - Assign vehicle

Verify DSO is able to assign same vehicle for multiple requests - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number. 4) Click on take action and Assign the vehicle. 5) Select another application. 6) Click on take action and Assign same vehicle.

DSO Should be able to assign same vehicle to multiple requests.

PASSED

DSO_03

DSO

DSO - Assign vehicle

Verify Vehicle capacity field and Number of trips is disable while assigning vehicle - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number and Assign the vehicle. 4) Check vehicle capacity and number of trips fields.

Vehicle capacity and number of trips should be deisable.

PASSED

DSO_04

DSO

DSO - Assign vehicle

Verify Vehicle capacity field and Number of trips is disable while assigning vehicle - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number and Assign the vehicle. 4) Check vehicle capacity and number of trips fields.

Vehicle capacity and number of trips should be deisable.

PASSED

DSO_05

DSO

DSO - Assign vehicle

Verify DSO assigned vehicle is captured on new application - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number and Assign vehicle. 4) Check application.

DSO assigned vehicle number should be captured on new application.

PASSED

DSO_06

DSO

DSO - Assign vehicle

Verify DSO assigned vehicle is captured on new application - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number and Assign vehicle. 4) Check application.

DSO assigned vehicle number should be captured on new application.

PASSED

DSO_07

DSO

DSO - Assign vehicle

Verify DSO is able to overwrite number of trips while scheduling vehicle - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and overwrite number of trips.

DSO should be able to overwrite number of trips.

PASSED

DSO_08

DSO

DSO - Assign vehicle

Verify DSO is able to overwrite number of trips while scheduling vehicle - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and overwrite number of trips.

DSO should be able to overwrite number of trips.

PASSED

DSO_09

DSO

DSO - Assign vehicle

Verify DSO is able to select valid date in Desludging on field - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and Select valid date.

DSO Should be able to select valid date.

PASSED

DSO_10

DSO

DSO - Assign vehicle

Verify DSO is able to select valid date in Desludging on field - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and Select valid date.

DSO Should be able to select valid date.

PASSED

DSO_11

DSO

DSO - Assign vehicle

Verify DSO is able to schedule vehicle - ENGLISH

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and Click on schedule.

DSO should be able to schedule vehicle.

PASSED

DSO_12

DSO

DSO - Assign vehicle

Verify DSO is able to schedule vehicle - HINDI

1) Login as DSO. 2) Click on inbox. 3) Click on application number and assign vehicle. 4) Click on take action and Click on schedule.

DSO should be able to schedule vehicle.

PASSED

https://digit-discuss.atlassian.net/browse/SAN-1063 https://digit-discuss.atlassian.net/browse/SAN-1157

FSTPO_01

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Home button

1.Login as FSTPO in mobile 2.click on Home button

FSTPO should be able to see home page details

PASSED

FSTPO_02

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Inbox button in FSTPO operations page

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Inbox button

FSTPO Should be able to view Inbox page

PASSED

FSTPO_03

FSTPO

FSTPO Inbox

To verify FSTPO Can able to enter all fields and FSTPO Should able to select Application number or Vehicle log number

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Inbox button a 4.Enter all the fields or 5.Click on Application number or Vehicle log number

FSTPO Should be able to view vehicle scheduling page

PASSED

FSTPO_04

FSTPO

FSTPO Inbox

To verify FSTPO Can able to select Search Button

1.Login as FSTPO in Mobile 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.Click on Select 7.Enter application number or vehicle number or Dso name

FSTPO Should be able to view application details after filtered

PASSED

FSTPO_05

FSTPO

FSTPO Inbox

To verify FSTPO Can able to select Sort Button

1.Login as FSTPO in Mobile 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.Click on Select 7.Click on Date(latest first) or click on Date(latest last)

FSTPO Should be able to view application details after filtered

PASSED

FSTPO_06

FSTPO

FSTPO Inbox

To verify FSTPO can able to enter all fields and Vehicle in time and vehicle out time in vehicle entry log page and FSTPO can able to choose file from device and able to upload that file

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.click on citizen name 7.click on Select 8.Fill the details in all the fields 9.Click on choose file and select a photo and upload it

FSTPO Should able to enter all the fields and FSTPO should able to view photo uploaded details

PASSED

FSTPO_07

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Take action button in vehicle scheduling page

FSTPO Should be able to view Submit button or Decline vehicle button

PASSED

FSTPO_08

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Submit button in vehicle scheduling page

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.click on citizen name. 9.Fill the details in all the fields 10.Click on choose file and select a photo and upload it 11.click on Take action button 12.Click on submit

FSTPO Should be able to view vehicle submitted sucessfully message on the screen

PASSED

FSTPO_09

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Decline vehicle button in vehicle scheduling page

.1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.click on citizen name 7.Fill the details in all the fields 8.Click on choose file and select a photo and upload it 9.click on Take action button 10.Click on submit 11.click on Decline vehicle

FSTPO Should be able to view reason for Declining

PASSED

FSTPO_10

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Reason For Declining Dropdown

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Add new button 4.Enter vehicle number 5.click on next 6.click on citizen name 7.Fill the details in all the fields 8.Click on choose file and select a photo and upload it 9.click on Take action button 10.click on Decline vehicle 11.Select anyone of the reason from Reason For declining dropdown

FSTPO Should be able to select any one reason

PASSED

FSTPO_11

FSTPO

FSTPO Inbox

To verify FSTPO can able to select Decline vehicle button

FSTPO Should be able to view updated sucessfully message on the screen

PASSED

https://digit-discuss.atlassian.net/browse/SAN-1064 https://digit-discuss.atlassian.net/browse/SAN-1158

FSTPO_01

FSTPO

FSTPO Home

To verify FSTPO can able to select Home button

1.Login as FSTPO in mobile 2.click on Home button

FSTPO should be able to see home page details

PASSED

FSTPO_02

FSTPO

FSTPO Home

To verify FSTPO can able to select Inbox button in FSTPO operations page

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Inbox button

FSTPO Should be able to view Inbox page

PASSED

FSTPO_03

FSTPO

FSTPO Home

To verify FSTPO Can able to enter all fields and FSTPO Should able to select Application number or Vehicle log number

1.Login as FSTPO in Desktop 2.click on Home button 3.Click on Inbox button a 4.Enter all the fields or 5.Click on Application number or Vehicle log number

FSTPO Should be able to view vehicle scheduling page

PASSED

FSTPO_04

FSTPO

FSTPO Home

To verify FSTPO can able to enter all fields and Vehicle in time and vehicle out time in vehicle entry log page and FSTPO can able to choose file from device and able to upload that file

FSTPO Should able to enter all the fields and FSTPO should able to view photo uploaded details

PASSED

FSTPO_05

FSTPO

FSTPO Home

To verify FSTPO can able to select Take action button in vehicle scheduling page

FSTPO Should be able to view Submit button or Decline vehicle button

PASSED

FSTPO_06

FSTPO

FSTPO Home

To verify FSTPO can able to select Submit button in vehicle scheduling page

FSTPO Should be able to view vehicle submitted sucessfully message on the screen

PASSED

FSTPO_07

FSTPO

FSTPO Home

To verify FSTPO can able to select Decline vehicle button in vehicle scheduling page

FSTPO Should be able to view reason for Declining

PASSED

FSTPO_08

FSTPO

FSTPO Home

To verify FSTPO can able to select Reason For Declining Dropdown

FSTPO Should be able to select any one reason

PASSED

FSTPO_09

FSTPO

FSTPO Home

To verify FSTPO can able to select Decline vehicle button

FSTPO Should be able to view updated sucessfully message on the screen

PASSED

https://digit-discuss.atlassian.net/browse/SAN-987 https://digit-discuss.atlassian.net/browse/SAN-1165

Editor_01

Editor

DSO Photo upload

Verify if Editor should be able to view the photo uploaded by DSO

1. Login to citizen/creator 2. Go through all the steps and create application 3. Go until DSO login 4. Login as DSO ,upload the photo

Photo should be uploaded

PASSED

Editor_02

Editor

DSO Photo upload

Verify if Editor should be able to view the photo uploaded by DSO

1. Login to citizen/creator 2. Go through all the steps and create application 3. Go until DSO login 4. Login as DSO ,upload the photo 5.Login as editor and check photos uploaded by DSO is viewable

Editor should able to view photo in his timeline

PASSED

https://digit-discuss.atlassian.net/browse/SAN-1037 https://digit-discuss.atlassian.net/browse/SAN-1162

DSO and FSTPO

Photo uploads

To check all the application timeline aligned with roles

1.Go through until Application updated/payment/trips screen

Application timeline should be aligned with roles

PASSED

Editor_01

DSO and FSTPO

Photo uploads

To check photos uploaded by DSO

1.Login as editor check who has uploaded the DSO

Editor should be viewable as photo uploaded by DSO

PASSED

Editor_02

DSO and FSTPO

Photo uploads

To check the breadcrumbs in all the FSTPO pages

1.Login as FSTPO Check all the breadcrumbs

Breadcrumbs should be in the format Home/Inbox/vehicle log

PASSED

Editor_03

DSO and FSTPO

Photo uploads

To check the the Disposing time Schedule in the Format AM/PM

1.Login as FSTPO Check whether Disposal time schedule is in the format AM/PM

FSTPO Should be able to select AM/PM in Disposal scheduling page

PASSED

https://digit-discuss.atlassian.net/browse/SAN-1075 https://digit-discuss.atlassian.net/browse/SAN-1160

UI_UX_01

Ui/UX

UI/UX changes

Verify UI UX enhancements in citizen and employee login

1. login as citizen/Employee 2. Validate below UI UX enhancements 3.Log in as citizen,In service request text change in trip number screen in create application 4.Login as citizen ,In trip number screen in citizen side, number of trips will be on top and vehicle capacity will be on bottom. 5.Login as DSo Localisation should be changed from Scheduled to Update Trips 6.Login as Citizen all the Location detail and pit detail and combining all under property details

In UI UX AUDIT 1.In service request text change in trip number screen in create application should be creadted. 2.Citizen should be viewable In trip number screen in citizen side, number of trips will be on top and vehicle capacity will be on bottom. 3.Schedule localisation shoule be changed to Update trips 4.All the location details and pit details should be under property details

PASSED

Employee _01

Employee

Dashboard charts

1.Dashboard Should have pie chart for gender,revenue by usage type,application preference,customer rating ,request status , data and Apply all the drill-down (by Date, ULB) on payment chart 2.Dashboard should be on mobile and desktop versions 3.The Dashboard chart should be shareable and downloadable

Dashboard should display pie chart for gender,revenue by usage type,application preference,customer rating ,request status , data and Apply all the drill-down and dashboard should be viewable in both mobile and desktop versions and it should be in shareable and downable format

PASSED

Citizen Flow

FSM/Citizen/01

Citizen

Citizen feedback

Validate that Citizen is able to verify new field "Number of Trips" on citizen feedback page_With English and Hindi Language

1. Login as Citizen 2. Go to My application 3.Citizen should be able to see the completed application 4.Validate that Citizen is able to verify new field "Number of Trips" on citizen feedback page in EN & Hindi

1)Citizen is able to verify new field "Number of Trips" on citizen feedback page In EN 2)Citizen is able to verify new field "कुल फेरों की संख्या" on citizen feedback page_Hindi

PASSED

FSM/Citizen/02

Citizen

Citizen feedback

Validate Citizen is able to Add integer from dropdown field on citizen feedback page_Hindi/English

1. Login as Citizen 2. Go to My application 3.Citizen should be able to see the completed application 4.Validate that Citizen is able to Add integer from dropdown field on citizen feedback page 5.Validate that Citizen is able to submit the feed back with giving the proper rating and comments

Citizen will be able to Add integer from 1-10 from drop down and will be able to submit the feedback

PASSED

FSM/Citizen/03

Citizen

Citizen feedback

Validate that Total number of trips field should not be mandatory for feedback submission _Hindi/English

1. Login as Citizen 2. Go to My application 3.Citizen should be able to see the completed application 4.Validate that Citizen is able to submit the feed back without Total num of Field trips

Citizen will be able to submit the feed back without Total num of Field trips

PASSED

Citizen Flow

FSM/Citizen/05

Citizen

Citizen feedback number of trips

Validate that citizen gender info is Captured on New application right after OTP step with citizen login_English_Male

1.Login as a Citizen in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that citizen gender info is Captured on New application as Male right after OTP step 5.Validate Citizen is able to Complete the Request further with required details 6.Validate Citizen shouldn’t see gender information on the application summary view

1. citizen gender info is Captured on New application as Male right after OTP step 2. Citizen shouldn’t see gender information on the application summary view

PASSED

FSM/Citizen/06

Citizen

Citizen feedback number of trips

Validate that citizen gender info is Captured on New application right after OTP step with citizen login_Hindi_Female

1.Login as a Citizen in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that citizen gender info is Captured on New application as Female right after OTP step 5.Validate Citizen is able to Complete the Request further with required details 6.Validate Citizen shouldn’t see gender information on the application summary view

1. citizen gender info is Captured on New application as Female right after OTP step 2. Citizen shouldn’t see gender information on the application summary view

PASSED

FSM/Citizen/07

Citizen

Citizen feedback number of trips

Validate that citizen gender info is Captured on New application right after OTP step with Employee Creator login_English_Transgender

1.Login as a Employee Creator in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that citizen gender info is Captured on New application as Transgender right after OTP step 5.Validate Citizen is able to Complete the Request further with required details 6.Validate Citizen shouldn’t see gender information on the application summary view

1. citizen gender info is Captured on New application as Transgender right after OTP step 2. Citizen shouldn’t see gender information on the application summary view

PASSED

FSM/Citizen/08

Citizen

Citizen feedback number of trips

Validate that citizen gender info is Captured on New application right after OTP step with Employee Creator login_Hindi_Others

1.Login as a Employee Creator in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that citizen gender info is Captured on New application as Others right after OTP step 5.Validate Citizen is able to Complete the Request further with required details 6.Validate Citizen shouldn’t see gender information on the application summary view

1. citizen gender info is Captured on New application as Others right after OTP step 2. Citizen shouldn’t see gender information on the application summary view

PASSED

FSM/Citizen/09

Citizen

Citizen feedback number of trips

Validate that Citizen gender step is skippable with Citizen Login_Hindi

1.Login as a Citizen in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that Citizen gender step is skippable

It is Validated that Citizen gender step is skippable in Citizen Logins

PASSED

FSM/Citizen/10

Citizen

Citizen feedback number of trips

Validate that Citizen gender step is skippable with Employee creator Login_English

1.Login as a Employee Creator in mSeva Portal 2.Navigate to FSM 3.Citizen Create New Application 4.Validate that Citizen gender step is skippable

It is Validated that Citizen gender step is skippable in Employee creator Logins

PASSED

FSM/Citizen/11

Citizen

Citizen feedback number of trips

Validate that Employee editor is able to view the gender of the applicant on the application summary view_Hindi

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that Employee is able to view the gender of the applicant on the application summary view

Employee is able to view the gender of the applicant on the application summary view

PASSED

FSM/Citizen/12

Citizen

Citizen feedback number of trips

Validate that DSO is not able to view the gender of the applicant on the application summary view_English

1.Login as a DSO in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that DSO is not able to view the gender of the applicant on the application summary view

DSO is not able to view the gender of the applicant on the application summary view

PASSED

DSO Flow

FSM/DSO/01

DSO

DSO validation message

Validate message when unregistered phone number is entered in DSO login_English

1.Login to the mSeva Portal 2.Navigate to FSM 3.User click on DSO Login 4."Validate message when unregistered phone number is entered in DSO login: Please use a registered number for logging as a DSO"

validate message when unregistered phone number is entered in DSO login: Please use a registered number for logging as a DSO

PASSED

FSM/DSO/02

DSO

DSO validation message

Validate message when unregistered phone number is entered in DSO login_Hindi

1.Login to the mSeva Portal 2.Navigate to FSM 3.User click on DSO Login 4. Validate message when unregistered phone number is entered in DSO login: कृपया डीएसओ के रूप में लॉगिंग के लिए पंजीकृत नंबर का उपयोग करें

Validate message when unregistered phone number is entered in DSO login: कृपया डीएसओ के रूप में लॉगिंग के लिए पंजीकृत नंबर का उपयोग करें

PASSED

FSM/DSO/03

DSO

DSO validation message

Validate when DSO login with registered phone number is able to see the application_English

1.Login to the mSeva Portal 2.Navigate to FSM 3.User click on DSO Login 4. Validate when DSO login with registered phone number is able to see the application

Validate when DSO login with registered phone number is able to see the application

PASSED

FSM/DSO/04

DSO

DSO validation message

Validate when DSO login with registered phone number is able to see the application_Hindi

1.Login to the mSeva Portal 2.Navigate to FSM 3.User click on DSO Login 4.Validate when DSO login with registered phone number is able to see the application

Validate when DSO login with registered phone number is able to see the application

PASSED

DSO Flow

FSM/DSO/01

DSO

DSO - edit pit and property usage details

Validate that DSO can edit the Pit Details for a application_English

1.Login as a DSO in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that DSO can edit the Pit Type and Pit Dimension and Upload a PIT photo for a application 5.Validate DSO is able to Submit the Request further with required details

1.DSO will be able to edit the Pit Type and Pit Dimension and Upload a PIT photo for a application

PASSED

FSM/DSO/02

DSO

DSO - edit pit and property usage details

Validate that DSO can edit the Pit Details for a application_Hindi

1.DSO will be able to edit the Pit Type and Pit Dimension and Upload a PIT photo for a application

PASSED

FSM/DSO/03

DSO

DSO - edit pit and property usage details

Validate that DSO cannot modify the applicant and the property address for a application_Hindi

1.Login as a DSO in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that DSO cannot modify the applicant and the property address for a application

1.DSO will not be able to edit the applicant and the property address for a application

PASSED

FSM/DSO/04

DSO

DSO - edit pit and property usage details

Validate that DSO cannot modify the possible service date_English

1.Login as a DSO in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that DSO cannot modify the possible service date for a application

1.DSO will not be able to modify the possible service date for a application

PASSED

FSM/DSO/05

DSO

DSO - edit pit and property usage details

Validate that DSO shouldn’t be able to modify old applications (i.e. service date < current date) or applications in citizen feedback pending status_Hindi/English

1.Login as a DSO in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that DSO shouldn’t be able to modify old applications (i.e. service date < current date) or applications in citizen feedback pending status

1.DSO will not be able to modify old applications (i.e. service date < current date) or applications in citizen feedback pending status

PASSED

Employee Specific Test Cases

Employee Flow

FSM/Emp/01

Employee

Employee - Select vehicle capacity instead of vehicle make

Validate ULB Employee select vehicle capacity instead of Vechile Type_English_Employee Editor

1.Login as a Employee Editor in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate ULB Employee select vehicle capacity from the drop down 5.Validate Vechile Type is not present in the form 6.Validate Employee is able to Submit the Request further

1) ULB Employee should be able to select vehicle capacity from the drop down 2)ULB Employee doesn’t see the Vechile Type in the entire form 3)ULB Employee is able to Submit the Request further

PASSED

FSM/Emp/02

Employee

Employee - Select vehicle capacity instead of vehicle make

Validate ULB Employee select vehicle capacity instead of Vechile Type_Hindi_Employee Editor

1) ULB Employee should be able to select vehicle capacity from the drop down 2)ULB Employee doesn’t see the Vechile Type in the entire form 3)ULB Employee is able to Submit the Request further

PASSED

FSM/Emp/03

Employee

Employee - Select vehicle capacity instead of vehicle make

Validate ULB Employee select vehicle capacity instead of Vechile Type_English_Employee Creator

1.Login as a Employee Creator in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down 4.Validate Vechile Type is not present in the form 5.Validate Employee is able to Submit the Request further

1) ULB Employee should be able to select vehicle capacity from the drop down 2)ULB Employee doesn’t see the Vechile Type in the entire form 3)ULB Employee is able to Submit the Request further

PASSED

FSM/Emp/04

Employee

Employee - Select vehicle capacity instead of vehicle make

Validate ULB Employee select vehicle capacity instead of Vechile Type_Hindi_Employee Creator

1) ULB Employee should be able to select vehicle capacity from the drop down 2)ULB Employee doesn’t see the Vechile Type in the entire form 3)ULB Employee is able to Submit the Request further

PASSED

DSO Specific Test Cases

DSO Flow

DSO_01

DSO

DSO - Edit property usage details

Check wehther "Try updating the pit details, it should allow the user to update the pit details."

1. Login as citizen and create an application 2. Login as editor and update application to make payment 3. Login as Collector and make payment 4. Login as Editor and update pit details and Asiign DSO 5. Login as DSO and Try updating the pit details, it should allow the user to update the pit details.

Try updating the pit details, it should allow the user to update the pit details.

PASSED

DSO_02

DSO

DSO - Edit property usage details

Check whether "DSO shouldn’t be able to modify old applications (i.e. desludging date < current date) or applications in citizen feedback pending status"

1. Login as citizen and create an application 2. Login as editor and update application to make payment 3. Login as Collector and make payment 4. Login as Editor and update pit details and Asiign DSO 5. Login as DSO and TDSO shouldn’t be able to modify old applications (i.e. desludging date < current date) or applications in citizen feedback pending status

DSO shouldn’t be able to modify old applications (i.e. desludging date < current date) or applications in citizen feedback pending status

PASSED

DSO_03

DSO

DSO - Edit property usage details

Check whether "DSO can add pit photo"

DSO can add pit photo

PASSED

DSO_04

DSO

DSO - Edit property usage details

Check whether Pre-selected Property and Pit details should be shown. If no value is present, then show - and data from mdms in the drop-down

1. Login as citizen and create an application 2. Login as editor and update application to make payment 3. Login as Collector and make payment 4. Login as Editor and update pit details and Asiign DSO 5. Login as DSO and DSO can Pre-selected Property and Pit details should be shown. If no value is present, then show - and data from mdms in the drop-down

Pre-selected Property and Pit details should be shown. If no value is present, then show - and data from mdms in the drop-down

PASSED

DSO_05

DSO

DSO - Edit property usage details

Check whether This will need to be a role based edit. This can be edited by roles = dso, editor

1. Login as citizen and create an application 2. Login as editor and update application to make payment 3. Login as Collector and make payment 4. Login as Editor and update pit details and Asiign DSO 5. Login as DSO and This will need to be a role based edit. This can be edited by roles = dso, editor

This will need to be a role based edit. This can be edited by roles = dso, editor

PASSED

DSO_06

DSO

DSO - Edit property usage details

Check whether the application should be editable in: Pending for DSO approval, DSO InProgress status

1. Login as citizen and create an application 2. Login as editor and update application to make payment 3. Login as Collector and make payment 4. Login as Editor and update pit details and Asiign DSO 5. Login as DSO and the application should be editable in: Pending for DSO approval, DSO InProgress status

the application should be editable in: Pending for DSO approval, DSO InProgress status

PASSED

DSO Specific Test Cases

DSO Flow

Vehicle_01

Employee

Employee - Edit property usage details

check whether Vehicle Capacity is a mandatory field

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down

Vehicle Capacity is a mandatory field

PASSED

Vehicle_02

Employee

Employee - Edit property usage details

check whether Vehicle Capacity should show unique capacity value from master data

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down

Vehicle Capacity should show unique capacity value from master data

PASSED

Vehicle_03

Employee

Employee - Edit property usage details

check whether Vehicle Capacity should show unique capacity value from master data

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down

Vehicle Capacity should show unique capacity value from master data

PASSED

Vehicle_04

Employee

Employee - Edit property usage details

Check whether Vehicle Type is not shown on any user interface

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down

Vehicle Type is not shown on any user interface

PASSED

Vehicle_05

Employee

Employee - Edit property usage details

Check whether Ensure that the logic for assignment of DSO is not changed with this ticket

1.Login as a Employee editor in mSeva Portal 2.Navigate to FSM 3.Validate ULB Employee select vehicle capacity from the drop down

Ensure that the logic for assignment of DSO is not changed with this ticket

PASSED

DSO Specific Test Cases

FSM/DSO/01

DSo and FSTPO

DSo and FSTPO gender

Check whether DSO gender addition is during DSO creation

1.User requests search DSO API 2.User can see the Gender info for that DSO in return

User should be able to Create new DSO with Gender info using Create DSO API and can Verify the gender info using search API.

PASSED

FSM/DSO/02

DSo and FSTPO

DSo and FSTPO gender

Check whether search API is updated so that DSO gender can be returned

1.User requests search DSO API 2.User can see the Gender info for that DSO in return

DSO gender is returned when Search DSO request is Triggered

PASSED

FSM/DSO/03

DSo and FSTPO

DSo and FSTPO gender

Validate If DSO is registered as Citizen then it should show Gender

1.Citizen is Registered as DSO 2.User requests search DSO API 3.User can see the Gender info for that DSO in return

Citizen is registered as DSO then Gender info should be returned

PASSED

FSM/DSO/04

DSo and FSTPO

DSo and FSTPO gender

Validate update API is Updating gender info for existing DSOs

1.User request Update API for updating gender infor for existing DSOs 2.User requests search DSO API 3.User can see the Gender info for that DSO in return

User should be able to request update API for existing DSOs with gender info

PASSED

FSM/DSO/05

DSo and FSTPO

DSo and FSTPO gender

Citizen gender should not get overriden when DSO gender is updated from Backend (pre requisite: when Citizen is a DSO also)

1.User request Update API for updating gender info for existing DSO 2.User requests search DSO API 3.User can see the Gender info for that DSO in return 4.Validate Citizen gender should not get overriden in UI

User should be able to validate Citizen gender is not getting overriden when DSO gender is updated from Backend (pre requisite: when Citizen is a DSO also)

PASSED

FSM/DSO/06

DSo and FSTPO

DSo and FSTPO gender

DSO gender should not get overriden when Citizen gender is updated from Backend (pre requisite: when Citizen is a DSO also)

1.User request Update API for updating gender info for existing citizen 2.User requests search citizen API 3.User can see the Gender info for that citizen in return 4.Validate DSO gender info should not get overriden in backend

User should be able to validate DSO gender is not getting overriden when Citizen gender is updated from Backend (pre requisite: when Citizen is a DSO also)

PASSED

Employee Specific Test Cases

FSM/Emp/01

Employee

Employee update number of trips

Validate that "No Option Availaible" message should be present in drop down when there is no vechicle present to assign in Assign Vechile page

1.Login as a Employee Editor in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that "No Option Availaible" message should be present in drop down on Assign Vechile page

User should be able to Validate that "No Option Availaible" message should be present in drop down on Assign Vechile page

PASSED

FSM/Emp/02

Employee

Employee update number of trips

Validate that list of Vechile is pesent in drop down in Assign Vechile page

1.Login as a Employee Editor in mSeva Portal 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate that list of Vechile is pesent in drop down in Assign Vechile page

User should be able to Validate that list of Vechile is pesent in drop down in Assign Vechile page

PASSED

Employee Flow

FSM/Emp/01

Employee

Employee - Slum area create application

Validate "Waiting for disposal" application status is added in filter _English

1.Login as a ULB Employee in mSeva Portal with English language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Waiting for disposal" application status is added in filter 5. Validate "Waiting for disposal" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

1. User should be able to Filter out the application on basis of "Waiting for disposal" Filter. 2. User is able to see "Waiting for disposal" under “Application Status” and see “-” under “SLA Days Remaining” 3)Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/02

Employee

Employee - Slum area create application

Validate "Disposed" application status is added in filter_English

1.Login as a ULB Employee in mSeva Portal with English language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Disposed" application status is added in filter 5. Validate "Disposed" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

1. User should be able to Filter out the application on basis of "Disposed" Filter. 2. User is able to see"Disposed" under “Application Status” and see “-” under “SLA Days Remaining” 3)Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/034

Employee

Employee - Slum area create application

Validate "Citizen Feedback Pending" application status is added in filter _English

1.Login as a ULB Employee in mSeva Portal with English language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Citizen Feedback Pending" application status isadded in filter 5. Validate "Citizen Feedback Pending" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

1. User should be able to Filter out the application on basis of "Citizen Feedback Pending" Filter. 2. User is able to show "Citizen Feedback Pending" under “Application Status” and see “-” under “SLA Days Remaining” 3)Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/04

Employee

Employee - Slum area create application

Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter_English

1.Login as a ULB Employee in mSeva Portal with English language 2.Navigate to FSM 3.Go to employee inbox 4.Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter 5. Validate "Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status under “Application Status” and show “num of days” under “SLA Days Remaining”

1. User should be able to see Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status in filter column 2. User is able to see above status under “Application Status” and see “num of days” under “SLA Days Remaining” 3.Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/05

Employee

Employee - Slum area create application

Validate "Waiting for disposal" application status is added in filter_Hindi

1.Login as a ULB Employee in mSeva Portal with Hindi language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Waiting for disposal" application status is added in filter 5. Validate "Waiting for disposal" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/06

Employee

Employee - Slum area create application

Validate "Disposed" application status is added in filter_Hindi

1.Login as a ULB Employee in mSeva Portal with Hindi language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Disposed" application status is added in filter 5. Validate "Disposed" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

tatus should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/07

Employee

Employee - Slum area create application

Validate "Citizen Feedback Pending" application status is added in filter_Hindi

1.Login as a ULB Employee in mSeva Portal with Hindi language 2.Navigate to FSM 3.Go to employee inbox 4.Validate "Citizen Feedback Pending" application status isadded in filter 5. Validate "Citizen Feedback Pending" under “Application Status” and show “-” under “SLA Days Remaining” 6)Status should also reflect on application Timeline when user click on application

1. User should be able to Filter out the application on basis of "Citizen Feedback Pending" Filter. 2. User is able to show "Citizen Feedback Pending" under “Application Status” and see “-” under “SLA Days Remaining” 3.Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/08

Employee

Employee - Slum area create application

Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter_Hindi

1.Login as a ULB Employee in mSeva Portal with Hindi language 2.Navigate to FSM 3.Go to employee inbox 4.Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter 5. Validate "Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status under “Application Status” and show “num of days” under “SLA Days Remaining”

PASSED

Citizen Flow

FSM/Citizen/01

Citizen

Add ULB contact in FSM application flow

Validate Citizen is able to see helpline numbe on hamburger menu_English

1.Login as a Citizen with English Language 2.Navigate to FSM 3.Validate Citizen is able to see helpline numbe on hamburger menu

Citizen should be able to see Helpline number on hamburger menu

PASSED

FSM/Citizen/02

Citizen

Add ULB contact in FSM application flow

Helpline link should be clickable and trigger call function for the entered number_English

1.Login as a Citizen with English Language 2.Navigate to FSM 3.Validate Citizen is able to see helpline numbe on hamburger menu 4.Helpline link should be clickable and trigger call function for the entered number

Citizen should be able to click Helpline link and trigger call function for the entered number

PASSED

FSM/Citizen/03

Citizen

Add ULB contact in FSM application flow

Validate Citizen is able to see helpline numbe on hamburger menu_Hindi

1.Login as a Citizen with Hindi Language 2.Navigate to FSM 3.Validate Citizen is able to see helpline numbe on hamburger menu

Citizen should be able to see Helpline number on hamburger menu

PASSED

FSM/Citizen/04

Citizen

Add ULB contact in FSM application flow

Helpline link should be clickable and trigger call function for the entered number_Hindi

1.Login as a Citizen with Hindi Language 2.Navigate to FSM 3.Validate Citizen is able to see helpline numbe on hamburger menu 4.Helpline link should be clickable and trigger call function for the entered number

Citizen should be able to click Helpline link and trigger call function for the entered number

PASSED

FSTPO Specific Test Cases

FSTPO Flow

FSM/FSTPO/01

FSTPO

FSTPO can decline the vehicle trip

Validate Decline Vehicle action should be added for FSTPO,with predefined reasons and conditional comment option

1.Login as a FSTPO 2.Navigate to FSM 3.Search for application and Click on Take action 4.Validate Decline Vehicle action with predefined reasons and conditional comment option is added for FSTPO

User should be able to Validate Decline Vehicle action with predefined reasons and conditional comment option is added for FSTPO

PASSED

FSM/FSTPO/02

FSTPO

FSTPO can decline the vehicle trip

Validate Reason for Declining is a mandatory Field

1.Login as a FSTPO with English/Hindi language 2.Navigate to FSM 3.Search for application and Click on Take action 4.FSTPO clicks on Decline Vehicle button without choosing Reason for Declining 5.Validate error msg: This field cannot be empty

Reason for Declining is a Mandatory Field

PASSED

FSM/FSTPO/03

FSTPO

FSTPO can decline the vehicle trip

Validate when "others" is selected as Reason for Declining then "Comments" input box appear which is mandatory field

1.Login as a FSTPO with English/Hindi language 2.Navigate to FSM 3.Search for application and Click on Take action 4.FSTPO choose "Others" in Reason for Declining Field 5.Validate "Comments" input box appear 6.FSTPO clicks on Decline Vehicle button without entering anything in "comment" input box 7.Validate error msg: This field cannot be empty

If "others" is selected as Reason for Declining then "Comments" input box appear which is mandatory field

PASSED

FSM/FSTPO/04

FSTPO

FSTPO can decline the vehicle trip

Validate After declining from FSTPO, the vehicle trip will be in “TRIP DECLINED” status

1.Login as a FSTPO with English/Hindi language 2.Navigate to FSM 3.Search for application and Click on Take action 4.FSTPO choose Reason for Declining and clicks on "Decline Vehicle" Button. 5.Validate the vehicle trip will be in “TRIP DECLINED” status

Validate After declining from FSTPO, the vehicle trip should be in “TRIP DECLINED” status

PASSED

FSM/FSTPO/05

FSTPO

FSTPO can decline the vehicle trip

Validate Declining a vehicle will not require Vehicle Out time

Validate Declining vehicle should not require Vehicle Out time

PASSED

Dashboard Specific Test Cases

FSM/DSS/01

Dashboard

Validate a pie-chart for Request by gender in FSM Dashboard in Desktop

1.Login as a FSM DSS in mSeva Portal in Desktop 2.Navigate to Dashboard and then in FSM 3.Validate a pie-chart for Request by gender in FSM DSS Dashboard is Present

It is Validated a pie-chart for Request by gender in FSM DSS Dashboard is Present in Desktop version

PASSED

FSM/DSS/02

Dashboard

Validate that the view of DSS Dashbord is in 2x2 ( ColumnxRow)

1.Login as a FSM DSS in mSeva Portal 2.Navigate to Dashboard and then in FSM 3.Validate that the view of DSS Dashbord is in 2x2 ( ColumnxRow)

It is Validated that the view of DSS Dashbord is in 2x2 ( ColumnxRow)

PASSED

FSM/DSS/03

Dashboard

Validate the DSS Dashboard is seen with gender info in Mobile Version

1.Login as a FSM DSS in mSeva Portal in Mobile 2.Navigate to Dashboard and then in FSM 3.Validate the DSS Dashboard is seen with gender info in Mobile Version

It is Validated that DSS Dashboard is seen with gender info in Mobile Version

PASSED

FSM/DSS/04

Dashboard

Validate the FSM Dashboard is Shareable and can be downloaded in PDF

1.Login as a FSM DSS in mSeva Portal in Mobile 2.Navigate to Dashboard and then in FSM 3.Validate the DSS Dashboard is sharable 4.Validate the DSS Dashboard can be Downloaded in PDF

It is Validated that DSS Dashboard is Shareable and can be downloaded as well

PASSED

FSM/FSM-CREATOR_EMP_01

Employee Creator

Creator- Application creation

Check whether FSM-CREATOR can Create an application request with property type institutional , with capacity of vehicle as 5000 litres and number os trips 3 - the auto calculated amount should be = 2400 * 3 = Rs.7200/- -- ENGLISH

1. Login as citizen/creator and create an application 2. Login as editor and check if you are able toedit the application 3. Check if the number of trips is editable by selecting INSTITUTIONAL 4. Total Price calculated should be no of trips * price for each price

Calculated amount should display = 2400 * 3 = Rs.7200/-

FSM/FSM-CREATOR_EMP_03

Employee Creator

Creator- Application creation

Check whether FSM-CREATOR can Create an application request with property type commercial ,with capacity as 1000 and number of trips 1 - the auto calculated amount should be = 1000*1 = Rs.1000/- -- ENGLISH

1. Login as FSM-CREATOR_EMP 2. FSM-CREATOR enter login ID and password, choosing city as Amritsar 3. Navigte to application creation page 4. Entr all the required fields, make sure to select COMMERCIAL , with capacity as 1000 and number of trips 1 5. Auto Calculated amount should display = 1000*1 = Rs.1000/-

calculated amount should be = 1000*1 = Rs.1000/-

PASSED

FSM/FSM-CREATOR_EMP_05

Employee Creator

Creator- Application creation

Check whether FSM-CREATOR can Create an application request with property type residential , with capacity of vehicle as 5000 litres with slum data and number os trips 3 - the auto calculated amount should be = 1500 * 3 = Rs.4500/- -- ENGLISH

1. Login as FSM-CREATOR_EMP 2. FSM-CREATOR enter login ID and password, choosing city as Amritsar 3. Navigte to application creation page 4. Entr all the required fields, make sure to select RESIDENTIAL , with capacity of vehicle as 5000 litres with slum data and number os trips 3 5. Auto calculated amount should be = 1500 * 3 = Rs.4500/-

calculated amount should be = 1500 * 3 = Rs.4500/-

PASSED

FSM/FSM-CREATOR_EMP_07

Employee Creator

Creator- Application creation

1. Login as FSM-CREATOR_EMP 2. FSM-CREATOR enter login ID and password, choosing city as Amritsar 3. Navigte to application creation page 4. Entr all the required fields, make sure to select INSTITUTIONAL , with capacity of vehicle as 5000 litres and number os trips 3 5. Auto calculated amount should display = 2400 * 3 = Rs.7200/-

Calculated amount should display = 2400 * 3 = Rs.7200/-

PASSED

FSM/FSM-CREATOR_EMP_09

Employee Creator

Creator- Application creation

calculated amount should be = 1000*1 = Rs.1000/-

PASSED

FSM-EDITOR_Waiting_For_Dsiposal_Disposed_01

Employee

Show vehicle trip status in employee inbox along with fsm application

Check whther below status is updated 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality --ENGLISH

1. Login as a FSM-CREATOR 2. Creatte an applciation and submit 3. Login as FSM-EDITOR and go to inbox and look for the application created above 4. complete the DSO assignment process 5. Login with DSO and complete DSO process 6. Now the application status should be waiting for disposal since FSTPO is yet to be acted upon this 7. Login with FSM-EDITOR and go to inbox and check the status of the application and it should show as "Waiting for Disposal" 8. Now login with FSM-FSTPO and complete the application process 9. Now login with FSM-EDITOR and check the status under inbox it should as "Disposed" 10. Once the status is chagned to disposed, verify if the status is changed to "customer feedback pending" on the applcition--existing functionality

FSM-EDITOR All the 3 below status should be updated accordingly 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality

PASSED

FSM-EDITOR_SLA_for_Waiting_For_Dsiposal_Disposed_02

Employee

Show vehicle trip status in employee inbox along with fsm application

Check for SLA column for below status is present as - (No value) 1. Waiting for disposal 2. Disposed --ENGLISH

"1. Login as a FSM-CREATOR 2. Creatte an applciation and submit 3. Login as FSM-EDITOR and go to inbox and look for the application created above 4. complete the DSO assignment process 5. Login with DSO and complete DSO process 6. Now the application status should be waiting for disposal since FSTPO is yet to be acted upon this 7. Login with FSM-EDITOR and go to inbox and check the SLA status oshould be displayed as - (no value) for app status as ""Waiting for Disposal"" 8. Now login with FSM-FSTPO and complete the application process 9. Now login with FSM-EDITOR and check the status under inbox it should as SLA status should be displayed as - (no value) for applicationstatus as "disposed"

FSM-EDITOR SLA should be displayed as - for both the status of application

PASSED

FSM-EMP_FSTPO_Waiting_For_Dsiposal_Disposed_03

Employee

Show vehicle trip status in employee inbox along with fsm application

Check whther below status is updated 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality --ENGLISH

1. Login as a FSM-CREATOR 2. Creatte an applciation and submit 3. Login as FSM-EMP_FSTPO and go to inbox and look for the application created above 4. complete the DSO assignment process 5. Login with DSO and complete DSO process 6. Now the application status should be waiting for disposal since FSTPO is yet to be acted upon this 7. Login with FSM-EMP_FSTPO and go to inbox and check the status of the application and it should show as "Waiting for Disposal" 8. Now login with FSM-FSTPO and complete the application process 9. Now login with FSM-EMP_FSTPO and check the status under inbox it should as "Disposed" 10. Once the status is chagned to disposed, verify if the status is changed to "customer feedback pending" on the applcition--existing functionality

FSM-EMP_FSTPO All the 3 below status should be updated accordingly 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality

PASSED

FSM-EMP_FSTPO_SLA_for_Waiting_For_Dsiposal_Disposed_04

Employee

Show vehicle trip status in employee inbox along with fsm application

Check for SLA column for below status is present as - (No value) 1. Waiting for disposal 2. Disposed --ENGLISH

"1. Login as a FSM-CREATOR 2. Creatte an applciation and submit 3. Login as FSM-EMP_FSTPO and go to inbox and look for the application created above 4. complete the DSO assignment process 5. Login with DSO and complete DSO process 6. Now the application status should be waiting for disposal since FSTPO is yet to be acted upon this 7. Login with FSM-EMP_FSTPO and go to inbox and check the SLA status of the application vehcile trip status as ""Waiting for Disposal"" should be displayed as - (no value) 8. Now login with FSM-FSTPO and complete the application process 9. Now login with FSM-EMP_FSTPO and check the status under inbox it should as SLA status should be displayed as - (no value) for applicationstatus as "disposed"

FSM-EMP_FSTPO SLA should be displayed as - for both the status of application

PASSED

FSM-EDITOR_Waiting_For_Dsiposal_Disposed_HINDI_05

Employee

Show vehicle trip status in employee inbox along with fsm application

Check whther below status is updated 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality --HINDI

FSM-EDITOR All the 3 below status should be updated accordingly 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality

PASSED

FSM-EDITOR_SLA_for_Waiting_For_Dsiposal_Disposed_HINDI_06

Employee

Show vehicle trip status in employee inbox along with fsm application

Check for SLA column for below status is present as - (No value) 1. Waiting for disposal 2. Disposed --HINDI

FSM-EDITOR SLA should be displayed as - for both the status of application

PASSED

FSM-EMP_FSTPO_Waiting_For_Dsiposal_Disposed_HINDI_07

Employee

Show vehicle trip status in employee inbox along with fsm application

Check whther below status is updated 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality --HINDI

FSM-EMP_FSTPO All the 3 below status should be updated accordingly 1. Waiting for disposal 2. Disposed 3. Customer Fedback Rating-- Existing functionality

PASSED

FSM/Emp/01

Employee

Show vehicle trip status in employee inbox along with fsm application

Check for SLA column for below status is present as - (No value) 1. Waiting for disposal 2. Disposed --HINDI

FSM-EMP_FSTPO SLA should be displayed as - for both the status of application

PASSED

FSM/Emp/02

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Waiting for disposal" application status is added in filter _English

PASSED

FSM/Emp/03

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Disposed" application status is added in filter_English

PASSED

FSM/Emp/04

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Citizen Feedback Pending" application status is added in filter _English

PASSED

FSM/Emp/05

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter_English

PASSED

FSM/Emp/06

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Waiting for disposal" application status is added in filter_Hindi

PASSED

FSM/Emp/07

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Disposed" application status is added in filter_Hindi

3. atus should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/08

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate "Citizen Feedback Pending" application status is added in filter_Hindi

1. User should be able to Filter out the application on basis of "Citizen Feedback Pending" Filter. 2. User is able to show "Citizen Feedback Pending" under “Application Status” and see “-” under “SLA Days Remaining” 3.Status should also reflect on application Timeline when user click on application

PASSED

FSM/Emp/09

Employee

Show vehicle trip status in employee inbox along with fsm application

Validate Application Created, Pending DSO Assignment, Pending for Payment, Pending for DSO Approval, DSO Rejected, DSO InProgress application status is Present in filter_Hindi

PASSED

FSTPO_01

FSTPO

FSTPO Vehicle Log Inbox

Check whther "Application number for each vehicle log for each trip should be shown in the inbox"

1. Login as FSTPO 2. Click on Inbox 3. Check whther "Application number for each vehicle log for each trip should be shown in the inbox"

Application number for each vehicle log for each trip should be shown in the inbox

PASSED

FSTPO_02

FSTPO

FSTPO Vehicle Log Inbox

Check whether "Search criteria via Application umber must be made available to view all the trips taken in that application."

1. Login as FSTPO 2. Click on Inbox 3. Check whther "Search criteria via Application umber must be made available to view all the trips taken in that application."

Search criteria via Application umber must be made available to view all the trips taken in that application.

PASSED

FSTPO_FLOW_01

FSTPO

FSTPO - View error message

check whtether "FSTPO must have number of cards generated for each disposal based on the number of trips entered."

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as FSTPO and check "FSTPO must have number of cards generated for each disposal based on the number of trips entered."

FSTPO must have number of cards generated for each disposal based on the number of trips entered.

PASSED

FSTPO_FLOW_02

FSTPO

FSTPO - View error message

Check whether "User must not be allowed to enter the Trip No: (should not be user selection)"

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as FSTPO and check "User must not be allowed to enter the Trip No: (should not be user selection)."

User must not be allowed to enter the Trip No: (should not be user selection)

PASSED

FSTPO_FLOW_03

FSTPO

FSTPO - View error message

Check whether"Trip must be provided with “_of (no of trips entered by the DSO) eg: 2 of 3 in each screen each time."

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as and check whether "Trip must be provided with “_of (no of trips entered by the DSO) eg: 2 of 3 in each screen each time.."

Trip must be provided with “_of (no of trips entered by the DSO) eg: 2 of 3 in each screen each time.

PASSED

FSTPO_FLOW_04

FSTPO

FSTPO - View error message

Check whether "Take action and submit screen must be shown only after FSTP operator has entered the last screen with in and out time and the Trip number is for eg, 4 of 4 trips."

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as and check whether "Take action and submit screen must be shown only after FSTP operator has entered the last screen with in and out time and the Trip number is for eg, 4 of 4 trips..."

Take action and submit screen must be shown only after FSTP operator has entered the last screen with in and out time and the Trip number is for eg, 4 of 4 trips.

PASSED

FSTPO_FLOW_05

FSTPO

FSTPO - View error message

Check whether "After using the previous option, that option must be removed and cannot be used the next time."

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as and check whether "After using the previous option, that option must be removed and cannot be used the next time...."

After using the previous option, that option must be removed and cannot be used the next time.

PASSED

FSTPO_FLOW_06

FSTPO

FSTPO - View error message

Check whether "API Validation : the in time for the next team should not be before the out time of the previous trip."

1. Login as citizen/Creator and create the application 2. Login as Editor and update applciation 3. Login as collector and complete payment 4. Login as Editor and assign DSO 5. Login as DSO and assignvehicle with 2 or 3 trips 6. Now login as and check whether "API Validation : the in time for the next team should not be before the out time of the previous trip.."

API Validation : the in time for the next team should not be before the out time of the previous trip.

PASSED

FSM Dashboard View_01

Dashboad

FSM Dashboard View

Check whether under dashboard view user is able to see " pie chart for gender data"

1. Login as FSM Dashboard ViewER QADV/eGov@123 https://qa.digit.org/employee/user/login 2. Go to Dashboard on left hand side 3. Click on FSM 4. Validte if pie chart is available for gender data

Show pie chart for gender data

PASSED

FSM Dashboard View_02

Dashboad

FSM Dashboard View

Check if drill-down (by Date, ULB) on payment chart is available

1. Login as FSM Dashboard ViewER QADV/eGov@123 https://qa.digit.org/employee/user/login 2. Go to Dashboard on left hand side 3. Click on FSM 4. Check if drill-down (by Date, ULB) on payment chart is available

Check if drill-down (by Date, ULB) on payment chart is available

PASSED

FSM Dashboard View_03

Dashboad

FSM Dashboard View

Check above charts on mobile and desktop versions

1. Login as FSM Dashboard ViewER QADV/eGov@123 https://qa.digit.org/employee/user/login 2. Go to Dashboard on left hand side 3. Click on FSM 4. Check above graphs on mobile and desktop versions

Check above two graphs on mobile and desktop versions

PASSED

FSM Dashboard View_04

Dashboad

FSM Dashboard View

Check if chart should be shareable and downloadable

1. Login as FSM Dashboard ViewER QADV/eGov@123 https://qa.digit.org/employee/user/login 2. Go to Dashboard on left hand side 3. Click on FSM 4. check if chart should be shareable and downloadable

check if chart should be shareable and downloadable

PASSED

v1.4

Introducing Water-Sanitation

About Water-Sanitation

Useful Links

Contact Us

Water-Sanitation

Solution Design

Need for Water-Sanitation

Scope

Approach

Overview of Faecal Sludge Management

Why FSM matters - It is the way forward in sanitation

Systems Map

Part 1 - Toilets and containment units

Problems faced by key stakeholders

Part 2 - Emptying and transport

Problems faced by key stakeholders

Part 3 - Treatment

Part 4 - Ecosystem

Critical Problems in FSSM

Absence of well-defined standards for sanitation

Broken chain of custody from waste generation to reuse

Lack of verifiable, trusted data at various levels

Inability to convert waste to value

Release Notes

Release Summary

New ‌Feature Additions

Enhancements

Document Resources & Links

Test Cases

QA Test Cases for PQM:

QA Test Cases for Sanitation Worker Welfare:

Localisation

Impel Release Notes

Release Summary

Release Highlights

New Feature Additions

Document Resources and Link

Master Migration Document

Overview

Migration Steps

PQM Service

PQM Scheduler

PQM Anomaly Finder Service

Sanitation Worker Welfare

UI Migration Changes

Driver-Individual Migration Script

Overview

Build

API Spec

MDMS Roleaction Mapping

Water-Sanitation Product Suite

Waste Management System

TQM UI

How to Enable TQM UI

Overview

Enabling Module from MDMS

Enabling TQM Module from UI

Roles Required to Access TQM UI

Recommended Core UI module version

UI: Plant Operator

The screens/flows for a plant operator are given below:

Landing and Home Page

Landing Page

Home Page

Plant-User Mapping

Plant-User Mapping Flow

How a Plant's Dropdown is Populated

Help Section

Help Flow

UI: ULB Admin

The following screens/flows are available for an urban local body (ULB) admin:

ULB Admin Home Page

Home Page

API Details for TQM

View Past Test Results

Create Adhoc Test

Create Adhoc Test Flow

API Details for Create:

Sample curl for inbox:

Data Model

Data Model