|
|
12/19/2016 8:49:36 PM
handling. See #678
|
12/19/2016 1:33:39 PM
Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/19/2016 10:13:08 AM
should always sit at the same level or below corresponding
ADD items in the tree. Add sanity check for this and various tests around
repairs and overlapping periods.
See https://github.com/killbill/killbill/issues/664.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/16/2016 11:26:33 PM
See #678
|
|
|
|
|
12/16/2016 8:53:02 AM
the current behavior under atypical scenarios, namely:
* Complex timelines with various same-day changes do not trigger any bounds
* Duplicate (buggy) billing events do not lead to invoicing errors
* If multiple fixed items for a given subscription and start date already exist on disk, the next run will not re-generate one
* If multiple recurring items for a given subscription and service period already exist on disk, the next run will not complete (the merge logic will detect the existing bad state, i.e. double billing)
While the system can already handle these bad cases, it's still possible that either our items generation
code (proposed items) or the merge algorithm have issues in even more complex setups (repairs, adjustments, etc.).
To pro-actively detect these, this patch introduces new internal safety checks on the resulting list:
* At most one FIXED item should be present for a given subscription id and start date
* At most one RECURRING item should be present for a given subscription id and service period
The behavior can be disabled by setting org.killbill.invoice.sanitySafetyBoundEnabled=false.
See https://github.com/killbill/killbill/issues/664.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 7:20:41 PM
sure payment id/key, transaction id/key and processed amount/currency
are correctly passed to all PaymentControlPluginApi callbacks.
In particular, make sure that they are populated even for the priorCall
when completing a transaction.
This fixes https://github.com/killbill/killbill/issues/617.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 4:54:28 PM
Pierre-Alexandre Meyer <pierre@mouraf.org>
|
