In such a long thread I am a bit lost to understand which ideas exactly > you do not follow. Please be more precise here. >
Ok, let me try here. > > "Needed" in this discussion is IMHO to argue and typify the most simple > base functionality to maintain relationships between parties. > I agree. > > >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. > > >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. > > >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. > > >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. 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. Thanks for your help to bring me onboard. Kind regards, Denis
