Hi Cédric, thanks a lot for your feedback!
Fri, 18 Oct 2013 15:15:15 +0200 Cédric Krier <[email protected]>: >On 18/10/13 14:01 +0200, Udo Spallek wrote: >> great that you reanimate the discussion. >> Wed, 9 Oct 2013 19:15:29 +0200 >> Albert Cervera i Areny <[email protected]>: >> >I've just created a blueprint for it. Your comments will be very >> >welcomed. >> >[1] https://code.google.com/p/tryton/wiki/PartyRelationship >> IIUC the blueprint proposes structural relationships like >> memberships or roll-ups. IMHO the handling of structuring parties >> without sorting them them into persons and (legal/informal) >> organizations makes the later use of the information complicated >> (See [1] for the aged plannings). >I don't see why. In structural relationships could be combinations which doesn't make sense, like making parent-child relations out of persons. Employees can be persons only. Companies are always 'organizations'... It is just collecting semantic information and find ways to use them. >> But more important for me is, relationships could be so much more >> than *just* a structural roll-up of people and organizations. >I don't think the current design is. > >> Len Silverston, - the guy from whom we borrowed the conception of the >> actual party model,- proposes already a conception[2][3] for a >> relationship management which introduces *party roles* to relate >> parties in a relationship. His proposed design is not restricted to >> the management of *structural relationships* or just *customer >> relationships*. >We did not always follow it otherwise we will have a Rube Goldberg >machine. That's a good argument, but this one is better: Rube Goldberg machines are always awesome http://www.youtube.com/watch?v=qybUFnY7Y8w >> Len's model is able to handle the traditional >> customer relationships like (see table 1 for the data): >> >> "In a Customer-Relationship, Party ACME Company takes the >> role as a Customer of DEF firm an Internal Organization" >Yes. >> but also to collect information about a competitor: >> >> "In a Customer-Relationship, Party Eric is a Customer >> of Party UVW an (external) Competitor" >And why can't we store it with current design? >The relation type will be "is customer of". >The fact that UVW is a competitor is outside the relation because it is >the relation the current company has with UVW. no, that's unfortunately too simple. A 'relation' or 'relationship' is a _relational_ link or connection, not a functional. E.g. in another relationships UVW can be also play the role as a 'partner' of the enterprise, when they sponsoring a convention. >> It can be used to describe hierarchical relationships like company >> roll-ups your blueprint also provides, >> >> "In a Organization-Rollup-Relationship, Party XYZ is a Subsidiary >> of Party ABC the Parent Organization" >> "In a Organization-Rollup-Relationship, Party DEF is a Subsidiary >> of Party ABC the Parent Organization" >Same here. >> or handle information with different opinions >> >> "In Sales-Lead-Relationship, Party Thomas is a Hot-Lead >> of Party Victor an internal employee" >> "In Sales-Lead-Relationship, Party Thomas is a Cold-Lead >> of Party Jack an internal employee" >> >> "In a Sale-Chance-Relationship, Party Thomas is a 90%-Chance >> of Party Victor an internal employee" >> "In a Sale-Chance-Relationship, Party Thomas is a 10%-Chance >> of Party Jack an internal employee" >I would prefer to have a percentage field on the relation for such case >instead of predefined value in the relation/role. Here my point is: ability to collect different opinions about one and the same thing. Here are two employees having different opinions about one and the same interest. Again, as the name 'Relationship' suggests, it is about relational connections, not functional. >> The basic idea of Silverston's conception is to collect >> semantic information the company is interested in separated by >> relationship types. It is using the "roles" (and role types) the >> parties *take* or *play* in the relationship as the "relators". >I think the error is here. It is only about the point of view of the >company. Wrong. The collected data is about the point of view of everyone (usually Tryton users) who fills the database with opinions/meanings/facts. These facts can unfortunately change over time. >I think it is more powerful to remove this point of view and >be generic. And later with customization adding the point of view if >needed. There is no 'point of view of the company', because the company is not a person/user, which can encode the information/opinions. And be sure facts can be 'wrong' or getting 'wrong' over time. >> So for me, either the name 'Relationship' or 'Relation' is much too >> general for the structure-only approach of the blueprint, or the >> functionality misses all the needed parts to build real *semantic* >> relationships. >I think it is excatly the power of this design. Why? >> Table 1: >> >> ============ ========== ========== =========== ============ >> PARTY >> RELATIONSHIP FROM FROM TO TO >> TYPE NAME PARTY ROLE PARTY ROLE >> ============ ========== ========== =========== ============ >> Customer ACME Customer DEF Internal >> Relationship Company firm organization >> ------------ ---------- ---------- ----------- ------------ >> Customer Eric Customer UVW Competitor >> Relationship, >> ------------ ---------- ---------- ----------- ------------ >> Organization XYZ Subsidiary ABC Parent >> Rollup firm company Organization >> ------------ ---------- ---------- ----------- ------------ >> Organization DEF Subsidiary ABC Parent >> Rollup company company Organization >> ------------ ---------- ---------- ----------- ------------ >> Sales-Lead Thomas Hot-Lead Victor internal >> employee >> ------------ ---------- ---------- ----------- ------------ >> Sales-Lead Thomas Cold-Lead Jack internal >> employee >> ------------ ---------- ---------- ----------- ------------ >> Organization Customer Division DEF Subsidiary >> Rollup Service firm >> Division >> ------------ ---------- ---------- ----------- ------------ >> Agent Sell- Sales DEF Internal >> Relationship Assist. agent firm organization >> Corp. >> ------------ ---------- ---------- ----------- ------------ >> Supplier Fantastic Supplier DEF Internal >> Relationship Supplies firm organization >> ------------ ---------- ---------- ----------- ------------ >I don't see any advantage about the role because the role is contained >in the relation. ... so in the end, someone who really needs a relationship management will have a table with many many different relations. Without having some *aspects* to look on the data like roles and relation_types, it is nearly the same PITA as searching a bunch of free text fields filled with data ... Roles instead are declarative: The user 'defines' if a party is a 'customer', 'employee' or 'doctor'. You can say when someone started to be a 'customer', 'employee' or 'doctor'. And you can say when someone stops playing a role. Roles can be used to filter parties like showing customers on top of the search parties in out invoices or sales. And parties with roles take part in a relationship. >If we take the above example, they are no cross-mixing >between the possible role and the relationship type. >Indeed for me, in the current proposal, the relation type is the couple >(from role, to role). And the Silverston's relationship type could be a >group of relation type. Putting from role and to role together in one couple sounds interesting, but is IMHO a premature implementation detail. Just to be sure: Do you think every example I gave can be translated into the conception of Alberts blueprint, without information loss? Can you translate the examples to fit the blueprint? Or is the approach in the blueprint for rolling-up parties? Regards Udo -- _____________________________ virtual things Preisler & Spallek GbR München - Aachen Windeckstr. 77 81375 München Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz
