For many business, it is important to track whom and when contact or communication was made between parties. Often it is needed to know for a customer (or a supplier) who called them when and for which purpose. It is also needed to plan them in advance.
Sometime it may be useful to group a set of communications under a single case.
And finally communication often requires a follow up as one or multiple actions (work effort) to be taken.
Proposal
In a new module party_communication:
We add a model party.communication.event with:
company
parties : Many2Many to party.party with the involved parties in the communication (include the employee automatically).
contacts: Many2Many to party.contact_mechanism limited to parties and the type
case: Many2One to party.communication.case (optional) limited to party in parties
reference: Function that display the value from the case with a setter and searcher
start and end : DateTime
purpose: Many2One to party.communication.event.purpose
type: Selection [phone, email, etc] (same as for contact mechanism).
note: Text
follow up: One2Many to party.communication.work.effort
state: Selection [scheduled, in progress, completed]
A wizard eases the creation of follow up communication by creating an empty case if needed and copy with new dates the current event.
The party.communication.event.purpose model store the configuration of purpose with:
name: Char
The party.communication.case is defined with:
name: Char
description: Text
party: Many2One to party.party
reference: Reference
start and end: DateTime
events: One2Many to party.communication.event
works: One2Many function to linked party.communication.work.effort
status: Many2One to party.communication.case.status (similar to project.work.status).
Relate actions are created for each available reference.
The follow up are stored in party.communication.work.effort with:
event: Many2One to party.communication.event
name: Char
effort: Reference [work.effort, project.work]
state: Selection [scheduled, in progress, completed]
I’m wondering if we should make the case an reference field.
It is quite common to relate all the comunications related to a sale opportunity into a single case, so we should be able to relate to at least sale.opportunity here.
Sometimes the followup of a communication event is another communication event. So I think we should allow to have party.communication.event also as follup of another event.
First the work effort could be make a communication (even if it is little bit special).
But indeed we could add a events list on the event to schedule new communication.
But for the User Point of view it will be complex to create a case and manage all the comunication from the related case as the user will have the information split into two screens (one for communication another for the opportunity). I will prefer if the user has a One2Many on the opportunity to track all the communication events of such opportunity.
I’m wondering if it will be a good idea to follow the same design as we do on timesheet lines and projects. The idea is to have a checkbox on opportunity to enable comunication and when checked the system creates automatically the case for the opportunity.
Then the user will be able to see all the events of the case directly from a One2Many field in the opportunity.
The same should be applicable for other models like: Sale Complaint So probably we should make the module have a list of extra depends to have more generic comunication methods activated by default.
Of course not, but we should take in account the usability to design the user interface and that’s what I amb talking about.
Why not? The follow up comunication should be linked to the same case so they will be all included on the same opportunity.
That sound strange for me all the comunication is related to the opportunity (so a single case).
Could you provide an example of a single opportunity with multiple cases?
I think that the case model may not be needed in this module. This way @pokoli could link the communication event directly to the opportunity without having an unneeded extra model. For me the module would be more generic this way.
I do not agree. It should be no problem to do a proper migration if the case model is added later. Maybe we do not understand the “case” model on the business level. Can you please give some examples for a “case” and why it is needed?
But if you link the event to the opportunity it is already grouped by the reference to the opportunity.
Do you have any use case for an additional grouping? For now i did not find any argument to create a grouping model for events as there are a lot of models in tryton already that would be a good fit for grouping events like “sale.complaint” for example.
We’ve been using the activity module which basically implements the same Event concept and we link it with opportunities or projects using a Resource (fields.Reference) field.
We never felt the need of a “case” model (in fact we got were happy to get rid of it as it existed in OpenERP).
A CASE may be set up for a series of
Related COMMUNICATION EVENTs regarding a particular issue. Each CASE
may have several CASE ROLEs that identify who is responsible for the CASE,
who checks the quality of service within the CASE, who is the customer for the
CASE, and so on.
I think all the things that should be set on the case are already defined by our other models like the sale opportunity or the sale complaint. As we have all of this in one database i think we should not add a new model to define that but just do it on the existing ones like we already do.
I think this is a oversimplified vision.
Using other process document as grouping tool is a poor and limited design. It prevents to collect data about a specific case like report duration, the party involved, status etc.
We are working with such a design in a lot of projects and like @albert we never missed such a case model. And in fact like @albert i had such a model in the first run but we removed it before setting our module into production. And like @albert i had copied such model from TinyERP at that time.
I think that many CMS solutions do have such a case model because they are missing the possiblity to link the conversation directly to the object that it is related to. But we can do that. I would really prefer to have the reference field on the event like @pokoli proposed.
I see no counter proposal about how to group of communication.
For me the case will stay as long as there is no other counter proposal with the same feature.
And those who does not want to use it, will just not use it.
For me the Case model makes sense but I think we need to find an easy way for users to create cases from other models (like sale.opportunity and sale.complaint) and relate comunication events to the model using the case reference. Maybe just adding a One2Many to the models with a domain to the reference field of the case will work.
This will force the user to create a case when None exists and then let them create more if required but use the existing one if only one is found.