Overview

DIGIT is API based Platform here each API is denoting to a DIGIT resource. Access Control Service (ACS) primary job is to authorise end-user based on their roles and provide access to the DIGIT platform resources. Access control functionality basically works based on below points:

Actions: Actions are events which are performed by a user. This can be an API end-point or Frontend event. This is MDMS master

Roles: Role are assigned to the user, a user can hold multiple roles. Roles are defined in MDMS masters.

Role-Action: Role actions are mapping b/w Actions and Roles. Based on role, action mapping access control service identifies applicable action for the role.

Pre-requisites

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

• Java 8

• MDMS service is up and running

Key Functionalities

• Serve the applicable actions for a user based on user role (To print menu three).

• On each action which is performed by a user, access control looks at the roles for the user and validate actions mapping with the role.

• Support tenant-level role-action. For instance, an employee from Amritsar can have a role of APPROVER for other ULB like Jalandhar and hence will be authorised to act as APPROVER in Jalandhar.

Deployment Details

1. Deploy the latest version of Access Control Service

2. Deploy MDMS service to fetch the Role Action Mappings

Configuration Details

Define the roles

{
      "code": "EMPLOYEE",
      "name": "Employee",
      "description": "Default role for all employees"
}

Add the Actions (URL)

{
      "id": {{ACTION_ID}},
      "name": "Create TradeLicense",
      "url": "/tl-services/v1/_create",
      "parentModule": "",
      "displayName": "Create TradeLicense",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "tl-services",
      "code": "null",
      "path": ""
}

Add the role action mapping

{
      "rolecode": "EMPLOYEE",
      "actionid": {{ACTION_ID}},
      "actioncode": "",
      "tenantId": "pb"
    }

(The details about the fields in the configuration can be found in the swagger contract)

Integration Details

Integration Scope

Any microservice which requires authorisation can leverage the functionalities provided by access control service.

Integration Benefits

Any new microservice that is to be added in the platform won’t have to worry about authorisation. It can just add it’s role action mapping in the master data and Access Control Service will perform authorisation whenever API for the microservice is called.

Steps to Integration

1. To integrate with Access Control Service the role action mapping has to be configured(added) in the MDMS service.

2. The service needs to call /actions/_authorize API of Access Control Service to check for authorisation of any request

Interaction Diagram

Reference Docs

Doc Links

API List

Core Services is one of the key DIGIT components. Browse through this section to learn more about the key configuration and integration details of these core services.

• Workflow Services

• Location Services

• User Services

• Access Control Services

This section contains the configuration documents related to the DIGIT service stack.

Click on the respective service link below to find its configuration details and additional information resources.

• Core Services

• Business Services

• Municipal Services

• Utilities

Overview

Workflows are a series of steps that moves a process from one state to another state by actions performed by different kind of Actors - Humans, Machines, Time based events etc. to achieve a goal like onboarding an employee, or approve an application or grant a resource etc. The egov-workflow-v2 is a workflow engine which helps in performing these operations seamlessly using a predefined configuration.

Pre-requisites

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 workflow persister config path added in it

• PSQL server is running and database is created to store workflow configuration and data

Key Functionalities

• Always allow anyone with a role in the workflow state machine to view the workflow instances and comment on it

• On the creation of workflow, it will appear in the inbox of all employees that have roles that can perform any state transitioning actions in this state.

• Once an instance is marked to an individual employee it will appear only in that employee's inbox although point 1 will still hold true and all others participating in the workflow can still search it and act if they have necessary action available to them

• If the instance is marked to a person who cannot perform any state transitioning action, they can still comment/upload and mark to anyone else.

• Overall SLA: SLA for the complete processing of the application/Entity

• State-level SLA: SLA for a particular state in the workflow

Interaction Diagram

Deployment Details

1. Deploy the latest version of egov-workflow-v2 service

2. Add businessService persister yaml path in persister configuration

3. Add Role-Action mapping for BusinessService API’s

4. Overwrite the egov.wf.statelevel flag ( true for state level and false for tenant level)

5. Create businessService (workflow configuration) according to product requirements

6. Add Role-Action mapping for /processInstance/_search API

7. Add workflow persister yaml path in persister configuration

Configuration Details

For Configuration details please refer to the links in Reference Docs

Integration Details

Integration Scope

The workflow configuration can be used by any module which performs a sequence of operations on an application/Entity. It can be used to simulate and track processes in organisations to make it more efficient too and increase accountability.

Integration Benefits

• Role-based workflow

• An easy way of writing rule

• File movement within workflow roles

Steps to Integration

1. To integrate, host of egov-workflow-v2 should be overwritten in helm chart

2. /process/_search should be added as the search endpoint for searching workflow process Instance object.

3. /process/_transition should be added to perform an action on an application. (It’s for internal use in modules and should not be added in Role-Action mapping)

4. The workflow configuration can be fetched by calling _search API to check if data can be updated or not in the current state

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

Overview

The URL shortening service is used to shorten long URLs. There may be requirement when we want to avoid sending very long urls to the user via SMS, Whatsapp etc, this service compresses the URL.

Pre-requisites

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

1. Prior Knowledge of Java/J2EE

2. Prior Knowledge of SpringBoot

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

Key Functionalities

1. Compress long URLs.

2. Converted short URLs contains id, which is used by this service to identify and get longer URLs.

Deployment Details

• Deploy latest version of URL Shortening service

API Details

a) POST /egov-url-shortening/shortener

Receive long urls and converts them to shorter urls. Shortened urls contains urls to endpoint mentioned next. When user clicks on shortened URL, user is redirected to long URL.

b) GET /{id}

This shortened urls contains path to this endpoint. The service uses id used in last endpoint to get long URL. As response the user is redirected to long URL.

Reference Docs

Doc Links

Overview

The objective of PDF generation service is to bulk generate pdf as per requirement.

Pre-requisites

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

• Install npm.

• Kafka server is up and running.

• egov-persister service is running and has pdf generation persister config path added in it.

• PSQL server is running and the database is created to store filestore id and job id of generated pdf.

Key Functionalities

• Provide a common framework to generate PDF.

• Provide flexibility to customise the PDF as per the requirement.

• Provide functionality to add an image, Qr Code in PDF.

• Provide functionality to generate pdf in bulk.

• Provide functionality to specify a maximum number of records to be written in one PDF.

External Libraries used :

• Mustache.js: (https://github.com/janl/mustache.js/ ):- as templating engine to populate format as defined in format config, from request json based on mappings defined in data config

Interaction Diagram

Deployment Details

1. Create data config and format config for a PDF according to product requirement.

2. Add data config and format config files in PDF configuration

3. Add the file path of data and format config in the environment yml file

4. Deploy the latest version of pdf-service in a particular environment.

Configuration Details

For Configuration details please refer to Customizing PDF Receipts & Certificates.

Integration

Integration Scope

The PDF configuration can be used by any module which needs to show particular information in PDF format that can be print/downloaded by the user.

Integration Benefits

• Functionality to generate PDFs in bulk.

• Avoid regeneration.

• Support QR codes and Images.

• Functionality to specify the maximum number of records to be written in one PDF.

• Uploading generated PDF to filestore and return filestore id for easy access.

Steps to Integration

1. To download and print the required PDF _create API has to be called with the required key (For Integration with UI, please refer to the links in Reference Docs)

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

Overview

A core application which provides location details of the tenant for which the services are being provided.

Pre-requisites

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

• Java 8

• PSQL server is running and database is created

• Knowledge of egov-mdms service

• egov-mdms service is running and all the required mdms master are loaded in it

Key Functionalities

• The location information is also known as boundary data of ULB

• Boundary data can be of different hierarchies ADMIN, ELECTION hierarchy which is defined by the Administrators, Revenue hierarchy defined by the Revenue department.

• The election hierarchy has the locations divided into several types like zone, election ward, block, street and locality. The Revenue hierarchy has the locations divided into a zone, ward, block and locality.

• The model which defines the localities like zone, ward and etc is boundary object which contains information like name, lat, long, parent or children boundary if any. The boundaries come under each other in a hierarchy like a zone contains wards, ward contains blocks, a block contains locality. The order in which the boundaries are contained in each other will differ based on the tenants.

Deployment Details

1. Add/Update the mdms master file which contain boundary data of ULB’s.

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

3. Deploy/Redeploy the latest version of egov-mdms service.

4. Fill the above environment variables in egov-location with proper values.

5. Deploy the latest version of egov-location service.

Configuration Details

The boundary data has been moved to mdms from the master tables in DB. The location service fetches the JSON from mdms and parses it to the structure of boundary object as mentioned above. A sample master would look like below.

{
  "tenantId": "pg.cityA",
   "moduleName": "egov-location",
  "TenantBoundary": [
  {
      "hierarchyType": {
              "code": "ADMIN",
              "name": "ADMIN"
      },
       "boundary": {
                "id": 1,
                "boundaryNum": 1,
                "name": "CityA",
                "localname": "CityA",
                "longitude": null,
                "latitude": null,
                "label": "City",
                "code": "pg.cityA",
                "children": []
        }

    }
 ]
}

Integration

Integration Scope

The egov-location API’s can be used by any module which needs to store the location details of the tenant.

Integration Benefits

• Get the boundary details based on boundary type and hierarchy type within the tenant boundary structure.

• Get the geographical boundaries by providing appropriate GeoJson.

• Get the tenant list in the given latitude and longitude.

Steps to Integration

1. To integrate, host of egov-location should be overwritten in helm chart.

2. /boundarys/_search should be added as the search endpoint for searching boundary details based on tenant Id, Boundary Type, Hierarchy Type etc.

3. /geography/_search should be added as the search endpoint .This method handles all requests related to geographical boundaries by providing appropriate GeoJson and other associated data based on tenantId or lat/long etc.

4. /tenant/_search should be added as the search endpoint. This method tries to resolve a given lat, long to a corresponding tenant, provided there exists a mapping between the reverse geocoded city to tenant.

5. The MDMS Tenant boundary master file should be loaded in MDMS service.

Reference Docs

Doc Links

API List

Please refer to the Swagger API contract for egov-location service to understand the structure of APIs and to have a visualisation of all internal APIs.

Overview

User service is responsible for user data management and providing functionality to login and logout into Digit system

Pre-requisites

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

• Java 8

• Kafka server is up and running

• Encryption and MDMS services are running

• PSQL server is running and database

• Redis is running

Key Functionalities

• Store, update and search user data

• Provide authentication

• Provide login, logout functionality into DIGIT platform

• Store user data PIIs in encrypted form

Interaction Diagram

Deployment Details

1. Setup latest version of egov-enc-service and egov-mdms- service

2. Deploy the latest version of egov-user service

3. Add Role-Action mapping for API’s

Configuration Details

Following application properties file in user service are configurable.

Integration Details

Integration Scope

User data management and functionality to login and logout into Digit system using OTP and password.

Integration Benefits

Providing following functionality to citizen and employee type users

• Employee:

  • User registration

  • Search user

  • Update user details

  • Forgot password

  • Change password

  • User role mapping(Single ULB to multiple roles)

  • Enable employee to login into DIGIT system based on a password.

• Citizen:

  • Create user

  • Update user

  • Search user

  • User registration using OTP

  • OTP based login

Steps to Integration

• To integrate, host of egov-user should be overwritten in the helm chart.

• Use /citizen/_create and /users/_createnovalidate endpoints for creating users into the system

• Use /v1/_search and /_search endpoints to search users in the system depending on various search parameters

• Use /profile/_update for partial update and /users/_updatenovalidate for update

• Use /password/nologin/_update for otp based password reset and /password/_update for logged in user password reset

• Use /user/oauth/token for generating token, /_logoutfor logout and /_details for getting user information from his token

Reference Docs

Doc Links

API List

Overview

Indexer service runs as a separate service. This service is designed to perform all the indexing tasks of the digit platform. The service reads records posted on specific kafka topics and picks the corresponding index configuration from the yaml file provided by the respective module. Objective of Indexer service are listed as below.

• To provide a one stop framework for indexing the data to elasticsearch.

• To create provision for indexing live data, reindexing from one index to the other and indexing legacy data from the datastore.

Pre-requisites

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

1. Prior Knowledge of Java/J2EE

2. Prior Knowledge of SpringBoot

3. Prior Knowledge of Elasticsearch

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

5. Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic etc.

Key Functionalities

• Performs three major tasks namely: LiveIndex, Reindex and LegacyIndex.

• LiveIndex: Task of indexing the live transaction data on the platform. This keeps the es data in sync with the db.

• Reindex: Task of indexing data from one index to the other. ES already provides this feature, indexer does the same but with data transformation.

• LegacyIndex: Task of indexing legacy data from the tables to ES.

• Provides flexibility to index the entire object, a part of the object or an entirely different custom object all using one input json from modules.

• Provides features for customizing index json by field mapping, field masking, data enrichment through external APIs and data denormalization using MDMS.

• One stop shop for all the es index requirements with easy-to-write and easy-to-maintain configuration files.

• Designed as a consumer to save API overhead. The consumer configs are written from scratch to have complete control over the consumer behaviour.

Deployment Details

• Step 1: Write configuration as per your requirement. Structure of the config file is explained later in the same doc.

• Step 3: 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 egov-indexer's environment manifest file for it to be read at start-up of the application.

• Step 4: Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.

Interaction Diagram

Configuration Details

For Indexer Configuration, please refer to the document in Reference Docs table given below.

API Details

a) POST /{key}/_index

Receive data and index. There should be a mapping with topic as {key} in index config files.

b) POST /_reindex

This is used to migrate data from one index to another index

c) POST /_legacyindex

This is to run LegacyIndex job to index data from DB. In the request body the URL of the service which would be called by indexer service to pick data, must be mentioned.

Reference Docs

Doc Links

eGov Payment Gateway acts as a liaison between eGov apps and external payment gateways facilitating payments, reconciliation of payments and lookup of transactions' status'.

Pre-requisites

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 pg service persister config path added in it

• PSQL server is running and the database is created to store transaction data.

Key Functionalities

• Create or initiate a transaction, to make a payment against a bill.

• Make payment for multiple bill details [multi module] for a single consumer code at once.

• Transaction to be initiated with a call to the transaction/_create API, various validations are carried out to ensure the sanctity of the request.

• The response includes a generated transaction id and a redirect URL to the payment gateway itself.

• Various validations are carried out to verify the authenticity of the request and the status is updated accordingly. If the transaction is successful, a receipt is generated for the same.

Payment Flow

Reconciliation

• Reconciliation is carried out by two jobs scheduled via a Quartz clustered scheduler.

• Early Reconciliation job is set to run every 15 minutes [configurable via app properties], and is aimed at reconciling transactions which were created 15 - 30 minutes ago and are in PENDING state.

• Daily Reconciliation job is set to run once per day and is aimed at reconciling all transactions that are in PENDING state, except for ones which were created 30 minutes ago.

Extensions

• Axis, Phonepe and Paytm payment gateways are implemented.

Configuration Details

Following properties in the application.properties file in egov-pg-service has to be added and set to default value after integrating with the new payment gateway. In the below table properties for AXIS bank, payment gateway is shown the same relevant property needs to be added for other payment gateways.

Deployment Details

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

2. Add pg service persister yaml path in persister configuration

Integration Details

Integration Scope

The egov-pg-service acts as communication/contact between eGov apps and external payment gateways.

Integration Benefits

• Record of every transaction against a bill.

• Record of payment for multiple bill details for a single consumer code at once.

Steps to Integration

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

2. /pg-service/transaction/v1/_create should be added in the module to initiates a new payment transaction, on successful validation

3. /pg-service/transaction/v1/_update should be added as the update endpoint to updates an existing payment transaction. This endpoint is issued only by payment gateways to update the status of payments. It verifies the authenticity of the request with the payment gateway and forward all query params received from a payment gateway

4. /pg-service/transaction/v1/_search should be added as the search endpoint for retrieving the current status of a payment in our system.

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection, therefore, the same link is added in each row)

Overview

One of the applications in the Digit core group of services aims to reduce the time spent by developers on writing codes to store and fetch master data ( primary data needed for module functionality ) which doesn’t have any business logic associated with them. Instead of writing APIs, creating tables in every different service to store and retrieve data that is seldom changed MDMS service keeps them at a single location for all modules and provides data on will with the help of no more than three lines of configuration.

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. Advanced knowledge on how to operate JSON data would be an added advantage to understand the service.

Key Functionalities

• Adds master data for usage without the need to create master data APIs in every module.

• Reads data from GIT directly with no dependency on any database services.

Deployment Details

1. Deploy the latest version of Mdms-service

2. Add conf path for the file location

3. Add master config JSON path

Integration Details

Integration Scope

The MDMS service provides ease of access to master data for any service.

Integration Benefits

• No time spent writing repetitive codes with no business logic.

Steps to Integration

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

2. egov-mdms-service/v1/_search should be added as the search endpoint for searching master data.

3. Mdms client from eGov snapshots should be added as mvn entity in pom.xml for ease of access since it provides mdms request pojos.

Reference Docs

API List

Whenever any user logs an authorization token and a refresh token is generated for him. Using the auth token the client can make rest API calls to the server to fetch data. The auth token has an expiry period. Once the auth token is expired it cannot be used to make API calls. The client will have to generate a new authorization token. This is done by authenticating the refresh token with the server which then generates and sends new authorization token to the client. The refresh token avoids the need for the client to again login whenever Auth token expires.

Refresh token also has an expiry period and once it gets expired it cannot be used to generate new authorization token and the user will have to login again to get a new pair of authorization token and refresh token. Generally, the duration before the expiry of the refresh token is much longer compared to that of auth token. If the user logs out of the account both Auth token and the refresh token will become invalid.

Environment variables to configure expiry time

API

`

Overview

Goal: To onboard developers onto the XState-Chatbot code base so that they can modify existing flows or create new ones.

This document sticks to explaining the chatbot's core features and does not dive into the use cases implemented by the chatbot. There is another document dedicated to it.

Prerequisites

• NodeJS

• PostgreSQL

• Kafka(optional)

Key Functionalities

• Build a chat flow to facilitate a user to interact with rainmaker modules

• Link a chat flow with backend services

Deployment Details

1. Deploy the latest version of xstate-chatbot

2. Configure /xstate-chatbot to be a whitelisted open endpoint in zuul

3. Add to the egov-indexer to index all the telemetry messages

Overall Philosophy of Chatbot

This chatbot does not have any Natural Language Processing component. In the future, we can extend the chatbot to add such features.

Basic Introduction to XState

XState is a JavaScript implementation of StateCharts. There is detailed documentation available to study XState. Few of the concepts of XState that are used in Chatbot are listed below. Basic knowledge of these concepts is necessary. It can also be learned while going through the chat flow implementation of pilot use cases of PGR and Bills.

2. Actions

   1. onEntry

Few tips about using XState. These have been followed throughout the pilot chat flows.

1. If we want to move to any state which is not at the same hierarchical level, then we should assign it a unique id value. If it has an id value, we can address it using the # qualifier in the target attribute.

2. As id should be unique, please make sure there aren’t multiple states with the same id value. If there is a duplicate, the machine won’t function as expected.

3. Any actions(like onEntry) should be surrounded by assign.

This would include almost all functions except the guard condition code snippets.

Understanding the Chat Flow

All the interactions with the user - sending a message to the user and processing an incoming message from the user is coded as a state in the State Machine. It would be a nice start to test any chat flow with the supplementary react-app provided for the developers to execute the state machine locally. (Please follow the guidelines in the README of the react-app.)

We have followed few standard patterns to code any chat interaction. Please try to follow these patterns to code any new chat flow. These patterns are explained below. You can also study those by browsing through the code of the pilot use cases of PGR and Bills.

1. The chat states would only include dialog-specific code. Any code related to backend service should be written as a part of a separate …-service.js file.

2. Any code that doesn’t include any asynchronous API call can be written as a part of the onEntry function or action.

3. If the function needs to make an API call, that would have to be written with the invoke-on Done pattern. The asynchronous function should be written as a part of the service file. The consolidated data returned by it can be processed in the state of the dialog file.

4. Helper functions are written indialog.jsfile. It is advised to use those functions as much as possible rather than writing any custom logic in dialog files.

Scaffolding

Apart from the chat flow and its backend service API calls, few other components are present in the project. These components do NOT need to be modified to code any new chat flow or changing an existing chat flow. These components with a short description for each are listed below:

1. Session Manager: It manages sessions of all the users on a server. It will store the user’s state in a datastore, update it, and read it when any new message is received on the server. Based on the state of the user, it will create a state machine and send the incoming message event to the state machine. It sanctifies the state (any sensitive data like the name and mobile number of a user are removed) before storing the state to the datastore.

2. Repository: It is the datastore where the states of the users get stored. To reduce dependency, an in-memory repository is also provided, which can be used by configuring an environment variable. So to run the chatbot service, PostgreSQL isn’t a hard dependency, but it is advisable to use the PostgreSQL repo provider.

3. Channel Provider: There can be many different WhatsApp Providers. Any one of the providers will be configured to be used. A separate console WhatsApp Provider is present for the developer to test the chatbot server locally. Postman collection to mimic receiving messages from a user to the server is present in the project directory.

4. Localization: Every message to be sent to the user is stored within the chatbot. Localization service is not being used. These messages are present near the bottom of the dialog files. A separate localization-service.js is provided to get the messages for the localization codes for the messages that are not owned by the chatbot. For example, the PGR complaint types data is under the ownership of the PGR module, and the messages for such can be fetched from the egov-localization-service using the functions provided in the localization-service.js.

5. Service Provider: To ease the initial dialog development, instead of the coding API calls to the backend services, we can configure the chat flow to use a dummy service. This can be configured using an environment variable and modifying the service-loader.js file.

6. Telemetry: Chatbot logs telemetry events to a kafka topic. (Any sensitive data will get masked before indexing the events onto ElasticSearch by egov-indexer.) Following events get logged:

   1. Incoming message

   2. Outgoing message

   3. Transition of state

This section provides technical details about business service setup, configuration, deployment, and API integration.

• Bill Amendment

Details will be updated soon...

Overview

XState-Chatbot is a revamped version of the chatbot, which provides functionality to the user to access PGR module services like file complaint, track complaint, notifications from whats app, It allows the user to view receipts and pay the bills for Property, Trade Licence, FireNOC, Water and Sewerage and BPA service module.

Key Functionalities

• File PGR complaint

• Track PGR complaint

• Support images when filing complaints

• Notifications to citizen when an employee performs any action on the complaint

• Allow user to search and pay bills of different modules.

• Allow user to search and view receipts of different modules.

• Allow user to change the language of their choice to have a better experience.

• Put user interactions on an elastic search for Telemetry.

Integration

Integration Scope

XState chatbot can be integrated with any other module to improve the ease of search and view bills/past payment receipts and to improve speed and convenience for bill payment. It can be integrated with the PGR module for easiness of creation and tracking of the complaint.

Integration Benefits

• Increase in convenience and ease of making the bill payment.

• Increase in no. of users opting for online payment.

• Improvement in demand collection efficiency

• Creating an additional channel for payment.

• Remove dependency on mobile/web app or counter.

Integration Details

Integration of New Whatsapp Provider

Whatsapp provider is a third-party service that works in the middle of a user's WhatsApp client and XState-Chatbot server. All messages coming/going to/from user pass through WhatsApp provider. Chatbot calls WhatsApp provider to send messages to the user. When a user responds with any WhatsApp message the WhatsApp provider calls Chatbot service’s configured endpoint with details ex:- user sent message, sender’s number etc.

If any new WhatsApp provider is to be used with a chatbot, code must be written to convert the provider’s incoming messages to the format that the chatbot understands and also final output from the chatbot should be converted to WhatsApp provider’s API request format.

Currently, the XState-Chatbot service is using ValueFirst as the WhatsApp Provider. This will require provider-specific environment variable to be configured. If the provider changes then, all these environment variable will also change. Few of those environment variables are stored as secrets, so these values need to be configured in env-secrets.yaml.

As this is a revamped version of the chatbot service, all of the secrets should already be present. There is no need to create new secrets.

Integration of PGR complaint feature in XState-Chatbot

The integration of PGR with a chatbot can be enabled and disabled by making changes in this file. By exporting the respective PGR service file, the PGR service feature can be sable and vice versa.

Configuration of PGR version in chatbot

To configure the PGR module to use in Xstate-chatbot - the below variable values need to change in the environment file as per the requirement.

• pgrVersion

• pgrUpdateTopic

To configure PGR v2 in XState chatbot then pgrVersion should be ‘v2' and pgrUpdateTopic should be 'update-pgr-request’.

Adding Information Image in PGR complaint creation

To configure the filestoreid for informational image follow the steps mention below

1. Download this image

2. Upload the image into filestore server. Use the upload file API from this postman collection(https://www.getpostman.com/collections/bdb059c5af698f0d81d6)

3. Mention the filestore id here in the environment file.

Configuration of Compliant status template messages

For Compliant status update notifications to citizen when an employee performs any action on the complaint.

Xstate chatbot is maintaining the template id of each message which gets triggered on the respective status or action performed on the complaint. The template ids are maintained in the environment file. For any new notification, its template id has to mention in the above file.

Each notification in a different language will have different template ids. For example, the complaint resolve notification in English will have template-id as ‘12345' and the same notification in Hindi will have template-id as ‘6789’. The order of mentioning the template id must be the same as the order of the supported locale mentioned in env-variable.js file.

For example:

a) if supportedLocales: process.env.SUPPORTED_LOCALES || 'en_IN,hi_IN'

then valuefirst-notification-resolved-templateid: "12345,6789"

b) if supportedLocales: process.env.SUPPORTED_LOCALES || 'hi_IN,en_IN'

then valuefirst-notification-resolved-templateid: "6789,12345"

Integration of Bill Payment and Receipt Search feature in Xstate-Chatbot

The integration of the Bill payment and receipt search feature with a chatbot can be enabled and disabled by making changes in this file. By exporting the respective bill service and receipt service file, the payment and receipt search feature can be enabled and vice versa.

Configuration of module for Bill payment and Receipt search

To configure the list of modules to appear as an option for payment and receipt, Add the module business service code in the list present in the environment file.

For example: If bill-supported-modules: "WS, PT, TL" then Water and Sewerage, Property, Trade license module would appear for bill payment and receipt search.

Also add the message bundle, validation and service code for locality searcher in egov-bill and egov-receipt file.

Configuration of Xstate-Chatbot localisation message

XState-Chatbot does not have any MDMS data, nor does it store any messages in localization-service. If any message needs to be modified, the changes will have to be made in the source code, then build the new docker image and deploy it. For Configuration details of the XState-chatbot localisation message please refer to the links in Reference Docs.

The table below contains the details about some environment variables use in XState-Chatbot service which is present in this file:

Configuration of Telemetry File

Add this telemetry file in the config repo and mention the filename in the respective environment yaml file.

Reference Docs

Doc Links

API List

Overview

The Collection service is to serve as a revenue collection platform for all the billing systems through cash, cheque, dd, swipe machine. It enables payment for all services provided by the eGov platform at a single point for the Citizen and counter collection in municipal alike.

Pre-requisites

• Prior Knowledge of Java/J2EE

• Prior Knowledge of SpringBoot

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc

• Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic, etc.

• Following services should be up and running:

  • egov-localization

  • egov-mdms

  • egov-idgen

  • egov-url-shortening

  • billing-service

Key Functionalities

• Allows citizens to create a payment.

• Allows employees to create the payment for the citizen indirectly.

• provides facilities to capture partial and advanced payment based on configs.

• allows payment cancellation to help with scenarios of bad checks and other failed payment scenarios.

• Integrates with billing-service for demand back-update of payment.

Deployment Details

• deploy the latest version of the collection-services docker build.

Configuration Details

The MDMS data configuration uses the same data updated by Billing-Service

Billing Service | Configuration-Details: Refer MDMS data config from here.

Following are the properties in the application.properties

Integration

Integration Scope

Collection service can be integrated with any organization or system that wants a payment system to keep track of its payments. Organizations can customize part of the application or its functionality based on their requirements.

Integration Benefits

• Easy payments and tracking of payments.

• Configurable functionalities according to client requirement

Steps to Integration

1. Customer can create a payment using the /payments/_create

2. Actors on the system can keep track of payments using /payments/_searchendpoint

3. Once the payment is done but it encounters a technical issue outside of the system then it can be cancelled with /payments/_workflow

4. For employees to access the payments API the respective module name should be appended after the payment API path - /payments/PT/_workflow - here PT refers to property module.

Interaction Diagram

Billing-Collection-Integration Refer integration with details and explanation.

Reference Docs

Doc Links

API List

Overview

The consumer sometimes needs additional amounts (Amendments) added to their bill due to reasons from outside of the system. The addition of amounts happens with respect to the consumer code of the entity in the product(PT, WS, etc..,), any unpaid demand in the system is a candidate for amendments.

Pre-requisites

• Prior Knowledge of Billing-Service in Digit framework.

Key Functionality

Amendment mainly works with two types of functionality as follows:

• Amendment

• Demand

Bill Amendment provides a separate flow to enable workflow and validation for the process of adding additional amounts into the existing demands which were done through the respective modules only till this point in time. An amendment will be allowed only when the reason arises from out of the system to add or reduce the amount from the existing bill belonging to an entity. The reasons are as listed

1. Court case settlement

2. One time waiver

3. Write-offs

4. DCB correction (Old demands in paid status)

5. Remission for Property Tax

Criteria:

There are certain prerequisites to create an amendment,

1. presence of demand in the billing system

2. One of the Reason as Listed above

3. Valid document proof for the reason

4. No other Amendment already in workflow

Procedure:

The process of adding Amendment is as follows

Please follow the scenarios and let me know in case of doubts. There are two scenarios on how an amendment will be completed which is based on the paid status of the existing demands in the system.

1. when demand is unpaid/partially paid

1. create a demand (Or an existing demand can be used) with demand detail → DD1.

2. Do not pay the bill or make payment partially.

3. Create an amendment for the same consumer-code (with demand detail → DD2).

4. approve the amendment, the response should return an amendment with status CONSUMED.

5. search the demand or fetch bill for the consumer-code, demand/bill should contain demand details of demand and amendment together DD1 and DD2 in the same demand/bill.

2. when demand is completely paid,

1. create demand and make complete payment or choose a consumer-code which is fully paid.

2. create amendment (with demand detail → DD1).

3. Approve amendment, the response should be APPROVED this time.

4. create new demand for the consumer -code (with demand detail → DD3), demand response should contain two demand details DD1 and DD2 saved to the demand.

5. Now amendment search will return CONSUMED status after the demand is created.

IMPACT: Does not impact any other functionality other than adding demand details to demands on APPROVAL.

IMPACTED BY: Existence of demands in the system.

Configuration Details

Billing Service | Configuration-Details: ​Refer billing-service config for MDMS data. the amendment makes use of the same data set.

WORKFLOW CONFIG:

{
  "RequestInfo": {
    "apiId": "Rainmaker",
    "action": "",
    "did": 1,
    "key": "",
    "msgId": "20170310130900|en_IN",
    "requesterId": "",
    "ts": 1513579888683,
    "ver": ".01",
    "authToken": "{{authToken_amritsar}}"
  },
  "BusinessServices": [
    {
      "tenantId": "pb",
      "businessService": "BS.AMENDMENT",
      "business": "BS",
      "businessServiceSla": null,
      "states": [
        {
          "tenantId": "pb",
          "sla": null,
          "state": null,
          "applicationStatus": "INWORKFLOW",
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "actions": [
            {
              "tenantId": "pb",
              "action": "OPEN",
              "nextState": "APPROVALPENDING",
              "roles": [
                "EMPLOYEE"
              ]
            }
          ]
        },
        {
          "tenantId": "pb",
          "sla": null,
          "state": "APPROVALPENDING",
          "applicationStatus": "INWORKFLOW",
          "docUploadRequired": true,
          "isStartState": true,
          "isTerminateState": false,
          "actions": [
            {
              "tenantId": "pb",
              "action": "APPROVE",
              "nextState": "APPROVED",
              "roles": [
                "EMPLOYEE"
              ]
            },
            {
              "tenantId": "pb",
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "EMPLOYEE"
              ]
            }
          ]
        },
        {
          "tenantId": "pb",
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "INACTIVE",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "actions": null
        },
        {
          "tenantId": "pb",
          "sla": null,
          "state": "APPROVED",
          "applicationStatus": "ACTIVE",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "actions": null
        }
      ]
    }
  ]
}

Integration Details

Integration Scope

Amendment integration helps the respective Organization to add additional value to the demand without any change in the system.

Integration Benefits

• Easy to create and simple process of updating demands

• helps ease changes into the system which are not part of normal functionality - Amendment of bills in case of legal requirements.

Steps to Integration

This is integrated into the billing system by default.

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

Interaction Diagram

{yet to be addded}

Docs and Resource Links

API Definition

API SPEC FOR BILL-AMENDMENT

API LIST

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

• Prior Knowledge of Java/J2EE.

• Prior Knowledge of Spring Boot.

• Prior Knowledge of KAFKA

• Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.

• Prior knowledge of the demand-based systems.

• Following services should be up and running:

  • user

  • MDMS

  • Id-Gen

  • URL-Shortening

  • notification-sms

Key Functionality

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

MDMS

Business Service JSON

{
  "tenantId": "pb",
  "moduleName": "BillingService",
  "BusinessService": [
    {
      "businessService": "PropertyTax",
      "code": "PT",
      "isBillAmendmentEnabled":"true",
      "collectionModesNotAllowed": [
        "DD","OFFLINE_NEFT","OFFLINE_RTGS","POSTAL_ORDER"
      ],
      "partPaymentAllowed": true,
      "minAmountPayable":100,
      "isAdvanceAllowed": false,
      "demandUpdateTime": 86400000,
      "isVoucherCreationEnabled": true,
      "billGineiURL" : "egov-searcher/bill-genie/billswithaddranduser/_get"
    },
    {
      "businessService": "WaterCharges",
      "code": "WC",
      "isBillAmendmentEnabled":"true",
      "collectionModesNotAllowed": [
        "DD","OFFLINE_NEFT","OFFLINE_RTGS","POSTAL_ORDER"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": true,
      "demandUpdateTime": 86400000,
      "isVoucherCreationEnabled": false
    },
    {
      "businessService": "TradeLicense",
      "code": "TL",
      "collectionModesNotAllowed": [
        "DD","OFFLINE_NEFT","OFFLINE_RTGS","POSTAL_ORDER"
      ],
      "partPaymentAllowed": false,
      "isAdvanceAllowed": false,
      "demandUpdateTime": 604800000,
      "isVoucherCreationEnabled": true
    }
  ]
}

TAX-Head JSON

{
  "tenantId": "pb",
  "moduleName": "BillingService",
  "TaxHeadMaster": [
    {
      "category": "ADVANCE_COLLECTION",
      "service": "PT",
      "name": "Pt advance carry forward",
      "code": "PT_ADVANCE_CARRYFORWARD",
      "isDebit": true,
      "isActualDemand": false,
      "order": "0",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "Pt owner exemption",
      "code": "PT_OWNER_EXEMPTION",
      "isDebit": true,
      "isActualDemand": true,
      "order": "5",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "Pt time rebate",
      "code": "PT_TIME_REBATE",
      "isDebit": true,
      "isActualDemand": true,
      "order": "2",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "Pt unit usage excemption",
      "code": "PT_UNIT_USAGE_EXEMPTION",
      "isDebit": true,
      "isActualDemand": true,
      "order": "6",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "Pt adhoc penalty",
      "code": "PT_ADHOC_PENALTY",
      "isDebit": false,
      "isActualDemand": false,
      "order": "1",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "propertytax",
      "code": "PT_TAX",
      "isDebit": false,
      "isActualDemand": true,
      "order": "0",
      "isRequired": false
    },
    {
      "category": "TAX",
      "service": "PT",
      "name": "Pt fire cess",
      "code": "PT_FIRE_CESS",
      "isDebit": false,
      "isActualDemand": true,
      "order": "7",
      "isRequired": false
    }
  ]
}

Tax-Period JSON

{
  "tenantId": "pb",
  "moduleName": "BillingService",
  "TaxPeriod": [
    {
      "fromDate": 1554076799000,
      "toDate": 1585679399000,
      "periodCycle": "ANNUAL",
      "service": "PT",
      "code": "PTAN2019",
      "financialYear": "2019-20"
    },
    {
      "fromDate": 1522540800000,
      "toDate": 1554076799000,
      "periodCycle": "ANNUAL",
      "service": "PT",
      "code": "PTAN2018",
      "financialYear": "2018-19"
    },
    {
      "fromDate": 1491004800000,
      "toDate": 1522540798000,
      "periodCycle": "ANNUAL",
      "service": "PT",
      "code": "PTAN2017",
      "financialYear": "2017-18"
    },
    {
      "fromDate": 1459468800000,
      "toDate": 1491004799000,
      "periodCycle": "ANNUAL",
      "service": "PT",
      "code": "PTAN2016",
      "financialYear": "2016-17"
    },
    {
      "fromDate": 1522540800000,
      "toDate": 1554076799000,
      "periodCycle": "ANNUAL",
      "service": "TL",
      "code": "TLAN2018",
      "financialYear": "2018-19"
    }
  ]
}

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.

Steps to Integration

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

2. Organization 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 be used to cancel the created ones or update workflow if configured.

Interaction Diagram

Interaction Diagram V1.1:

Reference Docs

Doc Links

API List

Apportioning FAQs

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: (TBD)

• Proportionate based apportioning (Adjust total receivable with all the tax head 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, if the full amount is paid for any bill then each individual tax head should get nullify 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 generating demand in 2015-16 then the demand structure will as follows:

DSS Backend Configuration Manual

Overview

DSS has two sides to it. One is the process in which the Data is pooled to ElasticSearch and the other being the way it is fetched, aggregated, computed, transformed and sent across. As this revolves around a variety of Data Set, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, then it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.

This document explains the steps on how to define the configurations for both sides of DSS. Analytics and Ingest Pipeline Services.

Abbreviations

Ingest: Micro Service which runs as a pipeline and manages to validate, transform and enrich the incoming data and pushes the same to ElasticSearch Index

Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.

JOLT: JSON to JSON transformation library written in Java where the "specification" for the transform is itself a JSON document

Modules / Domain Level: These are the Services in this context. Each of the services, such as Property Tax, Trade License, Water and Sewerages are considered as Modules / Domains

Chart: Each individual graphical representation is considered as a Chart in specific. For example, a Metric of Total Collection is considered as a Chart.

Visualization: Group of different Charts is considered as a Visualization. For example, the group of Total Collection, Target Collection and Target Achieved is considered as a Metric Collection of Charts and thus it becomes a Visualization.

Ingest Pipeline Configurations

Below is the list of configurations -

1. Topic Context Configurations

2. Validator Schema

3. JOLT Transformation Schema

4. Enrichment Domain Configuration

5. JOLT Domain Transformation Schema

Descriptions

Topic Context Configurations

Topic Context Configuration is an outline to define which data is received on which Kafka Topic.

Indexer Service and many other services are sending out data on different Kafka Topics. If the Ingest Service is asked to receive those data and pass it through the pipeline, the context and the version of the data being received has to be set. This configuration is used to identify which kafka topic consumed the data and what is the mapping for that.

Click here for Full Configuration

1. Validator Schema

Validator Schema is a configuration Schema Library from EveritBy passing the data against this schema, it ensures whether the data abides by the rules and requirements of the schema which has been defined.

Click here for an example configuration

1. JOLT Transformation Schema

JOLT is a JSON to JSON Transformation Library. In order to change the structure of the data and transform it in a generic way, JOLT has been used.

While the transformation schemas are written for each Data Context, the data is transformed against the schema to obtain a transformed data.

Follow the slide deck for JOLT Transformations

Click here for an example configuration

1. Enrichment Domain Configuration

This configuration defines and directs the Enrichment Process which the data goes through.

For example, if the Data which is incoming is belonging to a Collection Module data, then the Collection Domain Config is picked. And based on the Business Type specified in the data, the right config is picked.

In order to enhance the data of Collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.

Click here for an example configuration

1. JOLT Domain Transformation Schema

As a part of Enhancement, once the domain level object is obtained, we might not need the complete document as is in the end data product.

Only those parameters which should be or can be used for aggregation and representation are to be held and others are to be discarded.

In order to do that, we make use of JOLT again and write schemas to keep the required ones and discard the unwanted ones.

The above configuration is used to transform the data response in the enrichment layer.

Click here for an example configuration

1. Use case:- JOLT Transformation Schema for collection V2

   JOLT transformation schema for payment-v1 has taken as a use case to explain the context collection and context version v2. The payment records are processed/transformed with the schema. The schema supports splitting the billing records into an independent new record. So if there are 2 bill items in the collection/payment incoming data then this results in 2 collection records in turn.

Click here for an example configuration

Here: $i, the variable value that gets incremented for the number of records of paymentDetails

$j, the variable value that gets incremented for the number of records of billDetails.

Note: For kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.

es.push.direct=false

Analytics Configurations

Below is the list of configurations

1. Chart API Configuration

2. Master Dashboard Configuration

3. Role Dashboard Mappings Configuration

Description

Chart API Configuration

Each Visualization has its own properties. Each Visualization comes from different data sources (Sometimes it is a combination of different data sources)

In order to configure each visualization and its properties, we have Chart API Configuration Document.

In this, Visualization Code, which happens to be the key, will be having its properties configured as a part of the configuration and are easily changeable.

Click here for an example configuration

1. Master Dashboard Configuration

Master Dashboard Configuration is the main configuration that defines which Dashboards that are to be painted on the screen.

It includes all the Visualizations, their groups, the charts which comes within them and even their dimensions as what should be their height and width.

Click here for an example configuration

1. Role Dashboard Mappings Configuration

Master Dashboard Configuration which was explained earlier hold the list of Dashboards that are available. Given the instance where Role Action Mapping is not maintained in the Application Service, this configuration will act as Role - Dashboard Mapping Configuration

In this, each Role is mapped against the Dashboard which they are authorized to see

This was used earlier when the Role Action Mapping of eGov was not integrated. Later, when the Role Action Mapping started controlling the Dashboards to be seen on the client-side, this configuration is just used to enable the Dashboards for viewing.

Click here for an example configuration

Adding Configurations

Adding Roles and Dashboards :

To add a new role, RoleDashboardMappingsConf.json (roles node) configuration file has to be modified as below

Below as in Figure 9. is a sample to add a new role object, new dashboard object

To add a new dashboard, MasterDashboardConfig.json (dashboards node) has to be modified as below in Figure 10.

Adding Visualizations in existing Dashboard

To add new visualisations, again MasterDashboardConfig.json (vizArray node) has to be modified as below as shown in Figure 11.

Note: vizArray is to hold multiple visualizations

Adding charts for visualizations

To add a new chart, chartApiConf.json has to be modified as shown below. A new chartid has to be added with the chart node object.

Metric chart Sample as shown in Figure 12.

Pie chart Sample as shown in Figure 13.

Line chart Sample as shown in Figure 14.

****

Table chart Sample: This chart comes in 2 kind - table and xtable.

table (as shown in Figure 15.) type allows to added aggregated fields added as available in the query keys, hence to extract the values based on the key, aggegationPaths needs to add along with their data type as in pathDataTypeMapping.

xtable(as shown in Figure 16.) type allows to add multiple computed fields with the aggregated fields dynamically added.

To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in existing in query key, newField as name to appear for computation must be defined.

https://github.com/egovernments/configs/blob/master/egov-dss-dashboards/dashboard-analytics/ChartApiConfig.json for the full configuration in detail.

Steps to create charts and visualise are:

• Create/Add a chart in chartApiConf.json

• Add a visualization for the existing dashboard in MasterDashboardConfig.json as defined above.

• Or in order to create/add a new dashboard create the dashboard in MasterDashboardConfig.json and create a role in RoleDashboardConfig.json

Configuration Changes for DrillThrough :

1. Example Drill through in Ward table in Property Dashboard.

wardDrillDown is the visualization code for PT Drill Down. kind is the attribute that shows the type of visualization code. Apart from two things all the attributes are common.

1. Example Drill through in ComplaintList table in PGR Dashboard.

complaintDrillDown is the visualization code for PGR Drill Down.

The above complaintDrillDown visualization code called in the drill chart parameter.

Overview

The consumer sometimes needs additional amounts (Amendments) added to their bill due to reasons external to the system. The addition of amounts happen with respect to the consumer-code of the entity in the product(PT, WS etc..,), any unpaid demand in the system is a candidate for amendments.

Functionality

Amendment mainly works with two types of functionality as follows:

• Amendment

• Demand

Objective

The main objective of the Bill-Amendment module is to create Credit/ Debit Notes against the bills for consumers who need an additional amount to be added to their bill.

Feature List

• Create Amendment

• Search Amendment

• Update Demand

• Update Amendment

API DEFINITION

POSTMAN-COLLECTION

Functionality

Bill Amendment provides a separate flow to enable workflow and validation for the process of adding additional amount into the existing demands which were done through the respective modules only till this point in time. An amendment will be allowed only when the reason arises from out of the system to add or reduce the amount from the existing bill belonging to an entity. The reasons are as listed below -

1. Court case settlement

2. One time waiver

3. Write-offs

4. DCB correction (Old demands in paid status)

5. Remission for Property Tax