Hello Denis, Wed, 30 Oct 2013 11:36:24 -0700 (PDT) [email protected]: >> >When setting up a party relationship module, the first thing we may >> >want to consider is: >> >NATURE >> >1. Legal entity. >> >2. Natural person. >> For me a basis model for relationships should not make this >> difference nor be based on it. IMHO this functionality should be >> implemented in other modules, since it is an independent and special >> conception. >I think this is the most important difference between the parties. The >natural person can move from one legal entity to the other. It is not >possible the other way around. I do not see a reason why a >non-distinguishment could be of any use. I do not see a situation in >which I may not need to know whether it is a real person or a legal >entity. no, I do not agree that this would be the most important difference between parties in all businesses. It is also reasonable to distinguish persons from legal or informal organizations. While running an website it could be useful to have a special type for "cookies" or "referer-ids" and when running a cemetery it could be useful to distinguish the "living" from the "death" persons. Pure B2B or B2C do not need this distinction at all.
This distinctions are useful in many scenarios, but they are _not needed_ to build relationships with parties. We always try to cut away everything not mandatory, to follow the UNIX philosophy. >> >These two objects can have three main relations between each other. >> >RELATION >> >A. Active relation (ongoing) >> >B. Passive relation (from the past) >> >C. Future relation (back to the future) >> IMHO "start date" and "thru date" are optional attributes of >> relationships. >> I do not understand 'main relations'. IMHO especially *relation* is >> the attribute in the model, we wanted to use in a flexible way. It >> is just to be able to collect *all* used party relations in every >> business we can think of. >I am not sure what the correct name may be. But we only have these >three options. And all three are important to link the relation. For me this would be much better controlled by using start- and end-date as optional attributes for each relation. Having no date or one start-date only is similar to your type A. Having start- and end-date in the past is type B and when both dates are in the future, it is type C. On the other hand your suggestion has problems with a moving time axis: What to do when the date of "today" is catching the dates of a relation you defined type C? By definition it is type C, but by the current date it is type A an active relation. >> >These relations again can be tagged by endless characteristics. >> >CHARACTERISTIC >> >i. Client >> >ii. Supplier >> >iii. Forwarder >> >iv. Employee >> >v. Authority >> >vi. Franchise-Partner >> >vii. Agent >> >viii. Consortium >> >etc... >> >From my point of view, as business models tend to be so different, >> >I would propose to have everybody create his own characteristics >> >fitting to business requirements. You can then combine as much as >> >you like. >> AFAIU these 'characteristics' are similar to Silverstons 'Party >> Roles'. Where parties 'play roles' in the company. This >> conception is in my understanding not necessary for a relationship >> model and could be implemented otherwise. >I believe this is crucial, because if we do not include this - what >then are we including that can be of any help? This is probably my >main problem of understanding. I do not understand what you/we want to >link, if not this. AFAIU we want to have a named link between parties or maybe party-like objects. Cédric mentioned the closest conception to roles or characteristics in Tryton are the models based on party, like company, employee or bank. So the idea is, to build relationships not only upon records in the party model, but on records of possibly different models, like said in his examples: Fri, 18 Oct 2013 18:19:29 +0200 Cédric Krier <[email protected]>: >>>> "Employee of" -> there is a employee and a company >>>> "Customer of" -> there is a customer and a supplier >>>> "Subsidiary of" -> there are two companies >>>> "Salemen of" -> there is a party and a company I find a module which can handle and display this examples would be very promising to argue. These relationships could be able to replace the company tree, we are currently using to set up multi-company scenarios and the hard wired company-employee relationship in Tryton. But surely this needs discussion. >> >Besides, one of the most crucial parts is whether the solution is >> >easy and comfortable to handle during operations, as every CRM >> >module depends on the user's ability and will to nurture the system >> >and benefit from it. >> >When I get a phone call from a person introducing him/herself with >> >name and company, I must be able to type this into the computer >> >within seconds to get an overview of who this contact is and what I >> >should be doing and consider. If the system does not allow this, >> >the best architecture will not be used and the data pool will not >> >grow after implementation as it costs more time than helps. >> For me this is far beyond of the aim of a base module which should >> introduce basic handling of party relationships. Of course you are >> right that it would be nice to have more modules coming, providing >> detailed functionality and optimized usability for certain use >> cases. But all these good ideas are definitely not necessary for a >> base party relationship module. > As far as I understand, the relations will usually be added when I > add a new party. Not only. Relations can be used always, when you want to collect and maintain relational information shared by more than one party. >If the handling does not provide the usability needed and >the positive work effect required, the functionality will never be >used. Attempting to add or update these features ones per year as a >project for let's say 1,500 parties is probably not doable - so it >must be provided during the daily workflow. >That is why I am confused here. From a commercial point of view, there >is no need to link relations when we do not have a detailed objective >what to use it for. The "detailed objective what to use it for" is having a functionality to build *any* kind of relationships between party-like objects. So the use case is general, world-wide, everywhere, always. It is good to check these conceptions to not stand in the way. Finding out if it is possible to enhance the provided functionality to built own ideas. Because of the general approach - it is sometimes called "generic" - the module will not implement your or other special implementation as a whole, but partly. >Thanks for your help to bring me onboard. Welcome! Best, 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
