TheSewerage Calculator Service is used for creating meter readings, searching meter readings, updating existing meter readings, calculating sewerage charges, demand generation, SMS & email notification to ULB officials on-demand generation and estimation of sewerage charges on basis of meter reading for existing sewerage application until the application is disconnected.
There are no additional billing slabs to be configured for sewerage disconnection, the calculation happens with the meter reading if added and uses existing billing slabs.
Criteria
connection type
building type
calculation attribute
property usage type
The combination of the above can be used to define the billing slab. Billing Slab is defined in MDMS under ws-services-calculation folder with the WCBillingSlab. The following is the sample slab (Same as the water connection).
For the disconnection application fee, the estimation will return all the related tax heads based on the criteria.
Following are the exemptions and taxes that are calculated:
Form fee
Scrutiny fee
Other charges
Security charges
Tax and cess
The sewerage charge is based on the billing slab, and for sewerage disconnection application charge will be based on the slab and tax based on the master configuration.
Interest
Below is a sample of the master data JSON for interest:
Penalty
Below is a sample of the master data JSON for penalty:
Round Off
If the fraction is greater than equal to 0.5 the number is rounded up else it’s rounded down. eg: 100.4 will be rounded to 100 while 100.6 will be rounded to 101.
Whenever _calculate API is called demand is first searched based on the connection no 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 connection no and demand from and to a period equal to the financial year start and end period.
In case of the update, if the tax head estimates change, 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 SEWERAGE_CHARGE equal to 120.
After updating if the SEWERAGE_CHARGE increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:
The disconnection charges will be the addition of both demand details taxAmount and we can generate demand until the workflow is in PENDING_FOR_DISCONNECTION_EXECUTION.
Note: if there is no pending payment when the connection gets approved then the workflow gets updated from PENDING_APPROVAL_FOR_DISCONNECTION to PENDING_FOR_DISCONNECTION_EXECUTION (it skips the payment step in the workflow internally).
Here the disconnection charges will be 120+30 = 150
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 SW_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all SW_ROUNDOFF will always be less than 0.5.
Final sewerage charges calculation
Final Sewerage Charges = Last Billing Period Amount * Days (Proposed disconnection date - Last Billing Date) / No. of days in last billing period
The additional parameter is being sent in the calculation request for the disconnection application.
disconnectRequest = true if the request is for _calculate API disconnection application.
(Note: All the APIs are in the same postman collection therefore the same link is added in each row)
Link
/sw-calculator/sewerageCalculator/_calculate
/sw-calculator/sewerageCalculator/_updateDemand
Sewerage Calculator Service is one of the major business logic services which is used for calculation of sewerage charge, generating demand, update existing demand, SMS & email notification to the ULB officials on-demand generation and also triggering demands(job scheduler) at some intervals and estimation of sewerage charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee etc.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has sewerage service persister configs path added in it
PSQL server is running and a database is created to store sewerage connection / application data
Following services should be up and running:
egov-perister
egov-mdms
sw-services
billing-service
Sewerage calculator services present in municipal services provide multiple functionalities like calculating sewerage charges, generating demands for a particular sewerage connection, updating demands, SMS & email notification to the ULB officials on-demand generation and also triggering demands(job scheduler) at some intervals and estimation of sewerage charge(one-time cost) which involves cost like road-cutting charge, form fee, scrutiny fee etc. The different functionalities provided by sewerage calculator services are:
Sewerage charge calculation
Demand generation(here as its always non-metered demand will be generated based on time period)
Sewerage charge estimation (one-time cost which involves cost like road-cutting charge, form fee, scrutiny fee etc.)
Deploy the latest version of sw-service and sw-calculator
Add sewerage-persist.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )
Criteria :
connection type
building type
calculation attribute
property usage type
The combination of the above can be used to define the billing slab. Billing Slab is defined in MDMS under sw-services-calculation folder with the SCBillingSlab. The following is the sample slab.
If all criteria will match for that sewerage connection this slab will use for calculation.
For application one-time fee, the estimation will return all the related tax head based on criteria. For estimation, all configuration is present in sw-services-calculation.
All the above master configuration is used for estimation.
Following are the exemptions and taxes that are calculated:
Form fee
Scrutiny fee
Other charges
Road cutting charges
One time fee
Security charges
Tax and cess
Sewerage charge is based on billing slab, for sewerage application charge will be based on slab and tax based on master configuration.
Interest
Below is a sample of master data JSON for interest :
Penalty
Below is a sample of master data JSON for penalty**:**
Round Off
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.
Role Action Mapping
Once sewerage is sent to the calculator, its tax estimates are calculated. Using the tax head estimates demand details are created. For every tax head, the estimated demand generates function will create a corresponding demand detail.
Whenever _calculate API is called demand is first searched based on the connection no or application no 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 connection no or application no and demand from and to a period equal to financial year start and end period.
In the case of an update, if the tax head estimates change, 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 SEWERAGE_CHARGE equal to 120
After updating if the SEWERAGE_CHARGE 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 SW_ROUNDOFF in demand detail can be greater than 0.5 but the sum of all SW_ROUNDOFF will always be less than 0.5.
For generating the demand for non metered connection we have a feature for generating the demand in batch. The scheduler is responsible for generating the demand based on the tenant.
The scheduler can be hit by scheduler API or we can schedule cron job or we can put config to kubectl which will hit scheduler based on config.
After the scheduler been hit we will search the list of the tenant (city) present in the database.
After getting the tenants we will pick up tenant one by one and generate the demand for that tenant.
We will load the consumer codes for the tenant and push the calculation criteria to Kafka. Calculation criteria contain minimal information (We are not pushing large data to Kafka), calculation criteria contain consumer code and one boolean variable.
After pushing the data into Kafka we are consuming the records based on the batch configuration. Ex:-> if the batch configuration is 50 so we will consume the 50 calculation criteria at a time.
After consuming the record(Calculation criteria) we will process the batch for generating the demand. If the batch is successful so will log the consumer codes which have been processed.
If some records failed in batch so we will push the batch into dead letter batch topic. From the dead letter batch topic, we will process the batch one by one.
If the record is successful we will log the consumer code, If the record is failed so we will push the data into a dead letter single topic.
Dead letter single topic contains information about failure records in Kafka.
Use cases
If the same job trigger multiple time what will happen?
If the same job triggers multiple times we will process again as mentioned above but at the demand level we will check the demand based on consumer code and billing period, If demand already exists then we will update the demand otherwise we will create the demand.
Are we maintaining success or failure status anywhere?
Currently, we are maintaining the status of failed records in Kafka.
Configuration
We need to configure the batch size for Kafka consumer. This configuration is for how much data will be processed at a time.1sw.demand.based.batch.size=10
sw-calculator will be integrated with sw-service. sw-services internally invoke the sw-calculator service to calculate and generate demand for the charges.
SW calculator application is used to calculate the sewerage application one time Fees and connection charges based on the different billing slabs that's why the calculation and demand generation logic will be separated out from SW service. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the SW service.
To Activate the Sewerage Service application, the user needs to pay the ONE_TIME_FEE for the connection. To calculate the ONE_TIME_FEE sw-calculator/sewerageCalculator/_estimate API is use.
To generate the demand for non-metered sewerage connection /sw-calculator/sewerageCalculator/_calculate API is use.
User can pay partial / full / advance amount for the Non-Metered connection bill. In these cases, Billing service would call back /sw-calculator/sewerageCalculator/_updateDemandAPI to update the details of the demand generated.
/sw-calculator/sewerageCalculator/_jobscheduler API is use to generate demand for Non-metered connections. This API can be called periodically.
/sw-calculator/sewerageCalculator/_applyAdhocTax API is used to add Rebate or Penalty on any bill and based on that the bill amount will be adjusted.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
This is one of the major application of the egov stack which helps municipal and citizens to handle sewerage services like creating sewerage connection, searching sewerage connection, sewerage connection, also creating property if it doesn't exist and creating and updating workflow were depending on different roles of the logged-in user he/she can perform various actions like editing or perform document verification and many more specified in workflow documentation and SMS & email notification sent to the owner for various actions performed in the workflow.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has sewerage service persister config path added in it
PSQL server is running and a database is created to store sewerage connection / application data
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service will be helpful.
The sewerage service provides multiple functionalities starting from serving as a central repository where one can create sewerage connection, update sewerage connection, search for a particular sewerage connection based on different criteria like mobile number, sewerage connection nos etc. and also creating property if it doesn't exist, creating and updating workflow were depending on different roles of the logged-in user he/she can perform various actions like editing or perform document verification and many more specified in workflow documentation and SMS & email notification sent to the owner for various actions performed in the workflow. The different services provided by the sewerage services are
Creating sewerage connection
Updating sewerage connection
Apply for Property creation.
Searching sewerage connection based on a few criteria mentioned in swagger documentation later
Creating property if it doesn't exist
Creating and updating workflow.
To Do
Table UML Diagram
****
MDMS configuration
master-config.json for sewerage service
Actions & Role Action Mapping
Actions
Role Action Mapping
Workflow business service config
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for sewerage service
Workflow for property creation through Water and Sewerage Module
Indexer config for sewerage-service
Setup
Provide the absolute path of the checked-in file to DevOps, to add it to the file-read path of egov-indexer. The file will be added to the egov-indexer's environment manifest file for it to be read at the start-up of the application.
Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.
Modify connection
After connection activation or legacy connection, we can edit the connection. This process based on a defined workflow. Any action is based on defined roles on the action level. For edit connection, we need to upload some supporting documents and mandatory info.
Workflow config for edit connection
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for editing sewerage connection.
1{ 2 "RequestInfo": { 3 "apiId": "Rainmaker", 4 "action": "", 5 "did": 1, 6 "key": "", 7 "msgId": "20170310130900|en_IN", 8 "requesterId": "", 9 "ts": 1513579888683, 10 "ver": ".01", 11 "authToken": "{{Auth_Token}}" 12 }, 13 "BusinessServices": [ 14 { 15 "tenantId": "pb", 16 "businessService": "ModifySWConnection", 17 "business": "sw-services", 18 "businessServiceSla": 259200000, 19 "states": [ 20 { 21 "sla": null, 22 "state": null, 23 "applicationStatus": null, 24 "docUploadRequired": false, 25 "isStartState": true, 26 "isTerminateState": false, 27 "isStateUpdatable": false, 28 "actions": [ 29 { 30 "action": "INITIATE", 31 "nextState": "INITIATED", 32 "roles": [ 33 "SW_CEMP" 34 ] 35 } 36 ] 37 }, 38 { 39 "sla": null, 40 "state": "INITIATED", 41 "applicationStatus": "INITIATED", 42 "docUploadRequired": false, 43 "isStartState": false, 44 "isTerminateState": false, 45 "isStateUpdatable": true, 46 "actions": [ 47 { 48 "action": "SUBMIT_APPLICATION", 49 "nextState": "PENDING_FOR_APPROVAL", 50 "roles": [ 51 "SW_CEMP" 52 ] 53 } 54 ] 55 }, 56 { 57 "sla": 86400000, 58 "state": "PENDING_FOR_APPROVAL", 59 "applicationStatus": "PENDING_FOR_APPROVAL", 60 "docUploadRequired": false, 61 "isStartState": false, 62 "isStateUpdatable": true, 63 "isTerminateState": false, 64 "actions": [ 65 { 66 "action": "APPROVE_CONNECTION", 67 "nextState": "APPROVED", 68 "roles": [ 69 "SW_APPROVER" 70 ] 71 }, 72 { 73 "action": "REJECT", 74 "nextState": "REJECTED", 75 "roles": [ 76 "SW_APPROVER" 77 ] 78 }, 79 { 80 "action": "SEND_BACK", 81 "nextState": "INITIATED", 82 "roles": [ 83 "SW_APPROVER" 84 ] 85 } 86 ] 87 }, 88 { 89 "sla": null, 90 "state": "REJECTED", 91 "applicationStatus": "REJECTED", 92 "isStateUpdatable": false, 93 "docUploadRequired": false, 94 "isStartState": false, 95 "isTerminateState": true 96 }, 97 { 98 "sla": null, 99 "state": "APPROVED", 100 "applicationStatus": "APPROVED", 101 "isStateUpdatable": false, 102 "docUploadRequired": false, 103 "isStartState": false, 104 "isTerminateState": true 105 } 106 ] 107 } 108 ] 109} 110
Notification
Notification will be sent to the property owners and connection holders based on different application states.
Capturing connection holders
We can add connection holders to the sewerage connection which will be the owner of the connection. We can fill in the connection holders' details or we can just make the property owner to the connection holder.
The connection holder will get a notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.
Multiple Road Type Support We can add road cutting details of multiple roads to the sewerage connection. For each road which goes under cutting process we have to fill their road type details and road cutting area. Based on this information, application one time fee estimate is calculated.
This sw-service module is use to manage sewerage service connections against a property in the system.
Provide backend support for the different sewerage connection registration process.
Mseva and SMS notifications on application status changes.
Elastic search index for creating visualisations and Dashboards.
Supports workflow which is configurable
To integrate, the host of sw-service module should be overwritten in helm chart.
/sw-services/swc/_create should be added as the create endpoint for creating sewerage application/connection in the system
/sw-services/swc/_search should be added as the search endpoint .This method handles all requests to search existing records depending on different search criteria
/sw-services/swc/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
After connection activation or legacy connection, the user can choose to disconnect the connection either temporarily or permanently. This process is based on a defined workflow. Any action is based on defined roles on the action level. For disconnecting the connection, the user needs to send extra parameters in the RequestBody as below :
disconnectionReason - to add the reason for disconnection
isDisconnectionTemporary - Whether the disconnection is temporary or permanent (if disconnection is temporary then isDisconnectionTemporary will be true else false)
disconnectRequest - This will always be true for disconnection applications.
disconnectionExecutionDate - This is the date when the application is disconnected.
and also user needs to upload some supporting documents and mandatory info.
URLs for the external API references:
eGov mdms: egov.mdms.host = /
eGov -idGen : egov.idgen.host = /
localization service: egov.localization.host = /
idGen Id formats: egov.idgen.sdcid.name=sewerageservice.disconnection.id egov.idgen.sdcid.format=SW_AP/[CITY.CODE]/[fy:yyyy-yy]/DC-[SEQ_SW_APP_[TENANT_ID]]
This new feature is developed using the same existing base APIs for new and modified connections. The changes for disconnection follow a similar approach as that of New Connection. The config and persister changes required are mentioned below.
Persister configuration
Workflow config for edit connection
Create businessService (workflow configuration) using the /businessservice/_create. Following is the product configuration for editing the water connection.
Disconnection notifications will be sent to the property owners and connection holders based on different application states.
We can add connection holders to the water connection which will be the owner of the connection. We can fill in the connection holders' details or we can just make the property owner to the connection holder this goes to the disconnection application.
The connection holder will get a notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.
To integrate, the host of sw-service module should be overwritten in the helm chart.
/sw-services/swc/_create should be added as the create endpoint for creating sewerage application/connection in the system
/sw-services/swc/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria
/sw-services/swc/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of applications based on workflow.
(Note: All the APIs are in the same postman collection therefore the same link is added in each row)
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
``
Property creation through WNS module
Persister configuration:
The indexer provides the facility for indexing the data to elastic search.
Write the configuration for sewerage service.
Put indexer config file to the config repo under egov-indexer folder. ( )
All content on this page by is licensed under a .
Title
Link
/sw-calculator/sewerageCalculatorr/_estimate
/sw-calculator/sewerageCalculator/_calculate
/sw-calculator/sewerageCalculator/_updateDemand
/sw-calculator/sewerageCalculator/_jobscheduler
/sw-calculator/sewerageCalculator/_applyAdhocTax
Environment Variables | Description |
egov.sewarageservice.createconnection | This variable contains the kafka topic name which is used to create new sewerage connection application in the system. |
egov.sewarageservice.updateconnection | This variable contains the kafka topic name which is used to update the existing v connection application in the system. |
egov.sewerageservice.updatesewerageconnection.workflow.topic | This variable contains the kafka topic name which is used to update the process instance of the sewerage connection application. |
egov.idgen.scapid.name | This variable contain the idgen format name for sewerage application |
egov.idgen.scapid.format | This variable contain the idgen format for sewerage application ex:- WS/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON] |
egov.idgen.scid.name | This variable contain the idgen format name for sewerage connection |
egov.idgen.scid.format | This variable contain the idgen format for sewerage connection ex:- WS_AP/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON] |
Title
Link
API Swagger Contract
Sewerage Service Document
Link |
/sw-services/swc/_create |
/sw-services/swc/_update |
/sw-services/swc/_search |
Title | Link |
API Swagger Documentation |
Sewerage Calculator Service |
Title | Link |
/sw-services/swc/_create |
/sw-services/swc/_update |
/sw-services/swc/_search |
