Advance Payment

This feature provides the user with functionality to pay more than the bill amount. The advance or extra amount paid will be automatically adjusted in the next billing cycle. Services which want’s to enable advance payment will have to create a new taxhead in which the advance amount will be stored.(The code of the taxhead should contain the word 'ADVANCE' in it/ eg: PT_ADVANCE_CARRYFORWARD, WS_ADVANCE_CARRYFORWARD etc.).

The following is a sample configuration of billing service master data which has advance payment enabled:

{ "businessService": "WaterCharges", "code": "WC", "collectionModesNotAllowed": [ "DD","OFFLINE_NEFT","OFFLINE_RTGS","POSTAL_ORDER" ], "partPaymentAllowed": false, "isAdvanceAllowed": true, "demandUpdateTime": 86400000, "isVoucherCreationEnabled": false }

The following is a sample configuration of advance taxhead:

{ "category": "ADVANCE_COLLECTION", "service": "PT", "name": "Pt advance carry forward", "code": "PT_ADVANCE_CARRYFORWARD", "isDebit": true, "isActualDemand": false, "order": "0", "isRequired": false }

The services that have impacted by advance changes are egov-apportion-service and billing-service. The collection-services will now point to v2 version of apportion API. The following are the properties that has to be added in infraOps:

In billing-service the apportion host has to be overwritten:

- name: EGOV_APPORTION_HOST valueFrom: configMapKeyRef: name: egov-service-host key: egov-apportion-service

In collection-service the apportion API path has to be overwritten:

(Till the time we do punjab upgrade the value of the variable should be taken from environment’s yaml file)

Flow:

Whenever payment is done of amount more than the bill amount, a new billAccountDetail is created and added in the latest billDetail with amount equal to the extra amount. When demand is created for the same consumer code but for different billing cycle the advance amount will get adjusted.

Following is a sample json of bill before and after payment

The bill for which advance payment is being done:

 

The output of the payment on the above bill (response contains a new advance taxHead):

 

Example:

Created a demand for billing cycle T1 with total amount of 1300 and paid 3300 with 2000 as advance:

Demand

Billing Cycle 

TaxHead

Amount

Collected

D1

T1

TAX

1000

1000

D1

T1

INTEREST

100

100

D1

T1

PENALTY

200

200

Total





1300

3300

D1

T1

ADVANCE

1300-3300 = -2000

0

 

Now when we create a demand for billing cycle T2 with total amount of 1700 the billing service will call apportion API if any advance is available to adjust the advance in the collected amount of current demand

Demand

Billing Cycle 

TaxHead

Amount

Collected

D2

T2

TAX

1200

1200

D2

T2

INTEREST

200

200

D2

T2

PENALTY

300

300

D2

T2

ADVANCE

0

0

Total





1700

1700

and the previous billing cycle demand is updated to:

Demand

Billing Cycle 

TaxHead

Amount

Collected

D1

T1

TAX

1000

1000

D1

T1

INTEREST

100

100

D1

T1

PENALTY

200

200

D1

T1

ADVANCE

-2000

-1700

 

Apportion Service:

Changes are made in apportion service to handle apportioning of both bill and demand. The core apportioning logic is extracted out and both demand and bill are translated first to same common object and then apportion is executed. Any new apportion logic implementation will just have to implement the common interface and it will handle the apportioning of both bill and demand. In case of apportion of demand only the available advance is apportioned as we cannot pay against a demand while in case of bill both advance and amount paid is apportioned .Following is the postman collection for the new V2 API’s:

https://github.com/egovernments/municipal-services/commit/3adc34feb4ccf7b43ce7253eb0f8e86b872a6cb3