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, | 1.Each time we need to make multiple api calls to post and search any master data. | 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 | 1. Currently every module has its own Business service master(Billing Svc) | 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 , | 1.Difficult to write query, | 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, | Currently Collection and Finance integrations are difficult to support, | Revenue module, Collection, | P1 |
Multiple owners in Demand so that we can generate consolidated bill for all revenue module? | Enhancement | In Future Billing Service will support | 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?