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
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 - property-services-registry.yml
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
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
Workflow Config for property create if the source is from WATER CONNECTION module
For the creation of property from the water and sewerage module, as per the use case mentioned in this ticket, a different workflow config is used. For each use case, to identify which workflow to use can be identified from this mdms file.
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
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.
Note: The above objects indicate each use case mentioned in this ticket, so at a time only one object (use case) enable field must set as true
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
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
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
Title
Link
USER Service
url-shortening
MDMS
Billing-service
Location
Workflow
Persister
**
Localization
Id-Gen service
API LIST:
Title
Link
/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.
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.
MDMS CONFIG: https://github.com/egovernments/egov-mdms-data/tree/DEV/data/pb/PropertyTax - Connect to preview
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Property-services
API Collection -
All content on this page by is licensed under a .
Please refer to the parent for external services:
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
Usage type
Minimum Market value
Maximum Market Value
Rate Percentage
Fixed amount
Calculation Type
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
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.
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
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
Title
Link
/assessment/_create
/assessment/_update
/assessment/_search
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.