Contributors mailing list archives
Re: Field Serviceby
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.
we discussed your answer and this is what we understood:
a team is prepared to do a particular type of work and this
particular type of work will be having a fixed set of phases or
For example, Team for constructing buildings.
They know their job and phases through which they need to go through, or the stages they need to undergo during the construction.
So when we create a construction order, we will assign it to a 'construction' team.
Now the order should go through all the stages which the team has. That means the phases or stages of their 'TYPE' of work.
The stages associated with the team is meant for the type of works they need to handle
if we understand this correctly, I still find the stages misplaced.
Jobs vary very much and might need different workflows, and teams often do a number of jobs in parallel.
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
On 26.09.2018 16:02, Maxime Chambreuil wrote:
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.