mGramSeva - Billing Service
Overview
The main objective of the billing module is to serve the Bill for all revenue Business services. To serve the Bill, Billing-Service requires demand. Demands will be prepared by Revenue modules and stored by billing based on which it will generate the Bill.
Pre-requisites
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
Prior Knowledge of KAFKA
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON, etc.
Prior knowledge of the demand-based systems.
Following services should be up and running:
user
MDMS
Id-Gen
URL-Shortening
notification-sms
Key Functionalities
eGov billing service creates and maintains demands.
Generates bills based on demands.
push created and updated bill/demand to Kafka on specified topics
Updates the demands from payment when the collection service takes a payment.
Deployment Details
Deploy the latest image of the billing service available.
Configuration Details
In the MDMS data configuration, the following master data is needed for the functionality of the billing
MDMS
Business Service JSON
TAX-Head JSON
Tax-Period JSON
bs.businesscode.demand.updateurl
{
Each module’s application calculator should provide its own update URL. if not present then 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
kafka.mgramseva.create.demand
mgramseva-create-demand
topic name to push demand created, to be consumed by mgramseva adaptor
kafka.mgramseva.update.demand
mgramseva-update-demand
topic name to push demand updated, to be consumed mgram sevaadaptor
kafka.mgramseva.create.bill
mgramseva-create-bill
topic name to push bill created, to be consumed mgram seva
kafka.mgramseva.update.bill
mgramseva-update-bill
topic name to push bill updated, to be consumed mgram seva
Integration
Integration Scope
Billing service can be integrated with any organization or system that wants a demand-based payment system.
Integration Benefits
Easy to create and simple process of generating bills from demands
The amalgamation of bills period-wise for a single entity like Water connection.
Amendment of bills in case of legal requirements.
Steps to Integration
Customers can create a demand using the
/demand/_create
Organizations or Systems can search the demand using
/demand/_search
endpointOnce 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 be used to cancel the created ones or update workflow if configured.
Interaction Diagram
Interaction Diagram V1.1
Reference Docs
Doc Links
Title
Link
Id-Gen service
url-shortening
MDMS
API List
Title
Link
/demand/_create, _update, _search
/bill/_fetchbill, _search
/amendment/_create, _update
Apportioning
What is apportioning?
Adjusting the receivable amount with the individual tax head.
Types of apportioning V1.1:
Default order based apportioning(Based on apportioning order adjust the received amount with each tax head).V1.1
Types of apportioning V1.2: (TBD)
Proportionate based apportioning (Adjust total receivable with all the tax head equally)
Order & Percentage based apportioning(Adjust total receivable based on order and the percentage which is defined for each tax head).
Principle of Apportioning
The basic principle of apportioning is, if the full amount is paid for any bill then each individual tax head should get nullify with their corresponding adjusted amount.
Example: Case 1: When there are no arrears all tax heads belong to their current purpose:
TaxHead
Amount
Order
Full Payment(2000)
Partial Payment1(1500)
Partial payment2(750)
Partial payment2 with rebate(500)
WS_CHARGE
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
Case 2: Apportioning with two years of arrear: If the current financial year is 2014-15. Below are the demands
TaxHead
Amount
TaxPeriodFrom
TaxPeriodTo
Order
Purpose
WS_CHARGE
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
if any payment is not done, and we generating demand in 2015-16 then the demand structure will as follows:
TaxHead
Amount
TaxPeriodFrom
TaxPeriodTo
Order
Purpose
WS_CHARGE
1000
2014
2015
6
Arrear
AdjustedAmt
0
WS_CHARGE
1500
2015
2016
6
Current
AdjustedAmt
0
Penality
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
Last updated