Lead improvements

[Nicolas Micoud]

Hello,

I would like to make some improvements to the "Lead" window, as I get same requirements from 2 distinct customers in the last month :)
 - Activity Type : migrate from a List (System level) to a real table
 - Add a "Position Name" to be used instead (ro in parallel) of the "Position" (C_Job_ID) field ; but maybe is doable using the current "Title" field
 - Be able to use Lead for both Sales and Purchase ; their idea is to manage recruitment of vendors (subcontractors).
    -> my idea is to :
        - add a IsVendorLead (so we would have structure as C_BPartner (IsCustomer=IsSalesLead ; IsVendor=IsVendorLead)
        - adapt the ConvertLead process to tick IsCustomer/IsVendor according to IsSalesLead/IsVendorLead

        - add a 'Vendor lead' window

        - add a 'Vendor Opportunities' window (and maybe a C_Opportunity.IsSOTrx, but maybe be can guess using C_BParter.IsCustomer/IsVendor)

 

I'll have to do it in their installations, so question is: can some of those ideas be integrated in trunk?
As the Lead module is not used ATM, i did not think about a migration script, but seems feasible to do it

wdyt?

Nicolas

[Carlos Antonio Ruiz Gomez]

Hi Nicolas, I don't use this module, but I know several installations
that use it, would be better to have opinions from real users.

My 2¢:

> - Activity Type : migrate from a List (System level) to a real table

This sounds a bit disruptive for actual installations, you would need to
take care of migrating the old list values (String) to the new table
values (Activity_ID)

Because of that I think the table must be System+Tenant - this is, the
System has the predefined values actually on the list, allowing to add
new values in tenants.

> - Add a "Position Name" to be used instead (ro in parallel) of the
"Position" (C_Job_ID) field ; but maybe is doable using the current
"Title" field

Right, for me Title sounds correct too

> - Be able to use Lead for both Sales and Purchase ; their idea is to
manage recruitment of vendors (subcontractors).
>     -> my idea is to :
>         - add a IsVendorLead (so we would have structure as
C_BPartner (IsCustomer=IsSalesLead ; IsVendor=IsVendorLead)
>         - adapt the ConvertLead process to tick IsCustomer/IsVendor
according to IsSalesLead/IsVendorLead

It sounds fine IMO.

>        - add a 'Vendor lead' window
>         - add a 'Vendor Opportunities' window (and maybe a
C_Opportunity.IsSOTrx, but maybe be can guess using
C_BParter.IsCustomer/IsVendor)

Not sure if is worthy - I guess you can adapt the existing window to
manage the lead, what if (same as in Business Partner) a lead is a
customer and vendor lead at the same time?

Regards,

Carlos Ruiz



Am 16.12.20 um 08:21 schrieb Nicolas Micoud:

> Nicolas --

[Nicolas Micoud]

Hello,

Thanks for your feedback - your're right, a dedicated window is not necessary.
And it can be done when needed directly on installations.

So, content of the patch will be :

 - add a new table (C_ActivityType ? as C_Activity as is already used) with very basic columns Value, Name, Description, Code (optional, but to be able to store value from list if anybody has some hardcoded mechanisms based on RefListValue) ; I would also add a List Sales/Purchase (Sales, Purchase, Both)
 - populate this table with records from the current list (be able to manage not dictionnary items)

 - add a column C_ActivityType_ID on C_ContactActivity

 - make an update to populate C_ActivityType_ID using ActivityTyp

 - deactivate ActivityType column

  - Add IsVendorLead on AD_User and display the field on Lead window

 - Update ConvertLead process to take care of the new field

 
 -> Migration scripts to be put in upcoming 8.1z

 

Does it sound correct?

Thanks

Nicolas

[Norbert Bede]

hi Nicolas, we are using it frequently at the customer, did some improvements, can be migrated to the core if quite generic and others involved.

at first activity type, we have as a table. that is  important, user should very specific names. 
regarding to isVendorLead = > I suggest same like for activitytype, replace leadsource to table and you can use this for any purpose. (if affordable) - dont't forget we are talking about ad_user table - is it better to less new fields.

especially previously discussed json field type would be really helpful in lead table. in my experience lead is very-very different on each crm implementation.

if you want i can send you above 2 tables as ddl then we can convert it to centralised id.

norbert

[Nicolas Micoud]

Hi Norbert,

That would be great to have details of tables, I'll use it as a basis for scripts.

Thanks,

Nicolas

[Nicolas Micoud]

Hi,

@Norbert: I've a look at your script ; can you give some details on C_ContactActivityType table please?

I did not plan to create following columns as I think they are related to some specific needs/development :

isselfservice

headercolor

contentcolor

gpw_calendar_id

contactactivitytype (I think this one is used to store the 'old' C_ContactActivity. ActivityType'hardcoded' value) ?

I also notice you have a 'Help' column on _Trl table but not on the main one.

Is it used ?

Thanks,

Nicolas

[Norbert Bede]

Hi,

@Nicolas Micoud 

isselfservice - no idea, probably not used. you can drop it.

headercolor/contentcolor - we are using these fields when rendering contact activities in iDempiere calendar - same logic like for R_RequestType  (title and body of calendar event) - IMO can be useful, just copy of logic from requests.

gpw_calendar_id -  is another part of the collaboration solution - gpw_calendar = groupware calendar - use case: when the user create/update activity, can assign to a group (groupware calendar) gpw calender ensure keep bi-directional syncing C_ContactActivity with external provider, by caldav protocol. ATM we are able to sync data with  google calendar (can be used for other providers - but generally ready need ot write api's) Goal: sharing/security/share with desktop/mobiles and collect data from devices and convert them to centralised activity.

how this works -after successful authentication flow with provider - we delegate calendar setup to master (google) user, The user can create many calendars, and in google can assign external google users to these calendars. when the calendar opening the plugin sync all calendars with an assignment to a user. Not implemented but relative easily can be implemented calendar selection between gpw calendars eg. sales, transport, worksheets, etc.  This is not important, while google and any caldav compactible calendar allow select subscribe/show/hide calendars.   Would be happy to review and commit to the community in case of involvement.

contactactivitytype = yes store - let say base type. I assume we should have 3 times calendar base type but 3 different - custom - names.

Help - missing is error - can be added to to main or remove from _trl (add can be easier, logical to me.)

norbert

--
You received this message because you are subscribed to a topic in the Google Groups "iDempiere" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/idempiere/Q_agFydASIM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/1f62ef12-b5a1-4d64-bc53-18ee4d7b0cf0n%40googlegroups.com.

[Nicolas Micoud]

Hi,

Ok, thanks for those infos

I've created two tickets :

 - https://idempiere.atlassian.net/browse/IDEMPIERE-4616 : add IsVendorLead - should be easy

- https://idempiere.atlassian.net/browse/IDEMPIERE-4617: replace lists with  tables - will probably take much time (I may need help for migrating data on Posgresql, Oracle should be fine) ; as it can have huge side effects, will be part of 8.2z scripts

Nicolas