Hello,

I am sure this is an issue many have dealt with.
I have a client with a relational system in 6 that will be re-writing in 8.
Their biggest complaint in 6 is the clunkiness of creating Orgs and related
Offices
and then assigning an instance of a Contact belonging to the Office.

As always the biggest problem is ensuring that someone does not create a
duplicate
instance of an Org thus ending up with divergent data.

To complicate matters they deal with tons of Associations and Government
Dept's
so a simple search to see if the org arleady exists ususally does not work
since
two employees may know the same org by different names.

My recommendation in the past has been to have one person resposible for
adding Orgs
and Offices and also to perform regular checking for duplicates.
Unfortunately they are not
well disciplined and in the end there ends up being multiple instances of an
org entity with
duplicate instances of associated offices and so on down the line to
dockets. Its always a real
pain to re-normalize.

Just wondering what types of interface solutions you are using to deal with
this type of situation in 8
since there is now so many more choices.

regards,

Pierre Lessard

It seems to me that the client needs to come up with a unique way of
identifying Orgs. If the name doesn't satisfy, because multiple names
may refer to the same Org, then another method is needed. Address?
phone number? How would the person checking for duplicates KNOW that
there was a duplicate org? I think that's where you need to start.
G

An org record record contains just a name. Many then have 50 or more
related offices so
an address or phone number won't work.
Really I am looking for the most elegant interface/process for the best
chance
at catching that the org exists.

thanks.
P.L


"Grip" <grip (AT) cybermesa (DOT) com> wrote

Well, if you just have a name, and people don't use the name
consistently, no amount of elegance or process is going to solve the
problem. You'll have to add something secondary.

If its more a case of one person punching in Dept. of Motor Vehicles,
and the other punching in Department of Motor Vehicles, and still
another punching in DMV, then you simply need to implement a policy for
data entry forbidding abbreviations and acronyms, or require the full
name along with the acronym -

Department of Motor Vehicles (DMV)

So that a search will find either.

Nearly any solution will come to employee discipline, diligence, and
training. You can certainly modify the system to make searches more
convenient.

If you find that you are duplicating the related offices too, then
searching by address or phone number is still a good idea. If a matching
office comes up, then you've got the matching organization for free,
regardless of what its called.

-Dave



In article <pYOif.3605$wf2.308139 (AT) news20 (DOT) bellglobal.com>,
lessardpeter (AT) hotmail (DOT) com says...

Part of the solution depends on the numbers we're talking about. How
many Org total? How many new ones are added per week/month?

Your solution of having one person responsible for adding new Orgs
makes sense if that fits into the time & workflow of your client. Then
by using permissions or by data validation you forbid all other
employees from entering new Orgs.

I like the validation solution (using a value list) personally, and you
can do it by assigning a unique Org ID with a lookup field or most
simply use a drop down list.

G