Contributors mailing list archives
Re: Field Serviceby
Hello Robert, Maxime,
For good collaboration it is crucial that the project has a clear terminology in place (even if you change some names in your deployment). Otherwise confusion will ensue when collaboration on features.
Some terms are not clear to me also, and when reading the code I feel that the terminology used is different from the one presented by Maxime at the OCADays.
- Customer opens a Service Request.
- Work Orders: Dispatcher plans the Work Orders for the Service Request. In the base module this is the same Model, an extension will allow for a an SR to have many WOs. Planning includes person assigned, scheduled dates, tasks to perform.
- Routes: is the Work order plan seen from the PoV of the Field people.
- Work Activities: Field People perform the Work Orders, and record the Work Activities for the work done, including time and material spent.
- Teams: Field people can be organized in Teams, although we have no detailed spec on what these teams are (skill sets, geographical areas, company departments?)
- Crews can be used, to form groups of Field People that travel together to a site, with the complementary skills necessary to fulfill a work order. But no detailed spec on this yet.
Robert's description sounds good to me, and here is a map to the terms Maxime presented (as far as I understood):
- Work order / Service Request: In line with Robert's description.
- Work Set: not in the roadmap, but compatible with current data structures, a nice feature to add.
- Work-item/activity: these are Work order lines, and Work Activity lines.
- Workflow and Transitions: current support is the basic kanban board, with column Stages.
- States: "Stages" in the Odoo terminology for Kanban workflow steps. There is a list of available Stages, and each Service Order is in a Stage/State.
My concern is that we should not have a single universal Stage/State kanban "workflow".
Instead, we should have a potentially different kanban workflow for each "team" (or whatever grouping concept makes sense).
- Teams has an "workflow": the list of expected Stages SOs are expected to go through.
- Service Orders are in one of the Stages of the "workflow" they are to follow.
Maybe rename my "Teams" model to "Service Flow"?
By the way, we should move this discussion to the repo.
I suggest creating a DESIGN.md file there, and initiate it with this terminology.
Citando Maxime Chambreuil <email@example.com>:
Hello Robert,Yes this is compatible with a different terminology.If teams do not make sense in your use case, don't check the option in the settings. Maybe what you call a team will be what we call a crew.Cheers,Maxime
El lun., 8 de oct. de 2018 15:43, robert <firstname.lastname@example.org> escribió:
We started to work with the oca field-service module and are trying to integrate the field service module into it, that we created ourselves.
Now I have a number of ideas and concerns:
It is unclear to me, whether we have the same understanding what a work order is.
Here is our approach/definition:
Work order / Service Request
A work order is a task or a job for a customer, that is scheduled or assigned to someone. A work order may be for products or services.
A Work Order may include one or more of the following: One or more Work-Sets Cost estimates Forms (like checklists) Date and time to execute the work order Information about the location and entities to execute the work order and the person to whom the work order is assigned
Work orders are often repetitive in nature. Such work orders consist of similar steps that have to be executed. A Work Set is used to help to create work orders. It consists of a number of work items that have to be executed
A Work Set may include one or more of the following: One or more Work-Items A category A workflow
A Work item is a task that is to be executed. It may include: Needed skill Time estimate Used time State out of a set of possible states
A state has a name, one or several inbound transitions and on outbound transition.
A transition is a possible path between two states. It has a
Guard which is a set of rules that define who and under what conditions this path can be crossed.
A workflow is a sequence of connected steps that executed together complete a specific process. Some of these steps are dependent on each other, each is controlled by a set of states.
We have all these elements implemented to diverse levels of completeness and are now trying to incorporate them into the oca field-system module.
Do you think that the above elements are “in line” with the overall structure of the oca field-system module?
Daniel Reis has made a PR in which he proposes to assign states to teams. However, I do not like this idea.
I discussed that with my people and I could find no good use case for it.
As outlined above I think stages should be assigned to work-items (subparts of a work order).
Thanks for your feedback
robertOn 26.09.2018 16:02, Maxime Chambreuil wrote:Dear Contributors,We have made good progress on the Field Service base module. I hope you guys will enjoy extending it next week at the 2018 OCA Days in Louvain-la-Neuve:Please review the list of issues and add yours if missing. We will review and discuss them on monday morning.