Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The search application feature provides a filter-based search tool to employees.
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.
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.
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"
The MDMS links (blue text hyperlinks) are used while selecting the OBPS application type, service type, risk type with business service and status filters.
Refer to the config below for risk type definition:-
To provide the facility for the stakeholder users to create and submit the eDCR Application. Stakeholders include Architects, Builders.....etc.
Users can generate and submit the eDCR application by clicking on the “Registered Architect Login”, through which only registered stakeholders (Stakeholders including Architect, Builder.....etc) can log in. Other users will not be able to proceed further.
Stakeholders can generate the eDCR scrutiny number by clicking on Plan Scrutiny For New Construction link. They can add all the information, according to the questions asked, after filling in the information in the eDCR form click on the Submit button. This triggers the Create API call. The success or failure of the API routes the user to the acknowledgement screen. If eDCR API is Success => it routes to the acknowledgement screen. Stakeholders can see the eDCR number, application number and download option. If eDCR API is Failure => it routes to the acknowledgement screen. Stakeholders can see the application number and download option but not eDCR number.
Users need to provide their City, Applicant Name and Upload dxf file in order to generate the eDCR number.
The acknowledgement Page gets displayed after the success of eDCR creates call. Here stakeholders can see -
eDCR Number
Application Number
Download option for downloading the scrutiny report
Apply for the building plan permit button for creating the BPA application( OBPS BPA/OCBPA - ARCHITECT )
Go Back To Home button to navigate to the home page
The failure acknowledgement page gets displayed if the eDCR Create API call results in failure due to some reason. Here stakeholders can see -
Application Number
Download option for downloading the scrutiny report
Go Back To Home button to navigate back to the home page
Users can apply for the OC eDCR application by clicking on the Registered Architect Login link through which only registered stakeholders (Stakeholders including Architect, Builder.....etc) can log in. Other users will not be able to proceed further. Stakeholders can generate the OC eDCR scrutiny number by clicking on the OC Plan Scrutiny for new Construction link. They can add all the information, according to the question asked, and after filling in the information in the eDCR form steps clicking on the Submit button triggers the Create API call. Depending on the success or failure of the API call users are routed to the acknowledgement screen.
The Permit Date and Permit Number of BPA are required to generate the OC eDCR. The permit details enable the search for specific BPA records followed by a search for the OLD eDCR details (BPA eDCR). These details are used to generate the OC eDCR Number.
1. Data Required
Click on OC Plan Scrutiny for new Construction link. This routes the user to the Data Required screen and the screen provides information about the data required to generate OC eDCR number.
Clicking on the Next button routes the user to the OC eDCR scrutiny details screen.
2. OC eDCR Scrutiny Details
After entering the permit number and permit date, stakeholders need to click the Search button. Internally BPA and eDCR search fetches the required data.
The BPA and eDCR search results display all details regarding the application along with the proceed for OC scrutiny button on a separate card.
On clicking the Procced for OC scrutiny button users are redirected to the Upload OC Plan Diagram screen.
File Path:
3. Upload OC Plan Diagram
Users have to upload the dxf file and click on the Submit button that triggers the Create API call.
File Path:
The Success Acknowledgement Page gets displayed after a successful eDCR create call. Here stakeholders can see -
eDCR Number
Application Number
Download option, for downloading the scrutiny report
Apply for OC For New Construction button, for creating the BPA application( OBPS BPA/OCBPA - ARCHITECT )
Go Back To Home button to navigate back to the home screen
Creating preview...
File Path:
The Failure Acknowledgement Page gets displayed in case the eDCR create call fails for some reason. Here stakeholders can see -
Application Number
Download option, for downloading the scrutiny report
Go Back To Home button to navigate back to the home screen
Creating preview...
File Path:
All screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL.
The link for the eDCR & OC eDCR Main Index is given below. It helps in understanding the starting point of the flow:
Config responsible for the routing of each flow
eDCR:
OC eDCR:
Throughout the flow, a few of the page data is imported from MDMS. Following is the list of pages that are using MDMS data. These pages .js files can be found under page components.
For calling the MDMS data React Hooks has been used, so that it can be shared across modules. Below is the little code snippet for the call used for MDMS.
Localization keys are added under the ‘rainmaker-bpa’ locale module. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed to the locale DB under rainmaker-bpa locale module. Below is an example of a few locale labels.
To provide the facility for the employee users to update the BPA application state.
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:
In this step, the user can upload multiple documents and/or approve the already uploaded documents.
The user approves the uploaded NOC documents.
The user fills in the inspection details (date, time, question, remarks) and submits.
Here the user approves the required permit conditions and can also add new conditions.
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.
Throughout the flow, some data is imported from the MDMS. Following is the list of MDMS data:
Checklist
RiskTypeComputation
Below is the MDMS config used to fetch MDMS data:
The localization module used across the OBPS module was rainmaker-bpa and rainmaker-common, out of which we initialized rainmaker-bpa with module initialization.
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:
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:
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.
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.
To provide the facility for the citizen user to view the application details, update the BPA application state and make the payment.
Users can review the list of applications and their status registered using their mobile number on the My Applications page. Each Application initially displays the Application Number, Application Type, Service Type, status, and SLA with the View Details option.
Click on the View Applications by Citizen link routes users to the My Applications screen. The screen provides BPA, OC-BPA and stakeholder registration applications and details. The BPA search API and the Stakeholder Registration search APIs are called and the application cards are visible after getting the response from the APIs.
File Path
Click on the View Details button. It routes users to the application details screen. 1. BPA Application Details
Clicking on the BPA/OC BPA application card routes users to the BPA application details page. The application details page displays the details of the application and also showcases all the actions that can be taken on the application.
Clicking on the Action button provides the citizen users with the actions list. Clicking on any one of the options opens a popup window. Users can enter comments and upload documents. Clicking on the Submit or Forward button triggers the Update API call.
File Path
When employees click on the Send Back to Citizen button, the applications are routed back to the My Applications list of the citizen. The Application Details screen allows users to make the required changes. The forward action button routes the citizen to the Summary screen. Users can attach the documents and submit the application.
File Path
Citizens can download the receipts which include Application Fee, Sanction Fee, Permit order, Revocation pdf, Comparison report etc based on the conditions.
File Path
Clicking on the Stakeholder Application card routes the user to the stakeholder application details. The application details page displays the details of the application and also showcases all the actions that can be taken on the application.
File Path
The Timeline component is present at the end of the application details and provides information on the current status.
All the screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL.
OBPS Hooks Details
File Path
OBPS Search API Hook
OBPS Update API Hook
OBPS WorkFlow API Hook
OBPS MDMS Hooks
Collection Services Hooks(For Receipts and Amount display)
Stakeholder Hooks
File Path
Search Hook
MDMS Hook
Collection Service Hook(For Receipts and Amount display)
Localisation keys are added under the ‘rainmaker-bpa’ and ‘rainmaker-bpareg’ locale modules. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed to the locale DB under 'rainmaker-bpa' locale module. Below is an example of a few locale labels.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
https://github.com/egovernments/DIGIT-Dev/tree/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pages/citizen/OCEDCR - Connect to preview eDCR and OC eDCR are part of OBPS (OBPS DIGIT-UI )
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
/
/
| S.No. | API | Action ID | Roles |
|---|
All content on this page by is licensed under a .
All content on this page by is licensed under a .
PageComponent
MDMS Detail
Module Details Name
Master Detail Name
EDCRForm
City list
tenant
citymodule
S.No.
API
Action id
Roles
1
/egov-mdms-service/v1/_search
954
CITIZEN
2
/edcr/rest/dcr/scrutinize
2075
BPA_ARCHITECT, BPA_TOWNPLANNER, BPA_BUILDER, BPA_STRUCTURALENGINEER, BPA_ENGINEER, BPA_SUPERVISOR
3
/edcr/rest/dcr/scrutinydetails
CITIZEN
4
/bpa-services/v1/bpa/_search
CITIZEN
5
/filestore/v1/files/url
1528
CITIZEN
6
/localization/messages/v1/_search
1531
CITIZEN
EDCRForm | City list |
|
|
DocsRequired | Documents required List |
|
|
BasicDetails | Risk Type |
|
|
OwnerDetails | Gender & Ownership category |
|
|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
API
| Action id | Roles |
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
|
The employee stakeholder flow consists of 2 independent screens and 1 application details page. Users have access to this flow using links in the Inbox and the Search application page.
The stakeholder MDMS data is used to filter views and service types displayed on the screen in accordance with the existing user role. The TradeTypeToRoleMapping MDMS data is also used to filter views based on the selected business service.
The localization module used in the OBPS module comprises rainmaker-bpareg and rainmaker-common. The rainmaker-bpareg is initialized for module localization.
User access to the stakeholder flows and BPAREG business service is role-based. Roles can be - "BPAREG_EMPLOYEE", "BPAREG_APPROVER", "BPAREG_DOC_VERIFIER", "BPAREG_DOC_VERIFIER"
This page provides details on the Stakeholder Registration workflow in the OBPAS module. Citizens have the option to submit registration applications for various stakeholders such as architects and construction companies.
Users can apply for stakeholder application by clicking on the “Register as a Stakeholder”, and while going through the workflow, can add all the information, according to the question asked, in the middle of the workflow after the correspondence address Create API will be called, and at the end of the flow, a summary screen will be visible for the review of the answers and on clicking the submit button an Update API will be called which will change the status from Initiated to Applied and Registration Application will get updated.
The stakeholder Document Required screen is displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for stakeholders. A citizen info card is also shown at the bottom of the page containing additional information such as the maximum size of the file that can be uploaded.
The TimeLine component is present on all pages. It informs the users about the steppers in completing the application for registration.
In this step, users need to provide information about the License type and Licensee.
The system asks for the type of license that the user is registering for. If the user selects architecture, then a new field is displayed i.e. architecture number. For all other roles, no additional information user is required. All the roles are populated from the MDMS.
Here users have to provide the information of the person for whom the license application is being generated. By default, the name and mobile number field will be automatically pre-filled with the logged-in user data. Edits to this detail are disabled. Applicants must fill in the remaining information accordingly.
In this step, users have to enter their address details.
Users have to provide a permanent address. This is mandatory information that the user needs to provide to move to proceed with the application.
Here user gets the option to either pre-fill the form with the permanent address provided earlier or enter a different address. Users can also skip this step as it is non-mandatory.
Clicking on the Next button calls the Create API. Further information is available in the technical Implementation details section.
This screen displays a list of documents and their type (in dropdown format) from the MDMS. The document list displayed is as per the role selected by the user in the license step. Users have to upload all the mandatory documents in order to proceed further.
Users can cross-verify the data entered throughout the flow on the Summary page. In case of any change or update required, the edit icon available adjacent to the section header allows the users to make the changes. It redirects users to the particular section page and the whole flow is repeated again in order to submit the application.
Along with the application details, the fee estimate for the corresponding application is also shown on the summary page.
The Update API is called for the BPAREG Application update. Update API snippet is given below:
If the API response is successful, the Acknowledgement Screen is displayed. Else, the Failed Acknowledgement Screen is displayed.
Click on the Make Payment option to pay the registration fees on the summary screen.
All the screen has been developed using the new-UI structure followed previously in FSM, PGR, PT and TL, few new components have been introduced such as TimeLine, Multi upload Document etc
The link for the Stakeholder Registration Main Index is given below, it can be used to understand the starting point of the flow:
The OBPAS module is segregated into a specified structure. The screen configuration details are available in the PageComponent folder and the configuration for routing of the pages is available in the config folder which is common for both citizens as well as employees. New components like TimeLine are defined in the component folder. Below is the snippet for folder structure and routing configuration.
The stakeholder config responsible for the routing of the pages is defined under the config folder. Click on the link below to access the code.
The Pages folder contains the high-level configuration for controlling the whole flow for citizens and employees. The flows for citizens include Apply flows, Send Back flows, Application details etc. These carry the index (the main starting point of the whole flow).
The main difference between the Stakeholder registration flow from the apply flow in other modules is that the Create API is called in between the flow and at the end, the Update API is called.
The code for Create API request object generation is found inside the correspondence address component. This API call is triggered when the user clicks on the Next button on the correspondence address page.
The hook used for this API call is Digit.OBPSService.BPAREGCreate(payload, tenantId) and payload can be found inside the gonext() method in the following file:
Code reference:
The Utils folder basically contains all the methods that are used throughout the OBPAS module, and if any common method needs to be declared here, which in turn can be imported into other files.
For updating an application the Update API from BPAREG is called using the React hooks, which have been declared under hooks/elements/obps as OBPSService.
The response object from the Create API is used for the request object of Update API, with the addition of document details that the user has entered. This marks the status of the Application as Applied instead of initiated.
Below is the hook used for fetching the update API call.
This API is called in the Stakeholder Acknowledgement code, using the useEffect Hook.
Code reference:
Throughout the flow, a few of the page data is imported from MDMS. Following is the list of pages that use MDMS data. These pages .js files can be found under page components.
For calling the MDMS data, React Hooks are used, so that it could be shared throughout the modules. Below is the little code snippet for the MDMS call.
Localization keys are added in the ‘rainmaker-bpareg’ locale module. In future, if any new labels are implemented in the OBPS - Stakeholder (Citizen) they should be pushed in the locale DB under rainmaker-bpareg locale module. Below is an example of a few locale labels.
The stakeholder search application screen is used to search all the applications independent of its workflow or process instance data, which eliminates the presence of valid roles to search an application from any business service.
The details for this screen are the same as discussed in the OBPS search application. Please refer to the same.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Users can view all the applications assigned to them in the stakeholder inbox. And it provides multiple filters and search options to filter the applications.
Stakeholder Inbox uses InboxComposer React HOC to create the Inbox through various child components, for both mobile and Desktop Components.
Inbox wrapper API used to fetch the inbox data:-
For viewing OBPS inbox these roles are necessary "BPAREG_APPROVER", "BPAREG_DOC_VERIFIER"
.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
PageComponent
MDMS Detail
Module Details Name
Master Detail Name
StakeholderDocsRequired
List of documents required for registration
StakeholderRegistraition
StakeholderRegistraition
LicenseType
License role options
StakeholderRegistraition
StakeholderRegistraition
LicenseDetails
Gender
common-masters
GenderType
StakeholderDocsRequired
Documents and its drop downs
StakeholderRegistraition
StakeholderRegistraition
S.No.
API
Action id
Roles
1
/egov-mdms-service/v1/_search
954
CITIZEN
2
/tl-services/v1/BPAREG/_create
CITIZEN
3
/filestore/v1/files/url
1528
CITIZEN
4
/billing-service/bill/v2/_fetchbill
1862
CITIZEN
5
/tl-calculator/billingslab/_search
1684
CITIZEN
6
/tl-services/v1/BPAREG/_update
CITIZEN
7
/localization/messages/v1/_search
1531
CITIZEN
8
/tl-calculator/v1/BPAREG/_getbill
CITIZEN
