"Pausing" subscriptions - and other temporary changes

I’m wondering whether sale_subscription is the correct choice for basing the following onto. I’d appreciate you comments and possible other recommendations

In a CAS (Community Supported Agriculture, SoLaWi) basically one subscribes to a weekly share of the crop. A CAS might provide different types of “crop”, e.g vegetable, bread, meat, juice; also different “sizes” of share might be available, or one can subscribe to several shares. (There are quite different types of CAS, so things vary. Anyhow most share these basic princibles)

At a first glance, sale_subscription` seems to be the perfect match for this: Each of the “crops” will become a subscription-line - and everything is fine :slight_smile:

It showed up that in detail this is much more complicated:

The CASes I try to specify a solution for, have a quite complicated (yet customer-friendly) model: One can pause the whole subscription (for vacation), or parts (e.g. no meat next week) and even temporary change any of these parts (bigger bread in thee weeks)

For example:

  • Basic subscription is ongoing (which is important for invoicing)
  • temporary pause whole subscription (I’m on vacation)
  • temporary change contact (a friend is picking up my share)
  • temporary change delivery address (a friend is picking up my share at another place)
  • temporary change size (kids are visiting me, need more vegetable)
  • temporary change number (kids are visiting me, need more bottles of juice)
  • temporary add some subscription_line (kids are visiting me, need meat)

My current state of planning is: Adding some “exceptions” layer on top of subscriptions. This layer would implement the temporary changes listed above (including start- and end-date). When creating a consumption, this layer would be take into account.


  • This would fit the user’s mental model of “subscription with exceptions” quite well
  • This would allow specifying changes (and duration) in advance


  • Given the long list of possible exceptions above, this looks like not being a good solution.

Comments? Ideas?

I think you should try to manage all your exceptions on consumptions. This means:

  • Once the customer creates a subscription to a croop the system will generate the consumptions in advance (next week consumptions are created today).
  • If the user has some special requests (any of your exception) this information is added into the consumption before it gets consumed.

As invocies are generated from consumptions you will also have the right information to create the invoice. You did not mention this part but I imagine you want to invoice the real consumption.

Of course, if the change become permanent, you should update the subscription line to be able to generate the new consumptions with the right data.