Overview

This page contains the changes related to core and municipal services along with the MDMS, DevOps and configuration setups required to accommodate multi-tenancy. Browse through the details below to learn more about the Central Instance.

Refer to SAAS Guidelines for Central Instance to find additional information.

Migration Steps

Service-request Module - Citizen Feedback Module

The service-request module is required for the surveys to work. Follow the steps given below:

1. Add the Service-request module

2. Add the new persister file: service-request-persister

3. Add the Helm chart

4. Configure the build

- name: "builds/digit-dev/core-services/service-request"
    build:
      - work-dir: "core-services/service-request"
        image-name: "service-request"
        dockerfile: "build/maven/Dockerfile"
      - work-dir: "core-services/service-request/src/main/resources/db"
        image-name: "service-request-db"

1. Make the role action-mapping changes in the MDMS

AccessControl Actions Test

AccessControl Role Actions

1. Click on the Job-builder once the above steps are complete.

2. Restart the following services: egov-accesscontrol, egov-mdms-service, egov-persister

3. Deploy the service-request module build

   For further details on how to use Citizen-feedback APIs refer to the Citizen Feedback service.

4. Create the Citizen Feedback Service definitions (as mentioned in the above Citizen Feedback Service document) for modules and flows as per requirement before using it on the UI.

New KPIs

1. Refer to KPIs: Pendancy, Citizen Feedback and Pt-SLA changes and make changes as per the document.

2. Restart dashboard analytics with Cluster-configs.

UI Migration Changes

• Central Instance:

Find the details for prepping the UI build for a new instance.

UI build preparation for a new instance

• Citizen Consent Form:

This feature allows citizen users to give their consent at the time of logging in.

Add this MDMS file

Documentation: a. Refer to Citizen Consent Form b. Restart MDMS and deploy the latest front-end builds.

• Citizen Feedback:

A functionality that allows users to provide the user facility to submit feedback/ratings at the end of the service.

Add the MDMS file available here: https://github.com/egovernments/egov-mdms-data/blob/QA/data/pb/common-masters/RatingAndFeedback.json

{
  "tenantId": "pb",
  "moduleName": "common-masters",
  "RatingAndFeedback": [
    {
      "type": "isCitizenRatingEnabled",
      "value": true
    },
    {
      "type": "headerByRating",
      "value": [
        {
          "minvalue": 1,
          "maxvalue": 3,
          "code": "CS_WHAT_WENT_WRONG"
        },
        {
          "minvalue": 4,
          "maxvalue": 5,
          "code": "CS_WHAT_WENT_GOOD"
        }
      ]
    },
    {
      "type": "enabledScreensList",
      "value": [
        {
          "module": "PT",
          "bussinessService": "PT_CREATE",
          "screenfrom": "pt/property/new-application/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_CREATE",
          "cardText": "PT_RATE_CARD_TEXT_CREATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT_MUTATION",
          "screenfrom": "pt/property/property-mutation/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_MUTATE",
          "cardText": "PT_RATE_CARD_TEXT_MUTATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT_UPDATE",
          "screenfrom": "pt/property/edit-application/acknowledgement",
          "cardHeader": "PT_RATE_HELP_TEXT_UPDATE",
          "cardText": "PT_RATE_CARD_TEXT_UPDATE"
        },
        {
          "module": "PT",
          "bussinessService": "PT",
          "screenfrom": "digit-ui/citizen/payment/success",
          "cardHeader": "PT_RATE_HELP_TEXT_PAY",
          "cardText": "PT_RATE_CARD_TEXT_PAY"
        }
      ]
    }
  ]
}

In the provided configuration, the parameter headerByRating is utilized to specify the value for the star condition, along with the corresponding message to be displayed on the UI screen. The enabledScreensList parameter is used to indicate the specific flows where the Citizen feedback screen will be presented, allowing citizens to provide reviews.

The rating component is utilized for displaying star ratings on the citizen feedback screen. You can locate this component within the micro-ui-internals folder on the following GitHub link: Rating.js.

Documentation

a. Refer to Citizen Feedback Documentation for more details.

b. Restart MDMS and deploy the latest front-end builds.

Release Summary

Local Governance 2.9 release includes the following changes:

• Citizen Consent Form

• Citizen Feedback Rating

• KPI List (National Dashboard)

  • Citizen Feedback Score

  • Citizen Service Delivery Index

  • Aggregated SLA

  • Pendancy

• mCollect (demand-based revenue collection) Pdf -QR code bug fix/alignment issues

• Residential Construction Permit System - bug fixes

• Local Business License Issuing System - bug fixes

• Property Tax System - bug fixes

• Finance - bug fix

• Central Instance-related changes for modules - Property Tax, Trade License, Citizen Complaint Resolution System, Residential Construction Permit System, Water and Sewerage Connections, Fire Safety Certification, Birth and Death, mCollect, Reports and Inbox.

New ‌Feature Additions

Enhancements

‌Document Resources & Links

Overview

The page assumes that the deployment of the central instance will happen in a Kubernetes-based environment independent of whether it’s a cloud-based or a bare metal deployment with a Kubernetes-based orchestrator. This page lists all types of services available in a DIGIT SAAS package and the steps to deploy, implement, and add a new service.

Useful Terms

Namespace/deployment-space - refers to the Kubernetes namespace or the equivalent by establishing access restrictions.

State/Tenant - A state is a separate entity whose applications and data are separated from the rest by namespaces and schemas in the database.

Deployment Setup

1. Backbone Services - The backbone services include Kafka, Redis, and Elastic stack. The number of deployments and the namespace where the services will be deployed are taken care of by the deployment manager itself.

2. State Deployment space - Namespace - In DIGIT SAAS, the private application/deployment space (namespace in K8s & schema in DB) is provided for different tenants (states) when they onboard, the steps to create and provide the same are mentioned in the following document.

3. Central/Shared Services - In DIGIT SAAS, each new tenant is given a separate namespace, but most use some unmodified out-of-box services provided by DIGIT deployed in a shared space known as the central namespace. These sets of services include some of DIGIT’s core services and registries. Among the services mentioned some can never be modified by the state (tenant) actors and some can be modified. In case of any modification, the services should be deployed in their own space.

   • 1.3.1 The unmodifiable core services are listed below:

     • user(egov-user + egov-otp + user-otp )

     • API-Gateway(Zuul + Access Control + nginx-ingress controller)

     • Internal gateway

     • Workflow

     • Persister

     • Indexer

     • Report

     • Searcher

     • HRMS

     • Localisation

     • Location

     • NDSS

     • MDMS

The above-mentioned services cannot be modified by the state actors and should only be deployed in the central/shared namespace.

• The modifiable registries

  • Registries of any kind are provided by eGov out of the box and are not customized by the state actors. for ex property-registry, TradeLicense-registry etc..,

  • These registries should be deployed in the central namespace to improve usage and reduce cost.

  • When there are modifications to the service then the same has to be deployed in the state’s own deployment space.

4. State services

The services that are by default deployed and run in the state namespaces whether there are modifications or not. Since they have functionalities that are directly related to the specific requirement of the state.

These services can be divided into multiple categories -

• User Interface - The DIGIT UI by default requires customisation related to the state(tenant), hence will always be deployed in state-specific deployment spaces.

• Core state services (Unmodifiable) - The DIGIT core services will be deployed in state-specific deployment spaces due to their nature of being dependent on the state(tenant) base configs.

  • MDMS

  • Notification SMS

  • Notification email

  • User event

  • IDgen

  • Payment gateway service

• Utility services - The utility services are always state config dependent hence they will be deployed in the state-specific spaces.

  • Pdf

  • Inbox

  • DSS

  • EDCR

  • Finance

• Calculators - The calculation logic requirement will mostly change along with the state-specific configs hence they are by default deployed in state-specific spaces.

  • Property

  • Trade License

  • Water

  • Sewerage etc..

Configuration Setup

The DIGIT applications require different types of config setup, they are as follows the MDMS data, persister, indexer, pdf, report, searcher and internal gateway.

1. MDMS Data

The MDMS data is required for the Master data management service to supply the data required by other modules to perform their basic validation and verify the validity of the data. The prescribed format of the same can be found in the application setup. Since the application is deployed in all the namespaces central and state. Each deployment will need its own GitHub repo.

Central MDMS - central MDMS repo

State 1 MDMS - state1 MDMS repo

2. Persister & Indexer

The persister and indexer configuration for all states should be added in a single GitHub repo in the same branch. Since both applications run in a single place. Each state deployment will have to modify their KAFKA topic names with a prefix of their state schema name.

3. PDF

The pdf configs have to be added in a separate repository since the format of pdfs printed will change with each different tenant.

4. Report & Searcher

The configs of report and searcher have to be added in the same GIT repo and same branches as the persister and indexer. The additional change that needs to be done here is that their URL should be appended with state schema names like the topic names with persister config.

5. Internal Gateway

The internal gateway config should be added to the central git config repo since the app is deployed in the central namespace.

Development Guide

The development of any service in DIGIT should be based on this development guide.

1. Common Update For All Services

The following library versions are a minimum requirement before any service can be made central instance compatible.

Changes to pom.xml

1. Add Tracer 2.1.1 and above

<dependency>
	<groupId>org.egov.services</groupId>
	<artifactId>tracer</artifactId>
	<version>2.1.1-SNAPSHOT</version>
</dependency>

1. Services-common 1.1.0 and above

<dependency>
	<groupId>org.egov.services</groupId>
	<artifactId>services-common</artifactId>
	<version>1.1.0-SNAPSHOT</version>
</dependency>

1. MDMS-Client 0.0.4 and above

<dependency>
	<groupId>org.egov</groupId>
	<artifactId>mdms-client</artifactId>
	<version>0.0.4-SNAPSHOT</version>
</dependency>

1. ENC-Client 2.04 and above

<dependency>
	<groupId>org.egov</groupId>
	<artifactId>enc-client</artifactId>
	<version>2.0.4-SNAPSHOT</version>
	<exclusions>
		<exclusion>
			<groupId>org.springframework.kafka</groupId>
			<artifactId>spring-kafka</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.apache.kafka</groupId>
			<artifactId>kafka-clients</artifactId>
		</exclusion>
	</exclusions>
</dependency>

2. Multi-Schema Services List

The following document helps to make multi-environment applications (Services which will run in the DIGIT namespace but store their data in state-specific namespaces of DB based on tenant-id) central instance compatible. These services include the likes of -

1. Billing-service

2. Collection-service

3. workflow-service

4. egov-apportion-service

5. egov-hrms

6. All the municipal registries

7. Property-services

8. TL-services

9. PGR-services

10. bpa-services

11. echallan-services

12. firenoc-services

13. land-services

14. noc-services

15. sw-services

16. ws-services

Any service that needs to share its data among multiple DB schemas can be added to the above category.

3. Migration Changes For Multi-Schema Services

Certain services in the Central-instance will only be deployed in the central (DIGIT) namespace but their data needs to be stored in different schema belonging to different state namespaces. The migrations of foretold services need to be run in all Required schemas (for instance: namespaces that want to make use of the centrally deployed services). To enable the above functionality the following changes are required.

1. Migrate.sh

This file is needed for building migration docker image is located in the DB folder of resources. eg: property-services/src/main/resources/db/migrate.sh. Update the file with the following contents:

#!/bin/sh
baseurl=$DB_URL
echo "the baseurl : $DB_URL"
schemasetter="?currentSchema="
schemas=$SCHEMA_NAME
echo "the schemas : $schemas"
for schemaname in ${schemas//,/ }
do
    echo "the schema name : ${baseurl}${schemasetter}${schemaname}"
    flyway -url=${baseurl}${schemasetter}${schemaname}  -table=$SCHEMA_TABLE -user=$FLYWAY_USER -password=$FLYWAY_PASSWORD -locations=$FLYWAY_LOCATIONS -baselineOnMigrate=true -outOfOrder=true -ignoreMissingMigrations=true migrate
done

1. values.yml

The DB configuration is by default provided in the common values.yml file in the helm chart and need not be edited in normal scenarios. Since we are injecting the multiple schema list for app-specific purposes all the DB-migration ENV variables should be overridden in the app-specific values.yml file.

#Values.yml of the specific service before multiple schema changes

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "property_services_schema"
    image:
      repository: "property-services-db"

#Values.yml of the specific service after multiple schema changes.

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "property_services_schema"
    image:
      repository: "property-services-db"
    env: |
        {{- if index .Values "property-ismultischema-enabled" }}        
        - name: SCHEMA_NAME
          value: {{ index .Values "property-schemas" | quote }}
        {{- end }}
        - name: "DB_URL"
          valueFrom: 
            configMapKeyRef: 
              name: egov-config
              key: db-url
        - name: "SCHEMA_TABLE"
          value: {{ .Values.initContainers.dbMigration.schemaTable | quote }}              
        - name: "FLYWAY_USER"
          valueFrom: 
            secretKeyRef: 
                name: db
                key: flyway-username
        - name: "FLYWAY_PASSWORD"
          valueFrom:
            secretKeyRef: 
                name: db
                key: flyway-password
        - name: "FLYWAY_LOCATIONS"
          valueFrom: 
            configMapKeyRef: 
                name: egov-config
                key: flyway-location

Only the - name: SCHEMA_NAME variable needs to be added and other fields can be copied from the common values.yml as it is without any changes. The above file contains an if-else condition with two new variables

{{- if index .Values "property-ismultischema-enabled" }}        
- name: SCHEMA_NAME
  value: {{ index .Values "property-schemas" | quote }}
{{- end }}

The "property-ismultischema-enabled" Boolean value to check if the feature is enabled and "property-schemas" to derive the value from respective environments YAML. This example of two variables should be named differently based on service-name to avoid conflicts.

1. Environments.yml

In the respective environment’s file add the two new variables, one for the if condition and the other field for actual values under the respective service names. Lines 6 and 7 are the sample values provided here.

eg :

property-services:
  property-schemas: 'public,statea,stateb'
  property-ismultischema-enabled: 'true'

4. Code Changes For Multi Schema Services

Any services that could potentially be commonly used by all environments in the central instance (refer to Multi Schema Service List for details).

Application.properties variables to be added.

1. state.level.tenantid.length=2 State-level tenant value will be picked from the full tenant-id separated by the '.' dot. once the tenant-id is separated by a dot the resulting array of sizes given above will be considered state level.

2. is.environment.central.instance=true

   Declares whether the environment in which the service is deployed belongs to a central-instance kind of setup.

3. The both above said variable has to be overridden in the values YAML file of the respective service to pick up the values from the environment.

  {{- if index .Values "global" "is-environment-central-instance" }}        
  - name: IS_ENVIRONMENT_CENTRAL_INSTANCE
    valueFrom:
      configMapKeyRef:
        name: egov-config
        key: is-environment-central-instance
  {{- end }}
  {{- if index .Values "global" "is-environment-central-instance" }}        
  - name: STATE_LEVEL_TENANTID_LENGTH
    valueFrom:
      configMapKeyRef:
        name: egov-config
        key: state-level-tenantid-length
  {{- end }}

1. The host of the state-specific services referred by this service should be changed to the internal gateway host for tenant-based(namespace) redirection.

  - name: EGOV_MDMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: internal-gateway

Sample values YAML file to refer to the above-said changes

1. If this service allows the search of data without tenant-id then the following validation should be added to all the search APIs belonging to the service. searches without state-level tenant-id (as described by this variable - state.level.tenantid.length) will render the application useless, so the following is mandatory

if(configs.getIsEnvironmentCentralInstance() && criteria.getTenantId() == null) 
  throw new CustomException("EG_PT_INVALID_SEARCH",
                                      " TenantId is mandatory for search ");
                                      
else if(configs.getIsEnvironmentCentralInstance() 
    && criteria.getTenantId().split("\\.").length < configs.getStateLevelTenantIdLength())
 throw new CustomException("EG_PT_INVALID_SEARCH",
       " TenantId should be mandatorily " + configs.getStateLevelTenantIdLength() + " levels for search");

1. Update the Kafka producer in the service with the following code to enable the service to post to a tenant (namespace) specific topic based on the tenant-id.

@Service
@Slf4j
public class Producer {

	@Autowired
	private CustomKafkaTemplate<String, Object> kafkaTemplate;
	
	@Autowired
	private PropertyConfiguration configs;

	public void push(String tenantId, String topic, Object value) {

		String updatedTopic = topic;
		if (configs.getIsEnvironmentCentralInstance()) {

			String[] tenants = tenantId.split("\\.");
			if (tenants.length > 1)
				updatedTopic = tenants[1].concat("-").concat(topic);
		}
		log.info("The Kafka topic for the tenantId : " + tenantId + " is : " + updatedTopic);
		kafkaTemplate.send(updatedTopic, value);
	}
} 

1. Replace all the table names in the queries present with the {schema} placeholder

private static String PROEPRTY_AUDIT_QUERY = "select property from {schema}.eg_pt_property_audit where propertyid=?";

1. Add the following Schema replacer utility method and use the same to replace all queries with the respective schema.

/* * add this variable to your constant class */
public static String SCHEMA_REPLACE_STRING = "{schema}"; /** * Method to fetch the state name from the tenantId * * @param query * @param tenantId * @return */
public String replaceSchemaPlaceholder(String query, String tenantId) {
    String finalQuery = null;
    if (tenantId.contains(".")) {
        String schemaName = tenantId.split("\\.")[1];
        finalQuery = query.replace(Constants.SCHEMA_REPLACE_STRING, schemaName);
    } else {
        finalQuery = query.replace(Constants.SCHEMA_REPLACE_STRING.concat("."), "");
    }
    return finalQuery;
} 

/* * Sample method example to replace query with schema */
public List < String > getPropertyIds(Set < String > ownerIds, String tenantId) {
    List < Object > preparedStmtList = new ArrayList < > ();
    String query = queryBuilder.getQuery(ownerIds, tenantId, preparedStmtList);
    query = util.replaceSchemaPlaceholder(query, tenantId);
    return jdbcTemplate.queryForList(query, preparedStmtList.toArray(), String.class);
}

1. Change the persister config to alter the Kafka topic names for the configs belonging to your respective multi-schema service. The Kafka topic name should be appended with the schema name of the respective state schema.

5. Central Instance Enabled Development

Whether a service is going to be deployed in a central instance or not, it should follow and integrate with the central instance util library of common services.

1. Refer to the common update document 3.1 General update for services to be Central-Instance compatible.

2. Make use of centralInstanceUtil class to perform any tenantId manipulations. Manual manipulation of tenantId is to be avoided for common purposes like getting state-level tenantId, and state-specific Kafka topics. Read the following methods from MultiStateInstanceUtil class found in the common-services package and make use of them as mentioned in the document.

1. New environment variables are to be added mandatorily for environments.

is.environment.central.instance=false
state.level.tenantid.length=2
state.schema.index.position.tenantid=1

1. The environment should be set to false when the current server is not for multi-state(non-central-instance), disabling and enabling this make the methods in the multiStateUtil class behave as required.

2. The state-level tenant length describes what part of the whole tenantId represents the state part. for eg: in tenantId “in.statea.tenantx”. in.statea represents the state part so the value will be 2.

3. The schema index position points to the substring of the tenantId whose value represents the schema name of the database for the given state.

Service Builds 2.9

Overview

This release offers the UI/UX revamp of the Residential Construction Permit System, workflow timeline changes and reports.

Release Highlights

The functionality in OBPS remains the same - only the UI/UX has changed.

Two reports were added for administrative purposes.

Changes made to the workflow timeline for clear representation of application status to the users.

Notification based on channels.

Release Features

• Stakeholder registration and employee approval flow

• Architect flow (permit application creation) and employee approval flow

• Architect occupancy certificate creation and employee approval flow

• Fire NOC employee approval flow

• Open link for stakeholder registration flow

• Daily collection report

Residential construction permit application status report

Workflow timeline changes in application flow - The image below the one illustration on the right displays the old status view. Here the application status shows pending even if the task is completed. As per the current release, the application displays only the current state where the action is marked as pending. The remaining status is marked as done or completed or in a submitted state.

Notification based on channels - The residential construction permit application allows the user to configure different messages for different channels (In-app, mobile messages, email) for the same event in the application process flow.

Known Issues

Upcoming Release Features

None

Reference Doc Links

Overview

This release provides UI/UX revamp of existing features of water and sewerage modules in addition to applying for disconnection, data privacy, and 3 standard reports.

Release Highlights

UI/UX revamp of water and sewerage covers the features given below.

Citizen

1. My Connections

2. My Applications

3. My Payments

4. My Bills

5. Search and Pay

6. Apply for a new connection

7. Apply for disconnection

8. View Connection Details

9. View Consumption Details

10. View Application Details

11. Pay Water and Sewerage Bill

12. Pay Application Fee

Employee

1. Water Inbox

2. Sewerage Inbox

3. Apply for a new connection

4. Modification of connection

5. Bill Amendment

6. Application Workflows

7. Search Connection

8. Search Application

9. View Connection Details

10. View Consumption Details

11. Add Meter Reading

12. View Application Details

13. Collect Application Fee

14. Collect Water and Sewerage Bill

Downloads/ PDFs

1. Connection Details

2. Application Acknowledgement/ From

3. Estimation Notice

4. Sanction Letter

New Features Added

1. Disconnection of water and sewerage connection.

2. Disconnection Notice PDF

3. Application acknowledgement/form PDF

Reports

1. Receipt Register

2. Collection Register

3. Defaulters Report

Data Privacy

1. Masking of PII data

2. Option to unmask the PII data

3. Audit trail of the unmasking of PII data

Release Features

Known Issues

Upcoming Release Features

None

Reference Doc Links

About Local Governance

The DIGIT-powered local governance solution catalyses digital transformation across towns and cities - changing how citizens interact with government bodies. As a digital public good, the DIGIT Local Governance stack fosters an open digital ecosystem, enabling co-creation and deployment of locally relevant solutions that enhance business operations and improve overall quality of life. By transforming local governance, this initiative not only elevates citizen well-being but also accelerates the nation's economic growth.

Useful Links

Contact Us

National Dashboard New KPIs

Citizen Feedback

Citizen Consent Form

Central Instance

No additional test cases have been added for the central instance. The existing test cases should work for the central instance as is.

Overview

This release provides PRDs of 3 property tax features and a few bug fixes.

Release Highlights

PRDs of 3 property tax features and bug fixes.

1. Properties amalgamation

2. Property bifurcation

3. Capital value system

4. Property mutation bug fixes

Release Features

None

Known Issues

Bug

UM-5322: PT: Mutation flow: In Acknowledgement Form only one Transferor Details are present.SIGNED OFF

Upcoming Release Features

None

Reference Doc Links

DIGIT Urban 2.9 release has a new following features:

• DIGIT Urban 2.9 Beta Features

• DIGIT as a Service

• Bug Fixes

NUDM Roll Out

The NUDM Team has shared the following requirements for upgrading UPYOG with the Central Instance:

*Conditions for Upgrading UPYOG with Central Instance

• Role & Access Management at Cluster Level so that each State SI can do its scope of work

• Role & Access Management at Logs Level so that each State SI can do its scope of work

• Role & Access Management at Elastic Search & Kibana Level so that each State SI can do its scope of work

• Enhancement & verification of Product default Kafka with more nodes, partitions, etc so that it sustains and performs for National Level traffic

• Enhancement & verification of Product default ElasticSearch with more nodes, shards, etc so that it sustains and performs for National Level traffic

• Availability of all States data in its DB schemas and the same should apply with ElasticSearch

• Other enhancements so that the State Infra & DevOps team can manage their resources independently.

Adoption Metrics

Success Metrics

Overview

A few reports are added to the TL module for administrative purposes.

Release Highlights

Daily collection report

Application status report

Trade license registry

Trade license renewal pending report

Release Features

Trade license daily collection report

Trade license application status report

Trade license registry

Trade license renewal pending report

Known Issues

Upcoming Release Features

None

Overview

UI/ UX revamp of bill amendment.

Release Highlights

UI/UX revamp of Bill Amendment Inbox and Application View.

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

MDMS Changes

Config Changes

DevOps Changes

Overview

This module gives citizens more information on a service delivery module than just links to access the service.

Release Highlights

Product Specific Pages Module consists of the following:

For Citizen

For a module and tenant that is configured.

1. FAQs

   • List of FAQs for each module

2. How it works

   • List of user manuals, help videos etc (Also in local language)

3. Link to access service via WhatsApp

4. Helpline Numbers

5. Address of Service Centres

   • Link to navigate to google maps

6. Static data

   • Ex. Days to process applications/ Amount to pay while applying etc

7. Dynamic Data

   • Number of citizens applied for service in last n months/ Amount collected etc

Known Issues/ Upcoming Features

https://digit-discuss.atlassian.net/browse/UM-5628 https://digit-discuss.atlassian.net/browse/UM-5721 https://digit-discuss.atlassian.net/browse/UM-5640 https://digit-discuss.atlassian.net/browse/UM-5725

Related Doc Links

Overview

UI/ UX revamp of Bill Genie.

Release Highlights

UI/UX revamp of Bill Genie features.

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Overview

This module allows employees to create surveys for citizens and let them fill out surveys. Later survey results can also be seen on the Survey results dashboard.

Release Highlights

The Survey module consists of the following

For Employees

1. Surveys section on Home Page

2. Surveys inbox

3. Create survey

   • Meta Data - Title, Description, Survey start & end date/time

   • Questions

     • Short Answer

     • Paragraph

     • Single Answer

     • Multiple choice questions

     • Date

     • Time

4. Survey Results

   • Aggregated view of all survey results in specific charts for each question type

   • Download the excel report with the survey results

5. Modify surveys

   • Survey questions

   • Extend the Survey date and time.

For Citizens

1. Notification on Survey creation.

2. Survey Filling

Known Issues/ Upcoming Enhancements

1. Expansion to other types of questions

2. More notifications to citizens prior to survey start, and survey end.

3. Making surveys open. (Right now citizens need to be logged in to fill out the survey. This needs to be made open)

https://digit-discuss.atlassian.net/browse/UM-5697 https://digit-discuss.atlassian.net/browse/UM-5700

Related Doc Links

Overview

Reports have been added to birth and death for administrative purposes.

Release Highlights

Birth count report

Death count report

Birth and death certificate payment records

Release Features

Birth count report

Death count report

Birth and death certificate payment report

Known Issues

https://digit-discuss.atlassian.net/browse/UM-5256

Upcoming Release Features

None

Overview

About page, FAQ and 3 new KPIs are added to the DSS page

Release Highlights

About page for the dashboard is added which helps users to understand the purpose, how data is secure and from where the data is being pushed.

And 3 new KPIs were added for administrative purposes.

Release Features

About page

FAQ

3 KPIS - Non-tax revenue collected, Non-tax revenue contribution % and Average PT collected.

Related Doc Links

Overview

The Local Governance 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 solutions are available to all members of society without profits or restrictions.

Goals

The urban mission offers digital governance solutions that encapsulate the core platform principles. The apps provide

• Secure & reliable governance tools

• Simple reusable modules for effective integration

• Scalable & standardized solutions

• Open APIs to promote interoperability

• Multiple channel support

• Configurable building blocks that support customization at each stage

Approach

The local governance focuses on inclusion and is designed to enhance 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.

• Open Source - The local governance stack is open source and has been built using the best-in-class open-source technology stacks powering the most advanced companies in the world. The solution can provide the lowest total cost of ownership and helps ensure that governments retain strategic control of their systems and data.

• Mobile-Enabled - The local governance solution design follows a mobile-first approach, with robust mobile applications enabling citizens to access government services through their phones easily. Government officials and field workers are also empowered with mobile applications that enable them to deliver 24×7 governance with ease.

• Real-time Dashboards - The 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.

About Local Business License Issuing System

The Local Business License Issuing System enables local government bodies to regulate trading establishments. It also serves to protect the interest of the public at large against possible health hazards and inconveniences that any business operation can cause. With the Business License Issuing application 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 application makes obtaining a trade licence easy, smooth, and transparent. Hence, the module removes the need for manual processing and streamlines the key trade licence management functions to provide a better user experience.

Click on the link below to download the trade licence brochure.

Key Features

Section Overview

This section contains all docs and information required to understand the Business Licensing module, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the business license issuing module.

Contact Us

The module offers citizens and governance bodies a convenient and transparent means of processing trade licenses. A trade licence is permission the local governing bodies issue to carry on a specified business or trading activity within the authorized area. It is a mandatory document required to run a business or commercial activity.

Using Local Business License Issuing Module

Click on the relevant role below to learn more about how to use the trade license solution.

Citizens and CE

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

The Citizen or CE role can -

Citizens or CEs can apply for a new trade licence through the DIGIT web portal or the DIGIT mobile app. To apply for a new trade licence click on the Trade Licence card available in the Citizen Services section of the DIGIT home page.

Introduction

The Local Business License Issuing application provides a digital interface, allowing citizens to apply for the Trade Licence and subsequently make the trade licence fee payment online.

The Local Business License Issuing application enables:

• Ease of doing business — Traders can apply for new licences, renewals, amendments, and supplemental licences

• Regulatory Tracking — Administrators can track and manage regulatory processes

• Shorter Timelines — Streamline and automate business licencing processes and help 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

Functional Scope

The list below summarizes the key features supported by the TL module -

Registration, Login and Creation of User Profile

Applying for a Trade Licence

Users can apply for a new Trade Licence from the system. They can select the type of license to apply. The user enters trade details, owner details and documents after which the application can be reviewed and submitted. Similarly, a counter employee can also apply for a trade licence on behalf of the citizen. The system has a workflow integration that enables stage-wise approval before issuing the Trade Licence.

Trade License Issue

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.

Modifications to a Trade Licence

The system has the facility to edit/update the application based on the inspection report against the application.

Trade Licence Renewal

The system has the facility to provide a hassle-free renewal process for citizens and employees, leading to increased revenues, by reducing unlicensed trades. The system allows the sending of SMS and email notifications and reminders based on the renewal cycle.

Payment and Fee

Dashboards and Reports

General Features

System specification in compliance with the Ease of Doing Business (EODB) BRAP 2019

List of Features- Trade Licence