OBPS-BPA/OC-BPA Architect
Last updated
Last updated
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
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.
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.
Users must provide the City, Applicant Name and upload the dxf file in order to generate eDCR number.
The 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.
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.
The TimeLine component is present on all pages of the application. It informs the user about each stepper in completing the registration application.
In this step, the users need to provide and verify the details from the scrutiny API.
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.
The data asked here is not compulsory - users can enter or skip it too.
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.
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.
In this step, users have to provide details about the owner. Owners could be single or multiple.
Select the type of owner and enter owner's details
In case, the 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.
Users have to select the document type. 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.
Users need to verify and upload the documents, if required, for the NOC details. This information is also fetched from the MDMS.
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.
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.
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.
The Documents Required screen lists all the documents or data required to generate the OC eDCR number.
Once the user provides the Permit Number and Date, the application details are pre-populated.
After verifying the details the user needs to upload the DXF file in order to generate the OC Scrutiny number.
The success acknowledgement page is shown in case of no errors in the application.
Clicking on Apply for OC New Construction redirects users to the Apply for new building permit form page. The Location & Owner Details will get auto-populated from the previous application details. The application triggers the Create API call from the scrutiny details page. The remaining flow is the same as for New Building Plan Permit.
All the screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL. Some new components have been introduced such as the TimeLine, Multi-Document Upload feature etc.
The links for the BPA & EDCR Main Index are given below. These help in understanding the starting point of the flow:
The links for the OCBPA & OCEDCR Main Index are given below. These help in understanding the starting point of the flow:
The OBPS Module is segregated into a specified structure. All the screen configurations are available inside the PageComponent Folder and the configuration for routing of the pages are available within the config folder which is common for both Citizen as well as Employees. New components like TimeLine are defined within the component folder. Below is the snippet for folder structure and routing configuration.
Config responsible for the routing of each flow
BPA (new building permit application):
EDCR (scrutiny number):
OCBPA (OC new building permit application):
OCEDCR (OC Scrutiny number):
The Pages Folder is where the high-level configuration for controlling the whole flow is defined, for citizens and employees. Citizen configuration details include Apply flows, send backflows, Application details etc. The folder contains the index (the main starting point of the whole flow).
The main difference in the BPA/OCBPA registration flow from other modules is in the apply flow. The create API is called in between the flow and the Update API is called at the end.
The code for Create API request object generation is available inside the Owner details or scrutiny details component for BPA & OCBPA respectively. This API call is triggered when the user clicks on the Next button on the Correspondence Address page.
The BPA/OBPS Create API call uses the Digit.OBPSService.create method to call the API. The code details are available within the gonext() method in the following files respectively.
Code reference:
https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pageComponents/OwnerDetails.js / https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pageComponents/ScrutinyDetails.js
The Utils Folder basically contains all the methods which are being used throughout the OBPS module, and if any common method needs to be declared here, it can be imported to other files.
Throughout the flow, the Download button is mentioned according to the current state of the Application. These documents are generated from the server side and are dependent on the business service of the application. Refer to the code below to define the business service and the following keys.
Following are the hooks used for the download PDF call:
For Occupancy Certificate use: occupancy-certificate and for Permit orders: buildingpermit-low
For updating an Application, the update API from BPA is called using the React hooks, which is declared under hooks/elements/obps as OBPSService.
The response object from the Create API is used for the request object of Update API, in addition to the document details that users have entered. This changes the status of the Application as Applied instead of initiated. Along with this NOC Update API is also called which updates the status of the NOC aligned with the particular application.
Update API for NOC, BPA & OCBPA, the hook used for calling the API is:
1Digit.Hooks.obps.useObpsAPI( 2 data?.address?.city ? data.address?.city?.code : tenantId, 3 true 4 );
This API is called in the respective Acknowledgement Page:
https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pages/citizen/OCBuildingPermit/OBPSAcknowledgement.js / https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pages/citizen/OCBuildingPermit/OBPSAcknowledgement.js
Throughout the flow, a few of the page data is imported from the MDMS. Following is the list of pages that are using MDMS data. These pages .js files can be found under page components.
EDCRForm | City list |
|
|
DocsRequired | Documents required List |
|
|
BasicDetails | Risk Type |
|
|
OwnerDetails | Gender & Ownership category |
|
|
For calling MDMS data React Hooks has been used, so that it can be shared throughout the modules. Below is the little code snippet used for the MDMS call.
Localization keys are added in the ‘rainmaker-bpa’ locale module. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed in the locale DB under rainmaker-bpa locale module. Below is an example of a few locale labels.
| S.No. | API | Action ID | Roles |
|---|---|---|---|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
