Question about best way to group together contact mechs

[Jacopo Cappellato-3]

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

[David E. Jones-2]

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
>

[Jacopo Cappellato-4]

Thank you David.
We could replace ContactMechLink with ContactMechAssoc/
ContactMechAssocType and add a few types like "RELATED_TO" and  
"ALTERNATE_OF" (or similar).
In this way we could setup something like:

FirstPostalAddress -RELATED_TO-> FirstPhoneNumber
   ^
   |
ALTERNATE_OF
   |
  SecondPostalAddress  -RELATED_TO-> SecondPhoneNumber
...

Is it a good idea?

Jacopo

On Oct 11, 2009, at 8:14 PM, David E Jones wrote:

>
> 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
>>
>