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:
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 |
|
|
|
|
|
|
|
|
|
|
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 demand structure will as follows:
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?