Overview

eGov-User-Events service provides a common point to manage all the events generated for the user in the system. Events include updates from multiple applications like PT, PGR, TL etc, events created by the employee addressing the citizen etc. This service provides APIs to create, update and search such events for the user.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has egov-user-events persister config path added to it

• PSQL server is running and the database is created

Key Functionalities

• Provide a common platform to create, manage and notify events.

• Events can be created either through an API call or by pushing records to the Kafka queue.

Deployment Details

1. Add mdms configs required for egov-user-events.

2. Add Role-Action mapping for API’s.

3. Deploy the latest version of egov-user-events

4. Add egov-user-events file in config folder in git and add that path in persister. (The file path is to be added in environment yaml file in a param called persist-yml-path )

Configuration Details

Add master data in MDMS service with the module name as mseva. Following is some sample master data for the service: Event Categories

{
  "tenantId": "pb",
  "moduleName": "mseva",
  "EventCategories": [
    {
      "code": "PUBLICHEALTH",
      "eventType":"EVENTSONGROUND",
      "active": true
    },
    {
      "code": "CULTURAL",
      "eventType":"EVENTSONGROUND",
      "active": true
    },
    {
      "code": "WARDCOMMITTEEMEETING",
      "eventType":"EVENTSONGROUND",
      "active": true
    }
  ]
}

Event Types:

{
  "tenantId": "pb",
  "moduleName": "mseva",
  "EventTypes": [
    {
      "code": "BROADCAST",
      "active": true
    },
    {
      "code": "EVENTSONGROUND",
      "active": true
    },
    {
      "code": "SYSTEMGENERATED",
      "active": true
    },
    {
      "code": "OTHERS",
      "active": true
    }
  ]
}

Using /localization/messages/v1/_upsert , add localisation (templates) for notification messages to be sent. Following are the product notification templates:

{
  "messages": [
    {
      "code": "egovuserevents.notification.counterevent.ondelete",
      "message": "<event_name> has been deleted. Please remove from your calendar.",
      "module": "egov-user-events",
      "locale": "en_IN"
    },
    {
      "code": "egovuserevents.notification.counterevent.onupdate",
      "message": "Details of <event_name> have been updated.",
      "module": "egov-user-events",
      "locale": "en_IN"
    }
  ]
}

Configurable Properties

Following are the properties in application.properties file in egov-user-events service which are configurable.

Entities:

Events: Model to capture the events information. This object captures all the details of an event which is either being created or updated.

EventDetails: Captures details of the event such as organiser, location, time etc are captured here. This is the child object to the Events object. This has significance only because the type of the event is ‘EVENTSONGROUND’.

Action: This captures the user actions involved in the event. Say the pay now option, reopen option, download certificate option etc.

Recipient: Every event is addressed to a crowd to which a notification of the same is sent. This model captures information about the recipients of the notification of this event or can also be framed as details of the address of the event.

Event Type: Events are divided into multiple types as follows:

1. BROADCAST - These are messages broadcasted addressing a group of people. For instance, “There’s road blockage near the bus stand, please use a different route”

2. EVENTSONGROUND - These are events organised by a group of people addressing another group of people usually it is the ULB organising events for the citizens. It can be any activity like a 10K Marathon, Polio Drive, Property Tax collection drive etc.

3. SYSTEMGENERATED - These events are generated by different systems on the egov platform like PT, TL, PGR etc addressing a group of people. For instance, “Dear Citizen, Your TL has been approved please proceed to Pay here <PAY_NOW>”

4. OTHERS - Events that don’t belong to the types mentioned above.

These are configured in MDMS.

Event Category: Events are categorised into the following:

1. PUBLICHEALTH - Events related to public health.

2. CULTURAL - Cultural events

3. WARDCOMMITEEMEETING - Events for recurring meetings of the ward committee.

These event categories are mapped to event types internally. The categories mentioned here are for EVENTSONGROUND type. These are configured in MDMS.

How does it work?

This service manages user events on the egov-platform, which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service. Events can be created either by an API call or by pushing records to the Kafka queue.

Every event should contain information about the event type, event category, event name, description, recipient, actions, event details etc. Based on the type of the event, the list of mandatory fields varies. MDMS configurations required for this service to work can be found here: https://github.com/egovernments/egov-mdms-data/tree/master/data/pb/mseva

Once the event is sent for creation, the service validates all the required fields and assigns a recipient list to that event. An event can be addressed to a particular person, group of people, user type and also roles. Events like updates on the TL application are addressed to the owner of the TL only, Events like Polio Drive are addressed to the entire ULB, and Events like mass Bill generation are addressed only to those who are required to pay those bills. Similarly, a recipient list is generated based on the request and stored in the system.

When an event is updated a counter event is generated, Counter events are of 2 types: Counter event on Delete and Counter event on Update. When an event in ACTIVE status is made INACTIVE or CANCELLED, a counter event on delete is generated. When details of an event are updated irrespective of the status a counter event on update is generated. These counter-events are stored along with the actual event in the system. However, when a counter-event on delete is generated, its corresponding actual event is marked INACTIVE.

One of the important aspects of this service is the search API. Searching for the events stored in the user-events system is different for different roles. When CITIZEN searches, all the events addressed to that citizen are retrieved, the events that contain corresponding counter-events are deduplicated and only the latest ACTIVE events are returned.

We have a use-case where past events have to be marked INACTIVE, this applies to all the BROADCAST and EVENTSONGROUND types of events which are time-capped. If a BROADCAST event is active from 1/Jan to 10/Jan, it’ll be marked inactive post 10/Jan, after which the CITIZEN stops receiving any updates to that event. This changing of the status of the events is achieved by a lazy-update technique instead of a cron job. Due to this, the search API not only returns the events but also updates the status of events before returning them to the user based on whether it has expired.

When an EMPLOYEE searches, all the EVENTSONGROUND posted in his particular ULB are returned by default irrespective of the status. He/She can perform actions on those events, which if active, are notified to the CITIZEN.

An EMPLOYEE can search event based on the date the range, whatever the event created or last modified in that range, will appear in the search response. So, to get the details about an event in a particular date range pass the value in the fromDate and toDate fields of search criteria.

fromDate and toDate fields accept epoch values only.

And to get details about Delete event, pass Status as CANCELLED and to get details about Broadcast event pass eventType as BROADCAST.

Review the code and descriptions of every method to understand the use-cases and flow-of-logic in a better way.

Integration Details

Integration Scope

eGov-user-events can be integrated with any organisation or system which wants to send the events generated for the user in the system

Integration Benefits

• Easy manages user events on the system, which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service.

Integration Steps

1. An employee can create events in the system using /egov-user-event/v1/events/_create endpoint

2. Employees can update events in the system using /egov-user-event/v1/events/_update endpoint

3. Events are searched in the system using /egov-user-event/v1/events/_search endpoint

4. /egov-user-event/v1/events/notifications/_count API is used to fetch the count of total, unread, and read notifications.

5. /egov-user-event/v1/events/lat/_update API is use to update the last-login-time of the user. We store the last login time of the user through this API thereby deciding which notifications have been read.

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore same link is added in each row).

Overview

Vendor Registry is a system that enables ULB employees to create and search vendors i.e. Desludging Operator (DSO) and driver entities with appropriate vehicle Entities for FSM Applications. This document contains details on how to set up the Vendor and describes the functionalities provided.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has a vendor-persister config path added to it

• PSQL server is running and a database is created to store FSM Application data

• The following services should be up and running:

  • egov-mdms-service

  • egov-user-service

  • boundary-service

  • vehicle

Key Functionalities

1. Added payment payment preference and agency attributes for DSO

2. Added gender attribute in the create and update APIs for Vendor

3. Updated the Vendor search API to add vehicleCapacity in the search parameter to search all vendors matching the vehicle capacity specified in the search parameter.

Deployment Details

1. Deploy the latest version of the vendor

2. Add vendor-persister.yml file in the config folder in git and add that path in persister. (The file path is to be added in the environment yaml file in a param called persist-yml-path ) and restart egov-persister-service.

3. Integrate the below changes in vendor-persister.yml - https://github.com/egovernments/configs/commit/95dd26f926ec44d07448926ee4b6b7e031847a57

4. https://github.com/egovernments/configs/pull/2237/files

Configuration Details

Actions & Role Action Mapping

After adding Actions and role-action mappings, restart the egov-mdms-service.

Actions

{
      "id": {{PLACEHOLDER1}},
      "name": "Create Vendor/DSO",
      "url": "/vendor/v1/_create",
      "displayName": "Create Vehicle",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "vendor",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER1}},
      "name": "Search Vendor/DSO",
      "url": "/vendor/v1/_search",
      "displayName": "Search  Vendor",
      "orderNumber": 1,
      "enabled": false,
      "serviceCode": "vendor",
      "code": "null",
      "path": ""
    },

Role Action Mapping

[
  {
    "rolecode": "FSM_ADMIN",
    "actionid": "{{PLACEHOLDER1}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_ADMIN",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_DSO",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_EDITOR_EMP",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_VIEW_EMP",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "FSM_EMP_FSTPO",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "CITIZEN",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  }
]

Infra Ops Configuration

Configurations we can manage through values.yml of the vendor in the infra ops repo are as follows: values.yml for a vehicle can be found.

Configurations sample in Values.yml

# Common Labels
labels:
  app: "vendor"
  group: "rainmaker"

# Ingress Configs
ingress:
  enabled: true
  zuul: true
  context: "vendor"

# Init Containers Configs
initContainers:
  dbMigration:
    enabled: true
    schemaTable: "vendor_schema"
    image:
      repository: "vendor-db"

# Container Configs
image:
  repository: "vendor"
replicas: "1"
healthChecks:
  enabled: true
  livenessProbePath: "/vendor/health"
  readinessProbePath: "/vendor/health"
appType: "java-spring"
tracing-enabled: true
heap: "-Xmx256m -Xms256m"
java-args: "-Dspring.profiles.active=monitoring"

# Additional Container Envs
env: |
  - name: EGOV_VEHICLE_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: vehicle
  - name: EGOV_MDMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-mdms-service
  - name: EGOV_USER_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-user
  - name: EGOV_LOCATION_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-location
  - name: EGOV_HRMS_HOST
    valueFrom:
      configMapKeyRef:
        name: egov-service-host
        key: egov-hrms
  - name: SPRING_KAFKA_CONSUMER_GROUP_ID
    value: egov-vendor-services
  - name: PERSISTER_SAVE_VENDOR_TOPIC
    value: save-vendor-application
  - name: PERSISTER_UPDATE_VENDOR_TOPIC
    value: update-vendor-application
  - name: SPRING_KAFKA_PRODUCER_KEY_SERIALIZER
    value: org.apache.kafka.common.serialization.StringSerializer
  - name: SPRING_KAFKA_PRODUCER_VALUE_SERIALIZER
    value: org.springframework.kafka.support.serializer.JsonSerializer
  - name: JAVA_OPTS
    value: {{ index .Values "heap" | quote }}
  - name: JAVA_ARGS
    value: {{ index .Values "java-args" | quote }}
  - name: SERVER_PORT
    value: "8080"
  - name: SECURITY_BASIC_ENABLED
    value: "false"  
  - name: MANAGEMENT_SECURITY_ENABLED
    value: "false"
  {{- if index .Values "tracing-enabled" }}
  - name: TRACER_OPENTRACING_ENABLED
    value: "true" 
  {{- end }}
 

Data Setup

DSO for FSM System is a vendor, For every city/ULB DSO should be created with the Representative details as owner, associated vehicles and drivers.

Sample Curl

curl --location --request POST 'https://dev.digit.org/vendor/v1/_create' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "apiInfo": {
            "id": "string",
            "version": "string",
            "path": "string"
        },
        "deviceDetail": {
            "id": "string",
            "signature": "string"
        },
        "ts": 0,
        "action": "string",
        "key": "string",
        "msgId": "string",
        "requesterId": "string",
        "authToken": "a35b5ba7-2d5f-4272-8a67-0303cfab2c9f"
    },
    "vendor": {
        "tenantId": "pb.amritsar",
        "name": "DSO TATA1",
        "address": { 
            "tenantId": "pb.amritsar",
            "doorNo": "my door",
            "plotNo": "my plot",
            "landmark": "my landmark",
            "city": "amritsar",
            "district": "amritsar",
            "region": "amritsar",
            "state": "punjab",
            "country": "in",
            "pincode": "143001",
            "additionDetails": null,
            "buildingName": "my building",
            "street": "my streat",
            "locality": {
                "code": "SUN178",
                "name": "Mohalla Singh kia - Area2",
                "label": "Locality",
                "latitude": null,
                "longitude": null,
                "area": "Area2",
                "pincode": null,
                "boundaryNum": 1,
                "children": []
            },
            "geoLocation": {
                "latitude": 0,
                "longitude": 0,
                "additionalDetails": {}
            }
        },
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146603
        },
        "vehicles": [{
        "tenantId": "pb.amritsar",
        "registrationNumber": "TS 09 PA 3586",
        "model":"1998",
        "type":"TATA.407",
        "tankCapacity":"2000",
        "suctionType":"SEWER_SUCTION_MACHINE",
        "pollutionCertiValidTill":1611584416772,
        "InsuranceCertValidTill":1611584416772,
        "fitnessValidTill":1611584416772,
        "roadTaxPaidTill":1611584416772,
        "gpsEnabled":true,
        "source":"Municipal records",
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146617
        }
    },{
        "tenantId": "pb.amritsar",
        "registrationNumber": "TS 09 PA 2584",
        "model":"1998",
        "type":"MAHINDRA.BOLERO_PICKUP",
        "tankCapacity":"2000",
        "suctionType":"SEWER_SUCTION_MACHINE",
        "pollutionCertiValidTill":1611584416772,
        "InsuranceCertValidTill":1611584416772,
        "fitnessValidTill":1611584416772,
        "roadTaxPaidTill":1611584416772,
        "gpsEnabled":true,
        "source":"Municipal records",
        "owner": {

            "tenantId": "pb.amritsar",
            "name": "DSOc3",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146617
        }
    }],
        "drivers": [{

            "tenantId": "pb.amritsar",
            "name": "DriverDSO4",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146216
        },{

            "tenantId": "pb.amritsar",
            "name": "DriverDSO3",
            "fatherOrHusbandName": "Phani",
            "relationship": "FATHER",
            "gender": "MALE",
            "dob": 550261800000,
            "emailId": "test@dso.test",
            "correspondenceAddress": "KPHB",
            "mobileNumber": 8919146216
        }],
        "source": "WhatsApp"
    }
}'

Integration Details

Integration Scope

Any system or DIGIT module can integrated with Vendor Service, which helps to manage the Vendor with the vehicles, drivers and owner for the representative and login for the representative/owner to log into the system to carry our role-specific operations

Integration Benefits

• Validation of DSO/Vendor availability

• Fetch the vehicle assigned to the DSO

• Fetch the Drivers assigned to the DSO

Integration Steps

• FSM to call vendor/v1/_search to fetch the DSOs

• FSM can call vendor/v1/_search to fetch the DSOs and the respective vehicles and drivers

Reference Docs

API List

Overview

eChallan system enables employees to generate the challans for Adhoc services so that the payment can be recorded into the system along with service-specific details.

It also enables citizens to make payments online based on challan numbers.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has an eChallan persister config path added to it

• PSQL server is running and a database is created to store eChallan data

Key Functionalities

• Allow employees to capture service details for miscellaneous services and collect payment

• Allow employees to update/cancel challan

• Search, download, and print echallan / bill for miscellaneous service

• Generate and view echallan / bill pdf for all miscellaneous and ad-hoc services

• Send an SMS and an email bill notification to the citizen with a payment link and bill link

Configuration Details

Actions & Role Action Mapping

Actions

Role Action Mapping

Roles available:

Localization:

Deployment Details

1. Add MDMS configurations required for eChallan Service and calculator and restart the MDMS service.

2. Deploy the latest version of eChallan Service and calculator.

3. Add eChallan Service persister yaml path in persister configuration and restart persister service.

4. Add Role-Action mapping for APIs.

5. Add pdf configuration file for challan and bill.

Integration Details

Integration Scope

The eChallan service is used to generate e-challans / bills for all miscellaneous/ad-hoc services which citizens avail from ULBs.

Integration Benefits

• Can perform service-specific business logic without impacting the other module.

• Allows capturing the unique identifier of the entity for which the challan is generated.

• In the future, if we decide to make the application accessible to citizens, it can be done effortlessly.

• Workflow or service-specific workflow can be enabled at the challan service level at any time, without the need for any design changes.

• Allow employees to update/cancel challan.

Integration Steps

1. To integrate, you need to overwrite the host of the echallan-services module in the Helm chart.

2. echallan-services/eChallan/v1/_create should be added as the create endpoint for creating eChallan in the system.

3. echallan-services/eChallan/v1/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria.

4. echallan-services/eChallan/v1/_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.

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore the same link is added in each row).

Overview

One of the major applications of the eGov stack is that it helps municipalities and citizens handle property tax payments and other related functions on the property such as assessments, mutation, and so on.

Pre-requisites

1. Prior knowledge of Java/J2EE

2. Prior knowledge of Spring Boot

3. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

4. Prior knowledge of Git

5. Prior knowledge of the demand-based systems

6. The following services should be up and running:

   • user

   • MDMS

   • Persister

   • Location

   • Localization

   • Id-Gen

   • Billing-service

   • URL-shortener

Key Functionalities

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 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, and searched followed by the process of Mutation and Assessment.

• The same entry in the registry can be referred to by other modules for various business purposes (Water charges).

Configuration Details

Persister File Configuration

Workflow Configurations

Each flow in the property has a workflow associated with it, which can be controlled by following configurations.

The Boolean field can enable/disable Workflow - the same field controls the update and creates the workflow.

Workflow configuration for a property is created if the source is from the WATER CONNECTION module.

Use Case 1, which involves property creation from the Water and Sewerage module, necessitates a single-step workflow. In the MDMS file mentioned above, ensure that the businessService with PT.CREATEWITHWNS object is enabled, allowing the field to be set as true. Property creation from the Water and Sewerage module will feature a one-step workflow, for properties in an ACTIVE state.

Fields in the above MDMS file:

Note: Each object mentioned above represents a specific use case outlined in this ticket. Therefore, only one object (use case) enable field should be set to true at any given time.

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 notifications 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

Integration Details

Integration Scope

Property service can be integrated with any organization or system that wants to maintain a record of the property and collect taxes with ease.

Integration Benefits

• 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.

Integration Steps

1. Customers can create a property using the /property/_create

2. Search the property using /property/_searchendpoint

3. /property/_update endpoint to update the property demand as needed.

4. Mutation can be carried out with the help of /property/_update itself, no extra API is required.

Reference Docs

Doc Links

API LIST

Overview

Apportion service is used to apportion the amount paid against a bill among the different tax heads based on the implemented algorithm. The default algorithm uses the order of the tax head to apportion, the tax head with the lowest order is apportioned off first while the highest-order tax head is apportioned last.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• The Kafka server is up and running

• egov-persister service is running and has an apportioned persister configuration path added to it

• PSQL server is running and a database is created to store apportion audit data

Key Functionalities

• Apportion payment in tax heads of bill

• Apportion advance amount in tax heads of demand during demand creation

Deployment Details

1. Deploy the latest version of the egov-apportion-service service

2. Add apportion persister yaml path in persister configuration

Configuration Details

There is no separate configuration required. The TaxHead master that is configured in billing service is only used

Integration Details

Integration Scope

Any payment service which wants to divide the paid amount into different tax head buckets can integrate with the apportion service.

Integration Benefits

• Apportions amount in tax heads

Integration Steps

1. To integrate, the host of egov-apportion-service should be overwritten in the helm chart

2. /apportion-service/v2/bill/_apportion should be called to apportion the bill

3. /apportion-service/v2/demand/_apportion should be called to apportion advance amount in demands

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)

Overview

Water Calculator Service is used to create meter readings, search meter readings, update existing meter readings, calculate water charges, generate demand, notify ULB officials using SMS & email on-demand generation and estimation of water charges (one-time cost) which involves costs like road-cutting charge, form fee, scrutiny fee, etc.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

1. Java 8

2. The Kafka server is up and running

3. egov-persister service is running and has the water service persister configs path added to it

4. PSQL server is running and a database is created to store water connection/application data

5. The following services should be up and running:

   • egov-perister

   • egov-mdms

   • ws-services

   • billing-service

Key Functionalities

• Calculate water charges and taxes based on the billing slab

• Calculate meter reading charge for water connection

• Generate demand

• Scheduler for generating the demand (for non-metered connection)

Deployment Details

1. Deploy the latest version of ws-service and ws-calculator

2. Add water-persist.yml & water-meter.yml files in the config folder in git and add that path in persister. (Add the file path to the environment YAML file under a parameter named "persist-yml-path").

Configuration Details

MDMS Configuration

Billing Slabs

Criteria

1. connection type

2. building type

3. calculation attribute

4. property usage type

The above combination is used to define the billing slab. Billing Slab is defined in MDMS under the ws-services-calculation folder with the WCBillingSlab. Find below a sample slab.

  {
      "id": "1",
      "buildingType": "RESIDENTIAL",
      "connectionType": "Metered",
      "calculationAttribute": "Water consumption",
      "minimumCharge": 100,
      
      "slabs": [
        {
          "from": 0,
          "to": 10,
          "charge": 2,
          "meterCharge": 50
        },
        {
          "from": 10,
          "to": 20,
          "charge": 2.5,
          "meterCharge": 50
        },
        {
          "from": 20,
          "to": 30,
          "charge": 8,
          "meterCharge": 150
        },
        {
          "from": 30,
          "to": 40,
          "charge": 12,
          "meterCharge": 150
        },
        {
          "from": 40,
          "to": 1000000000,
          "charge": 15,
          "meterCharge": 150
        }
      ]
    },
    {
      "id": "5",
      "buildingType": "RESIDENTIAL",
      "calculationAttribute": "No. of taps",
      "connectionType": "Non Metered",
      
      "minimumCharge": 100,
      "slabs": [
        {
          "from": 0,
          "to": 1000000000,
          "charge": 100
        }
      ]
    },

Depending on the matching criteria for the water connection, the calculation applies the specified slab.

Estimation:

For the one-time fee application, the estimation will return all related tax heads based on criteria. All configurations for estimation are present in ws-services-calculation.

1. FeeSlab.json

2. PlotSizeSlab.json

3. RoadType.json

The above master configuration is used for estimation.

Following are the exemptions and taxes that are calculated:

• Form fee

• Scrutiny fee

• Meter charge (For metered connection)

• Other charges

• Road cutting charges

• One time fee

• Security charges

• Tax and cess

Water Charge and Tax:

The billing slab determines the water charges. Water application charges are based on the slab and tax calculations are based on the master configuration.

Interest:

Below is a sample of the master data JSON for interest :

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Interest": [
    {
      "rate": 5,
      "minAmount": null,
      "applicableAfterDays":0,
      "flatAmount": null,
      "maxAmount": null,
      "fromFY": "2019-20",
      "startingDay": "1/01/2019"
    }
  ]
}

Penalty:

Below is a sample of the master data JSON for penalty:

{
  "tenantId": "pb",
  "moduleName": "ws-services-calculation",
  "Penalty": [
    {
      "rate": 10,
      "minAmount": null,
      "applicableAfterDays": 0,
      "flatAmount": null,
      "fromFY": "2019-20",
      "startingDay": "1/01/2019"
    }
  ]
}

Round Off:

If the fraction is greater than equal to 0.5 the number is rounded up else it’s rounded down. For example, 100.4 is rounded to 100 while 100.6 is rounded to 101.

Actions & Role Action Mapping

Actions

[
  {
      "id": {{PLACEHOLDER1}},
      "name": "Bulk Demand Generation",
      "url": "/ws-calculator/waterCalculator/_bulkDemand",
      "parentModule": "",
      "displayName":"Bulk Demand Generation",
      "orderNumber": 1,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER2}},
      "name": "Demand Calculation",
      "url": "/ws-calculator/waterCalculator/_calculate",
      "parentModule": "",
      "displayName": "Demand Calculation",
      "orderNumber": 2,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER3}},
      "name": "Meter Demand Calculation",
      "url": "/ws-calculator/meterConnection/_create",
      "parentModule": "",
      "displayName": "Meter Demand Calculation",
      "orderNumber": 3,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER4}},
      "name": "Meter Demand search",
      "url": "/ws-calculator/meterConnection/_search",
      "parentModule": "",
      "displayName": "Meter Demand search",
      "orderNumber": 3,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    },
    {
      "id": {{PLACEHOLDER5}},
      "name": "Demand Estimate",
      "url": "/ws-calculator/waterCalculator/_estimate",
      "parentModule": "",
      "displayName": "Demand Estimate",
      "orderNumber": 2,
      "enabled": false,
      "serviceCode": "ws-services",
      "code": "null",
      "path": ""
    }
]

Role Action Mapping

[
    {
      "rolecode": "BULK_DEMAND_PROCESSING",
      "actionid": {{PLACEHOLDER1}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BULK_DEMAND_PROCESSING",
      "actionid": {{PLACEHOLDER2}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BULK_DEMAND_PROCESSING",
      "actionid": {{PLACEHOLDER3}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "BULK_DEMAND_PROCESSING",
      "actionid": {{PLACEHOLDER4}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "COLLECTION_OPERATOR",
      "actionid": {{PLACEHOLDER4}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER4}},
      "actioncode": "",
      "tenantId": "pb"
    },
    {
      "rolecode": "GP_ADMIN",
      "actionid": {{PLACEHOLDER5}},
      "actioncode": "",
      "tenantId": "pb"
    }
]

Demand Generation

Once water is sent to the calculator, its tax estimates are calculated. Using these tax head estimates, demand details are created. For every tax head, the estimated demand generates a corresponding demand detail.

When the _calculate API is called, demand is first searched based on the connection number or application number and the demand period. If demand already exists, it is updated with the new information. Otherwise, a new demand is generated for the financial year period.

During an update, if the tax head estimates change, the difference in amount for that tax head is added as a new demand detail. For example, if the initial demand has one demand detail with WATER_CHARGE equal to 120.

"demandDetails": [
                {
                    "id": "77ba1e93-a535-409c-b9d1-a312c409bd45",
                    "demandId": "687c3176-305b-461d-9cec-2fa26a30c88f",
                    "taxHeadMasterCode": "WATER_CHARGE",
                    "taxAmount": 120,
                    "collectionAmount": 120,
                    "additionalDetails": null,
                    "auditDetails": {
                        "createdBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "lastModifiedBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "createdTime": 1583675275873,
                        "lastModifiedTime": 1583675298705
                    },
                    "tenantId": "pb.amritsar"
                }
            ],

After updating if the WATER_CHARGE increases to 150 we add one more demand detail to account for the increased amount. The demand detail will be updated to:

"demandDetails": [
                {
                    "id": "77ba1e93-a535-409c-b9d1-a312c409bd45",
                    "demandId": "687c3176-305b-461d-9cec-2fa26a30c88f",
                    "taxHeadMasterCode": "WATER_CHARGE",
                    "taxAmount": 120,
                    "collectionAmount": 0,
                    "additionalDetails": null,
                    "auditDetails": {
                        "createdBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "lastModifiedBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "createdTime": 1583675275873,
                        "lastModifiedTime": 1583675298705
                    },
                    "tenantId": "pb.amritsar"
                },
                {
                    "id": "0d83f4b0-6442-11ea-bc55-0242ac130003 ",
                    "demandId": "687c3176-305b-461d-9cec-2fa26a30c88f",
                    "taxHeadMasterCode": "WATER_CHARGE",
                    "taxAmount": 30,
                    "collectionAmount": 0,
                    "additionalDetails": null,
                    "auditDetails": {
                        "createdBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "lastModifiedBy": "04956309-87cd-4526-b4e6-48123abd4f3d",
                        "createdTime": 1583675275873,
                        "lastModifiedTime": 1583675298705
                    },
                    "tenantId": "pb.amritsar"
                }
            ],

Round-off in the bill is based on the total amount, ensuring that the payable amount is a whole number. Each WS_ROUNDOFF in the demand detail can be greater than 0.5, but the sum of all WS_ROUNDOFF values is always less than 0.5.

Demand Generation Scheduler (For Non-metered Connection)

Description

To generate demand for non-metered connections, we have a feature for batch demand generation. The scheduler is responsible for generating demand based on the tenant.

• The scheduler can be triggered using the scheduler API, scheduled as a cron job, or configured in Kubectl to hit the scheduler based on the configuration.

• After the scheduler is triggered, we can search for the list of tenants (cities) in the database.

• After obtaining the list of tenants, iterate through the list and generate the demand for specific tenants.

• Load the consumer codes for the tenant and push the calculation criteria to Kafka. The calculation criteria contain minimal information, including the consumer code and one boolean variable.

• After pushing the data into Kafka, the system consumes the records based on the batch configuration. For example, if the batch configuration is set to 50, the system will consume 50 calculation criteria at a time.

• After consuming the records (calculation criteria), the system processes the batch to generate the demand. If the batch processing is successful, the processed consumer codes are logged.

• If some records fail in the batch, the system pushes the batch into the dead letter batch topic. From there, the batch is processed one record at a time.

• If the record is successful, the system logs the consumer code. If the record fails, the data is pushed into a dead-letter single topic.

• Dead letter single topic contains information about failure records in Kafka.

Use cases:

1. If the same job triggers multiple times what will happen?

If the same job triggers multiple times the system processes it again as mentioned above but at the demand level, it checks the demand based on consumer code and billing period. In case the demand already exists then it updates the demand or else creates the demand.

1. 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 consumers. This configuration determines how much data is processed at a time.

ws.demand.based.batch.size=10

Integration Details

Integration Scope

The ws-calculator is integrated with ws-service. ws-services internally invoke the ws-calculator service to calculate and generate demand for the charges.

Integration Benefits

WS calculator application is used to calculate the water application one-time fees and meter reading charges based on the different billing slabs. That's why the calculation and demand generation logic is separated from the WS service. So in future, if calculation logic requires modification the changes can be carried out for each implementation without modifying the WS service.

Integration Steps

1. Once the water connection is activated for the metered connection, the employee can add meter reading details using the API - /ws-calculator/meterConnection/_create. This generates the demand. For non-metered connections, the scheduler APIs should be called periodically to generate the demand.

2. For the metered connection service, the /meterConnection/_search API is used to get the previous meter reading,

3. To activate the Water Service application, the user has to pay the ONE_TIME_FEE for the connection. To calculate this fee, the ONE_TIME_FEE /waterCalculator/_estimate API is used.

4. To generate the demand for metered or non-metered water connection /waterCalculator/_calculate API is used.

5. Users can pay partial/full/advance amounts for the metered or non-metered connection bill. In such cases, the billing service would call back /waterCalculator/_updateDemandAPI to update the demand-generated details.

6. /waterCalculator/_jobscheduler API is used to generate demand for non-metered connections. This API can be called periodically.

7. /waterCalculator/_applyAdhocTax API is used to add a Rebate or Penalty on any bill and based on that the bill amount is adjusted.

Reference Docs

Doc Links

API List

(Note: All the APIs are in the same Postman collection therefore the same link is added in each row).

Overview

The main objective of the billing module is to serve the Bill for all revenue Business services. To serve the Bill, Billing-Service requires demand. Demands will be prepared by Revenue modules and stored by billing based on which it will generate the Bill.

Pre-requisites

1. Prior knowledge of Java/J2EE.

2. Prior knowledge of Spring Boot.

3. Prior knowledge of KAFKA

4. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

5. Prior knowledge of the demand-based systems.

6. The following services should be up and running:

   • user

   • MDMS

   • Id-Gen

   • URL-Shortening

   • notification-sms

Key Functionalities

• eGov billing service creates and maintains demands.

• Generates bills based on demands.

• Updates the demands from payment when the collection service takes a payment.

Deployment Details

• Deploy the latest image of the billing service available.

Configuration Details

In the MDMS data configuration, the following master data is needed for the functionality of billing

MDMS Configuration

Business Service JSON

TAX-Head JSON

Tax-Period JSON

Integration Details

Integration Scope

Billing service can be integrated with any organization or system that wants a demand-based payment system.

Integration Benefits

• Easy to create and simple process of generating bills from demands

• The amalgamation of bills period-wise for a single entity like PT or Water connection.

• Amendment of bills in case of legal requirements.

Integration Steps

1. Customers can create a demand using the /demand/_create

2. Organizations or system can search the demand using /demand/_searchendpoint

3. Once the demand is raised the system can call /demand/_update endpoint to update the demand as per need.

4. Bills can be generated using, which is a self-managing API that generates a new bill only when the old one expires /bill/_fetchbill.

5. Bills can be searched using /bill/_search.

6. Amendment facility can be used in case of a legal issue to add values to existing demands using /amendment/_create and /amendment/_update can used to cancel the created ones or update workflow if configured.

Interaction Diagram

Interaction Diagram V1.1

Reference Docs

Doc Links

API List

Apportioning

What is apportioning?

Adjusting the receivable amount with the individual tax head.

Types of apportioning V1.1:

Default order-based apportioning(Based on apportioning order adjust the received amount with each tax head).V1.1

Types of apportioning V1.2:

• Proportionate-based apportioning (Adjust total receivable with all the tax heads equally)

• Order & Percentage-based apportioning(Adjust total receivable based on order and the percentage which is defined for each tax head).

Principle of apportioning:

The basic principle of apportioning is, that if the full amount is paid for any bill then each tax head should get nullified with their corresponding adjusted amount.

Example: Case 1: When there are no arrears all tax heads belong to their current purpose:

Case 2: Apportioning with two years of arrear: If the current financial year is 2014-15. Below are the demands

If any payment is not done, and we generate demand in 2015-16 then the demand structure will be as follows: