0.20.x releases. The
0.21.x releases are a set a development/feature releases that won't be supported on the public mailing list. Use with caution if you must, or stay away from it!
Installation and Upgrade Notes
Also, there was a merge from master, a.k.a
0.20.13, containing the following fixes from milestone 78
There was a substantial amount of changes in our catalog api, as described by #1190, #1189: The catalog apis should now be simpler, i.e. require less
dates to be passed around. The api changes can be seen from the following api diff.
InvoiceItem now exposes the
catalogEffectiveDate, which in conjunction with our new catalog api, makes it easy to pull the catalog version associated to a given invoice item.
In terms of plugin apis, we have also introduced a new
Note: All plugins should be recompiled using the latest base
There is a change of behavior associated with cancelation of a subscription that was previously invoiced and whose invoice item got fully adjusted:
- (a) In case of a cancelation at SOT (start of term), the previous code would generate nothing, and the new behavior will generate a $0
- (b) In case of a cancelation through mid period, the previous code would re-invoice for the active part, and the new code will not (and will generate a $0
- (c) In case of a cancelation at EOT (end of term), there is no change in behavior
Let's look at a concrete scenario where we invoiced an
ANNUAL subscription for the period
- (a) A SOT cancelation on
2013-8-18would simply generate a $0
REPAIR_ADJfor the period
- (b) A cancelation on
2013-9-17used to recreate a
RECURRINGitem for the part
2013-9-17. Instead we will not regenerate such
RECURRINGand simply generate the
REPAIR_ADJfor the period
- (c) no change (since there is nothing to repair)
Note that this change was motivated to have a consistent behavior across these various use cases: We always repair the piece that was cancelled and because the item was fully adjusted the repair amount is $0. We expect existing data to not be modified, so the change would only affect new fully adjusted items with cancelation.
> kpm migrations killbill killbill-0.21.4 killbill-0.21.5
alter table invoice_items add column catalog_effective_date datetime after usage_name; alter table invoice_item_history add column catalog_effective_date datetime after usage_name; CREATE TABLE invoice_billing_events ( record_id serial unique, id varchar(36) NOT NULL, invoice_id varchar(36) NOT NULL, billing_events blob NOT NULL, created_by varchar(50) NOT NULL, created_date datetime NOT NULL, account_record_id bigint /*! unsigned */ not null, tenant_record_id bigint /*! unsigned */ not null default 0, PRIMARY KEY(record_id) ) /*! CHARACTER SET utf8 COLLATE utf8_bin */; CREATE UNIQUE INDEX invoice_billing_events_invoice_id ON invoice_billing_events(invoice_id); alter table invoice_payment_control_plugin_auto_pay_off drop column payment_method_id;