Odoo Changelog — 2026-03-22

Sunday, March 22, 2026

6 changes · saas-19.1

Bug Fixes(6)

Resolved issues and error corrections

[FIX] documents_hr_payroll: fix employee declaration PDF generation UX

Enterprisesaas-19.1hr_payrollMedium

This update fixes a user experience issue where the 'Generate PDFs' button in the employee declaration list view only processed the currently visible records. Now, selecting 'Select All' reliably generates PDFs for all employee declarations, improving user clarity and efficiency. The fix also allows users to regenerate PDFs for existing documents.

Original PR description

This PR solves the following issues:

- In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed.

- When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state.

task-5909426

Forward-Port-Of: odoo/enterprise#107232

#PDF Generation#Employee Declarations#User Experience

[FIX] documents_spreadsheet: linked record on import

PR #111532

Enterprisesaas-19.1documents_spreadsheet

This update fixes an issue where imported spreadsheets lost their connection to the original linked records. The change ensures that newly created spreadsheets maintain the same linked record as the source document during the import process, improving data consistency and workflow efficiency.

Original PR description

When importing an XLSX or CSV document into a spreadsheet, the linked record is lost on the newly created spreadsheet document.

This happens because the conversion creates a new document through `copy()`, while `res_model` and `res_id` are computed fields and are not copied by default.

This commit explicitly forwards the linked record values during the conversion so the created spreadsheet keeps the same linked record as the source document.

Task: [6008920](https://www.odoo.com/odoo/project/2328/tasks/6008920)

Forward-Port-Of: odoo/enterprise#110047

#import#spreadsheet#linked records

[FIX] l10n_jo_edi_pos: Fix payment methods issues

PR #255222

Coresaas-19.1l10n_jo_edi_posMedium

This update resolves an issue where multiple payment methods on a point-of-sale order caused errors. It now ensures that a customer is required when using receivable payment methods or cash payments exceeding 10,000 JOD, improving the reliability of transactions.

Original PR description

This commit fixes the following issues
1) Having more than one payment method on a pos.order led to an error
2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD

task-6005832

Forward-Port-Of: odoo/odoo#255030
Forward-Port-Of: odoo/odoo#252631

#pos#payment#jo

[FIX] purchase_mrp: fix kit cost calculation for multi-unit POs

PR #253439

Coresaas-19.1purchase_mrpstock_accountMedium

This update fixes an error in how the cost of kit products is calculated when ordering multiple units on a purchase order. Previously, the cost was incorrectly displayed, leading to inaccurate inventory valuation. This change ensures accurate cost calculations for multi-unit kit purchases.

Original PR description

**Issue**: A PO of several units of kit product can lead to a wrong BOM cost **Steps to reproduce**: - Create a kit product (by creating a BOM) with AVCO valuation - Create a purchase order with 3…

**Issue**:
A PO of several units of kit product can lead to a wrong BOM cost

**Steps to reproduce**:
- Create a kit product (by creating a BOM) with AVCO valuation
- Create a purchase order with 3 units and a unit price of 10
- Confirm it and confirm the associated receipt
- Go to the BOM of the kit product and check BOM overview 
-> The cost is 3.33 instead of 10

This also works with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the PO:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L371-L372 Which relies on the `cost_ratio`:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_stock/models/stock_move.py#L221-L222 Which is computed this way:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_mrp/models/stock_move.py#L17 And does not take the number of received units into account.

This means that the value of the move is 10 instead of 30, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

opw-5924940

Forward-Port-Of: odoo/odoo#249236

[FIX] stock_account: Ensure product stock is accurate for a given to date

PR #253438

Coresaas-19.1stock_accountMedium

This update fixes an issue where stock valuations were inaccurate for users in different timezones. The change ensures that stock quantities are correctly calculated when a 'to_date' is selected, addressing a discrepancy in how dates are interpreted and converted.

Original PR description

**Issue**
While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone.

**Steps to reproduce**
- Set the user timezone to UTC+1
- Create a storable product with:
  - quantity: 10 (created today)
  - unit cost: 5
  - valuation method: AVCO
- Go to Accounting > Review > Inventory > Inventory Valuation
- Select today's date
- Click on "Ending Stock"

-> The total value and quantity in stock are 0 instead of respectively 50 and 10.

**Cause**
When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation:
- 12/04 00:00 (user timezone) -> 11/04 23:00 UTC
- Converted to 23:59 UTC -> 12/04 00:59 in user timezone

As a consequence, most of the quantities created on 12/04 are excluded from the valuation.

This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153

This inconsistency leads to incorrect quantities and valuation results.

opw-5491743

Forward-Port-Of: odoo/odoo#246163

[FIX] mrp: use work center availability to compute total expected workorder duration

PR #254071

Coresaas-19.1mrpMedium

This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential delays in production timelines.

Original PR description

**Issue**
The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day.

**Steps to reproduce**
1. Create a manufacturing order with:
   - A work order with an expected duration of 1440 minutes.
   - A work center configured to work 8 hours per day.
2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date.

**Cause**
The `date_finish` computation:
https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105
does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration.

**Solution**
Use `_get_first_available_slot`:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332
to consider workcenter availability, inspired from when a workorder is planned:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527
**Additionnal notes**
- If a workcenter of at least one workorder is unavailable, just fallback on the previous computation.
- The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies.
- Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919

opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#252654
Forward-Port-Of: odoo/odoo#240617

This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232

When importing an XLSX or CSV document into a spreadsheet, the linked record is lost on the newly created spreadsheet document. This happens because the conversion creates a new document through `copy()`, while `res_model` and `res_id` are computed fields and are not copied by default. This commit explicitly forwards the linked record values during the conversion so the created spreadsheet keeps the same linked record as the source document. Task: [6008920](https://www.odoo.com/odoo/project/2328/tasks/6008920) Forward-Port-Of: odoo/enterprise#110047

This commit fixes the following issues 1) Having more than one payment method on a pos.order led to an error 2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD task-6005832 Forward-Port-Of: odoo/odoo#255030 Forward-Port-Of: odoo/odoo#252631

**Issue**: A PO of several units of kit product can lead to a wrong BOM cost **Steps to reproduce**: - Create a kit product (by creating a BOM) with AVCO valuation - Create a purchase order with 3 units and a unit price of 10 - Confirm it and confirm the associated receipt - Go to the BOM of the kit product and check BOM overview -> The cost is 3.33 instead of 10 This also works with FIFO valuation **Cause**: While computing the value of the move: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the PO: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L371-L372 Which relies on the `cost_ratio`: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_stock/models/stock_move.py#L221-L222 Which is computed this way: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_mrp/models/stock_move.py#L17 And does not take the number of received units into account. This means that the value of the move is 10 instead of 30, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393 opw-5924940 Forward-Port-Of: odoo/odoo#249236

**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to UTC+1 - Create a storable product with: - quantity: 10 (created today) - unit cost: 5 - valuation method: AVCO - Go to Accounting > Review > Inventory > Inventory Valuation - Select today's date - Click on "Ending Stock" -> The total value and quantity in stock are 0 instead of respectively 50 and 10. **Cause** When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation: - 12/04 00:00 (user timezone) -> 11/04 23:00 UTC - Converted to 23:59 UTC -> 12/04 00:59 in user timezone As a consequence, most of the quantities created on 12/04 are excluded from the valuation. This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153 This inconsistency leads to incorrect quantities and valuation results. opw-5491743 Forward-Port-Of: odoo/odoo#246163

**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#252654 Forward-Port-Of: odoo/odoo#240617