Document toolboxDocument toolbox

Payment Allocation


Contents 

  1. Problem 
  2. Test Done Prior to Updating The New Code and Identified Problems 
  3. Proposed Way It Should Work 
  4. Conclusion After Testing with New Code 
  5. What Went Well Prior to Updating The New Code (Details) 
  6. What Didn’t Go Well Prior to Updating The New Code 
  7. Test After Updating the New Code (In Test Environment)
  8. Conclusion 

Problem 

Partial ppayments are not being proportionally allocated across products to their daily rate or to monthly installment. Therefore, that has been leading to different issues where (1) if a customer has two products with the same contract length installed at the same day is not finished paying back at the same time. (2) Amount remaining to be paid appearing in negative once a customer has already fully paid that particular product 

Test Done Prior to Updating The New Code and Identified Problems. 

Below are the tests are done to very if (1) payment split proportionally across all products if a customer hasn’t completed paying for appliances, (2) if all amount paid after completion of appliance goes on ESF currently. 

  1. A big payment that makes a customer complete paying for all products (resemble ePay) (this seemed to work correctly) 
  2. A payment that makes some of the products-completed (this seemed to work correctly). However, there were some instances where the amount remaining to pay appeared to be negative instead of being zero.
  3. A week and a half payment to check how small payments are split across products (this seemed not to work well) 
  4. Days and Amount Until Energy Fees Only change after a payment (this seemed to work properly on the big payment that makes customers complete, but not on small payments) 
  5. What happens to customers on time if customer make payment when he has completed paying for appliances (all amounts turn into on-time) 

Proposed Way It Should Work 

For payment to correctly split across all products to allow Bboxx to communicate to customers with the correct amount they have paid for and probably ease the accounting, payment allocation might be working in the below logic(steps,1,2,3).  

  1. If a customer hasn’t completed paying back the appliances, any amount paid proportionally split on a monthly installment rate per product. 
  2. E.g. For a customer with the below products if he makes a payment of 9600 (50% goes on ESF,17% goes on Welcome Pack, 15% for the 2 led bulb set respectively) until this customer completes any of these products. 

 

Customer ID 

BXCR66535616 




Payment 

9600 




Details 

R 

MR 

What Should Happen 

Status 

ESF V1 

97 

2900 

50% 

Installed 

WP V1 

33 

1000 

17% 

Installed 

Led bulb set 

30 

900 

15% 

Installed 

Led Bulb Set 

30 

900 

15% 

Installed 

  1. If this customer, for instance, completes one of the products (bulb set), then the monthly installment rate per product changes so that his next top-up is split proportionally on the monthly rate of the only remaining products. E.g. on the next X amount payment (60% goes on ESF, 21% goes on Welcome Pack, and 19% goes on Led bulb set) 

Customer ID 

BXCR66535616 




Payment 

6000 




Details 

 

R 

What Should Happen 

Status 

ESF V1 

97 

2900 

60% 

Installed 

WP V1 

33 

1000 

21% 

Installed 

Led Bulb set 

30 

900 

19% 

Installed 

Led Bulb Set 

30 

900 

0% 

Completed 

  1. After completion of paying for appliances, (1) the “amount remaining” to pay become zero, (2) product status be marked “completed” 
  2. After completion of appliances and 3 years of ESF, “Days and Amount Until Energy Fees Only” decrease to zero.  
  3. Any amount paid after that go on ESF at 100% and turn into on-time 

Conclusion After Testing with New Code 

  1. The issue of application product remaining amounts being negative was resolved.  
  2. Small payment allocation sometimes is not correct (means doesn’t split proportionally to the monthly installment all the time), however, depending on the next payment the amount, this can be fixed by itself. However, this works much better than how previously it was used to split. 

 

What Went Well Prior to Updating The New Code (Details) 

At #1: A big payment that makes a customer complete paying for all products (resemble ePay) 

(1) Product with a high monthly rate and long completion date took the big portion. For instance, a customer had ESF v1 and Welcome Pack V3 (3bulbs), his monthly rate was 2900 and 1900 respectively (that is 60%: 40%), but the payment split at 84%: 16%. (more details in the Word Doc and Excel sheet). Which is correct 

(2) The days until Energy Fees Only dropped down to zero 

At#2: A payment that makes some of the products-completed 

(1) Product with a high monthly rate (installment) and long completion date took a big portion of the payment. With the payment of 270000 Rwf, Welcome pack V1 and Led bulb set were completed, except ESF. Which is correct 

(2) The “Days and Amount until Energy Fees Only” dropped down to zero. Which is correct 

What Didn’t Go Well Prior to Updating The New Code  

Test 5,6,7 from the excel sheet didn’t seem to follow the rule, there were some negative numbers (it means instead of a new payment to proportionally split to all products it only went to one product and also reduced to the prior payment of other products). (more evidence below at #3) 

A few examples. 

  1. Test 4,5,6 from the excel sheet didn’t seem to follow the rule, there were some negative numbers (it means instead of a new payment to proportionally split to all products it only went to one product and also reduced to the prior payment of other products. (more details in the excel sheet). 

The step that leads to the issue 

  • Added a payment of 1200 to customer BXCR66656145, then compared 
    actual result VS Expected result 
  • Application products amount paid for (Welcome pack v1 and 2 led bulb set) decreased instead of increasing 
  • Days/amount until ESF only decreased instead of increasing 

 
 1. Made payment of 3500 to a customer (BXCR66624234) and instead of the payment to split across all the products, the whole amount has gone to one product. Additionally, the days and amount Until energy fees only didn’t change, stayed constant. 

2. Again I made another payment of 129500 to a similar customer (BXCR66624234) that made him complete paying back the appliances and 3 years of the ESF. The amount split across products, however, instead of for the amount remaining to be zero at one of the appliances, it showed up in a negative balance.

 

What happens on customers on time if customer make payment when he has completed paying for appliances (all amounts turn into on-time) 

Test After Updating the New Code (In Test Environment) 

  1. A big payment that complete appliances work correctly  
    1. I made a payment almost equivalent to Amount Until Fees Only (67000 Rwf) to the customer BXCR66651018 
      1. The payment proportionally split across all products nearly to the monthly installment rate
      2. Days and Amount Until Energy Fees Only decreased to zero  
    2. There was no negative balance at the amount left to pay (it was zero) 

Test1 

 

 

 

 

 

 

 

 

Customer ID 

BXCR66651018 

 


Payment 

67000 

 

Details 

DR 

MR 

What Should Happen 

Amount Before Payment 

Amount After Payment 

Difference 

Reality 

ESF V1 

97 

2900 

51% 

69884 

105359 

35475 

53% 

WP V1 

33 

1000 

17% 

24098 

36000 

11902 

18% 

Led bulb 

30 

900 

16% 

22588 

32400 

9812 

15% 

Torch 

30 

900 

16% 

22588 

32400 

9812 

15% 

Total 

 

5700 

1 

 

 

67001 

1 

2. Payment after completion of appliances works well (100% goes on ESF). 

Example: I made another payment of 40000 Rwf to the same customer (BXCR66651018)  

  1. 100% went on ESF
  2. No change on Days and Amount Until Energy Fees Only (stayed Zero)

3. Small payment seemed also to work well. In some instances, it wasn’t splitting across all products by monthly installment rate, but on the next payment, it was updating itself. 

  1. Made two consecutive payments of 4800 Rwf and 1300 Rwf respectively to the customer BXCR66656145 
    1. The payment split nearly proportionally to the monthly installment rate  
    2. The total amount that was split across products seemed greater than the payment made, however, on the second payment the amount that was split across products was less which cancel the first and adjusted how the two payments should have proportionally split  

Below is also another similar example  

 

Cconclusion 

  1. The issue of application product remaining amounts being negative was resolved.  
  2. Small payment allocation sometimes is not correct (means doesn’t split proportionally to the monthly installment all the time), however, depending on the next payment amount, this can be fixed by itself.  

 Help Guide on Payment Allocation

https://bboxxeng.sharepoint.com/sites/africa/_layouts/15/Doc.aspx?sourcedoc=%7BC420A98D-5EAC-4546-A376-0855B4B39F5B%7D&file=Help%20Guide%20On%20Payment%20Allocation.docx&action=default&mobileredirect=true&CT=1580917925318&OR=ItemsView


BBOXX