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 citizens, officials and stakeholders

• Citizen functionalities

• Online application submission - new construction

• Occupancy certificate request

• Field inspection report capture

• Pay fee online and generate permit orders 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

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

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.

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

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

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

Sample Datasample-configuration-data-service-documents.xlsx - 10KB

Configuration data templateconfiguration-data-template-service-documents_v1.xlsx - 10KB

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

Configuration Data Templatefee-structure-template.xlsx - 10KB

Sample Datafee-structure-sample-data.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

Configuration Data Templateconfiguration-data-template-list-of-services-2-.xlsx - 10KB

Sample Datasample-configuration-data-list-of-services.xlsx - 10KB

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 National Bye-Laws 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

Configuration Data Templateconfiguration-data-template-building-usage-type_v1.xlsx - 10KB

Sample Datasample-configuration-data-building-usage-type.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

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 National Bye-Laws 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.

4. Identify the sub 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.

Attachment

Configuration Data Templateconfiguration-data-template-building-sub-occupancy_v1.xlsx - 10KB

Sample Datasub-occupancy-sample-data.xlsx - 10KB

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

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.

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.

Objective

To provide the facility for the employee users to update the BPA application state.

Localization

The localization module used across the OBPS module was rainmaker-bpa and rainmaker-common, out of which we initialized rainmaker-bpa with module initialization.

Application Details

The application details page is used to display the details of the application and also showcase all the actions that can be taken on the application.

The various step for the application:

Document Verification

In this step, the user can upload multiple documents and/or approve the already uploaded documents.

NOC Verification

The user approves the uploaded NOC documents.

Inspection Report

The user fills in the inspection details (date, time, question, remarks) and submits.

Permit Condition

Here the user approves the required permit conditions and can also add new conditions.

UI Implementation

All the screens are developed using the new-UI structure followed previously in FSM, PGR, PT, and TL. Certain new components have been introduced such as Multi-Document Upload, Approval Checks, etc.

MDMS Data

Throughout the flow, some data is imported from the MDMS. Following are the list of MDMS data:

1. CheckList

2. RiskTypeComputation

Below is the MDMS config used to fetch MDMS data:

curl 'https://qa.digit.org/egov-mdms-service/v1/_search?tenantId=pb' \
  -H 'authority: qa.digit.org' \
  -H 'sec-ch-ua: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'content-type: application/json;charset=UTF-8' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'origin: https://qa.digit.org' \
  -H 'sec-fetch-site: same-origin' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer: https://qa.digit.org/digit-ui/employee/obps/bpa/PB-BP-2021-10-19-002931' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'cookie: amplitude_id_fef1e872c952688acd962d30aa545b9edigit.org=eyJkZXZpY2VJZCI6IjYxMDYxMWFjLTY5MjMtNDQ1Yi04ZWZlLTUxNGVkMmE5MzRjOFIiLCJ1c2VySWQiOm51bGwsIm9wdE91dCI6ZmFsc2UsInNlc3Npb25JZCI6MTYzMzA4NTYwNzE5MiwibGFzdEV2ZW50VGltZSI6MTYzMzA4NTYwNzk2OCwiZXZlbnRJZCI6MSwiaWRlbnRpZnlJZCI6MSwic2VxdWVuY2VOdW1iZXIiOjJ9; _ga=GA1.2.1811666557.1633085608' \
  --data-raw '{"MdmsCriteria":{"tenantId":"pb","moduleDetails":[{"moduleName":"BPA","masterDetails":[{"name":"RiskTypeComputation"}]}]},"RequestInfo":{"apiId":"Rainmaker"}}' \
  --compressed

Objective

OBPS search application is used to search all the applications independent from the workflow/process instance data, which eliminates the presence of valid roles to search for an application from any business service.

Make use of the already documented applicationType and serviceType MDMS. Create a couple of hooks to coordinate and easily use the available filters.

Objective

Users can view all the applications assigned to them in the employee inbox. And it provides multiple filters and search options to filter the applications.

Application Details

OBPS Inbox uses InboxComposer React HOC to create the Inbox through various child components, for both mobile and Desktop Components.

The API used to fetch applications in the inbox

For viewing OBPS inbox these roles are necessary "BPA_FIELD_INSPECTOR", "BPA_NOC_VERIFIER", "BPA_APPROVER", "BPA_VERIFIER", "CEMP"

Refer to the config below for risk type definition:-

Objective

To provide the facility for the user for creating New Building Permit Application by the citizen. Every application which is created is a part of the workflow.

Apply for New Building Permit Application (BPA)

Users can apply for a new building permit application by clicking on the “Registered Architect Login”. This option can be used only by registered architects to log in. Other users will not be able to proceed further.

Architects will first need to generate an eDCR Scrutiny Number if it is not already available. For this click on “Plan Scrutiny For New Construction”. If the eDCR Scrutiny Number is available, navigate directly to “Building Plan Permit For New Construction”. Add all required information while going through the workflow.

The Create API is called in the middle of the workflow after owner details. And, at the end of the flow, a summary screen is visible for the review of the entered details. Click on the submit button calls the Update API that changes the status from Initiated to Applied and the Registration Application gets updated.

eDCR Scrutiny Registration

Users must provide the City, Applicant Name and upload the dxf file in order to generate eDCR number.

Acknowledgement Page gets displayed. Users can apply for the building permit by clicking on the Apply for Building Plan Permit button. Or, they can go back and apply from the home page as mentioned in the previous section.

New Building Plan Permit Registration

The New Building Permit Document Required screen is displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for New Building Permit. A Citizen Info card is also shown at the bottom of the page for any additional information such as the maximum size of the file that can be uploaded.

TimeLine Component

The TimeLine component is present on all pages of the application. It informs the user about each stepper in completing the registration application.

Scrutiny Details Step

In this step, the users need to provide and verify the details from scrutiny API.

Basic Details

Users will need to verify the basic details received from the API, using the eDCR scrutiny number. In case the scrutiny number is not entered, users can enter the number and search for the result.

Plot Details

The data asked here is not compulsory - users can enter or skip it too.

Scrutiny Details

On this page, half of the details are received from the scrutiny details API and a drop-down for sub occupancy which is multiple in nature. Users can select accordingly.

Location Details

Users can click on the GIS icon and select and pinpoint the current address on the geolocation component.

If the user does not want to select the location on the map, they can enter the Pincode. The city and locality get selected accordingly.

Owner & Document Step

In this step, users have to provide details about the owner. Owners could be single or multiple.

Owner Details

Select the type of owner and enter owner details

In case, multiple owner option is selected, the Add Owner button is visible. The Primary Owner checkbox is also available. Click on the Add Owner button allows users to add multiple owners accordingly. Click on the Next button calls the Create API.

Document Details

Users have to select the document type. The upload multiple documents if needed using the document upload component. If the type is only one, then it came pre-selected for user convenience. Also, the documents which are mandatory are defined in MDMS from where it is fetched.

An info card is also visible which informs the user about the application number of the application created in the create API call.

NOC Details

Users need to verify and upload the documents, if required, for the NOC details. This information is also fetched from the MDMS.

Summary Page and Acknowledgement Screen

Users can cross-verify the data entered throughout the flow on the Summary page. In case any change or update is required, they can click on the edit icon available adjacent to the section headers. This redirects them to the relevant page and the entire flow is repeated again in order to submit the application.

Along with this Fee estimate for the corresponding application is also shown on the summary page.

For BPA Application the Update API call is made. Below is the snippet of the Update API used:

If the API response is successful, then the Acknowledgement Screen is displayed. Else, the Failed Acknowledgement Screen is displayed.

OC Apply For New Building Permit Application (BPA)

The OCBPA flow is similar to the BPA flow detailed above with the exception of a few steps that are not necessary and therefore omitted in this flow.

OC Plan Scrutiny For New Construction

Click on the OC Plan Scrutiny for New Construction button to generate an OC eDCR number. Users need the Permit Number and the Date that is generated upon the completion of the BPA application.

Documents Required