Support for quantity in APIs

[pierre]

• When creating subscriptions, ability to specify a quantity (e.g. price=$20/mo, quantity=$2 => invoiceItem recurring amount=$40). Related: Seat based pricing #1434
• When creating external charges, specifying a quantity should be reflected into the invoice (e.g. price=$20, quantity=$2 => invoiceItem amount=$40)

[shaun-forgie]

Awesome...work Pierre. This will allow for so many more customers to benefit from the Kill Bill project. Couple of questions:
Is this coming in 0.23?
How will this impact the catalog structure?

[sbrossie]

@shaun-forgie Could you describe the exact use case you are after?

Is this a model where you want to invoice/pay in-advance based on a well defined number of seats? In such a scenario, being able to create one Plan in the catalog with the price of 1 seat and allow to toggle the quantity when creating the subscription should be enough? In such a model, do we expect the number of seats associated with a subscription to vary, and if so, what is the expectation?

Also, would our price override feature not be enough to implement this - if not what is missing?

[shaun-forgie]

@pierre Two scenarios I see

1. in-advance: with per seat cost defined in catalog and quantity in subscription.
2. in-arrears: with usage records providing quantities for invoice item calculations.

In the catalog the all or top tiered policy can still be used for rating purposes. Usage records would be supplied each month to trigger changes to the base quantity defined in the subscription.

A subscription quantity update policy should be defined in the invoice plugin to update the default quantity based on the current value of the usage record received for the period.

Pricing should be driven out of the catalog with tiered usage models.

[sbrossie]

@shaun-forgie My question was only for in-advance use case, and I am not really asking about how it should be implemented, but more interested about 1/ the use case(s) and 2/ why price override is not a good option already (given a Plan, you can override the price on a per subscription level to adjust for the # seats) ?

[shaun-forgie]

@sbrossie The problem I have is that prices and quantites are different things. Using price over rides to change a quantity is confusing at best.

[sbrossie]

@shaun-forgie I agree it would be best to have support for quantity, but fundamentally, you send a seat price and a quantity and you expect the system to compute total price = seat price * quantity and then have that reflected on your invoice. We already have support to override Plan#price, so you could make the multiplication on the client side and leverage this mechanism. So aside from the convenience is there anything else missing?

Also, on the convenience side, we allow plugins to implement custom endpoints, so you could have a custom endpoint that takes the quantity and implement this tiny piece of logic and then offer the 'nice' api to your client.

Mostly I am trying to understand if changing our apis, our tests, our docs, our DB schema, ... to support this quantity is really worth the effort.

[shaun-forgie]

You need to ensure the conceptual integrity of your framework is maintained. Define things in the catalog. Assign the catalog values to the subscription when creating it and update them as needed. A per seat usage cost for a given range of seats (top tier policy) can be defined in the catalog giving users price per seat costs for a given number of seats.

You then need to be able to query the system catalog for the per seat price at a given quantity so that this can then be used to update the subscription. In cases where only the quantity changes but the seat price remains the same only the quantity should be updated.

System logic on pricing and quantity breaks needs to be controlled at the server end. The client should ask the server for a change to the quantity of seats that are being applied to the subscription in much the same way that happens when previewing changes on future dated invoices with a dry run. Business alignment and approval rules can then also be applied to the change request.

Hope that helps.

[pcasaretto]

Hi there! I'm trying to learn more about Killbill's internals and this seems like a great chance to do that and help with an importante feature.
Is anyone actively working on this?

[shaun-forgie]

From what I have heard quantity is coming in the 0.24 release towards the end of the year. I am not clear on the actual implementation as yet. Ideally qty would be defined in the catalog as part of the recurring phase price. Typically this would be for a single unit where the numeric value was =1. At the time of creating a subscription you would override the qty with the number of units via the price override mechanism. This would result in invoice items containing qty × price = total fields.

[pcasaretto]

Sounds good. How does the organization manages the development of a feature such as this?
Is there any way I can get involved?

[shaun-forgie]

Follow the github way.....fork the repo and generate a pull request on your first proposal.

[pcasaretto]

Got it. Just wanted to minimize the chance of duplicated effort.