calculating offer period for subscription

Question

I'm maintaining a web application which deals with some kind of subscriptions. Users can to renew their subscriptions from 2 months before expiry (not earlier than that). Sometimes user does not renew before expiry and get grace period which is of 3 months. Now he can renew in these 3 months of grace period.

Now the problem part. In the previous transactions of renew requests I have to show what was the offer period for that particular request (subscription start and subscription end period if renew was granted). Things are pretty simple if user renews before expiry, but I'm not able to get things straight if there is grace period specially when the subscriptions is expiring in last months of the year. Also there sometimes calculations go haywire when subscription is ending in jan or feb.

All this is happening because offer period is not saved with the application anywhere (I don't know why). so if subscription is ending in 20 October 2008 and renew application is submitted in 16 January 2009 (because of grace period) the offer period should be 21 October 2008 to 20 October 2009.

How can I calculate correct offer period based on renew request submission date for old renew applications?

EDIT:- Now is 2010, suppose user is viewing past transaction from year 2009, when he submitted request to extend subscription from 21-10-2008 to 20-10-2009. But he has got grace period and requested renew on 16-Jan-2010. As I don't have 21-10-2008 to 20-10-2009 stored anywhere I have to calculate that it was 21-10-2008 to 20-10-2009 when the request was logged. And this is where I'm having trouble.

Answer 1

@TheVillageIdiot,

(A)> Now is 2010,
So far so good . . .

(B)> suppose user is viewing past transaction from year 2009,
Yup, I’m with you . . .

(C)> when he submitted request to extend subscription from 21-10-2008 to 20-10-2009.
So you can see somewhere in the database or in a log file that the subscription was from 21-10-2008 to 20-10-2009, right?

(D)>But he has got grace period and requested renew on 16-Jan-2010.
Ok. But this transaction date (16-01-2010) should not matter for the actual begin and end of the subscription. It is part of a constraint on when a “renew” can occur. (The other part of the constraint is the 2 months prior to expiry that you mentioned before.) Therefore you should never need to consider when a person renewed to know what the subscription begin and end dates are.

(E)>As I don't have 21-10-2008 to 20-10-2009 stored anywhere
Wait, then how in (C) do you know the subscription was from 10/08 to 10/09????

(F)> I have to calculate that it was 21-10-2008 to 20-10-2009 when the request was logged. And this is where I'm having trouble.
Yeah, unless you have it stored somewhere; I don’t see how you would know it was from 21-10-2008 to 20-10-2009 or 25-10-2008 to 24-10-2009 or 21-10-1908 to 20-10-1909.

I really think above in part (C) you must have the subscription begin and end dates around somewhere and as I commented in (D) you should be able to ignore when the actual renew request transaction was made in order to calculate the beginning of the next term.

---

Ok, now, I am going to assume that you truly do not have the subscription begin and end dates for past subscriptions stored somewhere. (Which I find really hard to believe.)

Here is a possible answer to your question:

You do have the customer’s current expiration date (otherwise you would not know when to begin the prior two month renew window or the three month grace window). So, given this current subscription expiration date you could work backwards on a year by year basis. In this way, you would be able to reconstruct all the customer’s past subscriptions.

However, there is a problem with this, if the customer failed to renew during the grace period then a new subscription probably began with a gap in time from the one prior.
Anyway, double check to ensure that there is no possible way to determine the subscription begin and end date. I think you will find them somewhere and should be able to get them into your database.

Good Luck.