Introduction
Construction or renovation of buildings is regulated by Municipal Body in India. One must get permission from ULB prior to construction . This process involves submitting the building plan to ULB along with other documents, ULB verifies the plan with other documents and approves the construction. The document which authorizes the construction is called “Permit Order” One must have this permit order with him till the completion of construction. ULB officials will inspect various stages of construction and make sure it is compliance to the plan . When construction completed ,after inspection Secretary provides “Completion certificate” and finally will provide “Occupancy Certificate”. This entire process is known as “Building Plan Approval”.
Prerequisites
BPA is one the revenue module among the eGov ERP. This module depends on Demand, Collection, Employee information system, DCR, financial, Common masters, Portal and infrastructure modules. These are the required dependent modules for BPA.
The overall ERP product suite is divided into modules, with each module being loosely coupled with the other modules. Only modules which are required for BPA are grouped in this branch. In eGov-erp and eGov-ear modules, pom.xml used to define dependency modules.
Deployment Configuration
State Wide/City wise implementation
Centralized Server hosting all the ULBs within a state
All ULBs access the software over the browser. There is no offline system.
.
Separate Database for each ULB.
Dashboard to aggregate data across ULBs for state-level analysis
Functionality
This section covers the high-level details of the functionalities available in the Building Plan Application system.
- State level registration of stakeholders
- State specific restriction for stakeholder application submission
- Centralized login page for citizen,official and stakeholders
- Citizen functionalities
- Online application submission - New construction, Additional/Alteration, Demolition etc
- Occupancy certificate request
- Pay fee online and generate permit order online
- Inspection of applications and online status
- Configurable workflow
- Schedule of appointment for document scrutiny and inspection
- Auto fee calculation
- Dash board and reports
- State specific format output and reports
- Online and off line payment collection
- Integration with NOC system
- Inspection pre,post and under construction stages.
- Rejection process
- Revocation process
- Renewal of permit order
- Configurable functionalities
Flow Diagram
End to end flow diagram of the BPA system looks like below-
| View file | ||||
|---|---|---|---|---|
|
Sequence Diagram
ER Diagram
New application
| View file | ||||
|---|---|---|---|---|
|
Inspection
| View file | ||||
|---|---|---|---|---|
|
General Instructions for Development
- All the database scripts are structured in standard format. Each module specific scripts are arranged in sample and main folder. Sample script used for development purpose. The database script include DDL and DML scripts.
City specific data will be saved in concerned city folder script of implementation branch.
- All the report templates are under reports template folder
Configurations and Setup
BPA allows configuring the system for different client requirements. These changes are configurable from UI. The configuration keys are detailed here.
Steps to setup client specific repository in eclipse:
1) Clone impl repo like below.git clone https://github.com/egovernments/eGov-Bihar-Implementation.git
2) Import impl repo to eclipse (digit-bpa workspace).
3) Add Impl egov-ear to server and remove digit-bpa egov ear.
4) Point the impl settings.xml in maven>user settings.
5) Delete temp/data and ear file from deployments folder and redeploy to wildfly.
| Key Name | Description | Data Type | Default Value | Allowed Values |
|---|---|---|---|---|
AUTO_CANCEL_UNATTENDED_DOCUMENT_SCRUTINY_OC | Flag to cancel the occupancy application for which the citizen is not attended for document scrutiny on the scheduled time | String | YES | YES, NO |
| BPA_CITIZENACCEPTANCE_CHECK | Is Citizen acceptance of application is required after stakeholder apply for a permit on behalf of citizen | String | YES | YES, NO |
| BPA_DEFAULT_FUNCTIONARY_CODE | Function code to be used for posting a voucher to the Financials system | Number | 1 | Code from Functionary master |
| BPA_DEFAULT_FUND_CODE | Fund code to be used for posting a voucher to the Financials system | Number | 1 | Code from Fund master |
| BPA_DEFAULT_FUND_SRC_CODE | The fund source code to be used for posting a voucher to the Financials system | Number | 1 | Code from Fund Source master |
| BPA_DEPARTMENT_CODE | Department code to be used for posting a voucher to the Financials system | String | REV | Code from Department master |
| BPA_FEE_CALCULATION | Permit fee calculation types AUTOFEECAL: Calculation by the system with defined rules AUTOFEECAL_EDIT: Calculation by the system with defined rules but officials can override these values MANUAL: Manually calculated by officials and entered into the system | String | AUTOFEECAL | AUTOFEECAL, AUTOFEECAL_EDIT, MANUAL |
| BPA_GENERIC_BOUNDARY_CONFIGURATION | The Boundary configuration. What are the type of boundaries application has to capture during new application creation. Here validBoundary → "REVENUE" refers to the hierarchy type. The data Should match with eg_hierarchy_type table, "Name" column data. Here validBoundary → "REVENUE" → "boundary": "Zone" referes "eg_boundary_type" table data. The data Should match with the eg_boundary_type table → "Name" column. The "hierarchy" column of "eg_boundary_type" table used to define the order of boundary to show in the UI. All the boundary data are mandatory as per current design which are defined in the configuration. Use "uniformBoundary" to autopopulate values on selection of boundary. Similarly Use "crossBoundary" to autopopulate values on selection of boundary if the boundaries are not related to each other. | Json | {"validBoundary": {"REVENUE": [{"boundary": "Zone", "displayName": "Circle"}, {"boundary": "Ward", "displayName": "Revenue Ward"}]}, "crossBoundary":{}, "uniformBoundary": {"REVENUE": [{"fromBoundary": "Zone:Circle", "toBoundary": "Ward:Revenue Ward"}]}} | A Defined structured JSON, one example is given in default value |
| BPA_ONLINE_PAY | Flag to enable online payment | String | YES | YES, NO |
| BPA_WORKFLOW_EMPLOYEE_BOUNDARY_HIERARCHY | Boundary hierarchy type for the employee when the workflow runs on employee jurisdiction | String | REVENUE | Code from Hierarchy Master |
| BPAPRIMARYDEPARTMENT | Building plan primary department | String | Town Planning | Name from Department Master |
| BUILDING_LICENSEE_REG_FEE_REQUIRED | Flag to collect registration fee or not for stakeholder registration | String | YES | YES, NO |
| BUILDINGDETAILSVALIDATIONREQUIRED | Flag to check whether building floor details validation required or not | String | YES | YES, NO |
| DCR_DOC_AUTO_POPULATE_AND_MANUAL_UPLOAD | Flag to populate required/available documents from eDCR in the Permit application. If this flag is YES then application allows overriding populated documents If this flag is NO then the application will not allow overriding populated documents | String | NO | YES, NO |
| DCR_DOC_AUTO_POPULATE_UPLOAD | Flag to populate required/available documents from eDCR in the Permit application. No override | String | NO | YES, NO |
| DCR_DOC_MANUAL_UPLOAD | Manually upload the all plan-related documents | String | YES | YES, NO |
| DCR_INTEGRATION_REQUIRE_WITH_BPA | Fag to know whether eDCR system integration is required or not with application process system | String | YES | YES, NO |
| DCRPDFQRCODEENABLED | Flag to |
stamp the plan scrutiny documents submitted by citizen or not | String | 1 | TRUE, FALSE | |
| DOCUMENT_SCRUTINY_INTEGRATION_REQUIRED | Flag to enable/disable document scrutiny for Permit application | String | NO | YES, NO |
| GAPFORSCHEDULING | The delay or gap of days for scheduling document scrutiny with citizen from the date of application. This is for permit application. | Number | 2 | Any integer number indicating no.of days |
| GAPFORSCHEDULINGOC | The delay or gap of days for scheduling document scrutiny with citizen from the date of application. This is for Occupancy application | Number | 0 | Any integer number indicating no.of days |
GAPFORSCHEDULINGONEDAYPERMITAPPLICATIONS | The delay or gap of days for scheduling document scrutiny with citizen from the date of application. This is for One Day Permit application | Number | 2 | Any integer number indicating no.of days |
| HELPLINENUMBER | Helpline number for Citizen in case he/she wants to re-schedule his/her appointment | Number | 4952362100 | Valid telephone number |
IS_AUTO_CANCEL_UNATTENDED_DOCUMENT_SCRUTINY_APPLICATION | Flag to cancel the permit application for which the citizen is not attended for document scrutiny on the scheduled time | String | YES | YES, NO |
| MERGEPERMITEDCR | Flag to show eDCR scrutiny report along with the permit order | String | 1 | TRUE, FALSE |
| NOOFDAYSFORASSIGNINGSLOTS | The number of days for which slots to be opened for document scrutiny for Permit application | Number | 1 | Any integer number indicating no.of days |
| NOOFDAYSFORASSIGNINGSLOTSFOROC | The number of days for which slots to be opened for document scrutiny for Occupancy application | Number | 3 | Any integer number indicating no.of days |
| NOOFDAYSFORASSIGNINGSLOTSFORONEDAYPERMIT | The number of days for which slots to be opened for document scrutiny for One Day Permit application | Number | 1 | Any integer number indicating no.of days |
| OC_ALLOW_DEVIATION | The percentage of violation compared to permit order while applying for Occupancy certificate | Number | 5 | Any integer number indicating deviation percentage |
| OC_DOCUMENT_SCRUTINY_INTEGRATION_REQUIRED | Flag to enable/disable document scrutiny for Occupancy application | String | NO | YES, NO |
| OC_FEE_CALCULATION | Occupancy Fee calculation type AUTOFEECAL: Calculation by the system with defined rules AUTOFEECAL_EDIT: Calculation by the system with defined rules but officials can override these values MANUAL: Manually calculated by officials and entered into the system | String | AUTOFEECAL | AUTOFEECAL, AUTOFEECAL_EDIT, MANUAL |
| OC_INSPECTION_SCHEDULE_INTEGRATION_REQUIRED | Flag to allow inspection schedule for OC application | String | YES | YES, NO |
| OCAPPLICATIONFEECOLLECTIONREQUIRED | Flag to generate and collect the application fee for OC | String | NO | YES, NO |
| ONE_DAY_PERMIT_APPLN_INTEGRATION_REQUIRED | Flag to enable/disable application type 'one day permit' | String | YES | YES, NO |
ONE_DAY_PERMIT_INSPECTION_SCHEDULE_INTEGRATION_REQUIRED | Flag to allow inspection schedule for One day permit application | String | NO | YES, NO |
| PDFHEIGHTSUBTRACTIONVALUE | The height in the page where to show/print ULB seal/stamp on eDCR scrutiny report | Number | 50 | Any integer number indicating the height |
| PDFWIDTHSUBTRACTIONVALUE | The width in the page where to show/print ULB seal/stamp on eDCR scrutiny report | Number | 50 | Any integer number indicating the height |
| PERMITAPPLNFEECOLLECTIONREQUIRED | Flag to generate and collect the application fee for permit application | String | YES | YES, NO |
RECENT_DCRRULE_AMENDMENTDATE | The latest eDCR rules amendment date | String | 01/01/2019 | A date in the format dd/MM/yyyy |
DCR_SCRUTINIZED_PLAN_EXPIRY_DAYS | The No.of days that eDCR scrutinized plan is valid from the date of scrutiny | Number | 30 | Any integer number indicating no.of days |
REGULAR_PERMIT_INSPECTION_SCHEDULE_INTEGRATION_REQUIRED | Flag to enable inspection appointment schedule for a permit application | String | YES | YES, NO |
SENDEMAILFROOMBPAMODULE | Flag to enable Email from OBPS module | String | YES | YES, NO |
| SENDSMSFROOMBPAMODULE | Flag to enable SMS from OBPS module | String | YES | YES, NO |
| SLAFORBPAAPPLICATION | Service Level Agreement (SLA) days for a Permit application | Number | 15 | Any integer number indicating no.of days |
| EIS EMPLOYEE JURISDICTION HIERARCHY | The boundary hierarchy for which the employee can be mapped in the jurisdiction | String | ADMINISTRATION | Code from Hierarchy Master |
How to Setup New City/State
Each city/state has their own rule book which explains the flow of application, application input format, notice format, permit format, fee calculation, restrictions for stakeholder, local language support etc. The work flow also decided by city based on the availability of designation or position present in concerned city. The following changes to be add for each city to go live. Each city enabled by adding new schema in the database. Add following data to go live,
- City information
- Boundary information
- Employees information
- Configuration changes
- Workflow (if required)
All the client specific implementations can be grouped in separate branch.
Eg:
https://github.com/egovernments/eGov-Bihar-Implementation
Permit format order changes are added as https://github.com/egovernments/eGov-Bihar-Implementation/blob/master/egov/egov-bihar-impl/src/main/java/org/egov/bihar/bpa/service/notice/impl/PermitOrderFormatImpl_Bihar.java
Support Information
Features of Building plan approval system
References and Notes
Digit BPA Code Base :
https://github.com/egovernments/digit-bpa.git
Client specific implementation Code Reference :
https://github.com/egovernments/eGov-Bihar-Implementation.git