Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Learn more about PT workflows and its configuration
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
DIGIT Infra and architecture details
DIGIT is India’s largest open-source platform for Urban Governance. It is built on OpenAPI (OAS 2.0) and provides API based access to a variety of urban/municipal services enabling state governments and city administrators to provide citizen services with relevant new services and also integrating the existing system into the platform and run seamlessly on any commercial/on-prem cloud infrastructure with scale and speed.
DIGIT is a microservices-based platform that is built to scale. Microservices are small, autonomous and developer-friendly services that work together.
A big software or system can be broken down into multiple small components or services. These components can be designed, developed & deployed independently without compromising the integrity of the application.
Parallelism in development: Microservices architectures are mainly business-centric.
MicroServices have smart endpoints that process info and apply logic. They receive requests, process them, and generate a response accordingly.
Decentralized control between teams, so that its developers strive to produce useful tools that can then be used by others to solve the same problems.
MicroServices architecture allows its neighbouring services to function while it bows out of service. This architecture also scales to cater to its clients’ sudden spike in demand.
MicroService is ideal for evolutionary systems where it is difficult to anticipate the types of devices that may be accessing our application.
DIGIT follows Multilayer or n-tiered distributed architecture pattern. As seen in the illustration above there are different horizontal layers with some set of components eg. Data Access Layer, Infra Services, Business Services, different modules layers, client Apps and some vertical adapters. Every layer consists of a set of microservices. Each layer of the layered architecture pattern has a specific role and responsibility within the application.
Layered architecture increases flexibility, maintainability, and scalability
Multiple applications can reuse the components
Parallelism
Different components of the application can be independently deployed, maintained, and updated, on different time schedules
Layered architecture also makes it possible to configure different levels of security to different components
Layered architecture also helps users test the components independent of each other
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
WhatsApp channel v2 release details
This release leverages the capabilities of WhatsApp as an additional channel for citizens to access/ pay bills for revenue modules like property tax and water/sewerage. With the improved user experience in terms of messaging and overall application flow, WhatsApp (V2) aims to strengthen the ease of service access for citizens at the last mile.
Improvements in Public Grievance Redressal Module
Enhancements in messaging language.
NLP Inclusion (For City & Boundary Selection).
Improvements in Bill Payments
Enhancements in messaging language.
Inclusion of call to action buttons (for certain messages).
For Linked Mobile Numbers
Single-click access to bills (for PT and W&S)
For Non-Linked Mobile Numbers
Provision of Search & Pay (If Property/Connection Details are known).
Inclusion of Open Search Links (If Property/ Connection Details are unknown).
Improvements in Payment History
Enhancements in messaging language and flow.
Inclusion of call to action buttons (for certain messages).
For Linked Mobile Numbers
Access to view the last three payments made (for PT & W&S)
Provision to download the last three payment receipts
For Non-Linked Mobile Numbers
Access control to view payments history only.
Key Feature
Description
Call to action (CTA) Buttons
Call to action buttons (CTA) is an interactive message template that aims to provide an improved conversational experience. For WhatsApp V2, certain endpoints have called to action buttons included.
Instead of citizens typing for a reply, CTA buttons allow citizens to select the option and perform action instantly. The CTAs are applicable to the following scenarios :
Pay Bills.
Return to Main Menu.
View Payment Receipts.
Provision For Search & Pay Bills.
(Non-Linked Mobile Numbers)
As part of the WhatsApp V2, citizens :
whose mobile numbers are not linked with DIGIT.
are aware of the account details (PT ID/ Connection No).
can now search and pay the outstanding bills.
This feature encourages citizens to have access to outstanding bills on DIGIT even if the mobile number is not registered on the platform.
Inclusion of Open Search Links
As part of the WhatsApp V2, citizens :
whose mobile numbers are not linked with DIGIT
not aware of the account details (PT ID/ Connection No)
can now use the open search and pay the outstanding bills.
The open search allows citizens to fetch outstanding bills using other parameters (like door no/ name etc). In this case, the citizens will be redirected to the open search webpage and all the further interactions are exclusive of WhatsApp Chatbot.
This feature encourages citizens to have an access gateway to pay outstanding bills even when the required details are unknown.
View Payment History
View Payment History feature allows citizens to view the last three payments made for revenue service.
Further, in order to comply with data privacy :
Only linked mobile numbers are allowed to download the past payment receipts.
Non-Linked Mobile numbers cannot access the receipts and only have provision to view payments history.
NLP Inclusion
As part of the WhatsApp V2, citizens can now type and submit the :
City Name
Locality Details
while filing a complaint on PGR.
This feature is a major enhancement to the older version as now citizens don't have to be redirected outside the chatbot to select details.
Instead, citizens can now type and submit the information. Even when the information entered is incorrect, the NLP engine provides a suggestion for citizens to make corrections and proceed.
As an external independent environment, WhatsApp has the following limitations (applicable for current and future initiatives) :
Limitation
Description
Access Control On Template Messages
Only messages that are approved by WhatsApp can be part of the chatbot.
Post-approval only, internal development/ configuration can take place.
No Alteration/External Development Allowed.
WhatsApp does not allow the alteration such as chat inbox or message pad.
Access control over the User Experience
We cannot control UX Aspects such as :
Messaging Alignment (Auto-adjusted by WhatsApp as per Device).
Resolution Adjustment (Image & Multimedia Files).
Font Size & Style.
Message Character Length.
Message Delivery Speed (Not Fully)
Message Ordering
Water & Sewerage Open Search Infographic (For New UI).
Integrate common pay new UI.
DIGIT Platform Enhancements
Update a non linked mobile number as an alternate number (post payments).
Access control on payment recipients (owner vs others).
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Key themes and deliverables
Commitment and transparency are deeply ingrained values defining our product development approach. We are constantly developing new capabilities to facilitate the digital transformation of our cities. Take a glimpse into our DIGIT Roadmap to learn more about our upcoming tools and features.
Theme
Description
Widen Urban Mission Impact
Product feature enhancements and concentrated focus on increasing adoption
Champion Societal Missions
New products to address the sanitation issues facing urban areas and public finance management solutions
Promote Usability and Accessibility
Create integrated user experience with a key focus on flexibility, accessibility, quality of service; Optimized user experience
Enhance Platform Capabilities
Adopt improvements on the platforms that will address some key issues like privacy, security as well as adding new capabilities like GIS
Drive Product Research and Innovation
Identify high-impact research and product innovation areas through validation, understanding the domain, and processes involved
Property Tax -
Simplified Push Payments BBPS, demand base system - Internalize BBPS integration in the product and enable out of box implementation to increase citizen-led payment
Implementing registry principles in PT - Identify and plug the gaps in the current PT registry
Data uploader using excel files - User interface to allow the upload of legacy data excel files to upload legacy data in the product
Public Grievances & Redressal (PGR) -
Multi-selection of complaints & bulk action - Employees can select multiple complaints and perform actions (like allocation) in a couple of steps
mCollect -
Collection extension for other services like PT, TL - Enable collection of the core taxes through the mCollect interface
FSM -
Whatsapp POC - WhatsApp as a channel for citizens to request desludging
OCR POC - Use Optical character recognition to get test result info by taking a photograph instead of manually entering the figures
Scheduling - Manage schedule for the desludging vehicles on a daily basis
Standardization and Simplification -
Standardization of Master Data, Configurations, Taxonomies for ease of deployment
Knowledge assets, Tools, Documentation -
Self-help demo setup - product videos to assist users with key module workflows
Product Training material - help links and how-to articles
Property Tax -
Capital rules-based assessments supporting the product
Amalgamation of property / Bifurcation of property - feature enhancement to manage amalgamation or division of a property use cases
PGR -
Third-party integration with national or local initiatives - Expand capabilities to allow complaints lodged via National Initiatives (Like Swachta) to be routed to DIGIT's PGR for action
mCollect -
POS integration - Out of box app to integrate with POS machines on the field
Finance -
TP collection reconciliation - Third-party collection reconciliation framework
FSM -
Vehicle tracking - Track the desludging vehicles that are servicing the requests from citizens
Integration with IoT devices - Integrating IoT devices to track performance and assess standards at FSTP plant
FSTP performance tracking - Building capability for the treatment operators to track the performance of various treatment plants
Adoption -
Rollout dashboards
Automating infra uptime and tracking incidences via a dashboard
Bots - CSV to system data transfer
Bots - email id
National dashboard - POC
Mobile app
Findability/access to multiple channels -
Product packaging
Release Date: 01/03/2022
Beta date:
GA date:
Property Tax -
Explore PT integration with other departments like stamps and registration - the key objective is to increase the coverage of the property tax base of the ULB and also identify the revenue leakage points in the ULB
FSM -
Abstraction to business models - Abstracting the core components of various business models across containment/transport/treatment/reuse so that any state can use the platform
Marketplace - Having a marketplace model that connects desludging operators with citizens and manages the entire logistics chain
Open dashboards/data (for researchers) - Creating a one-stop solution for accessing key data points in the FSM space
Adoption and Enhancements -
BBPS integration - BBPs has multiple modes of payment - cash, transfer cheques, and electronic modes
Offline to online driven adoption (QR codes, redesign of receipts, etc) - critical in providing awareness of onboarding on the digital medium and a key catalyst for boosting online adoption
Pair with Whatsapp portal - Provide an alternative channel for the citizen to avail services, eliminating the dependency on other traditional channels
IVRS integration - Interactive Voice Response, a phone call based channel for availing services like Grievance Redressal
CSC integration - Inclusion of CSC/ Sewa Kendras as a channel for providing DIGIT services to Citizens
This is an enhancement in the workflow service where applications can get auto escalated to a designated role on breach of an SLA
Configure SLA at a workflow state level
Escalate the application to a role if there is a breach in SLA
Make the application status as deemed approved or reject on breach of an SLA
Escalate the application to the next logical step in the workflow ladder if there is a breach in SLA
One UX issue which will go out in the next patch release
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
Key Feature
Description
Configure SLA at a workflow state level
In the earlier versions, the SLA can be configured only at the business service level. Now it has been enhanced in a way that either the SLA can be configured at a business service level for a business service or it can be configured at each workflow state in the business service.
If a business service has 3 workflow states A-B-C , now there can be an SLA definition for application movement from A to B and one a separate definition for movement from B-C
Escalate the application to a role if there is a breach in SLA
Either if the SLA breach is at the business service level or at the workflow state level, the application can be configured to move the application from an existing state to a role.
For Example: If the config is in breach of SLA move the application to the Field inspector role, then the application will be moved automatically to the role field inspector when the SLA timeline is reached.
Make the application status as deemed approved or reject on breach of an SLA
On breach of an SLA either at the business service level or at the workflow state level, it can be configured to make the application deemed approved or rejected.
Deemed reject will come in use cases where citizen fails to take any action
Deemed approval will come in use cases where employees fail to take action within the stipulated SLA
Escalate the application to the next logical step in the workflow ladder if there is a breach in SLA
On breach of SLA in a workflow state, it can be configured to move the application to the next logical stage in the workflow ladder.
For example: if the flow of the application is from A-B-C, now in step B if there is a breach in SLA, automatically the application will be moved to step C.
Doc Links
Description
eDCR Service 2.0.0 is a baselined release that has got few enhancements to the existing features.
eDCR 2.0.0: The above feature is useful and required in other states.
Impact: Functionally, the upgrade to eDCR 2.0.0 will not impact the existing environments.
All content on this page by is licensed under a .
S.No.
Feature
Description
1.
River Distance
Enhanced the river distances and the colour code used to identify river type.
2.
Basement
In the basement footprint layer, captured additional dimension with colour code 3 to define the level of the basement under the ground.
3.
Stilt floor
In the stilt parking layer, capturing height from floor to the bottom of the beam of the stilt floor.
Explore DIGIT platform
Server Maintenance scheduled from 7th Feb 2022 10 AM to 14th Feb 2022 10 AM. The Demo Instance is temporarily unavailable due to system upgrades & maintenance.
Access DIGIT tool is an Open Demo Instance to provide you with a first-hand experience of the DIGIT platform. Use this facility to navigate all the features & workflows of DIGIT Platform Applications.
We have added user assistance docs below to help you learn more about DIGIT modules and the use-case scenarios supported by each.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Changes in Bill Amendment application to ensure ease of process for the user.
Changes in Bill Amendment screen to display current Demand
Key Feature
Description
Changes in Bill Amendment screen to display current Demand
The changes in the application screen are as below
Add a new column in the amount adjustment screen - "Current Demand" along with Reduced Amount and Additional Amount.
The New column would display the current demand (Latest) against each of the Tax Heads.
The Summary Screen which is shown after the Submission would also display this column info.
Doc Links
Description
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
New release features, enhancements, and fixes
DIGIT 2.5 is a release that has got new modules, a few functional changes, and non-functional changes.
Functional: Property Tax Citizen Open search flow UI/UX revamp, Property Tax Employee flow UI/UX revamp, Property Tax Mutation flow UI/UX revamp, HRMS UI/UX revamp, mCollect v2 (eChallan) UI/UX revamp, Trade License Citizen & Employee UI/UX revamp, Receipt Cancellation UI/UX Revamp, WhatsApp v2 (Pay and Enhanced PGR), Workflow Auto Escalation with reference implementations in PGR, W&S Enhancements, FSM DSS, and Standardized Reports for FSM/PT/mCollect.
Non-functional: QA Automaton of APIs for FSM & eChallan, Product Standard Ontologies, Technical improvements, Internal Data Mart, etc.
Feature
Description
1
Property Tax UI/UX Revamp
Citizen flow
Open Search and Payment
Employee flow
Employee Inbox
Create Property
Search Property
Transfer of Ownership
Update Property
Property Assessment
2
HRMS UI/UX Revamp
Create employee
Search employee
Edit Employee
Deactivate/re-activate employee
3
Trade License UX revamp
Allow citizen to create Trade License application
Allow citizen to check application status and make payment, download artefacts
Allow Employee to create Trade License application on behalf of citizen
Application processing by employees
Allow citizen to renew the existing trade licenses which are due for renewal
Allow employee to renew the existing trade license which are due for renewal
4
mCollect v2 (eChallan) UI/UX Revamp
Challan Generation
Challan Search Employee
Total Challan Count
My Challan - Citizen
Search and Pay - Citizen
5
Receipt Cancellation UI/UX Revamp
Receipt Cancellation UI/UX Revamp
6
FSM DSS
SLA Compliance
Average Collections
Performance by ULB and Districts
Performance by Desludging Operator
Plant Operating Efficiency
Drill downs for Desluding and Vehicle log report
7
Workflow Auto Escalation
Configure SLA at a workflow state level
Escalate the application to a role if there is a breach in SLA
Make the application status as deemed approved or reject on breach of an SLA
Escalate the application to the next logical step in the workflow ladder if there is a breach in SLA
8
Product Standardized Reports
FSM
Daily Collection Report
Desludging Request Report
Vehicle Log Report
PT
Defaulter Report
Collection Register Report
Receipt Register Report
mCollect
Challan Register Report
Daily Collection Report
Receipt Register Report
Updated Feature
Description
1
Water & Sewerage Enhancements
Bill Cancellation of latest bill
Show Due Date in Arrears breakup
Water & Sewerage Combined PDF Changes
Water & Sewerage Due Validation on PT Title Transfer
2
WhatsApp v2 (Pay and PGR) Enhancements
Improvements in Public Grievance Redressal Module
Enhancements in messaging language.
NLP Inclusion (For City & Boundary Selection).
Improvements in Bill Payments
Enhancements in messaging language.
Inclusion of call to action buttons (for certain messages).
For Linked Mobile Numbers
Single-click access to bills (for PT and W&S)
For Non-Linked Mobile Numbers
Provision of Search & Pay (If Property/Connection Details are known).
Inclusion of Open Search Links (If Property/ Connection Details are unknown).
Improvements in Payment History
Enhancements in messaging language and flow.
Inclusion of call to action buttons (for certain messages).
For Linked Mobile Numbers
Access to view the last three payments made (for PT & W&S)
Provision to download the last three payment receipts
For Non-Linked Mobile Numbers
Access control to view payments history only.
3
Bill Amendment Enhancement
Additional changes in Bill Amendment screen to display current Demand
4
PT Enhancements
PT Enhancements - Fuzzy search for Name, Door number, and old PT ID (old UI)
5
QA Automaton of APIs
APIs automation for
eChallan APIs including end to end APIs automation
Bill Amendment APIs
FSM Inbox API
6
Other Improvements and Tech Enhancements
Changes in Gender to introduce Transgender and Others.
Standardization of Product ontologies for Property Tax, Water & Sewerage, Fire NOC, mCollect (eChallan), PGR, and Online Building Plan Approval.
Inbox API to support module wise inbox for UI/UX revamp.
7
Internal Data mart
Internal Data mart for PT, TL, PGR, W&S, FSM, eChallan, OBPS, and Fire NOC modules.
8
eDCR Enhancements
River Distance: Colour code used to identify different river types.
In the basement footprint layer, captured additional dimension to define the level of the basement under the ground.
In the stilt parking layer, captured height from floor to the bottom of a beam of the stilt floor.
Trade License UI/UX Revamp
Citizen
Employee
HRMS UI/UX Revamp
Receipt cancellation UI/UX Revamp
Bill Cancellation
mCollect v2 (eChallan) UI/UX Revamp
Workflow Auto Escalation
Property Tax UI/UX Revamp
Citizen
Employee
Mutation
DSS
This release aims at the UI/UX Revamp of the existing HRMS module primarily, with certain minor enhancements incorporated functionally.
Employee summary card (post-login).
UI Enhancements for
Create new Employee
Search employee screen.
Usability enhancements
Inclusion of various filters
View of roles assigned in terms of count (post search)
Key Feature
Description
Employee Summary Card
(Post Login)
Once, State/ ULB Administrator has logged in to the master portal, they will land on the homepage consisting of the HRMS card.
This card provides an overall summary on:
The Total Employees Created (Total Employees in the Database).
The Total Employees that are active (at this time).
Along with the above, the admin has the following options :
Search Employee.
Create Employee
Employee Search
The UI of employee search has been upgraded with search now possible by using the following filters :
By ULB (Useful when an employee is operating jurisdictions)
By Designation
By Role (This filter is Multi-Select)
By Employment Status (Active/ Inactive).
The following search displays the following fields :
Employee ID
Name
No of Roles (Describes the no of roles assigned).
Designation
Department
Employment Status
The case sensitive search
Reports UI Revamp.
Onground implication for multiple assignment dates and propose the product changes.
Enhance the text for Exception Handling.
Inclusion of Privacy Bit.
The Digital Governance Platform
DIGIT Urban Stack is a set of Open APIs, services, and reference implementations, set up as a public good, to allow government entities, businesses, startups, and civil society to use a unique digital Infrastructure and build solutions for urban India at a large scale. It provides a set of open standards, specifications and documentation to create a level playing field and enable ecosystem players to innovate on the stack. As a public good, the platform is provided without profit or restriction to all members of society.
Open Source - DIGIT is Open Source and has been built using the best in class Open Source technology stacks powering the most advanced companies in the world. DIGIT is able to provide the lowest total cost of ownership and helps ensure that governments retain strategic control of their systems and data.
Mobile-Enabled - DIGIT has adopted a mobile-first approach, with robust mobile applications enabling citizens to easily access government services through their phones. Government officials and field workers are also empowered with mobile applications that enable them to deliver 24×7 governance with ease.
Real-time Dashboards - DIGIT’s real-time dashboards provide governments with actionable insights on demand. Administrators and department heads are empowered with verified data that enables them to manage their work and budgets better. Field level employee reports enable effective performance management and ensure efficient usage of government resources.
DIGIT focuses on inclusion and is designed on the principle of enhancing both platform openness and choice for citizens. The platform uses open APIs and standards, creating a powerful framework to drive convergence across the multiple systems currently in use and to lower the barrier to entry for locally-developed solutions. Keeping in mind that most Indians use the internet through their phones, we follow and advocate a “mobile-first” approach, while supporting multi-channel access to accommodate diverse needs and preferences.
.
.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
or for more details.
All content on this page by is licensed under a .
This release is for the FSM decision support system used by the ULB administrators and the day to day reports used by the officials.
FSM DSS
Daily collection register
Vehicle log report
Desludging request report
Key Feature
Description
FSM DSS
This decision support system will provide a comprehensive view for a state administrator to know the SLA compliance, average collections, performance by district and ULB, performance by the desludging operator, plan operational efficiency etc…
Daily Collection register
This report will help the head cashier and collection operator to know the daily collection instrument type wise and reconcile the physical collection at the end of the day.
Vehicle log report
This report details the volume of septage that is transported by a vehicle or operator for a date range.
Desludging request report
This is a detailed report which provides the life cycle of a desludging transaction, starting from application creation to septage being dumped at the plant
Doc Links
Description
This release is for the trade license UX revamp. There is no change in the existing functionality but the entire module moved to the new DIGIT UX
This release has the following features
Allow citizens to create trade license application
Allow citizens to check application status and make payment, download artefacts
Allow Employee to create trade license application on behalf of citizen
Application processing by employees
Allow citizens to renew the existing trade licenses which are due for renewal
Allow employees to renew the existing trade license which is due for renewal
Key Feature
Description
Allow citizens to create trade license application
This feature allows the citizen to register a trade license application online.
Allow citizens to check application status and make payment, download artefacts
This feature allows citizens to check the status of the application that was created online, respond to comments or clarifications raised by the employees, make the payment if there is an amount due and download trade license certificate and payment receipt online.
Allow Employee to create trade license application on behalf of citizen
This feature allows employees to create a trade license application on behalf of the citizen over the ULB counter and provide application acknowledgement for the applicant.
Application processing by employees
The application either created by the citizen online or by the employee over the counter can be processed for document verification, field inspection and approval.
In the process, the application can be sent back to the citizen for clarification, send back to the officer in the workflow approval for queries. The application can also be rejected with reasons.
Allow citizens to renew the existing trade licenses which are due for renewal
Citizens can apply for license renewal online, in the process if there are some changes made to the trade that can be updated in the application. If the trade details are modified during renewal then the application is considered as a new application and goes for processing at the employee side for doc verification and field inspection.
If it is not modified then it can be renewed right away after making payment.
Allow employees to renew the existing trade license which is due for renewal
Similar to the TLcreate , renewal also can be done by the employee on behalf of the citizen.
Doc Links
Description
Configuration changes and service build details
Feature
Service Name
Changes
Description
Common
Digit 2.5 common changes
Digit Employee Inbox
Employee navigation to Digit UI
Role Action
FSM inbox correction
Updated role action mapping
Property Tax
Updated documents for PT create and mutation flow
Auto Escalation
Auto Escalation specific changes
FSM-DSS
Added districtTenantCode for each city
Added fsm & ulb-fsm in uiCommonConstants
Product Ontology
Product Ontology Changes
NLP chatbot
NLP chatbot specific changes
Module
Action
PR
Description
Common
Digit 2.5 common changes
Indentation correction for Indexer
FSM-DSS and FSM Reports
Updated Mater Dashboard config for FSM DSS
Added FSM DSS configurations
Updated Chart Api changes for fsm dss
Inbox API
Added Inbox searcher config for TL
Updated searcher config for sorting application
Added config for count TL search,
Provided custom sorting for PT inbox
PT Reports
Removed duplicate records for PT reports
Corrected duplicate owner issue
Changes for localization for Receipt Cancellation
Changes for mcollect challan for Hindi localization
Feature
Feature
Description
Common
Digit 2.5 common changes
Corrected the indentation for Inbox
State level tenant ID for workflow v2
Open Payment (PT & WS)
Added mixed end point for PT and WS
TL Searcher
Added searcher for Inbox TL
nlp-engine
Added NLP specific changes
turn-io-adapter
Changes for turn-IO adapter
Category
Services
GIT TAGS
Docker Artifact ID
Remarks
Citizen
citizen:v1.6.0-f2e14587d-616
Employee
employee:v1.6.0-f2e14587d-618
DSS Dashboard
dss-dashboard:v1.6.0-520453001-21
DIGIT UI
digit-ui:v1.3.0-e03ec9d-664
Encryption
egov-enc-service:v1.1.1-19a3ba19-5
No changes in the current release.
xState Chatbot
xstate-chatbot:v1.0.2-196178f4-190
Searcher
egov-searcher:v1.1.4-196178f4-7
Payment Gateway
egov-pg-service:v1.2.2-2ee9ec37-17
No changes in the current release.
Filestore
egov-filestore:v1.2.3-2ee9ec37-4
No changes in the current release.
Zuul - API Gateway
zuul:v1.3.0-667cb3d3-8
No changes in the current release.
Mail Notification
egov-notification-mail:v1.1.1-19a3ba19-5
No changes in the current release.
SMS Notification
egov-notification-sms:v1.1.2-2ee9ec37-3
No changes in the current release.
Localization
egov-localization:v1.1.2-4517fb39-3
No changes in the current release.
Persist
egov-persister:v1.1.3-2ee9ec37-2
No changes in the current release.
ID Gen
egov-idgen:v1.2.2-2ee9ec37-3
No changes in the current release.
User
egov-user:v1.2.5-196178f4-28
User Chatbot
egov-user-chatbot:v1.2.1-4976757
No changes in the current release.
MDMS
egov-mdms-service:v1.3.1-2ee9ec37-3
No changes in the current release.
URL Shortening
egov-url-shortening:v1.1.0-19a3ba19-1
No changes in the current release.
Indexer
egov-indexer:v1.1.5-196178f4-9
Report
report:v1.3.3-c1315264-15
Workflow
egov-workflow-v2:v1.2.0-f8601b36-49
PDF Generator
pdf-service:v1.1.4-a4e9bb2c-16
No changes in the current release.
Chatbot
chatbot:v1.1.5-196178f4-9
Deprecated.
Access Control
egov-accesscontrol:v1.1.2-2ee9ec37-1
No changes in the current release.
Location
egov-location:v1.1.3-2ee9ec37-1
No changes in the current release.
OTP
egov-otp:v1.2.1-07a30430-2
No changes in the current release.
User OTP
user-otp:v1.1.3-2ee9ec37-6
No changes in the current release.
NLP Engine
nlp-engine:v1.0.0-fbea6fba-21
New Service
Apportion
egov-apportion-service:v1.1.4-ec514d1-12
No changes in the current release.
Collection
collection-services:v1.1.5-33d01f1-38
Billing
billing-service:v1.3.3-581d2eb-54
HRMS
egov-hrms:v1.2.3-464d95d-17
Dashboard Analytics
dashboard-analytics:v1.1.5-33d01f1-20
Dashboard Ingest
dashboard-ingest:v1.1.3-6cb5d67-5
No changes in the current release.
EGF Instrument
egf-instrument:v1.1.3-b5944f0-1
No changes in the current release.
EGF Master
egf-master:v1.1.2-b5944f0-2
No changes in the current release.
Finance Collection Voucher Consumer
finance-collections-voucher-consumer:v1.1.5-cb9776c-11
Trade License
tl-services:v1.1.5-d3163d602-29
Trade License Calculator
tl-calculator:v1.1.3-0b2efd7f-3
No changes in the current release.
Fire NOC
firenoc-services:v1.3.1-e3052c649-28
Fire NOC Calculator
firenoc-calculator:v1.2.0-a8da9ece-3
No changes in the current release.
Property Services
property-services:v1.1.6-dea64712f-117
Property Tax Calculator
pt-calculator-v2:v1.1.4-ef94c644-20
No changes in the current release.
Property Tax
pt-services-v2:v1.0.0-ecf3410a
Deprecated. No changes in the current release.
Water Charges
ws-services:v1.4.1-e3052c649-26
Water Charges Calculator
ws-calculator:v1.3.1-a8da9ece-41
No changes in the current release.
Sewerage Charges
sw-services:v1.4.1-e3052c649-22
Sewerage Charges Calculator
sw-calculator:v1.3.1-a8da9ece-32
No changes in the current release.
BPA Calculator
bpa-calculator:v1.1.0-4ee62c15-1
No changes in the current release.
BPA Services
bpa-services:v1.1.4-ebe6a2b30-20
User Event
egov-user-event:v1.1.3-a8da9ece-3
No changes in the current release.
PGR
rainmaker-pgr:v1.1.4-39d6a23fb-20
v1 - Deprecated.
PGR Service
pgr-services:v1.1.3-e3052c649-13
v2
Land Services
land-services:v1.0.3-e3052c649-6
NOC Services
noc-services:v1.0.3-d89ad8118-11
FSM
fsm:v1.0.3-e3052c649-62
FSM Calculator
fsm-calculator:v1.0.0-39678039-14
No changes in the current release.
Vehicle
vehicle:v1.0.2-e3052c649-25
Vendor
vendor:v1.0.2-e3052c649-23
eChallan Services
echallan-services:v1.0.3-fe3e42537-25
eChallan Calculator
echallan-calculator:v1.0.1-e3052c649-7
Inbox
inbox:v1.0.0-dd430b7a8-28
New Service
Turn-IO
turn-io-adapter:v1.0.0-e3052c649-33
New Service
Custom Consumer
egov-custom-consumer:v1.1.0-7a6db73
No changes in the current release.
egov-pdf:v1.1.1-caf76f9-17
Others Service
eDCR
egov-edcr:v2.0.0-baa4485-19
Finance
egov-finance:v3.0.2-0d0a8db8ff-28
For traders to do business in India, ease in redundant procedures and regulatory processes is of paramount importance. DIGIT-Trade License increases procedural efficiency, improves access to license information, and provides transparency thus enabling the business to flourish and function with ease.
This release for the Water and Sewerage module consists of a major feature and few enhancements for the urban local body employee to handle the ground operations seamlessly.
Dues validation on Property Transfer
Combined PDFs for Water and Sewerage Services
Arrears breakup and due date on the bill
Bill Cancelation
Handling combined PDFs batch-wise, for more than 50 connections
Property details on the bill
Current bill cancellation completeness for non-metered and sewerage connections
Role-based control for dues collection on property transfer
This section contains DIGIT product and module related documents
DIGIT offers several modules. Each module is designed to automate the manual workflows for various governance units.
DIGIT enables ULBs to be more effective and accountable—and to make better, data-driven decisions. The platform ensures both interoperability among ULBs and rapid development of new modules by a wide array of software partners.
Click on the respective link below to learn more about that product, its features, applications and configuration details.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
,
, , , , ,
,
, ,
, ,
, ,
, , , ,
, , , , , , , ,
,
, ,
, ,
,
Frontend
Digit-UI Digit-UI-Internals
Core Services
Business Services
Municipal Services
Utilities Services
Configs
MDMS
Localization
QA Automation
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
mCollect
echallan-services/eChallan/v1/_create
echallan-services/eChallan/v1/_update
echallan-services/eChallan/v1/_search
collection-services/payments/_create
echallan-calculator/v1/_calculate
e2e mCollect (API)
Billing Service
billing-service/amendment/_create
billing-service/amendment/_update
billing-service/amendment/_search
FSM
inbox/v1/_search
TC Review comments updates
e2e fire-noc API
e2e fsm API
Feature
Description
Dues validation on Property Transfer
If the connection holder’s W&S dues are pending, and holder information gets updated during property transfer, the ULB staff will have a lot of difficulties getting a hold of the previous holder (or property owner in this case) to recover the due amount. With this feature, we validate for W&S dues while property transfer on property tax module and do not allow a property to be transferred if W&S dues are not cleared
Combined PDFs for Water and Sewerage Services
A municipal employee goes to distributes water and sewerage bills door-to-door. However, since the bills get generated and printed at different times, this person has to have multiple trips for bill distribution. In addition, printing bills also uses a lot of stationery for a ULB. To save multiple trips for ULB Employees, we provide a combined PDF for W&S Bills with this enhancement
Arrears breakup and due date on the bill
It is important for the citizen to know when was the penalty for bills applied from. With this feature, we are adding bill due date and amount breakup on the bill.
Current Bill Cancelation
There are various cases like mistakes, changes in the billing, etc which will require the bill to be cancelled. This feature allows the employee is to cancel the bill for Water (metered and non-metered) and Sewerage connection and generate a newly updated bill
Module roadmap
Details coming soon..
Learn more about TL workflows and its configuration
Details coming soon..
Title
Link
QA Automation Release Notes 2.4
Manual Test Cases - API Services
Manual Test Cases - e2e integration
Automation Source Code
Automation Readme
Kafka Approach Document
Sample Config File (for passing to execution command)
This page provides configuration details for TL master data templates
The DIGIT-Trade License application makes the process of obtaining a Trade License easy, smooth, and transparent. The module, hence, removes the need for manual processing and streamlines the key trade license management functions to provide a better user experience.
DIGIT Trade License module enables citizens to -
Apply for a new trade license or renew an existing trade license.
Upload all the relevant documents required for the license.
Make payment for the Trade License (New/Renewal) fee using the online payment gateway.
Receive notifications and alerts by emails or SMS for new application status updates and pending renewals.
Download Trade License, Payment & Acknowledgement Receipts online.
DIGIT Trade License module enables employees to -
Create flexible role-based workflows.
Configure license fees calculation logic.
View custom dashboards for module statistics.
Filter search results using advanced configurable search parameters.
Receipt Register
Application Status
Cancelled Receipt Register
ULBwise Collection Report
ULBwise Application Status
Apply for trade license, ensure compliance with trade safety guidelines, and lots more
DIGIT-Trade License (TL) enables local government bodies to regulate trading establishments. It also serves to protect the interest of the public at large against possible health hazard and inconvenience that can be caused by any business operations. With DIGIT-TL traders can obtain the trade certificate in a simplified manner and ensure compliance with rules and safety guidelines issued by the government. The module offers the citizens and governance bodies a convenient and transparent means of processing trade licenses.
The Trade License application makes the process of obtaining a Trade License easy, smooth, and transparent. The module, hence, removes the need for manual processing and streamlines the key trade license management functions to provide a better user experience.
DIGIT Trade License module enables citizens to -
Apply for a new trade license or renew an existing trade license.
Upload all the relevant documents required for the license.
Make payment for the Trade License (New/Renewal) fee using the online payment gateway.
Receive notifications and alerts by emails or SMS for new application status updates and pending renewals.
Download Trade License, Payment & Acknowledgement Receipts online.
DIGIT Trade License module enables employees to -
Create flexible role-based workflows.
Configure license fees calculation logic.
View custom dashboards for module statistics.
Filter search results using advanced configurable search parameters.
This section contains all docs and information required to understand the TL module, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the TL module.
Implementation Handbook
Demo Script
Navigation Tips
Click on the embedded links within the content to browse topic details
Use the Contents links available on the right side of the screen to move to a specific heading
Find the list of Related Docs links at the bottom of each page to browse through additional product details
Reach out to us through any of the below-mentioned contact channels for any assistance or additional information on TL module deployment.
#147/J, 1st floor, 10th Cross, 12th Main, 3rd Block, Koramangala, Bangalore 560034
Functional overview for stakeholders
The Trade License product provides a digital interface, allowing citizens to apply for the Trade License and subsequently make the trade license fee payment online.
The Trade License product enables:
Ease of doing business — Traders can apply for new licenses, renewals, amendments, and supplemental licenses
Regulatory Tracking — Administrators can track and manage regulatory processes
Shorter Timelines — It streamlines and automates business licensing processes and helps a business to be set up quickly
Data-driven decision making — The application collates valuable information on the economic activity and employment opportunities in a ULB
The list below summarizes the key features supported by the TL module -
Registration, Login and Creation of User Profile
Applying for a Trade License
Trade License Issue
Modifications to a Trade License
Renewal of Trade License
Payments and Fee
Dashboards and Reports
General Features
Key capabilities offered by this functional component -
OTP Based Login for Citizen via Web/Mobile App
OTP Based Login for Employee via Web/Mobile App
Provision for language selection during first time registration for both Employee and citizens
Provision of creating a personalized Profile for Citizens and employees on Web App
Login Credentials for the various hierarchies of employees
Role-based access for performing different actions relating to Trade License modules
User can apply for a new TL from the system. User can select the type of license to apply. The user enters trade details, owner details and documents after which application can be reviewed and submitted. Similarly, a counter employee can also apply for TL on behalf of the citizen. The system has a workflow integration which enables stage-wise approval before Approval for issuing the Trade License.
Key capabilities offered by this functional component -
Citizen can Apply for a new Trade License through mobile app/ Web
Citizen/CSC can capture Trade details, Trade Units, Accessories, Owner Details, Address, purpose, Date of issuance, License number etc.
Citizen/CSC Upload Documents
Citizen/CSC can calculate Breakup Based on Selected Trade
Citizen/CSC can select Multiple Accessories for the Trade
Citizen/CSC can Apply for Multiple Trade Licenses
Citizen/CSC can Download/Print Application Summary
Citizen/CSC can Download/Print Trade Reference No
Citizen/CSC can View the applied licenses
The system has the facility to deliver the service online & through SEWA KENDRA.
The portal displays all the information including the processes and documents required for the convenience of the citizen.
The system has the facility to assign a unique identification number based on the license type, which will be used for all future transactions of the license.
The system has the facility to assign the application to the respective Inspector for survey and verification. After the application is submitted, it goes to the document verifier. The next step after document verification is field inspection. After the field inspector’s approval, the TL is approved by the approver.
Key capabilities offered by this functional component -
Document Verifier, Verifies & Forwards or Rejects the application
Licensing Inspector, Verifies and Forward the Application
Licensing Inspector, Sends Back or Rejects the Application
Licensing Inspectors Approves the Application
Citizen, Pays for the license post verification process online or at the CSC
CSC, Collects Fee post verification.
The system allows the printing of license and sending the license through e-mail.
The system allows the SMS alerts to the applicant regarding the date of inspection/visit by the inspector, approval/rejection of the application.
The system allows the inspector to enter the field visit details and a field visit report is generated and automatically routed to the superintendent.
The system has the facility to edit/update the Application based on the Inspection report against the application.
The system has the facility to provide a hassle-free renewal process for citizen and employee ease, leading to increased revenues, by reducing unlicensed trades. The system allows sending of SMS and Email notifications and reminders based on the renewal cycle.
Key capabilities offered by this functional component -
The citizen can pay for the license post verification process
CSC, Collects Fee post verification.
The system allows intimating the applicant about the payment of the license fee through SMS/ e-Mail.
The system allows the Generation of receipt for the payment
The payment modes enabled are Card(offline), cash, cheque, DD
Following reports offered by the module -
Cancelled Receipt Register Report
TL Collection
TL Application Status- showing the number of licenses approved/rejected.
TL ULB Wise Status
State Dashboard: View Reports for Total Licenses, Licenses Issued, Payment Collected, Payment Distribution
Notifications - The system has the capability to send notifications to citizens. These notifications can be sent for various steps like - verification completion, payment reminder, payment confirmation. These notifications can be sent in the language chosen by the ULB through all channels - SMS, Whatsapp, Email.
Configurable Masters - The system provides the following masters that can be configured as per the State’s requirements:
Charges & Calculation : Calculation Engine, Rebate, Penalty,
Rate Master
State Masters: Trade Ontology, Documents List, Accessories, Ownership, Employee Data Mapping, Boundary Data Mapping, Fee Matrix (License Fees)
System specification in compliance with the Ease of Doing Business (EODB) BRAP 2019
Reform No.
Reform Area
Weightage (score)
Recommendation
Remarks
80
Sector Specific
2
Implement an online application system with the following features:
i. Online submission of application without the need to submit physical copy of application
ii. Eliminate physical touchpoint for document submission
iii. Allow option of online payment of application fee
iv. Allow applicant to track status of application online
v. Applicant can download the final certificate online
Already available in the system
Registration, Login, Creation of User Profile
Provision for Language Selection during first-time registration via Mobile/ Web App.
OTP Based Login for Citizen/ Employee via Mobile/ Web App
Login Credentials for the various hierarchy of employees
Provision of Personalized Profile for Citizen/ Employee on Web App
Applying for a Trade License
Citizen/CSC: Enters Trade Details, Trade Units, Accessories, Owner Details.
Citizen/CSC: Upload Documents
Citizen/CSC: ULB Wise Trade Selection
Citizen/CSC: Calculation Breakup Based on Selected Trade
Citizen/CSC: Multiple Accessories Field Count
Citizen/CSC: Multiple Trade License.
Citizen/CSC: Download/Print Application Summary
Citizen/CSC: Download/PRINT Trade Reference No
Citizen/CSC: View the applied licenses.
Citizen: Pays for the license post verification process.
CSC: Collects Fee post verification.
Trade Licence Issue
Document Verifier : Verify & Forward/ Reject the application
Licensing Inspector: Verify and Forward/ Send back/ Reject the Application.
Licensing Officer: Approve/ Send back the Application
Licensing Officer: Reject/ Cancel the Application
Modification to a Trade License
Edit/ Update the Application based on the Inspection report against the application.
Renewal of a Trade Licence
Renew trade license.
Payment and Fee
Configurable Workflow Rights : Edit & Payment Collection
Payments & Collection : Various Payment Modes
Dashboards and reports
Cancelled Receipt Register Report
TL Collection
TL Application Status- showing the number of licenses approved/rejected.
TL ULB Wise Status
State Dashboard: View Reports for Total Licenses, Licenses Issued, Payment Collected, Payment Distribution
General features
Notifications : SMS Notifications
Charges & Calculation : Calculation Engine
Charges & Calculation : Rebate/ Penalty- Date Based
Charges & Calculation : Ad-Hoc Rebate/ Penalty
Charges & Calculation : Exemptions Trade Type & Owner Type
Configuration masters
Configurable Workflow Rights : Edit & Payment Collection
Configurable Verification & Approval
Once the Trade Categories are defined, the next task is to -
Define Trade Types
Map Trade Category to listed Trade Types
The Trade Type can be defined as the next (2nd) level classification of Trade. There can be multiple trade types and the list may vary from one State/ULB to another.
1
TRADE_TYPE_MEDICAL
Hospital
अस्पताल
TC1
2
TRADE_TYPE_HOTEL
Hotels
होटल
TC2
The table above contains sample Trade Type data.
1
Trade Type Code
Alphanumeric
64
Yes
The Code assigned to the Trade Type. Eg: TRADE_TYPE_MEDICAL is assigned to Hospitals
3
Trade Type Name (In English)
Text
256
Yes
Name of the Trade Type in English. Eg: Goods, Services etc.
3
Trade Type Name (In Local Language)
Text
256
Yes
Name of the Trade Type in Local Language (as decided). Eg: Service is described as “सर्विस” in Hindi
4
Trade Category Code
Reference
64
Yes
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.
Select the relevant Trade Category Code from the available drop-down list of Trade Category. This will map the listed Trade Type to the corresponding Trade Category.
Enter a unique Trade Type Code to identify the type of trade.
Enter a Trade Type Name (In English).
Enter the Trade Type Name (In Local Language).
The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
The format of the Trade Type Code defined should be alphanumeric and unique
TRADE_TYPE_MEDICAL
TRADE_TYPE_HOTELS
2
Trade Type Name (in either language) should not contain any special characters
Hospital: [Allowed]
#Hospital! : [Not allowed]
Configuration Data Templateconfiguration-data-template-trade-master-3-.xlsx - 17KB
Sample Data Templatesample-configuration-data-template-trade-master-filled-3- (1).xlsx - 19KB
The computerized and automatic Trade License system offered by eGov, facilitates citizens who seek to apply for a Trade License within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. Trade License (TL) is one of the components of a smart city that ensures a check on all the trade practices and increases the ease of conducting business within the state. Keeping in mind the benefits associated with the product offered, the proposed system is about to be implemented in 500+ ULBs across the country in 15 states. (For details on product features refer to Section-2)
For the offered product, the implementation process can be divided into seven major distinctive stages. Each stage has a predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. The whole implementation lifecycle is typical of 38-42 weeks for the State, keeping in mind the entry and exit criteria defined at the beginning and end of each stage are met on time recommended.
Exhibit 1: Phases of Implementation.
Stage Zero is that of program setup and onboarding which is a pre-requisite for the initiative to kick-off and requires setup of the governance model, implementation Team and decision regarding other significant elements of the initiative like funding and procurement process. Stage One requires scoping of the initiative and decisions on the priorities for implementation by the State Implementation Team. In stage two, the State Team will work upon identifying and finding solutions to the significant gaps in the product offered with respect to the need of the State. Configuration and customization of the product offered is the primary objective of stage four. This involves working on various aspects of State-specific needs and incorporating them into the product offered. In stage five, post doing UAT and including all the necessary feedback on the product, the roll-out of the product is done at the State level (Go Live) from a couple of ULBs to pan State coverage in batches. Finally, in stage 6 sustenance and ongoing improvements are worked upon while the product is already functioning in the State. (For details on implementation plan refer to Section-3)
Implementation of Trade License (TL) requires meticulous planning and close coordination between various stakeholders at the center and State level. The success of the initiative is dependent upon many factors like strong Program governance, availability of the trained resource, financial planning, targeted Implementation Team onboarding, focus on last-mile capacity building and ensuring necessary support to Urban center. Achievement of all these factors will provide the most effective and efficient roll-out and adoption of the Trade License System in the State.
The purpose of this document is to give an overview of the Trade License System (TLS). The Trade License product provides a digital interface, allowing citizens to apply for the Trade License and subsequently make the payment online.
The Trade License product enables:
Ease of doing business — Traders can apply for new licenses, renewals, amendments, and supplemental licenses
Regulatory Tracking — Administrators can track and manage regulatory processes
Shorter Timelines — It streamlines and automates business licensing processes and helps a business to be set up quickly
Data-driven decision making — The application collates valuable information on the economic activity and employment opportunities in a ULB
The TL product features can be broadly classified as the following modules:
Registration, Login and Creation of User Profile
Applying for a Trade License
Trade License Issue
Modifications to a Trade License
Renewal of Trade License
Payments and Fee
Dashboards and Reports
General Features
This section provides an overview of the methodology for State-wide implementation of TL. The Implementation of TL is distributed across seven distinct stages. Each stage has a predefined entry & exit criteria and roles & responsibilities. This is to ensure objective monitoring and decision making for the overall success of the program. Details of each stage are defined in this section.
Note: This document is specific for States that have more than 30 ULBs
TL implementation program is expected to be completed approximately between 38- 42 weeks with the resource deployment by the State and System Integrator (SI) Team (as defined below). However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.
This is a set of initial critical activities undertaken on receiving a letter of Enrolment or MOU from the State. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator (SI) Teams, and funds.
*Details of TL cell is mentioned in section 4 of the handbook
System Integrator and state will agree on program scope, program timelines, and budgeting & resourcing.
This stage envisages the in-person interaction of crucial State officials and implementation System Integrator (SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify scope and planning strategies for phasing/ rollout, create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.
*Exploration is required to understand the Inter and Intra Departmental Jurisdictions of Local Governments with respect to Trade License.
#Details of TL cell is mentioned in section 4 of the handbook
During the Solution design stage, key State officials and members, who are subject matter experts, are expected to share State acts and policies and help interpret the same for the System Integrator (SI) Team. This stage baselines the State-specific product features in the Product Configuration report.
This stage consists of a series of developments in accordance with the detailed project plan to ensure smooth functioning of the customised product. Master Data Collection & Environment Setup will be achieved in this phase. Further monitoring and maintenance strategies are put in place.
During this stage, demonstration of the product followed by a hands-on session is conducted for the ULB officials. Necessary training of ULB officials and resources required for UAT is conducted and identified respectively. The establishment of the State support Team and required processes are initiated in this stage.
On successful Go-Live in the Pilot ULBs, and further fine tuning to stabilize the product, the solution will be rolled out to the rest of the ULBs in phases. Guidance and support from the State Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.
The final stage consists of strategies to ensure the sustenance of the product in the State. Systems are put in place to ensure the continuous tracking of data and provisions are made to improve the product if new data suggests.
This section outlines the activities involved in each stage of the implementation along with responsibility and accountability of critical stakeholders - State, eGov Team and System Integrator Team onboard.
TL Cell: TL Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from Urban Development Department etc.
Resource requirements for the TL cell required to be formed by the State
eGOv Team: eGov Team is the technical partner of the project which will provide all necessary support to the State concerning the implementation, Program Designing etc.
System Integrator (SI)Team: SI Team will be responsible for consulting, program management and the implementation of products in the ULBs in close collaboration with the TL cell, technical partner (eGov) and various other stakeholders.
Vision:
Defining the time frame to go live, the time frame to scale it pan state, the value proposition of the programme for the state and year-on-year financial targets and adoption targets
Project Plan:
A detailed plan of Program schedule/timelines, implementation phases, team structure and ongoing support and maintenance required.
System Integrator:
The Entity/Company which collates all the subsystem required for the project and integrates them to achieve the program objective
Program Charter:
Outline of implementation plan agreement with priority applications and broad timelines, program governance model, program success metrics and capacity building.
Acceptance Letter/MOU:
Formal Acceptance/Sign Off of the Client State with a clear mandate of the Program
Program Success Metrics:
Defining the parameters (which are measurable) prior to the program, on which the success of the program is to be measured on the completion of the program
Project steering committee:
The key body within the governance structure which is responsible for the business issues associated with the project that are essential in ensuring the delivery of the project outputs and the attainment of project outcomes.
Project governance:
Set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programmes and portfolios.
Scoping:
List of activities measured against time taken to complete them in accordance with the project goals
Baseline data:
Set of information that serves as a foundation to compare other data acquired afterwards
Project Kick off meeting:
Meeting with the project team and the client of the project. This meeting would follow definition of the base elements for the project and other project planning activities
Fitment Study:
GAP Study of the Existing/Required Field Process Vs Product
Data migration:
Existing Records of the functional activities need to be moved into the Database of the newly released Application
Data collection:
Required data for the roll-out of the applications, which needs to be collected from the existing functional process
Data validation approach:
This approach enables the sanctity of the Data with built-in validation by Design
Data synchronization:
The process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.
Pilot Implementation:
Any new process is tested out as pilot in one or two instances before pan implementation
Pilot ULB:
The ULB's Selected for the pilot implementation are called pilot ULB’s.
Roll out:
On successful clearance of the Pilot, the Process/Application/Services are implemented across all Offices/ULB's
Deployment:
Deployment defines the complete package of Software components set up in a particular environment
Customization:
Details of changes to be made in the Product to comply with the needed field process
Configuration:
Defining existing content such as Options and Variables based on the requirements on the ground
Product walkthrough:
Explaining the users step-by-step through a set of actions that they need to take to achieve a specific outcome
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The Code assigned to the . Eg: TC1 For Goods, TC2 for Services
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
to view module capabilities and product functional specifications.
All content on this page by is licensed under a .
Duration
4-6 weeks
Entry Criteria
Acceptance Letter/MoU by State
Exit Criteria
Finalise Trade License Program Vision
Finalise funding for the program
Define State-specific procurement process
Trade License Cell appointment (*). Consisting of:
Domain expert
Nodal officer (EO/ Commissioner/ Senior Official)
Program Head
System Integrator (SI) Team sign-up/onboarding
Duration
4-6 weeks
Entry Criteria
Program setup (Stage 0) is complete
SI Team signed-up
Key Activities
Project kick-off meeting and consultation from stakeholders
Identify & agree on high-level scope and exclusions
Identify pilot ULBs (using criteria such as business penetration, revenue generated from previous TL systems etc.)
Product Walkthroughs
Define Project Steering Committee structure and Project Governance process
Define phases of Rollout/ Deployment
Agreement on Deployment Priorities and high-level delivery timelines
Identify and study all TL process
Definition of TL as per the municipal governance of the State
State wise conceptualization of trade categories
Citizen services/channels around it
Integration with other Departmental processes (*)
Finalise Program Success Metrics for Rollout, Adoption and Governance adhering to the vision of the program
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Collection of baseline data to measure end line target for the product (revenue generated, total properties in ULBs etc.)
Circulation of baseline data collection templates to the state/SI Team
Exit Criteria
Publish the program charter
Implementation plan agreement with priority features and broad timelines
Program Governance Model
Program Success Metrics
Capacity Building
TL Cell formation and appointment (#)
Data preparation/collection kick-off from Pilot ULBs
Cloud Infrastructure procured
Project Office Space allocated
Program Branding (name, logo, tagline etc.)
Duration
4-6 weeks
Entry Criteria
Program Charter
TL cell appointment
Key Activities
Standardisation of all TL processes
Initiate policy change if needed, based on the Processes defined
Define criteria for success
Conduct Product familiarisation workshop
Initiate collection of master data from pilot ULBs
Finalise data migration/collection/sync-up approach as per requirement
Finalise data validation approach
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Dashboard design finalisation for Program Tracking
Exit Criteria
State Sign Off and Publishing of the TL processes, data template/workflows
Finalisation of Roll-out plan (in different phases)
Product Configuration Report Sign Off
Solution agreement for required State- specific product customisations
Program tracking mechanism finalization and sign off by the state
Initial reporting structure
Dashboard KPIs
Sign-off on data approach (Data collection/migration/correction/ sync-up/validation)
Detailed project plan
Duration
6-8 weeks
Entry Criteria
Product Configuration Report has been Signed Off by the state
Sign-off on data approach (Data collection/migration/correction/ sync-up/validation)
State Sign Off and Publishing of the TL processes, data template/workflows
Detailed Project Plan
Key Activities
Setting up development environments
Development/customisation of reports and dashboards
Development/Integration of portal
Third-Party Integrations (Payment gateway, Handheld/pos device)
Updation of user manuals and other key documents
Preparation & execution of Test Cases
Setup monitoring, support & maintenance processes, tools and dashboards
TL Legacy data collection from Pilot ULBs as per the data agreement signoff by the state
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Identify ULB level nodal officers for day to day support
Migration and verification of Pilot ULB data as per the data agreement signoff by the state
Exit Criteria
Configured/Customized product that is ready for UAT
Set up of Monitoring, support & maintenance of Dashboards
finalization of Initial Reporting and Dashboard KPIs
Identification of participants for UAT session
Duration
2-3 weeks
Entry Criteria
Configured/Customized product ready for UAT
Pilot ULB Officials associated with TL are available for UAT & Training
Key Activities
UAT Environment Setup
Issues/bug identification and resolution
Regression UAT and Sign off from Pilot ULBs/ State
Setting up the Production environment
Setting up Support Centre & processes (Help Desk)
Training (Users, trainer)
master trainers identified from ground for simultaneous training
Training the Support Resources
Marketing & promotion activities
Go Live & launch event
Setup of review and monitoring cadence/team
Usage/review/Dashboard/Field Visits
Exit Criteria
UAT Sign-off & Go Live for Pilot ULBs
Setup of review and monitoring cadence
Duration
5-6 weeks
Entry Criteria
Pilot has been successful in the State
there are less than 3 open critical incidents (issues) with respect to product, implementation and data
Key Activities
ULB configurations phase wise as per the Project Plan
Verification and migration of ULB data phase wise as per the Data Agreement Sign Off provided by the State
Establishment of bug ticketing tool for resolving ground level issues by the state team
Training the Users at the district level
Pan State Roll Out - Phase wise
Stabilise product
Exit Criteria
State-wide Rollout in batches:
Adoption tracking & Review Cadence operational
Help Desk Effectiveness assured
Critical Bugs fixed
Program Success Metrics Tracking Kick-started
Duration
Ongoing process
Entry Criteria
Rollout Phase 1(First set of ULBs where rollout will happen after Pilot)
Key Ongoing Activities
Adoption Review Meetings as per the vision defined for the program.
Meetings are chaired by the Program Head
Need to be conducted weekly
TL Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around TL to make processes more robust towards enhancing TL revenues (e.g. Upstream and downstream Processes)
Plans of ongoing Sustenance in Place with respect to:
Funding
IT support
Process Effectiveness and Improvements
Project Head
1
Domain Expert
2
District Nodal Officer
1 per district
MIS Expert
4
Task/Activity
eGov
State Leadership
Appoint of TL Cell
Consult
Execute
Finalise funding for the program
Consult
Execute
Define state -specific procurement process
Consult
Execute
System Integrator(SI) Team sign-up/onboarding
Consult
Execute
Finalise Trade License Program Vision
Consult
Execute
Task/Activity
eGov
TL Cell
SI Team
Identify & agree on scope and exclusions
Consult
Consult
Execute
Identify pilot ULBs
Execute
Consult
Project Kickoff - Implementation Methodology Presentation
Consult
Consult
Execute
Product Walkthroughs
Consult
Execute
Define Project Steering Committee structure and Project Governance process
Consult
Consult
Execute
Define phases of deployment/ rollout
Consult
Execute
Agreement on Deployment Priorities and high-level delivery timelines
Consult
Execute
Identify and study all TL process
Consult
Execute
Finalize Program Success Metrics for Adoption and Governance adhering to the vision of the program
Consult
Consult
Execute
Stage 1 - Program kick-off
Task/Activity
eGov
TL Cell
SI Team
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Execute
Consult
Collection of baseline data to measure end line target for the product (Revenue generated, total properties in ULBs etc.)
Consult
Execute
Consult
Circulation of baseline data collection templates to the state/SI Team
Execute
Consult
Task/Activity
eGov
TL Cell
SI Team
Standardisation of all TL processes
Consult
Execute
Define criteria for success
Execute
Consult
Initiate policy change, if needed based on Processes defined
Consult
Execute
Consult
Conduct Product familiarisation workshop
Consult
Execute
Initiate collection of master data from pilot ULBs
Consult
Execute
Finalise data migration/collection/sync-up approach
Consult
Execute
Finalise data validation approach
Execute
Consult
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Execute
Consult
Dashboard design finalisation for Program Tracking
Execute
Consult
Task/Activity
eGov
TL Cell
SI Team
Setting up development environments
Consult
Execute
Development/customisation of reports and dashboards
Consult
Execute
Development/Integration of portal
Consult
Execute
Third-Party Integrations (Payment gateway, Handheld/pos device)
Consult
Execute
Updation of user manuals and other key documents
Consult
Execute
Preparation & execution of Test Cases
Consult
Execute
Setup monitoring, support & maintenance processes, tools and dashboards
Consult
Execute
TL legacy data collection from Pilot ULBs (at least)
Consult
Execute
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Execute
Consult
Verification and Migration of Pilot ULB data
Consult
Execute
Identification of participants for UAT session
Execute
Consult
Task/Activity
eGov
TL Cell
SI Team
UAT Environment Setup
Consult
Consult
Execute
Issues/bug identification and resolution
Consult
Execute
Regression UAT and sign off from Pilot ULBs/ State
Execute
Consult
Setting up the Production environment
Consult
Execute
Setting up Support Centre & processes (Help Desk)
Execute
Consult
Training user
Execute
Consult
Training Trainer
Consult
Execute
Stage 4 – UAT & Go Live
Task/Activity
eGov
TL Cell
SI Team
Training the Support Resources
Consult
Execute
Marketing & promotion activities
Execute
Consult
Go Live & launch event
Consult
Execute
Execute
Setup of review and monitoring cadence/team
Execute
Consult
Task/Activity
eGov
TL Cell
SI Team
ULB configurations phase wise as per the Project Plan
Consult
Execute
Verification and Migration of ULB data phase wise as per the Data Agreement Sign Off provided by the State
Execute
Consult
Establishment of bug ticketing tool for resolving ground level issues by the state team
Consult
Execute
Training the Users at the district level
Execute
Consult
Pan State Roll Out – Phase wise
Consult
Execute
Execute
Stabilise product
Consult
Execute
Task/Activity
eGov
TL Cell
SI Team
Adoption Review Meetings as per the vision defined for the program
Consult
Execute
Consult
TL Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around TL to make processes more robust towards enhancing TL revenues (e.g Upstream and downstream Processes)
Execute
Consult
Plans of ongoing Sustenance in Place with respect to:
Funding
IT support (infra, helpdesk, ongoing enhancements)
Process Effectiveness and Improvements
Consult
Execute
Consult
Infrastructure
The actual Infra will be provided based on the questionnaire inputs received from the state
The state will take care of providing necessary project infrastructure and office facilities during the program for all on-site project Team members, which will be confirmed during the initiation phase. This includes workspace, office equipment (e.g., telephone with STD, fax machine, photocopy machine, etc.), stationery, PC/workstation, project LAN and internet access, etc.
The state will provide the necessary administrative support staff to carry out day-to-day project administration tasks, e.g., meeting rooms, Videoconferencing, etc.
The state should provide a Project Office and at least one conference room with speakerphone throughout the Project Duration.
Project Scope
Any new requirements received from State during the implementation phase will be handled through a change management process
State Team
The state will nominate a reasonably sized multifunctional Team from various departments of the State to be responsible for the implementation. The state Team would be required for information, validation, and execution through the implementation cycle and the Team members should be reasonably empowered to take decisions. Any delay in the decision-making process and the non-availability of the State Team may have an impact on the schedule.
The participants from State are expected to have a thorough understanding of the State’s internal processes.
The state will engage internal and external stakeholders required for this engagement and ensure their availability whenever needed.
Documentation
The Tech Implementation Partner will ensure provision of the following:
User education and training documentation delivery as per the default product documentation of the identified product versions.
Product manuals are expected to be shared with the State as part of the user manual.
All documentation in English and the language requirement of the state.
Training
Training to the end-users will be driven by the state Team.
The state will be responsible for providing the necessary infrastructure required for the Training, which includes the following readiness.
Training Rooms (Parallel Training Sessions) with Projector, White Board, Markers, Internet Connection, sufficient seating capacity, Desktop/Laptop for each participant and availability of Network for Trainees to connect to the server.
Implementation
The scope of the implementation will be limited to the services mentioned in Section 2.
eGoc Team will have an identified SPOC for handling the first level of communication with the client unless discussed and agreed.
eGov Team will not be involved in defining the test cases or executing the test cases.
Necessary signoff would be provided by the state upon completion of the defined milestones.
The Trade Category List can be defined as the primary or the 1st level classification “head” for trade(s) defined at a ULB/State Level.
1
TC1
Goods
सामग्री
2
TC2
Services
सर्विस
The table above contains sample Trade Category data.
1
Trade Category Code
Alphameric
64
Yes
The Code assigned to the Trade Category. Eg: TC1 For Goods, TC2 for Services
2
Trade Category Name (In English)
Text
256
Yes
Name of the Trade Category in English. Eg: Goods, Services etc.
3
Trade Category Name (In Local Language)
Text
256
Yes
Name of the Trade Category in Local Language (as decided). Eg: Service is described as “सर्विस” in Hindi
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.
Enter a unique Trade Category Code for each trade head.
Enter the Trade Category Name. Some trade categories are already defined in the master. Add new categories as required.
Enter the Trade Category Name (Local Language).
The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
The format of the Trade Category Code defined should be alphanumeric and unique
TC1: Goods
TC2: Services
2
Trade Category Name (In either Language) should not contain any special characters
Goods: [Allowed]
#Goods! : [Not allowed]
Configuration Data Templateconfiguration-data-template-trade-master-2-.xlsx - 17KB
Sample Data Templatesample-configuration-data-template-trade-master-filled-2-.xlsx - 19KB
Trade Type can be further sub-classified into Trade Sub Type depending on the trade ontology existing in the ULBs or States. Hence, Hotels can be further classified into Dhabas in North India or Udupis in South India.
Once the Trade Type(s) are defined, the next task is to -
Define Trade Sub Types
Map Trade Types to corresponding Trade Sub Types
1
TRADE_SUBTYPE_CLINIC
Clinic
क्लिनिक
TRADE_TYPE_MEDICAL
2
TRADE_SUBTYPE_DHABA
Dhaba
ढाबा
TRADE_TYPE_HOTEL
The table above contains sample data.
1
Trade Sub Type Code
Alphanumeric
64
Yes
The Code assigned to the Trade Sub Type. Eg: TRADE_TYPE_Dhaba is assigned to Hotels
2
Trade Sub Type Name (In English)
Text
256
Yes
Name of the Trade Sub Type in English. Eg: Clinic
3
Trade Sub Type Name (In Local Language)
Text
256
Yes
Name of the Trade Sub Type in Local Language (as decided). Eg: Dhaba is described as “ढाबा” in Hindi
4
Trade Type Code
Reference
64
Yes
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.
Select the relevant Trade Type Code from the Trade Type master data. This will map the listed Trade Sub Type to the selected Trade Type.
Enter a unique value for Trade Sub Type Code.
Enter the English name for Trade Sub Type Name (English).
Enter the local name for the Trade Sub Type Name (Local Language).
The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
The format of the Trade Sub Type Code defined should be text and unique
TRADE_SUBTYPE_CLINIC
2
Trade Type Name (in either language) should not contain any special characters
Clinic: [Allowed]
#Clinic! : [Not allowed]
Configuration Data Templateconfiguration-data-template-trade-master-3- (1).xlsx - 17KB
Sample Data Templatesample-configuration-data-template-trade-master-filled-3-.xlsx - 19KB
Structure sub type is the second level of classification of the premises where the trade has to be established and conducted. This is mostly used as management information in the trade detail.
1
PUCCA
Pucca
पक्का
IMMOVABLE
2
KUTCHA
Kutcha
कच्चा
IMMOVABLE
3
HDV
Hand Driven Vehicle
हाथ चालित वाहन
MOVABLE
4
MDV
Motor-Driven Vehicle
मोटर चालित वाहन
MOVABLE
The table above contains sample data.
1
Code
Alphanumeric
64
Yes
Unique code to identify each and every record uniquely
2
Structure Sub Type* (In English)
Text
256
Yes
Structure sub type in English
3
Structure Sub Type* (In Local Language)
Text
256
Yes
Structure sub type in local language e.g. in Hindi, Telugu etc.
4
Structure Type Code*
Reference
64
Yes
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document for more details on data type, size, and definitions.
Contact the person who shared this template with you to discuss and clear your doubts.
Enter the relevant structure sub types with its proper mapping with structure type.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per specifications. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of.
A separate entity-specific checklist is not needed for this entity data template.
Configuration Data Templateconfiguration-data-template-structure-subtype_v1-1-.xlsx - 10KB
Sample Datasample-configuraion-data-structure-type-and-subtype-2-.xlsx - 9KB
The structure type is the first level of classification of the premises where the trade has to be established and conducted. This is mostly used as management information in the trade detail.
1
IMMOVABLE
Immovable
अचल
2
MOVABLE
Movable
चल
The table above contains sample data.
1
Code
Alphanumeric
64
Yes
Unique code to identify the records uniquely
2
Structure Type* (In English)
Text
256
Yes
Structure type in English
3
Structure Type* (In Local Language)
Text
256
Yes
Structure type in local language e.g. Hindi, Telugu etc.
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document for more details on data type, size, and definitions.
Contact the person who shared this template with you to discuss and clear your doubts.
Enter the relevant structure types.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per specifications. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
A separate entity-specific checklist is not needed for this entity data template.
Configuration Data Templateconfiguration-data-template-structure-type_v1-1- (1).xlsx - 10KB
Sample Datasample-configuraion-data-structure-type-and-subtype-1-.xlsx - 9KB
Once the Trade Ontology is defined, the next step is to allocate the license fee associated with the Trades.
Dependent on the Trade Classification Level (Types/ Subtypes), the fee allocated might be the same across the Sate or could vary from ULB to ULB. There could be a distinct fee(s) for two different types of applications (new and renewal).
Following are the key tasks to be executed :
Allocate the License Fee according to Trade Classification Level (Types/Subtypes).
Map the License fee with the respective Trade Classification Level.
1
TRADE_SMALL_BAKERY
Small Bakery
2500
2000
Workers
1
20
2
TRADE_SMALL_BAKERY
Small Bakery
3000
2500
Workers
21
30
2
TRADE_MED_BAKERY
Medium Bakery
5000
4500
Workers
1
30
The table above contains sample data.
1
Trade Sub Type Code
Reference
64
Yes
2
Trade Sub Type Name (In English)
Text
256
Yes
Name of the Trade Sub Type in English. Eg: Small Bakery
3
New License Fee
Decimal
(6,2)
Yes
The fee charged when the license applied for the respective trade for the first time.
4
Renewal License Fee
Decimal
(6,2)
Yes
The fee charged when the license applied for the respective trade for the renewal.
5
UOM
Text
64
No
The Units of Measurement” associated with the Trade. Eg: Workers is the UOM associated with the trade “Bakery”
6
UOM From
Integer
6
No
Initial Range from which the “Units of Measurement” is applicable for a Trade
7
UOM To
Integer
6
No
Final Range to which the “Units of Measurement” is applicable to a Trade
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
Identify the “Trade Sub Types” that exists at a ULB/ State level.
Collect the above information and feed it below the “Trade Sub Type Name” column accordingly. The Description of Trade Sub Type Name must be provided as per the language specified in the respective column.
Add the “Trade Sub Type Code” respectively against the identified trade type(s).
Fill in the New License Fee & New Renewal Fee accordingly. The New License Fee & Renewal Fee can be the same as well as distinct, depending on the by-laws/ mandate followed by the State/ULB.
Fill in the fields related to Units of Measurement (UOM Unit, From/To) for the available trades only.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
Trade Type Name (In either Language) should not contain any special characters
Small Bakery: [Allowed]
#Small_Bakery! : [Not allowed]
Configuration Data Templateconfiguration-data-template-trade-master-4-.xlsx - 23KB
Sample Data Templatesample-configuration-data-template-trade-master-filled-4- (1).xlsx - 24KB
Users can review the list of applications and their status registered under their mobile number in the My Applications tab. Each Application for the initial view will display Application No, Service Category, Owner Name (Multiple with a comma), status, SLA, Trade Name with View Details option, and if the status is pending for payment it will be View Details & Pay, through which User can look up more details about the Application.
Once the user clicks on the View Details or View Details & Pay button, the Application Details Page will be displayed with all the necessary information about the application.
The user can download the Application Acknowledgement Form (status - pending for payment ) or TL Certificate or receipt if it has been paid from the Download Link button at the top right corner of the page.
Timeline Component - timeline component is present at the end of the application details which tells about the current status and history of the application being initiated, Applied, Pending for Document Verification, Pending for Field Inspection, Pending approval, Pending payment, Approved etc.
The link for the Applications and Application Details main code is given below, it can be used to understand the working of the code, Below is the folder link.
The template for My Application List is present under https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/tl/src/pages/citizen/Applications/Application.js and Application Details page is present inside https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/tl/src/pages/citizen/Applications/ApplicationDetails.js .
All the Application list is being retrieved by calling the search API "/tl-services/v1/_search
", if the view is set as “bills”, all the application is loaded using the hook useFetchBill
which calls the /billing-service/bill/v2/_fetchbill
API. SLA value in Application List Screen is being calculated from the data received from workflow API : /egov-workflow-v2/egov-wf/process/_search
Following is the hook used for the Trade search API.
To get the Application details in key-value format, in order to make it more compatible, following hook is being used, which is a common service to be used across modules.
No MDMS data is being used here, all the data is being loaded from Search API/Fetch Bill API.
For My Applications also the Localization keys are being added in the ‘rainmaker-tl’ locale module same as other parts of module TL. To change, update or of adding any new localization key will be done in the same locale module only.
Along with the rates, the Trade License application process does require certain documents as an attachment of proof. The proof can be defined by a set of documents ranging from
Identification Proof (Drivers License/ Voter Card/ Adhaar/ Pan etc.)
Trade Premises Proof (Lease Agreement, Electricity Bills, etc).
Misc Documents (Affidavit, Self- Declaration, etc).
The Number and the Documents required could vary across the State, ULB(s), and might be dependent on Trade Subtypes, all of which are totally configurable on DIGIT.
1
TRADE_SMALL_BAKERY
Small Bakery
New
PAN/VOTER ID
LAND LEASE
2
TRADE_SMALL_BAKERY
Small Bakery
Renewal
PAN/VOTER ID
ELEC BILL
The table above contains sample data.
1
Trade Sub Type Code
Reference
64
Yes
2
Trade Sub Type Name (English)
Text
256
Yes
Name of the Trade Sub Type in English Eg: Clinic
3
Application Type
Text
256
Yes
Type of application for which the documents related to trade are configured. It can either be new or renewal
4
Document 1
Reference
256
Yes
5
Document 2
Reference
256
Yes
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify the “Trade Sub Types” that exists at a ULB/ State level.
Collect the above information and feed it below the “Trade Sub Type Name” column accordingly. The Description of Trade Sub Type Name must be provided as per the language specified in the respective column.
Add the “Trade Sub Type Code” respectively against the identified trade type(s).
Fill in the *Document 1 & *Document 2 columns respectively.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
Trade Sub Type Name (In either Language) should not contain any special characters
Small Bakery: [Allowed]
#Small_Bakery! : [Not allowed]
Configuration Data Templateconfiguration-data-template-trade-master-4- (1).xlsx - 23KB
Sample Datasample-configuration-data-template-trade-master-filled-4-.xlsx - 24KB
Trade License Calculator service is used to calculate the Trade license fees / renewal fees based on the defined billing slabs. This service enables the TL admins to create billing slab with different combination of license type, trade type, structure type and accessory type. The service is designed in such a way that it can be used to serve different type of licenses.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has tl-calculation-persister & tl-billing-slab-persister config path added in it
PSQL server is running and a database is created to store TL Application data
Following services should be up and running:
egov-perister
egov-mdms
tl-services
billing-service
TL Admin an Employee of ULB with TL_Admin role can create, update billing slab(s)
ULB Employee with TL_CREATOR and TL_ADMIN can search billing slab(s)
TL service internally calls tl-calculator to generate demand.
Deploy the latest version of tl-service and tl-calculator
Add tl-calculation-persister.yml & tl-billing-slab-persister.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )
tl-calculator will be integrated with tl-services. tl-services internally invoke the tl-calculator service to calculate and generate demand for the charges.
Tl calculator application is used to calculate the Trade license Fees based on the different billing slabs in the DB that's why the calculation and demand generation logic will be separated out from TL services. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the TL services.
TL application to call /tl-calculator/v1/_calculate to calculate and generate the demand for the TL application
ULB Employee can create billing slab calling /tl-calculator/billingslab/_create
ULB Employee can update billing slab calling /tl-calculator/billingslab/_update
ULB Employee can search billing slab calling /tl-calculator/billingslab/_search
TBD
Title
Link
API Swagger Contract
Trade License Document
Title
Link
tl-calculator/billingslab/_create
tl-calculator/billingslab/_search
tl-calculator/billingslab/_update
tl-calculator/v1/_calculate
(Note: All the API’s are in the same postman collection therefore the same link is added in each row)
__
__
This feature allows the user to edit the application already created under their mobile number. After verifying employee can send the application back to the citizen with remarks of any changes that are needed to be done, which can be edited by the user using this flow.
On the Application details page, on the employee side, if the application is marked with “Send Back to Citizen”, the edit option will appear dynamically at the end of the application details page, which the user can navigate through my applications.
After this, On clicking the button, the user can edit the trade license details by going through the create flow again. First, it will land on the Summary page, where for each section “change” button is there. Clicking on the Change button, the user will be redirected to the particular content, the only exception here will be the values will be pre-populated from the License object received from Trade License Search API, on completing the flow, Update API will be called and License application will get successfully updated.
Edit Trade License main index can be found in the link given below:
here the main code consists of the function which results in transforming the License object received in Search API to the object structure which is suitable for citizen Apply flow (owner details, units, accessories etc), as the user needs to go through Apply flow again with pre-populated details and update the value of any accordingly. it also consists of the routing for the pages in the Apply flow.
getTradeEditDetails() function is being used so that the License object which is received from the Trade Search API, is converted to the Apply flow relevant structure so that the values can be pre-populated for the user convenience, on completing the flow, the application is updated. The link for the same can be found below:
Similarly, for owners the method which is used to form the new request param array is gettradeownerarray
It is similar to Accessories and Units - the only difference is in UI. Users can’t select multiple owners and only add one owner, it needs to either add more than one owner or select a single owner as ownership category and proceed. After the successful update the application next action will be “Pending for document verification” as there is an update in the data.
On completing the flow, the same object structure which was being used earlier in the flow gets changed into the request body structure for the update API: /tl-services/v1/_update
, for this, the method which gets used is declared inside the Utils folder. Method name: convertToResubmitTrade
and it can be found in the below link:
MDMS data that is being used here is the same as the Apply flow only, as the flow structure used for edit trade is the same as the Apply for Trade License. Please refer to the link for detailed MDMS information.
For Edit Trade also, the Localization keys are being added in the ‘rainmaker-tl’ locale module. To change, update or adding of any new localization key will be done in the same locale module only.
Search Application and Search License pages are used for searching any application/ license that may or may not be relevant to the workflow action of the logged-in users.
Search Application has 2 components.
Search field component is a form which takes inputs and pass it into tl-search api params. It utilizes SearchForm and SearchField component to create and arrange the form.
Result Table uses Table react component and the result from api is adapted to the table config using a custom hook inside common parent wrapper and passing the response to individual components
Search License has fixed param where the status of the application is “APPROVED”, other than differences in table config
API end point for searching trade licenses is {env}/tl-services/v1/_search
API CURL -
Inbox page is constituted out of 4 react components:-
ApplicationLinks is a separate component that hold links to other pages of possible navigation from inbox. This component is common in both Mobile and Desktop view. Links are conditionally rendered according to the user roles
Search Application component is a form based component, that controls the Table component and the search param for Inbox API, it uses FormComposer HOC to render fields.
Validation of these fields are achieved by using controlled component rules
Any number of search fields can be added but by convention, only mobile numbers and appilication numbers are provided
Filters contain input fields to filter the result of api, by sending search params to inbox api.
It contains 3 sections
Assigned to Me/ All - It is a radio component to send assignedToMe param as true or false
Locality - Filter result according to the selected locality by sending locality code in moduleSearch params in inbox api
Status - Status filters are achieved by sending id received from inbox api response and mapping the name of businessService, status name and count
Table is a react component which uses React-Table plugin, used in multiple modules
However in Mobile view are using cards to list all the applications without pagination support
API CURL -
This service is used to issue a license to the user after verification. The service is designed in such a way that it can be used to serve different type of licenses. Currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass. The service is integrated with workflow where we can define the steps for approval of the application. Once the application is approved the license is generated.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has tl-services persister config path added in it
PSQL server is running and database is created
Used for license generations in trade licenses, stakeholder registration and issue lockdown pass
Define roles to applicants on successful application to access Building Plan Approval services at the time of stakeholder registration
Generate application number and license number
Support workflows
Provide notification on various status changes for an application
Add MDMS configs required for Trade License and BPA stakeholder registration and restart MDMS service
Deploy the latest version of tl-services service
Add tl-service persister yaml path in persister configuration and restart persister service
Add Role-Action mapping for API’s
Create businessService (workflow configuration) according to trade license and stakeholder registration
Add tl-service indexer yaml path in indexer service configuration and restart indexer service
Following application properties in the Trade License service are configurable.
The trade-license service is currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass.
Provide backend support for the different license registration process.
Mseva and SMS notifications on application status changes.
The elastic search index for creating visualizations and Dashboards.
Bpa Stakeholder registration provides new roles to the user to access the Building Plan Approval system.
Supports workflow which is configurable
To integrate, host of tl-services service should be overwritten in the helm chart.
{servicename}/_create/ _create should be added as the create endpoint for creating any license in the system
{servicename}/_search/ _search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
{servicename}/_update/ _update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
In all below endpoints if the service name is BPAREG it is treated as a stakeholder registration application and if it is TL or if it is absent then the application is treated as trade license application.
Users can apply for trade license application by clicking on the Apply for Trade License button, and while going through the workflow, can add all the information, according to the question asked, at the end of the flow a summary screen will be visible for the review of the answers and on clicking the submit button an Application Trade License will be created for current Financial Year.
Apply Flow - The Trade License Registration screen will be displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for Trade License. A Citizen Info card is also shown at the bottom of the page for any additional information, in here it’s about the maximum size of the file that can be uploaded.
Trade License Details/Assessment Flow - In this flow, the user needs to provide specific information about the trade being registered in order to get the license. Following are the steppers user needs to go through in this flow.
Trade Name - The user needs to give the name of the trade and on this page, only an info card is shown at the bottom which tells about the current financial year the trade application will be created, this financial year value is retrieved from MDMS.
Structure Type - here users need to select yes or no based on whether the trade has mobility or not, if they select Yes, then it will move to vehicle type and if they select No then it will move to the Building type page.
Commencement Date - It defines the date at which the trade had started or will start in the future.
Trade Units - User can enter about the trade category whether its goods or services, according to the option selected, Trade Type will load from MDMS as a drop-down and according to the trade type selected trade sub-type options will load in the trade sub type drop-down. The unit of measure and UOM value cannot be entered by the user, it will get pre-populated according to the options selected above that too from MDMS.
Users need to enter at least one unit to move forward and if needed to enter more, add more unit option can be clicked to do so, and to remove any unit, delete option on the top right of each unit card can be clicked.
Accessories - The Accessory page inquires if there are any accessories required for the business or not. Accessories may not be compulsory for all trades. If yes, it will move to the accessory details page. If no, it will skip it altogether and move to the start of the address flow.
Address Details Flow - After entering the details about the Trade, users will need to enter the address of the Trade, where it is located. The flow is straightforward, without any conditional routing.
Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, will be automatically filled.
Owner Details Flow - At the end, users need to enter the details, about the Trade owner. Ownership can be Single or Multiple Owners. According to which the details will be filled.
In the case of a single/Multiple Owner following screen will be displayed, rest flow will remain the same.
Users can add multiple owners by clicking on the add owner button, the same functionality as Trade units and accessories. Add Owner button is not visible if the user selects a single owner on the previous page.
The rest of the flow will contain the owner primary address and three documents mainly regarding address proof, owner identity and owner photograph.
Check Page and Acknowledgement Screen - Users can cross-verify the data entered throughout the flow in the Check page and also if needed to change/update any data, can do that by clicking on the change option just mentioned in front of the data, it will credit them to the said page which data needs to be changed and then the whole flow needs to be repeated again in order to submit the application.
For Applying of Trade License Create API is being called, following is the snippet of the Create API being used:1create: "/tl-services/v1/_create"
If the API response is successful, then the Acknowledgement Screen will be displayed, otherwise Failed Acknowledgement Screen will be displayed.
On clicking on the Download Acknowledgement Form, A PDF will be downloaded.
All the screen has been developed using the new-UI structure followed previously in FSM, PGR and PT, except for multi-component.
The link for the Apply Trade License Main Index is given below, it can be used to understand the starting point of the flow:
TL (Trade License) Module has been segregated into a specified structure, All the screen configuration is inside PageComponent Folder, and the configuration for routing of the pages are mentioned under config folder which is common for both Citizen as well as Employee. Below is the snippet for folder structure and routing configuration.
Pages Folder is where the high-level configuration for controlling the whole flow is mentioned, for citizens and employees. Citizen includes Create, EditTrade, Renewal, Applications and Search Trade. Which inside carry the index (the main starting point of the whole flow).
In the Accessory-details page, Billing slab search API "/tl-calculator/billingslab/_search"
is being called, which returns the array list of all the accessories for which the billing slab has been configured, from that object only a list of accessories has been formed, if the response came out to be an empty array then the options are curated from the MDMS API mentioned in the MDMS data section.
After completing the flow the user can download the acknowledgement PDF form of the License created and the config for the PDF generation can be found in the link given below:
Utils Folder basically contains all the methods which are being used throughout the TL module, and if any common method needs to be declared here, which in turn can be imported in other files.
For creating an Application the Create API from Trade License is being called using the React hooks, which has been declared under hooks/elements/TL as TLService.
Throughout the flow, a few of the page data are being imported from MDMS, Following is the list of pages that are using MDMS data, These pages .js files can be found under page components.
For calling of MDMS data React Hooks has been used, so that it could be shared throughout the modules. Below is the little code snippet for the call used for MDMS.
Localization keys are added under the ‘rainmaker-tl’ locale module. In future, if any new labels are implemented in the Trade License (Citizen) that should also be pushed in the locale DB under rainmaker-tl locale module. Below is an example of few locale labels.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The Code assigned to the Eg: TRADE_TYPE_MEDICAL is assigned to Hospitals
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Unique code of structure type to establish the mapping with
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The Code assigned to the . Eg: TRADE_SMALL_BAKERY is assigned to Bakery
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
If the status is Pending for Payment for the application or Action required by citizen (discussed elaborately here ), a button will be visible to pay or edit at the end of the page respectively. On clicking on the Make Payment button it will redirect to the common pay screen through which the user can make the payment.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The Code assigned to the. Eg: TRADE_SMALL_BAKERY is assigned to Bakery
The primary document required as a verification parameter. Refer to the
The Secondary Document required as a verification parameter. Refer to the
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
User can delete and add as many as accessory or units it needs but there should be at least one unit to complete the application, to add a new unit or accessory “Add” button is used which is located at the end of the page. A new array is formed with all the updated details or with the old unit/accessory, when the flow is completed, this new array is then compared with the old array of accessories and units, and a new resulting array object is formed for the request body, you can find the respective code in the following method : gettradeupdateaccessories
& gettradeupdateunits
. this can be found in the below link
On Inbox page {env} is the only API that is called.
Stakeholder registration APIs:-
Trade-License APIs:-
All content on this page by is licensed under a .
To provide the facility for the user to create trade license application for the current year by citizen or counter employee.
Vehicle Type / Building Type - The options for vehicle and building type are coming from the MDMS structure. Building type contains an information card about the options Pucca or kuccha.
Accessory details - The options for accessories are retrieved from MDMS. According to the option selected Unit of Measure or UOM gets pre-populated, which is non-editable by the user. The users can edit the UOM value and the accessory count or it may get pre-populated from MDMS. Click on Add More Trade Accessory button to add multiple accessories.
egov.idgen.tl.applicationNum.format
PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]
The format of the TL application number
egov.idgen.tl.licensenumber.format
PB-TL-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]
The format of the TL license number
egov.idgen.bpa.applicationNum.format
PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]
The format of the Stake holder application number
egov.idgen.bpa.licensenumber.format
PB-SK-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]
The format of the Stake holder license number
egov.tl.max.limit
100
Max number of records to be returned
citizen.allowed.search.params
tenantId, applicationNumber, limit, offset, licenseNumbers
The search parameters on which citizen can search
employee.allowed.search.params
tenantId, applicationNumber, applicationType, status, mobileNumber, fromDate, toDate, licenseNumbers, oldLicenseNumber, limit, offset
The search parameters on which employee can search
persister.save.tradelicense.topic
save-tl-tradelicense
The name of kafka topic on which create request is published
persister.update.tradelicense.topic
update-tl-tradelicense
The name of kafka topic on which update request is published
persister.update.tradelicense.workflow.topic
update-tl-workflow
The name of kafka topic on which update request is published
Title
Link
Local Setup
API Swagger Documentation (Trade License)
{servicename}/_create, _create
This API is used to create an application for the license in the system. Whenever an application is created an application number is generated and assigned to the application for future reference.
{servicename}/_search, /_search
This API is used to search the applications in the system based on various search parameters like mobile number, the application number, status etc.
{servicename}/_update, _update
The _update API is used to update the application information or to forward the application from one state to another.
In the case of the stakeholder registration if the application reaches the last stage the role depending on the license type is given to the user.
{servicename}/{jobname}/_batch, /_batch
Searches trade licenses that are expiring and send a reminder SMS to owner's of the licenses
TradeLicense
List of documents required for registration
TradeLicense
Documents
SelectTradeName
Current Financial Year
egf-master
FinancialYear
SelectVehicleType
Type of mobility trade
common-masters
StructureType
SelectBuildingType
Type of Steady Trade
common-masters
StructureType
SelectTradeUnits
List of trade category and its corresponding type and sub-type
TradeLicense
TradeType
SelectAccessoriesDetails
Lit of Accessory and its Unit of measure and UOM value
TradeLicense
AccessoriesCategory
TLSelectAddress
List of cities and its corresponding localities
TradeLicense
tenants
SelectOwnerShipDetails
categories imported are single and multiple owner.
common-masters
OwnerShipCategory
SelectOwnerDetails
List of Gender options.
common-masters
GenderType
S.No.
API
Action id
Roles
1
/egov-mdms-service/v1/_search
954
CITIZEN
2
/tl-services/v1/_create
1685
CITIZEN
3
/filestore/v1/files/url
1528
CITIZEN
4
/billing-service/bill/v2/_fetchbill
1862
CITIZEN
5
/tl-calculator/billingslab/_search
1684
CITIZEN
6
/tl-services/v1/_update
1686
CITIZEN
7
/localization/messages/v1/_search
1531
CITIZEN
This feature allows the user to renew any trade license applications, which either has been expired or had to be renewed for current financial year (Approved and Paid), it also had integration with the payment component, in order to complete the flow all together for renewal.
Renewal can be two types:
DIRECT RENEWAL
EDIT RENEWAL
If the user before renewal need to update the application, they can do so by clicking on the change button on the summary screen, this will tell that the flow has been changed from direct to edit renewal, and user will need to follow the same apply flow in order to complete the edit part of it. the values from the application will be pre-populated in the respective screens, to get the details about the edit flow,one can refer this link. Send Back Flow - Edit.
Once the user click on submit button it will change the current action of the application to pending for document verification as the data has been updated.
Renewal Trade main index can be found in the below given link:
in this we are calling the trade license search API, In order to get all the application, through which the sorting is happened to classify which application are eligible for renewal for the current financial year.
the hook which has been used for the API is:
The data from here then are sorted into application which doesn’t have any open renewal application for current financial year or which has a status of approved or expired. the significant method to get the renewal list of application is mentioned below:
From here the Trade License List Component has been called which displays the list of the renewal application.
The main functionality of converting the License Object received from the API to the object structure for formdata for apply flow , following is done at the similar way as the edit trade, and the same method is being used to convert the response object, to know more details please refer to Send Back Flow - Edit
Once the user has completed the flow as required or clicked the submit button directly, the method convertToEditTrade
is being called, which re arranges the data for the request body for the update API /tl-services/v1/_update
.
If its a direct renewal only one update API is being called which updates the financial year only.
but if its a edit renewal, two updated API is called after the first API successful call the application status gets changed to Initiated but after the second API call its changed to applied. with next action as pending for document verification.
the code for these can be found in utils folder index please refer the below link for the same:
https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/tl/src/utils/index.js
MDMS data which is being used here is same as the Apply flow only, as the flow structure used for edit renew trade is same as the Apply for Trade License. Please refer the link for detailed MDMS information.
For Renew Trade also, the Localization keys are being added in the ‘rainmaker-tl’ locale module. To change, update or adding of any new localization key will be done in the same locale module only.
Learn how to apply for new trade license, renew and pay trade license fee
Citizens represent individuals, communities, or business entities who are the system end-users. The TL module allows business owners to apply for a trade license online or even apply for renewal of an existing license.
The citizen can also approach the Counter Employee (CE) to submit new TL applications or raise renewal requests for existing licenses.
The Citizen or CE role can -
Download payment receipts, license certificates, or applications
Citizens or CE can apply for a new trade license through the DIGIT web portal or the DIGIT mobile app. To apply for a new TL click on the Trade License card available in the Citizen Services section of the DIGIT home page.
Enter Mobile Number, Name, and City details. Click on the Continue button.
Enter the OTP received on the given mobile number. Click on Continue. The system validates the details and allows the user to log in to the system with the registered mobile number.
Enter your registered mobile number and the OTP received on the mobile to log in. Click on Continue with Whatsapp button to register your service request using the WhatsApp channel.
Click on the Continue button.
Click on Apply for Trade License.
The initial application screen displays the list of documents that have to be submitted for trade license registration. Scroll through the list and make sure the required documents are scanned and ready for submission online.
Enter the Trade Name. Click on the Next button.
Click on the Yes or No option to indicate the Structure Type of the trading premises. Yes to indicate the trade will run on an immovable structure. And, No to indicate the trade will run on a movable structure.
Select Pucca or Kutcha option to indicate the Building Type. The Building Type option appears if the selected Structure Type in the previous screen is Immovable. In the case of Movable structures, the system displays the Structure Sub Type as Vehicle Type. Select Hand Driven Vehicle or Motor-Driven Vehicle option depending on the trading plans.
Enter the Trade Commencement Date. This date indicates the inception or starting date of the trade.
Select the Trade Category as either Goods or Services in the Trade Units screen. Next, select the appropriate Trade Type and Trade Sub Type from the available drop-down list. Click on Add More Trade Units button to append multiple trading units.
Select Yes or No to indicate if you have any trade accessories.
If Yes, select the applicable Accessory from the drop-down list. Enter the Count for the selected Accessory to provide details on the number of accessories required. The system auto-populates the applicable UOM, if any, for the selected accessory. Enter the UOM value. Click on Add More Trade Accessories button to append multiple accessories.
Enable the Location Finder to allow GPS to track the current location. Or, move the pin to the location manually. Alternatively, you can also enter the location in the Search bar.
The Pincode field gets auto-populated if the location is selected on the map. Else, enter the Pincode of the location details manually. Click on Skip and Continue in case you are unable to provide the Pincode details.
City and Locality/Mohalla fields are auto-populated once the Pincode is entered. Else, select the City and applicable Locality/Mohalla from the drop-down list**.**
Enter the Street Name and Door No. details.
Provide a Landmark to locate the trading premise.
Select either the Single Owner or Multiple Owners option to indicate the type of ownership in the Ownership Details screen.
Enter the Owner Name. Select the applicable Gender and enter the owner’s Mobile Number.
Enter the Owner’s Address. Check the Same as Trade Address box if the owner’s address and trading address are the same. This will auto-populate the trading address provided earlier.
Upload the documents as required.
Validate the information entered in the application summary screen. Click on Change to modify the information if required. Click on Submit button once the filled in details are found correct and complete.
The system generates a unique application reference number. Click on Download Acknowledgement Form to download and print the acknowledgement.
Citizens can renew their existing trade applications on the DIGIT portal. CE can also apply for TL renewal on behalf of the citizens. To renew TL navigate to the home page and then click on the Trade License option. Click on My Applications. Click on the Renew Now button on the specific license.
The system will display the license details. Click on the Take Action button. Click on the Edit button to make any changes to the existing license details. Click on the Submit for Renewal button to apply for renewal.
The Trade License is submitted for renewal.
My Applications option allows applicants to view their applications and track their status.
Click on My Applications.
The screen displays all the applications tagged to the registered mobile number. Click on the View Details button to view the application details. In case the application is pending payment click on View Details & Pay button to make the payment.
The Application Timeline displays the current status and completed actions on the selected application. If the application status shows Pending for Payment, click on the View Details and then the Pay button to initiate payment.
Click on Print Receipt to download the receipt. The citizen can also click on the home page to go back to the home page.
An illustrative guide to using the TL module
The Trade License (TL) module offers the citizens and governance bodies a convenient and transparent means of processing trade licenses. Trade license is the permission issued by the local governing bodies to carry on specified business or trading activity within the authorized area. It is a mandatory document required to run a business or commercial activity of any type.
The TL module enables citizens to apply for trade licenses or renew existing licenses online. It facilitates the governing bodies to validate and approve the license applications.
User Role
Scope of Action
Role Description
Citizen
Apply for Trade License
Pay for license
Track status of the license application
Download payment receipts
Individuals and business entities
Counter Employee (CE)
Apply for a Trade License
Complete the Payment for Trade License
Keep a track of the status of the Trade License
Download/Print payment receipts, applications, TL certificate
Counter employees who assist citizens and file new trade license applications or renewal applications on their behalf
Document Verifier (DV)
Verify and forward
Send Back
Edit
Employees responsible for verifying the supporting documents submitted by citizens for new trade license or renewal of existing licenses
Field Inspector (FI)
Verify and forward
Send Back
Reject
Edit
Employees who go on to the field (i.e. location of trade) and physically verifies the information provided by the applicant is correct, checks safety precaution followed by the trade owner
Approver
Approve
Send Back
Reject
Cancel TL
The employee who has the final authority to approve or reject the application
This section guides you through the details of using the TL module for each role. Click on the relevant role below to learn more about how to use the TL system.
All the fields in this flow are the same as the New TL Application. The difference here is that max fields are having pre-populated data (On Loading the page, search is made for that particular application).
Will get the Renew Trade License option, when the application is in an approved state and the same financial year application is not present in the workflow.
When we click on the Renew Trade License application, it will route to Renew screen
Direct Renewal: There is no change in any fields and directly clicks on submit application, update API call is made for the respective application wit respective to Direct Renewal (applicationType
: RENEWAL
, workflowCode
: DIRECTRENEWAL,
)and it will go into direct renewal flow.
Edit Renewal: If there is any change in any fields and clicks on submit application, update API call is made with respect to edit renewal (applicationType
: RENEWAL
,workflowCode
: EDITRENEWAL
)and update the application and it will go into edit renewal flow.
Units, Accessories, Owners and documents details in case of Edit/Renewal flow
Acknowledgement Screen
After a successful update call, the user is routed to the acknowledgement screen.
EDIT Flow: It is also the same as renewal flow only, but we are passing the action action
: RESUBMIT
on the update call with all the changes.
Application/ Trade Details: Application Details/Trade Details
TL Create New Application: New Trade License Application
API
ROLES
ACTION ID
1
/egov-mdms-service/v1/_search
TL_CEMP
954
2
/tl-services/v1/_create
TL_CEMP
1685
3
/tl-services/v1/_update
TL_CEMP
1686
4
/tl-calculator/billingslab/_search
TL_CEMP
1684
Provide Employee to purpose workflow actions.
The same screen is used for both application details and trade details.
Based on the conditions, we are showing the details here
example: If the application is not in an approved state and the business Service New TL, then we are showing application details otherwise we are showing trade details.
For workflow actions, please refer to the file below.
Timeline View
Workflow is the same as Old UI only, please refer to the documentation link below.
API
ROLES
ACTION ID
1
egov-mdms-service/v1/_search
CR_PT
954
2
/tl-services/v1/_update
TL_APPROVER, TL_CEMP, EMPLOYEE, TL_DOC_VERIFIER, TL_FIELD_INSPECTOR
2029
3
/egov-workflow-v2/egov-wf/process/_search
EMPLOYEE
1730
4
/tl-services/v1/_search
EMPLOYEE
, TL_APPROVER
, TL_CEMP
1687
5
/egov-hrms/employees/_search
TL_APPROVER, TL_CEMP, EMPLOYEE, TL_DOC_VERIFIER, TL_FIELD_INSPECTOR
1752
The trade license 'apply' is the major feature in TL Module. It allows Citizens or Counter Employees to create TL Applications for the current financial year.
Every application is a part of the workflow.
Once the user login with TL_CEMP
Role, then the User will get the option for creating a New TL Application in the TL card and as well as in the inbox.
Clicking of New Application it navigates to the New Trade License Application screen.
Initial MDMS call is being made on page load like old UI.
Data fetch, load and render
Clicking on Submit button, tl-services/v1/_create
api is called and create the application, after getting success response, we are calling update API tl-services/v1/_update
.
Acknowledgement Screen
After Success of create and update calls, will route to the ****acknowledgement screen.
API
ROLES
ACTION ID
1
/egov-mdms-service/v1/_search
TL_CEMP
954
2
/tl-services/v1/_create
TL_CEMP
1685
3
/tl-services/v1/_update
TL_CEMP
1686
4
/tl-calculator/billingslab/_search
TL_CEMP
1684
Once the user click on Renew Trade License button at the home page, it will redirect to the renewal list page which will display all the application eligible for the renewal corresponding to the mobile number on which the user has logged in. It will show the Trade name, License Number, Owner Name and status whether active or expired.
Once the user click on Renew Button, it will redirect the user on the summary page just like in edit Trade license, with all the values pre-populated from the search API. Info card will be declared so that user will understand how to proceed with either direct renewal or edit renewal.
If the user just want to renew the same application without updating any data, it will cross-verify all the values in the summary page and then click on submit button directly at the end of the page, this will lead the application with the next status as pending for payment and user can go through payment flow from the acknowledgement screen also, by clicking on the Make Payment button.
Click on Pay redirects the citizen to the internet banking page and make the payment.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Employee can edit units in both cases, employee can add and delete multiple units, please find the file below reg all use cases: digit-ui-internals/TLTradeUnitsEmployee.js at main · egovernments/digit-ui-internals
Employee cannot edit accessories in both cases, the employee can not add and delete multiple units and all fields are in disable state, please find the file below reg all use cases: digit-ui-internals/TLAccessoriesEmployee.js at main · egovernments/digit-ui-internals
Employee can edit in both cases, expect ownership details, ownership details field is in disable state in both cases. please find the file below reg all use cases: digit-ui-internals/TLTradeUnitsEmployee.js at main · egovernments/digit-ui-internals
Employee can edit the documents in both cases, please find the file below reg all use cases: digit-ui-internals/TLDocumentsEmployee.js at main · egovernments/digit-ui-internals
It is common for all modules, find the path here: digit-ui-internals/ApplicationDetailsContent.js at main · egovernments/digit-ui-internals
File path: digit-ui-internals/TLCard.js at main · egovernments/digit-ui-internals and digit-ui-internals/DesktopInbox.js at main · egovernments/digit-ui-internals
Route: mSeva
Structure Type and Sub Structure Type field data is fetched from egov-mdms-data/StructureType.json at master · egovernments/egov-mdms-data
Trade Category, Trade Type, Trade Sub Type field data is fetched from egov-mdms-data/TradeType.json at master · egovernments/egov-mdms-data
Mohalla Data - egov-mdms-data/boundary-data.json at master · egovernments/egov-mdms-data (For Amritsar)
Type of Ownership and Type of Sub ownership - egov-mdms-data/OwnerShipCategory.json at master · egovernments/egov-mdms-data egov-mdms-data/OwnerType.json at master · egovernments/egov-mdms-data
On loading the page, /tl-calculator/billingslab/_search
api is called for showing the licence type (File Path: digit-ui-internals/TLTradeDetailsEmployee.js at main · egovernments/digit-ui-internals ) and accessories options (File Path: digit-ui-internals/TLAccessoriesEmployee.js at main · egovernments/digit-ui-internals ).
Theme
Q1
Q2
Q3
Q4
Enhance functional Coverage
Open dashboards for citizens - To view defaulters - ULB collection performance - Document required in PT UX Revamp - Citizen & Employee - Mutation - Bill Genie & other functions - Receipt Cancellation
Capital rules based assessments supporting the product
- Amalgamation of a property - Bifurcation of a property
Increase adoption
- Product dashboard to measure adoption on field
- Completing the product dashboard documentation & Testing - Deploy updated UX to the existing clients - Data Uploader for improving data migration activities
- A/B testing on features based on the usage and adoption patterns - Data uploader using excel files - POC with impel
- A/B testing on features based on the usage and adoption patterns - Explore interoperability with other govt. functions like registry deptt. etc.
Product innovation
Implementing registry principle in the property tax product
POC - Revenue enhancement tool to plug revenue leakages using GIS, image processing, etc.
Ease of deployment & Partner Enablement
- Centralized Demo environment with completed demo scripts and videos - Standardized reports and dashboard for PT
- Internalizing the BBPS protocols & integration (as done in UK)
Download the brochure to view product features, capabilities, scope and application details
DIGIT-Property Tax (PT) is a self-serve web and mobile-based, easy-to-use and configurable product that addresses the objectives of municipal corporations and local government to automate all property tax operations, thus providing property tax assessment and payment services to citizens in real-time.
Online automated management of property tax revenues and collections
DIGIT-Property Tax (PT) is a self-serve web and mobile-based, easy-to-use and configurable product that addresses the objectives of municipal corporations and local government to automate all property tax operations, thus providing property tax assessment and payment services to citizens in real-time.
Manage property database
Provides support for property registration, transfer, bifurcations, amalgamation
GIS embedded and integrated with eGov financials municipal accounting system
Various payment options available to citizens to make payments from their convenient places
Auto-generated defaulters’ list and real time online tracking
This section contains all docs and information required to understand the PT module, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the PT module.
PT Service Configuration
Demo Script
Navigation Tips
Click on the embedded links within the content to browse topic details
Use the Contents links available on the right side of the screen to move to a specific heading
Find the list of Related Docs links at the bottom of each page to browse through additional product details
Reach out to us through any of the below-mentioned contact channels for any assistance or additional information on PT module deployment.
#147/J, 1st floor, 10th Cross, 12th Main, 3rd Block, Koramangala, Bangalore 560034
+91 80 4125 5708
contact@digit.org
A comprehensive guide to an effective module demo
Welcome to the DIGIT-Trade License product demo script. The key objective of the demo script is to walk users through the trade license module and highlight module capabilities and functions.
The Trade License module offers a comprehensive platform that automates the entire trade license approval process. The TL module streamlines the entire process right from the point of citizens applying for a trade license to the trade license certificate generation.
The module aims to address key trade license governance challenges that include -
Most trades are not registered with the city administration
Lack of transparency in the manual application process
Lack of clarity in the trade license fee computation
Key benefits of using the Trade licenses application -
Transparent process and fee computation
The city administration has the registry of trades operating in the city which helps in better planning of resources
Faster issuance of licenses
Consolidated TL application help ULBs -
Plan city infrastructure
data of all restaurants/party halls are available with the ULBs with the amount of waste generated every day - ULBs can plan efficient SWM truck routing logistics to collect the waste
data of markets and hawkers are present - better infrastructure for shopping complexes can be planned
data of manufacturing and textile units are available - ULB can plan for better power management
Vital to know dangerous and offensive trades like cracker sales / Chemical companies to keep fire stations informed of events
Generate revenue and facilitate prompt services to the citizen
Any citizen who runs a business in the city should get his business/trade registered with the ULB. On registering ULB provides a valid license which is valid for a time period.
Citizens in the TL application should provide info about the
Business/trade (name, location, nature of business)
Ownership details of the trade
Required documents prescribed in the application form
Trade units and accessories - accessories are equipment that is required for the trade which might be of dangerous nature or might make noise during operation like compressors, motors, and pumps.
On submit, the application auto-generates the fee that should be paid by the application and on making the payment it moves to the department side for processing.
The fee depends on the trade type and subtype
Employee processing - Clerk - Revenue inspector - Revenue officer
Application submitted by the citizen lands in the clerk's inbox
The clerk's responsibility is to scrutinize the application and documents submitted and check for correctness.
He/she can either request additional documents from the applicant
Or Upload documents on behalf of the applicant
Or Reject the application citing the reason for a rejection
Or if the application and documents are in order, a clerk can recommend the application for field inspection
On forwarding the application, it will reach the Revenue inspector who is responsible for the field inspection of the site on the ground.
He/she does the field inspection on the field and upload the field inspection report to the application.
On attaching the inspection report the user can either recommend and forward the application for license approval or reject the application.
On forwarding, the application is routed to the revenue officer who is in charge of issuing all licenses within the ULB.
The Approver can approve the application and provide a license certificate, which the applicant can download from his login.
Possible use case scenarios for the demo -
Citizen applies for Trade License
Citizen pays the Trade License fee
Citizen applies for renewal of Trade License
Counter employee submits an application for Trade License on behalf of citizen
Counter employee accepts Trade License fee payment
Employee reviews the application and forwards it for document verification
Employee reviews the documents and forwards them for field inspection
Employee approves the trade license application
Refer to the TL User Manual for step-by-step instructions for each of these demo scenarios.
Functional overview for stakeholders
The Property Tax System(PT) provides a digital interface to make property assessments, pay property tax, generate payment receipts and monitor tax collection. It can be used by the citizens, Urban Local Body (ULB) counter and field employees and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application.
The PT product features can be broadly classified as the following modules:
Registration, Login and Creation of User Profile
Filling an Assessment for a Property
Searching for a Property
Modifications to a Property
Generate Demand Notice
Payments collection and Receipts
Dashboards and Reports
General Features
OTP Based Login for Citizen via Web/Mobile App
OTP Based Login for Employee via Web/Mobile App
Provision for language selection during first time registration for both Employee and citizens
Provision of creating a personalized Profile for Citizens and employees on Web App
Login Credentials for the various hierarchy of employees
Role-based access for performing different actions relating to property tax modules
With this feature, a citizen and employee can perform a self-assessment of a new property for a financial year. This feature helps in registering the property in the system. The details of the property can be entered online and can be assessed for the calculation of the taxes.
The PT Product is designed in a user friendly manner and reduces chances of error. System calculates the tax automatically and creates the demand. If a user wants to reassess his property due to any reason (for eg, incorrect data, change in property etc), it can be done by editing details of the last assessment.
An employee can edit the details of the last assessment, on behalf of the citizen-based on the owner’s input. Citizen can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.
Citizen/CSC can Assess New Property (By Different Financial Years).
Citizen/CSC can Capture Address, Assessment Info, Owner Info.for all types of properties like residential houses, flats and commercial buildings.
o Sample Details captured:
Door Number,
Mutation number,
Number of floors,
Area covered,
Owner and co-owner,
Mailing & permanent address,
Built year
Individual room measurements
The system computes the property taxes automatically as per process and rules of the state.
The system has a facility to make entry in system by inspector after site visit and assessment of the same by the superintendent.
The system supports dynamic calculation for late fees, interest, rebates, etc. as on the day of demand generation.
The system fetches the data of previous year property data while e-filing for current year so that all the dues are calculated.
The system assigns a unique property ID based on the process defined in the ULBs.
Citizen/CSC : View/Print Summary of Filled Form
Assessment Form
Assessment Form is also sent by email to citizen
Upload Documents
Ownership/Title related
ID Proof
Any other statutory documents
Citizen or Employee can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.
Citizen/CSC can search for Property by
Mobile No,
City,
Property Tax Unique ID
Citizen/ CSC can view Incomplete Assessments
Citizen/CSC can reassess Searched Property
View Property details and pending dues
The PT system provides the ability to capture mutation and transfer of ownership. It reduces interfaces between the user and the State and thus promote greater transparency. It also helps in reducing the time taken for mutation after registration. The system provides the ability for alteration of assessment after verification and inspection. Any structural changes like addition/extension/reduction of existing built up area or construction type OR utility changes like usage or occupancy have an impact on the increase/decrease in property tax demand. These changes can be handled by the ‘Additional/Alteration of Assessment’ feature.
The System provides the ability for bifurcation/ amalgamation of property. The property bifurcation/ amalgamation undergoes an approval process. The parent property needs to be modified accordingly, which can be done in the system.
Mutation of property and change of ownership details
Capture Extension/ Addition and Alteration and reassessment based on changed property details
Bifurcation of property
Amalgamation of property
System has the capability to automatically generate demand notice for a financial year based on set triggers like time-based roll over on completion of a financial year. The system notifies the citizens about the demand through SMS/Email. The generated Bills can also be grouped and printed for physical distribution by the ULB employees. The system provides the capability to Employees to merge and download bills based on given parameters to plan their distribution drives.
Generate Demand Notice based on periodic basis
Group Demand Notices
Print Demand Notices
Cancel Demand Notices
Send notifications to citizens on demand generation- SMS, Whatsapp, Email, Physical bil
The citizen/ employee can view payment status of previous assessments from Assessment History section. Payment for any assessment with full or partially paid amount can be completed. Receipts for assessment can be downloaded in Assessment history section after searching for the property details.
Payment of Property Tax -Online, Cheque, Cash, DD, during assessment
Partial Payment of Property Tax -Online, Cheque, Cash, DD, during assessment
The system allows a citizen to pay for anyone's property without changing the demand
The system can also be integrated with PoS machines to enable doorstep collection of property tax and issual of receipt
PT reports provides facility to access receipt register, cancelled receipt register, account receipt register, ULB wise PT collection report, DCB Register. All reports can be downloaded in PDF/XLS format.State level administrator can monitor property tax collections, assessments and other information at a state level through dashboards.
State Dashboard : View Reports for Total Collections, Properties Assessed, ULBs on Prod, Usage Type, Payment Distribution
State Dashboard : PT Collection Timeline (Monthly,Weekly)
State Dashboard : ULB Wise (Collection, Assessments)
Cancelled Receipt Register Report
PT Collection Report (ULB/Date Wise)
Notifications - The system has the capability to send notifications to citizens. These notifications can be sent for various steps like - assessment completion, payment reminder, payment confirmation. These notifications can be sent in the language chosen by the ULB through all channels - SMS, Whatsapp, Email.
Legacy Data Migration - The system has the capability to migrate Demand and Collection. In most states, the preliminary step would be to migrate Legacy data of existing properties/connections along with the Demand and Collection details. This would ensure that subsequent demand generation happens through the system.
Configurable Masters - The system provides the following masters that can be configured as per the State’s
Requirements -
Charges & Calculation : Calculation Engine, Rebate, Penalty,
Rate Master
State Masters : Property Ontology, Documents List, Employee Data Mapping, Boundary Data Mapping
System specification in compliance with the Ease of Doing Business (EODB) BRAP 2019
7
Land administration and Transfer of Land and Property
3
Digitize land transaction deeds of last 10 years at all sub-registrar offices and make the same available on an online system to check for ownership details and history. The metadata should be searchable for each record and a soft copy of the registered deed should be available. The searchable metadata available should be:
i. Name of buyer
ii. Name of seller
iii. Survey no.
iv. Registration number
v. Registration date
The feature of ‘Property Registry’ in the product will enable this recommendation
8
Land administration and Transfer of Land and Property
3
Digitize and publish the updated Record of Rights (ROR) at all Revenue department offices online in public domain for all areas of the State/UT. The searchable metadata available should be:
i. Name of buyer
ii. Name of seller
iii. Date of mutation
iv. Survey no.
The Property tax system enables this capability
9
Land administration and Transfer of Land and Property
2
Digitize and publish data of Property Tax payment dues online in public domain for all the Urban Local Bodies (ULBs) in the State/UT. The searchable metadata available should be:
i. Name of the Property Tax payer
ii. Property Tax dues
iii. Survey no. of land / Unique Identification no. of property
This feature is enabled by the citizens itself
10
Land administration and Transfer of Land and Property
2
Digitize cadastral maps of all rural areas in the State/UT and make them available in public domain
This can be enabled and worked on by the state team
11
Land administration and Transfer of Land and Property
5
Integrate the below-mentioned records on one website:
i. Data of land transaction deeds for last 10 years at all sub-registrar offices (Name of buyer, Name of seller, Registration number, Registration date, Survey no.),
ii. Updated Record of Rights at all Revenue department offices (Date of mutation), and
iii. Data of Property Tax payment dues at all urban areas of the State/UT (Name of the Property Tax payer, Property Tax dues)
iv. Revenue Court case data (Court case number, Name of parties involved, Date of filing of court case, Status of case [Ongoing/Resolved])
v. Civil Court case data (Court case number, Name of parties involved, Date of filing of court case, Status of case [Ongoing/Resolved])
The website should be publicly accessible. It will help in establishing property ownership and identify tax encumbrances. The integration should be done for all areas of the State/UT.
The integration with external portals and systems of other departments can be enabled by state teams who can enhance the offered product to cater to this recommendation
12
Land administration and Transfer of Land and Property
2
Implement an online application system having the following features
i. Mandatory Online application submission including submission of draft deed and other documents
ii. Provision of online payment of Stamp duty and Registration fee
iii. Auto generation of appointment date and time on making the payment of Stamp duty and Registration fee
The system will provide these capabilities which can be customised as per the state specific rules and regulations
13
Land administration and Transfer of Land and Property
1
Provide model deed templates for sale, gift, lease, mortgage and rent in downloadable and editable format along with instructions to use them
This provision is made available through the ULB portal to make these features accessible to the citizens
14
Land administration and Transfer of Land and Property
2
Integrate the mutation process with the registration process and mandate initiation of mutation process (Revenue department and/ or ULB) as soon as the deed is registered. Ensure that:
i. Information to mutation authority to be automatically shared on completion of transaction (registration). This should be considered as initiation of mutation process.
ii. No separate application from transferee to be required.
iii. SMS/email should be sent to transferee/ transferor to inform about the initiation of mutation
The integration with external portals and systems of other departments can be enabled by state teams who can enhance the offered product to cater to this recommendation
List of Features- Property Tax
Registration, Login, Creation of User Profile
Provision for Language Selection during first time registration via Mobile/ Web App.
OTP Based Login for Citizen/ Employee via Mobile/ Web App
Login Credentials for various hierarchy of employees.
Provision of Personalized Profile for Citizen/ Employee on Web App
Filing an assessment for a property
Citizen/CSC : Assess New Property (By Different Financial Years).
Citizen/CSC : Capture Address, Assessment Info, Owner Info.
Citizen/CSC : View/Print Summary of Filled Form
Searching for a property
Citizen/CSC : Search Property (By Mobile No,City, Property Tax Unique ID, Existing ID).
Citizen/CSC : View the Searched Property
Citizen : View My Properties
Citizen : View Incomplete Assessments
Citizen/CSC : Edit the Searched Property
Citizen/CSC : Reassess Searched Property
Generate demand notice
Generate Demand Notice based on periodic basis
Group/ Print/ Cancel Demand Notices
Send notifications to citizens on demand generation- SMS, Whatsapp, Email, Physical bill
Modifications to a property
Mutation of property and change of ownership details
Capture Extension/ Addition and Alteration and reassessment based on changed property details
Bifurcation/ Amalgamation of property
Payment collection and receipts
Payment of TAX (Online,Cheque,Cash,DD) : During Assessment
Payment of TAX (Online,Cheque,Cash,DD) : Partial Payment
Citizen/CSC : Download Receipts for payments
Dashboards and reports
State Dashboard : View Reports for Total Collections, Properties Assessed, ULBs on Prod, Usage Type, Payment Distribution
State Dashboard : PT Collection Timeline (Monthly,Weekly)
State Dashboard : ULB Wise (Collection, Assessments)
Cancelled Receipt Register Report
PT Collection Report (ULB/Date Wise)
General features
Notification
Legacy data migration
System assigns a unique property ID based on the Process defined in the ULBs.
System has the facility to classify the property based on its type.
System allows changing the type of property.
Configuration masters
Configurable Rate Master (ULB Specific) : Fire Cess/ Building Height
Charges & Calculation : Calculation Engine, Rebate, Penalty
State Masters : Property Ontology, Documents List, Employee Data Mapping, Boundary Data Mapping
This page provides configuration details for PT master data templates
DIGIT Property Tax facilitate ULBs and citizens to automate the assessment/ re-assessment of property tax for a property and its demand billing and collection. It also enables the ULBs as well as citizens to process the transfer of title of a property in case of a sale, gift or will and captures the history of ownership.
The main features of the product are as given below.
Completely automated assessment and re-assessment of property tax against a property.
Online self-assessment process
Integrated workflow for ULB staff to perform the check and approve.
Transfer of title (Mutation)
Online application
Integrated workflow for ULB staff to perform the check and approve.
Generating the demand
Collection of property tax through various modes (Cash, Cheque, POS (Credit/ Debit Card), NEFT/RTGS, Online - Through Payment Gateway)
Auto calculation of rebate, interest and penalty.
Receipt Register
Cancelled Receipt Register
Demand Register
The computerized and automatic Property Tax system offered by eGov, facilitates citizens who seek to pay their Property Tax within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. Property Tax (PT) is one of the components of a smart city that has the capability of providing the highest revenue of a state. Keeping in mind the benefits associated with the product offered, the proposed system is about to be implemented in 500+ ULBs across the country in 15 states. (For details on product features refer to Section-2)
For the offered product, the implementation process can be divided into seven major distinctive stages. Each stage has a predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. The whole implementation lifecycle is typical of 38-42 weeks for the State, keeping in mind the entry, and exit criteria defined at the beginning and end of each stage are met on time recommended.
Stage Zero-program setup and onboarding is a pre-requisite for the initiative to kick-off and requires setup of the governance model, implementation Team and decision regarding other significant elements of the initiative like funding and procurement process. Stage One requires scoping of the initiative and decisions on the priorities for implementation by the State Implementation Team. In stage two, the State Team will work upon identifying and finding solutions to the significant gaps in the product offered with respect to the need of the State. Configuration and customization of the product offered is the primary objective of stage four. This involves working on various aspects of State-specific needs and incorporating them into the product offered. In stage five, post doing UAT and including all the necessary feedback on the product, the roll-out of the product is done at the State level (Go Live) from a couple of ULBs to pan State coverage in batches. Finally, in stage 6 sustenance and ongoing improvements are worked upon while the product is already functioning in the State. (For details on implementation plan refer to Section-3)
Implementation of Property Tax (PT) requires meticulous planning and close coordination between various stakeholders at the center and State level. The success of the initiative is dependent upon many factors like strong Program governance, availability of the trained resource, financial planning, targeted Implementation Team onboarding, focus on last-mile capacity building and ensuring necessary support to Urban center. Achievement of all these factors will provide the most effective and efficient roll-out and adoption of the Property Tax System in the State.
The Property Tax System(PT) provides a digital interface to make property assessments, pay property tax, generate payment receipts and monitor tax collection. It can be used by the citizens, Urban Local Body (ULB) counter and field employees, and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application. The PT product features can be broadly classified as the following modules:
Registration, Login and Creation of User Profile
Filling an Assessment for a Property
Searching for a Property
Modifications to a Property
Generate Demand Notice
Payments collection and Receipts
Dashboards and Reports
General Features
This module provides enables the following capabilities
OTP Based Login for Citizen via Web/Mobile App
OTP Based Login for Employee via Web/Mobile App
Provision for language selection during first time registration for both Employee and citizens
Provision of creating a personalized Profile for Citizens and employees on Web App
Login Credentials for various hierarchy of employees
Role based access for performing different actions relating to property tax modules
With this feature, a citizen and employee can perform self assessment of a new property for a financial year. This feature helps in registering the property in the system. The details of the property can be entered online and can be assessed for calculation of the taxes. The PT Product is designed in a user friendly manner and reduces chances of error. System calculates the tax automatically and creates the demand. If a user wants to reassess his property due to any reason (for eg, incorrect data, change in property etc), it can be done by editing details of last assessment. Employee can edit the details of the last assessment, on behalf of the citizen based on owner’s input. Citizen can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.
This module provides enables the following capabilities:
Citizen/CSC can Assess New Property (By Different Financial Years).
Citizen/CSC can Capture Address, Assessment Info, Owner Info.for all types of properties like residential houses, flats and commercial buildings.
Sample Details captured:
Door Number,
Mutation number,
Number of floors,
Area covered,
Owner and co-owner,
Mailing & permanent address,
Built year
Individual room measurements
The system computes the property taxes automatically as per process and rules of the state.
The system has a facility to make entry in system by inspector after site visit and assessment of the same by the superintendent.
The system supports dynamic calculation for late fees, interest, rebates, etc. as on the day of demand generation.
The system fetches the data of previous year property data while e-filing for current year so that all the dues are calculated.
The system assigns a unique property ID based on the process defined in the ULBs.
Citizen/CSC : View/Print Summary of Filled Form
Assessment Form
Assessment Form is also sent by email to citizen
Upload Documents
Ownership/Title related
ID Proof
Any other statutory documents
Citizen or Employee can track down the status of his incomplete assessment. Any incomplete assessment can be searched and completed.
This module provides the following capabilities:
Citizen/CSC can search for Property by
Mobile No,
City,
Property Tax Unique ID
Citizen/ CSC can view Incomplete Assessments
Citizen/CSC can reassess Searched Property
View Property details and pending dues
The PT system provides the ability to capture mutation and transfer of ownership. It reduces interfaces between the user and the State and thus promote greater transparency. It also helps in reducing the time taken for mutation after registration. The system provides the ability for alteration of assessment after verification and inspection. Any structural changes like addition/extension/reduction of existing built up area or construction type OR utility changes like usage or occupancy have an impact on the increase/decrease in property tax demand. These changes can be handled by the ‘Additional/Alteration of Assessment’ feature. The System provides the ability for bifurcation/ amalgamation of property. The property bifurcation/ amalgamation undergoes an approval process. The parent property needs to be modified accordingly, which can be done in the system.
This module provides the following capabilities:
Mutation of property and change of ownership details
Capture Extension/ Addition and Alteration and reassessment based on changed property details
Bifurcation of property
Amalgamation of property
System has the capability to automatically generate demand notice for a financial year based on set triggers like time-based roll over on completion of a financial year. The system notifies the citizens about the demand through SMS/Email. The generated Bills can also be grouped and printed for physical distribution by the ULB employees. The system provides the capability to Employees to merge and download bills based on given parameters to plan their distribution drives.
This module provides the following capabilities:
Generate Demand Notice based on periodic basis
Group Demand Notices
Print Demand Notices
Cancel Demand Notices
Send notifications to citizens on demand generation- SMS, Whatsapp, Email, Physical bill
The citizen/ employee can view payment status of previous assessments from Assessment History section. Payment for any assessment with full or partially paid amount can be completed. Receipts for assessment can be downloaded in Assessment history section after searching for the property details.
This module provides the following capabilities:
Payment of Property Tax -Online, Cheque, Cash, DD, during assessment
Partial Payment of Property Tax -Online, Cheque, Cash, DD, during assessment
The system allows a citizen to pay for anyone's property without changing the demand
The system can also be integrated with PoS machines to enable doorstep collection of property tax and issue of receipt.
PT reports provides facility to access receipt register, cancelled receipt register, account receipt register, ULB wise PT collection report, DCB Register. All reports can be downloaded in PDF/XLS format. State level administrator can monitor property tax collections, assessments and other information at a state level through dashboards.
This module provides the following capabilities:
State Dashboard : View Reports for Total Collections, Properties Assessed, ULBs on Prod, Usage Type, Payment Distribution
State Dashboard : PT Collection Timeline (Monthly,Weekly)
State Dashboard : ULB Wise (Collection, Assessments)
Cancelled Receipt Register Report
PT Collection Report (ULB/Date Wise)
The system has the capability to send notifications to citizens. These notifications can be sent for various steps like - assessment completion, payment reminder, payment confirmation. These notifications can be sent in the language chosen by the ULB through all channels - SMS, Whatsapp, Email.
The system has the capability to migrate Demand and Collection. In most states, the preliminary step would be to migrate Legacy data of existing properties/connections along with the Demand and Collection details. This would ensure that subsequent demand generation happens through the system.
The system provides the following masters that can be configured as per the State’s requirements:
Charges & Calculation : Calculation Engine, Rebate, Penalty,
Rate Master
State Masters : Property Ontology, Documents List, Employee Data Mapping, Boundary Data Mapping
This section provides an overview of the methodology for State-wide implementation of PT. The Implementation of PT is distributed across seven distinct stages. Each stage has a predefined entry & exit criteria and roles & responsibilities. This is to ensure objective monitoring and decision making for the overall success of the program. Details of each stage are defined in this section.
Note: This document is specific for States that have more than 30 ULBs
PT implementation program is expected to be completed approximately between 38- 42 weeks depending on the variety in Processes, Integration and the Disparate legacy data systems involved. This is done with the resource deployment by the State and System Integrator (SI) Team. However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.
This is a set of initial critical activities undertaken on receiving a letter of Enrollment or MOU from the State. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator(SI) Teams, and funds.
*Details of PT cell is mentioned in section 4 of the handbook
System Integrator and state will agree on program scope, program timelines, and budgeting & resourcing.
This stage envisages in-person interaction of crucial State officials and implementation System Integrator(SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify and agree on the scope and exclusions of Pilot ULBs, create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.
*Details of PT cell is mentioned in section 4 of the handbook
During the Solution design stage, key State officials and members, who are subject matter experts, are expected to share their inputs, discuss the process and help understand how to bring in compliance around the system design for the System Integrator(SI) Team. This stage baselines the State-specific product features in the Product Configuration report.
This stage consists of a series of developments in accordance with the detailed project plan to ensure smooth functioning of the customised product. Master Data Collection & Environment Setup will be achieved in this phase. Further monitoring and maintenance strategies are put in place.
During this stage, demonstration of the product followed by a hands on session is conducted for the ULB officials. Necessary training of ULB officials and resources required for UAT is conducted and identified respectively. The establishment of the State support Team and required processes are initiated in this stage.
On successful Go-Live in the Pilot ULBs, and further fine tuning to stabilize the product, the solution will be rolled out to the rest of the ULBs in phases. Guidance and support from the State Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.
Note: The rollout phase needs to be detailed out for iterative activities of onboarding ULBs in batches.
Note: Only once all the stages are complete in one batch of rollout of around 30 ULBs, the next batch begins. There are multiple phases of rollout. The second batch begins after the first batch has successfully fulfilled all the criteria of the Rollout Phase. Typical timeline for closure of rollout in each batch is 5-6 weeks (in a batch of 30 ULBs)
The final stage consists of strategies to ensure the sustenance of the program in the State. Systems are put in place to ensure the continuous tracking of data and provisions are made to improve the product if new data suggests.
This section outlines the activities involved in each stage of the implementation along with responsibility and accountability of critical stakeholders - State, eGov Team and System Integrator Team onboard.
PT Cell: PT Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from Urban Development Department etc.
Resource requirements for the PT cell required to be formed by the State
Note:
Designations mentioned above are in accordance with those already driving PT implementation at the State level.
The description of each designation is explained below.
Project Head: Is the Head of the PT Cell who will drive the project from the State’s Side
Domain Expert: Person who is well aware of the on ground scenario, well versed with the act, GOs passed, Prevalent Business processes, Deviations from the acts, PT Rates/ slabs applicable. In addition, provisions may be made to include External Domain Consultants/Advisors.
Nodal officer (EO/Commissioner/ Senior Official): the product coordinator to drive the project centrally. Monitor usage post Go Live- point of escalation for Implementation Team, Seasoned and worked in Multiple ULBs on various modules and has a good understanding of PT, Facilitate and Track data collection Post Go Live, Monitors and facilitates adoption of application. Point of contact for Management team, SI and at the HQ level.
MIS Expert: Data Preparation for ULBs,Day to day tracking of the data specific to ULBs, data collection/validation for correctness and comprehesiness, reporting and review to senior officials
eGOv Team: eGov Team is the technical partner of the project which will provide all necessary support to the State/UT concerning the implementation, Program Designing etc.
System Integrator (SI)Team: SI Team will be responsible for consulting, program management and the implementation of the state specific customized and configured products in the ULBs in close collaboration with the PT cell, technical partner (eGov) and various other stakeholders.
Execute - One who owns the accountability to complete the activity
Consult - One who may initiate, guide and in the process, handhold the execution of the activity
Note: Stage 0 is where the PT cell and SI team is formed, hence there are only two entities playing a role which is that of eGov and the state leadership. Once the PT cell and SI team is finalised, their role begins in the following stages.
Vision:
Defining the time frame to go live, the time frame to scale it pan state, the value proposition of the programme for the state and year-on-year financial targets and adoption targets
Project Plan:
A detailed plan of Program schedule/timelines, implementation phases, team structure and ongoing support and maintenance required.
System Integrator:
The Entity/Company which collates all the subsystem required for the project and integrates them to achieve the program objective
Program Charter:
Outline of implementation plan agreement with priority applications and broad timelines, program governance model, program success metrics and capacity building.
Acceptance Letter/MOU:
Formal Acceptance/Sign Off of the Client State with a clear mandate of the Program
Program Success Metrics:
Defining the parameters (which are measurable) prior to the program, on which the success of the program is to be measured on the completion of the program
Project steering committee:
The key body within the governance structure which is responsible for the business issues associated with the project that are essential in ensuring the delivery of the project outputs and the attainment of project outcomes.
Project governance:
Set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programmes and portfolios.
Scoping:
List of activities measured against time taken to complete them in accordance with the project goals
Baseline data:
Set of information that serves as a foundation to compare other data acquired afterwards
Project Kick off meeting:
Meeting with the project team and the client of the project. This meeting would follow definition of the base elements for the project and other project planning activities
Fitment Study:
GAP Study of the Existing/Required Field Process Vs Product
Data migration:
Existing Records of the functional activities need to be moved into the Database of the newly released Application
Data collection:
Required data for the roll-out of the applications, which needs to be collected from the existing functional process
Data validation approach:
This approach enables the sanctity of the Data with built-in validation by Design
Data synchronization:
The process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.
Pilot Implementation:
Any new process is tested out as pilot in one or two instances before pan implementation
Pilot ULB:
The ULB's Selected for the pilot implementation are called pilot ULB’s.
Roll out:
On successful clearance of the Pilot, the Process/Application/Services are implemented across all Offices/ULB's
Deployment:
Deployment defines the complete package of Software components set up in a particular environment
Customisation:
Details of changes to be made in the Product to comply with the needed field process
Configuration:
Defining existing content such as Options and Variables based on the requirements on the ground
Product walkthrough:
Explaining the users step-by-step through a set of actions that they need to take to achieve a specific outcome
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
7
Land administration and Transfer of Land and Property
3
Digitize land transaction deeds of last 10 years at all sub-registrar offices and make the same available on an online system to check for ownership details and history. The metadata should be searchable for each record and a soft copy of the registered deed should be available. The searchable metadata available should be:
i. Name of buyer
ii. Name of seller
iii. Survey no.
iv. Registration number
v. Registration date
The feature of ‘Property Registry’ in the product will enable this recommendation
8
Land administration and Transfer of Land and Property
3
Digitize and publish the updated Record of Rights (ROR) at all Revenue department offices online in public domain for all areas of the State/UT. The searchable metadata available should be:
i. Name of buyer
ii. Name of seller
iii. Date of mutation
iv. Survey no.
The Property tax system enables this capability
9
Land administration and Transfer of Land and Property
2
Digitize and publish data of Property Tax payment dues online in public domain for all the Urban Local Bodies (ULBs) in the State/UT. The searchable metadata available should be:
i. Name of the Property Tax payer
ii. Property Tax dues
iii. Survey no. of land / Unique Identification no. of property
This feature is enabled by the citizens itself
10
Land administration and Transfer of Land and Property
2
Digitize cadastral maps of all rural areas in the State/UT and make them available in public domain
This can be enabled and worked on by the state team
11
Land administration and Transfer of Land and Property
5
Integrate the below-mentioned records on one website:
i. Data of land transaction deeds for last 10 years at all sub-registrar offices (Name of buyer, Name of seller, Registration number, Registration date, Survey no.),
ii. Updated Record of Rights at all Revenue department offices (Date of mutation), and
iii. Data of Property Tax payment dues at all urban areas of the State/UT (Name of the Property Tax payer, Property Tax dues)
iv. Revenue Court case data (Court case number, Name of parties involved, Date of filing of court case, Status of case [Ongoing/Resolved])
v. Civil Court case data (Court case number, Name of parties involved, Date of filing of court case, Status of case [Ongoing/Resolved])
The website should be publicly accessible. It will help in establishing property ownership and identify tax encumbrances. The integration should be done for all areas of the State/UT.
The integration with external portals and systems of other departments can be enabled by state teams who can enhance the offered product to cater to this recommendation
12
Land administration and Transfer of Land and Property
2
Implement an online application system having the following features
i. Mandatory Online application submission including submission of draft deed and other documents
ii. Provision of online payment of Stamp duty and Registration fee
iii. Auto generation of appointment date and time on making the payment of Stamp duty and Registration fee
The system will provide these capabilities which can be customized as per the state specific rules and regulations
13
Land administration and Transfer of Land and Property
1
Provide model deed templates for sale, gift, lease, mortgage and rent in downloadable and editable format along with instructions to use them
This provision is made available through the ULB portal to make these features accessible to the citizens
14
Land administration and Transfer of Land and Property
2
Integrate the mutation process with the registration process and mandate initiation of mutation process (Revenue department and/ or ULB) as soon as the deed is registered. Ensure that:
i. Information to mutation authority to be automatically shared on completion of transaction (registration). This should be considered as initiation of mutation process.
ii. No separate application from transferee to be required.
iii. SMS/email should be sent to transferee/ transferor to inform about the initiation of mutation
The integration with external portals and systems of other departments can be enabled by state teams who can enhance the offered product to cater to this recommendation
Stage 0 - Program Setup/ On-Boarding
Duration
4-6 weeks
Entry Criteria
Acceptance Letter/MoU by State
Exit Criteria
Finalize Property Tax Program Vision
Finalize funding for the program
Define State- specific procurement process
Property Tax Cell appointment (*). Consisting of :
Domain expert
Nodal officer (EO/ Commissioner/ Senior Official)
Program Head
System Integrator(SI) Team sign-up/onboarding
Duration
4-6 weeks
Entry Criteria
Program setup (Stage 0) is complete
SI Team onboarded
Key Activities
Identify & agree on scope and exclusions
Identify pilot ULBs
Project Kickoff - Implementation Methodology Presentation
Product Walkthroughs
Define Project Steering Committee Structure and Project Governance process
Define phases of rollout/ deployment
Agreement on Deployment Priorities and high-level delivery timelines
Assessment of all current PT processes along
(1) Citizen services/channels around it
(2) Integration with other Department process
Finalise Program Success Metrics for Rollout, Adoption and Governance, adhering to the vision of the program
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Collection of baseline data to measure endline target for the product (Revenue generated, total properties in ULBs etc.)
Exit Criteria
Publish the program charter
Implementation plan agreement with priority applications and broad timelines
Program Governance Model and processes
Program Success Metrics
Capacity Building
PT Cell formation and appointment (*)
Data preparation/collection kickoff from Pilot ULBs
Cloud Infrastructure procured
Project Office Space allocated
Program Branding (name, logo, tagline etc.)
Stage 2 - Solution Design
Duration
4-6 weeks
Entry Criteria
Program Charter
PT Cell appointment
Key Activities
Standardisation of all PT processes
Initiate policy change if needed, based on the Processes defined
Conduct Product familiarisation workshop
Initiate collection of master data from pilot ULBs
Finalise data migration/collection/sync-up approach
Finalise data validation approach
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Dashboard design finalisation for Program Tracking
Exit Criteria
Publish the PT processes, data template/workflows
Finalisation of Roll-out plan (in different phases)
Solution agreement for required State- specific customisations
Program tracking mechanism (Dashboard design finalisation)
Sign-off on approach to work with legacy or manual data (Data collection/migration/correction/ sync-up/validation)
Detailed project plan
Stage 3 – Configuration & Customization
Duration
6-8 weeks
Entry Criteria
Product Configuration Report has been signed off by the state
Detailed Project Plan set up in accordance with master data collection and environment setup
Key Activities
Setting up development environments
Development/customisation of reports and dashboards
Development/ integration of portal
Third-Party integrations (payment gateway, handheld/pos device)
Updation of user manuals and other key documents
Preparation & execution of Test Cases
Setup monitoring, support & maintenance processes, tools and dashboards
PT legacy data collection from Pilot ULBs(at least). No historical transaction will be considered. Only outstanding and property details shall be migrated
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Identify ULB level Nodal officers for day to day support
Migration and verification of Pilot ULB data
Exit Criteria
Configured/Customized product that is ready for UAT
Monitoring, support & maintenance of Dashboards
Finalization of Initial Reporting and Dashboard KPIs
Identification of participants for UAT session
Training for System Content related Capacity Building finalised
Stage 4 – UAT & Go Live
Duration
2-3 weeks
Entry Criteria
Configured/Customized product ready for UAT
Pilot ULB Officials associated with TL are available for UAT & Training
Key Activities
UAT Environment Setup
Regression UAT and sign off from Pilot ULBs/ State
Issues/bug resolution
Setting up the Production environment
Setting up Support Center & processes (Help Desk)
Training (Users, trainer)
master trainers identified from ground for simultaneous training
Training the support resources
Marketing & promotion activities
Go Live & launch event
Setup of review and monitoring cadence/team
Usage/review/Dashboard/Field Visits
Exit Criteria
UAT Sign-off & Go Live for Pilot ULBs
Setup of review and monitoring cadence
Stage 5 – Rollout
Duration
5-6 weeks
Entry Criteria
Pilot has been successful in the State
there are less than 3 open critical incidents (issues) with respect to product, implementation and data
Key Activities
ULB configurations phase wise as per the Project Plan
Migration and verification of ULB data
Logistics planning for training
Establishment of bug ticketing tool for resolving ground level issues by the state team
Training the Users at the district level
Pan State Roll Out - Phase wise
Stabilise product
Exit Criteria
State-wide Rollout in batches:
Adoption tracking & Review Cadence operational
Help Desk Effectiveness assured
Critical Bugs fixed
Program Success Metrics Tracking Kick-started
Stage 6- Sustenance and Ongoing Improvement
Duration
Ongoing process
Entry Criteria
Rollout Phase 1 (First set of 30 ULBs where rollout will happen after all ULBs are live)
Key Ongoing Activities
Adoption Review Meetings as per the vision defined for the program
Plans for Execution of Core Team to ensure Sustenance of the initiative in the areas of:
Funding
IT support (infra, helpdesk, ongoing enhancements)
Process Effectiveness and Improvements
PT Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around PT to make processes more robust towards enhancing PT revenues (e.g Upstream and downstream Processes)
Project Head
1
Domain Expert
1 Representation from Corporations/Council/Panchayat etc.
District Nodal Officer
1 per district
MIS Expert
1 per district
Task/Activity
eGov
State Leadership
Appoint PT Cell
Consult
Execute
Finalise funding for the program
Consult
Execute
Define state -specific procurement process
Consult
Execute
System Integrator(SI) Team sign-up/onboarding
Consult
Execute
Finalise Property Tax Program Vision
Consult
Execute
Task/Activity
eGov
PT Cell
SI Team
Identify & agree on scope and exclusions
Consult
Consult
Execute
Identify pilot ULBs
Execute
Consult
Project Kickoff - Implementation Methodology Presentation
Consult
Consult
Execute
Product Walkthroughs
Consult
Execute
Define Project Steering Committee structure and Project Governance process
Consult
Consult
Execute
Define phases of deployment/ rollout
Consult
Execute
Agreement on Deployment Priorities and high-level delivery timelines
Consult
Execute
Assessment of all PT process along
(1) citizen services/channels around it
(2) Integration with other department process
Consult
Execute
Finalize Program Success Metrics for Adoption and Governance adhering to the vision of the program
Consult
Consult
Execute
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Execute
Consult
Collection of baseline data to measure endline target for the product (Revenue generated, total properties in ULBs etc.)
Consult
Execute
Consult
Task/Activity
eGov
PT Cell
SI Team
Standardisation of all PT processes, if needed
Consult
Execute
Initiate policy change, if needed based on identified improvements
Consult
Execute
Consult
Conduct Product familiarisation workshop
Consult
Execute
Initiate collection of master data from pilot ULBs
Consult
Execute
Finalise data migration/collection/sync-up approach
Consult
Execute
Finalise data validation approach
Execute
Consult
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Execute
Consult
Task/Activity
eGov
PT Cell
SI Team
Setting up development environments
Consult
Execute
Development/customisation of reports and dashboards
Consult
Execute
Development/Integration of portal
Consult
Execute
Third-Party Integrations (Payment gateway, Handheld/pos device)
Consult
Execute
Updation of user manuals and other key documents
Consult
Execute
Preparation & execution of Test Cases
Consult
Execute
Setup monitoring, support & maintenance processes, tools and dashboards
Consult
Execute
PT legacy data collection from Pilot ULBs(at least)
Consult
Execute
Capacity Building for making state team aware about basic usage of tools like MS Office, mails etc.
Execute
Consult
Migration and verification of Pilot ULB data
Consult
Execute
Task/Activity
eGov
PT Cell
SI Team
UAT Environment Setup
Consult
Consult
Execute
Identification of participants for UAT session
Consult
Execute
Issues/bug resolution
Consult
Execute
Regression UAT and sign off from Pilot ULBs/ State
Execute
Consult
Setting up the Production environment
Consult
Execute
Setting up Support Center & processes (Help Desk)
Execute
Consult
Training user
Execute
Consult
Training Trainer
Consult
Execute
Training the Support Resources
Consult
Execute
Marketing & promotion activities
Execute
Consult
Go Live & launch event
Consult
Execute
Execute
Setup of review and monitoring cadence/team
Execute
Consult
Task/Activity
eGov
PT Cell
SI Team
ULB configurations phase wise as per the Project Plan
Consult
Execute
Migration and verification of ULB data
Execute
Consult
Logistics planning for training
Execute
Consult
Establishment of bug ticketing tool for resolving ground level issues by the state team
Consult
Execute
Training the Users at the district level
Execute
Consult
Pan State Roll Out - All Locations
Consult
Execute
Execute
Stabilise product
Consult
Execute
Task/Activity
eGov
PT Cell
SI Team
Adoption Review Meetings as per the vision defined for the program
Consult
Execute
Consult
PT Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around PT to make processes more robust towards enhancing PT revenues (e.g Upstream and downstream Processes)
Execute
Consult
Plans of ongoing Sustenance in Place with respect to :
Funding
IT support (infra, helpdesk, ongoing enhancements)
Process Effectiveness and Improvements
Consult
Execute
Consult
Infrastructure
The actual Infra will be provided based on the questionnaire inputs received from the state
The state will take care of providing necessary project infrastructure and office facilities during the program for all on-site project Team members, which will be confirmed during the initiation phase. This includes workspace, office equipment (e.g., telephone with STD, fax machine, photocopy machine, etc.), stationery, PC/workstation, project LAN and internet access, etc.
The state will provide the necessary administrative support staff to carry out day-to-day project administration tasks, e.g., meeting rooms, Videoconferencing, etc.
The state should provide a Project Office and at least one conference room with speakerphone throughout the Project Duration.
Project Scope
Any new requirements received from State during the implementation phase will be handled through a change management process
State Team
The state will nominate a reasonably sized multifunctional Team from various departments of the State to be responsible for the implementation. The state Team would be required for information, validation, and execution through the implementation cycle and the Team members should be reasonably empowered to take decisions. Any delay in the decision-making process and the non-availability of the State Team may have an impact on the schedule.
The participants from State are expected to have a thorough understanding of the State’s internal processes.
The state will engage internal and external stakeholders required for this engagement and ensure their availability whenever needed.
Documentation
The Tech Implementation Partner will ensure provision of the following:
User education and training documentation delivery as per the default product documentation of the identified product versions.
Product manuals are expected to be shared with the State as part of the user manual.
All documentation in English and the language requirement of the state.
Training
Training to the end-users will be driven by the state Team.
The state will be responsible for providing the necessary infrastructure required for the Training, which includes the following readiness.
Training Rooms (Parallel Training Sessions) with Projector, White Board, Markers, Internet Connection, sufficient seating capacity, Desktop/Laptop for each participant and availability of Network for Trainees to connect to the server.
Implementation
The scope of the implementation will be limited to the services mentioned in Section 2.
State Team will have an identified SPOC for handling the first level of eGov communication with the client unless discussed and agreed.
eGov Team will not be involved in defining the test cases or executing the test cases.
Necessary signoff would be provided by the state upon completion of the defined milestones.
PROGRAM
In order to justify the Property Owner’s Special Category status, there are certain supporting documents that are required as the attachment of proof. These documents are crucial in terms of providing/ availing rebate on the property tax amount.
1
FREEDOMFIGHTER
Certificate issued by DC/ Competent Authority
डीसी / सक्षम प्राधिकारी द्वारा जारी प्रमाण पत्र
2
WIDOW
Death Certificate + Spouse proof
डेथ सर्टिफ़िकेट + जीवनसाथी प्रमाण
3
HANDICAPPED
Certificate of Handicap by a competent authority
सक्षम प्राधिकारी द्वारा विकलांग का प्रमाण पत्र
The data given in the table is sample data.
1
Owner Type Code
Reference
64
Yes
2
Ownership Documents Description (English)
Text
256
Yes
Nomenclature of “Owner Documents” in English. For ownership type Freedom Fighter, the document required is the certificate issued by DC/ Competent Authority
3
Ownership Documents Description (Local Language)*
Text
256
Yes
Nomenclature of “Owner Documents” in Hindi
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify the “Owner Categories” that exists at a ULB/ State level.
Add the “Owner Type Code” respectively. The predefined format of the Owner Type Code only must be used from the “Owner Special Category” Master Sheet and not any random code. This will provide the base reference for the mapping of ownership type with the required documents.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
This checklist covers the activities which are specific to the entity.
1
The format of the Owner Type Code defined should be Text
War Widow is represented as WIDOW
2
Owner Type Code should not contain any special characters
WIDOW: [Allowed]
#WIDOW! : [Not allowed]
Configuration Data Templateconfiguration-data-template-pt-master-3- (1).xlsx - 10KB
Sample Dataconfiguration-sample-data-pt-master-3-.xlsx - 15KB
Unit rates are also an important part of property tax. The property tax for a property is calculated on the area covered by the property. These unit rates could differ from ULB to ULB, Ward to Ward, Mohalla to Mohalla and then can be based on different parameters such as Road Type, Property Construction Type etc.
1
M001
Haldwani Mandir
PUCCA
< 12 m
1.50
2
M001
Haldwani Mandir
SEMIPUCCA
>= 12 m and <= 24 m
1.75
3
M001
Haldwani Mandir
KUCCHA
> 24 m
2.00
4
M002
Kali Mata Mandir Road
SEMIPUCCA
< 12 m
3.00
5
M002
Kali Mata Mandir Road
SEMIPUCCA
>= 12 m and <= 24 m
10.00
6
M002
Kali Mata Mandir Road
SEMIPUCCA
> 24 m
20.00
The data given in the table is sample data.
1
Boundary Code
Alphanumeric
64
Yes
2
Boundary Name (In English)
Text
256
Yes
3
Parameter 1
Alphanumeric
64
Yes
This has to be the parameter 1 code on the basis of which the unit rates are being defined
4
Parameter 2
Alphanumeric
64
No
This is the second parameter(if available) on the basis of which the unit rates are being defined
5
Unit rates
Decimal
(5,2)
Yes
The unit rate
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Figure out on what boundary types are the property tax unit rates being defined and start filling that with its code and its name in English in the boundary code and boundary code name column.
In case there are more parameters on which the unit rates are being classified such as road type, construction type is being classified, start making a different column for the same starting from parameter 1, parameter 2…
Make sure you replace the column name from parameter 1 to the classification on which it is being classified.
At the end fill up the unit rates column.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfigurable-data-template-property-tax-unit-rate-v1.xlsx - 9KB
Sample Dataconfigurable-sample-data-property-tax-unit-rate-v1.xlsx - 10KB
The request to change in owners associated with a property in municipal record is known as mutation or transfer of title. To process this request and make the necessary changes in the property records ULBs charge for a fee which is calculated based on the fee defined based on a few parameters.
1
RESD
1000
2
NONRESD
5000
Sr. No.
Column Name
Data Type
Data Size
Is Mandatory?
Description
1
Property Usage Code
Alphanumeric
64
Yes
Property usage code - the fee depends upon the type of property usage
2
Flat Fee Amount
Decimal
(5,2)
Yes
Mutation fee flat amount
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.
Reach out the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.
Identify usage wise mutation fee amount and fill into the given template.
Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfigurable-data-template-mutation-fee_v1.xlsx - 10KB
Rebate is provided on early payments which are done in month April in every financial year at the rate of 5% when the property is paid fully up to prevailing financial year demand.`
-10%
300
200
2018-19
01/10
1
RebateRate(In %)
Numeric
(12,2)
Yes
The percentage at which the rebate has to be provided
2
MaxRebateAmount
Numeric
(12,2)
Yes
The maximum amount of rebate that can be given
3
FlatAmount
Numeric
(12,2)
Yes
The flat amount which is levied
4
FromFY
Numeric
(12,2)
Yes
The year for which the rebate is being given
5
RebateEndDate (DD/MM)
Numeric
(12,2)
Yes
The date at which the rebate period ends
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get the rebate rate and the amount involved with it.
Get the year and the end date for the rebate period.
Start filling the template from the right which is the rebate percentage and end it with the rebate end date.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable.
Configuration Data Templateconfigurabe-data-template-rebate-v1.xlsx - 9KB
Sample Dataconfigurable-sample-data-rebate-v1-1-.xlsx - 9KB
Taxes are calculated based on the type of property and differ for each type.
For example, a residential property could have a different rate than a non-residential property, which could differ from year to year.
The tax could be a general property tax or a new type of tax introduced.
1
General Tax (Residential)
2019-20
10
2
General Tax (Non-residential)
2019-20
9
The data given in the table is sample data.
1
Tax Head
Alphanumeric
64
Yes
The type of tax and the property on which the tax is being levied
2
EffectiveFromFY
Numeric
(12,2)
Yes
The year from which the tax rate is being defined
3
Percentage
Numeric
(12,2)
Yes
The rate at which the tax is to be levied
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Gather the details for all the types of properties and the type of taxes levied on them.
Start filling the type of tax and the property type from the first column and then start defining the rates and year of application.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfigurable-data-template-tax-rate-v1.xlsx - 9KB
Sample Dataconfigurable-sample-data-tax-rate-v1.xlsx - 10KB
The penalty is defined as an amount which is charged to the citizen in violation of any rule. There would be multiple penalties defined associated with different rules and acts. Penalty rate decides on how and what amount to be calculated for a penalty.
Within DIGIT, the calculation of the penalty amount is configurable at both the State & ULB level.
1
Late assessment
12.5
1000
500
2019-20
01-04-2019
2
Unauthorized Construction
100
5000
5000
2019-20
01-04-2019
1
Penalty Rate
Decimal
(12,2)
Yes
The Penalty charged by percentage
2
Min Penalty Amount
Decimal
(12,2)
No
The Minimum amount charged as penalty
3
Flat Amount
Decimal
(12,2)
Yes
The pre-decided amount that must be charged as penalty on the amount
4
From Financial Year
Decimal
(12,2)
Yes
The year from which the penalty rate begins
5
Penalty Start Date
Decimal
(12,2)
Yes
The Date from which the penalty amount will be applicable within a financial year
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify all the different types of penalty amounts (by percentage/ by a flat amount) etc and fill them in the provided columns respectively.
Fill in the details of the financial year/ date from which the type of defined penalties will be applicable.
The checklist is a set of activities to be performed one the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfiguration-data-template-pt-master-4-.xlsx - 10KB
Sample Dataconfiguration-sample-data-pt-master-4-.xlsx - 15KB
This section illustrates the steps for different employee user roles at the ULB level
Employees can
Create applications on behalf of citizens
Make a payment on behalf of citizens
Process applications
Renew trade license
Log in to the employee portal using your credential.
An employee can create the application on behalf of citizens over the counter.
Select the applicable Financial Year for which the trade license is to be issued.
Fill in the application details (same as given in the citizen application process).
A unique application reference number is generated. This number is used to access the application and for further processing. The citizen receives a notification along with this application number in the registered mobile number.
Enter the Payment and Payer Details. Click on Collect Payment to process the payment.
The system generates a unique payment Receipt Number. Click on the Print Receipt button to print the receipt. Click on the Go Back to Home Page button to navigate back to the home page.
Click on the relevant Trade License Number to renew. Edit the trade license details in the application form as required.
Click on the Take Action button. Click on Renew Trade License option.
The user can renew it without modifying the trade details or it can be modified. If it is modified, it goes into application processing similar to a new TL application. If it is not edited then renewal happens in real-time after making payment.
Trade license applications pass through various stages where details are scanned, verified, and inspected before the final approval. The workflows are defined at the State or ULB level and adjusted to meet individual department requirements.
The prescribed stages through which trade license applications are routed include -
Document Verification
Field Inspection
Approval
Log in with Document Verifier credentials.
The employee landing page displays the list of applications waiting for processing. Use the search filters on the page to find specific applications from the list.
Scroll through the application details and review the uploaded documents.
Click on the Take Action button and click on Verify and Forward option if all documents are found complete and satisfactory.
Select the Assignee Name. The application will be forwarded to the selected assignee for field inspection.
In case, the documents are found incomplete or missing, click on Send Back to Citizen option. This will send back the application to the citizen for necessary action.
Click on the Reject option if the application details are found inaccurate. This will reject the application.
Log in with Field Inspector credentials.
The employee landing page displays the list of applications waiting for processing. Use the search filters on the page to find specific applications from the list.
Click on the Application Number hyperlink to open the application.
Scroll through the application details and review the details.
Click on the Take Action button and click on Verify and Forward option if all details are found complete and satisfactory.
Select the Assignee Name. The application will be forwarded to the selected assignee for approval.
In case, the documents and details are found incomplete or missing, click on Send Back to Citizen option. This will send back the application to the citizen for necessary action.
Click on the Reject option if the application details are found inaccurate. This will reject the application.
Click on Send Back option to send the application back to the previous employee (document verifier in this case) for further action.
Log in with Approver credentials.
The employee landing page displays the list of applications waiting for processing. Use the search filters on the page to find specific applications from the list.
Click on the Application Number hyperlink to open the application.
Scroll through the application details and review the details.
Click on the Take Action button and click on Approve option if all documents and details are found complete and satisfactory. The trade license is approved and a Trade License certificate is issued to the applicant.
Click on the Reject option if the application details are found inaccurate. This will reject the application.
Click on Send Back option to send the application back to the previous employee (field inspector in this case) for further action.
The TL application is approved and the TL Certificate is issued to the applicant. Click on the Download or Print button to download or print the TL Certificate.
The Usage category could be more detailed out on classifying them further and detailing more specifically on what kind of usage it is such as hotel, shops, community centre etc.
Below mentioned is the definition of the template which is used in data gathering:
The data given in the table is sample data.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Gather all the details for this last classification of Usage Category Detail.
Figure out the codes, if not present abbreviate the description so that it creates relevancy between code and description.
Get the relations to the sub minor, minor and major.
Start filling the template with the codes and description of the usage Category detail and then followed by relative sub minor codes.
In the active column fill up whether the category is still active or not.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed on the data that is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
The Owner’s Special Category represents those property owners whose property belongs to the “reserved” category as defined by the state. These special categories are entitled to a rebate in the property tax amount, as per the defined categories by a State/ ULB.
The data given in the table is sample data.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Add a description to the Owner Type Name, as per the required language.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
This is a further sub-classification of the ownership which details what is the ownership sub category, whether there is a single owner, multiple owner etc. . An example has been given in the attachments section of the page.
The data has to be collected for all the subcategories of ownership type present in the state. Below mentioned is the table of the template that is being used to gather data:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts. First, get all the sub classifications for the listed category.
Get the codes and start filling the template.
Fill in the codes for the sub category in the 2nd column with the proper mapping of Ownership Type category (Parent level).
Repeat the steps for all the ownership type categories(Parent Level).
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
Roads are constructed in order to facilitate the locomotion of people from a place to another.
The roads constructed in a state are classified into certain categories which could be on the basis of the width of the road, construction material or the function and location. Road type is one of the primary factor defining the unit rates and hence configuration is needed for the DIGIT module in order to describe the property and what are the taxes it could attract.
Given below is the sample data table from the template in which the data has to be collected:
Please note that the values mentioned in the data table are sample values and the states are free to add/update according to their specific requirements.
Ownership is the state or fact of exclusive rights and control over property, which may be an asset, including an object, land or real estate, or intellectual property. Ownership involves multiple rights, collectively referred to as title, which may be separated and held by different parties. Further, the ownership can be categorised based on the nature and type of the parties property is owned by e.g Property owned by an individual who is the resident of the city, by an institution etc.
Given below is the sample data table from the template in which the data has to be collected:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Firstly Identify all the categories of the owners present in the state.
After which identify the codes of all the categories, if not present then form an abbreviated version of the code.
Start filling the template with the codes in the second column, its English name in 3rd and Local Language name in 4th.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Not Applicable
This is the amount which is calculated on percentage defined and collected from citizen if failed to pay the property tax demand on time. It is also called the late payment penalty.
The data given in the table is sample data.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get the interest rate that is being levied over a period of time.
Get the year as well as the date from which this was brought in place.
Start filling the data from the interest rate followed by the rest of the details.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
Not Applicable
Unique Identifier assigned for the . For example, Freedom Fighter is represented as FREEDOMFIGHTER
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The code of the boundary that is being used, depending upon the client's requirement it could be Mohalla or Ward but has to be from the data collected
The name/description of the boundary that is being used for the classification. The names have to be from the data collected
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Click on the New Application option in the top left corner of the landing page.
Click on the Submit button once all details are found complete and accurate.
Click on Inbox to view the list of applications submitted.
Click on the relevant Application Number hyperlink to open and view the application details.
Scroll down the application and click on the Take Action button. Click on Pay.
Click on Renew Trade License option on the home page.
Click on the Application Number hyperlink to open the application.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
Identify the “” that exists at a ULB/ State level.
Add the “” respectively.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
All content on this page by is licensed under a .
1.
RED
RESIDENTIAL
आवासीय
2019-20
2.
NONRED
HOTELS
होटल पेईग गेस्ट हाउस 10 कमरों तक(बेगैर वातानुकूलित)
2018-19
1
Usage Category Detail Code
Alphanumeric
64
Yes
This column ideally contains the code for which the Usage Category Detail is being categorized
2
Usage Category Sub Minor Code
Alphanumeric
64
Yes
This is the mapping between detail and Sub Minor Code. Refer Sub Minor entity for more detail
3
Usage Category Detail Description (English)
Text
256
Yes
Description/ Detail of the detail code in which the category is being classified in the English Language
4
Usage Category Detail Description (Local Language)
Text
256
No
Description/ Detail of the detail code in which the category is being classified in Local Language. e.g. Hindi, Telugu etc.
5
Effective From Financial Year
Numeric
(12,2)
Yes
This is the year from which the category detail has come into effect for property tax
1
Make sure that each and every point in this reference list has been taken care of
1
FREEDOMFIGHTER
Freedom Fighter
स्वतंत्रता सेनानी
2
WIDOW
Widow
विधवा
3
HANDICAPPED
Handicapped Persons
विकलांग व्यक्ति
1
Owner Type Code
Alphanumeric
64
Yes
Unique Identifier for Owner Type
2
Owner Type Name ( In English)
Text
256
Yes
Nomenclature of “Owner Type” in English
3
Owner Type Name (In Local Language)
Text
256
Yes
Nomenclature of “Owner Type” in the local language as Telugu, Hindi, etc.
1
Make sure that each and every point in this reference list has been taken care of
1
The predefined format of the Owner Type Code only must be used and not any random code
-
1.
SO
INDIVIDUAL
Single Owner
एकल स्वामी
2.
MO
INDIVIDUAL
Multiple Owner
मल्टीपल ओनर
1
Ownership Sub Category Code
Alphanumeric
64
Yes
This is the code that is being used to categorize the sub type
2
Ownership Category Code
Alphanumeric
64
Yes
This is the mapping between the Ownership Category and Sub category
3
Ownership Sub Category (In English)
Text
256
Yes
Description of the ownership Sub type in the English Language
4
Ownership Sub Category (In Local Language)
Text
256
Yes
Description of the ownership Sub type in Native Language
1
Make sure that each and every point in this reference list has been taken care of
1
There should be a mapping code between the sub category (child) and Property Tax: Ownership Category (parent level), no child can be left without a parent
-
2
Make sure that no code which is not mentioned in the ownership category classification (parent) can be used
-
1
PUCCA
Pakka Building With R.C.C. Roof or R.B. Roof
पक्का भवन, आर0सी0सी0छत या आर0बी0 छत सहित
2
SEMIPUCCA
Any Other Pakka Building
अन्य पक्का भवन
3
KUCCHA
Kuccha building that is all other building not covered in clauses (a) and (b)
कच्चा भवन अर्थात समस्त अन्य भवन जो (एक) और (दो) में अच्छादित नही है
1
RD1
Less than 12 meters in width
12 मीटर से कम चौड़ाई वाले मार्ग पर
2
RD2
From 12 meters to 24 meters in width
12 मीटर से 24 मीटर तक की चौड़ाई वाले मार्ग पर
3
RD3
More than 24 meters in width
24 मीटर से अधिक की चौड़ाई वाले मार्ग पर
1
INDIVIDUAL
Individual
व्यक्तिगत
2
COMPANY
Company
कंपनिगत
3
SOCIETY
Society
सहकारी समिति
1
Ownership Category Code
Alphanumeric
64
Yes
Code to uniquely identify the ownership category record
2
Ownership Category (In English)
Text
256
Yes
This is the name of the ownership category in the English language
3
Ownership Category (In Local Language)
Text
256
Yes
This is the name of the ownership category in the local language
1
Make sure that each and every point in this reference list has been taken care of
18%
200
120
20000
2014-15
01/01/2019
1
Rate
Decimal
(12,2)
Yes
The interest rate percentage.
2
Minimum Amount
Decimal
(12,2)
No
Min amount of interest penalty levied.
3
Flat Amount
Decimal
(12,2)
No
The flat amount which is levied.
4
Maximum Amount
Decimal
(12,2)
No
The maximum amount which could be levied.
5
From FY
Decimal
(12,2)
Yes
The year from which the interest rate begins.
6
Start Date
Decimal
(12,2)
Yes
The date from which this penalty has to start.
1
Make sure that each and every point in this reference list has been taken care of.
Usage Category Minor is nothing but a further classification of Usage Category Major, which can be explained as a broad diversification of the usage of your property.
This broad diversification is ideally used to classify the tax amount to which a property could be exempted from.
Below mentioned is the data table that is used for collecting data:
1.
RESIDENTIAL
Residential
आवासीय
NA
0
0
RESIDENTIAL
2.
COMMERCIAL
Commercial
व्यावसायिक
NA
0
0
NONRESIDENTIAL
3.
INDUSTRIAL
Industrial
औद्योगिक
NA
0
0
NONRESIDENTIAL
Please note that the data mentioned in the table is sample data, however, the state might further update this on the basis of their requirements.
1
Usage Category Minor Code
Alphanumeric
64
Yes
This is the unique identifier that is given to every category.
2
Usage Category Minor (In English)
Text
256
Yes
This is the description of the Minor category in English.
3
Usage Category Minor (In Local Language)
Text
256
Yes
This is the description of the Minor Category in the Local Language.
4
Exemption Rate (in % )
Decimal
(12,2)
No
This column defines the % to which the property could be exempted.
5
Max Exemption Amount
Decimal
(12,2)
No
This is the maximum amount which the property can be exempted from.
6
Flat Exemption Amount
Decimal
(12,2)
No
The amount that should be exempted for a particular category from the property tax.
7
Usage Category Major Code
Reference
256
Yes
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Gather all the details available for the usage category minor type.
Start collecting the codes for the same, if not available abbreviate the description to create a relevant code.
Start filling the template with the codes and descriptions for details in the relevant columns.
After that start mapping them with the relevant Usage Category major codes.
Get the rates as well as amounts for the exemption if any.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of.
Not Applicable
Configuration Data Templateconfigurable-template-pt-usage-type-minor.xlsx - 9KB
Sample Dataconfigurable-sample-data-usage-category-minor.xlsx - 9KB
The Property Sub Type represents 2nd level classification to the Property Type and provides the option to further classify the property type in sub types. For example property type ‘Built-up’ is further classified into Independent House, A Flat In Apartment and Half Constructed Half Open and considered differently on tax calculation procedure.
1
SHAREDPROPERTY
Flat / Part of the building
फ्लैट / भवन का हिस्सा
BUILTUP
2
INDEPENDENTPROPERTY
Independent House / Whole Building
स्वतंत्र घर / पूरी इमारत
BUILTUP
The data described in the above table is sample.
1
Property Sub Type Code
Alphanumeric
64
Yes
Unique Identifier for property sub type record
2
Property Sub Type (In English)
Text
256
Yes
Nomenclature of “Property Sub Type” in English
3
Property Sub Type (In Local Language)
Text
256
Yes
Nomenclature of “Property Sub Type” in local language e.g. Telugu, Hindi etc.
4
Property Type Code
Reference
64
Yes
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.
Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.
Identify all the property sub types applicable and fill into the given template.
Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
There is no separate checklist is applicable to this entity.
Configuration Data Templateconfiguration-data-template-pt-master-2-.xlsx - 10KB
Sample Dataconfiguration-sample-data-pt-master-2-.xlsx - 15KB
This is a further or third level sub-classification of the property usage types into sub minor category. Here the properties can be further classified such as commercial food joints etc.
Below mentioned is the data table from the template used to collect the data:
1
RESIDENTIAL
RESIDENTIAL
Residential
निवास
2
100
200
01-04-2020
2
RETAIL
COMMERCIAL
Retail
खुदरा
3
300
200
01-04-2020
3
HOTELS
COMMERCIAL
Hotels
होटल
5.1
200
300
01-04-2020
The data given in the table is sample data.
1
Usage Category Sub Minor Code
Alphanumeric
64
Yes
This is the unique code given to every category
2
Usage Category Minor Code
Alphanumeric
64
Yes
3
Usage Category Sub Minor (In English)
Text
256
Yes
This is the description of the sub minor category in English
4
Usage Category Sub Minor (In Local Language)
Text
256
Yes
This is the description of the sub minor category in Local Language
5
Exemption Rate (in % )
Decimal
(5,2)
No
This column defines the % to which the property could be exempted
6
Max Exemption Amount
Decimal
(5,2)
No
This is the maximum amount which the property can be exempted from
7
Flat Exemption Amount
Decimal
(5,2)
No
This is the flat amount by which the property owner can be exempted
8
Effective From Date
Date
NA
Yes
This the date from which the exemption is applicable.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify all the sub minor categories used across the state.
After which identify the codes of all the sub minor categories, if not present abbreviate the description.
Get the details(description) of these codes.
Start filling the template with the codes and description in English and one native language would be helpful.
Get the exemption maximum amounts and their respective percentages.
Most importantly do get a mapping of these sub minor codes to their parent which is minor usage type.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed on the data that is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfigurable-data-template-pt-usagetypesubminor.xlsx - 9KB
Sample Datasample-configurable-data-pt-usagetype-minor.xlsx - 13KB
A property can be used for a variety of things such as to live or to do some trading/selling etc activity or for any other purpose. Properties can be classified into various categories on the basis of its usage. Ideally, property usage is categorized as residential, non-residential or a mix of both.
1
RESIDENTIAL
Residential
आवासीय
2
NONRESIDENTIAL
Non-residential
गैर आवासीय
3
MIXED
Mixed
मिश्रित
The data described in the above table is sample.
1
Usage Category Major Code
Alphanumeric
64
Yes
This is a unique identifier being assigned to every major category.
2
Usage Category Major (In English)
Text
256
Yes
This is the description of the major category in the English Language.
3
Usage Category Major (In Local Language)
Text
256
Yes
This is the description of the major category in the Local Language e.g. Telugu, Hindi etc.
Download the data template attached to this page.
Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.
Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.
Identify all the property usages categorized at the first level and fill into the given template.
Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
1.
Make sure that each and every point in this reference list has been taken care of
Not Applicable
Configuration Data Templateconfigurable-template-pt-usage-typemajor.xlsx - 10KB
Sample Dataconfigurable-sample-data-usage-category-major.xlsx - 10KB
Service configuration details
One of the major applications of the eGov stack which helps municipal and citizens to handle property tax payments and other related functions on the property such as assessments, mutation, and so on.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of the demand-based systems.
Following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
The Property Service provides multiple functionalities starting from serving as a central repository where property information is registered for reference of citizens and other municipality-provided services such as water connection and sewerage management. An assessment can be done so as to calculate and pay tax on the property. The different services provided by the property services are
Property Registry
Assessment
Mutation
Bifurcation
Consolidation
Registry Explanation
The registry flow helps the citizen/Employee to create a property in the system with the minimal information required.
Other workflows such as assessment or mutation can be triggered on the existing ACTIVE Property in the registry.
The property can be created, updated, cancelled, searched, Followed by the process of Mutation and Assessment.
The same entry in the registry can be referred by other modules for their business purposes(Water charges).
Persister File Config
Workflow-configs
Each flow in property has a workflow associated with it, which can be controlled by the following configs
The Boolean field which can enable/disable Workflow - same field controls the update and create the workflow
Workflow Config for property create if the source is from WATER CONNECTION module
For use case 1 which says, The property which is creating from Water and sewerage module should have one step workflow. for this requirement in the above MDMS file businessService with PT.CREATEWITHWNS object must have enabled the field to set as true. Then for all the property creation from Water and Sewerage module would have one step workflow and property would be created with an ACTIVE state.
Fields in the above MDMS file
Sample workflow config for use case 1 where property creation is from water and sewerage module with one step workflow
Sample workflow config - (The same PT.CREATE can be used for update workflow also since both involve the same functionality)
PT.LEGACY workflow config
Notifications :
To enable or disable notifcation notif.sms.enabled=true
#notif urls - makes use of the UI app host in notification service egov.notif.commonpay = citizen/egov-common/pay?consumerCode={CONSUMERCODE}&tenantId={TENANTID} egov.notif.view.property = citizen/property-tax/my-properties/property/{PROPERTYID}/{TENANTID} egov.notif.view.mutation = citizen/pt-mutation/search-preview?applicationNumber={APPID}&tenantId={TENANTID}
The Current localization messages for notification
Configs in App.props
Property service can be integrated with any organization or system that wants to maintain a record of the property and collect taxes with ease.
Easy to create and simple process of self-assessment to avoid the hassle.
Helps maintain property data which can be used in the integration of other essential services like asset management, water connection and so on.
provides additional functionalities like mutation, assessment of properties.
Customer can create a property using the /property/_create
Search the property using /property/_searchendpoint
/property/_update endpoint to update the property demand as per need.
Mutation can be carried out with the help of /property/_update itself, no extra API is needed.
Doc Links
API LIST:
The first level of classification of a property based on its construction is defined as Property Type. Generally, the property is divided into two types :
Built-up
Vacant Land
Mostly these property types are fixed and commonly used in all the ULBs across the country. Hence this data is not needed anymore in the template.
The data provided in the above table is sample.
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify the “Property Types” that exists at a ULB/ State level.
Collect the above information and feed it below the “Property Type Description” column accordingly. The Description of Property Type must be provided as per the language specified in the respective column.
Add the “Property Type Code” respectively against the identified Property Type(s).
The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.
This checklist covers all the activities which are common across the entities.
There is no separate checklist applicable to this entity.
Procedure to integrate elastic search for Fuzzy search with any of the eGov modules.
Creating the index as per the requirement
The elastic index has to be used for fuzzy search due to performance enhancement and when PII fields are involved which cannot be accessed in DB directly to apply fuzzy logic.
When PII data are involved those fields shouldn’t be returned by the elastic search but only can be used to apply the filter. To enable this that particular field should be indexed but not stored.
eg -
In the above example, when data is posted, all the fields will be stored, but the index will never return the excluded source fields when searched.
Querying an index
Elastic Integration with code
Add the elasticsearch host from the eGov cluster.
Divide the search params between the ones that will be sent to elastic and others to DB (search to elastic should be made only if the fuzzy fields are present in search request)
The result of the elastic search should be only the required primary-Id of the entity(property-id, trade license-id, etc..)
Then the resulting ids should be used in the normal search as it is.
Application Properties
Properties need to add for integration
The indices need to be reindexed for the fuzzy search to work if changes are done in the index. particularly in the case of protected fields being indexed but not to be returned in the search.
PT-Calculator Service is used for creating demands based on property assessments, mutations, and updating demands with the penalty, interest in case of payment delay.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
PSQL server is running and a database is created to store property/application data
Following services should be up and running:
MDMS
property-services
billing-service
Calculate property tax, mutation fee based on billing slab.
create and update demand.
Deploy the latest version of property service and pt-calculator
Criteria:
Property Type
Property Subtype
Usage Category Major
Usage Category Minor
Usage Category Subminor
Usage Category Detail
Ownership Category
Sub Ownership Category
Plot Size
Floor Number
Area Type
The combination of the above variables can be used to define a billing slab. The billing slabs are stored in db in the table named “eg_pt_billingslab_v2”. To perform CRUD operations on the billing slabs API’s are provided in the module. Following is a sample create request:
The ‘ALL' keyword can be used if the slab is independent of that particular variable. If ‘fromPlotSize’ or ‘toPlotSize’ values are null they will set to positive infinity and negative infinity, a similar process will be for ‘fromFloor’ and 'toFloor’ values.
The estimation service class loops through all the units and calculates the tax based on the applicable billing slab. The exemptions are calculated using master data in MDMS Service. Each tax or exemption is added to the tax head estimate. Following are the exemptions and taxes that are calculated:
Property Base Tax
Owner Exemption
Unit Exemption
Penalty
Rebate
Interest
Fire Cess
Cancer Cess
From the above charges and exemptions penalty, interest and rebate are time-based. Rebate is given if the payment is done before the rebate deadline date specified in Rebate master data. Similarly, the penalty is charged if payment is not done before the deadline to pay tax. After the deadline to pay tax is passed daily interest is charged according to the rate defined in the master.
Property tax is calculated by adding the tax for each unit calculated using the billing slab for that unit. The formula for calculating tax for the unit is:
In case the unit is commercial and rented the formula is as follows:
ARV stands for Annual rent value.
If the property contains ground units (i.e unit with floor number = 0) then tax is also calculated for the unbuilt area. The formula for calculating the tax on the unbuilt area is as follows:
Below is a sample of master data JSON for interest :
If the given year rate is not defined the service will recursively fall back on the previous year until it finds a defined rate slab. The time for which interest is applicable is calculated by subtracting the epoch value of starting day (At 00:00 AM) from the end of the day (23:59 PM) epoch value of the current date. In the case of partial payment, the interest is calculated for each interval between payments and summed as the applicable amount for interest won’t be constant throughout.
If the fraction is greater than equal to 0.5 the number is round up else it’s round down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101
The following is the format of penalty master data:
If the time during the demand creation date is greater than the penalty starting day, a penalty of x% will be applied. The x% is defined in the rate field. The penalty also provides a fallback for master data i.e if for a particular year entry is not present it will recursively search for the previous year and apply that rate.
Depending on the owner type of user flat amount or percentage of tax amount is given as exemption. In the case of multiple owners, the exemption is calculated for each owner and summed. Following is a sample master data:
Once the property is sent to the calculator its tax estimates are calculated. Using these tax head estimates demand details are created. For every tax head, the estimate-demand function will create a corresponding demand detail.
Whenever _calculate API is called demand is first searched based on the property id and the demand from and to period. If demand already exists the same demand is updated else new demand is generated with consumer code as property and demand from and to a period equal to financial year start and end period. In the case of Reassessment, the demand is always updated for the given year.
In case of update, if the tax head estimates changes, the difference in amount for that tax head is added as new demand detail. For example, if the initial demand has one demand detail with PT_TAX equal to 100
After updating if the PT_TAX increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:
RoundOff is bill-based i.e every time bill is generated round-off is adjusted so that the payable amount is the whole number. Individual PT_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all PT_ROUNDOFF will always be less than 0.5.
If demand is created and the total tax is supposed 100.40, then a negative round-off amount of -0.40 is added so that the tax becomes 100. If during reassessment the tax changes and becomes 111.70, to round it off estimate will give tax head estimate of +0.3. The demand generation logic will add a new demand detail by taking the difference in the old and new tax amount for that tax head. Therefore a new demand detail of 0.3-(-0.4)=0.7 will be added. There will be now two PT_ROUNDOFF tax heads one with an amount -0.4 and the other with 0.7 making the total round-off amount (-0.4+0.7)= 0.3 which with the tax amount of 111.70 will give a bill amount of 111.70+0.3=112.
PT-calculator should be integrated with property-services which internally invokes the calculator service to calculate and generate demand for the charges.
Carries out the process of creating demand and updating them on a need basis as per the requirement of assessment and mutation.
/_caluclate should be exposed internally for property-services integration.
/_estimate API should be exposed for UI integration, which enables users to view the estimate before proceeding.
/demand/_update API should be configured in billing service for demand update function on bill expiry.
Ownership Transfer Technical documentation
The mutation service provides a facility to change ownership of a property in relation to sales, inheritance of property. it helps by providing a workflow on config and allows the municipality to collect payment with ease on approval of the process. The mutation flows ad APIs exist within the property-services code base and makes use of all the mentioned external services and configured values, in addition to those the rest can be used to control mutation flow.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of the demand-based systems.
Following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
Enables the user to create a mutation and transfer the ownership to the new owner.
Workflow config:
In Addition to property information and the extra owner information being added, some other information is required for workflow
The Creation Reason in the property should be sent as MUTATION for the request to be considered as a mutation request.
Along with the workflow name for mutation, a few extra details have to be provided in the additional details field of the property. Also either a new owner has to be added or an existing one has to be set to inactive for a valid mutation request.
The business workflow config follows the structure given for property workflow with respective name changes.
Workflow sample config for Mutation.
The property services will make a call to the mutation calculator at the required interval during the mutation flow.
The mutation service belongs to the property service itself and provides the same ease of access for the functionality.
Pick a property id that is already created in the system.
call the property/update API by changing the owner information or adding new owner information.
workflow information must be added mandatorily before submitting the request.
The calculation logic for mutation fee depends on the usage type of property (RESIDENTIAL, NON-RESIDENTIAL, etc ) and the current market value of the property.
If the current market value (CMV) of the property comes in between the minimum and maximum market value range of billing slab and the usage type of property match with the usage type for that billing slab then the mutation fees for that property is the amount mentioned in that particular billing slab.
Further, there are two calculation types which are FLAT and RATE which have to set by state/ULB for their billing slab for property mutation. If the calculation type is set as FLAT then mutation fee is the fixed amount mentioned in the billing slab which is used for the property.
If the calculation type is set as RATE the Mutation fee is X% of the current market value, where X is the percentage rate mentioned in the billing slab which is used for the property.
Other factors influencing calculation can be :
Ownership type
Property type
Locality
When the property is registered for mutation/transfer of ownership and all the document is submitted, then the mutation fees have to pay within a specified period of time of property mutation registration date. If a person fails to pay the amount of the fee before the deadline date, then some penalty charges have to pay. The penalty charge is Y% of the tax amount. The penalty percentage is set by the state/ULB. If a person pays the amount of the fees within the specified month of the property mutation registration date, then a certain amount is rebated from the tax amount. The rebate charge is Z% of the tax amount. The rebate percentage is set by state/ULB.
Note: For mutation fees calculation, document date value (means the date at which property is registered for mutation), market value of property, usage type value of the property is essential.
This is the mapping between the minor’s and major’s of the usage category which can be found in
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Property Type code referring to the
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
This is the relationship between sub minor and
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
MDMS CONFIG:
The persister File config for property services can be found in the Config repo of eGov Git, which needs to be added in the persister service -
For the creation of property from the water and sewerage module, as per the use case mentioned in this , a different workflow config is used. For each use case, to identify which workflow to use can be identified from this .
Note: The above objects indicate each use case mentioned in this , so at a time only one object (use case) enable field must set as true
All content on this page by is licensed under a .
All content on this page by is licensed under a .
This is a simple request, there are that can be used to enhance the fuzzy search.
Please refer to the following for the integration
Reindexing for PT:
Property-services
API Collection -
All content on this page by is licensed under a .
Please refer to the parent for external services:
All content on this page by is licensed under a .
name
value
description
is.workflow.enabled
true/false
enable disbale workflow
PT.CREATE
the name should match the config name in the workflow businessservice JSON
PT.LEGACY
PT.UPDATE
MDMS Fields
Description
businessService
Name of workflow config
initialAction
Indicate the start(initial) action of the particular workflow mention in businessService.
inWorkflowStatusAllowed
This field indicate whether the property with application status as “inWorkflow” can be use with water and sewerage connection creation. If this field is true then for that particular use case, the property with “inWorkflow” status can be use with water and sewerage connection creation and vice versa
enable
If this filed is set as true, then the other fields associate with the particular object is use for property creation.
name
value
egov.idgen.ack.format
PB-AC-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ACK]
egov.idgen.mutation.format
PB-MT-[CITY]-[SEQ_EG_PT_MUTATION]
egov.idgen.assm.format
PB-AS-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ASSM]
egov.idgen.ptid.format
PB-PT-[cy:yyyy-MM-dd]-[SEQ_EG_PT_PTID]
citizen.allowed.search.params
accountId,ids,propertyDetailids,mobileNumber,oldpropertyids
employee.allowed.search.params
accountId,ids,propertyDetailids,mobileNumber,oldpropertyids
Title
Link
USER Service
url-shortening
MDMS
Billing-service
Location
Workflow
Persister
****
Localization
Id-Gen service
Title
Link
/Property/_create
/Property/_update
/property/_search
1
BUILTUP
Built-Up
निर्माण
2
VACANT
Vacant Land
खाली जमीन
1
Property Type Code
Alphanumeric
64
Yes
Unique Identifier for property type record
2
Property Type (In English)
Text
256
Yes
Nomenclature of “Property Type” in English
3
Property Type (In Local Language)
Text
256
Yes
Nomenclature of “Property Type” in local language e.g. Telugu, Hindi etc
1
Make sure that each and every point in this reference list has been taken care of
name
value
description
is.mutation.workflow.enabled
true/false
enables/disbales the workflow
PT.MUTATION
workfow config name
Residential
0
X lacs
A% of CMV
INR G
FLAT
Non -Residential
0
X lacs
E% of CMV
INR Q
RATE
Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
FLAT
Non -Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
RATE
Residential
Y+1 Lacs
>Y+1Lacs
D% of CMV
INR L
FLAT
Non -Residential
Y+1 Lacs
>Y+1Lacs
C% of CMV
INR I
RATE
Title
Link
API contract for MT calculator
API list to create Mutation Slabs mutation/_create, _search, _update
API list for MT-Calculator mutation/_calculate
Step 1
Get the current mapping of the pt index using the _mapping API
Step 2
Add the following json mappings in the existing mappings (parallel to properties key):
Sample QA final mapping for reference is attached at the end.
Step 3
Recreate property-services-enriched with the new mapping.
Step 4
Update the indexer configuration, add the following 3 fields ownerNames
, doorNo
, street
in custom mapping as added below in sample configuration:
https://github.com/egovernments/configs/blob/qa/egov-indexer/property-services.yml
** If search has to be enabled only on names of only ACTIVE user, configure indexer jsonPath accordingly. Use $.owners[*][?(@.status=='ACTIVE')].name
instead in the config
Step 5
Restart indexer
Step 6
Trigger reindexing
Recreated property-services-enriched index with the new mapping
Created kafka connector
Hit the legacy index api
Once data is indexed in property-services-enriched, verify that all the data is indexed
After validating the data, drop the property-services index and use alias to point property-services
to property-services-enriched
Sample mappings from QA env:
For overview Please refer to the parent file - Property Services
The assessment set of services inside the property module is used for assessing the value of a property in a given time frame and collect taxes for the same. Assessment is a snapshot of Property for a given transaction on that Property. These APIs provide functionalities to create/update/search the assessments. An assessment cannot exist without property.
Configs
Assessment shares most of the configs with Property as mentioned above, only exclusive properties are mentioned in this section.
name
value
description
assessment id format
PB-AS-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ASSM]
kafka create assessment topic
save-pt-assessment
kafka update assesmsent topic
update-pt-assessment
assessment.workflow.enabled
true/false
Workflow integration can be controlled by the following two properties
assessment.workflow.trigger.param
usageCategory,occupancyType,occupancyDate
PERSISTER CONFIG: https://raw.githubusercontent.com/egovernments/configs/master/egov-persister/assessment-persister.yml?token=AE4Z2KFWEQBDCUY6AZLGGIK6AM3QQ``
Workflow Config
The first property switches workflow on or off, while the second property provides a way to control which field change can trigger the workflow. A businessService needs to be created using the workflow /egov-workflow-v2/egov-wf/businessservice/_create API.
Sample businessService create API body for Assessment workflow:
Other system-level configs are the same as PT-Registry as mentioned above.
Notification Configs
Payment Notification
For adding localization for any status append ASMT_ prefix to the status and for adding a message for any status add ASMT_MSG_ before the status.
Assessment ****(Property Calculator) -
The calculator service Prepares and property tax and files the demand in the billing service for payment. It has the ‘estimate’ API to give the estimated property tax without persisting data and a calculated API to create demand for payments.
The calculator service PT Calculator
Assessment integration helps citizens to assess their property with ease and helps them verify their tax values by themselves which gives more control to the citizens and hep the municipality collect taxes with ease.
Easy to create and simple process of self-assessment to avoid the hassle.
Integrated payment for multiple years enables by digit platform.
Customer can create an assessment on a given property using the /assessment/_create
Search the assessment and its workflow status by using /assessment/_searchendpoint
/assessment/_update endpoint to update the assessment and its workflow states as per need.
please refer to the property document Property Services | Doc-Links
API LIST
Title
Link
/assessment/_create
/assessment/_update
/assessment/_search
Users can look for the list of the properties registered under their mobile number in My Properties Tab. Each Property for the initial view will display Property Id, Owner Name, Address and status, with view details option, through which User can look up more details about the property registered. If users do not find the property looking for, new property can be registered using the below link “Click here to register new Property”.
Once the user clicks on View Details, the Property Information Page is displayed with all the necessary information about the property.
Click here to fetch the working code for the My Properties and Property Details common Index.
The template for My properties and Property Information page is present inside pt/pages/citizen/MyProperties. The list of properties is retrieved by calling the search API "/property-services/property/_search".
This API is called using the React hook present inside the index of My Properties and Property information page, a single property is being loaded, bypassing the unique Property Id in the search API.
If search API result is successful, Assessment Search API is called to know the assessment status i.e /property-services/assessment/_search.
If the assessment object returned fetches assessment array details then the fetch bill API is called in order to retrieve the payment details for the particular property. API is /billing-service/bill/v2/_fetchbill
Following is the hook used for the property search API, assessment search and fetch bill.
No MDMS data is used here, all the data is loaded from Search API.
For My Properties also the Localization keys are added to the ‘rainmaker-pt’ locale module. To change, update or add, any new localization key is done in the same locale module only.
This page provides the user interface and API details for My Applications feature in the PT module. Users can review the list of applications and their status registered under their mobile number in the My Applications tab. Initially, only four application will load at once. If the user wants to look for more, the “Load More” option needs to be clicked. Each Application for the initial view will display Application No, Service Category, Property Id, Application Type and status, with Track option, that enables the user to look up more details about the Application. If a user is unable to find their property details on the system, a new Application can be raised using the link provided at the bottom of the page.
Once the user clicks on the Track Button, the Application Details Page is displayed with all the necessary information about the application.
Timeline component: The timeline component is present at the end of the application details which tells about the current status and history of the application passing through various workflows and actions taken.
Click here to fetch the working code details for My Applications and Application Details common Index.
The template for My Application is present under pt/pages/citizen/PTMyApplications and the Application Details page is present inside pt/pages/citizen named as PTApplicationDetails. The list of Applications is retrieved by calling the search API "/property-services/property/_search"
This API is called using the React hook present inside the index of PTMyapplication and PTApplicationDetails page, a single application is being loaded, bypassing the unique Property Id in the search API.
Following is the hook used for the property search API.
Create and Update Util Function
The two main util function and the objective of it are given below:
Create Util Function: While going through the Create flow, all the inputs that the user has entered are stored in a different structure. Since the units are not separated in the flow but incorporated according to each ground, the storing structure is different from the request body of Create API. This function transforms the flow of stored data into the requested body format.
Click here to fetch the code.
Update Util Function: Click here to find detailed information about this function.
No MDMS data is used here, all the data is being loaded from Search API.
For My Applications also the Localization keys are added in the ‘rainmaker-pt’ locale module same as My properties and create. To change, update or add any new localization key is done in the same locale module only.
This page provides information and details for edit and updates property feature in the PT module. This feature allows the user to edit the application already created or update the property already registered with their mobile number. After verification, the employee can send the application back to the citizen with remarks on any required changes. The edit and update feature allows the users to make these changes. It also allows the user to update the details of the property details online if there are any such upgrades or changes.
On the Application details page, on the employee side, if the property is marked with “Send Back to Citizen”, the edit option will appear dynamically at the end of the page and will be static in nature.
On clicking the Update button, users can edit/update the property details by going through the Create flow again. The only exception here is the values will be pre-populated from the Property object received from Property Search API. On completing the flow the Update API is called and the property is updated successfully.
Acknowledgement screen
Click here to access the Edit/Update property main index.
The main code contains the functions that transform the property object received in Search API to the object. This includes primarily the Assessment flow units suitable for the Create flow since the user has to go through Create flow again with pre-populated details and update the value of the data accordingly. It also contains the routing details for the pages in the Create flow.
Update Util function: this function does the exact opposite of the Create util function (refer Property Tax - My Applications ). The property object which is received from the Property Search API is converted to the Create flow relevant structure so that the values can be pre-populated for the user convenience, on completing the flow, the application is updated. The link for the same is available here.
MDMS data used here is the same as the Create flow since the flow structure used for edit/update property is the same as the create property flow. Please refer to the link here for detailed MDMS information.
For Edit/Update Property also, the Localization keys are being added in the ‘rainmaker-pt’ locale module. To change, update or adding of any new localization key will be done in the same locale module only.
This page provides detailed UI information on the Create Property feature available in the Property Tax module.
The objective is to provide user facilities to add a new property, view the property details and the application currently on their number. The feature allows users to update the property or edit the application.
Users can add new property using the Create Property button, and while going through the workflow, can add all the valid information, according to the question asked. At the end of the flow, a Check page will be displayed on which the user can cross verify the information entered. On submitting, the application is created.
Create Property Flow
Property Tax information screen will be displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for the property.
Property Details Flow
The user needs to enter the details about the property first. Below is the flow chart for the property details flow**.**
Assessment Details Flow
Then the user will be asked about the assessment details, which contains information about each floor and basement.
Address Details Flow
After entering the details of the property, the user needs to enter the address of the property, where it is located. The flow is straightforward, without any conditional routing.
Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, is auto-populated.
Owner Details Flow
Finally, the user needs to enter the details, about the property owner, it can be institutional - (Government/ Private) or Single/Multiple Owner. According to which the details will be filled.
Check Page and Acknowledgement Screen
Users can cross-verify the data entered throughout the flows in the Check page. Click on the change button adjacent to the relevant data allows users to change/update the entered data. The user is redirected to the relevant page where data needs to be changed. Repeat the successive flows to submit the application.
For Registration of property, Create API is called. Following is the snippet of the Create API used:1create: "/property-services/property/_create"
If the API response is successful, then the Acknowledgement Screen is displayed, otherwise Failed Acknowledgement Screen is displayed.
All the screens have been developed using the new-UI structure followed previously in FSM and PGR.
The link for the Create Property Main Index is given below, it can be used to understand the starting point of the flow:
PT (Property Tax) Module has been segregated into a specified structure. All the screen configuration is inside PageComponent Folder, and the configuration for routing of the pages are mentioned in the config folder which is common for both Citizen as well as Employee. The snippet for folder structure and routing configuration is given below.
Pages Folder is where the high-level configuration for controlling the whole flow is mentioned, for citizens and employees. Citizen flows include Create, Edit, My Properties, My Application and Search Property. The search property flow carries the index (the main starting point of the whole flow).
After completing the flow the user can download the acknowledgement PDF form of the property created. Click here to find the config for the PDF generation.
Utils Folder basically contains all the methods which are being used throughout the PT module. In case any common method needs to be declared here, it can be imported into other files.
For creating an Application the Create API from Property Tax is being called using the React hooks, which has been declared under hooks/elements/PT as PTService.
Throughout the flows, data across a few pages are imported from MDMS. Following is the list of pages that are using MDMS data. These pages .js files can be found under page components.
1
PropertyTax
List of documents required for each category
PropertyTax
Documents
2
PropertyUsageType
Four category imported - (Commercial, industrial, institutional & others)
PropertyTax
UsageCategory
3
PropertyType
three major categories - (Independent, Flat & Part of the building & Vacant)
PropertyTax
PropertyType
4
SubUsageType
List of sub-usage category according to the property usage selected before
PropertyTax
UsageCategory
5
SubUsageTypeOfRentedArea
List of sub-usage category according to the property usage category selected before, same as sub-usage type
PropertyTax
UsageCategory
6
PTSelectAddress
List of Cities (Amritsar, Jalandhar and Nawanshahr) and List of localities according to the city selected
PropertyTax
tenants
7
OwnershipDetails
Four categories imported - (Institutional - private, Institutional - Government, Single Owner and multiple Owner)
PropertyTax
OwnerShipCategory
8
SpecialOwnerCategory
List of special category imported eg Freedomfighter, handicap etc
PropertyTax
OwnerType
9
PTGeolocation
Default value for location i.e Pratap Nagar Latitude and longitude
PropertyTax
MapConfig
10
RentalDetails
Rentaldetails information regarding tax percentage is taken from MDMS
PropertyTax
RentalDetails
Data React Hooks are used for calling MDMS, so that it could be shared throughout the modules.
Below is the little code snippet for the call used for MDMS.
Localization keys are added under the ‘rainmaker-pt’ locale module. In future, if any new labels are implemented in the Property Tax (Citizen) they should also be pushed in the locale DB under rainmaker-pt locale module. Below is an example of few locale labels.
S.No.
API
Action Id
Roles
1
/access/v1/actions/mdms/_get
870
CITIZEN
2
/egov-mdms-service/v1/_search
954
CITIZEN
3
/localization/messages/v1/_search
1531
CITIZEN
4
/property-services/property/_create
1895
CITIZEN
5
/property-services/property/_search
1897
CITIZEN
6
/property-services/property/_update
1896
CITIZEN
7
/property-services/assessment/_search
CITIZEN
8
/billing-service/bill/v2/_fetchbill
CITIZEN
Property applications
Registered properties
Application details
Property information
Edit or update property details
Make payment or search property details
Objective: To provide employees with the functionality to search property (whether Active or in workflow). based on locality, owner mobile, or unique Property Id.
The employee also can see the dues for property within the search results and can choose to pay the dues if any, by clicking on collect tax.
Users can also view the current property Details page, to view Property Details, where employees can perform actions like assessment, Updation and Mutation, on an approved active Property.
The file for search can be found in:
APIs
The 1st API is used to fetch all the localities, based on the logged**-**in tenant.
The 2nd API is used to fetch the search Table data.
The 3rd API is used to fetch the bills for showing the due taxes present in search results.
Property Details Page
This page is visible to the employee when he clicks the property Id of property in search.
Here employees can see the latest approved Property Details. The employee also has the option to start property assessment, transfer ownership, and Edit Property details flow.
The employee also has the option to view history - this enables the users to view the owner details within the history of the property.
The code details can be found in:
APIs
Same as in the case of Application details, But here, The latest approved data is shown and any data which is not in the workflow is filtered out.
Assessment Popup
When an employee selects the action to assess property from the property details page of active property,
A popup is shown having a list of Financial Years:-
A financial Year is selected for the assessment of the property.
Technical Details
The Financial Years are fetched from the MDMS:
Assessment Screen
When selected and clicked on Assess Property the Property Assessment Screen is displayed.
This screen gives the assessment details of the selected financial year from the popup. After clicking on Assess Property, the button changes to “Proceed To Pay” which takes the employee to the common pay screen for employees.
Technical Details
The file for the assessment Details page can be found at the following link :
API Used
The 1st API is provided with financial Year and property Id as parameters to get the payment estimations for the Property.
The 2nd API is used to fetch Property Details.
The 3rd API is used to create an Assessment of the property. Which marks property with the estimated tax.
Objective: To provide the employees involved in PT workflow, the functionalities to create a property Application in create workflow.
A counter employee can use create an application form, to register a citizen’s property.
The file for create Application form for PT can be found in:-
for creating an application employee enters all the details of the form manually, and Documents are uploaded based on the MDMS configuration found in the file:
MDMS Data
The MDMS data for documents is similar to that found in :
**with the noted addition of formDataPath, formArrayAttrPath
, in filterCondition
and dropdownFilter
.
formDataPath
path is the form path in form of an array of keys that requires to be followed to a new UI form to check the entered value. similar to jsonPath
and parentJsonpath
in old UI, While the formArrayAttrPath
replaces the arrayAttribute
.
The use of the MDMS data within the component can be found in :
After adding all the valid documents and form values in the form, the user is allowed to submit the form
which calls the property create API:1property-services/property/_create
Acknowledgement Screen
If the Property creation is successful. then the employee is directed to this screen that shows Acknowledgement Id and the option to download a hardcopy of the acknowledgement containing property details.
An illustrative guide to using the property tax module
The Property Tax (PT) module offers the citizens and governance bodies a convenient and transparent means of processing property taxes. Local governing bodies identify the applicable tax slabs for different types of properties. The PT module assesses properties, calculates tax amount, processes tax payment and generates tax collection reports.
The PT module enables citizens to pay property taxes online. It facilitates the governing bodies process property tax payments.
Refer to the table below to understand the different user roles and the scope of action linked to each role. The applicable user roles and action items can vary from one State to another. DIGIT customizes the workflows to suit the requirements defined at the State level.
This section guides you through the details of using the PT module for each role. Click on the relevant role below to learn more about how to use the PT system.
Objective: To provide employees with the ability to Edit property Details (except Owner Details).
The Edit form can be used to update the details of an approved property, or whenever an application is in a workflow state that allows/require employees to make changes.
All the updatable Input fields are enabled, and all the fields related to owner details are disabled.
After editing and clicking submit when the user is successful the user is redirected to a success screen similar to that in Employee Create.
The implementation of the Edit Form can be found in:
The document details are implemented similar to the create application and uses the same MDMS configurations.
APIs Called:1property-services/property/_update
** The Update API is supplied with updated property values from the form, and also all the units that were added at the time of creation are set with active
: false
, while the new units are set to be active
: true
even if no change is made to the units.
Acknowledgement Screen
If the Property Update is successful. then the employee is directed to this screen that shows the Acknowledgement Id and option to download a pdf of the acknowledgement containing property details.
Objective: To provide citizens with the functionality to apply for Ownership Transfer for an active property.
The Transfer of Ownership Option is provided to citizens on the home screen in the citizen App, under property Tax card.
Upon clicking on “Transfer Property Ownership/Mutation” link, users are taken to property search page just like in case of “search & Pay” option, where he can search for the property he wants to search the property for.
After searching the property the user is shown the property details for the properties based on the search criteria. With Total Dues on top of the card.
If there are dues owed on the property (unpaid taxes), then users are shown a popup stating that the citizen has to clear his dues first. with a proceed to pay button that takes citizens to the common pay page, just like in the case of Search & Pay.
In case of dues cleared the citizen is taken to the Docs required Page, just like in the case of Employee Mutation, where he is shown the list of docs he is supposed to have in order to be able to transfer the property.
on this page after clicking on Transfer of Ownership, the citizen is made to go through the Ownership Transfer flow where he fills in the Ownership details and Mutation Details. After completing the flow citizen is shown with the success screen with his application number and the option to download his acknowledgement as a pdf.
The code for citizen mutation can be found in the link:
MDMS data
The MDMS data is the same as in the case of employee Mutation Screen.
API used
The citizen mutation calls the property-services/property/_update
API to update the property status after that the application is gone through the Employee workflow to complete the transfer.
**When Update API is called the documents are updated for the property according to the following snippet:-
Here originalProperty
is the property data before mutation, and mutationDocs
is the MDMS response for Mutation Docs.
Objective: To provide the employee with the functionality to search the created Applications.
The employee inbox screen shows all the created applications which are in the workflow and requires action from that particular employee.
The employee has the ability to search any application based on Application no, Property Id, or mobile number, or he can apply filters, based on the business service (create, edit, or update), application status, locality, and application assigned specifically to him.
By clicking on the /application no in the inbox user goes to the application details page. where he can take action on the application to push it forward or backwards in the workflow.
The file path for inbox can be found in:
API Used
The API used for searching the Inbox is
The above API is used to fetch the Inbox results based on filters and search criteria.
Inbox Screen offers customization for the fields in the inbox table. The fields inside the inbox table are exposed in the component registry service as in the file:
It is exposed as PTInboxTableConfig
key in component registry service, and can be redefined to reset the columns.
the function returns an object of the following structure:-
the object.PT
contains 2 keys inboxCloumns
and searchColumns
, which are yet again functions.
These functions are provided with props
as an argument, which are props supplied to the component called DesktopInbox
as can be seen in the following file:-
inboxCloumns
and searchColumns
functions return an array of objects, each object represents a column.
The inboxCloumns
is used for setting columns in the Inbox, while searchColumns
is used for setting columns
every column has the following properties:-
Header
is the head that is used in thead
of the column (basically name of the column).
accessor
is .
separated string value that specifies the path within each row to be followed in order to display the value of the column. The structure of the row object is similar to row.original
explained below.
Cell
is function returning a valid JSX, in case some complex component is needed to be rendered. The function is supplied an object with row
property, each row containing property details , with row.original
being the actual data for the property row which is of the form. The searchData
contains search related result associated with the property, while workflowData
contains workflow related data associated with property
This page is where the Employee visits after clicking on desired Application No. in the inbox. The user can find a “take action” button at the bottom of the screen and can perform actions, based on the role the employee profile has and the state of the application in the workflow. He can also view the timeline in which he can see which employee made what update in the workflow.
The employee can see details like owner details, address etc, along with the documents attached at the time of creation, and while action performing by any other employee in the workflow. In the case of mutation Application, the employee can see transferer and transferee details.
While performing the action user can upload docs, comments for the next employee in workflow, or they can assign them to a specific employee in the action resultant workflow.
The code for the application details can be found in
APIs Called
The application details page calls the following APIs.
the 1st API is called to fetch the timeline, through which the Process Instance has gone through.
The 2nd API is called to fetch address, owner-details, and document fileStoreId
for all the documents associated with the property.
The 3rd API is called to get current performable actions based on the current state of the process Instance, which is then filtered through according to actions performable by the employee’s role.
The 4th API is called to fetch all the documents for the file store ids.
The Quick Pay feature allows a citizen to quickly view or pay all his pending bills for Property Tax (or any other supported business Service) by clicking links directly from the Digit-UI home screen.
Clicking on the Property Tax link in the Quick Pay section, a user is logged in and redirected to the My Bills Screen. Else, the user has to log in using his mobile number and the OTP sent to the number. The user is redirected to the My Bills screen.
On the My Bills screen, the user finds his pending property Tax bills (displayed as cards) for registered properties. The user can click on the View Details button of the corresponding card to check the detailed bill summary which takes him to the bill details page. There is also a link for the case when the user is unable to find the property tax bills.
The Bill Details screen shows a list of various categories of taxes that are present. After checking the user can select to pay either the full amount or custom amount, which cannot be less than ₹100 and not more than the total tax. These restrictions, however, are customizable as per ULB requirement and can be changed through MDMS.
Click on the Proceed To Pay button redirects the user to the Pay screen. The user is asked to select the payment gateway from a bunch of radio buttons, and then after clicking pay, the user is redirected to the bank payment gateway.
After making a successful payment through the bank gateway, the user is redirected to the response screen which shows the details of the payment and other bill details.
In case the payment fails for any reason the response screen shows the message, that the payment transaction has failed.
Use Case: when user wants to pay for Property for a different mobile number:
My Bills page only displays the properties with pending Taxes, which are associated with the mobile number which is logged in. But if a user wants to search for any other property, then he can click on the link below the My Bills screen which will take the user to the search screen.
On the Search screen, the user can search a property by mobile Number, a unique property ID, or an existing property ID. After mentioning the parameters the search takes the user to the search results screen. Where user can see all the properties with the matching criteria, whether or not they have pending taxes.
From Here on clicking view Details a user is redirected to the bill-details Screen, for the property, just as in the case of My Bills Screen.
My Bills Screen
An MDMS call is made to this page to fetch details based on the defined restrictions such as partial payment is allowed or not, advance payment allowed or not, minimum payable amount etc. for the particular business Service which is supplied into URL.
The MDMS criteria used here for fetching MDMS details are:
Also, the pending bills are fetched for the citizen for the specific business service using the custom hook, that fetches bill for logged-in mobile number.
On this page, for each business service, there is a configuration stored to define what part of the bill is to be displayed.
The configuration returns an object of structure.
Here my-bill key has config for the my-bills screen, this configuration decides what details to show on the card for each service from the bill object returned through fetchBill API.
It is an array of objects, where each object puts the bill detail on the My-Bills bill card.
Each object contains 4 properties ie keyValue, keyPath, fallback, noteStyle
. The keynote config is added into the Digit component Registry as getBillDetailsConfigWithBusinessService
Bill Details Screen
It checks for various payment restrictions which are fetched from the MDMS on above mentioned MY Bills description, and also all the tax heads that are to be displayed in the summary are also fetched from the same MDMS.
The structure for payment rule response from the MDMS are -
partPaymentAllowed
key when true allows payment less than bill details to be paid otherwise the user can pay only the bill Amount.
minAmountPayable
is the minimum bill amount a user can pay.
isAdvanceAllowed
if the true user can enter the amount more than the specified.
Payment Screen
The payment screen fetches the payment gateways from an MDMS call.
Response Screen
Search Screen
Search Result Screen
The keynote config is responsible for adding the new bill UI for adding a new Bill for a business Service.
MDMS CONFIG:https://github.com/egovernments/egov-mdms-data/tree/DEV/data/pb/PropertyTaxTo show a preview of this link, connect your Github account.GithubConnect
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License
On the Property details page, on the employee side, if the property is marked with Verify → forward → approved, the Update option will appear dynamically at the end of the page and will be static in nature.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
In the case of Institutional, the following data will be asked in the first screen, and the following screen will remain the same.
In the case of a single/Multiple Owner following screen will be displayed, rest flow will remain the same.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
For further enquiry on how to set columns, you can check __out the link:-
If a particular workflow is completed then, the application is said to be completed and the status of property changes to ACTIVE
.
the My Bills screen starting file
The bill is rendered using a keynoteConfig file which .
The implementation of the config .
The bill details screen .
The link for the MDMS
The code .
The response page code .
The search screen is a part of PT module and its code
The Search Result screen code .
The whole function is exposed within the component Registry as getBillDetailsConfigWithBusinessService
and .
All content on this page by is licensed under a .
Url
Role
Action Id
/egov-location/location/v11/boundarys/_search
All Roles
1429
/property-services/property/_search
All Roles
1897
/billing-service/bill/v2/_fetchbill
All Roles
1862
/pt-calculator-v2/propertytax/v2/_estimate
PT-CEMP
1962
/property-services/property/_search
PT-CEMP
1897
/property-services/assessment/_create
PT-CEMP
1933
Url
ROLE
Action ID
property-services/property/_create
PT-CEMP
1895
Citizen
Add Property
Search Property
Edit Property
Assess Property
Re-Assess Property
Pay Property Tax
Transfer Property Ownership
Download Receipts/Applications
Individuals and Community groups
Counter Employee (CE)
Add Property
Search Property
Edit Property
Assess Property
Re-Assess Property
Pay Property Tax
Transfer Property Ownership
Download Receipts/Applications
Counter employees who assist citizens register new property details, transfer ownership of property, pay property tax on their behalf
Document Verifier (DV)
Verify and forward
Send Back
Edit Application
Employees responsible for verifying the supporting documents submitted by citizens for a new property or transfer of ownership of property
Field Inspector (FI)
Verify and forward
Send Back
Reject
Edit
Employees who go on to the field (i.e. location of property) and physically verifies the information provided by the applicant is correct
Approver
Approve
Send Back
Reject
Cancel
An employee who has the final authority to approve or reject the property registration
Url
Roles
Action Id
property-services/property/_update
PT-CEMP
1896
Url
Roles
Action Id
property-services/property/_update
CITIZEN
1896
Url
Roles
Action Id
egov-workflow-v2/egov-wf/process/_search
All Roles
1730
/property-services/property/_search
All Roles
1897
/egov-workflow-v2/egov-wf/businessservice/_search
All Roles
1743
/filestore/v1/files/url
All Roles
1528
S. No.
API
Action id
Roles
1
/access/v1/actions/mdms/_get
870
CITIZEN
3
/egov-mdms-service/v1/_search
954
CITIZEN
4
/localization/messages/v1/_search
1531
CITIZEN
5
/billing-service/bill/v2/_fetchbill
1862
CITIZEN,
6
/pg-service/transaction/v1/_create
1571
CITIZEN
7
/collection-services/payments/_search
1864
CITIZEN
8
/pg-service/transaction/v1/_update
1572
CITIZEN
9
collection-services/payments/PT/_search
2029
PTCEMP, CITIZEN
Objective: To Provide employees with functionality to transfer Ownership of an active property.
When a property is in Active status and has no dues to pay then Employee is given an option on the property details page to mutate a property.
The doc required page is shown if the property is paid for otherwise it is taken to the payment details page. It shows the employee the list of documents required in order to proceed with the form.
After clicking on the “Transfer of Ownership” button on the required page, the employee is redirected to the Transfer of Ownership or Mutation form. Here the Transferor details are displayed and Employee can fill the transferee details form.
The file for mutation can be found on:
MDMS Data Used
Similar to that in employee Property create along with Mutation Documents. Which can be found in:-
APIs Called: 1property-services/property/_update
**When update API is called the documents are updated according to the snippet :-
Here data.originalData
is the property before the update, while data.documents
is the documents that were uploaded in the form, and mutationDocs
is the MDMS response for Mutation Docs.
Acknowledgement Screen
If the Property Mutation is successful. then the employee is directed to this screen that shows the Acknowledgement Id and the option to download a pdf of the acknowledgement containing property details.
Url
Roles
Action Id
property-services/property/_update
PT-CEMP
1896
This section illustrates the steps for different employee user roles at the ULB level
DV is responsible for verifying the supporting documents uploaded by the property applicants or the counter employee on behalf of the applicants.
The DV can
Property applications are rejected if the supporting documents uploaded by the applicant fails to comply with the property regulatory requirements or the details provided in the form are incorrect.
To reject applications navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on Reject.
Enter your Comments to state the reason for rejection. Click on the Upload Files button to upload any supporting documents to validate the rejection. Click on the Reject button.
The applicant will receive a rejection notification on his mobile number or email address.
The DV verifies and forwards the property applications to the Field Inspector if the DV finds all information and documents provided by the applicant correct.
To verify and forward the application navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Verify and Forward button. Select the relevant Assignee Name from the list of available employees for subsequent processing.
Enter any additional information in the Comments field in context to the application for the assignee’s knowledge. Click on Upload Files to upload any supporting documents for the application. Click on the Verify and Forward button.
The property application is assigned to the selected assignee for subsequent processing.
To edit applications navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Edit button. Change any details in the form as required.
The FI can
FI sends back the applications to the citizens if some vital information is missing in the application or there is a mistake in the information provided.
To send applications back to the citizen navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Send Back to Citizen button. Enter any Comments stating why the application is sent back.
Click on the Upload Files button to upload any files or images in context to the application. Click on the Send Back to Citizen button.
The system displays a success acknowledgement message stating that the application is sent back to the initiator.
The FI can send back the PT application to the DV if there is any mistake or lapses in the document verification process.
To send back applications to the DV navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Send Back button.
Select the Assignee Name who will be responsible for verifying the application. Enter any Comments stating why the application is sent back. Click on the Upload Files button to upload any files or images in context. Click on the Send Back button.
The application is assigned back to the selected assignee for verification of documents.
Property tax applications are rejected if the supporting documents uploaded by the applicant fails to comply with the license requirements or the details provided in the form are incorrect.
To reject applications navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on Reject.
Enter your Comments to state the reason for rejection. Click on the Upload Files button to upload any supporting documents to validate the rejection. Click on the Reject button.
The applicant will receive a rejection notification on his mobile number or email address.
The FI verifies and forwards the property applications to the Approver if the information and documents provided by the applicant are correct.
To verify and forward the application navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Verify and Forward button. Select the relevant Assignee Name from the list of available employees for subsequent processing.
Enter any additional information in the Comments field in context to the application for the assignee’s knowledge. Click on Upload Files to upload any supporting documents for the application. Click on the Verify and Forward button.
The property application is assigned to the selected assignee for subsequent processing.
The Approver can
The Approver can send back the property applications to the FI or DV if there is any mistake or lapses in the document verification process.
To send back applications to the DV or FI navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Send Back button.
Select the Assignee Name who will be responsible for verifying the application. Enter any Comments stating why the application is sent back. Click on the Upload Files button to upload any files or images in context. Click on the Send Back button.
The application is assigned back to the selected assignee for verification of application.
Property applications are rejected if the supporting documents uploaded by the applicant fails to comply with the regulatory requirements or the details provided in the form are incorrect.
To reject applications navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on Reject.
Enter your Comments to state the reason for rejection. Click on the Upload Files button to upload any supporting documents to validate the rejection. Click on the Reject button.
The applicant will receive a rejection notification on his mobile number or email address.
The Approver signs off the PT application once the information and documents provided by the applicant are found correct.
To approve the application navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Take Action button available at the bottom of the page. Click on the Approve button.
Select the relevant Assignee Name from the list of available employees for subsequent processing. Enter any additional information in the Comments field in context to the application for the assignee’s knowledge. Click on Upload Files to upload any supporting documents for the application. Click on the Approve button.
The property application is approved.
Functional overview for stakeholders
The Water and Sewerage (W&S) module provides a digital interface to apply for water and sewerage connections and, pay the water and sewerage charges for connection/s. It can be used by the citizens, Urban Local Body (ULB) counter employees and field employees, and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application.
The Water and Sewerage product features can be broadly classified as the following modules:
Registration, Login and Creation of User Profile
Applying for a new Water/Sewerage connection
Searching for a Connection
Modifications to a Connection
Entering meter reading of metered connections
Generate Demand
Payment collection and Receipts
Closure of water connection
Dashboards and Reports
This module provides enables the following capabilities
OTP Based Login for Citizen via Web/Mobile App
OTP Based Login for Employee via Web/Mobile App
Provision for language selection during first time registration for both Employee and citizens
Provision of creating a personalized Profile for Citizens and employees on Web App
Login Credentials for the various hierarchy of employees
Role-based access for performing different actions relating to the W&S module
The system allows the Citizen / ULB user (with an appropriate role in the system) to apply for a New Water/Sewerage connection. The application goes through an approval workflow before it is available for various transactions in the system. The workflow to be followed for a new water/sewerage connection is configurable. In the workflow, the ULB official will generate the estimation notice. Once the payment is made, a work order will be generated.
Every time there is a change in the status of an application, the citizen will be intimated through in-app notifications, SMS and email. The citizen and employee can view the history of the various states that an application has been in and the comments added by the employee in each state of the application.
The employee from the W&S department will be able to access the feature, to search for water and sewerage connections. They can search for any connection based on parameters such as:
Consumer number
Application number
Owner mobile number
Application status
From date
To date
The search result contains, Application number, Consumer number, Owner name, Status, Due amount and Pay now option. The Employee can make payment for a connection on the citizen’s behalf using the ‘Pay Now’ option.
Citizens can also search for their connection in the portal. They can search using the Owners mobile number, Property ID, Consumer number etc. The search result yields, Owner’s Name, Address, Due amount and Pay option.
The system facilitates the title transfer of water tap connection from one person to the other person. Title transfer of water tap connection directly depends upon Property tax. If title transfer is done in the property tax module then at the time of final approval, the changes will reflect in the W&S module automatically. After the title transfer has been completed successfully, subsequent bills will be generated with the details of the new owner/s.
Water tap change in usage happens when property type is changed from residential to Non-residential or from Non-residential to residential. Change in usage directly depends on the property tax module. If the property type is changed in the Property tax system then it will automatically reflect in the W&S system. When there is a change in the usage type, the subsequent bills will reflect the rates as per the updated usage category. When there is a change in the usage category in the middle of the billing cycle, pro-rata charges will be applied in the next billing period.
The change in connection category from non-metered to metered and vice-versa is also possible in the W&S system with the appropriate workflow configured to intimate all stakeholders of the change and collect any charges (if applicable) from the citizen.
On the W&S billing screen, there is a card called ‘Meter reading’. An employee can click on ‘Meter reading’ which redirects the employee to the meter reading landing screen. The employee can search based on the following criteria:
ULB
Boundary Type
Boundary Value
Billing Year
Billing Period
Billing Period Value
Consumer No.
This feature facilitates the employee to search for all results based on desired criteria. The search result yields the following values: consumer number, owner name, meter status, last reading, current reading, date and consumption.
The employee can edit meter status, current reading, date and consumption under certain conditions. Based on this information the employee can generate the bills for connections.
In the system, there is a feature to generate demand under the billing section. Generate demand has a search feature in which, the connections can be searched for which demand has been already generated. An employee can view, also edit those demands based on certain conditions.
The system has the capability to configure the demand generation as an automatic or a manual process. In the automatic process, the demand generation for non-metered connections is automatically done periodically. For metered connection as soon as the employee enters the meter reading and clicks on ‘SAVE’, the demand is generated.
Any success/ failure to generate demand triggers an automatic notification to the concerned ULB officials via email. Also, the demand generation cycle, demand generation date and officials who should receive the notifications can be configured.
The citizen can pay for dues by searching his/her connection. In search results, the citizen can click on pay, which redirects to the summary page of the dues. After this, the citizen can pay for dues online. An employee can also collect the payment on the citizen’s behalf. After searching for the desired connection, clicking on pay will redirect the employee to the common payment page. The employee can print the receipt after the payment is successfully collected. The citizen is also notified and gets a download receipt link in the notification.
If the Water tap owner has got his own water source then the water tap owner can initiate for Water tap connection closure permanently. So, that tap will be closed permanently and demand would not be generated for the connection. Application for the closing of water tap connection is accepted only with the latest water charges receipt and clearing of old dues.
The state-level administrator can keep track of relevant metrics by using dashboards. Dashboards for W&S can be accessed by a state-level user under login. The dashboard has these components:
Financial Indicators
W&S Total collections YTD
Water Collection
Sewerage Collection
Water - Demand vs Collection (Monthly trend)
Sewerage - Demand vs Collection (Monthly trend)
Municipal Adoption
W & S : No. Of ULBs Live
W & S: Total Number of ULBs
Water Consumers by Connection Type
W & S Consumers by Usage Type
Total Collections by Source
Total Collections by Mode
W & S Adoption : ULB Wise
Today’s Collections
W&S Total collections: Today
Water Charges - Total collections: Today
Sewerage Charges - Total collections: Today
W&S - Total No. of Receipts: Today
Water - Total No. of Receipts: Today
Sewerage - Total No. of Receipts: Today
Mode wise W&S collections: Today
W&S ULB wise collections: Today
The table below lists the functionalities supported by the offered product as per the recommendations under the guidelines mentioned under the Ease of Doing Business (EODB) guidelines of 2019.
Obtaining Utility Permits
1
Obtaining Water Connection
Implement an online application system with the following features:
i. Online submission of application without the need to submit a physical copy of the application
ii. Eliminate physical touchpoint for document submission
iii. Allow the option of online payment of application fee
iv. Allow the applicant to track the status of the application online
( Available in DIGIT Platform)
Obtaining Utility Permits
1
Obtaining Water Connection
Display information on tariffs (in Rs. per kL) and notify customers of the change in tariff ahead of the billing cycle (for commercial and industrial users)
( Available in DIGIT Platform)
Obtaining Utility Permits
1
Obtaining Water Connection
Allow users to pay water bills online
( Available in DIGIT Platform)
Learn how to add new property, assess or transfer property and pay property tax
Citizens represent individuals, communities, or business entities who are the system end-users. The PT module allows property owners to register their property details online. These details are then used for various property-related transactions.
The Citizen or CE role can -
Citizens or CE can add new property details through the DIGIT web portal or the DIGIT mobile app.
The system will display the Required Documents - Property Tax list. Note the list of documents valid for address, identity, registration, usage, special category, and occupancy proofs.
Click on the Print button to get a hard copy of the documents list for reference. Click on the Apply button to proceed with adding your property. The form sections are available on the top of the page.
Add Property Form Sections
The add property form page contains various sections that include
Property Address
Property Details
Owner Details
Document Info
Summary
Enter the following information in the Property Address section.
The City field displays the registered city by default. Click on the drop-down list to select a different city. Enter the House/Shop No., Building/Colony Name, Street Name, Locality/Mohalla, and the Pincode. Enter the Existing Property ID in case there is a legacy property ID available for the listed property.
Click on the Next button to move to the next section.
Enter the following details in the Property Details section
Select the applicable Property Usage Type and the Property Type from the drop-down list available.
Check Yes or No to indicate Whether rainwater harvesting structure provided on the property? Enter Vasika No. and Vasika Date if applicable. Enter Allotment Letter No. and Allotment Date if applicable.
Enter Firm/Business Name if the property is listed as commercial or institutional. Enter any information in the Remarks field. Check the box Do you have any inflammable material stored on your property? if it is true. Check the box adjacent to Height of property more than 36 feet? if it is true. Fill in the Unit details if the selected property usage type is Commercial, Institutional, Other Non-Residential, or Residential.
The Unit Usage Type by default accepts the Property Usage Type value. Select the applicable Sub Usage Type for the listed property in case of Commercial or Institutional properties. Select the most applicable option for the type of Occupancy. Enter the Built-up-area (sq ft) value of the property. Select Floor to identify the relevant floor of the property. Click on +Add One More Unit button to add more units.
Click on the Next button to proceed to enter the Owner Details.
Enter the following information in the Owner Details section. Select the relevant Type of Ownership. Enter the Owner’s Name.
Check the applicable Gender of the owner. Enter the owner’s Mobile No. and Guardian’s Name. Select Relationship of the owner with the guardian. Enter the applicable Special Category. Enter the owner’s Email Id and the Correspondence Address. Check the Same as property address box if the correspondence address is the same as the address of the listed property. The Correspondence Address field is auto-populated in that case.
Click on the Next button to move to the Documents section.
Upload the required documents in the Documents section of the application form. In the Select Document field, select the type of document you are uploading for Address Proof, Identity Proof, Registration Proof, Usage Proof, and Construction Proof.
Click on the Upload File button to upload the documents.
Click on the Next button to proceed to the next section.
Click on the Add Property button once the details are reviewed and corrected. The system displays the New Property Successfully Added acknowledgement message.
The Property ID is available along with this message.
Click on the Download button on top of the message box to download the application. Click on the Print button to print the application.
To search for a submitted application or track the status of submitted applications navigate to the Property Tax home page. There are two search options available. Users can search by property or application.
To Search by Property click on the Search Property tab. Enter the ULB. The system displays the registered City or ULB details by default. Enter any of the following search parameters or combinations to refine the search for property. Enter the Owner Mobile No. or the Unique Property ID allotted by the system. Enter the Existing Property ID if there is any legacy ID linked to the property.
Click on the Search button to view the results. Click on the Reset button to renew search with different parameters.
To Search by Application click on the Search Application tab.
Enter any of the following search parameters or combinations to refine the search for property. Enter the Application No. or the Owner Mobile No. or the Unique Property ID.
Click on the Search button to view the search results. Click on the Reset button to renew search with different parameters.
The search results show the filtered list of property entries along with the application Status.
An Active Status means the listed property is pending for further action. Inworkflow status means there is some action going on for the listed property and hence it is not accessible for any other action. Once the action is complete the status will change to Active.
Click on the Unique Property ID or Application No. hyperlink to access the property details.
Listed properties are assessed every financial year to calculate the property tax amount.
To assess property navigate to the Property Tax >> Assess & Search menu option on the sidebar. Alternatively, click on the Property Tax card on the Home page. Enter the required search parameter to refine your search for properties.
Click on the Search button to view the results. Click on the relevant Unique Property ID.
Scroll down the Property Information page to view the property details. Expand the Assessment History panel to view the previous assessment details.
Click on the Re-Assess button if you want to reassess the property. Expand the Payment History panel to view earlier payments made for the listed property.
Click on the Download Receipt button to get a soft copy of the listed payment. Expand the Application History panel to view the property application details.
Click on the View Details button to fetch application details. Click on the Assess Property button.
Select the relevant Financial Year.
The panel will display the Property Tax Amount details.
Click on the Add Rebate button to apply any rebates or discounts on the tax amount. This feature is not available for the citizens.
Enter any Additional Charges amount, if applicable. Select the appropriate Reason for Charges. Enter any Additional Rebate amount, if applicable. Select the appropriate Reason for Rebate.
Click on the Submit button to apply the rebate or charges to the tax amount. Click on the Calculation Details button to view the calculation logic applied for calculating the tax amount.
Click on the OK button to move back to the Assessment page.
Click on Assess Property once you complete reviewing all details. The system will display the assessment success acknowledgement message.
Click on the Proceed to Payment button to pay the property tax. Else click on the Home button to navigate back to the home page.
Applicants have to pay the property tax once the property is assessed for the specified financial year.
To make payment for property tax click on the Proceed to Payment button after the property assessment is complete. The Payment Collection Details panel displays the tax Fee Details.
Enter the payment details. The system allows you to pay by cash, cheque, or credit/debit card. Click on the Cash, Cheque, Credit/Debit Card tab depending on the preferred payment method.
Enter payment details as requested on the screen. Click on the Generate Receipt button to confirm the payment. The screen displays the success acknowledgement message along with the Payment Receipt No.
Once the payment is complete the Property Tax Receipt is issued. Click on the Download or Print button to download or print the tax Payment Receipt.
The PT module allows users to transfer the ownership of property.
To transfer the ownership of property search for the property by entering the Unique Property ID or any other search parameter. Click on the Unique Property ID to open the application. Scroll down the Property Information page. Click on the Transfer Ownership button available in the Owner Details panel.
The system will display the list of Required Documents - Transfer to Ownership.
Click on the Print button to print the list of documents. Click on the Transfer Ownership button to proceed with the mutation process. The Transfer of Ownership form page is displayed.
The application timeline shows three sections -
Transfer Details
Document Upload
Summary
The Transfer Details page includes three panels -
Transferor Details - This panel displays the current owner details.
Transferee Details - This panel requires the user to input the details of the individual to whom the property is to be transferred.
Enter the following details in the form -
Select applicable Ownership Type. Enter the Name, Gender, and Mobile No. of the transferee. Enter Guardian’s Name of the transferee and the Relationship with Guardian. Enter the Email address of the transferee. Select the relevant Special Applicant Category. Enter the Correspondence Address of the transferee.
Registration Details - This panel requires the user to input the registration details in context to the transfer of the property ownership.
Enter the following details in the form.
Select Reason for Property Transfer. Enter Property Market Value, the Registration Document No. and the Registration Document Issue Date. Enter the Registration Document Value. Enter any Remarks.
Click on the Next Step button to move to the Document Upload section.
Select Document you want to upload for Address Proof, Identity Proof, and Registration Proof. Click on the Upload File button to upload the copy of scanned documents.
Click on the Next Step button to move to the Summary section.
The Summary page will display the filled-in application details. Scroll down the page to review the information entered. Click on the Previous Step button to go back and make any changes in the form.
Click on the Submit button once all details are reviewed. The screen will display the application success message. Click on the Download button on top of the message box to download the application. Click on the Print button to print the application.
To make any changes in the application navigate to the Home page. Search for the application you want to verify by entering any of the search parameters. Click on the Application No. to open the application. Scroll down the form to review the filled in details.
Click on the Edit Property button available at the bottom of the page. Change any details in the form as required. Click on the Update Property button once all changes are complete.
App to facilitate application for new W&S connections, pay bills, activate connections, generate bills
The Water & Sewerage module offers a consolidated platform for managing new and existing water and sewerage connections. The module eliminates the need for manual processing and streamlines the key water or sewerage management functions for operational efficiency. DIGIT Water & Sewerage (W&S) module enables automated processing of new connection requests, generating water bills, and facilitating online payment of bills.
DIGIT W&S module enables citizens to -
Apply for new sewerage or water connections
Upload documents required for processing new connections
Pay water or sewerage connection charges and bills using an online payment gateway
Receive SMS alerts on application status, bills generated, payment due date, and payment receipt confirmation
Download water or sewerage connection approval letter, payment receipts, and bills online
DIGIT W&S module enables employees at ULB and State level to -
Process applications using customizable workflows
Configure water and sewerage charges, interest, and penalty calculation logic
View custom dashboards for module statistics
Filter search results using advanced configurable search parameters
This section contains all docs and information required to understand the W&S module, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the W&S module.
W&S Roadmap
Product Brochure
W&S Workflows
W&S Service Configuration
Demo Script
Navigation Tips
Click on the embedded links within the content to browse topic details
Use the Contents links available on the right side of the screen to move to a specific heading
Find the list of Related Docs links at the bottom of each page to browse through additional product details
Reach out to us through any of the below-mentioned contact channels for any assistance or additional information on W&S module deployment.
#147/J, 1st floor, 10th Cross, 12th Main, 3rd Block, Koramangala, Bangalore 560034
+91 80 4125 5708
contact@digit.org
Migrating legacy data
This section covers the principles eGov will be following for migrating legacy property registry along with demand and collection balances to the DIGIT system (currently in Uttarakhand but can be used for other clients in future). eGov has been successful in implementing property tax applications in states of Andhra Pradesh, Punjab and various other Municipal Corporations like Greater Chennai, Nagpur and so on using best practices defined here.
The state team is supposed to take care of the below activities before property data is shared to eGov for data migration:
State team to share all master data and its localization that are part of the property tax. For example masters like - city, boundary, usage type, property type and so on
State team to do the data gathering and prepare the property tax data in the predefined template shared by eGov
Data prepared needs to be scrutinised by the data owner from the State’s team. Following data validations to be considered in particular:
Validate if all sheets have accurate records (owner details, property details and DCB details, Floor details) in terms of what is expected
DCB details can be more than the number of records in the property sheet
There can be multiple owners for a single property. But there needs to be an owner and DCB for each of the properties
Have a check on all mandatory data present
All sheets to be aligned with the unique id field
The state has to share the complete set of property data for a city in a single go. They can also give one set for residential properties and another for commercial properties, but cannot give multiple sets for the same.
Data owner to give a sign off on data before handing over to eGov team
State team to be aware of assumptions and default values that will be applied as part of the data migration process. This will be shared by the eGov team
UAT and production environment where the data is to be loaded to be provisioned and set up
Data received from the State team will be cleansed by eGov with default values
Mandatory fields that have no financial impact on citizens can be filled with default values in the absence of values specified by the State team. Few examples are listed below -
Covered areas can be updated as 0
Road type as 12 meters
The number of floors can be updated as 1
Certain fields that have a financial impact can also have default values like tax amount in the absence of values specified by the State team. (It can be updated as Rs.1)
If the mobile number is blank, a dummy mobile number will be updated. Care will be taken to ensure that this is not an actual mobile number and this number will be removed from notifications. Dummy numbers can be something like 99999xxxxx where the first few dummy numbers in a state will be 9999900001, 9999900002, 9999900003 so on.
Follow the below assumptions to do data cleaning
If the mobile number and user name combinations are duplicating we will consider these properties belong to the same owner. This means one user will be created in the system which will have a link to two properties.
Have a marker if any assumptions and default values are applied on a record
Certain data are currently not assumed or defaulted. Below listed are a few cases -
Owner details completely not available for a property - If complete owner details are missing, these records to be kept in the not to be migrated list.
If DCB is not there or given for a range of years - since there are a lot of use cases here, we can keep this record in the not to be migrated list
Duplicate old property id - leave the data as it is and then edit it later using the data entry screen
If boundary data is not present or data not aligned with the master data shared - update to a default mohalla which the state agrees to
Door number is not present - update the value as “door number”
Owner Name blank in the owner details sheet - update the value as “owner”.
Load the records using property migration kit to UAT server
Prepare a list of all passed and failed property records and share them back with the State team. Passed records along with values defaulted will be shared.
If the State team wants eGov to retry all failed records they are expected to come back with the revised data within one week.
Repeat Step 1 for revised records received from the State team.
The final status of the data load will be shared with the State team.
State team to verify data loaded on UAT server and provide a sign off for each of the ULBs within 1 week
On getting sign-off of UAT data, eGov will load that data to production using the migration kit used for loading to UAT instances. This can be done only if the production infrastructure is ready.
Get sign off on the production data before the application can be made live.
Roorkee
16363
500
97%
3%
Rishikesh
2877
356 in the first sheet
261 in the second pass
88%
91%
12%
9%
Communication for data migration exercise can be split into the following stages:
There will be a SPOC from the State team who is the data owner who will share data with the eGov team. Excel sheet data will be put on google drive and shared with the project manager from eGov. Similarly, all communications from the eGov side to State will be routed through the project manager.
Pre-migration
A demo of how PT module works - State + ULBs
Product fitment discussion, configurable data finalization and sign off - State
An overview of how data migration works - State + ULBs
Sharing the template (along with checklists and FAQs) in which we will collect data and type of data required against each field along with training - State + ULBs
Sharing assumptions which will be followed while migrating data - State + ULBs
During migration
Data inconsistencies observed in Data cleaning stage - State
Gaps needed to complete data migration (like mohalla mapping) - State
List of records which will be migrated as-is and the ones which will be migrated with assumptions - State
Post-migration
List of properties migrated without error - State
List of properties migrated with error for ULBs manual entry - State
UAT Sign-off document - State + ULB
Final confirmation post migration on Production - State + ULB
All failed records from the second pass will be manually entered into the system using data entry screens
The state has to make a mandate to collect property tax only using DIGIT.
All records with assumption markers or incorrect data can be updated by counter employees when citizens come for payment. Maybe this option can be given to the citizen when coming for online payment.
When a citizen is coming for making his payment, the counter operator can check if their property exists in the system using propertyid or mobile number. If it is found to be missing, it can be captured afresh in the system using the data entry option. All required information can be obtained from the citizen, either from previous year receipts that they carry or directly asking them.
With this approach, a ULB can go live with 90% of property data within a short time.
Data Migration Checklist
Data provided in the standard template attached only will be accepted for further analysis and process.
Data provided into the template is loaded into staging tables and then validation and data clean-up is done.
Properties with current Tax 0. (2020-21)
Properties with advance collection
Properties with current tax partially payment
Properties with Mohalla not configured in master
Masters mapping with the configured masters data in the system.
All the findings of data are reported to the onsite team and sought clarification.
Once all the queries/ findings are cleared/addressed data is moved into UAT.
Data is verified into UAT with sampling by the state team. Go ahead.
Preparing some basic checkpoints before moving into production.
Move the data into production and verify the checkpoints.
Water service is the egov application, which helps and gives flexibility to municipal and citizen to handle the water service like apply for water connection, search water connection. The application will go on different stages that the state can verify by given roles, If that role can take the action then the application will go to the next state. Based on the state, a citizen will get a notification (SMS and in-app ). Citizens also can pay for application fees or employees can collect the fee for the application.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has water service persister config path added in it
PSQL server is running and database is created to store water connection / application data
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service will be helpful.
Apply for a water connection.
Searching for water connections.
Apply for Property creation.
Can take different action based on state (Workflow)
Notification based on the application state.
Environment Variables
Description
egov.waterservice.createwaterconnection
This variable contains the kafka topic name which is used to create new water connection application in the system.
egov.waterservice.updatewaterconnection
This variable contains the kafka topic name which is used to update the existing water connection application in the system.
egov.waterservice.updatewaterconnection.workflow.topic
This variable contains the kafka topic name which is used to update the process instance of the water connection application.
egov.idgen.wcapid.name
This variable contain the idgen format name for water application
egov.idgen.wcapid.format
This variable contain the idgen format for water application ex:- WS/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]
egov.idgen.wcid.name
This variable contain the idgen format name for water connection
egov.idgen.wcid.format
This variable contain the idgen format for water connection ex:- WS_AP/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]
To Do
Table UML diagram
****
MDMS configuration
master-config.json for water service
Property creation through WNS module https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/PTWorkflow.json
Persister configuration
https://github.com/egovernments/configs/blob/DEV/egov-persister/water-persist.yml https://github.com/egovernments/configs/blob/master/egov-persister/water-meter.yml
Actions
Role Action Mapping
Workflow business service config
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for water service
Workflow for property creation through Water and Sewerage Module
Indexer config for water-service
The indexer provides the facility for indexing the data to elastic search. https://github.com/egovernments/configs/blob/DEV/egov-indexer/water-service.ymlhttps://github.com/egovernments/configs/blob/DEV/egov-indexer/water-services-meter.yml
Setup
Write the configuration for water service. https://github.com/egovernments/configs/blob/DEV/egov-indexer/water-service.ymlhttps://github.com/egovernments/configs/blob/DEV/egov-indexer/water-services-meter.yml
Provide the absolute path of the checked-in file to DevOps, to add it to the file-read path of egov-indexer. The file will be added to the egov-indexer's environment manifest file for it to be read at the start-up of the application.
Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.
Modify connection
After connection activation or legacy connection, we can edit the connection. This process based on a defined workflow. Any action is based on defined roles on the action level. For edit connection, we need to upload some supporting documents and mandatory info.
Workflow config for edit connection
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for editing the water connection.
Notification
Notification will be sent to the property owners and connection holders based on different application states.
Capturing connection holders
We can add connection holders to the water connection which will be the owner of the connection. We can fill in the connection holders' details or we can just make the property owner to the connection holder.
The connection holder will get a notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.
Multiple Road Type Support We can add road cutting details of multiple roads to the water connection. For each road that goes undercutting process, we have to fill their road type details and road cutting area. Based on this information, the application one-time fee estimate is calculated.
Add MDMS configs required for water connection registration and restart MDMS service.
Deploy the latest version of ws-services service.
Add water-service and water-services-meter persister yaml path in persister configuration and restart persister service.
Add Role-Action mapping for API’s.
Create businessService (workflow configuration) according for trade water connection, modify water connection
Add ws-service indexer yaml path in indexer service configuration and restart indexer service.
This ws-service module is used to manage water service connections against a property in the system.
Provide backend support for the different water connection registration process.
Mseva and SMS notifications on application status changes.
Elastic search index for creating visualizations and Dashboards.
Supports workflow which is configurable
To integrate, host of ws-service module should be overwritten in helm chart.
/ws-services/wc/_create should be added as the create endpoint for creating water application/connection in the system
/ws-services/wc/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
/ws-services/wc/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
Title
Link
API Swagger Documentation
Water Calculator Service
Title
Link
/ws-services/wc/_create
/ws-services/wc/_update
/ws-services/wc/_search
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
Access to clean and safe water is one of the basic needs of citizens. Each Urban local body has been mandated with catering to the water and sanitation needs of its citizens. The computerized and automatic Water and Sewerage system offered by eGov enables citizens who seek to apply and pay for water and sewerage connections within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. The ULB officials can now sanction connections, generate bills and collect payments for water and sewerage connections more efficiently. (For details on product features refer to Section-2)
For the offered product, the implementation process can be divided into six major distinctive stages. Each stage has predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. The whole implementation lifecycle is typical of 23-27 weeks for the State/UT keeping in mind the entry, and exit criteria defined at the beginning and end of each stage are met on time recommended.
Stage Zero-program setup and onboarding is a pre-requisite for the initiative to kick-off and requires setup of the governance model, implementation team and decision regarding other significant elements of the initiative like funding and procurement process. Stage One of the initiative requires scoping of the initiative and decide on the priorities for implementation by the State/UT implementation Team. In Stage Two, the W&S team is appointed and its processes are standardized. In Stage Three, the State/UT Team will work upon identifying and finding solutions to the significant gaps in the product offered w.r.t. to the need of the State/UT. Configuration and customization of the product offered in the primary objective of stage four. This involves working on various aspects of UT-specific needs and incorporating them into the product suite offered. In Stage Four and Five, post doing UAT and including all the necessary feedback on the product, the roll-out of the product is done at the State/UT level(Go Live) from a couple of ULBs to pan State/UT coverage. In Stage Six of sustenance and ongoing improvement, key activities are adoption and governance tracking with the planning of ongoing sustenance. (For details on implementation plan refer to Section-3).
Implementation of Water and Sewerage (W&S) requires meticulous planning and close coordination between various stakeholders at the centre and State/UT level. The success of the initiative is dependent upon many factors like strong Program governance, availability of the trained resource, financial planning, targeted implementation Team onboarding, focus on last-mile capacity building and ensuring necessary support to the urban centre. Achievement of all these factors will provide the most effective and efficient roll-out and adoption of the Water and Sewerage Implementation System in the UT.
The Water and Sewerage (W&S) module provides a digital interface to apply for water and sewerage connections and pay the water and sewerage charges for connection/s. It can be used by the citizens, Urban Local Body (ULB) counter employees and field employees, and ULB Administrators to accomplish their specific tasks. It is available as a mobile and web-based application. The W&S product features can be broadly classified as the following modules:
Registration, Login and Creation of User Profile
Application for new Water/Sewerage connection
Searching for a Connection
Modifications to a Connection
Entering meter reading of metered connections
Generate Demand
Payments collection and Receipts
Dashboards and Reports
This module provides enables the following capabilities:
OTP Based Login for Citizen via Web/Mobile App
OTP Based Login for Employee via Web/Mobile App
Provision for language selection during first time registration for both Employee and
citizens
Provision of creating a personalized Profile for Citizens and employees on Web App
Login Credentials for the various hierarchy of employees
Role-based access for performing different actions relating to the W&S module
The system allows the Citizen / ULB user (with an appropriate role in the system) to apply for a New Water/Sewerage connection. The application goes through an approval workflow before it is available for various transactions in the system. The workflow to be followed for a new water/sewerage connection is configurable. In the workflow, the ULB official will generate the estimation notice. Once the payment is made, a work order will be generated.
Every time there is a change in the status of an application, the citizen will be intimated through in-app notifications, SMS and email. The citizen and employee can view the history of the various states that an application has been in and the comments added by the employee in each state of the application.
Only employees from the W&S department will be able to access the feature, to search for water and sewerage connections. They can search for any connection based on parameters such as:
Consumer number
Application number
Owner mobile number
Application status
From date
To date
The search result contains the Application number, Consumer number, Owner name, Status, Due amount and the Pay now option. The Employee can make payment for a connection on the citizen’s behalf using the ‘Pay Now’ option.
Citizens can also search for their connection in the portal. They can search using the Owners mobile number, Property ID, Consumer number etc. The search result yields, Owner’s Name, Address, Due amount and Pay option.
The system facilitates the title transfer of water tap connection from one person to the other person. Title transfer of water tap connection directly depends upon Property tax. If title transfer is done in the property tax module then at the time of final approval, the changes will reflect in the W&S module automatically. After the title transfer has been completed successfully, subsequent bills will be generated with the details of the new owner/s.
Water tap change in usage happens when property type is changed from residential to Non-residential or from Non-residential to residential. Change in usage directly depends on the property tax module. If the property type is changed in the Property tax system then it will automatically reflect in the W&S system. When there is a change in the usage type, the subsequent bills will reflect the rates as per the updated usage category. When there is a change in the usage category in the middle of the billing cycle, pro-rata charges will be applied in the next billing period.
The change in connection category from non-metered to metered and vice-versa is also possible in the W&S system with the appropriate workflow configured to intimate all stakeholders of the change and collect any charges (if applicable) from the citizen.
On the W&S billing screen, there is a card called ‘Meter reading’. An employee can click on Meter reading which redirects the employee to the meter reading landing screen. The employee can search based on the following criteria:
ULB
Boundary Type
Boundary Value
Billing Year
Billing Period
Billing Period Value
Consumer No.
This feature facilitates the employee to search for all results based on desired criteria. The search result yields the following values: consumer number, owner name, meter status, last reading, current reading, date and consumption.
The employee can edit meter status, current reading, date and consumption under certain conditions. Based on this information the employee can generate the bills for connections.
In the system, there is a feature to generate demand under the billing section. Generate demand has a search feature in which the connections can be searched for which demand has been already generated. An employee can view, also edit those demands based on certain conditions.
The system has the capability to configure the demand generation as an automatic or a manual process. In the automatic process, the demand generation for non-metered connections is automatically done periodically. For metered connection as soon as the employee enters the meter reading and clicks on ‘SAVE’, the demand is generated.
Any success/ failure to generate demand triggers an automatic notification to the concerned ULB officials via email. Also, the demand generation cycle, demand generation date and officials who should receive the notifications can be configured.
The citizen can pay for dues by searching his/her connection. In search results, the citizen can click on pay, which redirects to the summary page of the dues. After this, the citizen can pay for dues online. An employee can also collect the payment on the citizen’s behalf. After searching for the desired connection, clicking on pay will redirect the employee to the common payment page. The employee can print the receipt after the payment is successfully collected. The citizen is also notified and gets a download receipt link in the notification.
If the Water tap owner has got his own water source then the water tap owner can initiate for Water tap connection closure permanently. So, that tap will be closed permanently and demand would not be generated for the connection. Application for the closing of water tap connection is accepted only with the latest water charges receipt and clearing of old dues.
The state-level administrator can keep track of relevant metrics by using dashboards. Dashboards for W&S can be accessed by a state-level user under login.
The dashboard has these components:
Financial Indicators
W&S Total collections YTD
Water Collection
Sewerage Collection
Water - Demand vs Collection (Monthly trend)
Sewerage - Demand vs Collection (Monthly trend)
Municipal Adoption
W & S: No. Of ULBs Live
W & S: Total Number of ULBs
Water Consumers by Connection Type
W & S Consumers by Usage Type
Total Collections by Source
Total Collections by Mode
W & S Adoption : ULB Wise
Today’s Collections
W&S Total collections: Today
Water Charges - Total collections: Today
Sewerage Charges - Total collections: Today
W&S - Total No. of Receipts: Today
Water - Total No. of Receipts: Today
Sewerage - Total No. of Receipts: Today
Mode wise W&S collections: Today
W&S ULB wise collections: Today
This section provides an overview of the methodology for State-wide implementation of W&S. The Implementation of W&S is distributed across seven distinct stages. Each stage has predefined entry & exit criteria and roles & responsibilities. This is to ensure objective monitoring and decision making for the overall success of the program. Details of each stage are defined in this section.
W&S implementation program is expected to be completed approximately between 38- 42 weeks with the resource deployment by the State and System Integrator (SI) Team (as defined below). However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.
There is a set of initial critical activities that are undertaken on receiving a letter of Enrollment from the State/Union Territory. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator(SI) Teams and funds.
Duration
4-6 weeks
Entry Criteria
Acceptance Letter/MoU by State
Exit Criteria
Finalize Water and Sewerage Program Vision
Finalize funding for the program
Define State/Union Territory -specific procurement process
Water and Sewerage Cell appointment. Consisting of :
Domain expert
Nodal officer (EO/ Commissioner/ Senior Official)
Program Head
System Integrator(SI) Team sign-up/onboarding
Define the value proposition of the programme for the state
Define the time frame within which the state needs to:
Go live
Scale pan-state
Define Year-on-Year(YoY) Financial Targets
System Integrator(SI) Sign-up:
System Integrator and state will agree on program scope, program timelines, and budgeting & resourcing.
This stage envisages the in-person interaction of crucial State/UT officials and implementation System Integrator(SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different stakeholders. The principal objective of these interactions is to identify scope, plan strategies for phasing/rollout (in pilot ULBs/Pan State) and create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.
Duration
4-6 weeks
Entry Criteria
Program setup (Stage 0) is complete
SI Team signed-up
Key Activities
Project kick-off meeting and stakeholders consultation
Identify & agree on scope and exclusions
Finalize the approach on obtaining the W&S Connection Legacy Data (At least from the Pilot ULBs)
Identify pilot ULBs
Product Walkthroughs
Define Project Steering Committee Structure and Project Governance process
Define phases of rollout/ deployment
State Baseline Data (As per the Module)
Pilot ULBs Specific Product Data Configuration
Agreement on Product Feature Priorities and high-level delivery timelines
Assessment of all on ground W&S process along (1) citizen services/channels around it (2) Integration with other Department process
Finalize Program Success Metrics for Rollout and Adoption and Governance adhering to the vision of the program
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Exit Criteria
Publish the program charter
Implementation plan agreement with priority applications and broad timelines
Program Governance Model
Program Success Metrics
Capacity Building
W&S Cell formation and appointment
Finalizing the strategy for W&S Connections Legacy Data
Master Data preparation/collection kickoff from Pilot ULBs
Cloud Infrastructure procured
Project Office Space allocated
Program Branding( Name, Logo, Tagline etc.)
During the Solution design stage, key State/UT officials and members, who are subject matter experts, are expected to share State/UT acts and policies and help interpret the same for the System Integrator (SI) Team. This stage baselines the State/UT-specific product features in the Product Configuration report.
Duration
4-6 weeks
Entry Criteria
Program Charter
W&S Cell appointment
Key Activities
Standardization of all W&S processes, if needed
Initiate policy change and Process Re-engineering, if needed based on identified improvements
Conduct Product familiarization workshop
Initiate collection of Master Data (Legacy & Product Based) from pilot ULBs
Finalize data migration/collection/sync-up approach (State needs to provide a signoff)
Finalize data validation approach (State needs to provide a signoff)
Building capacity for basic understanding of resources and tools required to be used
Exit Criteria
Publish the W&S processes, data template/workflows (State needs to provide a signoff)
Finalization of Roll-out plan(in different phases)
Solution agreement for required state/UT-specific customisations
Finalization of Initial Reporting and Design (State needs to provide a signoff)
Finalization of Dashboard KPIs (State needs to provide a signoff)
Sign-off on data approach( Data collection/migration/correction/sync-up/validation) from the state
Detailed project plan
This stage consists of a series of developments in accordance with the detailed project plan to ensure the smooth functioning of the customised product. Preparation for the testing and data collection of the product UAT is complete. Further monitoring and maintenance strategies are put in place.
Duration
6-8 weeks
Entry Criteria
Product Configuration Report has been Signed Off by the State/UT
Detailed Project Plan set up in accordance with master data collection and environment setup
Key Activities
Setting up development environments
Development/customization of reports and dashboards
Development/Integration of portal
Third-Party Integrations (Payment gateway, Handheld/pos device)
Updation of user manuals and other key documents
Preparation & execution of Test Cases
Setup monitoring, support & maintenance processes and tools
W&S and Legacy data collection from Pilot ULBs (at least)
Training for basic understanding of resources and tools required to be used (system-related)
identify ULB level nodal officers for day to day support
Legacy Data Validation signoff from the state on Data Validation
Post this migration exercise will be taken up for water/sewerage connections
Migration and verification of Pilot ULB data as per data provided by the State
Exit Criteria
Data Validation Signoff by the state, post which the Legacy Data will be uploaded to UAT
Configured/Customized product that is ready for UAT
Monitoring, support & maintenance of Dashboards
finalization of Initial Reporting and Dashboard KPIs
During this stage, a demonstration of the product followed by a hand on session is conducted for the ULB officials. Necessary training of ULB officials and resources required for UAT is conducted and identified respectively. The establishment of the State/UT support Team and required processes are initiated in this stage.
Duration
2-3 weeks
Entry Criteria
Configured/Customized product ready for UAT
Pilot ULB Officials (Associated with W&S) are available for UAT & Training
Key Activities
UAT Environment Setup
Sign off from Pilot ULBs on the Migrated Connection Legacy Data during UAT
Issues/bug identification and resolution
Regression UAT and Sign off from Pilot ULBs/ State
Setting up the Production environment
Setting up Support Center & processes (Help Desk)
Training (Users, trainer)
master trainers identified from the ground for simultaneous training
Training the Support Resources
Marketing & promotion activities
Go Live & launch event
Setup of review and monitoring cadence/team
Usage/review/Dashboard/Field Visits
Exit Criteria
UAT Sign-off & Go Live for Pilot ULBs
Setup of review and monitoring cadence
On successful Go-Live in the Pilot ULBs, after further configurations to stabilize the product, the solution will be rolled out to the rest of the ULBs in multiple phases. Guidance and support from the State/UT Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.
Duration
5-6 weeks
Entry Criteria
The pilot has been successful in the State/UT
there are less than 3 open critical incidents (issues) with respect to product, implementation and data
Key Activities
ULB configurations phase-wise as per the Project Plan
Phase wise migration and verification of ULB data (as per the Data Agreement signoff, provided by the State)
Logistics planning for training
Establishment of bug ticketing tool for resolving ground-level issues by the state team
Training the Users at the district level
Pan State Roll-Out - Phase wise
Stabilise product
Exit Criteria
State/UT wide Rollout in batches:
Adoption tracking & Review Cadence operational
Help Desk Effectiveness assured
Critical Bugs fixed
Program Success Metrics Tracking Kick-started
The final stage consists of strategies to ensure the sustenance of the product in the State/UT. Systems are put in place to ensure the continuous tracking of data and provisions are made to improve the product if new data suggest.
Duration
Ongoing process
Entry Criteria
Rollout Phase 1( First set of 30 ULBs where rollout will happen after Pilot)
Key Ongoing Activities
Adoption Review Meetings as per the vision defined for the program
W&S Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around W&S to make processes more robust towards enhancing W&S revenues (e.g Upstream and downstream Processes)
Conduct Weekly Review Meeting between ULBs, State Team for feedback on the system, which must be chaired by the Program Head
Plans of ongoing Sustenance in Place with respect to :
Funding
IT support (infra, helpdesk, ongoing enhancements)
Process Effectiveness and Improvements
This section outlines the activities involved in each stage of the implementation along with the responsibility and accountability of critical stakeholders - UT, NUS Team and System Integrator Team onboard.
W&S Cell: W&S Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from Urban Development Department etc.
Resource requirements for the W&S cell required to be formed by the UT
Project Head
1
Domain Expert
2
Nodal Officer
2
MIS Expert
4
Project Head: Is the Head of the W&S Cell who will drive the project from the State/UT Side
Domain Expert: Person who is well aware of the on-ground scenario, well versed with the act, GOs passed, Prevalent Business processes, Deviations from the acts, Rates/ slabs applicable
Nodal officer (EO/Commissioner/ Senior Official): the product coordinator to drive the project centrally. Monitor usage post Go Live- point of escalation for Implementation Team, Seasoned and worked in Multiple ULBs on various modules and has a good understanding of W&S, Facilitate and Track data collection Post Go Live, Monitors and facilitates the adoption of the application. point of contact for eGov, SI and at the HQ level.
MIS Expert: Day to day tracking of the program, data entry, reporting and review to senior officials
eGov Team: eGov Team is the technical partner of the project which will provide all necessary support to the State/UT concerning the implementation, Program Designing etc.
System Integrator (SI) Team: SI Team will be responsible for the rollout of the initiative in the UT, providing end to end support to the State/UT w.r.t. The implementation of the products in the ULBs.
Guidelines to read the table are mentioned on the next page:
Execute - One who owns the accountability to complete the activity
Consult - One who may initiate, guide and in the process, handhold the execution of the activity
Task/Activity
eGov
State Leadership
Appoint W&S Cell
Consult
Execute
Finalize funding for the program
Consult
Execute
Define state/UT-specific procurement process
Consult
Execute
System Integrator(SI) Team sign-up/onboarding
Consult
Execute
Finalize Water and Sewerage Program Vision
Consult
Execute
Note: Stage 0 is where the W&S cell and SI team are formed, hence there are only two entities playing a role which is that of eGov and the state leadership. Once the W&S cell and SI team are finalized, their role begins in the following stages.
Task/Activity
eGov
W&S Cell
SI Team
Identify & agree on scope and exclusions
Consult
Consult
Consult
Identify pilot ULBs
Execute
Consult
Project kick-off meeting and stakeholders consultation
Execute
Consult
Product Walkthroughs
Consult
Execute
Define Project Steering Committee structure and Project Governance process
Consult
Consult
Execute
Define phases of deployment/ rollout
Consult
Consult
Execute
Agreement on Product Feature Priorities and high-level delivery timelines
Consult
Execute
Assessment of all W&S process along
(1) citizen services/channels around it
(2) Integration with other department processes
Consult
Execute
Finalize Program Success Metrics for Adoption and Governance adhering to the vision of the program
Consult
Execute
Internal Capacity Building, program logistics at State and ULBs, as per the current scenario
Execute
Consult
Task/Activity
eGov
W&S Cell
SI Team
Standardisation of all W&S processes, if needed
Consult
Execute
Initiate policy change and Process Re-engineering, if needed based on identified improvements
Consult
Execute
Consult
Conduct Product familiarization workshop
Consult
Consult
Execute
Initiate collection of master data from pilot ULBs
Consult
Execute
Finalize data migration/collection/sync-up approach
Consult
Execute
Finalize data validation approach
Execute
Consult
Building capacity for basic understanding of resources and tools required to be used
Execute
Consult
Task/Activity
eGov
W&S Cell
SI Team
Setting up development environments
Consult
Execute
Development/customization of reports and dashboards
Consult
Execute
Development/Integration of portal
Consult
Execute
Third-Party Integrations (Payment gateway, Handheld/pos device)
Consult
Execute
Updation of user manuals and other key documents
Consult
Execute
Preparation & execution of Test Cases
Consult
Execute
Setup monitoring, support & maintenance processes, tools and dashboards
Consult
Execute
Data Migration for Pilot ULBs(at least)
Consult
Execute
Training for basic understanding of resources and tools required to be used (system-related)
Execute
Consult
Legacy Data Validation signoff from the state on Data Validation
Execute
Consult
Task/Activity
eGov
W&S Cell
SI Team
UAT Environment Setup
Consult
Consult
Execute
UAT Testing
Consult
Execute
Issues/bug resolution
Consult
Execute
UAT Sign off from Pilot ULBs
Execute
Consult
Setting up the Production environment
Consult
Execute
Setting up Support Center & processes (Help Desk)
Execute
Consult
Training (Users, trainer)
Execute
Consult
Training the Support Resources
Consult
Execute
Marketing & promotion activities
Execute
Consult
Go Live & launch event
Execute
Consult
Setup of review and monitoring cadence/team Usage/ review/Dashboard/Field Visits
Execute
Consult
Task/Activity
eGov
W&S Cell
SI Team
ULB configurations
Consult
Execute
Phase wise Migration and verification of ULB data
Execute
Consult
Logistics planning for training
Execute
Consult
Training the Users at the district level
Execute
Consult
Roll Out - All Locations
Consult
Execute
Execute
Stabilize product
Consult
Execute
Task/Activity
eGov
W&S Cell
SI Team
Adoption Review Meetings as per the vision defined for the program
Consult
Execute
Consult
W&S Cell Focuses on Using data for:
tracking field issues and performance data to identify improvements
identify additional Integrations around W&S to make processes more robust towards enhancing W&S revenues (e.g Upstream and downstream Processes)
Execute
Consult
Conduct Weekly Review Meeting between ULBs, State Team for feedback on the system, which must be chaired by the Program Head
Execute
Consult
Plans of ongoing Sustenance in Place with respect to :
Funding
IT support
Process Effectiveness and Improvements
Consult
Execute
Consult
Infrastructure
The actual Infra will be provided based on the questionnaire inputs received from the state
The state will take care of providing necessary project infrastructure and office facilities during the program for all on-site project Team members, which will be confirmed during the initiation phase. This includes workspace, office equipment (e.g., telephone with STD, fax machine, photocopy machine, etc.), stationery, PC/workstation, project LAN and internet access, etc.
The state will provide the necessary administrative support staff to carry out day-to-day project administration tasks, e.g., meeting rooms, Videoconferencing, etc.
The state should provide a Project Office and at least one conference room with a speaker phone throughout the Project Duration.
Project Scope
Any new requirements received from the State during the implementation phase will be handled through a change management process
State Team
The state will nominate a reasonably sized multifunctional Team from various departments of the State to be responsible for the implementation. The state Team would be required for information, validation, and execution through the implementation cycle and the Team members should be reasonably empowered to take decisions. Any delay in the decision-making process and the non-availability of the State Team may have an impact on the schedule.
The participants from State are expected to have a thorough understanding of the State’s internal processes.
The state will engage internal and external stakeholders required for this engagement and ensure their availability whenever needed.
Documentation
User education and training documentation will be delivered as per the default product documentation of the identified product versions.
The product manuals are expected to be shared with the State as part of the user manual.
All documentation would be in English only.
Training
Training to the end-users will be driven by the state Team.
The state will be responsible for providing the necessary infrastructure required for the Training, which includes the following readiness.
Training Rooms (Parallel Training Sessions) with Projector, White Board, Markers, Internet Connection, sufficient seating capacity, Desktop/Laptop for each participant and availability of Network for Trainees to connect to the server.
Implementation
The scope of the implementation will be limited to the services mentioned in Section 2.
eGov Team will have an identified SPOC for handling the first level of communication with the client unless discussed and agreed upon.
eGov Team will not be involved in defining the test cases or executing the test cases.
Necessary signoff would be provided by the state upon completion of the defined milestones.
Vision: Defining the time frame to go live, the time frame to scale it pan state, the value proposition of the programme for the state and year-on-year financial targets and adoption targets
Project Plan: A detailed plan of Program schedule/timelines, implementation phases, team structure and ongoing support and maintenance required.
System Integrator: The Entity/Company which collates all the subsystem required for the project and integrates them to achieve the program objective
Program Charter: Outline of implementation plan agreement with priority applications and broad timelines, program governance model, program success metrics and capacity building.
Acceptance Letter/MOU: Formal Acceptance/Sign Off of the Client State with a clear mandate of the Program
Program Success Metrics: Defining the parameters (which are measurable) prior to the program, on which the success of the program is to be measured on the completion of the program
Project steering committee: The key body within the governance structure which is responsible for the business issues associated with the project that are essential in ensuring the delivery of the project outputs and the attainment of project outcomes.
Project governance: Set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programmes and portfolios.
Scoping: List of activities measured against the time taken to complete them in accordance with the project goals
Baseline data: Set of information that serves as a foundation to compare other data acquired afterwards
Project Kick-off meeting: Meeting with the project team and the client of the project. This meeting would follow the definition of the base elements for the project and other project planning activities
Fitment Study: GAP Study of the Existing/Required Field Process Vs Product
Data migration: Existing Records of the functional activities need to be moved into the Database of the newly released Application
Data collection: Required data for the roll-out of the applications, which needs to be collected from the existing functional process
Data validation approach: This approach enables the sanctity of the Data with built-in validation by Design
Data synchronization: The process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.
Pilot Implementation: Any new process is tested out as a pilot in one or two instances before pan implementation
Pilot ULB: The ULBs selected for the pilot implementation are called pilot ULB.
Roll out: On successful clearance of the Pilot, the Process/Application/Services are implemented across all Offices/ULB's
Deployment: Deployment defines the complete package of Software components set up in a particular environment
Customisation: Details of changes to be made in the Product to comply with the needed field process
Configuration: Defining existing content such as Options and Variables based on the requirements on the ground
Product walkthrough: Explaining the users step-by-step through a set of actions that they need to take to achieve a specific outcome
This is one of the major application of the egov stack which helps municipal and citizens to handle sewerage services like creating sewerage connection, searching sewerage connection, sewerage connection, also creating property if it doesn't exist and creating and updating workflow were depending on different roles of the logged-in user he/she can perform various actions like editing or perform document verification and many more specified in workflow documentation and SMS & email notification sent to the owner for various actions performed in the workflow.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has sewerage service persister config path added in it
PSQL server is running and a database is created to store sewerage connection / application data
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service will be helpful.
The sewerage service provides multiple functionalities starting from serving as a central repository where one can create sewerage connection, update sewerage connection, search for a particular sewerage connection based on different criteria like mobile number, sewerage connection nos etc. and also creating property if it doesn't exist, creating and updating workflow were depending on different roles of the logged-in user he/she can perform various actions like editing or perform document verification and many more specified in workflow documentation and SMS & email notification sent to the owner for various actions performed in the workflow. The different services provided by the sewerage services are
Creating sewerage connection
Updating sewerage connection
Apply for Property creation.
Searching sewerage connection based on a few criteria mentioned in swagger documentation later
Creating property if it doesn't exist
Creating and updating workflow.
To Do
Table UML Diagram
****
MDMS configuration
master-config.json for sewerage service
Actions & Role Action Mapping
Actions
Role Action Mapping
Workflow business service config
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for sewerage service
Workflow for property creation through Water and Sewerage Module
Indexer config for sewerage-service
Setup
Provide the absolute path of the checked-in file to DevOps, to add it to the file-read path of egov-indexer. The file will be added to the egov-indexer's environment manifest file for it to be read at the start-up of the application.
Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.
Modify connection
After connection activation or legacy connection, we can edit the connection. This process based on a defined workflow. Any action is based on defined roles on the action level. For edit connection, we need to upload some supporting documents and mandatory info.
Workflow config for edit connection
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for editing sewerage connection.
1{ 2 "RequestInfo": { 3 "apiId": "Rainmaker", 4 "action": "", 5 "did": 1, 6 "key": "", 7 "msgId": "20170310130900|en_IN", 8 "requesterId": "", 9 "ts": 1513579888683, 10 "ver": ".01", 11 "authToken": "{{Auth_Token}}" 12 }, 13 "BusinessServices": [ 14 { 15 "tenantId": "pb", 16 "businessService": "ModifySWConnection", 17 "business": "sw-services", 18 "businessServiceSla": 259200000, 19 "states": [ 20 { 21 "sla": null, 22 "state": null, 23 "applicationStatus": null, 24 "docUploadRequired": false, 25 "isStartState": true, 26 "isTerminateState": false, 27 "isStateUpdatable": false, 28 "actions": [ 29 { 30 "action": "INITIATE", 31 "nextState": "INITIATED", 32 "roles": [ 33 "SW_CEMP" 34 ] 35 } 36 ] 37 }, 38 { 39 "sla": null, 40 "state": "INITIATED", 41 "applicationStatus": "INITIATED", 42 "docUploadRequired": false, 43 "isStartState": false, 44 "isTerminateState": false, 45 "isStateUpdatable": true, 46 "actions": [ 47 { 48 "action": "SUBMIT_APPLICATION", 49 "nextState": "PENDING_FOR_APPROVAL", 50 "roles": [ 51 "SW_CEMP" 52 ] 53 } 54 ] 55 }, 56 { 57 "sla": 86400000, 58 "state": "PENDING_FOR_APPROVAL", 59 "applicationStatus": "PENDING_FOR_APPROVAL", 60 "docUploadRequired": false, 61 "isStartState": false, 62 "isStateUpdatable": true, 63 "isTerminateState": false, 64 "actions": [ 65 { 66 "action": "APPROVE_CONNECTION", 67 "nextState": "APPROVED", 68 "roles": [ 69 "SW_APPROVER" 70 ] 71 }, 72 { 73 "action": "REJECT", 74 "nextState": "REJECTED", 75 "roles": [ 76 "SW_APPROVER" 77 ] 78 }, 79 { 80 "action": "SEND_BACK", 81 "nextState": "INITIATED", 82 "roles": [ 83 "SW_APPROVER" 84 ] 85 } 86 ] 87 }, 88 { 89 "sla": null, 90 "state": "REJECTED", 91 "applicationStatus": "REJECTED", 92 "isStateUpdatable": false, 93 "docUploadRequired": false, 94 "isStartState": false, 95 "isTerminateState": true 96 }, 97 { 98 "sla": null, 99 "state": "APPROVED", 100 "applicationStatus": "APPROVED", 101 "isStateUpdatable": false, 102 "docUploadRequired": false, 103 "isStartState": false, 104 "isTerminateState": true 105 } 106 ] 107 } 108 ] 109} 110
Notification
Notification will be sent to the property owners and connection holders based on different application states.
Capturing connection holders
We can add connection holders to the sewerage connection which will be the owner of the connection. We can fill in the connection holders' details or we can just make the property owner to the connection holder.
The connection holder will get a notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.
Multiple Road Type Support We can add road cutting details of multiple roads to the sewerage connection. For each road which goes under cutting process we have to fill their road type details and road cutting area. Based on this information, application one time fee estimate is calculated.
This sw-service module is use to manage sewerage service connections against a property in the system.
Provide backend support for the different sewerage connection registration process.
Mseva and SMS notifications on application status changes.
Elastic search index for creating visualisations and Dashboards.
Supports workflow which is configurable
To integrate, the host of sw-service module should be overwritten in helm chart.
/sw-services/swc/_create should be added as the create endpoint for creating sewerage application/connection in the system
/sw-services/swc/_search should be added as the search endpoint .This method handles all requests to search existing records depending on different search criteria
/sw-services/swc/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
Sewerage Calculator Service is one of the major business logic services which is used for calculation of sewerage charge, generating demand, update existing demand, SMS & email notification to the ULB officials on-demand generation and also triggering demands(job scheduler) at some intervals and estimation of sewerage charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee etc.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has sewerage service persister configs path added in it
PSQL server is running and a database is created to store sewerage connection / application data
Following services should be up and running:
egov-perister
egov-mdms
sw-services
billing-service
Sewerage calculator services present in municipal services provide multiple functionalities like calculating sewerage charges, generating demands for a particular sewerage connection, updating demands, SMS & email notification to the ULB officials on-demand generation and also triggering demands(job scheduler) at some intervals and estimation of sewerage charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee etc. The different functionalities provided by sewerage calculator services are:
Sewerage charge calculation
Demand generation(here as its always non-metered demand will be generated based on time period)
Sewerage charge estimation (one-time cost which involves cost like road-cutting charge, form fee, scrutiny fee etc.)
Deploy the latest version of sw-service and sw-calculator
Add sewerage-persist.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )
Criteria :
connection type
building type
calculation attribute
property usage type
If all criteria will match for that sewerage connection this slab will use for calculation.
For application one-time fee, the estimation will return all the related tax head based on criteria. For estimation, all configuration is present in sw-services-calculation.
All the above master configuration is used for estimation.
Following are the exemptions and taxes that are calculated:
Form fee
Scrutiny fee
Other charges
Road cutting charges
One time fee
Security charges
Tax and cess
Sewerage charge is based on billing slab, for sewerage application charge will be based on slab and tax based on master configuration.
Interest
Below is a sample of master data JSON for interest :
Penalty
Below is a sample of master data JSON for penalty**:**
Round Off
If the fraction is greater than equal to 0.5 the number is round up else it’s round down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101.
Role Action Mapping
Once sewerage is sent to the calculator, its tax estimates are calculated. Using the tax head estimates demand details are created. For every tax head, the estimated demand generates function will create a corresponding demand detail.
Whenever _calculate API is called demand is first searched based on the connection no or application no and the demand from and to period. If demand already exists the same demand is updated else new demand is generated with consumer code as connection no or application no and demand from and to a period equal to financial year start and end period.
In the case of an update, if the tax head estimates change, the difference in amount for that tax head is added as new demand detail. For example, if the initial demand has one demand detail with SEWERAGE_CHARGE equal to 120
After updating if the SEWERAGE_CHARGE increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:
RoundOff is bill based i.e every time bill is generated round off is adjusted so that the payable amount is the whole number. Individual SW_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all SW_ROUNDOFF will always be less than 0.5.
For generating the demand for non metered connection we have a feature for generating the demand in batch. The scheduler is responsible for generating the demand based on the tenant.
The scheduler can be hit by scheduler API or we can schedule cron job or we can put config to kubectl which will hit scheduler based on config.
After the scheduler been hit we will search the list of the tenant (city) present in the database.
After getting the tenants we will pick up tenant one by one and generate the demand for that tenant.
We will load the consumer codes for the tenant and push the calculation criteria to Kafka. Calculation criteria contain minimal information (We are not pushing large data to Kafka), calculation criteria contain consumer code and one boolean variable.
After pushing the data into Kafka we are consuming the records based on the batch configuration. Ex:-> if the batch configuration is 50 so we will consume the 50 calculation criteria at a time.
After consuming the record(Calculation criteria) we will process the batch for generating the demand. If the batch is successful so will log the consumer codes which have been processed.
If some records failed in batch so we will push the batch into dead letter batch topic. From the dead letter batch topic, we will process the batch one by one.
If the record is successful we will log the consumer code, If the record is failed so we will push the data into a dead letter single topic.
Dead letter single topic contains information about failure records in Kafka.
Use cases
If the same job trigger multiple time what will happen?
If the same job triggers multiple times we will process again as mentioned above but at the demand level we will check the demand based on consumer code and billing period, If demand already exists then we will update the demand otherwise we will create the demand.
Are we maintaining success or failure status anywhere?
Currently, we are maintaining the status of failed records in Kafka.
Configuration
We need to configure the batch size for Kafka consumer. This configuration is for how much data will be processed at a time.1sw.demand.based.batch.size=10
sw-calculator will be integrated with sw-service. sw-services internally invoke the sw-calculator service to calculate and generate demand for the charges.
SW calculator application is used to calculate the sewerage application one time Fees and connection charges based on the different billing slabs that's why the calculation and demand generation logic will be separated out from SW service. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the SW service.
To Activate the Sewerage Service application, the user needs to pay the ONE_TIME_FEE for the connection. To calculate the ONE_TIME_FEE sw-calculator/sewerageCalculator/_estimate API is use.
To generate the demand for non-metered sewerage connection /sw-calculator/sewerageCalculator/_calculate API is use.
User can pay partial / full / advance amount for the Non-Metered connection bill. In these cases, Billing service would call back /sw-calculator/sewerageCalculator/_updateDemandAPI to update the details of the demand generated.
/sw-calculator/sewerageCalculator/_jobscheduler API is use to generate demand for Non-metered connections. This API can be called periodically.
/sw-calculator/sewerageCalculator/_applyAdhocTax API is used to add Rebate or Penalty on any bill and based on that the bill amount will be adjusted.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
Water Calculator Service is used for creating meter reading, searching meter reading, updating existing meter reading, calculation of water charge, demand generation, SMS & email notification to ULB officials on-demand generation and estimation of water charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee, etc.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has water service persister configs path added in it
PSQL server is running and a database is created to store water connection / application data
Following services should be up and running:
egov-perister
egov-mdms
ws-services
billing-service
Calculate water charge and taxes based on billing slab.
Calculate meter reading charge for water connection
Generate demand
Scheduler for generating the demand(for non metered connection)
Deploy the latest version of ws-service and ws-calculator
Add water-persist.yml & water-meter.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )
Criteria :
connection type
building type
calculation attribute
property usage type
If all criteria will match for that water connection this slab will use for calculation.
For application one-time fee, the estimation will return all the related tax head based on criteria. For estimation, all configuration is present in ws-services-calculation.
All the above master configuration is used for estimation.
Following are the exemptions and taxes that are calculated:
Form fee
Scrutiny fee
Meter charge (For metered connection)
Other charges
Road cutting charges
One time fee
Security charges
Tax and cess
Water charge is based on billing slab, for water application charge will be based on slab and tax based on master configuration.
Interest
Below is a sample of master data JSON for interest :
Penalty
Below is a sample of master data JSON for penalty :
Round Off
If the fraction is greater than equal to 0.5 the number is round up else it’s round down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101.
Actions
Role Action Mapping
Once water is sent to the calculator, its tax estimates are calculated. Using these tax head estimates demand details are created. For every tax head, the estimated demand generates function will create a corresponding demand detail.
Whenever _calculate API is called demand is first searched based on the connection no or application no and the demand from and to period. If demand already exists the same demand is updated else new demand is generated with consumer code as connection no or application no and demand from and to a period equal to financial year start and end period.
In the case of an update, if the tax head estimates change, the difference in amount for that tax head is added as new demand detail. For example, if the initial demand has one demand detail with WATER_CHARGE equal to 120
After updating if the WATER_CHARGE increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:
RoundOff is bill based i.e every time bill is generated round off is adjusted so that the payable amount is the whole number. Individual WS_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all WS_ROUNDOFF will always be less than 0.5.
Description :
For generating the demand for non metered connection we have a feature for generating the demand in batch. The scheduler is responsible for generating the demand based on the tenant.
The scheduler can be hit by scheduler API or we can schedule cron job or we can put config to kubectl which will hit scheduler based on config.
After the scheduler been hit we will search the list of the tenant (city) present in the database.
After getting the tenants we will pick up tenant one by one and generate the demand for that tenant.
We will load the consumer codes for the tenant and push the calculation criteria to Kafka. Calculation criteria contain minimal information (We are not pushing large data to Kafka), calculation criteria contain consumer code and one boolean variable.
After pushing the data into Kafka we are consuming the records based on the batch configuration. Ex:-> if the batch configuration is 50 so we will consume the 50 calculation criteria at a time.
After consuming the record(Calculation criteria) we will process the batch for generating the demand. If the batch is successful so will log the consumer codes which have been processed.
If some records failed in batch so we will push the batch into dead letter batch topic. From the dead letter batch topic, we will process the batch one by one.
If the record is successful we will log the consumer code, If the record is failed so we will push the data into a dead letter single topic.
Dead letter single topic contains information about failure records in Kafka.
Use cases:
If the same job trigger multiple time what will happen?
If the same job triggers multiple times we will process again as mentioned above but at the demand level we will check the demand based on consumer code and billing period, If demand already exists then we will update the demand otherwise we will create the demand.
Are we maintaining success or failure status anywhere?
Currently, we are maintaining the status of failed records in Kafka.
Configuration :
We need to configure the batch size for Kafka consumer. This configuration is for how much data will be processed at a time.1ws.demand.based.batch.size=10
ws-calculator will be integrated with ws-service. ws-services internally invoke the ws-calculator service to calculate and generate demand for the charges.
WS calculator application is used to calculate the water application one time Fees and meter reading charges based on the different billing slabs that's why the calculation and demand generation logic will be separated out from the WS service. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the WS service.
Once the water connection is activated for metered-connection, employee can add meter reading details using this API - /ws-calculator/meterConnection/_createwhich in-turn will generate the demand. For the Non-Metered connections, the scheduler APIs need to be called periodically to generate the demand.
For the Metered Connection service, to get the previous meter reading /meterConnection/_search API is used.
To Activate the Water Service application, the user needs to pay the ONE_TIME_FEE for the connection. To calculate the ONE_TIME_FEE /waterCalculator/_estimate API is used.
To generate the demand for metered or non-metered water connection /waterCalculator/_calculate API is used.
User can pay partial / full / advance amount for the Metered or Non-Metered connection bill. In these cases, Billing service would call back /waterCalculator/_updateDemandAPI to update the details of the demand generated.
/waterCalculator/_jobscheduler API is use to generate demand for Non-metered connections. This API can be called periodically.
/waterCalculator/_applyAdhocTax API is used to add Rebate or Penalty on any bill and based on that the bill amount will be adjusted.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
FI is responsible for inspecting and verifying the field details of the property in the application.
The Approver is responsible for the final approval of the PT application.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
The citizen can also approach the Counter Employee (CE) to register new property, assess property or pay property tax.
To add a new property click on the Property Tax card available in the Citizen Services section of the Home page.
Click on the Add New Property button on the screen. This will open a new form page.
The system will display the New Property form page.
The Application Summary page provides all the information filled in by the applicant. Click on the Edit icon to make any changes to the application.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Put indexer config file to the config repo under egov-indexer folder.(egovernments/configs )
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
``
Property creation through WNS module
Persister configuration:
The indexer provides the facility for indexing the data to elastic search.
Write the configuration for sewerage service.
Put indexer config file to the config repo under egov-indexer folder. ( )
All content on this page by is licensed under a .
The combination of the above can be used to define the billing slab. Billing Slab is defined in MDMS under sw-services-calculation folder with the . The following is the sample slab.
All content on this page by is licensed under a .
The combination of the above can be used to define the billing slab. Billing Slab is defined in MDMS under ws-services-calculation folder with the . The following is the sample slab.
All content on this page by is licensed under a .
Environment Variables
Description
egov.sewarageservice.createconnection
This variable contains the kafka topic name which is used to create new sewerage connection application in the system.
egov.sewarageservice.updateconnection
This variable contains the kafka topic name which is used to update the existing v connection application in the system.
egov.sewerageservice.updatesewerageconnection.workflow.topic
This variable contains the kafka topic name which is used to update the process instance of the sewerage connection application.
egov.idgen.scapid.name
This variable contain the idgen format name for sewerage application
egov.idgen.scapid.format
This variable contain the idgen format for sewerage application ex:- WS/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]
egov.idgen.scid.name
This variable contain the idgen format name for sewerage connection
egov.idgen.scid.format
This variable contain the idgen format for sewerage connection ex:- WS_AP/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON]
Title
Link
API Swagger Documentation
Sewerage Calculator Service
Title
Link
/sw-services/swc/_create
/sw-services/swc/_update
/sw-services/swc/_search
Title
Link
/sw-calculator/sewerageCalculatorr/_estimate
/sw-calculator/sewerageCalculator/_calculate
/sw-calculator/sewerageCalculator/_updateDemand
/sw-calculator/sewerageCalculator/_jobscheduler
/sw-calculator/sewerageCalculator/_applyAdhocTax
Title
Link
/ws-calculator/meterConnection/_create
/ws-calculator/meterConnection/_search
/waterCalculator/_estimate
/waterCalculator/_calculate
/waterCalculator/_updateDemand
/waterCalculator/_jobscheduler
/waterCalculator/_applyAdhocTax
Title
Link
API Swagger Contract
Sewerage Service Document
Title
Link
API Swagger Contract
Water Service Document