IMO, the problem with "mere linkage" is that there'd be so many scattered pieces of data to stitch
together. Data retrieval or traversal will get a little heavy.
Might be better to simply reconcile duplicate Party(s) into one Party, and drop the duplicates
thereafter.
That said, I think the Link function can still work very nicely as an interim measure. Or even as
a permanent measure, if you don't mind having to keep track of scattered pieces of data. One
possible snag is when you perform a "lookup" function, say like "Find all Party(s) with name like
Blah". Your "lookup" function must consider linked Party(s) (aka duplicates), and NOT return those
results.
Jonathon
Dave Tenerowicz wrote:
Yes, that's what we'll be doing.
IP address and visitorId would not be useful, since (in Phase 1) this is
strictly an order taking function via sales reps- so there is no party
specific IP address or visitorId.
Thanks for the suggestions though!
I gather that the Link function would offer no benefit for this, since
no one has mentioned it??
-Dave
David E Jones wrote:
I think most companies do it by comparing things like name, phone
number, address, etc.
Not sure where the IP address idea came from...
-David
Jonathon -- Improov wrote:
What's the usual way to reconcile duplicates in Party(s)? Like if we
have multiple Party(s) for the same person.
Perhaps have an administrator click a button that pools together
suspected duplicate Party(s)? The administrator can then transfer all
related records from one duplicate to another, possibly with audit
trails intact too. Sounds like heavy coding work, though.
I'll need to handle the above, since there is no way I can prevent a
user from creating duplicate Party(s).
Or more strictly prevent duplicates in the first place? Maybe I can
have like a "3-point comparison" function that decides whether the
user is entering duplicate data. I suppose I can dictate that there
can be no duplicates in "name and postal code and mobile phone number
(plus any other super-personal details)".
Jonathon
David E Jones wrote:
The visitorId may be more reliable... at least you know it's the
same browser with that. See the Visitor table and related
functionality.
-David
[EMAIL PROTECTED] wrote:
When IP addresses are typically assigned dynamically, I doubt this
will be
useful. Better to store a back resolved host name if you can get one.
Still not infallible if two users use the same machine.
Skip
-----Original Message-----
From: BJ Freeman [mailto:[EMAIL PROTECTED]
Sent: Monday, September 10, 2007 8:22 PM
To: user@ofbiz.apache.org
Subject: Re: Link Party
An IP of each order is recorded.
you may be able to have a service the links orders by iP address.
this is not infallible but can help.
Dave Tenerowicz sent the following on 9/10/2007 3:03 PM:
Can anyone tell me what the Link Party function under Party
Manager does?
An implementation we are doing includes a significant number of
customer
records that are duplicates. In these cases the same party may have
placed Orders under different partyId's. The client claims that
identification of duplicates can only be done by humans( I doubt
this
!!, but that is another story). What they have requested is that we
develop a service that will assign all records related to one
party to
another partyId. I am wondering if Link Party can be leveraged here.
Thanks for any input
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.15/1002 - Release Date: 9/11/2007 5:46 PM
