Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Configure the backend services to expand the scope of NalJalSeva
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
NalJalSeva, powered by the DIGIT platform, is designed for rural communities to independently manage their water supply infrastructure. The solution allows users to add new consumers, generate demand, collect revenue, and record expenditure transactions. It simplifies record-keeping, maintains a consumer database, monitors user charges, and provides a unified system for benchmarking rural governance and operations.
The NalJalSeva solution design impacts the financial and operational governance outcomes in multiple ways. Some of these include:
Empowering Local Communities: Villages gain full control over their water systems, promoting long-term sustainability.
Digital Governance: Built on DIGIT, NalJalSeva streamlines revenue and expense management, ensuring smooth operation.
Transparent and Accountable: Financial and operational activities are visible to local governments, ensuring transparency and accountability.
The Finance Department and Water Supply and Sanitation Department have limited visibility over the fiscal sustainability of water schemes and get hit by the sudden demand for large funds to clear electricity bills.
The Department of Water Supply & Sanitation (DWSS) face several problems due to the lack of financial visibility of schemes:
Unreliable and poor-quality water—Ineffective fiscal resource tracking often results in underfunding of water quality or treatment schemes.
Inability to collect adequate water charges — Manual methods of revenue collection from households on account of water charges often lead to shortfalls. Pending dues often accumulate and adversely impact financial planning and proposed schemes.
Lack of visibility of revenue and expenditure information - Inadequate financial transparency offers limited insight into how funds are being managed and spent by the local governing bodies. This creates financial blind spots, leading to misallocation of resources and unplanned expenses.
NalJalSeva helps digitise the revenue and expense records of Gram Panchayat Water Supply Committees. The dashboards and data insights provide DWSS and FD officials with visibility into the GPWSC's financial status.
The app offers capabilities to:
track and manage the revenue and expenditure records using the digital platform
share reports over WhatsApp
access updated insights on consumer satisfaction/quality of services provided by local governing bodies
view dashboards for a snapshot of collections and expenditures to the Sarpanch/other rural administrative officials
access detailed collection reports from each household for accurate insights into consumption and demand
NalJalSeva integrates with the Fiscal Information Exchange (iFIX) platform to promote transparency and accountability in fiscal transactions. The fiscal events are posted on the platform in a standardised format making it easier to track and manage financial performance. The events are aggregated and processed to provide rich insights on key performance metrics which are available to users in the form of fiscal sustainability dashboards.
The illustration below provides a visualisation of how multiple actors interact with the distinctive Gram Panchayat Water Supply & Sanitation system registries to manage and coordinate various fiscal events. The key actors or stakeholders of the system include system administrators, department workers, local governing bodies, citizens and collection agents. Streamlined interaction between these actors is crucial for effective operations and management of fiscal events to facilitate sustainable and equitable access to basic services within the community.
The NalJalSeva app offers multiple benefits that promote the efficiency and transparency of water management services within local governing bodies.
Digital book-keeping - maintains all receipt and expense records in digital format reducing the reliance on physical documents.
Account management - simplified consumer and vendor account creation or management
Low-effort operations - easy to use and environmentally friendly
Minimise manual work - a simple mobile app that saves the time and effort of managing revenue & expenditure transactions
Environment friendly - digital operations ensure all accounts are managed digitally thus reducing paper usage
Accountability and transparency - recorded fiscal events and data-driven insights available through performance dashboards ensure accountability and transparency in operations
Seamless handover - easy to handover records from one to another Sarpanch
Dashboard insights - configurable dashboards provide easy and effective visualisation of local governance performance metrics
Better planning - helps in better planning and efficient fund management, leading to better services
Builds trust - information sharing about GPWSCs’ performance with citizens helps build trust and confidence
Online and cash payment - Online payment through multiple options - Netbanking, Credit/Debit Card, Mobile Wallets. Cash payment is also available
Notifications and alerts - SMS alerts, digital bills and receipts shared on registered mobile numbers, active SMS alerts
Consumer rating - Citizens can rate the quality of water services in villages/wards. It helps identify problems and improve water services.
Full or partial payment - users have the option to make partial payment of bills
A quick walkthrough of NalJalSeva app
Application designed to collect, manage revenue and expenditure
A digital solution powered by DIGIT that enables the gram panchayat water committee to collect & manage revenue and expenditure.
NalJalSeva meets the objectives of the Jal Jeevan Mission launched by the Department of Drinking Water & Sanitation (DDWS), which aims to "provide safe and adequate drinking water through individual household tap connections by 2024 to all households in rural India." The solution empowers the village communities with the ease of consumer management, billing, collection, expense management and monitoring water supply schemes.
The NalJalSeva mobile app enables rural local bodies to manage revenue and expenditures related to water supply projects. It is designed for water management committee members and collection agents. The collection agents can add consumers (or households) and generate bills and receipt acknowledgements. The app provides an intuitive interface for users at the local governance level along with insightful dashboards for effective decision-making.
NalJalSeva offers multiple features required to manage revenues and expenditures (listed below).
Create and maintain household registers
Collect payments
Download bills & receipts
Add and update expense records
Generate demands and bills
Create and edit consumer details
Access insights through rich dashboards
This section contains all docs and information required to understand NalJalSeva, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the NalJalSeva app.
Navigation Tips
Click on the embedded links within the content to browse topic details
Use the contents links available on the right side of the screen to move to a specific heading
Find the list of Related Docs links at the bottom of each page to browse through additional product details
NalJalSeva is an app-based solution designed for rural water governance and financial management. It supports local governance by providing tools to support consumer management, billing and collection added to financial reporting.
The solution enables the governance bodies to maintain financial records following established procedures and practices.
The solution offers an end-to-end solution for managing rural water supply schemes, focusing on maintaining transparency and simplifying financial transactions. It enhances governance and simplifies tasks for local authorities while ensuring accountability.
Click on the links below to explore the NalJalSeva workflows:
Consumers
Assurance of access to clean and regular water supply:
Ease of payment
Transparency
Digital invoice
Accountability
VWSCs
Ease of managing operations and maintenance of water supply -
Updated and verified data registry
Role base login
Village level dashboard and reports
Ease of collection
Government
Efficient monitoring and policy reforms -
State level dashboards and reports
Data verification
Billing to VWSCs
Ease of policy implementation
User Management:
Login to the application
Onboard new users in bulk and manage user profiles
Provide walkthroughs for users and gather post-payment feedback
Consumer and Billing Management:
Create, edit, and view consumer details
Generate bills for both metered and non-metered connections
Bulk demand generation for metered/non-metered connections
Collect offline payments and send bills/receipts as PDFsSend SMS notifications related to bills and payments
Financial Recordkeeping:
Add and update expense details
View expense and collection data through a tabular dashboard
Maintain financial records in compliance with established practices
Additional Functionalities:
View household registers
Display notifications on the homepage
Update expense search functionality
Download bills and receipts
Regular app updates to improve user experience
Role: GP Admin
Actions:
Role: Collection Operator
Actions:
Role: Revenue Bulk Demand Processing
Actions:
Role: Expense Processing
Actions:
Role: Dashboard Viewer
Actions:
All Gram Panchayats have a monthly billing cycle for water charges. The Scheduler automatically triggers on the “X” date of every month to generate demand and raise bills for non-metered connections.
Metered connections do not fall under bulk demand generation
For the first month of go-live, it is only the arrears and no demand that is generated hence there is no bill to collect payments.
From the second month (X date of Month 2) onwards, demand is generated.
Once the demand is generated, a notification is triggered to all mGramSeva users.
Details of Notification
“Demand for water charges has been raised for <GP>. New Bill Amount is Rs. Xyz. Overall pending amount is Rs.AbcD”
Each non-metered household also gets notifications
SMS Notification with Bill PDF
Dear “username”, A new water bill has been generated against <connection ID>. Please download the bill using <link>
SMS notification with a payment link
Dear “username”, A new water bill has been generated against <connection ID>. Please pay the bill online to avoid late payment charges<link>
Revenue collectors can see a new card (Updated card from month 2 onwards) with information related to demand and payment collection on the HH Details screen.
There is also a demand collection tile/card on the home screen.
This is used in cases when the scheduler is not run (due to technical errors) and the Gram Panchayat wants to run it manually.
The system does nothing if the manual demand generation is done in the middle of the billing cycle for which demand has already been generated.
Manual demand generation helps only when the scheduler has not generated a demand for a billing cycle.
To explore the Demand Generation Logic refer to Bulk Demand Generation for Non-Metered.
In the Bulk Demand screen -
Service Category: Defaulted to Water Charges (Module)
Service Type: Defaulted to “Non-Metered”
Billing Year: Dropdown with the list of the financial years from the master
Billing Cycle: Dropdown with the list of billing cycles for the selected financial year
Clicking on Generate Demand triggers the demand for the given billing cycle based on the logic defined above.
Users are redirected to the View Consumer screen from the home screen via
Collect payments → Search Screen → Consumer Details Screen
Download bills & receipts → Search screen → Consumer Details Screen
Dashboard → Collections → Click on Consumer ID
Household Register → Click on Consumer ID
This screen contains all information related to HH
Static HH card displays the following details
New Connection ID (also displayed as a heading)
Consumer name
Father's name
Phone number
Old connection ID
Address - Door Number, Street number, Ward (attached)
Property type
Service type
for metered connections - the meter number is displayed
If the bill is not generated (Post rollout until the first month)
Only the data Card is shown - No action is required
Once the first demand is generated - A new consumer bill/card gets generated and displays the following data points and actions -
Billing cycle – the latest billing cycle
Amount -
Current Amount - fixed charges applicable to the billing cycle
Arrears - Arrears from the first month (From next month onwards this field displays any unpaid dues)
Total Amount - Sum of current amount and arrears
Action Items
Download or Share Bill
Clicking on download bill prompts users to download the bill (Bill details are given in a separate user story)
Share bill (WhatsApp icon) opens sharing options to the phone OS and the user can share bills via WhatsApp
Message to go in WhatsApp “Please find Bill for water charges with Connection ID WS-83121-8312 generated on dd/mm/yyyy” along with bill PDF
Name of the PDF - “Bill ID”
Collect Payment
The Collect payment button takes the revenue collector to the payment collection screen
After the First payment collection is done
A receipt history block is visible only after the first payment transaction is completed through mGramSeva
A list of all the receipts is shown under this section as cards, with different data points as actions. Order of receipts is newest → oldest from top to bottom
Each receipt card contains
Receipt ID
Amount Paid
Paid Date
Actions
Download Receipt - Download the receipt in the Revenue Collector's phone as a PDF
Name of PDF - “Receipt ID”
Share (WhatsApp)
Message to go in WhatsApp “Please find the receipt for water charges with Connection ID WS-83121-8312 paid on dd/mm/yyyy” along with the receipt PDF
New Connection Before First Bill Generation
First bill is generated - Payment Collection is pending
2 payments made
If a bill is not generated (Post rollout until the first month)
A data card is displayed on the screen
Below the data card - the Card to generate a new bill is also displayed
This card contains
Last bill generation date - For the first time this is picked up from data entry. Next time onwards the system captures the last bill generation date
Days from last bill generation date - indicates to the revenue collector the number of days that passed since the last time a bill was generated.
Previous Meter reading - Displays the last read meter units
Pending Amount
Before the first bill is generated, the arrears are captured during data entry
After the first bill is generated, the pending amount includes the entire amount due for the specific user
Generate a new bill
Clicking on Generate a New Bill initiates bill generation flow for metered connection
Note - Users have to generate a bill to start collecting payments. Arrear amount collection also is not possible till the first bill is generated.
After the first bill is generated
A new consumer bill/card gets generated with the following data points and actions
Last bill generation date - date of bill generation
Amount -
Current Amount - Volumetric charges between 2 latest meter readings according to rate master
Arrears - All previously unpaid dues
Total Amount - Sum of current amount and arrears
Action Items
Download, Share Bill
Clicking on the download bill prompts users to download the bill for the respective amount (Bill details are given in a separate user story)
Share bill (WhatsApp icon) opens the sharing options of the phone OS and the users can share bill via WhatsApp
Message to go in WhatsApp “ Please find Bill for water charges with Connection ID WS-83121-8312 generated on dd/mm/yyyy” along with bill PDF
Name of the PDF - “Bill ID”
Collect Payment
Collect payment takes the revenue collector to the payment collection screen
After the first payment collection is done
A receipt history block is visible only after the first payment happens through mGramSeva
A list of all the receipts is shown under this section as cards, with different data points as actions. Order of receipts is newest → oldest from top to bottom
Each receipt card contains
Receipt ID
Amount Paid
Paid Date
Actions
Download Receipt - Download the receipt to the revenue collectors phone as a PDF
Name of PDF - “Receipt ID”
Share(WhatsApp)
Message to go in WhatsApp “ Please find receipt for water charges with Connection ID WS-83121-8312 paid on dd/mm/yyyy” along with receipt PDF
If a new bill is generated again by clicking on ‘Generate a new bill’ - the revenue collector goes through the bill generation flow and a single new card appears between ‘Generate bill’ and ‘Consumer receipts block’
The household masters have to be created in the system to initiate the demand generation and collection process. These consumers are also referred to as the household that regularly avails the water connection and supply.
Select the Create Consumer option from the list of tiles/cards on the home page. This redirects the user to the Create Consumer page.
Data element details for the consumer are listed in the table below -
Field Name | Type | Mandatory Y/N | Description |
---|---|---|---|
Multiple connections (HH or household records) can be created using the same phone number.
Phone numbers can be the same, but a new HH record cannot be created using the same old connection ID. The old connection ID should be different to create a new HH record.
A single HH record, cannot be registered in the system more than once. Trying to register the same record on the system again displays the error message “This connection already exists”.
Clicking on the Submit button creates the consumer master and a new consumer ID is assigned to the master. The consumer ID generated is based on logic defined as - “WS-<GP id>-<4 digit running seq No>”
If the connection ID already exists, the system displays an error message.
On first-time/new-load, all data entry fields and dropdowns are empty (since no records are prefilled except for the default fields).
SMS is not sent to any user upon consumer (HH) creation.
Submit is disabled until all mandatory fields are entered. Once all inputs are made, the button is enabled.
Arrears demand:
Metered - The arrear demand for the period is created, where the From date is counted as the start of the Financial year and the To date as the period mentioned on the screen.
Non-metered - The arrear demand is created for the selected billing cycle.
Successful creation of consumer records displays the toast message “ Registration successful”.
Closing this toast message, using the close icon, refreshes the page and the user sees an empty consumer creation screen.
Consumer information can be edited under certain conditions -
Before the first demand is generated in the system
After the first demand is generated in the system
Users with permission to edit consumer records can click on the Edit Consumer info tile on the home screen. This navigates them to the consumer search screen.
Users can navigate to the Consumer Edit Screen from the search screen or the search results screen (Case when multiple search results are displayed).
On the successful load of the consumer edit screen, all data parameters of the consumer are shown (with editable and non-editable fields).
By Default - A new consumer ID is shown on the top of the screen and is non-editable.
The table below lists the editable field details -
Date Field | Before First Demand | After First Demand | Comments |
---|
In case there are arrears, demand is generated. If there are no arrears, demand is not generated.
Users can modify the arrear value. In such a case, demand is generated with the updated value.
Users can add arrear to the connection, for which arrear was zero at the time of creating the connection. In such a case, new demand is generated.
Clicking on the Submit button shows a nudge saying Details Submitted Successfully. Closing the nudge navigates the user back to the home screen.
The CTA is activated only when any field is changed or updated. Else, it is in an inactive state.
The users receive a link via SMS. Clicking on this link redirects the users to the login page of the NalJalSeva app. The users can log in from this screen or even reset their password in case they are logging in for the first time.
The link in the SMS redirects users to this screen which is the first screen which is the language selection screen. The user selects the preferred language and clicks on Continue. English, Hindi, and Punjabi are the supported languages with Punjabi as the default language. Localization in the screens is displayed based on the language selected.
The user enters the User ID, which is the registered mobile number of the user, and the system-generated password. Clicking on the Continue button logs in the user.
The Forgot Password link navigates the user to the password reset screen.
The user is redirected to the password reset screen where they enter the OTP received on the registered mobile number. The next screen prompts the user to enter a new password and then confirm the same. This is similar to the first-time login screen. Clicking on Submit displays the acknowledgement screen. Clicking on the Continue to Login button on the acknowledgement screen takes the user to the login page.
The user is redirected to the home page of the application which displays the menu options based on the mapped user role.
Once the demand is generated for metered and non-metered connections, revenue collectors come to this screen to collect payments.
Users can see the consumer billing information on the screen
Clicking on View Details expands the card and shows more details. Clicking on the Hide Details collapses the card to show only the Connection ID, Consumer Name & Total Due Amount.
Payment amount - can either pay
The full amount, or
Custom amount - Users can enter the custom amount in the input field - this cannot be zero or greater than the total due amount.
Payment methods
Cash - select cash and proceed to payment takes the user to the successful collection screen
Online - The online payment option displays a Q/R code on the user screen that can be scanned by another phone to pay the due.
Post payment via any mode - payment success screen is shown
Receipt ID format - RB-dd/mm/yyyy-yy/running_sequence_number
User Actions
Download receipt - download the PDF version of the receipt with the receipt ID as the name of the PDF while downloading.
Share receipt via WhatsApp - opens the Phone OS sharing options.
back to home - takes the user back to the home screen.
SMS to HH
As soon as the amount is paid and the Revenue collector reaches the Payment success screen SMS is sent to HH.
SMS 1 - Dear ‘Username’, Paid Rs. X for water charges for bill period <Cycle>. Download receipt <link>
SMS 2 - Dear ‘Username’, Please leave a review on water supply at <GP> at <Link>
HH can leave a review for water charges. Refer
Details on the card
When an online payment method is selected, the “Collect Payment” option is disabled. Since HH scans the QR, the Revenue collector does not have control over the online process.
The partial amount cannot be greater than the full amount.
Detail | Comments |
---|
Consumer creation - non metered
Consumer creation - metered
Connection ID | New Connection ID will be displayed here |
Consumer Name | Consumer Name (Should take updated consumer name) |
Bill ID number | ID of the Bill |
Bill period | For non-metered connections
For metered connections
| Format
|
Water charges | Amount for the latest billing cycle | For metered, calculate charges as per rate master between the latest 2 billing dates |
Arrears | All old arrears accumulated for HH | Expansion should breakup of arrears by individual billing cycles/bill generation dates |
Total Due amount | Net amount consumer has to pay |
The user of the GP system is onboarded by loading user records in bulk as a backend activity. The system enables the loading of user records in bulk and creates the profiles with a mobile number as login ID and with a random password.
On loading user profiles - The GP users are sent a link and login credentials over SMS required to login to the mGramSeva application. The link navigates to this screen and takes the user through the flow of logging in and resetting the password in case of a first-time login.
The web link, too, initiates from the same screen.
Consumer’s Name
Text
Y
Name of the household or connection owner.
Gender
Radio
Y
Male, Female, Transgender
Father's Name
Text
Y
Name of the father of the owner
Mobile Number
Numeric
Y
Mobile number for the consumer
Old Connection id
Alpha Numeric
Y
Old connection id or ref number for reference
Door Number
Alpha Numeric
N
Address details with door number for the connection
Street No/Street Name
Alpha Numeric
N
Street number or name of the house for the connection
Ward
Drop Down
Y
For a tenant which has a single ward, the ward field is not shown
For a tenant which has multiple wards, the ward field is shown as a single select dropdown
Gram Panchayat
Display
-
For info. the GP or tenant in which the connection master is created.
Property Type
Drop Down
Y
Dropdown with the list of property types from Master ( Ex - Residential, Commercial, Mixed, etc)
Service Type
Drop Down
Y
Dropdown with the list of service types from Master (Ex - Metered, Non-metered)
Meter Number
Alpha - Numeric
Y
Only for Metered connections - Meter number will be attached to consumer respectively
Previous meter reading date
Date selection
Y
Only for Metered connections - This field is used to tag arrears to a demand. Less than current Date.
Previous meter reading
Numeric
Y
Only for Metered connections - This field is used to attach arrears to a demand.
Last Billing Cycle Billed
Drop Down
Y
Only for Non-metered connections - Dropdown with the list of Billing Cycles prior to the current cycle. This field is used to specify the arrears or total outstanding as of the billing cycle.
Arrears as of Last Bill
Numeric
Y
Arrears as of date - This will be considered for the first Demand/Bill generation as total outstanding or arrears as of the billing period mentioned.
If no arrears are present to a HH, '0' has to be entered by the user.
Submit
Button
-
On click of Submit button, the consumer master is created with the detail entered above. The new connection id is also generated as per the configuration.
New Consumer ID | NO | NO | Consumer ID is generated while user creation and is not editable |
Consumer’s Name | YES | YES | bills, receipts, bill generation screens etc starts displaying the newly entered consumer name |
Gender | YES | YES |
Father’s Name | YES | YES |
Phone number | YES | YES | Use Cases
|
Old Connection ID | YES | NO | Validated for unique IDs in the system for the GPWSC |
Door Number | YES | YES |
Street Number / Name | YES | YES |
Ward Number / Name | YES | YES |
Gram Panchayat Name | NO | NO |
Property Type | YES | YES | Charges applicable as per rate master. Effects take place from the next billing cycle |
Service Type | YES | YES |
|
Meter Number | YES | YES |
Previous meter reading Date | YES | NA | This field is not shown on screen after the first demand is generated |
Previous Meter Reading | YES | NA | This field is not shown on the screen after the first demand is generated |
Last Billing Cycle Billed | YES | NA | This field is not shown on the screen after the first demand is generated |
Arrears as of Last Bill | YES | NA | This field is not shown on the screen after the first demand is generated. When changed the arrear demand is deleted and updated accordingly based on the selected service type. |
Mark Connection as inactive | YES | YES | If a connection is marked inactive, it is not considered for demand generation for future billing cycles. An inactive connection can be reactivated later from this screen. |
Unlike non-metered connections with a billing cycle for demand & bills generated automatically, a metered connection needs more inputs, which helps in volumetric billing.
A revenue collector can see a CTA to “Generate a new Bill” on the HH details screen.
Clicking “Generate a new Bill” takes users to the bill generation screen where new meter reading details are entered.
The field on the bill generation screen for metered connections is displayed in the table below.
Clicking on “Generate bill” takes the user to the bill generation successful screen.
Logic for Bill ID number - “RB - dd/mm/yyyy-yy/running_sequence_number”.
There are 3 user actions on the success screen
Download bill - Download bill as PDF (name of PDF is always the Bill ID by default)
Share bill on WhatsApp - Share bill as PDF on WhatsApp
Collect Payment - navigates the revenue collector to the payment collection screen
Share on WhatsApp opens the WhatsApp share popup with the option to choose contacts/groups. The bill is shared with the below text and attached PDF details -
Text “ Dear <ConsumerName>, Please find water bill for billing cycle <Cycle> attached as PDF”
Input Metric | Description | Comments |
---|---|---|
To find details on Demand Generation Logic refer to the Demand/Bill Generation for metered connection.
All 5 digits in the meter reading must be entered. Show error message “ Old Meter Reading entered is Invalid” or “ New Meter Reading entered is invalid” respectively.
The New Meter reading should be greater than the Old Meter Reading.
The meter reading date is by default set to <today's date> but the user has the option to change it.
The expense entry for the O&M regularly is captured on this screen.
On selecting the option “Add Expense Record” from the list of tiles/cards on the home page, the user is navigated to the expense entry screen. The screen displays the following fields.
Field Name | Type | Mandatory Y/N | Description |
---|---|---|---|
On Submitting, the Expense entry gets created with a Bill number assigned. The Bill number generated would be based on logic defined as - “EB-<FY>-<4 digits running seq No>”
On Successful creation of expense entry, an acknowledgement screen is shown “Expense Entry successful” along with the Bill Number.
Expense modification is allowed based on the status of the payment as highlighted in the scenarios below -
Allows users to modify all the details except the Bill id. But the user has the option to mark the Bill as “Cancelled”.
Does not allow users to modify any details. But the user has the option to mark the Bill as “Cancelled”.
As soon as the revenue collector marks the bill as paid by the consumer, they receive one SMS with the link to the receipt in PDF format and another SMS with a link to collect feedback.
Users can walk through the application for a better understanding of different user actions available on key screens.
Note: For first-time users after login, the walkthrough automatically starts on the home page. For multi-tenant users, the walkthrough starts after selecting the tenant and landing on the home screen
Step Number | Element | Note |
---|---|---|
Step Number | Element | Note |
---|---|---|
mGramSeva users can edit their basic information like name, add gender, email and change the password using the hamburger menu on any screen.
Users can click on the hamburger menu from any screen. A slider from the left opens up.
Users can -
Change Language
Edit profile
Logout
Changing language changes localization as per standards
Edit profile takes users to the next screen where changes can be made to the user profile
Name - Can be changed
Phone number - Cannot be changed
Gender - This field is not present by default. Whatever the user enters is stored and saved
Email ID - It is an empty field. User input is stored as the user’s email id
Change Password - This takes users to the password changing screen where the old password, new password and confirmed new password have to be entered as per given standards.
Dynamic password validation happens the same as in the registration flow.
Until all fields are entered, the primary CTA is disabled.
Changing the password shows a nudge to the user “Password updated successfully” and closing this nudge takes the user to the user profile screen.
Clicking on save shows a nudge to the user” Details saved successfully”. Upon closing, this user remains on the screen but the fields show as edited.
Step Number | Element | Note |
---|---|---|
Step Number | Element | Note |
---|---|---|
1
Type of Expense
Select the category of expenditure
2
Vendor Name
Mention the name of the vendor who raised the bill
3
Amount
Add the amount that is mentioned in the bill
4
Bill Date
Add date on which bill is entered into records
5
Party Bill Date
Add date on which the bill is raised
6
Attach Bill
Attach JPEG/ PDF formats of the bill here
7
1
User feedback section
Feedback provided by consumers is shown here
2
Collections Snapshot
Summary of collections made in the selected time period
3
Search field
You can search for the consumer by Name or connection ID
4
Filters
Use filters to drill down by property type
5
Connection ID Column
These are new Connection IDs of consumers. Clicking on a consumer ID takes you to the respective Consumer Detail screen
6
Name
Name of the consumer
7
Collections
Collections made by the consumers in the selected time period
There are 2 methods to generate Bulk Demand -
Auto (scheduler based)
Manual
The demand is generated at the end of the month or the first day of the next month or as scheduled for the recently completed billing cycle. Use cases are as below -
First demand generated in the system: The demand is generated for the recently completed billing cycle considering the arrears in the master data. The arrears are tagged to the previous billing cycle of the current demand.
Consecutive demands: The demand is generated for all the months pending from the most recent to the last billing cycle completed.
The demand is generated for the recently completed billing cycle.
The demand is generated for the billing cycle selected by the user. The demand is generated only for those consumers for whom demand does not exist for the selected month.
First demand generated in the system: The demand is generated for the selected billing cycle considering the arrears in the master data. The arrears are tagged to the previous billing cycle of the current demand.
Consecutive demand: The demand for the selected month is generated only if the previous billing cycle demand exists. If the demand for the previous cycle does not exist, it gives an error message “Demand generation is pending from billing cycle - <Name of cycle>. Please generate demand from this cycle in sequence”. The validation considers the most recent billing cycle that exists in the system.
Charges/Heads & Calculation Logic
As part of V1, only the water charges head is applicable. Rate Master is defined at the GPWSC level.
Water Charges - Charges are applicable as defined in the Rate Masters based on - Validity, Property Type, and Service Type where the calculation type is “Per Bill Cycle” for the given billing period.
Bill Period - The billing periods are monthly as per the standards followed across GPWSCs. In future, GPWSC may switch to bi-monthly to reduce the processing effort. The sample billing period data is given in the MDMS data.
Exclusion
Reversion of demand is not allowed. This has to be done in the backend.
Exception reporting for every batch processing can be accessed from the backend only.
The demand is generated for metered connections for the billing period (defined based on the meter reading date) selected by the user at the time of recording the meter reading.
The 2 use cases to be handled are -
First demand generated in the system: The demand is generated for the selected billing period. The demand period would be from the “Previous meter reading date” from the consumer master or the demand created as part of the master TO the date entered in the billing screen. The arrears are tagged to the previous billing period of the current demand, and the period is from the start of FY to the “Previous meter reading date” from the consumer master.
Consecutive demand: The demand is generated for the period defined based on
From Date: Meter reading date from the last demand generated for the consumer
To Date: Is the selected meter reading date in the bill generation screen
As part of V1, only the water charges head is applicable. Rate Master is defined at the GPWSC level.
Water Charges - Charges are applicable as defined in the Rate Masters based on - Validity, Property Type, and Service Type where the calculation type is “Unit Rate” for the given number of units.
Bill Period - Is as per the date range selected for the bill generation.
Reversion of demand is not allowed. This has to be taken up in the backend.
Previous Meter reading
Only for first-time bill generation
New meter reading
For the first time and all consecutive bill generations
Previous meter reading units and previous meter reading dates will be taken from the last bill for new bill generation
Meter reading date
The default is the current date. Revenue collectors can change it to a previous date if required.
Vendor Name
Text (With Suggestions dropdown)
Y
Name of the Vendor. The suggestion list is shown as the user entry is done for every character. The new Name will also create a Vendor Register.
Type of Expense
Drop Down
Y
Type of expense list From Master
Amount
Numeric
Y
Expense amount for the Bill
Bill Date
Date
Y
Date on which the bill is to be recorded in the registers. Validation - Before Current Date and after party Bill Date.
Party Bill Date
Date
N
Date on which the Party/vendor bill was issued. Validation - Before the Bill Date.
Bill Paid
Radio Buttons
N
With option Yes/No. To update status if it is paid. If yes, “Paid Date” is captured.
Paid Date
Date
N
Date on which the bill is paid. Displayed if the Bill paid option is selected as “Yes”. Validation - After Bill date and less than current Date.
Attach Documents
Doc Attachments
N
Option to upload documents (Max of 5). Supported files - PDF, JPEG, PNG. Should show required validation for other types of files.
Submit
Button
-
On click, the consumer master gets created with the detail entered above. The new connection id also should get generated as per the configuration.
Expenditure Entry
Expenditure entry Successful
1
Tenant selection
Click here to switch to other Gram Panchayats
2
Household Register
Household Register contains a list of all consumers and their pending amounts
3
Collect Payments
Use collect payments to search for consumers, generate bills and collect payments
4
Download Bills and Receipts
Search by consumer details such as name or phone number to download bills & receipts
5
Add Expense Record
Use this to make a new expenditure entry into the system
6
Update Expenses
7
Generate Demand
8
Create Consumer
Create consumers records by adding details
9
Update Consumer Details
10
GPWSC Dashboard
View daily, monthly collection and expenditure summary
11
Notifications
Any new notifications that require your action regarding collections and expenditure will be shown here
1
Consumer’s Name
Start creating a consumer record by entering the consumer name
2
Gender
Select gender of the consumer
3
Father's Name
Add father’s name of the consumer
4
Mobile Number
Enter the mobile number of the consumer
5
Old Connection id
Enter OLD Connection ID Number. Eg.105
6
Door Number
7
Street No/Street Name
8
Ward
Select the ward where the consumer resides
9
Gram Panchayat
10
Property Type
Select one from residential/commercial type of property
11
Service Type
Select if the connection is metered or non-metered
12
Meter Number
Add meter number of the connection of the consumer
13
Previous meter reading date
Add the date of the last meter reading
14
Arrears
Add amount the household has to pay until today
For mGramSeva users, different notifications are displayed on the home screen based on various system triggers.
A new card is used for each notification displayed below.
Cards have a countdown timer - today, 1 day ago, 2 days ago, 3 days ago, and so on.
Cards have a close icon on the top right corner. Upon closing, the card view is removed from the screen. Cards, by default, do not have an expiry date.
A “New” text is shown to the user whenever there is a new notification after the user's last login.
The notification header shows the number of notifications in brackets.
Trigger | When | Text | Action | Data Criteria |
---|---|---|---|---|
Various SMS notifications are sent to different users on different actions. Below is a consolidated list of all SMS notifications required.
Event Type | Target User Type | Message | Comments |
---|---|---|---|
On selection of the “Modify Expense” option, the below search screen is shown for the users to search the Bill/s -
Search Criteria -
Vendor Name
Expense Type
Bill D
Search Result - Lists all the Expense bills matching the above search criteria
Bill ID
Type of Expense
Vendor Name
Amount
Bill Date
Status
Clicking on Bill ID displays the Expense Bill in edit mode based on the validations.
Bill and Receipt PDFs can be sent to consumers at multiple touchpoints.
When bulk demand is generated through SMS.
When a meter reading is done for metered connections, via SMS.
When the revenue collector goes to the HH screen and clicks on download PDF (into his mobile).
When the revenue collector goes to the HH screen and clicks on WhatsApp share PDF (Share PDFs on WhatsApp).
Click on the preferred language button. The app functions and screens will be available in the selected language.
Enter the registered mobile number and the password received via SMS.
The user receives an OTP on the registered mobile number. Enter the OTP. Enter a New Password and retype the password to confirm in the Confirm New Password field. Follow the Password Hint on the screen while setting up the password.
Click on the Confirm button. The user password is now updated. Click on the Continue to Login button to log in with the new password.
Click on the relevant village tenant assigned to the user from the screen.
This redirects the user to the relevant NalJalSeva functionalities available for the selected tenant.
Users can edit their profiles and change passwords as and when required. Click on the user icon on the top section of the screen. Click on Edit Profile to make profile changes.
Update Name, Gender, or Email ID as required. Make note that the registered Mobile Number cannot be changed. Save the changes.
Click on the Change Password button to change the password.
A step-by-step guide to using the NalJalSeva App
NalJalSeva is a standalone app-based module that enables the GPWSC committee to create new consumers, generate demand, collect revenue, record expenditure transactions etc.
NalJalSeva enables GPWSCs to maintain financial records of GPWSCs following established procedures and practices.
Follow the step-by-step (links below) guide to use the app:
There is an option to download bills without clicking on collect payment.
Bills and Receipts can be downloaded by clicking on the card/tile named Download Bills & Receipts on the home page.
Clicking on this card takes the user to the consumer search page. Searching by a phone number/ connection ID redirects to the Household Detail page.
Data Parameter | Description |
---|---|
Data Parameter | Description |
---|---|
On boarding - Creation login details
EMP/GP Users
Dear <user>, You've been invited to mGramSeva Application of Punjab. Please login using <Link>. Username: <Phone Number> Password: <Password>
On boarding - First time login OTP
EMP/GP Users
OTP for resetting password on mGramSeva is <OTP>
Forgot Password OTP
EMP/GP Users
OTP for resetting password on mGramSeva is <OTP>
Demand (Bulk)
EMP/GP Users
Dear <user>, Demand for Billing Cycle <Cycle> has been generated for <GPWSC>. Kindly plan for collection of water charges for this period. <Link>
1st of each month
Pending Collection Reminder
EMP/GP Users
Dear <user>, Rs. <Amount> is pending collections against water charges at <GPWSC> as of <Date>. Click <Link> to see more details
fortnight
On Collection Day
EMP/GP Users
Dear <user>, Rs. <Amount> has been collected today <Date> against water charges from <number> consumers in Cash for <GPWSC>.
On Collection Day
EMP/GP Users
Dear <user>, Rs. <Amount> has been collected today <Date> against water charges from <number> consumers Online for <GPWSC>.
New Calendar Month
EMP/GP Users
Dear <user>, Rs. <Amount> has been collected in <previous month> against water charges & Rs. <Amount> has been spent as expenditure for <GPWSC>. Click <link> to see more details
Fortnight
EMP/GP Users
Please enter new expenditure bills online for <GPWSC>. Click <link> to make an expense entry now
Alternate Fortnight
EMP/GP Users
Expenditure bills for <GPWSC> are awaiting payment confirmation. Please click <link> and mark them as paid, if paid already
Demand (Bulk) - (NM & M)
Consumer
Dear <user>, water bill for <cycle> has been generated for consumer id <new consumer id> for Rs. <Amount>. Click <link> to download latest bill.
Dear <user>, water bill for <cycle> has been generated for consumer id <new consumer id> for Rs. <Amount>. Click <link> to download latest bill. Please make payment to your GPWSC.
Demand (Bulk) - (NM & M)
Consumer
Dear <user>, pending amount for water charges for consumer id <new consumer id> is Rs. <Amount>. Click <link> to pay online.
Bill Paid
Consumer
Dear <user>, Rs. <Amount> has been paid for water charges for consumer id <new consumer id>. Pending Amount is Rs. <Amount>. Click <link> to download receipt
Feedback Collection
Consumer
Dear <user>, Thank you for paying water charges. Please take this short survey and help us know more about water supply at <GPWSC>
Whatspp Message - Bill share
Consumer
x
Whatsapp Message - Bill Payment
Consumer
Dear <user>, Rs. <Amount> has been paid for water charges for consumer id <new consumer id>. Pending Amount is Rs. <Amount>. Click <link> to download receipt
Title
Gram Panchayat Water Supply and Sanitation
Heading
Water Bill
Name of GPWSC
Connection ID
Consumer Name
Consumer Mobile Number
Consumer Address
As per user details (use mockups for reference)
GPWSC Name should be highlighted
Phone number should be partially masked
Service Type
Bill ID
Bill Period
Bill Date
Service Type - As per Bill generated - Metered or Non metered.
Bill Id - For metered connections, after service type - metered, add meter number, meter reading and meter reading date as additional fields before bill ID
Bill Period - For non- metered - As per Billing cycle for which demand was generated. For metered, will based on the previous meter reading date of last bill and current meter reading date of the corresponding Bill.
Bill Issue Date - Date on which the demand was generated.
Text Above breakup of charges
Below is the breakup of pending water charges for the connection ID <New Connection ID>
Breakup of Charges
Expansions of the amount to be paid.
For non metered connections
Current water charges is the most recent billing cycle completed
Arrears are the previous billing cycles pending dues arranged in decreasing order by months
For metered connections
Current charges are the amounts levied for the most recent bill read, previous bill read.
Arrears are the previous dues in similar fashion
Total Amount Due
Total Amount to be paid by consumer until time of bill generation (Also display in words)
Previous Billing Cycle Summary
Under this section we’ll display data collected from user, along with collection and expenditure done by GP
Example: If the bill is generated in November for October and previous months(arrears), all data shown will be w.r.t October.
Text: Below is the User Feedback, Collections and Expenditure summary of <GPWSC>
User ratings
Irrespective of service type, ratings of how many ever users, given in the last billing cycle, is shown.
Collections
New Demand - Latest Demand generated
Actual Collections - Actual collections made in the previous billing cycle
Total pending Collections (cumulative) - Total pending collections for GP until the last date of the previous billing cycle
If the same bill is downloaded by a user after n days and more collections are made by GP by that date, pending collections number should go down.
Expenditure
New Expenditure - Expenses logged in the previous billing month
Actual Payments - actual payments made in the previous billing month
Total Pending Expenditure (cumulative)- total pending expenses until last date of the previous billing month
If the bill is downloaded again after few expenses are marked paid, the cumulative figures will go down.
Title
Gram Panchayat Water Supply and Sanitation
Heading
Water Bill
Name of GPWSC
Connection ID
Consumer Name
Consumer Mobile Number
Consumer Address
As per user details (use mockups for reference)
GPWSC Name should be highlighted
Phone number should be partially masked
Service Type
Receipt ID
Receipt Period
Receipt Issue Date
As per the Receipt generated -
For metered connections, after service type - metered, add meter number and meter reading as additional fields before Receipt ID
Text
Below is the breakup of the amount paid for water charges for connection ID <New Connection ID>
Breakup of Charges
Expansions of amount to be paid.
For non metered connections
Current water charges is the most recent billing cycle completed
Arrears are the previous billing cycles pending dues arranged in decreasing order by months
For metered connections
Current charges are the amounts levied for the most recent bill read, the previous bill read.
Arrears are the previous dues in a similar fashion
Amount Paid
Total Amount paid by the consumer for the receipt to get generated
Show amount paid in words also
Due Amount
As of date, time (day receipt is generated)
The total amount yet to be paid
Previous Billing Cycle Summary
Under this section we’ll display data collected from user, along with collection and expenditure done by GP
Example: If the bill is generated in November for October and previous months(arrears), all data shown will be w.r.t October.
Text: Below is the User Feedback, Collections and Expenditure summary of <GPWSC>
User ratings
Irrespective of service type, ratings of how many ever users, given in the last billing cycle, is shown.
Collections
New Demand - Latest Demand generated
Actual Collections - Actual collections made in the previous billing cycle
Total pending Collections (cumulative) - Total pending collections for GP until the last date of the previous billing cycle
If the same bill is downloaded by a user after n days and more collections are made by GP by that date, pending collections number should go down.
Expenditure
New Expenditure - Expenses logged in the previous billing month
Actual Payments - actual payments made in the previous billing month
Total Pending Expenditure (cumulative)- total pending expenses until last date of the previous billing month
If the bill is downloaded again after few expenses are marked paid, these cumulative figures will go down.
New Demand Generation
Monthly
Demand Generated
Demand for <billing cycle> has been generated. X bills have been raised and sent to X/X+Y households. Y bills have to be raised. Click here to see details
Take to a filtered view of household register with “Pending” selected
<billing cycle> - new billing cycle for which demand is generated - Demand will be generated on the 1st of each month
Use - Case 1
If GP has all non-metered connections then, all X/X bills are generated using bulk demand. Notification change as following
Demand Generated
Demand for <billing cycle> has been generated. X bills have been raised and sent to X/X households. Click here to see details
Take to a filtered view of household register with “Pending” selected
<billing cycle> - new billing cycle for which demand is generated
Demand will be generated on the 1st of each month
Use - Case 2
If GP has all metered connections then, all 0/Y bills are generated using bulk demand. Notification changes as following
New Billing Cycle
New billing cycle will start today. Y bills have to be raised for last month. Click here to see details
Take to a filtered view of household register with “All” selected
<billing cycle> - new billing cycle for which demand is generated
Demand will be generated on the 1st of each month
Every fortnight
Pending Collections
Rs.X is pending collection as of <Today's Date>. Click here to view dashboard
Take to current months revenue Dashboard
In the current financial year, for each consumer, demand raised minus receipt generated will be pending collections for that HH
When collection happens
Collection Day
Send only on the days when a collection has happened either online or offline methods
Todays Collections
Rs. P has been collected today for water charges from <number> consumers in Cash.
Rs. Q has been collected today for water charges from <number> consumers online.
Take to current months revenue Dashboard
Sum of receipts value generated that day in that GP via cash.
New Calendar Month
1st day of month
Month Summary
Rs. X has been collected in <previous month> for water charges and Rs. Y has been spent as expenditure. Click here to view more details
Go to the most recent completed month's dashboard
X - Sum of receipts value generated that day in that GP via cash.
Y - Expense Bills marked as paid last month (paid date is previous month)
Every fortnight
Enter a New Expenditure
Please enter new expenditure bills online. Click here to make an expense entry now.
Take to expense entry screen
Alternate fortnight
Mark expense bills as paid
This should only be sent when there is a pending bill is there. If all bills are paid already on the date of notification, do not send this.
<N> expenditure bills are awaiting payment confirmation. Click here to search & mark as paid, if paid already.
Bulk Demand generation doesn't happen as per schedule
Generate Demand
We couldn't generate demand automatically for billing cycle <cycle>. Click here to generate demand manually.
Take to demand generation screen.
Heading
HouseHold Register
As of Date
As of <Todays Date>
Search
Search by consumer name or connection id
Partial match should be allowed.
Filters
Default is “All” selected
User can switch to “Pending” or “Paid” view. Based on selection, results are displayed in the table
Download PDF
Download PDF should download PDF format of Household Register with name of document as HH_Register_<Date>
WhatsApp Share
Should trigger same PDF as Whatsapp share
Columns
Connection ID
New Connection ID of the consumer. If there is a metered connection, an “M” in ⭕️ is shown alongside connection ID
Name
Name of the consumer - Similar to Revenue dashboard truncate it to 20 characters and show 3 dots
Pending Collections
Total pending collections of the consumer till date.
The table has sort options by all columns.
The sorted and filtered table, as in the screen view, is exported into the PDF format dynamically on printing.
Search Consumer records |
|
Filters |
|
Columns |
|
The Administrative user for a GPWSC/Village, i.e., a Sarpanch or anyone with admin access, needs to generate Bill (i.e., generation of monthly bills) for all the consumers. This activity is to be done at the beginning of the month and must be done only once per month. Sarpanch or anyone with admin access has the option to generate the bill for all consumers at once.
Click on the Generate Bill icon on the homepage to bulk generate bills for all consumer connections entered in the app.
Users can select the billing year and billing cycle (month) and click on the Generate Bill button.
Once the bill is generated, revenue can be collected from the users for the generated bill amount
Payments can be collected for consumers with outstanding bill. The collection module can be enabled for revenue collector, treasurer and chairman, as per state's requirement.
Click on the Collect Payment icon on the home page to search for a consumer record by Consumer’s Phone Number or Name of the Consumer or Old Connection ID or New Connection ID.
Click on the Search button to select a particular consumer for payment collection.
If the consumer wishes to receive a soft copy of his/her bill, click on the Share Bill button to send the bill to the consumer on the registered mobile number via WhatsApp message.
Click on the Collect Payment button to collect the payment via cash.
Full Payment or Partial Payment to indicate whether the consumer is paying the bill amount in full or making a partial payment. Enter the Amount that is being paid by the consumer in case it is a Partial Payment.
Click on the Download Receipt button to download the payment receipt. Click on the Share icon to send the receipt to the consumer via WhatsApp message.
Click on the Consumer Receipt Print button to print the receipt for consumer through thermal Bluetooth printer
Once the payment is completed an SMS is sent to the consumer to confirm the paymen with a copy of payment receipt.
Clicking on the Dashboard on the home screen navigates the user directly to the revenue dashboard of the current month. From here, the user can switch to the expenditure tab to get a view of expenses. This provides a tabular view of all expenses incurred in that month.
Following are the data points/actions needed on the screen:
Item | Description |
---|---|
The table on the screen is a horizontal scrollable one with the leftmost column fixed.
Click on the Create Consumer icon on the screen to create a new consumer.
This opens the Consumer Details screen. Enter the requested consumer details.
Name
Gender
Father Name
Phone Number
Old Connection ID
Door Number
Street Name/Number
Ward Name/Number
Type of Connection
Type of Water Supply
If the Type is non-metered
Previous Billing year and cycle
If Type is metered
Previous meter reading date
Meter number
Previous meter reading
Radio Button
Arrears: Enter the Arrear amount and penalty as of the billing cycle.
Advance: Enter the advance amount as of the billing cycle.
Users can also edit the consumer details if any changes need to be made in the consumer record. Click on the Edit Consumer Details icon on the home screen to make the necessary changes.
Check the option Mark this connection as Inactive to indicate that the given consumer connection is inactive.
Click on the Submit button to save these changes.
Users can enter the expense details as and when incurred. Click on the Add Expense icon on the home page.
Enter expense information like Type of Expense from the drop-down list available. The type of expenses can be Electricity, O&M, Salary & MISC etc.
Enter Vendor Name, Amount, Bill Date, and Party Bill Date. Select Yes or No to indicate if the bill is paid or not. Click on the Choose File button to attach a supporting document.
Enter the Payment Date if the bill is already paid before recording it into the system. Click on Submit to register the expense details.
The expenditure entry is saved successfully.
Click on the Modify Expenses icon on the home page to modify expense details. Enter the Vendor Name, Type of Expense or Bill ID details to search for the specific expense record which needs to be modified.
The system shows the expense records filtered by the search parameter. Click on the Update Expenditure button to modify a particular bill.
Make the necessary modifications to the bill. Update the expense type, or vendor name, amount, or bill date details as required.
Click on Submit to save the changes. Check the Mark this Bill as Cancelled box to indicate that the bill is cancelled.
Rate Masters can only be updated by Division Users. Login into your ID using your credentials. Check the Page for help.
After login, select the Village from the dropdown menu.
After selecting the village, the user will get the Menu panel meant for Division users. Here you will get the following options to use:
Create user
Search Village User
Search Department User
Rate Master Dashboard
Edit Rate Master
Edit Penalty Master
Click on “Edit Rate Master”. After Selecting the “Edit Rate Master”, User will get the following screen.
User can search by “Property Type”, “Service Type” and “Calculation Attribute” by selecting any from the dropdown.
User can search by “Property Type” by adding the value in the “Text Box”
Click on “Add Master Data” for adding new Master rate for the village.
After Selecting the “Add Master Data”, User will get the following screen.
Select the “Property Type” as either “Residential” or “Commercial”.
Select the “Service Type” as “Non-Metered”.
Select 'Calculation Attribute' as 'Flat'.
Enter the Minimum Charges in the given text box as the master rate of the village. For example, we have added 100, as shown in the screenshot below.
Click on “Add Data”
After clicking on 'Add Data,' ₹100 has been set as the master rate for the village Baho Yatri, as shown in the screenshot above.
If the user wants to add a metered rate for the village, please follow these steps:
Click on “Edit Rate Master”,
After Selecting the “Edit Rate Master”, User will get the following screen.
Click on “Add Master Data” for adding new Master rate for the village.
After Selecting the “Add Master Data”, User will get the following screen.
Select the “Property Type” as “Commercial”.
Select the “Service Type” as either “Metered”.
Select 'Calculation Attribute' as 'Flat'.
Click on Add slab for Metered Connections.
Enter the slabs defined by Panchayat or the Water Supply Department. For example, we have added as per the following:
0 – 100 KL - 100 Rs.
101 – 200 - 150 Rs.
Click on “Add Data”.
Metered Rated for Commercial Connection has been added by the system.
If the user wants to Update or Disable the Rate Master for the village with Non-Metered Connections, please follow these steps:
Click on “Edit Rate Master”,
After Selecting the “Edit Rate Master”, User will get the following screen.
Click on any existing Rate Master, as shown in the screenshot above, that the user wants to edit or disable.
After Selecting the existing Rate Master, User will get the following screen.
Click on “Take Action”.
To disable the Rate Master, click on 'Disable Master'. User will see message confirming that master has been disabled.
After Step 5, if the user clicks on 'Edit Master,' they will see the screen shown below.
Update the minimum charges to ₹100 as an example.
To enable a disabled Rate Master, click on the disabled Rate Master you want to enable.
For example, the user clicked on a disabled Metered Rate Master to enable it.
Click on ‘Take Action’.
Click on ‘Enable Master’
Click on the View Consumer Details button to perform the necessary action.
The journey of PFM Mission in Punjab began in January 2021 with signing of a tri party MoU among The Department of Governance Reforms and Public Grievances (DGR & PG), the Department of Finance (FD), Punjab, and eGov Foundation to provide a systemic solution to enhance public finance management in the state.
The pilot was agreed to be carried out in the Department of Water Supply and Sanitation (DWSS).
Multiple learning sessions with the DWSS officials were conducted to gain in-depth knowledge on current processes and systems, pressing challenges, and how the Mission can design potential solution(s) to the identified problem/s. After these discussions, the following problem statement was identified:
Visibility into financial sustainability of GPWSC run schemes:
The water charges (funds) collected by the GPWSC for their schemes and expenditures made thereof are not visible to the DWSS or the Department of Finance (FD)
Such transparency is necessary since DWSS funds the asset creation and provides for O&M and electricity charges shortfall of GPWSC, if any
To solve the above problem statement, eGov Foundation in consultation with the DWSS, Government of Punjab, identified Anandpur Sahib (APS) as the pilot division to implement mGramSeva. mGramSeva, a mobile application, envisions to capture all the Revenue and Expenditure details in digitized format which will bring in accountability and transparency of GPWSC funds, as well as enable and empower frontline leaders of the Panchayats.
The mGramSeva solution adoption highlights are given below:
In APS division there are more than 76 schemes and 100 villages which are GPWSC run schemes, for which the water bills are generated manually
No automated or digital system currently in place to notify the household through SMS for bills generated
Manual recording all the receipts and expenses in cash book
Sarpanch does not have access to real time information on collection and expenditure
Household information records are maintained manually
Install AWS. Follow the subsequent steps to begin the setup of NalJalSeva.
Create and add users on the NalJalSeva platform post-installation
Automate user creation in NalJalSeva - manage user roles and permissions
Load consumer data into the system
Localise the Nal Jal application to local languages
Change the master rates in Nal Jal
APIs to create property and consumers
API to create users with specific roles
Register SMS templates with the template ID
Configure the master data details
Add new tenants to the system
Add workflows to the system
We currently use the free Let's Encrypt SSL certificate, which is valid for 90 days and must be manually renewed afterwards. There are also several paid SSL certificate options available globally.
NalJalSeva architecture details
NalJalSeva is built on top of the DIGIT Platform. It consists of distinct layers listed below.
Back End - Core Services
User Services (egov-user)
User OTP (user-otp)
Access Control (access-control)
MDMS
ID Generation Service (id-gen)
Payment Gateway (pg-service)
Workflow Service (wf-service)
Encryption Service (data-encryption-service)
Localization Service (localization-service)
Boundary Service (boundary-service)
Location Service (location-service)
URL Shortening Service (url-shortening-service)
PDF Generation Service (pdf-generator)
SMS Notifications (notification-sms)
Email Notifications (notification-email)
Business Services
Dashboard Analytics (DSS)
Municipal Services
Property Service (property-services)
Water Service Calculator (ws-calculator)
Water Service (ws-service)
eChallan (echallan)
User Events (user-event)
Vendor
The sequence diagram below illustrates a typical interaction between the various services. Sample sequence diagram for a typical flow of DIGIT Microservices.
Search Expense Bills
Search by Bill ID or Vendor
The Vendor Name should be a partial match. As the user starts typing a consumer name, respective vendors get filtered in the table displayed below
Bill ID should be a partial match. As the user starts typing a New Bill ID, respective Bills should get filtered in the table displayed below
Filters
Default is “All” View. Switching to Paid or Pending filters the table accordingly. Alongside the filter, how many Bills fall into that filter is shown in numbers
The table also has sort options for each column (ascending, descending)
Columns
Bill ID - Vendor Name
Bill ID is assigned to each bill while creating an expense entry record
Sort happens on the Bill ID
Expense Type
Under which expense head the bill is tagged to
Amount
Bill Date
Paid Date
If Bill is not paid, this should show pending in RED
The Dashboard provides the stakeholders at the department level with a consolidated view of the information on Revenue and Expenditure trends month-wise.
The Sarpanch, Treasurer and Secretary at the GPWSC level can view the collection details like Demand, Pending Collection, Actual Collection, Collection from Residential, Collection from Commercial and Collection from Others. The consumer-wise collection details view is also available.
The Sarpanch, Treasurer and Secretary at the GPWSC level can view the expenditure details like total expenditure, the amount unpaid, the amount paid, total bills, pending bills, bills paid, Electricity bills, O&M and salary. The individual expense-wise details view is also available.
Metered & Non-Metered Connection
Click on the Generate Demand icon on the home page to search for a consumer record once the consumer is created. The application enables the users to search a consumer record by Consumer’s Phone Number or Name of the Consumer or Old Connection ID or New Connection ID.
Click on the Search button to view the consumer records. Click on the View Consumer Details button to perform the necessary action.
Users can see the relevant information of a particular consumer. Click on Generate a New Bill button to create a fresh bill. Enter the Previous Meter Reading, New Meter Reading and Meter Reading Date. Click on Generate Bill. A fresh bill is generated for the consumer.
Once the bill is generated, the user can collect payment for the particular bill. Click on the Collect Payment button to collect the payment via cash or online payment.
Click on the phone icon in green to share the bill with the consumer via SMS.
Enter/Update the Payment Amount or Partial Payment to indicate whether the consumer is paying the bill amount in full or making a partial payment. Enter the Amount that is being paid by the consumer in case it is a Partial Payment.
Select the applicable Payment Method as either Cash or Online. Users can also provide consumers with a scannable QR code to make the payment online.
Click on the Download button to download the payment receipt.
Click on the Share icon to send the receipt to the consumer via SMS.
Click on the Collect Payment icon on the home page to search for a consumer record by Consumer’s Phone Number or Name of the Consumer or Old Connection ID or New Connection ID.
Click on the Search button to view the consumer records. Click on the View Consumer Details button to perform the necessary action.
Click on the Collect Payment button to collect the payment via cash or online payment. Click on the Share Bill button to send the bill to the consumer on the registered mobile number via SMS.
Select Full Payment or Partial Payment to indicate whether the consumer is paying the bill amount in full or making a partial payment. Enter the Amount that is being paid by the consumer in case it is a Partial Payment.
Select the applicable Payment Method as either Cash or Online. Users can also provide consumers with a scannable QR code to make the payment online.
Click on the Download button to download the payment receipt. Click on the Share icon to send the receipt to the consumer via SMS.
Once the payment is completed an SMS is sent to the consumer to take the survey on the water service.
Tools and technologies used to setup, build and deploy NalJalSeva stack
DIGIT being an open-source platform, all the tools and tech stack used to build, deploy and operate DIGIT - are also open-sourced and community edition. The tools used to set up, develop and deploy the NalJalSeva stack are listed below with the specific versions used and short descriptions.
Platform Tools | Latest Version | Used Version | Description | License Type | |
---|---|---|---|---|---|
This page provides step-by-step details on setting up a git repo for code, configs, V1 MDMS, and Infra As Code.
Fork the following repos that contain the master data and default configurations. Customize the data (master data, ULB, Tenant details, Users, etc) as per specific implementation requirements in the respective GitHub organization accounts.
Follow the steps given below to set the git repository,
both the , and repos into your GitHub organization account.
Create a , and generate an SSH authentication key (and .
Enable new GitHub users to access the forked repos.
Add the ssh private key generated in the previous step to the within the git-sync section.
Update the services in the git-sync repository by specifying the forked repository and branch in the file.
Update the deployment configuration details for the below as per your specifications:
Number of replicas/scale of each service (depending on whether dev or prod load)
You must update the SMS gateway, email gateway, and payment gateway details for the notification and payment gateway services, etc.
Update the config and MDMS GitHub repos wherever marked.
Update GMap key (In case you are using Google Map services in your PGR, PT, TL, etc)
Create one private S3 bucket for Filestore and one public bucket for logos. Add the bucket details respectively and create an IAM user with the s3 bucket access. Add IAM user details to .
URL/DNS on which DIGIT will be exposed.
SSL certificate for the above URL.
Any specific endpoint configurations (Internal/external).
Domain or subdomain registry and mapping cname
Follow the steps provided on this page to configure domains or subdomains registry and mapping CNAME.
Create a CNAME (Canonical Name) entry in your domain's DNS settings and point it to the AWS load balancer or gateway URL. The external IP for the domain is provided by the AWS load balancer or gateway.
The domain name is the address through which the internet users can access the website rather than entering the whole IP address in the search bar of the browser.
This domain name is ideally chosen by the state/client since it is a product that has to be used for/by them.
Following is the table through which the information can be shared.
Note: The data given in the table is sample data.
Since all state governments/clients prefer to host the websites on their servers, this activity is ideally done by them.
Following are the steps which are to be followed:
Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
If the state agrees to host the website on their server, provide them with the 2 columns mentioned in the attached template.
If the state disagrees to host on their server, then a domain name has to be purchased by any of the external vendors and the EXTERNAL-IP address has to be mapped with them.
Verify the data once again by going through the checklist and making sure that each point mentioned in the checklist is covered.
This checklist covers all the activities that are common across the entities.
Following is the attached configurable data template in case the state is doing the required activities.
Configurable Data Template - Domain Name Configuration
Sample Configurable Data - Domain Name Configuration
Make sure the below-mentioned permissions are allowed or accepted:
Internet access
FileStore read and write
Bluetooth connection
Request packages
Query all packages
Download the flutter sdk from
Install for setting the IDE.
Open Android Studio. Open plugin preferences (File > Settings > Plugins) and select Marketplace. Select the Flutter plugin and click Install as shown in the image below. Click Yes when prompted to install the Dart plugin.
Set the Flutter SDK path in android studio by navigating to (File > Settings > Plugins > Language & Frameworks >>flutter) flutter as shown in the image below.
Add the flutter path to the system path variable for running the flutter commands as shown in the image below.
Open a new terminal and run the flutter doctor command. This downloads the respective Dart SDK version and runs flutter doctor--android-licenses to accept the android licenses.
Select the AVD manager from the right-side top corner as shown in the image. Now, select any device by tapping on the play button. The Android Studio launches the emulator and the device is auto-selected. There are two modes for running the application - play and debug. Tap on any one of the modes to launch the mGramSeva application in the emulator as shown in the image.
Select the Chrome option from the device selection and tap on the play button. This launches the application on a Chrome window.
Navigate to mgramseva folder → cd punjab-mgramseva/frontend/mgramseva
+3 => version code (increment by +1 every time)
Execute the flutter clean command → flutter clean
Execute the flutter pub get command → flutter pub get
Build the prod app bundle → flutter build appbundle Check the attached drive link below which includes the key-store, and version tracker. Update the version and release date in the sheet. Path → D:\mgramseva_prod\punjab-mgramseva\frontend\mgramseva\build\app\outputs\bundle\release\app-release.aab
2. Connect your Phone to the system and enable File transfer.
3. Select the AVD manager(your Phone) from the right side top corner in Android Studio
4. Go to the frontend/mgramseva/utils/execute_integration.sh file and run it.
5. The integration test will start on your device.
S.No. | Column Name | Data Type | Data Size | Is Mandatory? | Description |
---|
S.No. | Checklist Parameter | Example |
---|
The steps below guide us to run the project on both Web and Mobile 1. Clone the project from the . 2. Open the project in android studio by selecting (File > open), select the flutter project (punjab-mgramseva/frontend/mgramseva) from the cloned path as shown in the image below.
Note: To resolve the cors error follow the steps provided in this
key storeGoogleClone the Repo → git clone
Upgrade the version in the (version: 1.0.2+3) 1.0.2 => version name (which is displayed in play store)
Replace the base Url with Prod Url File → _baseUrl: window.location.origin + "/", => _baseUrl: " "
Comment the below line File → export 'dart:js' show allowInterop, allowInteropCaptureThis;
Download the key store from the below link Add this properties file to the android app folder as shown in the image below - android → key.properties
Download the Google service JSON from the link below Add this JSON file to the Android app folder as shown in the image below android → app → google-services.json
1. Enable the USB debugging option on your Mobile Phone. ( )
6.2.0
5.4.1
Apache Kafka is an open-sourced and community distributed event streaming platform capable of handling trillions of events a day.
6.2.0
5.4.1
ZooKeeper is an open-source Apache project that provides a centralized service for providing configuration information, naming, synchronization and group services over large clusters in distributed systems. When working with Apache Kafka, ZooKeeper is primarily used to track the status of nodes in the Kafka cluster and maintain a list of Kafka topics and messages.
Zuul
2.3.0
2.2.2
Zuul is an open-sourced edge service that proxies requests to multiple backing services. It provides a unified “front door” to your system, which allows a browser, mobile app, or other user interfaces to consume services from multiple hosts without managing cross-origin resource sharing (CORS) and authentication for each one.
8.0.0
6.6.2
Elasticsearch is a distributed, free and open search and analytics engine for all types of data, including textual, numerical, geospatial, structured and unstructured.
Kibana
8.0.0
6.6.2
Kibana is a free and open frontend application that sits on top of the Elastic Stack, providing search and data visualization capabilities for data indexed in Elasticsearch.
1.8.3
1.0.6
Fluent Bit is an open-source and multi-platform Log Processor and Forwarder which allows you to collect data/logs from different sources, unify and send them to multiple destinations. It's fully compatible with Docker and Kubernetes environments.
13.4
9.6 and 10.6
PostgreSQL is a powerful, open-source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance
redis
6.2.5
3.2.6
Redis is an open-source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyper logs, geospatial indexes, and streams.
Jaeger
1.25.0
1.18
Jaeger is open-source software for tracing transactions between distributed services. It's used for monitoring and troubleshooting complex microservices environments.
Dev Stack
Latest Version
Used Version
Description
License
Type
OpenJDK
JDK11
8u212
OpenJDK is completely open-source and can be used freely
GPL-2
2.2.6
Spring Boot is an open-source micro-framework maintained by a company called Pivotal. It provides Java developers with a platform to get started with an auto configurable production-grade Spring application.
React
17.0.2
16.7.0
React is one of Facebook's first open-source projects that is both under very active development and is also being used to ship code to everybody on facebook.com.
MIT
16.8.0
Material-UI CE (Community Edition) has been 100% open-source (MIT) since the very beginning, and always will be. Developers can ensure Material-UI is the right choice for their React applications through Material-UI's community maintenance strategy.
MIT
NodeJS
14.0
8.4.0
Node. js is an open-source, cross-platform, JavaScript runtime environment. It executes JavaScript code outside of a browser.
MIT
DevOps Stack
Latest Version
Used Version
Description
License Type
Kubernetes
1.22
1.18.x
Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
Docker
19.03.14
19.x
Docker, a subset of the Moby project, is a software framework for building, running, and managing containers on servers and the cloud.
Helm
3.6.3
3.x.x
Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes.
1.1.0
v0.14.10
Terraform allows infrastructure to be expressed as code in a simple, human-readable language called HCL (HashiCorp Configuration Language).
Jenkins
2.306
2.289
Jenkins – an open-source automation server that enables developers around the world to reliably build, test, and deploy their software.
MIT
Go Lang
1.16.7
1.13.3
Go is an open-source programming language that makes it easy to build simple, reliable, and efficient software.
Groovy
3.0.8
3.0
Apache Groovy is a powerful, optionally typed and dynamic language, with static-typing and static compilation capabilities, for the Java platform aimed at improving developer productivity thanks to a concise, familiar and easy to learn syntax.
Python
3.9.6
v3.9.6
Python software and documentation are licensed under the PSF License Agreement. Starting with Python 3.8.6,
PSF
Sops
v3.7.1
v3.7.1
sops is an editor of encrypted files that supports YAML, JSON, ENV, INI and BINARY formats and encrypts with AWS KMS, GCP KMS, Azure Key Vault, age, and PGP.
Ansible
2.11.3
v2.9.23
Ansible is an open-source community project sponsored by Red Hat, it's the simplest way to automate IT.
GNU General Public License
yaml
1.2
1.2
YAML is a human-readable data serialization standard that can be used in conjunction with all programming languages and is often used to write configuration files.
License
Domain Name | Alphanumeric | 253 | Yes | The name/address of the website being used to access the website/ module |
EXTERNAL-IP | Alphanumeric | 32 | Yes | It is the IP address that has to be mapped to the domain name |
This page provides the steps to follow to create a Git account in the client name.
To create a Git account in the client name, follow the steps below:
Register the client on a Git hosting platform such as GitHub, GitLab, or Bitbucket by providing their email address, choosing a username, and setting a secure password.
Once the account is set up, they can start using Git to manage their code repositories and collaborate on software development projects with ease.
This page provides step-by-step instructions for using a Python script to create consumers for NalJalSeva. Follow these guidelines to load consumer data into the system using the Python script provided.
Before running the script, ensure you have a properly formatted Excel sheet. The sheet should include the following columns:
Consumer Name (Mandatory, use "NA" if not available)
Gender (Male/Female)
Father Name (Mandatory, use "NA" if not available)
Mobile Number (Mandatory)
Old Connection Number
Property Type
Service Type (till now we have Non-metered only for data loading)
Ward (Always set to "Ward 1")
Meter Reading (If available, use the provided date; otherwise, default to "12/01/2022")
GPWSC Name
Arrears
Previous Reading ((if arrears and previous reading are not given, write '0')
Ensure the format of the meter reading matches the provided sample format given in the Excel file below, as incorrect formatting may lead to loading failures.
Edit the Python script with the following details:
Set the host URL based on whether it's for production, QA, or UAT.
Provide the username and password corresponding to your host URL.
Specify the path where your Excel file is stored. It is recommended to store the Excel file in the same location as your Python script.
Execute the Python script after configuring the host URL, username, password, and file path. The script will load data into mGramSeva based on the information provided in the Excel sheet.
Do not open the Excel file until the script completes its task. After completion, open the Excel file to check the status. The status will indicate whether the operation was successful or if there was a failure. If there's a failure, refer to the reason for further investigation and resolution.
This page provides a clear and concise guide for automating user creation in NalJalSeva. It allows you to efficiently create users and manage their roles in the system.
Follow the steps provided on this page to create users for NalJalSeva using a Python script. The process involves preparing an Excel sheet with user information, configuring the Python script, and executing it.
Python script for creating users for NalJalSeva.The sample format of the Python script is attached below.
Excel sheet containing user data. The sample format of the Excel sheet is attached below. Make sure to populate the data in the same format.
Columns: tenant name, mobile no, father name, gender, date of birth (dd/mm/yyyy), type, and ward (fixed to "ward 1").
Types: Sarpanch, Secretory, Revenue Collector, Division User or State User
Roles for Sarpanch: COLLECTION_OPERATOR, EXPENSE_PROCESSING, BULK_DEMAND_PROCESSING, DASHBOARD_VIEWER, GP_ADMIN.
Roles for Secretory: EXPENSE_PROCESSING, BULK_DEMAND_PROCESSING, DASHBOARD_VIEWER, GP_ADMIN, COLLECTION_OPERATOR.
Roles for Revenue Collector: COLLECTION_OPERATOR, DASHBOARD_VIEWER.
Roles for Division User: HRMS_ADMIN, DIVISION_ADMIN
Roles for State User: HRMS_ADMIN, STATE_ADMIN
Prepare the Excel Sheet:
Create an Excel sheet with the following columns and data in the given format:
Tenant Name (in lowercase)
For State User tenant name will be pb
Mobile Number
Father's Name (Mandatory, use "NA" if not available)
Gender (M/F - this data is mandatory)
Date of Birth (in the format dd/mm/yyyy)
Type (Sarpanch, Secretory, Revenue Collector, Division User or State User)
Roles - Based on the User Type, set corresponding roles:
Sarpanch: COLLECTION_OPERATOR, EXPENSE_PROCESSING, BULK_DEMAND_PROCESSING, DASHBOARD_VIEWER, GP_ADMIN
Secretary: EXPENSE_PROCESSING, BULK_DEMAND_PROCESSING, DASHBOARD_VIEWER, GP_ADMIN, COLLECTION_OPERATOR
Revenue Collector: COLLECTION_OPERATOR, DASHBOARD_VIEWER
Division User: HRMS_ADMIN, DIVISION_ADMIN
State User: HRMS_ADMIN, STATE_ADMIN
The 'Boundary' should be set to "Ward 1" as per mGramSeva standards.
Run the Python Script:
Open the Python script.
Provide the following information within the script:
Host URL: Specify the target environment (prod, qa, or uat).
Username and Password: As per your host URL.
Path to the Excel file: Ensure the Excel file is in the same location as the script.
Execute the script.
Post-Execution:
Do not open the Excel file until the script has completed its task.
After the script finishes, open the Excel file to review the results.
The Excel file will contain two columns:
User ID: If successful, the ID will be present.
Status: Will indicate either "Success" or "Failure." If failed, the reason for failure will be provided.
Steps to create and add users on NalJalSeva platform post-installation
Follow the steps provided on this page to create and add users on the mGramSeva platform once the installation is complete.
Ensure the Postman utility is installed to run the following scripts. If not, Install Postman on the local machine.
There are two methods to create users - either through API or through port-forwarding. To create users through port-forwarding refer here.
Follow the steps given below to create different types of users through the API.
There are primarily three different types of users as listed below:
Super User
Anonymous User
System User
Super User - A superuser is a privileged user account with elevated access rights in a computer system or application. It is typically reserved for administrators or trusted personnel and grants them full control and unrestricted access to all system resources. Superusers are necessary to manage and maintain the system, perform critical tasks, and troubleshoot issues efficiently.
A Superuser is created using the createnovaildate API. Below is the curl given for creating a superuser.
Steps to follow:
Import the curl given below in Postman.
Refresh the authorisation token.
Provide User data as per requirements. This API will create a Super User in production. To add users in any other environment change the URL.
The parameters - userName, name, gender, mobileNumber, tenantId, and password can be changed as per requirements.
Anonymous User -An anonymous user is a generic or unauthenticated user account that does not require login credentials to access certain parts of a system or website. These accounts are essential for providing basic access to public information or services without requiring user registration. They are commonly used to ensure accessibility for a wide audience and encourage user interaction while preserving user privacy. These are used when the system is accessing non-authentication links such as bills and payment receipts.
Creating an anonymous user is the same as creating a superuser. The only difference is to change the name and code in roles. The API below is used to create an Anonymous User in production.
System User - Creating a system user is the same as creating a superuser and anonymous user. The only difference is to change the name and code in roles.
While creating any user make sure your roles are present in ACCESSCONTROL-ROLES.
Here, 'pb' is used as tenantId since we are creating users at the state-level.
Sr. No. | Domain Name | EXTERNAL-IP |
1. | 3.108.166.195 |
1 | Make sure that each and every point in this reference list has been taken care of. |
This page outlines the step-by-step process for using a Python script to change master rates for NalJalSeva in bulk. The script reads data from an Excel file, updates the master rates, and generates a new CSV file containing the modified information. Once the script is successfully executed, changes can be pushed to the local MDMS repository on GitHub.
Python script
MDMS repository cloned on the local system
Excel file with tenant names, old master rates, and new master rates
1. Prepare Excel File:
Ensure the Excel file contains three columns: Tenant Name (in lowercase), Old Master Rate, and New Master Rate.
If the columns are not present, add them to the Excel file.
2. Clone and Create Branch:
Clone the MDMS repository to your local system.
Create a new branch from the branch where you intend to make changes.
3. Update Python Script:
Open the Python script and locate the variables:
updatedfile
: Provide the path to your Excel sheet.
localFilePath
: Specify the path where your MDMS repository is cloned.
Identify the columns in the Excel file where the Tenant Name, Old Master Rate, and New Master Rate are stored. Update the script accordingly:
Run the script.
4. Script Execution:
Do not open the Excel file during script execution.
The script will generate a new file named new_updated_file4.csv
containing information about whether rates were updated or not.
5. Verification:
Check new_updated_file4.csv
to verify if all rates were updated successfully.
6. Push Changes to Git:
If all rates are updated, the local changes will affect the MDMS repository.
Raise a pull request and merge changes from the Git repository.
Note:
It is crucial not to open the Excel file while the script is running to avoid data inconsistencies.
Ensure that the Python environment and dependencies are properly set up.
Follow the above steps to update NalJalSeva master rates in bulk, and ensure precise and streamlined changes to the MDMS repository.
NalJalSeva's Master Data Management System () is organized into several folders, each containing essential JSON files that define various aspects of the application's configuration. This documentation provides an overview of the key folders and their respective files, along with a description of the data contained within each file.
1.
This folder contains the actions-test.json
file, which defines various API endpoints along with their configurations.
id
: Unique identifier for the API endpoint. Increase id with respect to id present in action-test.json file.
name
: Name of the endpoint.
url
: URL of the API endpoint.
Other things
: As per your specific requirements.
This folder contains the roleactions.json
file, which associates roles with action IDs.
rolecode
: Code representing the role
actionid
: Action ID associated with the role, linking to entries in actions-test.json
actioncode
: Additional code for the action if needed
tenantId
: Tenant ID associated with the role
This folder contains the roles.json
file, defining roles in the system.
code
: Code representing the role
name
: Name of the role
description
: Description of the role
This folder contains various JSON files related to billing services.
4.1 BusinessService.json
Defines business services, such as expenses like electricity bills and salaries.
businessService
: Identifier for the business service.
code
: Code representing the business service.
collectionModesNotAllowed
: Collection modes not allowed for the service.
partPaymentAllowed
: Indicates whether part payment is allowed.
isAdvanceAllowed
: Indicates whether advance payment is allowed.
isVoucherCreationEnabled
: Indicates whether voucher creation is enabled.
isActive
: Indicates whether the service is active.
type
: Type of the service.
4.2 PaymentService.json
This file, located in the billingservice
folder provides configurations for payment services within the Billing Service module.
tenantId
: The identifier for the tenant associated with the configuration.
moduleName
: The name of the module, in this case, "BillingService."
PaymentService
: An array containing configurations for different payment services.
Payment Service Configuration:
businessService
: Identifier for the business service.
code
: Code representing the payment service.
collectionModesNotAllowed
: Array specifying modes of payment not allowed for this service.
"DD"
: Demand Draft
"CHEQUE"
: Cheque
"CARD"
: Card
"OFFLINE_NEFT"
: Offline NEFT
"OFFLINE_RTGS"
: Offline RTGS
"POSTAL_ORDER"
: Postal Order
"ONLINE"
: Online
partPaymentAllowed
: Indicates whether part payment is allowed for this service.
isAdvanceAllowed
: Indicates whether advance payment is allowed for this service.
demandUpdateTime
: Time interval (in milliseconds) for updating demands.
isVoucherCreationEnabled
: Indicates whether voucher creation is enabled for this service.
billGineiURL
: URL for generating bills using Bill Genie.
isBillAmendmentEnabled
: Indicates whether bill amendment is enabled for this service.
This configuration specifies the payment modes not allowed for the "ws-services-calculation" business service, whether part payment and advance payment are allowed, the demand update time, voucher creation status, Bill Genie URL, and bill amendment status.
4.3 TaxHeadMaster.json
This file is responsible for defining the various charges and taxes which are going to be configured in the application.
4.4 TaxPeriod.json
This file is used to define the number of financial years which are supported in each tax head.
This folder contains various JSON files related to ws-services-masters.
This folder contains various JSON files related to property tax.
This folder contains expense type in JSON format.
All (1 to 8 points) are state-level changes.
For each tenant, there is a unique folder containing three subfolders, each with its specific configuration files.
1. businessservice.json
- Billing Service Configuration
This file, located in the billing service
folder, provides tenant-specific configurations for the Billing Service module. It is similar to the global BusinessService.json
configuration but is specific to the tenant.
2. boundary-data.json
- Location Boundary Data Configuration
This file, located in the egov-location
folder contains boundary data specific to the tenant.
Details of the structure and content of this file would be specific to the actual data in the system. Please refer to the specific boundary-data.json
file for detailed information.
3. WCBillingSlab.json
- Water Connection Billing Slab Configuration
This file, found in the ws-services-calculation
folder defines billing slabs for water connection based on building type and connection type.
id
: Unique identifier for the billing slab.
buildingType
: Type of the building (e.g., RESIDENTIAL).
connectionType
: Type of connection (e.g., Metered).
calculationAttribute
: Attribute used for calculation (e.g., Water consumption).
minimumCharge
: Minimum charge for the billing slab.
slabs
: Array defining the billing slabs, including from
, to
, charge
, and meterCharge
.
This configuration is used to determine rates for water consumption based on the specified billing slab criteria.
This page provides a comprehensive guide on using the CreateNovaildate API to create users with specific roles based on their responsibilities within the system. Adjust the parameters and roles as needed for your specific requirements.
The API allows users to create a new user with specified details that include username, name, gender, mobile number, activation status, user type, tenant ID, and password. Refer to the details available below.
Additionally, users can be assigned specific roles based on their responsibilities.
username (string): User's unique username.
name (string): Full name of the user.
gender (string): Gender of the user.
mobileno (string): User's mobile number.
active (boolean): User's account status (true for active, false for inactive).
type (string): It will be EMPLOYEE only.
tenantid (string): User's tenant ID.
password (string): User's password.
Roles: Roles determine the permissions and responsibilities assigned to a user.
The available roles are as follows:
Roles for Sarpanch
COLLECTION_OPERATOR
EXPENSE_PROCESSING
BULK_DEMAND_PROCESSING
DASHBOARD_VIEWER
GP_ADMIN
Roles for Secretary
EXPENSE_PROCESSING
BULK_DEMAND_PROCESSING
DASHBOARD_VIEWER
GP_ADMIN
COLLECTION_OPERATOR
Roles for Revenue Collector
COLLECTION_OPERATOR
DASHBOARD_VIEWER
Roles for Division User
HRMS_ADMIN
DIVISION_ADMIN
Roles for State User
HRMS_ADMIN
STATE_ADMIN
To assign roles to a user, include the desired roles in the roles
section of the request. PROFILE_UPDATE role is available for every user to update existing roles.
This page provides details on how to register the SMS templates with the specified TEMPLATE ID for each Localization key and append the TEMPLATE ID at the end of the message in the Localization system.
To register the provided SMS templates with a specific TEMPLATE ID for each Localization key and append the TEMPLATE ID at the end of the message
The sample SMS messages in the table below have to be registered with a specific TEMPLATE ID (Eg.'100700746377980') for each Localization key.
Append the TEMPLATE ID at the end of the message.
Push the SMS templates in Localisation.
Action | Localization key | Localization message |
---|
This page provides step-by-step instructions for creating a consumer in the mGramSeva system using two API calls. The first API call is to create a property, and the second API call is to make a connection for the consumer.
Before proceeding with the given tasks, ensure the following prerequisites are met:
Authentication Token (authToken): Obtain a valid authentication token for the desired environment. This token is necessary to authenticate and authorize your requests.
API Endpoints: Ensure you have access to both APIs required for creating a property and a consumer. Make sure you have the correct API documentation or information about the endpoints, request payloads, and any required headers.
Postman: If you don't have Postman installed, download and install it. Import collection in Postman. Make sure you change the URL as per your requirements.
Follow the steps given below to create consumers using either Property Create API or Consumer Create API.
Here's a step-by-step guide:
Locate the Property Creation API:
Open the Postman collection you imported.
Find the request corresponding to the Property Creation API. It might be named something like "Create Property" or similar.
Set Request Parameters:
Review the request parameters for creating a property.
For metered connections, provide values for initialMeterReading
, meterReading
, meterId
, and previousReading
. Set them to null if not applicable.
Set ConnectionType
to "Metered" for metered connections and "Non_Metered" for non-metered connections.
Ensure that oldConnectionNo
is unique every time you create a property.
Execute the Request:
Click on the "Send" button to execute the request.
Review the response to confirm that the property has been created successfully.
Copy Property ID:
In the response, you should find the propertyId
field. Copy the value of propertyId
as this will be needed for subsequent steps.
Now, you have successfully created a property, and you have the propertyId
copied for future use. Ensure to follow any additional instructions provided in the Postman collection or the API documentation.
Follow the steps below to create a consumer using the Consumer Creation API from the Postman collection:
Locate the Consumer Creation API:
Open the Postman collection.
Find the request corresponding to the Consumer Creation API. It may be named "Create Consumer - Metered" for metered connections or "Create Consumer - Non-Metered" for non-metered connections.
Set Request Parameters:
Review the request parameters for creating a consumer.
For metered connections, provide values for initialMeterReading
, meterReading
, meterId
, and previousReading
. Set them to null if not applicable.
Set ConnectionType
to "Metered" for metered connections and "Non_Metered" for non-metered connections.
Ensure that oldConnectionNo
is unique every time you create a consumer.
Use the propertyId
obtained from creating the property as instructed in the previous step.
Execute the Request:
Click on the "Send" button to execute the request.
Review the response to ensure that the consumer has been created successfully.
By following these instructions and providing the necessary details, you should be able to successfully create a consumer with a property and connection in the NalJalSeva system. Ensure that you follow any additional guidelines or instructions provided in the Postman collection or API documentation.
2.
3.
4.
This folder contains various JSON files related to ws-services-calculations.
(City level changes for every city there is one folder in MDMS)
There is a folder in the MDMS which contains all tenants in file.
First time login OTP | RESET_PASSWORD_FIRST_TIME_OTP | OTP to reset password on NalJal is {otp} |
Forgot Password OTP | RESET_PASSWORD_OTP | OTP to reset password on NalJal is {otp} |
Creation login details | MGram.User.Invitation | Dear {USER}, You've been invited to NalJal Application. Please login using {LINK}. Username: {PHNO} Password: {PASSWORD} |
Demand (Bulk) | mGram.GP.MonthlyDemandGenerated | Dear {ownername}, Demand for Billing Cycle {billingcycle} has been generated for {tenant -name}. Kindly plan for collection of Water Charges for this period. {LINK} DWSS |
Pending Collection Reminder | mGram.GPUser.CollectionReminder | Dear {ownername}, Rs.{amount} is pending collections against Water Charges at {WIMC} as of {Date}. Click {PENDING_COL_LINK} to see more details. DWSS |
New Calendar Month | mGram.GPUser.PreviousMonthSummary | Dear {user}, Rs.{PREVIOUS_MONTH_COLLECTION} has been collected in {PREVIOUS_MONTH} against water charges & Rs.{PREVIOUS_MONTH_EXPENSE} has been spent as expenditure for {WIMC}. Click {LINK} to see more details. DWSS |
Fortnight | NEW_ENPENDITURE_SMS_EN_REMINDER | Please enter new expenditure bills online for {WIMC}. Click {NEW_EXP_LINK} to make an expense entry now. DWSS |
Alternate Fortnight | MARK_PAID_BILL_SMS_EN_REMINDER | Expenditure bills for {WIMC} are awaiting payment confirmation. Please click {EXP_MRK_LINK} and mark them as paid, if paid already. DWSS |
Demand (Bulk) - (NM & M) | mGram.Consumer.NewBill | Dear {ownername}, New water bill for Billing Cycle {Period} has been generated for Consumer Id {consumerno} for Rs.{billamount}. Click {BILL_LINK} to download latest bill. DWSS |
Demand (Bulk) - (NM & M)-1 | mGram.consumer.payment.message | Dear {ownername}, Pending Amount for water charges for Consumer Id {connectionno} is Rs.{billamount}. Click {PAY_LINK} to pay online. DWSS |
Bill Paid | Gram.Consumer.DownloadReceipt | Dear {ownername}, Rs.{amountpaid} has been paid for Water Charges for Consumer Id {consumercode}. Pending Amount is Rs.{pendingamount}. Click {RECEIPT_LINK} to Download Receipt. DWSS |
Feedback Collection | mGram.Consumer.TakeSurvey | Dear {ownername}, Thank you for paying water charges. Please take this short survey {SURVEY_LINK} and help us know more about water supply at {WIMC}. DWSS |
This documentation outlines the process of setting up a new tenant in MDMS (Master Data Management System). To achieve this, it involves cloning the MDMS repository locally and utilizing a Python script that interacts with an Excel file containing essential information for the new tenant setup.
Clone the MDMS repository to your local machine.
Have the Excel file ready for reference. The structure of the Excel file is critical, and any changes must align with the specified columns. The reference to the Excel file is given below.
Locate the Python script for adding a new tenant. The script can either be placed in the "tenants" folder locally or specify the full path where your "tenants.json" folder is present within the script.
Open the script and edit the following lines to match your requirements:
Replace "Book2.xlsx" with the name of your Excel file containing tenant information.
Specify the sheet name in your Excel file where the required data is stored.
Ensure your Excel file adheres to the specified format. The columns must match the template provided, and any deviation may result in script failure.
Do not modify the column structure in the Excel sheet, as the script relies on a consistent format.
Execute the Python script after configuring it according to your needs. The script will process the Excel file, and upon completion, a new file named "tenants_new.json" will be generated.
Deploying to MDMS
Copy the generated tenants_new.json
file to the MDMS repository or select and apply the updated data within MDMS as needed.
3KBcreate_tenants_json_Book2.py
After creating a tenant in the tenants.json file we need to make a separate folder in MDMS for each tenant.
Localization is the process of adapting a software application, website, or content to different languages and regions, making it accessible and user-friendly for diverse audiences. It involves translating text, adapting graphics, and configuring settings to suit a specific locale's cultural and linguistic preferences.
To retrieve localization messages in NalJalSeva, use the Search API given below. This API allows you to search for messages based on parameters like locale, tenantId, and apiId. Here is an example using cURL:
To search for messages in different languages and environments, you can customize the parameters such as locale (en_IN, hi_IN, pn_IN) and tenantId. Change the URL to search in any other environment. The current API is specific to the UAT environment.
The Upsert API allows users to update or insert new localization messages into NalJalSeva. This involves refreshing the authentication token and providing details like code, message, module, and locale. Here is an example using cURL:
In this example, you can customize the "code," "message," "module," and "locale" parameters to specify the localization details you want to upsert. Make sure to update the authentication token for security purposes.
Note: The provided APIs are for the UAT environment, and you may need to modify the URLs accordingly for other environments.
Water Connection advance changes are added to allow the customer to pay the advance amount. This amount is adjusted when a new demand is generated. We can enable or disable advance based on the configuration.
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 the water service persister configs path added to it
PSQL server is running and a database is created to store water connection/application data
The following services should be up and running:
egov-persister
egov-mdms
ws-services
billing-service
ws-calculator
egov-apportion-service
Accepts advance amount during water connection creation and while collecting payment
Creates demand for consumer-type water connection-advance
Adjusts the new demand with existing advance with apportion service
Deploy the latest version of ws-service, ws-calculator, billing-service, egov-apportion-service
Billing service tax head configuration
Tax-head master service configuration
Creating a new bill for the advance amount in BillServiceV2. Removing the following line while adding the bill objects to the list if (billAmount.compareTo(BigDecimal.ZERO) >= 0)
Passing Active status filter for demand search during apportioning in DemandService. DemandCriteria searchCriteria = DemandCriteria.builder().tenantId(tenantId) .status(Demand.StatusEnum.ACTIVE.toString()).consumerCode(Collections.singleton(consumerCode)). businessService(businessService).build();
New Demand audit history API in Demandcontroller. An API that returns the audit history of demandDetails. demand/_history
Create water connection API: Adding a check for payment type advance. If advance, passing a boolean isAdvanceCollection to calculationRequest to water calculator service.
Update water connection API: Adding a check for payment type advance. If advance, passing a boolean isAdvanceCollection to calculationRequest to water calculator service. Adding a check for advance in validateUpdate method to set the current demand to CANCELLED.
Calling estimation service getEstimationMap based on isAdvanceCalculation boolean. If true, reading taxAmount from criteria.getWaterConnection().getAdvance();
Changes in getEstimatesForTax for a new taxHeadCode ADVANCE_COLLECTION with value WS_ADVANCE_CARRYFORWARD
Getting the advance amount in getCalculation with taxHeadCode ADVANCE_COLLECTION
Calling generateDemand method based on isAdvanceCalculation. If true, create a demand object with consumerType “waterConnection-advance“.
The purpose of the NalJalSeva IFIX adapter service is to push the demand, bill, and payment events to IFIX from the NalJalSeva.
NalJalSeva IFIX adapter service is a wrapper for pushing data from the NalJalSeva to IFIX. When demand or payment is generated in the NalJalSeva system, the NalJalSeva IFIX adapter service listens to those topics and it calls the IFIX reference adapter service push API to publish the data to IFIX.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Java 8
Kafka
Spring boot
Pushing demand, bill and payment events to the IFIX adapter
The following topics interact with the NalJalSeva IFIX adapter service - When we create demand for ws-services, then it sends an event as demand for IFIX. If it is expense demand, it sends the event as a bill for IFIX. If it is a ws-services payment, then it sends the event as a receipt for IFIX. If it is an expense payment, it sends the payment as an event for IFIX.
naljalseva-create-demand
naljalseva-update-demand
egov.collection.payment-create
Deploy the following build.
ifix-adapter:v1.0.0-4e24064-14
NalJalSeva IFIX adapter is integrated with the IFIX Reference adaptor service. NalJalSeva IFIX adapter Application internally invokes the IFIX Reference adaptor service to push the data.
NalJalSeva IFIX adapter application triggers IFIX-reference-adapter/events/v1/_push to push the demand, bill, and payment events from NalJalSeva to IFIX.
Events push is used to manually push data from the NalJalSeva Adapter to the iFIX Adapter. Make sure the existing events are cleared or deleted to ensure reliable data transfer. Refer to the documentation here to find details on how to clean up the event data - IFIX-Core Data Clean-Up v2.0. Post events clean up the system loads the project code for all the tenants. Then it pushes the data to the iFIX adapter.
Access to Kubectl of the environment targetted
Postman scripts
The Postman script fetches the data from the existing NalJalSeva database and passes it to the NalJalSeva adapter, from where it is pushed to the iFIX adapter.
Pass the offset and limits based on the total transactions present in the database.
Here, TenantId is mandatory. Limit and offset can vary based on the requirement. Business service is not required.
This fetches all payment records irrespective of tenant based on the limit and offset. The data is passed to the IFIX adapter one after the other.
The above curl fetches the demands based on the tenant ID and business service passed. Business service can be ‘WS' or ‘EXPENSE.SALARY’ or 'EXPENSE.MISC’ or 'EXPENSE.OM’ etc. For WS it is saved as demand and for EXPENSE it is saved as bill.
This page provides the steps to follow to create a workflow in NalJalSeva. Here is the reference to the DIGIT workflow service.
Follow the steps below to create a workflow in NalJalSeva.
Follow these steps to create a workflow in NalJalSeva:
Check Existing Workflow:
Utilize the provided Postman collection that includes workflow creation and search APIs.
Use the search API to check if the workflow for the specified state already exists.
Workflow Creation:
If the workflow is not present, proceed to create it using the create API.
Ensure to provide the necessary details in the userInfo section and give superuser information.
Adjust parameters like tenantId and roles according to your specific requirements.
Port Forwarding:
Execute port forwarding to the workflow service using the following kubectl command:
Replace <pod-name>
with the appropriate pod name.
Create Workflow:
After port forwarding, initiate the workflow creation process.
Search Through API:
Use the search API to verify that the workflow has been successfully created.
Adjust the search parameters as needed.
These steps ensure a smooth workflow creation process inNalJalSeva. Make sure to follow each step in sequence for a seamless experience.
Water Connection Penalty changes are added to get the penalty amount after the due date. The due date is configurable and penalty enable and disable are also configurable. If we want to have the penalty we can enable or we can disable it through configuration.
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 the water service persister configs path added to it
PSQL server is running and a database is created to store water connection/application data
The following services should be up and running:
egov-persister
egov-mdms
ws-services
billing-service
Calculate water charges and taxes based on the billing slab.
Calculate meter reading charge for water connection
Generate demand for penalty feature
Scheduler for generating the demand(for non-metered connection)
Deploy the latest version of ws-service and ws-calculator
Add water-persist.yml & water-meter.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 )
Billing service tax head configuration
ws-calculator penalty configuration:
Use case 1: Fixed percentage on outstanding without penalty
Use case 2: Fixed percentage on the current month
Use case 3: Fixed percentage on outstanding including penalty
Note: All the above are applied to the running month only.
Use case 4: Fixed percentage on outstanding applied for every month on the outstanding amount respectively (not implemented)
Use case 1: "type": "Fixed", "subType": "outstandingWithoutPenalty"
Use case 2: "type": "Fixed", "subType": "currentMonth",
Use Case 3: "type": "Fixed", "subType": "outstanding", We have Total 4 types of penalty in the system:
Fixed - Current month: This type of penalty is applied to the current month's amount based on the rate (%) given in the configuration.
Fixed - outstanding: This is the penalty applied on the total outstanding amount including previously applied penalties based on the rate (%) given in the configuration.
Fixed - outstandingWithoutPenalty: This is the penalty applied on the total outstanding amount excluding previously applied penalties based on the rate (%) given in the configuration.
Flat - Current month: This type of penalty is applied to the current month's amount based on the amount given in the configuration.
Flat - outstanding: This type of penalty is applied to the total pending amount till the current month's amount based on the amount given in the configuration.
Curl to create:
We use re-indexing to transfer all data to the appropriate indexer. This process involves two steps:
Run the connector from the playground.
Call the legacy indexer service, which internally queries the plain search service to retrieve data and send it to the appropriate indexer.
Access to kubectl of the environment targeted
Plain search APIs in the respective services
NalJalSeva uses 3 main indexes for re-indexing:
Water-services
e-challan-services
dss-collection_v2
ws-services re-indexing - Kafka Connector Curl to be run from playground pod
Plain Search Call
EChallan-Reindexing
Kafka Connector Call to be run from Playground pod:
Legacy Index call from postman:
Dss collection v2 re-indexing - Kafka Connector call to be run from playground pod
payment re-indexing run from postman call
DSS has two sides to it. One is, the process in which the Data is pooled to ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across.
As this revolves around a variety of Data Sets, 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 process flow.
This document explains the steps on how to define the configurations for the Analytics Side Of DSS for NalJalSeva.
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.
Analytics Configurations: Analytics contains multiple configurations. we need to add the changes related to NalJalseva in this dashboard-analytics.
Dashboard analytics link - https://github.com/misdwss/config-mgramseva/tree/QA/egov-dss-dashboards/dashboard-analytics
Below is a list of configurations that need to be changed to run NalJalSeva successfully.
Each Visualization has its 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 a 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.
Here is the sample ChartApiConfiguration.json data for the NalJalSeva.
Click here to check the complete configuration.
Master Dashboard Configuration is the main configuration that defines the Dashboards to be painted on the screen.
It includes all the Visualizations, their groups, the charts which come within them and even their dimensions as what should be their height and width.
Click here to check the complete configuration.
Master Dashboard Configuration which was explained earlier holds 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 was just used to enable the Dashboards for viewing.
Click here to check the complete configuration.
Transform collection schema for V2
This transform collection v1 configuration file is used to map the incoming data. This mapped data will go inside the data object in the DSS collection v2 index.
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.
This configuration defines and directs the Enrichment Process which the data goes through.
For example, if the incoming data belongs to a Collection Module, then the Collection Domain Config is picked. Based on the Business Type specified in the data, the right config is picked.
To enhance the data Collection, the domain index specified in the configuration is queried with the right arguments and the response data is obtained, transformed and set.
Domain configuration
Topic context configuration
transform_expense.electricity_bill_v1 configuration
transform_expense.om_v1 configuration
transform_expense.salary_v1 configuration
transform_ws_v1 configuration
Below is the list of configurations made changes or added newly for NalJalSeva.
Click here to see the complete configuration
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 as in which Kafka topic consumed the data and what is the mapping for that.
Click here to see the complete configuration
Based on expense and water-service business service we added transform configurations as per below.
transform_expense.electricity_bill_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.electricity_bill_v1.json
transform_expense.om_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.om_v1.json
transform_expense.salary_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_expense.salary_v1.json
transform_ws_v1 configuration: https://github.com/misdwss/config-mgramseva/blob/QA/egov-dss-dashboards/dashboard-ingest/transform_ws_v1.json
Note: For Kafka connect to work, Ingest pipeline application properties or in environments direct push must be disabled.
es.push.direct=false
If DSS collection index data is indexing directly ( without Kafka connector) to ES through the ingest pipeline then, make the application properties or in environments, direct push must be enabled.
es.push.direct=true
Configure the Kafka topics in the environments or Ingest pipeline application properties as shown below.
For details on services such as re-indexing and Kafka connection, refer to the Services Re-indexing document.
Main-Monthly Dashboard
For the main monthly dashboard, we are using the service API to fetch the data and show it in the main monthly dashboard table.
Ws-services:
/ws-services/wc/_revenueCollectionData
Should be added to get the main monthly dashboard details. It is used to show the table data based on the no of months for selected financial year.
eChallan-Service:
/echallan-services/eChallan/v1/_chalanCollectionData
it is added to get the main monthly dashboard data for the expense.
Dashboard-Metrics:
To show the data in metrics format in a specific month dashboard we are using service API which will fetch the data based on dashboard type.
Ws-services:
/ws-services/wc/_revenueDashboard
Should be added to get the revenue dashboard metrix data. It will show the data of revenue collection information
eChallan-Service:
/echallan-services/eChallan/v1/_expenseDashboard
Is added in echallan-service to show the data of expenses in matrix format.
MDMS- changes for the dashboard:
User OTP service is used to generate OTP for user login, user registration and user password change.
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.
The following services should be up and running:
user
MDMS
Id-Gen
URL-Shortening
notification-sms
The user-otp service validates the user details and request type and sends OTP for a particular action.
Deploy the latest image of the user-otp service available.
User OTP service can be integrated with any organization or system that wants OTP-based validation for user login and registration.
Easy to create and simple process of generating bills from demands.
Easy to generate OTPs to validate mobile numbers for registration, login and password reset with simple API calls
OTP can be generated by calling /user-otp/v1/_send
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.
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.
The following services should be up and running:
user
MDMS
Id-Gen
URL-Shortening
notification-sms
eGov billing service creates and maintains demands.
Generates bills based on demands.
Updates the demands from payment when the collection service takes a payment.
Deploy the latest image of the billing service available.
In the MDMS data configuration, the following master data is needed for the functionality of billing
Billing service can be integrated with any organization or system that wants a demand-based payment system.
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.
Customers can create a demand using the /demand/_create
Organizations or systems can search the demand using /demand/_searchendpoint
Once the demand is raised the system can call /demand/_update endpoint to update the demand as per need.
Bills can be generated using, which is a self-managing API that generates a new bill only when the old one expires /bill/_fetchbill.
Bills can be searched using /bill/_search.
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.
Doc Links
API List
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:
User service is responsible for user data management and providing functionality to log in and log out of the DIGIT system.
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 the database
Redis is running
Store, update and search user data
Provide authentication
Provide login and logout functionality to the NalJalSeva platform
Store user data PIIs in encrypted form
Setup latest version of egov-enc-service and egov-mdms- service
Deploy the latest version of the egov-user service
Add Role-Action mapping for APIs
The following properties in the application.properties file in user service are configurable.
User data management and functionality to log in and log out into the DIGIT system using OTP and password.
Providing the 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 employees to login into the DIGIT system based on the password.
Citizen:
Create user
Update user
Search user
User registration using OTP
OTP based login
To integrate, the host of egov-user should be overwritten in the helm chart.
Use /citizen/_create
endpoint for creating users into the system. This endpoint requires the user to validate his mobile Number using OTP. The first OTP will be sent to his mobile number and then that OTP will be sent as otpReference
in the request body
Use /v1/_search
and /_search
endpoints to search users in the system depending on various search parameters
Use /profile/_update
for updating the user profile. The user will be validated (either by OTP-based validation or password validation) when this API is called
/users/_createnovalidate
and /users/_updatenovalidate
are endpoints to create user data into the system without any validations (no OTP or password required). They should be strictly used only for creating/updating users internally and should not be exposed outside
Forgot password: In case the user forgets the password it can be reset by first calling /user-otp/v1/_send
which will generate and send OTP on the employee’s mobile number, the password can then be updated using this OTP by calling the API /password/nologin/_update
in which a new password along with the OTP has to be sent.
Use /password/_update
to update the existing password by logging in. In the request body, both old and new password has to be sent. Details of the API can be found in the attached Swagger documentation
Use /user/oauth/token
for generating tokens, /_logout
for logout and /_details
for getting user information from his token
Multi-Tenant User: The multi-tenant user functionality allows a user to perform actions across multiple ULBs. For example, an employee belonging to Amritsar can perform the role of Trade License Approver for Jalandhar by assigning a tenant-level role of tenantId pb.jalandhar to him. Following is an example of such a user:
If an employee has a role with a state-level tenantId
he can perform actions corresponding to that role across all tenants
Refresh Token: Whenever the /user/oauth/token
is called to generate the access_token
, along with the access_token
one more token is generated called refresh_token
. The refresh token is used to generate new access_token
whenever the existing one expires. Till the time the refresh token is valid the user won’t have to log in even if his access_token
get’s expired, as it will be generated using refresh_token
. The validity time of the refresh token is configurable and can be configured using the property: refresh.token.validity.in.minutes
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)
Schedulers are designed to run a particular service at a scheduled time, without triggering manually. We can have multiple schedulers for an application. It will consider the GMT format only.
The Python script reads the mdms-read-cronjob JSON from the MDMS service using a token from the CRONJOB user.
Identify the APIs set up in this MDMS using the provided script argument. The script uses the config from the MDMS to call the corresponding API.
A total of 7 schedulers are available in the NalJalSeva:
_schedulerTodaysCollection: This scheduler will run daily to send the day collection amount to the collection employee.
_jobscheduler/true: This is to send the notification to the ULB employee when the bulk demand auto-generation is failed.
_schedulermarkexpensebill: This scheduler is used to mark the expense as paid for the paid expenses once every fortnight.
_schedulernewexpenditure: This is used to send the notification once every fortnight regarding the no of expenditures created.
_schedulermonthsummary: This is to send the monthly summary details to the ULB employee. _schedulerpendingcollection: This is to send the total pending amount details to the respective ULB employee user once every fortnight.
_jobscheduler/false: This is used to generate the bulk demand automatically once every month.
We have 7 different schedulers in NalJalSeva, running in 4 different time slots. We need to set them all to run the same Python scripts with different arguments, which you can find in the file under command -> args.
Configure the scheduler's runtime under the cron -> schedule option.
Example of failedBulkDemand scheduler:
The cron schedule is set to "30 3 5 * *", which triggers the job at 3:30 AM GMT on the 5th day of every month. Converting this to IST, the job runs at 9:00 AM IST on the 5th day of each month.
The command failedbulkdemand
is used to instruct the Python script to invoke only the API configured as "failedbulkdemand" in the mdms-read-cronjob.mdms JSON file.
PriorNote: In DevOps, the app name and schedule change based on the cron job file and set time. Arguments are set according to the job name in MDMS configuration.
labels: App: monthly-cronjob Group: mdms-read-cronjob <!-- Stays the same as we use the same Python script
cron: schedule: 30 3 4 * * // This depends on the time we need to run the scheduler
image: repository: api-cronjob tag: v1
command:
python3
cronJobAPIConfig.py
args:
monthly // This is the job name which differs from the requirement based on the scheduler type.
env:
name: JOB_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
resources: |
requests: {}
The remaining fields will be the same for all the schedulers.
Monthly: This will run and send the notification to the ULB employee or consumer on the 4th of every month morning at 9 am as per the scheduled time.
Fortnightevening: This scheduler will run on the 1st and 15th of every month evening at 6 pm to send the respective notification to the Consumer.
Failedbulkdemand: When the bulk demand generation is failed this scheduler will run and share the message to ULB employees to generate demand manually.
Dailyevening: This scheduler will run daily and send notifications to the collection operator daily.
Check the links below
MDMS object details and configuration:
{
"jobName": "monthly", // This will change based on the job name
"active": "true", // when the "active" param is set to true, the scheduler runs automatically. The scheduler does not run when set to false.
"method": "POST",
"url":http://echallan-services.mgramseva:8080/echallan-services/eChallan/v1/_schedulermonthsummary", // This is the respective service URL to call that service as per the scheduler.
"payload": {
"RequestInfo": "{DEFAULT_REQUESTINFO}" // this is common in all the schedulers used to send the request info.
},
"header": {
"Content-Type": "application/json" // This is a common property for all schedulers.
}
}
Here is the configuration for all the schedulers: Click here to see.
Need to create a user with CRONJOB as name and type as SYSTEM and ROLE as SYSTEM AND EMPLOYEE here is the sample curl to create the user.
A Build ID (similar to the ID given below) is created when you build the cronjob. api-cronjob:develop-c0aa08a-2
Take the id only from this instead of a complete name like develop-c0aa08a-2. This id will be used as the id for your respective yaml files and the same will be deployed to the required environment to test the cron job.
For example:
Mdms-read-cronjob:develop-c0aa08a-2,
failedbulkdemand:develop-c0aa08a-2,
Fortnightevening:develop-c0aa08a-2,
monthly:develop-c0aa08a-2 Note: develop-c0aa08a-2 is the common build id for all the files which you are using.
Run the cronjob manually - Steps
Delete the existing cron jobs if they already exist with the same name.
kubectl delete cronjob mdms-read-cronjob -n mgramseva
Deploy these builds in QA environments, which are related to cronjob schedulers
mdms-read-cronjob:develop-c0aa08a-2, failedbulkdemand:develop-c0aa08a-2, fortnightevening:develop-c0aa08a-2,monthly:develop-c0aa08a-2
Test the cron job scheduler - Steps
kubectl get cronjob -n mgramseva -- to check the list of cron jobs
Create the job manually to test the messages. Below are the commands to create the jobs.
A message is received for the respective schedulers each time we run it.
We can increase the number to test again like failedbulkdemand-manually-1 next it will be failedbulkdemand-manually-2.
kubectl create job --from=cronjob/failedbulkdemand failedbulkdemand-manually-1 -n mgramseva
kubectl create job --from=cronjob/fortnightevening fortnightevening-manually-1 -n mgramseva
kubectl create job --from=cronjob/mdms-read-cronjob mdms-read-cronjob-manually-1 -n mgramseva
kubectl create job --from=cronjob/monthly monthly-manually-1 -n mgramseva
kubectl get job -n mgramseva -- to check the list of jobs
To check the cronjob image
kubectl describe cronjob mdms-read-cronjob -n mgramseva
To delete specific job
kubectl delete jobs mdms-read-cronjob-manually-1 -n mgramseva
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.
Prior knowledge of Java/J2EE
Prior knowledge of Spring Boot
Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of the demand-based systems
The following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
The Property Service provides multiple functionalities starting from serving as a central repository where property information is registered for reference of citizens and other municipality-provided services such as water connection and sewerage management. An assessment can be done 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).
MDMS CONFIG: https://github.com/egovernments/egov-mdms-data/tree/DEV/data/pb/PropertyTax
The persister file configuration for property services can be found in the Config repo of eGov Git, which needs to be added in the persister service - property-services-registry.yml
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.
For the creation of property from the water and sewerage module, as per the use case mentioned in this ticket, a different workflow configuration is used. For each use case, to identify which workflow to use can be identified from this mdms file.
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
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
Property service can be integrated with any organization or system that wants to maintain a record of the property and collect taxes with ease.
Easy to create and simple process of self-assessment to avoid the hassle.
Helps maintain property data which can be used in the integration of other essential services like asset management, water connection and so on.
provides additional functionalities like mutation and assessment of properties.
Customers can create a property using the /property/_create
Search the property using /property/_searchendpoint
/property/_update endpoint to update the property demand as needed.
Mutation can be carried out with the help of /property/_update itself, no extra API is required.
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.
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
Added payment payment preference and agency attributes for DSO
Added gender attribute in the create and update APIs for Vendor
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.
Deploy the latest version of the vendor
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.
After adding Actions and role-action mappings, restart the egov-mdms-service.
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
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
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
Validation of DSO/Vendor availability
Fetch the vehicle assigned to the DSO
Fetch the Drivers assigned to the DSO
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
API List
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.
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 the water service persister configs path added to it
PSQL server is running and a database is created to store water connection/application data
The following services should be up and running:
egov-persister
egov-mdms
ws-services
billing-service
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)
Deploy the latest version of ws-service and ws-calculator
Add the water-persist.yml
and water-meter.yml
files to the config folder in git. Update the environment YAML file by adding a parameter called persist-yml-path
with the path to these files.
Master Config:
Billing Slabs:
Criteria -
connection type
building type
calculation attribute
property usage type
The calculation applies the specified slab based on the water connection criteria.
Estimation:
Water charge and tax
The water charge is based on the billing slab, and the water application charge will be based on the slab and tax based on the master configuration.
The charge for the given connection for a given billing cycle will be defined/identified by the system with the help of the CalculationAtrribute MDMS and WCBillngSlab MDMS.
CalcualtionAttribute helps to identify the type of calculation for the given ConnectionType below MDMS of
Metered Connection water consumption is the attribute used for the calculation of charge for the billing cycle i.e Based on the units consumed for a given billing cycle for a given connection would identify the actual charge from the WCBIllingSlab MDMS based on the propertyType, calcautionAttribute derived for a connection and ConnectionType.
Non-Metered Connection Flat is the attribute used for the calculation of the charge for a given billing cycle, i.e. for a Non-Metered connection, there would be a flat charge for the given billing cycle. The amount can be derived from the WCBillingSlab MDMS based on the propertyType, calcautionAttribute derived for a connection and ConnectionType.
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.
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:
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.
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.
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.
Are we maintaining success or failure status anywhere?
Currently, we are maintaining the status of failed records in Kafka.
We need to configure the batch size for Kafka consumers. This configuration determines how much data is processed at a time.
The ws-calculator is integrated with ws-service. ws-services internally invoke the ws-calculator service to calculate and generate demand for the charges.
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.
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. The scheduler APIs should be called periodically for non-metered connections to generate the demand.
For the metered connection service, the /meterConnection/_search API is used to get the previous meter reading,
To generate the demand for metered or non-metered water connection /waterCalculator/_calculate API is used.
Users can pay partial/full/advance amounts for the metered or non-metered connection bill. The billing service would call back /waterCalculator/_updateDemandAPI to update the demand-generated details in such cases.
/waterCalculator/_jobscheduler API is used to generate demand for non-metered connections. This API can be called periodically.
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row).
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.
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
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.
Add mdms configs required for egov-user-events.
Add Role-Action mapping for API’s.
Deploy the latest version of egov-user-events
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 )
Add master data in the MDMS service with the module name as mseva. Following is some sample master data for the service:
Event Categories
Event Types:
Using /localization/messages/v1/_upsert , add localisation (templates) for notification messages to be sent. Following are the product notification templates:
Copy
Following are the properties in the application.properties file in the egov-user-events service which is 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:
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”
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.
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>”
OTHERS - Events that don’t belong to the types mentioned above.
These are configured in MDMS.
Event Category: Events are categorised into the following:
PUBLICHEALTH - Events related to public health.
CULTURAL - Cultural events
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.
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 the Delete event, pass Status as CANCELLED and to get details about the 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.
eGov-user-events can be integrated with any organisation or system which wants to send the events generated for the user in the system
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.
An employee can create events in the system using /egov-user-event/v1/events/_create endpoint
Employees can update events in the system using /egov-user-event/v1/events/_update endpoint
Events are searched in the system using /egov-user-event/v1/events/_search endpoint
/egov-user-event/v1/events/notifications/_count API is used to fetch the count of total, unread, and read notifications.
/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.
(Note: All the APIs are in the same Postman collection therefore same link is added in each row).
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.
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
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
Environment variables | Description |
---|---|
Actions
Role Action Mapping
Roles available:
Localization:
Add MDMS configurations required for eChallan Service and calculator and restart the MDMS service.
Deploy the latest version of eChallan Service and calculator.
Add eChallan Service persister yaml path in persister configuration and restart persister service.
Add role-action mapping for APIs.
Add pdf configuration file for challan and bill.
The eChallan service is used to generate e-challans / bills for all miscellaneous/ad-hoc services which citizens avail from ULBs.
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.
To integrate, overwrite the host of the echallan-services module in the Helm chart.
Add the echallan-services/eChallan/v1/_create as the create endpoint for creating eChallan in the system.
Add the echallan-services/eChallan/v1/_search as the search endpoint. This method handles all requests to search existing records depending on different search criteria.
Add echallan-services/eChallan/v1/_update as the update endpoint. This method is used to update fields in existing records or to update the status of applications based on workflow.
/echallan-services/eChallan/v1/_expenseDashboard
Is added in echallan-service to show the data of expenses in matrix format.
/echallan-services/eChallan/v1/_chalanCollectionData
it is added to get the main monthly dashboard data for the expense.
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row).
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.
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
Apportion payment in tax heads of bill
Apportion advance amount in tax heads of demand during demand creation
Environment variables | Description |
---|---|
Deploy the latest version of the egov-apportion-service service
Add apportion persister yaml path in persister configuration
There is no separate configuration required. The TaxHead master that is configured in the billing service is only used
Any payment service which wants to divide the paid amount into different tax head buckets can integrate with the apportion service.
Apportions amount in tax heads
To integrate, the host of egov-apportion-service should be overwritten in the helm chart
/apportion-service/v2/bill/_apportion should be called to apportion the bill
/apportion-service/v2/demand/_apportion should be called to apportion advance amount in demands
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)
The NalJalSeva Rollout Dashboard Scripts gather data from the NalJalSeva database and services for the Metabase Rollout dashboard. This Python script transfers data daily from NalJalSeva to a database table, which is then used to create visual dashboards in Metabase.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Python 3.9
NalJalSeva DB
NalJalseva user details who has access to MDMS service API
NalJalSeva MDMS service access
Collects data on specific points and inserts it into the rollout dashboard table in the database. User Story details:
IFIX-485: [1.0.1] Rollout Dashboards on MetabaseQA SIGNOFF
Deploy the following build -
rollout-dashboard-cronjob:develop-2a8d6a44-3
NalJalSeva Rollout Dashboard is not directly integrated with any of the services except this scripts fetch the data from the MDMS service and NalJalSeva DB
Configure the username, tenantId, and password of the user for which mdms service access is available in the environment-specific yaml file in DevOps. Refer to the example below -
Follow the steps below to run this in the local environment.
The Python script inserts the data into the table “roll_out_dashboard
“ in NalJalSevaDb for every run, it cleans the old data and creates new data.
This table has to be loaded into the metabase by adding NalJalSeva DB to the metabase.
NalJalSeva is a Hybrid Application(web + App(Android + IOS)) built utilising Open Source Framework Flutter.
CrossPlatform Application
Faster
Single Codebase - Easy To Maintain
Large Community Support
Open Source
Link to Learn Flutter - Flutter - Beautiful native apps in record time
Flutter Version Utilised for Development
Flutter 2.2.3
Languages - > Dart 2.13.4
Users land on the Language Selection screen.
Link → {base url}/mgramseva/selectLanguage
Users can switch to different languages that the application supports.
Click on Continue to navigate to the next screen.
Primary files:
Secondary files:
LocalStorage
0 → Language selection screen
Pop → Application closes
Widgets utilized from library
Users are redirected to this screen once they click on the Forgot Password link on the home screen.
This feature allows users to request OTP by entering a valid (registered) mobile number.
Follow the steps below to set a new password -
Click on the Forgot Password link visible on the login screen
Enter the registered mobile number
The remaining steps are explained in the section.
Primary Files:
2 → Language Selection Screen. + Login Screen + ForgotPassword
Pop → Login Screen Screen
Widgets utilised from the Library
Users are redirected to this screen once they click on the Continue button on the Forgot Password screen.
Link - → {base url}/mgramseva/selectLanguage/login/forgotPassword/resetPassword
Enter the OTP sent on the user’s 10-digit mobile number.
Set the new password for logging into the application.
Click on Change Password to apply new password credentials for the user.
This feature helps to provide the users with a clear indication of what the password should contain. Acceptable passwords must contain -
Minimum 6 digits
At least one special character ( !#$%^&...)
At least one letter
At least one number
Primary Files:
1 → Language Selection Screen. + Login Screen + Forgot Password + Reset Password.
Pop → Forgot Password Screen.
Widgets utilised from the Library
Users are redirected to the home page screen after successful login. This screen consists of multiple sections and user interactions. If the user is mapped to multiple tenants then a dropdown appears. The user can select the desired tenant to proceed further. Once the user selects the tenant, the feature cards are displayed on the screen based on the roles mapped for the selected tenant.
YES → WalkThrough/User Guidance Enabled
NO → Home Screen
If the user logs in for the first time a system walkthrough begins automatically.
Otherwise, users can view walkthroughs at any time by clicking on the help icon.
Create a global key for each card.
Create placeholder cards, pointers and description widgets.
On click, the position of the card is determined and the placeholder card appears on the overlay exactly.
Primary Files:
,
Next → Changes the active index of the global key and repeat the same process outlined in the implementation logic skip,
End → closes the overlay
Home Screen - consists of multiple feature cards
Cards are displayed based on Role Access.
The home screen also consists of notifications. The notifications are customized for each user ID and user role.
Individual API calls are made with the user ID and with the user role that merges both and notifications are displayed accordingly.
Primary Files:
Users are redirected to this screen once they select the preferred language in the previous screen.
Link → {base url}/mgramseva/selectLanguage/login
Users enter the registered Phone Number and Password.
Click on Continue.
First-time login users navigate to Reset Password Page.
Log in with the default password
YES →
NO →
Primary Files:
Fields | Validations |
---|
Stack
1 → Language selection screen. + Login screen.
Pop → Language selection screen.
Widgets utilized from the library
Users are redirected to the Update Password screen once they log in successfully the first time.
Link: → {base url}/mgramseva/selectLanguage/login/updatepassword
Enter the OTP sent on the user’s 10-digit mobile number.
Set the new password for logging into the application.
Click on Change Password to apply new password credentials for the user.
Users can see the allocated Gram Panchayat name and code in the table.
This feature helps match the user’s password and check if the password contains
Minimum 6 digits
At least one special character ( !#$%^&...)
At least one letter
At least one number
Primary Files:
Fetch the tenants from MDMS, based on the user roles in the user request filtering the tenants by comparing tenant IDs.
1 → Language selection screen + Login screen + Update password + Update password success
Pop → Login
Widgets utilized from the library
View →
Controller →
Users are redirected to this screen once they click on the Change Password option in the sidebar app drawer.
Link → {base url}/mgramseva/home/changepassword
Enter the Current Password
Enter and Confirm a New Password to set the login credentials for the next time login
Click the Change Password Button. The user login password is set to the new password.
This feature helps match the user password to the requirements and checks if the password contains
Minimum 6 digits
At least one special character ( !#$%^&...)
At least one letter
At least one number
Primary Files:
Stack
1 → Home Screen. + Change Password Screen
Pop → Home Screen
Widgets utilised from the Library
Water service is a DIGIT application that helps and gives flexibility to municipalities and citizens to manage water service requirements like applying for a water connection or searching for water connections. The application goes through various steps as defined by the states. The application is passed through different users who verify and inspect the application details before moving it to the next stage. Based on the state, citizens get notifications (SMS and in-app ). Citizens can also pay application fees or employees can collect the fee for the application.
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 a water service persister config path added to it
PSQL server is running and a database is created to store water connection/application data
knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-sms, eGov-email,eGov-user, eGov-localization, eGov-workflow-service will be helpful.
Add old water connection to the system with/without arrears
Create a new Water Connection
Searching for water connections
Notification based on the application state
Environment variables | Description |
---|
MDMS configuration:
ConnectionType:
Two connection types supported Metered and Non metered.
CheckList:
A checklist is used to define the Q&A for the feedback form and its validation.
Category:
A predefined list of categories is allowed.
SubCategory:
A pre-defined list of subcategories is allowed.
Persister configuration:
Actions:
Role Action Mapping:
Roles available:
Workflow business service config:
Create businessService (workflow configuration) using the /businessservice/_create
. Following is the product configuration for water service:
Indexer config for water service:
Setup
Provide the absolute path of the checked-in file to DevOps, to add it to the file-read path of egov-indexer. The file will be added to the egov-indexer's environment manifest file for it to be read at the start-up of the application.
Run the egov-indexer app, Since it is a consumer, it starts listening to the configured topics and indexes the data.
Notification
Notification will be sent to the property owners and connection holders based on different application states.
Capturing Connection Holders
We can add connection holders to the water connection which will be the owner of the connection. We can fill in the connection holders' details or we can just make the property owner to the connection holder.
The connection holder will get a notification based on a different state of the application. We are pushing the data of the connection holders in the user service too.
Multiple Road Type Support
We can add road-cutting details of multiple roads to the water connection. For each road that goes undercutting process, we have to fill in the road type and the cutting area details. Based on this information, the application one-time fee estimate is calculated.
Add mdms configs required for water connection registration and restart mdms service.
Deploy the latest version of the ws-services service.
Add water-service and water-services-meter persister yaml path in persister configuration and restart persister service.
Add Role-Action mapping for API’s.
Create businessService (workflow configuration) according to trade water connection, modify water connection
Add ws-service indexer yaml path in indexer service configuration and restart indexer service.
This ws-service module is used to manage water service connections against a property in the system.
Provide backend support for the different water connection registration processes.
Mseva and SMS notifications on application status changes.
The elastic search index for creating visualizations and Dashboards.
Supports configurable workflows.
To integrate, the host of the ws-service module should be overwritten in the helm chart.
/ws-services/wc/_create
should be added as the endpoint for creating water applications/connections in the system.
/ws-services/wc/_search
should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria.
/ws-services/wc/_update
should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
(Note: All the APIs are in the same Postman collection therefore the same link is added in each row)
Users are navigated to the Edit Profile screen once they click on the option on the sidebar app drawer.
Link - → {base url}/mgramseva/home/editProfile
User can change their profile name, gender and email on this screen
Click on the Save button triggers a Details Saved Successfully message on the screen and saves the changes to the profile.
Primary Files:
Fields | Validations |
---|
End Point | Request Method | Request Info |
---|
Stack
1 → Home Screen. + Edit Profile Screen
Pop → Home Screen
Widgets utilised from the Library
Users are redirected to this screen once they click on the Collect Payment card or the Update Consumer Details card or the Download Bills and Receipts card on the home screen.
Link
→ {base url}/mgramseva/home/householdSearch?Mode=collect
→ {base url}/mgramseva/home/consumersearchupdate?Mode=update
→ {base url}/mgramseva/home/householdReceiptsSearch?Mode=receipts
Users can search the consumer/connection with their Mobile Number / Name / Old Connection ID / New Connection ID ( Search with any one of these
)
Click on Search to get the household details of the Consumer/Connection.
Primary Files:
Fields | Validations |
---|
1 → Home Screen. + Search Connection Screen
Pop → Home Screen
Widgets utilised from the Library
This page provides the UI screen technical details for the following features -
Users are redirected to this screen once they click on the Generate Demand card on the home screen.
This is used in cases when the scheduler is not running (due to technical errors) and the GP wants to run it manually.
Link → {base url}/mgramseva/home/billmanualgenerate
Default Values Set
The service category displays water charges by default
The service type displays a non-metered connection by default
Set the billing year from the drop-down which contains the list of financial years.
Set the Billing cycle which contains billing cycles for the selected financial year.
On clicking the Generate Demand Button, Bulk Demand is generated and the user is navigated to the success screen.
The Billing Cycle drop-down shows a list of months starting from the selected financial year from Date month till the current date month.
On selection of the desired month, the billing period value is set from the selected month’s first date to the selected month’s last date. (Eg. Selected Billing Cycle: June 2021, so Billing period: 01/07/2021 - 30/07/2021)
Primary Files:
1 → Home Screen. + Generate Bulk Demand Screen
Pop → Home Screen
Widgets utilised from the Library
Users are redirected to the Generate New Bill screen once they click on the Generate New Bill option in the household detail screen.
Link
→ {base url}/mgramseva/home/householddetails/billgenerate
Default Values Set
The service category defaults to water charges
The service type defaults to a metered connection
The property type defaults to the selected property type of the consumer
Previous Meter Reading: Takes input from the user only for a first-time bill generation and if the Previous meter reading is null, else it's defaulted if the meter reading is present.
New Meter Reading: Takes input from the user
Meter Reading Date: Defaulted to today’s date, the User can change it to the desired date.
Users have the option of downloading the bill or sharing it via WhatsApp
On click of the Collect Payment button, the user is navigated to the Payment Screen
Primary Files:
1 → Home Screen + Household Details Screen + Generate Bill Metered
Pop → Household Details Screen
Widgets utilised from the Library
To enable any municipal service in a fresh environment and for the first time, we require a basic idea of what DIGIT does and the generic services required to set it up.
DIGIT is an open-source, customizable platform that lends itself to extensibility. New modules can be built on top of the platform to suit new use-cases or existing modules can be modified or replaced. To enable this, in addition to deploying DIGIT, a CD/CI pipeline has to be set up. CD/CI pipelines enable the end users to automate & simplify the build/deploy process.
Find more details on DIGIT and platform deployment .
DIGIT platform comprises several core services that serve as the platform backbone. Some of the key core services are listed below:
..among
Each microservice has a distinct function explained in the provided documentation links.
Developers can activate specific municipal services easily once the platform and its terminologies are well understood.
Postman links |
---|
Property | Value | Description |
---|---|---|
param | value | description |
---|---|---|
Title | Link |
---|---|
Title | Link |
---|---|
TaxHead | Amount | Order | FullPayment(2000) | PartialPayment1(1500) | PartialPayment2(750) | PartialPayment2withrebate(500) |
---|---|---|---|---|---|---|
TaxHead | Amount | TaxPeriodFrom | TaxPeriodTo | Order | Purpose |
---|---|---|---|---|---|
TaxHead | Amount | TaxPeriodFrom | TaxPeriodTo | Order | Purpose |
---|---|---|---|---|---|
Property | Value | Description |
---|---|---|
Docs | APIs |
---|---|
crontab.guru - The cron schedule expression editor helps to define the pattern for the schedule cron.
name | value | description |
---|---|---|
MDMS Fields | Description |
---|---|
name | value |
---|---|
Title | Link |
---|---|
Title | Link |
---|---|
Integrate the below changes in vendor-persister.yml -
Description | name in values.yml | Current Value |
---|
API |
---|
Environment variables | Description |
---|
The above combination is used to define the billing slab. Billing Slab is defined in MDMS under the ws-services-calculation folder with the . Find below a sample slab.
Docs | APIs |
---|
Property | Value | Remarks |
---|
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:
API Docs |
---|
APIs |
---|
Docs | APIs |
---|---|
Title | Link |
---|---|
Title | Link |
---|---|
Key | Stored Data |
---|---|
API EndPoint | Input Params (Modules) | Description |
---|---|---|
Widgets Library |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
Fields | Validations |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
Fields | Validations |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
Fields | Validation |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
master-config.json for water service
Property creation through WNS module
The indexer provides the facility for indexing the data to elastic search.
Write the configuration for the water service.
Put the indexer config file into the config repo under egov-indexer folder.( )
Title | Link |
---|
Title | Link |
---|
Widgets | File Path | Description |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
Fields | Validations |
---|
API End Point | Input Params (Module) | Description |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
Fields | Validations |
---|
API End Point | Input Params (Modules) | Description |
---|
End Point | Request Method | Request Info |
---|
Widgets | File Path | Description |
---|
NOTE - NalJalSeva uses DIGIT core services and additional code is available in and .
egov.user.event.notification.enabled
This variable is to check the event Notification enabled or not.
egov.challan.default.limit
This variable is to get the default limit value
egov.challan.max.limit
This variable to check the max limit value.
create.ws.workflow.name
This variable will give the business service name while creating the workflow.
notification.sms.enabled
This variable is to check the SMS notifications are enabled or not.
egov.localization.statelevel
This variable is used to check the localizations are state level or not.
egov.pending.collection.link
variable for collection list screen link for notifications
egov.monthly.summary.link
variable for monthly summary screen link for notifications
egov.new.Expenditure.link
variable for new expenditure screen link
egov.mark.paid.Expenditure.link
variable for paid expenditure screen link
egov.bilk.demand.failed.link
variable for mnaul bulk demand generation screen link
egov.today.collection.link
variable for today’s collection screen link
egov.apportion.default.value.order
If set to true will apportion of negative amount first irrespective of tax head order
Collection Service
Billing Service
API Swagger Documentation
/apportion-service/v2/bill/_apportion
/apportion-service/v2/demand/_apportion
expiry.time.for.otp
3000
Expiry time of the otp
bs.businesscode.demand.updateurl
Each module’s application calculator should provide its updated URL. if not present then a new bill will be generated without making any changes to the demand.
bs.bill.billnumber.format
BILLNO-{module}-[SEQ_egbs_billnumber{tenantid}]
IdGen format for bill number
bs.amendment.idbs.bill.billnumber.format
BILLNO-{module}-[SEQ_egbs_billnumber{tenantid}]
is.amendment.workflow.enabled
true/false
enable disable workflow of bill amendment
Id-Gen service
url-shortening
MDMS
/demand/_create, _update, _search
/bill/_fetchbill, _search
/amendment/_create, _update
Pt_tax
1000
6
1000
1000
750
750
AdjustedAmt
1000
-250
-750
-750
RemainingAMTfromPayableAMT
0
0
0
0
Penality
500
5
500
500
AdjustedAmt
500
-500
RemainingAMTfromPayableAMT
1000
250
Interest
500
4
500
500
AdjustedAmt
500
-500
RemainingAMTfromPayableAMT
1500
750
Cess
500
3
500
500
AdjustedAmt
500
-500
RemainingAMTfromPayableAMT
2000
1250
Exm
-250
1
-250
-250
AdjustedAmt
-250
250
RemainingAMTfromPayableAMT
2250
1750
Rebate
-250
2
-250
-250
AdjustedAmt
-250
250
RemainingAMTfromPayableAMT
2500
750
Pt_tax
1000
2014
2015
6
Current
AdjustedAmt
0
Penality
500
2014
2015
5
Current
AdjustedAmt
0
Interest
500
2014
2015
4
Current
AdjustedAmt
0
Cess
500
2014
2015
3
Current
AdjustedAmt
0
Exm
-250
2014
2015
1
Current
AdjustedAmt
0
Pt_tax
1000
2014
2015
6
Arrear
AdjustedAmt
0
Pt_tax
1500
2015
2016
6
Current
AdjustedAmt
0
Penalty
600
2014
2015
5
Arrear
AdjustedAmt
0
Penalty
500
2015
2016
5
Current
AdjustedAmt
0
Interest
500
2014
4
Arrear
AdjustedAmt
0
Cess
500
2014
3
Arrear
AdjustedAmt
0
Exm
-250
2014
1
Arrear
AdjustedAmt
0
egov.user.search.default.size
10
default search record number limit
citizen.login.password.otp.enabled
true
whether citizen login otp based
employee.login.password.otp.enabled
false
whether employee login otp based
citizen.login.password.otp.fixed.value
123456
fixed otp for citizen
citizen.login.password.otp.fixed.enabled
false
allow fixed otp for citizen
otp.validation.register.mandatory
true
whether otp compulsory for registration
access.token.validity.in.minutes
10080
validity time of access token
refresh.token.validity.in.minutes
20160
validity time of refresh token
default.password.expiry.in.days
90
expiry date of a password
account.unlock.cool.down.period.minutes
60
unlock time
max.invalid.login.attempts.period.minutes
30
window size for counting attempts for lock
max.invalid.login.attempts
5
max failed login attempts before account is locked
egov.state.level.tenant.id
pb
is.workflow.enabled
true/false
enable disbale workflow
PT.CREATE
the name should match the config name in the workflow businessservice JSON
PT.LEGACY
PT.UPDATE
businessService
Name of workflow config
initialAction
Indicate the start(initial) action of the particular workflow mention in businessService.
inWorkflowStatusAllowed
This field indicate whether the property with application status as “inWorkflow” can be use with water and sewerage connection creation. If this field is true then for that particular use case, the property with “inWorkflow” status can be use with water and sewerage connection creation and vice versa
enable
If this filed is set as true, then the other fields associate with the particular object is use for property creation.
egov.idgen.ack.format
PB-AC-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ACK]
egov.idgen.mutation.format
PB-MT-[CITY]-[SEQ_EG_PT_MUTATION]
egov.idgen.assm.format
PB-AS-[cy:yyyy-MM-dd]-[SEQ_EG_PT_ASSM]
egov.idgen.ptid.format
PB-PT-[cy:yyyy-MM-dd]-[SEQ_EG_PT_PTID]
citizen.allowed.search.params
accountId,ids,propertyDetailids,mobileNumber,oldpropertyids
employee.allowed.search.params
accountId,ids,propertyDetailids,mobileNumber,oldpropertyids
USER Service
url-shortening
MDMS
Billing-service
Location
Workflow
Persister
Localization
Id-Gen service
/Property/_create
/Property/_update
/property/_search
states_key
State Information for From MDMS Service
ex :pn_IN
,en_IN
,hi_IN
Localization codes
egov-mdms-service/v1/_search
common-masters tenant
To fetch details State info Logo background Image Languages supported
localization/messages/v1/_search?module
={}locale
={}tenantId
={}
ALL the necessary Modules, with locale key and tenant Id
To Load the Localized data
Button Bar
|
| "otp": { "mobileNumber": {}, "tenantId": {}, "type": "passwordreset", "userType": "Employee" } |
Enter the OTP sent * |
|
Enter a New Password* |
|
Confirm New Password | Match with New Password |
|
| "otpReference": {}, "userName": {}, "newPassword": {}, "tenantId": {}, "type": “Employee” |
Kafka Consumer Group | SPRING_KAFKA_CONSUMER_GROUP_ID | egov-vendor-services |
kafka topic to which service push data to save new Vendor | PERSISTER_SAVE_VENDOR_TOPIC | save-vendor-application |
mdms service host | EGOV_MDMS_HOST | egov-mdms-service from egov-service-host |
Vehicle Service host | EGOV_VEHICLE_HOST | vehicle from egov-service-host |
User service host | EGOV_USER_HOST | egov-user-service from egov-service-host |
Location Service Host | EGOV_LOCATION_HOST | egov-location from egov-service-host |
|
| username: {} password:{} scope: read grant_type: password tenantId: {} userType: EMPLOYEE |
Enter the OTP sent * |
|
Enter a New Password* |
|
Confirm New Password | Match with New Password |
|
| "otpReference": {}, "userName": {}, "newPassword": {}, "tenantId": {}, "type": “Employee” |
| POST | "MdmsCriteria": { "tenantId": tenantId, "moduleDetails": [ { "moduleName": "tenant", "masterDetails": [ {"name": "tenants"} ], }, ] } |
| This variable is to check the SMS notifications are enabled or not. |
| This variable is to check the email notifications are enabled or not. |
| This variable is for download bill reciept path |
| This variable is to get the common link to the home page |
kafka.topics.persister.save.events | save-user-events | This is the persister topic onto which user-events pushes records for persistence. This is for creating events. |
kafka.topics.persister.update.events | update-user-events | This is the persister topic onto which user-events pushes records for persistence. This is for updating events. |
kafka.topics.lat.details | user-events-lat | This is the persister topic onto which user-events pushes records for persistence. This is for storing last-access-time / last-login-time of the user. |
kafka.topics.save.events | persist-user-events-async | Topic to which the user-events consumer is subscribed. Producers willing to create events must push records to this topic. |
kafka.topics.update.events | update-user-events-async | Topic to which the user-events consumer is subscribed. Producers willing to update events must push records to this topic |
mseva.notif.search.offset | 0 | Default pagination offset. |
mseva.notif.search.limit | 200 | Default pagination limit. |
Current Password* | No Validation |
Set a New Password* |
|
Confirm New Password* | Match with New Password |
|
| "userName": {}, "existingPassword": {}, "newPassword": {}, "tenantId": {}, "type": {} |
| This variable contains the kafka topic name which is used to create new water connection application in the system. |
| This variable contains the kafka topic name which is used to update the existing water connection application in the system. |
| This variable contains the kafka topic name which is used to update the process instance of the water connection application. |
| This variable contains the idgen format name for water application |
| This variable contains the idgen format for water application ex:- WS/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON] |
| This variable contains the idgen format name for water connection |
| This variable contains the idgen format for water connection ex:- WS_AP/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_EGOV_COMMON] |
|
| tenantId: {} oldConnectionNumber: {} name: {} connectionNumber: {} mobileNumber: {} |
Billing Year* |
|
Billing Cycle* |
|
|
| To Fetch the Details of
|
|
| "tenantId": {}, "billingPeriod": {} |
Previous Meter Reading* |
|
New Meter Reading* |
|
Meter Reading Date* |
|
|
| To Fetch the Details of
|
|
| "meterReadings": { "currentReading": {}, "currentReadingDate": {}, "billingPeriod": {}, "meterStatus": "Working", "connectionNo": {}, "lastReading": {}, "lastReadingDate": {}, "generateDemand": true, "tenantId": {} } |
| Text Field |
| Button |
| Text Field |
| Button |
| Password Hint Card |
| Text Field |
| Button |
| Text Field |
| Button |
| Password Hint Card |
| Text Field |
| Button |
API Swagger Documentation |
Water Calculator Service | Water-Service Calculator |
/ws-services/wc/_create |
/ws-services/wc/_update |
/ws-services/wc/_search |
/ws-services/wc/_submitfeedback |
/ws-services/wc/_getfeedback |
/ws-services/wc/_revenueDashboard |
/ws-services/wc/_revenueCollectionData |
| Text Field |
| Button |
| Radio Buttons for options |
| Text Field |
| Button |
(Primary File)
(Secondary File) | Searchable Dropdown |
| Success Screen |
| Button |
| Meter Reading 5 digit boxes field |
(Primary File)
(Secondary File) | Searchable Drop down |
| Date Picker |
| Success Screen |
| Button |
Fields | Validation |
Phone Number* |
|
Phone Number* |
|
Password* |
|
Name |
|
Email ID |
|
|
| "user": { "id": {}, "userName": {}, "salutation": null, "name": {}, "gender": {}, "mobileNumber": "9191919146", "emailId": {}, "altContactNumber": null, "pan": null, "aadhaarNumber": null, "permanentAddress": null, "permanentCity": null, "permanentPinCode": null, "correspondenceAddress": null, "correspondenceCity": null, "correspondencePinCode": null, "active": true, "locale": null, "type": "EMPLOYEE", "accountLocked": false, "accountLockedDate": 0, "fatherOrHusbandName": null, "relationship": null, "signature": null, "bloodGroup": null, "photo": null, "identificationMark": null, "createdBy": {}, "lastModifiedBy": {}, "tenantId": {}, "roles": [ {} ], } |
Owner Mobile Number |
|
Name of the Consumer |
|
Old Connection ID |
|
New Connection ID |
|