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.
