Account Data Import:
Locked
123
123
 
Administrator
|
OK, let's keep it "simple". Suppose you have (this is demo data + securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make much - if any
- sense) <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> Then suppose you need also (don't try to make sense to this just focus on my point) <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPL-NOEML"/> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND securityGroupId="MYPORTAL_EMPL-NOEML" That's just what I want to say. It maybe have no real interest in the case of PartyRelationship. But Ron's request at OFBIZ-3764 would not be covered if we simply added a field to PartyRelationship to what was initially envisioned by Bob (an account number) Because Ron's request (the condo association http://en.wikipedia.org/wiki/Condominium) is to have many different "account numbers" for the same parties in the the same roles. HTH Jacques Le 14/01/2015 23:54, Pierre Smits a écrit : > Jacques, > > In order to grasp what you tried to bring across I assembled some PoC data. > See below: > > <PartyRelationshipType description="" hasTable="N" parentTypeId="" > partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" > roleTypeIdValidFrom="" roleTypeIdValidTo=""/> > > > > <!-- relations from the left side party to 2 different parties with the > same role -->] > > <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= > "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" > > fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" > roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" > > fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > > > <!-- the relationship of the second example with a different fromDate > --> > > <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" > roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" > > fromDate="2010-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > > > <!-- a party relationship reversed --> > > <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= > "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" > > fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > > > > > <!-- both parties having the same role --> > > <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" > roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" > > fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > > > <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" > roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" > > fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId="AGENT" > comments="Sandbox example"/> > > > > All load perfectly well when the PartyRelationshipType doens't have and > when parties have the roles they should have for the relationship. > > So you do have to explain better, because I am not getting it. > 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < > [hidden email]> wrote: > >> This is not what I mean Pierre, please re-read >> >> Jacques >> >> |
|
Ahh.
Now it is getting clearer. You are introducing potentially new requirement regarding uniqueness (the securityGroupId). Of course it will fail to load, because the primary keys didn't change. The easiest workaround would be to change the fromDate, as this is part of the set of primary keys. 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 Thu, Jan 15, 2015 at 8:03 AM, Jacques Le Roux < [hidden email]> wrote: > OK, let's keep it "simple". Suppose you have (this is demo data + > securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make > much - if any - sense) > > <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" > partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" > roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" > securityGroupId="MYPORTAL_EMPLOYEE"/> > > Then suppose you need also (don't try to make sense to this just focus on > my point) > > <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" > partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" > roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" > securityGroupId="MYPORTAL_EMPL-NOEML"/> > > Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND > securityGroupId="MYPORTAL_EMPL-NOEML" > > That's just what I want to say. It maybe have no real interest in the case > of PartyRelationship. > But Ron's request at OFBIZ-3764 would not be covered if we simply added a > field to PartyRelationship to what was initially envisioned by Bob (an > account number) > Because Ron's request (the condo association http://en.wikipedia.org/wiki/ > Condominium) is to have many different "account numbers" for the same > parties in the the same roles. > > HTH > > Jacques > > Le 14/01/2015 23:54, Pierre Smits a écrit : > >> Jacques, >> >> In order to grasp what you tried to bring across I assembled some PoC >> data. >> See below: >> >> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >> >> >> >> <!-- relations from the left side party to 2 different parties with >> the >> same role -->] >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> >> >> <!-- the relationship of the second example with a different fromDate >> --> >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2010-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> >> >> <!-- a party relationship reversed --> >> >> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >> >> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> >> >> >> >> <!-- both parties having the same role --> >> >> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >> >> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> >> >> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >> >> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >> AGENT" >> comments="Sandbox example"/> >> >> >> >> All load perfectly well when the PartyRelationshipType doens't have and >> when parties have the roles they should have for the relationship. >> >> So you do have to explain better, because I am not getting it. >> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> This is not what I mean Pierre, please re-read >>> >>> Jacques >>> >>> >>> |
|
Administrator
|
Yes that would be the workaround since we have ms there
Jacques Le 15/01/2015 08:39, Pierre Smits a écrit : > Ahh. > > Now it is getting clearer. You are introducing potentially new requirement > regarding uniqueness (the securityGroupId). Of course it will fail to load, > because the primary keys didn't change. The easiest workaround would be to > change the fromDate, as this is part of the set of primary keys. > > 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 Thu, Jan 15, 2015 at 8:03 AM, Jacques Le Roux < > [hidden email]> wrote: > >> OK, let's keep it "simple". Suppose you have (this is demo data + >> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >> much - if any - sense) >> >> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >> partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" >> roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" >> securityGroupId="MYPORTAL_EMPLOYEE"/> >> >> Then suppose you need also (don't try to make sense to this just focus on >> my point) >> >> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >> partyRelationshipTypeId="EMPLOYMENT" roleTypeIdFrom="INTERNAL_ORGANIZATIO" >> roleTypeIdTo="EMPLOYEE" fromDate="2001-01-01 12:00:00.0" >> securityGroupId="MYPORTAL_EMPL-NOEML"/> >> >> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >> securityGroupId="MYPORTAL_EMPL-NOEML" >> >> That's just what I want to say. It maybe have no real interest in the case >> of PartyRelationship. >> But Ron's request at OFBIZ-3764 would not be covered if we simply added a >> field to PartyRelationship to what was initially envisioned by Bob (an >> account number) >> Because Ron's request (the condo association http://en.wikipedia.org/wiki/ >> Condominium) is to have many different "account numbers" for the same >> parties in the the same roles. >> >> HTH >> >> Jacques >> >> Le 14/01/2015 23:54, Pierre Smits a écrit : >> >>> Jacques, >>> >>> In order to grasp what you tried to bring across I assembled some PoC >>> data. >>> See below: >>> >>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>> >>> >>> >>> <!-- relations from the left side party to 2 different parties with >>> the >>> same role -->] >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <!-- the relationship of the second example with a different fromDate >>> --> >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2010-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <!-- a party relationship reversed --> >>> >>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>> >>> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> >>> >>> <!-- both parties having the same role --> >>> >>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>> >>> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>> >>> fromDate="2001-05-13 00:00:00.000" partyRelationshipTypeId=" >>> AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> All load perfectly well when the PartyRelationshipType doens't have and >>> when parties have the roles they should have for the relationship. >>> >>> So you do have to explain better, because I am not getting it. >>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> This is not what I mean Pierre, please re-read >>>> Jacques >>>> >>>> >>>> |
|
|
In reply to this post by Jacques Le Roux
An account number is a PARTY IDENTIFICATION - it has nothing to do with
party relationships. Adrian Crum Sandglass Software www.sandglass-software.com On 1/14/2015 11:03 PM, Jacques Le Roux wrote: > OK, let's keep it "simple". Suppose you have (this is demo data + > securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make > much - if any - sense) > > <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" > partyRelationshipTypeId="EMPLOYMENT" > roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" > fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> > > Then suppose you need also (don't try to make sense to this just focus > on my point) > > <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" > partyRelationshipTypeId="EMPLOYMENT" > roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" > fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPL-NOEML"/> > > Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND > securityGroupId="MYPORTAL_EMPL-NOEML" > > That's just what I want to say. It maybe have no real interest in the > case of PartyRelationship. > But Ron's request at OFBIZ-3764 would not be covered if we simply added > a field to PartyRelationship to what was initially envisioned by Bob (an > account number) > Because Ron's request (the condo association > http://en.wikipedia.org/wiki/Condominium) is to have many different > "account numbers" for the same parties in the the same roles. > > HTH > > Jacques > > Le 14/01/2015 23:54, Pierre Smits a écrit : >> Jacques, >> >> In order to grasp what you tried to bring across I assembled some PoC >> data. >> See below: >> >> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >> >> >> >> <!-- relations from the left side party to 2 different parties >> with the >> same role -->] >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2001-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2001-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> >> >> <!-- the relationship of the second example with a different >> fromDate >> --> >> >> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >> >> fromDate="2010-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> >> >> <!-- a party relationship reversed --> >> >> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >> >> fromDate="2001-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> >> >> >> >> <!-- both parties having the same role --> >> >> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >> >> fromDate="2001-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> >> >> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >> >> fromDate="2001-05-13 00:00:00.000" >> partyRelationshipTypeId="AGENT" >> comments="Sandbox example"/> >> >> >> >> All load perfectly well when the PartyRelationshipType doens't have and >> when parties have the roles they should have for the relationship. >> >> So you do have to explain better, because I am not getting it. >> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> This is not what I mean Pierre, please re-read >>> >>> Jacques >>> >>> |
|
|
It has everything to do with party relationships.
A PartyIdentification is worth nothing when not brought in relation to something else via PartyRelationship (in the case of OFBiz), specifically considering the PartyIdentifications of the internal parties in relation to the external. Each internal party will have at least one per relationship. And if an external party is in relation with multiple internal parties, it might be so that each relationship has a different partyIdentification. 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < [hidden email]> wrote: > An account number is a PARTY IDENTIFICATION - it has nothing to do with > party relationships. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/14/2015 11:03 PM, Jacques Le Roux wrote: > >> OK, let's keep it "simple". Suppose you have (this is demo data + >> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >> much - if any - sense) >> >> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >> partyRelationshipTypeId="EMPLOYMENT" >> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >> >> Then suppose you need also (don't try to make sense to this just focus >> on my point) >> >> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >> partyRelationshipTypeId="EMPLOYMENT" >> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPL-NOEML"/> >> >> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >> securityGroupId="MYPORTAL_EMPL-NOEML" >> >> That's just what I want to say. It maybe have no real interest in the >> case of PartyRelationship. >> But Ron's request at OFBIZ-3764 would not be covered if we simply added >> a field to PartyRelationship to what was initially envisioned by Bob (an >> account number) >> Because Ron's request (the condo association >> http://en.wikipedia.org/wiki/Condominium) is to have many different >> "account numbers" for the same parties in the the same roles. >> >> HTH >> >> Jacques >> >> Le 14/01/2015 23:54, Pierre Smits a écrit : >> >>> Jacques, >>> >>> In order to grasp what you tried to bring across I assembled some PoC >>> data. >>> See below: >>> >>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>> >>> >>> >>> <!-- relations from the left side party to 2 different parties >>> with the >>> same role -->] >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2001-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2001-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <!-- the relationship of the second example with a different >>> fromDate >>> --> >>> >>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>> >>> fromDate="2010-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <!-- a party relationship reversed --> >>> >>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>> >>> fromDate="2001-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> >>> >>> <!-- both parties having the same role --> >>> >>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>> >>> fromDate="2001-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>> >>> fromDate="2001-05-13 00:00:00.000" >>> partyRelationshipTypeId="AGENT" >>> comments="Sandbox example"/> >>> >>> >>> >>> All load perfectly well when the PartyRelationshipType doens't have and >>> when parties have the roles they should have for the relationship. >>> >>> So you do have to explain better, because I am not getting it. >>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> This is not what I mean Pierre, please re-read >>>> >>>> Jacques >>>> >>>> >>>> |
|
|
My California Drvers License number might be considered a relationship
from the DMV to me, but it is not a requirement. An internal organization might want to assign that identification to me, but they are not the DMV, and the assignment of that identification does not imply I have a relationship to the internal organization. So, the two are separate and unrelated. Until you understand that, this conversation will continue to go in circles. Adrian Crum Sandglass Software www.sandglass-software.com On 1/15/2015 6:35 AM, Pierre Smits wrote: > It has everything to do with party relationships. > > A PartyIdentification is worth nothing when not brought in relation to > something else via PartyRelationship (in the case of OFBiz), specifically > considering the PartyIdentifications of the internal parties in relation to > the external. Each internal party will have at least one per relationship. > > And if an external party is in relation with multiple internal parties, it > might be so that each relationship has a different partyIdentification. > > 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < > [hidden email]> wrote: > >> An account number is a PARTY IDENTIFICATION - it has nothing to do with >> party relationships. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >> >>> OK, let's keep it "simple". Suppose you have (this is demo data + >>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >>> much - if any - sense) >>> >>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>> partyRelationshipTypeId="EMPLOYMENT" >>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >>> >>> Then suppose you need also (don't try to make sense to this just focus >>> on my point) >>> >>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>> partyRelationshipTypeId="EMPLOYMENT" >>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPL-NOEML"/> >>> >>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>> securityGroupId="MYPORTAL_EMPL-NOEML" >>> >>> That's just what I want to say. It maybe have no real interest in the >>> case of PartyRelationship. >>> But Ron's request at OFBIZ-3764 would not be covered if we simply added >>> a field to PartyRelationship to what was initially envisioned by Bob (an >>> account number) >>> Because Ron's request (the condo association >>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>> "account numbers" for the same parties in the the same roles. >>> >>> HTH >>> >>> Jacques >>> >>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>> >>>> Jacques, >>>> >>>> In order to grasp what you tried to bring across I assembled some PoC >>>> data. >>>> See below: >>>> >>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>> >>>> >>>> >>>> <!-- relations from the left side party to 2 different parties >>>> with the >>>> same role -->] >>>> >>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>> >>>> fromDate="2001-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>> >>>> fromDate="2001-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> >>>> >>>> <!-- the relationship of the second example with a different >>>> fromDate >>>> --> >>>> >>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>> >>>> fromDate="2010-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> >>>> >>>> <!-- a party relationship reversed --> >>>> >>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>> >>>> fromDate="2001-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> >>>> >>>> >>>> >>>> <!-- both parties having the same role --> >>>> >>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>> >>>> fromDate="2001-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> >>>> >>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>> >>>> fromDate="2001-05-13 00:00:00.000" >>>> partyRelationshipTypeId="AGENT" >>>> comments="Sandbox example"/> >>>> >>>> >>>> >>>> All load perfectly well when the PartyRelationshipType doens't have and >>>> when parties have the roles they should have for the relationship. >>>> >>>> So you do have to explain better, because I am not getting it. >>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> This is not what I mean Pierre, please re-read >>>>> >>>>> Jacques >>>>> >>>>> >>>>> > |
|
|
A YAGNI, if I caption Adrians posting correctly....
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 Thu, Jan 15, 2015 at 3:48 PM, Adrian Crum < [hidden email]> wrote: > My California Drvers License number might be considered a relationship > from the DMV to me, but it is not a requirement. An internal organization > might want to assign that identification to me, but they are not the DMV, > and the assignment of that identification does not imply I have a > relationship to the internal organization. > > So, the two are separate and unrelated. Until you understand that, this > conversation will continue to go in circles. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/15/2015 6:35 AM, Pierre Smits wrote: > >> It has everything to do with party relationships. >> >> A PartyIdentification is worth nothing when not brought in relation to >> something else via PartyRelationship (in the case of OFBiz), specifically >> considering the PartyIdentifications of the internal parties in relation >> to >> the external. Each internal party will have at least one per relationship. >> >> And if an external party is in relation with multiple internal parties, it >> might be so that each relationship has a different partyIdentification. >> >> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >> [hidden email]> wrote: >> >> An account number is a PARTY IDENTIFICATION - it has nothing to do with >>> party relationships. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>> >>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >>>> much - if any - sense) >>>> >>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>> partyRelationshipTypeId="EMPLOYMENT" >>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >>>> >>>> Then suppose you need also (don't try to make sense to this just focus >>>> on my point) >>>> >>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>> partyRelationshipTypeId="EMPLOYMENT" >>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_ >>>> EMPL-NOEML"/> >>>> >>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>> >>>> That's just what I want to say. It maybe have no real interest in the >>>> case of PartyRelationship. >>>> But Ron's request at OFBIZ-3764 would not be covered if we simply added >>>> a field to PartyRelationship to what was initially envisioned by Bob (an >>>> account number) >>>> Because Ron's request (the condo association >>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>> "account numbers" for the same parties in the the same roles. >>>> >>>> HTH >>>> >>>> Jacques >>>> >>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>> >>>> Jacques, >>>>> >>>>> In order to grasp what you tried to bring across I assembled some PoC >>>>> data. >>>>> See below: >>>>> >>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>> >>>>> >>>>> >>>>> <!-- relations from the left side party to 2 different parties >>>>> with the >>>>> same role -->] >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>> partyIdTo="admin" >>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <!-- the relationship of the second example with a different >>>>> fromDate >>>>> --> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>> partyIdTo="admin" >>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2010-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <!-- a party relationship reversed --> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <!-- both parties having the same role --> >>>>> >>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> All load perfectly well when the PartyRelationshipType doens't have and >>>>> when parties have the roles they should have for the relationship. >>>>> >>>>> So you do have to explain better, because I am not getting it. >>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> This is not what I mean Pierre, please re-read >>>>> >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> >> |
|
Administrator
|
In reply to this post by Adrian Crum-3
For account number definition, are you referring to what Bob initially described at OFBIZ-3764?
Because indeed PARTY IDENTIFICATION does not entail a party relationship (actually it entails one but it's implicit as you mentioned below) But you might want/need to describe this party relationship with roles attached to each party, this is the meaning of OFBIZ-3764. I would be very interested to have your opinion on OFBIZ-3764. Actually I'd be very interested to have as much as possible opinions. See my comment at https://issues.apache.org/jira/browse/OFBIZ-3764?focusedCommentId=14276808 Jacques Le 15/01/2015 15:48, Adrian Crum a écrit : > My California Drvers License number might be considered a relationship from the DMV to me, but it is not a requirement. An internal organization > might want to assign that identification to me, but they are not the DMV, and the assignment of that identification does not imply I have a > relationship to the internal organization. > > So, the two are separate and unrelated. Until you understand that, this conversation will continue to go in circles. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/15/2015 6:35 AM, Pierre Smits wrote: >> It has everything to do with party relationships. >> >> A PartyIdentification is worth nothing when not brought in relation to >> something else via PartyRelationship (in the case of OFBiz), specifically >> considering the PartyIdentifications of the internal parties in relation to >> the external. Each internal party will have at least one per relationship. >> >> And if an external party is in relation with multiple internal parties, it >> might be so that each relationship has a different partyIdentification. >> >> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >> [hidden email]> wrote: >> >>> An account number is a PARTY IDENTIFICATION - it has nothing to do with >>> party relationships. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>> >>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >>>> much - if any - sense) >>>> >>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>> partyRelationshipTypeId="EMPLOYMENT" >>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >>>> >>>> Then suppose you need also (don't try to make sense to this just focus >>>> on my point) >>>> >>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>> partyRelationshipTypeId="EMPLOYMENT" >>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>> >>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>> >>>> That's just what I want to say. It maybe have no real interest in the >>>> case of PartyRelationship. >>>> But Ron's request at OFBIZ-3764 would not be covered if we simply added >>>> a field to PartyRelationship to what was initially envisioned by Bob (an >>>> account number) >>>> Because Ron's request (the condo association >>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>> "account numbers" for the same parties in the the same roles. >>>> >>>> HTH >>>> >>>> Jacques >>>> >>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>> >>>>> Jacques, >>>>> >>>>> In order to grasp what you tried to bring across I assembled some PoC >>>>> data. >>>>> See below: >>>>> >>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>> >>>>> >>>>> >>>>> <!-- relations from the left side party to 2 different parties >>>>> with the >>>>> same role -->] >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <!-- the relationship of the second example with a different >>>>> fromDate >>>>> --> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo="admin" >>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>> >>>>> fromDate="2010-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <!-- a party relationship reversed --> >>>>> >>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <!-- both parties having the same role --> >>>>> >>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>> >>>>> fromDate="2001-05-13 00:00:00.000" >>>>> partyRelationshipTypeId="AGENT" >>>>> comments="Sandbox example"/> >>>>> >>>>> >>>>> >>>>> All load perfectly well when the PartyRelationshipType doens't have and >>>>> when parties have the roles they should have for the relationship. >>>>> >>>>> So you do have to explain better, because I am not getting it. >>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> This is not what I mean Pierre, please re-read >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >> > |
|
|
I believe I already stated my opinion. The current data model meets the
requirements. An identifier MIGHT represent a party relationship, but it doesn't ALWAYS describe a party relationship. The current data model correctly represents the real world. Adrian Crum Sandglass Software www.sandglass-software.com On 1/15/2015 9:42 PM, Jacques Le Roux wrote: > For account number definition, are you referring to what Bob initially > described at OFBIZ-3764? > Because indeed PARTY IDENTIFICATION does not entail a party relationship > (actually it entails one but it's implicit as you mentioned below) > But you might want/need to describe this party relationship with roles > attached to each party, this is the meaning of OFBIZ-3764. > > I would be very interested to have your opinion on OFBIZ-3764. Actually > I'd be very interested to have as much as possible opinions. > See my comment at > https://issues.apache.org/jira/browse/OFBIZ-3764?focusedCommentId=14276808 > > Jacques > > > Le 15/01/2015 15:48, Adrian Crum a écrit : >> My California Drvers License number might be considered a relationship >> from the DMV to me, but it is not a requirement. An internal >> organization might want to assign that identification to me, but they >> are not the DMV, and the assignment of that identification does not >> imply I have a relationship to the internal organization. >> >> So, the two are separate and unrelated. Until you understand that, >> this conversation will continue to go in circles. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>> It has everything to do with party relationships. >>> >>> A PartyIdentification is worth nothing when not brought in relation to >>> something else via PartyRelationship (in the case of OFBiz), >>> specifically >>> considering the PartyIdentifications of the internal parties in >>> relation to >>> the external. Each internal party will have at least one per >>> relationship. >>> >>> And if an external party is in relation with multiple internal >>> parties, it >>> might be so that each relationship has a different partyIdentification. >>> >>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>> [hidden email]> wrote: >>> >>>> An account number is a PARTY IDENTIFICATION - it has nothing to do with >>>> party relationships. >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>> >>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >>>>> much - if any - sense) >>>>> >>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>> >>>>> Then suppose you need also (don't try to make sense to this just focus >>>>> on my point) >>>>> >>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>> fromDate="2001-01-01 12:00:00.0" >>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>> >>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>> >>>>> That's just what I want to say. It maybe have no real interest in the >>>>> case of PartyRelationship. >>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>> added >>>>> a field to PartyRelationship to what was initially envisioned by >>>>> Bob (an >>>>> account number) >>>>> Because Ron's request (the condo association >>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>> "account numbers" for the same parties in the the same roles. >>>>> >>>>> HTH >>>>> >>>>> Jacques >>>>> >>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>> >>>>>> Jacques, >>>>>> >>>>>> In order to grasp what you tried to bring across I assembled some PoC >>>>>> data. >>>>>> See below: >>>>>> >>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>> >>>>>> >>>>>> >>>>>> <!-- relations from the left side party to 2 different parties >>>>>> with the >>>>>> same role -->] >>>>>> >>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>> >>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>> partyIdTo="admin" >>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>> >>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> >>>>>> >>>>>> <!-- the relationship of the second example with a different >>>>>> fromDate >>>>>> --> >>>>>> >>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>> partyIdTo="admin" >>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>> >>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> >>>>>> >>>>>> <!-- a party relationship reversed --> >>>>>> >>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>> >>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <!-- both parties having the same role --> >>>>>> >>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>> >>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> >>>>>> >>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>> >>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>> partyRelationshipTypeId="AGENT" >>>>>> comments="Sandbox example"/> >>>>>> >>>>>> >>>>>> >>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>> have and >>>>>> when parties have the roles they should have for the relationship. >>>>>> >>>>>> So you do have to explain better, because I am not getting it. >>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> This is not what I mean Pierre, please re-read >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>> >> |
|
Administrator
|
Le 16/01/2015 06:49, Adrian Crum a écrit : > I believe I already stated my opinion. The current data model meets the requirements. > > An identifier MIGHT represent a party relationship, but it doesn't ALWAYS describe a party relationship. The current data model correctly represents > the real world. How can you see that the current data model correctly represents the real world, when in some cases you would need to represent a party relationship with roles, as you stated above. Jacques > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >> For account number definition, are you referring to what Bob initially >> described at OFBIZ-3764? >> Because indeed PARTY IDENTIFICATION does not entail a party relationship >> (actually it entails one but it's implicit as you mentioned below) >> But you might want/need to describe this party relationship with roles >> attached to each party, this is the meaning of OFBIZ-3764. >> >> I would be very interested to have your opinion on OFBIZ-3764. Actually >> I'd be very interested to have as much as possible opinions. >> See my comment at >> https://issues.apache.org/jira/browse/OFBIZ-3764?focusedCommentId=14276808 >> >> Jacques >> >> >> Le 15/01/2015 15:48, Adrian Crum a écrit : >>> My California Drvers License number might be considered a relationship >>> from the DMV to me, but it is not a requirement. An internal >>> organization might want to assign that identification to me, but they >>> are not the DMV, and the assignment of that identification does not >>> imply I have a relationship to the internal organization. >>> >>> So, the two are separate and unrelated. Until you understand that, >>> this conversation will continue to go in circles. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>> It has everything to do with party relationships. >>>> >>>> A PartyIdentification is worth nothing when not brought in relation to >>>> something else via PartyRelationship (in the case of OFBiz), >>>> specifically >>>> considering the PartyIdentifications of the internal parties in >>>> relation to >>>> the external. Each internal party will have at least one per >>>> relationship. >>>> >>>> And if an external party is in relation with multiple internal >>>> parties, it >>>> might be so that each relationship has a different partyIdentification. >>>> >>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>> [hidden email]> wrote: >>>> >>>>> An account number is a PARTY IDENTIFICATION - it has nothing to do with >>>>> party relationships. >>>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>> >>>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does make >>>>>> much - if any - sense) >>>>>> >>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>> fromDate="2001-01-01 12:00:00.0" securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>> >>>>>> Then suppose you need also (don't try to make sense to this just focus >>>>>> on my point) >>>>>> >>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>> >>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>> >>>>>> That's just what I want to say. It maybe have no real interest in the >>>>>> case of PartyRelationship. >>>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>>> added >>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>> Bob (an >>>>>> account number) >>>>>> Because Ron's request (the condo association >>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>>> "account numbers" for the same parties in the the same roles. >>>>>> >>>>>> HTH >>>>>> >>>>>> Jacques >>>>>> >>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>> >>>>>>> Jacques, >>>>>>> >>>>>>> In order to grasp what you tried to bring across I assembled some PoC >>>>>>> data. >>>>>>> See below: >>>>>>> >>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <!-- relations from the left side party to 2 different parties >>>>>>> with the >>>>>>> same role -->] >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>> >>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>> partyIdTo="admin" >>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>> >>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <!-- the relationship of the second example with a different >>>>>>> fromDate >>>>>>> --> >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>> partyIdTo="admin" >>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>> >>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <!-- a party relationship reversed --> >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>>> >>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <!-- both parties having the same role --> >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>> >>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>> >>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>> partyRelationshipTypeId="AGENT" >>>>>>> comments="Sandbox example"/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>> have and >>>>>>> when parties have the roles they should have for the relationship. >>>>>>> >>>>>>> So you do have to explain better, because I am not getting it. >>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> This is not what I mean Pierre, please re-read >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>> > |
|
|
What do party roles have to do with identifiers?
Nothing you have said in this discussion makes any sense. I am just as lost and confused as everyone else. What are you going on about? Adrian Crum Sandglass Software www.sandglass-software.com On 1/15/2015 10:10 PM, Jacques Le Roux wrote: > > Le 16/01/2015 06:49, Adrian Crum a écrit : >> I believe I already stated my opinion. The current data model meets >> the requirements. >> >> An identifier MIGHT represent a party relationship, but it doesn't >> ALWAYS describe a party relationship. The current data model correctly >> represents the real world. > > How can you see that the current data model correctly represents the > real world, when in some cases you would need to represent a party > relationship with roles, as you stated above. > > Jacques > >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>> For account number definition, are you referring to what Bob initially >>> described at OFBIZ-3764? >>> Because indeed PARTY IDENTIFICATION does not entail a party relationship >>> (actually it entails one but it's implicit as you mentioned below) >>> But you might want/need to describe this party relationship with roles >>> attached to each party, this is the meaning of OFBIZ-3764. >>> >>> I would be very interested to have your opinion on OFBIZ-3764. Actually >>> I'd be very interested to have as much as possible opinions. >>> See my comment at >>> https://issues.apache.org/jira/browse/OFBIZ-3764?focusedCommentId=14276808 >>> >>> >>> Jacques >>> >>> >>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>> My California Drvers License number might be considered a relationship >>>> from the DMV to me, but it is not a requirement. An internal >>>> organization might want to assign that identification to me, but they >>>> are not the DMV, and the assignment of that identification does not >>>> imply I have a relationship to the internal organization. >>>> >>>> So, the two are separate and unrelated. Until you understand that, >>>> this conversation will continue to go in circles. >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>> It has everything to do with party relationships. >>>>> >>>>> A PartyIdentification is worth nothing when not brought in relation to >>>>> something else via PartyRelationship (in the case of OFBiz), >>>>> specifically >>>>> considering the PartyIdentifications of the internal parties in >>>>> relation to >>>>> the external. Each internal party will have at least one per >>>>> relationship. >>>>> >>>>> And if an external party is in relation with multiple internal >>>>> parties, it >>>>> might be so that each relationship has a different >>>>> partyIdentification. >>>>> >>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>> [hidden email]> wrote: >>>>> >>>>>> An account number is a PARTY IDENTIFICATION - it has nothing to do >>>>>> with >>>>>> party relationships. >>>>>> >>>>>> Adrian Crum >>>>>> Sandglass Software >>>>>> www.sandglass-software.com >>>>>> >>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>> >>>>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>> make >>>>>>> much - if any - sense) >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>> >>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>> focus >>>>>>> on my point) >>>>>>> >>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>> >>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>> >>>>>>> That's just what I want to say. It maybe have no real interest in >>>>>>> the >>>>>>> case of PartyRelationship. >>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>>>> added >>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>> Bob (an >>>>>>> account number) >>>>>>> Because Ron's request (the condo association >>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>> >>>>>>> HTH >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>> >>>>>>>> Jacques, >>>>>>>> >>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>> some PoC >>>>>>>> data. >>>>>>>> See below: >>>>>>>> >>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>> parties >>>>>>>> with the >>>>>>>> same role -->] >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>> >>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>> partyIdTo="admin" >>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>> >>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <!-- the relationship of the second example with a different >>>>>>>> fromDate >>>>>>>> --> >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>> partyIdTo="admin" >>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>> >>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <!-- a party relationship reversed --> >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>>>> >>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <!-- both parties having the same role --> >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>> >>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>> >>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>> comments="Sandbox example"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>> have and >>>>>>>> when parties have the roles they should have for the relationship. >>>>>>>> >>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>> >> |
|
|
I suggest we keep it friendly. A bit more explanation in stead of curtly
sentences go a long way. 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:43 AM, Adrian Crum < [hidden email]> wrote: > What do party roles have to do with identifiers? > > Nothing you have said in this discussion makes any sense. I am just as > lost and confused as everyone else. What are you going on about? > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/15/2015 10:10 PM, Jacques Le Roux wrote: > >> >> Le 16/01/2015 06:49, Adrian Crum a écrit : >> >>> I believe I already stated my opinion. The current data model meets >>> the requirements. >>> >>> An identifier MIGHT represent a party relationship, but it doesn't >>> ALWAYS describe a party relationship. The current data model correctly >>> represents the real world. >>> >> >> How can you see that the current data model correctly represents the >> real world, when in some cases you would need to represent a party >> relationship with roles, as you stated above. >> >> Jacques >> >> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>> >>>> For account number definition, are you referring to what Bob initially >>>> described at OFBIZ-3764? >>>> Because indeed PARTY IDENTIFICATION does not entail a party relationship >>>> (actually it entails one but it's implicit as you mentioned below) >>>> But you might want/need to describe this party relationship with roles >>>> attached to each party, this is the meaning of OFBIZ-3764. >>>> >>>> I would be very interested to have your opinion on OFBIZ-3764. Actually >>>> I'd be very interested to have as much as possible opinions. >>>> See my comment at >>>> https://issues.apache.org/jira/browse/OFBIZ-3764? >>>> focusedCommentId=14276808 >>>> >>>> >>>> Jacques >>>> >>>> >>>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>> >>>>> My California Drvers License number might be considered a relationship >>>>> from the DMV to me, but it is not a requirement. An internal >>>>> organization might want to assign that identification to me, but they >>>>> are not the DMV, and the assignment of that identification does not >>>>> imply I have a relationship to the internal organization. >>>>> >>>>> So, the two are separate and unrelated. Until you understand that, >>>>> this conversation will continue to go in circles. >>>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>> >>>>>> It has everything to do with party relationships. >>>>>> >>>>>> A PartyIdentification is worth nothing when not brought in relation to >>>>>> something else via PartyRelationship (in the case of OFBiz), >>>>>> specifically >>>>>> considering the PartyIdentifications of the internal parties in >>>>>> relation to >>>>>> the external. Each internal party will have at least one per >>>>>> relationship. >>>>>> >>>>>> And if an external party is in relation with multiple internal >>>>>> parties, it >>>>>> might be so that each relationship has a different >>>>>> partyIdentification. >>>>>> >>>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> An account number is a PARTY IDENTIFICATION - it has nothing to do >>>>>>> with >>>>>>> party relationships. >>>>>>> >>>>>>> Adrian Crum >>>>>>> Sandglass Software >>>>>>> www.sandglass-software.com >>>>>>> >>>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>>> >>>>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>>> make >>>>>>>> much - if any - sense) >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>>> >>>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>>> focus >>>>>>>> on my point) >>>>>>>> >>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>>> >>>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>>> >>>>>>>> That's just what I want to say. It maybe have no real interest in >>>>>>>> the >>>>>>>> case of PartyRelationship. >>>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>>>>> added >>>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>>> Bob (an >>>>>>>> account number) >>>>>>>> Because Ron's request (the condo association >>>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>>> >>>>>>>> HTH >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>>> >>>>>>>> Jacques, >>>>>>>>> >>>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>>> some PoC >>>>>>>>> data. >>>>>>>>> See below: >>>>>>>>> >>>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>>> parties >>>>>>>>> with the >>>>>>>>> same role -->] >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>> >>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>> partyIdTo="admin" >>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>> >>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- the relationship of the second example with a different >>>>>>>>> fromDate >>>>>>>>> --> >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>> partyIdTo="admin" >>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>> >>>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- a party relationship reversed --> >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>>>>> >>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- both parties having the same role --> >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>> >>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>> >>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>> comments="Sandbox example"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>>> have and >>>>>>>>> when parties have the roles they should have for the relationship. >>>>>>>>> >>>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>>> [hidden email]> wrote: >>>>>>>>> >>>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>> >>> |
|
|
I am saying the same thing you and Ruth said - Jacques is not making any
sense and I don't understand what he is going on about. Adrian Crum Sandglass Software www.sandglass-software.com On 1/15/2015 11:55 PM, Pierre Smits wrote: > I suggest we keep it friendly. A bit more explanation in stead of curtly > sentences go a long way. > > 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:43 AM, Adrian Crum < > [hidden email]> wrote: > >> What do party roles have to do with identifiers? >> >> Nothing you have said in this discussion makes any sense. I am just as >> lost and confused as everyone else. What are you going on about? >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/15/2015 10:10 PM, Jacques Le Roux wrote: >> >>> >>> Le 16/01/2015 06:49, Adrian Crum a écrit : >>> >>>> I believe I already stated my opinion. The current data model meets >>>> the requirements. >>>> >>>> An identifier MIGHT represent a party relationship, but it doesn't >>>> ALWAYS describe a party relationship. The current data model correctly >>>> represents the real world. >>>> >>> >>> How can you see that the current data model correctly represents the >>> real world, when in some cases you would need to represent a party >>> relationship with roles, as you stated above. >>> >>> Jacques >>> >>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>>> >>>>> For account number definition, are you referring to what Bob initially >>>>> described at OFBIZ-3764? >>>>> Because indeed PARTY IDENTIFICATION does not entail a party relationship >>>>> (actually it entails one but it's implicit as you mentioned below) >>>>> But you might want/need to describe this party relationship with roles >>>>> attached to each party, this is the meaning of OFBIZ-3764. >>>>> >>>>> I would be very interested to have your opinion on OFBIZ-3764. Actually >>>>> I'd be very interested to have as much as possible opinions. >>>>> See my comment at >>>>> https://issues.apache.org/jira/browse/OFBIZ-3764? >>>>> focusedCommentId=14276808 >>>>> >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>>> >>>>>> My California Drvers License number might be considered a relationship >>>>>> from the DMV to me, but it is not a requirement. An internal >>>>>> organization might want to assign that identification to me, but they >>>>>> are not the DMV, and the assignment of that identification does not >>>>>> imply I have a relationship to the internal organization. >>>>>> >>>>>> So, the two are separate and unrelated. Until you understand that, >>>>>> this conversation will continue to go in circles. >>>>>> >>>>>> Adrian Crum >>>>>> Sandglass Software >>>>>> www.sandglass-software.com >>>>>> >>>>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>>> >>>>>>> It has everything to do with party relationships. >>>>>>> >>>>>>> A PartyIdentification is worth nothing when not brought in relation to >>>>>>> something else via PartyRelationship (in the case of OFBiz), >>>>>>> specifically >>>>>>> considering the PartyIdentifications of the internal parties in >>>>>>> relation to >>>>>>> the external. Each internal party will have at least one per >>>>>>> relationship. >>>>>>> >>>>>>> And if an external party is in relation with multiple internal >>>>>>> parties, it >>>>>>> might be so that each relationship has a different >>>>>>> partyIdentification. >>>>>>> >>>>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> An account number is a PARTY IDENTIFICATION - it has nothing to do >>>>>>>> with >>>>>>>> party relationships. >>>>>>>> >>>>>>>> Adrian Crum >>>>>>>> Sandglass Software >>>>>>>> www.sandglass-software.com >>>>>>>> >>>>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>>>> >>>>>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>>>> make >>>>>>>>> much - if any - sense) >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>>>> >>>>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>>>> focus >>>>>>>>> on my point) >>>>>>>>> >>>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>>>> >>>>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>>>> >>>>>>>>> That's just what I want to say. It maybe have no real interest in >>>>>>>>> the >>>>>>>>> case of PartyRelationship. >>>>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>>>>>> added >>>>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>>>> Bob (an >>>>>>>>> account number) >>>>>>>>> Because Ron's request (the condo association >>>>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>>>> >>>>>>>>> HTH >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>>>> >>>>>>>>> Jacques, >>>>>>>>>> >>>>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>>>> some PoC >>>>>>>>>> data. >>>>>>>>>> See below: >>>>>>>>>> >>>>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>>>> parties >>>>>>>>>> with the >>>>>>>>>> same role -->] >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>> >>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>> partyIdTo="admin" >>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>> >>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <!-- the relationship of the second example with a different >>>>>>>>>> fromDate >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>> partyIdTo="admin" >>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>> >>>>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <!-- a party relationship reversed --> >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>>>>>> >>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <!-- both parties having the same role --> >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>> >>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>> >>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>>>> have and >>>>>>>>>> when parties have the roles they should have for the relationship. >>>>>>>>>> >>>>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>>>> [hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>> >>>> > |
|
Administrator
|
Did you read?
http://ofbiz.135035.n4.nabble.com/Customer-number-from-suppliers-td142646.html#a142646 http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162 https://issues.apache.org/jira/browse/OFBIZ-3764 Jacques Le 16/01/2015 09:29, Adrian Crum a écrit : > I am saying the same thing you and Ruth said - Jacques is not making any sense and I don't understand what he is going on about. > > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/15/2015 11:55 PM, Pierre Smits wrote: >> I suggest we keep it friendly. A bit more explanation in stead of curtly >> sentences go a long way. >> >> 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:43 AM, Adrian Crum < >> [hidden email]> wrote: >> >>> What do party roles have to do with identifiers? >>> >>> Nothing you have said in this discussion makes any sense. I am just as >>> lost and confused as everyone else. What are you going on about? >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/15/2015 10:10 PM, Jacques Le Roux wrote: >>> >>>> >>>> Le 16/01/2015 06:49, Adrian Crum a écrit : >>>> >>>>> I believe I already stated my opinion. The current data model meets >>>>> the requirements. >>>>> >>>>> An identifier MIGHT represent a party relationship, but it doesn't >>>>> ALWAYS describe a party relationship. The current data model correctly >>>>> represents the real world. >>>>> >>>> >>>> How can you see that the current data model correctly represents the >>>> real world, when in some cases you would need to represent a party >>>> relationship with roles, as you stated above. >>>> >>>> Jacques >>>> >>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>>>> >>>>>> For account number definition, are you referring to what Bob initially >>>>>> described at OFBIZ-3764? >>>>>> Because indeed PARTY IDENTIFICATION does not entail a party relationship >>>>>> (actually it entails one but it's implicit as you mentioned below) >>>>>> But you might want/need to describe this party relationship with roles >>>>>> attached to each party, this is the meaning of OFBIZ-3764. >>>>>> >>>>>> I would be very interested to have your opinion on OFBIZ-3764. Actually >>>>>> I'd be very interested to have as much as possible opinions. >>>>>> See my comment at >>>>>> https://issues.apache.org/jira/browse/OFBIZ-3764? >>>>>> focusedCommentId=14276808 >>>>>> >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>>>> >>>>>>> My California Drvers License number might be considered a relationship >>>>>>> from the DMV to me, but it is not a requirement. An internal >>>>>>> organization might want to assign that identification to me, but they >>>>>>> are not the DMV, and the assignment of that identification does not >>>>>>> imply I have a relationship to the internal organization. >>>>>>> >>>>>>> So, the two are separate and unrelated. Until you understand that, >>>>>>> this conversation will continue to go in circles. >>>>>>> >>>>>>> Adrian Crum >>>>>>> Sandglass Software >>>>>>> www.sandglass-software.com >>>>>>> >>>>>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>>>> >>>>>>>> It has everything to do with party relationships. >>>>>>>> >>>>>>>> A PartyIdentification is worth nothing when not brought in relation to >>>>>>>> something else via PartyRelationship (in the case of OFBiz), >>>>>>>> specifically >>>>>>>> considering the PartyIdentifications of the internal parties in >>>>>>>> relation to >>>>>>>> the external. Each internal party will have at least one per >>>>>>>> relationship. >>>>>>>> >>>>>>>> And if an external party is in relation with multiple internal >>>>>>>> parties, it >>>>>>>> might be so that each relationship has a different >>>>>>>> partyIdentification. >>>>>>>> >>>>>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> An account number is a PARTY IDENTIFICATION - it has nothing to do >>>>>>>>> with >>>>>>>>> party relationships. >>>>>>>>> >>>>>>>>> Adrian Crum >>>>>>>>> Sandglass Software >>>>>>>>> www.sandglass-software.com >>>>>>>>> >>>>>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>>>>> >>>>>>>>> OK, let's keep it "simple". Suppose you have (this is demo data + >>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>>>>> make >>>>>>>>>> much - if any - sense) >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>>>>> >>>>>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>>>>> focus >>>>>>>>>> on my point) >>>>>>>>>> >>>>>>>>>> <PartyRelationship partyIdFrom="Company" partyIdTo="accountingadmin" >>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>>>>> >>>>>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>>>>> >>>>>>>>>> That's just what I want to say. It maybe have no real interest in >>>>>>>>>> the >>>>>>>>>> case of PartyRelationship. >>>>>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we simply >>>>>>>>>> added >>>>>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>>>>> Bob (an >>>>>>>>>> account number) >>>>>>>>>> Because Ron's request (the condo association >>>>>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many different >>>>>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>>>>> >>>>>>>>>> HTH >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>>>>> >>>>>>>>>> Jacques, >>>>>>>>>>> >>>>>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>>>>> some PoC >>>>>>>>>>> data. >>>>>>>>>>> See below: >>>>>>>>>>> >>>>>>>>>>> <PartyRelationshipType description="" hasTable="N" parentTypeId="" >>>>>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>>>>> parties >>>>>>>>>>> with the >>>>>>>>>>> same role -->] >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" partyIdTo= >>>>>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>> >>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>> >>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <!-- the relationship of the second example with a different >>>>>>>>>>> fromDate >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>> >>>>>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <!-- a party relationship reversed --> >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" partyIdTo= >>>>>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" roleTypeIdTo="CUSTOMER" >>>>>>>>>>> >>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <!-- both parties having the same role --> >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="admin" partyIdTo="ltdadmin" >>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>> >>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" partyIdTo="admin" >>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>> >>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>>>>> have and >>>>>>>>>>> when parties have the roles they should have for the relationship. >>>>>>>>>>> >>>>>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>>>>> [hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >> > |
|
|
On 1/16/2015 1:05 AM, Jacques Le Roux wrote: > Did you read? > http://ofbiz.135035.n4.nabble.com/Customer-number-from-suppliers-td142646.html#a142646 is a PARTY IDENTIFICATION. > > http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162 is a PARTY IDENTIFICATION. > > https://issues.apache.org/jira/browse/OFBIZ-3764 is a PARTY IDENTIFICATION. Adrian Crum Sandglass Software www.sandglass-software.com > > Jacques > > > Le 16/01/2015 09:29, Adrian Crum a écrit : >> I am saying the same thing you and Ruth said - Jacques is not making >> any sense and I don't understand what he is going on about. >> >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/15/2015 11:55 PM, Pierre Smits wrote: >>> I suggest we keep it friendly. A bit more explanation in stead of curtly >>> sentences go a long way. >>> >>> 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:43 AM, Adrian Crum < >>> [hidden email]> wrote: >>> >>>> What do party roles have to do with identifiers? >>>> >>>> Nothing you have said in this discussion makes any sense. I am just as >>>> lost and confused as everyone else. What are you going on about? >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 1/15/2015 10:10 PM, Jacques Le Roux wrote: >>>> >>>>> >>>>> Le 16/01/2015 06:49, Adrian Crum a écrit : >>>>> >>>>>> I believe I already stated my opinion. The current data model meets >>>>>> the requirements. >>>>>> >>>>>> An identifier MIGHT represent a party relationship, but it doesn't >>>>>> ALWAYS describe a party relationship. The current data model >>>>>> correctly >>>>>> represents the real world. >>>>>> >>>>> >>>>> How can you see that the current data model correctly represents the >>>>> real world, when in some cases you would need to represent a party >>>>> relationship with roles, as you stated above. >>>>> >>>>> Jacques >>>>> >>>>> >>>>>> Adrian Crum >>>>>> Sandglass Software >>>>>> www.sandglass-software.com >>>>>> >>>>>> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>>>>> >>>>>>> For account number definition, are you referring to what Bob >>>>>>> initially >>>>>>> described at OFBIZ-3764? >>>>>>> Because indeed PARTY IDENTIFICATION does not entail a party >>>>>>> relationship >>>>>>> (actually it entails one but it's implicit as you mentioned below) >>>>>>> But you might want/need to describe this party relationship with >>>>>>> roles >>>>>>> attached to each party, this is the meaning of OFBIZ-3764. >>>>>>> >>>>>>> I would be very interested to have your opinion on OFBIZ-3764. >>>>>>> Actually >>>>>>> I'd be very interested to have as much as possible opinions. >>>>>>> See my comment at >>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3764? >>>>>>> focusedCommentId=14276808 >>>>>>> >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>>>>> >>>>>>>> My California Drvers License number might be considered a >>>>>>>> relationship >>>>>>>> from the DMV to me, but it is not a requirement. An internal >>>>>>>> organization might want to assign that identification to me, but >>>>>>>> they >>>>>>>> are not the DMV, and the assignment of that identification does not >>>>>>>> imply I have a relationship to the internal organization. >>>>>>>> >>>>>>>> So, the two are separate and unrelated. Until you understand that, >>>>>>>> this conversation will continue to go in circles. >>>>>>>> >>>>>>>> Adrian Crum >>>>>>>> Sandglass Software >>>>>>>> www.sandglass-software.com >>>>>>>> >>>>>>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>>>>> >>>>>>>>> It has everything to do with party relationships. >>>>>>>>> >>>>>>>>> A PartyIdentification is worth nothing when not brought in >>>>>>>>> relation to >>>>>>>>> something else via PartyRelationship (in the case of OFBiz), >>>>>>>>> specifically >>>>>>>>> considering the PartyIdentifications of the internal parties in >>>>>>>>> relation to >>>>>>>>> the external. Each internal party will have at least one per >>>>>>>>> relationship. >>>>>>>>> >>>>>>>>> And if an external party is in relation with multiple internal >>>>>>>>> parties, it >>>>>>>>> might be so that each relationship has a different >>>>>>>>> partyIdentification. >>>>>>>>> >>>>>>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>>>>>> [hidden email]> wrote: >>>>>>>>> >>>>>>>>> An account number is a PARTY IDENTIFICATION - it has nothing >>>>>>>>> to do >>>>>>>>>> with >>>>>>>>>> party relationships. >>>>>>>>>> >>>>>>>>>> Adrian Crum >>>>>>>>>> Sandglass Software >>>>>>>>>> www.sandglass-software.com >>>>>>>>>> >>>>>>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>>>>>> >>>>>>>>>> OK, let's keep it "simple". Suppose you have (this is demo >>>>>>>>>> data + >>>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>>>>>> make >>>>>>>>>>> much - if any - sense) >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="Company" >>>>>>>>>>> partyIdTo="accountingadmin" >>>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>>>>>> >>>>>>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>>>>>> focus >>>>>>>>>>> on my point) >>>>>>>>>>> >>>>>>>>>>> <PartyRelationship partyIdFrom="Company" >>>>>>>>>>> partyIdTo="accountingadmin" >>>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>>>>>> >>>>>>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>>>>>> >>>>>>>>>>> That's just what I want to say. It maybe have no real >>>>>>>>>>> interest in >>>>>>>>>>> the >>>>>>>>>>> case of PartyRelationship. >>>>>>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we >>>>>>>>>>> simply >>>>>>>>>>> added >>>>>>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>>>>>> Bob (an >>>>>>>>>>> account number) >>>>>>>>>>> Because Ron's request (the condo association >>>>>>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many >>>>>>>>>>> different >>>>>>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>>>>>> >>>>>>>>>>> HTH >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>>>>>> >>>>>>>>>>> Jacques, >>>>>>>>>>>> >>>>>>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>>>>>> some PoC >>>>>>>>>>>> data. >>>>>>>>>>>> See below: >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationshipType description="" hasTable="N" >>>>>>>>>>>> parentTypeId="" >>>>>>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>>>>>> parties >>>>>>>>>>>> with the >>>>>>>>>>>> same role -->] >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>> partyIdTo= >>>>>>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <!-- the relationship of the second example with a >>>>>>>>>>>> different >>>>>>>>>>>> fromDate >>>>>>>>>>>> --> >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <!-- a party relationship reversed --> >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" >>>>>>>>>>>> partyIdTo= >>>>>>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" >>>>>>>>>>>> roleTypeIdTo="CUSTOMER" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <!-- both parties having the same role --> >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="admin" >>>>>>>>>>>> partyIdTo="ltdadmin" >>>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" >>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>>> >>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>>>>>> have and >>>>>>>>>>>> when parties have the roles they should have for the >>>>>>>>>>>> relationship. >>>>>>>>>>>> >>>>>>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>>>>>> [hidden email]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Jacques >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >> |
|
|
In reply to this post by Tom Running
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> |
|
|
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> > |
|
Administrator
|
In reply to this post by Adrian Crum-3
Thanks for your input :D
Jacques Le 16/01/2015 16:27, Adrian Crum a écrit : > > On 1/16/2015 1:05 AM, Jacques Le Roux wrote: >> Did you read? >> http://ofbiz.135035.n4.nabble.com/Customer-number-from-suppliers-td142646.html#a142646 > > is a PARTY IDENTIFICATION. > >> >> http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162 > > is a PARTY IDENTIFICATION. > >> >> https://issues.apache.org/jira/browse/OFBIZ-3764 > > is a PARTY IDENTIFICATION. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > >> >> Jacques >> >> >> Le 16/01/2015 09:29, Adrian Crum a écrit : >>> I am saying the same thing you and Ruth said - Jacques is not making >>> any sense and I don't understand what he is going on about. >>> >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/15/2015 11:55 PM, Pierre Smits wrote: >>>> I suggest we keep it friendly. A bit more explanation in stead of curtly >>>> sentences go a long way. >>>> >>>> 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:43 AM, Adrian Crum < >>>> [hidden email]> wrote: >>>> >>>>> What do party roles have to do with identifiers? >>>>> >>>>> Nothing you have said in this discussion makes any sense. I am just as >>>>> lost and confused as everyone else. What are you going on about? >>>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> On 1/15/2015 10:10 PM, Jacques Le Roux wrote: >>>>> >>>>>> >>>>>> Le 16/01/2015 06:49, Adrian Crum a écrit : >>>>>> >>>>>>> I believe I already stated my opinion. The current data model meets >>>>>>> the requirements. >>>>>>> >>>>>>> An identifier MIGHT represent a party relationship, but it doesn't >>>>>>> ALWAYS describe a party relationship. The current data model >>>>>>> correctly >>>>>>> represents the real world. >>>>>>> >>>>>> >>>>>> How can you see that the current data model correctly represents the >>>>>> real world, when in some cases you would need to represent a party >>>>>> relationship with roles, as you stated above. >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>>> Adrian Crum >>>>>>> Sandglass Software >>>>>>> www.sandglass-software.com >>>>>>> >>>>>>> On 1/15/2015 9:42 PM, Jacques Le Roux wrote: >>>>>>> >>>>>>>> For account number definition, are you referring to what Bob >>>>>>>> initially >>>>>>>> described at OFBIZ-3764? >>>>>>>> Because indeed PARTY IDENTIFICATION does not entail a party >>>>>>>> relationship >>>>>>>> (actually it entails one but it's implicit as you mentioned below) >>>>>>>> But you might want/need to describe this party relationship with >>>>>>>> roles >>>>>>>> attached to each party, this is the meaning of OFBIZ-3764. >>>>>>>> >>>>>>>> I would be very interested to have your opinion on OFBIZ-3764. >>>>>>>> Actually >>>>>>>> I'd be very interested to have as much as possible opinions. >>>>>>>> See my comment at >>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3764? >>>>>>>> focusedCommentId=14276808 >>>>>>>> >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 15/01/2015 15:48, Adrian Crum a écrit : >>>>>>>> >>>>>>>>> My California Drvers License number might be considered a >>>>>>>>> relationship >>>>>>>>> from the DMV to me, but it is not a requirement. An internal >>>>>>>>> organization might want to assign that identification to me, but >>>>>>>>> they >>>>>>>>> are not the DMV, and the assignment of that identification does not >>>>>>>>> imply I have a relationship to the internal organization. >>>>>>>>> >>>>>>>>> So, the two are separate and unrelated. Until you understand that, >>>>>>>>> this conversation will continue to go in circles. >>>>>>>>> >>>>>>>>> Adrian Crum >>>>>>>>> Sandglass Software >>>>>>>>> www.sandglass-software.com >>>>>>>>> >>>>>>>>> On 1/15/2015 6:35 AM, Pierre Smits wrote: >>>>>>>>> >>>>>>>>>> It has everything to do with party relationships. >>>>>>>>>> >>>>>>>>>> A PartyIdentification is worth nothing when not brought in >>>>>>>>>> relation to >>>>>>>>>> something else via PartyRelationship (in the case of OFBiz), >>>>>>>>>> specifically >>>>>>>>>> considering the PartyIdentifications of the internal parties in >>>>>>>>>> relation to >>>>>>>>>> the external. Each internal party will have at least one per >>>>>>>>>> relationship. >>>>>>>>>> >>>>>>>>>> And if an external party is in relation with multiple internal >>>>>>>>>> parties, it >>>>>>>>>> might be so that each relationship has a different >>>>>>>>>> partyIdentification. >>>>>>>>>> >>>>>>>>>> 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 Thu, Jan 15, 2015 at 3:06 PM, Adrian Crum < >>>>>>>>>> [hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> An account number is a PARTY IDENTIFICATION - it has nothing >>>>>>>>>> to do >>>>>>>>>>> with >>>>>>>>>>> party relationships. >>>>>>>>>>> >>>>>>>>>>> Adrian Crum >>>>>>>>>>> Sandglass Software >>>>>>>>>>> www.sandglass-software.com >>>>>>>>>>> >>>>>>>>>>> On 1/14/2015 11:03 PM, Jacques Le Roux wrote: >>>>>>>>>>> >>>>>>>>>>> OK, let's keep it "simple". Suppose you have (this is demo >>>>>>>>>>> data + >>>>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE", I just made it even if does >>>>>>>>>>>> make >>>>>>>>>>>> much - if any - sense) >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="Company" >>>>>>>>>>>> partyIdTo="accountingadmin" >>>>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>>>> securityGroupId="MYPORTAL_EMPLOYEE"/> >>>>>>>>>>>> >>>>>>>>>>>> Then suppose you need also (don't try to make sense to this just >>>>>>>>>>>> focus >>>>>>>>>>>> on my point) >>>>>>>>>>>> >>>>>>>>>>>> <PartyRelationship partyIdFrom="Company" >>>>>>>>>>>> partyIdTo="accountingadmin" >>>>>>>>>>>> partyRelationshipTypeId="EMPLOYMENT" >>>>>>>>>>>> roleTypeIdFrom="INTERNAL_ORGANIZATIO" roleTypeIdTo="EMPLOYEE" >>>>>>>>>>>> fromDate="2001-01-01 12:00:00.0" >>>>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML"/> >>>>>>>>>>>> >>>>>>>>>>>> Then you can't have both securityGroupId="MYPORTAL_EMPLOYEE" AND >>>>>>>>>>>> securityGroupId="MYPORTAL_EMPL-NOEML" >>>>>>>>>>>> >>>>>>>>>>>> That's just what I want to say. It maybe have no real >>>>>>>>>>>> interest in >>>>>>>>>>>> the >>>>>>>>>>>> case of PartyRelationship. >>>>>>>>>>>> But Ron's request at OFBIZ-3764 would not be covered if we >>>>>>>>>>>> simply >>>>>>>>>>>> added >>>>>>>>>>>> a field to PartyRelationship to what was initially envisioned by >>>>>>>>>>>> Bob (an >>>>>>>>>>>> account number) >>>>>>>>>>>> Because Ron's request (the condo association >>>>>>>>>>>> http://en.wikipedia.org/wiki/Condominium) is to have many >>>>>>>>>>>> different >>>>>>>>>>>> "account numbers" for the same parties in the the same roles. >>>>>>>>>>>> >>>>>>>>>>>> HTH >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> Le 14/01/2015 23:54, Pierre Smits a écrit : >>>>>>>>>>>> >>>>>>>>>>>> Jacques, >>>>>>>>>>>>> >>>>>>>>>>>>> In order to grasp what you tried to bring across I assembled >>>>>>>>>>>>> some PoC >>>>>>>>>>>>> data. >>>>>>>>>>>>> See below: >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationshipType description="" hasTable="N" >>>>>>>>>>>>> parentTypeId="" >>>>>>>>>>>>> partyRelationshipName="Agent" partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> roleTypeIdValidFrom="" roleTypeIdValidTo=""/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <!-- relations from the left side party to 2 different >>>>>>>>>>>>> parties >>>>>>>>>>>>> with the >>>>>>>>>>>>> same role -->] >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>>> partyIdTo= >>>>>>>>>>>>> "DemoCustAgent" roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <!-- the relationship of the second example with a >>>>>>>>>>>>> different >>>>>>>>>>>>> fromDate >>>>>>>>>>>>> --> >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustCompany" >>>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>>> roleTypeIdFrom="CUSTOMER" roleTypeIdTo="AGENT" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2010-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <!-- a party relationship reversed --> >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="DemoCustAgent" >>>>>>>>>>>>> partyIdTo= >>>>>>>>>>>>> "DemoCustCompany" roleTypeIdFrom="AGENT" >>>>>>>>>>>>> roleTypeIdTo="CUSTOMER" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <!-- both parties having the same role --> >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="admin" >>>>>>>>>>>>> partyIdTo="ltdadmin" >>>>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <PartyRelationship partyIdFrom="ltdadmin" >>>>>>>>>>>>> partyIdTo="admin" >>>>>>>>>>>>> roleTypeIdFrom="MANAGER" roleTypeIdTo="MANAGER" >>>>>>>>>>>>> >>>>>>>>>>>>> fromDate="2001-05-13 00:00:00.000" >>>>>>>>>>>>> partyRelationshipTypeId="AGENT" >>>>>>>>>>>>> comments="Sandbox example"/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> All load perfectly well when the PartyRelationshipType doens't >>>>>>>>>>>>> have and >>>>>>>>>>>>> when parties have the roles they should have for the >>>>>>>>>>>>> relationship. >>>>>>>>>>>>> >>>>>>>>>>>>> So you do have to explain better, because I am not getting it. >>>>>>>>>>>>> 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 Wed, Jan 14, 2015 at 11:10 PM, Jacques Le Roux < >>>>>>>>>>>>> [hidden email]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> This is not what I mean Pierre, please re-read >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> > |
|
|
In reply to this post by Adrian Crum-3
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 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> >>> >> > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |