Information being cleared when Downloading

DSYork · March 03, 2015, 08:56:33 AM

Hello Everyone,

Our office just started doing commercial lines downloading last month. Prior to downloading the CSRs in our office would always put if the client had Blanket Additional Insured on the GL App under Add'l Interest. The reason we put it there is so the person that does all of the certificates in our office knew where to look to see if the insured has it. Now with doing the download this information is wiped out.

I was wondering what other agencies are doing with this information so their certificate person knows where to look? Any feedback would be appreciated. Thank you so much for your help.

Darrah

Jim Jensen · March 03, 2015, 09:50:38 AM

Hi Darrah, complaints about fields being overwritten or cleared is a common issue with claims download. Does the carrier send the endorsement number that include the Blanket Additional Insured (if required by contract) option? If they do, then I would see about training to look for the endorsement(s) that apply.

Some there ideas as well as other CL download issues are in this thread: http://appliedusers.ca/forums/index.php/topic,242.15.html

DSYork · March 03, 2015, 10:23:04 AM

Thanks Jim,

Yes the codes come through so maybe that is one solution. So if I click off the AP Screen than for an auto policy or an umbrella policy a PCKG will no longer appear?

Jim Jensen · March 03, 2015, 11:06:21 AM

Quote from: DSYork on March 03, 2015, 10:23:04 AM
Thanks Jim,

Yes the codes come through so maybe that is one solution. So if I click off the AP Screen than for an auto policy or an umbrella policy a PCKG will no longer appear?

It shouldn't. I occasionally get a random one from one of our carriers on the auto policy, but mostly quit getting them by doing so.

Sherry Burrell · March 03, 2015, 11:55:53 AM

Our CSRs set up the Master cert and include in the title of the cert that Blanket AI or WOS applies. Then the person processing the cert knows to include the endt when issuing the cert if it applies. We attach the blanket endt forms separately in our attachment list.

Charlie Charbonneau · March 03, 2015, 12:52:40 PM

Our CL team flat refuses to allow CL download due to overwrites from Companies. I can see it and I can't. Part of me thinks the CL team learning to use fields as they should be properly used would be great. But then we test a download with a company and legit fields that are filled properly in the app are wiped clean by the download because for some reason the Company doesn't have or want the data so they send blank fields.

Jan Regnier · March 03, 2015, 01:05:53 PM

Quote from: Charlie Charbonneau on March 03, 2015, 12:52:40 PM
Our CL team flat refuses to allow CL download due to overwrites from Companies. I can see it and I can't. Part of me thinks the CL team learning to use fields as they should be properly used would be great. But then we test a download with a company and legit fields that are filled properly in the app are wiped clean by the download because for some reason the Company doesn't have or want the data so they send blank fields.

Ditto here....no CL download. If the company doesn't have the same info as your app, download wipes out the fields where you have info and they don't.

I don't understand what companies don't get about the fact we have info in our apps WE Need or want. Is it really that difficult to have JUST the info that was changed downloaded and leave the rest of the app alone?

Jeff Zylstra · March 03, 2015, 01:40:54 PM

Quote from: Jan Regnier on March 03, 2015, 01:05:53 PM
Quote from: Charlie Charbonneau on March 03, 2015, 12:52:40 PM
Our CL team flat refuses to allow CL download due to overwrites from Companies. I can see it and I can't. Part of me thinks the CL team learning to use fields as they should be properly used would be great. But then we test a download with a company and legit fields that are filled properly in the app are wiped clean by the download because for some reason the Company doesn't have or want the data so they send blank fields.

Ditto here....no CL download. If the company doesn't have the same info as your app, download wipes out the fields where you have info and they don't.

I don't understand what companies don't get about the fact we have info in our apps WE Need or want. Is it really that difficult to have JUST the info that was changed downloaded and leave the rest of the app alone?

It seems to me that there used to be a way to preserve this information by putting a carat "^" or other special character as the first character of the data. Is that not true? Jim or someone else, please feel free to chime in because I'm way out of my element here.

Jan Regnier · March 03, 2015, 01:45:58 PM

Quote from: Jeff Zylstra on March 03, 2015, 01:40:54 PM
Quote from: Jan Regnier on March 03, 2015, 01:05:53 PM
Quote from: Charlie Charbonneau on March 03, 2015, 12:52:40 PM
Our CL team flat refuses to allow CL download due to overwrites from Companies. I can see it and I can't. Part of me thinks the CL team learning to use fields as they should be properly used would be great. But then we test a download with a company and legit fields that are filled properly in the app are wiped clean by the download because for some reason the Company doesn't have or want the data so they send blank fields.

Jeff, I think there is/was a way the companies could do it by putting some character in the fields on their side that would not blank out the fields when downloaded into the agency application and I think some companies were/are doing that but most are not.

Ditto here....no CL download. If the company doesn't have the same info as your app, download wipes out the fields where you have info and they don't.

I don't understand what companies don't get about the fact we have info in our apps WE Need or want. Is it really that difficult to have JUST the info that was changed downloaded and leave the rest of the app alone?

It seems to me that there used to be a way to preserve this information by putting a carat "^" or other special character as the first character of the data. Is that not true? Jim or someone else, please feel free to chime in because I'm way out of my element here.

Jeff Zylstra · March 03, 2015, 01:52:00 PM

Quote from: Jan Regnier on March 03, 2015, 01:45:58 PM
Quote from: Jeff Zylstra on March 03, 2015, 01:40:54 PM
Quote from: Jan Regnier on March 03, 2015, 01:05:53 PM
Quote from: Charlie Charbonneau on March 03, 2015, 12:52:40 PM
Our CL team flat refuses to allow CL download due to overwrites from Companies. I can see it and I can't. Part of me thinks the CL team learning to use fields as they should be properly used would be great. But then we test a download with a company and legit fields that are filled properly in the app are wiped clean by the download because for some reason the Company doesn't have or want the data so they send blank fields.

Jeff, I think there is/was a way the companies could do it by putting some character in the fields on their side that would not blank out the fields when downloaded into the agency application and I think some companies were/are doing that but most are not.

Ditto here....no CL download. If the company doesn't have the same info as your app, download wipes out the fields where you have info and they don't.

I don't understand what companies don't get about the fact we have info in our apps WE Need or want. Is it really that difficult to have JUST the info that was changed downloaded and leave the rest of the app alone?

It seems to me that there used to be a way to preserve this information by putting a carat "^" or other special character as the first character of the data. Is that not true? Jim or someone else, please feel free to chime in because I'm way out of my element here.

If I remember correctly, the "carat" came from when you uploaded the policy to them, or maybe interfaced the policy on their system. Can't remember if both methods work or not.

Our issue is that any Commercial Auto downloads would screw up the "unit numbers" so that they would no long match. Many bigger fleets like to use their unit numbers when referring to their vehicles, and it was nice when you could match unit #1 with driver #1, etc.... It make keeping accidents and incidents easier for us and the insured. I wish they'd fix that or give some kind of an "indexing" method to keep all that information together.

Jim Jensen · March 03, 2015, 02:12:21 PM

I am not aware of anything that you can do on the agency end to retain info in a field that a carrier chooses to send either data or null bytes to. Preceding text with a "^" will do nothing. It all has to do with what the carrier sends in each data field. Some are standardized to send 'something' to each data field they may use. Additional Insured would be a good example. On some policies they will send some data to those fields if they have additional insureds. If they don't they have to send a blank. Some policy systems are not flexible enough to skip a field if it has no content.

However, it works both ways. Let's say you have an additional insured on the GL policy. Now you delete the additional insured. If they send a space or blank field, then it will clear the AI you had, which is good. If they skip the field because it is now empty, your AI will remain in the app in TAM, which is not good. We experience this accidents/tickets in the personal auto. If they had an accident 8 years ago and it rolled out of experience, it doesn't always get cleared, because of this issue of what to send.

I have more specific info about talking to carriers about 'null bytes' when not using certain fields and such in the thread I linked to in the upload/download area. Keep in mind too that carrier differ on which data fields they have in their policy systems. It is best to use your fields based on the broadest data set that can be sent to you to prevent data deletions that isn't consistent.

Jan, if you haven't tried download for a long time, try again. Carriers and IVANs are trying to make it work and trying to improve it. You can often choose which lines you want to get if you have issues with some. Naturally the GL and Property are the toughest, along with IM. I hear few complaints about WC, Umbrella and Commercial Auto. Those apps and policies are much more standardized between carriers, which makes download work better.

DebAmstutz · March 03, 2015, 02:59:19 PM

We use commercial download except for a few more complicated policies on a few clients. What I asked the CSRs to do was add the letters DNA to the end of the policy number so the downloads go into suspense. Then I send those downloads to history so we have the info on the apps to satisfy the CSRs plus we have what the company actually downloaded in history. That has worked pretty well for us.

Sherry Burrell · March 03, 2015, 03:56:42 PM

One nice feature of Epic is that you can check an individual policy to "Turn off policy download" . Everything else from that carrier will download, just not the policies with this check.

Jim Jensen · March 03, 2015, 04:14:14 PM

Quote from: Sherry Burrell on March 03, 2015, 03:56:42 PM
One nice feature of Epic is that you can check an individual policy to "Turn off policy download" . Everything else from that carrier will download, just not the policies with this check.

Tam 2014 R2 has this now, too.

Jeff Zylstra · March 04, 2015, 11:21:56 AM

Quote from: Jim Jensen on March 03, 2015, 02:12:21 PM
I am not aware of anything that you can do on the agency end to retain info in a field that a carrier chooses to send either data or null bytes to. Preceding text with a "^" will do nothing. It all has to do with what the carrier sends in each data field. Some are standardized to send 'something' to each data field they may use. Additional Insured would be a good example. On some policies they will send some data to those fields if they have additional insureds. If they don't they have to send a blank. Some policy systems are not flexible enough to skip a field if it has no content.

However, it works both ways. Let's say you have an additional insured on the GL policy. Now you delete the additional insured. If they send a space or blank field, then it will clear the AI you had, which is good. If they skip the field because it is now empty, your AI will remain in the app in TAM, which is not good. We experience this accidents/tickets in the personal auto. If they had an accident 8 years ago and it rolled out of experience, it doesn't always get cleared, because of this issue of what to send.

I have more specific info about talking to carriers about 'null bytes' when not using certain fields and such in the thread I linked to in the upload/download area. Keep in mind too that carrier differ on which data fields they have in their policy systems. It is best to use your fields based on the broadest data set that can be sent to you to prevent data deletions that isn't consistent.

Jan, if you haven't tried download for a long time, try again. Carriers and IVANs are trying to make it work and trying to improve it. You can often choose which lines you want to get if you have issues with some. Naturally the GL and Property are the toughest, along with IM. I hear few complaints about WC, Umbrella and Commercial Auto. Those apps and policies are much more standardized between carriers, which makes download work better.

I spoke to someone in Applied Download department yesterday about an unrelated subject and asked him about this subject. He was pretty funny and tactfully told me that this hasn't been around for "years" now. In short, I'm officially a "TAM geezer". He said that he heard it had existed "well over 10 years ago" and could have even been "TAM lore".

Anyways, he DID say that the latest version of TAM 2014 R2, gave you the option of not downloading to individual policies you did not want updated. He seemed to think the "check box" was on the billing screen, but could be on the ACORD application as well. We're not on R2, so I can't tell you.