9/2/2015 10:17:05 PM
billing.
The previous code would use the endDate of the latest (in arrear usage) item, and apply some heurstics based on that date
to figureb out the next notification date associated to that specific usage section in a specific subscription.
Instead, we now compute thgat logic from the in arrear usage code where all the information is already available.
|
9/2/2015 6:43:14 PM
and make sure to remove usage sections when the subscription has been cancelled.
Please enter the commit message for your changes. Lines starting
|
9/2/2015 12:22:21 AM
(pass 2)
Add new method getNextBillingCycleDate which is used to compute next notification for IN_ARREAR recurring mode.
Add BillingIntervalDetails tests for IN_ARREAR recurring mode
|
8/30/2015 9:18:10 PM
the change, the code would compute those future notifications after having generated the invoice. The code
was cumbersome because some of the info to compute those date were not easily accessible. Also, this does not work
for when we will need to implement the future notification date in the recurring IN_ARREAR because the information would only
be accessible deep inside the invoice computation logic.
|
8/29/2015 1:49:50 PM
existing tests
Fix an issue /BillingIntervalDetail
Add new test TestInArrearBillingMode
|
8/28/2015 1:34:12 AM
IN_ARREAR
Needs specific IN_ARREAR tests
|
8/28/2015 12:36:51 AM
up being null!
|
|
|
8/24/2015 12:51:55 PM
support for db-helper
|
|
|
