It sounds like we were taking a similar approach. My Insurance Certificates
table had 86 fields, one field for each parameter for each policy. If a new
type of policy were to come on the scene, widespread changes would be
required throughout the application. The cognoscenti refer to this as the
spreadsheet approach or "committing Excel" (as committing a crime or
suicide). I get the impression that the spreadsheet approach is both harder
to operate and harder to revise, although I am not sure which of the two
criteria is most dreaded. My intuition is that it takes more effort to build
flexibility into any product, and there are usually performance tradeoffs
too, as complexity increases. On the other hand, the folks on this forum
have been at this a long time, and I'm sure their views are very well founded.

Thanks,
oldblindpew


"Underwriting" wrote:

Pew,

We have one Policies record for each insured. It contains fields for the
policies we provide (GL, Work Comp, Property, auto, etc.); carrier, policy
number, limits, policy dates, etc.

The messier bits of information, such as additional insured wording, special
certificate wording, etc. is entered in the actual Certificate table. This
info is either pulled automatically from the Certificate Holder's client
record, or it can be entered manually for unusual circumstances.

Our application was created in-house. We have been using/improving it since
1998.

We keep 'insurance required' data (specific additional insured wording,
minimum coverage requirements, etc.) with the Certificate Holder record. The
'insurance provided' info is what we input in the Policies table for that
particular insured.

"oldblindpew" wrote:

Thanks for chiming in.

You said you have "a child table called Policies". A table is a place for
records that share a common set of fields. How do you handle the fact that
different types of policies have different sets of descriptive fields? Do
you 1) perhaps have separate child tables for GL, Auto, Excess, and Worker's
Comp Policies? Or, 2) perhaps have one table for common policy information,
and another table or tables for the messier bits of information? Or 3) maybe
your Policies table is extremely wide and has fields for almost every bit of
information on the Acord form?

This last case is what I started out doing, and in fact had actually built
the tables and forms for both the Insurance Required and Insurance Provided.
I was exploring how to go about checking provided coverage for compliance
with required coverage when I learned that my approach was not recommended.

Is your application something homemade, or is it a commercial product or a
trade association project?

Thanks,
Pew

"Underwriting" wrote:

Let me preface by saying this thread is way, way, over my head. :-)

But I want to let you know how we issue our certificates of insurance. We
are a special events firm insuring concerts, fairs, sporting events, etc.

We have one table called Clients which contains both our insureds and the
companies we may be issuing certificates to (certificate holders). Each
record has a class field. So our insured would be classified as Customer. The
certificate holder would be classified as Venue, etc.

We then have a child table called Policies. This contains all of the policy
info for a particular insured; carrier, policy number, limits, etc. This
table is updated manually as policies are renewed.

Finally we have a table called Certificates. When our insured requests a
certificate, we create a record in this table which pulls in insured
name/address info from Clients, venue info and additional insured wording
from Clients, and policy info from the Policies table. We then complete it
with any special wording (more additional insureds, any special conditions,
etc.) the certificate holder may require.