CiviCRM Community Forums (archive)

Hi,

We want to use CiviCRM to track subscriptions to a weekly magazine. There is a case study of The Monthly Magazine (http://civicrm.org/casestudy/node/1718) explaining that CiviMember can be used to manage magazine subscriptions so we decided to go that route.

A subscription has the following characteristics:
 
* Subscription period: 1 month, 3 month, 6 month, 1 year
* Subscription type: normal, student, support
* Delivery: national, international
* Delivery options: closed envelope, prior

This results in a rather complicated pricing scheme:

Period   Normal    Reduced   Support   International   International Envelope
      price        price      price         normal      reduced
1yr           50           40           100           100              80            +60
6months   25           20           50           50              40            +30
3months   12,5           10           25           25              20            +15
1months   5           4           10           10              8            +5

I wonder what is the best way to model the data in the database.

Scenario 1: 1 membership type for the magazine subscription and custom field set, connected to the membership type, to store all characteristics.

This seems to be the cleanest implementation:

* The membership dashboard is not cluttered with membership types. There is only one memberschip type for the magazine. Details about a specific subscription are stored in the custom field set for the membership type.
* It is easy to make specific queries using the custom fields in the Find Membership screen.

However, using this approach it is not possible to calculate the right price. Using a custom field set, the options for characteristics like subscription period, subscription type cannot be mapped to a amount and hence there is no way to calculate the subscription price.

Scenario 2: define enough membership types so all possible combination of subscription parameters that amount to the subscription price are covered.

In this scenario, we get the correct price by selecting the corresponding membership type.

However:

* The membership dashboard is cluttered with a lot of membership types. These membership types don't have any purpose other than getting the subscription price right. To implement the pricing scheme above, we would need 24 different membership types. 
* Searching for specific subscriptions is less straightforward as in scenario 1.

Scenario 3: using price sets to reduce the number of membership types necessary.

It is possible to reduce the number of membership types required by using price sets. E.g: the amount for the evelope option could be added through a field in a price set.

Although the subscription price is right in this case, you lose the ability to query for subscriptions with the envelope option enabled.

Scenario 1 would be my preferred scenario as it resembles the real world situation more closely: there is one subscription type, that has certain characteristics and a given combination of characteristics will determine the subscription price. Is is possible to implement a hook to adjust the price based on the input during the subscription creation or modification? I expect we will need to able to adjust other values, such as the end date of the subscription, as well.

Another solution would be to allow membership custom fields to be mapped in price sets. The current implementation only allows for mapping with membership types.

Any ideas on what would be the best approach? Any experiences to share?

Thanks in advance.

c.



 

Hi Tony,

Thanks for the feedback.

Both additional memberships types (we would need 24 different types to support our pricing scheme) or price sets (you cannot get a report on the individual line items) are not acceptable for us. IMHO, that leaves us with the option of creating a custom field set to store subscription related data and use hooks to calculate the subscription price accordingly.

From what i read in the developers manual, this would be the right approach. However, I have very little experience in extending CiviCRM and I'm seeking confirmation by the community that this is indeed the way to go. Or point me to the right direction otherwise

Cheers

c.