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
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:
https://github.com/egovernments/configs/blob/qa/egov-indexer/property-services.yml
** 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:
Ownership Transfer Technical documentation
The mutation service provides a facility to change ownership of a property in relation to sales, 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 the demand-based systems.
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 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 fees calculation, document date value (means the date at which property is registered for mutation), market value of property, usage type value of the property is essential.
Please refer to the parent for external services: Property Services | Doc-Links
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.
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 the demand-based systems.
Following services should be up and running:
user MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
Enables user to update 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 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.
Reference Docs: - For additional details please refer to the property document Property Services | Doc-Links
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.
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
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
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, assessment of properties.
Customer 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:
Usage type | Minimum Market value | Maximum Market Value | Rate Percentage | Fixed amount | Calculation Type |
---|---|---|---|---|---|
__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.
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
__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.
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 -
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
All content on this page by is licensed under a .
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
Title
Link
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
1
property-services/property/_addAlternateNumber
870
CITIZEN
,PT_CEMP
2
property-services/property/_update
954
CITIZEN,PT_CEMP
3
user-otp/v1/_send
1531
CITIZEN
4
/property-services/property/_search
1897
CITIZEN
,PT_CEMP
name
value
description
kafka update topic
update-property-registry
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
Title
Link
/assessment/_create
/assessment/_update
/assessment/_search
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 |
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 |
Title | Link |
USER Service |
url-shortening |
MDMS |
Billing-service |
Location |
Workflow |
Persister | **** |
Localization |
Id-Gen service |
Title | Link |
/Property/_create |
/Property/_update |
/property/_search |