Skip to main content
added 314 characters in body
Source Link

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.

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.

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.

Source Link

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.