Thanks David. I was using the term "subscription" too loosely. I understand the difference in the various entities.
Based on the ProductSubscriptionResource it appears as though a different product must be configured for different durations. For example if I sell a magazine and have the option to get a 1, 2, or 3 year subscription I would have to setup separate products. Is this correct? Can you elaborate on your statement about upfront payment. You said : "If you want a customer to pay for a long period up front, you would just configure a Product for that." Do you mean I would set the price for the full amount of the subscription? That is fine for accepting payment, but how would I handle fulfillment? Your other scenario for paying monthly by generating an order from a shopping list would deal with fulfillment by default, because an order would be generated for each issue. Now another twist... What I really want to do is also introduce the idea of volume and issue to better represent the real world of the publishing industry. Each issue of a magazine gets a different ISBN code. I'm thinking Product Features and virtual/variant products could be used. So I could have a virtual product representing the magazine title. Then product features could be applied to the variants to define volume and issue (year and month.) Some customization would be in order at this point to allow a virtual product to be placed on an order, or at least a shopping list. Then some intelligence to figure out the month and year so we know what issue to send out first. Still not sure how I would handle payment and fulfillment. ----- Original Message ----- From: "David E Jones" <[email protected]> To: [email protected] Sent: Monday, March 9, 2009 6:58:23 PM (GMT-0600) America/Chicago Subject: Re: subscriptions It sounds like you're misunderstanding the meaning of various entities: Subscription: keeps track of entitlement to SubscriptionResource for a certain period of time (ie history of what was purchased/etc, used to check permission to access, etc) SubscriptionResource: you would have one of these records for each resource, such as a file or a set of files, or a publication, or whatever ProductSubscriptionResource: this is where you specify how much time and to what resources the customer is entitled to when they purchase the Product; the system automatically creates a Subscription record for each of these when the Product is purchased If you want a customer to pay for a long period up front, you would just configure a Product for that. If you want the customer to pay monthly, but sign up for a longer period of time (like a year) then you would have a Product setup for 1 month of access, and create a ShoppingList for a recurring Order to happen once a month for 12 months. -David On Mar 9, 2009, at 4:38 PM, Vince M. Clark wrote: > I am looking to use the existing subscriptions functionality as a > starting point for handling magazine orders and need some clarity in > two areas: > 1) Duration of subscriptions. The example product, GZ-NEWS-1MO > suggests that the product itself has something to do with the > duration of the subscription. Is this correct? The subscription > record has a start and end date and I would expect this to control > the duration. > 2) Recurrence. I have seen posts on the ML about using re-order > shopping lists to create a new order for each issue of a > subscription. How would this work if it were paid upfront? Would you > accept a customer payment for the full amount and then apply it each > time an order was generated? I make the assumption here that an > order is not created for the entire duration. One order would be > generated for each issue until the subscription period ended.
