Versions Compared

Old Version 1

changes.mady.by.user Rupam Baruah

Saved on

compared with

New Version 2

changes.mady.by.user Rupam Baruah

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Billing-Service

      

Version:


    • V1.1(Jan-2019 To Till Today)

Audience:


    1. Product Managers
    2. Developers
    3. Testers
    4. Co-creation partners
    5. Implementation Team
    6. 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:


    1. Demand
    2. Bill

Objective:

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

Feature List:


    1. Create Demand
    2. Search Demand
    3. Update Demand
    4. Generate Bill
    5. Search Bill
    6. Update Bill

Current Masters :


    1. Business Service
    2. Tax Periods
    3. Tax Heads
    4. Gl Code()

Feature List:


Feature

Category

Why

Current

Impacted module

Priority

Remove GL codes from Billing service (faster roll out)

TechDebt

Image Added 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.

Image Added 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

Image Added 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

Image Added 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

Image Added 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

Image Added 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

Image Added First Level abstraction of calculation  

New / Enhancement

 

 

PT,TL

P2

Billing migration

Impacted

 

 

 

P1

Collection migration

Impacted

 

 

 

P1


 

Flow diagram V1:

Image Added

Flow diagram V1.1


Image Added

Interaction Diagram V1.1:

Image Added

Apportioning :

What is apportioning?
Adjusting the receivable amount with individual tax head.
Types of apportioning V1.1:


    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)


    1. Proportionate based apportioning (Adjust total receivable with all the tax head equaily)
    2. 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

  1. 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)
  2. Combination of tax head + purpose should be defining the apportion order?
  3. If we are updating details of revenue module which can affect the calculation then how to handle that?