Learn how to setup DIGIT master data.

• MDMS Overview

• Configuring Master Data

• Adding New Master

• Configuring Tenants

• State Level vs City Level Master

Learn how to configure the DIGIT Urban platform. Partner with us to enhance and integrate more into the platform.

All content on this page by is licensed under a .

Overview

Configuring Master Data for a new module requires creating a new module in the master config file and adding master data. For better organizing, create all the master data files belonging to the module in the same folder. Organizing in the same folder is not mandatory it is based on the moduleName in the Master data file.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

These data can be used to validate the incoming data.

Deployment Details

After adding the new module data, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Adding new module

The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

The new module can be added below the existing modules in the master config file.

Creating Masters data

Please check the link to create new master Adding New Master

Reference Docs

Doc Links

Overview

Tenant represents a body in a system. In the municipal system, a state and its ULBs (Urban local bodies) are tenants. ULB represents a city or a town in a state. Tenant configuration is done in MDMS.

Pre-requisites

Before proceeding with the configuration, the following pre-requisites are met -

• Knowledge of json and how to write a json is required.

• Knowledge of MDMS is required.

• User with permission to edit the git repository where MDMS data is configured.

Key Functionalities

• For the login page city name selection is required. Tenant added in MDMS shows in city drop-down of the login page.

• In reports or in the employee inbox page the details related to ULB is displayed from the fetched ULB data which is added in MDMS.

• Modules i.e., TL, PT, MCS can be enabled based on the requirement for the tenant.

Deployment Details

After adding the new tenant, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Tenant is added in tenant.json. In MDMS, file tenant.json, under tenant folder holds the details of state and ULBs to be added in that state.

{
  "tenantId": "uk",  //<ReplaceWithDesiredTenantId>
  "moduleName": "tenant",
  "tenants": [ {
      "code": "uk.citya", //<state.ulbname>
      "name": "City A",  //<name of the ulb>
      "description": "City A", //<ulb description>
      "logoId": "https://s3.ap-south-1.amazonaws.com/uk-egov-assets/uk.citya/logo.png",  //<ulb logo path - To display ulb logo on login>
      "imageId": null,
      "domainUrl": "", //<ulb website url>
      "type": "CITY",
      "twitterUrl": null,
      "facebookUrl": null,
      "emailId": "complaints.citya@gmail.com",  //<ulb email id>
      "OfficeTimings": {
        "Mon - Sat": "10.00 AM - 5.00 PM"
      },
"city": {
"name": "City A",
"localName": null,
"districtCode": "CITYA",
"districtName": null,
"regionName": null,
"ulbGrade": "Municipal Corporation",
"longitude": 78.0322,
"latitude": 30.3165,
"shapeFileLocation": null,
"captcha": null,
"code": "248430"
},
"address": "City A Municipal Cornoration Address",
"contactNumber": "91 (135) 2653572"
}]}

Localization should be pushed for ULB grade and ULB name. The format is given below.

Localization for ULB Grade

{
     "code": "ULBGRADE_MUNICIPAL_CORPORATION",
     "message": "MUNICIPAL CORPORATION",
     "module": "rainmaker-common",
     "locale": "en_IN"
  }

Localization for ULB Name

{
     "code": "TENANT_TENANTS_UK_HALDWANI",    
     "message": "Haldwani",
     "module": "rainmaker-tl",
     "locale": "en_IN"
}

Format of localization code for tenant name <MDMS_State_Tenant_Folder_Name>_<Tenants_Fille_Name>_<Tenant_Code> (replace dot with underscore)

Boundary data should be added for the new tenant.

Reference Docs

Doc Links

Overview

For creating a new master in MDMS, create the JSON file with the master data and configure the newly created master in the master config file.

Pre-requisites

Before proceeding with the configuration, make sure the following pre-requisites are met -

• User with permission to edit the git repository where MDMS data is configured.

Deployment Details

After adding the new master, the MDMS service needs to be restarted to read the newly added data.

Configuration Details

Creating Master JSON

The new JSON file needs to contain 3 keys as shown in the below code snippet. The new master can be created either State-wise or ULB-wise. Tenant id and config in the master config file determine this.

{
  "tenantId": "< TENANT ID >",
  "moduleName": "< MODULE NAME >",
  "< MASTER NAME >": []
}

Configuring The Master Config File

The Master config file is structured as below. Each key in the Master config is a module and each key in the module is a master.

{
  "<module1>":{
    "<master1>":{},
    "<master2>":{},
    ...
  },
  "<module2>":{
    <master3>:{},
    <master4>:{},
    ...
  },
  ...
}

Each master contains the following data and the keys are self-explanatory

"master":{
    "masterName": "<>",
    "isStateLevel": true,
    "uniqueKeys": []
}

Reference Docs

Doc Links

Overview

MDMS stands for Master Data Management Service. MDMS is One of the applications in the eGov DIGIT core group of services. This service aims to reduce the time spent by developers on writing codes to store and fetch master data ( primary data needed for module functionality ) which doesn’t have any business logic associated with them.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

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

• Advanced knowledge of how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

• The MDMS service reads the data from a set of JSON files from a pre-specified location.

• It can either be an online location (readable JSON files from online) or offline (JSON files stored in local memory).

• The JSON files will be in a prescribed format and store the data on a map. The tenantID of the file serves as a key and a map of master data details as values.

• Once the data is stored in the map the same can be retrieved by making an API request to the MDMS service. Filters can be applied in the request to retrieve data based on the existing fields of JSON.

Deployment Details

• For deploying the changes in MDMS data, the service needs to be restarted.

• The changes in MDMS data could be adding new data, updating existing data, or deletion.

Configuration Details

The config JSON files to be written should follow the listed rules

• The config files should have JSON extension

• The file should mention the tenantId, module name, and the master name first before defining the data

{
  "tenantId": "uk",
  "moduleName": "BillingService",
  "{$MasterName}":[ ]
}

Example Config JSON for “Billing Service”

{
  "tenantId": "pb",
  "moduleName": "BillingService",
 "BusinessService": 
 [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "collectionModesNotAllowed": [ "DD" ],
      "partPaymentAllowed": true,
      "isAdvanceAllowed": true,
      "isVoucherCreationEnabled": true
    }
]
}

Reference Docs

Doc Links

API List

Overview

MDMS supports the configuration of data at different levels. While we enable a state there can be data that is common to all the ULBs of the state and data specific to each ULBs. The data further can be configured at each module level as state-specific or ULB’s specific.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

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

• Advanced knowledge of how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

• State Level Masters are maintained in a common folder.

• ULB Level Masters are maintained in separate folders named after the ULB.

• Module Specific State Level Masters are maintained by a folder named after the specific module that is placed outside the common folder.

Deployment Details

• For deploying the changes(adding new data, updating existing data or deletion) in MDMS, the MDMS service needs to be restarted.

Configuration Details

State Level Master Configuration

• The common master data across all ULBs and modules like department, designation, etc are placed under the common-masters folder which is under the tenant folder of the MDMS repository.

• The common master data across all ULBs and are module-specific are placed in a folder named after each module. These folders are placed directly under the tenant folder.

ULB Level Master Configuration

• Module data that are specific to each ULB like boundary data, interest, penalty, etc are configured at the ULB level. There will be a folder per ULB under the tenant folder and all the ULB’s module-specific data are placed under this folder.

Reference Docs

Doc Links

API List

DIGIT environment setup is conducted at two levels.

Objective

Content of pages within this document is designed to help implementation parties and end-users in providing the required data in minimal interaction and iterations and ensure the quality, consistency and shape of data needed to configure into the system.

Audience

This page is intended to help stakeholders as given below on data gathering activities.

1. State Team

2. eGov Onsite Team/ Implementation Team

3. ULB Team (Nodal and DEO)

4. Implementation Partners

Output Artefacts

The artefacts of this document are the data template of a configurable entity, a page with content defining the entity template and helping on how to fill the template with required data.

All content on this page by is licensed under a .

Key configurations at the state level include -

• Tenants Information

• SMS Account Configuration

• Email Account Configuration

• Google Play Store Account

• Payment Gateway Configuration

• POS Configuration

• Domain Name Configuration

• SSL Configuration

• ULB Departments

• ULB Designations

• Localization

• Google Map Configuration

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

Introduction

The SMS service is a way of communicating necessary information/updates to the users on their various transactions on DIGIT applications.

In order to update the users, there are certain notification parameters that are system configured for various steps in the application process. These configurations can be changed/reconfigured based upon the ULB requirements.

Data Table

We have the below-mentioned parameters which we use for configuration:

Procedure

For the SMS service to be integrated there are various things for which the vendor more or less guides us for the steps to be followed but below mentioned are a few basic steps and the generic data definitions which could be followed.

Data Definition

Below mentioned are the descriptions of the parameters which are needed for configuration:

Steps to fill Data

Since the SMS service is a vendor delivered service for which the below steps would have to be followed:

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. The SMS vendor has to provide the data in the data template attached.

5. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

An Urban Local Body (ULB) is defined as a tenant. The information which describes the various attributes of a ULB is known as tenant information. This detail is required to add the ULB into the system.

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you and discuss the same to clear out the doubts.

5. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

6. Verify the data once again by going through the checklist by taking care of each and every point mentioned in the checklist.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.

Attachments

Introduction

Whenever an android mobile App is developed it has to be published on the Google play store in order to let the users avail its service. This page provides information about configuring the google play store account to make DIGIT mobile apps available for easy download.

Data Table

In order to start the configuration for the google play store following would be required:

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the state team/client to create an email account on Gmail.

5. Ask the client to log in to the google play console and make the required payment so that further tasks could be processed.

6. Ask the client to share the email id and password in the template.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

SSL is Secure Sockets Layer is an encryption-based network security protocol developed for the assurance of privacy, authenticity and data integrity in internet communications.

Ideally, the domain name configuration and the SSL certification are obtained consecutively without fail from the state’s IT team.

No data is needed from the state team for this.

Data Table

Not Applicable

Procedure

Not Applicable

Data Definition

Not Applicable

Steps to fill data

Not Applicable

Checklist

Not Applicable

Attachments

Not Applicable

Introduction

DIGIT has modules which require the user to pay for the service that he/ she is availing for example property tax, trade license etc. . In order to achieve the functionality, we have a common payment gateway developed which acts a liaison between DIGIT apps and external payment gateways (which depends on the client requirements).

This module facilitates payments and lookup of transaction status.

Data Table

Following are the details required from the payment gateway vendor in order to configure the payment gateway:

Procedure

Data Definition

Steps to fill data

The payment gateway is a vendor oriented service that is integrated with different modules in order to facilitate the transactions. Below mentioned are the steps which are followed:

1. The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. After which the details/ documents mentioned in the template would be provided by the vendor.

5. These details are to be received separately for both prods as well as UAT.

6. Get the IP address for UAT and Production environments whitelisted from the vendor.

7. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

An email account of the client/state team has to be set up in order to receive/send the email notifications.

In order to achieve the functionality, an email account has to be set up at there server since most of the states would defer from creating an account with the Gmail/public server. Further, this email account has to be integrated with the various DIGIT modules.

Data Table

In order to achieve the above functionality, we require the below-mentioned details

Procedure

Data Definition

Steps to fill Data

Below steps could be followed in order to fill the template:

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the state to gather all the data related to the technical configuration from the email server settings.

5. Get the attached template filled from the state and a sample data is provided in the data table section for reference.

6. The data would be available in the POP and IMAP account settings at the server level.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

Introduction

Point of Sales (POS) machine is a machine that helps in handling transaction processing. This machine accepts and verifies the payments which are made by citizens for prevailing the services of DIGIT.

POS facilitates a middleware app developed in order to verify the payment process between the DIGIT module and the payment.

In this case, no data is required from the state team.

Data Table

Not applicable.

Procedure

Not applicable.

Checklist

Not applicable.

Attachments

Not applicable.

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

Introduction

The domain name is the address through which the internet users can access the website rather than entering the whole IP address in the search bar of the browser.

This domain name is ideally chosen by the state/client since its a product which has to be used for/by them.

Data Table

Following is the table through which the information can be shared.

Procedure

Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.

Data Definition

Steps to fill data

Following are the steps which are to be followed:

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.

5. If the state disagrees to host on their server, then a domain name has to be purchased by any of the external vendors and the EXTERNAL-IP address has to be mapped with them.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity:

Attachments

Introduction

The departments are defined as different sections within the ULB based on which the functions performed by ULBs and employees in ULB are grouped. The budgets details of the ULBs are also defined by the department. It is suggested that the ULB across the state adopt the same department naming terminology. This document will help you in filling the department detail in the template provided.

Data Table

Procedure

Data Definition

Steps to Fill Data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

5. Identify all the departments in ULB well before start filling then into the template.

6. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed after 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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.

Attachments

Introduction

A designation is an act of pointing someone out with a name, a title or an assignment. For example, someone being named president of an organization. This document is to help to gather various designations data which are generally used in ULBs.

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

5. Identify all the designations exists in the ULB, refer to governments gazette to define the designations in ULBs.

6. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

7. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed after 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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.

Attachments

Introduction

Localization is a practice to localize various UI visible data into the local wordings according to the client's requirements. This practice of localization is enforced on various clients so that it becomes easier for the people using the service to understand the common terminology and make the best use of the available system.

The following texts (but not limited to) on the web page can be localized:

1. Labels

2. Messages: Alert messages, success messages, validation messages and other notifications etc.

3. Help Texts

Data Table

Procedure

Data Definition

Steps to fill Data

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Present the client the full sheet of codes as well as the English language for which the localized texts are required.

5. Ask the client to fill the localized text in the last column which is the message(local language) column.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

ULB level setup involves the configuration of ULB specific data parameters such as ULB boundaries, ULB bank accounts, and hierarchy details.

• Boundary Hierarchies

• Boundary Data

• Cross Hierarchy Mapping

• ULB Bank Accounts

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

Introduction

A ULB is divided into certain categories of boundaries by ULB administrative authorities in order to carry out ULB’s functions better. A ULB/City could be divided by a different set of delimitation of boundaries based on functions as given below.

1. Revenue - Delimitation of ULB into boundaries to perform the target setting and collection of revenue.

2. Administration - Delimitation of ULB into boundaries for the better administration of ULB.

3. Locality/ Location - Delimitation of ULB into boundaries based on the places known to citizen with names and easily identifiable by the common person.

All these authorities have designated certain levels of boundary classification for a certain ULB.

Data Table

The below mention table is used to collect data for the types of hierarchy being followed:

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Identify all the types of boundaries which are being used in the state in order to carry out various administrative/revenue functions.

5. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

6. Then fill up the hierarchy types and the codes in the respective columns in the template.

7. Code should be created for the type of boundary being classified.

8. A brief description of the boundary hierarchy type would be helpful.

9. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

This is the 3rd step that comes after the boundary data collection. Cross hierarchy mapping happens in case a child has a relationship with more than 2 parents. This double relationship between the child and parents could happen between different hierarchies as well.

For example: In Admin level boundary hierarchy a mohalla M1(child) could be a part of 2 Wards(parent) W1 and W2. In such a case a single Mohalla(child) has to be mapped to 2 Wards(parent).

Data Table

Below is the data table for the Boundary:

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Firstly Identify all the child levels which have a relation with more than 2 parent boundary types and their hierarchy types as well.

5. Fill up the boundary hierarchy (names/ codes) types in place of boundary type 1/2.

6. Then along with the codes start filling in one by one with the proper mapping between every child and parent.

7. The Sr. No should be in an incremental order for every new child level.

8. Prepare a new table for every different parent-child relation.

9. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist activity applicable here.

Attachments

Introduction

This is the next step after collating all the boundary hierarchies which are being used in the state. In a hierarchy, there are certain types of boundary classification and in all the levels there will be a mapping which we could define as a parent-child mapping in order to link certain levels of the classification.

For example, a hierarchy could be:

Administration Hierarchy: City/ULB → Zone → Ward → Locality

In the above-mentioned hierarchy, a City/ULB is being divided into different into zones followed by zones into wards and at the end wards into the locality.

Data Table

Data has to be collected for every boundary hierarchy type and boundary type with a mapping between the boundary code and its parent boundary code. Following is the table which is to be used across all the hierarchy types.

Procedure

Data Definition

Following is the definition of the data columns which are being used in the template:

Steps to fill data

Following are the steps which should be used to fill the template:

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. After Identifying all the boundary hierarchy, get the sub-classification of all the hierarchies.

5. Figure out the codes for all the sub-classification for a particular city/ULB.

6. Start filling the template from the top of the hierarchy in a drill-down approach.

7. A parent-child mapping code has to be created for every boundary level except for the top level.

8. Follow the steps until you reach the last sub-classification.

9. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

It is a ULB bank account which is operative at least to receive or deposit the day to day revenue collection done by the ULB. It is used by online payment integrator to disburse the amount in ULBs accounts which have been collected through a payment gateway into a pool account managed by the payment gateway.

Data Table

Below given data table represents the excel template attached. Data given in the table is a sample data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.

3. Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

4. Identify the bank account which is to be used to transfer the amount which is collected online for various services.

5. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

6. Verify the data once again by going through the checklist and taking care of each and every checklist point/ activity mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed after 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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

At times in the different modules, there is a need to capture the address of the user’s place of residence or where the person is doing a trade, for which the user has to enter his/her full address which creates a task. In order to simplify the process, we can have google map geolocation service in place which would help us get the exact coordinates of the place on the map and help us identify the place.

This service is paid and the client has to purchase the below items:

Data Table

Note:

Procedure

Data Definition

Steps to fill the data

1. Download the data template attached to this page.

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

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Ask the clients to purchase the above-mentioned APIs in the Introduction section.

5. Get the details for the API URL and key from the client.

6. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

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.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

Not Applicable

Attachments

States and ULBs can configure their web portal to deploy the DIGIT portal effectively. State-level and ULB level web portal configuration details are covered in this section.

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

Master data templates allow users to configure the key parameters and details required for the effective functioning of the modules. This section offers comprehensive information on how to configure the master data templates for each module.

The individual master data templates for specific modules are availed in the Product & Modules section of our docs. Click on the links given below to navigate to view the specific module setup details.

Property Tax Master Data Templates

Trade License Master Data Templates

PGR Master Data Templates

Water Charges Master Data Templates

Sewerage Charges Master Data Templates

mCollect Master Data Templates

OBPAS Master Data Templates

Finance Master Data Templates

Fire NOC Master Data Templates

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