Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 here 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.
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
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 is licensed under a .
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 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 | 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 |
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.
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.
This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.
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.
DIGIT environment setup is conducted at two levels.
To see common checklist refer to the page consisting of all the activities which are to be followed to ensure completeness and quality of 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 .
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 | 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 | Make sure that each and every point in this reference list has been taken care of |
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
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.
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.
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 eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
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 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:
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.
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
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
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.
This checklist covers the activities which are specific to the 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 is licensed under a .
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.
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 |
---|---|---|
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.
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 |
---|
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 .
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
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 each and every point in this reference list has been taken care of.
1
Make sure that the vendor should support multiple language functionality and especially the local language of the state.
-
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.
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
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 | 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 |
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:
|
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 the hierarchies types should be uniform across all the ULB’s /cities in the state | - |
2 | Only 3 types of boundary hierarchies are allowed | - |
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 |
1 | Make sure that each and every point in this reference list has been taken care of |
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.
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.
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. | 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.
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
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
-