2

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:

Combo

Every Combo is bind to several packages:

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

Community
  • 1
Ange1
  • 23
  • 6
  • 2
    How do you deal with renewal of a combo, if the end date comes near and the customer wants to keep on using your services? Would that change the end-date of the original, or create a new sale? – Bart van Ingen Schenau Sep 26 '15 at 13:32
  • @BartvanIngenSchenau I have edited my question to explain better – Ange1 Sep 28 '15 at 07:18

2 Answers2

0

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.

Charles Merriam
  • 419
  • 3
  • 5
  • the code in this case was already implemented, I have to improve it, because as I have mentioned earlier, the Upgrades or downgrades were made in a manual way, that left no trace of the actions, and so, the financial department was having issues to identify if one sale was Upgraded, or someone has been stealing the services from the company. The code, unfortunately is very rigid, and is very hard to optimize it in the short time I have to resolve the issue – Ange1 Sep 28 '15 at 07:25
  • Right, "so much code trying to second guess the indirection that you cannot fix it". In your own coding diary, try to keep track of your estimate about doing it "right" versus the time you spend patching around. It may be illuminating. – Charles Merriam Sep 28 '15 at 19:06
0

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • The problem over here is that the administrator of the portal does not approve nothing that would include overwriting the actual end-date, except in a renewal of the product. However, I am thinking about some changes that would probably help me solve the problem. See the Update section for more info – Ange1 Sep 28 '15 at 09:44
  • In this case, do you think that a variable which indicates if the product is activated or not is enough? In this case, the only change i have to make in the code side, is to avoid reading the packages that are not active for the client. And at the same time, to add a row in the audit table (we already have one) that sets the date of the cancellation, and into the combo window, add a combo that specifies in which date the customer downgraded. – Ange1 Sep 28 '15 at 11:01
  • @Ange1: Yes. Most likely, you already have such a variable, which gets set to "not activated" if the subscription to a package has expired. You could just mark the package as expired if the current date is after either the end-date or the cancellation-date (with an empty date meaning "some point in the far future"). – Bart van Ingen Schenau Sep 28 '15 at 11:49
  • For now, this variable does not exist, all the control is done from the end-date value. Nice hint the one of the check for either the cancellation date or the end-date. – Ange1 Sep 28 '15 at 11:51