ok, i will put the extra constraint in the lead find and contact find screens...
thanks for your help, regards, Hans On Thu, 2008-06-05 at 23:50 -0600, David E Jones wrote: > > It doesn't sound like the new field or the from/thru date are needed. > Let me try to clarify what I wrote before about the explicit exclusion > thing (ie when looking for leads include leads but exclude all of > those who are also contacts, so that contacts don't show up with the > leads). > > You have a one-way progression among these roles, so you can define > rules for viewing or reporting on them like: > > 1. if a party is in the contact role and the lead role include them on > the contact list, but not on the lead list > > In other words, just define a "lead" as only a lead and not a contact, > ie the current role but not the "next" role, so that you only look at > each in the furthest role down the line. > > Any new data structures or whatever sound like they would be redundant > and possibly confusing. > > Looking at this particular situation realistically: when a party move > from a lead to a contact, they ARE still a lead, but now they are also > a contact. However, because they are a contact there is no reason to > do anything with them to treat them as you would other leads. > > -David > > > On Jun 5, 2008, at 10:28 PM, Hans Bakker wrote: > > > Ok some more info. > > > > In the SFA application i want to be sure a party is only listed in > > either lead or contact or account and not in two lists. This is > > independent of any relation > > > > If i create party as a lead then i use this in the partyrelationship > > entity to have a related partyGroup record for the company name. > > When i covert the lead to contact I set the enddate on this > > relationship > > to keep the history and create a new one for the role 'contact'; > > Before that i add the role of 'contact' to this party to indicate the > > conversion. I can however not delete the 'lead' role because it is > > used > > in partyrelationship. > > > > having a new field on party is a very simple solution and i can change > > the partyFind service with no effort so one can search on this field. > > > > we can also consider to add a 'from/thru' date to the partyrole entity > > however that is a pretty big change to the system because this > > entity is > > used in many places..... > > > > > > On Thu, 2008-06-05 at 21:59 -0600, David E Jones wrote: > >> > >> I don't really like the idea of "primary role", as roles don't really > >> work that way. > >> > >> If you don't want a party showing up on a list of leads and contacts, > >> then they shouldn't have both the lead and contact roles... > >> > >> Could you be more specific about what you're trying to do here? > >> > >> -David > >> > >> > >> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote: > >> > >>> Why not make it a party relationship? A party is related to this > >>> party/company/etc as a lead/contact/account/etc. > >>> > >>> -Adrian > >>> > >>> --- On Thu, 6/5/08, Hans Bakker <[EMAIL PROTECTED]> > >>> wrote: > >>> From: Hans Bakker <[EMAIL PROTECTED]> > >>> Subject: primary Role on party > >>> To: "user" <[email protected]> > >>> Date: Thursday, June 5, 2008, 8:08 PM > >>> > >>> In the SFA application I need the definition of a 'primary roleType' > >>> to > >>> identify where a party is listed...either in leads, contacts or > >>> accounts... > >>> > >>> Anybody any objections when i add this field to the Party entity? > >>> > >>> Regards, > >>> Hans > >>> > >>> > >> > > >
