Acme IS the client company.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 7:34 AM, Ruth Hoffman wrote:
Hi Adrian:
Thanks for the input. As always, I appreciate other points of view. And,
I regard your feedback with the utmost respect.
First, I must respond to your final comment where you say:
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:
In the interest of preserving what is left of my sanity and getting back
with an example within a reasonable amount of time, my use case was
incomplete. I should have stated: An anonymous person must not see any
shopping lists, let alone those of another system user. Only users
acting as sales reps for the company of record (see below), can access
other user's shopping lists. And, sales reps can only access shopping
lists of other users who are acting as customers of the sales rep.
Please be aware that as things stand today, an anonymous user cannot
create a shopping list and, cannot login to the application we are using
to manage shopping lists. Therefore any security and/or fraud
vulnerability you suggest has been addressed.
Second, while your example below is useful in some situations, for my
client this will not work.
Susan Smith must act as on behalf of my client's company (the company of
record for the OFBiz instance) and not Acme.
So, there is at least another Party involved that:
My Client's Company
-------------------------------
Party = Client Company
Party Type = Internal Organization
Roles = NA
In this use case Client Company doesn't play any active roles. (In
another use case, Client, Acme and Coyote play roles where they have
relationships with Client Company. But that isn't really relevant here.)
However, Acme and Coyote do:
From Party = Acme Corporation
From Role = Franchisor (NOTE: This is a new role type we needed for
this application)
To Party = Coyote Enterprises
To Role = Franchisee (NOTE: This is a new role type we need for this
application)
Party Relationship Type = Group Rollup ***
*** This is the example of when having the party relationship type
helps. Because now we know all the users who can take advantage of all
the goodies the Franchisor (in this case Acme corp) gets based on
agreements that they execute with Client Company. Only Acme has these
agreements in effect. Not organizations that are franchisee's of Acme.
The other part of the use case I left out: Users from both Acme and
Coyote can have system accounts and create shopping lists. These users
may or may not have a relationship with sales reps from Client.
Where Susan Smith is an employee of Client and she plays a role of sales
rep:
From Party = Susan Smith
From Role = Sales Rep
To Party = Bob Brown
To Role = Customer
Not sure if all this makes things clear or just muddies the waters :-)
Again, thanks much for your input. It always helps to have a sounding
board.
Ruth
On 1/17/15 4:40 PM, Adrian Crum 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:
[email protected]
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="[email protected]"/>
<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="[email protected]"/>
<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>
