The usual approach so far has been to associate both contact mechs to
the OrderItemShipGroup or whatever. If I understand right what you are
going for is to allow a user to associate them in advance instead of
having to select both on checkout/etc.
I like the ContactMechLink idea a lot better than the Facility idea. I
think you're right that ContactMechLink isn't used, and probably
hasn't ever been updated from the original data model from the Data
Model Resource Book. So yeah, updating and using ContactMechLink would
be my vote.
-David
On Oct 10, 2009, at 4:56 AM, Jacopo Cappellato wrote:
Hi all,
what is the best way to divide into groups the contact mechanisms of
a party.
For example:
a party may have one primary postal address and phone number, plus a
series of alternative postal addresses each with its own phone number.
Using the PartyContactMechPurpose entity we can define the postal
addresses as "SHIPPING_LOCATION" and, for the primary postal address
we can use also the "PRIMARY_LOCATION"; for the phones we can use
the "PHONE_SHIPPING" purpose and for the phone associated to the
primary postal address we could also use the "PRIMARY_PHONE".
The problem is that, with the above setup, there is no way to
specify, for example, that the phone number #3 is associated with
the postal address #3... I would just end up with a set of
alternative phone numbers and an independent set of alternative
postal addresses.
I know that we could define a facility for each alternative address
(and the contact mechs will be associated to it), but for ecommerce
customers this seems a bit too complex.
I have seen the entity ContactMechLink that could be a good way to
link together a postal address with a phone number, but the entity
is not currently used and it seems not based on ofbiz conventions.
Any hints?
Jacopo
