Some services are not delivered directly at sale confirmation, they can take time. So we need a way to keep track of those tasks to perform.
Also company may want to invoice the service only once the service has been fulfilled.
Moreover the company may want to track the time spent for each of this service line to analyse the margin and profit.
Proposal
We add a checkbox on the service products to define a list of task template designed to create task (project work).
When a sale line with such product is confirmed, the sale create the corresponding tasks.
An origin field (to link with a sale line) is added to the project work of type task which prevents to fill the parent field and make the type selection limited to task.
The invoice method “On Shipment” is renamed to “On fulfillment” and include the management of all tasks being done to invoice the corresponding sale line. When such task is done, it marks the sale to be invoiced. A scheduled task will process those sales (this way only one invoice is created when multiple tasks are done closely).
If the Project Revenue Module is activated, the calculation of the revenue is based on the sale price (and the list price is hidden).
If the Project Invoice Module is activated, an invoice method “Sale” is added for such tasks.
The task template define the name of the task, if the timesheet are allowed, the effort computed from the quantity sold and eventually children tasks using the same design.
Maybe something to consider is that using inheritance one can reuse existing projects or tasks: we’ve found in some cases that the company needs to register some information before the project or task is approved and the best place to register that information is in the project/task itself. Maybe they even have to start working on it before its approval (because some blueprints need to be done in order to make a quotation and things like that).
The later proposal is indeed solving the same requirement.
But I finally think that it will be better to reuse project task instead of creating a new “work order” model. This way all the tasks are in the same place and both usage will benefit from the improvements made for each use case.
I also think that having the tasks in the same place is really nice. But the project itself is also in the same model as the tasks.
Maybe a further improvement will be that the project fields are moved into their own model. So you have one model for the tasks and one model for the projects. You can also create your own models to group tasks together like a work order. Both can also have their own rights, state and extra fields for employees etc.
The problem is that you will loose the tree view on the project view where you have the projects with their tasks as childs.
I just wanted to mention it but I think it will be a big task.
I wonder why this restriction is required. IMHO it would be nice to have the possibility to subordinate the new sale project tasks in a project structure.
It would be nice if the task template defaults the name of the task on the sale line, which can be edited by the user. The task template could be quite generic and needs to be specialised for a specific sale.
Because project will bring ambigus information about the task like an invoice method, a customer party etc.
I think that the task name from product in combination of the sale line origin will be enough to discriminate tasks.
But this part will be certainly extensible with custom module.
The sale.sale object could be the origin of an also newly created parent project, then all the project information could be controlled by the sale and being read only on project. This way it would be possible to use the project for planning and to define the exact tasks later.
This could be also done in an custom module, when avoiding constraints on database level in the base module.
I do not think it would be a clean design but it will create many ambiguity.
For example what happens to task created in such project but not related to a sale line (or related to a different sale)? Also users would want to group multiple sales into a “single” project.
For me the only point of this would be to group task from the same sale, but this can be done with an Function field.