Insurance Tax increasing
-
Hi, I work in the insurance industry and we are having to go through our code to check for any instances of hard-coding of 5% as the Insurance Tax (IPT) in increasing to 6%. The increase comes in on 4th January 2011 I think. I've noticed in my initial investigations that we have some hard-coding of the 5% calculations, etc, and some of our tables hold 0.05 as the rating factor, etc. The problem is the business is online and as it strikes midnight we would have to cater for the IPT increase. We also need to cater for existing business pre-IPT increase in terms of documentation, quotes, etc to leave the 5% in. Can anybody please recommend what approach they would take to resolve these problems? Thanks in advance
-
Hi, I work in the insurance industry and we are having to go through our code to check for any instances of hard-coding of 5% as the Insurance Tax (IPT) in increasing to 6%. The increase comes in on 4th January 2011 I think. I've noticed in my initial investigations that we have some hard-coding of the 5% calculations, etc, and some of our tables hold 0.05 as the rating factor, etc. The problem is the business is online and as it strikes midnight we would have to cater for the IPT increase. We also need to cater for existing business pre-IPT increase in terms of documentation, quotes, etc to leave the 5% in. Can anybody please recommend what approach they would take to resolve these problems? Thanks in advance
Firstly I would remove all of the hard coding and use a commonly defined variable. I would then look at applying the stretegy pattern so the proper tax rate can be applied at the proper time and under the proper circumstances
I know the language. I've read a book. - _Madmatt
-
Hi, I work in the insurance industry and we are having to go through our code to check for any instances of hard-coding of 5% as the Insurance Tax (IPT) in increasing to 6%. The increase comes in on 4th January 2011 I think. I've noticed in my initial investigations that we have some hard-coding of the 5% calculations, etc, and some of our tables hold 0.05 as the rating factor, etc. The problem is the business is online and as it strikes midnight we would have to cater for the IPT increase. We also need to cater for existing business pre-IPT increase in terms of documentation, quotes, etc to leave the 5% in. Can anybody please recommend what approach they would take to resolve these problems? Thanks in advance
As this is urgent, my advice is to create a static class with the rate defined as a readonly constant, and a static property to define the rate. Point all the hard-coded values at the static class property, then fix your SQL Tables. After you've fixed it everywhere you'll should be OK for midnight. Tomorrow, start refactoring so the rate is set in one place in the database and the static class retrieves it from the rate table. Don't leave the static class as I have described it.
-
As this is urgent, my advice is to create a static class with the rate defined as a readonly constant, and a static property to define the rate. Point all the hard-coded values at the static class property, then fix your SQL Tables. After you've fixed it everywhere you'll should be OK for midnight. Tomorrow, start refactoring so the rate is set in one place in the database and the static class retrieves it from the rate table. Don't leave the static class as I have described it.
I agree with Keith with one extra. Add a field to the rate table defining an effective date for the field and then have the old and new rates both in there. In your static class you only have to write it to pull the correct rate based on the current time and the changeover can happen automagically. I'm not sure if it is an official development term, but we do that sort of thing all the time here with pricing changes, etc. and call it time-coding.
I wasn't, now I am, then I won't be anymore.
-
I agree with Keith with one extra. Add a field to the rate table defining an effective date for the field and then have the old and new rates both in there. In your static class you only have to write it to pull the correct rate based on the current time and the changeover can happen automagically. I'm not sure if it is an official development term, but we do that sort of thing all the time here with pricing changes, etc. and call it time-coding.
I wasn't, now I am, then I won't be anymore.
Thanks for the replies guys, it would be great to have one central table containing the IPT rates and dates effective but this would be extremely difficult to do given there is only 2 developers in the team and the IPT is a rating factor in a few products quote engines. We also need to cater for the pre-IPT increase customers in terms of documentation and also have to re-quote them as their quotes could potentially be incorrect depending on the cover start date.
-
Thanks for the replies guys, it would be great to have one central table containing the IPT rates and dates effective but this would be extremely difficult to do given there is only 2 developers in the team and the IPT is a rating factor in a few products quote engines. We also need to cater for the pre-IPT increase customers in terms of documentation and also have to re-quote them as their quotes could potentially be incorrect depending on the cover start date.
Always fun to get thrown in the fire, isn't it... You may need this in large quantities.
I wasn't, now I am, then I won't be anymore.
-
Thanks for the replies guys, it would be great to have one central table containing the IPT rates and dates effective but this would be extremely difficult to do given there is only 2 developers in the team and the IPT is a rating factor in a few products quote engines. We also need to cater for the pre-IPT increase customers in terms of documentation and also have to re-quote them as their quotes could potentially be incorrect depending on the cover start date.
Danpeking wrote:
Thanks for the replies guys, it would be great to have one central table containing the IPT rates and dates effective but this would be extremely difficult to do given there is only 2 developers in the team and the IPT is a rating factor in a few products quote engines.
Not just great, but proper design, and you wouldn't need to face this problem again. If you don't fix this sort of problem properly, you'll spend increasing amounts of time firefighting, as you are doing now. You are in a triage type situation: 1) Sort the immediate problem 2) contact customer who have need re-quoting, 3) fix the system to handle this kind of change properly, tax rate changes are quite common (normally upwards :-)).
-
Danpeking wrote:
Thanks for the replies guys, it would be great to have one central table containing the IPT rates and dates effective but this would be extremely difficult to do given there is only 2 developers in the team and the IPT is a rating factor in a few products quote engines.
Not just great, but proper design, and you wouldn't need to face this problem again. If you don't fix this sort of problem properly, you'll spend increasing amounts of time firefighting, as you are doing now. You are in a triage type situation: 1) Sort the immediate problem 2) contact customer who have need re-quoting, 3) fix the system to handle this kind of change properly, tax rate changes are quite common (normally upwards :-)).
Yeah, I agree, it's just a case of small businesses and priorities, etc. We'll have one central figure if possible, gonna scope how long it will take, etc. EDIT - We're gonna do it the proper way - static class, bit of work but will be worth it! Thanks for the advice guys!
modified on Thursday, October 28, 2010 6:38 AM