Subscription entity

[Andrew Sykes]

Hi Folks,

I was thinking that it might be a good idea to add an autoRenew
attribute to the Subscription entity so that subscriptions could be
identified as being automatically renewable.

We could then create a service that queried the Subscriptions daily and
if one will expire in the next 24 hours and has autoRenew=Y, we could
try to re-bill the user.

Also, a service that cancelled the subscription, "cancelSubscription"
with a timestamp argument to update the Subscription.thruDate
This service would set autoRenew="N" and thruDate="timestamp"
if the timestamp is not present thruDate would be unchanged.

Any thoughts?
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[David E. Jones]

If you had the renewal settings on the Subscription entity it would need all payment, etc settings.

The plan right now is to use the ShoppingList, etc. for this and any other automatic reordering.

-David


Andrew Sykes wrote:

> Hi Folks,
>
> I was thinking that it might be a good idea to add an autoRenew
> attribute to the Subscription entity so that subscriptions could be
> identified as being automatically renewable.
>
> We could then create a service that queried the Subscriptions daily and
> if one will expire in the next 24 hours and has autoRenew=Y, we could
> try to re-bill the user.
>
> Also, a service that cancelled the subscription, "cancelSubscription"
> with a timestamp argument to update the Subscription.thruDate
> This service would set autoRenew="N" and thruDate="timestamp"
> if the timestamp is not present thruDate would be unchanged.
>
> Any thoughts?

[byersa]

Hi Andrew,

I just started working with subscriptions, too. Hopefully, David will
comment if he is not too busy, but in case he doesn't I will tell you
what I know. I was thinking like you, only I thought maybe Subscription
should have a recurrenceInfoId field, as RecurrenceInfo entity already
exists and is set up  to handle this. The place that there is an
instance of recurrenceInfoId is in ShoppingList which is what David told
me could be used to set up recurring Subscriptions.

I have not yet looked around for supporting services and such, but I
would be interested in collaborating with you and anyone else working in
this field to get a good solution. I am guessing that there are existing
services to support ShoppingList use; I will be looking today. The
ProductSubscriptionResource  entity replaces  ProductContent. It is more
flexible.

I started this email before David responded. I will send it anyway so
that you and I and any one else can collaborate, if desired. I am
wondering if there are some admin screen that need to be done?

-Al

Andrew Sykes wrote:

> Hi Folks,
>
> I was thinking that it might be a good idea to add an autoRenew
> attribute to the Subscription entity so that subscriptions could be
> identified as being automatically renewable.
>
> We could then create a service that queried the Subscriptions daily and
> if one will expire in the next 24 hours and has autoRenew=Y, we could
> try to re-bill the user.
>
> Also, a service that cancelled the subscription, "cancelSubscription"
> with a timestamp argument to update the Subscription.thruDate
> This service would set autoRenew="N" and thruDate="timestamp"
> if the timestamp is not present thruDate would be unchanged.
>
> Any thoughts?
>  

[BJ Freeman]

is there a jira for this?

Al Byers sent the following on 6/30/2006 11:13 AM:

> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up  to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource  entity replaces  ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
>> Hi Folks,
>>
>> I was thinking that it might be a good idea to add an autoRenew
>> attribute to the Subscription entity so that subscriptions could be
>> identified as being automatically renewable.
>>
>> We could then create a service that queried the Subscriptions daily and
>> if one will expire in the next 24 hours and has autoRenew=Y, we could
>> try to re-bill the user.
>>
>> Also, a service that cancelled the subscription, "cancelSubscription"
>> with a timestamp argument to update the Subscription.thruDate This
>> service would set autoRenew="N" and thruDate="timestamp"
>> if the timestamp is not present thruDate would be unchanged.
>>
>> Any thoughts?
>>  
>
>

[Andrew Sykes]

Al,

That's an interesting idea (RecurrenceInfo), it seems if we went that
route that there is a bit of overlap between the from/thru dates on
Subscription and the RecurrenceInfo stuff.

Can you see a reason to have both? I probably have to study this a bit
more before I comment further as I haven't thought along these before.

Hans is also working on this stuff so he'll probably have some useful
comments.

Of course, I'd be happy to collaborate on this.

- Andrew


On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:

> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up  to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource  entity replaces  ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
> > Hi Folks,
> >
> > I was thinking that it might be a good idea to add an autoRenew
> > attribute to the Subscription entity so that subscriptions could be
> > identified as being automatically renewable.
> >
> > We could then create a service that queried the Subscriptions daily and
> > if one will expire in the next 24 hours and has autoRenew=Y, we could
> > try to re-bill the user.
> >
> > Also, a service that cancelled the subscription, "cancelSubscription"
> > with a timestamp argument to update the Subscription.thruDate
> > This service would set autoRenew="N" and thruDate="timestamp"
> > if the timestamp is not present thruDate would be unchanged.
> >
> > Any thoughts?
> >  
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Andrew Sykes]

Al, Hans,

How do you think Subscription should be linked to RecurrenceInfo?

There seems to be two options...
new Entity
        SubscriptionRecurrenceInfo

new Attribute
        Subscription.recurrenceInfoId

There seems to be precedent for the second option, what do you think?

- Andrew

On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:

> Hi Andrew,
>
> I just started working with subscriptions, too. Hopefully, David will
> comment if he is not too busy, but in case he doesn't I will tell you
> what I know. I was thinking like you, only I thought maybe Subscription
> should have a recurrenceInfoId field, as RecurrenceInfo entity already
> exists and is set up  to handle this. The place that there is an
> instance of recurrenceInfoId is in ShoppingList which is what David told
> me could be used to set up recurring Subscriptions.
>
> I have not yet looked around for supporting services and such, but I
> would be interested in collaborating with you and anyone else working in
> this field to get a good solution. I am guessing that there are existing
> services to support ShoppingList use; I will be looking today. The
> ProductSubscriptionResource  entity replaces  ProductContent. It is more
> flexible.
>
> I started this email before David responded. I will send it anyway so
> that you and I and any one else can collaborate, if desired. I am
> wondering if there are some admin screen that need to be done?
>
> -Al
>
> Andrew Sykes wrote:
> > Hi Folks,
> >
> > I was thinking that it might be a good idea to add an autoRenew
> > attribute to the Subscription entity so that subscriptions could be
> > identified as being automatically renewable.
> >
> > We could then create a service that queried the Subscriptions daily and
> > if one will expire in the next 24 hours and has autoRenew=Y, we could
> > try to re-bill the user.
> >
> > Also, a service that cancelled the subscription, "cancelSubscription"
> > with a timestamp argument to update the Subscription.thruDate
> > This service would set autoRenew="N" and thruDate="timestamp"
> > if the timestamp is not present thruDate would be unchanged.
> >
> > Any thoughts?
> >  
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[David E Jones-2]

I would highly recommend against both options and instead use the ShoppingList for this.

Adding this stuff to the Subscription would simply result in duplication of the data model and logic that is on the ShoppingList. In this case much more than just the recurrence info is needed to be able to place orders to automatically renew a subscription...

-David


Andrew Sykes wrote:

> Al, Hans,
>
> How do you think Subscription should be linked to RecurrenceInfo?
>
> There seems to be two options...
> new Entity
> SubscriptionRecurrenceInfo
>
> new Attribute
> Subscription.recurrenceInfoId
>
> There seems to be precedent for the second option, what do you think?
>
> - Andrew
>
> On Fri, 2006-06-30 at 12:13 -0600, Al Byers wrote:
>> Hi Andrew,
>>
>> I just started working with subscriptions, too. Hopefully, David will
>> comment if he is not too busy, but in case he doesn't I will tell you
>> what I know. I was thinking like you, only I thought maybe Subscription
>> should have a recurrenceInfoId field, as RecurrenceInfo entity already
>> exists and is set up  to handle this. The place that there is an
>> instance of recurrenceInfoId is in ShoppingList which is what David told
>> me could be used to set up recurring Subscriptions.
>>
>> I have not yet looked around for supporting services and such, but I
>> would be interested in collaborating with you and anyone else working in
>> this field to get a good solution. I am guessing that there are existing
>> services to support ShoppingList use; I will be looking today. The
>> ProductSubscriptionResource  entity replaces  ProductContent. It is more
>> flexible.
>>
>> I started this email before David responded. I will send it anyway so
>> that you and I and any one else can collaborate, if desired. I am
>> wondering if there are some admin screen that need to be done?
>>
>> -Al
>>
>> Andrew Sykes wrote:
>>> Hi Folks,
>>>
>>> I was thinking that it might be a good idea to add an autoRenew
>>> attribute to the Subscription entity so that subscriptions could be
>>> identified as being automatically renewable.
>>>
>>> We could then create a service that queried the Subscriptions daily and
>>> if one will expire in the next 24 hours and has autoRenew=Y, we could
>>> try to re-bill the user.
>>>
>>> Also, a service that cancelled the subscription, "cancelSubscription"
>>> with a timestamp argument to update the Subscription.thruDate
>>> This service would set autoRenew="N" and thruDate="timestamp"
>>> if the timestamp is not present thruDate would be unchanged.
>>>
>>> Any thoughts?
>>>  

[Andrew Sykes]

David, Al, Hans,

This answers my previous question about duplication, thanks.

So we have a ShoppingList, with shoppingListTypeId="SLT_AUTO_REODR"

Should we have a special productTypeId for a Subscription or perhaps use
"SERVICE" or something similar...

When a product of a certain type is purchased, a SECA to create a
Subscription entity?

Also, the item should be added to the ShoppingList, with a
recurrenceInfoId etc...

Where do we get the data to populate the RecurrenceInfo? Should products
have an attachment to RecurrenceRule ???

Hopefully someone has some more thoughts on this...
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[David E Jones-2]

I'm actually working on implementing some of this stuff right now for a client, so watch for some commits related to it over the next couple of days.

-David


Andrew Sykes wrote:

> David, Al, Hans,
>
> This answers my previous question about duplication, thanks.
>
> So we have a ShoppingList, with shoppingListTypeId="SLT_AUTO_REODR"
>
> Should we have a special productTypeId for a Subscription or perhaps use
> "SERVICE" or something similar...
>
> When a product of a certain type is purchased, a SECA to create a
> Subscription entity?
>
> Also, the item should be added to the ShoppingList, with a
> recurrenceInfoId etc...
>
> Where do we get the data to populate the RecurrenceInfo? Should products
> have an attachment to RecurrenceRule ???
>
> Hopefully someone has some more thoughts on this...