Account Data Import:
Locked
123
123
 
|
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="[hidden email]"/> >>>> <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="[hidden email]"/> >>>> <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> >>>> >>> >> >> > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
The data model has not changed much from the book.
The parties are connected with the PartyRelationship entity, and they are connected with their roles. The Party IDs and RoleType IDs are required to make a PartyRelationship value. The PartyRelationshipType is optional. Adrian Crum Sandglass Software www.sandglass-software.com On 1/16/2015 7: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="[hidden email]"/> >>>>> <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="[hidden email]"/> >>>>> <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> >>>>> >>>> >>> >>> >> > > |
|
|
In reply to this post by Ron Wheeler
Nice example, Ron,
But what do the externalId fields stand for in the <Party> records? Is this a value defined to serve as some kind of internal identifier? Or is the value defined by the party and assigned to you as some kind of customer ID? If the latter, what do you do when you have multiple internal organisations and each has a different identifier assigned by that party? Where (in what entity would you capture that? And how would such look like (visavis the OFBiz datamodel)? 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 Fri, Jan 16, 2015 at 8:42 PM, Ron Wheeler <[hidden email] > 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="[hidden email]"/> > <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="[hidden email]"/> > <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> > > |
|
|
In reply to this post by Ron Wheeler
Ron,
It is optional as in: OFBiz needs to cater to various business setups/scenarios (realities), hence it isn't enforced through code. For some setups setting the relationship might prove superfluous. Don't be to skeptical, the books of Len Silverston describe models (see http://www.universaldatamodels.com) and as such can be out of touch with specific business scenarios. Good models though touch every aspect in all scenarios perceived so that they are applicable to the individual scenario. So, though the first edition of DMR, vol 1 was released 14 years ago it still holds validity until proven otherwise. 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 4:05 AM, Ron Wheeler <[hidden email] > 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="[hidden email]"/> >>>>> <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="[hidden email]"/> >>>>> <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> >>>>> >>>>> >>>> >>> >>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
|
|
In reply to this post by Ron Wheeler
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: [hidden email] 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="[hidden email]"/> >>>>> <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="[hidden email]"/> >>>>> <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> >>>>> >>>> >>> >>> >> > > |
|
|
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: > > [hidden email] > > 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="[hidden email]"/> >>>>>> <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="[hidden email]"/> >>>>>> <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> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
|
|
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 < [hidden email]> 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: >> >> [hidden email] >> >> 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="[hidden email]"/> >>>>>>> <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="[hidden email]"/> >>>>>>> <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> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> |
|
|
In reply to this post by Pierre Smits
This is not my installation, I am helping Tom Running get his setup
working so I do not have the whole picture. On 17/01/2015 4:49 AM, Pierre Smits wrote: > Nice example, Ron, > > But what do the externalId fields stand for in the <Party> records? Is > this a value defined to serve as some kind of internal identifier? Or > is the value defined by the party and assigned to you as some kind of > customer ID? > This is the "customer number" I am not sure how they are assigned but I am pretty sure that they are unique. I would think that they would have a 1-1 mapping with PartyID. The sample data that comes with OFBiz uses the customer name as an ID. The customer number would be an alternative but I did not see any examples where this is done nor any place to put the name. > If the latter, what do you do when you have multiple internal > organisations and each has a different identifier assigned by that > party? Where (in what entity would you capture that? And how would > such look like (visavis the OFBiz datamodel)? > Not sure what you mean here. Do you mean that the Sales department gives it a number and the Accounts payable department gives it another number? I am still trying to come to grips with the data model and the wiki's description of it and how to use it for moving data between OFBiz and other systems.. > 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 <http://www.orrtiz.com/> > > On Fri, Jan 16, 2015 at 8:42 PM, Ron Wheeler > <[hidden email] > <mailto:[hidden email]>> 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="[hidden email] > <mailto:[hidden email]>"/> > <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="[hidden email] > <mailto:[hidden email]>"/> > <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> > > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Adrian Crum-3
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: >> >> [hidden email] >> >> 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="[hidden email]"/> >>>>>>> <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="[hidden email]"/> >>>>>>> <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> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> |
|
|
In reply to this post by Pierre Smits
Hi All:
You missed something here: The original use case was NOT about creating orders. It was about sales reps being able to access customer shopping lists. OOTB, a user cannot create a shopping list without an account. I didn't change this. Best Regards, Ruth On 1/17/15 5:21 PM, Pierre Smits wrote: > 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 < > [hidden email]> 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: >>> >>> [hidden email] >>> >>> 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="[hidden email]"/> >>>>>>>> <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="[hidden email]"/> >>>>>>>> <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> >>>>>>>> >>>>>>>> >>>>>> >>>> |
|
|
In reply to this post by Ruth Hoffman-4
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: >>> >>> [hidden email] >>> >>> 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="[hidden email]"/> >>>>>>>> <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="[hidden email]"/> >>>>>>>> <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> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > |
|
|
In reply to this post by Ron Wheeler
HI Ron,
See inline. 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 Sun, Jan 18, 2015 at 12:00 AM, Ron Wheeler < [hidden email]> wrote: > This is not my installation, I am helping Tom Running get his setup > working so I do not have the whole picture. > > > On 17/01/2015 4:49 AM, Pierre Smits wrote: > >> Nice example, Ron, >> >> But what do the externalId fields stand for in the <Party> records? Is >> this a value defined to serve as some kind of internal identifier? Or is >> the value defined by the party and assigned to you as some kind of customer >> ID? >> >> This is the "customer number" > I am not sure how they are assigned but I am pretty sure that they are > unique. > I would think that they would have a 1-1 mapping with PartyID. > The sample data that comes with OFBiz uses the customer name as an ID. The > customer number would be an alternative but I did not see any examples > where this is done nor any place to put the name. > > If the latter, what do you do when you have multiple internal >> organisations and each has a different identifier assigned by that party? >> Where (in what entity would you capture that? And how would such look like >> (visavis the OFBiz datamodel)? >> >> > Not sure what you mean here. > Do you mean that the Sales department gives it a number and the Accounts > payable department gives it another number? > What I meant to say is the following: Suppose you have multiple internal organisations, whereby there is a certain amount of independency amongst the internal organisations. And each (unaware of the others) gets to do business with the various suppliers known. Now suppose that each supplier provides all of the internal organisations with a unique customerId. Like in following example: Internal Organisation A gets from Supplier 1 customerId 1-0001 assigned Internal Organisation A gets from Supplier 2 customerId 2-0001 assigned Internal Organisation A gets from Supplier 3 customerId A-A2-0001 assigned Internal Organisation A gets from Supplier 4 customerId 1-0001 assigned How would you see that captured in the OFBiz setup? > > I am still trying to come to grips with the data model and the wiki's > description of it and how to use it for moving data between OFBiz and other > systems.. > > 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 <http://www.orrtiz.com/> >> >> >> On Fri, Jan 16, 2015 at 8:42 PM, Ron Wheeler <rwheeler@artifact-software. >> com <mailto:[hidden email]>> 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="[hidden email] >> <mailto:[hidden email]>"/> >> >> <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="[hidden email] >> <mailto:[hidden email]>"/> >> <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> >> >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
|
|
The situation is sales reps and customers not purchase agents and suppliers.
I suppose that it is possible to have the same customer being sold to by two different salespeople from different organizations. I would expect that each instance of the company would have a different account number but I can also imagine a case where the selling company gives the same number to 2 divisions of the customer. I would expect that the customer would be represented by several Party records that are linked together to a higher level corporate entity. The number of external ids would likely be related to how the company wanted to be billed (1 account with the supplier or separate accounts with separate IDs for each purchasing arrangement. Ron On 18/01/2015 11:47 AM, Pierre Smits wrote: > HI Ron, > > See inline. > > 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 Sun, Jan 18, 2015 at 12:00 AM, Ron Wheeler < > [hidden email]> wrote: > >> This is not my installation, I am helping Tom Running get his setup >> working so I do not have the whole picture. >> >> >> On 17/01/2015 4:49 AM, Pierre Smits wrote: >> >>> Nice example, Ron, >>> >>> But what do the externalId fields stand for in the <Party> records? Is >>> this a value defined to serve as some kind of internal identifier? Or is >>> the value defined by the party and assigned to you as some kind of customer >>> ID? >>> >>> This is the "customer number" >> I am not sure how they are assigned but I am pretty sure that they are >> unique. >> I would think that they would have a 1-1 mapping with PartyID. >> The sample data that comes with OFBiz uses the customer name as an ID. The >> customer number would be an alternative but I did not see any examples >> where this is done nor any place to put the name. >> >> If the latter, what do you do when you have multiple internal >>> organisations and each has a different identifier assigned by that party? >>> Where (in what entity would you capture that? And how would such look like >>> (visavis the OFBiz datamodel)? >>> >>> >> Not sure what you mean here. >> Do you mean that the Sales department gives it a number and the Accounts >> payable department gives it another number? >> > What I meant to say is the following: > Suppose you have multiple internal organisations, whereby there is a > certain amount of independency amongst the internal organisations. And each > (unaware of the others) gets to do business with the various suppliers > known. Now suppose that each supplier provides all of the internal > organisations with a unique customerId. > > Like in following example: > Internal Organisation A gets from Supplier 1 customerId 1-0001 assigned > Internal Organisation A gets from Supplier 2 customerId 2-0001 assigned > Internal Organisation A gets from Supplier 3 customerId A-A2-0001 assigned > Internal Organisation A gets from Supplier 4 customerId 1-0001 assigned > > How would you see that captured in the OFBiz setup? > > > >> I am still trying to come to grips with the data model and the wiki's >> description of it and how to use it for moving data between OFBiz and other >> systems.. >> >> 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 <http://www.orrtiz.com/> >>> >>> >>> On Fri, Jan 16, 2015 at 8:42 PM, Ron Wheeler <rwheeler@artifact-software. >>> com <mailto:[hidden email]>> 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="[hidden email] >>> <mailto:[hidden email]>"/> >>> >>> <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="[hidden email] >>> <mailto:[hidden email]>"/> >>> <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> >>> >>> >>> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: [hidden email] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
That all dependents on how important the customer is to the supplier (how
much it will add to the cashflow) and how sophisticated the system of the supplier is. It's a lot of speculation. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Sun, Jan 18, 2015 at 10:49 PM, Ron Wheeler < [hidden email]> wrote: > The situation is sales reps and customers not purchase agents and > suppliers. > I suppose that it is possible to have the same customer being sold to by > two different salespeople from different organizations. > I would expect that each instance of the company would have a different > account number but I can also imagine a case where the selling company > gives the same number to 2 divisions of the customer. > I would expect that the customer would be represented by several Party > records that are linked together to a higher level corporate entity. > The number of external ids would likely be related to how the company > wanted to be billed (1 account with the supplier or separate accounts with > separate IDs for each purchasing arrangement. > > Ron > > > On 18/01/2015 11:47 AM, Pierre Smits wrote: > >> HI Ron, >> >> See inline. >> >> 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 Sun, Jan 18, 2015 at 12:00 AM, Ron Wheeler < >> [hidden email]> wrote: >> >> This is not my installation, I am helping Tom Running get his setup >>> working so I do not have the whole picture. >>> >>> >>> On 17/01/2015 4:49 AM, Pierre Smits wrote: >>> >>> Nice example, Ron, >>>> >>>> But what do the externalId fields stand for in the <Party> records? Is >>>> this a value defined to serve as some kind of internal identifier? Or is >>>> the value defined by the party and assigned to you as some kind of >>>> customer >>>> ID? >>>> >>>> This is the "customer number" >>>> >>> I am not sure how they are assigned but I am pretty sure that they are >>> unique. >>> I would think that they would have a 1-1 mapping with PartyID. >>> The sample data that comes with OFBiz uses the customer name as an ID. >>> The >>> customer number would be an alternative but I did not see any examples >>> where this is done nor any place to put the name. >>> >>> If the latter, what do you do when you have multiple internal >>> >>>> organisations and each has a different identifier assigned by that >>>> party? >>>> Where (in what entity would you capture that? And how would such look >>>> like >>>> (visavis the OFBiz datamodel)? >>>> >>>> >>>> Not sure what you mean here. >>> Do you mean that the Sales department gives it a number and the Accounts >>> payable department gives it another number? >>> >>> What I meant to say is the following: >> Suppose you have multiple internal organisations, whereby there is a >> certain amount of independency amongst the internal organisations. And >> each >> (unaware of the others) gets to do business with the various suppliers >> known. Now suppose that each supplier provides all of the internal >> organisations with a unique customerId. >> >> Like in following example: >> Internal Organisation A gets from Supplier 1 customerId 1-0001 assigned >> Internal Organisation A gets from Supplier 2 customerId 2-0001 assigned >> Internal Organisation A gets from Supplier 3 customerId A-A2-0001 assigned >> Internal Organisation A gets from Supplier 4 customerId 1-0001 assigned >> >> How would you see that captured in the OFBiz setup? >> >> >> >> I am still trying to come to grips with the data model and the wiki's >>> description of it and how to use it for moving data between OFBiz and >>> other >>> systems.. >>> >>> 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 <http://www.orrtiz.com/> >>>> >>>> >>>> On Fri, Jan 16, 2015 at 8:42 PM, Ron Wheeler >>>> <rwheeler@artifact-software. >>>> com <mailto:[hidden email]>> 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="[hidden email] >>>> <mailto:[hidden email]>"/> >>>> >>>> <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="[hidden email] >>>> <mailto:[hidden email]>"/> >>>> <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> >>>> >>>> >>>> >>>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: [hidden email] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |