Question: Assign multiple workers to an order?

[javimurcia]

It is posible to assign multiple workers to a single service order?

Here is my use case: We perform maintenance and repair of heating installations. When we have to perform a field service, we seldom send a single worker to the location, but instead we send multiple workers in a van to perform the service. We don't have teams: one day worker a and worker b will be on the van 1 to a location, and the next day we will send worker b and c to the same location (many jobs span multiple days)

[wolfhall]

There is currently no team concept for routes in the FSM module. The way we have modeled this in the past is by assigning work to routes. A route in your case exists for one day and is tied to one van. as long as you schedule Vans you don't run into conflicts. In the morning there is a simple assignment of people to vans so we know who went on what route. We are expanding on the day route right now and could add a list of assigned workers.
Maybe this will work for you? Wolfgang

[hparfr]

I work around this issue by setting a "van" as an fsm.person.

[brian10048]

I think it would still be useful for a field such as crew_ids on the order. Usually there is one worker (typically the driver) who is responsible for the work being done and provides the crew workers instruction while on the job. The driver is assigned as the main worker, and the rest of the workers on the job get set as the crew_ids

Even using routes to assign the multiple workers, it seems necessary at the order level to track all of the workers responsible and helps with reporting hours spent on a job.

[babatoko]

Same in my case. Question already asked some times ago.

[babatoko]

Do not want to be rude. It seems to my really strange to use concept of the past or a work around to answer to something that seem to be a new case. To make things or software that make the difference some open hunderstanding questions may be asked don't you think?

[wolfhall]

I am not sure what happened here. I thought we are discussing how to best solve a problem. There are multiple options. I see reasonable sharing of ideas by people who care to find a good solution or maybe multiple approaches? What was said to offend?

[brian10048]

Hi @babatoko,

I think @wolfhall simply means that in the past he has solved this problem using the method he described. The past he is referring to is not related to this specific project.

This concept is still new to this project and we are all here working to come up with a solution all of us can find useful for our unique situations.

[javimurcia]

I think it would still be useful for a field such as crew_ids on the order. Usually there is one worker (typically the driver) who is responsible for the work being done and provides the crew workers instruction while on the job. The driver is assigned as the main worker, and the rest of the workers on the job get set as the crew_ids

Even using routes to assign the multiple workers, it seems necessary at the order level to track all of the workers responsible and helps with reporting hours spent on a job.

This second option seems more flexible to me, here is an example:

Sometimes, the van may leave some workers at a location, and continue to a second service location, where the rest of the workers will perform another field service, so 2 service orders are being carried on at the same time. Even more, the van might leave a location while some workers are still performing operation, with only one or 2 workers to perform an operation in another location(usually one operation that requires special qualifications), so the van approach won't work for this case.

The proposed crew_ids would accommodate this scenario pretty well. We can use the current field assigned to to indicate the responsible worker, and the crew_ids to notify the rest of the workers thay have work to do.

We can add a state field to crew_ids, a simple selection field with the options ToDo and Done. That way each "normal" worker can mark it's own work as done (but they won't be able to change the field service order status), so the service order is no longer showing in its pending work, and the manager can be informed of the progress, and can validate the work done (by changing the crew_ids back to ToDo if corrective actions are needed).

This handles the worker assignment and work scheduling, for the encoding of the actual worked hours, the fieldservice_account module already does that, and allows each worker to their works report against a service order..

Maybe a simpler method to encode the worked hours could be implemented (my workers aren't very adept with technology) and we could implement something similar to the attendance app: Workers just have to press "start", "stop" or "pause" and the system automatically calculates the time spent, but maybe this deserves it's own discussion.

[hparfr]

@crazy-projects why not integrate Project / Tasks for that ? I mean if you need to have a certain level of precision, subtasks (suborders), timesheets, and so on, may be, having a link between an FSM Order and a project can be the solution to not re-invent the wheel.

Concerning crews, I have a quite similar need in the MRP where I need to track who were on the assembly line. The design is : crew: name, crew_members_ids _crewmembers: partner_id, start_date, end_date In that way, this allow us to change the composition of the crew.

[javimurcia]

@crazy-projects why not integrate Project / Tasks for that ? I mean if you need to have a certain level of precision, subtasks (suborders), timesheets, and so on, may be, having a link between an FSM Order and a project can be the solution to not re-invent the wheel.

Concerning crews, I have a quite similar need in the MRP where I need to track who were on the assembly line. The design is : crew: name, crew_members_ids _crewmembers: partner_id, start_date, end_date In that way, this allow us to change the composition of the crew.

I think four our case it would be overkill. Usually our work involves repair or maintenance of existing installations not done by us, but in most case these projects are so small that is not worth to create a formal definition of projects and a set of task to be completed and assign each task to a worker.

Rethinking our use case, what we really need (that is not already covered by the field service app) is basically telling each worker where to go each day, since the exact work to be performed will be decided on site by the responsible worker, or the workers themselves, so the order instructions are more than enough, there is no need to create instructions for each worker, so the crew_ids is the way to go.

[hparfr]

what we really need is basically telling each worker where to go each day

You may be interested by this —not finished— PR https://github.com/OCA/field-service/pull/358 It creates a link between a calendar and an order. In that way you can manage use the calendars tools (iCal invitations (accept / deny meetings) and synchronization, integration to smartphones / smartwatches, etc.)

[zachwaite]

@wolfhall You mentioned you guys "are expanding on the day route right now and could add a list of assigned workers." This sounds like it could solve the problem in most cases. Is there a way to preview this in a dev branch somewhere or still in design?

[wolfhall]

@zachwaite Still in design. Do you have a deadline for this?

[zachwaite]

@wolfhall This is one of a few features that is of interest for an upcoming project. I may be interested in contributing to development of the feature if the project takes off.

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.