Tree structure is annoying here. Indeed this is the case to group communication events.
So I think the best will be to have a wizard to schedule a follow up communication event that will create the case if needed and then create an event at the planned date.
I think a relate from the referenced document will be better than a One2Many because cases can be a keep growing list. So from this list the user can create a new case or complete one and in the form view of the case he can create a communication event.
Sounds interesting but I do not fully understand from where the wizard will be executed. For me it should be possible to schedule a communication from a event but also from other models (like sale.opportunity and sale.complaint.
Wonât be better to just create the relate to the comunication event? So from the form view you can create a new case if needed but select the current one if already exist. Altought it will probably better to just set the existing one as default if only one exists (or if others are already closed due to and end date).
This is execute from a current communication event as follow up.
I do not think it happens from no where that a users without having a communication with external needs to schedule a communication.
Any way, in such case he has to open the cases (create a new one or use an existing) and create a communication event.
It does not work as it is the case that does the link.
If I understand this correctly you expect the user that is working on an opportunity to create a case only to create an event later. That is creating manually two models just to fill in an event.
For me it is already hard enough to convince users to properly use opportunities and events. Try making them create intermediate models that they will find no usage for, and youâll have a hard time trying to put such a system in real use.
I guess it is possible to add a Function Reference field on the communication event with a searcher and a setter so it is possible to have a direct relate.
The setter will have to create the case automatically and it should do nothing it there is already a case (the function field should be readonly).
Thatâs my real concern here. If the user needs to do a lot of steps for just recording a done communication or mark one call as already done we will miss most of the usage of this feature.
I just checked Suite CRM demo and they allow to record any communication (call, meeting, emails) directly from any model (opportunity, case, etc). So the user just need to enter the communication detail and itâs status.
Also Iâve seen that there is a responsible field for all the comunications which they use to show a âMy eventsâ list. I think it will be great to have a similar view on Tryton.
That makes sense. Indeed we should use such Reference field for the relates on other Tryton models.
As long as the case isnât required, I see no problem. A references field with a many2many can be added to the communication from external module.
But we have similar experience with this kind of not necessary task. Users often see no direct benefit to collect communications, so the requirements for them should be minimal. We thought about making the client able to show communication events on related models, like notes and attachments or like emails. Adding a new communication on a model would auto fill all related parties and a reference to the model.
Also we should think about a way to integrate Tryton emails into the communication model, as these are already communications of type email.
Anyway email, communications and notes are all very similar and should be unified IMHO.
As we have a party relations we can include relation to any party (not only customers).
So the module will work also with communication with supplier or other kind of parties.
We are just talking to customers here because we are focusing on how to integrate such communication with Opportunity module because is more frequent for other ERP systems to have such feature.
I have thought about this for some time and read through the thread. I think some changes can be made to the models to make it easier. Itâs a bit more like a support ticket system. Iâve added and changed some fields see below
employee: Many2One the employee who handles this event
case: One2Many which references the different models with:
name: Char name of the reference
reference: Reference link to other models
notes: One2Many add notes during the lifetime of the event and the followups, the model is similar to ir.note
note: Text description of the event
state: Selection? make it the same how it works with the project module
In this case the event becomes more like a group of things around a certain âissueâ. It also can be used not only for âexternalâ communication, but also for âinternalâ communication, more like a âthings-todoâ.
I think Iâm slowly getting it. I was thinking that party.communication.event was the âentrypointâ but that should be the party.communication.case. Each case has many âeventsâ (which are points in time) like an email came in or was send, a call came in or was made, or an appointment was made etc. So you can build a timeline about a case.
So when I open a party I get a tab with cases and there I have all the cases for that particular party. I can also open all the cases from the main menu and have domain tabs with the state of the case. Opening a case shows me the events, dates, works etc.
What Iâm missing is:
move reference field on party.communication.case to a One2Many so many references can be made to different models and records
add a description field with Text type to describe the case.
Indeed, I can see the case as a ticket and then many events happens to complete the ticket.
Iâm thinking about something like sales and projects. You sold something and you created a project for it and now during the work, the customer has some doubts about the direction. So you create a case, but what to link? A project, the sale or both? During the âeventâ with the customer you have the referenced directly at hand and donât need to go deeper into Tryton to get the data.
Completely out-of-scope but a customer calls about an invoice which is not correct. During the call, based on the information, you also got the sale order. So you create a case, describe it, add the invoice and sale order as references and add the call as event.
In most cases I think that one document is sufficient, but in some cases it isnât.
This is not the Tryton workflow. You do not create a sale when using project.
So this is two case even if it is during the same call. The goal is not to have an exact matching between the number of call and the events. But to collect accurate data.
The cases, you think it is not, will always be better collected as multiple cases.
Who says that? I said the exact opposite. After you sold something you create a project basically to track the progress.
The invoice was created because of the sale order and the customer now have questions about the invoice. So it would be handy to have the sale order at hand to see what was ordered and what was invoiced. You can enter the sale order number into the event description, but then another employee have to search for it again, which it not very efficient.
From your quote, it seems the CASE is not linked to anything. So it can be used everywhere like in production where something goes wrong. A case is created and different events happen to fix the problem. Then the case is closed.
Another one: Building inspection, during inspection different cases are created and later events happen to fix the cases.
So I think that this model is way more then only a party communication. It can be used everywhere in the system and as a base for other modules. Maybe make it more general (rename) and have it as a first citizen in the system like notes and attachments?