Monday, February 9, 2026
6 changes · 17.0
Enhancements to existing features
This update enhances the generation of electronic transport documents (eTransport) for Romanian businesses. It includes logging of sent XML files for tracking, ensures accurate pricing using standard unit costs, and implements necessary rounding to comply with Romanian tax regulations. These changes improve the reliability and compliance of eTransport shipments.
Original PR description
- Adding logging of sent XML into move chatter - Adjusting the XML generator to use standard unit price - Adding rounding for product values as required by the XML structure task-5892338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts a key parameter within the Australian Payroll module (l10n_au_hr_payroll) to comply with recent tax regulations. This change ensures accurate processing of PEA (Payroll Tax Equivalent Arrangement) calculations, maintaining compliance and minimizing potential financial discrepancies. It's an important update for businesses operating in Australia.
Original PR description
This task updates PEA rule parameter value task-5884083
Resolved issues and error corrections
This update resolves a bug where importing journal entries in foreign currencies could fail due to rounding discrepancies. The issue stemmed from individual line rounding, leading to an imbalance between debit and credit. This fix ensures journal entries with foreign currency transactions can be reliably imported and balanced.
Original PR description
**PROBLEM** If you create/import a journal entry using a foreign currency, it can happen that the journal entry is balanced in said foreign currency but isn't balanced in the company currency,…
**PROBLEM** If you create/import a journal entry using a foreign currency, it can happen that the journal entry is balanced in said foreign currency but isn't balanced in the company currency, preventing you from creating/importing the journal entry. When creating the journal entry, you could add a line to balance this, but if you import it, you can't. **STEP TO REPRODUCE** 1. Set the exchange rate: 1€ = 0.134068$ 2. Import the journal entry named issue.csv (can be found in the ticket page or the PR). **CAUSE** Because we round each line individually, we may end up with a rounding issue that leads to debit/credit not being equal. opw-4668369 | Reference | account_move_journal.id | Date | Journal Items / Account | Journal Items / Currency | Journal Items / Amount in Currency | |-----------|--------------------------|---------|-------------------------|--------------------------|------------------------------------| | Bunq | Miscellaneous Operations | 8/15/25 | 1010 | EUR | -34.9 | | | | | 1050 | EUR | 34.9 | | | | | 1100 | EUR | 2.69 | | | | | 1200 | EUR | 32.21 | | | | | 1300 | EUR | -34.9 |€
This update corrects a reporting issue where unreserved stock was incorrectly included in the stock in transit forecast. The fix ensures that only non-available quantities are considered, providing a more accurate view of inventory movement for sales forecasting. This improves the reliability of sales order predictions.
Original PR description
**Issue** It is possible to have unreserved quantity, outside the stock location, considered as 'stock in transit' in the forecast report. This is an issue because that means some quantities, that…
**Issue** It is possible to have unreserved quantity, outside the stock location, considered as 'stock in transit' in the forecast report. This is an issue because that means some quantities, that are not meant to be moved to the stock location, are linked to a delivery. **Steps to reproduce** - Activate 3 step receipt on your warehouse - Create a new product 'Test' and adds 1 Unit in WH/Input and 1 Unit in WH/Quality - Create a sales order for 2 Units and check the forecast report of Test -> 2 units are recorded as 'stock in transit' links to the so delivery while they should not. **Cause** The forecast report is computed here: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L17-L24 The lines are computed here: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L125 Currently, stock in transit is calculated by: Aggregating quantities per product and location (including unreserved quantities): https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L327-L328 Removing the reserved stock, then summing per product: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L353-L354 Assigning the result as 'stock in transit' (since free_stock is 0 here): https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L361 This method incorrectly includes unreserved quantities from intermediate locations. **Solution** Since we only want non-available quantity to be considered as stock in transit, we use the reserved quantity instead. No need to substract the free quantity anymore since free quantity are no reserved by definition. opw-5865378
This update resolves a problem where project breadcrumbs disappeared after migrating databases from older versions to the latest. The change ensures correct breadcrumb functionality when opening projects from sale orders, particularly after upgrading from version 16. This improves the user experience and data visibility.
Original PR description
Steps to reproduce: 1. Create a db with having 'sale' & 'project' installed in version 16. 2. Create a sale order having linkage to more than single project. 3. Migrate the db to version 19. 4. When…
Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.
Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)
When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17
This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.
OPW-5448916
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-prThis update standardizes the way time off and absences are recorded and transmitted for payroll reporting in Switzerland (CH). It backports a fix from the main Odoo repository, ensuring accurate and compliant reporting by aligning views and data structures related to leave management.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/f238e04f3f6c39b61d0449a0766809df06eb6980 task-5384297