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 
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.
Pro:
- This would fit the user’s mental model of “subscription with exceptions” quite well
- This would allow specifying changes (and duration) in advance
Con:
- Given the long list of possible exceptions above, this looks like not being a good solution.
Comments? Ideas?