...

Version:

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:

Image RemovedImage Added

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:

...

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

Interest	500	2014	2015	4	Current
AdjustedAmt	0

Cess	500	2014	2015	3	Current
AdjustedAmt	0

Exm	-250	2014	2015	1	Current
AdjustedAmt	0

...

TaxHead	Amount	TaxPeriodFrom	TaxPeriodTo	Order	Purpose

Pt_tax	1000	2014	2015	6	Arrear
AdjustedAmt	0

Pt_tax	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

Questions, Clarification and Suggestions:

How tax period and demand period and billing cycle should work at platform level?
Difference between tax period and billing cycle (How it should work)?
On partial payment do we need to give rebate
How to work with multiple demand in a bill and the apportioning for all(now how billing system will know which demand need to be adjust first)
Combination of tax head + purpose should be defining the apportion order?
If we are updating details of revenue module which can affect the calculation then how to handle that?

Versions Compared

Old Version 3

New Version 4

Key

Version:

Page Comparison

Versions Compared

Old Version 3

New Version 4

Key

Version: