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