DIGIT-Online Building Permission System (OBPS) enables local government to bring in transparency, accountability and time-bound service for the public. With DIGIT-OBPS, professionals like architects, engineers, supervisors can seek permission for construction of a building from any Urban Local Bodies/District Town and Country Planning/Centre for Municipal Administration with a speedy, hassle-free and user-friendly procedure, online.

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

Introduction

Manual processes related to scrutiny, approval, or rejection of building construction or renovation plans is a time-consuming process for both citizens and employees. The DIGIT OBPAS module automates the entire building plan approval process right from enabling online submission of plans, documents to initiating verification and final approval of the plan. Citizens can now track their plan approval or inspection status, pay fees online, download and print the Permit Order and Occupancy Certificate online. The module streamlines the building plan approval system with configurable workflows for effective management through different phases of approval.

Module Features

• Centralized login page for citizen, officials and stakeholders

• Citizen functionalities

• Online application submission - New construction

• Occupancy certificate request

• Field Inspection Report Capture

• Pay fee online and generate permit order online

• Inspection of applications and online status

• Configurable workflow

• Auto fee calculation

• Online and offline payment collection

• Rejection process

• Revocation process

• Configurable functionalities

Module Ontology

State Level

1. List of services

2. Occupancy

3. Sub Occupancy

4. Usage

5. List of documents for each service

6. Inspection checklist

7. List of stakeholder types

8. Town planning schemes

9. List of NOC departments

ULB Level

1. Fee structure

Module Reports

None as of now.

Introduction

Stakeholders refer to the technical persons and end-users of the OBPS system. The Stakeholders Type masters list allows the registration of stakeholders in the OBPS system. The list of stakeholders varies from one State/ULB to another.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify the stakeholders and fill into the given template. Refer to the National Bye-Laws for more details on stakeholder types and defined limitations.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Configuration Data Templateconfigurable-data-template-stakeholder-type_v1.xlsx - 10KB

Sample Datasample-configuration-data-stakeholder-type.xlsx - 10KB

Introduction

The list of services in the OBPS module refers to the various types of services offered to citizens or end-users. The Data Table below contains an indicative list of services and details required to configure the building plan approval module.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify the services provided by the DIGIT OBPAS system and enter them into the template with other configurable parameters given in the template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Introduction

Service-wise documents list tells about the documents required for processing of listed services. Citizens can view the checklist based on the selected service. States/ULBs can configure the list of supporting documents required for each service.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify the documents which are needed to avail the services and fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Introduction

Building Occupancy classifications help in categorizing structures based on the proposed use of the building. Occupancy categories determine the required permits and approvals. The Building Occupancy types data is hence a vital parameter used to define approval workflows in the OBPS module. Refer to the National Bye-Laws to view the prescribed list of occupancy types.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify the occupancy which is applicable. Refer to National Bye-Laws to learn more about occupancy types and names.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Configauration Data Templateconfiguration-data-template-building-occupancy_v1.xlsx - 10KB

Sample Datasample-occupancy.xlsx - 11KB

About OBPAS

Manual processes related to scrutiny, approval, or rejection of building construction or renovation plans is a time-consuming process for both citizens and employees. The DIGIT OBPAS module automates the entire building plan approval process right from enabling online submission of plans, documents to initiating verification and final approval of the plan. Citizens can now track their plan approval or inspection status, pay fees online, download and print the Permit Order and Occupancy Certificate online. The module streamlines the building plan approval system with configurable workflows for effective management through different phases of approval.

Key Features

• Centralized login page for citizen, officials and stakeholders

• Citizen functionalities

• Online application submission - New construction

• Occupancy certificate request

• Field Inspection Report Capture

• Pay fee online and generate permit order online

• Inspection of applications and online status

• Configurable workflow

• Auto fee calculation

• Online and offline payment collection

• Rejection process

• Revocation process

• Configurable functionalities

Section Overview

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

• Functional Specifications

• OBPAS Roadmap

• OBPAS User Manual

• Product Brochure

• OBPAS Workflows

• Master Data Configuration Template

• OBPAS Service Configuration

• Implementation Handbook

• Demo Script

Contact Us

Reach out to us through any of the below-mentioned contact channels for any assistance or additional information on OBPAS module deployment.

Introduction

Town Planning Schemes masters list contains all building plan approval schemes and sub-schemes available for the benefits of the citizens. Create a list of the available schemes and map these schemes to specific Occupancy Types.

Data Table

Data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify all the scheme and sub-schemes and fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Configuration Data Templateconfigurable-data-template-scheme_v1.xlsx - 10KB

Sample Datatown-planning-scheme-sample.xlsx - 10KB

Introduction

The Inspection checklist contains the list of activities that a field inspector should consider and check while on the field. The checklist is configurable at the State/ULB level.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definitions

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify all the checkpoints service wise and then fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Configuration Data Templateinspection-checklist-template_obps.xlsx - 10KB

Sample Datainspection-checklist-sample_obps.xlsx - 10KB

Introduction

No objection certificates (NOC) are certifications or permissions acquired from various bodies like Airport authority, monument authority, etc before any construction activities actually take place.

To acquire a building permit, an applicant needs to acquire NOC from the concerned authorities. Add the specific authorities at the State/ULB level in the NOC Departments master list for automated processing of NOCs. Refer to the National Bye-Laws for details on State/ULB specific NOC requirements.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify all the departments, services and the approach on integration and then fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Configuration Data Templateconfigurable-data-template-noc-departments_v1.xlsx - 10KB

Sample Datanoc-department-sample.xlsx - 10KB

Introduction

This module enables Architects / Engineers / Supervisors /Town Planners etc. to register Online. Provision to migrate already registered Architects/ Engineers / Supervisors details in the system with current status and validity of registration. Provision to renew the registration.

1. Centralized Registration: Provide a single interface for the registration of all architects (across the state), who intend to do a transaction with the ULBs.

2. Online Application for Registration: Identify the applicant with reference to a unique ID. Capture the following minimum information of the applicant with appropriate validations.

   1. Unique ID

   2. Name

   3. Address

   4. Corporate Information

   5. Certificate from Council of Architecture/ Other authorities

   6. Educational Qualification

3. This module will also consist of the following:-

   1. Facility for uploading of attachments as required by ULB for establishing identity and past experience etc.

   2. Enable online submission of registration fee.

   3. Assigning a unique application number to each applicant.

   4. Enable tracking the status of the application.

Functional Scope

The OBPS product features can be broadly classified as the following modules:

1. Online registration of Architects/ Engineers / Supervisors etc.

2. Online Real Time Scrutiny of Drawing/Plan

3. Submission of Application and uploading Documents

4. Application Process by the Department

5. Online Payment

6. Certificate

7. Notice

8. General requirements

9. Module 1: Online registration of Architects/ Engineers / Supervisors etc.

10. Approval of Applications: Enable the Competent Authority to approve/reject the applications for registration; based on a workflow system and business rules. Communication of successful registration/ rejection to the applicant through an e-mail alert & SMS.

11. Renewal of Registrations: Enable the Competent Authority to renew the applications for registration according to workflow/business rules. Communication of successful renewal will be sent to the applicant through an e-mail alert & SMS.

12. Search: Enable authorized officials to search the database for list of registered architects based on the ‘search’ criteria such as - line of business, turnover, past experience or as decided by ULB.

13. Help: Provide an online handbook and user manual for registration. Provide FAQs on the registration process. ULB official will provide help desk assistance for resolving architects queries on registration process.

14. Module 2: Online Real Time Scrutiny of Drawing/Plan

15. The Module enables the Architect/Engineer to submit the Drawing in Drawing Interchange Format(DXF) format from any Open Source CAD tools of their choice. The condition for the following are:

    1. The drawing should adhere to the Standards stipulated.

    2. The Standards will be provided to the Architect in the native format (DXF) .

16. The Module enables the Architect/Engineer to submit the Application for various Services as listed above along with required supporting documents. Under the current provision, the document checklist will aid the Architect/Engineer.

    1. The scrutiny process is online realtime and the Architect/Engineer will get the detailed Scrutiny report within minutes of submitting the Plan.

    2. Scrutiny reports will list the Bye-laws and sub-clauses with the approved values against the extracted values.

    3. Based on the extracted value range validation will be done by the system.

    4. Only on clearance of all the Rules Scrutinised the Report will reflect ACCEPTED.

    5. On Accepted Report a unique number of the Scrutiny will be generated

17. Scrutiny Parameters for all types of building meant for different usage; as per building bye laws and approved master plan will be taken into scrutiny. The major Plan provisions are as under :

    1. Plot area / shape

    2. Road width details

    3. MOS (Marginal open space)

    4. Ground coverage

    5. FAR (Floor area ratio)

    6. Building height

    7. Use of building (Floor wise including mixed use in floors)

    8. Parking provision

    9. Amenities

    10. Components of building

    11. Services Evaluation

    12. Firefighting requirement

    13. Green building norms

    14. Rain Water Harvesting

    15. Water supply

    16. Water treatment

    17. Solid waste management provisions

    18. NOC required on the basis of drawing details

18. Module 3: Submission and processing of Application

19. The entire process from the time of submission of drawing to scrutiny completion is automatic without any human intervention and instantaneous.

    1. If the Scrutiny report REJECT the drawing the Report will have the details of the clauses in which it was rejected and also the values of the parameters.

    2. The Architect/Engineer can correct the drawing and can resubmit the drawing till he gets the approval.

    3. Only on approval the unique reference number for the Scrutiny Report will be generated.

    4. Only with this number the Submission of Application can be initiated.

20. The OBPS handles the Plan Scrutiny in Online Real time mode and there is no need for any wait time, once the Plan is drawn. Scrutiny gets completed in less than a minute..

21. From the Plan submitted by the Architect the System will generate all the relevant plan in PDF format automatically. These are the set of Plans which will be issued to the end user with certification on successful completion of the Application Process.

22. The Application can be filled and required documents can be uploaded by the Architect once he has the Plan Scrutiny Reference number.

23. On Submission the Citizen need to validate and self certify the Application.

24. Module -4: Application Process by the Department

25. Workflow is configurable as per the requirements and will be done during the Customisation phase of the Project

26. All approvals will be electronically signed (e-sign) with QR code

27. The application captures all relevant details for all internal and external agencies; relevant data needs to be forwarded to corresponding agencies for issuing NOCs.

28. SLA on NOC is also validated by the System. If the required date is passed without a reply from the NOC department the NOC will be taken as Deemed approved.

29. In addition a single window mechanism is also built into the system. This feature can be used by Departments which do not have the IT system for their process in full.

30. Provision for entering onsite inspection details and geo-tagged images (document upload facility) of the Site Inspection.

31. The product has for the staff and the management for viewing the completed and pending tasks / works / applications.

32. The product has features for Online single window system, and integrations with all internal and external agencies required to provide applicable NOCs/approvals (Fire Services, Water and Sewerage Department, Discoms, AAI, NMA, Forest, Labour, Factory Directorate)

33. A Statewide Dashboard is also available which can be used by State Administrators to see the flow of applications and the pendency or exceptions.

34. The product offers Security on User Authentication with Role based access

35. The product will generate various MIS reports as per requirements of the Departments from time to time. MIS reports based on the payment received, dues position, plans passed, pending proposals, delayed approvals be generated as per Department requirement.

36. The Product has well-defined inspection report format at various levels to guide the inspectors which is also configurable.

37. The Product incorporates digital signature (e-sign) for approval of application at different levels in the application system, Building permission letter, approved drawing, notices, letters, completion cum occupancy certificates etc.

38. Product has well defined service levels and the escalation matrix to officials regarding time limit for processing an application automatically in the system.

39. The Product after the Citizen validates the application the system will schedule the Document Verification visit date. This date can be rescheduled by both the parties once.

40. SMS/Email Alerts enabled in the Product

    1. Document Verification Meeting

    2. Field Verification

    3. Fee Computed and Demand Generated

    4. Plan Permit Approved and Digitally Signed

41. The Checklist for the Document Verification will be filled up by the officials on the Document Verification meeting. In the system the the Checklist is configurable.

42. The Product offers provision to incorporate the changes of building by-laws as intimated by the department in the application within time frame.

    1. Product has the feature to capture the history of changes and based on the original application submission date the relevant rules will be taken into account for scrutiny.

43. The Product has the feature of provisioning ther Revoking/Cancelling of Building Permission.

44. On completion of the Document Verification the applicable NOC Departments will be addressed by the System for NOC.

45. Field Verification Schedule will be assigned by the System with reschedule option for both the parties once.

46. The officials can do the Field Verification, update the report in a checklist format and forward for approval

47. Module-5: Online Fee Payments

48. The solution is integrated with the payment gateway for Online Payments and facilitate for Fee collection, Fee calculation, refund calculation and generate online fee receipts based on the submitted Building plan.

49. Upon approval of the report and NOC clearances the Fees are computed automatically by the system.

50. The Fee computation uses the Plan Parameters and the applicable laws and rules of the State which are configurable.

51. The Plans in PDF will be generated by the System with QR Code without any manual intervention.

52. Citizen/Architect can pay the Fees Online

53. Upon payment of Fees Plan Permit Approval process will be initiated and approved with Digital Signature. The Permit has been incorporated with QR Code.

54. The Fees can be collected under various heads of accounts and the Reports for the collections against the Heads of Accounts will be generated. This will enable the user to account the collections accordingly.

55. Module-6: Certificate(s)

56. The product has provision to generate certificates with e-Sign/ digital signature and QR code which can be downloaded by the applicant.

57. Module-7: Notice(s)

58. The notices, acknowledgment letters, approval letters, deviation or the rejection letters will be system generated with e-sign.

59. Every communication sent/received from/by an applicant will be received online only and reflected in the case as well as in the reports which can be used in court cases & for any other purpose.

60. Module-8: General requirements

61. The software tracks delays in approval steps and maintain an audit log of the approval process steps.

    1. System generates an alert against each application when it nears the time limit for disposing it.

62. The solution allows extraction of system logs to excel/pdf formats for internal analysis of cases.

63. The product have provisions where in providing basic parameters like certificate no., name, area etc. would generate basic information about approved certificate and hence would enable easy third party verification.

64. The Checklist, FAQ, User guide with video should be provided for end users.

65. The product provision to get month wise approved/ rejected/ pending application and status of pending approval.

Below mentioned table mention the functionality of the offered product as per the recommendations under the guidelines mentioned under the Ease of Doing Business(EODB) guidelines of 2019.

Description

For every building plan application, there is a need to get the No objection certificate from the concerned departments. Based on the configuration we have for the NOCs, for every application, there will be a set of NOCs required. There should be a provision to allow the NOC department user to login to our system and upload the required NOC. We are providing a user to one NOC department. Based on the workflow mode(online/offline) of each NOC type, the NOC department user can perform the action.

Online mode – NOC department user can log in to the system and approve/reject the application.

Offline mode – NOC application will be auto-approved.

System Requirements

• Knowledge of Java/J2EE(preferably Java 8 version)

• Knowledge of Spring Boot and spring-boot microservices.

• Knowledge of Git or any version control system.

• Knowledge of RESTful Web services.

• Knowledge of the Lombok library will helpful.

• knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-user, eGov-localization will be helpful.

External API References

• egov-user (Manage user)

• egov-idgen (To generate the application No)

• egov-localization (To use the localized messages)

• egov-location (To store the address locality)

• egov-mdms (Configurations/master data used in the application is served by MDMS)

• egov-notification-sms (Service to send SMS to the users involved in the application)

• egov-persister (Helps to persist the data)

• egov-workflow-v2 (Workflow configuration for different BPA application is configured)

API Information

Workflow Configuration

Fire Noc: Off-Line configuration

Airport Authority Noc: Off-Line configuration

Fire Noc: online configuration

Airport Authority: online configuration

Database Schema

Notifications

NA

PDF’s Used

NA

Description

Construction or renovation of buildings is regulated by Municipal Body in India. One must get permission from the 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 in compliance with the plan. When construction completed, after inspection Secretary provides a “Completion certificate” and finally will provide an “Occupancy Certificate”. This entire process is known as “Building Plan Approval”.

Functionality

This section covers the high-level details of the functionalities available in the Building Plan Application system.

• Centralized login page for citizen, official and stakeholders

• Citizen functionalities

• Online application submission - New construction

• Occupancy certificate request

• FieldInspection Report Capture

• Pay fee online and generate permit order online

• Inspection of applications and online status

• Configurable workflow

• Auto fee calculation

• Online and offline payment collection

• Rejection process

• Revocation process

• Configurable functionalities

System Requirements

• Knowledge of Java/J2EE(preferably Java 8 version)

• Knowledge of Spring Boot and spring-boot microservices

• Knowledge of Git or any version control system

• Knowledge of RESTful Web services

• Knowledge of the Lombok library will helpful

• knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service,dcr, land-services, bpa-calculator will be helpful

Setup and usage

• in the case of IntelliJ, the plugin can be installed directly, for eclipse the Lombok jar location has to be added in eclipse.ini file in this format javaagent:lombok.jar

API Information

Application.properties File Information

Here we are listing the configs apart from dependent service host, URLs, DB and Flyway configs.

• kafka topics persister configs for eGov persister to save and update BPA Data

  • persister.save.buildingplan.topic=save-bpa-buildingplan

  • persister.update.buildingplan.topic=update-bpa-buildingplan

  • persister.update.buildingplan.workflow.topic=update-bpa-workflow

  • persister.update.buildingplan.adhoc.topic=update-bpa-adhoc-buildingplan

• Receipt kafka topics where BPA application listens to move the application Status after payment completion

  • kafka.topics.receipt.create=egov.collection.payment-create

• Config for Demand Business service codes for different fees to be paid for BPA

  • egov.receipt.businessservice=

    • BPA.NC_APP_FEE := Building Plan Approval Application Fee

    • BPA.NC_SAN_FEE := Building Plan Approval Sanction Fee

    • BPA.LOW_RISK_PERMIT_FEE := Building Plan Approval Low Risk Permit Fee

    • BPA.NC_OC_APP_FEE := Building Plan Approval Occupancy Certificate Application Fee

    • BPA.NC_OC_SAN_FEE := Building Plan Approval Occupancy Certificate Sanction Fee

• Application and Permit Number Formats

  • egov.idgen.bpa.applicationNum.format=PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_APN]

  • egov.idgen.bpa.permitNum.format=PB-BP-[cy:yyyy-MM-dd]-[SEQ_EG_BP_PN]

• SMS Notification Topic to push the SMS and Notification’s to be sent by BPA module

  • kafka.topics.notification.sms=egov.core.notification.sms

• Payment Notification Config

  • egov.ui.app.host=https://egov-micro-dev.egovernments.org

  • egov.usr.events.create.topic=persist-user-events-async

  • egov.usr.events.pay.link=citizen/otpLogin?mobileNo=$mobile&redirectTo=egov-common/pay?consumerCode=$applicationNo&tenantId=$tenantId&businessService=$businessService

  • egov.usr.events.pay.code=PAY

• List of Application Statuses on which payment notification to be sent

  • egov.usr.events.pay.triggers=PENDING_SANC_FEE_PAYMENT,PENDING_APPL_FEE,PENDING_FEE

• Validity of the permit order generated in no of months

  • egov.bpa.validity.date.in.months=36

• Workflow code for the combination of applicationType , ServiceType

  • appSrvTypeBussSrvCode={"BUILDING_PLAN_SCRUTINY":{"NEW_CONSTRUCTION":"BPA,BPA_LOW"},"BUILDING_OC_PLAN_SCRUTINY":{"NEW_CONSTRUCTION":"BPA_OC"}}

• Application Status on which SKIP_PAYMENT action to be considered

  • egov.bpa.skippayment.status=PENDING_APPL_FEE,PENDING_SANC_FEE_PAYMENT,PENDING_FEE

• Business Service Code for WorkflowCode and Application Status

  • workflowStatusFeeBusinessSrvMap={"BPA":{"PENDING_APPL_FEE":"BPA.NC_APP_FEE","PENDING_SANC_FEE_PAYMENT":"BPA.NC_SAN_FEE"},"BPA_LOW":{"PENDING_FEE":"BPA.LOW_RISK_PERMIT_FEE"},"BPA_OC":{"PENDING_APPL_FEE":"BPA.NC_OC_APP_FEE","PENDING_SANC_FEE_PAYMENT":"BPA.NC_OC_SAN_FEE"}}

• NOC application Integration configs

  • Config to validate the status of applicable noc’s status to allow the application to move forward from NOC_VERIFICATION_PENDING Workflow State

    • validate.required.nocs.statuses=APPROVED,AUTO_APPROVED,REJECTED,VOIDED

  • NOC workflow initiate action code to initiate the workflow of the NOC when the appliation reachers the respective nocTrigerState

    • egov.noc.initiate.action=INITIATE

  • NOC workflow void action code to void the applicable NOC’s, when the application moved to REJECTED State

    • egov.noc.void.action=VOID

  • NOC workflow action goes for AutoAprove to auto-approve offline NOC , while moving from NOC_VERIFICATION_PENDING to the next state

    • egov.noc.autoapprove.action=AUTO_APPROVE

External API References

• egov-user - (Manage user)

• tl-services - Stakeholder Registration (Registration process of Stakeholder is handled by this service)

• egov-user-event (What’s New and Events)

• egov-filestore (To store the documents uploaded by the user)

• egov-idgen (To generate the application No, Permit No)

• egov-indexer (To index the BPA data)

• egov-localization (To use the localized messages)

• egov-location (To store the address locality)

• egov-mdms (Configurations/master data used in the application is served by MDMS)

• egov-notification-sms (Service to send SMS to the users involved in the application)

• egov-persister (Helps to persist the data)

• egov-searcher (Search query used to simplify the search)

• egov-workflow-v2 (Workflow configuration for different BPA application is configured)

• pdf-service (Receipt’s, permit order etc.. and prepared)

• billing-service (Create demands and bills for the fees to be collected)

• collection-services (Create a receipt for the payment received for the bills)

• bpa-calculator (Calculates the fees to be collected at different stages)

• land-services (land information related to BPA application is stored)

• dcr-services (get and validate EDCR data)

• noc-services (NOC application)

Configuration

BPA Specific Mdms configuration

Under the data/<state code> folder you can find the BPA which has all the MDMS JSON’s

master-config.json for BPA

MDMS Details

Access MDMS Config

Action Test : URL Actions adding

Access to the Roles for the above Actions

Billing Service MDMS Config

BusinessService Config for Fee’s to be collected

Application Fee, Sanction Fee BPA High/Medium Risk

Application Fee, Sanction Fee for BPA Low Risk

Application Fee, Sanction Fee for BPA OC

TaxHead MDMS

Tax Head for BPA High/Medium Risk

TaxHead config for BPA Low Risk

TaxHead config for BPA OC

TaxPeriod MDMS Config

TaxPeriod MDMS for BPA High/Medium Risk

TaxPeriod MDMS for BPA Low Risk

TaxPeriod Config for BPA OC

ID Gen Config for BPA Numbers

BPA Application Number format Config

BPA Permit Number format Config

BPA Receipt Number format config

BPA OC Receipt Number format config

Persister configuration

Indexer Configuration

Locality Search Configuration

Database Schema

Postman Links

Workflow Configuration

BPA and BPA OC Workflow Stages

BPA workflow configuration is for Building Plan Approval Apply High and Medium Risk Types.

BPA OC workflow configuration is for Building Plan Approval Occupancy Certificate irrespective of RiskTypes

Both the workflow flows as depicted below.

In the above Flow Chart

• Rectangle Indicates the Workflow State

• Line connecting two states indicates the action

  • Action name is in black colour text

  • User Role who can take action is in Blue colour Text

Specific Configurations and How To’s

• System allows configuring the Documents that can be visible, allowed to upload and Mandatory to move from the current state in DocumentTypeMapping MDMS as described in MDMS Details Table DocumentTypeMapping Row

• Application Creation Sage

  • Process

    • DCR system is integrated to get the applicationType, serviceType and riskType based on the EDCR Number populated by the architect.

    • DCR system is integrated to validate the status of the EDCRNumber populated

    • New BPA or BPAOC application cannot be created if there is existing un ended( application status other than approved or rejected is considered as unended) application with the same EDCR

  • How To add new Document

    • Should add new documentType group in DocumentTypeMapping MDMS with the applicable applicationType, serviceType, riskType, wfState (refer existing sample for understanding)

    • Can configure allow, required as well as the order for each documentType
• Initiated Stage

  • Process

    • NOC’s from the NocTypeMapping MDMS matching to the application data will get created

  • How To add new NocType

    • Should add new NOCType in NocTypeMapping MDMS

    • New NocType should add in noc-services application as well

• Citizen Approval Pending Stage

  • Process

    • According to the example in the NocTypeMapping Data in the MDMS Details Table, Once BPA or BPA OC reaches this Staus all the Applicable Noc’s workflow would be initiated.

  • How to change NOC workflow initiation step

    • Should change the nocTriggerState in NocTypeMapping to the desired application status.

• InProgress Stage

  • Process

    • Application fee Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How To change the Fee Amount

    • Will be discussed in bpa-calculator service

• Document Verification Pending Stage

  • Process

    • Nothing Specific

  • How To

    • NA

• FieldInspection Pending Stage

  • Process

    • At this stage, FieldInspector should answer the checklist questions and attached the documents which will be configured in checklist MDMS, as described in MDMS Details Table CheckList Row

    • Field Inspector can create multiple FieldInspection Reports

  • How to add new questions and documents

    • Should add/modify the questions for the desired combination of applicationType, serviceType, risktype

    • with the localization code for question text

    • specify the fieldType ( ass of now only YES/NO/NA only supported )

    • Should add/modify documents for the desired combination of applicationType, serviceType, risktype

• Noc Verification Pending State

  • Process

    • NOC verifier can upload the Documents to the NOC application’s if available.

    • Offline Noc’s would get auto-approved while NOC verifier is forwarding the BPA or BPAOC application from the current state

    • BPA or BPAOC application cannot be forwarded if any NOC is not in matching the status configured for validate.required.nocs.statuses in application.properties

  • How to change the NOC application status to be verified to move forward

    • should update the validate.required.nocs.statuses property in value in application.properties with the list of status to be considered to move forward

• Approval Pending Stage

  • Process

    • Approver can select the predefined conditions for approval updated in CheckList MDMS, as described in MDMS Details Table checkList Row

    • Approver can add new conditions as well for approval

    • Sanction fee Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How to add/remove/modify conditions

    • Should add/modify the conditions array for the desired combination of applicationType, serviceType, riskType

• Approved Stage

  • Process

    • System generates PermitOrder for the application

    • System Stamps the validate date for the permit Order by adding the no of months configured for the property egov.bpa.validity.date.in.months in application.properties

  • How to change the validity period of the permit order which will generate from now

    • Change the value of the property egov.bpa.validity.date.in.months in application.properties file to the desired no of months

  • How to change Permit Order

    • Can be changed by changing the data and format configs of the permit order, please refer to PDFs section of Permit Order

• Rejected Stage

  • Process

    • NA

BPA LOW Workflow

BPA with risk Type low has a separate workflow, which is almost the same as the BPA workflow as depicted below.

In the above Flow Chart

• Rectangle Indicates the Workflow State

• Line connecting two states indicates the action

  • Action name is in black colour text

  • User Role who can take action is in Blue colour Text

Specific Configurations and How To’s which are not common to BPA Workflow

• InProgress Stage

  • Process

    • Application and Sanction Fee together gets calculated and Demand gets generated by the bpa-calculator

    • Notification to the Stakeholder and owner will be sent regarding the fee payment

  • How To change the Fee Amount

    • Will be discussed in bpa-calculator service

• Document Verification Pending Stage

  • Process

    • System generates PermitOrder for the application

    • System Stamps the validate date for the permit Order by adding the no of months configured for the property egov.bpa.validity.date.in.months in application.properties

  • How to change the validity period of the permit order which will generate from now

    • Change the value of the property egov.bpa.validity.date.in.months in application.properties file to the desired no of months

• Approved Stage

  • Process

    • NA

• Revocated Stage

  • Process

    • System generates Revocation letter

  • How to change Revocation Letter format

    • Can be changed by changing the data and format configs of the revocation letter, please refer PDF’s section of Revocation letter

Validations included

• On Workflow action of Every Stage, System verifies the Documents Configured for the given stage of the workflow from the DocumentTypeMapping MDMS and validates the required Documents attached to move forward

• DropDown values to be validated against the MDMS values, Value in those fields should be one of the MDMS value.

Notifications

Notifications Message codes for SMS and User Events are prepared as follows

ApplicationType_ServiceType_WorkflowAction_ApplicationStatus.

Example BPA Apply Application (i.e applicationType is BUILDING_PLAN_SCRUTINY) with ServiceType NEW_CONSTRUCTION and the current application status is DOCUMENT_VERIFICATION_PENDING and workflow Action of the request is FORWARD then the localized message for this notification will be looked for the code: BUILDING_PLAN_SCRUTINY_NEW_CONSTRUCTION_FORWARD_DOCUMENT_VERIFICATION_PENDING

The message text for the above code is sent through SMS and Notification filling in the owner, serviceType, application Number and other values.

PDFS used

BPA supports below PDF’s

Section 1: Executive Summary

Overview of the Product

The computerised and automatic building permission system offered under the National Urban Stack(NUS) facilitates citizens who seek permission for construction of a building within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. Online Building Permission System (OBPS) is one of the components of a smart city that has the capability of providing a single window for acquiring building permits, NOCs, and clearances from multiple agencies or departments. Keeping in mind the benefits associated with the product offered, the proposed system is about to be implemented in 500+ ULBs across the country in 15 states and Union Territories. (For details on product features refer to Section-2).

Implementation Methodology for OBPS

For the offered product, the implementation process can be divided into six major distinctive stages. Each stage has predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. The whole implementation lifecycle is typical of 35-40 weeks keeping in mind the entry, and exit criteria defined at the beginning and end of each stage is met within the recommended time.

Stage Zero-program setup and onboarding is a pre-requisite for the initiative to kick-off and requires setup of the governance model, implementation Team and decision regarding other significant elements of the initiative like funding and procurement process.

Stage One of the initiative requires scoping of the initiative and deciding on the priorities for implementation by the state implementation Team.

In stage three, the state Team will work upon identifying and finding solutions to the significant gaps in the product offered w.r.t. to the needs of the state.

Configuration and customisation of the product offered in the primary objective of stage four. This involves working on various aspects of state-specific needs and incorporating them into the product suite offered.

In stage four and five, post doing UAT and including all the necessary feedback on the product, the roll-out of the product is done at the state level (Go Live) from a couple of ULBs to pan state coverage. (For details on the implementation plan refer to Section-3).

Manpower Requirement For Implementation

The whole implementation cycle requires a Team of individuals with specific skill sets to work very closely. The state implementation unit comprises individuals with Program management, business analysis, implementation engineering, software engineering, architecture (DCR Domain) and capacity building skills. Depending upon the phases of implementing the initiative is in, the amount of effort by each participant in the smaller units will vary. (For details on resource sizing and requirements refer to Section-5)

Budgetary Requirement For Implementation

Based on close deliberations with various stakeholders, it is recommended that the budgetary allocation for the implementation of the initiative should be around 3 crores to 3.8 crores1 for statewide implementation and Operation and Maintenance Cost (per Year )for the initiative will be approximately 1.35 crores to 2.0 crores2. The budget allocated needs to be utilised for human resources requirements primarily. The budgetary allocation is recommended as per the NICSI standards published on https://www.nicsi.com/ (Check Annexure 1 for NICSI standard rates). The estimation of the budget will increase or decrease based on the rates applicable to the resources required. (For details on budgetary allocation guidelines refer to Section 5).

Critical Success Factors For Implementation

1 Assuming NICSI standard rate cards and 20% range on the actual estimated cost

2 Assuming NICSI standard rate cards and 20% range on the actual estimated cost.

Section 2: Online Building Permission System(OBPS) Implementation Methodology

This section provides an overview of the methodology for the state-wide implementation of OBPS. Implementation of OBPS is distributed across six distinct stages. Each stage has predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. Details of each stage are defined in this section.

OBPS implementation program is expected to be completed within approximately 37 weeks with the resource deployment by the State and System Integrator(SI) Team (as defined below). However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.

Six Stages of Implementation

Stage 0 - Program Setup/Onboarding

Set of initial critical activities that are undertaken on receiving a Letter of Enrollment from the state. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator(SI) Teams and funds.

Stage 1 - Program Kick-Off

This stage envisages the in-person interaction of crucial State officials and implementation System Integrator(SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify Pilot ULBs, create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.

Stage 2 - Solution Design

During the Solution design stage key state officials and members, who are subject matter experts, are expected to share state by-laws and also help interpret these laws for the System Integrator(SI) Team. This stage baselines the State-specific product features in the Product Configuration report.

Stage 3 - Configuration & Customization

Configuration & customisation stage, spread across 12 weeks, envisages configuration of the product as per the baselined Product Configuration report and identified state-specific customisations. Active involvement of domain experts from the state Team is required in this stage to validate the implementation of state by-laws.

Stage 4 - UAT & Go Live

During this stage, the active involvement of Pilot ULB officials is expected for thorough testing of the configured product. Training of the key ULB officials will also be undertaken during this stage, along with the promotion of the solution. The establishment of the State support Team and required processes are initiated in this stage.

Stage 5 – Rollout

On successful rollout in the Pilot ULBs, the solution will be rolled out to the rest of the ULBs in batches. Guidance and support from the State Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.

Section 3: Roles and Responsibilities – OBPS Cell, NUS Team & System Integrator(SI)Team

This section outlines the activities involved in each stage of the implementation along with the responsibility and accountability of critical stakeholders - State, NUS Team and Implementation Team onboard.

OBPS Cell: OBPS Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from the Town and Country Planning Organization, Urban Development Department etc.

NUS Team: NUS Team is the National Program Management Unit established in Delhi which will provide all necessary support to the state concerning the implementation, Program Designing etc.

System Integrator (SI)Team: SI Team will be responsible for the rollout of the initiative in the state, providing all end to end support to the state w.r.t. The implementation of the products in the ULBs.

Execute - One who owns the accountability to complete the activity

Consult - One who may initiate, guide and in the process, handhold the execution of the activity

Section 4- Resource, effort estimation and Budget Requirements for the Program

Implementation effort and Budget requirements of the program(Stage 1 to Stage 5)

Implementation Budget requirements of the program

The summary of the budgeting is as per the NICSI rates(Please refer to annexure-1) and assuming a 20% range.

Resource requirements for the OBPS cell required to be formed by the state

Project Sponsor: Is the Head of the OBPS Cell who will drive the project from the State Side

Plan Process Expert: The two resources that will provide the BPA application process and workflow. Validate the UAT in compliance with the expected outcome.

Development Control Rules Experts: they should have the domain skills on the drawings and plan along with the DCR rules of the State. They would provide the templatization of the DCR Rules, validate the same once configured in the Application and approve.

Nodal Officer: He would play the organise role who will provide all logistics support and scheduling of activities related to the project, Rollout and training of both Engineers and ULB officials across the State.

Introduction

Building Sub Occupancy details refer to sub-categorization of primary occupancy types. For instance, residential buildings can be further classified as apartments or old age homes depending on the specific usage of the buildings. Refer to the to view the prescribed list of sub-occupancy types.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachment

Introduction

The Building Usage data allows States/ULBs to classify the buildings based on occupancy types, sub-types and its actual usage. Permits and approval process are dependent on the Usage type. The Data Table provides the details required to configure the Building Usage types. Refer to the to view the prescribed list of usage types.

Data Table

Data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify all the building usage and its mapping with sub occupancy and then fill into the template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Introduction

The Fee Structure masters list contains the fee details applicable for processing specific services. All fee-related information collected by the authorities during the course of building plan approval is maintained in this masters.

Data Table

The data given in the table is sample data for reference.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to understand the headers in the template sheet, their data type, size, and definitions.

3. Reach out to the person who shared the template for further details or to clear your doubts. Identify if the State/ULB has a provision for capturing pipe size for connections.

4. Identify the combination of attributes for with the fee is defined and then fill into the given template.

5. Go through the checklist to verify the data. Make sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

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

Entity Specific Checklist

There is no separate entity-specific checklist for this entity.

Attachments

Click on the page link below to view the eDCR integration details.

Software to install

• Java 1.8

• Eclipse

• Postgres

• PhpPgAdmin

• Postman (Application)

• Respective Git MiddleWare

• Kubectl

• Kafka

Take the code pull from the git:

Need to consider 2 repositories for code to run locally

1. Municipal services - where our BPA code exists and some dependency services also available here

2. Core Services - Where dependency services exist to run our code locally

Import the required projects to eclipse

From municipal-services import bpa-services, bpa-calculator and land-services. From core-services import user service, idgen service, mdms service, location service, localization service, workflow service, egov-persister.

Before running the application make sure the following setups are complete to ensure the application runs smoothly.

Run the below commands based on your system types

For linux: in kafka folder path

Example: D:\kafka_2.13-2.4.0

> bin/zookeeper-server-start.sh config/zookeeper.properties > bin/kafka-server-start.sh config/server.properties

For Windows: in windows path

Example: D:\kafka_2.13-2.4.0\bin\windows start zookeeper-server-start.bat ....\config\zookeeper.properties start kafka-server-start.bat ....\config\server.properties

• Kubectl setup based on the requirement To get the pods: kubectl get pods To port forward: kubectl port-forward <<pod name>> <<port number>>:8080 To get the logs: kubectl get logs

After all the setups are done successfully, try to run the application locally.

BPA-Services How to run the application in local:

Check the services which are connected to local and which are connected to dev

• Which are connected to dev no need to change anything.

• If it is connected to local check the services are in below list IDGEN – can run locally or can point to dev from cmd prompt PERSISTER – can run locally MDMS – can directly point to dev or can run in local LOCATION – can directly point to dev WORKFLOW – can point to dev or can run locally LOCALIZATIONS – we can directly point this to dev USER-SERVICE – need to point to dev from cmd prompt LAND-SERVICE – need to run locally BPA-CALCULATOR – can run locally or can point to dev.

• If the changes are from these services follow the below process to run those respective services.

For core services:

IDGEN:

Approach 1: Directly point this to dev from the application.properties in bpa-services Approach 2: Point this to local and give the port forward to dev by using kubctl.

PERSISTER:

U need to run it in local and need to add respective yaml files in persister resource folder which are bpa-persister.yml and egov-workflow-v2-persister.yml and also land-persister.yml

And need to add these in persister application.properties repo path

MDMS:

to run local: For running this in local need to change in 2 file that is application.properties and MDMSApplicationRunnerImpl

In application.properties need to change the paths for the master-config url as path of master-config.json and for config path as upto pb/bh

In MDMS ApplicationRunnerImpl need to change the data in a function from the path to file.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

LOCATION

Approach 1: Give it a local connection in BPA application.properties and port forward to dev by using kubectl.

Approach 2: Directly point this to dev from the application.properties in bpa-services

WORKFLOW

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

to run local:

can run locally by pointing to the local database, but for this need to create the workflow locally using the workflow create API.

USER-SERVICE Approach 1: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Approach 2: Directly point this to dev from the application.properties in bpa-services

LOCALIZATIONS

Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Changes from Municipal services

BPA-Calculator:

to run local:

can run locally by pointing to the local database.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Land-Service:

to run local:

can run locally by pointing to the local database.

to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services

Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.

Other than these services can directly by pointing to dev url.

All Dependent Services

• egov-user - (Manage user)

• tl-services - Stakeholder Registration (Registration process of Stakeholder is handled by this service)

• egov-user-event (What’s New and Events)

• egov-filestore (To store the documents uploaded by the user)

• egov-idgen (To generate the application No, Permit No)

• egov-indexer (To index the BPA data)

• egov-localization (To use the localized messages)

• egov-location (To store the address locality)

• egov-mdms (Configurations/master data used in the application is served by MDMS)

• egov-notification-sms (Service to send SMS to the users involved in the application)

• egov-persister (Helps to persist the data)

• egov-searcher (Search query used to simplify the search)

• egov-workflow-v2 (Workflow configuration for different BPA application is configured)

• pdf-service (Receipt’s, permitorder etc.. and prepared)

• billing-service (Create demands and bills for the fees to be collected)

• collection-services (Create a receipt for the payment received for the bills)

• bpa-calculator (Calculates the fees to be collected at different stages)

• land-services (land information related to BPA application is stored)

• dcr-services (get and validate EDCR data)