Upgrade and downgrade customers subscription

Question

I have been stuck at a requirement for way too long too handle it :(.

Our company is having increased number of customers who wants to upgrade or downgrade their subscription. For now, the subscription-customer relation is at follows:

Every Customer has its own Combo, like the following:

Every Combo is bind to several packages:

When a customer wanted to upgrade his combo, the IT department had to add manually the upgrading package with the start and end date specifications. Since this was a rare request at a time, nothing has been thought for an automatic solution to it. Now, in Upgrade, I have managed to add another Package which has the missing products. The problem is on Downgrade. My initial thought was to edit the enddate field of the package that has to be cancelled, in order that the application would not read it no more. But, maybe is not a good idea to overwrite the existing data, because in the future, it will be impossible to understand if the enddate field was changed by mistake or on purpose. Since tha application delivers the product via the package, reading its enddate, how can i manage to cancel the required package without overwritting it?

EDIT:

If the customer needs to renew the services, there are two steps taken:

1. In the first image is added a new row with the combo and saledate specification
2. In the second image,
   a. if the new combo is equal to the old one, it changes the end-date for each package according to the duration
   b. if the new combo is different from the old one, in that case, or the new packages are added, and the old ones do not change (This is the case when the new and old combo have no packages in common), or
   c. the packages are edited as mentioned in point a) except one package, which is not included in the new combo . This is the case when only one package does not renew its end-date ( This is the case eligible for an upgrade)

Or should I go on with the "Edit Field" idea?

UPDATE: As one of the possible solutions, I was thinking about adding a database field, which would activate or deactivate one or more package. Meanwhile, I have created a table which saves the pair of combos and the packages that differs them. I don't know if this is a good approach, in order to keep track of everything that happens in the user's experience

Answer 1

As you are already updating the enddate field selectively for a renewal, it should not be a problem to also update the enddate field in case of a downgrade.

To be able to answer customer questions/complaints after a downgrade, there are several possibilities.
One of the easiest would be to add a column cancellation to the table with packages, recording the date that the package was cancelled.
Another mechanism, that gives you full details when something was changed, is to setup an audit system for those tables. This may even already exist, but if it doesn't, an audit system in its simplest form is a table that you automatically add a row to when something gets changed in another table to record what got changed and when. The only changes made to an audit table are inserts.

---

If, as indicated, there are organizational issues with updating the end date for a downgrade, the easiest solution is to add a 'cancellation' column with the cancellation date and to update the logic that checks if a package is purchased by a customer to take the cancellation column into account as well.

Answer 2

It sounds like you running into issues where you coded past an indirection step in the hopes it would be constant.

From your limited description, you have:

• A discrete number of possible combinations
• One or zero combinations are active at any given time.
• In ordering a combo, a customer specifies a nominal end date.

So you have a a list of combinations, customers with an order history where each history includes an activation date, the ordered combo, and a nominal end date. The latest order history is what the customer has. You then derive a new table of customer id and active services to service the delivery.

My guess is you have more complications you are not sharing, or simply so much code trying to second guess the indirection that you cannot fix it.