Hello Denis, thank you for your feedback.
Tue, 29 Oct 2013 15:27:06 -0700 (PDT) [email protected]: >Still, very difficult to follow your ideas here without reading a >structured outline of what is needed and what is doable. In such a long thread I am a bit lost to understand which ideas exactly you do not follow. Please be more precise here. "Needed" in this discussion is IMHO to argue and typify the most simple base functionality to maintain relationships between parties. >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. >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. >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. >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. 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
