Some business models are based on subscription. Those business needs a way to generate periodically invoices. Also some services could be stopped or added during the lifetime of the subscription.
description (copy in party language from product service)
quantity (required, default 1)
UoM (copy from product service)
unit_price
consumption rrule (copy from service)
consumption delay (optional, copy from service)
next consumption date (for optimisation)
start date (optional, inside subscription dates)
end date (optional, inside subscription dates)
sale.subscription.consumption
line (required)
date (required)
invoice line
quantity
Workflow
A running subscription could be set back to draft for edition but only some field will be editable if consumptions already exist like end date and the quantity.
A cron task will run every day on lines with consumption rrule and a “next consumption date” - delay before today to create consumption record with the quantity from line. It will recalculate the “next consumption date” after.
A second cron task will run on subscription with a “next invoice date” before today to create an invoice. The invoice is generated based on the consumption. The consumption used will be linked to the invoice line (like timesheet lines in project_invoice). The taxes will be applied using the default taxes of the service product and using the tax rule of the party.
This is probably not relevant to your use case, but often a company does a subscription on a stockable item. So, the product on sale.subscription.service can also be something other than service.
I guess you are talking about subscription that involve an asset. But it is always a service that is invoiced, the asset is only assigned. For this case, it will require an extra module to manage the assignation of the asset to the subscription.
There is also another case where the subscribed service is about shipping some product recurrently. I guess the service should also be extended to define a list of product to ship and the consumption creation should also create the corresponding shipment.
I add a Future section on the blueprint with those cases.
On SISalp business, the customer subscribes for a service which is to be renewed when it expires. Duration is 1 month or 12, 15 or 24 months
Some time before expiration, I warn him.
He gets a renewal proposal. He can modify it to update his contract and confirms the renewal order.
He pays the amount of the order for the duration set in the order.
I renew the service on his new contract.
I generate a paid invoice.
He might opt in for auto renew. In this case I send him a renewal order, wait for his payment and generate a paid invoice.
I don’t think this “ovh like” process will be compatible with the proposed design. Will it ?
I do not see why it could not work.
Of course the explicit renewal and the single invoice makes it less interesting because at the end it is similar to a classic sale.
It seems that the current design only considers periodic invoicing, which is a particular and limited use case.
I guess that a design based on periodic order would fit both periodic invoicing by an auto-confirm order, and order based subscriptions which is more flexible imho. The fact that is is a classic sale is an advantage, I think. In case I need monthly payment on a 12 month contract I prefer use partial payment conditions and plan and partial invoicing.
Today I manage my subscriptions by hand because I miss a module to do it.
Creating a new sale is not a subscription because under a subscription the condition are not renegotiated on each period.
What you describe is not a subscription but renewal process. And in this renewal process, the sale is/could be renegotiated.
Of course, there is a need for a sale renewal module but the goal is different from the subscription.
This way of thinking is because you are talking about a sale where the service is prepaid no matter what will happen.
Yes, for me, by definition, subscription = sale renewal.
In fact, I don’t really see in which case a subscription could be a periodic invoice. Which examples have been considered ?
some hosting services (which invoice on consumption instead of fixed price)
Of course some do not have recurring consumption but manually created which this design takes into consideration. Also some of prepayment in addition that could be also implemented by extension.