Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Key configurations at the state level include -
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
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.
Following are the details required from the payment gateway vendor in order to configure the payment gateway:
Sr. No | Integration Kit | API Documentation | Redirect Working Key | Merchant Id | Test credential of Debit Card/ Net banking |
---|
Data given in the table is a sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|
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:
The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.
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.
After which the details/ documents mentioned in the template would be provided by the vendor.
These details are to be received separately for both prods as well as UAT.
Get the IP address for UAT and Production environments whitelisted from the vendor.
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.
This checklist covers the activities which are specific to the entity.
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.
In order to start the configuration for the google play store following would be required:
Sr. No | Email Id | Password |
---|
Data given in the table is sample data.
Sr. No. | Column Name | Data Type | Data Size | Mandatory | Description |
---|
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.
Ask the state team/client to create an email account on Gmail.
Ask the client to log in to the google play console and make the required payment so that further tasks could be processed.
Ask the client to share the email id and password in the template.
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.
This checklist covers the activities which are specific to the entity.
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.
We have the below-mentioned parameters which we use for configuration:
Sr. No. | Parameter | Value |
---|
The data given in the above table is sample data. The parameters and its values are SMS service provided specific and may vary accordingly.
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.
Below mentioned are the descriptions of the parameters which are needed for configuration:
Sr. No. | Column Name | Data Type | Data Size | Mandatory | Description |
---|
Parameter names could differ from vendor to vendor.
Since the SMS service is a vendor delivered service for which the below steps would have to be followed:
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.
The SMS vendor has to provide the data in the data template attached.
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.
This checklist covers the activities which are specific to the entity.
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.
Sr. No. | Department Code* | Department name (In English)* | Department Name (In Local Language)* |
---|
Data given in the table is a sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are 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.
Identify all the departments in ULB well before start filling then into the template.
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.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.
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.
Following is the table through which the information can be shared.
Sr. No. | Domain Name | EXTERNAL-IP |
---|
Data given in the table is a sample data.
Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|
Following are the steps which are to be followed:
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.
If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.
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.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity:
DIGIT environment setup is conducted at two levels.
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:
Google Map API's
"Maps Javascript API", "Places API" and "Geolocation API" are needed and first 200$ usages are free, once it exceeds, the price per 1000 requests as given below.
Maps JavaScript API (web-client) Return the location and accuracy radius of a device, based on Wi-Fi or cell towers. $5
Geolocation API Return the location and accuracy radius of a device, based on Wi-Fi or cell towers. $5
Places API for Web (web-server) Turn a phone number, address, or name into a place, and provide its name and address. $17
Sr. No | Google API URL* | API Key* |
---|
Note:
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|
The data provided 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.
Ask the clients to purchase the above-mentioned APIs in the Introduction section.
Get the details for the API URL and key from the client.
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.
Not Applicable
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.
Not applicable.
Not applicable.
Not applicable.
Not applicable.
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Sr. No. | Checklist Parameter | Example |
---|
Sr. No. | Checklist Parameter | Example |
---|
All content on this page by is licensed under a .
Sr. No. | Checklist Parameter | Example |
---|
Sr. No. | Checklist Parameter | Example |
---|
All content on this page by is licensed under a .
Sr. No. | Checklist Parameter | Example |
---|
Sr. No. | Checklist Parameter | Example |
---|
All content on this page by is licensed under a .
To see the common checklist refer to the page consisting of all the activities which are to be followed to ensure complete and quality data.
All content on this page by is licensed under a .
Sr. No. | Checklist Parameter | Example |
---|
Sr. No. | Checklist Parameter | Example |
---|
All content on this page by is licensed under a .
Sr. No. | Checklist Parameter | Example |
---|
All content on this page by is licensed under a .
1. | File Name | File Name | XYZ#123 | UDDUK | File Name |
1 | Integration Kit | Document | NA | Yes | This is a document that is sent by the vendor which contains information on how to integrate the service |
2 | API Documentation | Document | NA | Yes | This is a separate document which is sent by the vendor in order to help ideally helps us to retrieve the transaction status |
3 | Redirect Working Key | Alphanumeric | 64 | Yes | The working key is provided by the vendor for the generation of the redirection URL |
4 | Merchant Id | Alphanumeric | 64 | Yes | Merchant id provided by the vendor |
5 | Test credential of Debit Card/ Net Banking | Document | NA | Yes | These are the details of the debit/credit card or net banking credentials which would help us test the gateway This contains the card number/Code/Account number etc. |
1 | While finalizing a payment gateway vendor make sure that the vendor should support transactions into multiple bank accounts based on the key( which would be tenantid) | - |
2 | Do get the details for both the environments separately i.e UAT and Production | - |
1 | Make sure that the email account is created on Gmail since the play store works on Google accounts only | - |
2 | Email Id and Password is required in order to login to the google play store for configuration | - |
1 | sms.provider.url | www.xyz.com |
2 | sms.username.parameter | mnsbihar@001 |
3 | sms.username.value | *** |
1 | Parameter | Alphanumeric | 64 | Yes | The parameter required to be configured |
2 | Value | Alphanumeric | 64 | Yes | The corresponding value of the parameter |
1 | Make sure that the vendor should support multiple language functionality and especially the local language of the state. | - |
1 | ACC | Accounts | लेखा |
2 | PHS | Public Health And Sanitation | सार्वजनिक स्वास्थ्य और स्वच्छता |
3 | REV | Revenue | राजस्व |
4 | TP | Town Planning | नगर नियोजन |
1 | Department Code* | Alphanumeric | 64 | Yes | Unique code for the department to identify a department |
2 | Department Name ( In English)* | Text | 256 | Yes | The name of the department in the ULB in English |
3 | Department Name (In Local Language)* | Text | 256 | Yes | The name of the department working in the ULB in local language e.g. Telugu, Hindi etc. whichever is applicable |
No mistake should be done in providing the EXTERNAL-IP address | - |
2. | Only one domain name and its corresponding IP address have to be provided | - |
1 | Make sure that each and every point in this reference list has been taken care of |
1. | ******* |
1 | Email Id | Alphanumeric | NA | Yes | Gmail account id through which the app would be published on the google play store |
2 | Password | Alphanumeric | NA | Yes | Password for the Gmail account |
1 | Make sure that each and every point in this reference list has been taken care of |
1 | Make sure that each and every point in this reference list has been taken care of. |
192.78.98.12 |
Domain Name | Alphanumeric | 253 | Yes | The name/address of the website being used to access the website/ module |
EXTERNAL-IP | Alphanumeric | 32 | Yes | It is the IP address that has to be mapped to the domain name |
1 | Make sure that each and every point in this reference list has been taken care of. |
1458-ASD785-987722 |
Google API URL | Alphanumeric | 64 | Yes | The URL of the API that is being purchased |
2. | API Key | Alphanumeric | 64 | Yes | The key which the google would provide after the purchase for the API has been done |
1 | Make sure that each and every point in this reference list has been taken care of |
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 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.
Sr. No. | Boundary Code* | Boundary Name* (In English) | Boundary Name* ( In Local Language) | Parent Boundary Code* | Boundary Type* | Hierarchy Type Code* |
---|---|---|---|---|---|---|
Data given in the table is a sample data.
Following is the definition of the data columns which are being used in the template:
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|---|---|---|---|---|
Following are the steps which should be used to fill the template:
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.
After Identifying all the boundary hierarchy, get the sub-classification of all the hierarchies.
Figure out the codes for all the sub-classification for a particular city/ULB.
Start filling the template from the top of the hierarchy in a drill-down approach.
A parent-child mapping code has to be created for every boundary level except for the top level.
Follow the steps until you reach the last sub-classification.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
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.
Sr. No. | Designation Code* | Designation Name* (In English ) | Designation Name* (In Local Language) |
---|---|---|---|
Data given in the table is a sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|---|---|---|---|---|
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are 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.
Identify all the designations exists in the ULB, refer to governments gazette to define the designations in ULBs.
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.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
To see the common checklist refer to the Checklist page consisting of all the activities which are to be followed to ensure complete and quality data.
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist is applicable for this entity.
ULB level setup involves the configuration of ULB specific data parameters such as ULB boundaries, ULB bank accounts, and hierarchy details.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
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:
Labels
Messages: Alert messages, success messages, validation messages and other notifications etc.
Help Texts
The module-specific master data would already have been made available in the localized form while collecting the data for the respective module-specific configuration.
Sr. No. | Code* | Module* | Message (In English)* | Message (In Local Language)* |
---|---|---|---|---|
Data mentioned in the data table is a sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|---|---|---|---|---|
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.
Present the client the full sheet of codes as well as the English language for which the localized texts are required.
Ask the client to fill the localized text in the last column which is the message(local language) 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.
This checklist covers all the activities which are common across the entities.
Not Applicable
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.
Revenue - Delimitation of ULB into boundaries to perform the target setting and collection of revenue.
Administration - Delimitation of ULB into boundaries for the better administration of ULB.
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.
The below mention table is used to collect data for the types of hierarchy being followed:
Sr. No. | Code* | Boundary Hierarchy Type* | Description |
---|---|---|---|
The above-mentioned data for the boundary hierarchy is sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|---|---|---|---|---|
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 types of boundaries which are being used in the state in order to carry out various administrative/revenue functions.
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.
Then fill up the hierarchy types and the codes in the respective columns in the template.
Code should be created for the type of boundary being classified.
A brief description of the boundary hierarchy type would be helpful.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity.
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.
In order to achieve the above functionality, we require the below-mentioned details
Sr. No. | Email ID | Your Name | Account Type | Incoming Mail Server | Outgoing Mail Server (SMTP) | Password | Incoming Server POP3 Port | Outgoing server SMTP Port | Encrypted Connection Type | Days after which the email should be removed from the server |
---|---|---|---|---|---|---|---|---|---|---|
The values mentioned here are sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|---|---|---|---|---|
Below steps could be followed in order to fill the template:
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.
Ask the state to gather all the data related to the technical configuration from the email server settings.
Get the attached template filled from the state and a sample data is provided in the data table section for reference.
The data would be available in the POP and IMAP account settings at the server level.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
Not Applicable
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.
S. No. | ULB Name* | ULB Code* | ULB Grade* | City Name* | City Local Name | District Name* | District Code* | Region Name | Region Code |
---|---|---|---|---|---|---|---|---|---|
Contact Number* | Address* | ULB Website* | Latitude | Longitude | Email Address | GIS Location Link | Call Center No. | Facebook Link | Twitter Link | Logo file Path* |
---|---|---|---|---|---|---|---|---|---|---|
Data given in the table is a sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|---|---|---|---|---|
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.
Make sure all the headers, its data type, field size and its definition/ description are understood properly.
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.
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.
Verify the data once again by going through the checklist by taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
To see common checklist refer to the page Checklist consisting of all the activities which are to be followed to ensure completeness and quality of data.
This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.
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.
Below given data table represents the excel template attached. Data given in the table is a sample data.
Sr. No. | Code* | ULB Name* | Bank Name* | Branch Name* | Account Number* | Account Type* | IFSC* |
---|---|---|---|---|---|---|---|
Data given in the table is sample data.
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory | Definition/ Description |
---|---|---|---|---|---|
Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
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.
Identify the bank account which is to be used to transfer the amount which is collected online for various services.
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.
Verify the data once again by going through the checklist and taking care of each and every checklist point/ activity mentioned in the 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.
This checklist covers all the activities which are common across the entities.
To see the common checklist refer to the page Checklist consisting of all the activities which are to be followed to ensure complete and quality data.
This checklist covers the activities which are specific to the entity.
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).
Below is the data table for the Boundary:
Hierarchy Type | Hierarchy Type 1* | Hierarchy Type 2* | ||
---|---|---|---|---|
Sr. No. | Column Name | Data Type | Data Size | Is Mandatory? | Definition/ Description |
---|---|---|---|---|---|
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 child levels which have a relation with more than 2 parent boundary types and their hierarchy types as well.
Fill up the boundary hierarchy (names/ codes) types in place of boundary type 1/2.
Then along with the codes start filling in one by one with the proper mapping between every child and parent.
The Sr. No should be in an incremental order for every new child level.
Prepare a new table for every different parent-child relation.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the 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.
This checklist covers all the activities which are common across the entities.
This checklist covers the activities which are specific to the entity. There is no entity-specific checklist activity applicable here.
Sr. No. | Activity | Example |
---|---|---|
Sr. No. | Activity | Example |
---|---|---|
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.
Sr. No. | Checklist Parameter | Example |
---|---|---|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Sr. No. | Checklist Parameter | Example |
---|---|---|
Sr. No. | Checklist Parameter | Example |
---|---|---|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Sr. No. | Checklist Parameter | Example |
---|---|---|
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.
Sr. No. | Checklist Parameter | Example |
---|---|---|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
1
W1
Ward no.1
वार्ड नंबर 1
Z1
Ward
ADM
2
W2
Ward no.2
वार्ड नंबर 2
Z1
Ward
ADM
3
W3
Ward no.3
वार्ड नंबर 3
Z2
Ward
ADM
4
W4
Ward no.4
वार्ड नंबर 4
Z3
Ward
ADM
1
Boundary Code
Alphanumeric
64
Yes
This is a code for the sub-classification for a particular boundary. Should be unique across all boundaries defined
2
Boundary Name (In English)
Text
256
Yes
The name of the boundary that is being defined in the English language
3
Boundary Name (In Local Language)
Text
256
Yes
The name of the boundary that is being defined in the local language of the state e.g. Telugu, Hindi etc.
4
Parent Boundary Code
Alphanumeric
64
Yes
This is the boundary code of the parent which identifies to which parent the child belongs to
5
Boundary Type
Text
256
Yes
The name of the boundary type i.e. Ward, Zone etc.
6
Hierarchy Type Code
Alphanumeric
64
Yes
The code of the Boundary Hierarchies for which this particular boundary is defined
1
Make sure that each and every point in this reference list has been taken care of
1
Every boundary type of data should be filled separately
-
1
ACT
Accountant
अकाउंटेंट
2
AO
Accounts Officer
लेखा अधिकारी
3
AC
Additional Commissioner
अपर आयुक्त
1
Designation Code
Alphanumeric
64
Yes
Unique Identifier for designation which is used as a reference for child configuration mapping
2
Designation Name (In English)
Text
256
Yes
Designation name in English
3
Designation Name (In Local Language)
Text
256
Yes
Designation Name in the local language. e.g. Hindi, Telugu etc. whichever is applicable
1
ACTION_TEXT_APPLICATION
Trade License
Search Trade Licenses
व्यापार लाइसेंस खोजें
2
ACTION_TEST_TL_REPORTS
Trade License
Trade License Reports
ट्रेड लाइसेंस रिपोर्ट
3
CORE_COMMON_CITY
Property Tax
City
शहर
1
Code
Alphanumeric
64
Yes
The code for which the localized language is to be provided
2
Module
Alphanumeric
64
Yes
The module in which the code belongs to
3
Message(In English)
Text
256
Yes
The English language that is being displayed on the UI
4
Message(In Local Language)
Text
256
Yes
The text in the local language that the client wants to be displayed
1
Make sure that each and every point in this reference list has been taken care of
1
ADM
Administration
Administration level boundary classified on the basis of administrative functions such as scrutinize certain rules and regulations
2
REV
Revenue
Revenue-based classification of a ULB is done on the basis of revenue collection
3
LOC
Locality
Location-based classification could be done in order to identify a certain place. For example, Locality of a house of a citizen could follow the below hierarchy:
House no.
Mohalla
Area
Ward
City
1
Code
Alphabet
64
Yes
Code is used to identify a certain classification of the type of boundary hierarchy
2
Boundary Hierarchy Type
Alphanumeric
256
Yes
The meaningful name to define one group of boundaries defined to perform one function
3
Description
Alphanumeric
256
Yes
A brief description of the boundary hierarchy
1
Make sure that each and every point in this reference list has been taken care of
1
Make sure that the hierarchies types should be uniform across all the ULB’s /cities in the state
-
2
Only 3 types of boundary hierarchies are allowed
-
1
Bihar
POP3
SMTP
SMTP
****
192.172.82.12
192.172.82.12
Auto
14
1
Email ID
Alphanumeric
N/A
Yes
Email id which is being configured
2
Your Name
Text
256
Yes
The name on behalf of which the email would be sent in order to receive the updates
3
Account Type
Alphanumeric
64
Yes
The type of email account type protocol which will be used to download messages
4
Incoming Mail Server
Numeric
(12,2)
Yes
The IP address of the email server through which messages would be received
5
Outgoing Mail Server(SMTP)
Numeric
(12,2)
Yes
The IP address of the email server through which messages would be sent
6
Password
Alphanumeric
64
Yes
The password of the email server
7
Incoming Server POP3 Port
Numeric
(12,2)
Yes
The port number through which the emails are received
8
Outgoing server SMTP Port
Numeric
(12,2)
Yes
The port number through which the emails are to be sent
9
Encrypted Connection Type
Alphanumeric
64
Yes
The encryption type which is used for the connection
10
Days after which the email should be removed from the server
Numeric
(12,2)
Yes
The number of days after which the email should be deleted from the server (not from the local device)
1
Make sure that each and every point in this reference list has been taken care of
1
Sonepur Nagar Panchayat
47
Corp
Sonepur
Sonepur
Banka
BN47
Bihar
BBD47
98362532657
Main Hall, Sonepur
24.8874° N
86.9198° E
snp@bihar.gov.in
1
ULB Name
Text
256
Yes
Name of ULB. E.g. Kannur Municipal Corporation/ Saptarishi Municipal Council
2
ULB Code
Alphanumeric
64
Yes
It is a unique identifier which is assigned to each ULB. LGD (Local Government Directory) has already assigned a code urban local bodies and the same is used here
3
ULB Grade
Alphanumeric
64
Yes
Grade of ULB. e.g. Corporation, Municipality, Nagar Panchayat etc
4
City Name
Text
256
Yes
Name of city/ town which is covered by the ULB. E.g. Kannur/ Saptarishi
5
City Local Name
Text
256
No
Name of the city in the local language. e.g Telugu, Hindi etc
6
District Name
Text
256
Yes
Name of the District where the city is situated
7
District Code
Alphanumeric
64
Yes
It is a unique identifier which is assigned to each district. LGD (Local Government Directory) has already assigned code districts and the same is used here
8
Region Name
Text
256
No
Name of the region the listed district belongs to
9
Region Code
Alphanumeric
64
No
Unique code of the region to uniquely identify it
10
Contact Number
Alphanumeric
10
Yes
Contact person phone no. of ULB
11
Address
Text
256
Yes
Postal address of the ULB for the correspondence
12
ULB Website
Alphanumeric
256
Yes
URL address of the website for the ULB
13
Email Address
Alphanumeric
64
No
Email of the address of ULB where the email from the citizen can be received
14
Latitude
Alphanumeric
64
No
Latitude part of coordinates of the centroid of the city
15
Longitude
Alphanumeric
64
No
Longitude part of coordinates of the centroid of the city
16
GIS Location Link
Text
NA
No
GIS Location link of the ULB
17
Call Center No
Alphanumeric
10
No
Call centre contact number of ULB
18
Facebook Link
Text
NA
No
Face book page link of ULB
19
Twitter Link
Text
NA
No
Twitter page link of the ULB
20
Logo file Path
Document
NA
Yes
URL of logo file path to download the logo of ULB
1
dehradun
Dehradun Municipal Corporation
SBI
Rajpur
XXXX0082XX01
Saving
SBIX0921
2
haridwar
Haridwar Municipal Corporation
PNB
Chauk
XXXX9820XX9
Saving
PNBX8320
1
Code
Alphanumeric
64
Yes
Unique code is given to the bank detail record e.g. dehradun
2
ULB Name
Text
256
Yes
Name of Urban Local Body
3
Bank Name
Text
256
Yes
Name of the bank where the account exists
4
Branch Name
Text
256
Yes
Name of the bank branch where the account exists
5
Account Number
Alphanumeric
64
Yes
Bank account number to be used to transfer the amount
6
Account Type
Text
256
Yes
Account type. e.g. Saving, Current etc.
7
IFSC
Alphanumeric
64
Yes
IFS code of branch as per FBI guidelines
Sr. No.
Activity
Example
1
Code should not consist of any special characters
E.g. dehradun is allowed but dehradun@1 is not allowed
2
The account number should not consist of any special characters.
As issued by the bank
Sr.No
Boundary Type*
Boundary Code*
Boundary Type*
Boundary Code*
1
Ward
W1
Mohalla
M1
Ward
W2
Mohalla
M1
2
Ward
W3
Mohalla
M2
Ward
W4
Mohalla
M2
1
Hierarchy Type 1
Text
256
Yes
The type of hierarchy 1 the boundary belongs to which is to be mapped with other boundaries in hierarchy 2. Refer Boundary Hierarchies
2
Hierarchy Type 2
Text
256
Yes
The type of hierarchy 2 the boundary belongs to which is to be mapped with other boundaries in hierarchy 1. Refer Boundary Hierarchies
3
Boundary Type
Text
64
Yes
This is the type of boundary from hierarchy 1. Refer Boundary Data
4
Boundary Code
Alphanumeric
64
Yes
This is the code of the boundary for the boundary from hierarchy 1. Refer Boundary Data
5
Boundary Type
Text
64
Yes
This is the type of boundary from hierarchy 2. Refer Boundary Data
6
Boundary Code
Alphanumeric
64
Yes
This is the code of the boundary for the boundary from hierarchy 2. Refer Boundary Data
1
Make sure that each and every point in this reference list has been taken care of