The opportunity and sale workflows can be used to manage the quotation of services, which will be manually converted into project and tasks latter.
When using the project_invoice method the invoiced amount can be different from the quoted amount, specially in the case of using “Timesheet” invoices but also when new tasks are added that are not present on the initial quotation.
Proposal
Add an sale as extra dependency on the project_revenue module. If both modules are installed add the following functionalities:
Add a new Many2One from sale line to project work
Add the reverse One2Many from project work to sale line
Add a new functional field on project.work named “Quotation amount”. This fill will be computed as the sum of the amounts (quantity * unit_price) of the sale lines linked to this work.
I think it is wrong to use sale order for project management. Sale order are designed to be a one time operation.
Indeed I think it is better to have the sale_opportunity to be able to create a project (not sure it will be flexible enough). Or at least being able to convert it (link) to a project instead of creating a sale order.
Don’t understand. Here are some examples of projects which are on time operation:
Create a Website
Develop a custom tryton module
Create a Technical Study for your House
The main problem with the sale_opportunity is that is not possible to generate a quotation report for it and send it to the customer. This is generated by the sale module.
Also there it is common to generate several quotations for the same opportunity. For example, when creating a website the customer may request a quotation for a Static Website and a Dynamic website and then pick only one depending on it’s budget.
That said, sale_opportunity is the state of a project bid (or request for quotation)… so there is certainly much that can be done to start out in sale_opportunity, but pricing/discounts are dealt with once converted to a sale in the draft stage.
If there was a means to have the preliminary project (and project specific nomenclature) only visible/usable in the context of the sale [opportunity] that would be useful as the contract is not awarded yet and should not muddy the production side of project in the works.
Sergi is correct in that there may be many [parallel] and subsequent refinements to propositions… the opportunity/conversion process should be able to deal with that - but it appears that only one conversion be in progress at a time.
More so, companies who are subcontractors may quote multiple general contractors on the same ultimate project, but with differing conditions/pricing.
Also, as Sergi proposes, Quotation amounts come from sales not opportunities (though all of unit price, quantity and tax info are truly needed to be able to correctly invoice in project_revenue).
When you are selling only services, there are no need to use a sale order.
Also the invoicing of all those example are often a mix of partial advance payment and invoicing on progress or timesheet.
But this topic remember New invoicing method when selling both goods and services - #3 by ced but as I said I do not think this new task object should be project. project and sale are different workflow of selling.
Indeed I think we are missing a quotation report for the project.
On sale it would be managed by creating multiple sale so as for the project.
Probably but indeed the current design of project makes it difficult to manage such state because the field is on each work. Or we will need to have separate states for project and task.
Indeed I would prefer to have complete freedom on the definition of the states of a work.
Yes probably something like that. Project management workflow is not so standard as sale and neither very much constrained, each company has its own practice.
project_tracker provides a “category” (named “tracker”, the name was borrowed from redmine).
project_phase adds:
a model to store phases (would be the “state” you’re talking about). A phase also defines if it is a “final” phase (which would be equivalent to closed state)
a m2o field named “phase” to Tasks
a Workflow model where you define which phases are valid for each workflow (you may have a workflow for issues and another one for new features)
a m2o field named “workflow” to Trackers (you may define just three worfkflows but have 15 different trackers)
So once a task has a tracker assigned, only phases from the workflow of the tracker are valid
It is also useful to define which is the default phase for each tracker so it is filled with on_change once the tracker is set.
I’m not sure if it is really a good feature because it may appear unexpected to the user. I’m wondering if it will not be better to have a validation. If the progress is not equals or more to the progress of the state, the state is not valid.
But if you have total freedom over the states, how can I implement a workflow where fields are readonly in certain states? Do I have to ignore it and create the states in my own module? Because I prefer buttons to set the state (and eventually do some logic) instead of the dropdown (just a taste).
My experience shows me that if you set a fixed workflow for project, you will have trouble.
Instead it is better to just put constraint, the state definition can store such constraint like a field is required, the progress must be greater than etc.
In order to be know if the opportunity is won or lost we should know if a project is lost. So I think we should add an aditional mark on state to know if the project is still active or not. This should be able to negotiate the project state with the following conditions:
If project has empty progress and and active state is still in negotiation
If project has some progress is won
If project has no progress but and inactive state is lost
This will have an aditional benefit, that we can have a computed active field on project which will be used to “hide” cancelled and done projects