Party Communication Event

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.

What if the communication is with a supplier, or another party who is not supposed to become a customer ?

I guess that in this case, any proposal to tie communication to customer relationship would fail.
Or you have something in mind that I’m missing ?

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.

Because all examples were related to sales, I got mislead.
I agree with you.

It is just open for sales?

However, for those event often occured on the shipment and also purchase and also internal usage.

My opinion it might like the email action that appeared on every model. And user can create the event and follow up

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 it is too restrictive to have only one employee. So my design with a list of parties is more flexible.

I think if a event is under many cases, it is indeed a random event with no real case.

The point is that an event has no lifetime. It is just there to record what happened, is happening will happen.

Well this is no the purpose of the communication event to be a ticket system. But of course a ticket system could generate events.

FYI the design is inspired by the The Data Model Resource Book.

I think I’m slowly getting it. I was thinking that party.communication.event was the ‘entrypoint’ but that should be the 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 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.

It is better that each case is linked to only one document. Otherwise you must create more cases.

Indeed it can be helpful.

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?

1 Like

Is parent a field that is not yet defined here? Or is it something else?

It was a reminiscence of an older version.