Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Procedure to integrate elastic search for Fuzzy search with any of the eGov modules.
Creating the index as per the requirement
The elastic index has to be used for fuzzy search due to performance enhancement and when PII fields are involved which cannot be accessed in DB directly to apply fuzzy logic.
When PII data are involved those fields shouldn’t be returned by the elastic search but only can be used to apply the filter. To enable this that particular field should be indexed but not stored.
eg -
In the above example, when data is posted, all the fields will be stored, but the index will never return the excluded source fields when searched.
Querying an index
This is a simple request, there are additional parameters that can be used to enhance the fuzzy search.
Elastic Integration with code
Add the elasticsearch host from the eGov cluster.
Divide the search params between the ones that will be sent to elastic and others to DB (search to elastic should be made only if the fuzzy fields are present in search request)
The result of the elastic search should be only the required primary-Id of the entity(property-id, trade license-id, etc..)
Then the resulting ids should be used in the normal search as it is.
Please refer to the following commit for the integration
Application Properties
Properties need to add for integration
The indices need to be reindexed for the fuzzy search to work if changes are done in the index. particularly in the case of protected fields being indexed but not to be returned in the search.
Reindexing for PT: Refer here.
The update feature in property services provides a facility to update the owner’s primary mobile number (referred to as ‘mobile number’ hereafter). The already existing update API is used with some enhancements to implement this feature. Also, a facility has been provided to add an alternate mobile number for every owner of the property. This can be done using the newly created addAlternateNumber API. The alternate number can also be updated using this API.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of Git
Prior knowledge of demand-based systems.
The following services should be up and running:
user MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
Enables the user to update the property owner’s mobile number and to add/update the alternate mobile number.
All the property information (except the owner’s mobile number/ alternate number) should be the same as the information from the search result. The owner’s primary mobile number has to be necessarily different from the existing one.
The Creation Reason in the property should be sent as an UPDATE for the request to be considered as an update request. Also, the property has to be in ACTIVE status. For adding/updating alternate numbers, modify the alternateMobileNumber field in the Property.
Sample request for updating primary mobile number or adding/updating alternate number.
Configs:
The update service belongs to the property service itself and provides the same ease of access for the functionality.
Pick a property id that is already created in the system.
call the property/update API by changing the owner’s mobile number.
Steps to Integration (updating alternate number):
Pick a property id that is already created in the system.
call the property/addAlternateNumber API by adding/changing the owner’s alternate number.
Service configuration details
One of the major applications of the eGov stack which helps municipal and citizens to handle property tax payments and other related functions on the property such as assessments, mutation, and so on.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of the demand-based systems.
Following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
The Property Service provides multiple functionalities starting from serving as a central repository where property information is registered for reference of citizens and other municipality-provided services such as water connection and sewerage management. An assessment can be done so as to calculate and pay tax on the property. The different services provided by the property services are
Property Registry
Assessment
Mutation
Bifurcation
Consolidation
Registry Explanation
The registry flow helps the citizen/Employee to create a property in the system with the minimal information required.
Other workflows such as assessment or mutation can be triggered on the existing ACTIVE Property in the registry.
The property can be created, updated, cancelled, searched, Followed by the process of Mutation and Assessment.
The same entry in the registry can be referred by other modules for their business purposes(Water charges).
Persister File Config
Workflow-configs
Each flow in property has a workflow associated with it, which can be controlled by the following configs
The Boolean field which can enable/disable Workflow - same field controls the update and create the workflow
Workflow Config for property create if the source is from WATER CONNECTION module
For use case 1 which says, The property which is creating from Water and sewerage module should have one step workflow. for this requirement in the above MDMS file businessService with PT.CREATEWITHWNS object must have enabled the field to set as true. Then for all the property creation from Water and Sewerage module would have one step workflow and property would be created with an ACTIVE state.
Fields in the above MDMS file
Sample workflow config for use case 1 where property creation is from water and sewerage module with one step workflow
Sample workflow config - (The same PT.CREATE can be used for update workflow also since both involve the same functionality)
PT.LEGACY workflow config
Notifications :
To enable or disable notifcation notif.sms.enabled=true
#notif urls - makes use of the UI app host in notification service egov.notif.commonpay = citizen/egov-common/pay?consumerCode={CONSUMERCODE}&tenantId={TENANTID} egov.notif.view.property = citizen/property-tax/my-properties/property/{PROPERTYID}/{TENANTID} egov.notif.view.mutation = citizen/pt-mutation/search-preview?applicationNumber={APPID}&tenantId={TENANTID}
The current localization messages for notification
Configs in App.props
Property service can be integrated with any organization or system that wants to maintain a record of the property and collect taxes with ease.
Easy to create and simple process of self-assessment to avoid the hassle.
Helps maintain property data which can be used in the integration of other essential services like asset management, water connection and so on.
provides additional functionalities like mutation, and assessment of properties.
Customers can create a property using the /property/_create
Search the property using /property/_searchendpoint
/property/_update endpoint to update the property demand as per need.
Mutation can be carried out with the help of /property/_update itself, no extra API is needed.
Doc Links
API LIST
For overview Please refer to the parent file - Property Services
The assessment set of services inside the property module is used for assessing the value of a property in a given time frame and collect taxes for the same. Assessment is a snapshot of Property for a given transaction on that Property. These APIs provide functionalities to create/update/search the assessments. An assessment cannot exist without property.
MDMS CONFIG:https://github.com/egovernments/egov-mdms-data/tree/DEV/data/pb/PropertyTaxTo show a preview of this link, connect your Github account.GithubConnect
Configs
Assessment shares most of the configs with Property as mentioned above, only exclusive properties are mentioned in this section.
PERSISTER CONFIG: https://raw.githubusercontent.com/egovernments/configs/master/egov-persister/assessment-persister.yml?token=AE4Z2KFWEQBDCUY6AZLGGIK6AM3QQ``
Workflow Config
The first property switches workflow on or off, while the second property provides a way to control which field change can trigger the workflow. A businessService needs to be created using the workflow /egov-workflow-v2/egov-wf/businessservice/_create API.
Sample businessService create API body for Assessment workflow:
Other system-level configs are the same as PT-Registry as mentioned above.
Notification Configs
Payment Notification
For adding localization for any status append ASMT_ prefix to the status and for adding a message for any status add ASMT_MSG_ before the status.
Assessment ****(Property Calculator) -
The calculator service Prepares and property tax and files the demand in the billing service for payment. It has the ‘estimate’ API to give the estimated property tax without persisting data and a calculated API to create demand for payments.
The calculator service PT Calculator
Assessment integration helps citizens to assess their property with ease and helps them verify their tax values by themselves which gives more control to the citizens and hep the municipality collect taxes with ease.
Easy to create and simple process of self-assessment to avoid the hassle.
Integrated payment for multiple years enables by digit platform.
Customer can create an assessment on a given property using the /assessment/_create
Search the assessment and its workflow status by using /assessment/_searchendpoint
/assessment/_update endpoint to update the assessment and its workflow states as per need.
please refer to the property document Property Services | Doc-Links
API LIST
Objective: The feature allows users to edit the application already created or update the property already registered to their mobile number. After verification, employees can send the application back to the citizen with remarks on required changes. The edit and update feature allows the users to make these changes. It also allows the user to update the details of the property details online as required.
If the property is marked as Send Back to Citizen, the application details page for employees displays the edit option at the bottom of the page.
If the property is marked as Verify → Forward → Approved, the Property Details page for the employees displays the Update option at the bottom of the page.
Clicking on the Update button allows users to edit or update property details. The Create Property flow is revisited. The only exception here is the values are pre-populated from the Property object received from Property Search API. On completing the flow the Update API is called and the property is updated successfully.
The main code contains the functions that transform the property object received in Search API. This includes primarily the Assessment flow units contextualized as per the Create flow since users have to revisit the Create flow with pre-populated details. The data values are updated accordingly. It also contains the routing details for the pages in the Create flow.
The Localization keys for Edit or Update Property are added to the ‘rainmaker-pt’ locale module. Changing, updating, or adding any new localization key is done in the same locale module.
Objective: To provide user facilities to add a new property, view the property details and the application currently on their number. The feature allows users to update the property or edit the application.
Users can add new property using the Create Property button. The workflow captures user inputs through multiple questions and information gathering screens. At the end of the flow, a check page is displayed that enables the user to cross verify the information entered. The application is created on clicking the submit button.
Property tax registration information screen is displayed after login. This helps the user identify the required documents to complete the new registration for the property.
The users are prompted to enter the details about the property first. The flow chart below illustrates the property details flow.
The user is next asked to provide the assessment details. This flow captures information related to each floor and the basement.
Instead of capturing unit data in separate pages the system captures data in one page only. Users can add multiple units by clicking on the Add One More Unit button. The respective unit page loads for each floor and users can add the corresponding units as required.
After entering property details, the user is prompted to provide the address of the property. The flow is straightforward, without any conditional routing.
Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, is auto-populated.
Finally, the user is prompted to enter the property owner details. Ownership can be institutional - either Government or Private. Ownership can also be Single or Multiple owners. The system prompts the user to fill in the details accordingly.
In the case of Institutional, the following data is asked in the first screen. The subsequent screen does not change.
In the case of single or multiple owners the following screen is displayed. The rest of the flow remains the same.
The check page allows users to cross-verify the information furnished across the flows. Users can click on the change button available adjacent to the relevant data to make any change or update the input data. The user is redirected to the relevant page for updates. The subsequent flows are repeated till the user submits the application.
The Create API is called for registration of property. Following is the snippet of the Create API used: 1create: "/property-services/property/_create"
If the API response is successful, then the acknowledgement screen is displayed, else the failed acknowledgement screen is displayed.
All the screens have been developed using the new-UI structure followed previously in the FSM and PGR module.
The link for the Create Property main index is given below. This provides a better understanding of the starting point of the flow:
PT (Property Tax) Module has been segregated into a specified structure. All the screens configuration is available inside the PageComponent Folder. The configuration for routing the pages are mentioned in the config folder common for both citizens and employees. The snippet for the folder structure and routing configuration is given below.
The high-level configuration for controlling the whole flow for citizens and employees is available in the Pages folder. Citizen flows include Create, Edit, My Properties, My Application and Search Property. The search property flow carries the index (the main starting point of the whole flow).
The Utils folder basically contains all the methods used across the PT module. In case there is a common method that needs to be added, it can be imported into other files.
For creating an application the Create API from Property Tax is called using the React hooks. This hook is declared under hooks or elements of PT as PTService.
Data across some of the pages are imported from MDMS throughout the flows. The table below lists the pages using MDMS data. In these pages the .js files are found under page components.
Data React hooks are used to call MDMS and these are shared across the module. The code snippet below contains the call used for MDMS.
Localization keys are added to the ‘rainmaker-pt’ locale module. In future, if any new labels are implemented in the Property Tax (Citizen) they should also be pushed to the locale DB under rainmaker-pt locale module. Below is an example of few locale labels.
Objective: Common PT is used as a plugin for other modules to search or create a lightweight property data on the go and tag it to the requesting module.
CommonPT module provides two ways to search for a property. Users can search for a property either by Property Id or by Door Number.
Search By Property ID
The search by Property ID requires certain parameters to filter out required properties.
City Name (Drop Down)
Owner Mobile Number (Input Field)
Property Id (Input Field)
Old Property Id (Input Field)
where City Name is mandatory and at least one more parameter like Mobile Number, Property Id or Old Property Id must be provided to find properties.
Search By Door Number
The search by Door Number form requires certain parameters to filter out required properties
City Name (Drop Down)
Locality (Drop Down)
Door Number (Input Field)
Consumer Name(Input Field)
Where City Name and Locality are mandatory at least one more parameter like Door Number or Consumer Name is required to find properties.
Once the user enters all required details, the form redirects the user to the list of all properties registered with the property id or as per the search parameters entered by the user
Clicking on the Select button redirects users to the OTP verification page. Users must enter the OTP sent on their mobile number to proceed further.
Users are redirected to the Property Details pages where the user can create new property using the existing property ID.
Clicking on Create New Property button, redirects users to create a new property page form. Users can enter the property details to be registered.
After filling in all details users can submit. The Acknowledgment page displays the application status as either Success or Failed along with the application number.
Common PT search and create feature is integrated with the TL (Trade License) module. The two flows of common PT allow users to:
Select the desired property using property search facility. The user can select the property from the search results.
Create a new lightweight property during the trade license application process. Once the acknowledgement page is displayed, the Proceed button is enabled to move forward with the flow.
Once the property is selected/created, property details is available on the next page Property Details.
Clicking on the View More Details button redirects users to the view property page that offers an overview detail of the attached property.
Common PT implementation code link:
The Update Mobile Number feature in PT
Reminds ULB users about any invalid mobile numbers that exist in the owner records and enables them to update these.
Enables ULB users to update the mobile numbers as per requests from the property owner(s).
Enables property owner(s) to update the mobile number in their record to log in to the system.
If the mobile number is invalid it throws a warning in the property info screen whenever the user tries to pay the dues.
Mobile Number is invalid if it doesn't match the pattern defined in the MDMS config and if the number equals to the invalid number.
The Update number popup for employees requires a few documents to be uploaded. Citizens must provide the OTP received on the new number to update details.
Citizens must provide the OTP received on the new number to update details.
Update number component related files are present in the egov-ui-kit packages available in the link below.
Update API is used to update the property mobile number
property-services/property/_update
To update the number, just update the owner.mobileNumber
To update alternate number the API used is
property-services/property/_addAlternateNumber
Update owner.alternatemobilenumber
Click on the Edit Existing Number. A popup appears to update the number.
Enter the new number that needs to be added. Click on Send OTP.
UI makes an API call to user-otp/v1/_send with type as login to send the otp if it is registered.
In case the OTP fails then type register in the same API to create a new user.
Once the OTP is entered, it verifies and validates the user in both cases (in case of register the citizen gets registered).
Once the OTP is validated, the Property Update call is triggered to update the number in the property object.
Note: Employee users have to upload supporting documents and the property update API call is triggered directly. Steps 3,4, and 5 are skipped.
PT Alternate Number feature enables owners to add an alternate number for the property.
We can add an alternate number while creating the property. The system also provides the option to add an alternate number after making a payment.
Alternate Number component details link
Steps To Add Alternate Number
Click on Add Alternate Number. A popup opens to add the alternate number.
The system sends an OTP to the registered number.
Once the user enters the OTP, the system validates it.
Enter the new number that needs to be added. Click on the Send OTP button.
UI makes an API call to user-otp/v1/_send with type as login to send the OTP if it is registered.
If it fails then type register in the same API to create a new user.
Once the OTP is entered, it verifies and validates the user in both cases (in case of register the citizen gets registered).
Once the OTP is validated, the Property Update call is triggered to add the alternate number in the property object.
Step 1
Get the current mapping of the pt index using the _mapping API
Step 2
Add the following json mappings in the existing mappings (parallel to properties key):
Sample QA final mapping for reference is attached at the end.
Step 3
Recreate property-services-enriched with the new mapping.
Step 4
Update the indexer configuration, add the following 3 fields ownerNames, doorNo, street in custom mapping as added below in sample configuration:
** If search has to be enabled only on names of only ACTIVE user, configure indexer jsonPath accordingly. Use $.owners[*][?(@.status=='ACTIVE')].name instead in the config
Step 5
Restart indexer
Step 6
Trigger reindexing
Recreated property-services-enriched index with the new mapping
Created kafka connector
Hit the legacy index api
Once data is indexed in property-services-enriched, verify that all the data is indexed
After validating the data, drop the property-services index and use alias to point property-services to property-services-enriched
Sample mappings from QA env:
Reference Docs: - For additional details please refer to the property document
MDMS CONFIG:
The persister File config for property services can be found in the Config repo of eGov Git, which needs to be added in the persister service -
| name | value | description |
|---|
For the creation of property from the water and sewerage module, as per the use case mentioned in this , a different workflow config is used. For each use case, to identify which workflow to use can be identified from this .
Note: The above objects indicate each use case mentioned in this , so at a time only one object (use case) enable field must set as true
| Title | Link |
|---|
| Title | Link |
|---|
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
to access the Edit/Update property main index.
Update Util function: this function does the exact opposite of the Create util function (refer to ). The property object received from the Property Search API is converted to the Create Flow relevant structure to pre-populate the values for user convenience. The application is updated on completing the flow. The link for the same .
MDMS data used here is the same as the Create flow since the flow structure used for edit/update property is the same as the create property flow. Please refer to the .
All content on this page by is licensed under a .
After completing the flow users can download the acknowledgement details of the property created in pdf format. Click the config for the PDF generation.
| PageComponent | MDMS Detail | Module Detail Name | Master Detail Name |
|---|
| Link | Description |
|---|
All content on this page by is licensed under a .
All content on this page by is licensed under a .
Title
Link
/assessment/_create
/assessment/_update
/assessment/_search
API | Roles | Action Id |
/access/v1/actions/mdms/_get | CITIZEN | 870 |
/egov-mdms-service/v1/_search | CITIZEN | 954 |
/localization/messages/v1/_search | CITIZEN | 1531 |
/property-services/property/_create | CITIZEN | 1895 |
/property-services/property/_search | CITIZEN | 1897 |
/property-services/property/_update | CITIZEN | 1896 |
/property-services/assessment/_search | CITIZEN |
|
/billing-service/bill/v2/_fetchbill | CITIZEN |
|
PropertyTax | List of documents required for each category |
|
|
PropertyUsageType | Four category imported - (Commercial, industrial, institutional & others) |
|
|
PropertyType | three major categories - (Independent, Flat & Part of the building & Vacant) |
|
|
SubUsageType | List of sub-usage category according to the property usage selected before |
|
|
SubUsageTypeOfRentedArea | List of sub-usage category according to the property usage category selected before, same as sub-usage type |
|
|
PTSelectAddress | List of Cities (Amritsar, Jalandhar and Nawanshahr) and List of localities according to the city selected |
|
|
OwnershipDetails | Four categories imported - (Institutional - private, Institutional - Government, Single Owner and multiple Owner) |
|
|
SpecialOwnerCategory | List of special category imported eg Freedomfighter, handicap etc |
|
|
PTGeolocation | Default value for location i.e Pratap Nagar Latitude and longitude |
|
|
RentalDetails | Rentaldetails information regarding tax percentage is taken from MDMS |
|
|
API | Action Id | Roles |
/access/v1/actions/mdms/_get | 870 | CITIZEN |
/egov-mdms-service/v1/_search | 954 | CITIZEN |
/localization/messages/v1/_search | 1531 | CITIZEN |
/property-services/property/_create | 1895 | CITIZEN |
/property-services/property/_search | 1897 | CITIZEN |
/property-services/property/_update | 1896 | CITIZEN |
/property-services/assessment/_search | CITIZEN |
/billing-service/bill/v2/_fetchbill | CITIZEN |
name | value | description |
kafka update topic | update-property-registry |
|
API | ACTION ID | ROLES |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
API | Action Id | Roles |
1 |
| 870 |
|
2 |
| 954 |
|
3 |
| 1531 |
|
4 | /property-services/property/_search | 1897 |
|
MDMS Fields | Description |
businessService | Name of workflow config |
initialAction | Indicate the start(initial) action of the particular workflow mention in businessService. |
inWorkflowStatusAllowed | This field indicate whether the property with application status as “inWorkflow” can be use with water and sewerage connection creation. If this field is true then for that particular use case, the property with “inWorkflow” status can be use with water and sewerage connection creation and vice versa |
enable | If this filed is set as true, then the other fields associate with the particular object is use for property creation. |
name | value |
egov.idgen.ack.format | PB-AC-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ACK] |
egov.idgen.mutation.format | PB-MT-[CITY]-[SEQ_EG_PT_MUTATION] |
egov.idgen.assm.format | PB-AS-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ASSM] |
egov.idgen.ptid.format | PB-PT-[cy:yyyy-MM-dd]-[SEQ_EG_PT_PTID] |
citizen.allowed.search.params | accountId,ids,propertyDetailids,mobileNumber,oldpropertyids |
employee.allowed.search.params | accountId,ids,propertyDetailids,mobileNumber,oldpropertyids |
name
value
description
assessment id format
PB-AS-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ASSM]
kafka create assessment topic
save-pt-assessment
kafka update assesmsent topic
update-pt-assessment
assessment.workflow.enabled
true/false
Workflow integration can be controlled by the following two properties
assessment.workflow.trigger.param
usageCategory,occupancyType,occupancyDate
Property applications |
Registered properties |
Application details |
Property information |
Edit or update property details |
Make payment or search property details |
is.workflow.enabled | true/false | enable disbale workflow |
PT.CREATE | the name should match the config name in the workflow businessservice JSON |
PT.LEGACY |
PT.UPDATE |
USER Service |
url-shortening |
MDMS |
Billing-service |
Location |
Workflow |
Persister | **** |
Localization |
Id-Gen service |
/Property/_create |
/Property/_update |
/property/_search |
PT-Calculator Service is used for creating demands based on property assessments, mutations, and updating demands with the penalty, interest in case of payment delay.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
PSQL server is running and a database is created to store property/application data
Following services should be up and running:
MDMS
property-services
billing-service
Calculate property tax, mutation fee based on billing slab.
create and update demand.
Deploy the latest version of property service and pt-calculator
Criteria:
Property Type
Property Subtype
Usage Category Major
Usage Category Minor
Usage Category Subminor
Usage Category Detail
Ownership Category
Sub Ownership Category
Plot Size
Floor Number
Area Type
The combination of the above variables can be used to define a billing slab. The billing slabs are stored in db in the table named “eg_pt_billingslab_v2”. To perform CRUD operations on the billing slabs API’s are provided in the module. Following is a sample create request:
The ‘ALL' keyword can be used if the slab is independent of that particular variable. If ‘fromPlotSize’ or ‘toPlotSize’ values are null they will set to positive infinity and negative infinity, a similar process will be for ‘fromFloor’ and 'toFloor’ values.
The estimation service class loops through all the units and calculates the tax based on the applicable billing slab. The exemptions are calculated using master data in MDMS Service. Each tax or exemption is added to the tax head estimate. Following are the exemptions and taxes that are calculated:
Property Base Tax
Owner Exemption
Unit Exemption
Penalty
Rebate
Interest
Fire Cess
Cancer Cess
From the above charges and exemptions penalty, interest and rebate are time-based. Rebate is given if the payment is done before the rebate deadline date specified in Rebate master data. Similarly, the penalty is charged if payment is not done before the deadline to pay tax. After the deadline to pay tax is passed daily interest is charged according to the rate defined in the master.
Property tax is calculated by adding the tax for each unit calculated using the billing slab for that unit. The formula for calculating tax for the unit is:
In case the unit is commercial and rented the formula is as follows:
ARV stands for Annual rent value.
If the property contains ground units (i.e unit with floor number = 0) then tax is also calculated for the unbuilt area. The formula for calculating the tax on the unbuilt area is as follows:
Below is a sample of master data JSON for interest :
If the given year rate is not defined the service will recursively fall back on the previous year until it finds a defined rate slab. The time for which interest is applicable is calculated by subtracting the epoch value of starting day (At 00:00 AM) from the end of the day (23:59 PM) epoch value of the current date. In the case of partial payment, the interest is calculated for each interval between payments and summed as the applicable amount for interest won’t be constant throughout.
If the fraction is greater than equal to 0.5 the number is round up else it’s round down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101
The following is the format of penalty master data:
If the time during the demand creation date is greater than the penalty starting day, a penalty of x% will be applied. The x% is defined in the rate field. The penalty also provides a fallback for master data i.e if for a particular year entry is not present it will recursively search for the previous year and apply that rate.
Depending on the owner type of user flat amount or percentage of tax amount is given as exemption. In the case of multiple owners, the exemption is calculated for each owner and summed. Following is a sample master data:
Once the property is sent to the calculator its tax estimates are calculated. Using these tax head estimates demand details are created. For every tax head, the estimate-demand function will create a corresponding demand detail.
Whenever _calculate API is called demand is first searched based on the property id and the demand from and to period. If demand already exists the same demand is updated else new demand is generated with consumer code as property and demand from and to a period equal to financial year start and end period. In the case of Reassessment, the demand is always updated for the given year.
In case of update, if the tax head estimates changes, the difference in amount for that tax head is added as new demand detail. For example, if the initial demand has one demand detail with PT_TAX equal to 100
After updating if the PT_TAX increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:
RoundOff is bill-based i.e every time bill is generated round-off is adjusted so that the payable amount is the whole number. Individual PT_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all PT_ROUNDOFF will always be less than 0.5.
If demand is created and the total tax is supposed 100.40, then a negative round-off amount of -0.40 is added so that the tax becomes 100. If during reassessment the tax changes and becomes 111.70, to round it off estimate will give tax head estimate of +0.3. The demand generation logic will add a new demand detail by taking the difference in the old and new tax amount for that tax head. Therefore a new demand detail of 0.3-(-0.4)=0.7 will be added. There will be now two PT_ROUNDOFF tax heads one with an amount -0.4 and the other with 0.7 making the total round-off amount (-0.4+0.7)= 0.3 which with the tax amount of 111.70 will give a bill amount of 111.70+0.3=112.
PT-calculator should be integrated with property-services which internally invokes the calculator service to calculate and generate demand for the charges.
Carries out the process of creating demand and updating them on a need basis as per the requirement of assessment and mutation.
/_caluclate should be exposed internally for property-services integration.
/_estimate API should be exposed for UI integration, which enables users to view the estimate before proceeding.
/demand/_update API should be configured in billing service for demand update function on bill expiry.
Property-services Property Services
API Collection - https://www.getpostman.com/collections/d7c858f62b53d17c4335
Ownership Transfer Technical documentation
The mutation service provides a facility to change ownership of a property in relation to sales, and inheritance of property. it helps by providing a workflow on config and allows the municipality to collect payment with ease on approval of the process. The mutation flows ad APIs exist within the property-services code base and makes use of all the mentioned external services and configured values, in addition to those the rest can be used to control mutation flow.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of demand-based systems.
The following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
Enables the user to create a mutation and transfer the ownership to the new owner.
Workflow config:
In Addition to property information and the extra owner information being added, some other information is required for workflow
The Creation Reason in the property should be sent as MUTATION for the request to be considered as a mutation request.
Along with the workflow name for mutation, a few extra details have to be provided in the additional details field of the property. Also either a new owner has to be added or an existing one has to be set to inactive for a valid mutation request.
The business workflow config follows the structure given for property workflow with respective name changes.
Workflow sample config for Mutation.
The property services will make a call to the mutation calculator at the required interval during the mutation flow.
The mutation service belongs to the property service itself and provides the same ease of access for the functionality.
Pick a property id that is already created in the system.
call the property/update API by changing the owner information or adding new owner information.
workflow information must be added mandatorily before submitting the request.
The calculation logic for mutation fee depends on the usage type of property (RESIDENTIAL, NON-RESIDENTIAL, etc ) and the current market value of the property.
If the current market value (CMV) of the property comes in between the minimum and maximum market value range of billing slab and the usage type of property match with the usage type for that billing slab then the mutation fees for that property is the amount mentioned in that particular billing slab.
Further, there are two calculation types which are FLAT and RATE which have to set by state/ULB for their billing slab for property mutation. If the calculation type is set as FLAT then mutation fee is the fixed amount mentioned in the billing slab which is used for the property.
If the calculation type is set as RATE the Mutation fee is X% of the current market value, where X is the percentage rate mentioned in the billing slab which is used for the property.
Other factors influencing calculation can be :
Ownership type
Property type
Locality
When the property is registered for mutation/transfer of ownership and all the document is submitted, then the mutation fees have to pay within a specified period of time of the property mutation registration date. If a person fails to pay the amount of the fee before the deadline date, then some penalty charges have to pay. The penalty charge is Y% of the tax amount. The penalty percentage is set by the state/ULB. If a person pays the amount of the fees within the specified month of the property mutation registration date, then a certain amount is rebated from the tax amount. The rebate charge is Z% of the tax amount. The rebate percentage is set by state/ULB.
Note: For mutation fee calculation, document date value (means the date at which property is registered for mutation), market value of property, and usage type value of the property is essential.
Please refer to the parent for external services: Property Services | Doc-Links
Backend technical documentation
This document highlights the changes that need to be done in a Property module to support the privacy feature.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
MDMS Service
Encryption Service
The Security Policy MDMS file must have the model configuration for fields to be encrypted/decrypted. The following models have been used for W&S in SecurityPolicy.json file:
Next, add the following (if not already there) under roleBasedDecryptionPolicy of User model (already existing):
Refer to the SecurityPolicy.json file for full reference.
For modules, there is no such hard rule or pattern for naming the model, but it should be related to that service. ex: 1.) For user service we have two security policy models User which is used when a user tries to search other user data and he/she will get the PII data in masked, plain or encrypted form depending on the visibility sets for an attribute in the MDMS. And another model is UserSelf which is used when a user tries to search their own data, they get the data as per the configuration set there. For report and searcher config the model name should be similar to the value that we are setting in the field decryptionPathId. ex:- Employee Report. Employee Report Security Model
2.) For Property we have a model Property which is for Address fields like street, doorNo, landmark encryption and decryption.
For an attribute where its firstLevelVisibility is set as "Masked" and whenever the respective search API is called without the plain Access Request then in the API response for that attribute we will get the masked value for ex:- if for mobile number attribute’s firstLevelVisibility is masked and its plain value is 9089243280 then in response, we will get value as ******3280 and the masking pattern is defined in the MaskingPattern MDMS file and the pattern is picked up based on patternId. Similarly, if firstLevelVisibility is set as "ENCRYPTED" we will get the encrypted value of that plain data (which is present in DB) in the response.
NOTE: For adding of new attribute for encryption, the following things need to be kept in mind:
We do not have a direct approach to it, but a workaround is as follows:
We need to make sure which property has to be encrypted and what is the path of the property in the Request/Response object of Property. We can add a new property to the existing model Property.
The inclusion of any new attribute here would need encryption of the old data for this new property.
For that, in MDMS, we will have to replace the existing model attributes with only new attributes and hit the _encryptOldData API. Once old data encryption is done, we can put back all the required attributes (old and +new) in the model.
Also, before starting the encryption of old data, we will have to check the latest record of the table eg_pt_enc_audit. If the latest record has offset and record count value other than 0 then insert a random record with offset and record count as 0 and createdtime and encryptiontime as a current timestamp in millis in utc.
For further info about adding models refer here
Upgrade services-common library version.
Upgrade the tracer library version.
Add enc-client library
In property-services encryption and decryption endpoints should be declared as follows:
Now, update the following existing property in application-properties:
property.es.index=pt-fuzzy-search-index
We need an interfacing file for handling the encryption and decryption of attributes and for interacting with enc-client library directly.
For reference follow the below code snippet
You may find the file here in the repo.
UnmaskingUtil.java:
UnmaskingUtil.java file helps in extracting the plain data of the owner from the user service.
For reference follow the below code snippet
You may find the file here in the repo.
If you want to get all the PII data in the plain format then in the search request add the search param “isSearchInternal“ as “true”
If the user wants only specific fields to be unmasked then add the plainAccessRequest in the RequestBody in the following format:
plainAccessRequest contains :
recordId which will take the uuid of the user as an input for which PII data has to be unmasked, and
plainRequestFields will take an array of attributes that need to be unmasked. These attributes should comply with the attributes used in the Mdms SecurityPolicy.json’s models created.
Before using the privacy feature in any environment the encryption of existing data in the dB should be done.
An API for the same is written in the service and needs to be triggered by port-forwarding the respective service pod.
The data encryption API uses the existing plainSearch method and the encryption shall take place tenantId-wise. If tenantId is not specified then all the tenants are picked from the MDMS repository and the encryption happens for all the tenants. However, if the tenantId is specified, then the encryption happens only for that tenantId.
The following method is added to execute the oldDataEncryption
In PropertyController.java
In PropertyEncryptionService.java This service is solely for old data encryption and can be referred from here: PropertyEncryptionService.java
A new persister file needs to be added for keeping track of the progress of oldDataEncryption. Refer to this pt-enc-audit-persister.yml for the same.
Here is the Postman collection for all property, water and sewerage services for old Data encryption : https://www.getpostman.com/collections/b3858ec2020462a6407d
There is no need to re-indexing the base indexes(viz. property-services) once the API for old data encryption is executed as this will happen during the API execution itself. For any new data getting created, the new data will get saved in the encrypted format only in the indexes.
When talking about privacy changes, we would need 2 additional indexes to be added. both of them would be the copy of existing indexes. 1. A fuzzy index: Copy of index config under existing save topic
To enable or disable decryption in privacy, we need to make changes to only the privacy variable present in the environment file in DevOps. For enabling, its value should be “true” else “false”.
For property-services:
For user-service:
The variable can be found in the file here.
Note: Privacy decryption means: For any new application creation/ old application updation Internal data will be stored in the encrypted form itself, just that during decryption disabled it would give PLAIN text rather than masked one.
All the above changes need to be done for sw-services as well.
For detailed steps to configure the above changes refer to the document: Detailed Steps to configure privacy in Property module.
Migrating legacy data
This section covers the principles eGov will be following for migrating legacy property registry along with demand and collection balances to the DIGIT system (currently in Uttarakhand but can be used for other clients in future). eGov has been successful in implementing property tax applications in states of Andhra Pradesh, Punjab and various other Municipal Corporations like Greater Chennai, Nagpur and so on using best practices defined here.
The state team is supposed to take care of the below activities before property data is shared to eGov for data migration:
State team to share all master data and its localization that are part of the property tax. For example masters like - city, boundary, usage type, property type and so on
State team to do the data gathering and prepare the property tax data in the predefined template shared by eGov
Data prepared needs to be scrutinised by the data owner from the State’s team. Following data validations to be considered in particular:
Validate if all sheets have accurate records (owner details, property details and DCB details, Floor details) in terms of what is expected
DCB details can be more than the number of records in the property sheet
There can be multiple owners for a single property. But there needs to be an owner and DCB for each of the properties
Have a check on all mandatory data present
All sheets to be aligned with the unique id field
The state has to share the complete set of property data for a city in a single go. They can also give one set for residential properties and another for commercial properties, but cannot give multiple sets for the same.
Data owner to give a sign off on data before handing over to eGov team
State team to be aware of assumptions and default values that will be applied as part of the data migration process. This will be shared by the eGov team
UAT and production environment where the data is to be loaded to be provisioned and set up
Data received from the State team will be cleansed by eGov with default values
Mandatory fields that have no financial impact on citizens can be filled with default values in the absence of values specified by the State team. Few examples are listed below -
Covered areas can be updated as 0
Road type as 12 meters
The number of floors can be updated as 1
Certain fields that have a financial impact can also have default values like tax amount in the absence of values specified by the State team. (It can be updated as Rs.1)
If the mobile number is blank, a dummy mobile number will be updated. Care will be taken to ensure that this is not an actual mobile number and this number will be removed from notifications. Dummy numbers can be something like 99999xxxxx where the first few dummy numbers in a state will be 9999900001, 9999900002, 9999900003 so on.
Follow the below assumptions to do data cleaning
If the mobile number and user name combinations are duplicating we will consider these properties belong to the same owner. This means one user will be created in the system which will have a link to two properties.
Have a marker if any assumptions and default values are applied on a record
Certain data are currently not assumed or defaulted. Below listed are a few cases -
Owner details completely not available for a property - If complete owner details are missing, these records to be kept in the not to be migrated list.
If DCB is not there or given for a range of years - since there are a lot of use cases here, we can keep this record in the not to be migrated list
Duplicate old property id - leave the data as it is and then edit it later using the data entry screen
If boundary data is not present or data not aligned with the master data shared - update to a default mohalla which the state agrees to
Door number is not present - update the value as “door number”
Owner Name blank in the owner details sheet - update the value as “owner”.
Load the records using property migration kit to UAT server
Prepare a list of all passed and failed property records and share them back with the State team. Passed records along with values defaulted will be shared.
If the State team wants eGov to retry all failed records they are expected to come back with the revised data within one week.
Repeat Step 1 for revised records received from the State team.
The final status of the data load will be shared with the State team.
State team to verify data loaded on UAT server and provide a sign off for each of the ULBs within 1 week
On getting sign-off of UAT data, eGov will load that data to production using the migration kit used for loading to UAT instances. This can be done only if the production infrastructure is ready.
Get sign off on the production data before the application can be made live.
Communication for data migration exercise can be split into the following stages:
There will be a SPOC from the State team who is the data owner who will share data with the eGov team. Excel sheet data will be put on google drive and shared with the project manager from eGov. Similarly, all communications from the eGov side to State will be routed through the project manager.
Pre-migration
A demo of how PT module works - State + ULBs
Product fitment discussion, configurable data finalization and sign off - State
An overview of how data migration works - State + ULBs
Sharing the template (along with checklists and FAQs) in which we will collect data and type of data required against each field along with training - State + ULBs
Sharing assumptions which will be followed while migrating data - State + ULBs
During migration
Data inconsistencies observed in Data cleaning stage - State
Gaps needed to complete data migration (like mohalla mapping) - State
List of records which will be migrated as-is and the ones which will be migrated with assumptions - State
Post-migration
List of properties migrated without error - State
List of properties migrated with error for ULBs manual entry - State
UAT Sign-off document - State + ULB
Final confirmation post migration on Production - State + ULB
All failed records from the second pass will be manually entered into the system using data entry screens
The state has to make a mandate to collect property tax only using DIGIT.
All records with assumption markers or incorrect data can be updated by counter employees when citizens come for payment. Maybe this option can be given to the citizen when coming for online payment.
When a citizen is coming for making his payment, the counter operator can check if their property exists in the system using propertyid or mobile number. If it is found to be missing, it can be captured afresh in the system using the data entry option. All required information can be obtained from the citizen, either from previous year receipts that they carry or directly asking them.
With this approach, a ULB can go live with 90% of property data within a short time.
Data Migration Checklist
Data provided in the standard template attached only will be accepted for further analysis and process.
Data provided into the template is loaded into staging tables and then validation and data clean-up is done.
Properties with current Tax 0. (2020-21)
Properties with advance collection
Properties with current tax partially payment
Properties with Mohalla not configured in master
Masters mapping with the configured masters data in the system.
All the findings of data are reported to the onsite team and sought clarification.
Once all the queries/ findings are cleared/addressed data is moved into UAT.
Data is verified into UAT with sampling by the state team. Go ahead.
Preparing some basic checkpoints before moving into production.
Move the data into production and verify the checkpoints.
Bill details and payer details
Objective: The Search and Pay feature enables the user to search the property (with or without login) and pay any pending dues. It provides the user with the option to load all the bills linked to the registered mobile number and pay the bill.
Users can search for Property with or without login. Property can be searched either using Property Id or using property details.
Once the user provides certain parameters it calls the search property API and displays the search results accordingly.
Clicking on the View Details button redirects the user to the bill details page. The users can pay the dues from this page.
Users can view the break-up of the total amount due and select full or partial payment as required. They can enter the amount to be paid in case the partial payment option is selected.
Clicking on the Proceed To Pay button redirects the users to the Payer’s Details page.
For Logged In Users, the below information is captured.
I am making the payment as the owner/ consumer of the service.
I am making the payment on the behalf of the owner/ consumer of the service.
In case of option (i) is selected, the owner’s detail is linked with the receipt.
In case option (ii) is selected, the user’s profile detail is linked with the receipt.
For without login users, the below information is captured.
I am making the payment as the owner/ consumer of the service.
I am making the payment on the behalf of the owner/ consumer of the service.
In case of option (i) is selected, the owner’s detail is linked with the receipt.
In case option (ii) is selected, the user is asked to enter the Name and Mobile No. and the same is linked with the receipt.
Based on the selected option the user is redirected to the total amount page. The flow is same as DIGIT Payments from this screen.
The payer information for the payments API is added based on the mentioned criteria.
Objective: Users can look for the list of the properties registered for their mobile number in My Properties tab.
The initial view for each property offers the Property Id, Owner Name, Address and status, along with the View Details button. Users can click on this button to look up more details about the registered property. In case the users do not find the property they are looking for, they can click on the Click here to Register New Property option to register the property.
Clicking on the View Details button displays the Property Information page containing the necessary information about the property.
Click here to fetch the working code for the My Properties and Property Details common Index.
The template for My properties and Property Information page is present inside pt/pages/citizen/MyProperties. The list of properties is retrieved by calling the search API /property-services/property/_search.
This API is called using the React hook present inside the index of My Properties and Property information page. A single property is loaded, bypassing the unique Property Id in the search API.
If the search API result is successful, Assessment Search API is called to know the assessment status. Assessment Search API - /property-services/assessment/_search.
If the assessment object returned fetches assessment array details then the fetch bill API is called to retrieve the payment details for the particular property.
Fetch bill API - /billing-service/bill/v2/_fetchbill
Following is the hook used for the property search API, assessment search and fetch bill.
No MDMS data is used here. All data is loaded from the Search API.
The localization keys for My Properties are added to the ‘rainmaker-pt’ locale module. Any changes, updates or addition of a new localization key are done in the same locale module.
Objective: To provide employees with the functionality to search Applications (whether Active or in workflow) based on
Application No.
Property ID
Owner’s Mobile No.
Application Type
Application Status
Create Between Dates
Users can view the application details page by clicking on the application number. The details page allows the employees to initiate and perform different workflow actions.
Search application file link: https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/pt/src/components/SearchApplication.js
The below hook is used to call the Property Search API and load the search result:
1const { isLoading, isSuccess, isError, error, data: {Properties: searchReult, Count: count} = {} } = Digit.Hooks.pt.usePropertySearch( 2 { tenantId, 3 filters: payload 4 }, 5 config, 6 );
Objective: Users can review the list of applications and their status registered under their mobile number in the My Applications tab.
Initially, only four applications are loaded on the screen. The user can click on the Load More option to view more applications. Each application displays the Application Number, Service Category, Property Id, Application Type and Status details along with the Track option. This enables the user to find more details about the application. If users are unable to find their property details on the system, a new application can be created using the link provided at the bottom of the page.
Once the user clicks on the Track button, the Application Details page is displayed with all the necessary information about the application.
Timeline component: The timeline component is available at the end of the application details. This provides the details on the current status and history of the application passing through various workflows and actions taken.
Click here to fetch the working code details for My Applications and Application Details common Index.
The template for My Application is present under pt/pages/citizen/PTMyApplications and the Application Details page is present inside pt/pages/citizen named as PTApplicationDetails. The list of applications is retrieved by calling the search API "/property-services/property/_search".
This API is called using the React hook present inside the index of PTMyapplication and PTApplicationDetails page. A single application is loaded bypassing the unique Property Id in the search API.
Following is the hook used for the property search API.
The two main util functions and their objectives are given below:
Create Util Function: While going through the Create flow, all the inputs provided by the user are stored in a different structure. Since the units are not separated in the flow but incorporated into distinct categories, the storing structure is different from the request body of Create API. This function transforms the flow of stored data into the requested body format.
Click here to fetch the code.
Update Util Function: Click here to find detailed information about this function.
No MDMS data is used here - all the data is loaded from the Search API.
For My Applications, the localization keys are added to the ‘rainmaker-pt’ locale module same as in My Properties and Create Property. Any changes, updates or addition of any new localization key is done in the same locale module.
Objective: The Quick Pay feature allows a citizen to quickly view or pay all his pending bills for Property Tax (or any other supported business Service) by clicking links directly from the Digit-UI home screen.
Clicking on the Property Tax link in the Quick Pay section, a user is redirected to the My Bills screen. Else, the user has to log in using his mobile number and the OTP is sent to the number. The user is then redirected to the My Bills screen.
On the My Bills screen, the user finds his pending property tax bills (displayed as cards) for registered properties. The user can click on the View Details button of the corresponding card to check the detailed bill summary which takes him to the bill details page. There is also a link for the case when the user is unable to find the property tax bills.
The Bill Details screen shows a list of various categories of applicable taxes. After checking the user can select to pay either the full amount or the custom amount, which cannot be less than ₹100 and not more than the total tax. These restrictions, however, are customizable as per ULB requirement and can be changed in the MDMS.
Clicking on the Proceed To Pay button redirects the user to the Pay screen. The user is asked to select the payment gateway using the radio buttons. On clicking pay, the user is redirected to the bank payment gateway.
After making a successful payment through the bank gateway, the user is redirected to the response screen which shows the details of the payment and other bill details.
In case the payment fails for any reason the response screen shows the message, that the payment transaction has failed.
Use Case: when user wants to pay for property registered to a different mobile number
My Bills page only displays the properties with pending taxes linked to the mobile number used to log in. To search and pay for any other property, users can click on the link below the My Bills screen that redirects the user to the search screen.
On the Search screen, the user can search a property by mobile number, a unique property ID, or an existing property ID. The search parameters redirects the user to the search results screen. Here users can see all the properties with the matching criteria, whether or not they have pending taxes.
Clicking on the View Details buttons redirects the user to the bill details screen.
My Bills Screen
Click here to fetch the My Bills screen starting file
An MDMS call is made to this page to fetch details based on the defined restrictions such as partial payment is allowed or not, advance payment allowed or not, minimum payable amount etc. for the particular business service which is supplied into URL.
The MDMS criteria used here for fetching MDMS details are:
The pending bills are fetched for the citizen for the specific business service using the custom hook, that fetches bills linked to the logged-in mobile number.
The bill is rendered using a keynoteConfig file which can be located here.
On this page, for each business service, there is a configuration stored to define what part of the bill is to be displayed.
The configuration returns an object of structure.
Here my-bill key has config for the my-bills screen. This configuration decides what details to show on the card for each service from the bill object returned by the fetchBill API.
It is an array of objects, where each object puts the bill detail on the My-Bills bill card.
Each object contains 4 properties ie keyValue, keyPath, fallback, noteStyle. The keynote config is added into the Digit component Registry as getBillDetailsConfigWithBusinessService
The implementation of the config can be found here.
Bill Details Screen
The bill details screen can be found here.
It checks for various payment restrictions that are fetched from the MDMS on above mentioned My Bills description. The tax heads that are to be displayed in the summary are also fetched from the same MDMS.
The structure for payment rule response from the MDMS are -
partPaymentAllowed key when true allows payment less than bill details to be paid otherwise the user can pay only the bill Amount.
minAmountPayable is the minimum bill amount a user can pay.
isAdvanceAllowed if the true user can enter the amount more than the specified.
The link for the MDMS can be found here.
Payment Screen
The payment screen fetches the payment gateways from an MDMS call.
The code can be found here.
Response Screen
The response page code can be found here.
Search Screen
The search screen is a part of PT module and its code can be found here.
Search Result Screen
The Search Result screen code can be referred to here.
The keynote config is responsible for adding the new bill UI for adding a new bill for a business service.
The whole function is exposed within the component Registry as getBillDetailsConfigWithBusinessService and can be redefined from here.
Detailed steps to configure privacy in property tax module
To ensure that the system works as expected after enabling privacy, we will require some configurations to be made in the environment. This document contains the steps to ensure the successful implementation and working of the Property Tax module.
Following will be the changes required to move it to other environments:
Sample index at the bottom.
In the params list in both the above curls, “tenantIds” param can either be provided with a single tenantId or a list of tenantIds for encrypting the data with respect to the provided tenantIds. However, to encrypt the data for all tenantIds in the system, tenantIds param itself should be removed.
To validate if the encryption is completed, you can check with the following dB queries:
select * from eg_pt_enc_audit order by createdtime desc;
select count(*) from eg_pt_id_enc_audit;
With this query, it can be validated if all records are there or not. The count should match with the total count of records in the eg_ws_connection table.
select * from eg_pt_id_enc_audit;
This can help you check what all properties have been updated so far. This table contains the id, applicationnumber, connectionnumber and tenantid.
Sample Index for point 8:
Objective: Provide users with the payment details for properties registered to the given mobile number and facilitating payments.
Users can view the list of payments for properties registered to their mobile number in My Payments tab. The initial view displays the Amount Paid, Property Id, Owner Name, Receipt Date and Receipt Number, and the Download Receipt options. Clicking on the Download Receipt button offers a payment receipt details.
Clicking on the Download Receipt button downloads the payment receipt.
The property search API is called in order to get all the properties linked to the mobile number -https://qa.digit.org/property-services/property/_search?_=1646986118830
Next the payments search API is called to retrieve the payments for each property -
API Hooks used to call APIs are in the index file of My Payments
No MDMS data is used here. All data is loaded from the Search API.
For My Payments the Localization keys are added to the ‘rainmaker-pt’ locale module. Any changes, updates or addition of new localization keys is done in the same locale module.
Objective: To provide the employees involved in PT workflow, the functionalities to create a property Application in create workflow.
A counter employee can use create an application form, to register a citizen’s property.
The file for create Application form for PT can be found in:-
for creating an application employee enters all the details of the form manually, and Documents are uploaded based on the MDMS configuration found in the file:
MDMS Data
The MDMS data for documents is similar to that found in :
**with the noted addition of formDataPath, formArrayAttrPath, in filterCondition and dropdownFilter .
formDataPath path is the form path in form of an array of keys that requires to be followed to a new UI form to check the entered value. similar to jsonPath and parentJsonpath in old UI, While the formArrayAttrPath replaces the arrayAttribute.
The use of the MDMS data within the component can be found in :
After adding all the valid documents and form values in the form, the user is allowed to submit the form
which calls the property create API:1property-services/property/_create
Acknowledgement Screen
If the Property creation is successful. then the employee is directed to this screen that shows Acknowledgement Id and the option to download a hardcopy of the acknowledgement containing property details.
Objective: To provide employees with the functionality to search properties (either in active or in workflow status) based on locality, owner mobile, or unique Property Id.
The employee also can see the dues for property within the search results and can choose to pay the dues if any, by clicking on collect tax.
Users can also view the current property Details page, to view Property Details, where employees can perform actions like assessment, Updation and Mutation, on an approved active Property.
APIs
The 1st API is used to fetch all the localities, based on the logged in tenant.
The 2nd API is used to fetch the search results of the table data.
The 3rd API is used to fetch the bills showing the taxes due details in search results.
Property Details Page
This page is visible to the employee when they click on the property ID of the property in search.
Here employees can see the latest approved property details. The employee also has the option to start property assessment, transfer ownership, and edit property details.
The employee also has the option to view history - this enables the users to view the owner details within the history of the property.
Payment History
Users can access the payment history of a specific property as well as download the receipt for the same.
APIs
Same as in the case of application details. The latest approved data is shown and any data which is not in the workflow is filtered out.
Assessment Popup
The popup is displayed when an employee chooses to assess property from the property details page of active property.
The popup displays the list of financial years to select from:-
A financial year is selected for the assessment of the property.
Technical Details
Assessment Screen
Clicking on the Assess Property button displays the Property Assessment screen.
This screen gives the assessment details of the selected financial year from the popup. It also provides an overview of the property as well as the total calculation details. This value is fetched from the MDMS.
After clicking on Assess Property, the button changes to Proceed To Pay that redirects the employee to the common pay screen.
Technical Details
The following hook is used to retrieve the charge slabs from the MDMS call
API Used
The 1st API is provided with the financial year and property Id as parameters to get the payment estimations for the property.
The 2nd API is used to fetch property details.
The 3rd API is used to create an assessment of the property - this provides the estimated tax value for the property.
Objective: Provide employees with the options to view the assigned, escalated applications and the applications that are pending for action.
Route -
Inbox screen can be divided into 4 sub components as listed below:
Sidebar
Quick action button
Service List
Inbox worklist
Action Menu is the component that shows the menu items in the sidebar based on the response from the access/v1/actions/mdms/_get API .
Quick Action button which shows the menu based on the response from the access/v1/actions/mdms/_get API.
Service List is the component that shows the menu based on the response from the access/v1/actions/mdms/_get API.
Inbox worklist is the component that shows the records based on the response from the /egov-workflow-v2/egov-wf/process/_search API.
Inbox worklist contains options to filter and search the records based on the options.
Fetching all the records from the process instance is not made in a single call since we might fetch a lot of records. So we make a call to get the total count from egov-workflow-v2/egov-wf/process/_count API. After that, we load the initial records for all business services.
Once all the records are fetched the system loads the locality of the records based on the locality search provided by the service (BUSINESS SERVICE).
The Assigned To Me Tab displays all assigned applications for the logged-in user.
All records are fetched from the process instance response that filters the records based on the following condition:
1get(item, 'assignes[0].uuid')=== uuid;
Here, the UUID is the logged-in Employees User id and the item is the total records.
SLA of the Application is based on the businesssServiceSla and it is converted using the following conversion:
item.businesssServiceSla / (1000 * 60 * 60 * 24)
Nearing Escalation and Escalated is identified based on the businesssServiceSla present in that record and the configured MDMS data wfSlaConfig
It contains the slot colour and percentage.
Pagination is configured in the MDMS to hold default records and default options to show rows per page.
Table and Table pagination can be accessed from this file link below.
In every row, there is an option to view or perform an action on the record and this redirects users to the relevant module.
Refer to the Config below.
Redirection for every module should be configured in redirectConfigand similarly for any other config like active, locality, and locality modules.
Here in Escalated tab, it makes an escalation search, using egov-workflow-v2/egov-wf/escalate/_search.The object structure is similar to the process search.
On View History - It shows which state has it got escalated using flag. isEscalatedApplicationbased on it it shows a red mark for the corresponding state.
Here all the filter options are derived from the records that we receive through the process instances. It is not from any MDMS data.
Objective: To provide employees with the ability to Edit property Details (except Owner Details).
The Edit form can be used to update the details of an approved property, or whenever an application is in a workflow state that allows/require employees to make changes.
All the updatable Input fields are enabled, and all the fields related to owner details are disabled.
After editing and clicking submit when the user is successful the user is redirected to a success screen similar to that in Employee Create.
The implementation details are similar to the create application and uses the same MDMS configurations.
APIs called:1property-services/property/_update
The Update API is supplied with updated property values from the form. All units that are added at the time of creation are set to active : false . The new units are set to active : true. This applies even when no changes are made to the units.
Acknowledgement Screen
If the Property Update is successful. then the employee is directed to the Acknowledgement screen. The screen displays the Acknowledgement Id and the option to download a pdf copy of the acknowledgement containing property details.
Objective: To provide employees with the functionality to search for created applications.
The employee inbox screen shows all created applications in workflow and requires action from the logged-in employee.
The employee has the ability to search for specific applications based on application number, property ID, or mobile number. Filters can be applied based on the business service (create, edit, or update), application status, locality, and assigned applications.
Clicking on the application number hyperlink in the inbox redirects the user to the application details page. The user can take the required action on the application to push it forward or backwards in the workflow.
File path for inbox:
API Used
Below is the API used for searching the inbox:
The above API is used to fetch the Inbox results based on the selected filters and search criteria.
The inbox screen offers customization for the fields in the inbox table. The fields inside the inbox table are exposed in the component registry service as in the file:
It is exposed as PTInboxTableConfig key in component registry service, and can be redefined to reset the columns. The function returns an object of the following structure:-
inboxCloumns and searchColumns functions return an array of objects where each object represents a column.
The inboxCloumns is used for setting columns in the Inbox, while searchColumns is used for setting columns.
Every column has the following properties:-
Header is the heading that is used in the head of the column (basically name of the column).
accessor is . separated string value that specifies the path within each row to be followed in order to display the value of the column. The structure of the row object is similar to row.original explained below.
Cell is a function returning a valid JSX. In case some complex component requires to be rendered, the function is supplied an object with row property. Each row contains property details, with row.original being the actual data for the property row. The searchData contains search-related results associated with the property, while workflowData contains workflow related data associated with property.
This page is where the employee is redirected after clicking on the application number in the inbox. The user finds the Take Action button at the bottom of the screen and performs actions based on the employee's role and the state of the application in the workflow. Users can also view the timeline where they can see the updates by other employees and the actions taken on the application so far.
The employee views details like owner details, address along with the documents attached at the time of creation. In the case of mutation applications, the employee can see transferer and transferee details.
While performing the action users can upload docs, add comments for the next employee in workflow, or they can assign them to a specific employees in the action resultant workflow.
If a particular workflow is completed then, the application is said to be completed and the status of property changes to ACTIVE .
APIs Called
The application details page calls the following APIs.
the 1st API is called to fetch the timeline processed through the process instance.
The 2nd API is called to fetch address, owner-details, and document fileStoreId for all the documents associated with the property.
The 3rd API is called to get current performable actions based on the existing process instance. This is then filtered through as per the actions performable by the employee’s role.
The 4th API is called to fetch all the documents for the file store ids.
Objective: To Provide employees with functionality to transfer Ownership of an active property.
When a property is in active status and has no dues to pay, the employee has the option to mutate a property on the Property Details page.
The doc required page is shown if the property is paid for otherwise the user is redirected to the payment details page. It shows the employee the list of documents required in order to proceed with the form.
Clicking on the Transfer of Ownership button on the required page redirects the employee to the Transfer of Ownership or Mutation form. Here the Transferor details are displayed and the employee can fill out the transferee details form.
MDMS Data Used
APIs Called: 1property-services/property/_update
When update API is called the documents are updated in accordance to the snippet below:-
Here data.originalData is the property before the update. The data.documents is the documents that were uploaded in the form, and mutationDocs is the MDMS response for Mutation Docs.
Acknowledgement Screen
If the Property Mutation is successful. then the employee is directed to the acknowledgement screen. The screen displays the Acknowledgement Id and the option to download a pdf copy of the acknowledgement containing property details.
Objective: To provide citizens with the functionality to apply for Ownership Transfer for an active property.
The Transfer of Ownership Option is provided to citizens on the home screen in the citizen App, under property Tax card.
Upon clicking on “Transfer Property Ownership/Mutation” link, users are taken to property search page just like in case of “search & Pay” option, where he can search for the property he wants to search the property for.
After searching the property the user is shown the property details for the properties based on the search criteria. With Total Dues on top of the card.
If there are dues owed on the property (unpaid taxes), then users are shown a popup stating that the citizen has to clear his dues first. with a proceed to pay button that takes citizens to the common pay page, just like in the case of Search & Pay.
In case of dues cleared the citizen is taken to the Docs required Page, just like in the case of Employee Mutation, where he is shown the list of docs he is supposed to have in order to be able to transfer the property.
on this page after clicking on Transfer of Ownership, the citizen is made to go through the Ownership Transfer flow where he fills in the Ownership details and Mutation Details. After completing the flow citizen is shown with the success screen with his application number and the option to download his acknowledgement as a pdf.
MDMS data
The MDMS data is the same as in the case of employee Mutation Screen.
API used
The citizen mutation calls the property-services/property/_update API to update the property status after that the application is gone through the Employee workflow to complete the transfer.
When Update API is called the documents are updated for the property according to the following snippet:-
Here originalProperty is the property data before mutation, and mutationDocs is the MDMS response for Mutation Docs.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
| Usage type | Minimum Market value | Maximum Market Value | Rate Percentage | Fixed amount | Calculation Type |
|---|---|---|---|---|---|
| Title | Link |
|---|---|
2. An index for Old data encryption: Copy of index config under existing update topic Reference: Enc-Property indexer and persister changes by hinamakhija-eGov · Pull Request #2516 · egovernments/configs
| ULB | Total Records | Duplicate/Wrong data | % of data loadable after imposing assumptions | % of incorrect data |
|---|
All content on this page by is licensed under a .
File link for the code for payer details: https://github.com/egovernments/DIGIT-Dev/tree/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/common/src/payments/citizen/payers-details - Connect to preview
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
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
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
My Payments common index file link:
Static screen file link:
All content on this page by is licensed under a .
The file for search can be found in:
The code details can be found in:
The financial year list is fetched from the MDMS:
It also provides the counter employee with a chance to add penalty or rebate in the current bill and accordingly the total value is calculated. The counter employee needs to click on the Add Rebate/Penalty button that opens a popup containing the penalty and rebate details.
The file for the assessment Details page can be found here:
All content on this page by is licensed under a .
Inbox screen is loaded based on the file
Action Menu component file is present in. Based on the response the actions gets filtered based on the condition in navigationURL
The quick Action button is present in . Based on the response the actions get filtered based on the condition item.url === "quickAction"
based on the response the actions get filtered based on the condition item.url === "card"
These details are configured in CommonInboxConfig MDMS
Functionality file path:
All content on this page by is licensed under a .
Edit Form implementation file link:
All content on this page by is licensed under a .
The object.PT contains 2 keys- inboxColumns and searchColumns. These are functions that contain props as an argument. These props are supplied to the component called DesktopInbox as seen in the following file:-
For further enquiry on how to set columns check out the link here-
Code for the application details available here -
All content on this page by is licensed under a .
Mutation file link:
Similar to the MDMS used in employee Property Create flow and the Mutation Documents flow. Mutation documents MDMS data file link:
All content on this page by is licensed under a .
Code link for citizen mutation:
All content on this page by is licensed under a .
API
Action id
Roles
/access/v1/actions/mdms/_get
870
CITIZEN
/egov-mdms-service/v1/_search
954
CITIZEN
/localization/messages/v1/_search
1531
CITIZEN
/billing-service/bill/v2/_fetchbill
1862
CITIZEN,
/pg-service/transaction/v1/_create
1571
CITIZEN
/collection-services/payments/_search
1864
CITIZEN
/pg-service/transaction/v1/_update
1572
CITIZEN
collection-services/payments/PT/_search
2029
PTCEMP, CITIZEN
Url
Roles
Action Id
/egov-mdms-service/v1/_search?
PTCEMP,FI,APPROVER,DV
/egov-workflow-v2/egov-wf/businessservice/_search
PTCEMP,FI,APPROVER,DV
1743
/filestore/v1/files/url
PTCEMP,FI,APPROVER,DV
1528
/property-services/property/_search
PTCEMP,FI,APPROVER,DV
1897
egov-workflow-v2/egov-wf/process/_search
PTCEMP,FI,APPROVER,DV
1730
Url
Role
Action Id
/egov-location/location/v11/boundarys/_search
PTCEMP,FI,APPROVER,DV
1429
/property-services/property/_search
PTCEMP,FI,APPROVER,DV
1897
Url
Roles
Action Id
egov-workflow-v2/egov-wf/process/_search
PTCEMP,FI,APPROVER,DV
1730
/property-services/property/_search
PTCEMP,FI,APPROVER,DV
1897
/egov-workflow-v2/egov-wf/businessservice/_search
PTCEMP,FI,APPROVER,DV
1743
/filestore/v1/files/url
PTCEMP,FI,APPROVER,DV
1528
name
value
description
is.mutation.workflow.enabled
true/false
enables/disbales the workflow
PT.MUTATION
workfow config name
Residential
0
X lacs
A% of CMV
INR G
FLAT
Non -Residential
0
X lacs
E% of CMV
INR Q
RATE
Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
FLAT
Non -Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
RATE
Residential
Y+1 Lacs
>Y+1Lacs
D% of CMV
INR L
FLAT
Non -Residential
Y+1 Lacs
>Y+1Lacs
C% of CMV
INR I
RATE
API contract for MT calculator
API list to create Mutation Slabs mutation/_create, _search, _update
API list for MT-Calculator mutation/_calculate
API
Action id
Roles
/access/v1/actions/mdms/_get
870
CITIZEN
/egov-mdms-service/v1/_search
954
CITIZEN
/localization/messages/v1/_search
1531
CITIZEN
/billing-service/bill/v2/_fetchbill
1862
CITIZEN,
/pg-service/transaction/v1/_create
1571
CITIZEN
/collection-services/payments/_search
1864
CITIZEN
/pg-service/transaction/v1/_update
1572
CITIZEN
collection-services/payments/PT/_search
2029
PTCEMP, CITIZEN
Url | Roles | Action Id |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Url | ROLE | Action ID |
|
|
|
Url | Role | Action Id |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Url | Roles | Action Id |
|
|
|
Url | Roles | Action Id |
|
|
|
|
|
|
|
|
|
|
|
|
Url | Roles | Action Id |
|
|
|
Roorkee | 16363 | 500 | 97% | 3% |
Rishikesh | 2877 | 356 in the first sheet 261 in the second pass | 88% 91% | 12% 9% |
Url | Roles | Action Id |
|
|
|
API | ROLES | ACTION ID |
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
| 1730 |
5 |
|
|
|
6 |
|
|
|
