When converting a sale opportunity a sale is created for the proposed products. But this may not be suitable when the opportunity is about selling a project or selling a subscription service.
Proposal
In order to be able to convert to difernt models, we should be able to select different models on subscription lines, so I propose to change the current product field to a Reference field, which will accept the following models:
Product (To keep the current functionality)
Service (If sale_subscription module is installed). A subscription contract will be created for each line/service when converting the opportunity.
Project: A reference to project, so the user will be able to create a new project or link into an existing one.
An oportunity will be one if one of the following conditions are meet:
One of the sales reached the confirmed state (current behaviour)
One of the subscriptions reached the running (state)
One of the projects progress is greater or equal than 0 (we understand that a project with no progress is a not started project)
I do not think it is the right design. I think the opportunity should be typed as sale or subscription etc.
I do not think it is possible to mix inside the same opportunity a sale order and a project.
I don’t know enough tryton neither sale_opportunity module so sorry in advance but here I go:
May be a design with a base Opportunity class??
This class would contain all the logic shared plus a new “choose field” to force only one type of OpportuniyLine, I mean Product, Project, Subscription… which will be extended (“choose field”) and implemented through its typed classes (SaleOpportunityLine, ProjectOpportunityLine…) in its own modules where will override methods like get_sale_line…
PS → I’m not a fan of base classes neither implementation through inheritance. I always prefer composition over inheritance but, as I said before, I don’t have enough knowledge yet about tryton neither python. Anyway I hope above explanation will be enough to catch the idea
I think there should be only one opportunity. For example, it is common that an opportunity involves one project + one subscription. That is, if you win the opportunity you win both. If you lose, you lose both.
Also, if you take note of what has been talked about that opportunity (as we do with sale_opportunity_activity or your proposed followup design), that conversation also refers to the whole opportunity.
There’s at least the “Estimated revenue amount” in opportunities that does not make sense for subscriptions, but maybe that is because we need some extra fields to allow informing about “Estimated recurring amount”.
After a second though I think that we should not focus on subscription also. The subscription normally is a cause of sale or an project, and it should be generated once the sale or project is completed not before.
But we should keep the design open to allow third party modules to plug-in into the opportunity workflow and convert with other objetcs.
