Negociating an opportunity with a customer requires several interactions with the lead. It’s a good practice to store this activities related to the opportunity so other members of the sales team have all the communication available. This actvitiies can be from different types and are assigned to an employee which is the responsible of doing it.
Proposal
Create a new activity module with the following models:
Activity Type
Name: Translatable char to describe the activity type
Icon: Icon to represent the activity (will be used on the activity list view)
Active
By default the following activity types will be created:
Call
Meeting
Task
Activity
Type: Many2One to activity Type
Subject: Required Char
Description: Text field
Assigned to: Many2One to company.employee
Done by: Many2one to company.employee, it will be automatically filled by the employee of the user how clicked the complete button
Date: DateTime field
Resource: A reference field to link activities to other models
State: Pending/Done/Cancelled
The activity module will be a new dependency of the sale_opportunity module, and a One2Many realtion to the activity will be added on the Leads and Opportunities
I do not see any benefit for having such global object. For me, it would look better to have an aggregated view of activities based on dedicated object. For example, a call and a task do not have much in common.
Indeed I think it is better to implement the “Party Communication Event” and “Communication Event Follow-up” from The data Model Resource Book (which even consider to make links with work efforts).
Interesting proposal @pokoli. And yes, one single model with types makes sense to me.
One thing I would like to propose is to include a field for the timezone or location of the event. It may not be relevant for companies that never cross timezones, but if you do it would be a nice feature for users.
One example is a person in one timezone making an appointment with a person in another timezone, it’s easier to add a timezone and the time you are talking about rather than translate the time of the location of the event compared to having to calculate the local time.
Thanks for referencing this book @ced. It’s great that Tryton has a point of reference for its modeling.
Yes, but if you are in Brussels talking to someone who is in Sydney, Australia for example and wants to make an appointment with you at 10 am their local time you will have to convert 10 am to your local time when you are entering the appointment in Tryton. Outlook has a good example of this. By default they don’t have a field for timezones, but a user needs to they can specify the timezone.
I have to admit that it is a luxury, but it is a really nice feature.
It would be also nice to be able to list events per Party per period in a report.
Also, could be that Activity would need few days: projected and actual.
For me activities are not solely related to sales, customer and employees, but related to involved parties and other resources.
Readonly function field with first line of description
For me both are better managed with a complete project/issue/ticket workflow and not here.
But a kind of reminder system could be useful.
Better a list of Resources. Here you can put the
involved opportunity or sales.
I see no need for a general state, as the date time indicates
if it is coming/planned or done.
IMHO activities are better named events . They are a collection of information about already done or planed/coming events, the involved parties and references to resources.
For me events should enhance the party module.
Customer and Employees should be represented by a list of involved parties.
On each involved party we could show the related events.
Additionally events could enhance the note functionality
of Tryton, because a note is just one event type.
We could show events as a note to the involved parties
and to the related referenced resources.
Of course this schema must be adapted to Tryton models. And it is not required to implement all of them but thinking about future possibilities will create a good basic design.
