⚠️ Users should stick to 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

• New feature release Git changelog.
• See associated milestone 70

Also, there was a merge from master, a.k.a 0.20.13, containing the following fixes from milestone 78

API Changes

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.

Also, the 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 UsagePluginApi#getUsageForSubscription.

Note: All plugins should be recompiled using the latest base killbill-oss base pom.xml version 0.143.36.

Behavior Changes

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 REPAIR_ADJ item
• (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 REPAIR_ADJ item)
• (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 2013-8-18 -> 2014-8-18:

• (a) A SOT cancelation on 2013-8-18 would simply generate a $0 REPAIR_ADJ for the period 2013-8-18 -> 2014-8-18
• (b) A cancelation on 2013-9-17 used to recreate a RECURRING item for the part 2013-8-18 -> 2013-9-17. Instead we will not regenerate such RECURRING and simply generate the
  REPAIR_ADJ for the period 2013-9-17 -> 2014-8-18
• (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.

DB Changes

> 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;