Re: Dev - Party-to-Geo assoc entity?

Posted by David E. Jones on
URL: http://ofbiz.116.s1.nabble.com/Dev-Party-to-Geo-assoc-entity-tp166878p166885.html


A PartyGeoAssoc entity might make sense, but there is something that  
exists that might do what you need: the SegmentGroup and related  
entities.

These are specifically designed for segmenting groups of parties for  
marketing, sales, or any other purpose. They can be flexibly setup to  
constrain the group by various factors including Geos,  
PartyClassificationGroups, and so on. In this way you have a more  
flexible way of setting up your groups and specifying the constraints  
for each group.

You can also "override" the constraints specified on a SegmentGroup  
by associated parties directly with it in a particular role, like  
customer. For employees or others working with the specific groups  
they can also be associated using SegmentGroupRole with a role such  
as sales representative or whatever.

If there is a variation on this that you need, this model is fairly  
new and only in use that I know of in a couple of places, so review  
of it and such would be great.

-David


On Feb 13, 2006, at 4:23 PM, Si Chen wrote:

>
>
> Chris Howe wrote:
>
>> I would think the PartyGroups would be more intuitive
>> than a Party-Geo entity.  The PartyGroups can
>> encompass the functionality your trying to obtain and
>> the Party-Geo would be rather limited to that specific
>> functionality.  If you're looking to assign
>> specifically and not be based on a predefined
>> guesswork, you could accomplish it by assiging a party
>> of the GeoId you're defining and partytype Geo and
>> associate it that way.
>>
>>
>>
> If a partygroup is actually assigned to a geo and you don't provide a
> way to do it and instead ask people to put into the description, that
> actually is a bad thing to do. If we need a field, we should add it.
>
>> I think there's been a lot of leanings toward creating
>> new entities as opposed to new entitytypes in the
>> model that might be compromising normalization and
>> making it a bit more difficult to conceptualize the
>> way entity groups interact.
>>
>>
>>
> I disagree. The fact is there are a lot of new relationships and data
> that need to be tracked.
>
>> --- Si Chen <[hidden email]> wrote:
>>
>>
>>
>>> What if a company had several warehouse addresses
>>> and offices across the
>>> country? Which sales territority does he belong to?
>>> I don't think
>>> there's an automatic match up.
>>>
>>> Then again, maybe a better alternative is that a
>>> "sales territority" is
>>> really a PartyGroup with a PartyGroupRollup. So
>>> maybe it is not
>>> necessary to assign parties directly to it.
>>>
>>> Then again, though, it'd be intuitive still to
>>> associate this party
>>> group with a geo.
>>>
>>> Si
>>>
>>> Chris Howe wrote:
>>>
>>>
>>>
>>>> What limitations are you finding using the current
>>>> data model to group people this way?  ie a
>>>>
>>>>
>>> territory
>>>
>>>
>>>> is a geoId that consists of zip codes, city,
>>>> etc...anyone who has a zip code or city etc as
>>>>
>>>>
>>> their
>>>
>>>
>>>> primary address belongs to that geoId.  Seems to
>>>>
>>>>
>>> break
>>>
>>>
>>>> normalization unless something is limited by the
>>>> current structure.
>>>>
>>>> --- Si Chen <[hidden email]>
>>>>
>>>>
>>> wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>> customers in a territority.
>>>>>
>>>>> Chris Howe wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> What functionality are you thinking of?
>>>>>>
>>>>>> --- Si Chen <[hidden email]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi everybody -
>>>>>>>
>>>>>>> I'm thinking about adding an entity which would
>>>>>>> associate Parties with
>>>>>>> Geos, such that a particular party would be
>>>>>>> associated, with say,
>>>>>>> Florida or Europe.  I doesn't seem like there is
>>>>>>> anything like that
>>>>>>> right now.  How does PartyGeoAssoc with
>>>>>>>
>>>>>>>
>>> partyId*,
>>>
>>>
>>>>>>> geoId*, fromDate*,
>>>>>>> thruDate sound?
>>>>>>>
>>>>>>> Si
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev