What are you doing about the extra data that is inserted into a session?

I have notice extra coverage nodes getting inserted into the session. These nodes are not part of the policy. These nodes get inserted during the interview/rating process. How can I report on all the coverages of a policy, when I'm getting these erroneous coverage nodes inserted into the session? Since these nodes are in the session, they are getting shredded to the database. How has anybody handled this?

DCT put in an indicator field in the coverage table that has helped a little, but I still have to look at other things(like premium) to get what is actually on the policy (there are coverages we don't even offer that are in the coverage table). You also have to follow the exact XML path to get to that table. Since many of those extraneous coverages won't have the proper _pk keys populated that you need to link on. You'll probably find similar problems in the deductible and limit table. I have made a mapping table that has only coverages that we offer, and the includes the [type] = 'xxx' that you will need to get the limits and deductibles on the policy.

Jim

Jim Farbolin wrote:DCT put in an indicator field in the coverage table that has helped a little, but I still have to look at other things(like premium) to get what is actually on the policy (there are coverages we don't even offer that are in the coverage table). You also have to follow the exact XML path to get to that table. Since many of those extraneous coverages won't have the proper _pk keys populated that you need to link on. You'll probably find similar problems in the deductible and limit table. I have made a mapping table that has only coverages that we offer, and the includes the [type] = 'xxx' that you will need to get the limits and deductibles on the policy.

Jim

Jim, Thanks for replying. That is exactly what I was thinking. We plan on checking the Indicator (which I have seen not being set), the deleteIndicator and premium. However, I still feel we are going to be missing coverages that generate no premium (free coverages), which the indicator has not been set. I guess it comes down to making sure the indicator get's set. I was thinking of writing a custom shredding process to only shred coverages and etc that have the criteria that you have describe. At least I think I'm on the right track.

I'm looking at the ShredDB as just a staging database. It isn't quite an OLTP database, and useless for reporting. I'm concentrating on just getting the stuff that is actually on the policy and then putting it where it naturally belongs so I can report off of it. The toughest part is determining what is actually on the policy, and to do that you have to map out the XML path that the data took to get there. For example, to get the limit that was used on a policy you have to see if the iValue <> '999' where type = 'LineDefaultLiability', then the iValue is your limit, if the iValue = '-999' where type = 'LineDefaultLiability' then the sValue where type = 'LineDefaultLiability3' is your limit. And the rules are different for getting the UM Limits! The only way to know that stuff is by following the XML path given in ExampleAuthor. My mapping tables are what will do the reshredding for me. I am curious as to what others solutions are.

Jim