Billing Service

Version:

V1.1(Jan-2019 To Till Today)

Audience:

Product Managers
Developers
Testers
Co-creation partners
Implementation Team
Third Party(TP) integrators

Background:

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

Functionality:

Billing-Service mainly works with two types of functionality as following:

Demand
Bill

Objective:

The main objective of Billing module is to serve the Bill for all revenue Business Service based on criteria.

Feature List:

Create Demand
Search Demand
Update Demand
Generate Bill
Search Bill
Update Bill

Current Masters :

Business Service
Tax Periods
Tax Heads

Feature List:

Feature	Category	Why	Current	Impacted module	Priority
Remove GL codes from Billing service (faster roll out)	TechDebt	Gl codes belongs to finance system, hance finance module should own it.	Unnecessary data configuration for each revenue module.	PT, TL, Collection, Finance	P1
Move all the master to MDMS (faster roll out and audit)	TechDebt & Enhancement	1.Maintainability and Default auditing, 2.Simple with one call it can fetch all the masters from MDMS	1.Each time we need to make multiple api calls to post and search any master data. Currently there is no auditing functionality	PT,TL,Collection	P1
Business service should be a common master at system level, and it should have a capability of n level children	Enhancement	1. Single source of truth for the data 2. No change in future if level of child will increase 3. Wf also should be refer to System level Business service master	1. Currently every module has its own Business service master(Billing Svc) 2. Maintaining data in multiple master is difficult	Collection,WF, PT, TL	P2
Roundoff of bill amount should be standardised at the platform level (Keep it to 2 decimal)	New Feature	Each revenue module is writing the logic for round off the bill amount.	Each revenue module is writing the logic for round off the bill amount.	PT, TL	P1
Make Income as +ve and deduction as -ve in demand (Ease the apportioning logic)	Enhancement	1.Easy to understand , 2.Generating report as head wise is easy, 3.Makes simple system for integrator	1.Difficult to write query, 2.Query performance will be better 3. Have some issue in prod from the Report side	PT,TL,Collection,Finance	P1
Revenue module flow should be standardized at platform level for all known use-cases(A Step to apply and pay)	NewDesign	Reports, Dashboard, and third party integration(Finance) will be much more easier. Refer the diagram V1.1 below	Currently Collection and Finance integrations are difficult to support,	Revenue module, Collection, Finance, Report	P1
Multiple owners in Demand so that we can generate consolidated bill for all revenue module?	Enhancement	In Future Billing Service will support User based consolidated bill for all business service, without this it will not be possible	Current system takes only one owner	PT,TL	P3
Single api to create demand and get the bill for the same	Enhancement	Reduce multiple call to create demand and bill for all the revenue module	Currently each revenue module integrating with demand and bill api	NA	P3
First Level abstraction of calculation	New / Enhancement			PT,TL	P2
Billing migration	Impacted				P1
Collection migration	Impacted				P1

Flow diagram V1:

Flow diagram V1.1

Interaction Diagram V1.1:

Apportioning :

What is apportioning?

Adjusting the receivable amount with individual tax head.

Types of apportioning V1.1:

Default order based apportioning(Based of 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 equaily)
Order & Percentage based apportioning(Adjust total receivable based on order and the percentage which is defined for each tax head).

Principle of apportioning:

Basic principle of apportioning is, if 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 is no arrears all tax heads are belongs to current purpose:

TaxHead	Amount	Order	Full Payment(2000)	Partial Payment1(1500)	Partial payment2(750)	Partial payment2 with rebate(500)

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

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

TaxHead	Amount	TaxPeriodFrom	TaxPeriodTo	Order	Purpose

Pt_tax	1000	2014	2015	6	Current
AdjustedAmt	0

Penality	500	2014	2015	5	Current
AdjustedAmt	0