Odoo Changelog — 2024-11-26

Tuesday, November 26, 2024

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] hr_holidays: fix accrual plan in hours

Core17.0hr_holidaysMedium

This fix ensures time off accrual plans configured in hours calculate carry-over limits and future balances correctly, even when the time off type is displayed in days. It prevents employees from seeing inflated leave balances and helps HR teams apply accrual policies as intended.

Original PR description

Steps
- create an accrual plan with a level giving 1 hour every month and a carry
over with a maximum of 4 hours. Set accrued gain time at the start of the period
and carry-over time at start of the year.
- create an allocation using this accrual plan, for a time off type in days,
set the start date on the first day of next year.
- go to Time Off Dashboard
- check the balance on the middle of the month of the following year (e.g.
15 january 2026 if the allocation starts on 1 january 2025).

-> ~14 days of time off available: the max postpone amount is not applied,
the time gained is in days and not in hours and more than 1 day is gained/month
(balance a few days after the start of the allocation should be +1 added_value
but is more than that).

Causes:
- the maximum amount of carry over `postpone_max_days` is applied in days
even if the accrual `added_value` is in hours and the UI shows `postpone_max_days`
as "Up to X hours".
- `get_future_leaves` returns a number of hours if the allocation is in hours, even
if the time off type is in days.
- the number of hours from the accrual at the beginning of the allocation is too
high if the start of the accrual is in the future and gain time added at the start
of the period due to cache not being invalidated.
https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578

opw-4272315

#time off#accruals#leave balance#carry over

[FIX] web: editable grouped list: correctly leave edition

PR #188611

Core17.0webMedium

This fix prevents unsaved edits in grouped list views from being lost when a user collapses a group or adds a new line. It improves data reliability for users working with editable lists by making sure their in-progress changes are properly kept before the view changes.

Original PR description

This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state,
 - clicking on the group header to close the group, or
 - clicking on "Add a line" to add a new record would both lead to the change being lost.

This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record.

opw~4174315

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#editable lists#grouped views#data loss prevention

[FIX] stock: avoid error when apply putaway strategy on packages

PR #188074

Core17.0sale_stockstockMedium

Warehouse receipts no longer fail when products packed together need to be routed to different stock locations. This prevents a validation error and helps purchasing and warehouse teams complete receipts smoothly in this scenario.

Original PR description

Steps to reproduce the bug:
- Create a storable product “P1” and “P2”
- Create two route:
    - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action
                    - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action

    - route 2:
        - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action
        - rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action

- P1 -> route 1 + buy (add azure interior as vendor)
- P2 -> route 2 + buy (add azure interior as vendor)

- Create a SO: - vendor: Azure interior
    - One unit of P1 and P2

- Confirm the SO
- Go to the created PO
- Confirm the PO and go to the reception
- put in pack the products together
- Try to validate the picking

Probelm:
An User Error is triggered:
ValueError: Expected singleton: stock.location(3694, 3696)

Because we have two moves with different destination locations, and we are trying to set them in all the move lines.

opw-4291067

17.0 fix change costing method arm

PR #188190

Core17.0stock_accountMedium

This fix prevents incorrect stock valuation amounts when a product's costing method or category is changed. It ensures accounting entries stay balanced and inventory values remain reliable for financial reporting.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#inventory valuation#costing method#accounting

[FIX] account_reports: Sum total for parent groupby report line

PR #74542

Enterprise17.0account_reportsMedium

This fix ensures totals in grouped accounting reports are added together correctly instead of being overwritten. Business users viewing reports such as the balance sheet with custom groupings will now see accurate parent-line totals.

Original PR description

Version: 17.0+

Issue: Total of groupby is overwritten instead of summed.

Purpose of this PR:
Sum the totals to the parent groupby report line.

Steps to Reproduce on Runbot:
1) install accounting
2) go to balance sheet
3) create a new report line with a custom groupby (for ex: partner_id) 
4) set up simple expression (for ex: balance, prefix of account codes, 4) 
5) open balance sheet and see that the sum for some partners is incorrect

opw-4306356

#accounting#financial reports#grouped totals

[FIX] mrp_account_enterprise: use correct qty field in Cost Analysis

PR #70727

Enterprise17.0mrp_account_enterpriseMedium

This update fixes an issue where the Cost Analysis report inaccurately reflected manufactured quantities and unit costs. The change ensures the report correctly calculates costs based on the actual quantity of products manufactured, improving the accuracy of cost reporting.

Original PR description

## Issue:
- The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit.

## Steps to reproduce:
- Create a manufactured product and two components with costs and on hand quantities.
- Confirm a manufacturing order for the product.
- Adjust the manufactured quantity of the manufactured product.
- Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit.

## Solution:
- Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`.

opw-4118237

#costing#manufacturing#reporting

Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025). -> ~14 days of time off available: the max postpone amount is not applied, the time gained is in days and not in hours and more than 1 day is gained/month (balance a few days after the start of the allocation should be +1 added_value but is more than that). Causes: - the maximum amount of carry over `postpone_max_days` is applied in days even if the accrual `added_value` is in hours and the UI shows `postpone_max_days` as "Up to X hours". - `get_future_leaves` returns a number of hours if the allocation is in hours, even if the time off type is in days. - the number of hours from the accrual at the beginning of the allocation is too high if the start of the accrual is in the future and gain time added at the start of the period due to cache not being invalidated. https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578 opw-4272315

This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~4174315 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce the bug: - Create a storable product “P1” and “P2” - Create two route: - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action - route 2: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action - P1 -> route 1 + buy (add azure interior as vendor) - P2 -> route 2 + buy (add azure interior as vendor) - Create a SO: - vendor: Azure interior - One unit of P1 and P2 - Confirm the SO - Go to the created PO - Confirm the PO and go to the reception - put in pack the products together - Try to validate the picking Probelm: An User Error is triggered: ValueError: Expected singleton: stock.location(3694, 3696) Because we have two moves with different destination locations, and we are trying to set them in all the move lines. opw-4291067

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Version: 17.0+ Issue: Total of groupby is overwritten instead of summed. Purpose of this PR: Sum the totals to the parent groupby report line. Steps to Reproduce on Runbot: 1) install accounting 2) go to balance sheet 3) create a new report line with a custom groupby (for ex: partner_id) 4) set up simple expression (for ex: balance, prefix of account codes, 4) 5) open balance sheet and see that the sum for some partners is incorrect opw-4306356

## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution: - Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`. opw-4118237