Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Feature release doc
The Stakeholder registration process is done to allow any user access to the Building plan approval portal. The user registers the application for the desired role. Upon approval of the application, the user gets the role based on the application. This role will be stake level role. The user can also register on behalf of the organisation.
Notes:
Users can register for one role with a mobile number only once
After submission of the application user login is required to pay and view the status of his application
The citizen will get a state-level role on approval of his application
Employees performing actions on user applications must have suitable state-level roles
License types: Engineer, Town Planner, Builder, Architect, Structural Engineer
Actors: Citizen, Document Verifier, Approver
States of any application: Initiated, Pending for payment, Pending for document verification, Pending for approval, Approved, Rejected
Promote latest MDMS
MDMS
TradeLicense:- added type field in existing records and added new trade types
StakeholderRegistraition:- Contains additional information for each of the trade types being used in BPA registration
Endpoints:
Please whitelist the endpoint from Zuul wherever required
/tl-services/v1/BPAREG/_create:- mixed (both whitelisted and auth based)
/tl-services/v1/BPAREG/_update:- mixed (both whitelisted and auth based)
Auth based access:- CITIZEN,BPAREG_DOC_VERIFIER, BPAREG_EMPLOYEE, BPAREG_APPROVER
/tl-services/v1/BPAREG/_search :- Citizen, Approver, Document Verifier
/tl-calculator/v1/BPAREG/_getbill:- mixed (both whitelisted and auth based)
Auth based access:- CITIZEN,BPAREG_DOC_VERIFIER, BPAREG_EMPLOYEE, BPAREG_APPROVER
Users:
Create users with state level roles(tenantId=’pb’) , BPAREG_DOC_VERIFIER, EMPLOYEE, BPAREG_APPROVER
Create an anonymous user(related to whitelisting). Please refer to the end of this doc
Workflow config file -
Service Builds (use these or newer builds from master)
Billing-service-5f944c55c5-4dqcx
TL-service: tl-services-db:42-bpa-work-9371fe2
TL-calculator: tl-calculator-db:10-bpa-work-128d676
Citizen - citizen:210-Nov-15-Release-49699801
Employee - employee:238-Nov-15-Release-49699801
Zuul: zuul:21-master-5368046
Workflow: egov-workflow-v2:9-WF_MULTITENANCY-40d533f
Restart user and encryption service
Persister Config
Localisation File:
SQL Query:
Please run the below SQL script to add state-level bank account:
insert into egf_bank ( id,code,name,active,tenantid) values ( '23','AXIS','AXIS BANK',t,'pb')
insert into egf_bankbranch(id,bankid,code,name,address,city,state,contactperson,active,createddate ,lastmodifieddate,tenantid) values ('8','23','123','Axis_Bank_Ltd_Punjab','Amritsar','Amrisar','Punjab','ABCD','t','2019-08-16 21:04:32.064' ,'2019-08-16 21:04:32.064','pb')
insert into egf_bankaccount(id,bankbranchid ,chartofaccountid,fundid , accountnumber,accounttype , active ,type, createddate, lastmodifieddate ,tenantid) values ('8','123','1234','12', '91101055559123', 'SAVINGS' ,'t' ,'RECEIPTS_PAYMENTS', '2018-08-16 21:24:48.837','2018-08-16 21:24:48.837','pb')
Add ANONYMOUS role and create a system user as given below
https://egov-micro-qa.egovernments.org/user/users/_createnovalidate
We are using re-indexing to get all the data to respective indexer. We have 2 steps for this. First as to run the connector from playground, which is followed by legacyindexer service call from indexer service, which internally call the respective plain search service to get the data and to send to respective indexer.
Prerequisites:
Access to kubectl of the environment targetted
Postman scripts
Plain search apis in the respective services
OBPS reindexing steps
Connect to playground pod.
Delete the kafka connector if already exists with the kafka connection, using below command through playground pod.
Run below kafka connector curl from playground pod:
port forward to egov-indexer pod and run below curl throw postman.
Delete the kafka connection after all the data has been re-indexed by follwing below command through playground pod.
Alias water-services-enriched as water-services through kibana server.
This service is the major service supporting bpa-services which handles the data of the land like land details, owner information, unit, address and documents which has the complete information of the land.
Which can be used as input for the bpa-services to create and process the Building Plan Application.
This section covers the high-level details of the functionalities available Land Service
UI integrated as part of BPA screens
Ability to create/update Land Details
Knowledge of Java/J2EE(preferably Java 8 version)
Knowledge of Spring Boot and spring-boot microservices.
Knowledge of Git or any version control system.
Knowledge of RESTful Web services.
Knowledge of the Lombok library will helpful.
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-user, eGov-localization will be helpful.
The Application is present among the municipal services group of applications available in the eGov-services git repository with the folder name land-services. The spring boot application needs the Lombok* extension added in your IDE to load it. Once the application is up and running API requests can be posted to the URL and ids can be generated.
in 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
Please refer to Swagger API for YAML file details. Link - API Specs.
Here we are listing the configs apart from dependent service host, url’s, DB and Flyway configs.
kafka topics persister configs for eGov persister to save and update land Data
persister.save.landinfo.topic=save-landinfo
persister.update.landinfo.topic=update-landinfo
egov-user - ( Manage user )
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-persister ( Helps to persist the data )
There is not MDMS config for Land Service exists as of now.
Access MDMS Config
Action Test : URL Actions adding
Access to the Roles for the above Actions
NA
NA
NA
BPA application and BPA Occupancy Certificate application has Fee involved. Based on the Application Type, RiskType and ServiceType Fee to be calculated and generates a demand for the calculated amount for Payment. This service used to generate Application Fee, Sanction Fee, Low Application Permit Fee, Deviation Charges for BPA application and Occupancy Certificate Application.
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, bpa-services will be helpful.
bpa calculator services present in municipal services provide multiple functionalities like calculating Application Fee, Sanction Fee, Low Permit Fee, OC Deviation Charges, generating demands for a particular BPA, BPA OC applications, updating demands, The different functionalities provided by sewerage calculator services are:
The Application is present among the municipal services group of applications available in the eGov-services git repository with the folder name bpa-calculator. The spring boot application needs the Lombok* extension added in your IDE to load it. Once the application is up and running API requests can be posted to the URL and ids can be generated.
in 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
Business service codes for
BPA High/Medium Risk Application Fee
egov.demand.appl.businessservice=BPA.NC_APP_FEE
BPA High/Medium Risk Sanction Fee
egov.demand.sanc.businessservice=BPA.NC_SAN_FEE
BPA Low Risk Permit Fee
egov.demand.lowriskpermit.businessservice=BPA.LOW_RISK_PERMIT_FEE
BPA OC Application Fee
egov.demand.oc.appl.businessservice=BPA.NC_OC_APP_FEE
BPA OC Sanction Fee
egov.demand.oc.sanc.businessservice=BPA.NC_OC_SAN_FEE
Tax Head Code for
BPA High/Medium Risk Application Fee
egov.appl.fee=BPA_APPL_FEES
BPA High/Medium Risk Sanction Fee
egov.sanc.fee= BPA_SANC_FEES
BPA Low Risk Sanction Fee
egov.low.sanc.fee= BPA_LOW_SANC_FEES
BPA Low Risk Application Fee
egov.low.appl.fee=BPA_LOW_APPL_FEES
BPA OC Application Fee
egov.oc.appl.fee=BPA_OC_APPL_FEES
BPA OC Sanction Fee
egov.oc.sanc.fee= BPA_OC_SANC_FEES
External Application references
dcr-services (Use Edcr data )
egov-mdms ( Configurations/master by MDMS )
billing-service ( Generate and update demands )
bpa-services (Get the bpa application data for fee calculation )
bpa-calculator/v1/_calculate End point to calculate the Fee and create Demand with the applicable businessService and TaxHeads
Access MDMS Config
bpa-calculator cannot be accessed publicly, Only called by the bpa-calculator
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
NA
NA
NA
NA
NA
This document mainly covers all the steps that one needs to do for setting up a new instance of eDCR (Development Control Regulations). Say when a new State is to be set up, there are some activities to be executed in a defined order. Setting up an instance of an application server and configuring customer-specific rules, and data, etc are a few of the key activities.
Centralized Server hosting all the ULBs within a state
All ULBs access the software over API calls.
Uniform code base supporting all the ULBs for the state. City-specific changes are maintained using client-specific implementation repositories.
A separate schema for each ULB in the database.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring and Hibernate
Prior knowledge of Maven
Prior knowledge of Git.
Install the below version of the software in local machine
maven v3.2.x
PostgreSQL v9.6
Git 2.8.3
JDK 8 update 112 or higher
eDCR Service repository will be used to define default rules. The statewide rules to be defined within the client implementation repository.
How to set up a client implementation repository
After creating a client implementation repository, If you want to override rules processing for features, then create a project under egov directory like egov-client-impl.
The client-specific rules are configurable in the individual client implementation module. Here the rules are fetched by state wise, district wise, ULB wise, or grade-wise.
How to override rule processing across the state for a feature
The EG_CITY table, master data is used to decide the rules.
If the rules are the same for a feature across the state then the filename must need to keep like Far_{Client.id}.
Here client id nothing but a state name, the client.id need to update with the state name in application-config-client.properties file (Available in https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/resources/config/application-config-client.properties) or in egov-erp-override.properties file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config).
The client id used with the feature class name and configures in the properties file should match, then only the system will pick features and process otherwise it won't pick the file.
Eg: https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/java/org/egov/client/edcr/Far_Client.java Here filename to be added as Far_Assam.java for the Assam state rules.
How to override rule processing district, city, and grade wise for a feature
If the rules varying across district, city, and grade wise within a state then must need to follow the following naming conventions.
If the rules are varying from district to district, then the respective district-related rules need code under separate files with a filename like Far_{District Name}. eg: Far_Udalguri.
Similarly, if rules varying for city and grade wise then those respective rules need to code under separate files with a filename like Far_{City Name}, Far_{Grade}. eg: Far_Dispur, Far_Corp
The district, city, and grade information will be reading from the eg_city table, so in this table need to update that information before starting the coding.
In a state, only for one or two cities if the rules are changing then need to override rules only for those cities in a separate file, for other all cities the default code will pick. Here default code is state level (Far_{Client id}) configured one.
Configuration Changes to setup State and Cities
The state is configured by adding property tenant.{domain_name}=schema_name (state_name) in egov-erp-override.properties**.**
Each new ULB is enabled by adding a schema name and domain name in egov-erp-override.properties file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config). Schema names should follow a naming standard, It should be the same as that of the city name.
Each ULB can be configured by adding an entry like tenant.{domain_name}=schema_name (city_name) in egov-erp-override.properties file.
Insert data into eg_city, in the city table domain URL value should be the same as configured tenant domain_name in the egov-erp-override.properties.
Changes required for local machine workspace setup
Setup your eDCR service workspace by following the instructions provided in https://github.com/egovernments/eGov-dcr-service/blob/master/README.md
After set up is done, the local ubuntu machine need to update the domain URLs in the host file which you are going to use for scrutinizing and fetching the plan.
Navigate to the root directory and from there open the host config file available in the location 'etc/hosts'. Map the domain URLs with a local IP address in the hosts file and save the changes.
Update settings in standalone.xml under ${HOME_DIR}/wildfly-11.0.0.Final/standalone/configuration
Add 'max-post-size' attribute with value 100mb in bytes in the below location,
<server name="default-server"> <http-listener name="default" socket-binding="http" max-post-size="104857600" redirect-socket="https" enable-http2="true"/> <https-listener name="https" max-post-size="104857600" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/> </host> </server>
MDMS Integration
If you want to fetch master data from MDMS for following ApplicationType, ServiceType, OccupancyType, SubOccupancyType, Usages then the following configurations are needed,
Enable fetch master data from MDMS by adding mdms.enable=true property in application-config-client.properties file (Available in https://github.com/egovernments/egov-dcr-client/blob/master/egov/egov-client-impl/src/main/resources/config/application-config-client.properties) or in egov-erp-override.properties file(Available in Wildfly server under ${HOME_DIR}/wildfly-11.0.0.Final/modules/system/layers/base/org/egov/settings/main/config).
Add the property and update the MDMS hostname, mdms.host={HOST_NAME} in application-config-client.properties file or egov-erp-override.properties file
Add the property and update the MDMS search URL, mdms.searchurl=/egov-mdms-service/v1/_search in application-config-client.properties file or egov-erp-override.properties file
By default, the master data will be fetched from the database.
If you want to fetch from MDMS instead of the database then the above configurations are required.
After setup is done APIs one must use state domain URL and in the contract tenantId of concern, the city has to be passed to scrutinize multiple cities.
One should not use the city domain URL to scrutinize or fetch plan if used that way, the response will be empty.
The tenantId used should follow {state_name.city_name} naming convention, then the state_name passed in the request and city code in the state schema must be the same.
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”.
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
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
The Application is present among the municipal services group of applications available in the eGov-services git repository with the folder name bpa-services. The spring boot application needs the Lombok* extension added in your IDE to load it. Once the application is up and running API requests can be posted to the URL and ids can be generated.
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
Please refer to Swagger API for YAML file details. Link - API Specs.
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
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)
Under the data/<state code> folder you can find the BPA which has all the MDMS JSON’s
master-config.json for BPA
Action Test : URL Actions adding
Access to the Roles for the above Actions
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
Tax Head for BPA High/Medium Risk
TaxHead config for BPA Low Risk
TaxHead config for BPA OC
TaxPeriod MDMS for BPA High/Medium Risk
TaxPeriod MDMS for BPA Low Risk
TaxPeriod Config for BPA OC
BPA Application Number format Config
BPA Permit Number format Config
BPA Receipt Number format config
BPA OC Receipt Number format config
Setup the locality Search query in the localitySearcher.yml as a new entry. Add RoleAction Test and Role Action for the URL “/egov-searcher/locality/bpa-services/_get“
BPA - Building Plan Approval Apply High/Medium Risk
BPA Low – Building Plan Approval Apply Low Risk
BPA OC - Building Plan Approval Occupancy Certificate Apply
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
Make sure the new documentType added exists in documentType of common-masters
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
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 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.
BPA supports below PDF’s
For every building plan application, there is a need to get the No objection certificate from the concerned departments. Based on the configuration we have for the NOCs, for every application, there will be a set of NOCs required. There should be a provision to allow the NOC department user to login to our system and upload the required NOC. We are providing a user to one NOC department. Based on the workflow mode(online/offline) of each NOC type, the NOC department user can perform the action.
Online mode – NOC department user can log in to the system and approve/reject the application.
Offline mode – NOC application will be auto-approved.
Knowledge of Java/J2EE(preferably Java 8 version)
Knowledge of Spring Boot and spring-boot microservices.
Knowledge of Git or any version control system.
Knowledge of RESTful Web services.
Knowledge of the Lombok library will helpful.
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-user, eGov-localization will be helpful.
egov-user (Manage user)
egov-idgen (To generate the application No)
egov-localization (To use the localized messages)
egov-location (To store the address locality)
egov-mdms (Configurations/master data used in the application is served by MDMS)
egov-notification-sms (Service to send SMS to the users involved in the application)
egov-persister (Helps to persist the data)
egov-workflow-v2 (Workflow configuration for different BPA application is configured)
Fire Noc: online configuration
Airport Authority: online configuration
NA
NA
Technical Doc
DSS has two sides to it. One is the process in which the data is pooled into ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across.
As this revolves around a variety of data sets, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.
This document explains the steps on how to define the configurations for the analytics side Of DSS for OBPS.
What is analytics?
Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.
Analytics Configurations: Analytics contains multiple configurations. we need to add the changes related to OBPS in this dashboard analytics. Here is the location : configs/egov-dss-dashboards/dashboard-analytics at qa · egovernments/configs
Below is a list of configurations that need to be changed to run OBPS successfully.
Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration
Each visualization has its own properties. Each visualization comes from different data sources (Sometimes it is a combination of different data sources).
In order to configure each visualization and its properties, we have a Chart API configuration document.
In this, visualization code, which happens to be the key, will have its properties configured as a part of the configuration and easily changeable.
Below is the sample ChartApiConfiguration.json data for the OBPS.
Click here to check the complete configuration
Master dashboard configuration is the main configuration which defines which Dashboards are to be painted on screen.
It includes all the visualizations, their groups, the charts which come within them and even their dimensions as what should be their height and width.
Click here for the complete configuration
Master dashboard configuration which was explained earlier hold the list of Dashboards which are available. Given the instance where Role Action Mapping is not maintained in the application service, this configuration acts as the Role-Dashboard mapping configuration.
In this, each role is mapped against the dashboard which they are authorized to see. This was used earlier when the role action mapping of eGov was not integrated.
Later, when the role action mapping started controlling the dashboards to be seen on the client side, this configuration was just used to enable the dashboards for viewing.
Click here to check the configuration
common-masters/uiCommonConstants.json
Click here to check the complete configuration
roleaction.json
Click here to check the complete configuration
Action test.json:
Click here to check the complete configuration
OBPS-State DSS consists of multiple graphs which represent the data of OBPS. Each graph has its own configuration which describes the chart and its type.
State DSS consists of the following charts in OBPS:
Overview-Revenue
Overview-Service
Total Cumulative Collection
Total permits issued vs Total OC submitted vs Total OC issued
Collection by Payment Mode
Top 3 Performing States/ULBs/Ward
Bottom 3 Performing States/ULBs/Ward
Permits Issued by Risk Type
Permits Issued by Occupancy Type
Service Report
More details about the respective charts are below:
Overview-Revenue: The Overview-Revenue chart contains multiple data information as below in the selected time period.
Today's Collection - This represents today’s collection amount for OBPS Application Fee + Permit Fee.
Total Collection - This represents the total collection amount for OBPS Application Fee + Permit Fee.
Overview-Service: The Overview-Service chart contains multiple data information as below in the selected time period.
Total Plans Scrutinized - This represents the total number of plans submitted by an architect for scrutiny for new construction to the concerned authority.
Total permits issued - This represents the total number of new permits issued by the concerned authority.
Total sq m of land applied in the BPA system - This represents the total area in square meters approved for construction.
Avg. days to issue permits - This represents the average number of days taken to issue a permit application.
SLA Compliance (Permits) - This represents the total percentage of permits issued within SLA.
Avg. days to issue OC - This represents the average number of days taken to issue an OC.
SLA Compliance (OC) - This represents the percentage of OCs issued within SLA
Total Cumulative Collection: This graph contains the OBPS collection amount information on a monthly basis as a cumulative line graph for each OBPS collection separately. This changes as per the denomination amount filter selection.
line - this graph/chart is data representation on date histograms or date groupings.
Total permits issued vs Total OC submitted vs Total OC issued: This graph shows the total permits issued vs total OC submitted vs total OC issued for a given time period in the form of a line chart.
line - this graph/chart is data representation on date histograms or date groupings.
Collection by Payment Mode: This chart is a pie chart showing the bifurcation of total collections by payment mode (online, cash, card, cheque) which is the sum of revenue collected from the OBPS module for the applied date filter.
Top 3 Performing ULBs: This card will show the Top 3 Performing ULBs based on the percentage of permits issued. The number of permits issued / Number of applications.
Bottom 3 Performing States: This card shows the bottom 3 Performing States/ULBs/Wards based on the percentage of permits issued. Number of Permits issued / Number of applications
Permits Issued by Risk Type: This chart is a pie chart showing the bifurcation of total permits issued by risk type (low risk, medium risk, high risk) for the applied date filter.
Permits Issued by Occupancy Type: This chart is a pie chart showing the bifurcation of total permits issued by occupancy type (Residential, Institutional etc) for the applied date filter.
Service Report: This tabular chart representation graph shows information about multiple OBPS-related categories like Total Collection or Total Cumulative Collection, Total Plans Scrutinized, Total applications submitted, Total permits issued, Avg. days to issue a permit, SLA Compliance (Permits), Total OC Plans scrutinized, Total OC submitted, Total OC issued, Deviation Percentage, Avg. days to issue OC, SLA Compliance (OC), Total OCs with deviation. This table also shows the data at the state level and also has the drill-down chart for each state to ULB and from ULB to ward level data for the same.
Clicking on any DDR name drills down the charts to show the specified state data.
Clicking on the ULB navigates to the ward-level data for the specified ULB.
isRoundOff: This property is introduced to round off the decimal values. For instance, if the value is 25.43 by using isRoundOff property in the configuration, the value is displayed as 25. Similarly, if the value is 22.56 round of value is displayed as 23. This can be used for insights configuration as well for overview graphs.
Key(eg: bpaTotalCollection): This is the visualization code. This key is referred to in further visualization configurations. This is the key which will be used by the client application to indicate which visualization is needed for display.
chartName: The name of the chart which has to be used as a label on the dashboard. The name of the chart will be a detailed name. In this configuration, the Name of the Chart will be the code of Localization which will be used by the Client Side.
queries: Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation.
The queries of aggregation which are to be used to fetch out the right data in the right aggregated format are configured here.
queries.module: The module/domain level, on which the query should be applied i.e., OBPS
queries.indexName: The name of the index upon which the query has to be executed is configured here.
queries.aggrQuery: The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index
queries.requestQueryMap: Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents.
In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.
queries.dateRefField: Each of these modules have separate indexes. And all of them have their own date fields.
When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields.
In order to maintain what is the date field in which index, we have this configured in this configuration parameter.
chartType: As there are different types of visualizations, this field defines what is the type of chart/visualization that this data should be used to represent.
metric - this represents the aggregated amount/value for records filtered by the aggregate es query
pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts
line - this graph/chart is data representation on date histograms or date groupings
perform - this chart represents groping data performance-wise.
table - represents a form of plots and values with headers as grouped on and a list of its key, values pairs.
xtable - represents an advanced feature of the table, it has the addition capabilities for adding dynamic header values.
valueType - In any instance of data, the values which are sent for plotting, might be a percentage, sometimes an amount or sometimes just a count.
In order to represent them and differentiate the numbers from the amount from the percentage, this field is used to indicate the type of value that this visualization will be sending.
action: Some of the visualizations are not just aggregations of data sources. There might be some cases where we have to do a post-aggregation computation.
For example, in the case of the Top 3 performing ULBs, the target and total collection are obtained and then the percentage is calculated. In these kinds of cases, the action that has to be performed on the data obtained is defined in this parameter.
documentType: The type of document upon which the query has to be executed is defined here.
drillChart: If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill-downs.
aggregationPaths : All the queries will be having Aggregation names in it. In order to fetch the value out of each Aggregation Responses, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in them.
insights: It is to show the data with the comparison of last year with arrow symbols, it will show the data in how much % is increased or decreased.
_comment: In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.
Java 1.8
Eclipse
Postgres
PhpPgAdmin
Postman (Application)
Respective Git MiddleWare
Kubectl
Kafka
Take the code pull from the git:
Need to consider 2 repositories for code to run locally
Municipal services - where our BPA code exists and some dependency services also available here
Core Services - Where dependency services exist to run our code locally
Import the required projects to eclipse
From municipal-services import bpa-services, bpa-calculator and land-services. From core-services import user service, idgen service, mdms service, location service, localization service, workflow service, egov-persister.
Before running the application make sure the following setups are complete to ensure the application runs smoothly.
kafka set up in your system which is running fine. Download the latest version of kafka from here.
Run the below commands based on your system types
For linux: in kafka folder path
Example: D:\kafka_2.13-2.4.0
> bin/zookeeper-server-start.sh config/zookeeper.properties > bin/kafka-server-start.sh config/server.properties
For Windows: in windows path
Example: D:\kafka_2.13-2.4.0\bin\windows start zookeeper-server-start.bat ....\config\zookeeper.properties start kafka-server-start.bat ....\config\server.properties
Kubectl setup based on the requirement To get the pods: kubectl get pods To port forward: kubectl port-forward <<pod name>> <<port number>>:8080 To get the logs: kubectl get logs
After all the setups are done successfully, try to run the application locally.
BPA-Services How to run the application in local:
Check the services which are connected to local and which are connected to dev
Which are connected to dev no need to change anything.
If it is connected to local check the services are in below list IDGEN – can run locally or can point to dev from cmd prompt PERSISTER – can run locally MDMS – can directly point to dev or can run in local LOCATION – can directly point to dev WORKFLOW – can point to dev or can run locally LOCALIZATIONS – we can directly point this to dev USER-SERVICE – need to point to dev from cmd prompt LAND-SERVICE – need to run locally BPA-CALCULATOR – can run locally or can point to dev.
If the changes are from these services follow the below process to run those respective services.
For core services:
IDGEN:
Approach 1: Directly point this to dev from the application.properties in bpa-services Approach 2: Point this to local and give the port forward to dev by using kubctl.
Note: We are not running this service locally.
PERSISTER:
U need to run it in local and need to add respective yaml files in persister resource folder which are bpa-persister.yml and egov-workflow-v2-persister.yml and also land-persister.yml
And need to add these in persister application.properties repo path
Note: Please check whether data is is saving or not in local data base(DB).
MDMS:
to run local: For running this in local need to change in 2 file that is application.properties and MDMSApplicationRunnerImpl
In application.properties need to change the paths for the master-config url as path of master-config.json and for config path as upto pb/bh
In MDMS ApplicationRunnerImpl need to change the data in a function from the path to file.
to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services
Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
LOCATION
Approach 1: Give it a local connection in BPA application.properties and port forward to dev by using kubectl.
Approach 2: Directly point this to dev from the application.properties in bpa-services
Note: Not tried it in local / may got errors so pointing to dev.
WORKFLOW
to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services
Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
to run local:
can run locally by pointing to the local database, but for this need to create the workflow locally using the workflow create API.
USER-SERVICE Approach 1: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
Approach 2: Directly point this to dev from the application.properties in bpa-services
Note: In local not able to run the application successfully, so the following dev.
LOCALIZATIONS
Approach 1: Directly point this to dev from the application.properties in bpa-services
Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
Changes from Municipal services
BPA-Calculator:
to run local:
can run locally by pointing to the local database.
to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services
Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
Land-Service:
to run local:
can run locally by pointing to the local database.
to point to dev: Approach 1: Directly point this to dev from the application.properties in bpa-services
Approach 2: Give it as local connection in BPA application.properties and port forward to dev by using kubectl.
Other than these services can directly by pointing to dev url.
Note: After running the application successfully please check if the data is saving in db or not.
egov-user - (Manage user)
tl-services - Stakeholder Registration (Registration process of Stakeholder is handled by this service)
egov-user-event (What’s New and Events)
egov-filestore (To store the documents uploaded by the user)
egov-idgen (To generate the application No, Permit No)
egov-indexer (To index the BPA data)
egov-localization (To use the localized messages)
egov-location (To store the address locality)
egov-mdms (Configurations/master data used in the application is served by MDMS)
egov-notification-sms (Service to send SMS to the users involved in the application)
egov-persister (Helps to persist the data)
egov-searcher (Search query used to simplify the search)
egov-workflow-v2 (Workflow configuration for different BPA application is configured)
pdf-service (Receipt’s, permitorder etc.. and prepared)
billing-service (Create demands and bills for the fees to be collected)
collection-services (Create a receipt for the payment received for the bills)
bpa-calculator (Calculates the fees to be collected at different stages)
land-services (land information related to BPA application is stored)
dcr-services (get and validate EDCR data)
For automatic building plan scrutiny
Building plan approval (BPA) is one of the key activities performed by Urban Local Bodies and Planning Authorities. The Online Building Plan Application Software (OBPAS) automates the various steps in the plan approval process. The core intelligence of OBPAS resides in the automatic scrutiny of building plans with reference to the Development Control Regulations of the state. This functionality is called eDCR (eGov-DCR). It involves extracting the key plan parameters from the CADD drawing and evaluating the parameters against the defined rules in the State Development Control Regulations. Once the Plan Scrutiny is completed the application will be processed for other workflow stages like Document Verification, Field Verification, NOC Certificates, Fee Computation, and Permit Generation.
DIGIT offers the complete OBPAS as an open-source application and eDCR is an integral part of it. The automatic scrutiny capability provided by eDCR can be leveraged by States which already have existing BPA software through simple integration. This enables the States to reduce the manual and time-consuming process of evaluation of rules and ensures uniformity of evaluation.
This doc helps in understanding the integration process of eDCR Service with an existing Building Plan Application software. At a broad level, competencies in the below technical and functional areas are necessary for integrating eDCR system,
Integration expertise is backed by a sound understanding of the architecture of the existing ecosystem, its uniqueness, features, flaws, and a complete understanding of the challenges involved in making them successfully work together.
Subject matter expertise on Building Plans and DCR Rules to interpret DCR Rule Validation algorithm from the DCR Rules.
A good understanding of the configuration of the DCR Rule Validations in the Validation Engine of the eDCR Service
Note: The detailed training prerequisites for integrating eDCR into any legacy BPA system are listed in section.
The eDCR process typically involves the below sequence of steps,
Capture drawing files in DXF format along with city identifier
Submit DXF format drawing file to eDCR system for scrutiny
Collect generated reports from eDCR system with status as accepted or rejected. The eDCR system will generate additional information like floor-wise area details, compound wall length, number of wells, etc
The DXF file can be resubmitted any number of times into the system, irrespective of the acceptance or rejection status
An accepted status of the drawing indicates that it is validated and approved against all the bylaws configured in the system. The integrating system can use this for further processing
The eDCR status report and associated details can be retrieved at a later point also by sending the unique Transaction Number to eDCR system
The eDCR service has Extraction, Validation, and Repository as the key components. The architecture depicted here covers integration aspects and API requirements.
The diagram below clearly illustrates the process flow in the eDCR system. There are two major stages in the process:
Upload and Scrutinize Plan
Get Details (To check plan scrutiny status)
eDCR system will provide REST APIs to push drawing files (DXF format) along with a unique ID. The Integrating system will provide a unique Transaction Number. The same will be used by both systems to track applications.
eGov will publish two REST APIs.
Upload And Scrutinize Plan: The integrating system should call this API with the required parameters explained in the API structure. The system will scrutinize the plan and reply with a response as explained in the API structure. The Status "Accepted" indicates the plan is ready to use for further process. "Rejected" will indicate that either plan violates the rule or is missing basic information. Both rejected and accepted plans can be resubmitted. But eDCR system will consider each request as a new one.
Get Details: The integrating system will call this API with parameters specified in the API structure. The eDCR system will search for the details in the eDCR repository and respond with a) Status - accepted/rejected b) Scrutiny report c) Plan details (details present in Dxf) d) DXF file e) Generated Plan pdfs. If the transaction number or Autodcr number does not exist in the system, an appropriate message is published.
Note: The REST API reference information with Request/Response Structures, Request Urls, Methods, Status Messages, and Samples will be shared in subsequent documents.
For integrating eDCR the below knowledge and infrastructure requirements need to be addressed
State building by-laws with the latest amendments (hard or soft copy)
Subject matter expert (SME) from the ULB side, who understands the by-laws and building plan domain
An architect who can draw diagrams for the team to test – He or She should be able to understand the by-laws given by the SME and create diagrams to validate those by-laws in the diagram scrutiny
The technical team should have resources with 5+ years of experience in J2EE technology - Java, Spring, Hibernate, Postgress, Jboss/Wildfly, and GIT
The technical team should be equipped with LINUX machines preferably UBUNTU and the following
Maven v3.2.x
PostgreSQL v9.6
Elastic Search v2.3.5
Git 2.8.3
JDK 8 update 112 or higher
Eclipse or any IDE
Cloud instance for deployment (Azure / AWS)
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.
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.
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
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
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.
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"
Refer to the config below for risk type definition:-
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.
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.
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.
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 eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Branch out and create a eDCR service repository from https://github.com/egovernments/eGov-dcr-service - Connect to preview master repository. Refer https://github.com/egovernments/egov-dcr-client - Connect to preview for the client implementation setup has been done.
| Title | Link |
|---|---|
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 eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Please refer to Swagger API for YAML file details. Link - .
All content on this page by is licensed under a .
Ref:
And lombok setup for eclipse For ref:
Postman Collection
Postman collection
Postman collection
Postman Collection:
Postman Collection
All content on this page by is licensed under a .
All content on this page by is licensed under a .
File Path:
File Path:
File Path:
Apply for the building plan permit button for creating the BPA application( )
File Path:
File Path:
File Path:
Apply for OC For New Construction button, for creating the BPA application( )
eDCR and OC eDCR are part of OBPS ( )
All content on this page by is licensed under a .
The MDMS links (blue text hyperlinks) are used while selecting the OBPS , , risk type with business service and status filters.
All content on this page by is licensed under a .
/
/
| 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 .
MDMS Name
Path
Description
Example Json
CalculationType
Used by bpa-calculator Service which Defines the Fee to be collected for Given ApplicationType, ServiceType, RiskType and feeType
2. Second Example defines the calculation logic to figure out the fee for the Service, considering the different parameters from EDCR information of the BPA.
ParameterPath indicates the EDCR Response Data path to get the data point.
from
Indicates the from value of the data point to be considered
to
Indicates the to value of the data point to be considered
MF
multiplication factor to be considered to multiple the datapoint value to calculate the value when data point value falls between from and to
UOM
UOM to be considered to multiple the datapoint value and MF to calculate the Fee when data point value falls between from and to
{ "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "ALL", "riskType": "LOW", "feeType": "SanctionFee", "amount": 500 }, { "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "NEW_CONSTRUCTION", "riskType": "ALL", "feeType": "ApplicationFee", "amount": 120 }, { "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "NEW_CONSTRUCTION", "riskType": "LOW", "feeType": "Low_ApplicationFee", "amount": 100 }, { "applicationType": "BUILDING_OC_PLAN_SCRUTINY", "serviceType": "ALL", "riskType": "ALL", "feeType": "SanctionFee", "amount": 500, "calsiLogic": [ { "parameter": "builtuparea", "tolerancelimit": 10, "calculationType": "number", "deviation": [ { "from": 11, "to": 50, "MF": 1, "uom": 100 }, { "from": 51, "to": 100, "MF": 2, "uom": 150 }, { "from": 101, "to": 499, "MF": 3, "uom": 200 } ], "paramPath": "edcrDetail[0].planDetail.virtualBuilding.totalBuitUpArea" } ] }
From the above example
indicates SanctionFee is Rs 500 for applicationType=BuildingPlanScrutiny, RiskType=LOW and any ServiceType
indicates applicationFee is Rs 120 for applicationType=BuildingPlanScrutiny, ServiceType=NEW_CONSTRUCTION and any RiskType
indicates applicationFee is Rs 100 for applicationType=BuildingPlanScrutiny, ServiceType=NEW_CONSTRUCTION and RiskType=LOW
Design and Architecture
API Contracts
Repository the default rule processing code available
Sample client implementation repository
Configuring MDMS
MDMS Name
MDMS Path
Description
Example
ServiceType
Values for ServiceType Dropdown
NA
Application Type
Values for Application Type Dropdown
NA
Occupancy Type
Values for Occupancy Type Dropdown
NA
SubOccupancy Type
Values for SubOccupancy Type Dropdown
NA
DocumentTypeMapping
List’s out the documents required at the given stage of the application for Given ApplicationType, ServiceType, RiskType and WorklowState.
In the docTypes we have
Order - Indicates the sequence of the document
Code - Refers to the DocumentType parentGroup from DocumentTypes from common masters MDMS
allow - Indicates allow to edit
required - Mandatory at given stage
{ "applicationType": "BUILDING_PLAN_SCRUTINY", "ServiceType": "NEW_CONSTRUCTION", "RiskType": "LOW", "WFState": "INPROGRESS", "docTypes": [ { "code": "APPL.IDENTITYPROOF", "required": false, "allow": "false", "order": 1 }, { "code": "APPL.ADDRESSPROOF", "required": true, "allow": "true", "order": 2 } ]}
Above example indicates Documents from the common-master documentTypes starting with code(s) in the above example should be displayed in BPA Application UI when the Application of ApplicationType -BUILDINGPLAN_SCRUTINY ServiceType- NEW_CONSTRUCTION RiskType- LOW Workflow State - INPROGRESS Out of this, IDENTITY documentType is not allowed to upload in this stage and not mandatory. ADDRESSPROOF documentType is allowed to upload in this stage and mandatory to move forward from this stage.
CalculationType
Used by bpa-calculator Service which Defines the Fee to be collected for Given ApplicationType, ServiceType, RiskType and feeType
{ "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "ALL", "riskType": "LOW", "feeType": "SanctionFee", "amount": 500 }, { "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "NEW_CONSTRUCTION", "riskType": "ALL", "feeType": "ApplicationFee", "amount": 120 }, { "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "NEW_CONSTRUCTION", "riskType": "LOW", "feeType": "Low_ApplicationFee", "amount": 100 },
From the above example
indicates SanctionFee is Rs 500 for applicationType=BuildingPlanScrutiny, RiskType=LOW and any ServiceType
indicates applicationFee is Rs 120 for applicationType=BuildingPlanScrutiny, ServiceType=NEW_CONSTRUCTION and any RiskType
indicates applicationFee is Rs 100 for applicationType=BuildingPlanScrutiny, ServiceType=NEW_CONSTRUCTION and RiskType=LOW
RiskTypeComputation
Helps to Defines the RiskType of the Application based on the building Height and plotArea received from the EDCR System
{"fromPlotArea": 500, "toPlotArea": 9999999999, "fromBuildingHeight": 15, "toBuildingHeight":9999999999, "riskType": "HIGH", "note": "(Heigh 15 Mt or More) or ( Plot area >=800 sq.Mt)" }
CheckList
Used to Define the List of Questions and Documents to be attached on Field Inspection Pending Stage by Field Inspector.
The Example indicates
Four Questions with fieldType “YES/NO/NA“ ( Which indicates that field of type dropdown with Yes, NO and NA options) should be asked.
Readable question will be available in
2. Used to configure the conditions for Approval Stage
Condition checkboxes to be shown before approve which can be considered as Conditions for Approval
Field Inspection Questions & Documents { "applicationType": "BUILDING_PLAN_SCRUTINY", "ServiceType": "NEW_CONSTRUCTION", "RiskType": "LOW", "WFState": "FIELDINSPECTION_PENDING", "questions": [ { "question": "RIVER_EXISTS_ON_SITE", "fieldType": "YES/NO/NA", "active": true }, { "question": "TREE_EXISTS_ON_SITE", "fieldType": "YES/NO/NA", "active": true }, { "question": "PLAN_AS_PER_THE_SITE", "fieldType": "YES/NO/NA", "active": true }, { "question": "ROADWIDTH_AS_PER_THE_PLAN", "fieldType": "YES/NO/NA", "active": true } ], "docTypes": [ { "code": "FI.FIR", "required": true }, { "code": "FI.SINS", "required": true }, { "code": "FI.SISS", "required": true }, { "code": "FI.SIES", "required": true }, { "code": "FI.SIWS", "required": true } ] }
2. Conditions for Approval Stage { "applicationType": "BUILDING_PLAN_SCRUTINY", "ServiceType": "NEW_CONSTRUCTION", "RiskType": "HIGH", "WFState": "PENDINGAPPROVAL", "conditions": [ "The development shall be undertaken strictly according to plans enclosed with necessary permission endorsement.", "The land in question must be in lawful ownership and peaceful possession of the applicant.", "The permission is valid for period of X(this is the validity period in years) years with effect from the date of issue.", "Permission accorded under the provision cannot be construed as evidence in respect of right title interest of the plot over which the plan is approved.", "Any dispute arising out of land record or in respect of right/ title/ interest after this approval the plan shall be treated automatically cancelled during the period of dispute.", "Adequate safety precaution shall be provided at all stages of construction for safe guarding the life of workers and any public hazard.", "The land/ Building shall be used exclusively for the above occupancy for which you applied and the uses shall not be changed to any other use without prior approval of this Authority.", "Adequate space mentioned in the approved plan shall be kept open for parking and no part of it will be built upon.", "The land over which construction is proposed is accessible by an approved means of access with sufficient road width." ] }
NocTypeMapping
Mapping of the NOC Types applicable for BPA ApplicationType, ServiceType and riskType
From the Example
AIRPORT_AUTHORITY, NOC_FIRE NOC’s are applicable for applicationType → BULDING_PLAN_SCRUTINY
serviceType-> NEW_CONSTRUCTION
riskType-> ALL ( Any )
NocTypes-> list out the NOC Type object
and NOC Applications get created when BPA is created by the NOC’s Workflow would be initiated when the BPA application Status is equl to the nocTriggerState configured. ( According to this example, when the application status changes to Citizen Approval Pending, all the NOc’s workflow would be initiated)
{ "applicationType": "BUILDING_PLAN_SCRUTINY", "serviceType": "NEW_CONSTRUCTION", "riskType": "ALL", "nocTriggerState": "CITIZEN_APPROVAL_INPROCESS", "nocTypes": [ { "type": "AIRPORT_AUTHORITY", "required": true }, { "type": "FIRE_NOC", "required": false } ] }
PDF Name
Description
Config’s
BPA Permit Order
PDF Generated for the Permit Order on approval of the BPA HIGH and MEDIUM RISK Applications
BPA LOW Permit Order
PDF Generated for the Permit Order on approval of the BPA LOW RISK Applications
Revocation Letter
PDF of the Revocation Letter Generated when the LOW RISK BPA Application is Rejected
Occupancy Certificate
PDF Germinated for the Occupancy Certificate on Approval of the Occupancy Certificate Application
PageComponent | MDMS Detail | Module Details Name | Master Detail Name |
EDCRForm | City list |
|
|
EDCRForm | City list |
|
|
DocsRequired | Documents required List |
|
|
BasicDetails | Risk Type |
|
|
OwnerDetails | Gender & Ownership category |
|
|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
PageComponent | MDMS Detail | Module Details Name | Master Detail Name |
StakeholderDocsRequired | List of documents required for registration |
|
|
LicenseType | License role options |
|
|
LicenseDetails | Gender |
|
|
StakeholderDocsRequired | Documents and its drop downs |
|
|
API
| Action id | Roles |
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
|
API
| Action id | Roles |
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
API
| Action id | Roles |
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
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.
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"
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.
