|
|
9/2/2015 3:13:42 PM
default 100 mSec timeout
We want to at least wait for a 5 sec before the timeout so the value needs to be bumped to 50.
|
8/27/2015 6:59:15 PM
in mustache templates (to avoid throwing exceptions)
|
9/2/2015 11:26:22 PM
of early cancellation for instance, we want the cancellation event to trigger the next invoice (even though
we are not due for next billing date), and compute a pro-rated invoice for the last period.
|
9/2/2015 10:20:10 PM
cancellation date is not correctly respected.
Also add a beatrix test case and fix existing unit test to verify the new behavior.
|
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
|
