I have requirement where ImposedTerm name needs to be date managed.Could this be done via product designer?

Question

My imposed term name should be ABC before July 1 and from July 1 it should be XYZ. Is that possible via product designer, if not how it can be done through another possibility ?

I'm thinking another imposed term can be created with the new name and different availability dates but I'm assuming system will confuse as we will be having 2 imposed terms with the same code but with different name and availability dates?

Can someone provide their thoughts on how to implement it ?

Answer 1

Assuming that you are referring to a product model condition by "imposed term", it is much safer to define 2 different conditions in your scenario. If you intend to make any product model pattern (coverage /exclusion/ condition etc.) available by use of the StartEffectiveDate and EndEffectiveDate columns in the availability lookup table and have a continuous overlap with another pattern that becomes available after the first one becomes unavailable, it's recommended to define 2 separate patterns.

Condition ABC -> StartEffectiveDate = 1st Jan, EndEffectiveDate = 30 Jun
Condition XYZ -> StartEffectiveDate = 1st Jul, EndEffectiveDate = XXX

Using the above values in the availability lookup table, Condition XYZ can be made available starting 1st Jul for any jobs that have a reference date on or after 1st Jul (reference date could either be the effective date or edit effective date and there is a whole plugin just to calculate reference date). In this case, each defined condition will have a unique CodeIdentifier. It is not possible for 2 product model patterns to have the same CodeIdentifier as inquired in the question.

If you intend to change the name of a coverage or condition mid-term, that is neither technically possible nor legally advisable. The ideal way is to initiate a mid-term policy change that will automatically remove the first coverage and add the second coverage when the policy change job is quoted (based on their availabilities). However, I do not think any insurance company would attempt to do that, and a much cleaner way to replace older coverages with newer ones would be to do bulk policy changes as policies quoted on 30th Jun in the above example will continue to offer that coverage until their expiry. Another way would be to stop offering the older coverage to new submissions after a certain date and let older policies get rid of it at renewal.

Answer 2

I have seen customers construct a "coverage display name" utility to add to or change the clause name for display purposes. You could do something like this to meet your need and retain a single clause (and clause code).

But this is a complex piece of coding since you have to consider performance overhead as well as intercept every location where a clause display name may occur including downstream mappings like document production.

Other than that the "2 clause" approach is the only viable solution given the constraints of product model elements.