End of the Road

[Steven Strauss]

We've run into an interesting problem on which I'd appreciate a bit of guidance from the collective:

We have added our 99th policy on a particular account, but need to add #s 100, 101 and 102 as well. The problem is that TAM does not permit more than 99 policies to be attached to any particular account. As you can imagine, the account is VERY old and very complex. This leads to the questions:

1) If we decide to delete policies that have not been active in some years, is there any way to preserve history?
2) Is there another way around this other than deletign policies, short of adding another ID for this client, which creates its own set of problems?

As always, everyone's input is greatly appreciated.

[DebAmstutz]

Has nobody been saving policies/changes/etc. to history?  It would all be there if they have, and there is no real problem (in my opinion) in overwriting a billing screen of the same policy type with a more current policy, as long as the history has been saved.

[Ian Blundell]

The only time we have come close was with an account that had lots of bonds.  What we did was break it out into 2 customers,  one for just the bonds and the "main" customer for everything else.

[Steven Strauss]

Deb, does history have any direct relation to the policy# in the billing screen where there is a direct 1:1 relationship or are they maintained in a mutually exclusive way such that if changed the policy# of the new item (1001, for example) will then overwrite the history of the item it replaced in the billing screen?

Ian, that is indeed the case. At least 60 of the 99 policies are bonds, many of which are very old. Is there a way to move these old items to another ID with their associated histories?

[Bob]

Could you do as Ian says make a second client for the bonds, then use utilities to move the policies to the second client?

[Jeff Zylstra]

Deb, does history have any direct relation to the policy# in the billing screen where there is a direct 1:1 relationship or are they maintained in a mutually exclusive way such that if changed the policy# of the new item (1001, for example) will then overwrite the history of the item it replaced in the billing screen?

Ian, that is indeed the case. At least 60 of the 99 policies are bonds, many of which are very old. Is there a way to move these old items to another ID with their associated histories?

I agree with Ian's solution. Yes, you can move just certain policies (bonds) to prospect, create a new customer number, and then move those policies from prospect to the new customer number.  That should bring the history over with it.  Just be careful what options you specify. 

[Jan Regnier]

We do the same for several customers that have lots of bonds.  We set up a 2nd customer to accommodate just the bond files.

[Lance Bateman]

Saving to history is your solution, I think.  If there is an app attached to the billing screen, when you start changing the app (such as for endorsements), you get a request to "save to history".  Do that, and the info from the app BEFORE you made the change along with the billing screen info will be saved to history.  If no app attached, the same process will happen when you make any change to the billing screen.

For renewals, or rewrites, be sure to change the app (or do it from future apps) first, and change the billing screen AFTER the save to history is done.

I agree as someone mentioned below - don't re-use the billing screen for a different policy type.  But as most bonds are only billed for a three year period it seems, I could re-use them after the billed term.  What is saved to history is still accessible for invoicing, claims, change requests.

Our standard - once a policy has been out of force for two years, if not replaced/rewritten - we do a last "save to history" and then delete the billing screen.

[Billy Welsh]

Deb, does history have any direct relation to the policy# in the billing screen where there is a direct 1:1 relationship or are they maintained in a mutually exclusive way such that if changed the policy# of the new item (1001, for example) will then overwrite the history of the item it replaced in the billing screen?

Ian, that is indeed the case. At least 60 of the 99 policies are bonds, many of which are very old. Is there a way to move these old items to another ID with their associated histories?

We pick one of the "very old" policies (one that we know will not have future activity), copy to history, then re-use that risk number & billing screen.  We have the old policy number, exp date, and application if applicable in history, and if we are wrong and a transaction is required we can even transact from history.  The only real issues we've run into are:

A) when you are looking at the transaction history for that one policy you are in reality looking at it for 2 distinct policies so you have to use dates on the transaction filter; and

B) if for some odd reason you need to reprint an invoice for the expired policy it will pull the policy data from the current billing screen.  A quick trip through Acrobat after printing it to a PDF fixes that.

[Jim Jensen]

We do probate bonds fro some attorneys and many get accumulated under the attorney's file (they end up as the executor every now and then). Since the bonds are long closed and dormant, we simply move them to history and clearly mark the history description (e.g. Estate of Henry Bender, bond closed 3/1/99), then delete the current app and info. We will reuse the billing screen when needed then. I feel that there is little issue since the time between original and re-use is considerable and the history description and the app in histoty (a custom dec) are clearly marked. Bond numbers also help distinguish the different ones on the same TAM policy number as well.

[GeorgeW]

If you reuse the billing screens, when viewing attachments for just that policy will have the attachments for both the old and the new policy.  Not that big a deal!

[Steven Strauss]

Ended up creating setting up a new client ID and moving all the Bonds over to it. In speaking with Applied support, discovered some functionality that permits almost a parent/child relationship between two such IDs that permit a very simple transfer of policies from one to the other, while history and attachments stay resident in the old ID.

Thank you everyone for your input; I'm not sure that we could have reached this positive conclusion this quickly without a list of options to walk though with AS.