-
Notifications
You must be signed in to change notification settings - Fork 26k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FIX] sale_timesheet: get profitability items from all linked projects #167999
base: 16.0
Are you sure you want to change the base?
[FIX] sale_timesheet: get profitability items from all linked projects #167999
Conversation
e073f46
to
2c9d8a3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems good to me but I'm not too knowledgeable about how these flow functionally work
@@ -128,12 +128,18 @@ class SaleOrderLine(models.Model): | |||
|
|||
project_id = fields.Many2one( | |||
'project.project', 'Generated Project', | |||
compute='_compute_project_id', store=True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from this:
odoo/addons/sale_project/models/sale_order.py
Lines 29 to 32 in 0ae818c
@api.depends('order_line.product_id.service_tracking') | |
def _compute_visible_project(self): | |
""" Users should be able to select a project_id on the SO if at least one SO line has a product with its service tracking | |
configured as 'task_in_project' """ |
it seems like the user should be able to select a project, so the field should probably at least be readonly=False
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're able to select it on the SO, but this compute method only affect the order's lines, where project_id
is assumed to be generated or provided by the SO rather than user-selected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That field is only used to say the SOL generated that project, we don't really use it for the data displayed in the right side panel in project update, IMO. 🤔
And so that field is not used to say that SOL is linked to that project as you said in your commit message. 🙂
e3e3284
to
187b0a6
Compare
187b0a6
to
e84d2fc
Compare
52abddb
to
a654dde
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work, however, it does not seem you fix the bug explained in the video, the product used in the video does not create any project and task.
The steps to reproduce the issues described in your commit message are not the same than the ones showed in the video.
IMO, the bug is not in 15.0 and 16.0 but since 17.0.
@@ -128,12 +128,18 @@ class SaleOrderLine(models.Model): | |||
|
|||
project_id = fields.Many2one( | |||
'project.project', 'Generated Project', | |||
compute='_compute_project_id', store=True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That field is only used to say the SOL generated that project, we don't really use it for the data displayed in the right side panel in project update, IMO. 🤔
And so that field is not used to say that SOL is linked to that project as you said in your commit message. 🙂
You're right, I think I forgot to enable analytic accounting, which is why I wasn't able to reproduce it as in the video.
I'm not sure what you mean; as far as I can tell, the behavior in 17.0 is exactly the same as in 16.0. |
a654dde
to
2b53425
Compare
Versions -------- - 16.0+ Steps ----- 1. Enable analytic accounting; 2. have a sales order with a timesheeted service product; 3. have two projects with different AALs; 4. link both projecs to the same SOL; 5. create timesheets in both projects; 6. open the profitability view of a project. Issue ----- The profitability shows shows the total revenue of the SO, but only the cost of that specific project. Cause ----- The `_get_profitability_items` override only checks the AAL associated with that project. Solution -------- Call `_get_profitability_items` on all projects linked the the project's sales order. opw-3631672
2b53425
to
c8dce26
Compare
Hi @xavierbol Updated the PR in a way that it would fix the flow shown in the client video. |
Why don't we want to just take into account the timesheets linked to the project? 🤯 To me, the issue explained on the ticket is because we take into account the whole revenue instead of just taking the revenues related to the work done in the project itself. However, after investigating a bit, I don't think it is possible to fix that issue. 🧐 I will discuss about that with Alexandra (my product owner) |
Indeed, revenue is based on sale order lines, but one line can be linked to multiple projects/analytic accounts, so taking that approach would be way more complex, requiring some form of heuristic to divide the line's revenue between multiple timesheet entries. |
Yep, that's why I think we should not cover that case since it is too complex. 🙁 |
Versions
Steps
Issue
The profitability shows shows the total revenue of the SO, but only the cost of that specific project.
Cause
The
_get_profitability_items
override only checks the AAL associated with that project.Solution
Call
_get_profitability_items
on all projects linked the the project's sales order.opw-3631672