Link between sales and projects


(Sergi Almacellas Abellana) #1


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.


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 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.


(Cédric Krier) #2

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.

Convert opportunity to multiple modules
(Sergi Almacellas Abellana) #3

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.

(Richard PALO) #4

? Of course a [potential] project is a sale.

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).

(Cédric Krier) #5

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 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.

(Sergi Almacellas Abellana) #6

If we add a quotation report, then we should add a new quotation state to indicate which projects are still in negotiation.

Do you think we should add a workflow on projects similar to the one on sales?

(Cédric Krier) #7

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.

(Sergi Almacellas Abellana) #8

You mean allow the user to set custom states for task via a configuration table?

(Cédric Krier) #9

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.

(albert) #10

Then, you could be interested in project_phase:

which requires:

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.

(Sergi Almacellas Abellana) #11

I was thinking in something more simpler like create a new model ( to store the following fields:

  • Type: Project or task
  • Name: The name of the sequence

Then the state will depend on type and dynamically get the values from the table.

And maybe we can include the following flags:

  • Add tab domain: If set a new tab domain will be added for each action of project work that does not have any domain
  • Count tab domain: Set if the count should be set for the tab domain.

(Cédric Krier) #12

I would add a sequence on it.

So we also need a way to get the default value, or at least set the state with an on_change on the type.

(Cédric Krier) #13

Also in order to make state flexible, the invoice method should no more rely on it.

(Sergi Almacellas Abellana) #14

So I’m wondering if it makes sense to mark some states as Completed, which will be used to automatically set the work progress to 100%.

(Cédric Krier) #15

Probably as in some way we have starting state which are for 0% progress. So I would use the terms start and stop to describe both.

(Sergi Almacellas Abellana) #16

I’m wondering it won’t be better to add the progress on the state and automatically update the work progress when changing the state if it is lower.

(Cédric Krier) #17

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).

(Cédric Krier) #19

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.

(Sergi Almacellas Abellana) #20

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