ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: Account Data Import:
Date Sat, 17 Jan 2015 22:21:09 GMT
Adrian,

I concur with your model, except aspect 4. That I would model as:

>From Party  = Susan Smith
>From Role = Relation Manager
To Party = Bob Brown
To Role = Contact
partyRelationShipTypeId = Contact Relation

As for the concern regarding anonymous persons being able to order from the
internal companies on behalf of the customer organisation, there should be
checks in place, like sending the sales order to the purchasing officer of
the customer organisation and receiving confirmation before execution of
any sales order.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Jan 17, 2015 at 10:40 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:

> Ruth,
>
> Your approach is interesting, but I am not convinced it is the best way to
> model your client's data. Given a sales rep, a customer organization, and
> purchasing agents buying products on behalf of the customer organization,
> this is the model I would recommend:
>
> Acme Corporation
> ----------------
> Party Type = Internal Organization
>
> Coyote Enterprises
> ------------------
> Party Type = Organization
>
> Susan Smith
> -----------
> Party Type = Person
>
> Bob Brown
> ---------
> Party Type = Person
>
> Party Relationships
> -------------------
>
> 1. From Party = Acme Corporation
>    From Role = Internal Organization
>    To Party = Susan Smith
>    To Role = Sales Rep
>
> 2. From Party = Coyote Enterprises
>    From Role = Organization
>    To Party = Bob Brown
>    To Role = Purchasing Agent
>
> 3. From Party = Acme Corporation
>    From Role = Internal Organization
>    To Party = Coyote Enterprises
>    To Role = Customer
>
> 4. From Party = Susan Smith
>    From Role = Sales Rep
>    To Party = Bob Brown
>    To Role = Customer Agent
>
> Your use case also specifies an anonymous person can make a purchase on
> behalf of the customer organization, and product prices are adjusted
> accordingly. So, in that case you will need:
>
> 5. From Party = Susan Smith
>    From Role = Sales Rep
>    To Party = Coyote Enterprises
>    To Role = Customer
>
> Personally, I try to avoid that type of party relationship because it
> encourages fraud.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/17/2015 9:04 AM, Ruth Hoffman wrote:
>
>> Hi Ron:
>> In the interest of full disclosure, I have no relationship with the
>> author of the data modeling books referenced.
>>
>> IMHO, It is because the data model books have stood the test of time and
>> have not been superseded by anything else, that they should be regarded
>> as the best source for OFBiz data modeling information. I wish some of
>> the past committers had done a better job of implementing the patterns
>> describe therein.
>>
>> Not a project that I work on goes by, where I don't find that a
>> disregard or ignorance for these patterns resulted in project code that
>> cannot be easily adapted to work in my client's environment.
>>
>> That aside, what I'd like to offer here is a real life example of:
>>
>> "The party relationship type is optional, typically the party roles are
>> enough to describe the relationship."
>>
>> Or how to use the partyRelationshipTypeId.
>>
>> Since, email is not the best medium for me to communicate through, I've
>> posted a piece on my newly resurrected blog to describe a real life
>> situation where the use of party relationship types can be optional or
>> very useful.
>>
>> If interested: http://www.aesolves.com/control/blog
>>
>> As time permits, I'll update the blog to allow comments etc. but for
>> now, if you have any questions or comments concerning the content
>> posted, please feel free to contact me directly:
>>
>> rhoffman@aesolves.net
>>
>> Best Regards,
>> Ruth Hoffman
>>
>> On 1/16/15 10:05 PM, Ron Wheeler wrote:
>>
>>> Thanks Adrian.
>>>
>>> Can you elaborate on what this means "The party relationship type is
>>> optional, typically the party roles are enough to describe the
>>> relationship."
>>> Can you explain how the various sales reps and different customers are
>>> going to be connected without a partyRelationship.
>>>
>>> I really appreciate all of the contributions in this area since it is
>>> not documented in the wiki.
>>>
>>> I am a bit skeptical about relying on a book that is 14 years old
>>> since the project is very active.
>>>
>>> Ron
>>>
>>>
>>> On 16/01/2015 6:42 PM, Adrian Crum wrote:
>>>
>>>> The customer is in the role Customer, and Leslie is in the role Sales
>>>> Rep. The party relationship type is optional, typically the party
>>>> roles are enough to describe the relationship.
>>>>
>>>> You could create a custom entity for SIC codes, or use the
>>>> Enumeration entity.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 1/16/2015 1:17 PM, Ron Wheeler wrote:
>>>>
>>>>> She is the "Account Manager" (Salesperson assigned to this Customer).
>>>>>
>>>>> On 16/01/2015 2:57 PM, Adrian Crum wrote:
>>>>>
>>>>>> What is Leslie's role? Why is the customer related to Leslie?
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 1/16/2015 11:42 AM, Ron Wheeler wrote:
>>>>>>
>>>>>>> Does this look like a file that could be imported to produce
2
>>>>>>> customers. Both should be assigned to "LESLIE".
>>>>>>>
>>>>>>> I gather from the partyRelationshipName   that this is the correct
>>>>>>> Type
>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId=""
>>>>>>> partyRelationshipName="Account owned by"
>>>>>>> partyRelationshipTypeId="ACCOUNT" roleTypeIdValidFrom=""
>>>>>>> roleTypeIdValidTo=""/>
>>>>>>> The partyRelationshipTypeId="ACCOUNT"  could be better.
>>>>>>> partyRelationshipTypeId="ACCOUNT_OWNER" would be clearer and
more
>>>>>>> consistent with
>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId=""
>>>>>>> partyRelationshipName="Lead Owned by"
>>>>>>> partyRelationshipTypeId="LEAD_OWNER" roleTypeIdValidFrom=""
>>>>>>> roleTypeIdValidTo=""/>
>>>>>>> and
>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId=""
>>>>>>> partyRelationshipName="Lead Owners/Managers"
>>>>>>> partyRelationshipTypeId="LEAD_OWN_GRP_MEMBER" roleTypeIdValidFrom=""
>>>>>>> roleTypeIdValidTo=""/>
>>>>>>>
>>>>>>>
>>>>>>> They have a SIC code and an SIC description assigned to them
as
>>>>>>> attributes.
>>>>>>> Is there are better way to handle this (Table of SIC entities
and a
>>>>>>> relation to it or does that require code changes)?
>>>>>>>
>>>>>>>
>>>>>>> <entity-engine-xml>
>>>>>>>
>>>>>>> <PartyGroup partyId="FOUR SEASONS HOTEL" groupName="OFBIZ
COMPANY
>>>>>>> NAME"/>
>>>>>>>
>>>>>>> <Party partyId="FOUR SEASONS HOTEL" partyTypeId="PARTY_GROUP"
>>>>>>> externalId="100012"/>
>>>>>>> <PartyRole partyId="FOUR SEASONS HOTEL" roleTypeId="CUSTOMER"/>
>>>>>>>
>>>>>>> <PartyAttribute partyId="FOUR SEASONS HOTEL" attrName="SIC"
>>>>>>> attrValue="13"/>
>>>>>>> <PartyAttribute partyId="FOUR SEASONS HOTEL" attrName="SIC
>>>>>>> Description"
>>>>>>> attrValue="Miscellaneous"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="FOUR SEASONS HOTEL_POSTAL"
>>>>>>> contactMechTypeId="POSTAL_ADDRESS"/>
>>>>>>> <PostalAddress contactMechId="FOUR SEASONS HOTEL_POSTAL" toName="FOUR
>>>>>>> SEASONS HOTEL" address1="123 Main Street" city="NewYork"
>>>>>>> countryGeoId="USA" stateProvinceGeoId="NY" postalCode="126785"/>
>>>>>>> <PartyContactMech partyId="FOUR SEASONS HOTEL" contactMechId="FOUR
>>>>>>> SEASONS HOTEL-POSTAL" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="FOUR SEASONS HOTEL_EMAIL"
>>>>>>> contactMechTypeId="EMAIL_ADDRESS" infoString="t1@gmail.com"/>
>>>>>>> <PartyContactMech partyId="FOUR SEASONS HOTEL" contactMechId="FOUR
>>>>>>> SEASONS HOTEL_EMAIL" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>> <PartyContactMechPurpose contactMechPurposeTypeId="PRIMARY_EMAIL"
>>>>>>> partyId="FOUR SEASONS HOTEL" contactMechId="FOUR SEASONS HOTEL_MAIL"
>>>>>>> fromDate="2015-01-01 00:00:00.000"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="FOUR SEASONS HOTEL_PHONE"
>>>>>>> contactMechTypeId="POSTAL_ADDRESS"/>
>>>>>>> <TelecomNumber contactMechId="FOUR SEASONS HOTEL_PHONE" type="PHONE"
>>>>>>> countryCode="1" areaCode="254" contactNumber="555-4534"/>
>>>>>>> <PartyContactMech partyId="FOUR SEASONS HOTEL" contactMechId="FOUR
>>>>>>> SEASONS HOTEL_PHONE" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>>   <PartyRelationship partyIdFrom="FOUR SEASONS HOTEL"
>>>>>>> partyIdTo="LESLIE"
>>>>>>> partyRelationshipTypeId="ACCOUNT" roleTypeIdFrom="_NA_"
>>>>>>> roleTypeIdTo="_NA_" fromDate="2015-01-01 00:00:00.000"/>
>>>>>>>
>>>>>>>   <PartyGroup partyId="ABC ELECTRIC" groupName="OFBIZ COMPANY
NAME"/>
>>>>>>>
>>>>>>> <Party partyId="ABC ELECTRIC" partyTypeId="PARTY_GROUP"
>>>>>>> externalId="100041"/>
>>>>>>> <PartyRole partyId="ABC ELECTRIC" roleTypeId="CUSTOMER"/>
>>>>>>>
>>>>>>> <PartyAttribute partyId="ABC ELECTRIC" attrName="SIC"
>>>>>>> attrValue="02D"/>
>>>>>>> <PartyAttribute partyId="ABC ELECTRIC" attrName="SIC Description"
>>>>>>> attrValue="Electrical Contractor"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="ABC ELECTRIC_POSTAL"
>>>>>>> contactMechTypeId="POSTAL_ADDRESS"/>
>>>>>>> <PostalAddress contactMechId="ABC ELECTRIC_POSTAL" toName="ABC
>>>>>>> ELECTRIC"
>>>>>>> address1="123 Main Street" city="Toronto" postalCode="N5N 5X5"
>>>>>>> countryGeoId="CANADA" stateProvinceGeoId="ON" />
>>>>>>> <PartyContactMech partyId="ABC ELECTRIC" contactMechId="ABC
>>>>>>> ELECTRIC-POSTAL" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="ABC ELECTRIC_EMAIL"
>>>>>>> contactMechTypeId="EMAIL_ADDRESS" infoString="t2@gmail.com"/>
>>>>>>> <PartyContactMech partyId="ABC ELECTRIC" contactMechId="ABC
>>>>>>> ELECTRIC_EMAIL" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>> <PartyContactMechPurpose contactMechPurposeTypeId="PRIMARY_EMAIL"
>>>>>>> partyId="ABC ELECTRIC" contactMechId="ABC ELECTRIC_MAIL"
>>>>>>> fromDate="2015-01-01 00:00:00.000"/>
>>>>>>>
>>>>>>> <ContactMech contactMechId="ABC ELECTRIC_PHONE"
>>>>>>> contactMechTypeId="POSTAL_ADDRESS"/>
>>>>>>> <TelecomNumber contactMechId="ABC ELECTRIC_PHONE" type="PHONE"
>>>>>>> countryCode="1" areaCode="506" contactNumber="555-4433"/>
>>>>>>> <PartyContactMech partyId="ABC ELECTRIC" contactMechId="ABC
>>>>>>> ELECTRIC_PHONE" fromDate="2015-01-01 00:00:00.000"
>>>>>>> allowSolicitation="Y"/>
>>>>>>>   <PartyRelationship partyIdFrom="ABC ELECTRIC" partyIdTo="LESLIE"
>>>>>>> partyRelationshipTypeId="ACCOUNT" roleTypeIdFrom="_NA_"
>>>>>>> roleTypeIdTo="_NA_" fromDate="2015-01-01 00:00:00.000"/>
>>>>>>>
>>>>>>>   </entity-engine-xml>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message